Jaroslav,
Can you summarise the changes please? With the conversion to Java and
the infrastructure additions I can't tell what is actually fixing the
original timeout issue :)
Thanks,
David
On 8/10/2013 12:14 AM, Jaroslav Bachorik wrote:
On 19.9.2013 16:33, Jaroslav Bachorik wrote:
The upd
Jaroslav,
Thumbs up!
Thank you for addressing my comments.
-Dmitry
On 2013-10-07 21:10, Jaroslav Bachorik wrote:
> On 7.10.2013 16:31, Dmitry Samersoff wrote:
>> Jarsolav,
>>
>> Looks good for me, comments below is just a nits - so fill free to
>> ignore it.
>>
>> 1.
>> As FS.getPath(TEST_JDK,
On 7.10.2013 16:31, Dmitry Samersoff wrote:
Jarsolav,
Looks good for me, comments below is just a nits - so fill free to
ignore it.
1.
As FS.getPath(TEST_JDK, "jre", "lib", LIBARCH) is the only value for
findLibjvm parameter, It's better to create an overload function
findLibjvm().
2.
it's bet
On 7.10.2013 18:47, Dmitry Samersoff wrote:
Jaroslav,
Can you elaborate why checking for the current user being able to read
the actual library file might be wrong?
It's not applicable to this particular testcase (so I'd marked it as a
nit) but a generic security rule is to always check that
Jaroslav,
> Can you elaborate why checking for the current user being able to read
> the actual library file might be wrong?
It's not applicable to this particular testcase (so I'd marked it as a
nit) but a generic security rule is to always check that we deal with a
regular file.
Try to link an
On 7.10.2013 16:31, Dmitry Samersoff wrote:
Jarsolav,
Looks good for me, comments below is just a nits - so fill free to
ignore it.
1.
As FS.getPath(TEST_JDK, "jre", "lib", LIBARCH) is the only value for
findLibjvm parameter, It's better to create an overload function
findLibjvm().
Ok. It wil
This will make it less likely for the test to fail, but does not guarantee it
since there is nothing that says classloading will be done in 300 ms. Any
failures will unfortunately be harder to reproduce. (And the test is now 300 ms
slower to run.)
A different solution is to only allow the numbe
On 7.10.2013 16:22, Daniel Fuchs wrote:
Hi Jaroslav,
I am not an expert in classloading but I don't see any obvious
issue with what you propose.
I hope there is none :) If the number of loaded classes is not changing
the test should continue immediately. The only problem could be loading
the
Jarsolav,
Looks good for me, comments below is just a nits - so fill free to
ignore it.
1.
As FS.getPath(TEST_JDK, "jre", "lib", LIBARCH) is the only value for
findLibjvm parameter, It's better to create an overload function
findLibjvm().
2.
it's better to check for File.isFile() - readable (e.g
Hi Jaroslav,
I am not an expert in classloading but I don't see any obvious
issue with what you propose.
I wonder whether making the test always run in /othervm mode
might make it more stable.
best regards,
-- daniel
On 10/7/13 3:59 PM, Jaroslav Bachorik wrote:
The test captures the number o
On 19.9.2013 16:33, Jaroslav Bachorik wrote:
The updated webrev: http://cr.openjdk.java.net/~jbachorik/8004926/webrev.03
I've moved some of the functionality to the testlibrary.
-JB -
On 12.9.2013 17:31, Jaroslav Bachorik wrote:
On 09/12/2013 05:13 PM, Dmitry Samersoff wrote:
Jaroslav,
Cust
The test captures the number of loaded classes right at the start and
then checks the diffs when it's finished. However, it seems that there
might by some async class loading still going on, initiated by JFR.
The patch simply adds a loop to wait for the number of loaded classes to
settle befor
12 matches
Mail list logo
