JDK-8218166: [Graal] com/sun/jdi/SimulResumerTest.java failure

Gary Adams gary.adams at oracle.com
Wed Mar 13 11:49:07 UTC 2019


There is a caution in the disableCollection() docs that it should be used
sparingly, because the behavior between debug and non-debug runs
could differ. I actually prefer leaving the test in it's racy configuration.
The collection of the object is not central to what the test is actually
trying to observe. Ignoring the exception if it does occur allows the
test to complete the work it intends to cover.

On 3/12/19, 2:22 PM, Daniil Titov wrote:
> Hi Gary,
>
> The fix looks good. However, since there are only two references (debuggeeThread1 and debuggeeThread2) the test checks, an alternative to catching and ignoring ObjectCollectedException  could be just calling disableCollection() on these two thread references when a breakpoint handle is called (lines 130 and 135).
>
> Thanks!
>
> Best regards,
> Daniil
>
>
>
> On 3/12/19, 11:05 AM, "serviceability-dev on behalf of Gary Adams"<serviceability-dev-bounces at openjdk.java.net on behalf of gary.adams at oracle.com>  wrote:
>
>      Still need 2 more reviewers ...
>
>      On 3/7/19, 9:45 AM, Daniel D. Daugherty wrote:
>      >  Gary,
>      >
>      >  Since the 'graal' label was recently removed, I also removed "[Graal]"
>      >  from the bug synopsis. Please make sure you update your commit mesg.
>      >
>      >
>      >  On 3/7/19 8:19 AM, Gary Adams wrote:
>      >>  While trying to reproduce the timeout reported in
>      >>    JDK-8000669: com/sun/jdi/SimulResumerTest.java times out
>      >>
>      >>  I was unable to reproduce the timeout failure, but I did occasionally
>      >>  see the ObjectCollectedException. The output from the test is very
>      >>  verbose
>      >>  and may be the source of the occasional timeout. I'd like to close
>      >>  JDK-8000669
>      >>  as cannot reproduce and if it shows up again look into limiting the
>      >>  amount
>      >>  of non-essential output from the test.
>      >>
>      >>  This is a racy test to begin with and it already is ignoring exceptions
>      >>  due to unexpected thread states. Adding the ignore for
>      >>  ObjectCollectedException
>      >>  allows the test to complete without errors.
>      >>
>      >>  The graal label was recently removed. We should also remove it from
>      >>  the summary.
>      >>
>      >>  Proposed changeset:
>      >>
>      >>
>      >>  diff --git a/test/jdk/com/sun/jdi/SimulResumerTest.java
>      >>  b/test/jdk/com/sun/jdi/SimulResumerTest.java
>      >>  --- a/test/jdk/com/sun/jdi/SimulResumerTest.java
>      >>  +++ b/test/jdk/com/sun/jdi/SimulResumerTest.java
>      >>  @@ -1,5 +1,5 @@
>      >>   /*
>      >>  - * Copyright (c) 2008, 2015, Oracle and/or its affiliates. All
>      >>  rights reserved.
>      >>  + * Copyright (c) 2008, 2019, Oracle and/or its affiliates. All
>      >>  rights reserved.
>      >>    * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>      >>    *
>      >>    * This code is free software; you can redistribute it and/or modify it
>      >>  @@ -211,6 +211,8 @@
>      >>
>      >>               } catch (IncompatibleThreadStateException ee) {
>      >>                   // ignore
>      >>  +            } catch (ObjectCollectedException ee) {
>      >>  +                // ignore
>      >>               } catch (VMDisconnectedException ee) {
>      >>                   // This is how we stop.  The debuggee runs to
>      >>  completion
>      >>                   // and we get this exception.
>      >
>      >  There should be some sort of comment explaining why it is okay to ignore
>      >  the ObjectCollectedException. When the IncompatibleThreadStateException
>      >  was ignored, there should have been a comment added for that also.
>      >
>      >  Dan
>      >
>
>
>
>
>



More information about the serviceability-dev mailing list