hg: jdk8/tl/jdk: 8025198: Intermittent test failure: java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java

[david . holmes]

Changeset: d19ab5da83cc
Author:dholmes
Date:  2013-11-04 06:58 -0500
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d19ab5da83cc

8025198: Intermittent test failure: 
java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java
Reviewed-by: martin, dholmes
Contributed-by: Tristan Yan 

! makefiles/CompileLaunchers.gmk
! makefiles/lib/CoreLibraries.gmk
! src/share/bin/java.c
! test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java

URGENT - In correct push Fwd: [JBS] (JDK-8025198) Intermittent test failure: java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java

[David Holmes]

My commit pulled in a bunch of local changes that should never have been 
pushed (the import commit failed due to whitespace and when I re-issued 
the commit I didn't restrict it to the single test file).


Can anyone roll this back on the actual server?

Thanks,
David

 Original Message 
Subject: [JBS] (JDK-8025198) Intermittent test failure: 
java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java

Date: Mon, 4 Nov 2013 12:03:22 + (UTC)
From: HG Updates (JBS) 
To: david.hol...@oracle.com


 [ 
https://bugs.openjdk.java.net/browse/JDK-8025198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel 
]


HG Updates resolved JDK-8025198.


Resolved In Build: team
Fix Version/s: 8
   Resolution: Fixed

URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d19ab5da83cc
User:  dholmes
Date:  2013-11-04 12:01:30 +



Intermittent test failure: 
java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java
-

Key: JDK-8025198
URL: https://bugs.openjdk.java.net/browse/JDK-8025198
Project: JDK
 Issue Type: Bug
 Components: core-libs
   Affects Versions: 8
   Reporter: Amy Lu
   Assignee: Tristan Yan
 Labels: same-binary, sqebug, teststabilization
Fix For: 8


TESTFAIL:java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java
java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java failing 
intermittently:
#section:main
--messages:(3/175)--
command: main -XX:-UseVMInterruptibleIO ThrowingTasks
reason: User specified action: run main/othervm -XX:-UseVMInterruptibleIO 
ThrowingTasks
elapsed time (seconds): 480.015
--System.out:(0/0)--
--System.err:(0/0)--
result: Error. Program `/Users/aurora/sandbox_keepme/jdk/bin/java' interrupted! 
(timed out?)


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA 
administrators: 
https://bugs.openjdk.java.net/secure/ContactAdministrators!default.jspa

For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: URGENT - In correct push Fwd: [JBS] (JDK-8025198) Intermittent test failure: java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java

[Alan Bateman]

On 04/11/2013 12:10, David Holmes wrote:
My commit pulled in a bunch of local changes that should never have 
been pushed (the import commit failed due to whitespace and when I 
re-issued the commit I didn't restrict it to the single test file).


Can anyone roll this back on the actual server?
It might be simpler to just push another change that anti-deltas the 
launcher/other changes. That would get jdk8/tl fixed up before too many 
people are impacted.


-Alan.

Re: URGENT - In correct push Fwd: [JBS] (JDK-8025198) Intermittent test failure: java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java

[David Holmes]

On 4/11/2013 10:35 PM, Alan Bateman wrote:

On 04/11/2013 12:10, David Holmes wrote:

My commit pulled in a bunch of local changes that should never have
been pushed (the import commit failed due to whitespace and when I
re-issued the commit I didn't restrict it to the single test file).

Can anyone roll this back on the actual server?

It might be simpler to just push another change that anti-deltas the
launcher/other changes. That would get jdk8/tl fixed up before too many
people are impacted.


Okay RFR sent out to core-libs. Thanks Alan.

Apologies for the mess and the noise.

David


-Alan.

hg: jdk8/tl/jdk: 8027755: Anti-delta incorrect push for 8025198

[david . holmes]

Changeset: 23982079ad49
Author:dholmes
Date:  2013-11-04 07:39 -0500
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/23982079ad49

8027755: Anti-delta incorrect push for 8025198
Reviewed-by: alanb

! makefiles/CompileLaunchers.gmk
! makefiles/lib/CoreLibraries.gmk
! src/share/bin/java.c

Re: RFR 8027687: The constructors of URLPermission class do not behave as described in javadoc

[Michael McMahon]

Vitaly,

Good points, I agree. I think the optimisation is worthwhile
and not costly. I also found a small casting issue with
StringBuilder.append(char)
being interpreted as StringBuilder.append(int)

Here is the updated webrev:

http://cr.openjdk.java.net/~michaelm/8027687/webrev.2/

Thanks,
Michael


On 02/11/13 01:03, Vitaly Davidovich wrote:


The size to use is the length of the argument, which you're already 
using for the loop.


On a separate note, is toLowerCase in a perf sensitive area? It makes 
an assumption that the lowering will need to happen (by always 
allocating the stringbuilder) but is that a common case? If this isn't 
perf sensitive then disregard.


Thanks

Sent from my phone

On Nov 1, 2013 4:28 PM, "Michael McMahon" 
mailto:michael.x.mcma...@oracle.com>> 
wrote:


On 01/11/13 18:06, Mike Duigou wrote:

A couple minor quibbles

- Since the length is know the StringBuildiler can be created
with a size.


Right, 255 is probably a good size to use.

- sb.toString() is probably more efficient than new String(sb)


Since Chris also suggests it, I'm curious why this is. Is there
some clever sharing going on between
StringBuilder and String?

- I would like to see some IDN URL cases in the tests.


The first version of this class doesn't support Unicode strings in
the hostname labels.
So, I'm guessing you mean cases of IDNs that have been already
converted
into the ascii encoded form  (eg xn--blahblah.xn-blah.com
). Something I'd like to do
for JDK 9 will be to allow transparent Unicode in classes like
URLPermission with
automatic IDN conversions taking place in the http protocol handler.
So, I can add some cases of encoded IDNs in the test okay.

Thanks!

Michael

Mike

On Nov 1 2013, at 07:46 , Michael McMahon
mailto:michael.x.mcma...@oracle.com>> wrote:

Simple bug fix to new URLPermission class, caused by
insufficient parameter checking
of the constructor.

webrev:
http://cr.openjdk.java.net/~michaelm/8027687/webrev.1/


Thanks,
Michael

Re: RFR 8027687: The constructors of URLPermission class do not behave as described in javadoc

[Vitaly Davidovich]

That looks better.  One suggestion is to use StringBuilder.append(s, 0, i)
to avoid temp substring.

Thanks

Sent from my phone
On Nov 4, 2013 8:35 AM, "Michael McMahon" 
wrote:

>  Vitaly,
>
> Good points, I agree. I think the optimisation is worthwhile
> and not costly. I also found a small casting issue with
> StringBuilder.append(char)
> being interpreted as StringBuilder.append(int)
>
> Here is the updated webrev:
>
> http://cr.openjdk.java.net/~michaelm/8027687/webrev.2/
>
> Thanks,
> Michael
>
>
> On 02/11/13 01:03, Vitaly Davidovich wrote:
>
> The size to use is the length of the argument, which you're already using
> for the loop.
>
> On a separate note, is toLowerCase in a perf sensitive area? It makes an
> assumption that the lowering will need to happen (by always allocating the
> stringbuilder) but is that a common case? If this isn't perf sensitive then
> disregard.
>
> Thanks
>
> Sent from my phone
> On Nov 1, 2013 4:28 PM, "Michael McMahon" 
> wrote:
>
>> On 01/11/13 18:06, Mike Duigou wrote:
>>
>>> A couple minor quibbles
>>>
>>> - Since the length is know the StringBuildiler can be created with a
>>> size.
>>>
>>
>> Right, 255 is probably a good size to use.
>>
>>  - sb.toString() is probably more efficient than new String(sb)
>>>
>>
>> Since Chris also suggests it, I'm curious why this is. Is there some
>> clever sharing going on between
>> StringBuilder and String?
>>
>>  - I would like to see some IDN URL cases in the tests.
>>>
>>
>> The first version of this class doesn't support Unicode strings in the
>> hostname labels.
>> So, I'm guessing you mean cases of IDNs that have been already converted
>> into the ascii encoded form  (eg xn--blahblah.xn-blah.com). Something
>> I'd like to do
>> for JDK 9 will be to allow transparent Unicode in classes like
>> URLPermission with
>> automatic IDN conversions taking place in the http protocol handler.
>> So, I can add some cases of encoded IDNs in the test okay.
>>
>> Thanks!
>>
>> Michael
>>
>>  Mike
>>>
>>> On Nov 1 2013, at 07:46 , Michael McMahon 
>>> wrote:
>>>
>>>  Simple bug fix to new URLPermission class, caused by insufficient
 parameter checking
 of the constructor.

 webrev: http://cr.openjdk.java.net/~michaelm/8027687/webrev.1/

 Thanks,
 Michael

>>>
>>
>

hg: jdk8/tl/jdk: 8027625: test/java/math/BigInteger/ExtremeShiftingTests.java needs @run tag to specify heap size

[brian . burkhalter]

Changeset: 92fb6baaebc4
Author:bpb
Date:  2013-11-04 08:05 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/92fb6baaebc4

8027625: test/java/math/BigInteger/ExtremeShiftingTests.java needs @run tag to 
specify heap size
Summary: Add @run tag to specify heap size
Reviewed-by: alanb, dxu

! test/java/math/BigInteger/ExtremeShiftingTests.java

Re: RFR 8027687: The constructors of URLPermission class do not behave as described in javadoc

[Chris Hegarty]

The latest changes look better to me.

Trivially ( and in agreement with Vitaly ), I would, but you don't have 
to, change:


static final int CAP_DIFF = 0x20; // 'a' - 'A';

static String toLowerCase(String s) {
final int len = s.length();
StringBuilder sb = null;

for (int i=0; i= 'a' && c <= 'z') || (c == '.')) {
if (sb != null)
sb.append(c);
} else if ((c >= '0' && c <= '9') || (c == '-')) {
if (sb != null)
sb.append(c);
} else if (c >= 'A' && c <= 'Z') {
if (sb == null) {
sb = new StringBuilder(len);
sb.append(s, 0, i);  // <<< HERE
}
sb.append((char)(c + CAP_DIFF));
} else {
throw new IllegalArgumentException("Invalid characters 
in hostname");

}
}
return sb == null ? s : sb.toString();

-Chris.

On 04/11/2013 13:35, Michael McMahon wrote:

Vitaly,

Good points, I agree. I think the optimisation is worthwhile
and not costly. I also found a small casting issue with
StringBuilder.append(char)
being interpreted as StringBuilder.append(int)

Here is the updated webrev:

http://cr.openjdk.java.net/~michaelm/8027687/webrev.2/

Thanks,
Michael


On 02/11/13 01:03, Vitaly Davidovich wrote:


The size to use is the length of the argument, which you're already
using for the loop.

On a separate note, is toLowerCase in a perf sensitive area? It makes
an assumption that the lowering will need to happen (by always
allocating the stringbuilder) but is that a common case? If this isn't
perf sensitive then disregard.

Thanks

Sent from my phone

On Nov 1, 2013 4:28 PM, "Michael McMahon"
mailto:michael.x.mcma...@oracle.com>>
wrote:

On 01/11/13 18:06, Mike Duigou wrote:

A couple minor quibbles

- Since the length is know the StringBuildiler can be created
with a size.


Right, 255 is probably a good size to use.

- sb.toString() is probably more efficient than new String(sb)


Since Chris also suggests it, I'm curious why this is. Is there
some clever sharing going on between
StringBuilder and String?

- I would like to see some IDN URL cases in the tests.


The first version of this class doesn't support Unicode strings in
the hostname labels.
So, I'm guessing you mean cases of IDNs that have been already
converted
into the ascii encoded form (eg xn--blahblah.xn-blah.com
). Something I'd like to do
for JDK 9 will be to allow transparent Unicode in classes like
URLPermission with
automatic IDN conversions taking place in the http protocol handler.
So, I can add some cases of encoded IDNs in the test okay.

Thanks!

Michael

Mike

On Nov 1 2013, at 07:46 , Michael McMahon
mailto:michael.x.mcma...@oracle.com>> wrote:

Simple bug fix to new URLPermission class, caused by
insufficient parameter checking
of the constructor.

webrev:
http://cr.openjdk.java.net/~michaelm/8027687/webrev.1/


Thanks,
Michael

hg: jdk8/tl/jdk: 8027687: The constructors of URLPermission class do not behave as described in javad

[michael . x . mcmahon]

Changeset: 48449b5390fa
Author:michaelm
Date:  2013-11-04 17:47 +
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/48449b5390fa

8027687: The constructors of URLPermission class do not behave as described in 
javad
Reviewed-by: chegar, mduigou

! src/share/classes/java/net/HostPortrange.java
! src/share/classes/java/net/URLPermission.java
! test/java/net/URLPermission/URLPermissionTest.java

Re: hg: jdk8/tl/jdk: 8027687: The constructors of URLPermission class do not behave as described in javad

[mark . reinhold]

2013/11/4 1:49 -0800, michael.x.mcma...@oracle.com:
> Changeset: 48449b5390fa
> Author:michaelm
> Date:  2013-11-04 17:47 +
> URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/48449b5390fa
> 
> 8027687: The constructors of URLPermission class do not behave as described 
> in javad
> Reviewed-by: chegar, mduigou

What is "javad"?

- Mark

Re: RFR for JDK-8022963 /java/net/NetworkInterface/Equals.java fails with java.lang.RuntimeException: equality different for net8

[Chris Hegarty]

On 01/11/2013 14:43, Tristan Yan wrote:

Hi everyone
Please review the fix for JDK-8022963.

http://cr.openjdk.java.net/~pzhang/Tristan/8022963/webrev/


This is not pretty, but I don't have a better alternative.

Any objections? Otherwise, I can help sponsor this.

-Chris.


Description:
Since windows API has very inconsistent behavior on Teredo Tunneling
Pesudo-Interface, we removed this network interface for this test.

Thank you.
Tristan

On 01/11/2013 22:43, Chris Hegarty wrote:

Hi Tristan,

From what I understand of the issue I see no problem with what you are
suggesting. Webrev?

-Chris.

On 01/11/2013 05:44, Tristan Yan wrote:

Hi Everyone

I am working on bug https://bugs.openjdk.java.net/browse/JDK-8022963.
Root cause for this bug is Windows API has inconsistent behavior for
Teredo Tunneling Interface, based on the discussion with Chris Hegarty,
we decided to fix this test with removing "Windows && Teredo Tunneling
Pseudo-Interface" from this test.

Please let me know if you have any comments or suggestions.

Thank you

Tristan

/Tristan Yan(Haibo Yan)/

/Office : 8610-61066212/

/Fax : 8610-61065441/

/Cell : 86-18610696822/

//

/2F, Building No. 24, Zhongguancun Software Park/

/Haidian District Beijing


, 100193/

oracle

Re: hg: jdk8/tl/jdk: 8027687: The constructors of URLPermission class do not behave as described in javad

[Michael McMahon]

On 04/11/13 18:05, mark.reinh...@oracle.com wrote:

2013/11/4 1:49 -0800, michael.x.mcma...@oracle.com:

Changeset: 48449b5390fa
Author:michaelm
Date:  2013-11-04 17:47 +
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/48449b5390fa

8027687: The constructors of URLPermission class do not behave as described in 
javad
Reviewed-by: chegar, mduigou

What is "javad"?

- Mark


Mark,

Sorry. That was an incomplete copy/paste. It should say "as described in 
javadoc"


Michael.

hg: jdk8/tl/jdk: 8027612: java/io/File/MaxPathLength.java fails intermittently in the clean-up stage

[dan . xu]

Changeset: 6d1f3ba68db2
Author:dxu
Date:  2013-11-04 15:48 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6d1f3ba68db2

8027612: java/io/File/MaxPathLength.java fails intermittently in the clean-up 
stage
Reviewed-by: chegar

! test/java/io/File/MaxPathLength.java