On 05/07/2013 12:53 PM, Brian Burkhalter wrote:
> To recapitulate in one place, I think we agree on the following sequence:
>
> Phase 1: Faster multiplication and exponentiation of large integers
> * Karatsuba and Toom-Cook multiplication and squaring; revised pow() function.
> * http://bugs.sun.c
On 05/09/2013 07:53 AM, David Holmes wrote:
Hi Thomas,
On 9/05/2013 1:28 AM, Thomas Schatzl wrote:
Hi,
please review the latest webrev for this patch that is available at
http://cr.openjdk.java.net/~tschatzl/7038914/webrev.2/
As mentioned, it incorporates the fix and reproducer from Peter
On 05/09/2013 10:35 AM, Peter Levart wrote:
In my experience, the thread dies between 10-20ms after interrupting,
so waiting for about 500ms is enough I think.
But only if the test is started with low max. heap setting. When trying
with large heaps (2G+), a long GC pause can ruin Thread.sleep(
Thanks for taking care of this Sherman. I was wondering what sort of
impact JSR 310 would make on tzdata updates. The Atlantic/Stanley
display name issue mentioned is a regular one, we should log a bug
against the test file generation scripts.
I just had a quick grok of the jdk8 repo. The foll
On 05/09/2013 07:53 AM, David Holmes wrote:
Have you instrumented the code to verify that the test actually
triggers an OOME?
Without the patch, the test always throws OOME in lock.wait() and kills
the thread. At least in all executions I tried (100s) it did the same.
The test might pass with
On 05/08/13 17:26, Chris Hegarty wrote:
On 8 May 2013, at 21:56, Mike Duigou wrote:
On May 7 2013, at 10:13 , Chris Hegarty wrote:
On 05/07/2013 05:04 PM, Mike Duigou wrote:
The "currently" MIN_ARRAY_SORT_GRAN statement bothers me. Can we remove
currently?
No problem. That would read.
Hi Aleksey
Well the code change is easy enough to review :)
As to the effects ... no way to judge that: time and testing will tell.
David
On 9/05/2013 3:29 AM, Aleksey Shipilev wrote:
Hi,
This is from our backlog after JDK-8005926. After ThreadLocalRandom
state was merged into Thread, we now
Out of curiosity (my major was math back in university), I take a look
at BigInteger.java.phase1:
First you have:
/**
* The threshold value for using 3-way Toom-Cook multiplication.
* If the number of ints in both mag arrays are greater than this
number,
* then Toom-Cook mu
On 9/05/2013 7:26 AM, Chris Hegarty wrote:
On 8 May 2013, at 21:56, Mike Duigou wrote:
On May 7 2013, at 10:13 , Chris Hegarty wrote:
On 05/07/2013 05:04 PM, Mike Duigou wrote:
The "currently" MIN_ARRAY_SORT_GRAN statement bothers me. Can we remove
currently?
No problem. That would read.
On 05/09/2013 10:45 AM, David Holmes wrote:
Good point Mike. I guess the same argument could be made for putting
any value in the implementation detail. Any objection to completely
removing any reference to this?
The compile-time constant issue is easily fixed by using an
initialization f
On 05/09/2013 01:39 PM, David Holmes wrote:
> Well the code change is easy enough to review :)
Ha! Bike-shed opportunity: to use fully quailified class name in the
annotation, or not. (I'm following the suit for j.u.c.ForkJoinPool and
friends).
> As to the effects ... no way to judge that: time a
On 09/05/2013 01:13, Mandy Chung wrote:
Please review the simple change for:
JDK-4487672 (proxy) Proxy constructor should check for null argument
Webrev at:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/4487672/webrev.00/
It looks okay to me although technically an incompatible change. I gue
Hi Peter,
Thanks for clarifying the test details. A few follow ups:
- The reference class does get initialized early in the VM startup well
before Main will be loaded. But the use of the weakref doesn't hurt.
- 500ms may not be enough on some platforms, particularly some embedded
systems. Id
On 9/05/2013 7:18 PM, Peter Levart wrote:
On 05/09/2013 07:53 AM, David Holmes wrote:
Have you instrumented the code to verify that the test actually
triggers an OOME?
Without the patch, the test always throws OOME in lock.wait() and kills
the thread. At least in all executions I tried (100s)
On 09/05/2013 06:27, Henry Jen wrote:
On 05/08/2013 09:17 PM, Mike Duigou wrote:
Looks good to me.
Thanks, we have a minor update to exclude changes for DirectoryStream.
http://cr.openjdk.java.net/~henryjen/ccc/8006884.2/webrev/
A quick review on the update is really appreciated.
Looks goo
On 9/05/2013 7:47 PM, Chris Hegarty wrote:
On 05/09/2013 10:45 AM, David Holmes wrote:
Good point Mike. I guess the same argument could be made for putting
any value in the implementation detail. Any objection to completely
removing any reference to this?
The compile-time constant issue
On 9/05/2013 7:53 PM, Aleksey Shipilev wrote:
On 05/09/2013 01:39 PM, David Holmes wrote:
Well the code change is easy enough to review :)
Ha! Bike-shed opportunity: to use fully quailified class name in the
annotation, or not. (I'm following the suit for j.u.c.ForkJoinPool and
friends).
As
On 05/09/2013 02:15 PM, David Holmes wrote:
> On 9/05/2013 7:53 PM, Aleksey Shipilev wrote:
>> On 05/09/2013 01:39 PM, David Holmes wrote:
>>> Well the code change is easy enough to review :)
>>
>> Ha! Bike-shed opportunity: to use fully quailified class name in the
>> annotation, or not. (I'm foll
On 05/09/13 05:39, David Holmes wrote:
Hi Aleksey
Well the code change is easy enough to review :)
As to the effects ... no way to judge that: time and testing will tell.
For some initial sanity-check testing, I just built lambda with
the added @Contended annotation on Thread and ran a few
o
On 05/09/2013 12:08 PM, David Holmes wrote:
On 9/05/2013 7:18 PM, Peter Levart wrote:
On 05/09/2013 07:53 AM, David Holmes wrote:
Have you instrumented the code to verify that the test actually
triggers an OOME?
Without the patch, the test always throws OOME in lock.wait() and kills
the threa
Hi David,
On 05/09/2013 12:02 PM, David Holmes wrote:
Hi Peter,
Thanks for clarifying the test details. A few follow ups:
- The reference class does get initialized early in the VM startup
well before Main will be loaded. But the use of the weakref doesn't hurt.
Ok, so if this is guaranteed
On 9/05/2013 8:40 PM, Peter Levart wrote:
On 05/09/2013 12:08 PM, David Holmes wrote:
On 9/05/2013 7:18 PM, Peter Levart wrote:
On 05/09/2013 07:53 AM, David Holmes wrote:
Have you instrumented the code to verify that the test actually
triggers an OOME?
Without the patch, the test always thr
On 9/05/2013 9:16 PM, Peter Levart wrote:
Hi David,
On 05/09/2013 12:02 PM, David Holmes wrote:
Hi Peter,
Thanks for clarifying the test details. A few follow ups:
- The reference class does get initialized early in the VM startup
well before Main will be loaded. But the use of the weakref do
I don't understand why this is important. Is the general advise not,
always use parallelSort unless there is a good reason not to?
That certainly would NOT be my general advise. My general advise is only use
parallelism to solve a performance problem. Overuse of FJ for non critical tasks
will
On 05/09/2013 01:33 PM, David Holmes wrote:
On 9/05/2013 9:16 PM, Peter Levart wrote:
Hi David,
On 05/09/2013 12:02 PM, David Holmes wrote:
Hi Peter,
Thanks for clarifying the test details. A few follow ups:
- The reference class does get initialized early in the VM startup
well before Main
On 08/05/2013 23:05, Martin Buchholz wrote:
Alan (et al): Ping.
I've looked through the webrev.
The scary part is subsequenceRaw where the offsets including the
position. I don't see anything obviously wrong and the tests should
catch any issues. I don't see any issue conditionally generatin
Hi Aleksey,
Wouldn't it be even better if just threadLocalRandom* fields were
annotated with @Contended("ThreadLocal") ?
Some fields within the Thread object are accessed from non-local
threads. I don't know how frequently, but isolating just
threadLocalRandom* fields from all possible false-s
On May 9 2013, at 05:38 , Alan Bateman wrote:
> On 08/05/2013 23:05, Martin Buchholz wrote:
>> Alan (et al): Ping.
>>
> I've looked through the webrev.
>
> The scary part is subsequenceRaw where the offsets including the position. I
> don't see anything obviously wrong and the tests should cat
Hi all,
A stupid question:
any ThreadLocal subclass should be marked @Contended to be sure that false
sharing never happens between ThreadLocal instance and any other object on
the heap ?
Laurent
2013/5/9 Peter Levart
> Hi Aleksey,
>
> Wouldn't it be even better if just threadLocalRandom* fiel
On 5/9/13 3:00 AM, Alan Bateman wrote:
On 09/05/2013 01:13, Mandy Chung wrote:
Please review the simple change for:
JDK-4487672 (proxy) Proxy constructor should check for null argument
Webrev at:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/4487672/webrev.00/
It looks okay to me although t
On May 9, 2013, at 12:11 AM, Alan Eliasen wrote:
>> Phase 1: Faster multiplication and exponentiation of large integers
>> Phase 2: Faster string conversion of large integers
>> Phase 3: Faster division of large integers
>> Phase 4: Faster multiplication and division of very large integers
>
>
On 05/09/2013 04:59 PM, Laurent Bourgès wrote:
Hi all,
A stupid question:
any ThreadLocal subclass should be marked @Contended to be sure that
false sharing never happens between ThreadLocal instance and any other
object on the heap ?
Hi Laurent,
ThreadLocal object is just a key (into a
On May 9 2013, at 10:38 , Mandy Chung wrote:
> On 5/9/13 3:00 AM, Alan Bateman wrote:
>> On 09/05/2013 01:13, Mandy Chung wrote:
>>> Please review the simple change for:
>>> JDK-4487672 (proxy) Proxy constructor should check for null argument
>>>
>>> Webrev at:
>>> http://cr.openjdk.java.net/~m
On 5/9/13 11:16 AM, Mike Duigou wrote:
As we found with 5045147 (TreeMap with null first entry), which is similar in
terms of how the null treatment changed, there almost certainly will be
people's code who barfs when generating the proxy now throws the NPE.
Thanks for the reference.
The pro
Changeset: bb9cdfac1a7d
Author:juh
Date: 2013-05-09 12:00 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bb9cdfac1a7d
8007699: Move some tests from test/sun/security/provider/certpath/X509CertPath
to closed repo
Reviewed-by: mullan
- test/sun/security/provider/certpath/X509
Hi Max,
On May 9, 2013, at 2:45 AM, Weijun Wang wrote:
> Out of curiosity (my major was math back in university), I take a look at
> BigInteger.java.phase1:
All useful comments are welcome, for whatever reason!
> First you have:
>
>/**
> * The threshold value for using 3-way Toom-Cook
Changeset: 498ea4c3a4c6
Author:psandoz
Date: 2013-05-01 18:40 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/498ea4c3a4c6
8012646: Pattern.splitAsStream
Reviewed-by: forax, plevart, alanb
Contributed-by: Ben Evans , Paul Sandoz
! src/share/classes/java/util/regex/Pattern.j
On 05/09/2013 03:11 AM, Alan Bateman wrote:
> On 09/05/2013 06:27, Henry Jen wrote:
>> On 05/08/2013 09:17 PM, Mike Duigou wrote:
>>> Looks good to me.
>>>
>> Thanks, we have a minor update to exclude changes for DirectoryStream.
>>
>> http://cr.openjdk.java.net/~henryjen/ccc/8006884.2/webrev/
>>
>
Changeset: 1f13a798d1b8
Author:katleman
Date: 2013-05-02 13:34 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/1f13a798d1b8
Added tag jdk8-b88 for changeset 4e3a881ebb1e
! .hgtags
Changeset: fe4150590ee5
Author:lana
Date: 2013-05-06 11:41 -0700
URL: http://h
Changeset: 88838e08e4ef
Author:katleman
Date: 2013-05-02 13:35 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/88838e08e4ef
Added tag jdk8-b88 for changeset 24fa5452e5d4
! .hgtags
Changeset: adec2a5d510a
Author:katleman
Date: 2013-05-02 13:35 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/adec2a5d510a
Added tag jdk8-b88 for changeset a1e10f3adc47
! .hgtags
Changeset: ec434cfd2752
Author:lana
Date: 2013-05-06 11:53 -0700
URL: http
Changeset: 1dfcc874461e
Author:omajid
Date: 2013-04-29 12:34 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/rev/1dfcc874461e
8013480: fix zero build on arm
Reviewed-by: erikj
! common/autoconf/generated-configure.sh
! common/autoconf/platform.m4
! common/autoconf/spec.gmk.in
Change
Hi Sean,
Thanks for the review. It appears I missed jdk/test/sun/util/calendar/zi/tzdata,
webrev has been updated to include the test data update.
http://cr.openjdk.java.net/~sherman/8013386/webrev
I will update TCKZoneRulesProvider.java separately in JSR310 repo, this def is
actually is not be
Changeset: 501bc4aeb1b1
Author:katleman
Date: 2013-05-02 13:35 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/501bc4aeb1b1
Added tag jdk8-b88 for changeset 40c107d1ae6f
! .hgtags
Changeset: 45ce27fbe272
Author:lana
Date: 2013-05-06 11:53 -0700
URL: http:/
Changeset: 21f75e572cb3
Author:katleman
Date: 2013-05-02 13:35 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/21f75e572cb3
Added tag jdk8-b88 for changeset 7122f7bb0fcc
! .hgtags
Changeset: 893d2ba8bbea
Author:lana
Date: 2013-05-06 11:41 -0700
URL: http://hg
Changeset: d0081bfc425c
Author:katleman
Date: 2013-05-02 13:35 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d0081bfc425c
Added tag jdk8-b88 for changeset 8482058e74bc
! .hgtags
Changeset: 57ac6a688ae6
Author:amurillo
Date: 2013-04-26 00:40 -0700
URL: ht
Changeset: 78d08fc2dd12
Author:mullan
Date: 2013-04-25 11:18 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/78d08fc2dd12
8011313: OCSP timeout set to wrong value if com.sun.security.ocsp.timeout not
defined
Reviewed-by: vinnie
! src/share/classes/sun/security/provider/certp
Hello all;
This is a small review to clean up a non-longer-need workaround.
http://cr.openjdk.java.net/~mduigou/JDK-8014316/0/webrev/
Thanks
On May 9, 2013, at 10:44 AM, Brian Burkhalter wrote:
>> Tim and Brian, you might decide amongst yourselves who wants to file
>> the issues for phases 3 and 4. I don't know if Brian has any magical
>> powers to make the issues skip the QA process.
>
> Indeed if I file them it will streamline th
On 9/05/2013 10:13 PM, Peter Levart wrote:
On 05/09/2013 01:33 PM, David Holmes wrote:
On 9/05/2013 9:16 PM, Peter Levart wrote:
Hi David,
On 05/09/2013 12:02 PM, David Holmes wrote:
Hi Peter,
Thanks for clarifying the test details. A few follow ups:
- The reference class does get initializ
Looks good to me Mike!
David
On 10/05/2013 9:50 AM, Mike Duigou wrote:
Hello all;
This is a small review to clean up a non-longer-need workaround.
http://cr.openjdk.java.net/~mduigou/JDK-8014316/0/webrev/
Thanks
string ref -> strong ref
David
On 10/05/2013 1:20 PM, David Holmes wrote:
On 9/05/2013 10:13 PM, Peter Levart wrote:
On 05/09/2013 01:33 PM, David Holmes wrote:
On 9/05/2013 9:16 PM, Peter Levart wrote:
Hi David,
On 05/09/2013 12:02 PM, David Holmes wrote:
Hi Peter,
Thanks for clarifyin
Do we still need to keep the old javazic code in JDK8? It's a
maintenance burden to maintain both, isn't it?
I'm concerned about the 24:00 fix. Is there any way to produce the
correct rules without hard coding time zone IDs?
Masayoshi
On 5/10/2013 8:24 AM, Xueming Shen wrote:
Hi Sean,
Than
Short version:
Cache the value returned by toString and use it to copy-construct a new
String on subsequent calls to toString(). Clear the cache on any
mutating operation.
webrev: http://cr.openjdk.java.net/~dholmes/8013395/webrev.v2/
Testing: microbenchmark for toString performance; new reg
Hi David,
Would it be beneficial to push the toStringCache up to
AbstractStringBuilder so that StringBuilder.toString() benefits from this
cache as well? It seems like this would affect both StringBuilder and
StringBuffer for repeated calls to toString(), although StringBuffer would
obviously have
On 5/9/13 9:57 PM, Masayoshi Okutsu wrote:
Do we still need to keep the old javazic code in JDK8? It's a
maintenance burden to maintain both, isn't it?
While it's a burden, but somehow it serves as a test case pretty well.
The transitions are
being built the "old" jdk way and threeten way, i
Peter,
you're absolutely right: I was thinking about thread local values (object
instances) and not ThreadLocal keys !
I think ThreadLocal name is confusing as it does not correspond to values !
Several times I wonder if false sharing can happen between my thread local
values (i.e. different Thre
One other quick comment, if the toStringCache is non-null during invocation
of toString(), that seems to imply that the StringBuffer/StringBuilder has
not been mutated since the last invocation of toString(), is there any
reason to still use the String copy constructor? This would address the
http:
Hi David,
On 10/05/2013 4:39 PM, David Schlosnagle wrote:
One other quick comment, if the toStringCache is non-null during
invocation of toString(), that seems to imply that the
StringBuffer/StringBuilder has not been mutated since the last
invocation of toString(), is there any reason to still
Hi Dave,
On 10/05/2013 4:25 PM, David Schlosnagle wrote:
Hi David,
Would it be beneficial to push the toStringCache up to
AbstractStringBuilder so that StringBuilder.toString() benefits from
this cache as well? It seems like this would affect both StringBuilder
and StringBuffer for repeated cal
60 matches
Mail list logo
