Research into modifications on the primordial class loader

[Apurba Nath]

Hi Ivo

I am not an expert, read at your own risk, am looking into the same
problem myself. I understand that your original problem was "dynamic
continuous integration at run-time and dynamic self-modification", if
that is the case we are interested in reloading a different version of
the same class, if so unloading the class and loading the new class is
going to be pretty complicated, as we would need to move all the
existing objects from the previous class definition to the new, also
remember its impact on all the classes that extend this.

I am trying to currently soup up the vtable and itable portions in the
class definition, the idea is that when we provide a new version of an
existing class, we analyse the methods that have been modified and the
ones that have been added and make the corresponding changes in the
vtable. The current vtable implementation needs to be modified to make
it grow dynamically at class levels, if you or anyone else is
interested, can send details of the changes that I am trying to
implement.

Thanks
Apurba



> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 2 Aug 2010 21:17:25 +0100
> From: "kammerath i. (ik3g09)" <ik3g09 at ecs.soton.ac.uk>
> Subject: Research into modifications on the primordial class loader
> To: "hotspot-runtime-dev at openjdk.java.net"
>        <hotspot-runtime-dev at openjdk.java.net>, "hotspot-dev at openjdk.java.net"
>        <hotspot-dev at openjdk.java.net>, "core-libs-dev at openjdk.java.net"
>        <core-libs-dev at openjdk.java.net>
> Message-ID:
>        <E117AD245282BA48ABE1E16E9712070C9F3134CB46 at UOS-CL-EX7-L3.soton.ac.uk>
> Content-Type: text/plain; charset="us-ascii"
>
> 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
>