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

[Zoltán Majó]

Hi Aleksey,


thank you for the feedback!

On 02/25/2016 05:38 PM, Aleksey Shipilev wrote:
> 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.

You are right about that. Most "action" related to setting up 
concatenations happens once (in the case of this test during the 
execution of the first finalizer, i.e., FinalizeOverride$Base.finalize()).

> Is that one-shot action enough to get into the despair
> vortex in the test?

Yes, it is. In its original version, the test spends the largest part of 
its execution time in FinalizeOverride$Base.finalize().

>
>> 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?

I would expect "harder" GCs to trigger the same trouble. I would also 
expect the same (or similar) to happen if a lambda expression were used 
in the finalizer (instead of the string concatenation). But I did not do 
any experiments to confirm/deny this.

>> 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.

I would not want to do this as ISC will be (already is) the default in 
JDK 9 and we want to test that.

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

Yes, that is also a viable solution. But it is a workaround similar to 
Solution #1 that I've already tested/evaluated.

So, based on your feedback, I'd prefer to go with Solution #1:
http://cr.openjdk.java.net/~zmajo/8148940/webrev.00/

Thank you!

Best regards,


Zoltan

>
> -Aleksey
>