classpath-patches
[Top][All Lists]
Advanced

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

RE: [cp-patches] FYI: ClassLoader caching Part 2


From: Aaron Luchko
Subject: RE: [cp-patches] FYI: ClassLoader caching Part 2
Date: Mon, 25 Jul 2005 14:40:10 -0400

On Mon, 2005-07-25 at 18:20 +0200, Mark Wielaard wrote:
> On Mon, 2005-07-25 at 17:55 +0200, Jeroen Frijters wrote:
> > > This won't work if you make the VM_USE_CACHE field static final. Then
> > > the constant will be compiled into ClassLoader making it impossible to
> > > override for the runtime vm-classes later. It has to be a 
> > > static method for that to work.
> > 
> > Like Archie says, your comment doesn't make sense ;-) If a VM decides
> > not to use the cache in ClassLoader, it replaces VMClassLoader and sets
> > the constant to true.
> 
> Yes, but unfortunately that doesn't change the byte-code of the
> ClassLoader class. static final primitive (and String) field values are
> actually inlined into other classes. So you can replace VMClassLoader
> all you want with a version the has VM_USE_CACHE set to another value,
> that won't actually change the ClassLoader code paths unless ClassLoader
> is also recompiled against this new value. Really, try it out. It is an
> annoying byte code optimization. So for things that can be different at
> runtime like the VMClasses you unfortunately cannot use static final
> fields of primitive types.
> 
> > I haven't looked at jdwp yet, but hopefully jdwp will provide its own
> > VM interface instead of messing around with the internals of other
> > classes.
> 
> Yeah that would be the clean way to do it indeed.

Well if it were decided to have some minor changes to allow VM re-use
this is pretty much how I would alter ClassLoader.

We're not ready to use it anyways but I'll put it out there so people
know what would be required.

Aaron

Attachment: classLoader.patch
Description: Text Data


reply via email to

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