RFR: 8337505: Footprint and startup regressions up to 20% in GUI apps
Aleksey Shipilev
shade at openjdk.org
Thu Nov 7 10:54:43 UTC 2024
On Mon, 28 Oct 2024 21:26:38 GMT, Phil Race <prr at openjdk.org> wrote:
> https://bugs.openjdk.org/browse/JDK-8338677 already improved things for this so that's good.
>
> This fix adds to it lazy initialisation of VarHandles in StrikeCache at the cost of some extra code.
> Since these VarHandles get used more or less immediately on Linux this new fix won't further improve matters there
> But should help on Mac where they aren't usually needed at startup
> And Windows is somewhere in between.
> > Is `@Stable` usable here, if so you can annotate all these with it and there should be no runtime concern.
>
> I don't know and don't see much precedent. Outside of java.base, only the incubating vector module uses @stable. But I don't think it would help. The problem is the cost of initialisation itself. Later VM optimisations don't matter.
What I think @merykitty means here is taking your lazy-initialization patch, and then stamp `@Stable` over the affected `static` fields. This way, we get lazy initialization for good startup, _and_ also we get the ability to constant-fold the `VarHandles` once they are initialized.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21748#issuecomment-2461918103
More information about the client-libs-dev
mailing list