C1 code installation and JNIHandle::deleted_handle() oop

Aleksey Shipilev shade at redhat.com
Tue Nov 14 16:08:18 UTC 2017

On 11/14/2017 04:36 PM, Vladimir Ivanov wrote:
> Aleksey,
> I agree with your & Roman analysis: compilers shouldn't touch naked oops unless the thread is in
> _thread_in_vm mode.
> Looking at the crash log, the problematic code is under assert:
> void ConstantOopWriteValue::write_on(DebugInfoWriteStream* stream) {
>   assert(JNIHandles::resolve(value()) == NULL ||
>          Universe::heap()->is_in_reserved(JNIHandles::resolve(value())),
>          "Should be in heap");
>   stream->write_int(CONSTANT_OOP_CODE);
>   stream->write_handle(value());
> }
> So, the proper fix would be to make the verification code more robust.

Actually, in Shenandoah case, the failure is here (it is obscured by inlining, but visible in

... "== deleted_handle()" or "!= deleted_handle()". So fortifying assert code does not help, the bug
is touching the oop in improper thread state. Nightmarish scenario would be to fail "!="/"==" check
because the deleted_handle oop had been already updated, but the actual handle value did not.

The similar thing happens after we write the oop into the debug stream: it is not handelize-d
anymore, and so opaque for GC, and thus has all the chance to be garbled by the time GC finishes.

Having these two thoughts in mind, I think we have to consider _thread_in_vm on that C1 path. But
where exactly?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20171114/14202e2d/signature.asc>

More information about the hotspot-compiler-dev mailing list