Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK

Alan Bateman Alan.Bateman at oracle.com
Mon Apr 1 19:28:59 UTC 2013


On 27/03/2013 17:35, Mandy Chung wrote:
> This is the JDK change for JEP 176: JEP 176: Mechanical Checking of 
> Caller-Sensitive Methods [1].  Christian has posted the webrev for the 
> hotspot VM change a couple weeks ago [2].
>
> Webrev at:
> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7198429/webrev.00/
>
> While it touches many files, the fix is simple and straight-forward 
> for review.
I went through the latest webrev.01 and this looks very good.

I guess I was initially surprised to see @CS on some of the 
AccessController.doPrivileged methods as these usages aren't checked 
(although they are caller sensitive).

Did you consider adding a constant, JVM_DEPTH (-1) or some name like 
that, to jvm.h for the depth parameter?

I see Reflection.isCallerSensitive uses isExtClassLoader, we'll probably 
have to re-visit this in the future.

Doug and Chris are on this list but might not have seen that this 
updates AtomicXXXXFieldUpdaters. They need to be aware of this for 
future merges.

On the tests, does GetCallerClassTest really need to check the stack 
trace? It seems unnecessary.

One thing on the shell test (I read exchange about jtreg boot class path 
support) is that it needs the GPL header.

I was surprised to see CallerSensitiveFinder in the webrev and I'm 
curious how long it takes to run.

-Alan.



More information about the core-libs-dev mailing list