On Tue, 24 Sep 2024 04:33:14 GMT, Jaikiran Pai wrote:
> Can I please get a review of this cleanup to the launcher code to remove
> declarations of unused functions?
>
> The `ValidateModules` function appears to be a left-over from
> https://bugs.openjdk.org/browse/JDK-8194937.
>
> The `SetApp
On Mon, 23 Sep 2024 08:05:55 GMT, Matthias Baesken wrote:
> We still check for PROCESSOR_ARCHITECTURE_IA64 but this is not supported any
> more for a very long time in OpenJDK.
Filed [JDK-8340731](https://bugs.openjdk.org/browse/JDK-8340731) for HS cleanup
-
PR Comment: https://gi
On Mon, 23 Sep 2024 10:35:44 GMT, Maurizio Cimadamore
wrote:
> It is outside the scope of the javadoc text to state exactly why each
> restricted method is marked as such.
I don't agree. I think restricted methods should document why they are
restricted if it is not patently obvious.
--
On Mon, 23 Sep 2024 17:33:16 GMT, Ioi Lam wrote:
>> This is the 1st PR for [JEP 483: Ahead-of-Time Class Loading &
>> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>>
>> Add the following command-line options as specified in JEP 483:
>>
>>
>> - `-XX:AOTMode=off/record/create/auto/on`
On Fri, 20 Sep 2024 18:16:57 GMT, Calvin Cheung wrote:
>> Prior to this patch, if `--module-path` is specified in the command line:
>> during CDS dump time, full module graph will not be included in the CDS
>> archive;
>> during run time, full module graph will not be used.
>>
>> With this patc
On Tue, 24 Sep 2024 01:22:25 GMT, Ioi Lam wrote:
>> This is the 6th PR for [JEP 483: Ahead-of-Time Class Loading &
>> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>>
>> The implementation of java.lang.invoke uses SoftReferences so that unused
>> MethodHandles, LambdaForms, etc, can b
On Mon, 23 Sep 2024 08:42:43 GMT, Alan Bateman wrote:
> Is your ask that the javadoc generated text inline this, or the equivalent by
> change the method description of each restricted method?
I admit I had missed the fact there would be some auto-generated text and links
in the API docs for
On Mon, 23 Sep 2024 09:33:27 GMT, Alan Bateman wrote:
>> I suggested the current wording here:
>> https://github.com/openjdk/jdk/pull/21067#discussion_r1767316787
>>
>> I think 'no caller on the stack' is too vague. AFAICT, the mechanism by
>> which a CS method determines its caller is not doc
On Mon, 23 Sep 2024 08:05:55 GMT, Matthias Baesken wrote:
> We still check for PROCESSOR_ARCHITECTURE_IA64 but this is not supported any
> more for a very long time in OpenJDK.
Seems fine.
I thought we had eradicated ia64 from the codebase but it seems we missed a few
things in hotspot too. :
On Mon, 23 Sep 2024 05:11:34 GMT, Jaikiran Pai wrote:
> Can I please get a review of this trivial change which removes dead code from
> the `RequiresSetenv()` function?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8340596 this appears to be a
> left-over from the changes in https://bugs
On Mon, 23 Sep 2024 04:47:52 GMT, Jaikiran Pai wrote:
>> src/java.base/share/native/libjli/java.c line 1405:
>>
>>> 1403: * when launching java. It may be null, which implies the "-splash:"
>>> option wasn't used.
>>> 1404: * The jar_path is the value that was provided to the "-jar" option
>
een introduced in this PR and tier testing is currently
>> in progress.
>
> Jaikiran Pai has updated the pull request incrementally with three additional
> commits since the last revision:
>
> - David's review for code comment
>
>Co-authored-
On Mon, 23 Sep 2024 04:33:50 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to remove the
>> (internal) `SelectVersion()` function from the java launcher and also update
>> the code comments in the launcher to match the current implementation?
>>
>> As note
On Thu, 19 Sep 2024 07:40:43 GMT, Matthias Baesken wrote:
> Windows Server 2025 will be releases in a few months.
> The OS detection code of the JVM/JDK should recognize the new Windows server
> 2025 version.
> (currently Windows server 2022 is printed , that is wrong)
>
> The build numbers of
On Fri, 20 Sep 2024 08:48:50 GMT, Maurizio Cimadamore
wrote:
> Just be clarify: is it your expectation that, in order for this issue to be
> fixed, we should fix the javadoc of all caller sensitive methods, addressing
> issues that have nothing to do with restricted-ness?
No, just the new res
On Thu, 19 Sep 2024 12:29:34 GMT, Maurizio Cimadamore
wrote:
> And I claim that this is outside the scope of this PR.
And I strongly disagree because the only reason I conceded that this
documentation issue need not be addressed by the CSR request for JEP 472 was
because JDK-8338596 was filed
On Thu, 19 Sep 2024 22:06:14 GMT, Mat Carter wrote:
>> src/hotspot/share/runtime/flags/jvmFlagConstraintsRuntime.cpp line 40:
>>
>>> 38: strcmp(value, "create") != 0 &&
>>> 39: strcmp(value, "auto") != 0 &&
>>> 40: strcmp(value, "on")) {
>>
>> This should be strcmp(value, "on"
On Wed, 18 Sep 2024 18:03:47 GMT, Jorn Vernee wrote:
>> This PR moves the section on restricted methods from the the javadoc of
>> `java.lang.foreign` package into a standalone static [javadoc
>> page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/la
On Wed, 18 Sep 2024 15:47:01 GMT, Maurizio Cimadamore
wrote:
> This PR moves the section on restricted methods from the the javadoc of
> `java.lang.foreign` package into a standalone static [javadoc
> page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/j
On Wed, 18 Sep 2024 18:07:52 GMT, Jorn Vernee wrote:
> Is the java/lang/foreign package still the right place for this? (Maybe it
> should be under java/lang).
I agree, the scope for this is now outside the foreign package.
-
PR Comment: https://git.openjdk.org/jdk/pull/21067#issu
On Wed, 18 Sep 2024 03:04:50 GMT, Ioi Lam wrote:
>> This is the 6th PR for [JEP 483: Ahead-of-Time Class Loading &
>> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>>
>> The implementation of java.lang.invoke uses SoftReferences so that unused
>> MethodHandles, LambdaForms, etc, can b
On Tue, 17 Sep 2024 11:27:39 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to remove the
>> (internal) `SelectVersion()` function from the java launcher and also update
>> the code comments in the launcher to match the current implementation?
>>
>> As note
On Tue, 17 Sep 2024 23:44:40 GMT, Calvin Cheung wrote:
> Prior to this patch, if `--module-path` is specified in the command line:
> during CDS dump time, full module graph will not be included in the CDS
> archive;
> during run time, full module graph will not be used.
>
> With this patch, the
On Tue, 17 Sep 2024 23:48:11 GMT, Ioi Lam wrote:
> This is the 6th PR for [JEP 483: Ahead-of-Time Class Loading &
> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>
> The implementation of java.lang.invoke uses SoftReferences so that unused
> MethodHandles, LambdaForms, etc, can be gar
On Mon, 16 Sep 2024 13:55:49 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to remove the
>> (internal) `SelectVersion()` function from the java launcher and also update
>> the code comments in the launcher to match the current implementation?
>>
>> As note
On Mon, 16 Sep 2024 14:02:21 GMT, Jaikiran Pai wrote:
>> In the context of the 2 platforms - macosx and unix, the recursive
>> invocation still continues to happen.
>>
>> For macosx, the `CreateExecutionEnvironment` unconditionally, through an
>> internal `MacOSXStartup` function, spawns a new
On Tue, 17 Sep 2024 06:28:54 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to deprecate several
> outdated and undocumented java launcher options? This addresses
> https://bugs.openjdk.org/browse/JDK-8286851.
>
> Specifically, the non-standard launcher opti
On Mon, 16 Sep 2024 06:16:56 GMT, Jaikiran Pai wrote:
>> src/java.base/share/native/libjli/java.c line 38:
>>
>>> 36: * One job of the launcher is to remove command line options which the
>>> 37: * vm does not understand and will not process. These options include
>>> 38: * options which sele
On Mon, 16 Sep 2024 04:44:39 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this change which cleans up the `java`
>> launcher to remove checks/support for outdated options?
>>
>> As noted in https://bugs.openjdk.org/browse/JDK-8339918, these 6 options
>> have been outdated and unsu
On Mon, 16 Sep 2024 04:15:28 GMT, Jaikiran Pai wrote:
>> src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java line 991:
>>
>>> 989:// Old-style options (These should remain in place
>>> as long as
>>> 990:// the standard VM accepts them)
>>
On Mon, 16 Sep 2024 03:56:39 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this change which cleans up the `java`
>> launcher to remove checks/support for outdated options?
>>
>> As noted in https://bugs.openjdk.org/browse/JDK-8339918, these 6 options
>> have been outdated and unsu
On Mon, 16 Sep 2024 01:29:45 GMT, Jaikiran Pai wrote:
>> src/java.base/share/native/libjli/java.c line 1345:
>>
>>> 1343: if (JLI_StrCCmp(arg, "-Djava.class.path=") == 0) {
>>> 1344: _have_classpath = JNI_TRUE;
>>> 1345: } else if (JLI_StrCmp(arg, "-Djava.
On Fri, 13 Sep 2024 12:29:26 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to remove the
> (internal) `SelectVersion()` function from the java launcher and also update
> the code comments in the launcher to match the current implementation?
>
> As noted in
On Sat, 14 Sep 2024 16:08:00 GMT, Bernd wrote:
> What about `-Xdebug` it’s deprecated for remove. It’s not yet moved to the
> obsolete section of the manual. And we could also remove it from the -X
> command line help.
If it is deprecated then it goes in the Deprecated section. The obsoleted
On Fri, 13 Sep 2024 06:25:48 GMT, Per Minborg wrote:
> This PR fixes a regression introduced by
> https://github.com/openjdk/jdk/pull/20848
LGTM! Thanks for the quick fix.
-
Marked as reviewed by dholmes (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/20983#pullrequestrev
On Thu, 12 Sep 2024 23:11:31 GMT, Justin Lu wrote:
>> Please review this PR which restores the correct exception message when the
>> current working directory can not be found during java startup in
>> `initPhase1`.
>>
>> Both MacOS and Linux are expected to fail with `java.lang.Error: Propert
On Wed, 11 Sep 2024 11:42:19 GMT, Viktor Klang wrote:
>> This PR applies @AlanBateman's patch from the JBS issue.
>
> Viktor Klang has refreshed the contents of this pull request, and previous
> commits have been removed. The incremental views will show differences
> compared to the previous co
On Tue, 10 Sep 2024 06:15:57 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which cleans up the code in the
> `java` launcher? The original motivation for the change was to prevent the
> `java` launcher's C code from parsing a jar's manifest when launching an
> application
On Wed, 11 Sep 2024 09:47:24 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change which cleans up the `java` launcher
> to remove checks/support for outdated options?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8339918, these 6 options have
> been outdated and unsupport
On Tue, 10 Sep 2024 21:01:24 GMT, Viktor Klang wrote:
>> This PR applies @AlanBateman's patch from the JBS issue.
>
> Viktor Klang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Removing ThreadSleepEvent from stack trace checks
If these a
On Tue, 10 Sep 2024 21:01:24 GMT, Viktor Klang wrote:
>> This PR applies @AlanBateman's patch from the JBS issue.
>
> Viktor Klang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Removing ThreadSleepEvent from stack trace checks
With regar
On Tue, 10 Sep 2024 19:23:16 GMT, Brent Christian wrote:
>> From the bug description:
>> ForceGC would be improved by moving the Reference.reachabilityFence() calls
>> for 'obj' and 'ref'.
>>
>> Reference.reachabilityFence(obj) is currently placed after 'obj' has been
>> set to null, so effect
On Tue, 10 Sep 2024 11:10:38 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this trivial change which replaces the usages
>> of `-mx` and `-ms` to `-Xmx` and `-Xms` in tests and in one code comment?
>>
>> As noted in https://bugs.openjdk.org/browse/JDK-8339834, these options are
>> o
On Tue, 10 Sep 2024 11:07:30 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this trivial change which replaces the usages
>> of `-mx` and `-ms` to `-Xmx` and `-Xms` in tests and in one code comment?
>>
>> As noted in https://bugs.openjdk.org/browse/JDK-8339834, these options are
>> o
On Mon, 9 Sep 2024 09:50:59 GMT, SendaoYan wrote:
> Hi all,
> This PR delete tedious bool type define in
> `src/java.base/unix/native/libjsig/jsig.c` and
> `src/utils/hsdis/binutils/hsdis-binutils.c`. After JEP
> 347([JDK-8246032](https://bugs.openjdk.org/browse/JDK-8246032)), I think we
>
On Mon, 9 Sep 2024 09:50:59 GMT, SendaoYan wrote:
> Hi all,
> This PR delete tedious bool type define in
> `src/java.base/unix/native/libjsig/jsig.c` and
> `src/utils/hsdis/binutils/hsdis-binutils.c`. After JEP
> 347([JDK-8246032](https://bugs.openjdk.org/browse/JDK-8246032)), I think we
>
On Fri, 6 Sep 2024 19:57:41 GMT, Brent Christian wrote:
> From the bug description:
> ForceGC would be improved by moving the Reference.reachabilityFence() calls
> for 'obj' and 'ref'.
>
> Reference.reachabilityFence(obj) is currently placed after 'obj' has been set
> to null, so effectively d
On Mon, 9 Sep 2024 16:25:15 GMT, Stuart Marks wrote:
>> @dholmes-ora Is this really possible? The `obj` ref is passed to the
>> PhantomReference constructor, which stores it in a field, the constructed
>> PhantomReference is returned, and it's then used in a reachabilityFence call
>> below. So
On Sat, 7 Sep 2024 00:39:16 GMT, Stuart Marks wrote:
>> From the bug description:
>> ForceGC would be improved by moving the Reference.reachabilityFence() calls
>> for 'obj' and 'ref'.
>>
>> Reference.reachabilityFence(obj) is currently placed after 'obj' has been
>> set to null, so effectivel
On Wed, 4 Sep 2024 11:55:50 GMT, Jorn Vernee wrote:
>> It does return. `ShouldNotReachHere` is used to crash the VM.
>
> `fatal()` might be better here. I could change it.
Yes please do.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/20479#discussion_r1745356400
On Fri, 30 Aug 2024 02:07:54 GMT, David Holmes wrote:
> This is the implementation of a new method added to the JNI specification.
>
> From the CSR request:
>
> The `GetStringUTFLength` function returns the length as a `jint` (`jsize`)
> value and so is limited to
On Tue, 6 Aug 2024 17:26:55 GMT, Jorn Vernee wrote:
> As discussed in the JBS issue:
>
> FFM upcall stubs embed a `Method*` of the target method in the stub. This
> `Method*` is read from the `LambdaForm::vmentry` field associated with the
> target method handle at the time when the upcall stu
On Tue, 3 Sep 2024 20:50:09 GMT, Chris Plummer wrote:
>> David Holmes has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> The JNI version update was incompete
>
> Marked as reviewed by cjplummer
On Tue, 3 Sep 2024 06:01:15 GMT, Alan Bateman wrote:
>> David Holmes has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> The JNI version update was incompete
>
> Marked as reviewed by alanb (R
On Tue, 3 Sep 2024 05:52:31 GMT, Magnus Ihse Bursie wrote:
>> This code is devoid of pretty much all error handling and logging, but I
>> agree that a simple fprintf on error would be useful.
>> Also doesn't a call like this trigger the warning about ignoring a function
>> result, or have we di
along with the new method entries.
>
> Testing:
> - new test added
> - tiers 1-3 sanity
>
> Thanks
David Holmes has updated the pull request incrementally with one additional
commit since the last revision:
The JNI version update was incompete
-
Changes:
- all:
On Fri, 30 Aug 2024 20:45:11 GMT, Chris Plummer wrote:
>> David Holmes has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Exclude test on 32-bit
>
> Overall it looks good to me, although I don't have expe
On Mon, 2 Sep 2024 22:32:34 GMT, Magnus Ihse Bursie wrote:
>> Matthias Baesken has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> adjust indentation in X11Color.c
>
> src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c line 744:
On Mon, 2 Sep 2024 09:05:17 GMT, Alan Bateman wrote:
>> David Holmes has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Exclude test on 32-bit
>
> Deprecating the existing function and introducing the new func
On Sun, 1 Sep 2024 16:30:33 GMT, Julian Waters wrote:
> This does make me wonder: What if the new method for checking if the VM was
> statically linked was inlined? Then the problem comes back yet again as the
> object files need to be recompiled once more. This is possible if Link Time
> Opti
On Fri, 30 Aug 2024 20:45:11 GMT, Chris Plummer wrote:
>> David Holmes has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Exclude test on 32-bit
>
> Overall it looks good to me, although I don't have expe
On Fri, 30 Aug 2024 10:51:30 GMT, Magnus Ihse Bursie wrote:
>> I understand the cost overhead experienced by any individual Java run may be
>> lost in the noise, but it still impacts every single Java run just to save
>> some time/resources for the handful of builders of statically linked VMs.
On Fri, 30 Aug 2024 05:11:30 GMT, Chris Plummer wrote:
>> David Holmes has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Exclude test on 32-bit
>
> test/hotspot/jtreg/runtime/jni/checked/TestLargeUTF8Length.j
along with the new method entries.
>
> Testing:
> - new test added
> - tiers 1-3 sanity
>
> Thanks
David Holmes has updated the pull request incrementally with one additional
commit since the last revision:
Exclude test on 32-bit
-
Changes:
- all: https://g
This is the implementation of a new method added to the JNI specification.
>From the CSR request:
The `GetStringUTFLength` function returns the length as a `jint` (`jsize`)
value and so is limited to returning at most `Integer.MAX_VALUE`. But a Java
string can itself consist of `Integer.MAX_VAL
On Thu, 29 Aug 2024 22:11:36 GMT, Ioi Lam wrote:
>> This is the 1st PR for [JEP 483: Ahead-of-Time Class Loading &
>> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>>
>> Add the following command-line options as specified in JEP 483:
>>
>>
>> - `-XX:AOTMode=off/record/create/auto/on`
On Thu, 29 Aug 2024 05:05:58 GMT, David Holmes wrote:
>> Ioi Lam 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 contains five
On Thu, 29 Aug 2024 04:24:02 GMT, Ioi Lam wrote:
>> This is the 1st PR for [JEP 483: Ahead-of-Time Class Loading &
>> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>>
>> Add the following command-line options as specified in JEP 483:
>>
>>
>> - `-XX:AOTMode=off/record/create/auto/on`
On Wed, 21 Aug 2024 22:14:40 GMT, Magnus Ihse Bursie wrote:
>> As a preparation for Hermetic Java, we need to have a way to look up during
>> runtime if we are using a statically linked library or not.
>>
>> This change will be the first step needed towards compiling the object files
>> only o
On Sat, 24 Aug 2024 05:12:42 GMT, Julian Waters wrote:
>> snprintf has been available for all officially and unofficially supported
>> compilers for Windows, Visual Studio since version 2015 and gcc since, well,
>> forever. snprintf is conforming to C99 since the start when compiling using
>>
On Thu, 22 Aug 2024 08:54:56 GMT, Magnus Ihse Bursie wrote:
>> Sorry but I don't understand the point of changing build-time constructs
>> using `ifdef STATIC_BUILD` into what appear to be runtime checks, but the
>> result of which is already determined at build time. These are not really
>> r
On Wed, 21 Aug 2024 22:14:40 GMT, Magnus Ihse Bursie wrote:
>> As a preparation for Hermetic Java, we need to have a way to look up during
>> runtime if we are using a statically linked library or not.
>>
>> This change will be the first step needed towards compiling the object files
>> only o
On Thu, 15 Aug 2024 11:20:23 GMT, Markus Grönlund wrote:
>> Greetings,
>>
>> Explicitly pin a virtual thread before acquiring the JFR string pool monitor
>> because migrating a carrier thread local event writer object onto another
>> carrier thread is impossible.
>>
>> During event commit, th
On Thu, 15 Aug 2024 08:58:46 GMT, David Holmes wrote:
>> I assume you both mean I should change "elapses" to "elapsed" throughout the
>> PR, not just in that particular occurrence.
>
> No, elsewhere you don't have an existing tense to match - I only
On Thu, 15 Aug 2024 08:24:30 GMT, Pavel Rappo wrote:
>> Use "elapsed" here to match "completed".
>
> I assume you both mean I should change "elapses" to "elapsed" throughout the
> PR, not just in that particular occurrence.
No, elsewhere you don't have an existing tense to match - I only want t
On Wed, 14 Aug 2024 20:53:33 GMT, Markus Grönlund wrote:
> Greetings,
>
> Explicitly pin a virtual thread before acquiring the JFR string pool monitor
> because migrating a carrier thread local event writer object onto another
> carrier thread is impossible.
>
> During event commit, the threa
On Wed, 14 Aug 2024 22:11:39 GMT, Pavel Rappo wrote:
>> src/java.base/share/classes/java/util/concurrent/ForkJoinTask.java line 1075:
>>
>>> 1073: /**
>>> 1074: * Tries to join this task, returning true if it completed
>>> 1075: * (possibly exceptionally) before the given timeout e
On Mon, 12 Aug 2024 16:11:46 GMT, Viktor Klang wrote:
>> 8336384: AbstractQueuedSynchronizer.acquire should cancel acquire when
>> failing due to a LinkageError or other errors
>
> Viktor Klang has updated the pull request incrementally with one additional
> commit since the last revision:
>
>
On Tue, 13 Aug 2024 16:30:12 GMT, Axel Boldt-Christmas
wrote:
>> When inflating a monitor the `ObjectMonitor*` is written directly over the
>> `markWord` and any overwritten data is displaced into a displaced
>> `markWord`. This is problematic for concurrent GCs which needs extra care or
>> l
On Tue, 13 Aug 2024 08:02:04 GMT, Alan Bateman wrote:
> > It has been a while since I knew this code reasonably well so perhaps I
> > have just forgotten this difference between AQS and built-in monitors, but
> > it seems that a Condition.await can return by throwing an exception without
> > r
On Mon, 12 Aug 2024 16:11:46 GMT, Viktor Klang wrote:
>> 8336384: AbstractQueuedSynchronizer.acquire should cancel acquire when
>> failing due to a LinkageError or other errors
>
> Viktor Klang has updated the pull request incrementally with one additional
> commit since the last revision:
>
>
On Mon, 12 Aug 2024 21:37:45 GMT, Doug Lea wrote:
>> src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java
>> line 381:
>>
>>> 379: else
>>> 380: break;
>>> 381: } catch (Error | RuntimeException ex
On Fri, 19 Jul 2024 08:26:51 GMT, Alan Bateman wrote:
>> Before RC we need to update the man pages in the repo from their Markdown
>> sources. All pages at a minimum have 23-ea replaced with 23, and publication
>> year set to 2024 if needed.
>>
>> This also picks up the unpublished changes to
On Fri, 19 Jul 2024 05:47:15 GMT, David Holmes wrote:
> Before RC we need to update the man pages in the repo from their Markdown
> sources. All pages at a minimum have 23-ea replaced with 23, and publication
> year set to 2024 if needed.
>
> This also picks up the unpublished
On Fri, 19 Jul 2024 05:47:15 GMT, David Holmes wrote:
> Before RC we need to update the man pages in the repo from their Markdown
> sources. All pages at a minimum have 23-ea replaced with 23, and publication
> year set to 2024 if needed.
>
> This also picks up the unpublished
Before RC we need to update the man pages in the repo from their Markdown
sources. All pages at a minimum have 23-ea replaced with 23, and publication
year set to 2024 if needed.
This also picks up the unpublished changes to java.1 from:
- [JDK-8324836](https://bugs.openjdk.org/browse/JDK-83248
On Thu, 18 Jul 2024 13:48:06 GMT, Chen Liang wrote:
>> `Class` has 2 VM-injected fields that can be made explicit: `Object[]
>> signers` and `ProtectionDomain protectionDomain`. We make the signers field
>> explicit. (The ProtectionDomain can be revisited when SecurityManager is
>> removed, as
On Thu, 18 Jul 2024 13:48:06 GMT, Chen Liang wrote:
>> `Class` has 2 VM-injected fields that can be made explicit: `Object[]
>> signers` and `ProtectionDomain protectionDomain`. We make the signers field
>> explicit. (The ProtectionDomain can be revisited when SecurityManager is
>> removed, as
On Wed, 17 Jul 2024 19:47:44 GMT, Chen Liang wrote:
> `Class` has 2 VM-injected fields that can be made explicit: `Object[]
> signers` and `ProtectionDomain protectionDomain`. We make the signers field
> explicit. (The ProtectionDomain can be revisited when SecurityManager is
> removed, as Sec
On Mon, 15 Jul 2024 00:50:30 GMT, Axel Boldt-Christmas
wrote:
>> When inflating a monitor the `ObjectMonitor*` is written directly over the
>> `markWord` and any overwritten data is displaced into a displaced
>> `markWord`. This is problematic for concurrent GCs which needs extra care or
>> l
On Mon, 15 Jul 2024 00:50:30 GMT, Axel Boldt-Christmas
wrote:
>> When inflating a monitor the `ObjectMonitor*` is written directly over the
>> `markWord` and any overwritten data is displaced into a displaced
>> `markWord`. This is problematic for concurrent GCs which needs extra care or
>> l
On Mon, 15 Jul 2024 00:50:30 GMT, Axel Boldt-Christmas
wrote:
>> When inflating a monitor the `ObjectMonitor*` is written directly over the
>> `markWord` and any overwritten data is displaced into a displaced
>> `markWord`. This is problematic for concurrent GCs which needs extra care or
>> l
On Wed, 17 Jul 2024 06:39:14 GMT, David Holmes wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with 10
>> additional commits since the last revision:
>>
>> - Remove try_read
>> - Add explicit to single parameter constructors
>> -
On Mon, 15 Jul 2024 00:50:30 GMT, Axel Boldt-Christmas
wrote:
>> When inflating a monitor the `ObjectMonitor*` is written directly over the
>> `markWord` and any overwritten data is displaced into a displaced
>> `markWord`. This is problematic for concurrent GCs which needs extra care or
>> l
On Mon, 15 Jul 2024 00:50:30 GMT, Axel Boldt-Christmas
wrote:
>> When inflating a monitor the `ObjectMonitor*` is written directly over the
>> `markWord` and any overwritten data is displaced into a displaced
>> `markWord`. This is problematic for concurrent GCs which needs extra care or
>> l
On Tue, 16 Jul 2024 08:59:20 GMT, Julian Waters wrote:
>> snprintf has been available for all officially and unofficially supported
>> compilers for Windows, Visual Studio since version 2015 and gcc since, well,
>> forever. snprintf is conforming to C99 since the start when compiling using
>>
On Wed, 17 Jul 2024 02:57:51 GMT, Chen Liang wrote:
>> What would be the terminology for a final field that's set by hotspot,
>> against the regular java constrcutor rules?
>
> I have chosen the wording "all final fields are used by the VM"
I don't know of any specific terminology - we typicall
On Wed, 17 Jul 2024 03:03:23 GMT, Chen Liang wrote:
>> Move fields common to Method and Field to executable, which simplifies
>> implementation. Removed useless transient modifiers as Method and Field were
>> never serializable.
>
> Chen Liang has updated the pull request incrementally with one
On Tue, 16 Jul 2024 03:45:36 GMT, Chen Liang wrote:
> Move fields common to Method and Field to executable, which simplifies
> implementation. Removed useless transient modifiers as Method and Field were
> never serializable.
Hotspot changes look good. Core-libs do too but I will leave that fo
On Tue, 16 Jul 2024 03:45:36 GMT, Chen Liang wrote:
> Move fields common to Method and Field to executable
s/Field/Constructor
I was a bit confused about executable fields for a moment. :)
-
PR Comment: https://git.openjdk.org/jdk/pull/20188#issuecomment-2231889229
1 - 100 of 690 matches
Mail list logo
