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

[Hans Boehm]

Thanks! I like the revision better.

I think ideally it should be possible to provide GC hooks that would allow
somewhat plentiful, but limited, resources like file descriptors to be
managed by the GC. Using References rather than finalizers should help, in
that you no longer have to wait for arbitrary finalizers when opening a
file, which was deadlock-prone.

Hans

On Wed, May 29, 2019 at 8:06 AM Roger Riggs <Roger.Riggs at oracle.com> wrote:

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