On Thu, 18 Apr 2024 20:11:15 GMT, Claes Redestad wrote:
> Investigating a recent regression in mainline I realized we have an
> opportunity to improve the bootstrap overheads of ObjectMethods::bootstrap by
> using `invokeExact` in a way similar to what we already do for LMF and SCF
> BSMs.
Using compare the unsigned max(va, vb) could be written as:
var va = IntVector.fromArray(ispecies, ia, i);
var vb = IntVector.fromArray(ispecies, ib, i);
var vm = va.compare(UNSIGNED_LT, vb);
va.blend(vb, vm).intoArray(ir, i);
Where ia and ib
On Thu, 18 Apr 2024 21:54:26 GMT, Joe Wang wrote:
>> Add two sample configuration files:
>>
>> jaxp-strict.properties: used to set strict configuration, stricter than
>> jaxp.properties in previous versions such as JDK 22
>>
>> jaxp-compat.properties: used to regain compatibility from any
On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons wrote:
> Please review a set of updates to clean up use of `/**` comments in the
> vicinity of declarations.
>
> There are various categories of update:
>
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or
On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons wrote:
> Please review a set of updates to clean up use of `/**` comments in the
> vicinity of declarations.
>
> There are various categories of update:
>
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or
> **Subject**
> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to
> `java.util.List`
>
> **Motivation**
> The motivation behind this proposal is to enhance the functionality of the
> `List` interface by providing a more flexible way to find the index of an
> element.
On Thu, 18 Apr 2024 19:56:43 GMT, Alexey Semenyuk wrote:
> Pass a path with resolved symlinks to `dpkg -S` command. If it fails, try the
> original path if they differ.
>
> Testing on Ubuntu 24.04 passed. Successfully created a .deb package from
> SwingSet2.jar with the not-empty list of
On Tue, 9 Apr 2024 22:02:56 GMT, xxDark wrote:
> This does not solve the problem though. Source compatibility would still be
> broken as one would still need to add casts everywhere, or am I
> misinterpreting something?
The code you have provided in example is still valid and non-ambigous,
On Wed, 10 Apr 2024 11:20:32 GMT, xxDark wrote:
> Should be `findIndex`? Similarly with `findLastIndex`.
Yeah i guess IDE didnt do a great job with refactor. I will review aall changes
manually a bit later
-
PR Review Comment:
On Tue, 9 Apr 2024 20:48:19 GMT, Chen Liang wrote:
> A few remarks:
>
> 1. The concern on `indexOf(Object)` and `indexOf(Predicate)` is valid;
> `Optional` has `orElse` vs. `orElseGet` to avoid these clashes. The behavior
> change of `indexOf(null)` is a source incompatibility.
> 2. Have you
On Tue, 9 Apr 2024 21:48:23 GMT, Evemose wrote:
> One possible workaround is to temporally (for an intermidiate period) or
> permanently delegate null value handing to indexOf(Object), which seems odd
> for me to me tbh, although it preserves source compatibility.
This does not solve the
On Fri, 5 Apr 2024 00:00:58 GMT, Evemose wrote:
> **Subject**
> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to
> `java.util.List`
>
> **Motivation**
> The motivation behind this proposal is to enhance the functionality of the
> `List` interface by providing a more flexible
On Mon, 8 Apr 2024 03:57:33 GMT, ExE Boss wrote:
>> **Subject**
>> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to
>> `java.util.List`
>>
>> **Motivation**
>> The motivation behind this proposal is to enhance the functionality of the
>> `List` interface by providing a more
On Fri, 5 Apr 2024 00:31:22 GMT, Evemose wrote:
>> **Subject**
>> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to
>> `java.util.List`
>>
>> **Motivation**
>> The motivation behind this proposal is to enhance the functionality of the
>> `List` interface by providing a more
On Fri, 5 Apr 2024 00:00:58 GMT, Evemose wrote:
> **Subject**
> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to
> `java.util.List`
>
> **Motivation**
> The motivation behind this proposal is to enhance the functionality of the
> `List` interface by providing a more flexible
**Subject**
Addition of Predicate-based `indexOf` and `lastIndexOf` methods to
`java.util.List`
**Motivation**
The motivation behind this proposal is to enhance the functionality of the
`List` interface by providing a more flexible way to find the index of an
element. Currently, the `indexOf`
On Fri, 5 Apr 2024 00:00:58 GMT, Evemose wrote:
> **Subject**
> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to
> `java.util.List`
>
> **Motivation**
> The motivation behind this proposal is to enhance the functionality of the
> `List` interface by providing a more flexible
On Fri, 5 Apr 2024 00:00:58 GMT, Evemose wrote:
> **Subject**
> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to
> `java.util.List`
>
> **Motivation**
> The motivation behind this proposal is to enhance the functionality of the
> `List` interface by providing a more flexible
On Fri, 5 Apr 2024 00:31:22 GMT, Evemose wrote:
>> **Subject**
>> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to
>> `java.util.List`
>>
>> **Motivation**
>> The motivation behind this proposal is to enhance the functionality of the
>> `List` interface by providing a more
> Please review the updates to support a proposed new
> `-Xlint:dangling-doc-comments` option.
>
> The work can be thought of as in 3 parts:
>
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it
> is possible to specify the appropriately configured `Lint` object when
On Apr 17, 2024, at 7:14 AM, David Lloyd wrote:
>
> 2. Add .MIN_VALUE, min/max with a value or vector also offset by
> .MIN_VALUE, and then subtract the offset again
I think that’s the path of least resistance. It’s just a vxor on each operand,
with a constant mask. That can be done in Java
On Wed, 17 Apr 2024 23:24:06 GMT, Joe Wang wrote:
> Add two sample configuration files:
>
> jaxp-strict.properties: used to set strict configuration, stricter than
> jaxp.properties in previous versions such as JDK 22
>
> jaxp-compat.properties: used to regain compatibility from any more
> Add two sample configuration files:
>
> jaxp-strict.properties: used to set strict configuration, stricter than
> jaxp.properties in previous versions such as JDK 22
>
> jaxp-compat.properties: used to regain compatibility from any more
> restricted configuration than previous versions
> Please review the updates to support a proposed new
> `-Xlint:dangling-doc-comments` option.
>
> The work can be thought of as in 3 parts:
>
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it
> is possible to specify the appropriately configured `Lint` object when
On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons wrote:
> Please review a set of updates to clean up use of `/**` comments in the
> vicinity of declarations.
>
> There are various categories of update:
>
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or
On Thu, 18 Apr 2024 19:56:43 GMT, Alexey Semenyuk wrote:
> Pass a path with resolved symlinks to `dpkg -S` command. If it fails, try the
> original path if they differ.
>
> Testing on Ubuntu 24.04 passed. Successfully created a .deb package from
> SwingSet2.jar with the not-empty list of
> Please review the updates to support a proposed new
> `-Xlint:dangling-doc-comments` option.
>
> The work can be thought of as in 3 parts:
>
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it
> is possible to specify the appropriately configured `Lint` object when
Please review a set of updates to clean up use of `/**` comments in the
vicinity of declarations.
There are various categories of update:
* "Box comments" beginning with `/**`
* Misplaced doc comments before package or import statements
* Misplaced doc comments after the annotations for a
On Thu, 18 Apr 2024 07:34:24 GMT, Jan Lahoda wrote:
>> Hi folks,
>>
>> This PR aims to fix
>> [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581).
>>
>> I think the regression got introduced in
>> [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458).
>>
>> In the issue
On Mon, 15 Apr 2024 18:25:02 GMT, Sonia Zaldana Calles
wrote:
> Hi folks,
>
> This PR aims to fix
> [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581).
>
> I think the regression got introduced in
> [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458).
>
> In the issue
> Currently the JFR event FileForceEvent is generated by instrumenting the
> sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer
> mirror events with static methods.
>
> Added the event at jdk.internal.event.FileForceEvent, and changed
> jdk.jfr.events.FileForceEvent to
On Thu, 18 Apr 2024 18:59:20 GMT, Tim Prinzing wrote:
>> Currently the JFR event FileForceEvent is generated by instrumenting the
>> sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer
>> mirror events with static methods.
>>
>> Added the event at
Investigating a recent regression in mainline I realized we have an opportunity
to improve the bootstrap overheads of ObjectMethods::bootstrap by using
`invokeExact` in a way similar to what we already do for LMF and SCF BSMs. This
avoids generating type checking adapters and equates to a
Presently, I'm implementing operations for a WASM emulator/runtime, so it's
more a case of transitively acquiring use cases from WASM, though I'm also
doing this specifically to practice accomplishing useful things with the
vector API.
Regarding saturating arithmetic: WASM has operations for that
On Thu, 18 Apr 2024 19:56:43 GMT, Alexey Semenyuk wrote:
> Pass a path with resolved symlinks to `dpkg -S` command. If it fails, try the
> original path if they differ.
>
> Testing on Ubuntu 24.04 passed. Successfully created a .deb package from
> SwingSet2.jar with the not-empty list of
Pass a path with resolved symlinks to `dpkg -S` command. If it fails, try the
original path if they differ.
Testing on Ubuntu 24.04 passed. Successfully created a .deb package from
SwingSet2.jar with the not-empty list of dependencies. Before the fix the list
of required packages was empty. In
> Currently the JFR event FileForceEvent is generated by instrumenting the
> sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer
> mirror events with static methods.
>
> Added the event at jdk.internal.event.FileForceEvent, and changed
> jdk.jfr.events.FileForceEvent to
On Thu, 18 Apr 2024 18:46:36 GMT, Tim Prinzing wrote:
>> Currently the JFR event FileForceEvent is generated by instrumenting the
>> sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer
>> mirror events with static methods.
>>
>> Added the event at
> Currently the JFR event FileForceEvent is generated by instrumenting the
> sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer
> mirror events with static methods.
>
> Added the event at jdk.internal.event.FileForceEvent, and changed
> jdk.jfr.events.FileForceEvent to
Hi David,
It’s not at all outlandish, but would caution it's more work than one might
initially think.
Could you describe a little more about your use case? that can be helpful to
understand the larger picture and demand. Using unsigned comparison would be my
recommended approach with the
On Tue, 16 Apr 2024 00:04:15 GMT, Scott Gibbons wrote:
>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64. See
>> [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around
>> this change.
>>
>> Overall, making this an intrinsic improves overall
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 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 Thu, 18 Apr 2024 12:11:19 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 Thu, 18 Apr 2024 13:27:38 GMT, Jan Kratochvil
wrote:
> Could not we rename `is_containerized()` to `use_container_limit()` ? As that
> is the current only purpose of `is_containerized()`.
I'm not sure. There is value to have `is_containerized()` like it would behave
after this patch.
On Wed, 17 Apr 2024 20:46:26 GMT, Joe Darcy wrote:
> 8330458: Add missing @since tag to ClassFile.JAVA_23_VERSION
This pull request has now been integrated.
Changeset: 235ba9a7
Author:Joe Darcy
URL:
https://git.openjdk.org/jdk/commit/235ba9a7025964b1e43149c7102e26b82b2081ad
Stats:
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 15:14:10 GMT, Tim Prinzing wrote:
>> I think it might be the cause for
>> https://bugs.openjdk.org/browse/JDK-8329330 I have sent out a PR to remove
>> those separately so the fix can be backported.
>> https://github.com/openjdk/jdk/pull/18843
>
> That's correct, it is an
On Thu, 18 Apr 2024 14:32:28 GMT, Erik Gahlin wrote:
>> src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java line 66:
>>
>>> 64: FileWriteEvent.class,
>>> 65: SocketReadEvent.class,
>>> 66: SocketWriteEvent.class,
>>
>> I'm guessing that this change
On Wed, 17 Apr 2024 23:24:06 GMT, Joe Wang wrote:
> Add two sample configuration files:
>
> jaxp-strict.properties: used to set strict configuration, stricter than
> jaxp.properties in previous versions such as JDK 22
>
> jaxp-compat.properties: used to regain compatibility from any more
> This patch suggests a workaround to an issue with huge SCF MH expression
> trees taking excessive JIT compilation resources by reviving (part of) the
> simple bytecode-generating strategy that was originally available as an
> all-or-nothing strategy choice.
>
> Instead of reintroducing a
> This patch suggests a workaround to an issue with huge SCF MH expression
> trees taking excessive JIT compilation resources by reviving (part of) the
> simple bytecode-generating strategy that was originally available as an
> all-or-nothing strategy choice.
>
> Instead of reintroducing a
On Wed, 17 Apr 2024 14:05:28 GMT, Daniel Fuchs wrote:
>> Tim Prinzing has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> test file local to test
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java line 66:
>
>> 64:
On Wed, 17 Apr 2024 01:34:07 GMT, Tim Prinzing wrote:
>> Currently the JFR event FileForceEvent is generated by instrumenting the
>> sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer
>> mirror events with static methods.
>>
>> Added the event at
On Wed, 17 Apr 2024 01:34:07 GMT, Tim Prinzing wrote:
>> Currently the JFR event FileForceEvent is generated by instrumenting the
>> sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer
>> mirror events with static methods.
>>
>> Added the event at
On Thu, 11 Apr 2024 12:08:02 GMT, Severin Gehwolf wrote:
>> Please review this enhancement to the container detection code which allows
>> it to figure out whether the JVM is actually running inside a container
>> (`podman`, `docker`, `crio`), or with some other means that enforces
>>
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
>>
> 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 then
> expanded to import-on-demand in `TypeEnter`.
> There
On Thu, 18 Apr 2024 10:47:11 GMT, Maurizio Cimadamore
wrote:
>> Jan Lahoda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Updating JEP number and caption.
>
>
> 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::orElseThrow()` on the result.
>
> This PR proposes to
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 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 Wed, 17 Apr 2024 01:07:04 GMT, Jan Kratochvil
wrote:
>>> IMHO `is_containerized()` is OK to return `false` even when running in a
>>> container but with no limitations set.
>>
>> The idea here is to use this property to tune OpenJDK for in-container,
>> specifically k8s, use. In such a
On Wed, 17 Apr 2024 23:24:06 GMT, Joe Wang wrote:
> Add two sample configuration files:
>
> jaxp-strict.properties: used to set strict configuration, stricter than
> jaxp.properties in previous versions such as JDK 22
>
> jaxp-compat.properties: used to regain compatibility from any more
On Mon, 15 Apr 2024 18:25:02 GMT, Sonia Zaldana Calles
wrote:
> Hi folks,
>
> This PR aims to fix
> [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581).
>
> I think the regression got introduced in
> [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458).
>
> In the issue
On Thu, 18 Apr 2024 06:31:03 GMT, Alan Bateman wrote:
>> Hi Christoph, seems the USE_REGISTRY_LOOKUP is currently unused (at least
>> without additional defines that are not present usually)
>>
>> src/java.base/windows/native/libjli/java_md.c:52:#ifdef USE_REGISTRY_LOOKUP
>>
> We have already good JLI tracing capabilities. But GetApplicationHome and
> GetApplicationHomeFromDll lack some tracing and should be enhanced.
Matthias Baesken has updated the pull request incrementally with one additional
commit since the last revision:
remove obsolete
On Thu, 18 Apr 2024 05:43:03 GMT, Alan Bateman wrote:
>> Jan Lahoda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fixing ListModuleDeps test.
>
> src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 84:
>
>> 82:
> 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 then
> expanded to import-on-demand in `TypeEnter`.
> There
On Tue, 16 Apr 2024 14:29:13 GMT, Matthias Baesken wrote:
>> src/java.base/windows/native/libjli/java_md.c line 326:
>>
>>> 324: }
>>> 325:
>>> 326: JLI_TraceLauncher("GetJREPath - attempt to get JRE location from
>>> shared lib of the image\n");
>>
>> Maybe add a trace also in the
> java.base java.lang.invoke package heavily uses ASM to generate lambdas and
> method handles.
>
> This patch converts ASM calls to Classfile API.
>
> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
>
> Any comments and suggestions are welcome.
>
> Please review.
>
>
71 matches
Mail list logo
