On Thu, 25 Jul 2024 10:58:42 GMT, Jorn Vernee wrote:
> We are seeing some failures of this test in our CI, particularly on Windows
> machines, which are known to starve out certain threads.
>
> To make sure the compiler threads get a chance to work, I've added `-Xbatch`
> to the flags with
On Mon, 15 Jul 2024 16:30:11 GMT, Maurizio Cimadamore
wrote:
> * there is some issue involving segment access with `int` induction variable
> which we should investigate separately
This issue is tracked here:
https://bugs.openjdk.org/browse/JDK-8336759
-
PR Comment:
On Wed, 17 Jul 2024 15:19:18 GMT, Jorn Vernee wrote:
>> This PR limits the number of cases in which we deoptimize frames when
>> closing a shared Arena. The initial intent of this was to improve the
>> performance of shared arena closure in cases where a lot of threads are
>> accessing and
On Mon, 15 Jul 2024 17:00:24 GMT, Rémi Forax wrote:
> Even if the int vs long issue is fixed for this case, i think we should
> recommand to call `withInvokeExactBehavior()` after creating any VarHandle so
> all the auto-conversions are treated as runtime errors.
>
> This is what i do with my
On Mon, 15 Jul 2024 16:35:26 GMT, Uwe Schindler wrote:
> So +1 to merge this and hopefully backport it at least to 21?
Backport to 21 is difficult, given the handshake code there is different (and,
FFM is preview there). But, might be more possible for 22. I have notified
Roland re. the `int`
On Mon, 15 Jul 2024 14:02:27 GMT, Maurizio Cimadamore
wrote:
> So, that means that `arrayElementVarHandle` is ~4x faster than memory
> segment? Isn't that a bit odd?
I did some more analyis of the benchmark. I first eliminated the closing
thread, and started with two simple benc
On Mon, 15 Jul 2024 13:49:57 GMT, Jorn Vernee wrote:
> > > Even with `arrayElementVarHandle` it's about the same
> >
> >
> > This is very odd, and I don't have a good explanation as to why that is the
> > case. What does the baseline (confined arena) look like for
> > `arrayElementVarHandle`
On Fri, 17 May 2024 13:38:25 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>>
ms, such as
> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>
> Some changes were required in the package-info javadoc for
> `java.lang.foreign`, to reflect the changes in the command line flags
> described above.
Maurizio Cimadamore has updated the
On Mon, 15 Jul 2024 12:47:30 GMT, Jorn Vernee wrote:
> Even with `arrayElementVarHandle` it's about the same
This is very odd, and I don't have a good explanation as to why that is the
case. What does the baseline (confined arena) look like for
`arrayElementVarHandle` ?
-
PR
On Mon, 15 Jul 2024 12:34:37 GMT, Jorn Vernee wrote:
> This is the baseline if I change `closing` to use a confined arena:
>
> ```
> BenchmarkMode Cnt ScoreError
> Units
> ConcurrentClose.sharedClose avgt 10 8.089 ±
On Mon, 15 Jul 2024 12:13:23 GMT, Maurizio Cimadamore
wrote:
> > I also tried using `MethodHandles::arrayElementGetter` for the access, but
> > the numbers I got were pretty much the same:
>
> This is quite strange, as the code involved should be quite similar to those
>
On Mon, 15 Jul 2024 12:10:02 GMT, Maurizio Cimadamore
wrote:
> I also tried using `MethodHandles::arrayElementGetter` for the access, but
> the numbers I got were pretty much the same:
This is quite strange, as the code involved should be quite similar to those
with memory segments (e.
On Mon, 15 Jul 2024 12:00:31 GMT, Maurizio Cimadamore
wrote:
> When I remove the `has_scoped_access()` check before the deopt, I expect the
> `otherAccess` thread to be affected, but the effect isn't nearly as big as
> with the FFM thread. I think this is likely due to the `ot
On Mon, 15 Jul 2024 11:47:43 GMT, Jorn Vernee wrote:
> I've update the benchmark to run with 3 separate threads: 1 thread that is
> just creating and closing shared arenas in a loop, 1 that is accessing memory
> using the FFM API, and 1 that is accessing a `byte[]`.
>
> Current:
>
> ```
>
On Mon, 15 Jul 2024 09:11:53 GMT, Maurizio Cimadamore
wrote:
> avoiding unnecessary deoptimization (as in this PR) is not going to help much,
What would definitively help is to somehow reduce the number of threads to
handshake when calling close - e.g. have an arena that is shared but o
On Mon, 15 Jul 2024 09:02:29 GMT, Uwe Schindler wrote:
> One only closing arenas, another set that consumes scoped memory and a third
> group doing totally unrelated stuff.
Exactly. My general feeling is that the cost of handshaking a thread dominates
everything else, so doing improvements
On Fri, 12 Jul 2024 20:59:26 GMT, Jorn Vernee wrote:
>> This PR limits the number of cases in which we deoptimize frames when
>> closing a shared Arena. The initial intent of this was to improve the
>> performance of shared arena closure in cases where a lot of threads are
>> accessing and
On Sun, 14 Jul 2024 11:01:58 GMT, Uwe Schindler wrote:
> I have one problem with the benchmark: I think it is not measuring the whole
> setup in a way that is our workload: The basic problem is that we don't want
> to deoptimize threads which are not related to MemorySegments. So basically,
>
>
> The commit being backported was authored by Hannes Greule on 22 Jun 2024 and
> was reviewed by Maurizio Cimadamore.
>
> Thanks!
Thanks!
-
PR Comment: https://git.openjdk.org/jdk/pull/19846#issuecomment-2186031401
On Fri, 21 Jun 2024 07:40:31 GMT, Hannes Greule wrote:
> Addresses two simple problems regarding javadocs in the FFM API.
Yes, javadoc fixes such as this can be backported. Just use the `/backport`
command:
On Fri, 21 Jun 2024 07:40:31 GMT, Hannes Greule wrote:
> Addresses two simple problems regarding javadocs in the FFM API.
Thanks! Should we backport to 23?
-
Marked as reviewed by mcimadamore (Reviewer).
PR Review:
On Thu, 20 Jun 2024 11:38:26 GMT, Jorn Vernee wrote:
>> src/jdk.jdeps/share/man/jnativescan.1 line 121:
>>
>>> 119: .TP
>>> 120: \f[V]--release\f[R] \f[I]version\f[R]
>>> 121: Used to specify the Java SE release that specifies the set of
>>> restricted
>>
>> In principle, the release could
On Wed, 19 Jun 2024 21:22:10 GMT, Maurizio Cimadamore
wrote:
>> Jorn Vernee has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - review comments
>> - add man page
>
> src/jdk.jdeps/share/man/jnativesca
On Wed, 19 Jun 2024 21:16:46 GMT, Jorn Vernee wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted`.
>>
>> The tool
On Wed, 19 Jun 2024 19:59:19 GMT, Jorn Vernee wrote:
>> src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/JNativeScanTask.java
>> line 76:
>>
>>> 74: URI location = m.reference().location().orElseThrow();
>>> 75: Path path = Path.of(location);
>>> 76:
On Wed, 19 Jun 2024 18:00:37 GMT, Jorn Vernee wrote:
>> src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/JNativeScanTask.java
>> line 81:
>>
>>> 79:
>>> 80: Map>>
>>> allRestrictedMethods;
>>> 81: try(ClassResolver classesToScan =
>>>
On Wed, 19 Jun 2024 17:25:07 GMT, Jorn Vernee wrote:
>> src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/RestrictedMethodFinder.java
>> line 43:
>>
>>> 41: import java.util.*;
>>> 42:
>>> 43: class RestrictedMethodFinder {
>>
>> The name of this is a bit confusing as this class looks
On Tue, 18 Jun 2024 16:30:37 GMT, Jorn Vernee wrote:
> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
> code that accesses native functionality. Currently this includes `native`
> method declarations, and methods marked with `@Restricted`.
>
> The tool accepts a
On Tue, 18 Jun 2024 16:30:37 GMT, Jorn Vernee wrote:
> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
> code that accesses native functionality. Currently this includes `native`
> method declarations, and methods marked with `@Restricted`.
>
> The tool accepts a
On Tue, 18 Jun 2024 16:30:37 GMT, Jorn Vernee wrote:
> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
> code that accesses native functionality. Currently this includes `native`
> method declarations, and methods marked with `@Restricted`.
>
> The tool accepts a
On Tue, 18 Jun 2024 16:30:37 GMT, Jorn Vernee wrote:
> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
> code that accesses native functionality. Currently this includes `native`
> method declarations, and methods marked with `@Restricted`.
>
> The tool accepts a
On Tue, 18 Jun 2024 16:30:37 GMT, Jorn Vernee wrote:
> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
> code that accesses native functionality. Currently this includes `native`
> method declarations, and methods marked with `@Restricted`.
>
> The tool accepts a
On Tue, 18 Jun 2024 16:30:37 GMT, Jorn Vernee wrote:
> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
> code that accesses native functionality. Currently this includes `native`
> method declarations, and methods marked with `@Restricted`.
>
> The tool accepts a
On Tue, 18 Jun 2024 16:30:37 GMT, Jorn Vernee wrote:
> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
> code that accesses native functionality. Currently this includes `native`
> method declarations, and methods marked with `@Restricted`.
>
> The tool accepts a
On Tue, 11 Jun 2024 12:22:24 GMT, Per Minborg wrote:
>> This PR proposes to explicitly state that returned segments form the
>> `asSlice` and `reinterpret` method share memory regions with `this` memory
>> segment.
>>
>> Note: The term "subset" means a true subset or the same set.
>
> Per
On Mon, 10 Jun 2024 15:12:59 GMT, Per Minborg wrote:
> > Note that `asSlice` methods also lacks a similar guarantee on read-only
> > (but the impl works fine there)
>
> Even though not mentioned in the original issue, we could add documentation
> for this here as well. Or maybe via
>
On Mon, 10 Jun 2024 14:59:42 GMT, Per Minborg wrote:
>> This PR proposes to retain the read-only state when any of the
>> `MemorySegment::reinterpret` methods is called.
>>
>> Previously, the read-only state was lost and the returned `MemorySegment`
>> was always writable regardless of the
On Mon, 10 Jun 2024 13:18:43 GMT, Per Minborg wrote:
> This PR proposes to retain the read-only state when any of the
> `MemorySegment::reinterpret` methods is called.
>
> Previously, the read-only state was lost and the returned `MemorySegment` was
> always writable regardless of the
On Mon, 10 Jun 2024 08:30:59 GMT, Claes Redestad wrote:
> Trivially removing the a leftover, unused `ClassValue` from
> `java.lang.invoke.VarHandle`
Good catch!
-
Marked as reviewed by mcimadamore (Reviewer).
PR Review:
On Thu, 30 May 2024 16:15:22 GMT, Maurizio Cimadamore
wrote:
> This PR restores a var handle cache in `Utils::makeSegmentViewVarHandle`. The
> cache was moved to `ValueLayouts::varHandle` as part of
> [pull/19251](https://git.openjdk.org/jdk/pull/19251), on the basis that w
On Fri, 31 May 2024 16:26:50 GMT, Per Minborg wrote:
> Would it make sense to add some tests that assert, `VarHandle` objects get
> cached?
We can't - at least not easily. As explained in the new comment, the var
handles cached by this method are "raw" and always adapted by some other API.
ifferent picture - w/o any cache in
> `Utils` the test end up allocating 8963 var handle instances (instead of just
> 4), in each of the 4 runs the test includes. While this is admittedly a
> stress test, it seems nice to restore the level of sharing we had before
> [pull/19251](http
ifferent picture - w/o any cache in
> `Utils` the test end up allocating 8963 var handle instances (instead of just
> 4), in each of the 4 runs the test includes. While this is admittedly a
> stress test, it seems nice to restore the level of sharing we had before
> [pull/19251](http
On Fri, 31 May 2024 16:15:12 GMT, Maurizio Cimadamore
wrote:
>> This PR restores a var handle cache in `Utils::makeSegmentViewVarHandle`.
>> The cache was moved to `ValueLayouts::varHandle` as part of
>> [pull/19251](https://git.openjdk.org/jdk/pull/19251), on the basi
On Fri, 24 May 2024 16:17:41 GMT, Adam Sotona wrote:
>> ClassFile API `jdk.internal.classfile.verifier.VerifierImpl` performed only
>> bytecode-level class verification.
>> This patch adds `jdk.internal.classfile.verifier.ParserVerifier` with
>> additional class checks inspired by
>>
On Thu, 30 May 2024 17:04:44 GMT, Jorn Vernee wrote:
> I suggest leaving a comment to document which cases this cache is trying to
> address. I think that's mainly cases where the same ValueLayout is created
> many times in different places (instead of the same layout being reused, for
>
On Thu, 30 May 2024 16:15:22 GMT, Maurizio Cimadamore
wrote:
> This PR restores a var handle cache in `Utils::makeSegmentViewVarHandle`. The
> cache was moved to `ValueLayouts::varHandle` as part of
> [pull/19251](https://git.openjdk.org/jdk/pull/19251), on the basis that w
This PR restores a var handle cache in `Utils::makeSegmentViewVarHandle`. The
cache was moved to `ValueLayouts::varHandle` as part of
[pull/19251](https://git.openjdk.org/jdk/pull/19251), on the basis that we want
to optimize the common case like:
ValueLayout layout = ...
On Wed, 29 May 2024 15:35:41 GMT, Alan Bateman wrote:
>> JEP 481 proposes Scoped Values to continue to preview in JDK 23 with one
>> change. The type of the operation parameter of the callWhere method is
>> changed to a new functional interface to avoid having the API throw
>> Exception. With
On Thu, 16 May 2024 14:11:47 GMT, Maurizio Cimadamore
wrote:
> > > Do we have any performance tests available to see if there are any
> > > potential impacts?
> >
> >
> > I've run all micro benchmarks whose name match `LoopOver*`. No regression
>
On Wed, 15 May 2024 15:43:45 GMT, Maurizio Cimadamore
wrote:
> When creating a nested memory access var handle, we ensure that the segment
> is accessed at the correct alignment for the root layout being accessed. But
> we do not ensure that the segment has at least the size of the
On Wed, 22 May 2024 21:03:57 GMT, Jorn Vernee wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix typo in javadoc
>
> src/java.base/share/classes/java/lang/invoke/X-VarH
adaptation, by taking a more basic var handle of the form:
>
>
> (MemorySegment, long /* offset */)
>
>
> And then injecting the result of the index multiplication into `offset`. As
> such, we can't add an enclosing layout check inside the var handle returned
> by `VarHandle
On Tue, 21 May 2024 07:20:05 GMT, Alan Bateman wrote:
> > Have you looked into / thought about how this will work for jpackaged apps
> > ? I suspect that both the existing FFM usage and this will be options the
> > application packager will need to supply when building the jpackaged app -
> >
On Mon, 20 May 2024 16:42:19 GMT, Paul Sandoz wrote:
> some additional overhead e.g.,
>
> ```
> if (derefAdapters.length == 0) {
> // insert align check for the root layout on the initial MS +
> offset
> List> coordinateTypes = handle.coordinateTypes();
>
On Mon, 20 May 2024 09:45:31 GMT, Maurizio Cimadamore
wrote:
> > Separately, we might be missing a few long argument accepting guard methods
> > for simpler cases as I suspect they are still focused more on int index
> > types.
>
> Not sure I understand what guard m
On Fri, 17 May 2024 23:42:17 GMT, Paul Sandoz wrote:
> Separately, we might be missing a few long argument accepting guard methods
> for simpler cases as I suspect they are still focused more on int index types.
Not sure I understand what guard methods you are referring to here?
-
On Fri, 17 May 2024 15:54:04 GMT, Paul Sandoz wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix copyrights
>
> src/java.base/share/classes/java/lang/foreign/MemoryL
ms, such as
> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>
> Some changes were required in the package-info javadoc for
> `java.lang.foreign`, to reflect the changes in the command line flags
> described above.
Maurizio Cimadamore has updated the pul
On Thu, 16 May 2024 18:39:57 GMT, Alan Bateman wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add note on --illegal-native-access default value in the launcher help
>
> sr
adaptation, by taking a more basic var handle of the form:
>
>
> (MemorySegment, long /* offset */)
>
>
> And then injecting the result of the index multiplication into `offset`. As
> such, we can't add an enclosing layout check inside the var handle returned
> by `VarHandle
On Thu, 16 May 2024 14:34:41 GMT, Maurizio Cimadamore
wrote:
>> When creating a nested memory access var handle, we ensure that the segment
>> is accessed at the correct alignment for the root layout being accessed. But
>> we do not ensure that the segment has
On Thu, 16 May 2024 13:55:15 GMT, Maurizio Cimadamore
wrote:
> > Do we have any performance tests available to see if there are any
> > potential impacts?
>
> I've run all micro benchmarks whose name match `LoopOver*`. No regression was
> found. Few benchmar
On Thu, 16 May 2024 11:18:18 GMT, Per Minborg wrote:
> Do we have any performance tests available to see if there are any potential
> impacts?
I've run all micro benchmarks whose name match `LoopOver*`. No regression was
found. Few benchmarks seems a tad faster, but the percentages are so
ms, such as
> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>
> Some changes were required in the package-info javadoc for
> `java.lang.foreign`, to reflect the changes in the command line flags
> described above.
Maurizio Cimadamore has updated the pull
On Thu, 16 May 2024 11:55:35 GMT, Jaikiran Pai wrote:
>> We already do, see
>> https://github.com/openjdk/jdk/pull/19213/files/1c45e5d56c429205ab8185481bc1044a86ab3bc6#diff-d05029afe6aed86f860a10901114402f1f6af4fe1e4b46d883141ab1d2a527b8R582
>
> This is slightly different from what we do in the
On Thu, 16 May 2024 11:42:48 GMT, Jaikiran Pai wrote:
> Hello Maurizio, in the current mainline, we have code in `LauncherHelper`
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/launcher/LauncherHelper.java#L636
> where we enable native access to all unnamed
On Thu, 16 May 2024 10:54:15 GMT, Maurizio Cimadamore
wrote:
>> When creating a nested memory access var handle, we ensure that the segment
>> is accessed at the correct alignment for the root layout being accessed. But
>> we do not ensure that the segment has
On Wed, 15 May 2024 15:43:45 GMT, Maurizio Cimadamore
wrote:
> When creating a nested memory access var handle, we ensure that the segment
> is accessed at the correct alignment for the root layout being accessed. But
> we do not ensure that the segment has at least the size of the
When creating a nested memory access var handle, we ensure that the segment is
accessed at the correct alignment for the root layout being accessed. But we do
not ensure that the segment has at least the size of the accessed root layout.
Example:
MemoryLayout LAYOUT = sequenceLayout(2,
On Thu, 16 May 2024 07:14:53 GMT, Alan Bateman wrote:
>> This is the implementation changes for JEP 471.
>>
>> The methods in sun.misc.Unsafe for on-heap and off-heap access are
>> deprecated for removal. This means a removal warning at compile time. No
>> methods have been removed. A
ms, such as
> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>
> Some changes were required in the package-info javadoc for
> `java.lang.foreign`, to reflect the changes in the command line flags
> described above.
Maurizio Cimadamore has updated the pul
On Thu, 9 May 2024 15:00:35 GMT, Maurizio Cimadamore
wrote:
> Consider this layout:
>
>
> MemoryLayout SEQ = MemoryLayout.sequenceLayout(5,
> MemoryLayout.sequenceLayout(10, JAVA_INT));
>
>
> And the corresponding offset handle:
>
>
ms, such as
> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>
> Some changes were required in the package-info javadoc for
> `java.lang.foreign`, to reflect the changes in the command line flags
> described above.
Maurizio Cimadamore has updated the pu
On Wed, 15 May 2024 06:15:35 GMT, Alan Bateman wrote:
>> So my recollection/understanding is that we use this mechanism to convert
>> module-related `--` flags passed to the VM into system properties that the
>> Java code can then read, but we set them up such that you are not allowed to
>>
On Fri, 10 May 2024 10:06:55 GMT, Alan Bateman wrote:
> This is the implementation changes for JEP 471.
>
> The methods in sun.misc.Unsafe for on-heap and off-heap access are deprecated
> for removal. This means a removal warning at compile time. No methods have
> been removed. A deprecated
On Fri, 10 May 2024 10:06:55 GMT, Alan Bateman wrote:
> This is the implementation changes for JEP 471.
>
> The methods in sun.misc.Unsafe for on-heap and off-heap access are deprecated
> for removal. This means a removal warning at compile time. No methods have
> been removed. A deprecated
On Wed, 15 May 2024 07:55:27 GMT, ExE Boss wrote:
> Note that this line is still not entirely correct, as for code like:
You are correct - the message is however consistent with what written in JEP
472. I'll discuss with @pron
-
PR Review Comment:
On Tue, 14 May 2024 11:42:19 GMT, Adam Sotona wrote:
>> ClassFile API `jdk.internal.classfile.verifier.VerifierImpl` performed only
>> bytecode-level class verification.
>> This patch adds `jdk.internal.classfile.verifier.ParserVerifier` with
>> additional class checks inspired by
>>
ms, such as
> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>
> Some changes were required in the package-info javadoc for
> `java.lang.foreign`, to reflect the changes in the command line flags
> described above.
Maurizio Cimadamore has updated the pull
On Wed, 17 Apr 2024 11:12:37 GMT, Per Minborg wrote:
>> Yes, consider the 3 capture scenarios:
>> | API | Capture frequency | Capture Impact | Code Convenience | Flexibility |
>> |-|---||--|-|
>> | `StableValue.ofMap(map, k -> ...)`
On Tue, 16 Apr 2024 11:47:23 GMT, Per Minborg wrote:
> # Stable Values & Collections (Internal)
>
> ## Summary
> This PR proposes to introduce an internal _Stable Values & Collections_ API,
> which provides immutable value holders where elements are initialized _at
> most once_. Stable Values
On Mon, 13 May 2024 17:15:15 GMT, Maurizio Cimadamore
wrote:
>> Adam Sotona has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - fixed error thrown by VerifierImpl
>> - applied suggested changes
>
On Thu, 9 May 2024 10:11:22 GMT, Adam Sotona wrote:
>> ClassFile API `jdk.internal.classfile.verifier.VerifierImpl` performed only
>> bytecode-level class verification.
>> This patch adds `jdk.internal.classfile.verifier.ParserVerifier` with
>> additional class checks inspired by
>>
:byteOffsetHandle` to actually
> state that the indices will be checked against the "size" of the
> corresponding open path element (this is a new concept that I also have
> defined in the javadoc).
>
> I also added a test for `byteOffsetHandle` as I don't think we had a test for
> tha
ms, such as
> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>
> Some changes were required in the package-info javadoc for
> `java.lang.foreign`, to reflect the changes in the command line flags
> described above.
Maurizio Cimadamore has updated the pul
On Mon, 13 May 2024 11:38:40 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>>
ms, such as
> `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
>
> Some changes were required in the package-info javadoc for
> `java.lang.foreign`, to reflect the changes in the command line flags
> described above.
Maurizio Cimadamore has updated the pull r
This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the
use of JNI in the following ways:
* `System::load` and `System::loadLibrary` are now restricted methods
* `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
* binding a JNI `native` method
On Mon, 13 May 2024 10:42:26 GMT, Maurizio Cimadamore
wrote:
> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
> the use of JNI in the following ways:
>
> * `System::load` and `System::loadLibrary` are now restricted methods
> * `Runtime::loa
On Fri, 10 May 2024 07:57:40 GMT, Alan Bateman wrote:
> In preparation for JEP 471 and JEP 472, provide access to the initial value
> of System.err from JavaLangAccess. The initial value of System.in is already
> exposed to code in java.base with this shared secret.
Marked as reviewed by
On Fri, 10 May 2024 10:58:42 GMT, Alan Bateman wrote:
> There aren't any API or implementations changes in third preview but the JEP
> number/title needs to be bumped for the javadoc page.
Marked as reviewed by mcimadamore (Reviewer).
-
PR Review:
On Tue, 7 May 2024 15:42:23 GMT, Maurizio Cimadamore
wrote:
> This PR fixes an issue that has crept into the FFM API implementation.
>
> From very early stages, the FFM API used to disable the alignment check on
> nested layout elements, in favor of an alignment check agains
On Wed, 8 May 2024 16:39:16 GMT, Maurizio Cimadamore
wrote:
>> This PR fixes an issue that has crept into the FFM API implementation.
>>
>> From very early stages, the FFM API used to disable the alignment check on
>> nested layout elements, in favor of an alignment
:byteOffsetHandle` to actually
> state that the indices will be checked against the "size" of the
> corresponding open path element (this is a new concept that I also have
> defined in the javadoc).
>
> I also added a test for `byteOffsetHandle` as I don't think we had a test for
> tha
:byteOffsetHandle` to actually
> state that the indices will be checked against the "size" of the
> corresponding open path element (this is a new concept that I also have
> defined in the javadoc).
>
> I also added a test for `byteOffsetHandle` as I don't think we had a test for
> tha
:byteOffsetHandle` to actually
> state that the indices will be checked against the "size" of the
> corresponding open path element (this is a new concept that I also have
> defined in the javadoc).
>
> I also added a test for `byteOffsetHandle` as I don't think we had a test for
> tha
On Thu, 9 May 2024 18:26:17 GMT, Maurizio Cimadamore
wrote:
>> Consider this layout:
>>
>>
>> MemoryLayout SEQ = MemoryLayout.sequenceLayout(5,
>> MemoryLayout.sequenceLayout(10, JAVA_INT));
>>
>>
>> And the corresponding off
:byteOffsetHandle` to actually
> state that the indices will be checked against the "size" of the
> corresponding open path element (this is a new concept that I also have
> defined in the javadoc).
>
> I also added a test for `byteOffsetHandle` as I don't think we had a test for
> tha
1 - 100 of 943 matches
Mail list logo
