From xueming.shen at sun.com  Fri May  1 19:23:03 2009
From: xueming.shen at sun.com (xueming.shen at sun.com)
Date: Fri, 01 May 2009 19:23:03 +0000
Subject: hg: jdk7/tl/jdk: 6836489: Incorrect @link usage in java.util.zip API
	doc
Message-ID: <20090501192329.E0ADCED78@hg.openjdk.java.net>

Changeset: d2114c1adb2d
Author:    sherman
Date:      2009-05-01 12:06 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d2114c1adb2d

6836489: Incorrect @link usage in java.util.zip API doc
Summary: correct the wrong @link tag
Reviewed-by: alanb

! src/share/classes/java/util/zip/ZipFile.java
! src/share/classes/java/util/zip/ZipInputStream.java
! src/share/classes/java/util/zip/ZipOutputStream.java



From fw at deneb.enyo.de  Sat May  2 12:53:00 2009
From: fw at deneb.enyo.de (Florian Weimer)
Date: Sat, 02 May 2009 14:53:00 +0200
Subject: Obscure eclipse failures with OpenJDK 7
Message-ID: <87bpqbeker.fsf@mid.deneb.enyo.de>

A stock build of OpenJDK 7 on Debian sid results in obscure failures
when running Eclipse due to internal errors in java.util.zip:

java.lang.InternalError: error code: -6
	at java.util.zip.Deflater.init(Native Method)
	at java.util.zip.Deflater.<init>(Deflater.java:140)
	at java.util.zip.ZipOutputStream.<init>(ZipOutputStream.java:117)
	at java.util.zip.ZipOutputStream.<init>(ZipOutputStream.java:103)
	at org.eclipse.mylyn.internal.tasks.core.externalization.TaskListExternalizer.writeTaskList(TaskListExternalizer.java:105)
	at org.eclipse.mylyn.internal.tasks.core.externalization.TaskListExternalizationParticipant$2.execute(TaskListExternalizationParticipant.java:126)
	at org.eclipse.mylyn.internal.tasks.core.TaskList.run(TaskList.java:654)
	at org.eclipse.mylyn.internal.tasks.core.externalization.TaskListExternalizationParticipant.save(TaskListExternalizationParticipant.java:133)
	at org.eclipse.mylyn.internal.tasks.core.externalization.AbstractExternalizationParticipant.execute(AbstractExternalizationParticipant.java:70)
	at org.eclipse.mylyn.internal.tasks.core.externalization.ExternalizationManager$ExternalizationJob.run(ExternalizationManager.java:200)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

I guess that this is an incompatibility between the system zlib (which
is loaded by Eclipse) and OpenJDK's copy.  Both use the same symbols,
and with ELF dynamic linking, it is a bit hard to predict which
definition gets picked up.  (I haven't positively identified such a
symbol clash as the actual cause, but -6 is Z_VERSION_ERROR in the
system zlib, and OpenJDK's zlib copy doesn't return this error code,
so I'm reasonably convinced I've identified the problem.)

There are several ways to work around that: Dynamically link against
the system zlib in OpenJDK (this is what I did, using the patch from
IcedTea), use "ld -r" with some linker script to hide the zlib
symbols, use hidden visibility, use symbol versioning, or rename all
definitions in the source file.

I don't know why this issue only appeared relatively recently.
Perhaps the system zlib and OpenJDK's version were somewhat
compatible, hiding the name clash.  Or there were some changes in
OpenJDK how dlopen was used.


From linuxhippy at gmail.com  Mon May  4 09:28:29 2009
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Mon, 4 May 2009 05:28:29 -0400
Subject: Inflater/Deflater improvements
Message-ID: <194f62550905040228p49bab23bl2e1132203584e723@mail.gmail.com>

Hi,

I've written some patches for Inflater/Deflater about a year ago with
Dave Bristor as contact point, however I was in hurry and suspended
work on it back then.

I would be happy if somebody could have a look at:
https://bugs.openjdk.java.net/show_bug.cgi?id=100009

... the sooner the stuff is in ... the less chance do regressions have
to hide ;)

Thank you in advance, Clemens


From Alan.Bateman at Sun.COM  Mon May  4 11:04:59 2009
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Mon, 04 May 2009 12:04:59 +0100
Subject: Review request 6834246: (ch) AsynchronousSocketChannel#write completes
	...
Message-ID: <49FECBDB.6010009@sun.com>

6834246:  (ch) AsynchronousSocketChannel#write completes with wrong 
number of bytes written under load (win)

Sherman - this is a Windows specific stability issue with 
AsynchronousSocketChannel. For cases where I/O operations complete 
immediately then it is possible that we will initiate another I/O 
operation on the same connection before the completion notification is 
delivered. For these cases the notification is simply discarded and the 
OVERLAPPED structure returned to the cache. This reduces the latency to 
the completion handler in many cases but is proving unreliable under 
load on some versions of Windows (something that we need to follow up 
with Microsoft on). The proposed fix plays it safe by deferring all 
completion handling to when the notification is received.  I'm hoping to 
push this to b59 (if approved by the release team). The webrev is here:
  http://cr.openjdk.java.net/~alanb/6834246/webrev.00/

Thanks,
Alan.


From Xueming.Shen at Sun.COM  Mon May  4 15:34:33 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Mon, 04 May 2009 08:34:33 -0700
Subject: Inflater/Deflater improvements
In-Reply-To: <194f62550905040228p49bab23bl2e1132203584e723@mail.gmail.com>
References: <194f62550905040228p49bab23bl2e1132203584e723@mail.gmail.com>
Message-ID: <49FF0B09.7040003@sun.com>

Clemens, I will be the "contact person" for this change. I will take a 
look at you patch
this week.

Thanks,
Sherman

Clemens Eisserer wrote:
> Hi,
>
> I've written some patches for Inflater/Deflater about a year ago with
> Dave Bristor as contact point, however I was in hurry and suspended
> work on it back then.
>
> I would be happy if somebody could have a look at:
> https://bugs.openjdk.java.net/show_bug.cgi?id=100009
>
> ... the sooner the stuff is in ... the less chance do regressions have
> to hide ;)
>
> Thank you in advance, Clemens
>   



From alan.bateman at sun.com  Mon May  4 18:39:08 2009
From: alan.bateman at sun.com (alan.bateman at sun.com)
Date: Mon, 04 May 2009 18:39:08 +0000
Subject: hg: jdk7/tl/jdk: 6834246: (ch) AsynchronousSocketChannel#write
	completes with wrong number of bytes written under load (win)
Message-ID: <20090504183944.7C8FCEE47@hg.openjdk.java.net>

Changeset: e1a713f0361f
Author:    alanb
Date:      2009-05-04 19:25 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e1a713f0361f

6834246: (ch) AsynchronousSocketChannel#write completes with wrong number of bytes written under load (win)
Reviewed-by: sherman

! src/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java
! src/windows/native/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.c
+ test/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java



From martinrb at google.com  Mon May  4 21:38:23 2009
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 4 May 2009 14:38:23 -0700
Subject: Inflater/Deflater improvements
In-Reply-To: <194f62550905040228p49bab23bl2e1132203584e723@mail.gmail.com>
References: <194f62550905040228p49bab23bl2e1132203584e723@mail.gmail.com>
Message-ID: <1ccfd1c10905041438h78dbcbb0i6c200ddc822861b2@mail.gmail.com>

I think many people will be interested in performance improvements
in Inflater/Deflater.  I may have time to help review.

Caution: This is an area where it can be very tricky to make
improvements.  Past efforts have optimized one usage pattern
at the cost of pessimizing another.

Martin

On Mon, May 4, 2009 at 02:28, Clemens Eisserer <linuxhippy at gmail.com> wrote:
> Hi,
>
> I've written some patches for Inflater/Deflater about a year ago with
> Dave Bristor as contact point, however I was in hurry and suspended
> work on it back then.
>
> I would be happy if somebody could have a look at:
> https://bugs.openjdk.java.net/show_bug.cgi?id=100009
>
> ... the sooner the stuff is in ... the less chance do regressions have
> to hide ;)
>
> Thank you in advance, Clemens
>


From tim.bell at sun.com  Tue May  5 04:19:40 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Tue, 05 May 2009 04:19:40 +0000
Subject: hg: jdk7/tl/corba: 6529590: flaw in
	com.sun.corba.se.impl.presentation.rmi.IDLNameTranslatorImpl
Message-ID: <20090505041941.DE8E7EEC9@hg.openjdk.java.net>

Changeset: e149090eb21a
Author:    tbell
Date:      2009-05-04 18:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/e149090eb21a

6529590: flaw in com.sun.corba.se.impl.presentation.rmi.IDLNameTranslatorImpl
Reviewed-by: darcy

! make/com/sun/corba/se/sources/Makefile
! src/share/classes/com/sun/corba/se/impl/presentation/rmi/IDLNameTranslatorImpl.java
! src/share/classes/com/sun/tools/corba/se/idl/first.set
! src/share/classes/com/sun/tools/corba/se/idl/follow.set
! src/share/classes/com/sun/tools/corba/se/idl/grammar.idl
! src/share/classes/com/sun/tools/corba/se/idl/grammar3.idl
! src/share/classes/com/sun/tools/corba/se/idl/idl.prp
! src/share/classes/com/sun/tools/corba/se/idl/idl_ja.prp
! src/share/classes/com/sun/tools/corba/se/idl/idl_zh_CN.prp
! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable.prp
! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable_ja.prp
! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable_zh_CN.prp



From tim.bell at sun.com  Tue May  5 04:23:29 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Tue, 05 May 2009 04:23:29 +0000
Subject: hg: jdk7/tl/jaxp: 6588002: XSLTProcessorApplet still allows reading
	from forbidden URLs
Message-ID: <20090505042332.7AF62EED2@hg.openjdk.java.net>

Changeset: 3abf80631f99
Author:    tbell
Date:      2009-05-04 21:10 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/3abf80631f99

6588002: XSLTProcessorApplet still allows reading from forbidden URLs
Reviewed-by: darcy

- src/share/classes/com/sun/org/apache/xalan/internal/client/XSLTProcessorApplet.java
- src/share/classes/com/sun/org/apache/xalan/internal/client/package.html



From tim.bell at sun.com  Tue May  5 04:27:16 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Tue, 05 May 2009 04:27:16 +0000
Subject: hg: jdk7/tl/jaxws: 6658158: Mutable statics in SAAJ (findbugs); ...
Message-ID: <20090505042718.BA2E3EED7@hg.openjdk.java.net>

Changeset: 42dfec6871f6
Author:    tbell
Date:      2009-05-04 21:10 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/42dfec6871f6

6658158: Mutable statics in SAAJ (findbugs)
6658163: txw2.DatatypeWriter.BUILDIN is a mutable static (findbugs)
Reviewed-by: darcy

! src/share/classes/com/sun/codemodel/internal/JClassContainer.java
! src/share/classes/com/sun/codemodel/internal/JDefinedClass.java
! src/share/classes/com/sun/codemodel/internal/JForEach.java
! src/share/classes/com/sun/codemodel/internal/JMethod.java
! src/share/classes/com/sun/codemodel/internal/JMods.java
! src/share/classes/com/sun/codemodel/internal/util/SingleByteEncoder.java
! src/share/classes/com/sun/codemodel/internal/util/Surrogate.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/client/p2p/HttpSOAPConnection.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/AttachmentPartImpl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/EnvelopeFactory.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ImageDataContentHandler.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/MessageFactoryImpl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/MessageImpl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/SAAJMetaFactoryImpl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPDocumentImpl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPFactoryImpl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPPartImpl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/CDATAImpl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/CommentImpl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/ElementImpl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/TextImpl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/name/NameImpl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Fault1_1Impl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Header1_1Impl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/HeaderElement1_1Impl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Message1_1Impl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/SOAPPart1_1Impl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Body1_2Impl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Detail1_2Impl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Envelope1_2Impl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Fault1_2Impl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Header1_2Impl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/HeaderElement1_2Impl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/SOAPPart1_2Impl.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/util/RejectDoctypeSaxFilter.java
! src/share/classes/com/sun/xml/internal/messaging/saaj/util/transform/EfficientStreamingTransformer.java
! src/share/classes/com/sun/xml/internal/txw2/DatatypeWriter.java
! src/share/classes/com/sun/xml/internal/txw2/Document.java



From john.rose at sun.com  Tue May  5 04:09:14 2009
From: john.rose at sun.com (john.rose at sun.com)
Date: Tue, 05 May 2009 04:09:14 +0000
Subject: hg: jdk7/tl/langtools: 6829189: Java programming with JSR 292 needs
	language support
Message-ID: <20090505040919.0AC77EEAB@hg.openjdk.java.net>

Changeset: e2722bd43f3a
Author:    jrose
Date:      2009-05-04 21:04 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/e2722bd43f3a

6829189: Java programming with JSR 292 needs language support
Summary: Language changes documented in http://wikis.sun.com/display/mlvm/ProjectCoinProposal
Reviewed-by: jjg, darcy, mcimadamore

! src/share/classes/com/sun/tools/classfile/Opcode.java
! src/share/classes/com/sun/tools/javac/code/Symtab.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/jvm/ByteCodes.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/share/classes/com/sun/tools/javac/jvm/Code.java
! src/share/classes/com/sun/tools/javac/jvm/Gen.java
! src/share/classes/com/sun/tools/javac/jvm/Items.java
! src/share/classes/com/sun/tools/javac/jvm/Target.java
! src/share/classes/com/sun/tools/javac/main/Main.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/parser/Scanner.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/util/Names.java
! src/share/classes/com/sun/tools/javap/ConstantWriter.java
! src/share/classes/sun/tools/javap/JavapPrinter.java
! src/share/classes/sun/tools/javap/RuntimeConstants.java
+ test/tools/javac/meth/InvokeDyn.java
+ test/tools/javac/meth/InvokeMH.java
+ test/tools/javac/meth/MakeNegTests.sh
+ test/tools/javac/quid/MakeNegTests.sh
+ test/tools/javac/quid/QuotedIdent.java
+ test/tools/javac/quid/QuotedIdent2.java



From tim.bell at sun.com  Tue May  5 22:44:39 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Tue, 05 May 2009 22:44:39 +0000
Subject: hg: jdk7/tl: 6 new changesets
Message-ID: <20090505224440.2AB84EFEC@hg.openjdk.java.net>

Changeset: b02d566c15a7
Author:    xdono
Date:      2009-04-23 15:54 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/b02d566c15a7

Added tag jdk7-b56 for changeset ba12117a5e6c

! .hgtags

Changeset: e13a01c44efe
Author:    ohair
Date:      2009-04-27 20:15 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/e13a01c44efe

6831225: Upgrade JPRT jobs to use newer Linux 2.6 (e.g. Fedora 9)
Reviewed-by: tbell

- make/jprt.config
! make/jprt.properties

Changeset: caba6a812b19
Author:    peterz
Date:      2009-04-25 21:34 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/caba6a812b19

6591875: Nimbus Swing Look and Feel
Reviewed-by: jasper, ohair

! README-builds.html

Changeset: 8f5674f7087d
Author:    yan
Date:      2009-04-28 13:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/8f5674f7087d

Merge


Changeset: ffd09e767dfa
Author:    yan
Date:      2009-04-29 00:24 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/ffd09e767dfa

Merge


Changeset: 59b497130f82
Author:    xdono
Date:      2009-04-30 15:04 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/59b497130f82

Added tag jdk7-b57 for changeset ffd09e767dfa

! .hgtags



From tim.bell at sun.com  Tue May  5 22:48:48 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Tue, 05 May 2009 22:48:48 +0000
Subject: hg: jdk7/tl/corba: 5 new changesets
Message-ID: <20090505224852.E26CEEFFB@hg.openjdk.java.net>

Changeset: aa147fe5f386
Author:    xdono
Date:      2009-04-23 15:54 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/aa147fe5f386

Added tag jdk7-b56 for changeset 553a664b807b

! .hgtags

Changeset: 1c55bc99d36c
Author:    tbell
Date:      2009-04-23 21:29 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/1c55bc99d36c

Merge


Changeset: 972c6157fae5
Author:    ohair
Date:      2009-04-27 20:17 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/972c6157fae5

6831225: Upgrade JPRT jobs to use newer Linux 2.6 (e.g. Fedora 9)
Reviewed-by: tbell

- make/jprt.config
! make/jprt.properties

Changeset: 080ecdea3020
Author:    xdono
Date:      2009-04-30 15:04 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/080ecdea3020

Added tag jdk7-b57 for changeset 972c6157fae5

! .hgtags

Changeset: 2e3b8edab3ef
Author:    tbell
Date:      2009-05-04 22:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/2e3b8edab3ef

Merge




From tim.bell at sun.com  Tue May  5 22:55:11 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Tue, 05 May 2009 22:55:11 +0000
Subject: hg: jdk7/tl/hotspot: 38 new changesets
Message-ID: <20090505225624.94429F000@hg.openjdk.java.net>

Changeset: a63bc96715a9
Author:    trims
Date:      2009-04-08 14:55 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a63bc96715a9

6828076: Fork HS15 to HS16 - renumber Major and build numbers of JVM
Summary: Update the Hotspot version number to HS16 B01 for HS16 fork
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: b9fba36710f2
Author:    xlu
Date:      2009-04-06 15:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b9fba36710f2

6699669: Hotspot server leaves synchronized block with monitor in bad state
Summary: Remove usage of _highest_lock field in Thread so that is_lock_owned won't depend on the correct update of that field.
Reviewed-by: never, dice, acorn

! agent/src/share/classes/sun/jvm/hotspot/runtime/JavaThread.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/Thread.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/Threads.java
! src/share/vm/runtime/javaCalls.cpp
! src/share/vm/runtime/synchronizer.cpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/thread.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 68cd0d7ee9bb
Author:    xlu
Date:      2009-04-09 13:59 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/68cd0d7ee9bb

Merge


Changeset: ad8c635e757e
Author:    kvn
Date:      2009-04-03 13:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ad8c635e757e

6823453: DeoptimizeALot causes fastdebug server jvm to fail with assert(false,"unscheduable graph")
Summary: Use a HaltNode on the fall through path of the AllocateArrayNode to indicate that it is unreachable if the array length is negative.
Reviewed-by: never, jrose

! src/share/vm/opto/callnode.cpp
! src/share/vm/opto/callnode.hpp
+ test/compiler/6823453/Test.java

Changeset: 1f2abec69714
Author:    never
Date:      2009-04-03 18:51 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1f2abec69714

6826261: class file dumping from SA is broken
Reviewed-by: kvn, jcoomes

! agent/src/share/classes/sun/jvm/hotspot/runtime/ClassConstants.java
! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ByteCodeRewriter.java
! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassDump.java
! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java

Changeset: 819880572f09
Author:    never
Date:      2009-04-06 11:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/819880572f09

6539464: Math.log() produces inconsistent results between successive runs.
Reviewed-by: kvn

! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
+ test/compiler/6539464/Test.java

Changeset: 4ec1257180ec
Author:    kvn
Date:      2009-04-07 10:05 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4ec1257180ec

6826960: C2 Sparc: assert(bb->_nodes(_bb_end)->is_Proj(),"skipping projections after expected call")
Summary: Add the check when a Halt node is placed in a separate block.
Reviewed-by: twisti

! src/share/vm/opto/output.cpp

Changeset: f2049ae95c3d
Author:    kvn
Date:      2009-04-07 19:04 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f2049ae95c3d

6711117: Assertion in 64bit server vm (flat != TypePtr::BOTTOM,"cannot alias-analyze an untyped ptr")
Summary: Delay a memory node transformation if its control or address on IGVN worklist.
Reviewed-by: never

! src/share/vm/opto/macro.cpp
! src/share/vm/opto/memnode.cpp
+ test/compiler/6711117/Test.java

Changeset: 1d037ecd7960
Author:    jrose
Date:      2009-04-08 00:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1d037ecd7960

6827505: sizing logic for vtable and itable stubs needs self-check
Summary: Asserts and comments to help maintain the correct sizing of certain stubs
Reviewed-by: kvn

! src/cpu/sparc/vm/vtableStubs_sparc.cpp
! src/cpu/x86/vm/vtableStubs_x86_32.cpp
! src/cpu/x86/vm/vtableStubs_x86_64.cpp
! src/share/vm/code/vtableStubs.cpp

Changeset: e5b0439ef4ae
Author:    jrose
Date:      2009-04-08 10:56 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e5b0439ef4ae

6655638: dynamic languages need method handles
Summary: initial implementation, with known omissions (x86/64, sparc, compiler optim., c-oops, C++ interp.)
Reviewed-by: kvn, twisti, never

! src/cpu/sparc/vm/assembler_sparc.cpp
! src/cpu/sparc/vm/assembler_sparc.hpp
! src/cpu/sparc/vm/assembler_sparc.inline.hpp
! src/cpu/sparc/vm/cppInterpreter_sparc.cpp
! src/cpu/sparc/vm/interpreterGenerator_sparc.hpp
! src/cpu/sparc/vm/interpreter_sparc.cpp
+ src/cpu/sparc/vm/methodHandles_sparc.cpp
! src/cpu/sparc/vm/register_definitions_sparc.cpp
! src/cpu/sparc/vm/sharedRuntime_sparc.cpp
! src/cpu/sparc/vm/templateInterpreter_sparc.cpp
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/cppInterpreter_x86.cpp
! src/cpu/x86/vm/interp_masm_x86_32.cpp
! src/cpu/x86/vm/interp_masm_x86_32.hpp
! src/cpu/x86/vm/interp_masm_x86_64.cpp
! src/cpu/x86/vm/interp_masm_x86_64.hpp
! src/cpu/x86/vm/interpreterGenerator_x86.hpp
! src/cpu/x86/vm/interpreter_x86_32.cpp
! src/cpu/x86/vm/interpreter_x86_64.cpp
+ src/cpu/x86/vm/methodHandles_x86.cpp
! src/cpu/x86/vm/stubGenerator_x86_32.cpp
! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! src/share/vm/ci/ciMethod.cpp
! src/share/vm/ci/ciMethod.hpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/classFileParser.hpp
! src/share/vm/classfile/dictionary.cpp
! src/share/vm/classfile/dictionary.hpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/includeDB_core
! src/share/vm/includeDB_gc_parallel
! src/share/vm/interpreter/abstractInterpreter.hpp
! src/share/vm/interpreter/cppInterpreter.cpp
! src/share/vm/interpreter/interpreter.cpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/interpreter/interpreterRuntime.hpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/interpreter/linkResolver.hpp
! src/share/vm/interpreter/templateInterpreter.cpp
! src/share/vm/interpreter/templateInterpreter.hpp
! src/share/vm/interpreter/templateInterpreterGenerator.hpp
! src/share/vm/memory/dump.cpp
! src/share/vm/oops/methodKlass.cpp
! src/share/vm/oops/methodOop.cpp
! src/share/vm/oops/methodOop.hpp
! src/share/vm/oops/oop.hpp
! src/share/vm/oops/oop.inline.hpp
+ src/share/vm/prims/methodHandles.cpp
+ src/share/vm/prims/methodHandles.hpp
! src/share/vm/prims/nativeLookup.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/sharedRuntime.hpp
! src/share/vm/utilities/accessFlags.hpp
! src/share/vm/utilities/exceptions.hpp
! src/share/vm/utilities/globalDefinitions.hpp

Changeset: 9610b2a8ab4e
Author:    cfang
Date:      2009-04-10 15:01 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9610b2a8ab4e

6829021: tests for 6636138 use UseSuperword instead of UseSuperWord
Summary: Remove the wrong flag -XX:+UseSuperword to fix the Nightly failure
Reviewed-by: kvn, never

! test/compiler/6636138/Test1.java
! test/compiler/6636138/Test2.java

Changeset: 6e33bfd4139b
Author:    never
Date:      2009-04-14 12:25 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6e33bfd4139b

Merge

! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 4961a8a726a4
Author:    trims
Date:      2009-04-15 21:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4961a8a726a4

6830815: jprt.config not setting proper compiler version for use in 6u14
Summary: Add the 6u14 option to the jprt.config file in workspace
Reviewed-by: ohair

! make/jprt.config

Changeset: 981375ca07b7
Author:    never
Date:      2009-04-17 12:22 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/981375ca07b7

6831604: missing null check in guarantee
Reviewed-by: kvn

! src/share/vm/memory/dump.cpp

Changeset: a3fd9e40ff2e
Author:    trims
Date:      2009-04-21 15:08 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a3fd9e40ff2e

Merge


Changeset: bc47cdb8966c
Author:    xdono
Date:      2009-04-23 15:54 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/bc47cdb8966c

Added tag jdk7-b56 for changeset a3fd9e40ff2e

! .hgtags

Changeset: c8152ae3f339
Author:    coleenp
Date:      2009-04-21 16:12 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c8152ae3f339

6830069: UseLargePages is broken on Win64
Summary: Making VirtualAlloc/VirtualProtect two calls for PAGE_EXECUTE_READWRITE doesn't work for MEM_LARGE_PAGES.
Reviewed-by: xlu, kvn, jcoomes

! src/os/windows/vm/os_windows.cpp

Changeset: 670013185256
Author:    xlu
Date:      2009-04-22 11:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/670013185256

Merge


Changeset: a61730a6fdbc
Author:    trims
Date:      2009-04-22 19:30 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a61730a6fdbc

6833316: jprt.properties not setting values for 6u14 release flag
Summary: Fix jprt.properties to do 6u14 tests right
Reviewed-by: ohair

! make/jprt.properties

Changeset: 67a2f5ba5582
Author:    never
Date:      2009-04-15 09:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/67a2f5ba5582

6684007: PrintAssembly plugin not available for linux or windows
Reviewed-by: rasbold, jrose, twisti

! .hgignore
! make/windows/makefiles/vm.make
! src/share/tools/MakeDeps/BuildConfig.java
! src/share/tools/hsdis/Makefile
! src/share/tools/hsdis/README
! src/share/tools/hsdis/hsdis-demo.c
! src/share/tools/hsdis/hsdis.c

Changeset: 1b42d5772ae0
Author:    never
Date:      2009-04-16 10:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1b42d5772ae0

6449385: JCK test dup2_x200106m1 fails with Segmentation Fault on x86
Reviewed-by: kvn

! src/os_cpu/solaris_x86/vm/globals_solaris_x86.hpp

Changeset: a134d9824964
Author:    never
Date:      2009-04-16 15:50 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a134d9824964

6828024: verification of fixed interval usage is too weak
Reviewed-by: kvn

! src/share/vm/c1/c1_LinearScan.cpp
! src/share/vm/includeDB_compiler1

Changeset: 3ec1ff9307d6
Author:    never
Date:      2009-04-16 21:25 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3ec1ff9307d6

6741757: minor ctw improvements
Reviewed-by: kvn

! src/share/vm/classfile/classLoader.cpp

Changeset: 2bf529ef0adb
Author:    kvn
Date:      2009-04-17 09:38 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2bf529ef0adb

6831323: Use v8plus as minimum required hardware for current Hotspot sources
Summary: Use -xarch=v8plus as default for 32-bits VM on sparc.
Reviewed-by: never, twisti

! make/solaris/makefiles/sparcWorks.make

Changeset: 928912ce8438
Author:    never
Date:      2009-04-20 14:48 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/928912ce8438

Merge


Changeset: be93aad57795
Author:    jrose
Date:      2009-04-21 23:21 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/be93aad57795

6655646: dynamic languages need dynamically linked call sites
Summary: invokedynamic instruction (JSR 292 RI)
Reviewed-by: twisti, never

! src/cpu/sparc/vm/templateInterpreter_sparc.cpp
! src/cpu/sparc/vm/templateTable_sparc.cpp
! src/cpu/x86/vm/interp_masm_x86_32.cpp
! src/cpu/x86/vm/interp_masm_x86_32.hpp
! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! src/cpu/x86/vm/templateTable_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_32.hpp
! src/cpu/x86/vm/templateTable_x86_64.cpp
! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/ci/bcEscapeAnalyzer.cpp
! src/share/vm/ci/ciStreams.cpp
! src/share/vm/ci/ciStreams.hpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/classfile/verifier.cpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/includeDB_core
! src/share/vm/includeDB_gc_parallel
! src/share/vm/includeDB_jvmti
! src/share/vm/interpreter/abstractInterpreter.hpp
! src/share/vm/interpreter/bytecode.cpp
! src/share/vm/interpreter/bytecode.hpp
! src/share/vm/interpreter/bytecodeStream.hpp
! src/share/vm/interpreter/bytecodeTracer.cpp
! src/share/vm/interpreter/bytecodes.cpp
! src/share/vm/interpreter/bytecodes.hpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/interpreter/interpreterRuntime.hpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/interpreter/linkResolver.hpp
! src/share/vm/interpreter/rewriter.cpp
! src/share/vm/interpreter/rewriter.hpp
! src/share/vm/interpreter/templateInterpreter.cpp
! src/share/vm/interpreter/templateInterpreter.hpp
! src/share/vm/interpreter/templateInterpreterGenerator.hpp
! src/share/vm/interpreter/templateTable.cpp
! src/share/vm/interpreter/templateTable.hpp
! src/share/vm/oops/constantPoolKlass.cpp
! src/share/vm/oops/constantPoolOop.cpp
! src/share/vm/oops/constantPoolOop.hpp
! src/share/vm/oops/cpCacheKlass.cpp
! src/share/vm/oops/cpCacheOop.cpp
! src/share/vm/oops/cpCacheOop.hpp
! src/share/vm/oops/generateOopMap.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/instanceKlassKlass.cpp
! src/share/vm/oops/methodDataOop.cpp
! src/share/vm/oops/methodOop.cpp
! src/share/vm/oops/methodOop.hpp
! src/share/vm/opto/bytecodeInfo.cpp
! src/share/vm/opto/doCall.cpp
! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/parse1.cpp
! src/share/vm/opto/parse2.cpp
! src/share/vm/opto/parseHelper.cpp
! src/share/vm/prims/jvm.cpp
! src/share/vm/prims/jvmtiClassFileReconstituter.cpp
! src/share/vm/prims/methodComparator.cpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/utilities/globalDefinitions.hpp

Changeset: 6b2273dd6fa9
Author:    twisti
Date:      2009-04-21 11:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6b2273dd6fa9

6822110: Add AddressLiteral class on SPARC
Summary: The Address class on SPARC currently handles both, addresses and address literals, what makes the Address class more complicated than it has to be.
Reviewed-by: never, kvn

! src/cpu/sparc/vm/assembler_sparc.cpp
! src/cpu/sparc/vm/assembler_sparc.hpp
! src/cpu/sparc/vm/assembler_sparc.inline.hpp
! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp
! src/cpu/sparc/vm/c1_FrameMap_sparc.cpp
! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp
! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp
! src/cpu/sparc/vm/dump_sparc.cpp
! src/cpu/sparc/vm/icBuffer_sparc.cpp
! src/cpu/sparc/vm/interp_masm_sparc.cpp
! src/cpu/sparc/vm/interpreterRT_sparc.cpp
! src/cpu/sparc/vm/jniFastGetField_sparc.cpp
! src/cpu/sparc/vm/nativeInst_sparc.cpp
! src/cpu/sparc/vm/relocInfo_sparc.cpp
! src/cpu/sparc/vm/runtime_sparc.cpp
! src/cpu/sparc/vm/sharedRuntime_sparc.cpp
! src/cpu/sparc/vm/sparc.ad
! src/cpu/sparc/vm/stubGenerator_sparc.cpp
! src/cpu/sparc/vm/templateInterpreter_sparc.cpp
! src/cpu/sparc/vm/templateTable_sparc.cpp
! src/cpu/sparc/vm/vtableStubs_sparc.cpp

Changeset: 85656c8fa13f
Author:    twisti
Date:      2009-04-22 06:09 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/85656c8fa13f

Merge

! src/cpu/sparc/vm/templateInterpreter_sparc.cpp
! src/cpu/sparc/vm/templateTable_sparc.cpp

Changeset: 04fa5affa478
Author:    kvn
Date:      2009-04-22 17:03 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/04fa5affa478

6709742: find_base_for_derived's use of Ideal NULL is unsafe causing crashes during register allocation
Summary: Create a mach node corresponding to ideal node ConP #NULL specifically for derived pointers.
Reviewed-by: never

! src/share/vm/opto/buildOopMap.cpp
! src/share/vm/opto/chaitin.cpp
! src/share/vm/opto/matcher.cpp
! src/share/vm/opto/matcher.hpp

Changeset: 9c6be3edf0dc
Author:    cfang
Date:      2009-04-23 14:04 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9c6be3edf0dc

6589834: deoptimization problem with -XX:+DeoptimizeALot
Summary: Relocate the stack pointer adjustment to where uncommon_trap is actually inserted for new_array.
Reviewed-by: kvn, jrose

! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/graphKit.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/parse.hpp
! src/share/vm/opto/parse3.cpp
+ test/compiler/6589834/Test_ia32.java

Changeset: aa92a90b1cc6
Author:    cfang
Date:      2009-04-24 09:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/aa92a90b1cc6

6833951: Extra ":" Causes Testcase in CR 6589834 "Parse Exception: Invalid tag: summary:"
Summary: Remove the colon
Reviewed-by: never

! test/compiler/6589834/Test_ia32.java

Changeset: fb4c18a2ec66
Author:    never
Date:      2009-04-24 15:08 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/fb4c18a2ec66

6833573: C2 sparc: assert(c < 64 && (c & 1) == 0,"bad double float register")
Reviewed-by: twisti

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

Changeset: 6ffcd0923239
Author:    never
Date:      2009-04-24 18:45 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6ffcd0923239

Merge


Changeset: 3672e1dac765
Author:    kvn
Date:      2009-04-27 12:45 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3672e1dac765

6834142: method->print_codes(): Error: ShouldNotReachHere()
Summary: Restore the call to Bytecodes::java_code() in BytecodePrinter::print_attributes().
Reviewed-by: jrose

! src/share/vm/interpreter/bytecodeTracer.cpp

Changeset: 27e8e660fbd0
Author:    kvn
Date:      2009-04-27 12:55 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/27e8e660fbd0

Merge


Changeset: 451fd2abeda8
Author:    jcoomes
Date:      2009-04-29 13:22 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/451fd2abeda8

Merge


Changeset: f4cbf78110c7
Author:    jcoomes
Date:      2009-04-29 13:27 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f4cbf78110c7

6834202: Bump the HS16 build number to 02
Reviewed-by: jmasa

! make/hotspot_version

Changeset: 53d9bf689e80
Author:    xdono
Date:      2009-04-30 15:04 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/53d9bf689e80

Added tag jdk7-b57 for changeset f4cbf78110c7

! .hgtags



From tim.bell at sun.com  Tue May  5 23:02:33 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Tue, 05 May 2009 23:02:33 +0000
Subject: hg: jdk7/tl/jaxp: 5 new changesets
Message-ID: <20090505230241.D3249E005@hg.openjdk.java.net>

Changeset: de2086677f62
Author:    xdono
Date:      2009-04-23 15:54 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/de2086677f62

Added tag jdk7-b56 for changeset c197c6801271

! .hgtags

Changeset: 4f6b0a4d3768
Author:    tbell
Date:      2009-04-23 21:30 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/4f6b0a4d3768

Merge


Changeset: e4851e9f7be2
Author:    ohair
Date:      2009-04-27 20:18 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/e4851e9f7be2

6831225: Upgrade JPRT jobs to use newer Linux 2.6 (e.g. Fedora 9)
Reviewed-by: tbell

! make/jprt.properties

Changeset: fb846b3f9450
Author:    xdono
Date:      2009-04-30 15:04 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/fb846b3f9450

Added tag jdk7-b57 for changeset e4851e9f7be2

! .hgtags

Changeset: 13bf67d8c634
Author:    tbell
Date:      2009-05-04 22:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/13bf67d8c634

Merge

- src/share/classes/com/sun/org/apache/xalan/internal/client/XSLTProcessorApplet.java
- src/share/classes/com/sun/org/apache/xalan/internal/client/package.html



From tim.bell at sun.com  Tue May  5 23:06:40 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Tue, 05 May 2009 23:06:40 +0000
Subject: hg: jdk7/tl/jaxws: 5 new changesets
Message-ID: <20090505230647.A9192E00A@hg.openjdk.java.net>

Changeset: 75c6d6edb8b1
Author:    xdono
Date:      2009-04-23 15:54 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/75c6d6edb8b1

Added tag jdk7-b56 for changeset 0f7fbf85f7a1

! .hgtags

Changeset: fdb6df80707e
Author:    tbell
Date:      2009-04-23 21:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/fdb6df80707e

Merge

- src/share/classes/com/sun/tools/internal/txw2/AntErrorListener.java
- src/share/classes/com/sun/tools/internal/txw2/ConsoleErrorReporter.java
- src/share/classes/com/sun/tools/internal/txw2/ErrorListener.java
- src/share/classes/com/sun/tools/internal/txw2/Main.java
- src/share/classes/com/sun/tools/internal/txw2/NameUtil.java
- src/share/classes/com/sun/tools/internal/txw2/RELAXNGLoader.java
- src/share/classes/com/sun/tools/internal/txw2/SchemaBuilder.java
- src/share/classes/com/sun/tools/internal/txw2/TxwOptions.java
- src/share/classes/com/sun/tools/internal/txw2/TxwTask.java
- src/share/classes/com/sun/tools/internal/txw2/XmlSchemaLoader.java
- src/share/classes/com/sun/tools/internal/txw2/builder/relaxng/AnnotationsImpl.java
- src/share/classes/com/sun/tools/internal/txw2/builder/relaxng/CommentListImpl.java
- src/share/classes/com/sun/tools/internal/txw2/builder/relaxng/DataPatternBuilderImpl.java
- src/share/classes/com/sun/tools/internal/txw2/builder/relaxng/DatatypeFactory.java
- src/share/classes/com/sun/tools/internal/txw2/builder/relaxng/DivImpl.java
- src/share/classes/com/sun/tools/internal/txw2/builder/relaxng/ElementAnnotationBuilderImpl.java
- src/share/classes/com/sun/tools/internal/txw2/builder/relaxng/GrammarImpl.java
- src/share/classes/com/sun/tools/internal/txw2/builder/relaxng/GrammarSectionImpl.java
- src/share/classes/com/sun/tools/internal/txw2/builder/relaxng/SchemaBuilderImpl.java
- src/share/classes/com/sun/tools/internal/txw2/builder/relaxng/package.html
- src/share/classes/com/sun/tools/internal/txw2/builder/xsd/XmlSchemaBuilder.java
- src/share/classes/com/sun/tools/internal/txw2/builder/xsd/package.html
- src/share/classes/com/sun/tools/internal/txw2/model/Attribute.java
- src/share/classes/com/sun/tools/internal/txw2/model/CycleIterator.java
- src/share/classes/com/sun/tools/internal/txw2/model/Data.java
- src/share/classes/com/sun/tools/internal/txw2/model/Define.java
- src/share/classes/com/sun/tools/internal/txw2/model/Element.java
- src/share/classes/com/sun/tools/internal/txw2/model/Empty.java
- src/share/classes/com/sun/tools/internal/txw2/model/Grammar.java
- src/share/classes/com/sun/tools/internal/txw2/model/Leaf.java
- src/share/classes/com/sun/tools/internal/txw2/model/List.java
- src/share/classes/com/sun/tools/internal/txw2/model/Node.java
- src/share/classes/com/sun/tools/internal/txw2/model/NodeSet.java
- src/share/classes/com/sun/tools/internal/txw2/model/Ref.java
- src/share/classes/com/sun/tools/internal/txw2/model/Text.java
- src/share/classes/com/sun/tools/internal/txw2/model/Value.java
- src/share/classes/com/sun/tools/internal/txw2/model/WriterNode.java
- src/share/classes/com/sun/tools/internal/txw2/model/XmlNode.java
- src/share/classes/com/sun/tools/internal/txw2/model/prop/AttributeProp.java
- src/share/classes/com/sun/tools/internal/txw2/model/prop/ElementProp.java
- src/share/classes/com/sun/tools/internal/txw2/model/prop/LeafElementProp.java
- src/share/classes/com/sun/tools/internal/txw2/model/prop/Prop.java
- src/share/classes/com/sun/tools/internal/txw2/model/prop/ValueProp.java
- src/share/classes/com/sun/tools/internal/txw2/model/prop/XmlItemProp.java
- src/share/classes/com/sun/tools/internal/ws/processor/Processor.java
- src/share/classes/com/sun/tools/internal/ws/processor/ProcessorAction.java
- src/share/classes/com/sun/tools/internal/ws/processor/ProcessorActionVersion.java
- src/share/classes/com/sun/tools/internal/ws/processor/ProcessorConstants.java
- src/share/classes/com/sun/tools/internal/ws/processor/ProcessorNotificationListener.java
- src/share/classes/com/sun/tools/internal/ws/processor/ProcessorOptions.java
- src/share/classes/com/sun/tools/internal/ws/processor/config/ClassModelInfo.java
- src/share/classes/com/sun/tools/internal/ws/processor/config/Configuration.java
- src/share/classes/com/sun/tools/internal/ws/processor/config/ConfigurationException.java
- src/share/classes/com/sun/tools/internal/ws/processor/config/HandlerChainInfo.java
- src/share/classes/com/sun/tools/internal/ws/processor/config/HandlerInfo.java
- src/share/classes/com/sun/tools/internal/ws/processor/config/ModelInfo.java
- src/share/classes/com/sun/tools/internal/ws/processor/config/WSDLModelInfo.java
- src/share/classes/com/sun/tools/internal/ws/processor/config/parser/ClassModelParser.java
- src/share/classes/com/sun/tools/internal/ws/processor/config/parser/CustomizationParser.java
- src/share/classes/com/sun/tools/internal/ws/processor/config/parser/InputParser.java
- src/share/classes/com/sun/tools/internal/ws/processor/config/parser/JAXWSBindingInfoParser.java
- src/share/classes/com/sun/tools/internal/ws/processor/config/parser/ParserUtil.java
- src/share/classes/com/sun/tools/internal/ws/processor/config/parser/Reader.java
- src/share/classes/com/sun/tools/internal/ws/processor/generator/JAXBTypeGenerator.java
- src/share/classes/com/sun/tools/internal/ws/processor/generator/SimpleToBoxedUtil.java
- src/share/classes/com/sun/tools/internal/ws/processor/modeler/ModelerUtils.java
- src/share/classes/com/sun/tools/internal/ws/processor/modeler/annotation/WebServiceReferenceCollector.java
- src/share/classes/com/sun/tools/internal/ws/processor/util/ClientProcessorEnvironment.java
- src/share/classes/com/sun/tools/internal/ws/processor/util/GeneratedFileInfo.java
- src/share/classes/com/sun/tools/internal/ws/processor/util/ProcessorEnvironment.java
- src/share/classes/com/sun/tools/internal/ws/processor/util/ProcessorEnvironmentBase.java
- src/share/classes/com/sun/tools/internal/ws/util/JAXWSClassFactory.java
- src/share/classes/com/sun/tools/internal/ws/util/JavaCompilerHelper.java
- src/share/classes/com/sun/tools/internal/ws/util/MapBase.java
- src/share/classes/com/sun/tools/internal/ws/util/ToolBase.java
- src/share/classes/com/sun/tools/internal/ws/util/xml/NodeListIterator.java
- src/share/classes/com/sun/tools/internal/ws/util/xml/NullEntityResolver.java
- src/share/classes/com/sun/tools/internal/ws/util/xml/PrettyPrintingXmlWriter.java
- src/share/classes/com/sun/tools/internal/ws/util/xml/XmlWriter.java
- src/share/classes/com/sun/tools/internal/ws/wscompile/ActionConstants.java
- src/share/classes/com/sun/tools/internal/ws/wscompile/CompileTool.java
- src/share/classes/com/sun/tools/internal/ws/wsdl/document/schema/BuiltInTypes.java
- src/share/classes/com/sun/tools/internal/ws/wsdl/document/schema/Schema.java
- src/share/classes/com/sun/tools/internal/ws/wsdl/document/schema/SchemaAttribute.java
- src/share/classes/com/sun/tools/internal/ws/wsdl/document/schema/SchemaDocument.java
- src/share/classes/com/sun/tools/internal/ws/wsdl/document/schema/SchemaElement.java
- src/share/classes/com/sun/tools/internal/ws/wsdl/document/schema/SchemaEntity.java
- src/share/classes/com/sun/tools/internal/ws/wsdl/framework/Extensible.java
- src/share/classes/com/sun/tools/internal/ws/wsdl/framework/Extension.java
- src/share/classes/com/sun/tools/internal/ws/wsdl/framework/ParserContext.java
- src/share/classes/com/sun/tools/internal/ws/wsdl/framework/WriterContext.java
- src/share/classes/com/sun/tools/internal/ws/wsdl/parser/ExtensionHandler.java
- src/share/classes/com/sun/tools/internal/ws/wsdl/parser/ExtensionHandlerBase.java
- src/share/classes/com/sun/tools/internal/ws/wsdl/parser/SchemaExtensionHandler.java
- src/share/classes/com/sun/tools/internal/ws/wsdl/parser/SchemaParser.java
- src/share/classes/com/sun/tools/internal/ws/wsdl/parser/SchemaWriter.java
- src/share/classes/com/sun/tools/internal/ws/wsdl/parser/WSDLWriter.java
- src/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/DOM4JLocator.java
- src/share/classes/com/sun/tools/internal/xjc/util/XMLStreamReaderToContentHandler.java
- src/share/classes/com/sun/xml/internal/bind/v2/doc-files/packages.png
- src/share/classes/com/sun/xml/internal/bind/v2/doc-files/packages.vsd
- src/share/classes/com/sun/xml/internal/bind/v2/doc-files/readme.txt
- src/share/classes/com/sun/xml/internal/ws/binding/http/HTTPBindingImpl.java
- src/share/classes/com/sun/xml/internal/ws/binding/soap/SOAPBindingImpl.java
- src/share/classes/com/sun/xml/internal/ws/client/AsyncHandlerService.java
- src/share/classes/com/sun/xml/internal/ws/client/ClientConfigurationException.java
- src/share/classes/com/sun/xml/internal/ws/client/ContactInfoBase.java
- src/share/classes/com/sun/xml/internal/ws/client/ContactInfoListImpl.java
- src/share/classes/com/sun/xml/internal/ws/client/ContactInfoListIteratorBase.java
- src/share/classes/com/sun/xml/internal/ws/client/ContextMap.java
- src/share/classes/com/sun/xml/internal/ws/client/EndpointIFBase.java
- src/share/classes/com/sun/xml/internal/ws/client/EndpointIFContext.java
- src/share/classes/com/sun/xml/internal/ws/client/EndpointIFInvocationHandler.java
- src/share/classes/com/sun/xml/internal/ws/client/InternalBindingProvider.java
- src/share/classes/com/sun/xml/internal/ws/client/PortInfoBase.java
- src/share/classes/com/sun/xml/internal/ws/client/ServiceContext.java
- src/share/classes/com/sun/xml/internal/ws/client/ServiceContextBuilder.java
- src/share/classes/com/sun/xml/internal/ws/client/WSFuture.java
- src/share/classes/com/sun/xml/internal/ws/client/dispatch/DispatchBase.java
- src/share/classes/com/sun/xml/internal/ws/client/dispatch/DispatchContext.java
- src/share/classes/com/sun/xml/internal/ws/client/dispatch/ResponseImpl.java
- src/share/classes/com/sun/xml/internal/ws/client/dispatch/impl/DispatchContactInfoList.java
- src/share/classes/com/sun/xml/internal/ws/client/dispatch/impl/DispatchDelegate.java
- src/share/classes/com/sun/xml/internal/ws/client/dispatch/impl/encoding/DispatchSerializer.java
- src/share/classes/com/sun/xml/internal/ws/client/dispatch/impl/encoding/DispatchUtil.java
- src/share/classes/com/sun/xml/internal/ws/client/dispatch/impl/protocol/MessageDispatcherHelper.java
- src/share/classes/com/sun/xml/internal/ws/encoding/EncoderDecoderBase.java
- src/share/classes/com/sun/xml/internal/ws/encoding/JAXWSAttachmentMarshaller.java
- src/share/classes/com/sun/xml/internal/ws/encoding/JAXWSAttachmentUnmarshaller.java
- src/share/classes/com/sun/xml/internal/ws/encoding/internal/InternalEncoder.java
- src/share/classes/com/sun/xml/internal/ws/encoding/jaxb/JAXBBeanInfo.java
- src/share/classes/com/sun/xml/internal/ws/encoding/jaxb/JAXBBridgeInfo.java
- src/share/classes/com/sun/xml/internal/ws/encoding/jaxb/JAXBTypeSerializer.java
- src/share/classes/com/sun/xml/internal/ws/encoding/jaxb/RpcLitPayload.java
- src/share/classes/com/sun/xml/internal/ws/encoding/jaxb/RpcLitPayloadSerializer.java
- src/share/classes/com/sun/xml/internal/ws/encoding/simpletype/EncoderUtils.java
- src/share/classes/com/sun/xml/internal/ws/encoding/simpletype/SimpleTypeConstants.java
- src/share/classes/com/sun/xml/internal/ws/encoding/soap/ClientEncoderDecoder.java
- src/share/classes/com/sun/xml/internal/ws/encoding/soap/EncoderDecoder.java
- src/share/classes/com/sun/xml/internal/ws/encoding/soap/SOAPDecoder.java
- src/share/classes/com/sun/xml/internal/ws/encoding/soap/SOAPEPTFactory.java
- src/share/classes/com/sun/xml/internal/ws/encoding/soap/SOAPEncoder.java
- src/share/classes/com/sun/xml/internal/ws/encoding/soap/SOAPVersion.java
- src/share/classes/com/sun/xml/internal/ws/encoding/soap/ServerEncoderDecoder.java
- src/share/classes/com/sun/xml/internal/ws/encoding/soap/client/SOAP12XMLDecoder.java
- src/share/classes/com/sun/xml/internal/ws/encoding/soap/client/SOAP12XMLEncoder.java
- src/share/classes/com/sun/xml/internal/ws/encoding/soap/client/SOAPXMLDecoder.java
- src/share/classes/com/sun/xml/internal/ws/encoding/soap/client/SOAPXMLEncoder.java
- src/share/classes/com/sun/xml/internal/ws/encoding/soap/internal/AttachmentBlock.java
- src/share/classes/com/sun/xml/internal/ws/encoding/soap/internal/BodyBlock.java
- src/share/classes/com/sun/xml/internal/ws/encoding/soap/internal/DelegateBase.java
- src/share/classes/com/sun/xml/internal/ws/encoding/soap/internal/HeaderBlock.java
- src/share/classes/com/sun/xml/internal/ws/encoding/soap/internal/InternalMessage.java
- src/share/classes/com/sun/xml/internal/ws/encoding/soap/internal/MessageBlock.java
- src/share/classes/com/sun/xml/internal/ws/encoding/soap/internal/MessageInfoBase.java
- src/share/classes/com/sun/xml/internal/ws/encoding/soap/internal/SOAP12NotUnderstoodHeaderBlock.java
- src/share/classes/com/sun/xml/internal/ws/encoding/soap/message/FaultCode.java
- src/share/classes/com/sun/xml/internal/ws/encoding/soap/message/FaultCodeEnum.java
- src/share/classes/com/sun/xml/internal/ws/encoding/soap/message/FaultReason.java
- src/share/classes/com/sun/xml/internal/ws/encoding/soap/message/FaultReasonText.java
- src/share/classes/com/sun/xml/internal/ws/encoding/soap/message/FaultSubcode.java
- src/share/classes/com/sun/xml/internal/ws/encoding/soap/message/SOAP12FaultInfo.java
- src/share/classes/com/sun/xml/internal/ws/encoding/soap/message/SOAPFaultInfo.java
- src/share/classes/com/sun/xml/internal/ws/encoding/soap/message/SOAPMsgCreateException.java
- src/share/classes/com/sun/xml/internal/ws/encoding/soap/message/SOAPMsgFactoryCreateException.java
- src/share/classes/com/sun/xml/internal/ws/encoding/soap/server/ProviderSED.java
- src/share/classes/com/sun/xml/internal/ws/encoding/soap/server/SOAP12XMLDecoder.java
- src/share/classes/com/sun/xml/internal/ws/encoding/soap/server/SOAP12XMLEncoder.java
- src/share/classes/com/sun/xml/internal/ws/encoding/soap/server/SOAPXMLDecoder.java
- src/share/classes/com/sun/xml/internal/ws/encoding/soap/server/SOAPXMLEncoder.java
- src/share/classes/com/sun/xml/internal/ws/encoding/xml/XMLDecoder.java
- src/share/classes/com/sun/xml/internal/ws/encoding/xml/XMLEPTFactory.java
- src/share/classes/com/sun/xml/internal/ws/encoding/xml/XMLEncoder.java
- src/share/classes/com/sun/xml/internal/ws/handler/HandlerChainCaller.java
- src/share/classes/com/sun/xml/internal/ws/handler/HandlerContext.java
- src/share/classes/com/sun/xml/internal/ws/handler/HandlerResolverImpl.java
- src/share/classes/com/sun/xml/internal/ws/handler/MessageContextUtil.java
- src/share/classes/com/sun/xml/internal/ws/handler/SHDSOAPMessageContext.java
- src/share/classes/com/sun/xml/internal/ws/handler/SOAPHandlerContext.java
- src/share/classes/com/sun/xml/internal/ws/handler/XMLHandlerContext.java
- src/share/classes/com/sun/xml/internal/ws/handler/XMLLogicalMessageContextImpl.java
- src/share/classes/com/sun/xml/internal/ws/handler/XMLLogicalMessageImpl.java
- src/share/classes/com/sun/xml/internal/ws/handler/package-info.java
- src/share/classes/com/sun/xml/internal/ws/model/CheckedException.java
- src/share/classes/com/sun/xml/internal/ws/model/ExceptionType.java
- src/share/classes/com/sun/xml/internal/ws/model/JavaMethod.java
- src/share/classes/com/sun/xml/internal/ws/model/Mode.java
- src/share/classes/com/sun/xml/internal/ws/model/Parameter.java
- src/share/classes/com/sun/xml/internal/ws/model/ParameterBinding.java
- src/share/classes/com/sun/xml/internal/ws/model/RuntimeModel.java
- src/share/classes/com/sun/xml/internal/ws/model/soap/SOAPBinding.java
- src/share/classes/com/sun/xml/internal/ws/model/soap/SOAPRuntimeModel.java
- src/share/classes/com/sun/xml/internal/ws/model/soap/Style.java
- src/share/classes/com/sun/xml/internal/ws/model/soap/Use.java
- src/share/classes/com/sun/xml/internal/ws/modeler/RuntimeModeler.java
- src/share/classes/com/sun/xml/internal/ws/modeler/RuntimeModelerException.java
- src/share/classes/com/sun/xml/internal/ws/pept/Delegate.java
- src/share/classes/com/sun/xml/internal/ws/pept/encoding/Decoder.java
- src/share/classes/com/sun/xml/internal/ws/pept/encoding/Encoder.java
- src/share/classes/com/sun/xml/internal/ws/pept/ept/Acceptor.java
- src/share/classes/com/sun/xml/internal/ws/pept/ept/ContactInfo.java
- src/share/classes/com/sun/xml/internal/ws/pept/ept/ContactInfoList.java
- src/share/classes/com/sun/xml/internal/ws/pept/ept/ContactInfoListIterator.java
- src/share/classes/com/sun/xml/internal/ws/pept/ept/EPTFactory.java
- src/share/classes/com/sun/xml/internal/ws/pept/ept/MessageInfo.java
- src/share/classes/com/sun/xml/internal/ws/pept/presentation/MessageStruct.java
- src/share/classes/com/sun/xml/internal/ws/pept/presentation/Stub.java
- src/share/classes/com/sun/xml/internal/ws/pept/presentation/TargetFinder.java
- src/share/classes/com/sun/xml/internal/ws/pept/presentation/Tie.java
- src/share/classes/com/sun/xml/internal/ws/pept/protocol/Interceptors.java
- src/share/classes/com/sun/xml/internal/ws/pept/protocol/MessageDispatcher.java
- src/share/classes/com/sun/xml/internal/ws/protocol/soap/client/SOAPMessageDispatcher.java
- src/share/classes/com/sun/xml/internal/ws/protocol/soap/server/ProviderSOAPMD.java
- src/share/classes/com/sun/xml/internal/ws/protocol/soap/server/SOAPMessageDispatcher.java
- src/share/classes/com/sun/xml/internal/ws/protocol/xml/client/XMLMessageDispatcher.java
- src/share/classes/com/sun/xml/internal/ws/protocol/xml/server/ProviderXMLMD.java
- src/share/classes/com/sun/xml/internal/ws/protocol/xml/server/XMLMessageDispatcher.java
- src/share/classes/com/sun/xml/internal/ws/server/AppMsgContextImpl.java
- src/share/classes/com/sun/xml/internal/ws/server/DocInfo.java
- src/share/classes/com/sun/xml/internal/ws/server/EPTFactoryBase.java
- src/share/classes/com/sun/xml/internal/ws/server/EPTFactoryFactoryBase.java
- src/share/classes/com/sun/xml/internal/ws/server/PeptTie.java
- src/share/classes/com/sun/xml/internal/ws/server/RuntimeContext.java
- src/share/classes/com/sun/xml/internal/ws/server/RuntimeEndpointInfo.java
- src/share/classes/com/sun/xml/internal/ws/server/TargetFinderImpl.java
- src/share/classes/com/sun/xml/internal/ws/server/Tie.java
- src/share/classes/com/sun/xml/internal/ws/server/XMLEPTFactoryImpl.java
- src/share/classes/com/sun/xml/internal/ws/server/provider/ProviderModel.java
- src/share/classes/com/sun/xml/internal/ws/server/provider/ProviderPeptTie.java
- src/share/classes/com/sun/xml/internal/ws/spi/runtime/Binding.java
- src/share/classes/com/sun/xml/internal/ws/spi/runtime/ClientTransportFactory.java
- src/share/classes/com/sun/xml/internal/ws/spi/runtime/ClientTransportFactoryTypes.java
- src/share/classes/com/sun/xml/internal/ws/spi/runtime/InternalSoapEncoder.java
- src/share/classes/com/sun/xml/internal/ws/spi/runtime/Invoker.java
- src/share/classes/com/sun/xml/internal/ws/spi/runtime/MessageContext.java
- src/share/classes/com/sun/xml/internal/ws/spi/runtime/MtomCallback.java
- src/share/classes/com/sun/xml/internal/ws/spi/runtime/RuntimeEndpointInfo.java
- src/share/classes/com/sun/xml/internal/ws/spi/runtime/SOAPMessageContext.java
- src/share/classes/com/sun/xml/internal/ws/spi/runtime/StubBase.java
- src/share/classes/com/sun/xml/internal/ws/spi/runtime/SystemHandlerDelegate.java
- src/share/classes/com/sun/xml/internal/ws/spi/runtime/SystemHandlerDelegateFactory.java
- src/share/classes/com/sun/xml/internal/ws/spi/runtime/Tie.java
- src/share/classes/com/sun/xml/internal/ws/spi/runtime/WSConnection.java
- src/share/classes/com/sun/xml/internal/ws/spi/runtime/WebServiceContext.java
- src/share/classes/com/sun/xml/internal/ws/spi/runtime/package-info.java
- src/share/classes/com/sun/xml/internal/ws/streaming/XMLStreamReaderFactory.java
- src/share/classes/com/sun/xml/internal/ws/streaming/XMLStreamWriterFactory.java
- src/share/classes/com/sun/xml/internal/ws/transport/WSConnectionImpl.java
- src/share/classes/com/sun/xml/internal/ws/transport/http/client/HttpClientTransportFactory.java
- src/share/classes/com/sun/xml/internal/ws/transport/http/server/EndpointDocInfo.java
- src/share/classes/com/sun/xml/internal/ws/transport/http/server/EndpointEntityResolver.java
- src/share/classes/com/sun/xml/internal/ws/transport/http/server/WebServiceContextImpl.java
- src/share/classes/com/sun/xml/internal/ws/transport/local/LocalMessage.java
- src/share/classes/com/sun/xml/internal/ws/transport/local/client/LocalClientTransport.java
- src/share/classes/com/sun/xml/internal/ws/transport/local/client/LocalClientTransportFactory.java
- src/share/classes/com/sun/xml/internal/ws/transport/local/server/LocalConnectionImpl.java
- src/share/classes/com/sun/xml/internal/ws/transport/local/server/LocalWSContextImpl.java
- src/share/classes/com/sun/xml/internal/ws/util/Base64Util.java
- src/share/classes/com/sun/xml/internal/ws/util/MessageInfoUtil.java
- src/share/classes/com/sun/xml/internal/ws/util/NullIterator.java
- src/share/classes/com/sun/xml/internal/ws/util/SOAPConnectionUtil.java
- src/share/classes/com/sun/xml/internal/ws/util/SOAPUtil.java
- src/share/classes/com/sun/xml/internal/ws/util/SunStAXReflection.java
- src/share/classes/com/sun/xml/internal/ws/util/XMLConnectionUtil.java
- src/share/classes/com/sun/xml/internal/ws/util/xml/XMLStreamReaderToContentHandler.java
- src/share/classes/com/sun/xml/internal/ws/wsdl/WSDLContext.java
- src/share/classes/com/sun/xml/internal/ws/wsdl/parser/Binding.java
- src/share/classes/com/sun/xml/internal/ws/wsdl/parser/BindingOperation.java
- src/share/classes/com/sun/xml/internal/ws/wsdl/parser/Message.java
- src/share/classes/com/sun/xml/internal/ws/wsdl/parser/Part.java
- src/share/classes/com/sun/xml/internal/ws/wsdl/parser/Port.java
- src/share/classes/com/sun/xml/internal/ws/wsdl/parser/PortType.java
- src/share/classes/com/sun/xml/internal/ws/wsdl/parser/PortTypeOperation.java
- src/share/classes/com/sun/xml/internal/ws/wsdl/parser/Service.java
- src/share/classes/com/sun/xml/internal/ws/wsdl/parser/WSDLDocument.java
- src/share/classes/com/sun/xml/internal/ws/wsdl/writer/WSDLOutputResolver.java
- src/share/classes/com/sun/xml/internal/xsom/impl/util/ConcatIterator.java
- src/share/classes/com/sun/xml/internal/xsom/impl/util/FilterIterator.java

Changeset: 68257a5eb19a
Author:    ohair
Date:      2009-04-27 20:18 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/68257a5eb19a

6831225: Upgrade JPRT jobs to use newer Linux 2.6 (e.g. Fedora 9)
Reviewed-by: tbell

! make/jprt.properties

Changeset: c2d622fe401b
Author:    xdono
Date:      2009-04-30 15:04 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/c2d622fe401b

Added tag jdk7-b57 for changeset 68257a5eb19a

! .hgtags

Changeset: 5fb4fbea81c3
Author:    tbell
Date:      2009-05-04 22:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/5fb4fbea81c3

Merge




From tim.bell at sun.com  Tue May  5 23:13:02 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Tue, 05 May 2009 23:13:02 +0000
Subject: hg: jdk7/tl/jdk: 33 new changesets
Message-ID: <20090505231958.7146EE00F@hg.openjdk.java.net>

Changeset: ffc29fac1330
Author:    chegar
Date:      2009-04-16 17:42 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ffc29fac1330

4927640: Implementation of the sctp protocol
Summary: An implementation-specific API for the Stream Control Transmission Protocol
Reviewed-by: alanb, michaelm, jccollet

! make/com/sun/Makefile
+ make/com/sun/nio/Makefile
+ make/com/sun/nio/sctp/Exportedfiles.gmk
+ make/com/sun/nio/sctp/FILES_c.gmk
+ make/com/sun/nio/sctp/FILES_java.gmk
+ make/com/sun/nio/sctp/Makefile
+ make/com/sun/nio/sctp/mapfile-vers
! make/docs/NON_CORE_PKGS.gmk
! make/java/nio/mapfile-linux
! make/java/nio/mapfile-solaris
+ src/share/classes/com/sun/nio/sctp/AbstractNotificationHandler.java
+ src/share/classes/com/sun/nio/sctp/Association.java
+ src/share/classes/com/sun/nio/sctp/AssociationChangeNotification.java
+ src/share/classes/com/sun/nio/sctp/HandlerResult.java
+ src/share/classes/com/sun/nio/sctp/IllegalReceiveException.java
+ src/share/classes/com/sun/nio/sctp/IllegalUnbindException.java
+ src/share/classes/com/sun/nio/sctp/InvalidStreamException.java
+ src/share/classes/com/sun/nio/sctp/MessageInfo.java
+ src/share/classes/com/sun/nio/sctp/Notification.java
+ src/share/classes/com/sun/nio/sctp/NotificationHandler.java
+ src/share/classes/com/sun/nio/sctp/PeerAddressChangeNotification.java
+ src/share/classes/com/sun/nio/sctp/SctpChannel.java
+ src/share/classes/com/sun/nio/sctp/SctpMultiChannel.java
+ src/share/classes/com/sun/nio/sctp/SctpServerChannel.java
+ src/share/classes/com/sun/nio/sctp/SctpSocketOption.java
+ src/share/classes/com/sun/nio/sctp/SctpStandardSocketOption.java
+ src/share/classes/com/sun/nio/sctp/SendFailedNotification.java
+ src/share/classes/com/sun/nio/sctp/ShutdownNotification.java
+ src/share/classes/com/sun/nio/sctp/package-info.java
+ src/share/classes/sun/nio/ch/SctpMessageInfoImpl.java
+ src/share/classes/sun/nio/ch/SctpStdSocketOption.java
+ src/solaris/classes/sun/nio/ch/SctpAssocChange.java
+ src/solaris/classes/sun/nio/ch/SctpAssociationImpl.java
+ src/solaris/classes/sun/nio/ch/SctpChannelImpl.java
+ src/solaris/classes/sun/nio/ch/SctpMultiChannelImpl.java
+ src/solaris/classes/sun/nio/ch/SctpNet.java
+ src/solaris/classes/sun/nio/ch/SctpNotification.java
+ src/solaris/classes/sun/nio/ch/SctpPeerAddrChange.java
+ src/solaris/classes/sun/nio/ch/SctpResultContainer.java
+ src/solaris/classes/sun/nio/ch/SctpSendFailed.java
+ src/solaris/classes/sun/nio/ch/SctpServerChannelImpl.java
+ src/solaris/classes/sun/nio/ch/SctpShutdown.java
+ src/solaris/classes/sun/nio/ch/SctpSocketDispatcher.java
+ src/solaris/native/sun/nio/ch/Sctp.h
+ src/solaris/native/sun/nio/ch/SctpChannelImpl.c
+ src/solaris/native/sun/nio/ch/SctpNet.c
+ src/solaris/native/sun/nio/ch/SctpServerChannelImpl.c
+ src/windows/classes/sun/nio/ch/SctpChannelImpl.java
+ src/windows/classes/sun/nio/ch/SctpMultiChannelImpl.java
+ src/windows/classes/sun/nio/ch/SctpServerChannelImpl.java
+ test/com/sun/nio/sctp/MessageInfoTests.java
+ test/com/sun/nio/sctp/SctpChannel/Bind.java
+ test/com/sun/nio/sctp/SctpChannel/Connect.java
+ test/com/sun/nio/sctp/SctpChannel/Receive.java
+ test/com/sun/nio/sctp/SctpChannel/Send.java
+ test/com/sun/nio/sctp/SctpChannel/Shutdown.java
+ test/com/sun/nio/sctp/SctpChannel/SocketOptionTests.java
+ test/com/sun/nio/sctp/SctpChannel/Util.java
+ test/com/sun/nio/sctp/SctpMultiChannel/Send.java
+ test/com/sun/nio/sctp/SctpMultiChannel/Util.java
+ test/com/sun/nio/sctp/SctpServerChannel/Accept.java
+ test/com/sun/nio/sctp/SctpServerChannel/NonBlockingAccept.java
+ test/com/sun/nio/sctp/SctpServerChannel/Util.java

Changeset: 7fd3bc37afe3
Author:    xdono
Date:      2009-04-16 19:10 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7fd3bc37afe3

Merge

- src/share/classes/sun/text/normalizer/UProperty.java
- src/windows/native/sun/windows/awt_KeyboardFocusManager.h

Changeset: 38e1121342d8
Author:    xdono
Date:      2009-04-23 15:55 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/38e1121342d8

Added tag jdk7-b56 for changeset 7fd3bc37afe3

! .hgtags

Changeset: ea611a547fbf
Author:    tbell
Date:      2009-04-21 21:26 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ea611a547fbf

Merge

- src/share/native/java/util/zip/ZipEntry.c

Changeset: 7859c68fed2b
Author:    tbell
Date:      2009-04-23 21:32 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7859c68fed2b

Merge


Changeset: 31a9fa5a8e6b
Author:    ohair
Date:      2009-04-27 20:26 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/31a9fa5a8e6b

6831225: Upgrade JPRT jobs to use newer Linux 2.6 (e.g. Fedora 9)
Reviewed-by: tbell

! make/jprt.properties

Changeset: 45dfc3aeee8f
Author:    ohair
Date:      2009-04-28 14:43 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/45dfc3aeee8f

6835241: Annotate some tests with @ignore that have shown to be unpredictable
Reviewed-by: tbell

! test/java/lang/Class/getEnclosingConstructor/EnclosingConstructorTests.java
! test/java/lang/instrument/ParallelTransformerLoader.sh
! test/java/lang/management/ThreadMXBean/ThreadStateTest.java
! test/java/security/Security/ClassLoaderDeadlock/Deadlock2.sh
! test/java/util/logging/LoggingDeadlock2.java

Changeset: 8dd1c3eb1288
Author:    denis
Date:      2009-04-13 21:42 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8dd1c3eb1288

6590857: Drag & Drop arbitrary file copy
Reviewed-by: uta

! src/share/classes/sun/awt/datatransfer/DataTransferer.java

Changeset: 98ddbb3840a4
Author:    anthony
Date:      2009-04-14 14:17 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/98ddbb3840a4

6825342: Security warning may change Z-order of top-level
Summary: Added the SWP_NOOWNERZORDER flag when calling ::SetWindowPos()
Reviewed-by: art, dcherepanov

! src/windows/native/sun/windows/awt_Window.cpp

Changeset: 6f4446ca5499
Author:    yan
Date:      2009-04-16 23:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6f4446ca5499

Merge

- make/common/shared/Compiler.gmk
- make/jprt.config
- src/share/classes/sun/misc/JavaIODeleteOnExitAccess.java
- src/share/classes/sun/text/normalizer/UProperty.java
- src/solaris/classes/sun/nio/ch/FileDispatcher.java
- src/solaris/native/sun/nio/ch/FileDispatcher.c
- src/windows/classes/sun/awt/windows/fontconfig.98.properties
- src/windows/classes/sun/awt/windows/fontconfig.Me.properties
- src/windows/classes/sun/nio/ch/FileDispatcher.java
- src/windows/native/sun/nio/ch/FileDispatcher.c

Changeset: c6503f2a93d1
Author:    anthony
Date:      2009-04-17 16:16 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c6503f2a93d1

6826104: Getting a NullPointer exception when clicked on Application & Toolkit Modal dialog
Summary: The addition of window peers to the windows collection has been restored in XWindowPeer.
Reviewed-by: art, dcherepanov

! src/solaris/classes/sun/awt/X11/XWindowPeer.java

Changeset: 9124b0123df3
Author:    anthony
Date:      2009-04-17 16:30 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9124b0123df3

6821948: Consider removing the constraints for bounds of untrusted top-level windows
Summary: The constrainBounds() methods are removed.
Reviewed-by: art, dcherepanov

! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java
! src/solaris/classes/sun/awt/X11/XEmbeddedFramePeer.java
! src/solaris/classes/sun/awt/X11/XWindow.java
! src/solaris/classes/sun/awt/X11/XWindowPeer.java
! src/windows/classes/sun/awt/windows/WDialogPeer.java
! src/windows/classes/sun/awt/windows/WEmbeddedFramePeer.java
! src/windows/classes/sun/awt/windows/WFramePeer.java
! src/windows/classes/sun/awt/windows/WWindowPeer.java

Changeset: 5555093749ab
Author:    anthony
Date:      2009-04-17 16:42 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5555093749ab

6829858: JInternalFrame is not redrawing heavyweight children properly
Summary: The Container.recursiveApplyCurrentShape() is now recursively called for all hw containers, even those having non-null layout
Reviewed-by: art, dcherepanov

! src/share/classes/java/awt/Container.java
+ test/java/awt/Mixing/MixingInHwPanel.java

Changeset: bd06d33634ee
Author:    dcherepanov
Date:      2009-04-20 14:41 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bd06d33634ee

6633354: AppletPanel loads Swing classes
Reviewed-by: art, anthony

! src/share/classes/sun/applet/AppletPanel.java

Changeset: 0d03c3cc2f03
Author:    dcherepanov
Date:      2009-04-20 17:05 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0d03c3cc2f03

6770457: Using ToolTips causes inactive app window to exhibit active window behavior
Reviewed-by: art, ant

! src/windows/native/sun/windows/awt_Component.cpp
! src/windows/native/sun/windows/awt_Window.cpp
! src/windows/native/sun/windows/awt_Window.h

Changeset: 68ce3fa2b4c5
Author:    dcherepanov
Date:      2009-04-20 19:18 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/68ce3fa2b4c5

6825362: Avoid calling peer.setZOrder on Window instances
Reviewed-by: anthony

! src/share/classes/java/awt/Component.java
! src/share/classes/java/awt/Container.java
! src/share/classes/java/awt/Window.java
! src/windows/classes/sun/awt/windows/WPanelPeer.java

Changeset: 9cb0aecf54bd
Author:    anthony
Date:      2009-04-21 11:35 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9cb0aecf54bd

6802853: API: shaped & translucent windows
Summary: A public API for the feature forward-ported from 6u10.
Reviewed-by: yan

! src/share/classes/java/awt/GraphicsConfiguration.java
! src/share/classes/java/awt/GraphicsDevice.java
! src/share/classes/java/awt/Window.java
! src/share/classes/sun/awt/EmbeddedFrame.java
! src/share/classes/sun/awt/SunToolkit.java
! src/solaris/classes/sun/awt/X11GraphicsConfig.java
! src/windows/classes/sun/awt/Win32GraphicsConfig.java
! src/windows/classes/sun/awt/windows/WComponentPeer.java
! src/windows/classes/sun/awt/windows/WWindowPeer.java
- test/com/sun/awt/Translucency/TranslucentJAppletTest/TranslucentJAppletTest.java
- test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TSFrame.java
- test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TranslucentShapedFrameTest.form
- test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TranslucentShapedFrameTest.java
+ test/java/awt/Window/TranslucentJAppletTest/TranslucentJAppletTest.java
+ test/java/awt/Window/TranslucentShapedFrameTest/TSFrame.java
+ test/java/awt/Window/TranslucentShapedFrameTest/TranslucentShapedFrameTest.form
+ test/java/awt/Window/TranslucentShapedFrameTest/TranslucentShapedFrameTest.java

Changeset: 48df681dc50a
Author:    yan
Date:      2009-04-28 13:30 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/48df681dc50a

Merge

- test/com/sun/awt/Translucency/TranslucentJAppletTest/TranslucentJAppletTest.java
- test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TSFrame.java
- test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TranslucentShapedFrameTest.form
- test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TranslucentShapedFrameTest.java

Changeset: 7601454859c2
Author:    art
Date:      2009-04-17 12:46 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7601454859c2

6829923: Test javax/swing/system/6799345/TestShutdown.java fails on X11 platforms
Summary: XAWT toolkit thread is correctly interrupted when AppContext is disposed
Reviewed-by: anthony, peterz

! src/solaris/classes/sun/awt/X11/XToolkit.java

Changeset: 8e01a3dee336
Author:    amenkov
Date:      2009-04-17 15:02 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8e01a3dee336

5050147: RFE: Add More Useful Constructors to MidiMessage Subclasses
Reviewed-by: alexp

! src/share/classes/javax/sound/midi/MetaMessage.java
! src/share/classes/javax/sound/midi/ShortMessage.java
! src/share/classes/javax/sound/midi/SysexMessage.java

Changeset: f94a3aaae91d
Author:    amenkov
Date:      2009-04-17 15:10 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f94a3aaae91d

4672194: FloatControl should provide consistent policy for the floats
Reviewed-by: alexp

! src/share/classes/javax/sound/sampled/FloatControl.java

Changeset: e7b19babfd80
Author:    amenkov
Date:      2009-04-17 15:11 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e7b19babfd80

4895403: SPEC: documentation of javax.sound.sampled.spi.MixerProvider should be detailed
Reviewed-by: malenkov

! src/share/classes/javax/sound/sampled/spi/MixerProvider.java

Changeset: a301fb619494
Author:    amenkov
Date:      2009-04-17 15:15 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a301fb619494

6806019: 38 JCK api/javax_sound/midi/ tests fails starting from jdk7 b46
Reviewed-by: kalli

! src/share/classes/com/sun/media/sound/SoftSynthesizer.java

Changeset: 923a730165bf
Author:    kalli
Date:      2009-04-17 16:13 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/923a730165bf

6821030: Merge OpenJDK Gervill with upstream sources, Q1CY2009
Reviewed-by: darcy, amenkov

! src/share/classes/com/sun/media/sound/SoftAudioPusher.java
! src/share/classes/com/sun/media/sound/SoftChannel.java
! src/share/classes/com/sun/media/sound/SoftChorus.java
! src/share/classes/com/sun/media/sound/SoftFilter.java
! src/share/classes/com/sun/media/sound/SoftJitterCorrector.java
! src/share/classes/com/sun/media/sound/SoftMainMixer.java
! src/share/classes/com/sun/media/sound/SoftVoice.java
+ test/javax/sound/midi/Gervill/SoftChannel/NoteOverFlowTest.java
+ test/javax/sound/midi/Gervill/SoftFilter/TestProcessAudio.java

Changeset: e61cd67602bd
Author:    kalli
Date:      2009-04-17 16:20 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e61cd67602bd

6823445: Gervill SoftChannel/ResetAllControllers jtreg test fails after portamento fix from last merge.
Reviewed-by: amenkov

! src/share/classes/com/sun/media/sound/SoftChannel.java

Changeset: 5ac8b97ffabd
Author:    kalli
Date:      2009-04-17 16:28 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5ac8b97ffabd

6823446: Gervill SoftLowFrequencyOscillator fails when freq is set to 0 cent or 8.1758 Hz.
Reviewed-by: amenkov

! src/share/classes/com/sun/media/sound/SoftLowFrequencyOscillator.java
+ test/javax/sound/midi/Gervill/SoftLowFrequencyOscillator/TestProcessControlLogic.java

Changeset: 7f45fcc04f8e
Author:    peterz
Date:      2009-04-25 21:17 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7f45fcc04f8e

6591875: Nimbus Swing Look and Feel
Reviewed-by: jasper, ohair

! README
! make/common/Sanity.gmk
! make/common/shared/Defs.gmk
! make/common/shared/Platform.gmk
! make/common/shared/Sanity-Settings.gmk
! make/common/shared/Sanity.gmk
! make/javax/swing/plaf/Makefile
+ make/javax/swing/plaf/nimbus/Makefile
! make/tools/Makefile
+ make/tools/swing-nimbus/Makefile
+ make/tools/swing-nimbus/classes/org/jdesktop/beans/AbstractBean.java
+ make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/BezierControlPoint.java
+ make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/BlendingMode.java
+ make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Canvas.java
+ make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/ControlPoint.java
+ make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Designer.jibx.xml
+ make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/DoubleBean.java
+ make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/EllipseShape.java
+ make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/GraphicsHelper.java
+ make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Layer.java
+ make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/LayerContainer.java
+ make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/PaintedShape.java
+ make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/PathShape.java
+ make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/RectangleShape.java
+ make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/SimpleShape.java
+ make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/TemplateLayer.java
+ make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/DropShadowEffect.java
+ make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/Effect.java
+ make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/EffectUtils.java
+ make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/EffectUtilsTemp.java
+ make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/InnerGlowEffect.java
+ make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/InnerShadowEffect.java
+ make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/OuterGlowEffect.java
+ make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/ShadowEffect.java
+ make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/font/Typeface.java
+ make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/CanvasMapper.java
+ make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/ColorMapper.java
+ make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/DimensionMapper.java
+ make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/InsetsMapper.java
+ make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/AbstractGradient.java
+ make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Gradient.java
+ make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/GradientStop.java
+ make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Matte.java
+ make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/PaintModel.java
+ make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/RadialGradient.java
+ make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Texture.java
+ make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasPath.java
+ make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasResources.java
+ make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasUIDefaults.java
+ make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/DefaultsGenerator.java
+ make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/Generator.java
+ make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/GeneratorUtils.java
+ make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/ObjectCodeConvertors.java
+ make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/PainterGenerator.java
+ make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/TemplateWriter.java
+ make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/CustomUIDefault.java
+ make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/HasUIStyle.java
+ make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/PainterBorder.java
+ make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/SynthModel.java
+ make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/SynthModel.jibx.xml
+ make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIBorder.java
+ make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIColor.java
+ make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIComponent.java
+ make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIDefault.java
+ make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIDimension.java
+ make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIFont.java
+ make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIIcon.java
+ make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIIconRegion.java
+ make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIInsets.java
+ make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIPaint.java
+ make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIProperty.java
+ make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIRegion.java
+ make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIState.java
+ make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIStateType.java
+ make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIStyle.java
+ make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/BorderMapper.java
+ make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/ClassConverter.java
+ make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/ClassMapper.java
+ make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/FontMapper.java
+ make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/UIPropertyMapper.java
+ src/share/classes/com/sun/java/swing/Painter.java
! src/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java
+ src/share/classes/com/sun/java/swing/plaf/nimbus/AbstractRegionPainter.java
+ src/share/classes/com/sun/java/swing/plaf/nimbus/NimbusLookAndFeel.java
! src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java
! src/share/classes/java/awt/Color.java
! src/share/classes/javax/swing/DefaultCellEditor.java
! src/share/classes/javax/swing/DefaultListCellRenderer.java
! src/share/classes/javax/swing/JComboBox.java
! src/share/classes/javax/swing/JScrollPane.java
! src/share/classes/javax/swing/JSpinner.java
! src/share/classes/javax/swing/JSplitPane.java
! src/share/classes/javax/swing/JTable.java
! src/share/classes/javax/swing/MultiUIDefaults.java
+ src/share/classes/javax/swing/Painter.java
! src/share/classes/javax/swing/UIManager.java
! src/share/classes/javax/swing/border/TitledBorder.java
! src/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java
! src/share/classes/javax/swing/plaf/basic/BasicListUI.java
! src/share/classes/javax/swing/plaf/basic/BasicMenuItemUI.java
! src/share/classes/javax/swing/plaf/basic/BasicProgressBarUI.java
! src/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java
! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java
! src/share/classes/javax/swing/plaf/basic/BasicSplitPaneUI.java
! src/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java
! src/share/classes/javax/swing/plaf/basic/BasicTableUI.java
! src/share/classes/javax/swing/plaf/basic/BasicTextUI.java
! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java
+ src/share/classes/javax/swing/plaf/nimbus/AbstractRegionPainter.java
+ src/share/classes/javax/swing/plaf/nimbus/Defaults.template
+ src/share/classes/javax/swing/plaf/nimbus/DerivedColor.java
+ src/share/classes/javax/swing/plaf/nimbus/DropShadowEffect.java
+ src/share/classes/javax/swing/plaf/nimbus/Effect.java
+ src/share/classes/javax/swing/plaf/nimbus/EffectUtils.java
+ src/share/classes/javax/swing/plaf/nimbus/ImageCache.java
+ src/share/classes/javax/swing/plaf/nimbus/ImageScalingHelper.java
+ src/share/classes/javax/swing/plaf/nimbus/InnerGlowEffect.java
+ src/share/classes/javax/swing/plaf/nimbus/InnerShadowEffect.java
+ src/share/classes/javax/swing/plaf/nimbus/LoweredBorder.java
+ src/share/classes/javax/swing/plaf/nimbus/NimbusIcon.java
+ src/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java
+ src/share/classes/javax/swing/plaf/nimbus/NimbusStyle.java
+ src/share/classes/javax/swing/plaf/nimbus/OuterGlowEffect.java
+ src/share/classes/javax/swing/plaf/nimbus/PainterImpl.template
+ src/share/classes/javax/swing/plaf/nimbus/ShadowEffect.java
+ src/share/classes/javax/swing/plaf/nimbus/State.java
+ src/share/classes/javax/swing/plaf/nimbus/StateImpl.template
+ src/share/classes/javax/swing/plaf/nimbus/SynthPainterImpl.java
+ src/share/classes/javax/swing/plaf/nimbus/TableScrollPaneCorner.java
+ src/share/classes/javax/swing/plaf/nimbus/ToolBarSeparatorPainter.java
+ src/share/classes/javax/swing/plaf/nimbus/doc-files/properties.html
+ src/share/classes/javax/swing/plaf/nimbus/package.html
+ src/share/classes/javax/swing/plaf/nimbus/skin.laf
! src/share/classes/javax/swing/plaf/synth/SynthArrowButton.java
! src/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java
! src/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java
! src/share/classes/javax/swing/plaf/synth/SynthProgressBarUI.java
! src/share/classes/javax/swing/plaf/synth/SynthScrollBarUI.java
! src/share/classes/javax/swing/plaf/synth/SynthScrollPaneUI.java
! src/share/classes/javax/swing/plaf/synth/SynthSliderUI.java
! src/share/classes/javax/swing/plaf/synth/SynthSpinnerUI.java
! src/share/classes/javax/swing/plaf/synth/SynthStyle.java
! src/share/classes/javax/swing/plaf/synth/SynthTabbedPaneUI.java
! src/share/classes/javax/swing/plaf/synth/SynthTableHeaderUI.java
! src/share/classes/javax/swing/plaf/synth/SynthTableUI.java
! src/share/classes/javax/swing/plaf/synth/SynthTextAreaUI.java
! src/share/classes/javax/swing/plaf/synth/SynthToggleButtonUI.java
! src/share/classes/javax/swing/plaf/synth/SynthToolBarUI.java
! src/share/classes/javax/swing/plaf/synth/SynthTreeUI.java
! src/share/classes/javax/swing/table/DefaultTableCellRenderer.java
! src/share/classes/javax/swing/tree/DefaultTreeCellRenderer.java
! src/share/classes/sun/swing/DefaultLookup.java
! src/share/classes/sun/swing/FilePane.java
+ src/share/classes/sun/swing/plaf/GTKKeybindings.java
+ src/share/classes/sun/swing/plaf/WindowsKeybindings.java
! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUI.java
! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java
! src/share/classes/sun/swing/table/DefaultTableCellHeaderRenderer.java

Changeset: 8df0db057762
Author:    peterz
Date:      2009-04-28 21:41 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8df0db057762

6835113: Nimbus Makefile issue
Reviewed-by: prr

! make/tools/swing-nimbus/Makefile

Changeset: 4b922e8fef3b
Author:    yan
Date:      2009-04-28 13:41 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4b922e8fef3b

Merge

! make/common/shared/Defs.gmk
! make/common/shared/Platform.gmk
! make/common/shared/Sanity-Settings.gmk
! make/common/shared/Sanity.gmk
! src/solaris/classes/sun/awt/X11/XToolkit.java

Changeset: d5a1223e9618
Author:    yan
Date:      2009-04-29 00:27 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d5a1223e9618

Merge

- test/com/sun/awt/Translucency/TranslucentJAppletTest/TranslucentJAppletTest.java
- test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TSFrame.java
- test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TranslucentShapedFrameTest.form
- test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TranslucentShapedFrameTest.java

Changeset: 6c7c0bccab55
Author:    xdono
Date:      2009-04-30 15:04 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6c7c0bccab55

Added tag jdk7-b57 for changeset d5a1223e9618

! .hgtags

Changeset: b056c42ea5b4
Author:    tbell
Date:      2009-05-04 18:28 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b056c42ea5b4

6837214: Update JDK7 man pages
Reviewed-by: darcy, bpatel, tbell
Contributed-by: jacob.royal at sun.com

! src/linux/doc/man/appletviewer.1
! src/linux/doc/man/apt.1
! src/linux/doc/man/extcheck.1
! src/linux/doc/man/idlj.1
! src/linux/doc/man/ja/appletviewer.1
! src/linux/doc/man/ja/apt.1
! src/linux/doc/man/ja/extcheck.1
! src/linux/doc/man/ja/idlj.1
! src/linux/doc/man/ja/jar.1
! src/linux/doc/man/ja/jarsigner.1
! src/linux/doc/man/ja/java.1
! src/linux/doc/man/ja/javac.1
! src/linux/doc/man/ja/javadoc.1
! src/linux/doc/man/ja/javah.1
! src/linux/doc/man/ja/javap.1
! src/linux/doc/man/ja/javaws.1
! src/linux/doc/man/ja/jconsole.1
! src/linux/doc/man/ja/jdb.1
! src/linux/doc/man/ja/jhat.1
! src/linux/doc/man/ja/jinfo.1
! src/linux/doc/man/ja/jmap.1
! src/linux/doc/man/ja/jps.1
! src/linux/doc/man/ja/jrunscript.1
! src/linux/doc/man/ja/jsadebugd.1
! src/linux/doc/man/ja/jstack.1
! src/linux/doc/man/ja/jstat.1
! src/linux/doc/man/ja/jstatd.1
! src/linux/doc/man/ja/keytool.1
! src/linux/doc/man/ja/native2ascii.1
! src/linux/doc/man/ja/orbd.1
! src/linux/doc/man/ja/pack200.1
! src/linux/doc/man/ja/policytool.1
! src/linux/doc/man/ja/rmic.1
! src/linux/doc/man/ja/rmid.1
! src/linux/doc/man/ja/rmiregistry.1
! src/linux/doc/man/ja/schemagen.1
! src/linux/doc/man/ja/serialver.1
! src/linux/doc/man/ja/servertool.1
! src/linux/doc/man/ja/tnameserv.1
! src/linux/doc/man/ja/unpack200.1
! src/linux/doc/man/ja/wsgen.1
! src/linux/doc/man/ja/wsimport.1
! src/linux/doc/man/ja/xjc.1
! src/linux/doc/man/jar.1
! src/linux/doc/man/jarsigner.1
! src/linux/doc/man/java.1
! src/linux/doc/man/javac.1
! src/linux/doc/man/javadoc.1
! src/linux/doc/man/javah.1
! src/linux/doc/man/javap.1
! src/linux/doc/man/javaws.1
! src/linux/doc/man/jconsole.1
! src/linux/doc/man/jdb.1
! src/linux/doc/man/jhat.1
! src/linux/doc/man/jinfo.1
! src/linux/doc/man/jmap.1
! src/linux/doc/man/jps.1
! src/linux/doc/man/jrunscript.1
! src/linux/doc/man/jsadebugd.1
! src/linux/doc/man/jstack.1
! src/linux/doc/man/jstat.1
! src/linux/doc/man/jstatd.1
! src/linux/doc/man/keytool.1
! src/linux/doc/man/native2ascii.1
! src/linux/doc/man/orbd.1
! src/linux/doc/man/pack200.1
! src/linux/doc/man/policytool.1
! src/linux/doc/man/rmic.1
! src/linux/doc/man/rmid.1
! src/linux/doc/man/rmiregistry.1
! src/linux/doc/man/schemagen.1
! src/linux/doc/man/serialver.1
! src/linux/doc/man/servertool.1
! src/linux/doc/man/tnameserv.1
! src/linux/doc/man/unpack200.1
! src/linux/doc/man/wsgen.1
! src/linux/doc/man/wsimport.1
! src/linux/doc/man/xjc.1
! src/solaris/doc/sun/man/man1/appletviewer.1
! src/solaris/doc/sun/man/man1/apt.1
! src/solaris/doc/sun/man/man1/extcheck.1
! src/solaris/doc/sun/man/man1/idlj.1
! src/solaris/doc/sun/man/man1/ja/appletviewer.1
! src/solaris/doc/sun/man/man1/ja/apt.1
! src/solaris/doc/sun/man/man1/ja/extcheck.1
! src/solaris/doc/sun/man/man1/ja/idlj.1
! src/solaris/doc/sun/man/man1/ja/jar.1
! src/solaris/doc/sun/man/man1/ja/jarsigner.1
! src/solaris/doc/sun/man/man1/ja/java.1
! src/solaris/doc/sun/man/man1/ja/javac.1
! src/solaris/doc/sun/man/man1/ja/javadoc.1
! src/solaris/doc/sun/man/man1/ja/javah.1
! src/solaris/doc/sun/man/man1/ja/javap.1
! src/solaris/doc/sun/man/man1/ja/javaws.1
! src/solaris/doc/sun/man/man1/ja/jconsole.1
! src/solaris/doc/sun/man/man1/ja/jdb.1
! src/solaris/doc/sun/man/man1/ja/jhat.1
! src/solaris/doc/sun/man/man1/ja/jinfo.1
! src/solaris/doc/sun/man/man1/ja/jmap.1
! src/solaris/doc/sun/man/man1/ja/jps.1
! src/solaris/doc/sun/man/man1/ja/jrunscript.1
! src/solaris/doc/sun/man/man1/ja/jsadebugd.1
! src/solaris/doc/sun/man/man1/ja/jstack.1
! src/solaris/doc/sun/man/man1/ja/jstat.1
! src/solaris/doc/sun/man/man1/ja/jstatd.1
! src/solaris/doc/sun/man/man1/ja/keytool.1
! src/solaris/doc/sun/man/man1/ja/native2ascii.1
! src/solaris/doc/sun/man/man1/ja/orbd.1
! src/solaris/doc/sun/man/man1/ja/pack200.1
! src/solaris/doc/sun/man/man1/ja/policytool.1
! src/solaris/doc/sun/man/man1/ja/rmic.1
! src/solaris/doc/sun/man/man1/ja/rmid.1
! src/solaris/doc/sun/man/man1/ja/rmiregistry.1
! src/solaris/doc/sun/man/man1/ja/schemagen.1
! src/solaris/doc/sun/man/man1/ja/serialver.1
! src/solaris/doc/sun/man/man1/ja/servertool.1
! src/solaris/doc/sun/man/man1/ja/tnameserv.1
! src/solaris/doc/sun/man/man1/ja/unpack200.1
! src/solaris/doc/sun/man/man1/ja/wsgen.1
! src/solaris/doc/sun/man/man1/ja/wsimport.1
! src/solaris/doc/sun/man/man1/ja/xjc.1
! src/solaris/doc/sun/man/man1/jar.1
! src/solaris/doc/sun/man/man1/jarsigner.1
! src/solaris/doc/sun/man/man1/java.1
! src/solaris/doc/sun/man/man1/javac.1
! src/solaris/doc/sun/man/man1/javadoc.1
! src/solaris/doc/sun/man/man1/javah.1
! src/solaris/doc/sun/man/man1/javap.1
! src/solaris/doc/sun/man/man1/javaws.1
! src/solaris/doc/sun/man/man1/jconsole.1
! src/solaris/doc/sun/man/man1/jdb.1
! src/solaris/doc/sun/man/man1/jhat.1
! src/solaris/doc/sun/man/man1/jinfo.1
! src/solaris/doc/sun/man/man1/jmap.1
! src/solaris/doc/sun/man/man1/jps.1
! src/solaris/doc/sun/man/man1/jrunscript.1
! src/solaris/doc/sun/man/man1/jsadebugd.1
! src/solaris/doc/sun/man/man1/jstack.1
! src/solaris/doc/sun/man/man1/jstat.1
! src/solaris/doc/sun/man/man1/jstatd.1
! src/solaris/doc/sun/man/man1/keytool.1
! src/solaris/doc/sun/man/man1/native2ascii.1
! src/solaris/doc/sun/man/man1/orbd.1
! src/solaris/doc/sun/man/man1/pack200.1
! src/solaris/doc/sun/man/man1/policytool.1
! src/solaris/doc/sun/man/man1/rmic.1
! src/solaris/doc/sun/man/man1/rmid.1
! src/solaris/doc/sun/man/man1/rmiregistry.1
! src/solaris/doc/sun/man/man1/schemagen.1
! src/solaris/doc/sun/man/man1/serialver.1
! src/solaris/doc/sun/man/man1/servertool.1
! src/solaris/doc/sun/man/man1/tnameserv.1
! src/solaris/doc/sun/man/man1/unpack200.1
! src/solaris/doc/sun/man/man1/wsgen.1
! src/solaris/doc/sun/man/man1/wsimport.1
! src/solaris/doc/sun/man/man1/xjc.1

Changeset: b3720710a4ba
Author:    tbell
Date:      2009-05-04 22:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b3720710a4ba

Merge




From tim.bell at sun.com  Tue May  5 23:30:02 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Tue, 05 May 2009 23:30:02 +0000
Subject: hg: jdk7/tl/langtools: 4 new changesets
Message-ID: <20090505233011.5AF34E014@hg.openjdk.java.net>

Changeset: 4cfd3a840538
Author:    xdono
Date:      2009-04-23 15:55 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/4cfd3a840538

Added tag jdk7-b56 for changeset 825f23a4f262

! .hgtags

Changeset: 4030cc469205
Author:    ohair
Date:      2009-04-27 20:19 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/4030cc469205

6831225: Upgrade JPRT jobs to use newer Linux 2.6 (e.g. Fedora 9)
Reviewed-by: tbell

! make/jprt.properties

Changeset: 8a2424db1a14
Author:    xdono
Date:      2009-04-30 15:04 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/8a2424db1a14

Added tag jdk7-b57 for changeset 4030cc469205

! .hgtags

Changeset: 5bcac54d408b
Author:    tbell
Date:      2009-05-04 22:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/5bcac54d408b

Merge




From john.rose at sun.com  Wed May  6 05:53:29 2009
From: john.rose at sun.com (john.rose at sun.com)
Date: Wed, 06 May 2009 05:53:29 +0000
Subject: hg: jdk7/tl/jdk: 6829144: JSR 292 JVM features need a provisional
	Java API
Message-ID: <20090506055359.7BD34E0E5@hg.openjdk.java.net>

Changeset: d201987cb76c
Author:    jrose
Date:      2009-05-05 22:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d201987cb76c

6829144: JSR 292 JVM features need a provisional Java API
Summary: JDK API and runtime (partial) for anonk, meth, indy
Reviewed-by: mr

! make/docs/CORE_PKGS.gmk
! make/java/Makefile
+ make/java/dyn/Makefile
+ src/share/classes/java/dyn/CallSite.java
+ src/share/classes/java/dyn/InvokeDynamic.java
+ src/share/classes/java/dyn/InvokeDynamicBootstrapError.java
+ src/share/classes/java/dyn/JavaMethodHandle.java
+ src/share/classes/java/dyn/Linkage.java
+ src/share/classes/java/dyn/LinkagePermission.java
+ src/share/classes/java/dyn/MethodHandle.java
+ src/share/classes/java/dyn/MethodHandles.java
+ src/share/classes/java/dyn/MethodType.java
+ src/share/classes/java/dyn/MethodTypeForm.java
+ src/share/classes/java/dyn/NoAccessException.java
+ src/share/classes/java/dyn/WrongMethodTypeException.java
+ src/share/classes/java/dyn/package-info.java
+ src/share/classes/sun/dyn/Access.java
+ src/share/classes/sun/dyn/AdapterMethodHandle.java
+ src/share/classes/sun/dyn/BoundMethodHandle.java
+ src/share/classes/sun/dyn/CallSiteImpl.java
+ src/share/classes/sun/dyn/DirectMethodHandle.java
+ src/share/classes/sun/dyn/FilterGeneric.java
+ src/share/classes/sun/dyn/FilterOneArgument.java
+ src/share/classes/sun/dyn/FromGeneric.java
+ src/share/classes/sun/dyn/Invokers.java
+ src/share/classes/sun/dyn/MemberName.java
+ src/share/classes/sun/dyn/MethodHandleImpl.java
+ src/share/classes/sun/dyn/MethodHandleNatives.java
+ src/share/classes/sun/dyn/MethodTypeImpl.java
+ src/share/classes/sun/dyn/ToGeneric.java
+ src/share/classes/sun/dyn/anon/AnonymousClassLoader.java
+ src/share/classes/sun/dyn/anon/ConstantPoolParser.java
+ src/share/classes/sun/dyn/anon/ConstantPoolPatch.java
+ src/share/classes/sun/dyn/anon/ConstantPoolVisitor.java
+ src/share/classes/sun/dyn/anon/InvalidConstantPoolFormatException.java
+ src/share/classes/sun/dyn/empty/Empty.java
+ src/share/classes/sun/dyn/package-info.java
+ src/share/classes/sun/dyn/util/BytecodeName.java
+ src/share/classes/sun/dyn/util/BytecodeSignature.java
+ src/share/classes/sun/dyn/util/ValueConversions.java
+ src/share/classes/sun/dyn/util/VerifyAccess.java
+ src/share/classes/sun/dyn/util/VerifyType.java
+ src/share/classes/sun/dyn/util/Wrapper.java
+ src/share/classes/sun/dyn/util/package-info.java
! src/share/classes/sun/misc/Unsafe.java
! src/share/javavm/export/classfile_constants.h
! src/share/native/common/check_code.c
! src/share/native/common/opcodes.in_out



From tim.bell at sun.com  Thu May  7 18:31:47 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Thu, 07 May 2009 18:31:47 +0000
Subject: hg: jdk7/tl/jdk: 10 new changesets
Message-ID: <20090507183410.43350E528@hg.openjdk.java.net>

Changeset: a33222e53611
Author:    prr
Date:      2009-04-02 10:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a33222e53611

6753173: No need to read all the TrueType 'post' table to get underline info
Reviewed-by: igor, jgodinez

! src/share/classes/sun/font/TrueTypeFont.java

Changeset: e3b4eb55a696
Author:    lana
Date:      2009-04-08 15:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e3b4eb55a696

Merge

- make/common/shared/Compiler.gmk
- make/jprt.config
- src/share/classes/sun/misc/JavaIODeleteOnExitAccess.java

Changeset: e61d93fc8ed1
Author:    mchung
Date:      2009-04-14 17:43 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e61d93fc8ed1

6818072: Load Ductus using Class.forName if exist instead of using the service loader
Summary: First attempt Class.forName to load Ductus class before using service loader
Reviewed-by: flar, prr

! src/share/classes/sun/java2d/pipe/RenderingEngine.java

Changeset: d609ae2faac2
Author:    jgodinez
Date:      2009-04-15 08:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d609ae2faac2

6827989: Use Unsafe.copyMemory for array->Unsafe copy operations in RenderBuffer
Reviewed-by: campbell, flar
Contributed-by: linuxhippy <linuxhippy at gmail.com>

! make/sun/awt/FILES_c_unix.gmk
! make/sun/awt/FILES_c_windows.gmk
! make/sun/awt/mapfile-vers
! make/sun/awt/mapfile-vers-linux
! src/share/classes/sun/java2d/pipe/RenderBuffer.java
- src/share/native/sun/java2d/pipe/RenderBuffer.c

Changeset: c3aaa11e4eb6
Author:    jgodinez
Date:      2009-04-20 12:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c3aaa11e4eb6

6821495: test/java/awt/print/PrinterJob/PrtException.java fails
Reviewed-by: igor, prr

! test/java/awt/PrintJob/EdgeTest/EdgeTest.java
! test/java/awt/PrintJob/MultipleEnd/MultipleEnd.java
+ test/java/awt/print/PrinterJob/Collate2DPrintingTest.java
+ test/java/awt/print/PrinterJob/PrtException.java
! test/javax/print/CheckDupFlavor.java
+ test/javax/print/LookupServices.java
! test/javax/print/TestRaceCond.java
+ test/javax/print/attribute/Chroma.java
+ test/javax/print/attribute/ChromaticityValues.java
+ test/javax/print/attribute/GetCopiesSupported.java
! test/javax/print/attribute/PSCopiesFlavorTest.java
+ test/javax/print/attribute/SidesPageRangesTest.java
+ test/javax/print/attribute/SupportedPrintableAreas.java
+ test/javax/print/attribute/autosense/PrintAutoSenseData.java

Changeset: 53ca5822bdfe
Author:    jgodinez
Date:      2009-04-21 09:43 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/53ca5822bdfe

6829678: StrokeShapeTest: createStrokedShape() behaves differently
Reviewed-by: igor, flar
Contributed-by: rkennke <roman.kennke at aicas.com>

! src/share/classes/sun/java2d/pisces/Stroker.java
+ test/sun/pisces/StrokeShapeTest.java

Changeset: b4450e6de8a3
Author:    jgodinez
Date:      2009-04-28 13:25 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b4450e6de8a3

Merge

! make/sun/awt/FILES_c_windows.gmk
! make/sun/awt/mapfile-vers-linux
! src/share/classes/sun/font/TrueTypeFont.java
- src/share/classes/sun/text/normalizer/UProperty.java
- src/share/native/java/util/zip/ZipEntry.c
- src/windows/native/sun/windows/awt_KeyboardFocusManager.h

Changeset: 662a327cfe1d
Author:    jgodinez
Date:      2009-04-29 12:27 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/662a327cfe1d

Merge

- src/share/native/sun/java2d/pipe/RenderBuffer.c

Changeset: f8b061ea131c
Author:    jgodinez
Date:      2009-05-05 09:09 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f8b061ea131c

Merge

- src/share/native/sun/java2d/pipe/RenderBuffer.c

Changeset: 9ba256e2e5c1
Author:    tbell
Date:      2009-05-05 23:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9ba256e2e5c1

Merge




From gbenson at redhat.com  Fri May  8 16:14:41 2009
From: gbenson at redhat.com (Gary Benson)
Date: Fri, 8 May 2009 17:14:41 +0100
Subject: Review Request: 6812511: Allow Interpreter-only builds
Message-ID: <20090508161440.GK3190@redhat.com>

Hi all,

I have a patch that's been sitting in the bug databases for a while:

  https://bugs.openjdk.java.net/show_bug.cgi?id=100011
  http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6812511

It allows HotSpot to be built interpreter-only, which is required
for the Zero assembler port.  It touches both the hotspot and the
jdk forests, so it may need approval from someone in both teams.
Christian Thalinger (twisti) said that someone (Kelly?) told him
verbally it was fine to commit a while back, but it was a month
or so ago and can't remember exactly what was said.  I have push
access (I think -- I've not tried it out yet!) but I don't want
to commit it while it's ambiguous like this.

Cheers,
Gary

-- 
http://gbenson.net/


From martinrb at google.com  Fri May  8 16:47:03 2009
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 8 May 2009 09:47:03 -0700
Subject: Review Request: 6812511: Allow Interpreter-only builds
In-Reply-To: <20090508161440.GK3190@redhat.com>
References: <20090508161440.GK3190@redhat.com>
Message-ID: <1ccfd1c10905080947n10b45f0dk7f96916e8a91d16b@mail.gmail.com>

[+build-dev]

Not that it matters much, but build-dev is a better list for this patch
than core-libs-dev.

Martin

On Fri, May 8, 2009 at 09:14, Gary Benson <gbenson at redhat.com> wrote:
> Hi all,
>
> I have a patch that's been sitting in the bug databases for a while:
>
> ?https://bugs.openjdk.java.net/show_bug.cgi?id=100011
> ?http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6812511
>
> It allows HotSpot to be built interpreter-only, which is required
> for the Zero assembler port. ?It touches both the hotspot and the
> jdk forests, so it may need approval from someone in both teams.
> Christian Thalinger (twisti) said that someone (Kelly?) told him
> verbally it was fine to commit a while back, but it was a month
> or so ago and can't remember exactly what was said. ?I have push
> access (I think -- I've not tried it out yet!) but I don't want
> to commit it while it's ambiguous like this.
>
> Cheers,
> Gary
>
> --
> http://gbenson.net/
>


From Ulf.Zibis at gmx.de  Sat May  9 17:50:39 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Sat, 09 May 2009 19:50:39 +0200
Subject: Rewrite of IBM doublebyte charsets
In-Reply-To: <49FA9B45.8020802@sun.com>
References: <49FA9B45.8020802@sun.com>
Message-ID: <4A05C26F.9060900@gmx.de>

Am 01.05.2009 08:48, Xueming Shen schrieb:
> Hi,
>
> While I'm waiting for Alan's code-review result for my rewriting of 
> EUC_TW
>    http://cr.openjdk.java.net/~sherman/6831794_6229811/webrev
> (much faster, much smaller, near 8% decrease of size of charsets.jar 
> with one
> charset update. OK, it's a shame...I meant the old data structure)


EUC_TW statistics:

Plane   range   length  segments  segments-usage-ratio

 0    a1a1-fdcb   5868  5d = 93   66 %
 _0   a1a1-a744    434   7 = 7    65 %
 _1   c2a1-fdcb   5434  3c = 60   95 %

 1:8ea2   -f2c4   7650  52 = 82   98 %
 2:8ea3   -e7aa   6394  47 = 71   95 %
 3:8ea4   -eedc   7286  4e = 78   98 %
 4:8ea5   -fcd1   8601  5c = 92   98 %
 5:8ea6   -e4fa   6385  44 = 68   99 %
 6:8ea7   -ebd5   6532  4b = 75   98 %
 7:8eaf   -edb9   8721  4d = 77   92 %

Sum:             55446  262 = 610

memory amount for all segments (not truncated):
610 * 95 = 57950 code points



*** Decoder-Suggestions:

(1) Increase dimension of b2c and decouple plane 0:
      String[] b2c = new String[0x10]
      String b2c_0 = ...
    Benefit[1]: save calculation of plane no. to range 0..7 (but mask by 
0xa0)
    Benefit[2]: save range-check for plane (catch malformed plane by NPE)
    sophisticated (additionally save masking of plane no.):
      String[] b2c = new String[0xb0]

(2) Save Strings in 2-dimensional array:
      String[][] b2c = new String[0x10][]
      String[] b2c_0 = new String[0x5d]
      b2c[0x2] = new String[0x52]
      b2c[0x3] = new String[0x47]
      b2c[0x4] = new String[0x4e]
      b2c[0x5] = new String[0x5c]
      b2c[0x6] = new String[0x44]
      b2c[0x7] = new String[0x4b]
      b2c[0xf] = new String[0x4d]
    sophisticated (segments a8..c1 are unused in plane 0):
      String[] b2c_0 = new String[0x07]
      String[] b2c_1 = new String[0x3c]
    Benefit[3]: save calculation of index (multiplying with dbSegSize), 
but add 1 indirection
    Benefit[4]: save range-check for segment index (catch malformed 
segment index by NPE)
    Benefit[5]: save range-check for String index (catch malformed 
String indexes by IndexOutOfBoundsException)
    Benefit[6]: avoid 22 % superfluous memory and disk-footprint

(3) Truncate Strings (catch unmappable String indexes by 
IndexOutOfBoundsException):
    Benefit[7]: save another 4 % superfluous memory and disk-footprint

Note: All exceptions can be catched at once, as they are all of 
RuntimeException.

(4) Save mappings in data file (modified UTF-8-saved chars need 2.97 
bytes in average):
    Benefit[8]: save modified UTF-8 decoding while loading class file
    Benefit[9]: avoid another 48 % superfluous disk-footprint
    Note: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6795536
    ( I have just created patch, but I'm waiting for launch of OpenJDK-7 
project "charset-enhancement".)
    Disadvantage[1]: loading data from jar-file may be slow, but ...
    - host data file outside of jar, as loading by 
nio.channel.FileChannel from direct buffer should be fast
    - resolve Bugs:
      http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6818736
      http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6818737

(5) Generate mappings as surrogate pairs:
    High surrogates could be saved as bytes and ANDed by 0xdc00, as they 
won't exceed 0xdc80
    Benefit[10]: save decoding to surrogate pairs (I guess, this would 
significantly increase performance)
    Benefit[11]: save b2cIsSupp[] (saves another 4 % memory and 
disk-footprint)
    Disadvantage[2]: memory and disk-footprint would again increase by 50 %

(6) Change parameters of decode() method:
    static void decode(byte[] src, char[] dst, int sp, int sl, int dp, 
int dl, int p) ("beta" approach)
    speads up buffer access + avoids c1, c1 buffering
    Benefit[12]: increase performance
    Disadvantage[3]: need different methods for direct buffers

(7) Provide 4-way fork from de/encodeLoop():
    See: 
https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/src/sun/nio/cs/SingleByteEncoder_new.java?rev=&view=markup
    Benefit[13]: increase performance, if there is only 1 direct buffer

(8) Quit coders xBufferLoop by exception on xflow:
    http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6806227
    Benefit[14]: increase performance

(9) Get rid of sun.io package dependency:
    
https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/tags/milestone2/src/sun/io/
    Benefit[15]: avoid superfluous disk-footprint
    Benefit[16]: save maintenance of sun.io converters
    Disadvantage[4]: published under JRL (waiting for launch of 
OpenJDK-7 project "charset-enhancement") ;-)

*** Encoder-Suggestions (not complete, just some thoughts):

(11) Initialize encoder mappings lazy:
    Benefit[17]: increase startup performance for decoder

(12) Generate mappings for surrogate pairs:
    Benefit[18]: save encoding from surrogate pairs (I guess, this would 
significantly increase performance)

(13) Introduce 16-bit intermediate mapping ("beta"-thoughts: overall 
count of code points is < 65536):
    Benefit[19]: avoid superfluous memory and disk-footprint

-Ulf





From Ulf.Zibis at gmx.de  Sun May 10 22:57:26 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Mon, 11 May 2009 00:57:26 +0200
Subject: Rewrite of IBM doublebyte charsets
In-Reply-To: <49FA9B45.8020802@sun.com>
References: <49FA9B45.8020802@sun.com>
Message-ID: <4A075BD6.5020909@gmx.de>

Completed ...:


*** Decoder-Suggestions:

(10) Split map data files into chunks and load lazy.
    TW native speakers must be consulted, to define reasonable chunks!
    Benefit[17]: save startup time
    Benefit[18]: save memory

(11) Use java.util.BitSet for b2cIsSupp
    Benefit[19]: save memory, maybe faster


*** Encoder-Suggestions:

(21) Initialize encoder mappings lazy, maybe split into reasonable chunks:
    Benefit[21]: increase startup performance for de/encoder

(21) Save c2b and c2bPlane in 2-dimensional array:
      char[][] c2b = new char[0x100][]
      only instantiate actually used segments:
      c2b[x] = new char[0x100]
    Benefit[22]: save lookup and calculation of index, but add 1 indirection
    Benefit[23]: save range-check for segment index (catch malformed segment index by NPE)
    Benefit[24]: save c2bIndex

(22) In case of surrogate code points, use high surrogate (8 lower bits) as segment index:
      char[][] c2bSupp = new char[0x100][]
      only instantiate actually used segments:
      c2bSupp[x] = new char[0x400]
    Benefit[25]: save encoding to UC4 from surrogate pairs (I guess, this would significantly 
increase performance)
    Benefit[26]: save lookup and calculation of index, but add 1 indirection
    Benefit[27]: save range-check for segment index (catch malformed segment index by NPE)
    Benefit[28]: save c2bSuppIndex

(23) Truncate c2b segments:
      c2b[x] = new char[usedLength]
      (usedLength values could be generated and saved in EUC_TWMapping or data file)
    Benefit[29]: avoid superfluous memory and disk-footprint (I guess ~30 %)
    Benefit[30]: don't range-check in-segment index, catch unmappable index by IndexOutOfBoundsException

(24) Additinally truncate leading unmappables in c2b segments, and host offsets:
    Benefit[31]: avoid another superfluous memory and disk-footprint (I guess ~10 %)
    Disadvantage[21]: needs hosting of offsets: 256 bytes

(25) Concerning (23),(24): Check out best segment size (maybe 256 is not optimal):
    Benefit[32]: avoid another superfluous memory and disk-footprint (I guess 10-20 %)

(26) Concerning (22),(23),(24): maybe use 3-dim array and check out best segment size (maybe 10 bit 
is not optimal):
    Benefit[33]: avoid another superfluous memory and disk-footprint (I guess 10-20 %)

(27) Save Plane no. as 0x0, 0x2 .. 0x7 and 0xf:
    Benefit[34]: simplify calculation of 2nd byte, increases performance

(28) Save 2nd byte in c2bPlane directly (0xa2 .. 0xa7 and 0xaf) instead of Plane no.:
    Benefit[35]: save calculation of 2nd byte, increases performance
    Disadvantage[22]: increases c2bPlane by ~73%

-Ulf


EUC_TW statistics (updated):

Plane   range   length  segments  segments-usage-ratio

0    a1a1-fdcb   5868   5d = 93   66 %
_0   a1a1-a744    434    7 = 7    65 %
_1   c2a1-fdcb   5434   3c = 60   95 %

1:8ea2   -f2c4   7650   52 = 82   98 %
2:8ea3   -e7aa   6394   47 = 71   95 %
3:8ea4   -eedc   7286   4e = 78   98 %
4:8ea5   -fcd1   8601   5c = 92   98 %
5:8ea6   -e4fa   6385   44 = 68   99 %
6:8ea7   -ebd5   6532   4b = 75   98 %
7:8eaf   -edb9   8721   4d = 77   92 %

Sum:             55446  262 = 610

max b1 range: 5d = 93
max b2 range: 5e = 94

memory amount for all segments (not truncated):
610 * 94 = 57,340 code points
truncated -4 % :  ~55,000 code points
decoder surrogate mapping (*3):  ~165,000 bytes

disk-footprint of EUC_TWMapping (1. Approach from Sherman):
b2c           : 8 * 94 * 94 * 2.97 = 209,943 Bytes
b2cIsSuppStr  : 94 * 94 * 1.48     =  13,077
c2bIndex      : 256 * 7            =   1,792
c2bSuppIndex  : 256 * 7            =   1,792
Sum                                 ~227,000 Bytes

memory of EUC_TW (1. Approach from Sherman):
b2c           : 8 * 94 * 94 * 2 = 141,376 Bytes
b2cIsSupp     : 94 * 94         =   8,836
decoder sum   :                   150,212
c2b           : 31744 * 2       =  63,488
c2bIndex      : 256 * 2         =     512
c2bSupp       : 43520 * 2       =  87,040
c2bSuppIndex  : 256 * 2         =     512
c2bPlane      : 43520 * 1       =  43,520
encoder sum   :                   195,072




From gbenson at redhat.com  Mon May 11 07:32:50 2009
From: gbenson at redhat.com (Gary Benson)
Date: Mon, 11 May 2009 08:32:50 +0100
Subject: Review Request: 6812511: Allow Interpreter-only builds
In-Reply-To: <1ccfd1c10905080947n10b45f0dk7f96916e8a91d16b@mail.gmail.com>
References: <20090508161440.GK3190@redhat.com>
	<1ccfd1c10905080947n10b45f0dk7f96916e8a91d16b@mail.gmail.com>
Message-ID: <20090511073249.GA3204@redhat.com>

Ah, thank you.

Cheers,
Gary

Martin Buchholz wrote:
> [+build-dev]
> 
> Not that it matters much, but build-dev is a better list for this
> patch than core-libs-dev.
> 
> Martin
> 
> On Fri, May 8, 2009 at 09:14, Gary Benson <gbenson at redhat.com> wrote:
> > Hi all,
> >
> > I have a patch that's been sitting in the bug databases for a while:
> >
> > ?https://bugs.openjdk.java.net/show_bug.cgi?id=100011
> > ?http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6812511
> >
> > It allows HotSpot to be built interpreter-only, which is required
> > for the Zero assembler port. ?It touches both the hotspot and the
> > jdk forests, so it may need approval from someone in both teams.
> > Christian Thalinger (twisti) said that someone (Kelly?) told him
> > verbally it was fine to commit a while back, but it was a month
> > or so ago and can't remember exactly what was said. ?I have push
> > access (I think -- I've not tried it out yet!) but I don't want
> > to commit it while it's ambiguous like this.
> >
> > Cheers,
> > Gary
> >
> > --
> > http://gbenson.net/


From Xueming.Shen at Sun.COM  Tue May 12 06:30:53 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Mon, 11 May 2009 23:30:53 -0700
Subject: Rewrite of IBM doublebyte charsets
In-Reply-To: <4A075BD6.5020909@gmx.de>
References: <49FA9B45.8020802@sun.com> <4A075BD6.5020909@gmx.de>
Message-ID: <4A09179D.1020308@sun.com>

Ulf, thanks for taking time reviewing the changes.

It seems most of the suggestions are based on two approaches you adopted 
in your charset-improvement project

(1)extract the mapping data into a binary data file and load in the data 
as the resource file during initialization of
charset decoder/encoder

(2)totally depends on catching the IndexOutOfBoundsException to avoid 
sanity check on any array index when access
the array data

For (1), as I explained last time,  the 30% more size saving is 
attractive,  but the magnitude of the charset startup/
initialization regression (reading data from the resource inputstream is 
much slower than loading in the data as a constant
String object of a class file) is not acceptable. I do have a version of 
implementation that goes that approach, I even
sent the webrev to Alan and Masayoshi for review, I "recalled" the 
review request after realized the startup regression.
That was 6 months ago (I uploaded the webrev at 
http://cr.openjdk.java.net/~sherman/Old_newEUC_TW.)
So for now it's not a choice for me to extract the data out.

For (2), I'm not convinced that this approach is an appropriate one for 
a complicated charset like EUC_TW,
given the number of array it carries, the recovery work (to trace back 
to what goes wrong and then return the
appropriate CoderResult) will be complicated and redundant...). This 
might have a benefit of saving the range
check (I don't have any data to show how much we can gain from doing 
this, only a guess), but given almost all
segments are near "full", I don't see the benefit on the footprint 
saving side. We need some hard data to support
this approach, which I don't have for now. I would leave this one for 
you for further optimization in your project.

I have updated the webrev to address some of your other optimization 
suggestions

(1)simplify the "plane number" byte check by adding a new static array 
of cnspToIndex[16] for decoder
(2)only do the isLeagalDB check when lookup failed (assume most bytes 
fed are legal...) for decoder
(3)save plane no as 0x0, 0x2...0x7 and 0xf  for encoder (this helps save 
the plane number check during
encoding).

Something I don't think I'm going to do

(1)No I don't think we want to save the supplementary into surrogate 
pair, this is what I'm trying to fix. We don't
care the performance of surrogates, those codepoints are RARE used, 99%+ 
coding/decoding happens in
BMP, we did not have the supplementary characters for the first couple 
years. (OK, I'm a native, I don't think
I can even read those characters)

(2)The initialization c2b data for encoder has already been "lazied" 
until Encoder class gets loaded.

(3)I doubt use BitSet for b2cIsSupp will save any memory, or faster. 
b2cIsSupp has been fully utilized to
use each/every bit of its storage.

 
I gave the latest version a "quick" run, I'm happy with the performance 
gain, especially the encoding.

-client
    Encoding TimeRatio EUC_TW_OLD/x-EUC-TW: 84927,10151 :8.366368d
    Decoding TimeRatio EUC_TW_OLD/x-EUC-TW: 13162,9237 :1.424922d
    Encoding(dir) TimeRatio EUC_TW_OLD/x-EUC-TW: 94829,19950 :4.753333d
    Decoding(dir) TimeRatio EUC_TW_OLD/x-EUC-TW: 21884,17992 :1.216318d

-server

    Encoding TimeRatio EUC_TW_OLD/x-EUC-TW: 74651,12218 :6.109920d
    Decoding TimeRatio EUC_TW_OLD/x-EUC-TW: 11686,10364 :1.127557d
    Encoding(dir) TimeRatio EUC_TW_OLD/x-EUC-TW: 79058,12187 :6.487076d
    Decoding(dir) TimeRatio EUC_TW_OLD/x-EUC-TW: 13518,10198 :1.325554d

The latest webrev is at
 
http://cr.openjdk.java.net/~sherman/6831794_6229811/webrev/

Thanks,
Sherman


Ulf Zibis wrote:
> Completed ...:
>
>
> *** Decoder-Suggestions:
>
> (10) Split map data files into chunks and load lazy.
>    TW native speakers must be consulted, to define reasonable chunks!
>    Benefit[17]: save startup time
>    Benefit[18]: save memory
>
> (11) Use java.util.BitSet for b2cIsSupp
>    Benefit[19]: save memory, maybe faster
>
>
> *** Encoder-Suggestions:
>
> (21) Initialize encoder mappings lazy, maybe split into reasonable 
> chunks:
>    Benefit[21]: increase startup performance for de/encoder
>
> (21) Save c2b and c2bPlane in 2-dimensional array:
>      char[][] c2b = new char[0x100][]
>      only instantiate actually used segments:
>      c2b[x] = new char[0x100]
>    Benefit[22]: save lookup and calculation of index, but add 1 
> indirection
>    Benefit[23]: save range-check for segment index (catch malformed 
> segment index by NPE)
>    Benefit[24]: save c2bIndex
>
> (22) In case of surrogate code points, use high surrogate (8 lower 
> bits) as segment index:
>      char[][] c2bSupp = new char[0x100][]
>      only instantiate actually used segments:
>      c2bSupp[x] = new char[0x400]
>    Benefit[25]: save encoding to UC4 from surrogate pairs (I guess, 
> this would significantly increase performance)
>    Benefit[26]: save lookup and calculation of index, but add 1 
> indirection
>    Benefit[27]: save range-check for segment index (catch malformed 
> segment index by NPE)
>    Benefit[28]: save c2bSuppIndex
>
> (23) Truncate c2b segments:
>      c2b[x] = new char[usedLength]
>      (usedLength values could be generated and saved in EUC_TWMapping 
> or data file)
>    Benefit[29]: avoid superfluous memory and disk-footprint (I guess 
> ~30 %)
>    Benefit[30]: don't range-check in-segment index, catch unmappable 
> index by IndexOutOfBoundsException
>
> (24) Additinally truncate leading unmappables in c2b segments, and 
> host offsets:
>    Benefit[31]: avoid another superfluous memory and disk-footprint (I 
> guess ~10 %)
>    Disadvantage[21]: needs hosting of offsets: 256 bytes
>
> (25) Concerning (23),(24): Check out best segment size (maybe 256 is 
> not optimal):
>    Benefit[32]: avoid another superfluous memory and disk-footprint (I 
> guess 10-20 %)
>
> (26) Concerning (22),(23),(24): maybe use 3-dim array and check out 
> best segment size (maybe 10 bit is not optimal):
>    Benefit[33]: avoid another superfluous memory and disk-footprint (I 
> guess 10-20 %)
>
> (27) Save Plane no. as 0x0, 0x2 .. 0x7 and 0xf:
>    Benefit[34]: simplify calculation of 2nd byte, increases performance
>
> (28) Save 2nd byte in c2bPlane directly (0xa2 .. 0xa7 and 0xaf) 
> instead of Plane no.:
>    Benefit[35]: save calculation of 2nd byte, increases performance
>    Disadvantage[22]: increases c2bPlane by ~73%
>
> -Ulf
>
>
> EUC_TW statistics (updated):
>
> Plane   range   length  segments  segments-usage-ratio
>
> 0    a1a1-fdcb   5868   5d = 93   66 %
> _0   a1a1-a744    434    7 = 7    65 %
> _1   c2a1-fdcb   5434   3c = 60   95 %
>
> 1:8ea2   -f2c4   7650   52 = 82   98 %
> 2:8ea3   -e7aa   6394   47 = 71   95 %
> 3:8ea4   -eedc   7286   4e = 78   98 %
> 4:8ea5   -fcd1   8601   5c = 92   98 %
> 5:8ea6   -e4fa   6385   44 = 68   99 %
> 6:8ea7   -ebd5   6532   4b = 75   98 %
> 7:8eaf   -edb9   8721   4d = 77   92 %
>
> Sum:             55446  262 = 610
>
> max b1 range: 5d = 93
> max b2 range: 5e = 94
>
> memory amount for all segments (not truncated):
> 610 * 94 = 57,340 code points
> truncated -4 % :  ~55,000 code points
> decoder surrogate mapping (*3):  ~165,000 bytes
>
> disk-footprint of EUC_TWMapping (1. Approach from Sherman):
> b2c           : 8 * 94 * 94 * 2.97 = 209,943 Bytes
> b2cIsSuppStr  : 94 * 94 * 1.48     =  13,077
> c2bIndex      : 256 * 7            =   1,792
> c2bSuppIndex  : 256 * 7            =   1,792
> Sum                                 ~227,000 Bytes
>
> memory of EUC_TW (1. Approach from Sherman):
> b2c           : 8 * 94 * 94 * 2 = 141,376 Bytes
> b2cIsSupp     : 94 * 94         =   8,836
> decoder sum   :                   150,212
> c2b           : 31744 * 2       =  63,488
> c2bIndex      : 256 * 2         =     512
> c2bSupp       : 43520 * 2       =  87,040
> c2bSuppIndex  : 256 * 2         =     512
> c2bPlane      : 43520 * 1       =  43,520
> encoder sum   :                   195,072
>
>



From Ulf.Zibis at gmx.de  Tue May 12 18:25:15 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Tue, 12 May 2009 20:25:15 +0200
Subject: Rewrite of IBM doublebyte charsets
In-Reply-To: <4A09179D.1020308@sun.com>
References: <49FA9B45.8020802@sun.com> <4A075BD6.5020909@gmx.de>
	<4A09179D.1020308@sun.com>
Message-ID: <4A09BF0B.60702@gmx.de>

Sherman,
thanks for verifying my suggestions.

 > (1) simplify the "plane number" byte check by adding a new static 
array of cnspToIndex[16] for decoder
What you think about:

            int cnsPlane = sa[sp +1] ^ 0xa0;
            if (cnsPlane > 0xf ||
                           (cnsPlane = cnspToIndex[cnsPlane]) < 0)
                return CoderResult.malformedForLength(2);

or maybe (to force LoadUB, which may be faster than sign extension to int):
            int cnsPlane = (sa[sp +1] ^ 0xa0) && 0xff;

or maybe use byte[] (to force LoadUB, which may be faster than sign 
extension to int):
            byte cnsPlane = (byte)(sa[sp +1] ^ 0xa0);

or simply:

       static final byte[] cnspToIndex = new byte[0x100];
       static {
           Arrays.fill(cnspToIndex, -1);
           cnspToIndex[0xa2] = 1; cnspToIndex[0xa3] = 2; 
cnspToIndex[0xa4] = 3;
           cnspToIndex[0xa5] = 4; cnspToIndex[0xa6] = 5; 
cnspToIndex[0xa7] = 6; cnspToIndex[0xaf] = 7;
       }

            if ((cnsPlane = cnspToIndex[sa[sp + 1] && 0xff]) < 0)
                return CoderResult.malformedForLength(2);


*** Question: Why you code:

                   } else if ((byte1 & MSB) == 0) {  // ASCII  G0

instead of:

                   } else if (byte1 >= 0) {  // ASCII  G0

???

-Ulf




From Xueming.Shen at Sun.COM  Tue May 12 18:31:50 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Tue, 12 May 2009 11:31:50 -0700
Subject: Rewrite of IBM doublebyte charsets
In-Reply-To: <4A09BF0B.60702@gmx.de>
References: <49FA9B45.8020802@sun.com> <4A075BD6.5020909@gmx.de>
	<4A09179D.1020308@sun.com> <4A09BF0B.60702@gmx.de>
Message-ID: <4A09C096.8000505@sun.com>

Ulf Zibis wrote:
> Sherman,
> thanks for verifying my suggestions.
>
> > (1) simplify the "plane number" byte check by adding a new static 
> array of cnspToIndex[16] for decoder
>
> or simply:
>
>       static final byte[] cnspToIndex = new byte[0x100];
>       static {
>           Arrays.fill(cnspToIndex, -1);
>           cnspToIndex[0xa2] = 1; cnspToIndex[0xa3] = 2; 
> cnspToIndex[0xa4] = 3;
>           cnspToIndex[0xa5] = 4; cnspToIndex[0xa6] = 5; 
> cnspToIndex[0xa7] = 6; cnspToIndex[0xaf] = 7;
>       }
>
>            if ((cnsPlane = cnspToIndex[sa[sp + 1] && 0xff]) < 0)
>                return CoderResult.malformedForLength(2);
>
considered that, but ended up thinking it might not really worth the 
0x100 bytes:-) at least based on my measurement.

>
> *** Question: Why you code:
>
>                   } else if ((byte1 & MSB) == 0) {  // ASCII  G0
>
> instead of:
>
>                   } else if (byte1 >= 0) {  // ASCII  G0
>
I believe this line was written 10 years ago, so I have no idea (or 
forgot) why we picked this one, my guess is the code might
be a little easier to read with "MSB"...you think the >=0 is better or 
faster/




> ???
>
> -Ulf
>
>



From Ulf.Zibis at gmx.de  Tue May 12 19:00:24 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Tue, 12 May 2009 21:00:24 +0200
Subject: Rewrite of IBM doublebyte charsets
In-Reply-To: <4A09C096.8000505@sun.com>
References: <49FA9B45.8020802@sun.com> <4A075BD6.5020909@gmx.de>
	<4A09179D.1020308@sun.com> <4A09BF0B.60702@gmx.de>
	<4A09C096.8000505@sun.com>
Message-ID: <4A09C748.6070302@gmx.de>

Am 12.05.2009 20:31, Xueming Shen schrieb:
> Ulf Zibis wrote:
>> Sherman,
>> thanks for verifying my suggestions.
>>
>> > (1) simplify the "plane number" byte check by adding a new static 
>> array of cnspToIndex[16] for decoder
>>
>> or simply:
>>
>>       static final byte[] cnspToIndex = new byte[0x100];
>>       static {
>>           Arrays.fill(cnspToIndex, -1);
>>           cnspToIndex[0xa2] = 1; cnspToIndex[0xa3] = 2; 
>> cnspToIndex[0xa4] = 3;
>>           cnspToIndex[0xa5] = 4; cnspToIndex[0xa6] = 5; 
>> cnspToIndex[0xa7] = 6; cnspToIndex[0xaf] = 7;
>>       }
>>
>>            if ((cnsPlane = cnspToIndex[sa[sp + 1] && 0xff]) < 0)
>>                return CoderResult.malformedForLength(2);
>>
> considered that, but ended up thinking it might not really worth the 
> 0x100 bytes:-) at least based on my measurement.

Well, int[16] is even 64 bytes, and loop performance should be more 
important here than wasting 196 bytes considering ~227,000 Bytes for the 
mapping tables?

>
>>
>> *** Question: Why you code:
>>
>>                   } else if ((byte1 & MSB) == 0) {  // ASCII  G0
>>
>> instead of:
>>
>>                   } else if (byte1 >= 0) {  // ASCII  G0
>>
> I believe this line was written 10 years ago, so I have no idea (or 
> forgot) why we picked this one, my guess is the code might
> be a little easier to read with "MSB"...you think the >=0 is better or 
> faster/

Yes, I think it's also faster, as loading of "MSB" + AND would be saved.
Not sure if HotSpot will detect the shortcut!





From Xueming.Shen at Sun.COM  Tue May 12 19:03:01 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Tue, 12 May 2009 12:03:01 -0700
Subject: Rewrite of IBM doublebyte charsets
In-Reply-To: <4A09C748.6070302@gmx.de>
References: <49FA9B45.8020802@sun.com> <4A075BD6.5020909@gmx.de>
	<4A09179D.1020308@sun.com> <4A09BF0B.60702@gmx.de>
	<4A09C096.8000505@sun.com> <4A09C748.6070302@gmx.de>
Message-ID: <4A09C7E5.4060301@sun.com>

Ulf Zibis wrote:
>>>
>>> *** Question: Why you code:
>>>
>>>                   } else if ((byte1 & MSB) == 0) {  // ASCII  G0
>>>
>>> instead of:
>>>
>>>                   } else if (byte1 >= 0) {  // ASCII  G0
>>>
>> I believe this line was written 10 years ago, so I have no idea (or 
>> forgot) why we picked this one, my guess is the code might
>> be a little easier to read with "MSB"...you think the >=0 is better 
>> or faster/
>
> Yes, I think it's also faster, as loading of "MSB" + AND would be saved.
> Not sure if HotSpot will detect the shortcut!
>

it actually should be "byte1 < 0x80"

>
>



From Ulf.Zibis at gmx.de  Tue May 12 22:45:56 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Wed, 13 May 2009 00:45:56 +0200
Subject: Rewrite of IBM doublebyte charsets
In-Reply-To: <4A09C7E5.4060301@sun.com>
References: <49FA9B45.8020802@sun.com> <4A075BD6.5020909@gmx.de>
	<4A09179D.1020308@sun.com> <4A09BF0B.60702@gmx.de>
	<4A09C096.8000505@sun.com> <4A09C748.6070302@gmx.de>
	<4A09C7E5.4060301@sun.com>
Message-ID: <4A09FC24.8070200@gmx.de>

Am 12.05.2009 21:03, Xueming Shen schrieb:
> Ulf Zibis wrote:
>>>>
>>>> *** Question: Why you code:
>>>>
>>>>                   } else if ((byte1 & MSB) == 0) {  // ASCII  G0
>>>>
>>>> instead of:
>>>>
>>>>                   } else if (byte1 >= 0) {  // ASCII  G0
>>>>
>>> I believe this line was written 10 years ago, so I have no idea (or 
>>> forgot) why we picked this one, my guess is the code might
>>> be a little easier to read with "MSB"...you think the >=0 is better 
>>> or faster/
>>
>> Yes, I think it's also faster, as loading of "MSB" + AND would be saved.
>> Not sure if HotSpot will detect the shortcut!
>>
>
> it actually should be "byte1 < 0x80"
>

Oops, you are right. I was in the assumption, that byte1 was, "naked" 
from byte array, in range 0xffffff80..0x7f.
Maybe it's better to do:
    byte byte1 = sa[sp];
or mask by 0xff after the if .. else

... so we could save some more loop effective opcode by "byte1 >= 0"


-Ulf




From Ulf.Zibis at gmx.de  Tue May 12 23:00:05 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Wed, 13 May 2009 01:00:05 +0200
Subject: Rewrite of EUC_TW
In-Reply-To: <4A09CEBD.3050703@sun.com>
References: <49FA9B45.8020802@sun.com> <4A075BD6.5020909@gmx.de>
	<4A09179D.1020308@sun.com> <4A09BF0B.60702@gmx.de>
	<4A09C096.8000505@sun.com> <4A09C748.6070302@gmx.de>
	<4A09CEBD.3050703@sun.com>
Message-ID: <4A09FF75.4010400@gmx.de>

Am 12.05.2009 21:32, Xueming Shen schrieb:
> Updated the webrev with some "final tweak".
>
> http://cr.openjdk.java.net/~sherman/6831794_6229811/webrev
>
> (1)change the MSB to < 0x80 as Ulf suggested, hope it faster, but it 
> at lease saved one field from the class file:-)
> (2)tweak the encoder code a little to encode supplementary character 
> only after BMP character encoding failed,
> as commented in the code, it boots the BMP encoding about 10% on the 
> price of supplementary character, but
> something worth doing.

I think, this was good idea !

> (3)tweak the initC2B code a little to make it a little faster (to 
> avoid the n * segSize)

Also good :-)

>
> Hope this is really a final one:-) the performance data looks good 
> enough for me, yesterday and today's tweak
> seems to be helpful, thanks Ulf!

Could you share the new performance data ?

> After we are done with this one, please keep doing the real "ibm 
> charset rewrite":-)
>

Tomorrow..... :-)

-Ulf




From Xueming.Shen at Sun.COM  Wed May 13 03:42:15 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Tue, 12 May 2009 20:42:15 -0700
Subject: Rewrite of EUC_TW
In-Reply-To: <4A09FF75.4010400@gmx.de>
References: <49FA9B45.8020802@sun.com> <4A075BD6.5020909@gmx.de>
	<4A09179D.1020308@sun.com> <4A09BF0B.60702@gmx.de>
	<4A09C096.8000505@sun.com>
	<4A09C748.6070302@gmx.de> <4A09CEBD.3050703@sun.com>
	<4A09FF75.4010400@gmx.de>
Message-ID: <4A0A4197.4030503@sun.com>

Ulf Zibis wrote:
>
>>
>> Hope this is really a final one:-) the performance data looks good 
>> enough for me, yesterday and today's tweak
>> seems to be helpful, thanks Ulf!
>
> Could you share the new performance data ?
>
I simply ran the test case TestEUC_TW attached in the test case, set the 
iteration set to 200, run with
BMP characters only, supplementary characters only and mixed.

http://cr.openjdk.java.net/~sherman/6831794_6229811/webrev/test/sun/nio/cs/TestEUC_TW.java.html

Though this is not a real benchmark, the data does say something.

BMP -client:
    Encoding TimeRatio EUC_TW_OLD/x-EUC-TW: 14178,3350 :4.232239
    Decoding TimeRatio EUC_TW_OLD/x-EUC-TW: 5061,3538 :1.430469
    Encoding(dir) TimeRatio EUC_TW_OLD/x-EUC-TW: 17917,7431 :2.411116
    Decoding(dir) TimeRatio EUC_TW_OLD/x-EUC-TW: 7966,6859 :1.161394

SUPP -client
    Encoding TimeRatio EUC_TW_OLD/x-EUC-TW: 72054,7165 :10.056385
    Decoding TimeRatio EUC_TW_OLD/x-EUC-TW: 7912,5550 :1.425586
    Encoding(dir) TimeRatio EUC_TW_OLD/x-EUC-TW: 78578,12924 :6.080006
    Decoding(dir) TimeRatio EUC_TW_OLD/x-EUC-TW: 13198,11483 :1.149351

Mixed -client
    Encoding TimeRatio EUC_TW_OLD/x-EUC-TW: 73012,7499 :9.736231
    Decoding TimeRatio EUC_TW_OLD/x-EUC-TW: 7952,5549 :1.433051
    Encoding(dir) TimeRatio EUC_TW_OLD/x-EUC-TW: 77963,13116 :5.944114
    Decoding(dir) TimeRatio EUC_TW_OLD/x-EUC-TW: 13139,11727 :1.120406

BMP -server:
    Encoding TimeRatio EUC_TW_OLD/x-EUC-TW: 13164,3479 :3.783846
    Decoding TimeRatio EUC_TW_OLD/x-EUC-TW: 4703,2304 :2.041233
    Encoding(dir) TimeRatio EUC_TW_OLD/x-EUC-TW: 13758,3572 :3.851624
    Decoding(dir) TimeRatio EUC_TW_OLD/x-EUC-TW: 5370,3421 :1.569716

SUPP -server
    Encoding TimeRatio EUC_TW_OLD/x-EUC-TW: 67307,5540 :12.149278
    Decoding TimeRatio EUC_TW_OLD/x-EUC-TW: 5825,4434 :1.313712
    Encoding(dir) TimeRatio EUC_TW_OLD/x-EUC-TW: 68738,5710 :12.038179
    Decoding(dir) TimeRatio EUC_TW_OLD/x-EUC-TW: 5980,4104 :1.457115

Mixed -server
    Encoding TimeRatio EUC_TW_OLD/x-EUC-TW: 67568,5465 :12.363769
    Decoding TimeRatio EUC_TW_OLD/x-EUC-TW: 6323,4421 :1.430219
    Encoding(dir) TimeRatio EUC_TW_OLD/x-EUC-TW: 68766,5767 :11.924051
    Decoding(dir) TimeRatio EUC_TW_OLD/x-EUC-TW: 5637,4040 :1.395297



From Ulf.Zibis at gmx.de  Thu May 14 20:14:30 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Thu, 14 May 2009 22:14:30 +0200
Subject: Rewrite of IBM doublebyte charsets
In-Reply-To: <4A09179D.1020308@sun.com>
References: <49FA9B45.8020802@sun.com> <4A075BD6.5020909@gmx.de>
	<4A09179D.1020308@sun.com>
Message-ID: <4A0C7BA6.1040600@gmx.de>

Now I have time to answer more detailed ...

Am 12.05.2009 08:30, Xueming Shen schrieb:
> For (2), I'm not convinced that this approach is an appropriate one 
> for a complicated charset like EUC_TW,
> given the number of array it carries, the recovery work (to trace back 
> to what goes wrong and then return the
> appropriate CoderResult) will be complicated and redundant...).

Well, checking the range twice is also redundant (It's additionally 
checked behind the scenes on every array access by JVM).

> This might have a benefit of saving the range
> check (I don't have any data to show how much we can gain from doing 
> this, only a guess), but given almost all
> segments are near "full", I don't see the benefit on the footprint 
> saving side. We need some hard data to support
> this approach, which I don't have for now. I would leave this one for 
> you for further optimization in your project.

Yes, that's good idea. I would be happy, if it would be launched in the 
near future ...

>
> I have updated the webrev to address some of your other optimization 
> suggestions
>

Happy to see that. :-)

>
> (1)No I don't think we want to save the supplementary into surrogate 
> pair, this is what I'm trying to fix. We don't
> care the performance of surrogates, those codepoints are RARE used, 
> 99%+ coding/decoding happens in
> BMP, we did not have the supplementary characters for the first couple 
> years. (OK, I'm a native, I don't think
> I can even read those characters)

This is, what I didn't know. My assumption was, that those supplementary 
characters would be regularly used, as they are 137 % of BMP chars count.
But if they are so rare used, wouldn't it be reasonable to split the 
mapping into 2 chunks, or even 3 chunks, having a base-chunk of about 
~10 % of BMP. Your native status would help to discover those ~10 %. ;-)
Well, such optimization would ideally placed in the mentioned project.

>
> (2)The initialization c2b data for encoder has already been "lazied" 
> until Encoder class gets loaded.

Oops, I oversaw this fact. ;-)


-Ulf




From Ulf.Zibis at gmx.de  Thu May 14 20:26:11 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Thu, 14 May 2009 22:26:11 +0200
Subject: Rewrite of IBM doublebyte charsets
In-Reply-To: <4A09C096.8000505@sun.com>
References: <49FA9B45.8020802@sun.com> <4A075BD6.5020909@gmx.de>
	<4A09179D.1020308@sun.com> <4A09BF0B.60702@gmx.de>
	<4A09C096.8000505@sun.com>
Message-ID: <4A0C7E63.2010208@gmx.de>

Am 12.05.2009 20:31, Xueming Shen schrieb:
> Ulf Zibis wrote:
>> Sherman,
>> thanks for verifying my suggestions.
>>
>> > (1) simplify the "plane number" byte check by adding a new static 
>> array of cnspToIndex[16] for decoder
>>
>> or simply:
>>
>>       static final byte[] cnspToIndex = new byte[0x100];
>>       static {
>>           Arrays.fill(cnspToIndex, -1);
>>           cnspToIndex[0xa2] = 1; cnspToIndex[0xa3] = 2; 
>> cnspToIndex[0xa4] = 3;
>>           cnspToIndex[0xa5] = 4; cnspToIndex[0xa6] = 5; 
>> cnspToIndex[0xa7] = 6; cnspToIndex[0xaf] = 7;
>>       }
>>
>>            if ((cnsPlane = cnspToIndex[sa[sp + 1] && 0xff]) < 0)
>>                return CoderResult.malformedForLength(2);
>>
> considered that, but ended up thinking it might not really worth the 
> 0x100 bytes:-) at least based on my measurement.

But I wonder, that you don't consider my XOR approach. The XOR needs 
only to be computed once in contrast to 3 times computing AND + 
comparing against -1 (needs load operation in contrast to compare '< 0')


-Ulf




From Ulf.Zibis at gmx.de  Thu May 14 20:44:04 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Thu, 14 May 2009 22:44:04 +0200
Subject: Rewrite of EUC_TW
In-Reply-To: <4A0A4197.4030503@sun.com>
References: <49FA9B45.8020802@sun.com> <4A075BD6.5020909@gmx.de>
	<4A09179D.1020308@sun.com> <4A09BF0B.60702@gmx.de>
	<4A09C096.8000505@sun.com> <4A09C748.6070302@gmx.de>
	<4A09CEBD.3050703@sun.com> <4A09FF75.4010400@gmx.de>
	<4A0A4197.4030503@sun.com>
Message-ID: <4A0C8294.7020602@gmx.de>

Am 13.05.2009 05:42, Xueming Shen schrieb:
> Ulf Zibis wrote:
>>
>>>
>>> Hope this is really a final one:-) the performance data looks good 
>>> enough for me, yesterday and today's tweak
>>> seems to be helpful, thanks Ulf!
>>
>> Could you share the new performance data ?
>>


Regrettably I can't compare your results against the results from day 
before (without the tweaks suggested from my side), as it seems you have 
used different algorithm. :-(

-Ulf


> I simply ran the test case TestEUC_TW attached in the test case, set 
> the iteration set to 200, run with
> BMP characters only, supplementary characters only and mixed.
>
> http://cr.openjdk.java.net/~sherman/6831794_6229811/webrev/test/sun/nio/cs/TestEUC_TW.java.html 
>
>
> Though this is not a real benchmark, the data does say something.
>
> BMP -client:
>    Encoding TimeRatio EUC_TW_OLD/x-EUC-TW: 14178,3350 :4.232239
>    Decoding TimeRatio EUC_TW_OLD/x-EUC-TW: 5061,3538 :1.430469
>    Encoding(dir) TimeRatio EUC_TW_OLD/x-EUC-TW: 17917,7431 :2.411116
>    Decoding(dir) TimeRatio EUC_TW_OLD/x-EUC-TW: 7966,6859 :1.161394
>
> SUPP -client
>    Encoding TimeRatio EUC_TW_OLD/x-EUC-TW: 72054,7165 :10.056385
>    Decoding TimeRatio EUC_TW_OLD/x-EUC-TW: 7912,5550 :1.425586
>    Encoding(dir) TimeRatio EUC_TW_OLD/x-EUC-TW: 78578,12924 :6.080006
>    Decoding(dir) TimeRatio EUC_TW_OLD/x-EUC-TW: 13198,11483 :1.149351
>
> Mixed -client
>    Encoding TimeRatio EUC_TW_OLD/x-EUC-TW: 73012,7499 :9.736231
>    Decoding TimeRatio EUC_TW_OLD/x-EUC-TW: 7952,5549 :1.433051
>    Encoding(dir) TimeRatio EUC_TW_OLD/x-EUC-TW: 77963,13116 :5.944114
>    Decoding(dir) TimeRatio EUC_TW_OLD/x-EUC-TW: 13139,11727 :1.120406
>
> BMP -server:
>    Encoding TimeRatio EUC_TW_OLD/x-EUC-TW: 13164,3479 :3.783846
>    Decoding TimeRatio EUC_TW_OLD/x-EUC-TW: 4703,2304 :2.041233
>    Encoding(dir) TimeRatio EUC_TW_OLD/x-EUC-TW: 13758,3572 :3.851624
>    Decoding(dir) TimeRatio EUC_TW_OLD/x-EUC-TW: 5370,3421 :1.569716
>
> SUPP -server
>    Encoding TimeRatio EUC_TW_OLD/x-EUC-TW: 67307,5540 :12.149278
>    Decoding TimeRatio EUC_TW_OLD/x-EUC-TW: 5825,4434 :1.313712
>    Encoding(dir) TimeRatio EUC_TW_OLD/x-EUC-TW: 68738,5710 :12.038179
>    Decoding(dir) TimeRatio EUC_TW_OLD/x-EUC-TW: 5980,4104 :1.457115
>
> Mixed -server
>    Encoding TimeRatio EUC_TW_OLD/x-EUC-TW: 67568,5465 :12.363769
>    Decoding TimeRatio EUC_TW_OLD/x-EUC-TW: 6323,4421 :1.430219
>    Encoding(dir) TimeRatio EUC_TW_OLD/x-EUC-TW: 68766,5767 :11.924051
>    Decoding(dir) TimeRatio EUC_TW_OLD/x-EUC-TW: 5637,4040 :1.395297
>
>



From Xueming.Shen at Sun.COM  Thu May 14 20:55:30 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Thu, 14 May 2009 13:55:30 -0700
Subject: Rewrite of EUC_TW
In-Reply-To: <4A0C8294.7020602@gmx.de>
References: <49FA9B45.8020802@sun.com> <4A075BD6.5020909@gmx.de>
	<4A09179D.1020308@sun.com> <4A09BF0B.60702@gmx.de>
	<4A09C096.8000505@sun.com>
	<4A09C748.6070302@gmx.de> <4A09CEBD.3050703@sun.com>
	<4A09FF75.4010400@gmx.de>
	<4A0A4197.4030503@sun.com> <4A0C8294.7020602@gmx.de>
Message-ID: <4A0C8542.10503@sun.com>

Thanks again for taking time on this. Here is the IBM db charsets webrev

http://cr.openjdk.java.net/~sherman/ibmdb/webrev

This is a bigger fish than the EUC_TW:-)

If you really want to see the performance difference, simply drop the 
EUC_TW.java, EUC_TWMapping.java
(I sent to you last time) into your ws/respository and build, or simply 
remove the package head and use a null
for the alias list in the construct,  and then run the TestEUC_TW.java 
against them.

Sherman


Ulf Zibis wrote:
>
>
> Regrettably I can't compare your results against the results from day 
> before (without the tweaks suggested from my side), as it seems you 
> have used different algorithm. :-(
>
> -Ulf
>
>
>> I simply ran the test case TestEUC_TW attached in the test case, set 
>> the iteration set to 200, run with
>> BMP characters only, supplementary characters only and mixed.
>>
>> http://cr.openjdk.java.net/~sherman/6831794_6229811/webrev/test/sun/nio/cs/TestEUC_TW.java.html 
>>
>>
>> Though this is not a real benchmark, the data does say something.
>>
>> BMP -client:
>>    Encoding TimeRatio EUC_TW_OLD/x-EUC-TW: 14178,3350 :4.232239
>>    Decoding TimeRatio EUC_TW_OLD/x-EUC-TW: 5061,3538 :1.430469
>>    Encoding(dir) TimeRatio EUC_TW_OLD/x-EUC-TW: 17917,7431 :2.411116
>>    Decoding(dir) TimeRatio EUC_TW_OLD/x-EUC-TW: 7966,6859 :1.161394
>>
>> SUPP -client
>>    Encoding TimeRatio EUC_TW_OLD/x-EUC-TW: 72054,7165 :10.056385
>>    Decoding TimeRatio EUC_TW_OLD/x-EUC-TW: 7912,5550 :1.425586
>>    Encoding(dir) TimeRatio EUC_TW_OLD/x-EUC-TW: 78578,12924 :6.080006
>>    Decoding(dir) TimeRatio EUC_TW_OLD/x-EUC-TW: 13198,11483 :1.149351
>>
>> Mixed -client
>>    Encoding TimeRatio EUC_TW_OLD/x-EUC-TW: 73012,7499 :9.736231
>>    Decoding TimeRatio EUC_TW_OLD/x-EUC-TW: 7952,5549 :1.433051
>>    Encoding(dir) TimeRatio EUC_TW_OLD/x-EUC-TW: 77963,13116 :5.944114
>>    Decoding(dir) TimeRatio EUC_TW_OLD/x-EUC-TW: 13139,11727 :1.120406
>>
>> BMP -server:
>>    Encoding TimeRatio EUC_TW_OLD/x-EUC-TW: 13164,3479 :3.783846
>>    Decoding TimeRatio EUC_TW_OLD/x-EUC-TW: 4703,2304 :2.041233
>>    Encoding(dir) TimeRatio EUC_TW_OLD/x-EUC-TW: 13758,3572 :3.851624
>>    Decoding(dir) TimeRatio EUC_TW_OLD/x-EUC-TW: 5370,3421 :1.569716
>>
>> SUPP -server
>>    Encoding TimeRatio EUC_TW_OLD/x-EUC-TW: 67307,5540 :12.149278
>>    Decoding TimeRatio EUC_TW_OLD/x-EUC-TW: 5825,4434 :1.313712
>>    Encoding(dir) TimeRatio EUC_TW_OLD/x-EUC-TW: 68738,5710 :12.038179
>>    Decoding(dir) TimeRatio EUC_TW_OLD/x-EUC-TW: 5980,4104 :1.457115
>>
>> Mixed -server
>>    Encoding TimeRatio EUC_TW_OLD/x-EUC-TW: 67568,5465 :12.363769
>>    Decoding TimeRatio EUC_TW_OLD/x-EUC-TW: 6323,4421 :1.430219
>>    Encoding(dir) TimeRatio EUC_TW_OLD/x-EUC-TW: 68766,5767 :11.924051
>>    Decoding(dir) TimeRatio EUC_TW_OLD/x-EUC-TW: 5637,4040 :1.395297
>>
>>
>



From Xueming.Shen at Sun.COM  Thu May 14 22:03:18 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Thu, 14 May 2009 15:03:18 -0700
Subject: Rewrite of IBM doublebyte charsets
In-Reply-To: <4A0C7E63.2010208@gmx.de>
References: <49FA9B45.8020802@sun.com> <4A075BD6.5020909@gmx.de>
	<4A09179D.1020308@sun.com> <4A09BF0B.60702@gmx.de>
	<4A09C096.8000505@sun.com> <4A0C7E63.2010208@gmx.de>
Message-ID: <4A0C9526.2010206@sun.com>

Ulf Zibis wrote:
> Am 12.05.2009 20:31, Xueming Shen schrieb:
>> Ulf Zibis wrote:
>>> Sherman,
>>> thanks for verifying my suggestions.
>>>
>>> > (1) simplify the "plane number" byte check by adding a new static 
>>> array of cnspToIndex[16] for decoder
>>>
>>> or simply:
>>>
>>>       static final byte[] cnspToIndex = new byte[0x100];
>>>       static {
>>>           Arrays.fill(cnspToIndex, -1);
>>>           cnspToIndex[0xa2] = 1; cnspToIndex[0xa3] = 2; 
>>> cnspToIndex[0xa4] = 3;
>>>           cnspToIndex[0xa5] = 4; cnspToIndex[0xa6] = 5; 
>>> cnspToIndex[0xa7] = 6; cnspToIndex[0xaf] = 7;
>>>       }
>>>
>>>            if ((cnsPlane = cnspToIndex[sa[sp + 1] && 0xff]) < 0)
>>>                return CoderResult.malformedForLength(2);
>>>
>> considered that, but ended up thinking it might not really worth the 
>> 0x100 bytes:-) at least based on my measurement.
>
> But I wonder, that you don't consider my XOR approach. The XOR needs 
> only to be computed once in contrast to 3 times computing AND + 
> comparing against -1 (needs load operation in contrast to compare '< 0')
>
>
What is the "XOR approach"? I might have miss it. I'm happy to try it 
out. OK, the "3 times computing" and "compare <0" are the good hint to 
improve, the
latest one looks like

 180                         int cnsPlane = sa[sp +1];
 181                         if ((cnsPlane & 0xf0) != 0xa0 ||
 182                             (cnsPlane = cnspToIndex[cnsPlane&0x0f]) < 0)
 183                             return CoderResult.malformedForLength(2);



And it definitely is better than the previous one, thanks! :-) Now maybe you might want to eye the
IBM db webrev, any change would benefit several charsets:-)

Sherman



From Ulf.Zibis at gmx.de  Thu May 14 22:45:43 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Fri, 15 May 2009 00:45:43 +0200
Subject: Rewrite of IBM doublebyte charsets
In-Reply-To: <4A0C9526.2010206@sun.com>
References: <49FA9B45.8020802@sun.com> <4A075BD6.5020909@gmx.de>
	<4A09179D.1020308@sun.com> <4A09BF0B.60702@gmx.de>
	<4A09C096.8000505@sun.com> <4A0C7E63.2010208@gmx.de>
	<4A0C9526.2010206@sun.com>
Message-ID: <4A0C9F17.3030305@gmx.de>

Am 15.05.2009 00:03, Xueming Shen schrieb:
>
> What is the "XOR approach"? I might have miss it. I'm happy to try it 
> out. OK, the "3 times computing" and "compare <0" are the good hint to 
> improve, the
> latest one looks like

I'm afraid, you really missed it. See my post from 12.05.2009 20:25 CEST 
;-)
I mean:

           int cnsPlane = sa[sp +1] ^ 0xa0;
           if (cnsPlane > 0xf || (cnsPlane = cnspToIndex[cnsPlane]) < 0)
               return CoderResult.malformedForLength(2);

or maybe (to force LoadUB (Bug ID 6797305), which may be faster than 
sign extension to int):
           int cnsPlane = (sa[sp +1] ^ 0xa0) && 0xff;

or maybe use byte[] (to force LoadUB, which may be faster than sign 
extension to int):
           byte cnsPlane = (byte)(sa[sp +1] ^ 0xa0);
or
           byte cnsPlane = (byte)((sa[sp +1] && 0xff) ^ (0xa0 && 0xff)); 
// don't know if this make a difference

But anyway, I think,
       static final byte[] cnspToIndex = new byte[0x100];
       ...

would be the fastest.

>
> 180                         int cnsPlane = sa[sp +1];

I guess this is worse, but definitely not better, than
        int cnsPlane = sa[sp +1] & 0xff;

Reason:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6797305

> 181                         if ((cnsPlane & 0xf0) != 0xa0 ||
> 182                             (cnsPlane = 
> cnspToIndex[cnsPlane&0x0f]) < 0)
> 183                             return CoderResult.malformedForLength(2);
>
>
>
> And it definitely is better than the previous one, thanks! :-) Now 
> maybe you might want to eye the
> IBM db webrev, any change would benefit several charsets:-)

... I'm doing that since 2 hours. :-)

-Ulf




From Xueming.Shen at Sun.COM  Thu May 14 23:48:49 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Thu, 14 May 2009 16:48:49 -0700
Subject: Rewrite of IBM doublebyte charsets
In-Reply-To: <4A0C9F17.3030305@gmx.de>
References: <49FA9B45.8020802@sun.com> <4A075BD6.5020909@gmx.de>
	<4A09179D.1020308@sun.com> <4A09BF0B.60702@gmx.de>
	<4A09C096.8000505@sun.com>
	<4A0C7E63.2010208@gmx.de> <4A0C9526.2010206@sun.com>
	<4A0C9F17.3030305@gmx.de>
Message-ID: <4A0CADE1.7070908@sun.com>

Ulf Zibis wrote:
> Am 15.05.2009 00:03, Xueming Shen schrieb:
>>
>> What is the "XOR approach"? I might have miss it. I'm happy to try it 
>> out. OK, the "3 times computing" and "compare <0" are the good hint 
>> to improve, the
>> latest one looks like
>
> I'm afraid, you really missed it. See my post from 12.05.2009 20:25 
> CEST ;-)
> I mean:
>
>           int cnsPlane = sa[sp +1] ^ 0xa0;
>           if (cnsPlane > 0xf || (cnsPlane = cnspToIndex[cnsPlane]) < 0)
>               return CoderResult.malformedForLength(2);
>
> or maybe (to force LoadUB (Bug ID 6797305), which may be faster than 
> sign extension to int):
>           int cnsPlane = (sa[sp +1] ^ 0xa0) && 0xff;
>
> or maybe use byte[] (to force LoadUB, which may be faster than sign 
> extension to int):
>           byte cnsPlane = (byte)(sa[sp +1] ^ 0xa0);
> or
>           byte cnsPlane = (byte)((sa[sp +1] && 0xff) ^ (0xa0 && 
> 0xff)); // don't know if this make a difference
>
> But anyway, I think,
>       static final byte[] cnspToIndex = new byte[0x100];
>       ...
>
> would be the fastest.
With the motivation of pushing you move on to the ibm charsets as quick 
as possible:-) I've tried both xor and the
byte[256]. since we have to do "int cnsPlane = (sa[sp +1] ^ 0xa0) && 
0xff;", (without & 0xff, you got a negative
sign extension), it is not faster than the existing one, actually my 
"not that accurate" benchmark shows it is slower...

The "static final byte[] cnspToIndex = new byte[0x100];" is slightly 
faster, the measurement shows about 3-5%
improvement of the decoding. So the webrev has been updated to go with 
this approach. Thanks!

Sherman


From tim.bell at sun.com  Fri May 15 19:13:37 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Fri, 15 May 2009 19:13:37 +0000
Subject: hg: jdk7/tl: Added tag jdk7-b58 for changeset 59b497130f82
Message-ID: <20090515191337.A0D2AEF4B@hg.openjdk.java.net>

Changeset: 030142474602
Author:    vasya
Date:      2009-05-11 12:08 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/030142474602

Added tag jdk7-b58 for changeset 59b497130f82

! .hgtags



From tim.bell at sun.com  Fri May 15 19:17:46 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Fri, 15 May 2009 19:17:46 +0000
Subject: hg: jdk7/tl/corba: Added tag jdk7-b58 for changeset 2e3b8edab3ef
Message-ID: <20090515191747.E4BDBEF50@hg.openjdk.java.net>

Changeset: 7e6b2b55c00c
Author:    vasya
Date:      2009-05-11 12:08 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/7e6b2b55c00c

Added tag jdk7-b58 for changeset 2e3b8edab3ef

! .hgtags



From tim.bell at sun.com  Fri May 15 19:23:31 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Fri, 15 May 2009 19:23:31 +0000
Subject: hg: jdk7/tl/hotspot: 27 new changesets
Message-ID: <20090515192424.B6861EF55@hg.openjdk.java.net>

Changeset: 313b56165de7
Author:    vasya
Date:      2009-05-11 12:08 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/313b56165de7

Added tag jdk7-b58 for changeset 53d9bf689e80

! .hgtags

Changeset: c8379544879a
Author:    ohair
Date:      2009-04-29 17:30 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c8379544879a

6831225: Upgrade JPRT jobs to use newer Linux 2.6 (e.g. Fedora 9)
Reviewed-by: kvn

- make/jprt.config
! make/jprt.properties

Changeset: 61c5604c8422
Author:    jcoomes
Date:      2009-04-30 09:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/61c5604c8422

Merge

- make/jprt.config

Changeset: 45463a04ca27
Author:    kvn
Date:      2009-04-29 12:58 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/45463a04ca27

6834177: Running jsynprog on Solaris Nevada can cause JVM crash
Summary: Use CodeCache buffer blob instead of static buffer in AdapterHandlerLibrary.
Reviewed-by: never

! src/share/vm/runtime/dtraceJSDT.cpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/sharedRuntime.hpp

Changeset: f36f12d01311
Author:    kvn
Date:      2009-04-30 12:09 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f36f12d01311

Merge


Changeset: af5d39ca39a3
Author:    kvn
Date:      2009-04-30 15:57 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/af5d39ca39a3

6835796: Fedora 9 linux_i586-fastdebug-c2-runThese_Xcomp times out
Summary: Switch off GCC 4.3.0 optimized compilation for mulnode.o.
Reviewed-by: johnc

! make/jprt.properties
! make/linux/makefiles/gcc.make

Changeset: 2b6c55e36143
Author:    tonyp
Date:      2009-04-23 16:58 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2b6c55e36143

6829013: G1: set the default value of G1VerifyConcMarkPrintRechable to false
Summary: Turn off G1VerifyConcMarkPrintReachable by default to minimize the amount of verbose output we generate by default.
Reviewed-by: jmasa

! src/share/vm/gc_implementation/g1/g1_globals.hpp
! src/share/vm/gc_implementation/g1/heapRegion.cpp

Changeset: 4753e4079a5a
Author:    apetrusenko
Date:      2009-04-27 12:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4753e4079a5a

Merge


Changeset: b803b1b9e206
Author:    iveresov
Date:      2009-04-27 16:52 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b803b1b9e206

6819098: G1: reduce RSet scanning times
Summary: Added a feedback-driven exponential skipping for parallel RSet scanning.
Reviewed-by: tonyp, apetrusenko

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

Changeset: 51285b431bb2
Author:    apetrusenko
Date:      2009-05-04 02:57 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/51285b431bb2

Merge


Changeset: 81a249214991
Author:    poonam
Date:      2009-05-04 17:58 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/81a249214991

6829234: Refix 6822407 and 6812971
Summary: Fixes two SA issues 6822407 and 6812971
Reviewed-by: swamyv, acorn, kvn, coleenp

! agent/src/share/classes/sun/jvm/hotspot/HotSpotTypeDataBase.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java

Changeset: c8f1f4de26c9
Author:    kamg
Date:      2009-05-07 11:44 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c8f1f4de26c9

Merge


Changeset: 20c6f43950b5
Author:    johnc
Date:      2009-04-30 15:07 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/20c6f43950b5

6490395: G1: Tidy up command line flags.
Summary: Change G1 flag names to be more consistent and disable some in 'product' mode.
Reviewed-by: tonyp, iveresov

! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp
! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp
! src/share/vm/gc_implementation/g1/g1RemSet.cpp
! src/share/vm/gc_implementation/g1/g1_globals.hpp
! src/share/vm/gc_implementation/g1/heapRegion.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp

Changeset: a2957df801a1
Author:    johnc
Date:      2009-05-05 22:15 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a2957df801a1

6833576: G1: assert illegal index, growableArray.hpp:186
Summary: The code that calculates the heap region index for an object address incorrectly used signed arithmetic.
Reviewed-by: jcoomes, ysr

! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp

Changeset: a58ad611cc63
Author:    jcoomes
Date:      2009-05-07 13:54 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a58ad611cc63

Merge


Changeset: 2b25645dab33
Author:    never
Date:      2009-05-04 22:06 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2b25645dab33

6837224: libsaproc.so on linux needs version of 6799141
Reviewed-by: kvn

! agent/src/os/linux/Makefile

Changeset: 36ee9b69616e
Author:    cfang
Date:      2009-05-05 11:02 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/36ee9b69616e

6833879: Assigning positive zero is ignored when old value is negative zero
Summary: Don't perform CMOVE identity optimization for floating point types
Reviewed-by: kvn, never

! src/share/vm/opto/connode.cpp

Changeset: cecd04fc6f93
Author:    twisti
Date:      2009-05-06 12:04 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/cecd04fc6f93

6837011: SIGSEGV in PhaseIdealLoop in 32bit jvm
Summary: The CR's test crashes with SIGSEGV when running with "-server -Xcomp" using using 32bit jvm.
Reviewed-by: kvn, never, rasbold

! src/share/vm/opto/divnode.cpp
+ test/compiler/6837011/Test6837011.java

Changeset: f96f285ed3dd
Author:    never
Date:      2009-05-06 17:52 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f96f285ed3dd

6838154: make/linux/makefiles/sa.make needs hash-style fix
Reviewed-by: kvn, jrose

! make/linux/makefiles/jsig.make
! make/linux/makefiles/saproc.make

Changeset: 9b3a41ccc927
Author:    kvn
Date:      2009-05-07 17:09 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9b3a41ccc927

Merge


Changeset: 8078631685e4
Author:    trims
Date:      2009-05-07 21:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8078631685e4

Merge

- make/jprt.config

Changeset: fede134842ab
Author:    trims
Date:      2009-05-07 21:35 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/fede134842ab

6838819: Bump the HS16 build number to 03
Summary: Update the HS16 build number to 03
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 622212a69394
Author:    iveresov
Date:      2009-05-08 15:20 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/622212a69394

6838842: NUMA allocator: Segfault during startup on Linux
Summary: Restored os::free_memory() semantics
Reviewed-by: apetrusenko

! src/os/linux/vm/os_linux.cpp

Changeset: 7e1dbef51011
Author:    trims
Date:      2009-05-08 19:50 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7e1dbef51011

Merge


Changeset: cf71f149d7ae
Author:    iveresov
Date:      2009-05-12 15:55 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/cf71f149d7ae

6840196: NUMA allocator: crash in fastdebug during startup on Linux
Summary: With libnuma >1.2 explicity use 1.1 symbols
Reviewed-by: ysr

! src/os/linux/vm/os_linux.cpp
! src/os/linux/vm/os_linux.hpp

Changeset: 07c1c01e0315
Author:    trims
Date:      2009-05-13 08:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/07c1c01e0315

Merge


Changeset: c55be0c7bd32
Author:    trims
Date:      2009-05-13 08:46 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c55be0c7bd32

Merge




From tim.bell at sun.com  Fri May 15 19:38:02 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Fri, 15 May 2009 19:38:02 +0000
Subject: hg: jdk7/tl/jaxp: Added tag jdk7-b58 for changeset 13bf67d8c634
Message-ID: <20090515193804.9CCFCEF5A@hg.openjdk.java.net>

Changeset: 75113d7ce083
Author:    vasya
Date:      2009-05-11 12:08 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/75113d7ce083

Added tag jdk7-b58 for changeset 13bf67d8c634

! .hgtags



From tim.bell at sun.com  Fri May 15 19:42:01 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Fri, 15 May 2009 19:42:01 +0000
Subject: hg: jdk7/tl/jaxws: Added tag jdk7-b58 for changeset 5fb4fbea81c3
Message-ID: <20090515194203.E4A4BEF5F@hg.openjdk.java.net>

Changeset: f64566bf4c2b
Author:    vasya
Date:      2009-05-11 12:08 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/f64566bf4c2b

Added tag jdk7-b58 for changeset 5fb4fbea81c3

! .hgtags



From tim.bell at sun.com  Fri May 15 19:46:18 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Fri, 15 May 2009 19:46:18 +0000
Subject: hg: jdk7/tl/jdk: 9 new changesets
Message-ID: <20090515194826.7AE35EF7C@hg.openjdk.java.net>

Changeset: 878863c9072d
Author:    vasya
Date:      2009-05-11 12:08 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/878863c9072d

Added tag jdk7-b58 for changeset 9ba256e2e5c1

! .hgtags

Changeset: 2007e3d9c195
Author:    anthony
Date:      2009-05-05 14:45 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2007e3d9c195

6762511: Translucency is not working on Linux using Metacity
Summary: Introduced additional blits and new X11 surface types (ARGB, ABGR)
Reviewed-by: art, avu

! src/solaris/classes/sun/awt/X11GraphicsConfig.java
! src/solaris/classes/sun/java2d/x11/X11PMBlitBgLoops.java
! src/solaris/classes/sun/java2d/x11/X11PMBlitLoops.java
! src/solaris/classes/sun/java2d/x11/X11SurfaceData.java
! src/solaris/native/sun/awt/X11Color.c
! src/solaris/native/sun/awt/awt_GraphicsEnv.c
! src/solaris/native/sun/awt/awt_p.h

Changeset: ba95c9101e50
Author:    art
Date:      2009-05-06 12:39 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ba95c9101e50

6837004: java.awt.GraphicsDevice.setFullScreenWindow throws NPE for windows with background color not set
Reviewed-by: yan, dcherepanov

! src/share/classes/java/awt/GraphicsDevice.java
+ test/java/awt/FullScreen/TranslucentWindow/TranslucentWindow.java

Changeset: b28b073e72b6
Author:    anthony
Date:      2009-05-06 20:06 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b28b073e72b6

6838046: Rollback 6762511 due to build failure (6838003)
Reviewed-by: yan

! src/solaris/classes/sun/awt/X11GraphicsConfig.java
! src/solaris/classes/sun/java2d/x11/X11PMBlitBgLoops.java
! src/solaris/classes/sun/java2d/x11/X11PMBlitLoops.java
! src/solaris/classes/sun/java2d/x11/X11SurfaceData.java
! src/solaris/native/sun/awt/X11Color.c
! src/solaris/native/sun/awt/awt_GraphicsEnv.c
! src/solaris/native/sun/awt/awt_p.h

Changeset: 2b86dbc51d11
Author:    yan
Date:      2009-05-06 09:37 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2b86dbc51d11

Merge


Changeset: 0c6f5f1c58fd
Author:    yan
Date:      2009-05-12 00:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0c6f5f1c58fd

Merge


Changeset: 2387e3b1994e
Author:    jrose
Date:      2009-05-11 21:09 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2387e3b1994e

6839802: java.dyn needs to be on the CORE_PKGS list
Summary: fix makefile to expose the new APIs in the core list; edit some javadocs for correctness
Reviewed-by: mr

! make/common/Release.gmk
! make/docs/CORE_PKGS.gmk
! src/share/classes/java/dyn/CallSite.java
! src/share/classes/java/dyn/InvokeDynamic.java
! src/share/classes/java/dyn/Linkage.java
! src/share/classes/java/dyn/MethodHandles.java
! src/share/classes/java/dyn/MethodType.java

Changeset: 29180ef374c8
Author:    jrose
Date:      2009-05-12 13:54 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/29180ef374c8

6839839: access checking logic is wrong at three points in MethodHandles
Summary: point fixes to access checking logic
Reviewed-by: mr

! src/share/classes/java/dyn/MethodHandles.java
! src/share/classes/sun/dyn/DirectMethodHandle.java
! src/share/classes/sun/dyn/MemberName.java
! src/share/classes/sun/dyn/MethodHandleImpl.java
! src/share/classes/sun/dyn/MethodHandleNatives.java
! src/share/classes/sun/dyn/util/VerifyAccess.java

Changeset: 2a5a1b269e89
Author:    xdono
Date:      2009-05-12 14:05 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2a5a1b269e89

Merge




From tim.bell at sun.com  Fri May 15 19:58:43 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Fri, 15 May 2009 19:58:43 +0000
Subject: hg: jdk7/tl/langtools: Added tag jdk7-b58 for changeset 5bcac54d408b
Message-ID: <20090515195844.CEE78EF83@hg.openjdk.java.net>

Changeset: 88bcb6772159
Author:    vasya
Date:      2009-05-11 12:08 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/88bcb6772159

Added tag jdk7-b58 for changeset 5bcac54d408b

! .hgtags



From Ulf.Zibis at gmx.de  Fri May 15 20:42:56 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Fri, 15 May 2009 22:42:56 +0200
Subject: Rewrite of EUC_TW
In-Reply-To: <4A0C8542.10503@sun.com>
References: <49FA9B45.8020802@sun.com> <4A075BD6.5020909@gmx.de>
	<4A09179D.1020308@sun.com> <4A09BF0B.60702@gmx.de>
	<4A09C096.8000505@sun.com> <4A09C748.6070302@gmx.de>
	<4A09CEBD.3050703@sun.com> <4A09FF75.4010400@gmx.de>
	<4A0A4197.4030503@sun.com> <4A0C8294.7020602@gmx.de>
	<4A0C8542.10503@sun.com>
Message-ID: <4A0DD3D0.1010206@gmx.de>

Sherman,

could you send/link me please generated DoubleByte-X.java files?

-Ulf


Am 14.05.2009 22:55, Xueming Shen schrieb:
> Thanks again for taking time on this. Here is the IBM db charsets webrev
>
> http://cr.openjdk.java.net/~sherman/ibmdb/webrev
>
> This is a bigger fish than the EUC_TW:-)
>
>



From Xueming.Shen at Sun.COM  Fri May 15 20:46:13 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Fri, 15 May 2009 13:46:13 -0700
Subject: Rewrite of EUC_TW
In-Reply-To: <4A0DD3D0.1010206@gmx.de>
References: <49FA9B45.8020802@sun.com> <4A075BD6.5020909@gmx.de>
	<4A09179D.1020308@sun.com> <4A09BF0B.60702@gmx.de>
	<4A09C096.8000505@sun.com>
	<4A09C748.6070302@gmx.de> <4A09CEBD.3050703@sun.com>
	<4A09FF75.4010400@gmx.de>
	<4A0A4197.4030503@sun.com> <4A0C8294.7020602@gmx.de>
	<4A0C8542.10503@sun.com> <4A0DD3D0.1010206@gmx.de>
Message-ID: <4A0DD495.1060405@sun.com>

http://cr.openjdk.java.net/~sherman/ibmdb/gensrc/ext/

Ulf Zibis wrote:
> Sherman,
>
> could you send/link me please generated DoubleByte-X.java files?
>
> -Ulf
>
>
> Am 14.05.2009 22:55, Xueming Shen schrieb:
>> Thanks again for taking time on this. Here is the IBM db charsets webrev
>>
>> http://cr.openjdk.java.net/~sherman/ibmdb/webrev
>>
>> This is a bigger fish than the EUC_TW:-)
>>
>>
>



From Ulf.Zibis at gmx.de  Sun May 17 18:19:28 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Sun, 17 May 2009 20:19:28 +0200
Subject: Rewrite of IBM doublebyte charsets
In-Reply-To: <4A0C8542.10503@sun.com>
References: <49FA9B45.8020802@sun.com> <4A075BD6.5020909@gmx.de>
	<4A09179D.1020308@sun.com> <4A09BF0B.60702@gmx.de>
	<4A09C096.8000505@sun.com> <4A09C748.6070302@gmx.de>
	<4A09CEBD.3050703@sun.com> <4A09FF75.4010400@gmx.de>
	<4A0A4197.4030503@sun.com> <4A0C8294.7020602@gmx.de>
	<4A0C8542.10503@sun.com>
Message-ID: <4A105530.80201@gmx.de>

Am 14.05.2009 22:55, Xueming Shen schrieb:
> Thanks again for taking time on this. Here is the IBM db charsets webrev
>
> http://cr.openjdk.java.net/~sherman/ibmdb/webrev
>
> This is a bigger fish than the EUC_TW:-)
>


*** Decoder-Suggestions:

(1) Unused imports in DoubleByte-X.java:
    import java.util.Arrays;
    import sun.nio.cs.StandardCharsets;
    import static sun.nio.cs.CharsetMapping.*;
    import sun.nio.cs.ext.DoubleByte;  // or instead: static 
sun.nio.cs.ext.DoubleByte.*;

(2) Please extract de/encoder classes to separate java file:
    In tabbed editor it's much more comfortable to select a tab, than 
scrolling 760 lines up and down.
      DoubleByteXcoder
      EBCDICXcoder
      DoubleByteOnlyXcoder
      EUCSimpleXcoder

(3) Modify dimension of b2c:
      char[][] b2c = new char[0x100][segSize];
    so decode :
      public char decodeDouble(int b1, int b2) {
          if ((b2-=b2Min) < 0 || b2 >= segSize)
              return UNMAPPABLE_DECODING;
          return b2c[b1][b2];
      }
   Benefit[1]: increase performance of decoder
   Benefit[2]: reduce memory of B2C_UNMAPPABLE from 8192 to 512 bytes
   Benefit[3]: some of b2c pages could be saved (if only containing \uFFFD)

(4) Don't care about b2Max (it's always not far from 0xff):
   Benefit[4]: another performance increase of decoder (only check: 
(b2-=b2Min) < 0)

(5) Truncate String segments (there are 65 % "\uFFFD" in IBM933):
    (fill b2c segments first with "\uFFFD", then initialize)
   Benefit[5]: save up to 180 % superfluous memory and disk-footprint

(6) Unload b2cStr from memory after startup:
    - outsource b2cStr to additional class file like EUC_TW approach
    - set b2cStr = null after startup (remove final modifier)
   Benefit[6]: avoid 100 % superfluous memory-footprint

(7) Avoid copying b2cStr to b2c:
    (String#charAt() is fast as char[] access)
   Benefit[7]: increase startup performance for decoder

(8) Truncate b2c segments (catch unmappable indexes by RuntimeException):
   Benefit[8]: save up to 180 % superfluous memory-footprint

(9) Share mappings (IBM930 and IBM939 are 99 % identical):
   Benefit[9]: save up to 99 % superfluous disk-footprint
   Benefit[10]: save up to 99 % superfluous memory-footprint (if both 
charsets are loaded)

(10) Provide 4-way fork from de/encodeLoop():
    See:  
https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/src/sun/nio/cs/SingleByteEncoder_new.java?rev=&view=markup
   Benefit[11]: increase performance, if there is only 1 direct buffer

(11) Quit coders xBufferLoop by exception on xflow:
   http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6806227
   Benefit[12]: increase performance

(12) Get rid of sun.io package dependency:
   
https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/tags/milestone2/src/sun/io/
   Benefit[13]: avoid superfluous disk-footprint
   Benefit[14]: save maintenance of sun.io converters
   Disadvantage[1]: published under JRL (waiting for launch of OpenJDK-7 
project "charset-enhancement") ;-)

(13) Take data files in account _once more_:
   Following upper suggestions, data files should be much more smaller 
than for EUC_TW,
   so loading time from jar by getResourceAsStream() could be 
acceptable. If some day
   Bug ID 6818736, 6818736 were solved, we could profit once more, 
without doing much.
   Benefit[15]: avoid 50 % superfluous disk-footprint
   Benefit[16]: sharing of map data for different charsets becomes more 
simple

(14) Split map data files into chunks and load lazy.
   TW native speakers must be consulted, to define reasonable chunks!
   Benefit[17]: save startup time
   Benefit[18]: save memory
   Benefit[19]: sharing of map data becomes much more simple

(15) Diff also IBM1381.java against IBM1383.java and see similarity

(16) decodeArrayLoop: shortcut calculation of limits:
      int sl = sp + src.remaining();
      int dl = dp + dst.remaining();

(17) Decoder#decodeArrayLoop: shortcut for single byte only:
      int sr = src.remaining();
      int sl = sp + sr;
      int dr = dst.remaining();
      int dl = dp + dr;
      // single byte only loop
      int slSB = sp + sr < dr ? sr : dr;
      while (sp < slSB) {
          char c = b2cSB[sa[sp] && 0xff];
          if (c == UNMAPPABLE_DECODING)
              break;
          da[dp++] = c;
          sp++;
      }
     Same for Encoder#encodeArrayLoop

(18) Decoder_EBCDIC: boolean singlebyteState:
      if (singlebyteState)
          ...

(19) Decoder_EBCDIC: decode single byte first:
      if (singlebyteState)
          c = b2cSB[b1];
      if (c == UNMAPPABLE_DECODING) {
          ...
      }
   Benefit[20]: should be faster


*** Encoder-Suggestions:

(21) join *.nr to *.c2b files (25->000a becomes 000a->fffd):
   Benefit[21]: reduce no. of files
   Benefit[22]: simplifies initC2B() (avoids 2 loops)

(22) Save c2b in 2-dimensional array:
     char[][] c2b = new char[0x100][]
     set unused segments to 256-size UNMAPPABLE_ENCODING[]
   Benefit[23]: save calculation of index in encodeChar() --> little faster
   Benefit[24]: initC2B() becomes faster
   - huge c2b[] is initialized twice, 1st with 0 (according JLS) + 2nd 
with UNMAPPABLE_ENCODING
   - only fill 256 bytes with UNMAPPABLE_ENCODING, and get copies by 
Arrays.copyOf()
   Benefit[25]: save c2bIndex

(23) Truncate c2b segments:
     c2b[x] = new char[usedLength]
     (usedLength values could be generated and saved in DoubleByte-X or 
data file)
   Benefit[26]: avoid superfluous memory and disk-footprint (I guess ~30 %)
   Benefit[27]: don't range-check in-segment index, catch unmappable 
index by IndexOutOfBoundsException

(24) Additionally truncate leading unmappables in c2b segments, and host 
offsets:
   Benefit[28]: avoid another superfluous memory and disk-footprint (I 
guess ~10 %)
   Disadvantage[21]: needs hosting of offsets: 256 bytes

(25) Concerning (23),(24): Check out best segment size (maybe 256 is not 
optimal):
   Benefit[29]: avoid another superfluous memory and disk-footprint (I 
guess 10-20 %)


-Ulf





From Ulf.Zibis at gmx.de  Sun May 17 19:04:49 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Sun, 17 May 2009 21:04:49 +0200
Subject: Rewrite of IBM doublebyte charsets
In-Reply-To: <4A0C8542.10503@sun.com>
References: <49FA9B45.8020802@sun.com> <4A075BD6.5020909@gmx.de>
	<4A09179D.1020308@sun.com> <4A09BF0B.60702@gmx.de>
	<4A09C096.8000505@sun.com> <4A09C748.6070302@gmx.de>
	<4A09CEBD.3050703@sun.com> <4A09FF75.4010400@gmx.de>
	<4A0A4197.4030503@sun.com> <4A0C8294.7020602@gmx.de>
	<4A0C8542.10503@sun.com>
Message-ID: <4A105FD1.4000202@gmx.de>

Am 14.05.2009 22:55, Xueming Shen schrieb:
> Thanks again for taking time on this. Here is the IBM db charsets webrev
>
> http://cr.openjdk.java.net/~sherman/ibmdb/webrev
>
> This is a bigger fish than the EUC_TW:-)
>


*** Encoder-Suggestions:

(26) Why copying String to char[] in initC2B(), String access should be same fast?:
      - char[] sb = b2cSB.toCharArray();
      - char[] db = b2c[i].toCharArray();

-Ulf






From Ulf.Zibis at gmx.de  Sun May 17 20:11:53 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Sun, 17 May 2009 22:11:53 +0200
Subject: Rewrite of IBM doublebyte charsets
In-Reply-To: <4A0CADE1.7070908@sun.com>
References: <49FA9B45.8020802@sun.com> <4A075BD6.5020909@gmx.de>
	<4A09179D.1020308@sun.com> <4A09BF0B.60702@gmx.de>
	<4A09C096.8000505@sun.com> <4A0C7E63.2010208@gmx.de>
	<4A0C9526.2010206@sun.com> <4A0C9F17.3030305@gmx.de>
	<4A0CADE1.7070908@sun.com>
Message-ID: <4A106F89.1070305@gmx.de>

Am 15.05.2009 01:48, Xueming Shen schrieb:
> Ulf Zibis wrote:
>> I mean:
>>
>>           int cnsPlane = sa[sp +1] ^ 0xa0;
>>           if (cnsPlane > 0xf || (cnsPlane = cnspToIndex[cnsPlane]) < 0)
>>               return CoderResult.malformedForLength(2);
>>
>> or maybe (to force LoadUB (Bug ID 6797305), which may be faster than 
>> sign extension to int):
>>           int cnsPlane = (sa[sp +1] ^ 0xa0) && 0xff;
>>
>> or maybe use byte[] (to force LoadUB, which may be faster than sign 
>> extension to int):
>>           byte cnsPlane = (byte)(sa[sp +1] ^ 0xa0);
>> or
>>           byte cnsPlane = (byte)((sa[sp +1] && 0xff) ^ (0xa0 && 
>> 0xff)); // don't know if this make a difference
>>
>> But anyway, I think,
>>       static final byte[] cnspToIndex = new byte[0x100];
>>       ...
>>
>> would be the fastest.
> With the motivation of pushing you move on to the ibm charsets as 
> quick as possible:-) I've tried both xor and the
> byte[256]. since we have to do "int cnsPlane = (sa[sp +1] ^ 0xa0) && 
> 0xff;", (without & 0xff, you got a negative
> sign extension),

Oops, it should be "int cnsPlane = (sa[sp +1] ^ (byte)0xa0);"

> it is not faster than the existing one, actually my "not that 
> accurate" benchmark shows it is slower...

Maybe XOR is not covered by Bug ID 6797305 ... Christian Thalinger?

-Ulf




From Ulf.Zibis at gmx.de  Sun May 17 20:29:20 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Sun, 17 May 2009 22:29:20 +0200
Subject: Rewrite of EUC_TW
In-Reply-To: <4A0C8542.10503@sun.com>
References: <49FA9B45.8020802@sun.com> <4A075BD6.5020909@gmx.de>
	<4A09179D.1020308@sun.com> <4A09BF0B.60702@gmx.de>
	<4A09C096.8000505@sun.com> <4A09C748.6070302@gmx.de>
	<4A09CEBD.3050703@sun.com> <4A09FF75.4010400@gmx.de>
	<4A0A4197.4030503@sun.com> <4A0C8294.7020602@gmx.de>
	<4A0C8542.10503@sun.com>
Message-ID: <4A1073A0.80208@gmx.de>

Am 14.05.2009 22:55, Xueming Shen schrieb:
> If you really want to see the performance difference, simply drop the 
> EUC_TW.java, EUC_TWMapping.java
> (I sent to you last time) into your ws/respository and build, or 
> simply remove the package head and use a null
> for the alias list in the construct,  and then run the TestEUC_TW.java 
> against them.

Unfortunately I'm working on a laptop, which throttles down CPU speed, 
when getting hot. So it is likely inaccurate, to compare absolute times 
from one run to another. :-(

Well, so it's ok to me, missing the gain in %.

-Ulf





From Xueming.Shen at Sun.COM  Sun May 17 21:00:14 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Sun, 17 May 2009 14:00:14 -0700
Subject: Rewrite of IBM doublebyte charsets
In-Reply-To: <4A105FD1.4000202@gmx.de>
References: <49FA9B45.8020802@sun.com> <4A075BD6.5020909@gmx.de>
	<4A09179D.1020308@sun.com> <4A09BF0B.60702@gmx.de>
	<4A09C096.8000505@sun.com>
	<4A09C748.6070302@gmx.de> <4A09CEBD.3050703@sun.com>
	<4A09FF75.4010400@gmx.de>
	<4A0A4197.4030503@sun.com> <4A0C8294.7020602@gmx.de>
	<4A0C8542.10503@sun.com> <4A105FD1.4000202@gmx.de>
Message-ID: <4A107ADE.2080208@sun.com>

Ulf Zibis wrote:
> Am 14.05.2009 22:55, Xueming Shen schrieb:
>> Thanks again for taking time on this. Here is the IBM db charsets webrev
>>
>> http://cr.openjdk.java.net/~sherman/ibmdb/webrev
>>
>> This is a bigger fish than the EUC_TW:-)
>>
>
>
> *** Encoder-Suggestions:
>
> (26) Why copying String to char[] in initC2B(), String access should 
> be same fast?:
>      - char[] sb = b2cSB.toCharArray();
>      - char[] db = b2c[i].toCharArray();
>
> -Ulf
>
>

because the b2c tables need to be updated before used to generate the 
c2b tables, if there is
a b2cNR table (means there are multiple "bytes" mapped to a single same 
"char", when do
c->b, we need to know which "bytes" to map to, this is done by specified 
that in .nr map). In
theory we need only do that if b2cNR presents, but I don't want to keep 
two paths. A possible
optimization is to pass in char[] instead of String, then only make a 
copy when necessary.



From tim.bell at sun.com  Mon May 18 08:37:37 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Mon, 18 May 2009 08:37:37 +0000
Subject: hg: jdk7/tl: Added tag jdk7-b59 for changeset 030142474602
Message-ID: <20090518083737.9B99DE13C@hg.openjdk.java.net>

Changeset: 0d76c4da605f
Author:    vasya
Date:      2009-05-14 10:57 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/0d76c4da605f

Added tag jdk7-b59 for changeset 030142474602

! .hgtags



From tim.bell at sun.com  Mon May 18 08:41:41 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Mon, 18 May 2009 08:41:41 +0000
Subject: hg: jdk7/tl/corba: Added tag jdk7-b59 for changeset 7e6b2b55c00c
Message-ID: <20090518084142.C15EBE149@hg.openjdk.java.net>

Changeset: e9ba2b962ddf
Author:    vasya
Date:      2009-05-14 10:57 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/e9ba2b962ddf

Added tag jdk7-b59 for changeset 7e6b2b55c00c

! .hgtags



From tim.bell at sun.com  Mon May 18 08:48:44 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Mon, 18 May 2009 08:48:44 +0000
Subject: hg: jdk7/tl/hotspot: Added tag jdk7-b59 for changeset c55be0c7bd32
Message-ID: <20090518084849.BC5E0E14F@hg.openjdk.java.net>

Changeset: aa0c48844632
Author:    vasya
Date:      2009-05-14 10:57 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/aa0c48844632

Added tag jdk7-b59 for changeset c55be0c7bd32

! .hgtags



From tim.bell at sun.com  Mon May 18 09:05:37 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Mon, 18 May 2009 09:05:37 +0000
Subject: hg: jdk7/tl/jaxp: Added tag jdk7-b59 for changeset 75113d7ce083
Message-ID: <20090518090539.3CCDAE154@hg.openjdk.java.net>

Changeset: 748976d69503
Author:    vasya
Date:      2009-05-14 10:58 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/748976d69503

Added tag jdk7-b59 for changeset 75113d7ce083

! .hgtags



From tim.bell at sun.com  Mon May 18 09:09:38 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Mon, 18 May 2009 09:09:38 +0000
Subject: hg: jdk7/tl/jaxws: Added tag jdk7-b59 for changeset f64566bf4c2b
Message-ID: <20090518090940.21E87E159@hg.openjdk.java.net>

Changeset: 4fa7398559d0
Author:    vasya
Date:      2009-05-14 10:58 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/4fa7398559d0

Added tag jdk7-b59 for changeset f64566bf4c2b

! .hgtags



From tim.bell at sun.com  Mon May 18 09:13:40 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Mon, 18 May 2009 09:13:40 +0000
Subject: hg: jdk7/tl/jdk: Added tag jdk7-b59 for changeset 2a5a1b269e89
Message-ID: <20090518091358.C223DE15E@hg.openjdk.java.net>

Changeset: 827a93c4d06a
Author:    vasya
Date:      2009-05-14 10:58 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/827a93c4d06a

Added tag jdk7-b59 for changeset 2a5a1b269e89

! .hgtags



From tim.bell at sun.com  Mon May 18 09:23:50 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Mon, 18 May 2009 09:23:50 +0000
Subject: hg: jdk7/tl/langtools: Added tag jdk7-b59 for changeset 88bcb6772159
Message-ID: <20090518092351.DE884E163@hg.openjdk.java.net>

Changeset: 0f653be1a42f
Author:    vasya
Date:      2009-05-14 10:58 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/0f653be1a42f

Added tag jdk7-b59 for changeset 88bcb6772159

! .hgtags



From Ulf.Zibis at gmx.de  Mon May 18 13:54:46 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Mon, 18 May 2009 15:54:46 +0200
Subject: Rewrite of IBM doublebyte charsets
In-Reply-To: <4A107ADE.2080208@sun.com>
References: <49FA9B45.8020802@sun.com> <4A075BD6.5020909@gmx.de>
	<4A09179D.1020308@sun.com> <4A09BF0B.60702@gmx.de>
	<4A09C096.8000505@sun.com> <4A09C748.6070302@gmx.de>
	<4A09CEBD.3050703@sun.com> <4A09FF75.4010400@gmx.de>
	<4A0A4197.4030503@sun.com> <4A0C8294.7020602@gmx.de>
	<4A0C8542.10503@sun.com> <4A105FD1.4000202@gmx.de>
	<4A107ADE.2080208@sun.com>
Message-ID: <4A1168A6.4090307@gmx.de>

Am 17.05.2009 23:00, Xueming Shen schrieb:
> Ulf Zibis wrote:
>> *** Encoder-Suggestions:
>>
>> (26) Why copying String to char[] in initC2B(), String access should 
>> be same fast?:
>>      - char[] sb = b2cSB.toCharArray();
>>      - char[] db = b2c[i].toCharArray();
>>
>> -Ulf
>>
>>
>
> because the b2c tables need to be updated before used to generate the 
> c2b tables, if there is
> a b2cNR table (means there are multiple "bytes" mapped to a single 
> same "char", when do
> c->b, we need to know which "bytes" to map to, this is done by 
> specified that in .nr map). In
> theory we need only do that if b2cNR presents, but I don't want to 
> keep two paths. A possible
> optimization is to pass in char[] instead of String, then only make a 
> copy when necessary.

Oops, yes, it was late after hours of thinking digital.

While thinking, why I didn't have this problem in my code....
   I didn't have to manipulate the b2c map, as I transformed all the 
NR's to the *.irregularities map file, which you called *.c2b, which is 
in fact an overwriting of the from b2c generated c2b map. (BTW, in *.nr 
the 2nd value is redundant and could be saved)
So if we have
    15 --> 000A
    25 --> 000A
in *.map, instead of
    25 (--> 000A)
in *.nr, we could have
    15 <-- 000A
in *.c2b

So avoiding the copying of the whole b2c map should be an additional 
sincere argument for my suggestion (21), which I must correct:

(21) join *.nr to *.c2b files (25->000a becomes 000a->15):
   Benefit[21]: reduce no. of files
   Benefit[22]: simplifies initC2B() (avoids 2 loops + saves copying the 
whole b2c map)

-Ulf






From Christian.Thalinger at Sun.COM  Mon May 18 15:03:30 2009
From: Christian.Thalinger at Sun.COM (Christian Thalinger)
Date: Mon, 18 May 2009 17:03:30 +0200
Subject: Rewrite of IBM doublebyte charsets
In-Reply-To: <4A106F89.1070305@gmx.de>
References: <49FA9B45.8020802@sun.com> <4A075BD6.5020909@gmx.de>
	<4A09179D.1020308@sun.com> <4A09BF0B.60702@gmx.de>
	<4A09C096.8000505@sun.com>
	<4A0C7E63.2010208@gmx.de> <4A0C9526.2010206@sun.com>
	<4A0C9F17.3030305@gmx.de>
	<4A0CADE1.7070908@sun.com> <4A106F89.1070305@gmx.de>
Message-ID: <1242659010.29179.34.camel@macbook>

On Sun, 2009-05-17 at 22:11 +0200, Ulf Zibis wrote:
> > it is not faster than the existing one, actually my "not that 
> > accurate" benchmark shows it is slower...
> 
> Maybe XOR is not covered by Bug ID 6797305 ... Christian Thalinger?

No, it's not covered.  There is not really a possible performance win.

-- Christian



From Ulf.Zibis at gmx.de  Mon May 18 17:13:56 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Mon, 18 May 2009 19:13:56 +0200
Subject: OpenJDK 7 project 'charset-enhancement'
Message-ID: <4A119754.3050207@gmx.de>

Hi all,

I guess, you have noticed, that since some time I'm working on enhancing 
the JDK's charset de/encoding: 
https://java-nio-charset-enhanced.dev.java.net/.

Dalibor Topic and Martin Buchholz have suggested to create a new OpenJDK 
7 project to make those enhancements available for OpenJDK 7 under GPL.

It should cover following topics:
- enhancing performance
- reducing disk-footprint
- reducing memory consumption
- discussing different strategies to serve differing frequency of 
occurrence of characters in charsets
- discussing coder result accuracy against compatibility of legacy behaviour
- extending functionality, e.g.:
- - adding short cut methods to speed up direct array access
- - adding short cut for replacement coders
- - adding methods to terminate the decoding on occurrence of exclusive 
cipher. See: Bug 6695386
- providing wrapper to replace converter classes from sun.io package

The project should be a clone from jdk7/tl/jdk tree.

In near future there should be a survey about launching this project.

Regards,

Ulf Zibis





From linuxhippy at gmail.com  Mon May 18 17:21:50 2009
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Mon, 18 May 2009 13:21:50 -0400
Subject: Inflater/Deflater improvements
In-Reply-To: <1ccfd1c10905041438h78dbcbb0i6c200ddc822861b2@mail.gmail.com>
References: <194f62550905040228p49bab23bl2e1132203584e723@mail.gmail.com>
	<1ccfd1c10905041438h78dbcbb0i6c200ddc822861b2@mail.gmail.com>
Message-ID: <194f62550905181021qb4cccbegc4d84a3ac27604ff@mail.gmail.com>

Hi Martin,

> I think many people will be interested in performance improvements
> in Inflater/Deflater. ?I may have time to help review.
>
> Caution: This is an area where it can be very tricky to make
> improvements. ?Past efforts have optimized one usage pattern
> at the cost of pessimizing another.

I can't imagine a use-case where this version would perform a lot
worse, however a clear downside is for sure the larger amount of
C-heap consumed.
However the current implementation is so bad, it should be worth it ;)
I am more afraid of behaviour change in corner cases ...

Thanks, Clemens


From Ulf.Zibis at gmx.de  Mon May 18 18:00:47 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Mon, 18 May 2009 20:00:47 +0200
Subject: Inflater/Deflater improvements
In-Reply-To: <1ccfd1c10905041438h78dbcbb0i6c200ddc822861b2@mail.gmail.com>
References: <194f62550905040228p49bab23bl2e1132203584e723@mail.gmail.com>
	<1ccfd1c10905041438h78dbcbb0i6c200ddc822861b2@mail.gmail.com>
Message-ID: <4A11A24F.9090702@gmx.de>

Am 04.05.2009 23:38, Martin Buchholz schrieb:
> I think many people will be interested in performance improvements
> in Inflater/Deflater.  I may have time to help review.
>   

Yes, there is also interest from charset de/encoding side. See:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6818736
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6818737

Current charset mapping tables are hosted as huge String constants 
inside charset classes. Hosting them as resource data files would would 
avoid ~50 % disk-footprint wastage of the charsets.jar. Additionally 
sharing of overlapping charset mapping data would become manageable. 
Currently we only have ClassLoader#getResouceAsStream() to load such 
data files, but we can't use it, because the underlying buffered stream 
is too slow in respect of JVM startup time. We need fast nio direct 
buffer access via java.nio.channels.Channel to load the data from 
charsets.jar.

So improving performance of jar/zip file access would be much 
appreciated. :-)

-Ulf




From linuxhippy at gmail.com  Mon May 18 19:03:02 2009
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Mon, 18 May 2009 15:03:02 -0400
Subject: Inflater/Deflater improvements
In-Reply-To: <4A11A24F.9090702@gmx.de>
References: <194f62550905040228p49bab23bl2e1132203584e723@mail.gmail.com>
	<1ccfd1c10905041438h78dbcbb0i6c200ddc822861b2@mail.gmail.com>
	<4A11A24F.9090702@gmx.de>
Message-ID: <194f62550905181203m4e7be163k3f57ef68f78241a2@mail.gmail.com>

Hi Ulf,

I don't think the JVM uses the Inflater/Deflater classes directly, but
instead accesses zblib directly - but I could be wrong.
Furthermore as far as I know charsets.jar isn't compressed.

The patches only try to remove some horrible memcpy overhead in some
common situation.

- Clemens

2009/5/18 Ulf Zibis <Ulf.Zibis at gmx.de>:
> Am 04.05.2009 23:38, Martin Buchholz schrieb:
>>
>> I think many people will be interested in performance improvements
>> in Inflater/Deflater. ?I may have time to help review.
>>
>
> Yes, there is also interest from charset de/encoding side. See:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6818736
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6818737
>
> Current charset mapping tables are hosted as huge String constants inside
> charset classes. Hosting them as resource data files would would avoid ~50 %
> disk-footprint wastage of the charsets.jar. Additionally sharing of
> overlapping charset mapping data would become manageable. Currently we only
> have ClassLoader#getResouceAsStream() to load such data files, but we can't
> use it, because the underlying buffered stream is too slow in respect of JVM
> startup time. We need fast nio direct buffer access via
> java.nio.channels.Channel to load the data from charsets.jar.
>
> So improving performance of jar/zip file access would be much appreciated.
> :-)
>
> -Ulf
>
>
>


From Xueming.Shen at Sun.COM  Mon May 18 20:21:25 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Mon, 18 May 2009 13:21:25 -0700
Subject: Inflater/Deflater improvements
In-Reply-To: <4A11A24F.9090702@gmx.de>
References: <194f62550905040228p49bab23bl2e1132203584e723@mail.gmail.com>
	<1ccfd1c10905041438h78dbcbb0i6c200ddc822861b2@mail.gmail.com>
	<4A11A24F.9090702@gmx.de>
Message-ID: <4A11C345.1060704@sun.com>


Performance of Inflater/Deflater does not change the class loading 
performance from
jar files bundled with JDK/JRE, they have been "uncompressed" after 
installation...

Sherman

Ulf Zibis wrote:
> Am 04.05.2009 23:38, Martin Buchholz schrieb:
>> I think many people will be interested in performance improvements
>> in Inflater/Deflater.  I may have time to help review.
>>   
>
> Yes, there is also interest from charset de/encoding side. See:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6818736
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6818737
>
> Current charset mapping tables are hosted as huge String constants 
> inside charset classes. Hosting them as resource data files would 
> would avoid ~50 % disk-footprint wastage of the charsets.jar. 
> Additionally sharing of overlapping charset mapping data would become 
> manageable. Currently we only have ClassLoader#getResouceAsStream() to 
> load such data files, but we can't use it, because the underlying 
> buffered stream is too slow in respect of JVM startup time. We need 
> fast nio direct buffer access via java.nio.channels.Channel to load 
> the data from charsets.jar.
>
> So improving performance of jar/zip file access would be much 
> appreciated. :-)
>
> -Ulf
>
>



From Xueming.Shen at Sun.COM  Mon May 18 21:07:33 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Mon, 18 May 2009 14:07:33 -0700
Subject: Inflater/Deflater improvements
In-Reply-To: <194f62550905181021qb4cccbegc4d84a3ac27604ff@mail.gmail.com>
References: <194f62550905040228p49bab23bl2e1132203584e723@mail.gmail.com>
	<1ccfd1c10905041438h78dbcbb0i6c200ddc822861b2@mail.gmail.com>
	<194f62550905181021qb4cccbegc4d84a3ac27604ff@mail.gmail.com>
Message-ID: <4A11CE15.6050409@sun.com>

Clemens,

If I read the code correctly, what your patch is trying to address is to 
save the redundant
memory allocate/free operations at native level, if the input byte 
buffer is bigger than the
"stride" size? In other words, it does not really reduce any memory copy 
but reduce the
trip numbers of java<->native. Am I reading the code correctly? I will 
take a second
round of read later...

Couple months ago I also tried some experimental code on the zip 
package, then I got
detoured to something else:-( maybe it's the time to revisit it, 
together with your code.

What I was trying to do is to pull as much as the native stuff to the 
java level...and to
use the ByteBuffer instead of byte[], in which we might get the chance 
to really reduce
the copy of data, if the input ByteBuffer is a direct bytebuffer...there 
was a nasty bug
somewhere in the code I did not have time to figure out back then tough. 
The snapshot
of part of the code is at

http://cr.openjdk.java.net/~sherman/deflater2/webrev/

Just tried to share some idea for discussion.

Sherman


Clemens Eisserer wrote:
> Hi Martin,
>
>   
>> I think many people will be interested in performance improvements
>> in Inflater/Deflater.  I may have time to help review.
>>
>> Caution: This is an area where it can be very tricky to make
>> improvements.  Past efforts have optimized one usage pattern
>> at the cost of pessimizing another.
>>     
>
> I can't imagine a use-case where this version would perform a lot
> worse, however a clear downside is for sure the larger amount of
> C-heap consumed.
> However the current implementation is so bad, it should be worth it ;)
> I am more afraid of behaviour change in corner cases ...
>
> Thanks, Clemens
>   



From Ulf.Zibis at gmx.de  Tue May 19 00:11:28 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Tue, 19 May 2009 02:11:28 +0200
Subject: Inflater/Deflater improvements
In-Reply-To: <194f62550905181203m4e7be163k3f57ef68f78241a2@mail.gmail.com>
References: <194f62550905040228p49bab23bl2e1132203584e723@mail.gmail.com>	
	<1ccfd1c10905041438h78dbcbb0i6c200ddc822861b2@mail.gmail.com>	
	<4A11A24F.9090702@gmx.de>
	<194f62550905181203m4e7be163k3f57ef68f78241a2@mail.gmail.com>
Message-ID: <4A11F930.2030001@gmx.de>

Clemens, Sherman,

you are right. Oops!

But there is another bottleneck, where both are concerned from:
If used by ZipFile#getInputStream(ZipEntry entry), the underlying 
BufferedInputStream is very slow because of internal copying.
I'm sure, direct ByteBuffer, served from getChannel(ZipEntry entry), 
would be faster. ;-)

-Ulf


Am 18.05.2009 21:03, Clemens Eisserer schrieb:
> Hi Ulf,
>
> I don't think the JVM uses the Inflater/Deflater classes directly, but
> instead accesses zblib directly - but I could be wrong.
> Furthermore as far as I know charsets.jar isn't compressed.
>
> The patches only try to remove some horrible memcpy overhead in some
> common situation.
>
> - Clemens
>
> 2009/5/18 Ulf Zibis <Ulf.Zibis at gmx.de>:
>   
>> Am 04.05.2009 23:38, Martin Buchholz schrieb:
>>     
>>> I think many people will be interested in performance improvements
>>> in Inflater/Deflater.  I may have time to help review.
>>>
>>>       
>> Yes, there is also interest from charset de/encoding side. See:
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6818736
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6818737
>>
>> Current charset mapping tables are hosted as huge String constants inside
>> charset classes. Hosting them as resource data files would would avoid ~50 %
>> disk-footprint wastage of the charsets.jar. Additionally sharing of
>> overlapping charset mapping data would become manageable. Currently we only
>> have ClassLoader#getResouceAsStream() to load such data files, but we can't
>> use it, because the underlying buffered stream is too slow in respect of JVM
>> startup time. We need fast nio direct buffer access via
>> java.nio.channels.Channel to load the data from charsets.jar.
>>
>> So improving performance of jar/zip file access would be much appreciated.
>> :-)
>>
>> -Ulf
>>
>>
>>
>>     
>
>
>   



From Ulf.Zibis at gmx.de  Tue May 19 00:15:17 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Tue, 19 May 2009 02:15:17 +0200
Subject: Inflater/Deflater improvements
In-Reply-To: <4A11C345.1060704@sun.com>
References: <194f62550905040228p49bab23bl2e1132203584e723@mail.gmail.com>
	<1ccfd1c10905041438h78dbcbb0i6c200ddc822861b2@mail.gmail.com>
	<4A11A24F.9090702@gmx.de> <4A11C345.1060704@sun.com>
Message-ID: <4A11FA15.5060108@gmx.de>

But remember, the my interest in this discussion is not class loading 
speed, it's resource file loading speed. ;-)

-Ulf


Am 18.05.2009 22:21, Xueming Shen schrieb:
>
> Performance of Inflater/Deflater does not change the class loading 
> performance from
> jar files bundled with JDK/JRE, they have been "uncompressed" after 
> installation...
>
> Sherman
>
> Ulf Zibis wrote:
>> Am 04.05.2009 23:38, Martin Buchholz schrieb:
>>> I think many people will be interested in performance improvements
>>> in Inflater/Deflater.  I may have time to help review.
>>>   
>>
>> Yes, there is also interest from charset de/encoding side. See:
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6818736
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6818737
>>
>> Current charset mapping tables are hosted as huge String constants 
>> inside charset classes. Hosting them as resource data files would 
>> would avoid ~50 % disk-footprint wastage of the charsets.jar. 
>> Additionally sharing of overlapping charset mapping data would become 
>> manageable. Currently we only have ClassLoader#getResouceAsStream() 
>> to load such data files, but we can't use it, because the underlying 
>> buffered stream is too slow in respect of JVM startup time. We need 
>> fast nio direct buffer access via java.nio.channels.Channel to load 
>> the data from charsets.jar.
>>
>> So improving performance of jar/zip file access would be much 
>> appreciated. :-)
>>
>> -Ulf
>>
>>
>
>



From Ulf.Zibis at gmx.de  Tue May 19 00:37:38 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Tue, 19 May 2009 02:37:38 +0200
Subject: Rewrite of IBM doublebyte charsets
In-Reply-To: <4A0C8F42.9040106@sun.com>
References: <49FA9B45.8020802@sun.com> <4A075BD6.5020909@gmx.de>
	<4A09179D.1020308@sun.com> <4A0C88B0.9000600@gmx.de>
	<4A0C8F42.9040106@sun.com>
Message-ID: <4A11FF52.3050708@gmx.de>

Am 14.05.2009 23:38, Xueming Shen schrieb:
> Ulf,
>
> There are 3 goals of this re-writing
> (1)shrink the storage size of the EUC_TW to a reasonable number
> (2)move away from hard-coding the mapping data in the source file to a 
> mapping based-build time built approach
> for easy maintenance in the future.
> (3)no regression on decoding, encoding performance, decoder startup 
> and resulting CoderResult when compared
> to the existing implementation, with the exception of encoder startup 
> (we need to build it from the b2c).
>
> So far I'm happy to see all of them are archived. I'm not targeting to 
> have a perfect one (actually the purpose of
> goal of (2) is to make it easier for future tuning.).

Yes, the map files are good start point for future tuning.

>
> I would not try to argue which cr is more appropriate, unmappable or 
> malformed, it's hard to draw the line, some
> codepage/charset set leave some codepoint for future use, private use, 
> user-defined characters, you can't not make
> the decision based on simply looking at the mapping table, you need to 
> have a standard on your desk to check
> segment by segment, and in fact personally I don't think it really 
> makes too much sense to distinguish these two. So
> I would like to follow the existing behavior, is possible.
>

Mainly I agree with you and I guess, most users don't care about this 
difference, so the wouldn't run into compatibility problems, if only 
checking CoderResult#isError(), but I think, that users, who are 
interested in this difference, they should get most accurate results, 
regardless, if former implementations have been malicious.


Hope, you are inspired by my suggestions from yesterday ;-)

-Ulf




From Ulf.Zibis at gmx.de  Tue May 19 10:02:51 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Tue, 19 May 2009 12:02:51 +0200
Subject: Rewrite of IBM doublebyte charsets
In-Reply-To: <4A125D72.5080509@sun.com>
References: <49FA9B45.8020802@sun.com> <4A075BD6.5020909@gmx.de>
	<4A09179D.1020308@sun.com> <4A0C88B0.9000600@gmx.de>
	<4A0C8F42.9040106@sun.com> <4A11FF52.3050708@gmx.de>
	<4A125D72.5080509@sun.com>
Message-ID: <4A1283CB.80906@gmx.de>

Am 19.05.2009 09:19, Xueming Shen schrieb:
> I will try the b2c[0x100][] idea to see the
> performance...I actually tried b2cIndex[0x100] +  b2c[], which did not 
> bring me the performance
> I expected, but that was a long time ago, so this time might be 
> different:-)

Even if there is no performance gain, the code will become more 
readable, and initC2B becomes more simple.
Additionally, when doing research on the generated source files (e.g. 
visual diff between different charsets), interpretation of the data 
becomes much more simple, as there would be exactly 1 String element for 
1 mapping segment, always starting at it's b2Min value as first left 
value of each chunk.
With that help, if would be easy to discover similar mapping for later 
tuning regarding sharing maps partly. :-)

Don't forget to try
    char c = b2cStr[byte1].charAt(byte2);
, using
    String[] b2cStr = new String[0x100];
, to avoid copying String[] to char[][].

-Ulf




From Tim.Bell at Sun.COM  Tue May 19 16:59:29 2009
From: Tim.Bell at Sun.COM (Tim Bell)
Date: Tue, 19 May 2009 09:59:29 -0700
Subject: TL is open for M4 work
In-Reply-To: <4A12D8D6.2030106@sun.com>
References: <A2917AE2-A3A3-42AB-9B62-AEA69D1C3F6C@Sun.COM>
	<4A12D810.1060208@sun.com> <4A12D8D6.2030106@sun.com>
Message-ID: <4A12E571.3000606@sun.com>

Joseph D. Darcy wrote:

> You may want to send out an "all clear" on this point to let everyone 
> know TL is again open for normal business.

"all clear".  TL is open for b61 at this point.  b60 is reserved for 
last-minute surprises in the JavaOne preview release, in case some high 
priority issue comes along.

The integration schedule is here:

    http://openjdk.java.net/projects/jdk7/builds/

Check the schedule for updates as we move forward.  There may still be 
changes due to JavaOne - in my past experience we don't promote anything 
during JavaOne.

For any week where TL/JSN is listed on the calendar (see above), I
freeze for PIT builds at 10PM (Pacific time) on the Monday of that
week.  If you want changes in that build you need to push them before
10PM PT on Monday.

Tim


From jonathan.gibbons at sun.com  Tue May 19 18:31:30 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Tue, 19 May 2009 18:31:30 +0000
Subject: hg: jdk7/tl/langtools: 6841422: classfile: add Type visitor
Message-ID: <20090519183131.D7C47E3A2@hg.openjdk.java.net>

Changeset: b5872f0790e7
Author:    jjg
Date:      2009-05-19 11:27 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/b5872f0790e7

6841422: classfile: add Type visitor
Reviewed-by: mcimadamore
Contributed-by: kevin.t.looney at sun.com

! src/share/classes/com/sun/tools/classfile/Type.java



From jonathan.gibbons at sun.com  Tue May 19 18:37:40 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Tue, 19 May 2009 18:37:40 +0000
Subject: hg: jdk7/tl/langtools: 6841420: classfile: add new methods to
	ConstantClassInfo
Message-ID: <20090519183741.C8459E3AD@hg.openjdk.java.net>

Changeset: f838537fb1ac
Author:    jjg
Date:      2009-05-19 11:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/f838537fb1ac

6841420: classfile: add new methods to ConstantClassInfo
Reviewed-by: mcimadamore
Contributed-by: kevin.t.looney at sun.com

! src/share/classes/com/sun/tools/classfile/ConstantPool.java



From jonathan.gibbons at sun.com  Tue May 19 18:48:20 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Tue, 19 May 2009 18:48:20 +0000
Subject: hg: jdk7/tl/langtools: 6841419: classfile: add constant pool iterator
Message-ID: <20090519184822.69DBCE3B2@hg.openjdk.java.net>

Changeset: fc634a593812
Author:    jjg
Date:      2009-05-19 11:43 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/fc634a593812

6841419: classfile: add constant pool iterator
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/classfile/ClassTranslator.java
! src/share/classes/com/sun/tools/classfile/ClassWriter.java
! src/share/classes/com/sun/tools/classfile/ConstantPool.java



From jonathan.gibbons at sun.com  Tue May 19 18:55:25 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Tue, 19 May 2009 18:55:25 +0000
Subject: hg: jdk7/tl/langtools: 6824493: experimental support for additional
	info for instructions
Message-ID: <20090519185527.8E2DFE3C5@hg.openjdk.java.net>

Changeset: cd0630109de5
Author:    jjg
Date:      2009-05-19 11:50 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/cd0630109de5

6824493: experimental support for additional info for instructions
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/classfile/StackMapTable_attribute.java
! src/share/classes/com/sun/tools/javap/BasicWriter.java
! src/share/classes/com/sun/tools/javap/ClassWriter.java
! src/share/classes/com/sun/tools/javap/CodeWriter.java
+ src/share/classes/com/sun/tools/javap/InstructionDetailWriter.java
! src/share/classes/com/sun/tools/javap/JavapTask.java
+ src/share/classes/com/sun/tools/javap/Messages.java
! src/share/classes/com/sun/tools/javap/Options.java
+ src/share/classes/com/sun/tools/javap/SourceWriter.java
+ src/share/classes/com/sun/tools/javap/StackMapWriter.java
+ src/share/classes/com/sun/tools/javap/TryBlockWriter.java
! src/share/classes/com/sun/tools/javap/resources/javap.properties
+ test/tools/javap/T6824493.java



From jonathan.gibbons at sun.com  Tue May 19 20:57:44 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Tue, 19 May 2009 20:57:44 +0000
Subject: hg: jdk7/tl/langtools: 6843013: missing files in fix for 6824493
Message-ID: <20090519205746.0F70BE40F@hg.openjdk.java.net>

Changeset: 0c6cd88f72b9
Author:    jjg
Date:      2009-05-19 13:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/0c6cd88f72b9

6843013: missing files in fix for 6824493
Reviewed-by: darcy

+ src/share/classes/com/sun/tools/javap/LocalVariableTableWriter.java
+ src/share/classes/com/sun/tools/javap/LocalVariableTypeTableWriter.java



From jonathan.gibbons at sun.com  Tue May 19 22:11:48 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Tue, 19 May 2009 22:11:48 +0000
Subject: hg: jdk7/tl/langtools: 6832154: refactor Paths to be just a utility
	class for JavacFileManager
Message-ID: <20090519221150.19110E41D@hg.openjdk.java.net>

Changeset: 4ce1c1400334
Author:    jjg
Date:      2009-05-19 15:07 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/4ce1c1400334

6832154: refactor Paths to be just a utility class for JavacFileManager
Reviewed-by: darcy

! src/share/classes/com/sun/tools/apt/main/Main.java
! src/share/classes/com/sun/tools/javac/file/Paths.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java



From xueming.shen at sun.com  Tue May 19 22:36:24 2009
From: xueming.shen at sun.com (xueming.shen at sun.com)
Date: Tue, 19 May 2009 22:36:24 +0000
Subject: hg: jdk7/tl/jdk: 6831794: charset EUC_TW is 12.6% of the total size
	of charsets.jar; ...
Message-ID: <20090519223635.EBDE4E425@hg.openjdk.java.net>

Changeset: 842fb12a21d7
Author:    sherman
Date:      2009-05-19 15:25 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/842fb12a21d7

6831794: charset EUC_TW is 12.6% of the total size of charsets.jar
6229811: Several codepoints in EUC_TW failed in roundtrip conversion
Summary: Re-write EUC_TW charset to address the size and roundtrip issue.
Reviewed-by: alanb

! make/java/nio/Makefile
! make/sun/Makefile
! make/sun/nio/FILES_java.gmk
! make/sun/nio/Makefile
! make/tools/CharsetMapping/Makefile
! make/tools/src/build/tools/charsetmapping/CharsetMapping.java
! make/tools/src/build/tools/charsetmapping/GenerateMapping.java
! make/tools/src/build/tools/charsetmapping/GenerateSBCS.java
! src/share/classes/sun/io/ByteToCharEUC_TW.java
! src/share/classes/sun/io/CharToByteEUC_TW.java
! src/share/classes/sun/nio/cs/ext/EUC_TW.java
! src/share/classes/sun/nio/cs/ext/ISO2022.java
! src/share/classes/sun/nio/cs/ext/ISO2022_CN.java
! src/solaris/classes/sun/awt/motif/X11CNS11643.java
! test/sun/nio/cs/TestISO2022CNDecoder.java



From xueming.shen at sun.com  Tue May 19 23:08:10 2009
From: xueming.shen at sun.com (xueming.shen at sun.com)
Date: Tue, 19 May 2009 23:08:10 +0000
Subject: hg: jdk7/tl/jdk: 6843079: Putback for the new EUC_TW is not complete
Message-ID: <20090519230822.4C0B3E438@hg.openjdk.java.net>

Changeset: 72e4312ea1e0
Author:    sherman
Date:      2009-05-19 16:03 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/72e4312ea1e0

6843079: Putback for the new EUC_TW is not complete
Summary: Putback the files missed in last putback
Reviewed-by: alanb

+ make/tools/CharsetMapping/euc_tw.map
+ make/tools/src/build/tools/charsetmapping/GenerateEUC_TW.java
+ make/tools/src/build/tools/charsetmapping/Main.java
+ test/sun/nio/cs/EUC_TW_OLD.java
+ test/sun/nio/cs/TestEUC_TW.java
+ test/sun/nio/cs/TestX11CNS.java
+ test/sun/nio/cs/X11CNS11643.java
+ test/sun/nio/cs/X11CNS11643P1.java
+ test/sun/nio/cs/X11CNS11643P2.java
+ test/sun/nio/cs/X11CNS11643P3.java



From Ulf.Zibis at gmx.de  Tue May 19 23:09:40 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Wed, 20 May 2009 01:09:40 +0200
Subject: hg: jdk7/tl/jdk: 6831794: charset EUC_TW is 12.6% of the total
	size	of charsets.jar; ...
In-Reply-To: <20090519223635.EBDE4E425@hg.openjdk.java.net>
References: <20090519223635.EBDE4E425@hg.openjdk.java.net>
Message-ID: <4A133C34.7000404@gmx.de>

Congratulation ;-)

... I'm wondering, that euc_tw.map is not part of the changeset. ??

-Ulf


Am 20.05.2009 00:36, xueming.shen at sun.com schrieb:
> Changeset: 842fb12a21d7
> Author:    sherman
> Date:      2009-05-19 15:25 -0700
> URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/842fb12a21d7
>
> 6831794: charset EUC_TW is 12.6% of the total size of charsets.jar
> 6229811: Several codepoints in EUC_TW failed in roundtrip conversion
> Summary: Re-write EUC_TW charset to address the size and roundtrip issue.
> Reviewed-by: alanb
>
> ! make/java/nio/Makefile
> ! make/sun/Makefile
> ! make/sun/nio/FILES_java.gmk
> ! make/sun/nio/Makefile
> ! make/tools/CharsetMapping/Makefile
> ! make/tools/src/build/tools/charsetmapping/CharsetMapping.java
> ! make/tools/src/build/tools/charsetmapping/GenerateMapping.java
> ! make/tools/src/build/tools/charsetmapping/GenerateSBCS.java
> ! src/share/classes/sun/io/ByteToCharEUC_TW.java
> ! src/share/classes/sun/io/CharToByteEUC_TW.java
> ! src/share/classes/sun/nio/cs/ext/EUC_TW.java
> ! src/share/classes/sun/nio/cs/ext/ISO2022.java
> ! src/share/classes/sun/nio/cs/ext/ISO2022_CN.java
> ! src/solaris/classes/sun/awt/motif/X11CNS11643.java
> ! test/sun/nio/cs/TestISO2022CNDecoder.java
>
>
>   



From xueming.shen at sun.com  Tue May 19 23:40:13 2009
From: xueming.shen at sun.com (xueming.shen at sun.com)
Date: Tue, 19 May 2009 23:40:13 +0000
Subject: hg: jdk7/tl/jdk: 2 new changesets
Message-ID: <20090519234037.4EB4AE444@hg.openjdk.java.net>

Changeset: 49478a651a28
Author:    sherman
Date:      2009-05-19 16:21 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/49478a651a28

6728376: Wrong error handling in Java_java_util_zip_Deflater_deflateBytes leads to size 0 if compress fails
6735255: ZipFile.close() does not close ZipFileInputStreams, contrary to the API document
Summary: Throws OOM when malloc failed. Closes all outstanding streams when closing
Reviewed-by: alanb

! src/share/classes/java/util/zip/ZipFile.java
! src/share/native/java/util/zip/Deflater.c
! src/share/native/java/util/zip/Inflater.c

Changeset: 057cc7d16812
Author:    sherman
Date:      2009-05-19 16:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/057cc7d16812

Merge




From weijun.wang at sun.com  Wed May 20 02:20:32 2009
From: weijun.wang at sun.com (weijun.wang at sun.com)
Date: Wed, 20 May 2009 02:20:32 +0000
Subject: hg: jdk7/tl/jdk: 3 new changesets
Message-ID: <20090520022108.8E097E4EB@hg.openjdk.java.net>

Changeset: 02b02a886b9b
Author:    weijun
Date:      2009-05-20 10:11 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/02b02a886b9b

6832016: {DigestMD5Base,Des3DkCrypto}.setParityBit should use Integer.bitCount
Reviewed-by: weijun
Contributed-by: Christian Thalinger <christian.thalinger at sun.com>

! src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java
! src/share/classes/sun/security/krb5/internal/crypto/dk/Des3DkCrypto.java

Changeset: 4d607dc5cb22
Author:    weijun
Date:      2009-05-20 10:12 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4d607dc5cb22

6682516: SPNEGO_HTTP_AUTH/WWW_KRB and SPNEGO_HTTP_AUTH/WWW_SPNEGO failed on all non-windows platforms
Reviewed-by: xuelei

! src/share/classes/sun/security/krb5/PrincipalName.java
+ test/sun/security/krb5/canonicalize/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor
+ test/sun/security/krb5/canonicalize/Test.java

Changeset: eb46247f6c53
Author:    weijun
Date:      2009-05-20 10:12 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/eb46247f6c53

6832353: Krb5LoginModule: use the KRB5CCNAME when searching for Kerberos ticket cache
Reviewed-by: xuelei

! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java



From jonathan.gibbons at sun.com  Wed May 20 20:41:06 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Wed, 20 May 2009 20:41:06 +0000
Subject: hg: jdk7/tl/langtools: 6827026: Change javac source and target
	default to 7
Message-ID: <20090520204108.78052E5AC@hg.openjdk.java.net>

Changeset: 79eb8795a1de
Author:    jjg
Date:      2009-05-20 13:36 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/79eb8795a1de

6827026: Change javac source and target default to 7
Reviewed-by: darcy, ohair

! make/Makefile
! make/build.properties
! make/build.xml
! src/share/classes/com/sun/tools/javac/code/Source.java
! src/share/classes/com/sun/tools/javac/jvm/Target.java



From jonathan.gibbons at sun.com  Wed May 20 20:45:48 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Wed, 20 May 2009 20:45:48 +0000
Subject: hg: jdk7/tl/corba: 6827026: Change javac source and target default to
	7
Message-ID: <20090520204549.95064E5B1@hg.openjdk.java.net>

Changeset: 2752d8bd4142
Author:    jjg
Date:      2009-05-20 13:41 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/2752d8bd4142

6827026: Change javac source and target default to 7
Reviewed-by: darcy, ohair

! make/Makefile



From jonathan.gibbons at sun.com  Wed May 20 20:50:38 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Wed, 20 May 2009 20:50:38 +0000
Subject: hg: jdk7/tl/jaxp: 6827026: Change javac source and target default to 7
Message-ID: <20090520205039.83F07E5BD@hg.openjdk.java.net>

Changeset: bdaf6acaf6e3
Author:    jjg
Date:      2009-05-20 13:45 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/bdaf6acaf6e3

6827026: Change javac source and target default to 7
Reviewed-by: darcy, ohair

! make/Makefile
! make/build.properties
! make/build.xml



From jonathan.gibbons at sun.com  Wed May 20 20:55:23 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Wed, 20 May 2009 20:55:23 +0000
Subject: hg: jdk7/tl/jaxws: 6827026: Change javac source and target default to
	7
Message-ID: <20090520205524.8E305E5C2@hg.openjdk.java.net>

Changeset: 605e1cdeba48
Author:    jjg
Date:      2009-05-20 13:50 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/605e1cdeba48

6827026: Change javac source and target default to 7
Reviewed-by: darcy, ohair

! make/Makefile
! make/build.properties
! make/build.xml



From jonathan.gibbons at sun.com  Wed May 20 21:00:31 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Wed, 20 May 2009 21:00:31 +0000
Subject: hg: jdk7/tl/jdk: 6827026: Change javac source and target default to 7
Message-ID: <20090520210043.02ECFE5C7@hg.openjdk.java.net>

Changeset: 1bc5be8665cc
Author:    jjg
Date:      2009-05-20 13:55 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1bc5be8665cc

6827026: Change javac source and target default to 7
Reviewed-by: darcy, ohair

! make/common/shared/Defs-control.gmk
! make/common/shared/Defs-java.gmk
! make/javax/swing/beaninfo/SwingBeans.gmk



From jonathan.gibbons at sun.com  Wed May 20 21:07:41 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Wed, 20 May 2009 21:07:41 +0000
Subject: hg: jdk7/tl: 6827026: Change javac source and target default to 7
Message-ID: <20090520210741.CFD03E5D5@hg.openjdk.java.net>

Changeset: 54d14906940b
Author:    jjg
Date:      2009-05-20 14:02 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/54d14906940b

6827026: Change javac source and target default to 7
Reviewed-by: darcy, ohair

! make/Defs-internal.gmk



From Xueming.Shen at Sun.COM  Wed May 20 22:22:04 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Wed, 20 May 2009 15:22:04 -0700
Subject: Rewrite of IBM doublebyte charsets
In-Reply-To: <4A105530.80201@gmx.de>
References: <49FA9B45.8020802@sun.com> <4A075BD6.5020909@gmx.de>
	<4A09179D.1020308@sun.com> <4A09BF0B.60702@gmx.de>
	<4A09C096.8000505@sun.com>
	<4A09C748.6070302@gmx.de> <4A09CEBD.3050703@sun.com>
	<4A09FF75.4010400@gmx.de>
	<4A0A4197.4030503@sun.com> <4A0C8294.7020602@gmx.de>
	<4A0C8542.10503@sun.com> <4A105530.80201@gmx.de>
Message-ID: <4A14828C.1000101@sun.com>

Ulf, thanks for the review!

Now we have a bugid for this one. The webrev has been updated to address 
some of your
suggestions (see my below) and rename to

http://cr.openjdk.java.net/~sherman/6843578/webrev
(old webrevs are still there with webrev.0x)

With this change,
(1)21% reduce of rt.jar size (from 2.99M-with the euc_tw reduce to 2.35M)
(2)much faster coding performance,  a quick/not_really_a_benchmark 
result can been found at
    http://cr.openjdk.java.net/~sherman/6843578/codingPerm
(3)also addressed the bugids listed below.

6639450: IBM949C encoder modifies state of IBM949 encoder
6569191: Cp943 io converter returns U+0000 and U+FFFD for unconvertable 
character
6577466: Character encoder IBM970 throws a BufferOverflowException
5065777: CharsetEncoder canEncode() methods often incorrectly return false

The test case test/sun/nio/cs/OLD/TestIBMDB.java is used to make sure 
there is no mapping
regression, there are new mapping entries added (because switching to 
the latest IBM cdc
mapping tables for some charsets, which the b2c tables we have are not 
accurate/complete), but
no conflit with previous mappings.

Alan, Martin, I need you guys also help review the change, I will need a 
name on the putback message.
The number of file is huge, but only the files listed at beginning need 
attention:-)

Sherman

Ulf Zibis wrote:
>
> *** Decoder-Suggestions:
>
> (1) Unused imports in DoubleByte-X.java:
>    import java.util.Arrays;
>    import sun.nio.cs.StandardCharsets;
>    import static sun.nio.cs.CharsetMapping.*;
>    import sun.nio.cs.ext.DoubleByte;  // or instead: static 
> sun.nio.cs.ext.DoubleByte.*;
>
done! good catch.

>
> (3) Modify dimension of b2c:
>      char[][] b2c = new char[0x100][segSize];
>    so decode :
>      public char decodeDouble(int b1, int b2) {
>          if ((b2-=b2Min) < 0 || b2 >= segSize)
>              return UNMAPPABLE_DECODING;
>          return b2c[b1][b2];
>      }
>   Benefit[1]: increase performance of decoder
>   Benefit[2]: reduce memory of B2C_UNMAPPABLE from 8192 to 512 bytes
>   Benefit[3]: some of b2c pages could be saved (if only containing 
> \uFFFD)
>
A good suggestion. I tried, and it does bring in about 10%+% gain of 
decoding (for non-direct buffer,
we also have similar gian in direct buffer, but the % number is not this 
big). The webrev has been updated
for this one.


> (4) Don't care about b2Max (it's always not far from 0xff):
>   Benefit[4]: another performance increase of decoder (only check: 
> (b2-=b2Min) < 0)
Decided to keep it. We do have some charsets (not included this time) 
that care about b2max.

>
> (5) Truncate String segments (there are 65 % "\uFFFD" in IBM933):
>    (fill b2c segments first with "\uFFFD", then initialize)
>   Benefit[5]: save up to 180 % superfluous memory and disk-footprint
Changing from the b2c index from 4-bit to 8-bit (#2) should have already 
improved this a lot (I see
a 1.5%+ improvement of overall charsets.jar)

>
> (6) Unload b2cStr from memory after startup:
>    - outsource b2cStr to additional class file like EUC_TW approach
>    - set b2cStr = null after startup (remove final modifier)
>   Benefit[6]: avoid 100 % superfluous memory-footprint
>
I doubt it really saves something real, since the "class" should still 
keep its copy somewhere...and
I will need it for c2b (now I'm "delaying" the c2b init)

> (7) Avoid copying b2cStr to b2c:
>    (String#charAt() is fast as char[] access)
>   Benefit[7]: increase startup performance for decoder
>
I tried again last night. char[][] is much faster than the String[] 
version in both client
and server vm. So keep it asis. (this was actually I switched from 
String[] to char[][])


>
> (9) Share mappings (IBM930 and IBM939 are 99 % identical):
>   Benefit[9]: save up to 99 % superfluous disk-footprint
>   Benefit[10]: save up to 99 % superfluous memory-footprint (if both 
> charsets are loaded)
>
I still want to keep one map for one charset, at least for now. It might 
be something worth researching
in the future.

> (12) Get rid of sun.io package dependency:
>   
> https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/tags/milestone2/src/sun/io/ 
>
>   Benefit[13]: avoid superfluous disk-footprint
>   Benefit[14]: save maintenance of sun.io converters
>   Disadvantage[1]: published under JRL (waiting for launch of 
> OpenJDK-7 project "charset-enhancement") ;-)
>
This is not something about engineering. It's about license, policy...

>
> (17) Decoder#decodeArrayLoop: shortcut for single byte only:
>      int sr = src.remaining();
>      int sl = sp + sr;
>      int dr = dst.remaining();
>      int dl = dp + dr;
>      // single byte only loop
>      int slSB = sp + sr < dr ? sr : dr;
>      while (sp < slSB) {
>          char c = b2cSB[sa[sp] && 0xff];
>          if (c == UNMAPPABLE_DECODING)
>              break;
>          da[dp++] = c;
>          sp++;
>      }
>     Same for Encoder#encodeArrayLoop
>
> (18) Decoder_EBCDIC: boolean singlebyteState:
>      if (singlebyteState)
>          ...
>
> (19) Decoder_EBCDIC: decode single byte first:
>      if (singlebyteState)
>          c = b2cSB[b1];
>      if (c == UNMAPPABLE_DECODING) {
>          ...
>      }
>   Benefit[20]: should be faster
>
>
Not like when we dealing with singlebyte charsets. For doublebyte charsets
the priority should be given to doublebyte codepoints, if possible. Not 
single
byte codepoints.


> *** Encoder-Suggestions:
>
> (21) join *.nr to *.c2b files (25->000a becomes 000a->fffd):
>   Benefit[21]: reduce no. of files
>   Benefit[22]: simplifies initC2B() (avoids 2 loops)
>
In theory you can do some magic to "join" .nr into .c2b. The price might 
be more complicated
logic depends on the codepoints. You may end up doing some table lookup 
for each codepoint
in b2c when processing.

And big thanks for all the suggestions.


From martinrb at google.com  Wed May 20 23:27:15 2009
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 20 May 2009 16:27:15 -0700
Subject: Rewrite of IBM doublebyte charsets
In-Reply-To: <4A14828C.1000101@sun.com>
References: <49FA9B45.8020802@sun.com> <4A09C096.8000505@sun.com>
	<4A09C748.6070302@gmx.de> <4A09CEBD.3050703@sun.com>
	<4A09FF75.4010400@gmx.de> <4A0A4197.4030503@sun.com>
	<4A0C8294.7020602@gmx.de> <4A0C8542.10503@sun.com>
	<4A105530.80201@gmx.de> <4A14828C.1000101@sun.com>
Message-ID: <1ccfd1c10905201627r331ebbcj3561ed08e0408172@mail.gmail.com>

5-minute review.

Looks pretty good.

Thanks for fixing old bugs found by FindXXcoderBugs.java

Thanks Ulf for your hard work on implementation and review.

Again, charset changes are very hard to review, hence scary,
but relatively easy to test in an automated fashion.

I imagine generating tests with
random input,
random charset,
random choice of direct/non-direct buffers,
and checking that charset behavior is unchanged
except for performance.

---

// it's time to generate the class file
Confusing - you're generating a source file,
and the phrase "class file" usually means
XX.class


typos:

typitcal

date structure.

correspoinding

ruondtrip

*file dbcs has trailing newlines

*Martin

On Wed, May 20, 2009 at 15:22, Xueming Shen <Xueming.Shen at sun.com> wrote:

> Ulf, thanks for the review!
>
> Now we have a bugid for this one. The webrev has been updated to address
> some of your
> suggestions (see my below) and rename to
>
> http://cr.openjdk.java.net/~sherman/6843578/webrev<http://cr.openjdk.java.net/%7Esherman/6843578/webrev>
> (old webrevs are still there with webrev.0x)
>
> With this change,
> (1)21% reduce of rt.jar size (from 2.99M-with the euc_tw reduce to 2.35M)
> (2)much faster coding performance,  a quick/not_really_a_benchmark result
> can been found at
>   http://cr.openjdk.java.net/~sherman/6843578/codingPerm<http://cr.openjdk.java.net/%7Esherman/6843578/codingPerm>
> (3)also addressed the bugids listed below.
>
> 6639450: IBM949C encoder modifies state of IBM949 encoder
> 6569191: Cp943 io converter returns U+0000 and U+FFFD for unconvertable
> character
> 6577466: Character encoder IBM970 throws a BufferOverflowException
> 5065777: CharsetEncoder canEncode() methods often incorrectly return false
>
> The test case test/sun/nio/cs/OLD/TestIBMDB.java is used to make sure there
> is no mapping
> regression, there are new mapping entries added (because switching to the
> latest IBM cdc
> mapping tables for some charsets, which the b2c tables we have are not
> accurate/complete), but
> no conflit with previous mappings.
>
> Alan, Martin, I need you guys also help review the change, I will need a
> name on the putback message.
> The number of file is huge, but only the files listed at beginning need
> attention:-)
>
> Sherman
>
> Ulf Zibis wrote:
>
>>
>> *** Decoder-Suggestions:
>>
>> (1) Unused imports in DoubleByte-X.java:
>>   import java.util.Arrays;
>>   import sun.nio.cs.StandardCharsets;
>>   import static sun.nio.cs.CharsetMapping.*;
>>   import sun.nio.cs.ext.DoubleByte;  // or instead: static
>> sun.nio.cs.ext.DoubleByte.*;
>>
>>  done! good catch.
>
>
>> (3) Modify dimension of b2c:
>>     char[][] b2c = new char[0x100][segSize];
>>   so decode :
>>     public char decodeDouble(int b1, int b2) {
>>         if ((b2-=b2Min) < 0 || b2 >= segSize)
>>             return UNMAPPABLE_DECODING;
>>         return b2c[b1][b2];
>>     }
>>  Benefit[1]: increase performance of decoder
>>  Benefit[2]: reduce memory of B2C_UNMAPPABLE from 8192 to 512 bytes
>>  Benefit[3]: some of b2c pages could be saved (if only containing \uFFFD)
>>
>>  A good suggestion. I tried, and it does bring in about 10%+% gain of
> decoding (for non-direct buffer,
> we also have similar gian in direct buffer, but the % number is not this
> big). The webrev has been updated
> for this one.
>
>
>  (4) Don't care about b2Max (it's always not far from 0xff):
>>  Benefit[4]: another performance increase of decoder (only check:
>> (b2-=b2Min) < 0)
>>
> Decided to keep it. We do have some charsets (not included this time) that
> care about b2max.
>
>
>> (5) Truncate String segments (there are 65 % "\uFFFD" in IBM933):
>>   (fill b2c segments first with "\uFFFD", then initialize)
>>  Benefit[5]: save up to 180 % superfluous memory and disk-footprint
>>
> Changing from the b2c index from 4-bit to 8-bit (#2) should have already
> improved this a lot (I see
> a 1.5%+ improvement of overall charsets.jar)
>
>
>> (6) Unload b2cStr from memory after startup:
>>   - outsource b2cStr to additional class file like EUC_TW approach
>>   - set b2cStr = null after startup (remove final modifier)
>>  Benefit[6]: avoid 100 % superfluous memory-footprint
>>
>>  I doubt it really saves something real, since the "class" should still
> keep its copy somewhere...and
> I will need it for c2b (now I'm "delaying" the c2b init)
>
>  (7) Avoid copying b2cStr to b2c:
>>   (String#charAt() is fast as char[] access)
>>  Benefit[7]: increase startup performance for decoder
>>
>>  I tried again last night. char[][] is much faster than the String[]
> version in both client
> and server vm. So keep it asis. (this was actually I switched from String[]
> to char[][])
>
>
>
>> (9) Share mappings (IBM930 and IBM939 are 99 % identical):
>>  Benefit[9]: save up to 99 % superfluous disk-footprint
>>  Benefit[10]: save up to 99 % superfluous memory-footprint (if both
>> charsets are loaded)
>>
>>  I still want to keep one map for one charset, at least for now. It might
> be something worth researching
> in the future.
>
>  (12) Get rid of sun.io package dependency:
>>
>> https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/tags/milestone2/src/sun/io/
>>  Benefit[13]: avoid superfluous disk-footprint
>>  Benefit[14]: save maintenance of sun.io converters
>>  Disadvantage[1]: published under JRL (waiting for launch of OpenJDK-7
>> project "charset-enhancement") ;-)
>>
>>  This is not something about engineering. It's about license, policy...
>
>
>> (17) Decoder#decodeArrayLoop: shortcut for single byte only:
>>     int sr = src.remaining();
>>     int sl = sp + sr;
>>     int dr = dst.remaining();
>>     int dl = dp + dr;
>>     // single byte only loop
>>     int slSB = sp + sr < dr ? sr : dr;
>>     while (sp < slSB) {
>>         char c = b2cSB[sa[sp] && 0xff];
>>         if (c == UNMAPPABLE_DECODING)
>>             break;
>>         da[dp++] = c;
>>         sp++;
>>     }
>>    Same for Encoder#encodeArrayLoop
>>
>> (18) Decoder_EBCDIC: boolean singlebyteState:
>>     if (singlebyteState)
>>         ...
>>
>> (19) Decoder_EBCDIC: decode single byte first:
>>     if (singlebyteState)
>>         c = b2cSB[b1];
>>     if (c == UNMAPPABLE_DECODING) {
>>         ...
>>     }
>>  Benefit[20]: should be faster
>>
>>
>>  Not like when we dealing with singlebyte charsets. For doublebyte
> charsets
> the priority should be given to doublebyte codepoints, if possible. Not
> single
> byte codepoints.
>
>
>  *** Encoder-Suggestions:
>>
>> (21) join *.nr to *.c2b files (25->000a becomes 000a->fffd):
>>  Benefit[21]: reduce no. of files
>>  Benefit[22]: simplifies initC2B() (avoids 2 loops)
>>
>>  In theory you can do some magic to "join" .nr into .c2b. The price might
> be more complicated
> logic depends on the codepoints. You may end up doing some table lookup for
> each codepoint
> in b2c when processing.
>
> And big thanks for all the suggestions.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090520/6f37ef73/attachment.html>

From Xueming.Shen at Sun.COM  Wed May 20 23:48:03 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Wed, 20 May 2009 16:48:03 -0700
Subject: Rewrite of IBM doublebyte charsets
In-Reply-To: <1ccfd1c10905201627r331ebbcj3561ed08e0408172@mail.gmail.com>
References: <49FA9B45.8020802@sun.com> <4A09C096.8000505@sun.com>
	<4A09C748.6070302@gmx.de> <4A09CEBD.3050703@sun.com>
	<4A09FF75.4010400@gmx.de>
	<4A0A4197.4030503@sun.com> <4A0C8294.7020602@gmx.de>
	<4A0C8542.10503@sun.com>
	<4A105530.80201@gmx.de> <4A14828C.1000101@sun.com>
	<1ccfd1c10905201627r331ebbcj3561ed08e0408172@mail.gmail.com>
Message-ID: <4A1496B3.4070708@sun.com>

Thanks for the 5 minutes:-)

Your FindXYZcoderBugs tests are indeed very helpful to catch most of the 
"inconsistent" behaviors
between different paths by feeding the "random" inputs.

The TestIBMDB.java is diffing the behaviors of old implementation and 
new implementation
with all "decode-able" bytes and "encode-able" chars...so it gives us 
some of the guarantee.

Oh, the typos are being fixed:-)

Sherman

Martin Buchholz wrote:
> 5-minute review.
>
> Looks pretty good.
>
> Thanks for fixing old bugs found by FindXXcoderBugs.java
>
> Thanks Ulf for your hard work on implementation and review.
>
> Again, charset changes are very hard to review, hence scary,
> but relatively easy to test in an automated fashion.
>
> I imagine generating tests with
> random input,
> random charset,
> random choice of direct/non-direct buffers,
> and checking that charset behavior is unchanged
> except for performance.
>
> ---
> // it's time to generate the class file
> Confusing - you're generating a source file,
> and the phrase "class file" usually means
> XX.class
>   
>
> typos:
>
> typitcal
> date structure. 
>   
> correspoinding
>
> ruondtrip
>
> *file dbcs has trailing newlines
>
> *Martin
>
>   
> On Wed, May 20, 2009 at 15:22, Xueming Shen <Xueming.Shen at sun.com 
> <mailto:Xueming.Shen at sun.com>> wrote:
>
>     Ulf, thanks for the review!
>
>     Now we have a bugid for this one. The webrev has been updated to
>     address some of your
>     suggestions (see my below) and rename to
>
>     http://cr.openjdk.java.net/~sherman/6843578/webrev
>     <http://cr.openjdk.java.net/%7Esherman/6843578/webrev>
>     (old webrevs are still there with webrev.0x)
>
>     With this change,
>     (1)21% reduce of rt.jar size (from 2.99M-with the euc_tw reduce to
>     2.35M)
>     (2)much faster coding performance,  a quick/not_really_a_benchmark
>     result can been found at
>       http://cr.openjdk.java.net/~sherman/6843578/codingPerm
>     <http://cr.openjdk.java.net/%7Esherman/6843578/codingPerm>
>     (3)also addressed the bugids listed below.
>
>     6639450: IBM949C encoder modifies state of IBM949 encoder
>     6569191: Cp943 io converter returns U+0000 and U+FFFD for
>     unconvertable character
>     6577466: Character encoder IBM970 throws a BufferOverflowException
>     5065777: CharsetEncoder canEncode() methods often incorrectly
>     return false
>
>     The test case test/sun/nio/cs/OLD/TestIBMDB.java is used to make
>     sure there is no mapping
>     regression, there are new mapping entries added (because switching
>     to the latest IBM cdc
>     mapping tables for some charsets, which the b2c tables we have are
>     not accurate/complete), but
>     no conflit with previous mappings.
>
>     Alan, Martin, I need you guys also help review the change, I will
>     need a name on the putback message.
>     The number of file is huge, but only the files listed at beginning
>     need attention:-)
>
>     Sherman
>
>
>     Ulf Zibis wrote:
>
>
>         *** Decoder-Suggestions:
>
>         (1) Unused imports in DoubleByte-X.java:
>           import java.util.Arrays;
>           import sun.nio.cs.StandardCharsets;
>           import static sun.nio.cs.CharsetMapping.*;
>           import sun.nio.cs.ext.DoubleByte;  // or instead: static
>         sun.nio.cs.ext.DoubleByte.*;
>
>     done! good catch.
>
>
>
>         (3) Modify dimension of b2c:
>             char[][] b2c = new char[0x100][segSize];
>           so decode :
>             public char decodeDouble(int b1, int b2) {
>                 if ((b2-=b2Min) < 0 || b2 >= segSize)
>                     return UNMAPPABLE_DECODING;
>                 return b2c[b1][b2];
>             }
>          Benefit[1]: increase performance of decoder
>          Benefit[2]: reduce memory of B2C_UNMAPPABLE from 8192 to 512
>         bytes
>          Benefit[3]: some of b2c pages could be saved (if only
>         containing \uFFFD)
>
>     A good suggestion. I tried, and it does bring in about 10%+% gain
>     of decoding (for non-direct buffer,
>     we also have similar gian in direct buffer, but the % number is
>     not this big). The webrev has been updated
>     for this one.
>
>
>
>         (4) Don't care about b2Max (it's always not far from 0xff):
>          Benefit[4]: another performance increase of decoder (only
>         check: (b2-=b2Min) < 0)
>
>     Decided to keep it. We do have some charsets (not included this
>     time) that care about b2max.
>
>
>
>         (5) Truncate String segments (there are 65 % "\uFFFD" in IBM933):
>           (fill b2c segments first with "\uFFFD", then initialize)
>          Benefit[5]: save up to 180 % superfluous memory and
>         disk-footprint
>
>     Changing from the b2c index from 4-bit to 8-bit (#2) should have
>     already improved this a lot (I see
>     a 1.5%+ improvement of overall charsets.jar)
>
>
>
>         (6) Unload b2cStr from memory after startup:
>           - outsource b2cStr to additional class file like EUC_TW approach
>           - set b2cStr = null after startup (remove final modifier)
>          Benefit[6]: avoid 100 % superfluous memory-footprint
>
>     I doubt it really saves something real, since the "class" should
>     still keep its copy somewhere...and
>     I will need it for c2b (now I'm "delaying" the c2b init)
>
>
>         (7) Avoid copying b2cStr to b2c:
>           (String#charAt() is fast as char[] access)
>          Benefit[7]: increase startup performance for decoder
>
>     I tried again last night. char[][] is much faster than the
>     String[] version in both client
>     and server vm. So keep it asis. (this was actually I switched from
>     String[] to char[][])
>
>
>
>
>         (9) Share mappings (IBM930 and IBM939 are 99 % identical):
>          Benefit[9]: save up to 99 % superfluous disk-footprint
>          Benefit[10]: save up to 99 % superfluous memory-footprint (if
>         both charsets are loaded)
>
>     I still want to keep one map for one charset, at least for now. It
>     might be something worth researching
>     in the future.
>
>
>         (12) Get rid of sun.io <http://sun.io> package dependency:
>          https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/tags/milestone2/src/sun/io/
>
>          Benefit[13]: avoid superfluous disk-footprint
>          Benefit[14]: save maintenance of sun.io <http://sun.io>
>         converters
>          Disadvantage[1]: published under JRL (waiting for launch of
>         OpenJDK-7 project "charset-enhancement") ;-)
>
>     This is not something about engineering. It's about license,
>     policy...
>
>
>
>         (17) Decoder#decodeArrayLoop: shortcut for single byte only:
>             int sr = src.remaining();
>             int sl = sp + sr;
>             int dr = dst.remaining();
>             int dl = dp + dr;
>             // single byte only loop
>             int slSB = sp + sr < dr ? sr : dr;
>             while (sp < slSB) {
>                 char c = b2cSB[sa[sp] && 0xff];
>                 if (c == UNMAPPABLE_DECODING)
>                     break;
>                 da[dp++] = c;
>                 sp++;
>             }
>            Same for Encoder#encodeArrayLoop
>
>         (18) Decoder_EBCDIC: boolean singlebyteState:
>             if (singlebyteState)
>                 ...
>
>         (19) Decoder_EBCDIC: decode single byte first:
>             if (singlebyteState)
>                 c = b2cSB[b1];
>             if (c == UNMAPPABLE_DECODING) {
>                 ...
>             }
>          Benefit[20]: should be faster
>
>
>     Not like when we dealing with singlebyte charsets. For doublebyte
>     charsets
>     the priority should be given to doublebyte codepoints, if
>     possible. Not single
>     byte codepoints.
>
>
>
>         *** Encoder-Suggestions:
>
>         (21) join *.nr to *.c2b files (25->000a becomes 000a->fffd):
>          Benefit[21]: reduce no. of files
>          Benefit[22]: simplifies initC2B() (avoids 2 loops)
>
>     In theory you can do some magic to "join" .nr into .c2b. The price
>     might be more complicated
>     logic depends on the codepoints. You may end up doing some table
>     lookup for each codepoint
>     in b2c when processing.
>
>     And big thanks for all the suggestions.
>
>



From jonathan.gibbons at sun.com  Thu May 21 02:16:54 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Thu, 21 May 2009 02:16:54 +0000
Subject: hg: jdk7/tl/langtools: 6843648: tools/javac/versions/check.sh is
	broken
Message-ID: <20090521021657.53D9AE5FB@hg.openjdk.java.net>

Changeset: 44eaac2b4501
Author:    jjg
Date:      2009-05-20 19:10 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/44eaac2b4501

6843648: tools/javac/versions/check.sh is broken
Reviewed-by: darcy

! test/tools/javac/6341866/Anno.java
! test/tools/javac/6464451/BigFinally.java
! test/tools/javac/6464451/DeepNestedFinally.java
! test/tools/javac/6464451/ManyExitsInTry.java
! test/tools/javac/ClassLit.java
! test/tools/javac/T6557865.java
! test/tools/javac/foreach/T6682380.java
! test/tools/javac/processing/6348499/A.java
! test/tools/javac/processing/6414633/A.java
! test/tools/javac/processing/6430209/b6341534.java
! test/tools/javac/processing/T6439826.java
! test/tools/javac/stackmap/T4955930.sh
! test/tools/javac/versions/check.sh



From maurizio.cimadamore at sun.com  Thu May 21 10:04:30 2009
From: maurizio.cimadamore at sun.com (maurizio.cimadamore at sun.com)
Date: Thu, 21 May 2009 10:04:30 +0000
Subject: hg: jdk7/tl/langtools: 6722234: javac diagnostics need better
	integration with the type-system
Message-ID: <20090521100435.1B205E67A@hg.openjdk.java.net>

Changeset: d402db1005ad
Author:    mcimadamore
Date:      2009-05-21 10:56 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d402db1005ad

6722234: javac diagnostics need better integration with the type-system
Summary: Added RichDiagnosticFormatter which provides better formatting capabilities for javac types/symbols
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Printer.java
! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java
! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java
+ src/share/classes/com/sun/tools/javac/util/ForwardingDiagnosticFormatter.java
! src/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java
+ src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java
! test/tools/javac/6304921/T6304921.java
! test/tools/javac/6304921/T6304921.out
! test/tools/javac/6491592/T6491592.out
+ test/tools/javac/Diagnostics/6722234/T6722234a.java
+ test/tools/javac/Diagnostics/6722234/T6722234a_1.out
+ test/tools/javac/Diagnostics/6722234/T6722234a_2.out
+ test/tools/javac/Diagnostics/6722234/T6722234b.java
+ test/tools/javac/Diagnostics/6722234/T6722234b_1.out
+ test/tools/javac/Diagnostics/6722234/T6722234b_2.out
+ test/tools/javac/Diagnostics/6722234/T6722234c.java
+ test/tools/javac/Diagnostics/6722234/T6722234c.out
+ test/tools/javac/Diagnostics/6722234/T6722234d.java
+ test/tools/javac/Diagnostics/6722234/T6722234d_1.out
+ test/tools/javac/Diagnostics/6722234/T6722234d_2.out
! test/tools/javac/ExtendArray.java
! test/tools/javac/ExtendArray.out
! test/tools/javac/OverridePosition.java
! test/tools/javac/OverridePosition.out
! test/tools/javac/T4093617/T4093617.java
! test/tools/javac/T4093617/T4093617.out
! test/tools/javac/T5003235/T5003235c.java
! test/tools/javac/T5003235/T5003235c.out
! test/tools/javac/miranda/T4666866.java
! test/tools/javac/miranda/T4666866.out
! test/tools/javac/protectedAccess/ProtectedMemberAccess2.java
! test/tools/javac/protectedAccess/ProtectedMemberAccess3.java
! test/tools/javac/protectedAccess/ProtectedMemberAccess4.java



From fw at deneb.enyo.de  Thu May 21 17:18:55 2009
From: fw at deneb.enyo.de (Florian Weimer)
Date: Thu, 21 May 2009 19:18:55 +0200
Subject: c.toArray might (incorrectly) not return Object[] (see 6260652)
Message-ID: <87pre2nzls.fsf@mid.deneb.enyo.de>

So says the ArrayList(Collection) constructor.  Can this bug report be
opened?  Is this workaround still necessary?


From Ulf.Zibis at gmx.de  Thu May 21 19:20:00 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Thu, 21 May 2009 21:20:00 +0200
Subject: Rewrite of IBM doublebyte charsets
In-Reply-To: <1ccfd1c10905201627r331ebbcj3561ed08e0408172@mail.gmail.com>
References: <49FA9B45.8020802@sun.com> <4A09C096.8000505@sun.com>	
	<4A09C748.6070302@gmx.de> <4A09CEBD.3050703@sun.com>	
	<4A09FF75.4010400@gmx.de> <4A0A4197.4030503@sun.com>	
	<4A0C8294.7020602@gmx.de> <4A0C8542.10503@sun.com>	
	<4A105530.80201@gmx.de> <4A14828C.1000101@sun.com>
	<1ccfd1c10905201627r331ebbcj3561ed08e0408172@mail.gmail.com>
Message-ID: <4A15A960.909@gmx.de>

Hi Martin,

I have missed your comments for long time. Have you have had holidays?

Am 21.05.2009 01:27, Martin Buchholz schrieb:
>
> Again, charset changes are very hard to review, hence scary,
> but relatively easy to test in an automated fashion.

Good point !

>
> I imagine generating tests with
> random input,
> random charset,
> random choice of direct/non-direct buffers,
> and checking that charset behavior is unchanged
> except for performance.

I do "some" kind of those tests, hence valid + invalid bytes, in:
https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/test/sun/nio/cs/CharsetsTest.java

-Ulf




From Ulf.Zibis at gmx.de  Thu May 21 19:30:34 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Thu, 21 May 2009 21:30:34 +0200
Subject: Rewrite of IBM doublebyte charsets
In-Reply-To: <4A1496B3.4070708@sun.com>
References: <49FA9B45.8020802@sun.com>
	<4A09C096.8000505@sun.com>	<4A09C748.6070302@gmx.de>
	<4A09CEBD.3050703@sun.com>	<4A09FF75.4010400@gmx.de>	<4A0A4197.4030503@sun.com>
	<4A0C8294.7020602@gmx.de>	<4A0C8542.10503@sun.com>	<4A105530.80201@gmx.de>
	<4A14828C.1000101@sun.com>	<1ccfd1c10905201627r331ebbcj3561ed08e0408172@mail.gmail.com>
	<4A1496B3.4070708@sun.com>
Message-ID: <4A15ABDA.1080104@gmx.de>

Am 21.05.2009 01:48, Xueming Shen schrieb:
> Thanks for the 5 minutes:-)
>
> Your FindXYZcoderBugs tests are indeed very helpful to catch most of 
> the "inconsistent" behaviors
> between different paths by feeding the "random" inputs.
>
> The TestIBMDB.java is diffing the behaviors of old implementation and 
> new implementation
> with all "decode-able" bytes and "encode-able" chars...so it gives us 
> some of the guarantee.

Why do we *try* to stick on old behaviour in case of malformed and/or 
unmappable input, if we don't diff new against old ?
Then we also could *try*, to treat malformed and/or unmappable input 
most accurate.
As you mentioned, most users don't distinguish between those, so they 
won't be affected. On the other hand, user's, who did this distinction, 
would probably happy to return more accurate results, even if not 
identical to recent results.

-Ulf




From martinrb at google.com  Thu May 21 19:45:53 2009
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 21 May 2009 12:45:53 -0700
Subject: Rewrite of IBM doublebyte charsets
In-Reply-To: <4A15A960.909@gmx.de>
References: <49FA9B45.8020802@sun.com> <4A09CEBD.3050703@sun.com>
	<4A09FF75.4010400@gmx.de> <4A0A4197.4030503@sun.com>
	<4A0C8294.7020602@gmx.de> <4A0C8542.10503@sun.com>
	<4A105530.80201@gmx.de> <4A14828C.1000101@sun.com>
	<1ccfd1c10905201627r331ebbcj3561ed08e0408172@mail.gmail.com>
	<4A15A960.909@gmx.de>
Message-ID: <1ccfd1c10905211245y66097824x6eee11953fefa426@mail.gmail.com>

On Thu, May 21, 2009 at 12:20, Ulf Zibis <Ulf.Zibis at gmx.de> wrote:

> Hi Martin,
>
> I have missed your comments for long time. Have you have had holidays?


I remember fondly the time when I had neither a job nor a "life".

Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090521/7cc2766e/attachment.html>

From Xueming.Shen at Sun.COM  Thu May 21 19:52:35 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Thu, 21 May 2009 12:52:35 -0700
Subject: Rewrite of IBM doublebyte charsets
In-Reply-To: <4A15ABDA.1080104@gmx.de>
References: <49FA9B45.8020802@sun.com> <4A09C096.8000505@sun.com>
	<4A09C748.6070302@gmx.de> <4A09CEBD.3050703@sun.com>
	<4A09FF75.4010400@gmx.de>
	<4A0A4197.4030503@sun.com> <4A0C8294.7020602@gmx.de>
	<4A0C8542.10503@sun.com>
	<4A105530.80201@gmx.de> <4A14828C.1000101@sun.com>
	<1ccfd1c10905201627r331ebbcj3561ed08e0408172@mail.gmail.com>
	<4A1496B3.4070708@sun.com> <4A15ABDA.1080104@gmx.de>
Message-ID: <4A15B103.8090509@sun.com>

Ulf Zibis wrote:
> Am 21.05.2009 01:48, Xueming Shen schrieb:
>> Thanks for the 5 minutes:-)
>>
>> Your FindXYZcoderBugs tests are indeed very helpful to catch most of 
>> the "inconsistent" behaviors
>> between different paths by feeding the "random" inputs.
>>
>> The TestIBMDB.java is diffing the behaviors of old implementation and 
>> new implementation
>> with all "decode-able" bytes and "encode-able" chars...so it gives us 
>> some of the guarantee.
>
> Why do we *try* to stick on old behaviour in case of malformed and/or 
> unmappable input, if we don't diff new against old ?
> Then we also could *try*, to treat malformed and/or unmappable input 
> most accurate.
> As you mentioned, most users don't distinguish between those, so they 
> won't be affected. On the other hand, user's, who did this 
> distinction, would probably happy to return more accurate results, 
> even if not identical to recent results.
>
This is the approach/plan I decided to go with to achieve the goals I 
listed last time. Sticking with the old behavior for
now make it easy, or say possible, to push in such a big change. You 
don't want to be stuck on this kind of "arguable"
issues when it's not the main goal of the project, detour yourself  to 
defend/argue whether or not this is the "correct"
change,  if it's correct,  then is this the right thing to do to break 
the compatibility, is there people depend on them. If
you just start a new implementation, you definitely should do all the 
"right" things. It is a different story when you
maintenance some existing products. As I said last time, with this 
change, the implementation, the data structure are
now real open and ready for further optimization (instead of looking at 
a big chunk of data without knowledge where
they come from), you can  now work on the issue, if any, one by one, 
including starting the argument of which error
should be "malformed" and which one should "unmapped". We're (I'm) 60% 
done after this:-)


I



From Ulf.Zibis at gmx.de  Thu May 21 20:11:13 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Thu, 21 May 2009 22:11:13 +0200
Subject: Rewrite of IBM doublebyte charsets
In-Reply-To: <4A14828C.1000101@sun.com>
References: <49FA9B45.8020802@sun.com> <4A075BD6.5020909@gmx.de>
	<4A09179D.1020308@sun.com> <4A09BF0B.60702@gmx.de>
	<4A09C096.8000505@sun.com> <4A09C748.6070302@gmx.de>
	<4A09CEBD.3050703@sun.com> <4A09FF75.4010400@gmx.de>
	<4A0A4197.4030503@sun.com> <4A0C8294.7020602@gmx.de>
	<4A0C8542.10503@sun.com> <4A105530.80201@gmx.de>
	<4A14828C.1000101@sun.com>
Message-ID: <4A15B561.2010301@gmx.de>

Am 21.05.2009 00:22, Xueming Shen schrieb:
> Ulf, thanks for the review!
>
> Now we have a bugid for this one.

Good idea! I set it on my watch list.

> With this change,
> (1)21% reduce of rt.jar size (from 2.99M-with the euc_tw reduce to 2.35M)

???  My rt.jar is 46 MB. Can you explain your numbers?

> The test case test/sun/nio/cs/OLD/TestIBMDB.java is used to make sure 
> there is no mapping
> regression, there are new mapping entries added (because switching to 
> the latest IBM cdc
> mapping tables for some charsets, which the b2c tables we have are not 
> accurate/complete), but
> no conflit with previous mappings.

In IBM933.map you state:

#    Warning:
#    (2) we "should" have an entry
#        25  000a
#        in IBM933.nr (b->c only tables) as other ebcdic
#        mappings do, but the "old" implementation actually
#        maps \u000a to 25. Keep it old behavior for now.

I think we shouldn't stick on old behaviour here, as there obviously was 
an error in old code, but nobody filed a bug until now.

>
> Alan, Martin, I need you guys also help review the change, I will need 
> a name on the putback message.

I would be happy to see my name in 2nd/3rd position. :-)

-Ulf




From martinrb at google.com  Thu May 21 20:20:27 2009
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 21 May 2009 13:20:27 -0700
Subject: Rewrite of IBM doublebyte charsets
In-Reply-To: <4A15B561.2010301@gmx.de>
References: <49FA9B45.8020802@sun.com> <4A09C748.6070302@gmx.de>
	<4A09CEBD.3050703@sun.com> <4A09FF75.4010400@gmx.de>
	<4A0A4197.4030503@sun.com> <4A0C8294.7020602@gmx.de>
	<4A0C8542.10503@sun.com> <4A105530.80201@gmx.de>
	<4A14828C.1000101@sun.com> <4A15B561.2010301@gmx.de>
Message-ID: <1ccfd1c10905211320x2a4f0a36h860772d21c1774d9@mail.gmail.com>

On Thu, May 21, 2009 at 13:11, Ulf Zibis <Ulf.Zibis at gmx.de> wrote:

>
>> Alan, Martin, I need you guys also help review the change, I will need a
>> name on the putback message.
>>
>
> I would be happy to see my name in 2nd/3rd position. :-)


I would be happy to see Ulf's name in first position.
Let's have a CFV to add Ulf to core-libs-dev.

Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090521/f5524dd2/attachment.html>

From Ulf.Zibis at gmx.de  Thu May 21 20:24:36 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Thu, 21 May 2009 22:24:36 +0200
Subject: Rewrite of IBM doublebyte charsets
In-Reply-To: <4A15B103.8090509@sun.com>
References: <49FA9B45.8020802@sun.com> <4A09C096.8000505@sun.com>
	<4A09C748.6070302@gmx.de> <4A09CEBD.3050703@sun.com>
	<4A09FF75.4010400@gmx.de> <4A0A4197.4030503@sun.com>
	<4A0C8294.7020602@gmx.de> <4A0C8542.10503@sun.com>
	<4A105530.80201@gmx.de> <4A14828C.1000101@sun.com>
	<1ccfd1c10905201627r331ebbcj3561ed08e0408172@mail.gmail.com>
	<4A1496B3.4070708@sun.com> <4A15ABDA.1080104@gmx.de>
	<4A15B103.8090509@sun.com>
Message-ID: <4A15B884.2020001@gmx.de>

Am 21.05.2009 21:52, Xueming Shen schrieb:
> Ulf Zibis wrote:
>> Am 21.05.2009 01:48, Xueming Shen schrieb:
>>> Thanks for the 5 minutes:-)
>>>
>>> Your FindXYZcoderBugs tests are indeed very helpful to catch most of 
>>> the "inconsistent" behaviors
>>> between different paths by feeding the "random" inputs.
>>>
>>> The TestIBMDB.java is diffing the behaviors of old implementation 
>>> and new implementation
>>> with all "decode-able" bytes and "encode-able" chars...so it gives 
>>> us some of the guarantee.
>>
>> Why do we *try* to stick on old behaviour in case of malformed and/or 
>> unmappable input, if we don't diff new against old ?
>> Then we also could *try*, to treat malformed and/or unmappable input 
>> most accurate.
>> As you mentioned, most users don't distinguish between those, so they 
>> won't be affected. On the other hand, user's, who did this 
>> distinction, would probably happy to return more accurate results, 
>> even if not identical to recent results.
>>
> This is the approach/plan I decided to go with to achieve the goals I 
> listed last time. Sticking with the old behavior for
> now make it easy, or say possible, to push in such a big change.

I happily can agree with this. Thanks for your further detailed 
explanation. :-)

> You don't want to be stuck on this kind of "arguable"
> issues when it's not the main goal of the project, detour yourself  to 
> defend/argue whether or not this is the "correct"
> change,  if it's correct,  then is this the right thing to do to break 
> the compatibility, is there people depend on them. If
> you just start a new implementation, you definitely should do all the 
> "right" things. It is a different story when you
> maintenance some existing products. As I said last time, with this 
> change, the implementation, the data structure are
> now real open and ready for further optimization (instead of looking 
> at a big chunk of data without knowledge where
> they come from), you can  now work on the issue, if any, one by one, 
> including starting the argument of which error
> should be "malformed" and which one should "unmapped". We're (I'm) 60% 
> done after this:-)


-Ulf




From Ulf.Zibis at gmx.de  Thu May 21 20:29:35 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Thu, 21 May 2009 22:29:35 +0200
Subject: Rewrite of EUC_TW
In-Reply-To: <4A0DD495.1060405@sun.com>
References: <49FA9B45.8020802@sun.com> <4A075BD6.5020909@gmx.de>
	<4A09179D.1020308@sun.com> <4A09BF0B.60702@gmx.de>
	<4A09C096.8000505@sun.com> <4A09C748.6070302@gmx.de>
	<4A09CEBD.3050703@sun.com> <4A09FF75.4010400@gmx.de>
	<4A0A4197.4030503@sun.com> <4A0C8294.7020602@gmx.de>
	<4A0C8542.10503@sun.com> <4A0DD3D0.1010206@gmx.de>
	<4A0DD495.1060405@sun.com>
Message-ID: <4A15B9AF.4070804@gmx.de>

Sherman, could you please update this link.

Please also include EUC_TW generated mapping.

Better: Please zip them in 1 file to simplify the download for me.

-Ulf


Am 15.05.2009 22:46, Xueming Shen schrieb:
> http://cr.openjdk.java.net/~sherman/ibmdb/gensrc/ext/
>
> Ulf Zibis wrote:
>> Sherman,
>>
>> could you send/link me please generated DoubleByte-X.java files?
>>
>> -Ulf
>>
>>
>> Am 14.05.2009 22:55, Xueming Shen schrieb:
>>> Thanks again for taking time on this. Here is the IBM db charsets 
>>> webrev
>>>
>>> http://cr.openjdk.java.net/~sherman/ibmdb/webrev
>>>
>>> This is a bigger fish than the EUC_TW:-)
>>>
>>>
>>
>
>



From Xueming.Shen at Sun.COM  Thu May 21 20:43:01 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Thu, 21 May 2009 13:43:01 -0700
Subject: Rewrite of IBM doublebyte charsets
In-Reply-To: <4A15B561.2010301@gmx.de>
References: <49FA9B45.8020802@sun.com> <4A075BD6.5020909@gmx.de>
	<4A09179D.1020308@sun.com> <4A09BF0B.60702@gmx.de>
	<4A09C096.8000505@sun.com>
	<4A09C748.6070302@gmx.de> <4A09CEBD.3050703@sun.com>
	<4A09FF75.4010400@gmx.de>
	<4A0A4197.4030503@sun.com> <4A0C8294.7020602@gmx.de>
	<4A0C8542.10503@sun.com>
	<4A105530.80201@gmx.de> <4A14828C.1000101@sun.com>
	<4A15B561.2010301@gmx.de>
Message-ID: <4A15BCD5.7000306@sun.com>

Ulf Zibis wrote:
> Am 21.05.2009 00:22, Xueming Shen schrieb:
>> Ulf, thanks for the review!
>>
>> Now we have a bugid for this one.
>
> Good idea! I set it on my watch list.
>
>> With this change,
>> (1)21% reduce of rt.jar size (from 2.99M-with the euc_tw reduce to 
>> 2.35M)
>
> ???  My rt.jar is 46 MB. Can you explain your numbers?
>
typo. I was talking about charsets.jar. my apology.


From Xueming.Shen at Sun.COM  Thu May 21 20:47:35 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Thu, 21 May 2009 13:47:35 -0700
Subject: Rewrite of IBM doublebyte charsets
In-Reply-To: <4A15B561.2010301@gmx.de>
References: <49FA9B45.8020802@sun.com> <4A075BD6.5020909@gmx.de>
	<4A09179D.1020308@sun.com> <4A09BF0B.60702@gmx.de>
	<4A09C096.8000505@sun.com>
	<4A09C748.6070302@gmx.de> <4A09CEBD.3050703@sun.com>
	<4A09FF75.4010400@gmx.de>
	<4A0A4197.4030503@sun.com> <4A0C8294.7020602@gmx.de>
	<4A0C8542.10503@sun.com>
	<4A105530.80201@gmx.de> <4A14828C.1000101@sun.com>
	<4A15B561.2010301@gmx.de>
Message-ID: <4A15BDE7.1070604@sun.com>

Ulf Zibis wrote:
>> Alan, Martin, I need you guys also help review the change, I will 
>> need a name on the putback message.
>
>
> I would be happy to see my name in 2nd/3rd position. :-)

Sorry about that, your name definitely should be there, but the tool 
does not let me do that:-(
I tried to add "reviewed also by Ulf" into the contributued-by line, but 
got refused as well, seem
like it only accepts email address. Alan suggested me now try put your  
name into the "summary
line" to acknowledge your contribution.

>
> -Ulf
>
>



From Xueming.Shen at Sun.COM  Thu May 21 22:30:36 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Thu, 21 May 2009 15:30:36 -0700
Subject: Rewrite of IBM doublebyte charsets
In-Reply-To: <4A15B561.2010301@gmx.de>
References: <49FA9B45.8020802@sun.com> <4A075BD6.5020909@gmx.de>
	<4A09179D.1020308@sun.com> <4A09BF0B.60702@gmx.de>
	<4A09C096.8000505@sun.com>
	<4A09C748.6070302@gmx.de> <4A09CEBD.3050703@sun.com>
	<4A09FF75.4010400@gmx.de>
	<4A0A4197.4030503@sun.com> <4A0C8294.7020602@gmx.de>
	<4A0C8542.10503@sun.com>
	<4A105530.80201@gmx.de> <4A14828C.1000101@sun.com>
	<4A15B561.2010301@gmx.de>
Message-ID: <4A15D60C.3010803@sun.com>

Ulf Zibis wrote:
> In IBM933.map you state:
>
> #    Warning:
> #    (2) we "should" have an entry
> #        25  000a
> #        in IBM933.nr (b->c only tables) as other ebcdic
> #        mappings do, but the "old" implementation actually
> #        maps \u000a to 25. Keep it old behavior for now.
>
> I think we shouldn't stick on old behaviour here, as there obviously 
> was an error in old code, but nobody filed a bug until now.
>

It's a tough call, and I always try to avoid the touch call:-)

I believe this brain-damage 0x15, 0x25 -> 000a -> 0x15, 0085->0x15 
mapping is the result of the
"fix" we made for #4159519, as the workaround solution for the "what is 
the real new line on ebcdic
system" problem, while none of the official ebcdic<->unicode mapping 
tables from IBM/MSFT do
NOT have this hack documented/recorded at all. So we might want to 
re-check the soundness of
this fix, which was made 10 years ago, sometime.

Sherman



From Xueming.Shen at Sun.COM  Thu May 21 22:33:44 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Thu, 21 May 2009 15:33:44 -0700
Subject: Rewrite of IBM doublebyte charsets
In-Reply-To: <4A15D60C.3010803@sun.com>
References: <49FA9B45.8020802@sun.com> <4A075BD6.5020909@gmx.de>
	<4A09179D.1020308@sun.com> <4A09BF0B.60702@gmx.de>
	<4A09C096.8000505@sun.com>
	<4A09C748.6070302@gmx.de> <4A09CEBD.3050703@sun.com>
	<4A09FF75.4010400@gmx.de>
	<4A0A4197.4030503@sun.com> <4A0C8294.7020602@gmx.de>
	<4A0C8542.10503@sun.com>
	<4A105530.80201@gmx.de> <4A14828C.1000101@sun.com>
	<4A15B561.2010301@gmx.de> <4A15D60C.3010803@sun.com>
Message-ID: <4A15D6C8.6060002@sun.com>

Xueming Shen wrote:
> Ulf Zibis wrote:
>> In IBM933.map you state:
>>
>> #    Warning:
>> #    (2) we "should" have an entry
>> #        25  000a
>> #        in IBM933.nr (b->c only tables) as other ebcdic
>> #        mappings do, but the "old" implementation actually
>> #        maps \u000a to 25. Keep it old behavior for now.
>>
>> I think we shouldn't stick on old behaviour here, as there obviously 
>> was an error in old code, but nobody filed a bug until now.
>>
>
> It's a tough call, and I always try to avoid the touch call:-)
>
> I believe this brain-damage 0x15, 0x25 -> 000a -> 0x15, 0085->0x15 
> mapping is the result of the
> "fix" we made for #4159519, as the workaround solution for the "what 
> is the real new line on ebcdic
> system" problem, while none of the official ebcdic<->unicode mapping 
> tables from IBM/MSFT do
> NOT have this hack documented/recorded at all. So we might want to 
> re-check the soundness of
I meant to say
"none of the official ebcdic<->unicode mapping tables from IBM/MSFT has 
this hack documented/recorded"


> this fix, which was made 10 years ago, sometime.
>
> Sherman
>



From Ulf.Zibis at gmx.de  Thu May 21 23:41:24 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Fri, 22 May 2009 01:41:24 +0200
Subject: Rewrite of IBM doublebyte charsets
In-Reply-To: <4A14828C.1000101@sun.com>
References: <49FA9B45.8020802@sun.com> <4A075BD6.5020909@gmx.de>
	<4A09179D.1020308@sun.com> <4A09BF0B.60702@gmx.de>
	<4A09C096.8000505@sun.com> <4A09C748.6070302@gmx.de>
	<4A09CEBD.3050703@sun.com> <4A09FF75.4010400@gmx.de>
	<4A0A4197.4030503@sun.com> <4A0C8294.7020602@gmx.de>
	<4A0C8542.10503@sun.com> <4A105530.80201@gmx.de>
	<4A14828C.1000101@sun.com>
Message-ID: <4A15E6A4.3060102@gmx.de>

Am 21.05.2009 00:22, Xueming Shen schrieb:
>
> Ulf Zibis wrote:
>>
>> (6) Unload b2cStr from memory after startup:
>>    - outsource b2cStr to additional class file like EUC_TW approach
>>    - set b2cStr = null after startup (remove final modifier)
>>   Benefit[6]: avoid 100 % superfluous memory-footprint
>>
> I doubt it really saves something real, since the "class" should still 
> keep its copy somewhere...and
> I will need it for c2b (now I'm "delaying" the c2b init)

I always thought, setting an object to null after use, it would be 
automatically GCed. Am I wrong?
... but we can do c2binit from b2c[][] instead from b2cstr[], so why 
saving it.

>
>> (7) Avoid copying b2cStr to b2c:
>>    (String#charAt() is fast as char[] access)
>>   Benefit[7]: increase startup performance for decoder
>>
> I tried again last night. char[][] is much faster than the String[] 
> version in both client
> and server vm. So keep it asis. (this was actually I switched from 
> String[] to char[][])

I'm surprised, because I had in mind from older benchmarks, that 
char_array[index] had same speed than str.charAt(index) after 
optimization from hotspot.
I also had this results here: 
https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/array_io_string/src/sun/nio/cs/SingleByteFastDecoder.java?rev=&view=markup


>
>> (12) Get rid of sun.io package dependency:
>>   
>> https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/tags/milestone2/src/sun/io/ 
>>
>>   Benefit[13]: avoid superfluous disk-footprint
>>   Benefit[14]: save maintenance of sun.io converters
>>   Disadvantage[1]: published under JRL (waiting for launch of 
>> OpenJDK-7 project "charset-enhancement") ;-)
>>
> This is not something about engineering. It's about license, policy...

So hopefully we would have OpenJDK7 project "charset-enhancement" soon.

>
>>
>> (17) Decoder#decodeArrayLoop: shortcut for single byte only:
>>      int sr = src.remaining();
>>      int sl = sp + sr;
>>      int dr = dst.remaining();
>>      int dl = dp + dr;
>>      // single byte only loop
>>      int slSB = sp + sr < dr ? sr : dr;
>>      while (sp < slSB) {
>>          char c = b2cSB[sa[sp] && 0xff];
>>          if (c == UNMAPPABLE_DECODING)
>>              break;
>>          da[dp++] = c;
>>          sp++;
>>      }
>>     Same for Encoder#encodeArrayLoop
>>
>> (18) Decoder_EBCDIC: boolean singlebyteState:
>>      if (singlebyteState)
>>          ...
>>
>> (19) Decoder_EBCDIC: decode single byte first:
>>      if (singlebyteState)
>>          c = b2cSB[b1];
>>      if (c == UNMAPPABLE_DECODING) {
>>          ...
>>      }
>>   Benefit[20]: should be faster
>>
>>
> Not like when we dealing with singlebyte charsets. For doublebyte 
> charsets
> the priority should be given to doublebyte codepoints, if possible. 
> Not single
> byte codepoints.

- I am in assumption that having singlebyte-only input is common use 
case. Am I wrong in case of EBCDIC ?
- This hack doesn't make processing of "normal" mixed input slower after 
escaping to "normal" while(...)-loop.
- This hack was copied from UTF-8 coder, where ASCII-only input is 
common use case.

>
>
>> *** Encoder-Suggestions:
>>
>> (21) join *.nr to *.c2b files (25->000a becomes 000a->fffd):
>>   Benefit[21]: reduce no. of files
>>   Benefit[22]: simplifies initC2B() (avoids 2 loops)
>>
> In theory you can do some magic to "join" .nr into .c2b. The price 
> might be more complicated
> logic depends on the codepoints. You may end up doing some table 
> lookup for each codepoint
> in b2c when processing.

This "magic" should be done in GenerateDBCS.java, so the price must only 
be paid once while building the JDK. But to be honest, it could be done 
by hand, for those few mapping pairs. See my single-byte IBMxxx mappings 
here:
https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/make/tools/CharsetMapping/ext/
... and don't forget, it prevents from copying the whole b2c.

>
> And big thanks for all the suggestions.
>

Thanks for your appreciation. :-)

-Ulf




From Ulf.Zibis at gmx.de  Thu May 21 23:57:05 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Fri, 22 May 2009 01:57:05 +0200
Subject: Rewrite of IBM doublebyte charsets
In-Reply-To: <4A15D60C.3010803@sun.com>
References: <49FA9B45.8020802@sun.com> <4A075BD6.5020909@gmx.de>
	<4A09179D.1020308@sun.com> <4A09BF0B.60702@gmx.de>
	<4A09C096.8000505@sun.com> <4A09C748.6070302@gmx.de>
	<4A09CEBD.3050703@sun.com> <4A09FF75.4010400@gmx.de>
	<4A0A4197.4030503@sun.com> <4A0C8294.7020602@gmx.de>
	<4A0C8542.10503@sun.com> <4A105530.80201@gmx.de>
	<4A14828C.1000101@sun.com> <4A15B561.2010301@gmx.de>
	<4A15D60C.3010803@sun.com>
Message-ID: <4A15EA51.5030600@gmx.de>



Am 22.05.2009 00:30, Xueming Shen schrieb:
> Ulf Zibis wrote:
>> In IBM933.map you state:
>>
>> #    Warning:
>> #    (2) we "should" have an entry
>> #        25  000a
>> #        in IBM933.nr (b->c only tables) as other ebcdic
>> #        mappings do, but the "old" implementation actually
>> #        maps \u000a to 25. Keep it old behavior for now.
>>
>> I think we shouldn't stick on old behaviour here, as there obviously 
>> was an error in old code, but nobody filed a bug until now.
>>
>
> It's a tough call, and I always try to avoid the touch call:-)
>
> I believe this brain-damage 0x15, 0x25 -> 000a -> 0x15, 0085->0x15 
> mapping is the result of the
> "fix" we made for #4159519, as the workaround solution for the "what 
> is the real new line on ebcdic
> system" problem, while none of the official ebcdic<->unicode mapping 
> tables from IBM/MSFT do
> NOT have this hack documented/recorded at all. So we might want to 
> re-check the soundness of
> this fix, which was made 10 years ago, sometime.

So IBM933 mapping *or* all other IBMxxx mappings should be corrected in 
future ?

-Ulf




From Ulf.Zibis at gmx.de  Fri May 22 00:06:21 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Fri, 22 May 2009 02:06:21 +0200
Subject: Rewrite of IBM doublebyte charsets
In-Reply-To: <4A15BDE7.1070604@sun.com>
References: <49FA9B45.8020802@sun.com> <4A075BD6.5020909@gmx.de>
	<4A09179D.1020308@sun.com> <4A09BF0B.60702@gmx.de>
	<4A09C096.8000505@sun.com> <4A09C748.6070302@gmx.de>
	<4A09CEBD.3050703@sun.com> <4A09FF75.4010400@gmx.de>
	<4A0A4197.4030503@sun.com> <4A0C8294.7020602@gmx.de>
	<4A0C8542.10503@sun.com> <4A105530.80201@gmx.de>
	<4A14828C.1000101@sun.com> <4A15B561.2010301@gmx.de>
	<4A15BDE7.1070604@sun.com>
Message-ID: <4A15EC7D.6050204@gmx.de>

Am 21.05.2009 22:47, Xueming Shen schrieb:
> Ulf Zibis wrote:
>>> Alan, Martin, I need you guys also help review the change, I will 
>>> need a name on the putback message.
>>
>>
>> I would be happy to see my name in 2nd/3rd position. :-)
>
> Sorry about that, your name definitely should be there, but the tool 
> does not let me do that:-(
> I tried to add "reviewed also by Ulf" into the contributued-by line, 
> but got refused as well, seem
> like it only accepts email address.

Much thanks on trying this.

> Alan suggested me now try put your  name into the "summary
> line" to acknowledge your contribution.

I didn't know about "contributued-by" (attention on typo ;-)) tag at 
all, I only recognized "reviewed-by" tag.
Maybe you can add 'ulfzibis' (My SDN + java.net account name) as 2nd in 
"reviewed-by" tag, or do "reviewed-by" twice in additional line.

-Ulf




From Ulf.Zibis at gmx.de  Fri May 22 00:21:31 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Fri, 22 May 2009 02:21:31 +0200
Subject: Rewrite of IBM doublebyte charsets
In-Reply-To: <4A15E6A4.3060102@gmx.de>
References: <49FA9B45.8020802@sun.com>
	<4A075BD6.5020909@gmx.de>	<4A09179D.1020308@sun.com>
	<4A09BF0B.60702@gmx.de>	<4A09C096.8000505@sun.com>
	<4A09C748.6070302@gmx.de>	<4A09CEBD.3050703@sun.com>
	<4A09FF75.4010400@gmx.de>	<4A0A4197.4030503@sun.com>
	<4A0C8294.7020602@gmx.de>	<4A0C8542.10503@sun.com>
	<4A105530.80201@gmx.de>	<4A14828C.1000101@sun.com>
	<4A15E6A4.3060102@gmx.de>
Message-ID: <4A15F00B.2030902@gmx.de>

Am 22.05.2009 01:41, Ulf Zibis schrieb:
> Am 21.05.2009 00:22, Xueming Shen schrieb:
>>
>> Ulf Zibis wrote:
>>
>>> (7) Avoid copying b2cStr to b2c:
>>>    (String#charAt() is fast as char[] access)
>>>   Benefit[7]: increase startup performance for decoder
>>>
>> I tried again last night. char[][] is much faster than the String[] 
>> version in both client
>> and server vm. So keep it asis. (this was actually I switched from 
>> String[] to char[][])
>
> I'm surprised, because I had in mind from older benchmarks, that 
> char_array[index] had same speed than str.charAt(index) after 
> optimization from hotspot.
> I also had this results here: 
> https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/array_io_string/src/sun/nio/cs/SingleByteFastDecoder.java?rev=&view=markup 
>
>

Maybe hotspot doesn't optimize here, because initC2B() only runs once, 
but later in de/encoder loops .... wouldn't str.charAt(index) be 
optimized by hotspot to same speed?

-Ulf




From David.Holmes at Sun.COM  Fri May 22 02:05:49 2009
From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems)
Date: Fri, 22 May 2009 12:05:49 +1000
Subject: c.toArray might (incorrectly) not return Object[] (see 6260652)
In-Reply-To: <87pre2nzls.fsf@mid.deneb.enyo.de>
References: <87pre2nzls.fsf@mid.deneb.enyo.de>
Message-ID: <4A16087D.60205@sun.com>

Florian Weimer said the following on 05/22/09 03:18:
> So says the ArrayList(Collection) constructor.  Can this bug report be
> opened?  Is this workaround still necessary?

I'm confused. The bug states:

     The Collection documentation claims that

         collection.toArray()

     is "identical in function" to

         collection.toArray(new Object[0]);

but I checked the Collection documentation back to 1.4.2 and it doesn't 
say anything like that as far as I can see.

But as far as I can tell from the code the implementation is unchanged. 
toArray() will "clone" the internal array and so if you really want 
Object[] you have use toArray(someObjectArray)

HTH

David Holmes


From fw at deneb.enyo.de  Fri May 22 04:46:07 2009
From: fw at deneb.enyo.de (Florian Weimer)
Date: Fri, 22 May 2009 06:46:07 +0200
Subject: c.toArray might (incorrectly) not return Object[] (see 6260652)
In-Reply-To: <4A16087D.60205@sun.com> (David Holmes's message of "Fri, 22 May
	2009 12:05:49 +1000")
References: <87pre2nzls.fsf@mid.deneb.enyo.de> <4A16087D.60205@sun.com>
Message-ID: <87skix3fu8.fsf@mid.deneb.enyo.de>

* David Holmes:

> Florian Weimer said the following on 05/22/09 03:18:
>> So says the ArrayList(Collection) constructor.  Can this bug report be
>> opened?  Is this workaround still necessary?
>
> I'm confused. The bug states:

Is the bug about the add method failing with an ArrayStoreException?

>     The Collection documentation claims that
>
>         collection.toArray()
>
>     is "identical in function" to
>
>         collection.toArray(new Object[0]);
>
> but I checked the Collection documentation back to 1.4.2 and it
> doesn't say anything like that as far as I can see.

It's there, but not in the documentation for toArray():

| Note that toArray(new Object[0]) is identical in function to toArray().

<http://java.sun.com/j2se/1.4.2/docs/api/java/util/Collection.html#toArray(java.lang.Object[])>
<http://java.sun.com/j2se/1.5.0/docs/api/java/util/Collection.html#toArray(T[])>


From David.Holmes at Sun.COM  Fri May 22 04:56:18 2009
From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems)
Date: Fri, 22 May 2009 14:56:18 +1000
Subject: c.toArray might (incorrectly) not return Object[] (see 6260652)
In-Reply-To: <87skix3fu8.fsf@mid.deneb.enyo.de>
References: <87pre2nzls.fsf@mid.deneb.enyo.de> <4A16087D.60205@sun.com>
	<87skix3fu8.fsf@mid.deneb.enyo.de>
Message-ID: <4A163072.5040309@sun.com>

Florian Weimer said the following on 05/22/09 14:46:
> It's there, but not in the documentation for toArray():
> 
> | Note that toArray(new Object[0]) is identical in function to toArray().
> 
> <http://java.sun.com/j2se/1.4.2/docs/api/java/util/Collection.html#toArray(java.lang.Object[])>
> <http://java.sun.com/j2se/1.5.0/docs/api/java/util/Collection.html#toArray(T[])>

Ah I see - thanks.

Okay well the bug is still open. I think the original intent was to 
change toArray() to match this, but I think it's far too late to change 
that behaviour now. So the only "fix" is to delete that sentence from 
the javadoc.

Were you looking for an actual change in the implementation?

Note this is just my opinion on this, I'm not a decision maker here :)

Cheers,
David


From xueming.shen at sun.com  Fri May 22 06:56:01 2009
From: xueming.shen at sun.com (xueming.shen at sun.com)
Date: Fri, 22 May 2009 06:56:01 +0000
Subject: hg: jdk7/tl/jdk: 6843578: Re-implement IBM doublebyte charsets; ...
Message-ID: <20090522065637.004DBE7AA@hg.openjdk.java.net>

Changeset: 914c33c7de3e
Author:    sherman
Date:      2009-05-21 23:32 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/914c33c7de3e

6843578: Re-implement IBM doublebyte charsets
6639450: IBM949C encoder modifies state of IBM949 encoder
6569191: Cp943 io converter returns U+0000 and U+FFFD for unconvertable character
6577466: Character encoder IBM970 throws a BufferOverflowException
5065777: CharsetEncoder canEncode() methods often incorrectly return false
Summary: Re-write 11 IBM doublebyte charsets. Thanks Ulf.Zibis for the codereview!
Reviewed-by: martin

! make/sun/nio/FILES_java.gmk
! make/sun/nio/Makefile
+ make/tools/CharsetMapping/DoubleByte-X.java
+ make/tools/CharsetMapping/IBM1381.c2b
+ make/tools/CharsetMapping/IBM1381.map
+ make/tools/CharsetMapping/IBM1383.c2b
+ make/tools/CharsetMapping/IBM1383.map
+ make/tools/CharsetMapping/IBM1383.nr
+ make/tools/CharsetMapping/IBM930.c2b
+ make/tools/CharsetMapping/IBM930.map
+ make/tools/CharsetMapping/IBM930.nr
+ make/tools/CharsetMapping/IBM933.c2b
+ make/tools/CharsetMapping/IBM933.map
+ make/tools/CharsetMapping/IBM935.c2b
+ make/tools/CharsetMapping/IBM935.map
+ make/tools/CharsetMapping/IBM935.nr
+ make/tools/CharsetMapping/IBM937.c2b
+ make/tools/CharsetMapping/IBM937.map
+ make/tools/CharsetMapping/IBM937.nr
+ make/tools/CharsetMapping/IBM939.c2b
+ make/tools/CharsetMapping/IBM939.map
+ make/tools/CharsetMapping/IBM939.nr
+ make/tools/CharsetMapping/IBM942.c2b
+ make/tools/CharsetMapping/IBM942.map
+ make/tools/CharsetMapping/IBM943.map
+ make/tools/CharsetMapping/IBM943.nr
+ make/tools/CharsetMapping/IBM948.c2b
+ make/tools/CharsetMapping/IBM948.map
+ make/tools/CharsetMapping/IBM949.map
+ make/tools/CharsetMapping/IBM950.c2b
+ make/tools/CharsetMapping/IBM950.map
+ make/tools/CharsetMapping/IBM970.c2b
+ make/tools/CharsetMapping/IBM970.map
+ make/tools/CharsetMapping/dbcs
+ make/tools/src/build/tools/charsetmapping/GenerateDBCS.java
! make/tools/src/build/tools/charsetmapping/Main.java
! src/share/classes/sun/io/ByteToCharCp1381.java
! src/share/classes/sun/io/ByteToCharCp1383.java
! src/share/classes/sun/io/ByteToCharCp834.java
! src/share/classes/sun/io/ByteToCharCp930.java
! src/share/classes/sun/io/ByteToCharCp933.java
! src/share/classes/sun/io/ByteToCharCp935.java
! src/share/classes/sun/io/ByteToCharCp937.java
! src/share/classes/sun/io/ByteToCharCp939.java
! src/share/classes/sun/io/ByteToCharCp942.java
! src/share/classes/sun/io/ByteToCharCp942C.java
! src/share/classes/sun/io/ByteToCharCp943.java
! src/share/classes/sun/io/ByteToCharCp943C.java
! src/share/classes/sun/io/ByteToCharCp948.java
! src/share/classes/sun/io/ByteToCharCp949.java
! src/share/classes/sun/io/ByteToCharCp949C.java
! src/share/classes/sun/io/ByteToCharCp950.java
! src/share/classes/sun/io/ByteToCharCp970.java
! src/share/classes/sun/io/ByteToCharDBCS_ASCII.java
! src/share/classes/sun/io/ByteToCharDBCS_EBCDIC.java
+ src/share/classes/sun/io/ByteToCharEUC2.java
! src/share/classes/sun/io/CharToByteCp1381.java
! src/share/classes/sun/io/CharToByteCp1383.java
! src/share/classes/sun/io/CharToByteCp834.java
! src/share/classes/sun/io/CharToByteCp930.java
! src/share/classes/sun/io/CharToByteCp933.java
! src/share/classes/sun/io/CharToByteCp935.java
! src/share/classes/sun/io/CharToByteCp937.java
! src/share/classes/sun/io/CharToByteCp939.java
! src/share/classes/sun/io/CharToByteCp942.java
! src/share/classes/sun/io/CharToByteCp942C.java
! src/share/classes/sun/io/CharToByteCp943.java
! src/share/classes/sun/io/CharToByteCp943C.java
! src/share/classes/sun/io/CharToByteCp948.java
! src/share/classes/sun/io/CharToByteCp949.java
! src/share/classes/sun/io/CharToByteCp949C.java
! src/share/classes/sun/io/CharToByteCp950.java
! src/share/classes/sun/io/CharToByteCp970.java
! src/share/classes/sun/io/CharToByteDBCS_ASCII.java
! src/share/classes/sun/io/CharToByteDBCS_EBCDIC.java
- src/share/classes/sun/nio/cs/ext/DBCSDecoderMapping.java
- src/share/classes/sun/nio/cs/ext/DBCS_IBM_ASCII_Decoder.java
- src/share/classes/sun/nio/cs/ext/DBCS_IBM_ASCII_Encoder.java
- src/share/classes/sun/nio/cs/ext/DBCS_IBM_EBCDIC_Decoder.java
- src/share/classes/sun/nio/cs/ext/DBCS_IBM_EBCDIC_Encoder.java
- src/share/classes/sun/nio/cs/ext/DBCS_ONLY_IBM_EBCDIC_Decoder.java
+ src/share/classes/sun/nio/cs/ext/DoubleByte.java
- src/share/classes/sun/nio/cs/ext/IBM1381.java
- src/share/classes/sun/nio/cs/ext/IBM1383.java
! src/share/classes/sun/nio/cs/ext/IBM834.java
- src/share/classes/sun/nio/cs/ext/IBM930.java
- src/share/classes/sun/nio/cs/ext/IBM933.java
- src/share/classes/sun/nio/cs/ext/IBM935.java
- src/share/classes/sun/nio/cs/ext/IBM937.java
- src/share/classes/sun/nio/cs/ext/IBM939.java
- src/share/classes/sun/nio/cs/ext/IBM942.java
! src/share/classes/sun/nio/cs/ext/IBM942C.java
- src/share/classes/sun/nio/cs/ext/IBM943.java
! src/share/classes/sun/nio/cs/ext/IBM943C.java
- src/share/classes/sun/nio/cs/ext/IBM948.java
- src/share/classes/sun/nio/cs/ext/IBM949.java
! src/share/classes/sun/nio/cs/ext/IBM949C.java
- src/share/classes/sun/nio/cs/ext/IBM950.java
- src/share/classes/sun/nio/cs/ext/IBM970.java
- src/share/classes/sun/nio/cs/ext/SimpleEUCDecoder.java
! test/sun/nio/cs/FindCanEncodeBugs.java
! test/sun/nio/cs/FindEncoderBugs.java
+ test/sun/nio/cs/OLD/DBCSDecoderMapping.java
+ test/sun/nio/cs/OLD/DBCS_IBM_ASCII_Decoder.java
+ test/sun/nio/cs/OLD/DBCS_IBM_ASCII_Encoder.java
+ test/sun/nio/cs/OLD/DBCS_IBM_EBCDIC_Decoder.java
+ test/sun/nio/cs/OLD/DBCS_IBM_EBCDIC_Encoder.java
+ test/sun/nio/cs/OLD/DBCS_ONLY_IBM_EBCDIC_Decoder.java
+ test/sun/nio/cs/OLD/IBM1381_OLD.java
+ test/sun/nio/cs/OLD/IBM1383_OLD.java
+ test/sun/nio/cs/OLD/IBM930_OLD.java
+ test/sun/nio/cs/OLD/IBM933_OLD.java
+ test/sun/nio/cs/OLD/IBM935_OLD.java
+ test/sun/nio/cs/OLD/IBM937_OLD.java
+ test/sun/nio/cs/OLD/IBM939_OLD.java
+ test/sun/nio/cs/OLD/IBM942C_OLD.java
+ test/sun/nio/cs/OLD/IBM942_OLD.java
+ test/sun/nio/cs/OLD/IBM943C_OLD.java
+ test/sun/nio/cs/OLD/IBM943_OLD.java
+ test/sun/nio/cs/OLD/IBM948_OLD.java
+ test/sun/nio/cs/OLD/IBM949C_OLD.java
+ test/sun/nio/cs/OLD/IBM949_OLD.java
+ test/sun/nio/cs/OLD/IBM950_OLD.java
+ test/sun/nio/cs/OLD/IBM970_OLD.java
+ test/sun/nio/cs/OLD/SimpleEUCDecoder.java
+ test/sun/nio/cs/OLD/TestIBMDB.java
! test/sun/nio/cs/TestEUC_TW.java
! test/sun/nio/cs/TestIBMBugs.java



From Michael.McMahon at Sun.COM  Fri May 22 10:05:15 2009
From: Michael.McMahon at Sun.COM (Michael McMahon)
Date: Fri, 22 May 2009 11:05:15 +0100
Subject: Review request for 5049299
Message-ID: <4A1678DB.9010209@sun.com>

Hi,

I have just posted a webrev for 5049299: (process) Use posix_spawn, not 
fork, on S10 to avoid swap exhaustion.

webrev location: http://cr.openjdk.java.net/~michaelm/5049299/webrev.00/

**I'd like to give an outline of the change here, to make reviewing the 
webrev a bit easier.
Basically, while posix_spawn() is a fairly elaborate and complicated 
system call, it can't quite do
everything that the old fork()/exec() combination can do, so the only 
feasible way to do this, is to
use posix_spawn to launch a new helper executable "processhelper", which 
in turn execs the
target (after cleaning up file-descriptors etc.) The end result is the 
same as before, a child process
linked to the parent in the same way, but it avoids the problem of 
duplicating the parent (VM) process
address space temporarily, before launching the target command.

In the original implementation, the native code for 
UNIXProcess.forkAndExec() was the same
for both Linux and Solaris.  Now, we have split it, so that Linux 
retains the original implementation
but for Solaris, the native method is renamed spawn() where the 
implementation is partly in this function,
but also partly in the new processhelper binary, which is spawned by the 
spawn() method.

A number of utility functions, which were originally in 
UNIXProcess_md.c, are also needed by the
processhelper binary, have been moved into new source files 
(processutil_md.[ch]).
Because the functions were originally static in UNIXProcess_md.c, a 
prefix is added to their names (jlup_)
(from initials of java.lang.UNIXProcess), to avoid any conflict in 
global scope. This applies to the Linux
version as well as the Solaris version. So, this looks like new code, 
but the body of these functions
are not changed from before.

I'm proposing not to add any unit/regression tests for this change, 
since the point of it
is kind of self-evident from the source code (ie. stop using fork() and 
use posix_spawn() instead),
and there shouldn't be any behaviour change other than memory usage.
This area of the platform seems to be well covered by existing 
regression/unit tests.

Hope this helps,
Thanks,
Michael.



From Ulf.Zibis at gmx.de  Fri May 22 10:22:06 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Fri, 22 May 2009 12:22:06 +0200
Subject: hg: jdk7/tl/jdk: 6843578: Re-implement IBM doublebyte charsets;
	...
In-Reply-To: <20090522065637.004DBE7AA@hg.openjdk.java.net>
References: <20090522065637.004DBE7AA@hg.openjdk.java.net>
Message-ID: <4A167CCE.2070500@gmx.de>

Very BIG THING !

... my browser nearly collapsed.

I think I have forgotten one thing:

isisDoubleByte() in DoubleByte uses hard-wired values. Shouldn't they be 
better b1Min etc. ?

-Ulf



Am 22.05.2009 08:56, xueming.shen at sun.com schrieb:
> Changeset: 914c33c7de3e
> Author:    sherman
> Date:      2009-05-21 23:32 -0700
> URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/914c33c7de3e
>
> 6843578: Re-implement IBM doublebyte charsets
> 6639450: IBM949C encoder modifies state of IBM949 encoder
> 6569191: Cp943 io converter returns U+0000 and U+FFFD for unconvertable character
> 6577466: Character encoder IBM970 throws a BufferOverflowException
> 5065777: CharsetEncoder canEncode() methods often incorrectly return false
> Summary: Re-write 11 IBM doublebyte charsets. Thanks Ulf.Zibis for the codereview!
> Reviewed-by: martin
>
>   



From aph at redhat.com  Fri May 22 10:37:31 2009
From: aph at redhat.com (Andrew Haley)
Date: Fri, 22 May 2009 11:37:31 +0100
Subject: Request for approval: fix 4428022, System.out.println(0.001) outputs
	0.0010
Message-ID: <4A16806B.9060001@redhat.com>

This bug has been in Java for a long time, and the fix has been in IcedTea
for a year and a half.

The bug is a trivial off-by-one error.

OK for OpenJDK7 and OpenJDK6?

Andrew.


--- oipenjdk/jdk/src/share/classes/sun/misc/FloatingDecimal.java        Thu Sep 27 12:56:46 2007 -0700
+++ openjdk/jdk/src/share/classes/sun/misc/FloatingDecimal.java 2007-11-13 13:39:18.000000000 -0500
@@ -730,7 +730,7 @@
                  * Thus we will need more than one digit if we're using
                  * E-form
                  */
-                if ( decExp <= -3 || decExp >= 8 ){
+                if ( decExp < -3 || decExp >= 8 ){
                     high = low = false;
                 }
                 while( ! low && ! high ){
@@ -783,7 +783,7 @@
                  * Thus we will need more than one digit if we're using
                  * E-form
                  */
-                if ( decExp <= -3 || decExp >= 8 ){
+                if ( decExp < -3 || decExp >= 8 ){
                     high = low = false;
                 }
                 while( ! low && ! high ){
@@ -847,7 +847,7 @@
              * Thus we will need more than one digit if we're using
              * E-form
              */
-            if ( decExp <= -3 || decExp >= 8 ){
+            if ( decExp < -3 || decExp >= 8 ){
                 high = low = false;
             }
             while( ! low && ! high ){


From David.Holmes at Sun.COM  Fri May 22 10:51:18 2009
From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems)
Date: Fri, 22 May 2009 20:51:18 +1000
Subject: Review request for 5049299
In-Reply-To: <4A1678DB.9010209@sun.com>
References: <4A1678DB.9010209@sun.com>
Message-ID: <4A1683A6.7070502@sun.com>

Hi Michael,

I can't say that I grok all the detail in this but I get the gist and 
overall I don't see anything obviously problematic. I have a couple of 
small comments:

In the Makefile:

+ HELPER_EXE = $(BINDIR)/processhelper$(EXE_SUFFIX)

Isn't EXE_SUFFIX superfluous here? It has to be an empty string 
otherwise the Java code won't know the name of the helper.

In UnixProcess_md.c:

116 jlup_xmalloc(void *env, int size)

Why did you have to lose the type of env ?
Why is this function defined differnetly in two files?

Cheers,
David


Michael McMahon said the following on 05/22/09 20:05:
> Hi,
> 
> I have just posted a webrev for 5049299: (process) Use posix_spawn, not 
> fork, on S10 to avoid swap exhaustion.
> 
> webrev location: http://cr.openjdk.java.net/~michaelm/5049299/webrev.00/
> 
> **I'd like to give an outline of the change here, to make reviewing the 
> webrev a bit easier.
> Basically, while posix_spawn() is a fairly elaborate and complicated 
> system call, it can't quite do
> everything that the old fork()/exec() combination can do, so the only 
> feasible way to do this, is to
> use posix_spawn to launch a new helper executable "processhelper", which 
> in turn execs the
> target (after cleaning up file-descriptors etc.) The end result is the 
> same as before, a child process
> linked to the parent in the same way, but it avoids the problem of 
> duplicating the parent (VM) process
> address space temporarily, before launching the target command.
> 
> In the original implementation, the native code for 
> UNIXProcess.forkAndExec() was the same
> for both Linux and Solaris.  Now, we have split it, so that Linux 
> retains the original implementation
> but for Solaris, the native method is renamed spawn() where the 
> implementation is partly in this function,
> but also partly in the new processhelper binary, which is spawned by the 
> spawn() method.
> 
> A number of utility functions, which were originally in 
> UNIXProcess_md.c, are also needed by the
> processhelper binary, have been moved into new source files 
> (processutil_md.[ch]).
> Because the functions were originally static in UNIXProcess_md.c, a 
> prefix is added to their names (jlup_)
> (from initials of java.lang.UNIXProcess), to avoid any conflict in 
> global scope. This applies to the Linux
> version as well as the Solaris version. So, this looks like new code, 
> but the body of these functions
> are not changed from before.
> 
> I'm proposing not to add any unit/regression tests for this change, 
> since the point of it
> is kind of self-evident from the source code (ie. stop using fork() and 
> use posix_spawn() instead),
> and there shouldn't be any behaviour change other than memory usage.
> This area of the platform seems to be well covered by existing 
> regression/unit tests.
> 
> Hope this helps,
> Thanks,
> Michael.
> 


From Michael.McMahon at Sun.COM  Fri May 22 11:05:09 2009
From: Michael.McMahon at Sun.COM (Michael McMahon)
Date: Fri, 22 May 2009 12:05:09 +0100
Subject: Review request for 5049299
In-Reply-To: <4A1683A6.7070502@sun.com>
References: <4A1678DB.9010209@sun.com> <4A1683A6.7070502@sun.com>
Message-ID: <4A1686E5.3040802@sun.com>

Hi David,

>
> In the Makefile:
>
> + HELPER_EXE = $(BINDIR)/processhelper$(EXE_SUFFIX)
>
> Isn't EXE_SUFFIX superfluous here? It has to be an empty string 
> otherwise the Java code won't know the name of the helper.
>
Yes, it is superfluous. I took the pattern from another makefile,
but it is probably better to remove it for maximum clarity.
> In UnixProcess_md.c:
>
> 116 jlup_xmalloc(void *env, int size)
>
> Why did you have to lose the type of env ?
> Why is this function defined differnetly in two files?
>
This malloc function is invoked in code that is common to the 
UNIXProcess native code,
and processhelper. The native code knows about JNI and it needs the JNI 
env in order to
be able to call  JNU_ThrowOutOfMemoryError((JNIEnv *)env, NULL);

But the implementation in processhelper, does not know about JNI, so it 
ignores the env
parameter, and in order to avoid including JNI header files in 
processhelper I made
it a void *, which is casted to a JNIEnv * in the other version.

Thanks,
Michael



From dl at cs.oswego.edu  Fri May 22 11:08:47 2009
From: dl at cs.oswego.edu (Doug Lea)
Date: Fri, 22 May 2009 07:08:47 -0400
Subject: c.toArray might (incorrectly) not return Object[] (see 6260652)
In-Reply-To: <4A163072.5040309@sun.com>
References: <87pre2nzls.fsf@mid.deneb.enyo.de>
	<4A16087D.60205@sun.com>	<87skix3fu8.fsf@mid.deneb.enyo.de>
	<4A163072.5040309@sun.com>
Message-ID: <4A1687BF.3080008@cs.oswego.edu>

David Holmes - Sun Microsystems wrote:
> Florian Weimer said the following on 05/22/09 14:46:
>> It's there, but not in the documentation for toArray():
>>
>> | Note that toArray(new Object[0]) is identical in function to toArray().
>>
>> <http://java.sun.com/j2se/1.4.2/docs/api/java/util/Collection.html#toArray(java.lang.Object[])> 
>>
>> <http://java.sun.com/j2se/1.5.0/docs/api/java/util/Collection.html#toArray(T[])> 
>>
> 
> Ah I see - thanks.
> 
> Okay well the bug is still open. I think the original intent was to 
> change toArray() to match this, but I think it's far too late to change 
> that behaviour now. So the only "fix" is to delete that sentence from 
> the javadoc.
> 

This bug is and its history are well-known to a few of us.
A fix once got vetoed in the approval process out of concern
that existing applications might rely on this incorrect behavior.
However, the bug causes all sorts of collateral damage. For
example, the ArrayList(Collection) constructor includes
     public ArrayList(Collection<? extends E> c) {
         elementData = c.toArray();
         size = elementData.length;
         // c.toArray might (incorrectly) not return Object[] (see 6260652)
         if (elementData.getClass() != Object[].class)
             elementData = Arrays.copyOf(elementData, size, Object[].class);
     }

It would be nice to know whether the number of collateral damage
bugs in existing applications is greater than the number of breakages
that would occur if this were fixed. This is not easy to estimate
though because only a few usages of "Object[] a = x.toArray()"
when toArray doesn't return Object[] are actually wrong.

-Doug



> Were you looking for an actual change in the implementation?
> 
> Note this is just my opinion on this, I'm not a decision maker here :)
> 
> Cheers,
> David
> 



From aph at redhat.com  Fri May 22 11:10:00 2009
From: aph at redhat.com (Andrew Haley)
Date: Fri, 22 May 2009 12:10:00 +0100
Subject: Request for approval: Bug 100057 -  Potential stack corruption in
	GetJavaProperties
Message-ID: <4A168808.5050805@redhat.com>

https://bugs.openjdk.java.net/show_bug.cgi?id=100057

GetJavaProperties has a stack-allocated fixed size buffer for holding a copy of
a string returned by setlocale(3).  However, there is no guarantee that the
string will fit into this buffer.

This one is probably due to Solaris code being reused for Linux.  The
patch has been in IcedTea for a long while.

OK to push, OpenJDK 7 and 6?

Andrew.


--- oldopenjdk6/jdk/src/solaris/native/java/lang/java_props_md.c        2008-08-28 04:15:51.000000000 -0400
+++ openjdk/jdk/src/solaris/native/java/lang/java_props_md.c    2008-09-15 10:37:26.000000000 -0400
@@ -211,7 +211,9 @@
              * <language name>_<country name>.<encoding name>@<variant name>
              * <country name>, <encoding name>, and <variant name> are optional.
              */
-            char temp[64];
+           char * temp;
+           temp = (char*) malloc(strlen(lc)+1);
+
             char *language = NULL, *country = NULL, *variant = NULL,
                  *encoding = NULL;
             char *std_language = NULL, *std_country = NULL, *std_variant = NULL,
@@ -323,6 +325,9 @@
             /* return same result nl_langinfo would return for en_UK,
              * in order to use optimizations. */
             std_encoding = (*p != '\0') ? p : "ISO8859-1";
+
+           /* Free temp */
+           free(temp);


 #ifdef __linux__


From David.Holmes at Sun.COM  Fri May 22 11:18:16 2009
From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems)
Date: Fri, 22 May 2009 21:18:16 +1000
Subject: Review request for 5049299
In-Reply-To: <4A1686E5.3040802@sun.com>
References: <4A1678DB.9010209@sun.com> <4A1683A6.7070502@sun.com>
	<4A1686E5.3040802@sun.com>
Message-ID: <4A1689F8.1020805@sun.com>

Hi Michael,

 > But the implementation in processhelper, does not know about JNI, so
 > it ignores the env

and doesn't throw the exception, which then begs the question as to what 
happens if malloc returns NULL in that case? If I understand you right, 
the jlup_* functions called from processhelper will use its jlup_xmalloc 
function, which simply returns malloc - but those jlup_* functions don't 
check for a NULL return because they "know" that xmalloc throws on 
out-of-memory.

David


Michael McMahon said the following on 05/22/09 21:05:
> Hi David,
> 
>>
>> In the Makefile:
>>
>> + HELPER_EXE = $(BINDIR)/processhelper$(EXE_SUFFIX)
>>
>> Isn't EXE_SUFFIX superfluous here? It has to be an empty string 
>> otherwise the Java code won't know the name of the helper.
>>
> Yes, it is superfluous. I took the pattern from another makefile,
> but it is probably better to remove it for maximum clarity.
>> In UnixProcess_md.c:
>>
>> 116 jlup_xmalloc(void *env, int size)
>>
>> Why did you have to lose the type of env ?
>> Why is this function defined differnetly in two files?
>>
> This malloc function is invoked in code that is common to the 
> UNIXProcess native code,
> and processhelper. The native code knows about JNI and it needs the JNI 
> env in order to
> be able to call  JNU_ThrowOutOfMemoryError((JNIEnv *)env, NULL);
> 
> But the implementation in processhelper, does not know about JNI, so it 
> ignores the env
> parameter, and in order to avoid including JNI header files in 
> processhelper I made
> it a void *, which is casted to a JNIEnv * in the other version.
> 
> Thanks,
> Michael
> 


From David.Holmes at Sun.COM  Fri May 22 11:22:29 2009
From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems)
Date: Fri, 22 May 2009 21:22:29 +1000
Subject: c.toArray might (incorrectly) not return Object[] (see 6260652)
In-Reply-To: <4A1687BF.3080008@cs.oswego.edu>
References: <87pre2nzls.fsf@mid.deneb.enyo.de> <4A16087D.60205@sun.com>
	<87skix3fu8.fsf@mid.deneb.enyo.de> <4A163072.5040309@sun.com>
	<4A1687BF.3080008@cs.oswego.edu>
Message-ID: <4A168AF5.7080808@sun.com>

Hi Doug,

Thanks for the info, one query though ...

Doug Lea said the following on 05/22/09 21:08:
> David Holmes - Sun Microsystems wrote:
>> Okay well the bug is still open. I think the original intent was to 
>> change toArray() to match this, but I think it's far too late to 
>> change that behaviour now. So the only "fix" is to delete that 
>> sentence from the javadoc.
>>
> 
> This bug is and its history are well-known to a few of us.
> A fix once got vetoed in the approval process out of concern
> that existing applications might rely on this incorrect behavior.
> However, the bug causes all sorts of collateral damage. For
> example, the ArrayList(Collection) constructor includes
>     public ArrayList(Collection<? extends E> c) {
>         elementData = c.toArray();
>         size = elementData.length;
>         // c.toArray might (incorrectly) not return Object[] (see 6260652)
>         if (elementData.getClass() != Object[].class)
>             elementData = Arrays.copyOf(elementData, size, Object[].class);
>     }

Ummm why didn't it just use:

     elementData = c.toArray(new Object[c.size()]);

??

David

> It would be nice to know whether the number of collateral damage
> bugs in existing applications is greater than the number of breakages
> that would occur if this were fixed. This is not easy to estimate
> though because only a few usages of "Object[] a = x.toArray()"
> when toArray doesn't return Object[] are actually wrong.
> 
> -Doug
> 
> 
> 
>> Were you looking for an actual change in the implementation?
>>
>> Note this is just my opinion on this, I'm not a decision maker here :)
>>
>> Cheers,
>> David
>>
> 


From dl at cs.oswego.edu  Fri May 22 11:31:50 2009
From: dl at cs.oswego.edu (Doug Lea)
Date: Fri, 22 May 2009 07:31:50 -0400
Subject: c.toArray might (incorrectly) not return Object[] (see 6260652)
In-Reply-To: <4A168AF5.7080808@sun.com>
References: <87pre2nzls.fsf@mid.deneb.enyo.de> <4A16087D.60205@sun.com>
	<87skix3fu8.fsf@mid.deneb.enyo.de> <4A163072.5040309@sun.com>
	<4A1687BF.3080008@cs.oswego.edu> <4A168AF5.7080808@sun.com>
Message-ID: <4A168D26.4050303@cs.oswego.edu>

David Holmes - Sun Microsystems wrote:
> Thanks for the info, one query though ...
> 
> Ummm why didn't it just use:
> 
>     elementData = c.toArray(new Object[c.size()]);
> 

Because "c" might be a concurrent collection, so you
don't want to independently call c.size(). Notice
that AbstractCollection correctly implements
toArray() even for such collections but cannot do so
for toArray(T[] a) because it must interpret
a.length as the required size.

-Doug





From David.Holmes at Sun.COM  Fri May 22 11:34:20 2009
From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems)
Date: Fri, 22 May 2009 21:34:20 +1000
Subject: Request for approval: Bug 100057 - Potential stack corruption in
	GetJavaProperties
In-Reply-To: <4A168808.5050805@redhat.com>
References: <4A168808.5050805@redhat.com>
Message-ID: <4A168DBC.8060903@sun.com>

Hi Andrew,

If you use malloc then you have to check for a NULL return and deal with 
the error possibility.

Alternatively use strncpy to make sure it's safe and continue to assume 
that it will be big enough.

Cheers,
David Holmes

Andrew Haley said the following on 05/22/09 21:10:
> https://bugs.openjdk.java.net/show_bug.cgi?id=100057
> 
> GetJavaProperties has a stack-allocated fixed size buffer for holding a copy of
> a string returned by setlocale(3).  However, there is no guarantee that the
> string will fit into this buffer.
> 
> This one is probably due to Solaris code being reused for Linux.  The
> patch has been in IcedTea for a long while.
> 
> OK to push, OpenJDK 7 and 6?
> 
> Andrew.
> 
> 
> --- oldopenjdk6/jdk/src/solaris/native/java/lang/java_props_md.c        2008-08-28 04:15:51.000000000 -0400
> +++ openjdk/jdk/src/solaris/native/java/lang/java_props_md.c    2008-09-15 10:37:26.000000000 -0400
> @@ -211,7 +211,9 @@
>               * <language name>_<country name>.<encoding name>@<variant name>
>               * <country name>, <encoding name>, and <variant name> are optional.
>               */
> -            char temp[64];
> +           char * temp;
> +           temp = (char*) malloc(strlen(lc)+1);
> +
>              char *language = NULL, *country = NULL, *variant = NULL,
>                   *encoding = NULL;
>              char *std_language = NULL, *std_country = NULL, *std_variant = NULL,
> @@ -323,6 +325,9 @@
>              /* return same result nl_langinfo would return for en_UK,
>               * in order to use optimizations. */
>              std_encoding = (*p != '\0') ? p : "ISO8859-1";
> +
> +           /* Free temp */
> +           free(temp);
> 
> 
>  #ifdef __linux__


From Alan.Bateman at Sun.COM  Fri May 22 11:35:40 2009
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Fri, 22 May 2009 12:35:40 +0100
Subject: Request for approval: Bug 100057 - Potential stack corruption in
	GetJavaProperties
In-Reply-To: <4A168808.5050805@redhat.com>
References: <4A168808.5050805@redhat.com>
Message-ID: <4A168E0C.4040603@sun.com>

Andrew Haley wrote:
> https://bugs.openjdk.java.net/show_bug.cgi?id=100057
>
> GetJavaProperties has a stack-allocated fixed size buffer for holding a copy of
> a string returned by setlocale(3).  However, there is no guarantee that the
> string will fit into this buffer.
>
> This one is probably due to Solaris code being reused for Linux.  The
> patch has been in IcedTea for a long while.
>
> OK to push, OpenJDK 7 and 6?
>
> Andrew
>   
I can't say I know this code very well but I see that the full-locale 
name can also be copied into temp when the locale is an alias. This 
makes me wonder if temp might need to be realloc'ed there? Also, I 
wonder if the return from malloc should be checked.

I've created a corresponding sunbug for this:
  6844255: Potential stack corruption in GetJavaProperties

-Alan




From David.Holmes at Sun.COM  Fri May 22 11:45:23 2009
From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems)
Date: Fri, 22 May 2009 21:45:23 +1000
Subject: c.toArray might (incorrectly) not return Object[] (see 6260652)
In-Reply-To: <4A168D26.4050303@cs.oswego.edu>
References: <87pre2nzls.fsf@mid.deneb.enyo.de> <4A16087D.60205@sun.com>
	<87skix3fu8.fsf@mid.deneb.enyo.de> <4A163072.5040309@sun.com>
	<4A1687BF.3080008@cs.oswego.edu> <4A168AF5.7080808@sun.com>
	<4A168D26.4050303@cs.oswego.edu>
Message-ID: <4A169053.4050608@sun.com>

Doug Lea said the following on 05/22/09 21:31:
> David Holmes - Sun Microsystems wrote:
>> Thanks for the info, one query though ...
>>
>> Ummm why didn't it just use:
>>
>>     elementData = c.toArray(new Object[c.size()]);
>>
> 
> Because "c" might be a concurrent collection, so you
> don't want to independently call c.size(). Notice
> that AbstractCollection correctly implements
> toArray() even for such collections but cannot do so
> for toArray(T[] a) because it must interpret
> a.length as the required size.

Has that code been updated recently because it sure looks like it tries 
to acommodate this and always return an array of exactly size() length 
(at the time toArray is called). ??

David


From aph at redhat.com  Fri May 22 11:45:36 2009
From: aph at redhat.com (Andrew Haley)
Date: Fri, 22 May 2009 12:45:36 +0100
Subject: Request for approval: Bug 100057 -  Potential stack corruption
	in	GetJavaProperties
In-Reply-To: <4A168DBC.8060903@sun.com>
References: <4A168808.5050805@redhat.com> <4A168DBC.8060903@sun.com>
Message-ID: <4A169060.7000909@redhat.com>

David Holmes - Sun Microsystems wrote:

> If you use malloc then you have to check for a NULL return and deal with
> the error possibility.
> 
> Alternatively use strncpy to make sure it's safe and continue to assume
> that it will be big enough.

It's just following the style used throughout that file, which is to
allocate memory (usually via strdup) but not check the retval.

OK.  I'll check for the NULL, then.  If I have to change the patch that's
been in IcedTea for ages then I'll use strdup instead of malloc.  But what
is one supposed to do if the allocation fails?  Simply emit an error
message to stderr and call abort() ?

Andrew.


> Andrew Haley said the following on 05/22/09 21:10:
>> https://bugs.openjdk.java.net/show_bug.cgi?id=100057
>>
>> GetJavaProperties has a stack-allocated fixed size buffer for holding
>> a copy of
>> a string returned by setlocale(3).  However, there is no guarantee
>> that the
>> string will fit into this buffer.
>>
>> This one is probably due to Solaris code being reused for Linux.  The
>> patch has been in IcedTea for a long while.
>>
>> OK to push, OpenJDK 7 and 6?
>>
>> Andrew.
>>
>>
>> ---
>> oldopenjdk6/jdk/src/solaris/native/java/lang/java_props_md.c       
>> 2008-08-28 04:15:51.000000000 -0400
>> +++ openjdk/jdk/src/solaris/native/java/lang/java_props_md.c   
>> 2008-09-15 10:37:26.000000000 -0400
>> @@ -211,7 +211,9 @@
>>               * <language name>_<country name>.<encoding
>> name>@<variant name>
>>               * <country name>, <encoding name>, and <variant name>
>> are optional.
>>               */
>> -            char temp[64];
>> +           char * temp;
>> +           temp = (char*) malloc(strlen(lc)+1);
>> +
>>              char *language = NULL, *country = NULL, *variant = NULL,
>>                   *encoding = NULL;
>>              char *std_language = NULL, *std_country = NULL,
>> *std_variant = NULL,
>> @@ -323,6 +325,9 @@
>>              /* return same result nl_langinfo would return for en_UK,
>>               * in order to use optimizations. */
>>              std_encoding = (*p != '\0') ? p : "ISO8859-1";
>> +
>> +           /* Free temp */
>> +           free(temp);
>>
>>
>>  #ifdef __linux__



From Alan.Bateman at Sun.COM  Fri May 22 11:48:32 2009
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Fri, 22 May 2009 12:48:32 +0100
Subject: Request for approval: fix 4428022,
	System.out.println(0.001) outputs	0.0010
In-Reply-To: <4A16806B.9060001@redhat.com>
References: <4A16806B.9060001@redhat.com>
Message-ID: <4A169110.1030003@sun.com>

Andrew Haley wrote:
> This bug has been in Java for a long time, and the fix has been in IcedTea
> for a year and a half.
>
> The bug is a trivial off-by-one error.
>
> OK for OpenJDK7 and OpenJDK6?
>
> Andrew.
>   
It looks reasonable to me although Joe would be the best person to 
review this. It would be good to create a regression test to include 
with the change-set.

-Alan.


From dl at cs.oswego.edu  Fri May 22 11:56:08 2009
From: dl at cs.oswego.edu (Doug Lea)
Date: Fri, 22 May 2009 07:56:08 -0400
Subject: c.toArray might (incorrectly) not return Object[] (see 6260652)
In-Reply-To: <4A169053.4050608@sun.com>
References: <87pre2nzls.fsf@mid.deneb.enyo.de> <4A16087D.60205@sun.com>
	<87skix3fu8.fsf@mid.deneb.enyo.de> <4A163072.5040309@sun.com>
	<4A1687BF.3080008@cs.oswego.edu> <4A168AF5.7080808@sun.com>
	<4A168D26.4050303@cs.oswego.edu> <4A169053.4050608@sun.com>
Message-ID: <4A1692D8.1030909@cs.oswego.edu>

David Holmes - Sun Microsystems wrote:
> Doug Lea said the following on 05/22/09 21:31:
>> David Holmes - Sun Microsystems wrote:
>>> Thanks for the info, one query though ...
>>>
>>> Ummm why didn't it just use:
>>>
>>>     elementData = c.toArray(new Object[c.size()]);
>>>
>>
>> Because "c" might be a concurrent collection, so you
>> don't want to independently call c.size(). Notice
>> that AbstractCollection correctly implements
>> toArray() even for such collections but cannot do so
>> for toArray(T[] a) because it must interpret
>> a.length as the required size.
> 
> Has that code been updated recently because it sure looks like it tries 
> to acommodate this and always return an array of exactly size() length 
> (at the time toArray is called). ??
> 

Sorry; I should have been clearer about why
   c.toArray(new Object[c.size()])
is subtly wrong here. ArrayList.size must equal
the number of elements, which might be different
than the array size. If c's size shrinks at an
inconvenient moment during the call, then we might
think that the trailing null, that toArray(T[] a)
is required to append if a is too big, is actually a
(null) element of the collection.

-Doug





From David.Holmes at Sun.COM  Fri May 22 11:58:35 2009
From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems)
Date: Fri, 22 May 2009 21:58:35 +1000
Subject: Request for approval: Bug 100057 - Potential stack corruption in
	GetJavaProperties
In-Reply-To: <4A169060.7000909@redhat.com>
References: <4A168808.5050805@redhat.com> <4A168DBC.8060903@sun.com>
	<4A169060.7000909@redhat.com>
Message-ID: <4A16936B.1020807@sun.com>

Andrew Haley said the following on 05/22/09 21:45:
> David Holmes - Sun Microsystems wrote:
> 
>> If you use malloc then you have to check for a NULL return and deal with
>> the error possibility.
>>
>> Alternatively use strncpy to make sure it's safe and continue to assume
>> that it will be big enough.
> 
> It's just following the style used throughout that file, which is to
> allocate memory (usually via strdup) but not check the retval.

Hmmm. In most (all?) cases though that just results in a NULL being 
stored in a property. Here if we get NULL we try to write into that 
space - and that's not good. Can't say for sure all the strdup uses are 
safe though.

The risk of fixing old code is that suddenly people notice everything 
else that's wrong with it.

> OK.  I'll check for the NULL, then.  If I have to change the patch that's
> been in IcedTea for ages then I'll use strdup instead of malloc.  

I do wonder why strdup wasn't used in the first place.

It also appears that the strdup of lc is never freed.

> But what
> is one supposed to do if the allocation fails?  Simply emit an error
> message to stderr and call abort() ?

Throw an OutOfMemory exception - see the use of JNU_ThrowByName later in 
the function.

Cheers,
David

> Andrew.
> 
> 
>> Andrew Haley said the following on 05/22/09 21:10:
>>> https://bugs.openjdk.java.net/show_bug.cgi?id=100057
>>>
>>> GetJavaProperties has a stack-allocated fixed size buffer for holding
>>> a copy of
>>> a string returned by setlocale(3).  However, there is no guarantee
>>> that the
>>> string will fit into this buffer.
>>>
>>> This one is probably due to Solaris code being reused for Linux.  The
>>> patch has been in IcedTea for a long while.
>>>
>>> OK to push, OpenJDK 7 and 6?
>>>
>>> Andrew.
>>>
>>>
>>> ---
>>> oldopenjdk6/jdk/src/solaris/native/java/lang/java_props_md.c       
>>> 2008-08-28 04:15:51.000000000 -0400
>>> +++ openjdk/jdk/src/solaris/native/java/lang/java_props_md.c   
>>> 2008-09-15 10:37:26.000000000 -0400
>>> @@ -211,7 +211,9 @@
>>>               * <language name>_<country name>.<encoding
>>> name>@<variant name>
>>>               * <country name>, <encoding name>, and <variant name>
>>> are optional.
>>>               */
>>> -            char temp[64];
>>> +           char * temp;
>>> +           temp = (char*) malloc(strlen(lc)+1);
>>> +
>>>              char *language = NULL, *country = NULL, *variant = NULL,
>>>                   *encoding = NULL;
>>>              char *std_language = NULL, *std_country = NULL,
>>> *std_variant = NULL,
>>> @@ -323,6 +325,9 @@
>>>              /* return same result nl_langinfo would return for en_UK,
>>>               * in order to use optimizations. */
>>>              std_encoding = (*p != '\0') ? p : "ISO8859-1";
>>> +
>>> +           /* Free temp */
>>> +           free(temp);
>>>
>>>
>>>  #ifdef __linux__
> 


From Alan.Bateman at Sun.COM  Fri May 22 12:04:59 2009
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Fri, 22 May 2009 13:04:59 +0100
Subject: Request for approval: Bug 100057 - Potential stack corruption in
	GetJavaProperties
In-Reply-To: <4A169060.7000909@redhat.com>
References: <4A168808.5050805@redhat.com> <4A168DBC.8060903@sun.com>
	<4A169060.7000909@redhat.com>
Message-ID: <4A1694EB.7020901@sun.com>

Andrew Haley wrote:
> :
> OK.  I'll check for the NULL, then.  If I have to change the patch that's
> been in IcedTea for ages then I'll use strdup instead of malloc.  But what
> is one supposed to do if the allocation fails?  Simply emit an error
> message to stderr and call abort() ?
>   
JNU_ThrowOutOfMemoryError(env, NULL) and return NULL should do it and 
will be treated as a fatal error by HotSpot.

-Alan.




From David.Holmes at Sun.COM  Fri May 22 12:05:30 2009
From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems)
Date: Fri, 22 May 2009 22:05:30 +1000
Subject: c.toArray might (incorrectly) not return Object[] (see 6260652)
In-Reply-To: <4A1692D8.1030909@cs.oswego.edu>
References: <87pre2nzls.fsf@mid.deneb.enyo.de> <4A16087D.60205@sun.com>
	<87skix3fu8.fsf@mid.deneb.enyo.de> <4A163072.5040309@sun.com>
	<4A1687BF.3080008@cs.oswego.edu> <4A168AF5.7080808@sun.com>
	<4A168D26.4050303@cs.oswego.edu> <4A169053.4050608@sun.com>
	<4A1692D8.1030909@cs.oswego.edu>
Message-ID: <4A16950A.5020108@sun.com>

Doug Lea said the following on 05/22/09 21:56:
> Sorry; I should have been clearer about why
>   c.toArray(new Object[c.size()])
> is subtly wrong here. ArrayList.size must equal
> the number of elements, which might be different
> than the array size. If c's size shrinks at an
> inconvenient moment during the call, then we might
> think that the trailing null, that toArray(T[] a)
> is required to append if a is too big, is actually a
> (null) element of the collection.

Ah I see.

I'm thinking though that I'd find this hack more aesthetically pleasing:

   static final Object[] ZERO_ARRAY = new Object[0];
   ...
   elementData = c.toArray(ZERO_ARRAY);

this deals with the size issue, gets the right type and only creates one 
array (asuming the collection doesn't concurrently grow).

Cheers,
David




From Alan.Bateman at Sun.COM  Fri May 22 12:15:15 2009
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Fri, 22 May 2009 13:15:15 +0100
Subject: Review request for 5049299
In-Reply-To: <4A1678DB.9010209@sun.com>
References: <4A1678DB.9010209@sun.com>
Message-ID: <4A169753.9080300@sun.com>

Michael McMahon wrote:
> Hi,
>
> I have just posted a webrev for 5049299: (process) Use posix_spawn, 
> not fork, on S10 to avoid swap exhaustion.
I'm very happy to see this one and I will review it in detail over the 
next few days. I'm sure Martin will want to review it too as he nurtured 
that code for a long time. It would also be interesting to see if 
HotSpot's OnError option could be updated to use posix_spawn.

-Alan.


From aph at redhat.com  Fri May 22 15:44:45 2009
From: aph at redhat.com (Andrew Haley)
Date: Fri, 22 May 2009 16:44:45 +0100
Subject: Request for approval: Bug 100057 -  Potential stack corruption
	in	GetJavaProperties
In-Reply-To: <4A168DBC.8060903@sun.com>
References: <4A168808.5050805@redhat.com> <4A168DBC.8060903@sun.com>
Message-ID: <4A16C86D.6040203@redhat.com>

David Holmes - Sun Microsystems wrote:

> If you use malloc then you have to check for a NULL return and deal with
> the error possibility.
> 
> Alternatively use strncpy to make sure it's safe and continue to assume
> that it will be big enough.

I'm working on fixing this properly, but I just came across a gem of
very confusing code:

            if ((encoding = strchr(p, '.')) != NULL) {
                p[encoding++ - p] = '\0';
                p = encoding;
            }

The middle line

                p[encoding++ - p] = '\0';

is unlike anything I have ever seen before.  As far as I can tell it
is equivalent to

                *encoding++ = '\0';

but expressed in a, er, unique way.  I suppose the idea is that it shows
that the store is within p.

I just had to share this...

Andrew.


From Michael.McMahon at Sun.COM  Fri May 22 16:29:38 2009
From: Michael.McMahon at Sun.COM (Michael McMahon)
Date: Fri, 22 May 2009 17:29:38 +0100
Subject: Review request for 5049299
In-Reply-To: <4A1689F8.1020805@sun.com>
References: <4A1678DB.9010209@sun.com> <4A1683A6.7070502@sun.com>
	<4A1686E5.3040802@sun.com> <4A1689F8.1020805@sun.com>
Message-ID: <4A16D2F2.7000909@sun.com>

David Holmes - Sun Microsystems wrote:
> Hi Michael,
>
> > But the implementation in processhelper, does not know about JNI, so
> > it ignores the env
>
> and doesn't throw the exception, which then begs the question as to 
> what happens if malloc returns NULL in that case? If I understand you 
> right, the jlup_* functions called from processhelper will use its 
> jlup_xmalloc function, which simply returns malloc - but those jlup_* 
> functions don't check for a NULL return because they "know" that 
> xmalloc throws on out-of-memory.
Right. It's only called in a couple of places, so that should be easy 
enough to fix
(check for null return)

Thanks,
Michael.


From aph at redhat.com  Fri May 22 16:44:20 2009
From: aph at redhat.com (Andrew Haley)
Date: Fri, 22 May 2009 17:44:20 +0100
Subject: Request for approval: Bug 100057 -  Potential stack corruption
	in	GetJavaProperties
In-Reply-To: <4A168E0C.4040603@sun.com>
References: <4A168808.5050805@redhat.com> <4A168E0C.4040603@sun.com>
Message-ID: <4A16D664.1050703@redhat.com>

Alan Bateman wrote:
> Andrew Haley wrote:
>> https://bugs.openjdk.java.net/show_bug.cgi?id=100057
>>
>> GetJavaProperties has a stack-allocated fixed size buffer for holding
>> a copy of
>> a string returned by setlocale(3).  However, there is no guarantee
>> that the
>> string will fit into this buffer.
>>
>> This one is probably due to Solaris code being reused for Linux.  The
>> patch has been in IcedTea for a long while.
>>
>> OK to push, OpenJDK 7 and 6?

> I can't say I know this code very well but I see that the full-locale
> name can also be copied into temp when the locale is an alias. This
> makes me wonder if temp might need to be realloc'ed there? Also, I
> wonder if the return from malloc should be checked.
> 
> I've created a corresponding sunbug for this:
>  6844255: Potential stack corruption in GetJavaProperties

I've reworked the patch.

I tried to refactor the code to make it cleaner and easier to follow,
but I ended up touching so many places that it bacame a major change,
and there's no way I could possibly test it all, especially the special
cases for Solaris.

So, I backed off and produced this, the minimum patch.  encoding_variant
and temp are malloc()d to the size that they need, and temp is realloc()d,
as you suggest.

Andrew.


diff -r 238591c80bc5 src/solaris/native/java/lang/java_props_md.c
--- a/src/solaris/native/java/lang/java_props_md.c	Thu May 21 18:41:50 2009 +0100
+++ b/src/solaris/native/java/lang/java_props_md.c	Fri May 22 17:37:20 2009 +0100
@@ -211,14 +211,19 @@
              * <language name>_<country name>.<encoding name>@<variant name>
              * <country name>, <encoding name>, and <variant name> are optional.
              */
-            char temp[64];
             char *language = NULL, *country = NULL, *variant = NULL,
                  *encoding = NULL;
             char *std_language = NULL, *std_country = NULL, *std_variant = NULL,
                  *std_encoding = NULL;
-            char *p, encoding_variant[64];
+            char *p, *encoding_variant;
             int i, found;

+            char *temp = malloc(strlen(lc)+1);
+            if (temp == NULL) {
+                JNU_ThrowOutOfMemoryError(env, NULL);
+                return NULL;
+            }
+
 #ifndef __linux__
             /*
              * Workaround for Solaris bug 4201684: Xlib doesn't like @euro
@@ -252,6 +257,13 @@
              * to a default country if that's possible.  It's also used to map
              * the Solaris locale aliases to their proper Java locale IDs.
              */
+
+            encoding_variant = malloc(strlen(p)+1);
+            if (encoding_variant == NULL) {
+                JNU_ThrowOutOfMemoryError(env, NULL);
+                return NULL;
+            }
+
             if ((p = strchr(temp, '.')) != NULL) {
                 strcpy(encoding_variant, p); /* Copy the leading '.' */
                 *p = '\0';
@@ -263,7 +275,12 @@
             }

             if (mapLookup(locale_aliases, temp, &p)) {
-                strcpy(temp, p);
+                temp = realloc(temp, strlen(p)+1);
+                if (temp == NULL) {
+                    JNU_ThrowOutOfMemoryError(env, NULL);
+                    return NULL;
+                }
+		strcpy(temp, p);
             }

             language = temp;
@@ -357,6 +374,9 @@
 #endif
             sprops.encoding = std_encoding;
             sprops.sun_jnu_encoding = sprops.encoding;
+
+            free(temp);
+            free(encoding_variant);
         }
     }



From aph at redhat.com  Fri May 22 17:21:52 2009
From: aph at redhat.com (Andrew Haley)
Date: Fri, 22 May 2009 18:21:52 +0100
Subject: Request for approval: fix 4428022, System.out.println(0.001)
	outputs	0.0010
In-Reply-To: <4A169110.1030003@sun.com>
References: <4A16806B.9060001@redhat.com> <4A169110.1030003@sun.com>
Message-ID: <4A16DF30.6080509@redhat.com>

Alan Bateman wrote:
> Andrew Haley wrote:
>> This bug has been in Java for a long time, and the fix has been in
>> IcedTea
>> for a year and a half.
>>
>> The bug is a trivial off-by-one error.
>>
>> OK for OpenJDK7 and OpenJDK6?
>>
>> Andrew.
>>   
> It looks reasonable to me although Joe would be the best person to
> review this. It would be good to create a regression test to include
> with the change-set.

OK, here it is.  I put the test in java/lang/Double/ToString.java
rather than sun/misc/FloatingDecimal because the bug manifested
itself in Double.toString although the fix was in
FloatingDecimal.dtoa.

Andrew.



diff -r 9b0f73e7a137 src/share/classes/sun/misc/FloatingDecimal.java
--- a/src/share/classes/sun/misc/FloatingDecimal.java	Thu May 21 14:48:03 2009 +0100
+++ b/src/share/classes/sun/misc/FloatingDecimal.java	Fri May 22 18:17:52 2009 +0100
@@ -730,7 +730,7 @@
                  * Thus we will need more than one digit if we're using
                  * E-form
                  */
-                if ( decExp <= -3 || decExp >= 8 ){
+                if ( decExp < -3 || decExp >= 8 ){
                     high = low = false;
                 }
                 while( ! low && ! high ){
@@ -783,7 +783,7 @@
                  * Thus we will need more than one digit if we're using
                  * E-form
                  */
-                if ( decExp <= -3 || decExp >= 8 ){
+                if ( decExp < -3 || decExp >= 8 ){
                     high = low = false;
                 }
                 while( ! low && ! high ){
@@ -847,7 +847,7 @@
              * Thus we will need more than one digit if we're using
              * E-form
              */
-            if ( decExp <= -3 || decExp >= 8 ){
+            if ( decExp < -3 || decExp >= 8 ){
                 high = low = false;
             }
             while( ! low && ! high ){
diff -r 9b0f73e7a137 test/java/lang/Double/ToString.java
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/test/java/lang/Double/ToString.java	Fri May 22 18:17:52 2009 +0100
@@ -0,0 +1,39 @@
+/*
+ * Copyright 2009 Sun Microsystems, Inc.  All Rights Reserved.
+ * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+ *
+ * This code is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.
+ *
+ * This code is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License version
+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa Clara,
+ * CA 95054 USA or visit www.sun.com if you need additional information or
+ * have any questions.
+ */
+
+/*
+ * @test
+ * @bug 4428022
+ * @summary Tests for Double.toString
+ * @author Andrew Haley <aph at redhat.com>
+ */
+
+public class ToString {
+
+    public static void main(String argv[]) {
+      if (!Double.toString(0.001).equals("0.001"))
+	  throw new RuntimeException("Double.toString(0.001) is not \"0.001\"");
+      if (!Double.toString(0.002).equals("0.002"))
+	  throw new RuntimeException("Double.toString(0.001) is not \"0.002\"");
+    }
+}


From Alan.Bateman at Sun.COM  Fri May 22 17:30:23 2009
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Fri, 22 May 2009 18:30:23 +0100
Subject: Request for approval: Bug 100057 - Potential stack corruption in
	GetJavaProperties
In-Reply-To: <4A16D664.1050703@redhat.com>
References: <4A168808.5050805@redhat.com> <4A168E0C.4040603@sun.com>
	<4A16D664.1050703@redhat.com>
Message-ID: <4A16E12F.3060006@sun.com>

Andrew Haley wrote:
> :
> I've reworked the patch.
>
> I tried to refactor the code to make it cleaner and easier to follow,
> but I ended up touching so many places that it bacame a major change,
> and there's no way I could possibly test it all, especially the special
> cases for Solaris.
>
> So, I backed off and produced this, the minimum patch.  encoding_variant
> and temp are malloc()d to the size that they need, and temp is realloc()d,
> as you suggest.
>   
This looks much better except the size when allocating encoding_variant. 
If I read the patch correctly then encoding_variant is malloc'ed before 
'p' is initialized (or 'p' might actually be null in the Solaris case 
when not a euro locale). Do I have this right? strlen(temp)+1 would work 
but would allocate a bit more than you need. A minor nit is that a 
malloc failure will return without freeing temp but I wouldn't worry 
about this because this is called once during startup and we won't get 
too far if heap is completely exhausted.

-Alan.


From aph at redhat.com  Fri May 22 17:40:03 2009
From: aph at redhat.com (Andrew Haley)
Date: Fri, 22 May 2009 18:40:03 +0100
Subject: Request for approval: Bug 100057 -  Potential stack corruption
	in	GetJavaProperties
In-Reply-To: <4A16E12F.3060006@sun.com>
References: <4A168808.5050805@redhat.com> <4A168E0C.4040603@sun.com>
	<4A16D664.1050703@redhat.com> <4A16E12F.3060006@sun.com>
Message-ID: <4A16E373.3030709@redhat.com>

Alan Bateman wrote:
> Andrew Haley wrote:
>> :
>> I've reworked the patch.
>>
>> I tried to refactor the code to make it cleaner and easier to follow,
>> but I ended up touching so many places that it bacame a major change,
>> and there's no way I could possibly test it all, especially the special
>> cases for Solaris.
>>
>> So, I backed off and produced this, the minimum patch.  encoding_variant
>> and temp are malloc()d to the size that they need, and temp is
>> realloc()d,
>> as you suggest.
>>   
> This looks much better except the size when allocating encoding_variant.
> If I read the patch correctly then encoding_variant is malloc'ed before
> 'p' is initialized (or 'p' might actually be null in the Solaris case
> when not a euro locale). Do I have this right?

Yes, you're right.  :-(

I reworked this silly patch so many times that I couldn't see it any
more.  As you say, encoding_variant needs to be at least the size of temp.

> strlen(temp)+1 would work  but would allocate a bit more than you need.
> A minor nit is that a malloc failure will return without freeing temp
> but I wouldn't worry about this because this is called once during>
> startup and we won't get too far if heap is completely exhausted.

Thanks for catching this.

Andrew.


diff -r 238591c80bc5 src/solaris/native/java/lang/java_props_md.c
--- a/src/solaris/native/java/lang/java_props_md.c	Thu May 21 18:41:50 2009 +0100
+++ b/src/solaris/native/java/lang/java_props_md.c	Fri May 22 18:38:21 2009 +0100
@@ -211,14 +211,19 @@
              * <language name>_<country name>.<encoding name>@<variant name>
              * <country name>, <encoding name>, and <variant name> are optional.
              */
-            char temp[64];
             char *language = NULL, *country = NULL, *variant = NULL,
                  *encoding = NULL;
             char *std_language = NULL, *std_country = NULL, *std_variant = NULL,
                  *std_encoding = NULL;
-            char *p, encoding_variant[64];
+            char *p, *encoding_variant;
             int i, found;

+            char *temp = malloc(strlen(lc)+1);
+            if (temp == NULL) {
+                JNU_ThrowOutOfMemoryError(env, NULL);
+                return NULL;
+            }
+
 #ifndef __linux__
             /*
              * Workaround for Solaris bug 4201684: Xlib doesn't like @euro
@@ -252,6 +257,13 @@
              * to a default country if that's possible.  It's also used to map
              * the Solaris locale aliases to their proper Java locale IDs.
              */
+
+            encoding_variant = malloc(strlen(temp)+1);
+            if (encoding_variant == NULL) {
+                JNU_ThrowOutOfMemoryError(env, NULL);
+                return NULL;
+            }
+
             if ((p = strchr(temp, '.')) != NULL) {
                 strcpy(encoding_variant, p); /* Copy the leading '.' */
                 *p = '\0';
@@ -263,7 +275,12 @@
             }

             if (mapLookup(locale_aliases, temp, &p)) {
-                strcpy(temp, p);
+                temp = realloc(temp, strlen(p)+1);
+                if (temp == NULL) {
+                    JNU_ThrowOutOfMemoryError(env, NULL);
+                    return NULL;
+                }
+		strcpy(temp, p);
             }

             language = temp;
@@ -357,6 +374,9 @@
 #endif
             sprops.encoding = std_encoding;
             sprops.sun_jnu_encoding = sprops.encoding;
+
+            free(temp);
+            free(encoding_variant);
         }
     }



From Alan.Bateman at Sun.COM  Fri May 22 19:21:51 2009
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Fri, 22 May 2009 20:21:51 +0100
Subject: Request for approval: Bug 100057 - Potential stack corruption in
	GetJavaProperties
In-Reply-To: <4A16E373.3030709@redhat.com>
References: <4A168808.5050805@redhat.com> <4A168E0C.4040603@sun.com>
	<4A16D664.1050703@redhat.com> <4A16E12F.3060006@sun.com>
	<4A16E373.3030709@redhat.com>
Message-ID: <4A16FB4F.20106@sun.com>

Andrew Haley wrote:
> :
> Yes, you're right.  :-(
>
> I reworked this silly patch so many times that I couldn't see it any
> more.  As you say, encoding_variant needs to be at least the size of temp.
>   
Thanks for perseveringly with it. The latest patch looks good to me.

-Alan.


From martinrb at google.com  Fri May 22 19:30:01 2009
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 22 May 2009 12:30:01 -0700
Subject: Review request for 5049299
In-Reply-To: <4A1678DB.9010209@sun.com>
References: <4A1678DB.9010209@sun.com>
Message-ID: <1ccfd1c10905221230u6f085d6eu26e0c516784e81ee@mail.gmail.com>

Hi Michael,

I am very happy to see this being worked on;
I would have done something like this
already if I could fork() myself.

This code is very tricky and has had many subtle bugs over the years.

---

Any way we could add Linux support to this,
via some flavor of low-level clone+exec?
Let me restate that more strongly -
we would really really want to solve the
memory problem for Linux as well - but how?

---

Remove space before (

return System.getProperty ("java.home");

Our C coding style is idiosyncratic,
but there also remove spaces for
function calls.

---

Isn't spawn only supported as of Solaris 10?
I don't see anything in the change for
older versions of Solaris.

---

The standard way of detecting presence of a function
at runtime is
dlsym(RTLD_DEFAULT, "function_name") != NULL

Wait! libc also has posix_spawn and friends!
On many systems we should be able to find posix_spawn.
Perhaps in most common special cases we can dispense with processhelper
and spawn the target executable directly?

---

processhelper should probably be named something more obviously java-related
e.g. javaprocesshelper.
Can we try to not install it in BINDIR, since it is not intended to be run
by users,
but hide it in some private subdir?

---

Please add include guards to

processutil_md.h


even though you can get away with not having them.

---

 296  * Reads nbyte bytes from file descriptor fd into buf,

Change comma to period.

---

processutil_md.h

can be made smaller.
Utilities such as

isAsciiDigit

can be static functions called from processutil_md.c

---

  41  * Utility used by j.l.ProcessBuilder (via UNIXProcess) to launch

In source code, let's splurge and write out java.lang instead of j.l.

---
  47  * argv[1] working directory for command

Add "or the empty string if none provided"

---

You appear to be both reading and writing to single fd pipefd.
I don't think bidirectional pipes are standard Unix.
I'd prefer to see separate read and write pipes.

---

  65  * - Msg type (4 bytes)
  66  *      1 = chdir error (detail in Field 1)
  67  *      2 = exec error (detail in Field 1)
  68  *      3 = target terminated (exit code in Field 1)

Please use constants

#define CHDIR_ERROR 1
etc...


---

It appears that Msg type 3 is never used with reply.

---

 100     FILE *f;

Unused?

---
  92     int child;

Unused?

---

  97     char name [256];

Unused?

---

 164     } else {
 165         /* empty environment */
 166         env = &nullptr;
 167     }

It feels wrong to have to special-case the
empty environment.

---

  26 #undef  _LARGEFILE64_SOURCE
  27 #define _LARGEFILE64_SOURCE 1

There's probably a reason why we want
_LARGEFILE64_SOURCE
defined in the new source files.

---

Martin

---On Fri, May 22, 2009 at 03:05, Michael McMahon
<Michael.McMahon at sun.com>wrote:

> Hi,
>
> I have just posted a webrev for 5049299: (process) Use posix_spawn, not
> fork, on S10 to avoid swap exhaustion.
>
> webrev location: http://cr.openjdk.java.net/~michaelm/5049299/webrev.00/<http://cr.openjdk.java.net/%7Emichaelm/5049299/webrev.00/>
>
> **I'd like to give an outline of the change here, to make reviewing the
> webrev a bit easier.
> Basically, while posix_spawn() is a fairly elaborate and complicated system
> call, it can't quite do
> everything that the old fork()/exec() combination can do, so the only
> feasible way to do this, is to
> use posix_spawn to launch a new helper executable "processhelper", which in
> turn execs the
> target (after cleaning up file-descriptors etc.) The end result is the same
> as before, a child process
> linked to the parent in the same way, but it avoids the problem of
> duplicating the parent (VM) process
> address space temporarily, before launching the target command.
>
> In the original implementation, the native code for
> UNIXProcess.forkAndExec() was the same
> for both Linux and Solaris.  Now, we have split it, so that Linux retains
> the original implementation
> but for Solaris, the native method is renamed spawn() where the
> implementation is partly in this function,
> but also partly in the new processhelper binary, which is spawned by the
> spawn() method.
>
> A number of utility functions, which were originally in UNIXProcess_md.c,
> are also needed by the
> processhelper binary, have been moved into new source files
> (processutil_md.[ch]).
> Because the functions were originally static in UNIXProcess_md.c, a prefix
> is added to their names (jlup_)
> (from initials of java.lang.UNIXProcess), to avoid any conflict in global
> scope. This applies to the Linux
> version as well as the Solaris version. So, this looks like new code, but
> the body of these functions
> are not changed from before.
>
> I'm proposing not to add any unit/regression tests for this change, since
> the point of it
> is kind of self-evident from the source code (ie. stop using fork() and use
> posix_spawn() instead),
> and there shouldn't be any behaviour change other than memory usage.
> This area of the platform seems to be well covered by existing
> regression/unit tests.
>
> Hope this helps,
> Thanks,
> Michael.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090522/0d99bc21/attachment.html>

From Xueming.Shen at Sun.COM  Fri May 22 20:50:51 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Fri, 22 May 2009 13:50:51 -0700
Subject: hg: jdk7/tl/jdk: 6843578: Re-implement IBM doublebyte charsets;
	...
In-Reply-To: <4A167CCE.2070500@gmx.de>
References: <20090522065637.004DBE7AA@hg.openjdk.java.net>
	<4A167CCE.2070500@gmx.de>
Message-ID: <4A17102B.8000800@sun.com>

Ulf Zibis wrote:
>
> I think I have forgotten one thing:
>
> isisDoubleByte() in DoubleByte uses hard-wired values. Shouldn't they 
> be better b1Min etc. ?
>
These hardcoded values are explicitly specified by the "spec" of ebcdic 
doublebyte encoding. So I
think it's fine to leave them hard-wired.

Sherman


From Alan.Bateman at Sun.COM  Fri May 22 20:56:37 2009
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Fri, 22 May 2009 21:56:37 +0100
Subject: Request for approval: fix 4428022,
	System.out.println(0.001) outputs	0.0010
In-Reply-To: <4A16DF30.6080509@redhat.com>
References: <4A16806B.9060001@redhat.com> <4A169110.1030003@sun.com>
	<4A16DF30.6080509@redhat.com>
Message-ID: <4A171185.8030504@sun.com>

Andrew Haley wrote:
> :
> OK, here it is.  I put the test in java/lang/Double/ToString.java
> rather than sun/misc/FloatingDecimal because the bug manifested
> itself in Double.toString although the fix was in
> FloatingDecimal.dtoa.
>   
I agree that test/java/lang/Double is the best place for this. All looks 
good to me (except minor nit, "String argv[]" -> "String[] args").  Joe, 
are you okay with this?

-Alan.


From Xueming.Shen at Sun.COM  Fri May 22 21:08:50 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Fri, 22 May 2009 14:08:50 -0700
Subject: Request for approval: Bug 100057 - Potential stack corruption in
	GetJavaProperties
In-Reply-To: <4A16E373.3030709@redhat.com>
References: <4A168808.5050805@redhat.com> <4A168E0C.4040603@sun.com>
	<4A16D664.1050703@redhat.com> <4A16E12F.3060006@sun.com>
	<4A16E373.3030709@redhat.com>
Message-ID: <4A171462.7000303@sun.com>

Andrew Haley wrote:
>              }
>
>              if (mapLookup(locale_aliases, temp, &p)) {
> -                strcpy(temp, p);
> +                temp = realloc(temp, strlen(p)+1);
> +                if (temp == NULL) {
> +                    JNU_ThrowOutOfMemoryError(env, NULL);
> +                    return NULL;
> +                }
> +		strcpy(temp, p);
>   

The max length string comes back from mapLookup(locale_aliases...) is 
known (in locale_str.h) , so if we can
give temp a minimum size when malloc, for example 64:-) then we might 
not need to update the code above

Sherman



From martinrb at google.com  Fri May 22 22:04:37 2009
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 22 May 2009 15:04:37 -0700
Subject: Review request for 5049299
In-Reply-To: <4A1678DB.9010209@sun.com>
References: <4A1678DB.9010209@sun.com>
Message-ID: <1ccfd1c10905221504i7dc65d6dv7806da9ba191727d@mail.gmail.com>

Meta:

I have a special interest in this feature,
partly because my employer has a special interest
- but... only on Linux.

I think glibc/linux has enough functionality to support
cheap spawn as documented e.g. here:
http://www.linuxfoundation.org/en/NewGlibc

Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090522/4d9e55b2/attachment.html>

From Michael.McMahon at Sun.COM  Fri May 22 22:13:44 2009
From: Michael.McMahon at Sun.COM (Michael McMahon)
Date: Fri, 22 May 2009 23:13:44 +0100
Subject: Review request for 5049299
In-Reply-To: <1ccfd1c10905221230u6f085d6eu26e0c516784e81ee@mail.gmail.com>
References: <4A1678DB.9010209@sun.com>
	<1ccfd1c10905221230u6f085d6eu26e0c516784e81ee@mail.gmail.com>
Message-ID: <4A172398.9000100@sun.com>

Martin,

Thanks. Great comments. Just a few comments of my own
on a couple of points.

1. Linux won't benefit from this change as much as solaris, since due to its
    "memory overcommit" architecture, it doesn't suffer from the problem 
(so much)
     in the first place (though memory overcommit causes some problems 
of its own).
     Nevertheless, maybe it could simplify the code a bit if we use 
posix_spawn() on Linux
     as well. So, I will look into that.

2. Support for older Solaris releases. My understanding was that jdk7 
doesn't need to support
    older releases of Solaris (than S10). Can someone clarify that 
situation?

3. Avoiding invocation of processhelper sometimes. The biggest issue (I 
found) with posix_spawn()
    is that it doesn't work too well in multi-threaded environments like 
the JVM.  The specific problem
    is that you have to set up a set of file-descriptor actions, prior 
to calling the function, whose purpose
    is to close file descriptors from the parent process in the child. 
Because the two parts to this are not
    atomic, other file descriptors could be opened/closed in the 
intervening period, and you couldn't
    guarantee that they would be handled correctly. So, for that reason, 
I see no way to avoid the
    "processhelper" approach, where we take care of the child's file 
descriptors after the child is spawned.

Thanks,
Michael.

Martin Buchholz wrote:
> Hi Michael,
>
> I am very happy to see this being worked on;
> I would have done something like this
> already if I could fork() myself.
>
> This code is very tricky and has had many subtle bugs over the years.
>
> ---
>
> Any way we could add Linux support to this,
> via some flavor of low-level clone+exec?
> Let me restate that more strongly -
> we would really really want to solve the
> memory problem for Linux as well - but how?
>
> ---
>
> Remove space before (
> return System.getProperty ("java.home");
>
> Our C coding style is idiosyncratic,
> but there also remove spaces for
> function calls.
>   
> ---
>
> Isn't spawn only supported as of Solaris 10?
> I don't see anything in the change for
> older versions of Solaris.
>
> ---
>
> The standard way of detecting presence of a function
> at runtime is
> dlsym(RTLD_DEFAULT, "function_name") != NULL
>
> Wait! libc also has posix_spawn and friends!
> On many systems we should be able to find posix_spawn.
> Perhaps in most common special cases we can dispense with processhelper
> and spawn the target executable directly?
>
> ---
>
> processhelper should probably be named something more obviously 
> java-related
> e.g. javaprocesshelper.
> Can we try to not install it in BINDIR, since it is not intended to be 
> run by users,
> but hide it in some private subdir?
>
> ---
>
> Please add include guards to
> processutil_md.h
>
> even though you can get away with not having them.
>
> ---
>  296  * Reads nbyte bytes from file descriptor fd into buf,
> Change comma to period.
>
> ---
> processutil_md.h
> can be made smaller.
> Utilities such as
> isAsciiDigit
>
> can be static functions called from processutil_md.c
>   
> ---
>   41  * Utility used by j.l.ProcessBuilder (via UNIXProcess) to launch
>
> In source code, let's splurge and write out java.lang instead of j.l.
>
> ---
>   47  * argv[1] working directory for command
>
>
> Add "or the empty string if none provided"
>
> ---
>
> You appear to be both reading and writing to single fd pipefd.
> I don't think bidirectional pipes are standard Unix.
> I'd prefer to see separate read and write pipes.
>
>
> ---
>
>   65  * - Msg type (4 bytes)
>   66  *      1 = chdir error (detail in Field 1)
>   67  *      2 = exec error (detail in Field 1)
>   68  *      3 = target terminated (exit code in Field 1)
>
> Please use constants
>
>
> #define CHDIR_ERROR 1
> etc...
>
>
> ---
>
> It appears that Msg type 3 is never used with reply.
>
> ---
>
>  100     FILE *f;
>
> Unused?
>
> ---
>   92     int child;
>
> Unused?
>
> ---
>
>
>   97     char name [256];
>
> Unused?
>
> ---
>
>  164     } else {
>  165         /* empty environment */
>  166         env = &nullptr;
>  167     }
>
> It feels wrong to have to special-case the
>
> empty environment.
>   
> ---
>   26 #undef  _LARGEFILE64_SOURCE
>   27 #define _LARGEFILE64_SOURCE 1
>
> There's probably a reason why we want 
> _LARGEFILE64_SOURCE
> defined in the new source files.
>
> ---
>
> Martin
>
>   
> ---
> On Fri, May 22, 2009 at 03:05, Michael McMahon 
> <Michael.McMahon at sun.com <mailto:Michael.McMahon at sun.com>> wrote:
>
>     Hi,
>
>     I have just posted a webrev for 5049299: (process) Use
>     posix_spawn, not fork, on S10 to avoid swap exhaustion.
>
>     webrev location:
>     http://cr.openjdk.java.net/~michaelm/5049299/webrev.00/
>     <http://cr.openjdk.java.net/%7Emichaelm/5049299/webrev.00/>
>
>     **I'd like to give an outline of the change here, to make
>     reviewing the webrev a bit easier.
>     Basically, while posix_spawn() is a fairly elaborate and
>     complicated system call, it can't quite do
>     everything that the old fork()/exec() combination can do, so the
>     only feasible way to do this, is to
>     use posix_spawn to launch a new helper executable "processhelper",
>     which in turn execs the
>     target (after cleaning up file-descriptors etc.) The end result is
>     the same as before, a child process
>     linked to the parent in the same way, but it avoids the problem of
>     duplicating the parent (VM) process
>     address space temporarily, before launching the target command.
>
>     In the original implementation, the native code for
>     UNIXProcess.forkAndExec() was the same
>     for both Linux and Solaris.  Now, we have split it, so that Linux
>     retains the original implementation
>     but for Solaris, the native method is renamed spawn() where the
>     implementation is partly in this function,
>     but also partly in the new processhelper binary, which is spawned
>     by the spawn() method.
>
>     A number of utility functions, which were originally in
>     UNIXProcess_md.c, are also needed by the
>     processhelper binary, have been moved into new source files
>     (processutil_md.[ch]).
>     Because the functions were originally static in UNIXProcess_md.c,
>     a prefix is added to their names (jlup_)
>     (from initials of java.lang.UNIXProcess), to avoid any conflict in
>     global scope. This applies to the Linux
>     version as well as the Solaris version. So, this looks like new
>     code, but the body of these functions
>     are not changed from before.
>
>     I'm proposing not to add any unit/regression tests for this
>     change, since the point of it
>     is kind of self-evident from the source code (ie. stop using
>     fork() and use posix_spawn() instead),
>     and there shouldn't be any behaviour change other than memory usage.
>     This area of the platform seems to be well covered by existing
>     regression/unit tests.
>
>     Hope this helps,
>     Thanks,
>     Michael.
>
>



From Ulf.Zibis at gmx.de  Fri May 22 22:37:32 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Sat, 23 May 2009 00:37:32 +0200
Subject: hg: jdk7/tl/jdk: 6843578: Re-implement IBM doublebyte charsets;
	...
In-Reply-To: <4A17102B.8000800@sun.com>
References: <20090522065637.004DBE7AA@hg.openjdk.java.net>
	<4A167CCE.2070500@gmx.de> <4A17102B.8000800@sun.com>
Message-ID: <4A17292C.2040603@gmx.de>

Am 22.05.2009 22:50, Xueming Shen schrieb:
> Ulf Zibis wrote:
>>
>> I think I have forgotten one thing:
>>
>> isisDoubleByte() in DoubleByte uses hard-wired values. Shouldn't they 
>> be better b1Min etc. ?
>>
> These hardcoded values are explicitly specified by the "spec" of 
> ebcdic doublebyte encoding. So I
> think it's fine to leave them hard-wired.
>
> Sherman

Ah, ok, I didn't know, that your DoubleByte class is exclusively 
designed for EBCDIC, I thought, it is base class for whatever 
double-byte encoding.
So, being pedantic, it should be named DoubleByteEBCDIC (?)

Ulf




From martinrb at google.com  Sat May 23 00:57:26 2009
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 22 May 2009 17:57:26 -0700
Subject: Review request for 5049299
In-Reply-To: <4A172398.9000100@sun.com>
References: <4A1678DB.9010209@sun.com>
	<1ccfd1c10905221230u6f085d6eu26e0c516784e81ee@mail.gmail.com>
	<4A172398.9000100@sun.com>
Message-ID: <1ccfd1c10905221757t30a7f610jd343084e50ec88bb@mail.gmail.com>

On Fri, May 22, 2009 at 15:13, Michael McMahon <Michael.McMahon at sun.com>wrote:

> Martin,
>
> Thanks. Great comments. Just a few comments of my own
> on a couple of points.
>
> 1. Linux won't benefit from this change as much as solaris, since due to
> its
>   "memory overcommit" architecture, it doesn't suffer from the problem (so
> much)
>    in the first place (though memory overcommit causes some problems of its
> own).
>    Nevertheless, maybe it could simplify the code a bit if we use
> posix_spawn() on Linux
>    as well. So, I will look into that.
>

Thank you very much.

Any company running server farms (think "Sun" or "Google")
would like to "bin-pack" as many processes as possible onto them,
and transient doubling of process size is a big problem in such an
environment.  Think of this as a
saving-the-planet-from-global-warning feature.


2. Support for older Solaris releases. My understanding was that jdk7
> doesn't need to support
>   older releases of Solaris (than S10). Can someone clarify that situation?


Sun used to be *so* conservative.
I think 5 years of support after OS FCS is a minimum.
Especially for Solaris, which is very much a server OS.



> 3. Avoiding invocation of processhelper sometimes. The biggest issue (I
> found) with posix_spawn()
>   is that it doesn't work too well in multi-threaded environments like the
> JVM.  The specific problem
>   is that you have to set up a set of file-descriptor actions, prior to
> calling the function, whose purpose
>   is to close file descriptors from the parent process in the child.
> Because the two parts to this are not
>   atomic, other file descriptors could be opened/closed in the intervening
> period, and you couldn't
>   guarantee that they would be handled correctly. So, for that reason, I
> see no way to avoid the
>   "processhelper" approach, where we take care of the child's file
> descriptors after the child is spawned.
>

I think you are perfectly right.
I think I came to the same conclusion myself once,
but then forgot about it.

---

The other approach on Linux is to try clone(2)
with flag CLONE_VM
but not CLONE_VFORK or CLONE_FS or CLONE_FILES,
instead of fork().  Then the child can modify
file descriptors and chdir without interference
except for the "small" problem that all memory is shared.
This doesn't work for environment variables,
so more special-casing or trickery may be required.

Martin


>
> Thanks,
> Michael.
>
> Martin Buchholz wrote:
>
>> Hi Michael,
>>
>> I am very happy to see this being worked on;
>> I would have done something like this
>> already if I could fork() myself.
>>
>> This code is very tricky and has had many subtle bugs over the years.
>>
>> ---
>>
>> Any way we could add Linux support to this,
>> via some flavor of low-level clone+exec?
>> Let me restate that more strongly -
>> we would really really want to solve the
>> memory problem for Linux as well - but how?
>>
>> ---
>>
>> Remove space before (
>> return System.getProperty ("java.home");
>>
>> Our C coding style is idiosyncratic,
>> but there also remove spaces for
>> function calls.
>>  ---
>>
>> Isn't spawn only supported as of Solaris 10?
>> I don't see anything in the change for
>> older versions of Solaris.
>>
>> ---
>>
>> The standard way of detecting presence of a function
>> at runtime is
>> dlsym(RTLD_DEFAULT, "function_name") != NULL
>>
>> Wait! libc also has posix_spawn and friends!
>> On many systems we should be able to find posix_spawn.
>> Perhaps in most common special cases we can dispense with processhelper
>> and spawn the target executable directly?
>>
>> ---
>>
>> processhelper should probably be named something more obviously
>> java-related
>> e.g. javaprocesshelper.
>> Can we try to not install it in BINDIR, since it is not intended to be run
>> by users,
>> but hide it in some private subdir?
>>
>> ---
>>
>> Please add include guards to
>> processutil_md.h
>>
>> even though you can get away with not having them.
>>
>> ---
>>  296  * Reads nbyte bytes from file descriptor fd into buf,
>> Change comma to period.
>>
>> ---
>> processutil_md.h
>> can be made smaller.
>> Utilities such as
>> isAsciiDigit
>>
>> can be static functions called from processutil_md.c
>>  ---
>>  41  * Utility used by j.l.ProcessBuilder (via UNIXProcess) to launch
>>
>> In source code, let's splurge and write out java.lang instead of j.l.
>>
>> ---
>>  47  * argv[1] working directory for command
>>
>>
>> Add "or the empty string if none provided"
>>
>> ---
>>
>> You appear to be both reading and writing to single fd pipefd.
>> I don't think bidirectional pipes are standard Unix.
>> I'd prefer to see separate read and write pipes.
>>
>>
>> ---
>>
>>  65  * - Msg type (4 bytes)
>>  66  *      1 = chdir error (detail in Field 1)
>>  67  *      2 = exec error (detail in Field 1)
>>  68  *      3 = target terminated (exit code in Field 1)
>>
>> Please use constants
>>
>>
>> #define CHDIR_ERROR 1
>> etc...
>>
>>
>> ---
>>
>> It appears that Msg type 3 is never used with reply.
>>
>> ---
>>
>>  100     FILE *f;
>>
>> Unused?
>>
>> ---
>>  92     int child;
>>
>> Unused?
>>
>> ---
>>
>>
>>  97     char name [256];
>>
>> Unused?
>>
>> ---
>>
>>  164     } else {
>>  165         /* empty environment */
>>  166         env = &nullptr;
>>  167     }
>>
>> It feels wrong to have to special-case the
>>
>> empty environment.
>>  ---
>>  26 #undef  _LARGEFILE64_SOURCE
>>  27 #define _LARGEFILE64_SOURCE 1
>>
>> There's probably a reason why we want _LARGEFILE64_SOURCE
>> defined in the new source files.
>>
>> ---
>>
>> Martin
>>
>>  ---
>> On Fri, May 22, 2009 at 03:05, Michael McMahon <Michael.McMahon at sun.com<mailto:
>> Michael.McMahon at sun.com>> wrote:
>>
>>    Hi,
>>
>>    I have just posted a webrev for 5049299: (process) Use
>>    posix_spawn, not fork, on S10 to avoid swap exhaustion.
>>
>>    webrev location:
>>    http://cr.openjdk.java.net/~michaelm/5049299/webrev.00/<http://cr.openjdk.java.net/%7Emichaelm/5049299/webrev.00/>
>>    <http://cr.openjdk.java.net/%7Emichaelm/5049299/webrev.00/>
>>
>>
>>    **I'd like to give an outline of the change here, to make
>>    reviewing the webrev a bit easier.
>>    Basically, while posix_spawn() is a fairly elaborate and
>>    complicated system call, it can't quite do
>>    everything that the old fork()/exec() combination can do, so the
>>    only feasible way to do this, is to
>>    use posix_spawn to launch a new helper executable "processhelper",
>>    which in turn execs the
>>    target (after cleaning up file-descriptors etc.) The end result is
>>    the same as before, a child process
>>    linked to the parent in the same way, but it avoids the problem of
>>    duplicating the parent (VM) process
>>    address space temporarily, before launching the target command.
>>
>>    In the original implementation, the native code for
>>    UNIXProcess.forkAndExec() was the same
>>    for both Linux and Solaris.  Now, we have split it, so that Linux
>>    retains the original implementation
>>    but for Solaris, the native method is renamed spawn() where the
>>    implementation is partly in this function,
>>    but also partly in the new processhelper binary, which is spawned
>>    by the spawn() method.
>>
>>    A number of utility functions, which were originally in
>>    UNIXProcess_md.c, are also needed by the
>>    processhelper binary, have been moved into new source files
>>    (processutil_md.[ch]).
>>    Because the functions were originally static in UNIXProcess_md.c,
>>    a prefix is added to their names (jlup_)
>>    (from initials of java.lang.UNIXProcess), to avoid any conflict in
>>    global scope. This applies to the Linux
>>    version as well as the Solaris version. So, this looks like new
>>    code, but the body of these functions
>>    are not changed from before.
>>
>>    I'm proposing not to add any unit/regression tests for this
>>    change, since the point of it
>>    is kind of self-evident from the source code (ie. stop using
>>    fork() and use posix_spawn() instead),
>>    and there shouldn't be any behaviour change other than memory usage.
>>    This area of the platform seems to be well covered by existing
>>    regression/unit tests.
>>
>>    Hope this helps,
>>    Thanks,
>>    Michael.
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090522/ef596c17/attachment.html>

From aph at redhat.com  Sat May 23 08:14:00 2009
From: aph at redhat.com (Andrew Haley)
Date: Sat, 23 May 2009 09:14:00 +0100
Subject: Request for approval: Bug 100057 -  Potential stack corruption
	in	GetJavaProperties
In-Reply-To: <4A171462.7000303@sun.com>
References: <4A168808.5050805@redhat.com> <4A168E0C.4040603@sun.com>
	<4A16D664.1050703@redhat.com> <4A16E12F.3060006@sun.com>
	<4A16E373.3030709@redhat.com> <4A171462.7000303@sun.com>
Message-ID: <4A17B048.2060303@redhat.com>

Xueming Shen wrote:
> Andrew Haley wrote:
>>              }
>>
>>              if (mapLookup(locale_aliases, temp, &p)) {
>> -                strcpy(temp, p);
>> +                temp = realloc(temp, strlen(p)+1);
>> +                if (temp == NULL) {
>> +                    JNU_ThrowOutOfMemoryError(env, NULL);
>> +                    return NULL;
>> +                }
>> +        strcpy(temp, p);
>>   
> 
> The max length string comes back from mapLookup(locale_aliases...) is
> known (in locale_str.h) , so if we can
> give temp a minimum size when malloc, for example 64:-) then we might
> not need to update the code above

It's fairly clear that this code can be correctly written in a great
many ways, but among the correct solutions there isn't much reason to
prefer one over the other.  I will make the change you suggest if it
is needed to get the patch in.

Andrew.


From aph at redhat.com  Sat May 23 08:28:43 2009
From: aph at redhat.com (Andrew Haley)
Date: Sat, 23 May 2009 09:28:43 +0100
Subject: Review request for 5049299
In-Reply-To: <1ccfd1c10905221757t30a7f610jd343084e50ec88bb@mail.gmail.com>
References: <4A1678DB.9010209@sun.com>	<1ccfd1c10905221230u6f085d6eu26e0c516784e81ee@mail.gmail.com>	<4A172398.9000100@sun.com>
	<1ccfd1c10905221757t30a7f610jd343084e50ec88bb@mail.gmail.com>
Message-ID: <4A17B3BB.4090706@redhat.com>

Martin Buchholz wrote:
> On Fri, May 22, 2009 at 15:13, Michael McMahon <Michael.McMahon at sun.com>wrote:
> 
>> Martin,
>>
>> Thanks. Great comments. Just a few comments of my own
>> on a couple of points.
>>
>> 1. Linux won't benefit from this change as much as solaris, since due to
>> its
>>   "memory overcommit" architecture, it doesn't suffer from the problem (so
>> much)
>>    in the first place (though memory overcommit causes some problems of its
>> own).
>>    Nevertheless, maybe it could simplify the code a bit if we use
>> posix_spawn() on Linux
>>    as well. So, I will look into that.
> 
> Any company running server farms (think "Sun" or "Google")
> would like to "bin-pack" as many processes as possible onto them,
> and transient doubling of process size is a big problem in such an
> environment.  Think of this as a
> saving-the-planet-from-global-warning feature.

But those running Linux won't benefit from such a change because
on Linux there is no transient doubling of process size: all that happens
is that the page table entries in the new process are mapped copy on write.
The extra pages count towards the overcommit limit, but that's wholly
artifical.

Andrew.


From Alan.Bateman at Sun.COM  Sat May 23 13:48:04 2009
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Sat, 23 May 2009 14:48:04 +0100
Subject: Review request for 5049299
In-Reply-To: <4A172398.9000100@sun.com>
References: <4A1678DB.9010209@sun.com>
	<1ccfd1c10905221230u6f085d6eu26e0c516784e81ee@mail.gmail.com>
	<4A172398.9000100@sun.com>
Message-ID: <4A17FE94.6000605@sun.com>

Michael McMahon wrote:
> :
>
> 2. Support for older Solaris releases. My understanding was that jdk7 
> doesn't need to support
>    older releases of Solaris (than S10). Can someone clarify that 
> situation?
Yes, that's right. Solaris 10 was released >4 years ago and the last 
ship date for Solaris 9 is approaching [1]. The jdk build moved to 
Solaris 10 last year. I don't think it has been buildable on older 
Solaris releases for some time.

-Alan.

[1] http://www.sun.com/service/eosl/eosl_solaris.html


From Alan.Bateman at Sun.COM  Sat May 23 15:37:30 2009
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Sat, 23 May 2009 16:37:30 +0100
Subject: Request for approval: Bug 100057 - Potential stack corruption in
	GetJavaProperties
In-Reply-To: <4A17B048.2060303@redhat.com>
References: <4A168808.5050805@redhat.com> <4A168E0C.4040603@sun.com>
	<4A16D664.1050703@redhat.com> <4A16E12F.3060006@sun.com>
	<4A16E373.3030709@redhat.com> <4A171462.7000303@sun.com>
	<4A17B048.2060303@redhat.com>
Message-ID: <4A18183A.9030505@sun.com>

Andrew Haley wrote:
> Xueming Shen wrote:
>   
>> Andrew Haley wrote:
>>     
>>>              }
>>>
>>>              if (mapLookup(locale_aliases, temp, &p)) {
>>> -                strcpy(temp, p);
>>> +                temp = realloc(temp, strlen(p)+1);
>>> +                if (temp == NULL) {
>>> +                    JNU_ThrowOutOfMemoryError(env, NULL);
>>> +                    return NULL;
>>> +                }
>>> +        strcpy(temp, p);
>>>   
>>>       
>> The max length string comes back from mapLookup(locale_aliases...) is
>> known (in locale_str.h) , so if we can
>> give temp a minimum size when malloc, for example 64:-) then we might
>> not need to update the code above
>>     
>
> It's fairly clear that this code can be correctly written in a great
> many ways, but among the correct solutions there isn't much reason to
> prefer one over the other.  I will make the change you suggest if it
> is needed to get the patch in.
>
>   
Sherman's suggestion does avoid a realloc when an alias is used but the 
initial sizing would need a comment to help future maintainers. As it 
stands, the current patch should make it obvious to future maintainers 
that the strcpy is safe. Up to you if you want to spend any more time on 
it but either is okay with me.

-Alan.



From martinrb at google.com  Sat May 23 18:12:15 2009
From: martinrb at google.com (Martin Buchholz)
Date: Sat, 23 May 2009 11:12:15 -0700
Subject: Review request for 5049299
In-Reply-To: <4A17B3BB.4090706@redhat.com>
References: <4A1678DB.9010209@sun.com>
	<1ccfd1c10905221230u6f085d6eu26e0c516784e81ee@mail.gmail.com>
	<4A172398.9000100@sun.com>
	<1ccfd1c10905221757t30a7f610jd343084e50ec88bb@mail.gmail.com>
	<4A17B3BB.4090706@redhat.com>
Message-ID: <1ccfd1c10905231112k61d8e13h31f693951ed91b76@mail.gmail.com>

On Sat, May 23, 2009 at 01:28, Andrew Haley <aph at redhat.com> wrote:

> Martin Buchholz wrote:
> > On Fri, May 22, 2009 at 15:13, Michael McMahon <Michael.McMahon at sun.com
> >wrote:
> >
> >> Martin,
> >>
> >> Thanks. Great comments. Just a few comments of my own
> >> on a couple of points.
> >>
> >> 1. Linux won't benefit from this change as much as solaris, since due to
> >> its
> >>   "memory overcommit" architecture, it doesn't suffer from the problem
> (so
> >> much)
> >>    in the first place (though memory overcommit causes some problems of
> its
> >> own).
> >>    Nevertheless, maybe it could simplify the code a bit if we use
> >> posix_spawn() on Linux
> >>    as well. So, I will look into that.
> >
> > Any company running server farms (think "Sun" or "Google")
> > would like to "bin-pack" as many processes as possible onto them,
> > and transient doubling of process size is a big problem in such an
> > environment.  Think of this as a
> > saving-the-planet-from-global-warning feature.
>
> But those running Linux won't benefit from such a change because
> on Linux there is no transient doubling of process size: all that happens
> is that the page table entries in the new process are mapped copy on write.
> The extra pages count towards the overcommit limit, but that's wholly
> artifical.
>

I confess to incomplete understanding of the situation on Linux, but...
I agree that the limit is artificial,
in that there is no doubling of actual  memory.
It's a monitoring problem, whether internal to the linux kernel
or perhaps some other external software "accounting" entity.
Nevertheless, I believe this limit prevents a process currently using
75% of memory from starting a small subprocess and
expect that clone() with CLONE_VM will fix that.

Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090523/bd22dd4f/attachment.html>

From aph at redhat.com  Sat May 23 19:09:01 2009
From: aph at redhat.com (Andrew Haley)
Date: Sat, 23 May 2009 20:09:01 +0100
Subject: Review request for 5049299
In-Reply-To: <1ccfd1c10905231112k61d8e13h31f693951ed91b76@mail.gmail.com>
References: <4A1678DB.9010209@sun.com>	
	<1ccfd1c10905221230u6f085d6eu26e0c516784e81ee@mail.gmail.com>	
	<4A172398.9000100@sun.com>	
	<1ccfd1c10905221757t30a7f610jd343084e50ec88bb@mail.gmail.com>	
	<4A17B3BB.4090706@redhat.com>
	<1ccfd1c10905231112k61d8e13h31f693951ed91b76@mail.gmail.com>
Message-ID: <4A1849CD.3060306@redhat.com>

Martin Buchholz wrote:

> I confess to incomplete understanding of the situation on Linux, but...
> I agree that the limit is artificial,
> in that there is no doubling of actual  memory.
> It's a monitoring problem, whether internal to the linux kernel
> or perhaps some other external software "accounting" entity.
> Nevertheless, I believe this limit prevents a process currently using
> 75% of memory from starting a small subprocess and
> expect that clone() with CLONE_VM will fix that.

AFAIAA that should not happen.  I'd be interested to try a test case.

Andrew.


From martinrb at google.com  Sun May 24 01:10:34 2009
From: martinrb at google.com (Martin Buchholz)
Date: Sat, 23 May 2009 18:10:34 -0700
Subject: Review request for 5049299
In-Reply-To: <4A1849CD.3060306@redhat.com>
References: <4A1678DB.9010209@sun.com>
	<1ccfd1c10905221230u6f085d6eu26e0c516784e81ee@mail.gmail.com>
	<4A172398.9000100@sun.com>
	<1ccfd1c10905221757t30a7f610jd343084e50ec88bb@mail.gmail.com>
	<4A17B3BB.4090706@redhat.com>
	<1ccfd1c10905231112k61d8e13h31f693951ed91b76@mail.gmail.com>
	<4A1849CD.3060306@redhat.com>
Message-ID: <1ccfd1c10905231810k17a99cd3vfa68d6108e28b46@mail.gmail.com>

I did a little research.

The overcommitment policy on Linux is configurable
http://lxr.linux.no/linux/Documentation/vm/overcommit-accounting
Of course, almost everyone will use the default "heuristic" policy,
and in this case the COW memory after fork() is subject to overcommit
accounting, which *may* cause the fork to fail.
http://lkml.indiana.edu/hypermail/linux/kernel/0902.1/01777.html
If a solution using clone(CLONE_VM ...) can be made to work,
subprocess creation will be a little cheaper and significantly more
reliable.

Martin

On Sat, May 23, 2009 at 12:09, Andrew Haley <aph at redhat.com> wrote:

> Martin Buchholz wrote:
>
> > I confess to incomplete understanding of the situation on Linux, but...
> > I agree that the limit is artificial,
> > in that there is no doubling of actual  memory.
> > It's a monitoring problem, whether internal to the linux kernel
> > or perhaps some other external software "accounting" entity.
> > Nevertheless, I believe this limit prevents a process currently using
> > 75% of memory from starting a small subprocess and
> > expect that clone() with CLONE_VM will fix that.
>
> AFAIAA that should not happen.  I'd be interested to try a test case.
>
> Andrew.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090523/c31a9d04/attachment.html>

From martinrb at google.com  Sun May 24 01:20:40 2009
From: martinrb at google.com (Martin Buchholz)
Date: Sat, 23 May 2009 18:20:40 -0700
Subject: Review request for 5049299
In-Reply-To: <4A1678DB.9010209@sun.com>
References: <4A1678DB.9010209@sun.com>
Message-ID: <1ccfd1c10905231820i75d9fc1dg4717928f2e0825a@mail.gmail.com>

Two comments:

---

I would use _exit instead of standard exit in the process helper code,
as in the existing code, although unlike the existing code,
it doesn't seem to be a correctness issue.

---

I implemented

defaultPath

but should have tried to use confstr(_SC_PATH)

as in this example from the confstr manpage:

           char *pathbuf;
           size_t n;

           n = confstr(_CS_PATH,NULL,(size_t) 0);
           pathbuf = malloc(n);
           if (pathbuf == NULL)
               abort();
           confstr(_CS_PATH, pathbuf, n);

Of course, only within
#ifdef _CS_PATH

That's a small portability bug that is worth
fixing now that the jdk sources are targeting more platforms.

Martin

On Fri, May 22, 2009 at 03:05, Michael McMahon <Michael.McMahon at sun.com>wrote:

> Hi,
>
> I have just posted a webrev for 5049299: (process) Use posix_spawn, not
> fork, on S10 to avoid swap exhaustion.
>
> webrev location: http://cr.openjdk.java.net/~michaelm/5049299/webrev.00/<http://cr.openjdk.java.net/%7Emichaelm/5049299/webrev.00/>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090523/6d2cd33b/attachment.html>

From aph at redhat.com  Sun May 24 09:16:19 2009
From: aph at redhat.com (Andrew Haley)
Date: Sun, 24 May 2009 10:16:19 +0100
Subject: Review request for 5049299
In-Reply-To: <1ccfd1c10905231810k17a99cd3vfa68d6108e28b46@mail.gmail.com>
References: <4A1678DB.9010209@sun.com>	
	<1ccfd1c10905221230u6f085d6eu26e0c516784e81ee@mail.gmail.com>	
	<4A172398.9000100@sun.com>	
	<1ccfd1c10905221757t30a7f610jd343084e50ec88bb@mail.gmail.com>	
	<4A17B3BB.4090706@redhat.com>	
	<1ccfd1c10905231112k61d8e13h31f693951ed91b76@mail.gmail.com>	
	<4A1849CD.3060306@redhat.com>
	<1ccfd1c10905231810k17a99cd3vfa68d6108e28b46@mail.gmail.com>
Message-ID: <4A191063.5060401@redhat.com>

Martin Buchholz wrote:
> I did a little research.
> 
> The overcommitment policy on Linux is configurable
> http://lxr.linux.no/linux/Documentation/vm/overcommit-accounting
> Of course, almost everyone will use the default "heuristic" policy,
> and in this case the COW memory after fork() is subject to overcommit
> accounting, which *may* cause the fork to fail.

Sure, it *may*, but I don't think it's at all common.

> http://lkml.indiana.edu/hypermail/linux/kernel/0902.1/01777.html
> If a solution using clone(CLONE_VM ...) can be made to work,
> subprocess creation will be a little cheaper and significantly more
> reliable.

Maybe, but I think that needs to be measured before any changes are made.
I'm not opposed to such a change that makes a real improvement, but I'm
not convinced it will.  As usual, I'm happy to be proved wrong.

There may be a kernel bug in the case described in the mail above: it
certainly should be possible to fork a 38 GB process on a system with
64 GB RAM.  If so, I expect that this will be fixed long before any Java
VM change makes it into production.

Andrew.


From xiaobin.lu at sun.com  Sun May 24 23:40:34 2009
From: xiaobin.lu at sun.com (xiaobin.lu at sun.com)
Date: Sun, 24 May 2009 23:40:34 +0000
Subject: hg: jdk7/tl/jdk: 6622432: RFE: Performance improvements to
	java.math.BigDecimal
Message-ID: <20090524234057.6E60DE931@hg.openjdk.java.net>

Changeset: 8d2efec31d78
Author:    xlu
Date:      2009-05-24 16:29 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8d2efec31d78

6622432: RFE: Performance improvements to java.math.BigDecimal
Reviewed-by: darcy

! src/share/classes/java/math/BigDecimal.java
! src/share/classes/java/math/BigInteger.java
! src/share/classes/java/math/BitSieve.java
! src/share/classes/java/math/MathContext.java
! src/share/classes/java/math/MutableBigInteger.java
! src/share/classes/java/math/SignedMutableBigInteger.java
! test/java/math/BigDecimal/AddTests.java
! test/java/math/BigDecimal/DivideTests.java



From martinrb at google.com  Mon May 25 01:09:22 2009
From: martinrb at google.com (Martin Buchholz)
Date: Sun, 24 May 2009 18:09:22 -0700
Subject: Review request for 5049299
In-Reply-To: <4A191063.5060401@redhat.com>
References: <4A1678DB.9010209@sun.com>
	<1ccfd1c10905221230u6f085d6eu26e0c516784e81ee@mail.gmail.com>
	<4A172398.9000100@sun.com>
	<1ccfd1c10905221757t30a7f610jd343084e50ec88bb@mail.gmail.com>
	<4A17B3BB.4090706@redhat.com>
	<1ccfd1c10905231112k61d8e13h31f693951ed91b76@mail.gmail.com>
	<4A1849CD.3060306@redhat.com>
	<1ccfd1c10905231810k17a99cd3vfa68d6108e28b46@mail.gmail.com>
	<4A191063.5060401@redhat.com>
Message-ID: <1ccfd1c10905241809m10ded53bpb4c9360f76b36888@mail.gmail.com>

Below is a java program and a shell extract demonstrating the problem
on a Ubuntu-hardy-like system.  The fork() fails from within a large
Java process (but normal commands started from an
independent shell continue to work fine).

Linux overcommit heuristics are hard to understand.

The failing fork problem becomes more serious on a server system
running only one significant large program, which is using most of
the memory on the system, perhaps by sysctl'ing
the vm.overcommit_ratio to a value higher than the default 50%.

On systems with two large processes using most of memory,
you may see rare failures when both try to fork() at the same time..

$ perl -e 'system("cat BigFork.java"); print "-----\n"; system("javac
BigFork.java"); system("java -showversion -Xmx6000m BigFork")'
import java.util.*;
import java.io.*;

public class BigFork {
    static void touchPages(byte[] chunk) {
        final int pageSize = 4096;
        for (int i = 0; i < chunk.length; i+= pageSize) {
            chunk[i] = (byte) '!';
        }
    }

    static void showCommittedMemory() throws IOException {
        BufferedReader r =
            new BufferedReader(
                new InputStreamReader(
                    new FileInputStream("/proc/meminfo")));
        System.out.println("-------");
        String line;
        while ((line = r.readLine()) != null) {
            if (line.startsWith("Commit")) {
                System.out.printf("%s%n", line);
            }
        }
        System.out.println("-------");
    }

    public static void main(String[] args) throws Throwable {
        final int chunkSize = 1024 * 1024 * 100;
        List<byte[]> chunks = new ArrayList<byte[]>(100);
        try {
            for (;;) {
                byte[] chunk = new byte[chunkSize];
                touchPages(chunk);
                chunks.add(chunk);
            }
        } catch (OutOfMemoryError e) {
            chunks.set(0, null);        // Free up one chunk
            System.gc();
            int size = chunks.size();
            System.out.printf("size=%.2gGB%n", (double)size/10);

            showCommittedMemory();

            // Can we fork/exec in our current bloated state?
            Process p = new ProcessBuilder("/bin/true").start();
            p.waitFor();
        }
    }
}
-----
openjdk version "1.7.0-Goobuntu"
OpenJDK Runtime Environment (build 1.7.0-Goobuntu-b59)
OpenJDK 64-Bit Server VM (build 16.0-b03, mixed mode)

size=3.9GB
-------
CommitLimit:   6214700 kB
Committed_AS:  6804248 kB
-------
Exception in thread "main" java.io.IOException: Cannot run program
"/bin/true": java.io.IOException: error=12, Cannot allocate memory
    at java.lang.ProcessBuilder.start(ProcessBuilder.java:1018)
    at BigFork.main(BigFork.java:45)
Caused by: java.io.IOException: java.io.IOException: error=12, Cannot
allocate memory
    at java.lang.UNIXProcess.<init>(UNIXProcess.java:190)
    at java.lang.ProcessImpl.start(ProcessImpl.java:128)
    at java.lang.ProcessBuilder.start(ProcessBuilder.java:1010)


Martin

On Sun, May 24, 2009 at 02:16, Andrew Haley <aph at redhat.com> wrote:

> Martin Buchholz wrote:
> > I did a little research.
> >
> > The overcommitment policy on Linux is configurable
> > http://lxr.linux.no/linux/Documentation/vm/overcommit-accounting
> > Of course, almost everyone will use the default "heuristic" policy,
> > and in this case the COW memory after fork() is subject to overcommit
> > accounting, which *may* cause the fork to fail.
>
> Sure, it *may*, but I don't think it's at all common.
>
> > http://lkml.indiana.edu/hypermail/linux/kernel/0902.1/01777.html
> > If a solution using clone(CLONE_VM ...) can be made to work,
> > subprocess creation will be a little cheaper and significantly more
> > reliable.
>
> Maybe, but I think that needs to be measured before any changes are made.
> I'm not opposed to such a change that makes a real improvement, but I'm
> not convinced it will.  As usual, I'm happy to be proved wrong.
>
> There may be a kernel bug in the case described in the mail above: it
> certainly should be possible to fork a 38 GB process on a system with
> 64 GB RAM.  If so, I expect that this will be fixed long before any Java
> VM change makes it into production.
>
> Andrew.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090524/dbf40029/attachment.html>

From martinrb at google.com  Mon May 25 06:42:47 2009
From: martinrb at google.com (Martin Buchholz)
Date: Sun, 24 May 2009 23:42:47 -0700
Subject: c.toArray might (incorrectly) not return Object[] (see 6260652)
In-Reply-To: <4A16950A.5020108@sun.com>
References: <87pre2nzls.fsf@mid.deneb.enyo.de> <4A16087D.60205@sun.com>
	<87skix3fu8.fsf@mid.deneb.enyo.de> <4A163072.5040309@sun.com>
	<4A1687BF.3080008@cs.oswego.edu> <4A168AF5.7080808@sun.com>
	<4A168D26.4050303@cs.oswego.edu> <4A169053.4050608@sun.com>
	<4A1692D8.1030909@cs.oswego.edu> <4A16950A.5020108@sun.com>
Message-ID: <1ccfd1c10905242342p12414508j8d60e72667cd150d@mail.gmail.com>

I continue to believe that not fixing 6260652
was a mistake, both technically and
from the point of view of community relations.

I prefer the current implementation of ArrayList(Collection)
to one using c.toArray(ZERO_ARRAY) because it has
slightly less trust of the argument collection.
(In any case, I think it's an academic question;
it would not be worth changing
either implementation to the other for aesthetic reasons)

Historically, we have also had bugs implementing
toArray(T[]).

Martin

On Fri, May 22, 2009 at 05:05, David Holmes - Sun Microsystems <
David.Holmes at sun.com> wrote:

> Doug Lea said the following on 05/22/09 21:56:
>
>> Sorry; I should have been clearer about why
>>  c.toArray(new Object[c.size()])
>> is subtly wrong here. ArrayList.size must equal
>> the number of elements, which might be different
>> than the array size. If c's size shrinks at an
>> inconvenient moment during the call, then we might
>> think that the trailing null, that toArray(T[] a)
>> is required to append if a is too big, is actually a
>> (null) element of the collection.
>>
>
> Ah I see.
>
> I'm thinking though that I'd find this hack more aesthetically pleasing:
>
>  static final Object[] ZERO_ARRAY = new Object[0];
>  ...
>  elementData = c.toArray(ZERO_ARRAY);
>
> this deals with the size issue, gets the right type and only creates one
> array (asuming the collection doesn't concurrently grow).
>
> Cheers,
> David
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090524/7979cb8d/attachment.html>

From xiaobin.lu at sun.com  Mon May 25 19:33:53 2009
From: xiaobin.lu at sun.com (xiaobin.lu at sun.com)
Date: Mon, 25 May 2009 12:33:53 -0700
Subject: hg: jdk7/tl/jdk: 6806261: BigDecimal.longValueExact() method throws
	NullPointerException
Message-ID: <20090525193413.98928E9A4@hg.openjdk.java.net>

Changeset: 3994c5c669cb
Author:    xlu
Date:      2009-05-24 16:35 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3994c5c669cb

6806261: BigDecimal.longValueExact() method throws NullPointerException
Summary: add various tests to test the change to 6622432
Reviewed-by: darcy

+ test/java/math/BigDecimal/EqualsTests.java
+ test/java/math/BigDecimal/LongValueExactTests.java
+ test/java/math/BigDecimal/MultiplyTests.java
+ test/java/math/BigDecimal/PrecisionTests.java
+ test/java/math/BigInteger/CompareToTests.java



From Xueming.Shen at Sun.COM  Mon May 25 20:30:16 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Mon, 25 May 2009 13:30:16 -0700
Subject: Request for approval: Bug 100057 - Potential stack corruption in
	GetJavaProperties
In-Reply-To: <4A17B048.2060303@redhat.com>
References: <4A168808.5050805@redhat.com> <4A168E0C.4040603@sun.com>
	<4A16D664.1050703@redhat.com> <4A16E12F.3060006@sun.com>
	<4A16E373.3030709@redhat.com> <4A171462.7000303@sun.com>
	<4A17B048.2060303@redhat.com>
Message-ID: <4A1AFFD8.7080407@sun.com>

Andrew Haley wrote:
> Xueming Shen wrote:
>   
>> Andrew Haley wrote:
>>     
>>>              }
>>>
>>>              if (mapLookup(locale_aliases, temp, &p)) {
>>> -                strcpy(temp, p);
>>> +                temp = realloc(temp, strlen(p)+1);
>>> +                if (temp == NULL) {
>>> +                    JNU_ThrowOutOfMemoryError(env, NULL);
>>> +                    return NULL;
>>> +                }
>>> +        strcpy(temp, p);
>>>   
>>>       
>> The max length string comes back from mapLookup(locale_aliases...) is
>> known (in locale_str.h) , so if we can
>> give temp a minimum size when malloc, for example 64:-) then we might
>> not need to update the code above
>>     
>
> It's fairly clear that this code can be correctly written in a great
> many ways, but among the correct solutions there isn't much reason to
> prefer one over the other.  I will make the change you suggest if it
> is needed to get the patch in.
>
> Andrew.
>   
It's simply a comment. The first thing popped up when read the code is 
"should we check the length
of p to see if really need to realloc"...then, if we already know the 
maximum length of the string from
aliases lookup why bother to even check the length/realloc each/every 
time. This is kind of nitpicking
comment,  so definitely not going to block your patch.

Sherman


From jean-christophe.collet at sun.com  Mon May 25 20:35:39 2009
From: jean-christophe.collet at sun.com (jean-christophe.collet at sun.com)
Date: Mon, 25 May 2009 20:35:39 +0000
Subject: hg: jdk7/tl/jdk: 6349566: java.net.CookieManager doesn't set default
	domain
Message-ID: <20090525203554.ED859E9B0@hg.openjdk.java.net>

Changeset: 206d73d299d4
Author:    jccollet
Date:      2009-05-25 22:27 +0200
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/206d73d299d4

6349566: java.net.CookieManager doesn't set default domain
Summary: Enforce default domain in CookieManager
Reviewed-by: michaelm

! src/share/classes/java/net/CookieManager.java
! test/java/net/CookieHandler/CookieManagerTest.java



From Joe.Darcy at Sun.COM  Mon May 25 22:09:00 2009
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Mon, 25 May 2009 15:09:00 -0700
Subject: Request for approval: fix 4428022,
	System.out.println(0.001) outputs	0.0010
In-Reply-To: <4A171185.8030504@sun.com>
References: <4A16806B.9060001@redhat.com> <4A169110.1030003@sun.com>
	<4A16DF30.6080509@redhat.com> <4A171185.8030504@sun.com>
Message-ID: <4A1B16FC.80108@sun.com>

Alan Bateman wrote:
> Andrew Haley wrote:
>> :
>> OK, here it is.  I put the test in java/lang/Double/ToString.java
>> rather than sun/misc/FloatingDecimal because the bug manifested
>> itself in Double.toString although the fix was in
>> FloatingDecimal.dtoa.
>>   
> I agree that test/java/lang/Double is the best place for this. All 
> looks good to me (except minor nit, "String argv[]" -> "String[] 
> args").  Joe, are you okay with this?
>
> -Alan.

Yes; the changes look fine for both releases.

Thanks,

-Joe


From weijun.wang at sun.com  Tue May 26 02:19:45 2009
From: weijun.wang at sun.com (weijun.wang at sun.com)
Date: Tue, 26 May 2009 02:19:45 +0000
Subject: hg: jdk7/tl/jdk: 6844887: NPE in TextCallbackHandler
Message-ID: <20090526022002.C84CCE9B5@hg.openjdk.java.net>

Changeset: dc3865883a5a
Author:    weijun
Date:      2009-05-26 10:12 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dc3865883a5a

6844887: NPE in TextCallbackHandler
Reviewed-by: xuelei

! src/share/classes/com/sun/security/auth/callback/TextCallbackHandler.java
+ test/com/sun/security/auth/callback/TextCallbackHandler/NPE.java



From xuelei.fan at sun.com  Tue May 26 08:34:27 2009
From: xuelei.fan at sun.com (xuelei.fan at sun.com)
Date: Tue, 26 May 2009 08:34:27 +0000
Subject: hg: jdk7/tl/jdk: 6822460: support self-issued certificate
Message-ID: <20090526083444.10EA1E9C8@hg.openjdk.java.net>

Changeset: d93b7df1e260
Author:    xuelei
Date:      2009-05-26 16:19 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d93b7df1e260

6822460: support self-issued certificate
Summary: checking self-issued certificate during certification path building
Reviewed-by: mullan, weijun

! src/share/classes/sun/security/validator/PKIXValidator.java
! src/share/classes/sun/security/validator/SimpleValidator.java
+ test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/SelfIssuedCert.java



From xuelei.fan at sun.com  Tue May 26 08:56:53 2009
From: xuelei.fan at sun.com (xuelei.fan at sun.com)
Date: Tue, 26 May 2009 08:56:53 +0000
Subject: hg: jdk7/tl/jdk: 6720721: CRL check with circular depency support
	needed
Message-ID: <20090526085706.9CC5CE9D1@hg.openjdk.java.net>

Changeset: c3c5cc0f2a3e
Author:    xuelei
Date:      2009-05-26 16:43 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c3c5cc0f2a3e

6720721: CRL check with circular depency support needed
Summary: checking AKID of certificates and CRLs
Reviewed-by: mullan, weijun

! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java
+ test/java/security/cert/CertPathValidator/indirectCRL/CircularCRLOneLevel.java
+ test/java/security/cert/CertPathValidator/indirectCRL/CircularCRLOneLevelRevoked.java
+ test/java/security/cert/CertPathValidator/indirectCRL/CircularCRLTwoLevel.java
+ test/java/security/cert/CertPathValidator/indirectCRL/CircularCRLTwoLevelRevoked.java
+ test/java/security/cert/CertPathValidator/indirectCRL/README
+ test/java/security/cert/CertPathValidator/indirectCRL/generate.sh
+ test/java/security/cert/CertPathValidator/indirectCRL/openssl.cnf



From Michael.McMahon at Sun.COM  Tue May 26 11:10:34 2009
From: Michael.McMahon at Sun.COM (Michael McMahon)
Date: Tue, 26 May 2009 12:10:34 +0100
Subject: Review request for 5049299
In-Reply-To: <1ccfd1c10905241809m10ded53bpb4c9360f76b36888@mail.gmail.com>
References: <4A1678DB.9010209@sun.com>
	<1ccfd1c10905221230u6f085d6eu26e0c516784e81ee@mail.gmail.com>
	<4A172398.9000100@sun.com>
	<1ccfd1c10905221757t30a7f610jd343084e50ec88bb@mail.gmail.com>
	<4A17B3BB.4090706@redhat.com>
	<1ccfd1c10905231112k61d8e13h31f693951ed91b76@mail.gmail.com>
	<4A1849CD.3060306@redhat.com>
	<1ccfd1c10905231810k17a99cd3vfa68d6108e28b46@mail.gmail.com>
	<4A191063.5060401@redhat.com>
	<1ccfd1c10905241809m10ded53bpb4c9360f76b36888@mail.gmail.com>
Message-ID: <4A1BCE2A.2010401@sun.com>

Martin Buchholz wrote:
> Below is a java program and a shell extract demonstrating the problem
> on a Ubuntu-hardy-like system.  The fork() fails from within a large
> Java process (but normal commands started from an
> independent shell continue to work fine).
>
> Linux overcommit heuristics are hard to understand.
>
> The failing fork problem becomes more serious on a server system
> running only one significant large program, which is using most of
> the memory on the system, perhaps by sysctl'ing
> the vm.overcommit_ratio to a value higher than the default 50%.
>
> On systems with two large processes using most of memory,
> you may see rare failures when both try to fork() at the same time..
>
I played around with your test and I see similar behaviour on my Ubuntu 
8.04 system.
When you switch on "always overcommit" (not the default) then you get 
the expected
behaviour, ie. you can go quite close to the VM limit, and manage to 
spawn a small command
from Java.

However, in the default "heuristic" mode, it doesn't work. The comment 
on the web page
you mentioned says:

"Heuristic overcommit handling. Obvious overcommits of
address space are refused. Used for a typical system. It
ensures a seriously wild allocation fails while allowing
overcommit to reduce swap usage:

Perhaps, this specifically does not suit the Java VM situation where 
fork() of a very
large process, is considered an "obvious overcommit".

In that context, I'll look into using the clone() system call on Linux. 
It seems
to be quite versatile and configurable. It looks likely that we can 
avoid the use
of the helper command with it as well.

- Michael.


From christos at zoulas.com  Tue May 26 12:57:43 2009
From: christos at zoulas.com (Christos Zoulas)
Date: Tue, 26 May 2009 08:57:43 -0400
Subject: Review request for 5049299
In-Reply-To: <4A1BCE2A.2010401@sun.com> from Michael McMahon (May 26, 12:10pm)
Message-ID: <20090526125743.60C605654E@rebar.astron.com>

On May 26, 12:10pm, Michael.McMahon at Sun.COM (Michael McMahon) wrote:
-- Subject: Re: Review request for 5049299

| I played around with your test and I see similar behaviour on my Ubuntu 
| 8.04 system.
| When you switch on "always overcommit" (not the default) then you get 
| the expected
| behaviour, ie. you can go quite close to the VM limit, and manage to 
| spawn a small command
| from Java.
| 
| However, in the default "heuristic" mode, it doesn't work. The comment 
| on the web page
| you mentioned says:
| 
| "Heuristic overcommit handling. Obvious overcommits of
| address space are refused. Used for a typical system. It
| ensures a seriously wild allocation fails while allowing
| overcommit to reduce swap usage:
| 
| Perhaps, this specifically does not suit the Java VM situation where 
| fork() of a very
| large process, is considered an "obvious overcommit".
| 
| In that context, I'll look into using the clone() system call on Linux. 
| It seems
| to be quite versatile and configurable. It looks likely that we can 
| avoid the use
| of the helper command with it as well.

Let's forget about the overcommit heuristics/settings alltogether.
We need a portable solution to the problem that works in all scenarios.
In addition the jvm maps memory on linux with MAP_NORESERVED which makes
the situation even more complicated. Yes, overcommit is useful
in a typical workstation setup, but not in a server environment where
deterministic behavior is desired. 

christos


From jean-christophe.collet at sun.com  Tue May 26 14:11:19 2009
From: jean-christophe.collet at sun.com (jean-christophe.collet at sun.com)
Date: Tue, 26 May 2009 14:11:19 +0000
Subject: hg: jdk7/tl/jdk: 6726695: HttpURLConnection shoul support 'Expect:
	100-contimue' headers for PUT
Message-ID: <20090526141139.919D2E9D6@hg.openjdk.java.net>

Changeset: 045aeb76b0ff
Author:    jccollet
Date:      2009-05-26 16:03 +0200
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/045aeb76b0ff

6726695: HttpURLConnection shoul support 'Expect: 100-contimue' headers for PUT
Summary: Added code triggered when 'Expect: 100-continue' header has been added
Reviewed-by: chegar

! src/share/classes/sun/net/www/http/HttpClient.java
! src/share/classes/sun/net/www/http/KeepAliveStreamCleaner.java
! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
+ test/sun/net/www/http/HttpClient/B6726695.java



From Michael.McMahon at Sun.COM  Tue May 26 14:20:08 2009
From: Michael.McMahon at Sun.COM (Michael McMahon)
Date: Tue, 26 May 2009 15:20:08 +0100
Subject: Review request for 5049299
In-Reply-To: <20090526125743.60C605654E@rebar.astron.com>
References: <20090526125743.60C605654E@rebar.astron.com>
Message-ID: <4A1BFA98.3000503@sun.com>

Christos Zoulas wrote:
> On May 26, 12:10pm, Michael.McMahon at Sun.COM (Michael McMahon) wrote:
> -- Subject: Re: Review request for 5049299
>
> | I played around with your test and I see similar behaviour on my Ubuntu 
> | 8.04 system.
> | When you switch on "always overcommit" (not the default) then you get 
> | the expected
> | behaviour, ie. you can go quite close to the VM limit, and manage to 
> | spawn a small command
> | from Java.
> | 
> | However, in the default "heuristic" mode, it doesn't work. The comment 
> | on the web page
> | you mentioned says:
> | 
> | "Heuristic overcommit handling. Obvious overcommits of
> | address space are refused. Used for a typical system. It
> | ensures a seriously wild allocation fails while allowing
> | overcommit to reduce swap usage:
> | 
> | Perhaps, this specifically does not suit the Java VM situation where 
> | fork() of a very
> | large process, is considered an "obvious overcommit".
> | 
> | In that context, I'll look into using the clone() system call on Linux. 
> | It seems
> | to be quite versatile and configurable. It looks likely that we can 
> | avoid the use
> | of the helper command with it as well.
>
> Let's forget about the overcommit heuristics/settings alltogether.
> We need a portable solution to the problem that works in all scenarios.
> In addition the jvm maps memory on linux with MAP_NORESERVED which makes
> the situation even more complicated. Yes, overcommit is useful
> in a typical workstation setup, but not in a server environment where
> deterministic behavior is desired. 
>
>   
Christos,

Can you elaborate on what you have in mind?

Michael.


From christos at zoulas.com  Tue May 26 16:23:47 2009
From: christos at zoulas.com (Christos Zoulas)
Date: Tue, 26 May 2009 12:23:47 -0400
Subject: Review request for 5049299
In-Reply-To: <4A1BFA98.3000503@sun.com> from Michael McMahon (May 26,  3:20pm)
Message-ID: <20090526162347.E41CC5654E@rebar.astron.com>

On May 26,  3:20pm, Michael.McMahon at Sun.COM (Michael McMahon) wrote:
-- Subject: Re: Review request for 5049299

| Christos Zoulas wrote:
| > Let's forget about the overcommit heuristics/settings alltogether.
| > We need a portable solution to the problem that works in all scenarios.
| > In addition the jvm maps memory on linux with MAP_NORESERVED which makes
| > the situation even more complicated. Yes, overcommit is useful
| > in a typical workstation setup, but not in a server environment where
| > deterministic behavior is desired. 
| >
| >   
| Christos,
| 
| Can you elaborate on what you have in mind?
| 

I don't have a good solution. The only option I see to to use
vfork(2) on systems that have it (*), and emulate it by suspending
the parent manually on systems that don't in order to achieve the
same process scheduling semantics. This of course takes away all
the vfork() benefits (speed/efficiency, avoiding the memory exhaustion
issues).

This is not a good solution because the vfork() semantics vary
across different OS's (specially with respect to signal handling)
and we probably need to come up with a simple test program to see
if the particular vfork() implementation is suitable, or we have
to fail back to using fork.

If there is a consensus to use vfork():
What is not clear to me is if java needs a special execute entry
point that uses the fake or real vfork() (with the parent suspension
semantics), or an implementation can just choose to implement
execute using vfork() at it own digression.

christos

(*) On linux - for some earlier vintages that did not have a vfork()
syscall - it is equivalent to calling clone(2) with flags
CLONE_VFORK|CLONE_VM|SIGCHLD.


From Michael.McMahon at Sun.COM  Tue May 26 16:39:22 2009
From: Michael.McMahon at Sun.COM (Michael McMahon)
Date: Tue, 26 May 2009 17:39:22 +0100
Subject: Review request for 5049299
In-Reply-To: <20090526162347.E41CC5654E@rebar.astron.com>
References: <20090526162347.E41CC5654E@rebar.astron.com>
Message-ID: <4A1C1B3A.9080801@sun.com>

Christos Zoulas wrote:
> On May 26,  3:20pm, Michael.McMahon at Sun.COM (Michael McMahon) wrote:
> -- Subject: Re: Review request for 5049299
>
> | Christos Zoulas wrote:
> | > Let's forget about the overcommit heuristics/settings alltogether.
> | > We need a portable solution to the problem that works in all scenarios.
> | > In addition the jvm maps memory on linux with MAP_NORESERVED which makes
> | > the situation even more complicated. Yes, overcommit is useful
> | > in a typical workstation setup, but not in a server environment where
> | > deterministic behavior is desired. 
> | >
> | >   
> | Christos,
> | 
> | Can you elaborate on what you have in mind?
> | 
>
> I don't have a good solution. The only option I see to to use
> vfork(2) on systems that have it (*), and emulate it by suspending
> the parent manually on systems that don't in order to achieve the
> same process scheduling semantics. This of course takes away all
> the vfork() benefits (speed/efficiency, avoiding the memory exhaustion
> issues).
>
>   
Unfortunately, vfork() on Solaris, won't do what we want to do.
vfork() cannot be used in multi-threaded apps, on Solaris.

So, I think we are stuck with different solutions for Solaris and Linux.
While it's not an ideal situation, at least it means we can still
have consistent behaviour across both operating systems.

- Michael


From xuelei.fan at sun.com  Wed May 27 09:58:27 2009
From: xuelei.fan at sun.com (xuelei.fan at sun.com)
Date: Wed, 27 May 2009 09:58:27 +0000
Subject: hg: jdk7/tl/jdk: 6845286: Add regression test for name constraints
Message-ID: <20090527095903.10BC4EAA6@hg.openjdk.java.net>

Changeset: 25db260cb810
Author:    xuelei
Date:      2009-05-27 17:48 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/25db260cb810

6845286: Add regression test for name constraints
Summary: create regression test cases on name constraints
Reviewed-by: weijun

+ test/java/security/cert/CertPathValidator/nameConstraints/NameConstraintsWithRID.java
+ test/java/security/cert/CertPathValidator/nameConstraints/NameConstraintsWithUnexpectedRID.java
+ test/java/security/cert/CertPathValidator/nameConstraints/NameConstraintsWithoutRID.java
+ test/java/security/cert/CertPathValidator/nameConstraints/generate.sh
+ test/java/security/cert/CertPathValidator/nameConstraints/openssl.cnf



From Dalibor.Topic at Sun.COM  Wed May 27 17:17:14 2009
From: Dalibor.Topic at Sun.COM (Dalibor Topic)
Date: Wed, 27 May 2009 10:17:14 -0700
Subject: OpenJDK Forum: Core Libraries Round Table
Message-ID: <4A1D759A.5020504@sun.com>

Hi core libraries developers,

I met Alan Bateman last evening, and we thought that we
should have another OpenJDK Core Libraries Forum this week, 
so (drumroll) it's time again on Friday, for the

	OpenJDK Forum

Date/Time: Friday May 29th, 8 AM Pacific, 1600 GMT, 5 PM Germany

Subject: Core libraries round table

Call Host: Dalibor Topic

Expected Participants: 

	* members of discuss at openjdk and core-libs-dev at openjdk 
	mailing lists interested in hearing what everyone
        else is working on in the core libraries area.

Synopsis:

The agenda would be just go around the table and get everyone 
to speak on what they are working on in the core libraries 
area in OpenJDK in light of the finished M3 and the upcoming 
M4, and the JavaOne conference just around the corner next week.

We will then switch to open discussion mode to hear people's 
questions, concerns, and suggestions on the subject matter.

The call will be recorded, and the recording will be made 
available after the call - in a free format, of course!

Dial in numbers: 

Passcode: 5817876

Speed dial extension for developers inside Sun:	x44414

Country                              Toll Numbers          Freephone/Toll Free Number

ARGENTINA                                                   0800-777-0463 
AUSTRALIA           ADELAIDE:      61-8-8121-4868           1-800-249-288 
AUSTRALIA           BRISBANE:      61-7-3102-0970           1-800-249-288 
AUSTRALIA           CANBERRA:      61-2-6100-1970           1-800-249-288 
AUSTRALIA           MELBOURNE:     61-3-9010-7739           1-800-249-288 
AUSTRALIA           PERTH:         61-8-9467-5249           1-800-249-288 
AUSTRALIA           SYDNEY:        61-2-8205-8125           1-800-249-288 
AUSTRIA                            43-1-92-86-506           0800-005-029 
BELGIUM                            32-1-150-0314            0800-4-8680 
BRAZIL                                                      0800-7610674 
CHILE                                                       1230-020-2867 
CHINA*                             86-400-810-4766          10800-712-1433 
                                                            10800-120-1433 
COLOMBIA                                                    01800-9-156430 
CZECH REPUBLIC                     420-2-25-98-56-54        800-700-173 
DENMARK                            45-7014-0280             8088-6132 
ESTONIA                                                     800-011-1089 
FINLAND             Land Line:     106-33-146               0-800-1-10100 
FINLAND             Mobile:        09-106-33-146            0-800-1-10100 
FRANCE              LYON:          33-4-26-69-12-81         080-563-9647 
FRANCE              MARSEILLE:     33-4-86-06-00-81         080-563-9647 
FRANCE              PARIS:         33-1-70-70-74-20         080-563-9647 
GERMANY                            49-69-2222-2566          0800-000-3441 
GREECE                             30-80-1-100-0683         00800-12-6973 
HONG KONG                          852-2286-5731            800-930-705 
HUNGARY                                                     06-800-18013 
INDIA                                                       000-800-852-1266 
INDONESIA                                                   001-803-011-3787 
IRELAND                            353-1-247-5253           1800-932-145 
ISRAEL                                                      1-80-9214916 
ITALY                              39-02-3600-3642          800-986-570 
JAPAN               OSAKA:         81-6-7739-4769           0034-800-400828 
JAPAN               TOKYO:         81-3-5539-5189           0034-800-400828 
LATVIA                                                      8000-3025 
LUXEMBOURG                         352-27-000-1360           
MALAYSIA                                                    1-800-80-2812 
MEXICO                                                      001-866-627-0574 
NETHERLANDS                        31-20-718-8533           0800-020-1392 
NEW ZEALAND                        64-9-970-4769            0800-449-823 
NORWAY                             47-21-59-00-59           800-15414 
PANAMA                                                      011-001-800-5072129 
PERU                                                        0800-53733 
PHILIPPINES                        63-2-858-3715             
POLAND                                                      00-800-1212021 
PORTUGAL                                                    8008-14061 
RUSSIA                                                      8-10-8002-9683011 
SINGAPORE                          65-6883-9228             800-120-4662 
SLOVAK REPUBLIC                    421-2-322-422-21          
SOUTH AFRICA                                                080-09-80416 
SOUTH KOREA                        82-2-6744-1081           00798-14800-6860 
SPAIN                              34-91-414-62-98          800-099-810 
SWEDEN                             46-8-505-78-524          0200-890-106 
SWITZERLAND                        41-44-580-4389           0800-001-523 
TAIWAN                             886-2-2795-7377          00801-137-766 
THAILAND                                                    001-800-1206-65656 
UNITED KINGDOM      BIRMINGHAM:    44-121-210-9021          0808-238-6025 
UNITED KINGDOM      GLASGOW:       44-141-202-3221          0808-238-6025 
UNITED KINGDOM      LEEDS:         44-113-301-2121          0808-238-6025 
UNITED KINGDOM      LONDON:        44-20-7075-3246          0808-238-6025 
UNITED KINGDOM      MANCHESTER:    44-161-601-1421          0808-238-6025 
URUGUAY                                                     000-413-598-3415 
USA                                1-203-418-3122           866-692-3163 
VENEZUELA                                                   0800-1-00-3733  


cheers,
dalibor topic
-- 
*******************************************************************
Dalibor Topic                   Tel: (+49 40) 23 646 738
Java F/OSS Ambassador           AIM: robiladonaim
Sun Microsystems GmbH           Mobile: (+49 177) 2664 192
Nagelsweg 55                    http://openjdk.java.net
D-20097 Hamburg                 mailto:Dalibor.Topic at sun.com
Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht M?nchen: HRB 161028
Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin H?ring




From mandy.chung at sun.com  Wed May 27 22:24:09 2009
From: mandy.chung at sun.com (mandy.chung at sun.com)
Date: Wed, 27 May 2009 22:24:09 +0000
Subject: hg: jdk7/tl/jdk: 6 new changesets
Message-ID: <20090527222803.186F4EB25@hg.openjdk.java.net>

Changeset: 7772d77bd7c2
Author:    mchung
Date:      2009-05-26 17:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7772d77bd7c2

6829636: test/java/util/logging/LoggingDeadlock2.java is flaky
Summary: remove @ignore
Reviewed-by: swamyv

! src/share/classes/java/net/URLConnection.java
! test/Makefile
! test/java/util/logging/LoggingDeadlock2.java

Changeset: 2aeaffb6c897
Author:    mchung
Date:      2009-05-26 17:54 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2aeaffb6c897

6798842: TEST_BUG: ThreadStackTrace.java fails intermittently with unexpected thread status.
Summary: remove @ignore
Reviewed-by: swamyv

! test/java/lang/management/ThreadMXBean/ThreadStackTrace.java
+ test/java/lang/management/ThreadMXBean/Utils.java

Changeset: fba2425da9b1
Author:    mchung
Date:      2009-05-26 18:02 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fba2425da9b1

5080203: TEST_BUG: ThreadStateTest fails intermittently.
Summary: Retry a few times to check thread status before reporting failure
Reviewed-by: swamyv

! test/java/lang/management/ThreadMXBean/ThreadStateTest.java

Changeset: a7a38e606a7a
Author:    mchung
Date:      2009-05-26 18:07 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a7a38e606a7a

6512493: TEST_BUG: unexpected LockInfo failure in LockedSynchronizers.java
Summary: Retry a few times to check thread status before reporting failure
Reviewed-by: swamyv

! test/java/lang/management/ThreadMXBean/LockingThread.java
! test/java/lang/management/ThreadMXBean/MonitorDeadlock.java

Changeset: fb97068670e6
Author:    mchung
Date:      2009-05-26 18:09 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fb97068670e6

6535104: TEST_BUG: FindDeadlocks.java fails intermittently.
Summary: Retry a few times to check thread status before reporting failure
Reviewed-by: swamyv

! test/java/lang/management/ThreadMXBean/SynchronizerDeadlock.java
! test/java/lang/management/ThreadMXBean/SynchronizerLockingThread.java

Changeset: 742b55c45a70
Author:    mchung
Date:      2009-05-27 13:02 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/742b55c45a70

Merge




From keith.mcguigan at sun.com  Wed May 27 23:54:05 2009
From: keith.mcguigan at sun.com (keith.mcguigan at sun.com)
Date: Wed, 27 May 2009 23:54:05 +0000
Subject: hg: jdk7/tl/jdk: 2 new changesets
Message-ID: <20090527235533.995A8EB2E@hg.openjdk.java.net>

Changeset: 59bbb9f3f430
Author:    kamg
Date:      2009-05-27 13:20 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/59bbb9f3f430

6838211: jdk docs creation broken for tracing docs
Summary: Fix javadoc makefile macro
Reviewed-by: ohair, jjg

! make/docs/Makefile

Changeset: 8e77f61508cc
Author:    kamg
Date:      2009-05-27 15:32 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8e77f61508cc

Merge




From mr at sun.com  Thu May 28 03:52:05 2009
From: mr at sun.com (Mark Reinhold)
Date: Wed, 27 May 2009 20:52:05 -0700
Subject: Review request for 5049299 
In-Reply-To: michael.mcmahon@sun.com; Fri, 22 May 2009 23:13:44 BST;
	<4A172398.9000100@sun.com> 
Message-ID: <20090528035205.C1EF594A8@callebaut.niobe.net>

> Date: Fri, 22 May 2009 23:13:44 +0100
> From: michael.mcmahon at sun.com

> ...
> 
> 2. Support for older Solaris releases. My understanding was that jdk7
> doesn't need to support older releases of Solaris (than S10). Can
> someone clarify that situation?

Yes.

We (i.e., Sun) will support JDK 7 only on Solaris releases from S10u2
forward, and we'll recommend that customers run S10u4 or later if at
all possible.

(We'll update the project pages with more complete supported-platform
 information ... after JavaOne.)

- Mark


From joe.darcy at sun.com  Thu May 28 05:43:31 2009
From: joe.darcy at sun.com (joe.darcy at sun.com)
Date: Thu, 28 May 2009 05:43:31 +0000
Subject: hg: jdk7/tl/langtools: 6843761: Update langtools tests to remove
	unncessary -source and -target options
Message-ID: <20090528054336.73520EB3E@hg.openjdk.java.net>

Changeset: 84061bd68019
Author:    darcy
Date:      2009-05-27 22:34 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/84061bd68019

6843761: Update langtools tests to remove unncessary -source and -target options
Reviewed-by: jjg

! test/com/sun/javadoc/testIndex/TestIndex.java
! test/com/sun/javadoc/testInterface/TestInterface.java
! test/com/sun/javadoc/testNavagation/TestNavagation.java
! test/com/sun/javadoc/testTagInheritence/TestTagInheritence.java
! test/tools/javac/5005368.java
! test/tools/javac/Ambig3.java
! test/tools/javac/ArrayCast.java
! test/tools/javac/BadCovar.java
! test/tools/javac/ClassLiterals/InitializeOuter.java
! test/tools/javac/ClassLiterals/InitializeTarget.java
! test/tools/javac/ClassToTypeParm.java
! test/tools/javac/Closure1.java
! test/tools/javac/Closure2.java
! test/tools/javac/Closure3.java
! test/tools/javac/Closure4.java
! test/tools/javac/Closure5.java
! test/tools/javac/CompoundBox.java
! test/tools/javac/ConditionalArgTypes_1.java
! test/tools/javac/ConditionalArgTypes_2.java
! test/tools/javac/DefiniteAssignment/DUAssert.java
! test/tools/javac/EarlyAssert.java
! test/tools/javac/Enum1.java
! test/tools/javac/GoodCovar.java
! test/tools/javac/HexFloatLiterals.java
! test/tools/javac/HexThree.java
! test/tools/javac/InterfaceAssert.java
! test/tools/javac/InvalidIntfCast.java
! test/tools/javac/NewGeneric.java
! test/tools/javac/ObjectMethodRefFromInterface.java
! test/tools/javac/PrivateLocalConstructor.java
! test/tools/javac/RawCrash.java
! test/tools/javac/SynthName2.java
! test/tools/javac/T5090006/compiler.sh
! test/tools/javac/T5092545.java
! test/tools/javac/T5105890.java
! test/tools/javac/annotations/default/A.java
! test/tools/javac/annotations/neg/AnnComma.java
! test/tools/javac/annotations/neg/ArrayLit.java
! test/tools/javac/annotations/neg/Constant.java
! test/tools/javac/annotations/neg/Cycle1.java
! test/tools/javac/annotations/neg/Cycle2.java
! test/tools/javac/annotations/neg/Cycle3.java
! test/tools/javac/annotations/neg/Dep.java
! test/tools/javac/annotations/neg/Dup.java
! test/tools/javac/annotations/neg/DupTarget.java
! test/tools/javac/annotations/neg/MemberOver.java
! test/tools/javac/annotations/neg/ObjectMembers.java
! test/tools/javac/annotations/neg/OverrideNo.java
! test/tools/javac/annotations/neg/Package.java
! test/tools/javac/annotations/neg/Recovery.java
! test/tools/javac/annotations/neg/Recovery1.java
! test/tools/javac/annotations/neg/Scope.java
! test/tools/javac/annotations/neg/Syntax1.java
! test/tools/javac/annotations/neg/WrongTarget.java
! test/tools/javac/annotations/neg/WrongTarget2.java
! test/tools/javac/annotations/neg/WrongValue.java
! test/tools/javac/annotations/neg/Z1.java
! test/tools/javac/annotations/neg/Z10.java
! test/tools/javac/annotations/neg/Z11.java
! test/tools/javac/annotations/neg/Z12.java
! test/tools/javac/annotations/neg/Z13.java
! test/tools/javac/annotations/neg/Z14.java
! test/tools/javac/annotations/neg/Z15.java
! test/tools/javac/annotations/neg/Z16.java
! test/tools/javac/annotations/neg/Z2.java
! test/tools/javac/annotations/neg/Z3.java
! test/tools/javac/annotations/neg/Z4.java
! test/tools/javac/annotations/neg/Z5.java
! test/tools/javac/annotations/neg/Z8.java
! test/tools/javac/annotations/neg/Z9.java
! test/tools/javac/annotations/pos/AnnoteElideBraces.java
! test/tools/javac/annotations/pos/ClassA.java
! test/tools/javac/annotations/pos/Dep.java
! test/tools/javac/annotations/pos/Enum1.java
! test/tools/javac/annotations/pos/Local.java
! test/tools/javac/annotations/pos/Members.java
! test/tools/javac/annotations/pos/NType.java
! test/tools/javac/annotations/pos/OverrideCheck.java
! test/tools/javac/annotations/pos/OverrideOK.java
! test/tools/javac/annotations/pos/Parameter.java
! test/tools/javac/annotations/pos/Primitives.java
! test/tools/javac/annotations/pos/RightTarget.java
! test/tools/javac/annotations/pos/Z1.java
! test/tools/javac/annotations/pos/Z2.java
! test/tools/javac/annotations/pos/Z3.java
! test/tools/javac/annotations/pos/Z4.java
! test/tools/javac/annotations/pos/package-info.java
! test/tools/javac/assert/Attach.java
! test/tools/javac/assert/DU1.java
! test/tools/javac/assert/DU2.java
! test/tools/javac/assert/Position.java
! test/tools/javac/boxing/BoxedForeach.java
! test/tools/javac/boxing/Boxing1.java
! test/tools/javac/boxing/Boxing2.java
! test/tools/javac/boxing/Boxing4.java
! test/tools/javac/boxing/BoxingCaching.java
! test/tools/javac/capture/Capture1.java
! test/tools/javac/capture/Capture2.java
! test/tools/javac/capture/Capture3.java
! test/tools/javac/capture/Capture5.java
! test/tools/javac/cast/BoxedArray.java
! test/tools/javac/enum/AbstractEmptyEnum.java
! test/tools/javac/enum/AbstractEnum1.java
! test/tools/javac/enum/DA1.java
! test/tools/javac/enum/DA2.java
! test/tools/javac/enum/DA3.java
! test/tools/javac/enum/Def.java
! test/tools/javac/enum/Enum1.java
! test/tools/javac/enum/Enum2.java
! test/tools/javac/enum/Enum3.java
! test/tools/javac/enum/EnumImplicitPrivateConstructor.java
! test/tools/javac/enum/EnumInit.java
! test/tools/javac/enum/EnumPrivateConstructor.java
! test/tools/javac/enum/EnumProtectedConstructor.java
! test/tools/javac/enum/EnumPublicConstructor.java
! test/tools/javac/enum/EnumSwitch1.java
! test/tools/javac/enum/EnumSwitch2.java
! test/tools/javac/enum/EnumSwitch3.java
! test/tools/javac/enum/EnumSwitch4.java
! test/tools/javac/enum/ExplicitlyAbstractEnum1.java
! test/tools/javac/enum/ExplicitlyAbstractEnum2.java
! test/tools/javac/enum/ExplicitlyFinalEnum1.java
! test/tools/javac/enum/ExplicitlyFinalEnum2.java
! test/tools/javac/enum/FauxEnum1.java
! test/tools/javac/enum/FauxEnum3.java
! test/tools/javac/enum/FauxSpecialEnum1.java
! test/tools/javac/enum/FauxSpecialEnum2.java
! test/tools/javac/enum/LocalEnum.java
! test/tools/javac/enum/NoFinal.java
! test/tools/javac/enum/NoFinal2.java
! test/tools/javac/enum/NoFinal3.java
! test/tools/javac/enum/NoFinal4.java
! test/tools/javac/enum/NoFinal5.java
! test/tools/javac/enum/OkFinal.java
! test/tools/javac/enum/SynthValues.java
! test/tools/javac/enum/T5075242.java
! test/tools/javac/enum/T5081785.java
! test/tools/javac/enum/TrailingComma.java
! test/tools/javac/enum/UserValue.java
! test/tools/javac/enum/ValueOf.java
! test/tools/javac/enum/enumSwitch/EnumSwitch.java
! test/tools/javac/foreach/Foreach.java
! test/tools/javac/foreach/GenericIterator.java
! test/tools/javac/foreach/IntersectIterator.java
! test/tools/javac/foreach/ListOfListTest.java
! test/tools/javac/foreach/SpecIterable.java
! test/tools/javac/foreach/StaticBlock.java
! test/tools/javac/foreach/SuperfluousAbstract.java
! test/tools/javac/generics/ArrayClone.java
! test/tools/javac/generics/ArrayTypearg.java
! test/tools/javac/generics/BridgeClash.java
! test/tools/javac/generics/BridgeOrder.java
! test/tools/javac/generics/CastCrash.java
! test/tools/javac/generics/Casting.java
! test/tools/javac/generics/Casting2.java
! test/tools/javac/generics/Casting3.java
! test/tools/javac/generics/Casting4.java
! test/tools/javac/generics/Conditional.java
! test/tools/javac/generics/Covar2.java
! test/tools/javac/generics/Covar3.java
! test/tools/javac/generics/Covar4.java
! test/tools/javac/generics/Crash01.java
! test/tools/javac/generics/Crash02.java
! test/tools/javac/generics/CyclicInheritance3.java
! test/tools/javac/generics/CyclicInheritance5.java
! test/tools/javac/generics/ErasureClashCrash.java
! test/tools/javac/generics/ExtendedRaw1.java
! test/tools/javac/generics/ExtendedRaw2.java
! test/tools/javac/generics/ExtendedRaw3.java
! test/tools/javac/generics/ExtendedRaw4.java
! test/tools/javac/generics/FinalBridge.java
! test/tools/javac/generics/GenLit1.java
! test/tools/javac/generics/GenLit2.java
! test/tools/javac/generics/GenericAnonCtor.java
! test/tools/javac/generics/GenericMerge.java
! test/tools/javac/generics/GenericOverride.java
! test/tools/javac/generics/GenericThrowable.java
! test/tools/javac/generics/GetClass.java
! test/tools/javac/generics/GetClass2.java
! test/tools/javac/generics/InheritanceConflict.java
! test/tools/javac/generics/InheritanceConflict2.java
! test/tools/javac/generics/InheritanceConflict3.java
! test/tools/javac/generics/InnerInterface1.java
! test/tools/javac/generics/InnerInterface2.java
! test/tools/javac/generics/InstanceOf1.java
! test/tools/javac/generics/InstanceOf2.java
! test/tools/javac/generics/InstanceOf3.java
! test/tools/javac/generics/InterfaceCast1.java
! test/tools/javac/generics/LoadOrder.java
! test/tools/javac/generics/MissingBridge.java
! test/tools/javac/generics/MissingCast.java
! test/tools/javac/generics/Multibound1.java
! test/tools/javac/generics/MultipleInheritance.java
! test/tools/javac/generics/NameOrder.java
! test/tools/javac/generics/Nonlinear.java
! test/tools/javac/generics/ParametricException.java
! test/tools/javac/generics/ParenVerify.java
! test/tools/javac/generics/PermuteBound.java
! test/tools/javac/generics/PrimitiveClass.java
! test/tools/javac/generics/PrimitiveVariant.java
! test/tools/javac/generics/RawClient.java
! test/tools/javac/generics/RefEqual.java
! test/tools/javac/generics/RelaxedArrays.java
! test/tools/javac/generics/ReverseOrder.java
! test/tools/javac/generics/SelfImplement.java
! test/tools/javac/generics/SilentUnchecked.java
! test/tools/javac/generics/SuperTypeargs.java
! test/tools/javac/generics/T4661029.java
! test/tools/javac/generics/T4683314.java
! test/tools/javac/generics/T4684378.java
! test/tools/javac/generics/T4695348.java
! test/tools/javac/generics/T4695415.java
! test/tools/javac/generics/T4695847.java
! test/tools/javac/generics/T4711570.java
! test/tools/javac/generics/T4711572.java
! test/tools/javac/generics/T4711694.java
! test/tools/javac/generics/T4738171.java
! test/tools/javac/generics/T4739399.java
! test/tools/javac/generics/T4757416.java
! test/tools/javac/generics/T4784207a.java
! test/tools/javac/generics/T4784219.java
! test/tools/javac/generics/T5011073.java
! test/tools/javac/generics/T5094318.java
! test/tools/javac/generics/TyparamLit.java
! test/tools/javac/generics/TyparamStaticScope.java
! test/tools/javac/generics/TyparamStaticScope2.java
! test/tools/javac/generics/UncheckedArray.java
! test/tools/javac/generics/UncheckedConstructor.java
! test/tools/javac/generics/UncheckedCovariance.java
! test/tools/javac/generics/UnsoundInference.java
! test/tools/javac/generics/Varargs.java
! test/tools/javac/generics/Varargs2.java
! test/tools/javac/generics/WrongNew.java
! test/tools/javac/generics/abstract/T4717181c.java
! test/tools/javac/generics/bridge1/D.java
! test/tools/javac/generics/classreader/HArrayMethod.java
! test/tools/javac/generics/compat/CovariantCompat1.java
! test/tools/javac/generics/compat/OverrideBridge1.java
! test/tools/javac/generics/forwardSeparateBound/ForwardSeparateBound2.java
! test/tools/javac/generics/genericAbstract/A.java
! test/tools/javac/generics/odersky/BadTest.java
! test/tools/javac/generics/odersky/BadTest2.java
! test/tools/javac/generics/odersky/BadTest3.java
! test/tools/javac/generics/odersky/BadTest4.java
! test/tools/javac/generics/odersky/Test.java
! test/tools/javac/generics/odersky/Test2.java
! test/tools/javac/generics/odersky/Test3.java
! test/tools/javac/generics/odersky/Test4.java
! test/tools/javac/generics/parametricException/J.java
! test/tools/javac/generics/rare/Rare1.java
! test/tools/javac/generics/rare/Rare10.java
! test/tools/javac/generics/rare/Rare11.java
! test/tools/javac/generics/rare/Rare2.java
! test/tools/javac/generics/rare/Rare3.java
! test/tools/javac/generics/rare/Rare4.java
! test/tools/javac/generics/rare/Rare5.java
! test/tools/javac/generics/rare/Rare6.java
! test/tools/javac/generics/rare/Rare7.java
! test/tools/javac/generics/rare/Rare8.java
! test/tools/javac/generics/rare/Rare9.java
! test/tools/javac/generics/rawSeparate/RetroLexer.java
! test/tools/javac/generics/typeargs/Basic.java
! test/tools/javac/generics/typeargs/Metharg1.java
! test/tools/javac/generics/typeargs/Metharg2.java
! test/tools/javac/generics/typeargs/Newarg1.java
! test/tools/javac/generics/typeargs/Newarg2.java
! test/tools/javac/generics/typeargs/Superarg1.java
! test/tools/javac/generics/typeargs/Superarg2.java
! test/tools/javac/generics/typeargs/ThisArg.java
! test/tools/javac/generics/typevars/4856983/T4856983.java
! test/tools/javac/generics/typevars/4856983/T4856983a.java
! test/tools/javac/generics/typevars/4856983/T4856983b.java
! test/tools/javac/generics/wildcards/AssignmentDifferentTypes1.java
! test/tools/javac/generics/wildcards/AssignmentDifferentTypes2.java
! test/tools/javac/generics/wildcards/AssignmentDifferentTypes3.java
! test/tools/javac/generics/wildcards/AssignmentDifferentTypes4.java
! test/tools/javac/generics/wildcards/AssignmentDifferentTypes5.java
! test/tools/javac/generics/wildcards/AssignmentDifferentTypes6.java
! test/tools/javac/generics/wildcards/AssignmentDifferentTypes7.java
! test/tools/javac/generics/wildcards/AssignmentDifferentTypes8.java
! test/tools/javac/generics/wildcards/AssignmentDifferentTypes9.java
! test/tools/javac/generics/wildcards/AssignmentSameType1.java
! test/tools/javac/generics/wildcards/AssignmentSameType2.java
! test/tools/javac/generics/wildcards/AssignmentSameType3.java
! test/tools/javac/generics/wildcards/AssignmentSameType4.java
! test/tools/javac/generics/wildcards/AssignmentSameType5.java
! test/tools/javac/generics/wildcards/AssignmentSameType6.java
! test/tools/javac/generics/wildcards/AssignmentSameType7.java
! test/tools/javac/generics/wildcards/AssignmentSameType8.java
! test/tools/javac/generics/wildcards/BoundBug.java
! test/tools/javac/generics/wildcards/ContraArg.java
! test/tools/javac/generics/wildcards/T5097548.java
! test/tools/javac/generics/wildcards/T5097548b.java
! test/tools/javac/generics/wildcards/UnboundArray.java
! test/tools/javac/generics/wildcards/neg/AmbiguousCast.java
! test/tools/javac/generics/wildcards/neg/Capture.java
! test/tools/javac/generics/wildcards/neg/CastFail1.java
! test/tools/javac/generics/wildcards/neg/CastFail10.java
! test/tools/javac/generics/wildcards/neg/CastFail11.java
! test/tools/javac/generics/wildcards/neg/CastFail12.java
! test/tools/javac/generics/wildcards/neg/CastFail13.java
! test/tools/javac/generics/wildcards/neg/CastFail14.java
! test/tools/javac/generics/wildcards/neg/CastFail15.java
! test/tools/javac/generics/wildcards/neg/CastFail16.java
! test/tools/javac/generics/wildcards/neg/CastFail17.java
! test/tools/javac/generics/wildcards/neg/CastFail18.java
! test/tools/javac/generics/wildcards/neg/CastFail19.java
! test/tools/javac/generics/wildcards/neg/CastFail2.java
! test/tools/javac/generics/wildcards/neg/CastFail20.java
! test/tools/javac/generics/wildcards/neg/CastFail21.java
! test/tools/javac/generics/wildcards/neg/CastFail3.java
! test/tools/javac/generics/wildcards/neg/CastFail4.java
! test/tools/javac/generics/wildcards/neg/CastFail5.java
! test/tools/javac/generics/wildcards/neg/CastFail6.java
! test/tools/javac/generics/wildcards/neg/CastFail7.java
! test/tools/javac/generics/wildcards/neg/CastFail8.java
! test/tools/javac/generics/wildcards/neg/CastFail9.java
! test/tools/javac/generics/wildcards/neg/CastWarn10.java
! test/tools/javac/generics/wildcards/neg/CastWarn11.java
! test/tools/javac/generics/wildcards/neg/CastWarn12.java
! test/tools/javac/generics/wildcards/neg/CastWarn13.java
! test/tools/javac/generics/wildcards/neg/CastWarn14.java
! test/tools/javac/generics/wildcards/neg/CastWarn2.java
! test/tools/javac/generics/wildcards/neg/CastWarn3.java
! test/tools/javac/generics/wildcards/neg/CastWarn4.java
! test/tools/javac/generics/wildcards/neg/CastWarn5.java
! test/tools/javac/generics/wildcards/neg/CastWarn6.java
! test/tools/javac/generics/wildcards/neg/CastWarn7.java
! test/tools/javac/generics/wildcards/neg/CastWarn8.java
! test/tools/javac/generics/wildcards/neg/CastWarn9.java
! test/tools/javac/generics/wildcards/neg/ParamCast.java
! test/tools/javac/generics/wildcards/neg/Readonly.java
! test/tools/javac/generics/wildcards/neg/Unbounded.java
! test/tools/javac/generics/wildcards/pos/AmbiguousCast2.java
! test/tools/javac/generics/wildcards/pos/BoundsCollision.java
! test/tools/javac/generics/wildcards/pos/Capture.java
! test/tools/javac/generics/wildcards/pos/CastTest.java
! test/tools/javac/generics/wildcards/pos/InstanceOf.java
! test/tools/javac/generics/wildcards/pos/ParamCast.java
! test/tools/javac/generics/wildcards/pos/RvalConversion.java
! test/tools/javac/generics/wildcards/pos/UncheckedCast1.java
! test/tools/javac/importscope/A.java
! test/tools/javac/limits/FinallyNesting.java
! test/tools/javac/lint/Unchecked.java
! test/tools/javac/miranda/T4711325.java
! test/tools/javac/mixedTarget/CompatibleAbstracts1.java
! test/tools/javac/mixedTarget/ExtendCovariant2.java
! test/tools/javac/overload/T5090220.java
! test/tools/javac/processing/environment/TestSourceVersion.java
! test/tools/javac/stackmap/UninitThis.java
! test/tools/javac/staticImport/Ambig1.java
! test/tools/javac/staticImport/ImportInherit.java
! test/tools/javac/staticImport/ImportPrivate.java
! test/tools/javac/staticImport/PrivateStaticImport.java
! test/tools/javac/staticImport/Shadow.java
! test/tools/javac/staticImport/StaticImport.java
! test/tools/javac/staticImport/StaticImport2.java
! test/tools/javac/unicode/Unmappable.java
! test/tools/javac/varargs/Anon.java
! test/tools/javac/varargs/BadSyntax2.java
! test/tools/javac/varargs/Varargs1.java
! test/tools/javac/varargs/VarargsOverride.java
! test/tools/javac/varargs/Warn1.java
! test/tools/javac/varargs/Warn2.java
! test/tools/javac/varargs/warning/Warn2.java
! test/tools/javac/varargs/warning/Warn3.java
! test/tools/javadoc/LangVers.java
! test/tools/javadoc/annotations/annotateMethodsFields/Main.java
! test/tools/javadoc/annotations/annotatePackage/Main.java
! test/tools/javadoc/annotations/annotateParams/Main.java
! test/tools/javadoc/annotations/defaults/Main.java
! test/tools/javadoc/annotations/elementTypes/Main.java
! test/tools/javadoc/annotations/shortcuts/Main.java
! test/tools/javadoc/enum/docComments/Main.java
! test/tools/javadoc/enum/enumType/Main.java
! test/tools/javadoc/generics/genericClass/Main.java
! test/tools/javadoc/generics/genericInnerAndOuter/Main.java
! test/tools/javadoc/generics/genericInterface/Main.java
! test/tools/javadoc/generics/genericMethod/Main.java
! test/tools/javadoc/generics/genericSuper/Main.java
! test/tools/javadoc/generics/supertypes/Main.java
! test/tools/javadoc/generics/throwsGeneric/Main.java
! test/tools/javadoc/generics/tparamCycle/Main.java
! test/tools/javadoc/generics/tparamTagOnMethod/Main.java
! test/tools/javadoc/generics/tparamTagOnType/Main.java
! test/tools/javadoc/generics/wildcards/Main.java
! test/tools/javadoc/lib/Tester.java
! test/tools/javadoc/varArgs/Main.java



From gbenson at redhat.com  Thu May 28 08:34:11 2009
From: gbenson at redhat.com (Gary Benson)
Date: Thu, 28 May 2009 09:34:11 +0100
Subject: OpenJDK Forum: Core Libraries Round Table
In-Reply-To: <4A1D759A.5020504@sun.com>
References: <4A1D759A.5020504@sun.com>
Message-ID: <20090528083410.GA3215@redhat.com>

Dalibor Topic wrote:
> Date/Time: Friday May 29th, 8 AM Pacific, 1600 GMT, 5 PM Germany

Is that 1600 GMT or 1600 BST (ie 1500 GMT)?

Cheers,
Gary

-- 
http://gbenson.net/


From fweimer at bfk.de  Thu May 28 08:56:09 2009
From: fweimer at bfk.de (Florian Weimer)
Date: Thu, 28 May 2009 10:56:09 +0200
Subject: Review request for 5049299
In-Reply-To: <4A1678DB.9010209@sun.com> (Michael McMahon's message of "Fri\,
	22 May 2009 11\:05\:15 +0100")
References: <4A1678DB.9010209@sun.com>
Message-ID: <82iqjlli6u.fsf@mid.bfk.de>

* Michael McMahon:

> webrev location: http://cr.openjdk.java.net/~michaelm/5049299/webrev.00/
>
> **I'd like to give an outline of the change here, to make reviewing
> the webrev a bit easier.  Basically, while posix_spawn() is a fairly
> elaborate and complicated system call, it can't quite do everything
> that the old fork()/exec() combination can do,

I've always assumed that the ProcessBuilder requirements could be
fulfilled by posix_spawn and friends.  Could you elaborate why this is
not the case?

The file descriptor setup race mentioned in the comments shouldn't
apply, really--the reshuffling should occur in the child, isolated
from the parent, otherwise the implementation is quite broken and
pointless.

-- 
Florian Weimer                <fweimer at bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstra?e 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99


From gnu_andrew at member.fsf.org  Thu May 28 08:57:11 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Thu, 28 May 2009 09:57:11 +0100
Subject: OpenJDK Forum: Core Libraries Round Table
In-Reply-To: <20090528083410.GA3215@redhat.com>
References: <4A1D759A.5020504@sun.com> <20090528083410.GA3215@redhat.com>
Message-ID: <17c6771e0905280157q39131f98tde0334d4ad8b18aa@mail.gmail.com>

2009/5/28 Gary Benson <gbenson at redhat.com>:
> Dalibor Topic wrote:
>> Date/Time: Friday May 29th, 8 AM Pacific, 1600 GMT, 5 PM Germany
>
> Is that 1600 GMT or 1600 BST (ie 1500 GMT)?
>
> Cheers,
> Gary
>
> --
> http://gbenson.net/
>

Dalibor, it's looks like you copied and pasted the wrong line again... ;)

If it's 5pm in Germany, only 1600 BST makes any sense.
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8


From fweimer at bfk.de  Thu May 28 09:10:18 2009
From: fweimer at bfk.de (Florian Weimer)
Date: Thu, 28 May 2009 11:10:18 +0200
Subject: Review request for 5049299
In-Reply-To: <4A17B3BB.4090706@redhat.com> (Andrew Haley's message of "Sat\,
	23 May 2009 09\:28\:43 +0100")
References: <4A1678DB.9010209@sun.com>
	<1ccfd1c10905221230u6f085d6eu26e0c516784e81ee@mail.gmail.com>
	<4A172398.9000100@sun.com>
	<1ccfd1c10905221757t30a7f610jd343084e50ec88bb@mail.gmail.com>
	<4A17B3BB.4090706@redhat.com>
Message-ID: <82hbz5lhj9.fsf@mid.bfk.de>

* Andrew Haley:

> But those running Linux won't benefit from such a change because
> on Linux there is no transient doubling of process size: all that happens
> is that the page table entries in the new process are mapped copy on write.
> The extra pages count towards the overcommit limit, but that's wholly
> artifical.

On Linux in vm.overcommit_memory=2 mode, the whole heap (not just the
committed part) counts against the system's total memory allocation
limit.  After a fork, the heap counts twice.  Copy-on-write is just an
optimization in this mode, it does not change the physical memory
requirements of the workload (in vm.overcommit_memory=1 mode, it
does).

I guess the issue might even be worse on Linux than on Solaris because
the heap initialization code in Hotspot is wrong.  It uses
MAP_NORESERVE, which means that the VM will die with SIGSEGV when it
tries to write to a page for which the kernel cannot provide backing
storage.  This SIGSEGV is not turned into an OutOfMemoryError, leading
to hard-to-diagnose bug reports.  (It's not an OOM situation from the
kernel's point of view, so you don't get a trace from the OOM killer
in the system log, either.)

A better way seems to be to allocate the heap with PROT_NONE, and
later use mprotect with PROT_READ|PROT_WRITE (and perhaps PROT_EXEC)
to allocate chunks from the kernel.  This will fail deterministically
in the garbage collector if no physical memory is available.  The
PROT_NONE mapping is only there to reserve a continuous chunk of
address space (so that calls to malloc or dlopen do not create
mappings in the middle of the Java heap).  When I tested this some
time ago, a PROT_NONE mapping did not count towards the system's
memory allocation limit, hence the potential failure in the mprotect
call.  The main problem with this approach is that this is not a
documented way of using the kernel API; it might work accidentally now
and change behavior in the future.

Sorry for hijacking this thread, but I thought this clarification was
helpful.

-- 
Florian Weimer                <fweimer at bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstra?e 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99


From Michael.McMahon at Sun.COM  Thu May 28 09:18:24 2009
From: Michael.McMahon at Sun.COM (Michael McMahon)
Date: Thu, 28 May 2009 10:18:24 +0100
Subject: Review request for 5049299
In-Reply-To: <82iqjlli6u.fsf@mid.bfk.de>
References: <4A1678DB.9010209@sun.com> <82iqjlli6u.fsf@mid.bfk.de>
Message-ID: <4A1E56E0.7050402@sun.com>

Florian Weimer wrote:
> * Michael McMahon:
>
>   
>> webrev location: http://cr.openjdk.java.net/~michaelm/5049299/webrev.00/
>>
>> **I'd like to give an outline of the change here, to make reviewing
>> the webrev a bit easier.  Basically, while posix_spawn() is a fairly
>> elaborate and complicated system call, it can't quite do everything
>> that the old fork()/exec() combination can do,
>>     
>
> I've always assumed that the ProcessBuilder requirements could be
> fulfilled by posix_spawn and friends.  Could you elaborate why this is
> not the case?
>
>   
> The file descriptor setup race mentioned in the comments shouldn't
> apply, really--the reshuffling should occur in the child, isolated
> from the parent, otherwise the implementation is quite broken and
> pointless.
>
>   
But you can't expect an arbitrary command (eg. "/bin/ls") to do any
"reshuffling". It has to be done by something
in between the parent and the target command.

The other problem, is the requirement to change working directory
for the target. posix_spawn() doesn't allow this.

Just to be clear as well, posix_spawn() is being used (to avoid
the fork() memory duplication issue) but it isn't able to complete
the job which is why we need this extra helper (on Solaris).

Thanks,
Michael.



From fweimer at bfk.de  Thu May 28 09:52:05 2009
From: fweimer at bfk.de (Florian Weimer)
Date: Thu, 28 May 2009 11:52:05 +0200
Subject: Review request for 5049299
In-Reply-To: <4A1E56E0.7050402@sun.com> (Michael McMahon's message of "Thu\,
	28 May 2009 10\:18\:24 +0100")
References: <4A1678DB.9010209@sun.com> <82iqjlli6u.fsf@mid.bfk.de>
	<4A1E56E0.7050402@sun.com>
Message-ID: <82zlcxk116.fsf@mid.bfk.de>

* Michael McMahon:

>>   The file descriptor setup race mentioned in the comments shouldn't
>> apply, really--the reshuffling should occur in the child, isolated
>> from the parent, otherwise the implementation is quite broken and
>> pointless.
>>
>>   
> But you can't expect an arbitrary command (eg. "/bin/ls") to do any
> "reshuffling". It has to be done by something
> in between the parent and the target command.

I think you could implement this with actions set up using
posix_spawn_file_actions_adddup2.

> The other problem, is the requirement to change working directory
> for the target. posix_spawn() doesn't allow this.

Oh well, I agree that this is a problem.  This is a significant gap in
the API.  (OTOH, the API is extensible, so it should be possible to
address this, but probably not in the time frame for this bug.)

-- 
Florian Weimer                <fweimer at bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstra?e 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99


From Dalibor.Topic at Sun.COM  Thu May 28 09:59:11 2009
From: Dalibor.Topic at Sun.COM (Dalibor Topic)
Date: Thu, 28 May 2009 02:59:11 -0700
Subject: OpenJDK Forum: Core Libraries Round Table
In-Reply-To: <17c6771e0905280157q39131f98tde0334d4ad8b18aa@mail.gmail.com>
References: <4A1D759A.5020504@sun.com> <20090528083410.GA3215@redhat.com>
	<17c6771e0905280157q39131f98tde0334d4ad8b18aa@mail.gmail.com>
Message-ID: <4A1E606F.60500@sun.com>

Andrew John Hughes wrote:
> 2009/5/28 Gary Benson <gbenson at redhat.com>:
>> Dalibor Topic wrote:
>>> Date/Time: Friday May 29th, 8 AM Pacific, 1600 GMT, 5 PM Germany
>> Is that 1600 GMT or 1600 BST (ie 1500 GMT)?
>>
>> Cheers,
>> Gary
>>
>> --
>> http://gbenson.net/
>>
> 
> Dalibor, it's looks like you copied and pasted the wrong line again... ;)
> 
> If it's 5pm in Germany, only 1600 BST makes any sense.

Right, it should be 
http://www.timeanddate.com/worldclock/meetingdetails.html?year=2009&month=5&day=29&hour=3&min=0&sec=0&p1=224&p2=136&p3=37

cheers,
dalibor topic

-- 
*******************************************************************
Dalibor Topic                   Tel: (+49 40) 23 646 738
Java F/OSS Ambassador           AIM: robiladonaim
Sun Microsystems GmbH           Mobile: (+49 177) 2664 192
Nagelsweg 55                    http://openjdk.java.net
D-20097 Hamburg                 mailto:Dalibor.Topic at sun.com
Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht M?nchen: HRB 161028
Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin H?ring




From Dalibor.Topic at Sun.COM  Thu May 28 10:04:53 2009
From: Dalibor.Topic at Sun.COM (Dalibor Topic)
Date: Thu, 28 May 2009 03:04:53 -0700
Subject: OpenJDK Forum: Core Libraries Round Table
In-Reply-To: <17c6771e0905280157q39131f98tde0334d4ad8b18aa@mail.gmail.com>
References: <4A1D759A.5020504@sun.com> <20090528083410.GA3215@redhat.com>
	<17c6771e0905280157q39131f98tde0334d4ad8b18aa@mail.gmail.com>
Message-ID: <4A1E61C5.2000608@sun.com>

Andrew John Hughes wrote:
> 2009/5/28 Gary Benson <gbenson at redhat.com>:
>> Dalibor Topic wrote:
>>> Date/Time: Friday May 29th, 8 AM Pacific, 1600 GMT, 5 PM Germany
>> Is that 1600 GMT or 1600 BST (ie 1500 GMT)?
>>
>> Cheers,
>> Gary
>>
>> --
>> http://gbenson.net/
>>
> 
> Dalibor, it's looks like you copied and pasted the wrong line again... ;)
> 
> If it's 5pm in Germany, only 1600 BST makes any sense.

Thanks for catching it, it's 1600 BST according to
http://www.timeanddate.com/worldclock/meetingdetails.html?year=2009&month=5&day=29&hour=15&min=0&sec=0&p1=224&p2=136&p3=37

cheers,
dalibor topic
-- 
*******************************************************************
Dalibor Topic                   Tel: (+49 40) 23 646 738
Java F/OSS Ambassador           AIM: robiladonaim
Sun Microsystems GmbH           Mobile: (+49 177) 2664 192
Nagelsweg 55                    http://openjdk.java.net
D-20097 Hamburg                 mailto:Dalibor.Topic at sun.com
Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht M?nchen: HRB 161028
Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin H?ring




From Dalibor.Topic at Sun.COM  Thu May 28 10:09:39 2009
From: Dalibor.Topic at Sun.COM (Dalibor Topic)
Date: Thu, 28 May 2009 03:09:39 -0700
Subject: OpenJDK Forum: Core Libraries Round Table
In-Reply-To: <4A1E606F.60500@sun.com>
References: <4A1D759A.5020504@sun.com> <20090528083410.GA3215@redhat.com>
	<17c6771e0905280157q39131f98tde0334d4ad8b18aa@mail.gmail.com>
	<4A1E606F.60500@sun.com>
Message-ID: <4A1E62E3.3020801@sun.com>

Dalibor Topic wrote:
> Andrew John Hughes wrote:
>> 2009/5/28 Gary Benson <gbenson at redhat.com>:
>>> Dalibor Topic wrote:
>>>> Date/Time: Friday May 29th, 8 AM Pacific, 1600 GMT, 5 PM Germany
>>> Is that 1600 GMT or 1600 BST (ie 1500 GMT)?
>>>
>>> Cheers,
>>> Gary
>>>
>>> --
>>> http://gbenson.net/
>>>
>> Dalibor, it's looks like you copied and pasted the wrong line again... ;)
>>
>> If it's 5pm in Germany, only 1600 BST makes any sense.
> 
> Right, it should be 
> http://www.timeanddate.com/worldclock/meetingdetails.html?year=2009&month=5&day=29&hour=3&min=0&sec=0&p1=224&p2=136&p3=37

Heh, almost - it's actually 
http://www.timeanddate.com/worldclock/meetingdetails.html?year=2009&month=5&day=29&hour=15&min=0&sec=0&p1=224&p2=136&p3=37

(clearly I should just let a script do this rather then posting after
midnight myself)

cheers,
dalibor topic
-- 
*******************************************************************
Dalibor Topic                   Tel: (+49 40) 23 646 738
Java F/OSS Ambassador           AIM: robiladonaim
Sun Microsystems GmbH           Mobile: (+49 177) 2664 192
Nagelsweg 55                    http://openjdk.java.net
D-20097 Hamburg                 mailto:Dalibor.Topic at sun.com
Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht M?nchen: HRB 161028
Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin H?ring




From aph at redhat.com  Thu May 28 11:19:20 2009
From: aph at redhat.com (Andrew Haley)
Date: Thu, 28 May 2009 12:19:20 +0100
Subject: Review request for 5049299
In-Reply-To: <82hbz5lhj9.fsf@mid.bfk.de>
References: <4A1678DB.9010209@sun.com>	<1ccfd1c10905221230u6f085d6eu26e0c516784e81ee@mail.gmail.com>	<4A172398.9000100@sun.com>	<1ccfd1c10905221757t30a7f610jd343084e50ec88bb@mail.gmail.com>	<4A17B3BB.4090706@redhat.com>
	<82hbz5lhj9.fsf@mid.bfk.de>
Message-ID: <4A1E7338.8090800@redhat.com>

Florian Weimer wrote:
> * Andrew Haley:
> 
>> But those running Linux won't benefit from such a change because
>> on Linux there is no transient doubling of process size: all that happens
>> is that the page table entries in the new process are mapped copy on write.
>> The extra pages count towards the overcommit limit, but that's wholly
>> artifical.
> 
> On Linux in vm.overcommit_memory=2 mode, the whole heap (not just the
> committed part) counts against the system's total memory allocation
> limit.  After a fork, the heap counts twice.  Copy-on-write is just an
> optimization in this mode, it does not change the physical memory
> requirements of the workload (in vm.overcommit_memory=1 mode, it
> does).

Well, yes, all that vm.overcommit_memory=2 mode does is disable
overcommit, and overcommit is what you need to make this work
properly.  But even in vm.overcommit_memory=2 mode the pages still
aren't copied until written.  All that mode 2 does is prevent the
transient allocation of the pages in the copy of the forked process,
even though the system has all the memory it needs to fulfil the
request.  AIUI...

> A better way seems to be to allocate the heap with PROT_NONE, and
> later use mprotect with PROT_READ|PROT_WRITE (and perhaps PROT_EXEC)
> to allocate chunks from the kernel.  This will fail deterministically
> in the garbage collector if no physical memory is available.  The
> PROT_NONE mapping is only there to reserve a continuous chunk of
> address space (so that calls to malloc or dlopen do not create
> mappings in the middle of the Java heap).  When I tested this some
> time ago, a PROT_NONE mapping did not count towards the system's
> memory allocation limit, hence the potential failure in the mprotect
> call.  The main problem with this approach is that this is not a
> documented way of using the kernel API; it might work accidentally now
> and change behavior in the future.

I can see the sense in this.  In modes 0 and 1 Java won't behave any
differently from the way it does today, except that why it does run
out of real memory there will be a decent traceback rather than a segfault.

However, I think you don't want PROT_NONE whan a system has been configured
with mode 2: in that case, a user has a reasonable expectation that
they can use all of the memory they allocated at VM startup.  It makes
more sense to allocate all the -Xms size immediately.

Andrew.


From aph at redhat.com  Thu May 28 15:11:31 2009
From: aph at redhat.com (Andrew Haley)
Date: Thu, 28 May 2009 16:11:31 +0100
Subject: Request for approval: fix 4428022,	System.out.println(0.001)
	outputs	0.0010
In-Reply-To: <4A1B16FC.80108@sun.com>
References: <4A16806B.9060001@redhat.com> <4A169110.1030003@sun.com>
	<4A16DF30.6080509@redhat.com> <4A171185.8030504@sun.com>
	<4A1B16FC.80108@sun.com>
Message-ID: <4A1EA9A3.5030508@redhat.com>

Joseph D. Darcy wrote:
> Alan Bateman wrote:
>> Andrew Haley wrote:
>>> :
>>> OK, here it is.  I put the test in java/lang/Double/ToString.java
>>> rather than sun/misc/FloatingDecimal because the bug manifested
>>> itself in Double.toString although the fix was in
>>> FloatingDecimal.dtoa.
>>>   
>> I agree that test/java/lang/Double is the best place for this. All
>> looks good to me (except minor nit, "String argv[]" -> "String[]
>> args").  Joe, are you okay with this?
> 
> Yes; the changes look fine for both releases.

Thanks.  One odd problem.

I committed my change, and then did hg push.  It said:

abort: push creates new remote heads!
(did you forget to merge? use push -f to force)

OK, so I need to fetch:

 $ hg fetch
pulling from ssh://hg.openjdk.java.net/jdk6/jdk6/jdk
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files (+1 heads)
updating to 152:c00f461c45bc
2 files updated, 0 files merged, 5 files removed, 0 files unresolved
merging with 151:a42ec05e4313
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
new changeset 153:7e3508f40d3c merges remote changes with local

Try again:

 $ hg push ssh://hg.openjdk.java.net/jdk6/jdk6-gate/jdk
pushing to ssh://hg.openjdk.java.net/jdk6/jdk6-gate/jdk
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 2 changesets with 2 changes to 2 files
remote:
remote: > Changeset: 153:7e3508f40d3c
remote: > Author:    aphAutomated merge with
remote: > Date:      2009-05-28 16:04
remote: >
remote: > Automated merge with ssh://hg.openjdk.java.net/jdk6/jdk6/jdk
remote:
remote: Invalid comment for merge changeset (must be "Merge")
remote:
remote: abort: pretxnchangegroup.0.jcheck hook failed
remote: transaction abort!
remote: rollback completed

I think that jcheck is demanding that the merge comment must be "Merge",
but "hg fetch" generates "Automated merge with ..."

Surely this must happen to people inside Sun all the time.  So how do
y'all cope with it?

Andrew.


From jonathan.gibbons at sun.com  Thu May 28 16:55:17 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Thu, 28 May 2009 16:55:17 +0000
Subject: hg: jdk7/tl/langtools: 6802102: unignore @ignored tests where possible
Message-ID: <20090528165523.708A6ECCD@hg.openjdk.java.net>

Changeset: d4828eba4939
Author:    jjg
Date:      2009-05-28 09:49 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d4828eba4939

6802102: unignore @ignored tests where possible
Reviewed-by: mcimadamore

! test/tools/javac/T6405099.java
! test/tools/javac/api/6431257/T6431257.java
! test/tools/javac/api/TestJavacTaskScanner.java
! test/tools/javac/code/ArrayClone.java
- test/tools/javac/code/ArrayClone.sh
! test/tools/javac/generics/inference/6365166/NewTest.java



From aph at redhat.com  Thu May 28 17:34:54 2009
From: aph at redhat.com (Andrew Haley)
Date: Thu, 28 May 2009 18:34:54 +0100
Subject: Request for approval: fix 4428022,	System.out.println(0.001)
	outputs	0.0010
In-Reply-To: <4A1B16FC.80108@sun.com>
References: <4A16806B.9060001@redhat.com> <4A169110.1030003@sun.com>
	<4A16DF30.6080509@redhat.com> <4A171185.8030504@sun.com>
	<4A1B16FC.80108@sun.com>
Message-ID: <4A1ECB3E.2040803@redhat.com>

Joseph D. Darcy wrote:
> Alan Bateman wrote:
>> Andrew Haley wrote:
>>> :
>>> OK, here it is.  I put the test in java/lang/Double/ToString.java
>>> rather than sun/misc/FloatingDecimal because the bug manifested
>>> itself in Double.toString although the fix was in
>>> FloatingDecimal.dtoa.
>>>   
>> I agree that test/java/lang/Double is the best place for this. All
>> looks good to me (except minor nit, "String argv[]" -> "String[]
>> args").  Joe, are you okay with this?
>>
>> -Alan.
> 
> Yes; the changes look fine for both releases.

To which openjdk7 repo do you want me to push this?
My best guess is jdk7/jdk7-gate/jdk.

Andrew.


From martinrb at google.com  Thu May 28 17:56:00 2009
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 28 May 2009 10:56:00 -0700
Subject: Review request for 5049299
In-Reply-To: <82iqjlli6u.fsf@mid.bfk.de>
References: <4A1678DB.9010209@sun.com> <82iqjlli6u.fsf@mid.bfk.de>
Message-ID: <1ccfd1c10905281056t7a378cb8p5b9ebdbfe1292b32@mail.gmail.com>

On Thu, May 28, 2009 at 01:56, Florian Weimer <fweimer at bfk.de> wrote:

> * Michael McMahon:
>
> > webrev location: http://cr.openjdk.java.net/~michaelm/5049299/webrev.00/<http://cr.openjdk.java.net/%7Emichaelm/5049299/webrev.00/>
> >
> > **I'd like to give an outline of the change here, to make reviewing
> > the webrev a bit easier.  Basically, while posix_spawn() is a fairly
> > elaborate and complicated system call, it can't quite do everything
> > that the old fork()/exec() combination can do,
>
> I've always assumed that the ProcessBuilder requirements could be
> fulfilled by posix_spawn and friends.  Could you elaborate why this is
> not the case?
>

You need to pass a list of file descriptor actions to posix_spawn,
but you cannot safely compute such a complete list of actions because
you are still in the parent when doing this.

The computation of the list of actions (closes and dups)
itself needs to be done in the child.

Martin


> The file descriptor setup race mentioned in the comments shouldn't
> apply, really--the reshuffling should occur in the child, isolated
> from the parent, otherwise the implementation is quite broken and
> pointless.
>
> --
> Florian Weimer                <fweimer at bfk.de>
> BFK edv-consulting GmbH       http://www.bfk.de/
> Kriegsstra?e 100              tel: +49-721-96201-1
> D-76133 Karlsruhe             fax: +49-721-96201-99
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090528/46eb5dde/attachment.html>

From Alan.Bateman at Sun.COM  Thu May 28 18:02:09 2009
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Thu, 28 May 2009 19:02:09 +0100
Subject: Request for approval: fix 4428022,
	System.out.println(0.001) outputs	0.0010
In-Reply-To: <4A1ECB3E.2040803@redhat.com>
References: <4A16806B.9060001@redhat.com> <4A169110.1030003@sun.com>
	<4A16DF30.6080509@redhat.com> <4A171185.8030504@sun.com>
	<4A1B16FC.80108@sun.com> <4A1ECB3E.2040803@redhat.com>
Message-ID: <4A1ED1A1.5050401@sun.com>

Andrew Haley wrote:
> :
> To which openjdk7 repo do you want me to push this?
> My best guess is jdk7/jdk7-gate/jdk.
>   
jdk7/tl-gate/jdk is where libs changes should be pushed.

-Alan.


From aph at redhat.com  Thu May 28 18:32:31 2009
From: aph at redhat.com (Andrew Haley)
Date: Thu, 28 May 2009 19:32:31 +0100
Subject: Request for approval: fix 4428022,	System.out.println(0.001)
	outputs	0.0010
In-Reply-To: <4A1ED1A1.5050401@sun.com>
References: <4A16806B.9060001@redhat.com> <4A169110.1030003@sun.com>
	<4A16DF30.6080509@redhat.com> <4A171185.8030504@sun.com>
	<4A1B16FC.80108@sun.com> <4A1ECB3E.2040803@redhat.com>
	<4A1ED1A1.5050401@sun.com>
Message-ID: <4A1ED8BF.9080908@redhat.com>

Alan Bateman wrote:
> Andrew Haley wrote:
>> :
>> To which openjdk7 repo do you want me to push this?
>> My best guess is jdk7/jdk7-gate/jdk.
>>   
> jdk7/tl-gate/jdk is where libs changes should be pushed.

OK.  Just for my curiosity, what does "tl" stand for?  I guessed
it was something to do with thread-local storage!

Andrew.


From Xueming.Shen at Sun.COM  Thu May 28 18:54:07 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Thu, 28 May 2009 11:54:07 -0700
Subject: Request for approval: fix 4428022,
	System.out.println(0.001) outputs	0.0010
In-Reply-To: <4A1ED8BF.9080908@redhat.com>
References: <4A16806B.9060001@redhat.com> <4A169110.1030003@sun.com>
	<4A16DF30.6080509@redhat.com> <4A171185.8030504@sun.com>
	<4A1B16FC.80108@sun.com> <4A1ECB3E.2040803@redhat.com>
	<4A1ED1A1.5050401@sun.com> <4A1ED8BF.9080908@redhat.com>
Message-ID: <4A1EDDCF.5000706@sun.com>

Andrew Haley wrote:
> Alan Bateman wrote:
>   
>> Andrew Haley wrote:
>>     
>>> :
>>> To which openjdk7 repo do you want me to push this?
>>> My best guess is jdk7/jdk7-gate/jdk.
>>>   
>>>       
>> jdk7/tl-gate/jdk is where libs changes should be pushed.
>>     
>
> OK.  Just for my curiosity, what does "tl" stand for?  I guessed
> it was something to do with thread-local storage!
>
> Andrew.
>   
Tools and Libraries.



From Joe.Darcy at Sun.COM  Thu May 28 19:27:03 2009
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Thu, 28 May 2009 12:27:03 -0700
Subject: Request for approval: fix 4428022,
	System.out.println(0.001) outputs	0.0010
In-Reply-To: <4A1ECB3E.2040803@redhat.com>
References: <4A16806B.9060001@redhat.com> <4A169110.1030003@sun.com>
	<4A16DF30.6080509@redhat.com> <4A171185.8030504@sun.com>
	<4A1B16FC.80108@sun.com> <4A1ECB3E.2040803@redhat.com>
Message-ID: <4A1EE587.1030708@sun.com>

Andrew Haley wrote:
> Joseph D. Darcy wrote:
>   
>> Alan Bateman wrote:
>>     
>>> Andrew Haley wrote:
>>>       
>>>> :
>>>> OK, here it is.  I put the test in java/lang/Double/ToString.java
>>>> rather than sun/misc/FloatingDecimal because the bug manifested
>>>> itself in Double.toString although the fix was in
>>>> FloatingDecimal.dtoa.
>>>>   
>>>>         
>>> I agree that test/java/lang/Double is the best place for this. All
>>> looks good to me (except minor nit, "String argv[]" -> "String[]
>>> args").  Joe, are you okay with this?
>>>
>>> -Alan.
>>>       
>> Yes; the changes look fine for both releases.
>>     
>
> To which openjdk7 repo do you want me to push this?
> My best guess is jdk7/jdk7-gate/jdk.
>   

Please push this through TL (tools and libraries): 
ssh://hg.openjdk.java.net/jdk7/tl-gate/jdk

-Joe


From aph at redhat.com  Thu May 28 19:29:21 2009
From: aph at redhat.com (Andrew Haley)
Date: Thu, 28 May 2009 20:29:21 +0100
Subject: Request for approval: fix 4428022,	System.out.println(0.001)
	outputs	0.0010
In-Reply-To: <4A1EE587.1030708@sun.com>
References: <4A16806B.9060001@redhat.com> <4A169110.1030003@sun.com>
	<4A16DF30.6080509@redhat.com> <4A171185.8030504@sun.com>
	<4A1B16FC.80108@sun.com> <4A1ECB3E.2040803@redhat.com>
	<4A1EE587.1030708@sun.com>
Message-ID: <4A1EE611.4090200@redhat.com>

Joseph D. Darcy wrote:
> Andrew Haley wrote:
>> Joseph D. Darcy wrote:
>>  
>>> Alan Bateman wrote:
>>>    
>>>> Andrew Haley wrote:
>>>>      
>>>>> :
>>>>> OK, here it is.  I put the test in java/lang/Double/ToString.java
>>>>> rather than sun/misc/FloatingDecimal because the bug manifested
>>>>> itself in Double.toString although the fix was in
>>>>> FloatingDecimal.dtoa.
>>>>>           
>>>> I agree that test/java/lang/Double is the best place for this. All
>>>> looks good to me (except minor nit, "String argv[]" -> "String[]
>>>> args").  Joe, are you okay with this?
>>>>
>>>> -Alan.
>>>>       
>>> Yes; the changes look fine for both releases.
>>
>> To which openjdk7 repo do you want me to push this?
>> My best guess is jdk7/jdk7-gate/jdk.
> 
> Please push this through TL (tools and libraries):
> ssh://hg.openjdk.java.net/jdk7/tl-gate/jdk

Ta.  A request:

I think that patch approvals had better start to include the repo.
External contributors need this information, even if it's obvious
from inside Sun.

Thanks,
Andrew.



From Dalibor.Topic at Sun.COM  Fri May 29 00:16:24 2009
From: Dalibor.Topic at Sun.COM (Dalibor Topic)
Date: Thu, 28 May 2009 17:16:24 -0700
Subject: Request for approval: fix 4428022,
	System.out.println(0.001) outputs	0.0010
In-Reply-To: <4A1EA9A3.5030508@redhat.com>
References: <4A16806B.9060001@redhat.com> <4A169110.1030003@sun.com>
	<4A16DF30.6080509@redhat.com> <4A171185.8030504@sun.com>
	<4A1B16FC.80108@sun.com> <4A1EA9A3.5030508@redhat.com>
Message-ID: <4A1F2958.40900@sun.com>

Andrew Haley wrote:
> I think that jcheck is demanding that the merge comment must be "Merge",
> but "hg fetch" generates "Automated merge with ..."
> 
> Surely this must happen to people inside Sun all the time.  So how do
> y'all cope with it?

in .hgrc I've got:

fetch = -m Merge

cheers,
dalibor topic
-- 
*******************************************************************
Dalibor Topic                   Tel: (+49 40) 23 646 738
Java F/OSS Ambassador           AIM: robiladonaim
Sun Microsystems GmbH           Mobile: (+49 177) 2664 192
Nagelsweg 55                    http://openjdk.java.net
D-20097 Hamburg                 mailto:Dalibor.Topic at sun.com
Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht M?nchen: HRB 161028
Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin H?ring




From gnu_andrew at member.fsf.org  Fri May 29 00:44:24 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Fri, 29 May 2009 01:44:24 +0100
Subject: Request for approval: fix 4428022, System.out.println(0.001) 
	outputs 0.0010
In-Reply-To: <4A1EE611.4090200@redhat.com>
References: <4A16806B.9060001@redhat.com> <4A169110.1030003@sun.com>
	<4A16DF30.6080509@redhat.com> <4A171185.8030504@sun.com>
	<4A1B16FC.80108@sun.com> <4A1ECB3E.2040803@redhat.com>
	<4A1EE587.1030708@sun.com> <4A1EE611.4090200@redhat.com>
Message-ID: <17c6771e0905281744n271c9f95hd0e3211d3f3946d4@mail.gmail.com>

2009/5/28 Andrew Haley <aph at redhat.com>:
> Joseph D. Darcy wrote:
>> Andrew Haley wrote:
>>> Joseph D. Darcy wrote:
>>>
>>>> Alan Bateman wrote:
>>>>
>>>>> Andrew Haley wrote:
>>>>>
>>>>>> :
>>>>>> OK, here it is. ?I put the test in java/lang/Double/ToString.java
>>>>>> rather than sun/misc/FloatingDecimal because the bug manifested
>>>>>> itself in Double.toString although the fix was in
>>>>>> FloatingDecimal.dtoa.
>>>>>>
>>>>> I agree that test/java/lang/Double is the best place for this. All
>>>>> looks good to me (except minor nit, "String argv[]" -> "String[]
>>>>> args"). ?Joe, are you okay with this?
>>>>>
>>>>> -Alan.
>>>>>
>>>> Yes; the changes look fine for both releases.
>>>
>>> To which openjdk7 repo do you want me to push this?
>>> My best guess is jdk7/jdk7-gate/jdk.
>>
>> Please push this through TL (tools and libraries):
>> ssh://hg.openjdk.java.net/jdk7/tl-gate/jdk
>
> Ta. ?A request:
>
> I think that patch approvals had better start to include the repo.
> External contributors need this information, even if it's obvious
> from inside Sun.
>
> Thanks,
> Andrew.
>
>

I second that.  FWIW, I believe nothing ever gets pushed to the
jdk7-gate initially, it's used as part of the release engineering
process.
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8


From Dalibor.Topic at Sun.COM  Fri May 29 05:27:21 2009
From: Dalibor.Topic at Sun.COM (Dalibor Topic)
Date: Fri, 29 May 2009 07:27:21 +0200
Subject: Update: OpenJDK Forum: Core Libraries Round Table
In-Reply-To: <4A1D759A.5020504@sun.com>
References: <4A1D759A.5020504@sun.com>
Message-ID: <4A1F7239.1000700@Sun.COM>

Since conference calls may be a somewhat new experience to some of us,

here are a couple ground rules:

* Please identify yourself by name and location when speaking.

At least in theory, we could have more then one Dalibor on the call, for 
example, and for those of us not familiar with each Dalibor's voice, having
a way to pick them apart is useful. 

* Please address individuals by name when speaking.

That helps keep the discussion flowing, without causing confusion who a
particular question, remark or idea is addressed to.

* Please speak clearly and avoid side conversations and background noise.

We'll use the #openjdk IRC channel on irc.oftc.net for side conversations.
If you are not familiar with IRC clients, you can run the corresponding
web start application at http://openjdk.java.net/irc/ .

*  Keeping the noise down

When you're not speaking, please mute your own line by pressing *6 on your 
telephone keypad. To unmute press *6 again.

* On Sun campus in Santa Clara?

Please join Dalibor and Alan in conference room "Abba Zabba" in building 22.

See & hear you soon,
dalibor topic


-- 
*******************************************************************
Dalibor Topic                   Tel: (+49 40) 23 646 738
Java F/OSS Ambassador           AIM: robiladonaim
Sun Microsystems GmbH           Mobile: (+49 177) 2664 192
Nagelsweg 55                    http://openjdk.java.net
D-20097 Hamburg                 mailto:Dalibor.Topic at sun.com
Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht M?nchen: HRB 161028
Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Dr. Roland B?mer
Vorsitzender des Aufsichtsrates: Martin H?ring



From fweimer at bfk.de  Fri May 29 07:40:08 2009
From: fweimer at bfk.de (Florian Weimer)
Date: Fri, 29 May 2009 09:40:08 +0200
Subject: Review request for 5049299
In-Reply-To: <4A1E7338.8090800@redhat.com> (Andrew Haley's message of "Thu\,
	28 May 2009 12\:19\:20 +0100")
References: <4A1678DB.9010209@sun.com>
	<1ccfd1c10905221230u6f085d6eu26e0c516784e81ee@mail.gmail.com>
	<4A172398.9000100@sun.com>
	<1ccfd1c10905221757t30a7f610jd343084e50ec88bb@mail.gmail.com>
	<4A17B3BB.4090706@redhat.com> <82hbz5lhj9.fsf@mid.bfk.de>
	<4A1E7338.8090800@redhat.com>
Message-ID: <82zlcwfjc7.fsf@mid.bfk.de>

* Andrew Haley:

> However, I think you don't want PROT_NONE whan a system has been configured
> with mode 2: in that case, a user has a reasonable expectation that
> they can use all of the memory they allocated at VM startup.  It makes
> more sense to allocate all the -Xms size immediately.

-Xms?  Or -Xmx?  The latter leads to problems if the maximum heap size
is relatively large.  Currently, -Xmx is reserved, and some software
fails to build on vm.overcommit_memory systems due to this.

-- 
Florian Weimer                <fweimer at bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstra?e 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99


From aph at redhat.com  Fri May 29 08:52:06 2009
From: aph at redhat.com (Andrew Haley)
Date: Fri, 29 May 2009 09:52:06 +0100
Subject: Request for approval: fix 4428022,	System.out.println(0.001)
	outputs	0.0010
In-Reply-To: <4A1F2958.40900@sun.com>
References: <4A16806B.9060001@redhat.com> <4A169110.1030003@sun.com>
	<4A16DF30.6080509@redhat.com> <4A171185.8030504@sun.com>
	<4A1B16FC.80108@sun.com> <4A1EA9A3.5030508@redhat.com>
	<4A1F2958.40900@sun.com>
Message-ID: <4A1FA236.20109@redhat.com>

Dalibor Topic wrote:
> Andrew Haley wrote:
>> I think that jcheck is demanding that the merge comment must be "Merge",
>> but "hg fetch" generates "Automated merge with ..."
>>
>> Surely this must happen to people inside Sun all the time.  So how do
>> y'all cope with it?
> 
> in .hgrc I've got:
> 
> fetch = -m Merge

Aha!  We really need some sort of Hg user's kit.

I don't suppose there is any way that your Hg could be persuaded to
accept the default string from Hg, is there?  :-)

Andrew.


From aph at redhat.com  Fri May 29 08:54:48 2009
From: aph at redhat.com (Andrew Haley)
Date: Fri, 29 May 2009 09:54:48 +0100
Subject: Review request for 5049299
In-Reply-To: <82zlcwfjc7.fsf@mid.bfk.de>
References: <4A1678DB.9010209@sun.com>	<1ccfd1c10905221230u6f085d6eu26e0c516784e81ee@mail.gmail.com>	<4A172398.9000100@sun.com>	<1ccfd1c10905221757t30a7f610jd343084e50ec88bb@mail.gmail.com>	<4A17B3BB.4090706@redhat.com>
	<82hbz5lhj9.fsf@mid.bfk.de>	<4A1E7338.8090800@redhat.com>
	<82zlcwfjc7.fsf@mid.bfk.de>
Message-ID: <4A1FA2D8.5040803@redhat.com>

Florian Weimer wrote:
> * Andrew Haley:
> 
>> However, I think you don't want PROT_NONE whan a system has been configured
>> with mode 2: in that case, a user has a reasonable expectation that
>> they can use all of the memory they allocated at VM startup.  It makes
>> more sense to allocate all the -Xms size immediately.
> 
> -Xms?  Or -Xmx?

-Xms as a minimum: the user has a entitlement to that.  It's not unreasonable
that later heap expansion might fail.

> The latter leads to problems if the maximum heap size is relatively large.
> Currently, -Xmx is reserved, and some software fails to build on
> vm.overcommit_memory systems due to this.

I don't get it.  Why would overcommit cause some software to fail to
build?  I can understand it failing if overcommit was turned off.

Andrew.



From fweimer at bfk.de  Fri May 29 08:59:22 2009
From: fweimer at bfk.de (Florian Weimer)
Date: Fri, 29 May 2009 10:59:22 +0200
Subject: Review request for 5049299
In-Reply-To: <4A1FA2D8.5040803@redhat.com> (Andrew Haley's message of "Fri\,
	29 May 2009 09\:54\:48 +0100")
References: <4A1678DB.9010209@sun.com>
	<1ccfd1c10905221230u6f085d6eu26e0c516784e81ee@mail.gmail.com>
	<4A172398.9000100@sun.com>
	<1ccfd1c10905221757t30a7f610jd343084e50ec88bb@mail.gmail.com>
	<4A17B3BB.4090706@redhat.com> <82hbz5lhj9.fsf@mid.bfk.de>
	<4A1E7338.8090800@redhat.com> <82zlcwfjc7.fsf@mid.bfk.de>
	<4A1FA2D8.5040803@redhat.com>
Message-ID: <82y6sge13p.fsf@mid.bfk.de>

* Andrew Haley:

>> The latter leads to problems if the maximum heap size is relatively large.
>> Currently, -Xmx is reserved, and some software fails to build on
>> vm.overcommit_memory systems due to this.
>
> I don't get it.  Why would overcommit cause some software to fail to
> build?  I can understand it failing if overcommit was turned off.

Sorry, I meant to write "vm.overcommit_memory=2".

-- 
Florian Weimer                <fweimer at bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstra?e 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99


From aph at redhat.com  Fri May 29 10:18:28 2009
From: aph at redhat.com (Andrew Haley)
Date: Fri, 29 May 2009 11:18:28 +0100
Subject: Review request for 5049299
In-Reply-To: <82y6sge13p.fsf@mid.bfk.de>
References: <4A1678DB.9010209@sun.com>	<1ccfd1c10905221230u6f085d6eu26e0c516784e81ee@mail.gmail.com>	<4A172398.9000100@sun.com>	<1ccfd1c10905221757t30a7f610jd343084e50ec88bb@mail.gmail.com>	<4A17B3BB.4090706@redhat.com>
	<82hbz5lhj9.fsf@mid.bfk.de>	<4A1E7338.8090800@redhat.com>
	<82zlcwfjc7.fsf@mid.bfk.de>	<4A1FA2D8.5040803@redhat.com>
	<82y6sge13p.fsf@mid.bfk.de>
Message-ID: <4A1FB674.1030808@redhat.com>

Florian Weimer wrote:
> * Andrew Haley:
> 
>>> The latter leads to problems if the maximum heap size is relatively large.
>>> Currently, -Xmx is reserved, and some software fails to build on
>>> vm.overcommit_memory systems due to this.
>> I don't get it.  Why would overcommit cause some software to fail to
>> build?  I can understand it failing if overcommit was turned off.
> 
> Sorry, I meant to write "vm.overcommit_memory=2".

Well, the system is doing what the user asked it to do.  -Xmx means
"please reserve this memory for me, Hal"; if the memory isn't there,
then it's surely quite reasonable for Hal to respond "I'm sorry Dave,
I can't do that."

If you see what I mean.  :-)

Andrew.


From fweimer at bfk.de  Fri May 29 10:47:06 2009
From: fweimer at bfk.de (Florian Weimer)
Date: Fri, 29 May 2009 12:47:06 +0200
Subject: Review request for 5049299
In-Reply-To: <4A1FB674.1030808@redhat.com> (Andrew Haley's message of "Fri\,
	29 May 2009 11\:18\:28 +0100")
References: <4A1678DB.9010209@sun.com>
	<1ccfd1c10905221230u6f085d6eu26e0c516784e81ee@mail.gmail.com>
	<4A172398.9000100@sun.com>
	<1ccfd1c10905221757t30a7f610jd343084e50ec88bb@mail.gmail.com>
	<4A17B3BB.4090706@redhat.com> <82hbz5lhj9.fsf@mid.bfk.de>
	<4A1E7338.8090800@redhat.com> <82zlcwfjc7.fsf@mid.bfk.de>
	<4A1FA2D8.5040803@redhat.com> <82y6sge13p.fsf@mid.bfk.de>
	<4A1FB674.1030808@redhat.com>
Message-ID: <82skiodw45.fsf@mid.bfk.de>

* Andrew Haley:

> Florian Weimer wrote:
>> * Andrew Haley:
>> 
>>>> The latter leads to problems if the maximum heap size is relatively large.
>>>> Currently, -Xmx is reserved, and some software fails to build on
>>>> vm.overcommit_memory systems due to this.
>>> I don't get it.  Why would overcommit cause some software to fail to
>>> build?  I can understand it failing if overcommit was turned off.
>> 
>> Sorry, I meant to write "vm.overcommit_memory=2".
>
> Well, the system is doing what the user asked it to do.  -Xmx means
> "please reserve this memory for me, Hal"; if the memory isn't there,
> then it's surely quite reasonable for Hal to respond "I'm sorry Dave,
> I can't do that."

Well, I thought -Xms means that.  An untuned VM is not expected to hit
the -Xmx limit.  At least this is what I see in practice, and to me
this is the distinction expressed between the -Xmx and -Xms flags.

Reserving the -Xms heap portion does make sense, though.

-- 
Florian Weimer                <fweimer at bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstra?e 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99


From aph at redhat.com  Fri May 29 10:54:37 2009
From: aph at redhat.com (Andrew Haley)
Date: Fri, 29 May 2009 11:54:37 +0100
Subject: Review request for 5049299
In-Reply-To: <82skiodw45.fsf@mid.bfk.de>
References: <4A1678DB.9010209@sun.com>	<1ccfd1c10905221230u6f085d6eu26e0c516784e81ee@mail.gmail.com>	<4A172398.9000100@sun.com>	<1ccfd1c10905221757t30a7f610jd343084e50ec88bb@mail.gmail.com>	<4A17B3BB.4090706@redhat.com>
	<82hbz5lhj9.fsf@mid.bfk.de>	<4A1E7338.8090800@redhat.com>
	<82zlcwfjc7.fsf@mid.bfk.de>	<4A1FA2D8.5040803@redhat.com>
	<82y6sge13p.fsf@mid.bfk.de>	<4A1FB674.1030808@redhat.com>
	<82skiodw45.fsf@mid.bfk.de>
Message-ID: <4A1FBEED.2050906@redhat.com>

Florian Weimer wrote:
> * Andrew Haley:
> 
>> Florian Weimer wrote:
>>> * Andrew Haley:
>>>
>>>>> The latter leads to problems if the maximum heap size is relatively large.
>>>>> Currently, -Xmx is reserved, and some software fails to build on
>>>>> vm.overcommit_memory systems due to this.
>>>> I don't get it.  Why would overcommit cause some software to fail to
>>>> build?  I can understand it failing if overcommit was turned off.
>>> Sorry, I meant to write "vm.overcommit_memory=2".
>> Well, the system is doing what the user asked it to do.  -Xmx means
>> "please reserve this memory for me, Hal"; if the memory isn't there,
>> then it's surely quite reasonable for Hal to respond "I'm sorry Dave,
>> I can't do that."
> 
> Well, I thought -Xms means that.  An untuned VM is not expected to hit
> the -Xmx limit.  At least this is what I see in practice, and to me
> this is the distinction expressed between the -Xmx and -Xms flags.

I am very sorry, "-Xmx" was a typo, or perhaps a thinko.  In my original
posting -- which was trimmed -- I said

> It makes more sense to allocate all the -Xms size immediately.

and I thought you were disagreeing with me, but:

> Reserving the -Xms heap portion does make sense, though.

you weren't.

Andrew.



From fweimer at bfk.de  Fri May 29 10:58:56 2009
From: fweimer at bfk.de (Florian Weimer)
Date: Fri, 29 May 2009 12:58:56 +0200
Subject: Review request for 5049299
In-Reply-To: <4A1FBEED.2050906@redhat.com> (Andrew Haley's message of "Fri\,
	29 May 2009 11\:54\:37 +0100")
References: <4A1678DB.9010209@sun.com>
	<1ccfd1c10905221230u6f085d6eu26e0c516784e81ee@mail.gmail.com>
	<4A172398.9000100@sun.com>
	<1ccfd1c10905221757t30a7f610jd343084e50ec88bb@mail.gmail.com>
	<4A17B3BB.4090706@redhat.com> <82hbz5lhj9.fsf@mid.bfk.de>
	<4A1E7338.8090800@redhat.com> <82zlcwfjc7.fsf@mid.bfk.de>
	<4A1FA2D8.5040803@redhat.com> <82y6sge13p.fsf@mid.bfk.de>
	<4A1FB674.1030808@redhat.com> <82skiodw45.fsf@mid.bfk.de>
	<4A1FBEED.2050906@redhat.com>
Message-ID: <82eiu8dvkf.fsf@mid.bfk.de>

* Andrew Haley:

>> Well, I thought -Xms means that.  An untuned VM is not expected to hit
>> the -Xmx limit.  At least this is what I see in practice, and to me
>> this is the distinction expressed between the -Xmx and -Xms flags.
>
> I am very sorry, "-Xmx" was a typo, or perhaps a thinko.  In my original
> posting -- which was trimmed -- I said

Oops, sorry.

>> It makes more sense to allocate all the -Xms size immediately.
>
> and I thought you were disagreeing with me, but:

I tried to explain that, currently, the whole heap is reserved.  I
think we agree that it makes sense to reserve just the -Xms portion,
and leave the rest at PROT_NONE (or whatever mechanism the kernel
developers recommend).

-- 
Florian Weimer                <fweimer at bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstra?e 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99


From christopher.hegarty at sun.com  Fri May 29 14:57:46 2009
From: christopher.hegarty at sun.com (christopher.hegarty at sun.com)
Date: Fri, 29 May 2009 14:57:46 +0000
Subject: hg: jdk7/tl/jdk: 6807602: Increase MAX_BUFFER_LEN and
	MAX_HEAP_BUFFER_LEN on 64-bit Solaris and Linux
Message-ID: <20090529145758.759F4ED5C@hg.openjdk.java.net>

Changeset: 928e0f1043e6
Author:    chegar
Date:      2009-05-29 15:51 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/928e0f1043e6

6807602: Increase MAX_BUFFER_LEN and MAX_HEAP_BUFFER_LEN on 64-bit Solaris and Linux
Reviewed-by: alanb

! src/solaris/native/java/net/net_util_md.h



From Dalibor.Topic at Sun.COM  Fri May 29 17:07:46 2009
From: Dalibor.Topic at Sun.COM (Dalibor Topic)
Date: Fri, 29 May 2009 10:07:46 -0700
Subject: OpenJDK Forum: Core Libraries Round Table
In-Reply-To: <4A1D759A.5020504@sun.com>
References: <4A1D759A.5020504@sun.com>
Message-ID: <4A201662.1090002@sun.com>

Dalibor Topic wrote:
> Hi core libraries developers,
> 
> I met Alan Bateman last evening, and we thought that we
> should have another OpenJDK Core Libraries Forum this week, 
> so (drumroll) it's time again on Friday, for the
> 
> 	OpenJDK Forum
> 
> Date/Time: Friday May 29th, 8 AM Pacific, 1600 GMT, 5 PM Germany
> 
> Subject: Core libraries round table

Hi everyone,

a recording of the call in the Ogg Vorbis format is available at
http://mediacast.sun.com/users/robilad/media/openjdk-forum-3.ogg/details

Other formats are coming later tonight.

cheers,
dalibor topic
-- 
*******************************************************************
Dalibor Topic                   Tel: (+49 40) 23 646 738
Java F/OSS Ambassador           AIM: robiladonaim
Sun Microsystems GmbH           Mobile: (+49 177) 2664 192
Nagelsweg 55                    http://openjdk.java.net
D-20097 Hamburg                 mailto:Dalibor.Topic at sun.com
Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht M?nchen: HRB 161028
Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin H?ring




From jonathan.gibbons at sun.com  Fri May 29 23:35:30 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Fri, 29 May 2009 23:35:30 +0000
Subject: hg: jdk7/tl/jdk: 6838199: remove support for old javap
Message-ID: <20090529233553.202B7EDD1@hg.openjdk.java.net>

Changeset: aece9096d5cd
Author:    jjg
Date:      2009-05-29 16:27 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/aece9096d5cd

6838199: remove support for old javap
Reviewed-by: ohair, mcimadamore

! make/common/Release.gmk
! make/common/internal/Defs-langtools.gmk
! make/launchers/Makefile



From xueming.shen at sun.com  Fri May 29 23:44:03 2009
From: xueming.shen at sun.com (xueming.shen at sun.com)
Date: Fri, 29 May 2009 23:44:03 +0000
Subject: hg: jdk7/tl/jdk: 6808625: Incomplete code sample in Deflater javadoc
Message-ID: <20090529234421.109E7EDD6@hg.openjdk.java.net>

Changeset: d26c268597ed
Author:    sherman
Date:      2009-05-29 16:34 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d26c268597ed

6808625: Incomplete code sample in Deflater javadoc
Summary: added compresser.end() into example
Reviewed-by: martin

! src/share/classes/java/util/zip/Deflater.java



From jonathan.gibbons at sun.com  Sat May 30 03:53:32 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Fri, 29 May 2009 20:53:32 -0700
Subject: hg: jdk7/tl/langtools: 6838199: remove support for old javap
Message-ID: <20090530035334.3EED9EDF5@hg.openjdk.java.net>

Changeset: 47cf04bb80c9
Author:    jjg
Date:      2009-05-29 16:26 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/47cf04bb80c9

6838199: remove support for old javap
Reviewed-by: ohair, mcimadamore

! make/build.xml
! src/share/classes/com/sun/tools/javap/JavapTask.java
! src/share/classes/com/sun/tools/javap/Main.java
! src/share/classes/com/sun/tools/javap/resources/javap.properties
- src/share/classes/sun/tools/javap/AttrData.java
- src/share/classes/sun/tools/javap/CPX.java
- src/share/classes/sun/tools/javap/CPX2.java
- src/share/classes/sun/tools/javap/ClassData.java
- src/share/classes/sun/tools/javap/Constants.java
- src/share/classes/sun/tools/javap/FieldData.java
- src/share/classes/sun/tools/javap/InnerClassData.java
- src/share/classes/sun/tools/javap/JavapEnvironment.java
- src/share/classes/sun/tools/javap/JavapPrinter.java
- src/share/classes/sun/tools/javap/LineNumData.java
- src/share/classes/sun/tools/javap/LocVarData.java
- src/share/classes/sun/tools/javap/Main.java
- src/share/classes/sun/tools/javap/MethodData.java
- src/share/classes/sun/tools/javap/RuntimeConstants.java
- src/share/classes/sun/tools/javap/StackMapData.java
- src/share/classes/sun/tools/javap/StackMapTableData.java
- src/share/classes/sun/tools/javap/Tables.java
- src/share/classes/sun/tools/javap/TrapData.java
- src/share/classes/sun/tools/javap/TypeSignature.java
! test/tools/javap/ExtPath.java
- test/tools/javap/ListTest.java
- test/tools/javap/OptionTest.java



From martinrb at google.com  Sat May 30 17:51:25 2009
From: martinrb at google.com (Martin Buchholz)
Date: Sat, 30 May 2009 10:51:25 -0700
Subject: Review request for 5049299
In-Reply-To: <1ccfd1c10905241809m10ded53bpb4c9360f76b36888@mail.gmail.com>
References: <4A1678DB.9010209@sun.com>
	<1ccfd1c10905221230u6f085d6eu26e0c516784e81ee@mail.gmail.com>
	<4A172398.9000100@sun.com>
	<1ccfd1c10905221757t30a7f610jd343084e50ec88bb@mail.gmail.com>
	<4A17B3BB.4090706@redhat.com>
	<1ccfd1c10905231112k61d8e13h31f693951ed91b76@mail.gmail.com>
	<4A1849CD.3060306@redhat.com>
	<1ccfd1c10905231810k17a99cd3vfa68d6108e28b46@mail.gmail.com>
	<4A191063.5060401@redhat.com>
	<1ccfd1c10905241809m10ded53bpb4c9360f76b36888@mail.gmail.com>
Message-ID: <1ccfd1c10905301051j527d2e91m217020d037ac1732@mail.gmail.com>

I have a prototype implementation that works only for Linux,
only when the environment is inherited,
but seems to show that the clone/fork approach works.

The main idea is that passing these flags:
CLONE_VM | SIGCHLD
to clone() appears to work.
Passing CLONE_VFORK in addition also seems to work,
and may be more reliable.

Michael, we will need to coordinate to come up with
something that will work for all our Unices.

Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090530/d4f8547d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: clone-exec
Type: application/octet-stream
Size: 10485 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090530/d4f8547d/clone-exec.obj>