RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes

2024-03-29 Thread Vladimir Kozlov
Revert [JDK-8152664](https://bugs.openjdk.org/browse/JDK-8152664) RFE [changes](https://github.com/openjdk/jdk/commit/b853eb7f5ca24eeeda18acbb14287f706499c365) which was used for AOT [JEP 295](https://openjdk.org/jeps/295) implementation in JDK 9. The code was left in HotSpot assuming it will

Re: RFR: 8328665: serviceability/jvmti/vthread/PopFrameTest failed with a timeout [v4]

2024-03-29 Thread Daniel D . Daugherty
On Fri, 29 Mar 2024 23:02:03 GMT, Serguei Spitsyn wrote: >> So that would mean that the native side would always wait for 100 seconds? >> Or will it wait for some increment of time upto a maximum of 100 seconds? > > It wait for some increment of time upto a maximum of 100 seconds. I'm good with

Re: RFR: JDK-8328137: PreserveAllAnnotations can cause failure of class retransformation

2024-03-29 Thread Serguei Spitsyn
On Thu, 28 Mar 2024 22:12:49 GMT, Alex Menkov wrote: > PreserveAllAnnotations option causes class file parser to preserve > RuntimeInvisibleAnnotations so VM considers them as RuntimeVisibleAnnotations. > For class retransformation JvmtiClassFileReconstituter restores all > annotations as

Re: RFR: 8328665: serviceability/jvmti/vthread/PopFrameTest failed with a timeout [v4]

2024-03-29 Thread Serguei Spitsyn
On Fri, 29 Mar 2024 22:18:24 GMT, Daniel D. Daugherty wrote: >> Thank you for the example and for catching the typo. The timeout factor also >> needs to be passed to the native side. I think, this fragment is not worth >> this kind of extra complexity. One approach would be to just make it

Re: RFR: 8328665: serviceability/jvmti/vthread/PopFrameTest failed with a timeout [v4]

2024-03-29 Thread Daniel D . Daugherty
On Fri, 29 Mar 2024 20:44:48 GMT, Serguei Spitsyn wrote: >> runtime/8176717/TestInheritFD.java has an example of what I'm talking about: >> >> public static float timeoutFactor = >> Float.parseFloat(System.getProperty("test.timeout.factor", "1.0")); >> public static long

Re: RFR: 8328665: serviceability/jvmti/vthread/PopFrameTest failed with a timeout [v6]

2024-03-29 Thread Serguei Spitsyn
On Fri, 29 Mar 2024 18:44:35 GMT, Chris Plummer wrote: >> Serguei Spitsyn has updated the pull request incrementally with one >> additional commit since the last revision: >> >> review: move log message to the right place > >

Re: RFR: 8328665: serviceability/jvmti/vthread/PopFrameTest failed with a timeout [v4]

2024-03-29 Thread Serguei Spitsyn
On Fri, 29 Mar 2024 13:29:15 GMT, Daniel D. Daugherty wrote: >> Thanks for the comments, Chris and Dan. Updated as Chris suggested. I've >> added this with `-Xcomp` consideration as the worst case scenario in mind. >> Now, I think it is more save to make it 10 seconds instead of one. Is it

Re: RFR: JDK-8328137: PreserveAllAnnotations can cause failure of class retransformation

2024-03-29 Thread Alex Menkov
On Fri, 29 Mar 2024 07:08:58 GMT, Serguei Spitsyn wrote: > > Correct solution would be to store additional information about > > RuntimeInvisibleAnnotations and restore them exactly as they were in the > > original class (this should be done for all annotations: > >

Re: RFR: 8328665: serviceability/jvmti/vthread/PopFrameTest failed with a timeout [v6]

2024-03-29 Thread Chris Plummer
On Fri, 29 Mar 2024 04:15:43 GMT, Serguei Spitsyn wrote: >> 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

Re: RFR: 8328665: serviceability/jvmti/vthread/PopFrameTest failed with a timeout [v4]

2024-03-29 Thread Daniel D . Daugherty
On Thu, 28 Mar 2024 23:29:53 GMT, Serguei Spitsyn wrote: >> Caught this comment in passing. Delays like this should be scaled with >> defaultTimeoutFactor so that test tasks that invoke tests with options >> that can slow the test down, e.g., `-Xcomp`, can be accommodated. >> >> I believe the

Re: RFR: 8329103: assert(!thread->in_asgct()) failed during multi-mode profiling [v2]

2024-03-29 Thread Serguei Spitsyn
On Fri, 29 Mar 2024 11:35:57 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

Re: RFR: 8329103: assert(!thread->in_asgct()) failed during multi-mode profiling [v2]

2024-03-29 Thread Andrei Pangin
On Fri, 29 Mar 2024 05:55:01 GMT, Serguei Spitsyn wrote: >> Andrei Pangin has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Rephrased comment about AsyncGetCallTrace reentrancy > > src/hotspot/share/runtime/thread.hpp line 664: > >> 662:

Re: RFR: 8329103: assert(!thread->in_asgct()) failed during multi-mode profiling [v2]

2024-03-29 Thread Andrei Pangin
> 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 therefore one profiler may interrupt another in the middle of

Re: RFR: JDK-8328137: PreserveAllAnnotations can cause failure of class retransformation

2024-03-29 Thread Serguei Spitsyn
On Thu, 28 Mar 2024 22:12:49 GMT, Alex Menkov wrote: > Correct solution would be to store additional information about > RuntimeInvisibleAnnotations and restore them exactly as they were in the > original class (this should be done for all annotations: >