Could you please look at the updated version at [0]?
The new API for ReferenceQueue still targets the problem of
synchronizing Reference handling with CRaC. An example of that is a
java object that becomes unreachable just before the checkpoint, and an
associated Reference needs to be processed
On 2/2/22 17:48, Alan Bateman wrote:> At a high level it should be okay to
provide a JDK-internal way to await quiescent. You've added it as a public API
which might be okay for the current exploration but I don't think it would be
exposed in its current form. Once the method returns then
, each j.l.ref.Cleaner queue
is drained, only then the VM is called to prepare the image. More Reference
handling threads will be changed like Cleaner's ones. I'm looking for possible
problems or general comments about this approach.
Thanks,
Anton
On 1/31/22 14:51, Anton Kozlov wrote:
At the time
On Tue, 13 Apr 2021 06:55:33 GMT, Mikael Vidstedt wrote:
> Let's problem list java/util/concurrent/locks/Lock/TimedAcquireLeak.java (a
> tier1 test) until JDK-8262897 is fixed.
Marked as reviewed by akozlov (no project role).
-
PR: https://git.openjdk.java.net/jdk/pull/3452
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
>
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 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);
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
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 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;
>>
>>
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, 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, 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 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: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-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
On Mon, 25 Jan 2021 10:00:20 GMT, Andrew Haley wrote:
>> I like the suggestion. For the defense, new functions were made this way
>> intentionally, to match existing `pass_int`, `pass_long`,.. I take your
>> comment as a blessing to fix all of them. But I feel that refactoring of
>> existing
On Mon, 25 Jan 2021 14:40:42 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/runtime/thread.hpp line 915:
>>
>>> 913: verify_wx_state(WXExec);
>>> 914: }
>>> 915: };
>>
>> Rather than add all this to thread.hpp, can you make a wxVerifier.hpp and
>> just add the class instance
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 09:52:00 GMT, Andrew Haley wrote:
>> Hello
>> Why is it not nice ?
>> linux_aarch64 uses some linux specific tls function
>> _ZN10JavaThread25aarch64_get_thread_helperEv from
>> hotspot/os_cpu/linux_aarch64/threadLS_linux_aarch64.s
>> which clobbers only r0 and r1
>>
On Mon, 25 Jan 2021 14:36:35 GMT, Coleen Phillimore wrote:
>> Anton Kozlov has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Address feedback for signature generators
>> - Enable -Wformat-nonliteral
On Sat, 23 Jan 2021 11:42:48 GMT, Andrew Haley wrote:
>> Anton Kozlov has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Address feedback for signature generators
>> - Enable -Wformat-nonliteral ba
On Sat, 23 Jan 2021 11:10:17 GMT, Andrew Haley wrote:
>> Anton Kozlov has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Address feedback for signature generators
>> - Enable -Wformat-nonliteral ba
On Fri, 22 Jan 2021 20:18:51 GMT, Erik Joelsson wrote:
>> Anton Kozlov has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Address feedback for signature generators
>> - Enable -Wformat-nonliteral back
>
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
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/aarch64: support of the new calling convention (subtasks
JDK-8253817, JDK-8253818)
*
On Wed, 2 Dec 2020 17:34:00 GMT, Anton Kozlov wrote:
> Please review a small change that replaces use of objc_msgSend_stret in macOS
> platform code with pure ObjC code. It's also a prerequisite for macOS/AArch64
> support, where objc_msgSend_stret is not available.
This pull reques
On Wed, 2 Dec 2020 19:27:25 GMT, Phil Race wrote:
>> Please review a small change that replaces use of objc_msgSend_stret in
>> macOS platform code with pure ObjC code. It's also a prerequisite for
>> macOS/AArch64 support, where objc_msgSend_stret is not available.
>
> Surely these days you
On Thu, 3 Dec 2020 06:50:11 GMT, Anton Kozlov wrote:
>> Filed https://bugs.openjdk.java.net/browse/JDK-8257633
>
> Thanks for taking care of those issues. To be clear, there is no real need to
> bump the version for this PR, 10.9 is fine. This PR just proposes another way
On Wed, 2 Dec 2020 22:04:17 GMT, Erik Joelsson wrote:
>> We are indeed missing the macos-version-min argument when linking
>> libjvm.dylib. This is a bug.
>
> Filed https://bugs.openjdk.java.net/browse/JDK-8257633
Thanks for taking care of those issues. To be clear, there is no real need to
On Wed, 2 Dec 2020 20:19:54 GMT, Phil Race wrote:
>> Unfortunately, no. AFAIK, the minimum target version is 10.9
>> https://github.com/openjdk/jdk/blob/master/make/autoconf/flags.m4#L133, so I
>> had to keep indirection.
>
> I wonder if we should be "upping" that to something later.
> 10.9 is
On Wed, 2 Dec 2020 19:27:25 GMT, Phil Race wrote:
>> Please review a small change that replaces use of objc_msgSend_stret in
>> macOS platform code with pure ObjC code. It's also a prerequisite for
>> macOS/AArch64 support, where objc_msgSend_stret is not available.
>
> Surely these days you
Please review a small change that replaces use of objc_msgSend_stret in macOS
platform code with pure ObjC code. It's also a prerequisite for macOS/AArch64
support, where objc_msgSend_stret is not available.
-
Commit messages:
- Do not use objc_msgSend_stret to get macOS version
On 11.10.2019 00:28, Mandy Chung wrote:
> Since the method throws Exception, this try-catch block is not needed.
>
> The start year of the copyright in the new test files should be 2019.
Thanks! I preserved Amazon's copyright year as 2018, as I derived the file from
JDK-8194653 initially
Hi Mandy,
On 10.10.2019 08:00, Mandy Chung wrote:
> 2014 static synchronized void initLibraryPaths() {
> This does not need synchronized since it's still during phase 1 before other
> thread can execute java code.
Thanks! I missed this
> LoadLibraryTest.java
> - please add @bug 8231584
> -
Hi Mandy,
thanks for the review!
Updated webrev with fixes:
http://cr.openjdk.java.net/~akozlov/8231584/webrev.03/
Few notes below:
On 08.10.2019 01:20, Mandy Chung wrote:
> I think another way doing it is to initialize ClassLoader.sys_paths and
> usr_paths fields at System::initPhase1. These
Hi Mandy,
On 02.10.2019 01:08, Anton Kozlov wrote:>
> > On 30.09.2019 21:18, Mandy Chung wrote:
>> Skimming through the implementation, it seems to me that the
>> Runtime::loadLibrary0 does not need to be synchronized.
>> ClassLoader::loadLibrary0 should ensure that
On 30.09.2019 21:18, Mandy Chung wrote:
> Skimming through the implementation, it seems to me that the
> Runtime::loadLibrary0 does not need to be synchronized.
> ClassLoader::loadLibrary0 should ensure that a native library of a given name
> is loaded and registered only once.
Hi,
I think that JDK-8194653 [0] affects jdk/jdk and it doesn't specific to
FileSystems.getDefault.
I'm starting a new thread/bug as the original issue marked as resolved ([3])
Ryan, thanks for investigation and providing a test [1]!
But the test fails in the same way if the
98 matches
Mail list logo
