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