From joe.darcy at oracle.com Fri Apr 1 02:11:37 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 01 Apr 2011 02:11:37 +0000 Subject: hg: jdk7/tl/jdk: 7005628: Clarify NPE behavior of Throwable.addSuppressed(null) Message-ID: <20110401021209.1D8834769E@hg.openjdk.java.net> Changeset: 856cc9e97aea Author: darcy Date: 2011-03-31 19:09 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/856cc9e97aea 7005628: Clarify NPE behavior of Throwable.addSuppressed(null) Reviewed-by: dholmes, mchung, jjb ! src/share/classes/java/lang/ArithmeticException.java ! src/share/classes/java/lang/NullPointerException.java ! src/share/classes/java/lang/OutOfMemoryError.java ! src/share/classes/java/lang/Throwable.java ! test/java/lang/Throwable/SuppressedExceptions.java From maurizio.cimadamore at oracle.com Fri Apr 1 11:31:32 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 01 Apr 2011 11:31:32 +0000 Subject: hg: jdk7/tl/langtools: 7032633: javac -Xlint:all warns about flush() within try on an auto-closeable resource Message-ID: <20110401113139.6DBBC476C4@hg.openjdk.java.net> Changeset: b945b846c979 Author: mcimadamore Date: 2011-04-01 12:30 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/b945b846c979 7032633: javac -Xlint:all warns about flush() within try on an auto-closeable resource Summary: missing name check before calling MethodSymbol.overrides causes wrong warnings to be issued Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/TryWithResources/T7032633.java From neil.richards at ngmr.net Fri Apr 1 16:42:57 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Fri, 01 Apr 2011 09:42:57 -0700 Subject: Suspected regression: fix for 6735255 causes delay in GC of ZipFile InputStreams, increase in heap demand In-Reply-To: <4D93930A.2000604@oracle.com> References: <1300916786.4515.107.camel@chalkhill> <4D922D68.2080202@oracle.com> <1301514810.24605.64.camel@chalkhill> <4D93930A.2000604@oracle.com> Message-ID: <1301676177.24605.165.camel@chalkhill> On Wed, 2011-03-30 at 13:31 -0700, Xueming Shen wrote: > Isn't it true that when the finalize()->close() gets invoked, there > should be no strong reference anywhere else that you can use to invoke > close() in other thread? It's true that once finalize() has been called, there can't be another explicit call to close(). However, if close() is explicitly called first, it will be called again when finalize() calls it, so one still wants the update to 'isClosed' to be seen by the finalizer thread (in this case). > ZipFileInputStream class has to sync on ZipFile.this, the read/close() > methods are accessing the underlying/shared bits of the ZipFile. For > ZipFileInflaterInputStream.close() case, even we want to make sure the > isClose is synced, I would prefer to see a "local" lock, maybe simply > make close() synchronized is better? After assessing it again, I tend to agree - synchronizing on the ZFIIS (instead of the ZipFile) now looks to me to be safe because it does not do anything which synchronizes on the ZipFile object. (Note that if it _did_ cause such synchronization, it would risk deadlock with the code in ZipFile's close() method, which is synchronized on itself when it calls close() on each remaining ZFIIS. It's the difference in the order of acquiring the monitors that would cause the potential for deadlock). As it is, both close() methods synchronize on the 'inflaters' object within their respective synchronized blocks, but that does not risk deadlock. Please find below an updated changeset below, containing the suggested change to synchronization. Thanks once again for your suggestions, Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU # HG changeset patch # User Neil Richards , # Date 1300289208 0 # Branch zip-heap # Node ID 4aa4844cd3b9ae747ad736469134a8828ebeb652 # Parent 554adcfb615e63e62af530b1c10fcf7813a75b26 7031076: Retained ZipFile InputStreams increase heap demand Summary: Allow unreferenced ZipFile InputStreams to be finalized, GC'd Contributed-by: diff --git a/src/share/classes/java/util/zip/ZipFile.java b/src/share/classes/java/util/zip/ZipFile.java --- a/src/share/classes/java/util/zip/ZipFile.java +++ b/src/share/classes/java/util/zip/ZipFile.java @@ -30,11 +30,14 @@ import java.io.IOException; import java.io.EOFException; import java.io.File; +import java.lang.ref.ReferenceQueue; +import java.lang.ref.WeakReference; import java.nio.charset.Charset; import java.util.Vector; import java.util.Enumeration; import java.util.Set; import java.util.HashSet; +import java.util.Iterator; import java.util.NoSuchElementException; import java.security.AccessController; import sun.security.action.GetPropertyAction; @@ -315,7 +318,16 @@ private static native void freeEntry(long jzfile, long jzentry); // the outstanding inputstreams that need to be closed. - private Set streams = new HashSet<>(); + private final Set> streams = new HashSet<>(); + private final ReferenceQueue staleStreamQueue = + new ReferenceQueue<>(); + + private void clearStaleStreams() { + Object staleStream; + while (null != (staleStream = staleStreamQueue.poll())) { + streams.remove(staleStream); + } + } /** * Returns an input stream for reading the contents of the specified @@ -339,6 +351,7 @@ ZipFileInputStream in = null; synchronized (this) { ensureOpen(); + clearStaleStreams(); if (!zc.isUTF8() && (entry.flag & EFS) != 0) { jzentry = getEntry(jzfile, zc.getBytesUTF8(entry.name), false); } else { @@ -351,51 +364,19 @@ switch (getEntryMethod(jzentry)) { case STORED: - streams.add(in); + streams.add( + new WeakReference(in, staleStreamQueue)); return in; case DEFLATED: - final ZipFileInputStream zfin = in; // MORE: Compute good size for inflater stream: long size = getEntrySize(jzentry) + 2; // Inflater likes a bit of slack if (size > 65536) size = 8192; if (size <= 0) size = 4096; - InputStream is = new InflaterInputStream(zfin, getInflater(), (int)size) { - private boolean isClosed = false; - - public void close() throws IOException { - if (!isClosed) { - super.close(); - releaseInflater(inf); - isClosed = true; - } - } - // Override fill() method to provide an extra "dummy" byte - // at the end of the input stream. This is required when - // using the "nowrap" Inflater option. - protected void fill() throws IOException { - if (eof) { - throw new EOFException( - "Unexpected end of ZLIB input stream"); - } - len = this.in.read(buf, 0, buf.length); - if (len == -1) { - buf[0] = 0; - len = 1; - eof = true; - } - inf.setInput(buf, 0, len); - } - private boolean eof; - - public int available() throws IOException { - if (isClosed) - return 0; - long avail = zfin.size() - inf.getBytesWritten(); - return avail > (long) Integer.MAX_VALUE ? - Integer.MAX_VALUE : (int) avail; - } - }; - streams.add(is); + InputStream is = + new ZipFileInflaterInputStream(in, getInflater(), + (int)size); + streams.add( + new WeakReference(is, staleStreamQueue)); return is; default: throw new ZipException("invalid compression method"); @@ -403,6 +384,56 @@ } } + private class ZipFileInflaterInputStream extends InflaterInputStream { + private boolean isClosed = false; + private boolean eof = false; + private final ZipFileInputStream zfin; + private boolean inFinalizer = false; + + ZipFileInflaterInputStream(ZipFileInputStream zfin, Inflater inf, + int size) { + super(zfin, inf, size); + this.zfin = zfin; + } + + public synchronized void close() throws IOException { + if (!isClosed) { + super.close(); + if (false == inFinalizer) + releaseInflater(inf); + isClosed = true; + } + } + // Override fill() method to provide an extra "dummy" byte + // at the end of the input stream. This is required when + // using the "nowrap" Inflater option. + protected void fill() throws IOException { + if (eof) { + throw new EOFException("Unexpected end of ZLIB input stream"); + } + len = in.read(buf, 0, buf.length); + if (len == -1) { + buf[0] = 0; + len = 1; + eof = true; + } + inf.setInput(buf, 0, len); + } + + public int available() throws IOException { + if (isClosed) + return 0; + long avail = zfin.size() - inf.getBytesWritten(); + return (avail > (long) Integer.MAX_VALUE ? + Integer.MAX_VALUE : (int) avail); + } + + protected void finalize() throws IOException { + inFinalizer = true; + close(); + } + } + /* * Gets an inflater from the list of available inflaters or allocates * a new one. @@ -543,11 +574,14 @@ synchronized (this) { closeRequested = true; - if (streams.size() !=0) { - Set copy = streams; - streams = new HashSet<>(); - for (InputStream is: copy) + Iterator> streamsIterator = + streams.iterator(); + while (streamsIterator.hasNext()) { + InputStream is = streamsIterator.next().get(); + if (null != is) { is.close(); + } + streamsIterator.remove(); } if (jzfile != 0) { @@ -684,9 +718,12 @@ freeEntry(ZipFile.this.jzfile, jzentry); jzentry = 0; } - streams.remove(this); } } + + protected void finalize() { + close(); + } } diff --git a/test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java b/test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java new file mode 100644 --- /dev/null +++ b/test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java @@ -0,0 +1,148 @@ +/* + * Copyright (c) 2011 Oracle and/or its affiliates. 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 Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/* + * Portions Copyright (c) 2011 IBM Corporation + */ + +/* + * @test + * @bug 7031076 + * @summary Allow stale InputStreams from ZipFiles to be GC'd + * @author Neil Richards , + */ +import java.lang.ref.ReferenceQueue; +import java.lang.ref.WeakReference; +import java.io.File; +import java.io.FileOutputStream; +import java.io.InputStream; +import java.util.Enumeration; +import java.util.HashSet; +import java.util.Random; +import java.util.Set; +import java.util.zip.ZipEntry; +import java.util.zip.ZipFile; +import java.util.zip.ZipOutputStream; + +public class ClearStaleZipFileInputStreams { + private static final int ZIP_ENTRY_NUM = 5; + + private static final byte[][] data; + + static { + data = new byte[ZIP_ENTRY_NUM][]; + Random r = new Random(); + for (int i = 0; i < ZIP_ENTRY_NUM; i++) { + data[i] = new byte[1000]; + r.nextBytes(data[i]); + } + } + + private static File createTestFile(int compression) throws Exception { + File tempZipFile = + File.createTempFile("test-data" + compression, ".zip"); + tempZipFile.deleteOnExit(); + + ZipOutputStream zos = + new ZipOutputStream(new FileOutputStream(tempZipFile)); + zos.setLevel(compression); + + try { + for (int i = 0; i < ZIP_ENTRY_NUM; i++) { + String text = "Entry" + i; + ZipEntry entry = new ZipEntry(text); + zos.putNextEntry(entry); + try { + zos.write(data[i], 0, data[i].length); + } finally { + zos.closeEntry(); + } + } + } finally { + zos.close(); + } + + return tempZipFile; + } + + private static void startGcInducingThread(final int sleepMillis) { + final Thread gcInducingThread = new Thread() { + public void run() { + while (true) { + System.gc(); + try { + Thread.sleep(sleepMillis); + } catch (InterruptedException e) { } + } + } + }; + + gcInducingThread.setDaemon(true); + gcInducingThread.start(); + } + + public static void main(String[] args) throws Exception { + startGcInducingThread(500); + runTest(ZipOutputStream.DEFLATED); + runTest(ZipOutputStream.STORED); + } + + private static void runTest(int compression) throws Exception { + ReferenceQueue rq = new ReferenceQueue<>(); + + System.out.println("Testing with a zip file with compression level = " + + compression); + File f = createTestFile(compression); + try { + ZipFile zf = new ZipFile(f); + try { + Set refSet = createTransientInputStreams(zf, rq); + + System.out.println("Waiting for 'stale' input streams from ZipFile to be GC'd ..."); + System.out.println("(The test will hang on failure)"); + while (false == refSet.isEmpty()) { + refSet.remove(rq.remove()); + } + System.out.println("Test PASSED."); + System.out.println(); + } finally { + zf.close(); + } + } finally { + f.delete(); + } + } + + private static Set createTransientInputStreams(ZipFile zf, + ReferenceQueue rq) throws Exception { + Enumeration zfe = zf.entries(); + Set refSet = new HashSet<>(); + + while (zfe.hasMoreElements()) { + InputStream is = zf.getInputStream(zfe.nextElement()); + refSet.add(new WeakReference(is, rq)); + } + + return refSet; + } +} From lana.steuck at oracle.com Fri Apr 1 17:19:03 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 01 Apr 2011 17:19:03 +0000 Subject: hg: jdk7/tl: 7 new changesets Message-ID: <20110401171904.34E14476D5@hg.openjdk.java.net> Changeset: b87875789600 Author: ohair Date: 2011-03-22 08:15 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/b87875789600 6896934: README: Document how the drop source bundles work for jaxp/jaxws 6896978: README: Updates to openjdk README-builds.html 6903517: README: OpenJDK additions needed - cygwin issues Reviewed-by: dholmes ! README ! README-builds.html Changeset: 783bd02b4ab4 Author: cl Date: 2011-03-23 17:43 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/783bd02b4ab4 Merge Changeset: e97f037142f5 Author: schien Date: 2011-03-24 11:20 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/e97f037142f5 Added tag jdk7-b135 for changeset 783bd02b4ab4 ! .hgtags Changeset: dada8003df87 Author: dholmes Date: 2011-03-28 00:50 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/rev/dada8003df87 7030131: Update README-builds.html to cover changes introduced by SE-Embedded integration Reviewed-by: ohair ! README-builds.html Changeset: 2fe76e73adaa Author: ohair Date: 2011-03-29 18:17 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/2fe76e73adaa Merge Changeset: 7654afc6a29e Author: schien Date: 2011-03-31 18:13 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/7654afc6a29e Added tag jdk7-b136 for changeset 2fe76e73adaa ! .hgtags Changeset: 1527f425ee22 Author: lana Date: 2011-03-31 21:49 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/1527f425ee22 Merge From lana.steuck at oracle.com Fri Apr 1 17:18:58 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 01 Apr 2011 17:18:58 +0000 Subject: hg: jdk7/tl/corba: 2 new changesets Message-ID: <20110401171904.26019476D4@hg.openjdk.java.net> Changeset: 48ef0c712e7c Author: schien Date: 2011-03-24 11:20 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/48ef0c712e7c Added tag jdk7-b135 for changeset e0b72ae5dc5e ! .hgtags Changeset: a66c01d8bf89 Author: schien Date: 2011-03-31 18:13 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/a66c01d8bf89 Added tag jdk7-b136 for changeset 48ef0c712e7c ! .hgtags From lana.steuck at oracle.com Fri Apr 1 17:19:06 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 01 Apr 2011 17:19:06 +0000 Subject: hg: jdk7/tl/jaxws: 2 new changesets Message-ID: <20110401171907.0639D476D6@hg.openjdk.java.net> Changeset: c81d289c9a53 Author: schien Date: 2011-03-24 11:20 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/c81d289c9a53 Added tag jdk7-b135 for changeset d5fc61f18043 ! .hgtags Changeset: ccea3282991c Author: schien Date: 2011-03-31 18:14 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/ccea3282991c Added tag jdk7-b136 for changeset c81d289c9a53 ! .hgtags From lana.steuck at oracle.com Fri Apr 1 17:19:09 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 01 Apr 2011 17:19:09 +0000 Subject: hg: jdk7/tl/jaxp: 2 new changesets Message-ID: <20110401171909.8E332476D7@hg.openjdk.java.net> Changeset: 1759daa85d33 Author: schien Date: 2011-03-24 11:20 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/1759daa85d33 Added tag jdk7-b135 for changeset 4aa9916693dc ! .hgtags Changeset: 1d87f7460cde Author: schien Date: 2011-03-31 18:14 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/1d87f7460cde Added tag jdk7-b136 for changeset 1759daa85d33 ! .hgtags From lana.steuck at oracle.com Fri Apr 1 17:19:18 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 01 Apr 2011 17:19:18 +0000 Subject: hg: jdk7/tl/langtools: 5 new changesets Message-ID: <20110401171928.93144476D8@hg.openjdk.java.net> Changeset: 028248b9a397 Author: schien Date: 2011-03-24 11:20 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/028248b9a397 Added tag jdk7-b135 for changeset 9d0a61ac567b ! .hgtags Changeset: ed0f7f1f9511 Author: lana Date: 2011-03-26 00:11 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/ed0f7f1f9511 Merge Changeset: a15c9b058ae0 Author: schien Date: 2011-03-31 18:14 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a15c9b058ae0 Added tag jdk7-b136 for changeset ed0f7f1f9511 ! .hgtags Changeset: 28570a737e83 Author: lana Date: 2011-03-31 22:08 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/28570a737e83 Merge Changeset: d0b5026ec7ca Author: lana Date: 2011-04-01 10:17 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d0b5026ec7ca Merge From lana.steuck at oracle.com Fri Apr 1 17:19:28 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 01 Apr 2011 17:19:28 +0000 Subject: hg: jdk7/tl/hotspot: 61 new changesets Message-ID: <20110401172116.D67F2476D9@hg.openjdk.java.net> Changeset: 9f44e9aad2d9 Author: coleenp Date: 2011-03-03 19:51 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9f44e9aad2d9 7022999: Can't build with FORCE_TIERED=0 Summary: Put UseFastLocking test under #ifdef COMPILER1 Reviewed-by: kvn, phh, never, dcubed ! src/share/vm/runtime/arguments.cpp Changeset: fbbeec6dad2d Author: coleenp Date: 2011-03-03 19:52 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/fbbeec6dad2d 6512830: Error: assert(tag_at(which).is_unresolved_klass(), "Corrupted constant pool") Summary: Redefine classes copies the constant pool while the constant pool may be resolving strings or classes Reviewed-by: dcubed, dsamersoff, acorn ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: f767174aac14 Author: coleenp Date: 2011-03-03 19:53 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f767174aac14 7021653: Parfait issue in hotspot/src/share/vm/oops/methodDataOops.hpp Summary: Fix compilation error(s) Reviewed-by: kvn, phh, jcoomes, dholmes ! src/share/vm/oops/methodDataOop.hpp ! src/share/vm/runtime/os.cpp Changeset: dbad0519a1c4 Author: kamg Date: 2011-03-04 14:40 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/dbad0519a1c4 6845426: non-static method with no args is called during the class initialization process Summary: Only call with ACC_STATIC for classfiles with version > 50 Reviewed-by: acorn, dholmes, coleenp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp Changeset: 0cd0a06d2535 Author: acorn Date: 2011-03-07 09:16 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0cd0a06d2535 Merge ! src/share/vm/runtime/arguments.cpp Changeset: df1347358fe6 Author: coleenp Date: 2011-03-07 16:03 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/df1347358fe6 7024584: Symbol printouts shouldnt be under PrintGCDetails Summary: Put symbol printing under Verbose and WizardMode so you can get this information if you really want it. Reviewed-by: phh, stefank, never, dholmes, jcoomes ! src/share/vm/classfile/symbolTable.cpp Changeset: 02e6fc2effd8 Author: trims Date: 2011-03-11 22:41 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/02e6fc2effd8 Merge Changeset: 4f148718983e Author: bdelsart Date: 2011-03-10 17:44 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4f148718983e 7025485: leverage shared x86-only deoptimization code Summary: removed an ifdef IA32 around harmless code useful for some ports Reviewed-by: chrisphi, never ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/deoptimization.hpp Changeset: 3d5a546351ef Author: phh Date: 2011-03-11 16:09 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3d5a546351ef 7023931: PcDescCache::find_pc_desc should not write _last_pc_desc Summary: Remove _last_pc_desc and use pcdescs[0] instead. Reviewed-by: dcubed, coleenp, ysr ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp Changeset: 4775a1e3e923 Author: acorn Date: 2011-03-14 11:43 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4775a1e3e923 Merge Changeset: 216d916d5c12 Author: dcubed Date: 2011-03-15 06:35 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/216d916d5c12 7024234: 2/3 jvmti tests fail assert(!_oops_are_stale) failed: oops are stale on Win-AMD64 Summary: Move initialization of the '_instance' field to avoid race with ServiceThread start. Reviewed-by: dholmes, kamg, never, dsamersoff, ysr, coleenp, acorn ! src/share/vm/runtime/serviceThread.cpp Changeset: 46a56fac55c7 Author: dcubed Date: 2011-03-15 06:37 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/46a56fac55c7 7024970: 2/3 assert(ServiceThread::is_service_thread(Thread::current())) failed: Service thread must post enqueue Summary: Change nmethod_lock() to also prevent zombification of the nmethod. CompiledMethodUnload events also need to lock the nmethod. Clean ups in nmethod::make_not_entrant_or_zombie() Reviewed-by: dholmes, kamg, never, dsamersoff, ysr, coleenp, acorn ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp Changeset: 65f880e2869b Author: dcubed Date: 2011-03-15 06:50 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/65f880e2869b Merge ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp Changeset: 8a3f8defe568 Author: coleenp Date: 2011-03-16 14:57 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8a3f8defe568 7019165: Incorrect symbols in pstack output after SymbolTable changes Summary: And out lsb which is set for symbols in constant pool slots to distinguish them from strings Reviewed-by: phh, dholmes, never, dcubed ! src/os/solaris/dtrace/libjvm_db.c Changeset: b9684d5ccb52 Author: vladidan Date: 2011-03-10 14:56 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b9684d5ccb52 7011490: Wrong computation results in Test6880034 Summary: incorrect handling of c2i deoptimization on little endian architectures Reviewed-by: never ! src/share/vm/c1/c1_LinearScan.cpp Changeset: bc57bfb5bfad Author: vladidan Date: 2011-03-16 10:47 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/bc57bfb5bfad Merge Changeset: 2074c95f707e Author: vladidan Date: 2011-03-16 23:45 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2074c95f707e Merge Changeset: 5d8f5a6dced7 Author: iveresov Date: 2011-03-04 15:14 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5d8f5a6dced7 7020403: Add AdvancedCompilationPolicy for tiered Summary: This implements adaptive tiered compilation policy. Reviewed-by: kvn, never ! src/share/vm/oops/methodKlass.cpp ! src/share/vm/oops/methodOop.hpp + src/share/vm/runtime/advancedThresholdPolicy.cpp + src/share/vm/runtime/advancedThresholdPolicy.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/compilationPolicy.cpp Changeset: 4cd9add59b1e Author: never Date: 2011-03-04 20:01 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4cd9add59b1e 7024866: # assert(limit == NULL || limit <= nm->code_end()) failed: in bounds Reviewed-by: kvn, iveresov ! src/share/vm/code/nmethod.cpp Changeset: 8ec5e1f45ea1 Author: never Date: 2011-03-04 22:44 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8ec5e1f45ea1 Merge Changeset: 8e72cd29b15d Author: kvn Date: 2011-03-05 11:02 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8e72cd29b15d 6589823: Error: meet not symmetric Summary: arrays pointers meet must fall to bottom if exact array klasses in upper lattice are not equal or super klass is exact. Reviewed-by: never ! src/share/vm/opto/type.cpp Changeset: 425688247f3d Author: never Date: 2011-03-06 22:09 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/425688247f3d 6965570: assert(!needs_patching && x->is_loaded(),"how do we know it's volatile if it's not loaded") Reviewed-by: iveresov ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_ValueMap.hpp Changeset: 1c0cf339481b Author: kvn Date: 2011-03-09 09:15 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1c0cf339481b 7025742: Can not use CodeCache::unallocated_capacity() with fragmented CodeCache Summary: Use largest_free_block() instead of unallocated_capacity(). Reviewed-by: iveresov, never, ysr ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/memory/heap.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/runtime/sweeper.cpp Changeset: 83f08886981c Author: kvn Date: 2011-03-11 07:50 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/83f08886981c 7026631: field _klass is incorrectly set for dual type of TypeAryPtr::OOPS Summary: add missing check this->dual() != TypeAryPtr::OOPS into TypeAryPtr::klass(). Reviewed-by: never ! src/share/vm/opto/type.cpp Changeset: 799d8ccf63cf Author: jrose Date: 2011-03-11 21:19 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/799d8ccf63cf Merge ! src/share/vm/oops/methodOop.hpp ! src/share/vm/runtime/arguments.cpp Changeset: 72dee110246f Author: jrose Date: 2011-03-11 22:33 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/72dee110246f 6839872: remove implementation inheritance from JSR 292 APIs Summary: consolidate runtime support in java.dyn.MethodHandleNatives; include transitional compatibility logic Reviewed-by: twisti ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/runtime/globals.hpp Changeset: 8033953d67ff Author: jrose Date: 2011-03-11 22:34 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8033953d67ff 7012648: move JSR 292 to package java.lang.invoke and adjust names Summary: package and class renaming only; delete unused methods and classes Reviewed-by: twisti ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/interpreter_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! 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/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/ci/ciCallSite.cpp ! src/share/vm/ci/ciCallSite.hpp ! src/share/vm/ci/ciField.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethodHandle.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciStreams.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.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/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/prims/nativeLookup.cpp Changeset: 82de9bd880e3 Author: kvn Date: 2011-03-17 12:08 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/82de9bd880e3 7028394: Newer AMD Processor Prefetch Defaults Summary: This new default has shown improvement across many workloads. Reviewed-by: kvn Contributed-by: tom.deneau at amd.com ! src/cpu/x86/vm/vm_version_x86.cpp Changeset: d2134498fd3f Author: jrose Date: 2011-03-17 18:29 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/d2134498fd3f 7011865: JSR 292 CTW fails: !THREAD->is_Compiler_thread() failed: Can not load classes with the Compiler thre Reviewed-by: kvn, never ! src/share/vm/interpreter/linkResolver.cpp Changeset: fc5ebbb2d1a8 Author: twisti Date: 2011-03-18 01:44 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/fc5ebbb2d1a8 Merge ! src/share/vm/code/nmethod.cpp Changeset: 1216415d8e35 Author: tonyp Date: 2011-03-04 17:13 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1216415d8e35 7014923: G1: code cleanup Summary: Some G1 code cleanup. Reviewed-by: johnc, jcoomes, jwilhelm ! 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/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp ! src/share/vm/gc_implementation/g1/heapRegionSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSet.inline.hpp ! src/share/vm/gc_implementation/g1/heapRegionSets.cpp ! src/share/vm/utilities/debug.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: a2c2eac1ca62 Author: jcoomes Date: 2011-03-06 11:37 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a2c2eac1ca62 7018056: large pages not always enabled by default Reviewed-by: phh, kvn ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/globals.hpp Changeset: c93aa6caa02f Author: brutisso Date: 2011-03-03 22:58 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c93aa6caa02f 7022943: G1: improve logging to avoid interleaved numbers Summary: Introduced buffered loggging to make sure that log lines are logged one line at a time Reviewed-by: stefank, johnc, dsamersoff ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp Changeset: 04d1138b4cce Author: brutisso Date: 2011-03-03 11:35 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/04d1138b4cce 7023747: G1: too strict assert in RefineRecordRefsIntoCSCardTableEntryClosure::do_card_ptr in g1RemSet.cpp Summary: Made sure that the assert looks at ParallelGCThreads. Reviewed-by: stefank, tonyp, jwilhelm, johnc ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp Changeset: a181f3a124dd Author: ysr Date: 2011-03-14 21:52 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a181f3a124dd 6987703: iCMS: Intermittent hang with gc/gctests/CallGC/CallGC01 and +ExplicitGCInvokesConcurrent Summary: Count enable_icms() and disable_icms() events so as to prevent inteference between concurrent calls, which can cause the iCMS thread to be left stranded in icms_wait() with an unserviced request and no young allocations to unwedge it. Reviewed-by: jcoomes, poonam ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.hpp Changeset: 1fb790245268 Author: jwilhelm Date: 2011-03-11 16:35 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1fb790245268 6820066: Check that -XX:ParGCArrayScanChunk has a value larger than zero. Summary: Check that -XX:ParGCArrayScanChunk has a value larger than zero. Reviewed-by: johnc, jmasa, ysr ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 1abd292f8c38 Author: jwilhelm Date: 2011-03-15 09:07 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1abd292f8c38 Merge Changeset: dde920245681 Author: ysr Date: 2011-03-16 10:37 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/dde920245681 6896099: Integrate CMS heap ergo with default heap sizing ergo 6627787: CMS: JVM refuses to start up with -Xms16m -Xmx16m 7000125: CMS: Anti-monotone young gen sizing with respect to maximum whole heap size specification 7027529: CMS: retire CMSUseOldDefaults flag Summary: Simplify CMS heap sizing code, relying on ergonomic initial sizing consistent with other collectors for the most part, controlling only young gen sizing to rein in pause times. Make CMS young gen sizing default statically cpu-dependant. Remove inconsistencies wrt generation sizing and policy code, allowing for the fixing for 6627787 and 7000125. For 7027529, retire the flag CMSUseOldDefaults which had been introduced as a bridge from JDK 5 to JDK 6 a number of years ago. Reviewed-by: brutisso, poonam ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 92da084fefc9 Author: ysr Date: 2011-03-17 10:32 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/92da084fefc9 6668573: CMS: reference processing crash if ParallelCMSThreads > ParallelGCThreads Summary: Use _max_num_q = max(discovery_degree, processing_degree), and let balance_queues() redistribute from discovery_degree to processing_degree of queues. This should also allow a more dynamic and flexible parallelism policy in the future. Reviewed-by: jmasa, johnc ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/memory/generation.cpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/utilities/workgroup.cpp ! src/share/vm/utilities/workgroup.hpp Changeset: 048f98400b8e Author: jcoomes Date: 2011-03-18 09:03 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/048f98400b8e Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: e97ad5d5c990 Author: trims Date: 2011-03-18 13:28 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e97ad5d5c990 Merge Changeset: b898f0fc3ced Author: trims Date: 2011-03-18 13:28 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b898f0fc3ced 7028846: Bump the HS21 build number to 05 Summary: Update the HS21 build number to 05 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 7449da4cdab5 Author: schien Date: 2011-03-24 11:20 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7449da4cdab5 Added tag jdk7-b135 for changeset b898f0fc3ced ! .hgtags Changeset: 661c46a8434c Author: trims Date: 2011-03-25 17:26 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/661c46a8434c Added tag hs21-b05 for changeset b898f0fc3ced ! .hgtags Changeset: d673ef06fe96 Author: never Date: 2011-03-18 15:52 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/d673ef06fe96 7028374: race in fix_oop_relocations for scavengeable nmethods Reviewed-by: kvn ! src/cpu/sparc/vm/nativeInst_sparc.cpp ! src/cpu/sparc/vm/nativeInst_sparc.hpp ! src/cpu/sparc/vm/relocInfo_sparc.cpp ! src/cpu/x86/vm/relocInfo_x86.cpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/code/relocInfo.hpp ! src/share/vm/memory/universe.cpp Changeset: c7f3d0b4570f Author: never Date: 2011-03-18 16:00 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c7f3d0b4570f 7017732: move static fields into Class to prepare for perm gen removal Reviewed-by: kvn, coleenp, twisti, stefank ! agent/src/share/classes/sun/jvm/hotspot/jdi/FieldImpl.java ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/IntField.java ! agent/src/share/classes/sun/jvm/hotspot/oops/OopField.java ! agent/src/share/classes/sun/jvm/hotspot/oops/OopUtilities.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! agent/test/jdi/sasanity.sh ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/dump_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/ci/ciCPCache.cpp ! src/share/vm/ci/ciField.cpp ! src/share/vm/ci/ciInstance.cpp ! src/share/vm/ci/ciInstance.hpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/memory/compactingPermGenGen.hpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/arrayKlassKlass.cpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/cpCacheKlass.cpp ! src/share/vm/oops/cpCacheOop.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/instanceKlassKlass.hpp + src/share/vm/oops/instanceMirrorKlass.cpp + src/share/vm/oops/instanceMirrorKlass.hpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/klassKlass.cpp ! src/share/vm/oops/klassOop.hpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/objArrayKlassKlass.cpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/oops/oopsHierarchy.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/shark/sharkNativeWrapper.cpp Changeset: 57552dca1708 Author: never Date: 2011-03-21 14:06 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/57552dca1708 7029509: nightly failures after static fields in Class Reviewed-by: kvn ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/services/heapDumper.cpp Changeset: 924777755fad Author: jcoomes Date: 2011-03-21 18:38 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/924777755fad 6962930: make the string table size configurable Reviewed-by: never, phh, stefank, kamg, dholmes, coleenp ! agent/src/share/classes/sun/jvm/hotspot/memory/StringTable.java ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: b099aaf51bf8 Author: jcoomes Date: 2011-03-22 13:36 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b099aaf51bf8 6962931: move interned strings out of the perm gen Reviewed-by: never, coleenp, ysr, jwilhelm ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp ! src/share/vm/memory/dump.cpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/stringopts.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/runtime/globals.hpp Changeset: 32f7097f9d8f Author: never Date: 2011-03-23 10:55 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/32f7097f9d8f 7030300: more nightly failures after statics in Class changes Reviewed-by: iveresov, jcoomes, dcubed ! agent/src/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp Changeset: f195ebb181b8 Author: jcoomes Date: 2011-03-24 23:00 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f195ebb181b8 Merge Changeset: 3ef1a1866a60 Author: twisti Date: 2011-03-21 02:30 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3ef1a1866a60 7027232: JSR 292: wrong numeric value returned by MH on solaris-sparc Reviewed-by: kvn, never ! src/cpu/sparc/vm/methodHandles_sparc.cpp Changeset: 9dc311b8473e Author: kvn Date: 2011-03-21 11:28 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9dc311b8473e 7008866: Missing loop predicate for loop with multiple entries Summary: Add predicates when loop head bytecode is parsed instead of when back branch bytecode is parsed. Reviewed-by: never ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/idealKit.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopUnswitch.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/stringopts.cpp Changeset: 0a5d9566b8a4 Author: twisti Date: 2011-03-23 04:19 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0a5d9566b8a4 7029805: JSR 292 compiler/6991596/Test6991596.java fails in nightly Summary: Both JSR 292 compiler tests were moved with 6839872 to the jdk repository Reviewed-by: never - test/compiler/6987555/Test6987555.java - test/compiler/6991596/Test6991596.java Changeset: 0e3ed5a14f73 Author: jcoomes Date: 2011-03-24 23:04 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0e3ed5a14f73 Merge ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/stringopts.cpp - test/compiler/6987555/Test6987555.java - test/compiler/6991596/Test6991596.java Changeset: 083f13976b51 Author: dholmes Date: 2011-03-21 22:16 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/083f13976b51 6535709: interrupt of wait()ing thread isn't triggerring InterruptedException - test intwait3 Summary: only clear the interrupt state if we will report that it was set Reviewed-by: dcubed, alanb, phh, coleenp, dice ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/osThread.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: fc416c2556ec Author: mchung Date: 2011-03-22 18:04 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/fc416c2556ec 7025628: Remove the temporary hack added for jdk modularization in hotspot Summary: Removed Reviewed-by: ohair, coleenp ! src/share/vm/runtime/os.cpp Changeset: 006b3750a4d4 Author: jcoomes Date: 2011-03-24 23:06 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/006b3750a4d4 Merge ! src/share/vm/runtime/vmStructs.cpp Changeset: c10b82a05d58 Author: trims Date: 2011-03-25 18:04 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c10b82a05d58 Merge - test/compiler/6987555/Test6987555.java - test/compiler/6991596/Test6991596.java Changeset: bd586e392d93 Author: trims Date: 2011-03-25 18:04 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/bd586e392d93 7031227: Bump the HS21 build number to 06 Summary: Update the HS21 build number to 06 Reviewed-by: jcoomes ! make/hotspot_version Changeset: a1615ff22854 Author: schien Date: 2011-03-31 18:14 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a1615ff22854 Added tag jdk7-b136 for changeset bd586e392d93 ! .hgtags From lana.steuck at oracle.com Fri Apr 1 17:22:11 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 01 Apr 2011 17:22:11 +0000 Subject: hg: jdk7/tl/jdk: 56 new changesets Message-ID: <20110401173117.C97A6476DA@hg.openjdk.java.net> Changeset: 1c7cac250f71 Author: asaha Date: 2011-03-21 21:36 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1c7cac250f71 7029704: JFB: Refix JFB Custom Revision Version Build/Makefile changes Reviewed-by: mr, ohair ! make/common/Defs.gmk ! make/common/Release.gmk Changeset: e390396bc938 Author: katakai Date: 2011-02-26 03:53 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e390396bc938 6998391: Serbian (Latin) locale support Reviewed-by: naoto ! make/java/text/base/FILES_java.gmk ! make/java/util/FILES_properties.gmk ! src/share/classes/java/text/SimpleDateFormat.java + src/share/classes/sun/text/resources/CollationData_sr_Latn.java + src/share/classes/sun/text/resources/FormatData_sr_Latn.java + src/share/classes/sun/text/resources/FormatData_sr_Latn_BA.java + src/share/classes/sun/text/resources/FormatData_sr_Latn_ME.java + src/share/classes/sun/text/resources/FormatData_sr_Latn_RS.java + src/share/classes/sun/util/resources/CalendarData_sr_Latn_BA.properties + src/share/classes/sun/util/resources/CalendarData_sr_Latn_ME.properties + src/share/classes/sun/util/resources/CalendarData_sr_Latn_RS.properties + src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_BA.properties + src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_ME.properties + src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_RS.properties ! src/share/classes/sun/util/resources/LocaleData.java + src/share/classes/sun/util/resources/LocaleNames_sr_Latn.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: 0fc1f64bbd73 Author: mfang Date: 2011-03-04 14:31 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0fc1f64bbd73 Merge - src/share/classes/java/dyn/NoAccessException.java - src/share/classes/java/dyn/Switcher.java - test/java/lang/Thread/StopBeforeStart.java Changeset: a574a067d85a Author: mfang Date: 2011-03-05 14:10 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a574a067d85a 7016542: NLS: obsolete resources in MsgAppletViewer.java should be removed Reviewed-by: igor ! src/share/classes/sun/applet/resources/MsgAppletViewer.java Changeset: c3c9fda4591e Author: mfang Date: 2011-03-07 12:08 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c3c9fda4591e 7025267: NLS: t13y fix for 7021689 [ja] Notepad demo throws NPE Reviewed-by: ogino ! src/share/demo/jfc/Notepad/resources/Notepad.properties ! src/share/demo/jfc/Notepad/resources/Notepad_ja.properties ! src/share/demo/jfc/Notepad/resources/Notepad_zh_CN.properties Changeset: 9e4d258ac919 Author: mfang Date: 2011-03-07 12:17 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9e4d258ac919 7021693: [ja, zh_CN] jconsole throws exception and fail to start in ja and zh_CN locales Reviewed-by: ogino ! src/share/classes/sun/tools/jconsole/resources/JConsoleResources_ja.java ! src/share/classes/sun/tools/jconsole/resources/JConsoleResources_zh_CN.java Changeset: abe08bf657e3 Author: mfang Date: 2011-03-07 12:58 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/abe08bf657e3 7025303: NLS: t13y fix for 7021691 Most log level words are not translated in java logging Reviewed-by: yhuang ! src/share/classes/sun/util/logging/resources/logging.properties Changeset: 21737a3e16fb Author: mfang Date: 2011-03-09 14:19 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/21737a3e16fb Merge Changeset: 5ed7b3d84957 Author: yhuang Date: 2011-03-11 05:17 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5ed7b3d84957 7019267: Currency Display Names are not localized into pt_BR. Reviewed-by: naoto ! make/java/util/FILES_properties.gmk + src/share/classes/sun/util/resources/CurrencyNames_pt.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: e64ef0cd99ad Author: yhuang Date: 2011-03-11 05:49 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e64ef0cd99ad Merge Changeset: af4793ab50fb Author: mfang Date: 2011-03-19 19:12 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/af4793ab50fb Merge - make/common/Modules.gmk - make/java/nio/mxbean/Makefile - make/modules/Makefile - make/modules/bootmodule.roots - make/modules/jdk7.depconfig - make/modules/modules.config - make/modules/modules.group - make/modules/optional.depconfig - make/modules/tools/Makefile - make/modules/tools/build.xml - make/modules/tools/nbproject/project.properties - make/modules/tools/nbproject/project.xml - make/modules/tools/src/com/sun/classanalyzer/AnnotatedDependency.java - make/modules/tools/src/com/sun/classanalyzer/AnnotationParser.java - make/modules/tools/src/com/sun/classanalyzer/BootAnalyzer.java - make/modules/tools/src/com/sun/classanalyzer/CheckDeps.java - make/modules/tools/src/com/sun/classanalyzer/ClassAnalyzer.java - make/modules/tools/src/com/sun/classanalyzer/ClassFileParser.java - make/modules/tools/src/com/sun/classanalyzer/ClassPath.java - make/modules/tools/src/com/sun/classanalyzer/CodeAttributeParser.java - make/modules/tools/src/com/sun/classanalyzer/ConstantPoolAnalyzer.java - make/modules/tools/src/com/sun/classanalyzer/ConstantPoolParser.java - make/modules/tools/src/com/sun/classanalyzer/DependencyConfig.java - make/modules/tools/src/com/sun/classanalyzer/Klass.java - make/modules/tools/src/com/sun/classanalyzer/Module.java - make/modules/tools/src/com/sun/classanalyzer/ModuleConfig.java - make/modules/tools/src/com/sun/classanalyzer/ResolutionInfo.java - make/modules/tools/src/com/sun/classanalyzer/ResourceFile.java - make/modules/tools/src/com/sun/classanalyzer/ShowDeps.java - src/share/classes/sun/misc/BootClassLoaderHook.java - src/share/classes/sun/misc/JavaSecurityCodeSignerAccess.java - test/sun/misc/BootClassLoaderHook/TestHook.java Changeset: 258072f4db19 Author: yhuang Date: 2011-03-20 23:47 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/258072f4db19 7020960: CurrencyNames_sr_RS.properties is missing. Reviewed-by: naoto ! make/java/util/FILES_properties.gmk + src/share/classes/sun/util/resources/CurrencyNames_sr_RS.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: f9d15fd48919 Author: mfang Date: 2011-03-21 11:42 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f9d15fd48919 Merge Changeset: d8ced728159f Author: mfang Date: 2011-03-22 12:12 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d8ced728159f Merge Changeset: dbdd618765a8 Author: schien Date: 2011-03-24 11:20 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dbdd618765a8 Added tag jdk7-b135 for changeset d8ced728159f ! .hgtags Changeset: 9f88ef1d373f Author: srl Date: 2011-03-07 17:23 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9f88ef1d373f 7017324: Kerning crash in JDK 7 since ICU layout update Reviewed-by: igor, prr ! src/share/native/sun/font/layout/KernTable.cpp + test/java/awt/font/TextLayout/KernCrash.java Changeset: be2e229513a7 Author: srl Date: 2011-03-07 19:37 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/be2e229513a7 6962082: merge back in lines from bad merge in CR 6501644 and open up a test Reviewed-by: igor, prr ! src/share/native/sun/font/layout/LayoutEngine.cpp + test/java/awt/font/TextLayout/CombiningPerf.java Changeset: 48d97c8653f0 Author: jgodinez Date: 2011-03-08 11:47 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/48d97c8653f0 7020528: closed/java/awt/print/PageFormat/PageFormatFromAttributes.java failed Reviewed-by: igor, prr ! src/windows/native/sun/windows/awt_PrintJob.cpp Changeset: 69ec42543dd9 Author: bae Date: 2011-03-09 13:08 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/69ec42543dd9 7022280: Parfait reports Format string argument mismatch in /jdk/src/solaris/native/sun/awt/awt_GraphicsEnv.c Reviewed-by: jgodinez, prr ! src/solaris/native/sun/awt/awt_GraphicsEnv.c Changeset: 87444344d616 Author: bae Date: 2011-03-10 11:18 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/87444344d616 6710434: PIT: Reg test java/awt/Graphics2D/ClipPrimitivesTest.java fails in pit build 6u10_b26 Reviewed-by: flar, prr ! src/share/native/sun/java2d/loops/ProcessPath.c Changeset: fd8b81c558d3 Author: dlila Date: 2011-03-15 15:15 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fd8b81c558d3 7027667: clipped aa rectangles are not drawn properly. Summary: Already fixed. This is just a regression test for it. Reviewed-by: prr + test/sun/java2d/pipe/Test7027667.java Changeset: 253f3bc64961 Author: dlila Date: 2011-03-15 17:05 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/253f3bc64961 7019861: Last scanline is skipped in pisces.Renderer. Summary: not skipping it anymore. Reviewed-by: flar ! src/share/classes/sun/java2d/pisces/Helpers.java ! src/share/classes/sun/java2d/pisces/PiscesTileGenerator.java ! src/share/classes/sun/java2d/pisces/Renderer.java ! src/share/classes/sun/java2d/pisces/Stroker.java + test/sun/java2d/pisces/Renderer/Test7019861.java Changeset: 5c61c31d2621 Author: bae Date: 2011-03-16 19:21 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5c61c31d2621 6989760: cmm native compiler warnings Reviewed-by: prr, ohair ! make/sun/cmm/kcms/Makefile ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c Changeset: 4450c35a5f90 Author: bae Date: 2011-03-17 17:45 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4450c35a5f90 7014528: ColorModel and SampleModel gotten from the same ImageTypeSpecifier instance can be not compatible Reviewed-by: jgodinez, prr ! src/share/classes/java/awt/image/PackedColorModel.java Changeset: 5371ec6c4f41 Author: lana Date: 2011-03-18 23:33 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5371ec6c4f41 Merge - make/common/Modules.gmk - make/java/nio/mxbean/Makefile - make/modules/Makefile - make/modules/bootmodule.roots - make/modules/jdk7.depconfig - make/modules/modules.config - make/modules/modules.group - make/modules/optional.depconfig - make/modules/tools/Makefile - make/modules/tools/build.xml - make/modules/tools/nbproject/project.properties - make/modules/tools/nbproject/project.xml - make/modules/tools/src/com/sun/classanalyzer/AnnotatedDependency.java - make/modules/tools/src/com/sun/classanalyzer/AnnotationParser.java - make/modules/tools/src/com/sun/classanalyzer/BootAnalyzer.java - make/modules/tools/src/com/sun/classanalyzer/CheckDeps.java - make/modules/tools/src/com/sun/classanalyzer/ClassAnalyzer.java - make/modules/tools/src/com/sun/classanalyzer/ClassFileParser.java - make/modules/tools/src/com/sun/classanalyzer/ClassPath.java - make/modules/tools/src/com/sun/classanalyzer/CodeAttributeParser.java - make/modules/tools/src/com/sun/classanalyzer/ConstantPoolAnalyzer.java - make/modules/tools/src/com/sun/classanalyzer/ConstantPoolParser.java - make/modules/tools/src/com/sun/classanalyzer/DependencyConfig.java - make/modules/tools/src/com/sun/classanalyzer/Klass.java - make/modules/tools/src/com/sun/classanalyzer/Module.java - make/modules/tools/src/com/sun/classanalyzer/ModuleConfig.java - make/modules/tools/src/com/sun/classanalyzer/ResolutionInfo.java - make/modules/tools/src/com/sun/classanalyzer/ResourceFile.java - make/modules/tools/src/com/sun/classanalyzer/ShowDeps.java ! make/sun/cmm/kcms/Makefile - src/share/classes/sun/misc/BootClassLoaderHook.java - src/share/classes/sun/misc/JavaSecurityCodeSignerAccess.java - test/sun/misc/BootClassLoaderHook/TestHook.java Changeset: 38ebd0682a54 Author: dav Date: 2011-03-09 17:29 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/38ebd0682a54 7023019: Constructor of class java.awt.Component.FlipBufferStrategy throws unspecified IAE Reviewed-by: dcherepanov, art ! src/share/classes/java/awt/Component.java Changeset: cb130134aacf Author: dav Date: 2011-03-14 18:57 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cb130134aacf 7022931: GradientPaint class spec clarification: 7022931, 7016391, 7017246, 7019386 Reviewed-by: flar ! src/share/classes/java/awt/LinearGradientPaint.java ! src/share/classes/java/awt/MultipleGradientPaint.java ! src/share/classes/java/awt/RadialGradientPaint.java + src/share/classes/java/awt/doc-files/RadialGradientPaint-3.png + src/share/classes/java/awt/doc-files/RadialGradientPaint-4.png Changeset: 16d75df4a240 Author: dav Date: 2011-03-18 17:56 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/16d75df4a240 7016131: JDK 7 b127: 8 crashes in native frame:awt_DrawingSurface_FreeDrawingSurfaceInfo+0xc on linux amd64 Reviewed-by: dcherepanov, art ! src/solaris/native/sun/awt/awt_DrawingSurface.c Changeset: 9ed3ec97315c Author: lana Date: 2011-03-18 15:44 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9ed3ec97315c Merge - make/common/Modules.gmk - make/java/nio/mxbean/Makefile - make/modules/Makefile - make/modules/bootmodule.roots - make/modules/jdk7.depconfig - make/modules/modules.config - make/modules/modules.group - make/modules/optional.depconfig - make/modules/tools/Makefile - make/modules/tools/build.xml - make/modules/tools/nbproject/project.properties - make/modules/tools/nbproject/project.xml - make/modules/tools/src/com/sun/classanalyzer/AnnotatedDependency.java - make/modules/tools/src/com/sun/classanalyzer/AnnotationParser.java - make/modules/tools/src/com/sun/classanalyzer/BootAnalyzer.java - make/modules/tools/src/com/sun/classanalyzer/CheckDeps.java - make/modules/tools/src/com/sun/classanalyzer/ClassAnalyzer.java - make/modules/tools/src/com/sun/classanalyzer/ClassFileParser.java - make/modules/tools/src/com/sun/classanalyzer/ClassPath.java - make/modules/tools/src/com/sun/classanalyzer/CodeAttributeParser.java - make/modules/tools/src/com/sun/classanalyzer/ConstantPoolAnalyzer.java - make/modules/tools/src/com/sun/classanalyzer/ConstantPoolParser.java - make/modules/tools/src/com/sun/classanalyzer/DependencyConfig.java - make/modules/tools/src/com/sun/classanalyzer/Klass.java - make/modules/tools/src/com/sun/classanalyzer/Module.java - make/modules/tools/src/com/sun/classanalyzer/ModuleConfig.java - make/modules/tools/src/com/sun/classanalyzer/ResolutionInfo.java - make/modules/tools/src/com/sun/classanalyzer/ResourceFile.java - make/modules/tools/src/com/sun/classanalyzer/ShowDeps.java - src/share/classes/sun/misc/BootClassLoaderHook.java - src/share/classes/sun/misc/JavaSecurityCodeSignerAccess.java - test/sun/misc/BootClassLoaderHook/TestHook.java Changeset: 458b205209a9 Author: lana Date: 2011-03-21 16:53 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/458b205209a9 Merge Changeset: 551a6faa60df Author: rupashka Date: 2011-03-14 15:01 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/551a6faa60df 6464022: Memory leak in JOptionPane.createDialog Reviewed-by: alexp ! src/share/classes/javax/swing/JOptionPane.java + test/javax/swing/JOptionPane/6464022/bug6464022.java ! test/javax/swing/UIDefaults/6795356/bug6795356.java ! test/javax/swing/regtesthelpers/Util.java Changeset: 33755bd32db9 Author: rupashka Date: 2011-03-14 20:28 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/33755bd32db9 7016150: 6246816 refers to the Laffy demo which is not present in the JDK 7 demo/jfc directory Reviewed-by: peterz + make/mkdemo/jfc/Laffy/Makefile ! make/mkdemo/jfc/Makefile Changeset: 9faa309e852b Author: malenkov Date: 2011-03-16 18:48 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9faa309e852b 7027043: (doc) Confusing typo at java/beans/VetoableChangeSupport.java Reviewed-by: rupashka ! src/share/classes/java/beans/VetoableChangeSupport.java Changeset: c53260a00454 Author: malenkov Date: 2011-03-17 18:22 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c53260a00454 7021517: java.beans code comments have issues with HTML4 compliance Reviewed-by: rupashka ! src/share/classes/java/beans/DefaultPersistenceDelegate.java ! src/share/classes/java/beans/DesignMode.java ! src/share/classes/java/beans/IndexedPropertyChangeEvent.java ! src/share/classes/java/beans/Introspector.java ! src/share/classes/java/beans/package.html Changeset: 55f97ad0a36e Author: peytoia Date: 2011-03-18 08:42 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/55f97ad0a36e 7027387: (tz) Support tzdata2011d Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/etcetera ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/leapseconds ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/southamerica ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java Changeset: 44daa419e52b Author: lana Date: 2011-03-18 15:44 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/44daa419e52b Merge - make/common/Modules.gmk - make/java/nio/mxbean/Makefile - make/modules/Makefile - make/modules/bootmodule.roots - make/modules/jdk7.depconfig - make/modules/modules.config - make/modules/modules.group - make/modules/optional.depconfig - make/modules/tools/Makefile - make/modules/tools/build.xml - make/modules/tools/nbproject/project.properties - make/modules/tools/nbproject/project.xml - make/modules/tools/src/com/sun/classanalyzer/AnnotatedDependency.java - make/modules/tools/src/com/sun/classanalyzer/AnnotationParser.java - make/modules/tools/src/com/sun/classanalyzer/BootAnalyzer.java - make/modules/tools/src/com/sun/classanalyzer/CheckDeps.java - make/modules/tools/src/com/sun/classanalyzer/ClassAnalyzer.java - make/modules/tools/src/com/sun/classanalyzer/ClassFileParser.java - make/modules/tools/src/com/sun/classanalyzer/ClassPath.java - make/modules/tools/src/com/sun/classanalyzer/CodeAttributeParser.java - make/modules/tools/src/com/sun/classanalyzer/ConstantPoolAnalyzer.java - make/modules/tools/src/com/sun/classanalyzer/ConstantPoolParser.java - make/modules/tools/src/com/sun/classanalyzer/DependencyConfig.java - make/modules/tools/src/com/sun/classanalyzer/Klass.java - make/modules/tools/src/com/sun/classanalyzer/Module.java - make/modules/tools/src/com/sun/classanalyzer/ModuleConfig.java - make/modules/tools/src/com/sun/classanalyzer/ResolutionInfo.java - make/modules/tools/src/com/sun/classanalyzer/ResourceFile.java - make/modules/tools/src/com/sun/classanalyzer/ShowDeps.java - src/share/classes/sun/misc/BootClassLoaderHook.java - src/share/classes/sun/misc/JavaSecurityCodeSignerAccess.java - test/sun/misc/BootClassLoaderHook/TestHook.java Changeset: e930c56882b9 Author: lana Date: 2011-03-21 16:55 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e930c56882b9 Merge Changeset: 8fafdc993bf2 Author: lana Date: 2011-03-21 16:57 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8fafdc993bf2 Merge - make/com/sun/xml/Makefile - src/share/classes/org/relaxng/datatype/Datatype.java - src/share/classes/org/relaxng/datatype/DatatypeBuilder.java - src/share/classes/org/relaxng/datatype/DatatypeException.java - src/share/classes/org/relaxng/datatype/DatatypeLibrary.java - src/share/classes/org/relaxng/datatype/DatatypeLibraryFactory.java - src/share/classes/org/relaxng/datatype/DatatypeStreamingValidator.java - src/share/classes/org/relaxng/datatype/ValidationContext.java - src/share/classes/org/relaxng/datatype/helpers/DatatypeLibraryLoader.java - src/share/classes/org/relaxng/datatype/helpers/ParameterlessDatatypeBuilder.java - src/share/classes/org/relaxng/datatype/helpers/StreamingValidatorImpl.java - src/solaris/bin/ergo_sparc.c - src/solaris/bin/ergo_zero.c Changeset: 3dabb2f78e73 Author: bae Date: 2010-10-30 00:24 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3dabb2f78e73 6985453: Font.createFont may expose some system properties in exception text Reviewed-by: prr, hawtin ! src/share/classes/sun/font/FileFont.java ! src/share/classes/sun/font/TrueTypeFont.java ! src/share/classes/sun/font/Type1Font.java Changeset: 85ccd221280b Author: mullan Date: 2010-11-01 11:32 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/85ccd221280b 6994263: Untrusted code can replace JRE's XML DSig Transform or C14N algorithm implementations Reviewed-by: xuelei ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/Transform.java Changeset: cc989209cbf1 Author: chegar Date: 2011-01-10 18:12 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cc989209cbf1 6997851: Create NTLM AuthenticationCallBack class to avoid NTLM info leakage on client side Reviewed-by: michaelm ! make/sun/net/FILES_java.gmk ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/classes/sun/net/www/protocol/http/NTLMAuthenticationProxy.java + src/share/classes/sun/net/www/protocol/http/ntlm/NTLMAuthenticationCallback.java ! src/solaris/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java ! src/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java Changeset: b5c340d6c905 Author: denis Date: 2011-03-17 17:16 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b5c340d6c905 6907662: System clipboard should ensure access restrictions Reviewed-by: alexp ! src/share/classes/java/awt/AWTEvent.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/java/awt/MenuComponent.java ! src/share/classes/java/awt/TrayIcon.java ! src/share/classes/java/security/AccessControlContext.java ! src/share/classes/java/security/ProtectionDomain.java ! src/share/classes/javax/swing/Timer.java ! src/share/classes/javax/swing/TransferHandler.java ! src/share/classes/sun/awt/AWTAccessor.java + src/share/classes/sun/misc/JavaSecurityAccess.java ! src/share/classes/sun/misc/SharedSecrets.java Changeset: d19e3b281dcc Author: michaelm Date: 2011-03-17 18:26 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d19e3b281dcc 6981922: DNS cache poisoning by untrusted applets Reviewed-by: chegar ! make/sun/net/FILES_java.gmk ! src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java ! src/share/classes/java/net/AbstractPlainSocketImpl.java + src/share/classes/sun/net/ResourceManager.java ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/share/classes/sun/nio/ch/Net.java Changeset: 8af27e4ecaed Author: lana Date: 2011-03-21 17:22 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8af27e4ecaed Merge ! src/share/classes/java/awt/Component.java Changeset: 6d1b98c84f85 Author: michaelm Date: 2011-03-25 16:23 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6d1b98c84f85 7031238: Problem with fix for 6981922 Reviewed-by: chegar ! src/windows/classes/java/net/TwoStacksPlainDatagramSocketImpl.java Changeset: a50a7f8a847d Author: lana Date: 2011-03-26 00:10 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a50a7f8a847d Merge - make/com/sun/xml/Makefile ! make/common/Defs.gmk - src/share/classes/org/relaxng/datatype/Datatype.java - src/share/classes/org/relaxng/datatype/DatatypeBuilder.java - src/share/classes/org/relaxng/datatype/DatatypeException.java - src/share/classes/org/relaxng/datatype/DatatypeLibrary.java - src/share/classes/org/relaxng/datatype/DatatypeLibraryFactory.java - src/share/classes/org/relaxng/datatype/DatatypeStreamingValidator.java - src/share/classes/org/relaxng/datatype/ValidationContext.java - src/share/classes/org/relaxng/datatype/helpers/DatatypeLibraryLoader.java - src/share/classes/org/relaxng/datatype/helpers/ParameterlessDatatypeBuilder.java - src/share/classes/org/relaxng/datatype/helpers/StreamingValidatorImpl.java - src/solaris/bin/ergo_sparc.c - src/solaris/bin/ergo_zero.c Changeset: 5acc8cf00539 Author: jrose Date: 2011-03-18 00:03 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5acc8cf00539 6839872: remove implementation inheritance from JSR 292 APIs Summary: move everything into a single package; remove all multi-package machinery Reviewed-by: twisti, forax + src/share/classes/java/dyn/AdapterMethodHandle.java + src/share/classes/java/dyn/BoundMethodHandle.java ! src/share/classes/java/dyn/CallSite.java ! src/share/classes/java/dyn/ClassValue.java + src/share/classes/java/dyn/DirectMethodHandle.java + src/share/classes/java/dyn/FilterGeneric.java + src/share/classes/java/dyn/FilterOneArgument.java + src/share/classes/java/dyn/FromGeneric.java ! src/share/classes/java/dyn/InvokeDynamic.java + src/share/classes/java/dyn/InvokeGeneric.java + src/share/classes/java/dyn/Invokers.java ! src/share/classes/java/dyn/Linkage.java + src/share/classes/java/dyn/MemberName.java ! src/share/classes/java/dyn/MethodHandle.java + src/share/classes/java/dyn/MethodHandleImpl.java + src/share/classes/java/dyn/MethodHandleNatives.java + src/share/classes/java/dyn/MethodHandleStatics.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/MutableCallSite.java + src/share/classes/java/dyn/SpreadGeneric.java + src/share/classes/java/dyn/ToGeneric.java ! src/share/classes/java/dyn/VolatileCallSite.java ! src/share/classes/java/dyn/WrongMethodTypeException.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/InvokeGeneric.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/SpreadGeneric.java - src/share/classes/sun/dyn/ToGeneric.java ! src/share/classes/sun/dyn/util/ValueConversions.java ! src/share/classes/sun/dyn/util/VerifyAccess.java + test/java/dyn/6987555/Test6987555.java + test/java/dyn/6991596/Test6991596.java ! test/java/dyn/MethodTypeTest.java Changeset: 9c1e4e0ab69f Author: jrose Date: 2011-03-23 23:02 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9c1e4e0ab69f 7012648: move JSR 292 to package java.lang.invoke and adjust names Summary: package and class renaming only; delete unused methods and classes; add @since tags; no code changes Reviewed-by: twisti ! make/common/Release.gmk ! make/docs/CORE_PKGS.gmk ! make/java/Makefile - make/java/dyn/Makefile + make/java/invoke/Makefile - src/share/classes/java/dyn/ConstantCallSite.java - src/share/classes/java/dyn/InvokeDynamicBootstrapError.java - src/share/classes/java/dyn/Linkage.java - src/share/classes/java/dyn/SwitchPoint.java - src/share/classes/java/dyn/package-info.java + src/share/classes/java/lang/BootstrapMethodError.java ! src/share/classes/java/lang/ClassValue.java < src/share/classes/java/dyn/ClassValue.java ! src/share/classes/java/lang/invoke/AdapterMethodHandle.java < src/share/classes/java/dyn/AdapterMethodHandle.java ! src/share/classes/java/lang/invoke/BoundMethodHandle.java < src/share/classes/java/dyn/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/CallSite.java < src/share/classes/java/dyn/CallSite.java + src/share/classes/java/lang/invoke/ConstantCallSite.java ! src/share/classes/java/lang/invoke/DirectMethodHandle.java < src/share/classes/java/dyn/DirectMethodHandle.java ! src/share/classes/java/lang/invoke/FilterGeneric.java < src/share/classes/java/dyn/FilterGeneric.java ! src/share/classes/java/lang/invoke/FilterOneArgument.java < src/share/classes/java/dyn/FilterOneArgument.java ! src/share/classes/java/lang/invoke/FromGeneric.java < src/share/classes/java/dyn/FromGeneric.java ! src/share/classes/java/lang/invoke/InvokeDynamic.java < src/share/classes/java/dyn/InvokeDynamic.java ! src/share/classes/java/lang/invoke/InvokeGeneric.java < src/share/classes/java/dyn/InvokeGeneric.java ! src/share/classes/java/lang/invoke/Invokers.java < src/share/classes/java/dyn/Invokers.java ! src/share/classes/java/lang/invoke/MemberName.java < src/share/classes/java/dyn/MemberName.java ! src/share/classes/java/lang/invoke/MethodHandle.java < src/share/classes/java/dyn/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java < src/share/classes/java/dyn/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java < src/share/classes/java/dyn/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/MethodHandleStatics.java < src/share/classes/java/dyn/MethodHandleStatics.java ! src/share/classes/java/lang/invoke/MethodHandles.java < src/share/classes/java/dyn/MethodHandles.java ! src/share/classes/java/lang/invoke/MethodType.java < src/share/classes/java/dyn/MethodType.java ! src/share/classes/java/lang/invoke/MethodTypeForm.java < src/share/classes/java/dyn/MethodTypeForm.java ! src/share/classes/java/lang/invoke/MutableCallSite.java < src/share/classes/java/dyn/MutableCallSite.java ! src/share/classes/java/lang/invoke/SpreadGeneric.java < src/share/classes/java/dyn/SpreadGeneric.java + src/share/classes/java/lang/invoke/SwitchPoint.java ! src/share/classes/java/lang/invoke/ToGeneric.java < src/share/classes/java/dyn/ToGeneric.java ! src/share/classes/java/lang/invoke/VolatileCallSite.java < src/share/classes/java/dyn/VolatileCallSite.java ! src/share/classes/java/lang/invoke/WrongMethodTypeException.java < src/share/classes/java/dyn/WrongMethodTypeException.java + src/share/classes/java/lang/invoke/package-info.java - src/share/classes/sun/dyn/WrapperInstance.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/BytecodeDescriptor.java - src/share/classes/sun/dyn/util/BytecodeName.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/invoke/WrapperInstance.java + src/share/classes/sun/invoke/anon/AnonymousClassLoader.java + src/share/classes/sun/invoke/anon/ConstantPoolParser.java + src/share/classes/sun/invoke/anon/ConstantPoolPatch.java + src/share/classes/sun/invoke/anon/ConstantPoolVisitor.java + src/share/classes/sun/invoke/anon/InvalidConstantPoolFormatException.java + src/share/classes/sun/invoke/empty/Empty.java + src/share/classes/sun/invoke/package-info.java + src/share/classes/sun/invoke/util/BytecodeDescriptor.java + src/share/classes/sun/invoke/util/BytecodeName.java ! src/share/classes/sun/invoke/util/ValueConversions.java < src/share/classes/sun/dyn/util/ValueConversions.java ! src/share/classes/sun/invoke/util/VerifyAccess.java < src/share/classes/sun/dyn/util/VerifyAccess.java + src/share/classes/sun/invoke/util/VerifyType.java + src/share/classes/sun/invoke/util/Wrapper.java + src/share/classes/sun/invoke/util/package-info.java ! src/share/native/common/check_code.c - test/java/dyn/ClassValueTest.java - test/java/dyn/InvokeDynamicPrintArgs.java - test/java/dyn/InvokeGenericTest.java - test/java/dyn/JavaDocExamplesTest.java - test/java/dyn/MethodHandlesTest.java - test/java/dyn/indify/Indify.java ! test/java/lang/invoke/6987555/Test6987555.java < test/java/dyn/6987555/Test6987555.java ! test/java/lang/invoke/6991596/Test6991596.java < test/java/dyn/6991596/Test6991596.java + test/java/lang/invoke/ClassValueTest.java + test/java/lang/invoke/InvokeDynamicPrintArgs.java + test/java/lang/invoke/InvokeGenericTest.java + test/java/lang/invoke/JavaDocExamplesTest.java + test/java/lang/invoke/MethodHandlesTest.java ! test/java/lang/invoke/MethodTypeTest.java < test/java/dyn/MethodTypeTest.java + test/java/lang/invoke/indify/Indify.java Changeset: 4770b99ba850 Author: jrose Date: 2011-03-24 00:17 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4770b99ba850 Merge ! make/common/Release.gmk - make/java/dyn/Makefile - src/share/classes/java/dyn/CallSite.java - src/share/classes/java/dyn/ClassValue.java - src/share/classes/java/dyn/ConstantCallSite.java - src/share/classes/java/dyn/InvokeDynamic.java - src/share/classes/java/dyn/InvokeDynamicBootstrapError.java - src/share/classes/java/dyn/Linkage.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/MutableCallSite.java - src/share/classes/java/dyn/SwitchPoint.java - src/share/classes/java/dyn/VolatileCallSite.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/InvokeGeneric.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/SpreadGeneric.java - src/share/classes/sun/dyn/ToGeneric.java - src/share/classes/sun/dyn/WrapperInstance.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/BytecodeDescriptor.java - src/share/classes/sun/dyn/util/BytecodeName.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 - test/java/dyn/ClassValueTest.java - test/java/dyn/InvokeDynamicPrintArgs.java - test/java/dyn/InvokeGenericTest.java - test/java/dyn/JavaDocExamplesTest.java - test/java/dyn/MethodHandlesTest.java - test/java/dyn/MethodTypeTest.java - test/java/dyn/indify/Indify.java Changeset: 137d0bb3887a Author: trims Date: 2011-03-29 13:28 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/137d0bb3887a Merge - make/java/dyn/Makefile - src/share/classes/java/dyn/CallSite.java - src/share/classes/java/dyn/ClassValue.java - src/share/classes/java/dyn/ConstantCallSite.java - src/share/classes/java/dyn/InvokeDynamic.java - src/share/classes/java/dyn/InvokeDynamicBootstrapError.java - src/share/classes/java/dyn/Linkage.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/MutableCallSite.java - src/share/classes/java/dyn/SwitchPoint.java - src/share/classes/java/dyn/VolatileCallSite.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/InvokeGeneric.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/SpreadGeneric.java - src/share/classes/sun/dyn/ToGeneric.java - src/share/classes/sun/dyn/WrapperInstance.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/BytecodeDescriptor.java - src/share/classes/sun/dyn/util/BytecodeName.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 - test/java/dyn/ClassValueTest.java - test/java/dyn/InvokeDynamicPrintArgs.java - test/java/dyn/InvokeGenericTest.java - test/java/dyn/JavaDocExamplesTest.java - test/java/dyn/MethodHandlesTest.java - test/java/dyn/MethodTypeTest.java - test/java/dyn/indify/Indify.java Changeset: 9b9ca2b816f0 Author: ohair Date: 2011-03-29 18:24 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9b9ca2b816f0 7032327: Fix overview-core.html file, refers to version 6 Reviewed-by: wetmore ! src/share/classes/overview-core.html Changeset: dfffbbd40f30 Author: ohair Date: 2011-03-29 18:30 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dfffbbd40f30 Merge - make/com/sun/xml/Makefile - make/java/dyn/Makefile - src/share/classes/java/dyn/CallSite.java - src/share/classes/java/dyn/ClassValue.java - src/share/classes/java/dyn/ConstantCallSite.java - src/share/classes/java/dyn/InvokeDynamic.java - src/share/classes/java/dyn/InvokeDynamicBootstrapError.java - src/share/classes/java/dyn/Linkage.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/MutableCallSite.java - src/share/classes/java/dyn/SwitchPoint.java - src/share/classes/java/dyn/VolatileCallSite.java - src/share/classes/java/dyn/WrongMethodTypeException.java - src/share/classes/java/dyn/package-info.java - src/share/classes/org/relaxng/datatype/Datatype.java - src/share/classes/org/relaxng/datatype/DatatypeBuilder.java - src/share/classes/org/relaxng/datatype/DatatypeException.java - src/share/classes/org/relaxng/datatype/DatatypeLibrary.java - src/share/classes/org/relaxng/datatype/DatatypeLibraryFactory.java - src/share/classes/org/relaxng/datatype/DatatypeStreamingValidator.java - src/share/classes/org/relaxng/datatype/ValidationContext.java - src/share/classes/org/relaxng/datatype/helpers/DatatypeLibraryLoader.java - src/share/classes/org/relaxng/datatype/helpers/ParameterlessDatatypeBuilder.java - src/share/classes/org/relaxng/datatype/helpers/StreamingValidatorImpl.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/InvokeGeneric.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/SpreadGeneric.java - src/share/classes/sun/dyn/ToGeneric.java - src/share/classes/sun/dyn/WrapperInstance.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/BytecodeDescriptor.java - src/share/classes/sun/dyn/util/BytecodeName.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/solaris/bin/ergo_sparc.c - src/solaris/bin/ergo_zero.c - test/java/dyn/ClassValueTest.java - test/java/dyn/InvokeDynamicPrintArgs.java - test/java/dyn/InvokeGenericTest.java - test/java/dyn/JavaDocExamplesTest.java - test/java/dyn/MethodHandlesTest.java - test/java/dyn/MethodTypeTest.java - test/java/dyn/indify/Indify.java Changeset: 0858c48466f0 Author: ohair Date: 2011-03-29 11:29 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0858c48466f0 7011718: VS2010, remove makefile logic with regards to use of VC6, VS2003, VS2005, VS2008 Reviewed-by: prr, weijun ! make/common/Defs-windows.gmk ! make/common/Release.gmk ! make/common/shared/Compiler-msvc.gmk ! make/common/shared/Defs-versions.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Sanity.gmk ! make/sun/cmm/lcms/Makefile Changeset: aa13e7702cd9 Author: ohair Date: 2011-03-29 20:19 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/aa13e7702cd9 Merge - make/com/sun/xml/Makefile ! make/common/Release.gmk ! make/common/shared/Defs-versions.gmk ! make/common/shared/Sanity.gmk - make/java/dyn/Makefile - src/share/classes/java/dyn/CallSite.java - src/share/classes/java/dyn/ClassValue.java - src/share/classes/java/dyn/ConstantCallSite.java - src/share/classes/java/dyn/InvokeDynamic.java - src/share/classes/java/dyn/InvokeDynamicBootstrapError.java - src/share/classes/java/dyn/Linkage.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/MutableCallSite.java - src/share/classes/java/dyn/SwitchPoint.java - src/share/classes/java/dyn/VolatileCallSite.java - src/share/classes/java/dyn/WrongMethodTypeException.java - src/share/classes/java/dyn/package-info.java - src/share/classes/org/relaxng/datatype/Datatype.java - src/share/classes/org/relaxng/datatype/DatatypeBuilder.java - src/share/classes/org/relaxng/datatype/DatatypeException.java - src/share/classes/org/relaxng/datatype/DatatypeLibrary.java - src/share/classes/org/relaxng/datatype/DatatypeLibraryFactory.java - src/share/classes/org/relaxng/datatype/DatatypeStreamingValidator.java - src/share/classes/org/relaxng/datatype/ValidationContext.java - src/share/classes/org/relaxng/datatype/helpers/DatatypeLibraryLoader.java - src/share/classes/org/relaxng/datatype/helpers/ParameterlessDatatypeBuilder.java - src/share/classes/org/relaxng/datatype/helpers/StreamingValidatorImpl.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/InvokeGeneric.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/SpreadGeneric.java - src/share/classes/sun/dyn/ToGeneric.java - src/share/classes/sun/dyn/WrapperInstance.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/BytecodeDescriptor.java - src/share/classes/sun/dyn/util/BytecodeName.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/solaris/bin/ergo_sparc.c - src/solaris/bin/ergo_zero.c - test/java/dyn/ClassValueTest.java - test/java/dyn/InvokeDynamicPrintArgs.java - test/java/dyn/InvokeGenericTest.java - test/java/dyn/JavaDocExamplesTest.java - test/java/dyn/MethodHandlesTest.java - test/java/dyn/MethodTypeTest.java - test/java/dyn/indify/Indify.java Changeset: c5cd41d19f5f Author: schien Date: 2011-03-31 18:14 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c5cd41d19f5f Added tag jdk7-b136 for changeset aa13e7702cd9 ! .hgtags Changeset: 9aaa2233b0de Author: lana Date: 2011-03-31 22:07 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9aaa2233b0de Merge ! make/common/Defs.gmk ! make/common/Release.gmk - make/java/dyn/Makefile - src/share/classes/java/dyn/CallSite.java - src/share/classes/java/dyn/ClassValue.java - src/share/classes/java/dyn/ConstantCallSite.java - src/share/classes/java/dyn/InvokeDynamic.java - src/share/classes/java/dyn/InvokeDynamicBootstrapError.java - src/share/classes/java/dyn/Linkage.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/MutableCallSite.java - src/share/classes/java/dyn/SwitchPoint.java - src/share/classes/java/dyn/VolatileCallSite.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/InvokeGeneric.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/SpreadGeneric.java - src/share/classes/sun/dyn/ToGeneric.java - src/share/classes/sun/dyn/WrapperInstance.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/BytecodeDescriptor.java - src/share/classes/sun/dyn/util/BytecodeName.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 - test/java/dyn/ClassValueTest.java - test/java/dyn/InvokeDynamicPrintArgs.java - test/java/dyn/InvokeGenericTest.java - test/java/dyn/JavaDocExamplesTest.java - test/java/dyn/MethodHandlesTest.java - test/java/dyn/MethodTypeTest.java - test/java/dyn/indify/Indify.java From xueming.shen at oracle.com Fri Apr 1 19:07:33 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 01 Apr 2011 12:07:33 -0700 Subject: Suspected regression: fix for 6735255 causes delay in GC of ZipFile InputStreams, increase in heap demand In-Reply-To: <1301676177.24605.165.camel@chalkhill> References: <1300916786.4515.107.camel@chalkhill> <4D922D68.2080202@oracle.com> <1301514810.24605.64.camel@chalkhill> <4D93930A.2000604@oracle.com> <1301676177.24605.165.camel@chalkhill> Message-ID: <4D962275.7010601@oracle.com> On 04/01/2011 09:42 AM, Neil Richards wrote: > On Wed, 2011-03-30 at 13:31 -0700, Xueming Shen wrote: >> Isn't it true that when the finalize()->close() gets invoked, there >> should be no strong reference anywhere else that you can use to invoke >> close() in other thread? > It's true that once finalize() has been called, there can't be another > explicit call to close(). > However, if close() is explicitly called first, it will be called again > when finalize() calls it, so one still wants the update to 'isClosed' to > be seen by the finalizer thread (in this case). I'm not a GC guy, so I might be missing something here, but if close() is being explicitly invoked by some thread, means someone has a strong reference to it, I don't think the finalize() can kick in until that close() returns and the strong reference used to make that explicit invocation is cleared. The InputStream is eligible for finalization only after it is "weakly" reachable, means no more "stronger" reachable exists, right? -sherman >> ZipFileInputStream class has to sync on ZipFile.this, the read/close() >> methods are accessing the underlying/shared bits of the ZipFile. For >> ZipFileInflaterInputStream.close() case, even we want to make sure the >> isClose is synced, I would prefer to see a "local" lock, maybe simply >> make close() synchronized is better? > After assessing it again, I tend to agree - synchronizing on the ZFIIS > (instead of the ZipFile) now looks to me to be safe because it does not > do anything which synchronizes on the ZipFile object. > > (Note that if it _did_ cause such synchronization, it would risk > deadlock with the code in ZipFile's close() method, which is > synchronized on itself when it calls close() on each remaining ZFIIS. > It's the difference in the order of acquiring the monitors that would > cause the potential for deadlock). > > As it is, both close() methods synchronize on the 'inflaters' object > within their respective synchronized blocks, but that does not risk > deadlock. > > Please find below an updated changeset below, containing the suggested > change to synchronization. > > Thanks once again for your suggestions, > Neil > From xueming.shen at oracle.com Fri Apr 1 23:04:35 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 01 Apr 2011 16:04:35 -0700 Subject: Review Request for 6751338: ZIP inflater/deflater performance Message-ID: <4D965A03.30107@oracle.com> Dave, Alan, Here is the final webrev based on Dave's patch and the jdk1.5 code that does not have the change for 6206933. JPRT job result suggests no new testing failure and my "non-scientific" benchmark test (to use GZIPOu/InputStream to compress/ decompress the rt.jar) does show relative performance gain. Will try to run more tests the weekend, but here is the webrev. http://cr.openjdk.java.net/~sherman/6751338/webrev/ Background Info: This fix is basically to back out the fix for #6206933 we made back to jdk5, which is to use malloc+GetByteArrayuRegion to replace the original GetPrimitiveArrayCritical/ ReleasePrimitiveArrayCritical() pair when access the java byte array at native code Inflater/Deflater.c, to mainly workaround the GC/Critical... issue discussed in #6186200. The change for #6206933 itself has triggered lots of performance issues since its integration, some fixed, some still outstanding. The GC rfe#6186200 has been fixed long time ago, after couple weeks of discussion/debating, we all agreed that it's the time to back out#6206933. -Sherman From David.Holmes at oracle.com Fri Apr 1 23:17:40 2011 From: David.Holmes at oracle.com (David Holmes) Date: Sat, 02 Apr 2011 09:17:40 +1000 Subject: Suspected regression: fix for 6735255 causes delay in GC of ZipFile InputStreams, increase in heap demand In-Reply-To: <4D962275.7010601@oracle.com> References: <1300916786.4515.107.camel@chalkhill> <4D922D68.2080202@oracle.com> <1301514810.24605.64.camel@chalkhill> <4D93930A.2000604@oracle.com> <1301676177.24605.165.camel@chalkhill> <4D962275.7010601@oracle.com> Message-ID: <4D965D14.6060504@oracle.com> Xueming Shen said the following on 04/02/11 05:07: > On 04/01/2011 09:42 AM, Neil Richards wrote: >> On Wed, 2011-03-30 at 13:31 -0700, Xueming Shen wrote: >>> Isn't it true that when the finalize()->close() gets invoked, there >>> should be no strong reference anywhere else that you can use to invoke >>> close() in other thread? >> It's true that once finalize() has been called, there can't be another >> explicit call to close(). >> However, if close() is explicitly called first, it will be called again >> when finalize() calls it, so one still wants the update to 'isClosed' to >> be seen by the finalizer thread (in this case). > > I'm not a GC guy, so I might be missing something here, but if close() > is being explicitly > invoked by some thread, means someone has a strong reference to it, I > don't think the > finalize() can kick in until that close() returns and the strong > reference used to make that > explicit invocation is cleared. The InputStream is eligible for > finalization only after it is > "weakly" reachable, means no more "stronger" reachable exists, right? Actually no. One of the more obscure corner cases with finalization is that you can actually finalize an object that is still being used. The JLS actually spells this out - see section 12.6.1 and in particular the Discussion within that section. David > -sherman > >>> ZipFileInputStream class has to sync on ZipFile.this, the read/close() >>> methods are accessing the underlying/shared bits of the ZipFile. For >>> ZipFileInflaterInputStream.close() case, even we want to make sure the >>> isClose is synced, I would prefer to see a "local" lock, maybe simply >>> make close() synchronized is better? >> After assessing it again, I tend to agree - synchronizing on the ZFIIS >> (instead of the ZipFile) now looks to me to be safe because it does not >> do anything which synchronizes on the ZipFile object. >> >> (Note that if it _did_ cause such synchronization, it would risk >> deadlock with the code in ZipFile's close() method, which is >> synchronized on itself when it calls close() on each remaining ZFIIS. >> It's the difference in the order of acquiring the monitors that would >> cause the potential for deadlock). >> >> As it is, both close() methods synchronize on the 'inflaters' object >> within their respective synchronized blocks, but that does not risk >> deadlock. >> >> Please find below an updated changeset below, containing the suggested >> change to synchronization. >> >> Thanks once again for your suggestions, >> Neil >> > From frances.ho at oracle.com Sat Apr 2 00:48:51 2011 From: frances.ho at oracle.com (Frances Ho) Date: Sat, 2 Apr 2011 00:48:51 +0000 Subject: Review Request for 6751338: ZIP inflater/deflater performance In-Reply-To: <4D965A03.30107@oracle.com> References: <4D965A03.30107@oracle.com> Message-ID: <1991301280-1301705333-cardhu_decombobulator_blackberry.rim.net-448630658-@bda920.bisx.prod.on.blackberry> Sherman, Regarding micro benchmark, did you ever get together with monica from performance team so that she can start building suites of micro benchmarks? I think we need to start doing this so that they help(take over) performance validation in the future. Of course developers should still do it before checkin but benchmarks need to be run regularly. Thanks. -----Original Message----- From: Xueming Shen Sender: core-libs-dev-bounces at openjdk.java.net Date: Fri, 01 Apr 2011 16:04:35 To: Dave Bristor; BATEMAN, ALAN; core-libs-dev Subject: Review Request for 6751338: ZIP inflater/deflater performance Dave, Alan, Here is the final webrev based on Dave's patch and the jdk1.5 code that does not have the change for 6206933. JPRT job result suggests no new testing failure and my "non-scientific" benchmark test (to use GZIPOu/InputStream to compress/ decompress the rt.jar) does show relative performance gain. Will try to run more tests the weekend, but here is the webrev. http://cr.openjdk.java.net/~sherman/6751338/webrev/ Background Info: This fix is basically to back out the fix for #6206933 we made back to jdk5, which is to use malloc+GetByteArrayuRegion to replace the original GetPrimitiveArrayCritical/ ReleasePrimitiveArrayCritical() pair when access the java byte array at native code Inflater/Deflater.c, to mainly workaround the GC/Critical... issue discussed in #6186200. The change for #6206933 itself has triggered lots of performance issues since its integration, some fixed, some still outstanding. The GC rfe#6186200 has been fixed long time ago, after couple weeks of discussion/debating, we all agreed that it's the time to back out#6206933. -Sherman From neil.richards at ngmr.net Sat Apr 2 01:28:38 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Fri, 01 Apr 2011 18:28:38 -0700 Subject: Suspected regression: fix for 6735255 causes delay in GC of ZipFile InputStreams, increase in heap demand In-Reply-To: <4D965D14.6060504@oracle.com> References: <1300916786.4515.107.camel@chalkhill> <4D922D68.2080202@oracle.com> <1301514810.24605.64.camel@chalkhill> <4D93930A.2000604@oracle.com> <1301676177.24605.165.camel@chalkhill> <4D962275.7010601@oracle.com> <4D965D14.6060504@oracle.com> Message-ID: <1301707718.14323.43.camel@chalkhill> On Sat, 2011-04-02 at 09:17 +1000, David Holmes wrote: > Xueming Shen said the following on 04/02/11 05:07: > > On 04/01/2011 09:42 AM, Neil Richards wrote: > >> On Wed, 2011-03-30 at 13:31 -0700, Xueming Shen wrote: > >>> Isn't it true that when the finalize()->close() gets invoked, there > >>> should be no strong reference anywhere else that you can use to invoke > >>> close() in other thread? > >> It's true that once finalize() has been called, there can't be another > >> explicit call to close(). > >> However, if close() is explicitly called first, it will be called again > >> when finalize() calls it, so one still wants the update to 'isClosed' to > >> be seen by the finalizer thread (in this case). > > > > I'm not a GC guy, so I might be missing something here, but if close() > > is being explicitly invoked by some thread, means someone has a > > strong reference to it, I don't think the finalize() can kick in > > until that close() returns and the strong reference used to make > > that explicit invocation is cleared. The InputStream is eligible > > for finalization only after it is "weakly" reachable, means no more > > "stronger" reachable exists, right? > > Actually no. One of the more obscure corner cases with finalization is > that you can actually finalize an object that is still being used. The > JLS actually spells this out - see section 12.6.1 and in particular the > Discussion within that section. Also, I don't think my argument rests just on the behaviour in this corner case. Consider a normal thread with a normal (ie. "strong") reference explicitly calls close(), and so updates the 'isClosed' field to 'true'. To guarantee that that update is flushed from that normal thread's local memory cache down to main memory, and to guarantee another thread (eg. the finalizer thread) will see the update on a subsequent call (by fetching the value from main memory rather than relying on its local memory cache), one must either: 1. Using some form of synchronization for both the write and the read of the field's value. 2. Mark the field as being 'volatile'. As the logic inside close() involving 'isClosed' is intended to only let the first caller through to perform the close operations, it seems more appropriate in this case to use synchronization here. David, I can't claim to have reached true enlightenment wrt the section of the JLS that you point to - I suspect I'll need to lie down in a darkened room with a dampened flannel across the brow and ponder the nature of things a while to get there :-) In the meantime, can you (or other knowledgeable GC folk) advise whether it has any implications which would cause the current suggested fix to be unsuitable? (To recap, the current suggestion has the ZipFileInflaterInputStream's close() method synchronized on itself, and called from its finalize() method. The close() method has both the read and write of the 'isClosed' field). Any reassurance (or otherwise) gratefully accepted on this matter, Thanks, Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From jeroen at sumatra.nl Sat Apr 2 06:56:48 2011 From: jeroen at sumatra.nl (Jeroen Frijters) Date: Sat, 2 Apr 2011 06:56:48 +0000 Subject: Suspected regression: fix for 6735255 causes delay in GC of ZipFile InputStreams, increase in heap demand In-Reply-To: <4D962275.7010601@oracle.com> References: <1300916786.4515.107.camel@chalkhill> <4D922D68.2080202@oracle.com> <1301514810.24605.64.camel@chalkhill> <4D93930A.2000604@oracle.com> <1301676177.24605.165.camel@chalkhill> <4D962275.7010601@oracle.com> Message-ID: Xueming Shen wrote: > I'm not a GC guy, so I might be missing something here, but if close() > is being explicitly invoked by some thread, means someone has a strong > reference to it, I don't think the finalize() can kick in until that > close() returns This is not correct. You can re-publish the reference from another finalizer method and thereby allow another thread to access the object concurrently with the finalizer. Here's a possible sequence of events: 1) GC runs and determines that A and B are finalizable 2) Finalizer thread run A.finalize() 3) A.finalize publishes reference to B in static variable 4a) Another thread reads the static variable and calls B.close() 4b) Finalizer thread runs B.finalize() Regards, Jeroen From xueming.shen at oracle.com Sat Apr 2 07:00:03 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Sat, 02 Apr 2011 00:00:03 -0700 Subject: Suspected regression: fix for 6735255 causes delay in GC of ZipFile InputStreams, increase in heap demand In-Reply-To: <4D965D14.6060504@oracle.com> References: <1300916786.4515.107.camel@chalkhill> <4D922D68.2080202@oracle.com> <1301514810.24605.64.camel@chalkhill> <4D93930A.2000604@oracle.com> <1301676177.24605.165.camel@chalkhill> <4D962275.7010601@oracle.com> <4D965D14.6060504@oracle.com> Message-ID: <4D96C973.40102@oracle.com> On 4/1/2011 4:17 PM, David Holmes wrote: > Xueming Shen said the following on 04/02/11 05:07: >> On 04/01/2011 09:42 AM, Neil Richards wrote: >>> On Wed, 2011-03-30 at 13:31 -0700, Xueming Shen wrote: >>>> Isn't it true that when the finalize()->close() gets invoked, there >>>> should be no strong reference anywhere else that you can use to invoke >>>> close() in other thread? >>> It's true that once finalize() has been called, there can't be another >>> explicit call to close(). >>> However, if close() is explicitly called first, it will be called again >>> when finalize() calls it, so one still wants the update to >>> 'isClosed' to >>> be seen by the finalizer thread (in this case). >> >> I'm not a GC guy, so I might be missing something here, but if >> close() is being explicitly >> invoked by some thread, means someone has a strong reference to it, I >> don't think the >> finalize() can kick in until that close() returns and the strong >> reference used to make that >> explicit invocation is cleared. The InputStream is eligible for >> finalization only after it is >> "weakly" reachable, means no more "stronger" reachable exists, right? > > Actually no. One of the more obscure corner cases with finalization is > that you can actually finalize an object that is still being used. The > JLS actually spells this out - see section 12.6.1 and in particular > the Discussion within that section. > > David David, The scenario that Neil and I were discussing is something like this, There is class A class A { void close() { ... } protect void finalize() { ... close(); } } when we are in the middle of A's close() (invoked by someone, not the finalizer), do we need to worry about that A's finalize() being invoked (and then the close()) by the finalizer concurrently. Does you "an object that still being used" include the scenario like above, which means an object became finalizer-reachable, when still in the middle of the execution (by some alive, non-finalizer-thread) of one of its instance method body? The JLS 12.6.1, if I read it correctly, is for scenario that a reachable object which is strongly referenced by a stack reference can/may become finalizer-reachable sooner than it might be expected, for example, the compiler optimization can null out such reference in the middle of the method body, so that object becomes finalizer-reachable before the execution reach the return point of the method, or ... The "execution" discussed is not the execution inside the target object's method body. Am I reading it correctly? Otherwise, it becomes a little weird, image, you are in the middle of the execution of an instance method, suddenly, the instance itself is being finalized, all the native resource get released... -Sherman From xueming.shen at oracle.com Sat Apr 2 07:47:01 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Sat, 02 Apr 2011 00:47:01 -0700 Subject: Suspected regression: fix for 6735255 causes delay in GC of ZipFile InputStreams, increase in heap demand In-Reply-To: References: <1300916786.4515.107.camel@chalkhill> <4D922D68.2080202@oracle.com> <1301514810.24605.64.camel@chalkhill> <4D93930A.2000604@oracle.com> <1301676177.24605.165.camel@chalkhill> <4D962275.7010601@oracle.com> Message-ID: <4D96D475.3070404@oracle.com> On 4/1/2011 11:56 PM, Jeroen Frijters wrote: > Xueming Shen wrote: >> I'm not a GC guy, so I might be missing something here, but if close() >> is being explicitly invoked by some thread, means someone has a strong >> reference to it, I don't think the finalize() can kick in until that >> close() returns > This is not correct. You can re-publish the reference from another finalizer method and thereby allow another thread to access the object concurrently with the finalizer. > > Here's a possible sequence of events: > 1) GC runs and determines that A and B are finalizable > 2) Finalizer thread run A.finalize() > 3) A.finalize publishes reference to B in static variable Jeroen, are you talking about the object resurrection from finalize()? How do you re-publish/get the reference to B inside A.finalize()? I think you can do that inside B's finalize() to assign "this" to a global static variable. Regard, -Sherman > 4a) Another thread reads the static variable and calls B.close() > 4b) Finalizer thread runs B.finalize() > > Regards, > Jeroen > From xueming.shen at oracle.com Sat Apr 2 08:15:14 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Sat, 02 Apr 2011 01:15:14 -0700 Subject: Suspected regression: fix for 6735255 causes delay in GC of ZipFile InputStreams, increase in heap demand In-Reply-To: <4D96D475.3070404@oracle.com> References: <1300916786.4515.107.camel@chalkhill> <4D922D68.2080202@oracle.com> <1301514810.24605.64.camel@chalkhill> <4D93930A.2000604@oracle.com> <1301676177.24605.165.camel@chalkhill> <4D962275.7010601@oracle.com> <4D96D475.3070404@oracle.com> Message-ID: <4D96DB12.5030801@oracle.com> On 04-02-2011 12:47 AM, Xueming Shen wrote: > On 4/1/2011 11:56 PM, Jeroen Frijters wrote: >> Xueming Shen wrote: >>> I'm not a GC guy, so I might be missing something here, but if close() >>> is being explicitly invoked by some thread, means someone has a strong >>> reference to it, I don't think the finalize() can kick in until that >>> close() returns >> This is not correct. You can re-publish the reference from another >> finalizer method and thereby allow another thread to access the >> object concurrently with the finalizer. >> >> Here's a possible sequence of events: >> 1) GC runs and determines that A and B are finalizable >> 2) Finalizer thread run A.finalize() >> 3) A.finalize publishes reference to B in static variable > > Jeroen, are you talking about the object resurrection from finalize()? > > How do you re-publish/get the reference to B inside A.finalize()? I > think you can do that inside > B's finalize() to assign "this" to a global static variable. Jeroen, Guess I replied too quick. I think I got what you meant. A has a reference to B, GC finalizes A and B the same time, then A republish reference to B and let someone else to invoke b.close().. I would have to admit it's a possible use scenario:-) -Sherman > > Regard, > -Sherman > >> 4a) Another thread reads the static variable and calls B.close() >> 4b) Finalizer thread runs B.finalize() >> >> Regards, >> Jeroen >> > > From bristor at yahoo.com Sat Apr 2 16:01:28 2011 From: bristor at yahoo.com (Dave Bristor) Date: Sat, 2 Apr 2011 09:01:28 -0700 (PDT) Subject: Review Request for 6751338: ZIP inflater/deflater performance In-Reply-To: <4D965A03.30107@oracle.com> Message-ID: <844057.57622.qm@web31008.mail.mud.yahoo.com> The webrev looks fine. I have only this minor comment: * Inflater.c: A minor suggestion: In inflateBytes, cases Z_OK and Z_NEED_DICT, I suggest replacing: this_off += this_len - strm->avail_in; (*env)->SetIntField(env, this, offID, this_off); with: (*env)->SetIntField(env, this, offID, this_len - strm->avail_in); as this_off is not further used in the function. Thanks! Dave --- On Fri, 4/1/11, Xueming Shen wrote: > From: Xueming Shen > Subject: Review Request for 6751338: ZIP inflater/deflater performance > To: "Dave Bristor" , "BATEMAN,ALAN" , "core-libs-dev" > Date: Friday, April 1, 2011, 4:04 PM > Dave, Alan, > > Here is the final webrev based on Dave's patch and the > jdk1.5 code that does not > have the change for 6206933. JPRT job result suggests no > new testing failure and > my "non-scientific" benchmark test (to use > GZIPOu/InputStream to compress/ > decompress the rt.jar) does show relative performance gain. > Will try to run more > tests the weekend, but here is the webrev. > > http://cr.openjdk.java.net/~sherman/6751338/webrev/ > > Background Info: > > This fix is basically to back out the fix for #6206933 we > made back to jdk5, which > is to use malloc+GetByteArrayuRegion to replace the > original GetPrimitiveArrayCritical/ > ReleasePrimitiveArrayCritical() pair when access the java > byte array at native code > Inflater/Deflater.c, to mainly workaround the > GC/Critical... issue discussed in > #6186200. > > The change for #6206933 itself has triggered lots of > performance issues > since its integration, some fixed, some still outstanding. > The GC rfe#6186200 has > been fixed long time ago, after couple weeks of > discussion/debating, we all agreed > that it's the time to back out#6206933. > > -Sherman > > From robert.fischer at smokejumperit.com Sat Apr 2 22:40:32 2011 From: robert.fischer at smokejumperit.com (Robert Fischer) Date: Sat, 2 Apr 2011 18:40:32 -0400 Subject: Suspected regression: fix for 6735255 causes delay in GC of ZipFile InputStreams, increase in heap demand In-Reply-To: <4D96DB12.5030801@oracle.com> References: <1300916786.4515.107.camel@chalkhill> <4D922D68.2080202@oracle.com> <1301514810.24605.64.camel@chalkhill> <4D93930A.2000604@oracle.com> <1301676177.24605.165.camel@chalkhill> <4D962275.7010601@oracle.com> <4D96D475.3070404@oracle.com> <4D96DB12.5030801@oracle.com> Message-ID: If A has a reference to B, how did B become finalizable? Is it something like this? root ---> A ---> B root ----> null (leaving A ---> B both stranded) Will the finalizer then consider both A and B eligilble for finalization? I always assumed A was then eligible for finalization, but B isn't. ~~ Robert. On Sat, Apr 2, 2011 at 4:15 AM, Xueming Shen wrote: > On 04-02-2011 12:47 AM, Xueming Shen wrote: >> >> ?On 4/1/2011 11:56 PM, Jeroen Frijters wrote: >>> >>> Xueming Shen wrote: >>>> >>>> I'm not a GC guy, so I might be missing something here, but if close() >>>> is being explicitly invoked by some thread, means someone has a strong >>>> reference to it, I don't think the finalize() can kick in until that >>>> close() returns >>> >>> This is not correct. You can re-publish the reference from another >>> finalizer method and thereby allow another thread to access the object >>> concurrently with the finalizer. >>> >>> Here's a possible sequence of events: >>> 1) GC runs and determines that A and B are finalizable >>> 2) Finalizer thread run A.finalize() >>> 3) A.finalize publishes reference to B in static variable >> >> Jeroen, are you talking about the object resurrection from finalize()? >> >> How do you re-publish/get the reference to B inside A.finalize()? I think >> you can do that inside >> B's finalize() to assign "this" to a global static variable. > > Jeroen, > > Guess I replied too quick. I think I got what you meant. A has a reference > to B, ?GC finalizes A > and B the same time, then A republish reference to B and let someone else to > invoke b.close().. > I would have to admit it's a possible use scenario:-) > > -Sherman > >> >> Regard, >> -Sherman >> >>> 4a) Another thread reads the static variable and calls B.close() >>> 4b) Finalizer thread runs B.finalize() >>> >>> Regards, >>> Jeroen >>> >> >> > > From David.Holmes at oracle.com Sun Apr 3 01:15:46 2011 From: David.Holmes at oracle.com (David Holmes) Date: Sun, 03 Apr 2011 11:15:46 +1000 Subject: Suspected regression: fix for 6735255 causes delay in GC of ZipFile InputStreams, increase in heap demand In-Reply-To: <4D96C973.40102@oracle.com> References: <1300916786.4515.107.camel@chalkhill> <4D922D68.2080202@oracle.com> <1301514810.24605.64.camel@chalkhill> <4D93930A.2000604@oracle.com> <1301676177.24605.165.camel@chalkhill> <4D962275.7010601@oracle.com> <4D965D14.6060504@oracle.com> <4D96C973.40102@oracle.com> Message-ID: <4D97CA42.9020404@oracle.com> Xueming Shen said the following on 04/02/11 17:00: > On 4/1/2011 4:17 PM, David Holmes wrote: >> Xueming Shen said the following on 04/02/11 05:07: ... >>> explicit invocation is cleared. The InputStream is eligible for >>> finalization only after it is >>> "weakly" reachable, means no more "stronger" reachable exists, right? >> >> Actually no. One of the more obscure corner cases with finalization is >> that you can actually finalize an object that is still being used. The >> JLS actually spells this out - see section 12.6.1 and in particular >> the Discussion within that section. > > The scenario that Neil and I were discussing is something like this, > > There is class A > > class A { > void close() { > ... > } > > protect void finalize() { > ... > close(); > } > > } > > when we are in the middle of A's close() (invoked by someone, not the > finalizer), do we need to worry about that > A's finalize() being invoked (and then the close()) by the finalizer > concurrently. > > Does you "an object that still being used" include the scenario like > above, which means an object became > finalizer-reachable, when still in the middle of the execution (by some > alive, non-finalizer-thread) of one of its > instance method body? > > The JLS 12.6.1, if I read it correctly, is for scenario that a reachable > object which is strongly referenced by a > stack reference can/may become finalizer-reachable sooner than it might > be expected, for example, the > compiler optimization can null out such reference in the middle of the > method body, so that object becomes > finalizer-reachable before the execution reach the return point of the > method, or ... The "execution" discussed > is not the execution inside the target object's method body. Am I > reading it correctly? Otherwise, it becomes a > little weird, image, you are in the middle of the execution of an > instance method, suddenly, the instance itself > is being finalized, all the native resource get released... Yes 12.6.1 refers to the case where the object is only strongly-reachable from a local stack reference. This includes the "little weird" scenario you describe. A thread can be executing a.close() where 'a' is a local stack reference, and 'a' can be finalized while that is heppening. I'm not saying hotspot will actually do this, but it is permissible within the spec. This situation has been discussed quite a bit in the past on the Java Memory Model mailing list. David > -Sherman > > > > From xueming.shen at oracle.com Sun Apr 3 05:39:17 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Sat, 02 Apr 2011 22:39:17 -0700 Subject: Suspected regression: fix for 6735255 causes delay in GC of ZipFile InputStreams, increase in heap demand In-Reply-To: <4D97CA42.9020404@oracle.com> References: <1300916786.4515.107.camel@chalkhill> <4D922D68.2080202@oracle.com> <1301514810.24605.64.camel@chalkhill> <4D93930A.2000604@oracle.com> <1301676177.24605.165.camel@chalkhill> <4D962275.7010601@oracle.com> <4D965D14.6060504@oracle.com> <4D96C973.40102@oracle.com> <4D97CA42.9020404@oracle.com> Message-ID: <4D980805.7000809@oracle.com> Thanks David! And Neil, it seems my assumption is wrong and we do need the synchronization for the close(). Your latest patch looks fine for me. Thanks, -Sherman On 04-02-2011 6:15 PM, David Holmes wrote: > Xueming Shen said the following on 04/02/11 17:00: >> On 4/1/2011 4:17 PM, David Holmes wrote: >>> Xueming Shen said the following on 04/02/11 05:07: > ... >>>> explicit invocation is cleared. The InputStream is eligible for >>>> finalization only after it is >>>> "weakly" reachable, means no more "stronger" reachable exists, right? >>> >>> Actually no. One of the more obscure corner cases with finalization >>> is that you can actually finalize an object that is still being >>> used. The JLS actually spells this out - see section 12.6.1 and in >>> particular the Discussion within that section. >> >> The scenario that Neil and I were discussing is something like this, >> >> There is class A >> >> class A { >> void close() { >> ... >> } >> >> protect void finalize() { >> ... >> close(); >> } >> >> } >> >> when we are in the middle of A's close() (invoked by someone, not the >> finalizer), do we need to worry about that >> A's finalize() being invoked (and then the close()) by the finalizer >> concurrently. >> >> Does you "an object that still being used" include the scenario like >> above, which means an object became >> finalizer-reachable, when still in the middle of the execution (by >> some alive, non-finalizer-thread) of one of its >> instance method body? >> >> The JLS 12.6.1, if I read it correctly, is for scenario that a >> reachable object which is strongly referenced by a >> stack reference can/may become finalizer-reachable sooner than it >> might be expected, for example, the >> compiler optimization can null out such reference in the middle of >> the method body, so that object becomes >> finalizer-reachable before the execution reach the return point of >> the method, or ... The "execution" discussed >> is not the execution inside the target object's method body. Am I >> reading it correctly? Otherwise, it becomes a >> little weird, image, you are in the middle of the execution of an >> instance method, suddenly, the instance itself >> is being finalized, all the native resource get released... > > Yes 12.6.1 refers to the case where the object is only > strongly-reachable from a local stack reference. This includes the > "little weird" scenario you describe. A thread can be executing > a.close() where 'a' is a local stack reference, and 'a' can be > finalized while that is heppening. > > I'm not saying hotspot will actually do this, but it is permissible > within the spec. This situation has been discussed quite a bit in the > past on the Java Memory Model mailing list. > > David > >> -Sherman >> >> >> >> From xueming.shen at oracle.com Sun Apr 3 22:12:46 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Sun, 03 Apr 2011 15:12:46 -0700 Subject: Review Request for 6751338: ZIP inflater/deflater performance In-Reply-To: <844057.57622.qm@web31008.mail.mud.yahoo.com> References: <844057.57622.qm@web31008.mail.mud.yahoo.com> Message-ID: <4D98F0DE.50501@oracle.com> On 04-02-2011 9:01 AM, Dave Bristor wrote: > The webrev looks fine. I have only this minor comment: > > * Inflater.c: > A minor suggestion: In inflateBytes, cases Z_OK and Z_NEED_DICT, I suggest replacing: > this_off += this_len - strm->avail_in; > (*env)->SetIntField(env, this, offID, this_off); > with: > (*env)->SetIntField(env, this, offID, this_len - strm->avail_in); > as this_off is not further used in the function. It would be (*env)->SetIntField(env, this, offID, this_off + this_len - strm->avail_in); Personally I feel to do it in two steps makes it more clear (we are updating this_off...) and it is what it was before the change. So if you don't insist, I prefer to just keep it asis. Thanks, -Sherman > Thanks! > Dave > > --- On Fri, 4/1/11, Xueming Shen wrote: > >> From: Xueming Shen >> Subject: Review Request for 6751338: ZIP inflater/deflater performance >> To: "Dave Bristor", "BATEMAN,ALAN", "core-libs-dev" >> Date: Friday, April 1, 2011, 4:04 PM >> Dave, Alan, >> >> Here is the final webrev based on Dave's patch and the >> jdk1.5 code that does not >> have the change for 6206933. JPRT job result suggests no >> new testing failure and >> my "non-scientific" benchmark test (to use >> GZIPOu/InputStream to compress/ >> decompress the rt.jar) does show relative performance gain. >> Will try to run more >> tests the weekend, but here is the webrev. >> >> http://cr.openjdk.java.net/~sherman/6751338/webrev/ >> >> Background Info: >> >> This fix is basically to back out the fix for #6206933 we >> made back to jdk5, which >> is to use malloc+GetByteArrayuRegion to replace the >> original GetPrimitiveArrayCritical/ >> ReleasePrimitiveArrayCritical() pair when access the java >> byte array at native code >> Inflater/Deflater.c, to mainly workaround the >> GC/Critical... issue discussed in >> #6186200. >> >> The change for #6206933 itself has triggered lots of >> performance issues >> since its integration, some fixed, some still outstanding. >> The GC rfe#6186200 has >> been fixed long time ago, after couple weeks of >> discussion/debating, we all agreed >> that it's the time to back out#6206933. >> >> -Sherman >> >> From David.Holmes at oracle.com Sun Apr 3 23:04:48 2011 From: David.Holmes at oracle.com (David Holmes) Date: Mon, 04 Apr 2011 09:04:48 +1000 Subject: Suspected regression: fix for 6735255 causes delay in GC of ZipFile InputStreams, increase in heap demand In-Reply-To: <1301707718.14323.43.camel@chalkhill> References: <1300916786.4515.107.camel@chalkhill> <4D922D68.2080202@oracle.com> <1301514810.24605.64.camel@chalkhill> <4D93930A.2000604@oracle.com> <1301676177.24605.165.camel@chalkhill> <4D962275.7010601@oracle.com> <4D965D14.6060504@oracle.com> <1301707718.14323.43.camel@chalkhill> Message-ID: <4D98FD10.4090608@oracle.com> Hi Neil, Neil Richards said the following on 04/02/11 11:28: > David, I can't claim to have reached true enlightenment wrt the section > of the JLS that you point to - I suspect I'll need to lie down in a > darkened room with a dampened flannel across the brow and ponder the > nature of things a while to get there :-) > > In the meantime, can you (or other knowledgeable GC folk) advise whether > it has any implications which would cause the current suggested fix to > be unsuitable? > (To recap, the current suggestion has the ZipFileInflaterInputStream's > close() method synchronized on itself, and called from its finalize() > method. The close() method has both the read and write of the 'isClosed' > field). > > Any reassurance (or otherwise) gratefully accepted on this matter, I don't fully understand the object relationships here so I'll just make a couple of observations on the synchronization in this code: public synchronized void close() throws IOException { if (!isClosed) { super.close(); if (false == inFinalizer) releaseInflater(inf); isClosed = true; } } public int available() throws IOException { if (isClosed) return 0; long avail = zfin.size() - inf.getBytesWritten(); ... } protected void finalize() throws IOException { inFinalizer = true; close(); } 1. If a call to close() occurs around the same time as finalization occurs then the finalizer thread will set inFinalizer to true, at which point the thread executing close() can see it is true and so may skip the releaseInflater(inf) call. 2. As isClosed is not volatile, and available() is not synchronized, a thread calling available() on a closed stream may not see that it has been closed and so will likely encounter an IOException rather than getting a zero return. Even if #1 is not a practical problem I'd be inclined to make the finalizer synchronized as well. By doing that you're effectively ensuring that premature finalization of the stream won't happen. For #2 it is a tricky call. If you don't actually expect the stream object to be used by multiple threads then using a synchronized block to read isClosed will be cheap in VMs that go to great effort to reduce the cost of unnecessary synchronization (eg biased-locking in hotspot). Otherwise making isClosed volatile is likely the better option. HTH David From kumar.x.srinivasan at oracle.com Mon Apr 4 00:02:27 2011 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Mon, 04 Apr 2011 00:02:27 +0000 Subject: hg: jdk7/tl/langtools: 7028405: (javac) remove unused JSR-292 code Message-ID: <20110404000232.E3E704776E@hg.openjdk.java.net> Changeset: 46d720734db3 Author: ksrini Date: 2011-04-03 17:00 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/46d720734db3 7028405: (javac) remove unused JSR-292 code Reviewed-by: jrose, mcimadamore ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/util/Names.java ! test/tools/javac/meth/InvokeMH.java ! test/tools/javac/meth/TestCP.java ! test/tools/javac/meth/XlintWarn.java From joe.darcy at oracle.com Mon Apr 4 06:32:32 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Sun, 03 Apr 2011 23:32:32 -0700 Subject: Code review request for 6543593 "(reflect) Clarify private final field mutability" Message-ID: <4D996600.2090808@oracle.com> Hello. Please review the more precise wording added to java.lang.reflect.Field to address bug 6543593 "(reflect) Clarify private final field mutability" http://cr.openjdk.java.net/~darcy/6543593.0/ Full patch below. In describing when IllegalAccessException is thrown, Field now uses phrasing consistent with that used by its sibling classes Method and Constructor: "if this Method object enforces Java language access control and the underlying method is inaccessible." "if this Constructor object enforces Java language access control and the underlying constructor is inaccessible." Thanks, -Joe --- old/src/share/classes/java/lang/reflect/Field.java 2011-04-03 23:25:40.000000000 -0700 +++ new/src/share/classes/java/lang/reflect/Field.java 2011-04-03 23:25:39.000000000 -0700 @@ -360,8 +360,9 @@ * {@code obj}; primitive values are wrapped in an appropriate * object before being returned * - * @exception IllegalAccessException if the underlying field - * is inaccessible. + * @exception IllegalAccessException if this {@code Field} object + * enforces Java language access control and the underlying + * field is inaccessible. * @exception IllegalArgumentException if the specified object is not an * instance of the class or interface declaring the underlying * field (or a subclass or implementor thereof). @@ -383,8 +384,9 @@ * from * @return the value of the {@code boolean} field * - * @exception IllegalAccessException if the underlying field - * is inaccessible. + * @exception IllegalAccessException if this {@code Field} object + * enforces Java language access control and the underlying + * field is inaccessible. * @exception IllegalArgumentException if the specified object is not * an instance of the class or interface declaring the * underlying field (or a subclass or implementor @@ -410,8 +412,9 @@ * from * @return the value of the {@code byte} field * - * @exception IllegalAccessException if the underlying field - * is inaccessible. + * @exception IllegalAccessException if this {@code Field} object + * enforces Java language access control and the underlying + * field is inaccessible. * @exception IllegalArgumentException if the specified object is not * an instance of the class or interface declaring the * underlying field (or a subclass or implementor @@ -439,8 +442,9 @@ * from * @return the value of the field converted to type {@code char} * - * @exception IllegalAccessException if the underlying field - * is inaccessible. + * @exception IllegalAccessException if this {@code Field} object + * enforces Java language access control and the underlying + * field is inaccessible. * @exception IllegalArgumentException if the specified object is not * an instance of the class or interface declaring the * underlying field (or a subclass or implementor @@ -468,8 +472,9 @@ * from * @return the value of the field converted to type {@code short} * - * @exception IllegalAccessException if the underlying field - * is inaccessible. + * @exception IllegalAccessException if this {@code Field} object + * enforces Java language access control and the underlying + * field is inaccessible. * @exception IllegalArgumentException if the specified object is not * an instance of the class or interface declaring the * underlying field (or a subclass or implementor @@ -497,8 +502,9 @@ * from * @return the value of the field converted to type {@code int} * - * @exception IllegalAccessException if the underlying field - * is inaccessible. + * @exception IllegalAccessException if this {@code Field} object + * enforces Java language access control and the underlying + * field is inaccessible. * @exception IllegalArgumentException if the specified object is not * an instance of the class or interface declaring the * underlying field (or a subclass or implementor @@ -526,8 +532,9 @@ * from * @return the value of the field converted to type {@code long} * - * @exception IllegalAccessException if the underlying field - * is inaccessible. + * @exception IllegalAccessException if this {@code Field} object + * enforces Java language access control and the underlying + * field is inaccessible. * @exception IllegalArgumentException if the specified object is not * an instance of the class or interface declaring the * underlying field (or a subclass or implementor @@ -555,8 +562,9 @@ * from * @return the value of the field converted to type {@code float} * - * @exception IllegalAccessException if the underlying field - * is inaccessible. + * @exception IllegalAccessException if this {@code Field} object + * enforces Java language access control and the underlying + * field is inaccessible. * @exception IllegalArgumentException if the specified object is not * an instance of the class or interface declaring the * underlying field (or a subclass or implementor @@ -584,8 +592,9 @@ * from * @return the value of the field converted to type {@code double} * - * @exception IllegalAccessException if the underlying field - * is inaccessible. + * @exception IllegalAccessException if this {@code Field} object + * enforces Java language access control and the underlying + * field is inaccessible. * @exception IllegalArgumentException if the specified object is not * an instance of the class or interface declaring the * underlying field (or a subclass or implementor @@ -626,9 +635,9 @@ * {@code IllegalAccessException}. * *

If the underlying field is final, the method throws an - * {@code IllegalAccessException} unless - * {@code setAccessible(true)} has succeeded for this field - * and this field is non-static. Setting a final field in this way + * {@code IllegalAccessException} unless {@code setAccessible(true)} + * has succeeded for this {@code Field} object + * and the field is non-static. Setting a final field in this way * is meaningful only during deserialization or reconstruction of * instances of classes with blank final fields, before they are * made available for access by other parts of a program. Use in @@ -658,8 +667,9 @@ * @param value the new value for the field of {@code obj} * being modified * - * @exception IllegalAccessException if the underlying field - * is inaccessible. + * @exception IllegalAccessException if this {@code Field} object + * enforces Java language access control and the underlying + * field is inaccessible. * @exception IllegalArgumentException if the specified object is not an * instance of the class or interface declaring the underlying * field (or a subclass or implementor thereof), @@ -686,8 +696,9 @@ * @param z the new value for the field of {@code obj} * being modified * - * @exception IllegalAccessException if the underlying field - * is inaccessible. + * @exception IllegalAccessException if this {@code Field} object + * enforces Java language access control and the underlying + * field is inaccessible. * @exception IllegalArgumentException if the specified object is not an * instance of the class or interface declaring the underlying * field (or a subclass or implementor thereof), @@ -715,8 +726,9 @@ * @param b the new value for the field of {@code obj} * being modified * - * @exception IllegalAccessException if the underlying field - * is inaccessible. + * @exception IllegalAccessException if this {@code Field} object + * enforces Java language access control and the underlying + * field is inaccessible. * @exception IllegalArgumentException if the specified object is not an * instance of the class or interface declaring the underlying * field (or a subclass or implementor thereof), @@ -744,8 +756,9 @@ * @param c the new value for the field of {@code obj} * being modified * - * @exception IllegalAccessException if the underlying field - * is inaccessible. + * @exception IllegalAccessException if this {@code Field} object + * enforces Java language access control and the underlying + * field is inaccessible. * @exception IllegalArgumentException if the specified object is not an * instance of the class or interface declaring the underlying * field (or a subclass or implementor thereof), @@ -773,8 +786,9 @@ * @param s the new value for the field of {@code obj} * being modified * - * @exception IllegalAccessException if the underlying field - * is inaccessible. + * @exception IllegalAccessException if this {@code Field} object + * enforces Java language access control and the underlying + * field is inaccessible. * @exception IllegalArgumentException if the specified object is not an * instance of the class or interface declaring the underlying * field (or a subclass or implementor thereof), @@ -802,8 +816,9 @@ * @param i the new value for the field of {@code obj} * being modified * - * @exception IllegalAccessException if the underlying field - * is inaccessible. + * @exception IllegalAccessException if this {@code Field} object + * enforces Java language access control and the underlying + * field is inaccessible. * @exception IllegalArgumentException if the specified object is not an * instance of the class or interface declaring the underlying * field (or a subclass or implementor thereof), @@ -831,8 +846,9 @@ * @param l the new value for the field of {@code obj} * being modified * - * @exception IllegalAccessException if the underlying field - * is inaccessible. + * @exception IllegalAccessException if this {@code Field} object + * enforces Java language access control and the underlying + * field is inaccessible. * @exception IllegalArgumentException if the specified object is not an * instance of the class or interface declaring the underlying * field (or a subclass or implementor thereof), @@ -860,8 +876,9 @@ * @param f the new value for the field of {@code obj} * being modified * - * @exception IllegalAccessException if the underlying field - * is inaccessible. + * @exception IllegalAccessException if this {@code Field} object + * enforces Java language access control and the underlying + * field is inaccessible. * @exception IllegalArgumentException if the specified object is not an * instance of the class or interface declaring the underlying * field (or a subclass or implementor thereof), @@ -889,8 +906,9 @@ * @param d the new value for the field of {@code obj} * being modified * - * @exception IllegalAccessException if the underlying field - * is inaccessible. + * @exception IllegalAccessException if this {@code Field} object + * enforces Java language access control and the underlying + * field is inaccessible. * @exception IllegalArgumentException if the specified object is not an * instance of the class or interface declaring the underlying * field (or a subclass or implementor thereof), From David.Holmes at oracle.com Mon Apr 4 07:22:00 2011 From: David.Holmes at oracle.com (David Holmes) Date: Mon, 04 Apr 2011 17:22:00 +1000 Subject: Code review request for 6543593 "(reflect) Clarify private final field mutability" In-Reply-To: <4D996600.2090808@oracle.com> References: <4D996600.2090808@oracle.com> Message-ID: <4D997198.4070905@oracle.com> Hi Joe, I'm not sure exactly what Bill was complaining about here, but using the same phrasing as Method and Constructor is a good thing. However, as the CR pertains in particular to the issue of final fields, I think for the setXXX cases the "@exception** IllegalAccessException" javadoc should also mention that it can be thrown because the field is final, not just because it is inaccessible. ** shouldn't all those @exception tags get converted to @throws? David Joe Darcy said the following on 04/04/11 16:32: > Hello. > > Please review the more precise wording added to java.lang.reflect.Field > to address bug > > 6543593 "(reflect) Clarify private final field mutability" > http://cr.openjdk.java.net/~darcy/6543593.0/ > > Full patch below. > > In describing when IllegalAccessException is thrown, Field now uses > phrasing consistent with that used by its sibling classes Method and > Constructor: > > "if this Method object enforces Java language access control and the > underlying method is inaccessible." > "if this Constructor object enforces Java language access control and > the underlying constructor is inaccessible." > > Thanks, > > -Joe > > --- old/src/share/classes/java/lang/reflect/Field.java 2011-04-03 > 23:25:40.000000000 -0700 > +++ new/src/share/classes/java/lang/reflect/Field.java 2011-04-03 > 23:25:39.000000000 -0700 > @@ -360,8 +360,9 @@ > * {@code obj}; primitive values are wrapped in an appropriate > * object before being returned > * > - * @exception IllegalAccessException if the underlying field > - * is inaccessible. > + * @exception IllegalAccessException if this {@code Field} object > + * enforces Java language access control and the > underlying > + * field is inaccessible. > * @exception IllegalArgumentException if the specified object is > not an > * instance of the class or interface declaring the > underlying > * field (or a subclass or implementor thereof). > @@ -383,8 +384,9 @@ > * from > * @return the value of the {@code boolean} field > * > - * @exception IllegalAccessException if the underlying field > - * is inaccessible. > + * @exception IllegalAccessException if this {@code Field} object > + * enforces Java language access control and the > underlying > + * field is inaccessible. > * @exception IllegalArgumentException if the specified object is not > * an instance of the class or interface declaring the > * underlying field (or a subclass or implementor > @@ -410,8 +412,9 @@ > * from > * @return the value of the {@code byte} field > * > - * @exception IllegalAccessException if the underlying field > - * is inaccessible. > + * @exception IllegalAccessException if this {@code Field} object > + * enforces Java language access control and the > underlying > + * field is inaccessible. > * @exception IllegalArgumentException if the specified object is not > * an instance of the class or interface declaring the > * underlying field (or a subclass or implementor > @@ -439,8 +442,9 @@ > * from > * @return the value of the field converted to type {@code char} > * > - * @exception IllegalAccessException if the underlying field > - * is inaccessible. > + * @exception IllegalAccessException if this {@code Field} object > + * enforces Java language access control and the > underlying > + * field is inaccessible. > * @exception IllegalArgumentException if the specified object is not > * an instance of the class or interface declaring the > * underlying field (or a subclass or implementor > @@ -468,8 +472,9 @@ > * from > * @return the value of the field converted to type {@code short} > * > - * @exception IllegalAccessException if the underlying field > - * is inaccessible. > + * @exception IllegalAccessException if this {@code Field} object > + * enforces Java language access control and the > underlying > + * field is inaccessible. > * @exception IllegalArgumentException if the specified object is not > * an instance of the class or interface declaring the > * underlying field (or a subclass or implementor > @@ -497,8 +502,9 @@ > * from > * @return the value of the field converted to type {@code int} > * > - * @exception IllegalAccessException if the underlying field > - * is inaccessible. > + * @exception IllegalAccessException if this {@code Field} object > + * enforces Java language access control and the > underlying > + * field is inaccessible. > * @exception IllegalArgumentException if the specified object is not > * an instance of the class or interface declaring the > * underlying field (or a subclass or implementor > @@ -526,8 +532,9 @@ > * from > * @return the value of the field converted to type {@code long} > * > - * @exception IllegalAccessException if the underlying field > - * is inaccessible. > + * @exception IllegalAccessException if this {@code Field} object > + * enforces Java language access control and the > underlying > + * field is inaccessible. > * @exception IllegalArgumentException if the specified object is not > * an instance of the class or interface declaring the > * underlying field (or a subclass or implementor > @@ -555,8 +562,9 @@ > * from > * @return the value of the field converted to type {@code float} > * > - * @exception IllegalAccessException if the underlying field > - * is inaccessible. > + * @exception IllegalAccessException if this {@code Field} object > + * enforces Java language access control and the > underlying > + * field is inaccessible. > * @exception IllegalArgumentException if the specified object is not > * an instance of the class or interface declaring the > * underlying field (or a subclass or implementor > @@ -584,8 +592,9 @@ > * from > * @return the value of the field converted to type {@code double} > * > - * @exception IllegalAccessException if the underlying field > - * is inaccessible. > + * @exception IllegalAccessException if this {@code Field} object > + * enforces Java language access control and the > underlying > + * field is inaccessible. > * @exception IllegalArgumentException if the specified object is not > * an instance of the class or interface declaring the > * underlying field (or a subclass or implementor > @@ -626,9 +635,9 @@ > * {@code IllegalAccessException}. > * > *

If the underlying field is final, the method throws an > - * {@code IllegalAccessException} unless > - * {@code setAccessible(true)} has succeeded for this field > - * and this field is non-static. Setting a final field in this way > + * {@code IllegalAccessException} unless {@code setAccessible(true)} > + * has succeeded for this {@code Field} object > + * and the field is non-static. Setting a final field in this way > * is meaningful only during deserialization or reconstruction of > * instances of classes with blank final fields, before they are > * made available for access by other parts of a program. Use in > @@ -658,8 +667,9 @@ > * @param value the new value for the field of {@code obj} > * being modified > * > - * @exception IllegalAccessException if the underlying field > - * is inaccessible. > + * @exception IllegalAccessException if this {@code Field} object > + * enforces Java language access control and the > underlying > + * field is inaccessible. > * @exception IllegalArgumentException if the specified object is > not an > * instance of the class or interface declaring the > underlying > * field (or a subclass or implementor thereof), > @@ -686,8 +696,9 @@ > * @param z the new value for the field of {@code obj} > * being modified > * > - * @exception IllegalAccessException if the underlying field > - * is inaccessible. > + * @exception IllegalAccessException if this {@code Field} object > + * enforces Java language access control and the > underlying > + * field is inaccessible. > * @exception IllegalArgumentException if the specified object is > not an > * instance of the class or interface declaring the > underlying > * field (or a subclass or implementor thereof), > @@ -715,8 +726,9 @@ > * @param b the new value for the field of {@code obj} > * being modified > * > - * @exception IllegalAccessException if the underlying field > - * is inaccessible. > + * @exception IllegalAccessException if this {@code Field} object > + * enforces Java language access control and the > underlying > + * field is inaccessible. > * @exception IllegalArgumentException if the specified object is > not an > * instance of the class or interface declaring the > underlying > * field (or a subclass or implementor thereof), > @@ -744,8 +756,9 @@ > * @param c the new value for the field of {@code obj} > * being modified > * > - * @exception IllegalAccessException if the underlying field > - * is inaccessible. > + * @exception IllegalAccessException if this {@code Field} object > + * enforces Java language access control and the > underlying > + * field is inaccessible. > * @exception IllegalArgumentException if the specified object is > not an > * instance of the class or interface declaring the > underlying > * field (or a subclass or implementor thereof), > @@ -773,8 +786,9 @@ > * @param s the new value for the field of {@code obj} > * being modified > * > - * @exception IllegalAccessException if the underlying field > - * is inaccessible. > + * @exception IllegalAccessException if this {@code Field} object > + * enforces Java language access control and the > underlying > + * field is inaccessible. > * @exception IllegalArgumentException if the specified object is > not an > * instance of the class or interface declaring the > underlying > * field (or a subclass or implementor thereof), > @@ -802,8 +816,9 @@ > * @param i the new value for the field of {@code obj} > * being modified > * > - * @exception IllegalAccessException if the underlying field > - * is inaccessible. > + * @exception IllegalAccessException if this {@code Field} object > + * enforces Java language access control and the > underlying > + * field is inaccessible. > * @exception IllegalArgumentException if the specified object is > not an > * instance of the class or interface declaring the > underlying > * field (or a subclass or implementor thereof), > @@ -831,8 +846,9 @@ > * @param l the new value for the field of {@code obj} > * being modified > * > - * @exception IllegalAccessException if the underlying field > - * is inaccessible. > + * @exception IllegalAccessException if this {@code Field} object > + * enforces Java language access control and the > underlying > + * field is inaccessible. > * @exception IllegalArgumentException if the specified object is > not an > * instance of the class or interface declaring the > underlying > * field (or a subclass or implementor thereof), > @@ -860,8 +876,9 @@ > * @param f the new value for the field of {@code obj} > * being modified > * > - * @exception IllegalAccessException if the underlying field > - * is inaccessible. > + * @exception IllegalAccessException if this {@code Field} object > + * enforces Java language access control and the > underlying > + * field is inaccessible. > * @exception IllegalArgumentException if the specified object is > not an > * instance of the class or interface declaring the > underlying > * field (or a subclass or implementor thereof), > @@ -889,8 +906,9 @@ > * @param d the new value for the field of {@code obj} > * being modified > * > - * @exception IllegalAccessException if the underlying field > - * is inaccessible. > + * @exception IllegalAccessException if this {@code Field} object > + * enforces Java language access control and the > underlying > + * field is inaccessible. > * @exception IllegalArgumentException if the specified object is > not an > * instance of the class or interface declaring the > underlying > * field (or a subclass or implementor thereof), > From joe.darcy at oracle.com Mon Apr 4 07:46:16 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 04 Apr 2011 00:46:16 -0700 Subject: Code review request for 6543593 "(reflect) Clarify private final field mutability" In-Reply-To: <4D997198.4070905@oracle.com> References: <4D996600.2090808@oracle.com> <4D997198.4070905@oracle.com> Message-ID: <4D997748.2030003@oracle.com> Hi David. David Holmes wrote: > Hi Joe, > > I'm not sure exactly what Bill was complaining about here, His specific issue was addressed by the diff *

If the underlying field is final, the method throws an - * {@code IllegalAccessException} unless - * {@code setAccessible(true)} has succeeded for this field - * and this field is non-static. Setting a final field in this way + * {@code IllegalAccessException} unless {@code setAccessible(true)} + * has succeeded for this {@code Field} object + * and the field is non-static. Setting a final field in this way * is meaningful only during deserialization or reconstruction of * instances of classes with blank final fields, before they are * made available for access by other parts of a program. Use in @@ -658,8 +667,9 @@ * @param value the new value for the field of {@code obj} * being modified In other words, setAccessible(true) can succeed on a java.lang.reflect.Field object but not on a field. > but using the same phrasing as Method and Constructor is a good thing. > However, as the CR pertains in particular to the issue of final > fields, I think for the setXXX cases the "@exception** > IllegalAccessException" javadoc should also mention that it can be > thrown because the field is final, not just because it is inaccessible. Fair enough. How about just for the setter methods + * @exception IllegalAccessException if this {@code Field} object + * enforces Java language access control and the underlying + * field is inaccessible or is final. > > ** shouldn't all those @exception tags get converted to @throws? That would certainly be my style recommendation, but I wasn't looking to make that change at the moment. Thanks, -Joe > > David > > Joe Darcy said the following on 04/04/11 16:32: >> Hello. >> >> Please review the more precise wording added to >> java.lang.reflect.Field to address bug >> >> 6543593 "(reflect) Clarify private final field mutability" >> http://cr.openjdk.java.net/~darcy/6543593.0/ >> >> Full patch below. >> >> In describing when IllegalAccessException is thrown, Field now uses >> phrasing consistent with that used by its sibling classes Method and >> Constructor: >> >> "if this Method object enforces Java language access control and the >> underlying method is inaccessible." >> "if this Constructor object enforces Java language access control and >> the underlying constructor is inaccessible." >> >> Thanks, >> >> -Joe >> >> --- old/src/share/classes/java/lang/reflect/Field.java 2011-04-03 >> 23:25:40.000000000 -0700 >> +++ new/src/share/classes/java/lang/reflect/Field.java 2011-04-03 >> 23:25:39.000000000 -0700 >> @@ -360,8 +360,9 @@ >> * {@code obj}; primitive values are wrapped in an appropriate >> * object before being returned >> * >> - * @exception IllegalAccessException if the underlying field >> - * is inaccessible. >> + * @exception IllegalAccessException if this {@code Field} >> object >> + * enforces Java language access control and the >> underlying >> + * field is inaccessible. >> * @exception IllegalArgumentException if the specified object >> is not an >> * instance of the class or interface declaring the >> underlying >> * field (or a subclass or implementor thereof). >> @@ -383,8 +384,9 @@ >> * from >> * @return the value of the {@code boolean} field >> * >> - * @exception IllegalAccessException if the underlying field >> - * is inaccessible. >> + * @exception IllegalAccessException if this {@code Field} >> object >> + * enforces Java language access control and the >> underlying >> + * field is inaccessible. >> * @exception IllegalArgumentException if the specified object >> is not >> * an instance of the class or interface declaring the >> * underlying field (or a subclass or implementor >> @@ -410,8 +412,9 @@ >> * from >> * @return the value of the {@code byte} field >> * >> - * @exception IllegalAccessException if the underlying field >> - * is inaccessible. >> + * @exception IllegalAccessException if this {@code Field} >> object >> + * enforces Java language access control and the >> underlying >> + * field is inaccessible. >> * @exception IllegalArgumentException if the specified object >> is not >> * an instance of the class or interface declaring the >> * underlying field (or a subclass or implementor >> @@ -439,8 +442,9 @@ >> * from >> * @return the value of the field converted to type {@code char} >> * >> - * @exception IllegalAccessException if the underlying field >> - * is inaccessible. >> + * @exception IllegalAccessException if this {@code Field} >> object >> + * enforces Java language access control and the >> underlying >> + * field is inaccessible. >> * @exception IllegalArgumentException if the specified object >> is not >> * an instance of the class or interface declaring the >> * underlying field (or a subclass or implementor >> @@ -468,8 +472,9 @@ >> * from >> * @return the value of the field converted to type {@code short} >> * >> - * @exception IllegalAccessException if the underlying field >> - * is inaccessible. >> + * @exception IllegalAccessException if this {@code Field} >> object >> + * enforces Java language access control and the >> underlying >> + * field is inaccessible. >> * @exception IllegalArgumentException if the specified object >> is not >> * an instance of the class or interface declaring the >> * underlying field (or a subclass or implementor >> @@ -497,8 +502,9 @@ >> * from >> * @return the value of the field converted to type {@code int} >> * >> - * @exception IllegalAccessException if the underlying field >> - * is inaccessible. >> + * @exception IllegalAccessException if this {@code Field} >> object >> + * enforces Java language access control and the >> underlying >> + * field is inaccessible. >> * @exception IllegalArgumentException if the specified object >> is not >> * an instance of the class or interface declaring the >> * underlying field (or a subclass or implementor >> @@ -526,8 +532,9 @@ >> * from >> * @return the value of the field converted to type {@code long} >> * >> - * @exception IllegalAccessException if the underlying field >> - * is inaccessible. >> + * @exception IllegalAccessException if this {@code Field} >> object >> + * enforces Java language access control and the >> underlying >> + * field is inaccessible. >> * @exception IllegalArgumentException if the specified object >> is not >> * an instance of the class or interface declaring the >> * underlying field (or a subclass or implementor >> @@ -555,8 +562,9 @@ >> * from >> * @return the value of the field converted to type {@code float} >> * >> - * @exception IllegalAccessException if the underlying field >> - * is inaccessible. >> + * @exception IllegalAccessException if this {@code Field} >> object >> + * enforces Java language access control and the >> underlying >> + * field is inaccessible. >> * @exception IllegalArgumentException if the specified object >> is not >> * an instance of the class or interface declaring the >> * underlying field (or a subclass or implementor >> @@ -584,8 +592,9 @@ >> * from >> * @return the value of the field converted to type {@code double} >> * >> - * @exception IllegalAccessException if the underlying field >> - * is inaccessible. >> + * @exception IllegalAccessException if this {@code Field} >> object >> + * enforces Java language access control and the >> underlying >> + * field is inaccessible. >> * @exception IllegalArgumentException if the specified object >> is not >> * an instance of the class or interface declaring the >> * underlying field (or a subclass or implementor >> @@ -626,9 +635,9 @@ >> * {@code IllegalAccessException}. >> * >> *

If the underlying field is final, the method throws an >> - * {@code IllegalAccessException} unless >> - * {@code setAccessible(true)} has succeeded for this field >> - * and this field is non-static. Setting a final field in this way >> + * {@code IllegalAccessException} unless {@code >> setAccessible(true)} >> + * has succeeded for this {@code Field} object >> + * and the field is non-static. Setting a final field in this way >> * is meaningful only during deserialization or reconstruction of >> * instances of classes with blank final fields, before they are >> * made available for access by other parts of a program. Use in >> @@ -658,8 +667,9 @@ >> * @param value the new value for the field of {@code obj} >> * being modified >> * >> - * @exception IllegalAccessException if the underlying field >> - * is inaccessible. >> + * @exception IllegalAccessException if this {@code Field} >> object >> + * enforces Java language access control and the >> underlying >> + * field is inaccessible. >> * @exception IllegalArgumentException if the specified object >> is not an >> * instance of the class or interface declaring the >> underlying >> * field (or a subclass or implementor thereof), >> @@ -686,8 +696,9 @@ >> * @param z the new value for the field of {@code obj} >> * being modified >> * >> - * @exception IllegalAccessException if the underlying field >> - * is inaccessible. >> + * @exception IllegalAccessException if this {@code Field} >> object >> + * enforces Java language access control and the >> underlying >> + * field is inaccessible. >> * @exception IllegalArgumentException if the specified object >> is not an >> * instance of the class or interface declaring the >> underlying >> * field (or a subclass or implementor thereof), >> @@ -715,8 +726,9 @@ >> * @param b the new value for the field of {@code obj} >> * being modified >> * >> - * @exception IllegalAccessException if the underlying field >> - * is inaccessible. >> + * @exception IllegalAccessException if this {@code Field} >> object >> + * enforces Java language access control and the >> underlying >> + * field is inaccessible. >> * @exception IllegalArgumentException if the specified object >> is not an >> * instance of the class or interface declaring the >> underlying >> * field (or a subclass or implementor thereof), >> @@ -744,8 +756,9 @@ >> * @param c the new value for the field of {@code obj} >> * being modified >> * >> - * @exception IllegalAccessException if the underlying field >> - * is inaccessible. >> + * @exception IllegalAccessException if this {@code Field} >> object >> + * enforces Java language access control and the >> underlying >> + * field is inaccessible. >> * @exception IllegalArgumentException if the specified object >> is not an >> * instance of the class or interface declaring the >> underlying >> * field (or a subclass or implementor thereof), >> @@ -773,8 +786,9 @@ >> * @param s the new value for the field of {@code obj} >> * being modified >> * >> - * @exception IllegalAccessException if the underlying field >> - * is inaccessible. >> + * @exception IllegalAccessException if this {@code Field} >> object >> + * enforces Java language access control and the >> underlying >> + * field is inaccessible. >> * @exception IllegalArgumentException if the specified object >> is not an >> * instance of the class or interface declaring the >> underlying >> * field (or a subclass or implementor thereof), >> @@ -802,8 +816,9 @@ >> * @param i the new value for the field of {@code obj} >> * being modified >> * >> - * @exception IllegalAccessException if the underlying field >> - * is inaccessible. >> + * @exception IllegalAccessException if this {@code Field} >> object >> + * enforces Java language access control and the >> underlying >> + * field is inaccessible. >> * @exception IllegalArgumentException if the specified object >> is not an >> * instance of the class or interface declaring the >> underlying >> * field (or a subclass or implementor thereof), >> @@ -831,8 +846,9 @@ >> * @param l the new value for the field of {@code obj} >> * being modified >> * >> - * @exception IllegalAccessException if the underlying field >> - * is inaccessible. >> + * @exception IllegalAccessException if this {@code Field} >> object >> + * enforces Java language access control and the >> underlying >> + * field is inaccessible. >> * @exception IllegalArgumentException if the specified object >> is not an >> * instance of the class or interface declaring the >> underlying >> * field (or a subclass or implementor thereof), >> @@ -860,8 +876,9 @@ >> * @param f the new value for the field of {@code obj} >> * being modified >> * >> - * @exception IllegalAccessException if the underlying field >> - * is inaccessible. >> + * @exception IllegalAccessException if this {@code Field} >> object >> + * enforces Java language access control and the >> underlying >> + * field is inaccessible. >> * @exception IllegalArgumentException if the specified object >> is not an >> * instance of the class or interface declaring the >> underlying >> * field (or a subclass or implementor thereof), >> @@ -889,8 +906,9 @@ >> * @param d the new value for the field of {@code obj} >> * being modified >> * >> - * @exception IllegalAccessException if the underlying field >> - * is inaccessible. >> + * @exception IllegalAccessException if this {@code Field} >> object >> + * enforces Java language access control and the >> underlying >> + * field is inaccessible. >> * @exception IllegalArgumentException if the specified object >> is not an >> * instance of the class or interface declaring the >> underlying >> * field (or a subclass or implementor thereof), >> From Alan.Bateman at oracle.com Mon Apr 4 09:09:14 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 04 Apr 2011 10:09:14 +0100 Subject: Review Request for 6751338: ZIP inflater/deflater performance In-Reply-To: <4D965A03.30107@oracle.com> References: <4D965A03.30107@oracle.com> Message-ID: <4D998ABA.5010400@oracle.com> Xueming Shen wrote: > Dave, Alan, > > Here is the final webrev based on Dave's patch and the jdk1.5 code > that does not > have the change for 6206933. JPRT job result suggests no new testing > failure and > my "non-scientific" benchmark test (to use GZIPOu/InputStream to > compress/ > decompress the rt.jar) does show relative performance gain. Will try > to run more > tests the weekend, but here is the webrev. > > http://cr.openjdk.java.net/~sherman/6751338/webrev/ I went through the webrev and also checked the old (pre-OpenJDK) code from before the changes for 6206933. The changes look okay to me. When testing with HotSpot then running with +PrintGCDetails and +PrintJNIGCStalls may be useful. One comment on the FlaterCriticalArray.java test is that it might be better to push this without the jtreg tags as the @ignore will cause it to be reported by jtreg as an "error". On the naming then maybe InflateDelatePerf.java might be better. -Alan From Alan.Bateman at oracle.com Mon Apr 4 12:34:03 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 04 Apr 2011 13:34:03 +0100 Subject: Code review request for 6543593 "(reflect) Clarify private final field mutability" In-Reply-To: <4D997748.2030003@oracle.com> References: <4D996600.2090808@oracle.com> <4D997198.4070905@oracle.com> <4D997748.2030003@oracle.com> Message-ID: <4D99BABB.706@oracle.com> Joe Darcy wrote: > > Fair enough. How about just for the setter methods > > + * @exception IllegalAccessException if this {@code Field} object > + * enforces Java language access control and the > underlying > + * field is inaccessible or is final. I think a comma before the "and" would make this a bit clearer (as the two conjunctions might force the reader to read it more than once to get the meaning). -Alan. From joe.darcy at oracle.com Mon Apr 4 17:04:22 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 04 Apr 2011 10:04:22 -0700 Subject: Code review request for 6543593 "(reflect) Clarify private final field mutability" In-Reply-To: <4D99BABB.706@oracle.com> References: <4D996600.2090808@oracle.com> <4D997198.4070905@oracle.com> <4D997748.2030003@oracle.com> <4D99BABB.706@oracle.com> Message-ID: <4D99FA16.1090400@oracle.com> Alan Bateman wrote: > Joe Darcy wrote: >> >> Fair enough. How about just for the setter methods >> >> + * @exception IllegalAccessException if this {@code Field} >> object >> + * enforces Java language access control and the >> underlying >> + * field is inaccessible or is final. > I think a comma before the "and" would make this a bit clearer (as the > two conjunctions might force the reader to read it more than once to > get the meaning). > > -Alan. How about for the setters * @exception IllegalAccessException if this {@code Field} object * enforces Java language access control and the underlying * field is either inaccessible or final. Updated webrev at http://cr.openjdk.java.net/~darcy/6543593.1/ Thanks, -Joe From bhavesh.patel at sun.com Mon Apr 4 17:16:53 2011 From: bhavesh.patel at sun.com (bhavesh.patel at sun.com) Date: Mon, 04 Apr 2011 17:16:53 +0000 Subject: hg: jdk7/tl/langtools: 7010344: Some of the html files do not have element in right context. Message-ID: <20110404171656.14EE74779A@hg.openjdk.java.net> Changeset: 734144b6b22f Author: bpatel Date: 2011-04-04 10:14 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/734144b6b22f 7010344: Some of the html files do not have element in right context. Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkInfoImpl.java ! test/com/sun/javadoc/testDeprecatedDocs/TestDeprecatedDocs.java ! test/com/sun/javadoc/testHref/TestHref.java ! test/com/sun/javadoc/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java ! test/com/sun/javadoc/testLinkOption/TestLinkOption.java ! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/com/sun/javadoc/testTypeParams/TestTypeParameters.java + test/com/sun/javadoc/testTypeParams/pkg/ClassUseTest3.java + test/com/sun/javadoc/testTypeParams/pkg/Foo4.java + test/com/sun/javadoc/testTypeParams/pkg/ParamTest2.java From mike.duigou at oracle.com Mon Apr 4 17:24:13 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 4 Apr 2011 10:24:13 -0700 Subject: Code review request for 6543593 "(reflect) Clarify private final field mutability" In-Reply-To: <4D99FA16.1090400@oracle.com> References: <4D996600.2090808@oracle.com> <4D997198.4070905@oracle.com> <4D997748.2030003@oracle.com> <4D99BABB.706@oracle.com> <4D99FA16.1090400@oracle.com> Message-ID: This looks good. Since accessibility is mutable I wonder if the wording should be: > * @exception IllegalAccessException if this {@code Field} object is > * enforcing Java language access control and the underlying > * field is either inaccessible or final. To me "is enforcing" is a stronger hint that access control is settable. Mike On Apr 4 2011, at 10:04 , Joe Darcy wrote: > Alan Bateman wrote: >> Joe Darcy wrote: >>> >>> Fair enough. How about just for the setter methods >>> >>> + * @exception IllegalAccessException if this {@code Field} object >>> + * enforces Java language access control and the underlying >>> + * field is inaccessible or is final. >> I think a comma before the "and" would make this a bit clearer (as the two conjunctions might force the reader to read it more than once to get the meaning). >> >> -Alan. > > How about for the setters > > * @exception IllegalAccessException if this {@code Field} object > * enforces Java language access control and the underlying > * field is either inaccessible or final. > > Updated webrev at > > http://cr.openjdk.java.net/~darcy/6543593.1/ > > Thanks, > > -Joe From joe.darcy at oracle.com Mon Apr 4 18:00:24 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 04 Apr 2011 11:00:24 -0700 Subject: Code review request for 6543593 "(reflect) Clarify private final field mutability" In-Reply-To: References: <4D996600.2090808@oracle.com> <4D997198.4070905@oracle.com> <4D997748.2030003@oracle.com> <4D99BABB.706@oracle.com> <4D99FA16.1090400@oracle.com> Message-ID: <4D9A0738.1060605@oracle.com> Mike Duigou wrote: > This looks good. > > Since accessibility is mutable I wonder if the wording should be: > > >> * @exception IllegalAccessException if this {@code Field} object is >> * enforcing Java language access control and the underlying >> * field is either inaccessible or final. >> > > > To me "is enforcing" is a stronger hint that access control is settable. > Okay; I'll push the change with "is enforcing" in Field and for consistency change the two instances of "enforces" to "is enforcing" in Method and Constructor. Thanks, -Joe > Mike > > On Apr 4 2011, at 10:04 , Joe Darcy wrote: > > >> Alan Bateman wrote: >> >>> Joe Darcy wrote: >>> >>>> Fair enough. How about just for the setter methods >>>> >>>> + * @exception IllegalAccessException if this {@code Field} object >>>> + * enforces Java language access control and the underlying >>>> + * field is inaccessible or is final. >>>> >>> I think a comma before the "and" would make this a bit clearer (as the two conjunctions might force the reader to read it more than once to get the meaning). >>> >>> -Alan. >>> >> How about for the setters >> >> * @exception IllegalAccessException if this {@code Field} object >> * enforces Java language access control and the underlying >> * field is either inaccessible or final. >> >> Updated webrev at >> >> http://cr.openjdk.java.net/~darcy/6543593.1/ >> >> Thanks, >> >> -Joe >> > > From Alan.Bateman at oracle.com Mon Apr 4 18:04:48 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 04 Apr 2011 19:04:48 +0100 Subject: Code review request for 6543593 "(reflect) Clarify private final field mutability" In-Reply-To: <4D99FA16.1090400@oracle.com> References: <4D996600.2090808@oracle.com> <4D997198.4070905@oracle.com> <4D997748.2030003@oracle.com> <4D99BABB.706@oracle.com> <4D99FA16.1090400@oracle.com> Message-ID: <4D9A0840.6070009@oracle.com> Joe Darcy wrote: > > How about for the setters > > * @exception IllegalAccessException if this {@code Field} object > * enforces Java language access control and the > underlying > * field is either inaccessible or final. > > Updated webrev at > > http://cr.openjdk.java.net/~darcy/6543593.1/ Adding in the word "either" makes this clear. Looks good. -Alan. From joe.darcy at oracle.com Mon Apr 4 18:23:01 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Mon, 04 Apr 2011 18:23:01 +0000 Subject: hg: jdk7/tl/jdk: 6543593: (reflect) Clarify private final field mutability Message-ID: <20110404182310.A03E34779E@hg.openjdk.java.net> Changeset: abb29a6bc9f3 Author: darcy Date: 2011-04-04 11:22 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/abb29a6bc9f3 6543593: (reflect) Clarify private final field mutability Reviewed-by: dholmes, alanb, mduigou ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/java/lang/reflect/Method.java From xueming.shen at oracle.com Mon Apr 4 18:31:03 2011 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Mon, 04 Apr 2011 18:31:03 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20110404183123.06565477A0@hg.openjdk.java.net> Changeset: 59f43e232481 Author: sherman Date: 2011-04-04 11:30 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/59f43e232481 6751338: ZIP inflater/deflater performance Summary: To use GetPrimitiveArrayCritical for bye array access Reviewed-by: bristor, alanb ! src/share/classes/java/util/zip/DeflaterOutputStream.java ! src/share/native/java/util/zip/Deflater.c ! src/share/native/java/util/zip/Inflater.c + test/java/util/zip/FlaterCriticalArray.java + test/java/util/zip/InflaterBufferSize.java Changeset: 83e5e081b4bb Author: sherman Date: 2011-04-04 11:36 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/83e5e081b4bb Merge From alan.bateman at oracle.com Mon Apr 4 18:33:18 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 04 Apr 2011 18:33:18 +0000 Subject: hg: jdk7/tl/jdk: 4 new changesets Message-ID: <20110404183358.21EF0477A1@hg.openjdk.java.net> Changeset: 05c9c157ec51 Author: alanb Date: 2011-04-04 18:09 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/05c9c157ec51 7029979: (fs) Path.toRealPath(boolean) should be toRealPath(LinkOption...) Reviewed-by: sherman ! src/share/classes/java/nio/file/Path.java ! src/share/classes/sun/nio/fs/Util.java ! src/share/classes/sun/util/calendar/ZoneInfoFile.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystemProvider.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipPath.java ! src/solaris/classes/sun/nio/fs/LinuxFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/SolarisFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/UnixPath.java ! src/solaris/classes/sun/nio/fs/UnixSecureDirectoryStream.java ! src/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java ! src/windows/classes/sun/nio/fs/WindowsPath.java ! test/java/nio/file/Files/CheckPermissions.java ! test/java/nio/file/Files/PassThroughFileSystem.java ! test/java/nio/file/Path/Misc.java Changeset: d5f0cf316f12 Author: alanb Date: 2011-04-04 18:12 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d5f0cf316f12 7033568: (file) Miscellaneous typos Reviewed-by: michaelm, mduigou ! src/share/classes/java/nio/file/Files.java Changeset: e9b9b0748794 Author: alanb Date: 2011-04-04 18:35 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e9b9b0748794 7030249: Eliminate use of LoadLibrary and other clean-ups Reviewed-by: ohair, chegar, mchung ! make/java/java/Makefile ! make/java/management/Makefile ! src/windows/native/com/sun/management/OperatingSystem_md.c ! src/windows/native/java/io/WinNTFileSystem_md.c ! src/windows/native/java/lang/java_props_md.c ! src/windows/native/sun/management/FileSystemImpl.c ! src/windows/native/sun/nio/fs/WindowsNativeDispatcher.c ! src/windows/native/sun/security/provider/WinCAPISeedGenerator.c Changeset: 9a3a1f8ad66b Author: alanb Date: 2011-04-04 19:32 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9a3a1f8ad66b Merge From alan.bateman at oracle.com Mon Apr 4 18:36:49 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 04 Apr 2011 18:36:49 +0000 Subject: hg: jdk7/tl/langtools: 2 new changesets Message-ID: <20110404183653.113C5477A2@hg.openjdk.java.net> Changeset: 7916df9c99be Author: alanb Date: 2011-04-04 18:10 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/7916df9c99be 7029979: (fs) Path.toRealPath(boolean) should be toRealPath(LinkOption...) Reviewed-by: mcimadamore, jjg ! src/share/classes/com/sun/tools/javac/nio/PathFileObject.java Changeset: 26b065bb4ee7 Author: alanb Date: 2011-04-04 19:36 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/26b065bb4ee7 Merge From mike.duigou at oracle.com Mon Apr 4 18:55:52 2011 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Mon, 04 Apr 2011 18:55:52 +0000 Subject: hg: jdk7/tl/jdk: 6565585: Remove critical section in Method.invoke, Constructor.newInstance, Field.getFieldAccessor improving performance Message-ID: <20110404185602.76D1E477A3@hg.openjdk.java.net> Changeset: 9f08a221e5f2 Author: mduigou Date: 2011-04-04 11:55 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9f08a221e5f2 6565585: Remove critical section in Method.invoke, Constructor.newInstance, Field.getFieldAccessor improving performance Reviewed-by: alanb, dholmes, briangoetz ! src/share/classes/java/lang/reflect/AccessibleObject.java ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/java/lang/reflect/Method.java From David.Holmes at oracle.com Mon Apr 4 22:31:54 2011 From: David.Holmes at oracle.com (David Holmes) Date: Tue, 05 Apr 2011 08:31:54 +1000 Subject: Code review request for 6543593 "(reflect) Clarify private final field mutability" In-Reply-To: <4D997748.2030003@oracle.com> References: <4D996600.2090808@oracle.com> <4D997198.4070905@oracle.com> <4D997748.2030003@oracle.com> Message-ID: <4D9A46DA.5060807@oracle.com> Joe Darcy said the following on 04/04/11 17:46: > David Holmes wrote: >> I'm not sure exactly what Bill was complaining about here, > > His specific issue was addressed by the diff ... > In other words, setAccessible(true) can succeed on a > java.lang.reflect.Field object but not on a field. Which is exactly what makes no sense to me - how could you possibly construe that setAccessible is applied to a field as opposed to a Field object ??? Anyway ... >> but using the same phrasing as Method and Constructor is a good thing. >> However, as the CR pertains in particular to the issue of final >> fields, I think for the setXXX cases the "@exception** >> IllegalAccessException" javadoc should also mention that it can be >> thrown because the field is final, not just because it is inaccessible. > > Fair enough. How about just for the setter methods > > + * @exception IllegalAccessException if this {@code Field} object > + * enforces Java language access control and the > underlying > + * field is inaccessible or is final. The latest version of this is fine. >> ** shouldn't all those @exception tags get converted to @throws? > > That would certainly be my style recommendation, but I wasn't looking to > make that change at the moment. Strike while the iron is hot :) Cheers, David > Thanks, > > -Joe > >> >> David >> >> Joe Darcy said the following on 04/04/11 16:32: >>> Hello. >>> >>> Please review the more precise wording added to >>> java.lang.reflect.Field to address bug >>> >>> 6543593 "(reflect) Clarify private final field mutability" >>> http://cr.openjdk.java.net/~darcy/6543593.0/ >>> >>> Full patch below. >>> >>> In describing when IllegalAccessException is thrown, Field now uses >>> phrasing consistent with that used by its sibling classes Method and >>> Constructor: >>> >>> "if this Method object enforces Java language access control and the >>> underlying method is inaccessible." >>> "if this Constructor object enforces Java language access control and >>> the underlying constructor is inaccessible." >>> >>> Thanks, >>> >>> -Joe >>> >>> --- old/src/share/classes/java/lang/reflect/Field.java 2011-04-03 >>> 23:25:40.000000000 -0700 >>> +++ new/src/share/classes/java/lang/reflect/Field.java 2011-04-03 >>> 23:25:39.000000000 -0700 >>> @@ -360,8 +360,9 @@ >>> * {@code obj}; primitive values are wrapped in an appropriate >>> * object before being returned >>> * >>> - * @exception IllegalAccessException if the underlying field >>> - * is inaccessible. >>> + * @exception IllegalAccessException if this {@code Field} >>> object >>> + * enforces Java language access control and the >>> underlying >>> + * field is inaccessible. >>> * @exception IllegalArgumentException if the specified object >>> is not an >>> * instance of the class or interface declaring the >>> underlying >>> * field (or a subclass or implementor thereof). >>> @@ -383,8 +384,9 @@ >>> * from >>> * @return the value of the {@code boolean} field >>> * >>> - * @exception IllegalAccessException if the underlying field >>> - * is inaccessible. >>> + * @exception IllegalAccessException if this {@code Field} >>> object >>> + * enforces Java language access control and the >>> underlying >>> + * field is inaccessible. >>> * @exception IllegalArgumentException if the specified object >>> is not >>> * an instance of the class or interface declaring the >>> * underlying field (or a subclass or implementor >>> @@ -410,8 +412,9 @@ >>> * from >>> * @return the value of the {@code byte} field >>> * >>> - * @exception IllegalAccessException if the underlying field >>> - * is inaccessible. >>> + * @exception IllegalAccessException if this {@code Field} >>> object >>> + * enforces Java language access control and the >>> underlying >>> + * field is inaccessible. >>> * @exception IllegalArgumentException if the specified object >>> is not >>> * an instance of the class or interface declaring the >>> * underlying field (or a subclass or implementor >>> @@ -439,8 +442,9 @@ >>> * from >>> * @return the value of the field converted to type {@code char} >>> * >>> - * @exception IllegalAccessException if the underlying field >>> - * is inaccessible. >>> + * @exception IllegalAccessException if this {@code Field} >>> object >>> + * enforces Java language access control and the >>> underlying >>> + * field is inaccessible. >>> * @exception IllegalArgumentException if the specified object >>> is not >>> * an instance of the class or interface declaring the >>> * underlying field (or a subclass or implementor >>> @@ -468,8 +472,9 @@ >>> * from >>> * @return the value of the field converted to type {@code short} >>> * >>> - * @exception IllegalAccessException if the underlying field >>> - * is inaccessible. >>> + * @exception IllegalAccessException if this {@code Field} >>> object >>> + * enforces Java language access control and the >>> underlying >>> + * field is inaccessible. >>> * @exception IllegalArgumentException if the specified object >>> is not >>> * an instance of the class or interface declaring the >>> * underlying field (or a subclass or implementor >>> @@ -497,8 +502,9 @@ >>> * from >>> * @return the value of the field converted to type {@code int} >>> * >>> - * @exception IllegalAccessException if the underlying field >>> - * is inaccessible. >>> + * @exception IllegalAccessException if this {@code Field} >>> object >>> + * enforces Java language access control and the >>> underlying >>> + * field is inaccessible. >>> * @exception IllegalArgumentException if the specified object >>> is not >>> * an instance of the class or interface declaring the >>> * underlying field (or a subclass or implementor >>> @@ -526,8 +532,9 @@ >>> * from >>> * @return the value of the field converted to type {@code long} >>> * >>> - * @exception IllegalAccessException if the underlying field >>> - * is inaccessible. >>> + * @exception IllegalAccessException if this {@code Field} >>> object >>> + * enforces Java language access control and the >>> underlying >>> + * field is inaccessible. >>> * @exception IllegalArgumentException if the specified object >>> is not >>> * an instance of the class or interface declaring the >>> * underlying field (or a subclass or implementor >>> @@ -555,8 +562,9 @@ >>> * from >>> * @return the value of the field converted to type {@code float} >>> * >>> - * @exception IllegalAccessException if the underlying field >>> - * is inaccessible. >>> + * @exception IllegalAccessException if this {@code Field} >>> object >>> + * enforces Java language access control and the >>> underlying >>> + * field is inaccessible. >>> * @exception IllegalArgumentException if the specified object >>> is not >>> * an instance of the class or interface declaring the >>> * underlying field (or a subclass or implementor >>> @@ -584,8 +592,9 @@ >>> * from >>> * @return the value of the field converted to type {@code double} >>> * >>> - * @exception IllegalAccessException if the underlying field >>> - * is inaccessible. >>> + * @exception IllegalAccessException if this {@code Field} >>> object >>> + * enforces Java language access control and the >>> underlying >>> + * field is inaccessible. >>> * @exception IllegalArgumentException if the specified object >>> is not >>> * an instance of the class or interface declaring the >>> * underlying field (or a subclass or implementor >>> @@ -626,9 +635,9 @@ >>> * {@code IllegalAccessException}. >>> * >>> *

If the underlying field is final, the method throws an >>> - * {@code IllegalAccessException} unless >>> - * {@code setAccessible(true)} has succeeded for this field >>> - * and this field is non-static. Setting a final field in this way >>> + * {@code IllegalAccessException} unless {@code >>> setAccessible(true)} >>> + * has succeeded for this {@code Field} object >>> + * and the field is non-static. Setting a final field in this way >>> * is meaningful only during deserialization or reconstruction of >>> * instances of classes with blank final fields, before they are >>> * made available for access by other parts of a program. Use in >>> @@ -658,8 +667,9 @@ >>> * @param value the new value for the field of {@code obj} >>> * being modified >>> * >>> - * @exception IllegalAccessException if the underlying field >>> - * is inaccessible. >>> + * @exception IllegalAccessException if this {@code Field} >>> object >>> + * enforces Java language access control and the >>> underlying >>> + * field is inaccessible. >>> * @exception IllegalArgumentException if the specified object >>> is not an >>> * instance of the class or interface declaring the >>> underlying >>> * field (or a subclass or implementor thereof), >>> @@ -686,8 +696,9 @@ >>> * @param z the new value for the field of {@code obj} >>> * being modified >>> * >>> - * @exception IllegalAccessException if the underlying field >>> - * is inaccessible. >>> + * @exception IllegalAccessException if this {@code Field} >>> object >>> + * enforces Java language access control and the >>> underlying >>> + * field is inaccessible. >>> * @exception IllegalArgumentException if the specified object >>> is not an >>> * instance of the class or interface declaring the >>> underlying >>> * field (or a subclass or implementor thereof), >>> @@ -715,8 +726,9 @@ >>> * @param b the new value for the field of {@code obj} >>> * being modified >>> * >>> - * @exception IllegalAccessException if the underlying field >>> - * is inaccessible. >>> + * @exception IllegalAccessException if this {@code Field} >>> object >>> + * enforces Java language access control and the >>> underlying >>> + * field is inaccessible. >>> * @exception IllegalArgumentException if the specified object >>> is not an >>> * instance of the class or interface declaring the >>> underlying >>> * field (or a subclass or implementor thereof), >>> @@ -744,8 +756,9 @@ >>> * @param c the new value for the field of {@code obj} >>> * being modified >>> * >>> - * @exception IllegalAccessException if the underlying field >>> - * is inaccessible. >>> + * @exception IllegalAccessException if this {@code Field} >>> object >>> + * enforces Java language access control and the >>> underlying >>> + * field is inaccessible. >>> * @exception IllegalArgumentException if the specified object >>> is not an >>> * instance of the class or interface declaring the >>> underlying >>> * field (or a subclass or implementor thereof), >>> @@ -773,8 +786,9 @@ >>> * @param s the new value for the field of {@code obj} >>> * being modified >>> * >>> - * @exception IllegalAccessException if the underlying field >>> - * is inaccessible. >>> + * @exception IllegalAccessException if this {@code Field} >>> object >>> + * enforces Java language access control and the >>> underlying >>> + * field is inaccessible. >>> * @exception IllegalArgumentException if the specified object >>> is not an >>> * instance of the class or interface declaring the >>> underlying >>> * field (or a subclass or implementor thereof), >>> @@ -802,8 +816,9 @@ >>> * @param i the new value for the field of {@code obj} >>> * being modified >>> * >>> - * @exception IllegalAccessException if the underlying field >>> - * is inaccessible. >>> + * @exception IllegalAccessException if this {@code Field} >>> object >>> + * enforces Java language access control and the >>> underlying >>> + * field is inaccessible. >>> * @exception IllegalArgumentException if the specified object >>> is not an >>> * instance of the class or interface declaring the >>> underlying >>> * field (or a subclass or implementor thereof), >>> @@ -831,8 +846,9 @@ >>> * @param l the new value for the field of {@code obj} >>> * being modified >>> * >>> - * @exception IllegalAccessException if the underlying field >>> - * is inaccessible. >>> + * @exception IllegalAccessException if this {@code Field} >>> object >>> + * enforces Java language access control and the >>> underlying >>> + * field is inaccessible. >>> * @exception IllegalArgumentException if the specified object >>> is not an >>> * instance of the class or interface declaring the >>> underlying >>> * field (or a subclass or implementor thereof), >>> @@ -860,8 +876,9 @@ >>> * @param f the new value for the field of {@code obj} >>> * being modified >>> * >>> - * @exception IllegalAccessException if the underlying field >>> - * is inaccessible. >>> + * @exception IllegalAccessException if this {@code Field} >>> object >>> + * enforces Java language access control and the >>> underlying >>> + * field is inaccessible. >>> * @exception IllegalArgumentException if the specified object >>> is not an >>> * instance of the class or interface declaring the >>> underlying >>> * field (or a subclass or implementor thereof), >>> @@ -889,8 +906,9 @@ >>> * @param d the new value for the field of {@code obj} >>> * being modified >>> * >>> - * @exception IllegalAccessException if the underlying field >>> - * is inaccessible. >>> + * @exception IllegalAccessException if this {@code Field} >>> object >>> + * enforces Java language access control and the >>> underlying >>> + * field is inaccessible. >>> * @exception IllegalArgumentException if the specified object >>> is not an >>> * instance of the class or interface declaring the >>> underlying >>> * field (or a subclass or implementor thereof), >>> > From kumar.x.srinivasan at oracle.COM Mon Apr 4 23:36:34 2011 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Mon, 04 Apr 2011 16:36:34 -0700 Subject: Please review: 7029048: LD_LIBRARY_PATH launcher changes Message-ID: <4D9A5602.1040305@oracle.COM> Hello core-libs friends, Background: Earlier in the jdk7 development setting of LD_LIBRARY_PATH was purged in the launcher, this is a good thing!, Joe has an excellent blog which explains the rational etc. etc. here: http://blogs.sun.com/darcy/entry/purging_ld_library_path More background: Unfortunately!, the library versioning that Kelly proposed earlier on build-dev, is infeasible for jdk7, though this is the correct approach. Thus the approach contained here, allows us to provide a transitional path to the version scheme in the future. This is also the reason, the c-code is encapsulated within a conditional and the test has been separated, such that these can be jettisoned when required. This explains the current proposed fix: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7029048 The old changeset for reference: The old changeset: http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/de45eac5670e and finally here is the proposed webrev: http://cr.openjdk.java.net/~ksrini/7029048/webrev.0/ Thanks Kumar -------------- next part -------------- An embedded message was scrubbed... From: "Kelly O'Hair" Subject: Need preliminary reviewers: Solaris/Linux shared library version changes Date: Wed, 16 Mar 2011 18:59:36 -0700 Size: 8245 URL: From joe.darcy at oracle.com Mon Apr 4 23:52:20 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Mon, 04 Apr 2011 16:52:20 -0700 Subject: Code review request for 6543593 "(reflect) Clarify private final field mutability" In-Reply-To: <4D9A46DA.5060807@oracle.com> References: <4D996600.2090808@oracle.com> <4D997198.4070905@oracle.com> <4D997748.2030003@oracle.com> <4D9A46DA.5060807@oracle.com> Message-ID: <4D9A59B4.9030902@oracle.com> On 4/4/2011 3:31 PM, David Holmes wrote: > Joe Darcy said the following on 04/04/11 17:46: >> David Holmes wrote: >> [snip] > >>> ** shouldn't all those @exception tags get converted to @throws? >> >> That would certainly be my style recommendation, but I wasn't looking >> to make that change at the moment. > > Strike while the iron is hot :) > > Cheers, > David > For the packages I look after, I've previously done general purges of obsolete javadoc style, replacing Foo for {@code Foo}, etc. The great @exception purge may start occurring early in JDK 8! -Joe From neil.richards at ngmr.net Tue Apr 5 14:28:34 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Tue, 5 Apr 2011 15:28:34 +0100 Subject: Request for review: 6312706: Map entrySet iterators should return different entries on each call to next() In-Reply-To: <52D0B0FD-470C-4918-B973-84B40EBD0FA1@oracle.com> References: <1300927894.11817.45.camel@chalkhill> <5EAE61D7-847F-4A35-BB23-FF5F93EC7255@oracle.com> <754C9AD9-E097-4276-B4CC-47750DC3AB57@oracle.com> <1301127009.22505.116.camel@chalkhill> <1A09DE36-D1C0-4F41-A2C2-12178351CA91@oracle.com> <1301501235.7943.68.camel@chalkhill> <52D0B0FD-470C-4918-B973-84B40EBD0FA1@oracle.com> Message-ID: On 31 March 2011 20:59, Mike Duigou wrote: > I will make the modification as Jason suggested and commit this issue today. > > Mike Can you point me to where the change is for this issue? (I can't see it in the jdk7/tl/jdk repository) Thanks, Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From bristor at yahoo.com Tue Apr 5 15:41:00 2011 From: bristor at yahoo.com (Dave Bristor) Date: Tue, 5 Apr 2011 08:41:00 -0700 (PDT) Subject: Review Request for 6751338: ZIP inflater/deflater performance In-Reply-To: <4D998ABA.5010400@oracle.com> Message-ID: <21463.31660.qm@web31002.mail.mud.yahoo.com> @Alan: Great idea about looking at runs with +PrintGCDetails and +PrintJNIGCStalls! Wish I had thought of that. About @ignore: it seems fine remove that, though if there are performance degradations the test won't catch them of course. Renaming the test seems fine. @Sherman: updating this_off is fine as "documentation". Dave --- On Mon, 4/4/11, Alan Bateman wrote: > From: Alan Bateman > Subject: Re: Review Request for 6751338: ZIP inflater/deflater performance > To: "Xueming Shen" > Cc: "Dave Bristor" , "core-libs-dev" > Date: Monday, April 4, 2011, 2:09 AM > Xueming Shen wrote: > > Dave, Alan, > > > > Here is the final webrev based on Dave's patch and the > jdk1.5 code that does not > > have the change for 6206933. JPRT job result suggests > no new testing failure and > > my "non-scientific" benchmark test (to use > GZIPOu/InputStream to compress/ > > decompress the rt.jar) does show relative performance > gain. Will try to run more > > tests the weekend, but here is the webrev. > > > > http://cr.openjdk.java.net/~sherman/6751338/webrev/ > I went through the webrev and also checked the old > (pre-OpenJDK) code from before the changes for 6206933. The > changes look okay to me. When testing with HotSpot then > running with +PrintGCDetails and +PrintJNIGCStalls may be > useful. > > One comment on the FlaterCriticalArray.java test is that it > might be better to push this without the jtreg tags as the > @ignore will cause it to be reported by jtreg as an "error". > On the naming then maybe InflateDelatePerf.java might be > better. > > -Alan > From mike.duigou at oracle.com Tue Apr 5 16:33:23 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 5 Apr 2011 09:33:23 -0700 Subject: Request for review: 6312706: Map entrySet iterators should return different entries on each call to next() In-Reply-To: References: <1300927894.11817.45.camel@chalkhill> <5EAE61D7-847F-4A35-BB23-FF5F93EC7255@oracle.com> <754C9AD9-E097-4276-B4CC-47750DC3AB57@oracle.com> <1301127009.22505.116.camel@chalkhill> <1A09DE36-D1C0-4F41-A2C2-12178351CA91@oracle.com> <1301501235.7943.68.camel@chalkhill> <52D0B0FD-470C-4918-B973-84B40EBD0FA1@oracle.com> Message-ID: It should go in today hopefully. I didn't get it committed in time for the cut for b138 because the I hadn't had a chance to rerun the full regression suite after making the change that Jason Mehrens suggested. That test job ran overnight but failed for unrelated reasons so I'm re-running it today. The regression suite has passed on my local system so I'm pretty confident that it should also pass on the regression cluster (windows/solaris/linux+x86/x64, 8 configs in all). Mike On Apr 5 2011, at 07:28 , Neil Richards wrote: > On 31 March 2011 20:59, Mike Duigou wrote: >> I will make the modification as Jason suggested and commit this issue today. >> >> Mike > > Can you point me to where the change is for this issue? > > (I can't see it in the jdk7/tl/jdk repository) > > Thanks, > Neil From mandy.chung at oracle.com Tue Apr 5 23:39:29 2011 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 05 Apr 2011 16:39:29 -0700 Subject: Please review: 7029048: LD_LIBRARY_PATH launcher changes In-Reply-To: <4D9A5602.1040305@oracle.COM> References: <4D9A5602.1040305@oracle.COM> Message-ID: <4D9BA831.8070102@oracle.com> Kumar, This looks okay to me and the change in java_md.c is mostly bringing back what you purged. http://hg.openjdk.java.net/jdk7/jdk7/jdk/diff/de45eac5670e/src/solaris/bin/java_md.c I briefly compared this fix with that changeset and a lot of testing to verify this fix. Minor comment: java_md.c a typo in L128 "propogate" - should be "propagate" test/tools/launcher/Test7029048.java: should it be marked with "othervm" test in @run clause? Mandy On 04/04/11 16:36, Kumar Srinivasan wrote: > Hello core-libs friends, > > Background: > Earlier in the jdk7 development setting of LD_LIBRARY_PATH was purged > in the launcher, this is a good thing!, Joe has an excellent blog > which explains > the rational etc. etc. here: > http://blogs.sun.com/darcy/entry/purging_ld_library_path > > More background: > Unfortunately!, the library versioning that Kelly proposed earlier on > build-dev, > is infeasible for jdk7, though this > is the correct > approach. > > Thus the approach contained here, allows us to provide a transitional > path to the > version scheme in the future. This is also the reason, the c-code is > encapsulated > within a conditional and the test has been separated, such that these > can be jettisoned > when required. > > This explains the current proposed fix: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7029048 > > The old changeset for reference: > The old changeset: > http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/de45eac5670e > > and finally here is the proposed webrev: > http://cr.openjdk.java.net/~ksrini/7029048/webrev.0/ > > Thanks > Kumar From mike.skells at talk21.com Tue Apr 5 23:42:28 2011 From: mike.skells at talk21.com (mike.skells at talk21.com) Date: Wed, 6 Apr 2011 00:42:28 +0100 (BST) Subject: proposal to optimise the performance of the Jar utility Message-ID: <479637.89357.qm@web86603.mail.ird.yahoo.com> Hi, Not sure if this is too late for Java 7 but I have made some optimisations for a client to improve the performance of the jar utility in their environment, and would like to promite then into the main code base The optimisations that I have performed are 1. Allowing the Jar utility to have other compression levels (currently it allows default (5) only) 2. Multi-threading, and pipelining the the file information and access 3. multi-threading the compression and file writing A little background A part of the development process of where I work they regularly Jar the content of the working projects as part of the distribution to remote systems. This is a large and complex code base of 6 million LOC and growing. The Jar file ends up compressed to approx 100Mb, Uncompressed the jar size is approx 245mb, about 4-5 times the size of rt.jar. I was looking at ways to improve the performance as this activity occurs several times a day for dozens of developers In essence when compressing a new jar file the jar utility is single threaded and staged. Forgive me if this is an oversimplification first it works out all of the files that are specified, buffering the file names, (IO bound) then it iterates through the files, and for each file, it load the file information, and then the file content sending it to a JarOutputStream, (CPU bound or IO bound depending on the IO speed) The JarOutputStream has a compression of 0 (just store) or 5 (the default), and the jar writing is single threaded by the design of the JarOutputStream The process of creation of a Jar took about 20 seconds in windows with the help of an SSD, and considerable longer without one, and was CPU bound to one CPU core ---- The changes that I made were 1. Allow deferent compression levels (for us a compression level of 1 increases the file size of the Jar to 110 Mb but reduces the CPU load in compression to approx 30% of what it was (rough estimate) 2. pipelining the file access 2.1 one thread is started for each file root (-C on the Jar command line), which scans for files and places the file information into a blocking queue(Q1), which I set to abretrary size of 200 items 2.2 one thread pool of 10 threads reads the file information from the queue (Q1) and buffers the file content to a specified size (again I specified an arbetrary size limit of 25K for a file, and places the buffered content into a queue(q2) (again arbetrary size of 10 items 2.3 one thread takes the filecontent from Q2 and compresses it or checksums it and adds it the the JarOutputStream. This process is single threaded due to the design of the JarOutputStream some other minor performance gain occurred by increasing the buffer on the output stream to reduce the IO load The end result is that the process takes about approx 5 seconds in the same configuration The above is in use in production configuration for a few months now As a home project I have completed some enhancements to the JarOutputStream, and produced a JarWriter that allows multiple threads to work concurrently deflating or calculating checksums, which seems to test OK for the test cases that Ihave generated,and successfully loads my quad core home dev machine on all cores. Each thread allocates a buffer, and the thread compresses a files into the buffer, only blocking other threads whenthe buffer is written to the output (which is after the compression is complete, unless the file is too large to compress This JarWriter is not API compatable with the JarOutputStream, it is not a stream. It allows the programmer to write a record based of the file information and an input stream, and is threadsafe. It is not a drop in replacement for JarOutputStream I am not an expert in the ZIp file format, but much of the code from ZipOutputStream is unchanged, just restructured --- I did think that there is some scope for improvement, that I have not looked at a. thresholding of file size for compression (very small files dont compress well b. some file types dont compress well (e.g. png, jpeg) as they have been compressed already) c. using NIO to parallelise the loading of the file information or content d. some pre-charging of the deflator dictionary (e.g. a class file contains the strings of the class name and packages), but this would make the format incompatable with zip, and require changes to the JVM to be useful, and is a long way from my comform zone, or skill set. This would reduce the file size -- What is the view of the readers. Is this something, or at least some parts of this that could be incorperated into Java 7 or is this too late on the dev cycle regards Mike From kumar.x.srinivasan at oracle.COM Tue Apr 5 23:44:49 2011 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Tue, 05 Apr 2011 16:44:49 -0700 Subject: Please review: 7029048: LD_LIBRARY_PATH launcher changes In-Reply-To: <4D9BA831.8070102@oracle.com> References: <4D9A5602.1040305@oracle.COM> <4D9BA831.8070102@oracle.com> Message-ID: <4D9BA971.7080404@oracle.COM> Mandy, > > This looks okay to me and the change in java_md.c is mostly bringing > back what you purged. > > http://hg.openjdk.java.net/jdk7/jdk7/jdk/diff/de45eac5670e/src/solaris/bin/java_md.c > > I briefly compared this fix with that changeset and a lot of testing > to verify this fix. Minor comment: > java_md.c a typo in L128 "propogate" - should be "propagate" oops will do. > test/tools/launcher/Test7029048.java: should it be marked with > "othervm" test in @run clause? No. not really, since the "driver/main" creates "test vectors" and compares them, ie. it configures the inputs, reaps the output, and analyzes the results, therefore this can remain in the samevm. Thanks Kumar > > Mandy > > On 04/04/11 16:36, Kumar Srinivasan wrote: >> Hello core-libs friends, >> >> Background: >> Earlier in the jdk7 development setting of LD_LIBRARY_PATH was purged >> in the launcher, this is a good thing!, Joe has an excellent blog >> which explains >> the rational etc. etc. here: >> http://blogs.sun.com/darcy/entry/purging_ld_library_path >> >> More background: >> Unfortunately!, the library versioning that Kelly proposed earlier >> on build-dev, >> is infeasible for jdk7, though this >> is the correct >> approach. >> >> Thus the approach contained here, allows us to provide a >> transitional path to the >> version scheme in the future. This is also the reason, the c-code is >> encapsulated >> within a conditional and the test has been separated, such that these >> can be jettisoned >> when required. >> >> This explains the current proposed fix: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7029048 >> >> The old changeset for reference: >> The old changeset: >> http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/de45eac5670e >> >> and finally here is the proposed webrev: >> http://cr.openjdk.java.net/~ksrini/7029048/webrev.0/ >> >> Thanks >> Kumar > From Alan.Bateman at oracle.com Wed Apr 6 11:07:23 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 06 Apr 2011 12:07:23 +0100 Subject: proposal to optimise the performance of the Jar utility In-Reply-To: <479637.89357.qm@web86603.mail.ird.yahoo.com> References: <479637.89357.qm@web86603.mail.ird.yahoo.com> Message-ID: <4D9C496B.6080001@oracle.com> mike.skells at talk21.com wrote: > Hi, > Not sure if this is too late for Java 7 but I have made some optimisations for a > client to improve the performance of the jar utility in their environment, and > would like to promite then into the main code base > It's been a long standing issue that creating JAR files with the jar command has been very slow. Sherman did some good improvements in jdk7 [1], and I think they've been back-ported into Oracle jdk6 releases too. Also Martin Buchholz and Jeremy Mason fixed another performance issue for cases where the -C option is used to specify many directories [2]. Combined, this leads to some good improvements compared to older releases of the JDK. Sherman has a blog entry [3] on this topic that details some of the results. I've no doubt more can be done and it sounds like you've made it your mission to get it as fast as possible (which is great). I would suggest sending a webrev or a patch so that the changes can be discussed. Also it would be good to include some performance figures comparing the implementation against jdk7. Just to set expectations, it probably is a bit late in jdk7 for extensive or risky changes but we probably need to see extend of the changes to judge that. If there are a lot of changes then one idea is to push it into jdk8 first and let it bake there for a while. -Alan [1] http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/57dc40ece164 [2] http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/ce55eb6668d9 [3] http://blogs.sun.com/CoreJavaTechTips/entry/superduper_slow_jar From mike.duigou at oracle.com Wed Apr 6 16:54:22 2011 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Wed, 06 Apr 2011 16:54:22 +0000 Subject: hg: jdk7/tl/jdk: 6312706: Map entrySet iterators should return different entries on each call to next() Message-ID: <20110406165432.222754784A@hg.openjdk.java.net> Changeset: c1e87a18e46a Author: mduigou Date: 2011-04-06 09:31 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c1e87a18e46a 6312706: Map entrySet iterators should return different entries on each call to next() Reviewed-by: mduigou, alanb Contributed-by: Neil Richards ! src/share/classes/java/util/EnumMap.java ! src/share/classes/java/util/IdentityHashMap.java + test/java/util/EnumMap/DistinctEntrySetElements.java + test/java/util/EnumMap/EntrySetIteratorRemoveInvalidatesEntry.java + test/java/util/EnumMap/SimpleSerialization.java + test/java/util/IdentityHashMap/DistinctEntrySetElements.java + test/java/util/IdentityHashMap/EntrySetIteratorRemoveInvalidatesEntry.java + test/java/util/concurrent/ConcurrentHashMap/DistinctEntrySetElements.java From naoto.sato at oracle.com Wed Apr 6 17:54:01 2011 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 06 Apr 2011 17:54:01 +0000 Subject: hg: jdk7/tl/jdk: 7031546: test/java/util/ResourceBundle/Bug4168625Test.java fails on solaris10u9 sparc. Message-ID: <20110406175411.BE6CD4784D@hg.openjdk.java.net> Changeset: ea45b4ed1758 Author: naoto Date: 2011-04-06 10:53 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ea45b4ed1758 7031546: test/java/util/ResourceBundle/Bug4168625Test.java fails on solaris10u9 sparc. Reviewed-by: okutsu ! test/java/util/ResourceBundle/Bug4168625Test.java From xueming.shen at oracle.com Wed Apr 6 18:04:25 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 06 Apr 2011 11:04:25 -0700 Subject: proposal to optimise the performance of the Jar utility In-Reply-To: <479637.89357.qm@web86603.mail.ird.yahoo.com> References: <479637.89357.qm@web86603.mail.ird.yahoo.com> Message-ID: <4D9CAB29.5090009@oracle.com> Hi Mike, We are in the final stage of the JDK7 development, work like this is unlikely to get in the last minute. I have filed a CR/RFE to trace this issue, we can use this CR as the start point for the discussion and target for some jdk7 update releases or JDK8. 7034403: proposal to optimise the performance of the Jar utility Thanks, Sherman On 04/05/2011 04:42 PM, mike.skells at talk21.com wrote: > Hi, > Not sure if this is too late for Java 7 but I have made some optimisations for a > client to improve the performance of the jar utility in their environment, and > would like to promite then into the main code base > > The optimisations that I have performed are > > 1. Allowing the Jar utility to have other compression levels (currently it > allows default (5) only) > 2. Multi-threading, and pipelining the the file information and access > 3. multi-threading the compression and file writing > > A little background > A part of the development process of where I work they regularly Jar the content > of the working projects as part of the distribution to remote systems. This is a > large and complex code base of 6 million LOC and growing. The Jar file ends up > compressed to approx 100Mb, Uncompressed the jar size is approx 245mb, about 4-5 > times the size of rt.jar. > > I was looking at ways to improve the performance as this activity occurs several > times a day for dozens of developers > > In essence when compressing a new jar file the jar utility is single threaded > and staged. Forgive me if this is an oversimplification > > first it works out all of the files that are specified, buffering the file > names, (IO bound) > then it iterates through the files, and for each file, it load the file > information, and then the file content sending it to a JarOutputStream, (CPU > bound or IO bound depending on the IO speed) > > The JarOutputStream has a compression of 0 (just store) or 5 (the default), and > the jar writing is single threaded by the design of the JarOutputStream > > The process of creation of a Jar took about 20 seconds in windows with the help > of an SSD, and considerable longer without one, and was CPU bound to one CPU > core > > ---- > The changes that I made were > 1. Allow deferent compression levels (for us a compression level of 1 increases > the file size of the Jar to 110 Mb but reduces the CPU load in compression to > approx 30% of what it was (rough estimate) > 2. pipelining the file access > 2.1 one thread is started for each file root (-C on the Jar command line), > which scans for files and places the file information into a blocking queue(Q1), > which I set to abretrary size of 200 items > 2.2 one thread pool of 10 threads reads the file information from the queue > (Q1) and buffers the file content to a specified size (again I specified an > arbetrary size limit of 25K for a file, and places the buffered content into a > queue(q2) (again arbetrary size of 10 items > 2.3 one thread takes the filecontent from Q2 and compresses it or checksums > it and adds it the the JarOutputStream. This process is single threaded due to > the design of the JarOutputStream > > some other minor performance gain occurred by increasing the buffer on the > output stream to reduce the IO load > > The end result is that the process takes about approx 5 seconds in the same > configuration > > The above is in use in production configuration for a few months now > > As a home project I have completed some enhancements to the JarOutputStream, and > produced a JarWriter that allows multiple threads to work concurrently deflating > or calculating checksums, which seems to test OK for the test cases that Ihave > generated,and successfully loads my quad core home dev machine on all cores. > Each thread allocates a buffer, and the thread compresses a files into the > buffer, only blocking other threads whenthe buffer is written to the output > (which is after the compression is complete, unless the file is too large to > compress > > This JarWriter is not API compatable with the JarOutputStream, it is not a > stream. It allows the programmer to write a record based of the file information > and an input stream, and is threadsafe. It is not a drop in replacement for > JarOutputStream > I am not an expert in the ZIp file format, but much of the code from > ZipOutputStream is unchanged, just restructured > --- > I did think that there is some scope for improvement, that I have not looked at > a. thresholding of file size for compression (very small files dont compress > well > b. some file types dont compress well (e.g. png, jpeg) as they have been > compressed already) > c. using NIO to parallelise the loading of the file information or content > d. some pre-charging of the deflator dictionary (e.g. a class file contains the > strings of the class name and packages), but this would make the format > incompatable with zip, and require changes to the JVM to be useful, and is a > long way from my comform zone, or skill set. This would reduce the file size > > -- > What is the view of the readers. Is this something, or at least some parts of > this that could be incorperated into Java 7 or is this too late on the dev cycle > > regards > > Mike From alan.bateman at oracle.com Wed Apr 6 19:54:39 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 06 Apr 2011 19:54:39 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20110406195458.7C1D947854@hg.openjdk.java.net> Changeset: cd86fbf11e33 Author: alanb Date: 2011-04-06 20:51 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cd86fbf11e33 7034155: (ch) NullPointerException in sun.io.ch.IOUtil when OOM is thrown Reviewed-by: forax ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/share/classes/sun/nio/ch/IOUtil.java Changeset: e279678f9f66 Author: alanb Date: 2011-04-06 20:54 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e279678f9f66 Merge From xueming.shen at oracle.com Wed Apr 6 20:16:38 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 06 Apr 2011 13:16:38 -0700 Subject: Codereview request for 7033561: Missing Unicode Script aliases Message-ID: <4D9CCA26.8050502@oracle.com> It appears the aliases mapping for Character.UnicodeScript is not updated accordingly when we upgraded the Unicode support to 6.0 for JDK7. The difference between the previous version (5.2) and 6.0 of the aliases are these 3 missing names reported in #7033561. The webrev with the change is at http://cr.openjdk.java.net/~sherman/7033561/webrev Thanks, Sherman From Alan.Bateman at oracle.com Wed Apr 6 20:29:46 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 06 Apr 2011 21:29:46 +0100 Subject: Codereview request for 7033561: Missing Unicode Script aliases In-Reply-To: <4D9CCA26.8050502@oracle.com> References: <4D9CCA26.8050502@oracle.com> Message-ID: <4D9CCD3A.40001@oracle.com> Xueming Shen wrote: > > It appears the aliases mapping for Character.UnicodeScript is not > updated accordingly when > we upgraded the Unicode support to 6.0 for JDK7. The difference > between the previous version > (5.2) and 6.0 of the aliases are these 3 missing names reported in > #7033561. > > The webrev with the change is at > > http://cr.openjdk.java.net/~sherman/7033561/webrev > > Thanks, > Sherman > It looks like test/java/lang/Character/CheckScript.java is missing the GPL header, might be good to add it while you are there. -Alan. From xueming.shen at oracle.com Wed Apr 6 20:42:52 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 06 Apr 2011 13:42:52 -0700 Subject: Codereview request for 7033561: Missing Unicode Script aliases In-Reply-To: <4D9CCD3A.40001@oracle.com> References: <4D9CCA26.8050502@oracle.com> <4D9CCD3A.40001@oracle.com> Message-ID: <4D9CD04C.4060105@oracle.com> Thanks! webrev has been updated accordingly. -Sherman On 04/06/2011 01:29 PM, Alan Bateman wrote: > Xueming Shen wrote: >> >> It appears the aliases mapping for Character.UnicodeScript is not >> updated accordingly when >> we upgraded the Unicode support to 6.0 for JDK7. The difference >> between the previous version >> (5.2) and 6.0 of the aliases are these 3 missing names reported in >> #7033561. >> >> The webrev with the change is at >> >> http://cr.openjdk.java.net/~sherman/7033561/webrev >> >> Thanks, >> Sherman >> > It looks like test/java/lang/Character/CheckScript.java is missing the > GPL header, might be good to add it while you are there. > > -Alan. From lance.andersen at oracle.com Wed Apr 6 21:38:20 2011 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Wed, 06 Apr 2011 21:38:20 +0000 Subject: hg: jdk7/tl/jdk: 7034471: Wrap registeredDrivers in DriverManager Message-ID: <20110406213829.B1FDD4785A@hg.openjdk.java.net> Changeset: d5bc10b1aa2c Author: lancea Date: 2011-04-06 17:37 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d5bc10b1aa2c 7034471: Wrap registeredDrivers in DriverManager Reviewed-by: alanb, briangoetz ! src/share/classes/java/sql/DriverManager.java From weijun.wang at oracle.com Thu Apr 7 00:53:52 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Thu, 07 Apr 2011 00:53:52 +0000 Subject: hg: jdk7/tl/jdk: 7032354: no-addresses should not be used on acceptor side Message-ID: <20110407005402.E835C47862@hg.openjdk.java.net> Changeset: 06c7ee973e05 Author: weijun Date: 2011-04-07 08:51 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/06c7ee973e05 7032354: no-addresses should not be used on acceptor side Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/KrbApReq.java ! test/sun/security/krb5/auto/KDC.java + test/sun/security/krb5/auto/NoAddresses.java From joe.darcy at oracle.com Thu Apr 7 02:31:13 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Thu, 07 Apr 2011 02:31:13 +0000 Subject: hg: jdk7/tl/langtools: 7033809: Rename "disjunctive" to "union" in javax.lang.model Message-ID: <20110407023119.79C0E47868@hg.openjdk.java.net> Changeset: 8cc5b440fdde Author: darcy Date: 2011-04-06 19:30 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/8cc5b440fdde 7033809: Rename "disjunctive" to "union" in javax.lang.model Reviewed-by: mcimadamore, jjg - src/share/classes/com/sun/source/tree/DisjunctiveTypeTree.java ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/source/tree/TreeVisitor.java + src/share/classes/com/sun/source/tree/UnionTypeTree.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java - src/share/classes/javax/lang/model/type/DisjunctiveType.java ! src/share/classes/javax/lang/model/type/TypeKind.java ! src/share/classes/javax/lang/model/type/TypeVisitor.java + src/share/classes/javax/lang/model/type/UnionType.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor6.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor7.java ! src/share/classes/javax/lang/model/util/SimpleTypeVisitor7.java ! src/share/classes/javax/lang/model/util/TypeKindVisitor7.java From kumar.x.srinivasan at oracle.com Thu Apr 7 02:32:18 2011 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Thu, 07 Apr 2011 02:32:18 +0000 Subject: hg: jdk7/tl/jdk: 7033954: (launcher) Launchers not built with mapfiles Message-ID: <20110407023228.25FB447869@hg.openjdk.java.net> Changeset: 244b27bb14f8 Author: ksrini Date: 2011-04-06 19:31 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/244b27bb14f8 7033954: (launcher) Launchers not built with mapfiles Reviewed-by: ohair ! make/com/sun/java/pack/Makefile + make/com/sun/java/pack/mapfile-vers-unpack200 ! make/common/Mapfile-vers.gmk ! make/common/Program.gmk ! make/java/main/java/Makefile ! make/java/main/java/mapfile-amd64 ! make/java/main/java/mapfile-i586 ! make/java/main/java/mapfile-sparc ! make/java/main/java/mapfile-sparcv9 From joe.darcy at oracle.com Thu Apr 7 06:29:02 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 06 Apr 2011 23:29:02 -0700 Subject: Code review request for 6998871 "Support making the Throwable.stackTrace field immutable" Message-ID: <4D9D59AE.7040701@oracle.com> Hello. Returning to some earlier work, I've developed a proposed fix for 6998871 "Support making the Throwable.stackTrace field immutable" http://cr.openjdk.java.net/~darcy/6998871.2/ One constructor of Throwable now takes an additional boolean argument to make the stack trace information immutable. Analogous constructors are added to Exception, RuntimeException, and Error. Mandy and David have already reviewed the change; I'm interested in getting additional feedback on the design of the API. Cheers, -Joe From dmytro_sheyko at hotmail.com Thu Apr 7 07:50:24 2011 From: dmytro_sheyko at hotmail.com (Dmytro Sheyko) Date: Thu, 7 Apr 2011 14:50:24 +0700 Subject: Code review request for 6998871 "Support making the Throwable.stackTrace field immutable" In-Reply-To: <4D9D59AE.7040701@oracle.com> References: <4D9D59AE.7040701@oracle.com> Message-ID: Just wonder what is the purpose of dummy parameter in native fillInStackTrace method. Couldn't we simply rename it (e.g. to fillInStackTrace0) > Date: Wed, 6 Apr 2011 23:29:02 -0700 > From: joe.darcy at oracle.com > To: core-libs-dev at openjdk.java.net > Subject: Code review request for 6998871 "Support making the Throwable.stackTrace field immutable" > > Hello. > > Returning to some earlier work, I've developed a proposed fix for > > 6998871 "Support making the Throwable.stackTrace field immutable" > http://cr.openjdk.java.net/~darcy/6998871.2/ > > One constructor of Throwable now takes an additional boolean argument to > make the stack trace information immutable. Analogous constructors are > added to Exception, RuntimeException, and Error. > > Mandy and David have already reviewed the change; I'm interested in > getting additional feedback on the design of the API. > > Cheers, > > -Joe From David.Holmes at oracle.com Thu Apr 7 08:03:42 2011 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 07 Apr 2011 18:03:42 +1000 Subject: Code review request for 6998871 "Support making the Throwable.stackTrace field immutable" In-Reply-To: References: <4D9D59AE.7040701@oracle.com> Message-ID: <4D9D6FDE.1050208@oracle.com> Dmytro Sheyko said the following on 04/07/11 17:50: > Just wonder what is the purpose of dummy parameter in native fillInStackTrace method. Couldn't we simply rename it (e.g. to fillInStackTrace0) Using an overload instead of renaming the native method was initially done to avoid having to make changes to the stacktrace filtering code in the VM. It turns out that we need to make a change anyway, but it is easier if we stick with the one name for the method to be filtered out. This isn't set in concrete though. David >> Date: Wed, 6 Apr 2011 23:29:02 -0700 >> From: joe.darcy at oracle.com >> To: core-libs-dev at openjdk.java.net >> Subject: Code review request for 6998871 "Support making the Throwable.stackTrace field immutable" >> >> Hello. >> >> Returning to some earlier work, I've developed a proposed fix for >> >> 6998871 "Support making the Throwable.stackTrace field immutable" >> http://cr.openjdk.java.net/~darcy/6998871.2/ >> >> One constructor of Throwable now takes an additional boolean argument to >> make the stack trace information immutable. Analogous constructors are >> added to Exception, RuntimeException, and Error. >> >> Mandy and David have already reviewed the change; I'm interested in >> getting additional feedback on the design of the API. >> >> Cheers, >> >> -Joe > From dalibor.topic at oracle.com Thu Apr 7 10:04:39 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Thu, 07 Apr 2011 12:04:39 +0200 Subject: How can I get all emails from this mailing list In-Reply-To: <4D6E060C.5070807@linux.vnet.ibm.com> References: <4D6E00A0.4020905@linux.vnet.ibm.com> <4D6E03DB.7040300@oracle.com> <4D6E060C.5070807@linux.vnet.ibm.com> Message-ID: <4D9D8C37.70309@oracle.com> On 3/2/11 9:55 AM, Charles Lee wrote: > Is there any place, which is like http://markmail.org/, holding all the mailing from openjdk mailing list? http://markmail.org/search/?q=list%3Anet.java.openjdk cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | | | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Rijnzathe 6, 3454PV De Meern, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Thu Apr 7 10:21:55 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Thu, 07 Apr 2011 12:21:55 +0200 Subject: Need reviewers: Update of jaxp 1.4.5 source drop bundle In-Reply-To: References: <984D321F-F4F4-4FC4-BE41-C89E75F66243@oracle.com> <4D6E9EFB.4000506@oracle.com> Message-ID: <4D9D9043.4040701@oracle.com> On 3/3/11 3:01 AM, Dr Andrew John Hughes wrote: > How do we know what the actual changes are between these tarballs? Is > there some JAXP repository somewhere these are derived from, with > appropriate tagging? Afaik, the JAXP API and implementation are supplied by the upstream JAXP developers in the GlassFish JAXP project, i.e. http://jaxp.java.net/ . The source code repository is at http://java.net/projects/jaxp-sources/sources/svn/show cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | | | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Rijnzathe 6, 3454PV De Meern, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From dmytro_sheyko at hotmail.com Thu Apr 7 11:27:03 2011 From: dmytro_sheyko at hotmail.com (Dmytro Sheyko) Date: Thu, 7 Apr 2011 18:27:03 +0700 Subject: Code review request for 6998871 "Support making the Throwable.stackTrace field immutable" In-Reply-To: <4D9D6FDE.1050208@oracle.com> References: <4D9D59AE.7040701@oracle.com> , <4D9D6FDE.1050208@oracle.com> Message-ID: Thanks. Got it. > Date: Thu, 7 Apr 2011 18:03:42 +1000 > From: David.Holmes at oracle.com > To: dmytro_sheyko at hotmail.com > CC: joe.darcy at oracle.com; core-libs-dev at openjdk.java.net > Subject: Re: Code review request for 6998871 "Support making the Throwable.stackTrace field immutable" > > Dmytro Sheyko said the following on 04/07/11 17:50: > > Just wonder what is the purpose of dummy parameter in native fillInStackTrace method. Couldn't we simply rename it (e.g. to fillInStackTrace0) > > Using an overload instead of renaming the native method was initially > done to avoid having to make changes to the stacktrace filtering code in > the VM. It turns out that we need to make a change anyway, but it is > easier if we stick with the one name for the method to be filtered out. > > This isn't set in concrete though. > > David From neil.richards at ngmr.net Thu Apr 7 13:30:23 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Thu, 07 Apr 2011 14:30:23 +0100 Subject: Suspected regression: fix for 6735255 causes delay in GC of ZipFile InputStreams, increase in heap demand In-Reply-To: <4D98FD10.4090608@oracle.com> References: <1300916786.4515.107.camel@chalkhill> <4D922D68.2080202@oracle.com> <1301514810.24605.64.camel@chalkhill> <4D93930A.2000604@oracle.com> <1301676177.24605.165.camel@chalkhill> <4D962275.7010601@oracle.com> <4D965D14.6060504@oracle.com> <1301707718.14323.43.camel@chalkhill> <4D98FD10.4090608@oracle.com> Message-ID: <1302183023.27698.20.camel@chalkhill> On Mon, 2011-04-04 at 09:04 +1000, David Holmes wrote: > 1. If a call to close() occurs around the same time as finalization > occurs then the finalizer thread will set inFinalizer to true, at which > point the thread executing close() can see it is true and so may skip > the releaseInflater(inf) call. > > 2. As isClosed is not volatile, and available() is not synchronized, a > thread calling available() on a closed stream may not see that it has > been closed and so will likely encounter an IOException rather than > getting a zero return. > > > Even if #1 is not a practical problem I'd be inclined to make the > finalizer synchronized as well. By doing that you're effectively > ensuring that premature finalization of the stream won't happen. I tend to agree, especially as it also makes the intention of the code clearer. > > For #2 it is a tricky call. If you don't actually expect the stream > object to be used by multiple threads then using a synchronized block to > read isClosed will be cheap in VMs that go to great effort to reduce the > cost of unnecessary synchronization (eg biased-locking in hotspot). > Otherwise making isClosed volatile is likely the better option. The check at the start of available() guards the logic beyond (which uses a value from the inflater object, which would not be valid if the stream has been closed()). Because of this, I think it would be clearer to synchronize the available() method too. As you say, it is extremely likely that, in practice, this synchronization will never be contended, and so won't impact performance significantly (in modern VMs). Please find below an updated changeset with these modifications, Thanks for your advice in this, Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU # HG changeset patch # User Neil Richards , # Date 1300289208 0 # Branch zip-heap # Node ID db52003c128c8706f45e0b2bf9f98d5e905d2090 # Parent 554adcfb615e63e62af530b1c10fcf7813a75b26 7031076: Retained ZipFile InputStreams increase heap demand Summary: Allow unreferenced ZipFile InputStreams to be finalized, GC'd Contributed-by: diff -r 554adcfb615e -r db52003c128c src/share/classes/java/util/zip/ZipFile.java --- a/src/share/classes/java/util/zip/ZipFile.java Wed Mar 16 15:01:07 2011 -0700 +++ b/src/share/classes/java/util/zip/ZipFile.java Wed Mar 16 15:26:48 2011 +0000 @@ -30,11 +30,14 @@ import java.io.IOException; import java.io.EOFException; import java.io.File; +import java.lang.ref.ReferenceQueue; +import java.lang.ref.WeakReference; import java.nio.charset.Charset; import java.util.Vector; import java.util.Enumeration; import java.util.Set; import java.util.HashSet; +import java.util.Iterator; import java.util.NoSuchElementException; import java.security.AccessController; import sun.security.action.GetPropertyAction; @@ -315,7 +318,16 @@ private static native void freeEntry(long jzfile, long jzentry); // the outstanding inputstreams that need to be closed. - private Set streams = new HashSet<>(); + private final Set> streams = new HashSet<>(); + private final ReferenceQueue staleStreamQueue = + new ReferenceQueue<>(); + + private void clearStaleStreams() { + Object staleStream; + while (null != (staleStream = staleStreamQueue.poll())) { + streams.remove(staleStream); + } + } /** * Returns an input stream for reading the contents of the specified @@ -339,6 +351,7 @@ ZipFileInputStream in = null; synchronized (this) { ensureOpen(); + clearStaleStreams(); if (!zc.isUTF8() && (entry.flag & EFS) != 0) { jzentry = getEntry(jzfile, zc.getBytesUTF8(entry.name), false); } else { @@ -351,51 +364,19 @@ switch (getEntryMethod(jzentry)) { case STORED: - streams.add(in); + streams.add( + new WeakReference(in, staleStreamQueue)); return in; case DEFLATED: - final ZipFileInputStream zfin = in; // MORE: Compute good size for inflater stream: long size = getEntrySize(jzentry) + 2; // Inflater likes a bit of slack if (size > 65536) size = 8192; if (size <= 0) size = 4096; - InputStream is = new InflaterInputStream(zfin, getInflater(), (int)size) { - private boolean isClosed = false; - - public void close() throws IOException { - if (!isClosed) { - super.close(); - releaseInflater(inf); - isClosed = true; - } - } - // Override fill() method to provide an extra "dummy" byte - // at the end of the input stream. This is required when - // using the "nowrap" Inflater option. - protected void fill() throws IOException { - if (eof) { - throw new EOFException( - "Unexpected end of ZLIB input stream"); - } - len = this.in.read(buf, 0, buf.length); - if (len == -1) { - buf[0] = 0; - len = 1; - eof = true; - } - inf.setInput(buf, 0, len); - } - private boolean eof; - - public int available() throws IOException { - if (isClosed) - return 0; - long avail = zfin.size() - inf.getBytesWritten(); - return avail > (long) Integer.MAX_VALUE ? - Integer.MAX_VALUE : (int) avail; - } - }; - streams.add(is); + InputStream is = + new ZipFileInflaterInputStream(in, getInflater(), + (int)size); + streams.add( + new WeakReference(is, staleStreamQueue)); return is; default: throw new ZipException("invalid compression method"); @@ -403,6 +384,56 @@ } } + private class ZipFileInflaterInputStream extends InflaterInputStream { + private boolean isClosed = false; + private boolean eof = false; + private final ZipFileInputStream zfin; + private boolean inFinalizer = false; + + ZipFileInflaterInputStream(ZipFileInputStream zfin, Inflater inf, + int size) { + super(zfin, inf, size); + this.zfin = zfin; + } + + public synchronized void close() throws IOException { + if (!isClosed) { + super.close(); + if (false == inFinalizer) + releaseInflater(inf); + isClosed = true; + } + } + // Override fill() method to provide an extra "dummy" byte + // at the end of the input stream. This is required when + // using the "nowrap" Inflater option. + protected void fill() throws IOException { + if (eof) { + throw new EOFException("Unexpected end of ZLIB input stream"); + } + len = in.read(buf, 0, buf.length); + if (len == -1) { + buf[0] = 0; + len = 1; + eof = true; + } + inf.setInput(buf, 0, len); + } + + public synchronized int available() throws IOException { + if (isClosed) + return 0; + long avail = zfin.size() - inf.getBytesWritten(); + return (avail > (long) Integer.MAX_VALUE ? + Integer.MAX_VALUE : (int) avail); + } + + protected synchronized void finalize() throws IOException { + inFinalizer = true; + close(); + } + } + /* * Gets an inflater from the list of available inflaters or allocates * a new one. @@ -543,11 +574,14 @@ synchronized (this) { closeRequested = true; - if (streams.size() !=0) { - Set copy = streams; - streams = new HashSet<>(); - for (InputStream is: copy) + Iterator> streamsIterator = + streams.iterator(); + while (streamsIterator.hasNext()) { + InputStream is = streamsIterator.next().get(); + if (null != is) { is.close(); + } + streamsIterator.remove(); } if (jzfile != 0) { @@ -684,9 +718,12 @@ freeEntry(ZipFile.this.jzfile, jzentry); jzentry = 0; } - streams.remove(this); } } + + protected void finalize() { + close(); + } } diff -r 554adcfb615e -r db52003c128c test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java Wed Mar 16 15:26:48 2011 +0000 @@ -0,0 +1,148 @@ +/* + * Copyright (c) 2011 Oracle and/or its affiliates. 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 Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/* + * Portions Copyright (c) 2011 IBM Corporation + */ + +/* + * @test + * @bug 7031076 + * @summary Allow stale InputStreams from ZipFiles to be GC'd + * @author Neil Richards , + */ +import java.lang.ref.ReferenceQueue; +import java.lang.ref.WeakReference; +import java.io.File; +import java.io.FileOutputStream; +import java.io.InputStream; +import java.util.Enumeration; +import java.util.HashSet; +import java.util.Random; +import java.util.Set; +import java.util.zip.ZipEntry; +import java.util.zip.ZipFile; +import java.util.zip.ZipOutputStream; + +public class ClearStaleZipFileInputStreams { + private static final int ZIP_ENTRY_NUM = 5; + + private static final byte[][] data; + + static { + data = new byte[ZIP_ENTRY_NUM][]; + Random r = new Random(); + for (int i = 0; i < ZIP_ENTRY_NUM; i++) { + data[i] = new byte[1000]; + r.nextBytes(data[i]); + } + } + + private static File createTestFile(int compression) throws Exception { + File tempZipFile = + File.createTempFile("test-data" + compression, ".zip"); + tempZipFile.deleteOnExit(); + + ZipOutputStream zos = + new ZipOutputStream(new FileOutputStream(tempZipFile)); + zos.setLevel(compression); + + try { + for (int i = 0; i < ZIP_ENTRY_NUM; i++) { + String text = "Entry" + i; + ZipEntry entry = new ZipEntry(text); + zos.putNextEntry(entry); + try { + zos.write(data[i], 0, data[i].length); + } finally { + zos.closeEntry(); + } + } + } finally { + zos.close(); + } + + return tempZipFile; + } + + private static void startGcInducingThread(final int sleepMillis) { + final Thread gcInducingThread = new Thread() { + public void run() { + while (true) { + System.gc(); + try { + Thread.sleep(sleepMillis); + } catch (InterruptedException e) { } + } + } + }; + + gcInducingThread.setDaemon(true); + gcInducingThread.start(); + } + + public static void main(String[] args) throws Exception { + startGcInducingThread(500); + runTest(ZipOutputStream.DEFLATED); + runTest(ZipOutputStream.STORED); + } + + private static void runTest(int compression) throws Exception { + ReferenceQueue rq = new ReferenceQueue<>(); + + System.out.println("Testing with a zip file with compression level = " + + compression); + File f = createTestFile(compression); + try { + ZipFile zf = new ZipFile(f); + try { + Set refSet = createTransientInputStreams(zf, rq); + + System.out.println("Waiting for 'stale' input streams from ZipFile to be GC'd ..."); + System.out.println("(The test will hang on failure)"); + while (false == refSet.isEmpty()) { + refSet.remove(rq.remove()); + } + System.out.println("Test PASSED."); + System.out.println(); + } finally { + zf.close(); + } + } finally { + f.delete(); + } + } + + private static Set createTransientInputStreams(ZipFile zf, + ReferenceQueue rq) throws Exception { + Enumeration zfe = zf.entries(); + Set refSet = new HashSet<>(); + + while (zfe.hasMoreElements()) { + InputStream is = zf.getInputStream(zfe.nextElement()); + refSet.add(new WeakReference(is, rq)); + } + + return refSet; + } +} From gnu_andrew at member.fsf.org Thu Apr 7 13:49:01 2011 From: gnu_andrew at member.fsf.org (Dr Andrew John Hughes) Date: Thu, 7 Apr 2011 14:49:01 +0100 Subject: Need reviewers: Update of jaxp 1.4.5 source drop bundle In-Reply-To: <4D9D9043.4040701@oracle.com> References: <984D321F-F4F4-4FC4-BE41-C89E75F66243@oracle.com> <4D6E9EFB.4000506@oracle.com> <4D9D9043.4040701@oracle.com> Message-ID: On 07/04/2011, Dalibor Topic wrote: > On 3/3/11 3:01 AM, Dr Andrew John Hughes wrote: >> How do we know what the actual changes are between these tarballs? Is >> there some JAXP repository somewhere these are derived from, with >> appropriate tagging? > > Afaik, the JAXP API and implementation are supplied by the upstream JAXP > developers > in the GlassFish JAXP project, i.e. http://jaxp.java.net/ . The source code > repository > is at http://java.net/projects/jaxp-sources/sources/svn/show > http://java.net/projects/jaxp-sources/sources/svn/show/tags shows no tags in the last six months. What does this tarball correspond to? > cheers, > dalibor topic > -- -- 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 lance.andersen at oracle.com Thu Apr 7 13:48:59 2011 From: lance.andersen at oracle.com (Lance Andersen - Oracle) Date: Thu, 7 Apr 2011 09:48:59 -0400 Subject: Review request for removal of lint warnings in DriverManager, CR 7034656 Message-ID: Hi all, This is a request for a review of the changes to remove the lint warnings for DriverManager. The diff is at http://cr.openjdk.java.net/~lancea/7034656/. Thank you. Regards, Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From dalibor.topic at oracle.com Thu Apr 7 14:04:14 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Thu, 07 Apr 2011 16:04:14 +0200 Subject: Need reviewers: Update of jaxp 1.4.5 source drop bundle In-Reply-To: References: <984D321F-F4F4-4FC4-BE41-C89E75F66243@oracle.com> <4D6E9EFB.4000506@oracle.com> <4D9D9043.4040701@oracle.com> Message-ID: <4D9DC45E.7000006@oracle.com> On 4/7/11 3:49 PM, Dr Andrew John Hughes wrote: > On 07/04/2011, Dalibor Topic wrote: >> On 3/3/11 3:01 AM, Dr Andrew John Hughes wrote: >>> How do we know what the actual changes are between these tarballs? Is >>> there some JAXP repository somewhere these are derived from, with >>> appropriate tagging? >> >> Afaik, the JAXP API and implementation are supplied by the upstream JAXP >> developers >> in the GlassFish JAXP project, i.e. http://jaxp.java.net/ . The source code >> repository >> is at http://java.net/projects/jaxp-sources/sources/svn/show >> > > http://java.net/projects/jaxp-sources/sources/svn/show/tags shows no > tags in the last six months. What does this tarball correspond to? Good point. CC:ing Joe. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | | | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Rijnzathe 6, 3454PV De Meern, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From Alan.Bateman at oracle.com Thu Apr 7 14:12:29 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 07 Apr 2011 15:12:29 +0100 Subject: Review request for removal of lint warnings in DriverManager, CR 7034656 In-Reply-To: References: Message-ID: <4D9DC64D.6080608@oracle.com> Lance Andersen - Oracle wrote: > Hi all, > > This is a request for a review of the changes to remove the lint warnings for DriverManager. The diff is at http://cr.openjdk.java.net/~lancea/7034656/. > > Looks okay to me. -Alan From forax at univ-mlv.fr Thu Apr 7 14:24:08 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 07 Apr 2011 16:24:08 +0200 Subject: Code review request for 6998871 "Support making the Throwable.stackTrace field immutable" In-Reply-To: <4D9D59AE.7040701@oracle.com> References: <4D9D59AE.7040701@oracle.com> Message-ID: <4D9DC908.9040507@univ-mlv.fr> On 04/07/2011 08:29 AM, Joe Darcy wrote: > Hello. > > Returning to some earlier work, I've developed a proposed fix for > > 6998871 "Support making the Throwable.stackTrace field immutable" > http://cr.openjdk.java.net/~darcy/6998871.2/ > > One constructor of Throwable now takes an additional boolean argument > to make the stack trace information immutable. Analogous constructors > are added to Exception, RuntimeException, and Error. > > Mandy and David have already reviewed the change; I'm interested in > getting additional feedback on the design of the API. > > Cheers, > > -Joe Joe, I don't think you need the sentinel in the serialized form, you have only two states: an immutable stacktrace (stacktrace == null) or a stacktrace. I think it's better to don't serialize the field "stacktrace" if the stacktrace is immutable. Also, FILLED_IN_STACK is not necessary, you can use EMPTY_STACKinstead, or if you find it hard to understand, at least FILLED_IN_STACK should be an empty array. R?mi From forax at univ-mlv.fr Thu Apr 7 14:26:21 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 07 Apr 2011 16:26:21 +0200 Subject: Review request for removal of lint warnings in DriverManager, CR 7034656 In-Reply-To: <4D9DC64D.6080608@oracle.com> References: <4D9DC64D.6080608@oracle.com> Message-ID: <4D9DC98D.8080301@univ-mlv.fr> On 04/07/2011 04:12 PM, Alan Bateman wrote: > Lance Andersen - Oracle wrote: >> Hi all, >> >> This is a request for a review of the changes to remove the lint >> warnings for DriverManager. The diff is at >> http://cr.openjdk.java.net/~lancea/7034656/. >> > Looks okay to me. > > -Alan So am I. R?mi From chris.hegarty at oracle.com Thu Apr 7 14:49:14 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 07 Apr 2011 14:49:14 +0000 Subject: hg: jdk7/tl/jdk: 7034657: Update Creative Commons license URL in legal notices Message-ID: <20110407144924.EDAC84788C@hg.openjdk.java.net> Changeset: 31619dfa6a4a Author: dl Date: 2011-04-07 15:06 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/31619dfa6a4a 7034657: Update Creative Commons license URL in legal notices Reviewed-by: chegar ! src/share/classes/java/util/AbstractQueue.java ! src/share/classes/java/util/ArrayDeque.java ! src/share/classes/java/util/Deque.java ! src/share/classes/java/util/NavigableMap.java ! src/share/classes/java/util/NavigableSet.java ! src/share/classes/java/util/Queue.java ! src/share/classes/java/util/concurrent/AbstractExecutorService.java ! src/share/classes/java/util/concurrent/ArrayBlockingQueue.java ! src/share/classes/java/util/concurrent/BlockingDeque.java ! src/share/classes/java/util/concurrent/BlockingQueue.java ! src/share/classes/java/util/concurrent/BrokenBarrierException.java ! src/share/classes/java/util/concurrent/Callable.java ! src/share/classes/java/util/concurrent/CancellationException.java ! src/share/classes/java/util/concurrent/CompletionService.java ! src/share/classes/java/util/concurrent/ConcurrentHashMap.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java ! src/share/classes/java/util/concurrent/ConcurrentMap.java ! src/share/classes/java/util/concurrent/ConcurrentNavigableMap.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListSet.java ! src/share/classes/java/util/concurrent/CopyOnWriteArraySet.java ! src/share/classes/java/util/concurrent/CountDownLatch.java ! src/share/classes/java/util/concurrent/CyclicBarrier.java ! src/share/classes/java/util/concurrent/DelayQueue.java ! src/share/classes/java/util/concurrent/Delayed.java ! src/share/classes/java/util/concurrent/Exchanger.java ! src/share/classes/java/util/concurrent/ExecutionException.java ! src/share/classes/java/util/concurrent/Executor.java ! src/share/classes/java/util/concurrent/ExecutorCompletionService.java ! src/share/classes/java/util/concurrent/ExecutorService.java ! src/share/classes/java/util/concurrent/Executors.java ! src/share/classes/java/util/concurrent/ForkJoinPool.java ! src/share/classes/java/util/concurrent/ForkJoinTask.java ! src/share/classes/java/util/concurrent/ForkJoinWorkerThread.java ! src/share/classes/java/util/concurrent/Future.java ! src/share/classes/java/util/concurrent/FutureTask.java ! src/share/classes/java/util/concurrent/LinkedBlockingDeque.java ! src/share/classes/java/util/concurrent/LinkedBlockingQueue.java ! src/share/classes/java/util/concurrent/LinkedTransferQueue.java ! src/share/classes/java/util/concurrent/Phaser.java ! src/share/classes/java/util/concurrent/PriorityBlockingQueue.java ! src/share/classes/java/util/concurrent/RecursiveAction.java ! src/share/classes/java/util/concurrent/RecursiveTask.java ! src/share/classes/java/util/concurrent/RejectedExecutionException.java ! src/share/classes/java/util/concurrent/RejectedExecutionHandler.java ! src/share/classes/java/util/concurrent/RunnableFuture.java ! src/share/classes/java/util/concurrent/RunnableScheduledFuture.java ! src/share/classes/java/util/concurrent/ScheduledExecutorService.java ! src/share/classes/java/util/concurrent/ScheduledFuture.java ! src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java ! src/share/classes/java/util/concurrent/Semaphore.java ! src/share/classes/java/util/concurrent/SynchronousQueue.java ! src/share/classes/java/util/concurrent/ThreadFactory.java ! src/share/classes/java/util/concurrent/ThreadLocalRandom.java ! src/share/classes/java/util/concurrent/ThreadPoolExecutor.java ! src/share/classes/java/util/concurrent/TimeUnit.java ! src/share/classes/java/util/concurrent/TimeoutException.java ! src/share/classes/java/util/concurrent/TransferQueue.java ! src/share/classes/java/util/concurrent/atomic/AtomicBoolean.java ! src/share/classes/java/util/concurrent/atomic/AtomicInteger.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicLong.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicMarkableReference.java ! src/share/classes/java/util/concurrent/atomic/AtomicReference.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicStampedReference.java ! src/share/classes/java/util/concurrent/atomic/package-info.java ! src/share/classes/java/util/concurrent/locks/AbstractOwnableSynchronizer.java ! src/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java ! src/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java ! src/share/classes/java/util/concurrent/locks/Condition.java ! src/share/classes/java/util/concurrent/locks/Lock.java ! src/share/classes/java/util/concurrent/locks/LockSupport.java ! src/share/classes/java/util/concurrent/locks/ReadWriteLock.java ! src/share/classes/java/util/concurrent/locks/ReentrantLock.java ! src/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java ! src/share/classes/java/util/concurrent/locks/package-info.java ! src/share/classes/java/util/concurrent/package-info.java ! test/java/util/PriorityQueue/NoNulls.java ! test/java/util/PriorityQueue/PriorityQueueSort.java ! test/java/util/Random/DistinctSeeds.java ! test/java/util/concurrent/BlockingQueue/CancelledProducerConsumerLoops.java ! test/java/util/concurrent/BlockingQueue/LoopHelpers.java ! test/java/util/concurrent/BlockingQueue/MultipleProducersSingleConsumerLoops.java ! test/java/util/concurrent/BlockingQueue/OfferDrainToLoops.java ! test/java/util/concurrent/BlockingQueue/PollMemoryLeak.java ! test/java/util/concurrent/BlockingQueue/ProducerConsumerLoops.java ! test/java/util/concurrent/BlockingQueue/SingleProducerMultipleConsumerLoops.java ! test/java/util/concurrent/ConcurrentHashMap/LoopHelpers.java ! test/java/util/concurrent/ConcurrentHashMap/MapCheck.java ! test/java/util/concurrent/ConcurrentHashMap/MapLoops.java ! test/java/util/concurrent/ConcurrentQueues/ConcurrentQueueLoops.java ! test/java/util/concurrent/ConcurrentQueues/GCRetention.java ! test/java/util/concurrent/ConcurrentQueues/IteratorWeakConsistency.java ! test/java/util/concurrent/ConcurrentQueues/LoopHelpers.java ! test/java/util/concurrent/ConcurrentQueues/RemovePollRace.java ! test/java/util/concurrent/Exchanger/ExchangeLoops.java ! test/java/util/concurrent/Exchanger/LoopHelpers.java ! test/java/util/concurrent/ExecutorCompletionService/ExecutorCompletionServiceLoops.java ! test/java/util/concurrent/ExecutorCompletionService/LoopHelpers.java ! test/java/util/concurrent/FutureTask/CancelledFutureLoops.java ! test/java/util/concurrent/FutureTask/LoopHelpers.java ! test/java/util/concurrent/Phaser/Arrive.java ! test/java/util/concurrent/Phaser/Basic.java ! test/java/util/concurrent/Phaser/FickleRegister.java ! test/java/util/concurrent/Phaser/PhaseOverflow.java ! test/java/util/concurrent/Phaser/TieredArriveLoops.java ! test/java/util/concurrent/ScheduledThreadPoolExecutor/DelayOverflow.java ! test/java/util/concurrent/Semaphore/PermitOverflow.java ! test/java/util/concurrent/Semaphore/RacingReleases.java ! test/java/util/concurrent/forkjoin/Integrate.java ! test/java/util/concurrent/forkjoin/NQueensCS.java ! test/java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java ! test/java/util/concurrent/locks/ReentrantLock/LockOncePerThreadLoops.java ! test/java/util/concurrent/locks/ReentrantLock/LoopHelpers.java ! test/java/util/concurrent/locks/ReentrantLock/SimpleReentrantLockLoops.java ! test/java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java ! test/java/util/concurrent/locks/ReentrantReadWriteLock/LoopHelpers.java ! test/java/util/concurrent/locks/ReentrantReadWriteLock/MapLoops.java ! test/java/util/concurrent/locks/ReentrantReadWriteLock/RWMap.java From kelly.ohair at oracle.com Thu Apr 7 15:02:50 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 7 Apr 2011 08:02:50 -0700 Subject: Review request for removal of lint warnings in DriverManager, CR 7034656 In-Reply-To: References: Message-ID: <7827DFD4-3C91-4379-9B42-AE58B2511105@oracle.com> And the big man in the sky opens his book of good deeds, looks up Lance, and adds "4/7/2011 - Lance fixed warning errors". ;^) Thanks! -kto On Apr 7, 2011, at 6:48 AM, Lance Andersen - Oracle wrote: > Hi all, > > This is a request for a review of the changes to remove the lint warnings for DriverManager. The diff is at http://cr.openjdk.java.net/~lancea/7034656/. > > Thank you. > > Regards, > > Lance > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > From lance.andersen at oracle.com Thu Apr 7 15:25:53 2011 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Thu, 07 Apr 2011 15:25:53 +0000 Subject: hg: jdk7/tl/jdk: 7034656: Address lint warnings for DriverManager Message-ID: <20110407152602.CD1CF4788F@hg.openjdk.java.net> Changeset: 5137806a3e34 Author: lancea Date: 2011-04-07 11:25 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5137806a3e34 7034656: Address lint warnings for DriverManager Reviewed-by: alanb, forax, ohair ! src/share/classes/java/sql/DriverManager.java From kumar.x.srinivasan at oracle.COM Thu Apr 7 19:05:10 2011 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Thu, 07 Apr 2011 12:05:10 -0700 Subject: Need reviewer: 7034700: simple fix Message-ID: <4D9E0AE6.1@oracle.COM> Hi, This fixes a build issue in non-product builds, with the fix for 7033954. During the pack200 build the wrong mapfile is picked up due to the idiosyncrasy of the makefile. Thus the fix is simply and explicitly instructing Mapfile-vers.gmk not to use a mapfile for a non-product build. http://cr.openjdk.java.net/~ksrini/7034700/webrev.0/ Thanks Kumar PS: the previous change which activates mapfile checking, for reference : http://cr.openjdk.java.net/~ksrini/7033954/webrev.0/make/com/sun/java/pack/Makefile.udiff.html From kumar.x.srinivasan at oracle.com Thu Apr 7 19:15:01 2011 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Thu, 07 Apr 2011 19:15:01 +0000 Subject: hg: jdk7/tl/jdk: 7029048: (launcher) fence the launcher against LD_LIBRARY_PATH Message-ID: <20110407191519.517F447898@hg.openjdk.java.net> Changeset: d8dfd1a0bd8d Author: ksrini Date: 2011-04-07 12:06 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d8dfd1a0bd8d 7029048: (launcher) fence the launcher against LD_LIBRARY_PATH Reviewed-by: mchung, ohair ! src/share/bin/jli_util.h ! src/solaris/bin/java_md.c ! test/tools/launcher/ExecutionEnvironment.java + test/tools/launcher/Test7029048.java ! test/tools/launcher/TestHelper.java From kelly.ohair at oracle.com Thu Apr 7 19:17:19 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 7 Apr 2011 12:17:19 -0700 Subject: Need reviewer: 7034700: simple fix In-Reply-To: <4D9E0AE6.1@oracle.COM> References: <4D9E0AE6.1@oracle.COM> Message-ID: <05705EF8-5851-4DC5-AE70-776C2411EF8D@oracle.com> Looks fine to me. -kto On Apr 7, 2011, at 12:05 PM, Kumar Srinivasan wrote: > Hi, > > This fixes a build issue in non-product builds, with the fix for 7033954. > During the pack200 build the wrong mapfile is picked up due to the > idiosyncrasy of the makefile. Thus the fix is simply and explicitly instructing > Mapfile-vers.gmk not to use a mapfile for a non-product build. > > http://cr.openjdk.java.net/~ksrini/7034700/webrev.0/ > > Thanks > Kumar > > PS: > the previous change which activates mapfile checking, for reference : > http://cr.openjdk.java.net/~ksrini/7033954/webrev.0/make/com/sun/java/pack/Makefile.udiff.html From David.Holmes at oracle.com Thu Apr 7 22:13:23 2011 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 08 Apr 2011 08:13:23 +1000 Subject: Suspected regression: fix for 6735255 causes delay in GC of ZipFile InputStreams, increase in heap demand In-Reply-To: <1302183023.27698.20.camel@chalkhill> References: <1300916786.4515.107.camel@chalkhill> <4D922D68.2080202@oracle.com> <1301514810.24605.64.camel@chalkhill> <4D93930A.2000604@oracle.com> <1301676177.24605.165.camel@chalkhill> <4D962275.7010601@oracle.com> <4D965D14.6060504@oracle.com> <1301707718.14323.43.camel@chalkhill> <4D98FD10.4090608@oracle.com> <1302183023.27698.20.camel@chalkhill> Message-ID: <4D9E3703.6070509@oracle.com> Hi Neil, Neil Richards said the following on 04/07/11 23:30: > On Mon, 2011-04-04 at 09:04 +1000, David Holmes wrote: >> 1. If a call to close() occurs around the same time as finalization >> occurs then the finalizer thread will set inFinalizer to true, at which >> point the thread executing close() can see it is true and so may skip >> the releaseInflater(inf) call. >> >> 2. As isClosed is not volatile, and available() is not synchronized, a >> thread calling available() on a closed stream may not see that it has >> been closed and so will likely encounter an IOException rather than >> getting a zero return. >> >> >> Even if #1 is not a practical problem I'd be inclined to make the >> finalizer synchronized as well. By doing that you're effectively >> ensuring that premature finalization of the stream won't happen. > > I tend to agree, especially as it also makes the intention of the code > clearer. > >> For #2 it is a tricky call. If you don't actually expect the stream >> object to be used by multiple threads then using a synchronized block to >> read isClosed will be cheap in VMs that go to great effort to reduce the >> cost of unnecessary synchronization (eg biased-locking in hotspot). >> Otherwise making isClosed volatile is likely the better option. > > The check at the start of available() guards the logic beyond (which > uses a value from the inflater object, which would not be valid if the > stream has been closed()). > > Because of this, I think it would be clearer to synchronize the > available() method too. > > As you say, it is extremely likely that, in practice, this > synchronization will never be contended, and so won't impact performance > significantly (in modern VMs). > > Please find below an updated changeset with these modifications, > > Thanks for your advice in this, No problem. From a synchronization perspective this all seems fine now. Cheers, David From stuart.marks at oracle.com Thu Apr 7 22:19:19 2011 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 07 Apr 2011 15:19:19 -0700 Subject: advice & review requested for 6896297, race condition in rmid causing JCK failure Message-ID: <4D9E3867.7030004@oracle.com> Hi Core-Libs developers, I'd like to solicit some advice and discussion about this bug and a potential fix I'm cooking for it. Here is the bug report; it contains details about the problem and my analysis of it: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6896297 and here's a webrev of the fix I'm working on: http://cr.openjdk.java.net/~smarks/reviews/6896297/webrev.0/ Briefly, the problem is incorrect synchronization of groupTable, a HashMap field of an Activation object. The code mostly locks groupTable around any access to it. However, no such locking is done during serialization. If the groupTable is modified while it's being serialized, ConcurrentModificationException occurs. The obvious fix would be to use ConcurrentHashMap instead of Hashmap and to remove the external locking entirely. Unfortunately this will change the serialized representation of the Activation object, which I'm not sure is acceptable. Assuming that we can't change the serialized represenation, the alternative approach would be to make sure that locking is done properly during serialization. This is fairly easy to do by locking groupTable in a writeObject() method. Unfortunately, this introduces a deadlock. This deadlock occurs because, with this modification, there are now paths through the code that take locks in the opposite order. Specifically, the addLogRecord() method locks the log object and then (via serialization and the newly added writeObject() method) locks groupTable. However, the unregisterGroup() method locks groupTable and calls GroupEntry.unregisterGroup() which logs the event, which takes a lock on the log. After some analysis, I've determined that the call to GroupEntry.unregisterGroup() can be moved outside the synchronization of groupTable. This removes the ordering problem. With these fixes in place (the state of the webrev above) I can get several hundred successful test runs with neither ConcurrentModificationException nor any deadlocks. Of course, that doesn't mean the change is correct. :-) Questions: 1. Is there a requirement that the serialized form of Activation remain unchanged? If we can change it, we might as well just use ConcurrentHashMap instead of HashMap. 2. Is my lock ordering analysis correct? I've pored over the code, but not really being familiar with any RMI concepts, I'm not sure I have it right. I've written this analysis into a big comment I've added to the code. 3. There is also a potential concurrency issue with idTable, which is used similarly to groupTable. I haven't seen a test failure from it though. It seems sensible to add a lock for it in Activation.writeObject() though. I don't particularly like nesting the locks of idTable and groupTable, but locking them separately would require serializing the Activation object field by field instead of simply using defaultWriteObject(). Is this a reasonable approach? Thanks for any advice or comments. s'marks From xueming.shen at oracle.com Thu Apr 7 23:02:55 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 07 Apr 2011 16:02:55 -0700 Subject: Suspected regression: fix for 6735255 causes delay in GC of ZipFile InputStreams, increase in heap demand In-Reply-To: <1302183023.27698.20.camel@chalkhill> References: <1300916786.4515.107.camel@chalkhill> <4D922D68.2080202@oracle.com> <1301514810.24605.64.camel@chalkhill> <4D93930A.2000604@oracle.com> <1301676177.24605.165.camel@chalkhill> <4D962275.7010601@oracle.com> <4D965D14.6060504@oracle.com> <1301707718.14323.43.camel@chalkhill> <4D98FD10.4090608@oracle.com> <1302183023.27698.20.camel@chalkhill> Message-ID: <4D9E429F.9030200@oracle.com> Neil, It appears it might not be necessary to do the finalize() in ZipFileInflaterInputStream. The ZipFileInflaterInputStream itself does not directly hold any native resource by itself that needs to be released at the end of its life circle, if not closed explicitly. The native resource/ memory that need to be taken care of are held by its fields "inf" and "zfin", which should be finalized by the corresponding finalize() of their own classes (again, if not closed explicitly), when their outer ZFIIS object is unreachable. The Inflater class has its own finalize() implemented already to invoke its cleanup method end(), so the only thing need to be addressed is to add the finalize() into ZipFileInputStream class to call its close(), strictly speaking this issue is not the regression caused by #6735255, we have this "leak" before #6735255. Also, would you like to consider to use WeakHeapMap instead of handling all the weak reference impl by yourself, the bonus would be that the stalled entries might be cleaned up more frequently. Sherman On 04/07/2011 06:30 AM, Neil Richards wrote: > On Mon, 2011-04-04 at 09:04 +1000, David Holmes wrote: >> 1. If a call to close() occurs around the same time as finalization >> occurs then the finalizer thread will set inFinalizer to true, at which >> point the thread executing close() can see it is true and so may skip >> the releaseInflater(inf) call. >> >> 2. As isClosed is not volatile, and available() is not synchronized, a >> thread calling available() on a closed stream may not see that it has >> been closed and so will likely encounter an IOException rather than >> getting a zero return. >> >> >> Even if #1 is not a practical problem I'd be inclined to make the >> finalizer synchronized as well. By doing that you're effectively >> ensuring that premature finalization of the stream won't happen. > I tend to agree, especially as it also makes the intention of the code > clearer. > >> For #2 it is a tricky call. If you don't actually expect the stream >> object to be used by multiple threads then using a synchronized block to >> read isClosed will be cheap in VMs that go to great effort to reduce the >> cost of unnecessary synchronization (eg biased-locking in hotspot). >> Otherwise making isClosed volatile is likely the better option. > The check at the start of available() guards the logic beyond (which > uses a value from the inflater object, which would not be valid if the > stream has been closed()). > > Because of this, I think it would be clearer to synchronize the > available() method too. > > As you say, it is extremely likely that, in practice, this > synchronization will never be contended, and so won't impact performance > significantly (in modern VMs). > > Please find below an updated changeset with these modifications, > > Thanks for your advice in this, > Neil > From David.Holmes at oracle.com Thu Apr 7 23:19:57 2011 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 08 Apr 2011 09:19:57 +1000 Subject: advice & review requested for 6896297, race condition in rmid causing JCK failure In-Reply-To: <4D9E3867.7030004@oracle.com> References: <4D9E3867.7030004@oracle.com> Message-ID: <4D9E469D.5050803@oracle.com> Hi Stuart, I can't answer your specific questions as I'm not familiar with the RMI infrastructure either. Taking the lock in writeObject and moving group.unregister out of the sync block to avoid deadlock seems reasonable. The main question to ask with such a move is whether the temporary inconsistency in state is something that can be observed and cause a problem. The lock ordering analysis seems reasonable. I do note that the startupLock protocol seems suspicious as there is a race with detection of the lock value. I assume init itself can never be invoked by more than one thread ;-) It may be that the object can only become accessible concurrently at some time during init (ie it gets published) in which case the protocol will work fine - but you really need a full understanding of the lifecycle of the objects to determine that. That aside, using ConcurrentHashMap would simplify the solution to the current problem. If you are concerned about the serialized form then you could define writeObject and readObject such that they convert between CHM and plain HM using the serialized-fields API. Cheers, David Stuart Marks said the following on 04/08/11 08:19: > Hi Core-Libs developers, > > I'd like to solicit some advice and discussion about this bug and a > potential fix I'm cooking for it. Here is the bug report; it contains > details about the problem and my analysis of it: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6896297 > > and here's a webrev of the fix I'm working on: > > http://cr.openjdk.java.net/~smarks/reviews/6896297/webrev.0/ > > Briefly, the problem is incorrect synchronization of groupTable, a > HashMap field of an Activation object. The code mostly locks groupTable > around any access to it. However, no such locking is done during > serialization. If the groupTable is modified while it's being > serialized, ConcurrentModificationException occurs. > > The obvious fix would be to use ConcurrentHashMap instead of Hashmap and > to remove the external locking entirely. Unfortunately this will change > the serialized representation of the Activation object, which I'm not > sure is acceptable. > > Assuming that we can't change the serialized represenation, the > alternative approach would be to make sure that locking is done properly > during serialization. This is fairly easy to do by locking groupTable in > a writeObject() method. Unfortunately, this introduces a deadlock. > > This deadlock occurs because, with this modification, there are now > paths through the code that take locks in the opposite order. > Specifically, the addLogRecord() method locks the log object and then > (via serialization and the newly added writeObject() method) locks > groupTable. However, the unregisterGroup() method locks groupTable and > calls GroupEntry.unregisterGroup() which logs the event, which takes a > lock on the log. > > After some analysis, I've determined that the call to > GroupEntry.unregisterGroup() can be moved outside the synchronization of > groupTable. This removes the ordering problem. > > With these fixes in place (the state of the webrev above) I can get > several hundred successful test runs with neither > ConcurrentModificationException nor any deadlocks. > > Of course, that doesn't mean the change is correct. :-) > > Questions: > > 1. Is there a requirement that the serialized form of Activation remain > unchanged? If we can change it, we might as well just use > ConcurrentHashMap instead of HashMap. > > 2. Is my lock ordering analysis correct? I've pored over the code, but > not really being familiar with any RMI concepts, I'm not sure I have it > right. I've written this analysis into a big comment I've added to the > code. > > 3. There is also a potential concurrency issue with idTable, which is > used similarly to groupTable. I haven't seen a test failure from it > though. It seems sensible to add a lock for it in > Activation.writeObject() though. I don't particularly like nesting the > locks of idTable and groupTable, but locking them separately would > require serializing the Activation object field by field instead of > simply using defaultWriteObject(). Is this a reasonable approach? > > Thanks for any advice or comments. > > s'marks > From joe.darcy at oracle.com Thu Apr 7 23:26:29 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 07 Apr 2011 16:26:29 -0700 Subject: Code review request for 6998871 "Support making the Throwable.stackTrace field immutable" In-Reply-To: <4D9DC908.9040507@univ-mlv.fr> References: <4D9D59AE.7040701@oracle.com> <4D9DC908.9040507@univ-mlv.fr> Message-ID: <4D9E4825.5010504@oracle.com> Hi R?mi. R?mi Forax wrote: > On 04/07/2011 08:29 AM, Joe Darcy wrote: >> Hello. >> >> Returning to some earlier work, I've developed a proposed fix for >> >> 6998871 "Support making the Throwable.stackTrace field immutable" >> http://cr.openjdk.java.net/~darcy/6998871.2/ >> >> One constructor of Throwable now takes an additional boolean argument >> to make the stack trace information immutable. Analogous >> constructors are added to Exception, RuntimeException, and Error. >> >> Mandy and David have already reviewed the change; I'm interested in >> getting additional feedback on the design of the API. >> >> Cheers, >> >> -Joe > > Joe, > I don't think you need the sentinel in the serialized form, > you have only two states: an immutable stacktrace (stacktrace == null) or > a stacktrace. I think it's better to don't serialize the field > "stacktrace" if > the stacktrace is immutable. > > Also, FILLED_IN_STACK is not necessary, you can use EMPTY_STACKinstead, > or if you find it hard to understand, at least FILLED_IN_STACK should > be an empty array. > > R?mi > Here is an explanation and rationale of the protocol in more detail. As far as serialization goes, there are three cases of interest where "new" means JDK 7 and "old" means any release prior to JDK 7 1) Object serialized on *new* platform has same semantics after being deserialized on *new* platform. 2) Object serialized on *old* platform has same semantics after being deserialized on *new* platform. 3) Object serialized on *new* platform has reasonable semantics after being deserialized on *old* platform. (And of course when both source and destination platforms are old, JDK 7 isn't involved.) For point 1), a logically equivalent object should result, which in this case means the cause, stack trace, stack trace, message, etc. should be the same on the old and new objects. For 2), if an exception object serialized prior to the stack trace facility being added was deserialized in JDK 7, that is logically equivalent to there being not stack trace information, so an empty stack is a better result than an immutable stack. I've updated the readObject method accordingly. For 3), since null was not a valid value for stackTrace in the past, some other sentinel object should be written in out in the serial form to denote such a value, which is the role played by STACK_TRACE_SENTINEL as used in the writeObject method. A marker value other than EMPTY_STACK is needed for the following reason since the stack trace information is spread amongst two fields, backtrace and stackTrace. The transient backtrace field pre-dates the programmatic stack facility being added; that facility uses the stackTrace field. If fillInStackTrace is called *after* a call to setStackTrace, the real stack information is held in the backtrace field as written by fillInStackTrace. The FILLED_IN_STACK value alerts the getourstacktrace method to this situation. Revised webrev: http://cr.openjdk.java.net/~darcy/6998871.3/ Thanks, -Joe From mandy.chung at oracle.com Thu Apr 7 23:50:58 2011 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 07 Apr 2011 16:50:58 -0700 Subject: Code review request for 6998871 "Support making the Throwable.stackTrace field immutable" In-Reply-To: <4D9E4825.5010504@oracle.com> References: <4D9D59AE.7040701@oracle.com> <4D9DC908.9040507@univ-mlv.fr> <4D9E4825.5010504@oracle.com> Message-ID: <4D9E4DE2.8080109@oracle.com> On 04/07/11 16:26, Joe Darcy wrote: > > Revised webrev: > > http://cr.openjdk.java.net/~darcy/6998871.3/ Looks good. Mandy From yuka.kamiya at oracle.com Fri Apr 8 00:32:48 2011 From: yuka.kamiya at oracle.com (Yuka Kamiya) Date: Fri, 08 Apr 2011 09:32:48 +0900 Subject: Codereview request for 7033561: Missing Unicode Script aliases In-Reply-To: <4D9CCA26.8050502@oracle.com> References: <4D9CCA26.8050502@oracle.com> Message-ID: <4D9E57B0.6050908@oracle.com> Hi Sherman, The fix looks good to me. Thanks, -- Yuka (11/04/07 5:16), Xueming Shen wrote: > > It appears the aliases mapping for Character.UnicodeScript is not updated accordingly when > we upgraded the Unicode support to 6.0 for JDK7. The difference between the previous version > (5.2) and 6.0 of the aliases are these 3 missing names reported in #7033561. > > The webrev with the change is at > > http://cr.openjdk.java.net/~sherman/7033561/webrev > > Thanks, > Sherman > > From kumar.x.srinivasan at oracle.com Fri Apr 8 01:37:45 2011 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Fri, 08 Apr 2011 01:37:45 +0000 Subject: hg: jdk7/tl/jdk: 7034700: (unpack200) build fails with fastdebug builds Message-ID: <20110408013755.A89BA478B8@hg.openjdk.java.net> Changeset: 587e968b03ee Author: ksrini Date: 2011-04-07 17:08 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/587e968b03ee 7034700: (unpack200) build fails with fastdebug builds Reviewed-by: ohair ! make/com/sun/java/pack/Makefile From joe.darcy at oracle.com Fri Apr 8 02:26:26 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 07 Apr 2011 19:26:26 -0700 Subject: Code review request for 6998871 "Support making the Throwable.stackTrace field immutable" In-Reply-To: <4D9E4825.5010504@oracle.com> References: <4D9D59AE.7040701@oracle.com> <4D9DC908.9040507@univ-mlv.fr> <4D9E4825.5010504@oracle.com> Message-ID: <4D9E7252.9050003@oracle.com> Joe Darcy wrote: > Hi R?mi. > > R?mi Forax wrote: >> On 04/07/2011 08:29 AM, Joe Darcy wrote: >>> Hello. >>> >>> Returning to some earlier work, I've developed a proposed fix for >>> >>> 6998871 "Support making the Throwable.stackTrace field immutable" >>> http://cr.openjdk.java.net/~darcy/6998871.2/ >>> >>> One constructor of Throwable now takes an additional boolean >>> argument to make the stack trace information immutable. Analogous >>> constructors are added to Exception, RuntimeException, and Error. >>> >>> Mandy and David have already reviewed the change; I'm interested in >>> getting additional feedback on the design of the API. >>> >>> Cheers, >>> >>> -Joe >> >> Joe, >> I don't think you need the sentinel in the serialized form, >> you have only two states: an immutable stacktrace (stacktrace == >> null) or >> a stacktrace. I think it's better to don't serialize the field >> "stacktrace" if >> the stacktrace is immutable. >> >> Also, FILLED_IN_STACK is not necessary, you can use EMPTY_STACKinstead, >> or if you find it hard to understand, at least FILLED_IN_STACK should >> be an empty array. >> >> R?mi >> > > Here is an explanation and rationale of the protocol in more detail. > As far as serialization goes, there are three cases of interest where > "new" means JDK 7 and "old" means any release prior to JDK 7 > > 1) Object serialized on *new* platform has same semantics after being > deserialized on *new* platform. > > 2) Object serialized on *old* platform has same semantics after being > deserialized on *new* platform. > > 3) Object serialized on *new* platform has reasonable semantics after > being deserialized on *old* platform. > > (And of course when both source and destination platforms are old, JDK > 7 isn't involved.) > > For point 1), a logically equivalent object should result, which in > this case means the cause, stack trace, stack trace, message, etc. > should be the same on the old and new objects. > > For 2), if an exception object serialized prior to the stack trace > facility being added was deserialized in JDK 7, that is logically > equivalent to there being not stack trace information, so an empty > stack is a better result than an immutable stack. I've updated the > readObject method accordingly. > > For 3), since null was not a valid value for stackTrace in the past, > some other sentinel object should be written in out in the serial form > to denote such a value, which is the role played by > STACK_TRACE_SENTINEL as used in the writeObject method. > > A marker value other than EMPTY_STACK is needed for the following > reason since the stack trace information is spread amongst two fields, > backtrace and stackTrace. The transient backtrace field pre-dates the > programmatic stack facility being added; that facility uses the > stackTrace field. If fillInStackTrace is called *after* a call to > setStackTrace, the real stack information is held in the backtrace > field as written by fillInStackTrace. The FILLED_IN_STACK value > alerts the getourstacktrace method to this situation. > > Revised webrev: > > http://cr.openjdk.java.net/~darcy/6998871.3/ > > Thanks, > > -Joe PS A little more detail here, exception objects can be created via deserialization as well as by a constructor. As currently written, the writeObject method uses EMPTY_STACK for both a zero-length incoming stack and a null stackTrace pointer (which can result from an throwable object serialized from a JDK release before the stack trace facility was added). The native fillInStackTrace method writes a null into the stackTrace field to indicate it is no longer valid; this goes against the new protocol and the Java-level of fillInStackTraces needs to write a non-null "dirty" value into the field to signal to getOurStackTrace that the stack trace array needs to be recomputed if requested. Therefore, if fillInStackTrace were called on one of these deserialized objects to logically replace its stack trace, using EMPTY_STACK would not allow the getOutStackTrace code to know that the stack trace had logically been replaced by a new value in backtrace since EMPY_STACK could result from serialization. The serialization code could use EMPTY_STACK.clone() instead of EMPTY_STACK, which would break the object equality being tested in getOurStackTrace. I'll consider making this change in the Throwable.readObject method. Cheers, -Joe From xuelei.fan at oracle.com Fri Apr 8 09:01:54 2011 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Fri, 08 Apr 2011 09:01:54 +0000 Subject: hg: jdk7/tl/jdk: 6976117: SSLContext.getInstance("TLSv1.1") returns SSLEngines/SSLSockets without TLSv1.1 enabled Message-ID: <20110408090203.BAB61478DA@hg.openjdk.java.net> Changeset: 9c29dd06e138 Author: xuelei Date: 2011-04-08 02:00 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9c29dd06e138 6976117: SSLContext.getInstance("TLSv1.1") returns SSLEngines/SSLSockets without TLSv1.1 enabled Summary: Reorg the SSLContext implementation Reviewed-by: weijun ! src/share/classes/sun/security/ssl/CipherSuiteList.java - src/share/classes/sun/security/ssl/DefaultSSLContextImpl.java ! src/share/classes/sun/security/ssl/JsseJce.java ! src/share/classes/sun/security/ssl/ProtocolList.java ! src/share/classes/sun/security/ssl/SSLContextImpl.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLServerSocketFactoryImpl.java ! src/share/classes/sun/security/ssl/SSLServerSocketImpl.java ! src/share/classes/sun/security/ssl/SSLSocketFactoryImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! src/share/classes/sun/security/ssl/SunJSSE.java + test/sun/security/ssl/javax/net/ssl/SSLContextVersion.java From neil.richards at ngmr.net Fri Apr 8 12:36:33 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Fri, 08 Apr 2011 13:36:33 +0100 Subject: Suspected regression: fix for 6735255 causes delay in GC of ZipFile InputStreams, increase in heap demand In-Reply-To: <4D9E429F.9030200@oracle.com> References: <1300916786.4515.107.camel@chalkhill> <4D922D68.2080202@oracle.com> <1301514810.24605.64.camel@chalkhill> <4D93930A.2000604@oracle.com> <1301676177.24605.165.camel@chalkhill> <4D962275.7010601@oracle.com> <4D965D14.6060504@oracle.com> <1301707718.14323.43.camel@chalkhill> <4D98FD10.4090608@oracle.com> <1302183023.27698.20.camel@chalkhill> <4D9E429F.9030200@oracle.com> Message-ID: <1302266193.17745.18.camel@chalkhill> On Thu, 2011-04-07 at 16:02 -0700, Xueming Shen wrote: > It appears it might not be necessary to do the finalize() in > ZipFileInflaterInputStream. The ZipFileInflaterInputStream itself does > not directly hold any native resource by itself that needs to be > released at the end of its life circle, if not closed explicitly. The > native resource/memory that need to be taken care of are held by its > fields "inf" and "zfin", which should be finalized by the > corresponding finalize() of their own classes (again, if not closed > explicitly), when their outer ZFIIS object is unreachable. The Inflater > class has its own finalize() implemented already to invoke its cleanup > method end(), so the only thing need to be addressed is to add the > finalize() into ZipFileInputStream class to call its close(), strictly > speaking this issue is not the regression caused by #6735255, we have > this "leak" before #6735255. > > Also, would you like to consider to use WeakHeapMap > instead of handling all the weak reference impl by yourself, the bonus > would be that the stalled entries might be cleaned up more frequently. > Hi Sherman, Thanks for your continuing analysis of this change. I concur with your assessment above, and agree that making the suggested modifications to the changeset results in the code being simpler and clearer. Please find below an updated changeset incorporating these suggestions (and rebased off jdk7-b136), Let me know if you need anything else to progress this fix forward, Thanks, Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU # HG changeset patch # User Neil Richards , # Date 1300289208 0 # Branch zip-heap # Node ID 6e5ae64dd0437327f9d20f72c55bfdef6649bb7d # Parent aa13e7702cd9d8aca9aa38f1227f966990866944 7031076: Retained ZipFile InputStreams increase heap demand Summary: Allow unreferenced ZipFile InputStreams to be finalized, GC'd Contributed-by: diff -r aa13e7702cd9 -r 6e5ae64dd043 src/share/classes/java/util/zip/ZipFile.java --- a/src/share/classes/java/util/zip/ZipFile.java Tue Mar 29 20:19:55 2011 -0700 +++ b/src/share/classes/java/util/zip/ZipFile.java Wed Mar 16 15:26:48 2011 +0000 @@ -33,9 +33,11 @@ import java.nio.charset.Charset; import java.util.Vector; import java.util.Enumeration; +import java.util.Map; import java.util.Set; -import java.util.HashSet; +import java.util.Iterator; import java.util.NoSuchElementException; +import java.util.WeakHashMap; import java.security.AccessController; import sun.security.action.GetPropertyAction; import static java.util.zip.ZipConstants64.*; @@ -315,7 +317,7 @@ private static native void freeEntry(long jzfile, long jzentry); // the outstanding inputstreams that need to be closed. - private Set streams = new HashSet<>(); + private final Map streams = new WeakHashMap<>(); /** * Returns an input stream for reading the contents of the specified @@ -351,51 +353,17 @@ switch (getEntryMethod(jzentry)) { case STORED: - streams.add(in); + streams.put(in, null); return in; case DEFLATED: - final ZipFileInputStream zfin = in; // MORE: Compute good size for inflater stream: long size = getEntrySize(jzentry) + 2; // Inflater likes a bit of slack if (size > 65536) size = 8192; if (size <= 0) size = 4096; - InputStream is = new InflaterInputStream(zfin, getInflater(), (int)size) { - private boolean isClosed = false; - - public void close() throws IOException { - if (!isClosed) { - super.close(); - releaseInflater(inf); - isClosed = true; - } - } - // Override fill() method to provide an extra "dummy" byte - // at the end of the input stream. This is required when - // using the "nowrap" Inflater option. - protected void fill() throws IOException { - if (eof) { - throw new EOFException( - "Unexpected end of ZLIB input stream"); - } - len = this.in.read(buf, 0, buf.length); - if (len == -1) { - buf[0] = 0; - len = 1; - eof = true; - } - inf.setInput(buf, 0, len); - } - private boolean eof; - - public int available() throws IOException { - if (isClosed) - return 0; - long avail = zfin.size() - inf.getBytesWritten(); - return avail > (long) Integer.MAX_VALUE ? - Integer.MAX_VALUE : (int) avail; - } - }; - streams.add(is); + InputStream is = + new ZipFileInflaterInputStream(in, getInflater(), + (int)size); + streams.put(is, null); return is; default: throw new ZipException("invalid compression method"); @@ -403,6 +371,49 @@ } } + private class ZipFileInflaterInputStream extends InflaterInputStream { + private boolean isClosed = false; + private boolean eof = false; + private final ZipFileInputStream zfin; + + ZipFileInflaterInputStream(ZipFileInputStream zfin, Inflater inf, + int size) { + super(zfin, inf, size); + this.zfin = zfin; + } + + public void close() throws IOException { + if (!isClosed) { + super.close(); + releaseInflater(inf); + isClosed = true; + } + } + // Override fill() method to provide an extra "dummy" byte + // at the end of the input stream. This is required when + // using the "nowrap" Inflater option. + protected void fill() throws IOException { + if (eof) { + throw new EOFException("Unexpected end of ZLIB input stream"); + } + len = in.read(buf, 0, buf.length); + if (len == -1) { + buf[0] = 0; + len = 1; + eof = true; + } + inf.setInput(buf, 0, len); + } + + public int available() throws IOException { + if (isClosed) + return 0; + long avail = zfin.size() - inf.getBytesWritten(); + return (avail > (long) Integer.MAX_VALUE ? + Integer.MAX_VALUE : (int) avail); + } + } + /* * Gets an inflater from the list of available inflaters or allocates * a new one. @@ -543,11 +554,14 @@ synchronized (this) { closeRequested = true; - if (streams.size() !=0) { - Set copy = streams; - streams = new HashSet<>(); - for (InputStream is: copy) + Iterator streamsIterator = + streams.keySet().iterator(); + while (streamsIterator.hasNext()) { + InputStream is = streamsIterator.next(); + if (null != is) { is.close(); + } + streamsIterator.remove(); } if (jzfile != 0) { @@ -684,9 +698,12 @@ freeEntry(ZipFile.this.jzfile, jzentry); jzentry = 0; } - streams.remove(this); } } + + protected void finalize() { + close(); + } } diff -r aa13e7702cd9 -r 6e5ae64dd043 test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java Wed Mar 16 15:26:48 2011 +0000 @@ -0,0 +1,148 @@ +/* + * Copyright (c) 2011 Oracle and/or its affiliates. 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 Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/* + * Portions Copyright (c) 2011 IBM Corporation + */ + +/* + * @test + * @bug 7031076 + * @summary Allow stale InputStreams from ZipFiles to be GC'd + * @author Neil Richards , + */ +import java.lang.ref.ReferenceQueue; +import java.lang.ref.WeakReference; +import java.io.File; +import java.io.FileOutputStream; +import java.io.InputStream; +import java.util.Enumeration; +import java.util.HashSet; +import java.util.Random; +import java.util.Set; +import java.util.zip.ZipEntry; +import java.util.zip.ZipFile; +import java.util.zip.ZipOutputStream; + +public class ClearStaleZipFileInputStreams { + private static final int ZIP_ENTRY_NUM = 5; + + private static final byte[][] data; + + static { + data = new byte[ZIP_ENTRY_NUM][]; + Random r = new Random(); + for (int i = 0; i < ZIP_ENTRY_NUM; i++) { + data[i] = new byte[1000]; + r.nextBytes(data[i]); + } + } + + private static File createTestFile(int compression) throws Exception { + File tempZipFile = + File.createTempFile("test-data" + compression, ".zip"); + tempZipFile.deleteOnExit(); + + ZipOutputStream zos = + new ZipOutputStream(new FileOutputStream(tempZipFile)); + zos.setLevel(compression); + + try { + for (int i = 0; i < ZIP_ENTRY_NUM; i++) { + String text = "Entry" + i; + ZipEntry entry = new ZipEntry(text); + zos.putNextEntry(entry); + try { + zos.write(data[i], 0, data[i].length); + } finally { + zos.closeEntry(); + } + } + } finally { + zos.close(); + } + + return tempZipFile; + } + + private static void startGcInducingThread(final int sleepMillis) { + final Thread gcInducingThread = new Thread() { + public void run() { + while (true) { + System.gc(); + try { + Thread.sleep(sleepMillis); + } catch (InterruptedException e) { } + } + } + }; + + gcInducingThread.setDaemon(true); + gcInducingThread.start(); + } + + public static void main(String[] args) throws Exception { + startGcInducingThread(500); + runTest(ZipOutputStream.DEFLATED); + runTest(ZipOutputStream.STORED); + } + + private static void runTest(int compression) throws Exception { + ReferenceQueue rq = new ReferenceQueue<>(); + + System.out.println("Testing with a zip file with compression level = " + + compression); + File f = createTestFile(compression); + try { + ZipFile zf = new ZipFile(f); + try { + Set refSet = createTransientInputStreams(zf, rq); + + System.out.println("Waiting for 'stale' input streams from ZipFile to be GC'd ..."); + System.out.println("(The test will hang on failure)"); + while (false == refSet.isEmpty()) { + refSet.remove(rq.remove()); + } + System.out.println("Test PASSED."); + System.out.println(); + } finally { + zf.close(); + } + } finally { + f.delete(); + } + } + + private static Set createTransientInputStreams(ZipFile zf, + ReferenceQueue rq) throws Exception { + Enumeration zfe = zf.entries(); + Set refSet = new HashSet<>(); + + while (zfe.hasMoreElements()) { + InputStream is = zf.getInputStream(zfe.nextElement()); + refSet.add(new WeakReference(is, rq)); + } + + return refSet; + } +} From chris.hegarty at oracle.com Fri Apr 8 14:01:38 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 08 Apr 2011 14:01:38 +0000 Subject: hg: jdk7/tl/jdk: 7035020: ForkJoinPool.invoke may deadlock if parallelism = 1 Message-ID: <20110408140156.15DA2478EA@hg.openjdk.java.net> Changeset: 8fbd15bd6149 Author: dl Date: 2011-04-08 10:33 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8fbd15bd6149 7035020: ForkJoinPool.invoke may deadlock if parallelism = 1 Reviewed-by: chegar ! src/share/classes/java/util/concurrent/ForkJoinPool.java From Alan.Bateman at oracle.com Fri Apr 8 15:40:08 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 08 Apr 2011 16:40:08 +0100 Subject: Request for review: 6597112: Referential integrity loophole during remote object export In-Reply-To: References: <4D775A58.6010708@oracle.com> <1301000071.25581.16.camel@chalkhill> Message-ID: <4D9F2C58.9050404@oracle.com> Neil - I think I offered to help get this one in and I'm just wondering if your patch of 3/24 is the latest? Just checking as it would be good to get this one in before jdk7 gets locked down. -Alan Peter Jones wrote: > Neil, > > Hi. For background, I filed 6597112. Thanks for looking into it. > > I don't see any correctness flaws with your suggested fix. It feels to me, however, unnecessarily elaborate for the problem being fixed. It adds an additional (and less localized) use of the Target.pinImpl/unpinImpl mechanism, which is currently only used to "pin" remote objects that are known to have live remote references (or for the internal "permanent" case), for which ongoing strong reachability from a static root (i.e. ObjectTable) is necessary. For this bug, it is only necessary to ensure strong reachability during the execution of the UnicastServerRef.exportObject method in the exporting thread. The reachabilityFence method from the concurrency folks' Fences proposal would enable a robust one-line fix: > > http://g.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/atomic/Fences.html#reachabilityFence(java.lang.Object) > > But I haven't been following the status of that API making it into the JDK. Barring that, other localized approaches should work-- the canonical if not optimal example is passing the reference to a native method. It would be nice to have a recommended idiom from JVM experts.[*] > > Another possibility, though, is to just not throw this ExportException (which is effectively an assertion failure) in ObjectTable.putTarget, but rather let the remote object's export appear to succeed even though it is known to have been garbage collected. Given that the caller isn't ensuring strong reachability of the object, the effect would be indistinguishable from the remote object being collected immediately after the remote object export completes anyway. [This likely indicates a bug in a real application, as opposed to a test case, which is why 6597112 didn't seem especially severe, unlike 6181943.] With this approach, it would be important to guard against the case of ObjectTable.Reaper processing a WeakRef from the queue before ObjectTable.putTarget has executed for it. > > Regarding this diff in particular: > > >> - * If "permanent" is true, then the impl is pinned permanently >> - * (the impl will not be collected via distributed and/or local >> - * GC). If "on" is false, than the impl is subject to >> - * collection. Permanent objects do not keep a server from >> - * exiting. >> + * Upon return, the impl is pinned, thus not initially eligible >> + * for collection via distributed and/or local GC). >> + * If "permanent" is false, the impl subsequently may be made subject to >> + * collection by calling {@link #unpinImpl()}. >> + * Permanent or pinned objects do not keep a server from exiting. >> > > I would leave the last sentence alone-- pinned objects can prevent JVM exit, the point there is really that so-called "permanent" objects don't. > > Cheers, > > -- Peter > > [*] The fix for the similar bug 6181943, in StreamRemoteCall.executeCall, used a DGCAckHandler instance to hold references to objects to be kept strongly reachable for the duration of a remote call, and the invocation of "ackHandler" in the finally block ensured that the container itself remains reachable from the thread for the same duration. For 6181943, there was a desire to hold only remote references, not the entirety of the call arguments, hence the use of DGCAckHandler which cooperates with the object output stream. The 6597112 case is simpler: just need to hold the remote object being exported. > From neil.richards at ngmr.net Fri Apr 8 17:17:49 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Fri, 08 Apr 2011 18:17:49 +0100 Subject: Request for review: 6597112: Referential integrity loophole during remote object export In-Reply-To: <4D9F2C58.9050404@oracle.com> References: <4D775A58.6010708@oracle.com> <1301000071.25581.16.camel@chalkhill> <4D9F2C58.9050404@oracle.com> Message-ID: <1302283069.32207.58.camel@chalkhill> On Fri, 2011-04-08 at 16:40 +0100, Alan Bateman wrote: > > Neil - I think I offered to help get this one in and I'm just > wondering if your patch of 3/24 is the latest? Just checking as it > would be good to get this one in before jdk7 gets locked down. > > -Alan Hi Alan, thanks for the prod (and apologies for the delay - see my excuses below). > Peter Jones wrote: > > Hi. For background, I filed 6597112. Thanks for looking into it. > > > > Another possibility, though, is to just not throw this > > ExportException (which is effectively an assertion failure) in > > ObjectTable.putTarget, but rather let the remote object's export > > appear to succeed even though it is known to have been garbage > > collected. Hi Peter, Thank you for your review on this problem - it really helped in highlighting some invalid assumptions I was making about the way that the RMI code behaves. I had assumed that, once the stub is returned from exportObject, the 'liveness' of the stub would control the the 'liveness' of the exported object (as the stub is, logically, a kind of remote reference to the object). I'd argue this is a naturally reasonable expectation to have (ie. it would be good to enhance the RMI mechanism so that behaves this way), but, as you point out, that's not how it currently behaves (there are current get-out clauses in the RMI spec which warn about the behaviour being different than one would initially expect in this case). (I easily found a conversation [1] highlighting the confusion the current behaviour causes for a Java developer unversed in the deeper machinations of the RMI server - I suspect the developer's confusion here is not unique). If the RMI were enhanced so that reality met with my initial assumptions (!), I now see that the messing about with pinning & unpinning WeakRef would probably be unnecessary (as the impl would be held strongly by another means whilst the stub lives). Until / unless it is enhanced in this way, I agree that messing about with pinning & unpinning WeakRef is overly complex, given that the impl object is going to disappear immediately anyhow. I've been looking into how one would change the code to make the behavioural enhancement, but realise I'm running out of runway to develop / champion such a change at this point in the schedule. Given all of this, your suggestion of modifying ObjectTable.putTarget() such that it is tolerant of being given Targets whose impl objects may have been GC'd (ie. without it throwing an exception) seems excellent to me. Please find below a (far simpler) revised suggested changeset, which addresses the problem in this fashion. (NB: In the new changeset, the check for the impl having been GC'd is now within the block synchronized on tableLock. The operation of the Reaper thread is also performed synchronized on this lock. This ensures that the keep alive count is incremented / decremented properly, even if the impl happens to be GC'd after the check). Please let me know if you have any further comments or suggestions on this, Thanks, Neil [1] http://www.coderanch.com/t/492590/java/java/RMI-GC -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU # HG changeset patch # User Neil Richards , # Date 1302196316 -3600 # Branch j6597112 # Node ID cfa1f7fcaabb03ab79aae8f051e4c084b45c75b9 # Parent aa13e7702cd9d8aca9aa38f1227f966990866944 6597112: referential integrity loophole during remote object export Summary: Make ObjectTable.putTarget() tolerant of Target's with a GC'd impl Contributed-by: diff -r aa13e7702cd9 -r cfa1f7fcaabb src/share/classes/sun/rmi/transport/ObjectTable.java --- a/src/share/classes/sun/rmi/transport/ObjectTable.java Tue Mar 29 20:19:55 2011 -0700 +++ b/src/share/classes/sun/rmi/transport/ObjectTable.java Thu Apr 07 18:11:56 2011 +0100 @@ -175,25 +175,21 @@ DGCImpl.dgcLog.log(Log.VERBOSE, "add object " + oe); } - Remote impl = target.getImpl(); - if (impl == null) { - throw new ExportException( - "internal error: attempt to export collected object"); - } + synchronized (tableLock) { + if (null != target.getImpl()) { + if (objTable.containsKey(oe)) { + throw new ExportException( + "internal error: ObjID already in use"); + } else if (implTable.containsKey(weakImpl)) { + throw new ExportException("object already exported"); + } - synchronized (tableLock) { - if (objTable.containsKey(oe)) { - throw new ExportException( - "internal error: ObjID already in use"); - } else if (implTable.containsKey(weakImpl)) { - throw new ExportException("object already exported"); - } + objTable.put(oe, target); + implTable.put(weakImpl, target); - objTable.put(oe, target); - implTable.put(weakImpl, target); - - if (!target.isPermanent()) { - incrementKeepAliveCount(); + if (!target.isPermanent()) { + incrementKeepAliveCount(); + } } } } diff -r aa13e7702cd9 -r cfa1f7fcaabb test/java/rmi/server/UnicastRemoteObject/gcDuringExport/GcDuringExport.java --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/test/java/rmi/server/UnicastRemoteObject/gcDuringExport/GcDuringExport.java Thu Apr 07 18:11:56 2011 +0100 @@ -0,0 +1,67 @@ +/* + * Copyright (c) 2011 Oracle and/or its affiliates. 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 Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/* + * Portions Copyright (c) 2011 IBM Corporation + */ + +/* + * @test + * @bug 6597112 + * @summary GC'ing objects whilst being exported to RMI should not cause exceptions + * @author Neil Richards , + */ + +import java.rmi.Remote; +import java.rmi.server.UnicastRemoteObject; + +public class GcDuringExport { + private static final long MAX_EXPORT_ITERATIONS = 50000; + + public static void main(String[] args) throws Exception { + final Thread gcInducingThread = new Thread() { + public void run() { while (true) { + System.gc(); + try { Thread.sleep(1); } catch (InterruptedException e) { } + } + } + }; + + gcInducingThread.setDaemon(true); + gcInducingThread.start(); + + long i = 0; + try { + while (i < MAX_EXPORT_ITERATIONS) { + i++; + UnicastRemoteObject.exportObject(new Remote() { }, 0); + } + } catch (Throwable e) { + throw new RuntimeException("Test FAILED on iteration " + i + ".", e); + } + + System.out.println("Test successfully exported " + i + " objects."); + } +} + + From joe.darcy at oracle.com Fri Apr 8 18:27:33 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 08 Apr 2011 11:27:33 -0700 Subject: Code review request for 6998871 "Support making the Throwable.stackTrace field immutable" In-Reply-To: <4D9E7252.9050003@oracle.com> References: <4D9D59AE.7040701@oracle.com> <4D9DC908.9040507@univ-mlv.fr> <4D9E4825.5010504@oracle.com> <4D9E7252.9050003@oracle.com> Message-ID: <4D9F5395.6010401@oracle.com> Updated webrev described below... Joe Darcy wrote: > Joe Darcy wrote: >> Hi R?mi. >> >> R?mi Forax wrote: >>> On 04/07/2011 08:29 AM, Joe Darcy wrote: >>>> Hello. >>>> >>>> Returning to some earlier work, I've developed a proposed fix for >>>> >>>> 6998871 "Support making the Throwable.stackTrace field immutable" >>>> http://cr.openjdk.java.net/~darcy/6998871.2/ >>>> >>>> One constructor of Throwable now takes an additional boolean >>>> argument to make the stack trace information immutable. Analogous >>>> constructors are added to Exception, RuntimeException, and Error. >>>> >>>> Mandy and David have already reviewed the change; I'm interested in >>>> getting additional feedback on the design of the API. >>>> >>>> Cheers, >>>> >>>> -Joe >>> >>> Joe, >>> I don't think you need the sentinel in the serialized form, >>> you have only two states: an immutable stacktrace (stacktrace == >>> null) or >>> a stacktrace. I think it's better to don't serialize the field >>> "stacktrace" if >>> the stacktrace is immutable. >>> >>> Also, FILLED_IN_STACK is not necessary, you can use EMPTY_STACKinstead, >>> or if you find it hard to understand, at least FILLED_IN_STACK >>> should be an empty array. >>> >>> R?mi >>> >> >> Here is an explanation and rationale of the protocol in more detail. >> As far as serialization goes, there are three cases of interest where >> "new" means JDK 7 and "old" means any release prior to JDK 7 >> >> 1) Object serialized on *new* platform has same semantics after being >> deserialized on *new* platform. >> >> 2) Object serialized on *old* platform has same semantics after being >> deserialized on *new* platform. >> >> 3) Object serialized on *new* platform has reasonable semantics after >> being deserialized on *old* platform. >> >> (And of course when both source and destination platforms are old, >> JDK 7 isn't involved.) >> >> For point 1), a logically equivalent object should result, which in >> this case means the cause, stack trace, stack trace, message, etc. >> should be the same on the old and new objects. >> >> For 2), if an exception object serialized prior to the stack trace >> facility being added was deserialized in JDK 7, that is logically >> equivalent to there being not stack trace information, so an empty >> stack is a better result than an immutable stack. I've updated the >> readObject method accordingly. >> >> For 3), since null was not a valid value for stackTrace in the past, >> some other sentinel object should be written in out in the serial >> form to denote such a value, which is the role played by >> STACK_TRACE_SENTINEL as used in the writeObject method. >> >> A marker value other than EMPTY_STACK is needed for the following >> reason since the stack trace information is spread amongst two >> fields, backtrace and stackTrace. The transient backtrace field >> pre-dates the programmatic stack facility being added; that facility >> uses the stackTrace field. If fillInStackTrace is called *after* a >> call to setStackTrace, the real stack information is held in the >> backtrace field as written by fillInStackTrace. The FILLED_IN_STACK >> value alerts the getourstacktrace method to this situation. >> >> Revised webrev: >> >> http://cr.openjdk.java.net/~darcy/6998871.3/ >> >> Thanks, >> >> -Joe > > PS A little more detail here, exception objects can be created via > deserialization as well as by a constructor. As currently written, > the writeObject method uses EMPTY_STACK for both a zero-length > incoming stack and a null stackTrace pointer (which can result from an > throwable object serialized from a JDK release before the stack trace > facility was added). The native fillInStackTrace method writes a null > into the stackTrace field to indicate it is no longer valid; this goes > against the new protocol and the Java-level of fillInStackTraces needs > to write a non-null "dirty" value into the field to signal to > getOurStackTrace that the stack trace array needs to be recomputed if > requested. Therefore, if fillInStackTrace were called on one of these > deserialized objects to logically replace its stack trace, using > EMPTY_STACK would not allow the getOutStackTrace code to know that the > stack trace had logically been replaced by a new value in backtrace > since EMPY_STACK could result from serialization. > > The serialization code could use EMPTY_STACK.clone() instead of > EMPTY_STACK, which would break the object equality being tested in > getOurStackTrace. I'll consider making this change in the > Throwable.readObject method. > > Cheers, > > -Joe I've put the updated webrev up at http://cr.openjdk.java.net/~darcy/6998871.4/ Diff of Throwable compared to .3 version is below. EMPTY_STACK has been renamed to UNASSIGNED_STACK and that value (or a clone if it) is used as the sentential and for zero-length arrays. The distinct FILLED_IN_STACK value has been removed. The protocol around updating the fields is better documented. In other files, ArithmeticException, NullPointerException, and OutOfMemoryError are updated to state the VM may created them with immutable stack too. Thanks, -Joe 157,163d156 < * A value indicating that the logical stack trace has been < * populated into the backtrace field. < */ < private static final StackTraceElement[] FILLED_IN_STACK = < new StackTraceElement[] {new StackTraceElement("FILLED_IN", "STACK", null, -1)}; < < /** 166c159 < private static final StackTraceElement[] EMPTY_STACK = new StackTraceElement[0]; --- > private static final StackTraceElement[] UNASSIGNED_STACK = new StackTraceElement[0]; 211c204,205 < * #setStackTrace()} and {@link #fillInStackTrace} will be be no-ops. --- > * #setStackTrace(StackTraceElement[])} and {@link > * #fillInStackTrace()} will be be no-ops. 216c210 < private StackTraceElement[] stackTrace = EMPTY_STACK; --- > private StackTraceElement[] stackTrace = UNASSIGNED_STACK; 330c324,325 < * #fillInStackTrace()} and subsequent calls to {@code --- > * #fillInStackTrace()}, a {@code null} will be written to the > * {@code stackTrace} field, and subsequent calls to {@code 339,342c334,339 < * conditions under which suppression is disabled. Disabling of < * suppression should only occur in exceptional circumstances < * where special requirements exist, such as a virtual machine < * reusing exception objects under low-memory situations. --- > * conditions under which suppression is disabled and document > * conditions under which the stack trace is not writable. > * Disabling of suppression should only occur in exceptional > * circumstances where special requirements exist, such as a > * virtual machine reusing exception objects under low-memory > * situations. 770c767 < stackTrace = FILLED_IN_STACK; --- > stackTrace = UNASSIGNED_STACK; 807c804 < if (stackTrace == FILLED_IN_STACK) { --- > if (stackTrace == UNASSIGNED_STACK) { 813c810 < return EMPTY_STACK; --- > return UNASSIGNED_STACK; 886,888c883,886 < * trace elements. A single-element stack trace whose entry is < * equal to {@code new StackTraceElement("", "", null, < * Integer.MIN_VALUE)} results in a {@code null} {@code --- > * trace elements. A null stack trace in the serial form results > * in a zero-length stack element array. A single-element stack > * trace whose entry is equal to {@code new StackTraceElement("", > * "", null, Integer.MIN_VALUE)} results in a {@code null} {@code 918c916,924 < // Check for the marker of an immutable stack trace --- > /* > * For zero-length stack traces, use a clone of > * UNASSIGNED_STACK rather than UNASSIGNED_STACK itself to > * allow identity comparison against UNASSIGNED_STACK in > * getOurStackTrace. The identity of UNASSIGNED_STACK in > * stackTrace indicates to the getOurStackTrace method that > * the stackTrace needs to be constructed from the information > * in backtrace. > */ 920d925 < // Share zero-length stack traces 922c927 < stackTrace = EMPTY_STACK; --- > stackTrace = UNASSIGNED_STACK.clone(); 923a929 > // Check for the marker of an immutable stack trace 937c943 < stackTrace = EMPTY_STACK; --- > stackTrace = UNASSIGNED_STACK.clone(); 976,977c982,983 < * {@linkplain #Throwable(String, Throwable, boolean) via a < * constructor}. When suppression is disabled, this method does --- > * {@linkplain #Throwable(String, Throwable, boolean, boolean) via > * a constructor}. When suppression is disabled, this method does 1043,1044c1049,1050 < * #Throwable(String, Throwable, boolean) suppression is disabled}, < * an empty array is returned. --- > * #Throwable(String, Throwable, boolean, boolean) suppression is > * disabled}, an empty array is returned. From forax at univ-mlv.fr Fri Apr 8 20:43:46 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 08 Apr 2011 22:43:46 +0200 Subject: Code review request for 6998871 "Support making the Throwable.stackTrace field immutable" In-Reply-To: <4D9F5395.6010401@oracle.com> References: <4D9D59AE.7040701@oracle.com> <4D9DC908.9040507@univ-mlv.fr> <4D9E4825.5010504@oracle.com> <4D9E7252.9050003@oracle.com> <4D9F5395.6010401@oracle.com> Message-ID: <4D9F7382.6040504@univ-mlv.fr> Maybe I'm wrong but you can reuse the same clone. I mean, it has to have a different identity from UNASSIGNED_STACK but it can be the same for all clones. R?mi On 04/08/2011 08:27 PM, Joe Darcy wrote: > Updated webrev described below... > > Joe Darcy wrote: >> Joe Darcy wrote: >>> Hi R?mi. >>> >>> R?mi Forax wrote: >>>> On 04/07/2011 08:29 AM, Joe Darcy wrote: >>>>> Hello. >>>>> >>>>> Returning to some earlier work, I've developed a proposed fix for >>>>> >>>>> 6998871 "Support making the Throwable.stackTrace field immutable" >>>>> http://cr.openjdk.java.net/~darcy/6998871.2/ >>>>> >>>>> One constructor of Throwable now takes an additional boolean >>>>> argument to make the stack trace information immutable. Analogous >>>>> constructors are added to Exception, RuntimeException, and Error. >>>>> >>>>> Mandy and David have already reviewed the change; I'm interested >>>>> in getting additional feedback on the design of the API. >>>>> >>>>> Cheers, >>>>> >>>>> -Joe >>>> >>>> Joe, >>>> I don't think you need the sentinel in the serialized form, >>>> you have only two states: an immutable stacktrace (stacktrace == >>>> null) or >>>> a stacktrace. I think it's better to don't serialize the field >>>> "stacktrace" if >>>> the stacktrace is immutable. >>>> >>>> Also, FILLED_IN_STACK is not necessary, you can use >>>> EMPTY_STACKinstead, >>>> or if you find it hard to understand, at least FILLED_IN_STACK >>>> should be an empty array. >>>> >>>> R?mi >>>> >>> >>> Here is an explanation and rationale of the protocol in more >>> detail. As far as serialization goes, there are three cases of >>> interest where "new" means JDK 7 and "old" means any release prior >>> to JDK 7 >>> >>> 1) Object serialized on *new* platform has same semantics after >>> being deserialized on *new* platform. >>> >>> 2) Object serialized on *old* platform has same semantics after >>> being deserialized on *new* platform. >>> >>> 3) Object serialized on *new* platform has reasonable semantics >>> after being deserialized on *old* platform. >>> >>> (And of course when both source and destination platforms are old, >>> JDK 7 isn't involved.) >>> >>> For point 1), a logically equivalent object should result, which in >>> this case means the cause, stack trace, stack trace, message, etc. >>> should be the same on the old and new objects. >>> >>> For 2), if an exception object serialized prior to the stack trace >>> facility being added was deserialized in JDK 7, that is logically >>> equivalent to there being not stack trace information, so an empty >>> stack is a better result than an immutable stack. I've updated the >>> readObject method accordingly. >>> >>> For 3), since null was not a valid value for stackTrace in the past, >>> some other sentinel object should be written in out in the serial >>> form to denote such a value, which is the role played by >>> STACK_TRACE_SENTINEL as used in the writeObject method. >>> >>> A marker value other than EMPTY_STACK is needed for the following >>> reason since the stack trace information is spread amongst two >>> fields, backtrace and stackTrace. The transient backtrace field >>> pre-dates the programmatic stack facility being added; that facility >>> uses the stackTrace field. If fillInStackTrace is called *after* a >>> call to setStackTrace, the real stack information is held in the >>> backtrace field as written by fillInStackTrace. The FILLED_IN_STACK >>> value alerts the getourstacktrace method to this situation. >>> >>> Revised webrev: >>> >>> http://cr.openjdk.java.net/~darcy/6998871.3/ >>> >>> Thanks, >>> >>> -Joe >> >> PS A little more detail here, exception objects can be created via >> deserialization as well as by a constructor. As currently written, >> the writeObject method uses EMPTY_STACK for both a zero-length >> incoming stack and a null stackTrace pointer (which can result from >> an throwable object serialized from a JDK release before the stack >> trace facility was added). The native fillInStackTrace method writes >> a null into the stackTrace field to indicate it is no longer valid; >> this goes against the new protocol and the Java-level of >> fillInStackTraces needs to write a non-null "dirty" value into the >> field to signal to getOurStackTrace that the stack trace array needs >> to be recomputed if requested. Therefore, if fillInStackTrace were >> called on one of these deserialized objects to logically replace its >> stack trace, using EMPTY_STACK would not allow the getOutStackTrace >> code to know that the stack trace had logically been replaced by a >> new value in backtrace since EMPY_STACK could result from serialization. >> >> The serialization code could use EMPTY_STACK.clone() instead of >> EMPTY_STACK, which would break the object equality being tested in >> getOurStackTrace. I'll consider making this change in the >> Throwable.readObject method. >> >> Cheers, >> >> -Joe > > I've put the updated webrev up at > > http://cr.openjdk.java.net/~darcy/6998871.4/ > > Diff of Throwable compared to .3 version is below. EMPTY_STACK has > been renamed to UNASSIGNED_STACK and that value (or a clone if it) is > used as the sentential and for zero-length arrays. The distinct > FILLED_IN_STACK value has been removed. The protocol around updating > the fields is better documented. In other files, ArithmeticException, > NullPointerException, and OutOfMemoryError are updated to state the VM > may created them with immutable stack too. > > Thanks, > > -Joe > > 157,163d156 > < * A value indicating that the logical stack trace has been > < * populated into the backtrace field. > < */ > < private static final StackTraceElement[] FILLED_IN_STACK = > < new StackTraceElement[] {new StackTraceElement("FILLED_IN", > "STACK", null, -1)}; > < > < /** > 166c159 > < private static final StackTraceElement[] EMPTY_STACK = new > StackTraceElement[0]; > --- > > private static final StackTraceElement[] UNASSIGNED_STACK = new > StackTraceElement[0]; > 211c204,205 > < * #setStackTrace()} and {@link #fillInStackTrace} will be be > no-ops. > --- > > * #setStackTrace(StackTraceElement[])} and {@link > > * #fillInStackTrace()} will be be no-ops. > 216c210 > < private StackTraceElement[] stackTrace = EMPTY_STACK; > --- > > private StackTraceElement[] stackTrace = UNASSIGNED_STACK; > 330c324,325 > < * #fillInStackTrace()} and subsequent calls to {@code > --- > > * #fillInStackTrace()}, a {@code null} will be written to the > > * {@code stackTrace} field, and subsequent calls to {@code > 339,342c334,339 > < * conditions under which suppression is disabled. Disabling of > < * suppression should only occur in exceptional circumstances > < * where special requirements exist, such as a virtual machine > < * reusing exception objects under low-memory situations. > --- > > * conditions under which suppression is disabled and document > > * conditions under which the stack trace is not writable. > > * Disabling of suppression should only occur in exceptional > > * circumstances where special requirements exist, such as a > > * virtual machine reusing exception objects under low-memory > > * situations. > 770c767 > < stackTrace = FILLED_IN_STACK; > --- > > stackTrace = UNASSIGNED_STACK; > 807c804 > < if (stackTrace == FILLED_IN_STACK) { > --- > > if (stackTrace == UNASSIGNED_STACK) { > 813c810 > < return EMPTY_STACK; > --- > > return UNASSIGNED_STACK; > 886,888c883,886 > < * trace elements. A single-element stack trace whose entry is > < * equal to {@code new StackTraceElement("", "", null, > < * Integer.MIN_VALUE)} results in a {@code null} {@code > --- > > * trace elements. A null stack trace in the serial form results > > * in a zero-length stack element array. A single-element stack > > * trace whose entry is equal to {@code new StackTraceElement("", > > * "", null, Integer.MIN_VALUE)} results in a {@code null} {@code > 918c916,924 > < // Check for the marker of an immutable stack trace > --- > > /* > > * For zero-length stack traces, use a clone of > > * UNASSIGNED_STACK rather than UNASSIGNED_STACK itself to > > * allow identity comparison against UNASSIGNED_STACK in > > * getOurStackTrace. The identity of UNASSIGNED_STACK in > > * stackTrace indicates to the getOurStackTrace method that > > * the stackTrace needs to be constructed from the information > > * in backtrace. > > */ > 920d925 > < // Share zero-length stack traces > 922c927 > < stackTrace = EMPTY_STACK; > --- > > stackTrace = UNASSIGNED_STACK.clone(); > 923a929 > > // Check for the marker of an immutable > stack trace > 937c943 > < stackTrace = EMPTY_STACK; > --- > > stackTrace = UNASSIGNED_STACK.clone(); > 976,977c982,983 > < * {@linkplain #Throwable(String, Throwable, boolean) via a > < * constructor}. When suppression is disabled, this method does > --- > > * {@linkplain #Throwable(String, Throwable, boolean, boolean) via > > * a constructor}. When suppression is disabled, this method does > 1043,1044c1049,1050 > < * #Throwable(String, Throwable, boolean) suppression is disabled}, > < * an empty array is returned. > --- > > * #Throwable(String, Throwable, boolean, boolean) suppression is > > * disabled}, an empty array is returned. > > From David.Holmes at oracle.com Fri Apr 8 23:01:20 2011 From: David.Holmes at oracle.com (David Holmes) Date: Sat, 09 Apr 2011 09:01:20 +1000 Subject: Suspected regression: fix for 6735255 causes delay in GC of ZipFile InputStreams, increase in heap demand In-Reply-To: <1302266193.17745.18.camel@chalkhill> References: <1300916786.4515.107.camel@chalkhill> <4D922D68.2080202@oracle.com> <1301514810.24605.64.camel@chalkhill> <4D93930A.2000604@oracle.com> <1301676177.24605.165.camel@chalkhill> <4D962275.7010601@oracle.com> <4D965D14.6060504@oracle.com> <1301707718.14323.43.camel@chalkhill> <4D98FD10.4090608@oracle.com> <1302183023.27698.20.camel@chalkhill> <4D9E429F.9030200@oracle.com> <1302266193.17745.18.camel@chalkhill> Message-ID: <4D9F93C0.7050800@oracle.com> Neil, You now have concurrency issues again. isClosed would need to be volatile if the methods that set/check it aren't synchronized. Multiple threads could call close() at the same time, and threads can call available etc after close has finished its main work. David Neil Richards said the following on 04/08/11 22:36: > On Thu, 2011-04-07 at 16:02 -0700, Xueming Shen wrote: >> It appears it might not be necessary to do the finalize() in >> ZipFileInflaterInputStream. The ZipFileInflaterInputStream itself does >> not directly hold any native resource by itself that needs to be >> released at the end of its life circle, if not closed explicitly. The >> native resource/memory that need to be taken care of are held by its >> fields "inf" and "zfin", which should be finalized by the >> corresponding finalize() of their own classes (again, if not closed >> explicitly), when their outer ZFIIS object is unreachable. The Inflater >> class has its own finalize() implemented already to invoke its cleanup >> method end(), so the only thing need to be addressed is to add the >> finalize() into ZipFileInputStream class to call its close(), strictly >> speaking this issue is not the regression caused by #6735255, we have >> this "leak" before #6735255. >> >> Also, would you like to consider to use WeakHeapMap >> instead of handling all the weak reference impl by yourself, the bonus >> would be that the stalled entries might be cleaned up more frequently. >> > > Hi Sherman, > Thanks for your continuing analysis of this change. > > I concur with your assessment above, and agree that making the suggested > modifications to the changeset results in the code being simpler and > clearer. > > Please find below an updated changeset incorporating these suggestions > (and rebased off jdk7-b136), > > Let me know if you need anything else to progress this fix forward, > Thanks, > Neil > From neil.richards at ngmr.net Sat Apr 9 00:04:29 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Sat, 9 Apr 2011 01:04:29 +0100 Subject: Suspected regression: fix for 6735255 causes delay in GC of ZipFile InputStreams, increase in heap demand In-Reply-To: <4D9F93C0.7050800@oracle.com> References: <1300916786.4515.107.camel@chalkhill> <4D922D68.2080202@oracle.com> <1301514810.24605.64.camel@chalkhill> <4D93930A.2000604@oracle.com> <1301676177.24605.165.camel@chalkhill> <4D962275.7010601@oracle.com> <4D965D14.6060504@oracle.com> <1301707718.14323.43.camel@chalkhill> <4D98FD10.4090608@oracle.com> <1302183023.27698.20.camel@chalkhill> <4D9E429F.9030200@oracle.com> <1302266193.17745.18.camel@chalkhill> <4D9F93C0.7050800@oracle.com> Message-ID: Hi David, You are correct that the ZipFileInflaterInputStream code is not inherently thread-safe (without user synchronization), but then, the contract of InputStream does not require it to be (as Sherman previously observed on this thread). The previous suggested fix caused ZFIIS to interact with the finalize thread, thus it had to care about being thread-safe at least to the extent of safe-guarding that interaction. As Sherman observed, and I agreed, finalization on that object is not really needed, so the inherent cross-thread interaction that would be introduced by the finalize method can be avoided in that case, and so the need to cater for inherent thread-safety can likewise be avoided. With the latest suggested change, if the ZFIIS is driven by multiple threads, it will be done at the user's (developer's) behest, so the user can (should) know to implement suitable synchronization to ensure correct behaviour. Therefore, I believe the same lack of synchronization in ZFIIS as there was in the previous anonymous inner class to be entirely justified in this case, given that it no longer has a finalize() method. Please let me know if you still disagree with this assessment, Thanks, Neil (Sent from my phone, so probably missing my usual signature) From David.Holmes at oracle.com Sat Apr 9 01:14:24 2011 From: David.Holmes at oracle.com (David Holmes) Date: Sat, 09 Apr 2011 11:14:24 +1000 Subject: Suspected regression: fix for 6735255 causes delay in GC of ZipFile InputStreams, increase in heap demand In-Reply-To: References: <1300916786.4515.107.camel@chalkhill> <4D922D68.2080202@oracle.com> <1301514810.24605.64.camel@chalkhill> <4D93930A.2000604@oracle.com> <1301676177.24605.165.camel@chalkhill> <4D962275.7010601@oracle.com> <4D965D14.6060504@oracle.com> <1301707718.14323.43.camel@chalkhill> <4D98FD10.4090608@oracle.com> <1302183023.27698.20.camel@chalkhill> <4D9E429F.9030200@oracle.com> <1302266193.17745.18.camel@chalkhill> <4D9F93C0.7050800@oracle.com> Message-ID: <4D9FB2F0.6050707@oracle.com> Neil Richards said the following on 04/09/11 10:04: > You are correct that the ZipFileInflaterInputStream code is not > inherently thread-safe (without user synchronization), but then, the > contract of InputStream does not require it to be (as Sherman previously > observed on this thread). > > The previous suggested fix caused ZFIIS to interact with the finalize > thread, thus it had to care about being thread-safe at least to the > extent of safe-guarding that interaction. > > As Sherman observed, and I agreed, finalization on that object is not > really needed, so the inherent cross-thread interaction that would be > introduced by the finalize method can be avoided in that case, and so > the need to cater for inherent thread-safety can likewise be avoided. Ok. David ------ > With the latest suggested change, if the ZFIIS is driven by multiple > threads, it will be done at the user's (developer's) behest, so the user > can (should) know to implement suitable synchronization to ensure > correct behaviour. > > Therefore, I believe the same lack of synchronization in ZFIIS as there > was in the previous anonymous inner class to be entirely justified in > this case, given that it no longer has a finalize() method. > > Please let me know if you still disagree with this assessment, > Thanks, > Neil > > (Sent from my phone, so probably missing my usual signature) > From xueming.shen at oracle.com Sat Apr 9 03:53:26 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 08 Apr 2011 20:53:26 -0700 Subject: Suspected regression: fix for 6735255 causes delay in GC of ZipFile InputStreams, increase in heap demand In-Reply-To: <1302266193.17745.18.camel@chalkhill> References: <1300916786.4515.107.camel@chalkhill> <4D922D68.2080202@oracle.com> <1301514810.24605.64.camel@chalkhill> <4D93930A.2000604@oracle.com> <1301676177.24605.165.camel@chalkhill> <4D962275.7010601@oracle.com> <4D965D14.6060504@oracle.com> <1301707718.14323.43.camel@chalkhill> <4D98FD10.4090608@oracle.com> <1302183023.27698.20.camel@chalkhill> <4D9E429F.9030200@oracle.com> <1302266193.17745.18.camel@chalkhill> Message-ID: <4D9FD836.1070909@oracle.com> Neil, Regression test /test/java/util/zip/ZipFile/FinalizeInflater.java failed with this fix. The possible solution I can think of now is to do nothing but simply return the inflater back to the cache, but do an additional sanity check when "check out" private Inflater getInflater() { synchronized (inflaters) { int size = inflaters.size(); while ((size = inflaters.size())> 0) { Inflater inf = inflaters.remove(size - 1); if (!inf.ended()) return inf; } return new Inflater(true); } } http://cr.openjdk.java.net/~sherman/7031076/webrev/ What do you think? have a better idea? Sherman On 04-08-2011 5:36 AM, Neil Richards wrote: > On Thu, 2011-04-07 at 16:02 -0700, Xueming Shen wrote: >> It appears it might not be necessary to do the finalize() in >> ZipFileInflaterInputStream. The ZipFileInflaterInputStream itself does >> not directly hold any native resource by itself that needs to be >> released at the end of its life circle, if not closed explicitly. The >> native resource/memory that need to be taken care of are held by its >> fields "inf" and "zfin", which should be finalized by the >> corresponding finalize() of their own classes (again, if not closed >> explicitly), when their outer ZFIIS object is unreachable. The Inflater >> class has its own finalize() implemented already to invoke its cleanup >> method end(), so the only thing need to be addressed is to add the >> finalize() into ZipFileInputStream class to call its close(), strictly >> speaking this issue is not the regression caused by #6735255, we have >> this "leak" before #6735255. >> >> Also, would you like to consider to use WeakHeapMap >> instead of handling all the weak reference impl by yourself, the bonus >> would be that the stalled entries might be cleaned up more frequently. >> > Hi Sherman, > Thanks for your continuing analysis of this change. > > I concur with your assessment above, and agree that making the suggested > modifications to the changeset results in the code being simpler and > clearer. > > Please find below an updated changeset incorporating these suggestions > (and rebased off jdk7-b136), > > Let me know if you need anything else to progress this fix forward, > Thanks, > Neil > From David.Holmes at oracle.com Sat Apr 9 07:42:12 2011 From: David.Holmes at oracle.com (David Holmes) Date: Sat, 09 Apr 2011 17:42:12 +1000 Subject: Urgent Request for review: 7035109 Regression: awt SplashScreen/test18.sh fails - missing mapfile entry Message-ID: <4DA00DD4.307@oracle.com> Very simple review - the mapfile was missing an entry for a new native method added in 7030063 and caused an UnsatisfiedLinkError http://cr.openjdk.java.net/~dholmes/jdk7-clone/webrev-7035109/ Failing test now passes. Due to the urgency this will get pushed directly into the TL PIT jdk repo so that it will be paired with 7030063 and present in b138. Thanks, David From Alan.Bateman at oracle.com Sat Apr 9 08:57:59 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 09 Apr 2011 09:57:59 +0100 Subject: Urgent Request for review: 7035109 Regression: awt SplashScreen/test18.sh fails - missing mapfile entry In-Reply-To: <4DA00DD4.307@oracle.com> References: <4DA00DD4.307@oracle.com> Message-ID: <4DA01F97.9070507@oracle.com> David Holmes wrote: > Very simple review - the mapfile was missing an entry for a new native > method added in 7030063 and caused an UnsatisfiedLinkError > > http://cr.openjdk.java.net/~dholmes/jdk7-clone/webrev-7035109/ > > Failing test now passes. > > Due to the urgency this will get pushed directly into the TL PIT jdk > repo so that it will be paired with 7030063 and present in b138. There is always a bit of risk pushing AWT or other client area changes to the TL forest as probably very few of us run those tests. The update the map file looks good to me. -Alan. From kumar.x.srinivasan at oracle.com Sat Apr 9 15:08:19 2011 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Sat, 9 Apr 2011 08:08:19 -0700 (PDT) Subject: Urgent Request for review: 7035109 Regression: awt SplashScreen/test18.sh fails - missing mapfile entry Message-ID: Approved!. I agree with Alan if a change is to be made in a component, it is best that it is pushed to that component's forest/repo, where all the necessary/appropriate tests will be performed on a nightly basis. Kumar ----- Alan.Bateman at oracle.com wrote: > From: Alan.Bateman at oracle.com > To: David.Holmes at oracle.com > Cc: awt-dev at openjdk.java.net, core-libs-dev at openjdk.java.net > Sent: Saturday, April 9, 2011 1:59:17 AM GMT -08:00 US/Canada Pacific > Subject: Re: Urgent Request for review: 7035109 Regression: awt SplashScreen/test18.sh fails - missing mapfile entry > > David Holmes wrote: > > Very simple review - the mapfile was missing an entry for a new > native > > method added in 7030063 and caused an UnsatisfiedLinkError > > > > http://cr.openjdk.java.net/~dholmes/jdk7-clone/webrev-7035109/ > > > > Failing test now passes. > > > > Due to the urgency this will get pushed directly into the TL PIT jdk > > > repo so that it will be paired with 7030063 and present in b138. > There is always a bit of risk pushing AWT or other client area changes > > to the TL forest as probably very few of us run those tests. The > update > the map file looks good to me. > > -Alan. From philip.race at oracle.com Sun Apr 10 16:39:27 2011 From: philip.race at oracle.com (Phil Race) Date: Sun, 10 Apr 2011 09:39:27 -0700 Subject: Urgent Request for review: 7035109 Regression: awt SplashScreen/test18.sh fails - missing mapfile entry In-Reply-To: References: Message-ID: <4DA1DD3F.2080109@oracle.com> I think that there can be times when something is extremely cross-area and that makes it more of a pain if it can't easily be divided up. But I completely agree that running the right tests is a vital part of making sure there are no problems. I don't know if that would have happened any faster in this case. But so is the review. Code changes that cross areas should also be posted for review by the relevant teams. Some times that might save pain down the line. So if you change awt code, send the review to the AWT team (etc). I expect core libs would like to know if I decided to change something in java.util :-) -phil. On 4/9/2011 8:08 AM, Kumar Srinivasan wrote: > Approved!. I agree with Alan if a change is to be made in > a component, it is best that it is pushed to that component's > forest/repo, where all the necessary/appropriate tests will be > performed on a nightly basis. > > Kumar > > > ----- Alan.Bateman at oracle.com wrote: > >> From: Alan.Bateman at oracle.com >> To: David.Holmes at oracle.com >> Cc: awt-dev at openjdk.java.net, core-libs-dev at openjdk.java.net >> Sent: Saturday, April 9, 2011 1:59:17 AM GMT -08:00 US/Canada Pacific >> Subject: Re: Urgent Request for review: 7035109 Regression: awt SplashScreen/test18.sh fails - missing mapfile entry >> >> David Holmes wrote: >>> Very simple review - the mapfile was missing an entry for a new >> native >>> method added in 7030063 and caused an UnsatisfiedLinkError >>> >>> http://cr.openjdk.java.net/~dholmes/jdk7-clone/webrev-7035109/ >>> >>> Failing test now passes. >>> >>> Due to the urgency this will get pushed directly into the TL PIT jdk >>> repo so that it will be paired with 7030063 and present in b138. >> There is always a bit of risk pushing AWT or other client area changes >> >> to the TL forest as probably very few of us run those tests. The >> update >> the map file looks good to me. >> >> -Alan. From neil.richards at ngmr.net Sun Apr 10 17:28:02 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Sun, 10 Apr 2011 18:28:02 +0100 Subject: Suspected regression: fix for 6735255 causes delay in GC of ZipFile InputStreams, increase in heap demand In-Reply-To: <4D9FD836.1070909@oracle.com> References: <1300916786.4515.107.camel@chalkhill> <4D922D68.2080202@oracle.com> <1301514810.24605.64.camel@chalkhill> <4D93930A.2000604@oracle.com> <1301676177.24605.165.camel@chalkhill> <4D962275.7010601@oracle.com> <4D965D14.6060504@oracle.com> <1301707718.14323.43.camel@chalkhill> <4D98FD10.4090608@oracle.com> <1302183023.27698.20.camel@chalkhill> <4D9E429F.9030200@oracle.com> <1302266193.17745.18.camel@chalkhill> <4D9FD836.1070909@oracle.com> Message-ID: <1302456482.18865.109.camel@chalkhill> On Fri, 2011-04-08 at 20:53 -0700, Xueming Shen wrote: > Regression test /test/java/util/zip/ZipFile/FinalizeInflater.java failed > with this fix. > > The possible solution I can think of now is to do nothing but simply > return the inflater back to the cache, but do an additional sanity > check when "check out" > > private Inflater getInflater() { > > synchronized (inflaters) { > int size = inflaters.size(); > while ((size = inflaters.size())> 0) { > Inflater inf = inflaters.remove(size - 1); > if (!inf.ended()) > return inf; > } > return new Inflater(true); > } > } > > > http://cr.openjdk.java.net/~sherman/7031076/webrev/ > > What do you think? have a better idea? Whilst checking on "check out" might hope to reduce the timing window, I fear that doing so will not entirely eliminate it. (The timing window is essentially between the point the inflater object is placed on the finalization queue for finalization and the point at which that finalization has actually occurred. In that window, if any implementation or user code can cause it to be added to the cache, it could also be retrieved from the cache prior to the point the Finalization thread gets round to calling Inflater.finalize()). Instead, in order to safely cache and reuse inflater objects in ZipFile, I believe it to be necessary for the ZipFile to prevent them from becoming eligible for finalization/GC (until a decision is made not to put them back in the inflater cache due to their having been explicitly ended). It can do this by holding references to the inflater objects that are in use by its input streams, as well as those in the cache (ie. those currently unused). (NB: Previously, the Inflater objects happened to be preserved in this way, due to the ZipFile keeping alive the InputStream objects, which have references to the inflater objects. Thus the challenge is to preserve the Inflater objects - so that they can be cached and reused - without hitting the heap by prolonging the life of the InputStream objects). ZipFile must also only return an inflater to the inflater cache at the point where its end() method can no longer be explicitly called (directly or indirectly) by the user - such as i done in the InflaterFinalization testscase. In other words, it's addition to the cache should only be considered once the input stream that was using it has been completely GC'd. Please see below another formulation of the suggested change which incorporates these features. It adapts the 'streams' map to hold references to the in-use inflater objects as values, and reverts to explicitly dealing with the cleanup of stale entries in the map so as to use that point to drive releaseInflater() with the stored value. (I have chosen to hold these values 'softly', so that they may be released by GC if they are not reused - by being given to the cache - in a timely manner. If the input stream is not explicitly closed, an inflater object may not be reset() until the call to releaseInflater() from clearStaleStreams() - ie. it may continue to hold onto its old buffer until then. As clearStaleStreams() is only driven when a new InputStream is requested, this may be retained for some time. By holding the inflater 'softly', the system can decide to release the inflater's resources by GC'ing it, if heap demand is high, or the system has not asked for new InputStreams from this ZipFile for a while). With releaseInflater() being driven from the cleanup of stale 'streams' entries, it no longer needs to be called from ZFIIS.close(), so, instead, only Inflater.reset() is called from there (providing the inflater object has not explicitly been ended) so that it releases the buffer it has been holding. This allows the synchronization to be simplified, as there's no longer a reason to synchronize on the inflater cache independently of that on the ZipFile itself. (I've also changed the inflater cache to use a Deque, which allows its code to be simplified and should be (marginally) more efficient, according to the API doc). Also, based on the previous observation that object's finalize() methods should concentrate on freeing off their own associated system resources, I've modified ZipFile's close() and finalize() methods such that they both call closeFile(), which deals with closing its system resources). I believe, with these changes, the handling of the caching & reuse of ZipFile's Inflater objects is handled in a safe manner, whilst still allowing its InputStreams to be GC'd in a timely manner. Please get back to me with any comments, questions or suggestions on this, Thanks, Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU # HG changeset patch # User Neil Richards , # Date 1300289208 0 # Branch zip-heap # Node ID c7ed122ae9e3354e99c53ca191b467ef9d9c97ff # Parent aa13e7702cd9d8aca9aa38f1227f966990866944 7031076: Retained ZipFile InputStreams increase heap demand Summary: Allow unreferenced ZipFile InputStreams to be finalized, GC'd Contributed-by: diff -r aa13e7702cd9 -r c7ed122ae9e3 src/share/classes/java/util/zip/ZipFile.java --- a/src/share/classes/java/util/zip/ZipFile.java Tue Mar 29 20:19:55 2011 -0700 +++ b/src/share/classes/java/util/zip/ZipFile.java Wed Mar 16 15:26:48 2011 +0000 @@ -30,11 +30,16 @@ import java.io.IOException; import java.io.EOFException; import java.io.File; +import java.lang.ref.ReferenceQueue; +import java.lang.ref.SoftReference; +import java.lang.ref.WeakReference; import java.nio.charset.Charset; -import java.util.Vector; +import java.util.ArrayDeque; +import java.util.Deque; import java.util.Enumeration; -import java.util.Set; -import java.util.HashSet; +import java.util.HashMap; +import java.util.Iterator; +import java.util.Map; import java.util.NoSuchElementException; import java.security.AccessController; import sun.security.action.GetPropertyAction; @@ -314,8 +319,21 @@ // freeEntry releases the C jzentry struct. private static native void freeEntry(long jzfile, long jzentry); - // the outstanding inputstreams that need to be closed. - private Set streams = new HashSet<>(); + // the outstanding inputstreams that need to be closed, + // mapped to the inflater objects they use. + private final Map, SoftReference> + streams = new HashMap<>(); + private final ReferenceQueue staleStreamQueue = + new ReferenceQueue<>(); + private static final SoftReference NULL_INFLATER_REF = + new SoftReference<>(null); + + private synchronized void clearStaleStreams() { + Object staleStream; + while (null != (staleStream = staleStreamQueue.poll())) { + releaseInflater(streams.remove(staleStream).get()); + } + } /** * Returns an input stream for reading the contents of the specified @@ -339,6 +357,7 @@ ZipFileInputStream in = null; synchronized (this) { ensureOpen(); + clearStaleStreams(); if (!zc.isUTF8() && (entry.flag & EFS) != 0) { jzentry = getEntry(jzfile, zc.getBytesUTF8(entry.name), false); } else { @@ -351,51 +370,21 @@ switch (getEntryMethod(jzentry)) { case STORED: - streams.add(in); + streams.put( + new WeakReference(in, staleStreamQueue), + NULL_INFLATER_REF); return in; case DEFLATED: - final ZipFileInputStream zfin = in; // MORE: Compute good size for inflater stream: long size = getEntrySize(jzentry) + 2; // Inflater likes a bit of slack if (size > 65536) size = 8192; if (size <= 0) size = 4096; - InputStream is = new InflaterInputStream(zfin, getInflater(), (int)size) { - private boolean isClosed = false; - - public void close() throws IOException { - if (!isClosed) { - super.close(); - releaseInflater(inf); - isClosed = true; - } - } - // Override fill() method to provide an extra "dummy" byte - // at the end of the input stream. This is required when - // using the "nowrap" Inflater option. - protected void fill() throws IOException { - if (eof) { - throw new EOFException( - "Unexpected end of ZLIB input stream"); - } - len = this.in.read(buf, 0, buf.length); - if (len == -1) { - buf[0] = 0; - len = 1; - eof = true; - } - inf.setInput(buf, 0, len); - } - private boolean eof; - - public int available() throws IOException { - if (isClosed) - return 0; - long avail = zfin.size() - inf.getBytesWritten(); - return avail > (long) Integer.MAX_VALUE ? - Integer.MAX_VALUE : (int) avail; - } - }; - streams.add(is); + Inflater inf = getInflater(); + InputStream is = + new ZipFileInflaterInputStream(in, inf, (int)size); + streams.put( + new WeakReference(is, staleStreamQueue), + new SoftReference(inf)); return is; default: throw new ZipException("invalid compression method"); @@ -403,36 +392,77 @@ } } + private class ZipFileInflaterInputStream extends InflaterInputStream { + private boolean isClosed = false; + private boolean eof = false; + private final ZipFileInputStream zfin; + + ZipFileInflaterInputStream(ZipFileInputStream zfin, Inflater inf, + int size) { + super(zfin, inf, size); + this.zfin = zfin; + } + + public void close() throws IOException { + if (!isClosed) { + super.close(); + if (false == inf.ended()) { + inf.reset(); + } + isClosed = true; + } + } + // Override fill() method to provide an extra "dummy" byte + // at the end of the input stream. This is required when + // using the "nowrap" Inflater option. + protected void fill() throws IOException { + if (eof) { + throw new EOFException("Unexpected end of ZLIB input stream"); + } + len = in.read(buf, 0, buf.length); + if (len == -1) { + buf[0] = 0; + len = 1; + eof = true; + } + inf.setInput(buf, 0, len); + } + + public int available() throws IOException { + if (isClosed) + return 0; + long avail = zfin.size() - inf.getBytesWritten(); + return (avail > (long) Integer.MAX_VALUE ? + Integer.MAX_VALUE : (int) avail); + } + } + /* * Gets an inflater from the list of available inflaters or allocates * a new one. */ - private Inflater getInflater() { - synchronized (inflaters) { - int size = inflaters.size(); - if (size > 0) { - Inflater inf = (Inflater)inflaters.remove(size - 1); - return inf; - } else { - return new Inflater(true); + private synchronized Inflater getInflater() { + Inflater inf; + while (null != (inf = inflaterCache.poll())) { + if (false == inf.ended()) { + return inf; + } } - } + return new Inflater(true); } /* * Releases the specified inflater to the list of available inflaters. */ - private void releaseInflater(Inflater inf) { - synchronized (inflaters) { - if (inf.ended()) - return; + private synchronized void releaseInflater(Inflater inf) { + if ((null != inf) && (false == inf.ended())) { inf.reset(); - inflaters.add(inf); + inflaterCache.add(inf); } } // List of available Inflater objects for decompression - private Vector inflaters = new Vector(); + private Deque inflaterCache = new ArrayDeque<>(); /** * Returns the path name of the ZIP file. @@ -539,40 +569,48 @@ * * @throws IOException if an I/O error has occurred */ - public void close() throws IOException { - synchronized (this) { - closeRequested = true; + public synchronized void close() throws IOException { + closeRequested = true; - if (streams.size() !=0) { - Set copy = streams; - streams = new HashSet<>(); - for (InputStream is: copy) - is.close(); + // Close streams, release their inflaters + Iterator, SoftReference>> + streamEntryIterator = streams.entrySet().iterator(); + while (streamEntryIterator.hasNext()) { + Map.Entry, SoftReference> + streamEntry = streamEntryIterator.next(); + InputStream is = streamEntry.getKey().get(); + if (null != is) { + is.close(); } + Inflater inf = streamEntry.getValue().get(); + if (null != inf) { + inf.end(); + } + streamEntryIterator.remove(); + } - if (jzfile != 0) { - // Close the zip file - long zf = this.jzfile; - jzfile = 0; + // Release cached inflaters + Inflater inf; + while (null != (inf = inflaterCache.poll())) { + inf.end(); + } - close(zf); + closeFile(); + } - // Release inflaters - synchronized (inflaters) { - int size = inflaters.size(); - for (int i = 0; i < size; i++) { - Inflater inf = (Inflater)inflaters.get(i); - inf.end(); - } - } - } + private synchronized void closeFile() { + if (jzfile != 0) { + // Close the zip file + long zf = this.jzfile; + jzfile = 0; + + close(zf); } } - /** - * Ensures that the close method of this ZIP file is - * called when there are no more references to it. + * Ensures that the system resources held by this ZipFile object are + * released when there are no more references to it. * *

* Since the time when GC would invoke this method is undetermined, @@ -585,7 +623,7 @@ * @see java.util.zip.ZipFile#close() */ protected void finalize() throws IOException { - close(); + closeFile(); } private static native void close(long jzfile); @@ -684,9 +722,12 @@ freeEntry(ZipFile.this.jzfile, jzentry); jzentry = 0; } - streams.remove(this); } } + + protected void finalize() { + close(); + } } diff -r aa13e7702cd9 -r c7ed122ae9e3 test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java Wed Mar 16 15:26:48 2011 +0000 @@ -0,0 +1,148 @@ +/* + * Copyright (c) 2011 Oracle and/or its affiliates. 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 Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/* + * Portions Copyright (c) 2011 IBM Corporation + */ + +/* + * @test + * @bug 7031076 + * @summary Allow stale InputStreams from ZipFiles to be GC'd + * @author Neil Richards , + */ +import java.lang.ref.ReferenceQueue; +import java.lang.ref.WeakReference; +import java.io.File; +import java.io.FileOutputStream; +import java.io.InputStream; +import java.util.Enumeration; +import java.util.HashSet; +import java.util.Random; +import java.util.Set; +import java.util.zip.ZipEntry; +import java.util.zip.ZipFile; +import java.util.zip.ZipOutputStream; + +public class ClearStaleZipFileInputStreams { + private static final int ZIP_ENTRY_NUM = 5; + + private static final byte[][] data; + + static { + data = new byte[ZIP_ENTRY_NUM][]; + Random r = new Random(); + for (int i = 0; i < ZIP_ENTRY_NUM; i++) { + data[i] = new byte[1000]; + r.nextBytes(data[i]); + } + } + + private static File createTestFile(int compression) throws Exception { + File tempZipFile = + File.createTempFile("test-data" + compression, ".zip"); + tempZipFile.deleteOnExit(); + + ZipOutputStream zos = + new ZipOutputStream(new FileOutputStream(tempZipFile)); + zos.setLevel(compression); + + try { + for (int i = 0; i < ZIP_ENTRY_NUM; i++) { + String text = "Entry" + i; + ZipEntry entry = new ZipEntry(text); + zos.putNextEntry(entry); + try { + zos.write(data[i], 0, data[i].length); + } finally { + zos.closeEntry(); + } + } + } finally { + zos.close(); + } + + return tempZipFile; + } + + private static void startGcInducingThread(final int sleepMillis) { + final Thread gcInducingThread = new Thread() { + public void run() { + while (true) { + System.gc(); + try { + Thread.sleep(sleepMillis); + } catch (InterruptedException e) { } + } + } + }; + + gcInducingThread.setDaemon(true); + gcInducingThread.start(); + } + + public static void main(String[] args) throws Exception { + startGcInducingThread(500); + runTest(ZipOutputStream.DEFLATED); + runTest(ZipOutputStream.STORED); + } + + private static void runTest(int compression) throws Exception { + ReferenceQueue rq = new ReferenceQueue<>(); + + System.out.println("Testing with a zip file with compression level = " + + compression); + File f = createTestFile(compression); + try { + ZipFile zf = new ZipFile(f); + try { + Set refSet = createTransientInputStreams(zf, rq); + + System.out.println("Waiting for 'stale' input streams from ZipFile to be GC'd ..."); + System.out.println("(The test will hang on failure)"); + while (false == refSet.isEmpty()) { + refSet.remove(rq.remove()); + } + System.out.println("Test PASSED."); + System.out.println(); + } finally { + zf.close(); + } + } finally { + f.delete(); + } + } + + private static Set createTransientInputStreams(ZipFile zf, + ReferenceQueue rq) throws Exception { + Enumeration zfe = zf.entries(); + Set refSet = new HashSet<>(); + + while (zfe.hasMoreElements()) { + InputStream is = zf.getInputStream(zfe.nextElement()); + refSet.add(new WeakReference(is, rq)); + } + + return refSet; + } +} From David.Holmes at oracle.com Sun Apr 10 22:22:46 2011 From: David.Holmes at oracle.com (David Holmes) Date: Mon, 11 Apr 2011 08:22:46 +1000 Subject: Urgent Request for review: 7035109 Regression: awt SplashScreen/test18.sh fails - missing mapfile entry In-Reply-To: <4DA1DD3F.2080109@oracle.com> References: <4DA1DD3F.2080109@oracle.com> Message-ID: <4DA22DB6.5010504@oracle.com> Phil Race said the following on 04/11/11 02:39: > I think that there can be times when something is extremely cross-area > and that makes it more of a pain if it can't easily be divided up. The embedded changes were very cross-area and we would have had to put back through three different team repos, meaning we wouldn't actually get a full working copy until everything propagated through the master. Hence everything was pushed through TL/jdk (with approval from build and AWT folk) > But I completely agree that running the right tests is a vital part of > making > sure there are no problems. I don't know if that would have happened any > faster in this case. Yes the testing was lacking - mea culpa. This was the last piece to push through and the AWT folk insisted that we re-work parts of it compared to how it was done in 6u23. The change that introduced the native method wasn't specifically tested. > But so is the review. Code changes that cross areas should also be > posted for > review by the relevant teams. Some times that might save pain down > the line. So if you change awt code, send the review to the AWT team (etc). > I expect core libs would like to know if I decided to change something > in java.util :-) Just so there's no misunderstanding these changes were all approved by AWT. All of the SE Embedded integration work was done in full cooperation with the TL, Build and AWT folk and I've immensely grateful for their assistance in getting this all pushed through. This fix has been pushed into the PIT respin for b138. Cheers, David > > -phil. > > > On 4/9/2011 8:08 AM, Kumar Srinivasan wrote: >> Approved!. I agree with Alan if a change is to be made in >> a component, it is best that it is pushed to that component's >> forest/repo, where all the necessary/appropriate tests will be >> performed on a nightly basis. >> >> Kumar >> >> >> ----- Alan.Bateman at oracle.com wrote: >> >>> From: Alan.Bateman at oracle.com >>> To: David.Holmes at oracle.com >>> Cc: awt-dev at openjdk.java.net, core-libs-dev at openjdk.java.net >>> Sent: Saturday, April 9, 2011 1:59:17 AM GMT -08:00 US/Canada Pacific >>> Subject: Re: Urgent Request for review: 7035109 Regression: awt >>> SplashScreen/test18.sh fails - missing mapfile entry >>> >>> David Holmes wrote: >>>> Very simple review - the mapfile was missing an entry for a new >>> native >>>> method added in 7030063 and caused an UnsatisfiedLinkError >>>> >>>> http://cr.openjdk.java.net/~dholmes/jdk7-clone/webrev-7035109/ >>>> >>>> Failing test now passes. >>>> >>>> Due to the urgency this will get pushed directly into the TL PIT jdk >>>> repo so that it will be paired with 7030063 and present in b138. >>> There is always a bit of risk pushing AWT or other client area changes >>> >>> to the TL forest as probably very few of us run those tests. The >>> update >>> the map file looks good to me. >>> >>> -Alan. > From philip.race at oracle.com Mon Apr 11 01:54:49 2011 From: philip.race at oracle.com (Phil Race) Date: Sun, 10 Apr 2011 18:54:49 -0700 Subject: Urgent Request for review: 7035109 Regression: awt SplashScreen/test18.sh fails - missing mapfile entry In-Reply-To: <4DA22DB6.5010504@oracle.com> References: <4DA1DD3F.2080109@oracle.com> <4DA22DB6.5010504@oracle.com> Message-ID: <4DA25F69.6070800@oracle.com> On 4/10/2011 3:22 PM, David Holmes wrote: > > Just so there's no misunderstanding these changes were all approved by > AWT. > > All of the SE Embedded integration work was done in full cooperation > with the TL, Build and AWT folk and I've immensely grateful for their > assistance in getting this all pushed through. OK, that's good to know. Think of my comment as a note to the general population :-), that might help folks. -phil. From weijun.wang at oracle.com Mon Apr 11 02:24:14 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Mon, 11 Apr 2011 02:24:14 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20110411022442.343E547989@hg.openjdk.java.net> Changeset: 4de90f390a48 Author: weijun Date: 2011-04-11 10:22 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4de90f390a48 7012160: read SF file in signed jar in streaming mode Reviewed-by: mullan ! src/share/classes/java/util/jar/JarFile.java ! src/share/classes/java/util/jar/JarInputStream.java ! src/share/classes/java/util/jar/JarVerifier.java ! src/share/classes/sun/security/pkcs/PKCS7.java ! src/share/classes/sun/security/pkcs/SignerInfo.java ! src/share/classes/sun/security/util/ManifestEntryVerifier.java + src/share/classes/sun/security/util/SignatureFileManifest.java ! src/share/classes/sun/security/util/SignatureFileVerifier.java Changeset: 50f77a77ffcf Author: weijun Date: 2011-04-11 10:22 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/50f77a77ffcf 7030180: AES 128/256 decrypt exception Reviewed-by: valeriep ! src/share/classes/sun/security/jgss/krb5/InitSecContextToken.java ! src/share/classes/sun/security/jgss/krb5/InitialToken.java + test/sun/security/krb5/KrbCredSubKey.java From xueming.shen at oracle.com Mon Apr 11 06:28:34 2011 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Mon, 11 Apr 2011 06:28:34 +0000 Subject: hg: jdk7/tl/jdk: 7033561: Missing Unicode Script aliases Message-ID: <20110411062851.D2B5747992@hg.openjdk.java.net> Changeset: c8f22fc4aa00 Author: sherman Date: 2011-04-10 23:33 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c8f22fc4aa00 7033561: Missing Unicode Script aliases Summary: added 6.0 aliases Reviewed-by: okutsu, peytoia, alanb ! src/share/classes/java/lang/Character.java ! test/java/lang/Character/CheckScript.java + test/java/lang/Character/PropertyValueAliases.txt From neil.richards at ngmr.net Mon Apr 11 12:15:16 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Mon, 11 Apr 2011 13:15:16 +0100 Subject: Suspected regression: fix for 6735255 causes delay in GC of ZipFile InputStreams, increase in heap demand In-Reply-To: <1302456482.18865.109.camel@chalkhill> References: <1300916786.4515.107.camel@chalkhill> <4D922D68.2080202@oracle.com> <1301514810.24605.64.camel@chalkhill> <4D93930A.2000604@oracle.com> <1301676177.24605.165.camel@chalkhill> <4D962275.7010601@oracle.com> <4D965D14.6060504@oracle.com> <1301707718.14323.43.camel@chalkhill> <4D98FD10.4090608@oracle.com> <1302183023.27698.20.camel@chalkhill> <4D9E429F.9030200@oracle.com> <1302266193.17745.18.camel@chalkhill> <4D9FD836.1070909@oracle.com> <1302456482.18865.109.camel@chalkhill> Message-ID: <1302524116.15253.25.camel@chalkhill> On Sun, 2011-04-10 at 18:28 +0100, Neil Richards wrote: > With releaseInflater() being driven from the cleanup of stale 'streams' > entries, it no longer needs to be called from ZFIIS.close(), so, > instead, only Inflater.reset() is called from there (providing the > inflater object has not explicitly been ended) so that it releases the > buffer it has been holding. Actually, I have a slight change of heart on this aspect. Because close() may be driven from a finalize() method in user code (as is done in the InflaterFinalizer test case), I believe it is possible (albeit unlikely) for an inflater object to have been reclaimed from 'streams' (by a call to clearStaleStreams()), put into the inflater cache, retrieved from there (by another thread creating an input stream) and having started to be used by that other stream at the point at which the code in close() is run. (This is because weak references will be cleared, and *may* be queued on the ReferenceQueue, prior to finalization). Because of this, it's not actually entirely safe now to call inf.reset() from ZFIIS.close(). Instead, I have added additional calls to clearStaleStreams() from the finalize() methods of both InputStream implementations in the latest (hopefully in the meaning of "last") changeset included below. As always, please get back to me with any comments, questions or suggestions on this, Thanks, Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU # HG changeset patch # User Neil Richards , # Date 1300289208 0 # Branch zip-heap # Node ID b66c974bcfa957281e69a63cd4019a12c13cacae # Parent aa13e7702cd9d8aca9aa38f1227f966990866944 7031076: Retained ZipFile InputStreams increase heap demand Summary: Allow unreferenced ZipFile InputStreams to be finalized, GC'd Contributed-by: diff -r aa13e7702cd9 -r b66c974bcfa9 src/share/classes/java/util/zip/ZipFile.java --- a/src/share/classes/java/util/zip/ZipFile.java Tue Mar 29 20:19:55 2011 -0700 +++ b/src/share/classes/java/util/zip/ZipFile.java Wed Mar 16 15:26:48 2011 +0000 @@ -30,11 +30,16 @@ import java.io.IOException; import java.io.EOFException; import java.io.File; +import java.lang.ref.ReferenceQueue; +import java.lang.ref.SoftReference; +import java.lang.ref.WeakReference; import java.nio.charset.Charset; -import java.util.Vector; +import java.util.ArrayDeque; +import java.util.Deque; import java.util.Enumeration; -import java.util.Set; -import java.util.HashSet; +import java.util.HashMap; +import java.util.Iterator; +import java.util.Map; import java.util.NoSuchElementException; import java.security.AccessController; import sun.security.action.GetPropertyAction; @@ -314,8 +319,21 @@ // freeEntry releases the C jzentry struct. private static native void freeEntry(long jzfile, long jzentry); - // the outstanding inputstreams that need to be closed. - private Set streams = new HashSet<>(); + // the outstanding inputstreams that need to be closed, + // mapped to the inflater objects they use. + private final Map, SoftReference> + streams = new HashMap<>(); + private final ReferenceQueue staleStreamQueue = + new ReferenceQueue<>(); + private static final SoftReference NULL_INFLATER_REF = + new SoftReference<>(null); + + private synchronized void clearStaleStreams() { + Object staleStream; + while (null != (staleStream = staleStreamQueue.poll())) { + releaseInflater(streams.remove(staleStream).get()); + } + } /** * Returns an input stream for reading the contents of the specified @@ -339,6 +357,7 @@ ZipFileInputStream in = null; synchronized (this) { ensureOpen(); + clearStaleStreams(); if (!zc.isUTF8() && (entry.flag & EFS) != 0) { jzentry = getEntry(jzfile, zc.getBytesUTF8(entry.name), false); } else { @@ -351,51 +370,21 @@ switch (getEntryMethod(jzentry)) { case STORED: - streams.add(in); + streams.put( + new WeakReference(in, staleStreamQueue), + NULL_INFLATER_REF); return in; case DEFLATED: - final ZipFileInputStream zfin = in; // MORE: Compute good size for inflater stream: long size = getEntrySize(jzentry) + 2; // Inflater likes a bit of slack if (size > 65536) size = 8192; if (size <= 0) size = 4096; - InputStream is = new InflaterInputStream(zfin, getInflater(), (int)size) { - private boolean isClosed = false; - - public void close() throws IOException { - if (!isClosed) { - super.close(); - releaseInflater(inf); - isClosed = true; - } - } - // Override fill() method to provide an extra "dummy" byte - // at the end of the input stream. This is required when - // using the "nowrap" Inflater option. - protected void fill() throws IOException { - if (eof) { - throw new EOFException( - "Unexpected end of ZLIB input stream"); - } - len = this.in.read(buf, 0, buf.length); - if (len == -1) { - buf[0] = 0; - len = 1; - eof = true; - } - inf.setInput(buf, 0, len); - } - private boolean eof; - - public int available() throws IOException { - if (isClosed) - return 0; - long avail = zfin.size() - inf.getBytesWritten(); - return avail > (long) Integer.MAX_VALUE ? - Integer.MAX_VALUE : (int) avail; - } - }; - streams.add(is); + Inflater inf = getInflater(); + InputStream is = + new ZipFileInflaterInputStream(in, inf, (int)size); + streams.put( + new WeakReference(is, staleStreamQueue), + new SoftReference(inf)); return is; default: throw new ZipException("invalid compression method"); @@ -403,36 +392,78 @@ } } + private class ZipFileInflaterInputStream extends InflaterInputStream { + private boolean isClosed = false; + private boolean eof = false; + private final ZipFileInputStream zfin; + + ZipFileInflaterInputStream(ZipFileInputStream zfin, Inflater inf, + int size) { + super(zfin, inf, size); + this.zfin = zfin; + } + + public void close() throws IOException { + if (!isClosed) { + super.close(); + isClosed = true; + } + } + // Override fill() method to provide an extra "dummy" byte + // at the end of the input stream. This is required when + // using the "nowrap" Inflater option. + protected void fill() throws IOException { + if (eof) { + throw new EOFException("Unexpected end of ZLIB input stream"); + } + len = in.read(buf, 0, buf.length); + if (len == -1) { + buf[0] = 0; + len = 1; + eof = true; + } + inf.setInput(buf, 0, len); + } + + public int available() throws IOException { + if (isClosed) + return 0; + long avail = zfin.size() - inf.getBytesWritten(); + return (avail > (long) Integer.MAX_VALUE ? + Integer.MAX_VALUE : (int) avail); + } + + protected void finalize() { + clearStaleStreams(); + } + } + /* * Gets an inflater from the list of available inflaters or allocates * a new one. */ - private Inflater getInflater() { - synchronized (inflaters) { - int size = inflaters.size(); - if (size > 0) { - Inflater inf = (Inflater)inflaters.remove(size - 1); + private synchronized Inflater getInflater() { + Inflater inf; + while (null != (inf = inflaterCache.poll())) { + if (false == inf.ended()) { return inf; - } else { - return new Inflater(true); } } + return new Inflater(true); } /* * Releases the specified inflater to the list of available inflaters. */ - private void releaseInflater(Inflater inf) { - synchronized (inflaters) { - if (inf.ended()) - return; + private synchronized void releaseInflater(Inflater inf) { + if ((null != inf) && (false == inf.ended())) { inf.reset(); - inflaters.add(inf); + inflaterCache.add(inf); } } // List of available Inflater objects for decompression - private Vector inflaters = new Vector(); + private Deque inflaterCache = new ArrayDeque<>(); /** * Returns the path name of the ZIP file. @@ -539,40 +570,48 @@ * * @throws IOException if an I/O error has occurred */ - public void close() throws IOException { - synchronized (this) { - closeRequested = true; + public synchronized void close() throws IOException { + closeRequested = true; - if (streams.size() !=0) { - Set copy = streams; - streams = new HashSet<>(); - for (InputStream is: copy) - is.close(); + // Close streams, release their inflaters + Iterator, SoftReference>> + streamEntryIterator = streams.entrySet().iterator(); + while (streamEntryIterator.hasNext()) { + Map.Entry, SoftReference> + streamEntry = streamEntryIterator.next(); + InputStream is = streamEntry.getKey().get(); + if (null != is) { + is.close(); } + Inflater inf = streamEntry.getValue().get(); + if (null != inf) { + inf.end(); + } + streamEntryIterator.remove(); + } - if (jzfile != 0) { - // Close the zip file - long zf = this.jzfile; - jzfile = 0; + // Release cached inflaters + Inflater inf; + while (null != (inf = inflaterCache.poll())) { + inf.end(); + } - close(zf); + closeFile(); + } - // Release inflaters - synchronized (inflaters) { - int size = inflaters.size(); - for (int i = 0; i < size; i++) { - Inflater inf = (Inflater)inflaters.get(i); - inf.end(); - } - } - } + private synchronized void closeFile() { + if (jzfile != 0) { + // Close the zip file + long zf = this.jzfile; + jzfile = 0; + + close(zf); } } - /** - * Ensures that the close method of this ZIP file is - * called when there are no more references to it. + * Ensures that the system resources held by this ZipFile object are + * released when there are no more references to it. * *

* Since the time when GC would invoke this method is undetermined, @@ -585,7 +624,7 @@ * @see java.util.zip.ZipFile#close() */ protected void finalize() throws IOException { - close(); + closeFile(); } private static native void close(long jzfile); @@ -684,9 +723,13 @@ freeEntry(ZipFile.this.jzfile, jzentry); jzentry = 0; } - streams.remove(this); } } + + protected void finalize() { + close(); + clearStaleStreams(); + } } diff -r aa13e7702cd9 -r b66c974bcfa9 test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java Wed Mar 16 15:26:48 2011 +0000 @@ -0,0 +1,148 @@ +/* + * Copyright (c) 2011 Oracle and/or its affiliates. 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 Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/* + * Portions Copyright (c) 2011 IBM Corporation + */ + +/* + * @test + * @bug 7031076 + * @summary Allow stale InputStreams from ZipFiles to be GC'd + * @author Neil Richards , + */ +import java.lang.ref.ReferenceQueue; +import java.lang.ref.WeakReference; +import java.io.File; +import java.io.FileOutputStream; +import java.io.InputStream; +import java.util.Enumeration; +import java.util.HashSet; +import java.util.Random; +import java.util.Set; +import java.util.zip.ZipEntry; +import java.util.zip.ZipFile; +import java.util.zip.ZipOutputStream; + +public class ClearStaleZipFileInputStreams { + private static final int ZIP_ENTRY_NUM = 5; + + private static final byte[][] data; + + static { + data = new byte[ZIP_ENTRY_NUM][]; + Random r = new Random(); + for (int i = 0; i < ZIP_ENTRY_NUM; i++) { + data[i] = new byte[1000]; + r.nextBytes(data[i]); + } + } + + private static File createTestFile(int compression) throws Exception { + File tempZipFile = + File.createTempFile("test-data" + compression, ".zip"); + tempZipFile.deleteOnExit(); + + ZipOutputStream zos = + new ZipOutputStream(new FileOutputStream(tempZipFile)); + zos.setLevel(compression); + + try { + for (int i = 0; i < ZIP_ENTRY_NUM; i++) { + String text = "Entry" + i; + ZipEntry entry = new ZipEntry(text); + zos.putNextEntry(entry); + try { + zos.write(data[i], 0, data[i].length); + } finally { + zos.closeEntry(); + } + } + } finally { + zos.close(); + } + + return tempZipFile; + } + + private static void startGcInducingThread(final int sleepMillis) { + final Thread gcInducingThread = new Thread() { + public void run() { + while (true) { + System.gc(); + try { + Thread.sleep(sleepMillis); + } catch (InterruptedException e) { } + } + } + }; + + gcInducingThread.setDaemon(true); + gcInducingThread.start(); + } + + public static void main(String[] args) throws Exception { + startGcInducingThread(500); + runTest(ZipOutputStream.DEFLATED); + runTest(ZipOutputStream.STORED); + } + + private static void runTest(int compression) throws Exception { + ReferenceQueue rq = new ReferenceQueue<>(); + + System.out.println("Testing with a zip file with compression level = " + + compression); + File f = createTestFile(compression); + try { + ZipFile zf = new ZipFile(f); + try { + Set refSet = createTransientInputStreams(zf, rq); + + System.out.println("Waiting for 'stale' input streams from ZipFile to be GC'd ..."); + System.out.println("(The test will hang on failure)"); + while (false == refSet.isEmpty()) { + refSet.remove(rq.remove()); + } + System.out.println("Test PASSED."); + System.out.println(); + } finally { + zf.close(); + } + } finally { + f.delete(); + } + } + + private static Set createTransientInputStreams(ZipFile zf, + ReferenceQueue rq) throws Exception { + Enumeration zfe = zf.entries(); + Set refSet = new HashSet<>(); + + while (zfe.hasMoreElements()) { + InputStream is = zf.getInputStream(zfe.nextElement()); + refSet.add(new WeakReference(is, rq)); + } + + return refSet; + } +} From alan.bateman at oracle.com Mon Apr 11 12:13:17 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 11 Apr 2011 12:13:17 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20110411121350.7C0F94799F@hg.openjdk.java.net> Changeset: dc74b14a8753 Author: alanb Date: 2011-04-10 19:45 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dc74b14a8753 7034532: (fs) AssertionError when working directory is UNC Reviewed-by: forax, mduigou ! src/windows/classes/sun/nio/fs/WindowsFileSystem.java Changeset: 36e467e1e8b0 Author: alanb Date: 2011-04-11 12:52 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/36e467e1e8b0 Merge From Alan.Bateman at oracle.com Mon Apr 11 14:46:43 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 11 Apr 2011 15:46:43 +0100 Subject: advice & review requested for 6896297, race condition in rmid causing JCK failure In-Reply-To: <4D9E3867.7030004@oracle.com> References: <4D9E3867.7030004@oracle.com> Message-ID: <4DA31453.2020408@oracle.com> Stuart Marks wrote: > Hi Core-Libs developers, > > I'd like to solicit some advice and discussion about this bug and a > potential fix I'm cooking for it. Here is the bug report; it contains > details about the problem and my analysis of it: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6896297 > > and here's a webrev of the fix I'm working on: > > http://cr.openjdk.java.net/~smarks/reviews/6896297/webrev.0/ I haven't worked on RMI and so I don't have a good insight into the implementation. I think (and Peter Jones can correct me) that changing the serialized form would just inhibit recovery of rmid from an existing log file. As David said, you could switch to CHM and implement readObject/writeObject to serialize/deserialize in the current form. That said, I looked your webrev and the changes look reasonable to me. I don't see anything obviously wrong with moving the unregisterGroup out of the synchronized block. -Alan. From lance.andersen at oracle.com Mon Apr 11 17:48:24 2011 From: lance.andersen at oracle.com (Lance Andersen - Oracle) Date: Mon, 11 Apr 2011 13:48:24 -0400 Subject: Review request for removal of unchecked lint warnings in javax.sql.rowset, CR 7035615 Message-ID: Hi all, This is a request for a review of the changes to remove the lint warnings for javax.sql.rowset. The diff is at http://cr.openjdk.java.net/~lancea/7035615 Thank you. Regards, Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From Alan.Bateman at oracle.com Mon Apr 11 18:19:47 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 11 Apr 2011 19:19:47 +0100 Subject: Review request for removal of unchecked lint warnings in javax.sql.rowset, CR 7035615 In-Reply-To: References: Message-ID: <4DA34643.1040303@oracle.com> Lance Andersen - Oracle wrote: > Hi all, > > This is a request for a review of the changes to remove the lint warnings for javax.sql.rowset. The diff is at http://cr.openjdk.java.net/~lancea/7035615 > In RowSetMetaDataImpl.wrap it might be better to test with iface.isInstance(this)) rather than catching the CCE? At L937 it might be good to put the method declaration onto its own line (I assume a newline was gobbled up at some point). In BaseRowSet.java I notice the constants near the top aren't indented, might be worth fixing that "while you are in the area". Minor inconsistency but in the new type parameters you've got a space between the types in two places, and no space between them in the other place. Otherwise the changes look okay to me. -Alan. PS: javac was updated recently to emit warnings for unreachable catch clauses and one place that generates this warning is src/share/classes/com/sun/rowset/CachedRowSetImpl.java:947. It would be great to get that one fixed while you are fixing the other warnings. From joe.darcy at oracle.com Mon Apr 11 18:28:58 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Mon, 11 Apr 2011 11:28:58 -0700 Subject: Review request for removal of unchecked lint warnings in javax.sql.rowset, CR 7035615 In-Reply-To: References: Message-ID: <4DA3486A.9030603@oracle.com> Hi Lance. The generification looks fine. Separately I'd recommend considering replacing Vector with ArrayList and Hashtable with HashMap. Cheers, -Joe On 4/11/2011 10:48 AM, Lance Andersen - Oracle wrote: > Hi all, > > This is a request for a review of the changes to remove the lint warnings for javax.sql.rowset. The diff is at http://cr.openjdk.java.net/~lancea/7035615 > > Thank you. > > Regards, > > Lance > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > From lance.andersen at oracle.com Mon Apr 11 18:31:19 2011 From: lance.andersen at oracle.com (Lance Andersen - Oracle) Date: Mon, 11 Apr 2011 14:31:19 -0400 Subject: Review request for removal of unchecked lint warnings in javax.sql.rowset, CR 7035615 In-Reply-To: <4DA34643.1040303@oracle.com> References: <4DA34643.1040303@oracle.com> Message-ID: <0CCA292D-8061-4A11-9B22-EA403CDAD014@oracle.com> Hi Alan, thank you for the feedback. On Apr 11, 2011, at 2:19 PM, Alan Bateman wrote: > Lance Andersen - Oracle wrote: >> Hi all, >> >> This is a request for a review of the changes to remove the lint warnings for javax.sql.rowset. The diff is at http://cr.openjdk.java.net/~lancea/7035615 >> > In RowSetMetaDataImpl.wrap it might be better to test with iface.isInstance(this)) rather than catching the CCE? I thought about that as well and am happy to make that change > At L937 it might be good to put the method declaration onto its own line (I assume a newline was gobbled up at some point). will fix looks like that has been that way since day 1. > > In BaseRowSet.java I notice the constants near the top aren't indented, might be worth fixing that "while you are in the area". Minor inconsistency but in the new type parameters you've got a space between the types in two places, and no space between them in the other place. I will take care of that. > > Otherwise the changes look okay to me. > > -Alan. > > PS: javac was updated recently to emit warnings for unreachable catch clauses and one place that generates this warning is src/share/classes/com/sun/rowset/CachedRowSetImpl.java:947. It would be great to get that one fixed while you are fixing the other warnings. If you are OK with do it as part of this change, happy to change. Regards Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From Alan.Bateman at oracle.com Mon Apr 11 18:35:11 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 11 Apr 2011 19:35:11 +0100 Subject: Review request for removal of unchecked lint warnings in javax.sql.rowset, CR 7035615 In-Reply-To: <4DA3486A.9030603@oracle.com> References: <4DA3486A.9030603@oracle.com> Message-ID: <4DA349DF.7090209@oracle.com> joe.darcy at oracle.com wrote: > Hi Lance. > > The generification looks fine. Separately I'd recommend considering > replacing Vector with ArrayList and Hashtable with HashMap. I was thinking this too but the class is Serializable so it would require implementing read/writeObject to keep the serialized form. -Alan. From lance.andersen at oracle.com Mon Apr 11 18:38:19 2011 From: lance.andersen at oracle.com (Lance Andersen - Oracle) Date: Mon, 11 Apr 2011 14:38:19 -0400 Subject: Review request for removal of unchecked lint warnings in javax.sql.rowset, CR 7035615 In-Reply-To: <4DA349DF.7090209@oracle.com> References: <4DA3486A.9030603@oracle.com> <4DA349DF.7090209@oracle.com> Message-ID: <27BA3B2C-7A6D-4707-9C16-BD3592B25B23@oracle.com> Hi Joe, Alan, Thank you for your feedback Joe. On Apr 11, 2011, at 2:35 PM, Alan Bateman wrote: > joe.darcy at oracle.com wrote: >> Hi Lance. >> >> The generification looks fine. Thank you Joe >> Separately I'd recommend considering replacing Vector with ArrayList and Hashtable with HashMap. > I was thinking this too but the class is Serializable so it would require implementing read/writeObject to keep the serialized form. I would prefer to not do that at this part of this change. I will look to incorporate his change as part of the additional clean up I know want to do. Regards, Lance > > -Alan. Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From Alan.Bateman at oracle.com Mon Apr 11 18:48:49 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 11 Apr 2011 19:48:49 +0100 Subject: Review request for removal of unchecked lint warnings in javax.sql.rowset, CR 7035615 In-Reply-To: <0CCA292D-8061-4A11-9B22-EA403CDAD014@oracle.com> References: <4DA34643.1040303@oracle.com> <0CCA292D-8061-4A11-9B22-EA403CDAD014@oracle.com> Message-ID: <4DA34D11.9060600@oracle.com> Lance Andersen - Oracle wrote: > : >> >> PS: javac was updated recently to emit warnings for unreachable catch >> clauses and one place that generates this warning is >> src/share/classes/com/sun/rowset/CachedRowSetImpl.java:947. It would >> be great to get that one fixed while you are fixing the other warnings. > > If you are OK with do it as part of this change, happy to change. Absolutely, warnings needs to be eliminated. Looks to me that the try/catch can be completely removed from that method. -Alan. From lance.andersen at oracle.com Mon Apr 11 18:55:44 2011 From: lance.andersen at oracle.com (Lance Andersen - Oracle) Date: Mon, 11 Apr 2011 14:55:44 -0400 Subject: Review request for removal of unchecked lint warnings in javax.sql.rowset, CR 7035615 In-Reply-To: <4DA34D11.9060600@oracle.com> References: <4DA34643.1040303@oracle.com> <0CCA292D-8061-4A11-9B22-EA403CDAD014@oracle.com> <4DA34D11.9060600@oracle.com> Message-ID: <5C969AB6-0225-45E0-86AC-A43A4551D0A5@oracle.com> On Apr 11, 2011, at 2:48 PM, Alan Bateman wrote: > Lance Andersen - Oracle wrote: >> : >>> >>> PS: javac was updated recently to emit warnings for unreachable catch clauses and one place that generates this warning is src/share/classes/com/sun/rowset/CachedRowSetImpl.java:947. It would be great to get that one fixed while you are fixing the other warnings. >> >> If you are OK with do it as part of this change, happy to change. > Absolutely, warnings needs to be eliminated. Looks to me that the try/catch can be completely removed from that method. Yep, the try/catch block can definitely go away.... Regards Lance > > -Alan. Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From lance.andersen at oracle.com Mon Apr 11 20:53:39 2011 From: lance.andersen at oracle.com (Lance Andersen - Oracle) Date: Mon, 11 Apr 2011 16:53:39 -0400 Subject: Review request for removal of unchecked lint warnings in javax.sql.rowset, CR 7035615 In-Reply-To: <4DA34D11.9060600@oracle.com> References: <4DA34643.1040303@oracle.com> <0CCA292D-8061-4A11-9B22-EA403CDAD014@oracle.com> <4DA34D11.9060600@oracle.com> Message-ID: <2EAA9A99-E50B-4E22-9C73-36CF0CA5EDF7@oracle.com> Hi Alan, Joe I pushed the revised webrev out (webrev.01). I am going through a directory at time to resolve the lint errors and found a few additional classes to address in com.sun.rowset (as I had not looked at this directory yet) which you will see in the change log. Regards, lance On Apr 11, 2011, at 2:48 PM, Alan Bateman wrote: > Lance Andersen - Oracle wrote: >> : >>> >>> PS: javac was updated recently to emit warnings for unreachable catch clauses and one place that generates this warning is src/share/classes/com/sun/rowset/CachedRowSetImpl.java:947. It would be great to get that one fixed while you are fixing the other warnings. >> >> If you are OK with do it as part of this change, happy to change. > Absolutely, warnings needs to be eliminated. Looks to me that the try/catch can be completely removed from that method. > > -Alan. Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From mike.duigou at oracle.com Mon Apr 11 21:31:15 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 11 Apr 2011 14:31:15 -0700 Subject: Review request : 4884238 : Constants for standard charsets Message-ID: http://cr.openjdk.java.net/~mduigou/4884238/0/webrev/ This webrev proposes a class java.nio.charset.Charsets to contain definitions for the (currently) six standard character sets and a seventh definition for the platform default character set. There are also minor amendments to the existing javadoc. This change has been previously proposed but the constants were to be defined in Charset which was deemed to have too high a static initialization cost. Using a separate class, Charsets, means that the cost for initialization is only borne by those who use the class--there's virtually no incremental cost to platform initialization. These standard charsets are primarily of value to those currently using the various I/O APIs which take a charset name as a string and throw UnsupportedEncodingException by allowing for easier usage of the APIs which take a Charset instead. It's not been determined yet whether this change, even the change is well received, will make the cutoff for Java 7. It's coming in very late so it is possible that it may be held back until Java 8 for timing/testing/l18n/release issues. Mike From joe.darcy at oracle.com Tue Apr 12 06:21:58 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 12 Apr 2011 06:21:58 +0000 Subject: hg: jdk7/tl/jdk: 7035834: Bad @param tags in LayerUI.java Message-ID: <20110412062208.0A277479CC@hg.openjdk.java.net> Changeset: a12f142410f2 Author: darcy Date: 2011-04-11 23:20 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a12f142410f2 7035834: Bad @param tags in LayerUI.java Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/LayerUI.java From Alan.Bateman at oracle.com Tue Apr 12 08:08:45 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 12 Apr 2011 09:08:45 +0100 Subject: Review request for removal of unchecked lint warnings in javax.sql.rowset, CR 7035615 In-Reply-To: <2EAA9A99-E50B-4E22-9C73-36CF0CA5EDF7@oracle.com> References: <4DA34643.1040303@oracle.com> <0CCA292D-8061-4A11-9B22-EA403CDAD014@oracle.com> <4DA34D11.9060600@oracle.com> <2EAA9A99-E50B-4E22-9C73-36CF0CA5EDF7@oracle.com> Message-ID: <4DA4088D.60703@oracle.com> Lance Andersen - Oracle wrote: > Hi Alan, Joe > > > I pushed the revised webrev out (webrev.01). I am going through a > directory at time to resolve the lint errors and found a few > additional classes to address in com.sun.rowset (as I had not looked > at this directory yet) which you will see in the change log. > The updated changes look okay to me. A few minor comments: src/share/classes/com/sun/rowset/CachedRowSetImpl.java L120 - you want want to insert a line after the declaration of rvh. L296 and L301 - misaligned? L1287 - you could use the diamond operator here L2956 - I assume this can be Map rather than java.util.Map. src/share/classes/com/sun/rowset/JoinRowSetImpl.java L62 - end of comment is misaligned L225 - you could use the diamond operator here -Alan. From lance.andersen at oracle.com Tue Apr 12 14:35:15 2011 From: lance.andersen at oracle.com (Lance Andersen - Oracle) Date: Tue, 12 Apr 2011 10:35:15 -0400 Subject: Review request for removal of unchecked lint warnings in javax.sql.rowset, CR 7035615 In-Reply-To: <4DA4088D.60703@oracle.com> References: <4DA34643.1040303@oracle.com> <0CCA292D-8061-4A11-9B22-EA403CDAD014@oracle.com> <4DA34D11.9060600@oracle.com> <2EAA9A99-E50B-4E22-9C73-36CF0CA5EDF7@oracle.com> <4DA4088D.60703@oracle.com> Message-ID: <3533EFA3-4321-48A1-B8D1-E603D989D5CB@oracle.com> Hi Alan, http://cr.openjdk.java.net/~lancea/7035615/webrev.02/ has your suggested changes below. Regards Lance On Apr 12, 2011, at 4:08 AM, Alan Bateman wrote: > Lance Andersen - Oracle wrote: >> Hi Alan, Joe >> >> >> I pushed the revised webrev out (webrev.01). I am going through a directory at time to resolve the lint errors and found a few additional classes to address in com.sun.rowset (as I had not looked at this directory yet) which you will see in the change log. >> > The updated changes look okay to me. A few minor comments: > > src/share/classes/com/sun/rowset/CachedRowSetImpl.java > L120 - you want want to insert a line after the declaration of rvh. > L296 and L301 - misaligned? > L1287 - you could use the diamond operator here > L2956 - I assume this can be Map rather than java.util.Map. > > src/share/classes/com/sun/rowset/JoinRowSetImpl.java > L62 - end of comment is misaligned > L225 - you could use the diamond operator here > > -Alan. > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From xuelei.fan at oracle.com Tue Apr 12 15:27:39 2011 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Tue, 12 Apr 2011 15:27:39 +0000 Subject: hg: jdk7/tl/jdk: 6882437: CertPath/X509CertPathDiscovery/Test fails on jdk7/pit/b62 Message-ID: <20110412152749.40707479F0@hg.openjdk.java.net> Changeset: 6e306c3aa17b Author: xuelei Date: 2011-04-12 08:27 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6e306c3aa17b 6882437: CertPath/X509CertPathDiscovery/Test fails on jdk7/pit/b62 Summary: Pass trust anchors to CRL certification path building, support CRLs without AKID extension. Reviewed-by: mullan ! src/share/classes/sun/security/provider/certpath/CrlRevocationChecker.java ! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java From Alan.Bateman at oracle.com Tue Apr 12 15:58:18 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 12 Apr 2011 16:58:18 +0100 Subject: Review request for removal of unchecked lint warnings in javax.sql.rowset, CR 7035615 In-Reply-To: <3533EFA3-4321-48A1-B8D1-E603D989D5CB@oracle.com> References: <4DA34643.1040303@oracle.com> <0CCA292D-8061-4A11-9B22-EA403CDAD014@oracle.com> <4DA34D11.9060600@oracle.com> <2EAA9A99-E50B-4E22-9C73-36CF0CA5EDF7@oracle.com> <4DA4088D.60703@oracle.com> <3533EFA3-4321-48A1-B8D1-E603D989D5CB@oracle.com> Message-ID: <4DA4769A.6000205@oracle.com> Lance Andersen - Oracle wrote: > Hi Alan, > > http://cr.openjdk.java.net/~lancea/7035615/webrev.02/ > has your > suggested changes below. Looks good to me, thanks for taking on board the trivial comments. -Alan From lance.andersen at oracle.com Tue Apr 12 16:25:54 2011 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Tue, 12 Apr 2011 16:25:54 +0000 Subject: hg: jdk7/tl/jdk: 7035615: Address lint warnings for javax.sql.rowset & com.sun.rowset Message-ID: <20110412162604.4ADA0479F3@hg.openjdk.java.net> Changeset: 1bb95f6ac753 Author: lancea Date: 2011-04-12 12:25 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1bb95f6ac753 7035615: Address lint warnings for javax.sql.rowset & com.sun.rowset Reviewed-by: alanb, darcy ! src/share/classes/com/sun/rowset/CachedRowSetImpl.java ! src/share/classes/com/sun/rowset/JdbcRowSetImpl.java ! src/share/classes/com/sun/rowset/JoinRowSetImpl.java ! src/share/classes/javax/sql/rowset/BaseRowSet.java ! src/share/classes/javax/sql/rowset/RowSetMetaDataImpl.java ! src/share/classes/javax/sql/rowset/RowSetProvider.java From mike.duigou at oracle.com Tue Apr 12 17:38:17 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 12 Apr 2011 10:38:17 -0700 Subject: Constants for standard charsets -- CR #4884238 In-Reply-To: <4DA42A67.3070802@oracle.com> References: <14F9AA44-1D78-4A56-A11E-329BF0A47911@oracle.com> <4D9AD48E.3060208@oracle.com> <4D9D8C6A.90402@oracle.com> <4DA2ADD9.6000209@oracle.com> <6E61E959-C55D-4394-A3AE-95C3AF5D080C@oracle.com> <4DA339C5.6060103@oracle.com> <4DA409AB.507@oracle.com> <4DA42A67.3070802@oracle.com> Message-ID: <2F5A48EE-A1C9-429F-A924-DB632C300392@oracle.com> On Apr 12 2011, at 03:33 , Alan Bateman wrote: > Alan Bateman wrote: >> I see your mail in the archives: >> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-April/006487.html >> >> but I didn't receive it. I had a similar issue yesterday on another list but I've no idea where the problem is. >> >> -Alan >> > Just a couple of initial comments on the webrev: > > 1. In the standard charsets section of the class description then it might be useful to include a reference to Charsets, maybe "The {@link Charsets} class defines constants for each of the standard charsets". OK > > 2. @see Charsets.DEFAULT, I assume this should be @see Charsets#DEFAULT_CHARSET Correct. I changed it to DEFAULT_CHARSET and forgot to fix this link. > > 3. Looks like Charsets is using 2 rather than 4-space indenting. Ooops, I will correct this. > > > 4. It would be nice to update java.nio.file.Path's class description to replace Charset.forName("UTF-8") with Charsets.UTF_8; I will do so. > I was thinking more about DEFAULT_CHARSET and I'm not sure that we really need it. In the java.io package then all constructors that take a Charset also have a constructor that uses the default charset, same thing in java.lang.String and java.util.zip package. In javax.tools.JavaCompiler I see that null can be used to select the default charset. In java.nio.file.Files then we didn't include versions of readAllLines, newBufferedReader, etc. that didn't take a Charset parameter. I agree that requiring an explicit Charset is best because it makes it clear what charset is being used. For me this argues though for the DEFAULT_CHARSET declaration because it's best to be obvious that the default charset is being used. I always interpret content being accessed with the default charset in one of two ways; - Content that's known to be private that the jvm wrote itself. Useful for caches because it's assumed that the default charset is the most efficient for that platform & configuration. - Content that's potentially uninterpretable because it has an unknown charset and the default charset is the fallback choice. In recent times I've considered switching to using UTF-8 for unknown content. Charset.getDefaultCharset() is possibly just as clear. I personally would use the constant and use only Charsets constants for accessing content. > They can be added if needed but there is an argument that you really need to know the charset when accessing a text file as it can be too fragile to assume the default encoding (esp. with files that are shared between users, applications, or machines). I wouldn't add them. Default charset content should never be shared between instances (though it frequently is). When I have used the default charset it's usually been in mime type declarations for content encoded using the default charset. An example from JXTA: private static final MimeMediaType DEFAULT_TEXT_ENCODING = new MimeMediaType(MimeMediaType.TEXT_DEFAULTENCODING, "charset=\"" + Charset.defaultCharset().name() + "\"", true) My goal in adding a DEFAULT_CHARSET constant was to make use of the default charset more explicit. I definitely don't want to do anything which encourages inappropriate use of the default charset. Mike From Lance.Andersen at oracle.com Tue Apr 12 17:57:18 2011 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Tue, 12 Apr 2011 13:57:18 -0400 Subject: Quick code review to address a couple typos in the javadoc for ResultSet, CR 7007772 Message-ID: <40E6ADF0-7EFC-42D3-9775-A1A5D7BF1E28@oracle.com> Hi folks, Looking for a reviewer for the following simple change to ResultSet to address CR 7007772 hg diff diff -r 1bb95f6ac753 src/share/classes/java/sql/ResultSet.java --- a/src/share/classes/java/sql/ResultSet.java Tue Apr 12 12:25:15 2011 -0400 +++ b/src/share/classes/java/sql/ResultSet.java Tue Apr 12 13:52:32 2011 -0400 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1996, 2010, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1996, 2011, Oracle and/or its affiliates. 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 @@ -137,7 +137,7 @@ * to retrieve the next result from a sequence of multiple results. * *

The number, types and properties of a ResultSet - * object's columns are provided by the ResulSetMetaData + * object's columns are provided by the ResultSetMetaData * object returned by the ResultSet.getMetaData method. * * @see Statement#executeQuery @@ -422,7 +422,7 @@ * of this ResultSet object as * a stream of ASCII characters. The value can then be read in chunks from the * stream. This method is particularly - * suitable for retrieving large LONGVARCHAR values. + * suitable for retrieving large LONGVARCHAR values. * The JDBC driver will * do any necessary conversion from the database format into ASCII. Thank you. Regards, Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From mark.reinhold at oracle.com Tue Apr 12 18:11:25 2011 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 12 Apr 2011 11:11:25 -0700 Subject: Constants for standard charsets -- CR #4884238 In-Reply-To: mike.duigou@oracle.com; Tue, 12 Apr 2011 10:38:17 PDT; <2F5A48EE-A1C9-429F-A924-DB632C300392@oracle.com> Message-ID: <20110412181125.737A0818@eggemoggin.niobe.net> 2011/4/12 10:38 -0700, mike.duigou at oracle.com: > On Apr 12 2011, at 03:33 , Alan Bateman wrote: >> ... >> >> 2. @see Charsets.DEFAULT, I assume this should be @see Charsets#DEFAULT_CHARSET > > Correct. I changed it to DEFAULT_CHARSET and forgot to fix this link. Why is forcing people to type Charsets.DEFAULT_CHARSET better than Charsets.DEFAULT? If DEFAULT_CHARSET needs the _CHARSET suffix then don't the other constants need that too? Why is DEFAULT special? >> ... >> >> I was thinking more about DEFAULT_CHARSET and I'm not sure that we >> really need it. In the java.io package then all constructors that take >> a Charset also have a constructor that uses the default charset, same >> thing in java.lang.String and java.util.zip package. In >> javax.tools.JavaCompiler I see that null can be used to select the >> default charset. In java.nio.file.Files then we didn't include >> versions of readAllLines, newBufferedReader, etc. that didn't take a >> Charset parameter. I tend to agree with Alan that the DEFAULT isn't really necessary. There's already a perfectly good method for that, and invoking a method rather than referencing a static field makes it harder for developers to assume, incorrectly, that it's actually constant across platforms. - Mark From stuart.marks at oracle.com Tue Apr 12 18:22:49 2011 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 12 Apr 2011 11:22:49 -0700 Subject: Quick code review to address a couple typos in the javadoc for ResultSet, CR 7007772 In-Reply-To: <40E6ADF0-7EFC-42D3-9775-A1A5D7BF1E28@oracle.com> References: <40E6ADF0-7EFC-42D3-9775-A1A5D7BF1E28@oracle.com> Message-ID: <4DA49879.50206@oracle.com> Lance, Looks fine to me. s'marks On 4/12/11 10:57 AM, Lance Andersen - Oracle wrote: > Hi folks, > > Looking for a reviewer for the following simple change to ResultSet to address CR 7007772 > > hg diff > diff -r 1bb95f6ac753 src/share/classes/java/sql/ResultSet.java > --- a/src/share/classes/java/sql/ResultSet.java Tue Apr 12 12:25:15 2011 -0400 > +++ b/src/share/classes/java/sql/ResultSet.java Tue Apr 12 13:52:32 2011 -0400 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1996, 2010, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1996, 2011, Oracle and/or its affiliates. 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 > @@ -137,7 +137,7 @@ > * to retrieve the next result from a sequence of multiple results. > * > *

The number, types and properties of aResultSet > - * object's columns are provided by theResulSetMetaData > + * object's columns are provided by theResultSetMetaData > * object returned by theResultSet.getMetaData method. > * > * @see Statement#executeQuery > @@ -422,7 +422,7 @@ > * of thisResultSet object as > * a stream of ASCII characters. The value can then be read in chunks from the > * stream. This method is particularly > - * suitable for retrieving largeLONGVARCHAR values. > + * suitable for retrieving largeLONGVARCHAR values. > * The JDBC driver will > * do any necessary conversion from the database format into ASCII. > > > Thank you. > > Regards, > Lance > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > From kelly.ohair at oracle.com Tue Apr 12 18:22:39 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Tue, 12 Apr 2011 11:22:39 -0700 Subject: Quick code review to address a couple typos in the javadoc for ResultSet, CR 7007772 In-Reply-To: <40E6ADF0-7EFC-42D3-9775-A1A5D7BF1E28@oracle.com> References: <40E6ADF0-7EFC-42D3-9775-A1A5D7BF1E28@oracle.com> Message-ID: <3B29D5FD-A92C-4BB0-82DE-D9BA47AE7D7B@oracle.com> ooks fne. ;^) -kto On Apr 12, 2011, at 10:57 AM, Lance Andersen - Oracle wrote: > Hi folks, > > Looking for a reviewer for the following simple change to ResultSet to address CR 7007772 > > hg diff > diff -r 1bb95f6ac753 src/share/classes/java/sql/ResultSet.java > --- a/src/share/classes/java/sql/ResultSet.java Tue Apr 12 12:25:15 2011 -0400 > +++ b/src/share/classes/java/sql/ResultSet.java Tue Apr 12 13:52:32 2011 -0400 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1996, 2010, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1996, 2011, Oracle and/or its affiliates. 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 > @@ -137,7 +137,7 @@ > * to retrieve the next result from a sequence of multiple results. > * > *

The number, types and properties of a ResultSet > - * object's columns are provided by the ResulSetMetaData > + * object's columns are provided by the ResultSetMetaData > * object returned by the ResultSet.getMetaData method. > * > * @see Statement#executeQuery > @@ -422,7 +422,7 @@ > * of this ResultSet object as > * a stream of ASCII characters. The value can then be read in chunks from the > * stream. This method is particularly > - * suitable for retrieving large LONGVARCHAR values. > + * suitable for retrieving large LONGVARCHAR values. > * The JDBC driver will > * do any necessary conversion from the database format into ASCII. > > > Thank you. > > Regards, > Lance > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > From mike.duigou at oracle.com Tue Apr 12 18:27:28 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 12 Apr 2011 11:27:28 -0700 Subject: Constants for standard charsets -- CR #4884238 In-Reply-To: <20110412181125.737A0818@eggemoggin.niobe.net> References: <20110412181125.737A0818@eggemoggin.niobe.net> Message-ID: <8E9FA2E5-3E8E-41A4-AEC3-75EB1CBE5831@oracle.com> On Apr 12 2011, at 11:11 , mark.reinhold at oracle.com wrote: > 2011/4/12 10:38 -0700, mike.duigou at oracle.com: >> On Apr 12 2011, at 03:33 , Alan Bateman wrote: >>> ... >>> >>> 2. @see Charsets.DEFAULT, I assume this should be @see Charsets#DEFAULT_CHARSET >> >> Correct. I changed it to DEFAULT_CHARSET and forgot to fix this link. > > Why is forcing people to type Charsets.DEFAULT_CHARSET better than > Charsets.DEFAULT? > > If DEFAULT_CHARSET needs the _CHARSET suffix then don't the other > constants need that too? Why is DEFAULT special? The addition of _CHARSET is to encourage static import of Charsets. Unadorned DEFAULT has too much chance of collision. The other defined names shouldn't collide. > >>> ... >>> >>> I was thinking more about DEFAULT_CHARSET and I'm not sure that we >>> really need it. In the java.io package then all constructors that take >>> a Charset also have a constructor that uses the default charset, same >>> thing in java.lang.String and java.util.zip package. In >>> javax.tools.JavaCompiler I see that null can be used to select the >>> default charset. In java.nio.file.Files then we didn't include >>> versions of readAllLines, newBufferedReader, etc. that didn't take a >>> Charset parameter. > > I tend to agree with Alan that the DEFAULT isn't really necessary. > There's already a perfectly good method for that, and invoking a method > rather than referencing a static field makes it harder for developers to > assume, incorrectly, that it's actually constant across platforms. A good point. I think consensus is currently leaning towards removing DEFAULT_CHARSET. Mike From lance.andersen at oracle.com Tue Apr 12 18:34:11 2011 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Tue, 12 Apr 2011 18:34:11 +0000 Subject: hg: jdk7/tl/jdk: 7007772: Address typos in javadoc for ResultSet Message-ID: <20110412183420.F298847A02@hg.openjdk.java.net> Changeset: 0bae251b548b Author: lancea Date: 2011-04-12 14:32 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0bae251b548b 7007772: Address typos in javadoc for ResultSet Reviewed-by: ohair, smarks ! src/share/classes/java/sql/ResultSet.java From Ulf.Zibis at gmx.de Tue Apr 12 19:10:18 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 12 Apr 2011 21:10:18 +0200 Subject: Constants for standard charsets -- CR #4884238 In-Reply-To: <8E9FA2E5-3E8E-41A4-AEC3-75EB1CBE5831@oracle.com> References: <20110412181125.737A0818@eggemoggin.niobe.net> <8E9FA2E5-3E8E-41A4-AEC3-75EB1CBE5831@oracle.com> Message-ID: <4DA4A39A.2070209@gmx.de> Am 12.04.2011 20:27, schrieb Mike Duigou: > On Apr 12 2011, at 11:11 , mark.reinhold at oracle.com wrote: > >> 2011/4/12 10:38 -0700, mike.duigou at oracle.com: >>> On Apr 12 2011, at 03:33 , Alan Bateman wrote: >>>> ... >>>> >>>> 2. @see Charsets.DEFAULT, I assume this should be @see Charsets#DEFAULT_CHARSET >>> Correct. I changed it to DEFAULT_CHARSET and forgot to fix this link. >> Why is forcing people to type Charsets.DEFAULT_CHARSET better than >> Charsets.DEFAULT? >> >> If DEFAULT_CHARSET needs the _CHARSET suffix then don't the other >> constants need that too? Why is DEFAULT special? > The addition of _CHARSET is to encourage static import of Charsets. Unadorned DEFAULT has too much chance of collision. The other defined names shouldn't collide. For me, Charsets.DEFAULT should be enough: 1.) Looks better. 2.) Usage of those constants should be rare, so static import should be rare too. So prevent developpers from typing more than neccessary. 3.) We stay in current tradition. Remember Integer.MAX_VALUE, Long.MAX_VALUE etc... ... but anyway, we drop it. BTW: I too miss the original post of this thread in my emails. Problem with the mail server ? > This change has been previously proposed but the constants were to be defined in Charset which was deemed to have too high a static initialization cost. Using a separate class, Charsets, means that the cost for initialization is only borne by those who use the class--there's virtually no incremental cost to platform initialization. I can't agree with that, because you statically invoke e.g. Charset.forName("US-ASCII"), which causes the expensive initialization of the Charset class. Please note my long waiting patches: ***Bug 100091* - No system start for file.encoding=x-SJIS_0213 *****Bug 100092* - Speed-up FastCharsetProvider *****Bug 100095* - Avoid 2-step lookup in sun.nio.cs charset providers *****Bug 100098* - Make sun.nio.cs.* charset objects light-weight ** -Ulf From xueming.shen at oracle.com Tue Apr 12 19:33:03 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 12 Apr 2011 12:33:03 -0700 Subject: Suspected regression: fix for 6735255 causes delay in GC of ZipFile InputStreams, increase in heap demand In-Reply-To: <1302524116.15253.25.camel@chalkhill> References: <1300916786.4515.107.camel@chalkhill> <4D922D68.2080202@oracle.com> <1301514810.24605.64.camel@chalkhill> <4D93930A.2000604@oracle.com> <1301676177.24605.165.camel@chalkhill> <4D962275.7010601@oracle.com> <4D965D14.6060504@oracle.com> <1301707718.14323.43.camel@chalkhill> <4D98FD10.4090608@oracle.com> <1302183023.27698.20.camel@chalkhill> <4D9E429F.9030200@oracle.com> <1302266193.17745.18.camel@chalkhill> <4D9FD836.1070909@oracle.com> <1302456482.18865.109.camel@chalkhill> <1302524116.15253.25.camel@chalkhill> Message-ID: <4DA4A8EF.4060103@oracle.com> Hi Neil, (1) I believe it would be better to keep the synchronization lock for get/releaseInfalter() "local" instead of using the "global" ZipFile.this, which I agree is "simple". But it also means each/every time when you release the used inflater back to cache, ZipFile.this has to be held and any possible/potential read operation on ZipFile from other thead/ inputstream has to wait ("get" seems fine, the current impl holds the ZipFile.this anyway before reach the getInflater()). (2) The "resource" Infalter mainly holds is the native memory block it alloc-ed at native for zlib, which is not in the Java heap, so I doubt making it "softly" really helps for GC. Sure, cleanup of those "objects" themself is a plus, but I'm not sure if it is really worth using SoftReference in this case (it appears you are now invoking clearStaleStreams() from the finalize()). (3) The releaseInfalter() is now totally driven from clearStaleStreams()/staleStreamQueue, which is under full control of GC. If GC does not kick in for hours/days, infalters can never be put back into its cache after use, even the applications correctly/promptly close those streams after use. And when the GC kicks in, we might see "bunch" (hundreds, thousands) of inflaters get pushed into cache. The approach does solve the "timing" issue that got us here, but it also now has this "native memory cache" mechanism totally under the control of/driven by the GC, the java heap management mechanism, which might not be a preferred scenario. Just wonder if we can have a better choice, say with this GC-driven as the backup cleanup and meanwhile still have the ZFIIS.close() to do something to safely put the used inflater back to cache promptly. To put the infalter as the value of the "streams" map appears to be a good idea/start, now the "infalter" will not be targeted for finalized until the entry gets cleaned from the map, in which might in fact provide us a sort of "orderly" (between the "stream" and its "inflater") clearup that the GC/finalizer can't guarantee. We still have couple days before we hit the "deadline" (to get this one in), so it might worth taking some time on this direction? -Sherman On 04/11/2011 05:15 AM, Neil Richards wrote: > On Sun, 2011-04-10 at 18:28 +0100, Neil Richards wrote: >> With releaseInflater() being driven from the cleanup of stale 'streams' >> entries, it no longer needs to be called from ZFIIS.close(), so, >> instead, only Inflater.reset() is called from there (providing the >> inflater object has not explicitly been ended) so that it releases the >> buffer it has been holding. > Actually, I have a slight change of heart on this aspect. > > Because close() may be driven from a finalize() method in user code (as > is done in the InflaterFinalizer test case), I believe it is possible > (albeit unlikely) for an inflater object to have been reclaimed from > 'streams' (by a call to clearStaleStreams()), put into the inflater > cache, retrieved from there (by another thread creating an input stream) > and having started to be used by that other stream at the point at which > the code in close() is run. > > (This is because weak references will be cleared, and *may* be queued on > the ReferenceQueue, prior to finalization). > > Because of this, it's not actually entirely safe now to call inf.reset() > from ZFIIS.close(). > > Instead, I have added additional calls to clearStaleStreams() from the > finalize() methods of both InputStream implementations in the latest > (hopefully in the meaning of "last") changeset included below. > > As always, please get back to me with any comments, questions or > suggestions on this, > Thanks, > Neil > From Ulf.Zibis at gmx.de Tue Apr 12 19:49:03 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 12 Apr 2011 21:49:03 +0200 Subject: Constants for standard charsets -- CR #4884238 In-Reply-To: <4DA4A39A.2070209@gmx.de> References: <20110412181125.737A0818@eggemoggin.niobe.net> <8E9FA2E5-3E8E-41A4-AEC3-75EB1CBE5831@oracle.com> <4DA4A39A.2070209@gmx.de> Message-ID: <4DA4ACAF.6010907@gmx.de> Am 12.04.2011 21:10, schrieb Ulf Zibis: > > > This change has been previously proposed but the constants were to be defined in Charset which > was deemed to have too high a static initialization cost. Using a separate class, Charsets, means > that the cost for initialization is only borne by those who use the class--there's virtually no > incremental cost to platform initialization. > > I can't agree with that, because you statically invoke e.g. Charset.forName("US-ASCII"), which > causes the expensive initialization of the Charset class. > Additionally I think we should not add another new class for such lousy content, we have so much. Or contrary, there are more methods which should be better located in Charsets than in Charset, but now it's too late for this: availableCharsets() defaultCharset() forName(String charsetName) (then better: get(String charsetName) or retrieve(String charsetName)) isSupported(String charsetName) -Ulf From daniel.daugherty at oracle.com Tue Apr 12 20:37:52 2011 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Tue, 12 Apr 2011 20:37:52 +0000 Subject: hg: jdk7/tl/jdk: 7035555: 4/4 attach/BasicTests.sh needs another tweak for Cygwin Message-ID: <20110412203802.490B547A09@hg.openjdk.java.net> Changeset: 59b2b9a34b3c Author: dcubed Date: 2011-04-12 13:36 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/59b2b9a34b3c 7035555: 4/4 attach/BasicTests.sh needs another tweak for Cygwin Summary: Test needs to properly detect missing AgentInitializationException. Clarify when exceptions are expected. Another Cygwin tweak. Reviewed-by: dsamersoff, ohair ! test/com/sun/tools/attach/ApplicationSetup.sh ! test/com/sun/tools/attach/BasicTests.java ! test/com/sun/tools/attach/BasicTests.sh From Kelly.Ohair at oracle.com Tue Apr 12 21:07:11 2011 From: Kelly.Ohair at oracle.com (Kelly O'Hair) Date: Tue, 12 Apr 2011 14:07:11 -0700 Subject: Heads up, new jaxws source drop bundle Message-ID: <2C65EF31-D918-4517-A521-80D70061E6FD@oracle.com> 7034918: Integrate JAX-WS 2.2.4-b01 in to JDK 7 http://cr.openjdk.java.net/~ohair/openjdk7/jaxws-7034918/webrev/ More details on the changes here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7034918 The new jaxws source drop bundle is called: jdk7-jaxws2_2_4-b01-2011_04_08.zip So if you have your own ALT_DROPS_DIR cache, you need to add this file: http://download.java.net/glassfish/components/jax-ws/openjdk/jdk7/jdk7-jaxws2_2_4-b01-2011_04_08.zip -kto From kelly.ohair at oracle.com Tue Apr 12 21:07:23 2011 From: kelly.ohair at oracle.com (kelly.ohair at oracle.com) Date: Tue, 12 Apr 2011 21:07:23 +0000 Subject: hg: jdk7/tl/jaxws: 7034918: Integrate JAX-WS 2.2.4-b01 in to JDK 7 Message-ID: <20110412210723.EE91B47A0A@hg.openjdk.java.net> Changeset: d5e3452a6909 Author: ohair Date: 2011-04-12 12:39 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/d5e3452a6909 7034918: Integrate JAX-WS 2.2.4-b01 in to JDK 7 Reviewed-by: ramap ! jaxws.properties From mike.duigou at oracle.com Tue Apr 12 21:25:10 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 12 Apr 2011 14:25:10 -0700 Subject: Constants for standard charsets -- CR #4884238 In-Reply-To: <4DA4A39A.2070209@gmx.de> References: <20110412181125.737A0818@eggemoggin.niobe.net> <8E9FA2E5-3E8E-41A4-AEC3-75EB1CBE5831@oracle.com> <4DA4A39A.2070209@gmx.de> Message-ID: <8FE56A64-C782-475F-80D8-8FD5AA2D4DB9@oracle.com> On Apr 12 2011, at 12:10 , Ulf Zibis wrote: > Am 12.04.2011 20:27, schrieb Mike Duigou: >> This change has been previously proposed but the constants were to be defined in Charset which was deemed to have too high a static initialization cost. Using a separate class, Charsets, means that the cost for initialization is only borne by those who use the class--there's virtually no incremental cost to platform initialization. > > I can't agree with that, because you statically invoke e.g. Charset.forName("US-ASCII"), which causes the expensive initialization of the Charset class. It's expected that by the time Charsets is referenced that Charset will already be initialized. Charset is initialized during the setup of System.out/System.err or earlier. > Please note my long waiting patches: > Bug 100091 - No system start for file.encoding=x-SJIS_0213 > Bug 100092 - Speed-up FastCharsetProvider > Bug 100095 - Avoid 2-step lookup in sun.nio.cs charset providers > Bug 100098 - Make sun.nio.cs.* charset objects light-weight Unfortunately I don't know anything about the status of these issues. Mike From stuart.marks at oracle.com Tue Apr 12 21:42:23 2011 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 12 Apr 2011 14:42:23 -0700 Subject: advice & review requested for 6896297, race condition in rmid causing JCK failure In-Reply-To: <4D9E469D.5050803@oracle.com> References: <4D9E3867.7030004@oracle.com> <4D9E469D.5050803@oracle.com> Message-ID: <4DA4C73F.8060307@oracle.com> Hi David, Thanks for your notes and analysis. Good point about the temporary inconsistency between groupEntry and groupTable. With the change, there's a brief moment where a GroupEntry in the registered state can be observed to be absent from the groupTable, which wasn't possible before. I don't think this is a problem though. I can't find any places where operations on a GroupEntry need to look in the groupTable. (If they did exist, they'd have run into the same deadlock that I ran into in making this change.) Most paths through the code seem to first fetch an entry from groupTable and then operate on the entry. Somebody could remove and unregister the entry from groupTable between the fetch and the operation on the entry, but that can already occur in absence of this change. In general the style of this code seems to be to lock individual data structures piecemeal, so I wouldn't be surprised if there are already cases where they can be inconsistent temporarily. For example, it seems like there ought to be some relationship between the members of idTable and groupTable, yet they are locked and updated independently through quite different code paths. This is dangerously close to a line of reasoning that goes like "it's already inconsistent, so making it a little more inconsistent doesn't hurt" which I detest. However, I don't have any better ideas at the moment. Also note that switching from HM to CHM (regardless of what we do with the serialized form) has the same issue. Doing this will protect the maps themselves -- and avoid ConcurrentModificationException, the original cause of this problem -- but it won't preserve any consistency between the maps. Thanks for mentioning startupLock. It seemed suspicious to me too, but I think addressing those issues is out of scope for this bugfix. I'll talk about serialization more in my forthcoming reply to Alan. s'marks On 4/7/11 4:19 PM, David Holmes wrote: > Hi Stuart, > > I can't answer your specific questions as I'm not familiar with the RMI > infrastructure either. Taking the lock in writeObject and moving > group.unregister out of the sync block to avoid deadlock seems reasonable. The > main question to ask with such a move is whether the temporary inconsistency in > state is something that can be observed and cause a problem. > > The lock ordering analysis seems reasonable. > > I do note that the startupLock protocol seems suspicious as there is a race > with detection of the lock value. I assume init itself can never be invoked by > more than one thread ;-) It may be that the object can only become accessible > concurrently at some time during init (ie it gets published) in which case the > protocol will work fine - but you really need a full understanding of the > lifecycle of the objects to determine that. > > That aside, using ConcurrentHashMap would simplify the solution to the current > problem. If you are concerned about the serialized form then you could define > writeObject and readObject such that they convert between CHM and plain HM > using the serialized-fields API. > > Cheers, > David > > Stuart Marks said the following on 04/08/11 08:19: >> Hi Core-Libs developers, >> >> I'd like to solicit some advice and discussion about this bug and a potential >> fix I'm cooking for it. Here is the bug report; it contains details about the >> problem and my analysis of it: >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6896297 >> >> and here's a webrev of the fix I'm working on: >> >> http://cr.openjdk.java.net/~smarks/reviews/6896297/webrev.0/ >> >> Briefly, the problem is incorrect synchronization of groupTable, a HashMap >> field of an Activation object. The code mostly locks groupTable around any >> access to it. However, no such locking is done during serialization. If the >> groupTable is modified while it's being serialized, >> ConcurrentModificationException occurs. >> >> The obvious fix would be to use ConcurrentHashMap instead of Hashmap and to >> remove the external locking entirely. Unfortunately this will change the >> serialized representation of the Activation object, which I'm not sure is >> acceptable. >> >> Assuming that we can't change the serialized represenation, the alternative >> approach would be to make sure that locking is done properly during >> serialization. This is fairly easy to do by locking groupTable in a >> writeObject() method. Unfortunately, this introduces a deadlock. >> >> This deadlock occurs because, with this modification, there are now paths >> through the code that take locks in the opposite order. Specifically, the >> addLogRecord() method locks the log object and then (via serialization and >> the newly added writeObject() method) locks groupTable. However, the >> unregisterGroup() method locks groupTable and calls >> GroupEntry.unregisterGroup() which logs the event, which takes a lock on the >> log. >> >> After some analysis, I've determined that the call to >> GroupEntry.unregisterGroup() can be moved outside the synchronization of >> groupTable. This removes the ordering problem. >> >> With these fixes in place (the state of the webrev above) I can get several >> hundred successful test runs with neither ConcurrentModificationException nor >> any deadlocks. >> >> Of course, that doesn't mean the change is correct. :-) >> >> Questions: >> >> 1. Is there a requirement that the serialized form of Activation remain >> unchanged? If we can change it, we might as well just use ConcurrentHashMap >> instead of HashMap. >> >> 2. Is my lock ordering analysis correct? I've pored over the code, but not >> really being familiar with any RMI concepts, I'm not sure I have it right. >> I've written this analysis into a big comment I've added to the code. >> >> 3. There is also a potential concurrency issue with idTable, which is used >> similarly to groupTable. I haven't seen a test failure from it though. It >> seems sensible to add a lock for it in Activation.writeObject() though. I >> don't particularly like nesting the locks of idTable and groupTable, but >> locking them separately would require serializing the Activation object field >> by field instead of simply using defaultWriteObject(). Is this a reasonable >> approach? >> >> Thanks for any advice or comments. >> >> s'marks >> From stuart.marks at oracle.com Tue Apr 12 22:08:43 2011 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 12 Apr 2011 15:08:43 -0700 Subject: advice & review requested for 6896297, race condition in rmid causing JCK failure In-Reply-To: <4DA31453.2020408@oracle.com> References: <4D9E3867.7030004@oracle.com> <4DA31453.2020408@oracle.com> Message-ID: <4DA4CD6B.8000209@oracle.com> On 4/11/11 7:46 AM, Alan Bateman wrote: > Stuart Marks wrote: >> Hi Core-Libs developers, >> >> I'd like to solicit some advice and discussion about this bug and a potential >> fix I'm cooking for it. Here is the bug report; it contains details about the >> problem and my analysis of it: >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6896297 >> >> and here's a webrev of the fix I'm working on: >> >> http://cr.openjdk.java.net/~smarks/reviews/6896297/webrev.0/ > I haven't worked on RMI and so I don't have a good insight into the > implementation. I think (and Peter Jones can correct me) that changing the > serialized form would just inhibit recovery of rmid from an existing log file. > As David said, you could switch to CHM and implement readObject/writeObject to > serialize/deserialize in the current form. That said, I looked your webrev and > the changes look reasonable to me. I don't see anything obviously wrong with > moving the unregisterGroup out of the synchronized block. I didn't see anything obviously wrong either... my hope (or fear) was that somebody would point out something non-obviously wrong. :-) In a face-to-face conversation, Joe Darcy pointed out to me that serialization compatibility is over the types of the fields declared in the class, not the actual serial data in the object stream. The groupTable and idTable fields are both Maps, so we could change the implementation from HashMap to ConcurrentHashMap and it would be compatible with any implementation that has CHM, i.e. 1.5 or later. (It would probably be wise to have readObject reconstitute the tables as CHM in case they encountered HM in the serialized form.) The alternatives seem to be as follows: 1. Convert groupTable and idTable to ConcurrentHashMap and remove external synchronization, and otherwise make minimal changes to serialization code. This puts a CHM into the object stream, which should be compatible with anything using JDK 1.5 or later as noted above. 2. Convert groupTable and idTable to ConcurrentHashMap and remove external synchronization, and provide readObject/writeObject implementations to place ordinary HashMaps (as opposed to CHMs) in the object stream. This serialized form is more compatible, but it requires more serialization code to be developed, tested, and maintained. 3. Adjust the locking strategy to prevent ConcurrentModificationException but otherwise make no changes to serialization or data structures. This is what I've posted in the webrev. The key issue seems to be whether we want to preserve compatibility of the serialized form. If we care about compatibility of the serialized form, #3 is probably the safest. If somebody comes along and tells us that we don't have to worry about serial compatibility of this stuff at all, then #1 is probably the best since it simplifies the code a lot. In the absence of any further information, I'm inclined to go with #3, since I've already developed and tested it and it's basically ready to go. Any further thoughts, anybody? s'marks From Ulf.Zibis at gmx.de Tue Apr 12 22:09:13 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Wed, 13 Apr 2011 00:09:13 +0200 Subject: Constants for standard charsets -- CR #4884238 In-Reply-To: <8FE56A64-C782-475F-80D8-8FD5AA2D4DB9@oracle.com> References: <20110412181125.737A0818@eggemoggin.niobe.net> <8E9FA2E5-3E8E-41A4-AEC3-75EB1CBE5831@oracle.com> <4DA4A39A.2070209@gmx.de> <8FE56A64-C782-475F-80D8-8FD5AA2D4DB9@oracle.com> Message-ID: <4DA4CD89.4080200@gmx.de> Am 12.04.2011 23:25, schrieb Mike Duigou: > On Apr 12 2011, at 12:10 , Ulf Zibis wrote: > >> Am 12.04.2011 20:27, schrieb Mike Duigou: >>> This change has been previously proposed but the constants were to be defined in Charset which was deemed to have too high a static initialization cost. Using a separate class, Charsets, means that the cost for initialization is only borne by those who use the class--there's virtually no incremental cost to platform initialization. >> I can't agree with that, because you statically invoke e.g. Charset.forName("US-ASCII"), which causes the expensive initialization of the Charset class. > It's expected that by the time Charsets is referenced that Charset will already be initialized. Charset is initialized during the setup of System.out/System.err or earlier. Yes, and I think, initializing those 6 simple charsets is nothing against initializing Charset class, and even less after integrating ***Bug 100098* - Make sun.nio.cs.* charset objects light-weight .** >> Please note my long waiting patches: >> Bug 100091 - No system start for file.encoding=x-SJIS_0213 >> Bug 100092 - Speed-up FastCharsetProvider >> Bug 100095 - Avoid 2-step lookup in sun.nio.cs charset providers >> Bug 100098 - Make sun.nio.cs.* charset objects light-weight > Unfortunately I don't know anything about the status of these issues. It's a pity. Lookup and initializing charsets could be much faster. -Ulf From dl at cs.oswego.edu Wed Apr 13 00:13:02 2011 From: dl at cs.oswego.edu (Doug Lea) Date: Tue, 12 Apr 2011 20:13:02 -0400 Subject: Fwd: [concurrency-interest] ConcurrentHashMap footprint and contention improvements Message-ID: <4DA4EA8E.6070506@cs.oswego.edu> Members of this list are also invited to check this out. I'm not sure if it will make Java7 schedule, but the improvements seem worthwhile given the increased use of ConcurrentHashMap inside the JDK (including multiple tables per class loader in JDK7.) -Doug -------- Original Message -------- Subject: [concurrency-interest] ConcurrentHashMap footprint and contention improvements Date: Tue, 12 Apr 2011 20:07:17 -0400 From: Doug Lea

To: Concurrency-interest at cs.oswego.edu For years, we've known that ConcurrentHashMaps have initial footprints (over 1000 bytes using default constructor) that are too big for casual use. And that the best way to address this would be to use the Fences API to emulate "final field" memory model guarantees in the presence of lazy initialization. But we aren't releasing the Fences API. So I committed a version that instead uses Unsafe calls to essentially the same effect (reducing initial footprint to around 100 bytes, plus a few percent savings for large populated tables). Also, this version includes throughput improvements under contention (mainly by interleaving locking with probes, to absorb cache misses), which can double performance on big tables with many threads. While conceptually straightforward, these lead to many line-of-code changes. The main price paid for these improvements is a greater reliance of "volatile" vs "final" reads, which are essentially equivalent in cost on most machines, but can be more costly on ARM and POWER. Even on these though, the net effect should be positive. It would be helpful if members of this list could help check that this is so. The committed version is now in java.util.concurrent sources (at http://gee.cs.oswego.edu/dl/concurrency-interest/index.html) and can be run by getting jsr166.jar and using "java -Xbootclasspath/p:jsr166.jar" with any java7 build or binary (http://dlc.sun.com.edgesuite.net/jdk7/binaries/index.html). Also, as an alternative, I temporarily placed an unpackaged source version (with the class renamed "CHM") at http://gee.cs.oswego.edu/dl/wwwtmp/CHM.java You can compile and somehow run in any java6/7 JVM. While working on these changes, I also contemplated other more extensive redesigns, including Cliff Click's non-blocking version (http://sourceforge.net/projects/high-scale-lib/) which usually has better scalability with large numbers of threads solely using get and put, but not otherwise uniformly a better choice. -Doug _______________________________________________ Concurrency-interest mailing list Concurrency-interest at cs.oswego.edu http://cs.oswego.edu/mailman/listinfo/concurrency-interest From mike.skells at talk21.com Wed Apr 13 00:48:38 2011 From: mike.skells at talk21.com (mike.skells at talk21.com) Date: Wed, 13 Apr 2011 01:48:38 +0100 (BST) Subject: proposal to optimise the performance of the Jar utility In-Reply-To: <4D9CAB29.5090009@oracle.com> References: <479637.89357.qm@web86603.mail.ird.yahoo.com> <4D9CAB29.5090009@oracle.com> Message-ID: <652584.84963.qm@web86605.mail.ird.yahoo.com> Hi Sherman, I have had a quick look at the current code to see what 'low hanging fruit' there is. I appreciate that parallelizing the command in its entirity may not be feasible for the first release The tests that I have run are jarring the content of the 1.7 rt.jar with varying compression levels. Each jar is run as an child process 6 times and the average of the last 5 is taken. Tests are pretty much CPU bound on a single core 1. The performance of the cf0 (create file with no compression) path can be improved for the general case if the file is buffered. In my test env (windows 7 64bit) this equates to a 17% time performance improvement in my tests. In the existing code the file is read twice, once to calc the CRC and once to write the file to the Jar file. This change would buffer a single small file at a time (size < 100K) 2. It is also a trivial fix to allow different compression levels, rather than stored and default After that it is harder to gain performance improvements without structural change or more discussion 3. The largest saving after that is in the management of the 'entries' Set, as the hashcode of the File is expensive (this may not apply to other filesystems). the management of this map seems to account for more cpu than Deflator! I cannot see the reason for this data being collected. I am probably missing the obvious ... 4. After that there is just the parallelisation of the jar utility and the underlying stream What is the best way to proceed regards Mike ________________________________ From: Xueming Shen To: core-libs-dev at openjdk.java.net Sent: Wednesday, 6 April, 2011 19:04:25 Subject: Re: proposal to optimise the performance of the Jar utility Hi Mike, We are in the final stage of the JDK7 development, work like this is unlikely to get in the last minute. I have filed a CR/RFE to trace this issue, we can use this CR as the start point for the discussion and target for some jdk7 update releases or JDK8. 7034403: proposal to optimise the performance of the Jar utility Thanks, Sherman On 04/05/2011 04:42 PM, mike.skells at talk21.com wrote: > Hi, > Not sure if this is too late for Java 7 but I have made some optimisations for >a > client to improve the performance of the jar utility in their environment, and > would like to promite then into the main code base > > The optimisations that I have performed are > > 1. Allowing the Jar utility to have other compression levels (currently it > allows default (5) only) > 2. Multi-threading, and pipelining the the file information and access > 3. multi-threading the compression and file writing > > A little background > A part of the development process of where I work they regularly Jar the >content > of the working projects as part of the distribution to remote systems. This is >a > large and complex code base of 6 million LOC and growing. The Jar file ends up > compressed to approx 100Mb, Uncompressed the jar size is approx 245mb, about >4-5 > times the size of rt.jar. > > I was looking at ways to improve the performance as this activity occurs >several > times a day for dozens of developers > > In essence when compressing a new jar file the jar utility is single threaded > and staged. Forgive me if this is an oversimplification > > first it works out all of the files that are specified, buffering the file > names, (IO bound) > then it iterates through the files, and for each file, it load the file > information, and then the file content sending it to a JarOutputStream, (CPU > bound or IO bound depending on the IO speed) > > The JarOutputStream has a compression of 0 (just store) or 5 (the default), and > the jar writing is single threaded by the design of the JarOutputStream > > The process of creation of a Jar took about 20 seconds in windows with the help > of an SSD, and considerable longer without one, and was CPU bound to one CPU > core > > ---- > The changes that I made were > 1. Allow deferent compression levels (for us a compression level of 1 increases > the file size of the Jar to 110 Mb but reduces the CPU load in compression to > approx 30% of what it was (rough estimate) > 2. pipelining the file access > 2.1 one thread is started for each file root (-C on the Jar command line), > which scans for files and places the file information into a blocking >queue(Q1), > which I set to abretrary size of 200 items > 2.2 one thread pool of 10 threads reads the file information from the queue > (Q1) and buffers the file content to a specified size (again I specified an > arbetrary size limit of 25K for a file, and places the buffered content into a > queue(q2) (again arbetrary size of 10 items > 2.3 one thread takes the filecontent from Q2 and compresses it or checksums > it and adds it the the JarOutputStream. This process is single threaded due to > the design of the JarOutputStream > > some other minor performance gain occurred by increasing the buffer on the > output stream to reduce the IO load > > The end result is that the process takes about approx 5 seconds in the same > configuration > > The above is in use in production configuration for a few months now > > As a home project I have completed some enhancements to the JarOutputStream, >and > produced a JarWriter that allows multiple threads to work concurrently >deflating > or calculating checksums, which seems to test OK for the test cases that Ihave > generated,and successfully loads my quad core home dev machine on all cores. > Each thread allocates a buffer, and the thread compresses a files into the > buffer, only blocking other threads whenthe buffer is written to the output > (which is after the compression is complete, unless the file is too large to > compress > > This JarWriter is not API compatable with the JarOutputStream, it is not a > stream. It allows the programmer to write a record based of the file >information > and an input stream, and is threadsafe. It is not a drop in replacement for > JarOutputStream > I am not an expert in the ZIp file format, but much of the code from > ZipOutputStream is unchanged, just restructured > --- > I did think that there is some scope for improvement, that I have not looked at > a. thresholding of file size for compression (very small files dont compress > well > b. some file types dont compress well (e.g. png, jpeg) as they have been > compressed already) > c. using NIO to parallelise the loading of the file information or content > d. some pre-charging of the deflator dictionary (e.g. a class file contains the > strings of the class name and packages), but this would make the format > incompatable with zip, and require changes to the JVM to be useful, and is a > long way from my comform zone, or skill set. This would reduce the file size > > -- > What is the view of the readers. Is this something, or at least some parts of > this that could be incorperated into Java 7 or is this too late on the dev >cycle > > regards > > Mike From valerie.peng at oracle.com Wed Apr 13 01:13:03 2011 From: valerie.peng at oracle.com (valerie.peng at oracle.com) Date: Wed, 13 Apr 2011 01:13:03 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20110413011343.F24FF47A1B@hg.openjdk.java.net> Changeset: 5d132f3bfbbf Author: valeriep Date: 2011-04-12 15:57 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5d132f3bfbbf 7001094: Can't initialize SunPKCS11 more times than PKCS11 driver maxSessionCount Summary: Changed SessionManager to keep track of session count for each instance Reviewed-by: mullan ! src/share/classes/sun/security/pkcs11/SessionManager.java Changeset: a3de1543568b Author: valeriep Date: 2011-04-12 16:09 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a3de1543568b 6986789: Sun pkcs11 provider fails to parse path name containing "+" Summary: Modified to accept '+' as valid character. Reviewed-by: weijun ! src/share/classes/sun/security/pkcs11/Config.java ! test/sun/security/pkcs11/Provider/ConfigShortPath.java + test/sun/security/pkcs11/Provider/cspPlus.cfg From huizhe.wang at oracle.com Sun Apr 10 03:59:02 2011 From: huizhe.wang at oracle.com (Joe Wang) Date: Sat, 09 Apr 2011 20:59:02 -0700 Subject: Need reviewers: Update of jaxp 1.4.5 source drop bundle In-Reply-To: <4D9DC45E.7000006@oracle.com> References: <984D321F-F4F4-4FC4-BE41-C89E75F66243@oracle.com> <4D6E9EFB.4000506@oracle.com> <4D9D9043.4040701@oracle.com> <4D9DC45E.7000006@oracle.com> Message-ID: <4DA12B06.8050606@oracle.com> Sorry for the late answer to this question. I was on a long vacation. Please see inline below. On 4/7/2011 7:04 AM, Dalibor Topic wrote: > On 4/7/11 3:49 PM, Dr Andrew John Hughes wrote: > >> On 07/04/2011, Dalibor Topic wrote: >> >>> On 3/3/11 3:01 AM, Dr Andrew John Hughes wrote: >>> >>>> How do we know what the actual changes are between these tarballs? Is >>>> there some JAXP repository somewhere these are derived from, with >>>> appropriate tagging? >>>> >>> Afaik, the JAXP API and implementation are supplied by the upstream JAXP >>> developers >>> in the GlassFish JAXP project, i.e. http://jaxp.java.net/ . The source code >>> repository >>> is at http://java.net/projects/jaxp-sources/sources/svn/show >>> >>> >> http://java.net/projects/jaxp-sources/sources/svn/show/tags shows no >> tags in the last six months. What does this tarball correspond to? >> The last tag I added was JAXP-1_4_4. Those that starts with a "t" were probably added when the migration team converted the repo from cvs. I'll check with them to see if they can help remove them. They are crazy too many. The bundle contains sources up to revision 3025. I did not create tag for dev releases. We used to add a tag for each formal release in cvs. SVN does not have tag and I didn't see the need to make a copy of the trunk when we can use revision. I should have made a note of the revision, which I just did, see 7023289 jaxp 1.4.5 developement jdk7 2nd integration. Here's a list of the changes: 1. 2 regressions fixed 2. 13 of 19 JCK bugs evaluated; 9 fixed, 4 were determined as invalid and needed to be excluded from JCK. 3. Xerces and Xalan localization updated; 72 resource bundles updated, 107 new bundles added provided by Oracle localization team 4. 1 SQE conformance related test updated 5. 1 comprehensive performance improvement from the performance team; performance improved by 23% in final result. 6. 4 other bugs fixed. 1. Regressions : Issues Priority Status Synopsis Resolution Date Note CR 7014246 2-High 10-Fix delivered Code.toString can exit VM 1/25/2011 JCK regression from jdk7 b125 CR 7014220 3-Medium 10-Fix delivered UTF lexical presentation of some new digits accepted by XML document validator with JAXP 1.4.5 1/27/2011 JCK regression from jdk7 b125 2. Conformance (JCK bugs): Issues Priority Status Synopsis Resolution Date Note CR 6970890 3-Medium 11-closed Single XML char "-" in a regex char class expression 2/7/2011 conformance CR 6953797 2-Incomplete Conformance SchemaFactory cannot parse schema if whitespace added within patterns in Selector XPath expression 1/18/2011 Conflicting w3c tests. See 4988387 CR 6963124 3-Medium 11-closed Reference to all model group allows maxOccurs > 1 11/19/2010 conformance CR 6963468 3-Medium 10-Fix delivered Error reported for a valid element substitution 2/3/2011 conformance CR 6989956 3-Medium 10-Fix delivered Wrong error message if maxOccurs in Choice less than maxOccurs in Elements contained in the Choice 1/31/2011 conformance CR 6975493 3-Medium 2-Incomplete Schema parser fails with NPE if ErrorHandler is set 2/16/2011 conformance CR 6977201 3-Medium 10-Fix delivered Validator incorrectly interprets an empty regex pattern 2/11/2011 conformance CR 6975265 3-Medium 11-closed Schema parser allows some Element Information Items contain other element information item 2/9/2011 conformance CR 6972140 3-Medium 10-Fix delivered Regex's with wrong char range pattern are accepted by validator and schema parser 2/7/2011 conformance CR 6967214 3-Medium 10-Fix delivered Schema compiler allows schemata to have unpaired parenthesises in regex 1/24/2011 JCK CR 6938436 3-Medium invalid xjc fails if attribute-value in a schema contains leading, trailing space (#x20) characters 11/17/2010 Evaluated; Now a JCK bug. CR 6942120 3-Medium 2-incomplete SchemaFactory does not catch enum. value that is not in the value space of the base type, anyURI. 12/03/2010 suggested exclusion from JCK CR 6964720 3-Medium 10-Fix delivered The inexpressible union of two attribute wildcards should be reported as an error 3. Localization CR 7001986 3-Medium 10-Fix delivered NLS: jaxp resource bundles cannot be processed by translation team 6904166 jdk-jaxp localization ? Xerces Accessibility compliance CR 7018661 3-Medium 2-incomplete javax.xml code comments have issues with Accessibility compliance 2/14/2011 Need to be split among JAXP, JAX-WS, and XML-DSIG. Need testcase 4. SQE Test CR 6999203 3-Medium 10-Fix delivered jaxp-test for conformance bug 6756677 still fails 2/8/2011 JDK SQE needs to update 5. CR 6956363 3-Medium 10-Fix delivered reducing throwing of XMLConfigurationException can improve SPECjvm2008 xml.validation by 10% 6. other P3 bugs CR 6992561 3-Medium 10-Fix delivered Encoding of SystemId in Locator in JDK 6 1/12/2011 jaxws CR 7003147 3-Medium 11-Closed DOMImplementation.getFeature() requires "+" prefix for XPath, contrary to spec CR 6841137 3-Medium 10-Fix delivered com.sun.org.apache.bcel.internal.Constants.ArrayType missing hashCode() CR 7021889 3-Medium 10-Fix delivered XNIException swallows the cause of error Thanks, Joe > > Good point. CC:ing Joe. > > cheers, > dalibor topic > From masayoshi.okutsu at oracle.com Mon Apr 11 05:10:28 2011 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Mon, 11 Apr 2011 14:10:28 +0900 Subject: Codereview request for 7033561: Missing Unicode Script aliases In-Reply-To: <4D9CD04C.4060105@oracle.com> References: <4D9CCA26.8050502@oracle.com> <4D9CCD3A.40001@oracle.com> <4D9CD04C.4060105@oracle.com> Message-ID: <4DA28D44.7020200@oracle.com> The fix looks good to me. Masayoshi On 4/7/2011 5:42 AM, Xueming Shen wrote: > Thanks! webrev has been updated accordingly. > > -Sherman > > > On 04/06/2011 01:29 PM, Alan Bateman wrote: >> Xueming Shen wrote: >>> >>> It appears the aliases mapping for Character.UnicodeScript is not >>> updated accordingly when >>> we upgraded the Unicode support to 6.0 for JDK7. The difference >>> between the previous version >>> (5.2) and 6.0 of the aliases are these 3 missing names reported in >>> #7033561. >>> >>> The webrev with the change is at >>> >>> http://cr.openjdk.java.net/~sherman/7033561/webrev >>> >>> Thanks, >>> Sherman >>> >> It looks like test/java/lang/Character/CheckScript.java is missing >> the GPL header, might be good to add it while you are there. >> >> -Alan. > From rickard.backman at oracle.com Tue Apr 12 07:35:08 2011 From: rickard.backman at oracle.com (rickard.backman at oracle.com) Date: Tue, 12 Apr 2011 07:35:08 +0000 Subject: hg: jdk7/tl/jdk: 7026287: Asynchronous API sample Message-ID: <20110412073518.17E2E479D1@hg.openjdk.java.net> Changeset: 54446de9fbb0 Author: rbackman Date: 2011-04-12 09:04 +0200 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/54446de9fbb0 7026287: Asynchronous API sample Summary: Implement a chat server using the new asynchronous networking API Reviewed-by: hosterda, alanb ! make/mksample/nio/Makefile + make/mksample/nio/chatserver/Makefile + src/share/sample/nio/chatserver/ChatServer.java + src/share/sample/nio/chatserver/Client.java + src/share/sample/nio/chatserver/ClientReader.java + src/share/sample/nio/chatserver/DataReader.java + src/share/sample/nio/chatserver/MessageReader.java + src/share/sample/nio/chatserver/NameReader.java + src/share/sample/nio/chatserver/README.txt + test/sample/chatserver/ChatTest.java From rickard.backman at oracle.com Tue Apr 12 11:14:45 2011 From: rickard.backman at oracle.com (rickard.backman at oracle.com) Date: Tue, 12 Apr 2011 11:14:45 +0000 Subject: hg: jdk7/tl/jdk: 7026304: Fork-Join sample Message-ID: <20110412111454.BE533479DA@hg.openjdk.java.net> Changeset: 9128eace50f5 Author: rbackman Date: 2011-04-12 13:14 +0200 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9128eace50f5 7026304: Fork-Join sample Summary: Implement a merge-sort sample using Fork-Join Reviewed-by: hosterda, chegar, dholmes ! make/mksample/Makefile + make/mksample/forkjoin/Makefile + make/mksample/forkjoin/mergesort/Makefile + src/share/sample/forkjoin/mergesort/MergeDemo.java + src/share/sample/forkjoin/mergesort/MergeSort.java + test/sample/mergesort/MergeSortTest.java From maurizio.cimadamore at oracle.com Wed Apr 13 04:00:16 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 13 Apr 2011 04:00:16 +0000 Subject: hg: jdk7/tl/langtools: 2 new changesets Message-ID: <20110413040027.70AD047A28@hg.openjdk.java.net> Changeset: f00986f55961 Author: mcimadamore Date: 2011-04-12 20:56 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/f00986f55961 7034511: Loophole in typesafety Summary: Type-variable substutution takes upper bound of replaced captured type-variable Reviewed-by: dlsmith ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/generics/7034511/T7034511a.java + test/tools/javac/generics/7034511/T7034511a.out + test/tools/javac/generics/7034511/T7034511b.java + test/tools/javac/generics/7034511/T7034511b.out Changeset: bfbc197b560f Author: mcimadamore Date: 2011-04-12 20:58 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/bfbc197b560f 7034019: ClassCastException in javac with conjunction types Summary: Resolve.mostSpecific doesn't handle case of raw override Reviewed-by: dlsmith ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/generics/7034019/T7034019a.java + test/tools/javac/generics/7034019/T7034019b.java + test/tools/javac/generics/7034019/T7034019c.java + test/tools/javac/generics/7034019/T7034019c.out + test/tools/javac/generics/7034019/T7034019d.java + test/tools/javac/generics/7034019/T7034019d.out From pcj at roundroom.net Wed Apr 13 05:13:32 2011 From: pcj at roundroom.net (Peter Jones) Date: Wed, 13 Apr 2011 01:13:32 -0400 Subject: Request for review: 6597112: Referential integrity loophole during remote object export In-Reply-To: <1302283069.32207.58.camel@chalkhill> References: <4D775A58.6010708@oracle.com> <1301000071.25581.16.camel@chalkhill> <4D9F2C58.9050404@oracle.com> <1302283069.32207.58.camel@chalkhill> Message-ID: <6D7ED3FB-E15F-4465-AD1A-BABD4E70E63E@roundroom.net> Neil, On Apr 8, 2011, at 1:17 PM, Neil Richards wrote: > Hi Peter, > Thank you for your review on this problem - it really helped in > highlighting some invalid assumptions I was making about the way that > the RMI code behaves. > > I had assumed that, once the stub is returned from exportObject, the > 'liveness' of the stub would control the the 'liveness' of the exported > object (as the stub is, logically, a kind of remote reference to the > object). > > I'd argue this is a naturally reasonable expectation to have (ie. it > would be good to enhance the RMI mechanism so that behaves this way), > but, as you point out, that's not how it currently behaves (there are > current get-out clauses in the RMI spec which warn about the behaviour > being different than one would initially expect in this case). Yes, this is the subject of a different, old bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4114579 which I agree is problematic, but that behavior having existed for so long, I think that there is a question of whether fixing it now would cause more harm than good. At any rate, it's separate from 6597112. > Given all of this, your suggestion of modifying ObjectTable.putTarget() > such that it is tolerant of being given Targets whose impl objects may > have been GC'd (ie. without it throwing an exception) seems excellent to > me. > > Please find below a (far simpler) revised suggested changeset, which > addresses the problem in this fashion. > > (NB: In the new changeset, the check for the impl having been GC'd is > now within the block synchronized on tableLock. The operation of the > Reaper thread is also performed synchronized on this lock. This ensures > that the keep alive count is incremented / decremented properly, even if > the impl happens to be GC'd after the check). > > Please let me know if you have any further comments or suggestions on > this, This fix looks good to me. The synchronization subtlety may be worth a brief comment, to explain that you don't want the Reaper processing to occur in between the null guard and the put/increment actions. Cheers, -- Peter > # HG changeset patch > # User Neil Richards , > # Date 1302196316 -3600 > # Branch j6597112 > # Node ID cfa1f7fcaabb03ab79aae8f051e4c084b45c75b9 > # Parent aa13e7702cd9d8aca9aa38f1227f966990866944 > 6597112: referential integrity loophole during remote object export > Summary: Make ObjectTable.putTarget() tolerant of Target's with a GC'd impl > Contributed-by: > > diff -r aa13e7702cd9 -r cfa1f7fcaabb src/share/classes/sun/rmi/transport/ObjectTable.java > --- a/src/share/classes/sun/rmi/transport/ObjectTable.java Tue Mar 29 20:19:55 2011 -0700 > +++ b/src/share/classes/sun/rmi/transport/ObjectTable.java Thu Apr 07 18:11:56 2011 +0100 > @@ -175,25 +175,21 @@ > DGCImpl.dgcLog.log(Log.VERBOSE, "add object " + oe); > } > > - Remote impl = target.getImpl(); > - if (impl == null) { > - throw new ExportException( > - "internal error: attempt to export collected object"); > - } > + synchronized (tableLock) { > + if (null != target.getImpl()) { > + if (objTable.containsKey(oe)) { > + throw new ExportException( > + "internal error: ObjID already in use"); > + } else if (implTable.containsKey(weakImpl)) { > + throw new ExportException("object already exported"); > + } > > - synchronized (tableLock) { > - if (objTable.containsKey(oe)) { > - throw new ExportException( > - "internal error: ObjID already in use"); > - } else if (implTable.containsKey(weakImpl)) { > - throw new ExportException("object already exported"); > - } > + objTable.put(oe, target); > + implTable.put(weakImpl, target); > > - objTable.put(oe, target); > - implTable.put(weakImpl, target); > - > - if (!target.isPermanent()) { > - incrementKeepAliveCount(); > + if (!target.isPermanent()) { > + incrementKeepAliveCount(); > + } > } > } > } From michael.x.mcmahon at oracle.com Wed Apr 13 11:33:44 2011 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 13 Apr 2011 12:33:44 +0100 Subject: Review request for 7034570 Message-ID: <4DA58A18.8080004@oracle.com> This issue occurs on some versions of Windows since we switched compiler to VC 2010. The new C runtime library requires the "SystemRoot" environment variable to be set, when launching sub-processes via Runtime.exec() or ProcessBuilder. The problem occurs in instances where the environment is specified by the caller, rather than simply inheriting (or inheriting and adding to) the environment of the parent process. The change is simple enough. We just check for the presence of "SystemRoot" in the child process's environment, and set it if it's not there. No change will be visible to the parent process. But, to avoid ambiguity, we'd like to make the change explicit with a small spec. change. http://cr.openjdk.java.net/~michaelm/7034570/webrev.1/ Thanks, Michael. From Alan.Bateman at oracle.com Wed Apr 13 11:08:48 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 13 Apr 2011 12:08:48 +0100 Subject: Request for review: 6597112: Referential integrity loophole during remote object export In-Reply-To: <6D7ED3FB-E15F-4465-AD1A-BABD4E70E63E@roundroom.net> References: <4D775A58.6010708@oracle.com> <1301000071.25581.16.camel@chalkhill> <4D9F2C58.9050404@oracle.com> <1302283069.32207.58.camel@chalkhill> <6D7ED3FB-E15F-4465-AD1A-BABD4E70E63E@roundroom.net> Message-ID: <4DA58440.5030503@oracle.com> Peter Jones wrote: > : > This fix looks good to me. The synchronization subtlety may be worth a brief comment, to explain that you don't want the Reaper processing to occur in between the null guard and the put/increment actions. > > Cheers, > > -- Peter > > Thanks Peter, thanks Neil, looks like we are almost done with this one. Neil - I did a hg import --no-commit of the last change-set that you attached, ran the RMI tests and all seems okay. I noticed a couple of minor things: 1. You had "if (null != target.getImpl())" so changed it to "if (target.getImpl() != null)" to make is consistent 2. The run method in the test had inconsistent formatting 3. I "moved" the test to test/java/rmi/server/UnicastRemoteObject/exportObject so that additional tests could be added in the future The updated webrev is here: http://cr.openjdk.java.net/~alanb/6597112/webrev/ If you are okay with this then I can push this later today. -Alan. From David.Holmes at oracle.com Wed Apr 13 11:29:52 2011 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 13 Apr 2011 21:29:52 +1000 Subject: Review request for 7034570 In-Reply-To: <4DA58A18.8080004@oracle.com> References: <4DA58A18.8080004@oracle.com> Message-ID: <4DA58930.9030100@oracle.com> Hi Michael, Michael McMahon said the following on 04/13/11 21:33: > This issue occurs on some versions of Windows since we switched compiler > to VC 2010. The new C runtime library requires the "SystemRoot" environment > variable to be set, when launching sub-processes via Runtime.exec() or > ProcessBuilder. > > The problem occurs in instances where the environment is specified by > the caller, > rather than simply inheriting (or inheriting and adding to) the > environment of the parent process. > > The change is simple enough. We just check for the presence of > "SystemRoot" in the > child process's environment, and set it if it's not there. No change > will be visible > to the parent process. But, to avoid ambiguity, we'd like to make the > change explicit with a small spec. change. Spec change seems fine to me. > http://cr.openjdk.java.net/~michaelm/7034570/webrev.1/ Is it possible to watch for the SystemRoot entry while iterating through at line 322 (ProcessEnvironment.java) instead of doing the iterative search before-hand? Or even doing the sort first and then a binary-search? Maybe the environment on windows is small enough that this isn't an issue? Also what if the parent process doesn't have SystemRoot set in its environment? Does the child just get a 'null' entry? Cheers, David > Thanks, > Michael. From Alan.Bateman at oracle.com Wed Apr 13 11:29:53 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 13 Apr 2011 12:29:53 +0100 Subject: Review request for 7034570 In-Reply-To: <4DA58A18.8080004@oracle.com> References: <4DA58A18.8080004@oracle.com> Message-ID: <4DA58931.8060007@oracle.com> Michael McMahon wrote: > This issue occurs on some versions of Windows since we switched compiler > to VC 2010. The new C runtime library requires the "SystemRoot" > environment > variable to be set, when launching sub-processes via Runtime.exec() or > ProcessBuilder. > > The problem occurs in instances where the environment is specified by > the caller, > rather than simply inheriting (or inheriting and adding to) the > environment of the parent > process. > > The change is simple enough. We just check for the presence of > "SystemRoot" in the > child process's environment, and set it if it's not there. No change > will be visible > to the parent process. But, to avoid ambiguity, we'd like to make the > change explicit > with a small spec. change. > > http://cr.openjdk.java.net/~michaelm/7034570/webrev.1/ Thanks for taking this one. Although we might be seeing this issue more frequently since moving to the newer C runtime, I'm pretty sure that not having SystemRoot in the environment has always lead to an altered state of consciousness. At one point I recall that Windows Sockets could be initialized but would fail creating sockets when this variable wasn't set, something to do with how layered service providers were located via the registry if I recall. Anyway, it's good to get this fixed. The update to the javadoc mostly looks good to me. One suggestion for ProcessBuilder.start is that "beyond those in the specified environment" doesn't quite work as the environment isn't specified to the method. How about "beyond those in the process builder's {@link #environment()}". The update to Runtime.exec looks good to me. In toEnvironmentBlock does the getenv("SystemRoot") need to be done in a privileged block (I'm just thinking of the case where you have permissions to exec the process but not read the variable). Also do you need to handle the case that it is null? It would be good to add the bugID to the list at the top of the test. -Alan. From Alan.Bateman at oracle.com Wed Apr 13 11:38:29 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 13 Apr 2011 12:38:29 +0100 Subject: Review request for 7034570 In-Reply-To: <4DA58A18.8080004@oracle.com> References: <4DA58A18.8080004@oracle.com> Message-ID: <4DA58B35.4090104@oracle.com> Michael McMahon wrote: > This issue occurs on some versions of Windows since we switched compiler > to VC 2010. The new C runtime library requires the "SystemRoot" > environment > variable to be set, when launching sub-processes via Runtime.exec() or > ProcessBuilder. > > The problem occurs in instances where the environment is specified by > the caller, > rather than simply inheriting (or inheriting and adding to) the > environment of the parent > process. > > The change is simple enough. We just check for the presence of > "SystemRoot" in the > child process's environment, and set it if it's not there. No change > will be visible > to the parent process. But, to avoid ambiguity, we'd like to make the > change explicit > with a small spec. change. > > http://cr.openjdk.java.net/~michaelm/7034570/webrev.1/ Thanks for taking this one. Although we might be seeing this issue more frequently since moving to the newer C runtime, I'm pretty sure that not having SystemRoot in the environment has always lead to an altered state of consciousness. At one point I recall that Windows Sockets could be initialized but would fail creating sockets when this variable wasn't set, something to do with how layered service providers were located via the registry if I recall. Anyway, it's good to get this fixed. The update to the javadoc mostly looks good to me. One suggestion for ProcessBuilder.start is that "beyond those in the specified environment" doesn't quite work as the environment isn't specified to the method. How about "beyond those in the process builder's {@link #environment()}". The update to Runtime.exec looks good to me. In toEnvironmentBlock does the getenv("SystemRoot") need to be done in a privileged block (I'm just thinking of the case where you have permissions to exec the process but not read the variable). Also do you need to handle the case that it is null? It would be good to add the bugID to the list at the top of the test. -Alan. From Alan.Bateman at oracle.com Wed Apr 13 12:33:57 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 13 Apr 2011 13:33:57 +0100 Subject: Constants for standard charsets -- CR #4884238 In-Reply-To: <4DA4A39A.2070209@gmx.de> References: <20110412181125.737A0818@eggemoggin.niobe.net> <8E9FA2E5-3E8E-41A4-AEC3-75EB1CBE5831@oracle.com> <4DA4A39A.2070209@gmx.de> Message-ID: <4DA59835.5030407@oracle.com> Ulf Zibis wrote: > : > > Please note my long waiting patches: > ***Bug 100091* > - No system start for file.encoding=x-SJIS_0213 > *****Bug 100092* > - Speed-up > FastCharsetProvider > *****Bug 100095* > - Avoid 2-step > lookup in sun.nio.cs charset providers > *****Bug 100098* > - Make > sun.nio.cs.* charset objects light-weight I don't know if anyone is looking at these and I don't know how up to date they are. How about re-basing them and restarting the discussion here once jdk8 has opened? It would be best to focus on a single issue at a time and separate out the reformatting of the code to a separate patch. -Alan From michael.x.mcmahon at oracle.com Wed Apr 13 14:26:29 2011 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 13 Apr 2011 15:26:29 +0100 Subject: Review request for 7034570 In-Reply-To: <4DA58930.9030100@oracle.com> References: <4DA58A18.8080004@oracle.com> <4DA58930.9030100@oracle.com> Message-ID: <4DA5B295.1000508@oracle.com> David Holmes wrote: > > Spec change seems fine to me. > >> http://cr.openjdk.java.net/~michaelm/7034570/webrev.1/ > > Is it possible to watch for the SystemRoot entry while iterating > through at line 322 (ProcessEnvironment.java) instead of doing the > iterative search before-hand? Or even doing the sort first and then a > binary-search? Maybe the environment on windows is small enough that > this isn't an issue? > Originally, I thought that wouldn't work due to the case-insensitivity of the names. You could get the name as "SYSTEMROOT" or "SysTeMRoOt" for example. But, thinking about it again, I could compareToIgnoreCase() with whatever variant is lexicographically last ( "systemroot" I think) and considering the list is already sorted, if we encounter a name that is greater than "systemroot", we know it's not there. It's still the same number of comparisons, but only one loop. > Also what if the parent process doesn't have SystemRoot set in its > environment? Does the child just get a 'null' entry? > Yes, it's probably better not to set it at all, in the event that SystemRoot is not set in the parent. Thanks, Michael. From michael.x.mcmahon at oracle.com Wed Apr 13 14:33:12 2011 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 13 Apr 2011 15:33:12 +0100 Subject: Review request for 7034570 In-Reply-To: <4DA58931.8060007@oracle.com> References: <4DA58A18.8080004@oracle.com> <4DA58931.8060007@oracle.com> Message-ID: <4DA5B428.4040508@oracle.com> Alan Bateman wrote: > Michael McMahon wrote: >> This issue occurs on some versions of Windows since we switched compiler >> to VC 2010. The new C runtime library requires the "SystemRoot" >> environment >> variable to be set, when launching sub-processes via Runtime.exec() >> or ProcessBuilder. >> >> The problem occurs in instances where the environment is specified by >> the caller, >> rather than simply inheriting (or inheriting and adding to) the >> environment of the parent >> process. >> >> The change is simple enough. We just check for the presence of >> "SystemRoot" in the >> child process's environment, and set it if it's not there. No change >> will be visible >> to the parent process. But, to avoid ambiguity, we'd like to make the >> change explicit >> with a small spec. change. >> >> http://cr.openjdk.java.net/~michaelm/7034570/webrev.1/ > Thanks for taking this one. Although we might be seeing this issue > more frequently since moving to the newer C runtime, I'm pretty sure > that not having SystemRoot in the environment has always lead to an > altered state of consciousness. At one point I recall that Windows > Sockets could be initialized but would fail creating sockets when this > variable wasn't set, something to do with how layered service > providers were located via the registry if I recall. > > Anyway, it's good to get this fixed. The update to the javadoc mostly > looks good to me. One suggestion for ProcessBuilder.start is that > "beyond those in the specified environment" doesn't quite work as the > environment isn't specified to the method. How about "beyond those in > the process builder's {@link #environment()}". The update to > Runtime.exec looks good to me. > Ok. > In toEnvironmentBlock does the getenv("SystemRoot") need to be done in > a privileged block (I'm just thinking of the case where you have > permissions to exec the process but not read the variable). Also do > you need to handle the case that it is null? > The permission check happens at a higher level. We're dealing directly with the data at this level. So, we don't need a privileged block. Yes, the null case needs to be distinguished. I'll send another webrev soon. Thanks, Michael. From Alan.Bateman at oracle.com Wed Apr 13 13:54:53 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 13 Apr 2011 14:54:53 +0100 Subject: Review request for 7034570 In-Reply-To: <4DA5B428.4040508@oracle.com> References: <4DA58A18.8080004@oracle.com> <4DA58931.8060007@oracle.com> <4DA5B428.4040508@oracle.com> Message-ID: <4DA5AB2D.9040200@oracle.com> Michael McMahon wrote: > : >> In toEnvironmentBlock does the getenv("SystemRoot") need to be done >> in a privileged block (I'm just thinking of the case where you have >> permissions to exec the process but not read the variable). Also do >> you need to handle the case that it is null? >> > The permission check happens at a higher level. We're dealing directly > with the data at this level. > So, we don't need a privileged block. Do you mind checking it? I'm pretty sure there will be caller frames on the stack that aren't in the null protection domain and so getenv will fail with a security exception if there isn't permission to read it. -Alan. From pcj at roundroom.net Wed Apr 13 14:08:05 2011 From: pcj at roundroom.net (Peter Jones) Date: Wed, 13 Apr 2011 10:08:05 -0400 Subject: Request for review: 6597112: Referential integrity loophole during remote object export In-Reply-To: <4DA58440.5030503@oracle.com> References: <4D775A58.6010708@oracle.com> <1301000071.25581.16.camel@chalkhill> <4D9F2C58.9050404@oracle.com> <1302283069.32207.58.camel@chalkhill> <6D7ED3FB-E15F-4465-AD1A-BABD4E70E63E@roundroom.net> <4DA58440.5030503@oracle.com> Message-ID: <7ADBF8F9-C662-4EB3-B270-3412E8F13379@roundroom.net> On Apr 13, 2011, at 7:08 AM, Alan Bateman wrote: > Peter Jones wrote: >> : >> This fix looks good to me. The synchronization subtlety may be worth a brief comment, to explain that you don't want the Reaper processing to occur in between the null guard and the put/increment actions. >> >> Cheers, >> >> -- Peter >> >> > Thanks Peter, thanks Neil, looks like we are almost done with this one. > > Neil - I did a hg import --no-commit of the last change-set that you attached, ran the RMI tests and all seems okay. I noticed a couple of minor things: > > 1. You had "if (null != target.getImpl())" so changed it to "if (target.getImpl() != null)" to make is consistent > 2. The run method in the test had inconsistent formatting > 3. I "moved" the test to test/java/rmi/server/UnicastRemoteObject/exportObject so that additional tests could be added in the future > > The updated webrev is here: > http://cr.openjdk.java.net/~alanb/6597112/webrev/ > > If you are okay with this then I can push this later today. > > -Alan. Alan, Your webrev looks good to me-- my only suggestion would be to add a comment explaining the null check. Here are some suggested words: Do nothing if impl has already been collected (see 6597112). Check while holding tableLock to ensure that Reaper cannot process weakImpl in between null check and put/increment effects. -- Peter From Lance.Andersen at oracle.com Wed Apr 13 14:18:51 2011 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Wed, 13 Apr 2011 10:18:51 -0400 Subject: Review needed for 7036251, clarification to SQLPermission Constructors Message-ID: <3C84B886-C2F3-4407-913B-AC74D26A4303@oracle.com> HI all, Need a reviewer for this minor update to the SQLPermission constructors which I missed when I added the updates for the new permission target names. Thank you. Regards, Lance hg diff diff -r 0bae251b548b src/share/classes/java/sql/SQLPermission.java --- a/src/share/classes/java/sql/SQLPermission.java Tue Apr 12 14:32:03 2011 -0400 +++ b/src/share/classes/java/sql/SQLPermission.java Tue Apr 12 15:42:16 2011 -0400 @@ -116,11 +116,11 @@ /** * Creates a new SQLPermission object with the specified name. - * The name is the symbolic name of the SQLPermission; currently, - * the only name allowed is "setLog". + * The name is the symbolic name of the SQLPermission. * * @param name the name of this SQLPermission object, which must - * be setLog + * be either {@code setLog}, {@code callAbort}, {@code setSyncFactory}, + * or {@code setNetworkTimeout} * @throws NullPointerException if name is null. * @throws IllegalArgumentException if name is empty. @@ -134,10 +134,11 @@ * Creates a new SQLPermission object with the specified name. * The name is the symbolic name of the SQLPermission; the * actions String is currently unused and should be - * null. + * null. * * @param name the name of this SQLPermission object, which must - * be setLog + * be either {@code setLog}, {@code callAbort}, {@code setSyncFactory}, + * or {@code setNetworkTimeout} * @param actions should be null * @throws NullPointerException if name is null. * @throws IllegalArgumentException if name is empty. Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From Ulf.Zibis at gmx.de Wed Apr 13 14:20:21 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Wed, 13 Apr 2011 16:20:21 +0200 Subject: Review request for 7034570 - java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited In-Reply-To: <4DA58A18.8080004@oracle.com> References: <4DA58A18.8080004@oracle.com> Message-ID: <4DA5B125.7030707@gmx.de> First: please add some more description to the subject line. ProcessEnvironment : Line 146: There is a superfluous space between 'checkedEntry' and '(Object o)'. Instead of suppressing the warnings, we could code: public boolean contains(Map.Entry o) {return s.contains(checkedEntry(o));} public boolean remove(Map.Entry o) {return s.remove(checkedEntry(o));} Maybe we could generify the whole inner class against CheckedEntry: private static class CheckedEntrySet extends AbstractSet { I don't know why we need the environment block sorted, but I think, we could use a SortedSet from the beginning instead of sorting a normal Set later. Iterating over the List list should be faster than iterating over the Set entries to find the "SystemRoot". Additionally I guess, TreeSet should be faster than HashSet for such few entries. Anyway, what about: 305 EnsureSystemRoot: { 306 final String SR = "SystemRoot"; 307 for (Map.Entry entry : list) { 308 if (entry.getKey().equalsIgnoreCase(SR)) 309 break EnsureSystemRoot; 310 } 311 list.add(new AbstractMap.SimpleEntry(SR, getenv(SR))); 312 } 318 We do not have to iterate twice, to find the "SystemRoot". We could insert the missing value while filling the StringBuilder If we would generally uppercase the entries by put(), we wouldn't have to scan each entry by equalsIgnoreCase() to find the "SystemRoot". We simply could use entries.contains("SYSTEMROOT") -Ulf Am 13.04.2011 13:33, schrieb Michael McMahon: > This issue occurs on some versions of Windows since we switched compiler > to VC 2010. The new C runtime library requires the "SystemRoot" environment > variable to be set, when launching sub-processes via Runtime.exec() or ProcessBuilder. > > The problem occurs in instances where the environment is specified by the caller, > rather than simply inheriting (or inheriting and adding to) the environment of the parent > process. > > The change is simple enough. We just check for the presence of "SystemRoot" in the > child process's environment, and set it if it's not there. No change will be visible > to the parent process. But, to avoid ambiguity, we'd like to make the change explicit > with a small spec. change. > > http://cr.openjdk.java.net/~michaelm/7034570/webrev.1/ > > Thanks, > Michael. > From Alan.Bateman at oracle.com Wed Apr 13 14:39:10 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 13 Apr 2011 15:39:10 +0100 Subject: Review needed for 7036251, clarification to SQLPermission Constructors In-Reply-To: <3C84B886-C2F3-4407-913B-AC74D26A4303@oracle.com> References: <3C84B886-C2F3-4407-913B-AC74D26A4303@oracle.com> Message-ID: <4DA5B58E.3090108@oracle.com> Lance Andersen - Oracle wrote: > HI all, > > Need a reviewer for this minor update to the SQLPermission constructors which I missed when I added the updates for the new permission target names. > > Looks okay to me. I assume at some point it would be good to migrate this javadoc to using the @code tag. -Alan. From Lance.Andersen at oracle.com Wed Apr 13 14:45:21 2011 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Wed, 13 Apr 2011 10:45:21 -0400 Subject: Review needed for 7036251, clarification to SQLPermission Constructors In-Reply-To: <4DA5B58E.3090108@oracle.com> References: <3C84B886-C2F3-4407-913B-AC74D26A4303@oracle.com> <4DA5B58E.3090108@oracle.com> Message-ID: Hi Alan, thank you. Yes I will be going through all of JDBC to clean up the java docs in the coming weeks. Regards, lance On Apr 13, 2011, at 10:39 AM, Alan Bateman wrote: > Lance Andersen - Oracle wrote: >> HI all, >> >> Need a reviewer for this minor update to the SQLPermission constructors which I missed when I added the updates for the new permission target names. >> >> > Looks okay to me. I assume at some point it would be good to migrate this javadoc to using the @code tag. > > -Alan. > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From Alan.Bateman at oracle.com Wed Apr 13 14:54:58 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 13 Apr 2011 15:54:58 +0100 Subject: advice & review requested for 6896297, race condition in rmid causing JCK failure In-Reply-To: <4DA4CD6B.8000209@oracle.com> References: <4D9E3867.7030004@oracle.com> <4DA31453.2020408@oracle.com> <4DA4CD6B.8000209@oracle.com> Message-ID: <4DA5B942.3010706@oracle.com> Stuart Marks wrote: > : > > The key issue seems to be whether we want to preserve compatibility of > the serialized form. If we care about compatibility of the serialized > form, #3 is probably the safest. If somebody comes along and tells us > that we don't have to worry about serial compatibility of this stuff > at all, then #1 is probably the best since it simplifies the code a lot. I think (and Peter can say for sure) that the compatibility issue is really only for the case that rmid needs to recover from an existing log file. Without more insight then I tend to agree that #3 is the best for now. -Alan. From spoole at linux.vnet.ibm.com Wed Apr 13 15:19:22 2011 From: spoole at linux.vnet.ibm.com (Steve Poole) Date: Wed, 13 Apr 2011 16:19:22 +0100 Subject: Suspected regression: fix for 6735255 causes delay in GC of ZipFile InputStreams, increase in heap demand In-Reply-To: <4DA4A8EF.4060103@oracle.com> References: <1300916786.4515.107.camel@chalkhill> <4D922D68.2080202@oracle.com> <1301514810.24605.64.camel@chalkhill> <4D93930A.2000604@oracle.com> <1301676177.24605.165.camel@chalkhill> <4D962275.7010601@oracle.com> <4D965D14.6060504@oracle.com> <1301707718.14323.43.camel@chalkhill> <4D98FD10.4090608@oracle.com> <1302183023.27698.20.camel@chalkhill> <4D9E429F.9030200@oracle.com> <1302266193.17745.18.camel@chalkhill> <4D9FD836.1070909@oracle.com> <1302456482.18865.109.camel@chalkhill> <1302524116.15253.25.camel@chalkhill> <4DA4A8EF.4060103@oracle.com> Message-ID: <4DA5BEFA.30707@linux.vnet.ibm.com> On 12/04/11 20:33, Xueming Shen wrote: > Hi Neil, Hi Sherman , Neil is out on vacation so I will do my best to stand in for him. > > (1) I believe it would be better to keep the synchronization lock for > get/releaseInfalter() > "local" instead of using the "global" ZipFile.this, which I agree > is "simple". But it also > means each/every time when you release the used inflater back to > cache, ZipFile.this > has to be held and any possible/potential read operation on > ZipFile from other thead/ > inputstream has to wait ("get" seems fine, the current impl holds > the ZipFile.this > anyway before reach the getInflater()). Ok - I agree - seems sensible. (Though I reserve the right to contradict myself later) > > (2) The "resource" Infalter mainly holds is the native memory block it > alloc-ed at native > for zlib, which is not in the Java heap, so I doubt making it > "softly" really helps for GC. > Sure, cleanup of those "objects" themself is a plus, but I'm not > sure if it is really worth > using SoftReference in this case (it appears you are now invoking > clearStaleStreams() > from the finalize()). I'd like to keep this in - not all implementations of zlib are equal in where they allocate memory. > > (3) The releaseInfalter() is now totally driven from > clearStaleStreams()/staleStreamQueue, > which is under full control of GC. If GC does not kick in for > hours/days, infalters can never > be put back into its cache after use, even the applications > correctly/promptly close those > streams after use. And when the GC kicks in, we might see "bunch" > (hundreds, thousands) > of inflaters get pushed into cache. The approach does solve the > "timing" issue that got > us here, but it also now has this "native memory cache" mechanism > totally under the > control of/driven by the GC, the java heap management mechanism, > which might not be > a preferred scenario. Just wonder if we can have a better choice, > say with this GC-driven > as the backup cleanup and meanwhile still have the ZFIIS.close() > to do something to safely > put the used inflater back to cache promptly. To put the infalter > as the value of the "streams" > map appears to be a good idea/start, now the "infalter" will not > be targeted for finalized > until the entry gets cleaned from the map, in which might in fact > provide us a sort of > "orderly" (between the "stream" and its "inflater") clearup that > the GC/finalizer can't > guarantee. We still have couple days before we hit the "deadline" > (to get this one in), so it > might worth taking some time on this direction? > What is this "deadline" you are talking about? > -Sherman > > > > > > On 04/11/2011 05:15 AM, Neil Richards wrote: >> On Sun, 2011-04-10 at 18:28 +0100, Neil Richards wrote: >>> With releaseInflater() being driven from the cleanup of stale 'streams' >>> entries, it no longer needs to be called from ZFIIS.close(), so, >>> instead, only Inflater.reset() is called from there (providing the >>> inflater object has not explicitly been ended) so that it releases the >>> buffer it has been holding. >> Actually, I have a slight change of heart on this aspect. >> >> Because close() may be driven from a finalize() method in user code (as >> is done in the InflaterFinalizer test case), I believe it is possible >> (albeit unlikely) for an inflater object to have been reclaimed from >> 'streams' (by a call to clearStaleStreams()), put into the inflater >> cache, retrieved from there (by another thread creating an input stream) >> and having started to be used by that other stream at the point at which >> the code in close() is run. >> >> (This is because weak references will be cleared, and *may* be queued on >> the ReferenceQueue, prior to finalization). >> >> Because of this, it's not actually entirely safe now to call inf.reset() >> from ZFIIS.close(). >> >> Instead, I have added additional calls to clearStaleStreams() from the >> finalize() methods of both InputStream implementations in the latest >> (hopefully in the meaning of "last") changeset included below. >> >> As always, please get back to me with any comments, questions or >> suggestions on this, >> Thanks, >> Neil >> > From lance.andersen at oracle.com Wed Apr 13 15:22:07 2011 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Wed, 13 Apr 2011 15:22:07 +0000 Subject: hg: jdk7/tl/jdk: 7036251: Correct SQLPermission constructor javadocs for permission target names Message-ID: <20110413152220.372FC47A4A@hg.openjdk.java.net> Changeset: d9248245a88c Author: lancea Date: 2011-04-13 11:21 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d9248245a88c 7036251: Correct SQLPermission constructor javadocs for permission target names Reviewed-by: alanb ! src/share/classes/java/sql/SQLPermission.java From spoole at linux.vnet.ibm.com Wed Apr 13 15:25:06 2011 From: spoole at linux.vnet.ibm.com (Steve Poole) Date: Wed, 13 Apr 2011 16:25:06 +0100 Subject: Suspected regression: fix for 6735255 causes delay in GC of ZipFile InputStreams, increase in heap demand In-Reply-To: <4DA5BEFA.30707@linux.vnet.ibm.com> References: <1300916786.4515.107.camel@chalkhill> <4D922D68.2080202@oracle.com> <1301514810.24605.64.camel@chalkhill> <4D93930A.2000604@oracle.com> <1301676177.24605.165.camel@chalkhill> <4D962275.7010601@oracle.com> <4D965D14.6060504@oracle.com> <1301707718.14323.43.camel@chalkhill> <4D98FD10.4090608@oracle.com> <1302183023.27698.20.camel@chalkhill> <4D9E429F.9030200@oracle.com> <1302266193.17745.18.camel@chalkhill> <4D9FD836.1070909@oracle.com> <1302456482.18865.109.camel@chalkhill> <1302524116.15253.25.camel@chalkhill> <4DA4A8EF.4060103@oracle.com> <4DA5BEFA.30707@linux.vnet.ibm.com> Message-ID: <4DA5C052.6030500@linux.vnet.ibm.com> On 13/04/11 16:19, Steve Poole wrote: > On 12/04/11 20:33, Xueming Shen wrote: >> Hi Neil, > > > Hi Sherman , Neil is out on vacation so I will do my best to stand > in for him. >> >> (1) I believe it would be better to keep the synchronization lock for >> get/releaseInfalter() >> "local" instead of using the "global" ZipFile.this, which I >> agree is "simple". But it also >> means each/every time when you release the used inflater back to >> cache, ZipFile.this >> has to be held and any possible/potential read operation on >> ZipFile from other thead/ >> inputstream has to wait ("get" seems fine, the current impl >> holds the ZipFile.this >> anyway before reach the getInflater()). > Ok - I agree - seems sensible. (Though I reserve the right to > contradict myself later) >> >> (2) The "resource" Infalter mainly holds is the native memory block >> it alloc-ed at native >> for zlib, which is not in the Java heap, so I doubt making it >> "softly" really helps for GC. >> Sure, cleanup of those "objects" themself is a plus, but I'm not >> sure if it is really worth >> using SoftReference in this case (it appears you are now >> invoking clearStaleStreams() >> from the finalize()). > I'd like to keep this in - not all implementations of zlib are equal > in where they allocate memory. >> >> (3) The releaseInfalter() is now totally driven from >> clearStaleStreams()/staleStreamQueue, >> which is under full control of GC. If GC does not kick in for >> hours/days, infalters can never >> be put back into its cache after use, even the applications >> correctly/promptly close those >> streams after use. And when the GC kicks in, we might see >> "bunch" (hundreds, thousands) >> of inflaters get pushed into cache. The approach does solve the >> "timing" issue that got >> us here, but it also now has this "native memory cache" >> mechanism totally under the >> control of/driven by the GC, the java heap management mechanism, >> which might not be >> a preferred scenario. Just wonder if we can have a better >> choice, say with this GC-driven >> as the backup cleanup and meanwhile still have the ZFIIS.close() >> to do something to safely >> put the used inflater back to cache promptly. To put the >> infalter as the value of the "streams" >> map appears to be a good idea/start, now the "infalter" will not >> be targeted for finalized >> until the entry gets cleaned from the map, in which might in >> fact provide us a sort of >> "orderly" (between the "stream" and its "inflater") clearup that >> the GC/finalizer can't >> guarantee. We still have couple days before we hit the >> "deadline" (to get this one in), so it >> might worth taking some time on this direction? >> Dang! - pressed send when I meant save. I understand your comments - on the face of it I agree with what you're suggesting - let me think it through some more though. > What is this "deadline" you are talking about? > >> -Sherman >> >> >> >> >> >> On 04/11/2011 05:15 AM, Neil Richards wrote: >>> On Sun, 2011-04-10 at 18:28 +0100, Neil Richards wrote: >>>> With releaseInflater() being driven from the cleanup of stale >>>> 'streams' >>>> entries, it no longer needs to be called from ZFIIS.close(), so, >>>> instead, only Inflater.reset() is called from there (providing the >>>> inflater object has not explicitly been ended) so that it releases the >>>> buffer it has been holding. >>> Actually, I have a slight change of heart on this aspect. >>> >>> Because close() may be driven from a finalize() method in user code (as >>> is done in the InflaterFinalizer test case), I believe it is possible >>> (albeit unlikely) for an inflater object to have been reclaimed from >>> 'streams' (by a call to clearStaleStreams()), put into the inflater >>> cache, retrieved from there (by another thread creating an input >>> stream) >>> and having started to be used by that other stream at the point at >>> which >>> the code in close() is run. >>> >>> (This is because weak references will be cleared, and *may* be >>> queued on >>> the ReferenceQueue, prior to finalization). >>> >>> Because of this, it's not actually entirely safe now to call >>> inf.reset() >>> from ZFIIS.close(). >>> >>> Instead, I have added additional calls to clearStaleStreams() from the >>> finalize() methods of both InputStream implementations in the latest >>> (hopefully in the meaning of "last") changeset included below. >>> >>> As always, please get back to me with any comments, questions or >>> suggestions on this, >>> Thanks, >>> Neil >>> >> > From Ulf.Zibis at gmx.de Wed Apr 13 15:55:31 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Wed, 13 Apr 2011 17:55:31 +0200 Subject: Constants for standard charsets -- CR #4884238 In-Reply-To: <4DA59835.5030407@oracle.com> References: <20110412181125.737A0818@eggemoggin.niobe.net> <8E9FA2E5-3E8E-41A4-AEC3-75EB1CBE5831@oracle.com> <4DA4A39A.2070209@gmx.de> <4DA59835.5030407@oracle.com> Message-ID: <4DA5C773.2040601@gmx.de> Am 13.04.2011 14:33, schrieb Alan Bateman: > Ulf Zibis wrote: >> : >> >> Please note my long waiting patches: >> ***Bug 100091* - No system start for >> file.encoding=x-SJIS_0213 >> *****Bug 100092* - Speed-up >> FastCharsetProvider >> *****Bug 100095* - Avoid 2-step lookup in >> sun.nio.cs charset providers >> *****Bug 100098* - Make sun.nio.cs.* >> charset objects light-weight > I don't know if anyone is looking at these and I don't know how up to date they are. How about > re-basing them and restarting the discussion here once jdk8 has opened? It would be best to focus > on a single issue at a time and separate out the reformatting of the code to a separate patch. > Yes, but if we have added the Charsets class to JDK-7 we can't remove it later. Is CR #4884238 essential for JDK-7 ? I think we can too move this CR to JDK-8, so we wouldn't miss the advantages of my proposed changes, or we could add the constants to the existing Charset class. I still think, initializing those 6 simple charsets is nothing against initializing Charset class, which happens anyway at system start, and even less after integrating ***Bug 100098* - Make sun.nio.cs.* charset objects light-weight. In this change, the then light-weight charset objects (each of same class in contrary to today's one separate class per charset) are directly initialized in the Charset's lookup map instead their canonical String names, so lookup would become very fast, and the huge mapping data of some charsets would get cached by SoftReference, which actually doesn't hold on today's approach. -Ulf From chris.hegarty at oracle.com Wed Apr 13 15:58:10 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 13 Apr 2011 16:58:10 +0100 Subject: Fwd: [concurrency-interest] ConcurrentHashMap footprint and contention improvements In-Reply-To: <4DA4EA8E.6070506@cs.oswego.edu> References: <4DA4EA8E.6070506@cs.oswego.edu> Message-ID: <4DA5C812.4080408@oracle.com> Doug, This change does appear worthwhile. We have a narrowing window of opportunity for JDK7. I spoke to Alan Bateman about this and we feel that if we could finalize the JDK7 changes by next Monday (that is, get them in for JDK7 b140), this would give us a reasonable time for them to soak before it gets harder to get changes into 7. Do you think this is a reasonable time frame? Do you expect any more implementation changes than what you have today? -Chris On 04/13/11 01:13 AM, Doug Lea wrote: > > Members of this list are also invited to check this out. > I'm not sure if it will make Java7 schedule, but the > improvements seem worthwhile given the increased > use of ConcurrentHashMap inside the JDK (including > multiple tables per class loader in JDK7.) > > -Doug > > > > -------- Original Message -------- > Subject: [concurrency-interest] ConcurrentHashMap footprint and > contention improvements > Date: Tue, 12 Apr 2011 20:07:17 -0400 > From: Doug Lea
> To: Concurrency-interest at cs.oswego.edu > > > For years, we've known that ConcurrentHashMaps have initial > footprints (over 1000 bytes using default constructor) that > are too big for casual use. And that the best way to address > this would be to use the Fences API to emulate "final field" > memory model guarantees in the presence of lazy initialization. > But we aren't releasing the Fences API. So I committed a version > that instead uses Unsafe calls to essentially the same effect > (reducing initial footprint to around 100 bytes, plus a few > percent savings for large populated tables). Also, this > version includes throughput improvements under contention > (mainly by interleaving locking with probes, to absorb cache misses), > which can double performance on big tables with many threads. > While conceptually straightforward, these lead to many > line-of-code changes. > > The main price paid for these improvements is a greater reliance > of "volatile" vs "final" reads, which are essentially equivalent > in cost on most machines, but can be more costly on ARM and POWER. > Even on these though, the net effect should be positive. > > It would be helpful if members of this list could help check > that this is so. The committed version is now > in java.util.concurrent sources (at > http://gee.cs.oswego.edu/dl/concurrency-interest/index.html) > and can be run by getting jsr166.jar and using > "java -Xbootclasspath/p:jsr166.jar" with any java7 build > or binary (http://dlc.sun.com.edgesuite.net/jdk7/binaries/index.html). > Also, as an alternative, I temporarily placed an unpackaged > source version (with the class renamed "CHM") > at http://gee.cs.oswego.edu/dl/wwwtmp/CHM.java > You can compile and somehow run in any java6/7 JVM. > > While working on these changes, I also contemplated other > more extensive redesigns, including Cliff Click's non-blocking > version (http://sourceforge.net/projects/high-scale-lib/) > which usually has better scalability with large numbers > of threads solely using get and put, but not otherwise > uniformly a better choice. > > -Doug > > _______________________________________________ > Concurrency-interest mailing list > Concurrency-interest at cs.oswego.edu > http://cs.oswego.edu/mailman/listinfo/concurrency-interest > From michael.x.mcmahon at oracle.com Wed Apr 13 16:20:03 2011 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 13 Apr 2011 17:20:03 +0100 Subject: Review request for 7034570 - java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited In-Reply-To: <4DA5B125.7030707@gmx.de> References: <4DA58A18.8080004@oracle.com> <4DA5B125.7030707@gmx.de> Message-ID: <4DA5CD33.50609@oracle.com> Ulf, Thanks for the comments. I think I will remove the @SuppressWarning for now, and we can look at generifying CheckedEntrySet another time. The environment block is required to be sorted when you call CreateProcess() on Windows. Yes, as per the earlier message to David Holmes, I'm looking at iterating once over the list (rather than the Set). Lastly, even though environment variables are case-insensitive on Windows, it does "remember" the case that was used (rather than normalising the names to uppercase or whatever). Java has always treated them as case-sensitive. So, I don't think we can convert the names to uppercase. - Michael. On 13/04/2011 15:20, Ulf Zibis wrote: > First: please add some more description to the subject line. > > ProcessEnvironment : > > Line 146: There is a superfluous space between 'checkedEntry' and > '(Object o)'. > > Instead of suppressing the warnings, we could code: > public boolean contains(Map.Entry o) {return > s.contains(checkedEntry(o));} > public boolean remove(Map.Entry o) {return > s.remove(checkedEntry(o));} > > Maybe we could generify the whole inner class against CheckedEntry: > private static class CheckedEntrySet extends > AbstractSet { > > I don't know why we need the environment block sorted, but I think, we > could use a SortedSet from the beginning instead of sorting a normal > Set later. > > Iterating over the List list should be faster than iterating over the > Set entries to find the "SystemRoot". > Additionally I guess, TreeSet should be faster than HashSet for such > few entries. > > Anyway, what about: > 305 EnsureSystemRoot: { > 306 final String SR = "SystemRoot"; > 307 for (Map.Entry entry : list) { > 308 if (entry.getKey().equalsIgnoreCase(SR)) > 309 break EnsureSystemRoot; > 310 } > 311 list.add(new > AbstractMap.SimpleEntry(SR, getenv(SR))); > 312 } > 318 > > We do not have to iterate twice, to find the "SystemRoot". We could > insert the missing value while filling the StringBuilder > > If we would generally uppercase the entries by put(), we wouldn't have > to scan each entry by equalsIgnoreCase() to find the "SystemRoot". We > simply could use entries.contains("SYSTEMROOT") > > -Ulf > > > Am 13.04.2011 13:33, schrieb Michael McMahon: >> This issue occurs on some versions of Windows since we switched compiler >> to VC 2010. The new C runtime library requires the "SystemRoot" >> environment >> variable to be set, when launching sub-processes via Runtime.exec() >> or ProcessBuilder. >> >> The problem occurs in instances where the environment is specified by >> the caller, >> rather than simply inheriting (or inheriting and adding to) the >> environment of the parent >> process. >> >> The change is simple enough. We just check for the presence of >> "SystemRoot" in the >> child process's environment, and set it if it's not there. No change >> will be visible >> to the parent process. But, to avoid ambiguity, we'd like to make the >> change explicit >> with a small spec. change. >> >> http://cr.openjdk.java.net/~michaelm/7034570/webrev.1/ >> >> Thanks, >> Michael. >> From Alan.Bateman at oracle.com Wed Apr 13 17:21:48 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 13 Apr 2011 18:21:48 +0100 Subject: Fwd: [concurrency-interest] ConcurrentHashMap footprint and contention improvements In-Reply-To: <4DA5C812.4080408@oracle.com> References: <4DA4EA8E.6070506@cs.oswego.edu> <4DA5C812.4080408@oracle.com> Message-ID: <4DA5DBAC.2050400@oracle.com> Chris Hegarty wrote: > Doug, > > This change does appear worthwhile. We have a narrowing window of > opportunity for JDK7. I spoke to Alan Bateman about this and we feel > that if we could finalize the JDK7 changes by next Monday (that is, > get them in for JDK7 b140), this would give us a reasonable time for > them to soak before it gets harder to get changes into 7. > > Do you think this is a reasonable time frame? Do you expect any more > implementation changes than what you have today? > > -Chris I don't think there is any harm trying but we should run as many tests and applications as possible. I saw Doug's mail to concurrency-interest and hopefully folks will report back their experiences with real applications in a timely manner. -Alan. From alan.bateman at oracle.com Wed Apr 13 17:41:37 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 13 Apr 2011 17:41:37 +0000 Subject: hg: jdk7/tl/jdk: 6597112: referential integrity loophole during remote object export Message-ID: <20110413174147.551E847A53@hg.openjdk.java.net> Changeset: c0602036be5d Author: alanb Date: 2011-04-13 18:39 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c0602036be5d 6597112: referential integrity loophole during remote object export Reviewed-by: peterjones Contributed-by: Neil Richards ! src/share/classes/sun/rmi/transport/ObjectTable.java + test/java/rmi/server/UnicastRemoteObject/exportObject/GcDuringExport.java From bradford.wetmore at oracle.com Wed Apr 13 18:54:26 2011 From: bradford.wetmore at oracle.com (bradford.wetmore at oracle.com) Date: Wed, 13 Apr 2011 18:54:26 +0000 Subject: hg: jdk7/tl/jdk: 6914617: JCE framework code signing certificate is expiring at the end of 2010. Message-ID: <20110413185436.2F96747A57@hg.openjdk.java.net> Changeset: 29e88b0c0894 Author: wetmore Date: 2011-04-13 11:36 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/29e88b0c0894 6914617: JCE framework code signing certificate is expiring at the end of 2010. Reviewed-by: valeriep, weijun, mullan ! make/javax/crypto/Defs-jce.gmk From bradford.wetmore at oracle.com Wed Apr 13 19:11:38 2011 From: bradford.wetmore at oracle.com (bradford.wetmore at oracle.com) Date: Wed, 13 Apr 2011 19:11:38 +0000 Subject: hg: jdk7/tl/jdk: 7031343: Provide API changes to support future GCM AEAD ciphers Message-ID: <20110413191148.A509F47A58@hg.openjdk.java.net> Changeset: 13af7c12c62a Author: wetmore Date: 2011-04-13 11:59 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/13af7c12c62a 7031343: Provide API changes to support future GCM AEAD ciphers Reviewed-by: valeriep, xuelei + src/share/classes/javax/crypto/AEADBadTagException.java ! src/share/classes/javax/crypto/Cipher.java ! src/share/classes/javax/crypto/CipherSpi.java + src/share/classes/javax/crypto/spec/GCMParameterSpec.java + test/javax/crypto/Cipher/GCMAPI.java + test/javax/crypto/spec/GCMParameterSpec/GCMParameterSpecTest.java From xueming.shen at oracle.com Wed Apr 13 19:22:24 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 13 Apr 2011 12:22:24 -0700 Subject: Suspected regression: fix for 6735255 causes delay in GC of ZipFile InputStreams, increase in heap demand In-Reply-To: <4DA5C052.6030500@linux.vnet.ibm.com> References: <1300916786.4515.107.camel@chalkhill> <4D922D68.2080202@oracle.com> <1301514810.24605.64.camel@chalkhill> <4D93930A.2000604@oracle.com> <1301676177.24605.165.camel@chalkhill> <4D962275.7010601@oracle.com> <4D965D14.6060504@oracle.com> <1301707718.14323.43.camel@chalkhill> <4D98FD10.4090608@oracle.com> <1302183023.27698.20.camel@chalkhill> <4D9E429F.9030200@oracle.com> <1302266193.17745.18.camel@chalkhill> <4D9FD836.1070909@oracle.com> <1302456482.18865.109.camel@chalkhill> <1302524116.15253.25.camel@chalkhill> <4DA4A8EF.4060103@oracle.com> <4DA5BEFA.30707@linux.vnet.ibm.com> <4DA5C052.6030500@linux.vnet.ibm.com> Message-ID: <4DA5F7F0.9070601@oracle.com> On 04/13/2011 08:25 AM, Steve Poole wrote: > On 13/04/11 16:19, Steve Poole wrote: >> On 12/04/11 20:33, Xueming Shen wrote: >>> Hi Neil, >> >> >> Hi Sherman , Neil is out on vacation so I will do my best to stand >> in for him. >>> >>> (1) I believe it would be better to keep the synchronization lock >>> for get/releaseInfalter() >>> "local" instead of using the "global" ZipFile.this, which I >>> agree is "simple". But it also >>> means each/every time when you release the used inflater back >>> to cache, ZipFile.this >>> has to be held and any possible/potential read operation on >>> ZipFile from other thead/ >>> inputstream has to wait ("get" seems fine, the current impl >>> holds the ZipFile.this >>> anyway before reach the getInflater()). >> Ok - I agree - seems sensible. (Though I reserve the right to >> contradict myself later) >>> >>> (2) The "resource" Infalter mainly holds is the native memory block >>> it alloc-ed at native >>> for zlib, which is not in the Java heap, so I doubt making it >>> "softly" really helps for GC. >>> Sure, cleanup of those "objects" themself is a plus, but I'm >>> not sure if it is really worth >>> using SoftReference in this case (it appears you are now >>> invoking clearStaleStreams() >>> from the finalize()). >> I'd like to keep this in - not all implementations of zlib are equal >> in where they allocate memory. Hi Steve, It might be better/appropriate to use the SoftReference in the "inflaterCache" instead of the "streams", if we want to use the SoftReference for inflater caching purpose. /* * Gets an inflater from the list of available inflaters or allocates * a new one. */ private synchronized Inflater getInflater() { SoftReference sref; Inflater inf; while (null != (sref = inflaterCache.poll())) { if ((inf = sref.get()) != null && !inf.ended()) { return inf; } } return new Inflater(true); } /* * Releases the specified inflater to the list of available inflaters. */ private synchronized void releaseInflater(Inflater inf) { if ((null != inf) && (false == inf.ended())) { inf.reset(); inflaterCache.add(new SoftReference(inf)); } } // List of available Inflater objects for decompression private Deque> inflaterCache = new ArrayDeque<>(); -Sherman >>> >>> (3) The releaseInfalter() is now totally driven from >>> clearStaleStreams()/staleStreamQueue, >>> which is under full control of GC. If GC does not kick in for >>> hours/days, infalters can never >>> be put back into its cache after use, even the applications >>> correctly/promptly close those >>> streams after use. And when the GC kicks in, we might see >>> "bunch" (hundreds, thousands) >>> of inflaters get pushed into cache. The approach does solve the >>> "timing" issue that got >>> us here, but it also now has this "native memory cache" >>> mechanism totally under the >>> control of/driven by the GC, the java heap management >>> mechanism, which might not be >>> a preferred scenario. Just wonder if we can have a better >>> choice, say with this GC-driven >>> as the backup cleanup and meanwhile still have the >>> ZFIIS.close() to do something to safely >>> put the used inflater back to cache promptly. To put the >>> infalter as the value of the "streams" >>> map appears to be a good idea/start, now the "infalter" will >>> not be targeted for finalized >>> until the entry gets cleaned from the map, in which might in >>> fact provide us a sort of >>> "orderly" (between the "stream" and its "inflater") clearup >>> that the GC/finalizer can't >>> guarantee. We still have couple days before we hit the >>> "deadline" (to get this one in), so it >>> might worth taking some time on this direction? >>> > > Dang! - pressed send when I meant save. I understand your comments - > on the face of it I agree with what you're suggesting - let me think > it through some more though. >> What is this "deadline" you are talking about? >> >>> -Sherman >>> >>> >>> >>> >>> >>> On 04/11/2011 05:15 AM, Neil Richards wrote: >>>> On Sun, 2011-04-10 at 18:28 +0100, Neil Richards wrote: >>>>> With releaseInflater() being driven from the cleanup of stale >>>>> 'streams' >>>>> entries, it no longer needs to be called from ZFIIS.close(), so, >>>>> instead, only Inflater.reset() is called from there (providing the >>>>> inflater object has not explicitly been ended) so that it releases >>>>> the >>>>> buffer it has been holding. >>>> Actually, I have a slight change of heart on this aspect. >>>> >>>> Because close() may be driven from a finalize() method in user code >>>> (as >>>> is done in the InflaterFinalizer test case), I believe it is possible >>>> (albeit unlikely) for an inflater object to have been reclaimed from >>>> 'streams' (by a call to clearStaleStreams()), put into the inflater >>>> cache, retrieved from there (by another thread creating an input >>>> stream) >>>> and having started to be used by that other stream at the point at >>>> which >>>> the code in close() is run. >>>> >>>> (This is because weak references will be cleared, and *may* be >>>> queued on >>>> the ReferenceQueue, prior to finalization). >>>> >>>> Because of this, it's not actually entirely safe now to call >>>> inf.reset() >>>> from ZFIIS.close(). >>>> >>>> Instead, I have added additional calls to clearStaleStreams() from the >>>> finalize() methods of both InputStream implementations in the latest >>>> (hopefully in the meaning of "last") changeset included below. >>>> >>>> As always, please get back to me with any comments, questions or >>>> suggestions on this, >>>> Thanks, >>>> Neil >>>> >>> >> > From jim.holmlund at sun.com Wed Apr 13 20:28:36 2011 From: jim.holmlund at sun.com (jim.holmlund at sun.com) Date: Wed, 13 Apr 2011 20:28:36 +0000 Subject: hg: jdk7/tl/jdk: 7032960: API files in java.awt need to be updated for references to JVM Spec with editions/hyperlinks; ... Message-ID: <20110413202846.754E947A5C@hg.openjdk.java.net> Changeset: 2dc552b0ebac Author: jjh Date: 2011-04-13 12:16 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2dc552b0ebac 7032960: API files in java.awt need to be updated for references to JVM Spec with editions/hyperlinks 7032965: API files in java.io need to updated for references to JVM Spec with editions/hyperlinks 7032958: API files in java.lang need to updated for references to JLS with editions/hyperlinks 7032961: API files in java.lang need to updated for references to JVM with editions/hyperlinks 7032976: API files in javax.lang need to be updated for references to JLS with editions/hyperlinks 7032959: API files in java.util need to updated for references to JLS with editions/hyperlinks 7032962: API files in java.util need to updated for references to JVM Spec with editions/hyperlinks 7032967: API files in java.security need to updated for references to JVM Spec with editions/hyperlinks 7032955: API files in java.math need to updated for references to JLS with editions/hyperlinks Summary: Removed URLs and 'edition' references Reviewed-by: darcy ! make/docs/Makefile ! make/jpda/jdwp/jdwp.spec ! src/share/classes/com/sun/beans/TypeResolver.java ! src/share/classes/com/sun/java/util/jar/pack/package.html ! src/share/classes/com/sun/jdi/Accessible.java ! src/share/classes/com/sun/jdi/ArrayType.java ! src/share/classes/com/sun/jdi/ClassLoaderReference.java ! src/share/classes/com/sun/jdi/ClassNotLoadedException.java ! src/share/classes/com/sun/jdi/ClassType.java ! src/share/classes/com/sun/jdi/LocalVariable.java ! src/share/classes/com/sun/jdi/Method.java ! src/share/classes/com/sun/jdi/ObjectReference.java ! src/share/classes/com/sun/jdi/ReferenceType.java ! src/share/classes/com/sun/jdi/TypeComponent.java ! src/share/classes/java/awt/doc-files/AWTThreadIssues.html ! src/share/classes/java/io/Console.java ! src/share/classes/java/io/PrintStream.java ! src/share/classes/java/io/PrintWriter.java ! src/share/classes/java/lang/AssertionError.java ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Enum.java ! src/share/classes/java/lang/Error.java ! src/share/classes/java/lang/Exception.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/Object.java ! src/share/classes/java/lang/Override.java ! src/share/classes/java/lang/Package.java ! src/share/classes/java/lang/RuntimeException.java ! src/share/classes/java/lang/SafeVarargs.java ! src/share/classes/java/lang/Short.java ! src/share/classes/java/lang/String.java ! src/share/classes/java/lang/Throwable.java ! src/share/classes/java/lang/annotation/Annotation.java ! src/share/classes/java/lang/instrument/ClassFileTransformer.java ! src/share/classes/java/lang/instrument/Instrumentation.java ! src/share/classes/java/lang/invoke/package-info.java ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/java/lang/reflect/GenericDeclaration.java ! src/share/classes/java/lang/reflect/Method.java ! src/share/classes/java/lang/reflect/Modifier.java ! src/share/classes/java/math/BigDecimal.java ! src/share/classes/java/math/BigInteger.java ! src/share/classes/java/security/SecureClassLoader.java ! src/share/classes/java/util/Formatter.java ! src/share/classes/java/util/Properties.java ! src/share/classes/java/util/PropertyResourceBundle.java ! src/share/classes/java/util/concurrent/atomic/package-info.java ! src/share/classes/java/util/concurrent/locks/Lock.java ! src/share/classes/java/util/concurrent/package-info.java ! src/share/classes/java/util/jar/Pack200.java ! src/share/classes/java/util/regex/Pattern.java ! src/share/classes/javax/management/remote/package.html ! src/share/classes/sun/misc/FpUtils.java From jim.holmlund at sun.com Wed Apr 13 20:29:40 2011 From: jim.holmlund at sun.com (jim.holmlund at sun.com) Date: Wed, 13 Apr 2011 20:29:40 +0000 Subject: hg: jdk7/tl/langtools: 7032975: API files in javax.annotation.processing need to be updated for references to JLS; ... Message-ID: <20110413202943.0015A47A5D@hg.openjdk.java.net> Changeset: 694ff82ca68e Author: jjh Date: 2011-04-13 11:35 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/694ff82ca68e 7032975: API files in javax.annotation.processing need to be updated for references to JLS 7032972: API files in javax.tools need to updated for references to JVM Spec with editions/hyperlinks 7032978: API files in javax.tools need to be updated for references to JLS with editions/hyperlinks Summary: Removed URLs and 'edition' references Reviewed-by: jjg, darcy ! make/build.properties ! make/build.xml ! src/share/classes/com/sun/javadoc/ClassDoc.java ! src/share/classes/com/sun/source/tree/AnnotationTree.java ! src/share/classes/com/sun/source/tree/ArrayAccessTree.java ! src/share/classes/com/sun/source/tree/ArrayTypeTree.java ! src/share/classes/com/sun/source/tree/AssertTree.java ! src/share/classes/com/sun/source/tree/AssignmentTree.java ! src/share/classes/com/sun/source/tree/BinaryTree.java ! src/share/classes/com/sun/source/tree/BlockTree.java ! src/share/classes/com/sun/source/tree/BreakTree.java ! src/share/classes/com/sun/source/tree/CaseTree.java ! src/share/classes/com/sun/source/tree/CatchTree.java ! src/share/classes/com/sun/source/tree/ClassTree.java ! src/share/classes/com/sun/source/tree/CompilationUnitTree.java ! src/share/classes/com/sun/source/tree/CompoundAssignmentTree.java ! src/share/classes/com/sun/source/tree/ConditionalExpressionTree.java ! src/share/classes/com/sun/source/tree/ContinueTree.java ! src/share/classes/com/sun/source/tree/DoWhileLoopTree.java ! src/share/classes/com/sun/source/tree/EmptyStatementTree.java ! src/share/classes/com/sun/source/tree/EnhancedForLoopTree.java ! src/share/classes/com/sun/source/tree/ExpressionStatementTree.java ! src/share/classes/com/sun/source/tree/ExpressionTree.java ! src/share/classes/com/sun/source/tree/ForLoopTree.java ! src/share/classes/com/sun/source/tree/IdentifierTree.java ! src/share/classes/com/sun/source/tree/IfTree.java ! src/share/classes/com/sun/source/tree/ImportTree.java ! src/share/classes/com/sun/source/tree/InstanceOfTree.java ! src/share/classes/com/sun/source/tree/LabeledStatementTree.java ! src/share/classes/com/sun/source/tree/LiteralTree.java ! src/share/classes/com/sun/source/tree/MemberSelectTree.java ! src/share/classes/com/sun/source/tree/MethodInvocationTree.java ! src/share/classes/com/sun/source/tree/MethodTree.java ! src/share/classes/com/sun/source/tree/ModifiersTree.java ! src/share/classes/com/sun/source/tree/NewArrayTree.java ! src/share/classes/com/sun/source/tree/NewClassTree.java ! src/share/classes/com/sun/source/tree/ParameterizedTypeTree.java ! src/share/classes/com/sun/source/tree/ParenthesizedTree.java ! src/share/classes/com/sun/source/tree/PrimitiveTypeTree.java ! src/share/classes/com/sun/source/tree/ReturnTree.java ! src/share/classes/com/sun/source/tree/StatementTree.java ! src/share/classes/com/sun/source/tree/SwitchTree.java ! src/share/classes/com/sun/source/tree/SynchronizedTree.java ! src/share/classes/com/sun/source/tree/ThrowTree.java ! src/share/classes/com/sun/source/tree/TryTree.java ! src/share/classes/com/sun/source/tree/TypeCastTree.java ! src/share/classes/com/sun/source/tree/TypeParameterTree.java ! src/share/classes/com/sun/source/tree/UnaryTree.java ! src/share/classes/com/sun/source/tree/VariableTree.java ! src/share/classes/com/sun/source/tree/WhileLoopTree.java ! src/share/classes/com/sun/source/tree/WildcardTree.java ! src/share/classes/com/sun/tools/apt/mirror/util/DeclarationsImpl.java ! src/share/classes/com/sun/tools/classfile/AccessFlags.java ! src/share/classes/com/sun/tools/classfile/Annotation.java ! src/share/classes/com/sun/tools/classfile/AnnotationDefault_attribute.java ! src/share/classes/com/sun/tools/classfile/BootstrapMethods_attribute.java ! src/share/classes/com/sun/tools/classfile/ClassFile.java ! src/share/classes/com/sun/tools/classfile/Code_attribute.java ! src/share/classes/com/sun/tools/classfile/ConstantPool.java ! src/share/classes/com/sun/tools/classfile/ConstantValue_attribute.java ! src/share/classes/com/sun/tools/classfile/Deprecated_attribute.java ! src/share/classes/com/sun/tools/classfile/Descriptor.java ! src/share/classes/com/sun/tools/classfile/EnclosingMethod_attribute.java ! src/share/classes/com/sun/tools/classfile/Exceptions_attribute.java ! src/share/classes/com/sun/tools/classfile/InnerClasses_attribute.java ! src/share/classes/com/sun/tools/classfile/Instruction.java ! src/share/classes/com/sun/tools/classfile/LineNumberTable_attribute.java ! src/share/classes/com/sun/tools/classfile/LocalVariableTable_attribute.java ! src/share/classes/com/sun/tools/classfile/LocalVariableTypeTable_attribute.java ! src/share/classes/com/sun/tools/classfile/Opcode.java ! src/share/classes/com/sun/tools/classfile/RuntimeAnnotations_attribute.java ! src/share/classes/com/sun/tools/classfile/RuntimeInvisibleAnnotations_attribute.java ! src/share/classes/com/sun/tools/classfile/RuntimeInvisibleParameterAnnotations_attribute.java ! src/share/classes/com/sun/tools/classfile/RuntimeParameterAnnotations_attribute.java ! src/share/classes/com/sun/tools/classfile/RuntimeVisibleAnnotations_attribute.java ! src/share/classes/com/sun/tools/classfile/RuntimeVisibleParameterAnnotations_attribute.java ! src/share/classes/com/sun/tools/classfile/Signature.java ! src/share/classes/com/sun/tools/classfile/Signature_attribute.java ! src/share/classes/com/sun/tools/classfile/SourceDebugExtension_attribute.java ! src/share/classes/com/sun/tools/classfile/SourceFile_attribute.java ! src/share/classes/com/sun/tools/classfile/StackMapTable_attribute.java ! src/share/classes/com/sun/tools/classfile/Synthetic_attribute.java ! src/share/classes/com/sun/tools/classfile/package.html ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Types.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/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/javax/annotation/processing/Processor.java ! src/share/classes/javax/lang/model/SourceVersion.java ! src/share/classes/javax/lang/model/element/Element.java ! src/share/classes/javax/lang/model/element/Modifier.java ! src/share/classes/javax/lang/model/element/PackageElement.java ! src/share/classes/javax/lang/model/element/TypeElement.java ! src/share/classes/javax/lang/model/element/VariableElement.java ! src/share/classes/javax/lang/model/type/DeclaredType.java ! src/share/classes/javax/lang/model/type/TypeVariable.java ! src/share/classes/javax/lang/model/util/Elements.java ! src/share/classes/javax/lang/model/util/Types.java ! src/share/classes/javax/tools/JavaCompiler.java ! src/share/classes/javax/tools/JavaFileManager.java ! src/share/classes/javax/tools/JavaFileObject.java ! src/share/sample/javac/processing/src/CheckNamesProcessor.java From mike.duigou at oracle.com Wed Apr 13 22:00:26 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 13 Apr 2011 15:00:26 -0700 Subject: proposal to optimise the performance of the Jar utility In-Reply-To: <652584.84963.qm@web86605.mail.ird.yahoo.com> References: <479637.89357.qm@web86603.mail.ird.yahoo.com> <4D9CAB29.5090009@oracle.com> <652584.84963.qm@web86605.mail.ird.yahoo.com> Message-ID: <16C637B3-F74E-4658-BEC6-4577ACBC85A8@oracle.com> Mike, can you share the results of performance testing at various compression levels? Is there much difference between the levels or an apparent "sweet spot"? For low hanging fruit for jdk 7 it might be worth considering raising the default compression level from 5 to 6 (the zlib default). Raising the level from 5 to 6 entails (by today's standards) very modest increases in the amount of memory and effort used (16Kb additional buffer space for compression). In general zlib reflects size choices that are almost 20 years old and it may be of no measurable benefit to be using the lower compression levels. Mike (also) On Apr 12 2011, at 17:48 , mike.skells at talk21.com wrote: > Hi Sherman, > I have had a quick look at the current code to see what 'low hanging fruit' > there is. I appreciate that parallelizing the command in its entirity may not be > feasible for the first release > > The tests that I have run are jarring the content of the 1.7 rt.jar with varying > compression levels. Each jar is run as an child process 6 times and the average > of the last 5 is taken. Tests are pretty much CPU bound on a single core > > 1. The performance of the cf0 (create file with no compression) path can be > improved for the general case if the file is buffered. > In my test env (windows 7 64bit) this equates to a 17% time performance > improvement in my tests. In the existing code the file is read twice, once to > calc the CRC and once to write the file to the Jar file. This change would > buffer a single small file at a time (size < 100K) > > 2. It is also a trivial fix to allow different compression levels, rather than > stored and default > > After that it is harder to gain performance improvements without structural > change or more discussion > > 3. The largest saving after that is in the management of the 'entries' Set, as > the hashcode of the File is expensive (this may not apply to other filesystems). > the management of this map seems to account for more cpu than Deflator! > I cannot see the reason for this data being collected. I am probably missing the > obvious ... > > 4. After that there is just the parallelisation of the jar utility and the > underlying stream > > What is the best way to proceed > > regards > > Mike > > > > ________________________________ > From: Xueming Shen > To: core-libs-dev at openjdk.java.net > Sent: Wednesday, 6 April, 2011 19:04:25 > Subject: Re: proposal to optimise the performance of the Jar utility > > Hi Mike, > > We are in the final stage of the JDK7 development, work like this is > unlikely to get in the > last minute. I have filed a CR/RFE to trace this issue, we can use this > CR as the start > point for the discussion and target for some jdk7 update releases or JDK8. > > 7034403: proposal to optimise the performance of the Jar utility > > Thanks, > Sherman > > > On 04/05/2011 04:42 PM, mike.skells at talk21.com wrote: >> Hi, >> Not sure if this is too late for Java 7 but I have made some optimisations for >> a >> client to improve the performance of the jar utility in their environment, and >> would like to promite then into the main code base >> >> The optimisations that I have performed are >> >> 1. Allowing the Jar utility to have other compression levels (currently it >> allows default (5) only) >> 2. Multi-threading, and pipelining the the file information and access >> 3. multi-threading the compression and file writing >> >> A little background >> A part of the development process of where I work they regularly Jar the >> content >> of the working projects as part of the distribution to remote systems. This is >> a >> large and complex code base of 6 million LOC and growing. The Jar file ends up >> compressed to approx 100Mb, Uncompressed the jar size is approx 245mb, about >> 4-5 >> times the size of rt.jar. >> >> I was looking at ways to improve the performance as this activity occurs >> several >> times a day for dozens of developers >> >> In essence when compressing a new jar file the jar utility is single threaded >> and staged. Forgive me if this is an oversimplification >> >> first it works out all of the files that are specified, buffering the file >> names, (IO bound) >> then it iterates through the files, and for each file, it load the file >> information, and then the file content sending it to a JarOutputStream, (CPU >> bound or IO bound depending on the IO speed) >> >> The JarOutputStream has a compression of 0 (just store) or 5 (the default), > and >> the jar writing is single threaded by the design of the JarOutputStream >> >> The process of creation of a Jar took about 20 seconds in windows with the > help >> of an SSD, and considerable longer without one, and was CPU bound to one CPU >> core >> >> ---- >> The changes that I made were >> 1. Allow deferent compression levels (for us a compression level of 1 > increases >> the file size of the Jar to 110 Mb but reduces the CPU load in compression to >> approx 30% of what it was (rough estimate) >> 2. pipelining the file access >> 2.1 one thread is started for each file root (-C on the Jar command line), >> which scans for files and places the file information into a blocking >> queue(Q1), >> which I set to abretrary size of 200 items >> 2.2 one thread pool of 10 threads reads the file information from the queue >> (Q1) and buffers the file content to a specified size (again I specified an >> arbetrary size limit of 25K for a file, and places the buffered content into a >> queue(q2) (again arbetrary size of 10 items >> 2.3 one thread takes the filecontent from Q2 and compresses it or checksums >> it and adds it the the JarOutputStream. This process is single threaded due > to >> the design of the JarOutputStream >> >> some other minor performance gain occurred by increasing the buffer on the >> output stream to reduce the IO load >> >> The end result is that the process takes about approx 5 seconds in the same >> configuration >> >> The above is in use in production configuration for a few months now >> >> As a home project I have completed some enhancements to the JarOutputStream, >> and >> produced a JarWriter that allows multiple threads to work concurrently >> deflating >> or calculating checksums, which seems to test OK for the test cases that Ihave >> generated,and successfully loads my quad core home dev machine on all cores. >> Each thread allocates a buffer, and the thread compresses a files into the >> buffer, only blocking other threads whenthe buffer is written to the output >> (which is after the compression is complete, unless the file is too large to >> compress >> >> This JarWriter is not API compatable with the JarOutputStream, it is not a >> stream. It allows the programmer to write a record based of the file >> information >> and an input stream, and is threadsafe. It is not a drop in replacement for >> JarOutputStream >> I am not an expert in the ZIp file format, but much of the code from >> ZipOutputStream is unchanged, just restructured >> --- >> I did think that there is some scope for improvement, that I have not looked > at >> a. thresholding of file size for compression (very small files dont compress >> well >> b. some file types dont compress well (e.g. png, jpeg) as they have been >> compressed already) >> c. using NIO to parallelise the loading of the file information or content >> d. some pre-charging of the deflator dictionary (e.g. a class file contains > the >> strings of the class name and packages), but this would make the format >> incompatable with zip, and require changes to the JVM to be useful, and is a >> long way from my comform zone, or skill set. This would reduce the file size >> >> -- >> What is the view of the readers. Is this something, or at least some parts of >> this that could be incorperated into Java 7 or is this too late on the dev >> cycle >> >> regards >> >> Mike From bradford.wetmore at oracle.com Wed Apr 13 23:17:24 2011 From: bradford.wetmore at oracle.com (bradford.wetmore at oracle.com) Date: Wed, 13 Apr 2011 23:17:24 +0000 Subject: hg: jdk7/tl/jdk: 6626257: Update SWAN-specific webcaching to Oracle environment in the regression tests. Message-ID: <20110413231734.0AD4A47A65@hg.openjdk.java.net> Changeset: 65b6fe866a6f Author: wetmore Date: 2011-04-13 16:12 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/65b6fe866a6f 6626257: Update SWAN-specific webcaching to Oracle environment in the regression tests. Reviewed-by: valeriep ! test/sun/net/InetAddress/nameservice/dns/cname.sh From xueming.shen at oracle.com Wed Apr 13 23:22:31 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 13 Apr 2011 16:22:31 -0700 Subject: proposal to optimise the performance of the Jar utility In-Reply-To: <16C637B3-F74E-4658-BEC6-4577ACBC85A8@oracle.com> References: <479637.89357.qm@web86603.mail.ird.yahoo.com> <4D9CAB29.5090009@oracle.com> <652584.84963.qm@web86605.mail.ird.yahoo.com> <16C637B3-F74E-4658-BEC6-4577ACBC85A8@oracle.com> Message-ID: <4DA63037.7050601@oracle.com> On 04-13-2011 3:00 PM, Mike Duigou wrote: > Mike, can you share the results of performance testing at various compression levels? Is there much difference between the levels or an apparent "sweet spot"? > > For low hanging fruit for jdk 7 it might be worth considering raising the default compression level from 5 to 6 (the zlib default). Raising the level from 5 to 6 entails (by today's Hi Mike, zlib1.2.3/zlib.h states the default is level 6. I've not checked or run any test to verify if its implementation matches its docs, any reason you think zlib actually is using level 5 as default? I can take look into it further... ... ZEXTERN int ZEXPORT deflateInit OF((z_streamp strm, int level)); Initializes the internal stream state for compression. The fields zalloc, zfree and opaque must be initialized before by the caller. If zalloc and zfree are set to Z_NULL, deflateInit updates them to use default allocation functions. The compression level must be Z_DEFAULT_COMPRESSION, or between 0 and 9: 1 gives best speed, 9 gives best compression, 0 gives no compression at all (the input data is simply copied a block at a time). Z_DEFAULT_COMPRESSION requests a default compromise between speed and compression (currently equivalent to level 6). ... -Sherman > standards) very modest increases in the amount of memory and effort used (16Kb additional buffer space for compression). In general zlib reflects size choices that are almost 20 years old and it may be of no measurable benefit to be using the lower compression levels. > > Mike (also) > > > On Apr 12 2011, at 17:48 , mike.skells at talk21.com wrote: > >> Hi Sherman, >> I have had a quick look at the current code to see what 'low hanging fruit' >> there is. I appreciate that parallelizing the command in its entirity may not be >> feasible for the first release >> >> The tests that I have run are jarring the content of the 1.7 rt.jar with varying >> compression levels. Each jar is run as an child process 6 times and the average >> of the last 5 is taken. Tests are pretty much CPU bound on a single core >> >> 1. The performance of the cf0 (create file with no compression) path can be >> improved for the general case if the file is buffered. >> In my test env (windows 7 64bit) this equates to a 17% time performance >> improvement in my tests. In the existing code the file is read twice, once to >> calc the CRC and once to write the file to the Jar file. This change would >> buffer a single small file at a time (size< 100K) >> >> 2. It is also a trivial fix to allow different compression levels, rather than >> stored and default >> >> After that it is harder to gain performance improvements without structural >> change or more discussion >> >> 3. The largest saving after that is in the management of the 'entries' Set, as >> the hashcode of the File is expensive (this may not apply to other filesystems). >> the management of this map seems to account for more cpu than Deflator! >> I cannot see the reason for this data being collected. I am probably missing the >> obvious ... >> >> 4. After that there is just the parallelisation of the jar utility and the >> underlying stream >> >> What is the best way to proceed >> >> regards >> >> Mike >> >> >> >> ________________________________ >> From: Xueming Shen >> To: core-libs-dev at openjdk.java.net >> Sent: Wednesday, 6 April, 2011 19:04:25 >> Subject: Re: proposal to optimise the performance of the Jar utility >> >> Hi Mike, >> >> We are in the final stage of the JDK7 development, work like this is >> unlikely to get in the >> last minute. I have filed a CR/RFE to trace this issue, we can use this >> CR as the start >> point for the discussion and target for some jdk7 update releases or JDK8. >> >> 7034403: proposal to optimise the performance of the Jar utility >> >> Thanks, >> Sherman >> >> >> On 04/05/2011 04:42 PM, mike.skells at talk21.com wrote: >>> Hi, >>> Not sure if this is too late for Java 7 but I have made some optimisations for >>> a >>> client to improve the performance of the jar utility in their environment, and >>> would like to promite then into the main code base >>> >>> The optimisations that I have performed are >>> >>> 1. Allowing the Jar utility to have other compression levels (currently it >>> allows default (5) only) >>> 2. Multi-threading, and pipelining the the file information and access >>> 3. multi-threading the compression and file writing >>> >>> A little background >>> A part of the development process of where I work they regularly Jar the >>> content >>> of the working projects as part of the distribution to remote systems. This is >>> a >>> large and complex code base of 6 million LOC and growing. The Jar file ends up >>> compressed to approx 100Mb, Uncompressed the jar size is approx 245mb, about >>> 4-5 >>> times the size of rt.jar. >>> >>> I was looking at ways to improve the performance as this activity occurs >>> several >>> times a day for dozens of developers >>> >>> In essence when compressing a new jar file the jar utility is single threaded >>> and staged. Forgive me if this is an oversimplification >>> >>> first it works out all of the files that are specified, buffering the file >>> names, (IO bound) >>> then it iterates through the files, and for each file, it load the file >>> information, and then the file content sending it to a JarOutputStream, (CPU >>> bound or IO bound depending on the IO speed) >>> >>> The JarOutputStream has a compression of 0 (just store) or 5 (the default), >> and >>> the jar writing is single threaded by the design of the JarOutputStream >>> >>> The process of creation of a Jar took about 20 seconds in windows with the >> help >>> of an SSD, and considerable longer without one, and was CPU bound to one CPU >>> core >>> >>> ---- >>> The changes that I made were >>> 1. Allow deferent compression levels (for us a compression level of 1 >> increases >>> the file size of the Jar to 110 Mb but reduces the CPU load in compression to >>> approx 30% of what it was (rough estimate) >>> 2. pipelining the file access >>> 2.1 one thread is started for each file root (-C on the Jar command line), >>> which scans for files and places the file information into a blocking >>> queue(Q1), >>> which I set to abretrary size of 200 items >>> 2.2 one thread pool of 10 threads reads the file information from the queue >>> (Q1) and buffers the file content to a specified size (again I specified an >>> arbetrary size limit of 25K for a file, and places the buffered content into a >>> queue(q2) (again arbetrary size of 10 items >>> 2.3 one thread takes the filecontent from Q2 and compresses it or checksums >>> it and adds it the the JarOutputStream. This process is single threaded due >> to >>> the design of the JarOutputStream >>> >>> some other minor performance gain occurred by increasing the buffer on the >>> output stream to reduce the IO load >>> >>> The end result is that the process takes about approx 5 seconds in the same >>> configuration >>> >>> The above is in use in production configuration for a few months now >>> >>> As a home project I have completed some enhancements to the JarOutputStream, >>> and >>> produced a JarWriter that allows multiple threads to work concurrently >>> deflating >>> or calculating checksums, which seems to test OK for the test cases that Ihave >>> generated,and successfully loads my quad core home dev machine on all cores. >>> Each thread allocates a buffer, and the thread compresses a files into the >>> buffer, only blocking other threads whenthe buffer is written to the output >>> (which is after the compression is complete, unless the file is too large to >>> compress >>> >>> This JarWriter is not API compatable with the JarOutputStream, it is not a >>> stream. It allows the programmer to write a record based of the file >>> information >>> and an input stream, and is threadsafe. It is not a drop in replacement for >>> JarOutputStream >>> I am not an expert in the ZIp file format, but much of the code from >>> ZipOutputStream is unchanged, just restructured >>> --- >>> I did think that there is some scope for improvement, that I have not looked >> at >>> a. thresholding of file size for compression (very small files dont compress >>> well >>> b. some file types dont compress well (e.g. png, jpeg) as they have been >>> compressed already) >>> c. using NIO to parallelise the loading of the file information or content >>> d. some pre-charging of the deflator dictionary (e.g. a class file contains >> the >>> strings of the class name and packages), but this would make the format >>> incompatable with zip, and require changes to the JVM to be useful, and is a >>> long way from my comform zone, or skill set. This would reduce the file size >>> >>> -- >>> What is the view of the readers. Is this something, or at least some parts of >>> this that could be incorperated into Java 7 or is this too late on the dev >>> cycle >>> >>> regards >>> >>> Mike From xueming.shen at oracle.com Wed Apr 13 23:28:39 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 13 Apr 2011 16:28:39 -0700 Subject: proposal to optimise the performance of the Jar utility In-Reply-To: <16C637B3-F74E-4658-BEC6-4577ACBC85A8@oracle.com> References: <479637.89357.qm@web86603.mail.ird.yahoo.com> <4D9CAB29.5090009@oracle.com> <652584.84963.qm@web86605.mail.ird.yahoo.com> <16C637B3-F74E-4658-BEC6-4577ACBC85A8@oracle.com> Message-ID: <4DA631A7.3000502@oracle.com> On 04-13-2011 3:00 PM, Mike Duigou wrote: > Mike, can you share the results of performance testing at various compression levels? Is there much difference between the levels or an apparent "sweet spot"? > > For low hanging fruit for jdk 7 it might be worth considering raising the default compression level from 5 to 6 (the zlib default). Raising the level from 5 to 6 entails (by today's Mike, src/share/native/java/util/zip/zlib-1.2.3/zlib.h/ states zlib-1.2.3 uses level 6 as its default compression (when -1 passed in), I also checked defaulte.c, it also appears it replaces -1 with level 6. Any reason we should not trust it or you were mentioning different thing? -Sherman > standards) very modest increases in the amount of memory and effort used (16Kb additional buffer space for compression). In general zlib reflects size choices that are almost 20 years old and it may be of no measurable benefit to be using the lower compression levels. > > Mike (also) > > > On Apr 12 2011, at 17:48 , mike.skells at talk21.com wrote: > >> Hi Sherman, >> I have had a quick look at the current code to see what 'low hanging fruit' >> there is. I appreciate that parallelizing the command in its entirity may not be >> feasible for the first release >> >> The tests that I have run are jarring the content of the 1.7 rt.jar with varying >> compression levels. Each jar is run as an child process 6 times and the average >> of the last 5 is taken. Tests are pretty much CPU bound on a single core >> >> 1. The performance of the cf0 (create file with no compression) path can be >> improved for the general case if the file is buffered. >> In my test env (windows 7 64bit) this equates to a 17% time performance >> improvement in my tests. In the existing code the file is read twice, once to >> calc the CRC and once to write the file to the Jar file. This change would >> buffer a single small file at a time (size< 100K) >> >> 2. It is also a trivial fix to allow different compression levels, rather than >> stored and default >> >> After that it is harder to gain performance improvements without structural >> change or more discussion >> >> 3. The largest saving after that is in the management of the 'entries' Set, as >> the hashcode of the File is expensive (this may not apply to other filesystems). >> the management of this map seems to account for more cpu than Deflator! >> I cannot see the reason for this data being collected. I am probably missing the >> obvious ... >> >> 4. After that there is just the parallelisation of the jar utility and the >> underlying stream >> >> What is the best way to proceed >> >> regards >> >> Mike >> >> >> >> ________________________________ >> From: Xueming Shen >> To: core-libs-dev at openjdk.java.net >> Sent: Wednesday, 6 April, 2011 19:04:25 >> Subject: Re: proposal to optimise the performance of the Jar utility >> >> Hi Mike, >> >> We are in the final stage of the JDK7 development, work like this is >> unlikely to get in the >> last minute. I have filed a CR/RFE to trace this issue, we can use this >> CR as the start >> point for the discussion and target for some jdk7 update releases or JDK8. >> >> 7034403: proposal to optimise the performance of the Jar utility >> >> Thanks, >> Sherman >> >> >> On 04/05/2011 04:42 PM, mike.skells at talk21.com wrote: >>> Hi, >>> Not sure if this is too late for Java 7 but I have made some optimisations for >>> a >>> client to improve the performance of the jar utility in their environment, and >>> would like to promite then into the main code base >>> >>> The optimisations that I have performed are >>> >>> 1. Allowing the Jar utility to have other compression levels (currently it >>> allows default (5) only) >>> 2. Multi-threading, and pipelining the the file information and access >>> 3. multi-threading the compression and file writing >>> >>> A little background >>> A part of the development process of where I work they regularly Jar the >>> content >>> of the working projects as part of the distribution to remote systems. This is >>> a >>> large and complex code base of 6 million LOC and growing. The Jar file ends up >>> compressed to approx 100Mb, Uncompressed the jar size is approx 245mb, about >>> 4-5 >>> times the size of rt.jar. >>> >>> I was looking at ways to improve the performance as this activity occurs >>> several >>> times a day for dozens of developers >>> >>> In essence when compressing a new jar file the jar utility is single threaded >>> and staged. Forgive me if this is an oversimplification >>> >>> first it works out all of the files that are specified, buffering the file >>> names, (IO bound) >>> then it iterates through the files, and for each file, it load the file >>> information, and then the file content sending it to a JarOutputStream, (CPU >>> bound or IO bound depending on the IO speed) >>> >>> The JarOutputStream has a compression of 0 (just store) or 5 (the default), >> and >>> the jar writing is single threaded by the design of the JarOutputStream >>> >>> The process of creation of a Jar took about 20 seconds in windows with the >> help >>> of an SSD, and considerable longer without one, and was CPU bound to one CPU >>> core >>> >>> ---- >>> The changes that I made were >>> 1. Allow deferent compression levels (for us a compression level of 1 >> increases >>> the file size of the Jar to 110 Mb but reduces the CPU load in compression to >>> approx 30% of what it was (rough estimate) >>> 2. pipelining the file access >>> 2.1 one thread is started for each file root (-C on the Jar command line), >>> which scans for files and places the file information into a blocking >>> queue(Q1), >>> which I set to abretrary size of 200 items >>> 2.2 one thread pool of 10 threads reads the file information from the queue >>> (Q1) and buffers the file content to a specified size (again I specified an >>> arbetrary size limit of 25K for a file, and places the buffered content into a >>> queue(q2) (again arbetrary size of 10 items >>> 2.3 one thread takes the filecontent from Q2 and compresses it or checksums >>> it and adds it the the JarOutputStream. This process is single threaded due >> to >>> the design of the JarOutputStream >>> >>> some other minor performance gain occurred by increasing the buffer on the >>> output stream to reduce the IO load >>> >>> The end result is that the process takes about approx 5 seconds in the same >>> configuration >>> >>> The above is in use in production configuration for a few months now >>> >>> As a home project I have completed some enhancements to the JarOutputStream, >>> and >>> produced a JarWriter that allows multiple threads to work concurrently >>> deflating >>> or calculating checksums, which seems to test OK for the test cases that Ihave >>> generated,and successfully loads my quad core home dev machine on all cores. >>> Each thread allocates a buffer, and the thread compresses a files into the >>> buffer, only blocking other threads whenthe buffer is written to the output >>> (which is after the compression is complete, unless the file is too large to >>> compress >>> >>> This JarWriter is not API compatable with the JarOutputStream, it is not a >>> stream. It allows the programmer to write a record based of the file >>> information >>> and an input stream, and is threadsafe. It is not a drop in replacement for >>> JarOutputStream >>> I am not an expert in the ZIp file format, but much of the code from >>> ZipOutputStream is unchanged, just restructured >>> --- >>> I did think that there is some scope for improvement, that I have not looked >> at >>> a. thresholding of file size for compression (very small files dont compress >>> well >>> b. some file types dont compress well (e.g. png, jpeg) as they have been >>> compressed already) >>> c. using NIO to parallelise the loading of the file information or content >>> d. some pre-charging of the deflator dictionary (e.g. a class file contains >> the >>> strings of the class name and packages), but this would make the format >>> incompatable with zip, and require changes to the JVM to be useful, and is a >>> long way from my comform zone, or skill set. This would reduce the file size >>> >>> -- >>> What is the view of the readers. Is this something, or at least some parts of >>> this that could be incorperated into Java 7 or is this too late on the dev >>> cycle >>> >>> regards >>> >>> Mike From mike.skells at talk21.com Wed Apr 13 23:55:04 2011 From: mike.skells at talk21.com (mike.skells at talk21.com) Date: Thu, 14 Apr 2011 00:55:04 +0100 (BST) Subject: proposal to optimise the performance of the Jar utility In-Reply-To: <16C637B3-F74E-4658-BEC6-4577ACBC85A8@oracle.com> References: <479637.89357.qm@web86603.mail.ird.yahoo.com> <4D9CAB29.5090009@oracle.com> <652584.84963.qm@web86605.mail.ird.yahoo.com> <16C637B3-F74E-4658-BEC6-4577ACBC85A8@oracle.com> Message-ID: <490699.26101.qm@web86607.mail.ird.yahoo.com> Hi Mike, apart from compression 0 it doesn't make a lot of difference as far as I see it. As I posted earlier, converting the file name to lower case seems (according the the NB profiler) to take more time than the compression Bearing in mind that I have tweaked my system so that I am accessing from cache only, so the elapsed time is pretty much the single core time, here are the results the result I have re-run today (hence the delay) in csv format --- ,cf,cf0,cf1,cf2,cf3,cf4,cf5,cf6,cf7,cf8,cf9 1.6.0_24 (1.6 vm),10255,9751,,,,,,,,, java 1.7 release candinate,10498,9663,,,,,,,,, orig ,10481,9707,,,,,,,,, buffer CRC32 data,,7398,9490,9641,9565,10038,10142,10366,10310,10536,10440 --- this run shows a 25% improvement in cf0 times (9703 ms vs 7398 wthen the tweaks are applied) cf1 (compressed level 1) takes 9490 and cf9 takes 10440, so not a huge difference Regards Mike ________________________________ From: Mike Duigou To: mike.skells at talk21.com Cc: Xueming Shen ; core-libs-dev Libs Sent: Wednesday, 13 April, 2011 23:00:26 Subject: Re: proposal to optimise the performance of the Jar utility Mike, can you share the results of performance testing at various compression levels? Is there much difference between the levels or an apparent "sweet spot"? For low hanging fruit for jdk 7 it might be worth considering raising the default compression level from 5 to 6 (the zlib default). Raising the level from 5 to 6 entails (by today's standards) very modest increases in the amount of memory and effort used (16Kb additional buffer space for compression). In general zlib reflects size choices that are almost 20 years old and it may be of no measurable benefit to be using the lower compression levels. Mike (also) On Apr 12 2011, at 17:48 , mike.skells at talk21.com wrote: > Hi Sherman, > I have had a quick look at the current code to see what 'low hanging fruit' > there is. I appreciate that parallelizing the command in its entirity may not >be > > feasible for the first release > > The tests that I have run are jarring the content of the 1.7 rt.jar with >varying > > compression levels. Each jar is run as an child process 6 times and the average > > of the last 5 is taken. Tests are pretty much CPU bound on a single core > > 1. The performance of the cf0 (create file with no compression) path can be > improved for the general case if the file is buffered. > In my test env (windows 7 64bit) this equates to a 17% time performance > improvement in my tests. In the existing code the file is read twice, once to > calc the CRC and once to write the file to the Jar file. This change would > buffer a single small file at a time (size < 100K) > > 2. It is also a trivial fix to allow different compression levels, rather than > stored and default > > After that it is harder to gain performance improvements without structural > change or more discussion > > 3. The largest saving after that is in the management of the 'entries' Set, as > the hashcode of the File is expensive (this may not apply to other >filesystems). > > the management of this map seems to account for more cpu than Deflator! > I cannot see the reason for this data being collected. I am probably missing >the > > obvious ... > > 4. After that there is just the parallelisation of the jar utility and the > underlying stream > > What is the best way to proceed > > regards > > Mike > > > > ________________________________ > From: Xueming Shen > To: core-libs-dev at openjdk.java.net > Sent: Wednesday, 6 April, 2011 19:04:25 > Subject: Re: proposal to optimise the performance of the Jar utility > > Hi Mike, > > We are in the final stage of the JDK7 development, work like this is > unlikely to get in the > last minute. I have filed a CR/RFE to trace this issue, we can use this > CR as the start > point for the discussion and target for some jdk7 update releases or JDK8. > > 7034403: proposal to optimise the performance of the Jar utility > > Thanks, > Sherman > > > On 04/05/2011 04:42 PM, mike.skells at talk21.com wrote: >> Hi, >> Not sure if this is too late for Java 7 but I have made some optimisations for > >> a >> client to improve the performance of the jar utility in their environment, and >> would like to promite then into the main code base >> >> The optimisations that I have performed are >> >> 1. Allowing the Jar utility to have other compression levels (currently it >> allows default (5) only) >> 2. Multi-threading, and pipelining the the file information and access >> 3. multi-threading the compression and file writing >> >> A little background >> A part of the development process of where I work they regularly Jar the >> content >> of the working projects as part of the distribution to remote systems. This is > >> a >> large and complex code base of 6 million LOC and growing. The Jar file ends up >> compressed to approx 100Mb, Uncompressed the jar size is approx 245mb, about >> 4-5 >> times the size of rt.jar. >> >> I was looking at ways to improve the performance as this activity occurs >> several >> times a day for dozens of developers >> >> In essence when compressing a new jar file the jar utility is single threaded >> and staged. Forgive me if this is an oversimplification >> >> first it works out all of the files that are specified, buffering the file >> names, (IO bound) >> then it iterates through the files, and for each file, it load the file >> information, and then the file content sending it to a JarOutputStream, (CPU >> bound or IO bound depending on the IO speed) >> >> The JarOutputStream has a compression of 0 (just store) or 5 (the default), > and >> the jar writing is single threaded by the design of the JarOutputStream >> >> The process of creation of a Jar took about 20 seconds in windows with the > help >> of an SSD, and considerable longer without one, and was CPU bound to one CPU >> core >> >> ---- >> The changes that I made were >> 1. Allow deferent compression levels (for us a compression level of 1 > increases >> the file size of the Jar to 110 Mb but reduces the CPU load in compression to >> approx 30% of what it was (rough estimate) >> 2. pipelining the file access >> 2.1 one thread is started for each file root (-C on the Jar command line), >> which scans for files and places the file information into a blocking >> queue(Q1), >> which I set to abretrary size of 200 items >> 2.2 one thread pool of 10 threads reads the file information from the queue >> (Q1) and buffers the file content to a specified size (again I specified an >> arbetrary size limit of 25K for a file, and places the buffered content into a >> queue(q2) (again arbetrary size of 10 items >> 2.3 one thread takes the filecontent from Q2 and compresses it or checksums >> it and adds it the the JarOutputStream. This process is single threaded due > to >> the design of the JarOutputStream >> >> some other minor performance gain occurred by increasing the buffer on the >> output stream to reduce the IO load >> >> The end result is that the process takes about approx 5 seconds in the same >> configuration >> >> The above is in use in production configuration for a few months now >> >> As a home project I have completed some enhancements to the JarOutputStream, >> and >> produced a JarWriter that allows multiple threads to work concurrently >> deflating >> or calculating checksums, which seems to test OK for the test cases that Ihave >> generated,and successfully loads my quad core home dev machine on all cores. >> Each thread allocates a buffer, and the thread compresses a files into the >> buffer, only blocking other threads whenthe buffer is written to the output >> (which is after the compression is complete, unless the file is too large to >> compress >> >> This JarWriter is not API compatable with the JarOutputStream, it is not a >> stream. It allows the programmer to write a record based of the file >> information >> and an input stream, and is threadsafe. It is not a drop in replacement for >> JarOutputStream >> I am not an expert in the ZIp file format, but much of the code from >> ZipOutputStream is unchanged, just restructured >> --- >> I did think that there is some scope for improvement, that I have not looked > at >> a. thresholding of file size for compression (very small files dont compress >> well >> b. some file types dont compress well (e.g. png, jpeg) as they have been >> compressed already) >> c. using NIO to parallelise the loading of the file information or content >> d. some pre-charging of the deflator dictionary (e.g. a class file contains > the >> strings of the class name and packages), but this would make the format >> incompatable with zip, and require changes to the JVM to be useful, and is a >> long way from my comform zone, or skill set. This would reduce the file size >> >> -- >> What is the view of the readers. Is this something, or at least some parts of >> this that could be incorperated into Java 7 or is this too late on the dev >> cycle >> >> regards >> >> Mike From mike.duigou at oracle.com Thu Apr 14 00:02:10 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 13 Apr 2011 17:02:10 -0700 Subject: proposal to optimise the performance of the Jar utility In-Reply-To: <4DA63037.7050601@oracle.com> References: <479637.89357.qm@web86603.mail.ird.yahoo.com> <4D9CAB29.5090009@oracle.com> <652584.84963.qm@web86605.mail.ird.yahoo.com> <16C637B3-F74E-4658-BEC6-4577ACBC85A8@oracle.com> <4DA63037.7050601@oracle.com> Message-ID: <7A4FDE50-0275-4471-AE63-F8B9C0B01A2E@oracle.com> On Apr 13 2011, at 16:22 , Xueming Shen wrote: > On 04-13-2011 3:00 PM, Mike Duigou wrote: >> Mike, can you share the results of performance testing at various compression levels? Is there much difference between the levels or an apparent "sweet spot"? >> >> For low hanging fruit for jdk 7 it might be worth considering raising the default compression level from 5 to 6 (the zlib default). Raising the level from 5 to 6 entails (by today's > > Hi Mike, > > zlib1.2.3/zlib.h states the default is level 6. I've not checked or run any test to verify if its > implementation matches its docs, any reason you think zlib actually is using level 5 as > default? I can take look into it further... I was basing this on Mike Skells' earlier posting: >>>> 1. Allowing the Jar utility to have other compression levels (currently it >>>> allows default (5) only) If it's using Z_DEFAULT_COMPRESSION then it's actually using 6 as you suggest. Sorry for the confusion. Mike > ... > ZEXTERN int ZEXPORT deflateInit OF((z_streamp strm, int level)); > > Initializes the internal stream state for compression. The fields > zalloc, zfree and opaque must be initialized before by the caller. > If zalloc and zfree are set to Z_NULL, deflateInit updates them to > use default allocation functions. > > The compression level must be Z_DEFAULT_COMPRESSION, or between 0 and 9: > 1 gives best speed, 9 gives best compression, 0 gives no compression at > all (the input data is simply copied a block at a time). > Z_DEFAULT_COMPRESSION requests a default compromise between speed and > compression (currently equivalent to level 6). > ... From weijun.wang at oracle.com Thu Apr 14 04:42:01 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Thu, 14 Apr 2011 04:42:01 +0000 Subject: hg: jdk7/tl/jdk: 7036157: TCP connection does not use kdc_timeout Message-ID: <20110414044211.5DBE947A74@hg.openjdk.java.net> Changeset: e9ae2178926a Author: weijun Date: 2011-04-14 12:40 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e9ae2178926a 7036157: TCP connection does not use kdc_timeout Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/internal/NetClient.java From xueming.shen at oracle.com Thu Apr 14 06:12:26 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 13 Apr 2011 23:12:26 -0700 Subject: proposal to optimise the performance of the Jar utility In-Reply-To: <490699.26101.qm@web86607.mail.ird.yahoo.com> References: <479637.89357.qm@web86603.mail.ird.yahoo.com> <4D9CAB29.5090009@oracle.com> <652584.84963.qm@web86605.mail.ird.yahoo.com> <16C637B3-F74E-4658-BEC6-4577ACBC85A8@oracle.com> <490699.26101.qm@web86607.mail.ird.yahoo.com> Message-ID: <4DA6904A.3090303@oracle.com> On 4/13/2011 4:55 PM, mike.skells at talk21.com wrote: > Hi Mike, > apart from compression 0 it doesn't make a lot of difference as far as > I see it. As I posted earlier, converting the file name to lower case > seems (according the the NB profiler) to take more time than the > compression File.hashCode() is slow on Windows (yes, we have to go down to String.toLowerCase() to be "correct" and yes, its slow), we have the comment in Win32FileSystem.hashCode() just for this:-) public int hashCode(File f) { /* Could make this more efficient: String.hashCodeIgnoreCase */ return f.getPath().toLowerCase(Locale.ENGLISH).hashCode() ^ 1234321; } I tried to use ArrayList for the "entries" (instead of LinkedHashSet), as showed below (yes, it's total fine to use List for "creating", need a little more work for "updating", but let's put "updating" aside for now) // All files need to be added/updated. //Set entries = new LinkedHashSet(); List entries = new ArrayList(); and run the cf0 on rtjar, which has the rt.jar extracted (time measured by System.currentTimeMillis() [List] $ ../jdk1.7.0/bin/java Main cf0 foo.jar rtjar expand=406, create=10703 expand=406, create=10797 expand=407, create=11046 [Set] $ ../jdk1.7.0/bin/java Main cf0 foo.jar rtjar expand=469, create=10703 expand=469, create=10688 expand=469, create=10656 The "List" version is indeed about 15% faster than the "Set" version, in "expanding", but "expanding" is only about 5% of the over all "creating" time (I've not tried to measure yet, but I will not be surprised to find that we probably spend more time on i/o than deflating) So it is nice to have, but does not appear to bring us some thing "significant". -Sherman > > Bearing in mind that I have tweaked my system so that I am accessing > from cache only, so the elapsed time is pretty much the single core > time, here are the results > > the result I have re-run today (hence the delay) > in csv format > --- > ,cf,cf0,cf1,cf2,cf3,cf4,cf5,cf6,cf7,cf8,cf9 > 1.6.0_24 (1.6 vm),10255,9751,,,,,,,,, > java 1.7 release candinate,10498,9663,,,,,,,,, > orig ,10481,9707,,,,,,,,, > buffer CRC32 data,,7398,9490,9641,9565,10038,10142,10366,10310,10536,10440 > --- > this run shows a 25% improvement in cf0 times (9703 ms vs 7398 wthen > the tweaks are applied) > cf1 (compressed level 1) takes 9490 and cf9 takes 10440, so not a huge > difference > > > Regards > > Mike > > > > ------------------------------------------------------------------------ > *From:* Mike Duigou > *To:* mike.skells at talk21.com > *Cc:* Xueming Shen ; core-libs-dev Libs > > *Sent:* Wednesday, 13 April, 2011 23:00:26 > *Subject:* Re: proposal to optimise the performance of the Jar utility > > Mike, can you share the results of performance testing at various > compression levels? Is there much difference between the levels or an > apparent "sweet spot"? > > For low hanging fruit for jdk 7 it might be worth considering raising > the default compression level from 5 to 6 (the zlib default). Raising > the level from 5 to 6 entails (by today's standards) very modest > increases in the amount of memory and effort used (16Kb additional > buffer space for compression). In general zlib reflects size choices > that are almost 20 years old and it may be of no measurable benefit to > be using the lower compression levels. > > Mike (also) > > > On Apr 12 2011, at 17:48 , mike.skells at talk21.com > wrote: > > > Hi Sherman, > > I have had a quick look at the current code to see what 'low hanging > fruit' > > there is. I appreciate that parallelizing the command in its > entirity may not be > > feasible for the first release > > > > The tests that I have run are jarring the content of the 1.7 rt.jar > with varying > > compression levels. Each jar is run as an child process 6 times and > the average > > of the last 5 is taken. Tests are pretty much CPU bound on a single core > > > > 1. The performance of the cf0 (create file with no compression) path > can be > > improved for the general case if the file is buffered. > > In my test env (windows 7 64bit) this equates to a 17% time performance > > improvement in my tests. In the existing code the file is read > twice, once to > > calc the CRC and once to write the file to the Jar file. This change > would > > buffer a single small file at a time (size < 100K) > > > > 2. It is also a trivial fix to allow different compression levels, > rather than > > stored and default > > > > After that it is harder to gain performance improvements without > structural > > change or more discussion > > > > 3. The largest saving after that is in the management of the > 'entries' Set, as > > the hashcode of the File is expensive (this may not apply to other > filesystems). > > the management of this map seems to account for more cpu than Deflator! > > I cannot see the reason for this data being collected. I am probably > missing the > > obvious ... > > > > 4. After that there is just the parallelisation of the jar utility > and the > > underlying stream > > > > What is the best way to proceed > > > > regards > > > > Mike > > > > > > > > ________________________________ > > From: Xueming Shen > > > To: core-libs-dev at openjdk.java.net > > > Sent: Wednesday, 6 April, 2011 19:04:25 > > Subject: Re: proposal to optimise the performance of the Jar utility > > > > Hi Mike, > > > > We are in the final stage of the JDK7 development, work like this is > > unlikely to get in the > > last minute. I have filed a CR/RFE to trace this issue, we can use this > > CR as the start > > point for the discussion and target for some jdk7 update releases or > JDK8. > > > > 7034403: proposal to optimise the performance of the Jar utility > > > > Thanks, > > Sherman > > > > > > On 04/05/2011 04:42 PM, mike.skells at talk21.com > wrote: > >> Hi, > >> Not sure if this is too late for Java 7 but I have made some > optimisations for > >> a > >> client to improve the performance of the jar utility in their > environment, and > >> would like to promite then into the main code base > >> > >> The optimisations that I have performed are > >> > >> 1. Allowing the Jar utility to have other compression levels > (currently it > >> allows default (5) only) > >> 2. Multi-threading, and pipelining the the file information and access > >> 3. multi-threading the compression and file writing > >> > >> A little background > >> A part of the development process of where I work they regularly > Jar the > >> content > >> of the working projects as part of the distribution to remote > systems. This is > >> a > >> large and complex code base of 6 million LOC and growing. The Jar > file ends up > >> compressed to approx 100Mb, Uncompressed the jar size is approx > 245mb, about > >> 4-5 > >> times the size of rt.jar. > >> > >> I was looking at ways to improve the performance as this activity > occurs > >> several > >> times a day for dozens of developers > >> > >> In essence when compressing a new jar file the jar utility is > single threaded > >> and staged. Forgive me if this is an oversimplification > >> > >> first it works out all of the files that are specified, buffering > the file > >> names, (IO bound) > >> then it iterates through the files, and for each file, it load the > file > >> information, and then the file content sending it to a > JarOutputStream, (CPU > >> bound or IO bound depending on the IO speed) > >> > >> The JarOutputStream has a compression of 0 (just store) or 5 (the > default), > > and > >> the jar writing is single threaded by the design of the JarOutputStream > >> > >> The process of creation of a Jar took about 20 seconds in windows > with the > > help > >> of an SSD, and considerable longer without one, and was CPU bound > to one CPU > >> core > >> > >> ---- > >> The changes that I made were > >> 1. Allow deferent compression levels (for us a compression level of 1 > > increases > >> the file size of the Jar to 110 Mb but reduces the CPU load in > compression to > >> approx 30% of what it was (rough estimate) > >> 2. pipelining the file access > >> 2.1 one thread is started for each file root (-C on the Jar > command line), > >> which scans for files and places the file information into a blocking > >> queue(Q1), > >> which I set to abretrary size of 200 items > >> 2.2 one thread pool of 10 threads reads the file information > from the queue > >> (Q1) and buffers the file content to a specified size (again I > specified an > >> arbetrary size limit of 25K for a file, and places the buffered > content into a > >> queue(q2) (again arbetrary size of 10 items > >> 2.3 one thread takes the filecontent from Q2 and compresses it > or checksums > >> it and adds it the the JarOutputStream. This process is single > threaded due > > to > >> the design of the JarOutputStream > >> > >> some other minor performance gain occurred by increasing the buffer > on the > >> output stream to reduce the IO load > >> > >> The end result is that the process takes about approx 5 seconds in > the same > >> configuration > >> > >> The above is in use in production configuration for a few months now > >> > >> As a home project I have completed some enhancements to the > JarOutputStream, > >> and > >> produced a JarWriter that allows multiple threads to work concurrently > >> deflating > >> or calculating checksums, which seems to test OK for the test cases > that Ihave > >> generated,and successfully loads my quad core home dev machine on > all cores. > >> Each thread allocates a buffer, and the thread compresses a files > into the > >> buffer, only blocking other threads whenthe buffer is written to > the output > >> (which is after the compression is complete, unless the file is too > large to > >> compress > >> > >> This JarWriter is not API compatable with the JarOutputStream, it > is not a > >> stream. It allows the programmer to write a record based of the file > >> information > >> and an input stream, and is threadsafe. It is not a drop in > replacement for > >> JarOutputStream > >> I am not an expert in the ZIp file format, but much of the code from > >> ZipOutputStream is unchanged, just restructured > >> --- > >> I did think that there is some scope for improvement, that I have > not looked > > at > >> a. thresholding of file size for compression (very small files dont > compress > >> well > >> b. some file types dont compress well (e.g. png, jpeg) as they have > been > >> compressed already) > >> c. using NIO to parallelise the loading of the file information or > content > >> d. some pre-charging of the deflator dictionary (e.g. a class file > contains > > the > >> strings of the class name and packages), but this would make the format > >> incompatable with zip, and require changes to the JVM to be useful, > and is a > >> long way from my comform zone, or skill set. This would reduce the > file size > >> > >> -- > >> What is the view of the readers. Is this something, or at least > some parts of > >> this that could be incorperated into Java 7 or is this too late on > the dev > >> cycle > >> > >> regards > >> > >> Mike > From pcj at roundroom.net Thu Apr 14 06:14:18 2011 From: pcj at roundroom.net (Peter Jones) Date: Thu, 14 Apr 2011 02:14:18 -0400 Subject: advice & review requested for 6896297, race condition in rmid causing JCK failure In-Reply-To: <4D9E3867.7030004@oracle.com> References: <4D9E3867.7030004@oracle.com> Message-ID: <15C8B16F-4EAB-40E0-B926-7882A1D5793C@roundroom.net> Stuart, A couple of comments so far: I don't think that there would be a serialization compatibility problem with changing Activation.groupTable to have a ConcurrentHashMap instead of a HashMap. The field's declared type is Map, so the deserialization process would be able to assign either class to the field, and the code doesn't otherwise care about the Map implementation class. An rmid's state created with CHM could not be recoverable with JDK 1.4, of course, but I don't think that that's a concern. The fix would not help an rmid whose state gets recovered from an earlier version created with HM, unless a replacement (HM->CHM) was also done upon deserialization. More troubling I think is the higher-level issue suggested by this ConcurrentModificationException. Thread B (in the 6896297 Evaluation) is attempting to write a "snapshot" of the entire persistent state of the Activation instance, which presumably should be consistent with future "updates" written to the log, while Thread A is concurrently attempting to mutate that state (before writing an update for its mutation). It seems highly doubtful that potentially including an uncertain amount of this concurrent mutation in the written snapshot is safe. I might expect a coarser lock to be used across all such mutations, together with their associated log writes (at which point groupTable wouldn't need to be concurrent). The approach at your webrev below seems OK to address the immediate ConcurrentModificationException, but (unless I'm missing something) the higher-level issue with snapshot correctness described above would remain. Cheers, -- Peter P.S. This seems somewhat related to http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4945726 On Apr 7, 2011, at 6:19 PM, Stuart Marks wrote: > Hi Core-Libs developers, > > I'd like to solicit some advice and discussion about this bug and a potential fix I'm cooking for it. Here is the bug report; it contains details about the problem and my analysis of it: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6896297 > > and here's a webrev of the fix I'm working on: > > http://cr.openjdk.java.net/~smarks/reviews/6896297/webrev.0/ > > Briefly, the problem is incorrect synchronization of groupTable, a HashMap field of an Activation object. The code mostly locks groupTable around any access to it. However, no such locking is done during serialization. If the groupTable is modified while it's being serialized, ConcurrentModificationException occurs. > > The obvious fix would be to use ConcurrentHashMap instead of Hashmap and to remove the external locking entirely. Unfortunately this will change the serialized representation of the Activation object, which I'm not sure is acceptable. > > Assuming that we can't change the serialized represenation, the alternative approach would be to make sure that locking is done properly during serialization. This is fairly easy to do by locking groupTable in a writeObject() method. Unfortunately, this introduces a deadlock. > > This deadlock occurs because, with this modification, there are now paths through the code that take locks in the opposite order. Specifically, the addLogRecord() method locks the log object and then (via serialization and the newly added writeObject() method) locks groupTable. However, the unregisterGroup() method locks groupTable and calls GroupEntry.unregisterGroup() which logs the event, which takes a lock on the log. > > After some analysis, I've determined that the call to GroupEntry.unregisterGroup() can be moved outside the synchronization of groupTable. This removes the ordering problem. > > With these fixes in place (the state of the webrev above) I can get several hundred successful test runs with neither ConcurrentModificationException nor any deadlocks. > > Of course, that doesn't mean the change is correct. :-) > > Questions: > > 1. Is there a requirement that the serialized form of Activation remain unchanged? If we can change it, we might as well just use ConcurrentHashMap instead of HashMap. > > 2. Is my lock ordering analysis correct? I've pored over the code, but not really being familiar with any RMI concepts, I'm not sure I have it right. I've written this analysis into a big comment I've added to the code. > > 3. There is also a potential concurrency issue with idTable, which is used similarly to groupTable. I haven't seen a test failure from it though. It seems sensible to add a lock for it in Activation.writeObject() though. I don't particularly like nesting the locks of idTable and groupTable, but locking them separately would require serializing the Activation object field by field instead of simply using defaultWriteObject(). Is this a reasonable approach? > > Thanks for any advice or comments. > > s'marks > From mike.skells at talk21.com Thu Apr 14 08:54:22 2011 From: mike.skells at talk21.com (mike.skells at talk21.com) Date: Thu, 14 Apr 2011 09:54:22 +0100 (BST) Subject: proposal to optimise the performance of the Jar utility In-Reply-To: <4DA6904A.3090303@oracle.com> References: <479637.89357.qm@web86603.mail.ird.yahoo.com> <4D9CAB29.5090009@oracle.com> <652584.84963.qm@web86605.mail.ird.yahoo.com> <16C637B3-F74E-4658-BEC6-4577ACBC85A8@oracle.com> <490699.26101.qm@web86607.mail.ird.yahoo.com> <4DA6904A.3090303@oracle.com> Message-ID: <268588.79039.qm@web86601.mail.ird.yahoo.com> Hi Sherman, I agree that the update case is different, but always thought that your new zip file system would be a better way to do this rather than unpacking and repacking a jar, which is what happens not isnt it? Forgive me if I am wrong but I never looked at the code in detail for update I will check up on the timing that I get, but it will be after the weekend. It may be that they were skewed by the overhead of the profiler etc. I was running with full instrumentation for those timings Just to be clear I was saying that the CPU time taken was by the hashcode was greater than the CPU time taken in deflate. I am attempting to eliminate any real IO time for the timings I have also started on pipelining the 'expand' and 'create' code sections so that the expand time can be eliminated, if there is no IO contention, and another core available. In this case there is no list stored, just a queue of files to be added For the cf0 case the quick win is not scanning the file twice (once for Adler32 and once for content), which in my tests takes a couple of seconds off the create time regards Mike ________________________________ From: Xueming Shen To: mike.skells at talk21.com Cc: core-libs-dev Libs Sent: Thursday, 14 April, 2011 7:12:26 Subject: Re: proposal to optimise the performance of the Jar utility On 4/13/2011 4:55 PM, mike.skells at talk21.com wrote: Hi Mike, >apart from compression 0 it doesn't make a lot of difference as far as >I see it. As I posted earlier, converting the file name to lower case >seems (according the the NB profiler) to take more time than the >compression File.hashCode() is slow on Windows (yes, we have to go down to String.toLowerCase() to be "correct" and yes, its slow), we have the comment in Win32FileSystem.hashCode() just for this:-) public int hashCode(File f) { /* Could make this more efficient: String.hashCodeIgnoreCase */ return f.getPath().toLowerCase(Locale.ENGLISH).hashCode() ^ 1234321; } I tried to use ArrayList for the "entries" (instead of LinkedHashSet), as showed below (yes, it's total fine to use List for "creating", need a little more work for "updating", but let's put "updating" aside for now) // All files need to be added/updated. //Set entries = new LinkedHashSet(); List entries = new ArrayList(); and run the cf0 on rtjar, which has the rt.jar extracted (time measured by System.currentTimeMillis() [List] $ ../jdk1.7.0/bin/java Main cf0 foo.jar rtjar expand=406, create=10703 expand=406, create=10797 expand=407, create=11046 [Set] $ ../jdk1.7.0/bin/java Main cf0 foo.jar rtjar expand=469, create=10703 expand=469, create=10688 expand=469, create=10656 The "List" version is indeed about 15% faster than the "Set" version, in "expanding", but "expanding" is only about 5% of the over all "creating" time (I've not tried to measure yet, but I will not be surprised to find that we probably spend more time on i/o than deflating) So it is nice to have, but does not appear to bring us some thing "significant". -Sherman > >Bearing in mind that I have tweaked my system so that I am accessing >from cache only, so the elapsed time is pretty much the single core >time, here are the results > > >the result I have re-run today (hence the delay) >in csv format >--- >,cf,cf0,cf1,cf2,cf3,cf4,cf5,cf6,cf7,cf8,cf9 >1.6.0_24 (1.6 vm),10255,9751,,,,,,,,, >java 1.7 release candinate,10498,9663,,,,,,,,, >orig ,10481,9707,,,,,,,,, >buffer CRC32 >data,,7398,9490,9641,9565,10038,10142,10366,10310,10536,10440 >--- >this run shows a 25% improvement in cf0 times (9703 ms vs 7398 wthen >the tweaks are applied) >cf1 (compressed level 1) takes 9490 and cf9 takes 10440, so not a huge >difference > > > > >Regards > > >Mike > > > > > > > ________________________________ From: Mike Duigou >To: mike.skells at talk21.com >Cc: Xueming Shen ; core-libs-dev Libs > >Sent: Wednesday, 13 April, 2011 23:00:26 >Subject: Re: proposal to optimise the performance of the Jar >utility > >Mike, can you share the results of performance testing at various >compression levels? Is there much difference between the levels or >an apparent "sweet spot"? > >For low hanging fruit for jdk 7 it might be worth considering >raising the default compression level from 5 to 6 (the zlib >default). Raising the level from 5 to 6 entails (by today's >standards) very modest increases in the amount of memory and effort >used (16Kb additional buffer space for compression). In general zlib >reflects size choices that are almost 20 years old and it may be of >no measurable benefit to be using the lower compression levels. > >Mike (also) > > >On Apr 12 2011, at 17:48 , mike.skells at talk21.com wrote: > >> Hi Sherman, >> I have had a quick look at the current code to see what 'low >>hanging fruit' >> >> there is. I appreciate that parallelizing the command in its >>entirity may not be >> >> feasible for the first release >> >> The tests that I have run are jarring the content of the 1.7 rt.jar >>with varying >> >> compression levels. Each jar is run as an child process 6 times and >>the average >> >> of the last 5 is taken. Tests are pretty much CPU bound on a single >>core >> >> 1. The performance of the cf0 (create file with no compression) >>path can be >> >> improved for the general case if the file is buffered. >> In my test env (windows 7 64bit) this equates to a 17% time >>performance >> >> improvement in my tests. In the existing code the file is read >>twice, once to >> >> calc the CRC and once to write the file to the Jar file. This >>change would >> >> buffer a single small file at a time (size < 100K) >> >> 2. It is also a trivial fix to allow different compression levels, >>rather than >> >> stored and default >> >> After that it is harder to gain performance improvements without >>structural >> >> change or more discussion >> >> 3. The largest saving after that is in the management of the >>'entries' Set, as >> >> the hashcode of the File is expensive (this may not apply to other >>filesystems). >> >> the management of this map seems to account for more cpu than >>Deflator! >> I cannot see the reason for this data being collected. I am >>probably missing the >> >> obvious ... >> >> 4. After that there is just the parallelisation of the jar utility >>and the >> >> underlying stream >> >> What is the best way to proceed >> >> regards >> >> Mike >> >> >> >> ________________________________ >> From: Xueming Shen >> To: core-libs-dev at openjdk.java.net >> Sent: Wednesday, 6 April, 2011 19:04:25 >> Subject: Re: proposal to optimise the performance of the Jar >>utility >> >> Hi Mike, >> >> We are in the final stage of the JDK7 development, work like this >>is >> >> unlikely to get in the >> last minute. I have filed a CR/RFE to trace this issue, we can use >>this >> >> CR as the start >> point for the discussion and target for some jdk7 update releases >>or JDK8. >> >> 7034403: proposal to optimise the performance of the Jar utility >> >> Thanks, >> Sherman >> >> >> On 04/05/2011 04:42 PM, mike.skells at talk21.com wrote: >>> Hi, >>> Not sure if this is too late for Java 7 but I have made some >>>optimisations for >>> >>> a >>> client to improve the performance of the jar utility in their >>>environment, and >>> would like to promite then into the main code base >>> >>> The optimisations that I have performed are >>> >>> 1. Allowing the Jar utility to have other compression levels >>>(currently it >>> allows default (5) only) >>> 2. Multi-threading, and pipelining the the file information and >>>access >>> 3. multi-threading the compression and file writing >>> >>> A little background >>> A part of the development process of where I work they regularly >>>Jar the >>> >>> content >>> of the working projects as part of the distribution to remote >>>systems. This is >>> >>> a >>> large and complex code base of 6 million LOC and growing. The Jar >>>file ends up >>> compressed to approx 100Mb, Uncompressed the jar size is approx >>>245mb, about >>> >>> 4-5 >>> times the size of rt.jar. >>> >>> I was looking at ways to improve the performance as this activity >>>occurs >>> >>> several >>> times a day for dozens of developers >>> >>> In essence when compressing a new jar file the jar utility is >>>single threaded >>> and staged. Forgive me if this is an oversimplification >>> >>> first it works out all of the files that are specified, buffering >>>the file >>> names, (IO bound) >>> then it iterates through the files, and for each file, it load the >>>file >>> information, and then the file content sending it to a >>>JarOutputStream, (CPU >>> bound or IO bound depending on the IO speed) >>> >>> The JarOutputStream has a compression of 0 (just store) or 5 (the >>>default), >>> >> and >>> the jar writing is single threaded by the design of the >>>JarOutputStream >>> >>> The process of creation of a Jar took about 20 seconds in windows >>>with the >>> >> help >>> of an SSD, and considerable longer without one, and was CPU bound >>>to one CPU >>> core >>> >>> ---- >>> The changes that I made were >>> 1. Allow deferent compression levels (for us a compression level of >>>1 >>> >> increases >>> the file size of the Jar to 110 Mb but reduces the CPU load in >>>compression to >>> approx 30% of what it was (rough estimate) >>> 2. pipelining the file access >>> 2.1 one thread is started for each file root (-C on the Jar >>>command line), >>> which scans for files and places the file information into a >>>blocking >>> >>> queue(Q1), >>> which I set to abretrary size of 200 items >>> 2.2 one thread pool of 10 threads reads the file information >>>from the queue >>> (Q1) and buffers the file content to a specified size (again I >>>specified an >>> arbetrary size limit of 25K for a file, and places the buffered >>>content into a >>> queue(q2) (again arbetrary size of 10 items >>> 2.3 one thread takes the filecontent from Q2 and compresses it >>>or checksums >>> it and adds it the the JarOutputStream. This process is single >>>threaded due >>> >> to >>> the design of the JarOutputStream >>> >>> some other minor performance gain occurred by increasing the buffer >>>on the >>> output stream to reduce the IO load >>> >>> The end result is that the process takes about approx 5 seconds in >>>the same >>> configuration >>> >>> The above is in use in production configuration for a few months >>>now >>> >>> As a home project I have completed some enhancements to the >>>JarOutputStream, >>> >>> and >>> produced a JarWriter that allows multiple threads to work >>>concurrently >>> >>> deflating >>> or calculating checksums, which seems to test OK for the test cases >>>that Ihave >>> generated,and successfully loads my quad core home dev machine on >>>all cores. >>> Each thread allocates a buffer, and the thread compresses a files >>>into the >>> buffer, only blocking other threads whenthe buffer is written to >>>the output >>> (which is after the compression is complete, unless the file is too >>>large to >>> compress >>> >>> This JarWriter is not API compatable with the JarOutputStream, it >>>is not a >>> stream. It allows the programmer to write a record based of the >>>file >>> >>> information >>> and an input stream, and is threadsafe. It is not a drop in >>>replacement for >>> JarOutputStream >>> I am not an expert in the ZIp file format, but much of the code >>>from >>> ZipOutputStream is unchanged, just restructured >>> --- >>> I did think that there is some scope for improvement, that I have >>>not looked >>> >> at >>> a. thresholding of file size for compression (very small files dont >>>compress >>> well >>> b. some file types dont compress well (e.g. png, jpeg) as they have >>>been >>> compressed already) >>> c. using NIO to parallelise the loading of the file information or >>>content >>> d. some pre-charging of the deflator dictionary (e.g. a class file >>>contains >>> >> the >>> strings of the class name and packages), but this would make the >>>format >>> incompatable with zip, and require changes to the JVM to be useful, >>>and is a >>> long way from my comform zone, or skill set. This would reduce the >>>file size >>> >>> -- >>> What is the view of the readers. Is this something, or at least >>>some parts of >>> this that could be incorperated into Java 7 or is this too late on >>>the dev >>> >>> cycle >>> >>> regards >>> >>> Mike > > From mike.skells at talk21.com Thu Apr 14 09:15:35 2011 From: mike.skells at talk21.com (mike.skells at talk21.com) Date: Thu, 14 Apr 2011 09:15:35 +0000 Subject: proposal to optimise the performance of the Jar utility In-Reply-To: <7A4FDE50-0275-4471-AE63-F8B9C0B01A2E@oracle.com> References: <479637.89357.qm@web86603.mail.ird.yahoo.com> <4D9CAB29.5090009@oracle.com> <652584.84963.qm@web86605.mail.ird.yahoo.com> <16C637B3-F74E-4658-BEC6-4577ACBC85A8@oracle.com> <4DA63037.7050601@oracle.com><7A4FDE50-0275-4471-AE63-F8B9C0B01A2E@oracle.com> Message-ID: <1346156442-1302772549-cardhu_decombobulator_blackberry.rim.net-1313984429-@b3.c3.bise7.blackberry> Hi Mike & Sherman, My mistake - not sure where I got that from Regards Mike Sent from my BlackBerry? wireless device -----Original Message----- From: Mike Duigou Date: Wed, 13 Apr 2011 17:02:10 To: Xueming Shen Cc: ; core-libs-dev Libs Subject: Re: proposal to optimise the performance of the Jar utility On Apr 13 2011, at 16:22 , Xueming Shen wrote: > On 04-13-2011 3:00 PM, Mike Duigou wrote: >> Mike, can you share the results of performance testing at various compression levels? Is there much difference between the levels or an apparent "sweet spot"? >> >> For low hanging fruit for jdk 7 it might be worth considering raising the default compression level from 5 to 6 (the zlib default). Raising the level from 5 to 6 entails (by today's > > Hi Mike, > > zlib1.2.3/zlib.h states the default is level 6. I've not checked or run any test to verify if its > implementation matches its docs, any reason you think zlib actually is using level 5 as > default? I can take look into it further... I was basing this on Mike Skells' earlier posting: >>>> 1. Allowing the Jar utility to have other compression levels (currently it >>>> allows default (5) only) If it's using Z_DEFAULT_COMPRESSION then it's actually using 6 as you suggest. Sorry for the confusion. Mike > ... > ZEXTERN int ZEXPORT deflateInit OF((z_streamp strm, int level)); > > Initializes the internal stream state for compression. The fields > zalloc, zfree and opaque must be initialized before by the caller. > If zalloc and zfree are set to Z_NULL, deflateInit updates them to > use default allocation functions. > > The compression level must be Z_DEFAULT_COMPRESSION, or between 0 and 9: > 1 gives best speed, 9 gives best compression, 0 gives no compression at > all (the input data is simply copied a block at a time). > Z_DEFAULT_COMPRESSION requests a default compromise between speed and > compression (currently equivalent to level 6). > ... From michael.x.mcmahon at oracle.com Thu Apr 14 14:06:08 2011 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 14 Apr 2011 15:06:08 +0100 Subject: Review request for 7034570 - java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited In-Reply-To: <4DA5CD33.50609@oracle.com> References: <4DA58A18.8080004@oracle.com> <4DA5B125.7030707@gmx.de> <4DA5CD33.50609@oracle.com> Message-ID: <4DA6FF50.7010308@oracle.com> An updated webrev is available for this fix. I'll probably go ahead with the CCC request for the spec. change anyway. http://cr.openjdk.java.net/~michaelm/7034570/webrev.2/ Thanks, Michael. From Alan.Bateman at oracle.com Thu Apr 14 14:56:51 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Apr 2011 15:56:51 +0100 Subject: Review request for 7034570 - java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited In-Reply-To: <4DA6FF50.7010308@oracle.com> References: <4DA58A18.8080004@oracle.com> <4DA5B125.7030707@gmx.de> <4DA5CD33.50609@oracle.com> <4DA6FF50.7010308@oracle.com> Message-ID: <4DA70B33.7000902@oracle.com> Michael McMahon wrote: > An updated webrev is available for this fix. I'll probably go ahead > with the CCC request for the spec. change anyway. > > http://cr.openjdk.java.net/~michaelm/7034570/webrev.2/ The updated webrev looks much better. A couple of minor suggestions - it might be useful to future maintainers if you put a comment in before the iteration to explain why SystemRoot is needed - it might be neater to add an append(StringBuilder sb, String key, String value) method to append the key=value\u0000 strings rather than doing it in two places - the string "systemroot" is in 3 places, might be nice to make it a constant. Otherwise looks fine to me. -Alan From Ulf.Zibis at gmx.de Thu Apr 14 16:34:41 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 14 Apr 2011 18:34:41 +0200 Subject: Review request for 7034570 - java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited In-Reply-To: <4DA6FF50.7010308@oracle.com> References: <4DA58A18.8080004@oracle.com> <4DA5B125.7030707@gmx.de> <4DA5CD33.50609@oracle.com> <4DA6FF50.7010308@oracle.com> Message-ID: <4DA72221.1010703@gmx.de> You need not to ensure double NUL termination, because now sb.length() is always > 0. -Ulf Am 14.04.2011 16:06, schrieb Michael McMahon: > An updated webrev is available for this fix. I'll probably go ahead > with the CCC request for the spec. change anyway. > > http://cr.openjdk.java.net/~michaelm/7034570/webrev.2/ > > > Thanks, > Michael. > From neil.richards at ngmr.net Thu Apr 14 17:52:20 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Thu, 14 Apr 2011 18:52:20 +0100 Subject: Request for review: 6597112: Referential integrity loophole during remote object export In-Reply-To: <4DA58440.5030503@oracle.com> References: <4D775A58.6010708@oracle.com> <1301000071.25581.16.camel@chalkhill> <4D9F2C58.9050404@oracle.com> <1302283069.32207.58.camel@chalkhill> <6D7ED3FB-E15F-4465-AD1A-BABD4E70E63E@roundroom.net> <4DA58440.5030503@oracle.com> Message-ID: Hi Alan, Thanks for making those modifications. I'm happy with how they look. I'm also happy with the suggested comment being added. I'm away from a computer until the weekend, so can't make the modification myself at the moment, but I'm happy if you want to proceed in getting it in. Thanks again for your help on this, and for the helpful reviews of others, Neil (sent from my mobile phone, so without the usual signature block) From Ulf.Zibis at gmx.de Thu Apr 14 18:02:02 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 14 Apr 2011 20:02:02 +0200 Subject: Review request for 7034570 - java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited In-Reply-To: <4DA72221.1010703@gmx.de> References: <4DA58A18.8080004@oracle.com> <4DA5B125.7030707@gmx.de> <4DA5CD33.50609@oracle.com> <4DA6FF50.7010308@oracle.com> <4DA72221.1010703@gmx.de> Message-ID: <4DA7369A.2050605@gmx.de> Oops, SystemRoot could be null theoretically. So forget my comment about NUL termination. But anyway, should we allow to have get("SystemRoot") != getEnv("SystemRoot")? Is it correct to defaultly set the "SystemRoot" variable on non-Windows OS? Why don't we inherit ProcessEnvironment from TreeMap, sorted by EntryComparator? Then we would not need to sort it later. > The environment block is required to be sorted when you call CreateProcess() on Windows. Shouldn't we handle this OS-dependent? There is no need to sort on non-Windows OS, and if, it should be case-sensitive. Imagine: ProcessEnvironment pe; pe.put("systemroot", "C:\\WINDOWS"); String systemroot = pe.get("SYSTEMROOT"); systemroot would remain null! So I ask, if we wouldn't better implement class ProcessEnvironment OS-dependent? -Ulf Am 14.04.2011 18:34, schrieb Ulf Zibis: > You need not to ensure double NUL termination, because now sb.length() is always > 0. > > -Ulf > > > Am 14.04.2011 16:06, schrieb Michael McMahon: >> An updated webrev is available for this fix. I'll probably go ahead >> with the CCC request for the spec. change anyway. >> >> http://cr.openjdk.java.net/~michaelm/7034570/webrev.2/ >> >> >> Thanks, >> Michael. >> > From Ulf.Zibis at gmx.de Thu Apr 14 20:55:41 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 14 Apr 2011 22:55:41 +0200 Subject: Review request for 7034570 - java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited In-Reply-To: <4DA6FF50.7010308@oracle.com> References: <4DA58A18.8080004@oracle.com> <4DA5B125.7030707@gmx.de> <4DA5CD33.50609@oracle.com> <4DA6FF50.7010308@oracle.com> Message-ID: <4DA75F4D.60809@gmx.de> You can have the code much shorter (and faster): // Only for use by ProcessImpl.start() String toEnvironmentBlock() { // Sort Unicode-case-insensitively by name Map.Entry[] list = entrySet().toArray(new Map.Entry<>[size()]); Arrays.sort(list, entryComparator); StringBuilder sb = new StringBuilder(list.length*30); for (int i = 0, cmp = -1; ; i++) { Map.Entry e = i < list.length ? list[i] : null; final String ROOT = "SystemRoot"; if (cmp < 0 && (e == null || (cmp = nameComparator.compare(e.getKey(), ROOT)) > 0)) { String value = getenv(ROOT); if (value != null) addEnv(sb, ROOT, value); // Ensure double NUL termination, even if environment is empty. else if (list.isEmpty()) sb.append('\u0000'); } if (e == null) break; addEnv(sb, e.getKey(), e.getValue()); } sb.append('\u0000'); return sb.toString(); } // add the environment variable to the child private static void addEnv(StringBuilder sb, String key, String value) { sb.append(key+"="+value+'\u0000'); // under the hood, it compiles to 4 sb.append() } Do you like it? Note: I think, if we use NameComparator, we can use "SystemRoot". -Ulf Am 14.04.2011 16:06, schrieb Michael McMahon: > An updated webrev is available for this fix. I'll probably go ahead > with the CCC request for the spec. change anyway. > > http://cr.openjdk.java.net/~michaelm/7034570/webrev.2/ > > > Thanks, > Michael. > From Ulf.Zibis at gmx.de Thu Apr 14 21:10:11 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 14 Apr 2011 23:10:11 +0200 Subject: Review request for 7034570 - java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited In-Reply-To: <4DA75F4D.60809@gmx.de> References: <4DA58A18.8080004@oracle.com> <4DA5B125.7030707@gmx.de> <4DA5CD33.50609@oracle.com> <4DA6FF50.7010308@oracle.com> <4DA75F4D.60809@gmx.de> Message-ID: <4DA762B3.2050002@gmx.de> If you like, you can save 1 more line: return sb.append('\u0000').toString(); ;-) -Ulf Am 14.04.2011 22:55, schrieb Ulf Zibis: > sb.append('\u0000'); > return sb.toString(); From xueming.shen at oracle.com Thu Apr 14 21:48:24 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 14 Apr 2011 14:48:24 -0700 Subject: Suspected regression: fix for 6735255 causes delay in GC of ZipFile InputStreams, increase in heap demand In-Reply-To: <4DA5C052.6030500@linux.vnet.ibm.com> References: <1300916786.4515.107.camel@chalkhill> <4D922D68.2080202@oracle.com> <1301514810.24605.64.camel@chalkhill> <4D93930A.2000604@oracle.com> <1301676177.24605.165.camel@chalkhill> <4D962275.7010601@oracle.com> <4D965D14.6060504@oracle.com> <1301707718.14323.43.camel@chalkhill> <4D98FD10.4090608@oracle.com> <1302183023.27698.20.camel@chalkhill> <4D9E429F.9030200@oracle.com> <1302266193.17745.18.camel@chalkhill> <4D9FD836.1070909@oracle.com> <1302456482.18865.109.camel@chalkhill> <1302524116.15253.25.camel@chalkhill> <4DA4A8EF.4060103@oracle.com> <4DA5BEFA.30707@linux.vnet.ibm.com> <4DA5C052.6030500@linux.vnet.ibm.com> Message-ID: <4DA76BA8.6000109@oracle.com> Steve, Neil, As we discussed in previous emails that Neil's last patch (to put the inflater into the "streams" as the value of the map) does solve the FinalizeInflater failure issue (provides a "orderly" final cleanup between the "stream" and the "inflater". However to leave releaseInfalter() to be solely driven by GC might delay the inflater to be cached/re-used in a timely manner, even in scenario that those streams get closed explicitly by the invoker. Ideally it is desirable that the inflater can be re-used/put back into the cache when ZFIIS.close() gets invoked explicitly. It appears it might be too hard, if not impossible, to arrange the releaseInflater() to be invoked from both clearStaleStreams()/staleStreamQueue and ZFIIS.close(), given the non-guarantee, by the VM/GC, of the timing/order among the clear up of weak reference objects, enqueue them and the invocation of finalize(). So I would suggest a relatively simple solution as showed in webrev at http://cr.openjdk.java.net/~sherman/7031076/webrev/src/share/classes/java/util/zip/ZipFile.java.sdiff.html (1) simply use the WeakHashMap to keep the pair, we don't try to release/put the used inflater back to cache, if the ZFIIS stream does not get closed explicitly (its underlying ZFIS stream and the inflater will then get finalized by themself). (2) release the inflater back to cache in ZFIIS.close(), only if the inflater is sill "alive" in the "streams", which guarantees that the inflater is not being finalized and safe to put back to cache (so long as we have the weak reference -> inflater pair in "streams", it does not matter if the reference to ZFIIS object is cleared or not). In most cases, I would expect when the ZFIIS.close() is invoked, both ZFIIS object and its inflater are still reachable, so the inflater gets re-used as expected. In "weird" scenario like what we have in FinalizeInflater, the ZFIIS object and its outer wrapper object are being finalized when ZFIIS.close() gets invoked (from wrapper.finalize()), there is possibility that the inflater might not be put back to cache, if the weak reverence->inflater pair has been expunged out of the "streams" already (because the weak reference to ZFIIS might have been cleared, so its entry in "streams" can be expunged any time, by any thread. At this moment, the inflater object might be declared as "un-reachable" and no longer safe to put back into cache), but I think we can live with this "missing". (3) I realized that we actually are not removing the closed ZFIIS objects (only the ZFIS objects are removed when closed) from "streams" even though those input streams are closed gracefully by the invoker (as preferred, suggested, desired), which means all those ZFIIS streams will stay in "streams" (strong referenced in current implementation), no matter whether or not they get closed explicitly, until the ZipFile object itself gets closed/finalized. This might contribute to the problem Neil observed at first place (the ZipFile InputStreams accumulat in heap), actually I do have another incident report #7033523 which I have closed as the dup of #7031076. Opinion? anything I overlooked/missed? -Sherman On 04/13/2011 08:25 AM, Steve Poole wrote: > On 13/04/11 16:19, Steve Poole wrote: >> On 12/04/11 20:33, Xueming Shen wrote: >>> Hi Neil, >> >> >> Hi Sherman , Neil is out on vacation so I will do my best to stand >> in for him. >>> >>> (1) I believe it would be better to keep the synchronization lock >>> for get/releaseInfalter() >>> "local" instead of using the "global" ZipFile.this, which I >>> agree is "simple". But it also >>> means each/every time when you release the used inflater back >>> to cache, ZipFile.this >>> has to be held and any possible/potential read operation on >>> ZipFile from other thead/ >>> inputstream has to wait ("get" seems fine, the current impl >>> holds the ZipFile.this >>> anyway before reach the getInflater()). >> Ok - I agree - seems sensible. (Though I reserve the right to >> contradict myself later) >>> >>> (2) The "resource" Infalter mainly holds is the native memory block >>> it alloc-ed at native >>> for zlib, which is not in the Java heap, so I doubt making it >>> "softly" really helps for GC. >>> Sure, cleanup of those "objects" themself is a plus, but I'm >>> not sure if it is really worth >>> using SoftReference in this case (it appears you are now >>> invoking clearStaleStreams() >>> from the finalize()). >> I'd like to keep this in - not all implementations of zlib are equal >> in where they allocate memory. >>> >>> (3) The releaseInfalter() is now totally driven from >>> clearStaleStreams()/staleStreamQueue, >>> which is under full control of GC. If GC does not kick in for >>> hours/days, infalters can never >>> be put back into its cache after use, even the applications >>> correctly/promptly close those >>> streams after use. And when the GC kicks in, we might see >>> "bunch" (hundreds, thousands) >>> of inflaters get pushed into cache. The approach does solve the >>> "timing" issue that got >>> us here, but it also now has this "native memory cache" >>> mechanism totally under the >>> control of/driven by the GC, the java heap management >>> mechanism, which might not be >>> a preferred scenario. Just wonder if we can have a better >>> choice, say with this GC-driven >>> as the backup cleanup and meanwhile still have the >>> ZFIIS.close() to do something to safely >>> put the used inflater back to cache promptly. To put the >>> infalter as the value of the "streams" >>> map appears to be a good idea/start, now the "infalter" will >>> not be targeted for finalized >>> until the entry gets cleaned from the map, in which might in >>> fact provide us a sort of >>> "orderly" (between the "stream" and its "inflater") clearup >>> that the GC/finalizer can't >>> guarantee. We still have couple days before we hit the >>> "deadline" (to get this one in), so it >>> might worth taking some time on this direction? >>> > > Dang! - pressed send when I meant save. I understand your comments - > on the face of it I agree with what you're suggesting - let me think > it through some more though. >> What is this "deadline" you are talking about? >> >>> -Sherman >>> >>> >>> >>> >>> >>> On 04/11/2011 05:15 AM, Neil Richards wrote: >>>> On Sun, 2011-04-10 at 18:28 +0100, Neil Richards wrote: >>>>> With releaseInflater() being driven from the cleanup of stale >>>>> 'streams' >>>>> entries, it no longer needs to be called from ZFIIS.close(), so, >>>>> instead, only Inflater.reset() is called from there (providing the >>>>> inflater object has not explicitly been ended) so that it releases >>>>> the >>>>> buffer it has been holding. >>>> Actually, I have a slight change of heart on this aspect. >>>> >>>> Because close() may be driven from a finalize() method in user code >>>> (as >>>> is done in the InflaterFinalizer test case), I believe it is possible >>>> (albeit unlikely) for an inflater object to have been reclaimed from >>>> 'streams' (by a call to clearStaleStreams()), put into the inflater >>>> cache, retrieved from there (by another thread creating an input >>>> stream) >>>> and having started to be used by that other stream at the point at >>>> which >>>> the code in close() is run. >>>> >>>> (This is because weak references will be cleared, and *may* be >>>> queued on >>>> the ReferenceQueue, prior to finalization). >>>> >>>> Because of this, it's not actually entirely safe now to call >>>> inf.reset() >>>> from ZFIIS.close(). >>>> >>>> Instead, I have added additional calls to clearStaleStreams() from the >>>> finalize() methods of both InputStream implementations in the latest >>>> (hopefully in the meaning of "last") changeset included below. >>>> >>>> As always, please get back to me with any comments, questions or >>>> suggestions on this, >>>> Thanks, >>>> Neil >>>> >>> >> > From stuart.marks at oracle.com Thu Apr 14 23:01:12 2011 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 14 Apr 2011 16:01:12 -0700 Subject: advice & review requested for 6896297, race condition in rmid causing JCK failure In-Reply-To: <15C8B16F-4EAB-40E0-B926-7882A1D5793C@roundroom.net> References: <4D9E3867.7030004@oracle.com> <15C8B16F-4EAB-40E0-B926-7882A1D5793C@roundroom.net> Message-ID: <4DA77CB8.8010709@oracle.com> Hi Peter, Thanks for your comments on this issue. I understand from Alan that you have some expertise in RMI; it's most welcome here. It's good to hear that serialization compatibility isn't that big of a deal. This makes things easier. It would seem reasonable to investigate replacing HashMap with ConcurrentHashMap, which would remove a fair bit of the external locking, and reduce or eliminate the need for a complex locking hierarchy along with a big comment that describes it. This will also make it easier to retrofit a coarser locking strategy if necessary; see below. Converting instances of HM to CHM if necessary upon deserialization is probably a good idea and isn't too difficult. The larger issue of snapshot consistency is indeed troubling. I'd agree that the ConcurrentModificationException is a symptom of a larger problem and that making it go away (either with a different locking strategy or using CHM) is mostly merely suppressing the symptom without addressing the larger issue. The immediate need, though, is to fix the JCK failure, so I suspect what I'll need to do is to push a fix for the CME and handle the resolution of any larger issue separately. I'll investigate an alternative fix that uses CHM instead of modified external locking, and I'll post an updated webrev. s'marks On 4/13/11 11:14 PM, Peter Jones wrote: > Stuart, > > A couple of comments so far: > > I don't think that there would be a serialization compatibility problem with changing Activation.groupTable to have a ConcurrentHashMap instead of a HashMap. The field's declared type is Map, so the deserialization process would be able to assign either class to the field, and the code doesn't otherwise care about the Map implementation class. An rmid's state created with CHM could not be recoverable with JDK 1.4, of course, but I don't think that that's a concern. The fix would not help an rmid whose state gets recovered from an earlier version created with HM, unless a replacement (HM->CHM) was also done upon deserialization. > > More troubling I think is the higher-level issue suggested by this ConcurrentModificationException. Thread B (in the 6896297 Evaluation) is attempting to write a "snapshot" of the entire persistent state of the Activation instance, which presumably should be consistent with future "updates" written to the log, while Thread A is concurrently attempting to mutate that state (before writing an update for its mutation). It seems highly doubtful that potentially including an uncertain amount of this concurrent mutation in the written snapshot is safe. I might expect a coarser lock to be used across all such mutations, together with their associated log writes (at which point groupTable wouldn't need to be concurrent). > > The approach at your webrev below seems OK to address the immediate ConcurrentModificationException, but (unless I'm missing something) the higher-level issue with snapshot correctness described above would remain. > > Cheers, > > -- Peter > > P.S. This seems somewhat related to http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4945726 > > > On Apr 7, 2011, at 6:19 PM, Stuart Marks wrote: > >> Hi Core-Libs developers, >> >> I'd like to solicit some advice and discussion about this bug and a potential fix I'm cooking for it. Here is the bug report; it contains details about the problem and my analysis of it: >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6896297 >> >> and here's a webrev of the fix I'm working on: >> >> http://cr.openjdk.java.net/~smarks/reviews/6896297/webrev.0/ >> >> Briefly, the problem is incorrect synchronization of groupTable, a HashMap field of an Activation object. The code mostly locks groupTable around any access to it. However, no such locking is done during serialization. If the groupTable is modified while it's being serialized, ConcurrentModificationException occurs. >> >> The obvious fix would be to use ConcurrentHashMap instead of Hashmap and to remove the external locking entirely. Unfortunately this will change the serialized representation of the Activation object, which I'm not sure is acceptable. >> >> Assuming that we can't change the serialized represenation, the alternative approach would be to make sure that locking is done properly during serialization. This is fairly easy to do by locking groupTable in a writeObject() method. Unfortunately, this introduces a deadlock. >> >> This deadlock occurs because, with this modification, there are now paths through the code that take locks in the opposite order. Specifically, the addLogRecord() method locks the log object and then (via serialization and the newly added writeObject() method) locks groupTable. However, the unregisterGroup() method locks groupTable and calls GroupEntry.unregisterGroup() which logs the event, which takes a lock on the log. >> >> After some analysis, I've determined that the call to GroupEntry.unregisterGroup() can be moved outside the synchronization of groupTable. This removes the ordering problem. >> >> With these fixes in place (the state of the webrev above) I can get several hundred successful test runs with neither ConcurrentModificationException nor any deadlocks. >> >> Of course, that doesn't mean the change is correct. :-) >> >> Questions: >> >> 1. Is there a requirement that the serialized form of Activation remain unchanged? If we can change it, we might as well just use ConcurrentHashMap instead of HashMap. >> >> 2. Is my lock ordering analysis correct? I've pored over the code, but not really being familiar with any RMI concepts, I'm not sure I have it right. I've written this analysis into a big comment I've added to the code. >> >> 3. There is also a potential concurrency issue with idTable, which is used similarly to groupTable. I haven't seen a test failure from it though. It seems sensible to add a lock for it in Activation.writeObject() though. I don't particularly like nesting the locks of idTable and groupTable, but locking them separately would require serializing the Activation object field by field instead of simply using defaultWriteObject(). Is this a reasonable approach? >> >> Thanks for any advice or comments. >> >> s'marks >> > From David.Holmes at oracle.com Thu Apr 14 23:44:12 2011 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 15 Apr 2011 09:44:12 +1000 Subject: Review request for 7034570 - java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited In-Reply-To: <4DA7369A.2050605@gmx.de> References: <4DA58A18.8080004@oracle.com> <4DA5B125.7030707@gmx.de> <4DA5CD33.50609@oracle.com> <4DA6FF50.7010308@oracle.com> <4DA72221.1010703@gmx.de> <4DA7369A.2050605@gmx.de> Message-ID: <4DA786CC.1060903@oracle.com> Ulf, Ulf Zibis said the following on 04/15/11 04:02: > Oops, SystemRoot could be null theoretically. So forget my comment about > NUL termination. > > But anyway, should we allow to have get("SystemRoot") != > getEnv("SystemRoot")? > > Is it correct to defaultly set the "SystemRoot" variable on non-Windows OS? This ProcessEnvironment.java is a Windows specific file. David > Why don't we inherit ProcessEnvironment from TreeMap, sorted by > EntryComparator? > Then we would not need to sort it later. > > > The environment block is required to be sorted when you call > CreateProcess() on Windows. > Shouldn't we handle this OS-dependent? There is no need to sort on > non-Windows OS, and if, it should be case-sensitive. > > Imagine: > ProcessEnvironment pe; > pe.put("systemroot", "C:\\WINDOWS"); > String systemroot = pe.get("SYSTEMROOT"); > > systemroot would remain null! > So I ask, if we wouldn't better implement class ProcessEnvironment > OS-dependent? > > -Ulf > > > Am 14.04.2011 18:34, schrieb Ulf Zibis: >> You need not to ensure double NUL termination, because now sb.length() >> is always > 0. >> >> -Ulf >> >> >> Am 14.04.2011 16:06, schrieb Michael McMahon: >>> An updated webrev is available for this fix. I'll probably go ahead >>> with the CCC request for the spec. change anyway. >>> >>> http://cr.openjdk.java.net/~michaelm/7034570/webrev.2/ >>> >>> >>> Thanks, >>> Michael. >>> >> From David.Holmes at oracle.com Fri Apr 15 01:03:33 2011 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 15 Apr 2011 11:03:33 +1000 Subject: Review request for 7034570 - java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited In-Reply-To: <4DA6FF50.7010308@oracle.com> References: <4DA58A18.8080004@oracle.com> <4DA5B125.7030707@gmx.de> <4DA5CD33.50609@oracle.com> <4DA6FF50.7010308@oracle.com> Message-ID: <4DA79965.8050708@oracle.com> Hi Michael, Michael McMahon said the following on 04/15/11 00:06: > An updated webrev is available for this fix. I'll probably go ahead > with the CCC request for the spec. change anyway. > > http://cr.openjdk.java.net/~michaelm/7034570/webrev.2/ Based on Alan's comments I checked for and found webrev.3 so that's what I reviewed :) Minor nit: + private final static String systemroot = "systemroot"; constant names are usually all-caps. So if I understand the logic here, if we find SystemRoot in the passed in environment then we simply use that for the child. Else we check if it is set in the parents environment, and if so we add that to the childs environment. Else neither parent nor child have it. So my only nit with this is that addEnv(sb, systemroot) gives the initial appearance of adding to the environment when in fact it only conditionally adds. Perhaps addToEnvIfSet(sb, systemroot) ? Minor nit: + .append("=") could be a char instead of String: + .append('=') Why do we append the NUL in addEnv when we do that at the end of the method anyway? Does it require double termination? David > > Thanks, > Michael. From joe.darcy at oracle.com Fri Apr 15 04:27:30 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 15 Apr 2011 04:27:30 +0000 Subject: hg: jdk7/tl/jdk: 6430675: Math.round has surprising behavior for 0x1.fffffffffffffp-2 Message-ID: <20110415042740.8B90E47AE1@hg.openjdk.java.net> Changeset: 2d89d0d1e0ff Author: darcy Date: 2011-04-14 21:27 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2d89d0d1e0ff 6430675: Math.round has surprising behavior for 0x1.fffffffffffffp-2 Reviewed-by: alanb ! src/share/classes/java/lang/Math.java ! src/share/classes/java/lang/StrictMath.java + test/java/lang/Math/RoundTests.java From Ulf.Zibis at gmx.de Fri Apr 15 08:34:27 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 15 Apr 2011 10:34:27 +0200 Subject: Review request for 7034570 - java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited In-Reply-To: <4DA786CC.1060903@oracle.com> References: <4DA58A18.8080004@oracle.com> <4DA5B125.7030707@gmx.de> <4DA5CD33.50609@oracle.com> <4DA6FF50.7010308@oracle.com> <4DA72221.1010703@gmx.de> <4DA7369A.2050605@gmx.de> <4DA786CC.1060903@oracle.com> Message-ID: <4DA80313.9060408@gmx.de> Am 15.04.2011 01:44, schrieb David Holmes: > Ulf, > > Ulf Zibis said the following on 04/15/11 04:02: >> Oops, SystemRoot could be null theoretically. So forget my comment about NUL termination. >> >> But anyway, should we allow to have get("SystemRoot") != getEnv("SystemRoot")? >> >> Is it correct to defaultly set the "SystemRoot" variable on non-Windows OS? > > This ProcessEnvironment.java is a Windows specific file. > Much thanks David for clarification. IMHO there should be a big hint in this file: ////////////////////////////////////////////////////////////////////////////////// // This is the Windows implementation of this class! // ////////////////////////////////////////////////////////////////////////////////// -Ulf From Alan.Bateman at oracle.com Fri Apr 15 08:50:58 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 15 Apr 2011 09:50:58 +0100 Subject: Review request for 7034570 - java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited In-Reply-To: <4DA80313.9060408@gmx.de> References: <4DA58A18.8080004@oracle.com> <4DA5B125.7030707@gmx.de> <4DA5CD33.50609@oracle.com> <4DA6FF50.7010308@oracle.com> <4DA72221.1010703@gmx.de> <4DA7369A.2050605@gmx.de> <4DA786CC.1060903@oracle.com> <4DA80313.9060408@gmx.de> Message-ID: <4DA806F2.3020301@oracle.com> Ulf Zibis wrote: > > IMHO there should be a big hint in this file: > > ////////////////////////////////////////////////////////////////////////////////// > > // This is the Windows implementation of this class! // > ////////////////////////////////////////////////////////////////////////////////// > > > -Ulf > I don't think this is needed because all files in the src/windows/** tree are Windows specific. -Alan. From Ulf.Zibis at gmx.de Fri Apr 15 09:05:12 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 15 Apr 2011 11:05:12 +0200 Subject: Review request for 7034570 - java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited In-Reply-To: <4DA806F2.3020301@oracle.com> References: <4DA58A18.8080004@oracle.com> <4DA5B125.7030707@gmx.de> <4DA5CD33.50609@oracle.com> <4DA6FF50.7010308@oracle.com> <4DA72221.1010703@gmx.de> <4DA7369A.2050605@gmx.de> <4DA786CC.1060903@oracle.com> <4DA80313.9060408@gmx.de> <4DA806F2.3020301@oracle.com> Message-ID: <4DA80A48.40201@gmx.de> Am 15.04.2011 10:50, schrieb Alan Bateman: > Ulf Zibis wrote: >> >> IMHO there should be a big hint in this file: >> >> ////////////////////////////////////////////////////////////////////////////////// >> // This is the Windows implementation of this class! // >> ////////////////////////////////////////////////////////////////////////////////// >> >> -Ulf >> > I don't think this is needed because all files in the src/windows/** tree are Windows specific. > Thanks Alan. I had opened the file from JDK's src.zip, the most easy way from NetBeans IDE, and there is no src/windows/** tree. So normal JDK user might be irritated even more if referring to the shipped sources, and if not aware about the branches in hg repository. -Ulf From michael.x.mcmahon at oracle.com Fri Apr 15 09:45:09 2011 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 15 Apr 2011 10:45:09 +0100 Subject: Review request for 7034570 - java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited In-Reply-To: <4DA75F4D.60809@gmx.de> References: <4DA58A18.8080004@oracle.com> <4DA5B125.7030707@gmx.de> <4DA5CD33.50609@oracle.com> <4DA6FF50.7010308@oracle.com> <4DA75F4D.60809@gmx.de> Message-ID: <4DA813A5.5070606@oracle.com> Ulf, It seems the NameComparator class uses exactly the same algorithm as the CASE_INSENSITIVE_ORDER comparator provided by the String class. So, it probably makes sense to replace NameComparator with the one from String (one less class in rt.jar :) ) On "SystemRoot" vs "systemroot", I had thought that Windows required the sort to be case-sensitive. But, I double-checked and it doesn't. So we can use "SystemRoot". I think your original comment about not needing the check for sb being empty was correct. On Windows, we are ensuring that SystemRoot will at a minimum always be set. I'll send another webrev later reflecting these and David's comments. - Michael. Ulf Zibis wrote: > You can have the code much shorter (and faster): > > // Only for use by ProcessImpl.start() > String toEnvironmentBlock() { > // Sort Unicode-case-insensitively by name > Map.Entry[] list = entrySet().toArray(new > Map.Entry<>[size()]); > Arrays.sort(list, entryComparator); > > StringBuilder sb = new StringBuilder(list.length*30); > for (int i = 0, cmp = -1; ; i++) { > Map.Entry e = i < list.length ? list[i] : > null; > final String ROOT = "SystemRoot"; > if (cmp < 0 && (e == null || (cmp = > nameComparator.compare(e.getKey(), ROOT)) > 0)) { > String value = getenv(ROOT); > if (value != null) > addEnv(sb, ROOT, value); > // Ensure double NUL termination, even if environment > is empty. > else if (list.isEmpty()) > sb.append('\u0000'); > } > if (e == null) break; > addEnv(sb, e.getKey(), e.getValue()); > } > sb.append('\u0000'); > return sb.toString(); > } > > // add the environment variable to the child > private static void addEnv(StringBuilder sb, String key, String > value) { > sb.append(key+"="+value+'\u0000'); // under the hood, it > compiles to 4 sb.append() > } > > Do you like it? > > Note: I think, if we use NameComparator, we can use "SystemRoot". > > -Ulf > > > Am 14.04.2011 16:06, schrieb Michael McMahon: >> An updated webrev is available for this fix. I'll probably go ahead >> with the CCC request for the spec. change anyway. >> >> http://cr.openjdk.java.net/~michaelm/7034570/webrev.2/ >> >> >> Thanks, >> Michael. >> From michael.x.mcmahon at oracle.com Fri Apr 15 09:52:46 2011 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 15 Apr 2011 10:52:46 +0100 Subject: Review request for 7034570 - java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited In-Reply-To: <4DA813A5.5070606@oracle.com> References: <4DA58A18.8080004@oracle.com> <4DA5B125.7030707@gmx.de> <4DA5CD33.50609@oracle.com> <4DA6FF50.7010308@oracle.com> <4DA75F4D.60809@gmx.de> <4DA813A5.5070606@oracle.com> Message-ID: <4DA8156E.7040101@oracle.com> Michael McMahon wrote: oops. This isn't correct. Sorry. .... > It seems the NameComparator class uses exactly the same algorithm as the > CASE_INSENSITIVE_ORDER comparator provided by the String class. So, > it probably makes sense to replace NameComparator with the one from > String > (one less class in rt.jar :) ) - Michael. From Alan.Bateman at oracle.com Fri Apr 15 09:54:15 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 15 Apr 2011 10:54:15 +0100 Subject: Review request for 7034570 - java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited In-Reply-To: <4DA813A5.5070606@oracle.com> References: <4DA58A18.8080004@oracle.com> <4DA5B125.7030707@gmx.de> <4DA5CD33.50609@oracle.com> <4DA6FF50.7010308@oracle.com> <4DA75F4D.60809@gmx.de> <4DA813A5.5070606@oracle.com> Message-ID: <4DA815C7.2000500@oracle.com> Michael McMahon wrote: > > On Windows, we are ensuring that SystemRoot will at a minimum always > be set. Don't you still have the corner case where Runtime.exec is invoked with an empty array and SystemRoot is not in the environment (launched by an older JDK for example)? In that case we can't make SystemRoot available to the child process either. -Alan From michael.x.mcmahon at oracle.com Fri Apr 15 09:59:13 2011 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 15 Apr 2011 10:59:13 +0100 Subject: Review request for 7034570 - java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited In-Reply-To: <4DA815C7.2000500@oracle.com> References: <4DA58A18.8080004@oracle.com> <4DA5B125.7030707@gmx.de> <4DA5CD33.50609@oracle.com> <4DA6FF50.7010308@oracle.com> <4DA75F4D.60809@gmx.de> <4DA813A5.5070606@oracle.com> <4DA815C7.2000500@oracle.com> Message-ID: <4DA816F1.8050600@oracle.com> Alan Bateman wrote: > Michael McMahon wrote: >> >> On Windows, we are ensuring that SystemRoot will at a minimum always >> be set. > Don't you still have the corner case where Runtime.exec is invoked > with an empty array and SystemRoot is not in the environment (launched > by an older JDK for example)? In that case we can't make SystemRoot > available to the child process either. > Yes, that's right. Thanks, Michael From Ulf.Zibis at gmx.de Fri Apr 15 11:03:40 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 15 Apr 2011 13:03:40 +0200 Subject: Review request for 7034570 - java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited In-Reply-To: <4DA815C7.2000500@oracle.com> References: <4DA58A18.8080004@oracle.com> <4DA5B125.7030707@gmx.de> <4DA5CD33.50609@oracle.com> <4DA6FF50.7010308@oracle.com> <4DA75F4D.60809@gmx.de> <4DA813A5.5070606@oracle.com> <4DA815C7.2000500@oracle.com> Message-ID: <4DA8260C.6040606@gmx.de> Am 15.04.2011 11:54, schrieb Alan Bateman: > Michael McMahon wrote: >> >> On Windows, we are ensuring that SystemRoot will at a minimum always be set. > Don't you still have the corner case where Runtime.exec is invoked with an empty array and > SystemRoot is not in the environment (launched by an older JDK for example)? In that case we can't > make SystemRoot available to the child process either. > ... and then on some versions of MSVCRT.DLL the whole thing will crash ?? Again I ask if we shouldn't disallow to user-define the "SystemRoot" variable on Windows? Imagine someone has set the variable to "C:\WINDOWS", but the correct value is "D:\WINDOWS". -Ulf From Ulf.Zibis at gmx.de Fri Apr 15 11:35:03 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 15 Apr 2011 13:35:03 +0200 Subject: Review request for 7034570 - java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited In-Reply-To: <4DA813A5.5070606@oracle.com> References: <4DA58A18.8080004@oracle.com> <4DA5B125.7030707@gmx.de> <4DA5CD33.50609@oracle.com> <4DA6FF50.7010308@oracle.com> <4DA75F4D.60809@gmx.de> <4DA813A5.5070606@oracle.com> Message-ID: <4DA82D67.2060900@gmx.de> Am 15.04.2011 11:45, schrieb Michael McMahon: > Ulf, > > On "SystemRoot" vs "systemroot", I had thought that Windows required the sort > to be case-sensitive. But, I double-checked and it doesn't. So we can use "SystemRoot". If that would be true, we wouldn't need to sort by CASE_INSENSITIVE_ORDER or rather NameComparator. ;-) Again my question: What you think of my below code? I think we only need 1 call site to insert the potentially missing "SystemRoot" variable, a simple array is faster than initializing a needless j.u.List, and boolean foundSysRoot is redundant to int cmp. Additionally I think having the addEnv method is too disproportionate. We can just inline 2 different String-catenations, and it should compile to 3/4 sb.append() under the hood. So here my shortest version: // Only for use by ProcessImpl.start() String toEnvironmentBlock() { // Sort Unicode-case-insensitively by name Map.Entry[] list = entrySet().toArray(new Map.Entry<>[size()]); Arrays.sort(list, entryComparator); StringBuilder sb = new StringBuilder(list.length*30); for (int i = 0, cmp = -1; ; i++) { Map.Entry e = i < list.length ? list[i] : null; // Some versions of MSVCRT.DLL require SystemRoot to be set: final String ROOT = "SystemRoot"; if (cmp < 0 && (e == null || (cmp = nameComparator.compare(e.getKey(), ROOT)) > 0)) { String value = getenv(ROOT); if (value != null) sb.append(ROOT+'='+value+'\u0000'); // Ensure double NUL termination, even if environment is empty. else if (list.length == 0) sb.append('\u0000'); } if (e == null) break; sb.append(e.getKey()+'='+e.getValue()+'\u0000'); } // Ensure double NUL termination return sb.append('\u0000').toString(); } -Ulf > > Ulf Zibis wrote: >> You can have the code much shorter (and faster): >> >> // Only for use by ProcessImpl.start() >> String toEnvironmentBlock() { >> // Sort Unicode-case-insensitively by name >> Map.Entry[] list = entrySet().toArray(new Map.Entry<>[size()]); >> Arrays.sort(list, entryComparator); >> >> StringBuilder sb = new StringBuilder(list.length*30); >> for (int i = 0, cmp = -1; ; i++) { >> Map.Entry e = i < list.length ? list[i] : null; >> final String ROOT = "SystemRoot"; >> if (cmp < 0 && (e == null || (cmp = nameComparator.compare(e.getKey(), ROOT)) > 0)) { >> String value = getenv(ROOT); >> if (value != null) >> addEnv(sb, ROOT, value); >> // Ensure double NUL termination, even if environment is empty. >> else if (list.length == 0) >> sb.append('\u0000'); >> } >> if (e == null) break; >> addEnv(sb, e.getKey(), e.getValue()); >> } >> // Ensure double NUL termination >> return sb.append('\u0000').toString(); >> } >> >> // add the environment variable to the child >> private static void addEnv(StringBuilder sb, String key, String value) { >> sb.append(key+'='+value+'\u0000'); // under the hood, it compiles to 4 sb.append() >> } >> >> Do you like it? >> >> Note: I think, if we use NameComparator, we can use "SystemRoot". >> >> -Ulf From Alan.Bateman at oracle.com Fri Apr 15 12:15:35 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 15 Apr 2011 13:15:35 +0100 Subject: Review request for 7034570 - java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited In-Reply-To: <4DA8260C.6040606@gmx.de> References: <4DA58A18.8080004@oracle.com> <4DA5B125.7030707@gmx.de> <4DA5CD33.50609@oracle.com> <4DA6FF50.7010308@oracle.com> <4DA75F4D.60809@gmx.de> <4DA813A5.5070606@oracle.com> <4DA815C7.2000500@oracle.com> <4DA8260C.6040606@gmx.de> Message-ID: <4DA836E7.8050200@oracle.com> Ulf Zibis wrote: > : > > Again I ask if we shouldn't disallow to user-define the "SystemRoot" > variable on Windows? > Imagine someone has set the variable to "C:\WINDOWS", but the correct > value is "D:\WINDOWS". No, I don't think we should silently change the value of this or other variables. -Alan. From Ulf.Zibis at gmx.de Fri Apr 15 12:45:46 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 15 Apr 2011 14:45:46 +0200 Subject: Review request for 7034570 - java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited In-Reply-To: <4DA836E7.8050200@oracle.com> References: <4DA58A18.8080004@oracle.com> <4DA5B125.7030707@gmx.de> <4DA5CD33.50609@oracle.com> <4DA6FF50.7010308@oracle.com> <4DA75F4D.60809@gmx.de> <4DA813A5.5070606@oracle.com> <4DA815C7.2000500@oracle.com> <4DA8260C.6040606@gmx.de> <4DA836E7.8050200@oracle.com> Message-ID: <4DA83DFA.9050207@gmx.de> Am 15.04.2011 14:15, schrieb Alan Bateman: > Ulf Zibis wrote: >> : >> >> Again I ask if we shouldn't disallow to user-define the "SystemRoot" variable on Windows? >> Imagine someone has set the variable to "C:\WINDOWS", but the correct value is "D:\WINDOWS". > No, I don't think we should silently change the value of this or other variables. I don't think about silently changing, I think about to *disallow to set* it e.g. by the put() method, and instead retrieve it by default from constructor, so it could be always read by the get() method. -Ulf From Alan.Bateman at oracle.com Fri Apr 15 13:18:41 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 15 Apr 2011 14:18:41 +0100 Subject: Review request for 7034570 - java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited In-Reply-To: <4DA83DFA.9050207@gmx.de> References: <4DA58A18.8080004@oracle.com> <4DA5B125.7030707@gmx.de> <4DA5CD33.50609@oracle.com> <4DA6FF50.7010308@oracle.com> <4DA75F4D.60809@gmx.de> <4DA813A5.5070606@oracle.com> <4DA815C7.2000500@oracle.com> <4DA8260C.6040606@gmx.de> <4DA836E7.8050200@oracle.com> <4DA83DFA.9050207@gmx.de> Message-ID: <4DA845B1.4050306@oracle.com> Ulf Zibis wrote: > > > I don't think about silently changing, I think about to *disallow to > set* it e.g. by the put() method, and instead retrieve it by default > from constructor, so it could be always read by the get() method. Ah, you mean the environment returned by ProcessBuilder where the spec does allow the Map to forbid changing certain variables. I don't see this working for the Runtime.exec case as we can't change these methods to fail if the environment includes SystemRoot. The other case is where the environment is initially cleared (in ProcessBuilder's class description it has a note suggesting to use the clear method to start a process with an explicit set of environment variables). All told, I think Michael's approach to ensure that SystemRoot is in the child environment is reasonable. -Alan. From michael.x.mcmahon at oracle.com Fri Apr 15 13:43:45 2011 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 15 Apr 2011 14:43:45 +0100 Subject: Review request for 7034570 - java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited In-Reply-To: <4DA83DFA.9050207@gmx.de> References: <4DA58A18.8080004@oracle.com> <4DA5B125.7030707@gmx.de> <4DA5CD33.50609@oracle.com> <4DA6FF50.7010308@oracle.com> <4DA75F4D.60809@gmx.de> <4DA813A5.5070606@oracle.com> <4DA815C7.2000500@oracle.com> <4DA8260C.6040606@gmx.de> <4DA836E7.8050200@oracle.com> <4DA83DFA.9050207@gmx.de> Message-ID: <4DA84B91.30607@oracle.com> Ulf Zibis wrote: > Am 15.04.2011 14:15, schrieb Alan Bateman: >> Ulf Zibis wrote: >>> : >>> >>> Again I ask if we shouldn't disallow to user-define the "SystemRoot" >>> variable on Windows? >>> Imagine someone has set the variable to "C:\WINDOWS", but the >>> correct value is "D:\WINDOWS". >> No, I don't think we should silently change the value of this or >> other variables. > > I don't think about silently changing, I think about to *disallow to > set* it e.g. by the put() method, and instead retrieve it by default > from constructor, so it could be always read by the get() method. > > -Ulf > I have incorporated much of Ulf's approach into this version. I agree with Alan about the spec. We could find other variables in the future that need to be set, but can have alternative values other than the default. I think this approach is the most flexible. http://cr.openjdk.java.net/~michaelm/7034570/webrev.4/ Thanks Michael. From mandy.chung at oracle.com Fri Apr 15 17:01:32 2011 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 15 Apr 2011 10:01:32 -0700 Subject: Review Request (1-line fix): 7032589 "FileHandler leaking file descriptor of the file lock" Message-ID: <4DA879EC.80200@oracle.com> Fix for 7032589: FileHandler leaking file descriptor of the file lock Webrev at: http://cr.openjdk.java.net/~mchung/jdk7/7032589/webrev.00/ When a log file is currently being used, tryLock() will fail and it has to close the file channel of the lock file Thanks Mandy From daniel.daugherty at oracle.com Fri Apr 15 17:55:17 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 15 Apr 2011 11:55:17 -0600 Subject: Review Request (1-line fix): 7032589 "FileHandler leaking file descriptor of the file lock" In-Reply-To: <4DA879EC.80200@oracle.com> References: <4DA879EC.80200@oracle.com> Message-ID: <4DA88685.3040202@oracle.com> Thumbs up. Dan On 4/15/2011 11:01 AM, Mandy Chung wrote: > Fix for 7032589: FileHandler leaking file descriptor of the file lock > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk7/7032589/webrev.00/ > > When a log file is currently being used, tryLock() will fail and it > has to close the file channel of the lock file > > Thanks > Mandy From forax at univ-mlv.fr Fri Apr 15 18:05:53 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 15 Apr 2011 20:05:53 +0200 Subject: Review Request (1-line fix): 7032589 "FileHandler leaking file descriptor of the file lock" In-Reply-To: <4DA88685.3040202@oracle.com> References: <4DA879EC.80200@oracle.com> <4DA88685.3040202@oracle.com> Message-ID: <4DA88901.8020509@univ-mlv.fr> On 04/15/2011 07:55 PM, Daniel D. Daugherty wrote: > Thumbs up. > > Dan Hi Mandy, if fc.close() throws an IOException , it goes wrong. I think you need to put fc.close() in its own a try/catch(IOException). R?mi > > > On 4/15/2011 11:01 AM, Mandy Chung wrote: >> Fix for 7032589: FileHandler leaking file descriptor of the file lock >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk7/7032589/webrev.00/ >> >> When a log file is currently being used, tryLock() will fail and it >> has to close the file channel of the lock file >> >> Thanks >> Mandy From lance.andersen at oracle.com Fri Apr 15 18:54:16 2011 From: lance.andersen at oracle.com (Lance Andersen - Oracle) Date: Fri, 15 Apr 2011 14:54:16 -0400 Subject: Review needed for 7037085 : Add hashCode() to Timestamp to address Findbugs warning Message-ID: Hi all, Need a reviewer for the following minor change which adds hasCode() to Timestamp to address a Findbugs warning. Regards Lance hg diff diff -r d9248245a88c src/share/classes/java/sql/Timestamp.java --- a/src/share/classes/java/sql/Timestamp.java Wed Apr 13 11:21:36 2011 -0400 +++ b/src/share/classes/java/sql/Timestamp.java Fri Apr 15 14:34:07 2011 -0400 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1996, 2010, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1996, 2011, Oracle and/or its affiliates. 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 @@ -515,6 +515,18 @@ } } + /** + * {@inheritDoc} + * + * The {@code hashcode} method uses the underlying {@code java.util.Date} + * implementation and therefore does not include nanos in its computation. + * + */ + @Override + public int hashCode() { + return super.hashCode(); + } + static final long serialVersionUID = 2745179027874758501L; } Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From mandy.chung at oracle.com Fri Apr 15 19:12:05 2011 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 15 Apr 2011 12:12:05 -0700 Subject: Review Request (1-line fix): 7032589 "FileHandler leaking file descriptor of the file lock" In-Reply-To: <4DA88901.8020509@univ-mlv.fr> References: <4DA879EC.80200@oracle.com> <4DA88685.3040202@oracle.com> <4DA88901.8020509@univ-mlv.fr> Message-ID: <4DA89885.9050201@oracle.com> Hi Remi, On 04/15/11 11:05, R?mi Forax wrote: > Hi Mandy, > if fc.close() throws an IOException , it goes wrong. > I think you need to put fc.close() in its own a try/catch(IOException). > That's a good point. I think it should throw IOException if anything goes wrong with fc.close(). Revised the fix: http://cr.openjdk.java.net/~mchung/jdk7/7032589/webrev.01/ The existing implementation looks a bit suspicious as it silently ignores the IOException thrown by tryLock() and uses that lock file. I am inclined to leave the existing behavior as it is to minimize behavioral change. And just resolve this file descriptor leak issue in this fix. I'll open a bug to follow up this. 412 try { 413 FileLock fl = fc.tryLock(); 414 if (fl == null) { 415 // We failed to get the lock. Try next file. 416 continue; 417 } 418 // We got the lock OK. 419 } catch (IOException ix) { 420 // We got an IOException while trying to get the lock. 421 // This normally indicates that locking is not supported 422 // on the target directory. We have to proceed without 423 // getting a lock. Drop through. 424 } Mandy From lance.andersen at oracle.com Fri Apr 15 19:45:04 2011 From: lance.andersen at oracle.com (Lance Andersen - Oracle) Date: Fri, 15 Apr 2011 15:45:04 -0400 Subject: Review needed for 7037085 : Add hashCode() to Timestamp to address Findbugs warning In-Reply-To: <4DA89E7F.9070903@oracle.com> References: <4DA89E7F.9070903@oracle.com> Message-ID: Hi Eamonn The javadocs for Timestamp have always specifically called the following blurb out in the class description. Based on some side discussions, it was best to also copy this blurb to the added hashCode method (you will see the text at the top of Timestamp) for additional clarity. Regards Lance On Apr 15, 2011, at 3:37 PM, Eamonn McManus wrote: > This isn't wrong, but wouldn't it be simpler to just add or xor the nanos field into the hashcode, rather than explicitly saying that you don't? > ?amonn > > On 15/4/11 8:54 PM, Lance Andersen - Oracle wrote: >> >> Hi all, >> >> Need a reviewer for the following minor change which adds hasCode() to Timestamp to address a Findbugs warning. >> >> Regards >> Lance >> >> >> hg diff >> diff -r d9248245a88c src/share/classes/java/sql/Timestamp.java >> --- a/src/share/classes/java/sql/Timestamp.java Wed Apr 13 11:21:36 2011 -0400 >> +++ b/src/share/classes/java/sql/Timestamp.java Fri Apr 15 14:34:07 2011 -0400 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 1996, 2010, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 1996, 2011, Oracle and/or its affiliates. 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 >> @@ -515,6 +515,18 @@ >> } >> } >> >> + /** >> + * {@inheritDoc} >> + * >> + * The {@code hashcode} method uses the underlying {@code java.util.Date} >> + * implementation and therefore does not include nanos in its computation. >> + * >> + */ >> + @Override >> + public int hashCode() { >> + return super.hashCode(); >> + } >> + >> static final long serialVersionUID = 2745179027874758501L; >> >> } >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From daniel.daugherty at oracle.com Fri Apr 15 20:41:35 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 15 Apr 2011 14:41:35 -0600 Subject: Review Request (1-line fix): 7032589 "FileHandler leaking file descriptor of the file lock" In-Reply-To: <4DA89885.9050201@oracle.com> References: <4DA879EC.80200@oracle.com> <4DA88685.3040202@oracle.com> <4DA88901.8020509@univ-mlv.fr> <4DA89885.9050201@oracle.com> Message-ID: <4DA8AD7F.2000305@oracle.com> On 4/15/2011 1:12 PM, Mandy Chung wrote: > Hi Remi, > > On 04/15/11 11:05, R?mi Forax wrote: >> Hi Mandy, >> if fc.close() throws an IOException , it goes wrong. >> I think you need to put fc.close() in its own a try/catch(IOException). >> > > That's a good point. I think it should throw IOException if anything > goes wrong with fc.close(). Revised the fix: > http://cr.openjdk.java.net/~mchung/jdk7/7032589/webrev.01/ Thumbs up on this version. > > The existing implementation looks a bit suspicious as it silently > ignores the IOException thrown by tryLock() and uses that lock file. I think that the existing code is remembering the lock file name even which IOOException is thrown because of the assumption that IOException is only thrown when locking is not supported on the target directory. By remembering the lock file name, any further attempt to lock the file by the same process doesn't result in a another tryLock() call with another resulting IOException. It is troubling that this code is giving a false assurance that the file system object is locked when it isn't. In the case where an IOException was thrown by tryLock(), the file system object is only locked in the context of the current process. That seems to make it easy for two different processes to both think that they have the file system object locked. Potential train wreck down the road? Quite possibly. > I am inclined to leave the existing behavior as it is to minimize > behavioral change. And just resolve this file descriptor leak issue > in this fix. Agreed that this bug should address the leak and that a new bug should be opened for the possible locking issue. Dan > I'll open a bug to follow up this. > > 412 try { > 413 FileLock fl = fc.tryLock(); > 414 if (fl == null) { > 415 // We failed to get the lock. Try next > file. > 416 continue; > 417 } > 418 // We got the lock OK. > 419 } catch (IOException ix) { > 420 // We got an IOException while trying to get > the lock. > 421 // This normally indicates that locking is > not supported > 422 // on the target directory. We have to > proceed without > 423 // getting a lock. Drop through. > 424 } > > Mandy > > > From mandy.chung at oracle.com Fri Apr 15 20:55:35 2011 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 15 Apr 2011 13:55:35 -0700 Subject: Review Request (1-line fix): 7032589 "FileHandler leaking file descriptor of the file lock" In-Reply-To: <4DA8AD7F.2000305@oracle.com> References: <4DA879EC.80200@oracle.com> <4DA88685.3040202@oracle.com> <4DA88901.8020509@univ-mlv.fr> <4DA89885.9050201@oracle.com> <4DA8AD7F.2000305@oracle.com> Message-ID: <4DA8B0C7.6030103@oracle.com> On 04/15/11 13:41, Daniel D. Daugherty wrote: > On 4/15/2011 1:12 PM, Mandy Chung wrote: >> Hi Remi, >> >> On 04/15/11 11:05, R?mi Forax wrote: >>> Hi Mandy, >>> if fc.close() throws an IOException , it goes wrong. >>> I think you need to put fc.close() in its own a try/catch(IOException). >>> >> >> That's a good point. I think it should throw IOException if anything >> goes wrong with fc.close(). Revised the fix: >> http://cr.openjdk.java.net/~mchung/jdk7/7032589/webrev.01/ > > Thumbs up on this version. > Thanks for the review. > > Agreed that this bug should address the leak and that a new > bug should be opened for the possible locking issue. > I created a CR 7037134: Potential writing to the same log file by multiple processes Mandy From forax at univ-mlv.fr Fri Apr 15 22:57:46 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sat, 16 Apr 2011 00:57:46 +0200 Subject: Review Request (1-line fix): 7032589 "FileHandler leaking file descriptor of the file lock" In-Reply-To: <4DA8B0C7.6030103@oracle.com> References: <4DA879EC.80200@oracle.com> <4DA88685.3040202@oracle.com> <4DA88901.8020509@univ-mlv.fr> <4DA89885.9050201@oracle.com> <4DA8AD7F.2000305@oracle.com> <4DA8B0C7.6030103@oracle.com> Message-ID: <4DA8CD6A.8080902@univ-mlv.fr> On 04/15/2011 10:55 PM, Mandy Chung wrote: > On 04/15/11 13:41, Daniel D. Daugherty wrote: >> On 4/15/2011 1:12 PM, Mandy Chung wrote: >>> Hi Remi, >>> >>> On 04/15/11 11:05, R?mi Forax wrote: >>>> Hi Mandy, >>>> if fc.close() throws an IOException , it goes wrong. >>>> I think you need to put fc.close() in its own a >>>> try/catch(IOException). >>>> >>> >>> That's a good point. I think it should throw IOException if >>> anything goes wrong with fc.close(). Revised the fix: >>> http://cr.openjdk.java.net/~mchung/jdk7/7032589/webrev.01/ >> >> Thumbs up on this version. >> > > Thanks for the review. > >> >> Agreed that this bug should address the leak and that a new >> bug should be opened for the possible locking issue. >> > > I created a CR 7037134: Potential writing to the same log file by > multiple processes > > Mandy > Hi Mandy, Minor nit, initializing available when declaring it is not necessary because both path (with or without exception) initialize it later. otherwise, I'm Ok with the patch. R?mi From valerie.peng at oracle.com Sat Apr 16 00:14:17 2011 From: valerie.peng at oracle.com (valerie.peng at oracle.com) Date: Sat, 16 Apr 2011 00:14:17 +0000 Subject: hg: jdk7/tl/jdk: 7035115: sun/security/pkcs11/Provider/ConfigShortPath.java compilation failed Message-ID: <20110416001440.4815047B18@hg.openjdk.java.net> Changeset: 131ed7967996 Author: valeriep Date: 2011-04-15 15:56 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/131ed7967996 7035115: sun/security/pkcs11/Provider/ConfigShortPath.java compilation failed Summary: Updated the test to use reflection and skip when SunPKCS11 provider not present. Reviewed-by: weijun ! test/sun/security/pkcs11/Provider/ConfigShortPath.java From mandy.chung at oracle.com Sat Apr 16 01:29:20 2011 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 15 Apr 2011 18:29:20 -0700 Subject: Review Request (1-line fix): 7032589 "FileHandler leaking file descriptor of the file lock" In-Reply-To: <4DA8CD6A.8080902@univ-mlv.fr> References: <4DA879EC.80200@oracle.com> <4DA88685.3040202@oracle.com> <4DA88901.8020509@univ-mlv.fr> <4DA89885.9050201@oracle.com> <4DA8AD7F.2000305@oracle.com> <4DA8B0C7.6030103@oracle.com> <4DA8CD6A.8080902@univ-mlv.fr> Message-ID: <4DA8F0F0.4030800@oracle.com> On 4/15/11 3:57 PM, R?mi Forax wrote: > > Hi Mandy, > Minor nit, initializing available when declaring it is not necessary > because both > path (with or without exception) initialize it later. > Sure. Will fix that before the push. > otherwise, I'm Ok with the patch. > Thanks Mandy From mandy.chung at oracle.com Sat Apr 16 06:42:35 2011 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Sat, 16 Apr 2011 06:42:35 +0000 Subject: hg: jdk7/tl/jdk: 7032589: FileHandler leaking file descriptor of the file lock Message-ID: <20110416064245.18FEC47B28@hg.openjdk.java.net> Changeset: 54d9513f87a4 Author: mchung Date: 2011-04-15 23:42 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/54d9513f87a4 7032589: FileHandler leaking file descriptor of the file lock Reviewed-by: forax, dcubed ! src/share/classes/java/util/logging/FileHandler.java From Alan.Bateman at oracle.com Sat Apr 16 09:49:42 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 16 Apr 2011 10:49:42 +0100 Subject: Review Request (1-line fix): 7032589 "FileHandler leaking file descriptor of the file lock" In-Reply-To: <4DA8B0C7.6030103@oracle.com> References: <4DA879EC.80200@oracle.com> <4DA88685.3040202@oracle.com> <4DA88901.8020509@univ-mlv.fr> <4DA89885.9050201@oracle.com> <4DA8AD7F.2000305@oracle.com> <4DA8B0C7.6030103@oracle.com> Message-ID: <4DA96636.5040301@oracle.com> Mandy Chung wrote: > : > I created a CR 7037134: Potential writing to the same log file by > multiple processes I don't see anything in the logging API that requires the log file to be locked but my guess is that this code is there for cases where the log file is on a NFS server and the lock daemon isn't running. -Alan. From roger.riggs at oracle.com Sat Apr 16 09:50:30 2011 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Sat, 16 Apr 2011 02:50:30 -0700 (PDT) Subject: Auto Reply: core-libs-dev Digest, Vol 48, Issue 41 Message-ID: <918437db-a4ea-4164-8b3a-e69c4cd95a08@default> Roger is out of the office until 4/19 with limited access to email. From Alan.Bateman at oracle.com Sat Apr 16 10:48:10 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 16 Apr 2011 11:48:10 +0100 Subject: Review request for 7034570 - java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited In-Reply-To: <4DA84B91.30607@oracle.com> References: <4DA58A18.8080004@oracle.com> <4DA5B125.7030707@gmx.de> <4DA5CD33.50609@oracle.com> <4DA6FF50.7010308@oracle.com> <4DA75F4D.60809@gmx.de> <4DA813A5.5070606@oracle.com> <4DA815C7.2000500@oracle.com> <4DA8260C.6040606@gmx.de> <4DA836E7.8050200@oracle.com> <4DA83DFA.9050207@gmx.de> <4DA84B91.30607@oracle.com> Message-ID: <4DA973EA.6050705@oracle.com> Michael McMahon wrote: > I have incorporated much of Ulf's approach into this version. > > I agree with Alan about the spec. We could find other variables in the > future that need > to be set, but can have alternative values other than the default. I > think this approach > is the most flexible. > > http://cr.openjdk.java.net/~michaelm/7034570/webrev.4/ This looks much better - thanks Ulf for the improved loop and changing it to use nameComparator. It will be good to get this one fixed. -Alan From schlosna at gmail.com Sat Apr 16 14:45:37 2011 From: schlosna at gmail.com (David Schlosnagle) Date: Sat, 16 Apr 2011 10:45:37 -0400 Subject: Review request for 7034570 - java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited In-Reply-To: <4DA973EA.6050705@oracle.com> References: <4DA58A18.8080004@oracle.com> <4DA5B125.7030707@gmx.de> <4DA5CD33.50609@oracle.com> <4DA6FF50.7010308@oracle.com> <4DA75F4D.60809@gmx.de> <4DA813A5.5070606@oracle.com> <4DA815C7.2000500@oracle.com> <4DA8260C.6040606@gmx.de> <4DA836E7.8050200@oracle.com> <4DA83DFA.9050207@gmx.de> <4DA84B91.30607@oracle.com> <4DA973EA.6050705@oracle.com> Message-ID: On Sat, Apr 16, 2011 at 6:48 AM, Alan Bateman wrote: > Michael McMahon wrote: >> >> I have incorporated much of Ulf's approach into this version. >> >> I agree with Alan about the spec. We could find other variables in the >> future that need >> to be set, but can have alternative values other than the default. I think >> this approach >> is the most flexible. >> >> http://cr.openjdk.java.net/~michaelm/7034570/webrev.4/ > > This looks much better - thanks Ulf for the improved loop and changing it to > use nameComparator. It will be good to get this one fixed. One minor nit in ProcessEnvironment.java 336 private static void addToEnv(StringBuilder sb, String name, String val) { 337 sb.append(name+"="+val+'\u0000'); 338 } I think it should be as follows to avoid implicitly constructing another StringBuilder and the extra copying overhead; 336 private static void addToEnv(StringBuilder sb, String name, String val) { 337 sb.append(name).append('=').append(val).append('\u0000'); 338 } - Dave From Alan.Bateman at oracle.com Sat Apr 16 16:33:18 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 16 Apr 2011 17:33:18 +0100 Subject: 7036582: Improve test coverage of java.math.BigDecimal Message-ID: <4DA9C4CE.9050901@oracle.com> This is webrev with new tests for BigDecimal that have been contributed by Sergey Kuksenko. The motive is to improve the test coverage to facilitate improvements to BigDecimal in the future. Joe Darcy has already reviewed the tests so I'm okay for a reviewer. http://cr.openjdk.java.net/~alanb/7036582/webrev/ -Alan. From alan.bateman at oracle.com Sun Apr 17 12:50:30 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 17 Apr 2011 12:50:30 +0000 Subject: hg: jdk7/tl/jdk: 7036582: Improve test coverage of java.math.BigDecimal Message-ID: <20110417125102.EC2A247B78@hg.openjdk.java.net> Changeset: 007b2535a7f5 Author: alanb Date: 2011-04-17 13:49 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/007b2535a7f5 7036582: Improve test coverage of java.math.BigDecimal Reviewed-by: darcy Contributed-by: sergey.kuksenko at oracle.com ! test/ProblemList.txt + test/java/math/BigDecimal/DivideMcTests.java ! test/java/math/BigDecimal/FloatDoubleValueTests.java + test/java/math/BigDecimal/RangeTests.java ! test/java/math/BigDecimal/StrippingZerosTest.java ! test/java/math/BigDecimal/ToPlainStringTests.java From Ulf.Zibis at gmx.de Sun Apr 17 17:27:23 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sun, 17 Apr 2011 19:27:23 +0200 Subject: Review request for 7034570 - java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited In-Reply-To: References: <4DA58A18.8080004@oracle.com> <4DA5B125.7030707@gmx.de> <4DA5CD33.50609@oracle.com> <4DA6FF50.7010308@oracle.com> <4DA75F4D.60809@gmx.de> <4DA813A5.5070606@oracle.com> <4DA815C7.2000500@oracle.com> <4DA8260C.6040606@gmx.de> <4DA836E7.8050200@oracle.com> <4DA83DFA.9050207@gmx.de> <4DA84B91.30607@oracle.com> <4DA973EA.6050705@oracle.com> Message-ID: <4DAB22FB.8000405@gmx.de> Am 16.04.2011 16:45, schrieb David Schlosnagle: > One minor nit in ProcessEnvironment.java > > 336 private static void addToEnv(StringBuilder sb, String name, > String val) { > 337 sb.append(name+"="+val+'\u0000'); > 338 } > > I think it should be as follows to avoid implicitly constructing > another StringBuilder and the extra copying overhead; > > 336 private static void addToEnv(StringBuilder sb, String name, > String val) { > 337 sb.append(name).append('=').append(val).append('\u0000'); > 338 } > Because this suggestion was from me, I must admit, that I didn't prove, if javac actually uses the existing StringBuilder sb, or forces another StringBuilder to instantiate. I just assumed, javac would use the existing one. So to be done: - examine the byte code - if not yet optimized: then new RFE for javac Sorry, if I was wrong. -Ulf From lana.steuck at oracle.com Sun Apr 17 17:49:10 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sun, 17 Apr 2011 17:49:10 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20110417174930.6140047B90@hg.openjdk.java.net> Changeset: 718617820e53 Author: dwanvik Date: 2011-04-15 23:01 +0200 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/718617820e53 7036048: Bring the Java DB in JDK7 to the same level as JDK 6 (Java DB v10.6.2.1) Summary: Replace the existing Java DB bundles with newer ones, and move demo dir into JDK's demo dir as db Reviewed-by: ohair ! make/common/Release.gmk Changeset: 6939022fa093 Author: dwanvik Date: 2011-04-17 16:21 +0200 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6939022fa093 Merge From schlosna at gmail.com Sun Apr 17 20:50:23 2011 From: schlosna at gmail.com (David Schlosnagle) Date: Sun, 17 Apr 2011 16:50:23 -0400 Subject: Review request for 7034570 - java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited In-Reply-To: <4DAB22FB.8000405@gmx.de> References: <4DA58A18.8080004@oracle.com> <4DA5B125.7030707@gmx.de> <4DA5CD33.50609@oracle.com> <4DA6FF50.7010308@oracle.com> <4DA75F4D.60809@gmx.de> <4DA813A5.5070606@oracle.com> <4DA815C7.2000500@oracle.com> <4DA8260C.6040606@gmx.de> <4DA836E7.8050200@oracle.com> <4DA83DFA.9050207@gmx.de> <4DA84B91.30607@oracle.com> <4DA973EA.6050705@oracle.com> <4DAB22FB.8000405@gmx.de> Message-ID: On Sun, Apr 17, 2011 at 1:27 PM, Ulf Zibis wrote: > Am 16.04.2011 16:45, schrieb David Schlosnagle: >> >> One minor nit in ProcessEnvironment.java >> >> ?336 ? ? private static void addToEnv(StringBuilder sb, String name, >> String val) { >> ?337 ? ? ? ? sb.append(name+"="+val+'\u0000'); >> ?338 ? ? } >> >> I think it should be as follows to avoid implicitly constructing >> another StringBuilder and the extra copying overhead; >> >> ?336 ? ? private static void addToEnv(StringBuilder sb, String name, >> String val) { >> ?337 ? ? ? ? sb.append(name).append('=').append(val).append('\u0000'); >> ?338 ? ? } >> > > Because this suggestion was from me, I must admit, that I didn't prove, if > javac actually uses the existing StringBuilder sb, or forces another > StringBuilder to instantiate. I just assumed, javac would use the existing > one. So to be done: > - examine the byte code > - if not yet optimized: then new RFE for javac Ulf, I'm not the right person to comment on whether javac could safely optimize away the StringBuilder creation here per JLS 15.18.1 [1] [2], but in this situation I'd assume that the expression name+"="+val+'\u0000' must return a "result is a reference to a String object (newly created, unless the expression is a compile-time constant expression (?15.28))that is the concatenation of the two operand strings" in which case I don't think javac can optimize it away. Some IDEs such as IntelliJ offer code inspections to find and fix such items, see "String concatenation inside 'StringBuffer.append()'" [3]: This inspection reports any instances of String concatenation used as the argument to StringBuffer.append(), StringBuilder.append() or Appendable.append(). Such calls may profitably be turned into chained append calls on the existing StringBuffer/Builder/Appendable, saving the cost of an extra StringBuffer/Builder allocation. This inspection ignores compile time evaluated String concatenations, which when converted to chained append calls would only worsen performance. Here's a quick `javap -c -private` dump of these two different methods in a test class, showing that the changes I'm recommending simplify the bytecode and avoid the extra StringBuilder construction and copying of underlying characters: Before: private static void addToEnv(StringBuilder sb, String name, String val) { sb.append(name+"="+val+'\u0000'); } Yields: private static void addToEnv(java.lang.StringBuilder, java.lang.String, java.lang.String); Code: 0: aload_0 1: new #2; //class java/lang/StringBuilder 4: dup 5: invokespecial #3; //Method java/lang/StringBuilder."":()V 8: aload_1 9: invokevirtual #8; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder; 12: ldc #9; //String = 14: invokevirtual #8; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder; 17: aload_2 18: invokevirtual #8; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder; 21: iconst_0 22: invokevirtual #10; //Method java/lang/StringBuilder.append:(C)Ljava/lang/StringBuilder; 25: invokevirtual #11; //Method java/lang/StringBuilder.toString:()Ljava/lang/String; 28: invokevirtual #8; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder; 31: pop 32: return ---- After: private static void addToEnv(StringBuilder sb, String name, String val) { sb.append(name).append('=').append(val).append('\u0000'); } Yields: private static void addToEnv(java.lang.StringBuilder, java.lang.String, java.lang.String); Code: 0: aload_0 1: aload_1 2: invokevirtual #8; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder; 5: bipush 61 7: invokevirtual #10; //Method java/lang/StringBuilder.append:(C)Ljava/lang/StringBuilder; 10: aload_2 11: invokevirtual #8; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder; 14: iconst_0 15: invokevirtual #10; //Method java/lang/StringBuilder.append:(C)Ljava/lang/StringBuilder; 18: pop 19: return [1] http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.18.1 [2] http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.18.1.2 [3] http://www.jetbrains.com/idea/documentation/inspections/StringConcatenationInsideStringBufferAppend.html - Dave From lana.steuck at oracle.com Mon Apr 18 04:45:47 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 18 Apr 2011 04:45:47 +0000 Subject: hg: jdk7/tl/jaxp: 4 new changesets Message-ID: <20110418044547.8FD6A47BAA@hg.openjdk.java.net> Changeset: d19dd3dd599e Author: schien Date: 2011-04-07 15:21 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/d19dd3dd599e Added tag jdk7-b137 for changeset 1d87f7460cde ! .hgtags Changeset: bc701b263f16 Author: ohair Date: 2011-04-06 20:15 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/bc701b263f16 7033660: Update copyright year to 2011 on any files changed in 2011 Reviewed-by: dholmes ! build-defs.xml ! build-drop-template.xml ! build.xml ! jaxp.properties ! make/Makefile Changeset: be3758943770 Author: ohair Date: 2011-04-12 18:36 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/be3758943770 Merge Changeset: 28c7c0ed2444 Author: schien Date: 2011-04-14 15:21 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/28c7c0ed2444 Added tag jdk7-b138 for changeset be3758943770 ! .hgtags From lana.steuck at oracle.com Mon Apr 18 04:45:47 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 18 Apr 2011 04:45:47 +0000 Subject: hg: jdk7/tl/jaxws: 5 new changesets Message-ID: <20110418044547.991C647BAB@hg.openjdk.java.net> Changeset: 6dfcea9f7a4e Author: schien Date: 2011-04-07 15:21 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/6dfcea9f7a4e Added tag jdk7-b137 for changeset ccea3282991c ! .hgtags Changeset: de11bd049d6f Author: ohair Date: 2011-04-06 20:16 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/de11bd049d6f 7033660: Update copyright year to 2011 on any files changed in 2011 Reviewed-by: dholmes ! build-defs.xml ! build-drop-template.xml ! build.xml ! make/Makefile Changeset: cc956c8a8255 Author: ohair Date: 2011-04-12 18:36 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/cc956c8a8255 Merge Changeset: c025078c8362 Author: schien Date: 2011-04-14 15:21 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/c025078c8362 Added tag jdk7-b138 for changeset cc956c8a8255 ! .hgtags Changeset: 97c69227f325 Author: lana Date: 2011-04-17 16:30 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/97c69227f325 Merge From lana.steuck at oracle.com Mon Apr 18 04:45:47 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 18 Apr 2011 04:45:47 +0000 Subject: hg: jdk7/tl: 5 new changesets Message-ID: <20110418044547.99F2F47BAC@hg.openjdk.java.net> Changeset: f911d742c40a Author: schien Date: 2011-04-07 15:20 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/f911d742c40a Added tag jdk7-b137 for changeset 7654afc6a29e ! .hgtags Changeset: 574b71659cb1 Author: lana Date: 2011-04-10 10:17 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/574b71659cb1 Merge Changeset: 7e13dbf7e8af Author: ohair Date: 2011-04-06 22:14 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/7e13dbf7e8af 7033660: Update copyright year to 2011 on any files changed in 2011 Reviewed-by: dholmes ! Makefile ! make/Defs-internal.gmk ! make/corba-rules.gmk ! make/deploy-rules.gmk ! make/hotspot-rules.gmk ! make/install-rules.gmk ! make/jaxp-rules.gmk ! make/jaxws-rules.gmk ! make/jdk-rules.gmk ! make/langtools-rules.gmk ! make/scripts/update_copyright_year.sh ! make/sponsors-rules.gmk ! test/Makefile Changeset: fc47c97bbbd9 Author: ohair Date: 2011-04-12 18:35 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/fc47c97bbbd9 Merge ! test/Makefile Changeset: 7ed6d0b9aaa1 Author: schien Date: 2011-04-14 15:21 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/7ed6d0b9aaa1 Added tag jdk7-b138 for changeset fc47c97bbbd9 ! .hgtags From lana.steuck at oracle.com Mon Apr 18 04:45:47 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 18 Apr 2011 04:45:47 +0000 Subject: hg: jdk7/tl/corba: 6 new changesets Message-ID: <20110418044551.8B76A47BAD@hg.openjdk.java.net> Changeset: 99f186b8097f Author: schien Date: 2011-04-07 15:20 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/99f186b8097f Added tag jdk7-b137 for changeset a66c01d8bf89 ! .hgtags Changeset: 53c6f4ad1e06 Author: ohair Date: 2011-04-06 20:36 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/53c6f4ad1e06 7033660: Update copyright year to 2011 on any files changed in 2011 Reviewed-by: dholmes ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_de.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_es.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_fr.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_it.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_ja.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_ko.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_pt_BR.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_sv.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_zh_CN.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_zh_TW.properties ! src/share/classes/com/sun/corba/se/spi/logging/data/Activation.mc ! src/share/classes/com/sun/corba/se/spi/logging/data/IOR.mc ! src/share/classes/com/sun/corba/se/spi/logging/data/Interceptors.mc ! src/share/classes/com/sun/corba/se/spi/logging/data/Naming.mc ! src/share/classes/com/sun/corba/se/spi/logging/data/OMG.mc ! src/share/classes/com/sun/corba/se/spi/logging/data/ORBUtil.mc ! src/share/classes/com/sun/corba/se/spi/logging/data/POA.mc ! src/share/classes/com/sun/corba/se/spi/logging/data/Util.mc Changeset: 63cbb2c9c88c Author: mfang Date: 2011-04-08 15:24 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/63cbb2c9c88c 7034940: message drop 2 translation integration Reviewed-by: yhuang ! 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_ja.prp ! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable_zh_CN.prp Changeset: 2f8ada17792a Author: mfang Date: 2011-04-11 13:36 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/2f8ada17792a Merge Changeset: 78d8cf04697e Author: mfang Date: 2011-04-11 14:09 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/78d8cf04697e Merge Changeset: 60b074ec6fcf Author: schien Date: 2011-04-14 15:21 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/60b074ec6fcf Added tag jdk7-b138 for changeset 78d8cf04697e ! .hgtags From lana.steuck at oracle.com Mon Apr 18 04:45:47 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 18 Apr 2011 04:45:47 +0000 Subject: hg: jdk7/tl/langtools: 9 new changesets Message-ID: <20110418044606.5593047BAE@hg.openjdk.java.net> Changeset: aa4f494c17ef Author: schien Date: 2011-04-07 15:21 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/aa4f494c17ef Added tag jdk7-b137 for changeset a15c9b058ae0 ! .hgtags Changeset: de8bb6fa070c Author: lana Date: 2011-04-10 10:25 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/de8bb6fa070c Merge Changeset: 0ff2bbd38f10 Author: ohair Date: 2011-04-06 20:33 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/0ff2bbd38f10 7033660: Update copyright year to 2011 on any files changed in 2011 Reviewed-by: dholmes ! make/netbeans/langtools/build.xml ! make/tools/GenStubs/GenStubs.java ! src/share/bin/launcher.sh-template ! src/share/classes/com/sun/tools/apt/resources/apt_ja.properties ! src/share/classes/com/sun/tools/apt/resources/apt_zh_CN.properties ! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Content.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/main/OptionName.java ! src/share/classes/com/sun/tools/javac/main/RecognizedOptions.java ! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java ! src/share/classes/com/sun/tools/javac/nio/PathFileObject.java ! src/share/classes/com/sun/tools/javac/resources/compiler_ja.properties ! src/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties ! src/share/classes/com/sun/tools/javac/resources/javac_ja.properties ! src/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties ! src/share/classes/com/sun/tools/javac/util/Names.java ! src/share/classes/com/sun/tools/javac/util/Options.java ! src/share/classes/com/sun/tools/javadoc/resources/javadoc_ja.properties ! src/share/classes/com/sun/tools/javadoc/resources/javadoc_zh_CN.properties ! src/share/classes/com/sun/tools/javah/resources/l10n_ja.properties ! src/share/classes/com/sun/tools/javah/resources/l10n_zh_CN.properties ! test/tools/javac/4917091/Test255.java ! test/tools/javac/4917091/Test256a.java ! test/tools/javac/4917091/Test256b.java ! test/tools/javac/ClassPathTest/ClassPathTest.sh ! test/tools/javac/ExtDirs/ExtDirs.sh ! test/tools/javac/Paths/Help.sh ! test/tools/javac/diags/CheckResourceKeys.java ! test/tools/javac/javazip/Test.sh ! test/tools/javac/meth/TestCP.java ! test/tools/javac/meth/XlintWarn.java ! test/tools/javac/options/T6900037.java ! test/tools/javac/scope/HashCollisionTest.java ! test/tools/javac/scope/StarImportTest.java ! test/tools/javac/types/GenericTypeWellFormednessTest.java ! test/tools/javac/types/TypeHarness.java ! test/tools/javac/varargs/6199075/T6199075.java ! test/tools/javac/varargs/warning/Warn4.java ! test/tools/javac/varargs/warning/Warn5.java ! test/tools/javac/versions/check.sh Changeset: 7278b5b61c17 Author: mfang Date: 2011-04-08 15:25 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/7278b5b61c17 7034940: message drop 2 translation integration Reviewed-by: yhuang ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_ja.properties ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_zh_CN.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_ja.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_zh_CN.properties ! src/share/classes/com/sun/tools/javac/resources/compiler_ja.properties ! src/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties ! src/share/classes/com/sun/tools/javac/resources/javac_ja.properties ! src/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties ! src/share/classes/com/sun/tools/javadoc/resources/javadoc_ja.properties ! src/share/classes/com/sun/tools/javadoc/resources/javadoc_zh_CN.properties Changeset: d042f2ca7e85 Author: mfang Date: 2011-04-11 14:01 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d042f2ca7e85 Merge Changeset: 6f8bb109a65b Author: mfang Date: 2011-04-11 16:31 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/6f8bb109a65b Merge ! src/share/classes/com/sun/tools/javac/resources/compiler_ja.properties ! src/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties ! src/share/classes/com/sun/tools/javac/resources/javac_ja.properties ! src/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties ! src/share/classes/com/sun/tools/javadoc/resources/javadoc_ja.properties ! src/share/classes/com/sun/tools/javadoc/resources/javadoc_zh_CN.properties Changeset: 53f212bed4f4 Author: ohair Date: 2011-04-13 16:57 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/53f212bed4f4 Merge ! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java ! src/share/classes/com/sun/tools/javac/nio/PathFileObject.java ! src/share/classes/com/sun/tools/javac/util/Names.java ! test/tools/javac/meth/TestCP.java ! test/tools/javac/meth/XlintWarn.java Changeset: 853b6bb99f9b Author: schien Date: 2011-04-14 15:22 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/853b6bb99f9b Added tag jdk7-b138 for changeset 53f212bed4f4 ! .hgtags Changeset: 5ed971fce27c Author: lana Date: 2011-04-17 16:23 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/5ed971fce27c Merge From lana.steuck at oracle.com Mon Apr 18 04:45:48 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 18 Apr 2011 04:45:48 +0000 Subject: hg: jdk7/tl/hotspot: 50 new changesets Message-ID: <20110418044717.19FE047BAF@hg.openjdk.java.net> Changeset: 2ffcf94550d5 Author: trims Date: 2011-04-01 12:06 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2ffcf94550d5 Added tag hs21-b06 for changeset bd586e392d93 ! .hgtags Changeset: 74e790c48cd4 Author: sla Date: 2011-03-28 12:48 +0200 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/74e790c48cd4 7031571: Generate native VS2010 project files Reviewed-by: hosterda, stefank, brutisso ! make/windows/create.bat ! make/windows/makefiles/projectcreator.make ! make/windows/makefiles/rules.make ! src/share/tools/ProjectCreator/Util.java ! src/share/tools/ProjectCreator/WinGammaPlatform.java + src/share/tools/ProjectCreator/WinGammaPlatformVC10.java ! src/share/tools/ProjectCreator/WinGammaPlatformVC7.java Changeset: df553e4a797b Author: acorn Date: 2011-03-30 17:05 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/df553e4a797b Merge Changeset: 151da0c145a8 Author: twisti Date: 2011-03-24 02:11 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/151da0c145a8 7030207: Zero tweak to remove accidentally incorporated code Summary: IcedTea contains a now-unmaintained ARM-specific interpreter and part of that interpreter was accidentally incorporated in one of the webrevs when Zero was initially imported. Reviewed-by: twisti Contributed-by: Gary Benson ! src/share/vm/interpreter/bytecodeInterpreter.cpp Changeset: b868d9928221 Author: twisti Date: 2011-03-24 23:04 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b868d9928221 Merge - test/compiler/6987555/Test6987555.java - test/compiler/6991596/Test6991596.java Changeset: f731b22cd52d Author: jcoomes Date: 2011-03-24 23:49 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f731b22cd52d Merge ! src/share/vm/interpreter/bytecodeInterpreter.cpp Changeset: 322a41ec766c Author: never Date: 2011-03-25 11:29 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/322a41ec766c 7025708: Assertion if using "-XX:+CITraceTypeFlow -XX:+Verbose" together Reviewed-by: never Contributed-by: volker.simonis at gmail.com ! src/share/vm/ci/ciTypeFlow.cpp Changeset: b2949bf39900 Author: never Date: 2011-03-25 18:19 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b2949bf39900 Merge Changeset: 29524004ce17 Author: never Date: 2011-03-25 18:50 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/29524004ce17 7022204: LogFile wildcarding should use %p instead of star Reviewed-by: coleenp, jrose ! src/share/vm/utilities/ostream.cpp Changeset: 7e88bdae86ec Author: roland Date: 2011-03-25 09:35 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7e88bdae86ec 7029017: Additional architecture support for c2 compiler Summary: Enables cross building of a c2 VM. Support masking of shift counts when the processor architecture mandates it. Reviewed-by: kvn, never ! make/linux/makefiles/adlc.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/rules.make ! make/linux/makefiles/sparcWorks.make ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/main.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/matcher.hpp Changeset: 244bf8afbbd3 Author: roland Date: 2011-03-26 08:31 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/244bf8afbbd3 Merge Changeset: 1927db75dd85 Author: never Date: 2011-03-27 00:00 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1927db75dd85 7024475: loop doesn't terminate when compiled Reviewed-by: kvn ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/idealGraphPrinter.hpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/runtime/globals.hpp + test/compiler/7024475/Test7024475.java Changeset: b40d4fa697bf Author: iveresov Date: 2011-03-27 13:17 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b40d4fa697bf 6964776: c2 should ensure the polling page is reachable on 64 bit Summary: Materialize the pointer to the polling page in a register instead of using rip-relative addressing when the distance from the code cache is larger than disp32. Reviewed-by: never, kvn ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/nativeInst_x86.hpp ! src/cpu/x86/vm/relocInfo_x86.cpp ! src/cpu/x86/vm/x86_64.ad Changeset: 3d58a4983660 Author: twisti Date: 2011-03-28 03:58 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3d58a4983660 7022998: JSR 292 recursive method handle calls inline themselves infinitely Reviewed-by: never, kvn ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp Changeset: a988a7bb3b8a Author: kvn Date: 2011-03-29 09:11 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a988a7bb3b8a 7032133: Enable sse4.2 for new AMD processors Summary: New AMD processors support sse4.2. Enable corresponding instructions in Hotspot. Reviewed-by: kvn Contributed-by: eric.caspole at amd.com ! src/cpu/x86/vm/vm_version_x86.cpp Changeset: b1c22848507b Author: iveresov Date: 2011-03-29 17:35 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b1c22848507b 6741940: Nonvolatile XMM registers not preserved across JNI calls Summary: Save xmm6-xmm15 in call stub on win64 Reviewed-by: kvn, never ! src/cpu/x86/vm/frame_x86.hpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp Changeset: 2cd0180da6e1 Author: never Date: 2011-03-29 22:05 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2cd0180da6e1 7032306: Fastdebug build failure on Solaris with SS11 compilers Reviewed-by: kvn, iveresov ! src/share/vm/oops/instanceKlass.cpp Changeset: 348c0df561a9 Author: iveresov Date: 2011-03-29 22:25 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/348c0df561a9 7026307: DEBUG MESSAGE: broken null klass on amd64 Summary: Correct typo introduces in 7020521 Reviewed-by: never, kvn ! src/cpu/x86/vm/stubGenerator_x86_64.cpp Changeset: fe1dbd98e18f Author: iveresov Date: 2011-03-30 03:48 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/fe1dbd98e18f Merge Changeset: 63997f575155 Author: never Date: 2011-03-30 07:47 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/63997f575155 7031614: jmap -permstat fails with java.lang.InternalError in sun.jvm.hotspot.oops.OopField.getValue Reviewed-by: kvn, dcubed ! agent/src/share/classes/sun/jvm/hotspot/jdi/ClassObjectReferenceImpl.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Instance.java ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java + agent/src/share/classes/sun/jvm/hotspot/oops/InstanceMirrorKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Oop.java ! agent/src/share/classes/sun/jvm/hotspot/oops/OopUtilities.java + agent/src/share/classes/sun/jvm/hotspot/oops/java_lang_Class.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! agent/src/share/classes/sun/jvm/hotspot/tools/FinalizerInfo.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HeapGXLWriter.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/ReversePtrsAnalysis.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/JSJavaFactoryImpl.java ! src/share/vm/oops/instanceMirrorKlass.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: f9424955eb18 Author: kvn Date: 2011-03-30 12:08 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f9424955eb18 7029152: Ideal nodes for String intrinsics miss memory edge optimization Summary: In Ideal() method of String intrinsics nodes look for TypeAryPtr::CHARS memory slice if memory is MergeMem. Do not unroll a loop with String intrinsics code. Reviewed-by: never ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp + test/compiler/7029152/Test.java Changeset: e2eb7f986c64 Author: iveresov Date: 2011-03-30 15:22 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e2eb7f986c64 6564610: assert(UseCompiler || CompileTheWorld, "UseCompiler should be set by now.") Summary: Remove invalid asserts Reviewed-by: never, kvn ! src/share/vm/runtime/compilationPolicy.cpp Changeset: 9d343b8113db Author: iveresov Date: 2011-03-30 18:55 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9d343b8113db Merge Changeset: 09f96c3ff1ad Author: twisti Date: 2011-03-31 00:27 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/09f96c3ff1ad 7032388: guarantee(VM_Version::supports_cmov()) failed: illegal instruction on i586 after 6919934 Summary: 6919934 added some unguarded cmov instructions which hit a guarantee on older hardware. Reviewed-by: never, iveresov, kvn, phh ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp Changeset: 38fea01eb669 Author: twisti Date: 2011-03-31 02:31 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/38fea01eb669 6817525: turn on method handle functionality by default for JSR 292 Summary: After appropriate testing, we need to turn on EnableMethodHandles and EnableInvokeDynamic by default. Reviewed-by: never, kvn, jrose, phh ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interpreter_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_64.cpp ! src/cpu/x86/vm/interpreter_x86_32.cpp ! src/cpu/x86/vm/interpreter_x86_64.cpp ! 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_64.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/thread.cpp Changeset: cb162b348743 Author: kvn Date: 2011-03-31 13:22 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/cb162b348743 7032696: Fix for 7029152 broke VM Summary: StrIntrinsicNode::Ideal() should not optimize memory during Parse. Reviewed-by: jrose, never ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/memnode.cpp Changeset: 352622fd140a Author: never Date: 2011-03-31 14:00 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/352622fd140a 7032129: Native memory usage grow unexpectedly for vm/oom/*InternedString tests Reviewed-by: kvn, kamg, jcoomes ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/memory/dump.cpp Changeset: 2a5104162671 Author: never Date: 2011-03-31 15:30 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2a5104162671 Merge Changeset: 8010c8c623ac Author: kvn Date: 2011-03-31 16:54 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8010c8c623ac 7032849: 7022998 changes broke hs_err compile task print Summary: Initialize the time stamp on ostream used for hs_err dumping. Reviewed-by: never ! src/share/vm/utilities/ostream.cpp Changeset: 6b9eb6d07c62 Author: kvn Date: 2011-04-01 15:16 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6b9eb6d07c62 Merge Changeset: 7ea7c9c0305c Author: trims Date: 2011-04-01 20:44 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7ea7c9c0305c Merge Changeset: 2dbcb4a4d8da Author: trims Date: 2011-04-01 20:44 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2dbcb4a4d8da 7033237: Bump the HS21 build number to 07 Summary: Update the HS21 build number to 07 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 9e6733fb56f8 Author: schien Date: 2011-04-07 15:20 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9e6733fb56f8 Added tag jdk7-b137 for changeset 2dbcb4a4d8da ! .hgtags Changeset: 987d9d10a30a Author: trims Date: 2011-04-08 15:56 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/987d9d10a30a Added tag hs21-b07 for changeset 2dbcb4a4d8da ! .hgtags Changeset: 1d1603768966 Author: trims Date: 2011-04-05 14:12 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1d1603768966 7010070: Update all 2010 Oracle-changed OpenJDK files to have the proper copyright dates - second pass Summary: Update the copyright to be 2010 on all changed files in OpenJDK Reviewed-by: ohair ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java ! agent/src/share/classes/sun/jvm/hotspot/HotSpotTypeDataBase.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeLoadConstant.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeWithKlass.java ! agent/src/share/classes/sun/jvm/hotspot/memory/DictionaryEntry.java ! agent/src/share/classes/sun/jvm/hotspot/memory/LoaderConstraintEntry.java ! agent/src/share/classes/sun/jvm/hotspot/memory/PlaceholderEntry.java ! agent/src/share/classes/sun/jvm/hotspot/memory/StringTable.java ! agent/src/share/classes/sun/jvm/hotspot/memory/SymbolTable.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! agent/src/share/classes/sun/jvm/hotspot/oops/GenerateOopMap.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Klass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Symbol.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java ! agent/src/share/classes/sun/jvm/hotspot/types/Field.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/Hashtable.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HashtableEntry.java ! make/linux/Makefile ! make/linux/makefiles/arm.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/linux/makefiles/ppc.make ! make/linux/makefiles/sparcWorks.make ! make/linux/makefiles/top.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/adlc.make ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/rules.make ! make/solaris/makefiles/top.make ! make/solaris/makefiles/vm.make ! make/windows/create_obj_files.sh ! make/windows/makefiles/launcher.make ! make/windows/makefiles/vm.make ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/dump_sparc.cpp ! src/cpu/sparc/vm/jni_sparc.h ! src/cpu/sparc/vm/nativeInst_sparc.cpp ! src/cpu/sparc/vm/nativeInst_sparc.hpp ! src/cpu/sparc/vm/relocInfo_sparc.cpp ! src/cpu/x86/vm/jni_x86.h ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/zero/vm/jni_zero.h ! src/os/linux/vm/jvm_linux.cpp ! src/os/linux/vm/osThread_linux.cpp ! src/os/linux/vm/os_linux.inline.hpp ! src/os/linux/vm/thread_linux.inline.hpp ! src/os/solaris/dtrace/generateJvmOffsets.cpp ! src/os/solaris/dtrace/jhelper.d ! src/os/solaris/dtrace/libjvm_db.c ! src/os/solaris/vm/dtraceJSDT_solaris.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/share/tools/hsdis/hsdis-demo.c ! src/share/tools/hsdis/hsdis.c ! src/share/vm/adlc/main.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_Defs.hpp ! src/share/vm/c1/c1_FpuStackSim.hpp ! src/share/vm/c1/c1_FrameMap.cpp ! src/share/vm/c1/c1_FrameMap.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_LinearScan.hpp ! src/share/vm/c1/c1_MacroAssembler.hpp ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/ci/ciClassList.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciKlass.cpp ! src/share/vm/ci/ciObjArrayKlass.cpp ! src/share/vm/ci/ciObject.hpp ! src/share/vm/ci/ciObjectFactory.hpp ! src/share/vm/ci/ciSignature.cpp ! src/share/vm/ci/ciSignature.hpp ! src/share/vm/ci/ciSymbol.cpp ! src/share/vm/ci/ciSymbol.hpp ! src/share/vm/ci/compilerInterface.hpp ! src/share/vm/classfile/classFileError.cpp ! src/share/vm/classfile/classFileStream.hpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoader.hpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/classfile/javaAssertions.cpp ! src/share/vm/classfile/loaderConstraints.cpp ! src/share/vm/classfile/loaderConstraints.hpp ! src/share/vm/classfile/placeholders.cpp ! src/share/vm/classfile/placeholders.hpp ! src/share/vm/classfile/resolutionErrors.cpp ! src/share/vm/classfile/resolutionErrors.hpp ! src/share/vm/classfile/stackMapFrame.cpp ! src/share/vm/classfile/stackMapFrame.hpp ! src/share/vm/classfile/stackMapTable.cpp ! src/share/vm/classfile/stackMapTable.hpp ! src/share/vm/classfile/verificationType.cpp ! src/share/vm/classfile/verificationType.hpp ! src/share/vm/classfile/verifier.hpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/compiledIC.cpp ! src/share/vm/code/compiledIC.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/icBuffer.cpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/code/relocInfo.hpp ! src/share/vm/code/vmreg.hpp ! src/share/vm/compiler/compileLog.hpp ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/compiler/compilerOracle.hpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/compiler/disassembler.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.hpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp ! src/share/vm/gc_implementation/shared/allocationStats.hpp ! src/share/vm/gc_implementation/shared/concurrentGCThread.cpp ! src/share/vm/gc_implementation/shared/gcUtil.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/interpreter/bytecodeInterpreter.hpp ! src/share/vm/interpreter/bytecodeInterpreter.inline.hpp ! src/share/vm/interpreter/cppInterpreter.hpp ! src/share/vm/interpreter/cppInterpreterGenerator.hpp ! src/share/vm/interpreter/interpreter.hpp ! src/share/vm/interpreter/interpreterGenerator.hpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/interpreter/templateInterpreter.hpp ! src/share/vm/interpreter/templateInterpreterGenerator.hpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/memory/barrierSet.cpp ! src/share/vm/memory/classify.cpp ! src/share/vm/memory/compactingPermGenGen.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/heap.cpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/memory/restore.cpp ! src/share/vm/memory/serialize.cpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/arrayOop.cpp ! src/share/vm/oops/cpCacheKlass.hpp ! src/share/vm/oops/generateOopMap.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/markOop.hpp ! src/share/vm/oops/symbol.cpp ! src/share/vm/oops/symbol.hpp ! src/share/vm/oops/typeArrayOop.hpp ! src/share/vm/opto/buildOopMap.cpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/idealKit.hpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/locknode.hpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopUnswitch.cpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/output.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/regmask.cpp ! src/share/vm/opto/regmask.hpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/stringopts.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/precompiled.hpp ! src/share/vm/prims/forte.cpp ! src/share/vm/prims/jni_md.h ! src/share/vm/prims/jvm_misc.hpp ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.hpp ! src/share/vm/prims/jvmtiEventController.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp ! src/share/vm/prims/jvmtiTagMap.hpp ! src/share/vm/runtime/deoptimization.hpp ! src/share/vm/runtime/dtraceJSDT.hpp ! src/share/vm/runtime/fieldDescriptor.hpp ! src/share/vm/runtime/fieldType.cpp ! src/share/vm/runtime/fieldType.hpp ! src/share/vm/runtime/fprofiler.cpp ! src/share/vm/runtime/fprofiler.hpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/frame.inline.hpp ! src/share/vm/runtime/handles.hpp ! src/share/vm/runtime/icache.hpp ! src/share/vm/runtime/interfaceSupport.cpp ! src/share/vm/runtime/interfaceSupport.hpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/javaFrameAnchor.hpp ! src/share/vm/runtime/jniHandles.cpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/reflection.hpp ! src/share/vm/runtime/reflectionUtils.hpp ! src/share/vm/runtime/registerMap.hpp ! src/share/vm/runtime/rframe.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/signature.cpp ! src/share/vm/runtime/signature.hpp ! src/share/vm/runtime/stackValueCollection.cpp ! src/share/vm/runtime/statSampler.cpp ! src/share/vm/runtime/stubCodeGenerator.cpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/threadLocalStorage.hpp ! src/share/vm/runtime/vframe.cpp ! src/share/vm/runtime/vmStructs.hpp ! src/share/vm/runtime/vm_operations.cpp ! src/share/vm/runtime/vm_operations.hpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/runtime/vm_version.hpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/attachListener.hpp ! src/share/vm/services/classLoadingService.cpp ! src/share/vm/services/management.hpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/memoryPool.cpp ! src/share/vm/services/memoryService.cpp ! src/share/vm/shark/sharkNativeWrapper.cpp ! src/share/vm/utilities/copy.hpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/debug.hpp ! src/share/vm/utilities/elfSymbolTable.cpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/exceptions.hpp ! src/share/vm/utilities/globalDefinitions_gcc.hpp ! src/share/vm/utilities/globalDefinitions_sparcWorks.hpp ! src/share/vm/utilities/globalDefinitions_visCPP.hpp ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/hashtable.hpp ! src/share/vm/utilities/hashtable.inline.hpp ! src/share/vm/utilities/ostream.hpp ! src/share/vm/utilities/taskqueue.hpp ! src/share/vm/utilities/utf8.cpp ! src/share/vm/utilities/utf8.hpp ! src/share/vm/utilities/xmlstream.cpp ! src/share/vm/utilities/xmlstream.hpp Changeset: a0de1dfd1933 Author: ysr Date: 2011-03-24 15:45 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a0de1dfd1933 7030435: Some oop_oop_iterate_m() methods iterate outside of specified memory bounds Summary: Filter ref-containing locations through the memory-interval specified in the call. Reviewed-by: jcoomes, jwilhelm, tonyp ! src/share/vm/oops/constantPoolKlass.cpp Changeset: 5134fa1cfe63 Author: ysr Date: 2011-03-24 15:47 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5134fa1cfe63 7029036: Card-table verification hangs with all framework collectors, except G1, even before the first GC Summary: When verifying clean card ranges, use memory-range-bounded iteration over oops of objects overlapping that range, thus avoiding the otherwise quadratic worst-case cost of scanning large object arrays. Reviewed-by: jmasa, jwilhelm, tonyp ! src/share/vm/memory/cardTableRS.cpp Changeset: c6580380076b Author: jcoomes Date: 2011-03-25 17:39 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c6580380076b Merge Changeset: 5c0b591e1074 Author: brutisso Date: 2011-03-23 14:12 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5c0b591e1074 6948149: G1: Imbalance in termination times Summary: Changed default value of WorkStealingYieldsBeforeSleep from 1000 to 5000. Added more information to G1 pause logging. Reviewed-by: jwilhelm, tonyp, jmasa ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/runtime/globals.hpp Changeset: 02f49b66361a Author: johnc Date: 2011-03-28 10:58 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/02f49b66361a 7026932: G1: No need to abort VM when card count cache expansion fails Summary: Manage allocation/freeing of the card cache counts and epochs arrays directly so that an allocation failure while attempting to expand these arrays does not abort the JVM. Failure to expand these arrays is not fatal. Reviewed-by: iveresov, tonyp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 455328d90876 Author: tonyp Date: 2011-03-29 22:36 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/455328d90876 7029458: G1: Add newly-reclaimed regions to the beginning of the region free list, not the end Summary: What the synopsis says. Reviewed-by: jwilhelm, iveresov, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/heapRegionSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSet.inline.hpp Changeset: abdfc822206f Author: tonyp Date: 2011-03-30 10:26 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/abdfc822206f 7023069: G1: Introduce symmetric locking in the slow allocation path 7023151: G1: refactor the code that operates on _cur_alloc_region to be re-used for allocs by the GC threads 7018286: G1: humongous allocation attempts should take the GC locker into account Summary: First, this change replaces the asymmetric locking scheme in the G1 slow alloc path by a summetric one. Second, it factors out the code that operates on _cur_alloc_region so that it can be re-used for allocations by the GC threads in the future. Reviewed-by: stefank, brutisso, johnc + src/share/vm/gc_implementation/g1/g1AllocRegion.cpp + src/share/vm/gc_implementation/g1/g1AllocRegion.hpp + src/share/vm/gc_implementation/g1/g1AllocRegion.inline.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegion.inline.hpp ! src/share/vm/memory/cardTableModRefBS.hpp ! src/share/vm/memory/space.cpp Changeset: c84ee870e0b9 Author: tonyp Date: 2011-04-04 13:18 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c84ee870e0b9 7033292: G1: nightly failure: Non-dirty cards in region that should be dirty Summary: The epochs on the card cache array are initialized to 0 and our initial epoch also starts at 0. So, until the first GC, it might be possible to successfully "claim" a card which was in fact never initialized. Reviewed-by: johnc, iveresov, ysr ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp Changeset: 371bbc844bf1 Author: tonyp Date: 2011-04-04 14:23 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/371bbc844bf1 7027766: G1: introduce flag to dump the liveness information per region at the end of marking Summary: Repurpose the existing flag G1PrintRegionLivenessInfo to print out the liveness distribution across the regions in the heap at the end of marking. Reviewed-by: iveresov, jwilhelm ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: 8f1042ff784d Author: johnc Date: 2011-02-18 10:07 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8f1042ff784d 7020042: G1: Partially remove fix for 6994628 Summary: Disable reference discovery and processing during concurrent marking by disabling fix for 6994628. Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 4f978fb6c81a Author: jmasa Date: 2011-04-06 16:02 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4f978fb6c81a Merge ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/runtime/globals.hpp Changeset: 24fbb4b7c2d3 Author: trims Date: 2011-04-08 16:18 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/24fbb4b7c2d3 Merge Changeset: 0930dc920c18 Author: trims Date: 2011-04-08 16:18 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0930dc920c18 7035259: Bump the HS21 build number to 08 Summary: Update the HS21 build number to 08 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 2705303a05c4 Author: schien Date: 2011-04-14 15:21 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2705303a05c4 Added tag jdk7-b138 for changeset 0930dc920c18 ! .hgtags Changeset: d6d9b537f2c6 Author: trims Date: 2011-04-14 17:53 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/d6d9b537f2c6 Added tag hs21-b08 for changeset 0930dc920c18 ! .hgtags From lana.steuck at oracle.com Mon Apr 18 04:48:47 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 18 Apr 2011 04:48:47 +0000 Subject: hg: jdk7/tl/jdk: 87 new changesets Message-ID: <20110418050326.A6B2B47BB1@hg.openjdk.java.net> Changeset: bf018f850da0 Author: ogino Date: 2011-03-29 22:59 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bf018f850da0 7032334: Update Font2DTest demo to support Unicode 6 Reviewed-by: naoto ! src/share/demo/jfc/Font2DTest/README.txt ! src/share/demo/jfc/Font2DTest/RangeMenu.java Changeset: c410d6550b20 Author: yhuang Date: 2011-03-30 22:46 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c410d6550b20 7025837: fix plural currency display names in sr_Latn_(BA|ME|RS).properties Reviewed-by: naoto ! src/share/classes/sun/util/resources/CurrencyNames.properties ! src/share/classes/sun/util/resources/CurrencyNames_pt.properties ! src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_BA.properties ! src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_ME.properties ! src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_RS.properties ! src/share/classes/sun/util/resources/CurrencyNames_sr_RS.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: a820f6db6eba Author: yhuang Date: 2011-03-30 22:52 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a820f6db6eba Merge Changeset: 7cff80a57422 Author: mfang Date: 2011-04-04 12:54 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7cff80a57422 Merge Changeset: da5e33af0e61 Author: resii Date: 2011-04-04 18:03 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/da5e33af0e61 6989729: jarreorder warnings (classlists files are out of date) Reviewed-by: ohair ! make/tools/sharing/classlist.linux ! make/tools/sharing/classlist.solaris ! make/tools/sharing/classlist.windows Changeset: 9d1f5ad258f8 Author: ohair Date: 2011-04-04 15:11 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9d1f5ad258f8 7029905: demo applets missing some html files Reviewed-by: omajid, mchung, igor ! make/mkdemo/jfc/Font2DTest/Makefile ! make/mkdemo/jfc/Java2D/Makefile ! make/mkdemo/jfc/SwingApplet/Makefile ! make/mkdemo/jfc/SwingSet2/Makefile Changeset: 570ea44f50cb Author: ohair Date: 2011-04-05 07:43 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/570ea44f50cb Merge Changeset: 61d9af63ff0e Author: ohair Date: 2011-04-05 08:14 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/61d9af63ff0e Merge Changeset: 29296ea6529a Author: ohair Date: 2011-04-05 17:24 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/29296ea6529a 7033960: Do not check for mapfiles when fastdebug building Reviewed-by: dcubed ! make/common/shared/Defs-linux.gmk ! make/common/shared/Defs-solaris.gmk Changeset: 376a971344a3 Author: schien Date: 2011-04-07 15:21 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/376a971344a3 Added tag jdk7-b137 for changeset 29296ea6529a ! .hgtags Changeset: 7e0c4c994e2e Author: bae Date: 2011-03-22 11:22 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7e0c4c994e2e 6993561: java.awt.image.SampleModel.setSamples() methods not always throw ArrayIndexOutOfBoundsException Reviewed-by: jgodinez, prr ! src/share/classes/java/awt/image/SampleModel.java ! test/java/awt/image/GetSamplesTest.java Changeset: 77a8566be102 Author: bae Date: 2011-03-22 12:28 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/77a8566be102 6773586: java.awt.image.SampleModel.getPixels() methods not allways throw ArrayIndexOutOfBoundsException Reviewed-by: jgodinez, prr ! src/share/classes/java/awt/image/BandedSampleModel.java ! src/share/classes/java/awt/image/ComponentSampleModel.java ! src/share/classes/java/awt/image/SampleModel.java ! src/share/classes/java/awt/image/SinglePixelPackedSampleModel.java Changeset: 8ab1b6226eed Author: bae Date: 2011-03-25 12:50 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8ab1b6226eed 6989717: media native code compiler warnings Reviewed-by: jgodinez, prr ! src/share/native/sun/awt/medialib/mlib_ImageAffine.c ! src/share/native/sun/awt/medialib/mlib_ImageAffineEdge.c ! src/share/native/sun/awt/medialib/mlib_ImageColorTrue2Index.c ! src/share/native/sun/awt/medialib/mlib_ImageConvMxN.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_16ext.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_16nw.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_32nw.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_8ext.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_8nw.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_D64nw.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_F32nw.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_u16ext.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_u16nw.c ! src/share/native/sun/awt/medialib/mlib_ImageCopy_Bit.c ! src/share/native/sun/awt/medialib/mlib_ImageCreate.c Changeset: 0f7256505703 Author: bae Date: 2011-03-27 15:51 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0f7256505703 6985593: Crash in Java_sun_java2d_loops_MaskBlit_MaskBlit on oel5.5-x64 Reviewed-by: ceisserer, jgodinez, prr ! src/solaris/classes/sun/java2d/xr/XRPMBlitLoops.java + test/sun/java2d/XRenderBlitsTest.java Changeset: d1ec8c106dda Author: bae Date: 2011-03-29 13:10 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d1ec8c106dda 7030147: java.awt.image.SampleModel.setDataElements() does't throw ArrayIndexOutOfBoundsEx for Integer.MAX_VA Reviewed-by: jgodinez, prr ! src/share/classes/java/awt/image/SampleModel.java Changeset: 5a0c0ae1c85b Author: bae Date: 2011-03-29 17:11 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5a0c0ae1c85b 7003516: Methods java.awt.geom.Line2D.Double/Float.getBounds2D() don't satisfy inherited spec Reviewed-by: flar, prr ! src/share/classes/java/awt/Shape.java Changeset: 81c8b844e917 Author: prr Date: 2011-03-31 15:02 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/81c8b844e917 7026407: Broken in javax.imageio.metadata.IIOMetadataNode.getTagName() Reviewed-by: jgodinez ! src/share/classes/javax/imageio/metadata/IIOMetadataNode.java Changeset: 8df5b67cc694 Author: prr Date: 2011-04-01 12:45 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8df5b67cc694 7029934: Xrender: Text is truncated with 64 bit Linux JRE Reviewed-by: bae, flar, ceisserer Contributed-by: linuxhippy at gmail.com ! src/solaris/native/sun/java2d/x11/XRBackendNative.c Changeset: 50d62d0a7a2e Author: prr Date: 2011-04-01 20:21 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/50d62d0a7a2e 7032930: A way to specify MS Mincho to be used in dialoginput on windows JA locale Reviewed-by: igor, jgodinez ! src/share/classes/sun/awt/FontConfiguration.java ! src/share/classes/sun/font/FontManagerForSGE.java ! src/share/classes/sun/font/SunFontManager.java ! src/share/classes/sun/java2d/SunGraphicsEnvironment.java ! src/windows/classes/sun/awt/Win32GraphicsEnvironment.java + test/sun/java2d/SunGraphicsEnvironment/TestSGEuseAlternateFontforJALocales.java Changeset: 3c576689e0ce Author: lana Date: 2011-04-01 23:55 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3c576689e0ce Merge - make/com/sun/xml/Makefile - make/java/dyn/Makefile - src/share/classes/java/dyn/CallSite.java - src/share/classes/java/dyn/ClassValue.java - src/share/classes/java/dyn/ConstantCallSite.java - src/share/classes/java/dyn/InvokeDynamic.java - src/share/classes/java/dyn/InvokeDynamicBootstrapError.java - src/share/classes/java/dyn/Linkage.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/MutableCallSite.java - src/share/classes/java/dyn/SwitchPoint.java - src/share/classes/java/dyn/VolatileCallSite.java - src/share/classes/java/dyn/WrongMethodTypeException.java - src/share/classes/java/dyn/package-info.java - src/share/classes/org/relaxng/datatype/Datatype.java - src/share/classes/org/relaxng/datatype/DatatypeBuilder.java - src/share/classes/org/relaxng/datatype/DatatypeException.java - src/share/classes/org/relaxng/datatype/DatatypeLibrary.java - src/share/classes/org/relaxng/datatype/DatatypeLibraryFactory.java - src/share/classes/org/relaxng/datatype/DatatypeStreamingValidator.java - src/share/classes/org/relaxng/datatype/ValidationContext.java - src/share/classes/org/relaxng/datatype/helpers/DatatypeLibraryLoader.java - src/share/classes/org/relaxng/datatype/helpers/ParameterlessDatatypeBuilder.java - src/share/classes/org/relaxng/datatype/helpers/StreamingValidatorImpl.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/InvokeGeneric.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/SpreadGeneric.java - src/share/classes/sun/dyn/ToGeneric.java - src/share/classes/sun/dyn/WrapperInstance.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/BytecodeDescriptor.java - src/share/classes/sun/dyn/util/BytecodeName.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/solaris/bin/ergo_sparc.c - src/solaris/bin/ergo_zero.c - test/java/dyn/ClassValueTest.java - test/java/dyn/InvokeDynamicPrintArgs.java - test/java/dyn/InvokeGenericTest.java - test/java/dyn/JavaDocExamplesTest.java - test/java/dyn/MethodHandlesTest.java - test/java/dyn/MethodTypeTest.java - test/java/dyn/indify/Indify.java Changeset: ddf1f385bf4b Author: dav Date: 2011-03-28 15:25 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ddf1f385bf4b 7023011: Toolkit.getPrintJob(Frame,String,Properties) throws HE instead of specified NPE Reviewed-by: dcherepanov, art ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/sun/awt/HeadlessToolkit.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/windows/classes/sun/awt/windows/WToolkit.java + test/java/awt/Toolkit/Headless/GetPrintJob/GetPrintJob.java + test/java/awt/Toolkit/Headless/GetPrintJob/GetPrintJobHeadless.java Changeset: 44c31bdf4d72 Author: dav Date: 2011-04-01 12:56 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/44c31bdf4d72 6984540: closed/java/awt/dnd/DragInterceptorAppletTest/DragInterceptorAppletTest.html test fails Reviewed-by: uta, art ! src/windows/native/sun/windows/awt_Toolkit.cpp Changeset: 346b4438a7d6 Author: anthony Date: 2011-04-01 15:43 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/346b4438a7d6 6903034: java.awt.Robot.createScreenCapture() doesn't work for translucent windows Summary: Use the composite overlay window to take the screenshot Reviewed-by: art, dcherepanov ! src/solaris/classes/sun/awt/X11/XRobotPeer.java ! src/solaris/native/sun/awt/awt_Robot.c Changeset: d7ab8deea646 Author: lana Date: 2011-04-01 16:55 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d7ab8deea646 Merge - make/com/sun/xml/Makefile - make/java/dyn/Makefile - src/share/classes/java/dyn/CallSite.java - src/share/classes/java/dyn/ClassValue.java - src/share/classes/java/dyn/ConstantCallSite.java - src/share/classes/java/dyn/InvokeDynamic.java - src/share/classes/java/dyn/InvokeDynamicBootstrapError.java - src/share/classes/java/dyn/Linkage.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/MutableCallSite.java - src/share/classes/java/dyn/SwitchPoint.java - src/share/classes/java/dyn/VolatileCallSite.java - src/share/classes/java/dyn/WrongMethodTypeException.java - src/share/classes/java/dyn/package-info.java - src/share/classes/org/relaxng/datatype/Datatype.java - src/share/classes/org/relaxng/datatype/DatatypeBuilder.java - src/share/classes/org/relaxng/datatype/DatatypeException.java - src/share/classes/org/relaxng/datatype/DatatypeLibrary.java - src/share/classes/org/relaxng/datatype/DatatypeLibraryFactory.java - src/share/classes/org/relaxng/datatype/DatatypeStreamingValidator.java - src/share/classes/org/relaxng/datatype/ValidationContext.java - src/share/classes/org/relaxng/datatype/helpers/DatatypeLibraryLoader.java - src/share/classes/org/relaxng/datatype/helpers/ParameterlessDatatypeBuilder.java - src/share/classes/org/relaxng/datatype/helpers/StreamingValidatorImpl.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/InvokeGeneric.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/SpreadGeneric.java - src/share/classes/sun/dyn/ToGeneric.java - src/share/classes/sun/dyn/WrapperInstance.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/BytecodeDescriptor.java - src/share/classes/sun/dyn/util/BytecodeName.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/solaris/bin/ergo_sparc.c - src/solaris/bin/ergo_zero.c - test/java/dyn/ClassValueTest.java - test/java/dyn/InvokeDynamicPrintArgs.java - test/java/dyn/InvokeGenericTest.java - test/java/dyn/JavaDocExamplesTest.java - test/java/dyn/MethodHandlesTest.java - test/java/dyn/MethodTypeTest.java - test/java/dyn/indify/Indify.java Changeset: 8859d18cb3aa Author: anthony Date: 2011-04-04 23:01 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8859d18cb3aa 7033579: XRobotPeer._dispose() native method should be added to the make/sun/xawt/mapfile-vers Reviewed-by: art, dcherepanov ! make/sun/xawt/mapfile-vers Changeset: 3b2378b84d5e Author: lana Date: 2011-04-04 17:18 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3b2378b84d5e Merge Changeset: b055e2ef5a97 Author: peytoia Date: 2011-03-24 15:29 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b055e2ef5a97 4715085: [Ch] Doc: java.lang.Character.digit documentation unclear regarding fullwidth characters Reviewed-by: okutsu ! src/share/classes/java/lang/Character.java Changeset: 707f3c6e66af Author: alexp Date: 2011-03-24 17:00 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/707f3c6e66af 6735285: "Zero" x,y springs passed to SpringLayout.Constraints constructor are not returned from getters Reviewed-by: rupashka ! src/share/classes/javax/swing/SpringLayout.java Changeset: ee0b74ec50f3 Author: alexp Date: 2011-03-24 17:01 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ee0b74ec50f3 6992716: Typos in JLayer files Reviewed-by: rupashka ! src/share/classes/javax/swing/JLayer.java ! src/share/classes/javax/swing/plaf/LayerUI.java Changeset: b52d96e7e125 Author: mrkam Date: 2011-03-24 17:45 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b52d96e7e125 7027676: /applets/CardTest demo needs to be improved Reviewed-by: rupashka ! src/share/demo/applets/CardTest/CardTest.java Changeset: 49e67bb5782c Author: mrkam Date: 2011-03-24 18:03 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/49e67bb5782c 7027677: /applets/Clock demo needs to be improved Reviewed-by: rupashka ! src/share/demo/applets/Clock/Clock.java Changeset: 98b66b617c31 Author: mrkam Date: 2011-03-24 18:07 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/98b66b617c31 7027688: /applets/SimpleGraph demo needs to be improved Reviewed-by: rupashka ! src/share/demo/applets/SimpleGraph/GraphApplet.java Changeset: f296a7c17120 Author: mrkam Date: 2011-03-24 18:09 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f296a7c17120 7027689: /applets/SortDemo demo needs to be improved Reviewed-by: rupashka ! src/share/demo/applets/SortDemo/BidirBubbleSortAlgorithm.java ! src/share/demo/applets/SortDemo/BubbleSortAlgorithm.java ! src/share/demo/applets/SortDemo/QSortAlgorithm.java ! src/share/demo/applets/SortDemo/SortAlgorithm.java ! src/share/demo/applets/SortDemo/SortItem.java ! src/share/demo/applets/SortDemo/example1.html Changeset: 291505740de9 Author: mrkam Date: 2011-03-24 18:13 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/291505740de9 7027678: /applets/DitherTest demo needs to be improved Reviewed-by: rupashka ! src/share/demo/applets/DitherTest/DitherTest.java Changeset: 010dc79258da Author: mrkam Date: 2011-03-24 18:15 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/010dc79258da 7027696: /jfc/Metalworks demo needs to be improved Reviewed-by: rupashka ! src/share/demo/jfc/Metalworks/AquaMetalTheme.java ! src/share/demo/jfc/Metalworks/BigContrastMetalTheme.java ! src/share/demo/jfc/Metalworks/ContrastMetalTheme.java ! src/share/demo/jfc/Metalworks/DemoMetalTheme.java ! src/share/demo/jfc/Metalworks/GreenMetalTheme.java ! src/share/demo/jfc/Metalworks/KhakiMetalTheme.java ! src/share/demo/jfc/Metalworks/MetalThemeMenu.java ! src/share/demo/jfc/Metalworks/Metalworks.java ! src/share/demo/jfc/Metalworks/MetalworksDocumentFrame.java ! src/share/demo/jfc/Metalworks/MetalworksFrame.java ! src/share/demo/jfc/Metalworks/MetalworksHelp.java ! src/share/demo/jfc/Metalworks/MetalworksInBox.java ! src/share/demo/jfc/Metalworks/MetalworksPrefs.java ! src/share/demo/jfc/Metalworks/PropertiesMetalTheme.java ! src/share/demo/jfc/Metalworks/UISwitchListener.java ! src/share/demo/jfc/Metalworks/resources/HelpFiles/credits.html ! src/share/demo/jfc/Metalworks/resources/HelpFiles/metal.html ! src/share/demo/jfc/Metalworks/resources/HelpFiles/metalworks.html ! src/share/demo/jfc/Metalworks/resources/HelpFiles/swing.html ! src/share/demo/jfc/Metalworks/resources/HelpFiles/toc.html Changeset: 3ed1b13ba934 Author: mrkam Date: 2011-03-24 18:20 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3ed1b13ba934 7027680: /applets/DrawTest demo needs to be improved Reviewed-by: rupashka ! src/share/demo/applets/DrawTest/DrawTest.java Changeset: f293a36f05fe Author: mrkam Date: 2011-03-24 18:54 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f293a36f05fe 7027849: New demo for Shaped/Translucent windows feature needs to be created Reviewed-by: rupashka + src/share/demo/jfc/TransparentRuler/README.txt + src/share/demo/jfc/TransparentRuler/transparentruler/Ruler.java + src/share/demo/nbproject/jfc/TransparentRuler/build.properties + src/share/demo/nbproject/jfc/TransparentRuler/build.xml + src/share/demo/nbproject/jfc/TransparentRuler/nbproject/file-targets.xml + src/share/demo/nbproject/jfc/TransparentRuler/nbproject/jdk.xml + src/share/demo/nbproject/jfc/TransparentRuler/nbproject/netbeans-targets.xml + src/share/demo/nbproject/jfc/TransparentRuler/nbproject/project.xml Changeset: cc4c80d4e85a Author: malenkov Date: 2011-03-24 21:45 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cc4c80d4e85a 6825739: jdk regression test failing on linux: java/lang/reflect/Method/InheritedMethods.java Reviewed-by: rupashka ! test/java/lang/reflect/Method/InheritedMethods.java Changeset: 5d96d28e8b41 Author: mrkam Date: 2011-03-25 13:17 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5d96d28e8b41 7030792: /jfc/TransparentRuler needs to be included into build process Reviewed-by: rupashka, ohair ! make/mkdemo/jfc/Makefile + make/mkdemo/jfc/TransparentRuler/Makefile ! src/share/demo/nbproject/project.xml Changeset: 26ff800b75ad Author: mrkam Date: 2011-03-25 13:23 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/26ff800b75ad 7027698: /jfc/SampleTree demo needs to be improved Reviewed-by: rupashka ! src/share/demo/jfc/SampleTree/DynamicTreeNode.java ! src/share/demo/jfc/SampleTree/SampleData.java ! src/share/demo/jfc/SampleTree/SampleTree.java ! src/share/demo/jfc/SampleTree/SampleTreeCellRenderer.java ! src/share/demo/jfc/SampleTree/SampleTreeModel.java Changeset: 098a8c2e9bd2 Author: mrkam Date: 2011-03-25 13:24 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/098a8c2e9bd2 7027697: /jfc/Notepad demo needs to be improved Reviewed-by: rupashka ! src/share/demo/jfc/Notepad/ElementTreePanel.java ! src/share/demo/jfc/Notepad/Notepad.java Changeset: 35fba3254594 Author: mrkam Date: 2011-03-25 13:27 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/35fba3254594 7027694: /jfc/FileChooserDemo demo needs to be improved Reviewed-by: rupashka ! src/share/demo/jfc/FileChooserDemo/ExampleFileSystemView.java ! src/share/demo/jfc/FileChooserDemo/ExampleFileView.java ! src/share/demo/jfc/FileChooserDemo/FileChooserDemo.java Changeset: a92ab497d39c Author: mrkam Date: 2011-03-25 17:52 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a92ab497d39c 7027675: /applets/Blink demo needs to be improved Reviewed-by: alexp ! src/share/demo/applets/Blink/Blink.java Changeset: 584dde6ffd1f Author: mrkam Date: 2011-03-25 17:55 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/584dde6ffd1f 7027683: /applets/GraphicsTest demo needs to be improved Reviewed-by: alexp ! src/share/demo/applets/GraphicsTest/AppletFrame.java ! src/share/demo/applets/GraphicsTest/GraphicsTest.java Changeset: 6b560dd15705 Author: mrkam Date: 2011-03-25 17:56 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6b560dd15705 7027686: /applets/MoleculeViewer demo needs to be improved Reviewed-by: alexp ! src/share/demo/applets/MoleculeViewer/Matrix3D.java ! src/share/demo/applets/MoleculeViewer/XYZApp.java ! src/share/demo/applets/MoleculeViewer/example1.html ! src/share/demo/applets/MoleculeViewer/example2.html ! src/share/demo/applets/MoleculeViewer/example3.html Changeset: 489a9669a344 Author: mrkam Date: 2011-03-25 17:57 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/489a9669a344 7027674: /applets/BarChart demo needs to be improved Reviewed-by: alexp ! src/share/demo/applets/BarChart/BarChart.java Changeset: db5fea7fbf76 Author: mrkam Date: 2011-03-25 17:59 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/db5fea7fbf76 7027692: /applets/WireFrame demo needs to be improved Reviewed-by: alexp ! src/share/demo/applets/WireFrame/Matrix3D.java ! src/share/demo/applets/WireFrame/ThreeD.java ! src/share/demo/applets/WireFrame/example1.html ! src/share/demo/applets/WireFrame/example2.html ! src/share/demo/applets/WireFrame/example3.html ! src/share/demo/applets/WireFrame/example4.html Changeset: e72a348f25c9 Author: mrkam Date: 2011-03-25 18:00 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e72a348f25c9 7027673: /applets/ArcTest demo needs to be improved Reviewed-by: alexp ! src/share/demo/applets/ArcTest/ArcTest.java Changeset: cf381d73bd1f Author: peytoia Date: 2011-03-28 18:00 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cf381d73bd1f 6957870: Monospaced font mapped to proportional font (David) for Hebrew Reviewed-by: okutsu ! src/windows/classes/sun/awt/windows/fontconfig.properties Changeset: 9024198193ce Author: alexp Date: 2011-03-29 21:02 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9024198193ce 7027486: JPopupMenu doesn't take window shape into account Reviewed-by: rupashka ! src/share/classes/javax/swing/PopupFactory.java Changeset: bdd09379168e Author: mrkam Date: 2011-03-30 08:52 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bdd09379168e 7027687: /applets/NervousText demo needs to be improved Reviewed-by: alexp ! src/share/demo/applets/NervousText/NervousText.java Changeset: 08bd29e16159 Author: mrkam Date: 2011-03-30 08:54 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/08bd29e16159 7027690: /applets/SpreadSheet demo needs to be improved Reviewed-by: alexp ! src/share/demo/applets/SpreadSheet/SpreadSheet.java Changeset: 10f3161ff33f Author: mrkam Date: 2011-03-30 08:58 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/10f3161ff33f 7027701: /jfc/TableExample demo needs to be improved Reviewed-by: alexp ! src/share/demo/jfc/TableExample/JDBCAdapter.java ! src/share/demo/jfc/TableExample/OldJTable.java ! src/share/demo/jfc/TableExample/TableExample.java ! src/share/demo/jfc/TableExample/TableExample2.java ! src/share/demo/jfc/TableExample/TableExample3.java ! src/share/demo/jfc/TableExample/TableExample4.java ! src/share/demo/jfc/TableExample/TableMap.java ! src/share/demo/jfc/TableExample/TableSorter.java Changeset: 7e4ce6c1e58b Author: mrkam Date: 2011-03-30 08:58 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7e4ce6c1e58b 7027682: /applets/Fractal demo needs to be improved Reviewed-by: alexp ! src/share/demo/applets/Fractal/CLSFractal.java ! src/share/demo/applets/Fractal/example1.html Changeset: f29110bbcaa2 Author: mrkam Date: 2011-03-30 15:52 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f29110bbcaa2 7027693: /jfc/CodePointIM demo needs to be improved Reviewed-by: alexp ! src/share/demo/jfc/CodePointIM/CodePointIM.java ! src/share/demo/jfc/CodePointIM/CodePointInputMethod.java ! src/share/demo/jfc/CodePointIM/CodePointInputMethodDescriptor.java Changeset: fe5623afdbfe Author: rupashka Date: 2011-03-31 17:04 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fe5623afdbfe 7009422: Two dead links in Swing API documentation Reviewed-by: darcy, art ! src/share/classes/java/awt/Component.java ! src/share/classes/java/lang/CharSequence.java Changeset: 3ced4a33c831 Author: mrkam Date: 2011-03-31 10:15 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3ced4a33c831 7027700: /jfc/SwingApplet demo needs to be improved Reviewed-by: alexp ! src/share/demo/jfc/SwingApplet/SwingApplet.java Changeset: f007fa22625d Author: mrkam Date: 2011-03-31 10:16 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f007fa22625d Merge Changeset: 379a6504216e Author: lana Date: 2011-04-01 14:47 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/379a6504216e Merge - make/com/sun/xml/Makefile - make/java/dyn/Makefile ! src/share/classes/java/awt/Component.java - src/share/classes/java/dyn/CallSite.java - src/share/classes/java/dyn/ClassValue.java - src/share/classes/java/dyn/ConstantCallSite.java - src/share/classes/java/dyn/InvokeDynamic.java - src/share/classes/java/dyn/InvokeDynamicBootstrapError.java - src/share/classes/java/dyn/Linkage.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/MutableCallSite.java - src/share/classes/java/dyn/SwitchPoint.java - src/share/classes/java/dyn/VolatileCallSite.java - src/share/classes/java/dyn/WrongMethodTypeException.java - src/share/classes/java/dyn/package-info.java - src/share/classes/org/relaxng/datatype/Datatype.java - src/share/classes/org/relaxng/datatype/DatatypeBuilder.java - src/share/classes/org/relaxng/datatype/DatatypeException.java - src/share/classes/org/relaxng/datatype/DatatypeLibrary.java - src/share/classes/org/relaxng/datatype/DatatypeLibraryFactory.java - src/share/classes/org/relaxng/datatype/DatatypeStreamingValidator.java - src/share/classes/org/relaxng/datatype/ValidationContext.java - src/share/classes/org/relaxng/datatype/helpers/DatatypeLibraryLoader.java - src/share/classes/org/relaxng/datatype/helpers/ParameterlessDatatypeBuilder.java - src/share/classes/org/relaxng/datatype/helpers/StreamingValidatorImpl.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/InvokeGeneric.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/SpreadGeneric.java - src/share/classes/sun/dyn/ToGeneric.java - src/share/classes/sun/dyn/WrapperInstance.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/BytecodeDescriptor.java - src/share/classes/sun/dyn/util/BytecodeName.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/solaris/bin/ergo_sparc.c - src/solaris/bin/ergo_zero.c - test/java/dyn/ClassValueTest.java - test/java/dyn/InvokeDynamicPrintArgs.java - test/java/dyn/InvokeGenericTest.java - test/java/dyn/JavaDocExamplesTest.java - test/java/dyn/MethodHandlesTest.java - test/java/dyn/MethodTypeTest.java - test/java/dyn/indify/Indify.java Changeset: 8093f407d57d Author: peytoia Date: 2011-04-04 15:24 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8093f407d57d 7033174: (tz) Support tzdata2011e Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/southamerica Changeset: 3549cec980ff Author: amenkov Date: 2011-04-04 13:22 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3549cec980ff 7026275: TEST_BUG: test/javax/sound/sampled/Clip/ClipSetPos.java throws uncatched IllegalArgumentException Reviewed-by: dav ! test/javax/sound/sampled/Clip/ClipSetPos.java Changeset: 8e21bec188ae Author: malenkov Date: 2011-04-04 19:55 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8e21bec188ae 7025987: Nimbus L&F increases insets unexpectedly Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/nimbus/LoweredBorder.java ! test/javax/swing/border/Test4856008.java ! test/javax/swing/border/Test6978482.java Changeset: 39a71949f1a4 Author: alexp Date: 2011-04-04 21:37 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/39a71949f1a4 7032791: TableCellRenderer.getTableCellRendererComponent() doesn't accept null JTable with GTK+ L&F Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/synth/SynthTableUI.java Changeset: 6230c920833f Author: lana Date: 2011-04-04 17:20 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6230c920833f Merge Changeset: a6677292a936 Author: lana Date: 2011-04-04 17:28 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a6677292a936 Merge ! src/share/classes/java/awt/Toolkit.java - src/share/classes/java/nio/BufferPoolMXBean.java - src/share/classes/java/util/logging/PlatformLoggingMXBean.java ! src/solaris/classes/sun/awt/X11/XToolkit.java - src/windows/native/java/net/NetworkInterface_win9x.c - test/java/nio/BufferPoolMXBean/Basic.java - test/java/util/logging/PlatformLoggingMXBean/PlatformLoggingMXBeanTest.java Changeset: ef4492cbf1d7 Author: dholmes Date: 2011-04-09 15:30 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ef4492cbf1d7 7035109: Regression: awt SplashScreen/test18.sh fails - missing mapfile entry Reviewed-by: alanb, ksrini ! make/sun/xawt/mapfile-vers Changeset: 6ff36c6e0cf4 Author: lana Date: 2011-04-10 10:23 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6ff36c6e0cf4 Merge - src/share/classes/java/nio/BufferPoolMXBean.java - src/share/classes/java/util/logging/PlatformLoggingMXBean.java - src/windows/native/java/net/NetworkInterface_win9x.c - test/java/nio/BufferPoolMXBean/Basic.java - test/java/util/logging/PlatformLoggingMXBean/PlatformLoggingMXBeanTest.java Changeset: fa9c8e314f10 Author: jrose Date: 2011-04-07 22:07 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fa9c8e314f10 6817525: turn on method handle functionality by default for JSR 292 Summary: JVM bug 6817525 requires changes to some JDK unit tests; update test invocation flags and "Indify" snapshot Reviewed-by: kvn, twisti ! test/java/lang/invoke/6987555/Test6987555.java ! test/java/lang/invoke/6991596/Test6991596.java ! test/java/lang/invoke/InvokeDynamicPrintArgs.java ! test/java/lang/invoke/InvokeGenericTest.java ! test/java/lang/invoke/JavaDocExamplesTest.java ! test/java/lang/invoke/MethodHandlesTest.java ! test/java/lang/invoke/MethodTypeTest.java ! test/java/lang/invoke/indify/Indify.java Changeset: f1ebf4c57417 Author: trims Date: 2011-04-12 16:37 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f1ebf4c57417 Merge Changeset: 272483f6650b Author: ohair Date: 2011-04-06 22:06 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/272483f6650b 7033660: Update copyright year to 2011 on any files changed in 2011 Reviewed-by: dholmes ! make/Makefile ! make/com/sun/crypto/provider/Makefile ! make/com/sun/java/pack/Makefile ! make/com/sun/java/pack/prop/Makefile ! make/com/sun/jndi/cosnaming/Makefile ! make/com/sun/jndi/dns/Makefile ! make/com/sun/jndi/ldap/Makefile ! make/com/sun/jndi/rmi/registry/Makefile ! make/com/sun/nio/sctp/Makefile ! make/com/sun/org/apache/xml/Makefile ! make/com/sun/rowset/Makefile ! make/com/sun/script/Makefile ! make/com/sun/security/auth/module/Makefile ! make/com/sun/servicetag/Makefile ! make/com/sun/tools/attach/Makefile ! make/common/Defs-solaris.gmk ! make/common/Defs-windows.gmk ! make/common/Demo.gmk ! make/common/Library.gmk ! make/common/Program.gmk ! make/common/Sanity.gmk ! make/common/Subdirs.gmk ! make/common/shared/Compiler-msvc.gmk ! make/common/shared/Defs-control.gmk ! make/common/shared/Defs-javadoc.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Defs.gmk ! make/docs/Makefile ! make/docs/NON_CORE_PKGS.gmk ! make/java/awt/Makefile ! make/java/fdlibm/Makefile ! make/java/java/FILES_java.gmk ! make/java/java/Makefile ! make/java/java_crw_demo/Makefile ! make/java/java_hprof_demo/Makefile ! make/java/jli/Makefile ! make/java/logging/Makefile ! make/java/main/java/Makefile ! make/java/main/javaw/Makefile ! make/java/management/Makefile ! make/java/net/Makefile ! make/java/nio/FILES_java.gmk ! make/java/nio/mapfile-linux ! make/java/nio/mapfile-solaris ! make/java/npt/Makefile ! make/java/redist/Makefile ! make/java/redist/fonts/Makefile ! make/java/redist/sajdi/Makefile ! make/java/sql/Makefile ! make/java/text/base/FILES_java.gmk ! make/java/text/base/Makefile ! make/java/util/FILES_properties.gmk ! make/java/verify/Makefile ! make/java/zip/Makefile ! make/javax/crypto/Defs-jce.gmk ! make/javax/crypto/Makefile ! make/javax/imageio/Makefile ! make/javax/print/Makefile ! make/javax/sound/Makefile ! make/javax/sound/jsoundalsa/Makefile ! make/javax/sound/jsoundds/Makefile ! make/javax/sql/Makefile ! make/javax/swing/Makefile ! make/javax/swing/plaf/Makefile ! make/jdk_generic_profile.sh ! make/jpda/back/Makefile ! make/jpda/transport/Makefile ! make/jpda/transport/shmem/Makefile ! make/jpda/transport/socket/Makefile ! make/jpda/tty/Makefile ! make/launchers/Makefile ! make/mkdemo/Makefile ! make/mkdemo/jfc/Font2DTest/Makefile ! make/mkdemo/jfc/Java2D/Makefile ! make/mkdemo/jfc/Makefile ! make/mkdemo/jfc/SwingApplet/Makefile ! make/mkdemo/jfc/SwingSet2/Makefile ! make/mkdemo/jfc/SwingSet3/Makefile ! make/mkdemo/jpda/Makefile ! make/mkdemo/jvmti/Makefile ! make/mkdemo/management/Makefile ! make/mksample/dtrace/Makefile ! make/mksample/jmx/jmx-scandir/Makefile ! make/mksample/nbproject/Makefile ! make/mksample/nio/file/Makefile ! make/mksample/nio/multicast/Makefile ! make/mksample/nio/server/Makefile ! make/mksample/scripting/scriptpad/Makefile ! make/mksample/webservices/EbayClient/Makefile ! make/mksample/webservices/EbayServer/Makefile ! make/netbeans/common/java-data-native.ent ! make/netbeans/common/java-data-no-native.ent ! make/sun/Makefile ! make/sun/applet/Makefile ! make/sun/awt/Makefile ! make/sun/awt/mapfile-mawt-vers ! make/sun/awt/mapfile-vers-linux ! make/sun/cmm/Makefile ! make/sun/cmm/kcms/Makefile ! make/sun/cmm/lcms/Makefile ! make/sun/dcpr/Makefile ! make/sun/font/Makefile ! make/sun/font/t2k/Makefile ! make/sun/headless/Makefile ! make/sun/headless/mapfile-vers ! make/sun/image/generic/Makefile ! make/sun/image/vis/Makefile ! make/sun/jar/Makefile ! make/sun/javazic/Makefile ! make/sun/jawt/Makefile ! make/sun/jconsole/Makefile ! make/sun/jdbc/Makefile ! make/sun/jdga/Makefile ! make/sun/jpeg/Makefile ! make/sun/launcher/Makefile ! make/sun/management/Makefile ! make/sun/native2ascii/Makefile ! make/sun/net/others/Makefile ! make/sun/net/spi/nameservice/dns/Makefile ! make/sun/nio/cs/FILES_java.gmk ! make/sun/nio/cs/Makefile ! make/sun/org/mozilla/javascript/Makefile ! make/sun/pisces/Makefile ! make/sun/rmi/cgi/Makefile ! make/sun/rmi/oldtools/Makefile ! make/sun/rmi/registry/Makefile ! make/sun/rmi/rmi/Makefile ! make/sun/rmi/rmic/Makefile ! make/sun/rmi/rmid/Makefile ! make/sun/security/ec/Makefile ! make/sun/security/jgss/wrapper/Makefile ! make/sun/security/krb5/Makefile ! make/sun/security/mscapi/Makefile ! make/sun/security/pkcs11/Makefile ! make/sun/security/smartcardio/Makefile ! make/sun/security/tools/Makefile ! make/sun/serialver/Makefile ! make/sun/splashscreen/Makefile ! make/sun/text/Makefile ! make/sun/tools/Makefile ! make/sun/tracing/dtrace/Makefile ! make/sun/xawt/Makefile ! make/sun/xawt/mapfile-vers ! make/tools/reorder/Makefile ! make/tools/src/build/tools/javazic/Zoneinfo.java ! src/share/back/debugInit.c ! src/share/back/eventFilter.c ! src/share/bin/java.c ! src/share/bin/java.h ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/com/sun/java/util/jar/pack/Driver.java ! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java ! src/share/classes/com/sun/java/util/jar/pack/PropMap.java ! src/share/classes/com/sun/java/util/jar/pack/UnpackerImpl.java ! src/share/classes/com/sun/java/util/jar/pack/Utils.java ! src/share/classes/com/sun/jndi/toolkit/ctx/Continuation.java ! src/share/classes/com/sun/media/sound/AiffFileWriter.java ! src/share/classes/com/sun/media/sound/AlawCodec.java ! src/share/classes/com/sun/media/sound/AuFileWriter.java ! src/share/classes/com/sun/media/sound/DirectAudioDevice.java ! src/share/classes/com/sun/media/sound/RealTimeSequencer.java ! src/share/classes/com/sun/media/sound/StandardMidiFileReader.java ! src/share/classes/com/sun/media/sound/SunFileWriter.java ! src/share/classes/com/sun/media/sound/WaveFileWriter.java ! src/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_es.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_fr.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_it.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_ja.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_ko.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_pt_BR.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_sv.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_zh_CN.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_zh_TW.properties ! src/share/classes/com/sun/script/javascript/RhinoScriptEngine.java ! src/share/classes/com/sun/script/javascript/RhinoScriptEngineFactory.java ! src/share/classes/com/sun/script/javascript/RhinoTopLevel.java ! src/share/classes/com/sun/script/util/InterfaceImplementor.java ! src/share/classes/com/sun/security/auth/PolicyFile.java ! src/share/classes/com/sun/security/auth/callback/DialogCallbackHandler.java ! src/share/classes/com/sun/security/auth/login/ConfigFile.java ! src/share/classes/com/sun/security/auth/module/JndiLoginModule.java ! src/share/classes/com/sun/security/auth/module/KeyStoreLoginModule.java ! src/share/classes/com/sun/security/auth/module/SolarisLoginModule.java ! src/share/classes/com/sun/security/auth/module/UnixLoginModule.java ! src/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java ! src/share/classes/com/sun/tools/example/debug/tty/TTYResources_zh_CN.java ! src/share/classes/com/sun/tools/script/shell/init.js ! src/share/classes/java/awt/AWTEvent.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/java/awt/Font.java ! src/share/classes/java/awt/LinearGradientPaint.java ! src/share/classes/java/awt/MenuComponent.java ! src/share/classes/java/awt/MultipleGradientPaint.java ! src/share/classes/java/awt/RadialGradientPaint.java ! src/share/classes/java/awt/TrayIcon.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/awt/color/ICC_Profile.java ! src/share/classes/java/awt/doc-files/FocusSpec.html ! src/share/classes/java/awt/geom/CubicCurve2D.java ! src/share/classes/java/awt/image/PackedColorModel.java ! src/share/classes/java/awt/image/SinglePixelPackedSampleModel.java ! src/share/classes/java/beans/DefaultPersistenceDelegate.java ! src/share/classes/java/beans/DesignMode.java ! src/share/classes/java/beans/IndexedPropertyChangeEvent.java ! src/share/classes/java/beans/Introspector.java ! src/share/classes/java/beans/VetoableChangeSupport.java ! src/share/classes/java/beans/package.html ! src/share/classes/java/io/BufferedReader.java ! src/share/classes/java/io/BufferedWriter.java ! src/share/classes/java/io/Console.java ! src/share/classes/java/io/DeleteOnExitHook.java ! src/share/classes/java/io/File.java ! src/share/classes/java/io/FileInputStream.java ! src/share/classes/java/io/FileOutputStream.java ! src/share/classes/java/io/FilePermission.java ! src/share/classes/java/io/FilterOutputStream.java ! src/share/classes/java/io/ObjectStreamClass.java ! src/share/classes/java/io/PushbackInputStream.java ! src/share/classes/java/io/PushbackReader.java ! src/share/classes/java/lang/ApplicationShutdownHooks.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/Package.java ! src/share/classes/java/lang/StackTraceElement.java ! src/share/classes/java/lang/StringCoding.java ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/lang/ThreadGroup.java ! src/share/classes/java/lang/management/ManagementFactory.java ! src/share/classes/java/lang/management/PlatformComponent.java ! src/share/classes/java/lang/reflect/Proxy.java ! src/share/classes/java/lang/reflect/ReflectAccess.java ! src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java ! src/share/classes/java/net/AbstractPlainSocketImpl.java ! src/share/classes/java/net/HttpURLConnection.java ! src/share/classes/java/net/InetAddress.java ! src/share/classes/java/net/NetPermission.java ! src/share/classes/java/net/NetworkInterface.java ! src/share/classes/java/net/URI.java ! src/share/classes/java/net/URLClassLoader.java ! src/share/classes/java/net/doc-files/net-properties.html ! src/share/classes/java/net/package.html ! src/share/classes/java/nio/channels/AsynchronousFileChannel.java ! src/share/classes/java/nio/channels/FileChannel.java ! src/share/classes/java/nio/channels/SeekableByteChannel.java ! src/share/classes/java/nio/channels/SocketChannel.java ! src/share/classes/java/nio/file/AccessMode.java ! src/share/classes/java/nio/file/CopyOption.java ! src/share/classes/java/nio/file/DirectoryIteratorException.java ! src/share/classes/java/nio/file/DirectoryStream.java ! src/share/classes/java/nio/file/FileStore.java ! src/share/classes/java/nio/file/FileSystem.java ! src/share/classes/java/nio/file/FileSystems.java ! src/share/classes/java/nio/file/FileTreeWalker.java ! src/share/classes/java/nio/file/FileVisitor.java ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/nio/file/LinkOption.java ! src/share/classes/java/nio/file/LinkPermission.java ! src/share/classes/java/nio/file/OpenOption.java ! src/share/classes/java/nio/file/Path.java ! src/share/classes/java/nio/file/PathMatcher.java ! src/share/classes/java/nio/file/Paths.java ! src/share/classes/java/nio/file/SecureDirectoryStream.java ! src/share/classes/java/nio/file/SimpleFileVisitor.java ! src/share/classes/java/nio/file/TempFileHelper.java ! src/share/classes/java/nio/file/WatchEvent.java ! src/share/classes/java/nio/file/WatchKey.java ! src/share/classes/java/nio/file/WatchService.java ! src/share/classes/java/nio/file/attribute/AclEntry.java ! src/share/classes/java/nio/file/attribute/AclFileAttributeView.java ! src/share/classes/java/nio/file/attribute/BasicFileAttributeView.java ! src/share/classes/java/nio/file/attribute/BasicFileAttributes.java ! src/share/classes/java/nio/file/attribute/DosFileAttributeView.java ! src/share/classes/java/nio/file/attribute/DosFileAttributes.java ! src/share/classes/java/nio/file/attribute/FileAttribute.java ! src/share/classes/java/nio/file/attribute/FileAttributeView.java ! src/share/classes/java/nio/file/attribute/FileOwnerAttributeView.java ! src/share/classes/java/nio/file/attribute/FileTime.java ! src/share/classes/java/nio/file/attribute/PosixFileAttributeView.java ! src/share/classes/java/nio/file/attribute/PosixFileAttributes.java ! src/share/classes/java/nio/file/attribute/PosixFilePermission.java ! src/share/classes/java/nio/file/attribute/PosixFilePermissions.java ! src/share/classes/java/nio/file/attribute/UserDefinedFileAttributeView.java ! src/share/classes/java/nio/file/attribute/package-info.java ! src/share/classes/java/nio/file/package-info.java ! src/share/classes/java/nio/file/spi/FileSystemProvider.java ! src/share/classes/java/nio/file/spi/FileTypeDetector.java ! src/share/classes/java/security/AccessControlContext.java ! src/share/classes/java/security/AlgorithmParameterGenerator.java ! src/share/classes/java/security/AlgorithmParameters.java ! src/share/classes/java/security/BasicPermission.java ! src/share/classes/java/security/KeyFactory.java ! src/share/classes/java/security/KeyPairGenerator.java ! src/share/classes/java/security/KeyStore.java ! src/share/classes/java/security/MessageDigest.java ! src/share/classes/java/security/Permissions.java ! src/share/classes/java/security/Policy.java ! src/share/classes/java/security/ProtectionDomain.java ! src/share/classes/java/security/Provider.java ! src/share/classes/java/security/SecureClassLoader.java ! src/share/classes/java/security/SecureRandom.java ! src/share/classes/java/security/Security.java ! src/share/classes/java/security/Signature.java ! src/share/classes/java/security/UnresolvedPermission.java ! src/share/classes/java/security/UnresolvedPermissionCollection.java ! src/share/classes/java/security/cert/CertPath.java ! src/share/classes/java/security/cert/CertPathBuilder.java ! src/share/classes/java/security/cert/CertPathValidator.java ! src/share/classes/java/security/cert/CertStore.java ! src/share/classes/java/security/cert/Certificate.java ! src/share/classes/java/security/cert/CertificateFactory.java ! src/share/classes/java/security/cert/CertificateFactorySpi.java ! src/share/classes/java/security/cert/package.html ! src/share/classes/java/security/package.html ! src/share/classes/java/sql/Timestamp.java ! src/share/classes/java/text/SimpleDateFormat.java ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/Currency.java ! src/share/classes/java/util/DualPivotQuicksort.java ! src/share/classes/java/util/EnumMap.java ! src/share/classes/java/util/EnumSet.java ! src/share/classes/java/util/HashMap.java ! src/share/classes/java/util/HashSet.java ! src/share/classes/java/util/Hashtable.java ! src/share/classes/java/util/IdentityHashMap.java ! src/share/classes/java/util/JumboEnumSet.java ! src/share/classes/java/util/LinkedHashMap.java ! src/share/classes/java/util/LinkedList.java ! src/share/classes/java/util/Locale.java ! src/share/classes/java/util/Objects.java ! src/share/classes/java/util/RegularEnumSet.java ! src/share/classes/java/util/ServiceLoader.java ! src/share/classes/java/util/TreeMap.java ! src/share/classes/java/util/UUID.java ! src/share/classes/java/util/Vector.java ! src/share/classes/java/util/WeakHashMap.java ! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java ! src/share/classes/java/util/logging/FileHandler.java ! src/share/classes/java/util/logging/Level.java ! src/share/classes/java/util/logging/Logger.java ! src/share/classes/java/util/logging/Logging.java ! src/share/classes/java/util/prefs/AbstractPreferences.java ! src/share/classes/java/util/regex/Pattern.java ! src/share/classes/java/util/spi/LocaleNameProvider.java ! src/share/classes/java/util/zip/Inflater.java ! src/share/classes/java/util/zip/ZipEntry.java ! src/share/classes/java/util/zip/ZipFile.java ! src/share/classes/java/util/zip/ZipOutputStream.java ! src/share/classes/java/util/zip/package.html ! src/share/classes/javax/crypto/Cipher.java ! src/share/classes/javax/crypto/ExemptionMechanism.java ! src/share/classes/javax/crypto/KeyAgreement.java ! src/share/classes/javax/crypto/KeyGenerator.java ! src/share/classes/javax/crypto/Mac.java ! src/share/classes/javax/crypto/package.html ! src/share/classes/javax/net/ssl/SSLContext.java ! src/share/classes/javax/net/ssl/package.html ! src/share/classes/javax/print/attribute/standard/DialogTypeSelection.java ! src/share/classes/javax/script/CompiledScript.java ! src/share/classes/javax/script/ScriptEngineFactory.java ! src/share/classes/javax/security/auth/PrivateCredentialPermission.java ! src/share/classes/javax/security/auth/SubjectDomainCombiner.java ! src/share/classes/javax/security/auth/kerberos/DelegationPermission.java ! src/share/classes/javax/security/auth/kerberos/ServicePermission.java ! src/share/classes/javax/security/auth/login/Configuration.java ! src/share/classes/javax/security/auth/login/package.html ! src/share/classes/javax/sound/midi/MidiSystem.java ! src/share/classes/javax/sound/sampled/AudioSystem.java ! src/share/classes/javax/sql/rowset/serial/SerialClob.java ! src/share/classes/javax/sql/rowset/spi/SyncFactory.java ! src/share/classes/javax/swing/AbstractButton.java ! src/share/classes/javax/swing/BorderFactory.java ! src/share/classes/javax/swing/BufferStrategyPaintManager.java ! src/share/classes/javax/swing/DefaultDesktopManager.java ! src/share/classes/javax/swing/JComponent.java ! src/share/classes/javax/swing/JEditorPane.java ! src/share/classes/javax/swing/JFileChooser.java ! src/share/classes/javax/swing/JLayer.java ! src/share/classes/javax/swing/JOptionPane.java ! src/share/classes/javax/swing/JSlider.java ! src/share/classes/javax/swing/JViewport.java ! src/share/classes/javax/swing/LookAndFeel.java ! src/share/classes/javax/swing/RepaintManager.java ! src/share/classes/javax/swing/SizeSequence.java ! src/share/classes/javax/swing/SwingUtilities.java ! src/share/classes/javax/swing/SwingWorker.java ! src/share/classes/javax/swing/Timer.java ! src/share/classes/javax/swing/ToolTipManager.java ! src/share/classes/javax/swing/TransferHandler.java ! src/share/classes/javax/swing/border/BevelBorder.java ! src/share/classes/javax/swing/border/StrokeBorder.java ! src/share/classes/javax/swing/event/InternalFrameAdapter.java ! src/share/classes/javax/swing/event/InternalFrameListener.java ! src/share/classes/javax/swing/plaf/LayerUI.java ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java ! src/share/classes/javax/swing/plaf/basic/BasicSpinnerUI.java ! src/share/classes/javax/swing/plaf/basic/BasicSplitPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java ! src/share/classes/javax/swing/plaf/nimbus/skin.laf ! src/share/classes/javax/swing/plaf/synth/SynthGraphicsUtils.java ! src/share/classes/javax/swing/plaf/synth/SynthTextPaneUI.java ! src/share/classes/javax/swing/text/AsyncBoxView.java ! src/share/classes/javax/swing/text/DefaultCaret.java ! src/share/classes/javax/swing/text/JTextComponent.java ! src/share/classes/javax/swing/text/Keymap.java ! src/share/classes/javax/swing/text/TableView.java ! src/share/classes/javax/swing/text/Utilities.java ! src/share/classes/javax/swing/text/View.java ! src/share/classes/javax/swing/text/WrappedPlainView.java ! src/share/classes/javax/swing/text/html/CSSBorder.java ! src/share/classes/javax/swing/text/html/HTMLEditorKit.java ! src/share/classes/javax/swing/text/html/ParagraphView.java ! src/share/classes/javax/swing/text/html/StyleSheet.java ! src/share/classes/javax/swing/text/html/parser/ParserDelegator.java ! src/share/classes/overview-core.html ! src/share/classes/sun/applet/AppletClassLoader.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_de.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_es.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_fr.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_it.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_ja.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_ko.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_pt_BR.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_sv.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_zh_CN.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_zh_TW.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/share/classes/sun/awt/SunToolkit.java ! src/share/classes/sun/awt/image/ImageFetcher.java ! src/share/classes/sun/awt/image/InputStreamImageSource.java ! src/share/classes/sun/dc/DuctusRenderingEngine.java ! src/share/classes/sun/font/FileFont.java ! src/share/classes/sun/font/FileFontStrike.java ! src/share/classes/sun/font/Font2D.java ! src/share/classes/sun/font/FontScaler.java ! src/share/classes/sun/font/FontUtilities.java ! src/share/classes/sun/font/FreetypeFontScaler.java ! src/share/classes/sun/font/NullFontScaler.java ! src/share/classes/sun/font/StrikeCache.java ! src/share/classes/sun/font/SunFontManager.java ! src/share/classes/sun/font/TrueTypeFont.java ! src/share/classes/sun/font/Type1Font.java ! src/share/classes/sun/invoke/package-info.java ! src/share/classes/sun/java2d/SunGraphicsEnvironment.java ! src/share/classes/sun/java2d/loops/CompositeType.java ! src/share/classes/sun/java2d/loops/MaskFill.java ! src/share/classes/sun/java2d/pipe/AAShapePipe.java ! src/share/classes/sun/java2d/pipe/AlphaColorPipe.java ! src/share/classes/sun/java2d/pipe/RenderingEngine.java ! src/share/classes/sun/java2d/pisces/Curve.java ! src/share/classes/sun/java2d/pisces/Dasher.java ! src/share/classes/sun/java2d/pisces/Helpers.java ! src/share/classes/sun/java2d/pisces/PiscesCache.java ! src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java ! src/share/classes/sun/java2d/pisces/PiscesTileGenerator.java ! src/share/classes/sun/java2d/pisces/Renderer.java ! src/share/classes/sun/java2d/pisces/Stroker.java ! src/share/classes/sun/java2d/pisces/TransformingPathConsumer2D.java ! src/share/classes/sun/jvmstat/monitor/MonitoredVmUtil.java ! src/share/classes/sun/launcher/LauncherHelper.java ! src/share/classes/sun/launcher/resources/launcher.properties ! src/share/classes/sun/management/resources/agent_de.properties ! src/share/classes/sun/management/resources/agent_es.properties ! src/share/classes/sun/management/resources/agent_fr.properties ! src/share/classes/sun/management/resources/agent_it.properties ! src/share/classes/sun/management/resources/agent_ja.properties ! src/share/classes/sun/management/resources/agent_ko.properties ! src/share/classes/sun/management/resources/agent_pt_BR.properties ! src/share/classes/sun/management/resources/agent_sv.properties ! src/share/classes/sun/management/resources/agent_zh_CN.properties ! src/share/classes/sun/management/resources/agent_zh_TW.properties ! src/share/classes/sun/misc/FloatingDecimal.java ! src/share/classes/sun/misc/JavaSecurityAccess.java ! src/share/classes/sun/misc/Launcher.java ! src/share/classes/sun/misc/URLClassPath.java ! src/share/classes/sun/misc/VM.java ! src/share/classes/sun/misc/resources/Messages_de.java ! src/share/classes/sun/misc/resources/Messages_es.java ! src/share/classes/sun/misc/resources/Messages_fr.java ! src/share/classes/sun/misc/resources/Messages_it.java ! src/share/classes/sun/misc/resources/Messages_ja.java ! src/share/classes/sun/misc/resources/Messages_ko.java ! src/share/classes/sun/misc/resources/Messages_pt_BR.java ! src/share/classes/sun/misc/resources/Messages_sv.java ! src/share/classes/sun/misc/resources/Messages_zh_CN.java ! src/share/classes/sun/misc/resources/Messages_zh_TW.java ! src/share/classes/sun/net/httpserver/ChunkedInputStream.java ! src/share/classes/sun/net/spi/DefaultProxySelector.java ! src/share/classes/sun/net/www/http/KeepAliveCache.java ! src/share/classes/sun/net/www/http/KeepAliveStream.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/classes/sun/net/www/protocol/http/NTLMAuthenticationProxy.java ! src/share/classes/sun/net/www/protocol/jar/URLJarFile.java ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/share/classes/sun/nio/ch/FileChannelImpl.java ! src/share/classes/sun/nio/ch/Net.java ! src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java ! src/share/classes/sun/nio/fs/AbstractAclFileAttributeView.java ! src/share/classes/sun/nio/fs/AbstractBasicFileAttributeView.java ! src/share/classes/sun/nio/fs/AbstractFileTypeDetector.java ! src/share/classes/sun/nio/fs/AbstractPath.java ! src/share/classes/sun/nio/fs/AbstractPoller.java ! src/share/classes/sun/nio/fs/AbstractUserDefinedFileAttributeView.java ! src/share/classes/sun/nio/fs/AbstractWatchKey.java ! src/share/classes/sun/nio/fs/AbstractWatchService.java ! src/share/classes/sun/nio/fs/DynamicFileAttributeView.java ! src/share/classes/sun/nio/fs/FileOwnerAttributeViewImpl.java ! src/share/classes/sun/nio/fs/PollingWatchService.java ! src/share/classes/sun/nio/fs/Util.java ! src/share/classes/sun/rmi/registry/resources/rmiregistry_de.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_es.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_fr.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_it.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_ja.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_ko.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_pt_BR.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_sv.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_zh_CN.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_zh_TW.properties ! src/share/classes/sun/rmi/rmic/resources/rmic_ja.properties ! src/share/classes/sun/rmi/rmic/resources/rmic_zh_CN.properties ! src/share/classes/sun/rmi/server/resources/rmid_de.properties ! src/share/classes/sun/rmi/server/resources/rmid_es.properties ! src/share/classes/sun/rmi/server/resources/rmid_fr.properties ! src/share/classes/sun/rmi/server/resources/rmid_it.properties ! src/share/classes/sun/rmi/server/resources/rmid_ja.properties ! src/share/classes/sun/rmi/server/resources/rmid_ko.properties ! src/share/classes/sun/rmi/server/resources/rmid_pt_BR.properties ! src/share/classes/sun/rmi/server/resources/rmid_sv.properties ! src/share/classes/sun/rmi/server/resources/rmid_zh_CN.properties ! src/share/classes/sun/rmi/server/resources/rmid_zh_TW.properties ! src/share/classes/sun/security/acl/AclEntryImpl.java ! src/share/classes/sun/security/acl/AclImpl.java ! src/share/classes/sun/security/acl/GroupImpl.java ! src/share/classes/sun/security/jca/ProviderList.java ! src/share/classes/sun/security/jca/Providers.java ! src/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java ! src/share/classes/sun/security/krb5/Config.java ! src/share/classes/sun/security/krb5/KdcComm.java ! src/share/classes/sun/security/krb5/KrbAsRep.java ! src/share/classes/sun/security/krb5/PrincipalName.java ! src/share/classes/sun/security/krb5/Realm.java ! src/share/classes/sun/security/krb5/internal/HostAddresses.java ! src/share/classes/sun/security/krb5/internal/KRBError.java ! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java ! src/share/classes/sun/security/krb5/internal/crypto/EType.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java ! src/share/classes/sun/security/pkcs11/Config.java ! src/share/classes/sun/security/pkcs11/P11Key.java ! src/share/classes/sun/security/provider/PolicyFile.java ! src/share/classes/sun/security/provider/SeedGenerator.java ! src/share/classes/sun/security/provider/Sun.java ! src/share/classes/sun/security/provider/VerificationProvider.java ! src/share/classes/sun/security/provider/X509Factory.java ! src/share/classes/sun/security/rsa/RSACore.java ! src/share/classes/sun/security/rsa/SunRsaSign.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/CipherSuiteList.java ! src/share/classes/sun/security/ssl/DefaultSSLContextImpl.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/HelloExtensions.java ! src/share/classes/sun/security/ssl/ProtocolList.java ! src/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java ! src/share/classes/sun/security/ssl/SSLSessionImpl.java ! src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java ! src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java ! src/share/classes/sun/security/ssl/TrustManagerFactoryImpl.java ! src/share/classes/sun/security/ssl/X509KeyManagerImpl.java ! src/share/classes/sun/security/tools/JarSignerResources_ja.java ! src/share/classes/sun/security/tools/JarSignerResources_zh_CN.java ! src/share/classes/sun/security/tools/policytool/PolicyTool.java ! src/share/classes/sun/security/util/AuthResources_de.java ! src/share/classes/sun/security/util/AuthResources_es.java ! src/share/classes/sun/security/util/AuthResources_fr.java ! src/share/classes/sun/security/util/AuthResources_it.java ! src/share/classes/sun/security/util/AuthResources_ja.java ! src/share/classes/sun/security/util/AuthResources_ko.java ! src/share/classes/sun/security/util/AuthResources_pt_BR.java ! src/share/classes/sun/security/util/AuthResources_sv.java ! src/share/classes/sun/security/util/AuthResources_zh_CN.java ! src/share/classes/sun/security/util/AuthResources_zh_TW.java ! src/share/classes/sun/security/util/Resources_de.java ! src/share/classes/sun/security/util/Resources_es.java ! src/share/classes/sun/security/util/Resources_fr.java ! src/share/classes/sun/security/util/Resources_it.java ! src/share/classes/sun/security/util/Resources_ja.java ! src/share/classes/sun/security/util/Resources_ko.java ! src/share/classes/sun/security/util/Resources_pt_BR.java ! src/share/classes/sun/security/util/Resources_sv.java ! src/share/classes/sun/security/util/Resources_zh_CN.java ! src/share/classes/sun/security/util/Resources_zh_TW.java ! src/share/classes/sun/swing/AccumulativeRunnable.java ! src/share/classes/sun/swing/WindowsPlacesBar.java ! src/share/classes/sun/text/resources/CollationData_sr_Latn.java ! src/share/classes/sun/tools/attach/HotSpotAttachProvider.java ! src/share/classes/sun/tools/jar/Main.java ! src/share/classes/sun/tools/jar/resources/jar_de.properties ! src/share/classes/sun/tools/jar/resources/jar_es.properties ! src/share/classes/sun/tools/jar/resources/jar_fr.properties ! src/share/classes/sun/tools/jar/resources/jar_it.properties ! src/share/classes/sun/tools/jar/resources/jar_ja.properties ! src/share/classes/sun/tools/jar/resources/jar_ko.properties ! src/share/classes/sun/tools/jar/resources/jar_pt_BR.properties ! src/share/classes/sun/tools/jar/resources/jar_sv.properties ! src/share/classes/sun/tools/jar/resources/jar_zh_CN.properties ! src/share/classes/sun/tools/jar/resources/jar_zh_TW.properties ! src/share/classes/sun/tools/javac/resources/javac_ja.properties ! src/share/classes/sun/tools/javac/resources/javac_zh_CN.properties ! src/share/classes/sun/tools/jconsole/resources/JConsoleResources_ja.java ! src/share/classes/sun/tools/jconsole/resources/JConsoleResources_zh_CN.java ! src/share/classes/sun/tools/native2ascii/Main.java ! src/share/classes/sun/tools/native2ascii/resources/MsgNative2ascii_ja.java ! src/share/classes/sun/tools/native2ascii/resources/MsgNative2ascii_zh_CN.java ! src/share/classes/sun/util/calendar/LocalGregorianCalendar.java ! src/share/classes/sun/util/locale/LanguageTag.java ! src/share/classes/sun/util/logging/PlatformLogger.java ! src/share/classes/sun/util/logging/resources/logging.properties ! src/share/classes/sun/util/logging/resources/logging_de.properties ! src/share/classes/sun/util/logging/resources/logging_es.properties ! src/share/classes/sun/util/logging/resources/logging_fr.properties ! src/share/classes/sun/util/logging/resources/logging_it.properties ! src/share/classes/sun/util/logging/resources/logging_ja.properties ! src/share/classes/sun/util/logging/resources/logging_ko.properties ! src/share/classes/sun/util/logging/resources/logging_pt_BR.properties ! src/share/classes/sun/util/logging/resources/logging_sv.properties ! src/share/classes/sun/util/logging/resources/logging_zh_CN.properties ! src/share/classes/sun/util/logging/resources/logging_zh_TW.properties ! src/share/classes/sun/util/resources/LocaleData.java ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java ! src/share/demo/jvmti/heapTracker/heapTracker.c ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileAttributeView.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileStore.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystemProvider.java ! src/share/instrument/JPLISAgent.c ! src/share/javavm/export/jvmti.h ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! src/share/native/common/check_code.c ! src/share/native/java/io/io_util.c ! src/share/native/sun/awt/image/awt_parseImage.c ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c ! src/share/native/sun/awt/image/jpeg/jpegdecoder.c ! src/share/native/sun/awt/splashscreen/splashscreen_gfx_impl.h ! src/share/native/sun/font/FontInstanceAdapter.cpp ! src/share/native/sun/java2d/cmm/lcms/LCMS.c ! src/share/native/sun/java2d/loops/MaskFill.c ! src/share/native/sun/java2d/loops/ParallelogramUtils.h ! src/share/native/sun/java2d/loops/ProcessPath.c ! src/share/native/sun/java2d/pipe/BufferedMaskBlit.c ! src/share/native/sun/security/ec/ECC_JNI.cpp ! src/share/native/sun/security/ec/impl/ec.c ! src/share/native/sun/security/ec/impl/ec.h ! src/share/native/sun/security/ec/impl/ec2.h ! src/share/native/sun/security/ec/impl/ec2_163.c ! src/share/native/sun/security/ec/impl/ec2_193.c ! src/share/native/sun/security/ec/impl/ec2_233.c ! src/share/native/sun/security/ec/impl/ec2_aff.c ! src/share/native/sun/security/ec/impl/ec2_mont.c ! src/share/native/sun/security/ec/impl/ec_naf.c ! src/share/native/sun/security/ec/impl/ecc_impl.h ! src/share/native/sun/security/ec/impl/ecdecode.c ! src/share/native/sun/security/ec/impl/ecl-curve.h ! src/share/native/sun/security/ec/impl/ecl-exp.h ! src/share/native/sun/security/ec/impl/ecl-priv.h ! src/share/native/sun/security/ec/impl/ecl.c ! src/share/native/sun/security/ec/impl/ecl.h ! src/share/native/sun/security/ec/impl/ecl_curve.c ! src/share/native/sun/security/ec/impl/ecl_gf.c ! src/share/native/sun/security/ec/impl/ecl_mult.c ! src/share/native/sun/security/ec/impl/ecp.h ! src/share/native/sun/security/ec/impl/ecp_192.c ! src/share/native/sun/security/ec/impl/ecp_224.c ! src/share/native/sun/security/ec/impl/ecp_256.c ! src/share/native/sun/security/ec/impl/ecp_384.c ! src/share/native/sun/security/ec/impl/ecp_521.c ! src/share/native/sun/security/ec/impl/ecp_aff.c ! src/share/native/sun/security/ec/impl/ecp_jac.c ! src/share/native/sun/security/ec/impl/ecp_jm.c ! src/share/native/sun/security/ec/impl/ecp_mont.c ! src/share/native/sun/security/ec/impl/logtab.h ! src/share/native/sun/security/ec/impl/mp_gf2m-priv.h ! src/share/native/sun/security/ec/impl/mp_gf2m.c ! src/share/native/sun/security/ec/impl/mp_gf2m.h ! src/share/native/sun/security/ec/impl/mpi-config.h ! src/share/native/sun/security/ec/impl/mpi-priv.h ! src/share/native/sun/security/ec/impl/mpi.c ! src/share/native/sun/security/ec/impl/mpi.h ! src/share/native/sun/security/ec/impl/mplogic.c ! src/share/native/sun/security/ec/impl/mplogic.h ! src/share/native/sun/security/ec/impl/mpmontg.c ! src/share/native/sun/security/ec/impl/mpprime.h ! src/share/native/sun/security/ec/impl/oid.c ! src/share/native/sun/security/ec/impl/secitem.c ! src/share/native/sun/security/ec/impl/secoidt.h ! src/share/sample/nio/file/AclEdit.java ! src/share/sample/nio/file/Chmod.java ! src/share/sample/nio/file/Copy.java ! src/share/sample/nio/file/DiskUsage.java ! src/share/sample/nio/file/FileType.java ! src/share/sample/nio/file/WatchDir.java ! src/share/sample/nio/file/Xdd.java ! src/solaris/classes/java/lang/ProcessEnvironment.java ! src/solaris/classes/java/util/prefs/FileSystemPreferences.java ! src/solaris/classes/sun/awt/X11/GtkFileDialogPeer.java ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/solaris/classes/sun/awt/X11/XDesktopPeer.java ! src/solaris/classes/sun/awt/X11/XGlobalCursorManager.java ! src/solaris/classes/sun/awt/X11/XSelection.java ! src/solaris/classes/sun/awt/X11/XTextAreaPeer.java ! src/solaris/classes/sun/awt/motif/MFontConfiguration.java ! src/solaris/classes/sun/awt/motif/MToolkit.java ! src/solaris/classes/sun/font/FcFontConfiguration.java ! src/solaris/classes/sun/font/FontConfigManager.java ! src/solaris/classes/sun/font/XRGlyphCache.java ! src/solaris/classes/sun/java2d/xr/XRSurfaceData.java ! src/solaris/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java ! src/solaris/classes/sun/nio/ch/UnixAsynchronousServerSocketChannelImpl.java ! src/solaris/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java ! src/solaris/classes/sun/nio/fs/GnomeFileTypeDetector.java ! src/solaris/classes/sun/nio/fs/LinuxDosFileAttributeView.java ! src/solaris/classes/sun/nio/fs/LinuxFileSystem.java ! src/solaris/classes/sun/nio/fs/LinuxFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/LinuxUserDefinedFileAttributeView.java ! src/solaris/classes/sun/nio/fs/LinuxWatchService.java ! src/solaris/classes/sun/nio/fs/SolarisAclFileAttributeView.java ! src/solaris/classes/sun/nio/fs/SolarisFileSystem.java ! src/solaris/classes/sun/nio/fs/SolarisFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/SolarisUserDefinedFileAttributeView.java ! src/solaris/classes/sun/nio/fs/SolarisWatchService.java ! src/solaris/classes/sun/nio/fs/UnixChannelFactory.java ! src/solaris/classes/sun/nio/fs/UnixCopyFile.java ! src/solaris/classes/sun/nio/fs/UnixFileAttributeViews.java ! src/solaris/classes/sun/nio/fs/UnixFileAttributes.java ! src/solaris/classes/sun/nio/fs/UnixFileStore.java ! src/solaris/classes/sun/nio/fs/UnixFileSystem.java ! src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/UnixPath.java ! src/solaris/classes/sun/nio/fs/UnixSecureDirectoryStream.java ! src/solaris/classes/sun/nio/fs/UnixUriUtils.java ! src/solaris/native/com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_CommonUtils.c ! src/solaris/native/com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_MidiIn.c ! src/solaris/native/java/net/Inet6AddressImpl.c ! src/solaris/native/java/net/NetworkInterface.c ! src/solaris/native/java/net/PlainDatagramSocketImpl.c ! src/solaris/native/java/net/PlainSocketImpl.c ! src/solaris/native/java/net/linux_close.c ! src/solaris/native/java/net/net_util_md.c ! src/solaris/native/sun/awt/awt_DrawingSurface.c ! src/solaris/native/sun/awt/awt_GraphicsEnv.c ! src/solaris/native/sun/awt/fontpath.c ! src/solaris/native/sun/awt/gtk2_interface.c ! src/solaris/native/sun/awt/gtk2_interface.h ! src/solaris/native/sun/java2d/loops/vis_IntArgbPre_Mask.c ! src/solaris/native/sun/java2d/loops/vis_SrcMaskFill.c ! src/solaris/native/sun/java2d/x11/X11SurfaceData.c ! src/solaris/native/sun/java2d/x11/X11SurfaceData.h ! src/solaris/native/sun/java2d/x11/XRBackendNative.c ! src/solaris/native/sun/java2d/x11/XRSurfaceData.c ! src/solaris/native/sun/nio/ch/FileChannelImpl.c ! src/solaris/native/sun/nio/ch/Net.c ! src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c ! src/solaris/native/sun/xawt/XToolkit.c ! src/solaris/native/sun/xawt/awt_Desktop.c ! src/windows/bin/java_md.c ! src/windows/classes/java/lang/ProcessEnvironment.java ! src/windows/classes/java/net/PlainSocketImpl.java ! src/windows/classes/java/net/TwoStacksPlainDatagramSocketImpl.java ! src/windows/classes/sun/awt/Win32FontManager.java ! src/windows/classes/sun/awt/windows/WPathGraphics.java ! src/windows/classes/sun/awt/windows/WPrinterJob.java ! src/windows/classes/sun/awt/windows/WToolkit.java ! src/windows/classes/sun/java2d/d3d/D3DSurfaceData.java ! src/windows/classes/sun/java2d/opengl/WGLVolatileSurfaceManager.java ! src/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java ! src/windows/classes/sun/nio/ch/PendingIoCache.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java ! src/windows/classes/sun/nio/fs/RegistryFileTypeDetector.java ! src/windows/classes/sun/nio/fs/WindowsFileAttributeViews.java ! src/windows/classes/sun/nio/fs/WindowsFileCopy.java ! src/windows/classes/sun/nio/fs/WindowsFileStore.java ! src/windows/classes/sun/nio/fs/WindowsFileSystem.java ! src/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java ! src/windows/classes/sun/nio/fs/WindowsPath.java ! src/windows/classes/sun/nio/fs/WindowsPathParser.java ! src/windows/classes/sun/nio/fs/WindowsSecurityDescriptor.java ! src/windows/classes/sun/nio/fs/WindowsUserDefinedFileAttributeView.java ! src/windows/classes/sun/nio/fs/WindowsWatchService.java ! src/windows/classes/sun/print/Win32PrintService.java ! src/windows/demo/jvmti/hprof/hprof_md.c ! src/windows/native/java/io/WinNTFileSystem_md.c ! src/windows/native/java/io/canonicalize_md.c ! src/windows/native/java/io/io_util_md.c ! src/windows/native/java/net/Inet4AddressImpl.c ! src/windows/native/java/net/Inet6AddressImpl.c ! src/windows/native/java/net/TwoStacksPlainSocketImpl.c ! src/windows/native/sun/java2d/d3d/D3DGraphicsDevice.cpp ! src/windows/native/sun/java2d/windows/GDIBlitLoops.cpp ! src/windows/native/sun/nio/ch/Iocp.c ! src/windows/native/sun/nio/ch/Net.c ! src/windows/native/sun/nio/fs/RegistryFileTypeDetector.c ! src/windows/native/sun/nio/fs/WindowsNativeDispatcher.c ! src/windows/native/sun/windows/Devices.h ! src/windows/native/sun/windows/awt_Debug.cpp ! src/windows/native/sun/windows/awt_Debug.h ! src/windows/native/sun/windows/awt_Dialog.h ! src/windows/native/sun/windows/awt_Frame.cpp ! src/windows/native/sun/windows/awt_Frame.h ! src/windows/native/sun/windows/awt_PrintJob.cpp ! src/windows/native/sun/windows/awt_TextArea.h ! src/windows/native/sun/windows/awt_Toolkit.cpp ! src/windows/native/sun/windows/awt_TrayIcon.cpp ! src/windows/native/sun/windows/awt_Win32GraphicsEnv.cpp ! src/windows/native/sun/windows/awt_Window.cpp ! test/Makefile ! test/ProblemList.txt ! test/com/sun/awt/Translucency/WindowOpacity.java ! test/com/sun/jdi/NativeInstanceFilter.java ! test/com/sun/jdi/NativeInstanceFilterTarg.java ! test/com/sun/jdi/ProcessAttachTest.sh ! test/com/sun/security/auth/module/LdapLoginModule/CheckConfigs.java ! test/com/sun/security/auth/module/LdapLoginModule/CheckOptions.java ! test/com/sun/tools/attach/ApplicationSetup.sh ! test/com/sun/tools/attach/BasicTests.sh ! test/com/sun/tools/attach/CommonSetup.sh ! test/com/sun/tools/attach/PermissionTests.sh ! test/demo/zipfs/Basic.java ! test/demo/zipfs/PathOps.java ! test/demo/zipfs/basic.sh ! test/java/awt/Container/CheckZOrderChange/CheckZOrderChange.java ! test/java/awt/FontClass/LCDScale.java ! test/java/awt/Graphics2D/RenderClipTest/RenderClipTest.java ! test/java/awt/PrintJob/Text/StringWidth.java ! test/java/awt/font/FontNames/LocaleFamilyNames.java ! test/java/awt/xembed/server/TestXEmbedServer.java ! test/java/io/File/IsHidden.java ! test/java/io/File/SetAccess.java ! test/java/io/File/SetLastModified.java ! test/java/io/File/SymLinks.java ! test/java/io/File/basic.sh ! test/java/io/FileInputStream/LargeFileAvailable.java ! test/java/io/FileOutputStream/AtomicAppend.java ! test/java/io/OutputStreamWriter/Encode.java ! test/java/io/PrintStream/EncodingConstructor.java ! test/java/io/Serializable/NPEProvoker/NPEProvoker.java ! test/java/io/Serializable/evolution/RenamePackage/install/SerialDriver.java ! test/java/io/Serializable/evolution/RenamePackage/test/SerialDriver.java ! test/java/lang/Double/ParseDouble.java ! test/java/lang/ProcessBuilder/Basic.java ! test/java/lang/Runtime/exec/Duped.java ! test/java/lang/Runtime/shutdown/ShutdownHooks.java ! test/java/lang/System/finalization/FinExit.sh ! test/java/lang/Thread/StartOOMTest.java ! test/java/lang/annotation/loaderLeak/LoaderLeak.sh ! test/java/lang/instrument/BootClassPath/Setup.java ! test/java/lang/instrument/appendToClassLoaderSearch/CommonSetup.sh ! test/java/lang/instrument/ilib/Inject.java ! test/java/lang/instrument/ilib/InjectBytecodes.java ! test/java/lang/invoke/indify/Indify.java ! test/java/lang/reflect/Generics/TestPlainArrayNotGeneric.java ! test/java/math/BigInteger/BigIntegerTest.java ! test/java/net/URI/Test.java ! test/java/net/URLClassLoader/closetest/CloseTest.java ! test/java/nio/MappedByteBuffer/Force.java ! test/java/nio/MappedByteBuffer/ZeroMap.java ! test/java/nio/channels/AsynchronousSocketChannel/Basic.java ! test/java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java ! test/java/nio/channels/FileChannel/AtomicAppend.java ! test/java/nio/channels/FileChannel/Position.java ! test/java/nio/channels/FileChannel/Transfer.java ! test/java/nio/charset/coders/CheckSJISMappingProp.sh ! test/java/nio/file/DirectoryStream/Basic.java ! test/java/nio/file/DirectoryStream/DriveLetter.java ! test/java/nio/file/DirectoryStream/SecureDS.java ! test/java/nio/file/FileStore/Basic.java ! test/java/nio/file/Files/CheckPermissions.java ! test/java/nio/file/Files/CopyAndMove.java ! test/java/nio/file/Files/DeleteOnClose.java ! test/java/nio/file/Files/FileAttributes.java ! test/java/nio/file/Files/InterruptCopy.java ! test/java/nio/file/Files/Links.java ! test/java/nio/file/Files/Misc.java ! test/java/nio/file/Files/PassThroughFileSystem.java ! test/java/nio/file/Files/SBC.java ! test/java/nio/file/Files/TemporaryFiles.java ! test/java/nio/file/Files/delete_on_close.sh ! test/java/nio/file/Files/probeContentType/Basic.java ! test/java/nio/file/Files/probeContentType/ForceLoad.java ! test/java/nio/file/Files/probeContentType/SimpleFileTypeDetector.java ! test/java/nio/file/Files/walkFileTree/CreateFileTree.java ! test/java/nio/file/Files/walkFileTree/MaxDepth.java ! test/java/nio/file/Files/walkFileTree/PrintFileTree.java ! test/java/nio/file/Files/walkFileTree/SkipSiblings.java ! test/java/nio/file/Files/walkFileTree/TerminateWalk.java ! test/java/nio/file/Files/walkFileTree/WalkWithSecurity.java ! test/java/nio/file/Files/walkFileTree/walk_file_tree.sh ! test/java/nio/file/Path/Misc.java ! test/java/nio/file/Path/PathOps.java ! test/java/nio/file/Path/UriImportExport.java ! test/java/nio/file/TestUtil.java ! test/java/nio/file/WatchService/Basic.java ! test/java/nio/file/WatchService/FileTreeModifier.java ! test/java/nio/file/WatchService/LotsOfEvents.java ! test/java/nio/file/WatchService/SensitivityModifier.java ! test/java/nio/file/attribute/AclFileAttributeView/Basic.java ! test/java/nio/file/attribute/BasicFileAttributeView/Basic.java ! test/java/nio/file/attribute/DosFileAttributeView/Basic.java ! test/java/nio/file/attribute/FileTime/Basic.java ! test/java/nio/file/attribute/PosixFileAttributeView/Basic.java ! test/java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java ! test/java/nio/file/spi/SetDefaultProvider.java ! test/java/nio/file/spi/TestProvider.java ! test/java/security/Security/ClassLoaderDeadlock/Deadlock2.sh ! test/java/util/Arrays/Sorting.java ! test/java/util/Collection/MOAT.java ! test/java/util/Currency/ValidateISO4217.java ! test/java/util/Locale/LocaleEnhanceTest.java ! test/java/util/Locale/LocaleTest.java ! test/java/util/Objects/BasicObjectsTest.java ! test/java/util/ResourceBundle/Bug6204853.java ! test/java/util/WeakHashMap/GCDuringIteration.java ! test/java/util/concurrent/Executors/AutoShutdown.java ! test/java/util/concurrent/ThreadPoolExecutor/CoreThreadTimeOut.java ! test/java/util/jar/JarEntry/GetMethodsReturnClones.java ! test/java/util/jar/JarFile/ScanSignedJar.java ! test/java/util/logging/ClassLoaderLeakTest.java ! test/java/util/regex/RegExTest.java ! test/java/util/zip/Available.java ! test/java/util/zip/FileBuilder.java ! test/java/util/zip/GZIP/Accordion.java ! test/java/util/zip/GZIP/GZIPInputStreamRead.java ! test/java/util/zip/InfoZip.java ! test/java/util/zip/LargeZip.java ! test/java/util/zip/TestEmptyZip.java ! test/java/util/zip/ZipCoding.java ! test/java/util/zip/ZipFile/Assortment.java ! test/java/util/zip/ZipFile/Comment.java ! test/java/util/zip/ZipFile/CopyJar.java ! test/java/util/zip/ZipFile/CorruptedZipFiles.java ! test/java/util/zip/ZipFile/DeleteTempJar.java ! test/java/util/zip/ZipFile/EnumAfterClose.java ! test/java/util/zip/ZipFile/FinalizeZipFile.java ! test/java/util/zip/ZipFile/GetDirEntry.java ! test/java/util/zip/ZipFile/LargeZipFile.java ! test/java/util/zip/ZipFile/ManyEntries.java ! test/java/util/zip/ZipFile/ManyZipFiles.java ! test/java/util/zip/ZipFile/ReadAfterClose.java ! test/java/util/zip/ZipFile/ReadZip.java ! test/java/util/zip/ZipFile/ShortRead.java ! test/java/util/zip/zip.java ! test/javax/imageio/stream/StreamCloserLeak/run_test.sh ! test/javax/print/DialogMargins.java ! test/javax/print/attribute/ServiceDialogTest.java ! test/javax/script/CommonSetup.sh ! test/javax/script/VersionTest.java ! test/javax/swing/JFileChooser/6342301/bug6342301.java ! test/javax/swing/JFileChooser/6798062/bug6798062.java ! test/javax/swing/JLabel/7004134/bug7004134.java ! test/javax/swing/JScrollBar/6542335/bug6542335.java ! test/javax/swing/UIDefaults/6795356/bug6795356.java ! test/javax/swing/text/NavigationFilter/6735293/bug6735293.java ! test/javax/swing/text/html/parser/Parser/6990651/bug6990651.java ! test/sun/java2d/pipe/RegionOps.java ! test/sun/misc/URLClassPath/ClassnameCharTest.sh ! test/sun/net/InetAddress/nameservice/chaining/Providers.java ! test/sun/net/InetAddress/nameservice/chaining/Simple1NameServiceDescriptor.java ! test/sun/net/InetAddress/nameservice/chaining/Simple2NameServiceDescriptor.java ! test/sun/net/InetAddress/nameservice/chaining/SimpleNameService.java ! test/sun/net/InetAddress/nameservice/simple/CacheTest.java ! test/sun/net/InetAddress/nameservice/simple/DefaultCaching.java ! test/sun/net/InetAddress/nameservice/simple/SimpleNameService.java ! test/sun/net/InetAddress/nameservice/simple/SimpleNameServiceDescriptor.java ! test/sun/security/krb5/IPv6.java ! test/sun/security/krb5/auto/Context.java ! test/sun/security/krb5/auto/KDC.java ! test/sun/security/krb5/tools/KtabCheck.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHandlerTest.java ! test/sun/text/resources/LocaleDataTest.java ! test/sun/tools/native2ascii/Native2AsciiTests.sh ! test/tools/launcher/Arrrghs.java ! test/tools/launcher/ClassPathWildCard.sh ! test/tools/launcher/MiscTests.java Changeset: eaca823dd3fe Author: ohair Date: 2011-04-07 19:59 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/eaca823dd3fe 7019210: Fix misc references to /bugreport websites Reviewed-by: skannan ! make/docs/Makefile ! src/share/classes/com/sun/beans/TypeResolver.java ! src/share/classes/java/awt/doc-files/AWTThreadIssues.html ! src/share/classes/javax/sql/rowset/package.html ! src/share/classes/javax/swing/package.html ! src/share/classes/sun/tools/javac/resources/javac.properties ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/JarFileSystemProvider.java ! src/share/native/java/lang/System.c Changeset: 712dff1413c0 Author: schien Date: 2011-04-12 13:58 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/712dff1413c0 7022841: LocaleNames_no_NO_NY.class is missing in rt.jar Reviewed-by: katleman, ohair ! make/java/util/FILES_properties.gmk Changeset: 19c6e9043934 Author: yhuang Date: 2011-04-05 21:09 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/19c6e9043934 7020583: Some currency names are missing in some locales Reviewed-by: naoto ! src/share/classes/sun/util/resources/CurrencyNames_de.properties ! src/share/classes/sun/util/resources/CurrencyNames_es.properties ! src/share/classes/sun/util/resources/CurrencyNames_fr.properties ! src/share/classes/sun/util/resources/CurrencyNames_it.properties ! src/share/classes/sun/util/resources/CurrencyNames_ja.properties ! src/share/classes/sun/util/resources/CurrencyNames_ko.properties ! src/share/classes/sun/util/resources/CurrencyNames_sv.properties ! src/share/classes/sun/util/resources/CurrencyNames_zh_CN.properties ! src/share/classes/sun/util/resources/CurrencyNames_zh_TW.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: 0aa16a3c5c95 Author: mfang Date: 2011-04-06 22:54 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0aa16a3c5c95 6384973: Incorrect translations in awt.properties Reviewed-by: yhuang ! src/share/classes/sun/awt/resources/awt_fr.properties Changeset: b2e8a6e414c4 Author: mfang Date: 2011-04-07 20:31 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b2e8a6e414c4 7034932: Merging src/share/classes/sun/util/resources/CurrencyNames.properties and CurrencyNames_pt.propertie Reviewed-by: yhuang ! src/share/classes/sun/util/resources/CurrencyNames.properties ! src/share/classes/sun/util/resources/CurrencyNames_pt.properties Changeset: fe4701bfdf26 Author: mfang Date: 2011-04-08 14:48 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fe4701bfdf26 7034940: message drop 2 translation integration Reviewed-by: yhuang ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_de.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_es.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_fr.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_it.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_ja.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_ko.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_pt_BR.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_sv.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_zh_CN.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_zh_TW.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_de.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_fr.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_it.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_pt_BR.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_CN.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_TW.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_de.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_es.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_fr.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_it.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_ja.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_pt_BR.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_sv.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_zh_CN.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_zh_TW.properties ! src/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_de.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_es.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_fr.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_it.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_ja.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_ko.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_pt_BR.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_sv.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_zh_CN.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_zh_TW.java ! src/share/classes/sun/launcher/resources/launcher_de.properties ! src/share/classes/sun/launcher/resources/launcher_es.properties ! src/share/classes/sun/launcher/resources/launcher_fr.properties ! src/share/classes/sun/launcher/resources/launcher_it.properties ! src/share/classes/sun/launcher/resources/launcher_ja.properties ! src/share/classes/sun/launcher/resources/launcher_ko.properties ! src/share/classes/sun/launcher/resources/launcher_pt_BR.properties ! src/share/classes/sun/launcher/resources/launcher_sv.properties ! src/share/classes/sun/launcher/resources/launcher_zh_CN.properties ! src/share/classes/sun/launcher/resources/launcher_zh_TW.properties ! src/share/classes/sun/print/resources/serviceui_de.properties ! src/share/classes/sun/print/resources/serviceui_es.properties ! src/share/classes/sun/print/resources/serviceui_fr.properties ! src/share/classes/sun/print/resources/serviceui_it.properties ! src/share/classes/sun/print/resources/serviceui_ja.properties ! src/share/classes/sun/print/resources/serviceui_ko.properties ! src/share/classes/sun/print/resources/serviceui_pt_BR.properties ! src/share/classes/sun/print/resources/serviceui_sv.properties ! src/share/classes/sun/print/resources/serviceui_zh_CN.properties ! src/share/classes/sun/print/resources/serviceui_zh_TW.properties ! src/share/classes/sun/rmi/server/resources/rmid_de.properties ! src/share/classes/sun/rmi/server/resources/rmid_sv.properties ! src/share/classes/sun/tools/jconsole/resources/JConsoleResources_ja.java ! src/share/classes/sun/tools/jconsole/resources/JConsoleResources_zh_CN.java ! src/share/classes/sun/util/logging/resources/logging_de.properties ! src/share/classes/sun/util/logging/resources/logging_es.properties ! src/share/classes/sun/util/logging/resources/logging_fr.properties ! src/share/classes/sun/util/logging/resources/logging_it.properties ! src/share/classes/sun/util/logging/resources/logging_ja.properties ! src/share/classes/sun/util/logging/resources/logging_ko.properties ! src/share/classes/sun/util/logging/resources/logging_pt_BR.properties ! src/share/classes/sun/util/logging/resources/logging_sv.properties ! src/share/classes/sun/util/logging/resources/logging_zh_CN.properties ! src/share/classes/sun/util/logging/resources/logging_zh_TW.properties Changeset: a17b92c217e8 Author: mfang Date: 2011-04-08 15:04 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a17b92c217e8 7024528: [sv] format error in appletviewer usage translation Reviewed-by: yhuang ! src/share/classes/sun/applet/resources/MsgAppletViewer_sv.java Changeset: 708070751be6 Author: mfang Date: 2011-04-08 16:17 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/708070751be6 Merge Changeset: cb3a6795cca5 Author: mfang Date: 2011-04-11 13:59 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cb3a6795cca5 Merge Changeset: 3cda8aa91ae4 Author: mfang Date: 2011-04-11 14:05 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3cda8aa91ae4 Merge Changeset: 14898478f33f Author: mfang Date: 2011-04-11 16:19 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/14898478f33f Merge ! src/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_de.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_es.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_fr.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_it.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_ja.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_ko.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_pt_BR.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_sv.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_zh_CN.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_zh_TW.java ! src/share/classes/sun/rmi/server/resources/rmid_de.properties ! src/share/classes/sun/rmi/server/resources/rmid_sv.properties ! src/share/classes/sun/tools/jconsole/resources/JConsoleResources_ja.java ! src/share/classes/sun/tools/jconsole/resources/JConsoleResources_zh_CN.java ! src/share/classes/sun/util/logging/resources/logging_de.properties ! src/share/classes/sun/util/logging/resources/logging_es.properties ! src/share/classes/sun/util/logging/resources/logging_fr.properties ! src/share/classes/sun/util/logging/resources/logging_it.properties ! src/share/classes/sun/util/logging/resources/logging_ja.properties ! src/share/classes/sun/util/logging/resources/logging_ko.properties ! src/share/classes/sun/util/logging/resources/logging_pt_BR.properties ! src/share/classes/sun/util/logging/resources/logging_sv.properties ! src/share/classes/sun/util/logging/resources/logging_zh_CN.properties ! src/share/classes/sun/util/logging/resources/logging_zh_TW.properties ! test/sun/text/resources/LocaleDataTest.java Changeset: cdd6e256d831 Author: mfang Date: 2011-04-12 18:58 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cdd6e256d831 Merge Changeset: 03d8d1eaaf6d Author: ohair Date: 2011-04-12 14:23 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/03d8d1eaaf6d 7033957: Library built without a mapfile: libxinerama.so Reviewed-by: ksrini ! make/common/shared/Defs-solaris.gmk Changeset: 0069845a086c Author: ohair Date: 2011-04-12 22:22 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0069845a086c Merge Changeset: 60d3d55dcc9c Author: ohair Date: 2011-04-13 16:56 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/60d3d55dcc9c Merge ! make/common/Library.gmk ! make/java/java/Makefile ! make/java/management/Makefile ! make/java/net/Makefile ! make/java/zip/Makefile ! make/launchers/Makefile ! make/mkdemo/jfc/Makefile ! make/sun/Makefile ! make/sun/jawt/Makefile ! make/sun/jpeg/Makefile ! make/sun/nio/cs/Makefile ! make/sun/security/tools/Makefile ! make/sun/xawt/Makefile ! make/sun/xawt/mapfile-vers ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/image/SinglePixelPackedSampleModel.java ! src/share/classes/java/lang/management/ManagementFactory.java ! src/share/classes/java/lang/management/PlatformComponent.java ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/nio/file/Path.java ! src/share/classes/java/util/Collections.java ! src/share/classes/javax/swing/JLayer.java ! src/share/classes/javax/swing/plaf/LayerUI.java ! src/share/classes/sun/font/SunFontManager.java ! src/share/classes/sun/java2d/SunGraphicsEnvironment.java ! src/share/classes/sun/nio/fs/Util.java ! src/share/classes/sun/security/krb5/Realm.java ! src/share/classes/sun/util/logging/PlatformLogger.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/LinuxFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/SolarisFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/UnixPath.java ! src/solaris/classes/sun/nio/fs/UnixSecureDirectoryStream.java ! src/solaris/native/sun/java2d/x11/XRBackendNative.c ! src/solaris/native/sun/xawt/XToolkit.c ! src/windows/classes/sun/awt/windows/WToolkit.java ! src/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java ! src/windows/classes/sun/nio/fs/WindowsPath.java ! src/windows/native/java/io/WinNTFileSystem_md.c ! src/windows/native/java/net/Inet6AddressImpl.c ! src/windows/native/sun/nio/fs/WindowsNativeDispatcher.c ! src/windows/native/sun/windows/awt_Toolkit.cpp ! test/Makefile ! test/ProblemList.txt ! test/java/lang/invoke/indify/Indify.java ! test/java/nio/file/Files/CheckPermissions.java ! test/java/nio/file/Files/PassThroughFileSystem.java ! test/java/nio/file/Path/Misc.java ! test/sun/security/krb5/IPv6.java Changeset: 6e099ee5c6f5 Author: schien Date: 2011-04-14 15:21 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6e099ee5c6f5 Added tag jdk7-b138 for changeset 60d3d55dcc9c ! .hgtags Changeset: caebdaf362ee Author: lana Date: 2011-04-17 16:19 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/caebdaf362ee Merge ! make/com/sun/java/pack/Makefile ! make/common/Program.gmk ! make/docs/Makefile ! make/java/main/java/Makefile ! make/javax/crypto/Defs-jce.gmk ! src/share/classes/com/sun/beans/TypeResolver.java ! src/share/classes/java/awt/doc-files/AWTThreadIssues.html ! src/share/classes/java/io/Console.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/Package.java ! src/share/classes/java/security/SecureClassLoader.java ! src/share/classes/java/util/EnumMap.java ! src/share/classes/java/util/IdentityHashMap.java ! src/share/classes/java/util/logging/FileHandler.java ! src/share/classes/java/util/regex/Pattern.java ! src/share/classes/javax/crypto/Cipher.java ! src/share/classes/javax/swing/plaf/LayerUI.java ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/share/classes/sun/security/pkcs11/Config.java ! src/share/classes/sun/security/ssl/CipherSuiteList.java ! src/share/classes/sun/security/ssl/ProtocolList.java ! src/windows/classes/sun/nio/fs/WindowsFileSystem.java ! test/ProblemList.txt ! test/com/sun/tools/attach/ApplicationSetup.sh ! test/com/sun/tools/attach/BasicTests.sh ! test/sun/security/krb5/auto/KDC.java From joe.darcy at oracle.com Mon Apr 18 05:52:46 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Mon, 18 Apr 2011 05:52:46 +0000 Subject: hg: jdk7/tl/jdk: 7021568: Double.parseDouble() returns architecture dependent results Message-ID: <20110418055255.F0AE647BB3@hg.openjdk.java.net> Changeset: bcc6e4c28684 Author: darcy Date: 2011-04-17 22:52 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bcc6e4c28684 7021568: Double.parseDouble() returns architecture dependent results Reviewed-by: alanb ! src/share/classes/sun/misc/FloatingDecimal.java ! src/share/classes/sun/misc/FormattedFloatingDecimal.java ! test/java/lang/Double/ParseDouble.java From michael.x.mcmahon at oracle.com Mon Apr 18 09:59:24 2011 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 18 Apr 2011 10:59:24 +0100 Subject: Review request for 7034570 - java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited In-Reply-To: References: <4DA58A18.8080004@oracle.com> <4DA5B125.7030707@gmx.de> <4DA5CD33.50609@oracle.com> <4DA6FF50.7010308@oracle.com> <4DA75F4D.60809@gmx.de> <4DA813A5.5070606@oracle.com> <4DA815C7.2000500@oracle.com> <4DA8260C.6040606@gmx.de> <4DA836E7.8050200@oracle.com> <4DA83DFA.9050207@gmx.de> <4DA84B91.30607@oracle.com> <4DA973EA.6050705@oracle.com> <4DAB22FB.8000405@gmx.de> Message-ID: <4DAC0B7C.20507@oracle.com> David Schlosnagle wrote: > On Sun, Apr 17, 2011 at 1:27 PM, Ulf Zibis wrote: > >> Am 16.04.2011 16:45, schrieb David Schlosnagle: >> >>> One minor nit in ProcessEnvironment.java >>> >>> 336 private static void addToEnv(StringBuilder sb, String name, >>> String val) { >>> 337 sb.append(name+"="+val+'\u0000'); >>> 338 } >>> >>> I think it should be as follows to avoid implicitly constructing >>> another StringBuilder and the extra copying overhead; >>> >>> 336 private static void addToEnv(StringBuilder sb, String name, >>> String val) { >>> 337 sb.append(name).append('=').append(val).append('\u0000'); >>> 338 } >>> >>> >> Because this suggestion was from me, I must admit, that I didn't prove, if >> javac actually uses the existing StringBuilder sb, or forces another >> StringBuilder to instantiate. I just assumed, javac would use the existing >> one. So to be done: >> - examine the byte code >> - if not yet optimized: then new RFE for javac >> > > Ulf, > > I'm not the right person to comment on whether javac could safely > optimize away the StringBuilder creation here per JLS 15.18.1 [1] [2], > but in this situation I'd assume that the expression > name+"="+val+'\u0000' must return a "result is a reference to a String > object (newly created, unless the expression is a compile-time > constant expression (?15.28))that is the concatenation of the two > operand strings" in which case I don't think javac can optimize it > away. > > Some IDEs such as IntelliJ offer code inspections to find and fix such > items, see "String concatenation inside 'StringBuffer.append()'" [3]: > This inspection reports any instances of String concatenation used as the > argument to StringBuffer.append(), StringBuilder.append() or > Appendable.append(). Such calls may profitably be turned into chained > append calls on the existing StringBuffer/Builder/Appendable, saving the > cost of an extra StringBuffer/Builder allocation. > > This inspection ignores compile time evaluated String concatenations, which > when converted to chained append calls would only worsen performance. > > Here's a quick `javap -c -private` dump of these two different methods > in a test class, showing that the changes I'm recommending simplify > the bytecode and avoid the extra StringBuilder construction and > copying of underlying characters: > > Thanks for confirming that. I'll switch it back to the original chained .append(). - Michael. From chris.hegarty at oracle.com Mon Apr 18 10:16:25 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 18 Apr 2011 10:16:25 +0000 Subject: hg: jdk7/tl/jdk: 7030649: URL.equals() fails to compare jar urls Message-ID: <20110418101654.2F8A447BBD@hg.openjdk.java.net> Changeset: 7e7bb0a97c40 Author: chegar Date: 2011-04-18 11:14 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7e7bb0a97c40 7030649: URL.equals() fails to compare jar urls Reviewed-by: michaelm ! src/share/classes/sun/net/www/protocol/jar/Handler.java ! test/java/net/URL/Equals.java From dl at cs.oswego.edu Mon Apr 18 10:18:44 2011 From: dl at cs.oswego.edu (Doug Lea) Date: Mon, 18 Apr 2011 06:18:44 -0400 Subject: Fwd: [concurrency-interest] ConcurrentHashMap footprint and contention improvements In-Reply-To: <4DA5C812.4080408@oracle.com> References: <4DA4EA8E.6070506@cs.oswego.edu> <4DA5C812.4080408@oracle.com> Message-ID: <4DAC1004.2060008@cs.oswego.edu> On 04/13/11 11:58, Chris Hegarty wrote: > This change does appear worthwhile. We have a narrowing window of opportunity > for JDK7. I spoke to Alan Bateman about this and we feel that if we could > finalize the JDK7 changes by next Monday (that is, get them in for JDK7 b140), > this would give us a reasonable time for them to soak before it gets harder to > get changes into 7. > > Do you think this is a reasonable time frame? I got a few small suggestions for improvements etc (now incorporated) and no reports of performance anomalies, so I think we should commit. -Doug From chris.hegarty at oracle.com Mon Apr 18 10:21:44 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 18 Apr 2011 11:21:44 +0100 Subject: Fwd: [concurrency-interest] ConcurrentHashMap footprint and contention improvements In-Reply-To: <4DAC1004.2060008@cs.oswego.edu> References: <4DA4EA8E.6070506@cs.oswego.edu> <4DA5C812.4080408@oracle.com> <4DAC1004.2060008@cs.oswego.edu> Message-ID: <4DAC10B8.1080806@oracle.com> On 04/18/11 11:18 AM, Doug Lea wrote: > On 04/13/11 11:58, Chris Hegarty wrote: >> This change does appear worthwhile. We have a narrowing window of >> opportunity >> for JDK7. I spoke to Alan Bateman about this and we feel that if we could >> finalize the JDK7 changes by next Monday (that is, get them in for >> JDK7 b140), >> this would give us a reasonable time for them to soak before it gets >> harder to >> get changes into 7. >> >> Do you think this is a reasonable time frame? > > I got a few small suggestions for improvements etc (now incorporated) > and no reports of performance anomalies, so I think we should commit. Thanks Doug, I seen some of the comments on c-i. I just pulled the latest CHM from your CVS and have started a JPRT job. All going well, I hope to integrate these changes later today. -Chris. > > -Doug > From Ulf.Zibis at gmx.de Mon Apr 18 11:00:22 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 18 Apr 2011 13:00:22 +0200 Subject: Review request for 7034570 - java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited In-Reply-To: References: <4DA58A18.8080004@oracle.com> <4DA5B125.7030707@gmx.de> <4DA5CD33.50609@oracle.com> <4DA6FF50.7010308@oracle.com> <4DA75F4D.60809@gmx.de> <4DA813A5.5070606@oracle.com> <4DA815C7.2000500@oracle.com> <4DA8260C.6040606@gmx.de> <4DA836E7.8050200@oracle.com> <4DA83DFA.9050207@gmx.de> <4DA84B91.30607@oracle.com> <4DA973EA.6050705@oracle.com> <4DAB22FB.8000405@gmx.de> Message-ID: <4DAC19C6.5060907@gmx.de> Hi David, much thanks for your detailed effort. -Ulf Am 17.04.2011 22:50, schrieb David Schlosnagle: > On Sun, Apr 17, 2011 at 1:27 PM, Ulf Zibis wrote: >> Am 16.04.2011 16:45, schrieb David Schlosnagle: >>> One minor nit in ProcessEnvironment.java >>> >>> 336 private static void addToEnv(StringBuilder sb, String name, >>> String val) { >>> 337 sb.append(name+"="+val+'\u0000'); >>> 338 } >>> >>> I think it should be as follows to avoid implicitly constructing >>> another StringBuilder and the extra copying overhead; >>> >>> 336 private static void addToEnv(StringBuilder sb, String name, >>> String val) { >>> 337 sb.append(name).append('=').append(val).append('\u0000'); >>> 338 } >>> >> Because this suggestion was from me, I must admit, that I didn't prove, if >> javac actually uses the existing StringBuilder sb, or forces another >> StringBuilder to instantiate. I just assumed, javac would use the existing >> one. So to be done: >> - examine the byte code >> - if not yet optimized: then new RFE for javac > Ulf, > > I'm not the right person to comment on whether javac could safely > optimize away the StringBuilder creation here per JLS 15.18.1 [1] [2], > but in this situation I'd assume that the expression > name+"="+val+'\u0000' must return a "result is a reference to a String > object (newly created, unless the expression is a compile-time > constant expression (?15.28))that is the concatenation of the two > operand strings" in which case I don't think javac can optimize it > away. > > Some IDEs such as IntelliJ offer code inspections to find and fix such > items, see "String concatenation inside 'StringBuffer.append()'" [3]: > This inspection reports any instances of String concatenation used as the > argument to StringBuffer.append(), StringBuilder.append() or > Appendable.append(). Such calls may profitably be turned into chained > append calls on the existing StringBuffer/Builder/Appendable, saving the > cost of an extra StringBuffer/Builder allocation. > > This inspection ignores compile time evaluated String concatenations, which > when converted to chained append calls would only worsen performance. > > Here's a quick `javap -c -private` dump of these two different methods > in a test class, showing that the changes I'm recommending simplify > the bytecode and avoid the extra StringBuilder construction and > copying of underlying characters: > > > Before: > private static void addToEnv(StringBuilder sb, String name, String val) { > sb.append(name+"="+val+'\u0000'); > } > > Yields: > > private static void addToEnv(java.lang.StringBuilder, > java.lang.String, java.lang.String); > Code: > 0: aload_0 > 1: new #2; //class java/lang/StringBuilder > 4: dup > 5: invokespecial #3; //Method java/lang/StringBuilder."":()V > 8: aload_1 > 9: invokevirtual #8; //Method > java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder; > 12: ldc #9; //String = > 14: invokevirtual #8; //Method > java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder; > 17: aload_2 > 18: invokevirtual #8; //Method > java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder; > 21: iconst_0 > 22: invokevirtual #10; //Method > java/lang/StringBuilder.append:(C)Ljava/lang/StringBuilder; > 25: invokevirtual #11; //Method > java/lang/StringBuilder.toString:()Ljava/lang/String; > 28: invokevirtual #8; //Method > java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder; > 31: pop > 32: return > > ---- > > After: > private static void addToEnv(StringBuilder sb, String name, String val) { > sb.append(name).append('=').append(val).append('\u0000'); > } > > Yields: > > private static void addToEnv(java.lang.StringBuilder, > java.lang.String, java.lang.String); > Code: > 0: aload_0 > 1: aload_1 > 2: invokevirtual #8; //Method > java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder; > 5: bipush 61 > 7: invokevirtual #10; //Method > java/lang/StringBuilder.append:(C)Ljava/lang/StringBuilder; > 10: aload_2 > 11: invokevirtual #8; //Method > java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder; > 14: iconst_0 > 15: invokevirtual #10; //Method > java/lang/StringBuilder.append:(C)Ljava/lang/StringBuilder; > 18: pop > 19: return > > [1] http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.18.1 > [2] http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.18.1.2 > [3] http://www.jetbrains.com/idea/documentation/inspections/StringConcatenationInsideStringBufferAppend.html > > > - Dave > From neil.richards at ngmr.net Mon Apr 18 12:33:21 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Mon, 18 Apr 2011 13:33:21 +0100 Subject: Suspected regression: fix for 6735255 causes delay in GC of ZipFile InputStreams, increase in heap demand In-Reply-To: <4DA76BA8.6000109@oracle.com> References: <1300916786.4515.107.camel@chalkhill> <4D922D68.2080202@oracle.com> <1301514810.24605.64.camel@chalkhill> <4D93930A.2000604@oracle.com> <1301676177.24605.165.camel@chalkhill> <4D962275.7010601@oracle.com> <4D965D14.6060504@oracle.com> <1301707718.14323.43.camel@chalkhill> <4D98FD10.4090608@oracle.com> <1302183023.27698.20.camel@chalkhill> <4D9E429F.9030200@oracle.com> <1302266193.17745.18.camel@chalkhill> <4D9FD836.1070909@oracle.com> <1302456482.18865.109.camel@chalkhill> <1302524116.15253.25.camel@chalkhill> <4DA4A8EF.4060103@oracle.com> <4DA5BEFA.30707@linux.vnet.ibm.com> <4DA5C052.6030500@linux.vnet.ibm.com> <4DA76BA8.6000109@oracle.com> Message-ID: <1303130001.20081.95.camel@chalkhill> On Thu, 2011-04-14 at 14:48 -0700, Xueming Shen wrote: > Opinion? anything I overlooked/missed? Hi Sherman, Thanks once more for all your help and advice on this - I'm in favour of almost all of what you suggest. :-) I think it's worthwhile trying to clear 'streams' entries from a finalize method in ZFIIS, to help ensure they are cleared in a timely manner. I don't think the Inflater objects need to be held softly in 'inflaterCache', as they will have been reset() at the point they are put into that cache (in releaseInflater()). (I was holding them softly due to a worry over any delay in clearing their 'buf' reference, which is done when reset() is called. Now that the 'streams' entries are being cleared from close() and finalize() - ie. up front - I think this worry is adequately addressed.) I'm worried about changing the object 'streams' refers to in ZipFile.close(), as threads are using that object to synchronize against. I don't believe it is currently giving the guarantee against ConcurrentModificationException being seen from the iterator that I believe you intend it to be, as other threads, calling (for example) ZFIIS.close() at the same time will not be guaranteed to see the update to the value of 'streams'. Instead, I've modified this code so that a real copy of 'streams' is produced, by calling 'new HashMap<>(streams)'. It is this copy that is iterated through to close() the InputStreams and end() the Inflaters. Once the copy is obtained, 'streams' can be safely clear()'d. Because it is not clear that a Collections.synchronizedMap will give consistent results when fed into the constructor of HashMap, I've used explicit synchronization on 'streams' instead, to ensure 'streams' isn't modified during the construction of 'copy'. As each of the calls to InputStream.close() will synchronize on 'streams' to call its remove() method, I've held that monitor whilst those calls are made. Other minor tweaks are changing 'isClosed' fields to 'closeRequested' (to better describe their use now), changing 'ZipFile.closeRequested' to be volatile (so it can be checked before synchronization, and so that it conforms to the pattern now established elsewhere in the file), and reducing the synchronization block in releaseInflater() (only the call to 'inflateCache.add()' need be protected by synchronization on 'inflaterCache'). Please find below the resultant changeset, Let me know what you think, Thanks, Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU # HG changeset patch # User Neil Richards , # Date 1300289208 0 # Branch zip-heap # Node ID c1c7b2dfa0091938bebc0727224690afc892a0b7 # Parent aa13e7702cd9d8aca9aa38f1227f966990866944 7031076: Retained ZipFile InputStreams increase heap demand Summary: Allow unreferenced ZipFile InputStreams to be finalized, GC'd Contributed-by: diff -r aa13e7702cd9 -r c1c7b2dfa009 src/share/classes/java/util/zip/ZipFile.java --- a/src/share/classes/java/util/zip/ZipFile.java Tue Mar 29 20:19:55 2011 -0700 +++ b/src/share/classes/java/util/zip/ZipFile.java Wed Mar 16 15:26:48 2011 +0000 @@ -31,11 +31,13 @@ import java.io.EOFException; import java.io.File; import java.nio.charset.Charset; -import java.util.Vector; +import java.util.ArrayDeque; +import java.util.Deque; import java.util.Enumeration; -import java.util.Set; -import java.util.HashSet; +import java.util.HashMap; +import java.util.Map; import java.util.NoSuchElementException; +import java.util.WeakHashMap; import java.security.AccessController; import sun.security.action.GetPropertyAction; import static java.util.zip.ZipConstants64.*; @@ -54,7 +56,7 @@ private long jzfile; // address of jzfile data private String name; // zip file name private int total; // total number of entries - private boolean closeRequested; + private volatile boolean closeRequested = false; private static final int STORED = ZipEntry.STORED; private static final int DEFLATED = ZipEntry.DEFLATED; @@ -314,8 +316,9 @@ // freeEntry releases the C jzentry struct. private static native void freeEntry(long jzfile, long jzentry); - // the outstanding inputstreams that need to be closed. - private Set streams = new HashSet<>(); + // the outstanding inputstreams that need to be closed, + // mapped to the inflater objects they use. + private final Map streams = new WeakHashMap<>(); /** * Returns an input stream for reading the contents of the specified @@ -351,51 +354,21 @@ switch (getEntryMethod(jzentry)) { case STORED: - streams.add(in); + synchronized (streams) { + streams.put(in, null); + } return in; case DEFLATED: - final ZipFileInputStream zfin = in; // MORE: Compute good size for inflater stream: long size = getEntrySize(jzentry) + 2; // Inflater likes a bit of slack if (size > 65536) size = 8192; if (size <= 0) size = 4096; - InputStream is = new InflaterInputStream(zfin, getInflater(), (int)size) { - private boolean isClosed = false; - - public void close() throws IOException { - if (!isClosed) { - super.close(); - releaseInflater(inf); - isClosed = true; - } - } - // Override fill() method to provide an extra "dummy" byte - // at the end of the input stream. This is required when - // using the "nowrap" Inflater option. - protected void fill() throws IOException { - if (eof) { - throw new EOFException( - "Unexpected end of ZLIB input stream"); - } - len = this.in.read(buf, 0, buf.length); - if (len == -1) { - buf[0] = 0; - len = 1; - eof = true; - } - inf.setInput(buf, 0, len); - } - private boolean eof; - - public int available() throws IOException { - if (isClosed) - return 0; - long avail = zfin.size() - inf.getBytesWritten(); - return avail > (long) Integer.MAX_VALUE ? - Integer.MAX_VALUE : (int) avail; - } - }; - streams.add(is); + Inflater inf = getInflater(); + InputStream is = + new ZipFileInflaterInputStream(in, inf, (int)size); + synchronized (streams) { + streams.put(is, inf); + } return is; default: throw new ZipException("invalid compression method"); @@ -403,36 +376,93 @@ } } + private class ZipFileInflaterInputStream extends InflaterInputStream { + private volatile boolean closeRequested = false; + private boolean eof = false; + private final ZipFileInputStream zfin; + + ZipFileInflaterInputStream(ZipFileInputStream zfin, Inflater inf, + int size) { + super(zfin, inf, size); + this.zfin = zfin; + } + + public void close() throws IOException { + if (closeRequested) + return; + closeRequested = true; + + super.close(); + Inflater inf; + synchronized (streams) { + inf = streams.remove(this); + } + if (inf != null) { + releaseInflater(inf); + } + } + + // Override fill() method to provide an extra "dummy" byte + // at the end of the input stream. This is required when + // using the "nowrap" Inflater option. + protected void fill() throws IOException { + if (eof) { + throw new EOFException("Unexpected end of ZLIB input stream"); + } + len = in.read(buf, 0, buf.length); + if (len == -1) { + buf[0] = 0; + len = 1; + eof = true; + } + inf.setInput(buf, 0, len); + } + + public int available() throws IOException { + if (closeRequested) + return 0; + long avail = zfin.size() - inf.getBytesWritten(); + return (avail > (long) Integer.MAX_VALUE ? + Integer.MAX_VALUE : (int) avail); + } + + protected void finalize() { + synchronized (streams) { + streams.remove(this); + } + } + } + /* * Gets an inflater from the list of available inflaters or allocates * a new one. */ private Inflater getInflater() { - synchronized (inflaters) { - int size = inflaters.size(); - if (size > 0) { - Inflater inf = (Inflater)inflaters.remove(size - 1); - return inf; - } else { - return new Inflater(true); + Inflater inf; + synchronized (inflaterCache) { + while (null != (inf = inflaterCache.poll())) { + if (false == inf.ended()) { + return inf; + } } } + return new Inflater(true); } /* * Releases the specified inflater to the list of available inflaters. */ private void releaseInflater(Inflater inf) { - synchronized (inflaters) { - if (inf.ended()) - return; + if (false == inf.ended()) { inf.reset(); - inflaters.add(inf); + synchronized (inflaterCache) { + inflaterCache.add(inf); + } } } // List of available Inflater objects for decompression - private Vector inflaters = new Vector(); + private Deque inflaterCache = new ArrayDeque<>(); /** * Returns the path name of the ZIP file. @@ -540,14 +570,32 @@ * @throws IOException if an I/O error has occurred */ public void close() throws IOException { + if (closeRequested) + return; + closeRequested = true; + synchronized (this) { - closeRequested = true; + // Close streams, release their inflaters + synchronized (streams) { + if (false == streams.isEmpty()) { + Map copy = new HashMap<>(streams); + streams.clear(); + for (Map.Entry e : copy.entrySet()) { + e.getKey().close(); + Inflater inf = e.getValue(); + if (inf != null) { + inf.end(); + } + } + } + } - if (streams.size() !=0) { - Set copy = streams; - streams = new HashSet<>(); - for (InputStream is: copy) - is.close(); + // Release cached inflaters + Inflater inf; + synchronized (inflaterCache) { + while (null != (inf = inflaterCache.poll())) { + inf.end(); + } } if (jzfile != 0) { @@ -556,23 +604,13 @@ jzfile = 0; close(zf); - - // Release inflaters - synchronized (inflaters) { - int size = inflaters.size(); - for (int i = 0; i < size; i++) { - Inflater inf = (Inflater)inflaters.get(i); - inf.end(); - } - } } } } - /** - * Ensures that the close method of this ZIP file is - * called when there are no more references to it. + * Ensures that the system resources held by this ZipFile object are + * released when there are no more references to it. * *

* Since the time when GC would invoke this method is undetermined, @@ -611,6 +649,7 @@ * (possibly compressed) zip file entry. */ private class ZipFileInputStream extends InputStream { + private volatile boolean closeRequested = false; protected long jzentry; // address of jzentry data private long pos; // current position within entry data protected long rem; // number of remaining bytes within entry @@ -678,15 +717,25 @@ } public void close() { + if (closeRequested) + return; + closeRequested = true; + rem = 0; synchronized (ZipFile.this) { if (jzentry != 0 && ZipFile.this.jzfile != 0) { freeEntry(ZipFile.this.jzfile, jzentry); jzentry = 0; } + } + synchronized (streams) { streams.remove(this); } } + + protected void finalize() { + close(); + } } diff -r aa13e7702cd9 -r c1c7b2dfa009 test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java Wed Mar 16 15:26:48 2011 +0000 @@ -0,0 +1,148 @@ +/* + * Copyright (c) 2011 Oracle and/or its affiliates. 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 Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/* + * Portions Copyright (c) 2011 IBM Corporation + */ + +/* + * @test + * @bug 7031076 + * @summary Allow stale InputStreams from ZipFiles to be GC'd + * @author Neil Richards , + */ +import java.lang.ref.ReferenceQueue; +import java.lang.ref.WeakReference; +import java.io.File; +import java.io.FileOutputStream; +import java.io.InputStream; +import java.util.Enumeration; +import java.util.HashSet; +import java.util.Random; +import java.util.Set; +import java.util.zip.ZipEntry; +import java.util.zip.ZipFile; +import java.util.zip.ZipOutputStream; + +public class ClearStaleZipFileInputStreams { + private static final int ZIP_ENTRY_NUM = 5; + + private static final byte[][] data; + + static { + data = new byte[ZIP_ENTRY_NUM][]; + Random r = new Random(); + for (int i = 0; i < ZIP_ENTRY_NUM; i++) { + data[i] = new byte[1000]; + r.nextBytes(data[i]); + } + } + + private static File createTestFile(int compression) throws Exception { + File tempZipFile = + File.createTempFile("test-data" + compression, ".zip"); + tempZipFile.deleteOnExit(); + + ZipOutputStream zos = + new ZipOutputStream(new FileOutputStream(tempZipFile)); + zos.setLevel(compression); + + try { + for (int i = 0; i < ZIP_ENTRY_NUM; i++) { + String text = "Entry" + i; + ZipEntry entry = new ZipEntry(text); + zos.putNextEntry(entry); + try { + zos.write(data[i], 0, data[i].length); + } finally { + zos.closeEntry(); + } + } + } finally { + zos.close(); + } + + return tempZipFile; + } + + private static void startGcInducingThread(final int sleepMillis) { + final Thread gcInducingThread = new Thread() { + public void run() { + while (true) { + System.gc(); + try { + Thread.sleep(sleepMillis); + } catch (InterruptedException e) { } + } + } + }; + + gcInducingThread.setDaemon(true); + gcInducingThread.start(); + } + + public static void main(String[] args) throws Exception { + startGcInducingThread(500); + runTest(ZipOutputStream.DEFLATED); + runTest(ZipOutputStream.STORED); + } + + private static void runTest(int compression) throws Exception { + ReferenceQueue rq = new ReferenceQueue<>(); + + System.out.println("Testing with a zip file with compression level = " + + compression); + File f = createTestFile(compression); + try { + ZipFile zf = new ZipFile(f); + try { + Set refSet = createTransientInputStreams(zf, rq); + + System.out.println("Waiting for 'stale' input streams from ZipFile to be GC'd ..."); + System.out.println("(The test will hang on failure)"); + while (false == refSet.isEmpty()) { + refSet.remove(rq.remove()); + } + System.out.println("Test PASSED."); + System.out.println(); + } finally { + zf.close(); + } + } finally { + f.delete(); + } + } + + private static Set createTransientInputStreams(ZipFile zf, + ReferenceQueue rq) throws Exception { + Enumeration zfe = zf.entries(); + Set refSet = new HashSet<>(); + + while (zfe.hasMoreElements()) { + InputStream is = zf.getInputStream(zfe.nextElement()); + refSet.add(new WeakReference(is, rq)); + } + + return refSet; + } +} From Ulf.Zibis at gmx.de Mon Apr 18 13:10:39 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 18 Apr 2011 15:10:39 +0200 Subject: Review request for 7034570 - java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited In-Reply-To: <4DA973EA.6050705@oracle.com> References: <4DA58A18.8080004@oracle.com> <4DA5B125.7030707@gmx.de> <4DA5CD33.50609@oracle.com> <4DA6FF50.7010308@oracle.com> <4DA75F4D.60809@gmx.de> <4DA813A5.5070606@oracle.com> <4DA815C7.2000500@oracle.com> <4DA8260C.6040606@gmx.de> <4DA836E7.8050200@oracle.com> <4DA83DFA.9050207@gmx.de> <4DA84B91.30607@oracle.com> <4DA973EA.6050705@oracle.com> Message-ID: <4DAC384F.8040008@gmx.de> Am 16.04.2011 12:48, schrieb Alan Bateman: > Michael McMahon wrote: >> I have incorporated much of Ulf's approach into this version. >> >> I agree with Alan about the spec. We could find other variables in the future that need >> to be set, but can have alternative values other than the default. I think this approach >> is the most flexible. >> >> http://cr.openjdk.java.net/~michaelm/7034570/webrev.4/ > This looks much better - thanks Ulf for the improved loop and changing it to use nameComparator. > It will be good to get this one fixed. > Thanks for the partial acceptance. I think, the comment in lines 295..297 more belongs to the code (lines 312..315 + 318..320 ) rather than to the constant SYSTEMROOT. Why defining it as class member, as it is only locally referred? I still don't see the advantage, having the SYSTEMROOT insertion code at 2 call sites. One would be shorter and much clearer as shown in my code. Then we too could save addToEnvIfSet(..) and the call to it. Additionally: Why instantiating, initializing and processing a fat j.u.List object, if a simple array would fulfil all needs? You have removed the 'Ensure double NUL termination' code. I guess, you have approved, that String->CString already handles this, right? -Ulf From michael.x.mcmahon at oracle.com Mon Apr 18 13:43:49 2011 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 18 Apr 2011 14:43:49 +0100 Subject: Review request for 7034570 - java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited In-Reply-To: <4DAC384F.8040008@gmx.de> References: <4DA58A18.8080004@oracle.com> <4DA5B125.7030707@gmx.de> <4DA5CD33.50609@oracle.com> <4DA6FF50.7010308@oracle.com> <4DA75F4D.60809@gmx.de> <4DA813A5.5070606@oracle.com> <4DA815C7.2000500@oracle.com> <4DA8260C.6040606@gmx.de> <4DA836E7.8050200@oracle.com> <4DA83DFA.9050207@gmx.de> <4DA84B91.30607@oracle.com> <4DA973EA.6050705@oracle.com> <4DAC384F.8040008@gmx.de> Message-ID: <4DAC4015.6020304@oracle.com> Ulf Zibis wrote: > Am 16.04.2011 12:48, schrieb Alan Bateman: >> Michael McMahon wrote: >>> I have incorporated much of Ulf's approach into this version. >>> >>> I agree with Alan about the spec. We could find other variables in >>> the future that need >>> to be set, but can have alternative values other than the default. I >>> think this approach >>> is the most flexible. >>> >>> http://cr.openjdk.java.net/~michaelm/7034570/webrev.4/ >> This looks much better - thanks Ulf for the improved loop and >> changing it to use nameComparator. It will be good to get this one >> fixed. >> > > Thanks for the partial acceptance. > > I think, the comment in lines 295..297 more belongs to the code (lines > 312..315 + 318..320 ) rather than to the constant SYSTEMROOT. Why > defining it as class member, as it is only locally referred? > It makes no difference to the generated code. And imo, there is more space for the comment there. > I still don't see the advantage, having the SYSTEMROOT insertion code > at 2 call sites. One would be shorter and much clearer as shown in my > code. Then we too could save addToEnvIfSet(..) and the call to it. > Shorter doesn't always mean clearer. I think this way is clearer. > Additionally: Why instantiating, initializing and processing a fat > j.u.List object, if a simple array would fulfil all needs? > I don't see a compelling reason to change it from a List (which is what it was). I think any additional overhead is inconsequential in the context of creating an OS process. Or if it is, then we should be looking at our List implementations. > You have removed the 'Ensure double NUL termination' code. I guess, > you have approved, that String->CString already handles this, right? > Actually no. That shouldn't have been omitted. Thanks for finding that! - Michael. From neil.richards at ngmr.net Mon Apr 18 14:04:15 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Mon, 18 Apr 2011 15:04:15 +0100 Subject: Suspected regression: fix for 6735255 causes delay in GC of ZipFile InputStreams, increase in heap demand In-Reply-To: <1303130001.20081.95.camel@chalkhill> References: <1300916786.4515.107.camel@chalkhill> <4D922D68.2080202@oracle.com> <1301514810.24605.64.camel@chalkhill> <4D93930A.2000604@oracle.com> <1301676177.24605.165.camel@chalkhill> <4D962275.7010601@oracle.com> <4D965D14.6060504@oracle.com> <1301707718.14323.43.camel@chalkhill> <4D98FD10.4090608@oracle.com> <1302183023.27698.20.camel@chalkhill> <4D9E429F.9030200@oracle.com> <1302266193.17745.18.camel@chalkhill> <4D9FD836.1070909@oracle.com> <1302456482.18865.109.camel@chalkhill> <1302524116.15253.25.camel@chalkhill> <4DA4A8EF.4060103@oracle.com> <4DA5BEFA.30707@linux.vnet.ibm.com> <4DA5C052.6030500@linux.vnet.ibm.com> <4DA76BA8.6000109@oracle.com> <1303130001.20081.95.camel@chalkhill> Message-ID: <1303135455.29095.6.camel@chalkhill> On Mon, 2011-04-18 at 13:33 +0100, Neil Richards wrote: > I think it's worthwhile trying to clear 'streams' entries from a > finalize method in ZFIIS, to help ensure they are cleared in a timely > manner. In fact, it's probably clearer (more closely following the pattern elsewhere in the file) for ZFIIS.finalize() to call ZFIIS.close(). See changeset below with this additional tweak, Please let me know what you think on this, Thanks, Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU # HG changeset patch # User Neil Richards , # Date 1300289208 0 # Branch zip-heap # Node ID 9e0a3d49e4978264054cbacc9d3023715f1776d3 # Parent aa13e7702cd9d8aca9aa38f1227f966990866944 7031076: Retained ZipFile InputStreams increase heap demand Summary: Allow unreferenced ZipFile InputStreams to be finalized, GC'd Contributed-by: diff -r aa13e7702cd9 -r 9e0a3d49e497 src/share/classes/java/util/zip/ZipFile.java --- a/src/share/classes/java/util/zip/ZipFile.java Tue Mar 29 20:19:55 2011 -0700 +++ b/src/share/classes/java/util/zip/ZipFile.java Wed Mar 16 15:26:48 2011 +0000 @@ -31,11 +31,13 @@ import java.io.EOFException; import java.io.File; import java.nio.charset.Charset; -import java.util.Vector; +import java.util.ArrayDeque; +import java.util.Deque; import java.util.Enumeration; -import java.util.Set; -import java.util.HashSet; +import java.util.HashMap; +import java.util.Map; import java.util.NoSuchElementException; +import java.util.WeakHashMap; import java.security.AccessController; import sun.security.action.GetPropertyAction; import static java.util.zip.ZipConstants64.*; @@ -54,7 +56,7 @@ private long jzfile; // address of jzfile data private String name; // zip file name private int total; // total number of entries - private boolean closeRequested; + private volatile boolean closeRequested = false; private static final int STORED = ZipEntry.STORED; private static final int DEFLATED = ZipEntry.DEFLATED; @@ -314,8 +316,9 @@ // freeEntry releases the C jzentry struct. private static native void freeEntry(long jzfile, long jzentry); - // the outstanding inputstreams that need to be closed. - private Set streams = new HashSet<>(); + // the outstanding inputstreams that need to be closed, + // mapped to the inflater objects they use. + private final Map streams = new WeakHashMap<>(); /** * Returns an input stream for reading the contents of the specified @@ -351,51 +354,21 @@ switch (getEntryMethod(jzentry)) { case STORED: - streams.add(in); + synchronized (streams) { + streams.put(in, null); + } return in; case DEFLATED: - final ZipFileInputStream zfin = in; // MORE: Compute good size for inflater stream: long size = getEntrySize(jzentry) + 2; // Inflater likes a bit of slack if (size > 65536) size = 8192; if (size <= 0) size = 4096; - InputStream is = new InflaterInputStream(zfin, getInflater(), (int)size) { - private boolean isClosed = false; - - public void close() throws IOException { - if (!isClosed) { - super.close(); - releaseInflater(inf); - isClosed = true; - } - } - // Override fill() method to provide an extra "dummy" byte - // at the end of the input stream. This is required when - // using the "nowrap" Inflater option. - protected void fill() throws IOException { - if (eof) { - throw new EOFException( - "Unexpected end of ZLIB input stream"); - } - len = this.in.read(buf, 0, buf.length); - if (len == -1) { - buf[0] = 0; - len = 1; - eof = true; - } - inf.setInput(buf, 0, len); - } - private boolean eof; - - public int available() throws IOException { - if (isClosed) - return 0; - long avail = zfin.size() - inf.getBytesWritten(); - return avail > (long) Integer.MAX_VALUE ? - Integer.MAX_VALUE : (int) avail; - } - }; - streams.add(is); + Inflater inf = getInflater(); + InputStream is = + new ZipFileInflaterInputStream(in, inf, (int)size); + synchronized (streams) { + streams.put(is, inf); + } return is; default: throw new ZipException("invalid compression method"); @@ -403,36 +376,91 @@ } } + private class ZipFileInflaterInputStream extends InflaterInputStream { + private volatile boolean closeRequested = false; + private boolean eof = false; + private final ZipFileInputStream zfin; + + ZipFileInflaterInputStream(ZipFileInputStream zfin, Inflater inf, + int size) { + super(zfin, inf, size); + this.zfin = zfin; + } + + public void close() throws IOException { + if (closeRequested) + return; + closeRequested = true; + + super.close(); + Inflater inf; + synchronized (streams) { + inf = streams.remove(this); + } + if (inf != null) { + releaseInflater(inf); + } + } + + // Override fill() method to provide an extra "dummy" byte + // at the end of the input stream. This is required when + // using the "nowrap" Inflater option. + protected void fill() throws IOException { + if (eof) { + throw new EOFException("Unexpected end of ZLIB input stream"); + } + len = in.read(buf, 0, buf.length); + if (len == -1) { + buf[0] = 0; + len = 1; + eof = true; + } + inf.setInput(buf, 0, len); + } + + public int available() throws IOException { + if (closeRequested) + return 0; + long avail = zfin.size() - inf.getBytesWritten(); + return (avail > (long) Integer.MAX_VALUE ? + Integer.MAX_VALUE : (int) avail); + } + + protected void finalize() throws Throwable { + close(); + } + } + /* * Gets an inflater from the list of available inflaters or allocates * a new one. */ private Inflater getInflater() { - synchronized (inflaters) { - int size = inflaters.size(); - if (size > 0) { - Inflater inf = (Inflater)inflaters.remove(size - 1); - return inf; - } else { - return new Inflater(true); + Inflater inf; + synchronized (inflaterCache) { + while (null != (inf = inflaterCache.poll())) { + if (false == inf.ended()) { + return inf; + } } } + return new Inflater(true); } /* * Releases the specified inflater to the list of available inflaters. */ private void releaseInflater(Inflater inf) { - synchronized (inflaters) { - if (inf.ended()) - return; + if (false == inf.ended()) { inf.reset(); - inflaters.add(inf); + synchronized (inflaterCache) { + inflaterCache.add(inf); + } } } // List of available Inflater objects for decompression - private Vector inflaters = new Vector(); + private Deque inflaterCache = new ArrayDeque<>(); /** * Returns the path name of the ZIP file. @@ -540,14 +568,32 @@ * @throws IOException if an I/O error has occurred */ public void close() throws IOException { + if (closeRequested) + return; + closeRequested = true; + synchronized (this) { - closeRequested = true; + // Close streams, release their inflaters + synchronized (streams) { + if (false == streams.isEmpty()) { + Map copy = new HashMap<>(streams); + streams.clear(); + for (Map.Entry e : copy.entrySet()) { + e.getKey().close(); + Inflater inf = e.getValue(); + if (inf != null) { + inf.end(); + } + } + } + } - if (streams.size() !=0) { - Set copy = streams; - streams = new HashSet<>(); - for (InputStream is: copy) - is.close(); + // Release cached inflaters + Inflater inf; + synchronized (inflaterCache) { + while (null != (inf = inflaterCache.poll())) { + inf.end(); + } } if (jzfile != 0) { @@ -556,23 +602,13 @@ jzfile = 0; close(zf); - - // Release inflaters - synchronized (inflaters) { - int size = inflaters.size(); - for (int i = 0; i < size; i++) { - Inflater inf = (Inflater)inflaters.get(i); - inf.end(); - } - } } } } - /** - * Ensures that the close method of this ZIP file is - * called when there are no more references to it. + * Ensures that the system resources held by this ZipFile object are + * released when there are no more references to it. * *

* Since the time when GC would invoke this method is undetermined, @@ -611,6 +647,7 @@ * (possibly compressed) zip file entry. */ private class ZipFileInputStream extends InputStream { + private volatile boolean closeRequested = false; protected long jzentry; // address of jzentry data private long pos; // current position within entry data protected long rem; // number of remaining bytes within entry @@ -678,15 +715,25 @@ } public void close() { + if (closeRequested) + return; + closeRequested = true; + rem = 0; synchronized (ZipFile.this) { if (jzentry != 0 && ZipFile.this.jzfile != 0) { freeEntry(ZipFile.this.jzfile, jzentry); jzentry = 0; } + } + synchronized (streams) { streams.remove(this); } } + + protected void finalize() { + close(); + } } diff -r aa13e7702cd9 -r 9e0a3d49e497 test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java Wed Mar 16 15:26:48 2011 +0000 @@ -0,0 +1,148 @@ +/* + * Copyright (c) 2011 Oracle and/or its affiliates. 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 Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/* + * Portions Copyright (c) 2011 IBM Corporation + */ + +/* + * @test + * @bug 7031076 + * @summary Allow stale InputStreams from ZipFiles to be GC'd + * @author Neil Richards , + */ +import java.lang.ref.ReferenceQueue; +import java.lang.ref.WeakReference; +import java.io.File; +import java.io.FileOutputStream; +import java.io.InputStream; +import java.util.Enumeration; +import java.util.HashSet; +import java.util.Random; +import java.util.Set; +import java.util.zip.ZipEntry; +import java.util.zip.ZipFile; +import java.util.zip.ZipOutputStream; + +public class ClearStaleZipFileInputStreams { + private static final int ZIP_ENTRY_NUM = 5; + + private static final byte[][] data; + + static { + data = new byte[ZIP_ENTRY_NUM][]; + Random r = new Random(); + for (int i = 0; i < ZIP_ENTRY_NUM; i++) { + data[i] = new byte[1000]; + r.nextBytes(data[i]); + } + } + + private static File createTestFile(int compression) throws Exception { + File tempZipFile = + File.createTempFile("test-data" + compression, ".zip"); + tempZipFile.deleteOnExit(); + + ZipOutputStream zos = + new ZipOutputStream(new FileOutputStream(tempZipFile)); + zos.setLevel(compression); + + try { + for (int i = 0; i < ZIP_ENTRY_NUM; i++) { + String text = "Entry" + i; + ZipEntry entry = new ZipEntry(text); + zos.putNextEntry(entry); + try { + zos.write(data[i], 0, data[i].length); + } finally { + zos.closeEntry(); + } + } + } finally { + zos.close(); + } + + return tempZipFile; + } + + private static void startGcInducingThread(final int sleepMillis) { + final Thread gcInducingThread = new Thread() { + public void run() { + while (true) { + System.gc(); + try { + Thread.sleep(sleepMillis); + } catch (InterruptedException e) { } + } + } + }; + + gcInducingThread.setDaemon(true); + gcInducingThread.start(); + } + + public static void main(String[] args) throws Exception { + startGcInducingThread(500); + runTest(ZipOutputStream.DEFLATED); + runTest(ZipOutputStream.STORED); + } + + private static void runTest(int compression) throws Exception { + ReferenceQueue rq = new ReferenceQueue<>(); + + System.out.println("Testing with a zip file with compression level = " + + compression); + File f = createTestFile(compression); + try { + ZipFile zf = new ZipFile(f); + try { + Set refSet = createTransientInputStreams(zf, rq); + + System.out.println("Waiting for 'stale' input streams from ZipFile to be GC'd ..."); + System.out.println("(The test will hang on failure)"); + while (false == refSet.isEmpty()) { + refSet.remove(rq.remove()); + } + System.out.println("Test PASSED."); + System.out.println(); + } finally { + zf.close(); + } + } finally { + f.delete(); + } + } + + private static Set createTransientInputStreams(ZipFile zf, + ReferenceQueue rq) throws Exception { + Enumeration zfe = zf.entries(); + Set refSet = new HashSet<>(); + + while (zfe.hasMoreElements()) { + InputStream is = zf.getInputStream(zfe.nextElement()); + refSet.add(new WeakReference(is, rq)); + } + + return refSet; + } +} From Ulf.Zibis at gmx.de Mon Apr 18 14:14:18 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 18 Apr 2011 16:14:18 +0200 Subject: Review request for 7034570 - java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited In-Reply-To: <4DA84B91.30607@oracle.com> References: <4DA58A18.8080004@oracle.com> <4DA5B125.7030707@gmx.de> <4DA5CD33.50609@oracle.com> <4DA6FF50.7010308@oracle.com> <4DA75F4D.60809@gmx.de> <4DA813A5.5070606@oracle.com> <4DA815C7.2000500@oracle.com> <4DA8260C.6040606@gmx.de> <4DA836E7.8050200@oracle.com> <4DA83DFA.9050207@gmx.de> <4DA84B91.30607@oracle.com> Message-ID: <4DAC473A.5060901@gmx.de> Am 15.04.2011 15:43, schrieb Michael McMahon: > > I have incorporated much of Ulf's approach into this version. > > I agree with Alan about the spec. We could find other variables in the future that need > to be set, but can have alternative values other than the default. I think this approach > is the most flexible. > > http://cr.openjdk.java.net/~michaelm/7034570/webrev.4/ > The comment is not correct: 288 // Only for use by Runtime.exec(...String[]envp...) 289 static Map emptyEnvironment(int capacity) { It should be: 288 // Only for use by ProcessBuilder.environment(String[] envp) -Ulf From chris.hegarty at oracle.com Mon Apr 18 14:51:02 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 18 Apr 2011 14:51:02 +0000 Subject: hg: jdk7/tl/jdk: 7037436: CR 7035020 fails to check shutdown Message-ID: <20110418145112.54B7947BC9@hg.openjdk.java.net> Changeset: 603e70836e74 Author: dl Date: 2011-04-18 15:50 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/603e70836e74 7037436: CR 7035020 fails to check shutdown Reviewed-by: chegar ! src/share/classes/java/util/concurrent/ForkJoinPool.java ! src/share/classes/java/util/concurrent/ForkJoinWorkerThread.java From chris.hegarty at oracle.com Mon Apr 18 15:11:37 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 18 Apr 2011 15:11:37 +0000 Subject: hg: jdk7/tl/jdk: 7036559: ConcurrentHashMap footprint and contention improvements Message-ID: <20110418151146.DE37047BCB@hg.openjdk.java.net> Changeset: 005c0c85b0de Author: dl Date: 2011-04-18 16:10 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/005c0c85b0de 7036559: ConcurrentHashMap footprint and contention improvements Reviewed-by: chegar ! src/share/classes/java/util/concurrent/ConcurrentHashMap.java From lance.andersen at oracle.com Mon Apr 18 16:00:44 2011 From: lance.andersen at oracle.com (Lance Andersen - Oracle) Date: Mon, 18 Apr 2011 12:00:44 -0400 Subject: Review needed for 7037085 : Add hashCode() to Timestamp to address Findbugs warning In-Reply-To: <4DAC13C2.8040305@oracle.com> References: <4DA89E7F.9070903@oracle.com> <4DAC13C2.8040305@oracle.com> Message-ID: Thank you Eamonn. I fixed the typo in the class description as well so they both reference hashCode Regards Lance On Apr 18, 2011, at 6:34 AM, Eamonn McManus wrote: > OK, in that case you can add me (emcmanus) as a reviewer. I'd just suggest fixing the case of {@code hashcode} in the doc comment. > ?amonn > > On 15/4/11 9:45 PM, Lance Andersen - Oracle wrote: >> >> Hi Eamonn >> >> The javadocs for Timestamp have always specifically called the following blurb out in the class description. Based on some side discussions, it was best to also copy this blurb to the added hashCode method (you will see the text at the top of Timestamp) for additional clarity. >> >> Regards >> Lance >> On Apr 15, 2011, at 3:37 PM, Eamonn McManus wrote: >> >>> This isn't wrong, but wouldn't it be simpler to just add or xor the nanos field into the hashcode, rather than explicitly saying that you don't? >>> ?amonn >>> >>> On 15/4/11 8:54 PM, Lance Andersen - Oracle wrote: >>>> >>>> Hi all, >>>> >>>> Need a reviewer for the following minor change which adds hasCode() to Timestamp to address a Findbugs warning. >>>> >>>> Regards >>>> Lance >>>> >>>> >>>> hg diff >>>> diff -r d9248245a88c src/share/classes/java/sql/Timestamp.java >>>> --- a/src/share/classes/java/sql/Timestamp.java Wed Apr 13 11:21:36 2011 -0400 >>>> +++ b/src/share/classes/java/sql/Timestamp.java Fri Apr 15 14:34:07 2011 -0400 >>>> @@ -1,5 +1,5 @@ >>>> /* >>>> - * Copyright (c) 1996, 2010, Oracle and/or its affiliates. All rights reserved. >>>> + * Copyright (c) 1996, 2011, Oracle and/or its affiliates. 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 >>>> @@ -515,6 +515,18 @@ >>>> } >>>> } >>>> >>>> + /** >>>> + * {@inheritDoc} >>>> + * >>>> + * The {@code hashcode} method uses the underlying {@code java.util.Date} >>>> + * implementation and therefore does not include nanos in its computation. >>>> + * >>>> + */ >>>> + @Override >>>> + public int hashCode() { >>>> + return super.hashCode(); >>>> + } >>>> + >>>> static final long serialVersionUID = 2745179027874758501L; >>>> >>>> } >>>> >>>> >>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>> Oracle Java Engineering >>>> 1 Network Drive >>>> Burlington, MA 01803 >>>> Lance.Andersen at oracle.com >>>> >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From lance.andersen at oracle.com Mon Apr 18 16:08:20 2011 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Mon, 18 Apr 2011 16:08:20 +0000 Subject: hg: jdk7/tl/jdk: 7037085: Add hashCode() to Timestamp to address Findbugs warning Message-ID: <20110418160830.0121347BCF@hg.openjdk.java.net> Changeset: 9b3e6baad033 Author: lancea Date: 2011-04-18 12:07 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9b3e6baad033 7037085: Add hashCode() to Timestamp to address Findbugs warning Reviewed-by: darcy, alanb, emcmanus ! src/share/classes/java/sql/Timestamp.java From xueming.shen at oracle.com Mon Apr 18 16:49:00 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 18 Apr 2011 09:49:00 -0700 Subject: Suspected regression: fix for 6735255 causes delay in GC of ZipFile InputStreams, increase in heap demand In-Reply-To: <1303130001.20081.95.camel@chalkhill> References: <1300916786.4515.107.camel@chalkhill> <4D922D68.2080202@oracle.com> <1301514810.24605.64.camel@chalkhill> <4D93930A.2000604@oracle.com> <1301676177.24605.165.camel@chalkhill> <4D962275.7010601@oracle.com> <4D965D14.6060504@oracle.com> <1301707718.14323.43.camel@chalkhill> <4D98FD10.4090608@oracle.com> <1302183023.27698.20.camel@chalkhill> <4D9E429F.9030200@oracle.com> <1302266193.17745.18.camel@chalkhill> <4D9FD836.1070909@oracle.com> <1302456482.18865.109.camel@chalkhill> <1302524116.15253.25.camel@chalkhill> <4DA4A8EF.4060103@oracle.com> <4DA5BEFA.30707@linux.vnet.ibm.com> <4DA5C052.6030500@linux.vnet.ibm.com> <4DA76BA8.6000109@oracle.com> <1303130001.20081.95.camel@chalkhill> Message-ID: <4DAC6B7C.30406@oracle.com> On 4/18/2011 5:33 AM, Neil Richards wrote: > On Thu, 2011-04-14 at 14:48 -0700, Xueming Shen wrote: >> Opinion? anything I overlooked/missed? > Hi Sherman, > Thanks once more for all your help and advice on this - I'm in favour of > almost all of what you suggest. :-) > > I think it's worthwhile trying to clear 'streams' entries from a > finalize method in ZFIIS, to help ensure they are cleared in a timely > manner. > > I don't think the Inflater objects need to be held softly in > 'inflaterCache', as they will have been reset() at the point they are > put into that cache (in releaseInflater()). > > (I was holding them softly due to a worry over any delay in clearing > their 'buf' reference, which is done when reset() is called. Now that > the 'streams' entries are being cleared from close() and finalize() - > ie. up front - I think this worry is adequately addressed.) > > > I'm worried about changing the object 'streams' refers to in > ZipFile.close(), as threads are using that object to synchronize > against. > I don't believe it is currently giving the guarantee against > ConcurrentModificationException being seen from the iterator that I > believe you intend it to be, as other threads, calling (for example) > ZFIIS.close() at the same time will not be guaranteed to see the update > to the value of 'streams'. > > Instead, I've modified this code so that a real copy of 'streams' is > produced, by calling 'new HashMap<>(streams)'. It is this copy that is > iterated through to close() the InputStreams and end() the Inflaters. > Once the copy is obtained, 'streams' can be safely clear()'d. > > Because it is not clear that a Collections.synchronizedMap will give > consistent results when fed into the constructor of HashMap, I've used > explicit synchronization on 'streams' instead, to ensure 'streams' isn't > modified during the construction of 'copy'. > As each of the calls to InputStream.close() will synchronize on > 'streams' to call its remove() method, I've held that monitor whilst > those calls are made. (resent, got some mail issue) Hi Neil, If you are now explicitly synchronize on "streams" everywhere, I don't think we even need a copy at close(). To add "close() in ZFIIS.finalize() appears to be safe now (?, maybe I should think it again), but given we are now using WeakHashMap, those weak reference will get expunged every time that map gets accessed, I doubt that really help lots (have to wait for the GC kicks in anyway, if not closed explicitly) I'm running tests now, with the "copy" mentioned above. -Sherman > > Other minor tweaks are changing 'isClosed' fields to > 'closeRequested' (to better describe their use now), changing > 'ZipFile.closeRequested' to be volatile (so it can be checked before > synchronization, and so that it conforms to the pattern now established > elsewhere in the file), and reducing the synchronization block in > releaseInflater() (only the call to 'inflateCache.add()' need be > protected by synchronization on 'inflaterCache'). > > Please find below the resultant changeset, > Let me know what you think, > Thanks, > Neil > From xueming.shen at oracle.com Mon Apr 18 17:32:56 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 18 Apr 2011 10:32:56 -0700 Subject: Suspected regression: fix for 6735255 causes delay in GC of ZipFile InputStreams, increase in heap demand In-Reply-To: <4DAC6B7C.30406@oracle.com> References: <1300916786.4515.107.camel@chalkhill> <4D922D68.2080202@oracle.com> <1301514810.24605.64.camel@chalkhill> <4D93930A.2000604@oracle.com> <1301676177.24605.165.camel@chalkhill> <4D962275.7010601@oracle.com> <4D965D14.6060504@oracle.com> <1301707718.14323.43.camel@chalkhill> <4D98FD10.4090608@oracle.com> <1302183023.27698.20.camel@chalkhill> <4D9E429F.9030200@oracle.com> <1302266193.17745.18.camel@chalkhill> <4D9FD836.1070909@oracle.com> <1302456482.18865.109.camel@chalkhill> <1302524116.15253.25.camel@chalkhill> <4DA4A8EF.4060103@oracle.com> <4DA5BEFA.30707@linux.vnet.ibm.com> <4DA5C052.6030500@linux.vnet.ibm.com> <4DA76BA8.6000109@oracle.com> <1303130001.20081.95.camel@chalkhill> <4DAC6B7C.30406@oracle.com> Message-ID: <4DAC75C8.2090700@oracle.com> Hi Neil, All tests passed. I'm starting to push your last patch. I generated the webrev at http://cr.openjdk.java.net/~sherman/7031076/webrev/ It should be exactly the same as your last patch. Thanks, Sherman On 4/18/2011 9:49 AM, Xueming Shen wrote: > On 4/18/2011 5:33 AM, Neil Richards wrote: >> On Thu, 2011-04-14 at 14:48 -0700, Xueming Shen wrote: >>> Opinion? anything I overlooked/missed? >> Hi Sherman, >> Thanks once more for all your help and advice on this - I'm in favour of >> almost all of what you suggest. :-) >> >> I think it's worthwhile trying to clear 'streams' entries from a >> finalize method in ZFIIS, to help ensure they are cleared in a timely >> manner. >> >> I don't think the Inflater objects need to be held softly in >> 'inflaterCache', as they will have been reset() at the point they are >> put into that cache (in releaseInflater()). >> >> (I was holding them softly due to a worry over any delay in clearing >> their 'buf' reference, which is done when reset() is called. Now that >> the 'streams' entries are being cleared from close() and finalize() - >> ie. up front - I think this worry is adequately addressed.) >> >> >> I'm worried about changing the object 'streams' refers to in >> ZipFile.close(), as threads are using that object to synchronize >> against. >> I don't believe it is currently giving the guarantee against >> ConcurrentModificationException being seen from the iterator that I >> believe you intend it to be, as other threads, calling (for example) >> ZFIIS.close() at the same time will not be guaranteed to see the update >> to the value of 'streams'. >> >> Instead, I've modified this code so that a real copy of 'streams' is >> produced, by calling 'new HashMap<>(streams)'. It is this copy that is >> iterated through to close() the InputStreams and end() the Inflaters. >> Once the copy is obtained, 'streams' can be safely clear()'d. >> >> Because it is not clear that a Collections.synchronizedMap will give >> consistent results when fed into the constructor of HashMap, I've used >> explicit synchronization on 'streams' instead, to ensure 'streams' isn't >> modified during the construction of 'copy'. >> As each of the calls to InputStream.close() will synchronize on >> 'streams' to call its remove() method, I've held that monitor whilst >> those calls are made. > > (resent, got some mail issue) > > Hi Neil, > > If you are now explicitly synchronize on "streams" everywhere, I don't > think we even need a copy > at close(). > > To add "close() in ZFIIS.finalize() appears to be safe now (?, maybe I > should think it again), but > given we are now using WeakHashMap, those weak reference will get > expunged every time that > map gets accessed, I doubt that really help lots (have to wait for the > GC kicks in anyway, if not > closed explicitly) > > I'm running tests now, with the "copy" mentioned above. > > -Sherman > > >> >> Other minor tweaks are changing 'isClosed' fields to >> 'closeRequested' (to better describe their use now), changing >> 'ZipFile.closeRequested' to be volatile (so it can be checked before >> synchronization, and so that it conforms to the pattern now established >> elsewhere in the file), and reducing the synchronization block in >> releaseInflater() (only the call to 'inflateCache.add()' need be >> protected by synchronization on 'inflaterCache'). >> >> Please find below the resultant changeset, >> Let me know what you think, >> Thanks, >> Neil >> > From Ulf.Zibis at gmx.de Mon Apr 18 17:40:21 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 18 Apr 2011 19:40:21 +0200 Subject: Review request for 7034570 - java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited In-Reply-To: <4DA84B91.30607@oracle.com> References: <4DA58A18.8080004@oracle.com> <4DA5B125.7030707@gmx.de> <4DA5CD33.50609@oracle.com> <4DA6FF50.7010308@oracle.com> <4DA75F4D.60809@gmx.de> <4DA813A5.5070606@oracle.com> <4DA815C7.2000500@oracle.com> <4DA8260C.6040606@gmx.de> <4DA836E7.8050200@oracle.com> <4DA83DFA.9050207@gmx.de> <4DA84B91.30607@oracle.com> Message-ID: <4DAC7785.70707@gmx.de> Am 15.04.2011 15:43, schrieb Michael McMahon: > > I have incorporated much of Ulf's approach into this version. > > I agree with Alan about the spec. We could find other variables in the future that need > to be set, but can have alternative values other than the default. I think this approach > is the most flexible. > > http://cr.openjdk.java.net/~michaelm/7034570/webrev.4/ > Additionally I see another problem: Because the ProcessEnvironment.nameComparator is static, creating a new Process will not be thread-safe! -Ulf From xueming.shen at oracle.com Mon Apr 18 17:45:31 2011 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Mon, 18 Apr 2011 17:45:31 +0000 Subject: hg: jdk7/tl/jdk: 7031076: Retained ZipFile InputStreams increase heap demand Message-ID: <20110418174542.0EBDE47BD4@hg.openjdk.java.net> Changeset: 98688c4be64b Author: sherman Date: 2011-04-18 10:51 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/98688c4be64b 7031076: Retained ZipFile InputStreams increase heap demand Summary: Allow unreferenced ZipFile InputStreams to be finalized, GC'd Reviewed-by: sherman, dholmes Contributed-by: neil.richards at ngmr.net ! src/share/classes/java/util/zip/ZipFile.java + test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java From neil.richards at ngmr.net Mon Apr 18 17:59:51 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Mon, 18 Apr 2011 18:59:51 +0100 Subject: Suspected regression: fix for 6735255 causes delay in GC of ZipFile InputStreams, increase in heap demand In-Reply-To: <4DAC6B7C.30406@oracle.com> References: <1300916786.4515.107.camel@chalkhill> <4D922D68.2080202@oracle.com> <1301514810.24605.64.camel@chalkhill> <4D93930A.2000604@oracle.com> <1301676177.24605.165.camel@chalkhill> <4D962275.7010601@oracle.com> <4D965D14.6060504@oracle.com> <1301707718.14323.43.camel@chalkhill> <4D98FD10.4090608@oracle.com> <1302183023.27698.20.camel@chalkhill> <4D9E429F.9030200@oracle.com> <1302266193.17745.18.camel@chalkhill> <4D9FD836.1070909@oracle.com> <1302456482.18865.109.camel@chalkhill> <1302524116.15253.25.camel@chalkhill> <4DA4A8EF.4060103@oracle.com> <4DA5BEFA.30707@linux.vnet.ibm.com> <4DA5C052.6030500@linux.vnet.ibm.com> <4DA76BA8.6000109@oracle.com> <1303130001.20081.95.camel@chalkhill> <4DAC6B7C.30406@oracle.com> Message-ID: On 18 April 2011 17:49, Xueming Shen wrote: > If you are now explicitly synchronize on "streams" everywhere, I don't think > we even need a copy > at close(). I thought that the copy is needed so that the Map being iterated over (in close()) is not able to be modified by the same thread via the calls to InputStream.close() that it makes (which will try to call streams.remove()), and hence avoid the risk of getting ConcurrentModificationExceptions being thrown. Are you sure that it is safe to avoid doing this copy ? > To add "close() in ZFIIS.finalize() appears to be safe now (?, maybe I > should think it again), but > given we are now using WeakHashMap, those weak reference will get expunged > every time that > map gets accessed, I doubt that really help lots (have to wait for the GC > kicks in anyway, if not > closed explicitly) As I recall, WeakHashMap only looks to expunge stale entries when one of its methods is called. Therefore, causing it to be accessed (indirectly) from the finalize() methods (by calling close()) helps to ensure that stale entries (with the retained inflater's associated system resources) are not retained for longer than needed. This is true even if the particular access is unlikely to retrieve a "live" entry. Hope this provides some clarification to the suggested changeset, Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From mike.duigou at oracle.com Mon Apr 18 17:59:58 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 18 Apr 2011 10:59:58 -0700 Subject: Review Request : 7035160 : Disable broken test cases Message-ID: <79844FAA-7D58-4E37-BCB1-D411ECCE5C71@oracle.com> Hello All; I would like a quick review for a small patch which disables certain test cases for test/java/lang/reflect/Generics/Probe.java This test is failing due to recent changes from CR # 6312706. The root cause is another issue, CR # 6476261, which currently has no fix available. The stopgap "solution" is to partially disable the test which is what this patch does. http://cr.openjdk.java.net/~mduigou/7035160/0/webrev/ Thanks, Mike From neil.richards at ngmr.net Mon Apr 18 18:11:56 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Mon, 18 Apr 2011 19:11:56 +0100 Subject: Suspected regression: fix for 6735255 causes delay in GC of ZipFile InputStreams, increase in heap demand In-Reply-To: <4DAC75C8.2090700@oracle.com> References: <1300916786.4515.107.camel@chalkhill> <4D922D68.2080202@oracle.com> <1301514810.24605.64.camel@chalkhill> <4D93930A.2000604@oracle.com> <1301676177.24605.165.camel@chalkhill> <4D962275.7010601@oracle.com> <4D965D14.6060504@oracle.com> <1301707718.14323.43.camel@chalkhill> <4D98FD10.4090608@oracle.com> <1302183023.27698.20.camel@chalkhill> <4D9E429F.9030200@oracle.com> <1302266193.17745.18.camel@chalkhill> <4D9FD836.1070909@oracle.com> <1302456482.18865.109.camel@chalkhill> <1302524116.15253.25.camel@chalkhill> <4DA4A8EF.4060103@oracle.com> <4DA5BEFA.30707@linux.vnet.ibm.com> <4DA5C052.6030500@linux.vnet.ibm.com> <4DA76BA8.6000109@oracle.com> <1303130001.20081.95.camel@chalkhill> <4DAC6B7C.30406@oracle.com> <4DAC75C8.2090700@oracle.com> Message-ID: On 18 April 2011 18:32, Xueming Shen wrote: > ?Hi Neil, > > All tests passed. > > I'm starting to push your last patch. I generated the webrev at > > http://cr.openjdk.java.net/~sherman/7031076/webrev/ > > It should be exactly the same as your last patch. > > Thanks, > Sherman Hi Sherman, Thanks for all your advice and help in reaching (and committing) a resolution for this issue - it really is much appreciated, Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From schlosna at gmail.com Mon Apr 18 18:16:43 2011 From: schlosna at gmail.com (David Schlosnagle) Date: Mon, 18 Apr 2011 14:16:43 -0400 Subject: Review request for 7034570 - java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited In-Reply-To: <4DAC7785.70707@gmx.de> References: <4DA58A18.8080004@oracle.com> <4DA5B125.7030707@gmx.de> <4DA5CD33.50609@oracle.com> <4DA6FF50.7010308@oracle.com> <4DA75F4D.60809@gmx.de> <4DA813A5.5070606@oracle.com> <4DA815C7.2000500@oracle.com> <4DA8260C.6040606@gmx.de> <4DA836E7.8050200@oracle.com> <4DA83DFA.9050207@gmx.de> <4DA84B91.30607@oracle.com> <4DAC7785.70707@gmx.de> Message-ID: On Mon, Apr 18, 2011 at 1:40 PM, Ulf Zibis wrote: > Am 15.04.2011 15:43, schrieb Michael McMahon: >> >> I have incorporated much of Ulf's approach into this version. >> >> I agree with Alan about the spec. We could find other variables in the >> future that need >> to be set, but can have alternative values other than the default. I think >> this approach >> is the most flexible. >> >> http://cr.openjdk.java.net/~michaelm/7034570/webrev.4/ >> > > Additionally I see another problem: > > Because the ProcessEnvironment.nameComparator is static, creating a new > Process will not be thread-safe! Ulf, I don't see a problem here. The ProcessEnvironment.nameComparator is a static final field that is initialized to `new NameComparator()` in a static initialization block for the ProcessEnvironment class. The NameComparator has no instance state, and can be safely shared by multiple threads. >From http://cr.openjdk.java.net/~michaelm/7034570/webrev.4/src/windows/classes/java/lang/ProcessEnvironment.java.html: 191 private static final class NameComparator 192 implements Comparator { 193 public int compare(String s1, String s2) { 194 // We can't use String.compareToIgnoreCase since it 195 // canonicalizes to lower case, while Windows 196 // canonicalizes to upper case! For example, "_" should 197 // sort *after* "Z", not before. 198 int n1 = s1.length(); 199 int n2 = s2.length(); 200 int min = Math.min(n1, n2); 201 for (int i = 0; i < min; i++) { 202 char c1 = s1.charAt(i); 203 char c2 = s2.charAt(i); 204 if (c1 != c2) { 205 c1 = Character.toUpperCase(c1); 206 c2 = Character.toUpperCase(c2); 207 if (c1 != c2) 208 // No overflow because of numeric promotion 209 return c1 - c2; 210 } 211 } 212 return n1 - n2; 213 } 214 } ... 227 private static final NameComparator nameComparator; ... 233 static { 234 nameComparator = new NameComparator(); ... - Dave From Alan.Bateman at oracle.com Mon Apr 18 18:26:17 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 18 Apr 2011 19:26:17 +0100 Subject: Review Request : 7035160 : Disable broken test cases In-Reply-To: <79844FAA-7D58-4E37-BCB1-D411ECCE5C71@oracle.com> References: <79844FAA-7D58-4E37-BCB1-D411ECCE5C71@oracle.com> Message-ID: <4DAC8249.9040203@oracle.com> Mike Duigou wrote: > Hello All; > > I would like a quick review for a small patch which disables certain test cases for test/java/lang/reflect/Generics/Probe.java This test is failing due to recent changes from CR # 6312706. The root cause is another issue, CR # 6476261, which currently has no fix available. The stopgap "solution" is to partially disable the test which is what this patch does. > > http://cr.openjdk.java.net/~mduigou/7035160/0/webrev/ > > Thanks, > > Mike It's definitely too risky to be looking at the signature parser this late in 7 so I agree that disabling this part of the test is the best for now. -Alan. From mike.duigou at oracle.com Mon Apr 18 18:32:52 2011 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Mon, 18 Apr 2011 18:32:52 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20110418183312.434F447BD6@hg.openjdk.java.net> Changeset: 60a457a944c4 Author: mduigou Date: 2011-04-18 11:31 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/60a457a944c4 7035160: Disable broken test cases for test/java/lang/reflect/Generics/Probe.java Reviewed-by: alanb ! test/java/lang/reflect/Generics/Probe.java Changeset: b38b204748c1 Author: mduigou Date: 2011-04-18 11:32 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b38b204748c1 Merge From Ulf.Zibis at gmx.de Mon Apr 18 19:26:56 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 18 Apr 2011 21:26:56 +0200 Subject: Review request for 7034570 - java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited In-Reply-To: <4DAC4015.6020304@oracle.com> References: <4DA58A18.8080004@oracle.com> <4DA5B125.7030707@gmx.de> <4DA5CD33.50609@oracle.com> <4DA6FF50.7010308@oracle.com> <4DA75F4D.60809@gmx.de> <4DA813A5.5070606@oracle.com> <4DA815C7.2000500@oracle.com> <4DA8260C.6040606@gmx.de> <4DA836E7.8050200@oracle.com> <4DA83DFA.9050207@gmx.de> <4DA84B91.30607@oracle.com> <4DA973EA.6050705@oracle.com> <4DAC384F.8040008@gmx.de> <4DAC4015.6020304@oracle.com> Message-ID: <4DAC9080.3060702@gmx.de> Am 18.04.2011 15:43, schrieb Michael McMahon: > Ulf Zibis wrote: >> I think, the comment in lines 295..297 more belongs to the code (lines 312..315 + 318..320 ) >> rather than to the constant SYSTEMROOT. Why defining it as class member, as it is only locally >> referred? >> > It makes no difference to the generated code. And imo, there is more space for the comment there. Hm, can't share that reason. But anyway, the comment would be little closer to the code, if the constant would at least be defined in the mothod's scope. >> I still don't see the advantage, having the SYSTEMROOT insertion code at 2 call sites. One would >> be shorter and much clearer as shown in my code. Then we too could save addToEnvIfSet(..) and the >> call to it. >> > Shorter doesn't always mean clearer. I think this way is clearer. Not always yes, but each code line has to be understood by the reader. The more lines to read, the more lines to understand, apart from the bigger memory and codebase footprint. Just my opinion. >> Additionally: Why instantiating, initializing and processing a fat j.u.List object, if a simple >> array would fulfil all needs? >> > I don't see a compelling reason to change it from a List (which is what it was). I think any > additional overhead > is inconsequential in the context of creating an OS process. I don't understand. The overhead is bigger while using a List than for a simple array. > Or if it is, then we should be looking at our List implementations. If there would be thousands of processes to create, I would agree. HotSpot would optimize to equivalent performance, but in real world, I guess, VM's interpreter has to deal with the more overloaded code from the List stuff. -Ulf From Ulf.Zibis at gmx.de Mon Apr 18 19:42:18 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 18 Apr 2011 21:42:18 +0200 Subject: Review request for 7034570 - java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited In-Reply-To: <4DA84B91.30607@oracle.com> References: <4DA58A18.8080004@oracle.com> <4DA5B125.7030707@gmx.de> <4DA5CD33.50609@oracle.com> <4DA6FF50.7010308@oracle.com> <4DA75F4D.60809@gmx.de> <4DA813A5.5070606@oracle.com> <4DA815C7.2000500@oracle.com> <4DA8260C.6040606@gmx.de> <4DA836E7.8050200@oracle.com> <4DA83DFA.9050207@gmx.de> <4DA84B91.30607@oracle.com> Message-ID: <4DAC941A.70200@gmx.de> Am 15.04.2011 15:43, schrieb Michael McMahon: > I have incorporated much of Ulf's approach into this version. > > I agree with Alan about the spec. We could find other variables in the future that need > to be set, but can have alternative values other than the default. I think this approach > is the most flexible. > > http://cr.openjdk.java.net/~michaelm/7034570/webrev.4/ > Alternatively we could insert the SystemRoot variable from the beginning in the ProcessEnvironment constructor. See my approach in the attachment, based on b84 sources and using TreeMap instead HashMap. IMO, looks much smarter. Please note, that my system is in a construction site state and not up to date. So I couldn't test the code. -Ulf From Ulf.Zibis at gmx.de Mon Apr 18 19:44:19 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 18 Apr 2011 21:44:19 +0200 Subject: Review request for 7034570 - java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited In-Reply-To: References: <4DA58A18.8080004@oracle.com> <4DA5B125.7030707@gmx.de> <4DA5CD33.50609@oracle.com> <4DA6FF50.7010308@oracle.com> <4DA75F4D.60809@gmx.de> <4DA813A5.5070606@oracle.com> <4DA815C7.2000500@oracle.com> <4DA8260C.6040606@gmx.de> <4DA836E7.8050200@oracle.com> <4DA83DFA.9050207@gmx.de> <4DA84B91.30607@oracle.com> <4DAC7785.70707@gmx.de> Message-ID: <4DAC9493.8080604@gmx.de> Oops, I was irritated by the internal int variables, but yes, they reside on stack, so no worry about thread-safety. -Ulf Am 18.04.2011 20:16, schrieb David Schlosnagle: > On Mon, Apr 18, 2011 at 1:40 PM, Ulf Zibis wrote: >> Am 15.04.2011 15:43, schrieb Michael McMahon: >>> I have incorporated much of Ulf's approach into this version. >>> >>> I agree with Alan about the spec. We could find other variables in the >>> future that need >>> to be set, but can have alternative values other than the default. I think >>> this approach >>> is the most flexible. >>> >>> http://cr.openjdk.java.net/~michaelm/7034570/webrev.4/ >>> >> Additionally I see another problem: >> >> Because the ProcessEnvironment.nameComparator is static, creating a new >> Process will not be thread-safe! > Ulf, > > I don't see a problem here. The ProcessEnvironment.nameComparator is a > static final field that is initialized to `new NameComparator()` in a > static initialization block for the ProcessEnvironment class. The > NameComparator has no instance state, and can be safely shared by > multiple threads. > > > From http://cr.openjdk.java.net/~michaelm/7034570/webrev.4/src/windows/classes/java/lang/ProcessEnvironment.java.html: > 191 private static final class NameComparator > 192 implements Comparator { > 193 public int compare(String s1, String s2) { > 194 // We can't use String.compareToIgnoreCase since it > 195 // canonicalizes to lower case, while Windows > 196 // canonicalizes to upper case! For example, "_" should > 197 // sort *after* "Z", not before. > 198 int n1 = s1.length(); > 199 int n2 = s2.length(); > 200 int min = Math.min(n1, n2); > 201 for (int i = 0; i< min; i++) { > 202 char c1 = s1.charAt(i); > 203 char c2 = s2.charAt(i); > 204 if (c1 != c2) { > 205 c1 = Character.toUpperCase(c1); > 206 c2 = Character.toUpperCase(c2); > 207 if (c1 != c2) > 208 // No overflow because of numeric promotion > 209 return c1 - c2; > 210 } > 211 } > 212 return n1 - n2; > 213 } > 214 } > ... > 227 private static final NameComparator nameComparator; > ... > 233 static { > 234 nameComparator = new NameComparator(); > ... > > - Dave > From mike.duigou at oracle.com Mon Apr 18 22:24:06 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 18 Apr 2011 15:24:06 -0700 Subject: Review (Updated) : 4884238 : Constants for Standard Charsets Message-ID: Hello All; I have updated the webrev for the standard Charset constants based upon feedback received from the earlier reviews. The constants class is now named StandardCharset rather than Charsets in mimicry of the class naming used by NIO.2 (JSR 203). According to the conventions used by JSR 203 and elsewhere in JDK a "Charsets" class would be for static utility methods rather than solely constants. The DEFAULT_CHARSET definition is also now removed. The Charset.getDefaultCharset() method makes it more clear that the value is not a constant across all all JVM instances. Also now included is a small unit test and replacement of several uses of Charset.forname() for standard charset names within the platform. The latest webrev : http://cr.openjdk.java.net/~mduigou/4884238/2/webrev/ Any other remaining feeback? Mike From bhavesh.patel at sun.com Mon Apr 18 22:41:38 2011 From: bhavesh.patel at sun.com (bhavesh.patel at sun.com) Date: Mon, 18 Apr 2011 22:41:38 +0000 Subject: hg: jdk7/tl/langtools: 6758050: javadoc handles nested generic types incorrectly Message-ID: <20110418224140.3794147BE0@hg.openjdk.java.net> Changeset: bbd053476ec3 Author: bpatel Date: 2011-04-18 15:39 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/bbd053476ec3 6758050: javadoc handles nested generic types incorrectly Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java + test/com/sun/javadoc/testNestedGenerics/TestNestedGenerics.java + test/com/sun/javadoc/testNestedGenerics/pkg/NestedGenerics.java From schlosna at gmail.com Mon Apr 18 23:13:10 2011 From: schlosna at gmail.com (David Schlosnagle) Date: Mon, 18 Apr 2011 19:13:10 -0400 Subject: Review (Updated) : 4884238 : Constants for Standard Charsets In-Reply-To: References: Message-ID: On Mon, Apr 18, 2011 at 6:24 PM, Mike Duigou wrote: > The latest webrev : http://cr.openjdk.java.net/~mduigou/4884238/2/webrev/ > > Any other remaining feeback? > Mike, You'll need to update the private constructor and AssertionError for StandardCharset as the existing private Charset() won't compile: 35 public final class StandardCharset { 36 37 private Charsets() { 38 throw new AssertionError("No java.nio.charset.Charsets instances for you!"); 39 } - Dave From mike.duigou at oracle.com Mon Apr 18 23:41:16 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 18 Apr 2011 16:41:16 -0700 Subject: Review (Updated) : 4884238 : Constants for Standard Charsets In-Reply-To: References: Message-ID: Oops, missed that one in my search-and-replace. I've updated the online webrev. Thanks! Mike On Apr 18 2011, at 16:13 , David Schlosnagle wrote: > On Mon, Apr 18, 2011 at 6:24 PM, Mike Duigou wrote: >> The latest webrev : http://cr.openjdk.java.net/~mduigou/4884238/2/webrev/ >> >> Any other remaining feeback? >> > > Mike, > > You'll need to update the private constructor and AssertionError for > StandardCharset as the existing private Charset() won't compile: > > 35 public final class StandardCharset { > 36 > 37 private Charsets() { > 38 throw new AssertionError("No java.nio.charset.Charsets > instances for you!"); > 39 } > > - Dave From mike.duigou at oracle.com Tue Apr 19 00:16:04 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 18 Apr 2011 17:16:04 -0700 Subject: Review : 7030579 : Correct confusing documentation in ListIterator.add() Message-ID: Hello All; A very simple patch to remove two instances of the unnecessary and potentially confusing word "next" from the documentation of ListIterator.add() http://cr.openjdk.java.net/~mduigou/7030579/0/webrev/ Mike From David.Holmes at oracle.com Tue Apr 19 01:34:06 2011 From: David.Holmes at oracle.com (David Holmes) Date: Tue, 19 Apr 2011 11:34:06 +1000 Subject: Review : 7030579 : Correct confusing documentation in ListIterator.add() In-Reply-To: References: Message-ID: <4DACE68E.7060007@oracle.com> Looks good to me Mike! Reads much clearer now. David Mike Duigou said the following on 04/19/11 10:16: > Hello All; > > A very simple patch to remove two instances of the unnecessary and potentially confusing word "next" from the documentation of ListIterator.add() > > http://cr.openjdk.java.net/~mduigou/7030579/0/webrev/ > > Mike From xueming.shen at oracle.com Tue Apr 19 04:37:41 2011 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Tue, 19 Apr 2011 04:37:41 +0000 Subject: hg: jdk7/tl/jdk: 7027900: (fs) glob syntax under-specified Message-ID: <20110419043750.91DB747BF0@hg.openjdk.java.net> Changeset: e9760efb5110 Author: sherman Date: 2011-04-18 21:44 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e9760efb5110 7027900: (fs) glob syntax under-specified Summary: Clarify how leading dots are treated in nio2 glob Reviewed-by: alanb ! src/share/classes/java/nio/file/FileSystem.java From Alan.Bateman at oracle.com Tue Apr 19 07:51:28 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 19 Apr 2011 08:51:28 +0100 Subject: Review : 7030579 : Correct confusing documentation in ListIterator.add() In-Reply-To: References: Message-ID: <4DAD3F00.60001@oracle.com> Mike Duigou wrote: > Hello All; > > A very simple patch to remove two instances of the unnecessary and potentially confusing word "next" from the documentation of ListIterator.add() > > http://cr.openjdk.java.net/~mduigou/7030579/0/webrev/ > > Mike I agree with David, much clearer now. -Alan. From Alan.Bateman at oracle.com Tue Apr 19 08:14:33 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 19 Apr 2011 09:14:33 +0100 Subject: Review (Updated) : 4884238 : Constants for Standard Charsets In-Reply-To: References: Message-ID: <4DAD4469.80506@oracle.com> Mike Duigou wrote: > : > > The latest webrev : http://cr.openjdk.java.net/~mduigou/4884238/2/webrev/ > > Any other remaining feeback? > > Mike Given that it now only defines the constants for the standard charsets then I think the new name is better, although with static import then it might not matter too much. I'm not sure whether we should use this in the zip code as we don't want this to causes the lesser used charsets to be loaded. It might be worth double checking the startup. The test claims to have been brewed in 2010. The "infrastructure" pasted in at the end is another reminder that we should have had a standard Assert/equivalent class in the test suite. -Alan From Ulf.Zibis at gmx.de Tue Apr 19 11:52:02 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 19 Apr 2011 13:52:02 +0200 Subject: Review (Updated) : 4884238 : Constants for Standard Charsets In-Reply-To: References: Message-ID: <4DAD7762.4000707@gmx.de> Am 19.04.2011 00:24, schrieb Mike Duigou: > Hello All; > > I have updated the webrev for the standard Charset constants based upon feedback received from the earlier reviews. The constants class is now named StandardCharset rather than Charsets in mimicry of the class naming used by NIO.2 (JSR 203). According to the conventions used by JSR 203 and elsewhere in JDK a "Charsets" class would be for static utility methods rather than solely constants. > > The DEFAULT_CHARSET definition is also now removed. The Charset.getDefaultCharset() method makes it more clear that the value is not a constant across all all JVM instances. > > Also now included is a small unit test and replacement of several uses of Charset.forname() for standard charset names within the platform. > > The latest webrev : http://cr.openjdk.java.net/~mduigou/4884238/2/webrev/ > > Any other remaining feeback? > Reading 'StandardCharset' one expects _the_ standard charset, but we have a collection of 6 here, so I'm for 'StandardCharsets' similar to e.g. j.u.z.ZipConstants, j.u.z.ZipConstants64, ... I'm still against this additional class and vote for adding these constants to existing Charset. We also don't have things like StandardDouble(s).NaN. Your rationale is to avoid 6 charset classes to be loaded (which I still think is nothing against the initialization of the existing Charset class) on very early state when instantiation of IN, OUT, ERR forces Charset class to load for the lookup of the default charset. I think, we should *catch the problem at the source*. The source is, that the given sun.nio.cs charset providers supply one distinct class for each charset, which is completely unnecessary. We only need distinct classes for each CharsetDecoder and CharsetEncoder to have them fast. In my approach from ***Bug 100098* - Make sun.nio.cs.* charset objects light-weight**such a class is named 'FastCharset'. As you can see there, in my FastCharsetProviderclass, the lookup of a charset doesn't anymore need a Class.forName(...) call, which should be much faster then before. In the meantime we could have something (which demonstrates the advantage to have the canonical names as constant) like: package sun.nio.cs; public class FastCharsetProvider extends CharsetProvider { public final Charset charsetForName(String charsetName) { switch (charsetName) { case US_ASCII : return new StandardCharset(US_ASCII); case ISO_8859_1 : return new StandardCharset(ISO_8859_1); case UTF_8 : return new StandardCharset(UTF_8); case UTF_16 : return new StandardCharset(UTF_16); case UTF_16BE : return new StandardCharset(UTF_16BE); case UTF_16LE : return new StandardCharset(UTF_16LE); default : synchronized (this) { return lookup(canonicalize(charsetName)); } } final class StandardCharset extends Charset { final String name; newDecoder() { switch (charsetName) { case US_ASCII : return new US_ASCII.Decoder(); case ISO_8859_1 : return new ISO_8859_1.Decoder(); case UTF_8 : return new UTF_8.Decoder(); case UTF_16 : return new UTF_16.Decoder(); case UTF_16BE : return new UTF_16BE.Decoder(); case UTF_16LE : return new UTF_16LE.Decoder(); default : return Charset.defaultCharset().newDecoder(); } newEncoder() { ... } ... } } So I tend to prefer the original request from 4884238 (have the canonical names as constants), as the lookup via Charset.forName(...) then could be very fast compared to the anyway following heavy de/encoding work. In that case we additionally could avoid such weird constructs (potentially superfluously forces the UTF-8 charset class to be loaded): 114 private ZipCoder(Charset cs) { 115 this.cs = cs; 116 this.isutf8 = cs.name().equals(StandardCharset.UTF_8.name()); 117 } Instead we could have: this.isutf8 = cs.name().equals(Charset.UTF_8); -Ulf From Ulf.Zibis at gmx.de Tue Apr 19 11:57:20 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 19 Apr 2011 13:57:20 +0200 Subject: Review (Updated) : 4884238 : Constants for Standard Charsets In-Reply-To: <4DAD4469.80506@oracle.com> References: <4DAD4469.80506@oracle.com> Message-ID: <4DAD78A0.9040103@gmx.de> Am 19.04.2011 10:14, schrieb Alan Bateman: > Given that it now only defines the constants for the standard charsets then I think the new name > is better, although with static import then it might not matter too much. > > I'm not sure whether we should use this in the zip code as we don't want this to causes the lesser > used charsets to be loaded. It might be worth double checking the startup. +1 So the use cases for those charset constants minimize against zero. As written before, I more prefer canonical name constants. -Ulf From Ulf.Zibis at gmx.de Tue Apr 19 12:03:11 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 19 Apr 2011 14:03:11 +0200 Subject: Review (Updated) : 4884238 : Constants for Standard Charsets In-Reply-To: <4DAD7762.4000707@gmx.de> References: <4DAD7762.4000707@gmx.de> Message-ID: <4DAD79FF.3050304@gmx.de> Am 19.04.2011 13:52, schrieb Ulf Zibis: > > Instead we could have: > this.isutf8 = cs.name().equals(Charset.UTF_8); > As you are there, I think names like 'isutf8' could be renamed to 'isUTF8' ... -Ulf From Ulf.Zibis at gmx.de Tue Apr 19 12:50:26 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 19 Apr 2011 14:50:26 +0200 Subject: Review request for 7034570 - java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited In-Reply-To: <4DAC941A.70200@gmx.de> References: <4DA58A18.8080004@oracle.com> <4DA5B125.7030707@gmx.de> <4DA5CD33.50609@oracle.com> <4DA6FF50.7010308@oracle.com> <4DA75F4D.60809@gmx.de> <4DA813A5.5070606@oracle.com> <4DA815C7.2000500@oracle.com> <4DA8260C.6040606@gmx.de> <4DA836E7.8050200@oracle.com> <4DA83DFA.9050207@gmx.de> <4DA84B91.30607@oracle.com> <4DAC941A.70200@gmx.de> Message-ID: <4DAD8512.8080403@gmx.de> Because the attachments were truncated by mailman, I inline my code below... Am 18.04.2011 21:42, schrieb Ulf Zibis: > Am 15.04.2011 15:43, schrieb Michael McMahon: >> I have incorporated much of Ulf's approach into this version. >> >> I agree with Alan about the spec. We could find other variables in the future that need >> to be set, but can have alternative values other than the default. I think this approach >> is the most flexible. >> >> http://cr.openjdk.java.net/~michaelm/7034570/webrev.4/ >> > > Alternatively we could insert the SystemRoot variable from the beginning in the ProcessEnvironment > constructor. > See my approach in the attachment, based on b84 sources and using TreeMap instead HashMap. > IMO, looks much smarter. > > Please note, that my system is in a construction site state and not up to date. So I couldn't test > the code. > > -Ulf > ==================================================================================== /* * Copyright 2003-2006 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. * * * * * * * * * * * * * * * * * * * * */ /* We use APIs that access a so-called Windows "Environment Block", * which looks like an array of jchars like this: * * FOO=BAR\u0000 ... GORP=QUUX\u0000\u0000 * * This data structure has a number of peculiarities we must contend with: * (see: http://windowssdk.msdn.microsoft.com/en-us/library/ms682009.aspx) * - The NUL jchar separators, and a double NUL jchar terminator. * It appears that the Windows implementation requires double NUL * termination even if the environment is empty. We should always * generate environments with double NUL termination, while accepting * empty environments consisting of a single NUL. * - on Windows9x, this is actually an array of 8-bit chars, not jchars, * encoded in the system default encoding. * - The block must be sorted by Unicode value, case-insensitively, * as if folded to upper case. * - There are magic environment variables maintained by Windows * that start with a `=' (!) character. These are used for * Windows drive current directory (e.g. "=C:=C:\WINNT") or the * exit code of the last command (e.g. "=ExitCode=0000001"). * * Since Java and non-9x Windows speak the same character set, and * even the same encoding, we don't have to deal with unreliable * conversion to byte streams. Just add a few NUL terminators. * * System.getenv(String) is case-insensitive, while System.getenv() * returns a map that is case-sensitive, which is consistent with * native Windows APIs. * * The non-private methods in this class are not for general use even * within this package. Instead, they are the system-dependent parts * of the system-independent method of the same name. Don't even * think of using this class unless your method's name appears below. * * @author Martin Buchholz * @author Ulf Zibis * @since 1.5 */ package java.lang; import java.util.*; final class ProcessEnvironment extends TreeMap { private static String validateName(String name) { // An initial `=' indicates a magic Windows variable name -- OK if (name.indexOf('=', 1) != -1 || name.indexOf('\u0000') != -1) throw new IllegalArgumentException ("Invalid environment variable name: \"" + name + "\""); return name; } private static String validateValue(String value) { if (value.indexOf('\u0000') != -1) throw new IllegalArgumentException ("Invalid environment variable value: \"" + value + "\""); return value; } private static String nonNullString(Object o) { if (o == null) throw new NullPointerException(); return (String) o; } public String put(String key, String value) { return super.put(validateName(key), validateValue(value)); } public String get(Object key) { return super.get(nonNullString(key)); } public boolean containsKey(Object key) { return super.containsKey(nonNullString(key)); } public boolean containsValue(Object value) { return super.containsValue(nonNullString(value)); } public String remove(Object key) { return super.remove(nonNullString(key)); } private static class CheckedEntry implements Map.Entry { private final Map.Entry e; public CheckedEntry(Map.Entry e) {this.e = e;} public String getKey() { return e.getKey();} public String getValue() { return e.getValue();} public String setValue(String value) { return e.setValue(validateValue(value)); } public String toString() { return getKey() + "=" + getValue();} public boolean equals(Object o) {return e.equals(o);} public int hashCode() {return e.hashCode();} } private static class CheckedEntrySet extends AbstractSet> { private final Set> s; public CheckedEntrySet(Set> s) {this.s = s;} public int size() {return s.size();} public boolean isEmpty() {return s.isEmpty();} public void clear() { s.clear();} public Iterator> iterator() { return new Iterator<>() { Iterator> i = s.iterator(); public boolean hasNext() { return i.hasNext();} public Map.Entry next() { return new CheckedEntry(i.next()); } public void remove() { i.remove();} }; } private static Map.Entry checkedEntry (Object o) { Map.Entry e = (Map.Entry) o; nonNullString(e.getKey()); nonNullString(e.getValue()); return e; } public boolean contains(Object o) {return s.contains(checkedEntry(o));} public boolean remove(Object o) {return s.remove(checkedEntry(o));} } private static class CheckedValues extends AbstractCollection { private final Collection c; public CheckedValues(Collection c) {this.c = c;} public int size() {return c.size();} public boolean isEmpty() {return c.isEmpty();} public void clear() { c.clear();} public Iterator iterator() {return c.iterator();} public boolean contains(Object o) {return c.contains(nonNullString(o));} public boolean remove(Object o) {return c.remove(nonNullString(o));} } private static class CheckedKeySet extends AbstractSet { private final Set s; public CheckedKeySet(Set s) {this.s = s;} public int size() {return s.size();} public boolean isEmpty() {return s.isEmpty();} public void clear() { s.clear();} public Iterator iterator() {return s.iterator();} public boolean contains(Object o) {return s.contains(nonNullString(o));} public boolean remove(Object o) {return s.remove(nonNullString(o));} } public Set keySet() { return new CheckedKeySet(super.keySet()); } public Collection values() { return new CheckedValues(super.values()); } public Set> entrySet() { return new CheckedEntrySet(super.entrySet()); } // Allow `=' as first char in name, e.g. =C:=C:\DIR static final int MIN_NAME_LENGTH = 1; private static final Comparator nameComparator; private static final ProcessEnvironment theEnvironment; private static final Map theUnmodifiableEnvironment; static { nameComparator = new Comparator<>() { public int compare(String s1, String s2) { // We can't use String.compareToIgnoreCase since it // canonicalizes to lower case, while Windows // canonicalizes to upper case! For example, "_" should // sort *after* "Z", not before. int n1 = s1.length(); int n2 = s2.length(); int min = Math.min(n1, n2); for (int i = 0; i < min; i++) { char c1 = s1.charAt(i); char c2 = s2.charAt(i); if (c1 != c2) { c1 = Character.toUpperCase(c1); c2 = Character.toUpperCase(c2); if (c1 != c2) // No overflow because of numeric promotion return c1 - c2; } } return n1 - n2; } }; theEnvironment = new ProcessEnvironment(); theUnmodifiableEnvironment = Collections.unmodifiableMap(theEnvironment); String envblock = environmentBlock(); int beg, end, eql; for (beg = 0; ((end = envblock.indexOf('\u0000', beg )) != -1 && // An initial `=' indicates a magic Windows variable name -- OK (eql = envblock.indexOf('=' , beg+1)) != -1); beg = end + 1) { // Ignore corrupted environment strings. if (eql < end) theEnvironment.put(envblock.substring(beg, eql), envblock.substring(eql+1,end)); } } private ProcessEnvironment() { super(nameComparator); // Some versions of MSVCRT.DLL require SystemRoot to be set. // So, we make sure that it is always set, even if not provided // by the caller. final String SYSTEMROOT = "SystemRoot"; try { put(SYSTEMROOT, getenv(SYSTEMROOT)); } catch (NullPointerException npe) {} } // Only for use by System.getenv(String) static String getenv(String name) { // The original implementation used a native call to _wgetenv, // but it turns out that _wgetenv is only consistent with // GetEnvironmentStringsW (for non-ASCII) if `wmain' is used // instead of `main', even in a process created using // CREATE_UNICODE_ENVIRONMENT. Instead we perform the // case-insensitive comparison ourselves. At least this // guarantees that System.getenv().get(String) will be // consistent with System.getenv(String). return theEnvironment.get(name); } // Only for use by System.getenv() static Map getenv() { return theUnmodifiableEnvironment; } // Only for use by ProcessBuilder.environment() static ProcessEnvironment environment() { return (ProcessEnvironment)theEnvironment.clone(); } // Only for use by ProcessBuilder.environment(String[] envp) static ProcessEnvironment emptyEnvironment() { return new ProcessEnvironment(); } private static native String environmentBlock(); // Only for use by ProcessImpl.start() String toEnvironmentBlock() { StringBuilder sb = new StringBuilder(size()*30); for (Map.Entry e : entrySet()) sb.append(e.getKey()) .append('=') .append(e.getValue()) .append('\u0000'); // Ensure double NUL termination, even if environment is empty. if (sb.length() == 0) sb.append('\u0000'); sb.append('\u0000'); return sb.toString(); } static String toEnvironmentBlock(ProcessEnvironment map) { return map == null ? null : map.toEnvironmentBlock(); } } ==================================================================================== /* * Copyright 2003-2008 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. * * * * * * * * * * * * * * * * * * * * */ package java.lang; import java.io.File; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; import java.io.FileOutputStream; import java.util.Arrays; import java.util.ArrayList; import java.util.List; /** * This class is used to create operating system processes. * *

Each {@code ProcessBuilder} instance manages a collection * of process attributes. The {@link #start()} method creates a new * {@link Process} instance with those attributes. The {@link * #start()} method can be invoked repeatedly from the same instance * to create new subprocesses with identical or related attributes. * *

Each process builder manages these process attributes: * *

* *

Modifying a process builder's attributes will affect processes * subsequently started by that object's {@link #start()} method, but * will never affect previously started processes or the Java process * itself. * *

Most error checking is performed by the {@link #start()} method. * It is possible to modify the state of an object so that {@link * #start()} will fail. For example, setting the command attribute to * an empty list will not throw an exception unless {@link #start()} * is invoked. * *

Note that this class is not synchronized. * If multiple threads access a {@code ProcessBuilder} instance * concurrently, and at least one of the threads modifies one of the * attributes structurally, it must be synchronized externally. * *

Starting a new process which uses the default working directory * and environment is easy: * * 

 {@code
  * Process p = new ProcessBuilder("myCommand", "myArg").start();
  * }
* *

Here is an example that starts a process with a modified working * directory and environment, and redirects standard output and error * to be appended to a log file: * * 

 {@code
  * ProcessBuilder pb =
  *   new ProcessBuilder("myCommand", "myArg1", "myArg2");
  * Map env = pb.environment();
  * env.put("VAR1", "myValue");
  * env.remove("OTHERVAR");
  * env.put("VAR2", env.get("VAR1") + "suffix");
  * pb.directory(new File("myDir"));
  * File log = new File("log");
  * pb.redirectErrorStream(true);
  * pb.redirectOutput(Redirect.appendTo(log));
  * Process p = pb.start();
  * assert pb.redirectInput() == Redirect.PIPE;
  * assert pb.redirectOutput().file() == log;
  * assert p.getInputStream().read() == -1;
  * }
* *

To start a process with an explicit set of environment * variables, first call {@link java.util.Map#clear() Map.clear()} * before adding environment variables. * * @author Martin Buchholz * @since 1.5 */ public final class ProcessBuilder { private List command; private File directory; private ProcessEnvironment environment; private boolean redirectErrorStream; private Redirect[] redirects; /** * Constructs a process builder with the specified operating * system program and arguments. This constructor does not * make a copy of the {@code command} list. Subsequent * updates to the list will be reflected in the state of the * process builder. It is not checked whether * {@code command} corresponds to a valid operating system * command. * * @param command the list containing the program and its arguments * @throws NullPointerException if the argument is null */ public ProcessBuilder(List command) { command(command); } /** * Constructs a process builder with the specified operating * system program and arguments. This is a convenience * constructor that sets the process builder's command to a string * list containing the same strings as the {@code command} * array, in the same order. It is not checked whether * {@code command} corresponds to a valid operating system * command. * * @param command a string array containing the program and its arguments */ public ProcessBuilder(String... command) { command(command); } /** * Sets this process builder's operating system program and * arguments. This method does not make a copy of the * {@code command} list. Subsequent updates to the list will * be reflected in the state of the process builder. It is not * checked whether {@code command} corresponds to a valid * operating system command. * * @param command the list containing the program and its arguments * @return this process builder * * @throws NullPointerException if the argument is null */ public ProcessBuilder command(List command) { if (command == null) throw new NullPointerException(); this.command = command; return this; } /** * Sets this process builder's operating system program and * arguments. This is a convenience method that sets the command * to a string list containing the same strings as the * {@code command} array, in the same order. It is not * checked whether {@code command} corresponds to a valid * operating system command. * * @param command a string array containing the program and its arguments * @return this process builder */ public ProcessBuilder command(String... command) { this.command = new ArrayList(command.length); for (String arg : command) this.command.add(arg); return this; } /** * Returns this process builder's operating system program and * arguments. The returned list is not a copy. Subsequent * updates to the list will be reflected in the state of this * process builder. * * @return this process builder's program and its arguments */ public List command() { return command; } /** * Returns a string map view of this process builder's environment. * * Whenever a process builder is created, the environment is * initialized to a copy of the current process environment (see * {@link System#getenv()}). Subprocesses subsequently started by * this object's {@link #start()} method will use this map as * their environment. * *

The returned object may be modified using ordinary {@link * java.util.Map Map} operations. These modifications will be * visible to subprocesses started via the {@link #start()} * method. Two {@code ProcessBuilder} instances always * contain independent process environments, so changes to the * returned map will never be reflected in any other * {@code ProcessBuilder} instance or the values returned by * {@link System#getenv System.getenv}. * *

If the system does not support environment variables, an * empty map is returned. * *

The returned map does not permit null keys or values. * Attempting to insert or query the presence of a null key or * value will throw a {@link NullPointerException}. * Attempting to query the presence of a key or value which is not * of type {@link String} will throw a {@link ClassCastException}. * *

The behavior of the returned map is system-dependent. A * system may not allow modifications to environment variables or * may forbid certain variable names or values. For this reason, * attempts to modify the map may fail with * {@link UnsupportedOperationException} or * {@link IllegalArgumentException} * if the modification is not permitted by the operating system. * *

Since the external format of environment variable names and * values is system-dependent, there may not be a one-to-one * mapping between them and Java's Unicode strings. Nevertheless, * the map is implemented in such a way that environment variables * which are not modified by Java code will have an unmodified * native representation in the subprocess. * *

The returned map and its collection views may not obey the * general contract of the {@link Object#equals} and * {@link Object#hashCode} methods. * *

The returned map is typically case-sensitive on all platforms. * *

If a security manager exists, its * {@link SecurityManager#checkPermission checkPermission} method * is called with a * {@link RuntimePermission}{@code ("getenv.*")} permission. * This may result in a {@link SecurityException} being thrown. * *

When passing information to a Java subprocess, * system properties * are generally preferred over environment variables. * * @return this process builder's environment * * @throws SecurityException * if a security manager exists and its * {@link SecurityManager#checkPermission checkPermission} * method doesn't allow access to the process environment * * @see Runtime#exec(String[],String[],java.io.File) * @see System#getenv() */ public ProcessEnvironment environment() { SecurityManager security = System.getSecurityManager(); if (security != null) security.checkPermission(new RuntimePermission("getenv.*")); if (environment == null) environment = ProcessEnvironment.environment(); assert environment != null; return environment; } // Only for use by Runtime.exec(...envp...) ProcessBuilder environment(String[] envp) { assert environment == null; if (envp != null) { environment = ProcessEnvironment.emptyEnvironment(); assert environment != null; for (String envstring : envp) { // Before 1.5, we blindly passed invalid envstrings // to the child process. // We would like to throw an exception, but do not, // for compatibility with old broken code. // Silently discard any trailing junk. if (envstring.indexOf((int) '\u0000') != -1) envstring = envstring.replaceFirst("\u0000.*", ""); int eqlsign = envstring.indexOf('=', ProcessEnvironment.MIN_NAME_LENGTH); // Silently ignore envstrings lacking the required `='. if (eqlsign != -1) environment.put(envstring.substring(0,eqlsign), envstring.substring(eqlsign+1)); } } return this; } /** * Returns this process builder's working directory. * * Subprocesses subsequently started by this object's {@link * #start()} method will use this as their working directory. * The returned value may be {@code null} -- this means to use * the working directory of the current Java process, usually the * directory named by the system property {@code user.dir}, * as the working directory of the child process. * * @return this process builder's working directory */ public File directory() { return directory; } /** * Sets this process builder's working directory. * * Subprocesses subsequently started by this object's {@link * #start()} method will use this as their working directory. * The argument may be {@code null} -- this means to use the * working directory of the current Java process, usually the * directory named by the system property {@code user.dir}, * as the working directory of the child process. * * @param directory the new working directory * @return this process builder */ public ProcessBuilder directory(File directory) { this.directory = directory; return this; } // ---------------- I/O Redirection ---------------- /** * Implements a null input stream. */ static class NullInputStream extends InputStream { public int read() { return -1; } public int available() { return 0; } } /** * Implements a null output stream. */ static class NullOutputStream extends OutputStream { public void write(int b) throws IOException { throw new IOException("Stream closed"); } } /** * Represents a source of subprocess input or a destination of * subprocess output. * * Each {@code Redirect} instance is one of the following: * *

    *
  • the special value {@link #PIPE Redirect.PIPE} *
  • the special value {@link #INHERIT Redirect.INHERIT} *
  • a redirection to read from a file, created by an invocation of * {@link Redirect#from Redirect.from(File)} *
  • a redirection to write to a file, created by an invocation of * {@link Redirect#to Redirect.to(File)} *
  • a redirection to append to a file, created by an invocation of * {@link Redirect#appendTo Redirect.appendTo(File)} *
* *

Each of the above categories has an associated unique * {@link Type Type}. * * @since 1.7 */ public static abstract class Redirect { /** * The type of a {@link Redirect}. */ public enum Type { /** * The type of {@link Redirect#PIPE Redirect.PIPE}. */ PIPE, /** * The type of {@link Redirect#INHERIT Redirect.INHERIT}. */ INHERIT, /** * The type of redirects returned from * {@link Redirect#from Redirect.from(File)}. */ READ, /** * The type of redirects returned from * {@link Redirect#to Redirect.to(File)}. */ WRITE, /** * The type of redirects returned from * {@link Redirect#appendTo Redirect.appendTo(File)}. */ APPEND }; /** * Returns the type of this {@code Redirect}. * @return the type of this {@code Redirect} */ public abstract Type type(); /** * Indicates that subprocess I/O will be connected to the * current Java process over a pipe. * * This is the default handling of subprocess standard I/O. * *

It will always be true that * 

 {@code
          * Redirect.PIPE.file() == null &&
          * Redirect.PIPE.type() == Redirect.Type.PIPE
          * }
*/ public static final Redirect PIPE = new Redirect() { public Type type() { return Type.PIPE; } public String toString() { return type().toString(); }}; /** * Indicates that subprocess I/O source or destination will be the * same as those of the current process. This is the normal * behavior of most operating system command interpreters (shells). * *

It will always be true that * 

 {@code
          * Redirect.INHERIT.file() == null &&
          * Redirect.INHERIT.type() == Redirect.Type.INHERIT
          * }
*/ public static final Redirect INHERIT = new Redirect() { public Type type() { return Type.INHERIT; } public String toString() { return type().toString(); }}; /** * Returns the {@link File} source or destination associated * with this redirect, or {@code null} if there is no such file. * * @return the file associated with this redirect, * or {@code null} if there is no such file */ public File file() { return null; } FileOutputStream toFileOutputStream() throws IOException { throw new UnsupportedOperationException(); } /** * Returns a redirect to read from the specified file. * *

It will always be true that * 

 {@code
          * Redirect.from(file).file() == file &&
          * Redirect.from(file).type() == Redirect.Type.READ
          * }
* * @throws NullPointerException if the specified file is null * @return a redirect to read from the specified file */ public static Redirect from(final File file) { if (file == null) throw new NullPointerException(); return new Redirect() { public Type type() { return Type.READ; } public File file() { return file; } public String toString() { return "redirect to read from file \"" + file + "\""; } }; } /** * Returns a redirect to write to the specified file. * If the specified file exists when the subprocess is started, * its previous contents will be discarded. * *

It will always be true that * 

 {@code
          * Redirect.to(file).file() == file &&
          * Redirect.to(file).type() == Redirect.Type.WRITE
          * }
* * @throws NullPointerException if the specified file is null * @return a redirect to write to the specified file */ public static Redirect to(final File file) { if (file == null) throw new NullPointerException(); return new Redirect() { public Type type() { return Type.WRITE; } public File file() { return file; } public String toString() { return "redirect to write to file \"" + file + "\""; } FileOutputStream toFileOutputStream() throws IOException { return new FileOutputStream(file, false); } }; } /** * Returns a redirect to append to the specified file. * Each write operation first advances the position to the * end of the file and then writes the requested data. * Whether the advancement of the position and the writing * of the data are done in a single atomic operation is * system-dependent and therefore unspecified. * *

It will always be true that * 

 {@code
          * Redirect.appendTo(file).file() == file &&
          * Redirect.appendTo(file).type() == Redirect.Type.APPEND
          * }
* * @throws NullPointerException if the specified file is null * @return a redirect to append to the specified file */ public static Redirect appendTo(final File file) { if (file == null) throw new NullPointerException(); return new Redirect() { public Type type() { return Type.APPEND; } public File file() { return file; } public String toString() { return "redirect to append to file \"" + file + "\""; } FileOutputStream toFileOutputStream() throws IOException { return new FileOutputStream(file, true); } }; } /** * Compares the specified object with this {@code Redirect} for * equality. Returns {@code true} if and only if the two * objects are identical or both objects are {@code Redirect} * instances of the same type associated with non-null equal * {@code File} instances. */ public boolean equals(Object obj) { if (obj == this) return true; if (! (obj instanceof Redirect)) return false; Redirect r = (Redirect) obj; if (r.type() != this.type()) return false; assert this.file() != null; return this.file().equals(r.file()); } /** * Returns a hash code value for this {@code Redirect}. * @return a hash code value for this {@code Redirect} */ public int hashCode() { File file = file(); if (file == null) return super.hashCode(); else return file.hashCode(); } /** * No public constructors. Clients must use predefined * static {@code Redirect} instances or factory methods. */ private Redirect() {} } private Redirect[] redirects() { if (redirects == null) redirects = new Redirect[] { Redirect.PIPE, Redirect.PIPE, Redirect.PIPE }; return redirects; } /** * Sets this process builder's standard input source. * * Subprocesses subsequently started by this object's {@link #start()} * method obtain their standard input from this source. * *

If the source is {@link Redirect#PIPE Redirect.PIPE} * (the initial value), then the standard input of a * subprocess can be written to using the output stream * returned by {@link Process#getOutputStream()}. * If the source is set to any other value, then * {@link Process#getOutputStream()} will return a * null output stream. * * @param source the new standard input source * @return this process builder * @throws IllegalArgumentException * if the redirect does not correspond to a valid source * of data, that is, has type * {@link Redirect.Type#WRITE WRITE} or * {@link Redirect.Type#APPEND APPEND} * @since 1.7 */ public ProcessBuilder redirectInput(Redirect source) { if (source.type() == Redirect.Type.WRITE || source.type() == Redirect.Type.APPEND) throw new IllegalArgumentException( "Redirect invalid for reading: " + source); redirects()[0] = source; return this; } /** * Sets this process builder's standard output destination. * * Subprocesses subsequently started by this object's {@link #start()} * method send their standard output to this destination. * *

If the destination is {@link Redirect#PIPE Redirect.PIPE} * (the initial value), then the standard output of a subprocess * can be read using the input stream returned by {@link * Process#getInputStream()}. * If the destination is set to any other value, then * {@link Process#getInputStream()} will return a * null input stream. * * @param destination the new standard output destination * @return this process builder * @throws IllegalArgumentException * if the redirect does not correspond to a valid * destination of data, that is, has type * {@link Redirect.Type#READ READ} * @since 1.7 */ public ProcessBuilder redirectOutput(Redirect destination) { if (destination.type() == Redirect.Type.READ) throw new IllegalArgumentException( "Redirect invalid for writing: " + destination); redirects()[1] = destination; return this; } /** * Sets this process builder's standard error destination. * * Subprocesses subsequently started by this object's {@link #start()} * method send their standard error to this destination. * *

If the destination is {@link Redirect#PIPE Redirect.PIPE} * (the initial value), then the error output of a subprocess * can be read using the input stream returned by {@link * Process#getErrorStream()}. * If the destination is set to any other value, then * {@link Process#getErrorStream()} will return a * null input stream. * *

If the {@link #redirectErrorStream redirectErrorStream} * attribute has been set {@code true}, then the redirection set * by this method has no effect. * * @param destination the new standard error destination * @return this process builder * @throws IllegalArgumentException * if the redirect does not correspond to a valid * destination of data, that is, has type * {@link Redirect.Type#READ READ} * @since 1.7 */ public ProcessBuilder redirectError(Redirect destination) { if (destination.type() == Redirect.Type.READ) throw new IllegalArgumentException( "Redirect invalid for writing: " + destination); redirects()[2] = destination; return this; } /** * Sets this process builder's standard input source to a file. * *

This is a convenience method. An invocation of the form * {@code redirectInput(file)} * behaves in exactly the same way as the invocation * {@link #redirectInput(Redirect) redirectInput} * {@code (Redirect.from(file))}. * * @param file the new standard input source * @return this process builder * @since 1.7 */ public ProcessBuilder redirectInput(File file) { return redirectInput(Redirect.from(file)); } /** * Sets this process builder's standard output destination to a file. * *

This is a convenience method. An invocation of the form * {@code redirectOutput(file)} * behaves in exactly the same way as the invocation * {@link #redirectOutput(Redirect) redirectOutput} * {@code (Redirect.to(file))}. * * @param file the new standard output destination * @return this process builder * @since 1.7 */ public ProcessBuilder redirectOutput(File file) { return redirectOutput(Redirect.to(file)); } /** * Sets this process builder's standard error destination to a file. * *

This is a convenience method. An invocation of the form * {@code redirectError(file)} * behaves in exactly the same way as the invocation * {@link #redirectError(Redirect) redirectError} * {@code (Redirect.to(file))}. * * @param file the new standard error destination * @return this process builder * @since 1.7 */ public ProcessBuilder redirectError(File file) { return redirectError(Redirect.to(file)); } /** * Returns this process builder's standard input source. * * Subprocesses subsequently started by this object's {@link #start()} * method obtain their standard input from this source. * The initial value is {@link Redirect#PIPE Redirect.PIPE}. * * @return this process builder's standard input source * @since 1.7 */ public Redirect redirectInput() { return (redirects == null) ? Redirect.PIPE : redirects[0]; } /** * Returns this process builder's standard output destination. * * Subprocesses subsequently started by this object's {@link #start()} * method redirect their standard output to this destination. * The initial value is {@link Redirect#PIPE Redirect.PIPE}. * * @return this process builder's standard output destination * @since 1.7 */ public Redirect redirectOutput() { return (redirects == null) ? Redirect.PIPE : redirects[1]; } /** * Returns this process builder's standard error destination. * * Subprocesses subsequently started by this object's {@link #start()} * method redirect their standard error to this destination. * The initial value is {@link Redirect#PIPE Redirect.PIPE}. * * @return this process builder's standard error destination * @since 1.7 */ public Redirect redirectError() { return (redirects == null) ? Redirect.PIPE : redirects[2]; } /** * Sets the source and destination for subprocess standard I/O * to be the same as those of the current Java process. * *

This is a convenience method. An invocation of the form * 

 {@code
      * pb.inheritIO()
      * }
* behaves in exactly the same way as the invocation * 
 {@code
      * pb.redirectInput(Redirect.INHERIT)
      *   .redirectOutput(Redirect.INHERIT)
      *   .redirectError(Redirect.INHERIT)
      * }
* * This gives behavior equivalent to most operating system * command interpreters, or the standard C library function * {@code system()}. * * @return this process builder * @since 1.7 */ public ProcessBuilder inheritIO() { Arrays.fill(redirects(), Redirect.INHERIT); return this; } /** * Tells whether this process builder merges standard error and * standard output. * *

If this property is {@code true}, then any error output * generated by subprocesses subsequently started by this object's * {@link #start()} method will be merged with the standard * output, so that both can be read using the * {@link Process#getInputStream()} method. This makes it easier * to correlate error messages with the corresponding output. * The initial value is {@code false}. * * @return this process builder's {@code redirectErrorStream} property */ public boolean redirectErrorStream() { return redirectErrorStream; } /** * Sets this process builder's {@code redirectErrorStream} property. * *

If this property is {@code true}, then any error output * generated by subprocesses subsequently started by this object's * {@link #start()} method will be merged with the standard * output, so that both can be read using the * {@link Process#getInputStream()} method. This makes it easier * to correlate error messages with the corresponding output. * The initial value is {@code false}. * * @param redirectErrorStream the new property value * @return this process builder */ public ProcessBuilder redirectErrorStream(boolean redirectErrorStream) { this.redirectErrorStream = redirectErrorStream; return this; } /** * Starts a new process using the attributes of this process builder. * *

The new process will * invoke the command and arguments given by {@link #command()}, * in a working directory as given by {@link #directory()}, * with a process environment as given by {@link #environment()}. * *

This method checks that the command is a valid operating * system command. Which commands are valid is system-dependent, * but at the very least the command must be a non-empty list of * non-null strings. * *

If there is a security manager, its * {@link SecurityManager#checkExec checkExec} * method is called with the first component of this object's * {@code command} array as its argument. This may result in * a {@link SecurityException} being thrown. * *

Starting an operating system process is highly system-dependent. * Among the many things that can go wrong are: *

    *
  • The operating system program file was not found. *
  • Access to the program file was denied. *
  • The working directory does not exist. *
* *

In such cases an exception will be thrown. The exact nature * of the exception is system-dependent, but it will always be a * subclass of {@link IOException}. * *

Subsequent modifications to this process builder will not * affect the returned {@link Process}. * * @return a new {@link Process} object for managing the subprocess * * @throws NullPointerException * if an element of the command list is null * * @throws IndexOutOfBoundsException * if the command is an empty list (has size {@code 0}) * * @throws SecurityException * if a security manager exists and *

    * *
  • its * {@link SecurityManager#checkExec checkExec} * method doesn't allow creation of the subprocess, or * *
  • the standard input to the subprocess was * {@linkplain #redirectInput redirected from a file} * and the security manager's * {@link SecurityManager#checkRead checkRead} method * denies read access to the file, or * *
  • the standard output or standard error of the * subprocess was * {@linkplain #redirectOutput redirected to a file} * and the security manager's * {@link SecurityManager#checkWrite checkWrite} method * denies write access to the file * *
* * @throws IOException if an I/O error occurs * * @see Runtime#exec(String[], String[], java.io.File) */ public Process start() throws IOException { // Must convert to array first -- a malicious user-supplied // list might try to circumvent the security check. String[] cmdarray = command.toArray(new String[command.size()]); for (String arg : cmdarray) if (arg == null) throw new NullPointerException(); // Throws IndexOutOfBoundsException if command is empty String prog = cmdarray[0]; SecurityManager security = System.getSecurityManager(); if (security != null) security.checkExec(prog); String dir = directory == null ? null : directory.toString(); try { return ProcessImpl.start(cmdarray, environment, dir, redirects, redirectErrorStream); } catch (IOException e) { // It's much easier for us to create a high-quality error // message than the low-level C code which found the problem. throw new IOException( "Cannot run program \"" + prog + "\"" + (dir == null ? "" : " (in directory \"" + dir + "\")") + ": " + e.getMessage(), e); } } } ==================================================================================== /* * Copyright 1995-2008 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. * * * * * * * * * * * * * * * * * * * * */ package java.lang; import java.io.IOException; import java.io.File; import java.io.InputStream; import java.io.OutputStream; import java.io.FileInputStream; import java.io.FileOutputStream; import java.io.FileDescriptor; import java.io.BufferedInputStream; import java.io.BufferedOutputStream; import java.lang.ProcessBuilder.Redirect; /* This class is for the exclusive use of ProcessBuilder.start() to * create new processes. * * @author Martin Buchholz * @since 1.5 */ final class ProcessImpl extends Process { private static final sun.misc.JavaIOFileDescriptorAccess fdAccess = sun.misc.SharedSecrets.getJavaIOFileDescriptorAccess(); // System-dependent portion of ProcessBuilder.start() static Process start(String cmdarray[], ProcessEnvironment environment, String dir, ProcessBuilder.Redirect[] redirects, boolean redirectErrorStream) throws IOException { String envblock = ProcessEnvironment.toEnvironmentBlock(environment); FileInputStream f0 = null; FileOutputStream f1 = null; FileOutputStream f2 = null; try { long[] stdHandles; if (redirects == null) { stdHandles = new long[] { -1L, -1L, -1L }; } else { stdHandles = new long[3]; if (redirects[0] == Redirect.PIPE) stdHandles[0] = -1L; else if (redirects[0] == Redirect.INHERIT) stdHandles[0] = fdAccess.getHandle(FileDescriptor.in); else { f0 = new FileInputStream(redirects[0].file()); stdHandles[0] = fdAccess.getHandle(f0.getFD()); } if (redirects[1] == Redirect.PIPE) stdHandles[1] = -1L; else if (redirects[1] == Redirect.INHERIT) stdHandles[1] = fdAccess.getHandle(FileDescriptor.out); else { f1 = redirects[1].toFileOutputStream(); stdHandles[1] = fdAccess.getHandle(f1.getFD()); } if (redirects[2] == Redirect.PIPE) stdHandles[2] = -1L; else if (redirects[2] == Redirect.INHERIT) stdHandles[2] = fdAccess.getHandle(FileDescriptor.err); else { f2 = redirects[2].toFileOutputStream(); stdHandles[2] = fdAccess.getHandle(f2.getFD()); } } return new ProcessImpl(cmdarray, envblock, dir, stdHandles, redirectErrorStream); } finally { // In theory, close() can throw IOException // (although it is rather unlikely to happen here) try { if (f0 != null) f0.close(); } finally { try { if (f1 != null) f1.close(); } finally { if (f2 != null) f2.close(); } } } } private long handle = 0; private OutputStream stdin_stream; private InputStream stdout_stream; private InputStream stderr_stream; private ProcessImpl(final String cmd[], final String envblock, final String path, final long[] stdHandles, final boolean redirectErrorStream) throws IOException { // Win32 CreateProcess requires cmd[0] to be normalized cmd[0] = new File(cmd[0]).getPath(); StringBuilder cmdbuf = new StringBuilder(80); for (int i = 0; i < cmd.length; i++) { if (i > 0) { cmdbuf.append(' '); } String s = cmd[i]; if (s.indexOf(' ') >= 0 || s.indexOf('\t') >= 0) { if (s.charAt(0) != '"') { cmdbuf.append('"'); cmdbuf.append(s); if (s.endsWith("\\")) { cmdbuf.append("\\"); } cmdbuf.append('"'); } else if (s.endsWith("\"")) { /* The argument has already been quoted. */ cmdbuf.append(s); } else { /* Unmatched quote for the argument. */ throw new IllegalArgumentException(); } } else { cmdbuf.append(s); } } String cmdstr = cmdbuf.toString(); handle = create(cmdstr, envblock, path, stdHandles, redirectErrorStream); java.security.AccessController.doPrivileged( new java.security.PrivilegedAction() { public Void run() { if (stdHandles[0] == -1L) stdin_stream = new ProcessBuilder.NullOutputStream(); else { FileDescriptor stdin_fd = new FileDescriptor(); fdAccess.setHandle(stdin_fd, stdHandles[0]); stdin_stream = new BufferedOutputStream( new FileOutputStream(stdin_fd)); } if (stdHandles[1] == -1L) stdout_stream = new ProcessBuilder.NullInputStream(); else { FileDescriptor stdout_fd = new FileDescriptor(); fdAccess.setHandle(stdout_fd, stdHandles[1]); stdout_stream = new BufferedInputStream( new FileInputStream(stdout_fd)); } if (stdHandles[2] == -1L) stderr_stream = new ProcessBuilder.NullInputStream(); else { FileDescriptor stderr_fd = new FileDescriptor(); fdAccess.setHandle(stderr_fd, stdHandles[2]); stderr_stream = new FileInputStream(stderr_fd); } return null; }}); } public OutputStream getOutputStream() { return stdin_stream; } public InputStream getInputStream() { return stdout_stream; } public InputStream getErrorStream() { return stderr_stream; } public void finalize() { closeHandle(handle); } private static final int STILL_ACTIVE = getStillActive(); private static native int getStillActive(); public int exitValue() { int exitCode = getExitCodeProcess(handle); if (exitCode == STILL_ACTIVE) throw new IllegalThreadStateException("process has not exited"); return exitCode; } private static native int getExitCodeProcess(long handle); public int waitFor() throws InterruptedException { waitForInterruptibly(handle); if (Thread.interrupted()) throw new InterruptedException(); return exitValue(); } private static native void waitForInterruptibly(long handle); public void destroy() { terminateProcess(handle); } private static native void terminateProcess(long handle); /** * Create a process using the win32 function CreateProcess. * * @param cmdstr the Windows commandline * @param envblock NUL-separated, double-NUL-terminated list of * environment strings in VAR=VALUE form * @param dir the working directory of the process, or null if * inheriting the current directory from the parent process * @param stdHandles array of windows HANDLEs. Indexes 0, 1, and * 2 correspond to standard input, standard output and * standard error, respectively. On input, a value of -1 * means to create a pipe to connect child and parent * processes. On output, a value which is not -1 is the * parent pipe handle corresponding to the pipe which has * been created. An element of this array is -1 on input * if and only if it is not -1 on output. * @param redirectErrorStream redirectErrorStream attribute * @return the native subprocess HANDLE returned by CreateProcess */ private static native long create(String cmdstr, String envblock, String dir, long[] stdHandles, boolean redirectErrorStream) throws IOException; private static native boolean closeHandle(long handle); } ==================================================================================== From maurizio.cimadamore at oracle.com Tue Apr 19 12:57:46 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 19 Apr 2011 12:57:46 +0000 Subject: hg: jdk7/tl/langtools: 7036906: Scope: CompoundScope.getElements() doesn't pass scope filter to subscopes Message-ID: <20110419125752.5CAEB47C12@hg.openjdk.java.net> Changeset: 671bb63f3ed5 Author: mcimadamore Date: 2011-04-19 13:57 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/671bb63f3ed5 7036906: Scope: CompoundScope.getElements() doesn't pass scope filter to subscopes Summary: CompoundScope.getElements() is not filtering elements according to the ScopeFilter argument Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Scope.java ! test/tools/javac/scope/7017664/CompoundScopeTest.java From Ulf.Zibis at gmx.de Tue Apr 19 14:05:54 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 19 Apr 2011 16:05:54 +0200 Subject: Review (Updated) : 4884238 : Constants for Standard Charsets - correction !!! In-Reply-To: <4DAD7762.4000707@gmx.de> References: <4DAD7762.4000707@gmx.de> Message-ID: <4DAD96C2.8040902@gmx.de> package sun.nio.cs; public class FastCharsetProvider extends CharsetProvider { ... private Charset lookup(String charsetName) { String csn = canonicalize(toLower(charsetName)); // Check cache first Charset cs = cache.get(csn); if (cs != null) return cs; StandardCharset: { switch (charsetName) { case US_ASCII : cs = StandardCharset(US_ASCII); break; case ISO_8859_1 : cs = StandardCharset(ISO_8859_1); break; case UTF_8 : cs = StandardCharset(UTF_8); break; case UTF_16 : cs = StandardCharset(UTF_16); break; case UTF_16BE : cs = StandardCharset(UTF_16BE); break; case UTF_16LE : cs = StandardCharset(UTF_16LE); break; default : break StandardCharset; } cache.put(csn, cs); return cs; } // Do we even support this charset? String cln = classMap.get(csn); if (cln == null) return null; // Instantiate the charset and cache it ... } final class StandardCharset extends Charset { final String name; newDecoder() { switch (charsetName) { case US_ASCII : return new US_ASCII.Decoder(); case ISO_8859_1 : return new ISO_8859_1.Decoder(); case UTF_8 : return new UTF_8.Decoder(); case UTF_16 : return new UTF_16.Decoder(); case UTF_16BE : return new UTF_16BE.Decoder(); case UTF_16LE : return new UTF_16LE.Decoder(); default : return Charset.defaultCharset().newDecoder(); } } newEncoder() { ... } ... } } -Ulf From mark.reinhold at oracle.com Tue Apr 19 15:00:05 2011 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 19 Apr 2011 08:00:05 -0700 Subject: Review (Updated) : 4884238 : Constants for Standard Charsets In-Reply-To: ulf.zibis@gmx.de; Tue, 19 Apr 2011 13:52:02 +0200; <4DAD7762.4000707@gmx.de> Message-ID: <20110419150005.07E98976@eggemoggin.niobe.net> 2011/4/19 4:52 -0700, ulf.zibis at gmx.de: > Am 19.04.2011 00:24, schrieb Mike Duigou: > Reading 'StandardCharset' one expects _the_ standard charset, but we have a > collection of 6 here, so I'm for 'StandardCharsets' similar to > e.g. j.u.z.ZipConstants, j.u.z.ZipConstants64, ... I agree. "StandardCharsets" would be a better name. - Mark From michael.x.mcmahon at oracle.com Tue Apr 19 15:05:14 2011 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 19 Apr 2011 16:05:14 +0100 Subject: Review request for 7034570 - java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited In-Reply-To: <4DAC9080.3060702@gmx.de> References: <4DA58A18.8080004@oracle.com> <4DA5B125.7030707@gmx.de> <4DA5CD33.50609@oracle.com> <4DA6FF50.7010308@oracle.com> <4DA75F4D.60809@gmx.de> <4DA813A5.5070606@oracle.com> <4DA815C7.2000500@oracle.com> <4DA8260C.6040606@gmx.de> <4DA836E7.8050200@oracle.com> <4DA83DFA.9050207@gmx.de> <4DA84B91.30607@oracle.com> <4DA973EA.6050705@oracle.com> <4DAC384F.8040008@gmx.de> <4DAC4015.6020304@oracle.com> <4DAC9080.3060702@gmx.de> Message-ID: <4DADA4AA.8040900@oracle.com> Ulf, On the usage of List vs [], my point was that the clarity, simplicity and safety provided by iterating over a Collection out-weighs any performance cost in this case, as compared with using an array. It makes little difference to the cost of creating an OS process. On moving the SYSTEMROOT constant to be a local variable inside toEnvironmentBlock(), on balance it probably does look neater. Since I have to regenerate the webrev to fix a problem I found with the testcase, I'm including that change and the change to the comment for emptyEnvironment(). But, at this stage, I have to move onto other work, and this is the last webrev for this fix, unless someone finds a bug .. http://cr.openjdk.java.net/~michaelm/7034570/webrev.5/ Thanks for the work you put into reviewing it. - Michael. Ulf Zibis wrote: > Am 18.04.2011 15:43, schrieb Michael McMahon: >> Ulf Zibis wrote: >>> I think, the comment in lines 295..297 more belongs to the code >>> (lines 312..315 + 318..320 ) rather than to the constant SYSTEMROOT. >>> Why defining it as class member, as it is only locally referred? >>> >> It makes no difference to the generated code. And imo, there is more >> space for the comment there. > > Hm, can't share that reason. But anyway, the comment would be little > closer to the code, if the constant would at least be defined in the > mothod's scope. > >>> I still don't see the advantage, having the SYSTEMROOT insertion >>> code at 2 call sites. One would be shorter and much clearer as shown >>> in my code. Then we too could save addToEnvIfSet(..) and the call to >>> it. >>> >> Shorter doesn't always mean clearer. I think this way is clearer. > Not always yes, but each code line has to be understood by the reader. > The more lines to read, the more lines to understand, apart from the > bigger memory and codebase footprint. Just my opinion. > >>> Additionally: Why instantiating, initializing and processing a fat >>> j.u.List object, if a simple array would fulfil all needs? >>> >> I don't see a compelling reason to change it from a List (which is >> what it was). I think any additional overhead >> is inconsequential in the context of creating an OS process. > I don't understand. The overhead is bigger while using a List than for > a simple array. > >> Or if it is, then we should be looking at our List implementations. > If there would be thousands of processes to create, I would agree. > HotSpot would optimize to equivalent performance, but in real world, I > guess, VM's interpreter has to deal with the more overloaded code from > the List stuff. > > > -Ulf > From Ulf.Zibis at gmx.de Tue Apr 19 15:31:38 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 19 Apr 2011 17:31:38 +0200 Subject: Review request for 7034570 - java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited In-Reply-To: <4DADA4AA.8040900@oracle.com> References: <4DA58A18.8080004@oracle.com> <4DA5B125.7030707@gmx.de> <4DA5CD33.50609@oracle.com> <4DA6FF50.7010308@oracle.com> <4DA75F4D.60809@gmx.de> <4DA813A5.5070606@oracle.com> <4DA815C7.2000500@oracle.com> <4DA8260C.6040606@gmx.de> <4DA836E7.8050200@oracle.com> <4DA83DFA.9050207@gmx.de> <4DA84B91.30607@oracle.com> <4DA973EA.6050705@oracle.com> <4DAC384F.8040008@gmx.de> <4DAC4015.6020304@oracle.com> <4DAC9080.3060702@gmx.de> <4DADA4AA.8040900@oracle.com> Message-ID: <4DADAADA.3050608@gmx.de> Thanks for your feedback Michael. One little nit: I guess you have overseen to replace .append("=") by .append('=') Am 19.04.2011 17:05, schrieb Michael McMahon: > Ulf, > > On the usage of List vs [], my point was that the clarity, simplicity and safety > provided by iterating over a Collection out-weighs any performance cost in this case, > as compared with using an array. It makes little difference to > the cost of creating an OS process. > > On moving the SYSTEMROOT constant to be a local variable inside toEnvironmentBlock(), > on balance it probably does look neater. > > Since I have to regenerate the webrev to fix a problem I found with the testcase, I'm including > that change and the change to the comment for emptyEnvironment(). But, at this stage, I have > to move onto other work, and this is the last webrev for this fix, unless someone finds a bug .. So too little time for the switch to inherit ProcessEnvironment from TreeMap. > > http://cr.openjdk.java.net/~michaelm/7034570/webrev.5/ > > Thanks for the work you put into reviewing it. My pleasure! -Ulf From mike.duigou at oracle.com Tue Apr 19 17:48:13 2011 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 19 Apr 2011 17:48:13 +0000 Subject: hg: jdk7/tl/jdk: 7030579: Extra words in documentation of ListIterator may cause confusion Message-ID: <20110419174823.6DAA347C20@hg.openjdk.java.net> Changeset: 495dcc360214 Author: mduigou Date: 2011-04-19 10:47 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/495dcc360214 7030579: Extra words in documentation of ListIterator may cause confusion Reviewed-by: dholmes, alanb ! src/share/classes/java/util/ListIterator.java From mike.duigou at oracle.com Tue Apr 19 22:00:21 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 19 Apr 2011 15:00:21 -0700 Subject: Review : 6546713: Link optional in Collection exception documentation to explanation Message-ID: <2677AA33-5EFC-471C-BD69-DE2ED028BEEC@oracle.com> Hello All; Another collections javadoc review request. This change links the "(optional)" notes in on various Collection methods to text which explains why they are not thrown by all collections. I have not applied the change to java.util.concurrent package javadoc. I will leave the JSR 166 maintainers. http://cr.openjdk.java.net/~mduigou/6546713/0/webrev/ Thanks, Mike From stuart.marks at oracle.com Tue Apr 19 22:35:14 2011 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 19 Apr 2011 15:35:14 -0700 Subject: advice & review requested for 6896297, race condition in rmid causing JCK failure In-Reply-To: <4DA77CB8.8010709@oracle.com> References: <4D9E3867.7030004@oracle.com> <15C8B16F-4EAB-40E0-B926-7882A1D5793C@roundroom.net> <4DA77CB8.8010709@oracle.com> Message-ID: <4DAE0E22.9030707@oracle.com> Hi all, Please review an updated webrev for this bug: http://cr.openjdk.java.net/~smarks/reviews/6896297/webrev.1/ Using ConcurrentHashMap is much nicer in many ways, and it seems to resolve the JCK failures at least as well as the previous fix did. This does nothing to remedy the issue of snapshot consistency, which seems to be covered by 4945726, which we'll postpone (again) to a future release. s'marks On 4/14/11 4:01 PM, Stuart Marks wrote: > Hi Peter, > > Thanks for your comments on this issue. I understand from Alan that you have > some expertise in RMI; it's most welcome here. > > It's good to hear that serialization compatibility isn't that big of a deal. > This makes things easier. It would seem reasonable to investigate replacing > HashMap with ConcurrentHashMap, which would remove a fair bit of the external > locking, and reduce or eliminate the need for a complex locking hierarchy along > with a big comment that describes it. This will also make it easier to retrofit > a coarser locking strategy if necessary; see below. > > Converting instances of HM to CHM if necessary upon deserialization is probably > a good idea and isn't too difficult. > > The larger issue of snapshot consistency is indeed troubling. I'd agree that > the ConcurrentModificationException is a symptom of a larger problem and that > making it go away (either with a different locking strategy or using CHM) is > mostly merely suppressing the symptom without addressing the larger issue. The > immediate need, though, is to fix the JCK failure, so I suspect what I'll need > to do is to push a fix for the CME and handle the resolution of any larger > issue separately. > > I'll investigate an alternative fix that uses CHM instead of modified external > locking, and I'll post an updated webrev. > > s'marks > > > On 4/13/11 11:14 PM, Peter Jones wrote: >> Stuart, >> >> A couple of comments so far: >> >> I don't think that there would be a serialization compatibility problem with >> changing Activation.groupTable to have a ConcurrentHashMap instead of a >> HashMap. The field's declared type is Map, so the deserialization process >> would be able to assign either class to the field, and the code doesn't >> otherwise care about the Map implementation class. An rmid's state created >> with CHM could not be recoverable with JDK 1.4, of course, but I don't think >> that that's a concern. The fix would not help an rmid whose state gets >> recovered from an earlier version created with HM, unless a replacement >> (HM->CHM) was also done upon deserialization. >> >> More troubling I think is the higher-level issue suggested by this >> ConcurrentModificationException. Thread B (in the 6896297 Evaluation) is >> attempting to write a "snapshot" of the entire persistent state of the >> Activation instance, which presumably should be consistent with future >> "updates" written to the log, while Thread A is concurrently attempting to >> mutate that state (before writing an update for its mutation). It seems >> highly doubtful that potentially including an uncertain amount of this >> concurrent mutation in the written snapshot is safe. I might expect a coarser >> lock to be used across all such mutations, together with their associated log >> writes (at which point groupTable wouldn't need to be concurrent). >> >> The approach at your webrev below seems OK to address the immediate >> ConcurrentModificationException, but (unless I'm missing something) the >> higher-level issue with snapshot correctness described above would remain. >> >> Cheers, >> >> -- Peter >> >> P.S. This seems somewhat related to >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4945726 >> >> >> On Apr 7, 2011, at 6:19 PM, Stuart Marks wrote: >> >>> Hi Core-Libs developers, >>> >>> I'd like to solicit some advice and discussion about this bug and a >>> potential fix I'm cooking for it. Here is the bug report; it contains >>> details about the problem and my analysis of it: >>> >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6896297 >>> >>> and here's a webrev of the fix I'm working on: >>> >>> http://cr.openjdk.java.net/~smarks/reviews/6896297/webrev.0/ >>> >>> Briefly, the problem is incorrect synchronization of groupTable, a HashMap >>> field of an Activation object. The code mostly locks groupTable around any >>> access to it. However, no such locking is done during serialization. If the >>> groupTable is modified while it's being serialized, >>> ConcurrentModificationException occurs. >>> >>> The obvious fix would be to use ConcurrentHashMap instead of Hashmap and to >>> remove the external locking entirely. Unfortunately this will change the >>> serialized representation of the Activation object, which I'm not sure is >>> acceptable. >>> >>> Assuming that we can't change the serialized represenation, the alternative >>> approach would be to make sure that locking is done properly during >>> serialization. This is fairly easy to do by locking groupTable in a >>> writeObject() method. Unfortunately, this introduces a deadlock. >>> >>> This deadlock occurs because, with this modification, there are now paths >>> through the code that take locks in the opposite order. Specifically, the >>> addLogRecord() method locks the log object and then (via serialization and >>> the newly added writeObject() method) locks groupTable. However, the >>> unregisterGroup() method locks groupTable and calls >>> GroupEntry.unregisterGroup() which logs the event, which takes a lock on the >>> log. >>> >>> After some analysis, I've determined that the call to >>> GroupEntry.unregisterGroup() can be moved outside the synchronization of >>> groupTable. This removes the ordering problem. >>> >>> With these fixes in place (the state of the webrev above) I can get several >>> hundred successful test runs with neither ConcurrentModificationException >>> nor any deadlocks. >>> >>> Of course, that doesn't mean the change is correct. :-) >>> >>> Questions: >>> >>> 1. Is there a requirement that the serialized form of Activation remain >>> unchanged? If we can change it, we might as well just use ConcurrentHashMap >>> instead of HashMap. >>> >>> 2. Is my lock ordering analysis correct? I've pored over the code, but not >>> really being familiar with any RMI concepts, I'm not sure I have it right. >>> I've written this analysis into a big comment I've added to the code. >>> >>> 3. There is also a potential concurrency issue with idTable, which is used >>> similarly to groupTable. I haven't seen a test failure from it though. It >>> seems sensible to add a lock for it in Activation.writeObject() though. I >>> don't particularly like nesting the locks of idTable and groupTable, but >>> locking them separately would require serializing the Activation object >>> field by field instead of simply using defaultWriteObject(). Is this a >>> reasonable approach? >>> >>> Thanks for any advice or comments. >>> >>> s'marks >>> >> From mike.duigou at oracle.com Wed Apr 20 00:22:02 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 19 Apr 2011 17:22:02 -0700 Subject: Review (Updated) : 4884238 : Constants for Standard Charsets In-Reply-To: <20110419150005.07E98976@eggemoggin.niobe.net> References: <20110419150005.07E98976@eggemoggin.niobe.net> Message-ID: My sentiment is for StandardCharset. I received offlist feedback which would support this. The pattern for enum like collections of constants has been to use the singular form; java.math.RoundingMode, java.lang.annotation.ElementType, javax.lang.model.element.ElementKind, java.lang.management.MemoryType, etc. The NIO 2 / JSR 203 classes use the relatively new naming convention of "Standard" for platform defined constants. java.util.zip.ZipConstants[64] are package private interfaces to define int constants which is against normally recommended practice. Any strong reason to use the plural form? Mike On Apr 19 2011, at 08:00 , mark.reinhold at oracle.com wrote: > 2011/4/19 4:52 -0700, ulf.zibis at gmx.de: >> Am 19.04.2011 00:24, schrieb Mike Duigou: >> Reading 'StandardCharset' one expects _the_ standard charset, but we have a >> collection of 6 here, so I'm for 'StandardCharsets' similar to >> e.g. j.u.z.ZipConstants, j.u.z.ZipConstants64, ... > > I agree. "StandardCharsets" would be a better name. > > - Mark From mike.duigou at oracle.com Wed Apr 20 00:23:41 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 19 Apr 2011 17:23:41 -0700 Subject: Review (Updated) : 4884238 : Constants for Standard Charsets In-Reply-To: <4DAD7762.4000707@gmx.de> References: <4DAD7762.4000707@gmx.de> Message-ID: <12D33A70-593A-40A4-9B33-445D8A8FB6A0@oracle.com> On Apr 19 2011, at 04:52 , Ulf Zibis wrote: > Am 19.04.2011 00:24, schrieb Mike Duigou: >> Hello All; >> >> I have updated the webrev for the standard Charset constants based upon feedback received from the earlier reviews. The constants class is now named StandardCharset rather than Charsets in mimicry of the class naming used by NIO.2 (JSR 203). According to the conventions used by JSR 203 and elsewhere in JDK a "Charsets" class would be for static utility methods rather than solely constants. >> >> The DEFAULT_CHARSET definition is also now removed. The Charset.getDefaultCharset() method makes it more clear that the value is not a constant across all all JVM instances. >> >> Also now included is a small unit test and replacement of several uses of Charset.forname() for standard charset names within the platform. >> >> The latest webrev : >> http://cr.openjdk.java.net/~mduigou/4884238/2/webrev/ >> >> >> Any other remaining feeback? >> >> > > Reading 'StandardCharset' one expects _the_ standard charset, but we have a collection of 6 here, so I'm for 'StandardCharsets' similar to e.g. j.u.z.ZipConstants, j.u.z.ZipConstants64, ... See my response to Mark for the singular vs plural issue. > I think, we should catch the problem at the source. ... In my approach from Bug 100098 - Make sun.nio.cs.* charset objects light-weight such a class is named 'FastCharset'. Unfortunately any we at a very late stage in Java 7's development and the degree of change required by 100098 are not possible. This issue itself may also be rejected solely for missing impending deadlines. I can't comment at all about the prospects for Java 8 as I am not generally involved with charset/unicode work. This issue is a one time involvement with Charset for me. > So I tend to prefer the original request from 4884238 (have the canonical names as constants), as the lookup via Charset.forName(...) then could be very fast compared to the anyway following heavy de/encoding work. I think that in most uses a constant of the Charset is more useful as that's what's desired for use. I am not opposed to having visible constants for the charset names but I don't think it's as useful as the Charset objects. The performance of Charset.forName() is a separate matter. Mike From David.Holmes at oracle.com Wed Apr 20 00:54:31 2011 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 20 Apr 2011 10:54:31 +1000 Subject: Review request for 7034570 - java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited In-Reply-To: <4DADAADA.3050608@gmx.de> References: <4DA58A18.8080004@oracle.com> <4DA5B125.7030707@gmx.de> <4DA5CD33.50609@oracle.com> <4DA6FF50.7010308@oracle.com> <4DA75F4D.60809@gmx.de> <4DA813A5.5070606@oracle.com> <4DA815C7.2000500@oracle.com> <4DA8260C.6040606@gmx.de> <4DA836E7.8050200@oracle.com> <4DA83DFA.9050207@gmx.de> <4DA84B91.30607@oracle.com> <4DA973EA.6050705@oracle.com> <4DAC384F.8040008@gmx.de> <4DAC4015.6020304@oracle.com> <4DAC9080.3060702@gmx.de> <4DADA4AA.8040900@oracle.com> <4DADAADA.3050608@gmx.de> Message-ID: <4DAE2EC7.9010600@oracle.com> Ulf Zibis said the following on 04/20/11 01:31: > Thanks for your feedback Michael. > > One little nit: > I guess you have overseen to replace .append("=") by .append('=') +1 Otherwise all looks good. Thanks Michael. David > > Am 19.04.2011 17:05, schrieb Michael McMahon: >> Ulf, >> >> On the usage of List vs [], my point was that the clarity, simplicity >> and safety >> provided by iterating over a Collection out-weighs any performance >> cost in this case, >> as compared with using an array. It makes little difference to >> the cost of creating an OS process. >> >> On moving the SYSTEMROOT constant to be a local variable inside >> toEnvironmentBlock(), >> on balance it probably does look neater. >> >> Since I have to regenerate the webrev to fix a problem I found with >> the testcase, I'm including >> that change and the change to the comment for emptyEnvironment(). But, >> at this stage, I have >> to move onto other work, and this is the last webrev for this fix, >> unless someone finds a bug .. > > So too little time for the switch to inherit ProcessEnvironment from > TreeMap. > >> >> http://cr.openjdk.java.net/~michaelm/7034570/webrev.5/ >> >> Thanks for the work you put into reviewing it. > > My pleasure! > > -Ulf > > From David.Holmes at oracle.com Wed Apr 20 01:07:04 2011 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 20 Apr 2011 11:07:04 +1000 Subject: Review : 6546713: Link optional in Collection exception documentation to explanation In-Reply-To: <2677AA33-5EFC-471C-BD69-DE2ED028BEEC@oracle.com> References: <2677AA33-5EFC-471C-BD69-DE2ED028BEEC@oracle.com> Message-ID: <4DAE31B8.7010507@oracle.com> Hi Mike, Mike Duigou said the following on 04/20/11 08:00: > Hello All; > > Another collections javadoc review request. This change links the "(optional)" notes in on various Collection methods to text which explains why they are not thrown by all collections. Generally looks good. I think you should revert this additional change in Collection.java: ! * @throws NullPointerException if the specified array is {@code null} "null" is used all over the place without being code font, including other @throws NullPointerException. > I have not applied the change to java.util.concurrent package javadoc. I will leave the JSR 166 maintainers. Yeah well ... on behalf of them can I twist your arm? If it isn't done now it needs another CR, etc etc. Appears to be 22 cases across 4 classes. Maybe I can generate the patch for you ... :) Cheers, David > http://cr.openjdk.java.net/~mduigou/6546713/0/webrev/ > > Thanks, > > Mike From mike.duigou at oracle.com Wed Apr 20 01:31:57 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 19 Apr 2011 18:31:57 -0700 Subject: Review : 6546713: Link optional in Collection exception documentation to explanation In-Reply-To: <4DAE31B8.7010507@oracle.com> References: <2677AA33-5EFC-471C-BD69-DE2ED028BEEC@oracle.com> <4DAE31B8.7010507@oracle.com> Message-ID: Not a problem on both counts. I will update the webrev shortly. Revised webrev, when it appears, will be at: http://cr.openjdk.java.net/~mduigou/6546713/1/webrev/ Mike On Apr 19 2011, at 18:07 , David Holmes wrote: > Hi Mike, > > Mike Duigou said the following on 04/20/11 08:00: >> Hello All; >> Another collections javadoc review request. This change links the "(optional)" notes in on various Collection methods to text which explains why they are not thrown by all collections. > > Generally looks good. I think you should revert this additional change in Collection.java: > > ! * @throws NullPointerException if the specified array is {@code null} > > "null" is used all over the place without being code font, including other @throws NullPointerException. > >> I have not applied the change to java.util.concurrent package javadoc. I will leave the JSR 166 maintainers. > > Yeah well ... on behalf of them can I twist your arm? If it isn't done now it needs another CR, etc etc. Appears to be 22 cases across 4 classes. Maybe I can generate the patch for you ... :) > > Cheers, > David > >> http://cr.openjdk.java.net/~mduigou/6546713/0/webrev/ >> Thanks, >> Mike From forax at univ-mlv.fr Wed Apr 20 01:34:46 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 20 Apr 2011 03:34:46 +0200 Subject: Review (Updated) : 4884238 : Constants for Standard Charsets In-Reply-To: References: <20110419150005.07E98976@eggemoggin.niobe.net> Message-ID: <4DAE3836.4080606@univ-mlv.fr> On 04/20/2011 02:22 AM, Mike Duigou wrote: > My sentiment is for StandardCharset. > > I received offlist feedback which would support this. The pattern for enum like collections of constants has been to use the singular form; java.math.RoundingMode, java.lang.annotation.ElementType, javax.lang.model.element.ElementKind, java.lang.management.MemoryType, etc. > > The NIO 2 / JSR 203 classes use the relatively new naming convention of "Standard" for platform defined constants. > > java.util.zip.ZipConstants[64] are package private interfaces to define int constants which is against normally recommended practice. > > Any strong reason to use the plural form? It's the classical question "how to name an enum class ?" If you consider that it contains several constants you will use the plural form, if you consider it as a kind of namespace for a constant, you will use the singular form. From my experience, the singular form is used more than the plural form. > Mike cheers R?mi From weijun.wang at oracle.com Wed Apr 20 11:03:30 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Wed, 20 Apr 2011 11:03:30 +0000 Subject: hg: jdk7/tl/jdk: 6894072: always refresh keytab Message-ID: <20110420110354.6127847C66@hg.openjdk.java.net> Changeset: f8956ba13b37 Author: weijun Date: 2011-04-20 18:41 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f8956ba13b37 6894072: always refresh keytab Reviewed-by: valeriep ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java + src/share/classes/javax/security/auth/kerberos/JavaxSecurityAuthKerberosAccessImpl.java ! src/share/classes/javax/security/auth/kerberos/KerberosKey.java + src/share/classes/javax/security/auth/kerberos/KeyTab.java + src/share/classes/sun/misc/JavaxSecurityAuthKerberosAccess.java ! src/share/classes/sun/misc/SharedSecrets.java ! src/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java ! src/share/classes/sun/security/jgss/krb5/Krb5Util.java ! src/share/classes/sun/security/jgss/krb5/SubjectComber.java ! src/share/classes/sun/security/krb5/Config.java ! src/share/classes/sun/security/krb5/EncryptionKey.java ! src/share/classes/sun/security/krb5/KrbAsRep.java ! src/share/classes/sun/security/krb5/KrbAsReqBuilder.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! src/share/classes/sun/security/ssl/krb5/Krb5ProxyImpl.java ! src/windows/classes/sun/security/krb5/internal/tools/Kinit.java ! src/windows/classes/sun/security/krb5/internal/tools/Klist.java ! src/windows/classes/sun/security/krb5/internal/tools/Ktab.java ! test/sun/security/krb5/auto/Context.java + test/sun/security/krb5/auto/DynamicKeytab.java ! test/sun/security/krb5/auto/KDC.java + test/sun/security/krb5/auto/KeyTabCompat.java ! test/sun/security/krb5/auto/LoginModuleOptions.java ! test/sun/security/krb5/auto/SSL.java + test/sun/security/krb5/auto/TwoPrinces.java ! test/sun/security/krb5/ktab/KeyTabIndex.java From michael.x.mcmahon at oracle.com Wed Apr 20 11:06:08 2011 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Wed, 20 Apr 2011 11:06:08 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20110420110627.BF53047C68@hg.openjdk.java.net> Changeset: ed01737a2e9a Author: michaelm Date: 2011-04-20 12:03 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ed01737a2e9a 7034570: java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited Reviewed-by: dholmes, alanb ! src/share/classes/java/lang/ProcessBuilder.java ! src/share/classes/java/lang/Runtime.java ! src/windows/classes/java/lang/ProcessEnvironment.java ! test/java/lang/ProcessBuilder/Basic.java Changeset: 31aa8c35a4df Author: michaelm Date: 2011-04-20 12:05 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/31aa8c35a4df Merge From dl at cs.oswego.edu Wed Apr 20 11:41:37 2011 From: dl at cs.oswego.edu (Doug Lea) Date: Wed, 20 Apr 2011 07:41:37 -0400 Subject: Review : 6546713: Link optional in Collection exception documentation to explanation In-Reply-To: <4DAE31B8.7010507@oracle.com> References: <2677AA33-5EFC-471C-BD69-DE2ED028BEEC@oracle.com> <4DAE31B8.7010507@oracle.com> Message-ID: <4DAEC671.2000205@cs.oswego.edu> On 04/19/11 21:07, David Holmes wrote: > Hi Mike, > > Mike Duigou said the following on 04/20/11 08:00: >> Hello All; >> >> Another collections javadoc review request. This change links the "(optional)" >> notes in on various Collection methods to text which explains why they are not >> thrown by all collections. > > Generally looks good. I think you should revert this additional change in > Collection.java: > > ! * @throws NullPointerException if the specified array is {@code null} > > "null" is used all over the place without being code font, including other > @throws NullPointerException. This, along with literals "true" and "false" are not code-fonted very consistently. Someday someone should do a big consistency pass across the whole code base. > >> I have not applied the change to java.util.concurrent package javadoc. I will >> leave the JSR 166 maintainers. > > Yeah well ... on behalf of them can I twist your arm? If it isn't done now it > needs another CR, etc etc. Appears to be 22 cases across 4 classes. Maybe I can > generate the patch for you ... :) This is probably easier if we (jsr166) do it, because we have jsr166->OpenJDK integration paths semi-automated, but not vice versa. -Doug From Ulf.Zibis at gmx.de Wed Apr 20 11:47:03 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Wed, 20 Apr 2011 13:47:03 +0200 Subject: Review (Updated) : 4884238 : Constants for Standard Charsets In-Reply-To: <12D33A70-593A-40A4-9B33-445D8A8FB6A0@oracle.com> References: <4DAD7762.4000707@gmx.de> <12D33A70-593A-40A4-9B33-445D8A8FB6A0@oracle.com> Message-ID: <4DAEC7B7.7000602@gmx.de> Am 20.04.2011 02:23, schrieb Mike Duigou: > On Apr 19 2011, at 04:52 , Ulf Zibis wrote: >> I think, we should catch the problem at the source. ... In my approach from Bug 100098 - Make sun.nio.cs.* charset objects light-weight such a class is named 'FastCharset'. > Unfortunately any we at a very late stage in Java 7's development and the degree of change required by 100098 are not possible. Yes, that's right. For that reason I have suggested an intermediate solution to avoid the additional, later not removable StandardCharset(s) class. > This issue itself may also be rejected solely for missing impending deadlines. Should there something be done for that? >> So I tend to prefer the original request from 4884238 (have the canonical names as constants), as the lookup via Charset.forName(...) then could be very fast compared to the anyway following heavy de/encoding work. > I think that in most uses a constant of the Charset is more useful as that's what's desired for use. I am not opposed to having visible constants for the charset names but I don't think it's as useful as the Charset objects. The performance of Charset.forName() is a separate matter. Thinking more I agree to some direct access to the standard charsets, because Charset.forName(..) potentially needs extra exception handling. But is there a must for static constants? I think we could have lazy initialized static methods, so (1) only the Charset class of request should be loaded, (2) separate StandardCharset(s) class and discussion about the naming becomes superfluous, (3) the small short cut cache in Charset remains it's proper function (otherwise the last 2, UTF_16BE, UTF_16LE are cached), and (4) we could profit from it in Charset.defaultCharset() for the fall-back case: 622 defaultCharset = UTF_8(); I still think, we should have constants for the canonical charset names: Charset.UTF_8 = "UTF-8"; etc... Additionally consider, that in many real world cases not the charset, but it's de/encoder is of interest, so the programmer anyway needs to define a static constant, if for performance reason it should be reused: static final CharsetDecoder UTF_8_DECODER = UTF_8.newDecoder(); Here my new suggestion: public abstract class Charset implements Comparable { static final String UTF_8 = "UTF-8"; ... static final Charset UTF_8() { return forName(UTF_8); // Note that recently used charsets are hold in a small short cut cache. } ... } -Ulf From Lance.Andersen at oracle.com Wed Apr 20 12:07:31 2011 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Wed, 20 Apr 2011 08:07:31 -0400 Subject: Review : 6546713: Link optional in Collection exception documentation to explanation In-Reply-To: <4DAEC671.2000205@cs.oswego.edu> References: <2677AA33-5EFC-471C-BD69-DE2ED028BEEC@oracle.com> <4DAE31B8.7010507@oracle.com> <4DAEC671.2000205@cs.oswego.edu> Message-ID: On Apr 20, 2011, at 7:41 AM, Doug Lea wrote: > On 04/19/11 21:07, David Holmes wrote: >> Hi Mike, >> >> Mike Duigou said the following on 04/20/11 08:00: >>> Hello All; >>> >>> Another collections javadoc review request. This change links the "(optional)" >>> notes in on various Collection methods to text which explains why they are not >>> thrown by all collections. >> >> Generally looks good. I think you should revert this additional change in >> Collection.java: >> >> ! * @throws NullPointerException if the specified array is {@code null} >> >> "null" is used all over the place without being code font, including other >> @throws NullPointerException. > > This, along with literals "true" and "false" are not code-fonted > very consistently. Someday someone should do a big consistency pass > across the whole code base. Perhaps we can document what we believe the standards should be WRT when to use {@code} . I am sure I have clean up to do throughout the JDBC as well for consistency in this area Regards, Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From Alan.Bateman at oracle.com Wed Apr 20 16:00:32 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 20 Apr 2011 17:00:32 +0100 Subject: advice & review requested for 6896297, race condition in rmid causing JCK failure In-Reply-To: <4DAE0E22.9030707@oracle.com> References: <4D9E3867.7030004@oracle.com> <15C8B16F-4EAB-40E0-B926-7882A1D5793C@roundroom.net> <4DA77CB8.8010709@oracle.com> <4DAE0E22.9030707@oracle.com> Message-ID: <4DAF0320.4050605@oracle.com> Stuart Marks wrote: > Hi all, > > Please review an updated webrev for this bug: > > http://cr.openjdk.java.net/~smarks/reviews/6896297/webrev.1/ > > Using ConcurrentHashMap is much nicer in many ways, and it seems to > resolve the JCK failures at least as well as the previous fix did. > This does nothing to remedy the issue of snapshot consistency, which > seems to be covered by 4945726, which we'll postpone (again) to a > future release. > > This is nicer and apologies for raising the concern about serialization compatibility - I incorrectly thought that these tables were declared as HashMaps. At L242 you might want to include a comment to remind a future maintainer why it's a zero length array rather than using size(). -Alan. From stuart.marks at oracle.com Wed Apr 20 17:50:49 2011 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 20 Apr 2011 10:50:49 -0700 Subject: advice & review requested for 6896297, race condition in rmid causing JCK failure In-Reply-To: <4DAF0320.4050605@oracle.com> References: <4D9E3867.7030004@oracle.com> <15C8B16F-4EAB-40E0-B926-7882A1D5793C@roundroom.net> <4DA77CB8.8010709@oracle.com> <4DAE0E22.9030707@oracle.com> <4DAF0320.4050605@oracle.com> Message-ID: <4DAF1CF9.4060200@oracle.com> On 4/20/11 9:00 AM, Alan Bateman wrote: > Stuart Marks wrote: >> Hi all, >> >> Please review an updated webrev for this bug: >> >> http://cr.openjdk.java.net/~smarks/reviews/6896297/webrev.1/ >> >> Using ConcurrentHashMap is much nicer in many ways, and it seems to resolve >> the JCK failures at least as well as the previous fix did. This does nothing >> to remedy the issue of snapshot consistency, which seems to be covered by >> 4945726, which we'll postpone (again) to a future release. >> >> > This is nicer and apologies for raising the concern about serialization > compatibility - I incorrectly thought that these tables were declared as HashMaps. > > At L242 you might want to include a comment to remind a future maintainer why > it's a zero length array rather than using size(). Yes, good idea; I had puzzled over this a bit myself and indeed I had gotten it wrong the first time. I'll add a comment and push the fix. s'marks From mike.duigou at oracle.com Wed Apr 20 18:29:40 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 20 Apr 2011 11:29:40 -0700 Subject: Review : 6546713: Link optional in Collection exception documentation to explanation In-Reply-To: References: <2677AA33-5EFC-471C-BD69-DE2ED028BEEC@oracle.com> <4DAE31B8.7010507@oracle.com> Message-ID: <1A708078-476B-4E57-A3E2-C4CA3D0B0F24@oracle.com> The webrev is now updated with the suggested changes. Doug Lea has already committed the cooresponding changes for the java.util.concurrent package to the jsr 166 CVS. Mike On Apr 19 2011, at 18:31 , Mike Duigou wrote: > Not a problem on both counts. I will update the webrev shortly. Revised webrev, when it appears, will be at: > > http://cr.openjdk.java.net/~mduigou/6546713/1/webrev/ > > Mike > > On Apr 19 2011, at 18:07 , David Holmes wrote: > >> Hi Mike, >> >> Mike Duigou said the following on 04/20/11 08:00: >>> Hello All; >>> Another collections javadoc review request. This change links the "(optional)" notes in on various Collection methods to text which explains why they are not thrown by all collections. >> >> Generally looks good. I think you should revert this additional change in Collection.java: >> >> ! * @throws NullPointerException if the specified array is {@code null} >> >> "null" is used all over the place without being code font, including other @throws NullPointerException. >> >>> I have not applied the change to java.util.concurrent package javadoc. I will leave the JSR 166 maintainers. >> >> Yeah well ... on behalf of them can I twist your arm? If it isn't done now it needs another CR, etc etc. Appears to be 22 cases across 4 classes. Maybe I can generate the patch for you ... :) >> >> Cheers, >> David >> >>> http://cr.openjdk.java.net/~mduigou/6546713/0/webrev/ >>> Thanks, >>> Mike > From pcj at roundroom.net Wed Apr 20 18:37:27 2011 From: pcj at roundroom.net (Peter Jones) Date: Wed, 20 Apr 2011 14:37:27 -0400 Subject: advice & review requested for 6896297, race condition in rmid causing JCK failure In-Reply-To: <4DAE0E22.9030707@oracle.com> References: <4D9E3867.7030004@oracle.com> <15C8B16F-4EAB-40E0-B926-7882A1D5793C@roundroom.net> <4DA77CB8.8010709@oracle.com> <4DAE0E22.9030707@oracle.com> Message-ID: <5C87F9E2-F789-4C9F-BB14-F4EF56B963DA@roundroom.net> Hi Stuart, On Apr 19, 2011, at 6:35 PM, Stuart Marks wrote: > Please review an updated webrev for this bug: > > http://cr.openjdk.java.net/~smarks/reviews/6896297/webrev.1/ > > Using ConcurrentHashMap is much nicer in many ways, and it seems to resolve the JCK failures at least as well as the previous fix did. These changes look good to me. > This does nothing to remedy the issue of snapshot consistency, which seems to be covered by 4945726, which we'll postpone (again) to a future release. > On 4/14/11 4:01 PM, Stuart Marks wrote: >> >> The larger issue of snapshot consistency is indeed troubling. I'd agree that >> the ConcurrentModificationException is a symptom of a larger problem and that >> making it go away (either with a different locking strategy or using CHM) is >> mostly merely suppressing the symptom without addressing the larger issue. The >> immediate need, though, is to fix the JCK failure, so I suspect what I'll need >> to do is to push a fix for the CME and handle the resolution of any larger >> issue separately. Understood, makes sense. Cheers, -- Peter From stuart.marks at oracle.com Wed Apr 20 23:58:08 2011 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Wed, 20 Apr 2011 23:58:08 +0000 Subject: hg: jdk7/tl/jdk: 6896297: (rmi) fix ConcurrentModificationException causing TCK failure Message-ID: <20110420235818.E681B47CC1@hg.openjdk.java.net> Changeset: 00f3997e6aeb Author: smarks Date: 2011-04-20 16:30 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/00f3997e6aeb 6896297: (rmi) fix ConcurrentModificationException causing TCK failure Reviewed-by: alanb, dholmes, peterjones ! src/share/classes/sun/rmi/log/ReliableLog.java ! src/share/classes/sun/rmi/server/Activation.java From mike.duigou at oracle.com Thu Apr 21 00:20:20 2011 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Thu, 21 Apr 2011 00:20:20 +0000 Subject: hg: jdk7/tl/jdk: 6546713: link the word (optional) in exception specifications to the text which provides explanation and context. Message-ID: <20110421002029.D473647CC5@hg.openjdk.java.net> Changeset: d5a7ed4e72a4 Author: mduigou Date: 2011-04-20 17:20 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d5a7ed4e72a4 6546713: link the word (optional) in exception specifications to the text which provides explanation and context. Reviewed-by: dholmes, dl ! src/share/classes/java/util/AbstractSet.java ! src/share/classes/java/util/ArrayList.java ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/Deque.java ! src/share/classes/java/util/List.java ! src/share/classes/java/util/Map.java ! src/share/classes/java/util/Set.java ! src/share/classes/java/util/Vector.java From lana.steuck at oracle.com Thu Apr 21 01:11:48 2011 From: lana.steuck at oracle.com (Lana Steuck) Date: Wed, 20 Apr 2011 18:11:48 -0700 Subject: TL/Client bug fixes after May 2 will require approval - b142 is the last JCG integration before Rampdown Phase 2 Start Message-ID: <4DAF8454.90003@oracle.com> To: TL and 2d, Awt, I18n, Swing Jdk7 Developers (Internal and External) What: b142 is the last TL/Client integration before Rampdown Phase 2 Start (RDP2) When: Mon, May 2 at 12PM PT PIT deadline for b142 is Mon, May 2 at 12PM PT (integrating on Tue, May 10). Any changes pushed to TL, 2d, Awt, I18n, and Swing forests after Mon, May 2, will require Release Team approval. For external developers, this means that someone from Oracle Jdk7 Engineering would need to file an approval request and advocate for their change. Regards, - Lana From chris.hegarty at oracle.com Thu Apr 21 12:54:50 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 21 Apr 2011 12:54:50 +0000 Subject: hg: jdk7/tl/jdk: 7038501: Clarify meaning of "(optional)" in javadoc Message-ID: <20110421125518.A7C5A47D2E@hg.openjdk.java.net> Changeset: 7fd31e477313 Author: dl Date: 2011-04-21 13:53 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7fd31e477313 7038501: Clarify meaning of "(optional)" in javadoc Reviewed-by: chegar ! src/share/classes/java/util/concurrent/BlockingDeque.java ! src/share/classes/java/util/concurrent/BlockingQueue.java ! src/share/classes/java/util/concurrent/ConcurrentMap.java ! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java From vincent.x.ryan at oracle.com Thu Apr 21 13:26:15 2011 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Thu, 21 Apr 2011 13:26:15 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20110421132635.CB23447D34@hg.openjdk.java.net> Changeset: 7cd0403492b6 Author: vinnie Date: 2011-04-21 14:23 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7cd0403492b6 6888925: SunMSCAPI's Cipher can't use RSA public keys obtained from other sources. Reviewed-by: mullan ! src/windows/classes/sun/security/mscapi/RSACipher.java ! src/windows/classes/sun/security/mscapi/RSAPublicKey.java ! src/windows/classes/sun/security/mscapi/RSASignature.java + test/sun/security/mscapi/PublicKeyInterop.java + test/sun/security/mscapi/PublicKeyInterop.sh Changeset: 401ef8c488e0 Author: vinnie Date: 2011-04-21 14:25 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/401ef8c488e0 Merge From chris.hegarty at oracle.com Thu Apr 21 16:01:18 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 21 Apr 2011 16:01:18 +0000 Subject: hg: jdk7/tl/jdk: 7038542: Small performace regression in ConcurrentHashMap on c1 since CR 703655 Message-ID: <20110421160129.A244C47D4A@hg.openjdk.java.net> Changeset: e9ec52c63a9f Author: dl Date: 2011-04-21 17:00 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e9ec52c63a9f 7038542: Small performace regression in ConcurrentHashMap on c1 since CR 703655 Reviewed-by: chegar ! src/share/classes/java/util/concurrent/ConcurrentHashMap.java From vincent.x.ryan at oracle.com Thu Apr 21 18:09:05 2011 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Thu, 21 Apr 2011 18:09:05 +0000 Subject: hg: jdk7/tl/jdk: 6732372: Some MSCAPI native methods not returning correct exceptions. Message-ID: <20110421180915.D495147D59@hg.openjdk.java.net> Changeset: 69fead598c1b Author: vinnie Date: 2011-04-21 19:05 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/69fead598c1b 6732372: Some MSCAPI native methods not returning correct exceptions. Reviewed-by: mullan ! src/share/classes/sun/security/ec/ECKeyPairGenerator.java ! src/windows/classes/sun/security/mscapi/KeyStore.java ! src/windows/classes/sun/security/mscapi/RSACipher.java ! src/windows/classes/sun/security/mscapi/RSAKeyPairGenerator.java ! src/windows/classes/sun/security/mscapi/RSAPublicKey.java ! src/windows/classes/sun/security/mscapi/RSASignature.java ! src/windows/native/sun/security/mscapi/security.cpp From lana.steuck at oracle.com Thu Apr 21 20:35:36 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 21 Apr 2011 20:35:36 +0000 Subject: hg: jdk7/tl/hotspot: 46 new changesets Message-ID: <20110421203701.787E147D6D@hg.openjdk.java.net> Changeset: c2323e2ea62b Author: never Date: 2011-03-31 21:05 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c2323e2ea62b 6385687: UseFastEmptyMethods/UseFastAccessorMethods considered harmful Reviewed-by: kvn, jrose, phh ! src/share/vm/prims/jvmtiManageCapabilities.cpp ! src/share/vm/runtime/globals.hpp Changeset: f8b038506985 Author: never Date: 2011-04-01 21:45 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f8b038506985 6909440: C2 fails with assertion (_always_cold->is_cold(),"must always be cold") Reviewed-by: kvn ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp Changeset: 07acc51c1d2a Author: kvn Date: 2011-04-02 09:49 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/07acc51c1d2a 7032314: Allow to generate CallLeafNoFPNode in IdealKit Summary: Added CallLeafNoFPNode generation to IdealKit. Added i_o synchronization. Reviewed-by: never ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/idealKit.hpp ! src/share/vm/opto/library_call.cpp Changeset: 08eb13460b3a Author: kvn Date: 2011-04-02 10:54 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/08eb13460b3a 7004535: Clone loop predicate during loop unswitch Summary: Clone loop predicate for clonned loops Reviewed-by: never ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/ifnode.cpp + src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopUnswitch.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/split_if.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/vectornode.hpp Changeset: 13bc79b5c9c8 Author: roland Date: 2011-04-03 12:00 +0200 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/13bc79b5c9c8 7033154: Improve C1 arraycopy performance Summary: better static analysis. Take advantage of array copy stubs. Reviewed-by: never ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/c1/c1_Runtime1.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp Changeset: e863062e521d Author: twisti Date: 2011-04-04 03:02 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e863062e521d 7032458: Zero and Shark fixes Reviewed-by: twisti Contributed-by: Gary Benson ! src/cpu/zero/vm/globals_zero.hpp ! src/cpu/zero/vm/relocInfo_zero.cpp ! src/cpu/zero/vm/sharedRuntime_zero.cpp ! src/share/vm/ci/ciTypeFlow.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/shark/sharkCompiler.cpp ! src/share/vm/shark/sharkCompiler.hpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/globalDefinitions_gcc.hpp Changeset: 8b2317d732ec Author: never Date: 2011-04-04 12:57 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8b2317d732ec 7026957: assert(type2aelembytes(store->as_Mem()->memory_type(), true) == 1 << shift->in(2)->get_int()) failed Reviewed-by: kvn, jrose ! src/share/vm/opto/loopTransform.cpp Changeset: bb22629531fa Author: iveresov Date: 2011-04-04 16:00 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/bb22629531fa 7033732: C1: When calling c2 arraycopy stubs offsets and length must have clear upper 32bits Summary: With 7033154 we started calling c2 arraycopy stubs from c1. On sparcv9 we must clear the upper 32bits for offset (src_pos, dst_pos) and length parameters when calling them. Reviewed-by: never, kvn ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp Changeset: a54519951ff6 Author: iveresov Date: 2011-04-04 18:48 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a54519951ff6 Merge Changeset: 87ce328c6a21 Author: never Date: 2011-04-04 19:03 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/87ce328c6a21 6528013: C1 CTW failure with -XX:+VerifyOops assert(allocates2(pc),"") Reviewed-by: kvn, iveresov ! src/share/vm/c1/c1_LIRAssembler.cpp Changeset: fb37e3eabfd0 Author: never Date: 2011-04-04 22:17 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/fb37e3eabfd0 Merge Changeset: d7a3fed1c1c9 Author: kvn Date: 2011-04-04 19:02 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/d7a3fed1c1c9 7004547: regular loop unroll should not unroll more than max unrolling Summary: Take into account that after unroll conjoined heads and tails will fold. Reviewed-by: never ! src/share/vm/opto/loopTransform.cpp Changeset: 03f2be00fa21 Author: kvn Date: 2011-04-05 00:27 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/03f2be00fa21 Merge Changeset: 479b4b4b6950 Author: never Date: 2011-04-05 00:31 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/479b4b4b6950 6777083: assert(target != __null,"must not be null") Reviewed-by: iveresov, kvn ! src/cpu/x86/vm/assembler_x86.hpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/code/relocInfo.hpp Changeset: 8e77e1f26188 Author: never Date: 2011-04-05 02:31 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8e77e1f26188 Merge Changeset: 527977d4f740 Author: never Date: 2011-04-05 19:16 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/527977d4f740 7033779: CodeCache::largest_free_block may need to hold the CodeCache lock Reviewed-by: kvn ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp Changeset: 98c560260039 Author: never Date: 2011-04-06 16:02 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/98c560260039 7034513: enable fast accessors and empty methods for ZERO and -Xint Reviewed-by: kvn, iveresov ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 55973726c600 Author: kvn Date: 2011-04-06 17:32 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/55973726c600 6992789: assert(phi->_idx >= nodes_size()) failed: only new Phi per instance memory slice Summary: Swap checks: check for regular memory slice first and keep input phi. Reviewed-by: never ! src/share/vm/opto/escape.cpp Changeset: ed69575596ac Author: jrose Date: 2011-04-07 17:02 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ed69575596ac 6981791: remove experimental code for JSR 292 Reviewed-by: twisti ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/ClassConstants.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/ConstantTag.java ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/javaClasses.cpp ! 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/interpreter/bytecodeTracer.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/cpCacheOop.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/constantTag.cpp ! src/share/vm/utilities/constantTag.hpp Changeset: 758ba0bf7bcc Author: jrose Date: 2011-04-07 17:12 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/758ba0bf7bcc 7012087: JSR 292 Misleading exception message for a non-bound MH for a virtual method Summary: Improve error message formatting to give more information to user. Also, catch a corner case related to 6930553 and 6844449. Reviewed-by: kvn ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 4124a5a27707 Author: jrose Date: 2011-04-07 17:12 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4124a5a27707 7009600: JSR 292 Server compiler crashes in Compile::find_intrinsic(ciMethod*, bool) Summary: catch errors during the compile-time processing of method handles; back out cleanly Reviewed-by: twisti ! src/share/vm/ci/ciMethodHandle.cpp ! src/share/vm/opto/doCall.cpp Changeset: 3f49d30f8184 Author: never Date: 2011-04-07 21:32 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3f49d30f8184 7034957: acquiring lock CodeCache_lock/1 out of order with lock tty_lock/0 -- possible deadlock Reviewed-by: iveresov ! src/share/vm/code/codeCache.cpp Changeset: d86923d96dca Author: iveresov Date: 2011-04-08 17:03 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/d86923d96dca 7034967: C1: assert(false) failed: error (assembler_sparc.cpp:2043) Summary: Fix -XX:+VerifyOops Reviewed-by: kvn, never ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: 3af54845df98 Author: kvn Date: 2011-04-08 14:56 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3af54845df98 7004555: Add new policy for one iteration loops Summary: Add new policy for one iteration loops (mostly formal pre- loops). Reviewed-by: never ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp Changeset: 46d145ee8e68 Author: kvn Date: 2011-04-08 20:52 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/46d145ee8e68 Merge Changeset: 3fa3c7e4d4f3 Author: never Date: 2011-04-08 23:00 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3fa3c7e4d4f3 7035161: assert(!o->is_null_object()) failed: null object not yet handled here. Reviewed-by: kvn ! src/share/vm/ci/ciInstance.cpp Changeset: 6c97c830fb6f Author: jrose Date: 2011-04-09 21:16 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6c97c830fb6f Merge ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/code/relocInfo.hpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/idealKit.hpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopUnswitch.cpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/globalDefinitions_gcc.hpp Changeset: 677234770800 Author: dsamersoff Date: 2011-03-30 19:38 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/677234770800 7017193: Small memory leak in get_stack_bounds os::create_stack_guard_pages Summary: getline() returns -1 but still allocate memory for str Reviewed-by: dcubed, coleenp ! src/os/linux/vm/os_linux.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp Changeset: b025bffd6c2c Author: dholmes Date: 2011-03-31 06:54 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b025bffd6c2c 7032775: Include Shark code in the build again Reviewed-by: ohair Contributed-by: gbenson at redhat.com, ahughes at redhat.com ! make/linux/makefiles/vm.make Changeset: 37be97a58393 Author: andrew Date: 2011-04-01 15:15 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/37be97a58393 7010849: 5/5 Extraneous javac source/target options when building sa-jdi Summary: Make code changes necessary to get rid of the '-source 1.4 -target 1.4' options. Reviewed-by: dholmes, dcubed ! agent/src/share/classes/sun/jvm/hotspot/HelloWorld.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/ByteValueImpl.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/CharValueImpl.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/ConnectorImpl.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/DoubleValueImpl.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/FieldImpl.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/FloatValueImpl.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/IntegerValueImpl.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/LocalVariableImpl.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/LocationImpl.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/LongValueImpl.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/MethodImpl.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/ReferenceTypeImpl.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/ShortValueImpl.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/VirtualMachineImpl.java ! make/linux/makefiles/sa.make ! make/solaris/makefiles/sa.make ! make/windows/makefiles/sa.make Changeset: 7144a1d6e0a9 Author: kamg Date: 2011-03-31 08:08 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7144a1d6e0a9 7030388: JCK test failed to reject invalid class check01304m10n. Summary: Restrict fix for 7020118 to only when checking exception handlers Reviewed-by: dcubed, dholmes ! src/share/vm/classfile/stackMapFrame.cpp ! src/share/vm/classfile/stackMapFrame.hpp ! src/share/vm/classfile/stackMapTable.cpp Changeset: 11427f216063 Author: dholmes Date: 2011-04-04 18:15 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/11427f216063 7009276: Add -XX:+IgnoreUnrecognizedVMOptions to several tests Reviewed-by: kvn ! test/compiler/6795161/Test.java Changeset: 1dac0f3af89f Author: ohair Date: 2011-04-07 20:26 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1dac0f3af89f 7019210: Fix misc references to /bugreport websites Reviewed-by: skannan ! src/share/vm/runtime/arguments.cpp Changeset: c49c3947b98a Author: brutisso Date: 2011-04-11 11:12 +0200 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c49c3947b98a 7034625: Product builds in Visual Studio projects should produce full symbol information Summary: Add the /debug flag to the linker command in Visual Studio Reviewed-by: mgronlun, poonam, hosterda ! src/share/tools/ProjectCreator/WinGammaPlatformVC10.java Changeset: 6a615eae2f34 Author: dholmes Date: 2011-04-12 02:53 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6a615eae2f34 7034585: Adjust fillInStackTrace filtering to assist 6998871 Summary: Allow for one or more fillInStackTrace frames to be skipped Reviewed-by: mchung, kvn ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/vmSymbols.hpp Changeset: 3449f5e02cc4 Author: coleenp Date: 2011-04-12 14:18 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3449f5e02cc4 Merge ! make/linux/makefiles/vm.make ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/stackMapFrame.cpp ! src/share/vm/classfile/stackMapFrame.hpp ! src/share/vm/classfile/stackMapTable.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/arguments.cpp Changeset: 328926869b15 Author: jrose Date: 2011-04-09 22:55 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/328926869b15 6987991: JSR 292 phpreboot test/testtracefun2.phpr segfaults Summary: Make MH verification tests more correct, robust, and informative. Fix lingering symbol refcount problems. Reviewed-by: twisti ! src/share/vm/oops/methodOop.cpp ! src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp Changeset: 15c9a0e16269 Author: kvn Date: 2011-04-11 15:30 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/15c9a0e16269 7035713: 3DNow Prefetch Instruction Support Summary: The upcoming processors from AMD are the first that support 3dnow prefetch without supporting the 3dnow instruction set. Reviewed-by: kvn Contributed-by: tom.deneau at amd.com ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/cpu/x86/vm/x86_32.ad Changeset: 4b95bbb36464 Author: twisti Date: 2011-04-12 02:40 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4b95bbb36464 7035870: JSR 292: Zero support Summary: This adds support for JSR 292 to Zero. Reviewed-by: twisti Contributed-by: Gary Benson ! src/cpu/zero/vm/bytecodeInterpreter_zero.hpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/cppInterpreter_zero.hpp ! src/cpu/zero/vm/interpreter_zero.cpp ! src/cpu/zero/vm/methodHandles_zero.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodeInterpreter.hpp Changeset: 3a808be061ff Author: iveresov Date: 2011-04-13 14:33 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3a808be061ff 6988308: assert((cnt > 0.0f) && (prob > 0.0f)) failed: Bad frequency assignment in if Summary: Make sure cnt doesn't become negative and integer overflow doesn't happen. Reviewed-by: kvn, twisti ! src/share/vm/opto/parse2.cpp Changeset: dbccacb79c63 Author: iveresov Date: 2011-04-14 00:02 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/dbccacb79c63 7036236: VM crashes assert((!inside_attrs()) || is_error_reported()) failed ... Summary: Eliminate the race condition. Reviewed-by: kvn ! src/share/vm/code/codeCache.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/runtime/sweeper.cpp Changeset: 1fcd6e9c3965 Author: twisti Date: 2011-04-14 01:53 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1fcd6e9c3965 7036220: Shark fails to find LLVM 2.9 System headers during build Reviewed-by: gbenson, twisti Contributed-by: Xerxes Ranby ! src/share/vm/shark/llvmHeaders.hpp Changeset: e9b9554f7fc3 Author: twisti Date: 2011-04-14 06:46 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e9b9554f7fc3 Merge Changeset: 97e8046e2562 Author: jrose Date: 2011-04-15 08:29 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/97e8046e2562 Merge Changeset: da7f1093a6b7 Author: trims Date: 2011-04-15 18:23 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/da7f1093a6b7 Merge Changeset: 611e19a16519 Author: trims Date: 2011-04-15 18:23 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/611e19a16519 7037174: Bump the HS21 build number to 09 Summary: Update the HS21 build number to 09 Reviewed-by: jcoomes ! make/hotspot_version From lana.steuck at oracle.com Thu Apr 21 20:35:39 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 21 Apr 2011 20:35:39 +0000 Subject: hg: jdk7/tl/jdk: 9 new changesets Message-ID: <20110421203713.78E6A47D70@hg.openjdk.java.net> Changeset: fb1d421c1e97 Author: jrose Date: 2011-04-09 21:38 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fb1d421c1e97 7019529: JSR292: java/dyn/ClassValueTest.java depends on sub-test execution order Summary: Test should not use static variables, because they may contain stale values. Reviewed-by: twisti ! test/java/lang/invoke/ClassValueTest.java Changeset: 861e16acfea7 Author: trims Date: 2011-04-19 18:14 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/861e16acfea7 Merge Changeset: c7452722c57d Author: yhuang Date: 2011-04-18 23:00 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c7452722c57d 7036905: [de] dem - the german mark display name is incorrect Reviewed-by: naoto ! src/share/classes/sun/util/resources/CurrencyNames_de.properties ! src/share/classes/sun/util/resources/CurrencyNames_it.properties ! test/java/util/Currency/CurrencyTest.java ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: 114089fb817c Author: mfang Date: 2011-04-19 10:55 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/114089fb817c Merge ! test/sun/text/resources/LocaleDataTest.java Changeset: 7e7c898b6352 Author: mfang Date: 2011-04-19 11:24 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7e7c898b6352 Merge Changeset: 5f6f3175decc Author: asaha Date: 2011-04-20 14:22 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5f6f3175decc 7018125: Reverting the JFB version string for JDK releases Reviewed-by: katleman ! make/common/shared/Defs.gmk Changeset: d80954a89b49 Author: cl Date: 2011-04-20 16:05 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d80954a89b49 Merge Changeset: ca4f216c0bae Author: lana Date: 2011-04-21 11:11 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ca4f216c0bae Merge Changeset: 3669d17e7799 Author: lana Date: 2011-04-21 13:32 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3669d17e7799 Merge From sean.mullan at oracle.com Thu Apr 21 21:45:15 2011 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Thu, 21 Apr 2011 21:45:15 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20110421214535.53B6C47D7F@hg.openjdk.java.net> Changeset: 2c46bf0a462c Author: mullan Date: 2011-04-21 17:39 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2c46bf0a462c 7038175: Expired PKITS certificates causing CertPathBuilder and CertPathValidator regression test failures Reviewed-by: xuelei ! src/share/classes/sun/security/provider/certpath/CrlRevocationChecker.java ! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java Changeset: 34b2c8e0ac85 Author: mullan Date: 2011-04-21 17:44 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/34b2c8e0ac85 Merge From joe.darcy at oracle.com Thu Apr 21 22:56:19 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Thu, 21 Apr 2011 22:56:19 +0000 Subject: hg: jdk7/tl/jdk: 6998871: Support making the Throwable.stackTrace field immutable Message-ID: <20110421225629.3651047DB8@hg.openjdk.java.net> Changeset: a5bb55c7cfde Author: darcy Date: 2011-04-21 15:55 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a5bb55c7cfde 6998871: Support making the Throwable.stackTrace field immutable Reviewed-by: dholmes, mchung, forax ! src/share/classes/java/lang/ArithmeticException.java ! src/share/classes/java/lang/Error.java ! src/share/classes/java/lang/Exception.java ! src/share/classes/java/lang/NullPointerException.java ! src/share/classes/java/lang/OutOfMemoryError.java ! src/share/classes/java/lang/RuntimeException.java ! src/share/classes/java/lang/Throwable.java ! src/share/native/java/lang/Throwable.c ! test/java/lang/Throwable/ChainedExceptions.java ! test/java/lang/Throwable/StackTraceSerialization.java ! test/java/lang/Throwable/SuppressedExceptions.java From sean.coffey at oracle.com Fri Apr 22 10:00:05 2011 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Fri, 22 Apr 2011 10:00:05 +0000 Subject: hg: jdk7/tl/jdk: 7025227: SSLSocketImpl does not close the TCP layer socket if a close notify cannot be sent to the peer; ... Message-ID: <20110422100100.71B3B47E19@hg.openjdk.java.net> Changeset: 48f659a09ed4 Author: coffeys Date: 2011-04-22 11:03 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/48f659a09ed4 7025227: SSLSocketImpl does not close the TCP layer socket if a close notify cannot be sent to the peer 6932403: SSLSocketImpl state issue Reviewed-by: xuelei ! src/share/classes/sun/security/ssl/SSLSocketImpl.java From dl at cs.oswego.edu Fri Apr 22 11:53:16 2011 From: dl at cs.oswego.edu (Doug Lea) Date: Fri, 22 Apr 2011 07:53:16 -0400 Subject: Improved bulk operation disclaimers for concurrent collections In-Reply-To: <4DAC10B8.1080806@oracle.com> References: <4DA4EA8E.6070506@cs.oswego.edu> <4DA5C812.4080408@oracle.com> <4DAC1004.2060008@cs.oswego.edu> <4DAC10B8.1080806@oracle.com> Message-ID: <4DB16C2C.80802@cs.oswego.edu> Here's another set of very minor javadoc updates: The lists of non-atomic "bulk" operations were incomplete in some concurrent collections and missing in others, as was noted in a recent ASPLOS paper "Specifying and Checking Semantic Atomicity for Multithreaded Programs" by Jacob Burnim, George Necula, Koushik Sen. (See http://www.cs.berkeley.edu/~jburnim/pubs/BurnimNeculaSen-ASPLOS11.pdf). A sample update is below. I updated jsr166 versions. I'll work with the usual folks to create a CR and integrate. (Thanks very much to Chris Hegarty in particular for being so helpful with these integrations!) diff -r1.73 ConcurrentLinkedQueue.java 46c46,53 < * of elements requires a traversal of the elements. --- > * of elements requires a traversal of the elements, and so may report > * inaccurate results if this collection is modified during traversal. > * Additionally, the bulk operations addAll, > * removeAll, retainAll, containsAll, > * equals, and toArray are not guaranteed > * to be performed atomically. For example, an iterator operating > * concurrently with an addAll operation might view only some > * of the added elements. From chris.hegarty at oracle.com Fri Apr 22 12:24:07 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 22 Apr 2011 13:24:07 +0100 Subject: Improved bulk operation disclaimers for concurrent collections In-Reply-To: <4DB16C2C.80802@cs.oswego.edu> References: <4DA4EA8E.6070506@cs.oswego.edu> <4DA5C812.4080408@oracle.com> <4DAC1004.2060008@cs.oswego.edu> <4DAC10B8.1080806@oracle.com> <4DB16C2C.80802@cs.oswego.edu> Message-ID: <4DB17367.8040309@oracle.com> Doug, I'll pull in these changes and try to get them into b142 ( before ramp down phase 2 ). Thanks, -Chris. On 04/22/11 12:53 PM, Doug Lea wrote: > > Here's another set of very minor javadoc updates: The lists of > non-atomic "bulk" operations were incomplete in some concurrent > collections and missing in others, as was noted in a recent ASPLOS paper > "Specifying and Checking Semantic Atomicity for Multithreaded Programs" > by Jacob Burnim, George Necula, Koushik Sen. (See > http://www.cs.berkeley.edu/~jburnim/pubs/BurnimNeculaSen-ASPLOS11.pdf). > A sample update is below. I updated jsr166 versions. I'll work > with the usual folks to create a CR and integrate. (Thanks very > much to Chris Hegarty in particular for being so helpful with these > integrations!) > > > diff -r1.73 ConcurrentLinkedQueue.java > 46c46,53 > < * of elements requires a traversal of the elements. > --- > > * of elements requires a traversal of the elements, and so may report > > * inaccurate results if this collection is modified during traversal. > > * Additionally, the bulk operations addAll, > > * removeAll, retainAll, containsAll, > > * equals, and toArray are not guaranteed > > * to be performed atomically. For example, an iterator operating > > * concurrently with an addAll operation might view only some > > * of the added elements. From Lance.Andersen at oracle.com Fri Apr 22 14:30:39 2011 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Fri, 22 Apr 2011 10:30:39 -0400 Subject: Review request for 7038565, for a findbugs warning for BatchUpdateException Message-ID: Hi Folks, I am looking for a reviewer for this update to BatchUpdateException to address a findbugs issue for exposing a mutable object. The webrev is at http://cr.openjdk.java.net/~lancea/7038565/ Have a great weekend! Regards, lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From chris.hegarty at oracle.com Fri Apr 22 15:34:17 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 22 Apr 2011 15:34:17 +0000 Subject: hg: jdk7/tl/jdk: 7038885: Improved bulk operation disclaimers for concurrent collections Message-ID: <20110422153428.C61F147E48@hg.openjdk.java.net> Changeset: 7c1cdb9c81a6 Author: dl Date: 2011-04-22 16:33 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7c1cdb9c81a6 7038885: Improved bulk operation disclaimers for concurrent collections Reviewed-by: chegar ! src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListSet.java ! src/share/classes/java/util/concurrent/LinkedTransferQueue.java From keith.mcguigan at oracle.com Fri Apr 22 15:48:06 2011 From: keith.mcguigan at oracle.com (keith.mcguigan at oracle.com) Date: Fri, 22 Apr 2011 15:48:06 +0000 Subject: hg: jdk7/tl/jdk: 3 new changesets Message-ID: <20110422154835.82C2C47E4E@hg.openjdk.java.net> Changeset: 7cd61feb3ec6 Author: kamg Date: 2011-04-15 10:17 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7cd61feb3ec6 6519228: JDWP Spec: need references at capability canRequestMonitorEvents for JDWP 1.6 Monitor* events Summary: Add descriptions in event type table Reviewed-by: ohair, jjh, acorn, dcubed ! make/jpda/jdwp/jdwp.spec Changeset: e56922f50d1c Author: kamg Date: 2011-04-22 04:57 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e56922f50d1c Merge Changeset: 9cc0045191ed Author: kamg Date: 2011-04-22 08:46 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9cc0045191ed Merge From vincent.x.ryan at oracle.com Fri Apr 22 16:04:56 2011 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Fri, 22 Apr 2011 16:04:56 +0000 Subject: hg: jdk7/tl/jdk: 6931562: Support SunMSCAPI Security Provider in Windows 64-bit releases of JVM Message-ID: <20110422160506.2084D47E51@hg.openjdk.java.net> Changeset: d64f9348c7ca Author: vinnie Date: 2011-04-22 17:03 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d64f9348c7ca 6931562: Support SunMSCAPI Security Provider in Windows 64-bit releases of JVM Reviewed-by: mullan ! make/java/security/Makefile ! make/sun/security/Makefile ! test/sun/security/mscapi/AccessKeyStore.sh ! test/sun/security/mscapi/IsSunMSCAPIAvailable.sh ! test/sun/security/mscapi/KeyStoreCompatibilityMode.sh ! test/sun/security/mscapi/KeytoolChangeAlias.sh ! test/sun/security/mscapi/RSAEncryptDecrypt.sh From lance.andersen at oracle.com Fri Apr 22 16:22:50 2011 From: lance.andersen at oracle.com (Lance Andersen - Oracle) Date: Fri, 22 Apr 2011 12:22:50 -0400 Subject: Review request for 7038565, for a findbugs warning for BatchUpdateException Message-ID: <5CE3B0CD-918C-4E03-B349-CD886129DB8E@oracle.com> Hi Folks, I am looking for a reviewer for this update to BatchUpdateException to address a findbugs issue for exposing a mutable object. The webrev is at http://cr.openjdk.java.net/~lancea/7038565/ Have a great weekend! Regards, lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From forax at univ-mlv.fr Fri Apr 22 16:29:09 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 22 Apr 2011 18:29:09 +0200 Subject: Review request for 7038565, for a findbugs warning for BatchUpdateException In-Reply-To: <5CE3B0CD-918C-4E03-B349-CD886129DB8E@oracle.com> References: <5CE3B0CD-918C-4E03-B349-CD886129DB8E@oracle.com> Message-ID: <4DB1ACD5.8010205@univ-mlv.fr> On 04/22/2011 06:22 PM, Lance Andersen - Oracle wrote: > Hi Folks, Hi Lance, > I am looking for a reviewer for this update to BatchUpdateException to address a findbugs issue for exposing a mutable object. > > The webrev is at http://cr.openjdk.java.net/~lancea/7038565/ You should use clone() instead of Arrays.copyOf. Also updateCounts should be declared final and initialized like this: public BatchUpdateException(String reason, String SQLState, int vendorCode, int []updateCounts,Throwable cause) { super(reason, SQLState, vendorCode, cause); this.updateCounts = (updateCounts == null)? null:updateCounts.clone(); } > Have a great weekend! > > Regards, > lance regards, R?mi From Lance.Andersen at oracle.com Fri Apr 22 16:51:02 2011 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Fri, 22 Apr 2011 12:51:02 -0400 Subject: Review request for 7038565, for a findbugs warning for BatchUpdateException In-Reply-To: <4DB1ACD5.8010205@univ-mlv.fr> References: <5CE3B0CD-918C-4E03-B349-CD886129DB8E@oracle.com> <4DB1ACD5.8010205@univ-mlv.fr> Message-ID: Hi Remi, Thank you for the feedback. On Apr 22, 2011, at 12:29 PM, R?mi Forax wrote: > On 04/22/2011 06:22 PM, Lance Andersen - Oracle wrote: >> Hi Folks, > > Hi Lance, > >> I am looking for a reviewer for this update to BatchUpdateException to address a findbugs issue for exposing a mutable object. >> >> The webrev is at http://cr.openjdk.java.net/~lancea/7038565/ > > You should use clone() instead of Arrays.copyOf. Can you explain why you have a preference for clone() in this case? > Also updateCounts should be declared final I will make updateCounts final. > and initialized like this: > > public BatchUpdateException(String reason, String SQLState, int vendorCode, > int []updateCounts,Throwable cause) { > super(reason, SQLState, vendorCode, cause); > this.updateCounts = (updateCounts == null)? null:updateCounts.clone(); > } > Regards, lance > >> Have a great weekend! >> >> Regards, >> lance > > regards, > R?mi > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From forax at univ-mlv.fr Fri Apr 22 18:22:35 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 22 Apr 2011 20:22:35 +0200 Subject: Review request for 7038565, for a findbugs warning for BatchUpdateException In-Reply-To: References: <5CE3B0CD-918C-4E03-B349-CD886129DB8E@oracle.com> <4DB1ACD5.8010205@univ-mlv.fr> Message-ID: <4DB1C76B.4060605@univ-mlv.fr> On 04/22/2011 06:51 PM, Lance Andersen - Oracle wrote: > Hi Remi, > > Thank you for the feedback. [...] >> >> You should use clone() instead of Arrays.copyOf. > > Can you explain why you have a preference for clone() in this case? It does the job :) Arrays.copyOf() allows to resize the array. >> Also updateCounts should be declared final > > I will make updateCounts final. >> and initialized like this: >> >> public BatchUpdateException(String reason, String SQLState, int >> vendorCode, >> int []updateCounts,Throwable cause) { >> super(reason, SQLState, vendorCode, cause); >> this.updateCounts = (updateCounts == null)? >> null:updateCounts.clone(); >> } >> > > Regards, > lance regards, r?mi From Lance.Andersen at oracle.com Fri Apr 22 19:34:27 2011 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Fri, 22 Apr 2011 15:34:27 -0400 Subject: Review request for 7038565, for a findbugs warning for BatchUpdateException In-Reply-To: <4DB1C76B.4060605@univ-mlv.fr> References: <5CE3B0CD-918C-4E03-B349-CD886129DB8E@oracle.com> <4DB1ACD5.8010205@univ-mlv.fr> <4DB1C76B.4060605@univ-mlv.fr> Message-ID: <9D698198-3999-4A8F-8649-AB076B9CEF1C@oracle.com> Hi Remi, I pushed a revised webrev http://cr.openjdk.java.net/~lancea/7038565/webrev.01/ Regards, lance On Apr 22, 2011, at 2:22 PM, R?mi Forax wrote: > On 04/22/2011 06:51 PM, Lance Andersen - Oracle wrote: >> Hi Remi, >> >> Thank you for the feedback. > > [...] > >>> >>> You should use clone() instead of Arrays.copyOf. >> >> Can you explain why you have a preference for clone() in this case? > > It does the job :) > Arrays.copyOf() allows to resize the array. > >>> Also updateCounts should be declared final >> >> I will make updateCounts final. >>> and initialized like this: >>> >>> public BatchUpdateException(String reason, String SQLState, int vendorCode, >>> int []updateCounts,Throwable cause) { >>> super(reason, SQLState, vendorCode, cause); >>> this.updateCounts = (updateCounts == null)? null:updateCounts.clone(); >>> } >>> >> >> Regards, >> lance > > regards, > r?mi Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From forax at univ-mlv.fr Fri Apr 22 19:42:49 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 22 Apr 2011 21:42:49 +0200 Subject: Review request for 7038565, for a findbugs warning for BatchUpdateException In-Reply-To: <9D698198-3999-4A8F-8649-AB076B9CEF1C@oracle.com> References: <5CE3B0CD-918C-4E03-B349-CD886129DB8E@oracle.com> <4DB1ACD5.8010205@univ-mlv.fr> <4DB1C76B.4060605@univ-mlv.fr> <9D698198-3999-4A8F-8649-AB076B9CEF1C@oracle.com> Message-ID: <4DB1DA39.5060701@univ-mlv.fr> On 04/22/2011 09:34 PM, Lance Andersen - Oracle wrote: > Hi Remi, > > I pushed a revised webrev > > http://cr.openjdk.java.net/~lancea/7038565/webrev.01/ > > > Regards, > lance Looks good. regards, R?mi From xueming.shen at oracle.com Sat Apr 23 08:00:08 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Sat, 23 Apr 2011 01:00:08 -0700 Subject: Codereview Request: 7039066 j.u.rgex does not match TR#18 RL1.4 Simple Word Boundaries and RL1.2 Properties Message-ID: <4DB28708.9060504@oracle.com> Hi This proposal tries to address (1) j.u.regex does not meet Unicode regex's Simple Word Boundaries [1] requirement as Tom pointed out in his email on i18n-dev list [2]. Basically we have 3 problems here. a. ju.regex word boundary construct \b and \B uses Unicode \p{letter} + \p{digit} as the "word" definition when the standard requires the true Unicode \p{Alphabetic} property be used instead. It also neglects two of the specifically required characters: U+200C ZERO WIDTH NON-JOINER U+200D ZERO WIDTH JOINER (or the "word" could be \p{alphabetic} + \p{gc=Mark} + \p{digit + \p{gc=Connector_Punctuation}, if follow Annex C). b. j.u.regex's word construct \w and \W are ASCII only version c. It breaks the historical connection between word characters and word boundaries (because of a) and b). For example "?l?ve" is NOT matched by the \b\w+\b pattern) (2) j.u.regex does not meet Unicode regex's Properties requirement [3][5][6][7]. Th main issues are a. Alphabetic: totally missing from the platform, not only regex b. Lowercase, Uppercase and White_Space: Java implementation (via \p{javaMethod} is different compared to Unicode Standard definition. c. j.u.regex's POSIX character classes are ASCII only, when standard has an Unicode version defined at tr#18 Annex C [3] As the solution, I propose to (1) add a flag UNICODE_UNICODE to a) flip the ASCII only predefined character classes (\b \B \w \W \d \D \s \S) and POSIX character classes (\p{alpha}, \p{lower}, \{upper}...) to Unicode version b) enable the UNICODE_CASE (anything Unicode) While ideally we would like to just evolve/upgrade the Java regex from the aged "ascii-only" to unicode (maybe add a OLD_ASCII_ONLY_POSIX as a fallback:-)), like what Perl did. But given the Java's "compatibility" spirit (and the performance concern as well), this is unlikely to happen. (2) add \p{IsBinaryProperty} to explicitly support some important Unicode binary properties, such as \p{IsAlphabetic}, \p{IsIdeographic}, \p{IsPunctuation}...with this j.u.regex can easily access some properties that are either not provided by j.l.Character directly or j.l.Character has a different version (for example the White_Space). (The missing alphabetic, different uppercase/lowercase issue has been/is being addressed at Cr#7037261 [4], any reviewer?) The webrev is at http://cr.openjdk.java.net/~sherman/7039066/webrev/ The corresponding updated api j.u.regex.Pattern API doc is at http://cr.openjdk.java.net/~sherman/7039066/Pattern.html Specdiff result is at http://cr.openjdk.java.net/~sherman/7039066/specdiff/diff.html I will file the CCC request if the API change proposal in webrev is approved. This is coming in very late so it is possible that it may be held back until Java 8, if it can not make the cutoff for jdk7. -Sherman [1] http://www.unicode.org/reports/tr18/#Simple_Word_Boundaries [2] http://mail.openjdk.java.net/pipermail/i18n-dev/2011-January/000256.html [3] http://www.unicode.org/reports/tr18/#Compatibility_Properties [4] http://mail.openjdk.java.net/pipermail/i18n-dev/2011-April/000370.html [5] http://mail.openjdk.java.net/pipermail/i18n-dev/2011-January/000249.html [6] http://mail.openjdk.java.net/pipermail/i18n-dev/2011-January/000253.html [7] http://mail.openjdk.java.net/pipermail/i18n-dev/2011-January/000254.html From xueming.shen at oracle.com Sat Apr 23 08:12:10 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Sat, 23 Apr 2011 01:12:10 -0700 Subject: Codereview Request: 7039066 j.u.rgex does not match TR#18 RL1.4 Simple Word Boundaries and RL1.2 Properties In-Reply-To: <4DB28708.9060504@oracle.com> References: <4DB28708.9060504@oracle.com> Message-ID: <4DB289DA.8040609@oracle.com> The flag this request proposed to add is UNICODE_CHARSET not the "UNICODE_UNICODE" in last email. My apology for the typo. Any suggestion for a better name? It was UNICODE_CHARACTERCLASS, but then it became UNICODE_CHARSET, considering the unicode_case. -Sherman On 4/23/2011 1:00 AM, Xueming Shen wrote: > Hi > > This proposal tries to address > > (1) j.u.regex does not meet Unicode regex's Simple Word Boundaries > [1] requirement as Tom pointed > out in his email on i18n-dev list [2]. Basically we have 3 problems here. > > a. ju.regex word boundary construct \b and \B uses Unicode > \p{letter} + \p{digit} as the "word" > definition when the standard requires the true Unicode > \p{Alphabetic} property be used instead. > It also neglects two of the specifically required characters: > U+200C ZERO WIDTH NON-JOINER > U+200D ZERO WIDTH JOINER > (or the "word" could be \p{alphabetic} + \p{gc=Mark} + > \p{digit + \p{gc=Connector_Punctuation}, if > follow Annex C). > b. j.u.regex's word construct \w and \W are ASCII only version > c. It breaks the historical connection between word characters and > word boundaries (because of > a) and b). For example "?l?ve" is NOT matched by the \b\w+\b > pattern) > > (2) j.u.regex does not meet Unicode regex's Properties requirement > [3][5][6][7]. Th main issues are > > a. Alphabetic: totally missing from the platform, not only regex > b. Lowercase, Uppercase and White_Space: Java implementation (via > \p{javaMethod} is different > compared to Unicode Standard definition. > c. j.u.regex's POSIX character classes are ASCII only, when > standard has an Unicode version defined > at tr#18 Annex C [3] > > As the solution, I propose to > > (1) add a flag UNICODE_UNICODE to > a) flip the ASCII only predefined character classes (\b \B \w \W > \d \D \s \S) and POSIX character > classes (\p{alpha}, \p{lower}, \{upper}...) to Unicode version > b) enable the UNICODE_CASE (anything Unicode) > > While ideally we would like to just evolve/upgrade the Java regex > from the aged "ascii-only" > to unicode (maybe add a OLD_ASCII_ONLY_POSIX as a fallback:-)), > like what Perl did. But > given the Java's "compatibility" spirit (and the performance > concern as well), this is unlikely to > happen. > > (2) add \p{IsBinaryProperty} to explicitly support some important > Unicode binary properties, such > as \p{IsAlphabetic}, \p{IsIdeographic}, \p{IsPunctuation}...with > this j.u.regex can easily access > some properties that are either not provided by j.l.Character > directly or j.l.Character has a > different version (for example the White_Space). > (The missing alphabetic, different uppercase/lowercase issue has > been/is being addressed at > Cr#7037261 [4], any reviewer?) > > The webrev is at > http://cr.openjdk.java.net/~sherman/7039066/webrev/ > > The corresponding updated api j.u.regex.Pattern API doc is at > http://cr.openjdk.java.net/~sherman/7039066/Pattern.html > > Specdiff result is at > http://cr.openjdk.java.net/~sherman/7039066/specdiff/diff.html > > I will file the CCC request if the API change proposal in webrev is > approved. This is coming in very late > so it is possible that it may be held back until Java 8, if it can not > make the cutoff for jdk7. > > -Sherman > > > [1] http://www.unicode.org/reports/tr18/#Simple_Word_Boundaries > [2] > http://mail.openjdk.java.net/pipermail/i18n-dev/2011-January/000256.html > [3] http://www.unicode.org/reports/tr18/#Compatibility_Properties > [4] > http://mail.openjdk.java.net/pipermail/i18n-dev/2011-April/000370.html > [5] > http://mail.openjdk.java.net/pipermail/i18n-dev/2011-January/000249.html > [6] > http://mail.openjdk.java.net/pipermail/i18n-dev/2011-January/000253.html > [7] > http://mail.openjdk.java.net/pipermail/i18n-dev/2011-January/000254.html From David.Holmes at oracle.com Sat Apr 23 10:11:40 2011 From: David.Holmes at oracle.com (David Holmes) Date: Sat, 23 Apr 2011 20:11:40 +1000 Subject: Review request for 7038565, for a findbugs warning for BatchUpdateException In-Reply-To: <4DB1C76B.4060605@univ-mlv.fr> References: <5CE3B0CD-918C-4E03-B349-CD886129DB8E@oracle.com> <4DB1ACD5.8010205@univ-mlv.fr> <4DB1C76B.4060605@univ-mlv.fr> Message-ID: <4DB2A5DC.8000204@oracle.com> R?mi Forax said the following on 04/23/11 04:22: > On 04/22/2011 06:51 PM, Lance Andersen - Oracle wrote: >>> >>> You should use clone() instead of Arrays.copyOf. >> >> Can you explain why you have a preference for clone() in this case? > > It does the job :) > Arrays.copyOf() allows to resize the array. So? That's not a reason to not use Arrays.copyOf. Look at copyOf as the new improved version of clone. David >>> Also updateCounts should be declared final >> >> I will make updateCounts final. >>> and initialized like this: >>> >>> public BatchUpdateException(String reason, String SQLState, int >>> vendorCode, >>> int []updateCounts,Throwable cause) { >>> super(reason, SQLState, vendorCode, cause); >>> this.updateCounts = (updateCounts == null)? >>> null:updateCounts.clone(); >>> } >>> >> >> Regards, >> lance > > regards, > r?mi From xueming.shen at oracle.com Sun Apr 24 01:50:53 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Sat, 23 Apr 2011 18:50:53 -0700 Subject: Fwd: Re: Codereview Request: 7039066 j.u.rgex does not match TR#18 RL1.4 Simple Word Boundaries and RL1.2 Properties Message-ID: <4DB381FD.7050600@oracle.com> Forwarding...forgot to include the list. -------- Original Message -------- Subject: Re: Codereview Request: 7039066 j.u.rgex does not match TR#18 RL1.4 Simple Word Boundaries and RL1.2 Properties Date: Sat, 23 Apr 2011 17:53:42 -0700 From: Xueming Shen To: Tom Christiansen Mark, Tom, I agree with Mark that UNICODE_SPEC is a better name than UNICODE_CHARSET. We will have to deal with the "compatibility" issue Tom mentioned anyway anyway should Java go higher level of Unicode Regex support someday. New option/flag will have to be introduced to let the developer to have the choice, just like what we are trying to do with the ASCII only or Unicode version for those classes. I also agree we should have an embedded flag. was thinking we can add it later, for example the JDK8, if we can get this one in jdk7, but the Pattern usage in String class is persuasive. The webrev, specdiff and Pattern doc have been updated to use UNICODE_SPEC as the flag and (?U) as the embedded flag. It might be a little confused, compared to we use (?u) for UNICODE_CASE, but feel it might feel "nature" to have uppercase "U" for broader Unicode support. The webrev is at http://cr.openjdk.java.net/~sherman/7039066/webrev/ j.u.regex.Pattern API: http://cr.openjdk.java.net/~sherman/7039066/Pattern.html Specdiff: http://cr.openjdk.java.net/~sherman/7039066/specdiff/diff.html Tom, it would be appreciated if you can at lease give the doc update a quick scan to see if I miss anything. And thanks for the suggestions for the Perl related doc update, I will need go through it a little later and address it in a separate CR. Thanks, -Sherman On 4/23/2011 10:48 AM, Tom Christiansen wrote: > Mark Davis ? wrote > on Sat, 23 Apr 2011 09:09:55 PDT: > >> The changes sound good. > They sure do, don't they? I'm quite happy about this. I think it is more > important to get this in the queue than that it (necessarily) be done for > JDK7. That said, having a good tr18 RL1 story for JDK7's Unicode 6.0 debut > makes it attractive now. But if not now, then soon is good enough. > >> The flag UNICODE_CHARSET will be misleading, since >> all of Java uses the Unicode Charset (= encoding). How about: >> UNICODE_SPEC >> or something that gives that flavor. > I hadn't thought of that, but I do see what you mean. The idea is > that the semantics of \w etc change to match the Unicode spec in tr18. > > I worry that UNICODE_SPEC, or even UNICODE_SEMANTICS, might be too > broad a brush. What then happens when, as I imagine it someday shall, > Java gets full support for RL2.3 boundaries, the way with ICU one uses > or (?w) or UREGEX_UWORD for? > > Wouldn't calling something UNICODE_SPEC be too broad? Or should > UNICODE_SPEC automatically include not just existing Unicode flags > like UNICODE_CASE, but also any UREGEX_UWORD that comes along? > If it does, you have back-compat issue, and if it doesn't, you > have a misnaming issue. Seems like a bit of a Catch22. > > The reason I'd suggested UNICODE_CHARSET was because of my own background > with the names we use for this within the Perl regex source code (which is > itself written in C). I believe that Java doesn't have the same situation > as gave rise to it in Perl, and perhaps something else would be clearer. > > Here's some background for why we felt we had to go that way. To control > the behavior of \w and such, when a regex is compiled, a compiled Perl > gets exactly one of these states: > > REGEX_UNICODE_CHARSET > REGEX_LOCALE_CHARSET > REGEX_ASCII_RESTRICTED_CHARSET > REGEX_DEPENDS_CHARSET > > That state it normally inherits from the surrounding lexical scope, > although this can be overridden with /u and /a, or (?u) and (?a), > either within the pattern or as a separate pattern-compilation flag. > > REGEX_UNICODE_CHARSET corresponds to out (?u), so \w and such all get the > full RL1.2a definitions. Because Perl always does Unicode casemapping -- > and full casemapping, too, not just simple -- we didn't need (?u) for what > Java uses it for, which is just as an extra flavor of (?i); it doesn't > do all that much. > > (BTW, the old default is *not* some sort of non-Unicode charset > semantics, it's the ugly REGEX_DEPENDS_CHARSET, which is Unicode for > code points> 255 and "maybe" so in the 128-255 range.) > > What we did certainly isn't perfect, but it allows for both backwards > compat and future growth. This was because people want(ed) to be able to > use regexes on both byte arrays yet also on character strings. Me, I think > it's nuts to support this at all, that if you want an input stream in (say) > CP1251 or ISO 8859-2, that you simply set that stream's encoding and be > done with it: everything turns into characters internally. But there's old > byte and locale code out there whose semantics we are loth to change out > from under people. Java has the same kind of issue. > > The reason we ever support anything else is because we got (IMHO nasty) > POSIX locales before we got Unicode support, which didn't happen till > toward the end of the last millennium. So we're stuck supporting code > well more than a decade old, perhaps indefinitely. It's messy, but it > is very hard to do anything about that. I think Java shares in that > perspective. > > This corresponds, I think, to Java needing to support pre-Unicode > regex semantics on \w and related escapes. If they had started out > with it always means the real thing the way ICU did, they wouldn't > need both. > > I wish there were a pragma to control this on a per-lexical-scope basis, > but I'm don't enough about the Java compilers internals to begin to know > how to go about implementing some thing like that, even as a > -XX:+UseUnicodeSemantics CLI switch for that compilation unit. > > One reason you want this is because the Java String class has these > "convenience" methods like matches, replaceAll, etc, that take regexes > but do not provide an API that admits Pattern compile flags. If there > is no way to embed a (?U) directive or some such, nor any way to pass > in a Pattern.UNICODE_something flag. The Java String API could also > be broadened through method signature overloading, but for now, you > can't do that. > > No matter what the UNICODE_something gets called, I think there needs to be > a corresponding embeddable (?X)-style flag as well. Even if String were > broadened, you'd want people to be able to specify *within the regex* that > that regex should have full Unicode semantics. After all, they might read > the pattern in from a file. That's why (most) Pattern.compile flags need > to be able to embedded, too. But you knew that already. :) > > --tom From xueming.shen at oracle.com Sun Apr 24 18:22:31 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Sun, 24 Apr 2011 11:22:31 -0700 Subject: Fwd: Re: Codereview Request: 7039066 j.u.rgex does not match TR#18 RL1.4 Simple Word Boundaries and RL1.2 Properties In-Reply-To: <4DB381FD.7050600@oracle.com> References: <4DB381FD.7050600@oracle.com> Message-ID: <4DB46A67.8010106@oracle.com> Two more names, UNICODE_PROPERTIES and UNICODE_CLASSES, are suggested. any opinion? -Sherman On 4/23/2011 6:50 PM, Xueming Shen wrote: > Forwarding...forgot to include the list. > > -------- Original Message -------- > Subject: Re: Codereview Request: 7039066 j.u.rgex does not match > TR#18 RL1.4 Simple Word Boundaries and RL1.2 Properties > Date: Sat, 23 Apr 2011 17:53:42 -0700 > From: Xueming Shen > To: Tom Christiansen > > > > Mark, Tom, > > I agree with Mark that UNICODE_SPEC is a better name than > UNICODE_CHARSET. We will have to deal with > the "compatibility" issue Tom mentioned anyway anyway should Java go > higher level of Unicode Regex support > someday. New option/flag will have to be introduced to let the developer > to have the choice, just like what we > are trying to do with the ASCII only or Unicode version for those classes. > > I also agree we should have an embedded flag. was thinking we can add it > later, for example the JDK8, if we > can get this one in jdk7, but the Pattern usage in String class is > persuasive. > > The webrev, specdiff and Pattern doc have been updated to use > UNICODE_SPEC as the flag and (?U) as the > embedded flag. It might be a little confused, compared to we use (?u) > for UNICODE_CASE, but feel it might > feel "nature" to have uppercase "U" for broader Unicode support. > > The webrev is at > http://cr.openjdk.java.net/~sherman/7039066/webrev/ > > j.u.regex.Pattern API: > http://cr.openjdk.java.net/~sherman/7039066/Pattern.html > > Specdiff: > http://cr.openjdk.java.net/~sherman/7039066/specdiff/diff.html > > Tom, it would be appreciated if you can at lease give the doc update a > quick scan to see if I miss anything. > And thanks for the suggestions for the Perl related doc update, I will > need go through it a little later and address > it in a separate CR. > > Thanks, > -Sherman > > > On 4/23/2011 10:48 AM, Tom Christiansen wrote: > > Mark Davis ? wrote > > on Sat, 23 Apr 2011 09:09:55 PDT: > > > >> The changes sound good. > > They sure do, don't they? I'm quite happy about this. I think it is more > > important to get this in the queue than that it (necessarily) be done for > > JDK7. That said, having a good tr18 RL1 story for JDK7's Unicode 6.0 debut > > makes it attractive now. But if not now, then soon is good enough. > > > >> The flag UNICODE_CHARSET will be misleading, since > >> all of Java uses the Unicode Charset (= encoding). How about: > >> UNICODE_SPEC > >> or something that gives that flavor. > > I hadn't thought of that, but I do see what you mean. The idea is > > that the semantics of \w etc change to match the Unicode spec in tr18. > > > > I worry that UNICODE_SPEC, or even UNICODE_SEMANTICS, might be too > > broad a brush. What then happens when, as I imagine it someday shall, > > Java gets full support for RL2.3 boundaries, the way with ICU one uses > > or (?w) or UREGEX_UWORD for? > > > > Wouldn't calling something UNICODE_SPEC be too broad? Or should > > UNICODE_SPEC automatically include not just existing Unicode flags > > like UNICODE_CASE, but also any UREGEX_UWORD that comes along? > > If it does, you have back-compat issue, and if it doesn't, you > > have a misnaming issue. Seems like a bit of a Catch22. > > > > The reason I'd suggested UNICODE_CHARSET was because of my own background > > with the names we use for this within the Perl regex source code (which is > > itself written in C). I believe that Java doesn't have the same situation > > as gave rise to it in Perl, and perhaps something else would be clearer. > > > > Here's some background for why we felt we had to go that way. To control > > the behavior of \w and such, when a regex is compiled, a compiled Perl > > gets exactly one of these states: > > > > REGEX_UNICODE_CHARSET > > REGEX_LOCALE_CHARSET > > REGEX_ASCII_RESTRICTED_CHARSET > > REGEX_DEPENDS_CHARSET > > > > That state it normally inherits from the surrounding lexical scope, > > although this can be overridden with /u and /a, or (?u) and (?a), > > either within the pattern or as a separate pattern-compilation flag. > > > > REGEX_UNICODE_CHARSET corresponds to out (?u), so \w and such all get the > > full RL1.2a definitions. Because Perl always does Unicode casemapping -- > > and full casemapping, too, not just simple -- we didn't need (?u) for what > > Java uses it for, which is just as an extra flavor of (?i); it doesn't > > do all that much. > > > > (BTW, the old default is *not* some sort of non-Unicode charset > > semantics, it's the ugly REGEX_DEPENDS_CHARSET, which is Unicode for > > code points> 255 and "maybe" so in the 128-255 range.) > > > > What we did certainly isn't perfect, but it allows for both backwards > > compat and future growth. This was because people want(ed) to be able to > > use regexes on both byte arrays yet also on character strings. Me, I think > > it's nuts to support this at all, that if you want an input stream in (say) > > CP1251 or ISO 8859-2, that you simply set that stream's encoding and be > > done with it: everything turns into characters internally. But there's old > > byte and locale code out there whose semantics we are loth to change out > > from under people. Java has the same kind of issue. > > > > The reason we ever support anything else is because we got (IMHO nasty) > > POSIX locales before we got Unicode support, which didn't happen till > > toward the end of the last millennium. So we're stuck supporting code > > well more than a decade old, perhaps indefinitely. It's messy, but it > > is very hard to do anything about that. I think Java shares in that > > perspective. > > > > This corresponds, I think, to Java needing to support pre-Unicode > > regex semantics on \w and related escapes. If they had started out > > with it always means the real thing the way ICU did, they wouldn't > > need both. > > > > I wish there were a pragma to control this on a per-lexical-scope basis, > > but I'm don't enough about the Java compilers internals to begin to know > > how to go about implementing some thing like that, even as a > > -XX:+UseUnicodeSemantics CLI switch for that compilation unit. > > > > One reason you want this is because the Java String class has these > > "convenience" methods like matches, replaceAll, etc, that take regexes > > but do not provide an API that admits Pattern compile flags. If there > > is no way to embed a (?U) directive or some such, nor any way to pass > > in a Pattern.UNICODE_something flag. The Java String API could also > > be broadened through method signature overloading, but for now, you > > can't do that. > > > > No matter what the UNICODE_something gets called, I think there needs to be > > a corresponding embeddable (?X)-style flag as well. Even if String were > > broadened, you'd want people to be able to specify *within the regex* that > > that regex should have full Unicode semantics. After all, they might read > > the pattern in from a file. That's why (most) Pattern.compile flags need > > to be able to embedded, too. But you knew that already. :) > > > > --tom > From forax at univ-mlv.fr Sun Apr 24 22:54:13 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 25 Apr 2011 00:54:13 +0200 Subject: Review request for 7038565, for a findbugs warning for BatchUpdateException In-Reply-To: <4DB2A5DC.8000204@oracle.com> References: <5CE3B0CD-918C-4E03-B349-CD886129DB8E@oracle.com> <4DB1ACD5.8010205@univ-mlv.fr> <4DB1C76B.4060605@univ-mlv.fr> <4DB2A5DC.8000204@oracle.com> Message-ID: <4DB4AA15.7010707@univ-mlv.fr> On 04/23/2011 12:11 PM, David Holmes wrote: > R?mi Forax said the following on 04/23/11 04:22: >> On 04/22/2011 06:51 PM, Lance Andersen - Oracle wrote: >>>> >>>> You should use clone() instead of Arrays.copyOf. >>> >>> Can you explain why you have a preference for clone() in this case? >> >> It does the job :) >> Arrays.copyOf() allows to resize the array. > > So? That's not a reason to not use Arrays.copyOf. Look at copyOf as > the new improved version of clone. Ok, it seems I'm too old to want to write something that will be seen in the future as a long troll on the merit of clone vs Arrays.copyOf. > > David R?mi From xueming.shen at oracle.com Mon Apr 25 05:38:48 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Sun, 24 Apr 2011 22:38:48 -0700 Subject: Fwd: Re: Codereview Request: 7039066 j.u.rgex does not match TR#18 RL1.4 Simple Word Boundaries and RL1.2 Properties In-Reply-To: References: <4DB381FD.7050600@oracle.com> <4DB46A67.8010106@oracle.com> Message-ID: <4DB508E8.5010907@oracle.com> Thanks Mark! Let's go with UNICODE_PROPERTY, if there is no objection. -Sherman On 4/24/2011 9:00 PM, Mark Davis ? wrote: > There are pluses and minuses to any of them: UNICODE_SPEC, > UNICODE_PROPERTY, UNICODE_CLASS, UNICODE_PROPERTIES, > or UNICODE_CLASSES, although any would work in a pinch. > > I'd favor a bit the singular over the plural, given the usage. > > The term 'class' is not used much in Unicode, just for two properties > (see below). So someone could possibly think it just meant those two > properties, and it could cause a bit of confusion with 'class' meaning > OO. So for that reason I don't think CLASS(ES) would be optimal. > bc ; Bidi_Class > ccc ; Canonical_Combining_Class > http://unicode.org/Public/UNIDATA/PropertyAliases.txt > > Mark > > /? Il meglio ? l?inimico del bene ?/ > > > On Sun, Apr 24, 2011 at 11:22, Xueming Shen > wrote: > > > Two more names, UNICODE_PROPERTIES and UNICODE_CLASSES, are suggested. > > any opinion? > > -Sherman > > > On 4/23/2011 6:50 PM, Xueming Shen wrote: >> Forwarding...forgot to include the list. >> >> -------- Original Message -------- >> Subject: Re: Codereview Request: 7039066 j.u.rgex does not match >> TR#18 RL1.4 Simple Word Boundaries and RL1.2 Properties >> Date: Sat, 23 Apr 2011 17:53:42 -0700 >> From: Xueming Shen >> >> To: Tom Christiansen >> >> >> >> Mark, Tom, >> >> I agree with Mark that UNICODE_SPEC is a better name than >> UNICODE_CHARSET. We will have to deal with >> the "compatibility" issue Tom mentioned anyway anyway should Java go >> higher level of Unicode Regex support >> someday. New option/flag will have to be introduced to let the developer >> to have the choice, just like what we >> are trying to do with the ASCII only or Unicode version for those classes. >> >> I also agree we should have an embedded flag. was thinking we can add it >> later, for example the JDK8, if we >> can get this one in jdk7, but the Pattern usage in String class is >> persuasive. >> >> The webrev, specdiff and Pattern doc have been updated to use >> UNICODE_SPEC as the flag and (?U) as the >> embedded flag. It might be a little confused, compared to we use (?u) >> for UNICODE_CASE, but feel it might >> feel "nature" to have uppercase "U" for broader Unicode support. >> >> The webrev is at >> http://cr.openjdk.java.net/~sherman/7039066/webrev/ >> >> j.u.regex.Pattern API: >> http://cr.openjdk.java.net/~sherman/7039066/Pattern.html >> >> Specdiff: >> http://cr.openjdk.java.net/~sherman/7039066/specdiff/diff.html >> >> Tom, it would be appreciated if you can at lease give the doc update a >> quick scan to see if I miss anything. >> And thanks for the suggestions for the Perl related doc update, I will >> need go through it a little later and address >> it in a separate CR. >> >> Thanks, >> -Sherman >> >> >> On 4/23/2011 10:48 AM, Tom Christiansen wrote: >> > Mark Davis ? wrote >> > on Sat, 23 Apr 2011 09:09:55 PDT: >> > >> >> The changes sound good. >> > They sure do, don't they? I'm quite happy about this. I think it is more >> > important to get this in the queue than that it (necessarily) be done for >> > JDK7. That said, having a good tr18 RL1 story for JDK7's Unicode 6.0 debut >> > makes it attractive now. But if not now, then soon is good enough. >> > >> >> The flag UNICODE_CHARSET will be misleading, since >> >> all of Java uses the Unicode Charset (= encoding). How about: >> >> UNICODE_SPEC >> >> or something that gives that flavor. >> > I hadn't thought of that, but I do see what you mean. The idea is >> > that the semantics of \w etc change to match the Unicode spec in tr18. >> > >> > I worry that UNICODE_SPEC, or even UNICODE_SEMANTICS, might be too >> > broad a brush. What then happens when, as I imagine it someday shall, >> > Java gets full support for RL2.3 boundaries, the way with ICU one uses >> > or (?w) or UREGEX_UWORD for? >> > >> > Wouldn't calling something UNICODE_SPEC be too broad? Or should >> > UNICODE_SPEC automatically include not just existing Unicode flags >> > like UNICODE_CASE, but also any UREGEX_UWORD that comes along? >> > If it does, you have back-compat issue, and if it doesn't, you >> > have a misnaming issue. Seems like a bit of a Catch22. >> > >> > The reason I'd suggested UNICODE_CHARSET was because of my own background >> > with the names we use for this within the Perl regex source code (which is >> > itself written in C). I believe that Java doesn't have the same situation >> > as gave rise to it in Perl, and perhaps something else would be clearer. >> > >> > Here's some background for why we felt we had to go that way. To control >> > the behavior of \w and such, when a regex is compiled, a compiled Perl >> > gets exactly one of these states: >> > >> > REGEX_UNICODE_CHARSET >> > REGEX_LOCALE_CHARSET >> > REGEX_ASCII_RESTRICTED_CHARSET >> > REGEX_DEPENDS_CHARSET >> > >> > That state it normally inherits from the surrounding lexical scope, >> > although this can be overridden with /u and /a, or (?u) and (?a), >> > either within the pattern or as a separate pattern-compilation flag. >> > >> > REGEX_UNICODE_CHARSET corresponds to out (?u), so \w and such all get the >> > full RL1.2a definitions. Because Perl always does Unicode casemapping -- >> > and full casemapping, too, not just simple -- we didn't need (?u) for what >> > Java uses it for, which is just as an extra flavor of (?i); it doesn't >> > do all that much. >> > >> > (BTW, the old default is *not* some sort of non-Unicode charset >> > semantics, it's the ugly REGEX_DEPENDS_CHARSET, which is Unicode for >> > code points> 255 and "maybe" so in the 128-255 range.) >> > >> > What we did certainly isn't perfect, but it allows for both backwards >> > compat and future growth. This was because people want(ed) to be able to >> > use regexes on both byte arrays yet also on character strings. Me, I think >> > it's nuts to support this at all, that if you want an input stream in (say) >> > CP1251 or ISO 8859-2, that you simply set that stream's encoding and be >> > done with it: everything turns into characters internally. But there's old >> > byte and locale code out there whose semantics we are loth to change out >> > from under people. Java has the same kind of issue. >> > >> > The reason we ever support anything else is because we got (IMHO nasty) >> > POSIX locales before we got Unicode support, which didn't happen till >> > toward the end of the last millennium. So we're stuck supporting code >> > well more than a decade old, perhaps indefinitely. It's messy, but it >> > is very hard to do anything about that. I think Java shares in that >> > perspective. >> > >> > This corresponds, I think, to Java needing to support pre-Unicode >> > regex semantics on \w and related escapes. If they had started out >> > with it always means the real thing the way ICU did, they wouldn't >> > need both. >> > >> > I wish there were a pragma to control this on a per-lexical-scope basis, >> > but I'm don't enough about the Java compilers internals to begin to know >> > how to go about implementing some thing like that, even as a >> > -XX:+UseUnicodeSemantics CLI switch for that compilation unit. >> > >> > One reason you want this is because the Java String class has these >> > "convenience" methods like matches, replaceAll, etc, that take regexes >> > but do not provide an API that admits Pattern compile flags. If there >> > is no way to embed a (?U) directive or some such, nor any way to pass >> > in a Pattern.UNICODE_something flag. The Java String API could also >> > be broadened through method signature overloading, but for now, you >> > can't do that. >> > >> > No matter what the UNICODE_something gets called, I think there needs to be >> > a corresponding embeddable (?X)-style flag as well. Even if String were >> > broadened, you'd want people to be able to specify *within the regex* that >> > that regex should have full Unicode semantics. After all, they might read >> > the pattern in from a file. That's why (most) Pattern.compile flags need >> > to be able to embedded, too. But you knew that already. :) >> > >> > --tom >> > > From xueming.shen at oracle.com Mon Apr 25 05:59:49 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Sun, 24 Apr 2011 22:59:49 -0700 Subject: Codereview Request: 7039066 j.u.rgex does not match TR#18 RL1.4 Simple Word Boundaries and RL1.2 Properties In-Reply-To: <29462.1303703270@chthon> References: <4DB28708.9060504@oracle.com> <4DB289DA.8040609@oracle.com> <17481.1303580915@chthon> <4DB37496.8070801@oracle.com> <29462.1303703270@chthon> Message-ID: <4DB50DD5.1090305@oracle.com> Thanks Tom! The j.u.regex does not have its own direct access to PropList for now, have to use the properties from j..l.Character class. I will have to move those CharacterDateNN classes from the java.lang package (package private) to sun.lang or somewhere that both j.u.Character and j.u.regex can both have access, given we are so late in release, I'm trying to make as less change as possible. Will redo the properties access part in JDK8 to (1) provide more useful properties or all (? :-), maybe with better performance) (2) as you suggested, to implement \X, need to access the property that probably not available via j.l.Character class. The "Noncharacter_code_point" is not difficult to achieve by simply hard coding those code points. -- "You'll certainly want to somehow make that available for Strings, too;" Yes, I remember I "joked" with a language guy about the possibility of adding the literal syntax for Unicode character name for String and "char", for example '\u{LATIN_CAPITAL_LETTER_A}', I got "haha, interesting",:-) It's going to be a language spec change. -Sherman On 4/24/2011 8:47 PM, Tom Christiansen wrote: > Xueming, the docs look good. > > On the name of the flag, I have no strong feelings one way or the other. > Perhaps between UNICODE_PROPERTIES and UNICODE_CLASSES, I would prefer > the second one. The first makes me think of the regular properties like > \p{Script=Greek} from RL1.2, not the compat properties from RL1.2a like > \w and \s. (I realize that the POSIX-compat stuff overlaps a bit.) > > One thing you might want to take a look at longer term is whether > all 11 properties listed in RL1.2 will be accessible. I don't > know whether you have methods in Character for #7 and #8 below; > I seem to recall seeing one but not the other. > > RL1.2 Properties > To meet this requirement, an implementation shall provide > at least a minimal list of properties, consisting of the > following: > > yes 1 General_Category > yes 2 Script > yes 3 Alphabetic > yes 4 Uppercase > yes 5 Lowercase > yes 6 White_Space > ? 7 Noncharacter_Code_Point > ? 8 Default_Ignorable_Code_Point > ? 9 ANY > yes 10 ASCII > ? 11 ASSIGNED > > RL1.2a Compatibility Properties > To meet this requirement, an implementation shall provide the > properties listed in Annex C. Compatibility Properties, with the > property values as listed there. Such an implementation shall > document whether it is using the Standard Recommendation or > POSIX-compatible properties. > > Other things... > > I've thought a bit about whether it's worth pointing out that \x{h..h.} > is the *only* way to (currently?) get non-BMP code points into a > bracketed character class, like for example [\x{1D400}-\x{1D419}] to > mean MATHEMATICAL BOLD CAPITAL A through MATHEMATICAL BOLD CAPITAL Z. > > Reasons for not mentioning it include how rarely (I imagine) that users come > across it, and also because this is one of those rare places in Java where > you can't treat UTF-16 code units separately and get the same results. > This matters for interpolation, because you can never build up a character > class by using [ ] to surround the two different 16-bit char units that > non-BMP codepoints turn into. You always have to use the indirect \x{h..h} > instead. This is rather non-obvious. > > However, after consideration I think it probably not worth risking > confusing people by talking about it. I'm just very glad it can now > be done. Having to figure out pieces of UTF-16 is no fun. > > Once the current effort is done and you've had a well-deserved rest, > I know you were thinking about \N{NAME} and \X for a future version > of the JDK. Both are important, although for quite different reasons. > > \N{NAME} is important for helping make regex code more maintainable by > being self-documenting, since having to putting raw "magic" numbers instead of > symbolic names in code is always bad. You'll certainly want to somehow > make that available for Strings, too; not sure how to do that. The regex > string escapes and the Java String escapes have already diverged, and I > don't know how that happened. For example, the rules for octal escapes > differ, and the regex engine supports things that Java proper does not; > The "\cA" style comes to mind, but I think there are a few others, too. > And now there is "\x{h..h}" too; pity Strings don't know that one. > > \X is important because you really do need access to graphemes. Otherwise > it is very difficult to write the equivalent of (?:(?=[aeiou])\X), which > assuming NFD, will match a grapheme that start with one of those five > letters. More importantly, you have to be able to chunk text by graphemes, > and you need to do this even if you don't someday make a way to tie \b to > the fancier sense like the ICU (?w) UREGEX_UWORD flag provides. > > Getting grapheme clusters right is harder than it might appear. A > careful reading of UAX#29 is important. There are two kinds of grapheme > clusters, either legacy or extended. The extended version is tricky to > get right, especially when you don't have access to all the syllable > type properties. One problem with the legacy version is that it breaks > up things that it shouldn't. We switched to the extended version for > the 5.12 release of Perl, as this shows: > > $ perl5.10.0 -le 'print "\r\n" =~ /\A\X\z/ ? 1 : 0' > 0 > > $ perl5.12.3 -le 'print "\r\n" =~ /\A\X\z/ ? 1 : 0' > 1 > > Which is the way it really needs to be. For the legacy sense, you can > always still code that one up more explicitly: > > $ perl5.12.3 -le 'print "\r\n" =~ /\A\p{Grapheme_Base}\p{Grapheme_Extend}*\z/ ? 1 : 0' > 0 > > But I don't think people often want that version; extended is much better. > > Giving Java access to the properties needed for either version of grapheme > clusters may be a good time to reconsider whether you might wish to > redesign how you check whether a code point has any particular Unicode > property. There are of course performance issues, but also because the > current mechanism does not seem easily extended to support the full > complement of Unicode properties (which is a new Level-2 RL). > > So if you are going to widen those again so you can have the properties > at your fingertips that you need to support grapheme clusters, it might > be worth thinking whether to refactor now or not. Performance and the > size of tables will someday become an issue, if not now. I do know the > Unicode docs mention this concern; I also know that we have people > rethinking how Perl grants access to properties, because even though we > do give you all of them, it could be done more tidily. > > I haven't thought much about what the non-regex interface to graphemes and > such should look like. Besides the ICU stuff, something you might want to > take a look at, just to see the sorts of things others are doing in the > non-regex grapheme arena, is these two classes: > > http://search.cpan.org/perldoc?Unicode::GCString > http://search.cpan.org/perldoc?Unicode::LineBreak > > It's Spartan, but it will give you an idea. I couldn't (well, wouldn't > *want* to) do East Asian text segmentation without those, which is > something I've done a bit of lately. Like all the good 3rd-party Unicode > modules in Perl, those two come from Asia. They're often the driving force > behind progress in Unicode support. With all those complicated scripts, > you can certainly see why, too. > > Hope this helps! > > --tom From lvjing at linux.vnet.ibm.com Mon Apr 25 16:12:52 2011 From: lvjing at linux.vnet.ibm.com (Jing LV) Date: Tue, 26 Apr 2011 00:12:52 +0800 Subject: BufferedOutputStream does not throw exception after it's closed In-Reply-To: <4D5CE3F0.1090704@oracle.com> References: <4D3EE928.1030701@linux.vnet.ibm.com> <4D3EEC37.5050004@univ-mlv.fr> <4D5CDAD4.4040704@linux.vnet.ibm.com> <4D5CE3F0.1090704@oracle.com> Message-ID: <4DB59D84.3070906@linux.vnet.ibm.com> ? 2011-2-17 17:01, Alan Bateman ??: > Jing LV wrote: >> : >> Thanks Remi. I've report this issue on the openjdk bugzilla. >> Any other comments on this? Can someone help to raise this issue on Sun >> bug system? Thanks in advance. >> > It's 7015589, sorry I should have been clearer in my mail of Jan 28 [1]. > > -Alan. > > [1] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-January/005781.html > Hi Alan, I have many trouble to find 7015589 - I thought it was on bugs.sun.com but search never return a correct result. I guess it was the problem of the system. However up to now I can find nothing. I aslo try it as a CR number, but I don't find it under ~alanb/7015589 . Would you please tell me what number is it and how can I check the status like this ( I remember there is a few on my list). Thanks! -- Best Regards, Jimmy, Jing LV From Lance.Andersen at oracle.com Mon Apr 25 16:28:55 2011 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Mon, 25 Apr 2011 12:28:55 -0400 Subject: Review request for 7038565, for a findbugs warning for BatchUpdateException In-Reply-To: <4DB2A5DC.8000204@oracle.com> References: <5CE3B0CD-918C-4E03-B349-CD886129DB8E@oracle.com> <4DB1ACD5.8010205@univ-mlv.fr> <4DB1C76B.4060605@univ-mlv.fr> <4DB2A5DC.8000204@oracle.com> Message-ID: <24CAE1E9-BB1A-425B-8B82-E6C9C8B3B362@oracle.com> As I have had suggestions to consider using Arrays.copyOf over clone(), I have pushed a webrev.02 which uses Arrays.copyOf. The diffs are at http://cr.openjdk.java.net/~lancea/7038565/ If you have any strong preferences, please let me know. Thank you to those who have provided input. Best Regards, Lance On Apr 23, 2011, at 6:11 AM, David Holmes wrote: > R?mi Forax said the following on 04/23/11 04:22: >> On 04/22/2011 06:51 PM, Lance Andersen - Oracle wrote: >>>> >>>> You should use clone() instead of Arrays.copyOf. >>> >>> Can you explain why you have a preference for clone() in this case? >> It does the job :) >> Arrays.copyOf() allows to resize the array. > > So? That's not a reason to not use Arrays.copyOf. Look at copyOf as the new improved version of clone. > > David > >>>> Also updateCounts should be declared final >>> >>> I will make updateCounts final. >>>> and initialized like this: >>>> >>>> public BatchUpdateException(String reason, String SQLState, int vendorCode, >>>> int []updateCounts,Throwable cause) { >>>> super(reason, SQLState, vendorCode, cause); >>>> this.updateCounts = (updateCounts == null)? null:updateCounts.clone(); >>>> } >>>> >>> >>> Regards, >>> lance >> regards, >> r?mi Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From neil.richards at ngmr.net Mon Apr 25 16:45:34 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Mon, 25 Apr 2011 17:45:34 +0100 Subject: Request for review: Optimize common-case UTF8 path for native ZipFile.getEntry calls In-Reply-To: References: Message-ID: <1303749934.13290.69.camel@chalkhill> Hi, Changeset 1aaeb8fbe705 [1] implemented a good set of enhancements, to allow the zip code to properly support zip files containing names and comments either encoded in non-UTF-8 codesets, or which contain supplementary characters. This support is achieved by doing the character conversion in Java code (using the code in ZipCoder.getBytes()), then feeding the resulting byte[] through to native code. This approach is more costly, both in terms of memory allocation and amount of data copying, than the preceding one, which did the conversion directly into a native byte[] using JNI's 'GetStringUTFRegion', which assumes a codeset of "modified UTF-8". The conversion performed for "modified UTF-8" is the same as that for standard UTF-8 for all codepoints except those for supplementary characters or for the character '\u0000' [2]. As the "common-case" is likely to be dealing with zip files with UTF-8 encoded names and comments containing neither supplementary characters nor '\u0000', the increase in cost of the conversion in this case is unfortunate. By introducing an extra check to determine if a UTF-8 encoded string may be safely converted using "modified UTF-8" (ie. to check that it has not any supplementary codepoints or '\u0000' in it), and using the aforementioned JNI routine to do the conversion if the check succeeds, I've noticed a decent performance improvement can be achieved by catering for this common-case. This benefit is particularly significant for applications which do a lot of rummaging around in zip files, or those involving lots of jar files and/or jar files with lots of entries in them. Please find below a changeset which implements the check I describe above ("isSafeToUseModifiedUTF8"), and uses it to choose whether to call a new modified-UTF8-specific variant of the native getEntry() method ("getEntryByModifiedUTF8"), which makes use of the JNI 'GetStringUTFRegion' method for the conversion. Please let me know if you have and comments, criticism of suggestions on this, Thanks, Neil [1] http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/1aaeb8fbe705 [2] http://java.sun.com/developer/technicalArticles/Intl/Supplementary/#Modified_UTF-8 -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU # HG changeset patch # User Neil Richards , # Date 1303394058 -3600 # Branch ojdk-121 # Node ID e5c8d8da677bce826b6bafc379d67c5d7775e7f6 # Parent 60d3d55dcc9c31a30ced9caa6ef5c0dcd7db031d Summary: Optimize name conversion when it is safe to use modified UTF-8 (common case) Contributed-by: diff -r 60d3d55dcc9c -r e5c8d8da677b make/java/zip/mapfile-vers --- a/make/java/zip/mapfile-vers Wed Apr 13 16:56:16 2011 -0700 +++ b/make/java/zip/mapfile-vers Thu Apr 21 14:54:18 2011 +0100 @@ -54,6 +54,7 @@ Java_java_util_zip_ZipFile_getCommentBytes; Java_java_util_zip_ZipFile_freeEntry; Java_java_util_zip_ZipFile_getEntry; + Java_java_util_zip_ZipFile_getEntryByModifiedUTF8; Java_java_util_zip_ZipFile_getEntryBytes; Java_java_util_zip_ZipFile_getEntryCrc; Java_java_util_zip_ZipFile_getEntryCSize; diff -r 60d3d55dcc9c -r e5c8d8da677b src/share/classes/java/util/zip/ZipFile.java --- a/src/share/classes/java/util/zip/ZipFile.java Wed Apr 13 16:56:16 2011 -0700 +++ b/src/share/classes/java/util/zip/ZipFile.java Thu Apr 21 14:54:18 2011 +0100 @@ -283,6 +283,24 @@ } } + private static boolean isSafeToUseModifiedUTF8(String s) { + final int length = s.length(); + + int codepoint; + // It's okay to step through the string one char at a time, as any + // codepoint encoded to more than one char will be greater or equal to + // Character.MIN_SUPPLEMENTARY_CODE_POINT, and so will have caused this + // method to return 'false'. + for (int i = 0; i < length; i++) { + codepoint = s.codePointAt(i); + if ((0 == codepoint) || + (codepoint >= Character.MIN_SUPPLEMENTARY_CODE_POINT)) { + return false; + } + } + return true; + } + /** * Returns the zip file entry for the specified name, or null * if not found. @@ -298,7 +316,13 @@ long jzentry = 0; synchronized (this) { ensureOpen(); - jzentry = getEntry(jzfile, zc.getBytes(name), true); + // Optimize if 'name' can be converted safely using + // "modified UTF-8" (common case) + if (zc.isUTF8() && isSafeToUseModifiedUTF8(name)) { + jzentry = getEntryByModifiedUTF8(jzfile, name, true); + } else { + jzentry = getEntry(jzfile, zc.getBytes(name), true); + } if (jzentry != 0) { ZipEntry ze = getZipEntry(name, jzentry); freeEntry(jzfile, jzentry); @@ -308,6 +332,9 @@ return null; } + private static native long getEntryByModifiedUTF8(long jzfile, String name, + boolean addSlash); + private static native long getEntry(long jzfile, byte[] name, boolean addSlash); @@ -339,8 +366,15 @@ ZipFileInputStream in = null; synchronized (this) { ensureOpen(); - if (!zc.isUTF8() && (entry.flag & EFS) != 0) { - jzentry = getEntry(jzfile, zc.getBytesUTF8(entry.name), false); + if (zc.isUTF8() || ((entry.flag & EFS) != 0)) { + // Optimize if 'entry.name' can be converted safely using + // "modified UTF-8" (common case) + if (isSafeToUseModifiedUTF8(entry.name)) { + jzentry = getEntryByModifiedUTF8(jzfile, entry.name, false); + } else { + jzentry = + getEntry(jzfile, zc.getBytesUTF8(entry.name), false); + } } else { jzentry = getEntry(jzfile, zc.getBytes(entry.name), false); } diff -r 60d3d55dcc9c -r e5c8d8da677b src/share/native/java/util/zip/ZipFile.c --- a/src/share/native/java/util/zip/ZipFile.c Wed Apr 13 16:56:16 2011 -0700 +++ b/src/share/native/java/util/zip/ZipFile.c Thu Apr 21 14:54:18 2011 +0100 @@ -142,11 +142,12 @@ ZIP_Close(jlong_to_ptr(zfile)); } +#define MAXNAME 1024 + JNIEXPORT jlong JNICALL Java_java_util_zip_ZipFile_getEntry(JNIEnv *env, jclass cls, jlong zfile, jbyteArray name, jboolean addSlash) { -#define MAXNAME 1024 jzfile *zip = jlong_to_ptr(zfile); jsize ulen = (*env)->GetArrayLength(env, name); char buf[MAXNAME+2], *path; @@ -170,6 +171,40 @@ } if (path != buf) { free(path); + path = NULL; + } + return ptr_to_jlong(ze); +} + +JNIEXPORT jlong JNICALL +Java_java_util_zip_ZipFile_getEntryByModifiedUTF8(JNIEnv *env, jclass cls, + jlong zfile, jstring name, jboolean addSlash) +{ + jzfile *zip = jlong_to_ptr(zfile); + jsize slen = (*env)->GetStringLength(env, name); + jsize ulen = (*env)->GetStringUTFLength(env, name); + char buf[MAXNAME+2], *path; + jzentry *ze; + + if (ulen > MAXNAME) { + path = malloc(ulen + 2); + if (path == 0) { + JNU_ThrowOutOfMemoryError(env, 0); + return 0; + } + } else { + path = buf; + } + (*env)->GetStringUTFRegion(env, name, 0, slen, path); + path[ulen] = '\0'; + if (addSlash == JNI_FALSE) { + ze = ZIP_GetEntry(zip, path, 0); + } else { + ze = ZIP_GetEntry(zip, path, (jint)ulen); + } + if (path != buf) { + free(path); + path = NULL; } return ptr_to_jlong(ze); } From mandy.chung at oracle.com Mon Apr 25 16:48:19 2011 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 25 Apr 2011 09:48:19 -0700 Subject: BufferedOutputStream does not throw exception after it's closed In-Reply-To: <4DB59D84.3070906@linux.vnet.ibm.com> References: <4D3EE928.1030701@linux.vnet.ibm.com> <4D3EEC37.5050004@univ-mlv.fr> <4D5CDAD4.4040704@linux.vnet.ibm.com> <4D5CE3F0.1090704@oracle.com> <4DB59D84.3070906@linux.vnet.ibm.com> Message-ID: <4DB5A5D3.1060805@oracle.com> Hi Jing, On 04/25/11 09:12, Jing LV wrote: > Hi Alan, > I have many trouble to find 7015589 - I thought it was on bugs.sun.com > but search never return a correct result. I guess it was the problem > of the system. However up to now I can find nothing. I aslo try it as > a CR number, but I don't find it under ~alanb/7015589 . Would you > please tell me what number is it and how can I check the status like > this ( I remember there is a few on my list). I think this is what you are looking for: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7015589 Mandy From jonathan.gibbons at oracle.com Mon Apr 25 22:51:39 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 25 Apr 2011 22:51:39 +0000 Subject: hg: jdk7/tl/langtools: 7039019: test cannot run standalone Message-ID: <20110425225142.4C1C147FCB@hg.openjdk.java.net> Changeset: fb84cfca28a1 Author: jjg Date: 2011-04-25 15:50 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/fb84cfca28a1 7039019: test cannot run standalone Reviewed-by: dlsmith ! test/tools/javac/processing/model/TestSymtabItems.java From jonathan.gibbons at oracle.com Mon Apr 25 22:56:27 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 25 Apr 2011 22:56:27 +0000 Subject: hg: jdk7/tl/langtools: 7038363: cast from object to primitive should be for source >= 1.7 Message-ID: <20110425225629.C1B4D47FCC@hg.openjdk.java.net> Changeset: 4c5f13798b8d Author: jjg Date: 2011-04-25 15:56 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/4c5f13798b8d 7038363: cast from object to primitive should be for source >= 1.7 Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/types/CastObjectToPrimitiveTest.java + test/tools/javac/types/CastObjectToPrimitiveTest.out From forax at univ-mlv.fr Tue Apr 26 00:51:32 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 26 Apr 2011 02:51:32 +0200 Subject: Review request for 7038565, for a findbugs warning for BatchUpdateException In-Reply-To: <24CAE1E9-BB1A-425B-8B82-E6C9C8B3B362@oracle.com> References: <5CE3B0CD-918C-4E03-B349-CD886129DB8E@oracle.com> <4DB1ACD5.8010205@univ-mlv.fr> <4DB1C76B.4060605@univ-mlv.fr> <4DB2A5DC.8000204@oracle.com> <24CAE1E9-BB1A-425B-8B82-E6C9C8B3B362@oracle.com> Message-ID: <4DB61714.9070205@univ-mlv.fr> On 04/25/2011 06:28 PM, Lance Andersen - Oracle wrote: > As I have had suggestions to consider using Arrays.copyOf over clone(), I have pushed a webrev.02 which uses Arrays.copyOf. The diffs are at http://cr.openjdk.java.net/~lancea/7038565/ > > > If you have any strong preferences, please let me know. I think you should use Arrays.copyOfRange instead of Arrays.copyOf because it looks as an improved version of Arrays.copyOf. sorry just kidding :) > > Thank you to those who have provided input. > > > Best Regards, > Lance regards, R?mi > On Apr 23, 2011, at 6:11 AM, David Holmes wrote: > >> R?mi Forax said the following on 04/23/11 04:22: >>> On 04/22/2011 06:51 PM, Lance Andersen - Oracle wrote: >>>>> You should use clone() instead of Arrays.copyOf. >>>> Can you explain why you have a preference for clone() in this case? >>> It does the job :) >>> Arrays.copyOf() allows to resize the array. >> So? That's not a reason to not use Arrays.copyOf. Look at copyOf as the new improved version of clone. >> >> David >> >>>>> Also updateCounts should be declared final >>>> I will make updateCounts final. >>>>> and initialized like this: >>>>> >>>>> public BatchUpdateException(String reason, String SQLState, int vendorCode, >>>>> int []updateCounts,Throwable cause) { >>>>> super(reason, SQLState, vendorCode, cause); >>>>> this.updateCounts = (updateCounts == null)? null:updateCounts.clone(); >>>>> } >>>>> >>>> Regards, >>>> lance >>> regards, >>> r?mi > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > From lvjing at linux.vnet.ibm.com Tue Apr 26 08:24:05 2011 From: lvjing at linux.vnet.ibm.com (Jing LV) Date: Tue, 26 Apr 2011 16:24:05 +0800 Subject: A method with return type size_t returns negative value In-Reply-To: <4D8B3A6B.8040005@oracle.com> References: <4D89BB76.5060900@linux.vnet.ibm.com> <4D89CA29.7040302@oracle.com> <4D8AF3C4.7020005@linux.vnet.ibm.com> <4D8B3A6B.8040005@oracle.com> Message-ID: <4DB68125.7080003@linux.vnet.ibm.com> Hello, Thanks for raising the defect. I see there is no patch now, so I create one (as the defect mentioned jint may be good, I use jint here). I have no Sun Online Account Id, would someone take a look? diff --git a/src/windows/native/java/io/io_util_md.c b/src/windows/native/java/io/io_util_md.c index 345f955..50bc988 100644 --- a/src/windows/native/java/io/io_util_md.c +++ b/src/windows/native/java/io/io_util_md.c @@ -478,7 +478,7 @@ handleSetLength(jlong fd, jlong length) { } JNIEXPORT -size_t +jint handleRead(jlong fd, void *buf, jint len) { DWORD read = 0; @@ -502,7 +502,7 @@ handleRead(jlong fd, void *buf, jint len) return read; } -static size_t writeInternal(jlong fd, const void *buf, jint len, jboolean append) +static jint writeInternal(jlong fd, const void *buf, jint len, jboolean append) { BOOL result = 0; DWORD written = 0; @@ -527,16 +527,16 @@ static size_t writeInternal(jlong fd, const void *buf, jint len, jboolean append if ((h == INVALID_HANDLE_VALUE) || (result == 0)) { return -1; } - return (size_t)written; + return (jint)written; } JNIEXPORT -size_t handleWrite(jlong fd, const void *buf, jint len) { +jint handleWrite(jlong fd, const void *buf, jint len) { return writeInternal(fd, buf, len, JNI_FALSE); } JNIEXPORT -size_t handleAppend(jlong fd, const void *buf, jint len) { +jint handleAppend(jlong fd, const void *buf, jint len) { return writeInternal(fd, buf, len, JNI_TRUE); } ? 2011-3-24 20:34, Alan Bateman ??: > Jing LV wrote: >> : >> Thanks Alan. Would you please tell me the bug number? > The bug now tracking this is: > > 7030624: size_t usages in src/windows/native/java/io/io_util_md.c need > to be re-visited > > -Alan. > -- Best Regards, Jimmy, Jing LV From Alan.Bateman at oracle.com Tue Apr 26 08:43:27 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 26 Apr 2011 09:43:27 +0100 Subject: A method with return type size_t returns negative value In-Reply-To: <4DB68125.7080003@linux.vnet.ibm.com> References: <4D89BB76.5060900@linux.vnet.ibm.com> <4D89CA29.7040302@oracle.com> <4D8AF3C4.7020005@linux.vnet.ibm.com> <4D8B3A6B.8040005@oracle.com> <4DB68125.7080003@linux.vnet.ibm.com> Message-ID: <4DB685AF.9070602@oracle.com> Jing LV wrote: > Hello, > > Thanks for raising the defect. I see there is no patch now, so I > create one (as the defect mentioned jint may be good, I use jint here). > I have no Sun Online Account Id, would someone take a look? The function prototypes would also require to be updated and there are a couple of other areas that would require clean-up too. If it's okay with you, I think we should postpone this to jdk8. This code has been using size_t for many years and I don't think is actually causing a real problem. I agree it should be cleaned up but we are out of time in jdk7. Another point is that jdk8 will be our opportunity to remove the dependencies on the JVM_* functions and so this code will be changing anyway (I realize we're not using these in the Windows code but the functions need to match as they are used from shared code). -Alan. From spoole at linux.vnet.ibm.com Tue Apr 26 09:12:20 2011 From: spoole at linux.vnet.ibm.com (Steve Poole) Date: Tue, 26 Apr 2011 10:12:20 +0100 Subject: A method with return type size_t returns negative value In-Reply-To: <4DB685AF.9070602@oracle.com> References: <4D89BB76.5060900@linux.vnet.ibm.com> <4D89CA29.7040302@oracle.com> <4D8AF3C4.7020005@linux.vnet.ibm.com> <4D8B3A6B.8040005@oracle.com> <4DB68125.7080003@linux.vnet.ibm.com> <4DB685AF.9070602@oracle.com> Message-ID: <4DB68C74.2040809@linux.vnet.ibm.com> On 26/04/11 09:43, Alan Bateman wrote: > . Another point is that jdk8 will be our opportunity to remove the > dependencies on the JVM_* functions > That sounds interesting Alan - care to share more? From Alan.Bateman at oracle.com Tue Apr 26 09:20:39 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 26 Apr 2011 10:20:39 +0100 Subject: Fwd: Re: Codereview Request: 7039066 j.u.rgex does not match TR#18 RL1.4 Simple Word Boundaries and RL1.2 Properties In-Reply-To: <4DB508E8.5010907@oracle.com> References: <4DB381FD.7050600@oracle.com> <4DB46A67.8010106@oracle.com> <4DB508E8.5010907@oracle.com> Message-ID: <4DB68E67.3050207@oracle.com> Xueming Shen wrote: > Thanks Mark! > > Let's go with UNICODE_PROPERTY, if there is no objection. I went through the updates to the javadoc and the approach looks good and nicely done. A minor comment is that the compile(String,int) method repeats the list of flags that are allowed so that should be updated to list the new flag. I don't know if you have a reviewer for the implementation changes yet; if not then I'll try to go through them later in the week. It looks like the outstanding question is the name of the flag. As it enables the predefined and POSIX character classes to be the Unicode versions then I think UNICODE_CHARACTER_CLASS (or _CLASSES) would be clearer to the reader. UNICODE_CLASSES is shorter but might cause someone to think java.lang.Class rather than character classes. I'm not sure whether the singular or plural name is better but the existing flags are a mix of singular and plural. -Alan From Alan.Bateman at oracle.com Tue Apr 26 09:40:33 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 26 Apr 2011 10:40:33 +0100 Subject: A method with return type size_t returns negative value In-Reply-To: <4DB68C74.2040809@linux.vnet.ibm.com> References: <4D89BB76.5060900@linux.vnet.ibm.com> <4D89CA29.7040302@oracle.com> <4D8AF3C4.7020005@linux.vnet.ibm.com> <4D8B3A6B.8040005@oracle.com> <4DB68125.7080003@linux.vnet.ibm.com> <4DB685AF.9070602@oracle.com> <4DB68C74.2040809@linux.vnet.ibm.com> Message-ID: <4DB69311.1020904@oracle.com> Steve Poole wrote: > On 26/04/11 09:43, Alan Bateman wrote: > >> . Another point is that jdk8 will be our opportunity to remove the >> dependencies on the JVM_* functions >> > > That sounds interesting Alan - care to share more? > As you know, it's really hard to remove things from the JDK. Medals are few. One thing that we've been trying to get rid of for many years is legacy interruptible I/O support, a troublesome mis-feature that dates back to jdk1.0. This is why older areas of the libraries (java.io and java.net specifically) call into the VM via JVM_* functions to do I/O. Back in jdk6 we added a VM option to allow the mechanism be disabled. Early in jdk7 the default option was changed so that it is now disabled by default. Once jdk8 opens then we should be able to remove the mechanism and clean-up the library code so that it no longer calls into the VM. My point to Jing LV was that this would seem a more appropriate time to do the clean-up he is suggesting. -Alan. From spoole at linux.vnet.ibm.com Tue Apr 26 10:44:24 2011 From: spoole at linux.vnet.ibm.com (Steve Poole) Date: Tue, 26 Apr 2011 11:44:24 +0100 Subject: A method with return type size_t returns negative value In-Reply-To: <4DB69311.1020904@oracle.com> References: <4D89BB76.5060900@linux.vnet.ibm.com> <4D89CA29.7040302@oracle.com> <4D8AF3C4.7020005@linux.vnet.ibm.com> <4D8B3A6B.8040005@oracle.com> <4DB68125.7080003@linux.vnet.ibm.com> <4DB685AF.9070602@oracle.com> <4DB68C74.2040809@linux.vnet.ibm.com> <4DB69311.1020904@oracle.com> Message-ID: <4DB6A208.3070209@linux.vnet.ibm.com> On 26/04/11 10:40, Alan Bateman wrote: > Steve Poole wrote: >> On 26/04/11 09:43, Alan Bateman wrote: >> >>> . Another point is that jdk8 will be our opportunity to remove the >>> dependencies on the JVM_* functions >>> >> >> That sounds interesting Alan - care to share more? >> > As you know, it's really hard to remove things from the JDK. Medals > are few. One thing that we've been trying to get rid of for many years > is legacy interruptible I/O support, a troublesome mis-feature that > dates back to jdk1.0. This is why older areas of the libraries > (java.io and java.net specifically) call into the VM via JVM_* > functions to do I/O. Back in jdk6 we added a VM option to allow the > mechanism be disabled. Early in jdk7 the default option was changed so > that it is now disabled by default. Once jdk8 opens then we should be > able to remove the mechanism and clean-up the library code so that it > no longer calls into the VM. My point to Jing LV was that this would > seem a more appropriate time to do the clean-up he is suggesting. > > -Alan. Ok Alan - thanks for the background. I must of missed the VM option along the way - what's it called? From Alan.Bateman at oracle.com Tue Apr 26 10:54:15 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 26 Apr 2011 11:54:15 +0100 Subject: A method with return type size_t returns negative value In-Reply-To: <4DB6A208.3070209@linux.vnet.ibm.com> References: <4D89BB76.5060900@linux.vnet.ibm.com> <4D89CA29.7040302@oracle.com> <4D8AF3C4.7020005@linux.vnet.ibm.com> <4D8B3A6B.8040005@oracle.com> <4DB68125.7080003@linux.vnet.ibm.com> <4DB685AF.9070602@oracle.com> <4DB68C74.2040809@linux.vnet.ibm.com> <4DB69311.1020904@oracle.com> <4DB6A208.3070209@linux.vnet.ibm.com> Message-ID: <4DB6A457.9050300@oracle.com> Steve Poole wrote: > > Ok Alan - thanks for the background. I must of missed the VM option > along the way - what's it called? > It's HotSpot specific and is named UseVMInterruptibleIO. -Alan From nils.loodin at oracle.com Tue Apr 26 10:48:15 2011 From: nils.loodin at oracle.com (nils.loodin at oracle.com) Date: Tue, 26 Apr 2011 10:48:15 +0000 Subject: hg: jdk7/tl/jdk: 7029383: Refresh of non-client demos Message-ID: <20110426104825.6B5EF47FE8@hg.openjdk.java.net> Changeset: 8b36b1c4bb7f Author: nloodin Date: 2011-04-26 12:49 +0200 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8b36b1c4bb7f 7029383: Refresh of non-client demos Reviewed-by: mchung, ohair ! src/share/classes/com/sun/tools/example/debug/bdi/AccessWatchpointSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/AmbiguousMethodException.java ! src/share/classes/com/sun/tools/example/debug/bdi/BreakpointSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/ChildSession.java ! src/share/classes/com/sun/tools/example/debug/bdi/EvaluationException.java ! src/share/classes/com/sun/tools/example/debug/bdi/EventRequestSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/ExceptionSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/ExecutionManager.java ! src/share/classes/com/sun/tools/example/debug/bdi/FrameIndexOutOfBoundsException.java ! src/share/classes/com/sun/tools/example/debug/bdi/JDIEventSource.java ! src/share/classes/com/sun/tools/example/debug/bdi/LineBreakpointSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/LineNotFoundException.java ! src/share/classes/com/sun/tools/example/debug/bdi/MalformedMemberNameException.java ! src/share/classes/com/sun/tools/example/debug/bdi/MethodBreakpointSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/MethodNotFoundException.java ! src/share/classes/com/sun/tools/example/debug/bdi/ModificationWatchpointSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/NoSessionException.java ! src/share/classes/com/sun/tools/example/debug/bdi/NoThreadException.java ! src/share/classes/com/sun/tools/example/debug/bdi/PatternReferenceTypeSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/ReferenceTypeSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/Session.java ! src/share/classes/com/sun/tools/example/debug/bdi/SourceNameReferenceTypeSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/SpecErrorEvent.java ! src/share/classes/com/sun/tools/example/debug/bdi/SpecEvent.java ! src/share/classes/com/sun/tools/example/debug/bdi/ThreadGroupIterator.java ! src/share/classes/com/sun/tools/example/debug/bdi/ThreadInfo.java ! src/share/classes/com/sun/tools/example/debug/bdi/ThreadIterator.java ! src/share/classes/com/sun/tools/example/debug/bdi/Utils.java ! src/share/classes/com/sun/tools/example/debug/bdi/VMLaunchFailureException.java ! src/share/classes/com/sun/tools/example/debug/bdi/VMNotInterruptedException.java ! src/share/classes/com/sun/tools/example/debug/bdi/WatchpointSpec.java ! src/share/classes/com/sun/tools/example/debug/event/AbstractEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/AccessWatchpointEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ClassPrepareEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ClassUnloadEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ExceptionEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/JDIAdapter.java ! src/share/classes/com/sun/tools/example/debug/event/LocatableEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/LocationTriggerEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ModificationWatchpointEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ThreadDeathEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ThreadStartEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/VMDeathEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/VMDisconnectEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/VMStartEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/WatchpointEventSet.java ! src/share/classes/com/sun/tools/example/debug/expr/ExpressionParser.java ! src/share/classes/com/sun/tools/example/debug/expr/ExpressionParserTokenManager.java ! src/share/classes/com/sun/tools/example/debug/expr/LValue.java ! src/share/classes/com/sun/tools/example/debug/expr/ParseException.java ! src/share/classes/com/sun/tools/example/debug/expr/Token.java ! src/share/classes/com/sun/tools/example/debug/expr/TokenMgrError.java ! src/share/classes/com/sun/tools/example/debug/gui/ApplicationTool.java ! src/share/classes/com/sun/tools/example/debug/gui/ClassTreeTool.java ! src/share/classes/com/sun/tools/example/debug/gui/CommandInterpreter.java ! src/share/classes/com/sun/tools/example/debug/gui/CommandTool.java ! src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java ! src/share/classes/com/sun/tools/example/debug/gui/CurrentFrameChangedEvent.java ! src/share/classes/com/sun/tools/example/debug/gui/Environment.java ! src/share/classes/com/sun/tools/example/debug/gui/GUI.java ! src/share/classes/com/sun/tools/example/debug/gui/JDBFileFilter.java ! src/share/classes/com/sun/tools/example/debug/gui/JDBMenuBar.java ! src/share/classes/com/sun/tools/example/debug/gui/JDBToolBar.java ! src/share/classes/com/sun/tools/example/debug/gui/LaunchTool.java ! src/share/classes/com/sun/tools/example/debug/gui/MonitorListModel.java ! src/share/classes/com/sun/tools/example/debug/gui/MonitorTool.java ! src/share/classes/com/sun/tools/example/debug/gui/SearchPath.java ! src/share/classes/com/sun/tools/example/debug/gui/SingleLeafTreeSelectionModel.java ! src/share/classes/com/sun/tools/example/debug/gui/SourceManager.java ! src/share/classes/com/sun/tools/example/debug/gui/SourceModel.java ! src/share/classes/com/sun/tools/example/debug/gui/SourceTool.java ! src/share/classes/com/sun/tools/example/debug/gui/SourceTreeTool.java ! src/share/classes/com/sun/tools/example/debug/gui/SourcepathChangedEvent.java ! src/share/classes/com/sun/tools/example/debug/gui/StackTraceTool.java ! src/share/classes/com/sun/tools/example/debug/gui/ThreadTreeTool.java ! src/share/classes/com/sun/tools/example/debug/gui/TypeScript.java ! src/share/classes/com/sun/tools/example/debug/gui/TypeScriptOutputListener.java ! src/share/classes/com/sun/tools/example/debug/gui/TypeScriptWriter.java ! src/share/classes/com/sun/tools/example/debug/tty/AccessWatchpointSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/AmbiguousMethodException.java ! src/share/classes/com/sun/tools/example/debug/tty/BreakpointSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/Commands.java ! src/share/classes/com/sun/tools/example/debug/tty/Env.java ! src/share/classes/com/sun/tools/example/debug/tty/EventHandler.java ! src/share/classes/com/sun/tools/example/debug/tty/EventRequestSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/EventRequestSpecList.java ! src/share/classes/com/sun/tools/example/debug/tty/ExceptionSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/LineNotFoundException.java ! src/share/classes/com/sun/tools/example/debug/tty/MalformedMemberNameException.java ! src/share/classes/com/sun/tools/example/debug/tty/ModificationWatchpointSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/PatternReferenceTypeSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/ReferenceTypeSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/SourceMapper.java ! src/share/classes/com/sun/tools/example/debug/tty/TTY.java ! src/share/classes/com/sun/tools/example/debug/tty/TTYResources.java ! src/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java ! src/share/classes/com/sun/tools/example/debug/tty/TTYResources_zh_CN.java ! src/share/classes/com/sun/tools/example/debug/tty/ThreadGroupIterator.java ! src/share/classes/com/sun/tools/example/debug/tty/ThreadInfo.java ! src/share/classes/com/sun/tools/example/debug/tty/ThreadIterator.java ! src/share/classes/com/sun/tools/example/debug/tty/VMConnection.java ! src/share/classes/com/sun/tools/example/debug/tty/VMNotConnectedException.java ! src/share/classes/com/sun/tools/example/debug/tty/WatchpointSpec.java ! src/share/classes/com/sun/tools/example/trace/EventThread.java ! src/share/classes/com/sun/tools/example/trace/StreamRedirectThread.java ! src/share/classes/com/sun/tools/example/trace/Trace.java ! src/share/demo/jvmti/minst/Minst.java ! src/share/demo/management/FullThreadDump/Deadlock.java ! src/share/demo/management/FullThreadDump/ThreadMonitor.java ! src/share/demo/management/JTop/JTop.java ! src/share/demo/management/JTop/JTopPlugin.java ! src/share/demo/management/MemoryMonitor/MemoryMonitor.java ! src/share/demo/management/VerboseGC/PrintGCStat.java ! src/share/demo/management/VerboseGC/VerboseGC.java ! src/share/demo/nio/zipfs/Demo.java ! src/share/demo/scripting/jconsole-plugin/src/com/sun/demo/scripting/jconsole/EditableAtEndDocument.java ! src/share/demo/scripting/jconsole-plugin/src/com/sun/demo/scripting/jconsole/ScriptJConsolePlugin.java ! src/share/demo/scripting/jconsole-plugin/src/com/sun/demo/scripting/jconsole/ScriptShellPanel.java From stuart.marks at oracle.com Tue Apr 26 15:20:32 2011 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 26 Apr 2011 08:20:32 -0700 Subject: array clone() vs Arrays.copyOf() In-Reply-To: <24CAE1E9-BB1A-425B-8B82-E6C9C8B3B362@oracle.com> References: <5CE3B0CD-918C-4E03-B349-CD886129DB8E@oracle.com> <4DB1ACD5.8010205@univ-mlv.fr> <4DB1C76B.4060605@univ-mlv.fr> <4DB2A5DC.8000204@oracle.com> <24CAE1E9-BB1A-425B-8B82-E6C9C8B3B362@oracle.com> Message-ID: <4DB6E2C0.3000503@oracle.com> Hi David, I have a general code style question about this. This arose in the review of Lance's webrevs for 7038565 [1] but I'm starting a new thread since I don't want further discussion to drag out that review. In that review, Lance initially used Arrays.copyOf() to do defensive copying of an array. R?mi suggested calling clone() instead, and Lance changed it, but it looks like you (David) convinced him to change it back to use Arrays.copyOf(). (Quotes from the emails are below, but the attribution is hard to follow.) What's the rationale for using Arrays.copyOf() in this case? To me, clone() is the clearest and most concise way of making the copy. Arrays.copyOf() is slightly more verbose and the reader has to do a tiny bit of analysis to determine that the length isn't being changed, since the value passed is the current length. Is there some other reason I'm not aware of that Arrays.copyOf() should be preferred? I guess, one point is that it's hard to find the javadoc for the array clone() call. :-) I guess I'm mainly aiming this at David since he seemed to be the strongest advocate for the use of Arrays.copyOf(), but I'd welcome opinions from others as well. s'marks [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-April/006694.html On 4/25/11 9:28 AM, Lance Andersen - Oracle wrote: > On Apr 23, 2011, at 6:11 AM, David Holmes wrote: > >> > R?mi Forax said the following on 04/23/11 04:22: >>> >> On 04/22/2011 06:51 PM, Lance Andersen - Oracle wrote: >>>>> >>>> >>>>> >>>> You should use clone() instead of Arrays.copyOf. >>>> >>> >>>> >>> Can you explain why you have a preference for clone() in this case? >>> >> It does the job :) >>> >> Arrays.copyOf() allows to resize the array. >> > >> > So? That's not a reason to not use Arrays.copyOf. Look at copyOf as the new improved version of clone. >> > From xueming.shen at oracle.com Tue Apr 26 16:33:41 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 26 Apr 2011 09:33:41 -0700 Subject: Fwd: Re: Codereview Request: 7039066 j.u.rgex does not match TR#18 RL1.4 Simple Word Boundaries and RL1.2 Properties In-Reply-To: <4DB68E67.3050207@oracle.com> References: <4DB381FD.7050600@oracle.com> <4DB46A67.8010106@oracle.com> <4DB508E8.5010907@oracle.com> <4DB68E67.3050207@oracle.com> Message-ID: <4DB6F3E5.9010704@oracle.com> On 04-26-2011 2:20 AM, Alan Bateman wrote: > Xueming Shen wrote: >> Thanks Mark! >> >> Let's go with UNICODE_PROPERTY, if there is no objection. > I went through the updates to the javadoc and the approach looks good > and nicely done. A minor comment is that the compile(String,int) > method repeats the list of flags that are allowed so that should be > updated to list the new flag. I don't know if you have a reviewer for > the implementation changes yet; if not then I'll try to go through > them later in the week. > > It looks like the outstanding question is the name of the flag. As it > enables the predefined and POSIX character classes to be the Unicode > versions then I think UNICODE_CHARACTER_CLASS (or _CLASSES) would be > clearer to the reader. UNICODE_CLASSES is shorter but might cause > someone to think java.lang.Class rather than character classes. I'm > not sure whether the singular or plural name is better but the > existing flags are a mix of singular and plural. Thanks Alan! UNICODE_CHARACTER_CLASS is clear and straightforward. I am OK with it. The webrev, ccc and api docs have been updated accordingly. Yes, I still need a reviewer for the implementation changes. Tom has helped review the doc (and the definition of those properties). Thanks, Sherman > -Alan From joe.darcy at oracle.com Tue Apr 26 17:35:27 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 26 Apr 2011 17:35:27 +0000 Subject: hg: jdk7/tl/jdk: 7039369: Limit range of strictfp in FloatingDecimal Message-ID: <20110426173545.3697A47FF8@hg.openjdk.java.net> Changeset: 147da2c8b749 Author: darcy Date: 2011-04-26 10:35 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/147da2c8b749 7039369: Limit range of strictfp in FloatingDecimal Summary: Additional reviews by sergey.kuksenko at oracle.com Reviewed-by: alanb ! src/share/classes/sun/misc/FloatingDecimal.java ! src/share/classes/sun/misc/FormattedFloatingDecimal.java ! test/java/lang/Double/ParseDouble.java From xueming.shen at oracle.com Tue Apr 26 20:14:16 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 26 Apr 2011 13:14:16 -0700 Subject: Request for review: Optimize common-case UTF8 path for native ZipFile.getEntry calls In-Reply-To: <1303749934.13290.69.camel@chalkhill> References: <1303749934.13290.69.camel@chalkhill> Message-ID: <4DB72798.3080900@oracle.com> Hi Neil, Thanks for looking into this performance problem. I had the assumption that (1) code conversion is really a small portion of the overall Zip read/write operation (2) I will have the time to do the same optimization for UTF_8 charset as I did for other singlebyte charsets [2] in JDK7 time frame when worked on the changeset 1aaeb8fbe705 [1]. It appears I was a little optimistic on my planning :-( just never had chance to go back to my charset work after that. But obviously if we only look at the utf8 conversion performance, to use the standard UTF_8 charset is slower compared to the original embedded utf8 conversion methods. The patch definitely improves the situation, I did some measurement simply on ZipFile.getEntry(String) as showed below on a jar file with a single entry named "abcdefghijklmnopqrstuvwxyz". public static void main(String[] args) throws Throwable { ZipFile zf = new ZipFile(args[0]); String ename = args[1]; if (zf.getEntry(ename) == null) { System.out.println("no such entry:" + ename); System.exit(1); } // warmup for (int i = 0; i < 10000; i++) { zf.getEntry(ename); } long t0 = System.currentTimeMillis(); for (int i = 0; i < 100000; i++) { zf.getEntry(ename); } long t1 = System.currentTimeMillis(); System.out.printf("time=%d%n", t1-t0); zf.close(); } It shows the WithoutPath/WithPatch ratio = 125/107 (this is not an accurate measurement of the utf8 conversion though, just give us a rough idea) However, the approach (1) is only about the zc.getBytesUTF8(), we should do the same thing for zc.toStringUTF8(). And ZipIn/OutputStream also uses ZipCoder. (2) is kinda against the direction that we are planning to do in the future release, in which we might want to bring most of the ZipFile access code up to Java level from native C code, we have a pure Java ZipFile (no zlib, yet) implementation in the zip filesystem code at src/share/demo/nio/zipfs already, we should probably do the same thing for ZipFile as well. Sure we will have to keep the native code anyway for vm access during boot. (3) And once we put the UTF-8 optimization work in, we probably have to again back this one out. I do have the UTF_8 optimization code ready (not fully tested though), I also ran the same test above, I got the number around "85". The webrev for the utf-8 optimization is at http://cr.openjdk.java.net/~sherman/utf8Str/webrev with the "improvement" showed at [3] [4] Any codereview volunteer ? :-) maybe just too late for 7. -Sherman [1] http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/1aaeb8fbe705 [2] http://blogs.sun.com/xuemingshen/entry/faster_new_string_bytes_cs [3] http://cr.openjdk.java.net/~sherman/utf8Str/client [4] http://cr.openjdk.java.net/~sherman/utf8Str/server On 04/25/2011 09:45 AM, Neil Richards wrote: > Hi, > Changeset 1aaeb8fbe705 [1] implemented a good set of enhancements, to > allow the zip code to properly support zip files containing names and > comments either encoded in non-UTF-8 codesets, or which contain > supplementary characters. > > This support is achieved by doing the character conversion in Java code > (using the code in ZipCoder.getBytes()), then feeding the resulting > byte[] through to native code. > > This approach is more costly, both in terms of memory allocation and > amount of data copying, than the preceding one, which did the conversion > directly into a native byte[] using JNI's 'GetStringUTFRegion', which > assumes a codeset of "modified UTF-8". > > The conversion performed for "modified UTF-8" is the same as that for > standard UTF-8 for all codepoints except those for supplementary > characters or for the character '\u0000' [2]. > > As the "common-case" is likely to be dealing with zip files with UTF-8 > encoded names and comments containing neither supplementary characters > nor '\u0000', the increase in cost of the conversion in this case is > unfortunate. > > By introducing an extra check to determine if a UTF-8 encoded string may > be safely converted using "modified UTF-8" (ie. to check that it has not > any supplementary codepoints or '\u0000' in it), and using the > aforementioned JNI routine to do the conversion if the check succeeds, > I've noticed a decent performance improvement can be achieved by > catering for this common-case. > > This benefit is particularly significant for applications which do a lot > of rummaging around in zip files, or those involving lots of jar files > and/or jar files with lots of entries in them. > > Please find below a changeset which implements the check I describe > above ("isSafeToUseModifiedUTF8"), and uses it to choose whether to call > a new modified-UTF8-specific variant of the native getEntry() method > ("getEntryByModifiedUTF8"), which makes use of the JNI > 'GetStringUTFRegion' method for the conversion. > > Please let me know if you have and comments, criticism of suggestions on > this, > Thanks, > Neil > > [1] http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/1aaeb8fbe705 > [2] http://java.sun.com/developer/technicalArticles/Intl/Supplementary/#Modified_UTF-8 > From David.Holmes at oracle.com Wed Apr 27 00:34:52 2011 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 27 Apr 2011 10:34:52 +1000 Subject: array clone() vs Arrays.copyOf() In-Reply-To: <4DB6E2C0.3000503@oracle.com> References: <5CE3B0CD-918C-4E03-B349-CD886129DB8E@oracle.com> <4DB1ACD5.8010205@univ-mlv.fr> <4DB1C76B.4060605@univ-mlv.fr> <4DB2A5DC.8000204@oracle.com> <24CAE1E9-BB1A-425B-8B82-E6C9C8B3B362@oracle.com> <4DB6E2C0.3000503@oracle.com> Message-ID: <4DB764AC.8030002@oracle.com> Hi Stuart, Actually my comments more a response to Remi's assertion that clone should have been used instead, without giving any technical rationale as to why clone would be better, and so much better that it warranted Lance changing the code. Personally I think we should be steering people to Arrays.copyOf for all their array copying needs. clone() is effectively legacy code. It may have a small performance benefit though ultimately both methods are intrinisified by the same C2 code so I don't believe the gain would be much, and likely only with smaller arrays. BTW I think Lance received communication from others over the use of copyOf versus clone, I never made any additional comments on the relative merits. Cheers, David Stuart Marks said the following on 04/27/11 01:20: > Hi David, > > I have a general code style question about this. This arose in the > review of Lance's webrevs for 7038565 [1] but I'm starting a new thread > since I don't want further discussion to drag out that review. > > In that review, Lance initially used Arrays.copyOf() to do defensive > copying of an array. R?mi suggested calling clone() instead, and Lance > changed it, but it looks like you (David) convinced him to change it > back to use Arrays.copyOf(). > > (Quotes from the emails are below, but the attribution is hard to follow.) > > What's the rationale for using Arrays.copyOf() in this case? To me, > clone() is the clearest and most concise way of making the copy. > Arrays.copyOf() is slightly more verbose and the reader has to do a tiny > bit of analysis to determine that the length isn't being changed, since > the value passed is the current length. Is there some other reason I'm > not aware of that Arrays.copyOf() should be preferred? > > I guess, one point is that it's hard to find the javadoc for the array > clone() call. :-) > > I guess I'm mainly aiming this at David since he seemed to be the > strongest advocate for the use of Arrays.copyOf(), but I'd welcome > opinions from others as well. > > s'marks > > [1] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-April/006694.html > > On 4/25/11 9:28 AM, Lance Andersen - Oracle wrote: >> On Apr 23, 2011, at 6:11 AM, David Holmes wrote: >> >>> > R?mi Forax said the following on 04/23/11 04:22: >>>> >> On 04/22/2011 06:51 PM, Lance Andersen - Oracle wrote: >>>>>> >>>> >>>>>> >>>> You should use clone() instead of Arrays.copyOf. >>>>> >>> >>>>> >>> Can you explain why you have a preference for clone() in this >>>>> case? >>>> >> It does the job :) >>>> >> Arrays.copyOf() allows to resize the array. >>> > >>> > So? That's not a reason to not use Arrays.copyOf. Look at copyOf >>> as the new improved version of clone. >>> > From joe.darcy at oracle.com Wed Apr 27 01:53:23 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 26 Apr 2011 18:53:23 -0700 Subject: Unreachable catch classes Message-ID: <4DB77713.1030101@oracle.com> Hello. FYI, javac in JDK 7 does a more precise analysis than before on what catch blocks can actually be reached and warnings are issued for unreachable catch blocks. I've extracted those warnings from a recent full JDK build in case anyone wants to update the code in question. -Joe ../../../../../../src/share/classes/com/sun/corba/se/impl/protocol/BootstrapServerRequestDispatcher.java:124: warning: unreachable catch clause } catch (java.lang.Exception ex) { ^ thrown type RuntimeException has already been caught ../../../../../../src/share/classes/com/sun/corba/se/impl/protocol/BootstrapServerRequestDispatcher.java:124: warning: unreachable catch clause } catch (java.lang.Exception ex) { ^ thrown type RuntimeException has already been caught ../../../src/share/classes/java/util/concurrent/ThreadPoolExecutor.java:1115: warning: unreachable catch clause } catch (Throwable x) { ^ thrown types RuntimeException,Error have already been caught ../../../src/share/classes/java/net/DatagramSocket.java:183: warning: unreachable catch clause } catch(IOException e) { ^ thrown type SocketException has already been caught Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. 2 warnings ../../../src/share/classes/java/security/cert/X509CertSelector.java:2217: warning: unreachable catch clause } catch (CertificateException e3) { ^ thrown types CertificateNotYetValidException,CertificateExpiredException have already been caught ../../../src/share/classes/javax/management/modelmbean/RequiredModelMBean.java:1220: warning: unreachable catch clause } catch (Exception e) { ^ thrown types InvocationTargetException,IllegalAccessException,RuntimeException have already been caught 1 warning ../../../../src/share/classes/sun/security/rsa/RSASignature.java:205: warning: unreachable catch clause } catch (GeneralSecurityException e) { ^ thrown type BadPaddingException has already been caught From David.Holmes at oracle.com Wed Apr 27 02:42:12 2011 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 27 Apr 2011 12:42:12 +1000 Subject: Unreachable catch classes In-Reply-To: <4DB77713.1030101@oracle.com> References: <4DB77713.1030101@oracle.com> Message-ID: <4DB78284.8080908@oracle.com> Hi Joe, I sent email to coin-dev on this yesterday but it doesn't seem to have turned up - at least I haven't seen it. In some cases at least these catch clauses are in fact reachable - e.g. ThreadPoolExecutor. The analysis assumes that checked-exceptions can only be thrown by methods that declare them, but we all know that is not the case: Class.newInstance and native methods can throw them too (are there other cases?). So sometimes we want the "unreachable" catch as a "safety-net" for these cases. Given checked-exception checks can be circumvented it seems to me that the analysis should not be issuing warnings for these cases because it will encourage people to "fix the code" - as you have just asked to be done! - when in fact the code could be less robust if it is changed. Cheers, David Joe Darcy said the following on 04/27/11 11:53: > Hello. > > FYI, javac in JDK 7 does a more precise analysis than before on what > catch blocks can actually be reached and warnings are issued for > unreachable catch blocks. I've extracted those warnings from a recent > full JDK build in case anyone wants to update the code in question. > > -Joe > > ../../../../../../src/share/classes/com/sun/corba/se/impl/protocol/BootstrapServerRequestDispatcher.java:124: > warning: unreachable catch clause > } catch (java.lang.Exception ex) { > ^ > thrown type RuntimeException has already been caught > > ../../../../../../src/share/classes/com/sun/corba/se/impl/protocol/BootstrapServerRequestDispatcher.java:124: > warning: unreachable catch clause > } catch (java.lang.Exception ex) { > ^ > thrown type RuntimeException has already been caught > > ../../../src/share/classes/java/util/concurrent/ThreadPoolExecutor.java:1115: > warning: unreachable catch clause > } catch (Throwable x) { > ^ > thrown types RuntimeException,Error have already been caught > ../../../src/share/classes/java/net/DatagramSocket.java:183: warning: > unreachable catch clause > } catch(IOException e) { > ^ > thrown type SocketException has already been caught > Note: Some input files use or override a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: Some input files use unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > 2 warnings > > ../../../src/share/classes/java/security/cert/X509CertSelector.java:2217: > warning: unreachable catch clause > } catch (CertificateException e3) { > ^ > thrown types > CertificateNotYetValidException,CertificateExpiredException have already > been caught > > ../../../src/share/classes/javax/management/modelmbean/RequiredModelMBean.java:1220: > warning: unreachable catch clause > } catch (Exception e) { > ^ > thrown types > InvocationTargetException,IllegalAccessException,RuntimeException have > already been caught > 1 warning > > ../../../../src/share/classes/sun/security/rsa/RSASignature.java:205: > warning: unreachable catch clause > } catch (GeneralSecurityException e) { > ^ > thrown type BadPaddingException has already been caught > > From mark.reinhold at oracle.com Wed Apr 27 03:43:41 2011 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 26 Apr 2011 20:43:41 -0700 Subject: Review (Updated) : 4884238 : Constants for Standard Charsets In-Reply-To: mike.duigou@oracle.com; Tue, 19 Apr 2011 17:22:02 PDT; Message-ID: <20110427034341.648F35BA@eggemoggin.niobe.net> (just saw your message; more e-mail delays I suppose) 2011/4/19 17:22 -0700, mike.duigou at oracle.com: > My sentiment is for StandardCharset. > > I received offlist feedback which would support this. The pattern for > enum like collections of constants has been to use the singular form; > java.math.RoundingMode, java.lang.annotation.ElementType, > javax.lang.model.element.ElementKind, java.lang.management.MemoryType, > etc. You're not defining an "enum-like collection of constants"; you're defining a set of convenient static constant values. In this way it's much more similar to java.util.Collections and j.u.Arrays and other multiply-named classes than it is to singularly-named enum classes. The only difference is that you're defining static constants rather than static methods. > The NIO 2 / JSR 203 classes use the relatively new naming convention of > "Standard" for platform defined constants. The uses of "Standard" in JSR 203 are for enums. > Any strong reason to use the plural form? See above. - Mark From maurizio.cimadamore at oracle.com Wed Apr 27 08:05:45 2011 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 27 Apr 2011 09:05:45 +0100 Subject: Unreachable catch classes In-Reply-To: <4DB78284.8080908@oracle.com> References: <4DB77713.1030101@oracle.com> <4DB78284.8080908@oracle.com> Message-ID: <4DB7CE59.2020206@oracle.com> On 27/04/11 03:42, David Holmes wrote: > Hi Joe, > > I sent email to coin-dev on this yesterday but it doesn't seem to have > turned up - at least I haven't seen it. > > In some cases at least these catch clauses are in fact reachable - > e.g. ThreadPoolExecutor. The analysis assumes that checked-exceptions > can only be thrown by methods that declare them, but we all know that > is not the case: Class.newInstance and native methods can throw them > too (are there other cases?). So sometimes we want the "unreachable" > catch as a "safety-net" for these cases. > > Given checked-exception checks can be circumvented it seems to me that > the analysis should not be issuing warnings for these cases because it > will encourage people to "fix the code" - as you have just asked to be > done! - when in fact the code could be less robust if it is changed. I see your concerns - unfortunately there is no way to statically distinguish 'good' cases from 'bad' cases - i.e. a call to Class.newInstance could be hidden behind a method called inside the try-block. So, it seems like the only sensible option would be to special case 'catch(Throwable)'. Maurizio > > Cheers, > David > > Joe Darcy said the following on 04/27/11 11:53: >> Hello. >> >> FYI, javac in JDK 7 does a more precise analysis than before on what >> catch blocks can actually be reached and warnings are issued for >> unreachable catch blocks. I've extracted those warnings from a >> recent full JDK build in case anyone wants to update the code in >> question. >> >> -Joe >> >> ../../../../../../src/share/classes/com/sun/corba/se/impl/protocol/BootstrapServerRequestDispatcher.java:124: >> warning: unreachable catch clause >> } catch (java.lang.Exception ex) { >> ^ >> thrown type RuntimeException has already been caught >> >> ../../../../../../src/share/classes/com/sun/corba/se/impl/protocol/BootstrapServerRequestDispatcher.java:124: >> warning: unreachable catch clause >> } catch (java.lang.Exception ex) { >> ^ >> thrown type RuntimeException has already been caught >> >> ../../../src/share/classes/java/util/concurrent/ThreadPoolExecutor.java:1115: >> warning: unreachable catch clause >> } catch (Throwable x) { >> ^ >> thrown types RuntimeException,Error have already been caught >> ../../../src/share/classes/java/net/DatagramSocket.java:183: warning: >> unreachable catch clause >> } catch(IOException e) { >> ^ >> thrown type SocketException has already been caught >> Note: Some input files use or override a deprecated API. >> Note: Recompile with -Xlint:deprecation for details. >> Note: Some input files use unchecked or unsafe operations. >> Note: Recompile with -Xlint:unchecked for details. >> 2 warnings >> >> ../../../src/share/classes/java/security/cert/X509CertSelector.java:2217: >> warning: unreachable catch clause >> } catch (CertificateException e3) { >> ^ >> thrown types >> CertificateNotYetValidException,CertificateExpiredException have >> already been caught >> >> ../../../src/share/classes/javax/management/modelmbean/RequiredModelMBean.java:1220: >> warning: unreachable catch clause >> } catch (Exception e) { >> ^ >> thrown types >> InvocationTargetException,IllegalAccessException,RuntimeException >> have already been caught >> 1 warning >> >> ../../../../src/share/classes/sun/security/rsa/RSASignature.java:205: >> warning: unreachable catch clause >> } catch (GeneralSecurityException e) { >> ^ >> thrown type BadPaddingException has already been caught >> >> From maurizio.cimadamore at oracle.com Wed Apr 27 08:10:56 2011 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 27 Apr 2011 09:10:56 +0100 Subject: Unreachable catch classes In-Reply-To: <4DB7CE59.2020206@oracle.com> References: <4DB77713.1030101@oracle.com> <4DB78284.8080908@oracle.com> <4DB7CE59.2020206@oracle.com> Message-ID: <4DB7CF90.6090608@oracle.com> On 27/04/11 09:05, Maurizio Cimadamore wrote: > On 27/04/11 03:42, David Holmes wrote: >> Hi Joe, >> >> I sent email to coin-dev on this yesterday but it doesn't seem to >> have turned up - at least I haven't seen it. >> >> In some cases at least these catch clauses are in fact reachable - >> e.g. ThreadPoolExecutor. The analysis assumes that checked-exceptions >> can only be thrown by methods that declare them, but we all know that >> is not the case: Class.newInstance and native methods can throw them >> too (are there other cases?). So sometimes we want the "unreachable" >> catch as a "safety-net" for these cases. >> >> Given checked-exception checks can be circumvented it seems to me >> that the analysis should not be issuing warnings for these cases >> because it will encourage people to "fix the code" - as you have just >> asked to be done! - when in fact the code could be less robust if it >> is changed. > I see your concerns - unfortunately there is no way to statically > distinguish 'good' cases from 'bad' cases - i.e. a call to > Class.newInstance could be hidden behind a method called inside the > try-block. So, it seems like the only sensible option would be to > special case 'catch(Throwable)'. Btw - it seems like both Constructor and Method throws InvocationTargetException in order to wrap checked exceptions from user code. Why Class.newInstance does not use ITE ? That'd be for compatibility, right? Maurizio > > Maurizio >> >> Cheers, >> David >> >> Joe Darcy said the following on 04/27/11 11:53: >>> Hello. >>> >>> FYI, javac in JDK 7 does a more precise analysis than before on what >>> catch blocks can actually be reached and warnings are issued for >>> unreachable catch blocks. I've extracted those warnings from a >>> recent full JDK build in case anyone wants to update the code in >>> question. >>> >>> -Joe >>> >>> ../../../../../../src/share/classes/com/sun/corba/se/impl/protocol/BootstrapServerRequestDispatcher.java:124: >>> warning: unreachable catch clause >>> } catch (java.lang.Exception ex) { >>> ^ >>> thrown type RuntimeException has already been caught >>> >>> ../../../../../../src/share/classes/com/sun/corba/se/impl/protocol/BootstrapServerRequestDispatcher.java:124: >>> warning: unreachable catch clause >>> } catch (java.lang.Exception ex) { >>> ^ >>> thrown type RuntimeException has already been caught >>> >>> ../../../src/share/classes/java/util/concurrent/ThreadPoolExecutor.java:1115: >>> warning: unreachable catch clause >>> } catch (Throwable x) { >>> ^ >>> thrown types RuntimeException,Error have already been caught >>> ../../../src/share/classes/java/net/DatagramSocket.java:183: >>> warning: unreachable catch clause >>> } catch(IOException e) { >>> ^ >>> thrown type SocketException has already been caught >>> Note: Some input files use or override a deprecated API. >>> Note: Recompile with -Xlint:deprecation for details. >>> Note: Some input files use unchecked or unsafe operations. >>> Note: Recompile with -Xlint:unchecked for details. >>> 2 warnings >>> >>> ../../../src/share/classes/java/security/cert/X509CertSelector.java:2217: >>> warning: unreachable catch clause >>> } catch (CertificateException e3) { >>> ^ >>> thrown types >>> CertificateNotYetValidException,CertificateExpiredException have >>> already been caught >>> >>> ../../../src/share/classes/javax/management/modelmbean/RequiredModelMBean.java:1220: >>> warning: unreachable catch clause >>> } catch (Exception e) { >>> ^ >>> thrown types >>> InvocationTargetException,IllegalAccessException,RuntimeException >>> have already been caught >>> 1 warning >>> >>> ../../../../src/share/classes/sun/security/rsa/RSASignature.java:205: warning: >>> unreachable catch clause >>> } catch (GeneralSecurityException e) { >>> ^ >>> thrown type BadPaddingException has already been caught >>> >>> > From David.Holmes at oracle.com Wed Apr 27 08:18:07 2011 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 27 Apr 2011 18:18:07 +1000 Subject: Unreachable catch classes In-Reply-To: <4DB7CE59.2020206@oracle.com> References: <4DB77713.1030101@oracle.com> <4DB78284.8080908@oracle.com> <4DB7CE59.2020206@oracle.com> Message-ID: <4DB7D13F.5050500@oracle.com> Maurizio Cimadamore said the following on 04/27/11 18:05: > On 27/04/11 03:42, David Holmes wrote: >> I sent email to coin-dev on this yesterday but it doesn't seem to have >> turned up - at least I haven't seen it. >> >> In some cases at least these catch clauses are in fact reachable - >> e.g. ThreadPoolExecutor. The analysis assumes that checked-exceptions >> can only be thrown by methods that declare them, but we all know that >> is not the case: Class.newInstance and native methods can throw them >> too (are there other cases?). So sometimes we want the "unreachable" >> catch as a "safety-net" for these cases. >> >> Given checked-exception checks can be circumvented it seems to me that >> the analysis should not be issuing warnings for these cases because it >> will encourage people to "fix the code" - as you have just asked to be >> done! - when in fact the code could be less robust if it is changed. > I see your concerns - unfortunately there is no way to statically > distinguish 'good' cases from 'bad' cases - i.e. a call to > Class.newInstance could be hidden behind a method called inside the > try-block. So, it seems like the only sensible option would be to > special case 'catch(Throwable)'. Special-casing Throwable wouldn't be sufficient as people may use Exception instead. What I suggested on coin-dev ( which has finally turned up now that someone has unblocked the openjdk mail pipes ;-) ) is that instead of doing an analysis of the expected thrown types, to simply warn for the more common mistake of catching a superclass before a subclass. David > Maurizio >> >> Cheers, >> David >> >> Joe Darcy said the following on 04/27/11 11:53: >>> Hello. >>> >>> FYI, javac in JDK 7 does a more precise analysis than before on what >>> catch blocks can actually be reached and warnings are issued for >>> unreachable catch blocks. I've extracted those warnings from a >>> recent full JDK build in case anyone wants to update the code in >>> question. >>> >>> -Joe >>> >>> ../../../../../../src/share/classes/com/sun/corba/se/impl/protocol/BootstrapServerRequestDispatcher.java:124: >>> warning: unreachable catch clause >>> } catch (java.lang.Exception ex) { >>> ^ >>> thrown type RuntimeException has already been caught >>> >>> ../../../../../../src/share/classes/com/sun/corba/se/impl/protocol/BootstrapServerRequestDispatcher.java:124: >>> warning: unreachable catch clause >>> } catch (java.lang.Exception ex) { >>> ^ >>> thrown type RuntimeException has already been caught >>> >>> ../../../src/share/classes/java/util/concurrent/ThreadPoolExecutor.java:1115: >>> warning: unreachable catch clause >>> } catch (Throwable x) { >>> ^ >>> thrown types RuntimeException,Error have already been caught >>> ../../../src/share/classes/java/net/DatagramSocket.java:183: warning: >>> unreachable catch clause >>> } catch(IOException e) { >>> ^ >>> thrown type SocketException has already been caught >>> Note: Some input files use or override a deprecated API. >>> Note: Recompile with -Xlint:deprecation for details. >>> Note: Some input files use unchecked or unsafe operations. >>> Note: Recompile with -Xlint:unchecked for details. >>> 2 warnings >>> >>> ../../../src/share/classes/java/security/cert/X509CertSelector.java:2217: >>> warning: unreachable catch clause >>> } catch (CertificateException e3) { >>> ^ >>> thrown types >>> CertificateNotYetValidException,CertificateExpiredException have >>> already been caught >>> >>> ../../../src/share/classes/javax/management/modelmbean/RequiredModelMBean.java:1220: >>> warning: unreachable catch clause >>> } catch (Exception e) { >>> ^ >>> thrown types >>> InvocationTargetException,IllegalAccessException,RuntimeException >>> have already been caught >>> 1 warning >>> >>> ../../../../src/share/classes/sun/security/rsa/RSASignature.java:205: >>> warning: unreachable catch clause >>> } catch (GeneralSecurityException e) { >>> ^ >>> thrown type BadPaddingException has already been caught >>> >>> > From David.Holmes at oracle.com Wed Apr 27 08:26:37 2011 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 27 Apr 2011 18:26:37 +1000 Subject: Unreachable catch classes In-Reply-To: <4DB7CF90.6090608@oracle.com> References: <4DB77713.1030101@oracle.com> <4DB78284.8080908@oracle.com> <4DB7CE59.2020206@oracle.com> <4DB7CF90.6090608@oracle.com> Message-ID: <4DB7D33D.2090907@oracle.com> Maurizio Cimadamore said the following on 04/27/11 18:10: > On 27/04/11 09:05, Maurizio Cimadamore wrote: >> On 27/04/11 03:42, David Holmes wrote: >>> >>> I sent email to coin-dev on this yesterday but it doesn't seem to >>> have turned up - at least I haven't seen it. >>> >>> In some cases at least these catch clauses are in fact reachable - >>> e.g. ThreadPoolExecutor. The analysis assumes that checked-exceptions >>> can only be thrown by methods that declare them, but we all know that >>> is not the case: Class.newInstance and native methods can throw them >>> too (are there other cases?). So sometimes we want the "unreachable" >>> catch as a "safety-net" for these cases. >>> >>> Given checked-exception checks can be circumvented it seems to me >>> that the analysis should not be issuing warnings for these cases >>> because it will encourage people to "fix the code" - as you have just >>> asked to be done! - when in fact the code could be less robust if it >>> is changed. >> I see your concerns - unfortunately there is no way to statically >> distinguish 'good' cases from 'bad' cases - i.e. a call to >> Class.newInstance could be hidden behind a method called inside the >> try-block. So, it seems like the only sensible option would be to >> special case 'catch(Throwable)'. > > Btw - it seems like both Constructor and Method throws > InvocationTargetException in order to wrap checked exceptions from user > code. Why Class.newInstance does not use ITE ? That'd be for > compatibility, right? Right - Class.newInstance predates the full reflection API and the powers that be at the time refused to change it for "compatibility concerns" even though it violated the language semantics. :( It took some effort to even get the problem clearly documented in the method. Because of that and the problem of native code, any framework code wanting to ensure that it dealt with all exceptions, has been forced to use the kind of pattern we are discussing - and similar ones for rethrowing exceptions (by wrapping any unexpected checked-exception in an Error). For some reason "they" never even considered deprecating Class.newInstance so that people would at least be steered to use the reflection APIs. Though given deprecated APIs never actually disappear it makes little practical difference. David > Maurizio >> >> Maurizio >>> >>> Cheers, >>> David >>> >>> Joe Darcy said the following on 04/27/11 11:53: >>>> Hello. >>>> >>>> FYI, javac in JDK 7 does a more precise analysis than before on what >>>> catch blocks can actually be reached and warnings are issued for >>>> unreachable catch blocks. I've extracted those warnings from a >>>> recent full JDK build in case anyone wants to update the code in >>>> question. >>>> >>>> -Joe >>>> >>>> ../../../../../../src/share/classes/com/sun/corba/se/impl/protocol/BootstrapServerRequestDispatcher.java:124: >>>> warning: unreachable catch clause >>>> } catch (java.lang.Exception ex) { >>>> ^ >>>> thrown type RuntimeException has already been caught >>>> >>>> ../../../../../../src/share/classes/com/sun/corba/se/impl/protocol/BootstrapServerRequestDispatcher.java:124: >>>> warning: unreachable catch clause >>>> } catch (java.lang.Exception ex) { >>>> ^ >>>> thrown type RuntimeException has already been caught >>>> >>>> ../../../src/share/classes/java/util/concurrent/ThreadPoolExecutor.java:1115: >>>> warning: unreachable catch clause >>>> } catch (Throwable x) { >>>> ^ >>>> thrown types RuntimeException,Error have already been caught >>>> ../../../src/share/classes/java/net/DatagramSocket.java:183: >>>> warning: unreachable catch clause >>>> } catch(IOException e) { >>>> ^ >>>> thrown type SocketException has already been caught >>>> Note: Some input files use or override a deprecated API. >>>> Note: Recompile with -Xlint:deprecation for details. >>>> Note: Some input files use unchecked or unsafe operations. >>>> Note: Recompile with -Xlint:unchecked for details. >>>> 2 warnings >>>> >>>> ../../../src/share/classes/java/security/cert/X509CertSelector.java:2217: >>>> warning: unreachable catch clause >>>> } catch (CertificateException e3) { >>>> ^ >>>> thrown types >>>> CertificateNotYetValidException,CertificateExpiredException have >>>> already been caught >>>> >>>> ../../../src/share/classes/javax/management/modelmbean/RequiredModelMBean.java:1220: >>>> warning: unreachable catch clause >>>> } catch (Exception e) { >>>> ^ >>>> thrown types >>>> InvocationTargetException,IllegalAccessException,RuntimeException >>>> have already been caught >>>> 1 warning >>>> >>>> ../../../../src/share/classes/sun/security/rsa/RSASignature.java:205: >>>> warning: unreachable catch clause >>>> } catch (GeneralSecurityException e) { >>>> ^ >>>> thrown type BadPaddingException has already been caught >>>> >>>> >> > From maurizio.cimadamore at oracle.com Wed Apr 27 08:35:33 2011 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 27 Apr 2011 09:35:33 +0100 Subject: Unreachable catch classes In-Reply-To: <4DB7D13F.5050500@oracle.com> References: <4DB77713.1030101@oracle.com> <4DB78284.8080908@oracle.com> <4DB7CE59.2020206@oracle.com> <4DB7D13F.5050500@oracle.com> Message-ID: <4DB7D555.2070302@oracle.com> On 27/04/11 09:18, David Holmes wrote: > Maurizio Cimadamore said the following on 04/27/11 18:05: >> On 27/04/11 03:42, David Holmes wrote: >>> I sent email to coin-dev on this yesterday but it doesn't seem to >>> have turned up - at least I haven't seen it. >>> >>> In some cases at least these catch clauses are in fact reachable - >>> e.g. ThreadPoolExecutor. The analysis assumes that >>> checked-exceptions can only be thrown by methods that declare them, >>> but we all know that is not the case: Class.newInstance and native >>> methods can throw them too (are there other cases?). So sometimes we >>> want the "unreachable" catch as a "safety-net" for these cases. >>> >>> Given checked-exception checks can be circumvented it seems to me >>> that the analysis should not be issuing warnings for these cases >>> because it will encourage people to "fix the code" - as you have >>> just asked to be done! - when in fact the code could be less robust >>> if it is changed. >> I see your concerns - unfortunately there is no way to statically >> distinguish 'good' cases from 'bad' cases - i.e. a call to >> Class.newInstance could be hidden behind a method called inside the >> try-block. So, it seems like the only sensible option would be to >> special case 'catch(Throwable)'. > > Special-casing Throwable wouldn't be sufficient as people may use > Exception instead. > > What I suggested on coin-dev ( which has finally turned up now that > someone has unblocked the openjdk mail pipes ;-) ) is that instead of > doing an analysis of the expected thrown types, to simply warn for the > more common mistake of catching a superclass before a subclass. So, you are saying that the JDK 7 compiler should stop generating additional warnings, and start behaving as usual (we always had errors when catching supertype after subtype, and such). Maurizio > > David > >> Maurizio >>> >>> Cheers, >>> David >>> >>> Joe Darcy said the following on 04/27/11 11:53: >>>> Hello. >>>> >>>> FYI, javac in JDK 7 does a more precise analysis than before on >>>> what catch blocks can actually be reached and warnings are issued >>>> for unreachable catch blocks. I've extracted those warnings from a >>>> recent full JDK build in case anyone wants to update the code in >>>> question. >>>> >>>> -Joe >>>> >>>> ../../../../../../src/share/classes/com/sun/corba/se/impl/protocol/BootstrapServerRequestDispatcher.java:124: >>>> warning: unreachable catch clause >>>> } catch (java.lang.Exception ex) { >>>> ^ >>>> thrown type RuntimeException has already been caught >>>> >>>> ../../../../../../src/share/classes/com/sun/corba/se/impl/protocol/BootstrapServerRequestDispatcher.java:124: >>>> warning: unreachable catch clause >>>> } catch (java.lang.Exception ex) { >>>> ^ >>>> thrown type RuntimeException has already been caught >>>> >>>> ../../../src/share/classes/java/util/concurrent/ThreadPoolExecutor.java:1115: >>>> warning: unreachable catch clause >>>> } catch (Throwable x) { >>>> ^ >>>> thrown types RuntimeException,Error have already been caught >>>> ../../../src/share/classes/java/net/DatagramSocket.java:183: >>>> warning: unreachable catch clause >>>> } catch(IOException e) { >>>> ^ >>>> thrown type SocketException has already been caught >>>> Note: Some input files use or override a deprecated API. >>>> Note: Recompile with -Xlint:deprecation for details. >>>> Note: Some input files use unchecked or unsafe operations. >>>> Note: Recompile with -Xlint:unchecked for details. >>>> 2 warnings >>>> >>>> ../../../src/share/classes/java/security/cert/X509CertSelector.java:2217: >>>> warning: unreachable catch clause >>>> } catch (CertificateException e3) { >>>> ^ >>>> thrown types >>>> CertificateNotYetValidException,CertificateExpiredException have >>>> already been caught >>>> >>>> ../../../src/share/classes/javax/management/modelmbean/RequiredModelMBean.java:1220: >>>> warning: unreachable catch clause >>>> } catch (Exception e) { >>>> ^ >>>> thrown types >>>> InvocationTargetException,IllegalAccessException,RuntimeException >>>> have already been caught >>>> 1 warning >>>> >>>> ../../../../src/share/classes/sun/security/rsa/RSASignature.java:205: >>>> warning: unreachable catch clause >>>> } catch (GeneralSecurityException e) { >>>> ^ >>>> thrown type BadPaddingException has already been caught >>>> >>>> >> From David.Holmes at oracle.com Wed Apr 27 08:40:11 2011 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 27 Apr 2011 18:40:11 +1000 Subject: Unreachable catch classes In-Reply-To: <4DB7D555.2070302@oracle.com> References: <4DB77713.1030101@oracle.com> <4DB78284.8080908@oracle.com> <4DB7CE59.2020206@oracle.com> <4DB7D13F.5050500@oracle.com> <4DB7D555.2070302@oracle.com> Message-ID: <4DB7D66B.6070703@oracle.com> Maurizio Cimadamore said the following on 04/27/11 18:35: > On 27/04/11 09:18, David Holmes wrote: >> What I suggested on coin-dev ( which has finally turned up now that >> someone has unblocked the openjdk mail pipes ;-) ) is that instead of >> doing an analysis of the expected thrown types, to simply warn for the >> more common mistake of catching a superclass before a subclass. > > So, you are saying that the JDK 7 compiler should stop generating > additional warnings, and start behaving as usual (we always had errors > when catching supertype after subtype, and such). In that case I guess that is what I am suggesting. Is there a @SuppressWarnings setting for these warnings? David > Maurizio >> >> David >> >>> Maurizio >>>> >>>> Cheers, >>>> David >>>> >>>> Joe Darcy said the following on 04/27/11 11:53: >>>>> Hello. >>>>> >>>>> FYI, javac in JDK 7 does a more precise analysis than before on >>>>> what catch blocks can actually be reached and warnings are issued >>>>> for unreachable catch blocks. I've extracted those warnings from a >>>>> recent full JDK build in case anyone wants to update the code in >>>>> question. >>>>> >>>>> -Joe >>>>> >>>>> ../../../../../../src/share/classes/com/sun/corba/se/impl/protocol/BootstrapServerRequestDispatcher.java:124: >>>>> warning: unreachable catch clause >>>>> } catch (java.lang.Exception ex) { >>>>> ^ >>>>> thrown type RuntimeException has already been caught >>>>> >>>>> ../../../../../../src/share/classes/com/sun/corba/se/impl/protocol/BootstrapServerRequestDispatcher.java:124: >>>>> warning: unreachable catch clause >>>>> } catch (java.lang.Exception ex) { >>>>> ^ >>>>> thrown type RuntimeException has already been caught >>>>> >>>>> ../../../src/share/classes/java/util/concurrent/ThreadPoolExecutor.java:1115: >>>>> warning: unreachable catch clause >>>>> } catch (Throwable x) { >>>>> ^ >>>>> thrown types RuntimeException,Error have already been caught >>>>> ../../../src/share/classes/java/net/DatagramSocket.java:183: >>>>> warning: unreachable catch clause >>>>> } catch(IOException e) { >>>>> ^ >>>>> thrown type SocketException has already been caught >>>>> Note: Some input files use or override a deprecated API. >>>>> Note: Recompile with -Xlint:deprecation for details. >>>>> Note: Some input files use unchecked or unsafe operations. >>>>> Note: Recompile with -Xlint:unchecked for details. >>>>> 2 warnings >>>>> >>>>> ../../../src/share/classes/java/security/cert/X509CertSelector.java:2217: >>>>> warning: unreachable catch clause >>>>> } catch (CertificateException e3) { >>>>> ^ >>>>> thrown types >>>>> CertificateNotYetValidException,CertificateExpiredException have >>>>> already been caught >>>>> >>>>> ../../../src/share/classes/javax/management/modelmbean/RequiredModelMBean.java:1220: >>>>> warning: unreachable catch clause >>>>> } catch (Exception e) { >>>>> ^ >>>>> thrown types >>>>> InvocationTargetException,IllegalAccessException,RuntimeException >>>>> have already been caught >>>>> 1 warning >>>>> >>>>> ../../../../src/share/classes/sun/security/rsa/RSASignature.java:205: >>>>> warning: unreachable catch clause >>>>> } catch (GeneralSecurityException e) { >>>>> ^ >>>>> thrown type BadPaddingException has already been caught >>>>> >>>>> >>> > From Ulf.Zibis at gmx.de Wed Apr 27 09:09:13 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Wed, 27 Apr 2011 11:09:13 +0200 Subject: array clone() vs Arrays.copyOf() In-Reply-To: <4DB764AC.8030002@oracle.com> References: <5CE3B0CD-918C-4E03-B349-CD886129DB8E@oracle.com> <4DB1ACD5.8010205@univ-mlv.fr> <4DB1C76B.4060605@univ-mlv.fr> <4DB2A5DC.8000204@oracle.com> <24CAE1E9-BB1A-425B-8B82-E6C9C8B3B362@oracle.com> <4DB6E2C0.3000503@oracle.com> <4DB764AC.8030002@oracle.com> Message-ID: <4DB7DD39.1070706@gmx.de> Am 27.04.2011 02:34, schrieb David Holmes: > Hi Stuart, > > Actually my comments more a response to Remi's assertion that clone should have been used instead, > without giving any technical rationale as to why clone would be better, and so much better that it > warranted Lance changing the code. > > Personally I think we should be steering people to Arrays.copyOf for all their array copying needs. Hm, why? > clone() is effectively legacy code. What does that mean? I prefer clone(): - less to type - better to read, especially in looong code lines, e.g. as method call argument - in-advanced reader potentially has less need to refer the doc - potentially faster, at least in interpreter and C1? -Ulf BTW: Did you answer to the wrong thread (see attached screen shot) ? That was the reason why I came aware about this post ;-) From weijun.wang at oracle.com Wed Apr 27 09:15:53 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Wed, 27 Apr 2011 09:15:53 +0000 Subject: hg: jdk7/tl/jdk: 6950929: Failures on Solaris sparc 64bit sun/security/krb5/auto/BadKdc4.java (and linux?) Message-ID: <20110427091614.1383847038@hg.openjdk.java.net> Changeset: 0e0db3421e8f Author: weijun Date: 2011-04-27 17:11 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0e0db3421e8f 6950929: Failures on Solaris sparc 64bit sun/security/krb5/auto/BadKdc4.java (and linux?) Reviewed-by: xuelei ! test/sun/security/krb5/auto/BadKdc.java From David.Holmes at oracle.com Wed Apr 27 09:19:49 2011 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 27 Apr 2011 19:19:49 +1000 Subject: array clone() vs Arrays.copyOf() In-Reply-To: <4DB7DD39.1070706@gmx.de> References: <5CE3B0CD-918C-4E03-B349-CD886129DB8E@oracle.com> <4DB1ACD5.8010205@univ-mlv.fr> <4DB1C76B.4060605@univ-mlv.fr> <4DB2A5DC.8000204@oracle.com> <24CAE1E9-BB1A-425B-8B82-E6C9C8B3B362@oracle.com> <4DB6E2C0.3000503@oracle.com> <4DB764AC.8030002@oracle.com> <4DB7DD39.1070706@gmx.de> Message-ID: <4DB7DFB5.3040901@oracle.com> Ulf Zibis said the following on 04/27/11 19:09: > Am 27.04.2011 02:34, schrieb David Holmes: >> >> Actually my comments more a response to Remi's assertion that clone >> should have been used instead, without giving any technical rationale >> as to why clone would be better, and so much better that it warranted >> Lance changing the code. >> >> Personally I think we should be steering people to Arrays.copyOf for >> all their array copying needs. > Hm, why? One API to learn that covers all the array-copying needs. >> clone() is effectively legacy code. > What does that mean? Just that it is an old mechanism that has been around for a long time, is limited to one specific use-case and has been made somewhat redundant by the newer APIs. > I prefer clone(): > - less to type > - better to read, especially in looong code lines, e.g. as method call > argument True. Would be nice if defender methods were expanded to allow you to do anArray.copyOf() > - in-advanced reader potentially has less need to refer the doc > - potentially faster, at least in interpreter and C1? I don't have the numbers one way or the other. > BTW: Did you answer to the wrong thread (see attached screen shot) ? > That was the reason why I came aware about this post ;-) That's weird. No I only answered direct to Stuarts email. Cheers, David > > ------------------------------------------------------------------------ > From Ulf.Zibis at gmx.de Wed Apr 27 09:41:22 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Wed, 27 Apr 2011 11:41:22 +0200 Subject: array clone() vs Arrays.copyOf() In-Reply-To: <4DB7DFB5.3040901@oracle.com> References: <5CE3B0CD-918C-4E03-B349-CD886129DB8E@oracle.com> <4DB1ACD5.8010205@univ-mlv.fr> <4DB1C76B.4060605@univ-mlv.fr> <4DB2A5DC.8000204@oracle.com> <24CAE1E9-BB1A-425B-8B82-E6C9C8B3B362@oracle.com> <4DB6E2C0.3000503@oracle.com> <4DB764AC.8030002@oracle.com> <4DB7DD39.1070706@gmx.de> <4DB7DFB5.3040901@oracle.com> Message-ID: <4DB7E4C2.1030004@gmx.de> Am 27.04.2011 11:19, schrieb David Holmes: > Ulf Zibis said the following on 04/27/11 19:09: >> Am 27.04.2011 02:34, schrieb David Holmes: >>> >>> Actually my comments more a response to Remi's assertion that clone should have been used >>> instead, without giving any technical rationale as to why clone would be better, and so much >>> better that it warranted Lance changing the code. >>> >>> Personally I think we should be steering people to Arrays.copyOf for all their array copying needs. >> Hm, why? > > One API to learn that covers all the array-copying needs. Ok, but from the point of *object-copying* needs, why should one care about sophisticated array stuff? > >>> clone() is effectively legacy code. >> What does that mean? > > Just that it is an old mechanism that has been around for a long time, is limited to one specific > use-case and has been made somewhat redundant by the newer APIs. Ok, you mean Array.copyOf() is clone() XL. There are many places, where legacy code became redundant because of some extensions. Should we always avoid them? E.g.: - StringBuilder.apend(...) instead '+' - Objects.hashcode(obj) instead obj.hashcode() - etc... > >> I prefer clone(): >> - less to type >> - better to read, especially in looong code lines, e.g. as method call argument > > True. Would be nice if defender methods were expanded to allow you to do anArray.copyOf() Can you explain that in other words. Sorry, I'm no english native ;-) -Ulf From Ulf.Zibis at gmx.de Wed Apr 27 09:51:42 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Wed, 27 Apr 2011 11:51:42 +0200 Subject: Review (Updated) : 4884238 : Constants for Standard Charsets In-Reply-To: <4DAEC7B7.7000602@gmx.de> References: <4DAD7762.4000707@gmx.de> <12D33A70-593A-40A4-9B33-445D8A8FB6A0@oracle.com> <4DAEC7B7.7000602@gmx.de> Message-ID: <4DB7E72E.2010501@gmx.de> No answer ? Especially on: static constant vs. static method -Ulf Am 20.04.2011 13:47, schrieb Ulf Zibis: > Am 20.04.2011 02:23, schrieb Mike Duigou: >> On Apr 19 2011, at 04:52 , Ulf Zibis wrote: >>> I think, we should catch the problem at the source. ... In my approach from Bug 100098 - Make >>> sun.nio.cs.* charset objects light-weight such a class is named 'FastCharset'. >> Unfortunately any we at a very late stage in Java 7's development and the degree of change >> required by 100098 are not possible. > > Yes, that's right. For that reason I have suggested an intermediate solution to avoid the > additional, later not removable StandardCharset(s) class. > >> This issue itself may also be rejected solely for missing impending deadlines. > Should there something be done for that? > >>> So I tend to prefer the original request from 4884238 (have the canonical names as constants), >>> as the lookup via Charset.forName(...) then could be very fast compared to the anyway following >>> heavy de/encoding work. >> I think that in most uses a constant of the Charset is more useful as that's what's desired for >> use. I am not opposed to having visible constants for the charset names but I don't think it's as >> useful as the Charset objects. The performance of Charset.forName() is a separate matter. > > Thinking more I agree to some direct access to the standard charsets, because Charset.forName(..) > potentially needs extra exception handling. But is there a must for static constants? I think we > could have lazy initialized static methods, so (1) only the Charset class of request should be > loaded, (2) separate StandardCharset(s) class and discussion about the naming becomes superfluous, > (3) the small short cut cache in Charset remains it's proper function (otherwise the last 2, > UTF_16BE, UTF_16LE are cached), and (4) we could profit from it in Charset.defaultCharset() for > the fall-back case: > 622 defaultCharset = UTF_8(); > > I still think, we should have constants for the canonical charset names: Charset.UTF_8 = "UTF-8"; > etc... > > Additionally consider, that in many real world cases not the charset, but it's de/encoder is of > interest, so the programmer anyway needs to define a static constant, if for performance reason it > should be reused: > static final CharsetDecoder UTF_8_DECODER = UTF_8.newDecoder(); > > Here my new suggestion: > > public abstract class Charset implements Comparable { > static final String UTF_8 = "UTF-8"; > ... > static final Charset UTF_8() { > return forName(UTF_8); // Note that recently used charsets are hold in a small short cut > cache. > } > ... > } > > -Ulf > > > From Ulf.Zibis at gmx.de Wed Apr 27 09:54:39 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Wed, 27 Apr 2011 11:54:39 +0200 Subject: Unreachable catch classes In-Reply-To: <4DB7D66B.6070703@oracle.com> References: <4DB77713.1030101@oracle.com> <4DB78284.8080908@oracle.com> <4DB7CE59.2020206@oracle.com> <4DB7D13F.5050500@oracle.com> <4DB7D555.2070302@oracle.com> <4DB7D66B.6070703@oracle.com> Message-ID: <4DB7E7DF.6050505@gmx.de> Am 27.04.2011 10:40, schrieb David Holmes: > Maurizio Cimadamore said the following on 04/27/11 18:35: >> On 27/04/11 09:18, David Holmes wrote: >>> What I suggested on coin-dev ( which has finally turned up now that someone has unblocked the >>> openjdk mail pipes ;-) ) is that instead of doing an analysis of the expected thrown types, to >>> simply warn for the more common mistake of catching a superclass before a subclass. >> >> So, you are saying that the JDK 7 compiler should stop generating additional warnings, and start >> behaving as usual (we always had errors when catching supertype after subtype, and such). > > In that case I guess that is what I am suggesting. > > Is there a @SuppressWarnings setting for these warnings? > +1 (for adding a special warning suppression to note people about special intention, e.g. catch from native call) -Ulf From David.Holmes at oracle.com Wed Apr 27 10:13:44 2011 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 27 Apr 2011 20:13:44 +1000 Subject: array clone() vs Arrays.copyOf() In-Reply-To: <4DB7E4C2.1030004@gmx.de> References: <5CE3B0CD-918C-4E03-B349-CD886129DB8E@oracle.com> <4DB1ACD5.8010205@univ-mlv.fr> <4DB1C76B.4060605@univ-mlv.fr> <4DB2A5DC.8000204@oracle.com> <24CAE1E9-BB1A-425B-8B82-E6C9C8B3B362@oracle.com> <4DB6E2C0.3000503@oracle.com> <4DB764AC.8030002@oracle.com> <4DB7DD39.1070706@gmx.de> <4DB7DFB5.3040901@oracle.com> <4DB7E4C2.1030004@gmx.de> Message-ID: <4DB7EC58.1080208@oracle.com> Ulf Zibis said the following on 04/27/11 19:41: > Am 27.04.2011 11:19, schrieb David Holmes: >> Ulf Zibis said the following on 04/27/11 19:09: >>> Am 27.04.2011 02:34, schrieb David Holmes: >>>> >>>> Actually my comments more a response to Remi's assertion that clone >>>> should have been used instead, without giving any technical >>>> rationale as to why clone would be better, and so much better that >>>> it warranted Lance changing the code. >>>> >>>> Personally I think we should be steering people to Arrays.copyOf for >>>> all their array copying needs. >>> Hm, why? >> >> One API to learn that covers all the array-copying needs. > Ok, but from the point of *object-copying* needs, why should one care > about sophisticated array stuff? All I'm saying is that when people think "I need a copy of this array" then copyOf is what should come to mind. Why learn two APIs just because one may handle a boundary case "better"? >>>> clone() is effectively legacy code. >>> What does that mean? >> >> Just that it is an old mechanism that has been around for a long time, >> is limited to one specific use-case and has been made somewhat >> redundant by the newer APIs. > Ok, you mean Array.copyOf() is clone() XL. > There are many places, where legacy code became redundant because of > some extensions. Should we always avoid them? E.g.: > - StringBuilder.apend(...) instead '+' > - Objects.hashcode(obj) instead obj.hashcode() > - etc... We should prefer them if they can do an overall better job - else why bother adding them. Why teach the old way when there is a more advanced/useful new way? Why learn two things when you can learn one that covers both use-cases? Sometimes there is a need for both - it isn't an absolute. >>> I prefer clone(): >>> - less to type >>> - better to read, especially in looong code lines, e.g. as method >>> call argument >> >> True. Would be nice if defender methods were expanded to allow you to >> do anArray.copyOf() > Can you explain that in other words. Sorry, I'm no english native ;-) You argued, quite correctly, that anArray.clone() is easier to read in some contexts, compared to Arrays.copyOf(anArray, anArray.length). I was saying that it is a pity that the defender method mechanism (for adding new methods to interfaces -coming in Java 8) wasn't extended so that you could also add methods to arrays - if it were then you could write anArray.copyOf() Anyway I'm not interested in convincing anybody either way. What I objected to originally was the assertion that copyOf should be replaced by clone() with no technical justification as to why. David > -Ulf > From maurizio.cimadamore at oracle.com Wed Apr 27 10:23:09 2011 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 27 Apr 2011 11:23:09 +0100 Subject: Unreachable catch classes In-Reply-To: <4DB7D66B.6070703@oracle.com> References: <4DB77713.1030101@oracle.com> <4DB78284.8080908@oracle.com> <4DB7CE59.2020206@oracle.com> <4DB7D13F.5050500@oracle.com> <4DB7D555.2070302@oracle.com> <4DB7D66B.6070703@oracle.com> Message-ID: <4DB7EE8D.5020703@oracle.com> On 27/04/11 09:40, David Holmes wrote: > Maurizio Cimadamore said the following on 04/27/11 18:35: >> On 27/04/11 09:18, David Holmes wrote: >>> What I suggested on coin-dev ( which has finally turned up now that >>> someone has unblocked the openjdk mail pipes ;-) ) is that instead >>> of doing an analysis of the expected thrown types, to simply warn >>> for the more common mistake of catching a superclass before a subclass. >> >> So, you are saying that the JDK 7 compiler should stop generating >> additional warnings, and start behaving as usual (we always had >> errors when catching supertype after subtype, and such). > > In that case I guess that is what I am suggesting. > > Is there a @SuppressWarnings setting for these warnings? Currently those warnings cannot be suppressed - i.e. those are not Xlint warnings. However I see the merit of what you are proposing. When I changed javac to the current behavior there has been a lot of discussion about whether this should be a supressable Xlint warning, a mandatory warning or an error. We decided for the mandatory warning as we assumed this was bad code that could eventually be rejected in a future release - but we overlooked the Class.newInstance case, which makes the whole argument rather pointless. Given that we should probably live with the Class.newInstance 'hole', I think that a suppressible warning would be the best option - i.e. user can decide whether the compiler should emit additional info about catch clause reachability (based on static information) by using a flag like -Xlint:try, and such warnings could then be suppressed the usual way (@SuppressWarnings("try")). I will discuss this with my team and then get back to you. Maurizio > > David > >> Maurizio >>> >>> David >>> >>>> Maurizio >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>> Joe Darcy said the following on 04/27/11 11:53: >>>>>> Hello. >>>>>> >>>>>> FYI, javac in JDK 7 does a more precise analysis than before on >>>>>> what catch blocks can actually be reached and warnings are issued >>>>>> for unreachable catch blocks. I've extracted those warnings from >>>>>> a recent full JDK build in case anyone wants to update the code >>>>>> in question. >>>>>> >>>>>> -Joe >>>>>> >>>>>> ../../../../../../src/share/classes/com/sun/corba/se/impl/protocol/BootstrapServerRequestDispatcher.java:124: >>>>>> warning: unreachable catch clause >>>>>> } catch (java.lang.Exception ex) { >>>>>> ^ >>>>>> thrown type RuntimeException has already been caught >>>>>> >>>>>> ../../../../../../src/share/classes/com/sun/corba/se/impl/protocol/BootstrapServerRequestDispatcher.java:124: >>>>>> warning: unreachable catch clause >>>>>> } catch (java.lang.Exception ex) { >>>>>> ^ >>>>>> thrown type RuntimeException has already been caught >>>>>> >>>>>> ../../../src/share/classes/java/util/concurrent/ThreadPoolExecutor.java:1115: >>>>>> warning: unreachable catch clause >>>>>> } catch (Throwable x) { >>>>>> ^ >>>>>> thrown types RuntimeException,Error have already been caught >>>>>> ../../../src/share/classes/java/net/DatagramSocket.java:183: >>>>>> warning: unreachable catch clause >>>>>> } catch(IOException e) { >>>>>> ^ >>>>>> thrown type SocketException has already been caught >>>>>> Note: Some input files use or override a deprecated API. >>>>>> Note: Recompile with -Xlint:deprecation for details. >>>>>> Note: Some input files use unchecked or unsafe operations. >>>>>> Note: Recompile with -Xlint:unchecked for details. >>>>>> 2 warnings >>>>>> >>>>>> ../../../src/share/classes/java/security/cert/X509CertSelector.java:2217: >>>>>> warning: unreachable catch clause >>>>>> } catch (CertificateException e3) { >>>>>> ^ >>>>>> thrown types >>>>>> CertificateNotYetValidException,CertificateExpiredException have >>>>>> already been caught >>>>>> >>>>>> ../../../src/share/classes/javax/management/modelmbean/RequiredModelMBean.java:1220: >>>>>> warning: unreachable catch clause >>>>>> } catch (Exception e) { >>>>>> ^ >>>>>> thrown types >>>>>> InvocationTargetException,IllegalAccessException,RuntimeException >>>>>> have already been caught >>>>>> 1 warning >>>>>> >>>>>> ../../../../src/share/classes/sun/security/rsa/RSASignature.java:205: >>>>>> warning: unreachable catch clause >>>>>> } catch (GeneralSecurityException e) { >>>>>> ^ >>>>>> thrown type BadPaddingException has already been caught >>>>>> >>>>>> >>>> >> From Lance.Andersen at oracle.com Wed Apr 27 12:28:46 2011 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Wed, 27 Apr 2011 08:28:46 -0400 Subject: Are emails arriving late to core-libs-dev In-Reply-To: <4D7A8E2B.3070407@univ-mlv.fr> References: <4D7A83AA.8060208@gmx.de> <4D7A8E2B.3070407@univ-mlv.fr> Message-ID: Hi Remi and team, I just received this today, notice the date "March 11th, 2011". I also received a slew of other emails from core-libs-dev that were also sent days ago. Regards, Lance p.s. Remi, Thank you for the comments below. I will look at incorporating some of the changes such as drivers.isEmpty() in a future update to DriverManager. My Best, Lance On Mar 11, 2011, at 4:03 PM, R?mi Forax wrote: > Hi Lance, > - logSync is not declared final. > - the comment "thow a SecurityException" is not that useful > - in getDrivers(), I think you can use an ArrayList to gather > all drivers and use Collections.enumeration() at the end. > - also instead of > > if (drivers == null || drivers.equals("")) { > > if (drivers == null || drivers.isEmpty()) { > > should be a little more efficient. > > That's all :) > > R?mi > > On 03/11/2011 09:18 PM, Ulf Zibis wrote: >> Maybe you could update the javadoc style ( -> @code etc.) and move the constructor to the begining. >> >> -Ulf >> >> >> Am 11.03.2011 21:03, schrieb Lance Andersen - Oracle: >>> Hi, >>> >>> I have posted the diffs to DriverManager for review at http://cr.openjdk.java.net/~lancea/7026898/. This change utilizes CopyOnWriteArrayList instead of the Vectors previously used. >>> >>> >>> Regards, >>> >>> Lance >>> >>> >>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>> Oracle Java Engineering >>> 1 Network Drive >>> Burlington, MA 01803 >>> Lance.Andersen at oracle.com >>> >>> Oracle is committed to developing practices and products that help protect the environment >>> >>> >>> > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From David.Holmes at oracle.com Wed Apr 27 12:44:14 2011 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 27 Apr 2011 22:44:14 +1000 Subject: Are emails arriving late to core-libs-dev In-Reply-To: References: <4D7A83AA.8060208@gmx.de> <4D7A8E2B.3070407@univ-mlv.fr> Message-ID: <4DB80F9E.7080902@oracle.com> Lance, There's been some kind of blockage in the openjdk mailing system and it finally got released today. As a result people are getting missing emails from as far back as early March, as well as some duplicate emails. David Lance Andersen - Oracle said the following on 04/27/11 22:28: > Hi Remi and team, > > I just received this today, notice the date "March 11th, 2011". I also received a slew of other emails from core-libs-dev that were also sent days ago. > > Regards, > Lance > > p.s. Remi, Thank you for the comments below. I will look at incorporating some of the changes such as drivers.isEmpty() in a future update to DriverManager. > > > My Best, > Lance > > > On Mar 11, 2011, at 4:03 PM, R?mi Forax wrote: > >> Hi Lance, >> - logSync is not declared final. >> - the comment "thow a SecurityException" is not that useful >> - in getDrivers(), I think you can use an ArrayList to gather >> all drivers and use Collections.enumeration() at the end. >> - also instead of >> >> if (drivers == null || drivers.equals("")) { >> >> if (drivers == null || drivers.isEmpty()) { >> >> should be a little more efficient. >> >> That's all :) >> >> R?mi >> >> On 03/11/2011 09:18 PM, Ulf Zibis wrote: >>> Maybe you could update the javadoc style ( -> @code etc.) and move the constructor to the begining. >>> >>> -Ulf >>> >>> >>> Am 11.03.2011 21:03, schrieb Lance Andersen - Oracle: >>>> Hi, >>>> >>>> I have posted the diffs to DriverManager for review at http://cr.openjdk.java.net/~lancea/7026898/. This change utilizes CopyOnWriteArrayList instead of the Vectors previously used. >>>> >>>> >>>> Regards, >>>> >>>> Lance >>>> >>>> >>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>> Oracle Java Engineering >>>> 1 Network Drive >>>> Burlington, MA 01803 >>>> Lance.Andersen at oracle.com >>>> >>>> Oracle is committed to developing practices and products that help protect the environment >>>> >>>> >>>> > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > From maurizio.cimadamore at oracle.com Wed Apr 27 12:51:19 2011 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 27 Apr 2011 13:51:19 +0100 Subject: Unreachable catch classes In-Reply-To: <4DB7D13F.5050500@oracle.com> References: <4DB77713.1030101@oracle.com> <4DB78284.8080908@oracle.com> <4DB7CE59.2020206@oracle.com> <4DB7D13F.5050500@oracle.com> Message-ID: <4DB81147.3010800@oracle.com> On 27/04/11 09:18, David Holmes wrote: > Special-casing Throwable wouldn't be sufficient as people may use > Exception instead. I guess this doesn't invalidate the argument - we could special-case Exception AND Throwable, since they are already treated specially in the language... Maurizio From alan.bateman at oracle.com Wed Apr 27 12:50:56 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 27 Apr 2011 12:50:56 +0000 Subject: hg: jdk7/tl/jdk: 7039186: (ch) EPoll based asynchronous I/O implementation should be portable to linux-arm and linux-ppc Message-ID: <20110427125120.A5E8147046@hg.openjdk.java.net> Changeset: a0dde3ff1dfd Author: alanb Date: 2011-04-27 13:46 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a0dde3ff1dfd 7039186: (ch) EPoll based asynchronous I/O implementation should be portable to linux-arm and linux-ppc Reviewed-by: dholmes ! make/java/nio/mapfile-linux ! src/solaris/classes/sun/nio/ch/EPoll.java ! src/solaris/classes/sun/nio/fs/LinuxWatchService.java ! src/solaris/native/sun/nio/ch/EPoll.c ! src/solaris/native/sun/nio/fs/LinuxWatchService.c From Lance.Andersen at oracle.com Wed Apr 27 13:20:22 2011 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Wed, 27 Apr 2011 09:20:22 -0400 Subject: Are emails arriving late to core-libs-dev In-Reply-To: <4DB80F9E.7080902@oracle.com> References: <4D7A83AA.8060208@gmx.de> <4D7A8E2B.3070407@univ-mlv.fr> <4DB80F9E.7080902@oracle.com> Message-ID: <4D561B9D-0400-4E45-AF2B-7A68C535940E@oracle.com> Hi David, Thank you for the confirmation, that it was a general outage and not just me :-) Regards, Lance On Apr 27, 2011, at 8:44 AM, David Holmes wrote: > Lance, > > There's been some kind of blockage in the openjdk mailing system and it finally got released today. As a result people are getting missing emails from as far back as early March, as well as some duplicate emails. > > David > > Lance Andersen - Oracle said the following on 04/27/11 22:28: >> Hi Remi and team, >> I just received this today, notice the date "March 11th, 2011". I also received a slew of other emails from core-libs-dev that were also sent days ago. >> Regards, >> Lance >> p.s. Remi, Thank you for the comments below. I will look at incorporating some of the changes such as drivers.isEmpty() in a future update to DriverManager. >> My Best, >> Lance >> On Mar 11, 2011, at 4:03 PM, R?mi Forax wrote: >>> Hi Lance, >>> - logSync is not declared final. >>> - the comment "thow a SecurityException" is not that useful >>> - in getDrivers(), I think you can use an ArrayList to gather >>> all drivers and use Collections.enumeration() at the end. >>> - also instead of >>> >>> if (drivers == null || drivers.equals("")) { >>> >>> if (drivers == null || drivers.isEmpty()) { >>> >>> should be a little more efficient. >>> >>> That's all :) >>> >>> R?mi >>> >>> On 03/11/2011 09:18 PM, Ulf Zibis wrote: >>>> Maybe you could update the javadoc style ( -> @code etc.) and move the constructor to the begining. >>>> >>>> -Ulf >>>> >>>> >>>> Am 11.03.2011 21:03, schrieb Lance Andersen - Oracle: >>>>> Hi, >>>>> >>>>> I have posted the diffs to DriverManager for review at http://cr.openjdk.java.net/~lancea/7026898/. This change utilizes CopyOnWriteArrayList instead of the Vectors previously used. >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Lance >>>>> >>>>> >>>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>>> Oracle Java Engineering >>>>> 1 Network Drive >>>>> Burlington, MA 01803 >>>>> Lance.Andersen at oracle.com >>>>> >>>>> Oracle is committed to developing practices and products that help protect the environment >>>>> >>>>> >>>>> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering 1 Network Drive Burlington, MA 01803 >> Lance.Andersen at oracle.com Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From Alan.Bateman at oracle.com Wed Apr 27 15:51:39 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 27 Apr 2011 16:51:39 +0100 Subject: Fwd: Re: Codereview Request: 7039066 j.u.rgex does not match TR#18 RL1.4 Simple Word Boundaries and RL1.2 Properties In-Reply-To: <4DB6F3E5.9010704@oracle.com> References: <4DB381FD.7050600@oracle.com> <4DB46A67.8010106@oracle.com> <4DB508E8.5010907@oracle.com> <4DB68E67.3050207@oracle.com> <4DB6F3E5.9010704@oracle.com> Message-ID: <4DB83B8B.4060903@oracle.com> Xueming Shen wrote: > : > > UNICODE_CHARACTER_CLASS is clear and straightforward. I am OK with it. > > The webrev, ccc and api docs have been updated accordingly. > > Yes, I still need a reviewer for the implementation changes. Tom has > helped review > the doc (and the definition of those properties). I've gone through the implementation changes. Looks good and I didn't see anything obviously wrong. A couple of minor comments: In UnicodeProp.forName it might be more efficient to eliminate the containsKey and instead check whether get returns null. Also, should this only be ignoring IAE rather than Exception? In Pattern.java L912 I guess you didn't mean to change "string" to "stringg". Another one at L1317 - "if UNICODE_CHARACTER_CLASS presents" - I assume this should be "present". You might want to check the headers on the new tests - looks like you've included the header that has the classpath exception, also they claim to have been written years ago. UnicodeProp is also confused about its birthdate. -Alan From stuart.marks at oracle.com Wed Apr 27 16:45:46 2011 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 27 Apr 2011 09:45:46 -0700 Subject: Are emails arriving late to core-libs-dev In-Reply-To: <4D561B9D-0400-4E45-AF2B-7A68C535940E@oracle.com> References: <4D7A83AA.8060208@gmx.de> <4D7A8E2B.3070407@univ-mlv.fr> <4DB80F9E.7080902@oracle.com> <4D561B9D-0400-4E45-AF2B-7A68C535940E@oracle.com> Message-ID: <4DB8483A.9010603@oracle.com> Yes, yesterday evening I also received around 60 old emails destined for core-libs-dev, plus bunches of emails for other openjdk lists. So it apparently affected all the openjdk lists, not just core-libs-dev. Interestingly, a message I sent early yesterday made it fairly quickly to the To-line recipients and into the mail archive, but it didn't go out to the mailing list itself until late yesterday during the general unblockage. This might be a clue as to the nature of the blockage; not sure. s'marks On 4/27/11 6:20 AM, Lance Andersen - Oracle wrote: > Hi David, > > Thank you for the confirmation, that it was a general outage and not just me :-) > > > Regards, > Lance > On Apr 27, 2011, at 8:44 AM, David Holmes wrote: > >> Lance, >> >> There's been some kind of blockage in the openjdk mailing system and it finally got released today. As a result people are getting missing emails from as far back as early March, as well as some duplicate emails. >> >> David >> >> Lance Andersen - Oracle said the following on 04/27/11 22:28: >>> Hi Remi and team, >>> I just received this today, notice the date "March 11th, 2011". I also received a slew of other emails from core-libs-dev that were also sent days ago. >>> Regards, >>> Lance >>> p.s. Remi, Thank you for the comments below. I will look at incorporating some of the changes such as drivers.isEmpty() in a future update to DriverManager. >>> My Best, >>> Lance >>> On Mar 11, 2011, at 4:03 PM, R?mi Forax wrote: >>>> Hi Lance, >>>> - logSync is not declared final. >>>> - the comment "thow a SecurityException" is not that useful >>>> - in getDrivers(), I think you can use an ArrayList to gather >>>> all drivers and use Collections.enumeration() at the end. >>>> - also instead of >>>> >>>> if (drivers == null || drivers.equals("")) { >>>> >>>> if (drivers == null || drivers.isEmpty()) { >>>> >>>> should be a little more efficient. >>>> >>>> That's all :) >>>> >>>> R?mi >>>> >>>> On 03/11/2011 09:18 PM, Ulf Zibis wrote: >>>>> Maybe you could update the javadoc style ( -> @code etc.) and move the constructor to the begining. >>>>> >>>>> -Ulf >>>>> >>>>> >>>>> Am 11.03.2011 21:03, schrieb Lance Andersen - Oracle: >>>>>> Hi, >>>>>> >>>>>> I have posted the diffs to DriverManager for review at http://cr.openjdk.java.net/~lancea/7026898/. This change utilizes CopyOnWriteArrayList instead of the Vectors previously used. >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Lance >>>>>> >>>>>> >>>>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>>>> Oracle Java Engineering >>>>>> 1 Network Drive >>>>>> Burlington, MA 01803 >>>>>> Lance.Andersen at oracle.com >>>>>> >>>>>> Oracle is committed to developing practices and products that help protect the environment >>>>>> >>>>>> >>>>>> >>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>> Oracle Java Engineering 1 Network Drive Burlington, MA 01803 >>> Lance.Andersen at oracle.com > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > From lance at luckydogtennis.com Fri Apr 22 14:28:27 2011 From: lance at luckydogtennis.com (Lance Andersen) Date: Fri, 22 Apr 2011 10:28:27 -0400 Subject: Review request for 7038565, for a findbugs warning for BatchUpdateException Message-ID: <37D90D60-1898-4544-9C78-E104A5F3A49F@luckydogtennis.com> Hi Folks, I am looking for a reviewer for this update to BatchUpdateException to address a findbugs issue for exposing a mutable object. The webrev is at http://cr.openjdk.java.net/~lancea/7038565/ Have a great weekend! Regards, lance -- Lance Andersen PTR National Tester & Clinician 4A/National Cardio Tennis Speaker Team/USPTA/USRSA mobile: 978 857-0446 luckydogtennis.com -- luckydogtennis.com/TennisBlog -- cardiotennis.com From mark at macchiato.com Sat Apr 23 16:09:55 2011 From: mark at macchiato.com (=?UTF-8?B?TWFyayBEYXZpcyDimJU=?=) Date: Sat, 23 Apr 2011 09:09:55 -0700 Subject: Codereview Request: 7039066 j.u.rgex does not match TR#18 RL1.4 Simple Word Boundaries and RL1.2 Properties In-Reply-To: <4DB289DA.8040609@oracle.com> References: <4DB28708.9060504@oracle.com> <4DB289DA.8040609@oracle.com> Message-ID: The changes sound good. The flag UNICODE_CHARSET will be misleading, since all of Java uses the Unicode Charset (= encoding). How about: UNICODE_SPEC or something that gives that flavor. Mark *? Il meglio ? l?inimico del bene ?* On Sat, Apr 23, 2011 at 01:12, Xueming Shen wrote: > The flag this request proposed to add is > > UNICODE_CHARSET > > not the "UNICODE_UNICODE" in last email. > > My apology for the typo. > > Any suggestion for a better name? It was UNICODE_CHARACTERCLASS, but then > it > became UNICODE_CHARSET, considering the unicode_case. > > -Sherman > > > On 4/23/2011 1:00 AM, Xueming Shen wrote: > >> Hi >> >> This proposal tries to address >> >> (1) j.u.regex does not meet Unicode regex's Simple Word Boundaries [1] >> requirement as Tom pointed >> out in his email on i18n-dev list [2]. Basically we have 3 problems here. >> >> a. ju.regex word boundary construct \b and \B uses Unicode \p{letter} + >> \p{digit} as the "word" >> definition when the standard requires the true Unicode >> \p{Alphabetic} property be used instead. >> It also neglects two of the specifically required characters: >> U+200C ZERO WIDTH NON-JOINER >> U+200D ZERO WIDTH JOINER >> (or the "word" could be \p{alphabetic} + \p{gc=Mark} + \p{digit + >> \p{gc=Connector_Punctuation}, if >> follow Annex C). >> b. j.u.regex's word construct \w and \W are ASCII only version >> c. It breaks the historical connection between word characters and word >> boundaries (because of >> a) and b). For example "?l?ve" is NOT matched by the \b\w+\b >> pattern) >> >> (2) j.u.regex does not meet Unicode regex's Properties requirement >> [3][5][6][7]. Th main issues are >> >> a. Alphabetic: totally missing from the platform, not only regex >> b. Lowercase, Uppercase and White_Space: Java implementation (via >> \p{javaMethod} is different >> compared to Unicode Standard definition. >> c. j.u.regex's POSIX character classes are ASCII only, when standard >> has an Unicode version defined >> at tr#18 Annex C [3] >> >> As the solution, I propose to >> >> (1) add a flag UNICODE_UNICODE to >> a) flip the ASCII only predefined character classes (\b \B \w \W \d \D >> \s \S) and POSIX character >> classes (\p{alpha}, \p{lower}, \{upper}...) to Unicode version >> b) enable the UNICODE_CASE (anything Unicode) >> >> While ideally we would like to just evolve/upgrade the Java regex from >> the aged "ascii-only" >> to unicode (maybe add a OLD_ASCII_ONLY_POSIX as a fallback:-)), like >> what Perl did. But >> given the Java's "compatibility" spirit (and the performance concern as >> well), this is unlikely to >> happen. >> >> (2) add \p{IsBinaryProperty} to explicitly support some important Unicode >> binary properties, such >> as \p{IsAlphabetic}, \p{IsIdeographic}, \p{IsPunctuation}...with this >> j.u.regex can easily access >> some properties that are either not provided by j.l.Character directly >> or j.l.Character has a >> different version (for example the White_Space). >> (The missing alphabetic, different uppercase/lowercase issue has >> been/is being addressed at >> Cr#7037261 [4], any reviewer?) >> >> The webrev is at >> http://cr.openjdk.java.net/~sherman/7039066/webrev/ >> >> The corresponding updated api j.u.regex.Pattern API doc is at >> http://cr.openjdk.java.net/~sherman/7039066/Pattern.html >> >> Specdiff result is at >> http://cr.openjdk.java.net/~sherman/7039066/specdiff/diff.html >> >> I will file the CCC request if the API change proposal in webrev is >> approved. This is coming in very late >> so it is possible that it may be held back until Java 8, if it can not >> make the cutoff for jdk7. >> >> -Sherman >> >> >> [1] http://www.unicode.org/reports/tr18/#Simple_Word_Boundaries >> [2] >> http://mail.openjdk.java.net/pipermail/i18n-dev/2011-January/000256.html >> [3] http://www.unicode.org/reports/tr18/#Compatibility_Properties >> [4] >> http://mail.openjdk.java.net/pipermail/i18n-dev/2011-April/000370.html >> [5] >> http://mail.openjdk.java.net/pipermail/i18n-dev/2011-January/000249.html >> [6] >> http://mail.openjdk.java.net/pipermail/i18n-dev/2011-January/000253.html >> [7] >> http://mail.openjdk.java.net/pipermail/i18n-dev/2011-January/000254.html >> > > From tchrist at perl.com Sat Apr 23 17:48:35 2011 From: tchrist at perl.com (Tom Christiansen) Date: Sat, 23 Apr 2011 11:48:35 -0600 Subject: Codereview Request: 7039066 j.u.rgex does not match TR#18 RL1.4 Simple Word Boundaries and RL1.2 Properties In-Reply-To: References: <4DB28708.9060504@oracle.com> <4DB289DA.8040609@oracle.com> Message-ID: <17481.1303580915@chthon> Mark Davis ? wrote on Sat, 23 Apr 2011 09:09:55 PDT: > The changes sound good. They sure do, don't they? I'm quite happy about this. I think it is more important to get this in the queue than that it (necessarily) be done for JDK7. That said, having a good tr18 RL1 story for JDK7's Unicode 6.0 debut makes it attractive now. But if not now, then soon is good enough. > The flag UNICODE_CHARSET will be misleading, since > all of Java uses the Unicode Charset (= encoding). How about: > UNICODE_SPEC > or something that gives that flavor. I hadn't thought of that, but I do see what you mean. The idea is that the semantics of \w etc change to match the Unicode spec in tr18. I worry that UNICODE_SPEC, or even UNICODE_SEMANTICS, might be too broad a brush. What then happens when, as I imagine it someday shall, Java gets full support for RL2.3 boundaries, the way with ICU one uses or (?w) or UREGEX_UWORD for? Wouldn't calling something UNICODE_SPEC be too broad? Or should UNICODE_SPEC automatically include not just existing Unicode flags like UNICODE_CASE, but also any UREGEX_UWORD that comes along? If it does, you have back-compat issue, and if it doesn't, you have a misnaming issue. Seems like a bit of a Catch22. The reason I'd suggested UNICODE_CHARSET was because of my own background with the names we use for this within the Perl regex source code (which is itself written in C). I believe that Java doesn't have the same situation as gave rise to it in Perl, and perhaps something else would be clearer. Here's some background for why we felt we had to go that way. To control the behavior of \w and such, when a regex is compiled, a compiled Perl gets exactly one of these states: REGEX_UNICODE_CHARSET REGEX_LOCALE_CHARSET REGEX_ASCII_RESTRICTED_CHARSET REGEX_DEPENDS_CHARSET That state it normally inherits from the surrounding lexical scope, although this can be overridden with /u and /a, or (?u) and (?a), either within the pattern or as a separate pattern-compilation flag. REGEX_UNICODE_CHARSET corresponds to out (?u), so \w and such all get the full RL1.2a definitions. Because Perl always does Unicode casemapping -- and full casemapping, too, not just simple -- we didn't need (?u) for what Java uses it for, which is just as an extra flavor of (?i); it doesn't do all that much. (BTW, the old default is *not* some sort of non-Unicode charset semantics, it's the ugly REGEX_DEPENDS_CHARSET, which is Unicode for code points > 255 and "maybe" so in the 128-255 range.) What we did certainly isn't perfect, but it allows for both backwards compat and future growth. This was because people want(ed) to be able to use regexes on both byte arrays yet also on character strings. Me, I think it's nuts to support this at all, that if you want an input stream in (say) CP1251 or ISO 8859-2, that you simply set that stream's encoding and be done with it: everything turns into characters internally. But there's old byte and locale code out there whose semantics we are loth to change out from under people. Java has the same kind of issue. The reason we ever support anything else is because we got (IMHO nasty) POSIX locales before we got Unicode support, which didn't happen till toward the end of the last millennium. So we're stuck supporting code well more than a decade old, perhaps indefinitely. It's messy, but it is very hard to do anything about that. I think Java shares in that perspective. This corresponds, I think, to Java needing to support pre-Unicode regex semantics on \w and related escapes. If they had started out with it always means the real thing the way ICU did, they wouldn't need both. I wish there were a pragma to control this on a per-lexical-scope basis, but I'm don't enough about the Java compilers internals to begin to know how to go about implementing some thing like that, even as a -XX:+UseUnicodeSemantics CLI switch for that compilation unit. One reason you want this is because the Java String class has these "convenience" methods like matches, replaceAll, etc, that take regexes but do not provide an API that admits Pattern compile flags. If there is no way to embed a (?U) directive or some such, nor any way to pass in a Pattern.UNICODE_something flag. The Java String API could also be broadened through method signature overloading, but for now, you can't do that. No matter what the UNICODE_something gets called, I think there needs to be a corresponding embeddable (?X)-style flag as well. Even if String were broadened, you'd want people to be able to specify *within the regex* that that regex should have full Unicode semantics. After all, they might read the pattern in from a file. That's why (most) Pattern.compile flags need to be able to embedded, too. But you knew that already. :) --tom From tchrist at perl.com Mon Apr 25 03:47:50 2011 From: tchrist at perl.com (Tom Christiansen) Date: Sun, 24 Apr 2011 21:47:50 -0600 Subject: Codereview Request: 7039066 j.u.rgex does not match TR#18 RL1.4 Simple Word Boundaries and RL1.2 Properties In-Reply-To: <4DB37496.8070801@oracle.com> References: <4DB28708.9060504@oracle.com> <4DB289DA.8040609@oracle.com> <17481.1303580915@chthon> <4DB37496.8070801@oracle.com> Message-ID: <29462.1303703270@chthon> Xueming, the docs look good. On the name of the flag, I have no strong feelings one way or the other. Perhaps between UNICODE_PROPERTIES and UNICODE_CLASSES, I would prefer the second one. The first makes me think of the regular properties like \p{Script=Greek} from RL1.2, not the compat properties from RL1.2a like \w and \s. (I realize that the POSIX-compat stuff overlaps a bit.) One thing you might want to take a look at longer term is whether all 11 properties listed in RL1.2 will be accessible. I don't know whether you have methods in Character for #7 and #8 below; I seem to recall seeing one but not the other. RL1.2 Properties To meet this requirement, an implementation shall provide at least a minimal list of properties, consisting of the following: yes 1 General_Category yes 2 Script yes 3 Alphabetic yes 4 Uppercase yes 5 Lowercase yes 6 White_Space ? 7 Noncharacter_Code_Point ? 8 Default_Ignorable_Code_Point ? 9 ANY yes 10 ASCII ? 11 ASSIGNED RL1.2a Compatibility Properties To meet this requirement, an implementation shall provide the properties listed in Annex C. Compatibility Properties, with the property values as listed there. Such an implementation shall document whether it is using the Standard Recommendation or POSIX-compatible properties. Other things... I've thought a bit about whether it's worth pointing out that \x{h..h.} is the *only* way to (currently?) get non-BMP code points into a bracketed character class, like for example [\x{1D400}-\x{1D419}] to mean MATHEMATICAL BOLD CAPITAL A through MATHEMATICAL BOLD CAPITAL Z. Reasons for not mentioning it include how rarely (I imagine) that users come across it, and also because this is one of those rare places in Java where you can't treat UTF-16 code units separately and get the same results. This matters for interpolation, because you can never build up a character class by using [ ] to surround the two different 16-bit char units that non-BMP codepoints turn into. You always have to use the indirect \x{h..h} instead. This is rather non-obvious. However, after consideration I think it probably not worth risking confusing people by talking about it. I'm just very glad it can now be done. Having to figure out pieces of UTF-16 is no fun. Once the current effort is done and you've had a well-deserved rest, I know you were thinking about \N{NAME} and \X for a future version of the JDK. Both are important, although for quite different reasons. \N{NAME} is important for helping make regex code more maintainable by being self-documenting, since having to putting raw "magic" numbers instead of symbolic names in code is always bad. You'll certainly want to somehow make that available for Strings, too; not sure how to do that. The regex string escapes and the Java String escapes have already diverged, and I don't know how that happened. For example, the rules for octal escapes differ, and the regex engine supports things that Java proper does not; The "\cA" style comes to mind, but I think there are a few others, too. And now there is "\x{h..h}" too; pity Strings don't know that one. \X is important because you really do need access to graphemes. Otherwise it is very difficult to write the equivalent of (?:(?=[aeiou])\X), which assuming NFD, will match a grapheme that start with one of those five letters. More importantly, you have to be able to chunk text by graphemes, and you need to do this even if you don't someday make a way to tie \b to the fancier sense like the ICU (?w) UREGEX_UWORD flag provides. Getting grapheme clusters right is harder than it might appear. A careful reading of UAX#29 is important. There are two kinds of grapheme clusters, either legacy or extended. The extended version is tricky to get right, especially when you don't have access to all the syllable type properties. One problem with the legacy version is that it breaks up things that it shouldn't. We switched to the extended version for the 5.12 release of Perl, as this shows: $ perl5.10.0 -le 'print "\r\n" =~ /\A\X\z/ ? 1 : 0' 0 $ perl5.12.3 -le 'print "\r\n" =~ /\A\X\z/ ? 1 : 0' 1 Which is the way it really needs to be. For the legacy sense, you can always still code that one up more explicitly: $ perl5.12.3 -le 'print "\r\n" =~ /\A\p{Grapheme_Base}\p{Grapheme_Extend}*\z/ ? 1 : 0' 0 But I don't think people often want that version; extended is much better. Giving Java access to the properties needed for either version of grapheme clusters may be a good time to reconsider whether you might wish to redesign how you check whether a code point has any particular Unicode property. There are of course performance issues, but also because the current mechanism does not seem easily extended to support the full complement of Unicode properties (which is a new Level-2 RL). So if you are going to widen those again so you can have the properties at your fingertips that you need to support grapheme clusters, it might be worth thinking whether to refactor now or not. Performance and the size of tables will someday become an issue, if not now. I do know the Unicode docs mention this concern; I also know that we have people rethinking how Perl grants access to properties, because even though we do give you all of them, it could be done more tidily. I haven't thought much about what the non-regex interface to graphemes and such should look like. Besides the ICU stuff, something you might want to take a look at, just to see the sorts of things others are doing in the non-regex grapheme arena, is these two classes: http://search.cpan.org/perldoc?Unicode::GCString http://search.cpan.org/perldoc?Unicode::LineBreak It's Spartan, but it will give you an idea. I couldn't (well, wouldn't *want* to) do East Asian text segmentation without those, which is something I've done a bit of lately. Like all the good 3rd-party Unicode modules in Perl, those two come from Asia. They're often the driving force behind progress in Unicode support. With all those complicated scripts, you can certainly see why, too. Hope this helps! --tom From xueming.shen at oracle.com Wed Apr 27 17:14:09 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 27 Apr 2011 10:14:09 -0700 Subject: Fwd: Re: Codereview Request: 7039066 j.u.rgex does not match TR#18 RL1.4 Simple Word Boundaries and RL1.2 Properties In-Reply-To: <4DB83B8B.4060903@oracle.com> References: <4DB381FD.7050600@oracle.com> <4DB46A67.8010106@oracle.com> <4DB508E8.5010907@oracle.com> <4DB68E67.3050207@oracle.com> <4DB6F3E5.9010704@oracle.com> <4DB83B8B.4060903@oracle.com> Message-ID: <4DB84EE1.7010601@oracle.com> Thanks Alan! webrev has been updated accordingly. -Sherman On 4/27/2011 8:51 AM, Alan Bateman wrote: > Xueming Shen wrote: >> : >> >> UNICODE_CHARACTER_CLASS is clear and straightforward. I am OK with it. >> >> The webrev, ccc and api docs have been updated accordingly. >> >> Yes, I still need a reviewer for the implementation changes. Tom has >> helped review >> the doc (and the definition of those properties). > I've gone through the implementation changes. Looks good and I didn't > see anything obviously wrong. A couple of minor comments: > > In UnicodeProp.forName it might be more efficient to eliminate the > containsKey and instead check whether get returns null. Also, should > this only be ignoring IAE rather than Exception? > > In Pattern.java L912 I guess you didn't mean to change "string" to > "stringg". Another one at L1317 - "if UNICODE_CHARACTER_CLASS > presents" - I assume this should be "present". > > You might want to check the headers on the new tests - looks like > you've included the header that has the classpath exception, also they > claim to have been written years ago. UnicodeProp is also confused > about its birthdate. > > -Alan > > From stuart.marks at oracle.com Wed Apr 27 17:38:00 2011 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 27 Apr 2011 10:38:00 -0700 Subject: array clone() vs Arrays.copyOf() In-Reply-To: <4DB7DFB5.3040901@oracle.com> References: <5CE3B0CD-918C-4E03-B349-CD886129DB8E@oracle.com> <4DB1ACD5.8010205@univ-mlv.fr> <4DB1C76B.4060605@univ-mlv.fr> <4DB2A5DC.8000204@oracle.com> <24CAE1E9-BB1A-425B-8B82-E6C9C8B3B362@oracle.com> <4DB6E2C0.3000503@oracle.com> <4DB764AC.8030002@oracle.com> <4DB7DD39.1070706@gmx.de> <4DB7DFB5.3040901@oracle.com> Message-ID: <4DB85478.3030007@oracle.com> On 4/27/11 2:19 AM, David Holmes wrote: > Ulf Zibis said the following on 04/27/11 19:09: >> BTW: Did you answer to the wrong thread (see attached screen shot) ? That was >> the reason why I came aware about this post ;-) > > That's weird. No I only answered direct to Stuarts email. I had replied on the same thread, but I changed the subject line in an attempt to make clear that I didn't intend to extend the review of Lance's change. The openjdk mail blockage intervened, and so David's reply appeared before my query. * * * As for Arrays.copyOf(), it's unfortunate that the overloads provided all require a length. It would be nice if you could just say newArray = Arrays.copyOf(oldArray); Then Arrays.copyOf() really would be one-stop shopping. I couldn't find any discussion about this, but I wouldn't be surprised if one-arg overloads of Arrays.copyOf() were ruled out with the reasoning that one could always use array.clone()! Of course, this is indeed redundant with array.clone(), but clone() is pretty obscure. I'll admit that I hadn't known about it until R?mi pointed it out in his review of Lance's changes. > Would be nice if defender methods were expanded to allow you to do anArray.copyOf() I'm not even sure defender methods are necessary here, since arrays don't implement any interface that, if extended, would cause binary compatibility. But I'm sure there are other language issues with extending arrays this way. This would also suffer from the same problem as clone(), in that it's pretty obscure. It's not in the javadoc, and you have to dive into the language spec in order to find it. This is a minor point, but is it worth an RFE? s'marks From mark.reinhold at oracle.com Wed Apr 27 17:44:18 2011 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 27 Apr 2011 10:44:18 -0700 Subject: Are emails arriving late to core-libs-dev In-Reply-To: stuart.marks@oracle.com; Wed, 27 Apr 2011 09:45:46 PDT; <4DB8483A.9010603@oracle.com> Message-ID: <20110427174418.6FA17AAB@eggemoggin.niobe.net> 2011/4/27 9:45 -0700, stuart.marks at oracle.com: > Yes, yesterday evening I also received around 60 old emails destined for > core-libs-dev, plus bunches of emails for other openjdk lists. So it apparently > affected all the openjdk lists, not just core-libs-dev. > > Interestingly, a message I sent early yesterday made it fairly quickly to the > To-line recipients and into the mail archive, but it didn't go out to the > mailing list itself until late yesterday during the general unblockage. This > might be a clue as to the nature of the blockage; not sure. The blockage was diagnosed last night (insert long story about intermittent DNS failures), a workaround was implemented, and the backlog was cleared. - Mark From stuart.marks at oracle.com Wed Apr 27 18:02:15 2011 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 27 Apr 2011 11:02:15 -0700 Subject: Review : 6546713: Link optional in Collection exception documentation to explanation In-Reply-To: References: <2677AA33-5EFC-471C-BD69-DE2ED028BEEC@oracle.com> <4DAE31B8.7010507@oracle.com> <4DAEC671.2000205@cs.oswego.edu> Message-ID: <4DB85A27.1080801@oracle.com> On 4/20/11 5:07 AM, Lance Andersen - Oracle wrote: > > On Apr 20, 2011, at 7:41 AM, Doug Lea wrote: > >> On 04/19/11 21:07, David Holmes wrote: >>> Hi Mike, >>> >>> Mike Duigou said the following on 04/20/11 08:00: >>>> Hello All; >>>> >>>> Another collections javadoc review request. This change links the "(optional)" >>>> notes in on various Collection methods to text which explains why they are not >>>> thrown by all collections. >>> >>> Generally looks good. I think you should revert this additional change in >>> Collection.java: >>> >>> ! * >>> >>> "null" is used all over the place without being code font, including other >>> @throws NullPointerException. >> >> This, along with literals "true" and "false" are not code-fonted >> very consistently. Someday someone should do a big consistency pass >> across the whole code base. > > Perhaps we can document what we believe the standards should be WRT when to use {@code} . I am sure I have clean up to do throughout the JDBC as well for consistency in this area I think there is a preference for {@code foobar} over foobar but I'm not sure it's written down anywhere. The "What's new in Javadoc 5.0" page [1] says that "{@code abc} is equivalent to {@literal abc}." This is useful in case "abc" contains angle brackets, which needn't be escaped if @code is used. This is a good reason to use @code instead of .... However, I think that and @code are overused in general. If it's used for an actual code fragment, fine, but I really think it's unnecessary for single words such as true, false, and null used within running text. To use this specific example, is @throws NullPointerException if the specified array is {@code null} really preferable to @throws NullPointerException if the specified array is null ? To my eye, the additional markup garbages up the javadoc source, makes it harder to edit, and it makes the formatted output harder to read. The most egregious example is {@code try}-with-resources. Check out java.lang.Throwable to see it in action. Perhaps @code is warranted in cases that would otherwise be ambiguous, such as create a long array versus create a {@code long} array But these cases are relatively rare. s'marks [1] http://download.oracle.com/javase/6/docs/technotes/guides/javadoc/whatsnew-1.5.0.html From Lance.Andersen at oracle.com Wed Apr 27 18:04:25 2011 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Wed, 27 Apr 2011 14:04:25 -0400 Subject: array clone() vs Arrays.copyOf() In-Reply-To: <4DB764AC.8030002@oracle.com> References: <5CE3B0CD-918C-4E03-B349-CD886129DB8E@oracle.com> <4DB1ACD5.8010205@univ-mlv.fr> <4DB1C76B.4060605@univ-mlv.fr> <4DB2A5DC.8000204@oracle.com> <24CAE1E9-BB1A-425B-8B82-E6C9C8B3B362@oracle.com> <4DB6E2C0.3000503@oracle.com> <4DB764AC.8030002@oracle.com> Message-ID: <70314DBF-E0ED-403D-8DA7-A025A3036412@oracle.com> Hi David, Stuart On Apr 26, 2011, at 8:34 PM, David Holmes wrote: > Hi Stuart, > > Actually my comments more a response to Remi's assertion that clone should have been used instead, without giving any technical rationale as to why clone would be better, and so much better that it warranted Lance changing the code. > > Personally I think we should be steering people to Arrays.copyOf for all their array copying needs. clone() is effectively legacy code. It may have a small performance benefit though ultimately both methods are intrinisified by the same C2 code so I don't believe the gain would be much, and likely only with smaller arrays. > > BTW I think Lance received communication from others over the use of copyOf versus clone, I never made any additional comments on the relative merits. Yes, I did receive additional input WRT using copyOf. I am going to stick with copyOf and I appreciate Remi's time and input (as I really do not want to change BatchUpdateException again ;-) ). Thank you for input. My Best, Lance > > Cheers, > David > > Stuart Marks said the following on 04/27/11 01:20: >> Hi David, >> I have a general code style question about this. This arose in the review of Lance's webrevs for 7038565 [1] but I'm starting a new thread since I don't want further discussion to drag out that review. >> In that review, Lance initially used Arrays.copyOf() to do defensive copying of an array. R?mi suggested calling clone() instead, and Lance changed it, but it looks like you (David) convinced him to change it back to use Arrays.copyOf(). >> (Quotes from the emails are below, but the attribution is hard to follow.) >> What's the rationale for using Arrays.copyOf() in this case? To me, clone() is the clearest and most concise way of making the copy. Arrays.copyOf() is slightly more verbose and the reader has to do a tiny bit of analysis to determine that the length isn't being changed, since the value passed is the current length. Is there some other reason I'm not aware of that Arrays.copyOf() should be preferred? >> I guess, one point is that it's hard to find the javadoc for the array clone() call. :-) >> I guess I'm mainly aiming this at David since he seemed to be the strongest advocate for the use of Arrays.copyOf(), but I'd welcome opinions from others as well. >> s'marks >> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-April/006694.html >> On 4/25/11 9:28 AM, Lance Andersen - Oracle wrote: >>> On Apr 23, 2011, at 6:11 AM, David Holmes wrote: >>> >>>> > R?mi Forax said the following on 04/23/11 04:22: >>>>> >> On 04/22/2011 06:51 PM, Lance Andersen - Oracle wrote: >>>>>>> >>>> >>>>>>> >>>> You should use clone() instead of Arrays.copyOf. >>>>>> >>> >>>>>> >>> Can you explain why you have a preference for clone() in this case? >>>>> >> It does the job :) >>>>> >> Arrays.copyOf() allows to resize the array. >>>> > >>>> > So? That's not a reason to not use Arrays.copyOf. Look at copyOf as the new improved version of clone. >>>> > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From forax at univ-mlv.fr Wed Apr 27 19:07:03 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 27 Apr 2011 21:07:03 +0200 Subject: array clone() vs Arrays.copyOf() In-Reply-To: <70314DBF-E0ED-403D-8DA7-A025A3036412@oracle.com> References: <5CE3B0CD-918C-4E03-B349-CD886129DB8E@oracle.com> <4DB1ACD5.8010205@univ-mlv.fr> <4DB1C76B.4060605@univ-mlv.fr> <4DB2A5DC.8000204@oracle.com> <24CAE1E9-BB1A-425B-8B82-E6C9C8B3B362@oracle.com> <4DB6E2C0.3000503@oracle.com> <4DB764AC.8030002@oracle.com> <70314DBF-E0ED-403D-8DA7-A025A3036412@oracle.com> Message-ID: <4DB86957.4090500@univ-mlv.fr> On 04/27/2011 08:04 PM, Lance Andersen - Oracle wrote: > Hi David, Stuart > On Apr 26, 2011, at 8:34 PM, David Holmes wrote: > >> Hi Stuart, >> >> Actually my comments more a response to Remi's assertion that clone should have been used instead, without giving any technical rationale as to why clone would be better, and so much better that it warranted Lance changing the code. >> >> Personally I think we should be steering people to Arrays.copyOf for all their array copying needs. clone() is effectively legacy code. It may have a small performance benefit though ultimately both methods are intrinisified by the same C2 code so I don't believe the gain would be much, and likely only with smaller arrays. >> >> BTW I think Lance received communication from others over the use of copyOf versus clone, I never made any additional comments on the relative merits. > Yes, I did receive additional input WRT using copyOf. I am going to stick with copyOf and I appreciate Remi's time and input (as I really do not want to change BatchUpdateException again ;-) ). > > Thank you for input. > > My Best, > Lance As I said, I'm not against Arrays.copyOf, for me it's like comparing for() and while(). >> Cheers, >> David cheers, R?mi From vincent.x.ryan at oracle.com Wed Apr 27 19:24:56 2011 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Wed, 27 Apr 2011 19:24:56 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20110427192526.9596547059@hg.openjdk.java.net> Changeset: 5a4e2a734f1d Author: vinnie Date: 2011-04-27 20:21 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5a4e2a734f1d 6753664: Support SHA256 (and higher) in SunMSCAPI Reviewed-by: mullan ! src/windows/classes/sun/security/mscapi/RSASignature.java ! src/windows/classes/sun/security/mscapi/SunMSCAPI.java ! src/windows/native/sun/security/mscapi/security.cpp + test/sun/security/mscapi/SignUsingSHA2withRSA.java + test/sun/security/mscapi/SignUsingSHA2withRSA.sh Changeset: 7c109d060365 Author: vinnie Date: 2011-04-27 20:24 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7c109d060365 Merge From mike.duigou at oracle.com Wed Apr 27 21:18:57 2011 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Wed, 27 Apr 2011 21:18:57 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20110427211930.A90834705F@hg.openjdk.java.net> Changeset: 5b05f8d1c0e5 Author: mduigou Date: 2011-04-26 14:25 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5b05f8d1c0e5 4884238: Adds java.nio.charset.StandardCharset to provide static final constants for the standard charsets. Reviewed-by: alanb, sherman, darcy ! src/share/classes/java/nio/charset/Charset.java + src/share/classes/java/nio/charset/StandardCharset.java ! src/share/classes/java/nio/file/Path.java ! src/share/classes/java/util/zip/ZipCoder.java ! src/share/classes/java/util/zip/ZipFile.java ! src/share/classes/java/util/zip/ZipInputStream.java ! src/share/classes/java/util/zip/ZipOutputStream.java ! src/share/classes/sun/awt/FontDescriptor.java + test/java/nio/charset/StandardCharset/Standard.java Changeset: bf2a12c1ffe3 Author: mduigou Date: 2011-04-27 14:18 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bf2a12c1ffe3 Merge From joe.darcy at oracle.com Thu Apr 28 00:04:12 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Thu, 28 Apr 2011 00:04:12 +0000 Subject: hg: jdk7/tl/langtools: 7039822: Project Coin: add explicit tests for the lub of an exception parameter Message-ID: <20110428000415.9A9DC47065@hg.openjdk.java.net> Changeset: a8f5cad1e6bb Author: darcy Date: 2011-04-27 17:03 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a8f5cad1e6bb 7039822: Project Coin: add explicit tests for the lub of an exception parameter Reviewed-by: mcimadamore, jjg + test/tools/javac/multicatch/Neg07.java + test/tools/javac/multicatch/Neg07.out + test/tools/javac/multicatch/Pos10.java From bhavesh.patel at sun.com Thu Apr 28 00:16:21 2011 From: bhavesh.patel at sun.com (bhavesh.patel at sun.com) Date: Thu, 28 Apr 2011 00:16:21 +0000 Subject: hg: jdk7/tl/langtools: 7028815: Missing styles for some bulleted items in the new stylesheet Message-ID: <20110428001623.5630847067@hg.openjdk.java.net> Changeset: 5c81ba0eddff Author: bpatel Date: 2011-04-27 17:13 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/5c81ba0eddff 7028815: Missing styles for some bulleted items in the new stylesheet Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css ! test/com/sun/javadoc/testStylesheet/TestStylesheet.java From xueming.shen at oracle.com Thu Apr 28 06:34:27 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 27 Apr 2011 23:34:27 -0700 Subject: Codereview request: CR 7040220 java/char_encodin Optimize UTF-8 charset for String.getBytes()/toCharArray() Message-ID: <4DB90A73.5080602@oracle.com> Hi This is motivated by Neil's request to optimize common-case UTF8 path for native ZipFile.getEntry calls [1]. As I said in my replying email [2] I believe a better approach might be to "patch" UTF8 charset directly to implement sun.nio.cs.ArrayDecoder/Encoder interface to speed up the coding operation for array based encoding/decoding under certain circumstance, as we did for all single byte charsets in #6636323 [3]. I have a old blog [4] that has some data for this optimization. The original plan was to do the same thing for our new UTF8 [5] as well in JDK7, but then (excuse, excuse) I was just too busy to come back to this topic till 2 days ago. After two days of small tweaking here and there and testing those possible corner cases I can think of, I'm happy with the result and think it might be worth sending it out for a codereview for JDK7, knowing we only have couple days left. The webrev is at http://cr.openjdk.java.net/~sherman/7040220/webrev Those tests are supposed to make sure the coding result from the new paths for String.getBytes()/ toCharArray() matches the result from the existing implementation. The performance results of running StrCodingBenchmarkUTF8 (included in webrev) on my linux box in -client and -server mode respectively are included at http://cr.openjdk.java.net/~sherman/7040220/client http://cr.openjdk.java.net/~sherman/7040220/server The microbenchmark measures 1-byte, 2-byte, 3-byte and 4 bytes utf8 bits separately with different length of data (from 12 bytes to thousands) Thanks! -Sherman [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-April/006710.html [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-April/006726.html [3] http://cr.openjdk.java.net/~sherman/6636323_6636319/webrev [4] http://blogs.sun.com/xuemingshen/entry/faster_new_string_bytes_cs [5] http://blogs.sun.com/xuemingshen/entry/the_big_overhaul_of_java From Alan.Bateman at oracle.com Thu Apr 28 11:01:33 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 28 Apr 2011 12:01:33 +0100 Subject: Codereview request: CR 7040220 java/char_encodin Optimize UTF-8 charset for String.getBytes()/toCharArray() In-Reply-To: <4DB90A73.5080602@oracle.com> References: <4DB90A73.5080602@oracle.com> Message-ID: <4DB9490D.40105@oracle.com> Xueming Shen wrote: > Hi > > This is motivated by Neil's request to optimize common-case UTF8 path > for native ZipFile.getEntry calls [1]. > As I said in my replying email [2] I believe a better approach might > be to "patch" UTF8 charset directly to > implement sun.nio.cs.ArrayDecoder/Encoder interface to speed up the > coding operation for array based > encoding/decoding under certain circumstance, as we did for all single > byte charsets in #6636323 [3]. I > have a old blog [4] that has some data for this optimization. > > The original plan was to do the same thing for our new UTF8 [5] as > well in JDK7, but then (excuse, excuse) > I was just too busy to come back to this topic till 2 days ago. After > two days of small tweaking here and there > and testing those possible corner cases I can think of, I'm happy with > the result and think it might be > worth sending it out for a codereview for JDK7, knowing we only have > couple days left. I skimmed through the webrev and I agree this is a better approach. I will try to do a detailed review before Monday. It would be great if others on the list could jump in and help too as we are running out of time. Neil - I don't know if you've had a chance to look at Sherman's changes but I think it's better than checking if mUTF-8 can be used. If you agree then would you have time to run your tests that altered you to this performance regression? There's a patch file in the webrev. -Alan. From xiaoqiangnk at gmail.com Thu Apr 28 11:18:22 2011 From: xiaoqiangnk at gmail.com (Yongqiang Yang) Date: Thu, 28 Apr 2011 19:18:22 +0800 Subject: HELP: agent library error. Message-ID: Hi, Is this the right list? I am being confused by an error 'Could not find agent library on the library path or in the local directory: instrument'. Could anyone has ideas? My jdk version is 1.5. Thank you in advance. -- Best Wishes Yongqiang Yang From Ulf.Zibis at gmx.de Thu Apr 28 11:27:06 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 28 Apr 2011 13:27:06 +0200 Subject: Review (Updated) : 4884238 : Constants for Standard Charsets In-Reply-To: <4DAEC7B7.7000602@gmx.de> References: <4DAD7762.4000707@gmx.de> <12D33A70-593A-40A4-9B33-445D8A8FB6A0@oracle.com> <4DAEC7B7.7000602@gmx.de> Message-ID: <4DB94F0A.503@gmx.de> No answer ? Especially on: static constant vs. static method -Ulf Am 20.04.2011 13:47, schrieb Ulf Zibis: > Am 20.04.2011 02:23, schrieb Mike Duigou: >> On Apr 19 2011, at 04:52 , Ulf Zibis wrote: >>> I think, we should catch the problem at the source. ... In my approach from Bug 100098 - Make >>> sun.nio.cs.* charset objects light-weight such a class is named 'FastCharset'. >> Unfortunately any we at a very late stage in Java 7's development and the degree of change >> required by 100098 are not possible. > > Yes, that's right. For that reason I have suggested an intermediate solution to avoid the > additional, later not removable StandardCharset(s) class. > >> This issue itself may also be rejected solely for missing impending deadlines. > Should there something be done for that? > >>> So I tend to prefer the original request from 4884238 (have the canonical names as constants), >>> as the lookup via Charset.forName(...) then could be very fast compared to the anyway following >>> heavy de/encoding work. >> I think that in most uses a constant of the Charset is more useful as that's what's desired for >> use. I am not opposed to having visible constants for the charset names but I don't think it's as >> useful as the Charset objects. The performance of Charset.forName() is a separate matter. > > Thinking more I agree to some direct access to the standard charsets, because Charset.forName(..) > potentially needs extra exception handling. But is there a must for static constants? I think we > could have lazy initialized static methods, so (1) only the Charset class of request should be > loaded, (2) separate StandardCharset(s) class and discussion about the naming becomes superfluous, > (3) the small short cut cache in Charset remains it's proper function (otherwise the last 2, > UTF_16BE, UTF_16LE are cached), and (4) we could profit from it in Charset.defaultCharset() for > the fall-back case: > 622 defaultCharset = UTF_8(); > > I still think, we should have constants for the canonical charset names: Charset.UTF_8 = "UTF-8"; > etc... > > Additionally consider, that in many real world cases not the charset, but it's de/encoder is of > interest, so the programmer anyway needs to define a static constant, if for performance reason it > should be reused: > static final CharsetDecoder UTF_8_DECODER = UTF_8.newDecoder(); > > Here my new suggestion: > > public abstract class Charset implements Comparable { > static final String UTF_8 = "UTF-8"; > ... > static final Charset UTF_8() { > return forName(UTF_8); // Note that recently used charsets are hold in a small short cut > cache. > } > ... > } > > -Ulf > > > From maurizio.cimadamore at oracle.com Thu Apr 28 11:56:36 2011 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 28 Apr 2011 12:56:36 +0100 Subject: Unreachable catch classes In-Reply-To: <4DB81147.3010800@oracle.com> References: <4DB77713.1030101@oracle.com> <4DB78284.8080908@oracle.com> <4DB7CE59.2020206@oracle.com> <4DB7D13F.5050500@oracle.com> <4DB81147.3010800@oracle.com> Message-ID: <4DB955F4.8050900@oracle.com> On 27/04/11 13:51, Maurizio Cimadamore wrote: > On 27/04/11 09:18, David Holmes wrote: >> Special-casing Throwable wouldn't be sufficient as people may use >> Exception instead. > I guess this doesn't invalidate the argument - we could special-case > Exception AND Throwable, since they are already treated specially in > the language... > > Maurizio Hi after a discussion with the team, we have decided that we will relax the new javac warnings so that they will *not* be generated for those catch clauses catching Exception or Throwable. This is similar to how javac has always handled a similar case (error message: 'exception never thrown in body of try'); for example, this code compiles: try { } catch (Exception e) { ... } while the following does not compile: try { } catch (IOException e) { ... } //error IOException never thrown The code generating the newly added javac warnings will be changed accordingly; for example, the following will compile w/o warnings: try { throw new FileNotFoundException(); } catch (FileNotFoundException fnf) { ... } catch (Exception e) { ... } while the following code will still emit a 'dead catch' warning: try { throw new FileNotFoundException(); } catch (FileNotFoundException fnf) { ... } catch (IOException e) { ... } This should accommodate all weird cases of checked exceptions not being declared (as in Class.newInstance). Maurizio From David.Holmes at oracle.com Thu Apr 28 12:03:13 2011 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 28 Apr 2011 22:03:13 +1000 Subject: Unreachable catch classes In-Reply-To: <4DB955F4.8050900@oracle.com> References: <4DB77713.1030101@oracle.com> <4DB78284.8080908@oracle.com> <4DB7CE59.2020206@oracle.com> <4DB7D13F.5050500@oracle.com> <4DB81147.3010800@oracle.com> <4DB955F4.8050900@oracle.com> Message-ID: <4DB95781.3090207@oracle.com> Maurizio Cimadamore said the following on 04/28/11 21:56: > On 27/04/11 13:51, Maurizio Cimadamore wrote: >> On 27/04/11 09:18, David Holmes wrote: >>> Special-casing Throwable wouldn't be sufficient as people may use >>> Exception instead. >> I guess this doesn't invalidate the argument - we could special-case >> Exception AND Throwable, since they are already treated specially in >> the language... >> >> Maurizio > Hi > after a discussion with the team, we have decided that we will relax the > new javac warnings so that they will *not* be generated for those catch > clauses catching Exception or Throwable. > > This is similar to how javac has always handled a similar case (error > message: 'exception never thrown in body of try'); for example, this > code compiles: > > try { } > catch (Exception e) { ... } > > while the following does not compile: > > try { } > catch (IOException e) { ... } //error IOException never thrown Thanks Maurizio. I never realized the above case existed. :) David ----- > > The code generating the newly added javac warnings will be changed > accordingly; for example, the following will compile w/o warnings: > > try { throw new FileNotFoundException(); } > catch (FileNotFoundException fnf) { ... } > catch (Exception e) { ... } > > while the following code will still emit a 'dead catch' warning: > > try { throw new FileNotFoundException(); } > catch (FileNotFoundException fnf) { ... } > catch (IOException e) { ... } > > > This should accommodate all weird cases of checked exceptions not being > declared (as in Class.newInstance). > > Maurizio > > > > > From weijun.wang at oracle.com Thu Apr 28 12:36:29 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Thu, 28 Apr 2011 12:36:29 +0000 Subject: hg: jdk7/tl/jdk: 7037201: regression: invalid signed jar file not detected Message-ID: <20110428123656.913574709B@hg.openjdk.java.net> Changeset: 76703c84b3a2 Author: weijun Date: 2011-04-28 20:34 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/76703c84b3a2 7037201: regression: invalid signed jar file not detected Reviewed-by: mullan ! src/share/classes/java/util/jar/JarFile.java ! src/share/classes/java/util/jar/JarInputStream.java ! src/share/classes/java/util/jar/JarVerifier.java ! src/share/classes/sun/security/pkcs/PKCS7.java ! src/share/classes/sun/security/pkcs/SignerInfo.java ! src/share/classes/sun/security/util/ManifestEntryVerifier.java - src/share/classes/sun/security/util/SignatureFileManifest.java ! src/share/classes/sun/security/util/SignatureFileVerifier.java ! test/java/util/jar/JarInputStream/ScanSignedJar.java ! test/java/util/jar/JarInputStream/TestIndexedJarWithBadSignature.java From Ulf.Zibis at gmx.de Thu Apr 28 12:44:06 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 28 Apr 2011 14:44:06 +0200 Subject: Codereview request: CR 7040220 java/char_encodin Optimize UTF-8 charset for String.getBytes()/toCharArray() In-Reply-To: <4DB90A73.5080602@oracle.com> References: <4DB90A73.5080602@oracle.com> Message-ID: <4DB96116.4050903@gmx.de> Interesting results! Some days ago we had the discussion about constants for standard Charsets. Looking at your results, I see, that using *charset names constants*, the conversion mostly performs little better (up to 25 %), than using *charset constants*. So again my question: Why do we need those charset constants? IMO, we more need de/encoder constants, and array-based API for Charset class. In malformed(byte[] src, int sp, int nb) I think you could cache the ByteBuffer bb, instead instantiating a new one all the time. For this the method should not be static to ensure thread-safety. As you are there, did you refer to: 6795537 -UTF_8$Decoder returns wrong results 6798514 - Charset UTF-8 accepts CESU-8 codings -Ulf Am 28.04.2011 08:34, schrieb Xueming Shen: > Hi > > This is motivated by Neil's request to optimize common-case UTF8 path for native ZipFile.getEntry > calls [1]. > As I said in my replying email [2] I believe a better approach might be to "patch" UTF8 charset > directly to > implement sun.nio.cs.ArrayDecoder/Encoder interface to speed up the coding operation for array based > encoding/decoding under certain circumstance, as we did for all single byte charsets in #6636323 > [3]. I > have a old blog [4] that has some data for this optimization. > > The original plan was to do the same thing for our new UTF8 [5] as well in JDK7, but then (excuse, > excuse) > I was just too busy to come back to this topic till 2 days ago. After two days of small tweaking > here and there > and testing those possible corner cases I can think of, I'm happy with the result and think it > might be > worth sending it out for a codereview for JDK7, knowing we only have couple days left. > > The webrev is at > > http://cr.openjdk.java.net/~sherman/7040220/webrev > > Those tests are supposed to make sure the coding result from the new paths for String.getBytes()/ > toCharArray() matches the result from the existing implementation. > > The performance results of running StrCodingBenchmarkUTF8 (included in webrev) on my linux > box in -client and -server mode respectively are included at > > http://cr.openjdk.java.net/~sherman/7040220/client > http://cr.openjdk.java.net/~sherman/7040220/server > > The microbenchmark measures 1-byte, 2-byte, 3-byte and 4 bytes utf8 bits separately with different > length of data (from 12 bytes to thousands) > > Thanks! > -Sherman > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-April/006710.html > [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-April/006726.html > [3] http://cr.openjdk.java.net/~sherman/6636323_6636319/webrev > [4] http://blogs.sun.com/xuemingshen/entry/faster_new_string_bytes_cs > [5] http://blogs.sun.com/xuemingshen/entry/the_big_overhaul_of_java > From Ulf.Zibis at gmx.de Thu Apr 28 13:12:16 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 28 Apr 2011 15:12:16 +0200 Subject: Codereview request: CR 7040220 java/char_encodin Optimize UTF-8 charset for String.getBytes()/toCharArray() In-Reply-To: <4DB96116.4050903@gmx.de> References: <4DB90A73.5080602@oracle.com> <4DB96116.4050903@gmx.de> Message-ID: <4DB967B0.4020706@gmx.de> According to comments in 6795537 I additionally assume else if (b1< (byte)0xc2) should be little faster than else if ((b1>> 5) == -2) and if (isMalformed2(b1, b2)) could be replaced by if (isNotContinuation(b2)) -Ulf Am 28.04.2011 14:44, schrieb Ulf Zibis: > Interesting results! > > Some days ago we had the discussion about constants for standard Charsets. > > Looking at your results, I see, that using *charset names constants*, the conversion mostly > performs little better (up to 25 %), than using *charset constants*. > So again my question: Why do we need those charset constants? > IMO, we more need de/encoder constants, and array-based API for Charset class. > > In malformed(byte[] src, int sp, int nb) I think you could cache the ByteBuffer bb, instead > instantiating a new one all the time. For this the method should not be static to ensure > thread-safety. > > As you are there, did you refer to: > 6795537 -UTF_8$Decoder returns wrong results > > 6798514 - Charset UTF-8 accepts CESU-8 codings > > > -Ulf > > > > Am 28.04.2011 08:34, schrieb Xueming Shen: >> Hi >> >> This is motivated by Neil's request to optimize common-case UTF8 path for native ZipFile.getEntry >> calls [1]. >> As I said in my replying email [2] I believe a better approach might be to "patch" UTF8 charset >> directly to >> implement sun.nio.cs.ArrayDecoder/Encoder interface to speed up the coding operation for array based >> encoding/decoding under certain circumstance, as we did for all single byte charsets in #6636323 >> [3]. I >> have a old blog [4] that has some data for this optimization. >> >> The original plan was to do the same thing for our new UTF8 [5] as well in JDK7, but then >> (excuse, excuse) >> I was just too busy to come back to this topic till 2 days ago. After two days of small tweaking >> here and there >> and testing those possible corner cases I can think of, I'm happy with the result and think it >> might be >> worth sending it out for a codereview for JDK7, knowing we only have couple days left. >> >> The webrev is at >> >> http://cr.openjdk.java.net/~sherman/7040220/webrev >> >> Those tests are supposed to make sure the coding result from the new paths for String.getBytes()/ >> toCharArray() matches the result from the existing implementation. >> >> The performance results of running StrCodingBenchmarkUTF8 (included in webrev) on my linux >> box in -client and -server mode respectively are included at >> >> http://cr.openjdk.java.net/~sherman/7040220/client >> http://cr.openjdk.java.net/~sherman/7040220/server >> >> The microbenchmark measures 1-byte, 2-byte, 3-byte and 4 bytes utf8 bits separately with different >> length of data (from 12 bytes to thousands) >> >> Thanks! >> -Sherman >> >> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-April/006710.html >> [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-April/006726.html >> [3] http://cr.openjdk.java.net/~sherman/6636323_6636319/webrev >> [4] http://blogs.sun.com/xuemingshen/entry/faster_new_string_bytes_cs >> [5] http://blogs.sun.com/xuemingshen/entry/the_big_overhaul_of_java >> > From lance.andersen at oracle.com Thu Apr 28 13:47:01 2011 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Thu, 28 Apr 2011 13:47:01 +0000 Subject: hg: jdk7/tl/jdk: 7038565: address Findbugs issue in BatchUpdateException Message-ID: <20110428134721.BA14E470A1@hg.openjdk.java.net> Changeset: 28caa191884a Author: lancea Date: 2011-04-28 09:46 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/28caa191884a 7038565: address Findbugs issue in BatchUpdateException Reviewed-by: alanb, forax ! src/share/classes/java/sql/BatchUpdateException.java From mandy.chung at oracle.com Thu Apr 28 15:52:12 2011 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 28 Apr 2011 15:52:12 +0000 Subject: hg: jdk7/tl/jdk: 7037081: Remove com.sun.tracing from NON_CORE_PKGS Message-ID: <20110428155230.6DA0E470A8@hg.openjdk.java.net> Changeset: c3f5333e10e3 Author: mchung Date: 2011-04-28 08:51 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c3f5333e10e3 7037081: Remove com.sun.tracing from NON_CORE_PKGS Reviewed-by: ohair, jjg, jmasa ! make/docs/Makefile ! make/docs/NON_CORE_PKGS.gmk From mandy.chung at oracle.com Thu Apr 28 15:53:01 2011 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 28 Apr 2011 15:53:01 +0000 Subject: hg: jdk7/tl/langtools: 7037081: Remove com.sun.tracing from NON_CORE_PKGS Message-ID: <20110428155304.BA077470A9@hg.openjdk.java.net> Changeset: c7841bbe1227 Author: mchung Date: 2011-04-28 08:46 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/c7841bbe1227 7037081: Remove com.sun.tracing from NON_CORE_PKGS Reviewed-by: ohair, jjg, jmasa ! src/share/classes/com/sun/tools/javac/resources/legacy.properties From mike.duigou at oracle.com Thu Apr 28 17:14:26 2011 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Thu, 28 Apr 2011 17:14:26 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20110428171447.42D64470AD@hg.openjdk.java.net> Changeset: 37722a0a1c65 Author: mduigou Date: 2011-04-28 10:12 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/37722a0a1c65 7040381: Add StandardCharset.java to FILES_java.gmk Reviewed-by: alanb ! make/java/nio/FILES_java.gmk Changeset: 7b7c1ffd0752 Author: mduigou Date: 2011-04-28 10:14 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7b7c1ffd0752 Merge - src/share/classes/sun/security/util/SignatureFileManifest.java From Ulf.Zibis at gmx.de Thu Apr 28 17:15:10 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 28 Apr 2011 19:15:10 +0200 Subject: hg: jdk7/tl/jdk: 2 new changesets In-Reply-To: <20110427211930.A90834705F@hg.openjdk.java.net> References: <20110427211930.A90834705F@hg.openjdk.java.net> Message-ID: <4DB9A09E.7000400@gmx.de> Hey Mike, why didn't you follow Mark's explanation about the naming for StandardCharset(s) ? Did you have had other discussions internally? -Ulf Am 27.04.2011 23:18, schrieb mike.duigou at oracle.com: > Changeset: 5b05f8d1c0e5 > Author: mduigou > Date: 2011-04-26 14:25 -0700 > URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5b05f8d1c0e5 > > 4884238: Adds java.nio.charset.StandardCharset to provide static final constants for the standard charsets. > Reviewed-by: alanb, sherman, darcy > > ! src/share/classes/java/nio/charset/Charset.java > + src/share/classes/java/nio/charset/StandardCharset.java > ! src/share/classes/java/nio/file/Path.java > ! src/share/classes/java/util/zip/ZipCoder.java > ! src/share/classes/java/util/zip/ZipFile.java > ! src/share/classes/java/util/zip/ZipInputStream.java > ! src/share/classes/java/util/zip/ZipOutputStream.java > ! src/share/classes/sun/awt/FontDescriptor.java > + test/java/nio/charset/StandardCharset/Standard.java > > Changeset: bf2a12c1ffe3 > Author: mduigou > Date: 2011-04-27 14:18 -0700 > URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bf2a12c1ffe3 > > Merge > > > From mike.duigou at oracle.com Thu Apr 28 17:38:25 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 28 Apr 2011 10:38:25 -0700 Subject: hg: jdk7/tl/jdk: 2 new changesets In-Reply-To: <4DB9A09E.7000400@gmx.de> References: <20110427211930.A90834705F@hg.openjdk.java.net> <4DB9A09E.7000400@gmx.de> Message-ID: <9A3BFB0C-22CC-45A0-82E0-05F09BF2D17B@oracle.com> Essentially we ran out of time for this task and were confident enough in out decision about the design and choice of names to go ahead. More discussion didn't seem to be leading anywhere but inaction and there are other issues (always) that need attention. Mike On Apr 28 2011, at 10:15 , Ulf Zibis wrote: > Hey Mike, > > why didn't you follow Mark's explanation about the naming for StandardCharset(s) ? > > Did you have had other discussions internally? > > -Ulf > > > Am 27.04.2011 23:18, schrieb mike.duigou at oracle.com: >> Changeset: 5b05f8d1c0e5 >> Author: mduigou >> Date: 2011-04-26 14:25 -0700 >> URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5b05f8d1c0e5 >> >> 4884238: Adds java.nio.charset.StandardCharset to provide static final constants for the standard charsets. >> Reviewed-by: alanb, sherman, darcy >> >> ! src/share/classes/java/nio/charset/Charset.java >> + src/share/classes/java/nio/charset/StandardCharset.java >> ! src/share/classes/java/nio/file/Path.java >> ! src/share/classes/java/util/zip/ZipCoder.java >> ! src/share/classes/java/util/zip/ZipFile.java >> ! src/share/classes/java/util/zip/ZipInputStream.java >> ! src/share/classes/java/util/zip/ZipOutputStream.java >> ! src/share/classes/sun/awt/FontDescriptor.java >> + test/java/nio/charset/StandardCharset/Standard.java >> >> Changeset: bf2a12c1ffe3 >> Author: mduigou >> Date: 2011-04-27 14:18 -0700 >> URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bf2a12c1ffe3 >> >> Merge >> >> >> From Lance.Andersen at oracle.com Thu Apr 28 18:13:00 2011 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Thu, 28 Apr 2011 14:13:00 -0400 Subject: Review request the fix for CR 7040150 Message-ID: Hi all, I could use a reviewer for 7040150 which addresses a positioning issue with CacheResultSetImpl.removeCurrentRow(). The diff is located at: http://cr.openjdk.java.net/~lancea/7040150/webrev.00/ Thank you. Regards, Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From xueming.shen at oracle.com Thu Apr 28 19:56:34 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 28 Apr 2011 12:56:34 -0700 Subject: Codereview request: CR 7040220 java/char_encodin Optimize UTF-8 charset for String.getBytes()/toCharArray() In-Reply-To: <4DB96116.4050903@gmx.de> References: <4DB90A73.5080602@oracle.com> <4DB96116.4050903@gmx.de> Message-ID: <4DB9C672.1070306@oracle.com> On 04/28/2011 05:44 AM, Ulf Zibis wrote: > > In malformed(byte[] src, int sp, int nb) I think you could cache the > ByteBuffer bb, instead instantiating a new one all the time. For this > the method should not be static to ensure thread-safety. I was assuming that in scenario that you have malformed byte(s) in your input bytes during String.toCharAray()/getBytes() coding, the performance probably is no longer your top priority. That said, you do have the point, we should do better even in malformed case, to wrap the input bytes every time there is a malformed byte is definitely not preferred. The webrev has been updated to "cache" a ByteBuffer wrapper object for each round of decode/encode() operation, when necessary (means if a malformed detected). http://cr.openjdk.java.net/~sherman/7040220/webrev (the previous one is at http://cr.openjdk.java.net/~sherman/7040220/webrev.00) Thanks, -Sherman > > > > Am 28.04.2011 08:34, schrieb Xueming Shen: >> Hi >> >> This is motivated by Neil's request to optimize common-case UTF8 path >> for native ZipFile.getEntry calls [1]. >> As I said in my replying email [2] I believe a better approach might >> be to "patch" UTF8 charset directly to >> implement sun.nio.cs.ArrayDecoder/Encoder interface to speed up the >> coding operation for array based >> encoding/decoding under certain circumstance, as we did for all >> single byte charsets in #6636323 [3]. I >> have a old blog [4] that has some data for this optimization. >> >> The original plan was to do the same thing for our new UTF8 [5] as >> well in JDK7, but then (excuse, excuse) >> I was just too busy to come back to this topic till 2 days ago. After >> two days of small tweaking here and there >> and testing those possible corner cases I can think of, I'm happy >> with the result and think it might be >> worth sending it out for a codereview for JDK7, knowing we only have >> couple days left. >> >> The webrev is at >> >> http://cr.openjdk.java.net/~sherman/7040220/webrev >> >> Those tests are supposed to make sure the coding result from the new >> paths for String.getBytes()/ >> toCharArray() matches the result from the existing implementation. >> >> The performance results of running StrCodingBenchmarkUTF8 (included >> in webrev) on my linux >> box in -client and -server mode respectively are included at >> >> http://cr.openjdk.java.net/~sherman/7040220/client >> http://cr.openjdk.java.net/~sherman/7040220/server >> >> The microbenchmark measures 1-byte, 2-byte, 3-byte and 4 bytes utf8 >> bits separately with different >> length of data (from 12 bytes to thousands) >> >> Thanks! >> -Sherman >> >> [1] >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-April/006710.html >> [2] >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-April/006726.html >> [3] http://cr.openjdk.java.net/~sherman/6636323_6636319/webrev >> [4] http://blogs.sun.com/xuemingshen/entry/faster_new_string_bytes_cs >> [5] http://blogs.sun.com/xuemingshen/entry/the_big_overhaul_of_java >> From Ulf.Zibis at gmx.de Thu Apr 28 20:55:41 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 28 Apr 2011 22:55:41 +0200 Subject: Codereview request: CR 7040220 java/char_encodin Optimize UTF-8 charset for String.getBytes()/toCharArray() In-Reply-To: <4DB9C672.1070306@oracle.com> References: <4DB90A73.5080602@oracle.com> <4DB96116.4050903@gmx.de> <4DB9C672.1070306@oracle.com> Message-ID: <4DB9D44D.2040109@gmx.de> Am 28.04.2011 21:56, schrieb Xueming Shen: > That said, you do have the point, we should do better even in > malformed case, ... Yes, that's what I wanted to point on. But I thought, you could go 1 step further, declaring bb as member of UTF_8.Decoder. Then it should be guaranteed, the a decoder is in use of only one thread at same time. Don't know if that is the case for the typical use cases? In http://cr.openjdk.java.net/~mduigou/4884238/2/webrev/ I've seen the change to use a constant Charset object instead of a constant charset name on some method calls. From your benchmark it seems, using constant charset names has some little performance gain (0..25 %) , so I don't see the benefit of the changes from 4884238 in contrary direction. -Ulf From xueming.shen at oracle.com Thu Apr 28 21:28:43 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 28 Apr 2011 14:28:43 -0700 Subject: Codereview request: CR 7040220 java/char_encodin Optimize UTF-8 charset for String.getBytes()/toCharArray() In-Reply-To: <4DB9D44D.2040109@gmx.de> References: <4DB90A73.5080602@oracle.com> <4DB96116.4050903@gmx.de> <4DB9C672.1070306@oracle.com> <4DB9D44D.2040109@gmx.de> Message-ID: <4DB9DC0B.2050108@oracle.com> On 04/28/2011 01:55 PM, Ulf Zibis wrote: > Am 28.04.2011 21:56, schrieb Xueming Shen: >> That said, you do have the point, we should do better even in >> malformed case, ... > Yes, that's what I wanted to point on. > But I thought, you could go 1 step further, declaring bb as member of > UTF_8.Decoder. Then it should be guaranteed, the a decoder is in use > of only one thread at same time. Don't know if that is the case for > the typical use cases? Why do you want to "re-use" a ByteBuffer object cross decode(byte[]...) invocations? I don't see any benefit of doing that. > In http://cr.openjdk.java.net/~mduigou/4884238/2/webrev/ I've seen the > change to use a constant Charset object instead of a constant charset > name on some method calls. From your benchmark it seems, using > constant charset names has some little performance gain (0..25 %) , so > I don't see the benefit of the changes from 4884238 in contrary > direction. > That is a totally different topic:-) Yes, you don't benefit from using a "Charset object" when do String.getBytes()/toCharArray() because of our caching optimization in StringCoding class. But that is a pure implementation detail. It's safe to say that java.nio.cs.StandardCharset is not for String.getBytes()/toCharArray() only, so the fact that "cs" variant of String.getBytes()/toCharArray() is "slower" than its "csn" variant arguably might not be a very strong/supportive material for that discussion:-) -Sherman > -Ulf > From jonathan.gibbons at oracle.com Thu Apr 28 22:06:33 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 28 Apr 2011 22:06:33 +0000 Subject: hg: jdk7/tl/langtools: 7029150: Project Coin: present union types from the tree API through to javax.lang.model Message-ID: <20110428220637.9E4F9470BE@hg.openjdk.java.net> Changeset: 7ae6c0fd479b Author: jjg Date: 2011-04-28 15:05 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/7ae6c0fd479b 7029150: Project Coin: present union types from the tree API through to javax.lang.model Reviewed-by: mcimadamore ! src/share/classes/com/sun/source/util/Trees.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/model/JavacTypes.java ! test/tools/javac/multicatch/model/Model01.java ! test/tools/javac/multicatch/model/ModelChecker.java + test/tools/javac/multicatch/model/UnionTypeInfo.java + test/tools/javac/processing/model/type/TestUnionType.java From Ulf.Zibis at gmx.de Thu Apr 28 22:46:41 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 29 Apr 2011 00:46:41 +0200 Subject: Codereview request: CR 7040220 java/char_encodin Optimize UTF-8 charset for String.getBytes()/toCharArray() In-Reply-To: <4DB9DC0B.2050108@oracle.com> References: <4DB90A73.5080602@oracle.com> <4DB96116.4050903@gmx.de> <4DB9C672.1070306@oracle.com> <4DB9D44D.2040109@gmx.de> <4DB9DC0B.2050108@oracle.com> Message-ID: <4DB9EE51.6050502@gmx.de> Am 28.04.2011 23:28, schrieb Xueming Shen: > On 04/28/2011 01:55 PM, Ulf Zibis wrote: >> Am 28.04.2011 21:56, schrieb Xueming Shen: >>> That said, you do have the point, we should do better even in >>> malformed case, ... >> Yes, that's what I wanted to point on. >> But I thought, you could go 1 step further, declaring bb as member of UTF_8.Decoder. Then it >> should be guaranteed, the a decoder is in use of only one thread at same time. Don't know if that >> is the case for the typical use cases? > > Why do you want to "re-use" a ByteBuffer object cross decode(byte[]...) invocations? > I don't see any benefit of doing that. Thinking again, I see my error. It's not re-usable, because it's size is always different, so question about the benefit seems obsolete. The benefit could have been: If the strings are kinda short, AND malformed case is kinda frequent, newly instantiations of ByteBuffers could decrease the overall performance in some percentage. > >> In http://cr.openjdk.java.net/~mduigou/4884238/2/webrev/ I've seen the change to use a constant >> Charset object instead of a constant charset name on some method calls. From your benchmark it >> seems, using constant charset names has some little performance gain (0..25 %) , so I don't see >> the benefit of the changes from 4884238 in contrary direction. >> > > That is a totally different topic:-) > > Yes, you don't benefit from using a "Charset object" when do String.getBytes()/toCharArray() > because of our caching optimization in StringCoding class. But that is a pure implementation > detail. I think, this fact should be mentioned in the javadoc of String.getBytes() etc. I guess, standard programmer would estimate the StandardCharset.UTF_8 version faster than the csn version. > It's safe to say that java.nio.cs.StandardCharset is not for String.getBytes()/toCharArray() > only, so the fact that "cs" variant of String.getBytes()/toCharArray() is "slower" than its "csn" > variant arguably might not be a very strong/supportive material for that discussion:-) So what prevents us from the same caching optimization in ZipCoder etc. class ? - ZipCoder.isutf8 is unreadeable. Better: isUTF8 - ArrayDecoder.decode(ba, 0, length, ca) could throw MalformedInput/UnmappableCharacterException instead returning -1. Benefits: -- prevent from translating -1 to IllegalArgumentException("MALFORMED") in ZipCoder etc. -- more precise exception -Ulf From Ulf.Zibis at gmx.de Thu Apr 28 22:48:41 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 29 Apr 2011 00:48:41 +0200 Subject: hg: jdk7/tl/jdk: 2 new changesets In-Reply-To: <9A3BFB0C-22CC-45A0-82E0-05F09BF2D17B@oracle.com> References: <20110427211930.A90834705F@hg.openjdk.java.net> <4DB9A09E.7000400@gmx.de> <9A3BFB0C-22CC-45A0-82E0-05F09BF2D17B@oracle.com> Message-ID: <4DB9EEC9.3070008@gmx.de> Thanks for the feedback. (but still waiting for the other one about static methods) -Ulf Am 28.04.2011 19:38, schrieb Mike Duigou: > Essentially we ran out of time for this task and were confident enough in out decision about the design and choice of names to go ahead. More discussion didn't seem to be leading anywhere but inaction and there are other issues (always) that need attention. > > Mike > > > On Apr 28 2011, at 10:15 , Ulf Zibis wrote: > >> Hey Mike, >> >> why didn't you follow Mark's explanation about the naming for StandardCharset(s) ? >> >> Did you have had other discussions internally? >> >> -Ulf >> >> >> Am 27.04.2011 23:18, schrieb mike.duigou at oracle.com: >>> Changeset: 5b05f8d1c0e5 >>> Author: mduigou >>> Date: 2011-04-26 14:25 -0700 >>> URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5b05f8d1c0e5 >>> >>> 4884238: Adds java.nio.charset.StandardCharset to provide static final constants for the standard charsets. >>> Reviewed-by: alanb, sherman, darcy >>> >>> ! src/share/classes/java/nio/charset/Charset.java >>> + src/share/classes/java/nio/charset/StandardCharset.java >>> ! src/share/classes/java/nio/file/Path.java >>> ! src/share/classes/java/util/zip/ZipCoder.java >>> ! src/share/classes/java/util/zip/ZipFile.java >>> ! src/share/classes/java/util/zip/ZipInputStream.java >>> ! src/share/classes/java/util/zip/ZipOutputStream.java >>> ! src/share/classes/sun/awt/FontDescriptor.java >>> + test/java/nio/charset/StandardCharset/Standard.java >>> >>> Changeset: bf2a12c1ffe3 >>> Author: mduigou >>> Date: 2011-04-27 14:18 -0700 >>> URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bf2a12c1ffe3 >>> >>> Merge >>> >>> >>> > From mandy.chung at oracle.com Thu Apr 28 22:58:54 2011 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 28 Apr 2011 15:58:54 -0700 Subject: Review request 7039809: "Remove @ConstructorProperties annotation from java.io.File class" Message-ID: <4DB9F12E.2020802@oracle.com> Sergey, Alan, Can you review the fix for: 7039809: "Remove @ConstructorProperties annotation from java.io.File class" Webrev at: http://cr.openjdk.java.net/~mchung/jdk7/7039809/webrev.00/ This is essentially backing out this changeset: http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/ec9c8e73ae53 Background: java.io.File is annotated with java.beans.ConstructorProperties in JDK 7 (6708550). This introduces a undesirable dependency to the base module (where java.io.File class is). The base module cannot depend on any other module. Unless java.beans.ConstructorProperties is included in the base module and splitting java.beans package across the base module and the client module, such dependency has to be eliminated. As multi-module packages (aka split packages) is currently an open requirement to the Java module system, it's agreed to back out the fix for 6708550 in JDK 7 and defer it to JDK 8 when it'll determine if the multi-module package will be supported. Thanks Mandy From vincent.x.ryan at oracle.com Thu Apr 28 23:22:23 2011 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Thu, 28 Apr 2011 23:22:23 +0000 Subject: hg: jdk7/tl/jdk: 6578658: Request for raw RSA (NONEwithRSA) Signature support in SunMSCAPI Message-ID: <20110428232243.84AB8470C4@hg.openjdk.java.net> Changeset: 67f411052dd6 Author: vinnie Date: 2011-04-29 00:21 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/67f411052dd6 6578658: Request for raw RSA (NONEwithRSA) Signature support in SunMSCAPI Reviewed-by: wetmore ! src/windows/classes/sun/security/mscapi/RSASignature.java ! src/windows/classes/sun/security/mscapi/SunMSCAPI.java ! src/windows/native/sun/security/mscapi/security.cpp + test/sun/security/mscapi/SignUsingNONEwithRSA.java + test/sun/security/mscapi/SignUsingNONEwithRSA.sh From xueming.shen at oracle.com Fri Apr 29 00:11:41 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 28 Apr 2011 17:11:41 -0700 Subject: Codereview request: CR 7040220 java/char_encodin Optimize UTF-8 charset for String.getBytes()/toCharArray() In-Reply-To: <4DB9EE51.6050502@gmx.de> References: <4DB90A73.5080602@oracle.com> <4DB96116.4050903@gmx.de> <4DB9C672.1070306@oracle.com> <4DB9D44D.2040109@gmx.de> <4DB9DC0B.2050108@oracle.com> <4DB9EE51.6050502@gmx.de> Message-ID: <4DBA023D.5090701@oracle.com> On 04-28-2011 3:46 PM, Ulf Zibis wrote: > >> It's safe to say that java.nio.cs.StandardCharset is not for >> String.getBytes()/toCharArray() >> only, so the fact that "cs" variant of >> String.getBytes()/toCharArray() is "slower" than its "csn" >> variant arguably might not be a very strong/supportive material for >> that discussion:-) > So what prevents us from the same caching optimization in ZipCoder > etc. class ? > What do you want to cache in ZipCoder? Each ZipFile object holds one ZipCoder object and uses it for its coding need through its lifetime. And ZipCoder does "remember" its de/encoder. > > - ZipCoder.isutf8 is unreadeable. Better: isUTF8 > Updated to isUTF8 as suggested. > - ArrayDecoder.decode(ba, 0, length, ca) could throw > MalformedInput/UnmappableCharacterException instead returning -1. > Benefits: > -- prevent from translating -1 to > IllegalArgumentException("MALFORMED") in ZipCoder etc. > -- more precise exception > Something we might consider to do in jdk8 or jdk7 updates. But for now I don't want to change ArrayDecoder/Encoder interface at this stage, otherwise I will have to touch those SingleByte charsets and the StringCoding class as well, those SingleByte charsets now only handle/assume "replace" action and the StringCoding does not expect MalformedInput or UnmappableCharacterException. -Sherman > > -Ulf > From joe.darcy at oracle.com Fri Apr 29 00:45:51 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 29 Apr 2011 00:45:51 +0000 Subject: hg: jdk7/tl/jdk: 7038843: IIOP serialization fails with NullPointerException when serializing Throwable Message-ID: <20110429004601.3090A470C8@hg.openjdk.java.net> Changeset: 6c8ae62463a3 Author: darcy Date: 2011-04-28 17:51 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6c8ae62463a3 7038843: IIOP serialization fails with NullPointerException when serializing Throwable Reviewed-by: dholmes, mchung ! src/share/classes/java/lang/Throwable.java From stuart.marks at oracle.com Fri Apr 29 03:52:24 2011 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 28 Apr 2011 20:52:24 -0700 Subject: Review request the fix for CR 7040150 In-Reply-To: References: Message-ID: <4DBA35F8.4040100@oracle.com> On 4/28/11 11:13 AM, Lance Andersen - Oracle wrote: > Hi all, > > I could use a reviewer for 7040150 which addresses a positioning issue with CacheResultSetImpl.removeCurrentRow(). > > The diff is located at: > > http://cr.openjdk.java.net/~lancea/7040150/webrev.00/ The change in the index value looks correct. It's hard to say, but it looks like removeCurrentRow() doesn't throw SQLException if the cursor is on the insert row. In that case, it might throw ClassCastException when the InsertRow is cast to Row. Also, if the cursor is before the first row, it might throw ArrayIndexOutOfBoundsException. Then again, it says "this is a implementation only method" [sic] as opposed to a public method, so it's hard to say whether it needs to handle all these cases, as they might not actually arise in practice. I guess if the change is sufficient to fix the customer's problem, then go ahead with it. s'marks From xueming.shen at oracle.com Fri Apr 29 03:53:29 2011 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Fri, 29 Apr 2011 03:53:29 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20110429035357.BCDBB470D1@hg.openjdk.java.net> Changeset: 775b77e74bec Author: sherman Date: 2011-04-28 20:18 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/775b77e74bec 7037261: j.l.Character.isLowerCase/isUpperCase need to match the Unicode Standard Summary: updated j.l.c.lsLowerCase/isUpperCase Reviewed-by: okutsu ! make/java/java/FILES_java.gmk ! make/java/java/Makefile ! make/tools/GenerateCharacter/CharacterData00.java.template ! make/tools/GenerateCharacter/CharacterData01.java.template ! make/tools/GenerateCharacter/CharacterData02.java.template ! make/tools/GenerateCharacter/CharacterData0E.java.template ! make/tools/GenerateCharacter/CharacterDataLatin1.java.template + make/tools/UnicodeData/PropList.txt ! make/tools/src/build/tools/generatecharacter/GenerateCharacter.java + make/tools/src/build/tools/generatecharacter/PropList.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/CharacterData.java + test/java/lang/Character/CheckProp.java + test/java/lang/Character/PropList.txt Changeset: 94d02b3c5ac4 Author: sherman Date: 2011-04-28 20:48 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/94d02b3c5ac4 7039066: j.u.rgex does not match TR18 RL1.4 Simple Word Boundaries and RL1.2 Properties Summary: updated the regex Unicode property support Reviewed-by: alanb ! src/share/classes/java/util/regex/Pattern.java + src/share/classes/java/util/regex/UnicodeProp.java + test/java/util/regex/POSIX_ASCII.java + test/java/util/regex/POSIX_Unicode.java ! test/java/util/regex/RegExTest.java From Alan.Bateman at oracle.com Fri Apr 29 06:10:35 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 29 Apr 2011 07:10:35 +0100 Subject: Review request 7039809: "Remove @ConstructorProperties annotation from java.io.File class" In-Reply-To: <4DB9F12E.2020802@oracle.com> References: <4DB9F12E.2020802@oracle.com> Message-ID: <4DBA565B.2050400@oracle.com> Mandy Chung wrote: > Sergey, Alan, > > Can you review the fix for: > 7039809: "Remove @ConstructorProperties annotation from > java.io.File class" > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk7/7039809/webrev.00/ Looks good to me. -Alan. From Lance.Andersen at oracle.com Fri Apr 29 12:39:17 2011 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Fri, 29 Apr 2011 08:39:17 -0400 Subject: Review request the fix for CR 7040150 In-Reply-To: <4DBA35F8.4040100@oracle.com> References: <4DBA35F8.4040100@oracle.com> Message-ID: <8C95A759-9C41-4B52-9D45-B074DC1774E9@oracle.com> On Apr 28, 2011, at 11:52 PM, Stuart Marks wrote: > On 4/28/11 11:13 AM, Lance Andersen - Oracle wrote: >> Hi all, >> >> I could use a reviewer for 7040150 which addresses a positioning issue with CacheResultSetImpl.removeCurrentRow(). >> >> The diff is located at: >> >> http://cr.openjdk.java.net/~lancea/7040150/webrev.00/ > > The change in the index value looks correct. > > It's hard to say, but it looks like removeCurrentRow() doesn't throw SQLException if the cursor is on the insert row. In that case, it might throw ClassCastException when the InsertRow is cast to Row. Also, if the cursor is before the first row, it might throw ArrayIndexOutOfBoundsException. > > Then again, it says "this is a implementation only method" [sic] as opposed to a public method, so it's hard to say whether it needs to handle all these cases, as they might not actually arise in practice. I guess if the change is sufficient to fix the customer's problem, then go ahead with it. Thanks Stuart. This method is only called by setOriginalRow which does check for insertRow. It does address the customer issue and allows the TCK to continue to pass. Best Regards, Lance > > s'marks Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From lance.andersen at oracle.com Fri Apr 29 13:04:43 2011 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Fri, 29 Apr 2011 13:04:43 +0000 Subject: hg: jdk7/tl/jdk: 7040150: Indexing Error in CachedRowSetImpl.removeCurrentRow Message-ID: <20110429130510.A740B470EC@hg.openjdk.java.net> Changeset: 0b1354ecf5a3 Author: lancea Date: 2011-04-29 09:04 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0b1354ecf5a3 7040150: Indexing Error in CachedRowSetImpl.removeCurrentRow Reviewed-by: smarks ! src/share/classes/com/sun/rowset/CachedRowSetImpl.java From mandy.chung at oracle.com Fri Apr 29 15:51:50 2011 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 29 Apr 2011 15:51:50 +0000 Subject: hg: jdk7/tl/jdk: 7039809: Remove @ConstructorProperties annotation from java.io.File class Message-ID: <20110429155208.F40A2470F5@hg.openjdk.java.net> Changeset: 24ad188dc46c Author: mchung Date: 2011-04-29 08:51 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/24ad188dc46c 7039809: Remove @ConstructorProperties annotation from java.io.File class Reviewed-by: alanb, malenkov ! src/share/classes/java/io/File.java - test/java/beans/XMLEncoder/java_io_File.java From maurizio.cimadamore at oracle.com Fri Apr 29 15:11:35 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 29 Apr 2011 15:11:35 +0000 Subject: hg: jdk7/tl/langtools: 4 new changesets Message-ID: <20110429151145.E97A0470F1@hg.openjdk.java.net> Changeset: 4c03383f6529 Author: mcimadamore Date: 2011-04-29 16:05 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/4c03383f6529 7040104: javac NPE on Object a[]; Object o = (a=null)[0]; Summary: When a null literal is found on top of stack, if expected type is 1-dimension array no checkcast is emitted Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/jvm/Code.java + test/tools/javac/T7040104.java Changeset: 9a847a77205d Author: mcimadamore Date: 2011-04-29 16:05 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/9a847a77205d 7039937: Improved catch analysis fails to handle a common idiom in the libraries Summary: Disable generation of 'unreachable catch' warnings for catch statements catching Exception/Throwable Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! test/tools/javac/6558548/T6558548.java ! test/tools/javac/6558548/T6558548_6.out ! test/tools/javac/6558548/T6558548_latest.out ! test/tools/javac/diags/examples/UnreachableCatch1.java Changeset: 1092b67b3cad Author: mcimadamore Date: 2011-04-29 16:05 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/1092b67b3cad 7034495: Javac asserts on usage of wildcards in bounds Summary: Problem with intersection types and wildcards causing javac to crash Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/generics/wildcards/7034495/T7034495.java + test/tools/javac/generics/wildcards/7034495/T7034495.out Changeset: dc3d9ef880a1 Author: mcimadamore Date: 2011-04-29 16:06 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/dc3d9ef880a1 6550655: com.sun.tools.javac.code.Symbol$CompletionFailure Summary: Accessing a non-existing enum constant from an annotation whose class is available results in an internal error Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/annotations/6550655/T6550655.java ! test/tools/javac/diags/examples.not-yet.txt From neil.richards at ngmr.net Fri Apr 29 16:47:29 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Fri, 29 Apr 2011 17:47:29 +0100 Subject: Codereview request: CR 7040220 java/char_encodin Optimize UTF-8 charset for String.getBytes()/toCharArray() In-Reply-To: <4DB9490D.40105@oracle.com> References: <4DB90A73.5080602@oracle.com> <4DB9490D.40105@oracle.com> Message-ID: On 28 April 2011 12:01, Alan Bateman wrote: > I skimmed through the webrev and I agree this is a better approach. I will > try to do a detailed review before Monday. It would be great if others on > the list could jump in and help too as we are running out of time. > > Neil - I don't know if you've had a chance to look at Sherman's changes but > I think it's better than checking if mUTF-8 can be used. ?If you agree then > would you have time to run your tests that altered you to this performance > regression? There's a patch file in the webrev. Hi Sherman, Thank you for responding so quickly to my post. I realise that my suggested change was quite restricted in its scope - it was designed so it could be considered easily (in the hope it might make it through the OpenJDK 7 gates before they finally clang shut). However, it's evident from your response that you have been thinking about possible enhancements in this area, and I agree that your proposed change addresses the issue in a more comprehensive - and strategic - manner. >From the testing I've been able to look at thus far, your proposed change seems to address the performance penalty which had caused me to raise the matter. Given this, I'd be delighted if it is adopted into OpenJDK 7, Thanks once again, Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From kelly.ohair at oracle.com Fri Apr 29 17:58:33 2011 From: kelly.ohair at oracle.com (kelly.ohair at oracle.com) Date: Fri, 29 Apr 2011 17:58:33 +0000 Subject: hg: jdk7/tl/jaxp: 7040147: jaxp 1.4.5 jdk7 integration Message-ID: <20110429175834.0BDC5470FD@hg.openjdk.java.net> Changeset: 30129a58aacc Author: ohair Date: 2011-04-29 10:58 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/30129a58aacc 7040147: jaxp 1.4.5 jdk7 integration Reviewed-by: joehw ! jaxp.properties From valerie.peng at oracle.com Fri Apr 29 20:48:46 2011 From: valerie.peng at oracle.com (valerie.peng at oracle.com) Date: Fri, 29 Apr 2011 20:48:46 +0000 Subject: hg: jdk7/tl/jdk: 7036252: sunpkcs11-solaris.cfg needs a review Message-ID: <20110429204855.E3C514710F@hg.openjdk.java.net> Changeset: 40e2b3a25533 Author: valeriep Date: 2011-04-29 13:31 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/40e2b3a25533 7036252: sunpkcs11-solaris.cfg needs a review Summary: Updated the disabled mechanisms section since Solaris bug 6306708 has been fixed. Reviewed-by: mullan ! src/share/lib/security/sunpkcs11-solaris.cfg From mike.duigou at oracle.com Fri Apr 29 21:19:25 2011 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Fri, 29 Apr 2011 21:19:25 +0000 Subject: hg: jdk7/tl/jdk: 7040572: Fix broken java/nio/charset/StandardCharset/Standard.java and add more tests. Message-ID: <20110429211934.BBF5547111@hg.openjdk.java.net> Changeset: 36dd30b5f85d Author: mduigou Date: 2011-04-29 14:09 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/36dd30b5f85d 7040572: Fix broken java/nio/charset/StandardCharset/Standard.java and add more tests. Reviewed-by: alanb ! test/java/nio/charset/StandardCharset/Standard.java From maurizio.cimadamore at oracle.com Sat Apr 30 10:59:51 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Sat, 30 Apr 2011 10:59:51 +0000 Subject: hg: jdk7/tl/langtools: 7039931: Project Coin: diamond inference fail with generic constructor explicit type-arguments Message-ID: <20110430105953.3E47347142@hg.openjdk.java.net> Changeset: 4caf17560ae0 Author: mcimadamore Date: 2011-04-30 11:57 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/4caf17560ae0 7039931: Project Coin: diamond inference fail with generic constructor explicit type-arguments Summary: diamond should be disallowed in cases where explicit generic constructor parameters are specified Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/DiamondAndExplicitParams.java ! test/tools/javac/generics/diamond/7030150/GenericConstructorAndDiamondTest.java - test/tools/javac/generics/diamond/7030150/Neg01.java - test/tools/javac/generics/diamond/7030150/Neg01.out - test/tools/javac/generics/diamond/7030150/Neg02.java - test/tools/javac/generics/diamond/7030150/Neg02.out - test/tools/javac/generics/diamond/7030150/Neg03.java - test/tools/javac/generics/diamond/7030150/Neg03.out - test/tools/javac/generics/diamond/7030150/Pos01.java - test/tools/javac/generics/diamond/7030150/Pos02.java From Ulf.Zibis at gmx.de Sat Apr 30 17:24:38 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 30 Apr 2011 19:24:38 +0200 Subject: Codereview request: CR 7040220 java/char_encodin Optimize UTF-8 charset for String.getBytes()/toCharArray() In-Reply-To: <4DBA023D.5090701@oracle.com> References: <4DB90A73.5080602@oracle.com> <4DB96116.4050903@gmx.de> <4DB9C672.1070306@oracle.com> <4DB9D44D.2040109@gmx.de> <4DB9DC0B.2050108@oracle.com> <4DB9EE51.6050502@gmx.de> <4DBA023D.5090701@oracle.com> Message-ID: <4DBC45D6.30605@gmx.de> Am 29.04.2011 02:11, schrieb Xueming Shen: > On 04-28-2011 3:46 PM, Ulf Zibis wrote: >> >>> It's safe to say that java.nio.cs.StandardCharset is not for String.getBytes()/toCharArray() >>> only, so the fact that "cs" variant of String.getBytes()/toCharArray() is "slower" than its "csn" >>> variant arguably might not be a very strong/supportive material for that discussion:-) >> So what prevents us from the same caching optimization in ZipCoder etc. class ? >> > > What do you want to cache in ZipCoder? Each ZipFile object holds one ZipCoder object and > uses it for its coding need through its lifetime. And ZipCoder does "remember" its de/encoder. I see! Yes, caching it for consecutive ZipFiles would be too much overhead compared to the "heavy" other work of each ZipFile. Thanks for the discussion, -Ulf