Re: RFR: 8283092: JMX subclass permission check redundant with strong encapsulation [v2]

2022-03-18 Thread Kevin Walls
> Removing permission checks which, in the presence of a Security Manager, > would check for a RuntimePermission "className.subclass". This was to > prevent subclassing these classes, but is no longer necessary with strong > encapsulation from modules. Kevin Walls has updated the pull request

Re: RFR: 8283092: JMX subclass permission check redundant with strong encapsulation

2022-03-18 Thread Kevin Walls
On Tue, 15 Mar 2022 20:22:16 GMT, Kevin Walls wrote: > Removing permission checks which, in the presence of a Security Manager, > would check for a RuntimePermission "className.subclass". This was to > prevent subclassing these classes, but is no longer necessary with strong > encapsulation

Re: RFR: 8283092: JMX subclass permission check redundant with strong encapsulation

2022-03-18 Thread Kevin Walls
On Thu, 17 Mar 2022 13:55:22 GMT, Sean Mullan wrote: > test/jdk/sun/management/PlatformMBeanProviderConstructorCheck.java Thank for noticing that Sean - had run various tests but missed this. I have an update, will add it here soon. - PR:

Re: Proposal of a new version of AsyncGetCallTrace

2022-03-18 Thread Remi Forax
Knowing if there is a C stackframe in the middle of the stack while blocking on a synchronized is an important feature for a profiler when loom will land. RĂ©mi - Original Message - > From: "Bechberger, Johannes" > To: "hotspot-dev" , > hotspot-jfr-...@openjdk.java.net,

Proposal of a new version of AsyncGetCallTrace

2022-03-18 Thread Bechberger, Johannes
Hi, I would like propose to 1. Replace duplicated stack walking code with unified API 2. Create a new version of AsyncGetCallTrace, tentatively called "AsyncGetCallTrace2", with more information on more frames using the unified API A demo (as well as this text) is available at

Re: RFR: 8282475: SafeFetch should not rely on existence of Thread::current [v7]

2022-03-18 Thread Johannes Bechberger
On Fri, 11 Mar 2022 07:52:16 GMT, Johannes Bechberger wrote: >> The WXMode for the current thread (on MacOS aarch64) is currently stored in >> the thread class which is unnecessary as the WXMode is bound to the current >> OS thread, not the current instance of the thread class. >> This pull