RFR(XXS): 8244278: Excessive code cache flushes and sweeps

[Laurent Bourgès]

Thanks Man for sharing your early benchmark results.

This one-liner fix seems giving nice throughtput improvements.
Using 40mb code cache looks quite small compared to default values (256mb
?).
Could you run 1 quick experiment with default code cache settings to see if
there is no regression in the main use case ?

PS: I am not a reviewer, but I am very implied in java jit performance.

Cheers,
Laurent

Le lun. 4 mai 2020 à 21:21, Man Cao <manc at google.com> a écrit :

> Hi,
>
> Thanks for the review!
> Yes, the code change is trivial, but runtime behavior change is
> considerable.
> In particular, throughput and CPU usage could improve, but code cache
> usage could increase a lot. In our experience, the improvement in
> throughput and CPU is well worth the code cache increase.
>
> I have attached some benchmarking results in JBS. They are based on JDK11.
> We have not rolled out this fix to our production JDK11 yet, as I'd like
> to confirm that this large change in runtime behavior is OK with the
> OpenJDK community.
> We are happy to share some performance numbers from production workload
> once we have them.
>
> -Man
>
>
> On Mon, May 4, 2020 at 4:11 AM Laurent Bourgès <bourges.laurent at gmail.com>
> wrote:
>
>> Hi,
>>
>> Do you have performance results to justify your assumption "could
>> significantly improve performance" ?
>>
>> Please share numbers in the jbs bug
>>
>> Laurent
>>
>> Le sam. 2 mai 2020 à 07:35, Man Cao <manc at google.com> a écrit :
>>
>>> Hi all,
>>>
>>> Can I have reviews for this one-line change that fixes a bug and could
>>> significantly improve performance?
>>> Webrev: https://cr.openjdk.java.net/~manc/8244278/webrev.00/
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8244278
>>>
>>> It passes tier-1 tests locally, as well as
>>> "vm/mlvm/meth/stress/compiler/deoptimize" (for the original JDK-8046809).
>>>
>>> -Man
>>>
>>