RFR: 8290025: Remove the Sweeper [v8]

[Erik Österlund]

On Thu, 11 Aug 2022 09:08:41 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > CodeCache exhaustion is something we can recover from.
> 
> So, Codecache OOMs are not observable? I see in the test log an OOM bubbling up:
> 
> ```
> OpenJDK 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled.
> OpenJDK 64-Bit Server VM warning: Try increasing the code cache size using -XX:ReservedCodeCacheSize=
> Thread Thread[#32,Thread-0,5,main] died with java.lang.VirtualMachineError: Out of space in CodeCache for adapters
> java.lang.VirtualMachineError: Out of space in CodeCache for adapters
> 	at java.base/java.time.zone.ZoneRules.readExternal(ZoneRules.java:483)
> 	at java.base/java.time.zone.Ser.readInternal(Ser.java:195)
> 	at java.base/java.time.zone.Ser.read(Ser.java:189)
> 	at java.base/java.time.zone.TzdbZoneRulesProvider.provideRules(TzdbZoneRulesProvider.java:135)
> 	at java.base/java.time.zone.ZoneRulesProvider.getRules(ZoneRulesProvider.java:236)
> 	at java.base/java.time.ZoneRegion.ofId(ZoneRegion.java:121)
> 	at java.base/java.time.ZoneId.of(ZoneId.java:410)
> 	at java.base/java.time.ZoneId.of(ZoneId.java:358)
> 	at java.base/java.time.ZoneId.of(ZoneId.java:314)
> 	at java.base/java.util.TimeZone.toZoneId0(TimeZone.java:581)
> 	at java.base/java.util.TimeZone.toZoneId(TimeZone.java:558)
> 	at java.base/java.util.TimeZone.toZoneId0(TimeZone.java:570)
> 	at java.base/java.util.TimeZone.toZoneId(TimeZone.java:558)
> 	at java.base/sun.util.cldr.CLDRTimeZoneNameProviderImpl.getDisplayNameArray(CLDRTimeZoneNameProviderImpl.java:94)
> 	at java.base/sun.util.locale.provider.TimeZoneNameProviderImpl.getDisplayName(TimeZoneNameProviderImpl.java:99)
> 	at java.base/sun.util.locale.provider.TimeZoneNameUtility$TimeZoneNameGetter.getName(TimeZoneNameUtility.java:271)
> 	at java.base/sun.util.locale.provider.TimeZoneNameUtility$TimeZoneNameGetter.getObject(TimeZoneNameUtility.java:229)
> 	at java.base/sun.util.locale.provider.TimeZoneNameUtility$TimeZoneNameGetter.getObject(TimeZoneNameUtility.java:215)
> 	at java.base/sun.util.locale.provider.LocaleServiceProviderPool.getLocalizedObjectImpl(LocaleServiceProviderPool.java:275)
> 	at java.base/sun.util.locale.provider.LocaleServiceProviderPool.getLocalizedObject(LocaleServiceProviderPool.java:236)
> 	at java.base/sun.util.locale.provider.TimeZoneNameUtility.retrieveDisplayNamesImpl(TimeZoneNameUtility.java:197)
> 	at java.base/sun.util.locale.provider.TimeZoneNameUtility.retrieveDisplayName(TimeZoneNameUtility.java:150)
> 	at java.base/java.util.TimeZone.getDisplayName(TimeZone.java:409)
> 	at java.base/java.util.TimeZone.getDisplayName(TimeZone.java:372)
> 	at com.crystaldecisions.reports.common.TimeZoneUtil.getTimeZoneString(TimeZoneUtil.java:165)
> ```
> 
>  > Could you share the -Xlog:codecache log information, so that we can see if the heuristics gave it its best shot, or if it was slacking, which would at least be a bug?
> 
> I can try, but I have not much time atm and no easy access to the failing test. I'll see what I can do.

Thank you for the log. This does look like a problem. In an earlier version I had a hook to provoke GCs from adapter allocations, but removed it because I thought they shouldn't share code cache with nmethods. But I think that assumption was incorrect. I'll look into it.

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

PR: https://git.openjdk.org/jdk/pull/9741