hg: jdk7/tl/jdk: 7035834: Bad @param tags in LayerUI.java
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
Re: Review request for removal of unchecked lint warnings in javax.sql.rowset, CR 7035615
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.
Re: Review request for removal of unchecked lint warnings in javax.sql.rowset, CR 7035615
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.ander...@oracle.com
hg: jdk7/tl/jdk: 6882437: CertPath/X509CertPathDiscovery/Test fails on jdk7/pit/b62
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
hg: jdk7/tl/jdk: 7035615: Address lint warnings for javax.sql.rowset com.sun.rowset
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
Re: Constants for standard charsets -- CR #4884238
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
Quick code review to address a couple typos in the javadoc for ResultSet, CR 7007772
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. * * PThe number, types and properties of a codeResultSet/code - * object's columns are provided by the codeResulSetMetaData/code + * object's columns are provided by the codeResultSetMetaData/code * object returned by the codeResultSet.getMetaData/code method. * * @see Statement#executeQuery @@ -422,7 +422,7 @@ * of this codeResultSet/code 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 charLONGVARCHAR/char values. + * suitable for retrieving large codeLONGVARCHAR/code 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.ander...@oracle.com
Re: Quick code review to address a couple typos in the javadoc for ResultSet, CR 7007772
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. * *PThe number, types and properties of acodeResultSet/code - * object's columns are provided by thecodeResulSetMetaData/code + * object's columns are provided by thecodeResultSetMetaData/code * object returned by thecodeResultSet.getMetaData/code method. * * @see Statement#executeQuery @@ -422,7 +422,7 @@ * of thiscodeResultSet/code 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 largecharLONGVARCHAR/char values. + * suitable for retrieving largecodeLONGVARCHAR/code 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.ander...@oracle.com
Re: Constants for standard charsets -- CR #4884238
On Apr 12 2011, at 11:11 , mark.reinh...@oracle.com wrote: 2011/4/12 10:38 -0700, mike.dui...@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
hg: jdk7/tl/jdk: 7007772: Address typos in javadoc for ResultSet
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
Re: Constants for standard charsets -- CR #4884238
Am 12.04.2011 20:27, schrieb Mike Duigou: On Apr 12 2011, at 11:11 , mark.reinh...@oracle.com wrote: 2011/4/12 10:38 -0700, mike.dui...@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* https://bugs.openjdk.java.net/show_bug.cgi?id=100091 - No system start for file.encoding=x-SJIS_0213 *Bug 100092* https://bugs.openjdk.java.net/show_bug.cgi?id=100092 - Speed-up FastCharsetProvider *Bug 100095* https://bugs.openjdk.java.net/show_bug.cgi?id=100095 - Avoid 2-step lookup in sun.nio.cs charset providers *Bug 100098* https://bugs.openjdk.java.net/show_bug.cgi?id=100098 - Make sun.nio.cs.* charset objects light-weight ** -Ulf
Re: Suspected regression: fix for 6735255 causes delay in GC of ZipFile InputStreams, increase in heap demand
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
Re: Constants for standard charsets -- CR #4884238
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
hg: jdk7/tl/jdk: 7035555: 4/4 attach/BasicTests.sh needs another tweak for Cygwin
Changeset: 59b2b9a34b3c Author:dcubed Date: 2011-04-12 13:36 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/59b2b9a34b3c 703: 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
Heads up, new jaxws source drop bundle
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
hg: jdk7/tl/jaxws: 7034918: Integrate JAX-WS 2.2.4-b01 in to JDK 7
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
Re: Constants for standard charsets -- CR #4884238
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
Re: advice review requested for 6896297, race condition in rmid causing JCK failure
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
Re: Constants for standard charsets -- CR #4884238
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* https://bugs.openjdk.java.net/show_bug.cgi?id=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
Fwd: [concurrency-interest] ConcurrentHashMap footprint and contention improvements
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 d...@cs.oswego.edu To: concurrency-inter...@cs.oswego.edu concurrency-inter...@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-inter...@cs.oswego.edu http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Re: proposal to optimise the performance of the Jar utility
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 xueming.s...@oracle.com To: core-libs-dev@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.ske...@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.1one 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.2one 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.3one 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
hg: jdk7/tl/jdk: 2 new changesets
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
hg: jdk7/tl/jdk: 7026304: Fork-Join sample
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
Re: i18n dev Codereview request for 7033561: Missing Unicode Script aliases
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.
Re: Need reviewers: Update of jaxp 1.4.5 source drop bundle
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 dalibor.to...@oracle.com 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
hg: jdk7/tl/langtools: 2 new changesets
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
