Request for reviews (M) 8005600: compiler/8004741/Test8004741.java fails intermediately

[David Chase]

On 2013-01-21, at 9:31 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> With current code we can't guaranty it. We can add an other @run command to the test to increase frequency of safepoints:
> 
>  * @run main/othervm -Xmx64m -Xbatch -XX:+IgnoreUnrecognizedVMOptions -XX:-TieredCompilation -XX:+StressCompiledExceptionHandlers Test8004741
> + * @run main/othervm -Xmx64m -Xbatch -XX:+IgnoreUnrecognizedVMOptions -XX:-TieredCompilation -XX:+StressCompiledExceptionHandlers -XX:+SafepointALot -XX:GuaranteedSafepointInterval=100 Test8004741
> 
> The test will be executed 2 times for each set of flags.

Got that change.  Note that it only executes once if the first one crashes :-).

>>> I think this cases should be separated (separate test methods). Also it would be nice to add third case, as you suggested, by injected invalid dimension size.
>> 
>> I tried that; it did not trigger any crash under jdk7u11.  Do we try it anyway?
> 
> Yes, it will be test for future compiler source code changes (to avoid breaking exception catching in compiled code).
> 
> In 7u11, which does not have 8004741 fix, we always deoptimize compiled frame and Interpreter will catch any exception/error. So with 7u11 you are testing Interpreter instead of compiled code. It could be used to verify correctness of the test itself.

I'll find a way to work this in.  The test was surprisingly delicate; I attempted to refactor it so that I passed the array bounds in to the thread allocation, and the bug quit happening.

And are you sure that 7u11 is testing the interpreter?  The crash looks like this (from the hotspot log file):

---------------  T H R E A D  ---------------

Current thread (0x00007fc893110000):  JavaThread "Thread-2" [_thread_in_vm, id=311300096, stack(0x00000001127e1000,0x00000001128e1000)]

Stack: [0x00000001127e1000,0x00000001128e1000],  sp=0x00000001128e0040,  free space=1020k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.dylib+0x4a1257]
V  [libjvm.dylib+0x1b0fd7]
V  [libjvm.dylib+0x40642d]
V  [libjvm.dylib+0x3fee58]
V  [libjvm.dylib+0x3fef27]
v  ~ExceptionBlob
v  ~StubRoutines::call_stub
V  [libjvm.dylib+0x286acf]
V  [libjvm.dylib+0x286fac]
V  [libjvm.dylib+0x2870e6]
V  [libjvm.dylib+0x2bd820]
V  [libjvm.dylib+0x4763cc]
V  [libjvm.dylib+0x4778b2]
V  [libjvm.dylib+0x3b393d]
C  [libsystem_c.dylib+0x14742]  _pthread_start+0x147
C  [libsystem_c.dylib+0x1181]  thread_start+0xd

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
v  ~ExceptionBlob
J  Test8004741.test(II)[[I
j  Test8004741.run()V+24
v  ~StubRoutines::call_stub

>>> An other thing to improve is to add COMPILED state which set after 11000 iterations in the loop in run(). We test without tiered so threshold is 10000 for C2 (1000 for c1) and we use -Xbatch so the code will wait compilation finish.
>> 
>> The state variable is per-thread, tracking that thread's progress.  COMPILED ought to be true for all of them after the warm-up loop, and I don't know how to verify that the compiler has run; I could make up a compiled state and set it, but I no way of knowing that the code was in fact compiled when I set the state to COMPILED.
> 
> Correct, we can't guaranty it but it is more accurate then rely on time. I want main thread wait for COMPILED instead of RUNNING. Actually we can set RUNNING after 11000 iterations then you don't need to change code in main().

This seems like it would only act as documentation (above and beyond the comments already there), but if you think this is a good idea, I'll do it.

David