While trying to reproduce JDK-8151256, this failure occurred a couple of times in about 50k runs. A SEGV occurs in memset when called from G1SATBCardTableModRefBS::g1_mark_as_young . It looks like the address range passed to g1_mark_as_young from dirty_young_block is valid.

#20 <signal handler called>
#21 0x00007fb37d5ea886 in __memset_sse2 () from /lib64/libc.so.6
#22 0x00007fb37c9b9370 in dirty_young_block (word_size=2697, start=0xff900000, this=0x7fb374025e30)
    at /scratch/workspace/9-2-build-linux-amd64-phase2/jdk9/4520/hotspot/src/share/vm/gc/g1/g1CollectedHeap.inline.hpp:134
#23 attempt_allocation (gclocker_retry_count_ret=0x7fb21dd4c70c, gc_count_before_ret=0x7fb21dd4c708, word_size=2697, this=0x7fb374025e30)
    at /scratch/workspace/9-2-build-linux-amd64-phase2/jdk9/4520/hotspot/src/share/vm/gc/g1/g1CollectedHeap.cpp:906
#24 G1CollectedHeap::allocate_new_tlab (this=0x7fb374025e30, word_size=2697)
    at /scratch/workspace/9-2-build-linux-amd64-phase2/jdk9/4520/hotspot/src/share/vm/gc/g1/g1CollectedHeap.cpp:517
#25 0x00007fb37c882783 in CollectedHeap::allocate_from_tlab_slow (klass=..., klass@entry=..., thread=thread@entry=0x7fb214114000, size=size@entry=3)
    at /scratch/workspace/9-2-build-linux-amd64-phase2/jdk9/4520/hotspot/src/share/vm/gc/shared/collectedHeap.cpp:301

It may be that all of these problems running HeapRetentionTest with +ResourceManagement are due to the same underlying synch problem (or 2).

One difference between these and the other reports is that these were run with the MainWrapper that the test system uses, rather than directly. The original failure (in 8151256) has finally just occurred once running this way.

Note, this is with build 9-ea+107-2016-02-24-205307.javare.4520, thus about a month old.