RFR (xxs) JDK-8012525 gc/metaspace/G1AddMetaspaceDependency.java Test fails a safepoint timeout assertion or hangs.
Bernd Eckenfels
bernd-2013 at eckenfels.net
Tue Oct 1 10:05:43 UTC 2013
Is the Bug about the Test failing or about the two slow path?
If it is about the test will there be work on the notorious slow path (if it is so easy to provoke)?
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
More information about the hotspot-gc-dev
mailing list