Am 11.09.2009 01:56, Martin Buchholz schrieb:
On Thu, Sep 10, 2009 at 16:48, Joe Darcy wrote:
I approve this change going back with the correction to the Character
class.
Oops! so many little mistakes. Webrev regenerated.
Is that webrev public anywhere ?
(Hopefully you consider my
Ulf Zibis said the following on 09/11/09 17:00:
Am 11.09.2009 01:56, Martin Buchholz schrieb:
On Thu, Sep 10, 2009 at 16:48, Joe Darcy wrote:
I approve this change going back with the correction to the Character
class.
Oops! so many little mistakes. Webrev regenerated.
Is that webrev
Xueming Shen wrote:
I think we have enough discussion on this topic, it's time to make a
final decision. Seems like we are all happy on the
changes in Deflater and new DOS.flush(mode), the only difference is
whether or not we should change the existing
behavior of DOS.flush() should use Z_SYNC_
Hello All,
I'd like to share with you new Dual-Pivot Quicksort which is
faster than the known implementations (theoretically and
experimental). I'd like to propose to replace the JDK's
Quicksort implementation by new one.
Description
---
The classical Quicksort algorithm uses the followi
just my two cents :
In the loop tagged "sorting" and "equals element",
a[k] can be stored in a local variable to avoid to recompute it several
time.
The algorithm use two constants: 37 and 13,
I think they should be declared as private static final.
Rémi
Le 11/09/2009 12:35, Vladimir Yarosla
Very interesting stuff.
Does one have tried (theoretically and/or experimental) P1+P2+P3,
P1+P2+P3+P2, ... segmentation ?
Maybe coefficient A has a minimum below 0.8.
-Ulf
Am 11.09.2009 12:35, Vladimir Yaroslavskiy schrieb:
Hello All,
I'd like to share with you new Dual-Pivot Quicksort whi
Hi Ulf,
Sure, I have tried it, see:
Original Message
Subject: Re: Dual-Pivot Quicksort Analysis
Date: Wed, 09 Sep 2009 18:45:46 +0400
From: Vladimir Yaroslavskiy
Organization: Sun Microsystems, Inc.
To: Jon Bentley
CC: Joshua Bloch
Hello,
I've converted the pseudocode into
sure, will do it
Rémi Forax wrote:
just my two cents :
In the loop tagged "sorting" and "equals element",
a[k] can be stored in a local variable to avoid to recompute it several
time.
The algorithm use two constants: 37 and 13,
I think they should be declared as private static final.
Rémi
L
Am 11.09.2009 15:32, Rémi Forax schrieb:
just my two cents :
In the loop tagged "sorting" and "equals element",
a[k] can be stored in a local variable to avoid to recompute it
several time.
I add 2 cents more:
Doesn't HotSpot see this, and optimize accordingly?
IMO: It's time that javac should
Hi,
I've tried to use local variable int ak = a[k] in the loop
and not found saving of time. There are 3 occurrences of a[k]
in each loop, but only two can be changed because third
comes after line: swap(a, k, great--);
As summary: I'm changing only hardcoded constant by
private static final var
Hello.
For JDK 7, I think it is high-time the platform included a class like
java.util.Objects to hold commonly-written utility methods. For
example, a two-argument static equals method that returned true if
both
arguments are null, returns false is one argument is null, and
otherwise
retur
Alan, David, Remi, Iris,
Thanks for the review and the revised webrev at:
http://cr.openjdk.java.net/~mchung/6878481/webrev.01/
I incorporate the comments you have and minimize the number of
System.nanoTime() calls and also remove the number of opened jars perf
counters. Please let me kno
Nice.
> int third = len / div;
>
> // "medians"
> int m1 = left + third;
> int m2 = right - third;
>
> if (m1 <= left) {
> m1 = left + 1;
> }
> if (m2 >= right) {
> m2 = right - 1;
> }
I'd suggest this inst
As an observation, why not expand the new algorithm to N-Pivot
where N = round(ln(array length)).
This should lower the average sort cost even lower.
Joe Darcy wrote:
Martin Buchholz wrote:
On Thu, Sep 10, 2009 at 16:48, Joe Darcy wrote:
Martin Buchholz wrote:
On Thu, Sep 10, 2009 at 15:48, Joe Darcy wrote:
On 09/09/09 08:01 PM, Joe Darcy wrote:
I noticed that the Character class should be similarly tightened:
Right you are. Webrev reg
Joe Darcy wrote:
Martin Buchholz wrote:
On Wed, Sep 9, 2009 at 17:34, Joe Darcy wrote:
Martin Buchholz wrote:
Google would like to contribute implementations of the methods below.
Here's a webrev:
http://cr.openjdk.java.net/~martin/webrevs/openjdk7/compare/
Wherever these compa
Martin,
Would you please help review the change?
http://cr.openjdk.java.net/~sherman/6881337/webrev
Somehow the development team messed up our change in ZipEntry.java in
b64 in their putback. This fix is to restore the api/impl.
The bug report probably has not been pushed out yet. Here is the
Approved.
(It would be nice for all changes to
openjdk7 core libraries to leave a trace on core-libs-dev,
so that they can get review here.)
Martin
On Fri, Sep 11, 2009 at 14:05, Xueming Shen wrote:
> Martin,
>
> Would you please help review the change?
>
> http://cr.openjdk.java.net/~sherman/68
Vladimir Yaroslavskiy writes:
> I'd like to share with you new Dual-Pivot Quicksort which is
> faster than the known implementations (theoretically and
> experimental). I'd like to propose to replace the JDK's
> Quicksort implementation by new one.
This is a great idea; as a mathematician I immed
Vadim-
It would be very interesting if something along these lines could be made
practical. It isn't obvious how to do step (3) in place. Either you end up
allocating extra storage to do it, in which case you might as well have used
a merge sort, or you end up doing some extra shuffling around o
I'm definitely open for any better choice, I'm not in hurry to close
this one up. Sure, I hope we can
reach a consensus before I go on vacation this weekend:-)
So here is the planB alan is proposing, no API doc added yet, but you
should know what it means. I will add the doc
in later if we a
> Vadim-It would be very interesting if something along these lines could be
made practical. It isn't obvious how to do step (3) in place. Either you
end up allocating extra storage to do it, in which case you might as well
have used a merge sort, or you end up doing some extra shuffling aroun
Stephen Colebourne wrote:
Joe Darcy wrote:
What other utility methods would have broad enough use and
applicability to go into a common java.util class?
Joe,
You've asked for a call for ideas, but not given any indication of
process. Are you going to evaluate everything that comes in and pick
Changeset: 46406871599c
Author:sherman
Date: 2009-09-11 16:36 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/46406871599c
6881337: ZipEntry.setComment() was accidentally changed back to old spec/impl
in jdk7-b64
Summary: restored the correct spec and implementation of setCom
Martin Buchholz wrote:
It is believed that the java memory model allows Class.getName()
to return null.
This is one of those methods with an intentional data race.
Probably this has not been seen in practice because only
a perverse or adversarial runtime would load the "name" field
twice, out-of-
On Fri, Sep 11, 2009 at 16:48, Joe Darcy wrote:
> Martin Buchholz wrote:
>>
>> It is believed that the java memory model allows Class.getName()
>> to return null.
>> This is one of those methods with an intentional data race.
>> Probably this has not been seen in practice because only
>> a perverse
Martin Buchholz wrote:
On Fri, Sep 11, 2009 at 16:48, Joe Darcy wrote:
Martin Buchholz wrote:
It is believed that the java memory model allows Class.getName()
to return null.
This is one of those methods with an intentional data race.
Probably this has not been seen in practice because
27 matches
Mail list logo
