> These tests have always silently permitted a -1 return value from
> OperatingSystemMXBean CPU time methods.
>
> They need to be stricter, but occasionally Windows 2019 returns a -1 for the
> first few calls of these methods. This seems to be a Windows 2019 bug or
> peculiarity. Other Window
On Mon, 24 Mar 2025 21:52:41 GMT, Kevin Walls wrote:
>> test/jdk/com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java
>> line 45:
>>
>>> 43: for(int i = 0; i < 10; i++) {
>>> 44: load = mbean.getProcessCpuLoad();
>>> 45: if (load == -1.0) {
>>
>> Plea
On Thu, 20 Mar 2025 14:23:19 GMT, Kevin Walls wrote:
> Following on from JEP 486 (Permanently Disable the Security Manager), there
> are Permission classes which are unused. These should be deprecated, for
> removal in future.
This pull request has now been integrated.
Changeset: 997aa176
Aut
On Tue, 25 Mar 2025 20:36:28 GMT, Chris Plummer wrote:
> Calling ThreadGroupReference.groups() from an event handler can cause a
> deadlock. Details in first comment. Tested with :jdk_lang on all supported
> platforms and tier1, tier2, tier3, and tier5 svc testing.
The reason is because this J
Calling ThreadGroupReference.groups() from an event handler can cause a
deadlock. Details in first comment. Tested with :jdk_lang on all supported
platforms and tier1, tier2, tier3, and tier5 svc testing.
-
Commit messages:
- get rid of unused breakpoint event code
- fix more jche
On Mon, 24 Mar 2025 17:11:55 GMT, Robert Toyonaga wrote:
> Hi stefank, I think you're right about (1.1) (2.1) (2.2) (1.2) being
> prevented by the current implementation. Is there a reason that the current
> implementation only does the wider locking for release/uncommit? Maybe (2.1)
> (1.1) (
On Tue, 25 Mar 2025 11:21:28 GMT, Kevin Walls wrote:
>> These tests have always silently permitted a -1 return value from
>> OperatingSystemMXBean CPU time methods.
>>
>> They need to be stricter, but occasionally Windows 2019 returns a -1 for the
>> first few calls of these methods. This see
On Tue, 25 Mar 2025 08:53:48 GMT, Serguei Spitsyn wrote:
> The internal class JvmtiSuspendControl is transitively used in the
> SuspendThread implementation is not really needed and is being removed. Also,
> the suspend_thread function has unused need_safepoint_p parameter which is
> being rem
On Tue, 25 Mar 2025 11:21:28 GMT, Kevin Walls wrote:
>> These tests have always silently permitted a -1 return value from
>> OperatingSystemMXBean CPU time methods.
>>
>> They need to be stricter, but occasionally Windows 2019 returns a -1 for the
>> first few calls of these methods. This see
On Tue, 25 Mar 2025 21:46:26 GMT, Kevin Walls wrote:
>> These tests have always silently permitted a -1 return value from
>> OperatingSystemMXBean CPU time methods.
>>
>> They need to be stricter, but occasionally Windows 2019 returns a -1 for the
>> first few calls of these methods. This see
On Tue, 25 Mar 2025 20:36:28 GMT, Chris Plummer wrote:
> Calling ThreadGroupReference.groups() from an event handler can cause a
> deadlock. Details in first comment. Tested with :jdk_lang on all supported
> platforms and tier1, tier2, tier3, and tier5 svc testing.
Sorry, I used the wrong bugI
On Mon, 24 Mar 2025 17:00:28 GMT, Thomas Stuefe wrote:
> > And isn't this locking scheme exactly what the current code is using? Have
> > you seen an issue that this proposed PR intends to solve? If there is such
> > a problem I wonder if there's just a missing lock extension in one of the
> >
On Tue, 25 Mar 2025 17:57:56 GMT, Leonid Mesnik wrote:
> The only one generic question: doesn't it makes sense to update JMX to retry
> several times if Windows 2029 returns -1.0 or undefined to make JDK more
> reliable? Are tools like JMC/VisualVM suffer from this issue or they make a
> lot o
On Tue, 25 Mar 2025 16:35:04 GMT, Chris Plummer wrote:
>> Kevin Walls has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> stricter check
>
> test/jdk/com/sun/management/OperatingSystemMXBean/GetProcessCpuTime.java line
> 60:
>
>> 58: /
> These tests have always silently permitted a -1 return value from
> OperatingSystemMXBean CPU time methods.
>
> They need to be stricter, but occasionally Windows 2019 returns a -1 for the
> first few calls of these methods. This seems to be a Windows 2019 bug or
> peculiarity. Other Window
On Tue, 25 Mar 2025 20:20:55 GMT, Robert Toyonaga wrote:
> > ... swapping the order of the release and NMT release booking as a way to
> > shrink the lock scope for the release operation:
> > ...
> > As long as we hold the reservation, no other thread can re-reserve the
> > reservation, so Thre
On Tue, 25 Mar 2025 18:55:56 GMT, Stefan Karlsson wrote:
> ... swapping the order of the release and NMT release booking as a way to
> shrink the lock scope for the release operation:
...
As long as we hold the reservation, no other thread can re-reserve the
reservation, so Thread B can take it
On Tue, 25 Mar 2025 08:53:48 GMT, Serguei Spitsyn wrote:
> The internal class JvmtiSuspendControl is transitively used in the
> SuspendThread implementation is not really needed and is being removed. Also,
> the suspend_thread function has unused need_safepoint_p parameter which is
> being rem
Hi, for you to consider.
These tests constantly fails in qemu-user.
Either the require host to be same arch or they are very very slow in emulation.
E.g. "ptrace(PTRACE_ATTACH, ..) failed for 405157: Function not implemented'"
for SA tests.
This is the initial set of tests, there are many more, b
On Tue, 25 Mar 2025 14:19:55 GMT, Robbin Ehn wrote:
> Hi, for you to consider.
>
> These tests constantly fails in qemu-user.
> Either the require host to be same arch or they are very very slow in
> emulation.
> E.g. "ptrace(PTRACE_ATTACH, ..) failed for 405157: Function not implemented'"
> f
On Wed, 26 Mar 2025 03:12:44 GMT, Serguei Spitsyn wrote:
>> The internal class JvmtiSuspendControl is transitively used in the
>> SuspendThread implementation is not really needed and is being removed.
>> Also, the suspend_thread function has unused need_safepoint_p parameter
>> which is being
On Wed, 26 Mar 2025 03:12:44 GMT, Serguei Spitsyn wrote:
>> The internal class JvmtiSuspendControl is transitively used in the
>> SuspendThread implementation is not really needed and is being removed.
>> Also, the suspend_thread function has unused need_safepoint_p parameter
>> which is being
On Tue, 25 Mar 2025 14:19:55 GMT, Robbin Ehn wrote:
> Hi, for you to consider.
>
> These tests constantly fails in qemu-user.
> Either the require host to be same arch or they are very very slow in
> emulation.
> E.g. "ptrace(PTRACE_ATTACH, ..) failed for 405157: Function not implemented'"
> f
> The internal class JvmtiSuspendControl is transitively used in the
> SuspendThread implementation is not really needed and is being removed. Also,
> the suspend_thread function has unused need_safepoint_p parameter which is
> being removed as well.
>
> Testing:
> - TBD: Run mach5 tiers 1-3 t
On Tue, 25 Mar 2025 20:36:28 GMT, Chris Plummer wrote:
> Calling ThreadGroupReference.groups() from an event handler can cause a
> deadlock. Details in first comment. Tested with :jdk_lang on all supported
> platforms and tier1, tier2, tier3, and tier5 svc testing.
src/java.base/share/classes/
On Tue, 25 Mar 2025 11:21:28 GMT, Kevin Walls wrote:
>> These tests have always silently permitted a -1 return value from
>> OperatingSystemMXBean CPU time methods.
>>
>> They need to be stricter, but occasionally Windows 2019 returns a -1 for the
>> first few calls of these methods. This see
The internal class JvmtiSuspendControl is transitively used in the
SuspendThread implementation is not really needed and is being removed. Also,
the suspend_thread function has unused need_safepoint_p parameter which is
being removed as well.
Testing:
- TBD: Run mach5 tiers 1-3 to be safe
---
On Thu, 20 Mar 2025 14:27:05 GMT, Kevin Walls wrote:
> Following on from JEP 486 (Permanently Disable the Security Manager), there
> are Permission classes which are unused. These should be deprecated, for
> removal in future.
Thanks for the reviews!
-
PR Comment: https://git.ope
On Thu, 20 Mar 2025 14:23:19 GMT, Kevin Walls wrote:
> Following on from JEP 486 (Permanently Disable the Security Manager), there
> are Permission classes which are unused. These should be deprecated, for
> removal in future.
Thanks for the reviews!
-
PR Comment: https://git.ope
On Thu, 20 Mar 2025 14:27:05 GMT, Kevin Walls wrote:
> Following on from JEP 486 (Permanently Disable the Security Manager), there
> are Permission classes which are unused. These should be deprecated, for
> removal in future.
This pull request has now been integrated.
Changeset: 3ac9678e
Aut
30 matches
Mail list logo
