Research into modifications on the primordial class loader

Tue Aug 3 06:05:32 PDT 2010

There is already a patch in mlvm repository for adding/removing
fields/methods.

see http://wikis.sun.com/display/mlvm/HotSwap

Rémi

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
> 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
>>
>>      