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

Bertrand Delsart bertrand.delsart at oracle.com
Wed Oct 29 17:55:05 UTC 2014


Got it,

I had forgotten that the GC no longer needs to walk the metadata by 
default and now understand why you need to instead explicitly keep the 
Java holder alive.

Looks good,

Bertrand, not a Reviewer.

On 29/10/14 16:05, Vladimir Ivanov wrote:
> 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
>>
>>


-- 
Bertrand Delsart,                     Grenoble Engineering Center
Oracle,         180 av. de l'Europe,          ZIRST de Montbonnot
38334 Saint Ismier,                                        FRANCE
bertrand.delsart at oracle.com             Phone : +33 4 76 18 81 23

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of
the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


More information about the hotspot-compiler-dev mailing list