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

Roger Riggs Roger.Riggs at oracle.com
Thu May 30 16:40:58 UTC 2019


Hi Mandy,

Yes, the method returns and something may have happened.

But "or even" is a essential element, because there can be no guarantee that
any reclamation will ever happen, whether or not the method returns.
For example, EpilsonGC.

Thanks, Roger

On 05/30/2019 12:11 PM, Mandy Chung wrote:
>
> On 5/30/19 8:55 AM, Peter Levart wrote:
>> Yes Roger, this sounds better to me.
>>
>> Maybe even easier:
>>
>> "There is no guarantee that this effort will recycle any particular 
>> number of unused objects, reclaim any particular amount of space, or 
>> complete before the method returns (or ever)."
>>
>
> +1 and take out "(or ever)"
>
> I agree that this is simpler and clear that there is no guarantee of 
> GC completion when this method returns.
>
> Mandy
>
>> So, hypothetically, the effort triggered by System.gc() may never 
>> complete although the method will eventually return. Is this what was 
>> meant to be said?
>>
>> Is it necessary to have this (or ever) at the end? What's the purpose 
>> of it? If the method returns before the attempt completes, there's no 
>> way to track the attempt to its completion and doesn't matter if it 
>> eventually completes or not. The completion is already out of bounds 
>> for this method when it says: "there is not guarantee that the 
>> attempt completes before the method returns"...
>>
>> Regards, Peter
>>
>> On 5/30/19 4:42 PM, Roger Riggs wrote:
>>> Hi,
>>>
>>> Though I see your point about gc() eventually returns, the spec 
>>> typically does not
>>> guarantee than any method eventually returns.  That's more a quality 
>>> of service attribute.
>>> The sentence refers to the effort to reclaim space, not the method 
>>> call.
>>>
>>> Would it clarify the case to add a qualification to the end of the 
>>> sentence:
>>> " before the method returns or ever."
>>>
>>> As a whole:
>>>
>>>      * Runs the garbage collector in the Java Virtual Machine.
>>>      * <p>
>>>      * 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.
>>>      * When control returns from the method call, the Java Virtual 
>>> Machine
>>>      * has made a best effort to reclaim space from all unused objects.
>>>      * 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 <b>before the 
>>> method returns or ever</b>.
>>>
>>> Thanks, Roger
>>>
>>> On 05/30/2019 06:27 AM, Roman Kennke wrote:
>>>>>> Any other comments on:
>>>>>> "* Runs the garbage collector in the Java Virtual Machine.
>>>>>> * <p>
>>>>>> * 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.
>>>>> The following two statements...
>>>>>
>>>>> 1st:
>>>>>> * When control returns from the method call, the Java Virtual 
>>>>>> Machine
>>>>>> * has made a best effort to reclaim space from all discarded 
>>>>>> objects.
>>>>> 2nd:
>>>>>> * 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*.
>>>>>> "
>>>>> ...makes one think that it is OK (by the spec) for System.gc() to 
>>>>> never
>>>>> complete.
>>>>>
>>>>> Could it rather be specified that System.gc() eventually completes?
>>>>>
>>>> +1 I was thinking the same.
>>>>
>>>> I think the intention is that GC may never actually complete, but
>>>> System.gc() must be guaranteed to eventually return.
>>>>
>>>> Roman
>>>>
>>>
>>
>



More information about the core-libs-dev mailing list