AnonymousClassLoader and ClassLoader

[John Rose]

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.

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

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

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

(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