RFR 8068260: java/io/Serializable/clearHandleTable/ClearHandleTable.java timed out
Stuart Marks
stuart.marks at oracle.com
Wed Mar 4 17:56:14 UTC 2015
Hi Chris, Roger,
Just as a background, the loop with System.gc() and sleep() was arrived at via
review comments between Eric Wang and David Holmes. See this thread:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-June/010592.html
which continued here:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-July/010741.html
We had decided that the loop can be an "infinite" loop, since the test framework
will timeout the test after a while (two minutes by default). As David said, if
the weak refs haven't been cleared in that time, there's clearly a problem. In
some ways I prefer having an "infinite" loop, since that time will be scaled by
the timeout factor, whereas TIMES will not be.
I think the point about having a gc/sleep in a loop is that, depending on which
GC is in use, it might take more than one cycle to clear the reference(s). In
addition, GC is asynchronous, so the caller really does have to sleep each time.
For checking the list of weak refs, you might be able to do something like
refs.removeIf(ref -> ref.get() == null)
if we don't care about backporting this any earlier than Java 8.
Finally, I think it would be a good idea to have a test library for this kind of
weak reference clearing ... eventually. I think it would be good to build up
several different use cases and then refactor the commonality into a library
that we know they can all use. We're already building up a few examples:
1) this test
2) java/lang/annotation/loaderLeak/Main.java (mentioned above)
3) java/rmi/transport/pinLastArguments/PinLastArguments.java
(mentioned in the bug report)
I'm not sure whether we want to do this now (i.e., part of this changeset) though.
s'marks
On 3/4/15 8:15 AM, Chris Hegarty wrote:
> On 04/03/15 15:58, Roger Riggs wrote:
>> Hi Chris,
>>
>> ok, though if System.gc is good enough it would not need a loop and
>> timeout logic.
>
> Ah ok, so some common library function taking a Predicate, or similar. I got you
> now.
>
>> It would be interesting to know if it ever needs to go through the loop
>> more than once.
>
> In my testing it only ever goes through once.
>
>> Maybe some indication of that can be added to the test output.
>
> I added some output ( updated the webrev in-place). The test should be quiet
> unless there is a problem.
>
> -Chris.
>
>>
>> Thanks, Roger
>>
>>
>> On 3/4/2015 10:57 AM, Chris Hegarty wrote:
>>> On 04/03/15 15:17, Roger Riggs wrote:
>>>> Hi Chris,
>>>>
>>>> looks fine.
>>>
>>> Thanks Roger.
>>>
>>>> Do you suppose the test library should have a function that takes a set
>>>> of (Weak)Refs
>>>> and does whatever it takes to clear them (or timeout).
>>>
>>> Well, the problem is: What is "whatever it takes"? The changes in this
>>> test are only "less bad", and typically take less time to execute. I'd
>>> like to keep an eye on the test after this change is pushed to see if
>>> there are any future issues with it.
>>>
>>>> Perhaps even a public API in Runtime...
>>>
>>> I think, System.gc is good enough, but maybe there is scope for
>>> something else here.
>>>
>>> -Chris.
>>>
>>>> Roger
>>>>
>>>> On 3/4/2015 9:59 AM, Chris Hegarty wrote:
>>>>> This is a small, test only, review request to fix an intermittently
>>>>> failing test.
>>>>>
>>>>> It replaces a "bad" technique, heap exhaustion, with the "less bad"
>>>>> technique of calling System.gc, potentially multiple times, to clear
>>>>> weak references. With this change the test runs much quicker, and has
>>>>> not failed in several thousands of runs on a local machine.
>>>>>
>>>>> http://cr.openjdk.java.net/~chegar/8068260/webrev.00/webrev/
>>>>>
>>>>> -Chris.
>>>>
>>
More information about the core-libs-dev
mailing list