RFR: 8229345: Memory leak due to vtable stubs not being shared on SPARC

[Doerr, Martin]

Hi Erik,

nice change! I like it.

We already switched this flag on in SAP JVM on SPARC.
We're also convinced that "improves performance markedly for mtrt and compress" is no longer true on recent hardware.

Best regards,
Martin


> -----Original Message-----
> From: hotspot-dev <hotspot-dev-bounces at openjdk.java.net> On Behalf Of
> Erik Österlund
> Sent: Donnerstag, 15. August 2019 17:01
> To: hotspot-dev developers <hotspot-dev at openjdk.java.net>
> Subject: RFR: 8229345: Memory leak due to vtable stubs not being shared on
> SPARC
> 
> Hi,
> 
> The code cache can be occupied by vtable stubs on SPARC. One of the
> potential scenarios are continuous creation and unloading of class loaders.
> It causes excessive allocation and deallocation of nmethods for classes
> in said class loaders. If call patterns are megamorphic, those nmethods
> will allocate corresponding vtable stubs for megamorphic inline cache
> transitions. While the nmethods are recycled, their corresponding vtable
> stubs are never released.
> 
> Normally, it is not a problem that vtable stubs are not cleaned up
> during code cache unloading, because they are shared. There is one for
> each VM-level signature, and the number of signatures does not grow out
> of control.
> 
> However, on SPARC, the vtable stubs are not shared, and are instead
> continuously allocated, causing a nasty leak that is considerable.
> 
> SPARC is the only architecture where we do not share vtable stubs. The
> switch for opting in to vtable stub sharing is the developer flag
> ShareVtableStubs. The description of the flag makes it seem like turning
> sharing off is a sweet optimization you can use if your branch
> prediction is bad and you would rather use a bit more memory, without
> mentioning that you get a nasty memory leak. It's mentioned that two
> benchmarks ran faster with sharing turned off. The flag was introduced
> longer ago than I can track back (Niagara?!), and since then SPARC
> machines have *much* better branch prediction. This flag doesn't seem to
> make sense today.
> 
> The obvious solution is to remove the flag and have all architectures
> consistently use vtable stub sharing, and hence not leak memory
> uncontrollably. So that is what I propose to do about this.
> 
> Webrev:
> http://cr.openjdk.java.net/~eosterlund/8229345/webrev.00/
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8229345
> 
> Thanks,
> /Erik