classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Query on stacktrace management logic


From: David Holmes
Subject: RE: Query on stacktrace management logic
Date: Wed, 3 Mar 2004 15:14:01 +1000

Archie Cobbs wrote:
> FYI, when I started working with Classpath I tried to respect the
> Foo-VMFoo split and not modify any Foo classes but eventually decided
> that it was too costly. E.g., every loaded class already has a Class
> object (I don't create them on-demand), but you double that number
> if you also have a VMClass object for each class.

Ouch! I hadn't seen the VMClass split as we're still on 0.05. I have to
agree there is no way I will use this version of things. Class is pretty
much guaranteed to be VM specific. I can see the benefit of having the class
initialization process spelt out in VMClass, but I'd be inclined to use
VMClass as a helper, with static methods that take a Class instance, rather
than having a VMClass shadow per Class object. (Just like VMClassloader is a
helper and there is not a VMClassloader per Classloader).

Whilst on the subject of class Class, I've mentioned before that it really
should not have any static initialization in it. class Class is the first
class that must be initialized and trying to set up protection domains as
the first thing the VM does seems implausible to me. At a minimum you have
defer processing of Class's <clinit> until later in the bootstrapping
process. We moved that code into a method for lazy initialization later in
the bootstrap process.

Cheers,
David Holmes





reply via email to

[Prev in Thread] Current Thread [Next in Thread]