RFR 8220238 : Enhancing j.l.Runtime/System::gc specification with an explicit 'no guarantee' statement

[Roger Riggs]

Hi Hans,

The language is hard to construct, in part because of the innovations in 
gc technology that have
resulted such a wide range of behaviors and timing.

I'll restore the sentence "When control returns"... but I don't think it 
carries any
definite requirement on an implementation. It is benign since 'best 
effort' is undefined
and depends on the unspecified intentions of the implementation(s).

On 05/28/2019 07:36 PM, Hans Boehm wrote:
> I agree with Aleksey's concern.
>
> AFAICT, these methods are usually used for one of two purposes:
>
> 1) Let the implementation know that this would be a good time to 
> garbage collect because the application is likely to remain idle for a 
> while.
"suggests that"...
>
> 2) Ensure that as many references as possible have been enqueued, and 
> traditionally, with runFinalization(), to ensure that as many 
> finalizers as possible have been run. If I run out of some resource 
> managed this way, I may want to try this before giving up.
The behaviors of reference types, including finalization, are described 
elsewhere
and are just as dependent on the particular gc implementation as making 
memory available for reuse.
>
> I don't think this API was ever that well suited to either of these. 
> For (1), I really want a call that says "garbage collect if we're n% 
> of the way to triggering the next GC". For (2), I really want a call 
> that does precisely that but, so long as we still have finalizers, 
> with a better specification of what happens if I hold a lock needed by 
> a finalizer.
>
> I'm a bit concerned that with the watered-down spec, (2) becomes 
> completely unimplementable. (1) was already kind of unimplementable, 
> since it's hard to avoid triggering way too many GCs in a row. In my 
> mind, this raises the question of whether these are actually still useful.
Timely recovery of resources based on gc side effects is a poor 
mechanism (except perhaps for memory), because gc behavior is so varied.

I didn't see this change as watering down the spec but to make it clear 
that it already does not make any guarantees.

Thanks, Roger
>
>
> On Tue, May 28, 2019 at 1:55 PM Roger Riggs <Roger.Riggs at oracle.com 
> <mailto:Roger.Riggs at oracle.com>> wrote:
>
>     Hi Aleksey,
>
>     The </p> is always optional (in html5).
>
>     The issue with the "when control returns" and "best effort"
>     sentence is
>     that is implies that something has been done
>     and that is not necessarily true.  At best, it could say is that the
>     implementation may have done something or done nothing
>     and anything in between.
>
>     Suggestions welcome.
>
>     Thanks, Roger
>
>
>
>     On 05/28/2019 02:06 PM, Aleksey Shipilev wrote:
>     > On 5/28/19 7:58 PM, Roger Riggs wrote:
>     >> Please review a change to the javadoc of Runtime.gc() and
>     System.gc() to clarify
>     >> that invoking these methods does not guarantee any specific
>     result or timeliness
>     >> of completion.
>     >>
>     >> The revised text is:
>     >>
>     >>        * Runs the garbage collector in the Java Virtual Machine.
>     >>        *
>     >>        * Calling this method suggests that the Java Virtual Machine
>     >>        * expend effort toward recycling unused objects in order to
>     >>        * make the memory they currently occupy available for reuse
>     >>        * by the Java Virtual Machine.
>     >>        * There is no guarantee that this effort will recycle
>     any particular
>     >>        * number of unused objects, reclaim any particular
>     amount of space,
>     >>        * or complete at any particular time, if at all.
>     >>
>     >> Issue:
>     >> https://bugs.openjdk.java.net/browse/JDK-8220238
>     >>
>     >> CSR:
>     >> https://bugs.openjdk.java.net/browse/JDK-8224760
>     >>
>     >> Webrev:
>     >> http://cr.openjdk.java.net/~rriggs/webrev-gc-8220238/index.html
>     <http://cr.openjdk.java.net/%7Erriggs/webrev-gc-8220238/index.html>
>     > Thank you.
>     >
>     > It feels like <p/> is missing between paragraphs?
>     >
>     > Also, I don't think it is sensible to drop the blocking behavior
>     ("When control returns...") -- I
>     > think some programs enjoy that property, and certainly many GCs
>     have special tests to enforce this
>     > property, even if GC is fully concurrent.
>     >
>