On Mon, 4 Nov 2024 18:18:38 GMT, Patricio Chilano Mateo
wrote:
>> Here's my suggested C2 change:
>>
>> diff --git a/src/hotspot/cpu/aarch64/aarch64.ad
>> b/src/hotspot/cpu/aarch64/aarch64.ad
>> index d9c77a2f529..1e99db191ae 100644
>> --- a/src/hotspot/cpu/aarch64/aarch64.ad
>> +++ b/src/hotsp
> Using SharedSecrets, I attempted to expose FileInputStream::path information.
> After implementing the fix, I validated the startup performance tests.
> Observed no consistent pattern of performance drops or gains, can disregard
> the occasional performance drop observed in 1 or 2 runs.
Prasa
On Tue, 5 Nov 2024 01:40:15 GMT, Patricio Chilano Mateo
wrote:
>> This is the implementation of JEP 491: Synchronize Virtual Threads without
>> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for
>> further details.
>>
>> In order to make the code review easier the changes
On Tue, 5 Nov 2024 00:18:17 GMT, Fei Yang wrote:
>>> Also, does this mean that the changes from 2 to frame::sender_sp_offset in
>>> all of the lines (267, 271 and 273) should be reverted?
>>>
>> I think the previous lines are okay because we are constructing the fp,
>> whereas in here we want t
> Adds a JFR event for socket connect operations.
>
> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also
> check for connect events.
Tim Prinzing has updated the pull request incrementally with one additional
commit since the last revision:
Added support for connect
On Mon, 4 Nov 2024 16:09:33 GMT, Weijun Wang wrote:
> The test was mistakenly put in a package as the library class it's testing.
> This is unnecessary since there is no internal field/method it needs access
> to.
This pull request has now been integrated.
Changeset: cd91a445
Author:Weiju
Hi all,
The copyright year of some files which has been changed by
[JDK-8341692](https://bugs.openjdk.org/browse/JDK-8341692) wasn't update
correctly. This PR update the copyright year of
[JDK-8341692](https://bugs.openjdk.org/browse/JDK-8341692). Trivial fix, no
risk.
-
Commit m
On Tue, 5 Nov 2024 01:40:15 GMT, Patricio Chilano Mateo
wrote:
>> This is the implementation of JEP 491: Synchronize Virtual Threads without
>> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for
>> further details.
>>
>> In order to make the code review easier the changes
On Mon, 4 Nov 2024 09:24:13 GMT, Stefan Karlsson wrote:
>> If I recall correctly this was a bug where one of the stackChunk fields was
>> allocated in that gap, but since we didn't zeroed it out it would start with
>> some invalid value. I guess the reason why we are not hitting this today is
On Mon, 4 Nov 2024 05:52:16 GMT, Alan Bateman wrote:
>> src/hotspot/share/classfile/javaClasses.cpp line 2107:
>>
>>> 2105:
>>> 2106: jlong java_lang_VirtualThread::waitTimeout(oop vthread) {
>>> 2107: return vthread->long_field(_timeout_offset);
>>
>> Not sure what motivated the name change
On Tue, 5 Nov 2024 00:23:37 GMT, Fei Yang wrote:
>>> As the same code on aarch64 and x86-64 uses `frame::sender_sp_offset` I
>>> suggested to change the literal 2 into `frame::sender_sp_offset` in order
>>> to increase the readability, but I forgot that `frame::sender_sp_offset` is
>>> 0 on ri
> This is the implementation of JEP 491: Synchronize Virtual Threads without
> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for
> further details.
>
> In order to make the code review easier the changes have been split into the
> following initial 4 commits:
>
> - Change
> Using SharedSecrets, I attempted to expose FileInputStream::path information.
> After implementing the fix, I validated the startup performance tests.
> Observed no consistent pattern of performance drops or gains, can disregard
> the occasional performance drop observed in 1 or 2 runs.
Prasa
On Tue, 5 Nov 2024 00:20:56 GMT, Vladimir Ivanov wrote:
> Looks good.
>
> Stylistic comment: while browsing the code a mix of "AOT" & "aot" caught my
> eye. I find the former spelling more descriptive. Any particular reason to
> use "aot" unless all lowercase spelling is preferred in some part
On Mon, 21 Oct 2024 17:56:23 GMT, Vicente Romero wrote:
>> Liam Miller-Cushon has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Migrate another use of sun.misc.Unsafewq
>
> lgtm
@vicente-romero-oracle could you please take another look?
On Mon, 4 Nov 2024 23:57:48 GMT, Ioi Lam wrote:
>> This is an implementation of [JEP 483: Ahead-of-Time Class Loading &
>> Linking](https://openjdk.org/jeps/483).
>>
>>
>> Note: this is a combined PR of the following individual PRs
>> - https://github.com/openjdk/jdk/pull/20516
>> - https:
On Sat, 2 Nov 2024 22:50:29 GMT, Shaojin Wen wrote:
> A small improvement to ArrayClassDescImpl#computeDescriptor that avoids
> intermediate object allocation in the common rank 1 scenario.
This pull request has now been integrated.
Changeset: 67907d5e
Author:Shaojin Wen
URL:
https
On Mon, 4 Nov 2024 18:23:23 GMT, Patricio Chilano Mateo
wrote:
>> Sorry, I also thought it matched the aarch64 one without checking.
>> @RealFYang should I change it for `hf.sp() + frame::link_offset` or just
>> leave it as it was?
>
>> Also, does this mean that the changes from 2 to frame::se
On Mon, 4 Nov 2024 14:21:09 GMT, Dan Heidinga wrote:
>> I think this is already done:
>>
>> `runtimeSetup()` is called inside `InstanceKlass::call_class_initializer()`.
>> When that returns, we will proceed to
>> `InstanceKlass::set_initialization_state_and_notify()` which will perform
>> the
> This is an implementation of [JEP 483: Ahead-of-Time Class Loading &
> Linking](https://openjdk.org/jeps/483).
>
>
> Note: this is a combined PR of the following individual PRs
> - https://github.com/openjdk/jdk/pull/20516
> - https://github.com/openjdk/jdk/pull/20517
> - https://github.co
> This addresses tendencies in previous update to increase fencing, scanning,
> and signalling that can increase contention, and slow down performance
> especially on ARM platforms. It also uses more ARM-friendly constructions to
> reduce overhead (leading to several changes that all of the same
On Mon, 4 Nov 2024 03:15:25 GMT, Ioi Lam wrote:
>> This is an implementation of [JEP 483: Ahead-of-Time Class Loading &
>> Linking](https://openjdk.org/jeps/483).
>>
>>
>> Note: this is a combined PR of the following individual PRs
>> - https://github.com/openjdk/jdk/pull/20516
>> - https:
On Mon, 4 Nov 2024 21:24:54 GMT, Magnus Ihse Bursie wrote:
> > There is no `static-jdk/bin/java.debuginfo`. I do see there's a
> > `./support/static-native/launcher/java.debuginfo`.
>
> Ah, I missed that part. So it's just about copying it to the right place?
> Fine, that is trivial to add. Di
> This change fixes a bug preventing javac from emitting
> 'compiler.warn.sun.proprietary' diagnostics if `--system` is set to a
> non-default value. The diagnostics are currently emitted for values of
> `--release`, and for the default value of `--system`.
>
> The is a redo of [JDK-8331081](ht
On Mon, 4 Nov 2024 19:08:49 GMT, Jorn Vernee wrote:
>> `checkValidStateRaw` synchronizes with `justClose` using handshakes so an
>> opaque or higher load is only needed in `sharedSessionAlreadyClosed`. A
>> `getOpaque` would probably be adequate. But I believe there is no formal
>> restriction
On Mon, 4 Nov 2024 19:27:59 GMT, Magnus Ihse Bursie wrote:
>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
>> Port_](https://openjdk.org/jeps/479).
>>
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port.
>>>
> As a prerequisite for Hermetic Java, we need a statically linked `java`
> launcher. It should behave like the normal, dynamically linked `java`
> launcher, except that all JDK native libraries should be statically, not
> dynamically, linked.
>
> This patch is the first step towards this goal.
On Mon, 4 Nov 2024 21:12:31 GMT, Magnus Ihse Bursie wrote:
> I can confirm that with your patch, and clang, and a complete wipe + rebuild,
> the .java file loading works. I'm currently testing with gcc as well.
Good.
I tested using gcc.
-
PR Comment: https://git.openjdk.org/jdk/
On Mon, 4 Nov 2024 21:29:51 GMT, Jiangli Zhou wrote:
>>> I notice incremental build with your current PR doesn't update
>>> `static-jdk/bin/java` properly. This should be fixed as well.
>>
>> This I fully agree with; it cannot wait for a follow-up PR. I'll look into
>> it as soon as I have got
On Fri, 1 Nov 2024 16:25:59 GMT, Magnus Ihse Bursie wrote:
>> As a prerequisite for Hermetic Java, we need a statically linked `java`
>> launcher. It should behave like the normal, dynamically linked `java`
>> launcher, except that all JDK native libraries should be statically, not
>> dynamica
On Sun, 3 Nov 2024 05:06:04 GMT, Jiangli Zhou wrote:
> There is no `static-jdk/bin/java.debuginfo`. I do see there's a
> `./support/static-native/launcher/java.debuginfo`.
Ah, I missed that part. So it's just about copying it to the right place? Fine,
that is trivial to add. Did you verify tha
On Wed, 30 Oct 2024 19:07:54 GMT, Alexey Semenyuk wrote:
> Clean up of jpackage jtreg test declarations:
> - remove "@modules java.base/jdk.internal.util";
> - remove `--add-opens` from @run;
> - replace "@library ../../../../helpers" and
> "@library ../helpers" with "@library
> /test/jdk/to
On Mon, 4 Nov 2024 19:05:05 GMT, Jiangli Zhou wrote:
> I notice incremental build with your current PR doesn't update
> `static-jdk/bin/java` properly. This should be fixed as well.
This I fully agree with; it cannot wait for a follow-up PR. I'll look into it
as soon as I have gotten back to a
On Mon, 4 Nov 2024 18:18:23 GMT, Patricio Chilano Mateo
wrote:
>> This is the implementation of JEP 491: Synchronize Virtual Threads without
>> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for
>> further details.
>>
>> In order to make the code review easier the changes
> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
> Port_](https://openjdk.org/jeps/479).
>
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port.
>> This port was [deprecated for removal in JDK
>> 21](https://openjd
On Mon, 4 Nov 2024 20:29:23 GMT, Magnus Ihse Bursie wrote:
>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
>> Port_](https://openjdk.org/jeps/479).
>>
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port.
>>>
> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
> Port_](https://openjdk.org/jeps/479).
>
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port.
>> This port was [deprecated for removal in JDK
>> 21](https://openjd
> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
> Port_](https://openjdk.org/jeps/479).
>
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port.
>> This port was [deprecated for removal in JDK
>> 21](https://openjd
> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
> Port_](https://openjdk.org/jeps/479).
>
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port.
>> This port was [deprecated for removal in JDK
>> 21](https://openjd
On Thu, 31 Oct 2024 21:33:11 GMT, Vladimir Ivanov wrote:
> The synchronization block may be substituted by the 'volatile' variable
> smaller synchronization block.
> It reduce the total blocking time for the specjvm2008::xml.validation
> workload and improve the reported score.
> Scores for the
> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
> Port_](https://openjdk.org/jeps/479).
>
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port.
>> This port was [deprecated for removal in JDK
>> 21](https://openjd
> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
> Port_](https://openjdk.org/jeps/479).
>
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port.
>> This port was [deprecated for removal in JDK
>> 21](https://openjd
> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
> Port_](https://openjdk.org/jeps/479).
>
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port.
>> This port was [deprecated for removal in JDK
>> 21](https://openjd
On Mon, 21 Oct 2024 18:30:50 GMT, Martin Balao wrote:
>> In addition to the goals, scope, motivation, specification and requirement
>> notes in [JDK-8315487](https://bugs.openjdk.org/browse/JDK-8315487), we
>> would like to describe the most relevant decisions taken during the
>> implementatio
Hi Fabian,
On 11/4/24 1:38 AM, Fabian Meumertzheim wrote:
Would contributions in this area be welcome? If it is possible to get
to a state where this assumption does hold via incremental, behavior
preserving changes to the native Windows parts of the Java runtime,
that would potentially allow t
> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
> Port_](https://openjdk.org/jeps/479).
>
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port.
>> This port was [deprecated for removal in JDK
>> 21](https://openjd
> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
> Port_](https://openjdk.org/jeps/479).
>
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port.
>> This port was [deprecated for removal in JDK
>> 21](https://openjd
On Mon, 4 Nov 2024 13:17:23 GMT, Quan Anh Mai wrote:
>>> I'm dubious about this.
>>
>> NVM, I see it now -`sharedSessionAlreadyAcquired` uses a `getVolatile`
>> (which has stronger semantics), so we're in the clear.
>
> `checkValidStateRaw` synchronizes with `justClose` using handshakes so an
On Fri, 1 Nov 2024 02:44:15 GMT, Quan Anh Mai wrote:
>> Hi,
>>
>> This patch makes `MemorySessionImpl.state` a `Stable` field so that liveness
>> check of non-closeable scopes such as the global scope can be elided.
>>
>> Currently, the `state` field is overloaded with 2 responsibilities, to a
On Fri, 1 Nov 2024 16:25:59 GMT, Magnus Ihse Bursie wrote:
>> As a prerequisite for Hermetic Java, we need a statically linked `java`
>> launcher. It should behave like the normal, dynamically linked `java`
>> launcher, except that all JDK native libraries should be statically, not
>> dynamica
On Sun, 3 Nov 2024 20:23:32 GMT, Jiangli Zhou wrote:
>> Magnus Ihse Bursie has updated the pull request with a new target base due
>> to a merge or a rebase. The pull request now contains 10 commits:
>>
>> - Merge branch 'master' into static-jdk-image
>> - Fix bug in filtering out -Wl,--exclu
On Mon, 4 Nov 2024 16:09:33 GMT, Weijun Wang wrote:
> The test was mistakenly put in a package as the library class it's testing.
> This is unnecessary since there is no internal field/method it needs access
> to.
Marked as reviewed by mullan (Reviewer).
-
PR Review: https://git.
On Thu, 31 Oct 2024 18:37:50 GMT, Mandy Chung wrote:
>> Severin Gehwolf has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 172 commits:
>>
>> - Merge branch 'master' into jdk-8311302-jmodless-link
>> - Some test fixes
>> - Remove
On Mon, 4 Nov 2024 18:18:23 GMT, Patricio Chilano Mateo
wrote:
>> This is the implementation of JEP 491: Synchronize Virtual Threads without
>> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for
>> further details.
>>
>> In order to make the code review easier the changes
On Thu, 31 Oct 2024 18:20:36 GMT, Mandy Chung wrote:
>> Severin Gehwolf has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 172 commits:
>>
>> - Merge branch 'master' into jdk-8311302-jmodless-link
>> - Some test fixes
>> - Remove
> Can I get a review for this patch that adds `@since` checker tests to the
> following modules: java.compiler, jdk.compiler, jdk.javadoc and jdk.jdeps.
> The initial test for `java.base` has been integrated in
> [JDK-8331051](https://bugs.openjdk.org/browse/JDK-8331051).
>
> The jtreg comment
On Sun, 3 Nov 2024 03:13:25 GMT, Archie Cobbs wrote:
>> Please review this patch which removes unnecessary `@SuppressWarnings`
>> annotations.
>
> Archie Cobbs has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excludes the unrelated changes
On Fri, 25 Oct 2024 04:40:24 GMT, David Holmes wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with four
>> additional commits since the last revision:
>>
>> - Rename set/has_owner_anonymous to set/has_anonymous_owner
>> - Fix comments in javaThread.hpp and Thread.
On Mon, 4 Nov 2024 18:22:42 GMT, Patricio Chilano Mateo
wrote:
>> Note that `frame::sender_sp_offset` is 0 instead of 2 on linux-riscv64,
>> which is different from aarch64 or x86-64. So I think we should revert this
>> change:
>> https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf
On Sat, 2 Nov 2024 02:41:44 GMT, Fei Yang wrote:
>> Changed.
>
> Note that `frame::sender_sp_offset` is 0 instead of 2 on linux-riscv64, which
> is different from aarch64 or x86-64. So I think we should revert this change:
> https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f
> Can I get a review for this patch that adds `@since` checker tests to the
> following modules: java.compiler, jdk.compiler, jdk.javadoc and jdk.jdeps.
> The initial test for `java.base` has been integrated in
> [JDK-8331051](https://bugs.openjdk.org/browse/JDK-8331051).
>
> The jtreg comment
On Thu, 31 Oct 2024 17:53:01 GMT, Mandy Chung wrote:
>> Severin Gehwolf has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 172 commits:
>>
>> - Merge branch 'master' into jdk-8311302-jmodless-link
>> - Some test fixes
>> - Remove
On Tue, 29 Oct 2024 22:58:31 GMT, Dean Long wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix comment in VThreadWaitReenter
>
> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 316:
>
>> 314:
On Fri, 1 Nov 2024 20:08:51 GMT, Dean Long wrote:
>> It turns out if we try to set last pc to the instruction after the
>> adjustment, then we need an oopmap there, and that would require more C2
>> changes. Then I thought about restoring SP from FP or last_Java_fp, but I
>> don't think we ca
> This is the implementation of JEP 491: Synchronize Virtual Threads without
> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for
> further details.
>
> In order to make the code review easier the changes have been split into the
> following initial 4 commits:
>
> - Change
On Wed, 30 Oct 2024 23:23:11 GMT, Mandy Chung wrote:
>> Severin Gehwolf has updated the pull request incrementally with 20
>> additional commits since the last revision:
>>
>> - Some test fixes
>> - Remove period in jlink.properties
>> - Revert changes to ResourcePoolEntry
>> - Fix comment
On Mon, 4 Nov 2024 17:31:00 GMT, Magnus Ihse Bursie wrote:
>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
>> Port_](https://openjdk.org/jeps/479).
>>
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port.
>>>
On Wed, 30 Oct 2024 22:44:45 GMT, Mandy Chung wrote:
>> Severin Gehwolf has updated the pull request incrementally with 20
>> additional commits since the last revision:
>>
>> - Some test fixes
>> - Remove period in jlink.properties
>> - Revert changes to ResourcePoolEntry
>> - Fix comment
On Sun, 6 Oct 2024 02:35:45 GMT, SendaoYan wrote:
> Hi all,
> The newly added test `java/foreign/TestUpcallStress.java` call
> `System.loadLibrary("TestUpcall")` load native library, so this test should
> mark as `/native`.
> The change has been verified locally, trivial fix, no risk.
Hi, can
On Mon, 4 Nov 2024 17:16:49 GMT, Vladimir Kozlov wrote:
>>> > With that said, it is sure as heck confusing! Which also apparently
>>> > Microsoft acknowledges by phasing in the term "Windows API". So I agree
>>> > that we should try to rename everything currently called "win32" into
>>> > "win
> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
> Port_](https://openjdk.org/jeps/479).
>
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port.
>> This port was [deprecated for removal in JDK
>> 21](https://openjd
On Fri, 1 Nov 2024 18:11:13 GMT, Vladimir Kozlov wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Remove superfluous check for 64-bit on Windows in
>> MacroAssembler::call_clobbered_xmm_registers
>> - Remo
On Mon, 4 Nov 2024 17:08:40 GMT, Magnus Ihse Bursie wrote:
>>> With that said, it is sure as heck confusing! Which also apparently
>>> Microsoft acknowledges by phasing in the term "Windows API". So I agree
>>> that we should try to rename everything currently called "win32" into
>>> "windows"
On Wed, 30 Oct 2024 22:41:49 GMT, Mandy Chung wrote:
>> Severin Gehwolf has updated the pull request incrementally with 20
>> additional commits since the last revision:
>>
>> - Some test fixes
>> - Remove period in jlink.properties
>> - Revert changes to ResourcePoolEntry
>> - Fix comment
On Mon, 4 Nov 2024 17:01:33 GMT, Vladimir Kozlov wrote:
> > With that said, it is sure as heck confusing! Which also apparently
> > Microsoft acknowledges by phasing in the term "Windows API". So I agree
> > that we should try to rename everything currently called "win32" into
> > "windows". B
These two annotations are found to be lost during the ClassFile API port of
LambdaForm generation. I seem not able to reproduce the master issue in a
current build but could reproduce before when the change is first made.
Anyways this restoration is always a right thing, better commit it and f
On Mon, 4 Nov 2024 16:04:12 GMT, Magnus Ihse Bursie wrote:
> With that said, it is sure as heck confusing! Which also apparently Microsoft
> acknowledges by phasing in the term "Windows API". So I agree that we should
> try to rename everything currently called "win32" into "windows". But I'd
> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
> Port_](https://openjdk.org/jeps/479).
>
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port.
>> This port was [deprecated for removal in JDK
>> 21](https://openjd
On Sun, 3 Nov 2024 20:23:32 GMT, Jiangli Zhou wrote:
>> Magnus Ihse Bursie has updated the pull request with a new target base due
>> to a merge or a rebase. The pull request now contains 10 commits:
>>
>> - Merge branch 'master' into static-jdk-image
>> - Fix bug in filtering out -Wl,--exclu
On Sun, 3 Nov 2024 05:06:04 GMT, Jiangli Zhou wrote:
> Please fix the debugging symbol issue in your PR.
That is a request with most likely a whole other magnitude of difficulty. Our
handling of debug symbols and all its intricacies is tightly coupled to the
existing dynamic linking process. I
On Thu, 31 Oct 2024 20:06:24 GMT, Naoto Sato wrote:
>> Upgrading the CLDR to version 46.0. A corresponding CSR has also been
>> drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Addresses review comments
Thank you fo
On Tue, 29 Oct 2024 18:12:43 GMT, Naoto Sato wrote:
> Upgrading the CLDR to version 46.0. A corresponding CSR has also been drafted.
This pull request has now been integrated.
Changeset: 1c448347
Author:Naoto Sato
URL:
https://git.openjdk.org/jdk/commit/1c4483473d878bb4c41e66f27fea8
On Wed, 30 Oct 2024 08:54:55 GMT, kabutz wrote:
> The ArrayBlockingQueue has had a readObject() method since Java 7, which
> checks invariants of the deserialized object. However, it does not have a
> writeObject() method. This means that the ArrayBlockingQueue could be
> modified whilst it is
On Mon, 4 Nov 2024 09:45:05 GMT, Thomas Stuefe wrote:
> Can we get rid of `JNICALL` too, please?
That we can never do, since it is part of jni.h which are imported in likely
millions of JNI projects. But we can replace it with an empty define. And we
can document it as not needed anymore, and
On Mon, 4 Nov 2024 09:58:49 GMT, Kim Barrett wrote:
>> There is a difference between "working" and not causing a build failure. I
>> suspect none of that code is actually needed these days, but I'm not sure.
>> As deleting the entire section goes beyond deleting 32-bit code, I would
>> expect
> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
> Port_](https://openjdk.org/jeps/479).
>
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port.
>> This port was [deprecated for removal in JDK
>> 21](https://openjd
On Sat, 2 Nov 2024 07:51:20 GMT, Alexander Zuev wrote:
>> make/modules/jdk.accessibility/Lib.gmk line 57:
>>
>>> 55: TARGETS += $(BUILD_LIBJAVAACCESSBRIDGE)
>>> 56:
>>> 57:
>>> ##
>>
>> Most of the desktop related
> Make final adjustments to drop PreviewFeature and updating the @ since
> markers.
Viktor Klang has updated the pull request incrementally with one additional
commit since the last revision:
Updating copyright years and removing an unneccessary import for Gatherers
-
Changes:
On Fri, 1 Nov 2024 10:58:09 GMT, kabutz wrote:
>> Since Java 10, spliterators for the ConcurrentSkipListMap were pointing to
>> the head, which has item == null, rather than to the first element. The
>> trySplit() method no longer worked, and always returned null. Therefore,
>> parallel stream
The test was mistakenly put in a package as the library class it's testing.
This is unnecessary since there is no internal field/method it needs access to.
-
Commit messages:
- 8343549: SeededSecureRandomTest needn't be in a package
Changes: https://git.openjdk.org/jdk/pull/21881/f
On Mon, 4 Nov 2024 09:45:05 GMT, Thomas Stuefe wrote:
>>> Can we get rid of `JNICALL` too, please?
>>>
>>> Or would that change be too big?
>>
>> There's >1000 in java.base, lots more elsewhere, so it would be a lot of
>> files and would hide the core changes. So maybe for a follow-up PR that
On Mon, 4 Nov 2024 15:47:46 GMT, Chen Liang wrote:
> These two annotations are found to be lost during the ClassFile API port of
> LambdaForm generation. I seem not able to reproduce the master issue in a
> current build but could reproduce before when the change is first made.
> Anyways thi
On Fri, 1 Nov 2024 10:58:09 GMT, kabutz wrote:
>> Since Java 10, spliterators for the ConcurrentSkipListMap were pointing to
>> the head, which has item == null, rather than to the first element. The
>> trySplit() method no longer worked, and always returned null. Therefore,
>> parallel stream
> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
> Port_](https://openjdk.org/jeps/479).
>
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port.
>> This port was [deprecated for removal in JDK
>> 21](https://openjd
On Mon, 4 Nov 2024 03:08:02 GMT, Ioi Lam wrote:
>> src/hotspot/share/cds/aotClassInitializer.cpp line 348:
>>
>>> 346: }
>>> 347: JavaValue result(T_VOID);
>>> 348: JavaCalls::call_static(&result, ik,
>>
>> Based on the discussions in JDK-8342283, do we need a memory fence after the
> This PR proposes to add a small text segment on the
> `MemorySegment::reinterpret` overloads that takes an Arena stating the
> responsibility of actually freeing reinterpreted segments lies with the
> *original* arena.
Per Minborg has updated the pull request incrementally with one additional
On Tue, 29 Oct 2024 12:20:01 GMT, Per Minborg wrote:
> This PR proposes to add a small text segment on the
> `MemorySegment::reinterpret` overloads that takes an Arena stating the
> responsibility of actually freeing reinterpreted segments lies with the
> *original* arena.
This pull request h
On Mon, 4 Nov 2024 14:08:08 GMT, Per Minborg wrote:
>> This PR proposes to add a small text segment on the
>> `MemorySegment::reinterpret` overloads that takes an Arena stating the
>> responsibility of actually freeing reinterpreted segments lies with the
>> *original* arena.
>
> Per Minborg h
On Sat, 2 Nov 2024 02:41:44 GMT, Fei Yang wrote:
>> Changed.
>
> Note that `frame::sender_sp_offset` is 0 instead of 2 on linux-riscv64, which
> is different from aarch64 or x86-64. So I think we should revert this change:
> https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f
On Thu, 31 Oct 2024 10:52:22 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>>
1 - 100 of 126 matches
Mail list logo
