On Mon, 4 Nov 2024 12:42:41 GMT, Aleksey Shipilev <[email protected]> wrote:
> > I am not baking in the specifics of the grouping that "happens" to be what > > I see today on whatever tests I run on Windows. > > Which might be completely different than some other cases or platforms. > > The similar argument can be applied to the expectation that non-foldable VHs > do not affect performance, right? Since we are dealing with a performance > regression already, it would be nice not to introduce another one. > In a previous fix I spent ages trying to see any improvement in perf of this over literally 100 of thousands of invocations Never saw it. What I did see there and the issue here is start up costs. And the startup cost is probably thousands of times more visible than any runtime cost here. This code could be slower at runtime and it would still be way less important than the startup cost. > I think holder classes are a fair compromise here until Stable Values arrive. > Look at this variant (untested): > [8337505-v1.patch](https://github.com/user-attachments/files/17618209/8337505-v1.patch). > This is also arguably more straight-forward than lazy initialization with > runtime null-checks and extra (mutable) fields, I think. In the case where they are all needed then this fix surely makes it worse. The worse case was Linux and SCAICS, now we have to initialise a class for each one as well. I can't see how this helps start up. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21748#issuecomment-2455587124
