On Tue, 29 Oct 2024 01:46:51 GMT, Serguei Spitsyn wrote:
>> This fixes a problem in the VTMS (Virtual Thread Mount State) transition
>> frames hiding mechanism.
>> Please, see a fix description in the first comment.
>>
>> Testing:
>> - Verified with new test `vthread/CheckHiddenFrames`
>> - M
On Mon, 28 Oct 2024 19:16:26 GMT, Brent Christian wrote:
>> Sean Mullan has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 175 commits:
>>
>> - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>> - Specify that pa
This is an update to the Virtual thread implementation that we'd like to
integrate in advance of JEP 491.
The update removes the use of "temporary transitions", basically cases where
the thread identity switches to the carrier thread to do something in the
context of the carrier while a virtua
On Tue, 29 Oct 2024 03:03:17 GMT, SendaoYan wrote:
> Hi all,
> The test `tools/jpackage/share/jdk/jpackage/tests/BasicTest.java` javac
> compile fails `cannot find symbol TKit.assertPathNotEmptyDirectory` after
> [JDK-8343101](https://bugs.openjdk.org/browse/JDK-8343101). I think we should
> u
On Tue, 29 Oct 2024 03:03:17 GMT, SendaoYan wrote:
> Hi all,
> The test `tools/jpackage/share/jdk/jpackage/tests/BasicTest.java` javac
> compile fails `cannot find symbol TKit.assertPathNotEmptyDirectory` after
> [JDK-8343101](https://bugs.openjdk.org/browse/JDK-8343101). I think we should
> u
On Tue, 29 Oct 2024 03:03:17 GMT, SendaoYan wrote:
> Hi all,
> The test `tools/jpackage/share/jdk/jpackage/tests/BasicTest.java` javac
> compile fails `cannot find symbol TKit.assertPathNotEmptyDirectory` after
> [JDK-8343101](https://bugs.openjdk.org/browse/JDK-8343101). I think we should
> u
On Tue, 29 Oct 2024 04:57:13 GMT, Jaikiran Pai wrote:
> I think you meant https://bugs.openjdk.org/browse/JDK-8343101.
Yes, Sorry for the mistake. The PR description has been updated.
-
PR Comment: https://git.openjdk.org/jdk/pull/21750#issuecomment-2443273038
On Tue, 29 Oct 2024 03:03:17 GMT, SendaoYan wrote:
> Hi all,
> The test `tools/jpackage/share/jdk/jpackage/tests/BasicTest.java` javac
> compile fails `cannot find symbol TKit.assertPathNotEmptyDirectory` after
> [JDK-8343101](https://bugs.openjdk.org/browse/JDK-8343101). I think we should
> u
On Tue, 29 Oct 2024 00:04:09 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 change
> Port of Float16 from java.lang in the lworld+fp16 branch to
> jdk.incubabor.vector.
Joe Darcy has updated the pull request incrementally with one additional commit
since the last revision:
Add support for proper String -> Float16 conversion.
-
Changes:
- all: https://git.ope
On Tue, 29 Oct 2024 04:30:57 GMT, Joe Darcy wrote:
>> Port of Float16 from java.lang in the lworld+fp16 branch to
>> jdk.incubabor.vector.
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Add support for proper String -> Float
On Tue, 29 Oct 2024 03:03:17 GMT, SendaoYan wrote:
> Hi all,
> The test `tools/jpackage/share/jdk/jpackage/tests/BasicTest.java` javac
> compile fails `cannot find symbol TKit.assertPathNotEmptyDirectory` after
> JDK-8343178. I think we should use `TKit.assertDirectoryNotEmpty` instead of
> `T
On Tue, 29 Oct 2024 04:30:57 GMT, Joe Darcy wrote:
>> Port of Float16 from java.lang in the lworld+fp16 branch to
>> jdk.incubabor.vector.
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Add support for proper String -> Float
On Tue, 29 Oct 2024 00:04:09 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 change
Hi all,
The test `tools/jpackage/share/jdk/jpackage/tests/BasicTest.java` javac compile
fails `cannot find symbol TKit.assertPathNotEmptyDirectory` after JDK-8343178.
I think we should use `TKit.assertDirectoryNotEmpty` instead of
`TKit.assertPathNotEmptyDirectory`.
The change has been verified
On Tue, 29 Oct 2024 00:04:09 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 change
On Tue, 29 Oct 2024 00:04:09 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 change
On Tue, 29 Oct 2024 00:04:09 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 change
On Tue, 29 Oct 2024 00:04:09 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 change
On Tue, 29 Oct 2024 00:04:09 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 change
> On Oct 28, 2024, at 5:40 PM, Alexander Matveev
> wrote:
>
> Hi Michael,
>
> > They would also, files in the app directory, all be automatically code
> > signed I think wouldn’t they?
> Yes, files under app directory will be signed as well.
>
> Thanks,
> Alexander
Sorry, I was going to
On Thu, 24 Oct 2024 09:08:09 GMT, Matthias Baesken wrote:
> Test java/io/IO/IO.java fails on Linux ppc64le because of issues with
> 'expect' .
Hello Matthias, as per the problem listing guidelines
https://openjdk.org/guide/#problemlisting-jtreg-tests which states:
> Remember to always add a pr
On Wed, 23 Oct 2024 07:24:05 GMT, Alan Bateman wrote:
>> Serguei Spitsyn has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 11 commits:
>>
>> - Merge
>> - review: explain better what methods can be annotated with
>> JvmtiMountTran
> This fixes a problem in the VTMS (Virtual Thread Mount State) transition
> frames hiding mechanism.
> Please, see a fix description in the first comment.
>
> Testing:
> - Verified with new test `vthread/CheckHiddenFrames`
> - Mach5 tiers 1-6 are passed
Serguei Spitsyn has updated the pull re
On Mon, 28 Oct 2024 05:56:20 GMT, Alan Bateman wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> remove newly added trailing space
>
> src/java.base/share/classes/jdk/internal/vm/annotation/JvmtiHideEvents.java
>
On Sat, 26 Oct 2024 06:40:00 GMT, Serguei Spitsyn wrote:
>> Good catch, thanks.
>> These two functions are impacted by temporary VTMS transitions. It seems we
>> fail to hide frames in these transitions while we skip the JVMTI events in
>> their context. I'll try to fix this issue.
>
> I'd sugg
On Mon, 28 Oct 2024 23:15:54 GMT, Vladimir Ivanov wrote:
> As an example, if `IntegerCache.high` is set to `1` during archiving, then
> `ModuleLoaderMap.PLATFORM_LOADER_INDEX=1` ends up pointing to archived
> instance and `ModuleLoaderMap.APP_LOADER_INDEX=2` points to non-archived
> instance w
On Mon, 28 Oct 2024 22:52:40 GMT, Coleen Phillimore wrote:
>> When creating the bitmap, processing oops in an interpreter frame is done
>> with `frame::oops_interpreted_do()` which already counts this extra oop for
>> native methods.
>
> What are we counting now with MaskFillerForNativeFrame th
On Mon, 28 Oct 2024 00:35:11 GMT, David Holmes wrote:
>> This vthread was unmounted on the call to `Object.wait`. Now it is mounted
>> and "running" again, and we need to check which case it is in: notified,
>> interrupted or timed-out. "First time" means it is the first time it's
>> running a
On Mon, 28 Oct 2024 23:21:14 GMT, Dean Long wrote:
>> What are we counting now with MaskFillerForNativeFrame that we weren't
>> counting before this change? in MaskFillerForNative::set_one.
>
> So it sounds like the adjustment at line 119 is a bug fix, but what I don't
> understand is why we w
On Mon, 28 Oct 2024 23:59:55 GMT, Patricio Chilano Mateo
wrote:
>> So it sounds like the adjustment at line 119 is a bug fix, but what I don't
>> understand is why we weren't seeing problems before. Something in this PR
>> exposed the need for this change.
>
>> What are we counting now with M
> 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 Mon, 28 Oct 2024 18:58:29 GMT, Patricio Chilano Mateo
wrote:
> regardless of when you freeze, while doing the freezing the monitor could
> have been released already. So trying to acquire the monitor after freezing
> can always succeed, which means we don't want to unmount but continue
> e
On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev
wrote:
> - It is not clear on which macOS versions codesign fails if application
> bundle contains additional content.
> - As a result test was modified to generate only application image, since PKG
> or DMG cannot be generated if signing fai
On Mon, 28 Oct 2024 18:56:58 GMT, Patricio Chilano Mateo
wrote:
>> The issue with the c2 runtime stub on aarch64 (and riscv) is that
>> cb->frame_size() doesn't match the size of the physical frame, it's short by
>> 2 words. I explained the reason for that in the comment above. So for a
>> re
On Sun, 27 Oct 2024 21:45:08 GMT, Serguei Spitsyn wrote:
>> This fixes a problem in the VTMS (Virtual Thread Mount State) transition
>> frames hiding mechanism.
>> Please, see a fix description in the first comment.
>>
>> Testing:
>> - Verified with new test `vthread/CheckHiddenFrames`
>> - M
> 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, 28 Oct 2024 18:58:51 GMT, Aleksey Shipilev 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.
>>> T
On Mon, 28 Oct 2024 18:09:41 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
On Mon, 28 Oct 2024 10:16:40 GMT, Aleksey Shipilev wrote:
> This is forked from
> [JDK-8342642](https://bugs.openjdk.org/browse/JDK-8342642) and filed as a
> general issue for archived boxed Integer cache when it's recreated at
> runtime. In short, current code drops the entire primitive cache
On Mon, 28 Oct 2024 20:49:45 GMT, Patricio Chilano Mateo
wrote:
>> src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp line 2382:
>>
>>> 2380: __ bind(after_transition);
>>> 2381:
>>> 2382: if (LockingMode != LM_LEGACY && method->is_object_wait0()) {
>>
>> It bothers me that we have to add a che
On Mon, 28 Oct 2024 10:16:40 GMT, Aleksey Shipilev wrote:
> This is forked from
> [JDK-8342642](https://bugs.openjdk.org/browse/JDK-8342642) and filed as a
> general issue for archived boxed Integer cache when it's recreated at
> runtime. In short, current code drops the entire primitive cache
On Mon, 28 Oct 2024 21:13:33 GMT, Patricio Chilano Mateo
wrote:
>> If preemption was cancelled, we skip over the cleanup. The native frames
>> haven't been unwound yet. So when we call thaw, does it cleanup the native
>> frames first, or does it copy the frames back on top of the existing fr
On Fri, 25 Oct 2024 13:12:11 GMT, Patricio Chilano Mateo
wrote:
>> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1275:
>>
>>> 1273:
>>> 1274: if (caller.is_interpreted_frame()) {
>>> 1275: _total_align_size += frame::align_wiggle;
>>
>> Please put a comment here about frame
On Thu, 24 Oct 2024 13:52:57 GMT, Claes Redestad wrote:
> Many OpenJDK micros use `@Fork(jvmArgs/-Append/-Prepend)` to add JVM
> reasonable or necessary flags, but when deploying and running micros we often
> want to add or replace flags to tune to the machine, test different GCs, etc.
> The i
On Mon, 28 Oct 2024 21:01:47 GMT, Patricio Chilano Mateo
wrote:
>> I tried to track down how interpreter_frame_num_oops() is used, and as far
>> as I can tell, it is only used to compare against the bitmap in debug/verify
>> code. So if this slot was added here, shouldn't there be a correspon
On Mon, 28 Oct 2024 20:51:22 GMT, Andrey Turbanov wrote:
>> Many OpenJDK micros use `@Fork(jvmArgs/-Append/-Prepend)` to add JVM
>> reasonable or necessary flags, but when deploying and running micros we
>> often want to add or replace flags to tune to the machine, test different
>> GCs, etc.
On Mon, 28 Oct 2024 22:04:23 GMT, Patricio Chilano Mateo
wrote:
>> It seems somewhat of an oxymoron that to force a slow path we push a
>> fastpath. ???
>
> Yes, I find the name confusing too. But since this is pre-existent and to
> avoid the noise in the PR I would rather not change it here.
On Thu, 24 Oct 2024 13:52:57 GMT, Claes Redestad wrote:
> Many OpenJDK micros use `@Fork(jvmArgs/-Append/-Prepend)` to add JVM
> reasonable or necessary flags, but when deploying and running micros we often
> want to add or replace flags to tune to the machine, test different GCs, etc.
> The i
Hi Michael,
> They would also, files in the app directory, all be automatically code signed
> I think wouldn’t they?
Yes, files under app directory will be signed as well.
Thanks,
Alexander
From: Michael Hall
Date: Friday, October 25, 2024 at 5:52 PM
To: Alexander Matveev
Cc: core-libs-dev
S
> 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 Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev
wrote:
> - It is not clear on which macOS versions codesign fails if application
> bundle contains additional content.
> - As a result test was modified to generate only application image, since PKG
> or DMG cannot be generated if signing fai
On Mon, 28 Oct 2024 10:16:40 GMT, Aleksey Shipilev wrote:
> This is forked from
> [JDK-8342642](https://bugs.openjdk.org/browse/JDK-8342642) and filed as a
> general issue for archived boxed Integer cache when it's recreated at
> runtime. In short, current code drops the entire primitive cache
On Mon, 28 Oct 2024 00:31:27 GMT, David Holmes wrote:
>> It is, we still increment _waiters for the vthread case.
>
> Sorry the target of my comment was not clear. `thread_of_waiter` looks
> suspicious - will JVMTI find the vthread from the JavaThread?
If the ObjectWaiter is associated with a
On Mon, 28 Oct 2024 00:55:34 GMT, David Holmes wrote:
>> H ... I guess we either slow down the monitor code by having the thread
>> search for and remove itself, or we allow for this and handle it correctly
>> ... okay.
>
> That said such a scenario is not about concurrently pushing the sa
On Mon, 28 Oct 2024 00:53:40 GMT, David Holmes wrote:
>> _cont_fastpath is what we check in freeze_internal to decide if we can take
>> the fast path. Since we are calling from the interpreter we have to take the
>> slow path. Added a comment.
>
> It seems somewhat of an oxymoron that to force
On Mon, 28 Oct 2024 20:58:33 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 change
On Fri, 25 Oct 2024 20:13:52 GMT, Roger Riggs wrote:
>> Sean Mullan has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 150 commits:
>>
>> - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>> - Merge
>> - Update
On Mon, 28 Oct 2024 12:29:07 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
On Mon, 15 Apr 2024 19:01:08 GMT, Joe Darcy wrote:
> Get JDK 24 underway.
LGTM
Thanks
test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java line 1:
> 1: /*
There are further updates to this test in the pipeline (new deprecated flags in
23) so you will need to keep updating to refl
On Mon, 21 Oct 2024 14:13:35 GMT, David M. Lloyd wrote:
>> Currently, `ParserVerifier#verifyConstantPool` uses a `switch` to produce a
>> `Runnable`, which is consumed by a `Consumer` (instantiated within
>> a loop) which runs the task inside if a `try`/`catch`. We can eliminate a
>> number of
On Mon, 28 Oct 2024 01:13:05 GMT, David Holmes wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Restore use of atPointA in test StopThreadTest.java
>> - remove interruptible check from conditional in Ob
On Mon, 28 Oct 2024 19:45:08 GMT, Dean Long wrote:
> If preemption was cancelled, we skip over the cleanup.
>
We only skip the cleanup for the enterSpecial frame since we are going to call
thaw again, all other frames are removed:
https://github.com/openjdk/jdk/pull/21565/files#diff-b938ab8a7bd
On Fri, 25 Oct 2024 21:33:24 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 change
On Mon, 28 Oct 2024 12:29:07 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
On Mon, 28 Oct 2024 20:10:16 GMT, Dean Long wrote:
>> It's the offset of the mirror passed to static native calls. It pre-existed
>> saving the mirror in all frames to keep the Method alive, and is duplicated.
>> I think this could be cleaned up someday, which would remove this special
>> ca
On Mon, 15 Apr 2024 19:01:08 GMT, Joe Darcy wrote:
> Get JDK 24 underway.
This pull request has now been integrated.
Changeset: 75dc2f85
Author:Joe Darcy
Committer: Jesper Wilhelmsson
URL:
https://git.openjdk.org/jdk/commit/75dc2f8518d0adea30f7065d6732b807c0220756
Stats: 2083 l
On Tue, 23 Apr 2024 07:03:45 GMT, David Holmes wrote:
> There are further updates to this test in the pipeline (new deprecated flags
> in 23) so you will need to keep updating to reflect that.
Thanks @dholmes-ora ; acknowledged.
-
PR Review Comment: https://git.openjdk.org/jdk/pul
On Mon, 15 Apr 2024 19:01:08 GMT, Joe Darcy wrote:
> Get JDK 24 underway.
This initial version of the PR intentionally excludes the creation of the new
symbol files so that the fundamental code aspects of the update are easier to
see.
-
PR Comment: https://git.openjdk.org/jdk/pul
On Mon, 15 Apr 2024 19:57:49 GMT, Iris Clark wrote:
> The copyright year was not updated in all files *14.java. I assume that's
> intentional.
I'll run my copyright update script before pushing.
> I've also Reviewed the associated CSRs.
Thanks.
> make/conf/version-numbers.conf line 36:
>
>>
On Thu, 30 May 2024 18:39:19 GMT, Chen Liang wrote:
>> Get JDK 24 underway.
>
> src/jdk.compiler/share/data/symbols/jdk.incubator.foreign-N.sym.txt line 1:
>
>> 1: #
>
> Just curious, does CreateSymbols not track module migrations, now that
> jdk.incubator.foreign is completely merged into jav
On Tue, 16 Apr 2024 21:21:43 GMT, Chen Liang wrote:
>> Get JDK 24 underway.
>
> src/java.base/share/classes/java/lang/classfile/ClassFile.java line 1481:
>
>> 1479: int JAVA_23_VERSION = 67;
>> 1480:
>> 1481: /** 68 */
>
> We need `@since 24` here.
Ah, good catch; looks like I was tre
On Mon, 15 Apr 2024 19:01:08 GMT, Joe Darcy wrote:
> Get JDK 24 underway.
ClassFile changes are OK.
-
Marked as reviewed by asotona (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/18787#pullrequestreview-2005504192
On Mon, 15 Apr 2024 19:01:08 GMT, Joe Darcy wrote:
> Get JDK 24 underway.
The copyright year was not updated in all files *14.java. I assume that's
intentional.
I've also Reviewed the associated CSRs.
Marked as reviewed by iris (Reviewer).
Marked as reviewed by iris (Reviewer).
Still loo
On Mon, 15 Apr 2024 19:01:08 GMT, Joe Darcy wrote:
> Get JDK 24 underway.
src/java.base/share/classes/java/lang/classfile/ClassFile.java line 1481:
> 1479: int JAVA_23_VERSION = 67;
> 1480:
> 1481: /** 68 */
We need `@since 24` here.
src/jdk.compiler/share/data/symbols/jdk.incubator.
On Wed, 6 Jul 2022 20:49:25 GMT, John R Rose wrote:
> The code examples in these files were exdented to make it easier to extract
> example code and test it, and to maintain equivalence during active
> development of the APIs.
>
> The examples in runnable form are in
> test/jdk/java/lang/invo
On Wed, 6 Jul 2022 00:08:04 GMT, Chen Liang wrote:
>> Update existing examples in java.lang.invoke.{MethodHandle, MethodHandles}
>> to use snippets rather than the older markup idiom.
>
> src/java.base/share/classes/java/lang/invoke/MethodHandle.java line 272:
>
>> 270: * Here are some exampl
On Mon, 15 Apr 2024 19:01:08 GMT, Joe Darcy wrote:
> Get JDK 24 underway.
lgtm
-
Marked as reviewed by vromero (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/18787#pullrequestreview-2004323374
Get JDK 24 underway.
-
Commit messages:
- Update copyright.
- Updated problem list after bug fix.
- Merge branch 'master' into JDK-8330188
- Merge branch 'master' into JDK-8330188
- Temporarily problem list java.lang.instrument tests until jar generation is
fixed.
- Merge branc
On Tue, 5 Jul 2022 22:22:46 GMT, Joe Darcy wrote:
> Update existing examples in java.lang.invoke.{MethodHandle, MethodHandles}
> to use snippets rather than the older markup idiom.
This pull request has now been integrated.
Changeset: a40c17b7
Author:Joe Darcy
URL:
https://git.ope
On Fri, 25 Oct 2024 20:57:09 GMT, Alexey Semenyuk wrote:
> - merge EmptyFolderTest, EmptyFolderPackageTest and EmptyFolderTestBase in
> EmptyFolderTest class.
> - for .msi packaging still verify the output. It should not contain empty
> folders from `--input`, but should contain other folders
On Tue, 5 Jul 2022 22:22:46 GMT, Joe Darcy wrote:
> Update existing examples in java.lang.invoke.{MethodHandle, MethodHandles}
> to use snippets rather than the older markup idiom.
The code examples in these files were exdented to make it easier to extract
example code and test it, and to mai
On Tue, 5 Jul 2022 22:22:46 GMT, Joe Darcy wrote:
> Update existing examples in java.lang.invoke.{MethodHandle, MethodHandles}
> to use snippets rather than the older markup idiom.
In addition, I believe we can add link in many examples, but I am not sure if
this is part of this issue or if i
Update existing examples in java.lang.invoke.{MethodHandle, MethodHandles} to
use snippets rather than the older markup idiom.
-
Commit messages:
- JDK-8289775: Update java.lang.invoke.MethodHandle[s] to use snippets
Changes: https://git.openjdk.org/jdk/pull/9385/files
Webrev: h
On Mon, 28 Oct 2024 13:12:22 GMT, Richard Reingruber wrote:
>> src/hotspot/share/runtime/objectMonitor.hpp line 202:
>>
>>> 200:
>>> 201: // Used in LM_LEGACY mode to store BasicLock* in case of inflation
>>> by contending thread.
>>> 202: BasicLock* volatile _stack_locker;
>>
>> IIUC the
On Mon, 28 Oct 2024 10:37:21 GMT, Yudi Zheng wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Restore use of atPointA in test StopThreadTest.java
>> - remove interruptible check from conditional in Obje
On Mon, 28 Oct 2024 07:55:02 GMT, Richard Reingruber wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Restore use of atPointA in test StopThreadTest.java
>> - remove interruptible check from conditional
> 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 Thu, 24 Oct 2024 03:01:54 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 Thu, 24 Oct 2024 13:52:57 GMT, Claes Redestad wrote:
> Many OpenJDK micros use `@Fork(jvmArgs/-Append/-Prepend)` to add JVM
> reasonable or necessary flags, but when deploying and running micros we often
> want to add or replace flags to tune to the machine, test different GCs, etc.
> The i
On Mon, 28 Oct 2024 17:30:44 GMT, Patricio Chilano Mateo
wrote:
>> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 159:
>>
>>> 157:
>>> 158: // The interpreter native wrapper code adds space in the stack equal
>>> to size_of_parameters()
>>> 159: // after the fixed
On Mon, 28 Oct 2024 12:29:07 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
On Mon, 28 Oct 2024 16:39:14 GMT, Coleen Phillimore wrote:
>> src/hotspot/cpu/aarch64/stackChunkFrameStream_aarch64.inline.hpp line 119:
>>
>>> 117: return mask.num_oops()
>>> 118: + 1 // for the mirror oop
>>> 119: + (f.interpreter_frame_method()->is_native() ? 1 : 0) // temp
On Sat, 26 Oct 2024 07:04:28 GMT, Richard Reingruber wrote:
>> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 3796:
>>
>>> 3794: __ movbool(rscratch1, Address(r15_thread,
>>> JavaThread::preemption_cancelled_offset()));
>>> 3795: __ testbool(rscratch1);
>>> 3796: __ jcc(Assembler::notZ
On Mon, 28 Oct 2024 18:15:38 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 Mon, 28 Oct 2024 18:09:41 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
On Mon, 28 Oct 2024 12:29:07 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
On Mon, 28 Oct 2024 12:29:07 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
On Sat, 26 Oct 2024 06:56:50 GMT, Richard Reingruber wrote:
>> src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1567:
>>
>>> 1565:
>>> 1566: // In case of preemption, this is where we will resume once we
>>> finally acquire the monitor.
>>> 1567: bind(resume_pc);
>>
>> If the idea is
On Mon, 28 Oct 2024 18:51:31 GMT, Dean Long wrote:
>> Its indeed difficult to see how the value is propagaged. I think it goes
>> like this:
>>
>> - read from the frame anchor and set as pc of `_last_frame`:
>> https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/h
1 - 100 of 175 matches
Mail list logo
