On Mon, 21 Nov 2022 17:00:52 GMT, Maurizio Cimadamore <mcimadam...@openjdk.org> wrote:
>>> Although this looks much simpler and concise, it means "a new object is >>> created for each invocation" >> >> My comment was actually to see if DirectBuffer could extend AutoCloseable so >> that the acquire returns "this" for the non-session case. Doing the >> equivalent for the session case might leak into MemorySessionImpl >> implementing DirectBuffer which you probably don't want to do. If >> NOP_CLOSE.close can do the Reference.reachabilityFence(this) then it would >> at least improve some of the use-sites. > >> > Although this looks much simpler and concise, it means "a new object is >> > created for each invocation" >> >> My comment was actually to see if DirectBuffer could extend AutoCloseable so >> that the acquire returns "this" for the non-session case. Doing the >> equivalent for the session case might leak into MemorySessionImpl >> implementing DirectBuffer which you probably don't want to do. If >> NOP_CLOSE.close can do the Reference.reachabilityFence(this) then it would >> at least improve some of the use-sites. > > Not sure that is simpler. ByteBuffer <: AutoCloseable doesn't seem to make > sense to me. I'm also not sure how much object allocation (all this stuff > will become value types) should be the driving factor in these code paths. Right, I didn't mean BB <: AC but to see if we avoid needing to wrap it because this PR is touching several low level and performance critical code paths. For the faraway places then having the close do a Reference.reachabilityFence(this) should avoid the surprise that the buffer has to kept alive even though it appears that the try-with-resources is doing it already. ------------- PR: https://git.openjdk.org/jdk/pull/11260
