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

[David Holmes]

Hi Erik,

Probably not needed but looks good to me too. Another flag bytes the dust.

FYI this is a "day one" setting going back to 2000. Though the reasoning 
for it probably predates that and comes from the Solaris Production VM 
(aka Exact VM). :)

Cheers,
David

On 16/08/2019 1:01 am, Erik Österlund wrote:
> 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