[Top][All Lists]

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

RE: Query on stacktrace management logic

From: Robert Lougher
Subject: RE: Query on stacktrace management logic
Date: Thu, 04 Mar 2004 11:41:49 +0000


Don't forget about the Thread/VMThread split introduced in Classpath 0.07!

Moving from 0.04 through to 0.07 I've had the same dilemma -- change the VM to go along with the changes or modify the classes. In the end, I've decided to stick with the split, mainly because of future maintenance issues. Hopefully at some point the VMFoo/Foo interface will become stable. I can then be pretty confident that no matter what changes are made in Classpath it should still work. If I modified the classes, on every release I'd need to check if any changes had been made that breaks JamVM, and do a merge if they had. Obviously the Foo classes should stabalise anyway so maybe it's pointless - it was a close call.


----Original Message Follows----
From: "David Holmes" <address@hidden>
To: "Archie Cobbs" <address@hidden>
CC: classpath <address@hidden>
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.

David Holmes

Classpath mailing list

It's fast, it's easy and it's free. Get MSN Messenger today!

reply via email to

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