From kim.barrett at oracle.com Thu Jul 12 04:03:42 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 12 Jul 2018 00:03:42 -0400 Subject: RFR(S): 8207011: Remove uses of the register storage class specifier In-Reply-To: References: Message-ID: <35BB03F7-3FCB-4DC9-82A1-F1DFD4FDCD2F@oracle.com> > On Jul 11, 2018, at 6:52 PM, Mikael Vidstedt wrote: > > > Please review the below change which removes *most* uses of the register keyword/storage class specifier. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8207011 > Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8207011/webrev.01/open/webrev/ > > * Background (from the bug) > > The C/C++ register keyword/storage class specifier may have made a difference many moons ago, but the C++11 standard deprecated it, and starting with C++17 it is a reserved keyword. Some compilers emit deprecation warnings even when targeting earlier C++ standards such as C++14. > > > * Commentary > > The one case where the register keyword remains is when compiling (effectively) inline assembly with gcc, patterns like: > > address os::current_stack_pointer() { > ? > #else // gcc > register void *esp __asm__ (SPELL_REG_SP); > return (address) esp; > #endif > } > > Removing the register keyword here breaks the code, and gcc does *not* complain about using it for these patterns, so I chose to leave it there. An alternative to that would be to always use the ?clang? style mov instruction. I know there is another thread[1] discussing how to move forward with the current_stack_pointer on clang 4.0. I?ll keep my eyes on that to make sure we don?t collide (and cc:ing Martin for good luck). > > Would appreciate some help from the respective porting folks to verify the aix/ppc/s390 changes. > > Cheers, > Mikael > > [1] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-July/029099.html Looks good. From mikael.vidstedt at oracle.com Wed Jul 11 22:52:26 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 11 Jul 2018 15:52:26 -0700 Subject: RFR(S): 8207011: Remove uses of the register storage class specifier Message-ID: Please review the below change which removes *most* uses of the register keyword/storage class specifier. Bug: https://bugs.openjdk.java.net/browse/JDK-8207011 Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8207011/webrev.01/open/webrev/ * Background (from the bug) The C/C++ register keyword/storage class specifier may have made a difference many moons ago, but the C++11 standard deprecated it, and starting with C++17 it is a reserved keyword. Some compilers emit deprecation warnings even when targeting earlier C++ standards such as C++14. * Commentary The one case where the register keyword remains is when compiling (effectively) inline assembly with gcc, patterns like: address os::current_stack_pointer() { ? #else // gcc register void *esp __asm__ (SPELL_REG_SP); return (address) esp; #endif } Removing the register keyword here breaks the code, and gcc does *not* complain about using it for these patterns, so I chose to leave it there. An alternative to that would be to always use the ?clang? style mov instruction. I know there is another thread[1] discussing how to move forward with the current_stack_pointer on clang 4.0. I?ll keep my eyes on that to make sure we don?t collide (and cc:ing Martin for good luck). Would appreciate some help from the respective porting folks to verify the aix/ppc/s390 changes. Cheers, Mikael [1] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-July/029099.html From takiguc at linux.vnet.ibm.com Thu Jul 19 18:06:06 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Fri, 20 Jul 2018 03:06:06 +0900 Subject: Console.readPassword() was failed on Linux s390x platform Message-ID: <76e6aabf100ac4e5a01fcdf95c52c1d8@linux.vnet.ibm.com> Hello. I ran following testcase on Linux s390x platform. ------ import java.io.Console; public class ConsoleTestC { public static void main(String[] args) { Console console = System.console(); char password[] = console.readPassword("password> "); System.out.println(password); } } ------ Test instruction 1. Compile and run ConsoleTestC on terminal $ java ConsoleTestC password> 2. Type "abc", then "abc" is displayed 3. Type "ls", but nothing is displayed 4. Type "stty echo" to change back the setting I wrote following program for PD. ------ import java.io.*; import java.lang.reflect.*; public class ConsoleTestB { public static void main(String[] args) throws Exception { Console console = System.console(); Method echo = Console.class.getDeclaredMethod("echo", boolean.class); echo.setAccessible(true); System.out.println("echo false"); System.out.println(echo.invoke(console, false)); console.reader().read(); System.out.println("echo true"); System.out.println(echo.invoke(console, true)); } } ------ Test instruction 1. Compile and run ConsoleTestB on terminal $ java ConsoleTestB ...... echo false false 2. Last output should be "true", so Java could not read echo flag properly 3. Press return key echo true false $ Console.readPassword() could not read initial echo flag, so move back to "-echo" instead of "echo" Fix candidate is as follows: ====== diff -r 14708e1acdc3 src/java.base/unix/native/libjava/Console_md.c --- a/src/java.base/unix/native/libjava/Console_md.c Tue Jul 03 09:27:41 2018 +0800 +++ b/src/java.base/unix/native/libjava/Console_md.c Fri Jul 20 02:52:38 2018 +0900 @@ -56,7 +56,7 @@ JNU_ThrowIOExceptionWithLastError(env, "tcgetattr failed"); return !on; } - old = (tio.c_lflag & ECHO); + old = (tio.c_lflag & ECHO) == ECHO ? JNI_TRUE : JNI_FALSE; if (on) { tio.c_lflag |= ECHO; } else { ====== I'd like to obtain a sponsor for this patch. Could you put it into JDK11 ? Thanks, Ichiroh Takiguchi IBM Japan, Ltd. From martinrb at google.com Thu Jul 12 18:42:06 2018 From: martinrb at google.com (Martin Buchholz) Date: Thu, 12 Jul 2018 18:42:06 -0000 Subject: RFR(S): 8207011: Remove uses of the register storage class specifier In-Reply-To: References: Message-ID: On Wed, Jul 11, 2018 at 3:52 PM, Mikael Vidstedt wrote: > > Removing the register keyword here breaks the code, and gcc does *not* > complain about using it for these patterns, so I chose to leave it there. > An alternative to that would be to always use the ?clang? style mov > instruction. I know there is another thread[1] discussing how to move > forward with the current_stack_pointer on clang 4.0. I?ll keep my eyes on > that to make sure we don?t collide (and cc:ing Martin for good luck). > As I wrote elsewhere, I'd like to get rid of the super-brittle stack pointer assembly entirely, but especially for stack alignment checking.