RFR: 8217348: assert(thread->is_Java_thread()) failed: just checking

[Jean Christophe Beyler]

Hi Daniil,

Looks good to me to :-)

FWIW, it seems like:
opto/library_call.cpp:    if (!C->too_many_traps(trap_method, trap_bci,
Deoptimization::Reason_intrinsic) &
          !C->too_many_traps(trap_method, trap_bci,
Deoptimization::Reason_null_check)) {

could also be fixed, but perhaps that is a different webrev.

Thanks!
Jc

On Fri, Jun 14, 2019 at 5:14 PM Alex Menkov <alexey.menkov at oracle.com>
wrote:

> +1
>
> --alex
>
> On 06/14/2019 17:01, serguei.spitsyn at oracle.com wrote:
> > Hi Daniil,
> >
> > Great discovery!
> > The fix looks good to me.
> >
> > Thanks,
> > Serguei
> >
> >
> > On 6/14/19 4:56 PM, Daniil Titov wrote:
> >> Please review the change that fixes an intermittent issue.
> >>
> >> The problem here is that a bitwise-AND (&) operator was used in the
> >> condition instead of a logical AND operator (&&).
> >> As a result pending_thread->is_thread_fully_suspended() is always
> >> evaluated regardless of the value of at_safepoint variable.
> >>
> >> Webrev: http://cr.openjdk.java.net/~dtitov/8217348/webrev.01/
> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217348
> >>
> >> Thanks!
> >> --Daniil
> >>
> >>
> >
>


-- 

Thanks,
Jc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20190614/7d8b20a2/attachment-0001.html>