Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]

2021-03-23 Thread Vladimir Kempik 
On Tue, 23 Mar 2021 13:58:03 GMT, Andrew Haley  wrote:

> > [ 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.
> 
> To the extent that 11u has fixed policies :) we definitely have a policy of 
> accepting patches to keep 11u working on current hardware. So yes.

@lewurm That sounds like a green flag for you and jep-388 (with its 
R18_RESERVED functionality) ;)

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]

2021-03-23 Thread Vladimir Kempik 
On Tue, 23 Mar 2021 13:26:19 GMT, Anton Kozlov  wrote:

>> Build changes still look good. Hope you can get this done now! :)
>
>> > No, no, no! I am not suggesting you change anything else, just that
>> > you do not define contentless macros. You might as well define it
>> > to be something, and true is a reasonable default, that's all. It's
>> > not terribly important, it's just good practice.
>> 
>> I'm quite prepared to drop this if it's holding up the port. It's a style 
>> thing, but it's not critical.
> 
> Sorry, I missed your reply.
> 
> R18_RESERVED is also defined in 
> https://github.com/openjdk/jdk/blob/master/make/hotspot/gensrc/GensrcAdlc.gmk#L96.
>  I think changing the value here and there would be slightly out of the scope 
> of this PR, so I would prefer to avoid the suggested change. 
> 
> The biggest argument from my side is that the current macro value is 
> consistent with the rest of the macros in this file. For example 
> https://github.com/openjdk/jdk/blob/8c1ab38ee20ed61fefbb64b6a9ee605c52d2cb4e/src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp#L35
> and 
> https://github.com/openjdk/jdk/blob/b7b391b2ac4208eabdee4e93acd5b0e364953f94/src/hotspot/share/runtime/mutexLocker.cpp#L137
> 
> But 
> https://github.com/openjdk/jdk/blob/8c1ab38ee20ed61fefbb64b6a9ee605c52d2cb4e/src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp#L59
> and   
> https://github.com/openjdk/jdk/blob/b23228d152ff8fa27bd32d9ef1307bf315039dea/src/hotspot/share/runtime/arguments.cpp#L1540

Hello
That depends on the will of openjdk11 maintainers to accept this (and few 
other, like jep-388, as we depend on it) contribution.

> 23 марта 2021 г., в 16:39, drej1 ***@***.***> написал(а):
> 
> 
> So, where are we up to now? Are we done yet?
> 
> Hello
> we would like to get approval for the final version we have now and then 
> integrate this pr as soon as Mark will target it to jdk17
> 
> Hi there, will this be also supported backwards? To support java11 LTS 
> version?
> 
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub 
> , or 
> unsubscribe 
> .
>

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v24]

2021-03-23 Thread Vladimir Kempik 
On Tue, 23 Mar 2021 09:54:16 GMT, Andrew Haley  wrote:

> So, where are we up to now? Are we done yet?

Hello
we would like to get approval for the final version we have now and then 
integrate this pr as soon as Mark will target it to jdk17

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]

2021-03-12 Thread Vladimir Kempik 
On Tue, 2 Mar 2021 08:12:10 GMT, Anton Kozlov  wrote:

>> I wasn't able to replicate JDK-8020753 and JDK-8186286. So will remove these 
>> workaround
>> @gerard-ziemski, 8020753 was originally your fix, do you know if it still 
>> needed on intel-mac ?
>
> The x86_bsd still carries the workaround 
> https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp#L745.
>  It's worth having macos ports to be aligned by features. I would propose to 
> have this workaround for now, and decide on it later for macos/x86 and 
> macos/aarch64 at once. Sorry for chiming in so late.

Hello Anton.
Please keep JDK-8020753 away from this port, as JDK-8020753 was very 
intel-specific workaround and macos11.0 on aarch64 doesn't show any signs of 
original bug.

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]

2021-03-04 Thread Vladimir Kempik 
On Thu, 4 Mar 2021 17:36:22 GMT, Alan Hayward 
 wrote:

> I was building this PR on a new machine, and I now get the following error:
> 
> > /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:258:31:
> >  error: cast to smaller integer type 'MIDIClientRef' (aka 'unsigned int') 
> > from 'void *' [-Werror,-Wvoid-pointer-to-int-cast]
> > static MIDIClientRef client = (MIDIClientRef) NULL;
> > ^~~~
> > /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:259:29:
> >  error: cast to smaller integer type 'MIDIPortRef' (aka 'unsigned int') 
> > from 'void *' [-Werror,-Wvoid-pointer-to-int-cast]
> > static MIDIPortRef inPort = (MIDIPortRef) NULL;
> > ^~
> > /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:260:30:
> >  error: cast to smaller integer type 'MIDIPortRef' (aka 'unsigned int') 
> > from 'void *' [-Werror,-Wvoid-pointer-to-int-cast]
> > static MIDIPortRef outPort = (MIDIPortRef) NULL;
> > ^~
> > /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:466:32:
> >  error: cast to smaller integer type 'MIDIEndpointRef' (aka 'unsigned int') 
> > from 'void *' [-Werror,-Wvoid-pointer-to-int-cast]
> > MIDIEndpointRef endpoint = (MIDIEndpointRef) NULL;
> > ^~
> > 4 errors generated.
> 
> As far as I can tell the only difference between the two systems is the xcode 
> version:
> 
> New system (failing)
> % xcodebuild -version
> Xcode 12.5
> Build version 12E5244e
> 
> Old system (working)
> % xcodebuild -version
> Xcode 12.4
> Build version 12D4e
> 
> Looks like the newer version of Xcode is being a little stricter with casting?
> Replacing the NULL with 0 seems to fix the issue.

Hello
there is one issue with the info you provided, it's from Xcode12.5 beta.
And beta license agreement forbids sharing output of beta version of compiler
So we can't say we have issue with newer xcode beta until that beta went public 
& released.
Fixing issues you found now will mean someone have violated xcode beta license 
agreement and made these issues public.

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]

2021-02-26 Thread Vladimir Kempik 
On Tue, 2 Feb 2021 23:07:08 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/java.base/macosx/native/libjli/java_md_macosx.m line 210:
> 
>> 208: if (preferredJVM == NULL) {
>> 209: #if defined(__i386__)
>> 210: preferredJVM = "client";
> 
> #if defined(__i386__)
> preferredJVM = "client";
> Not your bug, but Oracle/OpenJDK never supported 32-bit __i386__ on macOS.

Hello
I thought the openjdk7 supported 32-bit macos at some point in time

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10]

2021-02-16 Thread Vladimir Kempik 
On Thu, 4 Feb 2021 22:49:23 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
>>  - Add comments to WX transitions
>>
>>+ minor change of placements
>>  - Use macro conditionals instead of empty functions
>>  - Add W^X to tests
>>  - Do not require known W^X state
>>  - Revert w^x in gtests
>
> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 297:
> 
>> 295:   stub = SharedRuntime::handle_unsafe_access(thread, next_pc);
>> 296: }
>> 297:   } else if (sig == SIGILL && nativeInstruction_at(pc)->is_stop()) {
> 
> Can we add a comment here describing what this case means?

This was added as part of this commit ( to linux_aarch64) - 
https://github.com/openjdk/jdk/commit/339d52600b285eb3bc57d9ff107567d4424efeb1

@gerard-ziemski  do we really want to add anything new here ?

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v8]

2021-02-15 Thread Vladimir Kempik 
On Mon, 15 Feb 2021 19:07:40 GMT, Andrew Haley  wrote:

>> Hello, we have updated PR, now this bailout is used only by the code which 
>> can handle it (native wrapper generator), for the rest it will cause 
>> guarantee failed if this bailout is triggered
>
> This is when passing a float, yes? In the case where we have more float 
> arguments than n_float_register_parameters_c.
> I don't understand why you think it's acceptable to bail in this case. Can 
> you explain, please?

it's for everything that uses less than 8 bytes on a stack( ints ( 4), 
shorts(2), bytes(1), floats(4)).
currently native wrapper generation does not support such cases at all, it 
needs refactoring before this can be implemented.
So when a method has more argument than can be placed in registers, we may have 
issues. 

So we just bailing out to interpreter in case when a smaller (<=4 b) type is 
going to be passed thru the stack.

There was attempt to implement handling such cases but currently it requires 
some hacks (like using some vectors for non-specific task) - 
https://github.com/openjdk/aarch64-port/pull/3

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v8]

2021-02-15 Thread Vladimir Kempik 
On Mon, 1 Feb 2021 18:44:48 GMT, Andrew Haley  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 62 commits:
>> 
>>  - Merge branch 'master' into jdk-macos
>>  - Update copyright year for BsdAARCH64ThreadContext.java
>>  - Fix inclusing of StubRoutines header
>>  - Redo buildsys fix
>>  - Revert harfbuzz changes, disable warnings for it
>>  - Little adjustement of SlowSignatureHandler
>>  - Partially bring previous commit
>>  - Revert "Address feedback for signature generators"
>>
>>This reverts commit 50b55f6684cd21f8b532fa979b7b6fbb4613266d.
>>  - Refactor CDS disabling
>>  - Redo builsys support for aarch64-darwin
>>  - ... and 52 more: 
>> https://git.openjdk.java.net/jdk/compare/8a9004da...b421e0b4
>
> src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 839:
> 
>> 837:   // The code unable to handle this, bailout.
>> 838:   return -1;
>> 839: #endif
> 
> This looks like a bug to me. The caller doesn't necessarily check the return 
> value. See CallRuntimeNode::calling_convention.

Hello, we have updated PR, now this bailout is used only by the code which can 
handle it (native wrapper generator), for the rest it will cause guarantee 
failed if this bailout is triggered

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]

2021-02-15 Thread Vladimir Kempik 
On Tue, 2 Feb 2021 21:52:47 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/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.
> 
> Perhaps:  // The code is unable to handle this so bailout.

Hello, we have updated PR, now this bailout is used only by the code which can 
handle it (native wrapper generator), for the rest it will cause guarantee 
failed if this bailout is triggered

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10]

2021-02-12 Thread Vladimir Kempik 
On Thu, 4 Feb 2021 22:49:23 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
>>  - Add comments to WX transitions
>>
>>+ minor change of placements
>>  - Use macro conditionals instead of empty functions
>>  - Add W^X to tests
>>  - Do not require known W^X state
>>  - Revert w^x in gtests
>
> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 297:
> 
>> 295:   stub = SharedRuntime::handle_unsafe_access(thread, next_pc);
>> 296: }
>> 297:   } else if (sig == SIGILL && nativeInstruction_at(pc)->is_stop()) {
> 
> Can we add a comment here describing what this case means?

this arm64 specific part came as is from linux_aarch64 and I can't add any 
meaning comments here.

> 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 char *)*detail_msg_ptr;
> 
> Where is `detail_msg` used?

Came from linux_arm64. was used in os_linux_aarch64.cpp on line 246 in 
report_and_die
But became unused on bsd_arm64. I agree this needs to be removed

> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 403:
> 
>> 401:   }
>> 402: 
>> 403:   return false; // Mute compiler
> 
> Is this comment needed?

this part came as is from linux_aarch64 as well and was supposed to mean 
something there.

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]

2021-02-12 Thread Vladimir Kempik 
On Tue, 2 Feb 2021 22:08:14 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/os_bsd_aarch64.cpp line 221:
> 
>> 219: assert(sig == info->si_signo, "bad siginfo");
>> 220:   }
>> 221: */
> 
> Should this code be deleted? From here and from where it was copied
> from if it is also commented out there...

Thanks, will fix in bsd_aarch64 soon, as for bsd_x86 I've filled new bug and pr 
- https://github.com/openjdk/jdk/pull/2547

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]

2021-02-12 Thread Vladimir Kempik 
On Tue, 2 Feb 2021 22:14:42 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/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?

I wasn't able to replicate JDK-8020753 and JDK-8186286. So will remove these 
workaround
Gerard, 8020753 was originally your fix, do you know if it still needed on 
intel-mac ?

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]

2021-02-12 Thread Vladimir Kempik 
On Tue, 2 Feb 2021 22:12:07 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/os_bsd_aarch64.cpp line 435:
> 
>> 433: //||\  Java thread created by VM does not 
>> have glibc
>> 434: //|glibc guard page| - guard, attached Java thread usually 
>> has
>> 435: //||/  1 glibc guard page.
> 
> Is this code going to be built by GCC (with glibc) or will only
> macOS compilers and libraries be used?

only macos comiplers

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]

2021-02-12 Thread Vladimir Kempik 
On Thu, 4 Feb 2021 22:54:42 GMT, Gerard Ziemski  wrote:

>> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 363:
>> 
>>> 361: address pc = os::Posix::ucontext_get_pc(uc);
>>> 362: 
>>> 363: if (pc != addr && uc->context_esr == 0x924F) { //TODO: figure 
>>> out what this value means
>> 
>> Is this TODO going to be resolved by this port?
>
> Where did this come from - some snippet/example/tech note code? Maybe other 
> people can help figure it out if we provide more info.

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

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]

2021-02-12 Thread Vladimir Kempik 
On Tue, 2 Feb 2021 22:07:15 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/os_bsd_aarch64.cpp line 195:
> 
>> 193: frame os::get_sender_for_C_frame(frame* fr) {
>> 194:   return frame(fr->link(), fr->link(), fr->sender_pc());
>> 195: }
> 
> Is this file going to be built by GCC or just macOS compilers?

there is no support for compiling java with gcc on macos since about jdk11, 
only clang.
considering this and the absence of gcc for macos_m1, the answer is - just 
macOS compilers.

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10]

2021-02-12 Thread Vladimir Kempik 
On Thu, 4 Feb 2021 21:59:02 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
>>  - Add comments to WX transitions
>>
>>+ minor change of placements
>>  - Use macro conditionals instead of empty functions
>>  - Add W^X to tests
>>  - Do not require known W^X state
>>  - Revert w^x in gtests
>
> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 194:
> 
>> 192: // may get turned off by -fomit-frame-pointer.
>> 193: frame os::get_sender_for_C_frame(frame* fr) {
>> 194:   return frame(fr->link(), fr->link(), fr->sender_pc());
> 
> Why is it
> 
> return frame(fr->link(), fr->link(), fr->sender_pc());
> 
> and not 
> 
> return frame(fr->sender_sp(), fr->link(), fr->sender_pc());
> 
> like in the bsd-x86 counter part?

bsd_aarcb64 was based on linux_aarch64, with addition of bsd-specific things 
from bsd_x86
You think  the bsd-x86 is better here ?

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]

2021-02-04 Thread Vladimir Kempik 
On Thu, 4 Feb 2021 15:13:49 GMT, Anton Kozlov  wrote:

>> Out of curiosity, have you looked at the performance of the W^X state 
>> transition? In particular I'm wondering if the cost is effectively 
>> negligible so doing it unconditionally on JVM entry is a no-brainer and just 
>> easier/cleaner than the alternatives, or if there are reasons to look at 
>> only doing the transition if/when needed (perhaps do it lazily and revert 
>> back to X when leaving the JVM?).
>
>> 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 
> transitions like the proposed one vs. no transitions with the protection 
> disabled once. Results were identical for a small and large number of 
> iterations.
> 
> From the other hand, I've used 
> https://github.com/AntonKozlov/macos-aarch64-transition-bench to estimate the 
> cost of the transition.
> I re-did measurements with the current implementation and on consumer 
> hardware:
> 
> testJNIthrpt   25   277997000.151 ±   4095685.956  ops/s
> testJniNanoTimethrpt   2517851098.010 ±119489.599  ops/s
> testNanoTime   thrpt   2578007491.762 ±628455.971  ops/s
> testNothingthrpt   25  1724298829.088 ± 100537565.068  ops/s
> testTwoStateAndWX  thrpt   2521958839.057 ±210490.755  ops/s
> testWX thrpt   2523299813.266 ±149837.302  ops/s
> 
> There is an overhead, but it does not look like blocking the first 
> implementation. I'm not refusing future optimizations like enabling W only 
> when necessary. But for now, I don't have a robust and maintainable solution 
> for this, sorry.

> _Mailing list message from [erik.joelsson at 
> oracle.com](mailto:erik.joels...@oracle.com) on 
> [2d-dev](mailto:2d-...@openjdk.java.net):_
> 
> On 2021-01-26 04:44, Magnus Ihse Bursie wrote:
> 
> > On 2021-01-26 13:09, Vladimir Kempik wrote:
> > > On Tue, 26 Jan 2021 12:02:02 GMT, Alan Hayward
> > >  wrote:
> > > > AIUI, the configure line needs passing a prebuilt
> > > > JavaNativeFoundation framework
> > > > ie:
> > > > `--with-extra-ldflags='-F
> > > > /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/'`
> > > > Otherwise there will be missing _JNFNative* functions.
> > > > Is this the long term plan? Or will eventually the required code be
> > > > moved into JDK and/or the xcode one automatically get picked up by
> > > > the configure scripts?
> > > > There is ongoing work by P. Race to eliminate dependence on JNF at all
> > > > How far has that work come? Otherwise the logic should be added to
> > > > configure to look for this framework automatically, and provide a way
> > > > to override it/set it if not found.
> > 
> > 
> > I don't think it's OK to publish a new port that cannot build
> > out-of-the-box without hacks like this.
> 
> My understanding is that Apple chose to not provide JNF for aarch64, so
> if you want to build OpenJDK, you first need to build JNF yourself (it's
> available in github). Phil is working on removing this dependency
> completely, which will solve this issue [1].
> 
> In the meantime, I don't think we should rely on finding JNF in
> unsupported locations inside Xcode. Could we wait with integrating this
> port until it can be built without such hacks? If not, then adding
> something in the documentation on how to get a working JNF would at
> least be needed.
> 
> /Erik
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8257852

This doesn't seem to be an issue anymore, After P.Race have finished with 
JDK-8257852, Macarm port can be build without extra ld flags. J2Demo works fine 
as example.
This can be checked if one merges pull/2200 branch into his local copy of 
master branch.

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]

2021-02-04 Thread Vladimir Kempik 
On Thu, 4 Feb 2021 14:27:53 GMT, Andrew Haley  wrote:

> > > You read my mind, Andrew. Unless, of course, it's optimized to leverage 
> > > the fact that it's thread-specific..
> > 
> > 
> > it's thread-specific
> > https://developer.apple.com/documentation/apple_silicon/porting_just-in-time_compilers_to_apple_silicon
> > > Because pthread_jit_write_protect_np changes only the current thread’s 
> > > permissions, avoid accessing the same memory region from multiple 
> > > threads. Giving multiple threads access to the same memory region opens 
> > > up a potential attack vector, in which one thread has write access and 
> > > another has executable access to the same region.
> 
> Umm, so how does patching work? We don't even know if other threads are 
> executing the code we need to patch.

I thought java can handle that scenario in usual (non W^X systems) just fine, 
so we just believe jvm did everything right and it's safe to rewrite some code 
at specific moment.

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]

2021-02-04 Thread Vladimir Kempik 
On Thu, 4 Feb 2021 08:26:35 GMT, Mikael Vidstedt  wrote:

> You read my mind, Andrew. Unless, of course, it's optimized to leverage the 
> fact that it's thread-specific..

it's thread-specific

https://developer.apple.com/documentation/apple_silicon/porting_just-in-time_compilers_to_apple_silicon

>Because pthread_jit_write_protect_np changes only the current thread’s 
>permissions, avoid accessing the same memory region from multiple threads. 
>Giving multiple threads access to the same memory region opens up a potential 
>attack vector, in which one thread has write access and another has executable 
>access to the same region.

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6]

2021-02-02 Thread Vladimir Kempik 
On Tue, 2 Feb 2021 11:14:12 GMT, Vladimir Kempik  wrote:

> > > > Hello, hsdis is a separate out-of-tree project and is not part of this 
> > > > jep.
> > > 
> > > 
> > > Unless there's something I'm missing it only requires a few lines of 
> > > change to src/utils/hsdis/makefile (it already has support for macos 
> > > x86_64)
> > 
> > 
> > I agree with Alan that it makes sense to add this trivial change as part of 
> > this PR, if it allows the current hsdis solution to continue working on 
> > mac/aarch64.
> > > > support for looking for proper hsdis dylib library was added as part of 
> > > > this jep.
> > > 
> > > 
> > > I'm a little confused. Are you planning on adding a new disassembler?
> > 
> > 
> > @a74nh I think Vladimir is referring to #392. The hsdis "component" has 
> > been left behind for a long time, and there are several requests to add new 
> > backends, which require a modernized build of hsdis. This is undfortunately 
> > not a high-priority project, and has been postponed several times already. 
> > :(
> 
> Sorry I was under impression hsdis is not part of openjdk tree.
> 
> Alan, could you please share with us the version of binutils you were using 
> in your test ?
> 
> Regards, Vladimir

I have updated PR with patch for hsdis, one thing to notice, LP64 is not 
defined for arm64 in Makefile

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6]

2021-02-02 Thread Vladimir Kempik 
On Mon, 1 Feb 2021 14:06:32 GMT, Magnus Ihse Bursie  wrote:

>>> Hello, hsdis is a separate out-of-tree project and is not part of this jep.
>> 
>> Unless there's something I'm missing it only requires a few lines of change 
>> to src/utils/hsdis/makefile (it already has support for macos x86_64)
>> 
>>>support for looking for proper hsdis dylib library was added as part of this 
>>>jep.
>> 
>> I'm a little confused. Are you planning on adding a new disassembler?
>
>> > Hello, hsdis is a separate out-of-tree project and is not part of this jep.
>> 
>> Unless there's something I'm missing it only requires a few lines of change 
>> to src/utils/hsdis/makefile (it already has support for macos x86_64)
> 
> I agree with Alan that it makes sense to add this trivial change as part of 
> this PR, if it allows the current hsdis solution to continue working on 
> mac/aarch64.
> 
>> 
>> > support for looking for proper hsdis dylib library was added as part of 
>> > this jep.
>> 
>> I'm a little confused. Are you planning on adding a new disassembler?
> 
> @a74nh I think Vladimir is referring to 
> https://github.com/openjdk/jdk/pull/392. The hsdis "component" has been left 
> behind for a long time, and there are several requests to add new backends, 
> which require a modernized build of hsdis. This is undfortunately not a 
> high-priority project, and has been postponed several times already. :(

> > > Hello, hsdis is a separate out-of-tree project and is not part of this 
> > > jep.
> > 
> > 
> > Unless there's something I'm missing it only requires a few lines of change 
> > to src/utils/hsdis/makefile (it already has support for macos x86_64)
> 
> I agree with Alan that it makes sense to add this trivial change as part of 
> this PR, if it allows the current hsdis solution to continue working on 
> mac/aarch64.
> 
> > > support for looking for proper hsdis dylib library was added as part of 
> > > this jep.
> > 
> > 
> > I'm a little confused. Are you planning on adding a new disassembler?
> 
> @a74nh I think Vladimir is referring to #392. The hsdis "component" has been 
> left behind for a long time, and there are several requests to add new 
> backends, which require a modernized build of hsdis. This is undfortunately 
> not a high-priority project, and has been postponed several times already. :(

Sorry I was under impression hsdis is not part of openjdk tree.

Alan, could you please share with us the version of binutils you were using in 
your test ?

Regards, Vladimir

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6]

2021-02-01 Thread Vladimir Kempik 
On Mon, 1 Feb 2021 09:31:31 GMT, Alan Hayward 
 wrote:

> You need add macos arm64 to hsdis. Having it working is fairly essential for 
> debugging.
> 
> Inside src/utils/hsdis, After cloning binutils
> 
> ```
> make; make demo; ./build/macosx-arm64/hsdis-demo
> ```
> 
> Results in:
> 
> ```
> Hello, world!
> ...And now for something completely different:
> 
> Decoding from 0x1046e31a4 to 0x1046e3664...with decode_instructions_virtual
> hsdis: bad native mach=architecture not set in Makefile!; please port hsdis 
> to this platform
> hsdis output options:
> ```
> 
> I fixed it by changing the makefile to force the build flags:
> 
> ```
> ARCH=aarch64
> CFLAGS/aarch64+= -m64
> ```
> 
> Resulting in:
> 
> ```
> Hello, world!
> ...And now for something completely different:
> 
> Decoding from 0x10012719c to 0x10012765c...with decode_instructions_virtual
> Decoding for CPU 'aarch64'
> main:
>  0x10012719c  sub sp, sp, #0x60
>  0x1001271a0  stp x29, x30, [sp, #80]
> ...etc
> ```
> 
> Putting the library in the right place then made disassembly in java work for 
> me.

Hello, hsdis is a separate out-of-tree project and is not part of this jep.
support for looking for proper hsdis dylib library was added as part of this 
jep.

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v8]

2021-01-31 Thread Vladimir Kempik 
On Mon, 25 Jan 2021 09:48:46 GMT, Andrew Haley  wrote:

>> Would you like me to do something about it now? The problem is that the 
>> functions of SlowSignatureHandler are subtly different, so it will be 
>> multiple tables, not sure how many. Such change is another candidate for a 
>> separate code enhancement, which I would like not to mix into the JEP 
>> implementation (it's already not a small change :)). But if you think it 
>> would be a good thing, please let me know. In another case, I'll add this to 
>> a queue of follow-up enhancements.
>
> 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 direction ? 

https://github.com/VladimirKempik/jdk/commit/c2820734f4b10148154085a70d380b8c5775fa49

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6]

2021-01-27 Thread Vladimir Kempik 
On Wed, 27 Jan 2021 08:36:19 GMT, Magnus Ihse Bursie  wrote:

> Build changes per se now looks okay. However, I agree with Erik that unless 
> this PR can wait for the JNF removal, at the very least the build docs needs 
> to be updated to explain how to successfully build for this platform. (I can 
> live with the configure command line hack, since it's temporary -- otherwise 
> I'd have requested a new configure argument.) This can be done in this PR or 
> a follow-up PR.

I believe it's better be done under separate PR/bugfix, so it can be completely 
reverted once JNF removed.

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3]

2021-01-26 Thread Vladimir Kempik 
On Tue, 26 Jan 2021 09:23:18 GMT, Magnus Ihse Bursie  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
>
> make/autoconf/build-aux/autoconf-config.guess line 1275:
> 
>> 1273:  UNAME_PROCESSOR="aarch64"
>> 1274:  fi
>> 1275:fi ;;
> 
> Almost, but not quite, correct. We cannot change the autoconf-config.guess 
> file due to license restrictions (the license allows redistribution, not 
> modifications). Instead we have the config.guess file which "wraps" 
> autoconf-config.guess and makes pre-/post-call modifications to work around 
> limitations in the autoconf original file. So you need to check there if you 
> are getting incorrect results back and adjust it in that case. See the 
> already existing clauses in that file.

Hello
I have updated PR and moved this logic to make/autoconf/build-aux/config.guess
It's pretty similar to i386 -> x86_64 fix-up on macos_intel

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v5]

2021-01-26 Thread Vladimir Kempik 
On Tue, 26 Jan 2021 19:33:28 GMT, Weijun Wang  wrote:

>> Anton Kozlov has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Revert harfbuzz changes, disable warnings for it
>
> src/java.security.jgss/share/native/libj2gss/gssapi.h line 48:
> 
>> 46: // Condition was copied from
>> 47: // 
>> Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/gssapi/gssapi.h
>> 48: #if TARGET_OS_MAC && (defined(__ppc__) || defined(__ppc64__) || 
>> defined(__i386__) || defined(__x86_64__))
> 
> So for macOS/AArch64, this `if` is no longer true?

That is according to Xcode sdk.

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]

2021-01-26 Thread Vladimir Kempik 
On Mon, 25 Jan 2021 17:43:22 GMT, Phil Race  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
>
> src/java.desktop/share/native/libharfbuzz/hb-common.h line 113:
> 
>> 111: 
>> 112: #define HB_TAG(c1,c2,c3,c4) 
>> ((hb_tag_t)uint32_t)(c1)&0xFF)<<24)|(((uint32_t)(c2)&0xFF)<<16)|(((uint32_t)(c3)&0xFF)<<8)|((uint32_t)(c4)&0xFF)))
>> 113: #define HB_UNTAG(tag)   (char)(((tag)>>24)&0xFF), 
>> (char)(((tag)>>16)&0xFF), (char)(((tag)>>8)&0xFF), (char)((tag)&0xFF)
> 
> I need a robust explanation of these changes.
> They are not mentioned, nor are they in upstream harfbuzz.
> Likely these should be pushed to upstream first if there is a reason for them.

@lewurm This and other harfbuzz changes came from MS, could you please comment 
here ?

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3]

2021-01-26 Thread Vladimir Kempik 
On Tue, 26 Jan 2021 12:02:02 GMT, Alan Hayward 
 wrote:

> AIUI, the configure line needs passing a prebuilt JavaNativeFoundation 
> framework
> ie:
> `--with-extra-ldflags='-F 
> /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/'`
> 
> Otherwise there will be missing _JNFNative* functions.
> 
> Is this the long term plan? Or will eventually the required code be moved 
> into JDK and/or the xcode one automatically get picked up by the configure 
> scripts?

There is ongoing work by P. Race to eliminate dependence on JNF at all

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3]

2021-01-25 Thread Vladimir Kempik 
On Mon, 25 Jan 2021 23:35:52 GMT, Phil Race  wrote:

>> That may actually be a valid concern. Both say macOS 10.12+ ...  which might 
>> conflict with the 10.9 target.
>
> Maybe you should just file a bug after all for this to be dealt with 
> separately.
> Certainly if it is NOT fixed now such a bug needs to be filed.

I have created https://bugs.openjdk.java.net/browse/JDK-8260402 which is 
blocked by jep-391 currently

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3]

2021-01-25 Thread Vladimir Kempik 
On Mon, 25 Jan 2021 22:42:40 GMT, Phil Race  wrote:

>> Min_macos version is changed to 11.0 for macos_aarch64
>> 
>> https://github.com/openjdk/jdk/pull/2200/files/0c2cb0a372bf1a8607810d773b53d6959616a816#diff-7cd97cdbeb3053597e5d6659016cdf0f60b2c412bd39934a43817ee0b717b7a7R136
>
> 1) I meant change to NSWindowStyleMaskBorderless from NSBorderlessWindowMask
> 2) So maybe rather than the deprecation suppression  you could change both 
> constants to the new ones.
> Ordinarily I'd say let someone else do that but this looks like a simple 
> obvious change and is dwarfed by all the other changes going on for Mac ARM 
> ...

that sounds good to me, I am just afraid to break intel mac on older macos 
versions with this change.

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3]

2021-01-25 Thread Vladimir Kempik 
On Mon, 25 Jan 2021 22:22:06 GMT, Phil Race  wrote:

>> It seems these workarounds are still needed:
>> 
>> jdk/src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m:300:39:
>>  error: 'NSAlphaFirstBitmapFormat' is deprecated: first deprecated in macOS 
>> 10.14 [-Werror,-Wdeprecated-declarations]
>> bitmapFormat: NSAlphaFirstBitmapFormat | 
>> NSAlphaNonpremultipliedBitmapFormat
>>   ^~~~
>>   NSBitmapFormatAlphaFirst
>> 
>> jdk/src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m:438:34:
>>  error: 'NSBorderlessWindowMask' is deprecated: first deprecated in macOS 
>> 10.12 [-Werror,-Wdeprecated-declarations]
>>   styleMask: NSBorderlessWindowMask
>>  ^~
>>  NSWindowStyleMaskBorderless
>
> Are you doing something somewhere to change the target version of macOS or 
> SDK ? I had no such problem.
> I think we currently target a macOS 10.9 and if you are changing that it 
> would need discussion.
> If you are changing it only for Mac ARM that may make more sense .. 
> 
> And these appear to be just API churn by Apple
> NSAlphaFirstBitmapFormat is replaced by NSBitmapFormatAlphaFirst
> 
> https://developer.apple.com/documentation/appkit/nsbitmapformat/nsbitmapformatalphafirst?language=objc
> 
> NSBorderlessWindowMask is replaced by NSWindowStyleMask
> 
> https://developer.apple.com/documentation/appkit/nswindowstylemask?language=occ

Min_macos version is changed to 11.0 for macos_aarch64

https://github.com/openjdk/jdk/pull/2200/files/0c2cb0a372bf1a8607810d773b53d6959616a816#diff-7cd97cdbeb3053597e5d6659016cdf0f60b2c412bd39934a43817ee0b717b7a7R136

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3]

2021-01-25 Thread Vladimir Kempik 
On Mon, 25 Jan 2021 20:54:38 GMT, Vladimir Kempik  wrote:

>> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 573:
>> 
>>> 571: EXTRA_HEADER_DIRS := $(LIBFONTMANAGER_EXTRA_HEADER_DIRS), \
>>> 572: WARNINGS_AS_ERRORS_xlc := false, \
>>> 573: DISABLED_WARNINGS_clang := deprecated-declarations, \
>> 
>> I see this added here and in another location. What is deprecated ? You 
>> really need to explain these sorts of things.
>> I've built JDK using Xcode 12.3 and not had any need for this.
>
> Hello
> I believe it was a workaround for issues with xcode 12.2 in early beta days.
> Those issues were fixed later in upstream jdk, so most likely we need to 
> remove these workarounds.

It seems these workarounds are still needed:

jdk/src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m:300:39: 
error: 'NSAlphaFirstBitmapFormat' is deprecated: first deprecated in macOS 
10.14 [-Werror,-Wdeprecated-declarations]
bitmapFormat: NSAlphaFirstBitmapFormat | 
NSAlphaNonpremultipliedBitmapFormat
  ^~~~
  NSBitmapFormatAlphaFirst

jdk/src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m:438:34: 
error: 'NSBorderlessWindowMask' is deprecated: first deprecated in macOS 10.12 
[-Werror,-Wdeprecated-declarations]
  styleMask: NSBorderlessWindowMask
 ^~
 NSWindowStyleMaskBorderless

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3]

2021-01-25 Thread Vladimir Kempik 
On Mon, 25 Jan 2021 19:42:41 GMT, Phil Race  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
>
> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 573:
> 
>> 571: EXTRA_HEADER_DIRS := $(LIBFONTMANAGER_EXTRA_HEADER_DIRS), \
>> 572: WARNINGS_AS_ERRORS_xlc := false, \
>> 573: DISABLED_WARNINGS_clang := deprecated-declarations, \
> 
> I see this added here and in another location. What is deprecated ? You 
> really need to explain these sorts of things.
> I've built JDK using Xcode 12.3 and not had any need for this.

Hello
I believe it was a workaround for issues with xcode 12.2 in early beta days.
Those issues were fixed later in upstream jdk, so most likely we need to remove 
these workarounds.

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]

2021-01-25 Thread Vladimir Kempik 
On Mon, 25 Jan 2021 14:03:40 GMT, Per Liden  wrote:

> In `make/autoconf/jvm-features.m4` I notice that you haven't enabled ZGC for 
> macos/aarch64. Is that just an oversight, or is there a reason for that?

because it does not work
processor_id has no "official docs"-friendly implementation, only a hacky one 
from ios world.

Also ZGC needs additional W^X work.
I believe zgc supports needs to be done in a separate commit.

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]

2021-01-25 Thread Vladimir Kempik 
On Mon, 25 Jan 2021 13:18:34 GMT, Magnus Ihse Bursie  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
>
> make/common/NativeCompilation.gmk line 1180:
> 
>> 1178: # silently fail otherwise.
>> 1179: ifneq ($(CODESIGN), )
>> 1180:  $(CODESIGN) -f -s "$(MACOSX_CODESIGN_IDENTITY)" 
>> --timestamp --options runtime \
> 
> What does -f do, and is it needed for macos-x64 as well?

-f  - replace signature if it's present, if not  - just sign as usual
macos-aarch64 binaries always have adhoc signature, so need to replace it.

> make/modules/jdk.hotspot.agent/Lib.gmk line 34:
> 
>> 32: 
>> 33: else ifeq ($(call isTargetOs, macosx), true)
>> 34:   SA_CFLAGS := -D_GNU_SOURCE -mno-omit-leaf-frame-pointer \
> 
> Is this really proper for macos-x64? I thought we used -Damd64 as a marker 
> for all macos-x64 C/C++ files. (Most files get their flags from the common 
> setup in configure, but SA is a different beast due to historical reasons).

@luhenry , could you please check this comment, I think SA-agent was MS's job 
here.

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]

2021-01-24 Thread Vladimir Kempik 
On Sat, 23 Jan 2021 11:43:31 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 back
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5272:
> 
>> 5270: void MacroAssembler::get_thread(Register dst) {
>> 5271:   RegSet saved_regs = RegSet::range(r0, r1) + 
>> BSD_ONLY(RegSet::range(r2, r17)) + lr - dst;
>> 5272:   push(saved_regs, sp);
> 
> This isn't very nice.

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
macos_aarch64 has no such tls code and uses generic C-call to Thread::current();
Hence we  are saving possibly clobbered regs here.

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Integrated: 8253899: Make IsClassUnloadingEnabled signature match specification

2020-10-12 Thread Vladimir Kempik 
On Thu, 1 Oct 2020 15:02:01 GMT, Vladimir Kempik  wrote:

> Please review this change for hotspot and one test.
> There is few JVMTI callback/event functions in jdk which signature doesn't 
> match specification.
> for example:
> static jvmtiError JNICALL IsClassUnloadingEnabled(const jvmtiEnv* env, 
> jboolean* enabled, ...)
> but according to jvmti specs it should be:
> static jvmtiError JNICALL IsClassUnloadingEnabled(const jvmtiEnv* env, ...)
> same with ClassUnload(jvmtiEnv* jvmti_env, JNIEnv* jni_env, const char* name, 
> ...)  in tests
> for many years that didn't matter but with coming JEP-391 it becomes 
> important to make it match the spec
> https://developer.apple.com/documentation/apple_silicon/addressing_architectural_differences_in_your_macos_code
> This commit makes the above mentioned functions to have signature matching 
> jvmti specification

This pull request has now been integrated.

Changeset: c7f00640
Author:Vladimir Kempik 
URL:   https://git.openjdk.java.net/jdk/commit/c7f00640
Stats: 20 lines in 3 files changed: 17 ins; 0 del; 3 mod

8253899: Make IsClassUnloadingEnabled signature match specification

Reviewed-by: sspitsyn, dholmes

-

PR: https://git.openjdk.java.net/jdk/pull/466

Re: RFR: 8253899: Make IsClassUnloadingEnabled signature match specification [v2]

2020-10-12 Thread Vladimir Kempik 
On Mon, 5 Oct 2020 12:44:34 GMT, Vladimir Kempik  wrote:

>>> _Mailing list message from [David Holmes](mailto:david.hol...@oracle.com) on
>>> [hotspot-dev](mailto:hotspot-...@openjdk.java.net):_
>>> Hi Vladimir,
>>> 
>>> On 2/10/2020 5:37 pm, Vladimir Kempik wrote:
>>> 
>>> > On Fri, 2 Oct 2020 07:27:17 GMT, David Holmes  
>>> > wrote:
>>> > > Okay but look at the example that documentation gives:
>>> > > > For example, if the jvmtiParamInfo returned by GetExtensionEvents 
>>> > > > indicates that there is a jint parameter, the event
>>> > > > handler should be declared: ```
>>> > > > void JNICALL myHandler(jvmtiEnv* jvmti_env, jint myInt, ...)
>>> > > > ```
>>> > > 
>>> > > 
>>> > > The myInt is explicit, just as our "jboolean* enabled" is explicit. I 
>>> > > think they key point is that the signature must
>>> > > end with "..." which it does.
>>> > > I don't see anything here that needs to be fixed.
>>> > 
>>> > 
>>> > Hello David. On majority of platforms this would be fine.
>>> > But on some platforms, variadic arguments and non variadic arguments are 
>>> > passed differently ( for example on
>>> > macos-aarch64, variadic args are passed always on stack, non variadic on 
>>> > registers (and on stack for 9th+ arg) , that
>>> > causes issues.
>>> 
>>> Okay - I see the potential for a problme here but ...
>>> 
>>> > If you still see no issues here we can delay and make this changeset part 
>>> > of JEP-391.
>>> > But since this changeset isn't much macos-aarch64 specific, I thought it 
>>> > would be good to integrate it separately from
>>> > jep-391.
>>> 
>>> ... this change actually goes against the example in the spec, so if you
>>> make this change it indicates the spec needs to be updated too.
>>> 
>>> Cheers,
>>> David
>>> -
>> 
>> Hello David
>> 
>> I really believe the problem is in document here ( in examples)
>> first, the doc clearly specify the type
>> 
>> typedef jvmtiError (JNICALL *jvmtiExtensionFunction)
>> (jvmtiEnv* jvmti_env,
>>   ...);
>> 
>> then in examples it declares the function not matching this spec.
>> 
>> Is it a good idea to update the docs in a separate bug ?
>> 
>> Thanks, Vladimir
>
> Hello David
> I have created CSR draft
> https://bugs.openjdk.java.net/browse/JDK-8254014
> 
> Regards, Vladimir

Hello
I have updated the PR with changes from spec of CSR

Regards, Vladimir

-

PR: https://git.openjdk.java.net/jdk/pull/466

Re: RFR: 8253899: Make IsClassUnloadingEnabled signature match specification [v2]

2020-10-12 Thread Vladimir Kempik 
> Please review this change for hotspot and one test.
> There is few JVMTI callback/event functions in jdk which signature doesn't 
> match specification.
> for example:
> static jvmtiError JNICALL IsClassUnloadingEnabled(const jvmtiEnv* env, 
> jboolean* enabled, ...)
> but according to jvmti specs it should be:
> static jvmtiError JNICALL IsClassUnloadingEnabled(const jvmtiEnv* env, ...)
> same with ClassUnload(jvmtiEnv* jvmti_env, JNIEnv* jni_env, const char* name, 
> ...)  in tests
> for many years that didn't matter but with coming JEP-391 it becomes 
> important to make it match the spec
> https://developer.apple.com/documentation/apple_silicon/addressing_architectural_differences_in_your_macos_code
> This commit makes the above mentioned functions to have signature matching 
> jvmti specification

Vladimir Kempik has updated the pull request incrementally with one additional 
commit since the last revision:

  Add impl of CSR JDK-8254014

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/466/files
  - new: https://git.openjdk.java.net/jdk/pull/466/files/1ef832d2..cd7c4d53

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=466=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=466=00-01

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/466.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/466/head:pull/466

PR: https://git.openjdk.java.net/jdk/pull/466

Re: RFR: 8253899: Make IsClassUnloadingEnabled signature match specification

2020-10-05 Thread Vladimir Kempik 
On Fri, 2 Oct 2020 15:26:30 GMT, Vladimir Kempik  wrote:

>>> Okay but look at the example that documentation gives:
>>> 
>>> > For example, if the jvmtiParamInfo returned by GetExtensionEvents 
>>> > indicates that there is a jint parameter, the event
>>> > handler should be declared: ```
>>> > void JNICALL myHandler(jvmtiEnv* jvmti_env, jint myInt, ...)
>>> > ```
>>> 
>>> The myInt is explicit, just as our "jboolean* enabled" is explicit. I think 
>>> they key point is that the signature must
>>> end with "..." which it does.
>>> I don't see anything here that needs to be fixed.
>> 
>> Hello David. On majority of platforms this would be fine.
>> 
>> But on some platforms, variadic arguments and non variadic arguments are 
>> passed differently ( for example on
>> macos-aarch64, variadic args are passed always on stack, non variadic on 
>> registers (and on stack for 9th+ arg) , that
>> causes issues.  If you still see no issues here we can delay and make this 
>> changeset part of JEP-391.
>> But since this changeset isn't much macos-aarch64 specific, I thought it 
>> would be good to integrate it separately from
>> jep-391.
>> Regards, Vladimir
>
>> _Mailing list message from [David Holmes](mailto:david.hol...@oracle.com) on
>> [hotspot-dev](mailto:hotspot-...@openjdk.java.net):_
>> Hi Vladimir,
>> 
>> On 2/10/2020 5:37 pm, Vladimir Kempik wrote:
>> 
>> > On Fri, 2 Oct 2020 07:27:17 GMT, David Holmes  
>> > wrote:
>> > > Okay but look at the example that documentation gives:
>> > > > For example, if the jvmtiParamInfo returned by GetExtensionEvents 
>> > > > indicates that there is a jint parameter, the event
>> > > > handler should be declared: ```
>> > > > void JNICALL myHandler(jvmtiEnv* jvmti_env, jint myInt, ...)
>> > > > ```
>> > > 
>> > > 
>> > > The myInt is explicit, just as our "jboolean* enabled" is explicit. I 
>> > > think they key point is that the signature must
>> > > end with "..." which it does.
>> > > I don't see anything here that needs to be fixed.
>> > 
>> > 
>> > Hello David. On majority of platforms this would be fine.
>> > But on some platforms, variadic arguments and non variadic arguments are 
>> > passed differently ( for example on
>> > macos-aarch64, variadic args are passed always on stack, non variadic on 
>> > registers (and on stack for 9th+ arg) , that
>> > causes issues.
>> 
>> Okay - I see the potential for a problme here but ...
>> 
>> > If you still see no issues here we can delay and make this changeset part 
>> > of JEP-391.
>> > But since this changeset isn't much macos-aarch64 specific, I thought it 
>> > would be good to integrate it separately from
>> > jep-391.
>> 
>> ... this change actually goes against the example in the spec, so if you
>> make this change it indicates the spec needs to be updated too.
>> 
>> Cheers,
>> David
>> -
> 
> Hello David
> 
> I really believe the problem is in document here ( in examples)
> first, the doc clearly specify the type
> 
> typedef jvmtiError (JNICALL *jvmtiExtensionFunction)
> (jvmtiEnv* jvmti_env,
>   ...);
> 
> then in examples it declares the function not matching this spec.
> 
> Is it a good idea to update the docs in a separate bug ?
> 
> Thanks, Vladimir

Hello David
I have created CSR draft
https://bugs.openjdk.java.net/browse/JDK-8254014

Regards, Vladimir

-

PR: https://git.openjdk.java.net/jdk/pull/466

Re: RFR: 8253899: Make IsClassUnloadingEnabled signature match specification

2020-10-02 Thread Vladimir Kempik 
On Fri, 2 Oct 2020 07:34:45 GMT, Vladimir Kempik  wrote:

>> Okay but look at the example that documentation gives:
>> 
>>> For example, if the jvmtiParamInfo returned by GetExtensionEvents indicates 
>>> that there is a jint parameter, the event
>>> handler should be declared:
>>> void JNICALL myHandler(jvmtiEnv* jvmti_env, jint myInt, ...)
>> 
>> The myInt is explicit, just as our "jboolean* enabled" is explicit. I think 
>> they key point is that the signature must
>> end with "..." which it does.
>> I don't see anything here that needs to be fixed.
>
>> Okay but look at the example that documentation gives:
>> 
>> > For example, if the jvmtiParamInfo returned by GetExtensionEvents 
>> > indicates that there is a jint parameter, the event
>> > handler should be declared: ```
>> > void JNICALL myHandler(jvmtiEnv* jvmti_env, jint myInt, ...)
>> > ```
>> 
>> The myInt is explicit, just as our "jboolean* enabled" is explicit. I think 
>> they key point is that the signature must
>> end with "..." which it does.
>> I don't see anything here that needs to be fixed.
> 
> Hello David. On majority of platforms this would be fine.
> 
> But on some platforms, variadic arguments and non variadic arguments are 
> passed differently ( for example on
> macos-aarch64, variadic args are passed always on stack, non variadic on 
> registers (and on stack for 9th+ arg) , that
> causes issues.  If you still see no issues here we can delay and make this 
> changeset part of JEP-391.
> But since this changeset isn't much macos-aarch64 specific, I thought it 
> would be good to integrate it separately from
> jep-391.
> Regards, Vladimir

> _Mailing list message from [David Holmes](mailto:david.hol...@oracle.com) on
> [hotspot-dev](mailto:hotspot-...@openjdk.java.net):_
> Hi Vladimir,
> 
> On 2/10/2020 5:37 pm, Vladimir Kempik wrote:
> 
> > On Fri, 2 Oct 2020 07:27:17 GMT, David Holmes  
> > wrote:
> > > Okay but look at the example that documentation gives:
> > > > For example, if the jvmtiParamInfo returned by GetExtensionEvents 
> > > > indicates that there is a jint parameter, the event
> > > > handler should be declared: ```
> > > > void JNICALL myHandler(jvmtiEnv* jvmti_env, jint myInt, ...)
> > > > ```
> > > 
> > > 
> > > The myInt is explicit, just as our "jboolean* enabled" is explicit. I 
> > > think they key point is that the signature must
> > > end with "..." which it does.
> > > I don't see anything here that needs to be fixed.
> > 
> > 
> > Hello David. On majority of platforms this would be fine.
> > But on some platforms, variadic arguments and non variadic arguments are 
> > passed differently ( for example on
> > macos-aarch64, variadic args are passed always on stack, non variadic on 
> > registers (and on stack for 9th+ arg) , that
> > causes issues.
> 
> Okay - I see the potential for a problme here but ...
> 
> > If you still see no issues here we can delay and make this changeset part 
> > of JEP-391.
> > But since this changeset isn't much macos-aarch64 specific, I thought it 
> > would be good to integrate it separately from
> > jep-391.
> 
> ... this change actually goes against the example in the spec, so if you
> make this change it indicates the spec needs to be updated too.
> 
> Cheers,
> David
> -

Hello David

I really believe the problem is in document here ( in examples)
first, the doc clearly specify the type

typedef jvmtiError (JNICALL *jvmtiExtensionFunction)
(jvmtiEnv* jvmti_env,
  ...);

then in examples it declares the function not matching this spec.

Is it a good idea to update the docs in a separate bug ?

Thanks, Vladimir

-

PR: https://git.openjdk.java.net/jdk/pull/466

Re: RFR: 8253899: Make IsClassUnloadingEnabled signature match specification

2020-10-02 Thread Vladimir Kempik 
On Fri, 2 Oct 2020 07:27:17 GMT, David Holmes  wrote:

> Okay but look at the example that documentation gives:
> 
> > For example, if the jvmtiParamInfo returned by GetExtensionEvents indicates 
> > that there is a jint parameter, the event
> > handler should be declared: ```
> > void JNICALL myHandler(jvmtiEnv* jvmti_env, jint myInt, ...)
> > ```
> 
> The myInt is explicit, just as our "jboolean* enabled" is explicit. I think 
> they key point is that the signature must
> end with "..." which it does.
> I don't see anything here that needs to be fixed.

Hello David. On majority of platforms this would be fine.

But on some platforms, variadic arguments and non variadic arguments are passed 
differently ( for example on
macos-aarch64, variadic args are passed always on stack, non variadic on 
registers (and on stack for 9th+ arg) , that
causes issues.

If you still see no issues here we can delay and make this changeset part of 
JEP-391.
But since this changeset isn't much macos-aarch64 specific, I thought it would 
be good to integrate it separately from
jep-391.

Regards, Vladimir

-

PR: https://git.openjdk.java.net/jdk/pull/466

Re: RFR: 8253899: Make IsClassUnloadingEnabled signature match specification

2020-10-02 Thread Vladimir Kempik 
On Fri, 2 Oct 2020 05:10:20 GMT, Serguei Spitsyn  wrote:

>> Please review this change for hotspot and one test.
>> There is few JVMTI callback/event functions in jdk which signature doesn't 
>> match specification.
>> for example:
>> static jvmtiError JNICALL IsClassUnloadingEnabled(const jvmtiEnv* env, 
>> jboolean* enabled, ...)
>> but according to jvmti specs it should be:
>> static jvmtiError JNICALL IsClassUnloadingEnabled(const jvmtiEnv* env, ...)
>> same with ClassUnload(jvmtiEnv* jvmti_env, JNIEnv* jni_env, const char* 
>> name, ...)  in tests
>> for many years that didn't matter but with coming JEP-391 it becomes 
>> important to make it match the spec
>> https://developer.apple.com/documentation/apple_silicon/addressing_architectural_differences_in_your_macos_code
>> This commit makes the above mentioned functions to have signature matching 
>> jvmti specification
>
> Vladimir, it looks good to me.

> David,
> I think, Vladimir is referring to the JVMTI extension mechanism spec:
> https://docs.oracle.com/en/java/javase/15/docs/specs/jvmti.html#jvmtiExtensionFunction
> https://docs.oracle.com/en/java/javase/15/docs/specs/jvmti.html#jvmtiExtensionEvent

Hello Serguei, you are right, I was talking about this documents.
Thank you.

-

PR: https://git.openjdk.java.net/jdk/pull/466

RFR: 8253899: Make IsClassUnloadingEnabled signature match specification

2020-10-01 Thread Vladimir Kempik 
Please review this change for hotspot and one test.
There is few JVMTI callback/event functions in jdk which signature doesn't 
match specification.
for example:
static jvmtiError JNICALL IsClassUnloadingEnabled(const jvmtiEnv* env, 
jboolean* enabled, ...)
but according to jvmti specs it should be:
static jvmtiError JNICALL IsClassUnloadingEnabled(const jvmtiEnv* env, ...)
same with ClassUnload(jvmtiEnv* jvmti_env, JNIEnv* jni_env, const char* name, 
...)  in tests
for many years that didn't matter but with coming JEP-391 it becomes important 
to make it match the spec
https://developer.apple.com/documentation/apple_silicon/addressing_architectural_differences_in_your_macos_code
This commit makes the above mentioned functions to have signature matching 
jvmti specification

-

Commit messages:
 - 8253899: Make IsClassUnloadingEnabled signature match specification + jcheck
 - 8253899: Make IsClassUnloadingEnabled signature match specification

Changes: https://git.openjdk.java.net/jdk/pull/466/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=466=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253899
  Stats: 17 lines in 2 files changed: 15 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/466.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/466/head:pull/466

PR: https://git.openjdk.java.net/jdk/pull/466

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v10]

2020-09-28 Thread Vladimir Kempik 
On Mon, 28 Sep 2020 19:38:15 GMT, Bernhard Urban-Forster  
wrote:

>> this looks better I think, if it's done right from beginning, we won't have 
>> to modify it later.
>> The Question is, can we do it ahead of JEP-391 ?
>> If we can't then maybe better to leave it this way for now:
>> WIN64_ONLY("rtls") NOT_WIN64("r18")
>> 
>> as r18 is supposed to be reserved register on aarch64, linux is just an 
>> exception where it's allowed.
>
> Let us go with the following in this PR as that's the extend of this PR:
> Suggestion:
> 
> "r17", LINUX_ONLY("r18") WIN64_ONLY("rtls"), "r19",
> We can update it accordingly in a PR for JEP-391.

Ok, Great.

-

PR: https://git.openjdk.java.net/jdk/pull/212

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v10]

2020-09-28 Thread Vladimir Kempik 
On Mon, 28 Sep 2020 19:09:17 GMT, Bernhard Urban-Forster  
wrote:

>> src/hotspot/cpu/aarch64/register_aarch64.cpp line 44:
>> 
>>> 42: "rscratch1", "rscratch2",
>>> 43: "r10", "r11", "r12", "r13", "r14", "r15", "r16",
>>> 44: "r17", NOT_R18_RESERVED("r18") WIN64_ONLY("rtls"), "r19",
>> 
>> For me this line doesn't look good in case of expanding this functionality 
>> to macos-aarch64
>> as it's just the name of register and it's r18 on every platform except 
>> WIN64 and has nothing to do with reserving r18.
>
> The idea is that the naming should suggest that `r18` shouldn't be used on 
> that particular platform. Same is true for
> macOS, but the ABI docs suggest a different usage, hence we have something 
> like that in our internal branch for macOS:
> Suggestion:
> "r17", NOT_R18_RESERVED("r18") WIN64_ONLY("rtls") 
> MACOS_ONLY("rplatform"), "r19",
> Are you suggesting it should rather be something like this eventually?
> Suggestion:
> 
> "r17", LINUX_ONLY("r18") WIN64_ONLY("rtls") MACOS_ONLY("rplatform"), 
> "r19",

this looks better I think, if it's done right from beginning, we won't have to 
modify it later.
The Question is, can we do it ahead of JEP-391 ?
If we can't then maybe better to leave it this way for now:
WIN64_ONLY("rtls") NOT_WIN64("r18")

as r18 is supposed to be reserved register on aarch64, linux is just an 
exception where it's allowed.

-

PR: https://git.openjdk.java.net/jdk/pull/212

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v10]

2020-09-28 Thread Vladimir Kempik 
On Mon, 28 Sep 2020 14:07:16 GMT, Monica Beckwith  wrote:

>> This is a continuation of 
>> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
>>  
>> Changes since then:
>> * We've improved the write barrier as suggested by Andrew [1]
>> * The define-guards around R18 have been changed to `R18_RESERVED`. This 
>> will be enabled for Windows only for now but
>>   will be required for the upcoming macOS+Aarch64 [2] port as well.
>> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov 
>> in our PR for now and built the
>>   Windows-specific CPU feature detection on top of it.
>> 
>> [1] 
>> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html
>> [2] https://openjdk.java.net/jeps/8251280
>
> Monica Beckwith has updated the pull request with a new target base due to a 
> merge or a rebase. The pull request now
> contains 24 commits:
>  - Merge remote-tracking branch 'upstream/master' into jdk-windows
>  - SA: update copyright
>  - Fix graal codestyle
>  - Reduce includes
>  - Merge remote-tracking branch 'upstream/master' into jdk-windows
>  - os_windows: remove duplicated UMA handling
>  - test_safefetch{32,N} works fine on win+aarch64
>  - cleanup for 8253539: Remove unused JavaThread functions for 
> set_last_Java_fp/pc
>  - cleanup for 8253457: Remove unimplemented register stack functions
>  - Merge remote-tracking branch 'upstream/master' into jdk-windows
>  - ... and 14 more: 
> https://git.openjdk.java.net/jdk/compare/ec9bee68...a7cdaad6

src/hotspot/cpu/aarch64/register_aarch64.cpp line 44:

> 42: "rscratch1", "rscratch2",
> 43: "r10", "r11", "r12", "r13", "r14", "r15", "r16",
> 44: "r17", NOT_R18_RESERVED("r18") WIN64_ONLY("rtls"), "r19",

For me this line doesn't look good in case of expanding this functionality to 
macos-aarch64
as it's just the name of register and it's r18 on every platform except WIN64 
and has nothing to do with reserving r18.

-

PR: https://git.openjdk.java.net/jdk/pull/212

[8u] request for approval: backport of JDK-8048353

2015-07-23 Thread Vladimir Kempik 

Hi All,

I would like to backport fix for JDK-8048353 to 8u

Bug id: https://bugs.openjdk.java.net/browse/JDK-8048353

Changeset: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/5133956b4a98

Fix applies cleanly to jdk8

Review thread for original fix: 
http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-July/015408.html


 testing: jprt

Thanks,
Vladimir

Re: RFR: 8048353: jstack -l crashes VM when a Java mirror for a primitive type is locked

2015-07-20 Thread Vladimir Kempik 

hello

Can I have one more review for this please?

jstack/tmtools tested passed fine.

Thanks, Vladimir.

On 15.07.2015 17:31, Vladimir Kempik wrote:

Hello

Thanks for looking into this.

Where can I find jstack/tmtools tests to run them ?

Thanks, Vladimir.

On 14.07.2015 19:21, Daniel D. Daugherty wrote:

 Webrev: http://cr.openjdk.java.net/~vkempik/8048353/webrev.00/

src/share/vm/classfile/javaClasses.cpp
No comments. (Thanks for including the null case.)

src/share/vm/classfile/javaClasses.hpp
No comments.

src/share/vm/runtime/vframe.cpp
No comments.

Thumbs up (modulo running the proper tests).

Dan


On 7/14/15 9:56 AM, Daniel D. Daugherty wrote:

Adding serviceability-dev@... since jstack belongs to the
Serviceability team...

The jstack and/or tmtools tests should also be run...

Dan


On 7/14/15 9:51 AM, Vladimir Kempik wrote:

Hello,

Please review the patch to fix 8048353.
Customer has an issue with this bug when running jstack on jdk7.
He tested FVB and cofirmed it has fixed the issue.
Before pushing jdk7 backport I need to get the fix to 9 and 8.

Webrev: http://cr.openjdk.java.net/~vkempik/8048353/webrev.00/
JBS bug: https://bugs.openjdk.java.net/browse/JDK-8048353

testing: JPRT.

Thanks, Vladimir.

Re: RFR: 8048353: jstack -l crashes VM when a Java mirror for a primitive type is locked

2015-07-15 Thread Vladimir Kempik 

Hello

Thanks for looking into this.

Where can I find jstack/tmtools tests to run them ?

Thanks, Vladimir.

On 14.07.2015 19:21, Daniel D. Daugherty wrote:

 Webrev: http://cr.openjdk.java.net/~vkempik/8048353/webrev.00/

src/share/vm/classfile/javaClasses.cpp
No comments. (Thanks for including the null case.)

src/share/vm/classfile/javaClasses.hpp
No comments.

src/share/vm/runtime/vframe.cpp
No comments.

Thumbs up (modulo running the proper tests).

Dan


On 7/14/15 9:56 AM, Daniel D. Daugherty wrote:

Adding serviceability-dev@... since jstack belongs to the
Serviceability team...

The jstack and/or tmtools tests should also be run...

Dan


On 7/14/15 9:51 AM, Vladimir Kempik wrote:

Hello,

Please review the patch to fix 8048353.
Customer has an issue with this bug when running jstack on jdk7.
He tested FVB and cofirmed it has fixed the issue.
Before pushing jdk7 backport I need to get the fix to 9 and 8.

Webrev: http://cr.openjdk.java.net/~vkempik/8048353/webrev.00/
JBS bug: https://bugs.openjdk.java.net/browse/JDK-8048353

testing: JPRT.

Thanks, Vladimir.

RFR: 8024677: [TESTBUG] Move tests for classes in /testlibrary

2014-04-17 Thread Vladimir Kempik 

Hello

Please review this patch.
We've recently backported changes to testlibrary from jdk8 to jdk7 and 
now I want to bring TL tests to jdk7 as well. jdk7u-dev/jdk already has 
these tests, it's only hotspot that missing them.
Its partially backport of 8024677, but I don't remove old files and 
don't edit TEST.groups as these files don't exist in jdk7/hotspot.
I want to push these changes as backport of 8024677 to jdk7/hotspot, but 
since I've removed part of original patch (as mentioned before) I think 
I need to get a review.


Original fix: 
http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/5b1191bf0b4b

Webrev: http://cr.openjdk.java.net/~vkempik/8024677/webrev.00/

Thanks. Vladimir.

Re: RFR: 8039368 Remove testcase from npt utf.c

2014-04-09 Thread Vladimir Kempik 

Hello

Thanks for comments.

Updated webrev: http://cr.openjdk.java.net/~vkempik/8039368/webrev.01/

Vladimir.
On 09.04.2014 16:32, Dmitry Samersoff wrote:

Vladimir,

Please change define to

#ifdef COMPILE_WITH_UTF_TEST

-Dmitry


On 2014-04-09 16:28, Staffan Larsen wrote:

Sure.

On 9 apr 2014, at 14:24, Dmitry Samersoff dmitry.samers...@oracle.com
mailto:dmitry.samers...@oracle.com wrote:


Staffan,

On 2014-04-09 16:20, Staffan Larsen wrote:

I would prefer to keep the test where it is but change the “#if 1” to
“#if 0” on line 399.

Are you OK with

#ifdef COMPILE_WITH_UTF_TEST

-Dmitry


Thanks,
/Staffan

On 9 apr 2014, at 14:03, Dmitry Samersoff
dmitry.samers...@oracle.com mailto:dmitry.samers...@oracle.com wrote:


Staffan,

We can move it to separate file and put to test directory (with no
intention to run it automatically).

Other options is just change define to keep the test code but don't
compile it to production libnpt.

-Dmitry


On 2014-04-09 11:12, Staffan Larsen wrote:

It’s been a very useful little test when changing the code in
utf.c. Not sure why it has to be removed.

/Staffan

On 8 apr 2014, at 17:30, Vladimir Kempik
vladimir.kem...@oracle.com mailto:vladimir.kem...@oracle.com wrote:


Hello

Please review this changeset:

File jdk/src/share/npt/utf.c contains a testcase that shouldn't be
in production library.

bug: https://bugs.openjdk.java.net/browse/JDK-8039368
webrev: http://cr.openjdk.java.net/~vkempik/8039368/webrev.00/

Thanks, Vladimir.




--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.


--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

RFR: 8039368 Remove testcase from npt utf.c

2014-04-08 Thread Vladimir Kempik 

Hello

Please review this changeset:

File jdk/src/share/npt/utf.c contains a testcase that shouldn't be in 
production library.


bug: https://bugs.openjdk.java.net/browse/JDK-8039368
webrev: http://cr.openjdk.java.net/~vkempik/8039368/webrev.00/

Thanks, Vladimir.