C1 code installation and JNIHandle::deleted_handle() oop

[Aleksey Shipilev]

On 11/14/2017 05:23 PM, Vladimir Ivanov wrote:
>> 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.
> 

See this line:
  http://hg.openjdk.java.net/jdk/hs/file/5caa1d5f74c1/src/hotspot/share/runtime/jniHandles.hpp#l224

  } else if ((value == badJNIHandle) || (value == deleted_handle())) {
    value = NULL;
  }
  return value;

If we ever get in that code during the GC, we might get the deleted_handle() updated by GC code
(because it is a root via JNIHandles), but the $value may be not updated, and still point to old
location. Then "value == deleted_handle()" fails, and we return broken oop from guard_value. Notice
this code is not under the assert.

It seems to me the symptom of larger problem: touching naked oops is seldom reliable, if the thread
is inconsistent state. It does not seem right to fix asserts, because the real trouble is touching
that oop on product paths. It appears to work for other GCs, but for Shenandoah this failure is
observable, because its barriers touch heap through the oops.

>> 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.
>
> I don't follow you. Can you point to the code you are talking about?
> ConstantOopWriteValue::write_on() writes the _handle_ and not the naked oop [1].

Right, this part I overlooked.

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/35eed2aa/signature-0001.asc>