RE: [cp-patches] FYI: ClassLoader caching Part 2
Mark Wielaard wrote: On Mon, 2005-07-25 at 18:17 +0200, Jeroen Frijters wrote: Is this an important scenario? I thought you long haired types didn't like binary distributions ;-) He he. Sure we don't. But if you follow the harmony effort of the cleanly shaved apache types you will have noticed that they might actually be paranoid enough to not look at or use something that comes with source code :) But I do care about binary installations! I have here two runtimes (jamvm and kissme) who both use the same GNU Classpath installation, but both overlay the VM classes differently. I would actually like that to be true for some of the others I have installed here too. That's a good point. I've removed the final modifier, that should do the trick and still allow VMs that replace the class to make the field final. Regards, Jeroen 2005-07-26 Jeroen Frijters [EMAIL PROTECTED] * vm/reference/java/lang/VMClassLoader.java (USE_VM_CACHE): Removed final modifier. Index: vm/reference/java/lang/VMClassLoader.java === RCS file: /cvsroot/classpath/classpath/vm/reference/java/lang/VMClassLoader.java,v retrieving revision 1.28 diff -u -r1.28 VMClassLoader.java --- vm/reference/java/lang/VMClassLoader.java 25 Jul 2005 14:28:42 - 1.28 +++ vm/reference/java/lang/VMClassLoader.java 26 Jul 2005 06:45:09 - @@ -285,8 +285,10 @@ /** * Set this field to true if the VM wants to keep its own cache. + * Note that this field is not final, to allow VMs to have a + * different setting without having to recompile ClassLoader.java. */ - static final boolean USE_VM_CACHE = false; + static boolean USE_VM_CACHE = false; /** * If the VM wants to keep its own cache, this method can be replaced. ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
RE: [cp-patches] FYI: ClassLoader caching Part 2
Mark Wielaard wrote: 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. Trust me, I know all this ;-) It is an annoying byte code optimization. It's Java's version of #define. So for things that can be different at runtime like the VMClasses you unfortunately cannot use static final fields of primitive types. As long as you build everything from source (with the replaced VM* classes) it works, but I must admit that I have no clue about how everyone builds the class library (personally, I don't use any of the build infrastructure that comes with GNU Classpath). Regards, Jeroen ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
RE: [cp-patches] FYI: ClassLoader caching Part 2
Jeroen Frijters wrote: Mark Wielaard wrote: On Mon, 2005-07-25 at 16:29 +0200, Jeroen Frijters wrote: I committed the attached patch to complete to ability of the VM to bypass the class caching in ClassLoader. 2005-07-25 Jeroen Frijters [EMAIL PROTECTED] * java/lang/ClassLoader.java (loadedClasses): Set based on VMClassLoader.VM_USE_CACHE. (defineClass): Modified to respect VMClassLoader.VM_USE_CACHE. * vm/reference/java/lang/VMClassLoader.java (VM_USE_CACHE): New field. 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. Oh, I'm sorry, I think see what you mean. If a VM would take a binary GNU Classpath jar, it wouldn't be able to override the value of the flag. Is this an important scenario? I thought you long haired types didn't like binary distributions ;-) Regards, Jeroen ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] FYI: ClassLoader caching Part 2
Jeroen Frijters wrote: Oh, I'm sorry, I think see what you mean. If a VM would take a binary GNU Classpath jar, it wouldn't be able to override the value of the flag. Is this an important scenario? I thought you long haired types didn't like binary distributions ;-) OK now I get it too... I call this idea of imposing VM-specific versions of a class in front of the stock Classpath versions overlaying instead of overriding to avoid confusion :-) Yes, I think not breaking overlaying is important.. so a static method (with comment why being used) would be better. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
RE: [cp-patches] FYI: ClassLoader caching Part 2
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
Index: java/lang/ClassLoader.java
===
RCS file: /cvsroot/classpath/classpath/java/lang/ClassLoader.java,v
retrieving revision 1.54
diff -u -p -r1.54 ClassLoader.java
--- java/lang/ClassLoader.java 25 Jul 2005 14:28:42 - 1.54
+++ java/lang/ClassLoader.java 25 Jul 2005 18:37:38 -
@@ -40,6 +40,7 @@ package java.lang;
import gnu.classpath.SystemProperties;
import gnu.classpath.VMStackWalker;
+import gnu.classpath.jdwp.Jdwp;
import gnu.java.util.DoubleEnumeration;
import gnu.java.util.EmptyEnumeration;
@@ -152,6 +153,14 @@ public abstract class ClassLoader
*/
private final boolean initialized;
+ /**
+ * This list is kept around for JDWP. We need a way to know every class
+ * that this ClassLoader has been asked to load, thus they will be added
+ * here. There's no need to do anything else, JDWP is able to sniff out
+ * private fields so we'll just sniff this field as well!
+ */
+ final ArrayList loadRequests = new ArrayList();
+
static class StaticData
{
/**
@@ -333,23 +342,25 @@ public abstract class ClassLoader
{
if (parent == null)
{
- c = VMClassLoader.loadClass(name, resolve);
- if (c != null)
- return c;
- }
- else
- {
- return parent.loadClass(name, resolve);
- }
- }
- catch (ClassNotFoundException e)
- {
- }
- // Still not found, we have to do it ourself.
- c = findClass(name);
+ c = VMClassLoader.loadClass(name, resolve);
+ }
+else
+ {
+ c = parent.loadClass(name, resolve);
+ }
+ }
+ catch (ClassNotFoundException e)
+ {
+ }
+ // Still not found, we have to do it ourself.
+ if (c == null)
+c = findClass(name);
}
+}
if (resolve)
resolveClass(c);
+if (Jdwp.isDebugging)
+ loadRequests.add(c);
return c;
}
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
RE: [cp-patches] FYI: ClassLoader caching Part 2
Hi Jeroen, On Mon, 2005-07-25 at 18:17 +0200, Jeroen Frijters wrote: Is this an important scenario? I thought you long haired types didn't like binary distributions ;-) He he. Sure we don't. But if you follow the harmony effort of the cleanly shaved apache types you will have noticed that they might actually be paranoid enough to not look at or use something that comes with source code :) But I do care about binary installations! I have here two runtimes (jamvm and kissme) who both use the same GNU Classpath installation, but both overlay the VM classes differently. I would actually like that to be true for some of the others I have installed here too. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
