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/>
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.
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.
-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.wardhan...@oracle.com <mailto:harsha.wardhan...@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.wardhan...@oracle.com
<mailto:harsha.wardhan...@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/
<http://cr.openjdk.java.net/%7Ehb/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
