VarHandle optimization

[Maurizio Cimadamore]

(CC'ing Claes)

Good subject...

On 31/10/2024 18:45, Brian S O'Neill wrote:
> New subject... (was Unsafe vs MemorySegments / Bounds checking...)
>
> One thing that surprises me is that VarHandles don't have some sort of 
> "compile" step which can reduce to a smaller form. As far as I can 
> tell, before JDK 22, VarHandles didn't support any kind of transforms, 
> and so they were always tiny and inlinable.

While Java 22 added support for VH adapters, it is not the case that 
_all_ var handles were "small". For instance a var handle accessing a 
byte buffer is not too different from one accessing a memory segment.

But of course adaptation makes things worse (in pretty much the same 
ways in which MH adaptation -- upon which VH adaptation is built -- also 
make things worse).

>
> Whether I act upon a VarHandle directly or indirectly (via a 
> MemorySegment method), the full chain of transforms gets expanded and 
> processed again and again at each call site. My assumption was that 
> there would be some intermediate optimized form which could be re-used.
>
> Is it even possible to support some sort of compile/optimize/reduce 
> step with VarHandles? Manually or automatically?

The target MH that is used for the var handle operation is inlined into 
the caller, pretty much from scratch. I believe method handles 
(internally) supports "customization" , which allows a method handle to 
be "recompiled" into its own (possibly simpler) lambda form. Method 
handle specialization is avoided, where possible, to limit the number of 
classfiles being generated dynamically. It's a delicate balance (and one 
I'm not entirely familiar with, so I'll leave others to comment on this).

(that said, I agree with the general point that var handle warmup is 
quite bad -- and I do believe this will be tackled in some shape or form 
by Leyden).

Maurizio