Re: RFR: 8344882: (bf) Temporary direct buffers should not count against the upper limit on direct buffer memory [v3]

On Mon, 25 Nov 2024 19:25:47 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8344882: Remove DirectBuffer.temporary; rename JavaNioAccess temporary >> direct bu

Re: RFR: 8344882: (bf) Temporary direct buffers should not count against the upper limit on direct buffer memory [v4]

> Make the memory used by internal temporary direct buffers not count towards > the upper limit on direct buffer memory. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8344882: Remove vestigial import of Stable anno

Re: RFR: 8344882: (bf) Temporary direct buffers should not count against the upper limit on direct buffer memory [v3]

> Make the memory used by internal temporary direct buffers not count towards > the upper limit on direct buffer memory. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8344882: Remove DirectBuffer.temporary;

Re: RFR: 8344882: (bf) Temporary direct buffers should not count against the upper limit on direct buffer memory [v2]

On Mon, 25 Nov 2024 19:10:17 GMT, Brian Burkhalter wrote: >> src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 77: >> >>> 75: static final boolean UNALIGNED = Bits.unaligned(); >>> 76: >>> 77: private @Stable boolean tempora

Re: RFR: 8344882: (bf) Temporary direct buffers should not count against the upper limit on direct buffer memory [v2]

On Mon, 25 Nov 2024 19:04:21 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8344882: Do not create Cleaner for temporary buffers > > src/java.base/s

Re: RFR: 8344882: (bf) Temporary direct buffers should not count against the upper limit on direct buffer memory [v2]

> Make the memory used by internal temporary direct buffers not count towards > the upper limit on direct buffer memory. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8344882: Do not create Cleaner for temporary b

Re: RFR: 8344882: (bf) Temporary direct buffers should not count against the upper limit on direct buffer memory

On Sat, 23 Nov 2024 18:31:11 GMT, Alan Bateman wrote: > While you are there, can you also look into not creating a Cleaner for the > temporary direct buffers? They are explicitly deallocated when they can't be > returned to the TL cache or when the thread terminates (there is a hook in > threa

Re: RFR: 8344882: (bf) Temporary direct buffers should not count against the upper limit on direct buffer memory

On Mon, 25 Nov 2024 07:33:10 GMT, Per Minborg wrote: > Could we add some tests also? Do you have any suggestions? That the buffers do not affect the memory limit is implicitly tested by the tests associated with the issues linked in Jira. - PR Comment: https://git.openjdk.org/jdk/

Re: RFR: 8344882: (bf) Temporary direct buffers should not count against the upper limit on direct buffer memory

On Sat, 23 Nov 2024 01:03:25 GMT, ExE Boss wrote: >> Make the memory used by internal temporary direct buffers not count towards >> the upper limit on direct buffer memory. > > src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 77: > >> 75: static final boolean UNALIGNE

RFR: 8344882: (bf) Temporary direct buffers should not count against the upper limit on direct buffer memory

Make the memory used by internal temporary direct buffers not count towards the upper limit on direct buffer memory. - Commit messages: - 8344882: (bf) Temporary direct buffers should not count against the upper limit on direct buffer memory Changes: https://git.openjdk.org/jdk/pu

Re: RFR: 8344882: (bf) Temporary direct buffers should not count against the upper limit on direct buffer memory

On Fri, 22 Nov 2024 23:44:11 GMT, Brian Burkhalter wrote: > Make the memory used by internal temporary direct buffers not count towards > the upper limit on direct buffer memory. This change should also fix [JDK-8340728](https://bugs.openjdk.org/browse/JDK-8340728) and [JDK-8342849]

Re: RFR: 8344077: Remove security manager dependency in java.io [v4]

On Tue, 19 Nov 2024 16:53:27 GMT, Brian Burkhalter wrote: >> Expunge the use of the `SecurityManager`, `AccessController`, and the like >> from the `java.io` package. > > Brian Burkhalter has updated the pull request incrementally with one > additional commit si

Re: RFR: 8344446: Remove security manager dependency from module jdk.sctp [v2]

On Tue, 19 Nov 2024 16:33:49 GMT, Sean Mullan wrote: >> Brian Burkhalter has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 836: Address reviewer comments > > src/jdk.sctp/unix/classes/sun/nio/ch/sctp/

Integrated: 8344077: Remove security manager dependency in java.io

On Mon, 18 Nov 2024 20:28:49 GMT, Brian Burkhalter wrote: > Expunge the use of the `SecurityManager`, `AccessController`, and the like > from the `java.io` package. This pull request has now been integrated. Changeset: 81e43114 Author: Brian Burkhalter URL: https://git.openj

Integrated: 8344446: Remove security manager dependency from module jdk.sctp

On Tue, 19 Nov 2024 01:17:55 GMT, Brian Burkhalter wrote: > Expunge the use of the `SecurityManager`, `AccessController`, and the like > from the `jdk.sctp` module. This pull request has now been integrated. Changeset: f6f73ce7 Author: Brian Burkhalter URL: https://git.openj

Re: RFR: 8344446: Remove security manager dependency from module jdk.sctp [v2]

> Expunge the use of the `SecurityManager`, `AccessController`, and the like > from the `jdk.sctp` module. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 836: Address reviewer comments - Changes:

Re: RFR: 8344446: Remove security manager dependency from module jdk.sctp [v3]

> Expunge the use of the `SecurityManager`, `AccessController`, and the like > from the `jdk.sctp` module. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 836: Address more reviewer comments - Changes:

Re: RFR: 8344077: Remove security manager dependency in java.io [v3]

On Tue, 19 Nov 2024 07:56:55 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 836: Revert spurious inclusion of SCTP changes > > src/java.base/share/classe

Re: RFR: 8344077: Remove security manager dependency in java.io [v4]

> Expunge the use of the `SecurityManager`, `AccessController`, and the like > from the `java.io` package. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 836: Address reviewer comments - Changes:

Re: RFR: 8344446: Remove security manager dependency from module jdk.sctp [v2]

On Tue, 19 Nov 2024 13:57:01 GMT, Sean Mullan wrote: >> Brian Burkhalter has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 836: Address reviewer comments > > src/jdk.sctp/unix/classes/sun/nio/ch/sctp/

Re: RFR: 8344446: Remove security manager dependency from module jdk.sctp

On Tue, 19 Nov 2024 07:30:01 GMT, Alan Bateman wrote: > [...] so in theory there may be code that modifies the set [...] That is precisely why I did not use `Set.of(saa)`. - PR Review Comment: https://git.openjdk.org/jdk/pull/5#discussion_r1848645515

Re: RFR: 8344446: Remove security manager dependency from module jdk.sctp

On Tue, 19 Nov 2024 01:17:55 GMT, Brian Burkhalter wrote: > Expunge the use of the `SecurityManager`, `AccessController`, and the like > from the `jdk.sctp` module. On a Linux system with SCTP, the results for the `com/sun/nio/sctp` tests are the same with this patch applied as w

RFR: 8344446: Remove security manager dependency from module jdk.sctp

Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `jdk.sctp` module. - Commit messages: - 836: Remove security manager dependency from module jdk.sctp Changes: https://git.openjdk.org/jdk/pull/5/files Webrev: https://webrevs.openjdk.org/?

Re: RFR: 8344077: Remove security manager dependency in java.io [v3]

> Expunge the use of the `SecurityManager`, `AccessController`, and the like > from the `java.io` package. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 836: Revert spurious inclusion of SCTP c

Re: RFR: 8344077: Remove security manager dependency in java.io [v2]

On Mon, 18 Nov 2024 21:07:59 GMT, Brian Burkhalter wrote: >> Expunge the use of the `SecurityManager`, `AccessController`, and the like >> from the `java.io` package. > > Brian Burkhalter has updated the pull request incrementally with two > additional commits si

Re: RFR: 8344077: Remove security manager dependency in java.io [v2]

On Mon, 18 Nov 2024 20:46:24 GMT, Roger Riggs wrote: >> Brian Burkhalter has updated the pull request incrementally with two >> additional commits since the last revision: >> >> - 836: Address review comments >> - 836: Remove security manager dependenc

Re: RFR: 8344077: Remove security manager dependency in java.io [v2]

On Mon, 18 Nov 2024 20:56:59 GMT, Naoto Sato wrote: >> Brian Burkhalter has updated the pull request incrementally with two >> additional commits since the last revision: >> >> - 836: Address review comments >> - 836: Remove security manager dependenc

Re: RFR: 8344077: Remove security manager dependency in java.io [v2]

> Expunge the use of the `SecurityManager`, `AccessController`, and the like > from the `java.io` package. Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision: - 836: Address review comments - 836: Remove security m

Re: RFR: 8344077: Remove security manager dependency in java.io

On Mon, 18 Nov 2024 20:28:49 GMT, Brian Burkhalter wrote: > Expunge the use of the `SecurityManager`, `AccessController`, and the like > from the `java.io` package. Preliminary testing: the `jdk_io` tests pass on Linux and Windows. - PR Comment: https://git.openjdk.org/jd

RFR: 8344077: Remove security manager dependency in java.io

Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `java.io` package. - Commit messages: - 8344077: Remove security manager dependency in java.io Changes: https://git.openjdk.org/jdk/pull/22219/files Webrev: https://webrevs.openjdk.org/?repo=jdk&p

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v4]

On Mon, 28 Oct 2024 12:29:07 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security >> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The >> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the >> main ch

Re: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava

On Wed, 24 Jul 2024 19:11:42 GMT, Brian Burkhalter wrote: > This proposed change would move the native objects required for NIO file > interaction from the libnio native library to the libjava native library on > Linux, macOS, and Windows. This change passes CI tiers 1-5 jobs on all

RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava

This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows. - Commit messages: - 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava Cha

Re: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available [v6]

> Limit native memory allocation and move write loop from the native layer into > Java. This change should make the OOME reported in the issue much less likely. Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev exclud

Re: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available [v5]

> Limit native memory allocation and move write loop from the native layer into > Java. This change should make the OOME reported in the issue much less likely. Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev exclud

Re: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available [v4]

On Mon, 31 Jul 2023 17:02:15 GMT, Brian Burkhalter wrote: >> Limit native memory allocation and move write loop from the native layer >> into Java. This change should make the OOME reported in the issue much less >> likely. > > Brian Burkhalter has updated the pull re

Re: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available [v3]

On Sun, 30 Jul 2023 13:06:36 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 6478546: Move buffer clamping up to Java layer; correct read behavior to >> match

Re: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available [v4]

> Limit native memory allocation and move write loop from the native layer into > Java. This change should make the OOME reported in the issue much less likely. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 6478546: do

Re: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available [v2]

On Wed, 26 Jul 2023 09:29:18 GMT, Alan Bateman wrote: > I think this is close to what you want Modified as suggested in 9264975. The limit is increased to 1.5 Mb where it was in native malloc clamping. This appears to prevent any throughput degradation. - PR Comment: https://git.o

Re: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available [v3]

> Limit native memory allocation and move write loop from the native layer into > Java. This change should make the OOME reported in the issue much less likely. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 6478546

Re: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available [v2]

On Thu, 27 Jul 2023 16:35:05 GMT, Sergey Tsypanov wrote: >> I don't see how this is possible. The value of `buf` is either `stackBuf` or >> a value returned by `malloc()`. In any case, this code will be superseded. > > Then I guess we don't need this `if`-clause Then I think one gets an error i

Re: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available [v2]

On Thu, 27 Jul 2023 13:42:43 GMT, Sergey Tsypanov wrote: >> Brian Burkhalter has updated the pull request incrementally with three >> additional commits since the last revision: >> >> - 6478546: Decrease malloc limit to 1.5 MB >> - 6478546: Minor refactoring >

Re: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available [v2]

On Tue, 25 Jul 2023 23:50:07 GMT, Brian Burkhalter wrote: >> Limit native memory allocation and move write loop from the native layer >> into Java. This change should make the OOME reported in the issue much less >> likely. > > Brian Burkhalter has updated the pull re

Re: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available [v2]

On Tue, 25 Jul 2023 23:50:07 GMT, Brian Burkhalter wrote: >> Limit native memory allocation and move write loop from the native layer >> into Java. This change should make the OOME reported in the issue much less >> likely. > > Brian Burkhalter has updated the pull re

Re: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available [v2]

On Wed, 26 Jul 2023 15:58:15 GMT, Vyom Tewari wrote: >>> please reformat line 173 >> >> Why? > > "buf = (char*)malloc(len*sizeof(char));" --> "buf = (char*)malloc(len * > sizeof(char));" > "buf = (char*)malloc(len_sizeof(char));" --> "buf = (char_)malloc(len * > sizeof(char));" Both sides of

Re: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available [v2]

On Wed, 26 Jul 2023 05:31:57 GMT, Vyom Tewari wrote: > please reformat line 173 Why? - PR Review Comment: https://git.openjdk.org/jdk/pull/14981#discussion_r1275174632

Re: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available [v2]

On Wed, 26 Jul 2023 09:29:18 GMT, Alan Bateman wrote: > I think the main issue with this version is that it changes behavior of the > read methods to work like "read fully", I don't think we should do that. To me it looks more like `readNBytes`. - PR Comment: https://git.openjdk.o

Re: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available [v2]

On Wed, 26 Jul 2023 05:26:52 GMT, Vyom Tewari wrote: >> Brian Burkhalter has updated the pull request incrementally with three >> additional commits since the last revision: >> >> - 6478546: Decrease malloc limit to 1.5 MB >> - 6478546: Minor refactoring >

Re: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available [v2]

On Tue, 25 Jul 2023 05:51:26 GMT, Alan Bateman wrote: >> It's based on micro-benchmarks. Having the loops in Java reduces throughput >> but allocating memory using `malloc(len)` also reduces throughput as `len` >> gets larger and this threshold appears to balance the two. > >> It's based on mic

Re: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available [v2]

> Limit native memory allocation and move write loop from the native layer into > Java. This change should make the OOME reported in the issue much less likely. Brian Burkhalter has updated the pull request incrementally with three additional commits since the last revision: - 6

Re: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available [v2]

On Tue, 25 Jul 2023 02:05:52 GMT, Brian Burkhalter wrote: >> src/java.base/share/classes/java/io/FileOutputStream.java line 366: >> >>> 364: int n = writeBytes(b, off, len, append); >>> 365: if (n == -1) >>> 366:

Re: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available [v2]

On Mon, 24 Jul 2023 13:04:56 GMT, Alan Bateman wrote: >> src/java.base/share/native/libjava/io_util.c line 99: >> >>> 97: return 0; >>> 98: } else if (len > BUF_SIZE) { >>> 99: if (len > MAX_MALLOC_SIZE) >> >> Hi Brian if I am reading code correctly then with the current cod

Re: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available

On Mon, 24 Jul 2023 13:16:56 GMT, Alan Bateman wrote: >> Limit native memory allocation and move write loop from the native layer >> into Java. This change should make the OOME reported in the issue much less >> likely. > > src/java.base/share/native/libjava/io_util.c line 62: > >> 60: /* The

Re: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available

On Mon, 24 Jul 2023 12:59:55 GMT, Alan Bateman wrote: >> Limit native memory allocation and move write loop from the native layer >> into Java. This change should make the OOME reported in the issue much less >> likely. > > src/java.base/share/classes/java/io/FileOutputStream.java line 366: >

Re: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available

I think the idea is to treat an IOException thrown by any but the first invocation of readBytes() as equivalent to end-of-file such as described for InputStream::read(byte[],int,int) w

Re: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available

On Fri, 21 Jul 2023 22:40:00 GMT, Brian Burkhalter wrote: > Limit native memory allocation and move write loop from the native layer into > Java. This change should make the OOME reported in the issue much less likely. The cost of native memory allocation appears to degrade the through

RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available

Limit native memory allocation and move write loop from the native layer into Java. This change should make the OOME reported in the issue much less likely. - Commit messages: - 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available Changes: https:/

Integrated: 8308016: Use snippets in java.io package

On Fri, 12 May 2023 16:17:38 GMT, Brian Burkhalter wrote: > Replace `{@code ...}` patterns and the like with `{@snippet > lang=java : ...}`. This pull request has now been integrated. Changeset: 710453c6 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/

Re: RFR: 8308016: Use snippets in java.io package [v8]

On Mon, 22 May 2023 19:28:26 GMT, Roger Riggs wrote: > Thanks for the updates. Thanks for all the comments (and the approval). - PR Comment: https://git.openjdk.org/jdk/pull/13957#issuecomment-1557863535

Re: RFR: 8308016: Use snippets in java.io package [v7]

On Thu, 18 May 2023 18:23:53 GMT, Roger Riggs wrote: >> Brian Burkhalter has updated the pull request with a new target base due to >> a merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request contain

Re: RFR: 8308016: Use snippets in java.io package [v8]

> Replace `{@code ...}` patterns and the like with `{@snippet > lang=java : ...}`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8308016: Address reviewer comments since previous commit - Changes: - all:

Re: RFR: 8308016: Use snippets in java.io package [v2]

On Wed, 17 May 2023 15:50:13 GMT, Roger Riggs wrote: >> src/java.base/share/classes/java/io/RandomAccessFile.java line 904: >> >>> 902: * {@code b7}, and {@code b8,} where: >>> 903: * {@snippet lang=java : >>> 904: * 0 <= b1, b2, b3, b4, b5, b6, b7, b8 <= 255, >> >> Same:

Re: RFR: 8308016: Use snippets in java.io package [v7]

> Replace `{@code ...}` patterns and the like with `{@snippet > lang=java : ...}`. Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request co

Re: RFR: 8308016: Use snippets in java.io package [v6]

> Replace `{@code ...}` patterns and the like with `{@snippet > lang=java : ...}`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8308016: Reinstate @snippet for RandomAccessFile::readLong - Changes:

Re: RFR: 8308016: Use snippets in java.io package [v5]

> Replace `{@code ...}` patterns and the like with `{@snippet > lang=java : ...}`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8308016: Reduce linking in File::toPath snippet - Changes: - all:

Re: RFR: 8308016: Use snippets in java.io package [v4]

> Replace `{@code ...}` patterns and the like with `{@snippet > lang=java : ...}`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8308016: Fix link in snippet of File::toPath - Changes: - all:

Re: RFR: 8308016: Use snippets in java.io package [v3]

> Replace `{@code ...}` patterns and the like with `{@snippet > lang=java : ...}`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8308016: Address reviewer comments since previous commit - Changes: - all:

Re: RFR: 8308016: Use snippets in java.io package [v2]

> Replace `{@code ...}` patterns and the like with `{@snippet > lang=java : ...}`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8308016: Remove ellipses ("...") from snippets - Changes

Re: RFR: 8308016: Use snippets in java.io package

On Fri, 12 May 2023 17:31:32 GMT, Justin Lu wrote: >> Replace `{@code ...}` patterns and the like with `{@snippet >> lang=java : ...}`. > > src/java.base/share/classes/java/io/Console.java line 124: > >> 122: * if (con != null) { >> 123: * Scanner sc = new Scanner(

RFR: 8308016: Use snippets in java.io package

Replace `{@code ...}` patterns and the like with `{@snippet lang=java : ...>`. - Commit messages: - 8308016: Use snippets in java.io package Changes: https://git.openjdk.org/jdk/pull/13957/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13957&range=00 Issue: https://bugs.

Re: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v17]

On Tue, 29 Nov 2022 09:40:58 GMT, Per Minborg wrote: >> This PR proposes the introduction of **guarding** of the use of >> `DirectBuffer::address` within the JDK. With the introduction of the Foreign >> Function and Memory access, it is possible to derive Buffer instances that >> are backed by