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