Request for Review: 7094995: test/java/util/zip/ZipFile/ causes continuous GC in agentvm mode

Chris Hegarty chris.hegarty at
Wed Nov 23 14:13:25 UTC 2011

On 11/23/11 01:29 PM, Neil Richards wrote:
> On Tue, 2011-11-22 at 19:09 +0000, Chris Hegarty wrote:
>> On 11/22/11 06:56 PM, Alan Bateman wrote:
>>> On 22/11/2011 17:22, Neil Richards wrote:
>>>> :
>>>> Can you tell me, when jtreg decides to fire an interrupt at a test, has
>>>> it already concluded that the test has "failed" (or, at least, not
>>>> "passed") ?
>>> With othervm (the default) then each test is run in its own VM so the
>>> process termination will ensure that everything is cleaned up. With
>>> agentvm mode then tests are run sequentially in the same VM (or a pool
>>> VMs). In that case then jtreg gives each test its own ThreadGroup. When
>>> the test completes then it checks the thread group for any non-daemon
>>> threads and interrupts them with the hope that they will terminate in a
>>> timely manner. If they don't terminate within a short time then the test
>>> fails with an error. With the original test then the thread was a daemon
>>> thread which is why we didn't notice a problem. With your updated test
>>> then the thread terminates before the test completes so there shouldn't
>>> be a problem. Chris's concern comes in in the event that the test
>>> doesn't complete (it hangs for example), in which case jtreg will
>>> attempt to interrupt the remaining threads before giving up. In agent VM
>>> mode this just means the agent (process) will terminate and it spins up
>>> a new agent process to replace it.
>> Right, and I was proposing that any threads created by the test be
>> interruptible and be able to terminate in a timely manner.
>> I don't think in this case throwing from the catch block of IE is
>> necessary, just that the thread terminate quickly. It is not relevant to
>> the testing of the original bug. Make sense?
>> -Chris.
> Thanks for all your guidance on this.
> I've uploaded another webrev [1], incorporating David's suggested ARM
> correction (thanks) and Chris' suggested handling of
> InterruptedException (together a System.out.println(), for clarity).

Looks fine to me.


> Regards, Neil
> [1]

More information about the core-libs-dev mailing list