JDK-8217522 : Missing barriers in some java_lang_String assertion code after JDK-8217442
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 13
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2019-01-22
  • Updated: 2019-08-08
  • Resolved: 2019-01-23
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 13
13 b05Fixed
Related Reports
Relates :  
JDK-8217442 - Optimize native accesses to String.value
Relates :  
JDK-8213229 - Investigate treating StringTable as weak in young collections
Description
java_lang_String class methods have assertions like:
assert(oopDesc::equals_raw(value, java_lang_String::value(java_string))
The naked oop comparison can fail if value moved for GC like Shenandoah, should use 
assert(oopDesc::equals(value, java_lang_String::value(java_string)) instead.

The raw equal comparisons were introduced in JDK-8217442, but only manifested after  JDK-8213229, because references in stringtable are not longer updated at safepoints after JDK-8213229.
Comments
I did not know about the "Status" line, that is special to Shenandoah. I only looked at the "GC events" queue logging which had zero entries. Thanks. Yes, the brief Shenandoah testing has been done a while ago.
23-01-2019
[~tschatzl] Actually, it is in middle of a GC. Please see attached hs_err file, following lines indicate that the GC is in updating reference phase. Heap: Shenandoah Heap 1937920K total, 506880K committed, 5116K used 3785 x 512K regions Status: has forwarded objects, updating refs, not cancelled JDK-8217442 came into rather recent, not sure if you had this patch when you ran the tests.
23-01-2019
Suggested priority: Impact -> High (assert/crash), Likelihood -> High (unknown yet), Workaround -> High (none) -> P1
23-01-2019
Can you clarify how this crash that could not occur before JDK-8213229 can occur now? The stack trace indicates we are at VM startup where no GC events occurred yet that could have changed the string table. JDK-8213229 only modifies how the string table is handled during GC afaict even with Shenandoah, but with no GC having occurred... It may be that the assert had been wrong in the first place though. Also remember doing gc/shenandoah jtreg runs with that change on openjdk with no issues.
23-01-2019