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
>> sp
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 me
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 me
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: https://git.openjdk.org/jdk/pull/
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
>> `hotspot/
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
>> `hotspot/s
t::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 tes
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 declaratio
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 mcima
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: https://git.openjdk.org/jdk/pull/
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
t::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 tes
t::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 tes
t::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 tes
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
t::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 tes
Consider this layout:
MemoryLayout SEQ = MemoryLayout.sequenceLayout(5,
MemoryLayout.sequenceLayout(10, JAVA_INT));
And the corresponding offset handle:
MethodHandle offsetHandle = SEQ.offsetHandle(PathElement.sequenceLayout(),
PathElement.sequenceLayout());
The resulting meth
> code path affected, no significant difference was found, sign that C2 is
> indeed able to spot (and remove) the redundant alignment check. Note: if we
> know that `aligned_to_N(base)` holds, then it's easy to prove that
> `aligned_to_M(base + offset + index * scale)` hold
On Wed, 8 May 2024 15:32:27 GMT, Maurizio Cimadamore
wrote:
> * `x_handle` is really meant to provide access to a memory segment modelling
> (at least) one struct with layout `POINT_LAYOUT`. As such, the initial
> segment/offset combo should (a) be adequately aligned (acc
> code path affected, no significant difference was found, sign that C2 is
> indeed able to spot (and remove) the redundant alignment check. Note: if we
> know that `aligned_to_N(base)` holds, then it's easy to prove that
> `aligned_to_M(base + offset + index * scale)` hold
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
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 against the memory
>segment base address. The rationale was that the JIT had issue with
>eli
On Thu, 2 May 2024 12:22:23 GMT, Adam Sotona wrote:
>> This patch adds `javap -verify` option to check the class and print obvious
>> verification errors found.
>> Implementation depends on extended Class-File API verification support, so
>> PR #16809 is important to precede.
>> The new `javap`
gt; - Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
>
>Co-authored-by: Maurizio Cimadamore
> <54672762+mcimadam...@users.noreply.github.com>
> - Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
>
>Co-
On Thu, 18 Apr 2024 11:32:13 GMT, Per Minborg wrote:
>> While `SymbolLookup` correctly uses an `Optional` return to denote whether a
>> symbol has been found by the lookup or not (which enables composition of
>> symbol lookups), many clients end up just calling `Optional::get`, or
>> `Optional
On Tue, 16 Apr 2024 10:30:14 GMT, Alan Bateman wrote:
>> Thinking about this some more, would it not be possible to just use the
>> mainMethod directly down in C?
>
> The changes JEP 463 went through many iterations, it was a fine balance of
> avoiding too many transitions and upcalls, and at t
On Thu, 18 Apr 2024 06:34:22 GMT, Jan Lahoda wrote:
>> This is an implementation of JEP JDK-8315129: Module Import Declarations
>> (Preview). Please see the JEP for details:
>> https://bugs.openjdk.org/browse/JDK-8315129
>>
>> It is mostly straightforward - the module imports are parsed, and th
On Tue, 9 Apr 2024 11:34:45 GMT, Maurizio Cimadamore
wrote:
> This PR removes support for the string template feature from the Java
> compiler and the Java SE API, as discussed here:
>
> https://mail.openjdk.org/pipermail/amber-spec-experts/2024-April/004106.html
This pull req
On Tue, 9 Apr 2024 09:28:23 GMT, Jan Lahoda wrote:
>> This is a patch for javac, that adds the Derived Record Creation
>> expressions. The current draft specification for the feature is:
>> https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html
>>
>> The
On Tue, 2 Apr 2024 15:04:40 GMT, Per Minborg wrote:
> This PR proposes to add an internal layout transformer that could be used to
> transform MemoryLayout entities. For example, it would be possible to convert
> a struct layout to use network order ((big-endian) instead of native byte
> order
On Tue, 2 Apr 2024 15:04:40 GMT, Per Minborg wrote:
> This PR proposes to add an internal layout transformer that could be used to
> transform MemoryLayout entities. For example, it would be possible to convert
> a struct layout to use network order ((big-endian) instead of native byte
> order
On Tue, 16 Apr 2024 09:39:02 GMT, Maurizio Cimadamore
wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update JavaDoc
>
> src/java.base/share/classes/java/lang/foreign/MemorySe
On Tue, 16 Apr 2024 07:09:55 GMT, Per Minborg wrote:
> This PR proposes to update the javadocs for `ValueLayout.JAVA_LONG` and
> `ValueLayout.JAVA_DOUBLE` to reflect the changes made in
> https://bugs.openjdk.org/browse/JDK-8326172 (we forgot to update the docs
> when that issue was fixed)
M
On Tue, 16 Apr 2024 07:49:26 GMT, Per Minborg wrote:
>> This PR proposes to add a new method `MemorySegment::maxByteAlignment` that
>> returns the maximum byte alignment of a segment (both heap and native
>> segments).
>>
>> Clients can then use this method to determine if a segment is properl
ge.
>
> Per Minborg has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
>
> Co-authored-by: Maurizio Cimadamore
> <54672762+mcimadam...@users.noreply.gi
On Mon, 15 Apr 2024 14:39:02 GMT, Maurizio Cimadamore
wrote:
>> Per Minborg has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request conta
pMemorySegmentImpl.java
>
>Co-authored-by: Jorn Vernee
> - Update
> src/java.base/share/classes/jdk/internal/foreign/NativeMemorySegmentImpl.java
>
>Co-authored-by: Jorn Vernee
> - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
>
&g
ge.
>
> Per Minborg has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
>
> Co-authored-by: Maurizio Cimadamore
> <54672762+mcimadam...@users.noreply.g
On Mon, 15 Apr 2024 13:17:26 GMT, Per Minborg wrote:
>> test/jdk/java/foreign/TestMemoryAlignment.java line 154:
>>
>>> 152: Arena arena = Arena.ofConfined()) {
>>> 153: var segment =channel.map(FileChannel.MapMode.READ_WRITE,
>>> 0L, 32L, arena);
>>> 154: a
On Mon, 15 Apr 2024 13:05:01 GMT, Per Minborg wrote:
>> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 615:
>>
>>> 613: * the requested byte alignment during native segment allocation)}
>>> 614: *
>>> 615: * The returned alignment is always an even power of
On Mon, 15 Apr 2024 07:50:24 GMT, Per Minborg wrote:
> This PR proposes to add a new method `MemorySegment::maxByteAlignment` that
> returns the maximum byte alignment of a segment (both heap and native
> segments).
>
> Clients can then use this method to determine if a segment is properly
>
On Mon, 15 Apr 2024 07:50:24 GMT, Per Minborg wrote:
> This PR proposes to add a new method `MemorySegment::maxByteAlignment` that
> returns the maximum byte alignment of a segment (both heap and native
> segments).
>
> Clients can then use this method to determine if a segment is properly
>
On Mon, 15 Apr 2024 07:50:24 GMT, Per Minborg wrote:
> This PR proposes to add a new method `MemorySegment::maxByteAlignment` that
> returns the maximum byte alignment of a segment (both heap and native
> segments).
>
> Clients can then use this method to determine if a segment is properly
>
On Mon, 15 Apr 2024 08:21:41 GMT, Per Minborg wrote:
> This PR fixes a typo in the `Linker` documentation.
Marked as reviewed by mcimadamore (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/18781#pullrequestreview-2000556281
On Mon, 15 Apr 2024 08:37:55 GMT, Per Minborg wrote:
>> While `SymbolLookup` correctly uses an `Optional` return to denote whether a
>> symbol has been found by the lookup or not (which enables composition of
>> symbol lookups), many clients end up just calling `Optional::get`, or
>> `Optional
On Mon, 25 Mar 2024 14:56:23 GMT, Per Minborg wrote:
> While `SymbolLookup` correctly uses an `Optional` return to denote whether a
> symbol has been found by the lookup or not (which enables composition of
> symbol lookups), many clients end up just calling `Optional::get`, or
> `Optional::or
On Mon, 25 Mar 2024 14:56:23 GMT, Per Minborg wrote:
> While `SymbolLookup` correctly uses an `Optional` return to denote whether a
> symbol has been found by the lookup or not (which enables composition of
> symbol lookups), many clients end up just calling `Optional::get`, or
> `Optional::or
> This PR removes support for the string template feature from the Java
> compiler and the Java SE API, as discussed here:
>
> https://mail.openjdk.org/pipermail/amber-spec-experts/2024-April/004106.html
Maurizio Cimadamore has updated the pull request incrementally with one
addit
On Thu, 11 Apr 2024 09:12:06 GMT, Jan Lahoda wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix issues in digit classes
>
> test/langtools/jdk/jshell/CompletionSuggestio
On Wed, 10 Apr 2024 15:38:22 GMT, Jorn Vernee wrote:
> Please review this simple cleanup which removes the
> `AbstractLinker::linkerByteOrder` method. It was only used in
> `AixPPC64Linker`, where we know it will always return `ByteOrder.BIG_ENDIAN`
> so we can just replace the call with that.
On Wed, 10 Apr 2024 15:17:19 GMT, Jan Lahoda wrote:
>> Good catch. Since this was tweaked to be a public API as part of the string
>> template feature, I've reverted this code to what it was prior to string
>> template. That is, now this is a private static final constant, with
>> initializer
On Wed, 10 Apr 2024 12:49:11 GMT, Per Minborg wrote:
> This PR proposes to add two overloads `MemorySegment::reinterpretate` to
> allow aligned reinterpretation.
Should we add the full set of overloads? E.g.
reinterpret(arena, cleanup)
reinterpret(size)
reinterpret(size, arena, cleanup)
reinter
On Wed, 10 Apr 2024 15:19:31 GMT, Jorn Vernee wrote:
>> This PR proposes to add two overloads `MemorySegment::reinterpretate` to
>> allow aligned reinterpretation.
>
> test/jdk/java/foreign/TestSegments.java line 396:
>
>> 394: AtomicInteger counter = new AtomicInteger();
>> 395:
On Tue, 9 Apr 2024 13:38:29 GMT, Jan Lahoda wrote:
>> This is an implementation of JEP JDK-8315129: Module Import Declarations
>> (Preview). Please see the JEP for details:
>> https://bugs.openjdk.org/browse/JDK-8315129
>>
>> It is mostly straightforward - the module imports are parsed, and the
On Tue, 9 Apr 2024 23:45:39 GMT, Scott Gibbons wrote:
> Is there any way to disable some of the optimizations C2 will attempt on the
> IR? We need to maintain atomicity, so vectorization shouldn't occur, for
> instance. This seems like a rat-hole that would need constant maintenance as
> C2 op
> This PR removes support for the string template feature from the Java
> compiler and the Java SE API, as discussed here:
>
> https://mail.openjdk.org/pipermail/amber-spec-experts/2024-April/004106.html
Maurizio Cimadamore has updated the pull request incrementally with one
addit
> This PR removes support for the string template feature from the Java
> compiler and the Java SE API, as discussed here:
>
> https://mail.openjdk.org/pipermail/amber-spec-experts/2024-April/004106.html
Maurizio Cimadamore has updated the pull request incrementally with one
addit
On Tue, 9 Apr 2024 20:22:34 GMT, Chen Liang wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Revert StringConcatFactory field to before string template
>
> src/java.base/
> This PR removes support for the string template feature from the Java
> compiler and the Java SE API, as discussed here:
>
> https://mail.openjdk.org/pipermail/amber-spec-experts/2024-April/004106.html
Maurizio Cimadamore has updated the pull request incrementally with one
addit
This PR removes support for the string template feature from the Java compiler
and the Java SE API, as discussed here:
https://mail.openjdk.org/pipermail/amber-spec-experts/2024-April/004106.html
-
Commit messages:
- Drop spurious changes
- Merge branch 'master' into template_remo
On Fri, 5 Apr 2024 02:40:16 GMT, Dean Long wrote:
> That way C2 can do all its usual optimizations, like unrolling,
> vectorization, and redundant store elimination (if it is an on-heap primitive
> array that was just allocated, then there is no need to zero the parts that
> are being "set").
On Fri, 5 Apr 2024 18:28:58 GMT, Jan Lahoda wrote:
>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 4443:
>>
>>> 4441: }
>>> 4442:
>>> 4443: @Override
>>
>> As usual, I suggest to add some brief comment with the shape of the
>> generated code.
>
> Done here:
On Fri, 5 Apr 2024 12:40:22 GMT, Jan Lahoda wrote:
>> This is a patch for javac, that adds the Derived Record Creation
>> expressions. The current draft specification for the feature is:
>> https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html
>>
>> The
On Fri, 5 Apr 2024 12:40:22 GMT, Jan Lahoda wrote:
>> This is a patch for javac, that adds the Derived Record Creation
>> expressions. The current draft specification for the feature is:
>> https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html
>>
>> The
On Fri, 5 Apr 2024 12:40:22 GMT, Jan Lahoda wrote:
>> This is a patch for javac, that adds the Derived Record Creation
>> expressions. The current draft specification for the feature is:
>> https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html
>>
>> The
On Thu, 4 Apr 2024 20:27:36 GMT, Jan Lahoda wrote:
>> src/java.compiler/share/classes/javax/lang/model/element/ElementKind.java
>> line 133:
>>
>>> 131: */
>>> 132:
>>> @PreviewFeature(feature=PreviewFeature.Feature.DERIVED_RECORD_CREATION,
>>> reflective=true)
>>> 133: COMPONENT
On Mon, 18 Mar 2024 17:43:45 GMT, Suchismith Roy wrote:
>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request incremen
On Fri, 22 Mar 2024 19:56:30 GMT, Martin Doerr wrote:
> The symbols get found and the JVM can really call into the
> `libclang.a(libclang.so.16)`. Impressive! (That doesn't mean that jextract is
> working. clang crashes the way we are calling it. Maybe because of a thread
> stack size or other
On Fri, 22 Mar 2024 16:53:58 GMT, Martin Doerr wrote:
> In case of jextract (jdk22 branch), we would then need something like the
> following if we want AIX to behave like the other platforms?
>
> ```
> diff --git a/src/main/java/org/openjdk/jextract/clang/libclang/Index_h.java
> b/src/main/ja
On Fri, 22 Mar 2024 14:53:17 GMT, Martin Doerr wrote:
> Only the Java developer can select the right member.
Right, and I think this problem is isomporphic to the problem we have in Linux
distros of selecting between libclang.so.1 and libclang.so.2.
`System::loadLibrary` cannot do it. So, I th
On Thu, 21 Mar 2024 22:04:28 GMT, Maurizio Cimadamore
wrote:
> (I'm pessimistic)
To summarize: I think that allowing version-specific names (even if surrounded
by parenthesis) in `System::loadLibrary` would be very odd. After all,
`System::loadLibrary` doesn't support versione
On Mon, 18 Mar 2024 17:43:45 GMT, Suchismith Roy wrote:
>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request incremen
On Thu, 21 Mar 2024 09:23:45 GMT, Per Minborg wrote:
> This PR proposes to remove an old optimization check that was incorrect
> making `AbstractMemorySegmentImpl::mismatch` always return `-1` if the source
> and destination segment are the same (disregarding offsets).
Marked as reviewed by mc
On Sat, 16 Mar 2024 22:34:25 GMT, Jorn Vernee wrote:
>> Update the code gen code in CallGeneratorHelper to reflect the latest state
>> of the libTest(Downcall/Upcall)(Stack).c and shared.h files.
>>
>> - The previous code wanted users to pipe stdout into a file. But, since we
>> have 5 files t
On Wed, 6 Mar 2024 21:16:25 GMT, Jan Lahoda wrote:
>> Currently, JDK modules load by the bootstrap and platform ClassLoaders are
>> automatically granted the native access. I am working on an upgrade of JLine
>> inside the `jdk.internal.le` module, and I would like to replace the current
>> na
On Mon, 4 Mar 2024 13:52:13 GMT, Jan Lahoda wrote:
> Currently, JDK modules load by the bootstrap and platform ClassLoaders are
> automatically granted the native access. I am working on an upgrade of JLine
> inside the `jdk.internal.le` module, and I would like to replace the current
> native
On Mon, 26 Feb 2024 19:19:56 GMT, Jorn Vernee wrote:
>> Found the right one:
>> https://github.com/openjdk/jdk/commit/44218b1c9e5daa33557aac9336251cf8398d81eb
>
> Switched back to using the old generator (and removed the newer one):
> https://github.com/openjdk/jdk/pull/18007/commits/fad15a66b6
On Mon, 26 Feb 2024 19:17:56 GMT, Jorn Vernee wrote:
>> This patch changes the alignment for `JAVA_LONG` and `JAVA_DOUBLE` to 8,
>> regardless of the underlying platform. This means that atomic access modes
>> work on memory segments wrapping `long[]` or `double[]`, as they already do
>> when
On Mon, 26 Feb 2024 16:05:51 GMT, Jorn Vernee wrote:
>> This patch changes the alignment for `JAVA_LONG` and `JAVA_DOUBLE` to 8,
>> regardless of the underlying platform. This means that atomic access modes
>> work on memory segments wrapping `long[]` or `double[]`, as they already do
>> when
On Mon, 26 Feb 2024 13:24:11 GMT, Jorn Vernee wrote:
> This patch changes the alignment for `JAVA_LONG` and `JAVA_DOUBLE` to 8,
> regardless of the underlying platform. This means that atomic access modes
> work on memory segments wrapping `long[]` or `double[]`, as they already do
> when usin
On Thu, 1 Feb 2024 12:07:52 GMT, Per Minborg wrote:
> 8325001: Typo in the javadocs for the Arena::ofShared method
Marked as reviewed by mcimadamore (Reviewer).
-
PR Review: https://git.openjdk.org/jdk22/pull/100#pullrequestreview-1869843579
On Fri, 2 Feb 2024 07:41:16 GMT, Per Minborg wrote:
>> This PR proposes to implement `hashCode()` and `equals()` methods for
>> implementations of `PathElement`.
>>
>> In doing so, the previous `PathElementImpl` was removed and replaced in
>> favor of distinct `record` implementations, each re
On Thu, 1 Feb 2024 22:19:26 GMT, Joe Darcy wrote:
>> The restricted javac warning is disabled for java.base, but could be enabled
>> by suppressing the warning in a handful of files.
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
>
On Thu, 1 Feb 2024 20:10:29 GMT, Jorn Vernee wrote:
>> See the JBS issue for an extended problem description.
>>
>> This patch changes the specification and implementation of
>> `MethodHandles::byteArrayViewVarHandle`,
>> `MethodHandles::byteBufferViewVarHandle`, `ByteBuffer::alignedSlice`, an
On Thu, 1 Feb 2024 14:25:24 GMT, Per Minborg wrote:
>> src/java.base/share/classes/jdk/internal/foreign/LayoutPath.java line 454:
>>
>>> 452: }
>>> 453:
>>> 454: public static final class SequenceElement
>>
>> Why are these not empty records?
>
> I had that in the beginning but convert
On Wed, 31 Jan 2024 14:52:58 GMT, Maurizio Cimadamore
wrote:
>> src/java.base/share/classes/java/lang/foreign/Arena.java line 261:
>>
>>> 259:
>>> 260: /**
>>> 261: * {@return a new shared arena} Segments allocated with the sha
On Wed, 31 Jan 2024 14:51:34 GMT, Maurizio Cimadamore
wrote:
>> This PR fixes a typo in the documentation for the `Arena::ofShared`.
>
> src/java.base/share/classes/java/lang/foreign/Arena.java line 261:
>
>> 259:
>> 260: /**
>> 261: * {@return a new
On Wed, 31 Jan 2024 00:34:40 GMT, Paul Sandoz wrote:
>> test/jdk/jdk/incubator/vector/templates/X-LoadStoreTest.java.template line
>> 271:
>>
>>> 269: @DontInline
>>> 270: static $abstractvectortype$ fromArray($type$[] a, int i) {
>>> 271: return ($abstractvectortype$) SPECIES.f
201 - 300 of 1083 matches
Mail list logo
