[9] RFR (S): 8060147: SIGSEGV in Metadata::mark_on_stack() while marking metadata in ciEnv

Vladimir Ivanov vladimir.x.ivanov at oracle.com
Wed Oct 29 15:05:12 UTC 2014


Bertrand,

Thanks for the review.

There's another mechanism to support class redefinition - 
MetadataOnStackMark. It iterates over all threads and sets on_stack bit 
on every Metadata* it encounters. It keeps metadata from clearing.

Eventually, it calls ciObjectFactory::metadata_do() for every compiler 
thread which marks all Metadata* in associated 
ciObjectFactory::_ci_metadata.

Best regards,
Vladimir Ivanov

On 10/29/14, 7:24 PM, Bertrand Delsart wrote:
> Hi Vladimir,
>
> This seems OK with respect to class unloading but what about class
> redefinition ?
>
> In particular, this may not be sufficient for Method* or MethodData*.
> Still catching up on runtime issues but I think a redefined method has a
> smaller lifetime than its holder class. Hence, it seems that keeping the
> holder klass alive may not be sufficient to ensure a Method* survives as
> long as you need it for the ciMetadata.
>
> Regards,
>
> Bertrand.
>
> On 29/10/14 14:57, Vladimir Ivanov wrote:
>> http://cr.openjdk.java.net/~vlivanov/8060147/webrev.00
>> https://bugs.openjdk.java.net/browse/JDK-8060147
>>
>> ciObjectFactory doesn't keep cached Metadata* alive. ciMetadata is
>> different from ciObject - it doesn't store JNI handle, but a raw
>> Metadata* pointer.
>>
>> In order to avoid Metadata* vanishing during compilation, I cache
>> ciObject for it's holder, which should keep corresponding Metadata*
>> alive. Cached objects have the same lifetime as the owning
>> ciObjectFactory (no cache pruning), so Metadata* will be available as
>> long as ciObjectFactory instance is used.
>>
>> Also, cleaned relevant comments and strengthened some asserts (since
>> NULL keys are not allowed).
>>
>> Testing: jprt, stress mode - full Nashorn/Octane with aggressive VM
>> anonymous class unloading (LambdaForm/MethodHandle caching completely
>> turned off).
>>
>> Thanks!
>>
>> Best regards,
>> Vladimir Ivanov
>
>


More information about the hotspot-runtime-dev mailing list