FFM performance tweaks

[Brian S O'Neill]

I'm running some experiments by accessing "makeRawSegmentViewVarHandle" 
directly, to see if a simpler VarHandle is better. I'm not seeing much 
improvement over the existing VarHandle trick, but I need to tweak my 
test more to improve consistency between test runs.

One thing that strikes me as odd is the use of a MemorySegment in a 
context in which I really want an "unbounded" memory segment, which 
cannot be represented by the MemorySegment interface.

The VarHandle trick involves dropping the MemorySegment parameter, thus 
making it effectively unbounded. If a ValueLayout.unboundedVarHandle() 
method existed, then it could apply an equivalent transform, and it 
could do so in a way that's more direct and more likely to be inlined.

Such a feature doesn't address memory copies, which only work against 
MemorySegments. Lately, I've not been comparing the performance of these 
copy operations vs. the unsafe equivalents.


On 2024-11-19 09:28 AM, Maurizio Cimadamore wrote:
> 
> On 19/11/2024 16:52, Brian S O'Neill wrote:
>> Using the VarHandle transform, it's 1.6% slower than the baseline 
>> (unsafe), and when using an unbounded MemorySegment, it's 4.9% slower 
>> than the baseline.
> 
> Ok, so I'd say that this tweak didn't help much - results seem more or 
> less on par with what you had before. And, also on par with what 
> reported here:
> 
> https://github.com/openjdk/jdk/pull/21810#issuecomment-2450511880
> 
> My intuition is that, in most cases, the liveness check is always 
> hoisted away if access occurs in some kind of loop -- and so its cost is 
> amortized.
> 
> Liveness check becomes more important when considering a single-shot 
> access (or very small loops):
> 
> https://github.com/openjdk/jdk/pull/21810#issue-2627210220
> 
> But that's probably not a fair represention of your code base, which is 
> probably why you are not seeing a lot of upshot.
> 
> Maurizio
> 
> 
> 
>>
>> I've changed my testing methodology a bit, to average out the 
>> variability. So these numbers cannot be compared against any previous 
>> results I reported.
>>
>> There's a few more experiments I want to try out.
>>
>>
>> On 2024-11-19 08:23 AM, Maurizio Cimadamore wrote:
>>> Thanks Brian
>>>
>>> On 19/11/2024 15:35, Brian S O'Neill wrote:
>>>> I've already been running some tests against build 24 to see what 
>>>> affect pull 21810 has. Tests using the transformed VarHandle 
>>>> technique didn't show much improvement. 
>>> I believe that's to be expected.
>>>> I just started running tests which access the (effectively) 
>>>> unbounded MemorySegment and will report back in about an hour.
>>>
>>> That would be the more interesting one, yes. That said, I'm kind of 
>>> prepared not to see the gains in the synthetic benchmark to translate 
>>> in bigger real world gains (but I'd be very happy to be wrong here :) ).
>>>
>>> Maurizio
>>>
>>>>
>>>> On 2024-11-19 06:42 AM, Maurizio Cimadamore wrote:
>>>>> Hi,
>>>>> some performance tweaks have landed in the JDK 24 early access 
>>>>> build (build 24):
>>>>>
>>>>> https://urldefense.com/v3/__https://jdk.java.net/24/__;!! 
>>>>> ACWV5N9M2RV99hQ!PM1KvkakQk5XJ7ClEecm-f7zp5BUeBS- 
>>>>> oZ2mkmzcJ9qMOwzwRlkdbz7hBc3IO-1Nvd4uTQw13xtekdKgJZueUQ$
>>>>> They are:
>>>>>
>>>>> https://git.openjdk.org/jdk/pull/21764
>>>>> https://git.openjdk.org/jdk/pull/21810
>>>>>
>>>>> The former contains some optimizations for `MemorySegment
>>>>>
>>>>> ` which should improve scalarization - see [1]. The second contains 
>>>>> an improvement to the way we perform the liveness check, which 
>>>>> should make such check provably redundant for segments backed by 
>>>>> the global arena. This should improve the performance of 
>>>>> workarounds using an “everything” segment to access off-heap memory 
>>>>> with minimal impact from bound checks [2].
>>>>>
>>>>> As JDK 24 is moving closer to rampdown phase [3], it would be great 
>>>>> to give such changes a try and report back.
>>>>>
>>>>> Cheers
>>>>> Maurizio
>>>>>
>>>>> [1] - https://mail.openjdk.org/pipermail/panama-dev/2024- 
>>>>> October/020702.html
>>>>> [2] - https://mail.openjdk.org/pipermail/panama-dev/2024- 
>>>>> October/020736.html
>>>>> [3] - https://openjdk.org/projects/jdk/24/
>>>>>
>>>>> ​
>>>>>
>>>>> ​
>>>>
>>