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