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

[Hans Boehm]

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.

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.

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.


On Tue, May 28, 2019 at 1:55 PM Roger Riggs <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
> > 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.
> >
>
>