On Wed, 27 Mar 2024 01:02:41 GMT, Andrei Pangin wrote:
> This fix makes `AsyncGetCallTrace` reentrant and async-signal-safe.
> Reentrancy is required in the cases when two or more profiling engines are
> running at the same time, e.g., when CPU and Wall clock profilers work
> together and
On Tue, 2 Apr 2024 00:40:37 GMT, Alex Menkov wrote:
> The fix updated HeapDumper to always perform merge on the current thread.
>
> Testing: tier1-5, all HeapDump-related tests
> Covered heap dumping scenarios:
> - `jcmd GC.heap_dump` command;
> - `HotSpotDiagnosticMXBean.dumpHeap()`;
On Fri, 29 Mar 2024 11:35:57 GMT, Andrei Pangin wrote:
>> This fix makes `AsyncGetCallTrace` reentrant and async-signal-safe.
>> Reentrancy is required in the cases when two or more profiling engines are
>> running at the same time, e.g., when CPU and Wall clock profilers work
>> together and
On Wed, 27 Mar 2024 18:31:50 GMT, Kevin Walls wrote:
>> Introduce the jcmd "VM.inspect" to implement access to detailed JVM object
>> information.
>>
>> Not recommended for live production use. Requires UnlockDiagnosticVMOptions
>> and not included in jcmd help output, to remind us this is
On Mon, 1 Apr 2024 02:02:40 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to fix the test
> failure reported in https://bugs.openjdk.org/browse/JDK-8328273?
>
> As noted in that issue, the
> `sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java`
On Mon, 1 Apr 2024 02:02:40 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to fix the test
> failure reported in https://bugs.openjdk.org/browse/JDK-8328273?
>
> As noted in that issue, the
> `sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java`
On Tue, 2 Apr 2024 00:40:37 GMT, Alex Menkov wrote:
> The fix updated HeapDumper to always perform merge on the current thread.
>
> Testing: tier1-5, all HeapDump-related tests
> Covered heap dumping scenarios:
> - `jcmd GC.heap_dump` command;
> - `HotSpotDiagnosticMXBean.dumpHeap()`;
The internal JVM TI `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes
were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting
implementation of the virtual threads. This enhancement is to refactor JVM TI
functions `PopFrame` and `ForceEarlyReturn` on the base of
On Thu, 21 Mar 2024 07:11:33 GMT, Serguei Spitsyn wrote:
> This PR fixes a synchronization issue in the test:
> `test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest`
>
> The method `notifyAtBreakpoint()` can notify the `TestTask` thread when it
> has not reached an expected
On Fri, 29 Mar 2024 15:25:48 GMT, Coleen Phillimore wrote:
> This change simplifies the code that grows the jmethodID cache in
> InstanceKlass. Instead of lazily, when there's a rare request for a
> jmethodID for an obsolete method, the jmethodID cache is grown during the
> RedefineClasses
On Mon, 1 Apr 2024 21:07:34 GMT, Daniel D. Daugherty wrote:
> Trivial fixes to ProblemList noisy tests:
>
> [JDK-8329425](https://bugs.openjdk.org/browse/JDK-8329425) ProblemList
> containers/docker/TestJFREvents.java on linux-x64
> [JDK-8329426](https://bugs.openjdk.org/browse/JDK-8329426)
On Mon, 1 Apr 2024 22:15:06 GMT, David Holmes wrote:
>> Trivial fixes to ProblemList noisy tests:
>>
>> [JDK-8329425](https://bugs.openjdk.org/browse/JDK-8329425) ProblemList
>> containers/docker/TestJFREvents.java on linux-x64
>> [JDK-8329426](https://bugs.openjdk.org/browse/JDK-8329426)
On Mon, 1 Apr 2024 21:07:34 GMT, Daniel D. Daugherty wrote:
> Trivial fixes to ProblemList noisy tests:
>
> [JDK-8329425](https://bugs.openjdk.org/browse/JDK-8329425) ProblemList
> containers/docker/TestJFREvents.java on linux-x64
> [JDK-8329426](https://bugs.openjdk.org/browse/JDK-8329426)
Trivial fixes to ProblemList noisy tests:
[JDK-8329425](https://bugs.openjdk.org/browse/JDK-8329425) ProblemList
containers/docker/TestJFREvents.java on linux-x64
[JDK-8329426](https://bugs.openjdk.org/browse/JDK-8329426) ProblemList
On Mon, 1 Apr 2024 21:07:31 GMT, Vladimir Kozlov wrote:
>> Revert [JDK-8152664](https://bugs.openjdk.org/browse/JDK-8152664) RFE
>> [changes](https://github.com/openjdk/jdk/commit/b853eb7f5ca24eeeda18acbb14287f706499c365)
>> which was used for AOT [JEP 295](https://openjdk.org/jeps/295)
>>
> Revert [JDK-8152664](https://bugs.openjdk.org/browse/JDK-8152664) RFE
> [changes](https://github.com/openjdk/jdk/commit/b853eb7f5ca24eeeda18acbb14287f706499c365)
> which was used for AOT [JEP 295](https://openjdk.org/jeps/295)
> implementation in JDK 9. The code was left in HotSpot assuming
On Mon, 1 Apr 2024 02:02:40 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to fix the test
> failure reported in https://bugs.openjdk.org/browse/JDK-8328273?
>
> As noted in that issue, the
> `sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java`
On Mon, 1 Apr 2024 18:15:43 GMT, Dean Long wrote:
> The `not_used` state was introduced for AOT. It can go away now.
Good catch, Dean.
I want to keep `nmethod::make_not_used()` method because we use it in Leyden to
keep AOT code (outside of CodeCache):
On Mon, 1 Apr 2024 11:29:58 GMT, Serguei Spitsyn wrote:
>> This PR fixes a synchronization issue in the test:
>> `test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest`
>>
>> The method `notifyAtBreakpoint()` can notify the `TestTask` thread when it
>> has not reached an expected
On Mon, 1 Apr 2024 00:19:32 GMT, Fei Yang wrote:
>> Revert [JDK-8152664](https://bugs.openjdk.org/browse/JDK-8152664) RFE
>> [changes](https://github.com/openjdk/jdk/commit/b853eb7f5ca24eeeda18acbb14287f706499c365)
>> which was used for AOT [JEP 295](https://openjdk.org/jeps/295)
>>
On Fri, 29 Mar 2024 19:35:45 GMT, Vladimir Kozlov wrote:
> Revert [JDK-8152664](https://bugs.openjdk.org/browse/JDK-8152664) RFE
> [changes](https://github.com/openjdk/jdk/commit/b853eb7f5ca24eeeda18acbb14287f706499c365)
> which was used for AOT [JEP 295](https://openjdk.org/jeps/295)
>
On Mon, 1 Apr 2024 11:29:58 GMT, Serguei Spitsyn wrote:
>> This PR fixes a synchronization issue in the test:
>> `test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest`
>>
>> The method `notifyAtBreakpoint()` can notify the `TestTask` thread when it
>> has not reached an expected
This change simplifies the code that grows the jmethodID cache in
InstanceKlass. Instead of lazily, when there's a rare request for a jmethodID
for an obsolete method, the jmethodID cache is grown during the RedefineClasses
safepoint. The InstanceKlass's jmethodID cache is lazily allocated
On Fri, 29 Mar 2024 19:35:45 GMT, Vladimir Kozlov wrote:
> Revert [JDK-8152664](https://bugs.openjdk.org/browse/JDK-8152664) RFE
> [changes](https://github.com/openjdk/jdk/commit/b853eb7f5ca24eeeda18acbb14287f706499c365)
> which was used for AOT [JEP 295](https://openjdk.org/jeps/295)
>
On Sat, 30 Mar 2024 01:32:27 GMT, Daniel D. Daugherty
wrote:
>> It wait for some increment of time upto a maximum of 100 seconds.
>
> I'm good with that. Thanks for clarifying.
Thanks, Dan.
I've decided to increase this timeout to 20 secs. Pushed now.
-
PR Review Comment:
> This PR fixes a synchronization issue in the test:
> `test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest`
>
> The method `notifyAtBreakpoint()` can notify the `TestTask` thread when it
> has not reached an expected breakpoint yet.
> The fix is to add a call to the method
On Fri, 29 Mar 2024 20:45:14 GMT, Serguei Spitsyn wrote:
>> test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest/libPopFrameTest.cpp
>> line 164:
>>
>>> 162: fatal(jni, "Main: ensureAtBreakpoint: waited 10 sec");
>>> 163: }
>>> 164: LOG("Main: ensureAtBreakpoint: waitig
27 matches
Mail list logo
