RFR: 8274329: Fix non-portable HotSpot code in MethodMatcher::parse_method_pattern
jiefu at openjdk.java.net
Sat Oct 2 03:10:31 UTC 2021
On Thu, 30 Sep 2021 23:41:20 GMT, Jie Fu <jiefu at openjdk.org> wrote:
> > I will do your experiment next week. This is because it's already our National Day week and I can't find an English Windows machine until next week. I'll let you know the result as soon as possible. Thanks.
> No need to hurry :-). In case you can't find an English Windows, I think you can use the `chcp 65001` command mentioned in https://stackoverflow.com/questions/388490/how-to-use-unicode-characters-in-windows-command-line to change your command-line window to use the UTF8 codepage.
Hi @iklam ,
methodMatcher.obj  built with `System Locale: zh-cn;Chinese (China)`
methodMatcher.obj  built with `System Locale: en-us;English (United States)"`
There seems no difference when checking with `strings methodMatcher.obj`.
The warnings disappear when the system locale is `en-us;English (United States)`.
But unfortunately, I can't reproduce the "CJK" test example, which means non-ASCII chars for CompileCommand still fail for both jdk images (even when built with en-us locale, no warnings at all).
So it's far more complicated than I had thought.
I will just close this pr since we can't remove the non-ASCII code, which works in some countries.
Thank you all for your help and valuable comments.
More information about the hotspot-runtime-dev