On Apr 7, 2015, at 12:11 PM, Michael Haupt <michael.ha...@oracle.com> wrote: > > Dear all, > > please review and sponsor this change. Cross-posted to hs-comp and core-lib > as this is at the JVM/libraries boundary. This is a straightforward > refactoring change that removes many constants and unused API from MHNatives, > and places some constants used only in MemberName in that class.
The class MethodHandleNatives.Constants exists to enumerate and cross-check any constants which the JVM and JDK code need to agree about. Removing a constant from MethodHandleNatives.Constants (moving to MemberName) may cause failures when MHN.verifyConstants is run (via "java -esa" on a debug build of Java). If there are no failures, I wonder what would happen if the JVM and JDK got out of sync. in their notion of the value of a constant like MN_CALLER_SENSITIVE. It's important that some part of our release testing detect if MN_CALLER_SENSITIVE (etc.) gets out of sync. If there is some reason why this testing is no longer needed, I'd like to see the whole Constants class go away, since that's all it's really good for. But I don't see that reason yet, and moving the constants somewhere either will cause a test failure, or *should* cause a test failure. I'm happy to see the "GC" guys go away. They were artifacts of a quickly moving 292 implementation that spanned two repositories with unsynchronized change streams. — John > > RFE: https://bugs.openjdk.java.net/browse/JDK-8076461 > Changes: http://cr.openjdk.java.net/~mhaupt/8076461/webrev.00/ > > Tested with JPRT, HotSpot testset. > > Thanks, > > Michael > > -- > > <http://www.oracle.com/> > Dr. Michael Haupt | Principal Member of Technical Staff > Phone: +49 331 200 7277 | Fax: +49 331 200 7561 > Oracle Java Platform Group | HotSpot Compiler Team > Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany > <http://www.oracle.com/commitment> Oracle is committed to developing > practices and products that help protect the environment >
