Re: RFR: JDK-8255603: Memory/Performance regression after JDK-8210985
On Thu, 29 Oct 2020 15:11:09 GMT, Christoph Langer wrote: > It seems that there exists a memory/performance regression that was > introduced with JDK-8210985: Update the default SSL session cache size to > 20480. > > The idea to limit the maixmum SSL session cache size by itself is good. > Unfortunately, as per the current implementation of > sun.security.util.MemoryCache, it also modifies the initial size of the > LinkedHashMap that is backing the cache to initialize with more than the > maximum size. > > I suggest to restore the original behavior that initializes with an > initialCapacity of 1 in most cases. That was true when before JDK-8210985, > the property javax.net.ssl.sessionCacheSize was not set at all. > In case it was set, the initial size would have been like now, > (javax.net.ssl.sessionCacheSize / 0.75f) + 1, which still seems strange. I had a benchmarking with one client and one server for full handshaking, with JMH. I did not see throughput regression with this benchmarking, and the improvement is not visible although. The benchmarking itself may be limited as it is trying to use a large volume of connections. - Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/937
Re: RFR: JDK-8255603: Memory/Performance regression after JDK-8210985
On Thu, 29 Oct 2020 18:02:47 GMT, Xue-Lei Andrew Fan wrote: >>> > Benchmarking is probably hard because we don't know the average occupancy >>> > of the map. >>> >>> I agreed. No matter what the default value is, it will not fit perfectly in >>> all situations. The value 1 may be fit for small workload applications, but >>> not good for big workload applications. Applications could use the size >>> setting APIs for the tuning. For this update, I think the impact for >>> various workload may be limited/acceptable, but I'm not very sure of it. >>> Benchmarking data with various workload would help us for a better sense. >> >> But we did run with `1` for quite a long time without somebody complaining :) > >> > > Benchmarking is probably hard because we don't know the average >> > > occupancy of the map. >> > >> > >> > I agreed. No matter what the default value is, it will not fit perfectly >> > in all situations. The value 1 may be fit for small workload applications, >> > but not good for big workload applications. Applications could use the >> > size setting APIs for the tuning. For this update, I think the impact for >> > various workload may be limited/acceptable, but I'm not very sure of it. >> > Benchmarking data with various workload would help us for a better sense. >> >> But we did run with `1` for quite a long time without somebody complaining :) > > Yes, I think it is a safe update and looks good to me. I believe the impact > should be minimal. But normally, I would like to check with a test for sure. > If no regression test, an explain with noreg tag may be needed. External > testing, like a confirmation of no performance regression any longer in an > existing application, is fine. > > I don't want to block this integration, please go ahead if you are confident > with it. I added the noreg-hard label to the JBS bug. I'll wait for any further input til monday, before integration. @XueleiFan would be nice if you could approve then, too :) - PR: https://git.openjdk.java.net/jdk/pull/937
Re: RFR: 8255494: PKCS7 should use digest algorithm to verify the signature
On Wed, 28 Oct 2020 21:01:44 GMT, Weijun Wang wrote: > This is a regression made by > [JDK-8242068](https://bugs.openjdk.java.net/browse/JDK-8242068). When the > digest algorithm is not the same as the hash part of the signature algorithm, > we used to combine the digest algorithm with the key part of the signature > algorithm into a new signature algorithm and use it when generating a > signature. The previous code change uses the signature algorithm in the > SignerInfo directly. This bugfix will revert to the old behavior. Looks good! - PR: https://git.openjdk.java.net/jdk/pull/916
Re: RFR: 8255494: PKCS7 should use digest algorithm to verify the signature [v2]
> This is a regression made by > [JDK-8242068](https://bugs.openjdk.java.net/browse/JDK-8242068). When the > digest algorithm is not the same as the hash part of the signature algorithm, > we used to combine the digest algorithm with the key part of the signature > algorithm into a new signature algorithm and use it when generating a > signature. The previous code change uses the signature algorithm in the > SignerInfo directly. This bugfix will revert to the old behavior. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: more comment to the test, and full DER encoding - Changes: - all: https://git.openjdk.java.net/jdk/pull/916/files - new: https://git.openjdk.java.net/jdk/pull/916/files/bc354142..19aa3f4d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=916=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=916=00-01 Stats: 9 lines in 1 file changed: 3 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/916.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/916/head:pull/916 PR: https://git.openjdk.java.net/jdk/pull/916
Re: RFR: 8255536: Remove the directsign property and option
On Wed, 28 Oct 2020 20:56:31 GMT, Weijun Wang wrote: > I regret adding the `directsign` property/option to JarSigner/jarsigner. See > the bug for details. Looks good. - Marked as reviewed by mullan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/915
Re: RFR: JDK-8255603: Memory/Performance regression after JDK-8210985
On Thu, 29 Oct 2020 17:43:43 GMT, Volker Simonis wrote: > > > Benchmarking is probably hard because we don't know the average occupancy > > > of the map. > > > > > > I agreed. No matter what the default value is, it will not fit perfectly in > > all situations. The value 1 may be fit for small workload applications, but > > not good for big workload applications. Applications could use the size > > setting APIs for the tuning. For this update, I think the impact for > > various workload may be limited/acceptable, but I'm not very sure of it. > > Benchmarking data with various workload would help us for a better sense. > > But we did run with `1` for quite a long time without somebody complaining :) Yes, I think it is a safe update and looks good to me. I believe the impact should be minimal. But normally, I would like to check with a test for sure. If no regression test, an explain with noreg tag may be needed. External testing, like a confirmation of no performance regression any longer in an existing application, is fine. I don't want to block this integration, please go ahead if you are confident with it. - PR: https://git.openjdk.java.net/jdk/pull/937
Re: RFR: JDK-8255603: Memory/Performance regression after JDK-8210985
On Thu, 29 Oct 2020 17:14:17 GMT, Xue-Lei Andrew Fan wrote: >> It seems that there exists a memory/performance regression that was >> introduced with JDK-8210985: Update the default SSL session cache size to >> 20480. >> >> The idea to limit the maixmum SSL session cache size by itself is good. >> Unfortunately, as per the current implementation of >> sun.security.util.MemoryCache, it also modifies the initial size of the >> LinkedHashMap that is backing the cache to initialize with more than the >> maximum size. >> >> I suggest to restore the original behavior that initializes with an >> initialCapacity of 1 in most cases. That was true when before JDK-8210985, >> the property javax.net.ssl.sessionCacheSize was not set at all. >> In case it was set, the initial size would have been like now, >> (javax.net.ssl.sessionCacheSize / 0.75f) + 1, which still seems strange. > > No regression test. > > Benchmarking is probably hard because we don't know the average occupancy > > of the map. > > I agreed. No matter what the default value is, it will not fit perfectly in > all situations. The value 1 may be fit for small workload applications, but > not good for big workload applications. Applications could use the size > setting APIs for the tuning. For this update, I think the impact for various > workload may be limited/acceptable, but I'm not very sure of it. Benchmarking > data with various workload would help us for a better sense. But we did run with `1` for quite a long time without somebody complaining :) - PR: https://git.openjdk.java.net/jdk/pull/937
Re: RFR: JDK-8255603: Memory/Performance regression after JDK-8210985
On Thu, 29 Oct 2020 17:06:11 GMT, Volker Simonis wrote: >> It seems that there exists a memory/performance regression that was >> introduced with JDK-8210985: Update the default SSL session cache size to >> 20480. >> >> The idea to limit the maixmum SSL session cache size by itself is good. >> Unfortunately, as per the current implementation of >> sun.security.util.MemoryCache, it also modifies the initial size of the >> LinkedHashMap that is backing the cache to initialize with more than the >> maximum size. >> >> I suggest to restore the original behavior that initializes with an >> initialCapacity of 1 in most cases. That was true when before JDK-8210985, >> the property javax.net.ssl.sessionCacheSize was not set at all. >> In case it was set, the initial size would have been like now, >> (javax.net.ssl.sessionCacheSize / 0.75f) + 1, which still seems strange. > > Marked as reviewed by simonis (Reviewer). > Benchmarking is probably hard because we don't know the average occupancy of > the map. > I agreed. No matter what the default value is, it will not fit perfectly in all situations. The value 1 may be fit for small workload applications, but not good for big workload applications. Applications could use the size setting APIs for the tuning. For this update, I think the impact for various workload may be limited/acceptable, but I'm not very sure of it. Benchmarking data with various workload would help us for a better sense. - PR: https://git.openjdk.java.net/jdk/pull/937
Re: RFR: JDK-8255603: Memory/Performance regression after JDK-8210985
On Thu, 29 Oct 2020 15:11:09 GMT, Christoph Langer wrote: > It seems that there exists a memory/performance regression that was > introduced with JDK-8210985: Update the default SSL session cache size to > 20480. > > The idea to limit the maixmum SSL session cache size by itself is good. > Unfortunately, as per the current implementation of > sun.security.util.MemoryCache, it also modifies the initial size of the > LinkedHashMap that is backing the cache to initialize with more than the > maximum size. > > I suggest to restore the original behavior that initializes with an > initialCapacity of 1 in most cases. That was true when before JDK-8210985, > the property javax.net.ssl.sessionCacheSize was not set at all. > In case it was set, the initial size would have been like now, > (javax.net.ssl.sessionCacheSize / 0.75f) + 1, which still seems strange. No regression test. - Changes requested by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/937
Re: RFR: JDK-8255603: Memory/Performance regression after JDK-8210985
On Thu, 29 Oct 2020 15:11:09 GMT, Christoph Langer wrote: > It seems that there exists a memory/performance regression that was > introduced with JDK-8210985: Update the default SSL session cache size to > 20480. > > The idea to limit the maixmum SSL session cache size by itself is good. > Unfortunately, as per the current implementation of > sun.security.util.MemoryCache, it also modifies the initial size of the > LinkedHashMap that is backing the cache to initialize with more than the > maximum size. > > I suggest to restore the original behavior that initializes with an > initialCapacity of 1 in most cases. That was true when before JDK-8210985, > the property javax.net.ssl.sessionCacheSize was not set at all. > In case it was set, the initial size would have been like now, > (javax.net.ssl.sessionCacheSize / 0.75f) + 1, which still seems strange. Marked as reviewed by simonis (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/937
Re: RFR: JDK-8255603: Memory/Performance regression after JDK-8210985
On Thu, 29 Oct 2020 16:45:01 GMT, Christoph Langer wrote:
>>> > Did you have a benchmark with various cache sizes (for example, from 1 to
>>> > 10K) and various connections (for example from 1 to 10K) for those
>>> > components (including TLS implementation) that use Cache?
>>>
>>> Nope, we've just seen the memory regression in a certain customer use case
>>> (lot's of meory retained by a finalizer) and confirmed it resolved after
>>> setting javax.net.ssl.sessionCacheSize to 0.
>>>
>> Did you have this patch checked with the customer? I think the performance
>> may be similar or improved comparing to set the cache size to 0.
>>
>>> But I guess this change merits certain further benchmarking to get it right.
>>>
>> It looks good to me, but we may be more confident with it if there is a
>> benchmarking.
>
> We're currently rolling out a patch to our SAP JVM shipment (based on
> Oracle's JDK 8 licensee repository) with exactly this content. We will then
> check with the customer but I'd suspect his results will about the same as
> with -Djavax.net.ssl.sessionCacheSize=0.
>
> If you require some benchmarking I guess it'll take me some more time.
>
> In the end I doubt that we'll find a better default value than 1 for the
> cache size as it's hard to predict how full a cache will be in the average.
> Maybe one could spend a property for the initial size - but I also doubt
> that's worth the effort.
>
> I also think that for the use case in StatusResponseManager's responseCache
> the influence of a different initial value is neglectable.
I can confirm that JDK-8210985 can cause massive regressions in memory
consumption. Also, [JDK-8253116
Performance regression observed post upgrade to
8u261](https://bugs.openjdk.java.net/browse/JDK-8253116) is clearly a duplicate
for this.
I'm fine with setting the initial cache size to 1 as this restores the original
behavior for `javax.net.ssl.sessionCacheSize=0`.
The other possibility would be to use the default size for `LinkedHashMap` but
that's not easy if we want to set the `accessOrder` because the only
constructor which takes the `accessOrder` also requires the specification of
`initialCapacitiy` and `loadFactor`. Otherwise, `LinkedHashMap`s capacity
defaults to `HashMap`s default capacity which is `16`.
Setting the `initialCapacity` to `1` will initialize the hash map with one
bucket (see initialization code in `HashMap`).
/**
* Returns a power of two size for the given target capacity.
*/
static final int tableSizeFor(int cap) {
int n = cap - 1;
n |= n >>> 1;
n |= n >>> 2;
n |= n >>> 4;
n |= n >>> 8;
n |= n >>> 16;
return (n < 0) ? 1 : (n >= MAXIMUM_CAPACITY) ? MAXIMUM_CAPACITY : n + 1;
}
Benchmarking is probably hard because we don't know the average occupancy of
the map.
So in the end I think `1` is a good solution for now.
-
PR: https://git.openjdk.java.net/jdk/pull/937
Re: RFR: JDK-8255603: Memory/Performance regression after JDK-8210985
On Thu, 29 Oct 2020 16:21:47 GMT, Xue-Lei Andrew Fan wrote: >>> Did you have a benchmark with various cache sizes (for example, from 1 to >>> 10K) and various connections (for example from 1 to 10K) for those >>> components (including TLS implementation) that use Cache? >> >> Nope, we've just seen the memory regression in a certain customer use case >> (lot's of meory retained by a finalizer) and confirmed it resolved after >> setting javax.net.ssl.sessionCacheSize to 0. >> >> But I guess this change merits certain further benchmarking to get it right. > >> > Did you have a benchmark with various cache sizes (for example, from 1 to >> > 10K) and various connections (for example from 1 to 10K) for those >> > components (including TLS implementation) that use Cache? >> >> Nope, we've just seen the memory regression in a certain customer use case >> (lot's of meory retained by a finalizer) and confirmed it resolved after >> setting javax.net.ssl.sessionCacheSize to 0. >> > Did you have this patch checked with the customer? I think the performance > may be similar or improved comparing to set the cache size to 0. > >> But I guess this change merits certain further benchmarking to get it right. >> > It looks good to me, but we may be more confident with it if there is a > benchmarking. We're currently rolling out a patch to our SAP JVM shipment (based on Oracle's JDK 8 licensee repository) with exactly this content. We will then check with the customer but I'd suspect his results will about the same as with -Djavax.net.ssl.sessionCacheSize=0. If you require some benchmarking I guess it'll take me some more time. In the end I doubt that we'll find a better default value than 1 for the cache size as it's hard to predict how full a cache will be in the average. Maybe one could spend a property for the initial size - but I also doubt that's worth the effort. I also think that for the use case in StatusResponseManager's responseCache the influence of a different initial value is neglectable. - PR: https://git.openjdk.java.net/jdk/pull/937
Re: RFR: JDK-8255603: Memory/Performance regression after JDK-8210985
On Thu, 29 Oct 2020 16:01:19 GMT, Christoph Langer wrote: > > Did you have a benchmark with various cache sizes (for example, from 1 to > > 10K) and various connections (for example from 1 to 10K) for those > > components (including TLS implementation) that use Cache? > > Nope, we've just seen the memory regression in a certain customer use case > (lot's of meory retained by a finalizer) and confirmed it resolved after > setting javax.net.ssl.sessionCacheSize to 0. > Did you have this patch checked with the customer? I think the performance may be similar or improved comparing to set the cache size to 0. > But I guess this change merits certain further benchmarking to get it right. > It looks good to me, but we may be more confident with it if there is a benchmarking. - PR: https://git.openjdk.java.net/jdk/pull/937
Re: RFR: JDK-8255603: Memory/Performance regression after JDK-8210985
On Thu, 29 Oct 2020 16:01:19 GMT, Christoph Langer wrote: >> Did you have a benchmark with various cache sizes (for example, from 1 to >> 10K) and various connections (for example from 1 to 10K) for those >> components (including TLS implementation) that use Cache? > >> Did you have a benchmark with various cache sizes (for example, from 1 to >> 10K) and various connections (for example from 1 to 10K) for those >> components (including TLS implementation) that use Cache? > > Nope, we've just seen the memory regression in a certain customer use case > (lot's of meory retained by a finalizer) and confirmed it resolved after > setting javax.net.ssl.sessionCacheSize to 0. > > But I guess this change merits certain further benchmarking to get it right. Congratulations! You beat me about half an hour with this issue :) I was debugging this regression already the whole day and when I searched for JDK-8210985 in my mailbox I saw your post. - PR: https://git.openjdk.java.net/jdk/pull/937
Re: RFR: JDK-8255603: Memory/Performance regression after JDK-8210985
On Thu, 29 Oct 2020 15:54:27 GMT, Xue-Lei Andrew Fan wrote: > Did you have a benchmark with various cache sizes (for example, from 1 to > 10K) and various connections (for example from 1 to 10K) for those components > (including TLS implementation) that use Cache? Nope, we've just seen the memory regression in a certain customer use case (lot's of meory retained by a finalizer) and confirmed it resolved after setting javax.net.ssl.sessionCacheSize to 0. But I guess this change merits certain further benchmarking to get it right. - PR: https://git.openjdk.java.net/jdk/pull/937
Re: RFR: JDK-8255603: Memory/Performance regression after JDK-8210985
On Thu, 29 Oct 2020 15:11:09 GMT, Christoph Langer wrote: > It seems that there exists a memory/performance regression that was > introduced with JDK-8210985: Update the default SSL session cache size to > 20480. > > The idea to limit the maixmum SSL session cache size by itself is good. > Unfortunately, as per the current implementation of > sun.security.util.MemoryCache, it also modifies the initial size of the > LinkedHashMap that is backing the cache to initialize with more than the > maximum size. > > I suggest to restore the original behavior that initializes with an > initialCapacity of 1 in most cases. That was true when before JDK-8210985, > the property javax.net.ssl.sessionCacheSize was not set at all. > In case it was set, the initial size would have been like now, > (javax.net.ssl.sessionCacheSize / 0.75f) + 1, which still seems strange. Did you have a benchmark with various cache sizes (for example, from 1 to 10K) and various connections (for example from 1 to 10K) for those components (including TLS implementation) that use Cache? - PR: https://git.openjdk.java.net/jdk/pull/937
RFR: JDK-8255603: Memory/Performance regression after JDK-8210985
It seems that there exists a memory/performance regression that was introduced with JDK-8210985: Update the default SSL session cache size to 20480. The idea to limit the maixmum SSL session cache size by itself is good. Unfortunately, as per the current implementation of sun.security.util.MemoryCache, it also modifies the initial size of the LinkedHashMap that is backing the cache to initialize with more than the maximum size. I suggest to restore the original behavior that initializes with an initialCapacity of 1 in most cases. That was true when before JDK-8210985, the property javax.net.ssl.sessionCacheSize was not set at all. In case it was set, the initial size would have been like now, (javax.net.ssl.sessionCacheSize / 0.75f) + 1, which still seems strange. - Commit messages: - Copyright year - JDK-8255603: Memory/Performance regression after JDK-8210985 Changes: https://git.openjdk.java.net/jdk/pull/937/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=937=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255603 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/937.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/937/head:pull/937 PR: https://git.openjdk.java.net/jdk/pull/937
Re: RFR: 8254162: Implementation of Foreign-Memory Access API (Third Incubator)
On Tue, 27 Oct 2020 14:40:29 GMT, Maurizio Cimadamore wrote: >> 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 >>
Re: RFR: 8254162: Implementation of Foreign-Memory Access API (Third Incubator) [v18]
> 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
