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 <[email protected]
<mailto:[email protected]>> 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.
>
