RFR: JDK-8293114: JVM should trim the native heap [v10]

Thomas Stuefe stuefe at openjdk.org
Fri Jul 14 20:03:26 UTC 2023


On Fri, 14 Jul 2023 08:45:04 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>>> Realized that in production, we would like to see why trimmer might be late. I think this would look even better: [trimnative-shipilev-2.patch](https://github.com/openjdk/jdk/files/12043977/trimnative-shipilev-2.patch)
>> 
>> I thought about this too, but you don't really want to know if it was suspended for every wait interval, but for every trim interval. In other words, you want to know how many trims had been moved up because a safepoint had been happening, and how many trims had been skipped due to pause. Getting these infos is harder than just increasing a counter. Is it worth the added complexity?
>> 
>> I'll think something up.
>
>> > Realized that in production, we would like to see why trimmer might be late. I think this would look even better: [trimnative-shipilev-2.patch](https://github.com/openjdk/jdk/files/12043977/trimnative-shipilev-2.patch)
>> 
>> I thought about this too, but you don't really want to know if it was suspended for every wait interval, but for every trim interval. In other words, you want to know how many trims had been moved up because a safepoint had been happening, and how many trims had been skipped due to pause. 
> 
> Well, yes. Isn't that what my patch did?

Thanks a lot @shipilev!

Fixed the last nits, and fixed an issue where the "this platform does not support..." text was not displayed with warning level and hence not visible without Xlog. Plus, test for that.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14781#issuecomment-1636349888


More information about the serviceability-dev mailing list