Research into modifications on the primordial class loader
forax at univ-mlv.fr
Tue Aug 3 06:05:32 PDT 2010
There is already a patch in mlvm repository for adding/removing
Le 03/08/2010 07:20, Apurba Nath a écrit :
> 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
>> 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>
>> <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
>> 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-runtime-dev