Review request (S): 8005002: Crash because of a raw oop in ClassLoaderData::add_dependency

Stefan Karlsson stefan.karlsson at oracle.com
Thu Dec 13 02:32:52 PST 2012


On 12/13/12 11:28 AM, David Holmes wrote:
> Hi Stefan,
>
> On 13/12/2012 6:16 PM, Stefan Karlsson wrote:
>> http://cr.openjdk.java.net/~stefank/8005002/webrev.00/
>>
>> This is a fix for a crash seen the nightly comp testing in the test:
>> vm/mlvm/indy/stress/gc/lotsOfCallSites
>>
>> We have a raw oop while calling out to an allocation function that might
>> block for GC. If a GC enters, it might move the Object but will not
>> update the oop. Make sure that we wrap the oop in a handle before
>> calling the allocation function.
>
> Looks good to me.
>
> I guess CHECK_UNHANDLED_OOPS never got this one :(

Are we using CHECK_UNHANDLED_OOPS in our regular nightly testing or JPRT?

This code path is normally not executed, since most dependencies between 
class loaders are handled by the java.lang.ClassLoader.parent chain. 
However, running OSGi or jsr292 tests seem to exercise this code path.

thanks,
SefanK
>
> Thanks,
> David
>
>> StefanK



More information about the hotspot-dev mailing list