RFR: 8291065: Creating a VarHandle for a static field triggers class initialization [v5]

[Chen Liang]

On Wed, 7 Jun 2023 00:10:59 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>>> I believe instead of changing the guards we can change the implementation of the static methods on the concrete static VHs to call `asDirect()` (lets also add `@ForceInline` on `asDirect`), since `linkToStatic` will pass the args to the static method described by the member name (since the lazy and direct VH handles share the same var form).
>>> 
>>> That has the nice effect of pushing the complexity closer to where it is needed. Its subtle but i think can be explained. Thereby we can reduce the memory footprint for subsequent access modes. Perhaps we can even "zero" out the MH cache on initialization?
>> 
>> Is this aimed at decreasing long-term invocation cost or the initial invocation cost? FYI long-term invocation is already efficient enough; if this is for initial invocation, which can potentially bypass costly MH construction, I recommend creating an alternative method to `asDirect` for the purpose to be called and casted by X-VarHandle implementations.
>
>> Is this aimed at decreasing long-term invocation cost or the initial invocation cost? FYI long-term invocation is already efficient enough; if this is for initial invocation, which can potentially bypass costly MH construction, I recommend creating an alternative method to `asDirect` for the purpose to be called and casted by X-VarHandle implementations.
> 
> It aims to reduce the cost of getting to peak performance (the work that C2 has to perform) and reduce the overall memory footprint of such VHs (as long as the user does not explicitly request MHs from them). Assuming of course that the peak performance is good!
> 
> For this pattern i not sure we need to create another method returning the target that effectively does the same as `asDirect`, and instead it may come down to better naming and documentation of the concepts.
> 
> There is already a tight coupling between the `LazyInitializingVarHandle` and its target via the sharing of the var forms. Renaming `asDirect` to `target` might do it, and we refine a what a direct handle is to mean the guards just pass along the handle that is given to it, otherwise we use a (lazily created) method handle to its target. Thereby a VH implementation free to switch between indirect and direct and is further free to deal with any implementation specific indirection in its own implementation.

@PaulSandoz Thank you for your suggestion! It might be harder to measure the time to get to peak performance, but at least for the initial invocation, the lazy VH is almost no different from the eager VH now. The old overhead was mostly from LambdaForm spinning, same for the lazy DMH overhead. Is this what you've envisioned?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13821#issuecomment-1579742481