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 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 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 Sat, 13 Jul 2024 14:47:21 GMT, Markus Grönlund wrote:
> Greetings,
>
> Please help review this adjustment, which fixes rare situations where methods
> that have been retransformed or redefined can be perceived as being tagged by
> JFR when they, in fact, are not. The fix unconditionally set
8334781: JFR crash: assert(JfrTraceIdBits::load(klass)) &
((JfrTraceIdEpoch::this_epoch_method_and_class_bits( != 0))) failed:
invariant
-
Commit messages:
- Backport 67979eb0771ff834d6d3d18ba5a8bfe161cfc2ce
Changes: https://git.openjdk.org/jdk/pull/20217/files
Webrev:
On Wed, 17 Jul 2024 11:21:04 GMT, Markus Grönlund wrote:
> 8334781: JFR crash: assert(JfrTraceIdBits::load(klass)) &
> ((JfrTraceIdEpoch::this_epoch_method_and_class_bits( != 0))) failed:
> invariant
Marked as reviewed by egahlin (Reviewer).
-
PR Review: https://git.open
On Wed, 17 Jul 2024 11:21:04 GMT, Markus Grönlund wrote:
> 8334781: JFR crash: assert(JfrTraceIdBits::load(klass)) &
> ((JfrTraceIdEpoch::this_epoch_method_and_class_bits( != 0))) failed:
> invariant
This pull request has now been integrated.
Changeset: 88775f95
Author:Markus Grö
Hi all,
This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492)
enabling jcmd diagnostic commands that issue an output file to accept the `%p`
pattern in the file name and substitute it for the PID.
This PR addresses the following diagnostic commands:
- [x] Compiler.perfmap
> Hi all,
>
> This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492)
> enabling jcmd diagnostic commands that issue an output file to accept the
> `%p` pattern in the file name and substitute it for the PID.
>
> This PR addresses the following diagnostic commands:
> - [x] C
On Wed, 17 Jul 2024 14:02:31 GMT, Sonia Zaldana Calles
wrote:
>> Hi all,
>>
>> This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492)
>> enabling jcmd diagnostic commands that issue an output file to accept the
>> `%p` pattern in the file name and substitute it for the PID.
On Wed, 17 Jul 2024 14:02:01 GMT, Thomas Stuefe wrote:
>> Sonia Zaldana Calles has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Updating copyright headers
>
> src/hotspot/share/code/codeCache.cpp line 1800:
>
>> 1798: jio_snprintf(fn
On Wed, 17 Jul 2024 14:07:55 GMT, Thomas Stuefe wrote:
>> Sonia Zaldana Calles has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Updating copyright headers
>
> src/hotspot/share/services/diagnosticCommand.cpp line 1138:
>
>> 1136: str
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 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
> Hi all,
>
> This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492)
> enabling jcmd diagnostic commands that issue an output file to accept the
> `%p` pattern in the file name and substitute it for the PID.
>
> This PR addresses the following diagnostic commands:
> - [x] C
On Wed, 17 Jul 2024 19:59:10 GMT, Sonia Zaldana Calles
wrote:
>> Hi all,
>>
>> This PR addresses [8334492](https://bugs.openjdk.org/browse/JDK-8334492)
>> enabling jcmd diagnostic commands that issue an output file to accept the
>> `%p` pattern in the file name and substitute it for the PID.
On Fri, 12 Jul 2024 09:16:05 GMT, Kevin Walls wrote:
>> Short version:
>> Stop testing this test with -Xcomp by adding requires vm.compMode != "Xcomp"
>>
>> Make additional typo fixes and tidyups while here, it's just shocking.
>>
>> TestDescription.java contains the test definition, so the "re
On Mon, 24 Jun 2024 16:16:29 GMT, SendaoYan wrote:
> Hi all,
> After [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960), the
> footprint memory usage increased significantly when run the testcase with
> -Xcomp jvm options, then cause the testcase was killed by docker by OOM.
> Maybe
On Fri, 28 Jun 2024 20:34:48 GMT, Chris Plummer wrote:
> The completely unrelated fix to
> [JDK-8335124](https://bugs.openjdk.org/browse/JDK-8335124) led me to believe
> that the issue with sometimes not being able to get the stack trace of the
> SteadyStateThread might be due to the thread be
On Fri, 28 Jun 2024 22:30:52 GMT, Chris Plummer wrote:
> Once the main thread has detected that the spawned thread is in the BLOCKED
> state, the spawned thread's LingeredAppWithLock.lockMethod() should be
> visible on the top of the stack, but it is not, so the "waiting to lock"
> message is
Hi all,
The testcase `serviceability/attach/LongArgTest.java` intermittent fails
`java.lang.NoClassDefFoundError: jdk/test/lib/Utils`. Jtreg doesn't
automatically compile `jdk/test/lib/Utils.class` and
`jdk/test/lib/apps/LingeredApp.class` etc.. Maybe it's a jtreg framework bug.
I think it's ne
On Mon, 24 Jun 2024 16:16:29 GMT, SendaoYan wrote:
> Hi all,
> After [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960), the
> footprint memory usage increased significantly when run the testcase with
> -Xcomp jvm options, then cause the testcase was killed by docker by OOM.
> Maybe
On Mon, 24 Jun 2024 16:16:29 GMT, SendaoYan wrote:
> Hi all,
> After [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960), the
> footprint memory usage increased significantly when run the testcase with
> -Xcomp jvm options, then cause the testcase was killed by docker by OOM.
> Maybe
On Thu, 18 Jul 2024 01:49:54 GMT, SendaoYan wrote:
> Hi all,
> The testcase `serviceability/attach/LongArgTest.java` intermittent fails
> `java.lang.NoClassDefFoundError: jdk/test/lib/Utils`. Jtreg doesn't
> automatically compile `jdk/test/lib/Utils.class` and
> `jdk/test/lib/apps/LingeredApp.
On Thu, 18 Jul 2024 00:45:24 GMT, Leonid Mesnik wrote:
>> Sonia Zaldana Calles has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Updates based on feedback
>
> src/hotspot/share/code/codeCache.cpp line 1791:
>
>> 1789:
>> 1790: #ifdef LIN
On Thu, 18 Jul 2024 01:49:54 GMT, SendaoYan wrote:
> Hi all,
> The testcase `serviceability/attach/LongArgTest.java` intermittent fails
> `java.lang.NoClassDefFoundError: jdk/test/lib/Utils`. Jtreg doesn't
> automatically compile `jdk/test/lib/Utils.class` and
> `jdk/test/lib/apps/LingeredApp.
On Thu, 18 Jul 2024 05:37:31 GMT, David Holmes wrote:
>> Hi all,
>> The testcase `serviceability/attach/LongArgTest.java` intermittent fails
>> `java.lang.NoClassDefFoundError: jdk/test/lib/Utils`. Jtreg doesn't
>> automatically compile `jdk/test/lib/Utils.class` and
>> `jdk/test/lib/apps/Ling
On Mon, 24 Jun 2024 16:16:29 GMT, SendaoYan wrote:
> After [JDK-8294960](https://bugs.openjdk.org/browse/JDK-8294960), the
> footprint memory usage increased significantly when run the testcase with
> -Xcomp jvm options, then cause the testcase was killed by docker by OOM.
Maybe the footprint m
On Thu, 18 Jul 2024 05:37:31 GMT, David Holmes wrote:
>> Hi all,
>> The testcase `serviceability/attach/LongArgTest.java` intermittent fails
>> `java.lang.NoClassDefFoundError: jdk/test/lib/Utils`. Jtreg doesn't
>> automatically compile `jdk/test/lib/Utils.class` and
>> `jdk/test/lib/apps/Ling
On Thu, 18 Jul 2024 05:52:51 GMT, Jaikiran Pai wrote:
> So I think we should have this increase in memory reviewed by @asotona or
> someone familiar in that area, before deciding whether these tests should be
> changed.
Okey.
-
PR Comment: https://git.openjdk.org/jdk/pull/19864#i
30 matches
Mail list logo
