RFR (S): 8076461: JSR292: remove unused native and constants

Michael Haupt michael.haupt at oracle.com
Mon Apr 13 11:40:08 UTC 2015


Hi John,

thank you very much for your review; keeping the Constants class around for VM/JDK constant value agreement certainly makes sense. I have undone most of the removal work and verified in a slowdebug build that MHN.verifyConstants() works. I've also added a comment on the Constants class to clarify its role a bit. Local tests and JPRT are still happy with this.

Updated webrev: http://cr.openjdk.java.net/~mhaupt/8076461/webrev.01/

Best,

Michael

> Am 07.04.2015 um 23:49 schrieb John Rose <john.r.rose at oracle.com>:
> 
> On Apr 7, 2015, at 12:11 PM, Michael Haupt <michael.haupt at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150413/760673eb/attachment-0001.html>


More information about the hotspot-compiler-dev mailing list