Heads-up: failures with -XX:+StressLCM -XX:+StressGCM

[Aleksey Shipilev]

Actually no, still fails, but rarer, and in a different place. So far I
failed to come up with a minimized jtreg test. jcstress fails with this:

$ ~linux-x86_64-normal-server-release/images/jdk/bin/java
-XX:+UseShenandoahGC -jar tests-custom/target/jcstress.jar -t
StringBuilderTest -m quick --jvmArgs "-XX:+UnlockDiagnosticVMOptions
-XX:+StressLCM -XX:+StressGCM"

#  SIGSEGV (0xb) at pc=0x00007f28e954e097, pid=2163, tid=2200
#
# JRE version: OpenJDK Runtime Environment (9.0) (build
9-internal+0-2016-09-21-132916.shade.shenandoah-jdk9)
# Java VM: OpenJDK 64-Bit Server VM
(9-internal+0-2016-09-21-132916.shade.shenandoah-jdk9, mixed mode,
tiered, compressed oops, Shenandoah gc, linux-amd64)
# Problematic frame:
# J 844 C2 java.util.HashMap.resize()[Ljava/util/HashMap$Node;
java.base at 9-internal (356 bytes) @ 0x00007f28e954e097
[0x00007f28e954db80+0x0000000000000517]

hs_err points at SEGV in read barrier I recently asked about:

  0x00007f28e954e097: mov    -0x8(%r9),%rbp  <--- SEGV here
  0x00007f28e954e09b: cmpb   $0x0,0x3d8(%r15)
  0x00007f28e954e0a3: mov    -0x8(%r9),%rbp
  0x00007f28e954e0a7: je     0x00007f28e954e0b4
  0x00007f28e954e0a9: xchg   %rax,%rbp
  0x00007f28e954e0ac: callq  Stub::shenandoah_wb  ;   {runtime_call
StubRoutines (2)}
  0x00007f28e954e0b1: xchg   %rax,%rbp

This was supposed to be intercepted as trap, right?

-Aleksey

On 09/21/2016 11:18 AM, Aleksey Shipilev wrote:
> Thanks, it appears fixed on my side too, jcstress now happily chugs
> through the tests
> 
> Should we push some variant of this as regression test too?
>   http://cr.openjdk.java.net/~shade/shenandoah/TestFuzz.java
> 
> -Aleksey
> 
> On 09/21/2016 10:30 AM, Roland Westrelin wrote:
>>
>> Should be fixed now.
>>
>> Roland.
>>
>