From magnus.ihse.bursie at oracle.com  Wed Jul  1 00:27:10 2020
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 1 Jul 2020 02:27:10 +0200
Subject: RFR: JDK-8248610 Clean up handling of Windows RC files
Message-ID: <42384cac-92fa-7ceb-e056-70973a64ba37@oracle.com>

The logic for handling .rc files in Windows has been quite messy. The 
variable RCFLAGS was incorrectly named RC_FLAGS. In it, we mixed 
tool-specific values with defines needed by version.rc. The contents of 
version.rc was needlessly copied in several places, with some variation. 
Some of the "special" rc files that added to functionality provided by 
the "global" version.rc was in need of some love.

Bug: https://bugs.openjdk.java.net/browse/JDK-8248610
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8248610-clean-up-RCFLAGS/webrev.01

/Magnus


From jiefu at tencent.com  Wed Jul  1 02:29:44 2020
From: jiefu at tencent.com (=?utf-8?B?amllZnUo5YKF5p2wKQ==?=)
Date: Wed, 1 Jul 2020 02:29:44 +0000
Subject: RFR: 8248612: Back quotes and double quotes must not be escaped in:
 Cannot convert \"$unix_path\" to Windows path
Message-ID: <8C398822-52D1-4E33-A6BB-8ACC3420073D@tencent.com>

Hi all,

May I get reviews for this fix?

JBS:    https://bugs.openjdk.java.net/browse/JDK-8248612
Webrev: http://cr.openjdk.java.net/~jiefu/8248612/webrev.00/

Thanks a lot.
Best regards,
Jie

From vkempik at azul.com  Wed Jul  1 06:54:31 2020
From: vkempik at azul.com (Vladimir Kempik)
Date: Wed, 1 Jul 2020 06:54:31 +0000
Subject: RFR[16] 8248495: [macos] zerovm is broken due to libffi headers
 location
In-Reply-To: <DC7D9791-C212-45F6-B71D-45905ED99B30@tencent.com>
References: <DC7D9791-C212-45F6-B71D-45905ED99B30@tencent.com>
Message-ID: <6aeac521ee8046e2b9b3e9e9fe3385d7@azul.com>

Hello

You are using libffi from brew. I'm trying to use the system's one. On x86_64 you have a choice, but on arm64 there is no choice atm.

I believe its wrong when configure script can't find default system's library located at default location for this type of OS.

Thanks, Vladimir.

"jiefu(??)" <jiefu at tencent.com> 1 ???? 2020 ?. 02:59:18 ???????:

Hi Vladimir and Magnus,

How about configuring with --with-libffi=... like this:
        --with-libffi=/usr/local/Cellar/libffi/3.2.1/lib/libffi-3.2.1     --disable-warnings-as-errors

I can compile zero vm on our macos platforms with that configuration.

Thanks.
Best regards,
Jie

?On 2020/7/1, 3:15 AM, "build-dev on behalf of Vladimir Kempik" <build-dev-retn at openjdk.java.net on behalf of vkempik at azul.com> wrote:

    Hello

    I agree modding  hpp files is a bad idea

    Thanks for idea with setting LIBFFI_CFLAGS

    here is updated webrev: http://cr.openjdk.java.net/~vkempik/8248495/webrev.01/

    AC_CHECK_HEADERS ignored CFLAGS for some reason, so modding header_name for it was still needed.
    This special case only applies to macos/clang when sysroot is set and no libffi configure options is used. (which is default case)

    Thanks, Vladimir


30 ???? 2020 ?., ? 19:46, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> ???????(?):

Vladimir,

This looks like it can break in other situation than your specific case.

It sounds like you should set LIBFFI_CFLAGS= to  -I<path to your ffi installation>, such that "<path to your ffi installation>/ffi.h" exists. In particular, the change of include path in globalDefinitions_zero.hpp looks bad.

/Magnus

On 2020-06-30 15:33, Vladimir Kempik wrote:
Hello

Please review this fix for zero vm building on macos.

The issue comes from the libffi, it?s headers are located inside usr/include/ffi/ folder in Macos.sdk, so it can?t be found by configure script.

If one wants to use system?s libffi and pass path to libffi via configure argument as --with-libffi-include=/usr/include/ffi, then it won?t be found by configure because clang will look exactly in /usr/include/ffi, but not in macos.sdk
The system, at least on 10.15 doesn?t have /usr/includes at all.

This patch makes jdk to look for ffi/ffi.h header in case of Macos/clang and no --with-libffi-include argument.

However there is one issue with this patch, if --with-libffi-include passed then c++ code will still try to include <ffi/ffi.h>

I?m not sure which way is the best for such rare case. it could be possible to define include filename in configure and pass it via -D and CFLAGS to c++ code.


The webrev - http://cr.openjdk.java.net/~vkempik/8248495/webrev.00/

The bug - https://bugs.openjdk.java.net/browse/JDK-8248495

Thanks, Vladimir


From jan.lahoda at oracle.com  Wed Jul  1 07:18:10 2020
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 1 Jul 2020 09:18:10 +0200
Subject: JDK 16 RFR of JDK-8247534: Update --release 15 symbol information
 for JDK 15 build 29
In-Reply-To: <5d2c4d71-1741-be24-c0ee-502c490d47ab@oracle.com>
References: <5d2c4d71-1741-be24-c0ee-502c490d47ab@oracle.com>
Message-ID: <16cc0963-13bc-fb0c-fc44-528807ad4fb2@oracle.com>

Looks good to me. (A new innerclass entry was added for 
java/security/Provider$Service, and the current format sadly needs to 
restate the whole class header, including all innerclass entries for any 
change to the header.)

Jan

On 30. 06. 20 23:58, Joe Darcy wrote:
> Hello,
> 
> Please review a small change to bring JDK 16's --release information for 
> JDK 15 up to date with JDK 15 b29:
> 
>  ??? JDK-8247534: Update --release 15 symbol information for JDK 15 build 29
> http://cr.openjdk.java.net/~darcy/8247534.0/
> 
> Patch below.
> 
> Thanks,
> 
> -Joe
> 
> --- old/make/data/symbols/java.base-F.sym.txt	2020-06-30 14:45:07.594001000 -0700
> +++ new/make/data/symbols/java.base-F.sym.txt	2020-06-30 14:45:07.006001000 -0700
> @@ -182,6 +182,20 @@
>   method name openSocketChannel descriptor (Ljava/net/ProtocolFamily;)Ljava/nio/channels/SocketChannel; thrownTypes java/io/IOException flags 1
>   method name openServerSocketChannel descriptor (Ljava/net/ProtocolFamily;)Ljava/nio/channels/ServerSocketChannel; thrownTypes java/io/IOException flags 1
>   
> +class name java/security/KeyStore
> +header extends java/lang/Object nestMembers java/security/KeyStore$Builder,java/security/KeyStore$TrustedCertificateEntry,java/security/KeyStore$SecretKeyEntry,java/security/KeyStore$PrivateKeyEntry,java/security/KeyStore$Entry,java/security/KeyStore$Entry$Attribute,java/security/KeyStore$CallbackHandlerProtection,java/security/KeyStore$PasswordProtection,java/security/KeyStore$ProtectionParameter,java/security/KeyStore$LoadStoreParameter flags 21
> +innerclass innerClass java/security/KeyStore$LoadStoreParameter outerClass java/security/KeyStore innerClassName LoadStoreParameter flags 609
> +innerclass innerClass java/security/KeyStore$ProtectionParameter outerClass java/security/KeyStore innerClassName ProtectionParameter flags 609
> +innerclass innerClass java/security/KeyStore$Entry outerClass java/security/KeyStore innerClassName Entry flags 609
> +innerclass innerClass java/security/Provider$Service outerClass java/security/Provider innerClassName Service flags 9
> +innerclass innerClass java/security/KeyStore$Builder outerClass java/security/KeyStore innerClassName Builder flags 409
> +innerclass innerClass java/security/KeyStore$TrustedCertificateEntry outerClass java/security/KeyStore innerClassName TrustedCertificateEntry flags 19
> +innerclass innerClass java/security/KeyStore$SecretKeyEntry outerClass java/security/KeyStore innerClassName SecretKeyEntry flags 19
> +innerclass innerClass java/security/KeyStore$PrivateKeyEntry outerClass java/security/KeyStore innerClassName PrivateKeyEntry flags 19
> +innerclass innerClass java/security/KeyStore$CallbackHandlerProtection outerClass java/security/KeyStore innerClassName CallbackHandlerProtection flags 9
> +innerclass innerClass java/security/KeyStore$PasswordProtection outerClass java/security/KeyStore innerClassName PasswordProtection flags 9
> +innerclass innerClass java/security/KeyStore$Entry$Attribute outerClass java/security/KeyStore$Entry innerClassName Attribute flags 609
> +
>   class name java/security/interfaces/EdECKey
>   header extends java/lang/Object flags 601
>   method name getParams descriptor ()Ljava/security/spec/NamedParameterSpec; flags 401
> 


From magnus.ihse.bursie at oracle.com  Wed Jul  1 08:37:19 2020
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 1 Jul 2020 10:37:19 +0200
Subject: RFR: 8248612: Back quotes and double quotes must not be escaped
 in: Cannot convert \"$unix_path\" to Windows path
In-Reply-To: <8C398822-52D1-4E33-A6BB-8ACC3420073D@tencent.com>
References: <8C398822-52D1-4E33-A6BB-8ACC3420073D@tencent.com>
Message-ID: <40d4ebf1-e528-ff10-3d52-4474fda58383@oracle.com>

On 2020-07-01 04:29, jiefu(??) wrote:
> Hi all,
>
> May I get reviews for this fix?
>
> JBS:    https://bugs.openjdk.java.net/browse/JDK-8248612
> Webrev: http://cr.openjdk.java.net/~jiefu/8248612/webrev.00/
LGTM.

/Magnus
>
> Thanks a lot.
> Best regards,
> Jie



From jiefu at tencent.com  Wed Jul  1 08:46:10 2020
From: jiefu at tencent.com (=?utf-8?B?amllZnUo5YKF5p2wKQ==?=)
Date: Wed, 1 Jul 2020 08:46:10 +0000
Subject: RFR: 8248612: Back quotes and double quotes must not be escaped
 in: Cannot convert \"$unix_path\" to Windows path
Message-ID: <C927F187-F64B-4193-B032-9B5B01442394@tencent.com>

Thanks Magnus for your review.

I will push it tonight.

Best regards,
Jie

?On 2020/7/1, 4:39 PM, "Magnus Ihse Bursie" <magnus.ihse.bursie at oracle.com> wrote:

    On 2020-07-01 04:29, jiefu(??) wrote:
    > Hi all,
    >
    > May I get reviews for this fix?
    >
    > JBS:    https://bugs.openjdk.java.net/browse/JDK-8248612
    > Webrev: http://cr.openjdk.java.net/~jiefu/8248612/webrev.00/
    LGTM.
    
    /Magnus
    >
    > Thanks a lot.
    > Best regards,
    > Jie
    
    
    


From vkempik at azul.com  Wed Jul  1 09:45:53 2020
From: vkempik at azul.com (Vladimir Kempik)
Date: Wed, 1 Jul 2020 09:45:53 +0000
Subject: RFR[16] 8248495: [macos] zerovm is broken due to libffi headers
 location
In-Reply-To: <b31ef9a5-c408-0abd-d7ff-20bf07a7833d@oracle.com>
References: <00B73388-5073-46C6-9FB3-DBE426CE6B7B@azul.com>
 <000474e1-76e8-f19b-4690-5f15b8539dc7@oracle.com>
 <3A739E30-B112-4676-ABAB-D51E24C869BE@azul.com>
 <b31ef9a5-c408-0abd-d7ff-20bf07a7833d@oracle.com>
Message-ID: <D8C83D9B-898E-418A-B895-2C7CED1F335E@azul.com>

Hello

Please take a look at updated webrev - http://cr.openjdk.java.net/~vkempik/8248495/webrev.02/ <http://cr.openjdk.java.net/~vkempik/8248495/webrev.02/>

I decided to use AC_CHECK_HEADERS instead AC_CHECK_FILE as it doesn?t work in cross-compilation scenario.

libffi binary is located in absolutely standard location, so -lffi was enough.

Thanks, Vladimir

> 30 ???? 2020 ?., ? 23:09, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> ???????(?):
> 
> 
> On 2020-06-30 21:08, Vladimir Kempik wrote:
>> Hello
>> 
>> I agree modding  hpp files is a bad idea
>> 
>> Thanks for idea with setting LIBFFI_CFLAGS
>> 
>> here is updated webrev: http://cr.openjdk.java.net/~vkempik/8248495/webrev.01/
> I still think you are doing this too complicated, and the wrong way around.
>> 
>> AC_CHECK_HEADERS ignored CFLAGS for some reason, so modding header_name for it was still needed.
> 
> No, AC_CHECK_HEADERS does not work that way. It knows nothing about our internal variables. How could it?
> 
> First of all, I still think you should let PKG_CHECK_MODULES do its magic first. If that fails, you can try compiling with AC_CHECK_HEADERS([ffi.h]), just as the code currently does.
> 
> Only if this fails, your workaround should kick in, before giving up completely. At this point, you should check if ${SYSROOT}/usr/include/ffi/ffi/ffi.h exists. If it does, you should set
> LIBFFI_CFLAGS := -I${SYSROOT}/usr/include/ffi/ffi
> 
> and you will not need the AC_CHECK_HEADERS, since you know the ffi.h file is there, and there is a AC_LINK_IFELSE at the end to verify that everything works. You can even skip the platform checks, since this will apply to all configurations where the header file is in this odd place relative to the sysroot. (But please save a comment about where you have spotted it.)
> 
> However, you are not done yet.  Your patch do not address the whereabouts of the library, only the include file. I assume it might too be stored in an odd location?
> 
> I see that we do not follow the best-practice of separating LDFLAGS and LIBS here, so if you need to point to a non-standard location for the library, you have to do like this example:
> 
> LIBFFI_LIBS="-L${with_libffi}/lib -lffi"
> 
> Ideally, this should be explit out to an LIBFFI_LDFLAGS, but that's a change for another day, since it required changes in many places.
> 
> /Magnus
> 
> 
> 
>> This special case only applies to macos/clang when sysroot is set and no libffi configure options is used. (which is default case)
>> 
>> Thanks, Vladimir
>> 
>> 
>>> 30 ???? 2020 ?., ? 19:46, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> ???????(?):
>>> 
>>> Vladimir,
>>> 
>>> This looks like it can break in other situation than your specific case.
>>> 
>>> It sounds like you should set LIBFFI_CFLAGS= to  -I<path to your ffi installation>, such that "<path to your ffi installation>/ffi.h" exists. In particular, the change of include path in globalDefinitions_zero.hpp looks bad.
>>> 
>>> /Magnus
>>> 
>>> On 2020-06-30 15:33, Vladimir Kempik wrote:
>>>> Hello
>>>> 
>>>> Please review this fix for zero vm building on macos.
>>>> 
>>>> The issue comes from the libffi, it?s headers are located inside usr/include/ffi/ folder in Macos.sdk, so it can?t be found by configure script.
>>>> 
>>>> If one wants to use system?s libffi and pass path to libffi via configure argument as --with-libffi-include=/usr/include/ffi, then it won?t be found by configure because clang will look exactly in /usr/include/ffi, but not in macos.sdk
>>>> The system, at least on 10.15 doesn?t have /usr/includes at all.
>>>> 
>>>> This patch makes jdk to look for ffi/ffi.h header in case of Macos/clang and no --with-libffi-include argument.
>>>> 
>>>> However there is one issue with this patch, if --with-libffi-include passed then c++ code will still try to include <ffi/ffi.h>
>>>> 
>>>> I?m not sure which way is the best for such rare case. it could be possible to define include filename in configure and pass it via -D and CFLAGS to c++ code.
>>>> 
>>>> 
>>>> The webrev - http://cr.openjdk.java.net/~vkempik/8248495/webrev.00/
>>>> 
>>>> The bug - https://bugs.openjdk.java.net/browse/JDK-8248495
>>>> 
>>>> Thanks, Vladimir


From galder at redhat.com  Wed Jul  1 10:05:10 2020
From: galder at redhat.com (Galder Zamarreno)
Date: Wed, 1 Jul 2020 12:05:10 +0200
Subject: RFR: JDK-8248158 Configure fails with autoconf not found even though
 it's installed
Message-ID: <CAAcPREuoXF9rrO5YrZwYdNO6iUvQv=Yv7mPHY_OcRZ6H=7K+kg@mail.gmail.com>

Using `which` to check whether commands exist can result in confusing
errors when `which` itself is not installed in the system. This is the case
with `autoconf`, where if `autoconf` is present but `which` isn't, the
build system says that `autoconf` is missing, when in reality it is `which`
which is missing. The fix switches autoconf uses of `which` for `type -p`
instead, which is a Bash built-in command.

I've tested the fix with a fedora docker container that had `autoconf`
installed but `which`. When using `type -p` it correctly detects `autoconf`
installed and eventually fails saying that `which` is not installed, which
is the expected behaviour.

`which` is still in use in make/autoconf/util_windows.m4. A possible future
improvement would be to see if `which` use there could be replaced as well.
Eventually, when no `which` uses remain, the presence check for `which`
could be removed.

Bug: https://bugs.openjdk.java.net/browse/JDK-8248158
WebRev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8248158/01/webrev/

Galder


From jonathan.gibbons at oracle.com  Wed Jul  1 18:02:09 2020
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 1 Jul 2020 11:02:09 -0700
Subject: JDK-8244763: Update --release 8 symbol information after JSR 337
 MR3
In-Reply-To: <4774b5e1-0b78-bba0-95f2-445cdcab72b3@oracle.com>
References: <e187c922-49e3-ad4a-1111-33a0ce44943b@oracle.com>
 <87877fd1-5413-7518-a2e6-d6d2132f6356@oracle.com>
 <3f816bd3-bc9d-8f94-db98-94fd0423948d@oracle.com>
 <85933330-a0e2-74cf-876c-42b64eb28482@oracle.com>
 <4774b5e1-0b78-bba0-95f2-445cdcab72b3@oracle.com>
Message-ID: <19bde5be-c14b-fd5d-0c23-a7dfc9bfa2f0@oracle.com>

+1

-- Jon

On 6/26/20 6:13 AM, Jan Lahoda wrote:
> Hi,
>
> I propose to split the data update (for JDK 15 and for backports) and 
> the tool/CreateSymbols update (for JDK 16+). So I've created:
> https://bugs.openjdk.java.net/browse/JDK-8248405
>
> for the latter. Lets keep JDK-8244763 only for the former, i.e. for 
> this patch:
> http://cr.openjdk.java.net/~jlahoda/8244763/webrev.01-data/
>
> I believe the data patch is reviewed, and is not controversial. Please 
> let me know if you see any issues with this split.
>
> Thanks,
> ?? Jan
>
> On 01. 06. 20 10:07, Jan Lahoda wrote:
>> Further testing revealed some issues with the patch, especially:
>> -use of un-encoded version when deleting the old data for the version 
>> (so the data deletion failed for versions > 9)
>> -need to delete old module data as well
>> -when searching for existing methods and fields, we need to continue 
>> the search to find the best existing candidate (the code still had a 
>> for loop break, so only the first match was found).
>>
>> I apologize for missing those in the first review.
>>
>> Delta webrev:
>> http://cr.openjdk.java.net/~jlahoda/8244763/webrev.00-01-create-symbols/
>>
>> Full updated webrev:
>> http://cr.openjdk.java.net/~jlahoda/8244763/webrev.01-create-symbols/
>>
>> Does this look OK?
>>
>> Thanks!
>> ???? Jan
>>
>> On 28. 05. 20 16:47, Jonathan Gibbons wrote:
>>> Looks good to me.
>>>
>>> -- Jon
>>>
>>> On 5/18/20 9:36 AM, Jan Lahoda wrote:
>>>> I apologize, I used a wrong patch for the "data" webrev. The "class 
>>>> name java/util/jar/Attributes$Name" entry in java.base-7.sym.txt is 
>>>> first adding field descriptions, and then removing the old ones:
>>>> ---
>>>>> class name java/util/jar/Attributes$Name
>>>>> field name EXTENSION_INSTALLATION descriptor 
>>>>> Ljava/util/jar/Attributes$Name; flags 19
>>>>> field name IMPLEMENTATION_VENDOR_ID descriptor 
>>>>> Ljava/util/jar/Attributes$Name; flags 19
>>>>> field name IMPLEMENTATION_URL descriptor 
>>>>> Ljava/util/jar/Attributes$Name; flags 19
>>>>> -field name EXTENSION_INSTALLATION descriptor 
>>>>> Ljava/util/jar/Attributes$Name;
>>>>> -field name IMPLEMENTATION_VENDOR_ID descriptor 
>>>>> Ljava/util/jar/Attributes$Name;
>>>>> -field name IMPLEMENTATION_URL descriptor 
>>>>> Ljava/util/jar/Attributes$Name;---
>>>>
>>>> The correct order (and the order generated by the tool in the 
>>>> webrev.00-create-symbols/ webrev) is to first remove the field 
>>>> descriptions and then add the new ones:
>>>> ---
>>>>> class name java/util/jar/Attributes$Name
>>>>> -field name EXTENSION_INSTALLATION descriptor 
>>>>> Ljava/util/jar/Attributes$Name;
>>>>> -field name IMPLEMENTATION_VENDOR_ID descriptor 
>>>>> Ljava/util/jar/Attributes$Name;
>>>>> -field name IMPLEMENTATION_URL descriptor 
>>>>> Ljava/util/jar/Attributes$Name;
>>>>> field name EXTENSION_INSTALLATION descriptor 
>>>>> Ljava/util/jar/Attributes$Name; flags 19
>>>>> field name IMPLEMENTATION_VENDOR_ID descriptor 
>>>>> Ljava/util/jar/Attributes$Name; flags 19
>>>>> field name IMPLEMENTATION_URL descriptor 
>>>>> Ljava/util/jar/Attributes$Name; flags 19
>>>> ---
>>>>
>>>> An updated webrev is the correct data is here:
>>>> http://cr.openjdk.java.net/~jlahoda/8244763/webrev.01-data/
>>>>
>>>> The only change is the above difference in order of entries in 
>>>> Attributes$Name.
>>>>
>>>> Sorry for trouble.
>>>>
>>>> Jan
>>>>
>>>> On 18. 05. 20 16:55, Jan Lahoda wrote:
>>>>> Hi,
>>>>>
>>>>> Some new APIs have been introduced in JSR 337 MR3 (JDK 8). We 
>>>>> should update the historical data for JDK 8 with these new APIs.
>>>>>
>>>>> As this was the first time we need to update data for a release 
>>>>> that other release data use as a baseline, it was necessary to 
>>>>> improve the CreateSymbols tool a little:
>>>>> -adding ability to ignore synchronized and native flags for 
>>>>> methods (as these don't affect the API)
>>>>> -when analyzing a new entry (method/field/class), and multiple 
>>>>> existing entries compatible with the new one exist, the existing 
>>>>> entry that matches the baseline is chosen (this helps to eliminate 
>>>>> unnecessary entries, esp. when the synchronized or native flag 
>>>>> changes)
>>>>> -when replacing/updating a release data, the original approach was 
>>>>> to remove the data for the release, and read them from classfiles, 
>>>>> and build the record again from scratch. This does not work well 
>>>>> for baseline data, so the new approach is:
>>>>> --keep all the existing data
>>>>> --the new data are load into a new auxiliary slot, called "$"
>>>>> --the old data for the given release are deleted
>>>>> --the auxiliary release is renamed from "$" to the correct release 
>>>>> name
>>>>>
>>>>> Together these changes allow to minimize the updates to JDK 8 
>>>>> data, to mostly only changes in the MR3, with some extra changes 
>>>>> like new/removed overrides (where the superclass has the method 
>>>>> that is/was overridden).
>>>>>
>>>>> The proposed changes to CreateSymbols are:
>>>>> http://cr.openjdk.java.net/~jlahoda/8244763/webrev.00-create-symbols/
>>>>>
>>>>> The proposed updates to the historical data are:
>>>>> http://cr.openjdk.java.net/~jlahoda/8244763/webrev.00-data/
>>>>>
>>>>> Note the changes only apply for JDK 8 historical data, so JDK 8 
>>>>> data are updated, and JDK 7 and 9 data undo the changes.
>>>>>
>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244763
>>>>>
>>>>> The intent is to backport to JDK 11u.
>>>>>
>>>>> How does this look?
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Jan


From erik.joelsson at oracle.com  Wed Jul  1 18:59:19 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 1 Jul 2020 11:59:19 -0700
Subject: RFR[16] 8248495: [macos] zerovm is broken due to libffi headers
 location
In-Reply-To: <D8C83D9B-898E-418A-B895-2C7CED1F335E@azul.com>
References: <00B73388-5073-46C6-9FB3-DBE426CE6B7B@azul.com>
 <000474e1-76e8-f19b-4690-5f15b8539dc7@oracle.com>
 <3A739E30-B112-4676-ABAB-D51E24C869BE@azul.com>
 <b31ef9a5-c408-0abd-d7ff-20bf07a7833d@oracle.com>
 <D8C83D9B-898E-418A-B895-2C7CED1F335E@azul.com>
Message-ID: <4e732b28-0851-6dae-f457-781362f7c333@oracle.com>

I think this looks ok, but would like Magnus' input as he is already 
involved in this review.

/Erik

On 2020-07-01 02:45, Vladimir Kempik wrote:
> Hello
>
> Please take a look at updated webrev - http://cr.openjdk.java.net/~vkempik/8248495/webrev.02/ <http://cr.openjdk.java.net/~vkempik/8248495/webrev.02/>
>
> I decided to use AC_CHECK_HEADERS instead AC_CHECK_FILE as it doesn?t work in cross-compilation scenario.
>
> libffi binary is located in absolutely standard location, so -lffi was enough.
>
> Thanks, Vladimir
>
>> 30 ???? 2020 ?., ? 23:09, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> ???????(?):
>>
>>
>> On 2020-06-30 21:08, Vladimir Kempik wrote:
>>> Hello
>>>
>>> I agree modding  hpp files is a bad idea
>>>
>>> Thanks for idea with setting LIBFFI_CFLAGS
>>>
>>> here is updated webrev: http://cr.openjdk.java.net/~vkempik/8248495/webrev.01/
>> I still think you are doing this too complicated, and the wrong way around.
>>> AC_CHECK_HEADERS ignored CFLAGS for some reason, so modding header_name for it was still needed.
>> No, AC_CHECK_HEADERS does not work that way. It knows nothing about our internal variables. How could it?
>>
>> First of all, I still think you should let PKG_CHECK_MODULES do its magic first. If that fails, you can try compiling with AC_CHECK_HEADERS([ffi.h]), just as the code currently does.
>>
>> Only if this fails, your workaround should kick in, before giving up completely. At this point, you should check if ${SYSROOT}/usr/include/ffi/ffi/ffi.h exists. If it does, you should set
>> LIBFFI_CFLAGS := -I${SYSROOT}/usr/include/ffi/ffi
>>
>> and you will not need the AC_CHECK_HEADERS, since you know the ffi.h file is there, and there is a AC_LINK_IFELSE at the end to verify that everything works. You can even skip the platform checks, since this will apply to all configurations where the header file is in this odd place relative to the sysroot. (But please save a comment about where you have spotted it.)
>>
>> However, you are not done yet.  Your patch do not address the whereabouts of the library, only the include file. I assume it might too be stored in an odd location?
>>
>> I see that we do not follow the best-practice of separating LDFLAGS and LIBS here, so if you need to point to a non-standard location for the library, you have to do like this example:
>>
>> LIBFFI_LIBS="-L${with_libffi}/lib -lffi"
>>
>> Ideally, this should be explit out to an LIBFFI_LDFLAGS, but that's a change for another day, since it required changes in many places.
>>
>> /Magnus
>>
>>
>>
>>> This special case only applies to macos/clang when sysroot is set and no libffi configure options is used. (which is default case)
>>>
>>> Thanks, Vladimir
>>>
>>>
>>>> 30 ???? 2020 ?., ? 19:46, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> ???????(?):
>>>>
>>>> Vladimir,
>>>>
>>>> This looks like it can break in other situation than your specific case.
>>>>
>>>> It sounds like you should set LIBFFI_CFLAGS= to  -I<path to your ffi installation>, such that "<path to your ffi installation>/ffi.h" exists. In particular, the change of include path in globalDefinitions_zero.hpp looks bad.
>>>>
>>>> /Magnus
>>>>
>>>> On 2020-06-30 15:33, Vladimir Kempik wrote:
>>>>> Hello
>>>>>
>>>>> Please review this fix for zero vm building on macos.
>>>>>
>>>>> The issue comes from the libffi, it?s headers are located inside usr/include/ffi/ folder in Macos.sdk, so it can?t be found by configure script.
>>>>>
>>>>> If one wants to use system?s libffi and pass path to libffi via configure argument as --with-libffi-include=/usr/include/ffi, then it won?t be found by configure because clang will look exactly in /usr/include/ffi, but not in macos.sdk
>>>>> The system, at least on 10.15 doesn?t have /usr/includes at all.
>>>>>
>>>>> This patch makes jdk to look for ffi/ffi.h header in case of Macos/clang and no --with-libffi-include argument.
>>>>>
>>>>> However there is one issue with this patch, if --with-libffi-include passed then c++ code will still try to include <ffi/ffi.h>
>>>>>
>>>>> I?m not sure which way is the best for such rare case. it could be possible to define include filename in configure and pass it via -D and CFLAGS to c++ code.
>>>>>
>>>>>
>>>>> The webrev - http://cr.openjdk.java.net/~vkempik/8248495/webrev.00/
>>>>>
>>>>> The bug - https://bugs.openjdk.java.net/browse/JDK-8248495
>>>>>
>>>>> Thanks, Vladimir


From erik.joelsson at oracle.com  Wed Jul  1 19:06:38 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 1 Jul 2020 12:06:38 -0700
Subject: RFR: JDK-8248158 Configure fails with autoconf not found even
 though it's installed
In-Reply-To: <CAAcPREuoXF9rrO5YrZwYdNO6iUvQv=Yv7mPHY_OcRZ6H=7K+kg@mail.gmail.com>
References: <CAAcPREuoXF9rrO5YrZwYdNO6iUvQv=Yv7mPHY_OcRZ6H=7K+kg@mail.gmail.com>
Message-ID: <4a5377c0-509c-8504-8553-02bb7a12e9e2@oracle.com>

Looks good to me.

/Erik

On 2020-07-01 03:05, Galder Zamarreno wrote:
> Using `which` to check whether commands exist can result in confusing
> errors when `which` itself is not installed in the system. This is the case
> with `autoconf`, where if `autoconf` is present but `which` isn't, the
> build system says that `autoconf` is missing, when in reality it is `which`
> which is missing. The fix switches autoconf uses of `which` for `type -p`
> instead, which is a Bash built-in command.
>
> I've tested the fix with a fedora docker container that had `autoconf`
> installed but `which`. When using `type -p` it correctly detects `autoconf`
> installed and eventually fails saying that `which` is not installed, which
> is the expected behaviour.
>
> `which` is still in use in make/autoconf/util_windows.m4. A possible future
> improvement would be to see if `which` use there could be replaced as well.
> Eventually, when no `which` uses remain, the presence check for `which`
> could be removed.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8248158
> WebRev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8248158/01/webrev/
>
> Galder


From erik.joelsson at oracle.com  Wed Jul  1 19:15:09 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 1 Jul 2020 12:15:09 -0700
Subject: RFR: JDK-8248610 Clean up handling of Windows RC files
In-Reply-To: <42384cac-92fa-7ceb-e056-70973a64ba37@oracle.com>
References: <42384cac-92fa-7ceb-e056-70973a64ba37@oracle.com>
Message-ID: <a7a2117c-8877-e345-d3c4-54ca43118736@oracle.com>

Looks good.

/Erik

On 2020-06-30 17:27, Magnus Ihse Bursie wrote:
> The logic for handling .rc files in Windows has been quite messy. The 
> variable RCFLAGS was incorrectly named RC_FLAGS. In it, we mixed 
> tool-specific values with defines needed by version.rc. The contents 
> of version.rc was needlessly copied in several places, with some 
> variation. Some of the "special" rc files that added to functionality 
> provided by the "global" version.rc was in need of some love.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8248610
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8248610-clean-up-RCFLAGS/webrev.01
>
> /Magnus


From joe.darcy at oracle.com  Wed Jul  1 20:12:54 2020
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 1 Jul 2020 13:12:54 -0700
Subject: JDK 16 RFR of JDK-8247534: Update --release 15 symbol information
 for JDK 15 build 29
In-Reply-To: <16cc0963-13bc-fb0c-fc44-528807ad4fb2@oracle.com>
References: <5d2c4d71-1741-be24-c0ee-502c490d47ab@oracle.com>
 <16cc0963-13bc-fb0c-fc44-528807ad4fb2@oracle.com>
Message-ID: <6c29dd60-03c9-e7ed-121b-0cdab74877d0@oracle.com>

Thanks for the additional analysis Jan; I was wondering why the delta 
was so large.

Cheers,

-Joe

On 7/1/2020 12:18 AM, Jan Lahoda wrote:
> Looks good to me. (A new innerclass entry was added for 
> java/security/Provider$Service, and the current format sadly needs to 
> restate the whole class header, including all innerclass entries for 
> any change to the header.)
>
> Jan
>
> On 30. 06. 20 23:58, Joe Darcy wrote:
>> Hello,
>>
>> Please review a small change to bring JDK 16's --release information 
>> for JDK 15 up to date with JDK 15 b29:
>>
>> ???? JDK-8247534: Update --release 15 symbol information for JDK 15 
>> build 29
>> http://cr.openjdk.java.net/~darcy/8247534.0/
>>
>> Patch below.
>>
>> Thanks,
>>
>> -Joe
>>
>> --- old/make/data/symbols/java.base-F.sym.txt??? 2020-06-30 
>> 14:45:07.594001000 -0700
>> +++ new/make/data/symbols/java.base-F.sym.txt??? 2020-06-30 
>> 14:45:07.006001000 -0700
>> @@ -182,6 +182,20 @@
>> ? method name openSocketChannel descriptor 
>> (Ljava/net/ProtocolFamily;)Ljava/nio/channels/SocketChannel; 
>> thrownTypes java/io/IOException flags 1
>> ? method name openServerSocketChannel descriptor 
>> (Ljava/net/ProtocolFamily;)Ljava/nio/channels/ServerSocketChannel; 
>> thrownTypes java/io/IOException flags 1
>> ? +class name java/security/KeyStore
>> +header extends java/lang/Object nestMembers 
>> java/security/KeyStore$Builder,java/security/KeyStore$TrustedCertificateEntry,java/security/KeyStore$SecretKeyEntry,java/security/KeyStore$PrivateKeyEntry,java/security/KeyStore$Entry,java/security/KeyStore$Entry$Attribute,java/security/KeyStore$CallbackHandlerProtection,java/security/KeyStore$PasswordProtection,java/security/KeyStore$ProtectionParameter,java/security/KeyStore$LoadStoreParameter 
>> flags 21
>> +innerclass innerClass java/security/KeyStore$LoadStoreParameter 
>> outerClass java/security/KeyStore innerClassName LoadStoreParameter 
>> flags 609
>> +innerclass innerClass java/security/KeyStore$ProtectionParameter 
>> outerClass java/security/KeyStore innerClassName ProtectionParameter 
>> flags 609
>> +innerclass innerClass java/security/KeyStore$Entry outerClass 
>> java/security/KeyStore innerClassName Entry flags 609
>> +innerclass innerClass java/security/Provider$Service outerClass 
>> java/security/Provider innerClassName Service flags 9
>> +innerclass innerClass java/security/KeyStore$Builder outerClass 
>> java/security/KeyStore innerClassName Builder flags 409
>> +innerclass innerClass java/security/KeyStore$TrustedCertificateEntry 
>> outerClass java/security/KeyStore innerClassName 
>> TrustedCertificateEntry flags 19
>> +innerclass innerClass java/security/KeyStore$SecretKeyEntry 
>> outerClass java/security/KeyStore innerClassName SecretKeyEntry flags 19
>> +innerclass innerClass java/security/KeyStore$PrivateKeyEntry 
>> outerClass java/security/KeyStore innerClassName PrivateKeyEntry 
>> flags 19
>> +innerclass innerClass 
>> java/security/KeyStore$CallbackHandlerProtection outerClass 
>> java/security/KeyStore innerClassName CallbackHandlerProtection flags 9
>> +innerclass innerClass java/security/KeyStore$PasswordProtection 
>> outerClass java/security/KeyStore innerClassName PasswordProtection 
>> flags 9
>> +innerclass innerClass java/security/KeyStore$Entry$Attribute 
>> outerClass java/security/KeyStore$Entry innerClassName Attribute 
>> flags 609
>> +
>> ? class name java/security/interfaces/EdECKey
>> ? header extends java/lang/Object flags 601
>> ? method name getParams descriptor 
>> ()Ljava/security/spec/NamedParameterSpec; flags 401
>>


From magnus.ihse.bursie at oracle.com  Wed Jul  1 20:27:00 2020
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 1 Jul 2020 22:27:00 +0200
Subject: RFR: JDK-8248158 Configure fails with autoconf not found even
 though it's installed
In-Reply-To: <CAAcPREuoXF9rrO5YrZwYdNO6iUvQv=Yv7mPHY_OcRZ6H=7K+kg@mail.gmail.com>
References: <CAAcPREuoXF9rrO5YrZwYdNO6iUvQv=Yv7mPHY_OcRZ6H=7K+kg@mail.gmail.com>
Message-ID: <32d59c17-97aa-79ea-9684-329c01f80766@oracle.com>



On 2020-07-01 12:05, Galder Zamarreno wrote:
> Using `which` to check whether commands exist can result in confusing
> errors when `which` itself is not installed in the system. This is the case
> with `autoconf`, where if `autoconf` is present but `which` isn't, the
> build system says that `autoconf` is missing, when in reality it is `which`
> which is missing. The fix switches autoconf uses of `which` for `type -p`
> instead, which is a Bash built-in command.
>
> I've tested the fix with a fedora docker container that had `autoconf`
> installed but `which`. When using `type -p` it correctly detects `autoconf`
> installed and eventually fails saying that `which` is not installed, which
> is the expected behaviour.
>
> `which` is still in use in make/autoconf/util_windows.m4. A possible future
> improvement would be to see if `which` use there could be replaced as well.
> Eventually, when no `which` uses remain, the presence check for `which`
> could be removed.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8248158
> WebRev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8248158/01/webrev/
You don't need the grep part. "type -p" is well-defined to return 
nothing, or the path to the binary. The grep was needed for which on 
solaris, which returned this as an error message when a binary was not 
found, instead of nothing.

/Magnus
>
> Galder



From magnus.ihse.bursie at oracle.com  Wed Jul  1 20:30:08 2020
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 1 Jul 2020 22:30:08 +0200
Subject: RFR: JDK-8248158 Configure fails with autoconf not found even
 though it's installed
In-Reply-To: <CAAcPREuoXF9rrO5YrZwYdNO6iUvQv=Yv7mPHY_OcRZ6H=7K+kg@mail.gmail.com>
References: <CAAcPREuoXF9rrO5YrZwYdNO6iUvQv=Yv7mPHY_OcRZ6H=7K+kg@mail.gmail.com>
Message-ID: <5b25d03a-675f-072a-5772-2e2b03739484@oracle.com>



On 2020-07-01 12:05, Galder Zamarreno wrote:
> Using `which` to check whether commands exist can result in confusing
> errors when `which` itself is not installed in the system. This is the case
> with `autoconf`, where if `autoconf` is present but `which` isn't, the
> build system says that `autoconf` is missing, when in reality it is `which`
> which is missing. The fix switches autoconf uses of `which` for `type -p`
> instead, which is a Bash built-in command.
>
> I've tested the fix with a fedora docker container that had `autoconf`
> installed but `which`. When using `type -p` it correctly detects `autoconf`
> installed and eventually fails saying that `which` is not installed, which
> is the expected behaviour.
>
> `which` is still in use in make/autoconf/util_windows.m4. A possible future
> improvement would be to see if `which` use there could be replaced as well.
> Eventually, when no `which` uses remain, the presence check for `which`
> could be removed.
I agree that we should replace "which" with "type -p" everywhere. The 
best way to do this is probably to replace the value of $WHICH with 
"type -p". It's a bash built-in, so we can count on its presence. If you 
want to fix that as part of this bug, I'm ok with it, otherwise we 
should open a new bug to track this. I think there is also one or two 
instances of "command" recently added as (better, but not as good as 
"type -p") replacements for which.

/Magnus
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8248158
> WebRev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8248158/01/webrev/
>
> Galder



From magnus.ihse.bursie at oracle.com  Wed Jul  1 22:39:53 2020
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 2 Jul 2020 00:39:53 +0200
Subject: RFR: JDK-8248667 Need support for building native libraries located
 in the test/lib directory
Message-ID: <2ec76d11-3844-899f-1eaf-b4a18c6f1165@oracle.com>

Chris has requested help to add native test code to the test lib. From 
the bug report:

"As part of the work for JDK-8248194 I'm adding a native method to 
LingeredApp.c. The native method will be located in:

 ?? test/lib/jdk/test/lib/apps/libLingeredApp.c

However, currently there is only support for building native libs in 
test/jdk and test/hotspot/jtreg. Support is now also needed for test/lib"

This patch adds a simple lib. Since jtreg does not accept multiple roots 
for native libraries, I have to copy this to both hotspot and jdk native 
libs in the test image. The change in BuildTestLib.gmk is strictly not 
necessary, but allows more (unfortunately not all) of the testlib to be 
compiled, including LingeredApp, which allowed me to generate a proper 
.h file to base libLingeredApp.c on.

Bug: https://bugs.openjdk.java.net/browse/JDK-8248667
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8248667-build-testlib-native/webrev.01

/Magnus


From magnus.ihse.bursie at oracle.com  Wed Jul  1 22:50:13 2020
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 2 Jul 2020 00:50:13 +0200
Subject: RFR[16] 8248495: [macos] zerovm is broken due to libffi headers
 location
In-Reply-To: <D8C83D9B-898E-418A-B895-2C7CED1F335E@azul.com>
References: <00B73388-5073-46C6-9FB3-DBE426CE6B7B@azul.com>
 <000474e1-76e8-f19b-4690-5f15b8539dc7@oracle.com>
 <3A739E30-B112-4676-ABAB-D51E24C869BE@azul.com>
 <b31ef9a5-c408-0abd-d7ff-20bf07a7833d@oracle.com>
 <D8C83D9B-898E-418A-B895-2C7CED1F335E@azul.com>
Message-ID: <06A24DAE-239A-42CD-B37A-D13E6C5E6467@oracle.com>

I sent this before but it seems it did not reach the mailing list..? Resending, apologies if this arrives twice.

---

> On 2020-07-01 11:45, Vladimir Kempik wrote:
> Hello
> 
> Please take a look at updated webrev - http://cr.openjdk.java.net/~vkempik/8248495/webrev.02/
> 
> I decided to use AC_CHECK_HEADERS instead AC_CHECK_FILE as it doesn?t work in cross-compilation scenario.
> 
> libffi binary is located in absolutely standard             location, so -lffi was enough.
This looks much better. However, it is still not correct.

if test "x[$]$1SYSROOT" != "x"; then

This looks some code you have copied from elsewhere, out of context. LIB_SETUP_LIBFFI does not take any argument, so $1 will always be empty. The test you are looking for is just "x$SYSROOT".

And finally, a stylistic issue: please do not include a trailing slash on paths. If we ever need to concatenate paths, we will always add a "/" anyway. It just looks bad, and at times double slashes can cause trouble.

/Magnus


> 
> Thanks, Vladimir
> 
>> 30 ???? 2020 ?., ? 23:09, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> ???????(?):
>> 
>> 
>>> On 2020-06-30 21:08, Vladimir Kempik wrote:
>>> Hello
>>> 
>>> I agree modding  hpp files is a bad idea
>>> 
>>> Thanks for idea with setting LIBFFI_CFLAGS
>>> 
>>> here is updated webrev: http://cr.openjdk.java.net/~vkempik/8248495/webrev.01/
>> I still think you are doing this too complicated, and the wrong way around.
>>> 
>>> AC_CHECK_HEADERS ignored CFLAGS for some reason, so modding header_name for it was still needed.
>> 
>> No, AC_CHECK_HEADERS does not work that way. It knows nothing about our internal variables. How could it?
>> 
>> First of all, I still think you should let PKG_CHECK_MODULES do its magic first. If that fails, you can try compiling with AC_CHECK_HEADERS([ffi.h]), just as the code currently does.
>> 
>> Only if this fails, your workaround should kick in, before giving up completely. At this point, you should check if ${SYSROOT}/usr/include/ffi/ffi/ffi.h exists. If it does, you should set
>> LIBFFI_CFLAGS := -I${SYSROOT}/usr/include/ffi/ffi
>> 
>> and you will not need the AC_CHECK_HEADERS, since you know the ffi.h file is there, and there is a AC_LINK_IFELSE at the end to verify that everything works. You can even skip the platform checks, since this will apply to all configurations where the header file is in this odd place relative to the sysroot. (But please save a comment about where you have spotted it.)
>> 
>> However, you are not done yet.  Your patch do not address the whereabouts of the library, only the include file. I assume it might too be stored in an odd location?
>> 
>> I see that we do not follow the best-practice of separating LDFLAGS and LIBS here, so if you need to point to a non-standard location for the library, you have to do like this example:
>> 
>> LIBFFI_LIBS="-L${with_libffi}/lib -lffi"
>> 
>> Ideally, this should be explit out to an LIBFFI_LDFLAGS, but that's a change for another day, since it required changes in many places.
>> 
>> /Magnus
>> 
>> 
>> 
>>> This special case only applies to macos/clang when sysroot is set and no libffi configure options is used. (which is default case)
>>> 
>>> Thanks, Vladimir
>>> 
>>> 
>>>> 30 ???? 2020 ?., ? 19:46, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> ???????(?):
>>>> 
>>>> Vladimir,
>>>> 
>>>> This looks like it can break in other situation than your specific case.
>>>> 
>>>> It sounds like you should set LIBFFI_CFLAGS= to  -I<path to your ffi installation>, such that "<path to your ffi installation>/ffi.h" exists. In particular, the change of include path in globalDefinitions_zero.hpp looks bad.
>>>> 
>>>> /Magnus
>>>> 
>>>>> On 2020-06-30 15:33, Vladimir Kempik wrote:
>>>>> Hello
>>>>> 
>>>>> Please review this fix for zero vm building on macos.
>>>>> 
>>>>> The issue comes from the libffi, it?s headers are located inside usr/include/ffi/ folder in Macos.sdk, so it can?t be found by configure script.
>>>>> 
>>>>> If one wants to use system?s libffi and pass path to libffi via configure argument as --with-libffi-include=/usr/include/ffi, then it won?t be found by configure because clang will look exactly in /usr/include/ffi, but not in macos.sdk
>>>>> The system, at least on 10.15 doesn?t have /usr/includes at all.
>>>>> 
>>>>> This patch makes jdk to look for ffi/ffi.h header in case of Macos/clang and no --with-libffi-include argument.
>>>>> 
>>>>> However there is one issue with this patch, if --with-libffi-include passed then c++ code will still try to include <ffi/ffi.h>
>>>>> 
>>>>> I?m not sure which way is the best for such rare case. it could be possible to define include filename in configure and pass it via -D and CFLAGS to c++ code.
>>>>> 
>>>>> 
>>>>> The webrev - http://cr.openjdk.java.net/~vkempik/8248495/webrev.00/
>>>>> 
>>>>> The bug - https://bugs.openjdk.java.net/browse/JDK-8248495
>>>>> 
>>>>> Thanks, Vladimir



From jonathan.gibbons at oracle.com  Wed Jul  1 23:47:35 2020
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 1 Jul 2020 16:47:35 -0700
Subject: RFR: JDK-8248667 Need support for building native libraries
 located in the test/lib directory
In-Reply-To: <2ec76d11-3844-899f-1eaf-b4a18c6f1165@oracle.com>
References: <2ec76d11-3844-899f-1eaf-b4a18c6f1165@oracle.com>
Message-ID: <f1d9ad68-725e-7f78-1269-7ae987e44c68@oracle.com>


On 7/1/20 3:39 PM, Magnus Ihse Bursie wrote:
>
> This patch adds a simple lib. Since jtreg does not accept multiple 
> roots for native libraries,

This was a deliberate jtreg design choice, when support for native 
libraries was added, but IIRC
this decision could reasonably be changed, if that becomes desirable.

-- Jon



From magnus.ihse.bursie at oracle.com  Thu Jul  2 00:01:48 2020
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 2 Jul 2020 02:01:48 +0200
Subject: RFR: JDK-8248667 Need support for building native libraries
 located in the test/lib directory
In-Reply-To: <f1d9ad68-725e-7f78-1269-7ae987e44c68@oracle.com>
References: <2ec76d11-3844-899f-1eaf-b4a18c6f1165@oracle.com>
 <f1d9ad68-725e-7f78-1269-7ae987e44c68@oracle.com>
Message-ID: <6ed99cb6-cd64-838a-2b51-3342dfce1907@oracle.com>

On 2020-07-02 01:47, Jonathan Gibbons wrote:
>
> On 7/1/20 3:39 PM, Magnus Ihse Bursie wrote:
>>
>> This patch adds a simple lib. Since jtreg does not accept multiple 
>> roots for native libraries,
>
> This was a deliberate jtreg design choice, when support for native 
> libraries was added, but IIRC
> this decision could reasonably be changed, if that becomes desirable.
For the moment, we're talking about one small library that needs to be 
duplicated, so it's not a big issue. If this ever changes, so I think 
jtreg should be updated, I promise I'll let you know. :-)

/Magnus
>
> -- Jon
>



From galder at redhat.com  Thu Jul  2 08:13:02 2020
From: galder at redhat.com (Galder Zamarreno)
Date: Thu, 2 Jul 2020 10:13:02 +0200
Subject: RFR: JDK-8248158 Configure fails with autoconf not found even
 though it's installed
In-Reply-To: <32d59c17-97aa-79ea-9684-329c01f80766@oracle.com>
References: <CAAcPREuoXF9rrO5YrZwYdNO6iUvQv=Yv7mPHY_OcRZ6H=7K+kg@mail.gmail.com>
 <32d59c17-97aa-79ea-9684-329c01f80766@oracle.com>
Message-ID: <CAAcPREvCLVznS4xz6VXE7LvMPJv5oJG+4uACPi9a9ZZTJ8OXsg@mail.gmail.com>

On Thu, Jul 2, 2020 at 2:30 AM Magnus Ihse Bursie <
magnus.ihse.bursie at oracle.com> wrote:

>
>
> On 2020-07-01 12:05, Galder Zamarreno wrote:
> > Using `which` to check whether commands exist can result in confusing
> > errors when `which` itself is not installed in the system. This is the
> case
> > with `autoconf`, where if `autoconf` is present but `which` isn't, the
> > build system says that `autoconf` is missing, when in reality it is
> `which`
> > which is missing. The fix switches autoconf uses of `which` for `type -p`
> > instead, which is a Bash built-in command.
> >
> > I've tested the fix with a fedora docker container that had `autoconf`
> > installed but `which`. When using `type -p` it correctly detects
> `autoconf`
> > installed and eventually fails saying that `which` is not installed,
> which
> > is the expected behaviour.
> >
> > `which` is still in use in make/autoconf/util_windows.m4. A possible
> future
> > improvement would be to see if `which` use there could be replaced as
> well.
> > Eventually, when no `which` uses remain, the presence check for `which`
> > could be removed.
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8248158
> > WebRev:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8248158/01/webrev/
> You don't need the grep part. "type -p" is well-defined to return
> nothing, or the path to the binary. The grep was needed for which on
> solaris, which returned this as an error message when a binary was not
> found, instead of nothing.
>

Thanks for the info.

I've updated my local changes and it worked as expected within the docker
container.


>
> /Magnus
> >
> > Galder
>
>


From galder at redhat.com  Thu Jul  2 08:11:40 2020
From: galder at redhat.com (Galder Zamarreno)
Date: Thu, 2 Jul 2020 10:11:40 +0200
Subject: RFR: JDK-8248158 Configure fails with autoconf not found even
 though it's installed
In-Reply-To: <5b25d03a-675f-072a-5772-2e2b03739484@oracle.com>
References: <CAAcPREuoXF9rrO5YrZwYdNO6iUvQv=Yv7mPHY_OcRZ6H=7K+kg@mail.gmail.com>
 <5b25d03a-675f-072a-5772-2e2b03739484@oracle.com>
Message-ID: <CAAcPREub_iqDQJRRnsD7H-a43fzA8m1WgpxkdYGfr5DL247k+g@mail.gmail.com>

On Thu, Jul 2, 2020 at 12:37 AM Magnus Ihse Bursie <
magnus.ihse.bursie at oracle.com> wrote:

>
>
> On 2020-07-01 12:05, Galder Zamarreno wrote:
> > Using `which` to check whether commands exist can result in confusing
> > errors when `which` itself is not installed in the system. This is the
> case
> > with `autoconf`, where if `autoconf` is present but `which` isn't, the
> > build system says that `autoconf` is missing, when in reality it is
> `which`
> > which is missing. The fix switches autoconf uses of `which` for `type -p`
> > instead, which is a Bash built-in command.
> >
> > I've tested the fix with a fedora docker container that had `autoconf`
> > installed but `which`. When using `type -p` it correctly detects
> `autoconf`
> > installed and eventually fails saying that `which` is not installed,
> which
> > is the expected behaviour.
> >
> > `which` is still in use in make/autoconf/util_windows.m4. A possible
> future
> > improvement would be to see if `which` use there could be replaced as
> well.
> > Eventually, when no `which` uses remain, the presence check for `which`
> > could be removed.
> I agree that we should replace "which" with "type -p" everywhere. The
> best way to do this is probably to replace the value of $WHICH with
> "type -p".


Hmmm, not so sure about doing it this way.

$WHICH variable appears to be set when it checks for the presence of
`which`. So, if you don't need `which` any more, you can stop checking for
the presence and not set the variable in the first place.

I'd just try to replace $WHICH usages for "type -p" directly.


> It's a bash built-in, so we can count on its presence. If you
> want to fix that as part of this bug, I'm ok with it,


Happy to do it as part of this.


> otherwise we
> should open a new bug to track this. I think there is also one or two
> instances of "command" recently added as (better, but not as good as
> "type -p") replacements for which.
>
> /Magnus
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8248158
> > WebRev:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8248158/01/webrev/
> >
> > Galder
>
>


From galder at redhat.com  Thu Jul  2 08:22:35 2020
From: galder at redhat.com (Galder Zamarreno)
Date: Thu, 2 Jul 2020 10:22:35 +0200
Subject: RFR: JDK-8248158 Configure fails with autoconf not found even
 though it's installed
In-Reply-To: <5b25d03a-675f-072a-5772-2e2b03739484@oracle.com>
References: <CAAcPREuoXF9rrO5YrZwYdNO6iUvQv=Yv7mPHY_OcRZ6H=7K+kg@mail.gmail.com>
 <5b25d03a-675f-072a-5772-2e2b03739484@oracle.com>
Message-ID: <CAAcPREsPO5jGDWH+Y59rPonzOBf14+M3+t8or-wNuH6KAyOVtw@mail.gmail.com>

On Thu, Jul 2, 2020 at 12:37 AM Magnus Ihse Bursie <
magnus.ihse.bursie at oracle.com> wrote:

>
>
> On 2020-07-01 12:05, Galder Zamarreno wrote:
> > Using `which` to check whether commands exist can result in confusing
> > errors when `which` itself is not installed in the system. This is the
> case
> > with `autoconf`, where if `autoconf` is present but `which` isn't, the
> > build system says that `autoconf` is missing, when in reality it is
> `which`
> > which is missing. The fix switches autoconf uses of `which` for `type -p`
> > instead, which is a Bash built-in command.
> >
> > I've tested the fix with a fedora docker container that had `autoconf`
> > installed but `which`. When using `type -p` it correctly detects
> `autoconf`
> > installed and eventually fails saying that `which` is not installed,
> which
> > is the expected behaviour.
> >
> > `which` is still in use in make/autoconf/util_windows.m4. A possible
> future
> > improvement would be to see if `which` use there could be replaced as
> well.
> > Eventually, when no `which` uses remain, the presence check for `which`
> > could be removed.
> I agree that we should replace "which" with "type -p" everywhere. The
> best way to do this is probably to replace the value of $WHICH with
> "type -p". It's a bash built-in, so we can count on its presence. If you
> want to fix that as part of this bug, I'm ok with it, otherwise we
> should open a new bug to track this. I think there is also one or two
> instances of "command" recently added as (better, but not as good as
> "type -p") replacements for which.
>

I discovered one place in util.m4 where command was being used.

There are other places outside of make/ where command is used but I feel
those are a bit out of scope here.

My main objective is that from a configure perspective, we'd try to reduce
the number of dependencies needed to build things.

I'll send an updated webrev shortly.


>
> /Magnus
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8248158
> > WebRev:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8248158/01/webrev/
> >
> > Galder
>
>


From vkempik at azul.com  Thu Jul  2 09:13:45 2020
From: vkempik at azul.com (Vladimir Kempik)
Date: Thu, 2 Jul 2020 09:13:45 +0000
Subject: RFR[16] 8248495: [macos] zerovm is broken due to libffi headers
 location
In-Reply-To: <4e732b28-0851-6dae-f457-781362f7c333@oracle.com>
References: <00B73388-5073-46C6-9FB3-DBE426CE6B7B@azul.com>
 <000474e1-76e8-f19b-4690-5f15b8539dc7@oracle.com>
 <3A739E30-B112-4676-ABAB-D51E24C869BE@azul.com>
 <b31ef9a5-c408-0abd-d7ff-20bf07a7833d@oracle.com>
 <D8C83D9B-898E-418A-B895-2C7CED1F335E@azul.com>
 <4e732b28-0851-6dae-f457-781362f7c333@oracle.com>
Message-ID: <179BDD63-69BE-4F60-9837-F9E8CBECA72E@azul.com>

Hello
Thanks for looking into this
Here is updated webrev.

http://cr.openjdk.java.net/~vkempik/8248495/webrev.03/

Regards, Vladimir.

> 1 ???? 2020 ?., ? 21:59, Erik Joelsson <erik.joelsson at oracle.com> ???????(?):
> 
> I think this looks ok, but would like Magnus' input as he is already involved in this review.
> 
> /Erik
> 
> On 2020-07-01 02:45, Vladimir Kempik wrote:
>> Hello
>> 
>> Please take a look at updated webrev - http://cr.openjdk.java.net/~vkempik/8248495/webrev.02/ <http://cr.openjdk.java.net/~vkempik/8248495/webrev.02/>
>> 
>> I decided to use AC_CHECK_HEADERS instead AC_CHECK_FILE as it doesn?t work in cross-compilation scenario.
>> 
>> libffi binary is located in absolutely standard location, so -lffi was enough.
>> 
>> Thanks, Vladimir
>> 
>>> 30 ???? 2020 ?., ? 23:09, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> ???????(?):
>>> 
>>> 
>>> On 2020-06-30 21:08, Vladimir Kempik wrote:
>>>> Hello
>>>> 
>>>> I agree modding  hpp files is a bad idea
>>>> 
>>>> Thanks for idea with setting LIBFFI_CFLAGS
>>>> 
>>>> here is updated webrev: http://cr.openjdk.java.net/~vkempik/8248495/webrev.01/
>>> I still think you are doing this too complicated, and the wrong way around.
>>>> AC_CHECK_HEADERS ignored CFLAGS for some reason, so modding header_name for it was still needed.
>>> No, AC_CHECK_HEADERS does not work that way. It knows nothing about our internal variables. How could it?
>>> 
>>> First of all, I still think you should let PKG_CHECK_MODULES do its magic first. If that fails, you can try compiling with AC_CHECK_HEADERS([ffi.h]), just as the code currently does.
>>> 
>>> Only if this fails, your workaround should kick in, before giving up completely. At this point, you should check if ${SYSROOT}/usr/include/ffi/ffi/ffi.h exists. If it does, you should set
>>> LIBFFI_CFLAGS := -I${SYSROOT}/usr/include/ffi/ffi
>>> 
>>> and you will not need the AC_CHECK_HEADERS, since you know the ffi.h file is there, and there is a AC_LINK_IFELSE at the end to verify that everything works. You can even skip the platform checks, since this will apply to all configurations where the header file is in this odd place relative to the sysroot. (But please save a comment about where you have spotted it.)
>>> 
>>> However, you are not done yet.  Your patch do not address the whereabouts of the library, only the include file. I assume it might too be stored in an odd location?
>>> 
>>> I see that we do not follow the best-practice of separating LDFLAGS and LIBS here, so if you need to point to a non-standard location for the library, you have to do like this example:
>>> 
>>> LIBFFI_LIBS="-L${with_libffi}/lib -lffi"
>>> 
>>> Ideally, this should be explit out to an LIBFFI_LDFLAGS, but that's a change for another day, since it required changes in many places.
>>> 
>>> /Magnus
>>> 
>>> 
>>> 
>>>> This special case only applies to macos/clang when sysroot is set and no libffi configure options is used. (which is default case)
>>>> 
>>>> Thanks, Vladimir
>>>> 
>>>> 
>>>>> 30 ???? 2020 ?., ? 19:46, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> ???????(?):
>>>>> 
>>>>> Vladimir,
>>>>> 
>>>>> This looks like it can break in other situation than your specific case.
>>>>> 
>>>>> It sounds like you should set LIBFFI_CFLAGS= to  -I<path to your ffi installation>, such that "<path to your ffi installation>/ffi.h" exists. In particular, the change of include path in globalDefinitions_zero.hpp looks bad.
>>>>> 
>>>>> /Magnus
>>>>> 
>>>>> On 2020-06-30 15:33, Vladimir Kempik wrote:
>>>>>> Hello
>>>>>> 
>>>>>> Please review this fix for zero vm building on macos.
>>>>>> 
>>>>>> The issue comes from the libffi, it?s headers are located inside usr/include/ffi/ folder in Macos.sdk, so it can?t be found by configure script.
>>>>>> 
>>>>>> If one wants to use system?s libffi and pass path to libffi via configure argument as --with-libffi-include=/usr/include/ffi, then it won?t be found by configure because clang will look exactly in /usr/include/ffi, but not in macos.sdk
>>>>>> The system, at least on 10.15 doesn?t have /usr/includes at all.
>>>>>> 
>>>>>> This patch makes jdk to look for ffi/ffi.h header in case of Macos/clang and no --with-libffi-include argument.
>>>>>> 
>>>>>> However there is one issue with this patch, if --with-libffi-include passed then c++ code will still try to include <ffi/ffi.h>
>>>>>> 
>>>>>> I?m not sure which way is the best for such rare case. it could be possible to define include filename in configure and pass it via -D and CFLAGS to c++ code.
>>>>>> 
>>>>>> 
>>>>>> The webrev - http://cr.openjdk.java.net/~vkempik/8248495/webrev.00/
>>>>>> 
>>>>>> The bug - https://bugs.openjdk.java.net/browse/JDK-8248495
>>>>>> 
>>>>>> Thanks, Vladimir


From magnus.ihse.bursie at oracle.com  Thu Jul  2 13:21:58 2020
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 2 Jul 2020 15:21:58 +0200
Subject: RFR[16] 8248495: [macos] zerovm is broken due to libffi headers
 location
In-Reply-To: <179BDD63-69BE-4F60-9837-F9E8CBECA72E@azul.com>
References: <00B73388-5073-46C6-9FB3-DBE426CE6B7B@azul.com>
 <000474e1-76e8-f19b-4690-5f15b8539dc7@oracle.com>
 <3A739E30-B112-4676-ABAB-D51E24C869BE@azul.com>
 <b31ef9a5-c408-0abd-d7ff-20bf07a7833d@oracle.com>
 <D8C83D9B-898E-418A-B895-2C7CED1F335E@azul.com>
 <4e732b28-0851-6dae-f457-781362f7c333@oracle.com>
 <179BDD63-69BE-4F60-9837-F9E8CBECA72E@azul.com>
Message-ID: <c6fc8220-424b-1b7b-e061-55374ce6d973@oracle.com>

On 2020-07-02 11:13, Vladimir Kempik wrote:
> Hello
> Thanks for looking into this
> Here is updated webrev.
>
> http://cr.openjdk.java.net/~vkempik/8248495/webrev.03/
>
> Regards, Vladimir.
Thank you. Now it looks good.

/Magnus
>
>> 1 ???? 2020 ?., ? 21:59, Erik Joelsson <erik.joelsson at oracle.com> ???????(?):
>>
>> I think this looks ok, but would like Magnus' input as he is already involved in this review.
>>
>> /Erik
>>
>> On 2020-07-01 02:45, Vladimir Kempik wrote:
>>> Hello
>>>
>>> Please take a look at updated webrev - http://cr.openjdk.java.net/~vkempik/8248495/webrev.02/ <http://cr.openjdk.java.net/~vkempik/8248495/webrev.02/>
>>>
>>> I decided to use AC_CHECK_HEADERS instead AC_CHECK_FILE as it doesn?t work in cross-compilation scenario.
>>>
>>> libffi binary is located in absolutely standard location, so -lffi was enough.
>>>
>>> Thanks, Vladimir
>>>
>>>> 30 ???? 2020 ?., ? 23:09, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> ???????(?):
>>>>
>>>>
>>>> On 2020-06-30 21:08, Vladimir Kempik wrote:
>>>>> Hello
>>>>>
>>>>> I agree modding  hpp files is a bad idea
>>>>>
>>>>> Thanks for idea with setting LIBFFI_CFLAGS
>>>>>
>>>>> here is updated webrev: http://cr.openjdk.java.net/~vkempik/8248495/webrev.01/
>>>> I still think you are doing this too complicated, and the wrong way around.
>>>>> AC_CHECK_HEADERS ignored CFLAGS for some reason, so modding header_name for it was still needed.
>>>> No, AC_CHECK_HEADERS does not work that way. It knows nothing about our internal variables. How could it?
>>>>
>>>> First of all, I still think you should let PKG_CHECK_MODULES do its magic first. If that fails, you can try compiling with AC_CHECK_HEADERS([ffi.h]), just as the code currently does.
>>>>
>>>> Only if this fails, your workaround should kick in, before giving up completely. At this point, you should check if ${SYSROOT}/usr/include/ffi/ffi/ffi.h exists. If it does, you should set
>>>> LIBFFI_CFLAGS := -I${SYSROOT}/usr/include/ffi/ffi
>>>>
>>>> and you will not need the AC_CHECK_HEADERS, since you know the ffi.h file is there, and there is a AC_LINK_IFELSE at the end to verify that everything works. You can even skip the platform checks, since this will apply to all configurations where the header file is in this odd place relative to the sysroot. (But please save a comment about where you have spotted it.)
>>>>
>>>> However, you are not done yet.  Your patch do not address the whereabouts of the library, only the include file. I assume it might too be stored in an odd location?
>>>>
>>>> I see that we do not follow the best-practice of separating LDFLAGS and LIBS here, so if you need to point to a non-standard location for the library, you have to do like this example:
>>>>
>>>> LIBFFI_LIBS="-L${with_libffi}/lib -lffi"
>>>>
>>>> Ideally, this should be explit out to an LIBFFI_LDFLAGS, but that's a change for another day, since it required changes in many places.
>>>>
>>>> /Magnus
>>>>
>>>>
>>>>
>>>>> This special case only applies to macos/clang when sysroot is set and no libffi configure options is used. (which is default case)
>>>>>
>>>>> Thanks, Vladimir
>>>>>
>>>>>
>>>>>> 30 ???? 2020 ?., ? 19:46, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> ???????(?):
>>>>>>
>>>>>> Vladimir,
>>>>>>
>>>>>> This looks like it can break in other situation than your specific case.
>>>>>>
>>>>>> It sounds like you should set LIBFFI_CFLAGS= to  -I<path to your ffi installation>, such that "<path to your ffi installation>/ffi.h" exists. In particular, the change of include path in globalDefinitions_zero.hpp looks bad.
>>>>>>
>>>>>> /Magnus
>>>>>>
>>>>>> On 2020-06-30 15:33, Vladimir Kempik wrote:
>>>>>>> Hello
>>>>>>>
>>>>>>> Please review this fix for zero vm building on macos.
>>>>>>>
>>>>>>> The issue comes from the libffi, it?s headers are located inside usr/include/ffi/ folder in Macos.sdk, so it can?t be found by configure script.
>>>>>>>
>>>>>>> If one wants to use system?s libffi and pass path to libffi via configure argument as --with-libffi-include=/usr/include/ffi, then it won?t be found by configure because clang will look exactly in /usr/include/ffi, but not in macos.sdk
>>>>>>> The system, at least on 10.15 doesn?t have /usr/includes at all.
>>>>>>>
>>>>>>> This patch makes jdk to look for ffi/ffi.h header in case of Macos/clang and no --with-libffi-include argument.
>>>>>>>
>>>>>>> However there is one issue with this patch, if --with-libffi-include passed then c++ code will still try to include <ffi/ffi.h>
>>>>>>>
>>>>>>> I?m not sure which way is the best for such rare case. it could be possible to define include filename in configure and pass it via -D and CFLAGS to c++ code.
>>>>>>>
>>>>>>>
>>>>>>> The webrev - http://cr.openjdk.java.net/~vkempik/8248495/webrev.00/
>>>>>>>
>>>>>>> The bug - https://bugs.openjdk.java.net/browse/JDK-8248495
>>>>>>>
>>>>>>> Thanks, Vladimir



From erik.joelsson at oracle.com  Thu Jul  2 13:57:21 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 2 Jul 2020 06:57:21 -0700
Subject: RFR: JDK-8248667 Need support for building native libraries
 located in the test/lib directory
In-Reply-To: <2ec76d11-3844-899f-1eaf-b4a18c6f1165@oracle.com>
References: <2ec76d11-3844-899f-1eaf-b4a18c6f1165@oracle.com>
Message-ID: <eaa7e9cc-6c6e-013c-0af0-a0dc3036a84e@oracle.com>

Looks good.

/Erik

On 2020-07-01 15:39, Magnus Ihse Bursie wrote:
> Chris has requested help to add native test code to the test lib. From 
> the bug report:
>
> "As part of the work for JDK-8248194 I'm adding a native method to 
> LingeredApp.c. The native method will be located in:
>
> ?? test/lib/jdk/test/lib/apps/libLingeredApp.c
>
> However, currently there is only support for building native libs in 
> test/jdk and test/hotspot/jtreg. Support is now also needed for test/lib"
>
> This patch adds a simple lib. Since jtreg does not accept multiple 
> roots for native libraries, I have to copy this to both hotspot and 
> jdk native libs in the test image. The change in BuildTestLib.gmk is 
> strictly not necessary, but allows more (unfortunately not all) of the 
> testlib to be compiled, including LingeredApp, which allowed me to 
> generate a proper .h file to base libLingeredApp.c on.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8248667
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8248667-build-testlib-native/webrev.01
>
> /Magnus


From magnus.ihse.bursie at oracle.com  Thu Jul  2 15:48:12 2020
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 2 Jul 2020 17:48:12 +0200
Subject: RFR: JDK-8248667 Need support for building native libraries
 located in the test/lib directory
In-Reply-To: <f9592459-c11f-8686-a781-d7f1c3ef3160@oracle.com>
References: <f9592459-c11f-8686-a781-d7f1c3ef3160@oracle.com>
Message-ID: <CB76569E-5DE1-4006-9A5A-DD88532FA705@oracle.com>

Sorry if you get this twice, but I seem to have problem reaching the mailing list. 

> On 2020-07-02 16:26, Chris Plummer wrote:
> Hi Mangus,
> 
> Can you leave out libLingeredApp.c. It will conflict with the version I plan on pushing.
Chris,

You can just remove it, or replace the contents with your file. The code would otherwise have needed additional guards to handle the special case of no files, which was unnecessary to add for a short transition.

/Magnus
> 
> thanks,
> 
> Chris
>> Chris has requested help to add native test code to the test lib. From 
>> the bug report:
>> 
>> "As part of the work for JDK-8248194 I'm adding a native method to 
>> LingeredApp.c. The native method will be located in:
>> 
>>     test/lib/jdk/test/lib/apps/libLingeredApp.c
>> 
>> However, currently there is only support for building native libs in 
>> test/jdk and test/hotspot/jtreg. Support is now also needed for test/lib"
>> 
>> This patch adds a simple lib. Since jtreg does not accept multiple roots 
>> for native libraries, I have to copy this to both hotspot and jdk native 
>> libs in the test image. The change in BuildTestLib.gmk is strictly not 
>> necessary, but allows more (unfortunately not all) of the testlib to be 
>> compiled, including LingeredApp, which allowed me to generate a proper 
>> .h file to base libLingeredApp.c on.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8248667
>> WebRev: 
>> http://cr.openjdk.java.net/~ihse/JDK-8248667-build-testlib-native/webrev.01
>> 
>> /Magnus



From Monica.Beckwith at microsoft.com  Thu Jul  2 21:38:07 2020
From: Monica.Beckwith at microsoft.com (Monica Beckwith)
Date: Thu, 2 Jul 2020 21:38:07 +0000
Subject: Update: JEP drafted (was: RE: [EXTERNAL] Re: [aarch64-port-dev ]
 OpenJDK extension to AArch64 and Windows)
Message-ID: <DM6PR21MB1323FA866ECB223970E4947DE56D0@DM6PR21MB1323.namprd21.prod.outlook.com>

Hello all,

Here?s our JEP: https://bugs.openjdk.java.net/browse/JDK-8248496.Thank you all so much for helping us out with the process. 

We also have refined our changesets, and we are in the process of attaching them to the umbrella bug: https://bugs.openjdk.java.net/browse/JDK-8248238.

@Dalibor Topic: I wanted to provide more details on the UI support - we have recently tested ?JFC applications and applets?[0] in the JDK `demo/jfc` directory on three different Arm64 systems[1]. I found a bug related to Vectored Exception Handling (VEH) and Structured Exception Handling (SEH). @Ludovic is involved in the VEH/SEH discussions on the mailing list. And internally, we will make sure that the changeset for `VEH for aarch64` will incorporate the changes. 

@David Holmes: I will start a new RFR with the umbrella bug ID (8248238) in the subject once we have all the changesets ready to go.

Thanks,

Monica

[0]: https://docs.oracle.com/javase/7/docs/technotes/samples/demos.html 
[1]: https://github.com/microsoft/openjdk-aarch64/blob/master/Arm64_systems.md

-----Original Message-----
From: Dalibor Topic <dalibor.topic at oracle.com> 
Sent: Friday, June 26, 2020 8:07 AM
To: Andrew Haley <aph at redhat.com>; Mario Torre <neugens at redhat.com>
Cc: Monica Beckwith <Monica.Beckwith at microsoft.com>; hotspot-runtime-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; openjdk-aarch64 <openjdk-aarch64 at microsoft.com>
Subject: [EXTERNAL] Re: [aarch64-port-dev ] OpenJDK extension to AArch64 and Windows

On 26.06.2020 14:32, Andrew Haley wrote:
> On 26/06/2020 13:18, Dalibor Topic wrote:
>> Since there is no aarch64-port repository tracking jdk/jdk yet to 
>> host the port's changes in development (and stage it for a later 
>> merge into mainline once it's ready), I assume that's going to be the 
>> first step in that case.
> 
> Given that the patches are simpler and smaller than many changes that 
> just go into mainline, is there an actual reason for a new repo?

I assume that there would be some work remaining to be done on the port, since it's not quite done yet. For example, the UI layer has not been ported, according to Microsoft, which means that the port is not really fully functional in its current state. [0]

If that's just a matter of days, then sure, I fully understand that you may not want to add a new aarch64-port repo just for that.

On the other hand, if there is a question mark over whether the port would become fully functional in the coming weeks or months, then trying to integrate the port-specific parts of it piecemeal into mainline before that the case ... would seem a bit premature to me.

In that case, an aarch64-port specific jdk/jdk staging repo might be more useful.

cheers,
dalibor topic

[0]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.reddit.com%2Fr%2Fjava%2Fcomments%2Fhf4ofr%2Fannouncing_openjdk_for_windows_10_on_arm%2Ffvvmi8g%2F&amp;data=02%7C01%7CMonica.Beckwith%40microsoft.com%7C2914f9cc69324198ff0608d819d1eca3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637287736697879904&amp;sdata=9LRrh9xmix%2BMitQ1PAQg%2F1f9nEsuMcmoKXmFtrsHa60%3D&amp;reserved=0

--
<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.oracle.com%2F&amp;data=02%7C01%7CMonica.Beckwith%40microsoft.com%7C2914f9cc69324198ff0608d819d1eca3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637287736697879904&amp;sdata=%2FbjvUvv0gpWHeRO%2BSa4%2Btxt3YY3rCf4unXLq%2B0fzvJs%3D&amp;reserved=0> Dalibor Topic Consulting Product Manager
Phone: +494089091214 <tel:+494089091214>, Mobile: +491737185961 <tel:+491737185961>, Video: dalibor.topic at oracle.com <sip:dalibor.topic at oracle.com>

Oracle Global Services Germany GmbH
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRB 246209
Gesch?ftsf?hrer: Ralf Herrmann


From magnus.ihse.bursie at oracle.com  Sun Jul  5 00:08:20 2020
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Sun, 5 Jul 2020 02:08:20 +0200
Subject: Preliminary review for new WINENV support
Message-ID: <E8774EC8-612E-4646-B223-D55ED0C0BC46@oracle.com>

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: http://cr.openjdk.java.net/~ihse/winenv-preview-1/webrev.01/

(If you prefer, you can check out the branch "ihse-winenv-branch" on http://hg.openjdk.java.net/jdk/sandbox/ instead of downloading the patch from the webrev.)

I am leaving on vacation next week, so I won't be doing any more work on this for a while, but I promise to read all emails when I get back and try to rectify all issues that are reported. This means you have some time to try it out, too. 

Here are some technical notes of what is changing, compared to the current Windows build.

The native "fixpath.exe" tool is gone. This means that we do not need to compile it during configure, which was always tricky to get right (mostly since we did not have fixpath in place to help us...).

Instead, there is a new fixpath.sh shell script, that does the same job, and more. The script is written in highly optimized shell code (yeah, I see the oxymoron) so only bash internal functionality is used, to avoid calling external tools, which is expensive on Windows. This makes the performance practically roughly at par with the native fixpath.exe.

Fixpath also has a "print" and "import" mode, apart from the traditional"exec" mode. This makes it possible to use the same tool for converting individual paths at runtime to Windows style ("print"), and it takes the logic needed to "import" paths given by the user to configure, into a format usable internally by the build system, and moves it into a centralized location in the fixpath script.

A "winenv" is defined by a quartet of variables: PATHTOOL, DRIVEPREFIX, ENVROOT and WINTEMP. For instance, for "cygwin", these are:
 PATHTOOL=cygpath
 DRIVEPREFIX=/cygdrive (typically)
 ENVROOT=C:\Cygwin64 (typically)
 WINTEMP=/tmp

These are needed for fixpath to do it's magic. Fixpath can auto-detect those, but to save on execution time they are normally detected by configure and sent as arguments to fixpath.

Detection of the Visual Studio environment has been massively simplified. Using fixpath, conversion between Windows and unix paths is not so complex anymore. The bridge Windows batch file that is needed to extract the environment variables is no longer created on the fly, but is instead stored in make/scripts/extract-vs-env.cmd. This is called with fixpath, so all arguments to it can be unix paths.

Furthermore, TOOLCHAIN_SETUP_VISUAL_STUDIO_ENV is now clearly designed to have a single responsibility, to set SYSROOT flags (and TOOLCHAIN_PATH) for the microsoft toolchain. As a result of this, it is now called from FLAGS_SETUP_SYSROOT_FLAGS. Also, the file toolchain_windows.m4 is now more correctly named toolchain_microsoft.m4. A price we had to pay for this was that the old idea that you should be able to start a "Visual Studio console" and then run configure from it to extract the variables do not work anymore. (It had not been tested for ages, and might have been broken anyway.)

Fixpath also knows about the difference between unix path lists (/foo/bar:/my/dir) and windows path lists (c:\dir;d:\data) and can convert freely and automatically between them. This furthermore means that PATH_SEP is removed, and we only use unix style (colon separated) path lists internally.

The logic automatically detects if and when .exe is needed, so EXE_SUFFIX is removed too. There are some limitations; when code needs to explicitly test for the presence of a file, the suffix needs to be correct. Also when make files check for e.g. the generated bin/java.exe, the suffix needs to be present. For this, I have introduced an EXECUTABLE_SUFFIX, that has the same value as EXE_SUFFIX -- but not the same semantics! The old code added EXE_SUFFIX here and there, not caring about if we meant "microsoft" as a toolchain or if we were running on Windows as a build platform. Clearly not well adapted for future cross-compilation.

The old ways of locating programs in configure were messy, complicated and not always correct. We used a mixture of the original autoconf macros, and our own UTIL_PATH_PROGS and UTIL_CHECK_TOOLS. These did not have very well defined semantics, and were frequently mixed up. Also, UTIL_CHECK_TOOLS required UTIL_FIXUP_EXECUTABLE tobe called afterwards, to "rewrite" the result in a second step. This was not needed after UTIL_PATH_PROGS but was frequently done anyway to "be on the safe side".

I have now replaced:
  AC_(PATH|CHECK)_(PROG|PROGS) with UTIL_LOOKUP_PROGS
  AC_(PATH|CHECK)_(TOOL|TOOLS) with UTIL_LOOKUP_TOOLCHAIN_PROGS

This is actually almost the same semantic, but unless you're an autoconf aficionado, you ar not likely to understand the difference     between "PROG" and "TOOL". The only difference is that UTIL_LOOKUP_TOOLCHAIN_PROGS will try to look for "host-prefixed" tools first, when cross-compiling, and should therefore be used for all toolchain lookups.

There is also a fail-fast version of both, UTIL_REQUIRE_PROGS and UTIL_REQUIRE_TOOLCHAIN_PROGS.

UTIL_LOOKUP_PROGS is the core function, with the rest being thin wrappers around it. This function is created from scratch, to do exactly what we want, on Unix platforms and Windows. So there is no need anymore to call UTIL_FIXUP_EXECUTABLE, unless you have input from elsewhere (e.g. user flag) that you need to verify. I have also collected all this logic in a single file, util_paths.m4, moving parts from util.m4, and just removing util_windows.m4.

UTIL_LOOKUP_PROGS will use the new and nifty function UTIL_CHECK_WINENV_EXEC_TYPE, which will automatically determine if an executable needs to be prefixed by fixpath! That means that you can match and mix Windows-style and Unix-style programs however you like, with very few limitations. For instance, you can have a Linux version of the BootJDK on WSL. For this to work, the $FIXPATH prefix is now stored in the variables themselves (e.g. in $CC), rather than added as @FIXPATH@ in spec.gmk.in. This has generally worked out OK, but caused some headaches when the code thought that $CC (etc) was not a way to launch a program, but was a file that could be tested for existence, etc.

I reintroduced support for msys2. This was mostly free, since msys2 is so close to cygwin (which msys never where). To underline the difference, I renamed the winenv windows.msys2 (instead of windows.msys). Msys (version 1) will never be supported in modern OpenJDK due to critical packages being far too old, and not updated. I also clearly separate between WSL1 (which is using a kernel emulation layer, somewhat like Wine) and WSL2 (which is using a Hyper-V VM to run an actual Linux kernel), as windows.wsl1 and windows.wsl2.

I have also done a ton of small fixes, to make things more convenient and smooth when working in these winenvs. I have adjusted the output from configure to be less verbose and more streamlined. Overall, a lot of odd code in configure has been removed. A few changes that are strictly unneeded for this patch has also been included; mostly removal of dead code I came across, and a few fixes for additional debuggability that I needed when developing this patch, like ExecuteithLog.

I have also temporarily disabled the javac server, and building without absolute paths. I believe a better way forward is to address these with improved functionality in separate patches, instead of trying to work around the issues introduced by them in this patch.

I have done substantial testing of the core functionality (building jdk-images) on Cygwin, Msys2 and WSL2, both on my personal machine and on Oracle's CI system. The performance on Cygwin (which we use for our CI builds) is roughly on par with the old Cygwin performance, but the WSL1 performance is roughly 20% faster, so I think we should investigate if it is possible for us to switch to WSL1. Everything seems stable so far, but more testing is definitely needed. I have also not even started testing autxillary     functionality, such as the compare script, IDE project file generation etc.

However, the big disappointment in all of this is WSL2. That was the main driver that got me started on this rewrite. But it turned out that WSL2 is still very immature. :-( There are lot of issues, like stdout and stderr getting messed up, time synchronization issues causing make to complain about "Clock skew detected", extreme slowness when accessing disks cross the OS boundary. But worst of all has been that WSL2 is *extremly* unstable. After a few calls of Window executables, I get the impression that a conversion daemon dies. All further calls to Window binaries just stalls, and the WSL2 instance is unusable until I terminate it using "wsl -t Ubuntu-2004" from a cmd shell. :-(

So the WSL2 functionality is not very well tested, since I have not been able to build it completely a single time. I do believe that everything is correct, in "theory". So in case this is something broken with my WSL2 installation, I'd encourage anyone with a WSL2 installation to try it out.

/Magnus


From Monica.Beckwith at microsoft.com  Sun Jul  5 18:34:05 2020
From: Monica.Beckwith at microsoft.com (Monica Beckwith)
Date: Sun, 5 Jul 2020 18:34:05 +0000
Subject: Preliminary review for new WINENV support
In-Reply-To: <E8774EC8-612E-4646-B223-D55ED0C0BC46@oracle.com>
References: <E8774EC8-612E-4646-B223-D55ED0C0BC46@oracle.com>
Message-ID: <DM6PR21MB132346CB9B0A4EEFE2EF1306E5680@DM6PR21MB1323.namprd21.prod.outlook.com>

Wow! Impressive work, @Magnus Ihse Bursie<mailto:magnus.ihse.bursie at oracle.com> . 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<https://aka.ms/ghei36>

________________________________
From: build-dev <build-dev-retn at openjdk.java.net> on behalf of Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>
Sent: Saturday, July 4, 2020 7:08:20 PM
To: build-dev <build-dev at openjdk.java.net>
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%2F&amp;data=02%7C01%7Cmonica.beckwith%40microsoft.com%7C78ed6cf8f63042ee176908d82077a6cf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637295045569644419&amp;sdata=EnmrU3hXkAGeXuc4h0tXeQFljPwbmiCtaz%2BU2%2BrJMbE%3D&amp;reserved=0

(If you prefer, you can check out the branch "ihse-winenv-branch" on https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.openjdk.java.net%2Fjdk%2Fsandbox%2F&amp;data=02%7C01%7Cmonica.beckwith%40microsoft.com%7C78ed6cf8f63042ee176908d82077a6cf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637295045569654420&amp;sdata=7IDqLnBCiL%2FSoSyddEabAuKsehUaRo%2BnK9pesr%2F1x50%3D&amp;reserved=0 instead of downloading the patch from the webrev.)

I am leaving on vacation next week, so I won't be doing any more work on this for a while, but I promise to read all emails when I get back and try to rectify all issues that are reported. This means you have some time to try it out, too.

Here are some technical notes of what is changing, compared to the current Windows build.

The native "fixpath.exe" tool is gone. This means that we do not need to compile it during configure, which was always tricky to get right (mostly since we did not have fixpath in place to help us...).

Instead, there is a new fixpath.sh shell script, that does the same job, and more. The script is written in highly optimized shell code (yeah, I see the oxymoron) so only bash internal functionality is used, to avoid calling external tools, which is expensive on Windows. This makes the performance practically roughly at par with the native fixpath.exe.

Fixpath also has a "print" and "import" mode, apart from the traditional"exec" mode. This makes it possible to use the same tool for converting individual paths at runtime to Windows style ("print"), and it takes the logic needed to "import" paths given by the user to configure, into a format usable internally by the build system, and moves it into a centralized location in the fixpath script.

A "winenv" is defined by a quartet of variables: PATHTOOL, DRIVEPREFIX, ENVROOT and WINTEMP. For instance, for "cygwin", these are:
 PATHTOOL=cygpath
 DRIVEPREFIX=/cygdrive (typically)
 ENVROOT=C:\Cygwin64 (typically)
 WINTEMP=/tmp

These are needed for fixpath to do it's magic. Fixpath can auto-detect those, but to save on execution time they are normally detected by configure and sent as arguments to fixpath.

Detection of the Visual Studio environment has been massively simplified. Using fixpath, conversion between Windows and unix paths is not so complex anymore. The bridge Windows batch file that is needed to extract the environment variables is no longer created on the fly, but is instead stored in make/scripts/extract-vs-env.cmd. This is called with fixpath, so all arguments to it can be unix paths.

Furthermore, TOOLCHAIN_SETUP_VISUAL_STUDIO_ENV is now clearly designed to have a single responsibility, to set SYSROOT flags (and TOOLCHAIN_PATH) for the microsoft toolchain. As a result of this, it is now called from FLAGS_SETUP_SYSROOT_FLAGS. Also, the file toolchain_windows.m4 is now more correctly named toolchain_microsoft.m4. A price we had to pay for this was that the old idea that you should be able to start a "Visual Studio console" and then run configure from it to extract the variables do not work anymore. (It had not been tested for ages, and might have been broken anyway.)

Fixpath also knows about the difference between unix path lists (/foo/bar:/my/dir) and windows path lists (c:\dir;d:\data) and can convert freely and automatically between them. This furthermore means that PATH_SEP is removed, and we only use unix style (colon separated) path lists internally.

The logic automatically detects if and when .exe is needed, so EXE_SUFFIX is removed too. There are some limitations; when code needs to explicitly test for the presence of a file, the suffix needs to be correct. Also when make files check for e.g. the generated bin/java.exe, the suffix needs to be present. For this, I have introduced an EXECUTABLE_SUFFIX, that has the same value as EXE_SUFFIX -- but not the same semantics! The old code added EXE_SUFFIX here and there, not caring about if we meant "microsoft" as a toolchain or if we were running on Windows as a build platform. Clearly not well adapted for future cross-compilation.

The old ways of locating programs in configure were messy, complicated and not always correct. We used a mixture of the original autoconf macros, and our own UTIL_PATH_PROGS and UTIL_CHECK_TOOLS. These did not have very well defined semantics, and were frequently mixed up. Also, UTIL_CHECK_TOOLS required UTIL_FIXUP_EXECUTABLE tobe called afterwards, to "rewrite" the result in a second step. This was not needed after UTIL_PATH_PROGS but was frequently done anyway to "be on the safe side".

I have now replaced:
  AC_(PATH|CHECK)_(PROG|PROGS) with UTIL_LOOKUP_PROGS
  AC_(PATH|CHECK)_(TOOL|TOOLS) with UTIL_LOOKUP_TOOLCHAIN_PROGS

This is actually almost the same semantic, but unless you're an autoconf aficionado, you ar not likely to understand the difference     between "PROG" and "TOOL". The only difference is that UTIL_LOOKUP_TOOLCHAIN_PROGS will try to look for "host-prefixed" tools first, when cross-compiling, and should therefore be used for all toolchain lookups.

There is also a fail-fast version of both, UTIL_REQUIRE_PROGS and UTIL_REQUIRE_TOOLCHAIN_PROGS.

UTIL_LOOKUP_PROGS is the core function, with the rest being thin wrappers around it. This function is created from scratch, to do exactly what we want, on Unix platforms and Windows. So there is no need anymore to call UTIL_FIXUP_EXECUTABLE, unless you have input from elsewhere (e.g. user flag) that you need to verify. I have also collected all this logic in a single file, util_paths.m4, moving parts from util.m4, and just removing util_windows.m4.

UTIL_LOOKUP_PROGS will use the new and nifty function UTIL_CHECK_WINENV_EXEC_TYPE, which will automatically determine if an executable needs to be prefixed by fixpath! That means that you can match and mix Windows-style and Unix-style programs however you like, with very few limitations. For instance, you can have a Linux version of the BootJDK on WSL. For this to work, the $FIXPATH prefix is now stored in the variables themselves (e.g. in $CC), rather than added as @FIXPATH@ in spec.gmk.in. This has generally worked out OK, but caused some headaches when the code thought that $CC (etc) was not a way to launch a program, but was a file that could be tested for existence, etc.

I reintroduced support for msys2. This was mostly free, since msys2 is so close to cygwin (which msys never where). To underline the difference, I renamed the winenv windows.msys2 (instead of windows.msys). Msys (version 1) will never be supported in modern OpenJDK due to critical packages being far too old, and not updated. I also clearly separate between WSL1 (which is using a kernel emulation layer, somewhat like Wine) and WSL2 (which is using a Hyper-V VM to run an actual Linux kernel), as windows.wsl1 and windows.wsl2.

I have also done a ton of small fixes, to make things more convenient and smooth when working in these winenvs. I have adjusted the output from configure to be less verbose and more streamlined. Overall, a lot of odd code in configure has been removed. A few changes that are strictly unneeded for this patch has also been included; mostly removal of dead code I came across, and a few fixes for additional debuggability that I needed when developing this patch, like ExecuteithLog.

I have also temporarily disabled the javac server, and building without absolute paths. I believe a better way forward is to address these with improved functionality in separate patches, instead of trying to work around the issues introduced by them in this patch.

I have done substantial testing of the core functionality (building jdk-images) on Cygwin, Msys2 and WSL2, both on my personal machine and on Oracle's CI system. The performance on Cygwin (which we use for our CI builds) is roughly on par with the old Cygwin performance, but the WSL1 performance is roughly 20% faster, so I think we should investigate if it is possible for us to switch to WSL1. Everything seems stable so far, but more testing is definitely needed. I have also not even started testing autxillary     functionality, such as the compare script, IDE project file generation etc.

However, the big disappointment in all of this is WSL2. That was the main driver that got me started on this rewrite. But it turned out that WSL2 is still very immature. :-( There are lot of issues, like stdout and stderr getting messed up, time synchronization issues causing make to complain about "Clock skew detected", extreme slowness when accessing disks cross the OS boundary. But worst of all has been that WSL2 is *extremly* unstable. After a few calls of Window executables, I get the impression that a conversion daemon dies. All further calls to Window binaries just stalls, and the WSL2 instance is unusable until I terminate it using "wsl -t Ubuntu-2004" from a cmd shell. :-(

So the WSL2 functionality is not very well tested, since I have not been able to build it completely a single time. I do believe that everything is correct, in "theory". So in case this is something broken with my WSL2 installation, I'd encourage anyone with a WSL2 installation to try it out.

/Magnus


From suenaga at oss.nttdata.com  Mon Jul  6 02:19:18 2020
From: suenaga at oss.nttdata.com (Yasumasa Suenaga)
Date: Mon, 6 Jul 2020 11:19:18 +0900
Subject: Preliminary review for new WINENV support
In-Reply-To: <E8774EC8-612E-4646-B223-D55ED0C0BC46@oracle.com>
References: <E8774EC8-612E-4646-B223-D55ED0C0BC46@oracle.com>
Message-ID: <38907e54-b263-3251-dc26-feb5da7cd89f@oss.nttdata.com>

Hi Magnus,

It's awesome work! I tested your patch, but I saw some errors (configure --enable-debug --with-boot-jdk=/path/to/jdk14):


1) script error
checking for gdiff... /mnt/d/test/jdk-master/build/.configure-support/generated-configure.sh: line 9989: test: /mnt/c/Program: binary operator expected
/mnt/d/test/jdk-master/build/.configure-support/generated-configure.sh: line 9993: test: /mnt/c/Program: binary operator expected
/mnt/d/test/jdk-master/build/.configure-support/generated-configure.sh: line 9989: test: too many arguments

2) warning in awk
configure: Found potential Boot JDK using configure arguments
gawk: cmd. line:1: warning: regexp escape sequence `\"' is not a known regexp operator
checking for Boot JDK... /mnt/c/java/jdk-14.0.1

3) command not found at fixpath.sh (it happens on `make images`)
/mnt/d/test/jdk-master/make/scripts/fixpath.sh: line 402: /mnt/d/test/jdk-master/build/windows-x86_64-server-fastdebug/jdk/bin/java: No such file or directory


I fixed them with following patch, and it works fine on my WSL 1.

```
diff --git a/make/autoconf/boot-jdk.m4 b/make/autoconf/boot-jdk.m4
index 7059558b2..db73eba15 100644
--- a/make/autoconf/boot-jdk.m4
+++ b/make/autoconf/boot-jdk.m4
@@ -77,7 +77,7 @@ AC_DEFUN([BOOTJDK_DO_CHECK],
            # Additional [] needed to keep m4 from mangling shell constructs.
            java_to_test="$BOOT_JDK/bin/java"
            UTIL_FIXUP_EXECUTABLE(java_to_test)
-          [ BOOT_JDK_VERSION=`$java_to_test $USER_BOOT_JDK_OPTIONS -version 2>&1 | $AWK '/version \"[0-9a-zA-Z\._\-]+\"/{print $ 0; exit;}'` ]
+          [ BOOT_JDK_VERSION=`$java_to_test $USER_BOOT_JDK_OPTIONS -version 2>&1 | $AWK '/version "[0-9a-zA-Z\._\-]+"/{print $ 0; exit;}'` ]
            if [ [[ "$BOOT_JDK_VERSION" =~ "Picked up" ]] ]; then
              AC_MSG_NOTICE([You have _JAVA_OPTIONS or JAVA_TOOL_OPTIONS set. This can mess up the build. Please use --with-boot-jdk-jvmargs instead.])
              AC_MSG_NOTICE([Java reports: "$BOOT_JDK_VERSION".])
diff --git a/make/autoconf/util_paths.m4 b/make/autoconf/util_paths.m4
index 8dec82fdc..3d20d1700 100644
--- a/make/autoconf/util_paths.m4
+++ b/make/autoconf/util_paths.m4
@@ -377,11 +377,11 @@ AC_DEFUN([UTIL_LOOKUP_PROGS],
              continue
            fi
            full_path="$elem/$name"
-          if test ! -e $full_path && test "x$OPENJDK_BUILD_OS" = "xwindows"; then
+          if test ! -e "$full_path" && test "x$OPENJDK_BUILD_OS" = "xwindows"; then
              # Try again with .exe
              full_path="$elem/$name.exe"
            fi
-          if test -e $full_path; then
+          if test -e "$full_path"; then
              $1="$full_path"
              UTIL_FIXUP_EXECUTABLE($1, $3)
              result="[$]$1"
diff --git a/make/scripts/fixpath.sh b/make/scripts/fixpath.sh
index 14eacbec6..f8293a798 100644
--- a/make/scripts/fixpath.sh
+++ b/make/scripts/fixpath.sh
@@ -393,6 +393,10 @@ function exec_command_line() {
      fi
    done

+  if [ ! -e "$command" ]; then
+    command="$command".exe
+  fi
+
    # Now execute it
    if [[ -v DEBUG_FIXPATH ]]; then
      echo fixpath: debug: "$command" "${collected_args[@]}" >&2
```

I tried to build on WSL 2, but I couldn't because the process seemed to hangup.
configure script could work normally, but I saw following message on my console in the end.
I guess it is not an issue in your patch because I haven't seen it on WSL 1.

```
cat: standard output: No such file or directory
```

Also I saw LNK1158 error as following, but it might be caused by my environment - my Windows box has been installed both Visual Studio 2019 and Windows SDK.
(My PC is set locale to Japanese, sorry :)

* For target hotspot_variant-server_libjvm_objs_BUILD_LIBJVM_link:
    ????? d:\test\jdk-master\build\windows-x86_64-server-fastdebug\hotspot\variant-server\libjvm\objs\jvm.lib ??????? d:\test\jdk-master\build\windows-x86_64-server-fastdebug\hotspot\variant-server\libjvm\objs\jvm.exp ????
LINK : fatal error LNK1158: 'rc.exe' ?????????

I could solve the problem in the way the following URL indicate.

https://stackoverflow.com/questions/35215971/lnk1158-cannot-run-rc-exe-x64-visual-studio


Thanks,

Yasumasa


On 2020/07/05 9:08, Magnus Ihse Bursie wrote:
> 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: http://cr.openjdk.java.net/~ihse/winenv-preview-1/webrev.01/
> 
> (If you prefer, you can check out the branch "ihse-winenv-branch" on http://hg.openjdk.java.net/jdk/sandbox/ instead of downloading the patch from the webrev.)
> 
> I am leaving on vacation next week, so I won't be doing any more work on this for a while, but I promise to read all emails when I get back and try to rectify all issues that are reported. This means you have some time to try it out, too.
> 
> Here are some technical notes of what is changing, compared to the current Windows build.
> 
> The native "fixpath.exe" tool is gone. This means that we do not need to compile it during configure, which was always tricky to get right (mostly since we did not have fixpath in place to help us...).
> 
> Instead, there is a new fixpath.sh shell script, that does the same job, and more. The script is written in highly optimized shell code (yeah, I see the oxymoron) so only bash internal functionality is used, to avoid calling external tools, which is expensive on Windows. This makes the performance practically roughly at par with the native fixpath.exe.
> 
> Fixpath also has a "print" and "import" mode, apart from the traditional"exec" mode. This makes it possible to use the same tool for converting individual paths at runtime to Windows style ("print"), and it takes the logic needed to "import" paths given by the user to configure, into a format usable internally by the build system, and moves it into a centralized location in the fixpath script.
> 
> A "winenv" is defined by a quartet of variables: PATHTOOL, DRIVEPREFIX, ENVROOT and WINTEMP. For instance, for "cygwin", these are:
>   PATHTOOL=cygpath
>   DRIVEPREFIX=/cygdrive (typically)
>   ENVROOT=C:\Cygwin64 (typically)
>   WINTEMP=/tmp
> 
> These are needed for fixpath to do it's magic. Fixpath can auto-detect those, but to save on execution time they are normally detected by configure and sent as arguments to fixpath.
> 
> Detection of the Visual Studio environment has been massively simplified. Using fixpath, conversion between Windows and unix paths is not so complex anymore. The bridge Windows batch file that is needed to extract the environment variables is no longer created on the fly, but is instead stored in make/scripts/extract-vs-env.cmd. This is called with fixpath, so all arguments to it can be unix paths.
> 
> Furthermore, TOOLCHAIN_SETUP_VISUAL_STUDIO_ENV is now clearly designed to have a single responsibility, to set SYSROOT flags (and TOOLCHAIN_PATH) for the microsoft toolchain. As a result of this, it is now called from FLAGS_SETUP_SYSROOT_FLAGS. Also, the file toolchain_windows.m4 is now more correctly named toolchain_microsoft.m4. A price we had to pay for this was that the old idea that you should be able to start a "Visual Studio console" and then run configure from it to extract the variables do not work anymore. (It had not been tested for ages, and might have been broken anyway.)
> 
> Fixpath also knows about the difference between unix path lists (/foo/bar:/my/dir) and windows path lists (c:\dir;d:\data) and can convert freely and automatically between them. This furthermore means that PATH_SEP is removed, and we only use unix style (colon separated) path lists internally.
> 
> The logic automatically detects if and when .exe is needed, so EXE_SUFFIX is removed too. There are some limitations; when code needs to explicitly test for the presence of a file, the suffix needs to be correct. Also when make files check for e.g. the generated bin/java.exe, the suffix needs to be present. For this, I have introduced an EXECUTABLE_SUFFIX, that has the same value as EXE_SUFFIX -- but not the same semantics! The old code added EXE_SUFFIX here and there, not caring about if we meant "microsoft" as a toolchain or if we were running on Windows as a build platform. Clearly not well adapted for future cross-compilation.
> 
> The old ways of locating programs in configure were messy, complicated and not always correct. We used a mixture of the original autoconf macros, and our own UTIL_PATH_PROGS and UTIL_CHECK_TOOLS. These did not have very well defined semantics, and were frequently mixed up. Also, UTIL_CHECK_TOOLS required UTIL_FIXUP_EXECUTABLE tobe called afterwards, to "rewrite" the result in a second step. This was not needed after UTIL_PATH_PROGS but was frequently done anyway to "be on the safe side".
> 
> I have now replaced:
>    AC_(PATH|CHECK)_(PROG|PROGS) with UTIL_LOOKUP_PROGS
>    AC_(PATH|CHECK)_(TOOL|TOOLS) with UTIL_LOOKUP_TOOLCHAIN_PROGS
> 
> This is actually almost the same semantic, but unless you're an autoconf aficionado, you ar not likely to understand the difference     between "PROG" and "TOOL". The only difference is that UTIL_LOOKUP_TOOLCHAIN_PROGS will try to look for "host-prefixed" tools first, when cross-compiling, and should therefore be used for all toolchain lookups.
> 
> There is also a fail-fast version of both, UTIL_REQUIRE_PROGS and UTIL_REQUIRE_TOOLCHAIN_PROGS.
> 
> UTIL_LOOKUP_PROGS is the core function, with the rest being thin wrappers around it. This function is created from scratch, to do exactly what we want, on Unix platforms and Windows. So there is no need anymore to call UTIL_FIXUP_EXECUTABLE, unless you have input from elsewhere (e.g. user flag) that you need to verify. I have also collected all this logic in a single file, util_paths.m4, moving parts from util.m4, and just removing util_windows.m4.
> 
> UTIL_LOOKUP_PROGS will use the new and nifty function UTIL_CHECK_WINENV_EXEC_TYPE, which will automatically determine if an executable needs to be prefixed by fixpath! That means that you can match and mix Windows-style and Unix-style programs however you like, with very few limitations. For instance, you can have a Linux version of the BootJDK on WSL. For this to work, the $FIXPATH prefix is now stored in the variables themselves (e.g. in $CC), rather than added as @FIXPATH@ in spec.gmk.in. This has generally worked out OK, but caused some headaches when the code thought that $CC (etc) was not a way to launch a program, but was a file that could be tested for existence, etc.
> 
> I reintroduced support for msys2. This was mostly free, since msys2 is so close to cygwin (which msys never where). To underline the difference, I renamed the winenv windows.msys2 (instead of windows.msys). Msys (version 1) will never be supported in modern OpenJDK due to critical packages being far too old, and not updated. I also clearly separate between WSL1 (which is using a kernel emulation layer, somewhat like Wine) and WSL2 (which is using a Hyper-V VM to run an actual Linux kernel), as windows.wsl1 and windows.wsl2.
> 
> I have also done a ton of small fixes, to make things more convenient and smooth when working in these winenvs. I have adjusted the output from configure to be less verbose and more streamlined. Overall, a lot of odd code in configure has been removed. A few changes that are strictly unneeded for this patch has also been included; mostly removal of dead code I came across, and a few fixes for additional debuggability that I needed when developing this patch, like ExecuteithLog.
> 
> I have also temporarily disabled the javac server, and building without absolute paths. I believe a better way forward is to address these with improved functionality in separate patches, instead of trying to work around the issues introduced by them in this patch.
> 
> I have done substantial testing of the core functionality (building jdk-images) on Cygwin, Msys2 and WSL2, both on my personal machine and on Oracle's CI system. The performance on Cygwin (which we use for our CI builds) is roughly on par with the old Cygwin performance, but the WSL1 performance is roughly 20% faster, so I think we should investigate if it is possible for us to switch to WSL1. Everything seems stable so far, but more testing is definitely needed. I have also not even started testing autxillary     functionality, such as the compare script, IDE project file generation etc.
> 
> However, the big disappointment in all of this is WSL2. That was the main driver that got me started on this rewrite. But it turned out that WSL2 is still very immature. :-( There are lot of issues, like stdout and stderr getting messed up, time synchronization issues causing make to complain about "Clock skew detected", extreme slowness when accessing disks cross the OS boundary. But worst of all has been that WSL2 is *extremly* unstable. After a few calls of Window executables, I get the impression that a conversion daemon dies. All further calls to Window binaries just stalls, and the WSL2 instance is unusable until I terminate it using "wsl -t Ubuntu-2004" from a cmd shell. :-(
> 
> So the WSL2 functionality is not very well tested, since I have not been able to build it completely a single time. I do believe that everything is correct, in "theory". So in case this is something broken with my WSL2 installation, I'd encourage anyone with a WSL2 installation to try it out.
> 
> /Magnus
> 


From stooke at redhat.com  Mon Jul  6 20:47:52 2020
From: stooke at redhat.com (Simon Tooke)
Date: Mon, 6 Jul 2020 16:47:52 -0400
Subject: RFR: JDK-8248158 Configure fails with autoconf not found even
 though it's installed
In-Reply-To: <CAAcPREsPO5jGDWH+Y59rPonzOBf14+M3+t8or-wNuH6KAyOVtw@mail.gmail.com>
References: <CAAcPREuoXF9rrO5YrZwYdNO6iUvQv=Yv7mPHY_OcRZ6H=7K+kg@mail.gmail.com>
 <5b25d03a-675f-072a-5772-2e2b03739484@oracle.com>
 <CAAcPREsPO5jGDWH+Y59rPonzOBf14+M3+t8or-wNuH6KAyOVtw@mail.gmail.com>
Message-ID: <7ba7f5cd-abd2-3331-e836-97e769a8189d@redhat.com>

(Disclaimer: I am not a reviewer, so this is an opinion, not a review)

I have tested this on Windows and it built without issue, although the 
submit repo should be the final gate.? I'd also like to add my void to 
simply redefining 'WHICH' as it leads to less changes in the source 
code, which would make life easier should this be backported to 11u 
and/or 8u.

-Simon

On 2020-07-02 4:22 a.m., Galder Zamarreno wrote:
> On Thu, Jul 2, 2020 at 12:37 AM Magnus Ihse Bursie <
> magnus.ihse.bursie at oracle.com> wrote:
>
>>
>> On 2020-07-01 12:05, Galder Zamarreno wrote:
>>> Using `which` to check whether commands exist can result in confusing
>>> errors when `which` itself is not installed in the system. This is the
>> case
>>> with `autoconf`, where if `autoconf` is present but `which` isn't, the
>>> build system says that `autoconf` is missing, when in reality it is
>> `which`
>>> which is missing. The fix switches autoconf uses of `which` for `type -p`
>>> instead, which is a Bash built-in command.
>>>
>>> I've tested the fix with a fedora docker container that had `autoconf`
>>> installed but `which`. When using `type -p` it correctly detects
>> `autoconf`
>>> installed and eventually fails saying that `which` is not installed,
>> which
>>> is the expected behaviour.
>>>
>>> `which` is still in use in make/autoconf/util_windows.m4. A possible
>> future
>>> improvement would be to see if `which` use there could be replaced as
>> well.
>>> Eventually, when no `which` uses remain, the presence check for `which`
>>> could be removed.
>> I agree that we should replace "which" with "type -p" everywhere. The
>> best way to do this is probably to replace the value of $WHICH with
>> "type -p". It's a bash built-in, so we can count on its presence. If you
>> want to fix that as part of this bug, I'm ok with it, otherwise we
>> should open a new bug to track this. I think there is also one or two
>> instances of "command" recently added as (better, but not as good as
>> "type -p") replacements for which.
>>
> I discovered one place in util.m4 where command was being used.
>
> There are other places outside of make/ where command is used but I feel
> those are a bit out of scope here.
>
> My main objective is that from a configure perspective, we'd try to reduce
> the number of dependencies needed to build things.
>
> I'll send an updated webrev shortly.
>
>
>> /Magnus
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8248158
>>> WebRev:
>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8248158/01/webrev/
>>> Galder
>>



From kim.barrett at oracle.com  Tue Jul  7 01:10:54 2020
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 6 Jul 2020 21:10:54 -0400
Subject: RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language
 Features in HotSpot
In-Reply-To: <b1862407-8d48-a3e9-b343-99dc890d9b95@oracle.com>
References: <B98C962A-7864-446B-98ED-69068C7F00D1@oracle.com>
 <5EDE9A75.6020504@oracle.com>
 <A8A5757E-15BC-4104-83DB-6084DFF5CC81@oracle.com>
 <EFE531CD-86C7-4155-BBC9-F4B45179B9A8@oracle.com> <5EE5AB71.20505@oracle.com>
 <DA8424D0-F428-405E-891A-EAB43650F96D@oracle.com>
 <B49ADE47-FA0E-4E48-A9AB-2E9F79ED9DA7@oracle.com>
 <b1862407-8d48-a3e9-b343-99dc890d9b95@oracle.com>
Message-ID: <533C3CDA-B4D2-4809-B88E-23E19D8C98ED@oracle.com>

I just noticed that doc/building.{md,html} describes minimum toolchain versions,
so also needs to be updated.  Here?s the update, matching what?s now in the JEP:

full: https://cr.openjdk.java.net/~kbarrett/8246032/open.05/
incr: https://cr.openjdk.java.net/~kbarrett/8246032/open.05.inc/

I also deleted a discussion of a problem one might run into when building with
Visual Studio 2010, since that version is no longer relevant.



From peter.levart at gmail.com  Tue Jul  7 07:59:33 2020
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 7 Jul 2020 09:59:33 +0200
Subject: Change for 8248135: Build microbenchmarks with --enable-preview makes
 other non-preview JMH benchmarks to fail
Message-ID: <ccab9791-be7a-bb04-3575-b61acf668359@gmail.com>

Hi,


Recently I proposed and pushed a change for [1] which adds 
--enable-preview option to javac compilation of JMH microbenchmarks in 
general to enable running a benchmark that uses preview feature 
(Records). This makes the class files produced marked with version 
60.65535. The benchmark that uses preview feature executes without 
problems because it explicitly specifies the following in its code:


@Fork(value = 1, warmups = 0, jvmArgsAppend = "--enable-preview")


Recently I wanted to run JMH benchmarks for Stream ops with:


make test TEST="micro:java.util.stream.ops"


...but all of them fail to run with the following exception:


java.lang.UnsupportedClassVersionError: Preview features are not enabled 
for 
org/openjdk/bench/java/util/stream/ops/value/generated/NoneMatchShort_seq_start_jmhTest 
(class file version 60.65535). Try running with '--enable-preview'


What shall we do? Add similar annotation to all of them? Is there a way 
to specify that all micro benchmarks should be run with --enable-preview 
option passed to java?


[1] https://bugs.openjdk.java.net/browse/JDK-8248135


Regards, Peter




From david.holmes at oracle.com  Tue Jul  7 08:13:04 2020
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 7 Jul 2020 18:13:04 +1000
Subject: Change for 8248135: Build microbenchmarks with --enable-preview
 makes other non-preview JMH benchmarks to fail
In-Reply-To: <ccab9791-be7a-bb04-3575-b61acf668359@gmail.com>
References: <ccab9791-be7a-bb04-3575-b61acf668359@gmail.com>
Message-ID: <34646b79-3a4a-6068-0bcd-c813989d053f@oracle.com>

Hi Peter,

cc Claes

On 7/07/2020 5:59 pm, Peter Levart wrote:
> Hi,
> 
> 
> Recently I proposed and pushed a change for [1] which adds 
> --enable-preview option to javac compilation of JMH microbenchmarks in 
> general to enable running a benchmark that uses preview feature 
> (Records). This makes the class files produced marked with version 
> 60.65535. The benchmark that uses preview feature executes without 
> problems because it explicitly specifies the following in its code:
> 
> 
> @Fork(value = 1, warmups = 0, jvmArgsAppend = "--enable-preview")
> 
> 
> Recently I wanted to run JMH benchmarks for Stream ops with:
> 
> 
> make test TEST="micro:java.util.stream.ops"
> 
> 
> ...but all of them fail to run with the following exception:
> 
> 
> java.lang.UnsupportedClassVersionError: Preview features are not enabled 
> for 
> org/openjdk/bench/java/util/stream/ops/value/generated/NoneMatchShort_seq_start_jmhTest 
> (class file version 60.65535). Try running with '--enable-preview'
> 
> 
> What shall we do? Add similar annotation to all of them? Is there a way 
> to specify that all micro benchmarks should be run with --enable-preview 
> option passed to java?

So this breaks running all non-preview using benchmarks? If so I say we 
need to backout the change for 8248135 while a proper solution is found.

David
-----

> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8248135
> 
> 
> Regards, Peter
> 
> 


From peter.levart at gmail.com  Tue Jul  7 08:23:13 2020
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 7 Jul 2020 10:23:13 +0200
Subject: Change for 8248135: Build microbenchmarks with --enable-preview
 makes other non-preview JMH benchmarks to fail
In-Reply-To: <34646b79-3a4a-6068-0bcd-c813989d053f@oracle.com>
References: <ccab9791-be7a-bb04-3575-b61acf668359@gmail.com>
 <34646b79-3a4a-6068-0bcd-c813989d053f@oracle.com>
Message-ID: <8d9a3b30-436b-137d-f540-de1417695c7c@gmail.com>


On 7/7/20 10:13 AM, David Holmes wrote:
> Hi Peter,
>
> cc Claes
>
> On 7/07/2020 5:59 pm, Peter Levart wrote:
>> Hi,
>>
>>
>> Recently I proposed and pushed a change for [1] which adds 
>> --enable-preview option to javac compilation of JMH microbenchmarks 
>> in general to enable running a benchmark that uses preview feature 
>> (Records). This makes the class files produced marked with version 
>> 60.65535. The benchmark that uses preview feature executes without 
>> problems because it explicitly specifies the following in its code:
>>
>>
>> @Fork(value = 1, warmups = 0, jvmArgsAppend = "--enable-preview")
>>
>>
>> Recently I wanted to run JMH benchmarks for Stream ops with:
>>
>>
>> make test TEST="micro:java.util.stream.ops"
>>
>>
>> ...but all of them fail to run with the following exception:
>>
>>
>> java.lang.UnsupportedClassVersionError: Preview features are not 
>> enabled for 
>> org/openjdk/bench/java/util/stream/ops/value/generated/NoneMatchShort_seq_start_jmhTest 
>> (class file version 60.65535). Try running with '--enable-preview'
>>
>>
>> What shall we do? Add similar annotation to all of them? Is there a 
>> way to specify that all micro benchmarks should be run with 
>> --enable-preview option passed to java?
>
> So this breaks running all non-preview using benchmarks? If so I say 
> we need to backout the change for 8248135 while a proper solution is 
> found.


I guess it does break (at least the way I tried to run them). The 
problem is that this little change:


--- a/make/test/BuildMicrobenchmark.gmk??? Wed Jun 24 01:02:19 2020 +0200
+++ b/make/test/BuildMicrobenchmark.gmk??? Wed Jun 24 11:05:09 2020 +0200
@@ -90,10 +90,11 @@
 ???? TARGET_RELEASE := $(TARGET_RELEASE_NEWJDK_UPGRADED), \
 ???? SMALL_JAVA := false, \
 ???? CLASSPATH := $(MICROBENCHMARK_CLASSPATH), \
-??? DISABLED_WARNINGS := processing rawtypes cast serial, \
+??? DISABLED_WARNINGS := processing rawtypes cast serial preview, \
 ???? SRC := $(MICROBENCHMARK_SRC), \
 ???? BIN := $(MICROBENCHMARK_CLASSES), \
 ???? JAVA_FLAGS := --add-modules jdk.unsupported --limit-modules 
java.management, \
+??? JAVAC_FLAGS := --enable-preview, \
 ?))


...was pushed as part of larger fix for 8247532 which has already been 
forward and backported. So I think backing out the whole patch (which is 
perfectly OK by itself) would cause more problems then fixing this 
particular problem in a followup, given that we can find a fix quickly. 
Its has been 14 days since the above was pushed and nobody noticed until 
now, so I guess this is not a big problem?


Regards, Peter



>
> David
> -----
>
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8248135
>>
>>
>> Regards, Peter
>>
>>


From peter.levart at gmail.com  Tue Jul  7 08:41:38 2020
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 7 Jul 2020 10:41:38 +0200
Subject: Change for 8248135: Build microbenchmarks with --enable-preview
 makes other non-preview JMH benchmarks to fail
In-Reply-To: <8d9a3b30-436b-137d-f540-de1417695c7c@gmail.com>
References: <ccab9791-be7a-bb04-3575-b61acf668359@gmail.com>
 <34646b79-3a4a-6068-0bcd-c813989d053f@oracle.com>
 <8d9a3b30-436b-137d-f540-de1417695c7c@gmail.com>
Message-ID: <d53ceed3-a412-918b-37f9-2b28f0fd73ef@gmail.com>

A quick work-around for anyone wanting to run the microbenchmarks is to 
pass --enable-preview explicitly. For example:


make test TEST="micro:java.util.stream.ops" 
MICRO="JAVA_OPTIONS=--enable-preview"


Regards, Peter


On 7/7/20 10:23 AM, Peter Levart wrote:
>
> On 7/7/20 10:13 AM, David Holmes wrote:
>> Hi Peter,
>>
>> cc Claes
>>
>> On 7/07/2020 5:59 pm, Peter Levart wrote:
>>> Hi,
>>>
>>>
>>> Recently I proposed and pushed a change for [1] which adds 
>>> --enable-preview option to javac compilation of JMH microbenchmarks 
>>> in general to enable running a benchmark that uses preview feature 
>>> (Records). This makes the class files produced marked with version 
>>> 60.65535. The benchmark that uses preview feature executes without 
>>> problems because it explicitly specifies the following in its code:
>>>
>>>
>>> @Fork(value = 1, warmups = 0, jvmArgsAppend = "--enable-preview")
>>>
>>>
>>> Recently I wanted to run JMH benchmarks for Stream ops with:
>>>
>>>
>>> make test TEST="micro:java.util.stream.ops"
>>>
>>>
>>> ...but all of them fail to run with the following exception:
>>>
>>>
>>> java.lang.UnsupportedClassVersionError: Preview features are not 
>>> enabled for 
>>> org/openjdk/bench/java/util/stream/ops/value/generated/NoneMatchShort_seq_start_jmhTest 
>>> (class file version 60.65535). Try running with '--enable-preview'
>>>
>>>
>>> What shall we do? Add similar annotation to all of them? Is there a 
>>> way to specify that all micro benchmarks should be run with 
>>> --enable-preview option passed to java?
>>
>> So this breaks running all non-preview using benchmarks? If so I say 
>> we need to backout the change for 8248135 while a proper solution is 
>> found.
>
>
> I guess it does break (at least the way I tried to run them). The 
> problem is that this little change:
>
>
> --- a/make/test/BuildMicrobenchmark.gmk??? Wed Jun 24 01:02:19 2020 +0200
> +++ b/make/test/BuildMicrobenchmark.gmk??? Wed Jun 24 11:05:09 2020 +0200
> @@ -90,10 +90,11 @@
> ???? TARGET_RELEASE := $(TARGET_RELEASE_NEWJDK_UPGRADED), \
> ???? SMALL_JAVA := false, \
> ???? CLASSPATH := $(MICROBENCHMARK_CLASSPATH), \
> -??? DISABLED_WARNINGS := processing rawtypes cast serial, \
> +??? DISABLED_WARNINGS := processing rawtypes cast serial preview, \
> ???? SRC := $(MICROBENCHMARK_SRC), \
> ???? BIN := $(MICROBENCHMARK_CLASSES), \
> ???? JAVA_FLAGS := --add-modules jdk.unsupported --limit-modules 
> java.management, \
> +??? JAVAC_FLAGS := --enable-preview, \
> ?))
>
>
> ...was pushed as part of larger fix for 8247532 which has already been 
> forward and backported. So I think backing out the whole patch (which 
> is perfectly OK by itself) would cause more problems then fixing this 
> particular problem in a followup, given that we can find a fix 
> quickly. Its has been 14 days since the above was pushed and nobody 
> noticed until now, so I guess this is not a big problem?
>
>
> Regards, Peter
>
>
>
>>
>> David
>> -----
>>
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8248135
>>>
>>>
>>> Regards, Peter
>>>
>>>


From peter.levart at gmail.com  Tue Jul  7 08:59:13 2020
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 7 Jul 2020 10:59:13 +0200
Subject: Change for 8248135: Build microbenchmarks with --enable-preview
 makes other non-preview JMH benchmarks to fail
In-Reply-To: <d53ceed3-a412-918b-37f9-2b28f0fd73ef@gmail.com>
References: <ccab9791-be7a-bb04-3575-b61acf668359@gmail.com>
 <34646b79-3a4a-6068-0bcd-c813989d053f@oracle.com>
 <8d9a3b30-436b-137d-f540-de1417695c7c@gmail.com>
 <d53ceed3-a412-918b-37f9-2b28f0fd73ef@gmail.com>
Message-ID: <bc4209bd-85e8-5653-eec1-5296eca71381@gmail.com>

The following patch seems to fix this problem:


===================================================================
--- make/RunTests.gmk??? (revision 
60064:00a964b6ab716706f0deab6dd04b43f31b1939c0)
+++ make/RunTests.gmk??? (revision 60064+:00a964b6ab71+)
@@ -693,6 +693,9 @@
 ?? # Set library path for native dependencies
 ?? $1_JMH_JVM_ARGS := -Djava.library.path=$$(TEST_IMAGE_DIR)/micro/native

+? # Micro benchmarks are compiled with --enable-preview so we must run 
them with --enable-preview
+? $1_JMH_JVM_ARGS += --enable-preview
+
 ?? ifneq ($$(MICRO_VM_OPTIONS)$$(MICRO_JAVA_OPTIONS), )
 ???? $1_JMH_JVM_ARGS += $$(MICRO_VM_OPTIONS) $$(MICRO_JAVA_OPTIONS)
 ?? endif


...I can prepare a formal RFR quickly if this is the way to go.


Regards, Peter


On 7/7/20 10:41 AM, Peter Levart wrote:
> A quick work-around for anyone wanting to run the microbenchmarks is 
> to pass --enable-preview explicitly. For example:
>
>
> make test TEST="micro:java.util.stream.ops" 
> MICRO="JAVA_OPTIONS=--enable-preview"
>
>
> Regards, Peter
>
>
> On 7/7/20 10:23 AM, Peter Levart wrote:
>>
>> On 7/7/20 10:13 AM, David Holmes wrote:
>>> Hi Peter,
>>>
>>> cc Claes
>>>
>>> On 7/07/2020 5:59 pm, Peter Levart wrote:
>>>> Hi,
>>>>
>>>>
>>>> Recently I proposed and pushed a change for [1] which adds 
>>>> --enable-preview option to javac compilation of JMH microbenchmarks 
>>>> in general to enable running a benchmark that uses preview feature 
>>>> (Records). This makes the class files produced marked with version 
>>>> 60.65535. The benchmark that uses preview feature executes without 
>>>> problems because it explicitly specifies the following in its code:
>>>>
>>>>
>>>> @Fork(value = 1, warmups = 0, jvmArgsAppend = "--enable-preview")
>>>>
>>>>
>>>> Recently I wanted to run JMH benchmarks for Stream ops with:
>>>>
>>>>
>>>> make test TEST="micro:java.util.stream.ops"
>>>>
>>>>
>>>> ...but all of them fail to run with the following exception:
>>>>
>>>>
>>>> java.lang.UnsupportedClassVersionError: Preview features are not 
>>>> enabled for 
>>>> org/openjdk/bench/java/util/stream/ops/value/generated/NoneMatchShort_seq_start_jmhTest 
>>>> (class file version 60.65535). Try running with '--enable-preview'
>>>>
>>>>
>>>> What shall we do? Add similar annotation to all of them? Is there a 
>>>> way to specify that all micro benchmarks should be run with 
>>>> --enable-preview option passed to java?
>>>
>>> So this breaks running all non-preview using benchmarks? If so I say 
>>> we need to backout the change for 8248135 while a proper solution is 
>>> found.
>>
>>
>> I guess it does break (at least the way I tried to run them). The 
>> problem is that this little change:
>>
>>
>> --- a/make/test/BuildMicrobenchmark.gmk??? Wed Jun 24 01:02:19 2020 
>> +0200
>> +++ b/make/test/BuildMicrobenchmark.gmk??? Wed Jun 24 11:05:09 2020 
>> +0200
>> @@ -90,10 +90,11 @@
>> ???? TARGET_RELEASE := $(TARGET_RELEASE_NEWJDK_UPGRADED), \
>> ???? SMALL_JAVA := false, \
>> ???? CLASSPATH := $(MICROBENCHMARK_CLASSPATH), \
>> -??? DISABLED_WARNINGS := processing rawtypes cast serial, \
>> +??? DISABLED_WARNINGS := processing rawtypes cast serial preview, \
>> ???? SRC := $(MICROBENCHMARK_SRC), \
>> ???? BIN := $(MICROBENCHMARK_CLASSES), \
>> ???? JAVA_FLAGS := --add-modules jdk.unsupported --limit-modules 
>> java.management, \
>> +??? JAVAC_FLAGS := --enable-preview, \
>> ?))
>>
>>
>> ...was pushed as part of larger fix for 8247532 which has already 
>> been forward and backported. So I think backing out the whole patch 
>> (which is perfectly OK by itself) would cause more problems then 
>> fixing this particular problem in a followup, given that we can find 
>> a fix quickly. Its has been 14 days since the above was pushed and 
>> nobody noticed until now, so I guess this is not a big problem?
>>
>>
>> Regards, Peter
>>
>>
>>
>>>
>>> David
>>> -----
>>>
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8248135
>>>>
>>>>
>>>> Regards, Peter
>>>>
>>>>


From chris.hegarty at oracle.com  Tue Jul  7 09:00:34 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 7 Jul 2020 10:00:34 +0100
Subject: Change for 8248135: Build microbenchmarks with --enable-preview
 makes other non-preview JMH benchmarks to fail
In-Reply-To: <d53ceed3-a412-918b-37f9-2b28f0fd73ef@gmail.com>
References: <ccab9791-be7a-bb04-3575-b61acf668359@gmail.com>
 <34646b79-3a4a-6068-0bcd-c813989d053f@oracle.com>
 <8d9a3b30-436b-137d-f540-de1417695c7c@gmail.com>
 <d53ceed3-a412-918b-37f9-2b28f0fd73ef@gmail.com>
Message-ID: <4F7F6264-98FA-45DA-8E7C-578C6544682C@oracle.com>

Peter,

8248429 [1] tracks this issue, right?

There was a recent thread on build-dev relating to this, in the form of an RFR from Jorn :
  https://mail.openjdk.java.net/pipermail/build-dev/2020-June/thread.html#27804

Some great discussion was had, but I?m not sure that a conclusion was reached yet.

8248429 is the same issue, right?

-Chris.

[1] https://bugs.openjdk.java.net/browse/JDK-8248429

> On 7 Jul 2020, at 09:41, Peter Levart <peter.levart at gmail.com> wrote:
> 
> A quick work-around for anyone wanting to run the microbenchmarks is to pass --enable-preview explicitly. For example:
> 
> 
> make test TEST="micro:java.util.stream.ops" MICRO="JAVA_OPTIONS=--enable-preview"
> 
> 
> Regards, Peter
> 
> 
> On 7/7/20 10:23 AM, Peter Levart wrote:
>> 
>> On 7/7/20 10:13 AM, David Holmes wrote:
>>> Hi Peter,
>>> 
>>> cc Claes
>>> 
>>> On 7/07/2020 5:59 pm, Peter Levart wrote:
>>>> Hi,
>>>> 
>>>> 
>>>> Recently I proposed and pushed a change for [1] which adds --enable-preview option to javac compilation of JMH microbenchmarks in general to enable running a benchmark that uses preview feature (Records). This makes the class files produced marked with version 60.65535. The benchmark that uses preview feature executes without problems because it explicitly specifies the following in its code:
>>>> 
>>>> 
>>>> @Fork(value = 1, warmups = 0, jvmArgsAppend = "--enable-preview")
>>>> 
>>>> 
>>>> Recently I wanted to run JMH benchmarks for Stream ops with:
>>>> 
>>>> 
>>>> make test TEST="micro:java.util.stream.ops"
>>>> 
>>>> 
>>>> ...but all of them fail to run with the following exception:
>>>> 
>>>> 
>>>> java.lang.UnsupportedClassVersionError: Preview features are not enabled for org/openjdk/bench/java/util/stream/ops/value/generated/NoneMatchShort_seq_start_jmhTest (class file version 60.65535). Try running with '--enable-preview'
>>>> 
>>>> 
>>>> What shall we do? Add similar annotation to all of them? Is there a way to specify that all micro benchmarks should be run with --enable-preview option passed to java?
>>> 
>>> So this breaks running all non-preview using benchmarks? If so I say we need to backout the change for 8248135 while a proper solution is found.
>> 
>> 
>> I guess it does break (at least the way I tried to run them). The problem is that this little change:
>> 
>> 
>> --- a/make/test/BuildMicrobenchmark.gmk    Wed Jun 24 01:02:19 2020 +0200
>> +++ b/make/test/BuildMicrobenchmark.gmk    Wed Jun 24 11:05:09 2020 +0200
>> @@ -90,10 +90,11 @@
>>      TARGET_RELEASE := $(TARGET_RELEASE_NEWJDK_UPGRADED), \
>>      SMALL_JAVA := false, \
>>      CLASSPATH := $(MICROBENCHMARK_CLASSPATH), \
>> -    DISABLED_WARNINGS := processing rawtypes cast serial, \
>> +    DISABLED_WARNINGS := processing rawtypes cast serial preview, \
>>      SRC := $(MICROBENCHMARK_SRC), \
>>      BIN := $(MICROBENCHMARK_CLASSES), \
>>      JAVA_FLAGS := --add-modules jdk.unsupported --limit-modules java.management, \
>> +    JAVAC_FLAGS := --enable-preview, \
>>  ))
>> 
>> 
>> ...was pushed as part of larger fix for 8247532 which has already been forward and backported. So I think backing out the whole patch (which is perfectly OK by itself) would cause more problems then fixing this particular problem in a followup, given that we can find a fix quickly. Its has been 14 days since the above was pushed and nobody noticed until now, so I guess this is not a big problem?
>> 
>> 
>> Regards, Peter
>> 
>> 
>> 
>>> 
>>> David
>>> -----
>>> 
>>>> 
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8248135
>>>> 
>>>> 
>>>> Regards, Peter
>>>> 
>>>> 



From peter.levart at gmail.com  Tue Jul  7 09:10:19 2020
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 7 Jul 2020 11:10:19 +0200
Subject: Change for 8248135: Build microbenchmarks with --enable-preview
 makes other non-preview JMH benchmarks to fail
In-Reply-To: <4F7F6264-98FA-45DA-8E7C-578C6544682C@oracle.com>
References: <ccab9791-be7a-bb04-3575-b61acf668359@gmail.com>
 <34646b79-3a4a-6068-0bcd-c813989d053f@oracle.com>
 <8d9a3b30-436b-137d-f540-de1417695c7c@gmail.com>
 <d53ceed3-a412-918b-37f9-2b28f0fd73ef@gmail.com>
 <4F7F6264-98FA-45DA-8E7C-578C6544682C@oracle.com>
Message-ID: <0dff2c8d-a2fa-9869-b7a6-cf423b3e027f@gmail.com>

Yes, Chris, this is the same thing. I wasn't aware of it.

Peter

On 7/7/20 11:00 AM, Chris Hegarty wrote:
> Peter,
>
> 8248429 [1] tracks this issue, right?
>
> There was a recent thread on build-dev relating to this, in the form of an RFR from Jorn :
>    https://mail.openjdk.java.net/pipermail/build-dev/2020-June/thread.html#27804
>
> Some great discussion was had, but I?m not sure that a conclusion was reached yet.
>
> 8248429 is the same issue, right?
>
> -Chris.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8248429
>
>> On 7 Jul 2020, at 09:41, Peter Levart <peter.levart at gmail.com> wrote:
>>
>> A quick work-around for anyone wanting to run the microbenchmarks is to pass --enable-preview explicitly. For example:
>>
>>
>> make test TEST="micro:java.util.stream.ops" MICRO="JAVA_OPTIONS=--enable-preview"
>>
>>
>> Regards, Peter
>>
>>
>> On 7/7/20 10:23 AM, Peter Levart wrote:
>>> On 7/7/20 10:13 AM, David Holmes wrote:
>>>> Hi Peter,
>>>>
>>>> cc Claes
>>>>
>>>> On 7/07/2020 5:59 pm, Peter Levart wrote:
>>>>> Hi,
>>>>>
>>>>>
>>>>> Recently I proposed and pushed a change for [1] which adds --enable-preview option to javac compilation of JMH microbenchmarks in general to enable running a benchmark that uses preview feature (Records). This makes the class files produced marked with version 60.65535. The benchmark that uses preview feature executes without problems because it explicitly specifies the following in its code:
>>>>>
>>>>>
>>>>> @Fork(value = 1, warmups = 0, jvmArgsAppend = "--enable-preview")
>>>>>
>>>>>
>>>>> Recently I wanted to run JMH benchmarks for Stream ops with:
>>>>>
>>>>>
>>>>> make test TEST="micro:java.util.stream.ops"
>>>>>
>>>>>
>>>>> ...but all of them fail to run with the following exception:
>>>>>
>>>>>
>>>>> java.lang.UnsupportedClassVersionError: Preview features are not enabled for org/openjdk/bench/java/util/stream/ops/value/generated/NoneMatchShort_seq_start_jmhTest (class file version 60.65535). Try running with '--enable-preview'
>>>>>
>>>>>
>>>>> What shall we do? Add similar annotation to all of them? Is there a way to specify that all micro benchmarks should be run with --enable-preview option passed to java?
>>>> So this breaks running all non-preview using benchmarks? If so I say we need to backout the change for 8248135 while a proper solution is found.
>>>
>>> I guess it does break (at least the way I tried to run them). The problem is that this little change:
>>>
>>>
>>> --- a/make/test/BuildMicrobenchmark.gmk    Wed Jun 24 01:02:19 2020 +0200
>>> +++ b/make/test/BuildMicrobenchmark.gmk    Wed Jun 24 11:05:09 2020 +0200
>>> @@ -90,10 +90,11 @@
>>>       TARGET_RELEASE := $(TARGET_RELEASE_NEWJDK_UPGRADED), \
>>>       SMALL_JAVA := false, \
>>>       CLASSPATH := $(MICROBENCHMARK_CLASSPATH), \
>>> -    DISABLED_WARNINGS := processing rawtypes cast serial, \
>>> +    DISABLED_WARNINGS := processing rawtypes cast serial preview, \
>>>       SRC := $(MICROBENCHMARK_SRC), \
>>>       BIN := $(MICROBENCHMARK_CLASSES), \
>>>       JAVA_FLAGS := --add-modules jdk.unsupported --limit-modules java.management, \
>>> +    JAVAC_FLAGS := --enable-preview, \
>>>   ))
>>>
>>>
>>> ...was pushed as part of larger fix for 8247532 which has already been forward and backported. So I think backing out the whole patch (which is perfectly OK by itself) would cause more problems then fixing this particular problem in a followup, given that we can find a fix quickly. Its has been 14 days since the above was pushed and nobody noticed until now, so I guess this is not a big problem?
>>>
>>>
>>> Regards, Peter
>>>
>>>
>>>
>>>> David
>>>> -----
>>>>
>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8248135
>>>>>
>>>>>
>>>>> Regards, Peter
>>>>>
>>>>>


From erik.joelsson at oracle.com  Tue Jul  7 13:59:01 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 7 Jul 2020 06:59:01 -0700
Subject: RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language
 Features in HotSpot
In-Reply-To: <533C3CDA-B4D2-4809-B88E-23E19D8C98ED@oracle.com>
References: <B98C962A-7864-446B-98ED-69068C7F00D1@oracle.com>
 <5EDE9A75.6020504@oracle.com>
 <A8A5757E-15BC-4104-83DB-6084DFF5CC81@oracle.com>
 <EFE531CD-86C7-4155-BBC9-F4B45179B9A8@oracle.com> <5EE5AB71.20505@oracle.com>
 <DA8424D0-F428-405E-891A-EAB43650F96D@oracle.com>
 <B49ADE47-FA0E-4E48-A9AB-2E9F79ED9DA7@oracle.com>
 <b1862407-8d48-a3e9-b343-99dc890d9b95@oracle.com>
 <533C3CDA-B4D2-4809-B88E-23E19D8C98ED@oracle.com>
Message-ID: <8c4bb4ee-73fa-3568-0d70-c21703e2e06f@oracle.com>

Doc changes look good.

/Erik

On 2020-07-06 18:10, Kim Barrett wrote:
> I just noticed that doc/building.{md,html} describes minimum toolchain versions,
> so also needs to be updated.  Here?s the update, matching what?s now in the JEP:
>
> full: https://cr.openjdk.java.net/~kbarrett/8246032/open.05/
> incr: https://cr.openjdk.java.net/~kbarrett/8246032/open.05.inc/
>
> I also deleted a discussion of a problem one might run into when building with
> Visual Studio 2010, since that version is no longer relevant.
>


From peter.levart at gmail.com  Tue Jul  7 14:26:55 2020
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 7 Jul 2020 16:26:55 +0200
Subject: RFR [XS]: 8248429: Add --enable-preview as VM argument when
 running microbenchmarks
In-Reply-To: <16f12991-d147-0328-f2b1-e20845acb3b7@oracle.com>
References: <8cd2491e-3e90-6c00-1d09-c2a11022c287@oracle.com>
 <19b5a5a2-1f60-361e-c417-2933504907cd@oracle.com>
 <f70a3348-d9ee-4c50-1fdd-5558d54a8920@oracle.com>
 <b2ca5e6c-68c5-eee3-646c-48e6bb8ae2ea@oracle.com>
 <4e6978ad-774f-f8d4-c10a-b4a1482f25b1@oracle.com>
 <aef6de37-5bea-2513-2fa3-5cf6dd721435@oracle.com>
 <9784b512-3606-474b-18a6-dfe236b63ac8@oracle.com>
 <fca0f099-7f13-6b22-21ee-9b5dd6914256@oracle.com>
 <2f460e59-b5bc-4561-6c8a-712b1d7ee318@oracle.com>
 <af841f5a-9638-498e-44c0-d8c0220c43b9@oracle.com>
 <722302a9-9184-8800-d312-bb7a8ecd3dfb@oracle.com>
 <d1e82d58-0c32-c9db-02d6-1a333232a419@oracle.com>
 <16f12991-d147-0328-f2b1-e20845acb3b7@oracle.com>
Message-ID: <f8d2eb35-3f10-ef4a-e41d-11deb2850581@gmail.com>

I suggest adding --enable-preview to JMH_JVM_ARGS in general now (it 
doesn't hurt even if classes are not compiled with --enable-preview) and 
then take time to devise an effective strategy for selectively compiling 
micro benchmarks with or without --enable-preview. At least so the 
benchmarks would work out-of-the-box when run via make test.

WDYT?


Regards, Peter


On 6/30/20 10:15 PM, Claes Redestad wrote:
> On 2020-06-30 22:12, Magnus Ihse Bursie wrote:
>>>
>>> Second to that a solution in the build would be preferable - if we can
>>> come up with something that has infinitesimal impact to build times.
>> Are we talking about many files? Could you consider listing those 
>> files explicitly in the makefile? That would make it cheap to filter 
>> them out from the normal compilation, and instead do a secondary 
>> compilation with them.
>
> Right now there's one micro using --enable-preview, so that'd be a very
> short list.
>
> /Claes


From galder at redhat.com  Tue Jul  7 14:31:39 2020
From: galder at redhat.com (Galder Zamarreno)
Date: Tue, 7 Jul 2020 16:31:39 +0200
Subject: RFR: JDK-8248158 Configure fails with autoconf not found even
 though it's installed
In-Reply-To: <7ba7f5cd-abd2-3331-e836-97e769a8189d@redhat.com>
References: <CAAcPREuoXF9rrO5YrZwYdNO6iUvQv=Yv7mPHY_OcRZ6H=7K+kg@mail.gmail.com>
 <5b25d03a-675f-072a-5772-2e2b03739484@oracle.com>
 <CAAcPREsPO5jGDWH+Y59rPonzOBf14+M3+t8or-wNuH6KAyOVtw@mail.gmail.com>
 <7ba7f5cd-abd2-3331-e836-97e769a8189d@redhat.com>
Message-ID: <CAAcPREuMD3e=mDbtmZJj8dJuBP+5k12VxoKr=0TAn460BqUQZA@mail.gmail.com>

On Mon, Jul 6, 2020 at 10:50 PM Simon Tooke <stooke at redhat.com> wrote:

> (Disclaimer: I am not a reviewer, so this is an opinion, not a review)
>
> I have tested this on Windows and it built without issue, although the
> submit repo should be the final gate.  I'd also like to add my void to
> simply redefining 'WHICH' as it leads to less changes in the source
> code, which would make life easier should this be backported to 11u
> and/or 8u.


So, you would just switch the UTIL_REQUIRE_PROGS call for WHICH to be `type
...` instead?


>
> -Simon
>
> On 2020-07-02 4:22 a.m., Galder Zamarreno wrote:
> > On Thu, Jul 2, 2020 at 12:37 AM Magnus Ihse Bursie <
> > magnus.ihse.bursie at oracle.com> wrote:
> >
> >>
> >> On 2020-07-01 12:05, Galder Zamarreno wrote:
> >>> Using `which` to check whether commands exist can result in confusing
> >>> errors when `which` itself is not installed in the system. This is the
> >> case
> >>> with `autoconf`, where if `autoconf` is present but `which` isn't, the
> >>> build system says that `autoconf` is missing, when in reality it is
> >> `which`
> >>> which is missing. The fix switches autoconf uses of `which` for `type
> -p`
> >>> instead, which is a Bash built-in command.
> >>>
> >>> I've tested the fix with a fedora docker container that had `autoconf`
> >>> installed but `which`. When using `type -p` it correctly detects
> >> `autoconf`
> >>> installed and eventually fails saying that `which` is not installed,
> >> which
> >>> is the expected behaviour.
> >>>
> >>> `which` is still in use in make/autoconf/util_windows.m4. A possible
> >> future
> >>> improvement would be to see if `which` use there could be replaced as
> >> well.
> >>> Eventually, when no `which` uses remain, the presence check for `which`
> >>> could be removed.
> >> I agree that we should replace "which" with "type -p" everywhere. The
> >> best way to do this is probably to replace the value of $WHICH with
> >> "type -p". It's a bash built-in, so we can count on its presence. If you
> >> want to fix that as part of this bug, I'm ok with it, otherwise we
> >> should open a new bug to track this. I think there is also one or two
> >> instances of "command" recently added as (better, but not as good as
> >> "type -p") replacements for which.
> >>
> > I discovered one place in util.m4 where command was being used.
> >
> > There are other places outside of make/ where command is used but I feel
> > those are a bit out of scope here.
> >
> > My main objective is that from a configure perspective, we'd try to
> reduce
> > the number of dependencies needed to build things.
> >
> > I'll send an updated webrev shortly.
> >
> >
> >> /Magnus
> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8248158
> >>> WebRev:
> >> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8248158/01/webrev/
> >>> Galder
> >>
>
>


From kim.barrett at oracle.com  Tue Jul  7 14:38:48 2020
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 7 Jul 2020 10:38:48 -0400
Subject: RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language
 Features in HotSpot
In-Reply-To: <8c4bb4ee-73fa-3568-0d70-c21703e2e06f@oracle.com>
References: <B98C962A-7864-446B-98ED-69068C7F00D1@oracle.com>
 <5EDE9A75.6020504@oracle.com>
 <A8A5757E-15BC-4104-83DB-6084DFF5CC81@oracle.com>
 <EFE531CD-86C7-4155-BBC9-F4B45179B9A8@oracle.com> <5EE5AB71.20505@oracle.com>
 <DA8424D0-F428-405E-891A-EAB43650F96D@oracle.com>
 <B49ADE47-FA0E-4E48-A9AB-2E9F79ED9DA7@oracle.com>
 <b1862407-8d48-a3e9-b343-99dc890d9b95@oracle.com>
 <533C3CDA-B4D2-4809-B88E-23E19D8C98ED@oracle.com>
 <8c4bb4ee-73fa-3568-0d70-c21703e2e06f@oracle.com>
Message-ID: <0680F1AA-351F-405C-A73D-CDA217D66CFF@oracle.com>

> On Jul 7, 2020, at 9:59 AM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 
> Doc changes look good.
> 
> /Erik
> 
> On 2020-07-06 18:10, Kim Barrett wrote:
>> I just noticed that doc/building.{md,html} describes minimum toolchain versions,
>> so also needs to be updated.  Here?s the update, matching what?s now in the JEP:
>> 
>> full: https://cr.openjdk.java.net/~kbarrett/8246032/open.05/
>> incr: https://cr.openjdk.java.net/~kbarrett/8246032/open.05.inc/
>> 
>> I also deleted a discussion of a problem one might run into when building with
>> Visual Studio 2010, since that version is no longer relevant.

Thanks.



From peter.levart at gmail.com  Tue Jul  7 15:27:53 2020
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 7 Jul 2020 17:27:53 +0200
Subject: RFR [XS]: 8248429: Add --enable-preview as VM argument when
 running microbenchmarks
In-Reply-To: <f8d2eb35-3f10-ef4a-e41d-11deb2850581@gmail.com>
References: <8cd2491e-3e90-6c00-1d09-c2a11022c287@oracle.com>
 <19b5a5a2-1f60-361e-c417-2933504907cd@oracle.com>
 <f70a3348-d9ee-4c50-1fdd-5558d54a8920@oracle.com>
 <b2ca5e6c-68c5-eee3-646c-48e6bb8ae2ea@oracle.com>
 <4e6978ad-774f-f8d4-c10a-b4a1482f25b1@oracle.com>
 <aef6de37-5bea-2513-2fa3-5cf6dd721435@oracle.com>
 <9784b512-3606-474b-18a6-dfe236b63ac8@oracle.com>
 <fca0f099-7f13-6b22-21ee-9b5dd6914256@oracle.com>
 <2f460e59-b5bc-4561-6c8a-712b1d7ee318@oracle.com>
 <af841f5a-9638-498e-44c0-d8c0220c43b9@oracle.com>
 <722302a9-9184-8800-d312-bb7a8ecd3dfb@oracle.com>
 <d1e82d58-0c32-c9db-02d6-1a333232a419@oracle.com>
 <16f12991-d147-0328-f2b1-e20845acb3b7@oracle.com>
 <f8d2eb35-3f10-ef4a-e41d-11deb2850581@gmail.com>
Message-ID: <a993c461-0f19-f124-a13c-164f9f3a8a71@gmail.com>


On 7/7/20 4:26 PM, Peter Levart wrote:
> I suggest adding --enable-preview to JMH_JVM_ARGS in general now (it 
> doesn't hurt even if classes are not compiled with --enable-preview) 
> and then take time to devise an effective strategy for selectively 
> compiling micro benchmarks with or without --enable-preview. At least 
> so the benchmarks would work out-of-the-box when run via make test.
>
> WDYT?
>

Or maybe this variant is acceptable?


http://cr.openjdk.java.net/~plevart/jdk-dev/8248429_jmh_enable_preview/webrev.01/


I took Jorn Vernee's patch and modified it a bit so that it does not 
need to find and grep the files but I rather specify relative source 
directories for EXCLUDES and INCLUDES parameters to the two separate 
SetupJavaCompilation tasks respectively. Benchmarks that need preview 
features (currently just one) then need to be in a package with special 
prefix org.openjdk.bench.preview so they are separately compiled with 
--enable-preview option. Other files are compiled without it.


Peter


>
> Regards, Peter
>
>
> On 6/30/20 10:15 PM, Claes Redestad wrote:
>> On 2020-06-30 22:12, Magnus Ihse Bursie wrote:
>>>>
>>>> Second to that a solution in the build would be preferable - if we can
>>>> come up with something that has infinitesimal impact to build times.
>>> Are we talking about many files? Could you consider listing those 
>>> files explicitly in the makefile? That would make it cheap to filter 
>>> them out from the normal compilation, and instead do a secondary 
>>> compilation with them.
>>
>> Right now there's one micro using --enable-preview, so that'd be a very
>> short list.
>>
>> /Claes


From jorn.vernee at oracle.com  Tue Jul  7 17:25:35 2020
From: jorn.vernee at oracle.com (Jorn Vernee)
Date: Tue, 7 Jul 2020 19:25:35 +0200
Subject: RFR [XS]: 8248429: Add --enable-preview as VM argument when
 running microbenchmarks
In-Reply-To: <1b753251-3502-18e0-6728-3a050310c938@oracle.com>
References: <8cd2491e-3e90-6c00-1d09-c2a11022c287@oracle.com>
 <19b5a5a2-1f60-361e-c417-2933504907cd@oracle.com>
 <f70a3348-d9ee-4c50-1fdd-5558d54a8920@oracle.com>
 <b2ca5e6c-68c5-eee3-646c-48e6bb8ae2ea@oracle.com>
 <4e6978ad-774f-f8d4-c10a-b4a1482f25b1@oracle.com>
 <aef6de37-5bea-2513-2fa3-5cf6dd721435@oracle.com>
 <9784b512-3606-474b-18a6-dfe236b63ac8@oracle.com>
 <fca0f099-7f13-6b22-21ee-9b5dd6914256@oracle.com>
 <2f460e59-b5bc-4561-6c8a-712b1d7ee318@oracle.com>
 <af841f5a-9638-498e-44c0-d8c0220c43b9@oracle.com>
 <722302a9-9184-8800-d312-bb7a8ecd3dfb@oracle.com>
 <d1e82d58-0c32-c9db-02d6-1a333232a419@oracle.com>
 <16f12991-d147-0328-f2b1-e20845acb3b7@oracle.com>
 <1b753251-3502-18e0-6728-3a050310c938@oracle.com>
Message-ID: <d5060576-43ad-d8ef-736a-8a374fbd75e6@oracle.com>

On 30/06/2020 22:51, Erik Joelsson wrote:
> On 2020-06-30 13:15, Claes Redestad wrote:
>> On 2020-06-30 22:12, Magnus Ihse Bursie wrote:
>>>>
>>>> Second to that a solution in the build would be preferable - if we can
>>>> come up with something that has infinitesimal impact to build times.
>>> Are we talking about many files? Could you consider listing those 
>>> files explicitly in the makefile? That would make it cheap to filter 
>>> them out from the normal compilation, and instead do a secondary 
>>> compilation with them.
>>
>> Right now there's one micro using --enable-preview, so that'd be a very
>> short list.
>>
> Having to update a list manually is no fun, but at least we can make 
> the build fail if you forget. If you only disable the warning 
> "preview" for the special compilation set, the build would fail if 
> another microbenchmark was added that needed it.

A little bit of an update on this.

I've implemented the manual list of preview benchmarks [1], but there's 
a problem with the current patch. Both the BUILD_JDK_MICROBENCHMARK and 
the BUILD_JDK_MICROBENCHMARK_PREVIEW have the same output folder, and 
this is good, since we want only 1 benchmarks.jar, we want the 
compilation result to be combined. But the JMH annotation processor is 
also generating some metadata files in META-INF, namely BenchmarkList 
and CompilerHints.

The problem is that both compilation tasks seem to be trying to write to 
these files at the same time, leading to e.g. the RecordsDeserialization 
benchmark not appearing in the final BenchmarkList, or seemingly 
resulting in a mangled file, crashing the JMH parser.

I've tried to resolve this race be adding a dependency on 
BUILD_JDK_MICROBENCHMARK to BUILD_JDK_MICROBENCHMARK_PREVIEW (see the 
patch), but this doesn't resolve the problem. I'm still investigating this.

Jorn

[1] : http://cr.openjdk.java.net/~jvernee/8248429/webrev.02/

>
> /Erik
>
>> /Claes


From Roger.Riggs at oracle.com  Tue Jul  7 17:51:39 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Tue, 7 Jul 2020 13:51:39 -0400
Subject: RFR [XS]: 8248429: Add --enable-preview as VM argument when
 running microbenchmarks
In-Reply-To: <f8d2eb35-3f10-ef4a-e41d-11deb2850581@gmail.com>
References: <8cd2491e-3e90-6c00-1d09-c2a11022c287@oracle.com>
 <19b5a5a2-1f60-361e-c417-2933504907cd@oracle.com>
 <f70a3348-d9ee-4c50-1fdd-5558d54a8920@oracle.com>
 <b2ca5e6c-68c5-eee3-646c-48e6bb8ae2ea@oracle.com>
 <4e6978ad-774f-f8d4-c10a-b4a1482f25b1@oracle.com>
 <aef6de37-5bea-2513-2fa3-5cf6dd721435@oracle.com>
 <9784b512-3606-474b-18a6-dfe236b63ac8@oracle.com>
 <fca0f099-7f13-6b22-21ee-9b5dd6914256@oracle.com>
 <2f460e59-b5bc-4561-6c8a-712b1d7ee318@oracle.com>
 <af841f5a-9638-498e-44c0-d8c0220c43b9@oracle.com>
 <722302a9-9184-8800-d312-bb7a8ecd3dfb@oracle.com>
 <d1e82d58-0c32-c9db-02d6-1a333232a419@oracle.com>
 <16f12991-d147-0328-f2b1-e20845acb3b7@oracle.com>
 <f8d2eb35-3f10-ef4a-e41d-11deb2850581@gmail.com>
Message-ID: <56572ec4-1c79-66f0-76b2-1a710b606d33@oracle.com>

Hi,

I have found it very useful to be able to run benchmarks against multiple
versions of the JDK.? Build the benchmark jar once and to compare results.
If all of the classes are built with --enable-preview, none of them will 
run
against older JDKs. So an approach that only compiles those files that need
preview would be more useful.? Or perhaps, separate out preview based 
benchmarks
into a separate jar.

$.02, Roger


On 7/7/20 10:26 AM, Peter Levart wrote:
> I suggest adding --enable-preview to JMH_JVM_ARGS in general now (it 
> doesn't hurt even if classes are not compiled with --enable-preview) 
> and then take time to devise an effective strategy for selectively 
> compiling micro benchmarks with or without --enable-preview. At least 
> so the benchmarks would work out-of-the-box when run via make test.
>
> WDYT?
>
>
> Regards, Peter
>
>
> On 6/30/20 10:15 PM, Claes Redestad wrote:
>> On 2020-06-30 22:12, Magnus Ihse Bursie wrote:
>>>>
>>>> Second to that a solution in the build would be preferable - if we can
>>>> come up with something that has infinitesimal impact to build times.
>>> Are we talking about many files? Could you consider listing those 
>>> files explicitly in the makefile? That would make it cheap to filter 
>>> them out from the normal compilation, and instead do a secondary 
>>> compilation with them.
>>
>> Right now there's one micro using --enable-preview, so that'd be a very
>> short list.
>>
>> /Claes



From luhenry at microsoft.com  Tue Jul  7 19:57:54 2020
From: luhenry at microsoft.com (Ludovic Henry)
Date: Tue, 7 Jul 2020 19:57:54 +0000
Subject: Preliminary review for new WINENV support
In-Reply-To: <38907e54-b263-3251-dc26-feb5da7cd89f@oss.nttdata.com>
References: <E8774EC8-612E-4646-B223-D55ED0C0BC46@oracle.com>,
 <38907e54-b263-3251-dc26-feb5da7cd89f@oss.nttdata.com>
Message-ID: <MWHPR21MB051140086A5FB135B2411F5AB0660@MWHPR21MB0511.namprd21.prod.outlook.com>

Hi,

I tried out your changes locally, and with Yasumasa's change and the following diff [1], I can confirm that this works on my setup (VS2019 devkit w/ Cygwin). I'll give a spin with WSL1 and WSL2, as well as VS2017.

[1] Diff to fix support for VS2019

--- a/make/autoconf/toolchain_microsoft.m4
+++ b/make/autoconf/toolchain_microsoft.m4
@@ -628,9 +606,9 @@ AC_DEFUN([TOOLCHAIN_SETUP_VS_RUNTIME_DLLS],
   fi

   AC_ARG_WITH(vcruntime-1-dll, [AS_HELP_STRING([--with-vcruntime-1-dll],
       [path to microsoft C++ runtime dll (vcruntime*_1.dll) (Windows x64 only) @<:@probed@:>@])])

-  if test "x$VCRUNTIME_1_NAME" != "x" && test "x$OPENJDK_TARGET_BITS" = x64; then
+  if test "x$VCRUNTIME_1_NAME" != "x" && test "x$OPENJDK_TARGET_CPU_BITS" = x64; then
     if test "x$with_vcruntime_1_dll" != x; then
       # If given explicitly by user, do not probe. If not present, fail directly.
       TOOLCHAIN_CHECK_POSSIBLE_MSVC_DLL($VCRUNTIME_1_NAME, [$with_vcruntime_1_dll],

I also want to propose integrating the bits to support cross-compilation with the microsoft toolchain as part of your change, even without adding the targetting for Windows-AArch64. The following diff [2] integrates such support for cross-compilation without adding Windows-AArch64:

[2] Diff to add support for cross-compilation

commit c23c78e33e57955d3f344383619592f34b84169b
Author: Ludovic Henry <luhenry at microsoft.com>
Date:   Tue Jul 7 11:35:41 2020 -0700

    8248498: Add build system support for Windows AArch64 (Part 1)

    This adds support for cross-compilation on Windows, without adding the
    AArch64 specific bits.

    https://bugs.openjdk.java.net/browse/JDK-8248498

diff --git a/make/autoconf/basic.m4 b/make/autoconf/basic.m4
index 7248163242d..60b4097cba9 100644
--- a/make/autoconf/basic.m4
+++ b/make/autoconf/basic.m4
@@ -111,6 +111,16 @@ AC_DEFUN([BASIC_EVAL_DEVKIT_VARIABLE],
   fi
 ])

+###############################################################################
+# Evaluates platform specific overrides for build devkit variables.
+# $1: Name of variable
+AC_DEFUN([BASIC_EVAL_BUILD_DEVKIT_VARIABLE],
+[
+  if test "x[$]$1" = x; then
+    eval $1="\${$1_${OPENJDK_BUILD_CPU}}"
+  fi
+])
+
 ###############################################################################
 AC_DEFUN_ONCE([BASIC_SETUP_DEVKIT],
 [
diff --git a/make/autoconf/flags-ldflags.m4 b/make/autoconf/flags-ldflags.m4
index a2a52f98ef7..8af9a20b5e8 100644
--- a/make/autoconf/flags-ldflags.m4
+++ b/make/autoconf/flags-ldflags.m4
@@ -164,15 +164,14 @@ AC_DEFUN([FLAGS_SETUP_LDFLAGS_CPU_DEP],
     fi

   elif test "x$TOOLCHAIN_TYPE" = xmicrosoft; then
-    if test "x${OPENJDK_$1_CPU}" = "xx86"; then
-      $1_CPU_LDFLAGS="-safeseh"
-      # NOTE: Old build added -machine. Probably not needed.
-      $1_CPU_LDFLAGS_JVM_ONLY="-machine:I386"
+    if test "x${OPENJDK_$1_CPU_BITS}" = "x32"; then
       $1_CPU_EXECUTABLE_LDFLAGS="-stack:327680"
-    else
-      $1_CPU_LDFLAGS_JVM_ONLY="-machine:AMD64"
+    elif test "x${OPENJDK_$1_CPU_BITS}" = "x64"; then
       $1_CPU_EXECUTABLE_LDFLAGS="-stack:1048576"
     fi
+    if test "x${OPENJDK_$1_CPU}" = "xx86"; then
+      $1_CPU_LDFLAGS="-safeseh"
+    fi
   fi

   # JVM_VARIANT_PATH depends on if this is build or target...
diff --git a/make/autoconf/flags.m4 b/make/autoconf/flags.m4
index 694d41052ba..8cbf306ab0c 100644
--- a/make/autoconf/flags.m4
+++ b/make/autoconf/flags.m4
@@ -204,32 +204,36 @@ AC_DEFUN_ONCE([FLAGS_SETUP_USER_SUPPLIED_FLAGS],
 # Param 1 - Optional prefix to all variables. (e.g BUILD_)
 AC_DEFUN([FLAGS_SETUP_SYSROOT_FLAGS],
 [
-  if test "x[$]$1SYSROOT" != "x"; then
-    if test "x$TOOLCHAIN_TYPE" = xgcc; then
-      $1SYSROOT_CFLAGS="--sysroot=[$]$1SYSROOT"
-      $1SYSROOT_LDFLAGS="--sysroot=[$]$1SYSROOT"
-    elif test "x$TOOLCHAIN_TYPE" = xclang; then
-      $1SYSROOT_CFLAGS="-isysroot [$]$1SYSROOT"
-      $1SYSROOT_LDFLAGS="-isysroot [$]$1SYSROOT"
-    fi
-  fi
-
-  if test "x$OPENJDK_TARGET_OS" = xmacosx; then
-    # We also need -iframework<path>/System/Library/Frameworks
-    $1SYSROOT_CFLAGS="[$]$1SYSROOT_CFLAGS -iframework [$]$1SYSROOT/System/Library/Frameworks"
-    $1SYSROOT_LDFLAGS="[$]$1SYSROOT_LDFLAGS -iframework [$]$1SYSROOT/System/Library/Frameworks"
-    # These always need to be set, or we can't find the frameworks embedded in JavaVM.framework
-    # set this here so it doesn't have to be peppered throughout the forest
-    $1SYSROOT_CFLAGS="[$]$1SYSROOT_CFLAGS -F [$]$1SYSROOT/System/Library/Frameworks/JavaVM.framework/Frameworks"
-    $1SYSROOT_LDFLAGS="[$]$1SYSROOT_LDFLAGS -F [$]$1SYSROOT/System/Library/Frameworks/JavaVM.framework/Frameworks"
-  fi
-
   # For the microsoft toolchain, we need to get the SYSROOT flags from the
   # Visual Studio environment. Currently we cannot handle this as a separate
   # build toolchain.
-  if test "x$1" = x && test "x$OPENJDK_BUILD_OS" = "xwindows" \
-      && test "x$TOOLCHAIN_TYPE" = "xmicrosoft"; then
-    TOOLCHAIN_SETUP_VISUAL_STUDIO_ENV
+  if test "x$TOOLCHAIN_TYPE" = "xmicrosoft"; then
+    # The BUILD_* flags are setup in TOOLCHAIN_SETUP_BUILD_COMPILERS
+    if test "x$1" = x; then
+      TOOLCHAIN_SETUP_VISUAL_STUDIO_ENV
+    fi
+
+    TOOLCHAIN_SETUP_VISUAL_STUDIO_SYSROOT_FLAGS([$1])
+  else
+    if test "x[$]$1SYSROOT" != "x"; then
+      if test "x$TOOLCHAIN_TYPE" = xgcc; then
+        $1SYSROOT_CFLAGS="--sysroot=[$]$1SYSROOT"
+        $1SYSROOT_LDFLAGS="--sysroot=[$]$1SYSROOT"
+      elif test "x$TOOLCHAIN_TYPE" = xclang; then
+        $1SYSROOT_CFLAGS="-isysroot [$]$1SYSROOT"
+        $1SYSROOT_LDFLAGS="-isysroot [$]$1SYSROOT"
+      fi
+    fi
+
+    if test "x$OPENJDK_TARGET_OS" = xmacosx; then
+      # We also need -iframework<path>/System/Library/Frameworks
+      $1SYSROOT_CFLAGS="[$]$1SYSROOT_CFLAGS -iframework [$]$1SYSROOT/System/Library/Frameworks"
+      $1SYSROOT_LDFLAGS="[$]$1SYSROOT_LDFLAGS -iframework [$]$1SYSROOT/System/Library/Frameworks"
+      # These always need to be set, or we can't find the frameworks embedded in JavaVM.framework
+      # set this here so it doesn't have to be peppered throughout the forest
+      $1SYSROOT_CFLAGS="[$]$1SYSROOT_CFLAGS -F [$]$1SYSROOT/System/Library/Frameworks/JavaVM.framework/Frameworks"
+      $1SYSROOT_LDFLAGS="[$]$1SYSROOT_LDFLAGS -F [$]$1SYSROOT/System/Library/Frameworks/JavaVM.framework/Frameworks"
+    fi
   fi

   AC_SUBST($1SYSROOT_CFLAGS)
@@ -373,7 +377,8 @@ AC_DEFUN_ONCE([FLAGS_POST_TOOLCHAIN],
 [
   FLAGS_SETUP_TOOLCHAIN_CONTROL

-  if test "x$BUILD_SYSROOT" != x; then
+  if test "x$BUILD_SYSROOT" != x || \
+      test "x$TOOLCHAIN_TYPE" = "xmicrosoft"; then
     FLAGS_SETUP_SYSROOT_FLAGS([BUILD_])
   else
     if test "x$COMPILE_TYPE" != "xcross"; then
diff --git a/make/autoconf/toolchain.m4 b/make/autoconf/toolchain.m4
index 14213f896d4..4a2462c2dd6 100644
--- a/make/autoconf/toolchain.m4
+++ b/make/autoconf/toolchain.m4
@@ -798,14 +798,18 @@ AC_DEFUN_ONCE([TOOLCHAIN_SETUP_BUILD_COMPILERS],
           . $CONFIGURESUPPORT_OUTPUTDIR/build-devkit.info
           # This potentially sets the following:
           # A descriptive name of the devkit
-          BASIC_EVAL_DEVKIT_VARIABLE([BUILD_DEVKIT_NAME])
+          BASIC_EVAL_BUILD_DEVKIT_VARIABLE([BUILD_DEVKIT_NAME])
           # Corresponds to --with-extra-path
-          BASIC_EVAL_DEVKIT_VARIABLE([BUILD_DEVKIT_EXTRA_PATH])
+          BASIC_EVAL_BUILD_DEVKIT_VARIABLE([BUILD_DEVKIT_EXTRA_PATH])
           # Corresponds to --with-toolchain-path
-          BASIC_EVAL_DEVKIT_VARIABLE([BUILD_DEVKIT_TOOLCHAIN_PATH])
+          BASIC_EVAL_BUILD_DEVKIT_VARIABLE([BUILD_DEVKIT_TOOLCHAIN_PATH])
           # Corresponds to --with-sysroot
-          BASIC_EVAL_DEVKIT_VARIABLE([BUILD_DEVKIT_SYSROOT])
-          # Skip the Window specific parts
+          BASIC_EVAL_BUILD_DEVKIT_VARIABLE([BUILD_DEVKIT_SYSROOT])
+
+          if test "x$TOOLCHAIN_TYPE" = xmicrosoft; then
+            BASIC_EVAL_BUILD_DEVKIT_VARIABLE([BUILD_DEVKIT_VS_INCLUDE])
+            BASIC_EVAL_BUILD_DEVKIT_VARIABLE([BUILD_DEVKIT_VS_LIB])
+          fi
         fi

         AC_MSG_CHECKING([for build platform devkit])
@@ -817,11 +821,17 @@ AC_DEFUN_ONCE([TOOLCHAIN_SETUP_BUILD_COMPILERS],

         BUILD_SYSROOT="$BUILD_DEVKIT_SYSROOT"

-         # Fallback default of just /bin if DEVKIT_PATH is not defined
+        # Fallback default of just /bin if DEVKIT_PATH is not defined
         if test "x$BUILD_DEVKIT_TOOLCHAIN_PATH" = x; then
           BUILD_DEVKIT_TOOLCHAIN_PATH="$BUILD_DEVKIT_ROOT/bin"
         fi
-        PATH="$BUILD_DEVKIT_TOOLCHAIN_PATH:$BUILD_DEVKIT_EXTRA_PATH"
+
+        UTIL_PREPEND_TO_PATH([PATH],"$BUILD_DEVKIT_TOOLCHAIN_PATH:$BUILD_DEVKIT_EXTRA_PATH")
+
+        if test "x$TOOLCHAIN_TYPE" = xmicrosoft; then
+          BUILD_VS_INCLUDE="${BUILD_DEVKIT_VS_INCLUDE//;/:}"
+          BUILD_VS_LIB="${BUILD_DEVKIT_VS_LIB//;/:}"
+        fi
       fi
     fi

@@ -836,9 +846,27 @@ AC_DEFUN_ONCE([TOOLCHAIN_SETUP_BUILD_COMPILERS],
     UTIL_LOOKUP_PROGS(BUILD_STRIP, strip)
     # Assume the C compiler is the assembler
     BUILD_AS="$BUILD_CC -c"
-    # Just like for the target compiler, use the compiler as linker
-    BUILD_LD="$BUILD_CC"
-    BUILD_LDCXX="$BUILD_CXX"
+    if test "x$TOOLCHAIN_TYPE" = xmicrosoft; then
+      # In the Microsoft toolchain we have a separate LD command "link".
+      UTIL_LOOKUP_TOOLCHAIN_PROGS(BUILD_LD, link)
+
+      # Make sure we did not pick up /usr/bin/link, which is the unix-style
+      # link executable.
+      AC_MSG_CHECKING([if the found link.exe is actually the Visual Studio linker])
+      $BUILD_LD --version > /dev/null
+      if test $? -eq 0 ; then
+        AC_MSG_RESULT([no])
+        AC_MSG_ERROR([This is the winenv link tool. Please check your PATH and rerun configure.])
+      else
+        AC_MSG_RESULT([yes])
+      fi
+
+      BUILD_LDCXX="$BUILD_LD"
+    else
+      # Just like for the target compiler, use the compiler as linker
+      BUILD_LD="$BUILD_CC"
+      BUILD_LDCXX="$BUILD_CXX"
+    fi

     PATH="$OLDPATH"

@@ -879,7 +907,7 @@ AC_DEFUN_ONCE([TOOLCHAIN_MISC_CHECKS],
   # Check for extra potential brokenness.
   if test  "x$TOOLCHAIN_TYPE" = xmicrosoft; then
     # On Windows, double-check that we got the right compiler.
-    CC_VERSION_OUTPUT=`$COMPILER 2>&1 1>/dev/null | $GREP -v 'ERROR.*UtilTranslatePathList' | $HEAD -n 1 | $TR -d '\r'`
+    CC_VERSION_OUTPUT=`$CC 2>&1 1>/dev/null | $GREP -v 'ERROR.*UtilTranslatePathList' | $HEAD -n 1 | $TR -d '\r'`
     COMPILER_CPU_TEST=`$ECHO $CC_VERSION_OUTPUT | $SED -n "s/^.* \(.*\)$/\1/p"`
     if test "x$OPENJDK_TARGET_CPU" = "xx86"; then
       if test "x$COMPILER_CPU_TEST" != "x80x86" -a "x$COMPILER_CPU_TEST" != "xx86"; then
diff --git a/make/autoconf/toolchain_microsoft.m4 b/make/autoconf/toolchain_microsoft.m4
index fd8dfc3641d..2e297dc8be1 100644
--- a/make/autoconf/toolchain_microsoft.m4
+++ b/make/autoconf/toolchain_microsoft.m4
@@ -309,8 +309,8 @@ AC_DEFUN([TOOLCHAIN_FIND_VISUAL_STUDIO],
     eval VS_SUPPORTED="\${VS_SUPPORTED_${VS_VERSION}}"
     eval PLATFORM_TOOLSET="\${VS_VS_PLATFORM_NAME_${VS_VERSION}}"

-    VS_INCLUDE=${DEVKIT_VS_INCLUDE//;/:}
-    VS_LIB=${DEVKIT_VS_LIB//;/:}
+    VS_INCLUDE="${DEVKIT_VS_INCLUDE//;/:}"
+    VS_LIB="${DEVKIT_VS_LIB//;/:}"

     AC_MSG_NOTICE([Found devkit $VS_DESCRIPTION])

@@ -426,21 +426,6 @@ AC_DEFUN([TOOLCHAIN_SETUP_VISUAL_STUDIO_ENV],

       # Turn VS_PATH into TOOLCHAIN_PATH
       TOOLCHAIN_PATH="$TOOLCHAIN_PATH:$VS_PATH"
-
-      # Convert VS_INCLUDE into SYSROOT_CFLAGS
-      OLDIFS="$IFS"
-      IFS=":"
-
-      for ipath in $VS_INCLUDE; do
-        SYSROOT_CFLAGS="$SYSROOT_CFLAGS -I$ipath"
-      done
-
-      # Convert VS_LIB into SYSROOT_LDFLAGS
-      for libpath in $VS_LIB; do
-        SYSROOT_LDFLAGS="$SYSROOT_LDFLAGS -libpath:$libpath"
-      done
-
-      IFS="$OLDIFS"
     fi
   else
     AC_MSG_RESULT([not found])
@@ -488,22 +473,20 @@ AC_DEFUN([TOOLCHAIN_SETUP_MSVC_DLL],
   DLL_NAME="$1"
   MSVC_DLL=

+  if test "x$OPENJDK_TARGET_CPU" = xx86; then
+    vs_target_cpu=x86
+  elif test "x$OPENJDK_TARGET_CPU" = xx86_64; then
+    vs_target_cpu=x64
+  fi
+
   if test "x$MSVC_DLL" = x; then
     if test "x$VCINSTALLDIR" != x; then
       if test "$VS_VERSION" -lt 2017; then
         # Probe: Using well-known location from Visual Studio 12.0 and older
-        if test "x$OPENJDK_TARGET_CPU_BITS" = x64; then
-          POSSIBLE_MSVC_DLL="$VCINSTALLDIR/redist/x64/microsoft.vc${VS_VERSION_INTERNAL}.crt/$DLL_NAME"
-        else
-          POSSIBLE_MSVC_DLL="$VCINSTALLDIR/redist/x86/microsoft.vc${VS_VERSION_INTERNAL}.crt/$DLL_NAME"
-        fi
+        POSSIBLE_MSVC_DLL="$VCINSTALLDIR/redist/$vs_target_cpu/Microsoft.VC${VS_VERSION_INTERNAL}.CRT/$DLL_NAME"
       else
         # Probe: Using well-known location from VS 2017 and VS 2019
-        if test "x$OPENJDK_TARGET_CPU_BITS" = x64; then
-          POSSIBLE_MSVC_DLL="`ls $VCToolsRedistDir/x64/microsoft.vc${VS_VERSION_INTERNAL}.crt/$DLL_NAME`"
-        else
-          POSSIBLE_MSVC_DLL="`ls $VCToolsRedistDir/x86/microsoft.vc${VS_VERSION_INTERNAL}.crt/$DLL_NAME`"
-        fi
+        POSSIBLE_MSVC_DLL="`ls $VCToolsRedistDir/$vs_target_cpu/microsoft.vc${VS_VERSION_INTERNAL}.crt/$DLL_NAME`"
       fi
       # In case any of the above finds more than one file, loop over them.
       for possible_msvc_dll in $POSSIBLE_MSVC_DLL; do
@@ -537,13 +520,8 @@ AC_DEFUN([TOOLCHAIN_SETUP_MSVC_DLL],
       WIN_VS_TOOLS_DIR="$VS100COMNTOOLS/.."
       UTIL_FIXUP_PATH(WIN_VS_TOOLS_DIR, NOFAIL)
       if test "x$WIN_VS_TOOLS_DIR" != x; then
-        if test "x$OPENJDK_TARGET_CPU_BITS" = x64; then
-          POSSIBLE_MSVC_DLL=`$FIND "$WIN_VS_TOOLS_DIR" -name $DLL_NAME \
-          | $GREP -i /x64/ | $HEAD --lines 1`
-        else
-          POSSIBLE_MSVC_DLL=`$FIND "$WIN_VS_TOOLS_DIR" -name $DLL_NAME \
-          | $GREP -i /x86/ | $HEAD --lines 1`
-        fi
+        POSSIBLE_MSVC_DLL=`$FIND "$WIN_VS_TOOLS_DIR" -name $DLL_NAME \
+          | $GREP -i /$vs_target_cpu/ | $HEAD --lines 1`
         TOOLCHAIN_CHECK_POSSIBLE_MSVC_DLL([$DLL_NAME], [$POSSIBLE_MSVC_DLL],
             [search of VS100COMNTOOLS])
       fi
@@ -554,17 +532,17 @@ AC_DEFUN([TOOLCHAIN_SETUP_MSVC_DLL],
     # Probe: Search wildly in the VCINSTALLDIR. We've probably lost by now.
     # (This was the original behaviour; kept since it might turn something up)
     if test "x$VCINSTALLDIR" != x; then
-      if test "x$OPENJDK_TARGET_CPU_BITS" = x64; then
-        POSSIBLE_MSVC_DLL=`$FIND "$VCINSTALLDIR" -name $DLL_NAME \
-        | $GREP x64 | $HEAD --lines 1`
-      else
+      if test "x$vs_target_cpu" = xx86; then
         POSSIBLE_MSVC_DLL=`$FIND "$VCINSTALLDIR" -name $DLL_NAME \
-        | $GREP x86 | $GREP -v ia64 | $GREP -v x64 | $HEAD --lines 1`
+          | $GREP x86 | $GREP -v ia64 | $GREP -v x64 | $GREP -v arm64 | $HEAD --lines 1`
         if test "x$POSSIBLE_MSVC_DLL" = x; then
           # We're grasping at straws now...
           POSSIBLE_MSVC_DLL=`$FIND "$VCINSTALLDIR" -name $DLL_NAME \
-          | $HEAD --lines 1`
+            | $HEAD --lines 1`
         fi
+      else
+        POSSIBLE_MSVC_DLL=`$FIND "$VCINSTALLDIR" -name $DLL_NAME \
+          | $GREP $vs_target_cpu | $HEAD --lines 1`
       fi

       TOOLCHAIN_CHECK_POSSIBLE_MSVC_DLL([$DLL_NAME], [$POSSIBLE_MSVC_DLL],
@@ -628,9 +606,9 @@ AC_DEFUN([TOOLCHAIN_SETUP_VS_RUNTIME_DLLS],
   fi

   AC_ARG_WITH(vcruntime-1-dll, [AS_HELP_STRING([--with-vcruntime-1-dll],
-      [path to microsoft C++ runtime dll (vcruntime*_1.dll) (Windows x64 only) @<:@probed@:>@])])
+      [path to microsoft C++ runtime dll (vcruntime*_1.dll) (Windows 64-bits only) @<:@probed@:>@])])

-  if test "x$VCRUNTIME_1_NAME" != "x" && test "x$OPENJDK_TARGET_BITS" = x64; then
+  if test "x$VCRUNTIME_1_NAME" != "x" && test "x$OPENJDK_TARGET_CPU_BITS" = x64; then
     if test "x$with_vcruntime_1_dll" != x; then
       # If given explicitly by user, do not probe. If not present, fail directly.
       TOOLCHAIN_CHECK_POSSIBLE_MSVC_DLL($VCRUNTIME_1_NAME, [$with_vcruntime_1_dll],
@@ -695,3 +673,25 @@ AC_DEFUN([TOOLCHAIN_SETUP_VS_RUNTIME_DLLS],
   fi
   AC_SUBST(UCRT_DLL_DIR)
 ])
+
+# Setup the sysroot flags and add them to global CFLAGS and LDFLAGS so
+# that configure can use them while detecting compilers.
+# TOOLCHAIN_TYPE is available here.
+# Param 1 - Optional prefix to all variables. (e.g BUILD_)
+AC_DEFUN([TOOLCHAIN_SETUP_VISUAL_STUDIO_SYSROOT_FLAGS],
+[
+  OLDIFS="$IFS"
+  IFS=":"
+
+  # Convert $1VS_INCLUDE into $1SYSROOT_CFLAGS
+  for ipath in [$]$1VS_INCLUDE; do
+    $1SYSROOT_CFLAGS="[$]$1SYSROOT_CFLAGS -I$ipath"
+  done
+
+  # Convert $1VS_LIB into $1SYSROOT_LDFLAGS
+  for libpath in [$]$1VS_LIB; do
+    $1SYSROOT_LDFLAGS="[$]$1SYSROOT_LDFLAGS -libpath:$libpath"
+  done
+
+  IFS="$OLDIFS"
+])
diff --git a/make/hotspot/gensrc/GensrcAdlc.gmk b/make/hotspot/gensrc/GensrcAdlc.gmk
index 0947133c16e..bcdea62590d 100644
--- a/make/hotspot/gensrc/GensrcAdlc.gmk
+++ b/make/hotspot/gensrc/GensrcAdlc.gmk
@@ -88,6 +88,10 @@ ifeq ($(call check-jvm-feature, compiler2), true)
     ADLCFLAGS += -DAIX=1
   else ifeq ($(call isTargetOs, macosx), true)
     ADLCFLAGS += -D_ALLBSD_SOURCE=1 -D_GNU_SOURCE=1
+  else ifeq ($(call isTargetOs, windows), true)
+    ifeq ($(call isTargetCpuBits, 64), true)
+      ADLCFLAGS += -D_WIN64=1
+    endif
   endif

   ifeq ($(call isTargetOs, windows), false)
diff --git a/make/modules/java.base/gensrc/GensrcMisc.gmk b/make/modules/java.base/gensrc/GensrcMisc.gmk
index cd12f2ab318..5390fcabe85 100644
--- a/make/modules/java.base/gensrc/GensrcMisc.gmk
+++ b/make/modules/java.base/gensrc/GensrcMisc.gmk
@@ -60,6 +60,10 @@ ifneq ($(filter $(TOOLCHAIN_TYPE), gcc clang), )
   CPP_FLAGS += -x c
 else ifeq ($(TOOLCHAIN_TYPE), microsoft)
   CPP_FLAGS += -nologo
+
+  # cl.exe does only recognize few file extensions as valid (ex: .c, .h, .cpp), so
+  # make sure *.java.template files are recognized as valid input files
+  CPP_FILEPREFIX = -Tc
 endif

 # Generate a java source file from a template through the C preprocessor for the
@@ -73,7 +77,7 @@ define generate-preproc-src
        $(call MakeDir, $(@D))
        $(call ExecuteWithLog, $(SUPPORT_OUTPUTDIR)/gensrc/java.base/_$(@F), \
            ( $(NAWK) '/@@END_COPYRIGHT@@/{exit}1' $< && \
-             $(CPP) $(CPP_FLAGS) $(SYSROOT_CFLAGS) $(CFLAGS_JDKLIB) $< \
+             $(CPP) $(CPP_FLAGS) $(SYSROOT_CFLAGS) $(CFLAGS_JDKLIB) $(CPP_FILEPREFIX) $< \
                  2> >($(GREP) -v '^$(<F)$$' >&2) \
                  | $(NAWK) '/@@START_HERE@@/,0' \
                  |  $(SED) -e 's/@@START_HERE@@/\/\/ AUTOMATICALLY GENERATED FILE - DO NOT EDIT/' \

Thank you,

--
Ludovic


________________________________________
From: build-dev <build-dev-retn at openjdk.java.net> on behalf of Yasumasa Suenaga <suenaga at oss.nttdata.com>
Sent: Sunday, July 5, 2020 19:19
To: Magnus Ihse Bursie; build-dev
Subject: Re: Preliminary review for new WINENV support

Hi Magnus,

It's awesome work! I tested your patch, but I saw some errors (configure --enable-debug --with-boot-jdk=/path/to/jdk14):


1) script error
checking for gdiff... /mnt/d/test/jdk-master/build/.configure-support/generated-configure.sh: line 9989: test: /mnt/c/Program: binary operator expected
/mnt/d/test/jdk-master/build/.configure-support/generated-configure.sh: line 9993: test: /mnt/c/Program: binary operator expected
/mnt/d/test/jdk-master/build/.configure-support/generated-configure.sh: line 9989: test: too many arguments

2) warning in awk
configure: Found potential Boot JDK using configure arguments
gawk: cmd. line:1: warning: regexp escape sequence `\"' is not a known regexp operator
checking for Boot JDK... /mnt/c/java/jdk-14.0.1

3) command not found at fixpath.sh (it happens on `make images`)
/mnt/d/test/jdk-master/make/scripts/fixpath.sh: line 402: /mnt/d/test/jdk-master/build/windows-x86_64-server-fastdebug/jdk/bin/java: No such file or directory


I fixed them with following patch, and it works fine on my WSL 1.

```
diff --git a/make/autoconf/boot-jdk.m4 b/make/autoconf/boot-jdk.m4
index 7059558b2..db73eba15 100644
--- a/make/autoconf/boot-jdk.m4
+++ b/make/autoconf/boot-jdk.m4
@@ -77,7 +77,7 @@ AC_DEFUN([BOOTJDK_DO_CHECK],
            # Additional [] needed to keep m4 from mangling shell constructs.
            java_to_test="$BOOT_JDK/bin/java"
            UTIL_FIXUP_EXECUTABLE(java_to_test)
-          [ BOOT_JDK_VERSION=`$java_to_test $USER_BOOT_JDK_OPTIONS -version 2>&1 | $AWK '/version \"[0-9a-zA-Z\._\-]+\"/{print $ 0; exit;}'` ]
+          [ BOOT_JDK_VERSION=`$java_to_test $USER_BOOT_JDK_OPTIONS -version 2>&1 | $AWK '/version "[0-9a-zA-Z\._\-]+"/{print $ 0; exit;}'` ]
            if [ [[ "$BOOT_JDK_VERSION" =~ "Picked up" ]] ]; then
              AC_MSG_NOTICE([You have _JAVA_OPTIONS or JAVA_TOOL_OPTIONS set. This can mess up the build. Please use --with-boot-jdk-jvmargs instead.])
              AC_MSG_NOTICE([Java reports: "$BOOT_JDK_VERSION".])
diff --git a/make/autoconf/util_paths.m4 b/make/autoconf/util_paths.m4
index 8dec82fdc..3d20d1700 100644
--- a/make/autoconf/util_paths.m4
+++ b/make/autoconf/util_paths.m4
@@ -377,11 +377,11 @@ AC_DEFUN([UTIL_LOOKUP_PROGS],
              continue
            fi
            full_path="$elem/$name"
-          if test ! -e $full_path && test "x$OPENJDK_BUILD_OS" = "xwindows"; then
+          if test ! -e "$full_path" && test "x$OPENJDK_BUILD_OS" = "xwindows"; then
              # Try again with .exe
              full_path="$elem/$name.exe"
            fi
-          if test -e $full_path; then
+          if test -e "$full_path"; then
              $1="$full_path"
              UTIL_FIXUP_EXECUTABLE($1, $3)
              result="[$]$1"
diff --git a/make/scripts/fixpath.sh b/make/scripts/fixpath.sh
index 14eacbec6..f8293a798 100644
--- a/make/scripts/fixpath.sh
+++ b/make/scripts/fixpath.sh
@@ -393,6 +393,10 @@ function exec_command_line() {
      fi
    done

+  if [ ! -e "$command" ]; then
+    command="$command".exe
+  fi
+
    # Now execute it
    if [[ -v DEBUG_FIXPATH ]]; then
      echo fixpath: debug: "$command" "${collected_args[@]}" >&2
```

I tried to build on WSL 2, but I couldn't because the process seemed to hangup.
configure script could work normally, but I saw following message on my console in the end.
I guess it is not an issue in your patch because I haven't seen it on WSL 1.

```
cat: standard output: No such file or directory
```

Also I saw LNK1158 error as following, but it might be caused by my environment - my Windows box has been installed both Visual Studio 2019 and Windows SDK.
(My PC is set locale to Japanese, sorry :)

* For target hotspot_variant-server_libjvm_objs_BUILD_LIBJVM_link:
    ????? d:\test\jdk-master\build\windows-x86_64-server-fastdebug\hotspot\variant-server\libjvm\objs\jvm.lib ??????? d:\test\jdk-master\build\windows-x86_64-server-fastdebug\hotspot\variant-server\libjvm\objs\jvm.exp ????
LINK : fatal error LNK1158: 'rc.exe' ?????????

I could solve the problem in the way the following URL indicate.

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F35215971%2Flnk1158-cannot-run-rc-exe-x64-visual-studio&amp;data=02%7C01%7Cluhenry%40microsoft.com%7C0af6353951e7444afe0f08d8215372b6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637295989593225573&amp;sdata=NAyBUTKSQF8PrSgfa5nQADyYvzWdo4Ipi4csjjLiENc%3D&amp;reserved=0


Thanks,

Yasumasa


On 2020/07/05 9:08, Magnus Ihse Bursie wrote:
> 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%2F&amp;data=02%7C01%7Cluhenry%40microsoft.com%7C0af6353951e7444afe0f08d8215372b6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637295989593225573&amp;sdata=x2l2BWhjrvdlMRN3NdZFEU0Vq3mv7SSLiSG9nk7bYE4%3D&amp;reserved=0
>
> (If you prefer, you can check out the branch "ihse-winenv-branch" on https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.openjdk.java.net%2Fjdk%2Fsandbox%2F&amp;data=02%7C01%7Cluhenry%40microsoft.com%7C0af6353951e7444afe0f08d8215372b6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637295989593235570&amp;sdata=jUbEnTaogeVOgP%2BjSe2JyFH1wyx2eX6rBw%2F3ydXlnkI%3D&amp;reserved=0 instead of downloading the patch from the webrev.)
>
> I am leaving on vacation next week, so I won't be doing any more work on this for a while, but I promise to read all emails when I get back and try to rectify all issues that are reported. This means you have some time to try it out, too.
>
> Here are some technical notes of what is changing, compared to the current Windows build.
>
> The native "fixpath.exe" tool is gone. This means that we do not need to compile it during configure, which was always tricky to get right (mostly since we did not have fixpath in place to help us...).
>
> Instead, there is a new fixpath.sh shell script, that does the same job, and more. The script is written in highly optimized shell code (yeah, I see the oxymoron) so only bash internal functionality is used, to avoid calling external tools, which is expensive on Windows. This makes the performance practically roughly at par with the native fixpath.exe.
>
> Fixpath also has a "print" and "import" mode, apart from the traditional"exec" mode. This makes it possible to use the same tool for converting individual paths at runtime to Windows style ("print"), and it takes the logic needed to "import" paths given by the user to configure, into a format usable internally by the build system, and moves it into a centralized location in the fixpath script.
>
> A "winenv" is defined by a quartet of variables: PATHTOOL, DRIVEPREFIX, ENVROOT and WINTEMP. For instance, for "cygwin", these are:
>   PATHTOOL=cygpath
>   DRIVEPREFIX=/cygdrive (typically)
>   ENVROOT=C:\Cygwin64 (typically)
>   WINTEMP=/tmp
>
> These are needed for fixpath to do it's magic. Fixpath can auto-detect those, but to save on execution time they are normally detected by configure and sent as arguments to fixpath.
>
> Detection of the Visual Studio environment has been massively simplified. Using fixpath, conversion between Windows and unix paths is not so complex anymore. The bridge Windows batch file that is needed to extract the environment variables is no longer created on the fly, but is instead stored in make/scripts/extract-vs-env.cmd. This is called with fixpath, so all arguments to it can be unix paths.
>
> Furthermore, TOOLCHAIN_SETUP_VISUAL_STUDIO_ENV is now clearly designed to have a single responsibility, to set SYSROOT flags (and TOOLCHAIN_PATH) for the microsoft toolchain. As a result of this, it is now called from FLAGS_SETUP_SYSROOT_FLAGS. Also, the file toolchain_windows.m4 is now more correctly named toolchain_microsoft.m4. A price we had to pay for this was that the old idea that you should be able to start a "Visual Studio console" and then run configure from it to extract the variables do not work anymore. (It had not been tested for ages, and might have been broken anyway.)
>
> Fixpath also knows about the difference between unix path lists (/foo/bar:/my/dir) and windows path lists (c:\dir;d:\data) and can convert freely and automatically between them. This furthermore means that PATH_SEP is removed, and we only use unix style (colon separated) path lists internally.
>
> The logic automatically detects if and when .exe is needed, so EXE_SUFFIX is removed too. There are some limitations; when code needs to explicitly test for the presence of a file, the suffix needs to be correct. Also when make files check for e.g. the generated bin/java.exe, the suffix needs to be present. For this, I have introduced an EXECUTABLE_SUFFIX, that has the same value as EXE_SUFFIX -- but not the same semantics! The old code added EXE_SUFFIX here and there, not caring about if we meant "microsoft" as a toolchain or if we were running on Windows as a build platform. Clearly not well adapted for future cross-compilation.
>
> The old ways of locating programs in configure were messy, complicated and not always correct. We used a mixture of the original autoconf macros, and our own UTIL_PATH_PROGS and UTIL_CHECK_TOOLS. These did not have very well defined semantics, and were frequently mixed up. Also, UTIL_CHECK_TOOLS required UTIL_FIXUP_EXECUTABLE tobe called afterwards, to "rewrite" the result in a second step. This was not needed after UTIL_PATH_PROGS but was frequently done anyway to "be on the safe side".
>
> I have now replaced:
>    AC_(PATH|CHECK)_(PROG|PROGS) with UTIL_LOOKUP_PROGS
>    AC_(PATH|CHECK)_(TOOL|TOOLS) with UTIL_LOOKUP_TOOLCHAIN_PROGS
>
> This is actually almost the same semantic, but unless you're an autoconf aficionado, you ar not likely to understand the difference     between "PROG" and "TOOL". The only difference is that UTIL_LOOKUP_TOOLCHAIN_PROGS will try to look for "host-prefixed" tools first, when cross-compiling, and should therefore be used for all toolchain lookups.
>
> There is also a fail-fast version of both, UTIL_REQUIRE_PROGS and UTIL_REQUIRE_TOOLCHAIN_PROGS.
>
> UTIL_LOOKUP_PROGS is the core function, with the rest being thin wrappers around it. This function is created from scratch, to do exactly what we want, on Unix platforms and Windows. So there is no need anymore to call UTIL_FIXUP_EXECUTABLE, unless you have input from elsewhere (e.g. user flag) that you need to verify. I have also collected all this logic in a single file, util_paths.m4, moving parts from util.m4, and just removing util_windows.m4.
>
> UTIL_LOOKUP_PROGS will use the new and nifty function UTIL_CHECK_WINENV_EXEC_TYPE, which will automatically determine if an executable needs to be prefixed by fixpath! That means that you can match and mix Windows-style and Unix-style programs however you like, with very few limitations. For instance, you can have a Linux version of the BootJDK on WSL. For this to work, the $FIXPATH prefix is now stored in the variables themselves (e.g. in $CC), rather than added as @FIXPATH@ in spec.gmk.in. This has generally worked out OK, but caused some headaches when the code thought that $CC (etc) was not a way to launch a program, but was a file that could be tested for existence, etc.
>
> I reintroduced support for msys2. This was mostly free, since msys2 is so close to cygwin (which msys never where). To underline the difference, I renamed the winenv windows.msys2 (instead of windows.msys). Msys (version 1) will never be supported in modern OpenJDK due to critical packages being far too old, and not updated. I also clearly separate between WSL1 (which is using a kernel emulation layer, somewhat like Wine) and WSL2 (which is using a Hyper-V VM to run an actual Linux kernel), as windows.wsl1 and windows.wsl2.
>
> I have also done a ton of small fixes, to make things more convenient and smooth when working in these winenvs. I have adjusted the output from configure to be less verbose and more streamlined. Overall, a lot of odd code in configure has been removed. A few changes that are strictly unneeded for this patch has also been included; mostly removal of dead code I came across, and a few fixes for additional debuggability that I needed when developing this patch, like ExecuteithLog.
>
> I have also temporarily disabled the javac server, and building without absolute paths. I believe a better way forward is to address these with improved functionality in separate patches, instead of trying to work around the issues introduced by them in this patch.
>
> I have done substantial testing of the core functionality (building jdk-images) on Cygwin, Msys2 and WSL2, both on my personal machine and on Oracle's CI system. The performance on Cygwin (which we use for our CI builds) is roughly on par with the old Cygwin performance, but the WSL1 performance is roughly 20% faster, so I think we should investigate if it is possible for us to switch to WSL1. Everything seems stable so far, but more testing is definitely needed. I have also not even started testing autxillary     functionality, such as the compare script, IDE project file generation etc.
>
> However, the big disappointment in all of this is WSL2. That was the main driver that got me started on this rewrite. But it turned out that WSL2 is still very immature. :-( There are lot of issues, like stdout and stderr getting messed up, time synchronization issues causing make to complain about "Clock skew detected", extreme slowness when accessing disks cross the OS boundary. But worst of all has been that WSL2 is *extremly* unstable. After a few calls of Window executables, I get the impression that a conversion daemon dies. All further calls to Window binaries just stalls, and the WSL2 instance is unusable until I terminate it using "wsl -t Ubuntu-2004" from a cmd shell. :-(
>
> So the WSL2 functionality is not very well tested, since I have not been able to build it completely a single time. I do believe that everything is correct, in "theory". So in case this is something broken with my WSL2 installation, I'd encourage anyone with a WSL2 installation to try it out.
>
> /Magnus
>


From luhenry at microsoft.com  Tue Jul  7 20:52:46 2020
From: luhenry at microsoft.com (Ludovic Henry)
Date: Tue, 7 Jul 2020 20:52:46 +0000
Subject: OpenJDK extension to AArch64 and Windows
In-Reply-To: <3c43d27c-e3dd-63f3-46ac-86efa015a0ac@oracle.com>
References: <DM6PR21MB132317DB60F918EB7581AB18E5950@DM6PR21MB1323.namprd21.prod.outlook.com>
 <7148d08d-9510-9ad4-6b65-f833f6bacd37@oracle.com>
 <MWHPR21MB0511C10B0DD39D88A94CA8D2B0950@MWHPR21MB0511.namprd21.prod.outlook.com>
 <<de4b6ad9-7313-7e58-5547-fc483eb541ec@oracle.com>
 <CY4PR21MB05025470D9B09E3751E4A936B06E0@CY4PR21MB0502.namprd21.prod.outlook.com>,
 <3c43d27c-e3dd-63f3-46ac-86efa015a0ac@oracle.com>
Message-ID: <MWHPR21MB0511FEB6F1BFCBF7CE4B9802B0660@MWHPR21MB0511.namprd21.prod.outlook.com>

Hi Magnus,

Dropping hotspot-runtime-dev.

As you posted the patch you mentioned before (see https://mail.openjdk.java.net/pipermail/build-dev/2020-July/027872.html), I want to share an updated patch for the build system rebased on top of your patch. (I understand your patch still needs to go through a review, but I hope this will give us a better reference point on what adding support for Windows-AArch64 would look like in the build system.)

As I mentioned in your patch's discussion, I've broken down adding the support for Windows-AArch64 into 2 bits: [1] adding support for cross-compilation when targetting Windows, and [2] adding support for targetting Windows-AArch64. The two patches are available below.

Is it more in line with what you have in mind?

Thank you,

--
Ludovic


[1] Adding support for cross-compilation when targetting Windows

```
diff --git a/make/autoconf/basic.m4 b/make/autoconf/basic.m4
index 7248163242d..60b4097cba9 100644
--- a/make/autoconf/basic.m4
+++ b/make/autoconf/basic.m4
@@ -111,6 +111,16 @@ AC_DEFUN([BASIC_EVAL_DEVKIT_VARIABLE],
   fi
 ])
 
+###############################################################################
+# Evaluates platform specific overrides for build devkit variables.
+# $1: Name of variable
+AC_DEFUN([BASIC_EVAL_BUILD_DEVKIT_VARIABLE],
+[
+  if test "x[$]$1" = x; then
+    eval $1="\${$1_${OPENJDK_BUILD_CPU}}"
+  fi
+])
+
 ###############################################################################
 AC_DEFUN_ONCE([BASIC_SETUP_DEVKIT],
 [
diff --git a/make/autoconf/flags-ldflags.m4 b/make/autoconf/flags-ldflags.m4
index a2a52f98ef7..8af9a20b5e8 100644
--- a/make/autoconf/flags-ldflags.m4
+++ b/make/autoconf/flags-ldflags.m4
@@ -164,15 +164,14 @@ AC_DEFUN([FLAGS_SETUP_LDFLAGS_CPU_DEP],
     fi
 
   elif test "x$TOOLCHAIN_TYPE" = xmicrosoft; then
-    if test "x${OPENJDK_$1_CPU}" = "xx86"; then
-      $1_CPU_LDFLAGS="-safeseh"
-      # NOTE: Old build added -machine. Probably not needed.
-      $1_CPU_LDFLAGS_JVM_ONLY="-machine:I386"
+    if test "x${OPENJDK_$1_CPU_BITS}" = "x32"; then
       $1_CPU_EXECUTABLE_LDFLAGS="-stack:327680"
-    else
-      $1_CPU_LDFLAGS_JVM_ONLY="-machine:AMD64"
+    elif test "x${OPENJDK_$1_CPU_BITS}" = "x64"; then
       $1_CPU_EXECUTABLE_LDFLAGS="-stack:1048576"
     fi
+    if test "x${OPENJDK_$1_CPU}" = "xx86"; then
+      $1_CPU_LDFLAGS="-safeseh"
+    fi
   fi
 
   # JVM_VARIANT_PATH depends on if this is build or target...
diff --git a/make/autoconf/flags.m4 b/make/autoconf/flags.m4
index 694d41052ba..8cbf306ab0c 100644
--- a/make/autoconf/flags.m4
+++ b/make/autoconf/flags.m4
@@ -204,32 +204,36 @@ AC_DEFUN_ONCE([FLAGS_SETUP_USER_SUPPLIED_FLAGS],
 # Param 1 - Optional prefix to all variables. (e.g BUILD_)
 AC_DEFUN([FLAGS_SETUP_SYSROOT_FLAGS],
 [
-  if test "x[$]$1SYSROOT" != "x"; then
-    if test "x$TOOLCHAIN_TYPE" = xgcc; then
-      $1SYSROOT_CFLAGS="--sysroot=[$]$1SYSROOT"
-      $1SYSROOT_LDFLAGS="--sysroot=[$]$1SYSROOT"
-    elif test "x$TOOLCHAIN_TYPE" = xclang; then
-      $1SYSROOT_CFLAGS="-isysroot [$]$1SYSROOT"
-      $1SYSROOT_LDFLAGS="-isysroot [$]$1SYSROOT"
-    fi
-  fi
-
-  if test "x$OPENJDK_TARGET_OS" = xmacosx; then
-    # We also need -iframework<path>/System/Library/Frameworks
-    $1SYSROOT_CFLAGS="[$]$1SYSROOT_CFLAGS -iframework [$]$1SYSROOT/System/Library/Frameworks"
-    $1SYSROOT_LDFLAGS="[$]$1SYSROOT_LDFLAGS -iframework [$]$1SYSROOT/System/Library/Frameworks"
-    # These always need to be set, or we can't find the frameworks embedded in JavaVM.framework
-    # set this here so it doesn't have to be peppered throughout the forest
-    $1SYSROOT_CFLAGS="[$]$1SYSROOT_CFLAGS -F [$]$1SYSROOT/System/Library/Frameworks/JavaVM.framework/Frameworks"
-    $1SYSROOT_LDFLAGS="[$]$1SYSROOT_LDFLAGS -F [$]$1SYSROOT/System/Library/Frameworks/JavaVM.framework/Frameworks"
-  fi
-
   # For the microsoft toolchain, we need to get the SYSROOT flags from the
   # Visual Studio environment. Currently we cannot handle this as a separate
   # build toolchain.
-  if test "x$1" = x && test "x$OPENJDK_BUILD_OS" = "xwindows" \
-      && test "x$TOOLCHAIN_TYPE" = "xmicrosoft"; then
-    TOOLCHAIN_SETUP_VISUAL_STUDIO_ENV
+  if test "x$TOOLCHAIN_TYPE" = "xmicrosoft"; then
+    # The BUILD_* flags are setup in TOOLCHAIN_SETUP_BUILD_COMPILERS
+    if test "x$1" = x; then
+      TOOLCHAIN_SETUP_VISUAL_STUDIO_ENV
+    fi
+
+    TOOLCHAIN_SETUP_VISUAL_STUDIO_SYSROOT_FLAGS([$1])
+  else
+    if test "x[$]$1SYSROOT" != "x"; then
+      if test "x$TOOLCHAIN_TYPE" = xgcc; then
+        $1SYSROOT_CFLAGS="--sysroot=[$]$1SYSROOT"
+        $1SYSROOT_LDFLAGS="--sysroot=[$]$1SYSROOT"
+      elif test "x$TOOLCHAIN_TYPE" = xclang; then
+        $1SYSROOT_CFLAGS="-isysroot [$]$1SYSROOT"
+        $1SYSROOT_LDFLAGS="-isysroot [$]$1SYSROOT"
+      fi
+    fi
+
+    if test "x$OPENJDK_TARGET_OS" = xmacosx; then
+      # We also need -iframework<path>/System/Library/Frameworks
+      $1SYSROOT_CFLAGS="[$]$1SYSROOT_CFLAGS -iframework [$]$1SYSROOT/System/Library/Frameworks"
+      $1SYSROOT_LDFLAGS="[$]$1SYSROOT_LDFLAGS -iframework [$]$1SYSROOT/System/Library/Frameworks"
+      # These always need to be set, or we can't find the frameworks embedded in JavaVM.framework
+      # set this here so it doesn't have to be peppered throughout the forest
+      $1SYSROOT_CFLAGS="[$]$1SYSROOT_CFLAGS -F [$]$1SYSROOT/System/Library/Frameworks/JavaVM.framework/Frameworks"
+      $1SYSROOT_LDFLAGS="[$]$1SYSROOT_LDFLAGS -F [$]$1SYSROOT/System/Library/Frameworks/JavaVM.framework/Frameworks"
+    fi
   fi
 
   AC_SUBST($1SYSROOT_CFLAGS)
@@ -373,7 +377,8 @@ AC_DEFUN_ONCE([FLAGS_POST_TOOLCHAIN],
 [
   FLAGS_SETUP_TOOLCHAIN_CONTROL
 
-  if test "x$BUILD_SYSROOT" != x; then
+  if test "x$BUILD_SYSROOT" != x || \
+      test "x$TOOLCHAIN_TYPE" = "xmicrosoft"; then
     FLAGS_SETUP_SYSROOT_FLAGS([BUILD_])
   else
     if test "x$COMPILE_TYPE" != "xcross"; then
diff --git a/make/autoconf/toolchain.m4 b/make/autoconf/toolchain.m4
index 14213f896d4..4a2462c2dd6 100644
--- a/make/autoconf/toolchain.m4
+++ b/make/autoconf/toolchain.m4
@@ -798,14 +798,18 @@ AC_DEFUN_ONCE([TOOLCHAIN_SETUP_BUILD_COMPILERS],
           . $CONFIGURESUPPORT_OUTPUTDIR/build-devkit.info
           # This potentially sets the following:
           # A descriptive name of the devkit
-          BASIC_EVAL_DEVKIT_VARIABLE([BUILD_DEVKIT_NAME])
+          BASIC_EVAL_BUILD_DEVKIT_VARIABLE([BUILD_DEVKIT_NAME])
           # Corresponds to --with-extra-path
-          BASIC_EVAL_DEVKIT_VARIABLE([BUILD_DEVKIT_EXTRA_PATH])
+          BASIC_EVAL_BUILD_DEVKIT_VARIABLE([BUILD_DEVKIT_EXTRA_PATH])
           # Corresponds to --with-toolchain-path
-          BASIC_EVAL_DEVKIT_VARIABLE([BUILD_DEVKIT_TOOLCHAIN_PATH])
+          BASIC_EVAL_BUILD_DEVKIT_VARIABLE([BUILD_DEVKIT_TOOLCHAIN_PATH])
           # Corresponds to --with-sysroot
-          BASIC_EVAL_DEVKIT_VARIABLE([BUILD_DEVKIT_SYSROOT])
-          # Skip the Window specific parts
+          BASIC_EVAL_BUILD_DEVKIT_VARIABLE([BUILD_DEVKIT_SYSROOT])
+
+          if test "x$TOOLCHAIN_TYPE" = xmicrosoft; then
+            BASIC_EVAL_BUILD_DEVKIT_VARIABLE([BUILD_DEVKIT_VS_INCLUDE])
+            BASIC_EVAL_BUILD_DEVKIT_VARIABLE([BUILD_DEVKIT_VS_LIB])
+          fi
         fi
 
         AC_MSG_CHECKING([for build platform devkit])
@@ -817,11 +821,17 @@ AC_DEFUN_ONCE([TOOLCHAIN_SETUP_BUILD_COMPILERS],
 
         BUILD_SYSROOT="$BUILD_DEVKIT_SYSROOT"
 
-         # Fallback default of just /bin if DEVKIT_PATH is not defined
+        # Fallback default of just /bin if DEVKIT_PATH is not defined
         if test "x$BUILD_DEVKIT_TOOLCHAIN_PATH" = x; then
           BUILD_DEVKIT_TOOLCHAIN_PATH="$BUILD_DEVKIT_ROOT/bin"
         fi
-        PATH="$BUILD_DEVKIT_TOOLCHAIN_PATH:$BUILD_DEVKIT_EXTRA_PATH"
+
+        UTIL_PREPEND_TO_PATH([PATH],"$BUILD_DEVKIT_TOOLCHAIN_PATH:$BUILD_DEVKIT_EXTRA_PATH")
+
+        if test "x$TOOLCHAIN_TYPE" = xmicrosoft; then
+          BUILD_VS_INCLUDE="${BUILD_DEVKIT_VS_INCLUDE//;/:}"
+          BUILD_VS_LIB="${BUILD_DEVKIT_VS_LIB//;/:}"
+        fi
       fi
     fi
 
@@ -836,9 +846,27 @@ AC_DEFUN_ONCE([TOOLCHAIN_SETUP_BUILD_COMPILERS],
     UTIL_LOOKUP_PROGS(BUILD_STRIP, strip)
     # Assume the C compiler is the assembler
     BUILD_AS="$BUILD_CC -c"
-    # Just like for the target compiler, use the compiler as linker
-    BUILD_LD="$BUILD_CC"
-    BUILD_LDCXX="$BUILD_CXX"
+    if test "x$TOOLCHAIN_TYPE" = xmicrosoft; then
+      # In the Microsoft toolchain we have a separate LD command "link".
+      UTIL_LOOKUP_TOOLCHAIN_PROGS(BUILD_LD, link)
+
+      # Make sure we did not pick up /usr/bin/link, which is the unix-style
+      # link executable.
+      AC_MSG_CHECKING([if the found link.exe is actually the Visual Studio linker])
+      $BUILD_LD --version > /dev/null
+      if test $? -eq 0 ; then
+        AC_MSG_RESULT([no])
+        AC_MSG_ERROR([This is the winenv link tool. Please check your PATH and rerun configure.])
+      else
+        AC_MSG_RESULT([yes])
+      fi
+
+      BUILD_LDCXX="$BUILD_LD"
+    else
+      # Just like for the target compiler, use the compiler as linker
+      BUILD_LD="$BUILD_CC"
+      BUILD_LDCXX="$BUILD_CXX"
+    fi
 
     PATH="$OLDPATH"
 
@@ -879,7 +907,7 @@ AC_DEFUN_ONCE([TOOLCHAIN_MISC_CHECKS],
   # Check for extra potential brokenness.
   if test  "x$TOOLCHAIN_TYPE" = xmicrosoft; then
     # On Windows, double-check that we got the right compiler.
-    CC_VERSION_OUTPUT=`$COMPILER 2>&1 1>/dev/null | $GREP -v 'ERROR.*UtilTranslatePathList' | $HEAD -n 1 | $TR -d '\r'`
+    CC_VERSION_OUTPUT=`$CC 2>&1 1>/dev/null | $GREP -v 'ERROR.*UtilTranslatePathList' | $HEAD -n 1 | $TR -d '\r'`
     COMPILER_CPU_TEST=`$ECHO $CC_VERSION_OUTPUT | $SED -n "s/^.* \(.*\)$/\1/p"`
     if test "x$OPENJDK_TARGET_CPU" = "xx86"; then
       if test "x$COMPILER_CPU_TEST" != "x80x86" -a "x$COMPILER_CPU_TEST" != "xx86"; then
diff --git a/make/autoconf/toolchain_microsoft.m4 b/make/autoconf/toolchain_microsoft.m4
index fd8dfc3641d..2e297dc8be1 100644
--- a/make/autoconf/toolchain_microsoft.m4
+++ b/make/autoconf/toolchain_microsoft.m4
@@ -309,8 +309,8 @@ AC_DEFUN([TOOLCHAIN_FIND_VISUAL_STUDIO],
     eval VS_SUPPORTED="\${VS_SUPPORTED_${VS_VERSION}}"
     eval PLATFORM_TOOLSET="\${VS_VS_PLATFORM_NAME_${VS_VERSION}}"
 
-    VS_INCLUDE=${DEVKIT_VS_INCLUDE//;/:}
-    VS_LIB=${DEVKIT_VS_LIB//;/:}
+    VS_INCLUDE="${DEVKIT_VS_INCLUDE//;/:}"
+    VS_LIB="${DEVKIT_VS_LIB//;/:}"
 
     AC_MSG_NOTICE([Found devkit $VS_DESCRIPTION])
 
@@ -426,21 +426,6 @@ AC_DEFUN([TOOLCHAIN_SETUP_VISUAL_STUDIO_ENV],
 
       # Turn VS_PATH into TOOLCHAIN_PATH
       TOOLCHAIN_PATH="$TOOLCHAIN_PATH:$VS_PATH"
-
-      # Convert VS_INCLUDE into SYSROOT_CFLAGS
-      OLDIFS="$IFS"
-      IFS=":"
-
-      for ipath in $VS_INCLUDE; do
-        SYSROOT_CFLAGS="$SYSROOT_CFLAGS -I$ipath"
-      done
-
-      # Convert VS_LIB into SYSROOT_LDFLAGS
-      for libpath in $VS_LIB; do
-        SYSROOT_LDFLAGS="$SYSROOT_LDFLAGS -libpath:$libpath"
-      done
-
-      IFS="$OLDIFS"
     fi
   else
     AC_MSG_RESULT([not found])
@@ -488,22 +473,20 @@ AC_DEFUN([TOOLCHAIN_SETUP_MSVC_DLL],
   DLL_NAME="$1"
   MSVC_DLL=
 
+  if test "x$OPENJDK_TARGET_CPU" = xx86; then
+    vs_target_cpu=x86
+  elif test "x$OPENJDK_TARGET_CPU" = xx86_64; then
+    vs_target_cpu=x64
+  fi
+
   if test "x$MSVC_DLL" = x; then
     if test "x$VCINSTALLDIR" != x; then
       if test "$VS_VERSION" -lt 2017; then
         # Probe: Using well-known location from Visual Studio 12.0 and older
-        if test "x$OPENJDK_TARGET_CPU_BITS" = x64; then
-          POSSIBLE_MSVC_DLL="$VCINSTALLDIR/redist/x64/microsoft.vc${VS_VERSION_INTERNAL}.crt/$DLL_NAME"
-        else
-          POSSIBLE_MSVC_DLL="$VCINSTALLDIR/redist/x86/microsoft.vc${VS_VERSION_INTERNAL}.crt/$DLL_NAME"
-        fi
+        POSSIBLE_MSVC_DLL="$VCINSTALLDIR/redist/$vs_target_cpu/Microsoft.VC${VS_VERSION_INTERNAL}.CRT/$DLL_NAME"
       else
         # Probe: Using well-known location from VS 2017 and VS 2019
-        if test "x$OPENJDK_TARGET_CPU_BITS" = x64; then
-          POSSIBLE_MSVC_DLL="`ls $VCToolsRedistDir/x64/microsoft.vc${VS_VERSION_INTERNAL}.crt/$DLL_NAME`"
-        else
-          POSSIBLE_MSVC_DLL="`ls $VCToolsRedistDir/x86/microsoft.vc${VS_VERSION_INTERNAL}.crt/$DLL_NAME`"
-        fi
+        POSSIBLE_MSVC_DLL="`ls $VCToolsRedistDir/$vs_target_cpu/microsoft.vc${VS_VERSION_INTERNAL}.crt/$DLL_NAME`"
       fi
       # In case any of the above finds more than one file, loop over them.
       for possible_msvc_dll in $POSSIBLE_MSVC_DLL; do
@@ -537,13 +520,8 @@ AC_DEFUN([TOOLCHAIN_SETUP_MSVC_DLL],
       WIN_VS_TOOLS_DIR="$VS100COMNTOOLS/.."
       UTIL_FIXUP_PATH(WIN_VS_TOOLS_DIR, NOFAIL)
       if test "x$WIN_VS_TOOLS_DIR" != x; then
-        if test "x$OPENJDK_TARGET_CPU_BITS" = x64; then
-          POSSIBLE_MSVC_DLL=`$FIND "$WIN_VS_TOOLS_DIR" -name $DLL_NAME \
-          | $GREP -i /x64/ | $HEAD --lines 1`
-        else
-          POSSIBLE_MSVC_DLL=`$FIND "$WIN_VS_TOOLS_DIR" -name $DLL_NAME \
-          | $GREP -i /x86/ | $HEAD --lines 1`
-        fi
+        POSSIBLE_MSVC_DLL=`$FIND "$WIN_VS_TOOLS_DIR" -name $DLL_NAME \
+          | $GREP -i /$vs_target_cpu/ | $HEAD --lines 1`
         TOOLCHAIN_CHECK_POSSIBLE_MSVC_DLL([$DLL_NAME], [$POSSIBLE_MSVC_DLL],
             [search of VS100COMNTOOLS])
       fi
@@ -554,17 +532,17 @@ AC_DEFUN([TOOLCHAIN_SETUP_MSVC_DLL],
     # Probe: Search wildly in the VCINSTALLDIR. We've probably lost by now.
     # (This was the original behaviour; kept since it might turn something up)
     if test "x$VCINSTALLDIR" != x; then
-      if test "x$OPENJDK_TARGET_CPU_BITS" = x64; then
-        POSSIBLE_MSVC_DLL=`$FIND "$VCINSTALLDIR" -name $DLL_NAME \
-        | $GREP x64 | $HEAD --lines 1`
-      else
+      if test "x$vs_target_cpu" = xx86; then
         POSSIBLE_MSVC_DLL=`$FIND "$VCINSTALLDIR" -name $DLL_NAME \
-        | $GREP x86 | $GREP -v ia64 | $GREP -v x64 | $HEAD --lines 1`
+          | $GREP x86 | $GREP -v ia64 | $GREP -v x64 | $GREP -v arm64 | $HEAD --lines 1`
         if test "x$POSSIBLE_MSVC_DLL" = x; then
           # We're grasping at straws now...
           POSSIBLE_MSVC_DLL=`$FIND "$VCINSTALLDIR" -name $DLL_NAME \
-          | $HEAD --lines 1`
+            | $HEAD --lines 1`
         fi
+      else
+        POSSIBLE_MSVC_DLL=`$FIND "$VCINSTALLDIR" -name $DLL_NAME \
+          | $GREP $vs_target_cpu | $HEAD --lines 1`
       fi
 
       TOOLCHAIN_CHECK_POSSIBLE_MSVC_DLL([$DLL_NAME], [$POSSIBLE_MSVC_DLL],
@@ -628,9 +606,9 @@ AC_DEFUN([TOOLCHAIN_SETUP_VS_RUNTIME_DLLS],
   fi
 
   AC_ARG_WITH(vcruntime-1-dll, [AS_HELP_STRING([--with-vcruntime-1-dll],
-      [path to microsoft C++ runtime dll (vcruntime*_1.dll) (Windows x64 only) @<:@probed@:>@])])
+      [path to microsoft C++ runtime dll (vcruntime*_1.dll) (Windows 64-bits only) @<:@probed@:>@])])
 
-  if test "x$VCRUNTIME_1_NAME" != "x" && test "x$OPENJDK_TARGET_BITS" = x64; then
+  if test "x$VCRUNTIME_1_NAME" != "x" && test "x$OPENJDK_TARGET_CPU_BITS" = x64; then
     if test "x$with_vcruntime_1_dll" != x; then
       # If given explicitly by user, do not probe. If not present, fail directly.
       TOOLCHAIN_CHECK_POSSIBLE_MSVC_DLL($VCRUNTIME_1_NAME, [$with_vcruntime_1_dll],
@@ -695,3 +673,25 @@ AC_DEFUN([TOOLCHAIN_SETUP_VS_RUNTIME_DLLS],
   fi
   AC_SUBST(UCRT_DLL_DIR)
 ])
+
+# Setup the sysroot flags and add them to global CFLAGS and LDFLAGS so
+# that configure can use them while detecting compilers.
+# TOOLCHAIN_TYPE is available here.
+# Param 1 - Optional prefix to all variables. (e.g BUILD_)
+AC_DEFUN([TOOLCHAIN_SETUP_VISUAL_STUDIO_SYSROOT_FLAGS],
+[
+  OLDIFS="$IFS"
+  IFS=":"
+
+  # Convert $1VS_INCLUDE into $1SYSROOT_CFLAGS
+  for ipath in [$]$1VS_INCLUDE; do
+    $1SYSROOT_CFLAGS="[$]$1SYSROOT_CFLAGS -I$ipath"
+  done
+
+  # Convert $1VS_LIB into $1SYSROOT_LDFLAGS
+  for libpath in [$]$1VS_LIB; do
+    $1SYSROOT_LDFLAGS="[$]$1SYSROOT_LDFLAGS -libpath:$libpath"
+  done
+
+  IFS="$OLDIFS"
+])
diff --git a/make/hotspot/gensrc/GensrcAdlc.gmk b/make/hotspot/gensrc/GensrcAdlc.gmk
index 0947133c16e..bcdea62590d 100644
--- a/make/hotspot/gensrc/GensrcAdlc.gmk
+++ b/make/hotspot/gensrc/GensrcAdlc.gmk
@@ -88,6 +88,10 @@ ifeq ($(call check-jvm-feature, compiler2), true)
     ADLCFLAGS += -DAIX=1
   else ifeq ($(call isTargetOs, macosx), true)
     ADLCFLAGS += -D_ALLBSD_SOURCE=1 -D_GNU_SOURCE=1
+  else ifeq ($(call isTargetOs, windows), true)
+    ifeq ($(call isTargetCpuBits, 64), true)
+      ADLCFLAGS += -D_WIN64=1
+    endif
   endif
 
   ifeq ($(call isTargetOs, windows), false)
diff --git a/make/modules/java.base/gensrc/GensrcMisc.gmk b/make/modules/java.base/gensrc/GensrcMisc.gmk
index cd12f2ab318..5390fcabe85 100644
--- a/make/modules/java.base/gensrc/GensrcMisc.gmk
+++ b/make/modules/java.base/gensrc/GensrcMisc.gmk
@@ -60,6 +60,10 @@ ifneq ($(filter $(TOOLCHAIN_TYPE), gcc clang), )
   CPP_FLAGS += -x c
 else ifeq ($(TOOLCHAIN_TYPE), microsoft)
   CPP_FLAGS += -nologo
+
+  # cl.exe does only recognize few file extensions as valid (ex: .c, .h, .cpp), so
+  # make sure *.java.template files are recognized as valid input files
+  CPP_FILEPREFIX = -Tc
 endif
 
 # Generate a java source file from a template through the C preprocessor for the
@@ -73,7 +77,7 @@ define generate-preproc-src
 	$(call MakeDir, $(@D))
 	$(call ExecuteWithLog, $(SUPPORT_OUTPUTDIR)/gensrc/java.base/_$(@F), \
 	    ( $(NAWK) '/@@END_COPYRIGHT@@/{exit}1' $< && \
-	      $(CPP) $(CPP_FLAGS) $(SYSROOT_CFLAGS) $(CFLAGS_JDKLIB) $< \
+	      $(CPP) $(CPP_FLAGS) $(SYSROOT_CFLAGS) $(CFLAGS_JDKLIB) $(CPP_FILEPREFIX) $< \
 	          2> >($(GREP) -v '^$(<F)$$' >&2) \
 	          | $(NAWK) '/@@START_HERE@@/,0' \
 	          |  $(SED) -e 's/@@START_HERE@@/\/\/ AUTOMATICALLY GENERATED FILE - DO NOT EDIT/' \
```

[2] Adding support for targetting Windows-AArch64

```
diff --git a/make/autoconf/flags-cflags.m4 b/make/autoconf/flags-cflags.m4
index f5545caf10d..a8cf273644a 100644
--- a/make/autoconf/flags-cflags.m4
+++ b/make/autoconf/flags-cflags.m4
@@ -650,7 +650,9 @@ AC_DEFUN([FLAGS_SETUP_CFLAGS_CPU_DEP],
 
   # toolchain dependend, per-cpu
   if test "x$TOOLCHAIN_TYPE" = xmicrosoft; then
-    if test "x$FLAGS_CPU" = xx86_64; then
+    if test "x$FLAGS_CPU" = xaarch64; then
+      $1_DEFINES_CPU_JDK="${$1_DEFINES_CPU_JDK} -D_ARM64_ -Darm64"
+    elif test "x$FLAGS_CPU" = xx86_64; then
       $1_DEFINES_CPU_JDK="${$1_DEFINES_CPU_JDK} -D_AMD64_ -Damd64"
     else
       $1_DEFINES_CPU_JDK="${$1_DEFINES_CPU_JDK} -D_X86_ -Dx86"
diff --git a/make/autoconf/jvm-features.m4 b/make/autoconf/jvm-features.m4
index 8ec76f669f7..80678458263 100644
--- a/make/autoconf/jvm-features.m4
+++ b/make/autoconf/jvm-features.m4
@@ -237,8 +237,9 @@ AC_DEFUN_ONCE([JVM_FEATURES_CHECK_AOT],
   JVM_FEATURES_CHECK_AVAILABILITY(aot, [
     AC_MSG_CHECKING([if platform is supported by AOT])
     # AOT is only available where JVMCI is available since it requires JVMCI.
-    if test "x$OPENJDK_TARGET_CPU" = "xx86_64" || \
-        test "x$OPENJDK_TARGET_CPU" = "xaarch64"; then
+    if test "x$OPENJDK_TARGET_CPU" = "xx86_64"; then
+      AC_MSG_RESULT([yes])
+    elif test "x$OPENJDK_TARGET_OS-$OPENJDK_TARGET_CPU" = "xlinux-aarch64"; then
       AC_MSG_RESULT([yes])
     else
       AC_MSG_RESULT([no, $OPENJDK_TARGET_CPU])
@@ -303,8 +304,9 @@ AC_DEFUN_ONCE([JVM_FEATURES_CHECK_GRAAL],
   JVM_FEATURES_CHECK_AVAILABILITY(graal, [
     AC_MSG_CHECKING([if platform is supported by Graal])
     # Graal is only available where JVMCI is available since it requires JVMCI.
-    if test "x$OPENJDK_TARGET_CPU" = "xx86_64" || \
-        test "x$OPENJDK_TARGET_CPU" = "xaarch64" ; then
+    if test "x$OPENJDK_TARGET_CPU" = "xx86_64"; then
+      AC_MSG_RESULT([yes])
+    elif test "x$OPENJDK_TARGET_OS-$OPENJDK_TARGET_CPU" = "xlinux-aarch64"; then
       AC_MSG_RESULT([yes])
     else
       AC_MSG_RESULT([no, $OPENJDK_TARGET_CPU])
@@ -336,8 +338,9 @@ AC_DEFUN_ONCE([JVM_FEATURES_CHECK_JVMCI],
 [
   JVM_FEATURES_CHECK_AVAILABILITY(jvmci, [
     AC_MSG_CHECKING([if platform is supported by JVMCI])
-    if test "x$OPENJDK_TARGET_CPU" = "xx86_64" || \
-        test "x$OPENJDK_TARGET_CPU" = "xaarch64" ; then
+    if test "x$OPENJDK_TARGET_CPU" = "xx86_64"; then
+      AC_MSG_RESULT([yes])
+    elif test "x$OPENJDK_TARGET_OS-$OPENJDK_TARGET_CPU" = "xlinux-aarch64"; then
       AC_MSG_RESULT([yes])
     else
       AC_MSG_RESULT([no, $OPENJDK_TARGET_CPU])
@@ -353,8 +356,9 @@ AC_DEFUN_ONCE([JVM_FEATURES_CHECK_SHENANDOAHGC],
 [
   JVM_FEATURES_CHECK_AVAILABILITY(shenandoahgc, [
     AC_MSG_CHECKING([if platform is supported by Shenandoah])
-    if test "x$OPENJDK_TARGET_CPU_ARCH" = "xx86" || \
-        test "x$OPENJDK_TARGET_CPU" = "xaarch64" ; then
+    if test "x$OPENJDK_TARGET_CPU_ARCH" = "xx86"; then
+      AC_MSG_RESULT([yes])
+    elif test "x$OPENJDK_TARGET_OS-$OPENJDK_TARGET_CPU" = "xlinux-aarch64"; then
       AC_MSG_RESULT([yes])
     else
       AC_MSG_RESULT([no, $OPENJDK_TARGET_CPU])
diff --git a/make/autoconf/toolchain.m4 b/make/autoconf/toolchain.m4
index 4a2462c2dd6..aa77fe1db06 100644
--- a/make/autoconf/toolchain.m4
+++ b/make/autoconf/toolchain.m4
@@ -917,6 +917,10 @@ AC_DEFUN_ONCE([TOOLCHAIN_MISC_CHECKS],
       if test "x$COMPILER_CPU_TEST" != "xx64"; then
         AC_MSG_ERROR([Target CPU mismatch. We are building for $OPENJDK_TARGET_CPU but CL is for "$COMPILER_CPU_TEST"; expected "x64".])
       fi
+    elif test "x$OPENJDK_TARGET_CPU" = "xaarch64"; then
+      if test "x$COMPILER_CPU_TEST" != "xARM64"; then
+        AC_MSG_ERROR([Target CPU mismatch. We are building for $OPENJDK_TARGET_CPU but CL is for "$COMPILER_CPU_TEST"; expected "arm64".])
+      fi
     fi
   fi
 
diff --git a/make/autoconf/toolchain_microsoft.m4 b/make/autoconf/toolchain_microsoft.m4
index 2e297dc8be1..22f4c47e3a3 100644
--- a/make/autoconf/toolchain_microsoft.m4
+++ b/make/autoconf/toolchain_microsoft.m4
@@ -128,11 +128,15 @@ AC_DEFUN([TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT],
       fi
 
       AC_MSG_NOTICE([Found Visual Studio installation at $VS_BASE using $METHOD])
-      if test "x$OPENJDK_TARGET_CPU_BITS" = x32; then
+      if test "x$OPENJDK_TARGET_CPU" = xx86; then
         VCVARSFILES="vc/bin/vcvars32.bat vc/auxiliary/build/vcvars32.bat"
-      else
+      elif test "x$OPENJDK_TARGET_CPU" = xx86_64; then
         VCVARSFILES="vc/bin/amd64/vcvars64.bat vc/bin/x86_amd64/vcvarsx86_amd64.bat \
             vc/auxiliary/build/vcvarsx86_amd64.bat vc/auxiliary/build/vcvars64.bat"
+      elif test "x$OPENJDK_TARGET_CPU" = xaarch64; then
+        # for host x86-64, target aarch64
+        VCVARSFILES="vc/auxiliary/build/vcvarsamd64_arm64.bat \
+            vc/auxiliary/build/vcvarsx86_arm64.bat"
       fi
 
       for VCVARSFILE in $VCVARSFILES; do
@@ -174,10 +178,12 @@ AC_DEFUN([TOOLCHAIN_CHECK_POSSIBLE_WIN_SDK_ROOT],
       elif test -f "$WIN_SDK_BASE/bin/setenv.cmd"; then
         AC_MSG_NOTICE([Found Windows SDK installation at $WIN_SDK_BASE using $METHOD])
         VS_ENV_CMD="$WIN_SDK_BASE/bin/setenv.cmd"
-        if test "x$OPENJDK_TARGET_CPU_BITS" = x32; then
+        if test "x$OPENJDK_TARGET_CPU" = xx86; then
           VS_ENV_ARGS="/x86"
-        else
+        elif test "x$OPENJDK_TARGET_CPU" = xx86_64; then
           VS_ENV_ARGS="/x64"
+        elif test "x$OPENJDK_TARGET_CPU" = xaarch64; then
+          VS_ENV_ARGS="/arm64"
         fi
         # PLATFORM_TOOLSET is used during the compilation of the freetype sources (see
         # 'LIB_BUILD_FREETYPE' in libraries.m4) and must be 'Windows7.1SDK' for Windows7.1SDK
@@ -451,10 +457,15 @@ AC_DEFUN([TOOLCHAIN_CHECK_POSSIBLE_MSVC_DLL],
     # Need to check if the found msvcr is correct architecture
     AC_MSG_CHECKING([found $DLL_NAME architecture])
     MSVC_DLL_FILETYPE=`$FILE -b "$POSSIBLE_MSVC_DLL"`
-    if test "x$OPENJDK_TARGET_CPU_BITS" = x32; then
+    if test "x$OPENJDK_TARGET_CPU" = xx86; then
       CORRECT_MSVCR_ARCH=386
-    else
+    elif test "x$OPENJDK_TARGET_CPU" = xx86_64; then
       CORRECT_MSVCR_ARCH=x86-64
+    elif test "x$OPENJDK_TARGET_CPU" = xaarch64; then
+      # The cygwin 'file' command only returns "PE32+ executable (DLL) (console), for MS Windows",
+      # without specifying which architecture it is for specifically. This has been fixed upstream.
+      # https://github.com/file/file/commit/b849b1af098ddd530094bf779b58431395db2e10#diff-ff2eced09e6860de75057dd731d092aeR142
+      CORRECT_MSVCR_ARCH="PE32+ executable"
     fi
     if $ECHO "$MSVC_DLL_FILETYPE" | $GREP "$CORRECT_MSVCR_ARCH" 2>&1 > /dev/null; then
       AC_MSG_RESULT([ok])
@@ -477,6 +488,8 @@ AC_DEFUN([TOOLCHAIN_SETUP_MSVC_DLL],
     vs_target_cpu=x86
   elif test "x$OPENJDK_TARGET_CPU" = xx86_64; then
     vs_target_cpu=x64
+  elif test "x$OPENJDK_TARGET_CPU" = xaarch64; then
+    vs_target_cpu=arm64
   fi
 
   if test "x$MSVC_DLL" = x; then
@@ -649,8 +662,12 @@ AC_DEFUN([TOOLCHAIN_SETUP_VS_RUNTIME_DLLS],
       AC_MSG_RESULT($UCRT_DLL_DIR)
     else
       dll_subdir=$OPENJDK_TARGET_CPU
-      if test "x$dll_subdir" = "xx86_64"; then
+      if test "x$dll_subdir" = "xaarch64"; then
+        dll_subdir="arm64"
+      elif test "x$dll_subdir" = "xx86_64"; then
         dll_subdir="x64"
+      elif test "x$dll_subdir" = "xx86"; then
+        dll_subdir="x86"
       fi
       UCRT_DLL_DIR="$WINDOWSSDKDIR/redist/ucrt/dlls/$dll_subdir"
       if test -z "$(ls -d "$UCRT_DLL_DIR/"*.dll 2> /dev/null)"; then
diff --git a/make/devkit/createWindowsDevkit2017.sh b/make/devkit/createWindowsDevkit2017.sh
index a802b18a557..91227259bdf 100644
--- a/make/devkit/createWindowsDevkit2017.sh
+++ b/make/devkit/createWindowsDevkit2017.sh
@@ -113,19 +113,23 @@ REDIST_SUBDIR="VC/Redist/MSVC/$REDIST_VERSION"
 echo "Copying VC..."
 rm -rf $DEVKIT_ROOT/VC
 mkdir -p $DEVKIT_ROOT/VC/bin
+cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/bin/Hostx64/arm64" $DEVKIT_ROOT/VC/bin/
 cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/bin/Hostx64/x64" $DEVKIT_ROOT/VC/bin/
 cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/bin/Hostx86/x86" $DEVKIT_ROOT/VC/bin/
 mkdir -p $DEVKIT_ROOT/VC/lib
+cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/lib/arm64" $DEVKIT_ROOT/VC/lib/
 cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/lib/x64" $DEVKIT_ROOT/VC/lib/
 cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/lib/x86" $DEVKIT_ROOT/VC/lib/
 cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/include" $DEVKIT_ROOT/VC/
 mkdir -p $DEVKIT_ROOT/VC/atlmfc/lib
+cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/atlmfc/lib/arm64" $DEVKIT_ROOT/VC/atlmfc/lib/
 cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/atlmfc/lib/x64" $DEVKIT_ROOT/VC/atlmfc/lib/
 cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/atlmfc/lib/x86" $DEVKIT_ROOT/VC/atlmfc/lib/
 cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/atlmfc/include" $DEVKIT_ROOT/VC/atlmfc/
 mkdir -p $DEVKIT_ROOT/VC/Auxiliary
 cp -r "$VS_INSTALL_DIR/VC/Auxiliary/Build" $DEVKIT_ROOT/VC/Auxiliary/
 mkdir -p $DEVKIT_ROOT/VC/redist
+cp -r "$VS_INSTALL_DIR/$REDIST_SUBDIR/arm64" $DEVKIT_ROOT/VC/redist/
 cp -r "$VS_INSTALL_DIR/$REDIST_SUBDIR/x64" $DEVKIT_ROOT/VC/redist/
 cp -r "$VS_INSTALL_DIR/$REDIST_SUBDIR/x86" $DEVKIT_ROOT/VC/redist/
 
@@ -134,7 +138,9 @@ cp -r "$VS_INSTALL_DIR/$REDIST_SUBDIR/x86" $DEVKIT_ROOT/VC/redist/
 cp $DEVKIT_ROOT/VC/redist/x86/$MSVCR_DLL $DEVKIT_ROOT/VC/bin/x86
 cp $DEVKIT_ROOT/VC/redist/x86/$MSVCP_DLL $DEVKIT_ROOT/VC/bin/x86
 cp $DEVKIT_ROOT/VC/redist/x64/$MSVCR_DLL $DEVKIT_ROOT/VC/bin/x64
-cp $DEVKIT_ROOT/VC/redist/x64/$MSVCP_DLL $DEVKIT_ROOT/VC/bin/x64
+cp $DEVKIT_ROOT/VC/redist/x64/$MSVCR_DLL $DEVKIT_ROOT/VC/bin/x64
+cp $DEVKIT_ROOT/VC/redist/arm64/$MSVCP_DLL $DEVKIT_ROOT/VC/bin/arm64
+cp $DEVKIT_ROOT/VC/redist/arm64/$MSVCP_DLL $DEVKIT_ROOT/VC/bin/arm64
 
 ################################################################################
 # Copy SDK files
@@ -152,8 +158,10 @@ mkdir -p $DEVKIT_ROOT/$SDK_VERSION/bin
 cp -r "$SDK_INSTALL_DIR/bin/$SDK_FULL_VERSION/x64" $DEVKIT_ROOT/$SDK_VERSION/bin/
 cp -r "$SDK_INSTALL_DIR/bin/$SDK_FULL_VERSION/x86" $DEVKIT_ROOT/$SDK_VERSION/bin/
 mkdir -p $DEVKIT_ROOT/$SDK_VERSION/lib
+cp -r "$SDK_INSTALL_DIR/lib/$SDK_FULL_VERSION/um/arm64" $DEVKIT_ROOT/$SDK_VERSION/lib/
 cp -r "$SDK_INSTALL_DIR/lib/$SDK_FULL_VERSION/um/x64" $DEVKIT_ROOT/$SDK_VERSION/lib/
 cp -r "$SDK_INSTALL_DIR/lib/$SDK_FULL_VERSION/um/x86" $DEVKIT_ROOT/$SDK_VERSION/lib/
+cp -r "$SDK_INSTALL_DIR/lib/$SDK_FULL_VERSION/ucrt/arm64" $DEVKIT_ROOT/$SDK_VERSION/lib/
 cp -r "$SDK_INSTALL_DIR/lib/$SDK_FULL_VERSION/ucrt/x64" $DEVKIT_ROOT/$SDK_VERSION/lib/
 cp -r "$SDK_INSTALL_DIR/lib/$SDK_FULL_VERSION/ucrt/x86" $DEVKIT_ROOT/$SDK_VERSION/lib/
 mkdir -p $DEVKIT_ROOT/$SDK_VERSION/Redist
@@ -188,6 +196,13 @@ echo-info "DEVKIT_MSVCR_DLL_x86_64=\"\$DEVKIT_ROOT/VC/redist/x64/$MSVCR_DLL\""
 echo-info "DEVKIT_MSVCP_DLL_x86_64=\"\$DEVKIT_ROOT/VC/redist/x64/$MSVCP_DLL\""
 echo-info "DEVKIT_UCRT_DLL_DIR_x86_64=\"\$DEVKIT_ROOT/10/Redist/ucrt/DLLs/x64\""
 echo-info ""
+echo-info "DEVKIT_TOOLCHAIN_PATH_aarch64=\"\$DEVKIT_ROOT/VC/bin/arm64:\$DEVKIT_ROOT/$SDK_VERSION/bin/x64:\$DEVKIT_ROOT/$SDK_VERSION/bin/x86\""
+echo-info "DEVKIT_VS_INCLUDE_aarch64=\"\$DEVKIT_ROOT/VC/include;\$DEVKIT_ROOT/VC/atlmfc/include;\$DEVKIT_ROOT/$SDK_VERSION/include/shared;\$DEVKIT_ROOT/$SDK_VERSION/include/ucrt;\$DEVKIT_ROOT/$SDK_VERSION/include/um;\$DEVKIT_ROOT/$SDK_VERSION/include/winrt\""
+echo-info "DEVKIT_VS_LIB_aarch64=\"\$DEVKIT_ROOT/VC/lib/arm64;\$DEVKIT_ROOT/VC/atlmfc/lib/arm64;\$DEVKIT_ROOT/$SDK_VERSION/lib/arm64\""
+echo-info "DEVKIT_MSVCR_DLL_aarch64=\"\$DEVKIT_ROOT/VC/redist/arm64/$MSVCR_DLL\""
+echo-info "DEVKIT_MSVCP_DLL_aarch64=\"\$DEVKIT_ROOT/VC/redist/arm64/$MSVCP_DLL\""
+echo-info "DEVKIT_UCRT_DLL_DIR_aarch64=\"\$DEVKIT_ROOT/10/Redist/ucrt/DLLs/arm64\""
+echo-info ""
 echo-info "DEVKIT_TOOLS_VERSION=\"$TOOLS_VERSION\""
 echo-info "DEVKIT_REDIST_VERSION=\"$REDIST_VERSION\""
 echo-info "DEVKIT_SDK_VERSION=\"$SDK_FULL_VERSION\""
diff --git a/make/devkit/createWindowsDevkit2019.sh b/make/devkit/createWindowsDevkit2019.sh
index 8a97f0c2a3b..a5c89f09faa 100644
--- a/make/devkit/createWindowsDevkit2019.sh
+++ b/make/devkit/createWindowsDevkit2019.sh
@@ -117,19 +117,23 @@ REDIST_SUBDIR="VC/Redist/MSVC/$REDIST_VERSION"
 echo "Copying VC..."
 rm -rf $DEVKIT_ROOT/VC
 mkdir -p $DEVKIT_ROOT/VC/bin
+cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/bin/Hostx64/arm64" $DEVKIT_ROOT/VC/bin/
 cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/bin/Hostx64/x64" $DEVKIT_ROOT/VC/bin/
 cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/bin/Hostx86/x86" $DEVKIT_ROOT/VC/bin/
 mkdir -p $DEVKIT_ROOT/VC/lib
+cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/lib/arm64" $DEVKIT_ROOT/VC/lib/
 cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/lib/x64" $DEVKIT_ROOT/VC/lib/
 cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/lib/x86" $DEVKIT_ROOT/VC/lib/
 cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/include" $DEVKIT_ROOT/VC/
 mkdir -p $DEVKIT_ROOT/VC/atlmfc/lib
+cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/atlmfc/lib/arm64" $DEVKIT_ROOT/VC/atlmfc/lib/
 cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/atlmfc/lib/x64" $DEVKIT_ROOT/VC/atlmfc/lib/
 cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/atlmfc/lib/x86" $DEVKIT_ROOT/VC/atlmfc/lib/
 cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/atlmfc/include" $DEVKIT_ROOT/VC/atlmfc/
 mkdir -p $DEVKIT_ROOT/VC/Auxiliary
 cp -r "$VS_INSTALL_DIR/VC/Auxiliary/Build" $DEVKIT_ROOT/VC/Auxiliary/
 mkdir -p $DEVKIT_ROOT/VC/redist
+cp -r "$VS_INSTALL_DIR/$REDIST_SUBDIR/arm64" $DEVKIT_ROOT/VC/redist/
 cp -r "$VS_INSTALL_DIR/$REDIST_SUBDIR/x64" $DEVKIT_ROOT/VC/redist/
 cp -r "$VS_INSTALL_DIR/$REDIST_SUBDIR/x86" $DEVKIT_ROOT/VC/redist/
 
@@ -139,6 +143,8 @@ cp $DEVKIT_ROOT/VC/redist/x86/$MSVCR_DLL $DEVKIT_ROOT/VC/bin/x86
 cp $DEVKIT_ROOT/VC/redist/x86/$MSVCP_DLL $DEVKIT_ROOT/VC/bin/x86
 cp $DEVKIT_ROOT/VC/redist/x64/$MSVCR_DLL $DEVKIT_ROOT/VC/bin/x64
 cp $DEVKIT_ROOT/VC/redist/x64/$MSVCP_DLL $DEVKIT_ROOT/VC/bin/x64
+cp $DEVKIT_ROOT/VC/redist/arm64/$MSVCR_DLL $DEVKIT_ROOT/VC/bin/arm64
+cp $DEVKIT_ROOT/VC/redist/arm64/$MSVCP_DLL $DEVKIT_ROOT/VC/bin/arm64
 
 ################################################################################
 # Copy SDK files
@@ -156,8 +162,10 @@ mkdir -p $DEVKIT_ROOT/$SDK_VERSION/bin
 cp -r "$SDK_INSTALL_DIR/bin/$SDK_FULL_VERSION/x64" $DEVKIT_ROOT/$SDK_VERSION/bin/
 cp -r "$SDK_INSTALL_DIR/bin/$SDK_FULL_VERSION/x86" $DEVKIT_ROOT/$SDK_VERSION/bin/
 mkdir -p $DEVKIT_ROOT/$SDK_VERSION/lib
+cp -r "$SDK_INSTALL_DIR/lib/$SDK_FULL_VERSION/um/arm64" $DEVKIT_ROOT/$SDK_VERSION/lib/
 cp -r "$SDK_INSTALL_DIR/lib/$SDK_FULL_VERSION/um/x64" $DEVKIT_ROOT/$SDK_VERSION/lib/
 cp -r "$SDK_INSTALL_DIR/lib/$SDK_FULL_VERSION/um/x86" $DEVKIT_ROOT/$SDK_VERSION/lib/
+cp -r "$SDK_INSTALL_DIR/lib/$SDK_FULL_VERSION/ucrt/arm64" $DEVKIT_ROOT/$SDK_VERSION/lib/
 cp -r "$SDK_INSTALL_DIR/lib/$SDK_FULL_VERSION/ucrt/x64" $DEVKIT_ROOT/$SDK_VERSION/lib/
 cp -r "$SDK_INSTALL_DIR/lib/$SDK_FULL_VERSION/ucrt/x86" $DEVKIT_ROOT/$SDK_VERSION/lib/
 mkdir -p $DEVKIT_ROOT/$SDK_VERSION/Redist
@@ -193,6 +201,14 @@ echo-info "DEVKIT_VCRUNTIME_1_DLL_x86_64=\"\$DEVKIT_ROOT/VC/redist/x64/$VCRUNTIM
 echo-info "DEVKIT_MSVCP_DLL_x86_64=\"\$DEVKIT_ROOT/VC/redist/x64/$MSVCP_DLL\""
 echo-info "DEVKIT_UCRT_DLL_DIR_x86_64=\"\$DEVKIT_ROOT/10/Redist/ucrt/DLLs/x64\""
 echo-info ""
+echo-info "DEVKIT_TOOLCHAIN_PATH_aarch64=\"\$DEVKIT_ROOT/VC/bin/arm64:\$DEVKIT_ROOT/$SDK_VERSION/bin/x64:\$DEVKIT_ROOT/$SDK_VERSION/bin/x86\""
+echo-info "DEVKIT_VS_INCLUDE_aarch64=\"\$DEVKIT_ROOT/VC/include;\$DEVKIT_ROOT/VC/atlmfc/include;\$DEVKIT_ROOT/$SDK_VERSION/include/shared;\$DEVKIT_ROOT/$SDK_VERSION/include/ucrt;\$DEVKIT_ROOT/$SDK_VERSION/include/um;\$DEVKIT_ROOT/$SDK_VERSION/include/winrt\""
+echo-info "DEVKIT_VS_LIB_aarch64=\"\$DEVKIT_ROOT/VC/lib/arm64;\$DEVKIT_ROOT/VC/atlmfc/lib/arm64;\$DEVKIT_ROOT/$SDK_VERSION/lib/arm64\""
+echo-info "DEVKIT_MSVCR_DLL_aarch64=\"\$DEVKIT_ROOT/VC/redist/arm64/$MSVCR_DLL\""
+echo-info "DEVKIT_VCRUNTIME_1_DLL_aarch64=\"\$DEVKIT_ROOT/VC/redist/arm64/$VCRUNTIME_1_DLL\""
+echo-info "DEVKIT_MSVCP_DLL_aarch64=\"\$DEVKIT_ROOT/VC/redist/arm64/$MSVCP_DLL\""
+echo-info "DEVKIT_UCRT_DLL_DIR_aarch64=\"\$DEVKIT_ROOT/10/Redist/ucrt/DLLs/arm64\""
+echo-info ""
 echo-info "DEVKIT_TOOLS_VERSION=\"$TOOLS_VERSION\""
 echo-info "DEVKIT_REDIST_VERSION=\"$REDIST_VERSION\""
 echo-info "DEVKIT_SDK_VERSION=\"$SDK_FULL_VERSION\""
```
________________________________________
From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>
Sent: Tuesday, June 30, 2020 02:39
To: Ludovic Henry; Monica Beckwith; hotspot-runtime-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; build-dev
Cc: openjdk-aarch64
Subject: Re: OpenJDK extension to AArch64 and Windows



On 2020-06-30 01:20, Ludovic Henry wrote:
> Hi Magnus,
>
>> I have now looked a bit more closely at the code. This is what I have
>> found so far that attracted my eye. Please note that this is not a
>> complete review. When you have a JEP and a test plan for how to verify
>> these changes and make sure you do not break existing platforms, you can
>> post a new RFR and I'll do a full review.
> Understood. I'll answer some of your remarks here, taking into account that Monica is currently working on the JEP.
>
>> * In flags-cflags.m4: You don't have to set  $1_CFLAGS_CPU_JVM="", an
>> empty value is default for unspecified variables.
> I'll revert that.
>
>> * In flags-ldflags.m4: The stack size seems dependent on CPU_BITS, not
>> the CPU arch. Please break out the -stack argument setting. Also, have
>> you verified if -machine is really needed? The comment says that it's
>> probably not; if it's just an old, unnecessary, precaution, we should
>> probably remove it instead, to simplify the logic.
> I've verified that it works without the `-machine` bit for ARM64, I'll revert it. I'll also split the `-stack` arguments into 32 and 64 bits checks.
Great! If you can test if -machine can be removed for the other
platforms as well, I'd be grateful. Old code which adds special cases,
and besides that is flagged as "probably not needed", should really be
cleaned away.
>
>> * In platform.m4: These changes worries me. Neither of them were
>> necessary for the linux-aarch64 port. But now you are changing the
>> values for all aarch64 builds, not just windows-aarch64. Have you
>> discovered a bug for linux-aarch64? Otherwise, these changes looks like
>> they are going to break linux-aarch64. If you believe you need to modify
>> these legacy values (which we'd rather move away from), please see if
>> you have made changes elsewhere that can be resolved without resorting
>> to adding new identifiers to the legacy values.
> It seems to have been a mistake in the early stage of our port, I'll revert it.
I see. Good.
>
>> * In basic.m4: Please move BASIC_EVAL_BUILD_DEVKIT_VARIABLE to be
>> positioned next to BASIC_EVAL_DEVKIT_VARIABLE.
> Ok
>
>> * In toolchain_windows.m4:
>>    In TOOLCHAIN_CHECK_POSSIBLE_MSVC_DLL, if you know about the upcoming
>> changes to file, why don't you add both the old and the new pattern to
>> the test?
> The comment is slightly inaccurate as it won't break, it is just not going to be as precise as it could be. The future version of file(1) will still return `PE32+ executable` (like it does for x86_64 executables), but it will also return something specifically for aarch64.
I see. Since we will need to support old versions of file for a long
time to come, the upcoming fix is really not relevant for us then. We'll
just have to accept the fact that the check is not really useful for
aarch64. Perhaps you can adjust the wording of the comment, so it's
clear that it's irrelevant if the bug fix is present or not in the
version of file that the user has.
>
>>    In TOOLCHAIN_SETUP_MSVC_DLL, when it was just two instances, the code
>> duplication could be accepted, but with three instances you need to
>> generalize this and refactor out the changing platform part of the path
>> only to the if statement. This applies, with some variation, to all four
>> changed places.
> Ok, I'll refactor by adding a variable containing x86, x64 or arm64.
Perfect!
>
>>    In the new TOOLCHAIN_SETUP_VISUAL_STUDIO_SYSROOT_FLAGS, you are doing
>>     AC_SUBST($1SYSROOT_CFLAGS)
>>     AC_SUBST($1SYSROOT_LDFLAGS)
>>
>> However, that seems superfluous, since it is already done by
>> FLAGS_SETUP_SYSROOT_FLAGS in flags.m4. In fact, now that I checked this,
>> I spotted that we *already* do an unnecessary AC_SUBST in
>> FLAGS_POST_TOOLCHAIN for the build sysroot flags! :-o
> This part is what caused the most problems in getting cross-compilation with MSVC working, and the current solution is the simplest changeset I could come up with. I've to admit that this part stretched my understanding of the build system, and thus I'm not even sure what I propose as good as it can be.
>
> FLAGS_SETUP_SYSROOT_FLAGS for example, only sets $1SYSROOT_CFLAGS and $1SYSROOT_LDLAGS to a valid value on non-"microsoft" toolchain. That is because at the time FLAGS_PRE_TOOLCHAIN is called, the "microsoft" toolchain has not been initialized yet. It only gets properly initialized once TOOLCHAIN_SETUP_VISUAL_STUDIO_ENV is called.
I understand if it's confusing. Autoconf is a beast to work with; I've
done that for more years than I want to think about, and I still don't
understand it fully. However, in this case, it's "easy". The call to
AC_SUBST only flags a variable for export. The actual exportation to
spec.gmk is done at the end of the configure script, with the call to
AC_OUTPUT, and the value exported is the value the variables has at that
point. So the order of execution does not matter here. This also means
that it is not an error to call AC_SUBST multiple times, but it is a
style issue. On the other hand, we try to follow the pattern of "create
variable, call AC_SUBST" for our own sanity.

Conceptually, the microsoft toolchain setup is almost equivalent to
FLAGS_PRE_TOOLCHAIN. That is, the result should be that we have a set of
"sysroot" (think "global") flags that should always be added. I have a
patch in the works that changes this somewhat, and makes the
dependencies clearer.
>
>> * In GensrcMisc,gmk: You are changing this for all users of the
>> microsoft toolchain. I don't recall seeing any problems with this on
>> x64. What version of Visual Studio are you using? Is this a limitation
>> in the aarch64 version of CL.EXE, or does it apply to other platforms as
>> well? Finally, if we do need to keep it, please use "-" as prefix for
>> options (even though the microsoft tooling normally suggests the
>> non-standard "/" -- this can all too easily be confused with path names.)
> Ok.
>
>> * In GensrcAdlc.gmk: You are adding -D_WIN64=1 for all 64-bit platforms,
>> i.e. also for x64, which has apparently worked fine until now without
>> that define. What does the define do, and what is the rationale for not
>> only adding it on your platform?
> It is the default define used on Windows-compatible codebases to specify whether it's targetting a 64-bit platform or not. We need to define it to have Windows-specific code in the existing aarch64 code of the OpenJDK. It makes sense to define it for x64 as well as arm64, but I agree it's not a requirement.
Ok, sounds good. Keep it as it is then.
>
>> * In jib-profiles.js: I appreciate the effort, but this file is
>> basically just for Oracle-internal usage. If and when we will add
>> support for building on windows-aarch64, we can update the file to work
>> properly with the JIB tool.
> Ok.
>
>> I am impressed that you manage to get cross-compilation working for
>> Windows with that small amount of changes, though! If you had asked med
>> beforehand, I'd have guessed that it would require more substantial
>> changes. As you say, this is not something we have done before.
> The meat of the change is in `toolchain.m4` with the support functions in `toolchain_windows.m4`. It is where I iterated the most to find the right encapsulation across the different components relying on it - and I've to say it wasn't straightforward to understand how all the pieces fit together. I'd be happy to work out with you a better way to do the foundational work of supporting cross-compilation with the Microsoft toolchain, just le me know how you'd like to proceed.
I think you have found more or less exactly the right spots to inject
the support for cross-compilation. I think I'd ended up with something
similar if I was tasked with getting cross-compilation work on Windows.
Maybe there's room for more generalisations, but it's a bit hard to say
at this moment. I think things might clear up a bit more when I get the
"unified winenv" patch in. It makes the sysroot cflag handling a bit
more transparent.

/Magnus
>
> Thank you,
>
> --
> Ludovic
>
> ________________________________________
> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>
> Sent: Monday, June 29, 2020 07:12
> To: Ludovic Henry; Monica Beckwith; hotspot-runtime-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; build-dev
> Cc: openjdk-aarch64
> Subject: Re: OpenJDK extension to AArch64 and Windows
>
> I have now looked a bit more closely at the code. This is what I have
> found so far that attracted my eye. Please note that this is not a
> complete review. When you have a JEP and a test plan for how to verify
> these changes and make sure you do not break existing platforms, you can
> post a new RFR and I'll do a full review.
>
> * In flags-cflags.m4: You don't have to set  $1_CFLAGS_CPU_JVM="", an
> empty value is default for unspecified variables.
>
> * In flags-ldflags.m4: The stack size seems dependent on CPU_BITS, not
> the CPU arch. Please break out the -stack argument setting. Also, have
> you verified if -machine is really needed? The comment says that it's
> probably not; if it's just an old, unnecessary, precaution, we should
> probably remove it instead, to simplify the logic.
>
> * In platform.m4: These changes worries me. Neither of them were
> necessary for the linux-aarch64 port. But now you are changing the
> values for all aarch64 builds, not just windows-aarch64. Have you
> discovered a bug for linux-aarch64? Otherwise, these changes looks like
> they are going to break linux-aarch64. If you believe you need to modify
> these legacy values (which we'd rather move away from), please see if
> you have made changes elsewhere that can be resolved without resorting
> to adding new identifiers to the legacy values.
>
> * In basic.m4: Please move BASIC_EVAL_BUILD_DEVKIT_VARIABLE to be
> positioned next to BASIC_EVAL_DEVKIT_VARIABLE.
>
> * In toolchain_windows.m4:
>    In TOOLCHAIN_CHECK_POSSIBLE_MSVC_DLL, if you know about the upcoming
> changes to file, why don't you add both the old and the new pattern to
> the test?
>
>    In TOOLCHAIN_SETUP_MSVC_DLL, when it was just two instances, the code
> duplication could be accepted, but with three instances you need to
> generalize this and refactor out the changing platform part of the path
> only to the if statement. This applies, with some variation, to all four
> changed places.
>
>    In the new TOOLCHAIN_SETUP_VISUAL_STUDIO_SYSROOT_FLAGS, you are doing
>     AC_SUBST($1SYSROOT_CFLAGS)
>     AC_SUBST($1SYSROOT_LDFLAGS)
>
> However, that seems superfluous, since it is already done by
> FLAGS_SETUP_SYSROOT_FLAGS in flags.m4. In fact, now that I checked this,
> I spotted that we *already* do an unnecessary AC_SUBST in
> FLAGS_POST_TOOLCHAIN for the build sysroot flags! :-o
>
> * In GensrcMisc,gmk: You are changing this for all users of the
> microsoft toolchain. I don't recall seeing any problems with this on
> x64. What version of Visual Studio are you using? Is this a limitation
> in the aarch64 version of CL.EXE, or does it apply to other platforms as
> well? Finally, if we do need to keep it, please use "-" as prefix for
> options (even though the microsoft tooling normally suggests the
> non-standard "/" -- this can all too easily be confused with path names.)
>
> * In GensrcAdlc.gmk: You are adding -D_WIN64=1 for all 64-bit platforms,
> i.e. also for x64, which has apparently worked fine until now without
> that define. What does the define do, and what is the rationale for not
> only adding it on your platform?
>
> * In jib-profiles.js: I appreciate the effort, but this file is
> basically just for Oracle-internal usage. If and when we will add
> support for building on windows-aarch64, we can update the file to work
> properly with the JIB tool.
>
> I am impressed that you manage to get cross-compilation working for
> Windows with that small amount of changes, though! If you had asked med
> beforehand, I'd have guessed that it would require more substantial
> changes. As you say, this is not something we have done before.
>
> /Magnus
>
>
>
> On 2020-06-24 23:33, Ludovic Henry wrote:
>> Hi Magnus,
>>
>> Happy to answer any question you have on the build system changes.
>>
>> A lot of the changes were due to the build system not supporting cross-compilation well when targetting the microsoft toolchain (it just never really had to support it). We had to go through a few hoops to remove as many of our own quick hacks, initially there just to get things building - like hardcoding the target being windows-aarch64 for example.
>>
>> Thank you for your review,
>>
>> --
>> Ludovic
>>
>> ________________________________________
>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>
>> Sent: Wednesday, June 24, 2020 13:44
>> To: Monica Beckwith; hotspot-runtime-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; build-dev
>> Cc: openjdk-aarch64
>> Subject: Re: OpenJDK extension to AArch64 and Windows
>>
>> Hi Monica,
>>
>> All build system changes must be sent to build-dev for review by the
>> build team, and you are doing quite a lot of build changes. (I'm cc:ing
>> build-dev now.)
>>
>> I did a quick scan and found some changes that looked odd enough to draw
>> my attention.
>>
>> I will need some time to fully understand what you are trying to
>> accomplish here, before I can give a full review.
>>
>> /Magnus
>>
>>
>> On 2020-06-24 18:40, Monica Beckwith wrote:
>>> Hello OpenJDK community,
>>>
>>> As the project lead here @Microsoft, I am pleased to share that we have been working towards a Windows addition to the OpenJDK AArch64 port. We are very thankful to all that have contributed to the Linux+aarch64 and Windows+x86-64. Both these codebases came to our rescue on numerous occasions.
>>>
>>> Support status: We have successfully ported C2 and can build the server release (cross-compiled environment)
>>> Test coverage: C2 + ParallelGC (No AOT, JVMCI, ZGC, ShenandoahGC, G1GC)
>>> Tests and benchmarks covered [1]: JTReg [2], JCStress, jmh-jdk-microbenchmarks, SPEC SERT, SPECJBB2015 [3], SPEC JVM2008, Scimark2, SPEC JBB2005.
>>> Umbrella Bug ID: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8248238&amp;data=02%7C01%7Cluhenry%40microsoft.com%7C9136394326d9424e376c08d81cd99b84%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637291068232489298&amp;sdata=JcmGbXJwXrDl3f37gnajyIeyahgdRtpg%2BZSgXCHtzeA%3D&amp;reserved=0
>>> Webrevs:
>>> `Webrev P1`: https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~burban%2Fwinarm64_p1_llp64%2F&amp;data=02%7C01%7Cluhenry%40microsoft.com%7C9136394326d9424e376c08d81cd99b84%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637291068232489298&amp;sdata=ExZFlWo83XVb5ObE6nn9MjOEJEPkxd4ZCKwfPLhoQT4%3D&amp;reserved=0  &
>>> `Webrev P2`: https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~burban%2Fwinarm64_p2_new-target%2F&amp;data=02%7C01%7Cluhenry%40microsoft.com%7C9136394326d9424e376c08d81cd99b84%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637291068232499294&amp;sdata=eZmyl9Kni3MOzk%2BCzUM42Om20Z%2BYoLbGXYRykka1YaE%3D&amp;reserved=0
>>>
>>> The first patch `Webrev P1` (patch 1 aka P1 in our tests) helps integrate support for Windows (LLP64) on Linux + AArch64
>>> The second patch `Webrev P2` (patch 2 aka P2 in our tests) adds the 'windows-aarch64' support in `os_cpu`. We also had to modify shared code, and I am highlighting a few details here:
>>>         * In windows_x86 such as the `get_frame_at_stack_banging_point` in `os_windows_x86.cpp`,
>>>         * In `os/windows os_windows.cpp` to make it aware of Windows + Arm64
>>>         * `os/windows` in `threadCritical_windows.cpp`,
>>>         * Windbg support
>>>         * `globalDefinitions_visCPP.hpp` in `share/utilities`
>>>         * We also added Vectored Exception Handling (VEH) to P2, as it is a requirement on Windows + Arm64 (due to ABI specifications).
>>> Also, in `Webrev P2`, you will find that we have made some significant changes to `cpu/aarch64` around register usage since on Windows + Arm64, register R18 points to TEB [4]. We have discussed this with Andrew Haley and Andrew Dinn, and they are helping us with a cleaner implementation of the same. Their constant support and guidance have humbled me.
>>>
>>> I'd also like to recognize the great work done by Ludovic Henry (our resident runtime expert) in driving the C2 support and by Bernhard Urban-Forster, (who recently joined our team) in helping expand the coverage to G1 GC.
>>>
>>> As a part of this project, we have also worked on two additional patches:
>>>         * Expanding VEH on Windows to x86-64 (patch 3 aka P3 in our tests). Details here: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8247941&amp;data=02%7C01%7Cluhenry%40microsoft.com%7C9136394326d9424e376c08d81cd99b84%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637291068232499294&amp;sdata=w7L9DmFX1jVWQ6Y7kHCBJTAkdVrhvhScZKITimpf53k%3D&amp;reserved=0
>>>         * Improvements in the shared cross-platform code on Windows (patch 4 aka P4 in our tests) - We will send out a separate patch soon.
>>>
>>> We welcome any feedback and comments from the community and are looking forward to working together.
>>>
>>> Regards,
>>> Monica
>>>
>>> [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fopenjdk-aarch64%2Fblob%2Fmaster%2Fwkload-status-on-Win%252BArm64.md&amp;data=02%7C01%7Cluhenry%40microsoft.com%7C9136394326d9424e376c08d81cd99b84%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637291068232499294&amp;sdata=PBTDSkXsABCl4fPCGAPWxiUfWMxoBhgPY7y62GHPFJY%3D&amp;reserved=0
>>> [2] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fopenjdk-aarch64%2Fblob%2Fmaster%2FJTRegtests.md&amp;data=02%7C01%7Cluhenry%40microsoft.com%7C9136394326d9424e376c08d81cd99b84%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637291068232499294&amp;sdata=ddMzJGZMafiohidzmSiqBvF%2B3nx7yFsceFU1vd5tovs%3D&amp;reserved=0
>>> [3] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fopenjdk-aarch64%2Fblob%2Fmaster%2FSPECJBB2015-test-matrices.md&amp;data=02%7C01%7Cluhenry%40microsoft.com%7C9136394326d9424e376c08d81cd99b84%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637291068232499294&amp;sdata=NTLcoiHmlvnKugwkH%2BM0bO8hBipD9MKClXelmTPw9w8%3D&amp;reserved=0
>>> [4] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fcpp%2Fbuild%2Farm64-windows-abi-conventions%3Fview%3Dvs-2019%23integer-registers&amp;data=02%7C01%7Cluhenry%40microsoft.com%7C9136394326d9424e376c08d81cd99b84%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637291068232499294&amp;sdata=TxtHh9ZQkqBmuIIckce71E%2FZNkX%2BxyvB4tja26ZoT6s%3D&amp;reserved=0



From andrew_m_leonard at uk.ibm.com  Wed Jul  8 10:22:07 2020
From: andrew_m_leonard at uk.ibm.com (Andrew Leonard)
Date: Wed, 8 Jul 2020 11:22:07 +0100
Subject: RFR & sponsor: 8248701: On Windows generated modules-deps.gmk can
 contain backslash-r (CR) characters
Message-ID: <OF7E86B093.1E543A7C-ON0025859F.00385D18-8025859F.0038F52A@notes.na.collabserv.com>

Hi,

Please can I request a review and sponsor to push the following simple fix 
to Modules.gmk:
http://cr.openjdk.java.net/~aleonard/8248701/webrev.00/
for bug: https://bugs.openjdk.java.net/browse/JDK-8248701

which is to cover situations on Windows where a /r(CR) can cause a build 
break due to badly generated make dependency.

Thank you,
Andrew

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
internet email: andrew_m_leonard at uk.ibm.com 

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU



From erik.joelsson at oracle.com  Wed Jul  8 12:19:54 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 8 Jul 2020 05:19:54 -0700
Subject: RFR & sponsor: 8248701: On Windows generated modules-deps.gmk can
 contain backslash-r (CR) characters
In-Reply-To: <OF7E86B093.1E543A7C-ON0025859F.00385D18-8025859F.0038F52A@notes.na.collabserv.com>
References: <OF7E86B093.1E543A7C-ON0025859F.00385D18-8025859F.0038F52A@notes.na.collabserv.com>
Message-ID: <94a3415c-bdf1-1d89-9d8e-534f92606b60@oracle.com>

Looks good, I will sponsor it.

/Erik

On 2020-07-08 03:22, Andrew Leonard wrote:
> Hi,
>
> Please can I request a review and sponsor to push the following simple fix
> to Modules.gmk:
> http://cr.openjdk.java.net/~aleonard/8248701/webrev.00/
> for bug: https://bugs.openjdk.java.net/browse/JDK-8248701
>
> which is to cover situations on Windows where a /r(CR) can cause a build
> break due to badly generated make dependency.
>
> Thank you,
> Andrew
>
> Andrew Leonard
> Java Runtimes Development
> IBM Hursley
> IBM United Kingdom Ltd
> internet email: andrew_m_leonard at uk.ibm.com
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>


From dekeeler at microsoft.com  Thu Jul  9 00:53:57 2020
From: dekeeler at microsoft.com (Derek Keeler)
Date: Thu, 9 Jul 2020 00:53:57 +0000
Subject: Preliminary review for new WINENV support
In-Reply-To: <DM6PR21MB132346CB9B0A4EEFE2EF1306E5680@DM6PR21MB1323.namprd21.prod.outlook.com>
References: <E8774EC8-612E-4646-B223-D55ED0C0BC46@oracle.com>,
 <DM6PR21MB132346CB9B0A4EEFE2EF1306E5680@DM6PR21MB1323.namprd21.prod.outlook.com>
Message-ID: <DM6PR21MB1420AEA759D68BE5197E759CD0640@DM6PR21MB1420.namprd21.prod.outlook.com>

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 <build-dev-retn at openjdk.java.net> on behalf of Monica Beckwith <Monica.Beckwith at microsoft.com>
Sent: July 5, 2020 11:34 AM
To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; build-dev <build-dev at openjdk.java.net>
Subject: Re: Preliminary review for new WINENV support

Wow! Impressive work, @Magnus Ihse Bursie<mailto:magnus.ihse.bursie at oracle.com> . 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<https://aka.ms/ghei36>

________________________________
From: build-dev <build-dev-retn at openjdk.java.net> on behalf of Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>
Sent: Saturday, July 4, 2020 7:08:20 PM
To: build-dev <build-dev at openjdk.java.net>
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: http://cr.openjdk.java.net/~ihse/winenv-preview-1/webrev.01/

(If you prefer, you can check out the branch "ihse-winenv-branch" on http://hg.openjdk.java.net/jdk/sandbox instead of downloading the patch from the webrev.)


I am leaving on vacation next week, so I won't be doing any more work on this for a while, but I promise to read all emails when I get back and try to rectify all issues that are reported. This means you have some time to try it out, too.

Here are some technical notes of what is changing, compared to the current Windows build.

The native "fixpath.exe" tool is gone. This means that we do not need to compile it during configure, which was always tricky to get right (mostly since we did not have fixpath in place to help us...).

Instead, there is a new fixpath.sh shell script, that does the same job, and more. The script is written in highly optimized shell code (yeah, I see the oxymoron) so only bash internal functionality is used, to avoid calling external tools, which is expensive on Windows. This makes the performance practically roughly at par with the native fixpath.exe.

Fixpath also has a "print" and "import" mode, apart from the traditional"exec" mode. This makes it possible to use the same tool for converting individual paths at runtime to Windows style ("print"), and it takes the logic needed to "import" paths given by the user to configure, into a format usable internally by the build system, and moves it into a centralized location in the fixpath script.

A "winenv" is defined by a quartet of variables: PATHTOOL, DRIVEPREFIX, ENVROOT and WINTEMP. For instance, for "cygwin", these are:
 PATHTOOL=cygpath
 DRIVEPREFIX=/cygdrive (typically)
 ENVROOT=C:\Cygwin64 (typically)
 WINTEMP=/tmp

These are needed for fixpath to do it's magic. Fixpath can auto-detect those, but to save on execution time they are normally detected by configure and sent as arguments to fixpath.

Detection of the Visual Studio environment has been massively simplified. Using fixpath, conversion between Windows and unix paths is not so complex anymore. The bridge Windows batch file that is needed to extract the environment variables is no longer created on the fly, but is instead stored in make/scripts/extract-vs-env.cmd. This is called with fixpath, so all arguments to it can be unix paths.

Furthermore, TOOLCHAIN_SETUP_VISUAL_STUDIO_ENV is now clearly designed to have a single responsibility, to set SYSROOT flags (and TOOLCHAIN_PATH) for the microsoft toolchain. As a result of this, it is now called from FLAGS_SETUP_SYSROOT_FLAGS. Also, the file toolchain_windows.m4 is now more correctly named toolchain_microsoft.m4. A price we had to pay for this was that the old idea that you should be able to start a "Visual Studio console" and then run configure from it to extract the variables do not work anymore. (It had not been tested for ages, and might have been broken anyway.)

Fixpath also knows about the difference between unix path lists (/foo/bar:/my/dir) and windows path lists (c:\dir;d:\data) and can convert freely and automatically between them. This furthermore means that PATH_SEP is removed, and we only use unix style (colon separated) path lists internally.

The logic automatically detects if and when .exe is needed, so EXE_SUFFIX is removed too. There are some limitations; when code needs to explicitly test for the presence of a file, the suffix needs to be correct. Also when make files check for e.g. the generated bin/java.exe, the suffix needs to be present. For this, I have introduced an EXECUTABLE_SUFFIX, that has the same value as EXE_SUFFIX -- but not the same semantics! The old code added EXE_SUFFIX here and there, not caring about if we meant "microsoft" as a toolchain or if we were running on Windows as a build platform. Clearly not well adapted for future cross-compilation.

The old ways of locating programs in configure were messy, complicated and not always correct. We used a mixture of the original autoconf macros, and our own UTIL_PATH_PROGS and UTIL_CHECK_TOOLS. These did not have very well defined semantics, and were frequently mixed up. Also, UTIL_CHECK_TOOLS required UTIL_FIXUP_EXECUTABLE tobe called afterwards, to "rewrite" the result in a second step. This was not needed after UTIL_PATH_PROGS but was frequently done anyway to "be on the safe side".

I have now replaced:
  AC_(PATH|CHECK)_(PROG|PROGS) with UTIL_LOOKUP_PROGS
  AC_(PATH|CHECK)_(TOOL|TOOLS) with UTIL_LOOKUP_TOOLCHAIN_PROGS

This is actually almost the same semantic, but unless you're an autoconf aficionado, you ar not likely to understand the difference     between "PROG" and "TOOL". The only difference is that UTIL_LOOKUP_TOOLCHAIN_PROGS will try to look for "host-prefixed" tools first, when cross-compiling, and should therefore be used for all toolchain lookups.

There is also a fail-fast version of both, UTIL_REQUIRE_PROGS and UTIL_REQUIRE_TOOLCHAIN_PROGS.

UTIL_LOOKUP_PROGS is the core function, with the rest being thin wrappers around it. This function is created from scratch, to do exactly what we want, on Unix platforms and Windows. So there is no need anymore to call UTIL_FIXUP_EXECUTABLE, unless you have input from elsewhere (e.g. user flag) that you need to verify. I have also collected all this logic in a single file, util_paths.m4, moving parts from util.m4, and just removing util_windows.m4.

UTIL_LOOKUP_PROGS will use the new and nifty function UTIL_CHECK_WINENV_EXEC_TYPE, which will automatically determine if an executable needs to be prefixed by fixpath! That means that you can match and mix Windows-style and Unix-style programs however you like, with very few limitations. For instance, you can have a Linux version of the BootJDK on WSL. For this to work, the $FIXPATH prefix is now stored in the variables themselves (e.g. in $CC), rather than added as @FIXPATH@ in spec.gmk.in. This has generally worked out OK, but caused some headaches when the code thought that $CC (etc) was not a way to launch a program, but was a file that could be tested for existence, etc.

I reintroduced support for msys2. This was mostly free, since msys2 is so close to cygwin (which msys never where). To underline the difference, I renamed the winenv windows.msys2 (instead of windows.msys). Msys (version 1) will never be supported in modern OpenJDK due to critical packages being far too old, and not updated. I also clearly separate between WSL1 (which is using a kernel emulation layer, somewhat like Wine) and WSL2 (which is using a Hyper-V VM to run an actual Linux kernel), as windows.wsl1 and windows.wsl2.

I have also done a ton of small fixes, to make things more convenient and smooth when working in these winenvs. I have adjusted the output from configure to be less verbose and more streamlined. Overall, a lot of odd code in configure has been removed. A few changes that are strictly unneeded for this patch has also been included; mostly removal of dead code I came across, and a few fixes for additional debuggability that I needed when developing this patch, like ExecuteithLog.

I have also temporarily disabled the javac server, and building without absolute paths. I believe a better way forward is to address these with improved functionality in separate patches, instead of trying to work around the issues introduced by them in this patch.

I have done substantial testing of the core functionality (building jdk-images) on Cygwin, Msys2 and WSL2, both on my personal machine and on Oracle's CI system. The performance on Cygwin (which we use for our CI builds) is roughly on par with the old Cygwin performance, but the WSL1 performance is roughly 20% faster, so I think we should investigate if it is possible for us to switch to WSL1. Everything seems stable so far, but more testing is definitely needed. I have also not even started testing autxillary     functionality, such as the compare script, IDE project file generation etc.

However, the big disappointment in all of this is WSL2. That was the main driver that got me started on this rewrite. But it turned out that WSL2 is still very immature. :-( There are lot of issues, like stdout and stderr getting messed up, time synchronization issues causing make to complain about "Clock skew detected", extreme slowness when accessing disks cross the OS boundary. But worst of all has been that WSL2 is *extremly* unstable. After a few calls of Window executables, I get the impression that a conversion daemon dies. All further calls to Window binaries just stalls, and the WSL2 instance is unusable until I terminate it using "wsl -t Ubuntu-2004" from a cmd shell. :-(

So the WSL2 functionality is not very well tested, since I have not been able to build it completely a single time. I do believe that everything is correct, in "theory". So in case this is something broken with my WSL2 installation, I'd encourage anyone with a WSL2 installation to try it out.

/Magnus


From dekeeler at microsoft.com  Thu Jul  9 03:12:04 2020
From: dekeeler at microsoft.com (Derek Keeler)
Date: Thu, 9 Jul 2020 03:12:04 +0000
Subject: Preliminary review for new WINENV support
In-Reply-To: <DM6PR21MB1420AEA759D68BE5197E759CD0640@DM6PR21MB1420.namprd21.prod.outlook.com>
References: <E8774EC8-612E-4646-B223-D55ED0C0BC46@oracle.com>,
 <DM6PR21MB132346CB9B0A4EEFE2EF1306E5680@DM6PR21MB1323.namprd21.prod.outlook.com>,
 <DM6PR21MB1420AEA759D68BE5197E759CD0640@DM6PR21MB1420.namprd21.prod.outlook.com>
Message-ID: <DM6PR21MB14204A5FD56791B026D2F343D0640@DM6PR21MB1420.namprd21.prod.outlook.com>

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`.

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.

-Derek

________________________________
From: build-dev <build-dev-retn at openjdk.java.net> on behalf of Derek Keeler <dekeeler at microsoft.com>
Sent: July 8, 2020 5:53 PM
To: Monica Beckwith <Monica.Beckwith at microsoft.com>; Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; build-dev <build-dev at openjdk.java.net>
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 <build-dev-retn at openjdk.java.net> on behalf of Monica Beckwith <Monica.Beckwith at microsoft.com>
Sent: July 5, 2020 11:34 AM
To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; build-dev <build-dev at openjdk.java.net>
Subject: Re: Preliminary review for new WINENV support

Wow! Impressive work, @Magnus Ihse Bursie<mailto:magnus.ihse.bursie at oracle.com> . 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<https://aka.ms/ghei36>

________________________________
From: build-dev <build-dev-retn at openjdk.java.net> on behalf of Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>
Sent: Saturday, July 4, 2020 7:08:20 PM
To: build-dev <build-dev at openjdk.java.net>
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%2F&amp;data=02%7C01%7Cdekeeler%40microsoft.com%7C28e792b26f604f86be7108d823a29bf5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637298528593747355&amp;sdata=LkTMXBZRcaOe%2FRCvcckFViwDOysi7nS9H1Edve%2B4Alk%3D&amp;reserved=0

(If you prefer, you can check out the branch "ihse-winenv-branch" on https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.openjdk.java.net%2Fjdk%2Fsandbox&amp;data=02%7C01%7Cdekeeler%40microsoft.com%7C28e792b26f604f86be7108d823a29bf5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637298528593747355&amp;sdata=g8UElT7Zx15fMItd8yGGjS%2BuPcyKd3i1EEVHJLumfUo%3D&amp;reserved=0 instead of downloading the patch from the webrev.)


I am leaving on vacation next week, so I won't be doing any more work on this for a while, but I promise to read all emails when I get back and try to rectify all issues that are reported. This means you have some time to try it out, too.

Here are some technical notes of what is changing, compared to the current Windows build.

The native "fixpath.exe" tool is gone. This means that we do not need to compile it during configure, which was always tricky to get right (mostly since we did not have fixpath in place to help us...).

Instead, there is a new fixpath.sh shell script, that does the same job, and more. The script is written in highly optimized shell code (yeah, I see the oxymoron) so only bash internal functionality is used, to avoid calling external tools, which is expensive on Windows. This makes the performance practically roughly at par with the native fixpath.exe.

Fixpath also has a "print" and "import" mode, apart from the traditional"exec" mode. This makes it possible to use the same tool for converting individual paths at runtime to Windows style ("print"), and it takes the logic needed to "import" paths given by the user to configure, into a format usable internally by the build system, and moves it into a centralized location in the fixpath script.

A "winenv" is defined by a quartet of variables: PATHTOOL, DRIVEPREFIX, ENVROOT and WINTEMP. For instance, for "cygwin", these are:
 PATHTOOL=cygpath
 DRIVEPREFIX=/cygdrive (typically)
 ENVROOT=C:\Cygwin64 (typically)
 WINTEMP=/tmp

These are needed for fixpath to do it's magic. Fixpath can auto-detect those, but to save on execution time they are normally detected by configure and sent as arguments to fixpath.

Detection of the Visual Studio environment has been massively simplified. Using fixpath, conversion between Windows and unix paths is not so complex anymore. The bridge Windows batch file that is needed to extract the environment variables is no longer created on the fly, but is instead stored in make/scripts/extract-vs-env.cmd. This is called with fixpath, so all arguments to it can be unix paths.

Furthermore, TOOLCHAIN_SETUP_VISUAL_STUDIO_ENV is now clearly designed to have a single responsibility, to set SYSROOT flags (and TOOLCHAIN_PATH) for the microsoft toolchain. As a result of this, it is now called from FLAGS_SETUP_SYSROOT_FLAGS. Also, the file toolchain_windows.m4 is now more correctly named toolchain_microsoft.m4. A price we had to pay for this was that the old idea that you should be able to start a "Visual Studio console" and then run configure from it to extract the variables do not work anymore. (It had not been tested for ages, and might have been broken anyway.)

Fixpath also knows about the difference between unix path lists (/foo/bar:/my/dir) and windows path lists (c:\dir;d:\data) and can convert freely and automatically between them. This furthermore means that PATH_SEP is removed, and we only use unix style (colon separated) path lists internally.

The logic automatically detects if and when .exe is needed, so EXE_SUFFIX is removed too. There are some limitations; when code needs to explicitly test for the presence of a file, the suffix needs to be correct. Also when make files check for e.g. the generated bin/java.exe, the suffix needs to be present. For this, I have introduced an EXECUTABLE_SUFFIX, that has the same value as EXE_SUFFIX -- but not the same semantics! The old code added EXE_SUFFIX here and there, not caring about if we meant "microsoft" as a toolchain or if we were running on Windows as a build platform. Clearly not well adapted for future cross-compilation.

The old ways of locating programs in configure were messy, complicated and not always correct. We used a mixture of the original autoconf macros, and our own UTIL_PATH_PROGS and UTIL_CHECK_TOOLS. These did not have very well defined semantics, and were frequently mixed up. Also, UTIL_CHECK_TOOLS required UTIL_FIXUP_EXECUTABLE tobe called afterwards, to "rewrite" the result in a second step. This was not needed after UTIL_PATH_PROGS but was frequently done anyway to "be on the safe side".

I have now replaced:
  AC_(PATH|CHECK)_(PROG|PROGS) with UTIL_LOOKUP_PROGS
  AC_(PATH|CHECK)_(TOOL|TOOLS) with UTIL_LOOKUP_TOOLCHAIN_PROGS

This is actually almost the same semantic, but unless you're an autoconf aficionado, you ar not likely to understand the difference     between "PROG" and "TOOL". The only difference is that UTIL_LOOKUP_TOOLCHAIN_PROGS will try to look for "host-prefixed" tools first, when cross-compiling, and should therefore be used for all toolchain lookups.

There is also a fail-fast version of both, UTIL_REQUIRE_PROGS and UTIL_REQUIRE_TOOLCHAIN_PROGS.

UTIL_LOOKUP_PROGS is the core function, with the rest being thin wrappers around it. This function is created from scratch, to do exactly what we want, on Unix platforms and Windows. So there is no need anymore to call UTIL_FIXUP_EXECUTABLE, unless you have input from elsewhere (e.g. user flag) that you need to verify. I have also collected all this logic in a single file, util_paths.m4, moving parts from util.m4, and just removing util_windows.m4.

UTIL_LOOKUP_PROGS will use the new and nifty function UTIL_CHECK_WINENV_EXEC_TYPE, which will automatically determine if an executable needs to be prefixed by fixpath! That means that you can match and mix Windows-style and Unix-style programs however you like, with very few limitations. For instance, you can have a Linux version of the BootJDK on WSL. For this to work, the $FIXPATH prefix is now stored in the variables themselves (e.g. in $CC), rather than added as @FIXPATH@ in spec.gmk.in. This has generally worked out OK, but caused some headaches when the code thought that $CC (etc) was not a way to launch a program, but was a file that could be tested for existence, etc.

I reintroduced support for msys2. This was mostly free, since msys2 is so close to cygwin (which msys never where). To underline the difference, I renamed the winenv windows.msys2 (instead of windows.msys). Msys (version 1) will never be supported in modern OpenJDK due to critical packages being far too old, and not updated. I also clearly separate between WSL1 (which is using a kernel emulation layer, somewhat like Wine) and WSL2 (which is using a Hyper-V VM to run an actual Linux kernel), as windows.wsl1 and windows.wsl2.

I have also done a ton of small fixes, to make things more convenient and smooth when working in these winenvs. I have adjusted the output from configure to be less verbose and more streamlined. Overall, a lot of odd code in configure has been removed. A few changes that are strictly unneeded for this patch has also been included; mostly removal of dead code I came across, and a few fixes for additional debuggability that I needed when developing this patch, like ExecuteithLog.

I have also temporarily disabled the javac server, and building without absolute paths. I believe a better way forward is to address these with improved functionality in separate patches, instead of trying to work around the issues introduced by them in this patch.

I have done substantial testing of the core functionality (building jdk-images) on Cygwin, Msys2 and WSL2, both on my personal machine and on Oracle's CI system. The performance on Cygwin (which we use for our CI builds) is roughly on par with the old Cygwin performance, but the WSL1 performance is roughly 20% faster, so I think we should investigate if it is possible for us to switch to WSL1. Everything seems stable so far, but more testing is definitely needed. I have also not even started testing autxillary     functionality, such as the compare script, IDE project file generation etc.

However, the big disappointment in all of this is WSL2. That was the main driver that got me started on this rewrite. But it turned out that WSL2 is still very immature. :-( There are lot of issues, like stdout and stderr getting messed up, time synchronization issues causing make to complain about "Clock skew detected", extreme slowness when accessing disks cross the OS boundary. But worst of all has been that WSL2 is *extremly* unstable. After a few calls of Window executables, I get the impression that a conversion daemon dies. All further calls to Window binaries just stalls, and the WSL2 instance is unusable until I terminate it using "wsl -t Ubuntu-2004" from a cmd shell. :-(

So the WSL2 functionality is not very well tested, since I have not been able to build it completely a single time. I do believe that everything is correct, in "theory". So in case this is something broken with my WSL2 installation, I'd encourage anyone with a WSL2 installation to try it out.

/Magnus


From suenaga at oss.nttdata.com  Thu Jul  9 04:47:22 2020
From: suenaga at oss.nttdata.com (Yasumasa Suenaga)
Date: Thu, 9 Jul 2020 13:47:22 +0900
Subject: Preliminary review for new WINENV support
In-Reply-To: <DM6PR21MB14204A5FD56791B026D2F343D0640@DM6PR21MB1420.namprd21.prod.outlook.com>
References: <E8774EC8-612E-4646-B223-D55ED0C0BC46@oracle.com>
 <DM6PR21MB132346CB9B0A4EEFE2EF1306E5680@DM6PR21MB1323.namprd21.prod.outlook.com>
 <DM6PR21MB1420AEA759D68BE5197E759CD0640@DM6PR21MB1420.namprd21.prod.outlook.com>
 <DM6PR21MB14204A5FD56791B026D2F343D0640@DM6PR21MB1420.namprd21.prod.outlook.com>
Message-ID: <b1bd2259-ce2b-1ae3-5b79-5ae509d0e750@oss.nttdata.com>

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 <build-dev-retn at openjdk.java.net> on behalf of Derek Keeler <dekeeler at microsoft.com>
> Sent: July 8, 2020 5:53 PM
> To: Monica Beckwith <Monica.Beckwith at microsoft.com>; Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; build-dev <build-dev at openjdk.java.net>
> 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 <build-dev-retn at openjdk.java.net> on behalf of Monica Beckwith <Monica.Beckwith at microsoft.com>
> Sent: July 5, 2020 11:34 AM
> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; build-dev <build-dev at openjdk.java.net>
> Subject: Re: Preliminary review for new WINENV support
> 
> Wow! Impressive work, @Magnus Ihse Bursie<mailto:magnus.ihse.bursie at oracle.com> . 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<https://aka.ms/ghei36>
> 
> ________________________________
> From: build-dev <build-dev-retn at openjdk.java.net> on behalf of Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>
> Sent: Saturday, July 4, 2020 7:08:20 PM
> To: build-dev <build-dev at openjdk.java.net>
> 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%2F&amp;data=02%7C01%7Cdekeeler%40microsoft.com%7C28e792b26f604f86be7108d823a29bf5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637298528593747355&amp;sdata=LkTMXBZRcaOe%2FRCvcckFViwDOysi7nS9H1Edve%2B4Alk%3D&amp;reserved=0
> 
> (If you prefer, you can check out the branch "ihse-winenv-branch" on https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.openjdk.java.net%2Fjdk%2Fsandbox&amp;data=02%7C01%7Cdekeeler%40microsoft.com%7C28e792b26f604f86be7108d823a29bf5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637298528593747355&amp;sdata=g8UElT7Zx15fMItd8yGGjS%2BuPcyKd3i1EEVHJLumfUo%3D&amp;reserved=0 instead of downloading the patch from the webrev.)
> 
> 
> I am leaving on vacation next week, so I won't be doing any more work on this for a while, but I promise to read all emails when I get back and try to rectify all issues that are reported. This means you have some time to try it out, too.
> 
> Here are some technical notes of what is changing, compared to the current Windows build.
> 
> The native "fixpath.exe" tool is gone. This means that we do not need to compile it during configure, which was always tricky to get right (mostly since we did not have fixpath in place to help us...).
> 
> Instead, there is a new fixpath.sh shell script, that does the same job, and more. The script is written in highly optimized shell code (yeah, I see the oxymoron) so only bash internal functionality is used, to avoid calling external tools, which is expensive on Windows. This makes the performance practically roughly at par with the native fixpath.exe.
> 
> Fixpath also has a "print" and "import" mode, apart from the traditional"exec" mode. This makes it possible to use the same tool for converting individual paths at runtime to Windows style ("print"), and it takes the logic needed to "import" paths given by the user to configure, into a format usable internally by the build system, and moves it into a centralized location in the fixpath script.
> 
> A "winenv" is defined by a quartet of variables: PATHTOOL, DRIVEPREFIX, ENVROOT and WINTEMP. For instance, for "cygwin", these are:
>   PATHTOOL=cygpath
>   DRIVEPREFIX=/cygdrive (typically)
>   ENVROOT=C:\Cygwin64 (typically)
>   WINTEMP=/tmp
> 
> These are needed for fixpath to do it's magic. Fixpath can auto-detect those, but to save on execution time they are normally detected by configure and sent as arguments to fixpath.
> 
> Detection of the Visual Studio environment has been massively simplified. Using fixpath, conversion between Windows and unix paths is not so complex anymore. The bridge Windows batch file that is needed to extract the environment variables is no longer created on the fly, but is instead stored in make/scripts/extract-vs-env.cmd. This is called with fixpath, so all arguments to it can be unix paths.
> 
> Furthermore, TOOLCHAIN_SETUP_VISUAL_STUDIO_ENV is now clearly designed to have a single responsibility, to set SYSROOT flags (and TOOLCHAIN_PATH) for the microsoft toolchain. As a result of this, it is now called from FLAGS_SETUP_SYSROOT_FLAGS. Also, the file toolchain_windows.m4 is now more correctly named toolchain_microsoft.m4. A price we had to pay for this was that the old idea that you should be able to start a "Visual Studio console" and then run configure from it to extract the variables do not work anymore. (It had not been tested for ages, and might have been broken anyway.)
> 
> Fixpath also knows about the difference between unix path lists (/foo/bar:/my/dir) and windows path lists (c:\dir;d:\data) and can convert freely and automatically between them. This furthermore means that PATH_SEP is removed, and we only use unix style (colon separated) path lists internally.
> 
> The logic automatically detects if and when .exe is needed, so EXE_SUFFIX is removed too. There are some limitations; when code needs to explicitly test for the presence of a file, the suffix needs to be correct. Also when make files check for e.g. the generated bin/java.exe, the suffix needs to be present. For this, I have introduced an EXECUTABLE_SUFFIX, that has the same value as EXE_SUFFIX -- but not the same semantics! The old code added EXE_SUFFIX here and there, not caring about if we meant "microsoft" as a toolchain or if we were running on Windows as a build platform. Clearly not well adapted for future cross-compilation.
> 
> The old ways of locating programs in configure were messy, complicated and not always correct. We used a mixture of the original autoconf macros, and our own UTIL_PATH_PROGS and UTIL_CHECK_TOOLS. These did not have very well defined semantics, and were frequently mixed up. Also, UTIL_CHECK_TOOLS required UTIL_FIXUP_EXECUTABLE tobe called afterwards, to "rewrite" the result in a second step. This was not needed after UTIL_PATH_PROGS but was frequently done anyway to "be on the safe side".
> 
> I have now replaced:
>    AC_(PATH|CHECK)_(PROG|PROGS) with UTIL_LOOKUP_PROGS
>    AC_(PATH|CHECK)_(TOOL|TOOLS) with UTIL_LOOKUP_TOOLCHAIN_PROGS
> 
> This is actually almost the same semantic, but unless you're an autoconf aficionado, you ar not likely to understand the difference     between "PROG" and "TOOL". The only difference is that UTIL_LOOKUP_TOOLCHAIN_PROGS will try to look for "host-prefixed" tools first, when cross-compiling, and should therefore be used for all toolchain lookups.
> 
> There is also a fail-fast version of both, UTIL_REQUIRE_PROGS and UTIL_REQUIRE_TOOLCHAIN_PROGS.
> 
> UTIL_LOOKUP_PROGS is the core function, with the rest being thin wrappers around it. This function is created from scratch, to do exactly what we want, on Unix platforms and Windows. So there is no need anymore to call UTIL_FIXUP_EXECUTABLE, unless you have input from elsewhere (e.g. user flag) that you need to verify. I have also collected all this logic in a single file, util_paths.m4, moving parts from util.m4, and just removing util_windows.m4.
> 
> UTIL_LOOKUP_PROGS will use the new and nifty function UTIL_CHECK_WINENV_EXEC_TYPE, which will automatically determine if an executable needs to be prefixed by fixpath! That means that you can match and mix Windows-style and Unix-style programs however you like, with very few limitations. For instance, you can have a Linux version of the BootJDK on WSL. For this to work, the $FIXPATH prefix is now stored in the variables themselves (e.g. in $CC), rather than added as @FIXPATH@ in spec.gmk.in. This has generally worked out OK, but caused some headaches when the code thought that $CC (etc) was not a way to launch a program, but was a file that could be tested for existence, etc.
> 
> I reintroduced support for msys2. This was mostly free, since msys2 is so close to cygwin (which msys never where). To underline the difference, I renamed the winenv windows.msys2 (instead of windows.msys). Msys (version 1) will never be supported in modern OpenJDK due to critical packages being far too old, and not updated. I also clearly separate between WSL1 (which is using a kernel emulation layer, somewhat like Wine) and WSL2 (which is using a Hyper-V VM to run an actual Linux kernel), as windows.wsl1 and windows.wsl2.
> 
> I have also done a ton of small fixes, to make things more convenient and smooth when working in these winenvs. I have adjusted the output from configure to be less verbose and more streamlined. Overall, a lot of odd code in configure has been removed. A few changes that are strictly unneeded for this patch has also been included; mostly removal of dead code I came across, and a few fixes for additional debuggability that I needed when developing this patch, like ExecuteithLog.
> 
> I have also temporarily disabled the javac server, and building without absolute paths. I believe a better way forward is to address these with improved functionality in separate patches, instead of trying to work around the issues introduced by them in this patch.
> 
> I have done substantial testing of the core functionality (building jdk-images) on Cygwin, Msys2 and WSL2, both on my personal machine and on Oracle's CI system. The performance on Cygwin (which we use for our CI builds) is roughly on par with the old Cygwin performance, but the WSL1 performance is roughly 20% faster, so I think we should investigate if it is possible for us to switch to WSL1. Everything seems stable so far, but more testing is definitely needed. I have also not even started testing autxillary     functionality, such as the compare script, IDE project file generation etc.
> 
> However, the big disappointment in all of this is WSL2. That was the main driver that got me started on this rewrite. But it turned out that WSL2 is still very immature. :-( There are lot of issues, like stdout and stderr getting messed up, time synchronization issues causing make to complain about "Clock skew detected", extreme slowness when accessing disks cross the OS boundary. But worst of all has been that WSL2 is *extremly* unstable. After a few calls of Window executables, I get the impression that a conversion daemon dies. All further calls to Window binaries just stalls, and the WSL2 instance is unusable until I terminate it using "wsl -t Ubuntu-2004" from a cmd shell. :-(
> 
> So the WSL2 functionality is not very well tested, since I have not been able to build it completely a single time. I do believe that everything is correct, in "theory". So in case this is something broken with my WSL2 installation, I'd encourage anyone with a WSL2 installation to try it out.
> 
> /Magnus
> 


From youngty1997 at gmail.com  Thu Jul  9 08:29:58 2020
From: youngty1997 at gmail.com (Ty Young)
Date: Thu, 9 Jul 2020 03:29:58 -0500
Subject: cannot find valid Visual Code Studio install
Message-ID: <878af486-ec0b-525e-05c4-857e0c59128f@gmail.com>

Hopefully this is the right place. Don't shoot me if it isn't, please.


I'm trying to build the JDK from Windows 10. I got so far as to 
configure failing on finding what it needs from the Visual Code Studio 
install via command line:


configure: Found Visual Studio installation at /cygdrive/c/Program Files 
(x86)/Microsoft Visual Studio/2019/Community using well-known name
configure: Warning: None of vc/bin/amd64/vcvars64.bat 
vc/bin/x86_amd64/vcvarsx86_amd64.bat 
VC/Auxiliary/Build/vcvarsx86_amd64.bat VC/Auxiliary/Build/vcvars64.bat 
were found, Visual Studio installation not recognized. Ignoring
configure: Found Visual Studio installation at /cygdrive/c/Program Files 
(x86)/Microsoft Visual Studio/2019/Community using well-known name
configure: Warning: None of vc/bin/amd64/vcvars64.bat 
vc/bin/x86_amd64/vcvarsx86_amd64.bat 
VC/Auxiliary/Build/vcvarsx86_amd64.bat VC/Auxiliary/Build/vcvars64.bat 
were found, Visual Studio installation not recognized. Ignoring
configure: Cannot locate a valid Visual Studio installation, checking 
current environment
checking for Visual Studio variables... not found
configure: Cannot locate a valid Visual Studio or Windows SDK 
installation on disk,
configure: nor is this script run from a Visual Studio command prompt.
configure: Try setting --with-tools-dir to the VC/bin directory within 
the VS installation


However there is no "bin" directory in this installation, at least not 
one that contains any of the specified files. This is Visual Code 2019 
Community, but I've tried the Professional version too. The building 
document doesn't specify which version, nor does it tell me how to fix this.


How do I get this to work via command line?



From erik.joelsson at oracle.com  Thu Jul  9 12:37:51 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 9 Jul 2020 05:37:51 -0700
Subject: cannot find valid Visual Code Studio install
In-Reply-To: <878af486-ec0b-525e-05c4-857e0c59128f@gmail.com>
References: <878af486-ec0b-525e-05c4-857e0c59128f@gmail.com>
Message-ID: <1e8972ff-db0e-86e7-5e26-06e50b8cd491@oracle.com>

Hello Ty,

Microsoft Visual Studio 2019 or 2017, any edition, should work. My best 
guess is that you skipped installing the necessary parts of it. Run the 
installer again, click "Modify" and make sure you have "Desktop 
development with C++" ticked in.

/ERik

On 2020-07-09 01:29, Ty Young wrote:
> Hopefully this is the right place. Don't shoot me if it isn't, please.
>
>
> I'm trying to build the JDK from Windows 10. I got so far as to 
> configure failing on finding what it needs from the Visual Code Studio 
> install via command line:
>
>
> configure: Found Visual Studio installation at /cygdrive/c/Program 
> Files (x86)/Microsoft Visual Studio/2019/Community using well-known name
> configure: Warning: None of vc/bin/amd64/vcvars64.bat 
> vc/bin/x86_amd64/vcvarsx86_amd64.bat 
> VC/Auxiliary/Build/vcvarsx86_amd64.bat VC/Auxiliary/Build/vcvars64.bat 
> were found, Visual Studio installation not recognized. Ignoring
> configure: Found Visual Studio installation at /cygdrive/c/Program 
> Files (x86)/Microsoft Visual Studio/2019/Community using well-known name
> configure: Warning: None of vc/bin/amd64/vcvars64.bat 
> vc/bin/x86_amd64/vcvarsx86_amd64.bat 
> VC/Auxiliary/Build/vcvarsx86_amd64.bat VC/Auxiliary/Build/vcvars64.bat 
> were found, Visual Studio installation not recognized. Ignoring
> configure: Cannot locate a valid Visual Studio installation, checking 
> current environment
> checking for Visual Studio variables... not found
> configure: Cannot locate a valid Visual Studio or Windows SDK 
> installation on disk,
> configure: nor is this script run from a Visual Studio command prompt.
> configure: Try setting --with-tools-dir to the VC/bin directory within 
> the VS installation
>
>
> However there is no "bin" directory in this installation, at least not 
> one that contains any of the specified files. This is Visual Code 2019 
> Community, but I've tried the Professional version too. The building 
> document doesn't specify which version, nor does it tell me how to fix 
> this.
>
>
> How do I get this to work via command line?
>


From youngty1997 at gmail.com  Thu Jul  9 14:04:53 2020
From: youngty1997 at gmail.com (Ty Young)
Date: Thu, 9 Jul 2020 09:04:53 -0500
Subject: cannot find valid Visual Code Studio install
In-Reply-To: <1e8972ff-db0e-86e7-5e26-06e50b8cd491@oracle.com>
References: <878af486-ec0b-525e-05c4-857e0c59128f@gmail.com>
 <1e8972ff-db0e-86e7-5e26-06e50b8cd491@oracle.com>
Message-ID: <160667fd-50ab-fa83-0a49-8baae686eb8d@gmail.com>


On 7/9/20 7:37 AM, Erik Joelsson wrote:
> Hello Ty,
>
> Microsoft Visual Studio 2019 or 2017, any edition, should work. My 
> best guess is that you skipped installing the necessary parts of it. 
> Run the installer again, click "Modify" and make sure you have 
> "Desktop development with C++" ticked in.


That worked, thanks!


It still didn't configure though. Now it's complaining about not having 
clang installed. Once I installed clang and clang-devel, it then 
complained about not having version 9 installed. The latest version from 
cygdrive was 8<something>, 9 is not an option. If I try to trick it by 
copying and renaming the older 8<something> version, it then complains 
about Index.h being found but not being compileable and to report it here.


Any advice here? I tried installing more extra stuff from Visual Code 
Studio to see if it'd help, but it doesn't or I'm not installing the 
right things.


>
> /ERik
>
> On 2020-07-09 01:29, Ty Young wrote:
>> Hopefully this is the right place. Don't shoot me if it isn't, please.
>>
>>
>> I'm trying to build the JDK from Windows 10. I got so far as to 
>> configure failing on finding what it needs from the Visual Code 
>> Studio install via command line:
>>
>>
>> configure: Found Visual Studio installation at /cygdrive/c/Program 
>> Files (x86)/Microsoft Visual Studio/2019/Community using well-known name
>> configure: Warning: None of vc/bin/amd64/vcvars64.bat 
>> vc/bin/x86_amd64/vcvarsx86_amd64.bat 
>> VC/Auxiliary/Build/vcvarsx86_amd64.bat 
>> VC/Auxiliary/Build/vcvars64.bat were found, Visual Studio 
>> installation not recognized. Ignoring
>> configure: Found Visual Studio installation at /cygdrive/c/Program 
>> Files (x86)/Microsoft Visual Studio/2019/Community using well-known name
>> configure: Warning: None of vc/bin/amd64/vcvars64.bat 
>> vc/bin/x86_amd64/vcvarsx86_amd64.bat 
>> VC/Auxiliary/Build/vcvarsx86_amd64.bat 
>> VC/Auxiliary/Build/vcvars64.bat were found, Visual Studio 
>> installation not recognized. Ignoring
>> configure: Cannot locate a valid Visual Studio installation, checking 
>> current environment
>> checking for Visual Studio variables... not found
>> configure: Cannot locate a valid Visual Studio or Windows SDK 
>> installation on disk,
>> configure: nor is this script run from a Visual Studio command prompt.
>> configure: Try setting --with-tools-dir to the VC/bin directory 
>> within the VS installation
>>
>>
>> However there is no "bin" directory in this installation, at least 
>> not one that contains any of the specified files. This is Visual Code 
>> 2019 Community, but I've tried the Professional version too. The 
>> building document doesn't specify which version, nor does it tell me 
>> how to fix this.
>>
>>
>> How do I get this to work via command line?
>>


From erik.joelsson at oracle.com  Thu Jul  9 14:22:14 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 9 Jul 2020 07:22:14 -0700
Subject: cannot find valid Visual Code Studio install
In-Reply-To: <160667fd-50ab-fa83-0a49-8baae686eb8d@gmail.com>
References: <878af486-ec0b-525e-05c4-857e0c59128f@gmail.com>
 <1e8972ff-db0e-86e7-5e26-06e50b8cd491@oracle.com>
 <160667fd-50ab-fa83-0a49-8baae686eb8d@gmail.com>
Message-ID: <1afb447c-51ab-e105-97e1-7d71621bbb48@oracle.com>

Could you post the full configure command and log please. This sounds 
weird. You should not be needing clang on Windows.

Also, what source did you clone?

/Erik

On 2020-07-09 07:04, Ty Young wrote:
>
> On 7/9/20 7:37 AM, Erik Joelsson wrote:
>> Hello Ty,
>>
>> Microsoft Visual Studio 2019 or 2017, any edition, should work. My 
>> best guess is that you skipped installing the necessary parts of it. 
>> Run the installer again, click "Modify" and make sure you have 
>> "Desktop development with C++" ticked in.
>
>
> That worked, thanks!
>
>
> It still didn't configure though. Now it's complaining about not 
> having clang installed. Once I installed clang and clang-devel, it 
> then complained about not having version 9 installed. The latest 
> version from cygdrive was 8<something>, 9 is not an option. If I try 
> to trick it by copying and renaming the older 8<something> version, it 
> then complains about Index.h being found but not being compileable and 
> to report it here.
>
>
> Any advice here? I tried installing more extra stuff from Visual Code 
> Studio to see if it'd help, but it doesn't or I'm not installing the 
> right things.
>
>
>>
>> /ERik
>>
>> On 2020-07-09 01:29, Ty Young wrote:
>>> Hopefully this is the right place. Don't shoot me if it isn't, please.
>>>
>>>
>>> I'm trying to build the JDK from Windows 10. I got so far as to 
>>> configure failing on finding what it needs from the Visual Code 
>>> Studio install via command line:
>>>
>>>
>>> configure: Found Visual Studio installation at /cygdrive/c/Program 
>>> Files (x86)/Microsoft Visual Studio/2019/Community using well-known 
>>> name
>>> configure: Warning: None of vc/bin/amd64/vcvars64.bat 
>>> vc/bin/x86_amd64/vcvarsx86_amd64.bat 
>>> VC/Auxiliary/Build/vcvarsx86_amd64.bat 
>>> VC/Auxiliary/Build/vcvars64.bat were found, Visual Studio 
>>> installation not recognized. Ignoring
>>> configure: Found Visual Studio installation at /cygdrive/c/Program 
>>> Files (x86)/Microsoft Visual Studio/2019/Community using well-known 
>>> name
>>> configure: Warning: None of vc/bin/amd64/vcvars64.bat 
>>> vc/bin/x86_amd64/vcvarsx86_amd64.bat 
>>> VC/Auxiliary/Build/vcvarsx86_amd64.bat 
>>> VC/Auxiliary/Build/vcvars64.bat were found, Visual Studio 
>>> installation not recognized. Ignoring
>>> configure: Cannot locate a valid Visual Studio installation, 
>>> checking current environment
>>> checking for Visual Studio variables... not found
>>> configure: Cannot locate a valid Visual Studio or Windows SDK 
>>> installation on disk,
>>> configure: nor is this script run from a Visual Studio command prompt.
>>> configure: Try setting --with-tools-dir to the VC/bin directory 
>>> within the VS installation
>>>
>>>
>>> However there is no "bin" directory in this installation, at least 
>>> not one that contains any of the specified files. This is Visual 
>>> Code 2019 Community, but I've tried the Professional version too. 
>>> The building document doesn't specify which version, nor does it 
>>> tell me how to fix this.
>>>
>>>
>>> How do I get this to work via command line?
>>>


From youngty1997 at gmail.com  Thu Jul  9 19:56:55 2020
From: youngty1997 at gmail.com (Ty Young)
Date: Thu, 9 Jul 2020 14:56:55 -0500
Subject: cannot find valid Visual Code Studio install
In-Reply-To: <1afb447c-51ab-e105-97e1-7d71621bbb48@oracle.com>
References: <878af486-ec0b-525e-05c4-857e0c59128f@gmail.com>
 <1e8972ff-db0e-86e7-5e26-06e50b8cd491@oracle.com>
 <160667fd-50ab-fa83-0a49-8baae686eb8d@gmail.com>
 <1afb447c-51ab-e105-97e1-7d71621bbb48@oracle.com>
Message-ID: <34357344-bf7e-8a02-b61d-2a03ad7188ee@gmail.com>


On 7/9/20 9:22 AM, Erik Joelsson wrote:
> Could you post the full configure command and log please. This sounds 
> weird. You should not be needing clang on Windows.
>
> Also, what source did you clone?


On linux right now, but I think it's because I'm using the jextract 
branch of panama-foreign:


https://github.com/openjdk/panama-foreign


I remember there being a commit some time ago that requires clang to be 
specified on panama-dev, but I've never had to do that under Linux. This 
is my first time compiling on Windows so I have no idea what's going on.


>
> /Erik
>
> On 2020-07-09 07:04, Ty Young wrote:
>>
>> On 7/9/20 7:37 AM, Erik Joelsson wrote:
>>> Hello Ty,
>>>
>>> Microsoft Visual Studio 2019 or 2017, any edition, should work. My 
>>> best guess is that you skipped installing the necessary parts of it. 
>>> Run the installer again, click "Modify" and make sure you have 
>>> "Desktop development with C++" ticked in.
>>
>>
>> That worked, thanks!
>>
>>
>> It still didn't configure though. Now it's complaining about not 
>> having clang installed. Once I installed clang and clang-devel, it 
>> then complained about not having version 9 installed. The latest 
>> version from cygdrive was 8<something>, 9 is not an option. If I try 
>> to trick it by copying and renaming the older 8<something> version, 
>> it then complains about Index.h being found but not being compileable 
>> and to report it here.
>>
>>
>> Any advice here? I tried installing more extra stuff from Visual Code 
>> Studio to see if it'd help, but it doesn't or I'm not installing the 
>> right things.
>>
>>
>>>
>>> /ERik
>>>
>>> On 2020-07-09 01:29, Ty Young wrote:
>>>> Hopefully this is the right place. Don't shoot me if it isn't, please.
>>>>
>>>>
>>>> I'm trying to build the JDK from Windows 10. I got so far as to 
>>>> configure failing on finding what it needs from the Visual Code 
>>>> Studio install via command line:
>>>>
>>>>
>>>> configure: Found Visual Studio installation at /cygdrive/c/Program 
>>>> Files (x86)/Microsoft Visual Studio/2019/Community using well-known 
>>>> name
>>>> configure: Warning: None of vc/bin/amd64/vcvars64.bat 
>>>> vc/bin/x86_amd64/vcvarsx86_amd64.bat 
>>>> VC/Auxiliary/Build/vcvarsx86_amd64.bat 
>>>> VC/Auxiliary/Build/vcvars64.bat were found, Visual Studio 
>>>> installation not recognized. Ignoring
>>>> configure: Found Visual Studio installation at /cygdrive/c/Program 
>>>> Files (x86)/Microsoft Visual Studio/2019/Community using well-known 
>>>> name
>>>> configure: Warning: None of vc/bin/amd64/vcvars64.bat 
>>>> vc/bin/x86_amd64/vcvarsx86_amd64.bat 
>>>> VC/Auxiliary/Build/vcvarsx86_amd64.bat 
>>>> VC/Auxiliary/Build/vcvars64.bat were found, Visual Studio 
>>>> installation not recognized. Ignoring
>>>> configure: Cannot locate a valid Visual Studio installation, 
>>>> checking current environment
>>>> checking for Visual Studio variables... not found
>>>> configure: Cannot locate a valid Visual Studio or Windows SDK 
>>>> installation on disk,
>>>> configure: nor is this script run from a Visual Studio command prompt.
>>>> configure: Try setting --with-tools-dir to the VC/bin directory 
>>>> within the VS installation
>>>>
>>>>
>>>> However there is no "bin" directory in this installation, at least 
>>>> not one that contains any of the specified files. This is Visual 
>>>> Code 2019 Community, but I've tried the Professional version too. 
>>>> The building document doesn't specify which version, nor does it 
>>>> tell me how to fix this.
>>>>
>>>>
>>>> How do I get this to work via command line?
>>>>


From erik.joelsson at oracle.com  Thu Jul  9 20:20:14 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 9 Jul 2020 13:20:14 -0700
Subject: cannot find valid Visual Code Studio install
In-Reply-To: <34357344-bf7e-8a02-b61d-2a03ad7188ee@gmail.com>
References: <878af486-ec0b-525e-05c4-857e0c59128f@gmail.com>
 <1e8972ff-db0e-86e7-5e26-06e50b8cd491@oracle.com>
 <160667fd-50ab-fa83-0a49-8baae686eb8d@gmail.com>
 <1afb447c-51ab-e105-97e1-7d71621bbb48@oracle.com>
 <34357344-bf7e-8a02-b61d-2a03ad7188ee@gmail.com>
Message-ID: <875a5d2f-87b0-a323-12bd-297cc04ddfa8@oracle.com>


On 2020-07-09 12:56, Ty Young wrote:
>
> On 7/9/20 9:22 AM, Erik Joelsson wrote:
>> Could you post the full configure command and log please. This sounds 
>> weird. You should not be needing clang on Windows.
>>
>> Also, what source did you clone?
>
>
> On linux right now, but I think it's because I'm using the jextract 
> branch of panama-foreign:
>
>
> https://github.com/openjdk/panama-foreign
>
This was a very crucial piece of information that you left out 
initially. Panama uses libclang for specific new features in that 
project. I don't know the details on how to build that project. You will 
need to ask people working on Panama for details on any special needs 
they have.

I would recommend you clone the mainline jdk and get that to work first 
as a baseline.

/Erik

>
> I remember there being a commit some time ago that requires clang to 
> be specified on panama-dev, but I've never had to do that under Linux. 
> This is my first time compiling on Windows so I have no idea what's 
> going on.
>
>
>>
>> /Erik
>>
>> On 2020-07-09 07:04, Ty Young wrote:
>>>
>>> On 7/9/20 7:37 AM, Erik Joelsson wrote:
>>>> Hello Ty,
>>>>
>>>> Microsoft Visual Studio 2019 or 2017, any edition, should work. My 
>>>> best guess is that you skipped installing the necessary parts of 
>>>> it. Run the installer again, click "Modify" and make sure you have 
>>>> "Desktop development with C++" ticked in.
>>>
>>>
>>> That worked, thanks!
>>>
>>>
>>> It still didn't configure though. Now it's complaining about not 
>>> having clang installed. Once I installed clang and clang-devel, it 
>>> then complained about not having version 9 installed. The latest 
>>> version from cygdrive was 8<something>, 9 is not an option. If I try 
>>> to trick it by copying and renaming the older 8<something> version, 
>>> it then complains about Index.h being found but not being 
>>> compileable and to report it here.
>>>
>>>
>>> Any advice here? I tried installing more extra stuff from Visual 
>>> Code Studio to see if it'd help, but it doesn't or I'm not 
>>> installing the right things.
>>>
>>>
>>>>
>>>> /ERik
>>>>
>>>> On 2020-07-09 01:29, Ty Young wrote:
>>>>> Hopefully this is the right place. Don't shoot me if it isn't, 
>>>>> please.
>>>>>
>>>>>
>>>>> I'm trying to build the JDK from Windows 10. I got so far as to 
>>>>> configure failing on finding what it needs from the Visual Code 
>>>>> Studio install via command line:
>>>>>
>>>>>
>>>>> configure: Found Visual Studio installation at /cygdrive/c/Program 
>>>>> Files (x86)/Microsoft Visual Studio/2019/Community using 
>>>>> well-known name
>>>>> configure: Warning: None of vc/bin/amd64/vcvars64.bat 
>>>>> vc/bin/x86_amd64/vcvarsx86_amd64.bat 
>>>>> VC/Auxiliary/Build/vcvarsx86_amd64.bat 
>>>>> VC/Auxiliary/Build/vcvars64.bat were found, Visual Studio 
>>>>> installation not recognized. Ignoring
>>>>> configure: Found Visual Studio installation at /cygdrive/c/Program 
>>>>> Files (x86)/Microsoft Visual Studio/2019/Community using 
>>>>> well-known name
>>>>> configure: Warning: None of vc/bin/amd64/vcvars64.bat 
>>>>> vc/bin/x86_amd64/vcvarsx86_amd64.bat 
>>>>> VC/Auxiliary/Build/vcvarsx86_amd64.bat 
>>>>> VC/Auxiliary/Build/vcvars64.bat were found, Visual Studio 
>>>>> installation not recognized. Ignoring
>>>>> configure: Cannot locate a valid Visual Studio installation, 
>>>>> checking current environment
>>>>> checking for Visual Studio variables... not found
>>>>> configure: Cannot locate a valid Visual Studio or Windows SDK 
>>>>> installation on disk,
>>>>> configure: nor is this script run from a Visual Studio command 
>>>>> prompt.
>>>>> configure: Try setting --with-tools-dir to the VC/bin directory 
>>>>> within the VS installation
>>>>>
>>>>>
>>>>> However there is no "bin" directory in this installation, at least 
>>>>> not one that contains any of the specified files. This is Visual 
>>>>> Code 2019 Community, but I've tried the Professional version too. 
>>>>> The building document doesn't specify which version, nor does it 
>>>>> tell me how to fix this.
>>>>>
>>>>>
>>>>> How do I get this to work via command line?
>>>>>


From youngty1997 at gmail.com  Thu Jul  9 22:04:46 2020
From: youngty1997 at gmail.com (Ty Young)
Date: Thu, 9 Jul 2020 17:04:46 -0500
Subject: cannot find valid Visual Code Studio install
In-Reply-To: <875a5d2f-87b0-a323-12bd-297cc04ddfa8@oracle.com>
References: <878af486-ec0b-525e-05c4-857e0c59128f@gmail.com>
 <1e8972ff-db0e-86e7-5e26-06e50b8cd491@oracle.com>
 <160667fd-50ab-fa83-0a49-8baae686eb8d@gmail.com>
 <1afb447c-51ab-e105-97e1-7d71621bbb48@oracle.com>
 <34357344-bf7e-8a02-b61d-2a03ad7188ee@gmail.com>
 <875a5d2f-87b0-a323-12bd-297cc04ddfa8@oracle.com>
Message-ID: <246ef571-112a-77b9-2338-82b89fb84202@gmail.com>


On 7/9/20 3:20 PM, Erik Joelsson wrote:
>
> On 2020-07-09 12:56, Ty Young wrote:
>>
>> On 7/9/20 9:22 AM, Erik Joelsson wrote:
>>> Could you post the full configure command and log please. This 
>>> sounds weird. You should not be needing clang on Windows.
>>>
>>> Also, what source did you clone?
>>
>>
>> On linux right now, but I think it's because I'm using the jextract 
>> branch of panama-foreign:
>>
>>
>> https://github.com/openjdk/panama-foreign
>>
> This was a very crucial piece of information that you left out 
> initially. Panama uses libclang for specific new features in that 
> project. I don't know the details on how to build that project. You 
> will need to ask people working on Panama for details on any special 
> needs they have.
>
> I would recommend you clone the mainline jdk and get that to work 
> first as a baseline.


Just did, as well as a version of panama-foreign that should work but 
doesn't need clang(foreign-abi).


It configures now, but fails to build with errors like:


c1xx: fatal error C1083: Cannot open source file: 
'../../../..c:/cygwin64/home/young/jdk-master/jdk-master/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM_pch.cpp': 
No such file or directory


Basically every file within the objs file is missing... but it isn't 
actually. I can see them in Windows explorer just fine and configure 
doesn't throw any errors.


Thinking that this was an issue with file depth, I moved the cloned 
source code to root as "jdk-build". It still fails in the same spot. 
Both of them.


>
> /Erik
>
>>
>> I remember there being a commit some time ago that requires clang to 
>> be specified on panama-dev, but I've never had to do that under 
>> Linux. This is my first time compiling on Windows so I have no idea 
>> what's going on.
>>
>>
>>>
>>> /Erik
>>>
>>> On 2020-07-09 07:04, Ty Young wrote:
>>>>
>>>> On 7/9/20 7:37 AM, Erik Joelsson wrote:
>>>>> Hello Ty,
>>>>>
>>>>> Microsoft Visual Studio 2019 or 2017, any edition, should work. My 
>>>>> best guess is that you skipped installing the necessary parts of 
>>>>> it. Run the installer again, click "Modify" and make sure you have 
>>>>> "Desktop development with C++" ticked in.
>>>>
>>>>
>>>> That worked, thanks!
>>>>
>>>>
>>>> It still didn't configure though. Now it's complaining about not 
>>>> having clang installed. Once I installed clang and clang-devel, it 
>>>> then complained about not having version 9 installed. The latest 
>>>> version from cygdrive was 8<something>, 9 is not an option. If I 
>>>> try to trick it by copying and renaming the older 8<something> 
>>>> version, it then complains about Index.h being found but not being 
>>>> compileable and to report it here.
>>>>
>>>>
>>>> Any advice here? I tried installing more extra stuff from Visual 
>>>> Code Studio to see if it'd help, but it doesn't or I'm not 
>>>> installing the right things.
>>>>
>>>>
>>>>>
>>>>> /ERik
>>>>>
>>>>> On 2020-07-09 01:29, Ty Young wrote:
>>>>>> Hopefully this is the right place. Don't shoot me if it isn't, 
>>>>>> please.
>>>>>>
>>>>>>
>>>>>> I'm trying to build the JDK from Windows 10. I got so far as to 
>>>>>> configure failing on finding what it needs from the Visual Code 
>>>>>> Studio install via command line:
>>>>>>
>>>>>>
>>>>>> configure: Found Visual Studio installation at 
>>>>>> /cygdrive/c/Program Files (x86)/Microsoft Visual 
>>>>>> Studio/2019/Community using well-known name
>>>>>> configure: Warning: None of vc/bin/amd64/vcvars64.bat 
>>>>>> vc/bin/x86_amd64/vcvarsx86_amd64.bat 
>>>>>> VC/Auxiliary/Build/vcvarsx86_amd64.bat 
>>>>>> VC/Auxiliary/Build/vcvars64.bat were found, Visual Studio 
>>>>>> installation not recognized. Ignoring
>>>>>> configure: Found Visual Studio installation at 
>>>>>> /cygdrive/c/Program Files (x86)/Microsoft Visual 
>>>>>> Studio/2019/Community using well-known name
>>>>>> configure: Warning: None of vc/bin/amd64/vcvars64.bat 
>>>>>> vc/bin/x86_amd64/vcvarsx86_amd64.bat 
>>>>>> VC/Auxiliary/Build/vcvarsx86_amd64.bat 
>>>>>> VC/Auxiliary/Build/vcvars64.bat were found, Visual Studio 
>>>>>> installation not recognized. Ignoring
>>>>>> configure: Cannot locate a valid Visual Studio installation, 
>>>>>> checking current environment
>>>>>> checking for Visual Studio variables... not found
>>>>>> configure: Cannot locate a valid Visual Studio or Windows SDK 
>>>>>> installation on disk,
>>>>>> configure: nor is this script run from a Visual Studio command 
>>>>>> prompt.
>>>>>> configure: Try setting --with-tools-dir to the VC/bin directory 
>>>>>> within the VS installation
>>>>>>
>>>>>>
>>>>>> However there is no "bin" directory in this installation, at 
>>>>>> least not one that contains any of the specified files. This is 
>>>>>> Visual Code 2019 Community, but I've tried the Professional 
>>>>>> version too. The building document doesn't specify which version, 
>>>>>> nor does it tell me how to fix this.
>>>>>>
>>>>>>
>>>>>> How do I get this to work via command line?
>>>>>>


From peter.levart at gmail.com  Fri Jul 10 06:37:28 2020
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 10 Jul 2020 08:37:28 +0200
Subject: cannot find valid Visual Code Studio install
In-Reply-To: <246ef571-112a-77b9-2338-82b89fb84202@gmail.com>
References: <878af486-ec0b-525e-05c4-857e0c59128f@gmail.com>
 <1e8972ff-db0e-86e7-5e26-06e50b8cd491@oracle.com>
 <160667fd-50ab-fa83-0a49-8baae686eb8d@gmail.com>
 <1afb447c-51ab-e105-97e1-7d71621bbb48@oracle.com>
 <34357344-bf7e-8a02-b61d-2a03ad7188ee@gmail.com>
 <875a5d2f-87b0-a323-12bd-297cc04ddfa8@oracle.com>
 <246ef571-112a-77b9-2338-82b89fb84202@gmail.com>
Message-ID: <e5789f47-a7a9-23e0-b55c-63089da0a3e7@gmail.com>

Don't know much about build system but the following caught my eye:


On 7/10/20 12:04 AM, Ty Young wrote:
> c1xx: fatal error C1083: Cannot open source file: 
> '../../../..c:/cygwin64/home/young/jdk-master/jdk-master/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM_pch.cpp': 
> No such file or directory 


I don't think `../../../..c:/cygwin64/home/young/jdk-master/...` is a 
valid path. It is a concatenation of a `../../../..` prefix and and 
absolute path with drive letter `c:/cygwin64/home/young/jdk-master/...` 
as suffix. Perhaps some logic is expecting the second part to be a 
relative path or doesn't detect that it is an absolute path so it tries 
to resolve it against the prefix. Maybe this is a hint of where to look 
for solution...


Peter




From erik.joelsson at oracle.com  Fri Jul 10 12:43:00 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 10 Jul 2020 05:43:00 -0700
Subject: cannot find valid Visual Code Studio install
In-Reply-To: <246ef571-112a-77b9-2338-82b89fb84202@gmail.com>
References: <878af486-ec0b-525e-05c4-857e0c59128f@gmail.com>
 <1e8972ff-db0e-86e7-5e26-06e50b8cd491@oracle.com>
 <160667fd-50ab-fa83-0a49-8baae686eb8d@gmail.com>
 <1afb447c-51ab-e105-97e1-7d71621bbb48@oracle.com>
 <34357344-bf7e-8a02-b61d-2a03ad7188ee@gmail.com>
 <875a5d2f-87b0-a323-12bd-297cc04ddfa8@oracle.com>
 <246ef571-112a-77b9-2338-82b89fb84202@gmail.com>
Message-ID: <bfb09866-41df-36a3-b503-0ef3023936e8@oracle.com>


On 2020-07-09 15:04, Ty Young wrote:
>
> On 7/9/20 3:20 PM, Erik Joelsson wrote:
>>
>> On 2020-07-09 12:56, Ty Young wrote:
>>>
>>> On 7/9/20 9:22 AM, Erik Joelsson wrote:
>>>> Could you post the full configure command and log please. This 
>>>> sounds weird. You should not be needing clang on Windows.
>>>>
>>>> Also, what source did you clone?
>>>
>>>
>>> On linux right now, but I think it's because I'm using the jextract 
>>> branch of panama-foreign:
>>>
>>>
>>> https://github.com/openjdk/panama-foreign
>>>
>> This was a very crucial piece of information that you left out 
>> initially. Panama uses libclang for specific new features in that 
>> project. I don't know the details on how to build that project. You 
>> will need to ask people working on Panama for details on any special 
>> needs they have.
>>
>> I would recommend you clone the mainline jdk and get that to work 
>> first as a baseline.
>
>
> Just did, as well as a version of panama-foreign that should work but 
> doesn't need clang(foreign-abi).
>
>
> It configures now, but fails to build with errors like:
>
>
> c1xx: fatal error C1083: Cannot open source file: 
> '../../../..c:/cygwin64/home/young/jdk-master/jdk-master/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM_pch.cpp': 
> No such file or directory
>
>
Could you send your configure.log, spec.gmk and the exact command lines 
you used?

/Erik

> Basically every file within the objs file is missing... but it isn't 
> actually. I can see them in Windows explorer just fine and configure 
> doesn't throw any errors.
>
>
> Thinking that this was an issue with file depth, I moved the cloned 
> source code to root as "jdk-build". It still fails in the same spot. 
> Both of them.
>
>
>>
>> /Erik
>>
>>>
>>> I remember there being a commit some time ago that requires clang to 
>>> be specified on panama-dev, but I've never had to do that under 
>>> Linux. This is my first time compiling on Windows so I have no idea 
>>> what's going on.
>>>
>>>
>>>>
>>>> /Erik
>>>>
>>>> On 2020-07-09 07:04, Ty Young wrote:
>>>>>
>>>>> On 7/9/20 7:37 AM, Erik Joelsson wrote:
>>>>>> Hello Ty,
>>>>>>
>>>>>> Microsoft Visual Studio 2019 or 2017, any edition, should work. 
>>>>>> My best guess is that you skipped installing the necessary parts 
>>>>>> of it. Run the installer again, click "Modify" and make sure you 
>>>>>> have "Desktop development with C++" ticked in.
>>>>>
>>>>>
>>>>> That worked, thanks!
>>>>>
>>>>>
>>>>> It still didn't configure though. Now it's complaining about not 
>>>>> having clang installed. Once I installed clang and clang-devel, it 
>>>>> then complained about not having version 9 installed. The latest 
>>>>> version from cygdrive was 8<something>, 9 is not an option. If I 
>>>>> try to trick it by copying and renaming the older 8<something> 
>>>>> version, it then complains about Index.h being found but not being 
>>>>> compileable and to report it here.
>>>>>
>>>>>
>>>>> Any advice here? I tried installing more extra stuff from Visual 
>>>>> Code Studio to see if it'd help, but it doesn't or I'm not 
>>>>> installing the right things.
>>>>>
>>>>>
>>>>>>
>>>>>> /ERik
>>>>>>
>>>>>> On 2020-07-09 01:29, Ty Young wrote:
>>>>>>> Hopefully this is the right place. Don't shoot me if it isn't, 
>>>>>>> please.
>>>>>>>
>>>>>>>
>>>>>>> I'm trying to build the JDK from Windows 10. I got so far as to 
>>>>>>> configure failing on finding what it needs from the Visual Code 
>>>>>>> Studio install via command line:
>>>>>>>
>>>>>>>
>>>>>>> configure: Found Visual Studio installation at 
>>>>>>> /cygdrive/c/Program Files (x86)/Microsoft Visual 
>>>>>>> Studio/2019/Community using well-known name
>>>>>>> configure: Warning: None of vc/bin/amd64/vcvars64.bat 
>>>>>>> vc/bin/x86_amd64/vcvarsx86_amd64.bat 
>>>>>>> VC/Auxiliary/Build/vcvarsx86_amd64.bat 
>>>>>>> VC/Auxiliary/Build/vcvars64.bat were found, Visual Studio 
>>>>>>> installation not recognized. Ignoring
>>>>>>> configure: Found Visual Studio installation at 
>>>>>>> /cygdrive/c/Program Files (x86)/Microsoft Visual 
>>>>>>> Studio/2019/Community using well-known name
>>>>>>> configure: Warning: None of vc/bin/amd64/vcvars64.bat 
>>>>>>> vc/bin/x86_amd64/vcvarsx86_amd64.bat 
>>>>>>> VC/Auxiliary/Build/vcvarsx86_amd64.bat 
>>>>>>> VC/Auxiliary/Build/vcvars64.bat were found, Visual Studio 
>>>>>>> installation not recognized. Ignoring
>>>>>>> configure: Cannot locate a valid Visual Studio installation, 
>>>>>>> checking current environment
>>>>>>> checking for Visual Studio variables... not found
>>>>>>> configure: Cannot locate a valid Visual Studio or Windows SDK 
>>>>>>> installation on disk,
>>>>>>> configure: nor is this script run from a Visual Studio command 
>>>>>>> prompt.
>>>>>>> configure: Try setting --with-tools-dir to the VC/bin directory 
>>>>>>> within the VS installation
>>>>>>>
>>>>>>>
>>>>>>> However there is no "bin" directory in this installation, at 
>>>>>>> least not one that contains any of the specified files. This is 
>>>>>>> Visual Code 2019 Community, but I've tried the Professional 
>>>>>>> version too. The building document doesn't specify which 
>>>>>>> version, nor does it tell me how to fix this.
>>>>>>>
>>>>>>>
>>>>>>> How do I get this to work via command line?
>>>>>>>


From galder at redhat.com  Fri Jul 10 16:48:46 2020
From: galder at redhat.com (Galder Zamarreno)
Date: Fri, 10 Jul 2020 18:48:46 +0200
Subject: RFR: JDK-8248158 Configure fails with autoconf not found even
 though it's installed
In-Reply-To: <CAAcPREuMD3e=mDbtmZJj8dJuBP+5k12VxoKr=0TAn460BqUQZA@mail.gmail.com>
References: <CAAcPREuoXF9rrO5YrZwYdNO6iUvQv=Yv7mPHY_OcRZ6H=7K+kg@mail.gmail.com>
 <5b25d03a-675f-072a-5772-2e2b03739484@oracle.com>
 <CAAcPREsPO5jGDWH+Y59rPonzOBf14+M3+t8or-wNuH6KAyOVtw@mail.gmail.com>
 <7ba7f5cd-abd2-3331-e836-97e769a8189d@redhat.com>
 <CAAcPREuMD3e=mDbtmZJj8dJuBP+5k12VxoKr=0TAn460BqUQZA@mail.gmail.com>
Message-ID: <CAAcPREs_PF8rD3-BKjfcKsj+TsUv7wXaQTOZaE48u95ccPe0pQ@mail.gmail.com>

Hi again,

I've got a new webrev for this:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8248158/02/webrev/

It further expands `type -p` to replace `command -v` uses. It also replaces
$WHICH usages and removes the check for `which` as well.

I tried Simon's suggestions, but getting that right complicated the patch.

Galder


On Tue, Jul 7, 2020 at 4:31 PM Galder Zamarreno <galder at redhat.com> wrote:

>
>
> On Mon, Jul 6, 2020 at 10:50 PM Simon Tooke <stooke at redhat.com> wrote:
>
>> (Disclaimer: I am not a reviewer, so this is an opinion, not a review)
>>
>> I have tested this on Windows and it built without issue, although the
>> submit repo should be the final gate.  I'd also like to add my void to
>> simply redefining 'WHICH' as it leads to less changes in the source
>> code, which would make life easier should this be backported to 11u
>> and/or 8u.
>
>
> So, you would just switch the UTIL_REQUIRE_PROGS call for WHICH to be
> `type ...` instead?
>
>
>>
>> -Simon
>>
>> On 2020-07-02 4:22 a.m., Galder Zamarreno wrote:
>> > On Thu, Jul 2, 2020 at 12:37 AM Magnus Ihse Bursie <
>> > magnus.ihse.bursie at oracle.com> wrote:
>> >
>> >>
>> >> On 2020-07-01 12:05, Galder Zamarreno wrote:
>> >>> Using `which` to check whether commands exist can result in confusing
>> >>> errors when `which` itself is not installed in the system. This is the
>> >> case
>> >>> with `autoconf`, where if `autoconf` is present but `which` isn't, the
>> >>> build system says that `autoconf` is missing, when in reality it is
>> >> `which`
>> >>> which is missing. The fix switches autoconf uses of `which` for `type
>> -p`
>> >>> instead, which is a Bash built-in command.
>> >>>
>> >>> I've tested the fix with a fedora docker container that had `autoconf`
>> >>> installed but `which`. When using `type -p` it correctly detects
>> >> `autoconf`
>> >>> installed and eventually fails saying that `which` is not installed,
>> >> which
>> >>> is the expected behaviour.
>> >>>
>> >>> `which` is still in use in make/autoconf/util_windows.m4. A possible
>> >> future
>> >>> improvement would be to see if `which` use there could be replaced as
>> >> well.
>> >>> Eventually, when no `which` uses remain, the presence check for
>> `which`
>> >>> could be removed.
>> >> I agree that we should replace "which" with "type -p" everywhere. The
>> >> best way to do this is probably to replace the value of $WHICH with
>> >> "type -p". It's a bash built-in, so we can count on its presence. If
>> you
>> >> want to fix that as part of this bug, I'm ok with it, otherwise we
>> >> should open a new bug to track this. I think there is also one or two
>> >> instances of "command" recently added as (better, but not as good as
>> >> "type -p") replacements for which.
>> >>
>> > I discovered one place in util.m4 where command was being used.
>> >
>> > There are other places outside of make/ where command is used but I feel
>> > those are a bit out of scope here.
>> >
>> > My main objective is that from a configure perspective, we'd try to
>> reduce
>> > the number of dependencies needed to build things.
>> >
>> > I'll send an updated webrev shortly.
>> >
>> >
>> >> /Magnus
>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8248158
>> >>> WebRev:
>> >> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8248158/01/webrev/
>> >>> Galder
>> >>
>>
>>


From erik.joelsson at oracle.com  Fri Jul 10 17:33:25 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 10 Jul 2020 10:33:25 -0700
Subject: RFR: JDK-8249195: Change to Xcode 11.3.1 for building on Macos at
 Oracle
Message-ID: <3559426b-2398-2fcb-2730-9ad511ef70a2@oracle.com>

Please review this change which changes the compiler version used to 
build for Macos at Oracle to Xcode 11.3.1.

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

Webrev: http://cr.openjdk.java.net/~erikj/8249195/webrev.01/index.html

/Erik



From magnus.ihse.bursie at oracle.com  Sat Jul 11 00:12:12 2020
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Sat, 11 Jul 2020 02:12:12 +0200
Subject: RFR: JDK-8249195: Change to Xcode 11.3.1 for building on Macos at
 Oracle
In-Reply-To: <3559426b-2398-2fcb-2730-9ad511ef70a2@oracle.com>
References: <3559426b-2398-2fcb-2730-9ad511ef70a2@oracle.com>
Message-ID: <2e1463a7-f7ef-de22-790d-bbe69c62cda1@oracle.com>

On 2020-07-10 19:33, Erik Joelsson wrote:
> Please review this change which changes the compiler version used to 
> build for Macos at Oracle to Xcode 11.3.1.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8249195
>
> Webrev: http://cr.openjdk.java.net/~erikj/8249195/webrev.01/index.html
Looks good to me.

/Magnus
>
> /Erik
>



From peter.levart at gmail.com  Sat Jul 11 07:31:03 2020
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 11 Jul 2020 09:31:03 +0200
Subject: RFR [XS]: 8248429: Add --enable-preview as VM argument when
 running microbenchmarks
In-Reply-To: <56572ec4-1c79-66f0-76b2-1a710b606d33@oracle.com>
References: <8cd2491e-3e90-6c00-1d09-c2a11022c287@oracle.com>
 <19b5a5a2-1f60-361e-c417-2933504907cd@oracle.com>
 <f70a3348-d9ee-4c50-1fdd-5558d54a8920@oracle.com>
 <b2ca5e6c-68c5-eee3-646c-48e6bb8ae2ea@oracle.com>
 <4e6978ad-774f-f8d4-c10a-b4a1482f25b1@oracle.com>
 <aef6de37-5bea-2513-2fa3-5cf6dd721435@oracle.com>
 <9784b512-3606-474b-18a6-dfe236b63ac8@oracle.com>
 <fca0f099-7f13-6b22-21ee-9b5dd6914256@oracle.com>
 <2f460e59-b5bc-4561-6c8a-712b1d7ee318@oracle.com>
 <af841f5a-9638-498e-44c0-d8c0220c43b9@oracle.com>
 <722302a9-9184-8800-d312-bb7a8ecd3dfb@oracle.com>
 <d1e82d58-0c32-c9db-02d6-1a333232a419@oracle.com>
 <16f12991-d147-0328-f2b1-e20845acb3b7@oracle.com>
 <f8d2eb35-3f10-ef4a-e41d-11deb2850581@gmail.com>
 <56572ec4-1c79-66f0-76b2-1a710b606d33@oracle.com>
Message-ID: <27f7334b-c2f4-21e9-6b05-bd400daa3893@gmail.com>


On 7/7/20 7:51 PM, Roger Riggs wrote:
> Hi,
>
> I have found it very useful to be able to run benchmarks against multiple
> versions of the JDK.? Build the benchmark jar once and to compare 
> results.
> If all of the classes are built with --enable-preview, none of them 
> will run
> against older JDKs. So an approach that only compiles those files that 
> need
> preview would be more useful. 
...
> Or perhaps, separate out preview based benchmarks
> into a separate jar.
>
> $.02, Roger


Perhaps the last option is the way to go. Why? Preview features are 
specific to a major OpenJDK release so while a particular preview 
feature may be present as a preview feature in two consecutive releases, 
you can not run a class with the preview feature compiled for OpenJDK N 
on an OpenJDK N+1 or vice versa. So a single benchmarks.jar file makes 
sense only for benchmarks that don't use preview features and are 
compiled with (or for) lowest release possible...


The benchmarks using preview feature OTOH will need to be re-classified 
once the preview feature graduates and becomes a mainline feature. So 
once it is classified differently in OpenJDK N+1 as it was in OpenJDK N, 
it can not be built with such classification on (or for) the OpenJDK N 
release any more because, among other things, names of packages/modules 
may change. So these two sets of benchmarks (using or not using preview 
features) have different constraints and is therefore reasonable for 
them to be built separately and packed into separate benchmarks.jar files.


Packing to separate .jar files might be a pragmatic solution for a 
problem that Jorn Vernee discovered: the JMH compiler plugin generates 
two files in the output directory which are included in the benchmarks.jar:

/META-INF/BenchmarkList

/META-INF/CompilerHints


While the 1st one is "updated" incrementally if it already exists, its 
modification is not protected by any kind of locking mechanism and so 
concurrent compilation by two or more instances of javac may produce 
garbled result. The 2nd one seems to be overwritten entirely by content 
of a single compile session, so its final form does not represent 
compiler hints for all aggregated benchmarks and may therefore produce 
skewed results for some benchmarks. I see two solutions for that problem:

- fix JMH to correctly handle concurrent incremental updates to both 
above files and; or

- compile the two sets of benchmarks separately with separate output 
directories and create separate benchmarks.jar files for them


I think the 2nd option is a simpler, pragmatic solution.


Peter


>
>
> On 7/7/20 10:26 AM, Peter Levart wrote:
>> I suggest adding --enable-preview to JMH_JVM_ARGS in general now (it 
>> doesn't hurt even if classes are not compiled with --enable-preview) 
>> and then take time to devise an effective strategy for selectively 
>> compiling micro benchmarks with or without --enable-preview. At least 
>> so the benchmarks would work out-of-the-box when run via make test.
>>
>> WDYT?
>>
>>
>> Regards, Peter
>>
>>
>> On 6/30/20 10:15 PM, Claes Redestad wrote:
>>> On 2020-06-30 22:12, Magnus Ihse Bursie wrote:
>>>>>
>>>>> Second to that a solution in the build would be preferable - if we 
>>>>> can
>>>>> come up with something that has infinitesimal impact to build times.
>>>> Are we talking about many files? Could you consider listing those 
>>>> files explicitly in the makefile? That would make it cheap to 
>>>> filter them out from the normal compilation, and instead do a 
>>>> secondary compilation with them.
>>>
>>> Right now there's one micro using --enable-preview, so that'd be a very
>>> short list.
>>>
>>> /Claes
>


From peter.levart at gmail.com  Sat Jul 11 10:00:17 2020
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 11 Jul 2020 12:00:17 +0200
Subject: RFR [XS]: 8248429: Add --enable-preview as VM argument when
 running microbenchmarks
In-Reply-To: <27f7334b-c2f4-21e9-6b05-bd400daa3893@gmail.com>
References: <8cd2491e-3e90-6c00-1d09-c2a11022c287@oracle.com>
 <19b5a5a2-1f60-361e-c417-2933504907cd@oracle.com>
 <f70a3348-d9ee-4c50-1fdd-5558d54a8920@oracle.com>
 <b2ca5e6c-68c5-eee3-646c-48e6bb8ae2ea@oracle.com>
 <4e6978ad-774f-f8d4-c10a-b4a1482f25b1@oracle.com>
 <aef6de37-5bea-2513-2fa3-5cf6dd721435@oracle.com>
 <9784b512-3606-474b-18a6-dfe236b63ac8@oracle.com>
 <fca0f099-7f13-6b22-21ee-9b5dd6914256@oracle.com>
 <2f460e59-b5bc-4561-6c8a-712b1d7ee318@oracle.com>
 <af841f5a-9638-498e-44c0-d8c0220c43b9@oracle.com>
 <722302a9-9184-8800-d312-bb7a8ecd3dfb@oracle.com>
 <d1e82d58-0c32-c9db-02d6-1a333232a419@oracle.com>
 <16f12991-d147-0328-f2b1-e20845acb3b7@oracle.com>
 <f8d2eb35-3f10-ef4a-e41d-11deb2850581@gmail.com>
 <56572ec4-1c79-66f0-76b2-1a710b606d33@oracle.com>
 <27f7334b-c2f4-21e9-6b05-bd400daa3893@gmail.com>
Message-ID: <92167b16-8a7c-ea24-fb52-4272cd9e2459@gmail.com>


On 7/11/20 9:31 AM, Peter Levart wrote:
> - compile the two sets of benchmarks separately with separate output 
> directories and create separate benchmarks.jar files for them 


Here's my attempt at a patch for separate benchmarks.jar files. The 
minor complication, as I found out, was what to do when running the 
micro benchmarks via "make test TEST=..." command when there are two 
possible jar files to choose from. I opted for a separate tag in TEST 
variable, so preview benchmark(s) are run as follows:


make test TEST="micro.preview: ..."


http://cr.openjdk.java.net/~plevart/jdk-dev/8248429_jmh_enable_preview/webrev.02/


WDYT?


Regards, Peter




From claes.redestad at oracle.com  Sat Jul 11 15:15:06 2020
From: claes.redestad at oracle.com (Claes Redestad)
Date: Sat, 11 Jul 2020 17:15:06 +0200
Subject: RFR [XS]: 8248429: Add --enable-preview as VM argument when
 running microbenchmarks
In-Reply-To: <92167b16-8a7c-ea24-fb52-4272cd9e2459@gmail.com>
References: <8cd2491e-3e90-6c00-1d09-c2a11022c287@oracle.com>
 <19b5a5a2-1f60-361e-c417-2933504907cd@oracle.com>
 <f70a3348-d9ee-4c50-1fdd-5558d54a8920@oracle.com>
 <b2ca5e6c-68c5-eee3-646c-48e6bb8ae2ea@oracle.com>
 <4e6978ad-774f-f8d4-c10a-b4a1482f25b1@oracle.com>
 <aef6de37-5bea-2513-2fa3-5cf6dd721435@oracle.com>
 <9784b512-3606-474b-18a6-dfe236b63ac8@oracle.com>
 <fca0f099-7f13-6b22-21ee-9b5dd6914256@oracle.com>
 <2f460e59-b5bc-4561-6c8a-712b1d7ee318@oracle.com>
 <af841f5a-9638-498e-44c0-d8c0220c43b9@oracle.com>
 <722302a9-9184-8800-d312-bb7a8ecd3dfb@oracle.com>
 <d1e82d58-0c32-c9db-02d6-1a333232a419@oracle.com>
 <16f12991-d147-0328-f2b1-e20845acb3b7@oracle.com>
 <f8d2eb35-3f10-ef4a-e41d-11deb2850581@gmail.com>
 <56572ec4-1c79-66f0-76b2-1a710b606d33@oracle.com>
 <27f7334b-c2f4-21e9-6b05-bd400daa3893@gmail.com>
 <92167b16-8a7c-ea24-fb52-4272cd9e2459@gmail.com>
Message-ID: <e700ecd2-11fe-e029-c233-c77e6b89bb89@oracle.com>

Hi,

I think the idea of generating two distinct jars is workable, but I
really don't like the prospect of routinely having to move micros around
as the features they test promote from preview.

Would a manually managed list of which tests use --enable-preview work
for you? Not ideal either, but that would be less intrusive when taking
the feature out of preview along with removal of the flag from the micro
settings.

Also, I believe the INDIFY step to be an unfortunate piece of technical
debt which we don't need to carry over to a preview build step.

Thanks!

/Claes

On 2020-07-11 12:00, Peter Levart wrote:
> 
> On 7/11/20 9:31 AM, Peter Levart wrote:
>> - compile the two sets of benchmarks separately with separate output 
>> directories and create separate benchmarks.jar files for them 
> 
> 
> Here's my attempt at a patch for separate benchmarks.jar files. The 
> minor complication, as I found out, was what to do when running the 
> micro benchmarks via "make test TEST=..." command when there are two 
> possible jar files to choose from. I opted for a separate tag in TEST 
> variable, so preview benchmark(s) are run as follows:
> 
> 
> make test TEST="micro.preview: ..."
> 
> 
> http://cr.openjdk.java.net/~plevart/jdk-dev/8248429_jmh_enable_preview/webrev.02/ 
> 
> 
> 
> WDYT?
> 
> 
> Regards, Peter
> 
> 


From joe.darcy at oracle.com  Sun Jul 12 01:07:09 2020
From: joe.darcy at oracle.com (Joe Darcy)
Date: Sat, 11 Jul 2020 18:07:09 -0700
Subject: JDK 16 RFR of JDK-8248605: Update --release 15 symbol information for
 JDK 15 build 31
Message-ID: <0941b801-956d-f256-5a3e-790882ded358@oracle.com>

Hello,

Please review the updates of the JDK 16 symbol information for JDK 15 b31:

 ??? JDK-8248605: Update --release 15 symbol information for JDK 15 
build 31
 ??? http://cr.openjdk.java.net/~darcy/8248605.0/

It is not actually clear to me why the script determined an update was 
needed. Jan, can you shed light here?

Thanks,

-Joe



From youngty1997 at gmail.com  Sun Jul 12 07:46:34 2020
From: youngty1997 at gmail.com (Ty Young)
Date: Sun, 12 Jul 2020 02:46:34 -0500
Subject: cannot find valid Visual Code Studio install
In-Reply-To: <bfb09866-41df-36a3-b503-0ef3023936e8@oracle.com>
References: <878af486-ec0b-525e-05c4-857e0c59128f@gmail.com>
 <1e8972ff-db0e-86e7-5e26-06e50b8cd491@oracle.com>
 <160667fd-50ab-fa83-0a49-8baae686eb8d@gmail.com>
 <1afb447c-51ab-e105-97e1-7d71621bbb48@oracle.com>
 <34357344-bf7e-8a02-b61d-2a03ad7188ee@gmail.com>
 <875a5d2f-87b0-a323-12bd-297cc04ddfa8@oracle.com>
 <246ef571-112a-77b9-2338-82b89fb84202@gmail.com>
 <bfb09866-41df-36a3-b503-0ef3023936e8@oracle.com>
Message-ID: <b9ded9c8-aab3-30c1-fbfd-a2cc78f965f7@gmail.com>


On 7/10/20 7:43 AM, Erik Joelsson wrote:
>
> On 2020-07-09 15:04, Ty Young wrote:
>>
>> On 7/9/20 3:20 PM, Erik Joelsson wrote:
>>>
>>> On 2020-07-09 12:56, Ty Young wrote:
>>>>
>>>> On 7/9/20 9:22 AM, Erik Joelsson wrote:
>>>>> Could you post the full configure command and log please. This 
>>>>> sounds weird. You should not be needing clang on Windows.
>>>>>
>>>>> Also, what source did you clone?
>>>>
>>>>
>>>> On linux right now, but I think it's because I'm using the jextract 
>>>> branch of panama-foreign:
>>>>
>>>>
>>>> https://github.com/openjdk/panama-foreign
>>>>
>>> This was a very crucial piece of information that you left out 
>>> initially. Panama uses libclang for specific new features in that 
>>> project. I don't know the details on how to build that project. You 
>>> will need to ask people working on Panama for details on any special 
>>> needs they have.
>>>
>>> I would recommend you clone the mainline jdk and get that to work 
>>> first as a baseline.
>>
>>
>> Just did, as well as a version of panama-foreign that should work but 
>> doesn't need clang(foreign-abi).
>>
>>
>> It configures now, but fails to build with errors like:
>>
>>
>> c1xx: fatal error C1083: Cannot open source file: 
>> '../../../..c:/cygwin64/home/young/jdk-master/jdk-master/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM_pch.cpp': 
>> No such file or directory
>>
>>
> Could you send your configure.log, spec.gmk and the exact command 
> lines you used?
>
> /Erik


Attached.


>
>> Basically every file within the objs file is missing... but it isn't 
>> actually. I can see them in Windows explorer just fine and configure 
>> doesn't throw any errors.
>>
>>
>> Thinking that this was an issue with file depth, I moved the cloned 
>> source code to root as "jdk-build". It still fails in the same spot. 
>> Both of them.
>>
>>
>>>
>>> /Erik
>>>
>>>>
>>>> I remember there being a commit some time ago that requires clang 
>>>> to be specified on panama-dev, but I've never had to do that under 
>>>> Linux. This is my first time compiling on Windows so I have no idea 
>>>> what's going on.
>>>>
>>>>
>>>>>
>>>>> /Erik
>>>>>
>>>>> On 2020-07-09 07:04, Ty Young wrote:
>>>>>>
>>>>>> On 7/9/20 7:37 AM, Erik Joelsson wrote:
>>>>>>> Hello Ty,
>>>>>>>
>>>>>>> Microsoft Visual Studio 2019 or 2017, any edition, should work. 
>>>>>>> My best guess is that you skipped installing the necessary parts 
>>>>>>> of it. Run the installer again, click "Modify" and make sure you 
>>>>>>> have "Desktop development with C++" ticked in.
>>>>>>
>>>>>>
>>>>>> That worked, thanks!
>>>>>>
>>>>>>
>>>>>> It still didn't configure though. Now it's complaining about not 
>>>>>> having clang installed. Once I installed clang and clang-devel, 
>>>>>> it then complained about not having version 9 installed. The 
>>>>>> latest version from cygdrive was 8<something>, 9 is not an 
>>>>>> option. If I try to trick it by copying and renaming the older 
>>>>>> 8<something> version, it then complains about Index.h being found 
>>>>>> but not being compileable and to report it here.
>>>>>>
>>>>>>
>>>>>> Any advice here? I tried installing more extra stuff from Visual 
>>>>>> Code Studio to see if it'd help, but it doesn't or I'm not 
>>>>>> installing the right things.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> /ERik
>>>>>>>
>>>>>>> On 2020-07-09 01:29, Ty Young wrote:
>>>>>>>> Hopefully this is the right place. Don't shoot me if it isn't, 
>>>>>>>> please.
>>>>>>>>
>>>>>>>>
>>>>>>>> I'm trying to build the JDK from Windows 10. I got so far as to 
>>>>>>>> configure failing on finding what it needs from the Visual Code 
>>>>>>>> Studio install via command line:
>>>>>>>>
>>>>>>>>
>>>>>>>> configure: Found Visual Studio installation at 
>>>>>>>> /cygdrive/c/Program Files (x86)/Microsoft Visual 
>>>>>>>> Studio/2019/Community using well-known name
>>>>>>>> configure: Warning: None of vc/bin/amd64/vcvars64.bat 
>>>>>>>> vc/bin/x86_amd64/vcvarsx86_amd64.bat 
>>>>>>>> VC/Auxiliary/Build/vcvarsx86_amd64.bat 
>>>>>>>> VC/Auxiliary/Build/vcvars64.bat were found, Visual Studio 
>>>>>>>> installation not recognized. Ignoring
>>>>>>>> configure: Found Visual Studio installation at 
>>>>>>>> /cygdrive/c/Program Files (x86)/Microsoft Visual 
>>>>>>>> Studio/2019/Community using well-known name
>>>>>>>> configure: Warning: None of vc/bin/amd64/vcvars64.bat 
>>>>>>>> vc/bin/x86_amd64/vcvarsx86_amd64.bat 
>>>>>>>> VC/Auxiliary/Build/vcvarsx86_amd64.bat 
>>>>>>>> VC/Auxiliary/Build/vcvars64.bat were found, Visual Studio 
>>>>>>>> installation not recognized. Ignoring
>>>>>>>> configure: Cannot locate a valid Visual Studio installation, 
>>>>>>>> checking current environment
>>>>>>>> checking for Visual Studio variables... not found
>>>>>>>> configure: Cannot locate a valid Visual Studio or Windows SDK 
>>>>>>>> installation on disk,
>>>>>>>> configure: nor is this script run from a Visual Studio command 
>>>>>>>> prompt.
>>>>>>>> configure: Try setting --with-tools-dir to the VC/bin directory 
>>>>>>>> within the VS installation
>>>>>>>>
>>>>>>>>
>>>>>>>> However there is no "bin" directory in this installation, at 
>>>>>>>> least not one that contains any of the specified files. This is 
>>>>>>>> Visual Code 2019 Community, but I've tried the Professional 
>>>>>>>> version too. The building document doesn't specify which 
>>>>>>>> version, nor does it tell me how to fix this.
>>>>>>>>
>>>>>>>>
>>>>>>>> How do I get this to work via command line?
>>>>>>>>
-------------- next part --------------
#
# Copyright (c) 2011, 2020, Oracle and/or its affiliates. All rights reserved.
# DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
#
# This code is free software; you can redistribute it and/or modify it
# under the terms of the GNU General Public License version 2 only, as
# published by the Free Software Foundation.  Oracle designates this
# particular file as subject to the "Classpath" exception as provided
# by Oracle in the LICENSE file that accompanied this code.
#
# This code is distributed in the hope that it will be useful, but WITHOUT
# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
# FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
# version 2 for more details (a copy is included in the LICENSE file that
# accompanied this code).
#
# You should have received a copy of the GNU General Public License version
# 2 along with this work; if not, write to the Free Software Foundation,
# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
#
# Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
# or visit www.oracle.com if you need additional information or have any
# questions.
#

# Configured Sat Jul 11 23:52:36 PDT 2020 to build
# for target system windows-x86_64
#   (called x86_64-unknown-cygwin by autoconf)
# on build system windows-x86_64
#   (called x86_64-unknown-cygwin by autoconf)
# using 'configure --disable-warnings-as-errors'

# The command line given to configure.
CONFIGURE_COMMAND_LINE:=--disable-warnings-as-errors
# The current directory when configure was run
CONFIGURE_START_DIR:=/cygdrive/c/cygwin64/jdk

# A self-referential reference to this file.
SPEC:=/cygdrive/c/cygwin64/jdk/build/windows-x86_64-server-release/spec.gmk

# Path to autoconf if overriden by the user, to be used by "make reconfigure"
AUTOCONF := /usr/bin/autoconf

# SPACE and COMMA are defined in MakeBase.gmk, but they are also used in
# some definitions here, and are needed if MakeBase.gmk is not included before
# this file.
X:=
SPACE:=$(X) $(X)
COMMA:=,

# What make to use for main processing, after bootstrapping top-level Makefile.
MAKE := /usr/bin/make

# Make sure all shell commands are executed with the C locale
export LC_ALL := C

# The default make arguments
MAKE_ARGS = $(MAKE_LOG_FLAGS) -r -R -I $(TOPDIR)/make/common SPEC=$(SPEC) \
    MAKE_LOG_FLAGS="$(MAKE_LOG_FLAGS)" $(MAKE_LOG_VARS)

OUTPUT_SYNC_SUPPORTED:=true
OUTPUT_SYNC:=none

# Override the shell with bash
BASH:=/usr/bin/bash
BASH_ARGS:= -o pipefail -e
SHELL:=$(BASH) $(BASH_ARGS)

# The "human readable" name of this configuration
CONF_NAME:=windows-x86_64-server-release

# The built jdk will run in this target system.
OPENJDK_TARGET_OS:=windows
OPENJDK_TARGET_OS_TYPE:=windows
OPENJDK_TARGET_OS_ENV:=windows.cygwin
OPENJDK_TARGET_OS_UPPERCASE:=WINDOWS

OPENJDK_TARGET_CPU:=x86_64
OPENJDK_TARGET_CPU_ARCH:=x86
OPENJDK_TARGET_CPU_BITS:=64
OPENJDK_TARGET_CPU_ENDIAN:=little

COMPILE_TYPE:=native

# Legacy support
OPENJDK_TARGET_CPU_LEGACY:=amd64
OPENJDK_TARGET_CPU_LEGACY_LIB:=amd64
OPENJDK_TARGET_CPU_OSARCH:=amd64
OPENJDK_TARGET_OS_INCLUDE_SUBDIR:=win32

HOTSPOT_TARGET_OS := windows
HOTSPOT_TARGET_OS_TYPE := windows

HOTSPOT_TARGET_CPU := x86_64
HOTSPOT_TARGET_CPU_ARCH := x86
HOTSPOT_TARGET_CPU_DEFINE := AMD64

OPENJDK_TARGET_BUNDLE_PLATFORM:=windows-x64
JDK_ARCH_ABI_PROP_NAME := 

# We are building on this build system.
# When not cross-compiling, it is the same as the target.
OPENJDK_BUILD_OS:=windows
OPENJDK_BUILD_OS_TYPE:=windows
OPENJDK_BUILD_OS_ENV:=windows.cygwin

OPENJDK_BUILD_CPU:=x86_64
OPENJDK_BUILD_CPU_ARCH:=x86
OPENJDK_BUILD_CPU_BITS:=64
OPENJDK_BUILD_CPU_ENDIAN:=little

OPENJDK_BUILD_OS_INCLUDE_SUBDIR:=win32

# Target platform value in ModuleTarget class file attribute.
OPENJDK_MODULE_TARGET_PLATFORM:=windows-amd64

# OS_* properties in release file
RELEASE_FILE_OS_NAME:=Windows
RELEASE_FILE_OS_ARCH:=x86_64

SOURCE_DATE := updated
ENABLE_REPRODUCIBLE_BUILD := false

LIBM:=
LIBDL:=

# colon or semicolon
PATH_SEP:=;

# Save the original path before replacing it with the Visual Studio tools
ORIGINAL_PATH:=/usr/local/bin:/usr/bin:/cygdrive/c/Program Files/AdoptOpenJDK/jdk-14.0.1.7-hotspot/bin:/cygdrive/c/windows/system32:/cygdrive/c/windows:/cygdrive/c/windows/system32/wbem:/cygdrive/c/windows/system32/windowspowershell/v1.0:/cygdrive/c/windows/system32/openssh:/cygdrive/c/programdata/chocolatey/bin:/cygdrive/c/program files (x86)/nvidia corporation/physx/common:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/system32/wbem:/cygdrive/c/WINDOWS/system32/windowspowershell/v1.0:/cygdrive/c/WINDOWS/system32/openssh:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0:/cygdrive/c/WINDOWS/System32/OpenSSH:/cygdrive/c/Program Files/NVIDIA Corporation/NVIDIA NvDLISR:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0:/cygdrive/c/WINDOWS/System32/OpenSSH:/cygdrive/c/Program Files/LLVM/bin:/cygdrive/c/Users/young/AppData/Local/Microsoft/WindowsApps
ifeq ($(OPENJDK_TARGET_OS), windows)
  # On Windows, the Visual Studio toolchain needs the PATH to be adjusted
  # to include Visual Studio tools (this needs to be in cygwin/msys style).
  ifeq ($(OPENJDK_TARGET_OS_ENV), windows.wsl)
    export FIXPATH_PATH:=
    export WSLENV:=$(WSLENV):FIXPATH_PATH:DEBUG_FIXPATH
  else
    export PATH:=/cygdrive/c/PROGRA~2/MICROS~1/2019/COMMUN~1/Common7/IDE/Extensions/Microsoft/IntelliCode/CLI:/cygdrive/c/PROGRA~2/MICROS~1/2019/COMMUN~1/VC/Tools/MSVC/14.26.28801/bin/HostX86/x64:/cygdrive/c/PROGRA~2/MICROS~1/2019/COMMUN~1/VC/Tools/MSVC/14.26.28801/bin/HostX86/x86:/cygdrive/c/PROGRA~2/MICROS~1/2019/COMMUN~1/Common7/IDE/VC/VCPackages:/cygdrive/c/PROGRA~2/MICROS~1/2019/COMMUN~1/Common7/IDE/CommonExtensions/Microsoft/TestWindow:/cygdrive/c/PROGRA~2/MICROS~1/2019/COMMUN~1/Common7/IDE/CommonExtensions/Microsoft/TeamFoundation/Team Explorer:/cygdrive/c/PROGRA~2/MICROS~1/2019/COMMUN~1/MSBuild/Current/bin/Roslyn:/cygdrive/c/PROGRA~2/MICROS~1/2019/COMMUN~1/Team Tools/Performance Tools/x64:/cygdrive/c/PROGRA~2/MICROS~1/2019/COMMUN~1/Team Tools/Performance Tools:/cygdrive/c/Program Files (x86)/Microsoft Visual Studio/Shared/Common/VSPerfCollectionTools/vs2019/x64:/cygdrive/c/Program Files (x86)/Microsoft Visual Studio/Shared/Common/VSPerfCollectionTools/vs2019:/cygdrive/c/Program Files (x86)/Microsoft SDKs/Windows/v10.0A/bin/NETFX 4.8 Tools:/cygdrive/c/Program Files (x86)/HTML Help Workshop:/cygdrive/c/Program Files (x86)/Windows Kits/10/bin/10.0.18362.0/x86:/cygdrive/c/Program Files (x86)/Windows Kits/10/bin/x86:/cygdrive/c/PROGRA~2/MICROS~1/2019/COMMUN~1/MSBuild/Current/Bin:/cygdrive/c/Windows/Microsoft.NET/Framework/v4.0.30319:/cygdrive/c/PROGRA~2/MICROS~1/2019/COMMUN~1/Common7/IDE:/cygdrive/c/PROGRA~2/MICROS~1/2019/COMMUN~1/Common7/Tools:/usr/local/bin:/usr/bin:/cygdrive/c/Program Files/AdoptOpenJDK/jdk-14.0.1.7-hotspot/bin:/cygdrive/c/windows/system32:/cygdrive/c/windows:/cygdrive/c/windows/system32/wbem:/cygdrive/c/windows/system32/windowspowershell/v1.0:/cygdrive/c/windows/system32/openssh:/cygdrive/c/programdata/chocolatey/bin:/cygdrive/c/program files (x86)/nvidia corporation/physx/common:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/system32/wbem:/cygdrive/c/WINDOWS/system32/windowspowershell/v1.0:/cygdrive/c/WINDOWS/system32/openssh:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0:/cygdrive/c/WINDOWS/System32/OpenSSH:/cygdrive/c/Program Files/NVIDIA Corporation/NVIDIA NvDLISR:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0:/cygdrive/c/WINDOWS/System32/OpenSSH:/cygdrive/c/Program Files/LLVM/bin:/cygdrive/c/Users/young/AppData/Local/Microsoft/WindowsApps:/cygdrive/c/PROGRA~2/MICROS~1/2019/COMMUN~1/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/bin:/cygdrive/c/PROGRA~2/MICROS~1/2019/COMMUN~1/Common7/IDE/CommonExtensions/Microsoft/CMake/Ninja
  endif
endif

SYSROOT_CFLAGS :=  -I/cygdrive/c/progra~2/micros~1/2019/commun~1/vc/tools/msvc/1426~1.288/atlmfc/include -I/cygdrive/c/progra~2/micros~1/2019/commun~1/vc/tools/msvc/1426~1.288/include -I/cygdrive/c/progra~2/wi3cf2~1/netfxsdk/4.8/include/um -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100183~1.0/ucrt -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100183~1.0/shared -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100183~1.0/um -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100183~1.0/winrt -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100183~1.0/cppwinrt
SYSROOT_LDFLAGS :=  -libpath:/cygdrive/c/progra~2/micros~1/2019/commun~1/vc/tools/msvc/1426~1.288/atlmfc/lib/x64 -libpath:/cygdrive/c/progra~2/micros~1/2019/commun~1/vc/tools/msvc/1426~1.288/lib/x64 -libpath:/cygdrive/c/progra~2/wi3cf2~1/netfxsdk/4.8/lib/um/x64 -libpath:/cygdrive/c/progra~2/wi3cf2~1/10/lib/100183~1.0/ucrt/x64 -libpath:/cygdrive/c/progra~2/wi3cf2~1/10/lib/100183~1.0/um/x64

# The top-level directory of the source repository
TOPDIR:=/cygdrive/c/cygwin64/jdk
# Usually the top level directory, but could be something else if a custom
# root is defined.
WORKSPACE_ROOT:=/jdk
IMPORT_MODULES_CLASSES:=
IMPORT_MODULES_CMDS:=
IMPORT_MODULES_LIBS:=
IMPORT_MODULES_CONF:=
IMPORT_MODULES_LEGAL:=
IMPORT_MODULES_MAN:=
IMPORT_MODULES_SRC:=
IMPORT_MODULES_MAKE:=

COPYRIGHT_YEAR:=2020
HOTSPOT_BUILD_TIME:=

# Platform naming variables
LAUNCHER_NAME:=openjdk
PRODUCT_NAME:=OpenJDK
PRODUCT_SUFFIX:=Runtime Environment
JDK_RC_PLATFORM_NAME:=Platform
JDK_RC_NAME:=OpenJDK Platform
COMPANY_NAME:=N/A
HOTSPOT_VM_DISTRO:=OpenJDK
MACOSX_BUNDLE_NAME_BASE=OpenJDK
MACOSX_BUNDLE_ID_BASE=net.java.openjdk
USERNAME:=young
VENDOR_URL:=https://openjdk.java.net/
VENDOR_URL_BUG:=https://bugreport.java.com/bugreport/
VENDOR_URL_VM_BUG:=https://bugreport.java.com/bugreport/crash.jsp

# New (JEP-223) version information

## Building blocks of the version string
# First three version numbers, with well-specified meanings (numerical)
VERSION_FEATURE := 16
VERSION_INTERIM := 0
VERSION_UPDATE := 0
VERSION_PATCH := 0
VERSION_EXTRA1 := 0
VERSION_EXTRA2 := 0
VERSION_EXTRA3 := 0
# The pre-release identifier (string)
VERSION_PRE := internal
# The build number (numerical)
VERSION_BUILD := 0
# Optional build information (string)
VERSION_OPT := adhoc.young.jdk

## Composite variables
# The version number as a dot separated sequence of numbers, e.g. 9.0.1
VERSION_NUMBER := 16
# VERSION_NUMBER but always with exactly 4 positions, with 0 for empty positions.
VERSION_NUMBER_FOUR_POSITIONS := 16.0.0.0
# The complete version string, with additional build information
VERSION_STRING := 16-internal+0-adhoc.young.jdk
# The short version string, without trailing zeroes and just PRE, if present.
VERSION_SHORT := 16-internal
# The Java specification version. It usually equals the feature version number.
VERSION_SPECIFICATION := 16
# A GA version is defined by the PRE string being empty. Rather than testing for
# that, this variable defines it with true/false.
VERSION_IS_GA := false

# Version date
VERSION_DATE := 2021-03-16

# Vendor version string
VENDOR_VERSION_STRING := 

# Class-file version
VERSION_CLASSFILE_MAJOR := 60
VERSION_CLASSFILE_MINOR := 0

JDK_SOURCE_TARGET_VERSION := 16

# Convenience CFLAGS settings for passing version information into native programs.
VERSION_CFLAGS := \
    -DVERSION_FEATURE=$(VERSION_FEATURE) \
    -DVERSION_INTERIM=$(VERSION_INTERIM) \
    -DVERSION_UPDATE=$(VERSION_UPDATE) \
    -DVERSION_PATCH=$(VERSION_PATCH) \
    -DVERSION_EXTRA1=$(VERSION_EXTRA1) \
    -DVERSION_EXTRA2=$(VERSION_EXTRA2) \
    -DVERSION_EXTRA3=$(VERSION_EXTRA3) \
    -DVERSION_PRE='"$(VERSION_PRE)"' \
    -DVERSION_BUILD=$(VERSION_BUILD) \
    -DVERSION_OPT='"$(VERSION_OPT)"' \
    -DVERSION_NUMBER='"$(VERSION_NUMBER)"' \
    -DVERSION_STRING='"$(VERSION_STRING)"' \
    -DVERSION_SHORT='"$(VERSION_SHORT)"' \
    -DVERSION_SPECIFICATION='"$(VERSION_SPECIFICATION)"' \
    -DVERSION_DATE='"$(VERSION_DATE)"' \
    -DVENDOR_VERSION_STRING='"$(VENDOR_VERSION_STRING)"' \
    -DVERSION_CLASSFILE_MAJOR=$(VERSION_CLASSFILE_MAJOR) \
    -DVERSION_CLASSFILE_MINOR=$(VERSION_CLASSFILE_MINOR) \
    #

ifneq ($(COMPANY_NAME),)
  # COMPANY_NAME is set to "N/A" in $AUTOCONF_DIR/version-numbers by default,
  # but can be customized with the '--with-vendor-name' configure option.
  # Only export "VENDOR" to the build if COMPANY_NAME contains a real value.
  # Otherwise the default value for VENDOR, which is used to set the "java.vendor"
  # and "java.vm.vendor" properties is hard-coded into the source code (i.e. in
  # VersionProps.java.template in the jdk for "java.vendor" and
  # vm_version.cpp in the VM for "java.vm.vendor")
  ifneq ($(COMPANY_NAME), N/A)
    VERSION_CFLAGS += -DVENDOR='"$(COMPANY_NAME)"'
  endif
endif

# Only export VENDOR_URL, VENDOR_URL_BUG and VENDOR_VM_URL_BUG to the build if
# they are not empty. Otherwise, default values which are defined in the sources
# will be used.
ifneq ($(VENDOR_URL),)
  VERSION_CFLAGS += -DVENDOR_URL='"$(VENDOR_URL)"'
endif
ifneq ($(VENDOR_URL_BUG),)
  VERSION_CFLAGS += -DVENDOR_URL_BUG='"$(VENDOR_URL_BUG)"'
endif
ifneq ($(VENDOR_URL_VM_BUG),)
  VERSION_CFLAGS += -DVENDOR_URL_VM_BUG='"$(VENDOR_URL_VM_BUG)"'
endif

# Different naming strings generated from the above information.
RUNTIME_NAME=$(PRODUCT_NAME) $(PRODUCT_SUFFIX)

# How to compile the code: release, fastdebug or slowdebug
DEBUG_LEVEL:=release
HOTSPOT_DEBUG_LEVEL:=product

# Which JVM variants to build (space-separated list)
JVM_VARIANTS := server
JVM_VARIANT_MAIN := server

# Lists of features per variant. Only relevant for the variants listed in
# JVM_VARIANTS.
JVM_FEATURES_server := aot cds compiler1 compiler2 epsilongc g1gc graal jfr jni-check jvmci jvmti management nmt parallelgc serialgc services shenandoahgc vm-structs zgc
JVM_FEATURES_client := 
JVM_FEATURES_core := 
JVM_FEATURES_minimal := 
JVM_FEATURES_zero := 
JVM_FEATURES_custom := 

# Used for make-time verifications
VALID_JVM_FEATURES := aot cds compiler1 compiler2 dtrace epsilongc g1gc graal jfr jni-check jvmci jvmti link-time-opt management minimal nmt opt-size parallelgc serialgc services shenandoahgc static-build vm-structs zero zgc
VALID_JVM_VARIANTS := server client minimal core zero custom

# Allow overriding the default hotspot library path
HOTSPOT_OVERRIDE_LIBPATH := 

# Control use of precompiled header in hotspot libjvm build
USE_PRECOMPILED_HEADER := true

# Only build headless support or not
ENABLE_HEADLESS_ONLY := false

ENABLE_LINKTIME_GC := false

# Ship debug symbols (e.g. pdbs on Windows)
SHIP_DEBUG_SYMBOLS := 

ENABLE_FULL_DOCS := false

# JDK_OUTPUTDIR specifies where a working jvm is built.
# You can run $(JDK_OUTPUTDIR)/bin/java

OUTPUTDIR := /cygdrive/c/cygwin64/jdk/build/windows-x86_64-server-release
# Colon left out to be able to override IMAGES_OUTPUTDIR for bootcycle-images
SUPPORT_OUTPUTDIR=$(OUTPUTDIR)/support
BUILDTOOLS_OUTPUTDIR=$(OUTPUTDIR)/buildtools

HOTSPOT_OUTPUTDIR=$(OUTPUTDIR)/hotspot
JDK_OUTPUTDIR=$(OUTPUTDIR)/jdk
IMAGES_OUTPUTDIR=$(OUTPUTDIR)/images
BUNDLES_OUTPUTDIR=$(OUTPUTDIR)/bundles
TESTMAKE_OUTPUTDIR=$(OUTPUTDIR)/test-make
MAKESUPPORT_OUTPUTDIR=$(OUTPUTDIR)/make-support

# This does not get overridden in a bootcycle build
CONFIGURESUPPORT_OUTPUTDIR:=/cygdrive/c/cygwin64/jdk/build/windows-x86_64-server-release/configure-support
BUILDJDK_OUTPUTDIR=$(OUTPUTDIR)/buildjdk

BUILD_FAILURE_HANDLER := false

ENABLE_GENERATE_CLASSLIST := true

EXCLUDE_TRANSLATIONS := 

BUILD_MANPAGES := true

BUILD_CDS_ARCHIVE := true

ALLOW_ABSOLUTE_PATHS_IN_OUTPUT := false

# The boot jdk to use. This is overridden in bootcycle-spec.gmk. Make sure to keep
# it in sync.
BOOT_JDK:=/cygdrive/c/progra~1/adopto~1/jdk-14~1.7-h

BUILD_JDK:=$(JDK_OUTPUTDIR)
CREATE_BUILDJDK:=false
EXTERNAL_BUILDJDK:=false

# When compiling Java source to be run by the boot jdk
# use these extra flags, eg -source 6 -target 6
BOOT_JDK_SOURCETARGET:=-source 14 -target 14 -Xlint:-options

# Information about the build system
NUM_CORES:=16
MEMORY_SIZE:=32699
ENABLE_JAVAC_SERVER:=true
# Store javac server synchronization files here, and
# the javac server log files.
JAVAC_SERVER_DIR=$(MAKESUPPORT_OUTPUTDIR)/javacservers

# Number of parallel jobs to use for compilation
JOBS?=16
TEST_JOBS?=0

# Default make target
DEFAULT_MAKE_TARGET:=exploded-image
DEFAULT_LOG:=

FREETYPE_TO_USE:=bundled
FREETYPE_LIBS:=
FREETYPE_CFLAGS:=
FONTCONFIG_CFLAGS:=
CUPS_CFLAGS:=
ALSA_LIBS:=
ALSA_CFLAGS:=
LIBFFI_LIBS:=
LIBFFI_CFLAGS:=
ENABLE_LIBFFI_BUNDLING:=false
LIBFFI_LIB_FILE:=
GRAALUNIT_LIB := 
FILE_MACRO_CFLAGS := 

STATIC_LIBS_CFLAGS := -DSTATIC_BUILD=1 -DJNIEXPORT=

JMH_CORE_JAR := 
JMH_GENERATOR_JAR := 
JMH_JOPT_SIMPLE_JAR := 
JMH_COMMONS_MATH_JAR := 
JMH_VERSION := 

GTEST_FRAMEWORK_SRC := 

# Source file for cacerts
CACERTS_FILE=

# Enable unlimited crypto policy
UNLIMITED_CRYPTO=true

GCOV_ENABLED=false
JCOV_ENABLED=false
JCOV_HOME=
JCOV_INPUT_JDK=
JCOV_FILTERS=

# AddressSanitizer
export ASAN_ENABLED:=no
export DEVKIT_LIB_DIR:=
ifeq ($(ASAN_ENABLED), yes)
  export ASAN_OPTIONS=handle_segv=0 detect_leaks=0
  ifneq ($(DEVKIT_LIB_DIR),)
    export LD_LIBRARY_PATH:=$(LD_LIBRARY_PATH):$(DEVKIT_LIB_DIR)
  endif
endif

# Necessary additional compiler flags to compile X11
X_CFLAGS:=
X_LIBS:=

# The lowest required version of macosx
MACOSX_VERSION_MIN=
# The highest allowed version of macosx
MACOSX_VERSION_MAX=

# The macosx code signing identity to use
MACOSX_CODESIGN_IDENTITY=

# Toolchain type: gcc, clang, xlc, microsoft...
TOOLCHAIN_TYPE:=microsoft
TOOLCHAIN_VERSION := 2019
CC_VERSION_NUMBER := 19.26.28806
CXX_VERSION_NUMBER := 19.26.28806

# Legacy support
HOTSPOT_TOOLCHAIN_TYPE := visCPP

# Option used to tell the compiler whether to create 32- or 64-bit executables
COMPILER_TARGET_BITS_FLAG:=-m
COMPILER_SUPPORTS_TARGET_BITS_FLAG=true

# Option used to pass a command file to the compiler
COMPILER_COMMAND_FILE_FLAG:=@

# Option for specifying a file which saves the binder commands
# produced by the link step (for debugging, currently AIX only)
COMPILER_BINDCMD_FILE_FLAG:=

CC_OUT_OPTION:=-Fo
LD_OUT_OPTION:=-out:
AR_OUT_OPTION:=-out:

# Flags used for overriding the default opt setting for a C/C++ source file.
C_O_FLAG_HIGHEST_JVM:=-O2 -Oy-
C_O_FLAG_HIGHEST:=-O2
C_O_FLAG_HI:=-O1
C_O_FLAG_NORM:=-O1
C_O_FLAG_NONE:=-Od
C_O_FLAG_SIZE:=-Os
CXX_O_FLAG_HIGHEST_JVM:=-O2 -Oy-
CXX_O_FLAG_HIGHEST:=-O2
CXX_O_FLAG_HI:=-O1
CXX_O_FLAG_NORM:=-O1
CXX_O_FLAG_NONE:=-Od
CXX_O_FLAG_SIZE:=-Os

C_FLAG_DEPS:=
CXX_FLAG_DEPS:=

DISABLE_WARNING_PREFIX := -wd
CFLAGS_WARNINGS_ARE_ERRORS:=-WX
DISABLED_WARNINGS := 4800
DISABLED_WARNINGS_C := 
DISABLED_WARNINGS_CXX := 

# A global flag (true or false) determining if native warnings are considered errors.
WARNINGS_AS_ERRORS := false

CFLAGS_CCACHE:=
ADLC_CXXFLAG=

# Tools that potentially need to be cross compilation aware.
CC:=/cygdrive/c/cygwin64/jdk/build/windows-x86_64-server-release/configure-support/bin/fixpath.exe -c   /cygdrive/c/progra~2/micros~1/2019/commun~1/vc/tools/msvc/1426~1.288/bin/hostx86/x64/cl

# CFLAGS used to compile the jdk native libraries (C-code)
CFLAGS_JDKLIB:=       -I$(SUPPORT_OUTPUTDIR)/modules_include/java.base       -I$(SUPPORT_OUTPUTDIR)/modules_include/java.base/$(OPENJDK_TARGET_OS_INCLUDE_SUBDIR)       -I/cygdrive/c/cygwin64/jdk/src/java.base/share/native/libjava       -I/cygdrive/c/cygwin64/jdk/src/java.base/windows/native/libjava       -I/cygdrive/c/cygwin64/jdk/src/hotspot/share/include       -I/cygdrive/c/cygwin64/jdk/src/hotspot/os/windows/include -DWIN32_LEAN_AND_MEAN -D_CRT_SECURE_NO_DEPRECATE         -D_CRT_NONSTDC_NO_DEPRECATE -DWIN32 -DIAL -nologo -MD -Zc:wchar_t-         -DWINDOWS -DNDEBUG        -W3                      -D_LITTLE_ENDIAN -DARCH='"amd64"'       -Damd64 -D_AMD64_ -Damd64           
CXXFLAGS_JDKLIB:=       -I$(SUPPORT_OUTPUTDIR)/modules_include/java.base       -I$(SUPPORT_OUTPUTDIR)/modules_include/java.base/$(OPENJDK_TARGET_OS_INCLUDE_SUBDIR)       -I/cygdrive/c/cygwin64/jdk/src/java.base/share/native/libjava       -I/cygdrive/c/cygwin64/jdk/src/java.base/windows/native/libjava       -I/cygdrive/c/cygwin64/jdk/src/hotspot/share/include       -I/cygdrive/c/cygwin64/jdk/src/hotspot/os/windows/include -DWIN32_LEAN_AND_MEAN -D_CRT_SECURE_NO_DEPRECATE         -D_CRT_NONSTDC_NO_DEPRECATE -DWIN32 -DIAL -nologo -MD -Zc:wchar_t-         -DWINDOWS -DNDEBUG        -W3                                  -D_LITTLE_ENDIAN -DARCH='"amd64"'       -Damd64 -D_AMD64_ -Damd64           

# CFLAGS used to compile the jdk native launchers (C-code)
CFLAGS_JDKEXE:=       -I$(SUPPORT_OUTPUTDIR)/modules_include/java.base       -I$(SUPPORT_OUTPUTDIR)/modules_include/java.base/$(OPENJDK_TARGET_OS_INCLUDE_SUBDIR)       -I/cygdrive/c/cygwin64/jdk/src/java.base/share/native/libjava       -I/cygdrive/c/cygwin64/jdk/src/java.base/windows/native/libjava       -I/cygdrive/c/cygwin64/jdk/src/hotspot/share/include       -I/cygdrive/c/cygwin64/jdk/src/hotspot/os/windows/include -DWIN32_LEAN_AND_MEAN -D_CRT_SECURE_NO_DEPRECATE         -D_CRT_NONSTDC_NO_DEPRECATE -DWIN32 -DIAL -nologo -MD -Zc:wchar_t-         -DWINDOWS -DNDEBUG        -W3                      -D_LITTLE_ENDIAN -DARCH='"amd64"'       -Damd64 -D_AMD64_ -Damd64    
CXXFLAGS_JDKEXE:=       -I$(SUPPORT_OUTPUTDIR)/modules_include/java.base       -I$(SUPPORT_OUTPUTDIR)/modules_include/java.base/$(OPENJDK_TARGET_OS_INCLUDE_SUBDIR)       -I/cygdrive/c/cygwin64/jdk/src/java.base/share/native/libjava       -I/cygdrive/c/cygwin64/jdk/src/java.base/windows/native/libjava       -I/cygdrive/c/cygwin64/jdk/src/hotspot/share/include       -I/cygdrive/c/cygwin64/jdk/src/hotspot/os/windows/include -DWIN32_LEAN_AND_MEAN -D_CRT_SECURE_NO_DEPRECATE         -D_CRT_NONSTDC_NO_DEPRECATE -DWIN32 -DIAL -nologo -MD -Zc:wchar_t-         -DWINDOWS -DNDEBUG        -W3                                  -D_LITTLE_ENDIAN -DARCH='"amd64"'       -Damd64 -D_AMD64_ -Damd64    

FDLIBM_CFLAGS := 
JVM_CFLAGS := -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN       -nologo -MD -MP          -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_        -W3    -DVM_LITTLE_ENDIAN -D_LP64=1      
JVM_LDFLAGS := -nologo -opt:ref -pdbaltpath:%_PDB% -opt:icf,8 -subsystem:windows                  -machine:AMD64  
JVM_ASFLAGS :=   
JVM_LIBS :=  kernel32.lib user32.lib gdi32.lib winspool.lib         comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib         wsock32.lib winmm.lib version.lib psapi.lib

# These flags might contain variables set by a custom extension that is included later.
EXTRA_CFLAGS =  
EXTRA_CXXFLAGS =  
EXTRA_LDFLAGS =  
EXTRA_ASFLAGS = 

CXX:=/cygdrive/c/cygwin64/jdk/build/windows-x86_64-server-release/configure-support/bin/fixpath.exe -c   /cygdrive/c/progra~2/micros~1/2019/commun~1/vc/tools/msvc/1426~1.288/bin/hostx86/x64/cl

CPP:=/cygdrive/c/cygwin64/jdk/build/windows-x86_64-server-release/configure-support/bin/fixpath.exe -c /cygdrive/c/progra~2/micros~1/2019/commun~1/vc/tools/msvc/1426~1.288/bin/hostx86/x64/cl -E

# The linker can be gcc or ld on unix systems, or link.exe on windows systems.
LD:=/cygdrive/c/cygwin64/jdk/build/windows-x86_64-server-release/configure-support/bin/fixpath.exe -c /cygdrive/c/progra~2/micros~1/2019/commun~1/vc/tools/msvc/1426~1.288/bin/hostx86/x64/link

# Linker used by the jaotc tool for AOT compilation.
LD_JAOTC:=/cygdrive/c/progra~2/micros~1/2019/commun~1/vc/tools/msvc/1426~1.288/bin/hostx86/x64/link.exe

# Xcode SDK path
SDKROOT:=

# LDFLAGS used to link the jdk native libraries (C-code)
LDFLAGS_JDKLIB:=-nologo -opt:ref -pdbaltpath:%_PDB% -incremental:no                  -libpath:/cygdrive/c/cygwin64/jdk/build/windows-x86_64-server-release/support/modules_libs/java.base -dll
JDKLIB_LIBS:=

# LDFLAGS used to link the jdk native launchers (C-code)
LDFLAGS_JDKEXE:=-nologo -opt:ref -pdbaltpath:%_PDB% -incremental:no                  -stack:1048576
JDKEXE_LIBS:=

# LDFLAGS specific to C++ linking.
LDFLAGS_CXX_JDK:=  

# Sometimes a different linker is needed for c++ libs
LDCXX:=/cygdrive/c/cygwin64/jdk/build/windows-x86_64-server-release/configure-support/bin/fixpath.exe -c /cygdrive/c/progra~2/micros~1/2019/commun~1/vc/tools/msvc/1426~1.288/bin/hostx86/x64/link
# The flags for linking libstdc++ linker.
LIBCXX:=

# Compiler and linker flags used when building native tests
LDFLAGS_TESTEXE:=-libpath:/cygdrive/c/cygwin64/jdk/build/windows-x86_64-server-release/support/modules_libs/java.base

# BUILD_CC/BUILD_LD is a compiler/linker that generates code that is runnable on the
# build platform.
BUILD_CC:=/cygdrive/c/cygwin64/jdk/build/windows-x86_64-server-release/configure-support/bin/fixpath.exe -c  /cygdrive/c/progra~2/micros~1/2019/commun~1/vc/tools/msvc/1426~1.288/bin/hostx86/x64/cl
BUILD_CXX:=/cygdrive/c/cygwin64/jdk/build/windows-x86_64-server-release/configure-support/bin/fixpath.exe -c  /cygdrive/c/progra~2/micros~1/2019/commun~1/vc/tools/msvc/1426~1.288/bin/hostx86/x64/cl
BUILD_LD:=/cygdrive/c/cygwin64/jdk/build/windows-x86_64-server-release/configure-support/bin/fixpath.exe -c /cygdrive/c/progra~2/micros~1/2019/commun~1/vc/tools/msvc/1426~1.288/bin/hostx86/x64/link
BUILD_LDCXX:=/cygdrive/c/cygwin64/jdk/build/windows-x86_64-server-release/configure-support/bin/fixpath.exe -c /cygdrive/c/progra~2/micros~1/2019/commun~1/vc/tools/msvc/1426~1.288/bin/hostx86/x64/link
BUILD_AS:=/cygdrive/c/cygwin64/jdk/build/windows-x86_64-server-release/configure-support/bin/fixpath.exe -c /cygdrive/c/progra~2/micros~1/2019/commun~1/vc/tools/msvc/1426~1.288/bin/hostx86/x64/cl -c
BUILD_AR:=/cygdrive/c/cygwin64/jdk/build/windows-x86_64-server-release/configure-support/bin/fixpath.exe -c /cygdrive/c/progra~2/micros~1/2019/commun~1/vc/tools/msvc/1426~1.288/bin/hostx86/x64/lib
BUILD_NM:=/cygdrive/c/cygwin64/jdk/build/windows-x86_64-server-release/configure-support/bin/fixpath.exe -c 
BUILD_OBJCOPY:=
BUILD_STRIP:=
BUILD_SYSROOT_CFLAGS:= -I/cygdrive/c/progra~2/micros~1/2019/commun~1/vc/tools/msvc/1426~1.288/atlmfc/include -I/cygdrive/c/progra~2/micros~1/2019/commun~1/vc/tools/msvc/1426~1.288/include -I/cygdrive/c/progra~2/wi3cf2~1/netfxsdk/4.8/include/um -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100183~1.0/ucrt -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100183~1.0/shared -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100183~1.0/um -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100183~1.0/winrt -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100183~1.0/cppwinrt
BUILD_SYSROOT_LDFLAGS:= -libpath:/cygdrive/c/progra~2/micros~1/2019/commun~1/vc/tools/msvc/1426~1.288/atlmfc/lib/x64 -libpath:/cygdrive/c/progra~2/micros~1/2019/commun~1/vc/tools/msvc/1426~1.288/lib/x64 -libpath:/cygdrive/c/progra~2/wi3cf2~1/netfxsdk/4.8/lib/um/x64 -libpath:/cygdrive/c/progra~2/wi3cf2~1/10/lib/100183~1.0/ucrt/x64 -libpath:/cygdrive/c/progra~2/wi3cf2~1/10/lib/100183~1.0/um/x64

AS:=/cygdrive/c/cygwin64/jdk/build/windows-x86_64-server-release/configure-support/bin/fixpath.exe -c /cygdrive/c/progra~2/micros~1/2019/commun~1/vc/tools/msvc/1426~1.288/bin/hostx86/x64/cl -c

# AR is used to create a static library (is ar in unix, lib.exe in windows)
AR:=/cygdrive/c/cygwin64/jdk/build/windows-x86_64-server-release/configure-support/bin/fixpath.exe -c /cygdrive/c/progra~2/micros~1/2019/commun~1/vc/tools/msvc/1426~1.288/bin/hostx86/x64/lib
ARFLAGS:=-nologo -NODEFAULTLIB:MSVCRT

NM:=
GNM:=
STRIP:=
OBJDUMP:=/usr/bin/objdump
CXXFILT:=

LIPO:=
INSTALL_NAME_TOOL:=

# Options to linker to specify a mapfile.
# (Note absence of := assignment, because we do not want to evaluate the macro body here)
SET_SHARED_LIBRARY_MAPFILE=-def:$1

#
# Options for generating debug symbols
COMPILE_WITH_DEBUG_SYMBOLS := true
COPY_DEBUG_SYMBOLS := true
ZIP_EXTERNAL_DEBUG_SYMBOLS := false

CFLAGS_DEBUG_SYMBOLS:=-Z7
ASFLAGS_DEBUG_SYMBOLS:=

#
# Compress (or not) jars
COMPRESS_JARS=false

# Options to linker to specify the library name.
# (Note absence of := assignment, because we do not want to evaluate the macro body here)
SET_SHARED_LIBRARY_NAME=

SHARED_LIBRARY_FLAGS=-dll

# Set origin using the linker, ie use the relative path to the dependent library to find the dependees.
# (Note absence of := assignment, because we do not want to evaluate the macro body here)
SET_SHARED_LIBRARY_ORIGIN=
SET_EXECUTABLE_ORIGIN=

# Different OS:es have different ways of naming shared libraries.
# The SHARED_LIBRARY macro takes "verify" as and argument and returns:
#    "libverify.so" or "libverify.dylib" or "verify.dll" depending on platform.
# (Note absence of := assignment, because we do not want to evaluate the macro body here)
SHARED_LIBRARY=$1.dll
STATIC_LIBRARY=$1.lib
LIBRARY_PREFIX:=
SHARED_LIBRARY_SUFFIX:=.dll
STATIC_LIBRARY_SUFFIX:=.lib
EXE_SUFFIX:=.exe
OBJ_SUFFIX:=.obj
STATIC_BUILD:=false

STRIPFLAGS:=

JAVA_FLAGS:= -Duser.language=en -Duser.country=US -Xshare:auto 
JAVA_FLAGS_BIG:= -Xms64M -Xmx1600M
JAVA_FLAGS_SMALL:= -XX:+UseSerialGC -Xms32M -Xmx512M -XX:TieredStopAtLevel=1
BUILDJDK_JAVA_FLAGS_SMALL:=-Xms32M -Xmx512M -XX:TieredStopAtLevel=1
JAVA_TOOL_FLAGS_SMALL:= -J-XX:+UseSerialGC -J-Xms32M -J-Xmx512M -J-XX:TieredStopAtLevel=1

# The *_CMD variables are defined separately to be easily overridden in bootcycle-spec.gmk
# for bootcycle-images build. Make sure to keep them in sync. Do not use the *_CMD
# versions of the variables directly.
JAVA_CMD:=/cygdrive/c/progra~1/adopto~1/jdk-14~1.7-h/bin/java.exe
JAVAC_CMD:=/cygdrive/c/progra~1/adopto~1/jdk-14~1.7-h/bin/javac.exe
JAVADOC_CMD:=/cygdrive/c/progra~1/adopto~1/jdk-14~1.7-h/bin/javadoc.exe
JAR_CMD:=/cygdrive/c/progra~1/adopto~1/jdk-14~1.7-h/bin/jar.exe
JLINK_CMD := $(JDK_OUTPUTDIR)/bin/jlink
JMOD_CMD := $(JDK_OUTPUTDIR)/bin/jmod
JARSIGNER_CMD:=/cygdrive/c/progra~1/adopto~1/jdk-14~1.7-h/bin/jarsigner.exe
# These variables are meant to be used. They are defined with = instead of := to make
# it possible to override only the *_CMD variables.
JAVA=/cygdrive/c/cygwin64/jdk/build/windows-x86_64-server-release/configure-support/bin/fixpath.exe -c $(JAVA_CMD) $(JAVA_FLAGS_BIG) $(JAVA_FLAGS)
JAVA_SMALL=/cygdrive/c/cygwin64/jdk/build/windows-x86_64-server-release/configure-support/bin/fixpath.exe -c $(JAVA_CMD) $(JAVA_FLAGS_SMALL) $(JAVA_FLAGS)
JAVA_DETACH =/cygdrive/c/cygwin64/jdk/build/windows-x86_64-server-release/configure-support/bin/fixpath.exe -c --detach $(JAVA_CMD) $(JAVA_FLAGS_BIG) $(JAVA_FLAGS)
JAVAC=/cygdrive/c/cygwin64/jdk/build/windows-x86_64-server-release/configure-support/bin/fixpath.exe -c $(JAVAC_CMD)
JAVADOC=/cygdrive/c/cygwin64/jdk/build/windows-x86_64-server-release/configure-support/bin/fixpath.exe -c $(JAVADOC_CMD)
JAR=/cygdrive/c/cygwin64/jdk/build/windows-x86_64-server-release/configure-support/bin/fixpath.exe -c $(JAR_CMD)
JLINK = /cygdrive/c/cygwin64/jdk/build/windows-x86_64-server-release/configure-support/bin/fixpath.exe -c $(JLINK_CMD)
JMOD = /cygdrive/c/cygwin64/jdk/build/windows-x86_64-server-release/configure-support/bin/fixpath.exe -c $(JMOD_CMD) $(JAVA_TOOL_FLAGS_SMALL)
JARSIGNER=/cygdrive/c/cygwin64/jdk/build/windows-x86_64-server-release/configure-support/bin/fixpath.exe -c $(JARSIGNER_CMD)

BUILD_JAVA_FLAGS := -Xms64M -Xmx1600M
BUILD_JAVA=/cygdrive/c/cygwin64/jdk/build/windows-x86_64-server-release/configure-support/bin/fixpath.exe -c $(BUILD_JDK)/bin/java $(BUILD_JAVA_FLAGS)
BUILD_JAR=/cygdrive/c/cygwin64/jdk/build/windows-x86_64-server-release/configure-support/bin/fixpath.exe -c $(BUILD_JDK)/bin/jar

# Interim langtools modules and arguments
INTERIM_LANGTOOLS_BASE_MODULES := java.compiler jdk.compiler jdk.javadoc
INTERIM_LANGTOOLS_MODULES := $(addsuffix .interim, $(INTERIM_LANGTOOLS_BASE_MODULES))
INTERIM_LANGTOOLS_ADD_EXPORTS := \
    --add-exports java.base/sun.reflect.annotation=jdk.compiler.interim \
    --add-exports java.base/jdk.internal.jmod=jdk.compiler.interim \
    --add-exports java.base/jdk.internal.misc=jdk.compiler.interim \
    --add-exports java.base/sun.invoke.util=jdk.compiler.interim \
    #
INTERIM_LANGTOOLS_MODULES_COMMA := $(strip $(subst $(SPACE),$(COMMA),$(strip \
    $(INTERIM_LANGTOOLS_MODULES))))
INTERIM_LANGTOOLS_ARGS := \
    --limit-modules java.base,jdk.zipfs,$(INTERIM_LANGTOOLS_MODULES_COMMA) \
    --add-modules $(INTERIM_LANGTOOLS_MODULES_COMMA) \
    --module-path $(BUILDTOOLS_OUTPUTDIR)/interim_langtools_modules \
    $(INTERIM_LANGTOOLS_ADD_EXPORTS) \
    #
JAVAC_MAIN_CLASS = -m jdk.compiler.interim/com.sun.tools.javac.Main
JAVADOC_MAIN_CLASS = -m jdk.javadoc.interim/jdk.javadoc.internal.tool.Main

# You run the new javac using the boot jdk with $(BOOT_JDK)/bin/java $(NEW_JAVAC) ...
# Use = assignment to be able to override in bootcycle-spec.gmk
NEW_JAVAC   = $(INTERIM_LANGTOOLS_ARGS) $(JAVAC_MAIN_CLASS)
NEW_JAVADOC = $(INTERIM_LANGTOOLS_ARGS) $(JAVADOC_MAIN_CLASS)

JLINK_KEEP_PACKAGED_MODULES:=true

RCFLAGS := -nologo -DNDEBUG

# Tools adhering to a minimal and common standard of posix compliance.
AWK:=gawk
BASENAME:=/usr/bin/basename
CAT:=/usr/bin/cat
CCACHE:=
# CD is going away, but remains to cater for legacy makefiles.
CD:=cd
CHMOD:=/usr/bin/chmod
CODESIGN:=
COMM:=/usr/bin/comm
CP:=/usr/bin/cp
CPIO:=
CUT:=/usr/bin/cut
DATE:=/usr/bin/date
DIFF:=/usr/bin/diff
DIRNAME:=/usr/bin/dirname
DSYMUTIL:=
FIND:=/usr/bin/find
FIND_DELETE:=-delete
FLOCK:=/usr/bin/flock
ECHO:=/usr/bin/echo
EGREP:=/usr/bin/grep -E
FGREP:=/usr/bin/grep -F
GREP:=/usr/bin/grep
GZIP:=/usr/bin/gzip
HEAD:=/usr/bin/head
LS:=/usr/bin/ls
LN:=/usr/bin/ln
MIG:=
MKDIR:=/usr/bin/mkdir
MV:=/usr/bin/mv
NAWK:=/usr/bin/gawk
NICE:=/usr/bin/nice
PANDOC:=/cygdrive/c/cygwin64/jdk/build/windows-x86_64-server-release/configure-support/bin/fixpath.exe -c 
PATCH:=
PRINTF:=/usr/bin/printf
READLINK:=/usr/bin/readlink
RM:=/usr/bin/rm -f
RMDIR:=/usr/bin/rmdir
SED:=/usr/bin/sed
SH:=/usr/bin/sh
SORT:=/usr/bin/sort
TAR:=/usr/bin/tar
TAIL:=/usr/bin/tail
TEE:=/usr/bin/tee
TIME:=
IS_GNU_TIME:=no
TR:=/usr/bin/tr
TOUCH:=/usr/bin/touch
UNIQ:=/usr/bin/uniq
WC:=/usr/bin/wc
XARGS:=/usr/bin/xargs
ZIPEXE:=/usr/bin/zip
UNZIP:=/usr/bin/unzip
MT:=/cygdrive/c/cygwin64/jdk/build/windows-x86_64-server-release/configure-support/bin/fixpath.exe -c /cygdrive/c/progra~2/wi3cf2~1/10/bin/100183~1.0/x86/mt
RC:=/cygdrive/c/cygwin64/jdk/build/windows-x86_64-server-release/configure-support/bin/fixpath.exe -c /cygdrive/c/progra~2/wi3cf2~1/10/bin/100183~1.0/x86/rc
DUMPBIN:=/cygdrive/c/cygwin64/jdk/build/windows-x86_64-server-release/configure-support/bin/fixpath.exe -c /cygdrive/c/progra~2/micros~1/2019/commun~1/vc/tools/msvc/1426~1.288/bin/hostx86/x64/dumpbin
CYGPATH:=/usr/bin/cygpath
WSLPATH:=
LDD:=/usr/bin/ldd
OTOOL:=
READELF:=/usr/bin/readelf
EXPR:=/usr/bin/expr
FILE:=/usr/bin/file
DOT:=
HG:=
GIT:=/usr/bin/git
OBJCOPY:=
SETFILE:=
XATTR:=
JT_HOME:=
JIB_HOME:=
XCODEBUILD=
DTRACE := 
FIXPATH:=/cygdrive/c/cygwin64/jdk/build/windows-x86_64-server-release/configure-support/bin/fixpath.exe -c
ULIMIT:=

TAR_TYPE:=gnu
TAR_INCLUDE_PARAM:=T
TAR_SUPPORTS_TRANSFORM:=true

# Build setup
ENABLE_AOT:=true
ENABLE_INTREE_EC:=true
USE_EXTERNAL_LIBJPEG:=false
USE_EXTERNAL_LIBGIF:=false
USE_EXTERNAL_LIBZ:=false
LIBZ_CFLAGS:= -I/cygdrive/c/cygwin64/jdk/src/java.base/share/native/libzip/zlib
LIBZ_LIBS:=
LIBZIP_CAN_USE_MMAP:=true
MSVCR_DLL:=/cygdrive/c/progra~2/micros~1/2019/commun~1/vc/redist/msvc/1426~1.287/x64/Microsoft.VC142.CRT/vcruntime140.dll
VCRUNTIME_1_DLL:=/cygdrive/c/progra~2/micros~1/2019/commun~1/vc/redist/msvc/1426~1.287/x64/Microsoft.VC142.CRT/vcruntime140_1.dll
MSVCP_DLL:=/cygdrive/c/progra~2/micros~1/2019/commun~1/vc/redist/msvc/1426~1.287/x64/Microsoft.VC142.CRT/msvcp140.dll
UCRT_DLL_DIR:=/cygdrive/c/progra~2/wi3cf2~1/10/Redist/10.0.18362.0/ucrt/DLLs/x64
ENABLE_PANDOC:=false
PANDOC_MARKDOWN_FLAG:=markdown

####################################################
#
# INSTALLATION
#

# Common prefix for all installed files. Defaults to /usr/local,
# but /opt/myjdk is another common version.
INSTALL_PREFIX=/usr/local

# Directories containing architecture-dependent files should be relative to exec_prefix
INSTALL_EXECPREFIX=${prefix}

# java,javac,javap etc are installed here.
INSTALL_BINDIR=${exec_prefix}/bin

# Read only architecture-independent data
INSTALL_DATADIR=${datarootdir}

# Root of above.
INSTALL_DATAROOTDIR=${prefix}/share

# Doc files, other than info and man.
INSTALL_DOCDIR=${datarootdir}/doc/${PACKAGE_TARNAME}

# Html documentation
INSTALL_HTMLDIR=${docdir}

# Installing C header files, JNI headers for example.
INSTALL_INCLUDEDIR=${prefix}/include

# Installing library files....
INSTALL_INCLUDEDIR=${exec_prefix}/lib

# Executables that other programs run.
INSTALL_LIBEXECDIR=${exec_prefix}/libexec

# Locale-dependent but architecture-independent data, such as message catalogs.
INSTALL_LOCALEDIR=${datarootdir}/locale

# Modifiable single-machine data
INSTALL_LOCALSTATEDIR=${prefix}/var

# Man pages
INSTALL_MANDIR=${datarootdir}/man

# Modifiable architecture-independent data.
INSTALL_SHAREDSTATEDIR=${prefix}/com

# Read-only single-machine data
INSTALL_SYSCONFDIR=${prefix}/etc

####################################################
#
# Libraries
#

USE_EXTERNAL_LCMS:=false
LCMS_CFLAGS:=
LCMS_LIBS:=

USE_EXTERNAL_LIBPNG:=false
PNG_LIBS:=
PNG_CFLAGS:=

####################################################
#
# Misc
#

INCLUDE_SA=true
INCLUDE_GRAAL=true
INCLUDE_JVMCI=true

OS_VERSION_MAJOR:=3
OS_VERSION_MINOR:=1
OS_VERSION_MICRO:=6(0

# Images directory definitions
JDK_IMAGE_SUBDIR:=jdk
JRE_IMAGE_SUBDIR:=jre
JCOV_IMAGE_SUBDIR := jdk-jcov

# Colon left out to be able to override output dir for bootcycle-images
JDK_IMAGE_DIR=$(IMAGES_OUTPUTDIR)/$(JDK_IMAGE_SUBDIR)
JRE_IMAGE_DIR=$(IMAGES_OUTPUTDIR)/$(JRE_IMAGE_SUBDIR)
JCOV_IMAGE_DIR = $(IMAGES_OUTPUTDIR)/$(JCOV_IMAGE_SUBDIR)

# Test image, as above
TEST_IMAGE_SUBDIR:=test
TEST_IMAGE_DIR=$(IMAGES_OUTPUTDIR)/$(TEST_IMAGE_SUBDIR)

# Symbols image
SYMBOLS_IMAGE_SUBDIR:=symbols
SYMBOLS_IMAGE_DIR=$(IMAGES_OUTPUTDIR)/$(SYMBOLS_IMAGE_SUBDIR)

# Interim image
INTERIM_JMODS_DIR := $(SUPPORT_OUTPUTDIR)/interim-jmods
INTERIM_IMAGE_DIR := $(SUPPORT_OUTPUTDIR)/interim-image

# Docs image
DOCS_IMAGE_SUBDIR := docs
DOCS_IMAGE_DIR = $(IMAGES_OUTPUTDIR)/$(DOCS_IMAGE_SUBDIR)
# Output docs directly into image
DOCS_OUTPUTDIR := $(DOCS_IMAGE_DIR)

# Static libs image
STATIC_LIBS_IMAGE_SUBDIR := static-libs
STATIC_LIBS_IMAGE_DIR := $(IMAGES_OUTPUTDIR)/$(STATIC_LIBS_IMAGE_SUBDIR)

# Graal builder image
GRAAL_BUILDER_IMAGE_SUBDIR := graal-builder-jdk
GRAAL_BUILDER_IMAGE_DIR := $(IMAGES_OUTPUTDIR)/$(GRAAL_BUILDER_IMAGE_SUBDIR)

# Macosx bundles directory definitions
JDK_MACOSX_BUNDLE_SUBDIR=jdk-bundle
JRE_MACOSX_BUNDLE_SUBDIR=jre-bundle
JDK_MACOSX_BUNDLE_SUBDIR_SIGNED=jdk-bundle-signed
JRE_MACOSX_BUNDLE_SUBDIR_SIGNED=jre-bundle-signed
JDK_MACOSX_BUNDLE_DIR=$(IMAGES_OUTPUTDIR)/$(JDK_MACOSX_BUNDLE_SUBDIR)
JRE_MACOSX_BUNDLE_DIR=$(IMAGES_OUTPUTDIR)/$(JRE_MACOSX_BUNDLE_SUBDIR)
JDK_MACOSX_BUNDLE_DIR_SIGNED=$(IMAGES_OUTPUTDIR)/$(JDK_MACOSX_BUNDLE_SUBDIR_SIGNED)
JRE_MACOSX_BUNDLE_DIR_SIGNED=$(IMAGES_OUTPUTDIR)/$(JRE_MACOSX_BUNDLE_SUBDIR_SIGNED)
JDK_MACOSX_BUNDLE_TOP_DIR=jdk-$(VERSION_NUMBER).jdk
JRE_MACOSX_BUNDLE_TOP_DIR=jre-$(VERSION_NUMBER).jre
JDK_MACOSX_CONTENTS_SUBDIR=$(JDK_MACOSX_BUNDLE_TOP_DIR)/Contents
JRE_MACOSX_CONTENTS_SUBDIR=$(JRE_MACOSX_BUNDLE_TOP_DIR)/Contents
JDK_MACOSX_CONTENTS_DIR=$(JDK_MACOSX_BUNDLE_DIR)/$(JDK_MACOSX_CONTENTS_SUBDIR)
JRE_MACOSX_CONTENTS_DIR=$(JRE_MACOSX_BUNDLE_DIR)/$(JRE_MACOSX_CONTENTS_SUBDIR)

# Bundle names
BASE_NAME := $(VERSION_SHORT)+$(VERSION_BUILD)_$(OPENJDK_TARGET_BUNDLE_PLATFORM)
ifeq ($(DEBUG_LEVEL), fastdebug)
  DEBUG_PART := -debug
else ifneq ($(DEBUG_LEVEL), release)
  DEBUG_PART := -$(DEBUG_LEVEL)
endif
ifeq ($(OPENJDK_TARGET_OS), windows)
  JDK_BUNDLE_EXTENSION := zip
else
  JDK_BUNDLE_EXTENSION := tar.gz
endif
JDK_BUNDLE_NAME := jdk-$(BASE_NAME)_bin$(DEBUG_PART).$(JDK_BUNDLE_EXTENSION)
JRE_BUNDLE_NAME := jre-$(BASE_NAME)_bin$(DEBUG_PART).$(JDK_BUNDLE_EXTENSION)
JDK_SYMBOLS_BUNDLE_NAME := jdk-$(BASE_NAME)_bin$(DEBUG_PART)-symbols.tar.gz
TEST_DEMOS_BUNDLE_NAME := jdk-$(BASE_NAME)_bin-tests-demos$(DEBUG_PART).tar.gz
TEST_BUNDLE_NAME := jdk-$(BASE_NAME)_bin-tests$(DEBUG_PART).tar.gz
DOCS_BUNDLE_NAME := jdk-$(BASE_NAME)_doc-api-spec$(DEBUG_PART).tar.gz
STATIC_LIBS_BUNDLE_NAME := jdk-$(BASE_NAME)_bin-static-libs$(DEBUG_PART).tar.gz
JCOV_BUNDLE_NAME := jdk-jcov-$(BASE_NAME)_bin$(DEBUG_PART).$(JDK_BUNDLE_EXTENSION)

JDK_BUNDLE := $(BUNDLES_OUTPUTDIR)/$(JDK_BUNDLE_NAME)
JRE_BUNDLE :=  $(BUNDLES_OUTPUTDIR)/$(JRE_BUNDLE_NAME)
JDK_SYMBOLS_BUNDLE :=  $(BUNDLES_OUTPUTDIR)/$(JDK_SYMBOLS_BUNDLE_NAME)
TEST_DEMOS_BUNDLE := $(BUNDLES_OUTPUTDIR)/$(TEST_DEMOS_BUNDLE_NAME)
TEST_BUNDLE :=  $(BUNDLES_OUTPUTDIR)/$(TEST_BUNDLE_NAME)
DOCS_BUNDLE :=  $(BUNDLES_OUTPUTDIR)/$(DOCS_BUNDLE_NAME)
JCOV_BUNDLE := $(BUNDLES_OUTPUTDIR)/$(JCOV_BUNDLE_NAME)

# This macro is called to allow inclusion of closed source counterparts.
# Unless overridden in closed sources, it expands to nothing.
# Usage: This function is called in an open makefile, with the following
# argument:
# $1 the name of the makefile
define IncludeCustomExtension
endef

# Include the custom-spec.gmk file if it exists
-include $(dir /cygdrive/c/cygwin64/jdk/build/windows-x86_64-server-release/spec.gmk)/custom-spec.gmk
-------------- next part --------------
cd /


git clone https://github.com/openjdk/jdk

cd jdk

bash configure --disable-warnings-as-errors

make images

From erik.joelsson at oracle.com  Mon Jul 13 13:47:48 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 13 Jul 2020 06:47:48 -0700
Subject: RFR [XS]: 8248429: Add --enable-preview as VM argument when
 running microbenchmarks
In-Reply-To: <92167b16-8a7c-ea24-fb52-4272cd9e2459@gmail.com>
References: <8cd2491e-3e90-6c00-1d09-c2a11022c287@oracle.com>
 <19b5a5a2-1f60-361e-c417-2933504907cd@oracle.com>
 <f70a3348-d9ee-4c50-1fdd-5558d54a8920@oracle.com>
 <b2ca5e6c-68c5-eee3-646c-48e6bb8ae2ea@oracle.com>
 <4e6978ad-774f-f8d4-c10a-b4a1482f25b1@oracle.com>
 <aef6de37-5bea-2513-2fa3-5cf6dd721435@oracle.com>
 <9784b512-3606-474b-18a6-dfe236b63ac8@oracle.com>
 <fca0f099-7f13-6b22-21ee-9b5dd6914256@oracle.com>
 <2f460e59-b5bc-4561-6c8a-712b1d7ee318@oracle.com>
 <af841f5a-9638-498e-44c0-d8c0220c43b9@oracle.com>
 <722302a9-9184-8800-d312-bb7a8ecd3dfb@oracle.com>
 <d1e82d58-0c32-c9db-02d6-1a333232a419@oracle.com>
 <16f12991-d147-0328-f2b1-e20845acb3b7@oracle.com>
 <f8d2eb35-3f10-ef4a-e41d-11deb2850581@gmail.com>
 <56572ec4-1c79-66f0-76b2-1a710b606d33@oracle.com>
 <27f7334b-c2f4-21e9-6b05-bd400daa3893@gmail.com>
 <92167b16-8a7c-ea24-fb52-4272cd9e2459@gmail.com>
Message-ID: <b0513bed-6d92-7dd8-a8b3-4324174d2104@oracle.com>

Hello Peter,

On 2020-07-11 03:00, Peter Levart wrote:
>
> On 7/11/20 9:31 AM, Peter Levart wrote:
>> - compile the two sets of benchmarks separately with separate output 
>> directories and create separate benchmarks.jar files for them 
>
>
> Here's my attempt at a patch for separate benchmarks.jar files. The 
> minor complication, as I found out, was what to do when running the 
> micro benchmarks via "make test TEST=..." command when there are two 
> possible jar files to choose from. I opted for a separate tag in TEST 
> variable, so preview benchmark(s) are run as follows:
>
>
> make test TEST="micro.preview: ..."
>
>
> http://cr.openjdk.java.net/~plevart/jdk-dev/8248429_jmh_enable_preview/webrev.02/ 
>
>
This generally looks pretty good to me. I will defer to Claes on what 
build steps are actually needed for the new jar file. I agree with Claes 
that having a list of files in the makefile is probably easier to update 
than moving files around. I would recommend something like this:

MICROBENCHMARK_PREVIEW_FILES := \
 ??? org/openjdk/bench/java/io/RecordDeserialization.java \
 ??? #

This variable can then be fed into EXCLUDE_FILES and INCLUDE_FILES 
respectively. The formatting is our recommended way of building lists of 
things in the makefiles where lines can easily be added or removed 
without affecting any adjacent lines to minimize merge conflicts in the 
future.

Otherwise, I would only ask that you try to shorten some lines a bit. We 
aren't strictly enforcing 80 chars, but try to stay close when possible 
for easier side by side reviews and 3-way merges in the future. 
Specifically RunTests.gmk:682 (maybe an intermediate value?) and 
BuildMicrobenchmark.gmk:197.

/Erik

>
> WDYT?
>
>
> Regards, Peter
>
>


From jorn.vernee at oracle.com  Mon Jul 13 14:29:58 2020
From: jorn.vernee at oracle.com (Jorn Vernee)
Date: Mon, 13 Jul 2020 16:29:58 +0200
Subject: RFR [XS]: 8248429: Add --enable-preview as VM argument when
 running microbenchmarks
In-Reply-To: <92167b16-8a7c-ea24-fb52-4272cd9e2459@gmail.com>
References: <8cd2491e-3e90-6c00-1d09-c2a11022c287@oracle.com>
 <19b5a5a2-1f60-361e-c417-2933504907cd@oracle.com>
 <f70a3348-d9ee-4c50-1fdd-5558d54a8920@oracle.com>
 <b2ca5e6c-68c5-eee3-646c-48e6bb8ae2ea@oracle.com>
 <4e6978ad-774f-f8d4-c10a-b4a1482f25b1@oracle.com>
 <aef6de37-5bea-2513-2fa3-5cf6dd721435@oracle.com>
 <9784b512-3606-474b-18a6-dfe236b63ac8@oracle.com>
 <fca0f099-7f13-6b22-21ee-9b5dd6914256@oracle.com>
 <2f460e59-b5bc-4561-6c8a-712b1d7ee318@oracle.com>
 <af841f5a-9638-498e-44c0-d8c0220c43b9@oracle.com>
 <722302a9-9184-8800-d312-bb7a8ecd3dfb@oracle.com>
 <d1e82d58-0c32-c9db-02d6-1a333232a419@oracle.com>
 <16f12991-d147-0328-f2b1-e20845acb3b7@oracle.com>
 <f8d2eb35-3f10-ef4a-e41d-11deb2850581@gmail.com>
 <56572ec4-1c79-66f0-76b2-1a710b606d33@oracle.com>
 <27f7334b-c2f4-21e9-6b05-bd400daa3893@gmail.com>
 <92167b16-8a7c-ea24-fb52-4272cd9e2459@gmail.com>
Message-ID: <cf5590d5-9db3-4141-18b8-0dcbf2ba4bb9@oracle.com>

Hey Peter,

Thank you for looking into this. I planned on coming back to this later, 
as it wasn't as much of a quick-fix as I'd hoped, but got caught up 
working on other issues in the mean time.

Jorn

On 11/07/2020 12:00, Peter Levart wrote:
>
> On 7/11/20 9:31 AM, Peter Levart wrote:
>> - compile the two sets of benchmarks separately with separate output 
>> directories and create separate benchmarks.jar files for them 
>
>
> Here's my attempt at a patch for separate benchmarks.jar files. The 
> minor complication, as I found out, was what to do when running the 
> micro benchmarks via "make test TEST=..." command when there are two 
> possible jar files to choose from. I opted for a separate tag in TEST 
> variable, so preview benchmark(s) are run as follows:
>
>
> make test TEST="micro.preview: ..."
>
>
> http://cr.openjdk.java.net/~plevart/jdk-dev/8248429_jmh_enable_preview/webrev.02/ 
>
>
>
> WDYT?
>
>
> Regards, Peter
>
>


From erik.joelsson at oracle.com  Mon Jul 13 18:04:30 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 13 Jul 2020 11:04:30 -0700
Subject: cannot find valid Visual Code Studio install
In-Reply-To: <b9ded9c8-aab3-30c1-fbfd-a2cc78f965f7@gmail.com>
References: <878af486-ec0b-525e-05c4-857e0c59128f@gmail.com>
 <1e8972ff-db0e-86e7-5e26-06e50b8cd491@oracle.com>
 <160667fd-50ab-fa83-0a49-8baae686eb8d@gmail.com>
 <1afb447c-51ab-e105-97e1-7d71621bbb48@oracle.com>
 <34357344-bf7e-8a02-b61d-2a03ad7188ee@gmail.com>
 <875a5d2f-87b0-a323-12bd-297cc04ddfa8@oracle.com>
 <246ef571-112a-77b9-2338-82b89fb84202@gmail.com>
 <bfb09866-41df-36a3-b503-0ef3023936e8@oracle.com>
 <b9ded9c8-aab3-30c1-fbfd-a2cc78f965f7@gmail.com>
Message-ID: <01d88f47-1b93-ef28-0a7f-96c45933241a@oracle.com>

There seems to be something with the absolute path elimination that 
doesn't work when the workspace is located inside the c:/cygwin64 dir. 
As a workaround, you can either try moving the source to a directory 
outside of c:/cygwin64 or run configure with 
--enable-absolute-paths-in-output.

I'm still investigating the exact cause.

/Erik

On 2020-07-12 00:46, Ty Young wrote:
>
> On 7/10/20 7:43 AM, Erik Joelsson wrote:
>>
>> On 2020-07-09 15:04, Ty Young wrote:
>>>
>>> On 7/9/20 3:20 PM, Erik Joelsson wrote:
>>>>
>>>> On 2020-07-09 12:56, Ty Young wrote:
>>>>>
>>>>> On 7/9/20 9:22 AM, Erik Joelsson wrote:
>>>>>> Could you post the full configure command and log please. This 
>>>>>> sounds weird. You should not be needing clang on Windows.
>>>>>>
>>>>>> Also, what source did you clone?
>>>>>
>>>>>
>>>>> On linux right now, but I think it's because I'm using the 
>>>>> jextract branch of panama-foreign:
>>>>>
>>>>>
>>>>> https://github.com/openjdk/panama-foreign
>>>>>
>>>> This was a very crucial piece of information that you left out 
>>>> initially. Panama uses libclang for specific new features in that 
>>>> project. I don't know the details on how to build that project. You 
>>>> will need to ask people working on Panama for details on any 
>>>> special needs they have.
>>>>
>>>> I would recommend you clone the mainline jdk and get that to work 
>>>> first as a baseline.
>>>
>>>
>>> Just did, as well as a version of panama-foreign that should work 
>>> but doesn't need clang(foreign-abi).
>>>
>>>
>>> It configures now, but fails to build with errors like:
>>>
>>>
>>> c1xx: fatal error C1083: Cannot open source file: 
>>> '../../../..c:/cygwin64/home/young/jdk-master/jdk-master/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM_pch.cpp': 
>>> No such file or directory
>>>
>>>
>> Could you send your configure.log, spec.gmk and the exact command 
>> lines you used?
>>
>> /Erik
>
>
> Attached.
>
>
>>
>>> Basically every file within the objs file is missing... but it isn't 
>>> actually. I can see them in Windows explorer just fine and configure 
>>> doesn't throw any errors.
>>>
>>>
>>> Thinking that this was an issue with file depth, I moved the cloned 
>>> source code to root as "jdk-build". It still fails in the same spot. 
>>> Both of them.
>>>
>>>
>>>>
>>>> /Erik
>>>>
>>>>>
>>>>> I remember there being a commit some time ago that requires clang 
>>>>> to be specified on panama-dev, but I've never had to do that under 
>>>>> Linux. This is my first time compiling on Windows so I have no 
>>>>> idea what's going on.
>>>>>
>>>>>
>>>>>>
>>>>>> /Erik
>>>>>>
>>>>>> On 2020-07-09 07:04, Ty Young wrote:
>>>>>>>
>>>>>>> On 7/9/20 7:37 AM, Erik Joelsson wrote:
>>>>>>>> Hello Ty,
>>>>>>>>
>>>>>>>> Microsoft Visual Studio 2019 or 2017, any edition, should work. 
>>>>>>>> My best guess is that you skipped installing the necessary 
>>>>>>>> parts of it. Run the installer again, click "Modify" and make 
>>>>>>>> sure you have "Desktop development with C++" ticked in.
>>>>>>>
>>>>>>>
>>>>>>> That worked, thanks!
>>>>>>>
>>>>>>>
>>>>>>> It still didn't configure though. Now it's complaining about not 
>>>>>>> having clang installed. Once I installed clang and clang-devel, 
>>>>>>> it then complained about not having version 9 installed. The 
>>>>>>> latest version from cygdrive was 8<something>, 9 is not an 
>>>>>>> option. If I try to trick it by copying and renaming the older 
>>>>>>> 8<something> version, it then complains about Index.h being 
>>>>>>> found but not being compileable and to report it here.
>>>>>>>
>>>>>>>
>>>>>>> Any advice here? I tried installing more extra stuff from Visual 
>>>>>>> Code Studio to see if it'd help, but it doesn't or I'm not 
>>>>>>> installing the right things.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> /ERik
>>>>>>>>
>>>>>>>> On 2020-07-09 01:29, Ty Young wrote:
>>>>>>>>> Hopefully this is the right place. Don't shoot me if it isn't, 
>>>>>>>>> please.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I'm trying to build the JDK from Windows 10. I got so far as 
>>>>>>>>> to configure failing on finding what it needs from the Visual 
>>>>>>>>> Code Studio install via command line:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> configure: Found Visual Studio installation at 
>>>>>>>>> /cygdrive/c/Program Files (x86)/Microsoft Visual 
>>>>>>>>> Studio/2019/Community using well-known name
>>>>>>>>> configure: Warning: None of vc/bin/amd64/vcvars64.bat 
>>>>>>>>> vc/bin/x86_amd64/vcvarsx86_amd64.bat 
>>>>>>>>> VC/Auxiliary/Build/vcvarsx86_amd64.bat 
>>>>>>>>> VC/Auxiliary/Build/vcvars64.bat were found, Visual Studio 
>>>>>>>>> installation not recognized. Ignoring
>>>>>>>>> configure: Found Visual Studio installation at 
>>>>>>>>> /cygdrive/c/Program Files (x86)/Microsoft Visual 
>>>>>>>>> Studio/2019/Community using well-known name
>>>>>>>>> configure: Warning: None of vc/bin/amd64/vcvars64.bat 
>>>>>>>>> vc/bin/x86_amd64/vcvarsx86_amd64.bat 
>>>>>>>>> VC/Auxiliary/Build/vcvarsx86_amd64.bat 
>>>>>>>>> VC/Auxiliary/Build/vcvars64.bat were found, Visual Studio 
>>>>>>>>> installation not recognized. Ignoring
>>>>>>>>> configure: Cannot locate a valid Visual Studio installation, 
>>>>>>>>> checking current environment
>>>>>>>>> checking for Visual Studio variables... not found
>>>>>>>>> configure: Cannot locate a valid Visual Studio or Windows SDK 
>>>>>>>>> installation on disk,
>>>>>>>>> configure: nor is this script run from a Visual Studio command 
>>>>>>>>> prompt.
>>>>>>>>> configure: Try setting --with-tools-dir to the VC/bin 
>>>>>>>>> directory within the VS installation
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> However there is no "bin" directory in this installation, at 
>>>>>>>>> least not one that contains any of the specified files. This 
>>>>>>>>> is Visual Code 2019 Community, but I've tried the Professional 
>>>>>>>>> version too. The building document doesn't specify which 
>>>>>>>>> version, nor does it tell me how to fix this.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> How do I get this to work via command line?
>>>>>>>>>


From erik.joelsson at oracle.com  Mon Jul 13 18:50:20 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 13 Jul 2020 11:50:20 -0700
Subject: cannot find valid Visual Code Studio install
In-Reply-To: <01d88f47-1b93-ef28-0a7f-96c45933241a@oracle.com>
References: <878af486-ec0b-525e-05c4-857e0c59128f@gmail.com>
 <1e8972ff-db0e-86e7-5e26-06e50b8cd491@oracle.com>
 <160667fd-50ab-fa83-0a49-8baae686eb8d@gmail.com>
 <1afb447c-51ab-e105-97e1-7d71621bbb48@oracle.com>
 <34357344-bf7e-8a02-b61d-2a03ad7188ee@gmail.com>
 <875a5d2f-87b0-a323-12bd-297cc04ddfa8@oracle.com>
 <246ef571-112a-77b9-2338-82b89fb84202@gmail.com>
 <bfb09866-41df-36a3-b503-0ef3023936e8@oracle.com>
 <b9ded9c8-aab3-30c1-fbfd-a2cc78f965f7@gmail.com>
 <01d88f47-1b93-ef28-0a7f-96c45933241a@oracle.com>
Message-ID: <008b708e-45aa-6409-8f96-501e9826a8cd@oracle.com>

Filed https://bugs.openjdk.java.net/browse/JDK-8249255

/Erik

On 2020-07-13 11:04, Erik Joelsson wrote:
> There seems to be something with the absolute path elimination that 
> doesn't work when the workspace is located inside the c:/cygwin64 dir. 
> As a workaround, you can either try moving the source to a directory 
> outside of c:/cygwin64 or run configure with 
> --enable-absolute-paths-in-output.
>
> I'm still investigating the exact cause.
>
> /Erik
>
> On 2020-07-12 00:46, Ty Young wrote:
>>
>> On 7/10/20 7:43 AM, Erik Joelsson wrote:
>>>
>>> On 2020-07-09 15:04, Ty Young wrote:
>>>>
>>>> On 7/9/20 3:20 PM, Erik Joelsson wrote:
>>>>>
>>>>> On 2020-07-09 12:56, Ty Young wrote:
>>>>>>
>>>>>> On 7/9/20 9:22 AM, Erik Joelsson wrote:
>>>>>>> Could you post the full configure command and log please. This 
>>>>>>> sounds weird. You should not be needing clang on Windows.
>>>>>>>
>>>>>>> Also, what source did you clone?
>>>>>>
>>>>>>
>>>>>> On linux right now, but I think it's because I'm using the 
>>>>>> jextract branch of panama-foreign:
>>>>>>
>>>>>>
>>>>>> https://github.com/openjdk/panama-foreign
>>>>>>
>>>>> This was a very crucial piece of information that you left out 
>>>>> initially. Panama uses libclang for specific new features in that 
>>>>> project. I don't know the details on how to build that project. 
>>>>> You will need to ask people working on Panama for details on any 
>>>>> special needs they have.
>>>>>
>>>>> I would recommend you clone the mainline jdk and get that to work 
>>>>> first as a baseline.
>>>>
>>>>
>>>> Just did, as well as a version of panama-foreign that should work 
>>>> but doesn't need clang(foreign-abi).
>>>>
>>>>
>>>> It configures now, but fails to build with errors like:
>>>>
>>>>
>>>> c1xx: fatal error C1083: Cannot open source file: 
>>>> '../../../..c:/cygwin64/home/young/jdk-master/jdk-master/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM_pch.cpp': 
>>>> No such file or directory
>>>>
>>>>
>>> Could you send your configure.log, spec.gmk and the exact command 
>>> lines you used?
>>>
>>> /Erik
>>
>>
>> Attached.
>>
>>
>>>
>>>> Basically every file within the objs file is missing... but it 
>>>> isn't actually. I can see them in Windows explorer just fine and 
>>>> configure doesn't throw any errors.
>>>>
>>>>
>>>> Thinking that this was an issue with file depth, I moved the cloned 
>>>> source code to root as "jdk-build". It still fails in the same 
>>>> spot. Both of them.
>>>>
>>>>
>>>>>
>>>>> /Erik
>>>>>
>>>>>>
>>>>>> I remember there being a commit some time ago that requires clang 
>>>>>> to be specified on panama-dev, but I've never had to do that 
>>>>>> under Linux. This is my first time compiling on Windows so I have 
>>>>>> no idea what's going on.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> /Erik
>>>>>>>
>>>>>>> On 2020-07-09 07:04, Ty Young wrote:
>>>>>>>>
>>>>>>>> On 7/9/20 7:37 AM, Erik Joelsson wrote:
>>>>>>>>> Hello Ty,
>>>>>>>>>
>>>>>>>>> Microsoft Visual Studio 2019 or 2017, any edition, should 
>>>>>>>>> work. My best guess is that you skipped installing the 
>>>>>>>>> necessary parts of it. Run the installer again, click "Modify" 
>>>>>>>>> and make sure you have "Desktop development with C++" ticked in.
>>>>>>>>
>>>>>>>>
>>>>>>>> That worked, thanks!
>>>>>>>>
>>>>>>>>
>>>>>>>> It still didn't configure though. Now it's complaining about 
>>>>>>>> not having clang installed. Once I installed clang and 
>>>>>>>> clang-devel, it then complained about not having version 9 
>>>>>>>> installed. The latest version from cygdrive was 8<something>, 9 
>>>>>>>> is not an option. If I try to trick it by copying and renaming 
>>>>>>>> the older 8<something> version, it then complains about Index.h 
>>>>>>>> being found but not being compileable and to report it here.
>>>>>>>>
>>>>>>>>
>>>>>>>> Any advice here? I tried installing more extra stuff from 
>>>>>>>> Visual Code Studio to see if it'd help, but it doesn't or I'm 
>>>>>>>> not installing the right things.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> /ERik
>>>>>>>>>
>>>>>>>>> On 2020-07-09 01:29, Ty Young wrote:
>>>>>>>>>> Hopefully this is the right place. Don't shoot me if it 
>>>>>>>>>> isn't, please.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I'm trying to build the JDK from Windows 10. I got so far as 
>>>>>>>>>> to configure failing on finding what it needs from the Visual 
>>>>>>>>>> Code Studio install via command line:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> configure: Found Visual Studio installation at 
>>>>>>>>>> /cygdrive/c/Program Files (x86)/Microsoft Visual 
>>>>>>>>>> Studio/2019/Community using well-known name
>>>>>>>>>> configure: Warning: None of vc/bin/amd64/vcvars64.bat 
>>>>>>>>>> vc/bin/x86_amd64/vcvarsx86_amd64.bat 
>>>>>>>>>> VC/Auxiliary/Build/vcvarsx86_amd64.bat 
>>>>>>>>>> VC/Auxiliary/Build/vcvars64.bat were found, Visual Studio 
>>>>>>>>>> installation not recognized. Ignoring
>>>>>>>>>> configure: Found Visual Studio installation at 
>>>>>>>>>> /cygdrive/c/Program Files (x86)/Microsoft Visual 
>>>>>>>>>> Studio/2019/Community using well-known name
>>>>>>>>>> configure: Warning: None of vc/bin/amd64/vcvars64.bat 
>>>>>>>>>> vc/bin/x86_amd64/vcvarsx86_amd64.bat 
>>>>>>>>>> VC/Auxiliary/Build/vcvarsx86_amd64.bat 
>>>>>>>>>> VC/Auxiliary/Build/vcvars64.bat were found, Visual Studio 
>>>>>>>>>> installation not recognized. Ignoring
>>>>>>>>>> configure: Cannot locate a valid Visual Studio installation, 
>>>>>>>>>> checking current environment
>>>>>>>>>> checking for Visual Studio variables... not found
>>>>>>>>>> configure: Cannot locate a valid Visual Studio or Windows SDK 
>>>>>>>>>> installation on disk,
>>>>>>>>>> configure: nor is this script run from a Visual Studio 
>>>>>>>>>> command prompt.
>>>>>>>>>> configure: Try setting --with-tools-dir to the VC/bin 
>>>>>>>>>> directory within the VS installation
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> However there is no "bin" directory in this installation, at 
>>>>>>>>>> least not one that contains any of the specified files. This 
>>>>>>>>>> is Visual Code 2019 Community, but I've tried the 
>>>>>>>>>> Professional version too. The building document doesn't 
>>>>>>>>>> specify which version, nor does it tell me how to fix this.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> How do I get this to work via command line?
>>>>>>>>>>


From erik.joelsson at oracle.com  Mon Jul 13 20:47:44 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 13 Jul 2020 13:47:44 -0700
Subject: [15] RFR: JDK-8249255: Build fails if source code in cygwin home dir
Message-ID: <aae9bd38-8e37-6555-7644-074fc2e29393@oracle.com>

This is a fix for the problem reported by Ty in this thread: 
https://mail.openjdk.java.net/pipermail/build-dev/2020-July/027917.html

The problem is the --disable-absolute-paths-in-output option, which is 
default set to disable on release builds. When not allowing absolute 
paths, we rewrite absolute paths to relative in several types of build 
command lines. This rewrite relies on the WORKSPACE_ROOT variable to be 
fully resolved. Currently, if the workspace is located inside the cygwin 
root dir, the WORKSPACE_ROOT variable will have a path looking like 
"/home/user/jdk" while all other paths that we resolve files from will 
look like "/cygdrive/c/cygwin64/home/user/jdk". This causes the rewrite 
to fail and results in build errors like this:

c1xx: fatal error C1083: Cannot open source file: 
'../../../..c:/cygwin64/home/young/jdk-master/jdk-master/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM_pch.cpp': 
No such file or directory

The fix is to make sure WORKSPACE_ROOT in basics.m4 only gets values 
that have been fixed using UTIL_FIXUP_PATH.

(This issue rarely occurs within Oracle, where Jib is already changing 
the working to be on the /cygdrive format, which is why we haven't seen 
it reported internally so far.)

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

Webrev: http://cr.openjdk.java.net/~erikj/8249255/webrev.01/index.html

/Erik



From tim.bell at oracle.com  Tue Jul 14 03:25:49 2020
From: tim.bell at oracle.com (Tim Bell)
Date: Mon, 13 Jul 2020 20:25:49 -0700
Subject: [15] RFR: JDK-8249255: Build fails if source code in cygwin home
 dir
In-Reply-To: <aae9bd38-8e37-6555-7644-074fc2e29393@oracle.com>
References: <aae9bd38-8e37-6555-7644-074fc2e29393@oracle.com>
Message-ID: <122ed587-95c4-7294-6b48-d70f5b4619af@oracle.com>

Erik:

 > The fix is to make sure WORKSPACE_ROOT in basics.m4 only gets values
 > that have been fixed using UTIL_FIXUP_PATH.

Looks good.

Tim

> This is a fix for the problem reported by Ty in this thread: 
> https://mail.openjdk.java.net/pipermail/build-dev/2020-July/027917.html
> 
> The problem is the --disable-absolute-paths-in-output option, which is 
> default set to disable on release builds. When not allowing absolute 
> paths, we rewrite absolute paths to relative in several types of build 
> command lines. This rewrite relies on the WORKSPACE_ROOT variable to be 
> fully resolved. Currently, if the workspace is located inside the cygwin 
> root dir, the WORKSPACE_ROOT variable will have a path looking like 
> "/home/user/jdk" while all other paths that we resolve files from will 
> look like "/cygdrive/c/cygwin64/home/user/jdk". This causes the rewrite 
> to fail and results in build errors like this:
> 
> c1xx: fatal error C1083: Cannot open source file: 
> '../../../..c:/cygwin64/home/young/jdk-master/jdk-master/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM_pch.cpp': 
> No such file or directory
> 
> The fix is to make sure WORKSPACE_ROOT in basics.m4 only gets values 
> that have been fixed using UTIL_FIXUP_PATH.
> 
> (This issue rarely occurs within Oracle, where Jib is already changing 
> the working to be on the /cygdrive format, which is why we haven't seen 
> it reported internally so far.)
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8249255
> 
> Webrev: http://cr.openjdk.java.net/~erikj/8249255/webrev.01/index.html
> 
> /Erik
> 



From youngty1997 at gmail.com  Tue Jul 14 08:52:09 2020
From: youngty1997 at gmail.com (Ty Young)
Date: Tue, 14 Jul 2020 03:52:09 -0500
Subject: cannot find valid Visual Code Studio install
In-Reply-To: <01d88f47-1b93-ef28-0a7f-96c45933241a@oracle.com>
References: <878af486-ec0b-525e-05c4-857e0c59128f@gmail.com>
 <1e8972ff-db0e-86e7-5e26-06e50b8cd491@oracle.com>
 <160667fd-50ab-fa83-0a49-8baae686eb8d@gmail.com>
 <1afb447c-51ab-e105-97e1-7d71621bbb48@oracle.com>
 <34357344-bf7e-8a02-b61d-2a03ad7188ee@gmail.com>
 <875a5d2f-87b0-a323-12bd-297cc04ddfa8@oracle.com>
 <246ef571-112a-77b9-2338-82b89fb84202@gmail.com>
 <bfb09866-41df-36a3-b503-0ef3023936e8@oracle.com>
 <b9ded9c8-aab3-30c1-fbfd-a2cc78f965f7@gmail.com>
 <01d88f47-1b93-ef28-0a7f-96c45933241a@oracle.com>
Message-ID: <3ad8aa24-96fe-373f-1e9c-d4a17bb00bba@gmail.com>


On 7/13/20 1:04 PM, Erik Joelsson wrote:
> There seems to be something with the absolute path elimination that 
> doesn't work when the workspace is located inside the c:/cygwin64 dir. 
> As a workaround, you can either try moving the source to a directory 
> outside of c:/cygwin64 or run configure with 
> --enable-absolute-paths-in-output.
>
> I'm still investigating the exact cause.


Works, thank you!


Question: are Windows builds generally slower than Linux builds? It 
feels like building under cygwin is a bit slower, but I can't be sure.


>
> /Erik
>
> On 2020-07-12 00:46, Ty Young wrote:
>>
>> On 7/10/20 7:43 AM, Erik Joelsson wrote:
>>>
>>> On 2020-07-09 15:04, Ty Young wrote:
>>>>
>>>> On 7/9/20 3:20 PM, Erik Joelsson wrote:
>>>>>
>>>>> On 2020-07-09 12:56, Ty Young wrote:
>>>>>>
>>>>>> On 7/9/20 9:22 AM, Erik Joelsson wrote:
>>>>>>> Could you post the full configure command and log please. This 
>>>>>>> sounds weird. You should not be needing clang on Windows.
>>>>>>>
>>>>>>> Also, what source did you clone?
>>>>>>
>>>>>>
>>>>>> On linux right now, but I think it's because I'm using the 
>>>>>> jextract branch of panama-foreign:
>>>>>>
>>>>>>
>>>>>> https://github.com/openjdk/panama-foreign
>>>>>>
>>>>> This was a very crucial piece of information that you left out 
>>>>> initially. Panama uses libclang for specific new features in that 
>>>>> project. I don't know the details on how to build that project. 
>>>>> You will need to ask people working on Panama for details on any 
>>>>> special needs they have.
>>>>>
>>>>> I would recommend you clone the mainline jdk and get that to work 
>>>>> first as a baseline.
>>>>
>>>>
>>>> Just did, as well as a version of panama-foreign that should work 
>>>> but doesn't need clang(foreign-abi).
>>>>
>>>>
>>>> It configures now, but fails to build with errors like:
>>>>
>>>>
>>>> c1xx: fatal error C1083: Cannot open source file: 
>>>> '../../../..c:/cygwin64/home/young/jdk-master/jdk-master/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM_pch.cpp': 
>>>> No such file or directory
>>>>
>>>>
>>> Could you send your configure.log, spec.gmk and the exact command 
>>> lines you used?
>>>
>>> /Erik
>>
>>
>> Attached.
>>
>>
>>>
>>>> Basically every file within the objs file is missing... but it 
>>>> isn't actually. I can see them in Windows explorer just fine and 
>>>> configure doesn't throw any errors.
>>>>
>>>>
>>>> Thinking that this was an issue with file depth, I moved the cloned 
>>>> source code to root as "jdk-build". It still fails in the same 
>>>> spot. Both of them.
>>>>
>>>>
>>>>>
>>>>> /Erik
>>>>>
>>>>>>
>>>>>> I remember there being a commit some time ago that requires clang 
>>>>>> to be specified on panama-dev, but I've never had to do that 
>>>>>> under Linux. This is my first time compiling on Windows so I have 
>>>>>> no idea what's going on.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> /Erik
>>>>>>>
>>>>>>> On 2020-07-09 07:04, Ty Young wrote:
>>>>>>>>
>>>>>>>> On 7/9/20 7:37 AM, Erik Joelsson wrote:
>>>>>>>>> Hello Ty,
>>>>>>>>>
>>>>>>>>> Microsoft Visual Studio 2019 or 2017, any edition, should 
>>>>>>>>> work. My best guess is that you skipped installing the 
>>>>>>>>> necessary parts of it. Run the installer again, click "Modify" 
>>>>>>>>> and make sure you have "Desktop development with C++" ticked in.
>>>>>>>>
>>>>>>>>
>>>>>>>> That worked, thanks!
>>>>>>>>
>>>>>>>>
>>>>>>>> It still didn't configure though. Now it's complaining about 
>>>>>>>> not having clang installed. Once I installed clang and 
>>>>>>>> clang-devel, it then complained about not having version 9 
>>>>>>>> installed. The latest version from cygdrive was 8<something>, 9 
>>>>>>>> is not an option. If I try to trick it by copying and renaming 
>>>>>>>> the older 8<something> version, it then complains about Index.h 
>>>>>>>> being found but not being compileable and to report it here.
>>>>>>>>
>>>>>>>>
>>>>>>>> Any advice here? I tried installing more extra stuff from 
>>>>>>>> Visual Code Studio to see if it'd help, but it doesn't or I'm 
>>>>>>>> not installing the right things.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> /ERik
>>>>>>>>>
>>>>>>>>> On 2020-07-09 01:29, Ty Young wrote:
>>>>>>>>>> Hopefully this is the right place. Don't shoot me if it 
>>>>>>>>>> isn't, please.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I'm trying to build the JDK from Windows 10. I got so far as 
>>>>>>>>>> to configure failing on finding what it needs from the Visual 
>>>>>>>>>> Code Studio install via command line:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> configure: Found Visual Studio installation at 
>>>>>>>>>> /cygdrive/c/Program Files (x86)/Microsoft Visual 
>>>>>>>>>> Studio/2019/Community using well-known name
>>>>>>>>>> configure: Warning: None of vc/bin/amd64/vcvars64.bat 
>>>>>>>>>> vc/bin/x86_amd64/vcvarsx86_amd64.bat 
>>>>>>>>>> VC/Auxiliary/Build/vcvarsx86_amd64.bat 
>>>>>>>>>> VC/Auxiliary/Build/vcvars64.bat were found, Visual Studio 
>>>>>>>>>> installation not recognized. Ignoring
>>>>>>>>>> configure: Found Visual Studio installation at 
>>>>>>>>>> /cygdrive/c/Program Files (x86)/Microsoft Visual 
>>>>>>>>>> Studio/2019/Community using well-known name
>>>>>>>>>> configure: Warning: None of vc/bin/amd64/vcvars64.bat 
>>>>>>>>>> vc/bin/x86_amd64/vcvarsx86_amd64.bat 
>>>>>>>>>> VC/Auxiliary/Build/vcvarsx86_amd64.bat 
>>>>>>>>>> VC/Auxiliary/Build/vcvars64.bat were found, Visual Studio 
>>>>>>>>>> installation not recognized. Ignoring
>>>>>>>>>> configure: Cannot locate a valid Visual Studio installation, 
>>>>>>>>>> checking current environment
>>>>>>>>>> checking for Visual Studio variables... not found
>>>>>>>>>> configure: Cannot locate a valid Visual Studio or Windows SDK 
>>>>>>>>>> installation on disk,
>>>>>>>>>> configure: nor is this script run from a Visual Studio 
>>>>>>>>>> command prompt.
>>>>>>>>>> configure: Try setting --with-tools-dir to the VC/bin 
>>>>>>>>>> directory within the VS installation
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> However there is no "bin" directory in this installation, at 
>>>>>>>>>> least not one that contains any of the specified files. This 
>>>>>>>>>> is Visual Code 2019 Community, but I've tried the 
>>>>>>>>>> Professional version too. The building document doesn't 
>>>>>>>>>> specify which version, nor does it tell me how to fix this.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> How do I get this to work via command line?
>>>>>>>>>>


From erik.joelsson at oracle.com  Tue Jul 14 12:42:42 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 14 Jul 2020 05:42:42 -0700
Subject: cannot find valid Visual Code Studio install
In-Reply-To: <3ad8aa24-96fe-373f-1e9c-d4a17bb00bba@gmail.com>
References: <878af486-ec0b-525e-05c4-857e0c59128f@gmail.com>
 <1e8972ff-db0e-86e7-5e26-06e50b8cd491@oracle.com>
 <160667fd-50ab-fa83-0a49-8baae686eb8d@gmail.com>
 <1afb447c-51ab-e105-97e1-7d71621bbb48@oracle.com>
 <34357344-bf7e-8a02-b61d-2a03ad7188ee@gmail.com>
 <875a5d2f-87b0-a323-12bd-297cc04ddfa8@oracle.com>
 <246ef571-112a-77b9-2338-82b89fb84202@gmail.com>
 <bfb09866-41df-36a3-b503-0ef3023936e8@oracle.com>
 <b9ded9c8-aab3-30c1-fbfd-a2cc78f965f7@gmail.com>
 <01d88f47-1b93-ef28-0a7f-96c45933241a@oracle.com>
 <3ad8aa24-96fe-373f-1e9c-d4a17bb00bba@gmail.com>
Message-ID: <0d614d68-62f1-9ba0-7350-45b8809450fc@oracle.com>


On 2020-07-14 01:52, Ty Young wrote:
>
> Question: are Windows builds generally slower than Linux builds? It 
> feels like building under cygwin is a bit slower, but I can't be sure.
>
Yes, Windows builds are most definitely slower. Emulating a Unix like 
environment on top of Windows is inherently slow. The Unix model of 
forking lots of processes, which makefiles typically do, is very fast in 
Linux, but expensive in Windows. Another factor is the filesystem, which 
on Linux has a very fast caching mechanism that makes many small file 
operations very fast. This is a lot slower on Windows. On my 
workstations with equal hardware, the Windows build is about 2.5x slower 
than the Linux build.

/Erik




From erik.joelsson at oracle.com  Tue Jul 14 18:23:31 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 14 Jul 2020 11:23:31 -0700
Subject: RFR: JDK-8249292: DependOnVariable macro fails on empty value
Message-ID: <0937eb96-6b46-d2e4-3ef5-2d39be26da0d@oracle.com>

The DependOnVariable macro fails if the variable is empty. The failure 
is rather non intuitive as it complains that the vardeps file doesn't 
exist and is needed for the target. This patch make the macro treat an 
empty variable value just like any other value. I'm also adding test 
cases to verify this new behavior.

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

Webrev: http://cr.openjdk.java.net/~erikj/8249292/webrev.01/index.html

/Erik



From tim.bell at oracle.com  Tue Jul 14 22:16:11 2020
From: tim.bell at oracle.com (Tim Bell)
Date: Tue, 14 Jul 2020 15:16:11 -0700
Subject: RFR: JDK-8249292: DependOnVariable macro fails on empty value
In-Reply-To: <0937eb96-6b46-d2e4-3ef5-2d39be26da0d@oracle.com>
References: <0937eb96-6b46-d2e4-3ef5-2d39be26da0d@oracle.com>
Message-ID: <c8d8a23e-3f39-4fe5-dcf3-4d783797c579@oracle.com>

Erik:

> The DependOnVariable macro fails if the variable is empty. The failure 
> is rather non intuitive as it complains that the vardeps file doesn't 
> exist and is needed for the target. This patch make the macro treat an 
> empty variable value just like any other value. I'm also adding test 
> cases to verify this new behavior.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8249292
> 
> Webrev: http://cr.openjdk.java.net/~erikj/8249292/webrev.01/index.html

Looks good.

Tim



From jiefu at tencent.com  Sat Jul 18 06:17:35 2020
From: jiefu at tencent.com (=?utf-8?B?amllZnUo5YKF5p2wKQ==?=)
Date: Sat, 18 Jul 2020 06:17:35 +0000
Subject: RFR: 8249704: UTIL_DEPRECATED_ARG_ENABLE dumps incorrect warning
 message
Message-ID: <8299D8CB-AB4D-498B-A5E2-6BB2EDBEE0BF@tencent.com>

Hi all,

May I get reviews for this change?

JBS:    https://bugs.openjdk.java.net/browse/JDK-8249704
Webrev: http://cr.openjdk.java.net/~jiefu/8249704/webrev.00/

Thanks a lot.
Best regards,
Jie

From erik.joelsson at oracle.com  Mon Jul 20 13:32:43 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 20 Jul 2020 06:32:43 -0700
Subject: RFR: 8249704: UTIL_DEPRECATED_ARG_ENABLE dumps incorrect warning
 message
In-Reply-To: <8299D8CB-AB4D-498B-A5E2-6BB2EDBEE0BF@tencent.com>
References: <8299D8CB-AB4D-498B-A5E2-6BB2EDBEE0BF@tencent.com>
Message-ID: <eaf6d136-bd88-e921-91a8-763c9535e40a@oracle.com>

Hello Jie,

Your change looks fine if you really think this is a problem.

However, in Autoconf all --enable-* options have a corresponding 
--disable-* (and every --with-* has a --without-*). Always explicitly 
listing both in all help text would be very cumbersome and I think would 
need to be applied consistently if desired. We have assumed some basic 
autoconf knowledge like this when using the configure script, and so we 
aren't listing both variants. Sometimes we do list the negated version 
in the help text when that's the more obviously useful option. Perhaps 
that should have been done in this case as disabling gtest was the more 
common user option (as enabled was default).

/Erik

On 2020-07-17 23:17, jiefu(??) wrote:
> Hi all,
>
> May I get reviews for this change?
>
> JBS:    https://bugs.openjdk.java.net/browse/JDK-8249704
> Webrev: http://cr.openjdk.java.net/~jiefu/8249704/webrev.00/
>
> Thanks a lot.
> Best regards,
> Jie


From jiefu at tencent.com  Tue Jul 21 05:11:39 2020
From: jiefu at tencent.com (=?utf-8?B?amllZnUo5YKF5p2wKQ==?=)
Date: Tue, 21 Jul 2020 05:11:39 +0000
Subject: RFR: 8249704: UTIL_DEPRECATED_ARG_ENABLE dumps incorrect warning
 message
Message-ID: <BB1EA8F8-FD69-46A7-BA50-F56DA70854AB@tencent.com>

Hi Erik,

Thanks for sharing this knowledge with us.
I'll close this issue as won't fix.

Best regards,
Jie


?On 2020/7/20, 9:34 PM, "Erik Joelsson" <erik.joelsson at oracle.com> wrote:

    Hello Jie,
    
    Your change looks fine if you really think this is a problem.
    
    However, in Autoconf all --enable-* options have a corresponding 
    --disable-* (and every --with-* has a --without-*). Always explicitly 
    listing both in all help text would be very cumbersome and I think would 
    need to be applied consistently if desired. We have assumed some basic 
    autoconf knowledge like this when using the configure script, and so we 
    aren't listing both variants. Sometimes we do list the negated version 
    in the help text when that's the more obviously useful option. Perhaps 
    that should have been done in this case as disabling gtest was the more 
    common user option (as enabled was default).
    
    /Erik
    
    On 2020-07-17 23:17, jiefu(??) wrote:
    > Hi all,
    >
    > May I get reviews for this change?
    >
    > JBS:    https://bugs.openjdk.java.net/browse/JDK-8249704
    > Webrev: http://cr.openjdk.java.net/~jiefu/8249704/webrev.00/
    >
    > Thanks a lot.
    > Best regards,
    > Jie
    
    


From magnus.ihse.bursie at oracle.com  Tue Jul 21 12:17:07 2020
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 21 Jul 2020 14:17:07 +0200
Subject: RFR: 8249704: UTIL_DEPRECATED_ARG_ENABLE dumps incorrect warning
 message
In-Reply-To: <eaf6d136-bd88-e921-91a8-763c9535e40a@oracle.com>
References: <8299D8CB-AB4D-498B-A5E2-6BB2EDBEE0BF@tencent.com>
 <eaf6d136-bd88-e921-91a8-763c9535e40a@oracle.com>
Message-ID: <81DD0EFF-DF96-4984-8DDB-DE185D609350@oracle.com>


> 20 juli 2020 kl. 15:32 skrev Erik Joelsson <erik.joelsson at oracle.com>:
> 
> Hello Jie,
> 
> Your change looks fine if you really think this is a problem.
> 
> However, in Autoconf all --enable-* options have a corresponding --disable-* (and every --with-* has a --without-*). Always explicitly listing both in all help text would be very cumbersome and I think would need to be applied consistently if desired. We have assumed some basic autoconf knowledge like this when using the configure script, and so we aren't listing both variants. Sometimes we do list the negated version in the help text when that's the more obviously useful option.

Actually, we don?t do that anymore. I removed it since it just made things inconsistent. 

And I agree with Erik?s hesitation. I don?t think this is needed. 

/Magnus

> Perhaps that should have been done in this case as disabling gtest was the more common user option (as enabled was default).
> 
> /Erik
> 
>> On 2020-07-17 23:17, jiefu(??) wrote:
>> Hi all,
>> 
>> May I get reviews for this change?
>> 
>> JBS:    https://bugs.openjdk.java.net/browse/JDK-8249704
>> Webrev: http://cr.openjdk.java.net/~jiefu/8249704/webrev.00/
>> 
>> Thanks a lot.
>> Best regards,
>> Jie



From erik.joelsson at oracle.com  Tue Jul 21 19:24:43 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 21 Jul 2020 12:24:43 -0700
Subject: [15] RFR: JDK-8246094: [macos] Sound Recording and playback is not
 working
Message-ID: <2afd45c2-ba6d-b4fe-0e49-40d4b5d0e8a9@oracle.com>

Here is a late fix for Macos Catalina. In JDK-8244951, I added a missing 
entitlement to enable sound recording with the hardened runtime signing. 
It was later discovered that this wasn't quite enough. To be able to 
record sound you also need to specify a certain key in your Info.plist, 
NSMicrophoneUsageDescription. The value of this field is displayed to 
the user the first time the JDK wants to record sound. We also 
discovered that the way the JDK is laid out in the Macos specific bundle 
format, the global Info.plist is not actually considered when looking 
for this particular key, but rather the plist info we embed in the java 
executable.

This patch adds the new key to all the affected plists (JDK global, JRE 
global and the one being embedded in executables). We also noted that 
the bundle ID and version numbers had an effect on how this key was 
resolved, and to get somewhat better behavior, I'm also unifying the 
embedded values for those keys (which were hard coded today) with what 
we already put in the global Info.plist for the JDK. A followup bug 
where we more fully explore what the CFBundleIdentifier, CFBundleVersion 
and CFBundleShortVersionString values should actually be is planned for 
a later release.

With this fix, it's now verified possible to record sound on a Macos 
Catalina machine.

Webrev: http://cr.openjdk.java.net/~erikj/8246094/webrev.01/index.html

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

/Erik



From philip.race at oracle.com  Tue Jul 21 20:10:32 2020
From: philip.race at oracle.com (Philip Race)
Date: Tue, 21 Jul 2020 13:10:32 -0700
Subject: <Sound Dev> [15] RFR: JDK-8246094: [macos] Sound Recording and
 playback is not working
In-Reply-To: <2afd45c2-ba6d-b4fe-0e49-40d4b5d0e8a9@oracle.com>
References: <2afd45c2-ba6d-b4fe-0e49-40d4b5d0e8a9@oracle.com>
Message-ID: <5F174BB8.6020106@oracle.com>

LGTM.

-phil

On 7/21/20, 12:24 PM, Erik Joelsson wrote:
> Here is a late fix for Macos Catalina. In JDK-8244951, I added a 
> missing entitlement to enable sound recording with the hardened 
> runtime signing. It was later discovered that this wasn't quite 
> enough. To be able to record sound you also need to specify a certain 
> key in your Info.plist, NSMicrophoneUsageDescription. The value of 
> this field is displayed to the user the first time the JDK wants to 
> record sound. We also discovered that the way the JDK is laid out in 
> the Macos specific bundle format, the global Info.plist is not 
> actually considered when looking for this particular key, but rather 
> the plist info we embed in the java executable.
>
> This patch adds the new key to all the affected plists (JDK global, 
> JRE global and the one being embedded in executables). We also noted 
> that the bundle ID and version numbers had an effect on how this key 
> was resolved, and to get somewhat better behavior, I'm also unifying 
> the embedded values for those keys (which were hard coded today) with 
> what we already put in the global Info.plist for the JDK. A followup 
> bug where we more fully explore what the CFBundleIdentifier, 
> CFBundleVersion and CFBundleShortVersionString values should actually 
> be is planned for a later release.
>
> With this fix, it's now verified possible to record sound on a Macos 
> Catalina machine.
>
> Webrev: http://cr.openjdk.java.net/~erikj/8246094/webrev.01/index.html
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8246094
>
> /Erik
>


From Sergey.Bylokhov at oracle.com  Tue Jul 21 20:33:50 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 21 Jul 2020 13:33:50 -0700
Subject: <Sound Dev> [15] RFR: JDK-8246094: [macos] Sound Recording and
 playback is not working
In-Reply-To: <2afd45c2-ba6d-b4fe-0e49-40d4b5d0e8a9@oracle.com>
References: <2afd45c2-ba6d-b4fe-0e49-40d4b5d0e8a9@oracle.com>
Message-ID: <9445568f-5b27-237e-c0dd-787a50a111db@oracle.com>

+1

On 21.07.2020 12:24, Erik Joelsson wrote:
> Here is a late fix for Macos Catalina. In JDK-8244951, I added a missing entitlement to enable sound recording with the hardened runtime signing. It was later discovered that this wasn't quite enough. To be able to record sound you also need to specify a certain key in your Info.plist, NSMicrophoneUsageDescription. The value of this field is displayed to the user the first time the JDK wants to record sound. We also discovered that the way the JDK is laid out in the Macos specific bundle format, the global Info.plist is not actually considered when looking for this particular key, but rather the plist info we embed in the java executable.
> 
> This patch adds the new key to all the affected plists (JDK global, JRE global and the one being embedded in executables). We also noted that the bundle ID and version numbers had an effect on how this key was resolved, and to get somewhat better behavior, I'm also unifying the embedded values for those keys (which were hard coded today) with what we already put in the global Info.plist for the JDK. A followup bug where we more fully explore what the CFBundleIdentifier, CFBundleVersion and CFBundleShortVersionString values should actually be is planned for a later release.
> 
> With this fix, it's now verified possible to record sound on a Macos Catalina machine.
> 
> Webrev: http://cr.openjdk.java.net/~erikj/8246094/webrev.01/index.html
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8246094
> 
> /Erik
> 


-- 
Best regards, Sergey.


From philip.race at oracle.com  Tue Jul 21 21:39:08 2020
From: philip.race at oracle.com (Philip Race)
Date: Tue, 21 Jul 2020 14:39:08 -0700
Subject: RFR: 8249821: Separate libharfbuzz from libfontmanager
Message-ID: <5F17607C.20501@oracle.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8249821
Webrev: http://cr.openjdk.java.net/~prr/8249821/

This fix breaks out libharfbuzz from libfontmanager.
As well as building I've done extensive testing on all platforms.

I have tweaked the disabled warnings so we don't have un-needed duplication
but it is not a goal of this fix to resolve them.
There's a bug (JDK-8074844) already filed to resolve them for 
fontmanager and
that should be easier to fix now.

-phil.





From erik.joelsson at oracle.com  Tue Jul 21 22:03:28 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 21 Jul 2020 15:03:28 -0700
Subject: RFR: 8249821: Separate libharfbuzz from libfontmanager
In-Reply-To: <5F17607C.20501@oracle.com>
References: <5F17607C.20501@oracle.com>
Message-ID: <350fcf5d-ed32-aeb5-4708-4f083af25dc2@oracle.com>

Hello Phil,

This looks pretty good, only some style nits.

Awt2dLibraries.gmk

428 and 466: These comments aren't relevant anymore now that harfbuzz is 
its own library.

434: Missed indent of 2

436: Too much indent (should be 2)

459-464: Too much indent

493-494: Too much indent

/Erik

On 2020-07-21 14:39, Philip Race wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8249821
> Webrev: http://cr.openjdk.java.net/~prr/8249821/
>
> This fix breaks out libharfbuzz from libfontmanager.
> As well as building I've done extensive testing on all platforms.
>
> I have tweaked the disabled warnings so we don't have un-needed 
> duplication
> but it is not a goal of this fix to resolve them.
> There's a bug (JDK-8074844) already filed to resolve them for 
> fontmanager and
> that should be easier to fix now.
>
> -phil.
>
>
>


From philip.race at oracle.com  Tue Jul 21 22:18:18 2020
From: philip.race at oracle.com (Philip Race)
Date: Tue, 21 Jul 2020 15:18:18 -0700
Subject: RFR: 8249821: Separate libharfbuzz from libfontmanager
In-Reply-To: <350fcf5d-ed32-aeb5-4708-4f083af25dc2@oracle.com>
References: <5F17607C.20501@oracle.com>
 <350fcf5d-ed32-aeb5-4708-4f083af25dc2@oracle.com>
Message-ID: <5F1769AA.1000503@oracle.com>

Hi,

I noticed the indent problems at 434 & 436 myself once I looked at it as 
a webrev,
so I was already updating the fix with those but I've also fixed the 
rest you pointed out.
I've uploaded a new webrev with all of these resolved :-

http://cr.openjdk.java.net/~prr/8249821.1

-phil

On 7/21/20, 3:03 PM, Erik Joelsson wrote:
> Hello Phil,
>
> This looks pretty good, only some style nits.
>
> Awt2dLibraries.gmk
>
> 428 and 466: These comments aren't relevant anymore now that harfbuzz 
> is its own library.
>
> 434: Missed indent of 2
>
> 436: Too much indent (should be 2)
>
> 459-464: Too much indent
>
> 493-494: Too much indent
>
> /Erik
>
> On 2020-07-21 14:39, Philip Race wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8249821
>> Webrev: http://cr.openjdk.java.net/~prr/8249821/
>>
>> This fix breaks out libharfbuzz from libfontmanager.
>> As well as building I've done extensive testing on all platforms.
>>
>> I have tweaked the disabled warnings so we don't have un-needed 
>> duplication
>> but it is not a goal of this fix to resolve them.
>> There's a bug (JDK-8074844) already filed to resolve them for 
>> fontmanager and
>> that should be easier to fix now.
>>
>> -phil.
>>
>>
>>


From erik.joelsson at oracle.com  Wed Jul 22 12:45:08 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 22 Jul 2020 05:45:08 -0700
Subject: RFR: 8249821: Separate libharfbuzz from libfontmanager
In-Reply-To: <5F1769AA.1000503@oracle.com>
References: <5F17607C.20501@oracle.com>
 <350fcf5d-ed32-aeb5-4708-4f083af25dc2@oracle.com>
 <5F1769AA.1000503@oracle.com>
Message-ID: <66de937a-146a-202a-ad00-34b57a60d158@oracle.com>

Looks good, thanks!

/Erik

On 2020-07-21 15:18, Philip Race wrote:
> Hi,
>
> I noticed the indent problems at 434 & 436 myself once I looked at it 
> as a webrev,
> so I was already updating the fix with those but I've also fixed the 
> rest you pointed out.
> I've uploaded a new webrev with all of these resolved :-
>
> http://cr.openjdk.java.net/~prr/8249821.1
>
> -phil
>
> On 7/21/20, 3:03 PM, Erik Joelsson wrote:
>> Hello Phil,
>>
>> This looks pretty good, only some style nits.
>>
>> Awt2dLibraries.gmk
>>
>> 428 and 466: These comments aren't relevant anymore now that harfbuzz 
>> is its own library.
>>
>> 434: Missed indent of 2
>>
>> 436: Too much indent (should be 2)
>>
>> 459-464: Too much indent
>>
>> 493-494: Too much indent
>>
>> /Erik
>>
>> On 2020-07-21 14:39, Philip Race wrote:
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8249821
>>> Webrev: http://cr.openjdk.java.net/~prr/8249821/
>>>
>>> This fix breaks out libharfbuzz from libfontmanager.
>>> As well as building I've done extensive testing on all platforms.
>>>
>>> I have tweaked the disabled warnings so we don't have un-needed 
>>> duplication
>>> but it is not a goal of this fix to resolve them.
>>> There's a bug (JDK-8074844) already filed to resolve them for 
>>> fontmanager and
>>> that should be easier to fix now.
>>>
>>> -phil.
>>>
>>>
>>>


From ningsheng.jian at arm.com  Thu Jul 23 08:02:47 2020
From: ningsheng.jian at arm.com (Ningsheng Jian)
Date: Thu, 23 Jul 2020 16:02:47 +0800
Subject: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API
 (Incubator): AArch64 backend changes
In-Reply-To: <8c05d468-8753-b671-e3a9-92a7148f4f14@oracle.com>
References: <VI1PR0802MB2558C90ACF1189F17692FF278EB90@VI1PR0802MB2558.eurprd08.prod.outlook.com>
 <275eb57c-51c0-675e-c32a-91b198023559@redhat.com>
 <719F9169-ABC4-408E-B732-F1BD9A84337F@oracle.com>
 <9a13f5df-d946-579d-4282-917dc7338dc8@redhat.com>
 <09BC0693-80E0-4F87-855E-0B38A6F5EFA2@oracle.com>
 <668e500e-f621-5a2c-a41e-f73536880f73@redhat.com>
 <VI1PR0802MB255845256424F9EB4D5D81368EB30@VI1PR0802MB2558.eurprd08.prod.outlook.com>
 <1909fa9d-98bb-c2fb-45d8-540247d1ca8b@redhat.com>
 <VI1PR0802MB255895ADE9BC8D027EBB81048EB10@VI1PR0802MB2558.eurprd08.prod.outlook.com>
 <BYAPR11MB35438110FA50851942CE17A1EF950@BYAPR11MB3543.namprd11.prod.outlook.com>
 <HE1PR0802MB25542AE212E12FD3EF6D1BE48E6E0@HE1PR0802MB2554.eurprd08.prod.outlook.com>
 <2acbcc99-8dd4-b8f1-5982-1d439953c416@redhat.com>
 <VI1PR0802MB2558ECC61528694DBDFFF48F8E670@VI1PR0802MB2558.eurprd08.prod.outlook.com>
 <54d6b2b6-b79a-4700-981c-6ab33aca82f2@arm.com>
 <8c05d468-8753-b671-e3a9-92a7148f4f14@oracle.com>
Message-ID: <f588f038-669d-2320-9d3f-c12e6e9c1a66@arm.com>

Hi Vladimir,

Thanks for pointing out this. Yes, I missed that change in shared code. 
I've regenerated the webrev, with GensrcAdlc.gmk file change included:

http://cr.openjdk.java.net/~njian/vectorapi/8223347-integration/aarch64-webrev.01/

Also add build-dev.

Thanks,
Ningsheng

On 7/23/20 5:36 AM, Vladimir Ivanov wrote:
>> http://cr.openjdk.java.net/~njian/vectorapi/8223347-integration/aarch64-webrev.01/ 
> 
> 
> FTR there's one more aarch64-specific change in shared code to enable 
> aarch64_neon.ad processing:
> 
> diff --git a/make/hotspot/gensrc/GensrcAdlc.gmk 
> b/make/hotspot/gensrc/GensrcAdlc.gmk
> --- a/make/hotspot/gensrc/GensrcAdlc.gmk
> +++ b/make/hotspot/gensrc/GensrcAdlc.gmk
> @@ -129,6 +129,12 @@
> 
> $d/os_cpu/$(HOTSPOT_TARGET_OS)_$(HOTSPOT_TARGET_CPU_ARCH)/$(HOTSPOT_TARGET_OS)_$(HOTSPOT_TARGET_CPU_ARCH).ad 
> \
>  ???? )))
> 
> +? ifeq ($(HOTSPOT_TARGET_CPU_ARCH), aarch64)
> +??? AD_SRC_FILES += $(call uniq, $(wildcard $(foreach d, 
> $(AD_SRC_ROOTS), \
> + $d/cpu/$(HOTSPOT_TARGET_CPU_ARCH)/$(HOTSPOT_TARGET_CPU_ARCH)_neon.ad \
> +??? )))
> +? endif
> +
>  ?? ifeq ($(call check-jvm-feature, shenandoahgc), true)
>  ???? AD_SRC_FILES += $(call uniq, $(wildcard $(foreach d, 
> $(AD_SRC_ROOTS), \
> 
> $d/cpu/$(HOTSPOT_TARGET_CPU_ARCH)/gc/shenandoah/shenandoah_$(HOTSPOT_TARGET_CPU).ad 
> \
> 
> Best regards,
> Vladimir Ivanov
> 
>> On 7/8/20 3:05 PM, Yang Zhang wrote:
>>> Hi Andrew
>>>
>>> I have updated this patch. Could you please help to review it again?
>>> In this patch, the following changes are made:
>>> 1. Separate newly added NEON instructions to a new ad file
>>> ??? aarch64_neon.ad
>>> 2. Add assembler tests for NEON instructions. Trailing spaces
>>> ??? in the python script are also removed.
>>>
>>> http://cr.openjdk.java.net/~yzhang/vectorapi/vectorapi.rfr/aarch64_webrev/webrev.02/ 
>>>
>>>
>>> Thanks,
>>> Yang
>>>
>>>
>>> -----Original Message-----
>>> From: Andrew Haley <aph at redhat.com>
>>> Sent: Tuesday, June 30, 2020 12:10 AM
>>> To: Yang Zhang <Yang.Zhang at arm.com>; Viswanathan, Sandhya 
>>> <sandhya.viswanathan at intel.com>; Paul Sandoz <paul.sandoz at oracle.com>
>>> Cc: nd <nd at arm.com>; hotspot-compiler-dev at openjdk.java.net; 
>>> hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; 
>>> aarch64-port-dev at openjdk.java.net
>>> Subject: Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of 
>>> Vector API (Incubator): AArch64 backend changes
>>>
>>> On 29/06/2020 08:48, Yang Zhang wrote:
>>>> 1. Instructions that can be matched with NEON instructions directly.
>>>> MulVB, SqrtVF and AbsV have been merged into jdk master already.
>>>>
>>>> 2. Instructions that jdk master has middle end support for, but they 
>>>> cannot be matched with NEON instructions directly.
>>>> Such as AddReductionVL, MulReductionVL, And/Or/XorReductionV These 
>>>> new instructions can be moved into jdk master first, but for 
>>>> auto-vectorization, the performance might not get improved.
>>>>
>>>> 3. Panama/Vector API specific? instructions such as Load/StoreVector 
>>>> ( 16 bits), VectorReinterpret, VectorMaskCmp, MaxV/MinV, VectorBlend 
>>>> etc.
>>>> These instructions cannot be moved into jdk master first because 
>>>> there isn't middle-end support.
>>>>
>>>> I will put 2 and 3 in a new ad file aarch64_neon.ad. I will also 
>>>> update aarch64_asmtest.py and macroassemler.cpp. When the patch is 
>>>> ready, I will send it again.
>>>
>>> Thank you *very* much for your hard work. Appreciated!
>>>
>>> -- 
>>> Andrew Haley? (he/him)
>>> Java Platform Lead Engineer
>>> Red Hat UK Ltd. <https://www.redhat.com> https://keybase.io/andrewhaley
>>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>>>
>>



From erik.joelsson at oracle.com  Thu Jul 23 13:06:22 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 23 Jul 2020 06:06:22 -0700
Subject: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API
 (Incubator): AArch64 backend changes
In-Reply-To: <f588f038-669d-2320-9d3f-c12e6e9c1a66@arm.com>
References: <VI1PR0802MB2558C90ACF1189F17692FF278EB90@VI1PR0802MB2558.eurprd08.prod.outlook.com>
 <719F9169-ABC4-408E-B732-F1BD9A84337F@oracle.com>
 <9a13f5df-d946-579d-4282-917dc7338dc8@redhat.com>
 <09BC0693-80E0-4F87-855E-0B38A6F5EFA2@oracle.com>
 <668e500e-f621-5a2c-a41e-f73536880f73@redhat.com>
 <VI1PR0802MB255845256424F9EB4D5D81368EB30@VI1PR0802MB2558.eurprd08.prod.outlook.com>
 <1909fa9d-98bb-c2fb-45d8-540247d1ca8b@redhat.com>
 <VI1PR0802MB255895ADE9BC8D027EBB81048EB10@VI1PR0802MB2558.eurprd08.prod.outlook.com>
 <BYAPR11MB35438110FA50851942CE17A1EF950@BYAPR11MB3543.namprd11.prod.outlook.com>
 <HE1PR0802MB25542AE212E12FD3EF6D1BE48E6E0@HE1PR0802MB2554.eurprd08.prod.outlook.com>
 <2acbcc99-8dd4-b8f1-5982-1d439953c416@redhat.com>
 <VI1PR0802MB2558ECC61528694DBDFFF48F8E670@VI1PR0802MB2558.eurprd08.prod.outlook.com>
 <54d6b2b6-b79a-4700-981c-6ab33aca82f2@arm.com>
 <8c05d468-8753-b671-e3a9-92a7148f4f14@oracle.com>
 <f588f038-669d-2320-9d3f-c12e6e9c1a66@arm.com>
Message-ID: <2bc029fc-2823-18ac-9aa0-1a8edd7f9094@oracle.com>

Hello Ningsheng,

Build change looks good.

/Erik

On 2020-07-23 01:02, Ningsheng Jian wrote:
> Hi Vladimir,
>
> Thanks for pointing out this. Yes, I missed that change in shared 
> code. I've regenerated the webrev, with GensrcAdlc.gmk file change 
> included:
>
> http://cr.openjdk.java.net/~njian/vectorapi/8223347-integration/aarch64-webrev.01/ 
>
>
> Also add build-dev.
>
> Thanks,
> Ningsheng
>
> On 7/23/20 5:36 AM, Vladimir Ivanov wrote:
>>> http://cr.openjdk.java.net/~njian/vectorapi/8223347-integration/aarch64-webrev.01/ 
>>
>>
>>
>> FTR there's one more aarch64-specific change in shared code to enable 
>> aarch64_neon.ad processing:
>>
>> diff --git a/make/hotspot/gensrc/GensrcAdlc.gmk 
>> b/make/hotspot/gensrc/GensrcAdlc.gmk
>> --- a/make/hotspot/gensrc/GensrcAdlc.gmk
>> +++ b/make/hotspot/gensrc/GensrcAdlc.gmk
>> @@ -129,6 +129,12 @@
>>
>> $d/os_cpu/$(HOTSPOT_TARGET_OS)_$(HOTSPOT_TARGET_CPU_ARCH)/$(HOTSPOT_TARGET_OS)_$(HOTSPOT_TARGET_CPU_ARCH).ad 
>> \
>> ????? )))
>>
>> +? ifeq ($(HOTSPOT_TARGET_CPU_ARCH), aarch64)
>> +??? AD_SRC_FILES += $(call uniq, $(wildcard $(foreach d, 
>> $(AD_SRC_ROOTS), \
>> + $d/cpu/$(HOTSPOT_TARGET_CPU_ARCH)/$(HOTSPOT_TARGET_CPU_ARCH)_neon.ad \
>> +??? )))
>> +? endif
>> +
>> ??? ifeq ($(call check-jvm-feature, shenandoahgc), true)
>> ????? AD_SRC_FILES += $(call uniq, $(wildcard $(foreach d, 
>> $(AD_SRC_ROOTS), \
>>
>> $d/cpu/$(HOTSPOT_TARGET_CPU_ARCH)/gc/shenandoah/shenandoah_$(HOTSPOT_TARGET_CPU).ad 
>> \
>>
>> Best regards,
>> Vladimir Ivanov
>>
>>> On 7/8/20 3:05 PM, Yang Zhang wrote:
>>>> Hi Andrew
>>>>
>>>> I have updated this patch. Could you please help to review it again?
>>>> In this patch, the following changes are made:
>>>> 1. Separate newly added NEON instructions to a new ad file
>>>> ??? aarch64_neon.ad
>>>> 2. Add assembler tests for NEON instructions. Trailing spaces
>>>> ??? in the python script are also removed.
>>>>
>>>> http://cr.openjdk.java.net/~yzhang/vectorapi/vectorapi.rfr/aarch64_webrev/webrev.02/ 
>>>>
>>>>
>>>> Thanks,
>>>> Yang
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Andrew Haley <aph at redhat.com>
>>>> Sent: Tuesday, June 30, 2020 12:10 AM
>>>> To: Yang Zhang <Yang.Zhang at arm.com>; Viswanathan, Sandhya 
>>>> <sandhya.viswanathan at intel.com>; Paul Sandoz <paul.sandoz at oracle.com>
>>>> Cc: nd <nd at arm.com>; hotspot-compiler-dev at openjdk.java.net; 
>>>> hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; 
>>>> aarch64-port-dev at openjdk.java.net
>>>> Subject: Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of 
>>>> Vector API (Incubator): AArch64 backend changes
>>>>
>>>> On 29/06/2020 08:48, Yang Zhang wrote:
>>>>> 1. Instructions that can be matched with NEON instructions directly.
>>>>> MulVB, SqrtVF and AbsV have been merged into jdk master already.
>>>>>
>>>>> 2. Instructions that jdk master has middle end support for, but 
>>>>> they cannot be matched with NEON instructions directly.
>>>>> Such as AddReductionVL, MulReductionVL, And/Or/XorReductionV These 
>>>>> new instructions can be moved into jdk master first, but for 
>>>>> auto-vectorization, the performance might not get improved.
>>>>>
>>>>> 3. Panama/Vector API specific? instructions such as 
>>>>> Load/StoreVector ( 16 bits), VectorReinterpret, VectorMaskCmp, 
>>>>> MaxV/MinV, VectorBlend etc.
>>>>> These instructions cannot be moved into jdk master first because 
>>>>> there isn't middle-end support.
>>>>>
>>>>> I will put 2 and 3 in a new ad file aarch64_neon.ad. I will also 
>>>>> update aarch64_asmtest.py and macroassemler.cpp. When the patch is 
>>>>> ready, I will send it again.
>>>>
>>>> Thank you *very* much for your hard work. Appreciated!
>>>>
>>>> -- 
>>>> Andrew Haley? (he/him)
>>>> Java Platform Lead Engineer
>>>> Red Hat UK Ltd. <https://www.redhat.com> 
>>>> https://keybase.io/andrewhaley
>>>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>>>>
>>>
>


From mark.reinhold at oracle.com  Thu Jul 23 17:11:26 2020
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 23 Jul 2020 10:11:26 -0700
Subject: 15 RFR (XXS) 8250216: The README need not mention retrieving source
 code
Message-ID: <20200723101126.544547546@eggemoggin.niobe.net>

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

The README at the root of the source tree says, ?For information about
building the JDK, including how to retrieve all of the source code,
please see ...? yet we haven?t needed instructions on how to retrieve
the rest of the source code since JDK 10, when we consolidated
everything into a single repository.

(Also, the http://openjdk.java.net/ URL should be https://...)

Patch below.

Thanks,
- Mark

----

diff --git a/README b/README
--- a/README
+++ b/README
@@ -2,11 +2,10 @@
 Welcome to the JDK!
 ===================
 
-For information about building the JDK, including how to retrieve all
-of the source code, please see either of these files:
+For build instructions, please see either of these files:
 
   * doc/building.html   (html version)
   * doc/building.md     (markdown version)
 
-See http://openjdk.java.net/ for more information about the OpenJDK
+See https://openjdk.java.net/ for more information about the OpenJDK
 Community and the JDK.


From joe.darcy at oracle.com  Thu Jul 23 17:12:45 2020
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 23 Jul 2020 10:12:45 -0700
Subject: 15 RFR (XXS) 8250216: The README need not mention retrieving
 source code
In-Reply-To: <20200723101126.544547546@eggemoggin.niobe.net>
References: <20200723101126.544547546@eggemoggin.niobe.net>
Message-ID: <15da5f3d-fbce-45ae-e366-18b091902648@oracle.com>

Looks fine.

-Joe

On 7/23/2020 10:11 AM, mark.reinhold at oracle.com wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8250216
>
> The README at the root of the source tree says, ?For information about
> building the JDK, including how to retrieve all of the source code,
> please see ...? yet we haven?t needed instructions on how to retrieve
> the rest of the source code since JDK 10, when we consolidated
> everything into a single repository.
>
> (Also, the http://openjdk.java.net/ URL should be https://...)
>
> Patch below.
>
> Thanks,
> - Mark
>
> ----
>
> diff --git a/README b/README
> --- a/README
> +++ b/README
> @@ -2,11 +2,10 @@
>   Welcome to the JDK!
>   ===================
>   
> -For information about building the JDK, including how to retrieve all
> -of the source code, please see either of these files:
> +For build instructions, please see either of these files:
>   
>     * doc/building.html   (html version)
>     * doc/building.md     (markdown version)
>   
> -See http://openjdk.java.net/ for more information about the OpenJDK
> +See https://openjdk.java.net/ for more information about the OpenJDK
>   Community and the JDK.


From erik.joelsson at oracle.com  Thu Jul 23 17:15:25 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 23 Jul 2020 10:15:25 -0700
Subject: 15 RFR (XXS) 8250216: The README need not mention retrieving
 source code
In-Reply-To: <20200723101126.544547546@eggemoggin.niobe.net>
References: <20200723101126.544547546@eggemoggin.niobe.net>
Message-ID: <ea113615-d58c-97f3-3fe0-6f695b031ad6@oracle.com>

Looks good.

/Erik

On 2020-07-23 10:11, mark.reinhold at oracle.com wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8250216
>
> The README at the root of the source tree says, ?For information about
> building the JDK, including how to retrieve all of the source code,
> please see ...? yet we haven?t needed instructions on how to retrieve
> the rest of the source code since JDK 10, when we consolidated
> everything into a single repository.
>
> (Also, the http://openjdk.java.net/ URL should be https://...)
>
> Patch below.
>
> Thanks,
> - Mark
>
> ----
>
> diff --git a/README b/README
> --- a/README
> +++ b/README
> @@ -2,11 +2,10 @@
>   Welcome to the JDK!
>   ===================
>   
> -For information about building the JDK, including how to retrieve all
> -of the source code, please see either of these files:
> +For build instructions, please see either of these files:
>   
>     * doc/building.html   (html version)
>     * doc/building.md     (markdown version)
>   
> -See http://openjdk.java.net/ for more information about the OpenJDK
> +See https://openjdk.java.net/ for more information about the OpenJDK
>   Community and the JDK.


From iris.clark at oracle.com  Thu Jul 23 17:33:34 2020
From: iris.clark at oracle.com (Iris Clark)
Date: Thu, 23 Jul 2020 17:33:34 +0000 (UTC)
Subject: 15 RFR (XXS) 8250216: The README need not mention retrieving
 source code
In-Reply-To: <20200723101126.544547546@eggemoggin.niobe.net>
References: <20200723101126.544547546@eggemoggin.niobe.net>
Message-ID: <80e23558-58bc-4f89-98c2-e162ba1d2899@default>

Hi, Mark.

> Bug: https://bugs.openjdk.java.net/browse/JDK-8250216
> 
> [ ... ]
> 
> Patch below.

Looks good.

I think it would be nice if you could reference the JDK Project page (ojn/projects/jdk), not just ojn.

Thanks,
Iris


From mark.reinhold at oracle.com  Thu Jul 23 17:43:36 2020
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 23 Jul 2020 10:43:36 -0700
Subject: 15 RFR (XXS) 8250216: The README need not mention retrieving
 source code
In-Reply-To: <80e23558-58bc-4f89-98c2-e162ba1d2899@default>
References: <20200723101126.544547546@eggemoggin.niobe.net>
 <80e23558-58bc-4f89-98c2-e162ba1d2899@default>
Message-ID: <20200723104336.998057018@eggemoggin.niobe.net>

2020/7/23 10:33:34 -0700, iris.clark at oracle.com:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8250216
>> 
>> [ ... ]
>> 
>> Patch below.
> 
> Looks good.
> 
> I think it would be nice if you could reference the JDK Project page
> (ojn/projects/jdk), not just ojn.

Good idea ... but I just pushed the changeset.  I?ll fix that later.

- Mark


From iris.clark at oracle.com  Thu Jul 23 17:40:36 2020
From: iris.clark at oracle.com (Iris Clark)
Date: Thu, 23 Jul 2020 17:40:36 +0000 (UTC)
Subject: 15 RFR (XXS) 8250216: The README need not mention retrieving
 source code
In-Reply-To: <20200723104336.998057018@eggemoggin.niobe.net>
References: <20200723101126.544547546@eggemoggin.niobe.net>
 <80e23558-58bc-4f89-98c2-e162ba1d2899@default>
 <20200723104336.998057018@eggemoggin.niobe.net>
Message-ID: <ca07d403-6581-4dea-b239-66b461223c85@default>

Hi, Mark.

>> I think it would be nice if you could reference the JDK Project page 
>> (ojn/projects/jdk), not just ojn.
>
> Good idea ... but I just pushed the changeset.  I?ll fix that later.

Sorry for the late review.  You change wasn't there when I visited the README source and I haven't received the push notification yet.

Iris


From rkennke at redhat.com  Thu Jul 23 17:48:15 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Thu, 23 Jul 2020 19:48:15 +0200
Subject: RFR (16): JFR: Separate metadata per JVM-feature
Message-ID: <1ee4bd831287cd880cc3aabd6139f58a9744ed4d.camel@redhat.com>

This is a fall-out from my Shenandoah upstreaming work in JDK11, where
I made a similar change in order to separate-out Shenandoah parts from
JFR build when Shenandoah is disabled.

Currently, all JFR metadata is collected in a single metadata.xml file.
>From those, the build machinery generates headers and some other things
from it. For JVM-feature-specific metadata, this leads to stuff
generated that doesn't exist when the feature is excluded from the
build. For example, when disabling Shenandoah, we still need to compile
empty methods in jfrPeriodic.cpp to satisfy the generated code. 

The fix is to extend the code-generator to accept multiple metadata-
*.xml files and concatenate the parsing. The version in JDK16 accepts a
--xml $FILENAME argument, and I'm extending this to --xml
$FILENAME1:$FILENAME2:.. etc, i.e. multiple filenames separated by
colon. It allows empty filenames, e.g. metadata.xml::: would be parsed
as a single file metadata.xml files. That makes the build machinery
much simpler.

I also did the relevant metadata-separation for Shenandoah because that
is what I care about myself. If you'd like other parts treated the
same, just let me know.

Bug:
https://bugs.openjdk.java.net/browse/JDK-8250218
Webrev:
http://cr.openjdk.java.net/~rkennke/JDK-8250218/webrev.00/

Testing: build with and without Shenandoah, run some tests, I'd await
submit-repo results before pushing.

Can I please get a review?

Thanks!
Roman



From erik.gahlin at oracle.com  Thu Jul 23 18:30:20 2020
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Thu, 23 Jul 2020 20:30:20 +0200
Subject: RFR (16): JFR: Separate metadata per JVM-feature
In-Reply-To: <1ee4bd831287cd880cc3aabd6139f58a9744ed4d.camel@redhat.com>
References: <1ee4bd831287cd880cc3aabd6139f58a9744ed4d.camel@redhat.com>
Message-ID: <284EEA88-8165-482D-8FF6-9180E0A4C42A@oracle.com>

Hi Roman,

What is the problem you are trying to solve? 

Speed up compilation, or exclude metadata from recordings?

Having metadata per JVM-features adds complexity with little added benefit from what I can see. 

Thanks
Erik

> On 23 Jul 2020, at 19:48, Roman Kennke <rkennke at redhat.com> wrote:
> 
> This is a fall-out from my Shenandoah upstreaming work in JDK11, where
> I made a similar change in order to separate-out Shenandoah parts from
> JFR build when Shenandoah is disabled.
> 
> Currently, all JFR metadata is collected in a single metadata.xml file.
> From those, the build machinery generates headers and some other things
> from it. For JVM-feature-specific metadata, this leads to stuff
> generated that doesn't exist when the feature is excluded from the
> build. For example, when disabling Shenandoah, we still need to compile
> empty methods in jfrPeriodic.cpp to satisfy the generated code. 
> 
> The fix is to extend the code-generator to accept multiple metadata-
> *.xml files and concatenate the parsing. The version in JDK16 accepts a
> --xml $FILENAME argument, and I'm extending this to --xml
> $FILENAME1:$FILENAME2:.. etc, i.e. multiple filenames separated by
> colon. It allows empty filenames, e.g. metadata.xml::: would be parsed
> as a single file metadata.xml files. That makes the build machinery
> much simpler.
> 
> I also did the relevant metadata-separation for Shenandoah because that
> is what I care about myself. If you'd like other parts treated the
> same, just let me know.
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8250218
> Webrev:
> http://cr.openjdk.java.net/~rkennke/JDK-8250218/webrev.00/
> 
> Testing: build with and without Shenandoah, run some tests, I'd await
> submit-repo results before pushing.
> 
> Can I please get a review?
> 
> Thanks!
> Roman
> 



From rkennke at redhat.com  Thu Jul 23 20:29:01 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Thu, 23 Jul 2020 22:29:01 +0200
Subject: RFR (16): JFR: Separate metadata per JVM-feature
In-Reply-To: <284EEA88-8165-482D-8FF6-9180E0A4C42A@oracle.com>
References: <1ee4bd831287cd880cc3aabd6139f58a9744ed4d.camel@redhat.com>
 <284EEA88-8165-482D-8FF6-9180E0A4C42A@oracle.com>
Message-ID: <df5b61dbd9c077a42ed384011bf4db9fc5705783.camel@redhat.com>

Hi Erik,


> Hi Roman,
> 
> What is the problem you are trying to solve? 
> 

It is mostly an exercise in cleanliness. In the effort to upstream
Shenandoah GC to jdk11u (which is still ongoing), it has been asked to
make sure that build with Shenandoah excluded (--with-jvm-features=-
shenandoahgc) is identical to current build without Shenandoah patch.

The symbols and empty method(s) compiled in by JFR have been one of a
few places that needed some work. With this patch and a few more, I was
able to *prove mechanically* that the objects compiled by unpatched
JDK11u are byte-identical to patched JDK11u with Shenandoah disabled.

I thought I'd offer this here, maybe it's equally interesting going
forward. If it's agreed that it is not very interesting then be it - I
don't have a strong opinion about it.

Thanks & cheers,
Roman

> Having metadata per JVM-features adds complexity with little added
> benefit from what I can see. 


> Thanks
> Erik
> 
> > On 23 Jul 2020, at 19:48, Roman Kennke <rkennke at redhat.com> wrote:
> > 
> > This is a fall-out from my Shenandoah upstreaming work in JDK11,
> > where
> > I made a similar change in order to separate-out Shenandoah parts
> > from
> > JFR build when Shenandoah is disabled.
> > 
> > Currently, all JFR metadata is collected in a single metadata.xml
> > file.
> > From those, the build machinery generates headers and some other
> > things
> > from it. For JVM-feature-specific metadata, this leads to stuff
> > generated that doesn't exist when the feature is excluded from the
> > build. For example, when disabling Shenandoah, we still need to
> > compile
> > empty methods in jfrPeriodic.cpp to satisfy the generated code. 
> > 
> > The fix is to extend the code-generator to accept multiple
> > metadata-
> > *.xml files and concatenate the parsing. The version in JDK16
> > accepts a
> > --xml $FILENAME argument, and I'm extending this to --xml
> > $FILENAME1:$FILENAME2:.. etc, i.e. multiple filenames separated by
> > colon. It allows empty filenames, e.g. metadata.xml::: would be
> > parsed
> > as a single file metadata.xml files. That makes the build machinery
> > much simpler.
> > 
> > I also did the relevant metadata-separation for Shenandoah because
> > that
> > is what I care about myself. If you'd like other parts treated the
> > same, just let me know.
> > 
> > Bug:
> > https://bugs.openjdk.java.net/browse/JDK-8250218
> > Webrev:
> > http://cr.openjdk.java.net/~rkennke/JDK-8250218/webrev.00/
> > 
> > Testing: build with and without Shenandoah, run some tests, I'd
> > await
> > submit-repo results before pushing.
> > 
> > Can I please get a review?
> > 
> > Thanks!
> > Roman
> > 



From erik.gahlin at oracle.com  Thu Jul 23 21:50:38 2020
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Thu, 23 Jul 2020 23:50:38 +0200
Subject: RFR (16): JFR: Separate metadata per JVM-feature
In-Reply-To: <df5b61dbd9c077a42ed384011bf4db9fc5705783.camel@redhat.com>
References: <1ee4bd831287cd880cc3aabd6139f58a9744ed4d.camel@redhat.com>
 <284EEA88-8165-482D-8FF6-9180E0A4C42A@oracle.com>
 <df5b61dbd9c077a42ed384011bf4db9fc5705783.camel@redhat.com>
Message-ID: <25F033B8-AA04-4202-B60F-E9227F93D492@oracle.com>

Thanks for the explanation.

I think it would better to keep things as is going forward.

Erik

> On 23 Jul 2020, at 22:29, Roman Kennke <rkennke at redhat.com> wrote:
> 
> Hi Erik,
> 
> 
>> Hi Roman,
>> 
>> What is the problem you are trying to solve? 
>> 
> 
> It is mostly an exercise in cleanliness. In the effort to upstream
> Shenandoah GC to jdk11u (which is still ongoing), it has been asked to
> make sure that build with Shenandoah excluded (--with-jvm-features=-
> shenandoahgc) is identical to current build without Shenandoah patch.
> 
> The symbols and empty method(s) compiled in by JFR have been one of a
> few places that needed some work. With this patch and a few more, I was
> able to *prove mechanically* that the objects compiled by unpatched
> JDK11u are byte-identical to patched JDK11u with Shenandoah disabled.
> 
> I thought I'd offer this here, maybe it's equally interesting going
> forward. If it's agreed that it is not very interesting then be it - I
> don't have a strong opinion about it.
> 
> Thanks & cheers,
> Roman
> 
>> Having metadata per JVM-features adds complexity with little added
>> benefit from what I can see. 
> 
> 
>> Thanks
>> Erik
>> 
>>> On 23 Jul 2020, at 19:48, Roman Kennke <rkennke at redhat.com> wrote:
>>> 
>>> This is a fall-out from my Shenandoah upstreaming work in JDK11,
>>> where
>>> I made a similar change in order to separate-out Shenandoah parts
>>> from
>>> JFR build when Shenandoah is disabled.
>>> 
>>> Currently, all JFR metadata is collected in a single metadata.xml
>>> file.
>>> From those, the build machinery generates headers and some other
>>> things
>>> from it. For JVM-feature-specific metadata, this leads to stuff
>>> generated that doesn't exist when the feature is excluded from the
>>> build. For example, when disabling Shenandoah, we still need to
>>> compile
>>> empty methods in jfrPeriodic.cpp to satisfy the generated code. 
>>> 
>>> The fix is to extend the code-generator to accept multiple
>>> metadata-
>>> *.xml files and concatenate the parsing. The version in JDK16
>>> accepts a
>>> --xml $FILENAME argument, and I'm extending this to --xml
>>> $FILENAME1:$FILENAME2:.. etc, i.e. multiple filenames separated by
>>> colon. It allows empty filenames, e.g. metadata.xml::: would be
>>> parsed
>>> as a single file metadata.xml files. That makes the build machinery
>>> much simpler.
>>> 
>>> I also did the relevant metadata-separation for Shenandoah because
>>> that
>>> is what I care about myself. If you'd like other parts treated the
>>> same, just let me know.
>>> 
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8250218
>>> Webrev:
>>> http://cr.openjdk.java.net/~rkennke/JDK-8250218/webrev.00/
>>> 
>>> Testing: build with and without Shenandoah, run some tests, I'd
>>> await
>>> submit-repo results before pushing.
>>> 
>>> Can I please get a review?
>>> 
>>> Thanks!
>>> Roman
>>> 
> 



From erik.joelsson at oracle.com  Fri Jul 24 00:23:43 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 23 Jul 2020 17:23:43 -0700
Subject: RFR (16): JFR: Separate metadata per JVM-feature
In-Reply-To: <1ee4bd831287cd880cc3aabd6139f58a9744ed4d.camel@redhat.com>
References: <1ee4bd831287cd880cc3aabd6139f58a9744ed4d.camel@redhat.com>
Message-ID: <602da0d1-c6f9-1aeb-182b-c4c9e2eb6d34@oracle.com>

Build changes look ok to me. I would prefer if the long "COMMAND" line 
was broken up though as the side by side diff is already forcing a side 
scroll on my smaller monitor.

/Erik

On 2020-07-23 10:48, Roman Kennke wrote:
> This is a fall-out from my Shenandoah upstreaming work in JDK11, where
> I made a similar change in order to separate-out Shenandoah parts from
> JFR build when Shenandoah is disabled.
>
> Currently, all JFR metadata is collected in a single metadata.xml file.
>  From those, the build machinery generates headers and some other things
> from it. For JVM-feature-specific metadata, this leads to stuff
> generated that doesn't exist when the feature is excluded from the
> build. For example, when disabling Shenandoah, we still need to compile
> empty methods in jfrPeriodic.cpp to satisfy the generated code.
>
> The fix is to extend the code-generator to accept multiple metadata-
> *.xml files and concatenate the parsing. The version in JDK16 accepts a
> --xml $FILENAME argument, and I'm extending this to --xml
> $FILENAME1:$FILENAME2:.. etc, i.e. multiple filenames separated by
> colon. It allows empty filenames, e.g. metadata.xml::: would be parsed
> as a single file metadata.xml files. That makes the build machinery
> much simpler.
>
> I also did the relevant metadata-separation for Shenandoah because that
> is what I care about myself. If you'd like other parts treated the
> same, just let me know.
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8250218
> Webrev:
> http://cr.openjdk.java.net/~rkennke/JDK-8250218/webrev.00/
>
> Testing: build with and without Shenandoah, run some tests, I'd await
> submit-repo results before pushing.
>
> Can I please get a review?
>
> Thanks!
> Roman
>


From pavel.rappo at oracle.com  Fri Jul 24 09:34:30 2020
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Fri, 24 Jul 2020 10:34:30 +0100
Subject: RFR docs 8240777: Update all nroff manpages for JDK 15 release
In-Reply-To: <c7079ff7-1e8e-5b8b-3b3b-f6b3b0a95513@oracle.com>
References: <C32D0B83-C6A3-479E-9844-415415A593BF@oracle.com>
 <90e590db-bdd5-c10d-0d42-e28c623602dc@oracle.com>
 <449E470E-2E66-40A5-8C3B-CC3C7E0D2AD2@oracle.com>
 <c7079ff7-1e8e-5b8b-3b3b-f6b3b0a95513@oracle.com>
Message-ID: <9449D196-C55F-40AE-9AA4-63CAEAC545EF@oracle.com>

Please review the updated webrev:

    http://cr.openjdk.java.net/~prappo/8240777/webrev.01/

> On 24 Jun 2020, at 10:48, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Pavel,
> 
> On 24/06/2020 7:35 pm, Pavel Rappo wrote:
>> David,
>> I'm planning to review and push manpage changes that will have accumulate by Rampdown Phase Two, which is on 2020-07-16. Any updates after that date could be performed by the component owners themselves; I think this is reasonable, would you agree?
> 
> Okay sounds reasonable.
> 
> Thanks,
> David
> 
>> -Pavel
>>> On 11 Jun 2020, at 03:42, David Holmes <david.holmes at oracle.com> wrote:
>>> 
>>> Hi Pavel,
>>> 
>>> This issue can't be closed out yet as we are only at ramp down phase 1. There are still documentation changes coming that will need the manpages to be updated again before JDK 15 is released.
>>> 
>>> David
>>> 
>>> On 11/06/2020 5:21 am, Pavel Rappo wrote:
>>>> Hello,
>>>> Please review the change for https://bugs.openjdk.java.net/browse/JDK-8240777
>>>>   http://cr.openjdk.java.net/~prappo/8240777/webrev.00/
>>>> This is supposed to be similar to the previous iteration:
>>>>   https://mail.openjdk.java.net/pipermail/build-dev/2020-January/026578.html
>>>> The only difference is that the copyright years are more accurate as they are restored from the original man pages.
>>>> -Pavel



From rkennke at redhat.com  Fri Jul 24 10:20:46 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Fri, 24 Jul 2020 12:20:46 +0200
Subject: RFR (16): JFR: Separate metadata per JVM-feature
In-Reply-To: <602da0d1-c6f9-1aeb-182b-c4c9e2eb6d34@oracle.com>
References: <1ee4bd831287cd880cc3aabd6139f58a9744ed4d.camel@redhat.com>
 <602da0d1-c6f9-1aeb-182b-c4c9e2eb6d34@oracle.com>
Message-ID: <7b4cebb6097185ee338d638a6844c14ddbf1dda2.camel@redhat.com>

Thanks, Erik. I can do those changes. But can we first agree with Erik
Gahlin if we want this change at all?

Thanks,
Roman

On Thu, 2020-07-23 at 17:23 -0700, Erik Joelsson wrote:
> Build changes look ok to me. I would prefer if the long "COMMAND"
> line 
> was broken up though as the side by side diff is already forcing a
> side 
> scroll on my smaller monitor.
> 
> /Erik
> 
> On 2020-07-23 10:48, Roman Kennke wrote:
> > This is a fall-out from my Shenandoah upstreaming work in JDK11,
> > where
> > I made a similar change in order to separate-out Shenandoah parts
> > from
> > JFR build when Shenandoah is disabled.
> > 
> > Currently, all JFR metadata is collected in a single metadata.xml
> > file.
> >  From those, the build machinery generates headers and some other
> > things
> > from it. For JVM-feature-specific metadata, this leads to stuff
> > generated that doesn't exist when the feature is excluded from the
> > build. For example, when disabling Shenandoah, we still need to
> > compile
> > empty methods in jfrPeriodic.cpp to satisfy the generated code.
> > 
> > The fix is to extend the code-generator to accept multiple
> > metadata-
> > *.xml files and concatenate the parsing. The version in JDK16
> > accepts a
> > --xml $FILENAME argument, and I'm extending this to --xml
> > $FILENAME1:$FILENAME2:.. etc, i.e. multiple filenames separated by
> > colon. It allows empty filenames, e.g. metadata.xml::: would be
> > parsed
> > as a single file metadata.xml files. That makes the build machinery
> > much simpler.
> > 
> > I also did the relevant metadata-separation for Shenandoah because
> > that
> > is what I care about myself. If you'd like other parts treated the
> > same, just let me know.
> > 
> > Bug:
> > https://bugs.openjdk.java.net/browse/JDK-8250218
> > Webrev:
> > http://cr.openjdk.java.net/~rkennke/JDK-8250218/webrev.00/
> > 
> > Testing: build with and without Shenandoah, run some tests, I'd
> > await
> > submit-repo results before pushing.
> > 
> > Can I please get a review?
> > 
> > Thanks!
> > Roman
> > 



From lance.andersen at oracle.com  Fri Jul 24 10:28:32 2020
From: lance.andersen at oracle.com (Lance @ Oracle)
Date: Fri, 24 Jul 2020 06:28:32 -0400
Subject: RFR docs 8240777: Update all nroff manpages for JDK 15 release
In-Reply-To: <9449D196-C55F-40AE-9AA4-63CAEAC545EF@oracle.com>
References: <9449D196-C55F-40AE-9AA4-63CAEAC545EF@oracle.com>
Message-ID: <A29C2187-9DA4-4B4B-98E5-7B1B87FAFFC0@oracle.com>

Hi PaveL,

I made a pass through your web rev and had a couple quick questions:

Is there a reason we use macOS in some places and OS X in others as I would think we should be consistent throughout.

The notes regarding Jdk 10 that talk about adding support for the attach api that are being removed I was wondering if the information should be kept (or is this no longer valid) and just remove the jdk 10 specific reference?

Best,
Lance


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com
Sent from my iPad

> On Jul 24, 2020, at 5:34 AM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
> 
> ?Please review the updated webrev:
> 
>    http://cr.openjdk.java.net/~prappo/8240777/webrev.01/
> 
>> On 24 Jun 2020, at 10:48, David Holmes <david.holmes at oracle.com> wrote:
>> 
>> Hi Pavel,
>> 
>>> On 24/06/2020 7:35 pm, Pavel Rappo wrote:
>>> David,
>>> I'm planning to review and push manpage changes that will have accumulate by Rampdown Phase Two, which is on 2020-07-16. Any updates after that date could be performed by the component owners themselves; I think this is reasonable, would you agree?
>> 
>> Okay sounds reasonable.
>> 
>> Thanks,
>> David
>> 
>>> -Pavel
>>>> On 11 Jun 2020, at 03:42, David Holmes <david.holmes at oracle.com> wrote:
>>>> 
>>>> Hi Pavel,
>>>> 
>>>> This issue can't be closed out yet as we are only at ramp down phase 1. There are still documentation changes coming that will need the manpages to be updated again before JDK 15 is released.
>>>> 
>>>> David
>>>> 
>>>> On 11/06/2020 5:21 am, Pavel Rappo wrote:
>>>>> Hello,
>>>>> Please review the change for https://bugs.openjdk.java.net/browse/JDK-8240777
>>>>>  http://cr.openjdk.java.net/~prappo/8240777/webrev.00/
>>>>> This is supposed to be similar to the previous iteration:
>>>>>  https://mail.openjdk.java.net/pipermail/build-dev/2020-January/026578.html
>>>>> The only difference is that the copyright years are more accurate as they are restored from the original man pages.
>>>>> -Pavel
> 


From pavel.rappo at oracle.com  Fri Jul 24 11:21:50 2020
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Fri, 24 Jul 2020 12:21:50 +0100
Subject: RFR docs 8240777: Update all nroff manpages for JDK 15 release
In-Reply-To: <A29C2187-9DA4-4B4B-98E5-7B1B87FAFFC0@oracle.com>
References: <9449D196-C55F-40AE-9AA4-63CAEAC545EF@oracle.com>
 <A29C2187-9DA4-4B4B-98E5-7B1B87FAFFC0@oracle.com>
Message-ID: <76897BBA-1E7B-48DF-8AD2-581E463D26EB@oracle.com>

Lance,

Those are good questions that show that there's value in seeing all the changes to the man pages at once. Let's ask experts in the corresponding areas.

-Pavel

> On 24 Jul 2020, at 11:28, Lance @ Oracle <lance.andersen at oracle.com> wrote:
> 
> Hi PaveL,
> 
> I made a pass through your web rev and had a couple quick questions:
> 
> Is there a reason we use macOS in some places and OS X in others as I would think we should be consistent throughout.
> 
> The notes regarding Jdk 10 that talk about adding support for the attach api that are being removed I was wondering if the information should be kept (or is this no longer valid) and just remove the jdk 10 specific reference?
> 
> Best,
> Lance
> 
> 
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering 
> 1 Network Drive 
> Burlington, MA 01803
> Lance.Andersen at oracle.com
> Sent from my iPad
> 
>> On Jul 24, 2020, at 5:34 AM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>> 
>> ?Please review the updated webrev:
>> 
>>    http://cr.openjdk.java.net/~prappo/8240777/webrev.01/
>> 
>>> On 24 Jun 2020, at 10:48, David Holmes <david.holmes at oracle.com> wrote:
>>> 
>>> Hi Pavel,
>>> 
>>> On 24/06/2020 7:35 pm, Pavel Rappo wrote:
>>>> David,
>>>> I'm planning to review and push manpage changes that will have accumulate by Rampdown Phase Two, which is on 2020-07-16. Any updates after that date could be performed by the component owners themselves; I think this is reasonable, would you agree?
>>> 
>>> Okay sounds reasonable.
>>> 
>>> Thanks,
>>> David
>>> 
>>>> -Pavel
>>>>> On 11 Jun 2020, at 03:42, David Holmes <david.holmes at oracle.com> wrote:
>>>>> 
>>>>> Hi Pavel,
>>>>> 
>>>>> This issue can't be closed out yet as we are only at ramp down phase 1. There are still documentation changes coming that will need the manpages to be updated again before JDK 15 is released.
>>>>> 
>>>>> David
>>>>> 
>>>>> On 11/06/2020 5:21 am, Pavel Rappo wrote:
>>>>>> Hello,
>>>>>> Please review the change for https://bugs.openjdk.java.net/browse/JDK-8240777
>>>>>>  http://cr.openjdk.java.net/~prappo/8240777/webrev.00/
>>>>>> This is supposed to be similar to the previous iteration:
>>>>>>  https://mail.openjdk.java.net/pipermail/build-dev/2020-January/026578.html
>>>>>> The only difference is that the copyright years are more accurate as they are restored from the original man pages.
>>>>>> -Pavel
>> 



From david.holmes at oracle.com  Fri Jul 24 12:19:41 2020
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 24 Jul 2020 22:19:41 +1000
Subject: RFR docs 8240777: Update all nroff manpages for JDK 15 release
In-Reply-To: <9449D196-C55F-40AE-9AA4-63CAEAC545EF@oracle.com>
References: <C32D0B83-C6A3-479E-9844-415415A593BF@oracle.com>
 <90e590db-bdd5-c10d-0d42-e28c623602dc@oracle.com>
 <449E470E-2E66-40A5-8C3B-CC3C7E0D2AD2@oracle.com>
 <c7079ff7-1e8e-5b8b-3b3b-f6b3b0a95513@oracle.com>
 <9449D196-C55F-40AE-9AA4-63CAEAC545EF@oracle.com>
Message-ID: <d52648dc-0235-d106-79ab-2c1bfa811e01@oracle.com>

Hi Pavel,

The bulk update/conversion of the manpages looks good.

Thanks,
David

On 24/07/2020 7:34 pm, Pavel Rappo wrote:
> Please review the updated webrev:
> 
>      http://cr.openjdk.java.net/~prappo/8240777/webrev.01/
> 
>> On 24 Jun 2020, at 10:48, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Hi Pavel,
>>
>> On 24/06/2020 7:35 pm, Pavel Rappo wrote:
>>> David,
>>> I'm planning to review and push manpage changes that will have accumulate by Rampdown Phase Two, which is on 2020-07-16. Any updates after that date could be performed by the component owners themselves; I think this is reasonable, would you agree?
>>
>> Okay sounds reasonable.
>>
>> Thanks,
>> David
>>
>>> -Pavel
>>>> On 11 Jun 2020, at 03:42, David Holmes <david.holmes at oracle.com> wrote:
>>>>
>>>> Hi Pavel,
>>>>
>>>> This issue can't be closed out yet as we are only at ramp down phase 1. There are still documentation changes coming that will need the manpages to be updated again before JDK 15 is released.
>>>>
>>>> David
>>>>
>>>> On 11/06/2020 5:21 am, Pavel Rappo wrote:
>>>>> Hello,
>>>>> Please review the change for https://bugs.openjdk.java.net/browse/JDK-8240777
>>>>>    http://cr.openjdk.java.net/~prappo/8240777/webrev.00/
>>>>> This is supposed to be similar to the previous iteration:
>>>>>    https://mail.openjdk.java.net/pipermail/build-dev/2020-January/026578.html
>>>>> The only difference is that the copyright years are more accurate as they are restored from the original man pages.
>>>>> -Pavel
> 


From david.holmes at oracle.com  Fri Jul 24 12:21:38 2020
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 24 Jul 2020 22:21:38 +1000
Subject: RFR docs 8240777: Update all nroff manpages for JDK 15 release
In-Reply-To: <76897BBA-1E7B-48DF-8AD2-581E463D26EB@oracle.com>
References: <9449D196-C55F-40AE-9AA4-63CAEAC545EF@oracle.com>
 <A29C2187-9DA4-4B4B-98E5-7B1B87FAFFC0@oracle.com>
 <76897BBA-1E7B-48DF-8AD2-581E463D26EB@oracle.com>
Message-ID: <dec298c7-8a9f-89b4-aec0-c54b6ba2b32d@oracle.com>

Hi Lance,

Any issues with the content should result in JBS issues being filed 
against the appropriate component. Some of the manpages get more 
attention than others in terms of updates.

Thanks,
David

On 24/07/2020 9:21 pm, Pavel Rappo wrote:
> Lance,
> 
> Those are good questions that show that there's value in seeing all the changes to the man pages at once. Let's ask experts in the corresponding areas.
> 
> -Pavel
> 
>> On 24 Jul 2020, at 11:28, Lance @ Oracle <lance.andersen at oracle.com> wrote:
>>
>> Hi PaveL,
>>
>> I made a pass through your web rev and had a couple quick questions:
>>
>> Is there a reason we use macOS in some places and OS X in others as I would think we should be consistent throughout.
>>
>> The notes regarding Jdk 10 that talk about adding support for the attach api that are being removed I was wondering if the information should be kept (or is this no longer valid) and just remove the jdk 10 specific reference?
>>
>> Best,
>> Lance
>>
>>
>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering
>> 1 Network Drive
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com
>> Sent from my iPad
>>
>>> On Jul 24, 2020, at 5:34 AM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>>>
>>> ?Please review the updated webrev:
>>>
>>>     http://cr.openjdk.java.net/~prappo/8240777/webrev.01/
>>>
>>>> On 24 Jun 2020, at 10:48, David Holmes <david.holmes at oracle.com> wrote:
>>>>
>>>> Hi Pavel,
>>>>
>>>> On 24/06/2020 7:35 pm, Pavel Rappo wrote:
>>>>> David,
>>>>> I'm planning to review and push manpage changes that will have accumulate by Rampdown Phase Two, which is on 2020-07-16. Any updates after that date could be performed by the component owners themselves; I think this is reasonable, would you agree?
>>>>
>>>> Okay sounds reasonable.
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>> -Pavel
>>>>>> On 11 Jun 2020, at 03:42, David Holmes <david.holmes at oracle.com> wrote:
>>>>>>
>>>>>> Hi Pavel,
>>>>>>
>>>>>> This issue can't be closed out yet as we are only at ramp down phase 1. There are still documentation changes coming that will need the manpages to be updated again before JDK 15 is released.
>>>>>>
>>>>>> David
>>>>>>
>>>>>> On 11/06/2020 5:21 am, Pavel Rappo wrote:
>>>>>>> Hello,
>>>>>>> Please review the change for https://bugs.openjdk.java.net/browse/JDK-8240777
>>>>>>>   http://cr.openjdk.java.net/~prappo/8240777/webrev.00/
>>>>>>> This is supposed to be similar to the previous iteration:
>>>>>>>   https://mail.openjdk.java.net/pipermail/build-dev/2020-January/026578.html
>>>>>>> The only difference is that the copyright years are more accurate as they are restored from the original man pages.
>>>>>>> -Pavel
>>>
> 


From markus.gronlund at oracle.com  Fri Jul 24 12:23:27 2020
From: markus.gronlund at oracle.com (Markus Gronlund)
Date: Fri, 24 Jul 2020 05:23:27 -0700 (PDT)
Subject: RFR (16): JFR: Separate metadata per JVM-feature
In-Reply-To: <df5b61dbd9c077a42ed384011bf4db9fc5705783.camel@redhat.com>
References: <1ee4bd831287cd880cc3aabd6139f58a9744ed4d.camel@redhat.com>
 <284EEA88-8165-482D-8FF6-9180E0A4C42A@oracle.com>
 <df5b61dbd9c077a42ed384011bf4db9fc5705783.camel@redhat.com>
Message-ID: <0d393933-fd53-4f50-9627-76c949caf038@default>

Hi Roman,

Thanks for suggesting this, I understand what you are trying to prove, but I think the cost associated might not be warranted. The reason is that when we made JFR open source (JDK 11), we put a lot of engineering efforts into consolidation work for the JFR metadata to have it be described in a single place, metadata.xml. In the old system(s), there used to be many .xml (and .xslt) files scattered around, and it was quite painful to understand, manage and process them uniformly.

Unfortunately, this suggestion is a reminder of the old world, which have non-favorable connotations, so I would prefer if we can avoid doing this.

Thanks
Markus

-----Original Message-----
From: Roman Kennke <rkennke at redhat.com> 
Sent: den 23 juli 2020 22:29
To: Erik Gahlin <erik.gahlin at oracle.com>
Cc: hotspot-jfr-dev at openjdk.java.net; build-dev <build-dev at openjdk.java.net>
Subject: Re: RFR (16): JFR: Separate metadata per JVM-feature

Hi Erik,


> Hi Roman,
> 
> What is the problem you are trying to solve? 
> 

It is mostly an exercise in cleanliness. In the effort to upstream Shenandoah GC to jdk11u (which is still ongoing), it has been asked to make sure that build with Shenandoah excluded (--with-jvm-features=-
shenandoahgc) is identical to current build without Shenandoah patch.

The symbols and empty method(s) compiled in by JFR have been one of a few places that needed some work. With this patch and a few more, I was able to *prove mechanically* that the objects compiled by unpatched JDK11u are byte-identical to patched JDK11u with Shenandoah disabled.

I thought I'd offer this here, maybe it's equally interesting going forward. If it's agreed that it is not very interesting then be it - I don't have a strong opinion about it.

Thanks & cheers,
Roman

> Having metadata per JVM-features adds complexity with little added 
> benefit from what I can see.


> Thanks
> Erik
> 
> > On 23 Jul 2020, at 19:48, Roman Kennke <rkennke at redhat.com> wrote:
> > 
> > This is a fall-out from my Shenandoah upstreaming work in JDK11, 
> > where I made a similar change in order to separate-out Shenandoah 
> > parts from JFR build when Shenandoah is disabled.
> > 
> > Currently, all JFR metadata is collected in a single metadata.xml 
> > file.
> > From those, the build machinery generates headers and some other 
> > things from it. For JVM-feature-specific metadata, this leads to 
> > stuff generated that doesn't exist when the feature is excluded from 
> > the build. For example, when disabling Shenandoah, we still need to 
> > compile empty methods in jfrPeriodic.cpp to satisfy the generated 
> > code.
> > 
> > The fix is to extend the code-generator to accept multiple
> > metadata-
> > *.xml files and concatenate the parsing. The version in JDK16 
> > accepts a --xml $FILENAME argument, and I'm extending this to --xml 
> > $FILENAME1:$FILENAME2:.. etc, i.e. multiple filenames separated by 
> > colon. It allows empty filenames, e.g. metadata.xml::: would be 
> > parsed as a single file metadata.xml files. That makes the build 
> > machinery much simpler.
> > 
> > I also did the relevant metadata-separation for Shenandoah because 
> > that is what I care about myself. If you'd like other parts treated 
> > the same, just let me know.
> > 
> > Bug:
> > https://bugs.openjdk.java.net/browse/JDK-8250218
> > Webrev:
> > http://cr.openjdk.java.net/~rkennke/JDK-8250218/webrev.00/
> > 
> > Testing: build with and without Shenandoah, run some tests, I'd 
> > await submit-repo results before pushing.
> > 
> > Can I please get a review?
> > 
> > Thanks!
> > Roman
> > 



From rkennke at redhat.com  Fri Jul 24 16:40:43 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Fri, 24 Jul 2020 18:40:43 +0200
Subject: RFR (16): JFR: Separate metadata per JVM-feature
In-Reply-To: <0d393933-fd53-4f50-9627-76c949caf038@default>
References: <1ee4bd831287cd880cc3aabd6139f58a9744ed4d.camel@redhat.com>
 <284EEA88-8165-482D-8FF6-9180E0A4C42A@oracle.com>
 <df5b61dbd9c077a42ed384011bf4db9fc5705783.camel@redhat.com>
 <0d393933-fd53-4f50-9627-76c949caf038@default>
Message-ID: <26449baf1f368a771e5aefdfc767ef65d543bc18.camel@redhat.com>

Hi Markus,

Thank you for your insights. This is fine by me. As I already said in
reply to Erik Gahlin, I thought I'd offer this, but have no strong
opinion either way. I'll withdraw the RFR and Jire issue then.

Cheers,
Roman


> Hi Roman,
> 
> Thanks for suggesting this, I understand what you are trying to
> prove, but I think the cost associated might not be warranted. The
> reason is that when we made JFR open source (JDK 11), we put a lot of
> engineering efforts into consolidation work for the JFR metadata to
> have it be described in a single place, metadata.xml. In the old
> system(s), there used to be many .xml (and .xslt) files scattered
> around, and it was quite painful to understand, manage and process
> them uniformly.
> 
> Unfortunately, this suggestion is a reminder of the old world, which
> have non-favorable connotations, so I would prefer if we can avoid
> doing this.
> 
> Thanks
> Markus
> 
> -----Original Message-----
> From: Roman Kennke <rkennke at redhat.com> 
> Sent: den 23 juli 2020 22:29
> To: Erik Gahlin <erik.gahlin at oracle.com>
> Cc: hotspot-jfr-dev at openjdk.java.net; build-dev <
> build-dev at openjdk.java.net>
> Subject: Re: RFR (16): JFR: Separate metadata per JVM-feature
> 
> Hi Erik,
> 
> 
> > Hi Roman,
> > 
> > What is the problem you are trying to solve? 
> > 
> 
> It is mostly an exercise in cleanliness. In the effort to upstream
> Shenandoah GC to jdk11u (which is still ongoing), it has been asked
> to make sure that build with Shenandoah excluded (--with-jvm-
> features=-
> shenandoahgc) is identical to current build without Shenandoah patch.
> 
> The symbols and empty method(s) compiled in by JFR have been one of a
> few places that needed some work. With this patch and a few more, I
> was able to *prove mechanically* that the objects compiled by
> unpatched JDK11u are byte-identical to patched JDK11u with Shenandoah
> disabled.
> 
> I thought I'd offer this here, maybe it's equally interesting going
> forward. If it's agreed that it is not very interesting then be it -
> I don't have a strong opinion about it.
> 
> Thanks & cheers,
> Roman
> 
> > Having metadata per JVM-features adds complexity with little added 
> > benefit from what I can see.
> > Thanks
> > Erik
> > 
> > > On 23 Jul 2020, at 19:48, Roman Kennke <rkennke at redhat.com>
> > > wrote:
> > > 
> > > This is a fall-out from my Shenandoah upstreaming work in JDK11, 
> > > where I made a similar change in order to separate-out
> > > Shenandoah 
> > > parts from JFR build when Shenandoah is disabled.
> > > 
> > > Currently, all JFR metadata is collected in a single
> > > metadata.xml 
> > > file.
> > > From those, the build machinery generates headers and some other 
> > > things from it. For JVM-feature-specific metadata, this leads to 
> > > stuff generated that doesn't exist when the feature is excluded
> > > from 
> > > the build. For example, when disabling Shenandoah, we still need
> > > to 
> > > compile empty methods in jfrPeriodic.cpp to satisfy the
> > > generated 
> > > code.
> > > 
> > > The fix is to extend the code-generator to accept multiple
> > > metadata-
> > > *.xml files and concatenate the parsing. The version in JDK16 
> > > accepts a --xml $FILENAME argument, and I'm extending this to --
> > > xml 
> > > $FILENAME1:$FILENAME2:.. etc, i.e. multiple filenames separated
> > > by 
> > > colon. It allows empty filenames, e.g. metadata.xml::: would be 
> > > parsed as a single file metadata.xml files. That makes the build 
> > > machinery much simpler.
> > > 
> > > I also did the relevant metadata-separation for Shenandoah
> > > because 
> > > that is what I care about myself. If you'd like other parts
> > > treated 
> > > the same, just let me know.
> > > 
> > > Bug:
> > > https://bugs.openjdk.java.net/browse/JDK-8250218
> > > Webrev:
> > > http://cr.openjdk.java.net/~rkennke/JDK-8250218/webrev.00/
> > > 
> > > Testing: build with and without Shenandoah, run some tests, I'd 
> > > await submit-repo results before pushing.
> > > 
> > > Can I please get a review?
> > > 
> > > Thanks!
> > > Roman
> > > 



From joe.darcy at oracle.com  Fri Jul 24 21:38:26 2020
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 24 Jul 2020 14:38:26 -0700
Subject: JDK 16 RFR of JDK-8249219: Update --release 15 symbol information for
 JDK 15 build 33
Message-ID: <25fac426-f037-091f-4042-29f3d365de11@oracle.com>

Hello,

The fix for JDK-8248476 in JDK 15 b33 changed the symbol information 
used to represent --release 15 in JDK 16.

Please review the change to update the info:

 ??? http://cr.openjdk.java.net/~darcy/8249219.0/

Patch below; thanks,

-Joe

--- old/make/data/symbols/java.base-F.sym.txt??? 2020-07-24 
14:32:07.931767493 -0700
+++ new/make/data/symbols/java.base-F.sym.txt??? 2020-07-24 
14:32:07.255429494 -0700
@@ -69,6 +69,9 @@
 ?method name absExact descriptor (I)I flags 9
 ?method name absExact descriptor (J)J flags 9

+class name java/lang/NullPointerException
+method name fillInStackTrace descriptor ()Ljava/lang/Throwable; flags 21
+
 ?class name java/lang/Short
 ?header extends java/lang/Number implements 
java/lang/Comparable,java/lang/constant/Constable flags 31 signature 
Ljava/lang/Number;Ljava/lang/Comparable<Ljava/lang/Short;>;Ljava/lang/constant/Constable;
 ?method name describeConstable descriptor ()Ljava/util/Optional; flags 
1 signature 
()Ljava/util/Optional<Ljava/lang/constant/DynamicConstantDesc<Ljava/lang/Short;>;>;




From ningsheng.jian at arm.com  Mon Jul 27 01:58:38 2020
From: ningsheng.jian at arm.com (Ningsheng Jian)
Date: Mon, 27 Jul 2020 09:58:38 +0800
Subject: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API
 (Incubator): AArch64 backend changes
In-Reply-To: <2bc029fc-2823-18ac-9aa0-1a8edd7f9094@oracle.com>
References: <VI1PR0802MB2558C90ACF1189F17692FF278EB90@VI1PR0802MB2558.eurprd08.prod.outlook.com>
 <9a13f5df-d946-579d-4282-917dc7338dc8@redhat.com>
 <09BC0693-80E0-4F87-855E-0B38A6F5EFA2@oracle.com>
 <668e500e-f621-5a2c-a41e-f73536880f73@redhat.com>
 <VI1PR0802MB255845256424F9EB4D5D81368EB30@VI1PR0802MB2558.eurprd08.prod.outlook.com>
 <1909fa9d-98bb-c2fb-45d8-540247d1ca8b@redhat.com>
 <VI1PR0802MB255895ADE9BC8D027EBB81048EB10@VI1PR0802MB2558.eurprd08.prod.outlook.com>
 <BYAPR11MB35438110FA50851942CE17A1EF950@BYAPR11MB3543.namprd11.prod.outlook.com>
 <HE1PR0802MB25542AE212E12FD3EF6D1BE48E6E0@HE1PR0802MB2554.eurprd08.prod.outlook.com>
 <2acbcc99-8dd4-b8f1-5982-1d439953c416@redhat.com>
 <VI1PR0802MB2558ECC61528694DBDFFF48F8E670@VI1PR0802MB2558.eurprd08.prod.outlook.com>
 <54d6b2b6-b79a-4700-981c-6ab33aca82f2@arm.com>
 <8c05d468-8753-b671-e3a9-92a7148f4f14@oracle.com>
 <f588f038-669d-2320-9d3f-c12e6e9c1a66@arm.com>
 <2bc029fc-2823-18ac-9aa0-1a8edd7f9094@oracle.com>
Message-ID: <942c4be0-4f5d-acd6-86ae-e6769215ca37@arm.com>

Thank you Erik!

Regards,
Ningsheng

On 7/23/20 9:06 PM, Erik Joelsson wrote:
> Hello Ningsheng,
> 
> Build change looks good.
> 
> /Erik
> 
> On 2020-07-23 01:02, Ningsheng Jian wrote:
>> Hi Vladimir,
>>
>> Thanks for pointing out this. Yes, I missed that change in shared 
>> code. I've regenerated the webrev, with GensrcAdlc.gmk file change 
>> included:
>>
>> http://cr.openjdk.java.net/~njian/vectorapi/8223347-integration/aarch64-webrev.01/ 
>>
>>
>> Also add build-dev.
>>
>> Thanks,
>> Ningsheng
>>
>> On 7/23/20 5:36 AM, Vladimir Ivanov wrote:
>>>> http://cr.openjdk.java.net/~njian/vectorapi/8223347-integration/aarch64-webrev.01/ 
>>>
>>>
>>>
>>>
>>> FTR there's one more aarch64-specific change in shared code to enable 
>>> aarch64_neon.ad processing:
>>>
>>> diff --git a/make/hotspot/gensrc/GensrcAdlc.gmk 
>>> b/make/hotspot/gensrc/GensrcAdlc.gmk
>>> --- a/make/hotspot/gensrc/GensrcAdlc.gmk
>>> +++ b/make/hotspot/gensrc/GensrcAdlc.gmk
>>> @@ -129,6 +129,12 @@
>>>
>>> $d/os_cpu/$(HOTSPOT_TARGET_OS)_$(HOTSPOT_TARGET_CPU_ARCH)/$(HOTSPOT_TARGET_OS)_$(HOTSPOT_TARGET_CPU_ARCH).ad 
>>> \
>>> ????? )))
>>>
>>> +? ifeq ($(HOTSPOT_TARGET_CPU_ARCH), aarch64)
>>> +??? AD_SRC_FILES += $(call uniq, $(wildcard $(foreach d, 
>>> $(AD_SRC_ROOTS), \
>>> + $d/cpu/$(HOTSPOT_TARGET_CPU_ARCH)/$(HOTSPOT_TARGET_CPU_ARCH)_neon.ad \
>>> +??? )))
>>> +? endif
>>> +
>>> ??? ifeq ($(call check-jvm-feature, shenandoahgc), true)
>>> ????? AD_SRC_FILES += $(call uniq, $(wildcard $(foreach d, 
>>> $(AD_SRC_ROOTS), \
>>>
>>> $d/cpu/$(HOTSPOT_TARGET_CPU_ARCH)/gc/shenandoah/shenandoah_$(HOTSPOT_TARGET_CPU).ad 
>>> \
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>>
>>>> On 7/8/20 3:05 PM, Yang Zhang wrote:
>>>>> Hi Andrew
>>>>>
>>>>> I have updated this patch. Could you please help to review it again?
>>>>> In this patch, the following changes are made:
>>>>> 1. Separate newly added NEON instructions to a new ad file
>>>>> ??? aarch64_neon.ad
>>>>> 2. Add assembler tests for NEON instructions. Trailing spaces
>>>>> ??? in the python script are also removed.
>>>>>
>>>>> http://cr.openjdk.java.net/~yzhang/vectorapi/vectorapi.rfr/aarch64_webrev/webrev.02/ 
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Yang
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Andrew Haley <aph at redhat.com>
>>>>> Sent: Tuesday, June 30, 2020 12:10 AM
>>>>> To: Yang Zhang <Yang.Zhang at arm.com>; Viswanathan, Sandhya 
>>>>> <sandhya.viswanathan at intel.com>; Paul Sandoz <paul.sandoz at oracle.com>
>>>>> Cc: nd <nd at arm.com>; hotspot-compiler-dev at openjdk.java.net; 
>>>>> hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; 
>>>>> aarch64-port-dev at openjdk.java.net
>>>>> Subject: Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of 
>>>>> Vector API (Incubator): AArch64 backend changes
>>>>>
>>>>> On 29/06/2020 08:48, Yang Zhang wrote:
>>>>>> 1. Instructions that can be matched with NEON instructions directly.
>>>>>> MulVB, SqrtVF and AbsV have been merged into jdk master already.
>>>>>>
>>>>>> 2. Instructions that jdk master has middle end support for, but 
>>>>>> they cannot be matched with NEON instructions directly.
>>>>>> Such as AddReductionVL, MulReductionVL, And/Or/XorReductionV These 
>>>>>> new instructions can be moved into jdk master first, but for 
>>>>>> auto-vectorization, the performance might not get improved.
>>>>>>
>>>>>> 3. Panama/Vector API specific? instructions such as 
>>>>>> Load/StoreVector ( 16 bits), VectorReinterpret, VectorMaskCmp, 
>>>>>> MaxV/MinV, VectorBlend etc.
>>>>>> These instructions cannot be moved into jdk master first because 
>>>>>> there isn't middle-end support.
>>>>>>
>>>>>> I will put 2 and 3 in a new ad file aarch64_neon.ad. I will also 
>>>>>> update aarch64_asmtest.py and macroassemler.cpp. When the patch is 
>>>>>> ready, I will send it again.
>>>>>
>>>>> Thank you *very* much for your hard work. Appreciated!
>>>>>
>>>>> -- 
>>>>> Andrew Haley? (he/him)
>>>>> Java Platform Lead Engineer
>>>>> Red Hat UK Ltd. <https://www.redhat.com> 
>>>>> https://keybase.io/andrewhaley
>>>>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>>>>>
>>>>
>>



From shade at redhat.com  Mon Jul 27 07:28:20 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 27 Jul 2020 09:28:20 +0200
Subject: RFR (XS) 8250605: Linux x86_32 builds fail after JDK-8249821
Message-ID: <de25178d-770c-6ccb-35a1-2ef86dfd39b4@redhat.com>

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

I believe this happens because int-to-pointer-cast is now enabled for libfontmanager. Below is the
minimal fix, but I wonder if we should reinstate the disabled warning for clang (in the same manner)
and msvc (which warning code that one is?). Or we can wait for follow-up bug reports there...

Minimal fix:
  https://cr.openjdk.java.net/~shade/8250605/webrev.01/

Testing: Linux {x86_64, x86_32} builds; jdk-submit (running)

-- 
Thanks,
-Aleksey


From erik.joelsson at oracle.com  Mon Jul 27 12:41:23 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 27 Jul 2020 05:41:23 -0700
Subject: RFR (XS) 8250605: Linux x86_32 builds fail after JDK-8249821
In-Reply-To: <de25178d-770c-6ccb-35a1-2ef86dfd39b4@redhat.com>
References: <de25178d-770c-6ccb-35a1-2ef86dfd39b4@redhat.com>
Message-ID: <3dc7afbc-f776-a867-2920-24135ee11cea@oracle.com>

Looks good to me.

/Erik

On 2020-07-27 00:28, Aleksey Shipilev wrote:
> Bug:
>    https://bugs.openjdk.java.net/browse/JDK-8250605
>
> I believe this happens because int-to-pointer-cast is now enabled for libfontmanager. Below is the
> minimal fix, but I wonder if we should reinstate the disabled warning for clang (in the same manner)
> and msvc (which warning code that one is?). Or we can wait for follow-up bug reports there...
>
> Minimal fix:
>    https://cr.openjdk.java.net/~shade/8250605/webrev.01/
>
> Testing: Linux {x86_64, x86_32} builds; jdk-submit (running)
>


From philip.race at oracle.com  Mon Jul 27 16:53:02 2020
From: philip.race at oracle.com (Philip Race)
Date: Mon, 27 Jul 2020 09:53:02 -0700
Subject: [OpenJDK 2D-Dev] RFR (XS) 8250605: Linux x86_32 builds fail after
 JDK-8249821
In-Reply-To: <3dc7afbc-f776-a867-2920-24135ee11cea@oracle.com>
References: <de25178d-770c-6ccb-35a1-2ef86dfd39b4@redhat.com>
 <3dc7afbc-f776-a867-2920-24135ee11cea@oracle.com>
Message-ID: <5F1F066E.8010009@oracle.com>

OK .. although I hope to come back in JDK 16 and eliminate all disabled 
warnings
from the now much smaller libfontmanager :
https://bugs.openjdk.java.net/browse/JDK-8074844

-phil.


On 7/27/20, 5:41 AM, Erik Joelsson wrote:
> Looks good to me.
>
> /Erik
>
> On 2020-07-27 00:28, Aleksey Shipilev wrote:
>> Bug:
>>    https://bugs.openjdk.java.net/browse/JDK-8250605
>>
>> I believe this happens because int-to-pointer-cast is now enabled for 
>> libfontmanager. Below is the
>> minimal fix, but I wonder if we should reinstate the disabled warning 
>> for clang (in the same manner)
>> and msvc (which warning code that one is?). Or we can wait for 
>> follow-up bug reports there...
>>
>> Minimal fix:
>>    https://cr.openjdk.java.net/~shade/8250605/webrev.01/
>>
>> Testing: Linux {x86_64, x86_32} builds; jdk-submit (running)
>>


From jan.lahoda at oracle.com  Tue Jul 28 06:01:00 2020
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 28 Jul 2020 08:01:00 +0200
Subject: JDK 16 RFR of JDK-8249219: Update --release 15 symbol information
 for JDK 15 build 33
In-Reply-To: <25fac426-f037-091f-4042-29f3d365de11@oracle.com>
References: <25fac426-f037-091f-4042-29f3d365de11@oracle.com>
Message-ID: <8200ca17-7b9e-fed7-7cd5-5cc85287ff96@oracle.com>

Looks good to me.

Jan

On 24. 07. 20 23:38, Joe Darcy wrote:
> Hello,
> 
> The fix for JDK-8248476 in JDK 15 b33 changed the symbol information 
> used to represent --release 15 in JDK 16.
> 
> Please review the change to update the info:
> 
>  ??? http://cr.openjdk.java.net/~darcy/8249219.0/
> 
> Patch below; thanks,
> 
> -Joe
> 
> --- old/make/data/symbols/java.base-F.sym.txt??? 2020-07-24 
> 14:32:07.931767493 -0700
> +++ new/make/data/symbols/java.base-F.sym.txt??? 2020-07-24 
> 14:32:07.255429494 -0700
> @@ -69,6 +69,9 @@
>  ?method name absExact descriptor (I)I flags 9
>  ?method name absExact descriptor (J)J flags 9
> 
> +class name java/lang/NullPointerException
> +method name fillInStackTrace descriptor ()Ljava/lang/Throwable; flags 21
> +
>  ?class name java/lang/Short
>  ?header extends java/lang/Number implements 
> java/lang/Comparable,java/lang/constant/Constable flags 31 signature 
> Ljava/lang/Number;Ljava/lang/Comparable<Ljava/lang/Short;>;Ljava/lang/constant/Constable; 
> 
>  ?method name describeConstable descriptor ()Ljava/util/Optional; flags 
> 1 signature 
> ()Ljava/util/Optional<Ljava/lang/constant/DynamicConstantDesc<Ljava/lang/Short;>;>; 
> 
> 
> 


From shade at redhat.com  Tue Jul 28 07:05:56 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 28 Jul 2020 09:05:56 +0200
Subject: [OpenJDK 2D-Dev] RFR (XS) 8250605: Linux x86_32 builds fail after
 JDK-8249821
In-Reply-To: <5F1F066E.8010009@oracle.com>
References: <de25178d-770c-6ccb-35a1-2ef86dfd39b4@redhat.com>
 <3dc7afbc-f776-a867-2920-24135ee11cea@oracle.com>
 <5F1F066E.8010009@oracle.com>
Message-ID: <f2b8bb76-5412-46b6-eb37-6d3b17dca36f@redhat.com>

On 7/27/20 6:53 PM, Philip Race wrote:
> OK .. although I hope to come back in JDK 16 and eliminate all disabled 
> warnings
> from the now much smaller libfontmanager :
> https://bugs.openjdk.java.net/browse/JDK-8074844

OK, pushed.

-- 
Thanks,
-Aleksey


From igor.ignatyev at oracle.com  Tue Jul 28 14:51:45 2020
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 28 Jul 2020 07:51:45 -0700
Subject: [15] RFR(T) : 8250688 : missed open parenthesis for
 GTEST_FRAMEWORK_SRC var in Main.gmk
Message-ID: <4B6D79EE-CC50-4089-BE5D-80393DAB424C@oracle.com>

> 1 files changed, 1 insertions(+), 1 deletions(-)

Hi all,

could you please review the one-liner which fixes the typo introduced by 8245610?

patch:
> diff -r 31a8f79a7dfe make/Main.gmk
> --- a/make/Main.gmk	Tue Jul 28 10:32:57 2020 -0400
> +++ b/make/Main.gmk	Tue Jul 28 07:50:42 2020 -0700
> @@ -664,7 +664,7 @@
>      DEPS := build-test-hotspot-jtreg-graal, \
>  ))
>  
> -ifneq ($GTEST_FRAMEWORK_SRC), )
> +ifneq ($(GTEST_FRAMEWORK_SRC), )
>    $(eval $(call SetupTarget, test-image-hotspot-gtest, \
>        MAKEFILE := hotspot/test/GtestImage, \
>        DEPS := hotspot, \
> 


JBS: https://bugs.openjdk.java.net/browse/JDK-8250688
8245610: https://bugs.openjdk.java.net/browse/JDK-8245610

Thanks,
-- Igor

From erik.joelsson at oracle.com  Tue Jul 28 15:15:37 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 28 Jul 2020 08:15:37 -0700
Subject: [15] RFR(T) : 8250688 : missed open parenthesis for
 GTEST_FRAMEWORK_SRC var in Main.gmk
In-Reply-To: <4B6D79EE-CC50-4089-BE5D-80393DAB424C@oracle.com>
References: <4B6D79EE-CC50-4089-BE5D-80393DAB424C@oracle.com>
Message-ID: <176753d7-469d-a17c-a37e-62226d1a2b18@oracle.com>

Looks good.

/Erik

On 2020-07-28 07:51, Igor Ignatyev wrote:
>> 1 files changed, 1 insertions(+), 1 deletions(-)
> Hi all,
>
> could you please review the one-liner which fixes the typo introduced by 8245610?
>
> patch:
>> diff -r 31a8f79a7dfe make/Main.gmk
>> --- a/make/Main.gmk	Tue Jul 28 10:32:57 2020 -0400
>> +++ b/make/Main.gmk	Tue Jul 28 07:50:42 2020 -0700
>> @@ -664,7 +664,7 @@
>>       DEPS := build-test-hotspot-jtreg-graal, \
>>   ))
>>   
>> -ifneq ($GTEST_FRAMEWORK_SRC), )
>> +ifneq ($(GTEST_FRAMEWORK_SRC), )
>>     $(eval $(call SetupTarget, test-image-hotspot-gtest, \
>>         MAKEFILE := hotspot/test/GtestImage, \
>>         DEPS := hotspot, \
>>
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8250688
> 8245610: https://bugs.openjdk.java.net/browse/JDK-8245610
>
> Thanks,
> -- Igor


From igor.ignatyev at oracle.com  Tue Jul 28 16:10:55 2020
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 28 Jul 2020 09:10:55 -0700
Subject: [15] RFR(T) : 8250688 : missed open parenthesis for
 GTEST_FRAMEWORK_SRC var in Main.gmk
In-Reply-To: <176753d7-469d-a17c-a37e-62226d1a2b18@oracle.com>
References: <4B6D79EE-CC50-4089-BE5D-80393DAB424C@oracle.com>
 <176753d7-469d-a17c-a37e-62226d1a2b18@oracle.com>
Message-ID: <374945A4-CF5C-43A0-9AE3-EEEF0637EBD5@oracle.com>

thanks Erik, pushed to jdk15.

-- Igor

> On Jul 28, 2020, at 8:15 AM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 
> Looks good.
> 
> /Erik
> 
> On 2020-07-28 07:51, Igor Ignatyev wrote:
>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>> Hi all,
>> 
>> could you please review the one-liner which fixes the typo introduced by 8245610?
>> 
>> patch:
>>> diff -r 31a8f79a7dfe make/Main.gmk
>>> --- a/make/Main.gmk	Tue Jul 28 10:32:57 2020 -0400
>>> +++ b/make/Main.gmk	Tue Jul 28 07:50:42 2020 -0700
>>> @@ -664,7 +664,7 @@
>>>      DEPS := build-test-hotspot-jtreg-graal, \
>>>  ))
>>>  -ifneq ($GTEST_FRAMEWORK_SRC), )
>>> +ifneq ($(GTEST_FRAMEWORK_SRC), )
>>>    $(eval $(call SetupTarget, test-image-hotspot-gtest, \
>>>        MAKEFILE := hotspot/test/GtestImage, \
>>>        DEPS := hotspot, \
>>> 
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8250688
>> 8245610: https://bugs.openjdk.java.net/browse/JDK-8245610
>> 
>> Thanks,
>> -- Igor



From alexandre.iline at oracle.com  Wed Jul 29 05:29:22 2020
From: alexandre.iline at oracle.com (Alexander (Shura) Ilin)
Date: Tue, 28 Jul 2020 22:29:22 -0700
Subject: RFR 8250743: Switch to JCov build which supports byte code version 60
Message-ID: <4EDEE87E-F5A7-46A6-961A-26EB77A83346@oracle.com>

Hi,

Can you please take a look on a quick fix to update JCov version:

???????????????????????????????????????????
$ hg diff
diff -r 353f03fdf030 make/conf/jib-profiles.js
--- a/make/conf/jib-profiles.js Tue Jul 28 15:31:10 2020 -0700
+++ b/make/conf/jib-profiles.js Tue Jul 28 22:19:22 2020 -0700
@@ -1062,15 +1062,15 @@
 
         jcov: {
             // Until an official build of JCov is available, use custom
-            // build to support classfile version 57.
-            // See CODETOOLS-7902358 for more info.
+            // build to support classfile version 60.
+            // See CODETOOLS-7902734 for more info.
             // server: "jpg",
             // product: "jcov",
             // version: "3.0",
             // build_number: "b07",
             // file: "bundles/jcov-3_0.zip",
             organization: common.organization,
-            revision: "3.0-59-support+1.0",
+            revision: "3.0-60-support+1.0",
             ext: "zip",
             environment_name: "JCOV_HOME",
         },
???????????????????????????????????????????

Thank you,

Shura

From erik.joelsson at oracle.com  Wed Jul 29 12:57:27 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 29 Jul 2020 05:57:27 -0700
Subject: RFR 8250743: Switch to JCov build which supports byte code
 version 60
In-Reply-To: <4EDEE87E-F5A7-46A6-961A-26EB77A83346@oracle.com>
References: <4EDEE87E-F5A7-46A6-961A-26EB77A83346@oracle.com>
Message-ID: <33c8d464-2d72-c012-24c2-9d18e43a0f6c@oracle.com>

Looks good.

/Erik

On 2020-07-28 22:29, Alexander (Shura) Ilin wrote:
> Hi,
>
> Can you please take a look on a quick fix to update JCov version:
>
> ???????????????????????????????????????????
> $ hg diff
> diff -r 353f03fdf030 make/conf/jib-profiles.js
> --- a/make/conf/jib-profiles.js Tue Jul 28 15:31:10 2020 -0700
> +++ b/make/conf/jib-profiles.js Tue Jul 28 22:19:22 2020 -0700
> @@ -1062,15 +1062,15 @@
>   
>           jcov: {
>               // Until an official build of JCov is available, use custom
> -            // build to support classfile version 57.
> -            // See CODETOOLS-7902358 for more info.
> +            // build to support classfile version 60.
> +            // See CODETOOLS-7902734 for more info.
>               // server: "jpg",
>               // product: "jcov",
>               // version: "3.0",
>               // build_number: "b07",
>               // file: "bundles/jcov-3_0.zip",
>               organization: common.organization,
> -            revision: "3.0-59-support+1.0",
> +            revision: "3.0-60-support+1.0",
>               ext: "zip",
>               environment_name: "JCOV_HOME",
>           },
> ???????????????????????????????????????????
>
> Thank you,
>
> Shura


From chiroito107 at gmail.com  Thu Jul 30 13:23:23 2020
From: chiroito107 at gmail.com (Chihiro Ito)
Date: Thu, 30 Jul 2020 22:23:23 +0900
Subject: RFR: 8250818: idea.sh script doesn't work on WSL 1 and 2
Message-ID: <CAE_05uzeXAE4Tg70BwwJ0EXBh7MuCCO-kU_6dZ=U6Lcfh1fGLw@mail.gmail.com>

Hi,

Could you review this tiny change, please?

I ran on WSL 1, WSL 2, Cygwin and Linux. In these results, the .idea
created in all environments are able to read IntelliJ IDEA 2020.2.

JBS : https://bugs.openjdk.java.net/browse/JDK-8250818
Webrev : http://cr.openjdk.java.net/~cito/JDK-8238918/webrev.00/

Regards,
Chihiro


From erik.joelsson at oracle.com  Thu Jul 30 13:36:44 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 30 Jul 2020 06:36:44 -0700
Subject: RFR: 8250818: idea.sh script doesn't work on WSL 1 and 2
In-Reply-To: <CAE_05uzeXAE4Tg70BwwJ0EXBh7MuCCO-kU_6dZ=U6Lcfh1fGLw@mail.gmail.com>
References: <CAE_05uzeXAE4Tg70BwwJ0EXBh7MuCCO-kU_6dZ=U6Lcfh1fGLw@mail.gmail.com>
Message-ID: <ea853687-27e1-39d1-cdb0-50ce293ee11c@oracle.com>

Looks good to me.

/Erik

On 2020-07-30 06:23, Chihiro Ito wrote:
> Hi,
>
> Could you review this tiny change, please?
>
> I ran on WSL 1, WSL 2, Cygwin and Linux. In these results, the .idea
> created in all environments are able to read IntelliJ IDEA 2020.2.
>
> JBS : https://bugs.openjdk.java.net/browse/JDK-8250818
> Webrev : http://cr.openjdk.java.net/~cito/JDK-8238918/webrev.00/
>
> Regards,
> Chihiro


From chiroito107 at gmail.com  Fri Jul 31 12:39:51 2020
From: chiroito107 at gmail.com (Chihiro Ito)
Date: Fri, 31 Jul 2020 21:39:51 +0900
Subject: RFR: 8250818: idea.sh script doesn't work on WSL 1 and 2
In-Reply-To: <ea853687-27e1-39d1-cdb0-50ce293ee11c@oracle.com>
References: <CAE_05uzeXAE4Tg70BwwJ0EXBh7MuCCO-kU_6dZ=U6Lcfh1fGLw@mail.gmail.com>
 <ea853687-27e1-39d1-cdb0-50ce293ee11c@oracle.com>
Message-ID: <CAE_05uwN-N92rSE=L0_sMz6eHDtZExW4WUy15xS_0frEBTk2YA@mail.gmail.com>

Thank you for your prompt reviewing.

Regards,
Chihiro

2020?7?30?(?) 22:36 Erik Joelsson <erik.joelsson at oracle.com>:
>
> Looks good to me.
>
> /Erik
>
> On 2020-07-30 06:23, Chihiro Ito wrote:
> > Hi,
> >
> > Could you review this tiny change, please?
> >
> > I ran on WSL 1, WSL 2, Cygwin and Linux. In these results, the .idea
> > created in all environments are able to read IntelliJ IDEA 2020.2.
> >
> > JBS : https://bugs.openjdk.java.net/browse/JDK-8250818
> > Webrev : http://cr.openjdk.java.net/~cito/JDK-8238918/webrev.00/
> >
> > Regards,
> > Chihiro


From philip.race at oracle.com  Fri Jul 31 17:58:43 2020
From: philip.race at oracle.com (Philip Race)
Date: Fri, 31 Jul 2020 10:58:43 -0700
Subject: RFR: 8250894 : Provide a configure option to build and run against
 the platform libharfbuzz
Message-ID: <5F245BD3.2050107@oracle.com>

bug: https://bugs.openjdk.java.net/browse/JDK-8250894
webrev : http://cr.openjdk.java.net/~prr/8250894/

Since https://bugs.openjdk.java.net/browse/JDK-8249821 has now separated
out libharfbuzz from libfontmanager, it would be natural for distros
to want to link against the libharfbuzz that they distribute with the
platform, as is done for libfreetype. But there is no way to do it.

This fix adds a --with-harfbuzz=system configure option.
The valid values are system and bundled.
If specifying system it checks to see if you have the harfbuzz 
development package installed

Like similar options it is only useful on platforms that distribute
libharfbuzz, so there is no need to try to support windows and macOS for 
this option
and it will fast fail at configure time on those platforms.

I have verified this fix on Ubuntu 20.04 LTS.

-phil.




From erik.joelsson at oracle.com  Fri Jul 31 18:48:50 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 31 Jul 2020 11:48:50 -0700
Subject: RFR: 8250894 : Provide a configure option to build and run
 against the platform libharfbuzz
In-Reply-To: <5F245BD3.2050107@oracle.com>
References: <5F245BD3.2050107@oracle.com>
Message-ID: <d28f3622-7980-1863-4a88-d20c0738604a@oracle.com>

Hello Phil,

Looks good. The only thing I would ask is that you indent everything in 
the else clause in Awt2dLibraries.gmk.

Thanks

/Erik

On 2020-07-31 10:58, Philip Race wrote:
> bug: https://bugs.openjdk.java.net/browse/JDK-8250894
> webrev : http://cr.openjdk.java.net/~prr/8250894/
>
> Since https://bugs.openjdk.java.net/browse/JDK-8249821 has now separated
> out libharfbuzz from libfontmanager, it would be natural for distros
> to want to link against the libharfbuzz that they distribute with the
> platform, as is done for libfreetype. But there is no way to do it.
>
> This fix adds a --with-harfbuzz=system configure option.
> The valid values are system and bundled.
> If specifying system it checks to see if you have the harfbuzz 
> development package installed
>
> Like similar options it is only useful on platforms that distribute
> libharfbuzz, so there is no need to try to support windows and macOS 
> for this option
> and it will fast fail at configure time on those platforms.
>
> I have verified this fix on Ubuntu 20.04 LTS.
>
> -phil.
>
>


From philip.race at oracle.com  Fri Jul 31 19:56:03 2020
From: philip.race at oracle.com (Philip Race)
Date: Fri, 31 Jul 2020 12:56:03 -0700
Subject: RFR: 8250894 : Provide a configure option to build and run against
 the platform libharfbuzz
In-Reply-To: <d28f3622-7980-1863-4a88-d20c0738604a@oracle.com>
References: <5F245BD3.2050107@oracle.com>
 <d28f3622-7980-1863-4a88-d20c0738604a@oracle.com>
Message-ID: <5F247753.4070805@oracle.com>

Done : http://cr.openjdk.java.net/~prr/8250894.1/

Although it makes the webrev noisier ..

-phil.

On 7/31/20, 11:48 AM, Erik Joelsson wrote:
> Hello Phil,
>
> Looks good. The only thing I would ask is that you indent everything 
> in the else clause in Awt2dLibraries.gmk.
>
> Thanks
>
> /Erik
>
> On 2020-07-31 10:58, Philip Race wrote:
>> bug: https://bugs.openjdk.java.net/browse/JDK-8250894
>> webrev : http://cr.openjdk.java.net/~prr/8250894/
>>
>> Since https://bugs.openjdk.java.net/browse/JDK-8249821 has now separated
>> out libharfbuzz from libfontmanager, it would be natural for distros
>> to want to link against the libharfbuzz that they distribute with the
>> platform, as is done for libfreetype. But there is no way to do it.
>>
>> This fix adds a --with-harfbuzz=system configure option.
>> The valid values are system and bundled.
>> If specifying system it checks to see if you have the harfbuzz 
>> development package installed
>>
>> Like similar options it is only useful on platforms that distribute
>> libharfbuzz, so there is no need to try to support windows and macOS 
>> for this option
>> and it will fast fail at configure time on those platforms.
>>
>> I have verified this fix on Ubuntu 20.04 LTS.
>>
>> -phil.
>>
>>


From erik.joelsson at oracle.com  Fri Jul 31 20:04:43 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 31 Jul 2020 13:04:43 -0700
Subject: RFR: 8250894 : Provide a configure option to build and run
 against the platform libharfbuzz
In-Reply-To: <5F247753.4070805@oracle.com>
References: <5F245BD3.2050107@oracle.com>
 <d28f3622-7980-1863-4a88-d20c0738604a@oracle.com>
 <5F247753.4070805@oracle.com>
Message-ID: <330f38eb-3b6b-b1b4-48c4-ead72cd99f40@oracle.com>

On 2020-07-31 12:56, Philip Race wrote:
> Done : http://cr.openjdk.java.net/~prr/8250894.1/
>
> Although it makes the webrev noisier ..
>
Yes, but I prefer future readability. :)

Looks good now, thanks!

/Erik

> -phil.
>
> On 7/31/20, 11:48 AM, Erik Joelsson wrote:
>> Hello Phil,
>>
>> Looks good. The only thing I would ask is that you indent everything 
>> in the else clause in Awt2dLibraries.gmk.
>>
>> Thanks
>>
>> /Erik
>>
>> On 2020-07-31 10:58, Philip Race wrote:
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8250894
>>> webrev : http://cr.openjdk.java.net/~prr/8250894/
>>>
>>> Since https://bugs.openjdk.java.net/browse/JDK-8249821 has now 
>>> separated
>>> out libharfbuzz from libfontmanager, it would be natural for distros
>>> to want to link against the libharfbuzz that they distribute with the
>>> platform, as is done for libfreetype. But there is no way to do it.
>>>
>>> This fix adds a --with-harfbuzz=system configure option.
>>> The valid values are system and bundled.
>>> If specifying system it checks to see if you have the harfbuzz 
>>> development package installed
>>>
>>> Like similar options it is only useful on platforms that distribute
>>> libharfbuzz, so there is no need to try to support windows and macOS 
>>> for this option
>>> and it will fast fail at configure time on those platforms.
>>>
>>> I have verified this fix on Ubuntu 20.04 LTS.
>>>
>>> -phil.
>>>
>>>


From mikael.vidstedt at oracle.com  Fri Jul 31 20:51:02 2020
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Fri, 31 Jul 2020 13:51:02 -0700
Subject: RFR(XS): 8250899: Backout JDK-8249628 from jdk/jdk
Message-ID: <68DA5464-570A-4F03-AB14-7FC264082F05@oracle.com>


Please review this small change which will back out/revert the upcoming change[1] to remove the ?ea? suffix from the JDK 15 version string. Specifically, when that change gets pushed to jdk/jdk15 and then bulk integrated to jdk/jdk it needs to be immediately reverted to ensure that jdk/jdk remains in ?ea? mode.

--- old/make/autoconf/version-numbers	2020-07-31 13:44:01.220895013 -0700
+++ new/make/autoconf/version-numbers	2020-07-31 13:44:00.932889446 -0700
@@ -38,7 +38,7 @@
 DEFAULT_VERSION_CLASSFILE_MINOR=0
 DEFAULT_ACCEPTABLE_BOOT_VERSIONS="14 15 16"
 DEFAULT_JDK_SOURCE_TARGET_VERSION=16
-DEFAULT_PROMOTED_VERSION_PRE=
+DEFAULT_PROMOTED_VERSION_PRE=ea
 
 LAUNCHER_NAME=openjdk
 PRODUCT_NAME=OpenJDK

Cheers,
Mikael

[1] https://bugs.openjdk.java.net/browse/JDK-8249628 <https://bugs.openjdk.java.net/browse/JDK-8249628>



From erik.joelsson at oracle.com  Fri Jul 31 21:08:14 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 31 Jul 2020 14:08:14 -0700
Subject: RFR(XS): 8250899: Backout JDK-8249628 from jdk/jdk
In-Reply-To: <68DA5464-570A-4F03-AB14-7FC264082F05@oracle.com>
References: <68DA5464-570A-4F03-AB14-7FC264082F05@oracle.com>
Message-ID: <abdd46eb-06b9-3657-1a17-4294cefb3fff@oracle.com>

Looks good.

/Erik

On 2020-07-31 13:51, Mikael Vidstedt wrote:
> Please review this small change which will back out/revert the upcoming change[1] to remove the ?ea? suffix from the JDK 15 version string. Specifically, when that change gets pushed to jdk/jdk15 and then bulk integrated to jdk/jdk it needs to be immediately reverted to ensure that jdk/jdk remains in ?ea? mode.
>
> --- old/make/autoconf/version-numbers	2020-07-31 13:44:01.220895013 -0700
> +++ new/make/autoconf/version-numbers	2020-07-31 13:44:00.932889446 -0700
> @@ -38,7 +38,7 @@
>   DEFAULT_VERSION_CLASSFILE_MINOR=0
>   DEFAULT_ACCEPTABLE_BOOT_VERSIONS="14 15 16"
>   DEFAULT_JDK_SOURCE_TARGET_VERSION=16
> -DEFAULT_PROMOTED_VERSION_PRE=
> +DEFAULT_PROMOTED_VERSION_PRE=ea
>   
>   LAUNCHER_NAME=openjdk
>   PRODUCT_NAME=OpenJDK
>
> Cheers,
> Mikael
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8249628 <https://bugs.openjdk.java.net/browse/JDK-8249628>
>


From joe.darcy at oracle.com  Fri Jul 31 21:18:43 2020
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 31 Jul 2020 14:18:43 -0700
Subject: JDK 16 RFR of build changes for JDK-8071961: Add javac lint warning
 when a default constructor is created
Message-ID: <87717076-1eb8-a757-6be3-72ed71829e10@oracle.com>

Hello,

FYI, a new javac lint warning is in the works and out for review on 
compiler-dev:

 ??? JDK-8071961: Add javac lint warning when a default constructor is 
created
https://mail.openjdk.java.net/pipermail/compiler-dev/2020-July/014782.html

The warning notes where a formal API class exposes a default 
constructor, that is, an implicit constructor generated by the compiler 
(see JLS 8.8.9 for details 
https://docs.oracle.com/javase/specs/jls/se14/html/jls-8.html#jls-8.8.9).

The JDK modules are generally compiled under "-Xlint:all -Werror". 
Therefore, if a new lint warning is added *without* first clearing those 
conditions, the build will break. Many modules have already been cleared 
(JDK-8250212); others are still in progress (JDK-8250639).

Please review the make system portions of JDK-8071961 that disable the 
warning on modules where the new warning still has some occurrences:

 ??? http://cr.openjdk.java.net/~darcy/8071961.7/

Patch for the relevant file below. Depending on the relative timing of 
fixing the warning locations and the javac changes being ready, some of 
the module changes in the make file might be removed.

Thanks,

-Joe

--- old/make/CompileJavaModules.gmk??? 2020-07-31 14:04:28.285167000 -0700
+++ new/make/CompileJavaModules.gmk??? 2020-07-31 14:04:27.657167000 -0700
@@ -76,6 +76,7 @@

 ?################################################################################

+java.desktop_DISABLED_WARNINGS += default-ctor
 ?java.desktop_DOCLINT += -Xdoclint:all/protected,-reference \
 ???? '-Xdoclint/package:java.*,javax.*'
 ?java.desktop_COPY += .gif .png .wav .txt .xml .css .pf
@@ -298,6 +299,10 @@

 ?################################################################################

+jdk.accessibility_DISABLED_WARNINGS += default-ctor
+
+################################################################################
+
 ?jdk.charsets_COPY += .dat

 ?################################################################################
@@ -347,10 +352,19 @@

 ?################################################################################

+jdk.jartool_DISABLED_WARNINGS += default-ctor
 ?jdk.jartool_JAVAC_FLAGS += -XDstringConcat=inline

 ?################################################################################

+jdk.httpserver_DISABLED_WARNINGS += default-ctor
+
+################################################################################
+
+jdk.unsupported.desktop_DISABLED_WARNINGS += default-ctor
+
+################################################################################
+
 ?# No SCTP implementation on Mac OS X or AIX. These classes should be 
excluded.
 ?SCTP_IMPL_CLASSES = \
$(TOPDIR)/src/jdk.sctp/unix/classes/sun/nio/ch/sctp/AssociationChange.java \