Withdrawn: 8317819: Scope should reflect lifetime of underying resource (mainline)

Jorn Vernee jvernee at openjdk.org
Fri Oct 13 13:50:02 UTC 2023


On Tue, 10 Oct 2023 17:17:00 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Port of: https://github.com/openjdk/panama-foreign/pull/898
> 
> Original PR body:
> 
>> 
>> This patch addresses some issues with `MemorySegment.Scope::equals`. More specifically, when two segments are created from the same array/buffer, their underlying scope should be equal, but currently it is not, which is confusing.
>> 
>> This patch addesses that by adding a new subclass of `GlobalSession` (`HeapSession`) whose `equals`/`hashcode` methods are defined in terms of the heap reference it wraps. Note that the reference is deduped on construction - that is, we always try to find the "bottom" refrence that we should try to keep alive with the session, and we use that for comparisons (which avoid issues when comparing buffer slices and views).
>> 
>> As part of the changes, this patch also adds more javadoc on `MemorySegment.Scope` to document how equality works. And, this patch also makes all zero-length memory segments associate with the same "native" scope. This is a scope that is always alive, but is not the global scope (not to confuse with segments created by the global arena). While what the implementation does today is technically correct (a new fresh scope is returned with each new ZLMS), it seems also overkill given that the scope associated with segments originated outside Java code is not very interesting - if users really care about lifetime of such segments they should override the scope with `MemorySegment::reinterpret`. This leads to some changes in the javadoc of other methods where I replaced `fresh scope that is always alive` with just `scope that is always alive`, to avoid suggesting that a new scope should be created each time.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/16126


More information about the core-libs-dev mailing list