RFR (M): 7198429: need checked categorization of caller-sensitive methods in the JDK (original) (raw)

Christian Thalinger christian.thalinger at oracle.com
Fri Mar 15 17:53:16 PDT 2013


On Mar 15, 2013, at 3:08 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

Why do you need a switch in next code in LibraryCallKit::inlinenativeReflectiongetCallerClass()? I don't think you need to match JVMGetCallerClass code one-to-one. You don't have =0 case and the check for =1 could be done before loop. It will simplify code.

Yes it would but I want to keep the code as similar as possible to make future changes easier. If I could I would factor the code to a method but that doesn't work very well. I'd like to keep it as it is.

Adjust next comment to reference JVMGetCallerClass: // Frame 0 and 1 must be caller sensitive (see JVMGetCallerClass)

There is a comment right before the loop:

// Cf. JVM_GetCallerClass

but I can add this one too.

I think in JVMGetCallerClass() you can use intrinsicid: m->intrinsicid() == vmIntrinsics::getCallerClass

You're right. I missed that. Then I can undo the reflect_Reflection_klass change.

The webrev is updated:

http://cr.openjdk.java.net/~twisti/7198429/

-- Chris

Thanks, Vladimir On 3/14/13 8:31 PM, Christian Thalinger wrote: [This is the HotSpot part of JEP 176]

http://cr.openjdk.java.net/~twisti/7198429 7198429: need checked categorization of caller-sensitive methods in the JDK Reviewed-by: More information in JEP 176: http://openjdk.java.net/jeps/176 src/share/vm/ci/ciMethod.cpp src/share/vm/ci/ciMethod.hpp src/share/vm/classfile/classFileParser.cpp src/share/vm/classfile/classFileParser.hpp src/share/vm/classfile/javaClasses.hpp src/share/vm/classfile/systemDictionary.hpp src/share/vm/classfile/vmSymbols.hpp src/share/vm/oops/method.cpp src/share/vm/oops/method.hpp src/share/vm/opto/librarycall.cpp src/share/vm/prims/jvm.cpp src/share/vm/prims/methodHandles.cpp src/share/vm/prims/unsafe.cpp src/share/vm/runtime/vframe.cpp src/share/vm/runtime/vframe.hpp



More information about the hotspot-dev mailing list