RFR: 8341649: Regressions with large metaspace apps after 8338526
Coleen Phillimore
coleenp at openjdk.org
Tue Dec 3 15:26:39 UTC 2024
On Mon, 2 Dec 2024 17:41:30 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:
> Putting generated LambdaForm$MH and $DMH in non-class space seems to cause excess dependency checking for c2 compiled code and shows a performance regression in a new JMH performance test for MethodHandles (to be checked in at a later time).
>
> When I made this abstract rather than final, I thought there were a many generated classes but I haven't found in testing more than a small percentage. For example, Dacapo xalan there are 43/1000 classes that are these generated classes. In Eric's new JMH test, it was more like 51/681. Special casing "AllStatic" classes to go in non-class metaspace is a bit too risky at this time. If it does become a problem with limited class metaspace, we can create another attribute to use.
>
> Tested with tier1-4 and the JMH test. Thanks Eric Caspole for finding this and all the testing.
I did have a version of this patch that allocated InstanceKlass in non-class metaspace if all methods were static but I thought it was too risky. But maybe you cannot allocate an object if there's no `<init>` method. That might be a future patch if we decide that there are too many of these generated classes filling up limited class metaspace.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/22493#issuecomment-2514868050
More information about the core-libs-dev
mailing list