On Fri, 12 Apr 2024 14:40:05 GMT, Sergey Nazarkin wrote:
> An alternative for preemptively switching the W^X thread mode on macOS with
> an AArch64 CPU. This implementation triggers the switch in response to the
> SIGBUS signal if the *si_addr* belongs to the CodeCache area. With this
> approa
On Tue, 12 Mar 2024 15:05:00 GMT, Richard Reingruber wrote:
> Updated (2024-03-20):
>
> This PR adds switching to `WXWrite` mode before entering the vm where it is
> missing.
>
> With the changes the following jtreg tests succeed with AssertWXAtThreadSync
> enabled.
&g
On Wed, 20 Mar 2024 14:06:04 GMT, Richard Reingruber wrote:
>> Updated (2024-03-20):
>>
>> This PR adds switching to `WXWrite` mode before entering the vm where it is
>> missing.
>>
>> With the changes the following jtreg tests succeed with AssertWXAtThre
T=compiler/intrinsics/klass/CastNullCheckDroppingsTest.java
> TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
>
> More tests are pending.
Richard Reingruber has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unrelated changes
broug
On Tue, 19 Mar 2024 17:46:31 GMT, Tobias Holenstein
wrote:
>> I've asked this myself (after making the change).
>> Being in `WXWrite` mode would be wrong if the thread would execute
>> dynamically generated code. There's not too much happening outside the scope
>> of the `ThreadInVMfromNative`
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
T=compiler/intrinsics/klass/CastNullCheckDroppingsTest.java
> TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
>
> More tests are pending.
Richard Reingruber has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unrelated changes
broug
On Fri, 15 Mar 2024 13:58:15 GMT, Tobias Holenstein
wrote:
> > As I wrote in JBS, shouldn't this be handled by `ThreadInVMfromNative`?
>
> I agree. This is something I am investigating at the moment. Ideally,
> AssertWXAtThreadSync would also be true by default.
I've added a bunch more locati
T=compiler/intrinsics/klass/CastNullCheckDroppingsTest.java
> TEST_VM_OPTS=-XX:+AssertWXAtThreadSync
>
> More tests are pending.
Richard Reingruber has updated the pull request incrementally with one
additional commit since the last revision:
Set WXWrite at more locations
On Thu, 14 Mar 2024 14:49:12 GMT, Matthias Baesken 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=-X
On Tue, 12 Mar 2024 15:05:00 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
>
On Wed, 13 Mar 2024 12:19:34 GMT, David Holmes 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=-XX:+A
On Wed, 13 Mar 2024 09:49:19 GMT, David Holmes wrote:
> As I wrote in JBS, shouldn't this be handled by `ThreadInVMfromNative`?
(I wanted to publish the PR before answering your comment)
This would be reasonable in my opinion.
I've hoisted setting `WXWrite` mode in `JfrJvmtiAgent::retransform_c
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=-XX:+AssertWXAtThreadSync
make test TEST=compiler/intrinsics/klass/CastNullCheck
On Thu, 9 Nov 2023 15:54:13 GMT, Roman Kennke wrote:
>> See JBS issue for details.
>>
>> I basically:
>> - took the test-modification and turned it into its own test-case
>> - added test runners for lightweight- and legacy-locking, so that we keep
>> testing both, no matter what is the defaul
On Wed, 8 Nov 2023 19:00:53 GMT, Roman Kennke wrote:
> See JBS issue for details.
>
> I basically:
> - took the test-modification and turned it into its own test-case
> - added test runners for lightweight- and legacy-locking, so that we keep
> testing both, no matter what is the default
> -
On Tue, 28 Mar 2023 16:33:09 GMT, Martin Doerr wrote:
>> src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp line 652:
>>
>>> 650: // Scale the index to be the entry index *
>>> sizeof(ResolvedInvokeDynamicInfo)
>>> 651: __ sldi(size, size, log2i_exact(sizeof(ResolvedIndyEntry)));
On Tue, 21 Mar 2023 10:49:32 GMT, Andrew Haley wrote:
>> Matias Saavedra Silva has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix riscv interpreter mistake and acquire semantics
>
> src/hotspot/cpu/aarch64/templateTable_aarch64.cpp line
On Wed, 15 Mar 2023 18:45:00 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,
>>
On Wed, 15 Mar 2023 18:45:00 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,
>>
On Thu, 16 Mar 2023 09:21:26 GMT, Martin Doerr wrote:
>> Basically I kept the local variable as a name for the (now) constant value
>> passed in the call at L3409.
>>
>> The parameter cannot be eliminated since `load_invoke_cp_cache_entry()` is
>> declared in a shared header.
>>
>> I could re
On Wed, 15 Mar 2023 19:04:41 GMT, Martin Doerr wrote:
>> Matias Saavedra Silva has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fixed aarch64 interpreter mistake
>
> src/hotspot/cpu/ppc/templateTable_ppc_64.cpp line 3398:
>
>> 3396: co
On Tue, 14 Mar 2023 17:01:20 GMT, Matias Saavedra Silva
wrote:
> > @matias9927 can I ask you to merge master? There seem to be conflicts (at
> > least I see a message "This branch has conflicts that must be resolved").
> > I'd like to give the change a spin in our CI testing. This requires tha
On Tue, 14 Mar 2023 13:18:40 GMT, Coleen Phillimore wrote:
> Ok, never mind, I saw s390 port but it doesn't seem to be in these changes (?)
It is not in these changes.
@offamitkumar is working on s390x. It is not yet finished though.
(I wasn't aware that putting the URL of this PR into a comment
On Thu, 9 Mar 2023 21:18:19 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,
>>
On Thu, 9 Mar 2023 16:01:21 GMT, Coleen Phillimore wrote:
>> This change should be in a further RFE though (and you can explain it there
>> so we can maybe use it in the other platforms too). Does it affect
>> performance when generating the template interpreter? Do you need to have
>> hsdis
On Tue, 7 Mar 2023 13:30:50 GMT, Coleen Phillimore 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,
>> metho
On Mon, 20 Feb 2023 09:18:46 GMT, Johannes Bechberger wrote:
>> Extends the existing AsyncGetCallTrace test case and fixes the issue.
>
> Johannes Bechberger has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Improve condition again
Looks goo
On Mon, 20 Feb 2023 09:04:39 GMT, Johannes Bechberger wrote:
>> The sanity test worked :)
>
> ... and no regression in the other serviceability tests.
Probably it's better to adapt the limit though (sorry).
Problem with this version is that it allows `unextended_sp` outside the address
range re
On Fri, 17 Feb 2023 14:47:56 GMT, Johannes Bechberger wrote:
>> Extends the existing AsyncGetCallTrace test case and fixes the issue.
>
> Johannes Bechberger has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Revert previous change
src/hotspo
On Thu, 16 Feb 2023 14:25:15 GMT, Johannes Bechberger wrote:
>> Extends the existing AsyncGetCallTrace test case and fixes the issue by
>> modifying `MethodHandles` code.
>
> Johannes Bechberger has updated the pull request incrementally with one
> additional commit since the last revision:
>
On Thu, 16 Feb 2023 00:36:03 GMT, Jorn Vernee wrote:
> So... my understanding is that a c2i adapter is used when a callee is
> interpreted, so its `from_compiled_entry` points to the c2i adapter. A
> compiled caller calls the `from_compiled_entry`, so it ends up going through
> the `c2i` adapter
On Wed, 15 Feb 2023 21:39:52 GMT, Jorn Vernee wrote:
> The entry generated by generate_method_handle_interpreter_entry is
> essentially the from_interpreted_entry, AFAIU.
But it is also stored in `Method::_i2i_entry` which is [used by c2i
adapters](https://github.com/openjdk/jdk/blob/3ba156082
On Wed, 15 Feb 2023 21:12:19 GMT, Jorn Vernee wrote:
>>> I think your conclusion is correct wrt `unextended_sp < sp` in that case.
>>> For certain MH linker calls, an additional `MemberName` 'appendix' is
>>> passed as the last argument. The MH adapter/trampoline stub pops the
>>> appendix arg
On Wed, 15 Feb 2023 20:38:04 GMT, Johannes Bechberger wrote:
>>> I think `unextended_sp < sp` is possible on x86 when interpreter entries
>>> generated by `MethodHandles::generate_method_handle_interpreter_entry()`
>>> are executed. They modify `sp` ([here for
>>> example](https://github.com/o
On Tue, 14 Feb 2023 07:38:21 GMT, Johannes Bechberger wrote:
>> The test fails without this relaxation and the relaxation has been used on
>> PPC to solve a similar issue a few years back.
>
> The original assumption does not always hold anymore and should therefore
> relaxed.
I think `unexten
On Thu, 24 Nov 2022 10:59:41 GMT, Martin Doerr wrote:
> Related issue is fixed with
> [JDK-8228649](https://bugs.openjdk.org/browse/JDK-8228649)
> Test has passed.
Lgtm
-
Marked as reviewed by rrich (Reviewer).
PR: https://git.openjdk.org/jdk/pull/11351
On Tue, 22 Nov 2022 05:57:37 GMT, Serguei Spitsyn wrote:
>> The can_support_virtual_thread was initially implemented as an onload
>> capability.
>> It is why this capability does not work for the agents loaded into running
>> VM.
>> The fix is to move it from `onload` to `always`capabilities li
On Mon, 21 Nov 2022 19:08:16 GMT, Serguei Spitsyn wrote:
>> src/hotspot/share/prims/jvmtiExport.cpp line 201:
>>
>>> 199: JvmtiVirtualThreadEventMark(JavaThread *thread) :
>>> 200: JvmtiEventMark(thread) {
>>> 201: if (thread->vthread() != NULL) {
>>
>> Can this condition ever be fals
On Sun, 20 Nov 2022 08:48:16 GMT, Serguei Spitsyn wrote:
>> The can_support_virtual_thread was initially implemented as an onload
>> capability.
>> It is why this capability does not work for the agents loaded into running
>> VM.
>> The fix is to move it from `onload` to `always`capabilities li
On Thu, 17 Nov 2022 09:24:04 GMT, Erik Österlund wrote:
>> The current loom code makes some assumptions about GC that will not work
>> with generational ZGC. We should make this code more GC agnostic, and
>> provide a better interface for talking to the GC.
>>
>> In particular,
>> 1) All GCs h
On Thu, 17 Nov 2022 09:23:48 GMT, Erik Österlund wrote:
>> src/hotspot/share/gc/shared/barrierSetStackChunk.cpp line 68:
>>
>>> 66:
>>> 67: virtual void do_oop(oop* p) override {
>>> 68: if (UseCompressedOops) {
>>
>> Wouldn't it be better to hoist the check for `UseCompressedOops`?
>
>
On Mon, 14 Nov 2022 16:07:34 GMT, Erik Österlund wrote:
>> The current loom code makes some assumptions about GC that will not work
>> with generational ZGC. We should make this code more GC agnostic, and
>> provide a better interface for talking to the GC.
>>
>> In particular,
>> 1) All GCs h
On Wed, 19 Oct 2022 15:43:17 GMT, Richard Reingruber wrote:
> With `StressReflectiveCode` C2 has inexact type information which can prevent
> ea
> based optimizations (see `ConnectionGraph::add_call_node()`)
>
> This pr changes the test jdk/com/sun/jdi/EATests.java t
On Thu, 20 Oct 2022 20:55:12 GMT, Richard Reingruber wrote:
>> With `StressReflectiveCode` C2 has inexact type information which can
>> prevent ea
>> based optimizations (see `ConnectionGraph::add_call_node()`)
>>
>> This pr changes the test jdk/com/sun/jdi
VM_OPTS="-XX:+IgnoreUnrecognizedVMOptions -XX:+StressReflectiveCode"
Richard Reingruber has updated the pull request incrementally with one
additional commit since the last revision:
Skip all test cases if StressReflectiveCode is enabled
-
Changes:
- all: https://git.openjdk.org/jdk/pul
On Thu, 20 Oct 2022 19:52:39 GMT, Vladimir Kozlov wrote:
> Should we add check for `StressReflectiveCode` to all `shouldSkip()` methods
> too? Similar to `DeoptimizeObjectsALot` flag.
I'd be ok to skip all testcases (by checking for `StressReflectiveCode` in the
base classes' `shouldSkip()`).
On Wed, 19 Oct 2022 15:43:17 GMT, Richard Reingruber wrote:
> With `StressReflectiveCode` C2 has inexact type information which can prevent
> ea
> based optimizations (see `ConnectionGraph::add_call_node()`)
>
> This pr changes the test jdk/com/sun/jdi/EATests.java t
With `StressReflectiveCode` C2 has inexact type information which can prevent ea
based optimizations (see `ConnectionGraph::add_call_node()`)
This pr changes the test jdk/com/sun/jdi/EATests.java to read the flag
`StressReflectiveCode`. If enabled it shall neither expect ea based
optimizations
of
49 matches
Mail list logo
