Hi Roger,
The test has been updated. It now uses System.nanoTime.
http://cr.openjdk.java.net/~egahlin/8028474_6/
Thanks
Erik
roger riggs skrev 2014-07-01 14:35:
Hi Erik,
Consider switching to System.nanoTime; it is not sensitive to clock
changes
and avoids leaving a land mine that may
Hi Erik,
nice cleanup!
L160 break statement after this line would save unnecessary iterating
when a process has already been found
L172 You could use return true. -
'MonitoredVmUtil.mainArgs(target).contains(args)' has been asserted to
be true on L171
-JB-
On 07/03/2014 01:06 PM, Erik
On 07/03/2014 04:44 PM, Erik Gahlin wrote:
Hi Jaroslav,
Here is an updated webrev:
http://cr.openjdk.java.net/~egahlin/8028474_7/
Thanks. No more comments.
-JB-
See comments inline.
Jaroslav Bachorik skrev 2014-07-03 16:03:
Hi Erik,
nice cleanup!
L160 break statement after this line
I’m still ok with this.
/Staffan
On 3 jul 2014, at 16:42, Jaroslav Bachorik jaroslav.bacho...@oracle.com wrote:
On 07/03/2014 04:44 PM, Erik Gahlin wrote:
Hi Jaroslav,
Here is an updated webrev:
http://cr.openjdk.java.net/~egahlin/8028474_7/
Thanks. No more comments.
-JB-
See
On 1/07/2014 10:35 PM, roger riggs wrote:
Hi Erik,
Consider switching to System.nanoTime; it is not sensitive to clock changes
Not completely true unfortunately. The change to use CLOCK_MONOTONIC_RAW
will make it true (OS bugs not withstanding).
But I would suggest switching anyway.
Updated webrev:
http://cr.openjdk.java.net/~egahlin/8028474_5/
See comments inline.
Staffan Larsen skrev 2014-06-26 13:22:
Indentation around JavaProcess.getId() is weird.
Fixed
JavaProcess.getPid/setPid/pid do not appear to be used.
Fixed
JavaProcess.waitForRemoval: How about using
Looks good!
Thanks,
/Staffan
On 1 jul 2014, at 09:37, Erik Gahlin erik.gah...@oracle.com wrote:
Updated webrev:
http://cr.openjdk.java.net/~egahlin/8028474_5/
See comments inline.
Staffan Larsen skrev 2014-06-26 13:22:
Indentation around JavaProcess.getId() is weird.
Fixed
Hi Erik,
Consider switching to System.nanoTime; it is not sensitive to clock changes
and avoids leaving a land mine that may cause a spurious non-repeatable
test failure.
'Deducing it from the log' means there is a failure and creates probably
an hour or two of work
for some quality engineer
Indentation around JavaProcess.getId() is weird.
JavaProcess.getPid/setPid/pid do not appear to be used.
JavaProcess.waitForRemoval: How about using timestamps (currentTimeMillis())
before the loop and for each iteration to determine if the timeout has expired
(instead of time+=100”)?
nit:
Erik,
How about using Process.destroyForcibly() as a means to terminate the process
instead of using files for signaling?
/Staffan
On 17 jun 2014, at 23:13, Erik Gahlin erik.gah...@oracle.com wrote:
Yes, very weird
Could have been that I needed the tools.jar in the child processes, or it
Didn't know about destroyForcibly(). I could try that.
Erik
Staffan Larsen skrev 18/06/14 09:26:
Erik,
How about using Process.destroyForcibly() as a means to terminate the
process instead of using files for signaling?
/Staffan
On 17 jun 2014, at 23:13, Erik Gahlin erik.gah...@oracle.com
Yes, very weird
Could have been that I needed the tools.jar in the child processes, or
it could have been something else. If I remember correctly, I got a CNF
that I didn't get with the shell script, but it was few months back.
Anyway, I retried with JPRT and now it works without the shell
Hi Dmitry,
I'm not worried about files being left behind from a previous run , they
all have unique names.
Erik
Dmitry Samersoff skrev 2014-06-16 14:39:
Erik,
It's better to check lock-file age rather than maintain in-process
timeout variable, it guards the test from the situation when
Erik,
It should work see e.g.
hotspot/test/runtime/RedefineFinalizer
you might need to add
-Xbootclasspath/a:tools.jar to @run
and
-XDignore.symbol.file to @compile
-Dmitry
On 2014-06-16 14:32, Erik Gahlin wrote:
Yekaterina Kantserova skrev 13/06/14 12:59:
Erik,
is there some reason
14 matches
Mail list logo
