[RFA] JVMTI/JDWP GetAllLoadedClasses

Kyle Galloway kgallowa@redhat.com
Fri Apr 27 15:05:00 GMT 2007


Tom Tromey wrote:
>>>>>> "Kyle" == Kyle Galloway <kgallowa@redhat.com> writes:
>>>>>>             
>
> Kyle> In order to avoid problems with circular class loading(try to
> Kyle> load a class, then try to add it to the class list, whihc
> Kyle> requires WeakReference to be loaded, which needs to be stored in
> Kyle> the list, whichi requires WeakReference to be loaded...and so
> Kyle> on), until it can be assured that WeakReference is loaded (which
> Kyle> is checked in ClassList::setup ()), the classes that have been
> Kyle> loaded are stored in a temporary linked list of jclass *.  When
> Kyle> setup is called, these classes are transferred over to the
> Kyle> WeakReference list, and the memory used by this temporary list
> Kyle> is freed.
>   
I have dropped the entire ClassList class in favor of a HashSet in 
VMClassloader.  This does present the problem of an additional java 
class to deal with, but I managed to get around this, see below.
> There's some code like this already in the VM startup sequence, to
> handle handoff to the bootstrap class loader after it is created.
> Maybe we could reuse this somehow.
>   
I've taken a long look this and I think you are referring to 
_Jv_CopyClassesToSystemLoader.  It so happens that this methods does the 
exact same type of thing to avoid class loading issues.  The problem is 
that the list it copies over is not complete (most of the time it is 
empty), so it doesn't quite do the trick.  This method is, however, an 
ideal place to know when it is safe to start using java classes, so I 
have done the following:

1. Wait for system_class_list == SYSTEM_LOADER_INITIALIZED, which is set 
in _Jv_CopyClassesToSystemLoader, before starting to add to the HashSet 
directly.
2. When _Jv_CopyClasses... is called, I use this time to copy over from 
my temporary list (now in natClassLoader.cc) and free its memory.
> Kyle> +  return (::java::util::Collection *) (cls_lst);
>
> Just for future reference, there's no need to cast from a subclass to
> a superclass.  This can be done implicitly.
That's strange, when I take the cast out I get a "cannot convert from 
java::util::HashSet* to java::util::Collection* error", so I have left 
it in.

I've attached a new patch.

ChangeLog
2007-04-27  Kyle Galloway  <kgallowa@redhat.com>

    * jvmti.cc (_Jv_JVMTI_GetLoadedClasses): New method.
    * classpath/lib/java/lang/VMClassLoader.class: Rebuilt.
    * gnu/classpath/jdwp/natVMVirtualMachine (getAllClasses): Implement.
    * java/lang/natClassLoader.cc (_Jv_CopyClassesToSystemLoader): Copy and
    free the temporary class list for JVMTI.
    (_Jv_PushClass): Add classes to the loaded classes list for JVMTI.
    * java/lang/VMClassLoader.java (getAllLoadedClasses): New method.
    * java/lang/VMClassLoader.h: Regenerated.

More questions, or is this ok?

Thanks,

Kyle

-------------- next part --------------
A non-text attachment was scrubbed...
Name: classes.patch
Type: text/x-patch
Size: 8115 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/java-patches/attachments/20070427/7c1d2735/attachment.bin>


More information about the Java-patches mailing list