Re: deoptimization insanity

[Alen Vrečko]

I apologize for not following up on this sooner.

Andrei, spot on with the deoptimizations on JDWP agent. This JDWP deopt
insanity is what I am observing in my development environment.

Martijn, as I was chasing JDWP deopts I refactored the code a little bit
and since then not seeing any deoptimization issues on production hardware
when running performance tests.

Now I am seeing performance improvements consistent across all of the
performance tests. Looks very good. Before some performance tests performed
worse with the optimized code which confused me quite a lot.

A bit unsure which code change fixed it. But don't feel like spending more
time on this for now as the problem is fixed.

This has been an interesting learning experience.

Thank you
Alen

V V sob., 24. dec. 2022 ob 07:28 je oseba Martijn Verburg <
martijnverb...@gmail.com> napisala:

> Just saw this super late - sorry!  Which version of the JVM were you using
> and do you have a small reproducer?
>
> On Tue, 20 Dec 2022 at 07:56, Alen Vrečko  wrote:
>
>> Hello everyone.
>>
>> I am looking at a case where around 30% of CPU time is spent by the JVM
>> in deoptimizations (done the profile with async-profiler).
>>
>> I can locally reproduce the case. The log just explodes with
>> deoptimization messages. A few methods get deoptimized all the time. I
>> didn't stopwatch the deoptimization log count but it is in the order
>> 100s-1000s of them in a span of few seconds - consistently.
>>
>> Did JIT eliminate a branch by mistake? Then it figured it should be there?
>>
>> If there is a high number of method calls, could it trigger some dead
>> code elimination prematurely?
>>
>> Any ideas?
>>
>> Thank you
>> Alen
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "mechanical-sympathy" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to mechanical-sympathy+unsubscr...@googlegroups.com.
>> To view this discussion on the web, visit
>> https://groups.google.com/d/msgid/mechanical-sympathy/CACOdjgQaGqHN_uPU_EjowQ5_7jBfKE0a5kLeWSxScE9OTBdhRg%40mail.gmail.com
>> 
>> .
>>
> --
> Cheers, Martijn (Sent from Gmail Mobile)
>
> --
> You received this message because you are subscribed to the Google Groups
> "mechanical-sympathy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mechanical-sympathy+unsubscr...@googlegroups.com.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/mechanical-sympathy/CAP7YuASP_f264NwsrCc3WLNGOhCg3Kn6J2hH-8d_bM9FSamUng%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mechanical-sympathy+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/mechanical-sympathy/CACOdjgRWG-yna1axA1vR6_-ps-TJuddWP8Lz7EPwsqZqx028Jg%40mail.gmail.com.

Re: deoptimization insanity

[Martijn Verburg]

Just saw this super late - sorry!  Which version of the JVM were you using
and do you have a small reproducer?

On Tue, 20 Dec 2022 at 07:56, Alen Vrečko  wrote:

> Hello everyone.
>
> I am looking at a case where around 30% of CPU time is spent by the JVM in
> deoptimizations (done the profile with async-profiler).
>
> I can locally reproduce the case. The log just explodes with
> deoptimization messages. A few methods get deoptimized all the time. I
> didn't stopwatch the deoptimization log count but it is in the order
> 100s-1000s of them in a span of few seconds - consistently.
>
> Did JIT eliminate a branch by mistake? Then it figured it should be there?
>
> If there is a high number of method calls, could it trigger some dead code
> elimination prematurely?
>
> Any ideas?
>
> Thank you
> Alen
>
> --
> You received this message because you are subscribed to the Google Groups
> "mechanical-sympathy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mechanical-sympathy+unsubscr...@googlegroups.com.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/mechanical-sympathy/CACOdjgQaGqHN_uPU_EjowQ5_7jBfKE0a5kLeWSxScE9OTBdhRg%40mail.gmail.com
> 
> .
>
-- 
Cheers, Martijn (Sent from Gmail Mobile)

-- 
You received this message because you are subscribed to the Google Groups 
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mechanical-sympathy+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/mechanical-sympathy/CAP7YuASP_f264NwsrCc3WLNGOhCg3Kn6J2hH-8d_bM9FSamUng%40mail.gmail.com.

Re: deoptimization insanity

[Andrei Pangin]

Hi Alen,

If the same methods keep getting deoptimized again and again, this can be a 
JVM bug. I saw this happening several times:

 1. During static initialization: 
https://pangin.pro/posts/computation-in-static-initializer
 2. https://stackoverflow.com/a/66019887/3448419

If JVM runs with JDWP agent, deoptimization may also happen every time an 
exception is thrown.

API like MutableCallSite.setTarget can also provoke deoptimization.

So, there can be many reasons. Try to find the cause with 
-XX:+LogCompilation or with the help of async-profiler as shown in the 
above SO answer.

Regards,
Andrei

понедельник, 19 декабря 2022 г. в 18:56:30 UTC, alen@gmail.com: 

> Hello everyone.
>
> I am looking at a case where around 30% of CPU time is spent by the JVM in 
> deoptimizations (done the profile with async-profiler).
>
> I can locally reproduce the case. The log just explodes with 
> deoptimization messages. A few methods get deoptimized all the time. I 
> didn't stopwatch the deoptimization log count but it is in the order 
> 100s-1000s of them in a span of few seconds - consistently.
>
> Did JIT eliminate a branch by mistake? Then it figured it should be there?
>
> If there is a high number of method calls, could it trigger some dead code 
> elimination prematurely?
>
> Any ideas?
>
> Thank you
> Alen
>

-- 
You received this message because you are subscribed to the Google Groups 
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mechanical-sympathy+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/mechanical-sympathy/9da388a3-17b9-4561-bcb1-91776e0bfc74n%40googlegroups.com.

deoptimization insanity

[Alen Vrečko]

Hello everyone.

I am looking at a case where around 30% of CPU time is spent by the JVM in
deoptimizations (done the profile with async-profiler).

I can locally reproduce the case. The log just explodes with deoptimization
messages. A few methods get deoptimized all the time. I didn't stopwatch
the deoptimization log count but it is in the order 100s-1000s of them in a
span of few seconds - consistently.

Did JIT eliminate a branch by mistake? Then it figured it should be there?

If there is a high number of method calls, could it trigger some dead code
elimination prematurely?

Any ideas?

Thank you
Alen

-- 
You received this message because you are subscribed to the Google Groups 
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mechanical-sympathy+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/mechanical-sympathy/CACOdjgQaGqHN_uPU_EjowQ5_7jBfKE0a5kLeWSxScE9OTBdhRg%40mail.gmail.com.