On Sun, 20 Mar 2022 22:49:49 GMT, David Holmes wrote:
> My comment was specifically in response to your statement:
> > I see AsyncGetCallTrace to assume the JavaThread very soon
>
> But AGCT is only intended to ever be called on JavaThreads.
Sorry, it was my question. It looked for me this way
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
On Thu, 10 Mar 2022 18:04:50 GMT, Thomas Stuefe wrote:
> blocking SIGSEGV and SIGBUS - or other synchronous error signals like SIGFPE
> - and then triggering said signal is UB. What happens is OS-dependent. I saw
> processes vanishing, or hang, or core. It makes sense, since what is the
>
On Thu, 10 Mar 2022 18:07:37 GMT, Thomas Stuefe wrote:
> > > > Is it possible to change SafeFetch only? Switch to WXExec before
> > > > calling the stub and switch WXWrite back unconditionally? We won't need
> > > > to provide assert in ThreadWXEnable. But SafeFetch can check the
> > > >
On Thu, 10 Mar 2022 12:41:11 GMT, Thomas Stuefe wrote:
> You are saying that Java Threads may write too. And CompilerThreads, in the
> case of SafeFetch at least, may run generated code. So switching has to be
> done as a stack mark. Have I gotten this right?
Right.
> Depending on what the
On Thu, 10 Mar 2022 10:17:31 GMT, David Holmes wrote:
> Signal handlers are per-process not per-thread, so a thread need not be
> attached to the VM for our signal handlers to get involved - that is why they
> call Thread::current_or_null_safe().
Oh, right, thanks. I was too concentrated on
On Thu, 10 Mar 2022 07:09:27 GMT, Anton Kozlov wrote:
> > Interesting. But I would nonetheless create an assertion that checks that
> > there is no nesting in the case without a Thread object. I would this using
> > a thread local nesting counter in the ThreadWXEnable
On Thu, 10 Mar 2022 06:00:42 GMT, Thomas Stuefe wrote:
> Arguably we should restore, upon leaving the VM, the state that has been
> present before. Because a native thread may already have modified the wx
> state and overruling it is just rude. But I offhand don't see a way to do
> this since
On Wed, 9 Mar 2022 20:25:02 GMT, Johannes Bechberger
wrote:
> Interesting. But I would nonetheless create an assertion that checks that
> there is no nesting in the case without a Thread object. I would this using a
> thread local nesting counter in the ThreadWXEnable class (incremented in
On Thu, 10 Mar 2022 05:52:48 GMT, Thomas Stuefe wrote:
> Why don't we just switch it on once, for a thread that conceivably may call
> into generated code, and be done with? Why is this fine granular switching
> even needed? I find it difficult to imagine an attack vector that exploits
>
On Wed, 9 Mar 2022 08:35:41 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
On Wed, 9 Mar 2022 08:35:41 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
On Tue, 13 Jul 2021 10:13:39 GMT, Anton Kozlov wrote:
>> The change adds W^X transition in RawMonitor family of functions, fixing the
>> crash. RawMonitor functions are treated specially, so W^X transition is not
>> inserted automatically. A better fix would be i
On Mon, 12 Jul 2021 20:22:25 GMT, Anton Kozlov wrote:
> The change adds W^X transition in RawMonitor family of functions, fixing the
> crash. RawMonitor functions are treated specially, so W^X transition is not
> inserted automatically. A better fix would be in .xml description fo
hope to get this fixed in 17 in
> the simplest way and do re-work in the 18. This change is still 100% correct
> for the reported bug.
>
> Verified by:
>
> jtreg -vmoption:-XX:+AssertWXAtThreadSync
> test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002
On Tue, 13 Jul 2021 01:25:48 GMT, David Holmes wrote:
>> Anton Kozlov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Subset of RawMonitor; comments added
>
> I can understand that raw_enter and raw_wait n
The change adds W^X transition in RawMonitor family of functions, fixing the
crash. RawMonitor functions are treated specially, so W^X transition is not
inserted automatically. A better fix would be in .xml description for entries
generation, but for now it is too risky. I hope to get this
On Tue, 25 May 2021 11:23:33 GMT, Anton Kozlov wrote:
> Please review a small change that adds an option to GC.heap_dump to use an
> existing file.
>
> The option is necessary if the target file is a predefined file-like object,
> like a named pipe. This opens up a lot o
On Wed, 2 Jun 2021 20:57:02 GMT, Anton Kozlov wrote:
>> Please review a small change that adds an option to GC.heap_dump to use an
>> existing file.
>>
>> The option is necessary if the target file is a predefined file-like object,
>> like a named pipe. This o
On Sat, 5 Jun 2021 15:51:49 GMT, Christoph Langer wrote:
> I would suggest to change the CSR to use "overwrite" but other than that, it
> seems fine.
Right, thanks! Now it is fixed, CSR uses "overwrite".
-
PR: https://git.openjdk.java.net/jdk/pull/4183
ing it to the file system first.
>
> Reviews of the CSR linked to the bug would be appreciated as well.
Anton Kozlov has updated the pull request incrementally with one additional
commit since the last revision:
Fix windows flags (although complied fine)
-
Changes:
- all: http
On Wed, 2 Jun 2021 20:05:56 GMT, Anton Kozlov wrote:
>> Please review a small change that adds an option to GC.heap_dump to use an
>> existing file.
>>
>> The option is necessary if the target file is a predefined file-like object,
>> like a named pipe. This o
ing it to the file system first.
>
> Reviews of the CSR linked to the bug would be appreciated as well.
Anton Kozlov has updated the pull request incrementally with two additional
commits since the last revision:
- Fix create_binary_file
- Rename option to -overwrite
-
On Fri, 28 May 2021 10:49:32 GMT, Anton Kozlov wrote:
>> Please review a small change that adds an option to GC.heap_dump to use an
>> existing file.
>>
>> The option is necessary if the target file is a predefined file-like object,
>> like a named pipe. This o
On Fri, 28 May 2021 10:49:32 GMT, Anton Kozlov wrote:
>> Please review a small change that adds an option to GC.heap_dump to use an
>> existing file.
>>
>> The option is necessary if the target file is a predefined file-like object,
>> like a named pipe. This o
On Thu, 27 May 2021 13:57:05 GMT, Lin Zang wrote:
> you may need to add test cases
A test is trivial. Just in case, I've added it.
> it seems the /csr label is required
Is the label really required? I don't see any integrated RFR with the label. I
won't push this before CSR is approved
ing it to the file system first.
>
> Reviews of the CSR linked to the bug would be appreciated as well.
Anton Kozlov has updated the pull request incrementally with one additional
commit since the last revision:
Extend HeapDumpTest
-
Changes:
- all: https://git.openjdk.java
On Tue, 25 May 2021 11:23:33 GMT, Anton Kozlov wrote:
> Please review a small change that adds an option to GC.heap_dump to use an
> existing file.
>
> The option is necessary if the target file is a predefined file-like object,
> like a named pipe. This opens up a lot o
On Tue, 23 Mar 2021 16:33:50 GMT, Andrew Haley wrote:
>> Marked as reviewed by luhenry (Author).
>
>> > > > [ Back-porting this patch to JDK 11] depends on the will of openjdk11
>> > > > maintainers to accept this (and few other, like jep-388, as we depend
>> > > > on it) contribution.
>> > >
switch to
> execute-only mode. The same execute-only mode is enabled when a java thread
> executes in java or native states. This approach of managing W^X mode turned
> out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
On Fri, 22 Jan 2021 18:49:42 GMT, Anton Kozlov wrote:
> Please review the implementation of JEP 391: macOS/AArch64 Port.
>
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
> windows/aarch64.
>
> Major changes are in:
> * src/hotspot/cpu/aarch6
On Tue, 23 Mar 2021 12:49:34 GMT, Magnus Ihse Bursie wrote:
>> Anton Kozlov has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 115 commits:
>>
>> - Merge branch 'master' into jdk-macos
>> - JDK-82624
switch to
> execute-only mode. The same execute-only mode is enabled when a java thread
> executes in java or native states. This approach of managing W^X mode turned
> out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
On Sat, 13 Mar 2021 05:49:53 GMT, David Holmes wrote:
>> Anton Kozlov has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 114 commits:
>>
>> - JDK-8262491: bsd_aarch64 part
>> - JDK-8263002: bsd_a
On Wed, 10 Mar 2021 11:21:44 GMT, Andrew Haley wrote:
>> We always check for `R18_RESERVED` with `#if(n)def`, is there any reason to
>> define the value for the macro?
>
> Robustness, clarity, maintainability, convention. Why not?
I've tried to implement the suggestion, but it pulled more
On Thu, 11 Mar 2021 20:27:51 GMT, Stefan Karlsson wrote:
>> The thread_bsd_aarch64.hpp describes a part of JavaThread, while this block
>> belongs to Thread for now. Since W^X is an attribute of any operating system
>> thread, I assumed Thread to be the right place for W^X bookkeeping.
>>
>>
switch to
> execute-only mode. The same execute-only mode is enabled when a java thread
> executes in java or native states. This approach of managing W^X mode turned
> out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
switch to
> execute-only mode. The same execute-only mode is enabled when a java thread
> executes in java or native states. This approach of managing W^X mode turned
> out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-82549
On Thu, 11 Mar 2021 20:28:46 GMT, Stefan Karlsson wrote:
>> Anton Kozlov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8262903: [macos_aarch64] Thread::current() called on detached thread
>
> Marked as
switch to
> execute-only mode. The same execute-only mode is enabled when a java thread
> executes in java or native states. This approach of managing W^X mode turned
> out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-82549
On Fri, 12 Mar 2021 05:24:10 GMT, David Holmes wrote:
>> Anton Kozlov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8262903: [macos_aarch64] Thread::current() called on detached thread
>
On Wed, 3 Mar 2021 15:57:13 GMT, Gerard Ziemski wrote:
>> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 207:
>>
>>> 205: // Enable WXWrite: this function is called by the signal handler at
>>> arbitrary
>>> 206: // point of execution.
>>> 207: ThreadWXEnable wx(WXWrite, thread);
switch to
> execute-only mode. The same execute-only mode is enabled when a java thread
> executes in java or native states. This approach of managing W^X mode turned
> out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-82549
On Mon, 1 Mar 2021 10:31:19 GMT, Andrew Haley wrote:
>> Anton Kozlov has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos
>> - Minor fix
On Tue, 9 Feb 2021 09:23:50 GMT, Stefan Karlsson wrote:
>> Anton Kozlov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update signal handler part for debugger
>
> src/hotspot/share/runtime/thread.c
On Tue, 9 Feb 2021 09:12:13 GMT, Stefan Karlsson wrote:
>> Anton Kozlov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update signal handler part for debugger
>
> src/hotspot/share/runtime/thread.hpp line
switch to
> execute-only mode. The same execute-only mode is enabled when a java thread
> executes in java or native states. This approach of managing W^X mode turned
> out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
On Tue, 9 Feb 2021 09:06:26 GMT, Stefan Karlsson wrote:
>> Anton Kozlov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update signal handler part for debugger
>
> src/hotspot/share/runtime/threadWXSetters.
On Wed, 3 Mar 2021 17:46:41 GMT, Andrew Haley wrote:
> A list of the bugs that our internal testing revealed so far ...
Thank you! Some of them look like test issues, but a few need more serious
consideration. I want to resolve
https://bugs.openjdk.java.net/browse/JDK-8262903 at least, along
On Thu, 4 Feb 2021 22:58:39 GMT, Gerard Ziemski wrote:
>> Anton Kozlov has updated the pull request incrementally with six additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos
>> -
switch to
> execute-only mode. The same execute-only mode is enabled when a java thread
> executes in java or native states. This approach of managing W^X mode turned
> out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-82549
On Fri, 12 Feb 2021 15:21:06 GMT, Vladimir Kempik wrote:
>> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 302:
>>
>>> 300: const uint64_t *detail_msg_ptr
>>> 301: = (uint64_t*)(pc + NativeInstruction::instruction_size);
>>> 302: const char *detail_msg = (const
On Thu, 4 Feb 2021 22:34:16 GMT, Gerard Ziemski wrote:
>> Anton Kozlov has updated the pull request incrementally with six additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos
>> -
On Thu, 4 Feb 2021 22:15:47 GMT, Gerard Ziemski wrote:
>> Anton Kozlov has updated the pull request incrementally with six additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos
>> -
On Tue, 2 Feb 2021 23:10:17 GMT, Daniel D. Daugherty wrote:
> For platform files that were copied from other ports to this port, if the
> file wasn't
> changed I presume the copyright years are left alone. If the file required
> changes
> for this port, I expect the year to be updated to 2021.
On Tue, 2 Feb 2021 22:47:04 GMT, Daniel D. Daugherty wrote:
>> Anton Kozlov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> support macos_aarch64 in hsdis
>
> src/hotspot/share/prims/nativeEntryPoint.cpp
On Tue, 2 Feb 2021 22:18:43 GMT, Daniel D. Daugherty wrote:
>> Anton Kozlov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> support macos_aarch64 in hsdis
>
> src/hotspot/os_cpu/bsd_aarch64/thread_bsd
On Fri, 12 Feb 2021 13:32:52 GMT, Vladimir Kempik wrote:
>> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 486:
>>
>>> 484: }
>>> 485: }
>>> 486: }
>>
>> This appears to be a mix for Mavericks (10.9) and 10.12
>> work arounds. Is this code needed by this project?
>
>
On Fri, 12 Feb 2021 12:40:09 GMT, Florian Weimer wrote:
>> only macos comiplers
>
> The comment is also wrong for glibc: The AArch64 ABI requires a 64 KiB guard
> region independently of page size, otherwise `-fstack-clash-protection` is
> not reliable.
Thanks, I deleted the comment. It
On Mon, 15 Feb 2021 17:59:54 GMT, Vladimir Kempik wrote:
>> src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 810:
>>
>>> 808: #ifdef __APPLE__
>>> 809: // Less-than word types are stored one after another.
>>> 810: // The code unable to handle this, bailout.
>>
>>
On Mon, 1 Mar 2021 10:46:34 GMT, Andrew Haley wrote:
>> They are defined in 13.2.95. MIDR_EL1, Main ID Register. Apple's code is not
>> there, but "Arm can assign codes that are not published in this manual. All
>> values not assigned by Arm are reserved and must not be used.". I assume the
switch to
> execute-only mode. The same execute-only mode is enabled when a java thread
> executes in java or native states. This approach of managing W^X mode turned
> out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-82549
switch to
> execute-only mode. The same execute-only mode is enabled when a java thread
> executes in java or native states. This approach of managing W^X mode turned
> out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-82549
switch to
> execute-only mode. The same execute-only mode is enabled when a java thread
> executes in java or native states. This approach of managing W^X mode turned
> out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-82549
switch to
> execute-only mode. The same execute-only mode is enabled when a java thread
> executes in java or native states. This approach of managing W^X mode turned
> out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
On Tue, 2 Feb 2021 22:42:22 GMT, Daniel D. Daugherty wrote:
>> Anton Kozlov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> support macos_aarch64 in hsdis
>
> src/hotspot/share/logging/logStream.hpp line
On Mon, 15 Feb 2021 16:21:53 GMT, Bernhard Urban-Forster
wrote:
>> This is the version of w^x on-demand switch implemented by microsoft guys.
>> This is enabled only for debug builds.
>> @lewurm could you comment here please
>
> Those values can be observed in the debugger, but aren't
switch to
> execute-only mode. The same execute-only mode is enabled when a java thread
> executes in java or native states. This approach of managing W^X mode turned
> out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
On Tue, 2 Feb 2021 21:51:56 GMT, Daniel D. Daugherty wrote:
>> Anton Kozlov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> support macos_aarch64 in hsdis
>
> src/hotspot/cpu/aarch64/macroAssembler
switch to
> execute-only mode. The same execute-only mode is enabled when a java thread
> executes in java or native states. This approach of managing W^X mode turned
> out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-82549
switch to
> execute-only mode. The same execute-only mode is enabled when a java thread
> executes in java or native states. This approach of managing W^X mode turned
> out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-82549
On Wed, 3 Feb 2021 20:08:41 GMT, Anton Kozlov wrote:
> I'm going to do as much refactoring as needed before this patch under
> JDK-8261071
The recent merge resolves inconsitency between pass_byte/pass_short and other
methods.
-
PR: https://git.openjdk.java.net/jdk/pull/2200
On Sun, 31 Jan 2021 20:08:01 GMT, Vladimir Kempik wrote:
>> I'm not sure it can wait. This change turns already-messy code into
>> something significantly messier, to the extent that it's not really good
>> enough to go into mainline.
>
> Hello
> Does this look like something in the right
switch to
> execute-only mode. The same execute-only mode is enabled when a java thread
> executes in java or native states. This approach of managing W^X mode turned
> out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
switch to
> execute-only mode. The same execute-only mode is enabled when a java thread
> executes in java or native states. This approach of managing W^X mode turned
> out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
On Wed, 3 Feb 2021 09:11:50 GMT, Andrew Haley wrote:
>> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 323:
>>
>>> 321: str(zr, Address(rthread, JavaThread::last_Java_pc_offset()));
>>> 322:
>>> 323: str(zr, Address(rthread,
>>> JavaFrameAnchor::saved_fp_address_offset()));
>>
switch to
> execute-only mode. The same execute-only mode is enabled when a java thread
> executes in java or native states. This approach of managing W^X mode turned
> out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-82549
On Tue, 2 Feb 2021 18:35:51 GMT, Gerard Ziemski wrote:
>> Anton Kozlov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> support macos_aarch64 in hsdis
>
> src/hotspot/cpu/aarch64/vm_version_aarch64.hpp line
On Wed, 3 Feb 2021 23:29:30 GMT, Gerard Ziemski wrote:
>> using ` ```c `
>> https://docs.github.com/en/github/writing-on-github/creating-and-highlighting-code-blocks
>>
>> I was wrong about `SIGFPE` / `EXC_MASK_ARITHMETIC`, it's used on i386,
>> x86_64:
>>
switch to
> execute-only mode. The same execute-only mode is enabled when a java thread
> executes in java or native states. This approach of managing W^X mode turned
> out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-82549
On Mon, 25 Jan 2021 22:48:50 GMT, Chris Plummer wrote:
>> Anton Kozlov has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Refactor CDS disabling
>> - Redo builsys support for aarch64-darwin
>
>
switch to
> execute-only mode. The same execute-only mode is enabled when a java thread
> executes in java or native states. This approach of managing W^X mode turned
> out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-82549
On Fri, 5 Feb 2021 09:57:54 GMT, Magnus Ihse Bursie wrote:
>> Anton Kozlov has updated the pull request incrementally with six additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos
>> -
On Wed, 3 Feb 2021 20:08:28 GMT, Mikael Vidstedt wrote:
> Out of curiosity, have you looked at the performance of the W^X state
> transition?
Earlier it was possible to disable W^X protection (unfortunately, I don't know
a way to do this now). We compared Renaissance results with W^X
On Tue, 2 Feb 2021 22:56:55 GMT, Daniel D. Daugherty wrote:
>> Anton Kozlov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> support macos_aarch64 in hsdis
>
> src/hotspot/share/runtime/stubRouti
On Wed, 3 Feb 2021 09:14:24 GMT, Andrew Haley wrote:
>> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5271:
>>
>>> 5269: //
>>> 5270: void MacroAssembler::get_thread(Register dst) {
>>> 5271: RegSet saved_regs = RegSet::range(r0, r1) +
>>> BSD_ONLY(RegSet::range(r2, r17)) + lr -
On Wed, 3 Feb 2021 19:57:24 GMT, Anton Kozlov wrote:
>> For platform files that were copied from other ports to this port, if the
>> file wasn't
>> changed I presume the copyright years are left alone. If the file required
>> changes
>> for this port, I expect
On Tue, 2 Feb 2021 23:03:45 GMT, Daniel D. Daugherty wrote:
>> Anton Kozlov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> support macos_aarch64 in hsdis
>
> src/hotspot/share/runtime/thread.cpp line 3991
On Tue, 2 Feb 2021 18:00:06 GMT, Gerard Ziemski wrote:
>> Anton Kozlov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> support macos_aarch64 in hsdis
>
> src/hotspot/cpu/aarch64/interpreterRT_a
On Tue, 26 Jan 2021 12:01:30 GMT, Coleen Phillimore wrote:
>> I assume a WXVerifier class that tracks W^X mode in debug mode and does
>> nothing in release mode. I've considered to do this, it's relates to small
>> inefficiencies, while this patch brings zero overhead (in release) for a
>>
On Tue, 26 Jan 2021 12:50:22 GMT, Anton Kozlov wrote:
>> Yes, that's why I thought it should be added to the classes
>> ThreadInVMfromNative, etc like:
>> class ThreadInVMfromNative : public ThreadStateTransition {
>> ResetNoHandleMark __rnhm;
>>
>>
switch to
> execute-only mode. The same execute-only mode is enabled when a java thread
> executes in java or native states. This approach of managing W^X mode turned
> out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-82549
On Tue, 2 Feb 2021 23:10:17 GMT, Daniel D. Daugherty wrote:
>> Anton Kozlov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> support macos_aarch64 in hsdis
>
> For platform files that were copied
switch to
> execute-only mode. The same execute-only mode is enabled when a java thread
> executes in java or native states. This approach of managing W^X mode turned
> out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-82549
switch to
> execute-only mode. The same execute-only mode is enabled when a java thread
> executes in java or native states. This approach of managing W^X mode turned
> out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
switch to
> execute-only mode. The same execute-only mode is enabled when a java thread
> executes in java or native states. This approach of managing W^X mode turned
> out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-82549
switch to
> execute-only mode. The same execute-only mode is enabled when a java thread
> executes in java or native states. This approach of managing W^X mode turned
> out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-82549
On Tue, 26 Jan 2021 16:35:54 GMT, Bernhard Urban-Forster
wrote:
>> @lewurm This and other harfbuzz changes came from MS, could you please
>> comment here ?
>
> This looks like a merge fix mistake:
>
switch to
> execute-only mode. The same execute-only mode is enabled when a java thread
> executes in java or native states. This approach of managing W^X mode turned
> out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-82549
switch to
> execute-only mode. The same execute-only mode is enabled when a java thread
> executes in java or native states. This approach of managing W^X mode turned
> out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-82549
1 - 100 of 111 matches
Mail list logo
