On Wed, 20 Mar 2024 03:25:39 GMT, Serguei Spitsyn wrote:
>> Alex Menkov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Updated the fix and the test for multiple annotations
>
> test/jdk/java/lang/instrument/RetransformRecordAnnotation.j
On Tue, 19 Mar 2024 21:57:38 GMT, Alex Menkov wrote:
>> RecordComponent class has _attributes_count field.
>> The only user of the field is JvmtiClassFileReconstituter. Incorrect value
>> of the field causes producing incorrect data for Record attribute.
>> Parsing Record attribute ClassFilePars
On Tue, 19 Mar 2024 00:10:32 GMT, Serguei Spitsyn wrote:
>> The `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes were
>> introduced in the JDK 22 to unify/simplify the JVM TI functions supporting
>> implementation of the virtual threads. This enhancement is to refactor JVM
>> TI func
> This code change adds an alternative implementation of user-based
> authorization `Subject` APIs that doesn't depend on Security Manager APIs.
> Depending on if the Security Manager is allowed, the methods store the
> current subject differently. See the spec change in the `Subject.java` file
On Mon, 18 Mar 2024 13:14:41 GMT, Richard Reingruber wrote:
>> This pr changes `JfrJvmtiAgent::retransform_classes()` and
>> `jfr_set_enabled` to switch to `WXWrite` before transitioning to the vm.
>>
>> Testing:
>> make test TEST=jdk/jfr/event/runtime/TestClassLoadEvent.java
>> TEST_VM_OPTS=
On Sat, 9 Mar 2024 05:27:43 GMT, Leonid Mesnik wrote:
>> vmtestbase nsk/jdi tests run 2 processes: debugger and debugee.
>> There is not need to start debugger in the separate process for each test.
>> Also, no need to run it with "-Xcomp" because the main goal is to test
>> debugee behavior w
On Tue, 19 Mar 2024 20:41:56 GMT, Chris Plummer wrote:
>> Leonid Mesnik has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> reverted failing tests.
>
> test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Binder.java line 757:
>
>> 755: }
>>
On Sat, 9 Mar 2024 05:27:43 GMT, Leonid Mesnik wrote:
>> vmtestbase nsk/jdi tests run 2 processes: debugger and debugee.
>> There is not need to start debugger in the separate process for each test.
>> Also, no need to run it with "-Xcomp" because the main goal is to test
>> debugee behavior w
> RecordComponent class has _attributes_count field.
> The only user of the field is JvmtiClassFileReconstituter. Incorrect value of
> the field causes producing incorrect data for Record attribute.
> Parsing Record attribute ClassFileParser skips unknown attributes and may
> skip RuntimeInvisibl
On Sat, 9 Mar 2024 05:27:43 GMT, Leonid Mesnik wrote:
>> vmtestbase nsk/jdi tests run 2 processes: debugger and debugee.
>> There is not need to start debugger in the separate process for each test.
>> Also, no need to run it with "-Xcomp" because the main goal is to test
>> debugee behavior w
On Tue, 19 Mar 2024 20:42:34 GMT, Chris Plummer wrote:
>> Leonid Mesnik has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> reverted failing tests.
>
> test/hotspot/jtreg/vmTestbase/nsk/share/jdi/ClassExclusionFilterTest.java
> line 43:
>
On Sat, 9 Mar 2024 05:27:43 GMT, Leonid Mesnik wrote:
>> vmtestbase nsk/jdi tests run 2 processes: debugger and debugee.
>> There is not need to start debugger in the separate process for each test.
>> Also, no need to run it with "-Xcomp" because the main goal is to test
>> debugee behavior w
On Sat, 9 Mar 2024 05:27:43 GMT, Leonid Mesnik wrote:
>> vmtestbase nsk/jdi tests run 2 processes: debugger and debugee.
>> There is not need to start debugger in the separate process for each test.
>> Also, no need to run it with "-Xcomp" because the main goal is to test
>> debugee behavior w
On Mon, 18 Mar 2024 13:14:41 GMT, Richard Reingruber wrote:
>> This pr changes `JfrJvmtiAgent::retransform_classes()` and
>> `jfr_set_enabled` to switch to `WXWrite` before transitioning to the vm.
>>
>> Testing:
>> make test TEST=jdk/jfr/event/runtime/TestClassLoadEvent.java
>> TEST_VM_OPTS=
On Tue, 19 Mar 2024 15:17:50 GMT, Thomas Stuefe wrote:
> > Not necessarily. It may well remove some transitions from paths that don't
> > need it, but if you move the state change too low down the call chain you
> > could end up transitioning much more often in code that does need it e.g.
> >
On Tue, 19 Mar 2024 10:16:42 GMT, Matthias Baesken wrote:
>>> If -XX:HeapDumpPath is specified, then it is used as the default
>>
>> No, the filename set with jcmd GC:heamp_dump filename has priority. So we
>> should better keep the current description.
>
> So should I also use HeapDumpGzip
On Mon, 18 Mar 2024 13:14:41 GMT, Richard Reingruber wrote:
>> This pr changes `JfrJvmtiAgent::retransform_classes()` and
>> `jfr_set_enabled` to switch to `WXWrite` before transitioning to the vm.
>>
>> Testing:
>> make test TEST=jdk/jfr/event/runtime/TestClassLoadEvent.java
>> TEST_VM_OPTS=
On Mon, 18 Mar 2024 13:14:41 GMT, Richard Reingruber wrote:
>> This pr changes `JfrJvmtiAgent::retransform_classes()` and
>> `jfr_set_enabled` to switch to `WXWrite` before transitioning to the vm.
>>
>> Testing:
>> make test TEST=jdk/jfr/event/runtime/TestClassLoadEvent.java
>> TEST_VM_OPTS=
On Mon, 18 Mar 2024 13:14:41 GMT, Richard Reingruber wrote:
>> This pr changes `JfrJvmtiAgent::retransform_classes()` and
>> `jfr_set_enabled` to switch to `WXWrite` before transitioning to the vm.
>>
>> Testing:
>> make test TEST=jdk/jfr/event/runtime/TestClassLoadEvent.java
>> TEST_VM_OPTS=
> This task addresses an essential aspect of our testing infrastructure: the
> proper handling and cleanup of temporary files and socket files created
> during test execution. The motivation behind these changes is to prevent the
> accumulation of unnecessary files in the default temporary direc
On Wed, 13 Mar 2024 13:53:46 GMT, Richard Reingruber wrote:
>> src/hotspot/share/jfr/instrumentation/jfrJvmtiAgent.cpp line 160:
>>
>>> 158: ResourceMark rm(THREAD);
>>> 159: // WXWrite is needed before entering the vm below and in callee
>>> methods.
>>> 160: MACOS_AARCH64_ONLY(ThreadWXE
On Tue, 19 Mar 2024 17:08:52 GMT, Richard Reingruber wrote:
> I see it differently. This PR is just a simple attempt to get clean test runs
> with AssertWXAtThreadSync (after fixing an actual crash
> https://bugs.openjdk.org/browse/JDK-8327036). While the violating locations
> in this PR might
On Tue, 19 Mar 2024 12:17:22 GMT, David Holmes wrote:
> But all this discussion suggests to me that this PR is not really worth
> pursuing at this time - IIUC no actual failures are observed other than those
> pertaining to AssertWXAtThreadSync and that flag will be gone if we do decide
> to b
Would a PR to remove these APIs be welcome?
Good with me.
Mandy
On 3/19/24 9:41 AM, Eirik Bjørsnøs wrote:
Hi,
Last September, Volker shared the observation that we have
Hotspot-internal MBeans in sun.management which are strongly
encapsulated and not used internally by OpenJDK besides th
Hi,
Last September, Volker shared the observation that we have Hotspot-internal
MBeans in sun.management which are strongly encapsulated and not used
internally by OpenJDK besides their unit tests:
https://www.mail-archive.com/core-libs-dev@openjdk.org/msg19878.html
A summary of the email thread
On Mon, 18 Mar 2024 09:42:13 GMT, Eirik Bjørsnøs wrote:
> Please review this cleanup PR which removes per-thread compiler stats from
> `sun.management`
>
> This removes:
>
> * The deprecated interface method
> `HotspotCompilationMBean.getCompilerThreadStats()` along with the
> implementation
On Mon, 18 Mar 2024 09:42:13 GMT, Eirik Bjørsnøs wrote:
> Please review this cleanup PR which removes per-thread compiler stats from
> `sun.management`
>
> This removes:
>
> * The deprecated interface method
> `HotspotCompilationMBean.getCompilerThreadStats()` along with the
> implementation
On Tue, 19 Mar 2024 12:17:22 GMT, David Holmes wrote:
>> Instead, could we tag code that needs one or the other, keep track of the
>> current WX state in thread-local memory, and flip WX only when we know we
>> need to?
The first part we already do.
I wonder wheter we could - at least as wor
On Tue, 19 Mar 2024 12:17:22 GMT, David Holmes wrote:
> IIUC no actual failures are observed other than those pertaining to
> AssertWXAtThreadSync
We saw sporadic crashes in our jtreg (maybe also jck?) runs; only **_later_**
we enabled AssertWXAtThreadSync for more checking.
-
P
On Tue, 19 Mar 2024 09:30:52 GMT, Andrew Haley wrote:
> That's very odd. The example there doesn't even involve MAP_JIT memory, so
> what does it have to do with WX?
@theRealAph that is the mystery we hope will be resolved once we know the
nature of the underlying OS bug. Somehow switching to
On Tue, 19 Mar 2024 10:13:16 GMT, Matthias Baesken wrote:
>> So far we only use the gzip level setting from jcmd, not HeapDumpGzipLevel .
>> See the `level` variable in `HeapDumpDCmd::execute` . Yeah you are probably
>> right we should make it consistent.
>
>> If -XX:HeapDumpPath is specified,
On Sat, 16 Mar 2024 12:50:05 GMT, Matthias Baesken wrote:
>> src/hotspot/share/services/diagnosticCommand.cpp line 475:
>>
>>> 473: HeapDumpDCmd::HeapDumpDCmd(outputStream* output, bool heap) :
>>> 474:DCmdWithParser(output, heap),
>>> 475: _filename("filename","Nam
On Tue, 19 Mar 2024 04:37:41 GMT, David Holmes wrote:
> That said we have had a lot of people looking at the overall WX state
> management logic in the past week or so due to
> https://bugs.openjdk.org/browse/JDK-8327860. The workaround there requires us
> to be in EXEC mode
That's very odd.
On Fri, 1 Mar 2024 23:26:48 GMT, Serguei Spitsyn wrote:
> 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 th
On Mon, 18 Mar 2024 23:45:29 GMT, Serguei Spitsyn wrote:
>> 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
On Mon, 18 Mar 2024 23:45:29 GMT, Serguei Spitsyn wrote:
>> 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
On Mon, 18 Mar 2024 09:42:13 GMT, Eirik Bjørsnøs wrote:
> Please review this cleanup PR which removes per-thread compiler stats from
> `sun.management`
>
> This removes:
>
> * The deprecated interface method
> `HotspotCompilationMBean.getCompilerThreadStats()` along with the
> implementation
37 matches
Mail list logo
