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

Man Cao manc at google.com
Mon May 4 19:21:00 UTC 2020


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
>>
>


More information about the hotspot-compiler-dev mailing list