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

[Stefan Johansson]

On 2019-11-13 00:15, Kim Barrett wrote:
>> 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.
> 

Thanks for the explanation.

>> 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.
In that case I think we should go with your proposed solution.

Thanks,
Stefan

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