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.
Rob.
----Original Message Follows---- From: "David Holmes" <[EMAIL PROTECTED]> To: "Archie Cobbs" <[EMAIL PROTECTED]> CC: classpath <[EMAIL PROTECTED]> 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
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
_________________________________________________________________
It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
