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.
