[External] : Re: MemorySegment.ofAddress(...).reinterpret(...)

[Jorn Vernee]

If you're using constant memory layouts when using get/set, then there 
should be no difference in terms of performance. Using get/set would be 
preferable since it shares the access var handle between all users that 
are using the same memory layout.

Jorn

On 07/07/2023 18:18, Brian S O'Neill wrote:
> I also just realized something. If I use memorySegmentViewVarHandle 
> for the get/set methods, would this boost performance?
>
> On 2023-07-07 09:11 AM, Brian S O'Neill wrote:
>> When I obtain a MethodHandle, a module access check is performed. 
>> When I invoke it, no check is performed, and a static final reference 
>> to a it gets fully optimized.
>>
>> It seems to me that if I were to obtain access to the copy method 
>> (and the get/set methods) via a MethodHandle, then the restricted 
>> method check only needs to be performed once.
>>
>> Granted, this approach is a little bit ugly from an API perspective, 
>> but MethodHandles are already a key component of the ffm API. A 
>> MethodHandle transformation could also be performed automatically by 
>> the compiler (at some level), but that's probably going too far.
>>
>> On 2023-07-07 08:55 AM, Jorn Vernee wrote:
>>> Well, the implementation of a restricted method doesn't know whether 
>>> the caller's module has already been checked :) That is tracked on a 
>>> per-module basis, but either way we have to walk the stack to get 
>>> the caller's module.
>>>
>>> Jorn
>>>
>>> On 07/07/2023 17:51, Brian S O'Neill wrote:
>>>> Is the restricted method check performed every single time? Why? 
>>>> The restriction applies to the module, so it only really needs to 
>>>> be checked once.
>>>>
>>>> On 2023-07-07 08:32 AM, Jorn Vernee wrote:
>>>>
>>>>> We can't just drop an array bounds check, even if we were to make 
>>>>> the method restricted. (Besides, a restricted method needs to 
>>>>> check if the caller has native access, which adds its own overhead)
>>>>>