Re: RFR: 8243559: Remove root certificates with 1024-bit keys
On Mon, 23 Nov 2020 15:47:25 GMT, Weijun Wang wrote: >> This change removes five root certificates with 1024-bit RSA public keys >> from the system-wide `cacerts` keystore. These are older VeriSign and Thawte >> root CA certificates which are no longer necessary to retain and should have >> minimal compatibility risk if removed. >> >> See the CSR for more details: >> https://bugs.openjdk.java.net/browse/JDK-8256502 > > Marked as reviewed by weijun (Reviewer). > Looks fine. > > One nit: I see that the `VerifyCACerts.java` test has a whole bunch of `@bug` > ids. Maybe we should add this new one as well? Good catch. I will add it. - PR: https://git.openjdk.java.net/jdk/pull/1387
Re: RFR: 8243559: Remove root certificates with 1024-bit keys
On Mon, 23 Nov 2020 15:08:13 GMT, Sean Mullan wrote: > This change removes five root certificates with 1024-bit RSA public keys from > the system-wide `cacerts` keystore. These are older VeriSign and Thawte root > CA certificates which are no longer necessary to retain and should have > minimal compatibility risk if removed. > > See the CSR for more details: https://bugs.openjdk.java.net/browse/JDK-8256502 Marked as reviewed by weijun (Reviewer). Looks fine. One nit: I see that the `VerifyCACerts.java` test has a whole bunch of `@bug` ids. Maybe we should add this new one as well? - PR: https://git.openjdk.java.net/jdk/pull/1387
Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v2]
> This PR is to introduce a new random number API for the JDK. The primary API > is found in RandomGenerator and RandomGeneratorFactory. Further description > can be found in the JEP https://openjdk.java.net/jeps/356 . > > javadoc can be found at > http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html > > old PR: https://github.com/openjdk/jdk/pull/1273 Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Review changes @PaulSandoz and @rogermb - Changes: - all: https://git.openjdk.java.net/jdk/pull/1292/files - new: https://git.openjdk.java.net/jdk/pull/1292/files/2b3e4ed7..9d6d1a94 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=00-01 Stats: 18 lines in 4 files changed: 2 ins; 5 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/1292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292 PR: https://git.openjdk.java.net/jdk/pull/1292
Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
On Fri, 20 Nov 2020 23:30:03 GMT, Roger Baumgartner wrote: >> This PR is to introduce a new random number API for the JDK. The primary API >> is found in RandomGenerator and RandomGeneratorFactory. Further description >> can be found in the JEP https://openjdk.java.net/jeps/356 . >> >> javadoc can be found at >> http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html >> >> old PR: https://github.com/openjdk/jdk/pull/1273 > > src/java.base/share/classes/java/util/random/package-info.java line 149: > >> 147: * >> 148: * For an application running in a 32-bit hardware environment and >> using >> 149: * only one thread or a small number of threads, may be a good choice. > > I think the name of the suitable algorithm is missing here. Yes - "L32X64MixRandom". Thank you. - PR: https://git.openjdk.java.net/jdk/pull/1292
Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v3]
On Wed, 18 Nov 2020 00:29:36 GMT, Paul Sandoz wrote:
>> Jim Laskey has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 40 commits:
>>
>> - Merge branch 'master' into 8248862
>> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>
>>Update package-info.java
>> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>
>>Updated RandomGeneratorFactory javadoc.
>> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>
>>Updated documentation for RandomGeneratorFactory.
>> - Merge branch 'master' into 8248862
>> - Merge branch 'master' into 8248862
>> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>
>>Move RandomGeneratorProperty
>> - Merge branch 'master' into 8248862
>> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>
>>Clear up javadoc
>> - 8248862; Implement Enhanced Pseudo-Random Number Generators
>>
>>remove RandomGeneratorProperty from API
>> - ... and 30 more:
>> https://git.openjdk.java.net/jdk/compare/f7517386...6fe94c68
>
> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line
> 173:
>
>> 171: @SuppressWarnings("unchecked")
>> 172: private Map getProperties() {
>> 173: if (properties == null) {
>
> `properties` needs to be marked volatile, and it needs to be assigned at line
> 182 or line 184.
One of them foggy days.
-
PR: https://git.openjdk.java.net/jdk/pull/1273
Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v3]
On Mon, 23 Nov 2020 14:57:59 GMT, Jim Laskey wrote:
>> src/java.base/share/classes/module-info.java line 250:
>>
>>> 248: exports jdk.internal.util.xml.impl to
>>> 249: jdk.jfr;
>>> 250: exports jdk.internal.util.random;
>>
>> Unqualified export, should this be `to jdk.random`?
>
> I guess you are right. Until we have a defined SPI we should restrict.
On the other hand:
public class Random extends AbstractSpliteratorGenerator
^
error: warnings found and -Werror specified
public final class SplittableRandom extends AbstractSplittableGenerator {
-
PR: https://git.openjdk.java.net/jdk/pull/1273
Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v3]
On Tue, 17 Nov 2020 23:46:12 GMT, Paul Sandoz wrote:
>> Jim Laskey has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 40 commits:
>>
>> - Merge branch 'master' into 8248862
>> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>
>>Update package-info.java
>> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>
>>Updated RandomGeneratorFactory javadoc.
>> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>
>>Updated documentation for RandomGeneratorFactory.
>> - Merge branch 'master' into 8248862
>> - Merge branch 'master' into 8248862
>> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>
>>Move RandomGeneratorProperty
>> - Merge branch 'master' into 8248862
>> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>
>>Clear up javadoc
>> - 8248862; Implement Enhanced Pseudo-Random Number Generators
>>
>>remove RandomGeneratorProperty from API
>> - ... and 30 more:
>> https://git.openjdk.java.net/jdk/compare/f7517386...6fe94c68
>
> src/jdk.random/share/classes/module-info.java line 53:
>
>> 51: uses RandomSupport;
>> 52:
>> 53: exports jdk.random to
>
> Why is this needed?
Removing
> src/java.base/share/classes/java/util/random/package-info.java line 50:
>
>> 48: * given its name.
>> 49: *
>> 50: * The principal supporting class is {@link RandomGenertatorFactor}.
>> This
>
> s/RandomGenertatorFactor/RandomGenertatorFactory
fixing
> src/java.base/share/classes/java/util/random/package-info.java line 140:
>
>> 138: *
>> 139: * For applications with no special requirements,
>> 140: * "L64X128MixRandom" has a good balance among speed, space,
>
> The documentation assumes that the `jdk.random` module is present in the JDK
> image. Perhaps we need to spit the specifics to `jdk.random`?
But jdk.random isn't really a public API.
> src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line
> 1211:
>
>> 1209: Udiff = -Udiff;
>> 1210: U2 = U1;
>> 1211: U1 -= Udiff;
>
> Updated `U1` never used (recommend running the code through a checker e.g.
> use IntelliJ)
I noticed that before. I think it's a symmetry thing - will check with Guy.
> src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line
> 1157:
>
>> 1155: /*
>> 1156: * The tables themselves, as well as a number of associated
>> parameters, are
>> 1157: * defined in class java.util.DoubleZigguratTables, which is
>> automatically
>
> `DoubleZigguratTables` is an inner class of `RandomSupport`
Late change fixing.
> src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line
> 2895:
>
>> 2893: * distribution: 0.0330
>> 2894: */
>> 2895: static class DoubleZigguratTables {
>
> make `final`
fixing
> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line
> 167:
>
>> 165: * Return the properties map for the specified provider.
>> 166: *
>> 167: * @param provider provider to locate.
>
> Method has no such parameter
Fixing
-
PR: https://git.openjdk.java.net/jdk/pull/1273
RFR: 8243559: Remove root certificates with 1024-bit keys
This change removes five root certificates with 1024-bit RSA public keys from the system-wide `cacerts` keystore. These are older VeriSign and Thawte root CA certificates which are no longer necessary to retain and should have minimal compatibility risk if removed. See the CSR for more details: https://bugs.openjdk.java.net/browse/JDK-8256502 - Commit messages: - 8256502: Remove root certificates with 1024-bit keys Changes: https://git.openjdk.java.net/jdk/pull/1387/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1387&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8243559 Stats: 140 lines in 6 files changed: 0 ins; 138 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1387.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1387/head:pull/1387 PR: https://git.openjdk.java.net/jdk/pull/1387
Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v3]
On Tue, 17 Nov 2020 21:22:28 GMT, Paul Sandoz wrote:
>> Jim Laskey has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 40 commits:
>>
>> - Merge branch 'master' into 8248862
>> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>
>>Update package-info.java
>> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>
>>Updated RandomGeneratorFactory javadoc.
>> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>
>>Updated documentation for RandomGeneratorFactory.
>> - Merge branch 'master' into 8248862
>> - Merge branch 'master' into 8248862
>> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>
>>Move RandomGeneratorProperty
>> - Merge branch 'master' into 8248862
>> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>
>>Clear up javadoc
>> - 8248862; Implement Enhanced Pseudo-Random Number Generators
>>
>>remove RandomGeneratorProperty from API
>> - ... and 30 more:
>> https://git.openjdk.java.net/jdk/compare/f7517386...6fe94c68
>
> src/java.base/share/classes/java/util/Random.java line 592:
>
>> 590:
>> 591: @Override
>> 592: public Spliterator.OfInt makeIntsSpliterator(long index, long
>> fence, int origin, int bound) {
>
> Unsure if this and the other two methods are intended to be public or not,
> since they are at the end of the class and override methods of a module
> private class. In principle there is nothing wrong with such `Spliterator`
> factories, but wonder if they are really needed given the `Stream` returning
> methods. The arrangement of classes makes it awkward to hide these methods.
Re the properties general comment: I moved properties to RandomSupport based on
the notion that the SPI work with come later.
Re makeIntsSpliterator: These methods aren't exposed in the java.util.Random
API I guess no harm done. The only solution I can think of is to create an
intermediate implementor, but that leaves the methods exposed as well.
> src/java.base/share/classes/java/util/SplittableRandom.java line 171:
>
>> 169: * RandomGenerator properties.
>> 170: */
>> 171: static Map getProperties() {
>
> With records exiting preview in 16 this map of properties could i think be
> represented as a record instance, with better type safety, where
> `RandomSupport.RandomGeneratorProperty` enum values become typed fields
> declared on the record class. Something to consider after integration perhaps?
Yes.
> src/java.base/share/classes/java/util/SplittableRandom.java line 211:
>
>> 209: *
>> http://zimbry.blogspot.com/2011/09/better-bit-mixing-improving-on.html
>> 210: */
>> 211: private static long mix64(long z) {
>
> Usages be replaced with calls to `RandomSupport.mixStafford13`?
We were careful to not change the sequences (from fixed seed) generated by
existing prngs. This was an edge case.
> src/java.base/share/classes/module-info.java line 250:
>
>> 248: exports jdk.internal.util.xml.impl to
>> 249: jdk.jfr;
>> 250: exports jdk.internal.util.random;
>
> Unqualified export, should this be `to jdk.random`?
I guess you are right. Until we have a defined SPI we should restrict.
-
PR: https://git.openjdk.java.net/jdk/pull/1273
Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
Rémi, > On Nov 21, 2020, at 8:03 AM, Remi Forax wrote: > > Ok, i've taking the time to read some literature about random generators > because for me the Mersenne Twister was still the king. > > The current API proposed as clearly two levels, you have the user level and > the implementation level, at least the implementation level should seen as a > SPI Yes, We agree. It was decided that we work on the SPI separately from the original JEP. IMHO the implementation issues are too complex for a single JEP. So, the goal is to release the user level now, and refine the SPI at a later date. Only RandomGenerator (with descendant interfaces) and RandomGeneratorFactory will be public facing in the first release. > > RandomGenerator is the user facing API, for me it should be the sole > interface exposed by the API, the others (leap, arbitrary leap and split) > should be optional methods. Fair enough, but if your task requires leapable, you might be disappointed when you get an UnsupportedOperationException invoking leap. I personally like the "to the quick" ability of using LeapableGenerator for narrowing down the search. LeapableGenerator leapable = LeapableGenerator.all().findFirst().orElseThrow(); Open for discussion. > > In term of factory methods, we should have user driven methods: > - getDefaultGenerator() that currently returns a L64X128MixRandom and can be > changed in the future > - getFastGenerator() that currently returns a Xoroshiro128PlusPlus and can be > changed in the future > - getDefault[Splitable|Leapable|etc]Generator that returns a default > generator with the methods splits|leaps|etc defined > - of / getByName that returns a specific generator by its name (but mov ed in > a SPI class) I'm concerned that the "can be changed in the future" aspect of your default methods will create a false reliance. We sort of have default now with the java.util.Random class. If we were to change the underpinnings of Random all heck would break loose. We already ran into that aspect during testing - tests that relied on sequences from fixed seeds. We try to discourage the use of 'of', but there is a class of user (machine learning for example) that wants to be able to specify exactly. Often, choosing a specific fast prng for testing and then a more sophisticated one for production. The main purpose for RandomGenerator is swapability. > > The example in the documentation should use getDefaultGenerator() and not > of() to avoid the problem all the programming languages currently have by > having over-specified that the default generator is a Mersenne Twister. I have a problem with this as well. It would make it difficult to deprecate java.util.Random. > > All methods that returns a stream of the available implementations should be > moved in the SPI package. Open for discussion. > > Rémi > Cheers, -- Jim > --- > An honest question, > why do we need so many interfaces for the different categories of > RandomGenerator ? > > My fear is that we are encoding the state of our knowledge of the different > kinds of random generators now so it will not be pretty in the future when > new categories of random generator are discovered/invented. > If we can take example of the past to predict the future, 20 years ago, what > should have been the hierarchy at that time. > Is it not reasonable to think that we will need new kinds of random generator > in the future ? > > I wonder if it's not better to have one interface and several optional > methods like we have with the collections, it means that we are loosing the > possibilities to precisely type a method that only works with a precise type > of generator but it will be more future proof. > > Rémi > > - Mail original - >> De: "Jim Laskey" >> À: "core-libs-dev" , "security-dev" >> >> Envoyé: Mercredi 18 Novembre 2020 14:52:56 >> Objet: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators > >> This PR is to introduce a new random number API for the JDK. The primary API >> is >> found in RandomGenerator and RandomGeneratorFactory. Further description can >> be >> found in the JEP https://openjdk.java.net/jeps/356 . >> >> javadoc can be found at >> http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html >> >> old PR: https://github.com/openjdk/jdk/pull/1273 >> >> - >> >> Commit messages: >> - 8248862: Implement Enhanced Pseudo-Random Number Generators >> - 8248862: Implement Enhanced Pseudo-Random Number Generators >> - 8248862: Implement Enhanced Pseudo-Random Number Generators >> - 8248862: Implement Enhanced Pseudo-Random Number Generators >> - 8248862: Implement Enhanced Pseudo-Random Number Generators >> - 8248862; Implement Enhanced Pseudo-Random Number Generators >> - 8248862: Implement Enhanced Pseudo-Random Number Generators >> - 8248862: Implement Enhanced Pseudo-Random Number Generators >> - 8248862: Impleme
Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v3]
[Sorry it took so long. Have been on break.] From Guy: Thanks for the forward. Here are my thoughts: Good question from Rémi. If we consider PRNGs to have started at about the time of von Neumann, circa 1946, then I would say that we have been inventing a new category about once every 25 years or so: jumpable, multi-level jumpable, cryptographically secure, splittable. Twenty years ago we would just have one or more levels of jumping/leaping. I think SecureRandom appeared in 2002 (in J2SE 1.4), and the first version of SplittableRandom was in 2014. So I could be wrong, but I really don’t expect to have to add any more interfaces in the next decade or two. I think we will get more benefit from the better type checking than we would get with optional methods. —Guy > On Nov 17, 2020, at 7:18 PM, Remi Forax wrote: > > An honest question, > why do we need so many interfaces for the different categories of > RandomGenerator ? > > My fear is that we are encoding the state of our knowledge of the different > kinds of random generators now so it will not be pretty in the future when > new categories of random generator are discovered/invented. > If we can take example of the past to predict the future, 20 years ago, what > should have been the hierarchy at that time. > Is it not reasonable to think that we will need new kinds of random generator > in the future ? > > I wonder if it's not better to have one interface and several optional > methods like we have with the collections, it means that we are loosing the > possibilities to precisely type a method that only works with a precise type > of generator but it will be more future proof. > > Rémi > > - Mail original - >> De: "Jim Laskey" >> À: "build-dev" , "core-libs-dev" >> , >> security-dev@openjdk.java.net >> Envoyé: Mardi 17 Novembre 2020 23:21:18 >> Objet: Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators >> [v3] > >>> This PR is to introduce a new random number API for the JDK. The primary >>> API is >>> found in RandomGenerator and RandomGeneratorFactory. Further description >>> can be >>> found in the JEP https://openjdk.java.net/jeps/356 . >> >> Jim Laskey has updated the pull request with a new target base due to a >> merge or >> a rebase. The pull request now contains 40 commits: >> >> - Merge branch 'master' into 8248862 >> - 8248862: Implement Enhanced Pseudo-Random Number Generators >> >> Update package-info.java >> - 8248862: Implement Enhanced Pseudo-Random Number Generators >> >> Updated RandomGeneratorFactory javadoc. >> - 8248862: Implement Enhanced Pseudo-Random Number Generators >> >> Updated documentation for RandomGeneratorFactory. >> - Merge branch 'master' into 8248862 >> - Merge branch 'master' into 8248862 >> - 8248862: Implement Enhanced Pseudo-Random Number Generators >> >> Move RandomGeneratorProperty >> - Merge branch 'master' into 8248862 >> - 8248862: Implement Enhanced Pseudo-Random Number Generators >> >> Clear up javadoc >> - 8248862; Implement Enhanced Pseudo-Random Number Generators >> >> remove RandomGeneratorProperty from API >> - ... and 30 more: >> https://git.openjdk.java.net/jdk/compare/f7517386...6fe94c68 >> >> - >> >> Changes: https://git.openjdk.java.net/jdk/pull/1273/files >> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1273&range=02 >> Stats: 14891 lines in 31 files changed: 0 ins; 3704 del; 77 mod >> Patch: https://git.openjdk.java.net/jdk/pull/1273.diff >> Fetch: git fetch https://git.openjdk.java.net/jdk pull/1273/head:pull/1273 >> >> PR: https://git.openjdk.java.net/jdk/pull/1273
Integrated: 8254231: Implementation of Foreign Linker API (Incubator)
On Tue, 13 Oct 2020 13:08:14 GMT, Maurizio Cimadamore wrote: > This patch contains the changes associated with the first incubation round of > the foreign linker access API incubation > (see JEP 389 [1]). This work is meant to sit on top of the foreign memory > access support (see JEP 393 [2] and associated pull request [3]). > > The main goal of this API is to provide a way to call native functions from > Java code without the need of intermediate JNI glue code. In order to do > this, native calls are modeled through the MethodHandle API. I suggest > reading the writeup [4] I put together few weeks ago, which illustrates what > the foreign linker support is, and how it should be used by clients. > > Disclaimer: the pull request mechanism isn't great at managing *dependent* > reviews. For this reasons, I'm attaching a webrev which contains only the > differences between this PR and the memory access PR. I will be periodically > uploading new webrevs, as new iterations come out, to try and make the life > of reviewers as simple as possible. > > A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects > of all the hotspot changes you see here, and without their help, the foreign > linker support wouldn't be what it is today. As usual, a big thank to Paul > Sandoz, who provided many insights (often by trying the bits first hand). > > Thanks > Maurizio > > Webrev: > http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev > > Javadoc: > > http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html > > Specdiff (relative to [3]): > > http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html > > CSR: > > https://bugs.openjdk.java.net/browse/JDK-8254232 > > > > ### API Changes > > The API changes are actually rather slim: > > * `LibraryLookup` > * This class allows clients to lookup symbols in native libraries; the > interface is fairly simple; you can load a library by name, or absolute path, > and then lookup symbols on that library. > * `FunctionDescriptor` > * This is an abstraction that is very similar, in spirit, to `MethodType`; > it is, at its core, an aggregate of memory layouts for the function > arguments/return type. A function descriptor is used to describe the > signature of a native function. > * `CLinker` > * This is the real star of the show. A `CLinker` has two main methods: > `downcallHandle` and `upcallStub`; the first takes a native symbol (as > obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and > returns a `MethodHandle` instance which can be used to call the target native > symbol. The second takes an existing method handle, and a > `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a > code stub allocated by the VM which acts as a trampoline from native code to > the user-provided method handle. This is very useful for implementing upcalls. >* This class also contains the various layout constants that should be > used by clients when describing native signatures (e.g. `C_LONG` and > friends); these layouts contain additional ABI classfication information (in > the form of layout attributes) which is used by the runtime to *infer* how > Java arguments should be shuffled for the native call to take place. > * Finally, this class provides some helper functions e.g. so that clients > can convert Java strings into C strings and back. > * `NativeScope` > * This is an helper class which allows clients to group together logically > related allocations; that is, rather than allocating separate memory segments > using separate *try-with-resource* constructs, a `NativeScope` allows clients > to use a _single_ block, and allocate all the required segments there. This > is not only an usability boost, but also a performance boost, since not all > allocation requests will be turned into `malloc` calls. > * `MemorySegment` > * Only one method added here - namely `handoff(NativeScope)` which allows a > segment to be transferred onto an existing native scope. > > ### Safety > > The foreign linker API is intrinsically unsafe; many things can go wrong when > requesting a native method handle. For instance, the description of the > native signature might be wrong (e.g. have too many arguments) - and the > runtime has, in the general case, no way to detect such mismatches. For these > reasons, obtaining a `CLinker` instance is a *restricted* operation, which > can be enabled by specifying the usual JDK property > `-Dforeign.restricted=permit` (as it's the case for other restricted method > in the foreign memory API). > > ### Implementation changes > > The Java changes associated with `LibraryLookup` are relative > straightforward; the only interesting thing to note here is that library > loading does _not_ depend on class loaders, so `LibraryLookup` is not subject > to the same restricti
