Bug: ReferenceProcessor does from-space writes?

[Roman Kennke]

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
>