On 11/06/2013 1:54 AM, Chris Hegarty wrote:
I'm not sure I ever saw this test fail, but it does look like it has
issues.
I would much prefer to see a j.u.c.Latch/Phaser used to synchronize
across these threads.
I don't think that is possible. The main thread wants to reset the count
after the
On 06/11/2013 01:01 AM, Steven Schlansker wrote:
Sorry to double-reply, but I thought it worthwhile to note that the time to
intern strings via ConcurrentHashMap is measured in the low double-digit
nanoseconds on my machine, so this may indeed end up being nontrivial. But I
will consider it t
On Jun 10, 2013, at 7:20 PM, Aleksey Shipilev
wrote:
> Thanks for taking a look, Paul!
> Can I count your review as official?
Unfortunately i am not an unofficial reviewer so can only be counted in the
unofficial category for now :-(
>
> On 06/10/2013 08:44 PM, Paul Sandoz wrote:
>>> - reu
Changeset: bab844827181
Author:sundar
Date: 2013-06-06 21:41 +0530
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/bab844827181
8015346: JSON parsing issues with escaped strings, octal, decimal numbers
Reviewed-by: hannesw, jlaskey
! src/jdk/nashorn/internal/ir/BlockLexicalCont
On 06/10/2013 08:06 PM, Steven Schlansker wrote:
Hi core-libs-dev,
Hi Steven,
the main issue is that intern() doesn't work in isolation,
by example if you write
"foo" == new String("foo").intern()
the result should be always true so the String cache must be accessible
not only from the Java
On 06/11/2013 02:52 AM, Christian Thalinger wrote:
> This looks good to me.
Thanks for the review!
> Could you run RegExp with Nashorn again with and without your changes?
Being single-threaded, the benchmark will not show much of the
improvement. Also, the results are rather flaky.
Before:
On 06/11/2013 12:31 PM, Remi Forax wrote:
> On 06/10/2013 08:06 PM, Steven Schlansker wrote:
> Hi Steven,
> the main issue is that intern() doesn't work in isolation,
>
> I think it's better to change the JSON Parser implementation to use it's
> own cache (or not) and not rely on String.intern().
On 06/11/2013 01:31 AM, Peter Levart wrote:
> While you're at it adding getInterfaces() cache, why not also
> getSuperclass()? Is it maybe already intrinsified?
Yes, the C2 code and benchmarking shows it is already an intrinsic.
-Aleksey.
Changeset: bbedff0dc37e
Author:vromero
Date: 2013-06-11 09:35 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bbedff0dc37e
8008547: javac, warning message: use of ''_'' as an identifier might not be
supported in future releases, should be more especific
Reviewed-by: jjg
Changeset: 7fe655cad9b1
Author:vromero
Date: 2013-06-11 09:59 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7fe655cad9b1
8007907: javap, method com.sun.tools.javap.Main.run returns 0 even in case of
class not found error
Reviewed-by: jjg
! src/share/classes/com/sun/t
On 10/06/2013 19:06, Steven Schlansker wrote:
Hi core-libs-dev,
While doing performance profiling of my application, I discovered that nearly
50% of the time deserializing JSON was spent within String.intern(). I
understand that in general interning Strings is not the best approach for
thing
On 06/11/2013 08:08 AM, David Holmes wrote:
On 11/06/2013 1:54 AM, Chris Hegarty wrote:
I'm not sure I ever saw this test fail, but it does look like it has
issues.
I would much prefer to see a j.u.c.Latch/Phaser used to synchronize
across these threads.
I don't think that is possible. The ma
Hi Peter,
On 06/11/2013 12:57 AM, Peter Levart wrote:
> When 'sun.reflect.noCaches=true' system property is defined,
> reflectionData() returns null. In that case, the code should cope
> without using ReflectionData (no caching). See other uses of
> reflectionData() (for example: in privateGetD
Hi
Please review the following patch:
http://cr.openjdk.java.net/~psandoz/tl/JDK-8016308-Node/webrev/
This syncs up java.util.stream.Node/Nodes from the lambda repo to the tl repo.
The main changes are related to reducing the code for primitive
specializations. There are some temporary funct
Changeset: 8d627f324c38
Author:psandoz
Date: 2013-06-11 12:13 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8d627f324c38
8015895: Int/LongStream.range/rangeClosed
8012986: Right-bias range spliterators for large ranges
Reviewed-by: mduigou
! src/share/classes/java/util/stre
Aleksey,
On 06/11/2013 11:56 AM, Aleksey Shipilev wrote:
Hi Peter,
On 06/11/2013 12:57 AM, Peter Levart wrote:
When 'sun.reflect.noCaches=true' system property is defined,
reflectionData() returns null. In that case, the code should cope
without using ReflectionData (no caching). See other use
On 06/11/2013 03:27 PM, Peter Levart wrote:
>> The new webrev is here:
>> http://cr.openjdk.java.net/~shade/8016236/webrev.02/
>
> That's good now.
Thanks!
> I just wonder if renaming of native getGenericSignature ->
> getGenericSignature0 is still needed now that there's no
> getGenericSignat
The changes to classes in the security component look fine. One question
I have is about the change to javax/xml/crypto/dsig/Manifest.java. Was
there a specific error here or did you just want to make this cleaner by
removing all of the html special character handling? The reason I ask is
that
On 11/06/2013 13:08, Sean Mullan wrote:
The changes to classes in the security component look fine. One
question I have is about the change to
javax/xml/crypto/dsig/Manifest.java. Was there a specific error here
or did you just want to make this cleaner by removing all of the html
special char
Changeset: 669be1677ab7
Author:alanb
Date: 2013-06-11 11:22 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/669be1677ab7
7059085: Retire Thread.stop(Throwable) so that it throws UOE
Reviewed-by: dholmes, chegar, forax, darcy, mduigou
! src/share/classes/java/lang/Thread.java
Hi,
Please review the following patch contributed by Brian Goetz:
http://cr.openjdk.java.net/~psandoz/tl/JDK-8016324-pipelines/webrev/
This syncs most of code in the pipeline implementations from lambda to tl (the
remaining aspects are to do with Comparator changes which will follow later).
On 25/05/2013 12:35, Alan Bateman wrote:
On 24/05/2013 19:14, Martin Buchholz wrote:
:
Alan, you're telling everyone there's no need for Thread.stop, but
you are replacing usages in tests with calls to Unsafe, which is not
available to normal code. So you have a kind of moral obligation
her
Chris and David, thanks for review.
I've updated the test so the threads use CountDownLatch to wait for each
other.
Now, instead of checking whether the 'second' thread has incremented a
count, the 'main' thread waits for it to call countDown().
If a timeout was elapsed before the call, I assum
On Jun 11, 2013, at 1:47 AM, Aleksey Shipilev
wrote:
> On 06/11/2013 02:52 AM, Christian Thalinger wrote:
>> This looks good to me.
>
> Thanks for the review!
>
>> Could you run RegExp with Nashorn again with and without your changes?
>
> Being single-threaded, the benchmark will not show
On 2013-06-10, at 11:53 AM, Aleksey Shipilev
wrote:
>> o.b.ClassBench.generic_getGenericSuperclass avgt 1 51
>> 5.3000.008 nsec/op
Am I reading this correctly? 0.008 nsec/op means 125 times 10-to-the-9th ops
per second.
That's a high clock rate.
Have most bee
On 06/11/2013 07:43 PM, Christian Thalinger wrote:
> Thanks for this but I was thinking running it with -Xprof to see
> whether some of the table methods show up on the profile.
I put little trust into this kind of profiling, but here's the sample
output from JMH -prof stack, while running with 4
On Jun 11, 2013, at 9:03 AM, Aleksey Shipilev
wrote:
> On 06/11/2013 07:43 PM, Christian Thalinger wrote:
>> Thanks for this but I was thinking running it with -Xprof to see
>> whether some of the table methods show up on the profile.
>
> I put little trust into this kind of profiling, but her
On 06/11/2013 07:58 PM, David Chase wrote:
>
> On 2013-06-10, at 11:53 AM, Aleksey Shipilev
> wrote:
>
>>> o.b.ClassBench.generic_getGenericSuperclass avgt 1 51
>>> 5.3000.008 nsec/op
>
> Am I reading this correctly? 0.008 nsec/op means 125 times 10-to-the-9th
On 06/11/2013 08:06 PM, Christian Thalinger wrote:
> Anyway, let's push this.
Do you want me any other testing done? vm.mlvm.testlist is OK, but I
haven't done the full JPRT test cycle, only the build one.
-Aleksey.
On 6/11/2013 5:33 AM, Alan Bateman wrote:
On 11/06/2013 13:08, Sean Mullan wrote:
The changes to classes in the security component look fine. One
question I have is about the change to
javax/xml/crypto/dsig/Manifest.java. Was there a specific error here
or did you just want to make this cleane
Hi guys,
This mail was originality sent to lambda-lib EG but Brian ask me to also
send it here to not forget.
We should provide an implementation of forEach for HashMap that avoid to
create an Iterator,
HashMap is too common to not have it's dedicated implementation
(ArrayList by example has
Changeset: cadb0ef6e931
Author:naoto
Date: 2013-06-11 11:18 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cadb0ef6e931
8015960: java/util/Locale/LocaleProviders.java failing again on Windows
Reviewed-by: alanb
! test/java/util/Locale/LocaleProviders.java
On Jun 11, 2013, at 9:08 AM, Aleksey Shipilev
wrote:
> On 06/11/2013 08:06 PM, Christian Thalinger wrote:
>> Anyway, let's push this.
>
> Do you want me any other testing done? vm.mlvm.testlist is OK, but I
> haven't done the full JPRT test cycle, only the build one.
You could do a full Nasho
Hi,
Please review my fix for 8010325. Some background:
The alternative string-hashing implementation[1] added to
java.lang.String a new public method, hash32(), as well as a new private
int field to cache the alternate hash value.
Following 8005698 [2] and 8005704 [3], the new method and fi
Hi,
Please review http://cr.openjdk.java.net/~henryjen/ccc/8009736.2/webrev/
Highlight of changes,
- Comparators class is now only package-private implementations. The
public static methods have been move to other arguably more appropriate
places, mostly in Comparator.
- Comparator.reverseOrder
On Jun 11 2013, at 09:59 , Remi Forax wrote:
> Hi guys,
> This mail was originality sent to lambda-lib EG but Brian ask me to also send
> it here to not forget.
>
> We should provide an implementation of forEach for HashMap that avoid to
> create an Iterator,
> HashMap is too common to not hav
On 06/11/2013 10:24 PM, Christian Thalinger wrote:
>
> On Jun 11, 2013, at 9:08 AM, Aleksey Shipilev
> wrote:
>
>> On 06/11/2013 08:06 PM, Christian Thalinger wrote:
>>> Anyway, let's push this.
>>
>> Do you want me any other testing done? vm.mlvm.testlist is OK, but I
>> haven't done the full
We previously identified four phases of BigInteger performance improvement
based on contributions from Alan Eliasen and Tim Buktu:
1) Multiplication and exponentiation -
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4837946 and
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4646474
2)
This contributed patch
http://cr.openjdk.java.net/~bpb/4396272%2b7192954/
fixes these two issues:
1) http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7192954 - Fix
Float.parseFloat to round correctly and preserve monotonicity
2) http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4396272 - Pa
Yes. I was just looking at it again today. I was planning to post its RFR after
the one I just posted for 7192954+4396272 has been cleared. The changes for
7131192 are disjoint with the other BigInteger performance improvements in the
queue so this should be able to be patched in easily.
Brian
Changeset: 7f697d028937
Author:mduigou
Date: 2013-06-11 15:39 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7f697d028937
8016213: Convert j2se NetBeans project to use top-level make targets
Reviewed-by: chegar
! make/netbeans/common/shared.xml
! make/netbeans/j2se/build.xml
On Jun 11, 2013, at 2:21 PM, Aleksey Shipilev
wrote:
> On 06/11/2013 10:24 PM, Christian Thalinger wrote:
>>
>> On Jun 11, 2013, at 9:08 AM, Aleksey Shipilev
>> wrote:
>>
>>> On 06/11/2013 08:06 PM, Christian Thalinger wrote:
Anyway, let's push this.
>>>
>>> Do you want me any other t
42 matches
Mail list logo
