Hi Joe,
The value is from the operating system as it keeps track of cputime for
each process as
reported by java.lang.management. It starts at zero for each process
started.
static long getCpuTime() {
OperatingSystemMXBean osMbean =
(OperatingSystemMXBean)ManagementFactory.getOperatingS
Hi Roger,
Le me be more explicit, is getCpuTime() something that gets normalized
to zero-ish at the start of each run or is it just a shapshot of some
nano-second granularity counter? If it is the latter, it is possible
that the counter value is negative or near the long overflow threshold.
Looks good Roger; thanks,
-Joe
On 7/8/2015 2:08 PM, Roger Riggs wrote:
Hi Joe,
Webrev updated in place.
The jdk.testlibrary.Utils.adjustTimeout(timeout) returns the timeout
adjusted
by the jtreg -timeoutFactor argument.
Thanks, Roger
On 7/8/2015 4:50 PM, joe darcy wrote:
Hi Roger,
I th
Hi Joe,
The cputime loop is designed to run up the cputime of a child process a
specific
amount so that the parent can verify that the cputime information reported
about the child is correct.
No issues on either point, the range long in nanoseconds is more than
sufficient for
the length of t
Hi Joe,
Webrev updated in place.
The jdk.testlibrary.Utils.adjustTimeout(timeout) returns the timeout
adjusted
by the jtreg -timeoutFactor argument.
Thanks, Roger
On 7/8/2015 4:50 PM, joe darcy wrote:
Hi Roger,
I think the test would be more robust if the hard-coded time out
window was a
Hi Roger,
A few comments on the updated version.
284 long cpuMillis =
Long.valueOf(args[nextArg++]);
285 long cpuTarget = getCpuTime() + cpuMillis
* 1_000_000L;
286 while (getCpuTime() < cpuTarget) {
287
Hi Roger,
I think the test would be more robust if the hard-coded time out window
was a function of the time factor the test was running under. Maybe
10 seconds * timeout
IIRC, the timeout factor is available as an environment variable (or
similar) in the running tests. I checked the jtr
Ping and note this change is simplified after the fix for 8085981.
Please review this change to a ProcessHandle test to address
intermittent failures.
Unexpected subprocesses has been observed. The test succeeds if all of the
processes under test are accounted for; others are ignored.
Webrev:
Hi Joe,
Updated the webrev in place.
http://cr.openjdk.java.net/~rriggs/webrev-info-8098852/
On 7/7/2015 7:59 PM, joe darcy wrote:
Hi Roger,
Generally looks okay; a few comments and suggestions
114 long cpulooptime = 100; // 100 ms
How about
cpuLoopTime
ok
On Wed, Jul 8, 2015 at 12:59 AM, Paul Sandoz wrote:
>
> > The comment remains correct even if 6260652 is fixed.
> > I can't think up a clearly better one.
>
> I would recommend at least removing the issue id (since that refers
> specifically to Arrays.asList rather than something general that can
Thanks Sherman for looking to that!
On 11.07.2015 20:22, Xueming Shen wrote:
Hi,
Arguably the "StringIndexOutOfBoundsException" should only be used
when the index is out
of a "String" (the builder included) boundary, but the offending
object and the index here is
CharSequence/index. The place
Hi,
Arguably the "StringIndexOutOfBoundsException" should only be used when the
index is out
of a "String" (the builder included) boundary, but the offending object and the
index here is
CharSequence/index. The places that throw StringIndexoutOfBoundsException are
all for the
index/offset/leng
Resending the request with a new bug id.
On 07.07.2015 15:55, Ivan Gerasimov wrote:
Hi!
With the fix for JDK-8077242 ((str) Optimize
AbstractStringBuilder.append(CharSequence, int, int) for String
argument) a change in behavior was introduced.
In the places, where sb.append(str.substring(fr
---
old/src/java.annotations.common/share/classes/javax/annotation/PostConstruct.java
2015-07-08 13:25:02.0 +0200
+++
new/src/java.annotations.common/share/classes/javax/annotation/PostConstruct.java
2015-07-08 13:25:01.0 +0200
- * Copyright (c) 2005, 2013, Oracle and/or its aff
> -Original Message-
> From: Kumar Srinivasan [mailto:kumar.x.sriniva...@oracle.com]
>
> Hi Kirk,
>
> Thanks for proposing this change.
>
> If you notice all the posix calls are wrapped in JLI_* this gives us the
> ability to use "W" functions. I almost got it done, several years ago,
Hi Miroslav,
At least some of the changes in the patch are going in the wrong
direction. There are many instances toward the start of the patch where
{@code Foo} is listed as being replaced by Foo, but {@code Foo}
is what we want to use now.
Are you running doclint over Java source or in a d
Hi everybody,
I'd like to ask for review for following issue:
JBS: 8130753: Sync-up javadoc changes in jax-ws area - includes JAX-B
API, JAX-WS API, SAAJ-API
webrev: http://cr.openjdk.java.net/~mkos/8130753/jaxws.01/
It addresses all the javadoc errors in all 3 JSRs: SAAJ, JAX-B and
JAX-WS an
On Jul 8, 2015, at 10:01 AM, Amy Lu wrote:
> tools/pack200/PackTestZip64.java
>
> This test has been observed to fail intermittently. This patch is to mark it
> accordingly with keyword 'intermittent'.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8130402
> webrev: http://cr.openjdk.java.ne
Hi Tagir,
Yes, i forgot about that, thanks, nice catch. Patch updated:
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071597-take-drop-while/webrev/
See below for a diff.
Paul.
diff -r 61bc2fe3b2c6
src/java.base/share/classes/java/util/stream/DoubleStream.java
--- a/src/java.base/share/clas
tools/pack200/PackTestZip64.java
This test has been observed to fail intermittently. This patch is to
mark it accordingly with keyword 'intermittent'.
bug: https://bugs.openjdk.java.net/browse/JDK-8130402
webrev: http://cr.openjdk.java.net/~amlu/8130402/webrev.00/
Thanks,
Amy
--- old/test/t
HI Martin,
Sorry the late reply.
On Jun 30, 2015, at 7:04 PM, Martin Buchholz wrote:
>
> The comment remains correct even if 6260652 is fixed.
> I can't think up a clearly better one.
I would recommend at least removing the issue id (since that refers
specifically to Arrays.asList rather tha
21 matches
Mail list logo
