On Wed, Nov 12, 2014 at 6:25 PM, roger riggs wrote:
> Hi Martin,
>
> I think that sleep is the version that spawns a JavaChild process and
> has its own comment interpreter. See line 309: Am I getting the sleeps mixed
> up?
Ah, good point - yes, you're right. Although we could always bump up
the
Hi Martin,
I think that sleep is the version that spawns a JavaChild process and
has its own comment interpreter. See line 309: Am I getting the sleeps
mixed up?
Roger
On 11/12/2014 6:32 PM, Martin Buchholz wrote:
Hi Roger,
On Wed, Nov 12, 2014 at 1:57 PM, roger riggs wrote:
Hi Martin
Ok, you're right.
On Wed, Nov 12, 2014 at 11:19 PM, Wang Weijun
wrote:
> I hope we can restrict the code change to what the bug description is
> about. IMHO this bug should only include cleanup and introduce no obvious
> behavior change.
>
> Any other fix can go to another bug.
>
> --Max
>
> > O
I hope we can restrict the code change to what the bug description is about.
IMHO this bug should only include cleanup and introduce no obvious behavior
change.
Any other fix can go to another bug.
--Max
> On Nov 13, 2014, at 08:57, Otávio Gonçalves de Santana
> wrote:
>
> But this class is
But this class is an Exception, doesn't make sense an exception get another
Exception.
IMHO: I prefer this way
On Wed, Nov 12, 2014 at 8:36 AM, Ulf Zibis wrote:
> Hi Otávio,
> I now think you could replace
> if (!expected.isEmpty())
> with
> assert !expected.isEmpty();
>
> If e
Oh. I just replied to the wrong email. Anyway, here it goes again:
Maybe we should CC sound-dev (if that’s the correct list)?
The new jvm.cfg files should only have a copyright year of 2014.
Otherwise this looks good.
On Nov 12, 2014, at 3:48 AM, Andrew Haley wrote:
The changes for the /
Hi Roger,
On Wed, Nov 12, 2014 at 1:57 PM, roger riggs wrote:
> Hi Martin,
>
> I updated the webrev to use long timeouts for the test in question; they
> can't be too long
> because the spawned sleep is only alive for 10 seconds.
I am looking at the "sleep" command invocation, but it's an inde
On 11.11.2014 17:40, Aleksey Shipilev wrote:
> On 11/09/2014 09:45 PM, Aleksey Shipilev wrote:
>> Thread.getName() returns String, and does new String instantiation every
>> time, because the thread name is stored in char[]. Even though we use a
>> private String constructor that shares the char[]
On 12/11/2014 8:23 PM, Aleksey Shipilev wrote:
Hi David,
On 12.11.2014 07:48, David Holmes wrote:
On 12/11/2014 12:40 AM, Aleksey Shipilev wrote:
All looks good to me.
Thanks for the review!
But I also noticed this strange (to me) assertion in javaClasses.cpp
void java_lang_Thread::set_n
Hi Martin,
I updated the webrev to use long timeouts for the test in question; they
can't be too long
because the spawned sleep is only alive for 10 seconds.
Take a look please:
http://cr.openjdk.java.net/~rriggs/webrev-basic-debug-8043477/
Thanks, Roger
On 11/12/2014 4:45 PM, Martin Buchh
Looking over the test again (I was the original author IIRC),
I think this test still has lots of value with a longer timeout.
Experience seems to show that 200ms is not a long enough timeout for
"system" operations to use in non-flaky tests, including everything in
Process handling.
I say we ncre
Hi Martin, Rob,
I thought the point of the test was to verify the timeout logic in
waitFor(timeout).
Adding the prints without changing the test criteria was intended to
gather data
about the distribution.
A long timeout would still catch a failure in the reaper/waitFor
communication
so may
Eesh, Sorry Roger, I have something like this on my todo.
Martin, my concern with the long delay approach is that it effectively
nullifies the point of the test. Given that this test has been flakey
the approach has been to simply bump the acceptable delta by another
100ms or so every time. Si
The print statement below seems redundant with the assertion failure message.
You could improve the assertion message instead if need be.
Adding thousand separator underscores to 2L would help a little.
I like my little helper
static long millisElapsedSince(long startNanoTime) {
Please review test changes to ProcessBuilder Basic.java to add some
debugging information.
The test has been failing intermittently. The wait times have been
extended to see
if the systems are just slow. The failure criteria have not changed.
Suggestions welcome.
Webrev:
http://cr.openjdk
Hello Peter,
> Sadly, this seems not to be the case for MemberNames or for “Types”.
That statement is inoperative. Mistakes were made.
It’s compareTo that they lack.
David
On 2014-11-09, at 7:55 AM, Peter Levart wrote:
> Hi David,
>
> I played a little with the idea of having a hash tabl
Hello Peter,
I was looking at this (thinking it would be a useful thing to benchmark,
looking for possible improvements)
and noticed that you rely on the hashed objects having a sensible
value-dependent hashcode (as opposed
to the default Object hashcode). Sadly, this seems not to be the case f
Hi Otávio,
I now think you could replace
if (!expected.isEmpty())
with
assert !expected.isEmpty();
If expected ever would be empty, the only thing which happens is, that a "'" is missing in a message
which anyway doesn't make sense without arguments.
-Ulf
Am 12.11.2014 um
Hi David,
On 12.11.2014 07:48, David Holmes wrote:
> On 12/11/2014 12:40 AM, Aleksey Shipilev wrote:
> All looks good to me.
Thanks for the review!
> But I also noticed this strange (to me) assertion in javaClasses.cpp
>
> void java_lang_Thread::set_name(oop java_thread, oop name) {
> asse
Thanks Staffan!
-Aleksey.
On 11.11.2014 23:38, Staffan Larsen wrote:
> SA changes look good.
>
> /Staffan
>
>> On 11 nov 2014, at 15:40, Aleksey Shipilev
>> wrote:
>>
>> Hi,
>>
>> On 11/09/2014 09:45 PM, Aleksey Shipilev wrote:
>>> Thread.getName() returns String, and does new String instanti
20 matches
Mail list logo
