8044034: Remove unused com/sun/tools/hat files
These files are not used in the jdk repository and it'd be a good cleanup to remove them: jdk/src/share/classes/com/sun/tools/hat/MANIFEST.mf jdk/src/share/classes/com/sun/tools/hat/README.txt jdk/src/share/classes/com/sun/tools/hat/build.xml https://bugs.openjdk.java.net/browse/JDK-8044034 Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8044034/webrev.00/ Mandy
Re: [9] RFR (XS): JSR 292 support for PopFrame has a fragile coupling with DirectMethodHandle
Looks good. Would be good to put a FIXME on the comment as well so we don’t forget to remove it. On May 26, 2014, at 12:25 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com wrote: https://bugs.openjdk.java.net/browse/JDK-8034935 http://cr.openjdk.java.net/~vlivanov/8034935/webrev.00 Citing John's explanation of motivation for this change (from the bug): There is a coupling from bytecodes that call MethodHandle.linkToStatic (and similar linker methods) and the PopFrame feature. The linker methods accept an extra appendix argument of type MemberName which is popped from the list before vectoring to the desired method (it supplies the name of that method). In order to re-execute the call, the MemberName must be recovered somehow. Currently, the JVM assumes that the interpreter frame's local #0 will contain a DirectMethodHandle which holds the desired MemberName. The JVM should also accept the MemberName itself, and eventually stop looking for the DirectMethodHandle. This will simplify the handshake between JVM and JSR 292 implementation bytecodes. The DMH is difficult to recover at the point of call to linkToStatic, although the MemberName is guaranteed live at that point. Also, making this change (perhaps in two steps) will allow the JVM to stop coupling to SystemDictionary::DirectMethodHandle_klass. Such couplings should be minimized. Testing: JPRT, jtreg (java/lang/invoke), vm.mlvm.testlist Thanks! Best regards, Vladimir Ivanov
Re: [9] RFR (XS): JSR 292 support for PopFrame has a fragile coupling with DirectMethodHandle
Thanks, Chris. Will replicate FIXME comment at the end of method comment preamble as well. Best regards, Vladimir Ivanov On 5/27/14 9:05 PM, Christian Thalinger wrote: Looks good. Would be good to put a FIXME on the comment as well so we don’t forget to remove it. On May 26, 2014, at 12:25 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com wrote: https://bugs.openjdk.java.net/browse/JDK-8034935 http://cr.openjdk.java.net/~vlivanov/8034935/webrev.00 Citing John's explanation of motivation for this change (from the bug): There is a coupling from bytecodes that call MethodHandle.linkToStatic (and similar linker methods) and the PopFrame feature. The linker methods accept an extra appendix argument of type MemberName which is popped from the list before vectoring to the desired method (it supplies the name of that method). In order to re-execute the call, the MemberName must be recovered somehow. Currently, the JVM assumes that the interpreter frame's local #0 will contain a DirectMethodHandle which holds the desired MemberName. The JVM should also accept the MemberName itself, and eventually stop looking for the DirectMethodHandle. This will simplify the handshake between JVM and JSR 292 implementation bytecodes. The DMH is difficult to recover at the point of call to linkToStatic, although the MemberName is guaranteed live at that point. Also, making this change (perhaps in two steps) will allow the JVM to stop coupling to SystemDictionary::DirectMethodHandle_klass. Such couplings should be minimized. Testing: JPRT, jtreg (java/lang/invoke), vm.mlvm.testlist Thanks! Best regards, Vladimir Ivanov
Re: 8044034: Remove unused com/sun/tools/hat files
Looks good! Thanks, /Staffan On 27 maj 2014, at 18:52, Mandy Chung mandy.ch...@oracle.com wrote: These files are not used in the jdk repository and it'd be a good cleanup to remove them: jdk/src/share/classes/com/sun/tools/hat/MANIFEST.mf jdk/src/share/classes/com/sun/tools/hat/README.txt jdk/src/share/classes/com/sun/tools/hat/build.xml https://bugs.openjdk.java.net/browse/JDK-8044034 Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8044034/webrev.00/ Mandy
Re: [9] RFR (XS): JSR 292 support for PopFrame has a fragile coupling with DirectMethodHandle
Reviewed; thank you. — John On May 26, 2014, at 12:25 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com wrote: http://cr.openjdk.java.net/~vlivanov/8034935/webrev.00
Re: [9] RFR (XS): JSR 292 support for PopFrame has a fragile coupling with DirectMethodHandle
Vladimir, It looks good. Thanks, Serguei On 5/26/14 12:25 PM, Vladimir Ivanov wrote: https://bugs.openjdk.java.net/browse/JDK-8034935 http://cr.openjdk.java.net/~vlivanov/8034935/webrev.00 Citing John's explanation of motivation for this change (from the bug): There is a coupling from bytecodes that call MethodHandle.linkToStatic (and similar linker methods) and the PopFrame feature. The linker methods accept an extra appendix argument of type MemberName which is popped from the list before vectoring to the desired method (it supplies the name of that method). In order to re-execute the call, the MemberName must be recovered somehow. Currently, the JVM assumes that the interpreter frame's local #0 will contain a DirectMethodHandle which holds the desired MemberName. The JVM should also accept the MemberName itself, and eventually stop looking for the DirectMethodHandle. This will simplify the handshake between JVM and JSR 292 implementation bytecodes. The DMH is difficult to recover at the point of call to linkToStatic, although the MemberName is guaranteed live at that point. Also, making this change (perhaps in two steps) will allow the JVM to stop coupling to SystemDictionary::DirectMethodHandle_klass. Such couplings should be minimized. Testing: JPRT, jtreg (java/lang/invoke), vm.mlvm.testlist Thanks! Best regards, Vladimir Ivanov
