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

[Erik Osterlund]

Hi David,

Wow, this flag sure has overstayed its welcome. Thanks for the review!

/Erik

> On 16 Aug 2019, at 02:55, David Holmes <david.holmes at oracle.com> wrote:
> 
> 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