RFR: 8293336: AOT-linking of invokedynamic for lambda expression and string concat [v5]

[John Rose]

On 15 Oct 2024, at 12:35, Ioi Lam wrote:

> On Tue, 15 Oct 2024 19:08:20 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:
>
>>> 597:
>>> 598:     /** Number of CPUS, to place bounds on some sizings */
>>> 599:     static @Stable int NCPU;
>>
>> I would prefer to not mark this `@Stable` at this time as it would have different assembly and runtime values and instead add a followup RFE to investigate adding it in later.
>
> We have been archiving `ConcurrentHashMap` objects for many JDK releases (to support archiving of modules) and `NCPU` would change between CDS archive dump time and program run time. We have not seen any problems, so I think it's safe to use the `@Stable` annotation.

Is it necessary to get constant folding from NCPU?  I guess a division is slow, but it does not seem to be a hot path, at all.  The division is not in any loop.  If there is no performance issue, it’s perhaps more honest just to use a mutable variable.  I guess what we need here is something that means “stable except for AOT activity”.

Normally, making something stable means it should be used according to the contract of stable, which is only one second value, and no third, after the initial default.

There is a sub-rosa contract, as well, which is that we can add third values if they do not conflict with the second values.  But we have to convince ourselves that is safe, because the second and third values can (in general) co-exist as folded constants in JIT code.

We currently refuse to fold stable constants in AOT code (and there’s no AOT code in this JEP anyway) so the AOT-only stable binding is tolerable.

Here’s what I think we should do later (not in this PR):  Amend the contract for @Stable that the value is allowed to be different during the AOT assembly phase than later.  Working out the details will require some discussion:  Should the AOT-AP reset stable values that need new bindings?  (Probably…?)  Or should there be a warmup method that takes full responsibility for managing the stable value during the production run?

For now, I’m content to make this guy NCPU either stable or not.  But it is clear that, along with other details, we will need an amended story for the life-cycle of a stable variable that includes the AOT assembly phase.

Eventually, something like this may well play into a similar Leyden story for user-visible stables.  Those would be declared by an object API, not the private annotation we use in the JDK.  User-visible stable objects are likely to be wrappers for JDK-level stable-annotated fields, and that’s how the turtles tend to stack up.

No PR change requested here!