Re: RFR: 8274329: Fix non-portable HotSpot code in MethodMatcher::parse_method_pattern [v3]
On Wed, 6 Oct 2021 05:17:28 GMT, Jie Fu wrote:
>> Hi all,
>>
>> I tried to build OpenJDK on Cygwin (Windows 2016 + VS2019).
>> However, I failed with C4474 and C4778 warnings as below:
>>
>> Compiling 100 properties into resource bundles for java.desktop
>> Compiling 3038 files for java.base
>> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(269): error
>> C2220: the following warning is treated as an error
>> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(269): warning
>> C4778: 'sscanf' : unterminated format string
>> '%255[*\x01\x02\x03\x04\x05\x06\a\b\n\v\f\r\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f!"#$%&'*+,-0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ\^_`abcdefghijklmnopqrstuvwxyz{|}~\xe2\x82\xac\xe4\xba\x97\xe5\x84\x8e\xe5\x8e\x97%n'
>> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(269): warning
>> C4474: 'sscanf' : too many arguments passed for format string
>> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(269): note:
>> placeholders and their parameters expect 1 variadic arguments, but 3 were
>> provided
>> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(319): warning
>> C4778: 'sscanf' : unterminated format string
>> '%1022[[);/\x01\x02\x03\x04\x05\x06\a\b\n\v\f\r\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f!"#$%&'*+,-0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ\^_`abcdefghijklmnopqrstuvwxyz{|}~\xe2\x82\xac\xe4\xba\x97\xe5\x84\x8e\xe5\x8e%n'
>> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(319): warning
>> C4474: 'sscanf' : too many arguments passed for format string
>> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(319): note:
>> placeholders and their parameters expect 0 variadic arguments, but 2 were
>> provided
>>
>>
>> The failure is caused by non-ASCII chars in the format string of sscanf
>> [1][2], which is non-portable on our Windows platform.
>> In fact, these non-ASCII coding also triggers C4819 warning, which had been
>> disabled in JDK-8216154 [3].
>> And I also found an article showing that sscanf may fail with non-ASCII in
>> the format string [4].
>>
>> So it would be nice to remove these non-ASCII chars (`\x80 ~ \xef`).
>> And I think it's safe to do so.
>>
>> This is because:
>> 1) There are actually no non-ASCII chars for package/class/method/signature
>> names.
>> 2) I don't think there is a use case, in which people will input non-ASCII
>> for `CompileCommand`.
>>
>> You may argue that the non-ASCII may be used by the parser itself.
>> But I didn't find that usage at all. (Please let me know if I miss
>> something.)
>>
>> So I suggest to remove these non-ASCII code to make HotSpot to be more
>> portable.
>> And if we do so, we can also remove the only one
>> `PRAGMA_DISABLE_MSVC_WARNING(4819)` [5].
>>
>> Testing:
>> - Build tests on Windows
>> - tier1~3 on Linux/x64
>>
>> Thanks.
>> Best regards,
>> Jie
>>
>> [1]
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/methodMatcher.cpp#L269
>> [2]
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/methodMatcher.cpp#L319
>> [3]
>> https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-January/032014.html
>> [4] https://jeffpar.github.io/kbarchive/kb/047/Q47369/
>> [5]
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/methodMatcher.cpp#L246
>
> Jie Fu has updated the pull request incrementally with one additional commit
> since the last revision:
>
> Split with RANGEBASE_ASCII and RANGEBASE_NON_ASCII
Marked as reviewed by iklam (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/5704
Re: RFR: 8274329: Fix non-portable HotSpot code in MethodMatcher::parse_method_pattern [v3]
> Hi all,
>
> I tried to build OpenJDK on Cygwin (Windows 2016 + VS2019).
> However, I failed with C4474 and C4778 warnings as below:
>
> Compiling 100 properties into resource bundles for java.desktop
> Compiling 3038 files for java.base
> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(269): error
> C2220: the following warning is treated as an error
> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(269): warning
> C4778: 'sscanf' : unterminated format string
> '%255[*\x01\x02\x03\x04\x05\x06\a\b\n\v\f\r\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f!"#$%&'*+,-0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ\^_`abcdefghijklmnopqrstuvwxyz{|}~\xe2\x82\xac\xe4\xba\x97\xe5\x84\x8e\xe5\x8e\x97%n'
> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(269): warning
> C4474: 'sscanf' : too many arguments passed for format string
> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(269): note:
> placeholders and their parameters expect 1 variadic arguments, but 3 were
> provided
> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(319): warning
> C4778: 'sscanf' : unterminated format string
> '%1022[[);/\x01\x02\x03\x04\x05\x06\a\b\n\v\f\r\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f!"#$%&'*+,-0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ\^_`abcdefghijklmnopqrstuvwxyz{|}~\xe2\x82\xac\xe4\xba\x97\xe5\x84\x8e\xe5\x8e%n'
> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(319): warning
> C4474: 'sscanf' : too many arguments passed for format string
> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(319): note:
> placeholders and their parameters expect 0 variadic arguments, but 2 were
> provided
>
>
> The failure is caused by non-ASCII chars in the format string of sscanf
> [1][2], which is non-portable on our Windows platform.
> In fact, these non-ASCII coding also triggers C4819 warning, which had been
> disabled in JDK-8216154 [3].
> And I also found an article showing that sscanf may fail with non-ASCII in
> the format string [4].
>
> So it would be nice to remove these non-ASCII chars (`\x80 ~ \xef`).
> And I think it's safe to do so.
>
> This is because:
> 1) There are actually no non-ASCII chars for package/class/method/signature
> names.
> 2) I don't think there is a use case, in which people will input non-ASCII
> for `CompileCommand`.
>
> You may argue that the non-ASCII may be used by the parser itself.
> But I didn't find that usage at all. (Please let me know if I miss something.)
>
> So I suggest to remove these non-ASCII code to make HotSpot to be more
> portable.
> And if we do so, we can also remove the only one
> `PRAGMA_DISABLE_MSVC_WARNING(4819)` [5].
>
> Testing:
> - Build tests on Windows
> - tier1~3 on Linux/x64
>
> Thanks.
> Best regards,
> Jie
>
> [1]
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/methodMatcher.cpp#L269
> [2]
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/methodMatcher.cpp#L319
> [3]
> https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-January/032014.html
> [4] https://jeffpar.github.io/kbarchive/kb/047/Q47369/
> [5]
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/methodMatcher.cpp#L246
Jie Fu has updated the pull request incrementally with one additional commit
since the last revision:
Split with RANGEBASE_ASCII and RANGEBASE_NON_ASCII
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/5704/files
- new: https://git.openjdk.java.net/jdk/pull/5704/files/e1271085..d0070680
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5704&range=02
- incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5704&range=01-02
Stats: 15 lines in 1 file changed: 1 ins; 9 del; 5 mod
Patch: https://git.openjdk.java.net/jdk/pull/5704.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/5704/head:pull/5704
PR: https://git.openjdk.java.net/jdk/pull/5704
Re: RFR: 8274329: Fix non-portable HotSpot code in MethodMatcher::parse_method_pattern [v2]
On Wed, 6 Oct 2021 04:30:12 GMT, Ioi Lam wrote: > It's hard to tell what's the difference between these two RANGEBASE > definitions. How about doing it like this to make the code more readable? > > ``` > #define RANGEBASE_ASCII "." > #define RANGEBASE_NON_ASCII "." > #ifdef WINDOWS > #define RANGEBASE RANGEBASE_ASCII > #else > #define RANGEBASE RANGEBASE_ASCII RANGEBASE_NON_ASCII > #endif > ``` Good suggestion! Updated. Thanks. - PR: https://git.openjdk.java.net/jdk/pull/5704
Re: RFR: 8274329: Fix non-portable HotSpot code in MethodMatcher::parse_method_pattern [v2]
On Wed, 6 Oct 2021 02:33:30 GMT, Jie Fu wrote:
>> Hi all,
>>
>> I tried to build OpenJDK on Cygwin (Windows 2016 + VS2019).
>> However, I failed with C4474 and C4778 warnings as below:
>>
>> Compiling 100 properties into resource bundles for java.desktop
>> Compiling 3038 files for java.base
>> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(269): error
>> C2220: the following warning is treated as an error
>> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(269): warning
>> C4778: 'sscanf' : unterminated format string
>> '%255[*\x01\x02\x03\x04\x05\x06\a\b\n\v\f\r\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f!"#$%&'*+,-0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ\^_`abcdefghijklmnopqrstuvwxyz{|}~\xe2\x82\xac\xe4\xba\x97\xe5\x84\x8e\xe5\x8e\x97%n'
>> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(269): warning
>> C4474: 'sscanf' : too many arguments passed for format string
>> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(269): note:
>> placeholders and their parameters expect 1 variadic arguments, but 3 were
>> provided
>> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(319): warning
>> C4778: 'sscanf' : unterminated format string
>> '%1022[[);/\x01\x02\x03\x04\x05\x06\a\b\n\v\f\r\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f!"#$%&'*+,-0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ\^_`abcdefghijklmnopqrstuvwxyz{|}~\xe2\x82\xac\xe4\xba\x97\xe5\x84\x8e\xe5\x8e%n'
>> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(319): warning
>> C4474: 'sscanf' : too many arguments passed for format string
>> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(319): note:
>> placeholders and their parameters expect 0 variadic arguments, but 2 were
>> provided
>>
>>
>> The failure is caused by non-ASCII chars in the format string of sscanf
>> [1][2], which is non-portable on our Windows platform.
>> In fact, these non-ASCII coding also triggers C4819 warning, which had been
>> disabled in JDK-8216154 [3].
>> And I also found an article showing that sscanf may fail with non-ASCII in
>> the format string [4].
>>
>> So it would be nice to remove these non-ASCII chars (`\x80 ~ \xef`).
>> And I think it's safe to do so.
>>
>> This is because:
>> 1) There are actually no non-ASCII chars for package/class/method/signature
>> names.
>> 2) I don't think there is a use case, in which people will input non-ASCII
>> for `CompileCommand`.
>>
>> You may argue that the non-ASCII may be used by the parser itself.
>> But I didn't find that usage at all. (Please let me know if I miss
>> something.)
>>
>> So I suggest to remove these non-ASCII code to make HotSpot to be more
>> portable.
>> And if we do so, we can also remove the only one
>> `PRAGMA_DISABLE_MSVC_WARNING(4819)` [5].
>>
>> Testing:
>> - Build tests on Windows
>> - tier1~3 on Linux/x64
>>
>> Thanks.
>> Best regards,
>> Jie
>>
>> [1]
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/methodMatcher.cpp#L269
>> [2]
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/methodMatcher.cpp#L319
>> [3]
>> https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-January/032014.html
>> [4] https://jeffpar.github.io/kbarchive/kb/047/Q47369/
>> [5]
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/methodMatcher.cpp#L246
>
> Jie Fu has updated the pull request incrementally with one additional commit
> since the last revision:
>
> Disable non-ASCII for Windows only
The idea looks good to me. I just have a suggestion to make the code more
readable.
src/hotspot/share/compiler/methodMatcher.cpp line 77:
> 75: "\x60\x61\x62\x63\x64\x65\x66\x67\x68\x69\x6a\x6b\x6c\x6d\x6e\x6f" \
> 76: "\x70\x71\x72\x73\x74\x75\x76\x77\x78\x79\x7a\x7b\x7c\x7d\x7e\x7f"
> 77: #endif
It's hard to tell what's the difference between these two RANGEBASE
definitions. How about doing it like this to make the code more readable?
#define RANGEBASE_ASCII "."
#define RANGEBASE_NON_ASCII "."
#ifdef WINDOWS
#define RANGEBASE RANGEBASE_ASCII
#else
#define RANGEBASE RANGEBASE_ASCII RANGEBASE_NON_ASCII
#endif
-
Marked as reviewed by iklam (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/5704
RFR: 8274407: (tz) Update Timezone Data to 2021c
This PR is to upgrade the time zone data in the JDK to IANA's tzdata2021c level. Note that the tz data is "as is", as released by IANA. No `merged links` are retracted. The PR also fixes two issues along with the 2021c upgrade. - Commit messages: - Fix for Asia/Amman test case error - Test fix for Samoa not observing DST - tzdata2021c - 8274407: (tz) Update Timezone Data to 2021b Changes: https://git.openjdk.java.net/jdk/pull/5832/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5832&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274407 Stats: 635 lines in 13 files changed: 228 ins; 329 del; 78 mod Patch: https://git.openjdk.java.net/jdk/pull/5832.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5832/head:pull/5832 PR: https://git.openjdk.java.net/jdk/pull/5832
Re: RFR: 8274329: Fix non-portable HotSpot code in MethodMatcher::parse_method_pattern
On Tue, 5 Oct 2021 06:38:05 GMT, Ioi Lam wrote:
>> Hi all,
>>
>> I tried to build OpenJDK on Cygwin (Windows 2016 + VS2019).
>> However, I failed with C4474 and C4778 warnings as below:
>>
>> Compiling 100 properties into resource bundles for java.desktop
>> Compiling 3038 files for java.base
>> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(269): error
>> C2220: the following warning is treated as an error
>> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(269): warning
>> C4778: 'sscanf' : unterminated format string
>> '%255[*\x01\x02\x03\x04\x05\x06\a\b\n\v\f\r\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f!"#$%&'*+,-0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ\^_`abcdefghijklmnopqrstuvwxyz{|}~\xe2\x82\xac\xe4\xba\x97\xe5\x84\x8e\xe5\x8e\x97%n'
>> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(269): warning
>> C4474: 'sscanf' : too many arguments passed for format string
>> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(269): note:
>> placeholders and their parameters expect 1 variadic arguments, but 3 were
>> provided
>> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(319): warning
>> C4778: 'sscanf' : unterminated format string
>> '%1022[[);/\x01\x02\x03\x04\x05\x06\a\b\n\v\f\r\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f!"#$%&'*+,-0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ\^_`abcdefghijklmnopqrstuvwxyz{|}~\xe2\x82\xac\xe4\xba\x97\xe5\x84\x8e\xe5\x8e%n'
>> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(319): warning
>> C4474: 'sscanf' : too many arguments passed for format string
>> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(319): note:
>> placeholders and their parameters expect 0 variadic arguments, but 2 were
>> provided
>>
>>
>> The failure is caused by non-ASCII chars in the format string of sscanf
>> [1][2], which is non-portable on our Windows platform.
>> In fact, these non-ASCII coding also triggers C4819 warning, which had been
>> disabled in JDK-8216154 [3].
>> And I also found an article showing that sscanf may fail with non-ASCII in
>> the format string [4].
>>
>> So it would be nice to remove these non-ASCII chars (`\x80 ~ \xef`).
>> And I think it's safe to do so.
>>
>> This is because:
>> 1) There are actually no non-ASCII chars for package/class/method/signature
>> names.
>> 2) I don't think there is a use case, in which people will input non-ASCII
>> for `CompileCommand`.
>>
>> You may argue that the non-ASCII may be used by the parser itself.
>> But I didn't find that usage at all. (Please let me know if I miss
>> something.)
>>
>> So I suggest to remove these non-ASCII code to make HotSpot to be more
>> portable.
>> And if we do so, we can also remove the only one
>> `PRAGMA_DISABLE_MSVC_WARNING(4819)` [5].
>>
>> Testing:
>> - Build tests on Windows
>> - tier1~3 on Linux/x64
>>
>> Thanks.
>> Best regards,
>> Jie
>>
>> [1]
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/methodMatcher.cpp#L269
>> [2]
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/methodMatcher.cpp#L319
>> [3]
>> https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-January/032014.html
>> [4] https://jeffpar.github.io/kbarchive/kb/047/Q47369/
>> [5]
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/methodMatcher.cpp#L246
>
> My experiments above with ` -XX:CompileCommand='compileonly,*::爪哇'` was done
> on Linux. I tried doing the same on Windows. On US-English Windows, the
> default codepage is 437 (DOS Latin US). If I change it to 65001 (UTF8) then
> Java is able to output CJK characters to the console.
>
>
> public class CJK {
> public static void main(String args[]) {
> System.out.println(args[0]);
> \u722a\u54c7();
> }
>
> static void \u722a\u54c7() { // Chinese word for "Java"
> Thread.dumpStack();
> }
> }
>
>
>
> c:\ade>chcp
> Active code page: 437
>
> c:\ade>jdk-17\bin\java -cp . CJK 123
> 123
> java.lang.Exception: Stack trace
> at java.base/java.lang.Thread.dumpStack(Thread.java:1380)
> at CJK.??(CJK.java:8)
> at CJK.main(CJK.java:4)
>
> c:\ade>chcp 65001
> Active code page: 65001
>
> c:\ade>jdk-17\bin\java -cp . CJK 爪哇
> ??
> java.lang.Exception: Stack trace
> at java.base/java.lang.Thread.dumpStack(Thread.java:1380)
> at CJK.爪哇(CJK.java:8)
> at CJK.main(CJK.java:4)
>
>
> As you can see, the CJK characters in the command-line arguments can't even
> be correctly passed as arguments to the Java main class. If that doesn't
> work, I can't see how we can get `-XX:CompileCommand` to work with CJK
> characters.
Thanks @iklam and @magicus for your experiments and comments.
My experiments show that CompileCommand doesn't work with non-US-English env
Windows.
And @iklam 's experiments show that it doesn't work with US-English env Windows
Re: RFR: 8274329: Fix non-portable HotSpot code in MethodMatcher::parse_method_pattern [v2]
> Hi all,
>
> I tried to build OpenJDK on Cygwin (Windows 2016 + VS2019).
> However, I failed with C4474 and C4778 warnings as below:
>
> Compiling 100 properties into resource bundles for java.desktop
> Compiling 3038 files for java.base
> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(269): error
> C2220: the following warning is treated as an error
> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(269): warning
> C4778: 'sscanf' : unterminated format string
> '%255[*\x01\x02\x03\x04\x05\x06\a\b\n\v\f\r\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f!"#$%&'*+,-0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ\^_`abcdefghijklmnopqrstuvwxyz{|}~\xe2\x82\xac\xe4\xba\x97\xe5\x84\x8e\xe5\x8e\x97%n'
> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(269): warning
> C4474: 'sscanf' : too many arguments passed for format string
> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(269): note:
> placeholders and their parameters expect 1 variadic arguments, but 3 were
> provided
> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(319): warning
> C4778: 'sscanf' : unterminated format string
> '%1022[[);/\x01\x02\x03\x04\x05\x06\a\b\n\v\f\r\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f!"#$%&'*+,-0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ\^_`abcdefghijklmnopqrstuvwxyz{|}~\xe2\x82\xac\xe4\xba\x97\xe5\x84\x8e\xe5\x8e%n'
> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(319): warning
> C4474: 'sscanf' : too many arguments passed for format string
> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(319): note:
> placeholders and their parameters expect 0 variadic arguments, but 2 were
> provided
>
>
> The failure is caused by non-ASCII chars in the format string of sscanf
> [1][2], which is non-portable on our Windows platform.
> In fact, these non-ASCII coding also triggers C4819 warning, which had been
> disabled in JDK-8216154 [3].
> And I also found an article showing that sscanf may fail with non-ASCII in
> the format string [4].
>
> So it would be nice to remove these non-ASCII chars (`\x80 ~ \xef`).
> And I think it's safe to do so.
>
> This is because:
> 1) There are actually no non-ASCII chars for package/class/method/signature
> names.
> 2) I don't think there is a use case, in which people will input non-ASCII
> for `CompileCommand`.
>
> You may argue that the non-ASCII may be used by the parser itself.
> But I didn't find that usage at all. (Please let me know if I miss something.)
>
> So I suggest to remove these non-ASCII code to make HotSpot to be more
> portable.
> And if we do so, we can also remove the only one
> `PRAGMA_DISABLE_MSVC_WARNING(4819)` [5].
>
> Testing:
> - Build tests on Windows
> - tier1~3 on Linux/x64
>
> Thanks.
> Best regards,
> Jie
>
> [1]
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/methodMatcher.cpp#L269
> [2]
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/methodMatcher.cpp#L319
> [3]
> https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-January/032014.html
> [4] https://jeffpar.github.io/kbarchive/kb/047/Q47369/
> [5]
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/methodMatcher.cpp#L246
Jie Fu has updated the pull request incrementally with one additional commit
since the last revision:
Disable non-ASCII for Windows only
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/5704/files
- new: https://git.openjdk.java.net/jdk/pull/5704/files/d4b84f2b..e1271085
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5704&range=01
- incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5704&range=00-01
Stats: 30 lines in 1 file changed: 30 ins; 0 del; 0 mod
Patch: https://git.openjdk.java.net/jdk/pull/5704.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/5704/head:pull/5704
PR: https://git.openjdk.java.net/jdk/pull/5704
Re: RFR: 8255790: GTKL&F: Java 16 crashes on initialising GTKL&F on Manjaro Linux [v3]
On Tue, 16 Mar 2021 16:56:22 GMT, Phil Race wrote: >> From a build perspective this partially reverts >> https://bugs.openjdk.java.net/browse/JDK-8249821 except that it keeps >> the harfbuzz sources separate and still supports building and running >> against a system harfbuzz which is only of interest or relevance on Linux. >> >> I ended up having to go this way because its is the least unsatisfactory >> solution. >> I did not want us to build a devkit to link against a system linux only to >> find we couldn't use it at runtime >> because too many systems have to old a version of harfbuzz. >> >> This solves the Manjaro Linux problem and I've manually verified building >> against a system hardbuxz on Ubuntu 20.10 >> >> There are couple of incidental fixes in here too >> - "libharfbuzz" should not have been in the EXTRA_HEADERS var when building >> against a system version >> - harfbuzz/hb-ucdn is gone and should not be listed as a header directory >> needed to build the bundled copy >> - I expect it also resolves https://bugs.openjdk.java.net/browse/JDK-8262502 > > Phil Race has updated the pull request incrementally with one additional > commit since the last revision: > > 8255790: GTKL&F: Java 16 crashes on initialising GTKL&F on Manjaro Linux Yes, it would fail at runtime, perhaps in subtle ways if the issue is not a missing function but a difference in behaviour. In the scenario I'm considering, the build and runtime environments are effectively the same, as we're building packages for Fedora or RHEL on a specific version of that OS, which is then provided for that OS alone. We tend to use system libraries where possible as we know the library is going to be the same or newer than what we built against, and we benefit from fixes to the system library without rebuilding OpenJDK. Rather than relying on failures being found in an older environment at runtime, I'd like the build to check it is being built against is suitable. With that early build failure, we can then flip those builds to using the in-tree library. You do, however, make a good point that this check can be overridden at runtime if the build is run on a different system. So, if possible, it would be good to also have a runtime check if there is some clear entry point to add one. I'll try and look into a fix for both once the October security update cycle is out of the way. That's taking up most of my time right now. - PR: https://git.openjdk.java.net/jdk/pull/2982
Re: help
Apologies all On Tue, Oct 5, 2021 at 10:35 AM Bruno Borges wrote: > > --- > *Bruno Borges* > brunoborges.io >
Re: RFR: 8274329: Fix non-portable HotSpot code in MethodMatcher::parse_method_pattern
On 2021-10-05 08:41, Ioi Lam wrote: As you can see, the CJK characters in the command-line arguments can't even be correctly passed as arguments to the Java main class. If that doesn't work, I can't see how we can get `-XX:CompileCommand` to work with CJK characters. So, what does that mean? That we should explicitly limit `-XX:CompileCommand`to work with ASCII-only arguments? I accept that we might not get all characters to work in all circumstances due to limitations in Windows, but the current state of affairs still feel unsatisfactory. We should at least have a better failure mode, and document any limitations. /Magnus
Re: RFR: 8274716: JDWP Spec: the description for the Dispose command confuses suspend with resume. [v2]
On Tue, 5 Oct 2021 07:38:28 GMT, Richard Reingruber wrote: >> The following sentence in the JDWP Specification describing the Dispose >> command confuses resume with suspend [1]: >> >> All threads suspended by the thread-level **resume** command or the >> VM-level >> **resume** command are resumed as many times as necessary for them to run. >> >> It should be changed to >> >> All threads suspended by the thread-level **suspend** command or the >> VM-level >> **suspend** command are resumed as many times as necessary for them to run. >> >> [1] [JDWP Spec, Dispose Command >> (JDK17).](https://docs.oracle.com/en/java/javase/17/docs/specs/jdwp/jdwp-protocol.html#JDWP_VirtualMachine_Dispose) > > Richard Reingruber has updated the pull request incrementally with one > additional commit since the last revision: > > Updated copyright. Marked as reviewed by sspitsyn (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/5804
Re: RFR: 8274716: JDWP Spec: the description for the Dispose command confuses suspend with resume. [v2]
On Mon, 4 Oct 2021 18:20:42 GMT, Chris Plummer wrote: > > > Can you update the copyright please? Sure, thanks! > I checked the JDI spec and it looks correct there, which is actually > surprising since errors like this usually appear in both specs. Yes I noticed this too. Thanks for reviewing, Richard. - PR: https://git.openjdk.java.net/jdk/pull/5804
Re: RFR: 8274716: JDWP Spec: the description for the Dispose command confuses suspend with resume. [v2]
> The following sentence in the JDWP Specification describing the Dispose > command confuses resume with suspend [1]: > > All threads suspended by the thread-level **resume** command or the VM-level > **resume** command are resumed as many times as necessary for them to run. > > It should be changed to > > All threads suspended by the thread-level **suspend** command or the > VM-level > **suspend** command are resumed as many times as necessary for them to run. > > [1] [JDWP Spec, Dispose Command > (JDK17).](https://docs.oracle.com/en/java/javase/17/docs/specs/jdwp/jdwp-protocol.html#JDWP_VirtualMachine_Dispose) Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: Updated copyright. - Changes: - all: https://git.openjdk.java.net/jdk/pull/5804/files - new: https://git.openjdk.java.net/jdk/pull/5804/files/97396416..1d896c41 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5804&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5804&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5804.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5804/head:pull/5804 PR: https://git.openjdk.java.net/jdk/pull/5804
