RFR: 8232588: G1 concurrent System.gc can return early or late

[Kim Barrett]

> On Nov 12, 2019, at 5:03 PM, Stefan Johansson <stefan.johansson at oracle.com> wrote:
> 
>> 12 nov. 2019 kl. 19:23 skrev Kim Barrett <kim.barrett at oracle.com>:
>> I thought about adding a utility for this kind of thing, since this isn’t the only occurrence.
>> But I ran into problems for which I don’t currently have a solution (fixed by C++14).
> 
> Would a generic utility be implemented differently? To me this only works because we know that the values never differ much (1 or 2 I think), but I might be missing something.

One of the constraints on using such a utility is that one “knows” the difference “never" gets “too large”.
Another place doing this sort of thing is GlobalCounter.  I think I’ve seen others, but couldn’t find any
just now.

A generic utility should be templated over the integer type, and would use std::numeric_limits<T>::max().
But that doesn’t currently work on Solaris, where that expression produces a reference to a library
that we don’t link to.  C++14 (or maybe C++11) made that expression constexpr, so *must* be known
at compile-time.

> Another approach would be to reset those values in a well defined manner to ensure they never wrap. From what I can see we only use them to ensure this state machine is doing what we expect, or is it possible that we can end up in a situation where we never could reset the values? 

It’s true that the current values of those counters never differ by more than 1 or 2.  But the values
captured by some thread that gets stalled might differ by more.  And I don’t see a good reset
place because of the values captured by various threads.

>> New webrevs:
>> full: https://cr.openjdk.java.net/~kbarrett/8232588/open.02/
>> incr: https://cr.openjdk.java.net/~kbarrett/8232588/open.02.inc/
> 
> Looks good,
> Stefan

Thanks.