C1 code installation and JNIHandle::deleted_handle() oop

[Aleksey Shipilev]

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
slowdebug):
  http://hg.openjdk.java.net/jdk/hs/file/5caa1d5f74c1/src/hotspot/share/runtime/jniHandles.hpp#l220

... "== 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?

Thanks,
-Aleksey

-------------- 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>