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

[Maurizio Cimadamore]

On 07/07/2023 20:26, Jorn Vernee wrote:
> I think the greater issue is that e.g. having a separate version of 
> MS::copy that doesn't do any checks would create two versions of the 
> same API, one checked and one unchecked, for seemingly very little 
> gain. This doesn't seem worth it. 

I agree with this assessment. The FFM API tries quite hard to provided a 
view of the world that is "pay as you go" from a safety perspective. By 
default, there's lots of safety checks:

* confinement
* alignment
* liveness
* bounds

But these checks can be detuned (as discussed in this thread) with the 
use of some restricted methods. I think the proposed technique for 
having a single unbounded "ALL" segment to mimic unsafe access should 
eventually work out ok, the numbers you get are already "close enough" 
(although I realize it might be annoying for them not to be "exactly the 
same as with Unsafe").

AFAIK, all the work that went into hoisting bounds check with long 
induction variables should already have taken care of eliminating bounds 
checks in the vast majority of cases. I'm skeptical that the difference 
you see is caused by a bound check (especially one against 
Long.MAX_VALUE, effectively a constant). I think a more detailed 
benchmark is required here in order to assess exactly where the 
performance is being lost, as there can be several factors.

I'm very very skeptical that the restricted method check is playing a 
part in all of this. We have taken extra care to make the check fast, 
and to cache the results of such check in a VM @Stable field, which is 
treated as a true constant. We have benchmark to show that no peak 
performance is lost due to the restricted method check.

But, to come back to the beginning of this email, splitting the API in 
two, a checked API and an unchecked API is not the way forward. We 
actually used to have such splitting in previous iterations of the API, 
and we quickly discovered that the splitting was "invasive" that is, 
once the core API had two methods for doing the same thing, all API 
clients were now facing a choice as to whether using the checked or 
unchcecked methods (and maybe provide multiple entry points as well). 
This led to a lot of pain when building things on top of FFM API. I 
think unifying both safe and unsafe use cases under the same API 
umbrella is one of the main moves of the FFM API. The results you get 
are already in the right ballbark, IMHO we should see if there's a way 
to make them even better, but w/o compromising the design principles of 
the FFM API.

Cheers
Maurizio