[9] RFR (S): 8148940: java/lang/ref/FinalizeOverride.java can time out due to frequent safepointing

Aleksey Shipilev aleksey.shipilev at oracle.com
Thu Feb 25 16:38:21 UTC 2016

On 02/25/2016 07:27 PM, Zoltán Majó wrote:
> (1) The test spends an increased amount of time in the VM (e.g.,
> because an ISC-enabled build can trigger up to 2X more compilations
> than a non-ISC-enabled build);

I am confused about this. I thought we bootstrap the concatenations once
per concat site, and then we only "roll" with the linked in
implementation. Is that one-shot action enough to get into the despair
vortex in the test?

> Possible solutions: Update the test to give more chance to the VM to
> progress. I see two ways of doing that:
> Solution #1: Reduce the freqency of triggering GCs
> http://cr.openjdk.java.net/~zmajo/8148940/webrev.00/

From the set of presented solutions, I like this solution better,
because it breaks the Denial-of-Service setup. Other work after ISC --
e.g. harder GCs -- can possibly trigger the same trouble, right?

> Solution #2: Remove string operations from finalizers.
> http://cr.openjdk.java.net/~zmajo/8148940/webrev.01/
> Solution #2 is faster, but it makes more difficult to monitor the
> progress of the test than in the case of Solution #1.

Solution #3: Compile the test with -XDstringConcat=inline to disable ISC
for this test; jtreg allows this with @compile tag. Mention the vicious
feedback cycle in comments.

Solution #4: Kick finalize() methods in classes to link concats
preemptively, before entering System.gc+System.runFinalization loop.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160225/2d3684ca/signature-0001.asc>

More information about the hotspot-compiler-dev mailing list