AnonymousClassLoader and ClassLoader

[Rémi Forax]

John Rose a écrit :
> On Apr 25, 2008, at 8:47 AM, Rémi Forax wrote:
>
>> John Rose a écrit :
>>> On Apr 24, 2008, at 2:26 AM, Rémi Forax wrote:
>>>
>>>> In my opinion, getResource() is not the only method that makes this
>>>> assumption
>>>
>>> The getResource method probably needs to be adjusted since anonymous 
>>> classes have names that are intentionally distorted.  The anonymous 
>>> class name ends with "/${hashcode}" so that attempts to do forName 
>>> will rapidly fail, and so that it is clear which classes are anonymous.
>> Are you sure hashcode are unique and never creates a name collisions ?
>
> No, there *will* be name collisions.  The hashcode is to help with 
> debugging, and should be ignored by any code that is attempting to 
> assign a name to the anonymous class.   (Everything after the slash 
> should be stripped.)  Using the name in any way at all is a slippery 
> slope, but obtaining the resources from the class's formal name seems 
> like it's not too much of a hack.
ok
>
>>> The logic for Class.resolveName needs to take this case into account 
>>> if resources are to work.  (I assume that it is a good idea for them 
>>> to "work", but maybe it's not.)  It's a good question, and a nice 
>>> experiment.
>>>
>>> -- John
>> Perhaps it's a good idea to try to surface isAnonymousClass() a Java 
>> level
>> or even better getHostClass() (or getAnonymousHostClass()).
>> I will try to create a patch for that this week-end, i seems to be a 
>> good idea
>> to try to understand the VM internals.
>
> Yes; you can see from the JVM patch that I'm on the edge of doing 
> this.  The useful idea at present is that the class anonymous iff it 
> has a slash in its getName; it would be bad for it to have a legal 
> getName.
hum, i've chosen another path. I've  exported to the VM the 
instanceKlass.host_klass()
at Java level. It takes me less than hour to figure how to do that and
since that i know try to to find how to create a patch using mercurial 
queues
knowing that i've forget to apply the last patch (callcc without anonk)
before hacking the VM.
It's half past one am here, i am going to rest  and i will submit the  
patch  tomorrow.

>
>> Another experiment,
>> trying to resolve an anonymous class using ClassLoader.resolveClass() 
>> leads to a crash in SystemDictionnary.
>> Step to reproduce, change sun.misc.Launcher by the one in attachement,
>> I have chnage the application classloader to load all non bootstrap 
>> class as anonymous one
>> (see findClass) but when it tries to call resolveClass() (in 
>> ClassLoader.loadClass()) on an anonymous class,
>> the VM crashs.
>>
>> I don't know if trying to resolve an anonymous class is legal or not.
>
> No, it's not legal.  It should throw a ClassNotFound or similar 
> exception.  Should not crash, obviously.
ok, i will investigate
>
>> The following lines are a cut&paste of the crash using the fastdebug 
>> VM (patched with anonk and callcc).
>
> Right, a failure like that is to be expected if the query gets that far.
>
> When you load everything as anonymous, how do you resolve intra-module 
> references?  That seems hopeless.  You can resolve some references by 
> using the CP patching feature, but that does not cover CP 
> circularities.  We need a simultaneous loading model to create complex 
> graphs of anonymous classes.  I don't see the need to do this yet.
For me, it was just a test.
I've created an empty class and tried to load all other classes as 
anonymous of this one so there is no reference
between the empty class and each anonymous class. And between anonymous 
class, i've kept
the mapping between name and anonymous class in a weak hashmap.
>
> (First figure out a multi-class loading model for normal classes!  I 
> have some good ideas for this based on my work with Pack200, but they 
> are back-burnered because of more pressing features.)
>
> -- John
Rémi