Bug: ReferenceProcessor does from-space writes?

[Aleksey Shipilev]

Reproduced in CI two times, failed to reproduce locally.

-Aleksey

On 12/15/2016 12:36 PM, Roman Kennke wrote:
> This is odd.
> 
> During marking, we should only enqueue Reference objects that are in
> to-space. Adding read-barriers into ReferenceProcessor is most likely
> only hiding the real bug. The most likely cause is failing to mark a
> Reference object in previous cycle, thus not evacuating it....
> 
> Is this reproducible?
> 
> Roman
> 
> Am Donnerstag, den 15.12.2016, 12:32 +0100 schrieb Aleksey Shipilev:
>> Hi,
>>
>> Our CI brought us this assert:
>>
>> [VM ERROR] o.o.j.t.tearing.buffers.DirectByteBufferInterleaveTest
>>     (JVM args: [-Xmx16g, -XX:+ShenandoahStoreCheck,
>> -XX:ShenandoahGCHeuristics=aggressive,
>> -XX:+ShenandoahVerifyOptoBarriers,
>> -XX:+VerifyStrictOopOperations, -XX:+UseShenandoahGC, -XX:-
>> UseCompressedOops,
>> -Xint])
>>   Observed state   Occurrences   Expectation  Interpretation
>>
>>      0, 128, 128             0    ACCEPTABLE  Seeing all updates
>> intact.
>>
>>
>>     Messages:
>>         # To suppress the following error report, specify this
>> argument
>>         # after -XX: or in .hotspotrc:
>> SuppressErrorAt=/shenandoahBarrierSet.cpp:272
>>         #
>>         # A fatal error has been detected by the Java Runtime
>> Environment:
>>         #
>>         #  Internal Error
>> (/opt/jenkins/workspace/jdk9-shenandoah-
>> fastdebug/hotspot/src/share/vm/gc/shenandoah/shenandoahBarrierSet.cpp
>> :272),
>> pid=29026, tid=29028
>>         #  assert(o == __null || oopDesc::unsafe_equals(o,
>> resolve_oop_static(o))) failed: only write to-space values
>>
>>
>> hs_err shows this stack:
>>
>> V  [libjvm.so+0x15bc01f]  VMError::report_and_die(int, char const*,
>> char const*,
>> __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*,
>> int,
>> unsigned long)+0x15f
>> V  [libjvm.so+0x15bcdda]  VMError::report_and_die(Thread*, char
>> const*, int,
>> char const*, char const*, __va_list_tag*)+0x4a
>> V  [libjvm.so+0xa4e87a]  report_vm_error(char const*, int, char
>> const*, char
>> const*, ...)+0xea
>> V  [libjvm.so+0x13b374f]  ShenandoahBarrierSet::write_ref_field_work(
>> void*, oop,
>> bool)+0x11f
>> V  [libjvm.so+0x132f0e7]  BarrierSet::write_ref_field(void*, oop,
>> bool)+0x57
>> V  [libjvm.so+0x132c6dd]
>> ReferenceProcessor::enqueue_discovered_reflist(DiscoveredList&)+0x71d
>> V  [libjvm.so+0x1331582]  RefProcEnqueueTask::work(unsigned int)+0xa2
>> V  [libjvm.so+0x162b935]  GangWorker::loop()+0xc5
>> V  [libjvm.so+0x12315c2]  thread_native_entry(Thread*)+0x112
>>
>> The code is:
>>
>>     ...
>>     next_d = java_lang_ref_Reference::discovered(obj); // RB here
>>     ...
>>     java_lang_ref_Reference::set_next_raw(obj, obj);
>>     if (! oopDesc::safe_equals(next_d, obj)) {
>>       oopDesc::bs()->write_ref_field(
>>            // !!! Oops, re-reading without RB here?
>>            java_lang_ref_Reference::discovered_addr(obj),
>>            next_d);
>>
>> Most uses of Reference::*_addr seem suspicious to me.
>>
>> Thanks,
>> -Aleksey
>>