Rana Dasgupta wrote:
On 11/20/07, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
Eugene Ostrovsky wrote:
It seems that we have a regression.
org.apache.harmony.jpda.tests.jdwp.Events.ClassUnloadTest
starts to fail from r596304 to r596371
So it seems that now that class unloading is enabled, JVMTI extension
event for class unloading has to be implemented to let this test pass.
The problem that I see here is that Sun's implementation passes a
reference to the unloaded class into event callback, so the reference is
still live (maybe weak?) at this point.
In our implementation there are no live references to the class objects
in VM part of the class unloading. There is even an assertion that
checks this in classloader.cpp:564.
There are two ways to fix this. First one is to create our own
implementation of class unloading event that wouldn't pass a reference
to the class being unloaded, just its name.
I am not very good with JVMTI semantics, but if it is OK to support an event
with the name only, I would vote for this. It is least intrusive.
I've looked at the agent code and it seems that the reference is
actually required. I didn't understand all of it, so possibly there is
still a workaround...
Second is to make references available in the VM part of class
unloading. But in this case agent may create a strong reference to the
class object, and class unloading has to be canceled (Actually, since
this event is an extension, it is not specified whether or not a strong
reference may be created).
This may be difficult to do in this implementation, since by the time the VM
gets back control in the class unloading cycle, it is possibly too late to
do this.
I think in case JVMTI is enabled, and agent requests this event to be
supported it is possible to create a collection of weak references to
class objects. Once a weak reference is enqueued, VM would send an event
to the agent, and it creates a strong reference, unloading shall
automatically be canceled. Otherwise the class would be unloaded in the
normal way.
--
Gregory
