> This is a dependent PR containing a cleanup of the so called *heap sessions*. 
> Heap sessions are used in two cases:
> 
> * when a buffer segment is created, to keep the original buffer instance 
> reachable
> * when a loader symbol lookup is created, to keep the classloader instance 
> reachable
> 
> Spinning new sessions in these cases seems unnecessary, and inconsistent with 
> what we do for segments backed by on-heap arrays, whose session is set to the 
> global session. In that case, it's up to the segment to keep the underlying 
> array reachable. I think that's a better model.
> 
> This patch adds the ability to attach Object references to native and mapped 
> memory segments, so that we can attach loader/byte buffer instances to these 
> segments, keeping them alive. This means that, in these cases we can go back 
> to just use the global memory session, like we do for array segments.
> 
> This simplifies the implementation, makes the documentation more consistent, 
> and also simplifies the user model, as it removes a concept (of heap session) 
> that is not really documented anywhere. In fact, the javadoc for 
> MemorySegment::ofBuffer claims, (wrongly!) that the session of the resulting 
> segment is the global session - but that's not the case.

Maurizio Cimadamore has updated the pull request with a new target base due to 
a merge or a rebase. The pull request now contains eight commits:

 - Initial push
 - Revert implicit vs. heap session changes
 - Unify heap vs. implicit scopes
 - Merge branch 'master' into memory_session_cleanup
 - Fix issue in Direct-X-Buffer template
 - Simplify and drop the state class
 - Add missing files
 - Initial push

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

Changes: https://git.openjdk.org/jdk19/pull/39/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=39&range=01
  Stats: 577 lines in 28 files changed: 53 ins; 125 del; 399 mod
  Patch: https://git.openjdk.org/jdk19/pull/39.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/39/head:pull/39

PR: https://git.openjdk.org/jdk19/pull/39

Reply via email to