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

Alan Bateman Alan.Bateman at oracle.com
Tue Apr 2 14:41:31 UTC 2013


On 02/04/2013 00:25, Mandy Chung wrote:
>
> These few methods are the special case that their usage are not 
> checked.  This raises a good point  how we could enforce the check and 
> whether it's appropriate to check in JVM_DoPrivileged.  I will file a 
> bug to follow up this separately if you are okay.
Thanks.


>
>>
>> On the tests, does GetCallerClassTest really need to check the stack 
>> trace? It seems unnecessary.
>>
>
>
> The stack trace check tries to catch if InternalError is thrown for 
> other reason.  Such regression might be rare but I prefer to perform 
> an appropriate check while the test can reliably run.
Okay, my comment that mostly that this checking seem a bit over-the-top.




> :
>
>> I was surprised to see CallerSensitiveFinder in the webrev and I'm 
>> curious how long it takes to run.
>>
>
> This is one discussion point I'd like to have.  I was debating myself 
> initially if this test should be enabled or not.  What I found it 
> takes 5-14 sec.
> Some sample timing on the jprt machines:
>    linux_i586 jdk_lang took 14 mins and CallerSensitiveFinder took 8.5 
> sec
>    macosx_x64 jdk_lang took 20.5 mins and CallerSensitiveFinder took 
> 14.5 sec
>    solaris_i586 jdk_lang took 15.5 mins and CallerSensitiveFinder took 
> 10 sec
>    windows_x64 jdk_lang took 16.5 mins and CallerSensitiveFinder took 
> 10 sec
>
> We discussed tagging stress tests or long running tests so that they 
> can be run on demand.  I think this test would also be appropriate to 
> be run in post-build hudson job, kind of tests.
The duration is a lot less than I expected and I don't object to 
including it, it just seem more like something to run post-build as your 
suggest.

-Alan.




More information about the core-libs-dev mailing list