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

[Nils Eliasson]

Hi Man,

Why do you expect code cache usage would increase a lot? The sweeper 
still wakes up regularly and cleans the code cache. The code path fixed 
is just about sweeping extra aggressively under some circumstances. Some 
nmethod might live a little longer, but they will still be cleaned.

Without your bugfix the sweeper will be notified for every new 
allocation in the codecache as soon as code cache usages has gone beyond 
10%. That could in the worst case be one sweep for every allocation.

One number you could add to your benchmark numbers is the number of 
nmethods reclaimed and code cache usage. I expect both to remain the same.

Best regards,
Nils



On 2020-05-04 21:21, Man Cao wrote:
> 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
>>>