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
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
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)` holds, when `N >
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 (
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)` holds, when `N >
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
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
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-authored-b
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
>>
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
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
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
>
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
>
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)
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
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
mentImpl.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
>
>Co-a
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:
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
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
>>
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
>
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
>
> 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
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)
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
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
> 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
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:
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
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
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
>
1 - 100 of 890 matches
Mail list logo
