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 Thu, 28 Mar 2024 15:08:27 GMT, Matthias Baesken wrote:
> Yes it is some work on documentation (but seems some doc work needs to be
> done anyway because it was forgotten when `HeapDumpGzipLevel` was introduced).
That currently only impacts 3 documents. Having HeapDumpGzipLevel apply to the
On Fri, 29 Mar 2024 03:50:03 GMT, Chris Plummer wrote:
>> test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest/libPopFrameTest.cpp
>> line 161:
>>
>>> 159: int attempts = 0;
>>> 160: while (!bp_sync_reached) {
>>> 161: LOG("Main: ensureAtBreakpoint: waitig 5 millis\n");
>>
>>
> 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 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 Thu, 28 Mar 2024 15:08:27 GMT, Matthias Baesken wrote:
> Wouldn't this just be a case of changing a flag description? As luck has it,
> the flag already has a generic name that is not tied to OOMs.
One of the issues with this PR is that there are 7 places where some sort of
doc/help update
On Wed, 27 Mar 2024 19:59:28 GMT, Chris Plummer wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: improve diagnostics and reliability
>
>
On Wed, 27 Mar 2024 22:04:30 GMT, Jonathan Gibbons wrote:
> Please review the updates to support a proposed new
> `-Xlint:dangling-doc-comments` option.
>
> The work can be thought of as in 3 parts:
>
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it
> is possible
> 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 Wed, 27 Mar 2024 20:27:42 GMT, Daniel D. Daugherty
wrote:
>> test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest/libPopFrameTest.cpp
>> line 163:
>>
>>> 161: LOG("Main: ensureAtBreakpoint: waitig 5 millis\n");
>>> 162: if (++attempts > 100) {
>>> 163: fatal(jni,
On Wed, 27 Mar 2024 20:06:54 GMT, Chris Plummer wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: improve diagnostics and reliability
>
>
On Thu, 28 Mar 2024 13:09:10 GMT, David Holmes 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
PreserveAllAnnotations option causes class file parser to preserve
RuntimeInvisibleAnnotations so VM considers them as RuntimeVisibleAnnotations.
For class retransformation JvmtiClassFileReconstituter restores all annotations
as RuntimeVisibleAnnotations attributes.
This can cause problem is the
On Wed, 27 Mar 2024 18:39:38 GMT, Chris Plummer wrote:
> I think we also need to consider the flip side of this argument. Is this
> something that some customers might want to always enable, but don't want to
> always have UnlockDiagnosticVMOptions enabled. A new command line flag would
> be
On Thu, 28 Mar 2024 14:12:08 GMT, Andrew Dinn wrote:
>>> It looks like the test only inspects a thread and a java object. Perhaps
>>> you could add tests for additional VM objects. Maybe grab a frame PC from a
>>> thread stack trace.
>>
>> Yes - added a couple of metadata tests, and a
On Thu, 28 Mar 2024 07:02:16 GMT, Thomas Stuefe wrote:
> Wouldn't this just be a case of changing a flag description? As luck has it,
> the flag already has a generic name that is not tied to OOMs.
Yes it is some work on documentation (but seems some doc work needs to be done
anyway because
On Wed, 27 Mar 2024 18:28:07 GMT, Kevin Walls wrote:
>> It looks like the test only inspects a thread and a java object. Perhaps you
>> could add tests for additional VM objects. Maybe grab a frame PC from a
>> thread stack trace.
>
>> It looks like the test only inspects a thread and a java
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 Mon, 25 Mar 2024 13:15:48 GMT, Kevin Walls wrote:
> Test uses jdk.test.lib.Utils.getFreePort() when launching a new Java command.
> Looks like it already recognises "java.rmi.server.ExportException: Port
> already in use: " and retries, but there is a long-standing typo in the check.
>
>
On Mon, 25 Mar 2024 22:46:47 GMT, Kevin Walls wrote:
>> Test uses jdk.test.lib.Utils.getFreePort() when launching a new Java
>> command.
>> Looks like it already recognises "java.rmi.server.ExportException: Port
>> already in use: " and retries, but there is a long-standing typo in the
>>
On Mon, 25 Mar 2024 22:46:47 GMT, Kevin Walls wrote:
>> Test uses jdk.test.lib.Utils.getFreePort() when launching a new Java
>> command.
>> Looks like it already recognises "java.rmi.server.ExportException: Port
>> already in use: " and retries, but there is a long-standing typo in the
>>
On Tue, 19 Mar 2024 16:23:27 GMT, Kevin Walls wrote:
> Client.java has a fixed 30-second timeout on the CountDownLatch to wait for
> 10 notifications.
>
> If it fails, you can't tell if CountDownLatch.await threw, or returned false
> and the app threw InterruptedException, due to the way
On Tue, 19 Mar 2024 16:23:27 GMT, Kevin Walls wrote:
> Client.java has a fixed 30-second timeout on the CountDownLatch to wait for
> 10 notifications.
>
> If it fails, you can't tell if CountDownLatch.await threw, or returned false
> and the app threw InterruptedException, due to the way
On Wed, 27 Mar 2024 23:33:18 GMT, Chris Plummer wrote:
> I did get feedback from a couple of our support engineers. One felt it was of
> no real benefit as it was just as easy to provide the > filename as an
> argument to the jcmd.
That might be true for this support engineer, but not for
On Wed, 27 Mar 2024 23:26:14 GMT, Chris Plummer wrote:
>
> Backporting also came to mind since the trouble shooting guide would need to
> be updated for each Oracle version this PR is backported to. And yes,
> HeapDumpGzipLevel docs need to match the actual implementation. I'm not sure
> if
On Tue, 19 Mar 2024 16:23:27 GMT, Kevin Walls wrote:
> Client.java has a fixed 30-second timeout on the CountDownLatch to wait for
> 10 notifications.
>
> If it fails, you can't tell if CountDownLatch.await threw, or returned false
> and the app threw InterruptedException, due to the way
On Wed, 27 Mar 2024 13:44:42 GMT, Matthias Baesken wrote:
>> Currently jcmd command GC.heap_dump only works with an additionally provided
>> file name.
>> Syntax : GC.heap_dump [options]
>>
>> In case the JVM has the XX - flag HeapDumpPath set, we should support an
>> additional mode where
27 matches
Mail list logo
