RFR: 8274329: Fix non-portable HotSpot code in MethodMatcher::parse_method_pattern

[Jie Fu]

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 [1] built with `System Locale:             zh-cn;Chinese (China)`
methodMatcher.obj [2] 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.

Best regards,
Jie

[1] https://github.com/DamonFool/experiment/blob/main/JDK-8274329/ch-methodMatcher.obj
[2] https://github.com/DamonFool/experiment/blob/main/JDK-8274329/en-methodMatcher.obj

-------------

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