On Sat, 2 Mar 2024 04:33:11 GMT, Chris Plummer wrote:
>> Two variants:
>>
>> public void runHelper(CommandExecutor executor, String cmd, Path path) {
>>try {
>>run(executor, cmd, path);
>>} catch (Throwable t) {
>> t.printStackTrace(System.out);
>>
On Sat, 2 Mar 2024 01:40:39 GMT, Serguei Spitsyn wrote:
>>> Q2: Can we use Files.deleteIfExists(path) in the finally block of the
>>> run() method instead?
>>
>> I don't think that changes anything. If run() throws an exception and then
>> Files.deleteIfExists() throws an exception from the f
On Sat, 2 Mar 2024 00:44:02 GMT, Chris Plummer wrote:
>> test/hotspot/jtreg/serviceability/dcmd/compiler/PerfMapTest.java line 103:
>>
>>> 101: } while(Files.exists(path));
>>> 102: run(new JMXExecutor(), "Compiler.perfmap " + path.toString(),
>>> path);
>>> 103: }
>>
>> Q1
On Sat, 2 Mar 2024 00:14:22 GMT, Serguei Spitsyn wrote:
> Q2: Can we use Files.deleteIfExists(path) in the finally block of the run()
> method instead?
I don't think that changes anything. If run() throws an exception and then
Files.deleteIfExists() throws an exception from the finally block,
On Fri, 23 Feb 2024 21:55:15 GMT, Chris Plummer wrote:
> PerfMapTest.java issues the Compiler.perfmap jcmd with a filename argument to
> write the perfmap to. It does this in 3 different modes. 2 of the modes
> result in a perfmap file being left in the tmp directory that is not removed
> afte
On Fri, 23 Feb 2024 21:55:15 GMT, Chris Plummer wrote:
> PerfMapTest.java issues the Compiler.perfmap jcmd with a filename argument to
> write the perfmap to. It does this in 3 different modes. 2 of the modes
> result in a perfmap file being left in the tmp directory that is not removed
> afte
Please, review this fix correcting the JVMTI `RawMonitorWait()` implementation.
The `RawMonitorWait()` is using the the `jt->is_interrupted(true)` to update
the interrupt status of the interrupted waiting thread. The issue is that when
it calls `jt->is_interrupted(true)` to fetch and clear the
On Fri, 23 Feb 2024 21:55:15 GMT, Chris Plummer wrote:
> PerfMapTest.java issues the Compiler.perfmap jcmd with a filename argument to
> write the perfmap to. It does this in 3 different modes. 2 of the modes
> result in a perfmap file being left in the tmp directory that is not removed
> afte
On Fri, 1 Mar 2024 17:24:02 GMT, Doug Simon wrote:
> To account for slightly slower compile times on libgraal + fastdebug +
> `-Xcomp`, this PR increases a timeout in `NotifReconnectDeadlockTest.java`
> from 2000 ms to 3000 ms.
> With this change, the test now reliably passes.
This pull reques
On Fri, 1 Mar 2024 17:24:02 GMT, Doug Simon wrote:
> To account for slightly slower compile times on libgraal + fastdebug +
> `-Xcomp`, this PR increases a timeout in `NotifReconnectDeadlockTest.java`
> from 2000 ms to 3000 ms.
> With this change, the test now reliably passes.
Thanks for the r
On Fri, 1 Mar 2024 17:24:02 GMT, Doug Simon wrote:
> To account for slightly slower compile times on libgraal + fastdebug +
> `-Xcomp`, this PR increases a timeout in `NotifReconnectDeadlockTest.java`
> from 2000 ms to 3000 ms.
> With this change, the test now reliably passes.
Sounds good.
On
On Wed, 14 Feb 2024 21:13:56 GMT, Daniel D. Daugherty
wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: added assert to get_pending_threads; added suggested coverage to
>> test objmonusage003
>
> CHECK_F
On Fri, 1 Mar 2024 17:24:02 GMT, Doug Simon wrote:
> To account for slightly slower compile times on libgraal + fastdebug +
> `-Xcomp`, this PR increases a timeout in `NotifReconnectDeadlockTest.java`
> from 2000 ms to 3000 ms.
> With this change, the test now reliably passes.
Looks good
To account for slightly slower compile times on libgraal + fastdebug +
`-Xcomp`, this PR increases a timeout in `NotifReconnectDeadlockTest.java` from
2000 ms to 3000 ms.
With this change, the test now reliably passes.
-
Commit messages:
- adjust timeout in NotifReconnectDeadlockTe
On Fri, 1 Mar 2024 09:31:47 GMT, Kevin Walls wrote:
>> @slovdahl - Apologies for adding a comment to a closed Pull Request, but I
>> happened on https://bugs.openjdk.org/browse/JDK-8307977 via the earlier
>> https://bugs.openjdk.org/browse/JDK-8179498 after researching
>> "AttachNotSupportedEx
> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the
> spec.
> The function returns the following structure:
>
>
> typedef struct {
> jthread owner;
> jint entry_count;
> jint waiter_count;
> jthread* waiters;
> jint notify_waiter_count;
> jthread
> The implementation of the JVM TI `GetCurrentContendedMonitor()` does not
> match the spec. It can sometimes return an incorrect information about the
> contended monitor. Such a behavior does not match the function spec.
> With this update the `GetCurrentContendedMonitor()` is returning the mo
> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the
> spec.
> The function returns the following structure:
>
>
> typedef struct {
> jthread owner;
> jint entry_count;
> jint waiter_count;
> jthread* waiters;
> jint notify_waiter_count;
> jthread
On Thu, 29 Feb 2024 04:17:09 GMT, Serguei Spitsyn wrote:
>> The implementation of the JVM TI `GetCurrentContendedMonitor()` does not
>> match the spec. It can sometimes return an incorrect information about the
>> contended monitor. Such a behavior does not match the function spec.
>> With thi
> The implementation of the JVM TI `GetObjectMonitorUsage` does not match the
> spec.
> The function returns the following structure:
>
>
> typedef struct {
> jthread owner;
> jint entry_count;
> jint waiter_count;
> jthread* waiters;
> jint notify_waiter_count;
> jthread
On Tue, 27 Feb 2024 10:44:20 GMT, Kevin Walls wrote:
> The deprecated Subject Delegation feature in JMX will be removed.
>
> This was marked in JDK 21 as deprecated for removal (JDK-8298966).
This covers the public interface to the feature, and tests.
Locally the feature is refused during a ca
The deprecated Subject Delegation feature in JMX will be removed.
This was marked in JDK 21 as deprecated for removal (JDK-8298966).
-
Commit messages:
- JMXConnector to throw UnsupportedOperationException
- RMIConnectionImpl to throw when RMI calls invoke with delegatedSubject.
On Wed, 28 Feb 2024 20:02:39 GMT, jdoylei wrote:
>> Thank you @kevinjwalls and @jerboaa for reviewing and guiding me through
>> this process, this was a great as a first-time JDK contributor!
>>
>> One more question, can I do anything to help getting this backported to e.g.
>> 21 and 17?
>
> @
> Introduce the jcmd "VM.debug" to implement access to a useful set of the
> established debug.cpp utilities, with "jcmd PID VM.debug subcommand ...".
>
> Not recommended for live production use. Calling these "debug" utilities,
> and not including them in the jcmd help output, is to remind us
24 matches
Mail list logo
