Re: RFR: 8301995: Move invokedynamic resolution information out of ConstantPoolCacheEntry [v13]

2023-03-24 Thread Fei Yang
On Fri, 24 Mar 2023 15:13:40 GMT, Matias Saavedra Silva wrote: >> The current structure used to store the resolution information for >> invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its >> ambigious fields f1 and f2. This structure can hold information for fields, >>

Missing EnclosingMethod attribute in JvmtiClassFileReconstituter.cpp

2023-03-24 Thread Manuel Álvarez Álvarez
Dear all, When dealing with enclosed classes, frameworks like bytebuddy use the EnclosingMethod attribute in order to discover generic type argument bounds. When retransforming a class, the JvmtiClassFileReconstituter.cpp omits the enclosing attributes (they are available in the java.lang.Class ob

Re: Disallowing the dynamic loading of agents by default

2023-03-24 Thread Gregg Wonderly
Lot’s of people use Java in places where there is no “release” cycle of Java version in control of the users. These are “corporate users” in most cases and they have Java applications that they are using which will just “stop working” when a new version of Java is installed. Over the years, I’

Re: [External] : Re: Disallowing the dynamic loading of agents by default

2023-03-24 Thread Gregg Wonderly
After all, we do know that Oracle in fact knows about every single Java application, where it runs, where it’s deployed and what the future plans are for the same. Otherwise, how else could they know what changes need to be made in the platform, right? Gregg Wonderly > On Mar 20, 2023, at 5:1

Re: RFR: 8301995: Move invokedynamic resolution information out of ConstantPoolCacheEntry [v13]

2023-03-24 Thread Andrew Haley
On Fri, 24 Mar 2023 15:13:40 GMT, Matias Saavedra Silva wrote: >> The current structure used to store the resolution information for >> invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its >> ambigious fields f1 and f2. This structure can hold information for fields, >>

Re: RFR: 8304834: Fix wrapper insertion in TestScaffold.parseArgs(String args[]) [v2]

2023-03-24 Thread Leonid Mesnik
On Fri, 24 Mar 2023 06:31:14 GMT, Leonid Mesnik wrote: >> The TestScaffold incorrectly parse options, it should insert wrapper class >> between VM options and applications classame. > > Leonid Mesnik has updated the pull request incrementally with one additional > commit since the last revision

Re: RFR: 8304834: Fix wrapper insertion in TestScaffold.parseArgs(String args[]) [v2]

2023-03-24 Thread Chris Plummer
On Fri, 24 Mar 2023 06:31:14 GMT, Leonid Mesnik wrote: >> The TestScaffold incorrectly parse options, it should insert wrapper class >> between VM options and applications classame. > > Leonid Mesnik has updated the pull request incrementally with one additional > commit since the last revision

Re: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324 [v5]

2023-03-24 Thread Chris Plummer
On Fri, 24 Mar 2023 00:23:19 GMT, Serguei Spitsyn wrote: >> test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest.java >> line 68: >> >>> 66: if (n <= 0) { >>> 67: n = 1000; >>> 68: ToggleNotifyJvmtiTest.sleep(1);

Re: RFR: 8301995: Move invokedynamic resolution information out of ConstantPoolCacheEntry [v13]

2023-03-24 Thread Coleen Phillimore
On Fri, 24 Mar 2023 15:13:40 GMT, Matias Saavedra Silva wrote: >> The current structure used to store the resolution information for >> invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its >> ambigious fields f1 and f2. This structure can hold information for fields, >>

Re: Disallowing the dynamic loading of agents by default

2023-03-24 Thread Andrew Dinn
Hi Ron, Thank you for providing a heads up on the proposed JEP. The Red Hat Java team have been discussing this proposal. We have reviewed the original discussion and also the surrounding debate which established requirements for adaptation of Jigsaw to incorporate the needs of agents. As an

Re: RFR: 8291555: Implement alternative fast-locking scheme [v29]

2023-03-24 Thread Thomas Stuefe
On Thu, 16 Mar 2023 20:56:15 GMT, Roman Kennke wrote: >> This change adds a fast-locking scheme as an alternative to the current >> stack-locking implementation. It retains the advantages of stack-locking >> (namely fast locking in uncontended code-paths), while avoiding the overload >> of the

Re: RFR: 8291555: Implement alternative fast-locking scheme [v29]

2023-03-24 Thread Thomas Stuefe
On Fri, 24 Mar 2023 11:36:24 GMT, Aleksey Shipilev wrote: >> Roman Kennke has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2 >> - Set condition flags correctly afte

Re: RFR: 8301995: Move invokedynamic resolution information out of ConstantPoolCacheEntry [v13]

2023-03-24 Thread Matias Saavedra Silva
> The current structure used to store the resolution information for > invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its > ambigious fields f1 and f2. This structure can hold information for fields, > methods, and invokedynamics and each of its fields can hold different

Re: RFR: 8291555: Implement alternative fast-locking scheme [v29]

2023-03-24 Thread David Holmes
On Fri, 24 Mar 2023 07:00:35 GMT, David Holmes wrote: >> Roman Kennke has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2 >> - Set condition flags correctly after fa

Re: RFR: 8291555: Implement alternative fast-locking scheme [v29]

2023-03-24 Thread David Holmes
On Fri, 24 Mar 2023 10:10:58 GMT, Aleksey Shipilev wrote: >> Roman Kennke has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2 >> - Set condition flags correctly afte

Re: RFR: 8291555: Implement alternative fast-locking scheme [v29]

2023-03-24 Thread Aleksey Shipilev
On Thu, 16 Mar 2023 20:56:15 GMT, Roman Kennke wrote: >> This change adds a fast-locking scheme as an alternative to the current >> stack-locking implementation. It retains the advantages of stack-locking >> (namely fast locking in uncontended code-paths), while avoiding the overload >> of the

Re: RFR: 8301995: Move invokedynamic resolution information out of ConstantPoolCacheEntry [v12]

2023-03-24 Thread Andrew Haley
On Thu, 23 Mar 2023 15:37:27 GMT, Matias Saavedra Silva wrote: >> The current structure used to store the resolution information for >> invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its >> ambigious fields f1 and f2. This structure can hold information for fields, >>

Re: RFR: 8301995: Move invokedynamic resolution information out of ConstantPoolCacheEntry [v12]

2023-03-24 Thread Andrew Haley
On Thu, 23 Mar 2023 15:37:27 GMT, Matias Saavedra Silva wrote: >> The current structure used to store the resolution information for >> invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its >> ambigious fields f1 and f2. This structure can hold information for fields, >>

Re: RFR: 8304725: AsyncGetCallTrace can cause SIGBUS on M1 [v4]

2023-03-24 Thread Johannes Bechberger
> Fixes the issue by transitioning the thread into the WXWrite mode while > walking the stack in AsyncGetCallTrace. > > Tested on my M1 mac. Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision: - Remove misc lines - Disable cachi

Re: RFR: 8304725: AsyncGetCallTrace can cause SIGBUS on M1 [v3]

2023-03-24 Thread Johannes Bechberger
On Thu, 23 Mar 2023 08:20:18 GMT, Johannes Bechberger wrote: >> Fixes the issue by transitioning the thread into the WXWrite mode while >> walking the stack in AsyncGetCallTrace. >> >> Tested on my M1 mac. > > Johannes Bechberger has updated the pull request incrementally with one > additiona

Re: RFR: 8304725: AsyncGetCallTrace can cause SIGBUS on M1 [v3]

2023-03-24 Thread Johannes Bechberger
On Fri, 24 Mar 2023 07:54:56 GMT, Thomas Stuefe wrote: > Not if they run the walker outside the sampled thread. Which would be much > safer in a lot of ways. Yes, it would, but it is not currently possible with ASGCT, albeit changing it would be quite simple (not changing existing use cases or

Re: RFR: 8304725: AsyncGetCallTrace can cause SIGBUS on M1 [v3]

2023-03-24 Thread Thomas Stuefe
On Fri, 24 Mar 2023 07:28:27 GMT, Jaroslav Bachorik wrote: > > Yes, but while JFR interrupts threads too, its sampler runs in its own > > thread, so the async-safety of the interrupted code should not matter, or? > > And this sampling approach is quite subpar when compared with the signal > b

Re: RFR: 8291555: Implement alternative fast-locking scheme [v29]

2023-03-24 Thread Thomas Stuefe
On Fri, 24 Mar 2023 07:00:35 GMT, David Holmes wrote: >> Roman Kennke has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2 >> - Set condition flags correctly after fa

Re: RFR: 8301995: Move invokedynamic resolution information out of ConstantPoolCacheEntry [v12]

2023-03-24 Thread Gui Cao
On Thu, 23 Mar 2023 15:37:27 GMT, Matias Saavedra Silva wrote: >> The current structure used to store the resolution information for >> invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its >> ambigious fields f1 and f2. This structure can hold information for fields, >>

Re: RFR: 8304725: AsyncGetCallTrace can cause SIGBUS on M1 [v3]

2023-03-24 Thread Jaroslav Bachorik
On Thu, 23 Mar 2023 12:45:27 GMT, Johannes Bechberger wrote: > Yes, but while JFR interrupts threads too, its sampler runs in its own > thread, so the async-safety of the interrupted code should not matter, or? And this sampling approach is quite subpar when compared with the signal based pro

Re: RFR: 8291555: Implement alternative fast-locking scheme [v29]

2023-03-24 Thread David Holmes
On Thu, 16 Mar 2023 20:56:15 GMT, Roman Kennke wrote: >> This change adds a fast-locking scheme as an alternative to the current >> stack-locking implementation. It retains the advantages of stack-locking >> (namely fast locking in uncontended code-paths), while avoiding the overload >> of the

Re: RFR: 8291555: Implement alternative fast-locking scheme [v29]

2023-03-24 Thread David Holmes
On Thu, 16 Mar 2023 20:56:15 GMT, Roman Kennke wrote: >> This change adds a fast-locking scheme as an alternative to the current >> stack-locking implementation. It retains the advantages of stack-locking >> (namely fast locking in uncontended code-paths), while avoiding the overload >> of the