Re: RFR: 8255822: Zero: improve build-time JVMTI handling [v3]
> Current Zero interpreter has the optimization for JVMTI support. It > recognizes that JVMTI is disabled most of the time, and that JVMTI checks in > the interpreter code slows it down considerably. (I measured it myself when > working on this patch: removing this optimization yields about 20% hit in > build times). > > Current optimization works as follows. At build time, an XSLT transform is > performed on `bytecodeInterpreter.cpp`, yielding > `bytecodeInterpreterWithChecks.cpp`. In that new compilation unit, `VM_JVMTI` > macro is defined, and a new entry point -- `BytecodeInterpreter::withChecks` > -- is defined. Then, both compilation units are compiled. In one of them, > `JVMTI` hooks are stripped out. In another, they persist. Then, callers have > to choose which entry point to use. > > I believe this can be rewritten to use C++ templates instead of XLST and > defines dance. This also allows to clean up JVMTI checks a bit. > > Additional testing: > - [x] Linux x86_64 Zero fastdebug build with `-jvmti` > - [x] Linux x86_64 Zero fastdebug/release build times are not regressing Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Simplify a few JVMTI_ENABLED blocks - Merge branch 'master' into JDK-8255822-zero-jvmti-rework - Fix build error - Merge branch 'master' into JDK-8255822-zero-jvmti-rework - Revert one dubious change - 8255822: Zero: improve build-time JVMTI handling Summary: use C++ templates instead of XSLT transforms - Changes: https://git.openjdk.java.net/jdk/pull/1061/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=1061=02 Stats: 188 lines in 6 files changed: 5 ins; 128 del; 55 mod Patch: https://git.openjdk.java.net/jdk/pull/1061.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1061/head:pull/1061 PR: https://git.openjdk.java.net/jdk/pull/1061
Re: RFR: 8256048: Incomplete gitignore setting for netbeans project [v3]
On Mon, 9 Nov 2020 23:31:09 GMT, Jie Fu wrote: >> Hi all, >> >> The gitignore setting for netbeans project seems to be incomplete. >> Only nbproject/private/ [1] is ignored. >> >> But there are also other files under nbproject/, which should be ignored too. >> >> $ tree -L 1 nbproject/ >> nbproject/ >> ├── configurations.xml >> ├── private >> └── project.xml >> >> >> It would be better to fix it. >> >> Thanks. >> Best regards, >> Jie >> >> >> [1] https://github.com/openjdk/jdk/blob/master/.gitignore#L5 > > Jie Fu has updated the pull request incrementally with one additional commit > since the last revision: > > Updated v3 Marked as reviewed by erikj (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/1122
Re: RFR: 8256048: Incomplete gitignore setting for netbeans project [v3]
On Mon, 9 Nov 2020 18:03:31 GMT, Erik Joelsson wrote: >> You misunderstand me. Adding the following line is fine and will make git >> ignore any nbproject dir in the root of the repository, which is what I >> assume you want: >> >> >> But removing the following existing line is not, as this matches any >> potential private part of already existing nbproject directories: >> nbproject/private/ > > Adding the below will make git ignore a bunch of already existing nbproject > files. > nbproject/configurations.xml > nbproject/project.xml Got it. Thanks @erikj79 for your kind explanation. Updated. - PR: https://git.openjdk.java.net/jdk/pull/1122
Re: RFR: 8256048: Incomplete gitignore setting for netbeans project [v3]
> Hi all, > > The gitignore setting for netbeans project seems to be incomplete. > Only nbproject/private/ [1] is ignored. > > But there are also other files under nbproject/, which should be ignored too. > > $ tree -L 1 nbproject/ > nbproject/ > ├── configurations.xml > ├── private > └── project.xml > > > It would be better to fix it. > > Thanks. > Best regards, > Jie > > > [1] https://github.com/openjdk/jdk/blob/master/.gitignore#L5 Jie Fu has updated the pull request incrementally with one additional commit since the last revision: Updated v3 - Changes: - all: https://git.openjdk.java.net/jdk/pull/1122/files - new: https://git.openjdk.java.net/jdk/pull/1122/files/f48474eb..06d0c766 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=1122=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1122=01-02 Stats: 3 lines in 1 file changed: 1 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1122.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1122/head:pull/1122 PR: https://git.openjdk.java.net/jdk/pull/1122
Re: RFR: 8212879: Make JVMTI TagMap table concurrent [v6]
On Thu, 5 Nov 2020 12:42:40 GMT, Coleen Phillimore wrote: >> Thank you for the update, Coleen! >> I leave it for you to decide to refactor the gc_notification or not. >> Thanks, >> Serguei > > Thanks @sspitsyn . I'm going to leave the gc_notification code because > structurally the two sides of the if statement are different and it's not a > long function. Thank you for reviewing the change. This change also passes tier 7,8 testing. - PR: https://git.openjdk.java.net/jdk/pull/967
Re: RFR: 8256048: Incomplete gitignore setting for netbeans project [v2]
On Mon, 9 Nov 2020 15:25:28 GMT, Jie Fu wrote: >> .gitignore line 5: >> >>> 3: /.idea/ >>> 4: /.vscode/ >>> 5: /nbproject/ >> >> I believe the existing nbproject/private/ is meant to catch any private >> files created by someone opening any of the various nbproject directories >> that exist in the source base, so it should probably stay. Adding an ignore >> for any top level nbproject directory in addition to that should be ok. > > Thanks @erikj79 for your review. > Updated. > > Any comments? > Thanks. You misunderstand me. Adding the following line is fine and will make git ignore any nbproject dir in the root of the repository, which is what I assume you want: But removing the following existing line is not, as this matches any potential private part of already existing nbproject directories: nbproject/private/ - PR: https://git.openjdk.java.net/jdk/pull/1122
Re: RFR: 8256048: Incomplete gitignore setting for netbeans project [v2]
On Mon, 9 Nov 2020 18:02:32 GMT, Erik Joelsson wrote: >> Thanks @erikj79 for your review. >> Updated. >> >> Any comments? >> Thanks. > > You misunderstand me. Adding the following line is fine and will make git > ignore any nbproject dir in the root of the repository, which is what I > assume you want: > > > But removing the following existing line is not, as this matches any > potential private part of already existing nbproject directories: > nbproject/private/ Adding the below will make git ignore a bunch of already existing nbproject files. nbproject/configurations.xml nbproject/project.xml - PR: https://git.openjdk.java.net/jdk/pull/1122
Re: RFR: 8254162: Implementation of Foreign-Memory Access API (Third Incubator) [v26]
> This patch contains the changes associated with the third incubation round of > the foreign memory access API incubation (see JEP 393 [1]). This iteration > focus on improving the usability of the API in 3 main ways: > > * first, by providing a way to obtain truly *shared* segments, which can be > accessed and closed concurrently from multiple threads > * second, by providing a way to register a memory segment against a > `Cleaner`, so as to have some (optional) guarantee that the memory will be > deallocated, eventually > * third, by not requiring users to dive deep into var handles when they first > pick up the API; a new `MemoryAccess` class has been added, which defines > several useful dereference routines; these are really just thin wrappers > around memory access var handles, but they make the barrier of entry for > using this API somewhat lower. > > A big conceptual shift that comes with this API refresh is that the role of > `MemorySegment` and `MemoryAddress` is not the same as it used to be; it used > to be the case that a memory address could (sometimes, not always) have a > back link to the memory segment which originated it; additionally, memory > access var handles used `MemoryAddress` as a basic unit of dereference. > > This has all changed as per this API refresh; now a `MemoryAddress` is just > a dumb carrier which wraps a pair of object/long addressing coordinates; > `MemorySegment` has become the star of the show, as far as dereferencing > memory is concerned. You cannot dereference memory if you don't have a > segment. This improves usability in a number of ways - first, it is a lot > easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`; > secondly, it is crystal clear what a client has to do in order to dereference > memory: if a client has a segment, it can use that; otherwise, if the client > only has an address, it will have to create a segment *unsafely* (this can be > done by calling `MemoryAddress::asSegmentRestricted`). > > A list of the API, implementation and test changes is provided below. If you > have any questions, or need more detailed explanations, I (and the rest of > the Panama team) will be happy to point at existing discussions, and/or to > provide the feedback required. > > A big thank to Erik Osterlund, Vladimir Ivanov and David Holmes, without whom > the work on shared memory segment would not have been possible; also I'd like > to thank Paul Sandoz, whose insights on API design have been very helpful in > this journey. > > Thanks > Maurizio > > Javadoc: > > http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html > > Specdiff: > > http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html > > CSR: > > https://bugs.openjdk.java.net/browse/JDK-8254163 > > > > ### API Changes > > * `MemorySegment` > * drop factory for restricted segment (this has been moved to > `MemoryAddress`, see below) > * added a no-arg factory for a native restricted segment representing > entire native heap > * rename `withOwnerThread` to `handoff` > * add new `share` method, to create shared segments > * add new `registerCleaner` method, to register a segment against a cleaner > * add more helpers to create arrays from a segment e.g. `toIntArray` > * add some `asSlice` overloads (to make up for the fact that now segments > are more frequently used as cursors) > * rename `baseAddress` to `address` (so that `MemorySegment` can implement > `Addressable`) > * `MemoryAddress` > * drop `segment` accessor > * drop `rebase` method and replace it with `segmentOffset` which returns > the offset (a `long`) of this address relative to a given segment > * `MemoryAccess` > * New class supporting several static dereference helpers; the helpers are > organized by carrier and access mode, where a carrier is one of the usual > suspect (a Java primitive, minus `boolean`); the access mode can be simple > (e.g. access base address of given segment), or indexed, in which case the > accessor takes a segment and either a low-level byte offset,or a high level > logical index. The classification is reflected in the naming scheme (e.g. > `getByte` vs. `getByteAtOffset` vs `getByteAtIndex`). > * `MemoryHandles` > * drop `withOffset` combinator > * drop `withStride` combinator > * the basic memory access handle factory now returns a var handle which > takes a `MemorySegment` and a `long` - from which it is easy to derive all > the other handles using plain var handle combinators. > * `Addressable` > * This is a new interface which is attached to entities which can be > projected to a `MemoryAddress`. For now, both `MemoryAddress` and > `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more > implementations. Clients can largely ignore this interface, which comes in > really handy when
Re: RFR: 8256048: Incomplete gitignore setting for netbeans project [v2]
On Mon, 9 Nov 2020 13:53:35 GMT, Erik Joelsson wrote: >> Jie Fu has updated the pull request incrementally with one additional commit >> since the last revision: >> >> Don't remove nbproject/private/ > > .gitignore line 5: > >> 3: /.idea/ >> 4: /.vscode/ >> 5: /nbproject/ > > I believe the existing nbproject/private/ is meant to catch any private files > created by someone opening any of the various nbproject directories that > exist in the source base, so it should probably stay. Adding an ignore for > any top level nbproject directory in addition to that should be ok. Thanks @erikj79 for your review. Updated. Any comments? Thanks. - PR: https://git.openjdk.java.net/jdk/pull/1122
Re: RFR: 8254162: Implementation of Foreign-Memory Access API (Third Incubator) [v25]
> This patch contains the changes associated with the third incubation round of > the foreign memory access API incubation (see JEP 393 [1]). This iteration > focus on improving the usability of the API in 3 main ways: > > * first, by providing a way to obtain truly *shared* segments, which can be > accessed and closed concurrently from multiple threads > * second, by providing a way to register a memory segment against a > `Cleaner`, so as to have some (optional) guarantee that the memory will be > deallocated, eventually > * third, by not requiring users to dive deep into var handles when they first > pick up the API; a new `MemoryAccess` class has been added, which defines > several useful dereference routines; these are really just thin wrappers > around memory access var handles, but they make the barrier of entry for > using this API somewhat lower. > > A big conceptual shift that comes with this API refresh is that the role of > `MemorySegment` and `MemoryAddress` is not the same as it used to be; it used > to be the case that a memory address could (sometimes, not always) have a > back link to the memory segment which originated it; additionally, memory > access var handles used `MemoryAddress` as a basic unit of dereference. > > This has all changed as per this API refresh; now a `MemoryAddress` is just > a dumb carrier which wraps a pair of object/long addressing coordinates; > `MemorySegment` has become the star of the show, as far as dereferencing > memory is concerned. You cannot dereference memory if you don't have a > segment. This improves usability in a number of ways - first, it is a lot > easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`; > secondly, it is crystal clear what a client has to do in order to dereference > memory: if a client has a segment, it can use that; otherwise, if the client > only has an address, it will have to create a segment *unsafely* (this can be > done by calling `MemoryAddress::asSegmentRestricted`). > > A list of the API, implementation and test changes is provided below. If you > have any questions, or need more detailed explanations, I (and the rest of > the Panama team) will be happy to point at existing discussions, and/or to > provide the feedback required. > > A big thank to Erik Osterlund, Vladimir Ivanov and David Holmes, without whom > the work on shared memory segment would not have been possible; also I'd like > to thank Paul Sandoz, whose insights on API design have been very helpful in > this journey. > > Thanks > Maurizio > > Javadoc: > > http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html > > Specdiff: > > http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html > > CSR: > > https://bugs.openjdk.java.net/browse/JDK-8254163 > > > > ### API Changes > > * `MemorySegment` > * drop factory for restricted segment (this has been moved to > `MemoryAddress`, see below) > * added a no-arg factory for a native restricted segment representing > entire native heap > * rename `withOwnerThread` to `handoff` > * add new `share` method, to create shared segments > * add new `registerCleaner` method, to register a segment against a cleaner > * add more helpers to create arrays from a segment e.g. `toIntArray` > * add some `asSlice` overloads (to make up for the fact that now segments > are more frequently used as cursors) > * rename `baseAddress` to `address` (so that `MemorySegment` can implement > `Addressable`) > * `MemoryAddress` > * drop `segment` accessor > * drop `rebase` method and replace it with `segmentOffset` which returns > the offset (a `long`) of this address relative to a given segment > * `MemoryAccess` > * New class supporting several static dereference helpers; the helpers are > organized by carrier and access mode, where a carrier is one of the usual > suspect (a Java primitive, minus `boolean`); the access mode can be simple > (e.g. access base address of given segment), or indexed, in which case the > accessor takes a segment and either a low-level byte offset,or a high level > logical index. The classification is reflected in the naming scheme (e.g. > `getByte` vs. `getByteAtOffset` vs `getByteAtIndex`). > * `MemoryHandles` > * drop `withOffset` combinator > * drop `withStride` combinator > * the basic memory access handle factory now returns a var handle which > takes a `MemorySegment` and a `long` - from which it is easy to derive all > the other handles using plain var handle combinators. > * `Addressable` > * This is a new interface which is attached to entities which can be > projected to a `MemoryAddress`. For now, both `MemoryAddress` and > `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more > implementations. Clients can largely ignore this interface, which comes in > really handy when
Re: RFR: 8256048: Incomplete gitignore setting for netbeans project [v2]
> Hi all, > > The gitignore setting for netbeans project seems to be incomplete. > Only nbproject/private/ [1] is ignored. > > But there are also other files under nbproject/, which should be ignored too. > > $ tree -L 1 nbproject/ > nbproject/ > ├── configurations.xml > ├── private > └── project.xml > > > It would be better to fix it. > > Thanks. > Best regards, > Jie > > > [1] https://github.com/openjdk/jdk/blob/master/.gitignore#L5 Jie Fu has updated the pull request incrementally with one additional commit since the last revision: Don't remove nbproject/private/ - Changes: - all: https://git.openjdk.java.net/jdk/pull/1122/files - new: https://git.openjdk.java.net/jdk/pull/1122/files/573612e4..f48474eb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=1122=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1122=00-01 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1122.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1122/head:pull/1122 PR: https://git.openjdk.java.net/jdk/pull/1122
Re: RFR: 8256048: Incomplete gitignore setting for netbeans project
On Mon, 9 Nov 2020 12:07:37 GMT, Jie Fu wrote: > Hi all, > > The gitignore setting for netbeans project seems to be incomplete. > Only nbproject/private/ [1] is ignored. > > But there are also other files under nbproject/, which should be ignored too. > > $ tree -L 1 nbproject/ > nbproject/ > ├── configurations.xml > ├── private > └── project.xml > > > It would be better to fix it. > > Thanks. > Best regards, > Jie > > > [1] https://github.com/openjdk/jdk/blob/master/.gitignore#L5 .gitignore line 5: > 3: /.idea/ > 4: /.vscode/ > 5: /nbproject/ I believe the existing nbproject/private/ is meant to catch any private files created by someone opening any of the various nbproject directories that exist in the source base, so it should probably stay. Adding an ignore for any top level nbproject directory in addition to that should be ok. - PR: https://git.openjdk.java.net/jdk/pull/1122
Re: RFR: 8254162: Implementation of Foreign-Memory Access API (Third Incubator) [v24]
> This patch contains the changes associated with the third incubation round of > the foreign memory access API incubation (see JEP 393 [1]). This iteration > focus on improving the usability of the API in 3 main ways: > > * first, by providing a way to obtain truly *shared* segments, which can be > accessed and closed concurrently from multiple threads > * second, by providing a way to register a memory segment against a > `Cleaner`, so as to have some (optional) guarantee that the memory will be > deallocated, eventually > * third, by not requiring users to dive deep into var handles when they first > pick up the API; a new `MemoryAccess` class has been added, which defines > several useful dereference routines; these are really just thin wrappers > around memory access var handles, but they make the barrier of entry for > using this API somewhat lower. > > A big conceptual shift that comes with this API refresh is that the role of > `MemorySegment` and `MemoryAddress` is not the same as it used to be; it used > to be the case that a memory address could (sometimes, not always) have a > back link to the memory segment which originated it; additionally, memory > access var handles used `MemoryAddress` as a basic unit of dereference. > > This has all changed as per this API refresh; now a `MemoryAddress` is just > a dumb carrier which wraps a pair of object/long addressing coordinates; > `MemorySegment` has become the star of the show, as far as dereferencing > memory is concerned. You cannot dereference memory if you don't have a > segment. This improves usability in a number of ways - first, it is a lot > easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`; > secondly, it is crystal clear what a client has to do in order to dereference > memory: if a client has a segment, it can use that; otherwise, if the client > only has an address, it will have to create a segment *unsafely* (this can be > done by calling `MemoryAddress::asSegmentRestricted`). > > A list of the API, implementation and test changes is provided below. If you > have any questions, or need more detailed explanations, I (and the rest of > the Panama team) will be happy to point at existing discussions, and/or to > provide the feedback required. > > A big thank to Erik Osterlund, Vladimir Ivanov and David Holmes, without whom > the work on shared memory segment would not have been possible; also I'd like > to thank Paul Sandoz, whose insights on API design have been very helpful in > this journey. > > Thanks > Maurizio > > Javadoc: > > http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html > > Specdiff: > > http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html > > CSR: > > https://bugs.openjdk.java.net/browse/JDK-8254163 > > > > ### API Changes > > * `MemorySegment` > * drop factory for restricted segment (this has been moved to > `MemoryAddress`, see below) > * added a no-arg factory for a native restricted segment representing > entire native heap > * rename `withOwnerThread` to `handoff` > * add new `share` method, to create shared segments > * add new `registerCleaner` method, to register a segment against a cleaner > * add more helpers to create arrays from a segment e.g. `toIntArray` > * add some `asSlice` overloads (to make up for the fact that now segments > are more frequently used as cursors) > * rename `baseAddress` to `address` (so that `MemorySegment` can implement > `Addressable`) > * `MemoryAddress` > * drop `segment` accessor > * drop `rebase` method and replace it with `segmentOffset` which returns > the offset (a `long`) of this address relative to a given segment > * `MemoryAccess` > * New class supporting several static dereference helpers; the helpers are > organized by carrier and access mode, where a carrier is one of the usual > suspect (a Java primitive, minus `boolean`); the access mode can be simple > (e.g. access base address of given segment), or indexed, in which case the > accessor takes a segment and either a low-level byte offset,or a high level > logical index. The classification is reflected in the naming scheme (e.g. > `getByte` vs. `getByteAtOffset` vs `getByteAtIndex`). > * `MemoryHandles` > * drop `withOffset` combinator > * drop `withStride` combinator > * the basic memory access handle factory now returns a var handle which > takes a `MemorySegment` and a `long` - from which it is easy to derive all > the other handles using plain var handle combinators. > * `Addressable` > * This is a new interface which is attached to entities which can be > projected to a `MemoryAddress`. For now, both `MemoryAddress` and > `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more > implementations. Clients can largely ignore this interface, which comes in > really handy when
Re: RFR: 8254162: Implementation of Foreign-Memory Access API (Third Incubator) [v23]
> This patch contains the changes associated with the third incubation round of > the foreign memory access API incubation (see JEP 393 [1]). This iteration > focus on improving the usability of the API in 3 main ways: > > * first, by providing a way to obtain truly *shared* segments, which can be > accessed and closed concurrently from multiple threads > * second, by providing a way to register a memory segment against a > `Cleaner`, so as to have some (optional) guarantee that the memory will be > deallocated, eventually > * third, by not requiring users to dive deep into var handles when they first > pick up the API; a new `MemoryAccess` class has been added, which defines > several useful dereference routines; these are really just thin wrappers > around memory access var handles, but they make the barrier of entry for > using this API somewhat lower. > > A big conceptual shift that comes with this API refresh is that the role of > `MemorySegment` and `MemoryAddress` is not the same as it used to be; it used > to be the case that a memory address could (sometimes, not always) have a > back link to the memory segment which originated it; additionally, memory > access var handles used `MemoryAddress` as a basic unit of dereference. > > This has all changed as per this API refresh; now a `MemoryAddress` is just > a dumb carrier which wraps a pair of object/long addressing coordinates; > `MemorySegment` has become the star of the show, as far as dereferencing > memory is concerned. You cannot dereference memory if you don't have a > segment. This improves usability in a number of ways - first, it is a lot > easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`; > secondly, it is crystal clear what a client has to do in order to dereference > memory: if a client has a segment, it can use that; otherwise, if the client > only has an address, it will have to create a segment *unsafely* (this can be > done by calling `MemoryAddress::asSegmentRestricted`). > > A list of the API, implementation and test changes is provided below. If you > have any questions, or need more detailed explanations, I (and the rest of > the Panama team) will be happy to point at existing discussions, and/or to > provide the feedback required. > > A big thank to Erik Osterlund, Vladimir Ivanov and David Holmes, without whom > the work on shared memory segment would not have been possible; also I'd like > to thank Paul Sandoz, whose insights on API design have been very helpful in > this journey. > > Thanks > Maurizio > > Javadoc: > > http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html > > Specdiff: > > http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html > > CSR: > > https://bugs.openjdk.java.net/browse/JDK-8254163 > > > > ### API Changes > > * `MemorySegment` > * drop factory for restricted segment (this has been moved to > `MemoryAddress`, see below) > * added a no-arg factory for a native restricted segment representing > entire native heap > * rename `withOwnerThread` to `handoff` > * add new `share` method, to create shared segments > * add new `registerCleaner` method, to register a segment against a cleaner > * add more helpers to create arrays from a segment e.g. `toIntArray` > * add some `asSlice` overloads (to make up for the fact that now segments > are more frequently used as cursors) > * rename `baseAddress` to `address` (so that `MemorySegment` can implement > `Addressable`) > * `MemoryAddress` > * drop `segment` accessor > * drop `rebase` method and replace it with `segmentOffset` which returns > the offset (a `long`) of this address relative to a given segment > * `MemoryAccess` > * New class supporting several static dereference helpers; the helpers are > organized by carrier and access mode, where a carrier is one of the usual > suspect (a Java primitive, minus `boolean`); the access mode can be simple > (e.g. access base address of given segment), or indexed, in which case the > accessor takes a segment and either a low-level byte offset,or a high level > logical index. The classification is reflected in the naming scheme (e.g. > `getByte` vs. `getByteAtOffset` vs `getByteAtIndex`). > * `MemoryHandles` > * drop `withOffset` combinator > * drop `withStride` combinator > * the basic memory access handle factory now returns a var handle which > takes a `MemorySegment` and a `long` - from which it is easy to derive all > the other handles using plain var handle combinators. > * `Addressable` > * This is a new interface which is attached to entities which can be > projected to a `MemoryAddress`. For now, both `MemoryAddress` and > `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more > implementations. Clients can largely ignore this interface, which comes in > really handy when
Re: RFR: 8254162: Implementation of Foreign-Memory Access API (Third Incubator) [v22]
On Sun, 8 Nov 2020 16:28:41 GMT, Alan Bateman wrote: >> Maurizio Cimadamore has updated the pull request with a new target base due >> to a merge or a rebase. The pull request now contains 29 commits: >> >> - Fix post-merge issues caused by 8219014 >> - Merge branch 'master' into 8254162 >> - Addess remaining feedback from @AlanBateman and @mrserb >> - Address comments from @AlanBateman >> - Merge branch 'master' into 8254162 >> - Fix issues with derived buffers and IO operations >> - More 32-bit fixes for TestLayouts >> - * Add final to MappedByteBuffer::SCOPED_MEMORY_ACCESS field >>* Tweak TestLayouts to make it 32-bit friendly after recent MemoryLayouts >> tweaks >> - Remove TestMismatch from 32-bit problem list >> - Merge branch 'master' into 8254162 >> - ... and 19 more: >> https://git.openjdk.java.net/jdk/compare/a50fdd54...02f9e251 > > Marked as reviewed by alanb (Reviewer). > I see the xxxByteAtIndex methods that took a ByteOrder have been removed from > MemoryAccess. Should the xxxByte and xxxByteAtOffset that take a ByteOrder be > removed too? I've addresses this in the latest iteration. Since I was there I also removed `getByteAtIndex` and `getByteAtIndex`, since their behavior is identical to that of `getByteAtOffset` and `setByteAtOffset`, respectively (in other words, the indexed variants are not really helpful until carrier size > 1 byte). - PR: https://git.openjdk.java.net/jdk/pull/548
RFR: 8256048: Incomplete gitignore setting for netbeans project
Hi all, The gitignore setting for netbeans project seems to be incomplete. Only nbproject/private/ [1] is ignored. But there are also other files under nbproject/, which should be ignored too. $ tree -L 1 nbproject/ nbproject/ ├── configurations.xml ├── private └── project.xml It would be better to fix it. Thanks. Best regards, Jie [1] https://github.com/openjdk/jdk/blob/master/.gitignore#L5 - Commit messages: - 8256048: Incomplete gitignore setting for netbeans project Changes: https://git.openjdk.java.net/jdk/pull/1122/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=1122=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256048 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1122.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1122/head:pull/1122 PR: https://git.openjdk.java.net/jdk/pull/1122
