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

[serguei.spitsyn at oracle.com]

On 6/14/19 5:44 PM, Jean Christophe Beyler wrote:
> 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.

Thank you for the catch, Jc!
I've filed a separate bug:
   https://bugs.openjdk.java.net/browse/JDK-8226198
    use of & instead of && in LibraryCallKit::arraycopy_restore_alloc_state

Thanks,
Serguei

>
> Thanks!
> Jc
>
> On Fri, Jun 14, 2019 at 5:14 PM Alex Menkov <alexey.menkov at oracle.com 
> <mailto:alexey.menkov at oracle.com>> wrote:
>
>     +1
>
>     --alex
>
>     On 06/14/2019 17:01, serguei.spitsyn at oracle.com
>     <mailto: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/
>     <http://cr.openjdk.java.net/%7Edtitov/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/837d445c/attachment.html>