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 <[email protected]
<mailto:[email protected]>> wrote:
+1
--alex
On 06/14/2019 17:01, [email protected]
<mailto:[email protected]> 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
