RFR : JDK-8154166 - java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java fails with RuntimeException
Harsha Wardhana B
harsha.wardhana.b at oracle.com
Mon May 2 05:23:54 UTC 2016
Hi Jaroslav,
Thanks for pointing out the @required tag. It's a nifty Jtreg feature.
Below is webrev for updated patch.
http://cr.openjdk.java.net/~hb/8154166/webrev.02/
<http://cr.openjdk.java.net/%7Ehb/8154166/webrev.02/>
-Harsha
On Friday 29 April 2016 02:15 PM, Jaroslav Bachorik wrote:
>
>
> On Fri, Apr 29, 2016 at 6:20 AM, Harsha Wardhana B
> <harsha.wardhana.b at oracle.com> wrote:
>
> Hi Jaroslav,
>
> I am not sure how @required tag works. I searched code base and it
> is not used in any file. Also, the documentation on Jtreg page is
> sparse.
>
> Could you paste an example as to how to use it?
>
>
> Please, take a look
> at jdk/test/java/lang/management/MemoryMXBean/LowMemoryTest.java -
> actually, it is '@requires' tag.
>
>
> Also, I would still think that repeated gc via weak-reference is
> right and defensive approach. So I would like to leave that in
> place unless it is causing any side-effects.
>
>
> No objections here. It does not break anything and makes the test
> intentions clearer.
>
> -JB-
>
>
> Thanks
> Harsha
>
>
> On Tuesday 26 April 2016 04:05 PM, Jaroslav Bachorik wrote:
>>
>>
>> On Mon, Apr 25, 2016 at 9:27 AM, Harsha Wardhana B
>> <harsha.wardhana.b at oracle.com
>> <mailto:harsha.wardhana.b at oracle.com>> wrote:
>>
>> Hi,
>>
>> Please review below patch to disable concurrent GC option.
>> http://cr.openjdk.java.net/~hb/8154166/webrev.01/
>> <http://cr.openjdk.java.net/%7Ehb/8154166/webrev.01/>
>>
>>
>> I'm sorry to be a PITA, but why it is not possible to use the
>> @require tag?
>>
>>
>>
>> Jaroslav,
>>
>> According to Javadoc of Runtime.gc(),
>>
>> https://docs.oracle.com/javase/8/docs/api/java/lang/Runtime.html#gc--
>>
>> The call will only make it's best effort to do a GC and
>> provides no guarantee that a given object can be collected
>> even if GC runs.
>> It does not say that Runtime.gc() call will block till entire
>> GC cycle is finished and hence we cannot be making that
>> assumption.
>>
>>
>> I know, I had the same discussion a while ago when fixing some
>> other tests failing when run with allowed concurrent explicit GC
>> and I was pointed to the fact that all the known implementation
>> actually do wait until the complete GC cycle is over before
>> returning. Otherwise all those tests relying on some memory
>> having been reclaimed or some counters having been increased
>> would have to be considered random.
>>
>>
>> Hence it is required that we encapsulate the target object in
>> WeakReference and repeatedly call GC till weakRef returns null.
>> Granted that we will have a small window when weakRef returns
>> null and the target object is not removed from memory. But I
>> see no way how to fix that problem.
>>
>>
>> Exactly. The only guarantee for all the GC related metrics having
>> been updated before proceeding with the test is being able to run
>> the explicit GC in blocking manner. Otherwise the tests are not
>> really deterministic and can intermittently fail.
>>
>> -JB-
>>
>>
>> -Harsha
>>
>>
>> On Sunday 24 April 2016 03:17 PM, Jaroslav Bachorik wrote:
>>> The reproducer would be very time sensitive as with the
>>> provided 'ExplicitGCInvokesConcurrent' it will run GC
>>> concurrently with the invoker. Otherwise, in the current
>>> implementation, calling Runtime.gc() would guarantee the GC
>>> cycle has finished before that method returns.
>>>
>>> The WeakReference javadoc
>>> (https://docs.oracle.com/javase/7/docs/api/java/lang/ref/WeakReference.html)
>>> is only stating that the referenced object will be made
>>> finalizable at the same time as the reference is cleared. As
>>> a consequence a cleared reference might not always mean that
>>> the heap usage has been changed (unless a particular GC
>>> implementation makes some additional guarantees).
>>>
>>> I know we were stabilizing a bunch of related tests relying
>>> on GC doing its work before checking for some
>>> post-conditions and the only way to make the tests reliable
>>> was to forbid running those tests with
>>> '-XX:+ExplicitGCInvokesConcurrent'.
>>>
>>> -JB-
>>>
>>> On Sat, Apr 23, 2016 at 12:15 PM, Harsha Wardhana B
>>> <harsha.wardhana.b at oracle.com> wrote:
>>>
>>> Hello,
>>>
>>> The issue was not reproducible with or without,
>>>
>>> "-XX:+ExplicitGCInvokesConcurrent"
>>>
>>> Flag. The patch ensures that GC happens before we start
>>> measuring memory. Without the patch, GC might or might
>>> not happen.
>>>
>>> -Harsha
>>>
>>>
>>> On Friday 22 April 2016 07:58 PM, Jaroslav Bachorik wrote:
>>>> Hi,
>>>>
>>>> On Fri, Apr 22, 2016 at 9:10 AM, Harsha Wardhana B
>>>> <harsha.wardhana.b at oracle.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Please review the below simple fix for issue,
>>>>
>>>> issue :
>>>> https://bugs.openjdk.java.net/browse/JDK-8154166
>>>> webrev :
>>>> http://cr.openjdk.java.net/~hb/8154166/webrev.00/
>>>>
>>>>
>>>> Shouldn't this test rather declare the conditions when
>>>> it is supposed to work? According to the issue this was
>>>> caused by introducing the
>>>> "-XX:+ExplicitGCInvokesConcurrent" which makes it very
>>>> tricky to make any assumptions about the GC process.
>>>>
>>>> See eg.
>>>> jdk/tests/java/lang/management/MemoryMXBean/LowMemoryTest.java
>>>> for enabling the test only for allowed configurations.
>>>>
>>>> Cheers,
>>>>
>>>> -JB-
>>>>
>>>>
>>>>
>>>> -Harsha
>>>>
>>>>
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160502/062ae067/attachment-0001.html>
More information about the serviceability-dev
mailing list