RFR (xxs) JDK-8012525 gc/metaspace/G1AddMetaspaceDependency.java Test fails a safepoint timeout assertion or hangs.

[Mikael Gerdin]

On 10/01/2013 12:05 PM, Bernd Eckenfels wrote:
> Is the Bug about the Test failing or about the two slow path?

The bug is about the test hitting the timeout limit for the test harness.

>
> If it is about the test will there be work on the notorious slow path (if it is so easy to provoke)?

The test runs with -XX:G1UpdateBufferSize=1, it's a _very_ bad idea to 
run with this setting but it was extremely useful to provoke the bug 
that the regression test was attached to.

/Mikael

>
> Am 01.10.2013 um 11:44 schrieb Mikael Gerdin <mikael.gerdin at oracle.com>:
>
>> Hi
>>
>> Please review this small test fix to work around a problem where the test accidentally provokes a very slow execution path in the VM.
>> This slow path can cause very long GC pauses or delayed safepoints.
>>
>> Summary of the bug:
>> The byte array allocation causes a big MemRegion to be stored as the thread's deferred_card_mark. This can cause two separate slow code paths:
>>
>> * A slow GC pause because CollectedHeap::ensure_parsability flushes the cards through the VM barrier code and dirtying a large region is expensive with the small G1UpdateBufferSize.
>> * A thread_in_java being slow in reaching safepoint because it's flushing the cards in OptoRuntime::new_array_C at the call to new_store_pre_barrier, this ends up in the same code as ensure_parsability and can therefore be slow.
>>
>> I've ran the test with the large allocation removed and it still successfully reproduces the bug it was written to provoke on an unfixed build, so my suggestion is to simply remove the byte array allocation.
>>
>> The bug is unfortunately not externally visible.
>>
>> Webrev: http://cr.openjdk.java.net/~mgerdin/8012525/webrev
>>
>> /Mikael