On Mon, 28 Jul 2025 14:41:25 GMT, Francesco Andreuzzi wrote:
>> This PR sorts the includes in `hotspot/share/services` using
>> `SortIncludes.java`. I'm also adding the directory to
>> `TestIncludesAreSorted`.
>>
>> Passes tier1.
>
> Francesco Andreuzzi has updated the pull request with a new
On Wed, 9 Jul 2025 08:28:23 GMT, Albert Mingkun Yang wrote:
> Trivial changing boolean to the correct integer to avoid implicit bool-to-int
> conversion.
Marked as reviewed by shade (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/26214#pullrequestreview-3000579279
On Wed, 18 Jun 2025 14:44:54 GMT, Coleen Phillimore wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [e18277b4](https://github.com/openjdk/jdk/commit/e18277b470a162b9668297e8e286c812c4b0b604)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The commi
On Tue, 24 Jun 2025 13:56:40 GMT, Paul Hohensee wrote:
> Windows GHA failures are infra-related and unrelated to this change.
You can pull in from current master to get them fixed.
-
PR Comment: https://git.openjdk.org/jdk/pull/25951#issuecomment-3001233870
On Wed, 18 Jun 2025 14:44:54 GMT, Coleen Phillimore wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [e18277b4](https://github.com/openjdk/jdk/commit/e18277b470a162b9668297e8e286c812c4b0b604)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The commi
On Thu, 19 Jun 2025 10:02:45 GMT, Aleksey Shipilev wrote:
>> Thank you for the backport! @shipilev indicated that the backport to 21
>> should wait a bit, could you clarify when should I file that (e.g. end of
>> July, ...)?
>
>> @shipilev indicated that the backp
On Thu, 12 Jun 2025 23:42:41 GMT, William Kemper wrote:
> Remove `GCCause::_no_cause_specified` (only referenced by Shenandoah) and add
> a case for `_shenandoah_humongous_allocation_failure` in `GCCause::to_string`
> and the `SA` analog.
Marked as reviewed by shade (Reviewer).
-
On Wed, 18 Jun 2025 15:42:14 GMT, Radim Vansa wrote:
> @shipilev indicated that the backport to 21 should wait a bit, could you
> clarify when should I file that (e.g. end of July, ...)?
I would say for the fairly big change like this, we want to wait until JDK 25
GA (that would pass the all-t
On Thu, 12 Jun 2025 23:42:41 GMT, William Kemper wrote:
> We can remove `GCCause::_no_cause_specified` and need to add a case for
> `_shenandoah_humongous_allocation_failure` in `GCCause::to_string`. We are
> also missing `_shenandoah_humongous_allocation_failure` in the `SA` analog.
Shenandoa
On Wed, 4 Jun 2025 12:03:15 GMT, Aleksey Shipilev wrote:
> SonarCloud points out that ThreadLock class introduced by
> [JDK-8357650](https://bugs.openjdk.org/browse/JDK-8357650) can be turned into
> static nested class. I don't think this shows any real bug yet, as
> unref
On Wed, 4 Jun 2025 12:03:15 GMT, Aleksey Shipilev wrote:
> SonarCloud points out that ThreadLock class introduced by
> [JDK-8357650](https://bugs.openjdk.org/browse/JDK-8357650) can be turned into
> static nested class. I don't think this shows any real bug yet, as
> unref
On Wed, 4 Jun 2025 15:48:31 GMT, Johannes Bechberger
wrote:
>> This is the code for the [JEP 509: CPU Time based profiling for
>> JFR](https://openjdk.org/jeps/509).
>>
>> Currently tested using [this test
>> suite](https://github.com/parttimenerd/basic-profiler-tests). This runs
>> profiles
On Wed, 4 Jun 2025 12:56:22 GMT, Johannes Bechberger
wrote:
>> This is the code for the [JEP 509: CPU Time based profiling for
>> JFR](https://openjdk.org/jeps/509).
>>
>> Currently tested using [this test
>> suite](https://github.com/parttimenerd/basic-profiler-tests). This runs
>> profiles
On Wed, 4 Jun 2025 13:29:22 GMT, Alan Bateman wrote:
> The tests in test/jdk/com/sun/management/HotSpotDiagnosticMBean is the
> quickest way to exercise this code.
Thanks! I just ran the entire `jdk_management` test group without any problems.
-
PR Comment: https://git.openjdk.org
On Mon, 2 Jun 2025 13:50:49 GMT, Johannes Bechberger
wrote:
>> This is the code for the [JEP 509: CPU Time based profiling for
>> JFR](https://openjdk.org/jeps/509).
>>
>> Currently tested using [this test
>> suite](https://github.com/parttimenerd/basic-profiler-tests). This runs
>> profiles
On Mon, 2 Jun 2025 11:32:27 GMT, Johannes Bechberger
wrote:
>> This is the code for the [JEP 509: CPU Time based profiling for
>> JFR](https://openjdk.org/jeps/509).
>>
>> Currently tested using [this test
>> suite](https://github.com/parttimenerd/basic-profiler-tests). This runs
>> profiles
On Sun, 1 Jun 2025 07:19:54 GMT, Johannes Bechberger
wrote:
>> Thanks for catching this mistake. I'll fix it this afternoon.
>
> I fixed it by changing the JEP.
Hold on, shouldn't this really be "Lost"? @egahlin and @mgronlun need to chime
in here.
-
PR Review Comment: https://gi
On Wed, 28 May 2025 18:51:09 GMT, Aleksey Shipilev wrote:
> SonarCloud reports an issue since
> [JDK-8355003](https://bugs.openjdk.org/browse/JDK-8355003) integration:
> duplicate index in `metadataTypeArray` initialization code. Looks like a
> simple typo, this PR fixes it.
>
SonarCloud reports an issue since
[JDK-8355003](https://bugs.openjdk.org/browse/JDK-8355003) integration:
duplicate index in `metadataTypeArray` initialization code. Looks like a simple
typo, this PR fixes it.
Additional testing:
- [x] Linux x86_64 server fastdebug, `serviceability/sa`
-
On Mon, 26 May 2025 17:25:33 GMT, Aleksey Shipilev wrote:
> [JDK-8356251](https://bugs.openjdk.org/browse/JDK-8356251) changed
> `JvmtiThreadState._saved_interp_only_mode` from `int` to `bool`, which is
> good. But the initializations are still done with `0` literals. Even though
On Mon, 26 May 2025 17:25:33 GMT, Aleksey Shipilev wrote:
> [JDK-8356251](https://bugs.openjdk.org/browse/JDK-8356251) changed
> `JvmtiThreadState._saved_interp_only_mode` from `int` to `bool`, which is
> good. But the initializations are still done with `0` literals. Even though
[JDK-8356251](https://bugs.openjdk.org/browse/JDK-8356251) changed
`JvmtiThreadState._saved_interp_only_mode` from `int` to `bool`, which is good.
But the initializations are still done with `0` literals. Even though it is
benign, SonarCloud still complains about the intentionality of this
init
On Mon, 19 May 2025 17:06:09 GMT, Johannes Bechberger
wrote:
>> This is the code for the [JEP 509: CPU Time based profiling for
>> JFR](https://openjdk.org/jeps/509).
>>
>> Currently tested using [this test
>> suite](https://github.com/parttimenerd/basic-profiler-tests). This runs
>> profile
On Sun, 11 May 2025 04:57:44 GMT, Ioi Lam wrote:
> https://openjdk.org/jeps/483 mentions:
>
>> To enjoy the benefits of the AOT cache generated during a training run, the
>> training run and all subsequent runs must be essentially similar. [...] All
>> runs must not use JVMTI agents that can a
On Mon, 12 May 2025 17:21:30 GMT, Ioi Lam wrote:
>> src/hotspot/share/prims/jvmtiAgent.cpp line 588:
>>
>>> 586: // Agents are allowed with -XX:AOTMode=record and
>>> -XX:AOTMode=on/auto.
>>> 587: // Agents are completely disabled when -XX:AOTMode=create
>>> 588: assert(!CDSConfig::
On Sun, 11 May 2025 04:57:44 GMT, Ioi Lam wrote:
> https://openjdk.org/jeps/483 mentions:
>
>> To enjoy the benefits of the AOT cache generated during a training run, the
>> training run and all subsequent runs must be essentially similar. [...] All
>> runs must not use JVMTI agents that can a
On Fri, 25 Apr 2025 15:17:17 GMT, Aleksey Shipilev wrote:
> I noticed in `macros.hpp`:
>
>
> #ifdef ASSERT
> #define DEBUG_ONLY(code) code
> #define NOT_DEBUG(code)
> #define NOT_DEBUG_RETURN /*next token must be ;*/
> // Historical.
> #define debug_only(c
On Fri, 25 Apr 2025 15:17:17 GMT, Aleksey Shipilev wrote:
> I noticed in `macros.hpp`:
>
>
> #ifdef ASSERT
> #define DEBUG_ONLY(code) code
> #define NOT_DEBUG(code)
> #define NOT_DEBUG_RETURN /*next token must be ;*/
> // Historical.
> #define debug_only(c
I noticed in `macros.hpp`:
#ifdef ASSERT
#define DEBUG_ONLY(code) code
#define NOT_DEBUG(code)
#define NOT_DEBUG_RETURN /*next token must be ;*/
// Historical.
#define debug_only(code) code
#else // ASSERT
There are 350+ instances of `debug_only`, and 1600+ instances of `DEBUG_ONLY`.
We can cl
On Wed, 23 Apr 2025 17:14:17 GMT, Aleksey Shipilev wrote:
> A lot of SA infrastructure was added to support SA compiler replay with
> [JDK-7088955](https://bugs.openjdk.org/browse/JDK-7088955). With
> [JDK-8315488](https://bugs.openjdk.org/browse/JDK-8315488), we got rid from
> th
On Wed, 23 Apr 2025 17:14:17 GMT, Aleksey Shipilev wrote:
> A lot of SA infrastructure was added to support SA compiler replay with
> [JDK-7088955](https://bugs.openjdk.org/browse/JDK-7088955). With
> [JDK-8315488](https://bugs.openjdk.org/browse/JDK-8315488), we got rid from
> th
A lot of SA infrastructure was added to support SA compiler replay with
[JDK-7088955](https://bugs.openjdk.org/browse/JDK-7088955). With
[JDK-8315488](https://bugs.openjdk.org/browse/JDK-8315488), we got rid from the
most of it. `CompileTask` seems to be left behind. Nothing uses it in SA now.
On Thu, 13 Feb 2025 01:22:55 GMT, Vladimir Kozlov wrote:
> `CodeBlob::is_buffer_blob()` method is incorrectly used in few places because
> BufferBlob is not "leaf" class. You need to add checks for its subclasses too.
>
> I also updated statistic output for CodeCache (`-XX:+PrintCodeCache
> -X
On Tue, 28 Jan 2025 20:11:49 GMT, Chris Plummer wrote:
>> DeoptimizeObjectsALotThread was being unconditionally added to the mapping
>> table:
>>
>>virtualConstructor.addMapping("DeoptimizeObjectsALotThread",
>> DeoptimizeObjectsALotThread.class);
>>
>> But is conditionally included i
On Tue, 28 Jan 2025 19:14:56 GMT, Chris Plummer wrote:
> DeoptimizeObjectsALotThread was being unconditionally added to the mapping
> table:
>
>virtualConstructor.addMapping("DeoptimizeObjectsALotThread",
> DeoptimizeObjectsALotThread.class);
>
> But is conditionally included in VMStr
On Tue, 21 Jan 2025 21:19:06 GMT, Coleen Phillimore wrote:
> Please review this change to remove debug printing code that was added
> temporarily for the ClassFileReconstituter to debug constant pool copying a
> long time ago, that is now unused.
> Tested with tier1 locally.
Marked as reviewed
On Fri, 17 Jan 2025 01:07:29 GMT, Zhengyu Gu wrote:
> It leaks _frames array and frames stored inside the array
Looks fine. Good catch!
-
Marked as reviewed by shade (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/23169#pullrequestreview-2558194203
On Fri, 29 Nov 2024 16:00:52 GMT, William Kemper wrote:
>> This PR merges JEP 404, a generational mode for the Shenandoah garbage
>> collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We
>> would like to target JDK24 with this PR.
>
> William Kemper has updated the pull reques
On Tue, 26 Nov 2024 00:37:32 GMT, William Kemper wrote:
>> This PR merges JEP 404, a generational mode for the Shenandoah garbage
>> collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We
>> would like to target JDK24 with this PR.
>
> William Kemper has updated the pull reques
On Mon, 25 Nov 2024 17:59:05 GMT, William Kemper wrote:
>> We should really either predicate it on generational mode (we already poll
>> it a few lines below) and check for `MARKING` specifically, or assert it.
>
> I'll make some adjustments here. Note that `OLD_MARKING` also implies (and
> set
On Thu, 21 Nov 2024 18:12:43 GMT, William Kemper wrote:
>> src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 514:
>>
>>> 512:
>>> 513: public:
>>> 514: ShenandoahController* control_thread() { return _control_thread; }
>>
>> This method and field is probably `controller` then, right?
On Wed, 20 Nov 2024 00:13:13 GMT, William Kemper wrote:
>> src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp line 420:
>>
>>> 418: }
>>> 419: int gc_state = _heap->gc_state();
>>> 420: if ((gc_state & ShenandoahHeap::YOUNG_MARKING) != 0) {
>>
>> It is not very clear this wor
On Tue, 19 Nov 2024 19:54:45 GMT, William Kemper wrote:
>> src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp line 276:
>>
>>> 274: log_info(gc)("GC cancellation took %.3fs", cancel_time);
>>> 275: _cancel_requested_time = 0;
>>> 276: }
>>
>> Do we need this? Is this useful?
>
On Sat, 16 Nov 2024 17:54:01 GMT, Kelvin Nilsen wrote:
>> I think it's here for the same reason `propagate_gc_state_to_java_threads`
>> is here. Having it here makes it easier to see that this critical
>> synchronization step happens for every safepoint.
>
> I'm inclined to leave as is, not wan
On Thu, 21 Nov 2024 00:59:27 GMT, William Kemper wrote:
>> This PR merges JEP 404, a generational mode for the Shenandoah garbage
>> collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We
>> would like to target JDK24 with this PR.
>
> William Kemper has updated the pull reques
On Tue, 19 Nov 2024 23:07:21 GMT, William Kemper wrote:
>> src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.cpp line 44:
>>
>>> 42: for (size_t idx = 0; idx < num_regions; idx++) {
>>> 43: ShenandoahHeapRegion* r = heap->get_region(idx);
>>> 44: if (r->is_affiliated() && heap->
On Wed, 13 Nov 2024 19:32:53 GMT, William Kemper wrote:
>> This PR merges JEP 404, a generational mode for the Shenandoah garbage
>> collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We
>> would like to target JDK24 with this PR.
>
> William Kemper has updated the pull reques
On Wed, 13 Nov 2024 19:32:53 GMT, William Kemper wrote:
>> This PR merges JEP 404, a generational mode for the Shenandoah garbage
>> collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We
>> would like to target JDK24 with this PR.
>
> William Kemper has updated the pull reques
On Wed, 13 Nov 2024 19:32:53 GMT, William Kemper wrote:
>> This PR merges JEP 404, a generational mode for the Shenandoah garbage
>> collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We
>> would like to target JDK24 with this PR.
>
> William Kemper has updated the pull reques
On Wed, 13 Nov 2024 19:32:53 GMT, William Kemper wrote:
>> This PR merges JEP 404, a generational mode for the Shenandoah garbage
>> collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We
>> would like to target JDK24 with this PR.
>
> William Kemper has updated the pull reques
On Wed, 13 Nov 2024 19:32:53 GMT, William Kemper wrote:
>> This PR merges JEP 404, a generational mode for the Shenandoah garbage
>> collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We
>> would like to target JDK24 with this PR.
>
> William Kemper has updated the pull reques
On Wed, 13 Nov 2024 19:32:53 GMT, William Kemper wrote:
>> This PR merges JEP 404, a generational mode for the Shenandoah garbage
>> collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We
>> would like to target JDK24 with this PR.
>
> William Kemper has updated the pull reques
On Thu, 14 Nov 2024 19:12:25 GMT, Aleksey Shipilev wrote:
>> No objections here. @ysramakrishna , @kdnilsen ?
>
> See, with current code, default Shenandoah prints this:
>
>
> [0.025s][info][gc] GC(0) Concurrent reset (NON-GENERATIONAL) (unload classes)
> 0.135ms
&
On Wed, 13 Nov 2024 23:17:44 GMT, William Kemper wrote:
>> src/hotspot/share/gc/shenandoah/shenandoahUtils.hpp line 50:
>>
>>> 48: switch (generation_type) {
>>> \
>>> 49: case NON_GEN:
>>>
On Wed, 13 Nov 2024 23:07:02 GMT, William Kemper wrote:
>> test/hotspot/jtreg/gc/shenandoah/oom/TestThreadFailure.java line 61:
>>
>>> 59: // case that the previously instantiated NastyThread
>>> accumulated more than SheanndoahNoProgressThreshold
>>> 60: // unpr
On Mon, 4 Nov 2024 19:52:30 GMT, William Kemper wrote:
>> This PR merges JEP 404, a generational mode for the Shenandoah garbage
>> collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We
>> would like to target JDK24 with this PR.
>
> William Kemper has updated the pull request
On Wed, 6 Nov 2024 15:21:10 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 Thu, 7 Nov 2024 12:16:23 GMT, Aleksey Shipilev wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove FIXME
>
> I really wish we did not mess with `_stdcall` and `_cde
On Wed, 6 Nov 2024 15:21:10 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, 6 Nov 2024 00:56:49 GMT, David Holmes wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> fix: jvm_md.h was included, but not jvm.h...
>
> src/hotspot/os/windows/os_windows.cpp line 510:
>
>> 508: // Thr
On Tue, 29 Oct 2024 20:22:03 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 11:05:17 GMT, Magnus Ihse Bursie wrote:
>> make/scripts/compare.sh line 1457:
>>
>>> 1455: THIS_SEC_BIN="$THIS_SEC_DIR/sec-bin.zip"
>>> 1456: if [ "$OPENJDK_TARGET_OS" = "windows" ]; then
>>> 1457: JGSS_WINDOWS_BIN="jgss-windows-x64-bin.zip"
>>
>>
On Tue, 29 Oct 2024 13:26:57 GMT, Julian Waters wrote:
>> src/hotspot/os_cpu/windows_x86/os_windows_x86.cpp line 523:
>>
>>> 521:
>>> 522: extern "C" int SpinPause () {
>>> 523: #ifdef AMD64
>>
>> Weird that SpinPause is not implemented on Win64, but oh well. This whole
>> SpinPause mess shou
On Mon, 28 Oct 2024 23:15:36 GMT, Erik Joelsson wrote:
>> make/modules/jdk.accessibility/Launcher.gmk line 56:
>>
>>> 54: $(eval $(call SetupJdkExecutable, BUILD_JACCESSINSPECTOR, \
>>> 55: NAME := jaccessinspector, \
>>> 56: EXTRA_SRC := \
>>
>> I might be missing something here.
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 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, 30 Sep 2024 08:13:10 GMT, Axel Boldt-Christmas
wrote:
>> [JDK-8322630](https://bugs.openjdk.org/browse/JDK-8322630) / #17495 removed
>> the the concept of ICStubs, InlineCache buffers and related safepoints.
>>
>> There are a handfull of references and auxiliary constructs still in the
On Fri, 27 Sep 2024 19:42:12 GMT, Alex Menkov wrote:
>> The fix cleans up static variables/methods in HeapDumper.
>> See jira for details.
>>
>> Testing:
>> heap dump-related tests (test/hotspot/jtreg/serviceability,
>> test/hotspot/jtreg/compiler/c2/TestReduceAllocationAndHeapDump.java,
>>
On Fri, 27 Sep 2024 01:28:18 GMT, Alex Menkov wrote:
> The fix cleans up static variables/methods in HeapDumper.
> See jira for details.
>
> Testing:
> heap dump-related tests (test/hotspot/jtreg/serviceability,
> test/hotspot/jtreg/compiler/c2/TestReduceAllocationAndHeapDump.java,
> test/ho
On Sat, 21 Sep 2024 04:19:13 GMT, Kim Barrett wrote:
> Please review this change which removes the class NarrowPtrStruct. The only
> place it was still being used was as the type of CompressedOops::_narrow_oops.
> Instead, we move the members from NarrowPtrStruct directly into
> CompressedOops, f
On Fri, 13 Sep 2024 06:54:40 GMT, David Holmes wrote:
>> This is a trivial point fix for the `strace` tests to add in the missing
>> event (super)constructors. These tests have started failing more regularly
>> after the `Thread.sleep` code was recently changed.
>>
>> The fragility of these te
On Thu, 1 Aug 2024 03:37:26 GMT, David Holmes wrote:
> I must be missing something in the approach. The vast majority of
> confidential data will be in strings yet you focus on primitives that would
> rarely (if ever for boolean float/double) contain anything that could be
> recognised as such
On Wed, 31 Jul 2024 19:10:41 GMT, Henry Lin wrote:
> Adds a command line option `-redact` to `jcmd`, `redact` to `jmap` 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
On Tue, 30 Jul 2024 04:12:33 GMT, Kim Barrett wrote:
> Please review this change that removes some uses of literal 0 as a null
> pointer constant in prims code.
>
> Testing: mach5 tier1
All right, this looks fine. (I am somewhat allergic to `{}` syntax, but it is
what it is.)
-
M
On Wed, 17 Jul 2024 03:37:36 GMT, Vladimir Kozlov wrote:
> Citing David Holmes from bug report:
> "We provided the ability to leave out certain VM services (JVMTI, GC's other
> than serial, ...) as part of the design of the MinimalVM to support Java SE
> Embedded, along with the Compact Profile
On Wed, 17 Jul 2024 04:57:38 GMT, David Holmes wrote:
> It highlights the problem we have with optional components in that you either
> have to work things so that semantically we have a do-nothing implementation
> of that component, or else you have to put the guards around every piece of
> c
On Thu, 16 May 2024 11:00:33 GMT, Johan Sjölen wrote:
> Please wait 24 hours before attempting to integrate. In other words: Do not
> sponsor this until 24 hours has passed since opening the PR.
OTOH, I would say this is good and _trivial_, so the usual 24 hour rule does
not really apply. :)
On Wed, 15 May 2024 21:12:03 GMT, Andrei Pangin wrote:
> The fix for [JDK-8313332](https://bugs.openjdk.org/browse/JDK-8313332) has
> [removed](https://github.com/openjdk/jdk/commit/21867c929a2f2c961148f2cd1e79d672ac278d27#diff-7d448441e80a0b784429d5d8aee343fcb131c224b8ec7bc70ea636f78d561ecd
> )
On Mon, 13 May 2024 13:03:26 GMT, Evgeny Astigeevich
wrote:
> Backout of [JDK-8309271](https://bugs.openjdk.org/browse/JDK-8309271) which
> has known bugs, possible bugs and performance issues.
>
> Found bugs:
> - When refreshing `CompilerDirectivesAddDCmd::execute` will call
> `DirectivesSta
On Thu, 2 May 2024 14:40:35 GMT, Aleksey Shipilev wrote:
> `CollectedHeap::is_gc_active()` is confusing, since its name implies _any_ GC
> phase is running, while it actually only covers the STW GCs. It would be good
> to rename it for clarity. The freed-up name, `is_gc_active` coul
On Thu, 2 May 2024 17:26:58 GMT, Stefan Karlsson wrote:
>> Ah, hm. Indeed! Separate PR? There is some light cleanup in G1 that can be
>> associated with it. This PR would keep with just a mechanical rename.
>
> Sounds like a good idea.
Filed: https://bugs.openjdk.org/browse/JDK-8331719 -- I'll
On Thu, 2 May 2024 14:40:35 GMT, Aleksey Shipilev wrote:
> `CollectedHeap::is_gc_active()` is confusing, since its name implies _any_ GC
> phase is running, while it actually only covers the STW GCs. It would be good
> to rename it for clarity. The freed-up name, `is_gc_active` coul
On Thu, 2 May 2024 17:04:44 GMT, Stefan Karlsson wrote:
>> `CollectedHeap::is_gc_active()` is confusing, since its name implies _any_
>> GC phase is running, while it actually only covers the STW GCs. It would be
>> good to rename it for clarity. The freed-up name, `is_gc_active` could then
>>
On Thu, 2 May 2024 16:56:11 GMT, Stefan Karlsson wrote:
>> `CollectedHeap::is_gc_active()` is confusing, since its name implies _any_
>> GC phase is running, while it actually only covers the STW GCs. It would be
>> good to rename it for clarity. The freed-up name, `is_gc_active` could then
>>
`CollectedHeap::is_gc_active()` is confusing, since its name implies _any_ GC
phase is running, while it actually only covers the STW GCs. It would be good
to rename it for clarity. The freed-up name, `is_gc_active` could then be
repurposed to track any (concurrent or STW) GC phase running. That
On Tue, 30 Apr 2024 18:54:09 GMT, Alex Menkov wrote:
>> The fix makes VM heap dumping parallel by default.
>> `jcmd GC.heap_dump` and `jmap -dump` had parallel dumping by default, the
>> fix affects `HotSpotDiagnosticMXBean.dumpHeap()`,
>> `-XX:+HeapDumpBeforeFullGC`, `-XX:+HeapDumpAfterFullGC`
On Thu, 21 Mar 2024 08:38:34 GMT, Aleksey Shipilev wrote:
>> See the bug for symptoms. The tests are failing because hprof test library
>> is confused about non-compact strings.
>>
>> Additional testing:
>> - [x] `serviceability/HeapDump lib-test:all` with `-XX
On Wed, 20 Mar 2024 09:53:36 GMT, Aleksey Shipilev wrote:
> See the bug for symptoms. The tests are failing because hprof test library is
> confused about non-compact strings.
>
> Additional testing:
> - [x] `serviceability/HeapDump lib-test:all` with `-XX:-CompactStrings` now
b-test:all` with `-XX:+CompactStrings`
> still pass
Aleksey Shipilev has updated the pull request incrementally with one additional
commit since the last revision:
Copyright years
-
Changes:
- all: https://git.openjdk.org/jdk/pull/18394/files
- new: https://git.openjdk.org/jdk/p
On Wed, 20 Mar 2024 14:46:09 GMT, Paul Hohensee wrote:
> Are we guaranteed that non-compact string char component bytes are stored in
> little-endian order?
No, I don't think we are guaranteed any particular endianness, argh. The new
patch follows what `StringUTF16` does:
https://github.com/o
b-test:all` with `-XX:+CompactStrings`
> still pass
Aleksey Shipilev 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 three additional
commits since the l
See the bug for symptoms. The tests are failing because hprof test library is
confused about non-compact strings.
Additional testing:
- [x] `serviceability/HeapDump lib-test:all` with `-XX:-CompactStrings` now
pass
- [x] `serviceability/HeapDump lib-test:all` with `-XX:+CompactStrings` still
On Thu, 15 Feb 2024 02:45:26 GMT, Alex Menkov wrote:
>> The fix updates heap dumpers to report correct instance size value for
>> HPROF_GC_CLASS_DUMP records (currently it's reported as size of all instance
>> fields)
>>
>> Testing: tier1, tier2, tier5-svc
>
> Alex Menkov has updated the pull
On Wed, 24 Jan 2024 14:48:52 GMT, Volker Simonis wrote:
>> Currently we don't record dependencies on redefined methods (i.e.
>> `evol_method` dependencies) in JIT compiled methods if none of the
>> `can_redefine_classes`, `can_retransform_classes` or
>> `can_generate_breakpoint_events` JVMTI c
On Mon, 22 Jan 2024 21:26:41 GMT, Volker Simonis wrote:
>> Currently we don't record dependencies on redefined methods (i.e.
>> `evol_method` dependencies) in JIT compiled methods if none of the
>> `can_redefine_classes`, `can_retransform_classes` or
>> `can_generate_breakpoint_events` JVMTI c
On Sat, 20 Jan 2024 19:48:07 GMT, Volker Simonis wrote:
> Instead of unconditionally recording evol_method dependencies we could guard
> the recording by a new flag. But this would only make sense if that flag
> would be on by default and I don't know if such a flag is justified just for
> the
On Wed, 15 Nov 2023 06:22:58 GMT, Thomas Stuefe wrote:
>> When using 'MemStat' CompileCommand, we accidentally register the command if
>> an invalid suboption had been specified. Fixed, added regression test
>> (verified).
>
> Thomas Stuefe has updated the pull request incrementally with one ad
On Mon, 13 Nov 2023 13:33:26 GMT, Thomas Stuefe wrote:
>> When using 'MemStat' CompileCommand, we accidentally register the command if
>> an invalid suboption had been specified. Fixed, added regression test
>> (verified).
>
> Thomas Stuefe has updated the pull request with a new target base du
On Fri, 13 Oct 2023 01:38:13 GMT, Jonathan Joo wrote:
>> 8315149: Add hsperf counters for CPU time of internal GC threads
>
> Jonathan Joo has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Add call to publish in parallel gc and update counter
On Fri, 22 Sep 2023 03:28:18 GMT, David Holmes wrote:
>> Using `long` is to avoid build failure on 32-bit ARM and x86. `jlong` is
>> `long long` on 32-bit, and Atomic template does not support `long long` on
>> 32-bit. Example failure:
>> https://github.com/jjoo172/jdk/actions/runs/6229455243/
1 - 100 of 184 matches
Mail list logo
