On Tue, 15 Oct 2024 22:15:45 GMT, Sean Mullan wrote:
>> src/java.base/share/classes/java/lang/SecurityManager.java line 72:
>>
>>> 70: private static class StackWalkerHolder {
>>> 71: static final StackWalker STACK_WALKER =
>>> 72:
>>> StackWalker.getInstance(StackWalker
On Fri, 11 Oct 2024 06:43:33 GMT, Axel Boldt-Christmas
wrote:
>> This is the implementation task for `JEP 490: ZGC: Remove the
>> Non-Generational Mode`. See the JEP for details.
>> [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)
>
> Axel Boldt-Christmas has updated the pull request
On Wed, 16 Oct 2024 01:10:55 GMT, Serguei Spitsyn wrote:
>> There is a race between JVMTI NotifyFramePop function and FramePop event
>> posting code.
>> The fix is to return JVMTI_ERROR_OPAQUE_FRAME if if a FramePop event with
>> depth 0 is requested by NotifyFramePop at the time when the targe
> There is a race between JVMTI NotifyFramePop function and FramePop event
> posting code.
> The fix is to return JVMTI_ERROR_OPAQUE_FRAME if if a FramePop event with
> depth 0 is requested by NotifyFramePop at the time when the target frame is
> in exit epilogue, and MethodExit/FramePop events
On Wed, 16 Oct 2024 00:49:39 GMT, Chris Plummer wrote:
>> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/NotifyFramePopStressTest.java
>> line 103:
>>
>>> 101: }
>>> 102: }
>>> 103: if (waitCount > 50) {
>>
>> Is 50 is enough her
On Tue, 15 Oct 2024 23:50:42 GMT, Alex Menkov wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> minor comment tweak
>
> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStre
On Wed, 16 Oct 2024 00:30:49 GMT, Alex Menkov wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> minor comment tweak
>
> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/NotifyFramePopStressT
On Wed, 16 Oct 2024 00:28:03 GMT, Alex Menkov wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> minor comment tweak
>
> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/NotifyFramePopStressT
On Wed, 16 Oct 2024 00:28:40 GMT, Alex Menkov wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> minor comment tweak
>
> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/NotifyFramePopStressT
On Wed, 16 Oct 2024 00:45:17 GMT, Chris Plummer wrote:
>> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStressTest.cpp
>> line 169:
>>
>>> 167: err= jvmti->NotifyFramePop(thread, 0);
>>> 168: if (err == JVMTI_ERROR_OPAQUE_FRAME || err == JVMTI_ERRO
On Tue, 15 Oct 2024 23:55:52 GMT, Alex Menkov wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> minor comment tweak
>
> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStre
On Tue, 15 Oct 2024 23:45:15 GMT, Alex Menkov wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> minor comment tweak
>
> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStre
On Wed, 31 Jul 2024 19:10:41 GMT, Henry Lin wrote:
> Adds a command line option `-redact` to `jcmd` and `-XX:+HeapDumpRedacted`
> enabling redacted heap dumps. When enabled, the output binary heap dump has
> zeroes written out in place of the original primitive values in the object
> fields. T
On Tue, 15 Oct 2024 23:44:08 GMT, Alex Menkov wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> minor comment tweak
>
> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/NotifyFramePopStressT
> There is a race between JVMTI NotifyFramePop function and FramePop event
> posting code.
> The fix is to return JVMTI_ERROR_OPAQUE_FRAME if if a FramePop event with
> depth 0 is requested by NotifyFramePop at the time when the target frame is
> in exit epilogue, and MethodExit/FramePop events
On Tue, 15 Oct 2024 23:43:16 GMT, Alex Menkov wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> minor comment tweak
>
> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/NotifyFramePopStressT
On Fri, 11 Oct 2024 09:26:42 GMT, Serguei Spitsyn wrote:
>> There is a race between JVMTI NotifyFramePop function and FramePop event
>> posting code.
>> The fix is to return JVMTI_ERROR_OPAQUE_FRAME if if a FramePop event with
>> depth 0 is requested by NotifyFramePop at the time when the targe
On Fri, 11 Oct 2024 09:26:42 GMT, Serguei Spitsyn wrote:
>> There is a race between JVMTI NotifyFramePop function and FramePop event
>> posting code.
>> The fix is to return JVMTI_ERROR_OPAQUE_FRAME if if a FramePop event with
>> depth 0 is requested by NotifyFramePop at the time when the targe
On Tue, 15 Oct 2024 22:31:46 GMT, Alex Menkov wrote:
>> The fix improves Attch API protocol and implements updated protocol on
>> windows; shared code is ready to implement updated protocol support on other
>> platforms.
>> More detailed explanations on the 1st comment.
>>
>> Testing: tier1,ti
On Sun, 13 Oct 2024 15:38:49 GMT, Simon Tooke wrote:
>> This PR changes the status of realpath() from a Posix-specific API to a
>> globally available API, i.e. adding it to the "Hotspot Porting API". Code
>> would refer to os::realpath() instead of os::Posix::realpath().
>>
>> This requires a
On Tue, 15 Oct 2024 20:54:45 GMT, Chris Plummer wrote:
> Overall the fix looks good. I made a couple of minor suggestions for the
> test. Make sure you test on all platforms and with -Xcomp since the test is
> timing sensitive.
Thank you for reviewing this! Good suggestion about an extensive t
> This is the 3rd PR for [JEP 483: Ahead-of-Time Class Loading &
> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>
> **Overview**
>
> - A new `-XX:+AOTClassLinking` flag is added. See [JEP
> 498](https://bugs.openjdk.org/browse/JDK-8315737) and the
> [CSR](https://bugs.openjdk.org/bro
On Tue, 15 Oct 2024 22:41:07 GMT, David Holmes wrote:
> Still good for me - but seems to be jcheck whitespace issues.
Thanks for noticing it. I've fixed the whitespaces (and need to propagate that
to all subsequent PRs in this series).
-
PR Comment: https://git.openjdk.org/jdk/pul
On Fri, 11 Oct 2024 13:43:46 GMT, Roman Kennke wrote:
>> William Kemper has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 478 commits:
>>
>> - Fix merge error
>> - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-re
On Tue, 15 Oct 2024 10:12:21 GMT, Ramkumar Sunderbabu
wrote:
> Passing "-Xmx1g -Xcomp" to the LingeredApp.
> Testing: tier1
The only thing that is missed it change `othervm` to `driver`.
The adding -Xcomp in LingeredApp.startApp(theApp, "-Xmx1g", "-Xcomp");
should works fine except when -Xint/
On Tue, 15 Oct 2024 10:47:55 GMT, Roman Kennke wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>>
>> It is also a follow-up to #20640, which now also includes (and supersedes)
>> #20603 and #20605, plus the Tiny Class-Pointers parts that have been
>> prev
On Mon, 14 Oct 2024 07:19:03 GMT, Ioi Lam wrote:
>> This is the 3rd PR for [JEP 483: Ahead-of-Time Class Loading &
>> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>>
>> **Overview**
>>
>> - A new `-XX:+AOTClassLinking` flag is added. See [JEP
>> 498](https://bugs.openjdk.org/browse/
On Tue, 15 Oct 2024 09:52:27 GMT, Serguei Spitsyn wrote:
>> Alex Menkov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> renamed JVM_EnqueueOperation2
>>
>> renamed JVM_EnqueueOperation2 to JVM_EnqueueOperation_v2 for consistency
>>
> The fix improves Attch API protocol and implements updated protocol on
> windows; shared code is ready to implement updated protocol support on other
> platforms.
> More detailed explanations on the 1st comment.
>
> Testing: tier1,tier2,tier3,tier4,hs-tier5-svc
> manually tested backward com
On Fri, 11 Oct 2024 09:26:42 GMT, Serguei Spitsyn wrote:
>> There is a race between JVMTI NotifyFramePop function and FramePop event
>> posting code.
>> The fix is to return JVMTI_ERROR_OPAQUE_FRAME if if a FramePop event with
>> depth 0 is requested by NotifyFramePop at the time when the targe
On Tue, 15 Oct 2024 15:01:00 GMT, Daniel Fuchs 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 c
On Tue, 15 Oct 2024 21:17:37 GMT, Phil Race 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 chan
On Tue, 15 Oct 2024 19:11:24 GMT, Mandy Chung 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 Tue, 15 Oct 2024 20:55:54 GMT, Alex Menkov wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Disallow NotifyFramePop for
>> enter/enter0/VirtualThread.run/VThreadContinuation.run
>
> src/hotspot/share/prims/jv
On Tue, 15 Oct 2024 13:51:18 GMT, Daniel Fuchs 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 c
On Tue, 15 Oct 2024 20:40:50 GMT, Alex Menkov wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Disallow NotifyFramePop for
>> enter/enter0/VirtualThread.run/VThreadContinuation.run
>
> src/hotspot/share/prims/jv
On Tue, 15 Oct 2024 20:45:46 GMT, Alex Menkov wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Disallow NotifyFramePop for
>> enter/enter0/VirtualThread.run/VThreadContinuation.run
>
> src/hotspot/share/prims/jv
On Tue, 15 Oct 2024 20:51:47 GMT, Chris Plummer wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> minor comment tweak
>
> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/NotifyFramePopStres
On Mon, 14 Oct 2024 13:52:24 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 change
On Tue, 15 Oct 2024 20:49:51 GMT, Chris Plummer wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> minor comment tweak
>
> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopSt
On Wed, 9 Oct 2024 22:58:33 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`
>> - Ma
On Wed, 9 Oct 2024 22:58:33 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`
>> - Ma
On Tue, 15 Oct 2024 10:12:21 GMT, Ramkumar Sunderbabu
wrote:
> Passing "-Xmx1g -Xcomp" to the LingeredApp.
> Testing: tier1
The -Xmx1g is probably just copied from ClhsdbPrintAll.java so it could
probably be dropped. Since the point of this test is to exercise nmethod debug
info decoding we
On Fri, 11 Oct 2024 09:26:42 GMT, Serguei Spitsyn wrote:
>> There is a race between JVMTI NotifyFramePop function and FramePop event
>> posting code.
>> The fix is to return JVMTI_ERROR_OPAQUE_FRAME if if a FramePop event with
>> depth 0 is requested by NotifyFramePop at the time when the targe
On Fri, 11 Oct 2024 22:12:25 GMT, Y. Srinivas Ramakrishna
wrote:
>> src/hotspot/share/gc/shenandoah/shenandoahCardStats.hpp line 40:
>>
>>> 38: DIRTY_SCAN_OBJS = 6,
>>> 39: ALTERNATIONS= 7,
>>> 40: MAX_CARD_STAT_TYPE = 8
>>
>> Are the numerical values relevant or what is the
On Thu, 10 Oct 2024 12:58:56 GMT, Roman Kennke wrote:
>> William Kemper has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 478 commits:
>>
>> - Fix merge error
>> - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-re
On Tue, 15 Oct 2024 10:12:21 GMT, Ramkumar Sunderbabu
wrote:
> Passing "-Xmx1g -Xcomp" to the LingeredApp.
> Testing: tier1
We have 3 processes here:
1. The test.
2. The SA Debuggee process spawned by the test (LingeredApp)
3. The SA "tool", also spawned by the test.
(1) and (2) will automati
On Mon, 14 Oct 2024 13:52:24 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 change
On Wed, 2 Oct 2024 21:15:11 GMT, Larry Cable wrote:
>> this is a fix to: https://bugs.openjdk.org/browse/JDK-8327114
>>
>> to resolve an issue detected in:
>>
>> https://bugs.openjdk.org/browse/JDK-8341246
>>
>> /proc/**/* file accesses should be performed as "privileged" actions to
>> avoi
On Mon, 14 Oct 2024 13:52:24 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 change
On Mon, 14 Oct 2024 13:52:24 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 change
On Mon, 14 Oct 2024 13:52:24 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 change
On Mon, 14 Oct 2024 13:52:24 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 change
On Tue, 15 Oct 2024 16:34:06 GMT, David M. Lloyd wrote:
>> While making `LogManager.checkAccess` be a no-op might be more convenient,
>> it could unconditionally
>> permit operations that formerly required a permission check: clearly a bad
>> idea. Always throwing a `SecurityException` is the s
On Tue, 15 Oct 2024 16:34:40 GMT, Severin Gehwolf 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
>> mai
On Tue, 15 Oct 2024 16:34:40 GMT, Severin Gehwolf 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
>> mai
On Tue, 15 Oct 2024 16:14:58 GMT, Sean Mullan wrote:
> While making `LogManager.checkAccess` be a no-op might be more convenient, it
> could unconditionally permit operations that formerly required a permission
> check: clearly a bad idea. Always throwing a `SecurityException` is the
> safest
On Mon, 14 Oct 2024 13:52:24 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 change
On Tue, 15 Oct 2024 15:52:13 GMT, David M. Lloyd wrote:
>> OK
>
> While I disagree with this change on the principle of "the system should
> operate as if no security manager were installed", the workaround for callers
> is actually rather simple:
>
>
> if (System.getSecurityManager() != null
On Tue, 15 Oct 2024 15:33:03 GMT, Daniel Fuchs wrote:
>> This is a bit of forced move. Same thing with Thread.checkAccess and
>> ThreadGroup.checkAccess that also have to be re-specified to throw
>> unconditionally. They are called out in the CSR.
>
> OK
While I disagree with this change on th
On Mon, 14 Oct 2024 13:52:24 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 change
On Tue, 15 Oct 2024 15:21:32 GMT, Alan Bateman wrote:
>> src/java.logging/share/classes/java/util/logging/LogManager.java line 2430:
>>
>>> 2428: @Deprecated(since="17", forRemoval=true)
>>> 2429: public void checkAccess() {
>>> 2430: throw new SecurityException();
>>
>> Though
On Tue, 15 Oct 2024 14:27:13 GMT, Daniel Fuchs 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 c
On Mon, 14 Oct 2024 13:52:24 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 change
On Mon, 14 Oct 2024 13:52:24 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 change
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
changes in the JEP and also includes an apidiff of the specification
On Mon, 9 Sep 2024 11:53:13 GMT, Thomas Schatzl wrote:
>> Roman Kennke has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Try to avoid lea in loadNklass (aarch64)
>> - Fix release build error
>
> src/hotspot/share/oops/klass.hpp line 169
On Tue, 17 Sep 2024 14:10:07 GMT, Kevin Walls wrote:
> DiagnosticCommandImpl should only publish parameter types in a known standard
> set, and use "STRING" on anything else.
> e.g. We can say "FILE" in the help output for jcmd, as that's for humans, but
> the MBean parameter info should contai
> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>
> It is also a follow-up to #20640, which now also includes (and supersedes)
> #20603 and #20605, plus the Tiny Class-Pointers parts that have been
> previously missing.
>
> Main changes:
> - Introduction of the (
Passing "-Xmx1g -Xcomp" to the LingeredApp.
Testing: tier1
-
Commit messages:
- start the LingeredApp with jvm options
Changes: https://git.openjdk.org/jdk/pull/21519/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21519&range=00
Issue: https://bugs.openjdk.org/browse/JDK
On Tue, 15 Oct 2024 00:21:41 GMT, Alex Menkov wrote:
>> The fix improves Attch API protocol and implements updated protocol on
>> windows; shared code is ready to implement updated protocol support on other
>> platforms.
>> More detailed explanations on the 1st comment.
>>
>> Testing: tier1,ti
On Tue, 15 Oct 2024 00:21:41 GMT, Alex Menkov wrote:
>> The fix improves Attch API protocol and implements updated protocol on
>> windows; shared code is ready to implement updated protocol support on other
>> platforms.
>> More detailed explanations on the 1st comment.
>>
>> Testing: tier1,ti
On Tue, 15 Oct 2024 00:21:41 GMT, Alex Menkov wrote:
>> The fix improves Attch API protocol and implements updated protocol on
>> windows; shared code is ready to implement updated protocol support on other
>> platforms.
>> More detailed explanations on the 1st comment.
>>
>> Testing: tier1,ti
> Please review this fix for cgroups-based metrics reporting in the
> `jdk.internal.platform` package. This fix is supposed to address wrong
> reporting of certain limits if the limits aren't set at the leaf nodes.
>
> For example, on cg v2, the memory limit interface file is `memory.max`.
> Co
> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>
> It is also a follow-up to #20640, which now also includes (and supersedes)
> #20603 and #20605, plus the Tiny Class-Pointers parts that have been
> previously missing.
>
> Main changes:
> - Introduction of the (
> DiagnosticCommandImpl should only publish parameter types in a known standard
> set, and use "STRING" on anything else.
> e.g. We can say "FILE" in the help output for jcmd, as that's for humans, but
> the MBean parameter info should contain "STRING".
Kevin Walls has updated the pull request w
> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>
> It is also a follow-up to #20640, which now also includes (and supersedes)
> #20603 and #20605, plus the Tiny Class-Pointers parts that have been
> previously missing.
>
> Main changes:
> - Introduction of the (
On Thu, 10 Oct 2024 08:51:38 GMT, Kevin Walls wrote:
>> DiagnosticCommandImpl should only publish parameter types in a known
>> standard set, and use "STRING" on anything else.
>> e.g. We can say "FILE" in the help output for jcmd, as that's for humans,
>> but the MBean parameter info should co
On Thu, 10 Oct 2024 08:51:38 GMT, Kevin Walls wrote:
>> DiagnosticCommandImpl should only publish parameter types in a known
>> standard set, and use "STRING" on anything else.
>> e.g. We can say "FILE" in the help output for jcmd, as that's for humans,
>> but the MBean parameter info should co
On Thu, 10 Oct 2024 08:51:38 GMT, Kevin Walls wrote:
>> DiagnosticCommandImpl should only publish parameter types in a known
>> standard set, and use "STRING" on anything else.
>> e.g. We can say "FILE" in the help output for jcmd, as that's for humans,
>> but the MBean parameter info should co
On Wed, 31 Jul 2024 08:30:47 GMT, Kevin Walls wrote:
> Man page update for jcmd.
>
> Add updates for the filename options/arguments affected by:
> 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and
> substitute PID
>
> Also:
> In the initial "command" summary, remove t
On Mon, 14 Oct 2024 21:47:00 GMT, Martin Doerr wrote:
>@offamitkumar: It could still be done after this PR is integrated, but I guess
>you want to provide an s390 implementation.
I haven't looked into it yet. I am looking into other issues for now, but I
will if I can get time to work on this.
On Thu, 19 Sep 2024 15:01:26 GMT, Hamlin Li wrote:
>> Roman Kennke has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'lilliput/JEP-450-temporary-fix-branch-2'
>> into JDK-8305895-v4
>> - review feedback
>
>
83 matches
Mail list logo
