Research into modifications on the primordial class loader

[kammerath i. (ik3g09)]

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
Ivo
________________________________________
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.

http://hg.openjdk.java.net/jdk7/tl/jdk/file/4d72d0ec83f5/src/share/classes/j
ava/lang/ClassLoader.java
  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.

http://hg.openjdk.java.net/jdk7/tl/jdk/file/4d72d0ec83f5/src/share/native/ja
va/lang/ClassLoader.c
  The supporting libraries C code for j.l.ClassLoader.  This is where
  libraries makes the calls into the VM.

http://hg.openjdk.java.net/jdk7/tl/hotspot/file/cb4250ef73b2/src/share/vm/cl
assfile/
  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.

http://java.sun.com/docs/books/jvms/second_edition/html/VMSpecTOC.doc.html
  I'm sure you've' already found it, but just in case... The VM
specification,
  Chapter 5 contains the complete spec for loading, linking, and
initializing:

Hope this gets you started.  My apologies for not seeing your earlier
message.

Thanks,
iris
________________________________________
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
self-modification.
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++
classes/procedures?

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
Ivo