Nabble - OpenJDK Core Libraries

Re: hg: jdk7/tl/jdk: 3 new changesets

2009-11-27T21:24:02Z

Bob Lee wrote:

> On Wed, Oct 21, 2009 at 1:02 PM, <xueming.shen@...
> <mailto:xueming.shen@...>> wrote:
>
> 4206909: want java.util.zip to work for interactive use (Z_SYNC_FLUSH)
> Summary: Add sync_flush option into Deflater/DefalterOutputStream
> Reviewed-by: martin, alanb
>
> ! src/share/classes/java/util/zip/Deflater.java
> ! src/share/classes/java/util/zip/DeflaterOutputStream.java
> ! src/share/native/java/util/zip/Deflater.c
> + test/java/util/zip/InflateIn_DeflateOut.java
>
>
> Should we use an enum for the flush strategies? It would help separate
> them from the compression strategies, and it would make the new method
> easier to use because it would be obvious at compile time which values
> you can pass in (as opposed to allowing any random int).
>

Bob,

There was discussion on whether or not the enum should be used instead
of the raw integter tyep. Using an enum has
clear advantage as you pointed but would be inconsistent with existing
parameters (the strategy for example) . We settled
with the raw integer to prefer the local consistency.

> Also, we could add a note about how alternate flush strategies can
> negatively affect compatibility with tools like WinZip.
What exactly is this incompatibility you refer here?

Sherman

hg: jdk7/tl/jdk: 3 new changesets

2009-11-26T16:56:19Z

Changeset: 7871897537b1
Author: weijun
Date: 2009-11-27 08:51 +0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7871897537b1

6853328: Support OK-AS-DELEGATE flag
Reviewed-by: valeriep

! src/share/classes/com/sun/security/jgss/ExtendedGSSContext.java
! src/share/classes/org/ietf/jgss/GSSContext.java
! src/share/classes/sun/net/www/protocol/http/spnego/NegotiatorImpl.java
! src/share/classes/sun/security/jgss/GSSContextImpl.java
! src/share/classes/sun/security/jgss/krb5/InitialToken.java
! src/share/classes/sun/security/jgss/krb5/Krb5Context.java
! src/share/classes/sun/security/jgss/spi/GSSContextSpi.java
! src/share/classes/sun/security/jgss/spnego/SpNegoContext.java
! src/share/classes/sun/security/jgss/wrapper/NativeGSSContext.java
! src/share/classes/sun/security/krb5/Credentials.java
! src/share/classes/sun/security/krb5/internal/CredentialsUtil.java
! test/sun/security/krb5/auto/Context.java
! test/sun/security/krb5/auto/KDC.java
+ test/sun/security/krb5/auto/OkAsDelegate.java
+ test/sun/security/krb5/auto/OkAsDelegateXRealm.java
+ test/sun/security/krb5/auto/ok-as-delegate-xrealm.sh
+ test/sun/security/krb5/auto/ok-as-delegate.sh

Changeset: a7bf281b1de3
Author: weijun
Date: 2009-11-27 08:51 +0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a7bf281b1de3

6901085: SPNEGO does not works with native program
Reviewed-by: valeriep

! src/share/classes/sun/security/jgss/spnego/SpNegoContext.java

Changeset: a7d0572340fd
Author: weijun
Date: 2009-11-27 08:51 +0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a7d0572340fd

6770883: Infinite loop if SPNEGO specified as sun.security.jgss.mechanism
Reviewed-by: valeriep

! src/share/classes/sun/security/jgss/spnego/SpNegoMechFactory.java
+ test/sun/security/jgss/spnego/NoSpnegoAsDefMech.java

Re: Need reviewer - java.template changes

2009-11-26T13:24:52Z

Le 26/11/2009 19:18, Kelly O'Hair a écrit :

> Thanks.
>
> I don't quite understand the 'prefer the original' comment, all I'm
> adding
> is a .template suffix, the basename is still there, nothing was taken
> away.
>
> In the Makefiles and the ant scripts it makes life so much easier with
> this .template suffix. Maybe it's only something a 'build' person
> would love. ;^)
>
> -kto

You're not alone.
I currently use a patched version of eclipse to be able to incrementally
compile
the jdk with eclipse.
One reason is that because templates ends with ".java", they are recognized,
by eclipse as Java classes and eclipse behaves strangely when you try to
refactor
some code let say in package java.dyn, it also try to refactor the templates
and fails.

Rémi

>
> Alan Bateman wrote:
>> Kelly O'Hair wrote:
>>> Need reviewer.
>>>
>>> 6903197: Some java template files need to be renamed to .java.template
>>> http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-tl-6903197/webrev/
>> Looks okay to me (although I prefer the original names :-). It would
>> be good to send a heads-up to i18n-dev for the changes to generation
>> of the locales.
>>
>> -Alan.

Re: Need reviewer - java.template changes

2009-11-26T10:18:50Z

Thanks.

I don't quite understand the 'prefer the original' comment, all I'm adding
is a .template suffix, the basename is still there, nothing was taken away.

In the Makefiles and the ant scripts it makes life so much easier with
this .template suffix. Maybe it's only something a 'build' person would love. ;^)

-kto

Alan Bateman wrote:

> Kelly O'Hair wrote:
>> Need reviewer.
>>
>> 6903197: Some java template files need to be renamed to .java.template
>> http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-tl-6903197/webrev/
> Looks okay to me (although I prefer the original names :-). It would be
> good to send a heads-up to i18n-dev for the changes to generation of the
> locales.
>
> -Alan.

Re: hg: jdk7/tl/jdk: 3 new changesets

2009-11-26T01:00:04Z

Bob Lee wrote:
> :
>
> Should we use an enum for the flush strategies? It would help separate
> them from the compression strategies, and it would make the new method
> easier to use because it would be obvious at compile time which values
> you can pass in (as opposed to allowing any random int).
>
> Also, we could add a note about how alternate flush strategies can
> negatively affect compatibility with tools like WinZip.
This is a tough one. Enums have clear advantages but it isn't always
clear if it is the right thing (from a consistency point of view) when
updating APIs that date from before enums. In this case it probably
isn't too bad in that many applications use DeflaterOutputStream rather
than using Deflater directly.

I wasn't aware of any compatibility issues with WinZip (Sherman, do
might know about this?). The main motive, as you probably know, was the
compressed network stream rather than zip files.

-Alan.

Re: Gap Buffer based AbstractStringBuilder implementation

2009-11-26T00:57:43Z

I think, we can overcome the slowdown. The point of my prototype is to check the general performance characteristics. Slowdown is more likely due to the poorly optimized extra method call to keep all logic in one place. Normally the gap buffer algorithm should add only one comparison overhead to the common case which will not to be observable in benchmarks.

I have previously thought about implementing a similar behavior in other array-based growing structures, but it is not worth it. You can easily use your previous data structures for pre-appending algorithms - just by appending to end and iterating from reverse. But you can't do that in a StringBuilder because StringBuilder itself is the composed data. So, in my opinion, ArrayList is not a good analogy for this case.

StringBuilder, as its name suggests, is for building strings and building string by appending to end is only one of the ways of doing it.

I think we should go for this if we can do it without an observable slowdown.

On Thu, Nov 26, 2009 at 1:02 AM, Martin Buchholz <martinrb@...> wrote:

On Wed, Nov 25, 2009 at 21:24, Martin Buchholz <martinrb@...> wrote:
> On Mon, Nov 23, 2009 at 22:51, Goktug Gokdogan <gokdogan@...> wrote:
>> Nobody is interested or everybody is busy?
>
> I think there's a place for a StringBuilder-like
> abstraction that uses a gap buffer,
> but it shouldn't replace StringBuilder.

Let me qualify that.

It is hard to sell the small slowdown in the common case
to make other (rare?) operations much faster.
ArrayList should have been implemented to allow
O(1) insert at both ends, like ArrayDeque,
but it is hard to persuade the maintainers
that such a change is worth making today,
when the benchmarks all exercise only the common case.
Similarily for a hypothetical GapArrayList.
On the other hand, on modern cpus
arithmetic is ever closer to being "free",
so it is easier to justify the extra computation.

Martin

Re: Need reviewer - java.template changes

2009-11-26T00:42:10Z

Kelly O'Hair wrote:
> Need reviewer.
>
> 6903197: Some java template files need to be renamed to .java.template
> http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-tl-6903197/webrev/
Looks okay to me (although I prefer the original names :-). It would be
good to send a heads-up to i18n-dev for the changes to generation of the
locales.

-Alan.

Re: Fixes to java.util.zip javadoc

2009-11-26T00:37:05Z

Martin Buchholz wrote:

> Hi Sherman,
>
> Here are some javadoc fixes to recent changes in java.util.zip:
>
> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/ziplink/
>
> Please review.
>
> Martin
>

Looks good to me. I've created the following to track this:
6905029: Broken links in Deflater and DeflaterOutputStream javadoc

-Alan.

Re: Gap Buffer based AbstractStringBuilder implementation

2009-11-25T22:02:36Z

On Wed, Nov 25, 2009 at 21:24, Martin Buchholz <martinrb@...> wrote:
> On Mon, Nov 23, 2009 at 22:51, Goktug Gokdogan <gokdogan@...> wrote:
>> Nobody is interested or everybody is busy?
>
> I think there's a place for a StringBuilder-like
> abstraction that uses a gap buffer,
> but it shouldn't replace StringBuilder.

Let me qualify that.

It is hard to sell the small slowdown in the common case
to make other (rare?) operations much faster.
ArrayList should have been implemented to allow
O(1) insert at both ends, like ArrayDeque,
but it is hard to persuade the maintainers
that such a change is worth making today,
when the benchmarks all exercise only the common case.
Similarily for a hypothetical GapArrayList.
On the other hand, on modern cpus
arithmetic is ever closer to being "free",
so it is easier to justify the extra computation.

Martin

Re: Gap Buffer based AbstractStringBuilder implementation

2009-11-25T21:24:12Z

On Mon, Nov 23, 2009 at 22:51, Goktug Gokdogan <gokdogan@...> wrote:
> Nobody is interested or everybody is busy?

I think there's a place for a StringBuilder-like
abstraction that uses a gap buffer,
but it shouldn't replace StringBuilder.

Like ArrayList, users of StringBuilder
expect that it is very efficient for
appends, but no other operations.
I would think that most of the time
a gap buffer would not be used
just to create a string, but instead
would be a longer-lived software entity.
Gap buffers are used in emacs to implement
long-lived text buffers, and there the equivalent
of toString is a rare operation.

Martin

Re: Gap Buffer based AbstractStringBuilder implementation

2009-11-25T20:23:51Z

Actually, this code is not related to size change or management, instead it modifies where the builder keeps the gap taking into account the last change position. So I think it is better not to handle these two issues together.

On Tue, Nov 24, 2009 at 4:08 AM, Marek Kozieł <develop4lasu@...> wrote:

2009/11/17 Goktug Gokdogan <gokdogan@...>:

> Hi.
> As you know, java.lang.StringXXXX classes favor insertion to the end in
> terms of performance. Adding to beginning or middle of these sequences
> causes most of the array to be shifted toward the end every time. Every ones
> in a while I end up changing my algorithms those are based on prefixing
> strings (ex. building a fully qualified name from class name to root
> direction). Sometimes these kind of changes could result in less readable
> code. And I should note that, there are lots of developers out there who
> does not know the internal details of these classes.
> Anyway, this behavior was frustrating me for a while and I decided to
> suggest a gap buffer based modification to AbstractStringBuilder to solve
> this problem but never had time before to prototype it.
> I tested the original StringBuilder against the prototype. Preliminary
> results for the duration of 100000 insertions of a short string:
>    Original | Prototype
>    append => ~33 | ~34
> insert beginning => ~32000 | ~38
>    insert random => ~16000 | ~10000
>
> A negligible overhead appears for appending (which could be avoided with
> shortcuts), but lots of performance gain achieved for other cases.
> If we handle insertion at zero as a special case in insert method or if we
> add an another method like 'prepend', the insertion at beginning will show
> exactly same performance characteristics of insertion at the end.
> In my opinion, this is a well-worth modification to string building classes.
> If anybody agrees on sponsoring, I can tidy up code and contribute to
> OpenJDK.
> - Goktug
>
> PS: I've used following code for rough testing:
>
> private static final int LOOP_COUNT = 100000;
> public static void main(String[] args) {
> long nanoTime = System.nanoTime();
> testStandardAppend();
> //testAppendBeginning();
> //testAppendRandom();
> long span = System.nanoTime() - nanoTime;
> System.out.println(span / 1000000);
> }
> private static void testStandardAppend() {
> StringBuilder builder = new StringBuilder("initial");
> for (int i = 0; i < LOOP_COUNT; i++) {
> builder.append("tryouts");
> }
> }
> private static void testAppendBeginning() {
> StringBuilder builder = new StringBuilder("initial");
> for (int i = 0; i < LOOP_COUNT; i++) {
> builder.insert(0, "tryouts");
> }
> }
> private static void testAppendRandom() {
> Random random = new Random();
> StringBuilder builder = new StringBuilder("initial");
> for (int i = 0; i < LOOP_COUNT; i++) {
> builder.insert(random.nextInt(builder.length()), "tryouts");
> }
> }

Hello.

I think there is no point to implement that without size manager for
such resizeable structures because this mean that work will have to be
done twice.
So if any one would like to reimplement AbstractStringBuilder he
should also test how much custom memory management impact on used
memory, including decreasing buffer, and exchange size*=2 capacity
increasing.
Smf like:
if (size<some) size =max(size*2,requested*3/2);
else size = max(size+const,requested+const);

There are many reasons why String cannot share memory with changeable Objects.
If anything can be optimized then in my opinion it is:
Returned String can be hold in Builder using Reference (so it could be
garbaged ) and returned again if no modification were performed, and
on modification Reference should be cleaned.

Following String problems If there are concerns about unnecessary
String creations i suggest add one more Interface as standard rather
than hard to control solutions (need still some analysis):

interface ToStringBuilder{
// Appends current object to given builder, or created new builder
if null is given
StringBuilder appendTo(StringBuilder ret);
}

class SampleImplementation implements ToStringBuilder{

String toString(){
return appendTo(null).toString();
}

StringBuilder toBuilder(StringBuilder ret){
if (ret==null) ret= new StringBuilder();
...
return ret;
}
}

This could get caught up with efficiency.

The only thing which need to be considered is easy way to add some
type of simple transaction on this(but i'm not sure about it):

/* If object is appending data to builder and exception occurs (so
proper endAppendTransation will be not called) then all appends after
this call will be discarded */
public void startAppendTransation(Object key)

public void endAppendTransation(Object key)

--
Regards.
Lasu aka Marek Kozieł

http://lasu2string.blogspot.com/

Fixes to java.util.zip javadoc

2009-11-25T19:06:28Z

Hi Sherman,

Here are some javadoc fixes to recent changes in java.util.zip:

http://cr.openjdk.java.net/~martin/webrevs/openjdk7/ziplink/

Please review.

Martin

Re: Need reviewer - java.template changes

2009-11-25T14:47:42Z

The Basic-X.java related changes look good to me.

Martin

On Wed, Nov 25, 2009 at 14:34, Kelly O'Hair <Kelly.Ohair@...> wrote:

> Need reviewer.
>
> 6903197: Some java template files need to be renamed to .java.template
> http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-tl-6903197/webrev/
>
> Changing a few more java source template filenames:
>
> make/tools/CharsetMapping/DoubleByte-X.java.template
> (was make/tools/CharsetMapping/DoubleByte-X.java)
>
> make/tools/CharsetMapping/SingleByte-X.java.template
> (was make/tools/CharsetMapping/SingleByte-X.java)
>
> src/share/classes/sun/util/CoreResourceBundleControl-XLocales.java.template
> (was src/share/classes/sun/util/CoreResourceBundleControl-XLocales.java)
>
> src/share/classes/sun/util/LocaleDataMetaInfo-XLocales.java.template
> (was src/share/classes/sun/util/LocaleDataMetaInfo-XLocales.java)
>
> test/java/util/Formatter/Basic-X.java.template
> (was test/java/util/Formatter/Basic-X.java)
>
> -kto
>

Need reviewer - java.template changes

2009-11-25T14:34:48Z

Need reviewer.

6903197: Some java template files need to be renamed to .java.template
http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-tl-6903197/webrev/

Changing a few more java source template filenames:

make/tools/CharsetMapping/DoubleByte-X.java.template
(was make/tools/CharsetMapping/DoubleByte-X.java)

make/tools/CharsetMapping/SingleByte-X.java.template
(was make/tools/CharsetMapping/SingleByte-X.java)

src/share/classes/sun/util/CoreResourceBundleControl-XLocales.java.template
(was src/share/classes/sun/util/CoreResourceBundleControl-XLocales.java)

src/share/classes/sun/util/LocaleDataMetaInfo-XLocales.java.template
(was src/share/classes/sun/util/LocaleDataMetaInfo-XLocales.java)

test/java/util/Formatter/Basic-X.java.template
(was test/java/util/Formatter/Basic-X.java)

-kto

hg: jdk7/tl/jdk: 6904183: Fix jdk/test/com/sun/jdi tests to run with -samevm

2009-11-25T10:50:14Z

Changeset: 57195a368d33
Author: ohair
Date: 2009-11-25 08:24 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/57195a368d33

6904183: Fix jdk/test/com/sun/jdi tests to run with -samevm
Reviewed-by: dcubed

! test/Makefile
! test/ProblemList.txt
! test/com/sun/jdi/BadHandshakeTest.java
! test/com/sun/jdi/DoubleAgentTest.java
! test/com/sun/jdi/ExclusiveBind.java
! test/com/sun/jdi/JITDebug.sh
! test/com/sun/jdi/RepStep.java
! test/com/sun/jdi/RunToExit.java
! test/com/sun/jdi/SimulResumerTest.java
! test/com/sun/jdi/Solaris32AndSolaris64Test.sh
! test/com/sun/jdi/VMConnection.java
! test/com/sun/jdi/connect/spi/DebugUsingCustomConnector.java
! test/com/sun/jdi/connect/spi/GeneratedConnectors.java
! test/com/sun/jdi/connect/spi/SimpleLaunchingConnector.java
! test/com/sun/jdi/redefine/RedefineTest.java

Re: hg: jdk7/tl/jdk: 3 new changesets

2009-11-24T09:06:08Z

On Wed, Oct 21, 2009 at 1:02 PM, <xueming.shen@...> wrote:

4206909: want java.util.zip to work for interactive use (Z_SYNC_FLUSH)
Summary: Add sync_flush option into Deflater/DefalterOutputStream
Reviewed-by: martin, alanb

! src/share/classes/java/util/zip/Deflater.java
! src/share/classes/java/util/zip/DeflaterOutputStream.java
! src/share/native/java/util/zip/Deflater.c
+ test/java/util/zip/InflateIn_DeflateOut.java

Should we use an enum for the flush strategies? It would help separate them from the compression strategies, and it would make the new method easier to use because it would be obvious at compile time which values you can pass in (as opposed to allowing any random int).

Also, we could add a note about how alternate flush strategies can negatively affect compatibility with tools like WinZip.

Bob

Re: Gap Buffer based AbstractStringBuilder implementation

2009-11-24T01:08:20Z

2009/11/17 Goktug Gokdogan <gokdogan@...>:

> Hi.
> As you know, java.lang.StringXXXX classes favor insertion to the end in
> terms of performance. Adding to beginning or middle of these sequences
> causes most of the array to be shifted toward the end every time. Every ones
> in a while I end up changing my algorithms those are based on prefixing
> strings (ex. building a fully qualified name from class name to root
> direction). Sometimes these kind of changes could result in less readable
> code. And I should note that, there are lots of developers out there who
> does not know the internal details of these classes.
> Anyway, this behavior was frustrating me for a while and I decided to
> suggest a gap buffer based modification to AbstractStringBuilder to solve
> this problem but never had time before to prototype it.
> I tested the original StringBuilder against the prototype. Preliminary
> results for the duration of 100000 insertions of a short string:
>    Original | Prototype
>    append => ~33 | ~34
> insert beginning => ~32000 | ~38
>    insert random => ~16000 | ~10000
>
> A negligible overhead appears for appending (which could be avoided with
> shortcuts), but lots of performance gain achieved for other cases.
> If we handle insertion at zero as a special case in insert method or if we
> add an another method like 'prepend', the insertion at beginning will show
> exactly same performance characteristics of insertion at the end.
> In my opinion, this is a well-worth modification to string building classes.
> If anybody agrees on sponsoring, I can tidy up code and contribute to
> OpenJDK.
> - Goktug
>
> PS: I've used following code for rough testing:
>
> private static final int LOOP_COUNT = 100000;
> public static void main(String[] args) {
> long nanoTime = System.nanoTime();
> testStandardAppend();
> //testAppendBeginning();
> //testAppendRandom();
> long span = System.nanoTime() - nanoTime;
> System.out.println(span / 1000000);
> }
> private static void testStandardAppend() {
> StringBuilder builder = new StringBuilder("initial");
> for (int i = 0; i < LOOP_COUNT; i++) {
> builder.append("tryouts");
> }
> }
> private static void testAppendBeginning() {
> StringBuilder builder = new StringBuilder("initial");
> for (int i = 0; i < LOOP_COUNT; i++) {
> builder.insert(0, "tryouts");
> }
> }
> private static void testAppendRandom() {
> Random random = new Random();
> StringBuilder builder = new StringBuilder("initial");
> for (int i = 0; i < LOOP_COUNT; i++) {
> builder.insert(random.nextInt(builder.length()), "tryouts");
> }
> }

Hello.

I think there is no point to implement that without size manager for
such resizeable structures because this mean that work will have to be
done twice.
So if any one would like to reimplement AbstractStringBuilder he
should also test how much custom memory management impact on used
memory, including decreasing buffer, and exchange size*=2 capacity
increasing.
Smf like:
if (size<some) size =max(size*2,requested*3/2);
else size = max(size+const,requested+const);

There are many reasons why String cannot share memory with changeable Objects.
If anything can be optimized then in my opinion it is:
Returned String can be hold in Builder using Reference (so it could be
garbaged ) and returned again if no modification were performed, and
on modification Reference should be cleaned.

Following String problems If there are concerns about unnecessary
String creations i suggest add one more Interface as standard rather
than hard to control solutions (need still some analysis):

interface ToStringBuilder{
// Appends current object to given builder, or created new builder
if null is given
StringBuilder appendTo(StringBuilder ret);
}

class SampleImplementation implements ToStringBuilder{

String toString(){
return appendTo(null).toString();
}

StringBuilder toBuilder(StringBuilder ret){
if (ret==null) ret= new StringBuilder();
...
return ret;
}
}

This could get caught up with efficiency.

The only thing which need to be considered is easy way to add some
type of simple transaction on this(but i'm not sure about it):

/* If object is appending data to builder and exception occurs (so
proper endAppendTransation will be not called) then all appends after
this call will be discarded */
public void startAppendTransation(Object key)

public void endAppendTransation(Object key)

--
Regards.
Lasu aka Marek Kozieł

http://lasu2string.blogspot.com/

Re: Gap Buffer based AbstractStringBuilder implementation

2009-11-23T22:51:13Z

Nobody is interested or everybody is busy?

On Tue, Nov 17, 2009 at 3:16 AM, Goktug Gokdogan <gokdogan@...> wrote:

Hi.

As you know, java.lang.StringXXXX classes favor insertion to the end in terms of performance. Adding to beginning or middle of these sequences causes most of the array to be shifted toward the end every time. Every ones in a while I end up changing my algorithms those are based on prefixing strings (ex. building a fully qualified name from class name to root direction). Sometimes these kind of changes could result in less readable code. And I should note that, there are lots of developers out there who does not know the internal details of these classes.

Anyway, this behavior was frustrating me for a while and I decided to suggest a gap buffer based modification to AbstractStringBuilder to solve this problem but never had time before to prototype it.

I tested the original StringBuilder against the prototype. Preliminary results for the duration of 100000 insertions of a short string:

   Original | Prototype

   append => ~33 | ~34
insert beginning => ~32000 | ~38

   insert random => ~16000 | ~10000

A negligible overhead appears for appending (which could be avoided with shortcuts), but lots of performance gain achieved for other cases.

If we handle insertion at zero as a special case in insert method or if we add an another method like 'prepend', the insertion at beginning will show exactly same performance characteristics of insertion at the end.

In my opinion, this is a well-worth modification to string building classes. If anybody agrees on sponsoring, I can tidy up code and contribute to OpenJDK.

- Goktug


PS: I've used following code for rough testing:

private static final int LOOP_COUNT = 100000;

public static void main(String[] args) {
long nanoTime = System.nanoTime();

testStandardAppend();
//testAppendBeginning();
//testAppendRandom();

long span = System.nanoTime() - nanoTime;
System.out.println(span / 1000000);
}

private static void testStandardAppend() {
StringBuilder builder = new StringBuilder("initial");
for (int i = 0; i < LOOP_COUNT; i++) {

builder.append("tryouts");
}
}

private static void testAppendBeginning() {

StringBuilder builder = new StringBuilder("initial");
for (int i = 0; i < LOOP_COUNT; i++) {

builder.insert(0, "tryouts");
}
}

private static void testAppendRandom() {

Random random = new Random();
StringBuilder builder = new StringBuilder("initial");

for (int i = 0; i < LOOP_COUNT; i++) {
builder.insert(random.nextInt(builder.length()), "tryouts");

}
}

hg: jdk7/tl/langtools: 3 new changesets

2009-11-23T22:33:47Z

Changeset: 4c8c6159159c
Author: katleman
Date: 2009-11-12 15:36 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/4c8c6159159c

Added tag jdk7-b76 for changeset 8fb9b4be3cb1

! .hgtags

Changeset: 0398ae15b90a
Author: tbell
Date: 2009-11-17 10:35 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/0398ae15b90a

Merge

- src/share/classes/com/sun/tools/classfile/ModuleExportTable_attribute.java
- src/share/classes/com/sun/tools/classfile/ModuleMemberTable_attribute.java
- src/share/classes/com/sun/tools/classfile/Module_attribute.java

Changeset: b1508b6affd8
Author: tbell
Date: 2009-11-23 19:58 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/b1508b6affd8

Merge

hg: jdk7/tl/jdk: 5 new changesets

2009-11-23T22:28:33Z

Changeset: 7916c43cc007
Author: ohair
Date: 2009-11-04 11:19 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7916c43cc007

Merge

! make/java/redist/Makefile

Changeset: 8fb602395be0
Author: ohair
Date: 2009-11-08 14:49 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8fb602395be0

Merge

Changeset: 941b3fd6c22b
Author: katleman
Date: 2009-11-12 15:35 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/941b3fd6c22b

Added tag jdk7-b76 for changeset 8fb602395be0

! .hgtags

Changeset: c56b9022a4f3
Author: tbell
Date: 2009-11-17 10:25 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c56b9022a4f3

Merge

- src/share/classes/com/sun/jmx/event/DaemonThreadFactory.java
- src/share/classes/com/sun/jmx/event/EventBuffer.java
- src/share/classes/com/sun/jmx/event/EventClientFactory.java
- src/share/classes/com/sun/jmx/event/EventConnection.java
- src/share/classes/com/sun/jmx/event/EventParams.java
- src/share/classes/com/sun/jmx/event/LeaseManager.java
- src/share/classes/com/sun/jmx/event/LeaseRenewer.java
- src/share/classes/com/sun/jmx/event/ReceiverBuffer.java
- src/share/classes/com/sun/jmx/event/RepeatedSingletonJob.java
- src/share/classes/com/sun/jmx/interceptor/DispatchInterceptor.java
- src/share/classes/com/sun/jmx/interceptor/DomainDispatchInterceptor.java
- src/share/classes/com/sun/jmx/interceptor/MBeanServerInterceptorSupport.java
- src/share/classes/com/sun/jmx/interceptor/NamespaceDispatchInterceptor.java
- src/share/classes/com/sun/jmx/interceptor/SingleMBeanForwarder.java
- src/share/classes/com/sun/jmx/mbeanserver/MBeanInjector.java
- src/share/classes/com/sun/jmx/mbeanserver/NotificationMBeanSupport.java
- src/share/classes/com/sun/jmx/mbeanserver/NotifySupport.java
- src/share/classes/com/sun/jmx/mbeanserver/PerThreadGroupPool.java
- src/share/classes/com/sun/jmx/namespace/DomainInterceptor.java
- src/share/classes/com/sun/jmx/namespace/HandlerInterceptor.java
- src/share/classes/com/sun/jmx/namespace/NamespaceInterceptor.java
- src/share/classes/com/sun/jmx/namespace/ObjectNameRouter.java
- src/share/classes/com/sun/jmx/namespace/RoutingConnectionProxy.java
- src/share/classes/com/sun/jmx/namespace/RoutingMBeanServerConnection.java
- src/share/classes/com/sun/jmx/namespace/RoutingProxy.java
- src/share/classes/com/sun/jmx/namespace/RoutingServerProxy.java
- src/share/classes/com/sun/jmx/namespace/package.html
- src/share/classes/com/sun/jmx/namespace/serial/DefaultRewritingProcessor.java
- src/share/classes/com/sun/jmx/namespace/serial/IdentityProcessor.java
- src/share/classes/com/sun/jmx/namespace/serial/JMXNamespaceContext.java
- src/share/classes/com/sun/jmx/namespace/serial/RewritingProcessor.java
- src/share/classes/com/sun/jmx/namespace/serial/RoutingOnlyProcessor.java
- src/share/classes/com/sun/jmx/namespace/serial/SerialRewritingProcessor.java
- src/share/classes/com/sun/jmx/namespace/serial/package.html
- src/share/classes/com/sun/jmx/remote/internal/ProxyInputStream.java
- src/share/classes/com/sun/jmx/remote/util/EventClientConnection.java
- src/share/classes/javax/management/ClientContext.java
- src/share/classes/javax/management/Description.java
- src/share/classes/javax/management/DescriptorFields.java
- src/share/classes/javax/management/DynamicWrapperMBean.java
- src/share/classes/javax/management/GenericMBeanException.java
- src/share/classes/javax/management/Impact.java
- src/share/classes/javax/management/MBean.java
- src/share/classes/javax/management/ManagedAttribute.java
- src/share/classes/javax/management/ManagedOperation.java
- src/share/classes/javax/management/NotificationInfo.java
- src/share/classes/javax/management/NotificationInfos.java
- src/share/classes/javax/management/ObjectNameTemplate.java
- src/share/classes/javax/management/QueryNotificationFilter.java
- src/share/classes/javax/management/QueryParser.java
- src/share/classes/javax/management/SendNotification.java
- src/share/classes/javax/management/event/EventClient.java
- src/share/classes/javax/management/event/EventClientDelegate.java
- src/share/classes/javax/management/event/EventClientDelegateMBean.java
- src/share/classes/javax/management/event/EventClientNotFoundException.java
- src/share/classes/javax/management/event/EventConsumer.java
- src/share/classes/javax/management/event/EventForwarder.java
- src/share/classes/javax/management/event/EventReceiver.java
- src/share/classes/javax/management/event/EventRelay.java
- src/share/classes/javax/management/event/EventSubscriber.java
- src/share/classes/javax/management/event/FetchingEventForwarder.java
- src/share/classes/javax/management/event/FetchingEventRelay.java
- src/share/classes/javax/management/event/ListenerInfo.java
- src/share/classes/javax/management/event/NotificationManager.java
- src/share/classes/javax/management/event/RMIPushEventForwarder.java
- src/share/classes/javax/management/event/RMIPushEventRelay.java
- src/share/classes/javax/management/event/RMIPushServer.java
- src/share/classes/javax/management/event/package-info.java
- src/share/classes/javax/management/namespace/JMXDomain.java
- src/share/classes/javax/management/namespace/JMXNamespace.java
- src/share/classes/javax/management/namespace/JMXNamespaceMBean.java
- src/share/classes/javax/management/namespace/JMXNamespacePermission.java
- src/share/classes/javax/management/namespace/JMXNamespaceView.java
- src/share/classes/javax/management/namespace/JMXNamespaces.java
- src/share/classes/javax/management/namespace/JMXRemoteNamespace.java
- src/share/classes/javax/management/namespace/JMXRemoteNamespaceMBean.java
- src/share/classes/javax/management/namespace/MBeanServerConnectionWrapper.java
- src/share/classes/javax/management/namespace/MBeanServerSupport.java
- src/share/classes/javax/management/namespace/VirtualEventManager.java
- src/share/classes/javax/management/namespace/package-info.java
- src/share/classes/javax/management/openmbean/MXBeanMapping.java
- src/share/classes/javax/management/openmbean/MXBeanMappingClass.java
- src/share/classes/javax/management/openmbean/MXBeanMappingFactory.java
- src/share/classes/javax/management/openmbean/MXBeanMappingFactoryClass.java
- src/share/classes/javax/management/remote/IdentityMBeanServerForwarder.java
- src/share/classes/sun/net/www/protocol/http/HttpLogFormatter.java
- src/share/classes/sun/net/www/protocol/http/NegotiateCallbackHandler.java
- src/share/classes/sun/net/www/protocol/http/NegotiatorImpl.java
- src/share/classes/sun/security/ssl/KerberosPreMasterSecret.java
- src/windows/classes/sun/net/www/protocol/http/NTLMAuthSequence.java
- src/windows/classes/sun/net/www/protocol/http/NTLMAuthentication.java
- src/windows/native/sun/net/www/protocol/http/NTLMAuthSequence.c
- test/javax/management/Introspector/AnnotatedMBeanTest.java
- test/javax/management/Introspector/AnnotatedNotificationInfoTest.java
- test/javax/management/Introspector/ExceptionsDescriptorTest.java
- test/javax/management/Introspector/MBeanDescriptionTest.java
- test/javax/management/Introspector/ObjectNameTemplateTest.java
- test/javax/management/Introspector/ParameterNameTest.java
- test/javax/management/Introspector/ResourceInjectionTest.java
- test/javax/management/MBeanServer/AttributeListMapTest.java
- test/javax/management/MBeanServer/DynamicWrapperMBeanTest.java
- test/javax/management/MBeanServer/InstanceNotFoundExceptionTest.java
- test/javax/management/MBeanServerFactory/NamedMBeanServerTest.java
- test/javax/management/ObjectName/ValueOfTest.java
- test/javax/management/context/ContextForwarderTest.java
- test/javax/management/context/ContextTest.java
- test/javax/management/context/LocaleAwareBroadcasterTest.java
- test/javax/management/context/LocaleTest.java
- test/javax/management/context/LocalizableTest.java
- test/javax/management/context/RemoteContextTest.java
- test/javax/management/context/localizable/MBeanDescriptions.properties
- test/javax/management/context/localizable/MBeanDescriptions_fr.java
- test/javax/management/context/localizable/Whatsit.java
- test/javax/management/context/localizable/WhatsitMBean.java
- test/javax/management/descriptor/DescriptorConstructorTest.java
- test/javax/management/eventService/AddRemoveListenerTest.java
- test/javax/management/eventService/CustomForwarderTest.java
- test/javax/management/eventService/EventClientExecutorTest.java
- test/javax/management/eventService/EventClientThreadTest.java
- test/javax/management/eventService/EventDelegateSecurityTest.java
- test/javax/management/eventService/EventManagerTest.java
- test/javax/management/eventService/FetchingTest.java
- test/javax/management/eventService/LeaseManagerDeadlockTest.java
- test/javax/management/eventService/LeaseTest.java
- test/javax/management/eventService/ListenerTest.java
- test/javax/management/eventService/MyFetchingEventForwarder.java
- test/javax/management/eventService/NotSerializableNotifTest.java
- test/javax/management/eventService/PublishTest.java
- test/javax/management/eventService/ReconnectableConnectorTest.java
- test/javax/management/eventService/SharingThreadTest.java
- test/javax/management/eventService/SubUnsubTest.java
- test/javax/management/eventService/SubscribeTest.java
- test/javax/management/eventService/UsingEventService.java
- test/javax/management/interop/MBeanExceptionInteropTest.java
- test/javax/management/modelmbean/DefaultDescriptorFieldTest.java
- test/javax/management/monitor/InstantiateMonitorNotificationTest.java
- test/javax/management/mxbean/CustomTypeTest.java
- test/javax/management/mxbean/JMXServiceURLTest.java
- test/javax/management/mxbean/customtypes/CustomLongMXBean.java
- test/javax/management/mxbean/customtypes/CustomMXBean.java
- test/javax/management/mxbean/customtypes/IntegerIsLongFactory.java
- test/javax/management/mxbean/customtypes/IntegerIsStringFactory.java
- test/javax/management/mxbean/customtypes/package-info.java
- test/javax/management/namespace/DomainCreationTest.java
- test/javax/management/namespace/EventWithNamespaceControlTest.java
- test/javax/management/namespace/EventWithNamespaceTest.java
- test/javax/management/namespace/ExportNamespaceTest.java
- test/javax/management/namespace/JMXDomainTest.java
- test/javax/management/namespace/JMXNamespaceSecurityTest.java
- test/javax/management/namespace/JMXNamespaceTest.java
- test/javax/management/namespace/JMXNamespaceViewTest.java
- test/javax/management/namespace/JMXNamespacesTest.java
- test/javax/management/namespace/JMXRemoteNamespaceTest.java
- test/javax/management/namespace/JMXRemoteTargetNamespace.java
- test/javax/management/namespace/LazyDomainTest.java
- test/javax/management/namespace/LeadingSeparatorsTest.java
- test/javax/management/namespace/MXBeanRefTest.java
- test/javax/management/namespace/NamespaceController.java
- test/javax/management/namespace/NamespaceControllerMBean.java
- test/javax/management/namespace/NamespaceCreationTest.java
- test/javax/management/namespace/NamespaceNotificationsTest.java
- test/javax/management/namespace/NullDomainObjectNameTest.java
- test/javax/management/namespace/NullObjectNameTest.java
- test/javax/management/namespace/QueryNamesTest.java
- test/javax/management/namespace/RemoveNotificationListenerTest.java
- test/javax/management/namespace/RoutingServerProxyTest.java
- test/javax/management/namespace/SerialParamProcessorTest.java
- test/javax/management/namespace/SourceNamespaceTest.java
- test/javax/management/namespace/VirtualMBeanNotifTest.java
- test/javax/management/namespace/VirtualMBeanTest.java
- test/javax/management/namespace/VirtualNamespaceQueryTest.java
- test/javax/management/namespace/VirtualPropsTest.java
- test/javax/management/namespace/Wombat.java
- test/javax/management/namespace/WombatMBean.java
- test/javax/management/namespace/namespace.policy
- test/javax/management/notification/SupportClearTest.java
- test/javax/management/openmbean/CompositeDataToMapTest.java
- test/javax/management/openmbean/GenericMBeanExceptionTest.java
- test/javax/management/query/QueryDottedAttrTest.java
- test/javax/management/query/QueryNotifFilterTest.java
- test/javax/management/query/QueryParseTest.java
- test/javax/management/remote/mandatory/connectorServer/CloseConnectionTest.java
- test/javax/management/remote/mandatory/connectorServer/ForwarderChainTest.java
- test/javax/management/remote/mandatory/connectorServer/StandardForwardersTest.java
- test/javax/management/remote/mandatory/version/JMXSpecVersionTest.java
- test/javax/management/standardmbean/FindMethodTest.java
- test/javax/management/standardmbean/RegistrationTest.java

Changeset: ea9411ec1458
Author: tbell
Date: 2009-11-23 19:57 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ea9411ec1458

Merge

- test/sun/tools/native2ascii/test2

hg: jdk7/tl/jaxws: 2 new changesets

2009-11-23T22:27:54Z

Changeset: 701ccbf55ae5
Author: katleman
Date: 2009-11-12 15:35 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/701ccbf55ae5

Added tag jdk7-b76 for changeset 765d2077d1e6

! .hgtags

Changeset: 5b4968c11047
Author: tbell
Date: 2009-11-17 10:23 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/5b4968c11047

Merge

hg: jdk7/tl/jaxp: 2 new changesets

2009-11-23T22:27:48Z

Changeset: 86cc67d46db5
Author: katleman
Date: 2009-11-12 15:35 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/86cc67d46db5

Added tag jdk7-b76 for changeset 233a4871d336

! .hgtags

Changeset: bfadab8c7b1b
Author: tbell
Date: 2009-11-17 10:23 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/bfadab8c7b1b

Merge

hg: jdk7/tl/hotspot: 20 new changesets

2009-11-23T22:25:45Z

Changeset: 08780c8a9f04
Author: kamg
Date: 2009-10-20 16:34 -0400
URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/08780c8a9f04

6893483: DTrace probe return values for a couple JNI methods are wrong
Summary: Fix the shadowing and incorrect macro usages
Reviewed-by: coleenp

! src/share/vm/prims/jni.cpp

Changeset: a3b9e96881fe
Author: xlu
Date: 2009-10-23 18:44 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a3b9e96881fe

Merge

Changeset: d912f17c1ae4
Author: xlu
Date: 2009-10-28 10:37 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/d912f17c1ae4

Merge

Changeset: 0a46d0c5dccb
Author: never
Date: 2009-10-15 11:47 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0a46d0c5dccb

6891750: deopt blob kills values in O5
Reviewed-by: kvn, twisti

! src/cpu/sparc/vm/sharedRuntime_sparc.cpp
+ test/compiler/6891750/Test6891750.java

Changeset: 71fdc5052e49
Author: cfang
Date: 2009-10-16 16:14 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/71fdc5052e49

Merge

Changeset: 987e948ebbc8
Author: jrose
Date: 2009-10-17 19:51 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/987e948ebbc8

6815692: method handle code needs some cleanup (post-6655638)
Summary: correctly raise exceptions, support safe bitwise "raw" conversions, fix bugs revealed by VerifyMethodHandles, remove dead code, improve debugging support
Reviewed-by: never, twisti

! src/cpu/x86/vm/methodHandles_x86.cpp
! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/klass.cpp
! src/share/vm/oops/klass.hpp
! src/share/vm/oops/markOop.cpp
! src/share/vm/oops/methodOop.cpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/prims/methodHandles.hpp

Changeset: 873ec3787992
Author: kvn
Date: 2009-10-21 09:15 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/873ec3787992

6892186: SA does not dump debug info for scalar replaced objects
Summary: Implement scalar replaced objects debug info dump in SA.
Reviewed-by: twisti

! agent/make/saenv.sh
! agent/make/saenv64.sh
! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java
! agent/src/share/classes/sun/jvm/hotspot/code/CodeCache.java
! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java
! agent/src/share/classes/sun/jvm/hotspot/code/PCDesc.java
! agent/src/share/classes/sun/jvm/hotspot/code/ScopeDesc.java
! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/sa.js
! src/share/vm/opto/callnode.cpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: f875b4f472f7
Author: twisti
Date: 2009-10-27 03:00 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f875b4f472f7

6893554: SPECjvm2008 mpegaudio fails with SecurityException
Summary: The problem occurs with negative numbers, as the 32-bit input values are sign extended into the 64-bit registers.
Reviewed-by: kvn

! src/cpu/sparc/vm/sparc.ad

Changeset: 4926bf2d292f
Author: cfang
Date: 2009-10-29 08:49 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4926bf2d292f

Merge

Changeset: fc06cd9b42c7
Author: tonyp
Date: 2009-10-23 14:34 -0400
URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/fc06cd9b42c7

6886024: G1: assert(recent_avg_pause_time_ratio() < 1.00,"All GC?")
Summary: the assert is incorrect and can fire incorrectly due to floating point inaccuracy.
Reviewed-by: apetrusenko, ysr, jcoomes

! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp

Changeset: 6270f80a7331
Author: tonyp
Date: 2009-09-30 14:50 -0400
URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6270f80a7331

6890137: G1: revamp reachable object dump
Summary: Revamp the reachable object dump debugging facility.
Reviewed-by: jmasa, apetrusenko

! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1_globals.hpp

Changeset: fa2f65ebeb08
Author: apetrusenko
Date: 2009-10-27 02:42 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/fa2f65ebeb08

6870843: G1: G1 GC memory leak
Summary: The fix addresses two memory leaks in G1 code: (1) _evac_failure_scan_stack - a resource object allocated on the C heap was not freed; (2) RSHashTable were linked into deleted list which was only cleared at full GC.
Reviewed-by: tonyp, iveresov

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/sparsePRT.cpp
! src/share/vm/gc_implementation/g1/sparsePRT.hpp

Changeset: 72a6752ac432
Author: ysr
Date: 2009-10-28 11:16 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/72a6752ac432

6818264: Heap dumper unexpectedly adds .hprof suffix
Summary: Restore old behaviour wrt HeapDumpPath; first dump goes to <file>, <n>th dump goes to <file>.<n-1>, with default value of <file> the same as before.
Reviewed-by: alanb, jcoomes, tonyp

! src/share/vm/services/heapDumper.cpp

Changeset: beb8f45ee9f0
Author: johnc
Date: 2009-10-29 09:42 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/beb8f45ee9f0

6889740: G1: OpenDS fails with "unhandled exception in compiled code"
Summary: Incorrect code was being generated for the store operation in the null case of the aastore bytecode template. The bad code was generated by the store_heap_oop routine which takes a Register as its second argument. Passing NULL_WORD (0) as the second argument causes the value to be converted to Register(0), which is rax. Thus the generated store was "mov (dst), $rax" instead of "mov (dst), $0x0". Changed calls to store_heap_oop that pass NULL_WORD as the second argument to a new routine store_heap_oop_null.
Reviewed-by: kvn, twisti

! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/templateTable_x86_64.cpp

Changeset: 29adffcb6a61
Author: tonyp
Date: 2009-10-30 13:31 -0400
URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/29adffcb6a61

Merge

Changeset: a6280c71758e
Author: trims
Date: 2009-11-05 15:44 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a6280c71758e

Merge

Changeset: 50c16f09ddf5
Author: trims
Date: 2009-11-05 15:58 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/50c16f09ddf5

6898707: Bump the HS17 build number to 05
Summary: Update the HS17 build number to 05
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 26f1542097f1
Author: ysr
Date: 2009-11-03 16:43 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/26f1542097f1

6801625: CDS: HeapDump tests crash with internal error in compactingPermGenGen.cpp
Summary: Allow iteration over the shared spaces when using CDS, repealing previous proscription. Deferred further required CDS-related cleanups of perm gen to CR 6897789.
Reviewed-by: phh, jmasa

! src/share/vm/memory/compactingPermGenGen.cpp
! src/share/vm/memory/compactingPermGenGen.hpp
! src/share/vm/memory/generation.cpp

Changeset: 9174bb32e934
Author: trims
Date: 2009-11-06 00:41 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9174bb32e934

Merge

Changeset: 455105fc81d9
Author: katleman
Date: 2009-11-12 15:35 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/455105fc81d9

Added tag jdk7-b76 for changeset 9174bb32e934

! .hgtags

hg: jdk7/tl/corba: 3 new changesets

2009-11-23T22:24:22Z

Changeset: 6995f81e3b53
Author: ohair
Date: 2009-11-04 11:19 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/6995f81e3b53

Merge

Changeset: 937144222e22
Author: ohair
Date: 2009-11-08 14:49 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/937144222e22

Merge

Changeset: 086bf925ee95
Author: katleman
Date: 2009-11-12 15:35 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/086bf925ee95

Added tag jdk7-b76 for changeset 937144222e22

! .hgtags

hg: jdk7/tl: 4 new changesets

2009-11-23T22:24:17Z

Changeset: 0619361ff7c5
Author: ohair
Date: 2009-11-04 11:19 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/rev/0619361ff7c5

Merge

Changeset: c8b63075403d
Author: ohair
Date: 2009-11-08 14:46 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/rev/c8b63075403d

Merge

Changeset: 1f17ca8353ba
Author: katleman
Date: 2009-11-12 15:35 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/rev/1f17ca8353ba

Added tag jdk7-b76 for changeset c8b63075403d

! .hgtags

Changeset: 08f13b9af1b2
Author: tbell
Date: 2009-11-23 19:55 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/rev/08f13b9af1b2

Merge

hg: jdk7/tl/jdk: 3 new changesets

2009-11-23T17:37:05Z

Changeset: 2fec95bd2192
Author: mchung
Date: 2009-11-23 08:21 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2fec95bd2192

6903638: Remove dependency on AuthPermission from SecurityConstants
Summary: Move two static fields from SecurityConstants to javax.security.auth.Subject
Reviewed-by: mullan

! src/share/classes/javax/security/auth/Subject.java
! src/share/classes/sun/security/util/SecurityConstants.java

Changeset: 542a1f9d08be
Author: mchung
Date: 2009-11-23 10:46 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/542a1f9d08be

Merge

Changeset: 826cc6f77c4a
Author: mchung
Date: 2009-11-23 14:59 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/826cc6f77c4a

Merge

hg: jdk7/tl/jdk: 2 new changesets

2009-11-23T14:55:23Z

Changeset: 03f841635453
Author: ohair
Date: 2009-11-23 09:51 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/03f841635453

6902666: Include closed tests in the test/Makefile jdk_* targets
6902667: Fix JT_HOME not working from env in jdk/test/Makefile
Reviewed-by: mullan, dcubed

! test/Makefile
! test/ProblemList.txt

Changeset: 8d555c08e267
Author: ohair
Date: 2009-11-23 13:00 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8d555c08e267

Merge

hg: jdk7/tl/jdk: 6888171: JMX Monitor API should not require JavaBeans to be present

2009-11-23T11:29:15Z

Changeset: 1ced99075109
Author: alanb
Date: 2009-11-23 19:26 +0000
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1ced99075109

6888171: JMX Monitor API should not require JavaBeans to be present
Reviewed-by: emcmanus

! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java
! src/share/classes/com/sun/jmx/mbeanserver/MBeanIntrospector.java

hg: jdk7/tl/jdk: 2 new changesets

2009-11-23T10:58:09Z

Changeset: 5d2e63dad298
Author: mullan
Date: 2009-11-23 12:36 -0500
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5d2e63dad298

6899503: Security code issue using Verisign root certificate
Summary: Add support for reordering out-of-order certificate chains
Reviewed-by: vinnie, xuelei

! src/share/classes/sun/security/validator/PKIXValidator.java

Changeset: 38960b705c30
Author: mullan
Date: 2009-11-23 13:57 -0500
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/38960b705c30

Merge

hg: jdk7/tl/jdk: 6903102: 3/3 fixes in nightly testing version of ShellScaffold.sh need to be committed

2009-11-23T09:33:17Z

Changeset: 92198fb7e908
Author: dcubed
Date: 2009-11-23 10:29 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/92198fb7e908

6903102: 3/3 fixes in nightly testing version of ShellScaffold.sh need to be committed
Summary: Merge Jim's ShellScaffold.sh fixes with Tim's ShellScaffold.sh fixes.
Reviewed-by: tbell

! test/com/sun/jdi/ShellScaffold.sh

Re: Gap Buffer based AbstractStringBuilder implementation

2009-11-23T05:25:06Z

Hi Jesús,

I'm sorry for the noise, I just forgot to consider the issues of a StringBuilder shared between threads (I'm well aware of the JMM etc). A partial "fix" of sharing only StringBuffer seems useless because we're many years past JDK1.5 and most code uses StringBuilder now; the tradeoff of synchronization versus copying is pretty bad, as you confirmed again.

I agree that getting some help from HotSpot seems to be the only solution. HotSpot is certainly able to detect the easiest case of confinement through EA, and for StringBuilder this should detect virtually all uses. HotSpot would also need to compile toString() as a intrinsic, inlining alternative non-copying code, when it detected that the buffer object is confined.

I would like to see a more general solution; we may have many other cases of potentially great optimizations that are not done just because they're not thread-safe, but could be done for thread-confined objects. A raw suggestion:

public String toString () {
return Unsafe.isConfined(this) ? optimizedToString() : standardToString();
}

In this case HotSpot only has to provide one extra helper, isConfined(), that returns true iff the argument can be proven by the compiler to be confined to a single thread. This doesn't look difficult because it's not a new operation, just an accessor to information that the optimizer already has. The result is a compile-time constant (per compilation site) so the code generated for toString() has no extra calls or branches, it's just a straight call (or inlining) of either optimizedToString() or standardToString(). (For the interpreter, C1, or C2 with EA disabled, isConfined() would just always return false.) Now the big advantage of this approach is that the library team doesn't need to poke the compiler guys to add extra intrinsic compilation for every method that may benefit from optimizations which are only safe for confined objects.

A+
Osvaldo

2009/11/22 Jesús Viñuales <serverperformance@...>

Osvaldo Doederlein wrote:
>
> Em 22/11/2009 05:55, Thomas Hawtin escreveu:
>>

>> There is a security issue there. When multiple threads are involved,
>> it is possible (though not necessily easy) to create a mutable String
>> if the backing char[] is shared.
>>
>> Tom Hawtin
>
> That's true. But there's apparently a simple solution
>
> public String toStringShared() {
> // createShared() is a package-protected helper/ctor
> String ret = String.createShared(value, 0, count);
> // Reset value, so evil user can't abuse the buffer to change
> the String.
> value = EMPTY;
> count = 0;
> return ret;
> }
> private static final char[] EMPTY = new char[0];
>
> This solution should be safe, without need of escape/alias analysis,
> because StringBuilder and StringBuffer don't have any methods that
> return a new mutable object that shares the same char[]. The only APIs
> that aliases the buffer is subSequence(), but this returns a
> CharSequence which is a read-only object.
>
> A+
> Osvaldo

I don't agree. That solution isn't safe because the involved methods aren't
synchronized (in StringBuilder), nor you have any guarantee within the Java
memory model about the visibility to other threads of your changes in the
value and count variables ... except if they are volatile. And if you have
to establish the values for more than one variable (value and count) in an
atomic fashion, the volatile approach doesn't help you. And also may cause
the String to appear to mutate if one thread calls toString() while another
is between the read of shared and the insert/append/delete operation, or
even worst, executing the operation itself).

I'm pretty sure that the only solution is a copy-on-write approach based in
a volatile boolean flag, and not a never-copy one as Andrew said (and I
remember that GNU Classpath implementation even addressed the "unused space
consumption problem" evaluating in the toString method how much unused space
had the buffer, and if the underlining char[] is too big, make a copy
instead of sharing it).

Anyway. Read carefully the evaluation section of
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6219959. Reintroducing
the copy-on-write approach was tested by Sun in 2006 approach, and "It was
discovered that the reintroduction of the sharing code caused a reproducible
regression on the order of 4% in SPECjbb2005 scores", surely for impacting
the GC or whatever. If you see the prototype description, it is perfect:
using a volatile flag, testing whether to share or to copy the char[] in the
toString method, etc.

I tried different approaches last year, and even posted one of them in this
forum (as you can see in archives) but with no luck.

My guess is that this kind of COW optimization is work for the Hotspot via
Escape analysis... or in the end of the chain, work for the MMU of the CPU.

Regards,
Jesus

RE: Gap Buffer based AbstractStringBuilder implementation

2009-11-22T14:01:45Z

Osvaldo Doederlein wrote:

>
> Em 22/11/2009 05:55, Thomas Hawtin escreveu:
>>
>> There is a security issue there. When multiple threads are involved,
>> it is possible (though not necessily easy) to create a mutable String
>> if the backing char[] is shared.
>>
>> Tom Hawtin
>
> That's true. But there's apparently a simple solution
>
> public String toStringShared() {
> // createShared() is a package-protected helper/ctor
> String ret = String.createShared(value, 0, count);
> // Reset value, so evil user can't abuse the buffer to change
> the String.
> value = EMPTY;
> count = 0;
> return ret;
> }
> private static final char[] EMPTY = new char[0];
>
> This solution should be safe, without need of escape/alias analysis,
> because StringBuilder and StringBuffer don't have any methods that
> return a new mutable object that shares the same char[]. The only APIs
> that aliases the buffer is subSequence(), but this returns a
> CharSequence which is a read-only object.
>
> A+
> Osvaldo

I don't agree. That solution isn't safe because the involved methods aren't
synchronized (in StringBuilder), nor you have any guarantee within the Java
memory model about the visibility to other threads of your changes in the
value and count variables ... except if they are volatile. And if you have
to establish the values for more than one variable (value and count) in an
atomic fashion, the volatile approach doesn't help you. And also may cause
the String to appear to mutate if one thread calls toString() while another
is between the read of shared and the insert/append/delete operation, or
even worst, executing the operation itself).

I'm pretty sure that the only solution is a copy-on-write approach based in
a volatile boolean flag, and not a never-copy one as Andrew said (and I
remember that GNU Classpath implementation even addressed the "unused space
consumption problem" evaluating in the toString method how much unused space
had the buffer, and if the underlining char[] is too big, make a copy
instead of sharing it).

Anyway. Read carefully the evaluation section of
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6219959. Reintroducing
the copy-on-write approach was tested by Sun in 2006 approach, and "It was
discovered that the reintroduction of the sharing code caused a reproducible
regression on the order of 4% in SPECjbb2005 scores", surely for impacting
the GC or whatever. If you see the prototype description, it is perfect:
using a volatile flag, testing whether to share or to copy the char[] in the
toString method, etc.

I tried different approaches last year, and even posted one of them in this
forum (as you can see in archives) but with no luck.

My guess is that this kind of COW optimization is work for the Hotspot via
Escape analysis... or in the end of the chain, work for the MMU of the CPU.

Regards,
Jesus

Re: Gap Buffer based AbstractStringBuilder implementation

2009-11-22T13:50:02Z

Osvaldo Pinali Doederlein wrote:

> public String toStringShared() {
> // createShared() is a package-protected helper/ctor
> String ret = String.createShared(value, 0, count);
> // Reset value, so evil user can't abuse the buffer to change
> the String.
> value = EMPTY;
> count = 0;
> return ret;
> }
> private static final char[] EMPTY = new char[0];
>
> This solution should be safe, without need of escape/alias analysis,
> because StringBuilder and StringBuffer don't have any methods that
> return a new mutable object that shares the same char[]. The only APIs
> that aliases the buffer is subSequence(), but this returns a
> CharSequence which is a read-only object.

You will need to look at the Java Memory Model (JMM) (which is not
sequentially consistent (SC)) to understand why this sort of thing can
never work without adding synchronized/volatile to String. You can
synchronize StringBuffer as much as you like, but it still wont work.

Tom Hawtin

Re: Gap Buffer based AbstractStringBuilder implementation

2009-11-22T11:23:59Z

Em 22/11/2009 05:55, Thomas Hawtin escreveu:

> Osvaldo Doederlein wrote:
>
>> Looks like good stuff. And it remembers me from another old issue:
>> patterns of code that demand data copying that could often be
>> avoided. Every StringBuffer/StringBuilder is ultimately consumed by a
>> toString() invocation to produce the result String, and in 99% of all
>> uses, only one such String is produced and the buffer object is
>> immediately discarded. So, toString() could pass the internal char[]
>> to the String constructor, instead of forcing its copy. The API is
>> coded conservatively to always do that copy, because in 1% of cases
>> people
>
> There is a security issue there. When multiple threads are involved,
> it is possible (though not necessily easy) to create a mutable String
> if the backing char[] is shared.
>
> Tom Hawtin

That's true. But there's apparently a simple solution

public String toStringShared() {
// createShared() is a package-protected helper/ctor
String ret = String.createShared(value, 0, count);
// Reset value, so evil user can't abuse the buffer to change
the String.
value = EMPTY;
count = 0;
return ret;
}
private static final char[] EMPTY = new char[0];

This solution should be safe, without need of escape/alias analysis,
because StringBuilder and StringBuffer don't have any methods that
return a new mutable object that shares the same char[]. The only APIs
that aliases the buffer is subSequence(), but this returns a
CharSequence which is a read-only object.

A+
Osvaldo

RE: Gap Buffer based AbstractStringBuilder implementation

2009-11-22T07:12:19Z

> There is a security issue there. When multiple threads are involved, it
> is possible (though not necessily easy) to create a mutable String if
> the backing char[] is shared.
>
> Tom Hawtin

True. I worked in a buffer-sharing / copy-on-write optimization one year
ago, and the main issue was breaking the Java lang specs regarding the
inmutability of threads, surely only a issue in theory, but it is a
brokerage.

Nevertheless, the gaining is not clear in modern systems / hotspot / Oss,
because can be garbage collection issued and memory leaks... and in fact
that optimization was there in JDK 1.4 but it was removed in 1.5 because of
that problem (see
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6219959)

But... I would love it working!!!!

:-)