Research into modifications on the primordial class loader
David.Holmes at oracle.com
Mon Aug 2 16:44:35 PDT 2010
Just a clarification on terminology. The native loader in the VM is the
bootstrap loader. A class was loaded by the bootstrap loader if its
ClassLoader is reported as "null". There is then a hierarchy of
- the extensions loader is used to add the ability to load standard
extensions (from lib/ext if I recall correctly) these are classes that
are treated the same as "core" classes for security purposes
- the application-class loader, aka the system classloader (bad name),
is created to load the application class that you want to run
The application can then define its own classloaders.
For a ClassLoader to actually load a class it must use defineClass,
which is implemented in the VM as part of the native loader. Hence any
subterfuge has to be done inside the VM: you need to look at the
systemDictionary and the loader_constraints, which enforce the language
I really don't know how you would go about doing what you suggest
because the details are the critical points here. You could define a
ClassLoader that returned an arbitrary Class object for a given name,
but that Class object would report it's real identity. If this was part
of an implicit classloading process, then you'd likely get a
ClassCastException, or some other exception if you actually tried to
return a different Class than required.
kammerath i. (ik3g09) said the following on 08/03/10 06:17:
> Hello hotspot-runtime-dev, Hotspot-dev and core-libs-dev members,
> After initial contact with core-libs-owner, I have been able to get a lot further.
> The idea is to make certain modifications to the primordial/system-ClassLoader that lower security measures to gain a certain insight into higher reload-ability. As far as I currently understand, The Primordial ClassLoader is a mixture of system specific C files and standard Java classes. I am working with the version proposed below by Iris.
> When reloading an existing class I am so far forced to create a new classloader, as one classloader always has to return the same class object reference for the same class name. Meaning if I want to reload a class I always need an interface implemented by both the old and the new class-version to have a common type between both the custom and the system classloader, which allows me to access both versions of the class the same way (over a proxy pattern, to make references replaceable).
> Now I want to do something that one might consider as highly insecure. I want to allow a classloader to return different class object reference for the same class name. Thus I could bypass the whole interface fiddle and simply access the new object by the same type. I am aware of the fact that this means breaking the type-system/type-safe idea. As this means that two different types are considered as one without any shared inheritance. But logically they are the same type, but simply evolved.
> Where am I:
> Whilst reading through ClassLoader.java I came along void addClass(Class c) [line 258] which apperently is used by the JVM to record loaded classes, would this be where I could interfere by simply not record classes annotated with reloadable or something like that. Such that when checking whether a class is already registered it simply wouldn't be, thus I could reload it (probably not).
> Further along I came across getSystemClassLoader() in which I found initSystemClassLoader which lead me to Launcher.java [sun.misc.Launcher] in which I found the top-level nested class AppClassLoader, which I assume is the actual Primordial/System-ClassLoader. At least it is what ClassLoader.getSystemClassLoader() returns. In it I found a call "BootClassLoaderHook.preLoadClass(name);" is this where the C comes into play?
> I couldn't find anything else in the Java sources relating to "BootClassLoaderHook". What is this doing? Is this where I can make my insecure changes? Iris also pointed out ClassLoader.c, might this be what's hooked in with this specific call? if it is, how is it "hooked in"?
> I am open for any other suggestions in terms of: "where I could make changes" and "what changes I could make", to achieve the higher/different (even though less secure) reload ability.
> Many thanks in advance
> From: Iris Clark [iris at agathis.com] On Behalf Of irisg at alum.mit.edu [irisg at alum.mit.edu]
> Sent: 01 August 2010 03:35
> To: kammerath i. (ik3g09)
> Subject: RE: Research on the primordial class loader
> Hi, Ivo.
> I didn't receive your original message. I don't know what happened as it
> isn't in the set of pending moderator requests and your message didn't seem
> to make it into our archive (see the "archive link") near the top of this
> page: http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev
> One way to avoid the need for moderation is to become a subscriber. There
> is a digest mode if you get inundated with mail. Alternatively, you could
> just unsubscribe as soon as you get the information you need.
> I think that core-libs-dev is a fine place to ask your question.
> Alternatively hotspot-dev or hotspot-runtime-dev may also be good
> candidates as that is where a great deal of heavy lifting occurs for class
> loading. Here are some pointers for you to begin your investigation. I've
> selected subversion files from the JDK7 tl repository, but these files will
> reside in similar locations in other JDK repositories.
> java.lang.ClassLoader provides the specification for the delegation model
> and is the primary implementation. Note that specification comments such
> as this: "If the parent is "null", the class loader built-in to the
> virtual machine..." and the corresponding null checks are references to
> class loader implemented by the VM.
> The supporting libraries C code for j.l.ClassLoader. This is where
> libraries makes the calls into the VM.
> I am by no means a VM expert, but I believe that this is where the VM
> implements most of class loading. A VM engineer will be able to provide
> more details.
> I'm sure you've' already found it, but just in case... The VM
> Chapter 5 contains the complete spec for loading, linking, and
> Hope this gets you started. My apologies for not seeing your earlier
> From: Ivo
> Sent: 29 July 2010 17:15
> To: core-libs-dev at openjdk.java.net
> Subject: Research on the primordial class loader
> Hello core-libs-dev members,
> In my research on dynamic continuous integration at run-time and dynamic
> I reached a point where I would like to have a look at the implementation of
> the 'Primordial ClassLoader'.
> Which, according to what I read so far, is responsible for loading all
> classes, excluding those loaded by any
> custom ClassLaoder.
> When I downloaded the OpenJDK source I felt a little lost, I could not quite
> work out where to look.
> As far as I understood, the Primordial ClassLoader is more than just a
> bunch of Java classes.
> Correct me if I am wrong, but I assume it involves a few C/C++
> So my question is:
> Which classes are involved in the primordial classloading and which files of
> the HotSpot are involved in the process?
> many thanks in advance
More information about the hotspot-dev