Re: RFR: JDK-8252145: Unify Info.plist files with correct version strings

[Sergey Bylokhov]

Hi, Erik.

I would like to highlight one thing affected by this fix. The text in the 
default about dialog in the Swing application will be changed.

For my local build:
 - Current text: "Java Version 1.0 (16)"
 - After the fix: "Java Version 16 (0)"

I am not sure why the build version and as a result the CFBundleVersion is zero?

On 24.08.2020 08:19, Erik Joelsson wrote:

When fixing JDK-8246094, I concluded that our Info.plist files are in a bit of 
a mess. This patch tries to address this on a more fundamental level.

1. All Info.plist files and templates are moved to the same location in the 
source tree.

2. The CFBundleIdentifier is changed to no longer contain the version number. 
Instead it gets the $VERSION_PRE string if present.

3. The CFBundleShortVersionString is changed to the numeric version part of our 
version string.

4. The CFBundleVersion is changed to the build number (or a custom number if supplied 
through a new configure argument). For Oracle builds, this will take the form of 
..

For more details on why this particular scheme, see bug description, but in 
short, this is what I think best reflects what the Apple documentation says the 
fields are for.

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

Webrev: http://cr.openjdk.java.net/~erikj/8252145/webrev.01

/Erik




--
Best regards, Sergey.

Re: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of discrete GPU

[Philip Race]

Is there any performance cost to doing this ? I'd expect so. Any estimate ?

And there's then no way to explicitly request the discrete card on a 
15/16" MBP.

Should we release note this ?

-phil

On 8/21/20, 3:02 AM, Magnus Ihse Bursie wrote:

On 2020-08-21 06:55, Sergey Bylokhov wrote:

Hello.
Please review the fix for jdk/client.

Bug: https://bugs.openjdk.java.net/browse/JDK-8251854
Fix: http://cr.openjdk.java.net/~serb/8251854/webrev.00

The fix looks good from a build perspective.

(But it highlights the fact that we have no consistent placement of 
those plist files; we should probably address that in a separate fix.)


/Magnus



This is a review request for the bug particularly fixed some time ago:
https://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005425.html

In that review request it was found that the old fix does not work 
well in all cases, see:

https://mail.openjdk.java.net/pipermail/2d-dev/2015-August/005611.html

The current fix updates an embedded plist.info, so the java will not 
require

discrete graphics by default, same as for any other applications.

Note that the new "metal" pipeline also does not required the 
discrete graphics.


The documentation for NSSupportsAutomaticGraphicsSwitching:
https://developer.apple.com/documentation/bundleresources/information_property_list/nssupportsautomaticgraphicsswitching 

Re: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support

[Erik Österlund]

Hi Ningsheng,

On 2020-08-24 11:59, Ningsheng Jian wrote:

Hi Erik,

Thanks for the review!

On 8/22/20 12:21 AM, Erik Österlund wrote:

Hi,

Have you tried this with ZGC on AArch64? It has custom code for saving
live registers in the load barrier slow path.
I can't see any code changes there, so assuming this will just crash
instead.
The relevant code is in ZBarrierSetAssembler on aarch64.

Maybe I missed something?



I didn't add ZGC option while running tests. I think I need to update 
push_fp() which is called by ZSaveLiveRegisters. But do we need to get 
size info (float/neon/sve) instead of saving the whole vector 
register? Currently, it just simply saves the whole NEON register.


What we found on x86_64 was that there was a significant cost in saving 
vector registers in load barriers. That is why we perform some analysis 
so that only the exact registers that are affected, and only the parts 
of the registers that are affected, get spilled. It actually mattered. 
It will of course work either way, but that was our observation on 
x86_64. But I am okay with that being deferred to a separate RFE. I just 
wanted to make sure that it at the very least works with the new code, 
for a start, so it doesn't start crashing.


And in ZBarrierSetAssembler::load_at(), before calling to runtime 
code, we call push_call_clobbered_registers_except(), which just saves 
floating point registers instead of the whole NEON vector registers. 
Similar behavior in x86 implementation. Is that correct (not saving 
vectors)?


Yes. The call contexts are:
1) Interpreter. Does not use vector registers.
2) Method handle intrinsic. Uses only floats that are part of the Java 
calling convention, rest is garbage. No vectors here.

3) Checkcast arraycopy. Does not use vectors.

Thanks,
/Erik


Thanks,
Ningsheng

RE: Preliminary review for new WINENV support

[Ludovic Henry]

Hi Magnus,

I want to follow up on this work of yours, as we've particular interest in it 
for the Windows-AArch64 port.

Let me know how I could assist you in this effort.

Thank you,

--
Ludovic

-Original Message-
From: build-dev  On Behalf Of Yasumasa Suenaga
Sent: Wednesday, July 8, 2020 9:47 PM
To: Derek Keeler ; Monica Beckwith 
; Magnus Ihse Bursie 
; build-dev 
Subject: Re: Preliminary review for new WINENV support

On 2020/07/09 12:12, Derek Keeler wrote:
> After applying Suenaga's patch, I see this error:
> 
> checking wsl distribution... 
> /home/dekeeler/dev/openjdk.net/sandbox/build/.configure-support/generated-configure.sh:
>  line 32952: -d: command not found
> 
> I'm running Debian 10 in my WSL2 instance and it does not include 
> `lsb_release` by default. Installed it with `sudo apt-get install 
> lsb-release`.

It's better if we add AC_CHECK_PROG for lsb_release for Windows (for just WSL?)


> The next trouble I ran into is that I only have Visual Studio 2019 installed. 
> I tried to make it work but lack the necessary experience to wrangle this 
> code. Will start again in the morning after installing VS2017.

FYI: I can run configure script with VS2019 community edition on Ubuntu 20.04 
on both WSL 1 and 2, however I could not complete building OpenJDK image on WSL 
2 due to I/O performance issue.


Thanks,

Yasumasa


> -Derek
> 
> 
> From: build-dev  on behalf of Derek Keeler 
> 
> Sent: July 8, 2020 5:53 PM
> To: Monica Beckwith ; Magnus Ihse Bursie 
> ; build-dev 
> Subject: Re: Preliminary review for new WINENV support
> 
> This is fantastic!
> 
> I'm synching to this branch tonight and will start building it locally on my 
> WSL2 environment. I'll send questions/comments to this thread unless there is 
> a better place?
> 
> (Note: our internal email system may obfuscate the links below in future 
> replies, my apologies).
> 
> -Derek
> 
> 
> From: build-dev  on behalf of Monica 
> Beckwith 
> Sent: July 5, 2020 11:34 AM
> To: Magnus Ihse Bursie ; build-dev 
> 
> Subject: Re: Preliminary review for new WINENV support
> 
> Wow! Impressive work, @Magnus Ihse 
> Bursie . When working with 
> cross-compilation mods for aarch64-win port, I realized we needed to clean 
> up/better support the quirks around fixpath and also I was hoping to expand 
> the support to wsl2, etc. From what I am reading, you seem to have touched 
> all of these and more! I am mostly offline for the next two days, but will 
> start testing your changes when I am back online. Thank you for doing the 
> needful.
> 
> Monica
> 
> Get Outlook for Android
> 
> 
> From: build-dev  on behalf of Magnus Ihse 
> Bursie 
> Sent: Saturday, July 4, 2020 7:08:20 PM
> To: build-dev 
> Subject: Preliminary review for new WINENV support
> 
> I've been working for some time on a complete rewrite of how we handle the 
> pecularities of the Windows build environment. This new solution supports 
> Cygwin, Msys2, WSL1 and WSL2 (after a fashion, see below), what I have termed 
> different "winenvs".
> 
> One of the main design goals has been to minimize the difference for the 
> configure script and make files for the different winenvs, and leverage as 
> much shared code between them as possible. Another has been to try to collect 
> all the "trickiness" needed in as few places as possible, ideally just one, 
> instead of having it spread out all over the configure script. A third design 
> goal has been to prepare for cross-compilation for Windows from Linux, using 
> Wine.
> 
> It pretty soon turned out that I needed to get a better grip on how we detect 
> tools in configure, so a complete overhaul of this is included in the change. 
> Now we have more or less fully parted with the original autoconf functions, 
> which has long been too limited for us, and now finally has reached their end 
> of usefulness.
> 
> At this point, I have a prototype / preview that basically works, but has 
> some limitations.
> 
> I'd like to ask anyone interested in building OpenJDK on Windows to take the 
> patch for a spin. Especially if you have an esoteric or exotic setup!
> 
> Webrev: 
> https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~ihse%2Fwinenv-preview-1%2Fwebrev.01%2Fdata=02%7C01%7Cluhenry%40microsoft.com%7C55d5bddc82f142c2312c08d823c33111%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637298668546029073sdata=k7tQ6%2BfwdrD8AGryNZdqAD%2Fk3Lnc%2B%2B75opEaWASISo0%3Dreserved=0
> 
> (If you prefer, you can check out the branch "ihse-winenv-branch" on 
> 

RFR: JDK-8252145: Unify Info.plist files with correct version strings

[Erik Joelsson]

When fixing JDK-8246094, I concluded that our Info.plist files are in a 
bit of a mess. This patch tries to address this on a more fundamental level.


1. All Info.plist files and templates are moved to the same location in 
the source tree.


2. The CFBundleIdentifier is changed to no longer contain the version 
number. Instead it gets the $VERSION_PRE string if present.


3. The CFBundleShortVersionString is changed to the numeric version part 
of our version string.


4. The CFBundleVersion is changed to the build number (or a custom 
number if supplied through a new configure argument). For Oracle builds, 
this will take the form of ..


For more details on why this particular scheme, see bug description, but 
in short, this is what I think best reflects what the Apple 
documentation says the fields are for.


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

Webrev: http://cr.openjdk.java.net/~erikj/8252145/webrev.01

/Erik

Re: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support

[Ningsheng Jian]

Hi Erik,

Thanks for the review!

On 8/22/20 12:21 AM, Erik Österlund wrote:

Hi,

Have you tried this with ZGC on AArch64? It has custom code for saving
live registers in the load barrier slow path.
I can't see any code changes there, so assuming this will just crash
instead.
The relevant code is in ZBarrierSetAssembler on aarch64.

Maybe I missed something?



I didn't add ZGC option while running tests. I think I need to update 
push_fp() which is called by ZSaveLiveRegisters. But do we need to get 
size info (float/neon/sve) instead of saving the whole vector register? 
Currently, it just simply saves the whole NEON register.


And in ZBarrierSetAssembler::load_at(), before calling to runtime code, 
we call push_call_clobbered_registers_except(), which just saves 
floating point registers instead of the whole NEON vector registers. 
Similar behavior in x86 implementation. Is that correct (not saving 
vectors)?


Thanks,
Ningsheng