From Ulf.Zibis at gmx.de Mon Mar 2 07:16:05 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 02 Mar 2009 08:16:05 +0100 Subject: How to get FileChannel from resource Message-ID: <49AB87B5.3090804@gmx.de> Hi all there is a { URL getResource(String name) } in class Class. Does anybody know, how to get a java.nio.channels.Channel or FileChannel from this URL? Thanks in advance, -Ulf From Xueming.Shen at Sun.COM Mon Mar 2 07:50:26 2009 From: Xueming.Shen at Sun.COM (Xueming Shen) Date: Sun, 01 Mar 2009 23:50:26 -0800 Subject: How to get FileChannel from resource In-Reply-To: <49AB87B5.3090804@gmx.de> References: <49AB87B5.3090804@gmx.de> Message-ID: <49AB8FC2.8090602@sun.com> You can use java.nio.channels.Channels.newChannel() to get a ReadableByteChannel on top of the InputStream you get from URL.openStream()... but if my guess of what you want to do is correct, that channel is probably not that useful:-) Sherman Ulf Zibis wrote: > Hi all > > there is a { URL getResource(String name) } in class Class. > Does anybody know, how to get a java.nio.channels.Channel or > FileChannel from this URL? > > Thanks in advance, > > -Ulf > > From Ulf.Zibis at gmx.de Mon Mar 2 12:15:30 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 02 Mar 2009 13:15:30 +0100 Subject: How to get FileChannel from resource In-Reply-To: <49AB8FC2.8090602@sun.com> References: <49AB87B5.3090804@gmx.de> <49AB8FC2.8090602@sun.com> Message-ID: <49ABCDE2.9010709@gmx.de> Sherman, yes, you are right. That's not what I'm looking for. This would be slower, than reading the stream directly, because the underlying byte array will be copied 2 times by BufferedInputStream# + Channels.ReadableByteChannelImpl#read(), ... but maybe not, because looping BufferedInputStream#readChar() could be slower than twice System.arraycopy(). Anyway, I'm looking for a DirectBuffer directly from a resource file. So I think there is something missing: URL.openChannel() or Class#getResourceAsChannel() Maybe there is a way to get a RamdomAccessFile from URL to get the Channel from. Anybody knows ? Should I file a bug ? Somebody any objections ? -Ulf Am 02.03.2009 08:50, Xueming Shen schrieb: > You can use java.nio.channels.Channels.newChannel() to get a > ReadableByteChannel on top of the > InputStream you get from URL.openStream()... > > but if my guess of what you want to do is correct, that channel is > probably not that useful:-) > > Sherman > > Ulf Zibis wrote: >> Hi all >> >> there is a { URL getResource(String name) } in class Class. >> Does anybody know, how to get a java.nio.channels.Channel or >> FileChannel from this URL? >> >> Thanks in advance, >> >> -Ulf >> >> > > From Thomas.Hawtin at Sun.COM Mon Mar 2 13:13:36 2009 From: Thomas.Hawtin at Sun.COM (Tom Hawtin) Date: Mon, 02 Mar 2009 13:13:36 +0000 Subject: How to get FileChannel from resource In-Reply-To: <49ABCDE2.9010709@gmx.de> References: <49AB87B5.3090804@gmx.de> <49AB8FC2.8090602@sun.com> <49ABCDE2.9010709@gmx.de> Message-ID: <49ABDB80.9050005@sun.com> Ulf Zibis wrote: > > Anyway, I'm looking for a DirectBuffer directly from a resource file. > So I think there is something missing: > URL.openChannel() or Class#getResourceAsChannel() > > Maybe there is a way to get a RamdomAccessFile from URL to get the > Channel from. Anybody knows ? If it's a file URL, then obviously you can check the protocol and create a `File` from the file portion. However most resources are not stored in naked files. For jared resources, you can cast the URLConnection to JarURLConnection and call getJarFile. Some implementations of JarURLConnection may not return a JarFile. Tom Hawtin From Alan.Bateman at Sun.COM Mon Mar 2 13:18:31 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Mon, 02 Mar 2009 13:18:31 +0000 Subject: How to get FileChannel from resource In-Reply-To: <49ABCDE2.9010709@gmx.de> References: <49AB87B5.3090804@gmx.de> <49AB8FC2.8090602@sun.com> <49ABCDE2.9010709@gmx.de> Message-ID: <49ABDCA7.5020202@sun.com> Ulf Zibis wrote: > Sherman, yes, you are right. That's not what I'm looking for. > > This would be slower, than reading the stream directly, because the > underlying byte array will be copied 2 times by > BufferedInputStream# + Channels.ReadableByteChannelImpl#read(), > ... but maybe not, because looping BufferedInputStream#readChar() > could be slower than twice System.arraycopy(). > > Anyway, I'm looking for a DirectBuffer directly from a resource file. > So I think there is something missing: > URL.openChannel() or Class#getResourceAsChannel() > > Maybe there is a way to get a RamdomAccessFile from URL to get the > Channel from. Anybody knows ? A URL just identifies an abstract resource so it may not support random access or other file-like operations you require. Have you thought about special handling for when the scheme is "file"? That way you can get the FileChannel you want for the typical case. -Alan From Ulf.Zibis at gmx.de Mon Mar 2 14:11:51 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 02 Mar 2009 15:11:51 +0100 Subject: How to get FileChannel from resource In-Reply-To: <49ABDB80.9050005@sun.com> References: <49AB87B5.3090804@gmx.de> <49AB8FC2.8090602@sun.com> <49ABCDE2.9010709@gmx.de> <49ABDB80.9050005@sun.com> Message-ID: <49ABE927.5070507@gmx.de> Am 02.03.2009 14:13, Tom Hawtin schrieb: > Ulf Zibis wrote: > >> >> Anyway, I'm looking for a DirectBuffer directly from a resource file. >> So I think there is something missing: >> URL.openChannel() or Class#getResourceAsChannel() >> >> Maybe there is a way to get a RamdomAccessFile from URL to get the >> Channel from. Anybody knows ? > > If it's a file URL, then obviously you can check the protocol and > create a `File` from the file portion. However most resources are not > stored in naked files. > > For jared resources, you can cast the URLConnection to > JarURLConnection and call getJarFile. Some implementations of > JarURLConnection may not return a JarFile. > > Tom Hawtin Tom, thanks for your hint. Ii unfortunately wouldn't help to solve my current problem, because JarFile either doesn't provide getChannel(). ... But it would help to simplify my other problem from thread: "How to get list of classes from a package" from 2009-02-16 Anyway, don't you think, there should be something like getResourceAsChannel() ? -Ulf From Ulf.Zibis at gmx.de Mon Mar 2 14:28:21 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 02 Mar 2009 15:28:21 +0100 Subject: How to get FileChannel from resource In-Reply-To: <49ABDCA7.5020202@sun.com> References: <49AB87B5.3090804@gmx.de> <49AB8FC2.8090602@sun.com> <49ABCDE2.9010709@gmx.de> <49ABDCA7.5020202@sun.com> Message-ID: <49ABED05.8080501@gmx.de> Am 02.03.2009 14:18, Alan Bateman schrieb: > Ulf Zibis wrote: >> Sherman, yes, you are right. That's not what I'm looking for. >> >> This would be slower, than reading the stream directly, because the >> underlying byte array will be copied 2 times by >> BufferedInputStream# + Channels.ReadableByteChannelImpl#read(), >> ... but maybe not, because looping BufferedInputStream#readChar() >> could be slower than twice System.arraycopy(). >> >> Anyway, I'm looking for a DirectBuffer directly from a resource file. >> So I think there is something missing: >> URL.openChannel() or Class#getResourceAsChannel() >> >> Maybe there is a way to get a RamdomAccessFile from URL to get the >> Channel from. Anybody knows ? > A URL just identifies an abstract resource so it may not support > random access or other file-like operations you require. Have you > thought about special handling for when the scheme is "file"? That way > you can get the FileChannel you want for the typical case. > > -Alan I thought about something like: FileChannel fc = new RandomAccessFile(getClass().getResource(name).toURI().getPath(), "r").getChannel(); ... but this doesn't work, if resource is packed in jar file. -Ulf From david.lloyd at redhat.com Mon Mar 2 15:25:42 2009 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 02 Mar 2009 09:25:42 -0600 Subject: [PATCH 0/2] Class- and class loader-local storage (Bug ID #6493635) In-Reply-To: References: <49A83957.3060102@redhat.com> <49A84292.1070207@redhat.com> <49A85188.5060903@redhat.com> <49A8574E.1020601@redhat.com> <49A869E5.9050102@redhat.com> Message-ID: <49ABFA76.1050407@redhat.com> On 02/27/2009 07:08 PM, Bob Lee wrote: > David, > > I regret making my suggestion in the first place. I really think we need > ephemerons, but for the sake of discussion: OK, so you say that you don't think this feature should exist, period, until and unless ephemerons are implemented. Why? There's a need for it. It does no harm. Once ephemerons are implemented (if they ever are), my solution can *easily* be ported to use them without any API changes from the user perspective. The difference is that I have a real solution, now, whereas ephemerons are vaporware, and will remain so for some unspecified amount of time. > - Your patch adds 2 new classes. My suggestion adds one method (maybe 2 > for convenience). Mmm, okay. I don't see this as an advantage or a disadvantage, just as a difference. > - Your approach enables explicit clearing, but I thought the whole point > of adding this extension was to avoid explicit clearing. If you're going > to explicitly clear, why do you need this functionality at all? If we > want to support circular dependencies between class loaders, we should > pursue ephemerons because your solution requires explicit clearing > whereas ephemerons would not. My solution supports implicit *and* explicit clearing (and so could/should your solution). As long as you have a strong reference to the key, the data will remain. If you lose the reference to the key, then the associated keys on all the maps become only weakly reachable. Alternately you can explicitly clear the reference, which allows one to keep the Class*Local in a static without fear of introducing leaks (if that is how one wishes to use it). > - Say for example that I need a static map from Class to List > (some filtered list of methods in Class). Your patch requires one > WeakHashMap per Class. My suggestion requires only one map total and one > lightweight data structure per ClassLoader. Right. The advantage to many hashmaps is a sort of implicitly striped access. No hashmap would exist until data is initially associated with a class. As I said in an earlier mail, disadvantage to a single, shared structure will ultimately be contention. And of course the hashmap is simply an implementation detail - any specifically identified problems with it can be overcome using an alternate implementation (have any ideas?). > - Your patch forces users to use your data structure. My suggestion > enables users to use whatever data structure they like. Your patch > introduces a point of contention between completely orthogonal > libraries. Mine introduces almost none (assuming you implement the > internal data structure in a non-locking fashion). Now this is untrue. My patch allows users to associate a piece of data (any object really) with a class. Functionally there's little difference. With my code: public final ClassLocal fooHolder; ...in a method... fooHolder.set(someClass, someData); ...manually clear reference... fooHolder.clear(); With your suggestion (assuming you return a reference): public final Set> refHolders; ...in a method... refHolders.add(someClass.getClassLoader().addReferenceTo(someData)); ...manually clear references... refHolders.clear(); // assuming that's what this would do In fact, I think my solution is far more intuitive to the end-user. It's a nicer API, certainly more in line with what is in the JDK today (think ThreadLocals, *References, etc.). And there need not be one single point of contention; it's more of a striped affair as long as you are storing data on classes (the only reason one exists is due to the naive implementation I chose - one could use a better hashmap (there is at least one lock-free implementation that I know of)). - DML From xuelei.fan at sun.com Mon Mar 2 15:25:53 2009 From: xuelei.fan at sun.com (xuelei.fan at sun.com) Date: Mon, 02 Mar 2009 15:25:53 +0000 Subject: hg: jdk7/tl/jdk: 6549506: Specification of Permission.toString() method contradicts with JDK implementation Message-ID: <20090302152619.ADBAEE597@hg.openjdk.java.net> Changeset: b656e842e1be Author: xuelei Date: 2009-03-02 23:17 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b656e842e1be 6549506: Specification of Permission.toString() method contradicts with JDK implementation Summary: update the spec, and add double quotes around component. Reviewed-by: weijun ! src/share/classes/java/security/Permission.java + test/java/security/Permission/ToString.java From kevinb at google.com Mon Mar 2 23:49:55 2009 From: kevinb at google.com (Kevin Bourrillion) Date: Mon, 2 Mar 2009 15:49:55 -0800 Subject: Fix for 5015163, and my first webrev In-Reply-To: <498CDD73.7080803@univ-mlv.fr> References: <498CA4CE.1090207@univ-mlv.fr> <108fcdeb0902061503j626b4727y520afe683b43f184@mail.gmail.com> <498CDD73.7080803@univ-mlv.fr> Message-ID: <108fcdeb0903021549l309d9fc5w9aa3d47c4b3abecf@mail.gmail.com> Bumping this thread. From the peanut gallery, I believe that R?mi's change is extremely worthy. I have more nitpicking I'd like to do on it, but am holding off until we learn whether Sun would accept it in any shape. At this point, it's still very mysterious to me how this will work (small, simple new APIs being added to core libraries via openjdk). On Fri, Feb 6, 2009 at 5:01 PM, R?mi Forax wrote: > Kevin Bourrillion a ?crit : > >> Hello, >> >> A few thoughts. >> >> First, this functionality is badly needed. Absolutely everyone >> rewrites this, in hundreds of different ways. At Google we're no >> exception, we have our own hand-rolled Join.java class full of static >> methods, and it has thousands of callers in our private codebase. >> >> Your selection of overloads (Iterable, Object[], and >> (Object,Object...)) is exactly correct. Kudos. We'd added Iterator >> versions as well, but almost no one uses them, so forget that. >> >> My main concerns with your current API are: >> >> * I don't think that ",".join(collection) is a good idea. It clashes >> too strongly with the StringBuilder etc. versions. It also plain >> "looks weird". A static String.join(",", collection) is preferable. >> I don't think anyone would be surprised by this. >> >> > Use the receiver or not: > Pro: > - join works with split and split use the receiver > - Python use the receiver too > > Cons: > - static seems least surprising. > - Perl's join and PHP's join are functions > > I'm convinced, I will modify the patch. > > * It should be considered separately whether to support other >> Appendables via static methods (somewhere) like: >> >> static A join(A appendable, String delimiter, >> Iterable tokens) throws IOException >> >> This provides a superset of what your StringBuilder etc. methods can >> do, but your methods are still good because of their convenience >> especially in chains of method calls, and because they don't need to >> throw any exception. >> >> > Or perhaps, in JDK8 (when closure will be integrated) the compiler will > be able to infer that because join is used with String, it can't throw an > IOE > That's not what BGGA propose but I will love to see that :) > But that's another story. > >> * The biggest problem we've had with our Join class is that it turns >> out that everyone has a different idea of how they'd like nulls >> handled. >> >> - output as "null" (your, and our, current behavior) >> - skip? >> - skip only if trailing? >> - throw NPE? (often the best thing) >> >> > > In my opinion (i am perhaps wong) join will be mostly used > just before print the String. That's why I have chosen the the print(ln) > behavior. > > > We now support everyone by having the concept of an instantiable >> Joiner (I've seen this in other languages). Example: >> >> private static final Joiner JOINER = Joiner.with(", ").skipNulls(); >> . . . >> >> return JOINER.join("Harry", "Ron", "Hermione"); >> >> Just to give everyone food for thought, our Joiner's API currently >> looks like this: >> >> static Joiner with(String separator) >> >> Joiner skipNulls() >> Joiner useForNull(String nullText) >> >> A appendTo(A appendable, Iterable parts) >> throws IOException >> A appendTo(A appendable, Object[] parts) >> throws IOException >> A appendTo(A appendable, Object first, >> Object... rest) throws IOException >> >> StringBuilder appendTo(StringBuilder builder, Iterable parts) >> StringBuilder appendTo(StringBuilder builder, Object[] parts) >> StringBuilder appendTo(StringBuilder builder, Object first, Object... >> rest) >> >> String join(Iterable parts) >> String join(Object[] parts) >> String join(Object first, Object... rest) >> >> MapJoiner withKeyValueSeparator(String keyValueSeparator) >> >> class MapJoiner { >> A appendTo(A appendable, Map map) >> throws IOException >> StringBuilder appendTo(StringBuilder builder, Map map) >> String join(Map map) >> >> MapJoiner useForNull(String nullText) >> } >> >> End of random thoughts. >> >> > > Cool, i don't think this should be integrated in the JDK, > After all, If i want a full featured joiner, I can download the google > collection jar :) > > >> -- >> Kevin Bourrillion @ Google >> internal: http://go/javalibraries >> google-collections.googlecode.com >> google-guice.googlecode.com >> >> > R?mi > -- Kevin Bourrillion @ Google internal: http://go/javalibraries google-collections.googlecode.com google-guice.googlecode.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From openjdk at crazybob.org Tue Mar 3 04:47:49 2009 From: openjdk at crazybob.org (Bob Lee) Date: Mon, 2 Mar 2009 20:47:49 -0800 Subject: [PATCH 0/2] Class- and class loader-local storage (Bug ID #6493635) In-Reply-To: <49ABFA76.1050407@redhat.com> References: <49A84292.1070207@redhat.com> <49A85188.5060903@redhat.com> <49A8574E.1020601@redhat.com> <49A869E5.9050102@redhat.com> <49ABFA76.1050407@redhat.com> Message-ID: David, Here's the problem I'd like to see solved: enable a library to hold an indirect reference to a Class without preventing that Class's loader from being reclaimed. The reclamation should happen automatically when the loader is not otherwise strongly referenced. You added a further requirement: the class-local value should not prevent the library's loader from being reclaimed. For example, if code loaded in a child class loader stores a value (which strongly references a Class in the child loader) in a Class from the parent loader, the class-local value in the parent-loaded Class should not prevent the child loader from being reclaimed. Your solution is to explicitly clear the class-local value (for every class regardless of its loader), but doesn't that fail to solve the original problem? If you're going to explicitly clear anyway, why do you need this mechanism in the first place? When I started this thread, I was content with solving the simpler case: a library loaded in the parent class loader associating data with classes loaded in a child loader. This is solvable at the library level and doesn't require explicit clearing. If I want a library loaded in the child class loader to store information about classes from the parent loader, I can just keep strong references to the Class objects because I know that the child loader will be reclaimed before the parent loader. Your problem can't be solved at the library level (without explicit clearing, which defeats the purpose of this construct). Ephemerons are the only viable solution that I know of. Bob -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lloyd at redhat.com Tue Mar 3 06:37:53 2009 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 03 Mar 2009 00:37:53 -0600 Subject: [PATCH 0/2] Class- and class loader-local storage (Bug ID #6493635) In-Reply-To: References: <49A84292.1070207@redhat.com> <49A85188.5060903@redhat.com> <49A8574E.1020601@redhat.com> <49A869E5.9050102@redhat.com> <49ABFA76.1050407@redhat.com> Message-ID: <49ACD041.1070909@redhat.com> On 03/02/2009 10:45 PM, Bob Lee wrote: > David, > > Here's the problem I'd like to see solved: enable a library to hold an > indirect reference to a Class without preventing that Class's loader > from being reclaimed. The reclamation should happen automatically when > the loader is not otherwise strongly referenced. With you so far. > You added a further requirement: the class-local value should not > prevent the library's loader from being reclaimed. For example, if code > loaded in a child class loader stores a value (which strongly references > a Class in the child loader) in a Class from the parent loader, the > class-local value in the parent-loaded Class should not prevent the > child loader from being reclaimed. That is a natural consequence of the key-value design, though not exactly in the way you describe. The child-classloader-value is obviously strongly reachable from the parent loader's "stash", so it's not immediately collectable until the key is collected. If one associates a key with an instance of the child class, then this automatic reclamation can happen automatically. If not, then there is no automatic solution possible, even with special VM ephemeron support (this basically IS an ephemeron implementation, after all, albeit a specialized one). > Your solution is to explicitly clear the class-local value (for every > class regardless of its loader), but doesn't that fail to solve the > original problem? If you're going to explicitly clear anyway, why do you > need this mechanism in the first place? No, it compliments the solution of the original problem. You're only going to explicitly clear if you want to remove the value *before* the classloader is reclaimed (the one upon which the value is stashed). Think of it as two ways to reclaim the data. The value (normally strongly referenced from the "stash") is unreferenced when either: 1) The classloader upon which it is stashed is no longer strongly reachable, or 2) The reference is explicitly cleared. The reason you need that ability to explicitly clear a reference is simple. Imagine you're using the bare mechanism you describe with a Map, ?> that has weak keys and weak values (relying on the reference-stashing to keep the strong value reference) in order to make a weak-key mapping. What if you want to change the map? Remove an entry or change its value? You can stash a reference to the new value object, but the old one is still there, forever (or at least until the classloader is collected, which for the system classloader, is essentially forever). It's a guaranteed memory leak. This is where removal comes into play. One very sweeping use case that fits this description involves frameworks which use runtime annotations, building up (possibly complex) object structures for each annotated class it encounters. In many cases, this data might need to be cached to avoid possibly expensive reconstructions of that object structure for each class, yet the framework cannot directly retain references to any single classloader using it - at least not without risking the dreaded PermGen memory leak when its consumers were redeployed. The nature of the basic implementation ensures that this won't happen. If for some reason circumstances change, and the cached data needs to be updated (say, perhaps, that some new information became available about a database or remote system or whatever, which relates specifically to whatever service that framework provides to that class), the framework is free to do so by manually clearing or updating the value of the reference. Now if that *framework* were to be undeployed, the application server will drop its strong reference to the object of the deployment, which in turn would typically lead to the key object becoming only weakly reachable. This will automatically remove all of the framework's stashed key/value pairs, and ultimately allow the framework's classloader to be collected. If that is *not* the case, and the reference situation is more complex, then one is still free to manually clear the key during the undeployment process. > When I started this thread, I was content with solving the simpler case: > a library loaded in the parent class loader associating data with > classes loaded in a child loader. This is solvable at the library level > and doesn't require explicit clearing. If I want a library loaded in the > child class loader to store information about classes from the parent > loader, I can just keep strong references to the Class objects because I > know that the child loader will be reclaimed before the parent loader. When would that situation actually arise, just out of curiosity? In terms of specific use case I mean. > Your problem can't be solved at the library level (without explicit > clearing, which defeats the purpose of this construct). Ephemerons are > the only viable solution that I know of. I think you're confusing the requirement for explicit clearing when the value changes or becomes obsolete with automatic collection of the keys. Implicitly clearing the value in this situation can *never* work - not with ephemerons, not without a psychic GC - because the application is always holding only a weak reference to the value *already*. The whole point was to add a strong reference to the value from the classloader; how can the GC determine when you don't need that particular value anymore? With my solution (and also with an ephemeron-based solution), as long as you hold a strong reference to the key, the value can exist. The key becomes something which acts just like a strong reference to the value, but without actually preventing the classloader (and thereby the value) from being collected if it is no longer referenced. And that still holds true even if the value has a strong reference to that classloader. - DML From tim.bell at sun.com Tue Mar 3 15:52:17 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Tue, 03 Mar 2009 15:52:17 +0000 Subject: hg: jdk7/tl: Added tag jdk7-b49 for changeset aee93a8992d2 Message-ID: <20090303155218.13049E65B@hg.openjdk.java.net> Changeset: 5111e13e44e5 Author: xdono Date: 2009-02-26 10:57 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/5111e13e44e5 Added tag jdk7-b49 for changeset aee93a8992d2 ! .hgtags From tim.bell at sun.com Tue Mar 3 15:55:04 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Tue, 03 Mar 2009 15:55:04 +0000 Subject: hg: jdk7/tl/corba: 2 new changesets Message-ID: <20090303155506.71C80E660@hg.openjdk.java.net> Changeset: 0edbd0074b02 Author: xdono Date: 2009-02-26 10:57 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/0edbd0074b02 Added tag jdk7-b49 for changeset d70978bc64bc ! .hgtags Changeset: 082f59f5ac64 Author: tbell Date: 2009-03-02 15:10 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/082f59f5ac64 Merge From tim.bell at sun.com Tue Mar 3 16:00:08 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Tue, 03 Mar 2009 16:00:08 +0000 Subject: hg: jdk7/tl/hotspot: 34 new changesets Message-ID: <20090303160114.CFFBDE665@hg.openjdk.java.net> Changeset: 23673011938d Author: ysr Date: 2009-01-30 14:17 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/23673011938d 6787254: Work queue capacity can be increased substantially on some platforms Summary: Increased the default and maximum size of the CMS marking stack and the size of the parallel workers' work queues in 64-bit mode. The latter was accomplished by an increase in the width of the Taskqueue's Age struct and its Tag field in 64-bit mode. Reviewed-by: jmasa, tonyp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/taskqueue.cpp ! src/share/vm/utilities/taskqueue.hpp Changeset: 9a25e0c45327 Author: jmasa Date: 2009-01-31 00:15 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9a25e0c45327 6792421: assert(_bitMap->isMarked(addr+size-1),inconsistent Printezis mark) Summary: The CMS concurrent precleaning and concurrent marking phases should work around classes that are undergoing redefinition. Reviewed-by: ysr, tonyp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/oops/cpCacheKlass.cpp ! src/share/vm/oops/cpCacheKlass.hpp ! src/share/vm/oops/cpCacheOop.hpp Changeset: a268411445d9 Author: ysr Date: 2009-02-04 15:42 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a268411445d9 Merge Changeset: 82a980778b92 Author: never Date: 2009-02-05 11:42 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/82a980778b92 6793828: G1: invariant: queues are empty when activated Reviewed-by: jrose, kvn ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/memnode.cpp Changeset: 58054a18d735 Author: apetrusenko Date: 2009-02-06 01:38 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/58054a18d735 6484959: G1: introduce survivor spaces 6797754: G1: combined bugfix Summary: Implemented a policy to control G1 survivor space parameters. Reviewed-by: tonyp, iveresov ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/survRateGroup.cpp ! src/share/vm/gc_implementation/g1/survRateGroup.hpp ! src/share/vm/gc_implementation/includeDB_gc_g1 ! src/share/vm/gc_implementation/shared/ageTable.cpp ! src/share/vm/gc_implementation/shared/ageTable.hpp Changeset: 05c6d52fa7a9 Author: jmasa Date: 2009-02-08 13:18 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/05c6d52fa7a9 6690928: Use spinning in combination with yields for workstealing termination. Summary: Substitute a spin loop for most calls to yield() to reduce the stress on the system. Reviewed-by: tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.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/genCollectedHeap.cpp ! src/share/vm/oops/cpCacheKlass.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/taskqueue.cpp ! src/share/vm/utilities/taskqueue.hpp Changeset: 1e458753107d Author: apetrusenko Date: 2009-02-09 17:33 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1e458753107d 6802413: G1: G1FixedSurvivorSpaceSize should be converted into regions in calculate_survivors_policy() Reviewed-by: tonyp, jmasa ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp Changeset: 773234c55e8c Author: ysr Date: 2009-02-09 12:26 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/773234c55e8c 6800586: -XX:+PrintGCDateStamps is using mt-unsafe localtime function Summary: replaced localtime() with localtime_r() on Solaris and Linux. Reviewed-by: apetrusenko, dholmes, jmasa ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp Changeset: fe3d7c11b4b7 Author: apetrusenko Date: 2009-02-10 18:39 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/fe3d7c11b4b7 6700941: G1: allocation spec missing for some G1 classes Reviewed-by: tonyp ! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1MMUTracker.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp ! src/share/vm/gc_implementation/includeDB_gc_g1 ! src/share/vm/utilities/workgroup.hpp Changeset: 96964ebdb154 Author: kvn Date: 2009-01-07 11:04 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/96964ebdb154 6782232: assert("CreateEx must be first instruction in block" ) Summary: Add the missing check for CreateEx. Add new notproduct flag VerifyRegisterAllocator. Reviewed-by: never ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/reg_split.cpp Changeset: 6c4cda924d2e Author: kvn Date: 2009-01-07 11:23 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6c4cda924d2e 6790182: matcher.cpp:1375: assert(false,"bad AD file") Summary: Add a match rule for regD_low in regD definition. Reviewed-by: never ! src/cpu/sparc/vm/sparc.ad Changeset: 011517bbcd7b Author: kvn Date: 2009-01-13 11:10 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/011517bbcd7b 6784930: server jvm fails with assert(!n->is_SpillCopy(),"") Summary: Set minimum block frequency MIN_BLOCK_FREQUENCY 1.e-35f. Reviewed-by: never, rasbold ! src/share/vm/opto/gcm.cpp Changeset: 041fe019d769 Author: never Date: 2009-01-13 11:43 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/041fe019d769 6791132: bad control in autobox split code Reviewed-by: kvn ! src/share/vm/opto/memnode.cpp Changeset: 78144dc3db03 Author: never Date: 2009-01-13 14:02 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/78144dc3db03 Merge Changeset: 35ae4dd6c27c Author: never Date: 2009-01-14 14:12 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/35ae4dd6c27c 6788347: C2Compiler crash 6u7 Reviewed-by: kvn ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp Changeset: 48bb4a49b7ac Author: kvn Date: 2009-01-16 11:23 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/48bb4a49b7ac 6790209: server VM fails with assert(will_link,"_new: typeflow responsibility") Summary: Add missing code for reflection class loader in SystemDictionary::find(). Reviewed-by: never, jrose ! src/share/vm/classfile/systemDictionary.cpp Changeset: 465813e0303a Author: kvn Date: 2009-01-21 11:18 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/465813e0303a 6794939: assert(_base == OopPtr,"subclass must override cast_to_ptr_type") Summary: Fix the assert in TypeKlassPtr::cast_to_ptr_type(). Reviewed-by: never ! src/share/vm/opto/type.cpp Changeset: 3b5ac9e7e6ea Author: twisti Date: 2009-01-26 16:22 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3b5ac9e7e6ea 6796746: rename LoadC (char) opcode class to LoadUS (unsigned short) Summary: Renaming LoadC to LoadUS would round up the planned introduction of LoadUB and LoadUI. Reviewed-by: phh, kvn ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/forms.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/mulnode.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/vectornode.cpp Changeset: 7628781568e1 Author: twisti Date: 2009-02-03 01:39 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7628781568e1 6795362: 32bit server compiler leads to wrong results on solaris-x86 Summary: The C2 compiler leads to wrong results on solaris-i486 (32-bit) for a testcase given in the CR. Reviewed-by: never, rasbold ! src/share/vm/opto/mulnode.cpp ! src/share/vm/utilities/globalDefinitions.hpp + test/compiler/6795362/Test6795362.java Changeset: b79faa366fbd Author: twisti Date: 2009-02-03 08:10 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b79faa366fbd 6799452: HotSpot tests Makefile should take care of ALT_SLASH_JAVA Summary: The HotSpot tests Makefile has a hardcoded SLASH_JAVA which makes it difficult to run the tests on non-Sun build machines which do not have a /java infrastructure. Reviewed-by: kamg ! test/Makefile Changeset: 5bfdb08ea692 Author: never Date: 2009-02-03 18:05 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5bfdb08ea692 6782260: Memory leak in CodeBuffer::create_patch_overflow Reviewed-by: phh, kvn ! src/share/vm/asm/codeBuffer.cpp Changeset: 1580954e694c Author: never Date: 2009-02-04 11:44 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1580954e694c 6798785: Crash in OopFlow::build_oop_map: incorrect comparison of 64bit pointers Reviewed-by: phh, kvn ! src/share/vm/adlc/dict2.cpp ! src/share/vm/libadt/dict.cpp Changeset: 1b9fc6e3171b Author: never Date: 2009-02-04 23:17 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1b9fc6e3171b 6442502: assert(bits,"Use TypePtr for NULL") on linux-x86 Reviewed-by: kvn ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp Changeset: 323728917cf4 Author: kvn Date: 2009-02-05 13:38 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/323728917cf4 6788376: allow to ignore unrecognized VM options Summary: Add new product flag -XX:+IgnoreUnrecognizedVMOptions Reviewed-by: ysr, xlu ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! test/compiler/6775880/Test.java Changeset: 7fe62bb75bf4 Author: kvn Date: 2009-02-05 14:43 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7fe62bb75bf4 6799693: Server compiler leads to data corruption when expression throws an Exception Summary: Use merged memory state for an allocation's slow path. Reviewed-by: never ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/macro.cpp + test/compiler/6795161/Test.java + test/compiler/6799693/Test.java Changeset: 91263420e1c6 Author: kvn Date: 2009-02-06 13:31 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/91263420e1c6 6791852: assert(b->_nodes[insidx] == n,"got insidx set incorrectly") Summary: Move the CreateEx up before each round of IFG construction Reviewed-by: never, phh ! src/share/vm/opto/block.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/reg_split.cpp Changeset: bbef4344adb2 Author: twisti Date: 2009-02-13 09:09 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/bbef4344adb2 6800154: Add comments to long_by_long_mulhi() for better understandability Summary: This patch adds a comment pointing to the Hacker's Delight version of the algorithm plus a verbatim copy of it. Furthermore it adds inline comments. Reviewed-by: kvn, jrose ! src/share/vm/opto/divnode.cpp + test/compiler/6603011/Test.java + test/compiler/6800154/Test6800154.java Changeset: 30663ca5e8f4 Author: twisti Date: 2009-02-16 07:19 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/30663ca5e8f4 6805724: ModLNode::Ideal() generates functionally incorrect graph when divisor is any (2^k-1) constant. Summary: C2, ModLNode::Ideal() generates functionally incorrect graph when divisor is any (2^k-1) constant. Reviewed-by: rasbold ! src/share/vm/opto/divnode.cpp ! src/share/vm/utilities/globalDefinitions.hpp + test/compiler/6805724/Test6805724.java Changeset: 2cacccded90f Author: twisti Date: 2009-02-17 11:19 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2cacccded90f 6805950: Typos in andL_rReg_imm instructions in x86_64.ad Summary: There are two typos in andL_rReg_imm instructions in x86_64.ad. Reviewed-by: kvn ! src/cpu/x86/vm/x86_64.ad Changeset: dca06e7f503d Author: kvn Date: 2009-02-17 14:30 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/dca06e7f503d Merge ! src/cpu/x86/vm/x86_32.ad ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 6b7f6a17455e Author: trims Date: 2009-02-18 18:14 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6b7f6a17455e Merge Changeset: 1605bb4eb5a7 Author: trims Date: 2009-02-18 18:20 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1605bb4eb5a7 6807345: Bump HS15 build number to 02 Summary: Update the HS15 Build number to 02 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 8b22ccb5aba2 Author: trims Date: 2009-02-25 23:16 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8b22ccb5aba2 Merge Changeset: dae503d9f04c Author: xdono Date: 2009-02-26 10:57 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/dae503d9f04c Added tag jdk7-b49 for changeset 8b22ccb5aba2 ! .hgtags From tim.bell at sun.com Tue Mar 3 16:07:34 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Tue, 03 Mar 2009 16:07:34 +0000 Subject: hg: jdk7/tl/jaxp: Added tag jdk7-b49 for changeset 5c1f24531903 Message-ID: <20090303160736.6DBECE66A@hg.openjdk.java.net> Changeset: e8514e2be76d Author: xdono Date: 2009-02-26 10:57 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/e8514e2be76d Added tag jdk7-b49 for changeset 5c1f24531903 ! .hgtags From tim.bell at sun.com Tue Mar 3 16:10:20 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Tue, 03 Mar 2009 16:10:20 +0000 Subject: hg: jdk7/tl/jaxws: Added tag jdk7-b49 for changeset 18ca864890f3 Message-ID: <20090303161023.0C2D1E66F@hg.openjdk.java.net> Changeset: 5be52db581f1 Author: xdono Date: 2009-02-26 10:57 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/5be52db581f1 Added tag jdk7-b49 for changeset 18ca864890f3 ! .hgtags From tim.bell at sun.com Tue Mar 3 16:13:12 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Tue, 03 Mar 2009 16:13:12 +0000 Subject: hg: jdk7/tl/jdk: 4 new changesets Message-ID: <20090303161412.35627E674@hg.openjdk.java.net> Changeset: 383d6bebfba6 Author: xdono Date: 2009-02-26 10:57 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/383d6bebfba6 Added tag jdk7-b49 for changeset 8311105ea7a3 ! .hgtags Changeset: 59e76cdc647a Author: tbell Date: 2009-02-27 10:53 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/59e76cdc647a Merge Changeset: 58ba2cd5a250 Author: alanb Date: 2009-03-01 14:44 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/58ba2cd5a250 6811578: genSolarisConstants.c should not require kernel patch to compile on Solaris 10 Reviewed-by: tbell ! src/solaris/native/sun/nio/fs/genSolarisConstants.c Changeset: 7546743f4cc0 Author: tbell Date: 2009-03-02 15:10 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7546743f4cc0 Merge From tim.bell at sun.com Tue Mar 3 16:22:18 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Tue, 03 Mar 2009 16:22:18 +0000 Subject: hg: jdk7/tl/langtools: 5 new changesets Message-ID: <20090303162226.46444E679@hg.openjdk.java.net> Changeset: d17d927ad9bd Author: xdono Date: 2009-02-19 14:08 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d17d927ad9bd Added tag jdk7-b48 for changeset c53007f34195 ! .hgtags Changeset: 1a902c0eb3f9 Author: tbell Date: 2009-02-24 07:55 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/1a902c0eb3f9 Merge Changeset: cc69a0495ac5 Author: xdono Date: 2009-02-26 10:57 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/cc69a0495ac5 Added tag jdk7-b49 for changeset d17d927ad9bd ! .hgtags Changeset: 46f2f6ed96f1 Author: tbell Date: 2009-02-27 10:54 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/46f2f6ed96f1 Merge Changeset: 2f4c4900ca2b Author: tbell Date: 2009-03-02 15:11 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/2f4c4900ca2b Merge From openjdk at crazybob.org Tue Mar 3 18:14:16 2009 From: openjdk at crazybob.org (Bob Lee) Date: Tue, 3 Mar 2009 10:14:16 -0800 Subject: [PATCH 0/2] Class- and class loader-local storage (Bug ID #6493635) In-Reply-To: <49ACD041.1070909@redhat.com> References: <49A85188.5060903@redhat.com> <49A8574E.1020601@redhat.com> <49A869E5.9050102@redhat.com> <49ABFA76.1050407@redhat.com> <49ACD041.1070909@redhat.com> Message-ID: On Mon, Mar 2, 2009 at 10:37 PM, David M. Lloyd wrote: > If not, then there is no automatic solution possible, even with special VM > ephemeron support (this basically IS an ephemeron implementation, after all, > albeit a specialized one). Actually, your approach is not the same as an ephemeron at all. See http://en.wikipedia.org/wiki/Ephemeron: "Here, the registry (a third party) will hold onto the association itself which would require manual removal from the registry (instead of automated garbage collection). *While this problem can be always be solved in any given concrete situation by using one of the various weak association types, choosing the 'right' kind of association depends on a variety of factors some of which can change dynamically.* Ephemerons solve this problem by defining that the 'contents' (value) of an Ephemeron will be held strongly until the key is known to be garbage collected. From then on, the contents of the ephemeron will be held weakly. Therefore, the contents of an ephemeron can only become eligible for garbage collection if and only if the key is garbage collectable which is the exact behavior which we would observe for an instance variable of the object." All you've done is chosen a different weak association type. You're chosen type works in some situations, but it breaks others. Ephemerons work (in the sense that they're cleared automatically) in all situations. This can't be emulated in the libraries. > When I started this thread, I was content with solving the simpler case: a >> library loaded in the parent class loader associating data with classes >> loaded in a child loader. This is solvable at the library level and doesn't >> require explicit clearing. If I want a library loaded in the child class >> loader to store information about classes from the parent loader, I can just >> keep strong references to the Class objects because I know that the child >> loader will be reclaimed before the parent loader. >> > > When would that situation actually arise, just out of curiosity? In terms > of specific use case I mean. I run into this all the time: a library (like Dynaop, Guice or Google Collections) is in the system classpath (or maybe even an EAR class loader) and holds a reference to a class in a web app classloader and prevents the web app from being unloaded. > I think you're confusing the requirement for explicit clearing when the > value changes or becomes obsolete with automatic collection of the keys. > Implicitly clearing the value in this situation can *never* work - not with > ephemerons, not without a psychic GC - because the application is always > holding only a weak reference to the value *already*. The whole point was > to add a strong reference to the value from the classloader; how can the GC > determine when you don't need that particular value anymore? > The Class is the ephemeron key, and the GC knows it can clear the ephemeron when the Class is no longer strongly referenced outside of the ephemeron value. Bob -------------- next part -------------- An HTML attachment was scrubbed... URL: From Mandy.Chung at Sun.COM Tue Mar 3 18:25:43 2009 From: Mandy.Chung at Sun.COM (Mandy Chung) Date: Tue, 03 Mar 2009 10:25:43 -0800 Subject: Review request for 6799230 Message-ID: <49AD7627.6030005@Sun.com> 6799230: Lazily load java.lang.annotation.Annotation class Webrev at: http://cr.openjdk.java.net/~mchung/6799230/webrev.00/ java.lang.annotation.Annotation class is always loaded when loading java.lang.Class, java.lang.reflect.Constructor, java.lang.reflect.Method, and java.lang.reflect.Field due to a static field EMPTY_ANNOTATION_ARRAY. This dependency is only needed when the getAnnotations or getDeclaredAnnotation method is called. Thanks Mandy From david.lloyd at redhat.com Tue Mar 3 19:43:40 2009 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 03 Mar 2009 13:43:40 -0600 Subject: [PATCH 0/2] Class- and class loader-local storage (Bug ID #6493635) In-Reply-To: References: <49A85188.5060903@redhat.com> <49A8574E.1020601@redhat.com> <49A869E5.9050102@redhat.com> <49ABFA76.1050407@redhat.com> <49ACD041.1070909@redhat.com> Message-ID: <49AD886C.3060409@redhat.com> On 03/03/2009 12:13 PM, Bob Lee wrote: > On Mon, Mar 2, 2009 at 10:37 PM, David M. Lloyd > wrote: > > If not, then there is no automatic solution possible, even with > special VM ephemeron support (this basically IS an ephemeron > implementation, after all, albeit a specialized one). > > > Actually, your approach is not the same as an ephemeron at all. See > http://en.wikipedia.org/wiki/Ephemeron: > > "Here, the registry (a third party) will hold onto the association > itself which would require manual removal from the registry (instead of > automated garbage collection). *While this problem can be always be > solved in any given concrete situation by using one of the various weak > association types, choosing the 'right' kind of association depends on a > variety of factors some of which can change dynamically.* > > Ephemerons solve this problem by defining that the 'contents' (value) of > an Ephemeron will be held strongly until the key is known to be garbage > collected. From then on, the contents of the ephemeron will be held > weakly. Therefore, the contents of an ephemeron can only become eligible > for garbage collection if and only if the key is garbage collectable > which is the exact behavior which we would observe for an instance > variable of the object." > > All you've done is chosen a different weak association type. You're > chosen type works in some situations, but it breaks others. Ephemerons > work (in the sense that they're cleared automatically) in all > situations. This can't be emulated in the libraries. No, actually what I've implemented *exactly* matches this definition: a mapping where the value is held strongly until the key is known to be garbage collected (even when the value has a reference back to the key). The only difference between what I've done and a "real" ephemeron is that presumably a "real" ephemeron will be able to associate the value with ANY object, without there having to be a field for the value on that object (this is what they're referring to by "association type"). > The Class is the ephemeron key, and the GC knows it can clear the > ephemeron when the Class is no longer strongly referenced outside of the > ephemeron value. Precisely. - DML From crazybob at crazybob.org Tue Mar 3 20:17:06 2009 From: crazybob at crazybob.org (Bob Lee) Date: Tue, 3 Mar 2009 12:17:06 -0800 Subject: [PATCH 0/2] Class- and class loader-local storage (Bug ID #6493635) In-Reply-To: <49AD886C.3060409@redhat.com> References: <49A8574E.1020601@redhat.com> <49A869E5.9050102@redhat.com> <49ABFA76.1050407@redhat.com> <49ACD041.1070909@redhat.com> <49AD886C.3060409@redhat.com> Message-ID: On Tue, Mar 3, 2009 at 11:43 AM, David M. Lloyd wrote: > No, actually what I've implemented *exactly* matches this definition: a > mapping where the value is held strongly until the key is known to be > garbage collected (even when the value has a reference back to the key). The > only difference between what I've done and a "real" ephemeron is that > presumably a "real" ephemeron will be able to associate the value with ANY > object, without there having to be a field for the value on that object > (this is what they're referring to by "association type"). > Maybe an example will clarify. We have a child class loader that associates a value with a Class from the parent class loader. With your approach, the parent class loader has a strong reference to the value. If the value strongly references a class from the child class loader, the child class loader will not be able to be reclaimed (unless you explicitly clear which would defeat the purpose of this construct). Unlike your solution, if we use an ephemeron, there would be no strong reference from the parent class loader, so the child class loader can be reclaimed. Make sense? Bob -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at Sun.COM Tue Mar 3 20:21:23 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Tue, 03 Mar 2009 20:21:23 +0000 Subject: Fix for 5015163, and my first webrev In-Reply-To: <108fcdeb0903021549l309d9fc5w9aa3d47c4b3abecf@mail.gmail.com> References: <498CA4CE.1090207@univ-mlv.fr> <108fcdeb0902061503j626b4727y520afe683b43f184@mail.gmail.com> <498CDD73.7080803@univ-mlv.fr> <108fcdeb0903021549l309d9fc5w9aa3d47c4b3abecf@mail.gmail.com> Message-ID: <49AD9143.8050209@sun.com> Kevin Bourrillion wrote: > Bumping this thread. From the peanut gallery, I believe that R?mi's > change is extremely worthy. I have more nitpicking I'd like to do on > it, but am holding off until we learn whether Sun would accept it in > any shape. > > At this point, it's still very mysterious to me how this will work > (small, simple new APIs being added to core libraries via openjdk). I agree it's worth continuing this. As you said, it's one of those things that almost everyone has written many times. Mark sent out a link a few days ago to a draft process for jdk7 development [1]. I assume in time this will detail the process for reviewing API additions and replacing the current (Sun-internal) CCC process. -Alan. [1] http://mail.openjdk.java.net/pipermail/jdk7-dev/2009-February/000411.html From david.lloyd at redhat.com Tue Mar 3 22:01:40 2009 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 03 Mar 2009 16:01:40 -0600 Subject: [PATCH 0/2] Class- and class loader-local storage (Bug ID #6493635) In-Reply-To: References: <49A8574E.1020601@redhat.com> <49A869E5.9050102@redhat.com> <49ABFA76.1050407@redhat.com> <49ACD041.1070909@redhat.com> <49AD886C.3060409@redhat.com> Message-ID: <49ADA8C4.10809@redhat.com> On 03/03/2009 02:17 PM, Bob Lee wrote: > On Tue, Mar 3, 2009 at 11:43 AM, David M. Lloyd > wrote: > > No, actually what I've implemented *exactly* matches this > definition: a mapping where the value is held strongly until the key > is known to be garbage collected (even when the value has a > reference back to the key). The only difference between what I've > done and a "real" ephemeron is that presumably a "real" ephemeron > will be able to associate the value with ANY object, without there > having to be a field for the value on that object (this is what > they're referring to by "association type"). > > > Maybe an example will clarify. We have a child class loader that > associates a value with a Class from the parent class loader. With your > approach, the parent class loader has a strong reference to the value. > If the value strongly references a class from the child class loader, > the child class loader will not be able to be reclaimed (unless you > explicitly clear which would defeat the purpose of this construct). > Unlike your solution, if we use an ephemeron, there would be no strong > reference from the parent class loader, so the child class loader can be > reclaimed. Make sense? Yes, I see what you're saying. The issue is mitigated by having a separate, dedicated key object (in this case, the class local variable itself). The only reason you'd have to fall back on explicit clearing is if you set up your value to have a strong reference back to the class-local itself. As long as you don't do that, then the value can still be cleared when the class-local key is GC'd. Now that's the point of using a separate key object here - to decrease the likelihood of that reference structure from existing. If you *do* need to keep a reference back to the key from the value (even indirectly), you can usually make it a WeakReference and thus avoid a problem. The breakdown point here is when the ClassLocal is stored on a static field, thus tying its lifetime to that of the class. This is when you can only use explicit clearing to fix things - you'd be back to the original problem again otherwise. It is possible to rearrange things a little more to make the case slightly less likely, but not eliminate it 100%. Even a native ephemeron implementation would have to be able to take into account isolating values that are only reachable from ephemeron keys which are in turn reachable only from other ephemeron keys in order to avoid the same trap. In any case, like I said, moving to "real" ephemerons once they're available is a simple change, and it would be nice to have this ability sooner (by JDK7 possibly) rather than later (JDK8 or later). I think the semantics as they stand would be sufficient for many uses (certainly all the published use cases I could find). - DML From Joe.Darcy at Sun.COM Wed Mar 4 01:35:48 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Tue, 03 Mar 2009 17:35:48 -0800 Subject: Review request for 6799230 -- approved In-Reply-To: <49AD7627.6030005@Sun.com> References: <49AD7627.6030005@Sun.com> Message-ID: <49ADDAF4.7010506@sun.com> Hi Mandy. Looks fine; approved. -Joe Mandy Chung wrote: > 6799230: Lazily load java.lang.annotation.Annotation class > > Webrev at: > http://cr.openjdk.java.net/~mchung/6799230/webrev.00/ > > java.lang.annotation.Annotation class is always loaded when loading > java.lang.Class, java.lang.reflect.Constructor, > java.lang.reflect.Method, and java.lang.reflect.Field due to a static > field EMPTY_ANNOTATION_ARRAY. > > This dependency is only needed when the getAnnotations or > getDeclaredAnnotation method is called. > > Thanks > Mandy From mandy.chung at sun.com Wed Mar 4 03:30:13 2009 From: mandy.chung at sun.com (mandy.chung at sun.com) Date: Wed, 04 Mar 2009 03:30:13 +0000 Subject: hg: jdk7/tl/jdk: 6799230: Lazily load java.lang.annotation.Annotation class Message-ID: <20090304033038.8DF0FE72A@hg.openjdk.java.net> Changeset: 07d2550f5c84 Author: mchung Date: 2009-03-03 19:26 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/07d2550f5c84 6799230: Lazily load java.lang.annotation.Annotation class Summary: Remove the static EMPTY_ANNOTATION_ARRAY field; add AnnotationParser.toArray method Reviewed-by: darcy ! src/share/classes/java/lang/Class.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 ! src/share/classes/sun/reflect/annotation/AnnotationParser.java From weijun.wang at sun.com Wed Mar 4 07:13:40 2009 From: weijun.wang at sun.com (weijun.wang at sun.com) Date: Wed, 04 Mar 2009 07:13:40 +0000 Subject: hg: jdk7/tl/jdk: 6705872: SecureRandom number init is taking too long on a java.io.tmpdir with a large number of files. Message-ID: <20090304071409.50CCBE738@hg.openjdk.java.net> Changeset: a8d9e8cb38bb Author: weijun Date: 2009-03-04 15:09 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a8d9e8cb38bb 6705872: SecureRandom number init is taking too long on a java.io.tmpdir with a large number of files. Reviewed-by: xuelei, alanb ! src/share/classes/sun/security/provider/SeedGenerator.java From christopher.hegarty at sun.com Wed Mar 4 13:31:51 2009 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Wed, 04 Mar 2009 13:31:51 +0000 Subject: hg: jdk7/tl/jdk: 6775145: ClassLoaderUtil.releaseLoader calls System.out.println ("classLoader = " + classLoader) Message-ID: <20090304133203.CB064E762@hg.openjdk.java.net> Changeset: 94d02968a504 Author: chegar Date: 2009-03-04 13:28 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/94d02968a504 6775145: ClassLoaderUtil.releaseLoader calls System.out.println ("classLoader = " + classLoader) Summary: Remove System.out debugging statements Reviewed-by: michaelm ! src/share/classes/sun/misc/ClassLoaderUtil.java From christopher.hegarty at sun.com Wed Mar 4 13:39:47 2009 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Wed, 04 Mar 2009 13:39:47 +0000 Subject: hg: jdk7/tl/jdk: 6737323: Typo in javadoc for SocketPermission Message-ID: <20090304133959.2A056E767@hg.openjdk.java.net> Changeset: 03001e92d155 Author: chegar Date: 2009-03-04 13:36 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/03001e92d155 6737323: Typo in javadoc for SocketPermission Summary: Remove redundant line form class description Reviewed-by: jccollet ! src/share/classes/java/net/SocketPermission.java From xueming.shen at sun.com Wed Mar 4 17:40:37 2009 From: xueming.shen at sun.com (xueming.shen at sun.com) Date: Wed, 04 Mar 2009 17:40:37 +0000 Subject: hg: jdk7/tl/jdk: 6812879: Excess code line in ArrayList method Message-ID: <20090304174102.B4629E786@hg.openjdk.java.net> Changeset: 6568cd51ae12 Author: sherman Date: 2009-03-04 09:26 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6568cd51ae12 6812879: Excess code line in ArrayList method Summary: Removed the line of "oldData" which is no longer used. Reviewed-by: martin ! src/share/classes/java/util/ArrayList.java From weijun.wang at sun.com Thu Mar 5 06:54:09 2009 From: weijun.wang at sun.com (weijun.wang at sun.com) Date: Thu, 05 Mar 2009 06:54:09 +0000 Subject: hg: jdk7/tl/jdk: 6813402: keytool cannot -printcert entries without extensions Message-ID: <20090305065425.514D0E7DE@hg.openjdk.java.net> Changeset: 97da21737d9e Author: weijun Date: 2009-03-05 14:49 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/97da21737d9e 6813402: keytool cannot -printcert entries without extensions Reviewed-by: xuelei ! src/share/classes/sun/security/tools/KeyTool.java + test/sun/security/tools/keytool/NoExtNPE.sh From Mandy.Chung at Sun.COM Thu Mar 5 07:01:14 2009 From: Mandy.Chung at Sun.COM (Mandy Chung) Date: Wed, 04 Mar 2009 23:01:14 -0800 Subject: Review request for 6810254 Message-ID: <49AF78BA.8010608@sun.com> 6810254: Lazily instantiate the shared secret access objects Webrev at: http://cr.openjdk.java.net/~mchung/6810254/webrev.00/ sun.misc.Java*Access objects are created at initialization time. However, they are not always needed. They can be instantiated lazily when needed. The fix is to add a static setSharedSecret() method to be called by sun.misc.SharedSecrets via reflection when the shared secret access object is requested. Thanks Mandy From David.Holmes at Sun.COM Thu Mar 5 12:18:55 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Thu, 05 Mar 2009 22:18:55 +1000 Subject: Review request for 6810254 In-Reply-To: <49AF78BA.8010608@sun.com> References: <49AF78BA.8010608@sun.com> Message-ID: <49AFC32F.7020504@sun.com> Hi Mandy, Isn't this kind of change risky? With static initialization you know that once the VM gets up and running then everything is in place. But with lazy-initialization (and using reflection no less!) there's a danger that when you try to initialize you're more likely to fail due to lack of memory or resources. I can't quite tell exactly when these setSharedSecret methods will be called. BTW I think the comments copied into src/share/classes/java/io/DeleteOnExitHook.java need to be reviewed - they made sense when the code was java.io.File, but not now :) Cheers, David Mandy Chung said the following on 03/05/09 17:01: > 6810254: Lazily instantiate the shared secret access objects > > Webrev at: > http://cr.openjdk.java.net/~mchung/6810254/webrev.00/ > > sun.misc.Java*Access objects are created at initialization time. > However, they are not always needed. They can be instantiated lazily > when needed. The fix is to add a static setSharedSecret() method to be > called by sun.misc.SharedSecrets via reflection when the shared secret > access object is requested. > > Thanks > Mandy From maurizio.cimadamore at sun.com Thu Mar 5 17:50:50 2009 From: maurizio.cimadamore at sun.com (maurizio.cimadamore at sun.com) Date: Thu, 05 Mar 2009 17:50:50 +0000 Subject: hg: jdk7/tl/langtools: 4 new changesets Message-ID: <20090305175057.15409E7FD@hg.openjdk.java.net> Changeset: 850869f70213 Author: mcimadamore Date: 2009-03-05 17:24 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/850869f70213 6467183: javac fails to raise unchecked warning on cast of parameterized generic subclass Summary: cleanup code for generating unchecked cast warnings Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/cast/6467183/T6467183a.java + test/tools/javac/cast/6467183/T6467183a.out + test/tools/javac/cast/6467183/T6467183b.java Changeset: 84a18d7da478 Author: mcimadamore Date: 2009-03-05 17:24 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/84a18d7da478 6804733: javac generates spourious diagnostics for ill-formed type-variable bounds Summary: fixed algorithm for checking cycles in typevar declarations Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/generics/typevars/6804733/T6804733.java + test/tools/javac/generics/typevars/6804733/T6804733.out Changeset: 9711a6c2db7e Author: mcimadamore Date: 2009-03-05 17:25 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/9711a6c2db7e 6807255: LineNumberTable wrong if enhanced-for-loops are used Summary: end position of iterable for-each loop was not set properly Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Lower.java Changeset: 86b60aa941c6 Author: mcimadamore Date: 2009-03-05 17:25 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/86b60aa941c6 6799605: Basic/Raw formatters should use type/symbol printer instead of toString() Summary: create new combo type/symbol visitor printer used by all diagnostic formatters Reviewed-by: jjg + src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java + test/tools/javac/Diagnostics/6799605/T6799605.java + test/tools/javac/Diagnostics/6799605/T6799605.out ! test/tools/javac/NestedInnerClassNames.out ! test/tools/javac/T6241723.out ! test/tools/javac/depDocComment/SuppressDeprecation.out ! test/tools/javac/mandatoryWarnings/deprecated/Test3.out ! test/tools/javac/mandatoryWarnings/deprecated/Test3b.out ! test/tools/javac/mandatoryWarnings/deprecated/Test4.out ! test/tools/javac/mandatoryWarnings/deprecated/Test4b.out ! test/tools/javac/mandatoryWarnings/deprecated/Test4c.out ! test/tools/javac/mandatoryWarnings/deprecated/Test4d.out ! test/tools/javac/positions/T6253161.out ! test/tools/javac/positions/T6253161a.out ! test/tools/javac/warnings/Deprecation.lintAll.out ! test/tools/javac/warnings/Deprecation.lintDeprecation.out From mr at sun.com Thu Mar 5 18:35:03 2009 From: mr at sun.com (Mark Reinhold) Date: Thu, 05 Mar 2009 10:35:03 -0800 Subject: Meaning of -XX:MaxDirectMemorySize In-Reply-To: alan.bateman@sun.com; Thu, 05 Mar 2009 16:05:52 GMT; <49AFF860.80309@sun.com> Message-ID: <20090305183503.E59FB28E0EF@eggemoggin.niobe.net> > Date: Thu, 05 Mar 2009 16:05:52 +0000 > From: alan.bateman at sun.com > ... The issue will > likely come down to the meaning of the value passed to the > MaxDirectMemorySize option. Would I be correct to say that the original > intention was to limit the total memory usage and not the total > capacity? It was original implemented (in jdk5) to limit the total > capacity but I assume that was an oversight. The difference becomes an > issue when the buffer capacity is small but the page size is large. The original intent was to limit the total capacity, measured in bytes, of all direct buffers. Additional memory allocated due to rounding the size of each direct buffer up to the nearest page size was not to be counted. We assumed that large pages wouldn't be an issue -- is that what you're running into? - Mark From yu-ching.peng at sun.com Thu Mar 5 19:51:03 2009 From: yu-ching.peng at sun.com (yu-ching.peng at sun.com) Date: Thu, 05 Mar 2009 19:51:03 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20090305195128.766CAE81A@hg.openjdk.java.net> Changeset: da9d0283a496 Author: valeriep Date: 2009-03-03 19:50 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/da9d0283a496 6812738: SSL stress test with GF leads to 32 bit max process size in less than 5 minutes with PCKS11 provider Summary: Removed finalize() and add more error handling to native code Reviewed-by: vinnie ! src/share/classes/sun/security/pkcs11/P11Key.java ! src/share/classes/sun/security/pkcs11/P11RSACipher.java ! src/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java ! src/share/native/sun/security/pkcs11/wrapper/p11_convert.c ! src/share/native/sun/security/pkcs11/wrapper/p11_crypt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_digest.c ! src/share/native/sun/security/pkcs11/wrapper/p11_dual.c ! src/share/native/sun/security/pkcs11/wrapper/p11_general.c ! src/share/native/sun/security/pkcs11/wrapper/p11_keymgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_mutex.c ! src/share/native/sun/security/pkcs11/wrapper/p11_objmgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sessmgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sign.c ! src/share/native/sun/security/pkcs11/wrapper/p11_util.c ! src/share/native/sun/security/pkcs11/wrapper/pkcs11wrapper.h Changeset: 7b3cfde54812 Author: valeriep Date: 2009-03-05 11:44 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7b3cfde54812 Merge From Alan.Bateman at Sun.COM Thu Mar 5 20:26:07 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Thu, 05 Mar 2009 20:26:07 +0000 Subject: Meaning of -XX:MaxDirectMemorySize In-Reply-To: <20090305183503.E59FB28E0EF@eggemoggin.niobe.net> References: <20090305183503.E59FB28E0EF@eggemoggin.niobe.net> Message-ID: <49B0355F.2000709@sun.com> Mark Reinhold wrote: > : > The original intent was to limit the total capacity, measured in bytes, > of all direct buffers. Additional memory allocated due to rounding the > size of each direct buffer up to the nearest page size was not to be > counted. > > We assumed that large pages wouldn't be an issue -- is that what you're > running into? > Thanks for the clarification. The issue is the difference as the alignment currently costs an additional page per buffer. This is hard to explain to those trying to constrain the memory usage via the option. It's mostly an issue with applications that allocate small buffers rather than slicing big buffers. Large pages can be problem also (esp. the T1/T2 as they can support up to 256MB pages to compensate for the small TLB). At some point we'll need to re-visit the alignment, perhaps by having an option to not align. -Alan. From Mandy.Chung at Sun.COM Thu Mar 5 21:18:22 2009 From: Mandy.Chung at Sun.COM (Mandy Chung) Date: Thu, 05 Mar 2009 13:18:22 -0800 Subject: Review request for 6810254 In-Reply-To: <49AFC32F.7020504@sun.com> References: <49AF78BA.8010608@sun.com> <49AFC32F.7020504@sun.com> Message-ID: <49B0419E.2010509@Sun.com> On 03/05/09 04:18, David Holmes - Sun Microsystems wrote: > Hi Mandy, > > Isn't this kind of change risky? With static initialization you know > that once the VM gets up and running then everything is in place. But > with lazy-initialization (and using reflection no less!) there's a > danger that when you try to initialize you're more likely to fail due to > lack of memory or resources. That's a good point. I change the getSystemShutdownHooks() method to return a preallocated array. The initialization of the hooks themselves are not changed by this fix. However, if the application shutdown hook adds the first file to be deleted on exit, the lazy initialization may cause some trouble. I'll look into it and send out a new webrev. I ran the jtreg tests and I am going to run the JCK tests to make sure no regression. > I can't quite tell exactly when these > setSharedSecret methods will be called. When SharedSecrets.getJava*Access() method is called, it will SharedSecrets.setSharedSecret() which in turn calls .setSharedSecret() method of the given cls. > BTW I think the comments copied into > src/share/classes/java/io/DeleteOnExitHook.java need to be reviewed - > they made sense when the code was java.io.File, but not now :) Ok. Thanks Mandy > Cheers, > David > > Mandy Chung said the following on 03/05/09 17:01: >> 6810254: Lazily instantiate the shared secret access objects >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/6810254/webrev.00/ >> >> sun.misc.Java*Access objects are created at initialization time. >> However, they are not always needed. They can be instantiated lazily >> when needed. The fix is to add a static setSharedSecret() method to >> be called by sun.misc.SharedSecrets via reflection when the shared >> secret access object is requested. >> >> Thanks >> Mandy From David.Holmes at Sun.COM Thu Mar 5 22:06:08 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Fri, 06 Mar 2009 08:06:08 +1000 Subject: Review request for 6810254 In-Reply-To: <49B0419E.2010509@Sun.com> References: <49AF78BA.8010608@sun.com> <49AFC32F.7020504@sun.com> <49B0419E.2010509@Sun.com> Message-ID: <49B04CD0.2000506@sun.com> Hi Mandy, Note that my main concern is the use of reflection. If the class involved has not previously had it's reflection objects initialized then getDeclaredMethod can lead to a lot of native and Java-level allocation (I'm assuming this hasn't changed a great deal from the Java 5 code). Even if there is memory to be allocated this might induce some GC churn in a new and unexpected place. Maybe the lazy-initialization holder class pattern can be used instead eg: static { // setup access to this package in SharedSecrets sun.misc.SharedSecrets.setJavaNioAccess(... } becomes: static class SharedSecretsHelper { static { // setup access to this package in SharedSecrets sun.misc.SharedSecrets.setJavaNioAccess(... } } and setSharedSecret(Class cls) does: Class.forName(cls.getName() + "$SharedSecretsHelper"); ??? Leave it with you ... Cheers, David Mandy Chung said the following on 03/06/09 07:18: > On 03/05/09 04:18, David Holmes - Sun Microsystems wrote: >> Hi Mandy, >> >> Isn't this kind of change risky? With static initialization you know >> that once the VM gets up and running then everything is in place. But >> with lazy-initialization (and using reflection no less!) there's a >> danger that when you try to initialize you're more likely to fail due >> to lack of memory or resources. > > That's a good point. I change the getSystemShutdownHooks() method to > return a preallocated array. The initialization of the hooks themselves > are not changed by this fix. However, if the application shutdown hook > adds the first file to be deleted on exit, the lazy initialization may > cause some trouble. I'll look into it and send out a new webrev. > > I ran the jtreg tests and I am going to run the JCK tests to make sure > no regression. > >> I can't quite tell exactly when these setSharedSecret methods will be >> called. > > When SharedSecrets.getJava*Access() method is called, it will > SharedSecrets.setSharedSecret() which in turn calls > .setSharedSecret() method of the given cls. > >> BTW I think the comments copied into >> src/share/classes/java/io/DeleteOnExitHook.java need to be reviewed - >> they made sense when the code was java.io.File, but not now :) > > Ok. > > Thanks > Mandy > >> Cheers, >> David >> >> Mandy Chung said the following on 03/05/09 17:01: >>> 6810254: Lazily instantiate the shared secret access objects >>> >>> Webrev at: >>> http://cr.openjdk.java.net/~mchung/6810254/webrev.00/ >>> >>> sun.misc.Java*Access objects are created at initialization time. >>> However, they are not always needed. They can be instantiated lazily >>> when needed. The fix is to add a static setSharedSecret() method to >>> be called by sun.misc.SharedSecrets via reflection when the shared >>> secret access object is requested. >>> >>> Thanks >>> Mandy From Alan.Bateman at Sun.COM Fri Mar 6 15:21:44 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Fri, 06 Mar 2009 15:21:44 +0000 Subject: Review request for 6810254 In-Reply-To: <49AF78BA.8010608@sun.com> References: <49AF78BA.8010608@sun.com> Message-ID: <49B13F88.7050101@sun.com> Mandy Chung wrote: > 6810254: Lazily instantiate the shared secret access objects > > Webrev at: > http://cr.openjdk.java.net/~mchung/6810254/webrev.00/ > > sun.misc.Java*Access objects are created at initialization time. > However, they are not always needed. They can be instantiated lazily > when needed. The fix is to add a static setSharedSecret() method to > be called by sun.misc.SharedSecrets via reflection when the shared > secret access object is requested. > > Thanks > Mandy It's good to see the setup of the shutdown hooks being removed from the initialization. However, I think it might be cleaner have each register itself lazily rather than SharedSecrets knowing about it. That has the added benefit that only the needed hooks are registered. It also avoids needing the reflection code. A possible downside is that each hook needs to know its place in the world. Attached is a (completely unpolished) patch that does this and perhaps it would be useful to try. -Alan. -------------- next part -------------- A non-text attachment was scrubbed... Name: shutdown.patch Type: text/x-patch Size: 11568 bytes Desc: not available URL: From Mandy.Chung at Sun.COM Fri Mar 6 18:44:33 2009 From: Mandy.Chung at Sun.COM (Mandy Chung) Date: Fri, 06 Mar 2009 10:44:33 -0800 Subject: Review request for 6810254 In-Reply-To: <49B13F88.7050101@sun.com> References: <49AF78BA.8010608@sun.com> <49B13F88.7050101@sun.com> Message-ID: <49B16F11.9090605@sun.com> Thanks Alan. This is a good approach that avoids using reflection and addresses David's concern. I was a bit aggressive to lazily instantiate Java*Access objects as many as I can. I'll revise the fix and send out a new webrev. Thanks Mandy Alan Bateman wrote: > Mandy Chung wrote: >> 6810254: Lazily instantiate the shared secret access objects >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/6810254/webrev.00/ >> >> sun.misc.Java*Access objects are created at initialization time. >> However, they are not always needed. They can be instantiated lazily >> when needed. The fix is to add a static setSharedSecret() method to >> be called by sun.misc.SharedSecrets via reflection when the shared >> secret access object is requested. >> >> Thanks >> Mandy > It's good to see the setup of the shutdown hooks being removed from > the initialization. However, I think it might be cleaner have each > register itself lazily rather than SharedSecrets knowing about it. > That has the added benefit that only the needed hooks are registered. > It also avoids needing the reflection code. A possible downside is > that each hook needs to know its place in the world. Attached is a > (completely unpolished) patch that does this and perhaps it would be > useful to try. > > -Alan. From tim.bell at sun.com Sat Mar 7 19:35:19 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Sat, 07 Mar 2009 19:35:19 +0000 Subject: hg: jdk7/tl: Added tag jdk7-b50 for changeset 5111e13e44e5 Message-ID: <20090307193520.23FD8E9D5@hg.openjdk.java.net> Changeset: 28ba432554f4 Author: xdono Date: 2009-03-05 09:48 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/28ba432554f4 Added tag jdk7-b50 for changeset 5111e13e44e5 ! .hgtags From tim.bell at sun.com Sat Mar 7 19:40:20 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Sat, 07 Mar 2009 19:40:20 +0000 Subject: hg: jdk7/tl/corba: 2 new changesets Message-ID: <20090307194022.4CCF0E9DA@hg.openjdk.java.net> Changeset: 12f178e7737f Author: xdono Date: 2009-03-05 09:49 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/12f178e7737f Added tag jdk7-b50 for changeset 0edbd0074b02 ! .hgtags Changeset: ec634b3aa302 Author: tbell Date: 2009-03-06 10:52 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/ec634b3aa302 Merge From tim.bell at sun.com Sat Mar 7 19:47:27 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Sat, 07 Mar 2009 19:47:27 +0000 Subject: hg: jdk7/tl/hotspot: Added tag jdk7-b50 for changeset dae503d9f04c Message-ID: <20090307194730.14369E9DF@hg.openjdk.java.net> Changeset: 67f831f73d34 Author: xdono Date: 2009-03-05 09:49 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/67f831f73d34 Added tag jdk7-b50 for changeset dae503d9f04c ! .hgtags From tim.bell at sun.com Sat Mar 7 19:54:11 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Sat, 07 Mar 2009 19:54:11 +0000 Subject: hg: jdk7/tl/jaxp: Added tag jdk7-b50 for changeset e8514e2be76d Message-ID: <20090307195413.74EA4E9E4@hg.openjdk.java.net> Changeset: e2da22440463 Author: xdono Date: 2009-03-05 09:49 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/e2da22440463 Added tag jdk7-b50 for changeset e8514e2be76d ! .hgtags From tim.bell at sun.com Sat Mar 7 19:59:11 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Sat, 07 Mar 2009 19:59:11 +0000 Subject: hg: jdk7/tl/jaxws: Added tag jdk7-b50 for changeset 5be52db581f1 Message-ID: <20090307195913.40595E9E9@hg.openjdk.java.net> Changeset: 3f309316d6bf Author: xdono Date: 2009-03-05 09:49 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/3f309316d6bf Added tag jdk7-b50 for changeset 5be52db581f1 ! .hgtags From tim.bell at sun.com Sat Mar 7 20:04:13 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Sat, 07 Mar 2009 20:04:13 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20090307200442.0CD7BE9EE@hg.openjdk.java.net> Changeset: e0a8a9ccc4a4 Author: xdono Date: 2009-03-05 09:49 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e0a8a9ccc4a4 Added tag jdk7-b50 for changeset 58ba2cd5a250 ! .hgtags Changeset: 2b6cf18aeb6f Author: tbell Date: 2009-03-06 10:52 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2b6cf18aeb6f Merge From tim.bell at sun.com Sat Mar 7 20:15:07 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Sat, 07 Mar 2009 20:15:07 +0000 Subject: hg: jdk7/tl/langtools: 2 new changesets Message-ID: <20090307201511.AC9BEE9F3@hg.openjdk.java.net> Changeset: 4b72dc8fc51e Author: xdono Date: 2009-03-05 09:49 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/4b72dc8fc51e Added tag jdk7-b50 for changeset 46f2f6ed96f1 ! .hgtags Changeset: 6d00caa683b3 Author: tbell Date: 2009-03-06 10:53 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/6d00caa683b3 Merge From heiko.wagner at apis.de Mon Mar 9 09:57:16 2009 From: heiko.wagner at apis.de (Heiko Wagner) Date: Mon, 9 Mar 2009 10:57:16 +0100 Subject: RFE 4519026: (process) Process should support Unicode on Win NT, request for review Message-ID: <537D306D9A36468DB3441DD50A9CC6A9@HeikoXP> This is related to my previous post at http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-February/001145.ht ml and my first contribution to the JDK7 project. As Martin suggested, I have worked on a wide char version of ProcessImpl_md.c. For discussion of my proposed chages a copy of my source can be found at: http://www.apis.de/pub/jdk7/ProcessImpl_md.c and a diff at: http://www.apis.de/pub/jdk7/ProcessImpl_md.c This patch enables launching executables residing on a path containing non-ansi characters. My next goal is to get the java launcher working on a unicode path. I think this needs additional coordination with the hotspot team, since some of the code in os.cpp also has issues in a unicode path when loading verify.dll and java.dll. Regards Heiko From sean.mullan at sun.com Mon Mar 9 14:02:32 2009 From: sean.mullan at sun.com (sean.mullan at sun.com) Date: Mon, 09 Mar 2009 14:02:32 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20090309140257.5B3CAEA4B@hg.openjdk.java.net> Changeset: c769c46c27ce Author: mullan Date: 2009-03-09 09:46 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c769c46c27ce 6787130: java.policy file contains stale link to http://java.sun.com/notes Reviewed-by: weijun ! src/share/lib/security/java.policy Changeset: aa48deaf9af4 Author: mullan Date: 2009-03-09 09:56 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/aa48deaf9af4 Merge From Mandy.Chung at Sun.COM Wed Mar 11 17:29:51 2009 From: Mandy.Chung at Sun.COM (Mandy Chung) Date: Wed, 11 Mar 2009 10:29:51 -0700 Subject: Review request for 6810254 (v01) In-Reply-To: <49AF78BA.8010608@sun.com> References: <49AF78BA.8010608@sun.com> Message-ID: <49B7F50F.7050806@Sun.com> David, Alan, Thanks for your feedback. I revise the fix per Alan's suggestion. I decide not to keep the fix to lazily initialize the shutdown hook only. So java.io.Console, DeleteOnExitHook and java.lang.ApplicationShutdownHooks are only loaded when the app uses it. Webrev at: http://cr.openjdk.java.net/~mchung/6810254/webrev.01/ Thanks Mandy On 03/04/09 23:01, Mandy Chung wrote: > 6810254: Lazily instantiate the shared secret access objects > > Webrev at: > http://cr.openjdk.java.net/~mchung/6810254/webrev.00/ > > sun.misc.Java*Access objects are created at initialization time. > However, they are not always needed. They can be instantiated lazily > when needed. The fix is to add a static setSharedSecret() method to be > called by sun.misc.SharedSecrets via reflection when the shared secret > access object is requested. > > Thanks > Mandy From Mandy.Chung at Sun.COM Wed Mar 11 19:07:02 2009 From: Mandy.Chung at Sun.COM (Mandy Chung) Date: Wed, 11 Mar 2009 12:07:02 -0700 Subject: Review request for 6813240 (FormattedFloatingDecimal) Message-ID: <49B80BD6.1090607@Sun.com> 6813240: Remove dead code in sun.misc.FormattedFloatingDecimal class Webrev at: http://cr.openjdk.java.net/~mchung/6813240/webrev.00/ The CR synopsis says it all. Thanks Mandy From Alan.Bateman at Sun.COM Wed Mar 11 20:01:36 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Wed, 11 Mar 2009 20:01:36 +0000 Subject: Review request for 6810254 (v01) In-Reply-To: <49B7F50F.7050806@Sun.com> References: <49AF78BA.8010608@sun.com> <49B7F50F.7050806@Sun.com> Message-ID: <49B818A0.8040703@sun.com> Mandy Chung wrote: > David, Alan, > > Thanks for your feedback. I revise the fix per Alan's suggestion. I > decide not to keep the fix to lazily initialize the shutdown hook > only. So java.io.Console, DeleteOnExitHook and > java.lang.ApplicationShutdownHooks are only loaded when the app uses it. > > Webrev at: > http://cr.openjdk.java.net/~mchung/6810254/webrev.01/ > > Thanks > Mandy This looks a lot better. One suggestion is to reverse the order of the parameters to registerShutdownHook so that the Runnable is last. That would make it easier to read and also easier to see the hook slot which is the fragile part to the solution. Minor nit is that the comment in Shutdown.java reads "The order in with the hooks are added here is important ...". The registration order doesn't matter now so this could be changed. -Alan. From Joe.Darcy at Sun.COM Wed Mar 11 20:27:41 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Wed, 11 Mar 2009 13:27:41 -0700 Subject: Review request for 6813240 (FormattedFloatingDecimal) In-Reply-To: <49B80BD6.1090607@Sun.com> References: <49B80BD6.1090607@Sun.com> Message-ID: <49B81EBD.6030607@sun.com> Looks fine, -Joe Mandy Chung wrote: > 6813240: Remove dead code in sun.misc.FormattedFloatingDecimal class > > Webrev at: > http://cr.openjdk.java.net/~mchung/6813240/webrev.00/ > > The CR synopsis says it all. > > Thanks > Mandy From Mandy.Chung at Sun.COM Wed Mar 11 21:10:40 2009 From: Mandy.Chung at Sun.COM (Mandy Chung) Date: Wed, 11 Mar 2009 14:10:40 -0700 Subject: Review request for 6810254 (v01) In-Reply-To: <49B818A0.8040703@sun.com> References: <49AF78BA.8010608@sun.com> <49B7F50F.7050806@Sun.com> <49B818A0.8040703@sun.com> Message-ID: <49B828D0.9080107@Sun.com> On 03/11/09 13:01, Alan Bateman wrote: > Mandy Chung wrote: >> David, Alan, >> >> Thanks for your feedback. I revise the fix per Alan's suggestion. I >> decide not to keep the fix to lazily initialize the shutdown hook >> only. So java.io.Console, DeleteOnExitHook and >> java.lang.ApplicationShutdownHooks are only loaded when the app uses it. >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/6810254/webrev.01/ >> >> Thanks >> Mandy > This looks a lot better. One suggestion is to reverse the order of the > parameters to registerShutdownHook so that the Runnable is last. That > would make it easier to read and also easier to see the hook slot which > is the fragile part to the solution. Ok. Will change the parameter order. > Minor nit is that the comment in Shutdown.java reads "The order in with > the hooks are added here is important ...". The registration order > doesn't matter now so this could be changed. Right. Will update the comment. Thanks Mandy > -Alan. > > From heiko.wagner at apis.de Thu Mar 12 08:38:34 2009 From: heiko.wagner at apis.de (Heiko Wagner) Date: Thu, 12 Mar 2009 09:38:34 +0100 Subject: RFE 4519026: (process) Process should support Unicode on Win NT, request for review In-Reply-To: <537D306D9A36468DB3441DD50A9CC6A9@HeikoXP> Message-ID: <568DBA2331E347EC9BA2944ED3D09424@HeikoXP> Seemed I had the copy & paste gods against me. The corrct url for the diff is: http://www.apis.de/pub/jdk7/ProcessImpl_md.c.diff Regards Heiko -----Original Message----- From: core-libs-dev-bounces at openjdk.java.net [mailto:core-libs-dev-bounces at openjdk.java.net]On Behalf Of Heiko Wagner Sent: Montag, 9. M?rz 2009 10:57 To: core-libs-dev at openjdk.java.net Subject: RFE 4519026: (process) Process should support Unicode on Win NT,request for review This is related to my previous post at http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-February/001145.ht ml and my first contribution to the JDK7 project. As Martin suggested, I have worked on a wide char version of ProcessImpl_md.c. For discussion of my proposed chages a copy of my source can be found at: http://www.apis.de/pub/jdk7/ProcessImpl_md.c and a diff at: http://www.apis.de/pub/jdk7/ProcessImpl_md.c This patch enables launching executables residing on a path containing non-ansi characters. My next goal is to get the java launcher working on a unicode path. I think this needs additional coordination with the hotspot team, since some of the code in os.cpp also has issues in a unicode path when loading verify.dll and java.dll. Regards Heiko From mandy.chung at sun.com Thu Mar 12 17:39:55 2009 From: mandy.chung at sun.com (mandy.chung at sun.com) Date: Thu, 12 Mar 2009 17:39:55 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20090312174115.DEABFED8E@hg.openjdk.java.net> Changeset: e1064300e0f6 Author: mchung Date: 2009-03-12 10:27 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e1064300e0f6 6810254: Lazily instantiate the shared secret access objects Summary: Register the shutdown hooks only when needed and remove JavaIODeleteOnExitAccess Reviewed-by: alanb ! make/java/java/FILES_java.gmk ! 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/lang/ApplicationShutdownHooks.java ! src/share/classes/java/lang/Shutdown.java ! src/share/classes/java/lang/System.java ! src/share/classes/sun/misc/JavaIOAccess.java - src/share/classes/sun/misc/JavaIODeleteOnExitAccess.java ! src/share/classes/sun/misc/JavaLangAccess.java ! src/share/classes/sun/misc/SharedSecrets.java Changeset: fdb1567ea28c Author: mchung Date: 2009-03-12 10:32 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fdb1567ea28c 6813240: Remove dead code in sun.misc.FormattedFloatingDecimal class Summary: Remove unused methods from FormattedFloatingDecimal that were originally copied from FloatingDecimal Reviewed-by: darcy ! src/share/classes/sun/misc/FormattedFloatingDecimal.java From david.lloyd at redhat.com Thu Mar 12 22:35:53 2009 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 12 Mar 2009 17:35:53 -0500 Subject: [PATCH 1/1] Get rid of synchronization in java.util.logging.LogRecord constructor Message-ID: <49B98E49.6000302@redhat.com> Switch to atomic ops for the various sequence numbers, as opposed to synchronizing on the class object on every object construction. - DML -- diff -r dde3fe2e8164 src/share/classes/java/util/logging/LogRecord.java --- a/src/share/classes/java/util/logging/LogRecord.java Wed Feb 25 14:32:01 2009 +0000 +++ b/src/share/classes/java/util/logging/LogRecord.java Thu Mar 12 17:12:22 2009 -0500 @@ -25,6 +25,8 @@ package java.util.logging; import java.util.*; +import java.util.concurrent.atomic.AtomicLong; +import java.util.concurrent.atomic.AtomicInteger; import java.io.*; /** @@ -64,9 +66,9 @@ */ public class LogRecord implements java.io.Serializable { - private static long globalSequenceNumber; - private static int nextThreadId=10; - private static ThreadLocal threadIds = new ThreadLocal(); + private static final AtomicLong globalSequenceNumber = new AtomicLong(); + private static final AtomicInteger nextThreadId = new AtomicInteger(10); + private static final ThreadLocal threadIds = new ThreadLocal(); /** * @serial Logging message level @@ -144,15 +146,13 @@ this.level = level; message = msg; // Assign a thread ID and a unique sequence number. - synchronized (LogRecord.class) { - sequenceNumber = globalSequenceNumber++; - Integer id = threadIds.get(); - if (id == null) { - id = new Integer(nextThreadId++); - threadIds.set(id); - } - threadID = id.intValue(); + sequenceNumber = globalSequenceNumber.getAndIncrement(); + Integer id = threadIds.get(); + if (id == null) { + id = Integer.valueOf(nextThreadId.getAndIncrement()); + threadIds.set(id); } + threadID = id.intValue(); millis = System.currentTimeMillis(); needToInferCaller = true; } -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: LogRecord.patch URL: From mr at sun.com Thu Mar 12 22:41:25 2009 From: mr at sun.com (Mark Reinhold) Date: Thu, 12 Mar 2009 15:41:25 -0700 Subject: [PATCH 1/1] Get rid of synchronization in java.util.logging.LogRecord constructor In-Reply-To: david.lloyd@redhat.com; Thu, 12 Mar 2009 17:35:53 CDT; <49B98E49.6000302@redhat.com> Message-ID: <20090312224125.AF50E28E0EF@eggemoggin.niobe.net> You might want to have a look at the new contribution process [1]. Using that will increase the probability that someone will evaluate your patch sooner rather than later. - Mark [1] http://openjdk.java.net/contribute From david.lloyd at redhat.com Thu Mar 12 23:10:16 2009 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 12 Mar 2009 18:10:16 -0500 Subject: [PATCH 1/1] Get rid of synchronization in java.util.logging.LogRecord constructor In-Reply-To: <20090312224125.AF50E28E0EF@eggemoggin.niobe.net> References: <20090312224125.AF50E28E0EF@eggemoggin.niobe.net> Message-ID: <49B99658.1000507@redhat.com> On 03/12/2009 05:41 PM, Mark Reinhold wrote: > You might want to have a look at the new contribution process [1]. > Using that will increase the probability that someone will evaluate > your patch sooner rather than later. > > - Mark > > [1] http://openjdk.java.net/contribute Consider my post to be step 2 of that process. The patch itself is probably the most succinct way of expressing the proposed change (it only took a minute or two to write in any case). Anyone have comments on the change? - DML From martinrb at google.com Thu Mar 12 23:46:37 2009 From: martinrb at google.com (Martin Buchholz) Date: Thu, 12 Mar 2009 16:46:37 -0700 Subject: [PATCH 1/1] Get rid of synchronization in java.util.logging.LogRecord constructor In-Reply-To: <49B98E49.6000302@redhat.com> References: <49B98E49.6000302@redhat.com> Message-ID: <1ccfd1c10903121646y53990a92ub025345026ac22d0@mail.gmail.com> This looks fine, as long as there is no dependency of the implementation on the two atomic counters being incremented in concert, as seems likely. Martin On Thu, Mar 12, 2009 at 15:35, David M. Lloyd wrote: > Switch to atomic ops for the various sequence numbers, as opposed to > synchronizing on the class object on every object construction. > > - DML > -- > > diff -r dde3fe2e8164 src/share/classes/java/util/logging/LogRecord.java > --- a/src/share/classes/java/util/logging/LogRecord.java Wed Feb 25 > 14:32:01 2009 +0000 > +++ b/src/share/classes/java/util/logging/LogRecord.java Thu Mar 12 > 17:12:22 2009 -0500 > @@ -25,6 +25,8 @@ > > package java.util.logging; > import java.util.*; > +import java.util.concurrent.atomic.AtomicLong; > +import java.util.concurrent.atomic.AtomicInteger; > import java.io.*; > > /** > @@ -64,9 +66,9 @@ > */ > > public class LogRecord implements java.io.Serializable { > - private static long globalSequenceNumber; > - private static int nextThreadId=10; > - private static ThreadLocal threadIds = new > ThreadLocal(); > + private static final AtomicLong globalSequenceNumber = new > AtomicLong(); > + private static final AtomicInteger nextThreadId = new > AtomicInteger(10); > + private static final ThreadLocal threadIds = new > ThreadLocal(); > > /** > * @serial Logging message level > @@ -144,15 +146,13 @@ > this.level = level; > message = msg; > // Assign a thread ID and a unique sequence number. > - synchronized (LogRecord.class) { > - sequenceNumber = globalSequenceNumber++; > - Integer id = threadIds.get(); > - if (id == null) { > - id = new Integer(nextThreadId++); > - threadIds.set(id); > - } > - threadID = id.intValue(); > + sequenceNumber = globalSequenceNumber.getAndIncrement(); > + Integer id = threadIds.get(); > + if (id == null) { > + id = Integer.valueOf(nextThreadId.getAndIncrement()); > + threadIds.set(id); > } > + threadID = id.intValue(); > millis = System.currentTimeMillis(); > needToInferCaller = true; > } > > diff -r dde3fe2e8164 src/share/classes/java/util/logging/LogRecord.java > --- a/src/share/classes/java/util/logging/LogRecord.java Wed Feb 25 > 14:32:01 2009 +0000 > +++ b/src/share/classes/java/util/logging/LogRecord.java Thu Mar 12 > 17:12:22 2009 -0500 > @@ -25,6 +25,8 @@ > > package java.util.logging; > import java.util.*; > +import java.util.concurrent.atomic.AtomicLong; > +import java.util.concurrent.atomic.AtomicInteger; > import java.io.*; > > /** > @@ -64,9 +66,9 @@ > */ > > public class LogRecord implements java.io.Serializable { > - private static long globalSequenceNumber; > - private static int nextThreadId=10; > - private static ThreadLocal threadIds = new > ThreadLocal(); > + private static final AtomicLong globalSequenceNumber = new > AtomicLong(); > + private static final AtomicInteger nextThreadId = new > AtomicInteger(10); > + private static final ThreadLocal threadIds = new > ThreadLocal(); > > /** > * @serial Logging message level > @@ -144,15 +146,13 @@ > this.level = level; > message = msg; > // Assign a thread ID and a unique sequence number. > - synchronized (LogRecord.class) { > - sequenceNumber = globalSequenceNumber++; > - Integer id = threadIds.get(); > - if (id == null) { > - id = new Integer(nextThreadId++); > - threadIds.set(id); > - } > - threadID = id.intValue(); > + sequenceNumber = globalSequenceNumber.getAndIncrement(); > + Integer id = threadIds.get(); > + if (id == null) { > + id = Integer.valueOf(nextThreadId.getAndIncrement()); > + threadIds.set(id); > } > + threadID = id.intValue(); > millis = System.currentTimeMillis(); > needToInferCaller = true; > } > > From Dalibor.Topic at Sun.COM Fri Mar 13 00:01:36 2009 From: Dalibor.Topic at Sun.COM (Dalibor Topic) Date: Fri, 13 Mar 2009 01:01:36 +0100 Subject: [PATCH 1/1] Get rid of synchronization in java.util.logging.LogRecord constructor In-Reply-To: <49B99658.1000507@redhat.com> References: <20090312224125.AF50E28E0EF@eggemoggin.niobe.net> <49B99658.1000507@redhat.com> Message-ID: <49B9A260.9080700@sun.com> David M. Lloyd wrote: > On 03/12/2009 05:41 PM, Mark Reinhold wrote: >> You might want to have a look at the new contribution process [1]. >> Using that will increase the probability that someone will evaluate >> your patch sooner rather than later. >> >> - Mark >> >> [1] http://openjdk.java.net/contribute > > Consider my post to be step 2 of that process. The patch itself is > probably the most succinct way of expressing the proposed change (it > only took a minute or two to write in any case). That's understandable, but it's a lot easier to find interesting patches to review in a bug tracker, then to search for them among mailing list threads. In other words, if you, say, look at this thread so far in your mail reader, you'd have a hard time figuring out whether someone has reviewed your change or not, without spending the time reading the thread. Since more people end up reading each e-mail then people end up writing each e-mail, it's useful to optimize processes towards avoiding having to read a lot of e-mail in order to figure out simple things. So, please do add your patch to the bug tracker so that it doesn't get lost, and so that others don't have to spend time reading threads full of polite requests to please add your patch to the bug tracker. ;) > Anyone have comments on the change? It seems that the change would break serialization, by changing the type of a serialized field (in both classes) away from a primitive one. See http://java.sun.com/javase/6/docs/platform/serialization/spec/version.html for details. Such comments are, obviously, better preserved in a bug tracker, then in a mailing list thread, but you knew I'd say that, right? ;) cheers, dalibor topic -- ******************************************************************* Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55 http://openjdk.java.net D-20097 Hamburg mailto:Dalibor.Topic at sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht M?nchen: HRB 161028 Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Dr. Roland B?mer Vorsitzender des Aufsichtsrates: Martin H?ring From gnu_andrew at member.fsf.org Fri Mar 13 00:08:56 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 13 Mar 2009 00:08:56 +0000 Subject: [PATCH 1/1] Get rid of synchronization in java.util.logging.LogRecord constructor In-Reply-To: <49B9A260.9080700@sun.com> References: <20090312224125.AF50E28E0EF@eggemoggin.niobe.net> <49B99658.1000507@redhat.com> <49B9A260.9080700@sun.com> Message-ID: <17c6771e0903121708m3d056f59he99e449c64ba59d7@mail.gmail.com> 2009/3/13 Dalibor Topic : > David M. Lloyd wrote: >> On 03/12/2009 05:41 PM, Mark Reinhold wrote: >>> You might want to have a look at the new contribution process [1]. >>> Using that will increase the probability that someone will evaluate >>> your patch sooner rather than later. >>> >>> - Mark >>> >>> [1] http://openjdk.java.net/contribute >> >> Consider my post to be step 2 of that process. ?The patch itself is >> probably the most succinct way of expressing the proposed change (it >> only took a minute or two to write in any case). > > That's understandable, but it's a lot easier to find interesting patches > to review in a bug tracker, then to search for them among mailing list threads. > > In other words, if you, say, look at this thread so far in your mail reader, > you'd have a hard time figuring out whether someone has reviewed your change > or not, without spending the time reading the thread. Since more people end > up reading each e-mail then people end up writing each e-mail, it's useful > to optimize processes towards avoiding having to read a lot of e-mail in > order to figure out simple things. > > So, please do add your patch to the bug tracker so that it doesn't get lost, > and so that others don't have to spend time reading threads full of polite > requests to please add your patch to the bug tracker. ;) > +1 :) And we probably also need to cajole people into adding comments on patches already posted... >> Anyone have comments on the change? > > It seems that the change would break serialization, by changing the type > of a serialized field (in both classes) away from a primitive one. See > http://java.sun.com/javase/6/docs/platform/serialization/spec/version.html > for details. > Except that both fields are static, and static fields aren't serialised by default. http://java.sun.com/javase/6/docs/platform/serialization/spec/serial-arch.html#6250 > Such comments are, obviously, better preserved in a bug tracker, then in > a mailing list thread, but you knew I'd say that, right? ;) > > cheers, > dalibor topic > > -- > ******************************************************************* > Dalibor Topic ? ? ? ? ? ? ? ? ? Tel: (+49 40) 23 646 738 > Java F/OSS Ambassador ? ? ? ? ? AIM: robiladonaim > Sun Microsystems GmbH ? ? ? ? ? Mobile: (+49 177) 2664 192 > Nagelsweg 55 ? ? ? ? ? ? ? ? ? ?http://openjdk.java.net > D-20097 Hamburg ? ? ? ? ? ? ? ? mailto:Dalibor.Topic at sun.com > Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten > Amtsgericht M?nchen: HRB 161028 > Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Dr. Roland B?mer > Vorsitzender des Aufsichtsrates: Martin H?ring > > > -- 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 david.lloyd at redhat.com Fri Mar 13 00:11:38 2009 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 12 Mar 2009 19:11:38 -0500 Subject: [PATCH 1/1] Get rid of synchronization in java.util.logging.LogRecord constructor In-Reply-To: <49B9A260.9080700@sun.com> References: <20090312224125.AF50E28E0EF@eggemoggin.niobe.net> <49B99658.1000507@redhat.com> <49B9A260.9080700@sun.com> Message-ID: <49B9A4BA.1010609@redhat.com> On 03/12/2009 07:01 PM, Dalibor Topic wrote: > David M. Lloyd wrote: >> On 03/12/2009 05:41 PM, Mark Reinhold wrote: >>> You might want to have a look at the new contribution process [1]. >>> Using that will increase the probability that someone will evaluate >>> your patch sooner rather than later. >>> >>> - Mark >>> >>> [1] http://openjdk.java.net/contribute >> Consider my post to be step 2 of that process. The patch itself is >> probably the most succinct way of expressing the proposed change (it >> only took a minute or two to write in any case). > > That's understandable, but it's a lot easier to find interesting patches > to review in a bug tracker, then to search for them among mailing list threads. [...] OK, that's reasonable. Perhaps Step 2 should be switched with Step 3 then on the "contribute" page to make it match up then? > It seems that the change would break serialization, by changing the type > of a serialized field (in both classes) away from a primitive one. See > http://java.sun.com/javase/6/docs/platform/serialization/spec/version.html > for details. The fields are static so it shouldn't matter. - DML From david.lloyd at redhat.com Fri Mar 13 00:12:17 2009 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 12 Mar 2009 19:12:17 -0500 Subject: [PATCH 1/1] Get rid of synchronization in java.util.logging.LogRecord constructor In-Reply-To: <1ccfd1c10903121646y53990a92ub025345026ac22d0@mail.gmail.com> References: <49B98E49.6000302@redhat.com> <1ccfd1c10903121646y53990a92ub025345026ac22d0@mail.gmail.com> Message-ID: <49B9A4E1.5060405@redhat.com> I couldn't think of any situation where there would be. - DML On 03/12/2009 06:46 PM, Martin Buchholz wrote: > This looks fine, as long as there is no dependency of the implementation > on the two atomic counters being incremented in concert, as seems likely. > > Martin > > On Thu, Mar 12, 2009 at 15:35, David M. Lloyd wrote: >> Switch to atomic ops for the various sequence numbers, as opposed to >> synchronizing on the class object on every object construction. >> >> - DML >> -- >> >> diff -r dde3fe2e8164 src/share/classes/java/util/logging/LogRecord.java >> --- a/src/share/classes/java/util/logging/LogRecord.java Wed Feb 25 >> 14:32:01 2009 +0000 >> +++ b/src/share/classes/java/util/logging/LogRecord.java Thu Mar 12 >> 17:12:22 2009 -0500 >> @@ -25,6 +25,8 @@ >> >> package java.util.logging; >> import java.util.*; >> +import java.util.concurrent.atomic.AtomicLong; >> +import java.util.concurrent.atomic.AtomicInteger; >> import java.io.*; >> >> /** >> @@ -64,9 +66,9 @@ >> */ >> >> public class LogRecord implements java.io.Serializable { >> - private static long globalSequenceNumber; >> - private static int nextThreadId=10; >> - private static ThreadLocal threadIds = new >> ThreadLocal(); >> + private static final AtomicLong globalSequenceNumber = new >> AtomicLong(); >> + private static final AtomicInteger nextThreadId = new >> AtomicInteger(10); >> + private static final ThreadLocal threadIds = new >> ThreadLocal(); >> >> /** >> * @serial Logging message level >> @@ -144,15 +146,13 @@ >> this.level = level; >> message = msg; >> // Assign a thread ID and a unique sequence number. >> - synchronized (LogRecord.class) { >> - sequenceNumber = globalSequenceNumber++; >> - Integer id = threadIds.get(); >> - if (id == null) { >> - id = new Integer(nextThreadId++); >> - threadIds.set(id); >> - } >> - threadID = id.intValue(); >> + sequenceNumber = globalSequenceNumber.getAndIncrement(); >> + Integer id = threadIds.get(); >> + if (id == null) { >> + id = Integer.valueOf(nextThreadId.getAndIncrement()); >> + threadIds.set(id); >> } >> + threadID = id.intValue(); >> millis = System.currentTimeMillis(); >> needToInferCaller = true; >> } >> >> diff -r dde3fe2e8164 src/share/classes/java/util/logging/LogRecord.java >> --- a/src/share/classes/java/util/logging/LogRecord.java Wed Feb 25 >> 14:32:01 2009 +0000 >> +++ b/src/share/classes/java/util/logging/LogRecord.java Thu Mar 12 >> 17:12:22 2009 -0500 >> @@ -25,6 +25,8 @@ >> >> package java.util.logging; >> import java.util.*; >> +import java.util.concurrent.atomic.AtomicLong; >> +import java.util.concurrent.atomic.AtomicInteger; >> import java.io.*; >> >> /** >> @@ -64,9 +66,9 @@ >> */ >> >> public class LogRecord implements java.io.Serializable { >> - private static long globalSequenceNumber; >> - private static int nextThreadId=10; >> - private static ThreadLocal threadIds = new >> ThreadLocal(); >> + private static final AtomicLong globalSequenceNumber = new >> AtomicLong(); >> + private static final AtomicInteger nextThreadId = new >> AtomicInteger(10); >> + private static final ThreadLocal threadIds = new >> ThreadLocal(); >> >> /** >> * @serial Logging message level >> @@ -144,15 +146,13 @@ >> this.level = level; >> message = msg; >> // Assign a thread ID and a unique sequence number. >> - synchronized (LogRecord.class) { >> - sequenceNumber = globalSequenceNumber++; >> - Integer id = threadIds.get(); >> - if (id == null) { >> - id = new Integer(nextThreadId++); >> - threadIds.set(id); >> - } >> - threadID = id.intValue(); >> + sequenceNumber = globalSequenceNumber.getAndIncrement(); >> + Integer id = threadIds.get(); >> + if (id == null) { >> + id = Integer.valueOf(nextThreadId.getAndIncrement()); >> + threadIds.set(id); >> } >> + threadID = id.intValue(); >> millis = System.currentTimeMillis(); >> needToInferCaller = true; >> } >> >> From gnu_andrew at member.fsf.org Fri Mar 13 00:13:39 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 13 Mar 2009 00:13:39 +0000 Subject: [PATCH 1/1] Get rid of synchronization in java.util.logging.LogRecord constructor In-Reply-To: <1ccfd1c10903121646y53990a92ub025345026ac22d0@mail.gmail.com> References: <49B98E49.6000302@redhat.com> <1ccfd1c10903121646y53990a92ub025345026ac22d0@mail.gmail.com> Message-ID: <17c6771e0903121713h41a6c302h6b3899b765ebcd0f@mail.gmail.com> 2009/3/12 Martin Buchholz : > This looks fine, as long as there is no dependency of the implementation > on the two atomic counters being incremented in concert, as seems likely. > > Martin > > On Thu, Mar 12, 2009 at 15:35, David M. Lloyd wrote: >> Switch to atomic ops for the various sequence numbers, as opposed to >> synchronizing on the class object on every object construction. >> >> - DML >> -- >> >> diff -r dde3fe2e8164 src/share/classes/java/util/logging/LogRecord.java >> --- a/src/share/classes/java/util/logging/LogRecord.java ? ? ? ?Wed Feb 25 >> 14:32:01 2009 +0000 >> +++ b/src/share/classes/java/util/logging/LogRecord.java ? ? ? ?Thu Mar 12 >> 17:12:22 2009 -0500 >> @@ -25,6 +25,8 @@ >> >> ?package java.util.logging; >> ?import java.util.*; >> +import java.util.concurrent.atomic.AtomicLong; >> +import java.util.concurrent.atomic.AtomicInteger; >> ?import java.io.*; >> >> ?/** >> @@ -64,9 +66,9 @@ >> ?*/ >> >> ?public class LogRecord implements java.io.Serializable { >> - ? ?private static long globalSequenceNumber; >> - ? ?private static int nextThreadId=10; >> - ? ?private static ThreadLocal threadIds = new >> ThreadLocal(); >> + ? ?private static final AtomicLong globalSequenceNumber = new >> AtomicLong(); >> + ? ?private static final AtomicInteger nextThreadId = new >> AtomicInteger(10); >> + ? ?private static final ThreadLocal threadIds = new >> ThreadLocal(); >> >> ? ? /** >> ? ? ?* @serial Logging message level >> @@ -144,15 +146,13 @@ >> ? ? ? ? this.level = level; >> ? ? ? ? message = msg; >> ? ? ? ? // Assign a thread ID and a unique sequence number. >> - ? ? ? ?synchronized (LogRecord.class) { >> - ? ? ? ? ? ?sequenceNumber = globalSequenceNumber++; >> - ? ? ? ? ? ?Integer id = threadIds.get(); >> - ? ? ? ? ? ?if (id == null) { >> - ? ? ? ? ? ? ? ?id = new Integer(nextThreadId++); >> - ? ? ? ? ? ? ? ?threadIds.set(id); >> - ? ? ? ? ? ?} >> - ? ? ? ? ? ?threadID = id.intValue(); >> + ? ? ? ?sequenceNumber = globalSequenceNumber.getAndIncrement(); >> + ? ? ? ?Integer id = threadIds.get(); >> + ? ? ? ?if (id == null) { >> + ? ? ? ? ? ?id = Integer.valueOf(nextThreadId.getAndIncrement()); >> + ? ? ? ? ? ?threadIds.set(id); >> ? ? ? ? } >> + ? ? ? ?threadID = id.intValue(); >> ? ? ? ? millis = System.currentTimeMillis(); >> ? ? ? ? needToInferCaller = true; >> ? ?} >> >> diff -r dde3fe2e8164 src/share/classes/java/util/logging/LogRecord.java >> --- a/src/share/classes/java/util/logging/LogRecord.java ? ? ? ?Wed Feb 25 >> 14:32:01 2009 +0000 >> +++ b/src/share/classes/java/util/logging/LogRecord.java ? ? ? ?Thu Mar 12 >> 17:12:22 2009 -0500 >> @@ -25,6 +25,8 @@ >> >> ?package java.util.logging; >> ?import java.util.*; >> +import java.util.concurrent.atomic.AtomicLong; >> +import java.util.concurrent.atomic.AtomicInteger; >> ?import java.io.*; >> >> ?/** >> @@ -64,9 +66,9 @@ >> ?*/ >> >> ?public class LogRecord implements java.io.Serializable { >> - ? ?private static long globalSequenceNumber; >> - ? ?private static int nextThreadId=10; >> - ? ?private static ThreadLocal threadIds = new >> ThreadLocal(); >> + ? ?private static final AtomicLong globalSequenceNumber = new >> AtomicLong(); >> + ? ?private static final AtomicInteger nextThreadId = new >> AtomicInteger(10); >> + ? ?private static final ThreadLocal threadIds = new >> ThreadLocal(); >> >> ? ? /** >> ? ? ?* @serial Logging message level >> @@ -144,15 +146,13 @@ >> ? ? ? ? this.level = level; >> ? ? ? ? message = msg; >> ? ? ? ? // Assign a thread ID and a unique sequence number. >> - ? ? ? ?synchronized (LogRecord.class) { >> - ? ? ? ? ? ?sequenceNumber = globalSequenceNumber++; >> - ? ? ? ? ? ?Integer id = threadIds.get(); >> - ? ? ? ? ? ?if (id == null) { >> - ? ? ? ? ? ? ? ?id = new Integer(nextThreadId++); >> - ? ? ? ? ? ? ? ?threadIds.set(id); >> - ? ? ? ? ? ?} >> - ? ? ? ? ? ?threadID = id.intValue(); >> + ? ? ? ?sequenceNumber = globalSequenceNumber.getAndIncrement(); >> + ? ? ? ?Integer id = threadIds.get(); >> + ? ? ? ?if (id == null) { >> + ? ? ? ? ? ?id = Integer.valueOf(nextThreadId.getAndIncrement()); >> + ? ? ? ? ? ?threadIds.set(id); >> ? ? ? ? } >> + ? ? ? ?threadID = id.intValue(); >> ? ? ? ? millis = System.currentTimeMillis(); >> ? ? ? ? needToInferCaller = true; >> ? ?} >> >> > This is actually an interesting rare case where two atomic variables can replace a synchronised block. Looking at the code, there seems to be no issue with the thread being descheduled and then resumed during the operation of this constructor. Both atomic variables are only used within the constructor. The global sequence number is incremented and retrieve atomically and then assigned to a local variable. The rest of the code deals with allocating an ID to the thread creating the LogRequest object and doesn't depend on the global sequence number, so it doesn't matter if this is incremented by another thread before the constructor completes. Note that Thread.currentThread.getId() now provides an identifier for threads as well, but this will reuse the identifiers of dead threads and could thus lead to possible confusion between log messages. -- 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 gnu_andrew at member.fsf.org Fri Mar 13 00:16:19 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 13 Mar 2009 00:16:19 +0000 Subject: [PATCH 1/1] Get rid of synchronization in java.util.logging.LogRecord constructor In-Reply-To: <49B9A4BA.1010609@redhat.com> References: <20090312224125.AF50E28E0EF@eggemoggin.niobe.net> <49B99658.1000507@redhat.com> <49B9A260.9080700@sun.com> <49B9A4BA.1010609@redhat.com> Message-ID: <17c6771e0903121716o4c3506eay7ea7c202cba01c0f@mail.gmail.com> 2009/3/13 David M. Lloyd : > On 03/12/2009 07:01 PM, Dalibor Topic wrote: >> >> David M. Lloyd wrote: >>> >>> On 03/12/2009 05:41 PM, Mark Reinhold wrote: >>>> >>>> You might want to have a look at the new contribution process [1]. >>>> Using that will increase the probability that someone will evaluate >>>> your patch sooner rather than later. >>>> >>>> - Mark >>>> >>>> [1] http://openjdk.java.net/contribute >>> >>> Consider my post to be step 2 of that process. ?The patch itself is >>> probably the most succinct way of expressing the proposed change (it >>> only took a minute or two to write in any case). >> >> That's understandable, but it's a lot easier to find interesting patches >> to review in a bug tracker, then to search for them among mailing list >> threads. > > [...] > > OK, that's reasonable. ?Perhaps Step 2 should be switched with Step 3 then > on the "contribute" page to make it match up then? > I think it's more the case that step 2 is unnecessary for such a specific case. It applies more to a situation where the implementation would take a significant amount of time, such that it should first be discussed to avoid wasted time and/or work duplication. >> It seems that the change would break serialization, by changing the type >> of a serialized field (in both classes) away from a primitive one. See >> http://java.sun.com/javase/6/docs/platform/serialization/spec/version.html >> for details. > > The fields are static so it shouldn't matter. > > - DML > -- 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 david.lloyd at redhat.com Fri Mar 13 00:16:48 2009 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 12 Mar 2009 19:16:48 -0500 Subject: [PATCH 1/1] Get rid of synchronization in java.util.logging.LogRecord constructor In-Reply-To: <17c6771e0903121713h41a6c302h6b3899b765ebcd0f@mail.gmail.com> References: <49B98E49.6000302@redhat.com> <1ccfd1c10903121646y53990a92ub025345026ac22d0@mail.gmail.com> <17c6771e0903121713h41a6c302h6b3899b765ebcd0f@mail.gmail.com> Message-ID: <49B9A5F0.9040103@redhat.com> On 03/12/2009 07:13 PM, Andrew John Hughes wrote: > This is actually an interesting rare case where two atomic variables > can replace a synchronised block. Looking at the code, there seems to > be no issue with the thread being descheduled and then resumed during > the operation of this constructor. Both atomic variables are only > used within the constructor. The global sequence number is > incremented and retrieve atomically and then assigned to a local > variable. The rest of the code deals with allocating an ID to the > thread creating the LogRequest object and doesn't depend on the global > sequence number, so it doesn't matter if this is incremented by > another thread before the constructor completes. Note that > Thread.currentThread.getId() now provides an identifier for threads as > well, but this will reuse the identifiers of dead threads and could > thus lead to possible confusion between log messages. Yeah, while I did find that having a separate global notion of thread IDs (that starts with 10 no less) was odd, I didn't want to change behavior and I could not think of a reason to do so, so I retained that notion. - DML From gnu_andrew at member.fsf.org Fri Mar 13 00:21:12 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 13 Mar 2009 00:21:12 +0000 Subject: [PATCH 1/1] Get rid of synchronization in java.util.logging.LogRecord constructor In-Reply-To: <49B9A5F0.9040103@redhat.com> References: <49B98E49.6000302@redhat.com> <1ccfd1c10903121646y53990a92ub025345026ac22d0@mail.gmail.com> <17c6771e0903121713h41a6c302h6b3899b765ebcd0f@mail.gmail.com> <49B9A5F0.9040103@redhat.com> Message-ID: <17c6771e0903121721x153d1c07pf268fb3b0f739a2a@mail.gmail.com> 2009/3/13 David M. Lloyd : > On 03/12/2009 07:13 PM, Andrew John Hughes wrote: >> >> This is actually an interesting rare case where two atomic variables >> can replace a synchronised block. ?Looking at the code, there seems to >> be no issue with the thread being descheduled and then resumed during >> the operation of this constructor. ?Both atomic variables are only >> used within the constructor. ?The global sequence number is >> incremented and retrieve atomically and then assigned to a local >> variable. ?The rest of the code deals with allocating an ID to the >> thread creating the LogRequest object and doesn't depend on the global >> sequence number, so it doesn't matter if this is incremented by >> another thread before the constructor completes. ?Note that >> Thread.currentThread.getId() now provides an identifier for threads as >> well, but this will reuse the identifiers of dead threads and could >> thus lead to possible confusion between log messages. > > Yeah, while I did find that having a separate global notion of thread IDs > (that starts with 10 no less) was odd, I didn't want to change behavior and > I could not think of a reason to do so, so I retained that notion. > > - DML > I agree. I also noticed that Thread uses a synchronised block to do the increment rather than the atomic. I don't know if there'd be any advantage to changing it or whether there is a good reason it was done like that. -- 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 david.lloyd at redhat.com Fri Mar 13 00:22:33 2009 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 12 Mar 2009 19:22:33 -0500 Subject: [PATCH 1/1] Get rid of synchronization in java.util.logging.LogRecord constructor In-Reply-To: <49B98E49.6000302@redhat.com> References: <49B98E49.6000302@redhat.com> Message-ID: <49B9A749.40301@redhat.com> Opened as a BugZilla bug: https://bugs.openjdk.java.net/show_bug.cgi?id=100021 - DML On 03/12/2009 05:35 PM, David M. Lloyd wrote: > Switch to atomic ops for the various sequence numbers, as opposed to > synchronizing on the class object on every object construction. From Dalibor.Topic at Sun.COM Fri Mar 13 00:26:38 2009 From: Dalibor.Topic at Sun.COM (Dalibor Topic) Date: Fri, 13 Mar 2009 01:26:38 +0100 Subject: [PATCH 1/1] Get rid of synchronization in java.util.logging.LogRecord constructor In-Reply-To: <49B9A4BA.1010609@redhat.com> References: <20090312224125.AF50E28E0EF@eggemoggin.niobe.net> <49B99658.1000507@redhat.com> <49B9A260.9080700@sun.com> <49B9A4BA.1010609@redhat.com> Message-ID: <49B9A83E.5060902@sun.com> David M. Lloyd wrote: > >> It seems that the change would break serialization, by changing the type >> of a serialized field (in both classes) away from a primitive one. See >> http://java.sun.com/javase/6/docs/platform/serialization/spec/version.html >> >> for details. > > The fields are static so it shouldn't matter. > That's what I get for posting on technical matters after midnight ... ;) cheers, dalibor topic -- ******************************************************************* Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55 http://openjdk.java.net D-20097 Hamburg mailto:Dalibor.Topic at sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht M?nchen: HRB 161028 Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Dr. Roland B?mer Vorsitzender des Aufsichtsrates: Martin H?ring From gnu_andrew at member.fsf.org Fri Mar 13 00:34:16 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 13 Mar 2009 00:34:16 +0000 Subject: [PATCH 1/1] Get rid of synchronization in java.util.logging.LogRecord constructor In-Reply-To: <49B9A83E.5060902@sun.com> References: <20090312224125.AF50E28E0EF@eggemoggin.niobe.net> <49B99658.1000507@redhat.com> <49B9A260.9080700@sun.com> <49B9A4BA.1010609@redhat.com> <49B9A83E.5060902@sun.com> Message-ID: <17c6771e0903121734s60fd885eu9279ebe0f85eea5f@mail.gmail.com> 2009/3/13 Dalibor Topic : > David M. Lloyd wrote: >> >>> It seems that the change would break serialization, by changing the type >>> of a serialized field (in both classes) away from a primitive one. See >>> http://java.sun.com/javase/6/docs/platform/serialization/spec/version.html >>> >>> for details. >> >> The fields are static so it shouldn't matter. >> > > That's what I get for posting on technical matters after midnight ... ;) > So you turn into a pumpkin then as well? ;) > cheers, > dalibor topic > -- > ******************************************************************* > Dalibor Topic ? ? ? ? ? ? ? ? ? Tel: (+49 40) 23 646 738 > Java F/OSS Ambassador ? ? ? ? ? AIM: robiladonaim > Sun Microsystems GmbH ? ? ? ? ? Mobile: (+49 177) 2664 192 > Nagelsweg 55 ? ? ? ? ? ? ? ? ? ?http://openjdk.java.net > D-20097 Hamburg ? ? ? ? ? ? ? ? mailto:Dalibor.Topic at sun.com > Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten > Amtsgericht M?nchen: HRB 161028 > Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Dr. Roland B?mer > Vorsitzender des Aufsichtsrates: Martin H?ring > > > -- 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 martinrb at google.com Fri Mar 13 00:37:41 2009 From: martinrb at google.com (Martin Buchholz) Date: Thu, 12 Mar 2009 17:37:41 -0700 Subject: [PATCH 1/1] Get rid of synchronization in java.util.logging.LogRecord constructor In-Reply-To: <17c6771e0903121721x153d1c07pf268fb3b0f739a2a@mail.gmail.com> References: <49B98E49.6000302@redhat.com> <1ccfd1c10903121646y53990a92ub025345026ac22d0@mail.gmail.com> <17c6771e0903121713h41a6c302h6b3899b765ebcd0f@mail.gmail.com> <49B9A5F0.9040103@redhat.com> <17c6771e0903121721x153d1c07pf268fb3b0f739a2a@mail.gmail.com> Message-ID: <1ccfd1c10903121737y6ad7b3a4xd0632f6d649b163d@mail.gmail.com> On Thu, Mar 12, 2009 at 17:21, Andrew John Hughes wrote: > I agree. I also noticed that Thread uses a synchronised block to do > the increment rather than the atomic. I don't know if there'd be any > advantage to changing it or whether there is a good reason it was done > like that. java.lang.Thread should utilize Atomics for global counters Category http://bugs.sun.com/view_bug.do?bug_id=6741261 I tried to replace the use of static synchronized with Atomics in Thread.java, but there was a circular static initialization dependency, so I gave up. David Holmes, you might want to close 6741261as Will Not Fix. Or Andrew, you might want to prove me wrong and implement it properly. It's probably not worth it - thread creation is going to be slow no matter what, so the global lock is unlikely to be contended. Martin From weijun.wang at sun.com Fri Mar 13 01:28:14 2009 From: weijun.wang at sun.com (weijun.wang at sun.com) Date: Fri, 13 Mar 2009 01:28:14 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20090313012920.A3A5DEDD3@hg.openjdk.java.net> Changeset: 9d5cce463fa0 Author: weijun Date: 2009-03-13 09:20 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9d5cce463fa0 6815182: GSSAPI/SPNEGO does not work with server using MIT Kerberos library Reviewed-by: valeriep ! src/share/classes/sun/security/jgss/spnego/NegTokenInit.java ! src/share/classes/sun/security/jgss/spnego/SpNegoContext.java + test/sun/security/krb5/auto/SpnegoReqFlags.java Changeset: ef3eba839fb7 Author: weijun Date: 2009-03-13 09:21 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ef3eba839fb7 6550221: jaas, jgss and smartcardio javadoc files do not contain Copyrights Reviewed-by: ohair ! make/docs/Makefile From David.Holmes at Sun.COM Fri Mar 13 02:06:47 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Fri, 13 Mar 2009 12:06:47 +1000 Subject: [PATCH 1/1] Get rid of synchronization in java.util.logging.LogRecord constructor In-Reply-To: <1ccfd1c10903121737y6ad7b3a4xd0632f6d649b163d@mail.gmail.com> References: <49B98E49.6000302@redhat.com> <1ccfd1c10903121646y53990a92ub025345026ac22d0@mail.gmail.com> <17c6771e0903121713h41a6c302h6b3899b765ebcd0f@mail.gmail.com> <49B9A5F0.9040103@redhat.com> <17c6771e0903121721x153d1c07pf268fb3b0f739a2a@mail.gmail.com> <1ccfd1c10903121737y6ad7b3a4xd0632f6d649b163d@mail.gmail.com> Message-ID: <49B9BFB7.2020203@sun.com> Martin, I was thinking we could special case the first thread and have it do the initialization when "safe". (The first thread is the only case where it appears to be its own parent, or in other words, where Thread.currentThread()==this. But let's not hijack this thread for this discussion. Cheers, David Martin Buchholz said the following on 03/13/09 10:37: > On Thu, Mar 12, 2009 at 17:21, Andrew John Hughes > wrote: >> I agree. I also noticed that Thread uses a synchronised block to do >> the increment rather than the atomic. I don't know if there'd be any >> advantage to changing it or whether there is a good reason it was done >> like that. > > java.lang.Thread should utilize Atomics for global counters > Category > http://bugs.sun.com/view_bug.do?bug_id=6741261 > > I tried to replace the use of static synchronized with Atomics in Thread.java, > but there was a circular static initialization dependency, so I gave up. > > David Holmes, you might want to close 6741261as Will Not Fix. > > Or Andrew, you might want to prove me wrong and implement it properly. > It's probably not worth it - thread creation is going to be slow no matter what, > so the global lock is unlikely to be contended. > > Martin From David.Holmes at Sun.COM Fri Mar 13 02:14:34 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Fri, 13 Mar 2009 12:14:34 +1000 Subject: [PATCH 1/1] Get rid of synchronization in java.util.logging.LogRecord constructor In-Reply-To: <17c6771e0903121713h41a6c302h6b3899b765ebcd0f@mail.gmail.com> References: <49B98E49.6000302@redhat.com> <1ccfd1c10903121646y53990a92ub025345026ac22d0@mail.gmail.com> <17c6771e0903121713h41a6c302h6b3899b765ebcd0f@mail.gmail.com> Message-ID: <49B9C18A.4000602@sun.com> Andrew John Hughes said the following on 03/13/09 10:13: > The rest of the code deals with allocating an ID to the > thread creating the LogRequest object and doesn't depend on the global > sequence number, so it doesn't matter if this is incremented by > another thread before the constructor completes. Note that > Thread.currentThread.getId() now provides an identifier for threads as > well, but this will reuse the identifiers of dead threads and could > thus lead to possible confusion between log messages. Both "thread ids" simply increment an integer. The Thread ID will wrap sooner than the Logger thread ID simply because not all threads will use the logger. But I don't think wrapping is a practical concern in either case. Still, gratuitous changes seem to always have unintended consequences to some piece of code somewhere, so I wouldn't worry about trying to reuse the Thread getId() here. David Holmes From xuelei.fan at sun.com Fri Mar 13 05:20:06 2009 From: xuelei.fan at sun.com (xuelei.fan at sun.com) Date: Fri, 13 Mar 2009 05:20:06 +0000 Subject: hg: jdk7/tl/jdk: 6798714: OCSPResponse class has to check the validity of signing certificate for OCSP response Message-ID: <20090313052041.01D64EE0A@hg.openjdk.java.net> Changeset: f381e737916d Author: xuelei Date: 2009-03-13 12:59 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f381e737916d 6798714: OCSPResponse class has to check the validity of signing certificate for OCSP response Summary: checking validity and ocsp-nocheck extension. Reviewed-by: mullan, vinnie ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java + src/share/classes/sun/security/x509/OCSPNoCheckExtension.java ! src/share/classes/sun/security/x509/OIDMap.java ! src/share/classes/sun/security/x509/PKIXExtensions.java From tim.bell at sun.com Sun Mar 15 17:14:58 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Sun, 15 Mar 2009 17:14:58 +0000 Subject: hg: jdk7/tl: 5 new changesets Message-ID: <20090315171458.B2A8CEF7E@hg.openjdk.java.net> Changeset: 3398ae556a2a Author: ohair Date: 2009-01-31 15:26 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/3398ae556a2a 6791649: add "SKIP_MSIVAL2=true" to the Windows section of make/jprt.config Reviewed-by: tbell ! make/jdk-rules.gmk ! make/jprt.config ! make/jprt.gmk Changeset: a4fd1a33eb93 Author: xdono Date: 2009-02-27 15:12 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/a4fd1a33eb93 Merge Changeset: c2a7f3471532 Author: xdono Date: 2009-03-09 11:43 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/c2a7f3471532 Merge Changeset: 93c2600a45a4 Author: xdono Date: 2009-03-09 13:28 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/93c2600a45a4 6814575: Update copyright year Summary: Update copyright for files that have been modified in 2009, up to 03/09 Reviewed-by: katleman, tbell, ohair ! Makefile ! make/Defs-internal.gmk ! make/jdk-rules.gmk ! make/jprt.config ! make/jprt.gmk Changeset: 0f0189d55ce4 Author: xdono Date: 2009-03-09 13:33 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/0f0189d55ce4 Merge From tim.bell at sun.com Sun Mar 15 17:18:02 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Sun, 15 Mar 2009 17:18:02 +0000 Subject: hg: jdk7/tl/corba: 3 new changesets Message-ID: <20090315171806.2548CEF83@hg.openjdk.java.net> Changeset: e2f388853a9d Author: xdono Date: 2009-03-09 13:28 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/e2f388853a9d 6814575: Update copyright year Summary: Update copyright for files that have been modified in 2009, up to 03/09 Reviewed-by: katleman, tbell, ohair ! make/com/sun/corba/minclude/com_sun_corba_se_impl_dynamicany.jmk ! make/com/sun/corba/minclude/com_sun_corba_se_impl_encoding.jmk ! make/com/sun/corba/minclude/com_sun_corba_se_impl_ior.jmk ! make/com/sun/corba/minclude/com_sun_corba_se_impl_orbutil.jmk ! make/com/sun/corba/minclude/com_sun_corba_se_impl_protocol.jmk ! make/com/sun/corba/minclude/com_sun_corba_se_spi_legacy_interceptor.jmk ! make/com/sun/corba/minclude/com_sun_corba_se_spi_monitoring.jmk ! make/com/sun/corba/minclude/com_sun_corba_se_spi_presentation_rmi.jmk ! make/com/sun/corba/minclude/com_sun_corba_se_spi_transport.jmk ! make/com/sun/corba/minclude/org_omg_CosNaming.jmk ! make/com/sun/corba/minclude/org_omg_DynamicAny.jmk ! make/com/sun/corba/minclude/org_omg_PortableInterceptor.jmk ! make/com/sun/corba/se/sources/Makefile ! make/common/Defs-windows.gmk ! make/common/shared/Compiler-msvc.gmk ! make/common/shared/Compiler-sun.gmk ! make/common/shared/Defs-utils.gmk ! make/common/shared/Defs.gmk ! make/javax/xa/Makefile ! make/jprt.config ! make/org/omg/CORBA/Makefile ! src/share/classes/org/omg/CORBA/ir.idl ! src/share/classes/org/omg/DynamicAny/DynamicAny.idl Changeset: 3174f87bcd7c Author: xdono Date: 2009-03-09 13:33 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/3174f87bcd7c Merge Changeset: c471ac1a1770 Author: tbell Date: 2009-03-09 23:36 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/c471ac1a1770 Merge From tim.bell at sun.com Sun Mar 15 17:23:51 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Sun, 15 Mar 2009 17:23:51 +0000 Subject: hg: jdk7/tl/hotspot: 5 new changesets Message-ID: <20090315172403.936C8EF88@hg.openjdk.java.net> Changeset: 69c752d99841 Author: ohair Date: 2009-01-31 17:19 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/69c752d99841 6799141: Build with --hash-style=both so that binaries can work on SuSE 10 Reviewed-by: tbell ! make/linux/makefiles/gcc.make Changeset: f9d5cfc2afa2 Author: xdono Date: 2009-02-27 15:13 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f9d5cfc2afa2 Merge Changeset: f5eac45b1641 Author: xdono Date: 2009-03-09 11:43 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f5eac45b1641 Merge Changeset: 0fbdb4381b99 Author: xdono Date: 2009-03-09 13:28 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0fbdb4381b99 6814575: Update copyright year Summary: Update copyright for files that have been modified in 2009, up to 03/09 Reviewed-by: katleman, tbell, ohair ! agent/src/os/linux/ps_core.c ! agent/src/os/solaris/proc/saproc.cpp ! make/hotspot_version ! make/linux/makefiles/adlc.make ! make/linux/makefiles/gcc.make ! make/solaris/makefiles/adlc.make ! src/cpu/sparc/vm/jni_sparc.h ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/bytecodeInterpreter_x86.inline.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interpreterRT_x86_32.cpp ! src/cpu/x86/vm/jni_x86.h ! src/cpu/x86/vm/runtime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/solaris_x86_32.il ! src/os_cpu/solaris_x86/vm/solaris_x86_64.il ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/adlparse.hpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/dfa.cpp ! src/share/vm/adlc/dict2.cpp ! src/share/vm/adlc/filebuff.hpp ! src/share/vm/adlc/forms.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.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/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1MMUTracker.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/g1_specialized_oop_closures.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp ! src/share/vm/gc_implementation/g1/survRateGroup.cpp ! src/share/vm/gc_implementation/g1/survRateGroup.hpp ! src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep ! src/share/vm/gc_implementation/includeDB_gc_g1 ! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge ! src/share/vm/gc_implementation/includeDB_gc_shared ! src/share/vm/gc_implementation/parNew/parGCAllocBuffer.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.cpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psVirtualspace.cpp ! src/share/vm/gc_implementation/parallelScavenge/psVirtualspace.hpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.cpp ! src/share/vm/gc_implementation/shared/ageTable.cpp ! src/share/vm/gc_implementation/shared/ageTable.hpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.hpp ! src/share/vm/gc_implementation/shared/mutableSpace.cpp ! src/share/vm/gc_implementation/shared/mutableSpace.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/includeDB_compiler2 ! src/share/vm/includeDB_core ! src/share/vm/includeDB_features ! src/share/vm/includeDB_gc ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodeInterpreter.hpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/libadt/dict.cpp ! src/share/vm/libadt/port.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/generation.cpp ! src/share/vm/memory/generation.hpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/memory/permGen.cpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/sharedHeap.hpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/memory/tenuredGeneration.cpp ! src/share/vm/memory/threadLocalAllocBuffer.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/arrayOop.hpp ! src/share/vm/oops/constMethodKlass.cpp ! src/share/vm/oops/constMethodKlass.hpp ! src/share/vm/oops/constMethodOop.hpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/constantPoolKlass.hpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/cpCacheKlass.cpp ! src/share/vm/oops/cpCacheKlass.hpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/oops/oopsHierarchy.hpp ! src/share/vm/oops/typeArrayKlass.cpp ! src/share/vm/oops/typeArrayKlass.hpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/opto/vectornode.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/memprofiler.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/management.cpp ! src/share/vm/utilities/globalDefinitions_gcc.hpp ! src/share/vm/utilities/globalDefinitions_sparcWorks.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/taskqueue.cpp ! src/share/vm/utilities/taskqueue.hpp ! src/share/vm/utilities/vmError.cpp ! src/share/vm/utilities/vmError.hpp ! src/share/vm/utilities/workgroup.hpp ! test/Makefile ! test/compiler/6757316/Test6757316.java ! test/compiler/6758234/Test6758234.java ! test/compiler/6775880/Test.java ! test/compiler/6778657/Test.java Changeset: ce2272390558 Author: xdono Date: 2009-03-09 13:34 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ce2272390558 Merge From tim.bell at sun.com Sun Mar 15 17:27:11 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Sun, 15 Mar 2009 17:27:11 +0000 Subject: hg: jdk7/tl/jaxp: 2 new changesets Message-ID: <20090315172715.64A38EF8D@hg.openjdk.java.net> Changeset: 6698e1f801df Author: xdono Date: 2009-03-09 13:28 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/6698e1f801df 6814575: Update copyright year Summary: Update copyright for files that have been modified in 2009, up to 03/09 Reviewed-by: katleman, tbell, ohair ! make/Makefile Changeset: ae890d80d5df Author: xdono Date: 2009-03-09 13:34 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/ae890d80d5df Merge From tim.bell at sun.com Sun Mar 15 17:30:19 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Sun, 15 Mar 2009 17:30:19 +0000 Subject: hg: jdk7/tl/jaxws: 2 new changesets Message-ID: <20090315173022.8B7DAEF92@hg.openjdk.java.net> Changeset: d1525894c1a8 Author: xdono Date: 2009-03-09 13:28 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/d1525894c1a8 6814575: Update copyright year Summary: Update copyright for files that have been modified in 2009, up to 03/09 Reviewed-by: katleman, tbell, ohair ! make/Makefile Changeset: 41a66a42791b Author: xdono Date: 2009-03-09 13:34 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/41a66a42791b Merge From tim.bell at sun.com Sun Mar 15 17:34:18 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Sun, 15 Mar 2009 17:34:18 +0000 Subject: hg: jdk7/tl/jdk: 9 new changesets Message-ID: <20090315173626.2195CEF97@hg.openjdk.java.net> Changeset: 30bf00392b6d Author: ohair Date: 2009-01-31 17:31 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/30bf00392b6d 6799141: Build with --hash-style=both so that binaries can work on SuSE 10 Reviewed-by: tbell ! make/common/Defs-linux.gmk ! make/common/shared/Compiler-gcc.gmk ! make/common/shared/Compiler-msvc.gmk ! make/common/shared/Compiler-sun.gmk + make/common/shared/Defs-versions.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Defs.gmk ! make/common/shared/Platform.gmk ! make/common/shared/Sanity-Settings.gmk ! make/common/shared/Sanity.gmk Changeset: dfb5a9a71c1c Author: xdono Date: 2009-02-27 15:13 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dfb5a9a71c1c Merge - make/javax/sound/jsoundhs/FILES.gmk - make/javax/sound/jsoundhs/Makefile - make/javax/sound/jsoundhs/mapfile-vers - src/share/classes/com/sun/beans/ObjectHandler.java - src/share/lib/audio/soundbank.gm - src/windows/native/sun/windows/UnicowsLoader.cpp - src/windows/native/sun/windows/UnicowsLoader.h - src/windows/native/sun/windows/awt_MMStub.cpp - src/windows/native/sun/windows/awt_MMStub.h - src/windows/native/sun/windows/awt_Multimon.h - src/windows/native/sun/windows/awt_Unicode.cpp - src/windows/native/sun/windows/awt_Unicode.h - src/windows/native/sun/windows/awt_dlls.cpp - src/windows/native/sun/windows/awt_dlls.h Changeset: d71e3cc6c4e7 Author: xdono Date: 2009-02-27 15:55 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d71e3cc6c4e7 Merge - src/solaris/classes/sun/nio/ch/FileDispatcher.java - src/solaris/native/sun/nio/ch/FileDispatcher.c - src/windows/classes/sun/nio/ch/FileDispatcher.java - src/windows/native/sun/nio/ch/FileDispatcher.c Changeset: abfccc052872 Author: xdono Date: 2009-03-03 15:21 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/abfccc052872 Merge Changeset: 83c0526fb9c9 Author: xdono Date: 2009-03-09 11:43 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/83c0526fb9c9 Merge Changeset: ca0976a15868 Author: xdono Date: 2009-03-09 13:29 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ca0976a15868 6814575: Update copyright year Summary: Update copyright for files that have been modified in 2009, up to 03/09 Reviewed-by: katleman, tbell, ohair ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/util/regex/Matcher.java ! src/share/classes/java/util/regex/Pattern.java ! src/share/classes/sun/security/krb5/Realm.java ! src/share/classes/sun/security/x509/AuthorityInfoAccessExtension.java ! src/share/native/java/util/zip/zip_util.c ! src/share/native/java/util/zip/zip_util.h ! src/solaris/native/java/net/NetworkInterface.c Changeset: b1e3e3b8e6b2 Author: xdono Date: 2009-03-09 13:34 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b1e3e3b8e6b2 Merge Changeset: 175504cc095d Author: tbell Date: 2009-03-09 23:37 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/175504cc095d Merge Changeset: c2ca4a97ba86 Author: tbell Date: 2009-03-13 15:26 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c2ca4a97ba86 Merge - src/share/classes/sun/misc/JavaIODeleteOnExitAccess.java From tim.bell at sun.com Sun Mar 15 17:39:46 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Sun, 15 Mar 2009 17:39:46 +0000 Subject: hg: jdk7/tl/langtools: 3 new changesets Message-ID: <20090315173953.29109EF9C@hg.openjdk.java.net> Changeset: 03bcd66bd8e7 Author: xdono Date: 2009-03-09 13:29 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/03bcd66bd8e7 6814575: Update copyright year Summary: Update copyright for files that have been modified in 2009, up to 03/09 Reviewed-by: katleman, tbell, ohair ! make/build.properties ! make/build.xml ! make/netbeans/langtools/build.xml ! make/netbeans/langtools/nbproject/project.xml ! make/netbeans/langtools/nbproject/standard-context-menu-items.ent ! make/netbeans/langtools/nbproject/standard-ide-actions.ent ! make/tools/SelectTool/SelectToolTask.java ! src/share/classes/com/sun/tools/apt/comp/AnnotationProcessingError.java ! src/share/classes/com/sun/tools/apt/comp/Apt.java ! src/share/classes/com/sun/tools/apt/comp/UsageMessageNeededException.java ! src/share/classes/com/sun/tools/apt/main/JavaCompiler.java ! src/share/classes/com/sun/tools/apt/mirror/apt/RoundCompleteEventImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationProxyMaker.java ! src/share/classes/com/sun/tools/apt/mirror/type/TypeVariableImpl.java ! src/share/classes/com/sun/tools/classfile/Annotation.java ! src/share/classes/com/sun/tools/classfile/AttributeException.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/ConstantPoolException.java ! src/share/classes/com/sun/tools/classfile/Descriptor.java ! src/share/classes/com/sun/tools/classfile/DescriptorException.java ! src/share/classes/com/sun/tools/classfile/StackMapTable_attribute.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletOutputImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/SerializedFormWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocletAbortException.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MessageRetriever.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SourceToHTMLConverter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! src/share/classes/com/sun/tools/javac/api/DiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/api/Messages.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/Infer.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/main/Main.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/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/resources/javac.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/LayoutCharacters.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! src/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/Comment.java ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/share/classes/com/sun/tools/javadoc/DocImpl.java ! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java ! src/share/classes/com/sun/tools/javadoc/ExecutableMemberDocImpl.java ! src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java ! src/share/classes/com/sun/tools/javadoc/JavadocClassReader.java ! src/share/classes/com/sun/tools/javadoc/JavadocTool.java ! src/share/classes/com/sun/tools/javadoc/Messager.java ! src/share/classes/com/sun/tools/javadoc/PackageDocImpl.java ! src/share/classes/com/sun/tools/javadoc/RootDocImpl.java ! src/share/classes/com/sun/tools/javadoc/SourcePositionImpl.java ! src/share/classes/com/sun/tools/javadoc/TypeMaker.java ! src/share/classes/com/sun/tools/javah/Gen.java ! src/share/classes/com/sun/tools/javap/InternalError.java ! src/share/classes/sun/tools/javap/JavapPrinter.java ! test/tools/javac/6668794/badClass/Test.java ! test/tools/javac/cast/6558559/T6558559a.java ! test/tools/javac/cast/6558559/T6558559b.java ! test/tools/javac/cast/6665356/T6665356.java ! test/tools/javac/generics/6723444/T6723444.java ! test/tools/javac/generics/6729401/T6729401.java ! test/tools/javac/generics/rare/6665356/T6665356.java ! test/tools/javac/processing/model/testgetallmembers/Main.java ! test/tools/javadoc/6176978/T6176978.java ! test/tools/javadoc/6176978/X.java Changeset: 2c0076945b1a Author: xdono Date: 2009-03-09 13:34 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/2c0076945b1a Merge Changeset: 8c55d5b0ed71 Author: tbell Date: 2009-03-09 23:53 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/8c55d5b0ed71 Merge ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/SerializedFormWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java From martinrb at google.com Tue Mar 17 01:32:02 2009 From: martinrb at google.com (Martin Buchholz) Date: Mon, 16 Mar 2009 18:32:02 -0700 Subject: RFE 4519026: (process) Process should support Unicode on Win NT, request for review In-Reply-To: <537D306D9A36468DB3441DD50A9CC6A9@HeikoXP> References: <537D306D9A36468DB3441DD50A9CC6A9@HeikoXP> Message-ID: <1ccfd1c10903161832t18f0477wdf21e63d10b72c99@mail.gmail.com> Sorry for the delayed response. I've been busy. (Probably I should not have volunteered for this review.) Heiko, thanks for the patch. JDK engineers (Xueming, Alan?) will need to help with testing, architectural issues, and shepherding. I no longer use windows. I approve of the general approach being taken here. We need a general purpose version of JVM_NativePath, as you have coded it up, but it needs to go into some shared location for use by other JDK native code - not sure quite where that would be. I guess until we have another client for it, living in ProcessImpl_md.c is not so bad. Make sure you run the java.lang regression tests, especially ProcessBuilder/Basic.java There's a fair bit of cleanup that will be required. Use of white space and commenting style are non-standard and will need to be fixed (even if you've copied them from other parts of the JDK) I think the spec for free() guarantees that free(null) is a no-op, and the JDK already relies on this, so no need for releaseStringCopy. Typos/suggestions: path.md.c => path_md.c *(res + len) = 0; => res[len] = L'\0'; Martin On Mon, Mar 9, 2009 at 02:57, Heiko Wagner wrote: > This is related to my previous post at > http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-February/001145.ht > ml and my first contribution to the JDK7 project. As Martin suggested, I > have worked on a wide char version of ProcessImpl_md.c. For discussion of my > proposed chages a copy of my source can be found at: > > http://www.apis.de/pub/jdk7/ProcessImpl_md.c > > and a diff at: > > http://www.apis.de/pub/jdk7/ProcessImpl_md.c > > This patch enables launching executables residing on a path containing > non-ansi characters. My next goal is to get the java launcher working on a > unicode path. I think this needs additional coordination with the hotspot > team, since some of the code in os.cpp also has issues in a unicode path > when loading verify.dll and java.dll. > > Regards > Heiko > > From xuelei.fan at sun.com Tue Mar 17 04:02:13 2009 From: xuelei.fan at sun.com (xuelei.fan at sun.com) Date: Tue, 17 Mar 2009 04:02:13 +0000 Subject: hg: jdk7/tl/jdk: 6383095: CRL revoked certificate failures masked by OCSP failures Message-ID: <20090317040259.32AF1E0F3@hg.openjdk.java.net> Changeset: 181472dbbebb Author: xuelei Date: 2009-03-17 11:54 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/181472dbbebb 6383095: CRL revoked certificate failures masked by OCSP failures Summary: remove the mask if certificate revoked Reviewed-by: mullan ! src/share/classes/sun/security/provider/certpath/PKIXMasterCertPathValidator.java + test/java/security/cert/CertPathValidator/OCSP/FailoverToCRL.java From tim.bell at sun.com Tue Mar 17 18:39:04 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Tue, 17 Mar 2009 18:39:04 +0000 Subject: hg: jdk7/tl/langtools: 6814592: Legal notice repair needed in langtools/test/tools/javap/T4884240.java Message-ID: <20090317183908.77818E11F@hg.openjdk.java.net> Changeset: 889ec3ddc91b Author: tbell Date: 2009-03-17 11:28 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/889ec3ddc91b 6814592: Legal notice repair needed in langtools/test/tools/javap/T4884240.java Reviewed-by: jjg ! test/tools/javap/T4884240.java From tim.bell at sun.com Tue Mar 17 20:28:37 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Tue, 17 Mar 2009 20:28:37 +0000 Subject: hg: jdk7/tl/jdk: 6814587: Legal notice repair needed in jdk/src/share/classes/java/nio; ... Message-ID: <20090317202907.7B549E126@hg.openjdk.java.net> Changeset: 171dc1779708 Author: tbell Date: 2009-03-17 13:20 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/171dc1779708 6814587: Legal notice repair needed in jdk/src/share/classes/java/nio 6814590: Legal notice repair needed in jdk/test/java/awt/Frame/FrameSize/TestFrameSize.java 6814591: Legal notice repair needed in jdk/test/javax/script/Test3.java Reviewed-by: alanb, xdono ! src/share/classes/java/nio/file/SecureDirectoryStream.java ! src/solaris/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java ! test/java/awt/Frame/FrameSize/TestFrameSize.java ! test/javax/script/Test3.java From daniel.fuchs at sun.com Wed Mar 18 20:58:11 2009 From: daniel.fuchs at sun.com (daniel.fuchs at sun.com) Date: Wed, 18 Mar 2009 20:58:11 +0000 Subject: hg: jdk7/tl/jdk: 3 new changesets Message-ID: <20090318205909.A2694E1FF@hg.openjdk.java.net> Changeset: fa87de6b1ac3 Author: dfuchs Date: 2009-03-12 15:36 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fa87de6b1ac3 6661448: Make the SNMP agent optional when OPENJDK=true and IMPORT_BINARY_PLUGS=false Reviewed-by: mchung, ohair ! make/com/sun/jmx/Makefile ! make/java/management/Makefile ! make/javax/management/Makefile ! make/sun/management/Makefile ! src/share/classes/sun/management/Agent.java ! test/com/sun/jmx/snmp/SnmpOidHashCode.java ! test/com/sun/jmx/snmp/TimeTicksWrapping.java Changeset: e90ce2ac06a8 Author: dfuchs Date: 2009-03-13 14:25 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e90ce2ac06a8 Merge - src/share/classes/sun/misc/JavaIODeleteOnExitAccess.java Changeset: ef27484bbd7f Author: dfuchs Date: 2009-03-18 18:55 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ef27484bbd7f Merge From mandy.chung at sun.com Thu Mar 19 00:46:20 2009 From: mandy.chung at sun.com (mandy.chung at sun.com) Date: Thu, 19 Mar 2009 00:46:20 +0000 Subject: hg: jdk7/tl/jdk: 6817246: Redundant call to set InetAddressCachePolicy to FOREVER if not set during initialization Message-ID: <20090319004701.0C5DFE2E6@hg.openjdk.java.net> Changeset: 392cd358db5d Author: mchung Date: 2009-03-18 17:37 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/392cd358db5d 6817246: Redundant call to set InetAddressCachePolicy to FOREVER if not set during initialization Summary: Remove InetAddressCachePolicy.setIfNotSet call from System.setSecurityManager0 Reviewed-by: alanb, jccollet ! src/share/classes/java/lang/System.java From weijun.wang at sun.com Thu Mar 19 03:23:32 2009 From: weijun.wang at sun.com (weijun.wang at sun.com) Date: Thu, 19 Mar 2009 03:23:32 +0000 Subject: hg: jdk7/tl/jdk: 6819272: keytool -importcert should read the whole input Message-ID: <20090319032415.12C97E2EB@hg.openjdk.java.net> Changeset: 87acd36bd847 Author: weijun Date: 2009-03-19 11:17 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/87acd36bd847 6819272: keytool -importcert should read the whole input Reviewed-by: xuelei ! src/share/classes/sun/security/tools/KeyTool.java + test/sun/security/tools/keytool/importreadall.sh From heiko.wagner at apis.de Fri Mar 20 10:33:38 2009 From: heiko.wagner at apis.de (Heiko Wagner) Date: Fri, 20 Mar 2009 11:33:38 +0100 Subject: RFE 4519026: (process) Process should support Unicode on Win NT, request for review In-Reply-To: <1ccfd1c10903161832t18f0477wdf21e63d10b72c99@mail.gmail.com> Message-ID: <90B150C4E9484A0891F55FE693B760A0@HeikoXP> Thanks for your reply. I have updated both the source file and the diff file. (URL see in previous post below) I have made the following changes: - replace C++ style comments with plain C style comments - replace tabs with spaces in source (maybe using VC 2008 as editor in the first place was no good idea ;-)) - remove function releaseStringCopy and call free() directly - fix the types you suggested "path.md.c => path_md.c" and "*(res + len) = 0; => res[len] = L'\0';" I have tried to set up jtreg and run the regression tests. Somehow, I still haven't managed to get all things working. Some tests in ProcessBuilder/Basic.java fail, because the exit code of the invocation of the java child is 6 insted of 0. I am still working on that issue. P.S.: Is there any kind of guide line how to write the comments, so I can fix them as well? -----Original Message----- From: Martin Buchholz [mailto:martinrb at google.com] Sent: Dienstag, 17. M?rz 2009 02:32 To: Heiko Wagner Cc: core-libs-dev at openjdk.java.net; Xueming Shen; Alan Bateman Subject: Re: RFE 4519026: (process) Process should support Unicode on Win NT, request for review Sorry for the delayed response. I've been busy. (Probably I should not have volunteered for this review.) Heiko, thanks for the patch. JDK engineers (Xueming, Alan?) will need to help with testing, architectural issues, and shepherding. I no longer use windows. I approve of the general approach being taken here. We need a general purpose version of JVM_NativePath, as you have coded it up, but it needs to go into some shared location for use by other JDK native code - not sure quite where that would be. I guess until we have another client for it, living in ProcessImpl_md.c is not so bad. Make sure you run the java.lang regression tests, especially ProcessBuilder/Basic.java There's a fair bit of cleanup that will be required. Use of white space and commenting style are non-standard and will need to be fixed (even if you've copied them from other parts of the JDK) I think the spec for free() guarantees that free(null) is a no-op, and the JDK already relies on this, so no need for releaseStringCopy. Typos/suggestions: path.md.c => path_md.c *(res + len) = 0; => res[len] = L'\0'; Martin On Mon, Mar 9, 2009 at 02:57, Heiko Wagner wrote: > This is related to my previous post at > http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-February/001145.ht > ml and my first contribution to the JDK7 project. As Martin suggested, I > have worked on a wide char version of ProcessImpl_md.c. For discussion of my > proposed chages a copy of my source can be found at: > > http://www.apis.de/pub/jdk7/ProcessImpl_md.c > > and a diff at: > > http://www.apis.de/pub/jdk7/ProcessImpl_md.c.diff > > This patch enables launching executables residing on a path containing > non-ansi characters. My next goal is to get the java launcher working on a > unicode path. I think this needs additional coordination with the hotspot > team, since some of the code in os.cpp also has issues in a unicode path > when loading verify.dll and java.dll. > > Regards > Heiko > > From bhavesh.patel at sun.com Fri Mar 20 02:06:58 2009 From: bhavesh.patel at sun.com (bhavesh.patel at sun.com) Date: Fri, 20 Mar 2009 02:06:58 +0000 Subject: hg: jdk7/tl/langtools: 6786688: Javadoc HTML WCAG 2.0 accessibility issues in standard doclet - Table must have captions and headers Message-ID: <20090320020659.A22F1E3B7@hg.openjdk.java.net> Changeset: edd944553131 Author: bpatel Date: 2009-03-19 19:00 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/edd944553131 6786688: Javadoc HTML WCAG 2.0 accessibility issues in standard doclet - Table must have captions and headers Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractPackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/DeprecatedListWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/StylesheetWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/PackageSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets.properties ! test/com/sun/javadoc/testHeadings/TestHeadings.java ! test/com/sun/javadoc/testHtmlStrongTag/TestHtmlStrongTag.java + test/com/sun/javadoc/testHtmlTableTags/TestHtmlTableTags.java + test/com/sun/javadoc/testHtmlTableTags/pkg1/C1.java + test/com/sun/javadoc/testHtmlTableTags/pkg1/I1.java + test/com/sun/javadoc/testHtmlTableTags/pkg1/package-info.java + test/com/sun/javadoc/testHtmlTableTags/pkg2/C2.java + test/com/sun/javadoc/testHtmlTableTags/pkg2/C3.java + test/com/sun/javadoc/testHtmlTableTags/pkg2/C4.java + test/com/sun/javadoc/testHtmlTableTags/pkg2/package-info.java ! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/com/sun/javadoc/testSummaryHeading/TestSummaryHeading.java From Alan.Bateman at Sun.COM Fri Mar 20 16:41:35 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Fri, 20 Mar 2009 16:41:35 +0000 Subject: Review request for 100020 (sunbug=6819886) Message-ID: <49C3C73F.6090004@sun.com> Bug 100020 (https://bugs.openjdk.java.net/show_bug.cgi?id=100020) is a fix from Andreas Frischknecht. In summary File#lastModified, on Windows, uses GetFileTime to get the timestamp but doesn't check the result. This bites when accessing a remote file at just around the time that the file is deleted. Good sleuthing on the part of Andreas! As it only duplicates when accessing a file over SMB we don't propose to include a regression test. The webrev is here: http://cr.openjdk.java.net/~alanb/6819689/webrev.00/ Thanks, Alan. From Alan.Bateman at Sun.COM Fri Mar 20 16:42:39 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Fri, 20 Mar 2009 16:42:39 +0000 Subject: Review request for 6819886 Message-ID: <49C3C77F.80901@sun.com> 6819886: System.getProperty("os.name") reports Vista on Windows 7 Webrev at: http://cr.openjdk.java.net/~alanb/6819886/webrev.00/ The CR synopsis says it all. A separate CR (6820180) has been created to track updating HotSpot's os::print_os_info (this is used when emitting the system information to the fatal error log). Thanks, Alan. From Xueming.Shen at Sun.COM Fri Mar 20 17:48:17 2009 From: Xueming.Shen at Sun.COM (Xueming Shen) Date: Fri, 20 Mar 2009 09:48:17 -0800 Subject: Review request for 6819886 In-Reply-To: <49C3C77F.80901@sun.com> References: <49C3C77F.80901@sun.com> Message-ID: <49C3D6E1.3000100@sun.com> looks good sherman Alan Bateman wrote: > 6819886: System.getProperty("os.name") reports Vista on Windows 7 > > Webrev at: > http://cr.openjdk.java.net/~alanb/6819886/webrev.00/ > > The CR synopsis says it all. A separate CR (6820180) has been created > to track updating HotSpot's os::print_os_info (this is used when > emitting the system information to the fatal error log). > > Thanks, > Alan. > From Alan.Bateman at Sun.COM Fri Mar 20 16:57:12 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Fri, 20 Mar 2009 16:57:12 +0000 Subject: Review request for 6807702 Message-ID: <49C3CAE8.20002@sun.com> 6807702: Integer.valueOf cache should be configurable This is a forward-port from 6u14, which in turn is an update to the original library updates that Tom Rodriguez did in an earlier 6 update. Joe, you'll probably want to review this one as it relates to the cache you developed back in jdk5. The background to this is work in HotSpot to eliminate the use of box objects. The optimizer knows about Integer's autobox cache since hs11. Further performance can be gained by increasing the size of the cache, which HotSpot does when running with +AggressiveOpts. The webrev is here: http://cr.openjdk.java.net/~alanb/6807702/webrev.00/ Thanks, Alan. From Joe.Darcy at Sun.COM Fri Mar 20 17:02:55 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Fri, 20 Mar 2009 10:02:55 -0700 Subject: Review request for 6807702 -- approved In-Reply-To: <49C3CAE8.20002@sun.com> References: <49C3CAE8.20002@sun.com> Message-ID: <49C3CC3F.30406@sun.com> Looks good -- approved. -Joe Alan Bateman wrote: > > 6807702: Integer.valueOf cache should be configurable > > This is a forward-port from 6u14, which in turn is an update to the > original library updates that Tom Rodriguez did in an earlier 6 > update. Joe, you'll probably want to review this one as it relates to > the cache you developed back in jdk5. The background to this is work > in HotSpot to eliminate the use of box objects. The optimizer knows > about Integer's autobox cache since hs11. Further performance can be > gained by increasing the size of the cache, which HotSpot does when > running with +AggressiveOpts. > > The webrev is here: > http://cr.openjdk.java.net/~alanb/6807702/webrev.00/ > > Thanks, > > Alan. From Xueming.Shen at Sun.COM Fri Mar 20 18:25:24 2009 From: Xueming.Shen at Sun.COM (Xueming Shen) Date: Fri, 20 Mar 2009 10:25:24 -0800 Subject: Review request for 6636323_6636319 Message-ID: <49C3DF94.2040709@sun.com> The change has been/is being reviewed by Alan and Ulf, sent to the alias to see if anyone else is interested to take a look (Ulf suggested we should go more open:-) http://cr.openjdk.java.net/~sherman/6636323_6636319/webrev (a)It's a pure performance improvement for new String(byte[], cs/csn) and String.getBytes(cs/can) when data size is relatively small. (We're not ready to add those methods into CharsetDe/Encoder for now) The preliminary micro-benchmark data is at http://cr.openjdk.java.net/~sherman/6636323_6636319/benchmark.txt (b)This is now for ASCII, 8859-1 and all SingleByte based charsets. I yet to find time to migrate the DB charsets. Thanks, Sherman Simple writeup for the changes. ------------------------------- Problem/Issue to solve: StringCoding.java is "slow" and create "too many" objects when doing byte[]<->String conversion. Root Cause: There are "too many" layers and logic before the byte[]/char[] can reach the real de/encoding code and then going back. A pair of ByteBuffer/CharBuffer is always created (the wrapper) for each conversion. While the GC should be doing pretty good these days to clean these wrapper objects quickly, the "creating" and "cleaning" itself are still a waste of CPU/memory resource, if not really necessary. Two "facts/details" that we can take advantage of: (1) StringCoding always perform REPLACE when having malformed or unmappable input sequences. (2) The input and output byte/char[] are totally under our "control", the de/encoding should never "overflow" Changes: (1) 2 new internal interfaces sun.nio.cs.ArrayDecoder, sun.nio.cs.ArrayEncoder to provide the byte[] <->char[] fastpath from otherwise "well-encapsulated-X-Buffer only" CharsetDe/Encoder interface. (2)US_ASCII/ISO_8859_1/SingleByte.Decoder/Encoder to implement above interface (3)US_ASCII/ISO_8859_1/SingleByte.Decoder/Encoder also to override isLegalReplacement() which improve new CharsetEncoder() significantly, which has big impact to getBytes(charset). (4)StringCoding.java a)Use ArrayDecoder/ArrayEncoder interface if possible (instanceof) b)Added a "isTrusted" field to indicate the charset is from the system class loader during creating the StringDe/Encoder(invoking cs.getClass().getClassLoader0() is "expensive", to pay the cost everytime len==ba.length, when there is a SM installed, is unnecessary, it helps the benchmark lot when SM installed) c)No longer create StringDe/Encoder to in "param is charset" cases and avoid defensive copy if not necessary. From Ulf.Zibis at gmx.de Fri Mar 20 20:55:01 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 20 Mar 2009 21:55:01 +0100 Subject: fastpath for StringCoding.java In-Reply-To: <49C2D726.4060304@sun.com> References: <49C2D726.4060304@sun.com> Message-ID: <49C402A5.5070609@gmx.de> Am 20.03.2009 00:37, Xueming Shen schrieb: > Webrev has been updated to address your coments. I'm building the > binaries and will run the benchmark again > (up to 2048 this time) tonight. As I see, you take a seed from Random to create the test patterns. This approach would be good for testing stability of the coders, but for benchmark it wouldn't take to account the differing probability distribution of the code points in the particular charsets. For example see TIS-620. The code points from U+0e01 to U+0e5b would be probably more used than the latin chars and the unmappables. I accommodate this by different coders. See: https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/src/sun/nio/cs/ -Ulf From Ulf.Zibis at gmx.de Fri Mar 20 22:07:35 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 20 Mar 2009 23:07:35 +0100 Subject: Fastpath for new String(bytes...) and String.getBytes(...) In-Reply-To: <49C415FE.2070306@sun.com> References: <49C16E46.9040609@sun.com> <49C23DE2.5010901@gmx.de> <49C2CAD9.4070908@sun.com> <49C3FD30.4050005@gmx.de> <49C415FE.2070306@sun.com> Message-ID: <49C413A7.5040109@gmx.de> Am 20.03.2009 23:17, Xueming Shen schrieb: > Ulf Zibis wrote: >> >> The problem with the dependencies (EUC*, ISO2022*, etc.) from the >> jis0201 maps I've solved here: >> https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/src/sun/nio/cs/ext/?rev=674 >> >> So jis0201 can be constructed like all other single-byte charsets. >> > > nice to see that, so i will try to just take your code when i'm ready > to work on the db stuff > (if we can get that copyright stuff right) or you can start work on > the 7 based openjdk. I'm working on it. May be this would be my first changeset ...but I think, I should start with more simple changes e.g.: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6795536 (see my comments there) I assume, you have read my questions regarding build environment addressed to Alan. If I get stuck, can I count for some help? > > took a very quick scan, no, i don't think we are going to get all of > them in in one shoot:-) Yes, I'm aware of this. I think, I'm able to split my changes into reasonable slices. > > (1)don't try PCK and SJIS, they will have to be modified to the map > based implementation (i have the > implementation ready somewhere waiting for review), since the existing > implementation has a > fundamental flaw, the jis<->sjis algorithm (from the book) has the > assumption that all input > bytes are legal jis or sjis... Thanks. > > (2)anyway reason you do cs.getClass() == XYX.class instead of cs > instanceof XYZ? cs instanceof XYZ also includes subclasses of XYZ, but this often is wrong, subclass of XYZ likely contains different mapping, which is not equal from XYZ-side of view. Refer: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6761481 > > (3)some contains() methods do not seem right, they only check sjis0201. As I said: Charset#contains() should be examined for ALL charsets. :-( From bhavesh.patel at sun.com Fri Mar 20 22:56:02 2009 From: bhavesh.patel at sun.com (bhavesh.patel at sun.com) Date: Fri, 20 Mar 2009 22:56:02 +0000 Subject: hg: jdk7/tl/langtools: 6820360: Fix for definition list tags nesting adds an extra list tag for package summary page. Message-ID: <20090320225604.44F93E62E@hg.openjdk.java.net> Changeset: b000f7c728ae Author: bpatel Date: 2009-03-20 15:50 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/b000f7c728ae 6820360: Fix for definition list tags nesting adds an extra list tag for package summary page. Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! test/com/sun/javadoc/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java + test/com/sun/javadoc/testHtmlDefinitionListTag/pkg1/package-info.java From Ulf.Zibis at gmx.de Fri Mar 20 22:58:57 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 20 Mar 2009 23:58:57 +0100 Subject: fastpath for StringCoding.java In-Reply-To: <49C40A3B.8030403@sun.com> References: <49C2D726.4060304@sun.com> <49C3FDCE.9000703@gmx.de> <49C40A3B.8030403@sun.com> Message-ID: <49C41FB1.7000101@gmx.de> Am 20.03.2009 22:27, Xueming Shen schrieb: > http://cr.openjdk.java.net/~sherman/6636323_6636319/webrev > > I sent it to the core-libs-dev at openjdk.java.net as you suggested. Sorry, I've overseen it, because of lack of descriptive subject. Please use a more descriptive subject, I don't know all the CR no. in my head. Thanks, Ulf From Ulf.Zibis at gmx.de Fri Mar 20 23:28:33 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 21 Mar 2009 00:28:33 +0100 Subject: Fastpath for new String(bytes...) and String.getBytes(...) In-Reply-To: <49C4206A.1060509@sun.com> References: <49C16E46.9040609@sun.com> <49C23DE2.5010901@gmx.de> <49C2CAD9.4070908@sun.com> <49C3FD30.4050005@gmx.de> <49C4206A.1060509@sun.com> Message-ID: <49C426A1.8000009@gmx.de> Am 21.03.2009 00:02, Xueming Shen schrieb: > > to be honest i'm not convinced that a base/abstract-X-coder has any > advantage compared to > current interface approach, at least in this case, can you explain > more? you will have to cast > anyway in the StringCoding class until the those utility methods get > themself into the > Charset-X-coder class. 1.) You are right, it's not as simple as I thought first, having Base/Abstract-X-coder. Maybe there is a Chance by generifying Charset and Charset-X-coder. 2.) To implement the 4-way x-codeLoop() methods for general use for all sun.nio.cs charsets sun.nio.cs.Base/Abstract-X-coder is the only way, so why introduce additional interface. There also constants like MAX_ASCII, MALFORMED_EXCEPTION, etc. could be hosted. See: https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/src/sun/nio/cs/BaseCharset.java?rev=674&view=markup https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/src/sun/nio/cs/SingleByteDecoder_new.java?rev=572&view=markup -Ulf From xueming.shen at sun.com Sat Mar 21 00:47:54 2009 From: xueming.shen at sun.com (xueming.shen at sun.com) Date: Sat, 21 Mar 2009 00:47:54 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20090321004818.06899E639@hg.openjdk.java.net> Changeset: 3b6d7e15ccd9 Author: sherman Date: 2009-03-20 16:22 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3b6d7e15ccd9 6817475: named-capturing group name started with digit causes PSE exception Summary: Need accept the digit as the first char of the group name Reviewed-by: alanb ! src/share/classes/java/util/regex/Pattern.java ! test/java/util/regex/RegExTest.java Changeset: c6b37e92e387 Author: sherman Date: 2009-03-20 17:40 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c6b37e92e387 Merge ! src/share/classes/java/util/regex/Pattern.java - src/share/classes/sun/misc/JavaIODeleteOnExitAccess.java From Xueming.Shen at Sun.COM Sat Mar 21 07:03:15 2009 From: Xueming.Shen at Sun.COM (Xueming Shen) Date: Fri, 20 Mar 2009 23:03:15 -0800 Subject: fastpath for StringCoding.java In-Reply-To: <49C402A5.5070609@gmx.de> References: <49C2D726.4060304@sun.com> <49C402A5.5070609@gmx.de> Message-ID: <49C49133.5060602@sun.com> Ulf, The charsets being benchmarked here are all singlebyte charsets built on top of SingleByte.De/Encoder (excluding ASCII and 8859-1), which have exactly the same lookup mechanism of a b2c[] for decoding and a c2bIndex+c2b table for encoding. For these charsets what/which codepoint(s) are used to benchmark the performance actually is irrelevant as long as they are "mappable", the benchmark only collect those "mappable" codepoints (canEncode() returns true) as the testing data. The rational behind this is that the "most likely" real life use scenario of decoding/encoding is the "characters" in and out are all "mappable" characters, which is the performance really matters. Ulf Zibis wrote: > Am 20.03.2009 00:37, Xueming Shen schrieb: >> Webrev has been updated to address your coments. I'm building the >> binaries and will run the benchmark again >> (up to 2048 this time) tonight. > > As I see, you take a seed from Random to create the test patterns. > This approach would be good for testing stability of the coders, but > for benchmark it wouldn't take to account the differing probability > distribution of the code points in the particular charsets. > For example see TIS-620. The code points from U+0e01 to U+0e5b would > be probably more used than the latin chars and the unmappables. > I accommodate this by different coders. See: > https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/src/sun/nio/cs/ > > > -Ulf > > From Ulf.Zibis at gmx.de Sat Mar 21 14:57:56 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 21 Mar 2009 15:57:56 +0100 Subject: fastpath for StringCoding.java In-Reply-To: <49C49133.5060602@sun.com> References: <49C2D726.4060304@sun.com> <49C402A5.5070609@gmx.de> <49C49133.5060602@sun.com> Message-ID: <49C50074.9040703@gmx.de> Sherman, sorry, I haven't recognized, that you filtered the mappables for this benchmark. -Ulf Am 21.03.2009 08:03, Xueming Shen schrieb: > > Ulf, > > The charsets being benchmarked here are all singlebyte charsets built > on top of SingleByte.De/Encoder > (excluding ASCII and 8859-1), which have exactly the same lookup > mechanism of a b2c[] for decoding > and a c2bIndex+c2b table for encoding. For these charsets what/which > codepoint(s) are used to benchmark > the performance actually is irrelevant as long as they are "mappable", > the benchmark only collect those > "mappable" codepoints (canEncode() returns true) as the testing data. > The rational behind this is that the "most > likely" real life use scenario of decoding/encoding is the > "characters" in and out are all "mappable" characters, > which is the performance really matters. > > > Ulf Zibis wrote: >> Am 20.03.2009 00:37, Xueming Shen schrieb: >>> Webrev has been updated to address your coments. I'm building the >>> binaries and will run the benchmark again >>> (up to 2048 this time) tonight. >> >> As I see, you take a seed from Random to create the test patterns. >> This approach would be good for testing stability of the coders, but >> for benchmark it wouldn't take to account the differing probability >> distribution of the code points in the particular charsets. >> For example see TIS-620. The code points from U+0e01 to U+0e5b would >> be probably more used than the latin chars and the unmappables. >> I accommodate this by different coders. See: >> https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/src/sun/nio/cs/ >> >> >> -Ulf >> >> > > From tim.bell at sun.com Sun Mar 22 00:22:09 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Sun, 22 Mar 2009 00:22:09 +0000 Subject: hg: jdk7/tl: Added tag jdk7-b51 for changeset 0f0189d55ce4 Message-ID: <20090322002209.AF9BAE679@hg.openjdk.java.net> Changeset: 4264c2fe6649 Author: xdono Date: 2009-03-19 13:25 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/4264c2fe6649 Added tag jdk7-b51 for changeset 0f0189d55ce4 ! .hgtags From tim.bell at sun.com Sun Mar 22 00:25:12 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Sun, 22 Mar 2009 00:25:12 +0000 Subject: hg: jdk7/tl/corba: 4 new changesets Message-ID: <20090322002516.495DEE67E@hg.openjdk.java.net> Changeset: 53d5b45f73ab Author: ohair Date: 2009-03-11 14:38 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/53d5b45f73ab 6790292: BOOTDIR of jdk6 u12 will not work with jdk7 builds Reviewed-by: tbell ! make/common/Rules.gmk Changeset: 9c0cc0d0eca2 Author: ohair Date: 2009-03-11 17:31 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/9c0cc0d0eca2 6816311: Changes to allow builds with latest Windows SDK 6.1 on 64bit Windows 2003 Reviewed-by: tbell ! make/common/shared/Compiler-msvc.gmk ! make/common/shared/Defs-windows.gmk ! src/windows/resource/version.rc Changeset: 3eb8f1047a74 Author: xdono Date: 2009-03-16 16:18 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/3eb8f1047a74 Merge Changeset: bec82237d694 Author: xdono Date: 2009-03-19 13:25 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/bec82237d694 Added tag jdk7-b51 for changeset 3eb8f1047a74 ! .hgtags From tim.bell at sun.com Sun Mar 22 00:30:50 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Sun, 22 Mar 2009 00:30:50 +0000 Subject: hg: jdk7/tl/hotspot: 50 new changesets Message-ID: <20090322003226.303D1E683@hg.openjdk.java.net> Changeset: 9e5a6ed08fc9 Author: jmasa Date: 2009-02-17 15:35 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9e5a6ed08fc9 6786346: intermittent Internal Error (src/share/vm/memory/cardTableModRefBS.cpp:226) Summary: Two assertions were incorrectly composed. Reviewed-by: tonyp ! src/share/vm/memory/cardTableModRefBS.cpp Changeset: a0576ae7045f Author: ysr Date: 2009-02-20 11:12 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a0576ae7045f Merge Changeset: 5d75ab5f6698 Author: kvn Date: 2009-02-18 13:53 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5d75ab5f6698 6807084: AutoBox elimination is broken with compressed oops Summary: Add checks for DecodeN nodes into AutoBox elimination code. Reviewed-by: never ! src/share/vm/opto/memnode.cpp Changeset: 49a36a80b0c7 Author: kvn Date: 2009-02-19 17:38 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/49a36a80b0c7 6802499: EA: assert(false,"unknown node on this path") Summary: Add missing checks for SCMemProj node in Escape analysis code. Reviewed-by: never ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/macro.cpp Changeset: 22e09c0f4b47 Author: twisti Date: 2009-02-23 12:02 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/22e09c0f4b47 6808589: Merge vm_version_x86_{32,64}.{cpp,hpp} Summary: There is very much duplicated code in vm_version_x86_{32,64}.{cpp,hpp}. Refactoring these would help maintainability. Reviewed-by: kvn, never + src/cpu/x86/vm/vm_version_x86.cpp + src/cpu/x86/vm/vm_version_x86.hpp - src/cpu/x86/vm/vm_version_x86_32.cpp - src/cpu/x86/vm/vm_version_x86_32.hpp - src/cpu/x86/vm/vm_version_x86_64.cpp - src/cpu/x86/vm/vm_version_x86_64.hpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.hpp ! src/share/vm/includeDB_core Changeset: 6bea93606c11 Author: kvn Date: 2009-02-23 16:03 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6bea93606c11 6791572: assert("duplicating node that's already been matched") Summary: Mark inputs for an address expression as shared if there are other uses besides address expressions. Reviewed-by: never ! src/share/vm/opto/matcher.cpp Changeset: e57b6f22d1f3 Author: kvn Date: 2009-02-24 09:53 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e57b6f22d1f3 Merge - src/cpu/x86/vm/vm_version_x86_32.cpp - src/cpu/x86/vm/vm_version_x86_32.hpp - src/cpu/x86/vm/vm_version_x86_64.cpp - src/cpu/x86/vm/vm_version_x86_64.hpp Changeset: ef3b3df478b9 Author: trims Date: 2009-02-25 22:55 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ef3b3df478b9 Merge - src/cpu/x86/vm/vm_version_x86_32.cpp - src/cpu/x86/vm/vm_version_x86_32.hpp - src/cpu/x86/vm/vm_version_x86_64.cpp - src/cpu/x86/vm/vm_version_x86_64.hpp Changeset: 01ddca3f0730 Author: jcoomes Date: 2009-02-09 13:47 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/01ddca3f0730 Merge Changeset: 3264b1424f72 Author: apangin Date: 2009-02-15 20:09 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3264b1424f72 Merge Changeset: a53107650e8b Author: apangin Date: 2009-02-22 17:11 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a53107650e8b Merge Changeset: 82e4d969e7cb Author: ikrylov Date: 2009-02-19 04:54 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/82e4d969e7cb 6806046: Hotspot build error when compiled from Visual Studio Summary: Define HOTSPOT_LIB_ARCH in the preprocessor flags of the generated projects Reviewed-by: kamg, xlu ! src/share/tools/MakeDeps/BuildConfig.java Changeset: 1b68c738c0d9 Author: apangin Date: 2009-02-22 17:21 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1b68c738c0d9 Merge Changeset: 7898caac2071 Author: apangin Date: 2009-02-26 14:25 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7898caac2071 Merge - src/cpu/x86/vm/vm_version_x86_32.cpp - src/cpu/x86/vm/vm_version_x86_32.hpp - src/cpu/x86/vm/vm_version_x86_64.cpp - src/cpu/x86/vm/vm_version_x86_64.hpp Changeset: 3698e8f47799 Author: tonyp Date: 2009-02-24 15:50 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3698e8f47799 6804746: G1: guarantee(variance() > -1.0,"variance should be >= 0") (due to evacuation failure) Summary: Under certain circumstances (evacuation failure) the pause time is not communicated to the policy and, as a result, the pause time field is not initialized properly. Reviewed-by: jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp Changeset: 83ef1482304c Author: jmasa Date: 2009-02-24 22:12 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/83ef1482304c 6806226: Signed integer overflow in growable array code causes JVM crash Summary: Workaround the overflow by doing the intermediate calculations in an unsigned variable. Reviewed-by: ysr, jcoomes ! src/share/vm/utilities/growableArray.cpp Changeset: 59150d6667e1 Author: jmasa Date: 2009-02-24 22:51 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/59150d6667e1 Merge Changeset: 1fa16c3565be Author: ysr Date: 2009-02-27 15:30 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1fa16c3565be Merge Changeset: 0ad1cb407fa1 Author: never Date: 2009-02-25 10:53 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0ad1cb407fa1 6805427: adlc compiler may generate incorrect machnode emission code Reviewed-by: kvn, twisti ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp Changeset: 07d449658fc7 Author: never Date: 2009-02-25 14:36 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/07d449658fc7 6807963: need tool to make sense of LogCompilaton output Reviewed-by: kvn + src/share/tools/LogCompilation/Makefile + src/share/tools/LogCompilation/README + src/share/tools/LogCompilation/manifest.mf + src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/BasicLogEvent.java + src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/CallSite.java + src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/Compilation.java + src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/Constants.java + src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogCleanupReader.java + src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogCompilation.java + src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogEvent.java + src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogParser.java + src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/MakeNotEntrantEvent.java + src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/Method.java + src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/NMethod.java + src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/Phase.java + src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/UncommonTrapEvent.java Changeset: 523ded093c31 Author: kvn Date: 2009-02-26 14:26 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/523ded093c31 6809798: SafePointScalarObject node placed into incorrect block during GCM Summary: Replace the control edge of a pinned node before scheduling. Reviewed-by: never ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/macro.cpp Changeset: ed6404fac86b Author: never Date: 2009-02-26 16:57 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ed6404fac86b 6810855: KILL vs. TEMP ordering restrictions are too strong Reviewed-by: kvn ! src/share/vm/adlc/formssel.cpp Changeset: dbbe28fc66b5 Author: twisti Date: 2009-02-27 03:35 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/dbbe28fc66b5 6778669: Patch from Red Hat -- fixes compilation errors Summary: Some fixes which are required to build on recent GCCs. Reviewed-by: never, kvn Contributed-by: langel at redhat.com ! make/linux/makefiles/adlc.make ! make/solaris/makefiles/adlc.make ! src/share/vm/adlc/adlc.hpp ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/dfa.cpp ! src/share/vm/adlc/filebuff.cpp ! src/share/vm/adlc/filebuff.hpp ! src/share/vm/adlc/forms.cpp ! src/share/vm/adlc/forms.hpp ! src/share/vm/adlc/formsopt.cpp ! src/share/vm/adlc/formsopt.hpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/main.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/includeDB_core ! src/share/vm/utilities/vmError.cpp ! src/share/vm/utilities/vmError.hpp Changeset: ec59443af135 Author: kvn Date: 2009-02-27 08:34 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ec59443af135 6811267: Fix for 6809798 broke linux build Summary: Fix method's declaration. Reviewed-by: phh, twisti ! src/share/vm/opto/block.hpp Changeset: 98cb887364d3 Author: twisti Date: 2009-02-27 13:27 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/98cb887364d3 6810672: Comment typos Summary: I have collected some typos I have found while looking at the code. Reviewed-by: kvn, never ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/nativeInst_sparc.hpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.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/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os/linux/launcher/java.c ! src/os/linux/launcher/java_md.h ! src/os/linux/vm/perfMemory_linux.cpp ! src/os/solaris/launcher/java.c ! src/os/solaris/launcher/java_md.h ! src/os/solaris/vm/perfMemory_solaris.cpp ! src/os/windows/vm/perfMemory_windows.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/share/tools/MakeDeps/Database.java ! src/share/vm/adlc/Doc/Syntax.doc ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/dict2.cpp ! src/share/vm/adlc/dict2.hpp ! src/share/vm/adlc/filebuff.cpp ! src/share/vm/adlc/filebuff.hpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsAdaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsGCAdaptivePolicyCounters.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.cpp ! src/share/vm/gc_implementation/parallelScavenge/objectStartArray.hpp ! src/share/vm/gc_implementation/parallelScavenge/prefetchQueue.hpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! 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/templateInterpreter.hpp ! src/share/vm/interpreter/templateInterpreterGenerator.hpp ! src/share/vm/libadt/dict.cpp ! src/share/vm/libadt/dict.hpp ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/permGen.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/oops/generateOopMap.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/buildOopMap.cpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/coalesce.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/connode.cpp ! src/share/vm/opto/divnode.cpp ! src/share/vm/opto/domgraph.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/locknode.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/machnode.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/phase.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/postaloc.cpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/split_if.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/superword.hpp ! src/share/vm/opto/type.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/extendedPC.hpp ! src/share/vm/runtime/fprofiler.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.inline.hpp ! src/share/vm/runtime/mutex.hpp ! src/share/vm/runtime/orderAccess.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/signature.hpp ! src/share/vm/runtime/threadCritical.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 19962e74284f Author: never Date: 2009-03-01 20:49 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/19962e74284f 6811384: MacroAssembler::serialize_memory may touch next page on amd64 Reviewed-by: kvn, phh, twisti ! src/cpu/x86/vm/assembler_x86.cpp Changeset: d8c7fa77a6dc Author: kvn Date: 2009-03-03 10:34 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/d8c7fa77a6dc Merge ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 0386097d43d8 Author: dcubed Date: 2009-03-02 13:57 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0386097d43d8 6700114: 3/4 Assertion (_thread->get_interp_only_mode() == 1,"leaving interp only when mode not one") Summary: Don't create JvmtiThreadState for an exiting JavaThread. Reviewed-by: coleenp, swamyv ! src/share/vm/prims/jvmtiThreadState.hpp Changeset: ea20d7ce26b0 Author: dcubed Date: 2009-03-02 14:00 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ea20d7ce26b0 6800721: 3/4 JavaThread::jvmti_thread_state() and JvmtiThreadState::state_for() robustness Summary: Check for NULL return values from jvmti_thread_state() and state_for() and return a JVM TI error code as appropriate. Reviewed-by: coleenp, swamyv ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiEventController.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiThreadState.hpp ! src/share/vm/runtime/thread.hpp Changeset: 70998f2e05ef Author: dcubed Date: 2009-03-02 14:03 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/70998f2e05ef 6805864: 4/3 Problem with jvmti->redefineClasses: some methods don't get redefined Summary: Remove incorrect optimization in klassItable::adjust_method_entries(). Add RedefineClasses() tracing support for obsolete method entry. Reviewed-by: acorn, swamyv ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/share/vm/includeDB_core ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/prims/jvmtiRedefineClassesTrace.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp Changeset: 2f716c0acb64 Author: dcubed Date: 2009-03-02 14:05 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2f716c0acb64 6567360: 3/4 SIGBUS in jvmti RawMonitor magic check for unaligned bad monitor pointer Summary: Change JvmtiEnvBase::is_valid() and JvmtiRawMonitor::is_valid() to fetch the _magic fields via Bytes::get_native_u[248](). Reviewed-by: coleenp, swamyv ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiEnvBase.hpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp Changeset: afa80fa86d22 Author: dcubed Date: 2009-03-02 14:43 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/afa80fa86d22 Merge ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/share/vm/includeDB_core ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 5caef2219893 Author: dcubed Date: 2009-03-02 16:56 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5caef2219893 Merge ! src/share/vm/includeDB_core Changeset: 3db67f76d308 Author: acorn Date: 2009-03-05 22:07 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3db67f76d308 Merge ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/share/vm/includeDB_core ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: c6c601a0f2d6 Author: ysr Date: 2009-03-02 16:37 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c6c601a0f2d6 6797870: Add -XX:+{HeapDump,PrintClassHistogram}{Before,After}FullGC Summary: Call newly created CollectedHeap::dump_{pre,post}_full_gc before and after every stop-world full collection cycle on GenCollectedHeap and ParallelScavengeHeap. (Support for G1CollectedHeap forthcoming under CR 6810861.) Small modifications to existing heap dumping and class histogram implementation, especially to allow multiple on-the-fly histos/dumps by the VM thread during a single safepoint. Reviewed-by: jmasa, alanb, mchung ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/includeDB_gc ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/heapDumper.hpp Changeset: 4f360ec815ba Author: iveresov Date: 2009-03-06 13:50 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4f360ec815ba 6720309: G1: don't synchronously update RSet during evacuation pauses 6720334: G1: don't update RSets of collection set regions during an evacuation pause Summary: Introduced a deferred update mechanism for delaying the rset updates during the collection pause Reviewed-by: apetrusenko, tonyp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp Changeset: 0db4adb6e914 Author: tonyp Date: 2009-03-07 11:07 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0db4adb6e914 6810698: G1: two small bugs in the sparse remembered sets Summary: The _expanded flag of the sparse RSets is not reset and this can leave a RSet in an inconsistent state if it is expanded more than once. Also, we should be iterating over the _cur, instead of the _next, sparse table Reviewed-by: apetrusenko, iveresov ! src/share/vm/gc_implementation/g1/sparsePRT.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp Changeset: ae1579717a57 Author: tonyp Date: 2009-03-07 11:07 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ae1579717a57 6812428: G1: Error: assert(ret || obj_in_cs(obj),"sanity") Summary: The length of the fast cset test vector is decided at the beginning of a GC, but more regions can be added during the GC. The simple fix is to set the length of the fast cset test vector to the max. Reviewed-by: iveresov ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 7ea5ca260b28 Author: tonyp Date: 2009-03-07 11:07 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7ea5ca260b28 6814467: G1: small fixes related to concurrent marking verboseness Summary: A few small fixes to remove some inconsistencies in the concurrent mark-related verbose GC output. Reviewed-by: jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: bcedf688d882 Author: tonyp Date: 2009-03-09 11:32 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/bcedf688d882 Merge ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/runtime/os.cpp Changeset: 19f25e603e7b Author: kvn Date: 2009-03-03 18:25 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/19f25e603e7b 6812721: Block's frequency should not be NaN Summary: Set MIN_BLOCK_FREQUENCY block's frequency when calculated block's frequency is NaN Reviewed-by: never ! src/share/vm/opto/gcm.cpp Changeset: 56aae7be60d4 Author: jrose Date: 2009-03-04 09:58 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/56aae7be60d4 6812678: macro assembler needs delayed binding of a few constants (for 6655638) Summary: minor assembler enhancements preparing for method handles Reviewed-by: kvn ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_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/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp Changeset: 9adddb8c0fc8 Author: jrose Date: 2009-03-06 21:36 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9adddb8c0fc8 6812831: factor duplicated assembly code for megamorphic invokeinterface (for 6655638) Summary: Code in vtableStubs and templateTable moved into MacroAssembler. Reviewed-by: kvn ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/vtableStubs_x86_32.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp Changeset: 337400e7a5dd Author: twisti Date: 2009-03-09 03:17 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/337400e7a5dd 6797305: Add LoadUB and LoadUI opcode class Summary: Add a LoadUB (unsigned byte) and LoadUI (unsigned int) opcode class so we have these load optimizations in the first place and do not need to handle them in the matcher. Reviewed-by: never, kvn ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/forms.cpp ! src/share/vm/adlc/forms.hpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/mulnode.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp + test/compiler/6797305/Test6797305.java Changeset: 2f2f54ed12ce Author: kvn Date: 2009-03-10 08:52 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2f2f54ed12ce Merge ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp Changeset: 87fa6e083d82 Author: apetrusenko Date: 2009-03-10 00:47 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/87fa6e083d82 6760309: G1: update remembered sets during Full GCs Reviewed-by: iveresov, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: fcf566137dbf Author: tonyp Date: 2009-03-12 11:34 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/fcf566137dbf Merge Changeset: 7bb995fbd3c0 Author: trims Date: 2009-03-12 18:16 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7bb995fbd3c0 Merge ! make/linux/makefiles/adlc.make ! make/solaris/makefiles/adlc.make ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp - src/cpu/x86/vm/vm_version_x86_32.cpp - src/cpu/x86/vm/vm_version_x86_32.hpp - src/cpu/x86/vm/vm_version_x86_64.cpp - src/cpu/x86/vm/vm_version_x86_64.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/dfa.cpp ! src/share/vm/adlc/dict2.cpp ! src/share/vm/adlc/filebuff.hpp ! src/share/vm/adlc/forms.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/includeDB_core ! src/share/vm/includeDB_gc ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/libadt/dict.cpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/utilities/vmError.cpp ! src/share/vm/utilities/vmError.hpp Changeset: 2581d90c6c9b Author: trims Date: 2009-03-12 18:17 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2581d90c6c9b 6816970: Bump HS15 build number to 03 Summary: Update the HS15 Build number to 03 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 1b1e8f1a4fe8 Author: xdono Date: 2009-03-19 13:25 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1b1e8f1a4fe8 Added tag jdk7-b51 for changeset 2581d90c6c9b ! .hgtags From tim.bell at sun.com Sun Mar 22 00:38:19 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Sun, 22 Mar 2009 00:38:19 +0000 Subject: hg: jdk7/tl/jaxp: Added tag jdk7-b51 for changeset ae890d80d5df Message-ID: <20090322003821.8348CE688@hg.openjdk.java.net> Changeset: 69ad87dc25cb Author: xdono Date: 2009-03-19 13:25 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/69ad87dc25cb Added tag jdk7-b51 for changeset ae890d80d5df ! .hgtags From tim.bell at sun.com Sun Mar 22 00:41:24 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Sun, 22 Mar 2009 00:41:24 +0000 Subject: hg: jdk7/tl/jaxws: Added tag jdk7-b51 for changeset 41a66a42791b Message-ID: <20090322004126.5BEA4E68D@hg.openjdk.java.net> Changeset: e646890d18b7 Author: xdono Date: 2009-03-19 13:25 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/e646890d18b7 Added tag jdk7-b51 for changeset 41a66a42791b ! .hgtags From tim.bell at sun.com Sun Mar 22 00:44:43 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Sun, 22 Mar 2009 00:44:43 +0000 Subject: hg: jdk7/tl/jdk: 6 new changesets Message-ID: <20090322004554.E1213E692@hg.openjdk.java.net> Changeset: 711a9fb838d1 Author: ohair Date: 2009-03-16 11:24 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/711a9fb838d1 6816311: Changes to allow builds with latest Windows SDK 6.1 on 64bit Windows 2003 Summary: These changes create a preference for the newer 6.1 SDK on Windows. Reviewed-by: tbell ! make/common/Defs-windows.gmk ! make/common/shared/Compiler-gcc.gmk ! make/common/shared/Compiler-msvc.gmk ! make/common/shared/Compiler-sun.gmk ! make/common/shared/Defs-versions.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Sanity-Settings.gmk ! make/common/shared/Sanity.gmk ! src/windows/native/sun/windows/awt.rc ! src/windows/resource/version.rc Changeset: ece878b04159 Author: xdono Date: 2009-03-16 16:18 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ece878b04159 Merge Changeset: bdb4b0b28407 Author: ohair Date: 2009-03-17 13:44 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bdb4b0b28407 6818565: Regression with fix 6816311: COMPILER_VERSION -> REQUIRED_COMPILER_VERSION Reviewed-by: tbell - make/common/shared/Compiler.gmk ! make/common/shared/Defs-solaris.gmk ! make/common/shared/Defs.gmk Changeset: fea0898259ae Author: ohair Date: 2009-03-17 13:45 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fea0898259ae Merge Changeset: bcbeadb4a5d7 Author: xdono Date: 2009-03-19 13:25 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bcbeadb4a5d7 Added tag jdk7-b51 for changeset fea0898259ae ! .hgtags Changeset: cc8ffb0fc1a4 Author: tbell Date: 2009-03-21 13:52 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cc8ffb0fc1a4 Merge - src/share/classes/sun/misc/JavaIODeleteOnExitAccess.java From tim.bell at sun.com Sun Mar 22 00:55:11 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Sun, 22 Mar 2009 00:55:11 +0000 Subject: hg: jdk7/tl/langtools: 2 new changesets Message-ID: <20090322005514.D174CE697@hg.openjdk.java.net> Changeset: 29329051d483 Author: xdono Date: 2009-03-19 13:25 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/29329051d483 Added tag jdk7-b51 for changeset 8c55d5b0ed71 ! .hgtags Changeset: 3bf905cb80e7 Author: tbell Date: 2009-03-21 13:53 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/3bf905cb80e7 Merge From Ulf.Zibis at gmx.de Sun Mar 22 08:10:56 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sun, 22 Mar 2009 09:10:56 +0100 Subject: Setup Netbeans project - Please help! In-Reply-To: <49C4170C.9060601@sun.com> References: <49C16E46.9040609@sun.com> <49C23DE2.5010901@gmx.de> <49C23FA2.4000409@sun.com> <49C2BE03.1040700@gmx.de> <49C4170C.9060601@sun.com> Message-ID: <49C5F290.6070801@gmx.de> Hi Alan, I've opened the JConsole project from JDK7 b51 sources and ran into some errors. See attachment. Can you give me some hints? When I set .openjdk\build.properties to: bootstrap.jdk=C:/Programme/Java/jdk1.7.0 the compile warning disappears, but the errors in editor remain. I think, JConsole project would be a good "template" to create my own "nio-charset" project. Additionally, I don't see how to connect to the Mercurial repository. There is no "Mercurial" menu item on projects node, although there are plenty .hg* files in the project.. From Subversion I'm used to have "Subversion" menu item automatically if the .svn folders are present in project. -Ulf Am 20.03.2009 23:22, Alan Bateman schrieb: > Ulf Zibis wrote: >> : >> Alan, yes, I'm considering this. I regularly observe the regarding >> changes from jdk6 to jdk7, to be up to date. >> The SingleByte.java approach consumes little more memory for encoder >> maps than legacy jdk6 SingleByteDecoder, so my approach only consumes >> 20 % against this. Disk-footprint of SingleByte.java approach is 25 % >> against the legacy JDK 6 implementation, but initializing the b2c >> char[] needs copying the internal char[] from String constant and >> then throwing it to GC. >> >> In my current project, I only build a patch-jar using NetBeans 6.5, >> which I preload via -Xbootclasspath to test it using JUnit 4.5. >> This works fine on my system, after I've solved some tricky problems >> (using same JDK version for running my code + running NetBeans didn't >> work) >> >> Creating changesets against JDK7, I think, It's a must to also >> provide working MAKE + TEST stuff. >> So (1.) I should install a jdk build environment on my computer, but >> I hesitated until now because of: >> - I only have 60 GB disk 1.5 GB ram 2 GHz single core mobile computer >> for all my work including private stuff. Does that smoothly work ? > Yes, it's possible to build with this spec. The only thing is you are > on Windows and this is much harder to setup for the build when > compared to Linux or Solaris. > >> - I only have MS VS 6 enterprise, but MS VS 2008 is required to build >> JDK7. Is there any chance without that, if I don't touch native code ? > Currently we use VC7 (Visual Studio .NET 2003) but are in transition. > I think the jdk repository will build with the express (free) > compilers but I'll need to check on the status of that. For what you > are doing it may be that you don't care about native code so running > with patches that are prepended to the bootclasspath is okay. > > -Alan. > > -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenJDK - JConsole Errors.jpg Type: image/jpeg Size: 62894 bytes Desc: not available URL: From Ulf.Zibis at gmx.de Sun Mar 22 13:45:39 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sun, 22 Mar 2009 14:45:39 +0100 Subject: Setup OpenJDK Netbeans project - Please help! In-Reply-To: <49C5F290.6070801@gmx.de> References: <49C16E46.9040609@sun.com> <49C23DE2.5010901@gmx.de> <49C23FA2.4000409@sun.com> <49C2BE03.1040700@gmx.de> <49C4170C.9060601@sun.com> <49C5F290.6070801@gmx.de> Message-ID: <49C64103.7030700@gmx.de> Hi All, I've downloaded the b51 snapshot. How to make this a Mercurial Working Copy? Please see my problem in the attachment. Thanks in advance, Ulf -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenJDK - Mercurial Clone error.jpg Type: image/jpeg Size: 69032 bytes Desc: not available URL: From Alan.Bateman at Sun.COM Sun Mar 22 19:29:25 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Sun, 22 Mar 2009 19:29:25 +0000 Subject: Setup Netbeans project - Please help! In-Reply-To: <49C5F290.6070801@gmx.de> References: <49C16E46.9040609@sun.com> <49C23DE2.5010901@gmx.de> <49C23FA2.4000409@sun.com> <49C2BE03.1040700@gmx.de> <49C4170C.9060601@sun.com> <49C5F290.6070801@gmx.de> Message-ID: <49C69195.6050701@sun.com> Ulf Zibis wrote: > Hi Alan, > > I've opened the JConsole project from JDK7 b51 sources and ran into > some errors. See attachment. > > Can you give me some hints? > > When I set .openjdk\build.properties to: > bootstrap.jdk=C:/Programme/Java/jdk1.7.0 > the compile warning disappears, but the errors in editor remain. > > I think, JConsole project would be a good "template" to create my own > "nio-charset" project. > > Additionally, I don't see how to connect to the Mercurial repository. > There is no "Mercurial" menu item on projects node, although there are > plenty .hg* files in the project.. > From Subversion I'm used to have "Subversion" menu item automatically > if the .svn folders are present in project. > > -Ulf Ulf - I'm not very familiar with the NB projects that are in the repository but if you send mail to nb-projects-dev at openjdk.java.net then I'm sure that Daniel Fuchs or others will be able to help you get this running. As there is some code generation during the build then it may be challenging to setup as a standalone project. AFAIK, the mercurial plugin is part of the base IDE (Versioning menu -> Mercurial). -Alan. From Alan.Bateman at Sun.COM Sun Mar 22 19:50:08 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Sun, 22 Mar 2009 19:50:08 +0000 Subject: Setup OpenJDK Netbeans project - Please help! In-Reply-To: <49C64103.7030700@gmx.de> References: <49C16E46.9040609@sun.com> <49C23DE2.5010901@gmx.de> <49C23FA2.4000409@sun.com> <49C2BE03.1040700@gmx.de> <49C4170C.9060601@sun.com> <49C5F290.6070801@gmx.de> <49C64103.7030700@gmx.de> Message-ID: <49C69670.8090008@sun.com> Ulf Zibis wrote: > Hi All, > > I've downloaded the b51 snapshot. > > How to make this a Mercurial Working Copy? It looks like you've already done the fclone, in which case the contents of the directories is the working copy. You might want to spent a bit of time working through Bryan O?Sullivan's (online) book on Mercurial to get acquainted with the concepts. -Alan. From Xueming.Shen at Sun.COM Sun Mar 22 21:47:36 2009 From: Xueming.Shen at Sun.COM (Xueming Shen) Date: Sun, 22 Mar 2009 13:47:36 -0800 Subject: Review request for 100020 (sunbug=6819886) In-Reply-To: <49C3C73F.6090004@sun.com> References: <49C3C73F.6090004@sun.com> Message-ID: <49C6B1F8.3040609@sun.com> Looks fine, approved. - Sherman Alan Bateman wrote: > > Bug 100020 (https://bugs.openjdk.java.net/show_bug.cgi?id=100020) is a > fix from Andreas Frischknecht. In summary File#lastModified, on > Windows, uses GetFileTime to get the timestamp but doesn't check the > result. This bites when accessing a remote file at just around the > time that the file is deleted. Good sleuthing on the part of Andreas! > As it only duplicates when accessing a file over SMB we don't propose > to include a regression test. > > The webrev is here: > http://cr.openjdk.java.net/~alanb/6819689/webrev.00/ > > Thanks, > Alan. > > From sylvain.laurent at m4x.org Sun Mar 22 22:23:32 2009 From: sylvain.laurent at m4x.org (Sylvain Laurent) Date: Sun, 22 Mar 2009 23:23:32 +0100 Subject: java.lang.Thread.contextClassLoader : what if it were a weak reference ? Message-ID: <770FDE52-A356-4E35-98BA-8C812B923B5D@m4x.org> Hello all, I'm tracking classloader leaks more or less as a hobby and found out that one of the (many) source of leaks come from threads that still have a reference to a classloader through their contextClassLoader instance variable. So, I'm wondering : what if instead of "private ClassLoader contextClassLoader;" we had "private WeakReference contextClassLoaderRef" and the method getContextClassLoader would more or less returned contextClassLoaderRef.get() ? Would it break many things ? is it incompatible with the specs ? I'm very interested to read your opinion on this... Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Mon Mar 23 03:24:13 2009 From: martinrb at google.com (Martin Buchholz) Date: Sun, 22 Mar 2009 20:24:13 -0700 Subject: RFE 4519026: (process) Process should support Unicode on Win NT, request for review In-Reply-To: <90B150C4E9484A0891F55FE693B760A0@HeikoXP> References: <1ccfd1c10903161832t18f0477wdf21e63d10b72c99@mail.gmail.com> <90B150C4E9484A0891F55FE693B760A0@HeikoXP> Message-ID: <1ccfd1c10903222024x2ba35830r2df1b4e2b9d103f9@mail.gmail.com> Heiko, Thanks for your continuing work on this. ProcessBuilder/Basic.java has most of the tests related to subprocesses. I can't explain a return code of 6, since the test uses 5, 7, and 8. ProcessBuilder has a lot of infrastructure to help you write a test in this area, but it can be intimidating to newcomers (i.e. anyone but myself). The JDK C code is quite inconsistent, but please use the style /* * comments * here */ for block comments, and /* inline comments */ like this. You need to remove the comment /* selected based on exe type */ which is no longer correct. If you fix the style things, and get the tests to pass, and add a test for what you're actually trying to fix, I am ready to approve the change. Martin On Fri, Mar 20, 2009 at 03:33, Heiko Wagner wrote: > Thanks for your reply. I have updated both the source file and the diff > file. (URL see in previous post below) > I have made the following changes: > > - replace C++ style comments with plain C style comments > - replace tabs with spaces in source (maybe using VC 2008 as editor in the > first place was no good idea ;-)) > - remove function releaseStringCopy and call free() directly > - fix the types you suggested "path.md.c => path_md.c" and "*(res + len) = > 0; => res[len] = ?L'\0';" > > I have tried to set up jtreg and run the regression tests. Somehow, I still > haven't managed to get all things > working. Some tests in ProcessBuilder/Basic.java fail, because the exit code > of the invocation of the java child > is 6 insted of 0. I am still working on that issue. > > P.S.: Is there any kind of guide line how to write the comments, so I can > fix them as well? > > > -----Original Message----- > From: Martin Buchholz [mailto:martinrb at google.com] > Sent: Dienstag, 17. M?rz 2009 02:32 > To: Heiko Wagner > Cc: core-libs-dev at openjdk.java.net; Xueming Shen; Alan Bateman > Subject: Re: RFE 4519026: (process) Process should support Unicode on > Win NT, request for review > > > Sorry for the delayed response. ?I've been busy. > (Probably I should not have volunteered for this review.) > > Heiko, thanks for the patch. > > JDK engineers (Xueming, Alan?) will need to help > with testing, architectural issues, and shepherding. > I no longer use windows. > > I approve of the general approach being taken here. > We need a general purpose version of JVM_NativePath, > as you have coded it up, but it needs to go into some shared location > for use by other JDK native code - not sure quite where that would be. > I guess until we have another client for it, living > in ProcessImpl_md.c is not so bad. > > Make sure you run the java.lang regression tests, especially > ProcessBuilder/Basic.java > > There's a fair bit of cleanup that will be required. > Use of white space and commenting style are non-standard > and will need to be fixed (even if you've copied them > from other parts of the JDK) > > I think the spec for free() guarantees that free(null) is a no-op, > and the JDK already relies on this, so no need for > releaseStringCopy. > > Typos/suggestions: > > path.md.c => path_md.c > > *(res + len) = 0; => res[len] = ?L'\0'; > > Martin > > > On Mon, Mar 9, 2009 at 02:57, Heiko Wagner wrote: >> This is related to my previous post at >> > http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-February/001145.ht >> ml and my first contribution to the JDK7 project. As Martin suggested, I >> have worked on a wide char version of ProcessImpl_md.c. For discussion of > my >> proposed chages a copy of my source can be found at: >> >> http://www.apis.de/pub/jdk7/ProcessImpl_md.c >> >> and a diff at: >> >> http://www.apis.de/pub/jdk7/ProcessImpl_md.c.diff >> >> This patch enables launching executables residing on a path containing >> non-ansi characters. My next goal is to get the java launcher working on a >> unicode path. I think this needs additional coordination with the hotspot >> team, since some of the code in os.cpp also has issues in a unicode path >> when loading verify.dll and java.dll. >> >> Regards >> Heiko >> >> > > From weijun.wang at sun.com Mon Mar 23 09:12:40 2009 From: weijun.wang at sun.com (weijun.wang at sun.com) Date: Mon, 23 Mar 2009 09:12:40 +0000 Subject: hg: jdk7/tl/jdk: 6820606: keytool can generate serialno more randomly Message-ID: <20090323091259.B7ECAE6D6@hg.openjdk.java.net> Changeset: 74fe20f0e49b Author: weijun Date: 2009-03-23 17:05 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/74fe20f0e49b 6820606: keytool can generate serialno more randomly Reviewed-by: xuelei ! src/share/classes/sun/security/tools/KeyTool.java ! src/share/classes/sun/security/x509/CertAndKeyGen.java From heiko.wagner at apis.de Mon Mar 23 10:56:48 2009 From: heiko.wagner at apis.de (Heiko Wagner) Date: Mon, 23 Mar 2009 11:56:48 +0100 Subject: RFE 4519026: (process) Process should support Unicode on Win NT, request for review In-Reply-To: <1ccfd1c10903222024x2ba35830r2df1b4e2b9d103f9@mail.gmail.com> Message-ID: <79DCAA64DFAC49619FA1018B43C2C5E1@HeikoXP> Thanks for the description of the comment writing style. I have investigated, why I get a return code of 6. This return code indicates that java.exe launcher fails to start the Java VM. I will try to explain step by step. ;-) This is the test code that fails: try { ProcessBuilder pb = new ProcessBuilder(); pb.environment().clear(); equal(getenvInChild(pb), ""); } catch (Throwable t) { unexpected(t); } 1) this code does start the java.exe 2) java.exe tries to start the Java VM in function LoadJavaVM 3) LoadJavaVM tries to load the jvm.dll via LoadLibrary 4) LoadLibrary loads the jvm.dll and it's dependent libraries, in particular the C runtime lib 5) loading of the MSCV90.DLL fails with error message: "Unable to resolve storage root for assembly directory x86_Microsoft.VC90.CRT" This is caused by the "pb.environment().clear()", because it clears the env variable %SystemRoot%. 6) LoadLibrary fails due to missing dependencies, thus causing java.exe fail with exit code 6 You might not experience this problem, when you compile the JDK with an oder MS VC++ version. According to the build readme in the JDK VS2008 is required ("...The 32-bit OpenJDK Windows build requires Microsoft Visual Studio C++ 2008 (VS2008) Standard Edition compiler..."), but it seems the binary build downloads on the openJDK site use an older version of Visual Studio. -----Original Message----- From: Martin Buchholz [mailto:martinrb at google.com] Sent: Montag, 23. M?rz 2009 04:24 To: Heiko Wagner Cc: core-libs-dev at openjdk.java.net; Xueming Shen; Alan Bateman Subject: Re: RFE 4519026: (process) Process should support Unicode on Win NT, request for review Heiko, Thanks for your continuing work on this. ProcessBuilder/Basic.java has most of the tests related to subprocesses. I can't explain a return code of 6, since the test uses 5, 7, and 8. ProcessBuilder has a lot of infrastructure to help you write a test in this area, but it can be intimidating to newcomers (i.e. anyone but myself). The JDK C code is quite inconsistent, but please use the style /* * comments * here */ for block comments, and /* inline comments */ like this. You need to remove the comment /* selected based on exe type */ which is no longer correct. If you fix the style things, and get the tests to pass, and add a test for what you're actually trying to fix, I am ready to approve the change. Martin From Thomas.Hawtin at Sun.COM Mon Mar 23 11:11:39 2009 From: Thomas.Hawtin at Sun.COM (Tom Hawtin) Date: Mon, 23 Mar 2009 11:11:39 +0000 Subject: java.lang.Thread.contextClassLoader : what if it were a weak reference ? In-Reply-To: <770FDE52-A356-4E35-98BA-8C812B923B5D@m4x.org> References: <770FDE52-A356-4E35-98BA-8C812B923B5D@m4x.org> Message-ID: <49C76E6B.7060404@sun.com> Sylvain Laurent wrote: > > I'm tracking classloader leaks more or less as a hobby and found out > that one of the (many) source of leaks come from threads that still have > a reference to a classloader through their contextClassLoader instance > variable. > > So, I'm wondering : what if instead of > "private ClassLoader contextClassLoader;" we had "private > WeakReference contextClassLoaderRef" and the method > getContextClassLoader would more or less > returned contextClassLoaderRef.get() ? > > Would it break many things ? is it incompatible with the specs ? How much it would break, I wouldn't like to guess. Incompatible? Yes. It is legitimate to use a class loader only through Thread.getContextClassLoader. As for solutions: I guess containers could add a fake context class loader with a weak reference to the real one (perhaps parent could optionally become a weak reference?). Really there needs to be more care taken when creating threads to make sure the context class loader (and indeed InheritableThreadLocals) are inherited only when appropriate. Tom Hawtin From Ulf.Zibis at gmx.de Mon Mar 23 12:38:57 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 23 Mar 2009 13:38:57 +0100 Subject: Setup OpenJDK Netbeans project - Please help! In-Reply-To: <49C69195.6050701@sun.com> References: <49C16E46.9040609@sun.com> <49C23DE2.5010901@gmx.de> <49C23FA2.4000409@sun.com> <49C2BE03.1040700@gmx.de> <49C4170C.9060601@sun.com> <49C5F290.6070801@gmx.de> <49C69195.6050701@sun.com> Message-ID: <49C782E1.5060400@gmx.de> Am 22.03.2009 20:29, Alan Bateman schrieb: > Ulf Zibis wrote: >> Hi Alan, >> >> I've opened the JConsole project from JDK7 b51 sources and ran into >> some errors. See attachment. >> >> Can you give me some hints? >> >> When I set .openjdk\build.properties to: >> bootstrap.jdk=C:/Programme/Java/jdk1.7.0 >> the compile warning disappears, but the errors in editor remain. >> >> I think, JConsole project would be a good "template" to create my own >> "nio-charset" project. >> >> Additionally, I don't see how to connect to the Mercurial repository. >> There is no "Mercurial" menu item on projects node, although there >> are plenty .hg* files in the project.. >> From Subversion I'm used to have "Subversion" menu item automatically >> if the .svn folders are present in project. >> >> -Ulf > Ulf - I'm not very familiar with the NB projects that are in the > repository but if you send mail to nb-projects-dev at openjdk.java.net > then I'm sure that Daniel Fuchs or others will be able to help you get > this running. As there is some code generation during the build then > it may be challenging to setup as a standalone project. AFAIK, the > mercurial plugin is part of the base IDE (Versioning menu -> Mercurial). > > -Alan. > Thanks Alan. I hesitated to post to nb-projects-dev at openjdk.java.net, because there was no traffic since August 2008. But I'll give it a try. The error annotations in NetBeans for JConsole project, I guess, are result of a NB bug, because the build runs without error. The hg support from NetBeans didn't work, because the local .hg repository wasn't existent, so I created it by "Create Repository". After this, I think, I should commit the WC into it, but I hesitate, because I don't want to have an additional 250 MB copy of the whole jdk on my harddisk. I have to be economic with diskspace. I would be happy, if there would be a way, only to push the parts in the repository which I'm working on. Do you have some hint, how to solve this problem? Does it work, if I only commit the folder, which I'm working on? I also did a clone of http://hg.openjdk.java.net/jdk7/jdk7. This clone only contained some few make files, so I don't know what to do with it. -Ulf From Alan.Bateman at Sun.COM Mon Mar 23 12:56:06 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Mon, 23 Mar 2009 12:56:06 +0000 Subject: RFE 4519026: (process) Process should support Unicode on Win NT, request for review In-Reply-To: <79DCAA64DFAC49619FA1018B43C2C5E1@HeikoXP> References: <79DCAA64DFAC49619FA1018B43C2C5E1@HeikoXP> Message-ID: <49C786E6.7070607@sun.com> Heiko Wagner wrote: > Thanks for the description of the comment writing style. I have > investigated, why I get a return code of 6. This return code indicates that > java.exe launcher fails to start the Java VM. I will try to explain step by > step. ;-) > > This is the test code that fails: > > try { > ProcessBuilder pb = new ProcessBuilder(); > pb.environment().clear(); > equal(getenvInChild(pb), ""); > } catch (Throwable t) { unexpected(t); } > > 1) this code does start the java.exe > 2) java.exe tries to start the Java VM in function LoadJavaVM > 3) LoadJavaVM tries to load the jvm.dll via LoadLibrary > 4) LoadLibrary loads the jvm.dll and it's dependent libraries, in particular > the C runtime lib > 5) loading of the MSCV90.DLL fails with error message: > "Unable to resolve storage root for assembly directory > x86_Microsoft.VC90.CRT" > This is caused by the "pb.environment().clear()", because it clears the > env variable %SystemRoot%. > 6) LoadLibrary fails due to missing dependencies, thus causing java.exe fail > with exit code 6 > > You might not experience this problem, when you compile the JDK with an oder > MS VC++ version. According to the build readme in the JDK VS2008 is required > ("...The 32-bit OpenJDK Windows build requires Microsoft Visual Studio C++ > 2008 (VS2008) Standard Edition compiler..."), but it seems the binary build > downloads on the openJDK site use an older version of Visual Studio. > This does seems to be an environment issue. I ran this test with b51 on Windows XP and it fails for each case where the child is created without SystemRoot in the environment. This build was done with VC7/.NET 2003. I hacked the test to ensure that this variable is inherited from the parent and the modified tests works as expected. I also grabbed your changes and patched my src/windows/native/java/lang/ProcessImpl.c and all Runtime and ProcessBuilder tests are passing. -Alan. From Alan.Bateman at Sun.COM Mon Mar 23 14:10:07 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Mon, 23 Mar 2009 14:10:07 +0000 Subject: Setup OpenJDK Netbeans project - Please help! In-Reply-To: <49C782E1.5060400@gmx.de> References: <49C16E46.9040609@sun.com> <49C23DE2.5010901@gmx.de> <49C23FA2.4000409@sun.com> <49C2BE03.1040700@gmx.de> <49C4170C.9060601@sun.com> <49C5F290.6070801@gmx.de> <49C69195.6050701@sun.com> <49C782E1.5060400@gmx.de> Message-ID: <49C7983F.5010408@sun.com> Ulf Zibis wrote: > : > Thanks Alan. > I hesitated to post to nb-projects-dev at openjdk.java.net, because there > was no traffic since August 2008. But I'll give it a try. > > The error annotations in NetBeans for JConsole project, I guess, are > result of a NB bug, because the build runs without error. AFAIK, there are two compilers in NetBeans. A "standard" javac that is used for the full builds and a patched version that runs while you edit. If I understand your screenshot then your issue is with the latter. Someone more familiar with the environment may know how to configure it and I'm sure someone on nb-projects-dev will be able to help. > > The hg support from NetBeans didn't work, because the local .hg > repository wasn't existent, so I created it by "Create Repository". > After this, I think, I should commit the WC into it, but I hesitate, > because I don't want to have an additional 250 MB copy of the whole > jdk on my harddisk. I have to be economic with diskspace. I would be > happy, if there would be a way, only to push the parts in the > repository which I'm working on. Do you have some hint, how to solve > this problem? Does it work, if I only commit the folder, which I'm > working on? > I also did a clone of http://hg.openjdk.java.net/jdk7/jdk7. This clone > only contained some few make files, so I don't know what to do with it. OpenJDK uses the forest extension so to get all the repositories you need to "fclone" jdk7/jdk7 (not "clone"). However, if disk space is a problem and it sounds like you are only interested in the jdk repository then you could clone jdk7/jdk7/jdk. You might want to read through the developers guide to get familiar with the trees in the forest. Once you have a clone then you shouldn't need to "Create Repository" (which I assume is the GUI equivalent of "hg init"). I don't know if it possible to work with partial repositories but Mercurial seems to be very efficient in storage terms. -Alan. From martinrb at google.com Mon Mar 23 15:43:54 2009 From: martinrb at google.com (Martin Buchholz) Date: Mon, 23 Mar 2009 08:43:54 -0700 Subject: RFE 4519026: (process) Process should support Unicode on Win NT, request for review In-Reply-To: <49C786E6.7070607@sun.com> References: <79DCAA64DFAC49619FA1018B43C2C5E1@HeikoXP> <49C786E6.7070607@sun.com> Message-ID: <1ccfd1c10903230843g3bad234ak8b1e71a27dd449bc@mail.gmail.com> It's nice to use environment().clear() in tests, for testability, but environment().clear() has the problem that runtime environments on both Unix and Windows implicitly depend on certain environment variables to be able to do anything. E.g. you may someday end up with tests failing on unix due to KRB5CCNAME undefined. So environment().clear() is a bad idea for reliable code (and before ProcessBuilder, you had no choice; Runtime.exec API did it implicitly) Still, we would like to have tests for it. We could make tests more robust by whitelisting a set of environment variables added back in after clear(), which would include SystemRoot on Windows, and perhaps likely suspects like PATH and KRB5CCNAME. Heiko, that would be a difficult change to get right, and perhaps impossible to get 100% right if you take into consideration environment variable values that don't survive round-trip decoding-encoding intact or that contain newlines. So this would not be necessary to get my approval (it's a pre-existing test failure). Also, FYI, it is my understanding that pre-2008 versions of the Microsoft compiler are still supported. It would be my hope that as many versions as practical would be supported, since these products cost real money. Martin On Mon, Mar 23, 2009 at 05:56, Alan Bateman wrote: > Heiko Wagner wrote: >> >> Thanks for the description of the comment writing style. I have >> investigated, why I get a return code of 6. This return code indicates >> that >> java.exe launcher fails to start the Java VM. I will try to explain step >> by >> step. ;-) >> >> This is the test code that fails: >> >> ? ? ? ?try { >> ? ? ? ? ? ?ProcessBuilder pb = new ProcessBuilder(); >> ? ? ? ? ? ?pb.environment().clear(); >> ? ? ? ? ? ?equal(getenvInChild(pb), ""); >> ? ? ? ?} catch (Throwable t) { unexpected(t); } >> >> 1) this code does start the java.exe >> 2) java.exe tries to start the Java VM in function LoadJavaVM >> 3) LoadJavaVM tries to load the jvm.dll via LoadLibrary >> 4) LoadLibrary loads the jvm.dll and it's dependent libraries, in >> particular >> the C runtime lib >> 5) loading of the MSCV90.DLL fails with error message: >> ? "Unable to resolve storage root for assembly directory >> x86_Microsoft.VC90.CRT" >> ? This is caused by the "pb.environment().clear()", because it clears the >> env variable %SystemRoot%. >> 6) LoadLibrary fails due to missing dependencies, thus causing java.exe >> fail >> with exit code 6 >> >> You might not experience this problem, when you compile the JDK with an >> oder >> MS VC++ version. According to the build readme in the JDK VS2008 is >> required >> ("...The 32-bit OpenJDK Windows build requires Microsoft Visual Studio C++ >> 2008 (VS2008) Standard Edition compiler..."), but it seems the binary >> build >> downloads on the openJDK site use an older version of Visual Studio. >> > > This does seems to be an environment issue. I ran this test with b51 on > Windows XP and it fails for each case where the child is created without > SystemRoot in the environment. This build ?was done with VC7/.NET 2003. I > hacked the test to ensure that this variable is inherited from the parent > and the modified tests works as expected. I also grabbed your changes and > patched my src/windows/native/java/lang/ProcessImpl.c and all Runtime and > ProcessBuilder tests are passing. > > -Alan. > From Alan.Bateman at Sun.COM Mon Mar 23 16:38:13 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Mon, 23 Mar 2009 16:38:13 +0000 Subject: Review request for 6693490 Message-ID: <49C7BAF5.6040900@sun.com> 6693490: (se) select throws "File exists" IOException under load (lnx) Sherman, we've chatted about this issue so you will probably want to review. It's a race between registration (or re-registration) and close. Registrations are queued so that they come into effect at the next select (as required by the spec) but if the channel is pre-closed just before it is added to epoll then it possible that the socketpair, used in the closing mechanism, gets registered with epoll. Once that happens it creates the conditions to cause a Selector spin, and where the file descriptor is recycled for a new SelectableChannel, then registration will fail with IOException "file exists". The fix is to remove from epoll before the channel is killed and to skip pending updates for closed channels (as these can result in re-registration). To avoid any side effects with cancellation the deregister also purges pending updates for the channel. Thanks to Serge Baranov, Robert Larsen, Peter van Rensburg, Richard Ridgway, Greg Wilkins and others for testing this fix, or preliminary versions of. The webrev is here: http://cr.openjdk.java.net/~alanb/6693490/webrev.00 Thanks, -Alan. From xueming.shen at sun.com Mon Mar 23 16:39:58 2009 From: xueming.shen at sun.com (xueming.shen at sun.com) Date: Mon, 23 Mar 2009 16:39:58 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20090323164022.577B0E703@hg.openjdk.java.net> Changeset: 4faf788c4949 Author: sherman Date: 2009-03-23 09:19 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4faf788c4949 6636323: Optimize handling of builtin charsets 6636319: Encoders should implement isLegalReplacement(byte[] repl) Summary: optimized new String(byte[], cs/csn) and String.getBytes(cs/csn) for speed and memory consumption in singlebyte case. Reviewed-by: alanb ! make/java/nio/FILES_java.gmk ! src/share/classes/java/lang/StringCoding.java + src/share/classes/sun/nio/cs/ArrayDecoder.java + src/share/classes/sun/nio/cs/ArrayEncoder.java ! src/share/classes/sun/nio/cs/ISO_8859_1.java ! src/share/classes/sun/nio/cs/SingleByte.java ! src/share/classes/sun/nio/cs/US_ASCII.java ! test/sun/nio/cs/FindEncoderBugs.java + test/sun/nio/cs/StrCodingBenchmark.java + test/sun/nio/cs/TestStringCoding.java Changeset: b9cc5da6c516 Author: sherman Date: 2009-03-23 09:34 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b9cc5da6c516 Merge From Alan.Bateman at Sun.COM Mon Mar 23 17:55:41 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Mon, 23 Mar 2009 17:55:41 +0000 Subject: RFE 4519026: (process) Process should support Unicode on Win NT, request for review In-Reply-To: <1ccfd1c10903230843g3bad234ak8b1e71a27dd449bc@mail.gmail.com> References: <79DCAA64DFAC49619FA1018B43C2C5E1@HeikoXP> <49C786E6.7070607@sun.com> <1ccfd1c10903230843g3bad234ak8b1e71a27dd449bc@mail.gmail.com> Message-ID: <49C7CD1D.5060900@sun.com> Martin Buchholz wrote: > : > > We could make tests more robust by whitelisting a set of > environment variables added back in after clear(), > which would include SystemRoot on Windows, and perhaps > likely suspects like PATH and KRB5CCNAME. > Heiko, that would be a difficult change to get right, > and perhaps impossible to get 100% right if you take > into consideration environment variable values that > don't survive round-trip decoding-encoding intact or > that contain newlines. So this would not be necessary > to get my approval (it's a pre-existing test failure). > I agree. I'm finally looking at the patch and it mostly look good. I'm not an expert on the Process code but is the directory already normalized at this point? Just wondering if all of getNativePath is needed. -Alan. From Alan.Bateman at Sun.COM Mon Mar 23 17:57:03 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Mon, 23 Mar 2009 17:57:03 +0000 Subject: Review request for 6666739 and 6711667 Message-ID: <49C7CD6F.5020708@sun.com> 6666739: (ref) ReferenceQueue.poll() doesn't scale well 6711667: (ref) Update SoftReference timestamp only if clock advances This is forward-port from 6u14 of two scalability fixes. These were original fixed by Tom Rodriguez in an earlier update. The webrev is here: http://cr.openjdk.java.net/~alanb/6666739%2b6711667/webrev.00/ Thanks, Alan. From martinrb at google.com Mon Mar 23 18:19:49 2009 From: martinrb at google.com (Martin Buchholz) Date: Mon, 23 Mar 2009 11:19:49 -0700 Subject: RFE 4519026: (process) Process should support Unicode on Win NT, request for review In-Reply-To: <49C7CD1D.5060900@sun.com> References: <79DCAA64DFAC49619FA1018B43C2C5E1@HeikoXP> <49C786E6.7070607@sun.com> <1ccfd1c10903230843g3bad234ak8b1e71a27dd449bc@mail.gmail.com> <49C7CD1D.5060900@sun.com> Message-ID: <1ccfd1c10903231119g7e57ed03j888eda8159b666f3@mail.gmail.com> Alan asks a very good question. The kinds of pathname conversion done by getNativePath is likely already implemented in Java code somewhere. E.g. there is this comment in ProcessImpl.java: // Win32 CreateProcess requires cmd[0] to be normalized cmd[0] = new File(cmd[0]).getPath(); I've always considered the primary purpose of getNativePath to be native charset encoding, but for the win32 "W" API this is a no-op because we are converting UTF-16 to UTF-16. So I suspect we can get rid of that icky C code in getNativePath entirely, perhaps simply replacing it by java calls to getPath() or similar functionality extracted from something in NIO2, which is in jdk7 since b50. Martin On Mon, Mar 23, 2009 at 10:55, Alan Bateman wrote: > I'm not an expert > on the Process code but is the directory already normalized at this point? > Just wondering if all of getNativePath is needed. > > -Alan. > From martinrb at google.com Mon Mar 23 18:42:15 2009 From: martinrb at google.com (Martin Buchholz) Date: Mon, 23 Mar 2009 11:42:15 -0700 Subject: Review request for 6666739 and 6711667 In-Reply-To: <49C7CD6F.5020708@sun.com> References: <49C7CD6F.5020708@sun.com> Message-ID: <1ccfd1c10903231142t7a12ec59w77091e7f46569352@mail.gmail.com> These changes look fine, but I believe ReferenceQueue can benefit from more work. - Instead of having a Lock subclass, just make lock a new Object() - Update the queue using the CAS capabilities from java.util.concurrent.atomic. But that would be an independent and more difficult fix. While you're there, you could make the comments for SoftReference.clock and SoftReference.timestamp into proper javadoc comments (i.e. just add a '*' and some whitespace). Martin On Mon, Mar 23, 2009 at 10:57, Alan Bateman wrote: > 6666739: (ref) ReferenceQueue.poll() doesn't scale well > 6711667: (ref) Update SoftReference timestamp only if clock advances > > This is forward-port from 6u14 of two scalability fixes. These were original > fixed by Tom Rodriguez in an earlier update. > > The webrev is here: > ?http://cr.openjdk.java.net/~alanb/6666739%2b6711667/webrev.00/ > > Thanks, > > Alan. > > From tim.bell at sun.com Tue Mar 24 03:41:43 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Tue, 24 Mar 2009 03:41:43 +0000 Subject: hg: jdk7/tl/corba: 2 new changesets Message-ID: <20090324034145.E0A24E7C5@hg.openjdk.java.net> Changeset: 126389a38e7d Author: tbell Date: 2009-03-23 17:43 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/126389a38e7d 6695776: corba jscheme jar files in repository could be built from source Summary: Forward port of changes from the 6-open train. Reviewed-by: darcy, ohair, tbell Contributed-by: Andrew John Hughes ! make/com/sun/corba/se/sources/Makefile ! make/sun/rmi/corbalogsources/Makefile ! make/tools/Makefile + make/tools/logutil/Makefile ! src/share/classes/com/sun/tools/corba/se/logutil/IndentingPrintWriter.java + src/share/classes/com/sun/tools/corba/se/logutil/Input.java + src/share/classes/com/sun/tools/corba/se/logutil/InputCode.java + src/share/classes/com/sun/tools/corba/se/logutil/InputException.java + src/share/classes/com/sun/tools/corba/se/logutil/MC.java - src/share/classes/com/sun/tools/corba/se/logutil/lib/jscheme.jar - src/share/classes/com/sun/tools/corba/se/logutil/lib/jschemelogutil.jar - src/share/classes/com/sun/tools/corba/se/logutil/scripts/mc - src/share/classes/com/sun/tools/corba/se/logutil/scripts/mc.scm - src/share/classes/com/sun/tools/corba/se/logutil/scripts/run Changeset: 61116c9789b9 Author: tbell Date: 2009-03-23 17:58 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/61116c9789b9 Merge From tim.bell at sun.com Tue Mar 24 03:45:12 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Tue, 24 Mar 2009 03:45:12 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20090324034556.DDC3EE7D1@hg.openjdk.java.net> Changeset: 13cd6eb34cfa Author: tbell Date: 2009-03-23 17:43 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/13cd6eb34cfa 6695776: corba jscheme jar files in repository could be built from source Summary: Forward port of changes from the 6-open train. Reviewed-by: darcy, ohair, tbell Contributed-by: Andrew John Hughes ! THIRD_PARTY_README Changeset: 8306f3df15ff Author: tbell Date: 2009-03-23 17:57 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8306f3df15ff Merge - make/common/shared/Compiler.gmk From Alan.Bateman at Sun.COM Tue Mar 24 08:47:58 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Tue, 24 Mar 2009 08:47:58 +0000 Subject: Review request for 6795561 Message-ID: <49C89E3E.2020700@sun.com> 6795561: (bf) CharBuffer.subSequence() uses wrong capacity value for new buffer Iris, you might want to review this one. CharBuffer#subSequence(start,end) is specified to return a char buffer that has a position of position() + start, a limit of position() + end, and a capacity of capacity(). For buffers created via CharBuffer#allocate or char buffer views we've always generated code that return a CharBuffer with a position of 0 and a limit and capacity that is the length of the subsequence. To my knowledge this hasn't been noticed, probably because it required casting the result to a char buffer. In jdk7 this method has been updated to take advantage of covariant returns so it's more likely to be noticed now. Furthermore, your old adversary StringCharBuffer (used when wrapping a char sequence) has been returning a buffer with the incorrect capacity since 6546113 [1], leading to the IOOBE in the bug report. We should have caught this but didn't. To that end, I've added coverage to the unit test. The webrev is here: http://cr.openjdk.java.net/~alanb/6795561/webrev.00/ Thanks, Alan. [1] http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c73cb47fe250 From alan.bateman at sun.com Tue Mar 24 15:42:08 2009 From: alan.bateman at sun.com (alan.bateman at sun.com) Date: Tue, 24 Mar 2009 15:42:08 +0000 Subject: hg: jdk7/tl/jdk: 4 new changesets Message-ID: <20090324154328.5EC71E82A@hg.openjdk.java.net> Changeset: bccdcd761796 Author: alanb Date: 2009-03-24 14:03 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bccdcd761796 6819886: System.getProperty("os.name") reports Vista on Windows 7 Reviewed-by: sherman ! src/windows/native/java/lang/java_props_md.c Changeset: 4c3f752993a5 Author: alanb Date: 2009-03-24 14:05 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4c3f752993a5 6807702: Integer.valueOf cache should be configurable Reviewed-by: darcy ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/System.java + test/java/lang/Integer/ValueOf.java Changeset: 78063cf930e5 Author: alanb Date: 2009-03-24 14:08 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/78063cf930e5 6819689: File.lastModified can return bogus value for remote file accessed as it is being deleted [win] Reviewed-by: sherman Contributed-by: andreas.frischknecht at softwired-inc.com ! src/windows/native/java/io/WinNTFileSystem_md.c Changeset: 52bdf8cec41d Author: alanb Date: 2009-03-24 14:10 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/52bdf8cec41d 6621689: (dc spec) DatagramChannel.receive when channel is not bound is not specified Reviewed-by: sherman ! src/share/classes/java/nio/channels/DatagramChannel.java ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java ! test/java/nio/channels/DatagramChannel/NotBound.java From Alan.Bateman at Sun.COM Tue Mar 24 16:10:28 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Tue, 24 Mar 2009 16:10:28 +0000 Subject: RFE 4519026: (process) Process should support Unicode on Win NT, request for review In-Reply-To: <1ccfd1c10903231119g7e57ed03j888eda8159b666f3@mail.gmail.com> References: <79DCAA64DFAC49619FA1018B43C2C5E1@HeikoXP> <49C786E6.7070607@sun.com> <1ccfd1c10903230843g3bad234ak8b1e71a27dd449bc@mail.gmail.com> <49C7CD1D.5060900@sun.com> <1ccfd1c10903231119g7e57ed03j888eda8159b666f3@mail.gmail.com> Message-ID: <49C905F4.8070006@sun.com> Martin Buchholz wrote: > : > > So I suspect we can get rid of that icky C code in getNativePath entirely, > perhaps simply replacing it by java calls to getPath() or similar functionality > extracted from something in NIO2, which is in jdk7 since b50. > Eliminating this native code would be good although I don't think we'll find code that is completely compatible with the existing behavior. For example, in addition to normalizing the path separator, it trims trailing spaces. If you passed such input to FileSystem.getDefault().getPath method it would reject it immediately (because trailing spaces are prohibited in directory names). The simplest solution is probably to put this trimming in the Windows java.lang.ProcessImpl. I don't think it needs to worry about the separator because the working directory should already be normalized. -Alan. From Alan.Bateman at Sun.COM Tue Mar 24 18:12:30 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Tue, 24 Mar 2009 18:12:30 +0000 Subject: Review request for 6772303 Message-ID: <49C9228E.20702@sun.com> 6772303: (se) IOException: Invalid argument" thrown on a call to Selector.select(value) with -d64 This is Solaris and 64-bit specific. In summary, the DP_POLL ioctl used to retrieve events from the /dev/poll driver limits the number of pollfd entries in the poll array to the maximum number of file descriptors minus 1. The /dev/poll Selector uses this limit or 8k (whichever is smaller) to size its poll array. This sizing breaks for the unlimited case on 64-bit because RLIM64_INFINITY is negative (-3) and also the code is truncating the limit to a jint. This manifests with the select method throwing IOException "Invalid argument". There are many ways to fix this, one of the simplest being to treat infinity as Integer.MAX_VALUE. The webrev is here: http://cr.openjdk.java.net/~alanb/6772303/webrev.00/ Thanks, Alan. From David.Holmes at Sun.COM Wed Mar 25 00:58:41 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Wed, 25 Mar 2009 10:58:41 +1000 Subject: SIGFPE with FPE_FLTRES Message-ID: <49C981C1.1060509@sun.com> Can someone tell me when you can encounter a SIGFPE with si_code FPE_FLTRES? I'm suspecting this may be a case where a "bad" operation doesn't in itself fail but the next (innocent) FP operation gets hit with the FPE. Thanks, David Holmes From martinrb at google.com Wed Mar 25 08:15:34 2009 From: martinrb at google.com (martinrb at google.com) Date: Wed, 25 Mar 2009 08:15:34 +0000 Subject: hg: jdk7/tl/jdk: 6800572: Removing elements from views of NavigableMap implementations does not always work correctly. Message-ID: <20090325081613.D61D4E9B3@hg.openjdk.java.net> Changeset: 644849201ca6 Author: dl Date: 2009-03-24 19:42 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/644849201ca6 6800572: Removing elements from views of NavigableMap implementations does not always work correctly. Summary: Replace use of new TreeSet with new KeySet Reviewed-by: martin ! src/share/classes/java/util/TreeMap.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java ! test/java/util/Collection/MOAT.java From heiko.wagner at apis.de Wed Mar 25 09:22:54 2009 From: heiko.wagner at apis.de (Heiko Wagner) Date: Wed, 25 Mar 2009 10:22:54 +0100 Subject: RFE 4519026: (process) Process should support Unicode on Win NT, request for review In-Reply-To: <1ccfd1c10903222024x2ba35830r2df1b4e2b9d103f9@mail.gmail.com> Message-ID: Hi Martin, I have updated http://www.apis.de/pub/jdk7/ProcessImpl_md.c and http://www.apis.de/pub/jdk7/ProcessImpl_md.c.diff. Changes: - fix block comment style - remove note about Win95, since minumum system requirement is Win2000 - replace comment "selected based on exe type" with "creation flags" I have also been thinking about adding tests to ProcessBuilder/Basic.java. My suggestion would be to start from the version Alan made, to get the environment issue working. I would like to stick with your test pattern of starting a java process in the test. To show that we are now using CreateProcessW, I would start a java with Runtime.getRuntime().exec() having its working dir set to a, previously created, directory containing unicode characters and do a "pwd" operation in the java child. Although it is also possible to have the actual exe reside on a unicode path and pass unicode command line args, currently it is not possible to use this test pattern, as it needs additional modifications to the java launcher and java vm. What would you suggest to test this features, until we have a fully unicode aware version of java.exe? Regards Heiko -----Original Message----- From: Martin Buchholz [mailto:martinrb at google.com] Sent: Montag, 23. M?rz 2009 04:24 To: Heiko Wagner Cc: core-libs-dev at openjdk.java.net; Xueming Shen; Alan Bateman Subject: Re: RFE 4519026: (process) Process should support Unicode on Win NT, request for review Heiko, Thanks for your continuing work on this. ProcessBuilder/Basic.java has most of the tests related to subprocesses. I can't explain a return code of 6, since the test uses 5, 7, and 8. ProcessBuilder has a lot of infrastructure to help you write a test in this area, but it can be intimidating to newcomers (i.e. anyone but myself). The JDK C code is quite inconsistent, but please use the style /* * comments * here */ for block comments, and /* inline comments */ like this. You need to remove the comment /* selected based on exe type */ which is no longer correct. If you fix the style things, and get the tests to pass, and add a test for what you're actually trying to fix, I am ready to approve the change. Martin From maurizio.cimadamore at sun.com Wed Mar 25 10:41:29 2009 From: maurizio.cimadamore at sun.com (maurizio.cimadamore at sun.com) Date: Wed, 25 Mar 2009 10:41:29 +0000 Subject: hg: jdk7/tl/langtools: 3 new changesets Message-ID: <20090325104138.72FDEE9C9@hg.openjdk.java.net> Changeset: 5caa6c45936a Author: mcimadamore Date: 2009-03-25 10:28 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/5caa6c45936a 6182950: methods clash algorithm should not depend on return type Summary: fixed code that checks for duplicate method declarations Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/generics/6182950/T6182950a.java + test/tools/javac/generics/6182950/T6182950a.out + test/tools/javac/generics/6182950/T6182950b.java + test/tools/javac/generics/6182950/T6182950b.out + test/tools/javac/generics/6182950/T6182950c.java Changeset: 6ce39250fa88 Author: mcimadamore Date: 2009-03-25 10:28 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/6ce39250fa88 6816548: Uninitialized register when performing casting + auto(un)boxing Summary: Constant value of final variable is lost during lowering Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/boxing/T6816548.java Changeset: 1ee128971f5d Author: mcimadamore Date: 2009-03-25 10:29 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/1ee128971f5d 6400189: raw types and inference Summary: Fixed resolution problem with raw overriding (CCC) Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/OverrideChecks/6400189/T6400189a.java + test/tools/javac/OverrideChecks/6400189/T6400189a.out + test/tools/javac/OverrideChecks/6400189/T6400189b.java + test/tools/javac/OverrideChecks/6400189/T6400189b.out + test/tools/javac/OverrideChecks/6400189/T6400189c.java + test/tools/javac/OverrideChecks/6400189/T6400189d.java From Ulf.Zibis at gmx.de Wed Mar 25 14:12:36 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Wed, 25 Mar 2009 15:12:36 +0100 Subject: Fast String... In-Reply-To: <49C9A7DE.5060608@sun.com> References: <49C740AC.8090401@sun.com> <1ccfd1c10903231410l3cc5c3f3h29ec0a549683a25f@mail.gmail.com> <49C82E4E.9080005@sun.com> <49C971C1.4080301@gmx.de> <1ccfd1c10903241658p59f07dd0y391563bf35ed1464@mail.gmail.com> <49C9852F.6080409@sun.com> <49C98472.1050407@gmx.de> <49C9A7DE.5060608@sun.com> Message-ID: <49CA3BD4.3030704@gmx.de> Am 25.03.2009 04:41, Xueming Shen schrieb: > Ulf Zibis wrote: >> Am 25.03.2009 02:13, Xueming Shen schrieb: >>> reduce size is a good thing, that was my primary goal, to reduce the >>> charsets.jar to under 2M, and >>> doable if we can put the data outside the class file, that was what >>> I have done...the concern is the >>> startup time. one alternative is to pick this approach for those >>> charsets that don't care the startup, >>> such as the ibm charsets and the one on solaris:-) >>> >>> compared to stored the data in class file and out of the class, you >>> can still eliminate the c2b data >>> (generated from b2c), the difference is the String constants stored >>> in utf8 probably take 3 bytes >>> but 2 bytes in a ".dat" file....about 15% >> >> Your generated charset classes have 2 K in average, my data files >> have 250 bytes in average (including aliases + historicalName, so you >> should subtract 50..200 bytes for comparison). >> See: >> https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/releases/nio_charset_M4.jar?rev=682&view=log >> >> > it's unfair:-) you put me totally in defensive position:-) Martin can > testify i started to sell this idea of extracting all > mapping data into dat file and to have only one single base class to > load in dat and construct the charset class > on the fly, 2 years ago:-) so i know how small it can be. > > my 15% data is not for singlebyte, i'm talking about the doublebyte, Ah, ok. This makes it clearer. I totally agree with you, saving bytes only in singlebyte charsets isn't much worth. But it was good exercise for me, to find out relevant techniques. You may would wonder, how I can serve a coder for 256 2-byte chars with a 69 byte data file (e.g. koi8-u.dat), which also includes it's numerous names. The trick is, that I share map data between charsets, if they are similar enough. This is done by my sun.nio.cs.CharsetStream class. I would wonder, if there isn't heavy concordance between doublebyte maps, which could be shared. I have designed CharsetStream class to be extendible for doublebyte requirements. Additionally, I think it should be possible to partly share mapping tables in memory, as the doublebyte b2c maps in general seem to be sliced. The big problem is the lack in startup time, which for me seems to be caused by the dilly-dallying resource stream. -Ulf > let me explain why i don't really care the singlebyte size, > we have probably 100 singlebyte charsets in our repository, assume > each takes 2k, it's total of 200k of the 6M +(in stored mode) > size of charsets.jar, even you can reduce the size to 0, it's 5% of > the total size. yes, each bit counts, but sometime you have to > balance the advantage and disadvantage, so if we have to trade the > startup for the 5% reduce of total 6M charsets.jar, i would > give it a second thought. but it might be a totaly different story for > doublebyte, if you can cut the 6M in half (that was my goal), > with relatively small startup regression, it might be something worth > doing. > > Sherman > > From Ulf.Zibis at gmx.de Wed Mar 25 14:23:10 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Wed, 25 Mar 2009 15:23:10 +0100 Subject: Fastpath for new String(bytes...) and String.getBytes(...) In-Reply-To: <49CA1E92.2050603@sun.com> References: <49C16E46.9040609@sun.com> <49C26589.8050206@gmx.de> <1ccfd1c10903231424w61d3697aif4f07b666b4aae0a@mail.gmail.com> <49C8A82A.8020300@sun.com> <49C97922.6030806@gmx.de> <49CA1E92.2050603@sun.com> Message-ID: <49CA3E4E.5050205@gmx.de> Am 25.03.2009 13:07, Alan Bateman schrieb: > Ulf Zibis wrote: >> Well, so I should stay on my JRL-persisted >> https://java-nio-charset-enhanced.dev.java.net/ for working on my >> changes, having an additional HG based NetBeans project to forge >> changesets for OpenJDK. >> >> Thank for your help, >> >> -Ulf > If I was doing this then I would put my efforts into patches for > jdk7/OpenJDK and ignore jdk6. This is my plan. :-) > The reason is that jdk7/OpenJDK already has many performance > improvements and secondly it means that the changes can be > contributed. It is up to you of course. I hope you can get over the > hurdle of learning Mercurial and the build process. I'm improving. I've downloaded the tl clone, but I'm disappointed, because it has 200 MByte, not much less than the complete jdk7. I also tried nio2 clone, which isn't better, and not updated since 1 year. (Is there anybody responsible for it's update?) I would be happy if there would be some smaller "trees" in the mercurial forest for us externals. -Ulf > Also, I will make sure someone gets back to you on setting up NB > projects (I spent much of my time in the shell rather than in IDEs). > > -Alan. > > From Alan.Bateman at Sun.COM Wed Mar 25 15:19:22 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Wed, 25 Mar 2009 15:19:22 +0000 Subject: Fastpath for new String(bytes...) and String.getBytes(...) In-Reply-To: <49CA3E4E.5050205@gmx.de> References: <49C16E46.9040609@sun.com> <49C26589.8050206@gmx.de> <1ccfd1c10903231424w61d3697aif4f07b666b4aae0a@mail.gmail.com> <49C8A82A.8020300@sun.com> <49C97922.6030806@gmx.de> <49CA1E92.2050603@sun.com> <49CA3E4E.5050205@gmx.de> Message-ID: <49CA4B7A.7090108@sun.com> Ulf Zibis wrote: > > : > > I'm improving. I've downloaded the tl clone, but I'm disappointed, > because it has 200 MByte, not much less than the complete jdk7. I also > tried nio2 clone, which isn't better, and not updated since 1 year. > (Is there anybody responsible for it's update?) > I would be happy if there would be some smaller "trees" in the > mercurial forest for us externals. jdk7/tl/jdk is the most suitable repository for you to clone as updates to the charset code will be pushed there. I keep nio/nio/jdk up to date but there isn't any charset work happening there. I appreciate you've got disk space constraints but I don't have a solution that would allow you build without a complete repository. -Alan. From mandy.chung at sun.com Wed Mar 25 19:39:12 2009 From: mandy.chung at sun.com (mandy.chung at sun.com) Date: Wed, 25 Mar 2009 19:39:12 +0000 Subject: hg: jdk7/tl/jdk: 6819122: DefaultProxySelector should lazily initialize the Pattern object and the NonProxyInfo objects Message-ID: <20090325193940.AC6DEEA08@hg.openjdk.java.net> Changeset: 2dae30c4d687 Author: mchung Date: 2009-03-25 12:24 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2dae30c4d687 6819122: DefaultProxySelector should lazily initialize the Pattern object and the NonProxyInfo objects Summary: Move two static NonProxyInfo fields into NonProxyInfo class and instantiate Pattern object when needed Reviewed-by: jccollet ! src/share/classes/sun/net/spi/DefaultProxySelector.java From Xueming.Shen at Sun.COM Wed Mar 25 22:00:28 2009 From: Xueming.Shen at Sun.COM (Xueming Shen) Date: Wed, 25 Mar 2009 15:00:28 -0700 Subject: Review request for 6693490 In-Reply-To: <49C7BAF5.6040900@sun.com> References: <49C7BAF5.6040900@sun.com> Message-ID: <49CAA97C.2070707@sun.com> looks good, approved. Alan Bateman wrote: > > 6693490: (se) select throws "File exists" IOException under load (lnx) > > Sherman, we've chatted about this issue so you will probably want to > review. It's a race between registration (or re-registration) and > close. Registrations are queued so that they come into effect at the > next select (as required by the spec) but if the channel is pre-closed > just before it is added to epoll then it possible that the socketpair, > used in the closing mechanism, gets registered with epoll. Once that > happens it creates the conditions to cause a Selector spin, and where > the file descriptor is recycled for a new SelectableChannel, then > registration will fail with IOException "file exists". The fix is to > remove from epoll before the channel is killed and to skip pending > updates for closed channels (as these can result in re-registration). > To avoid any side effects with cancellation the deregister also purges > pending updates for the channel. Thanks to Serge Baranov, Robert > Larsen, Peter van Rensburg, Richard Ridgway, Greg Wilkins and others > for testing this fix, or preliminary versions of. > > The webrev is here: > http://cr.openjdk.java.net/~alanb/6693490/webrev.00 > > Thanks, > -Alan. From David.Holmes at Sun.COM Wed Mar 25 23:10:02 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Thu, 26 Mar 2009 09:10:02 +1000 Subject: SIGFPE with FPE_FLTRES In-Reply-To: <05FF4872-79F6-4009-87ED-9AB2B1627F09@sun.com> References: <49C981C1.1060509@sun.com> <05FF4872-79F6-4009-87ED-9AB2B1627F09@sun.com> Message-ID: <49CAB9CA.1020503@sun.com> The code was innocuous as far as I can see. One place does some basic calculations with some values used for GC statistics. The other was a crash here: double cpuTimer::seconds() const { double count = (double) _counter; double freq = (double) os::elapsed_frequency(); return count/freq; } and os::elapsed_frquency is a constant (1000*1000*1000) on Solaris. Both crashes occurs on 64-bit on Solaris AMD64. Thanks, David Tom Rodriguez said the following on 03/26/09 08:53: > FPE_FLTRES appears to concern inexact results being produced but these > kinds of exception should always be masked for us. In what kind of code > was this reported? > > tom > > On Mar 24, 2009, at 5:58 PM, David Holmes - Sun Microsystems wrote: > >> Can someone tell me when you can encounter a SIGFPE with si_code >> FPE_FLTRES? I'm suspecting this may be a case where a "bad" operation >> doesn't in itself fail but the next (innocent) FP operation gets hit >> with the FPE. >> >> Thanks, >> David Holmes > From Thomas.Rodriguez at Sun.COM Wed Mar 25 22:53:03 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 25 Mar 2009 15:53:03 -0700 Subject: SIGFPE with FPE_FLTRES In-Reply-To: <49C981C1.1060509@sun.com> References: <49C981C1.1060509@sun.com> Message-ID: <05FF4872-79F6-4009-87ED-9AB2B1627F09@sun.com> FPE_FLTRES appears to concern inexact results being produced but these kinds of exception should always be masked for us. In what kind of code was this reported? tom On Mar 24, 2009, at 5:58 PM, David Holmes - Sun Microsystems wrote: > Can someone tell me when you can encounter a SIGFPE with si_code > FPE_FLTRES? I'm suspecting this may be a case where a "bad" > operation doesn't in itself fail but the next (innocent) FP > operation gets hit with the FPE. > > Thanks, > David Holmes From Thomas.Rodriguez at Sun.COM Wed Mar 25 23:28:51 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 25 Mar 2009 16:28:51 -0700 Subject: SIGFPE with FPE_FLTRES In-Reply-To: <49CAB9CA.1020503@sun.com> References: <49C981C1.1060509@sun.com> <05FF4872-79F6-4009-87ED-9AB2B1627F09@sun.com> <49CAB9CA.1020503@sun.com> Message-ID: <08D85BD0-E437-44B0-91E1-4D20C9DA47BB@sun.com> That's even more odd to me. x86_64 shouldn't be using the old FP instructions and the SSE based one don't produce an inexact traps as far as I can tell. Maybe they are still being emitted somewhere, possibly for the transcendentals? Actually I can see that the template interpreter still uses them so maybe something is happening there with a left over precision exception? tom On Mar 25, 2009, at 4:10 PM, David Holmes - Sun Microsystems wrote: > The code was innocuous as far as I can see. One place does some > basic calculations with some values used for GC statistics. The > other was a crash here: > > double cpuTimer::seconds() const { > double count = (double) _counter; > double freq = (double) os::elapsed_frequency(); > return count/freq; > } > > and os::elapsed_frquency is a constant (1000*1000*1000) on Solaris. > > Both crashes occurs on 64-bit on Solaris AMD64. > > Thanks, > David > > Tom Rodriguez said the following on 03/26/09 08:53: >> FPE_FLTRES appears to concern inexact results being produced but >> these kinds of exception should always be masked for us. In what >> kind of code was this reported? >> tom >> On Mar 24, 2009, at 5:58 PM, David Holmes - Sun Microsystems wrote: >>> Can someone tell me when you can encounter a SIGFPE with si_code >>> FPE_FLTRES? I'm suspecting this may be a case where a "bad" >>> operation doesn't in itself fail but the next (innocent) FP >>> operation gets hit with the FPE. >>> >>> Thanks, >>> David Holmes From Ulf.Zibis at gmx.de Wed Mar 25 23:52:18 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 26 Mar 2009 00:52:18 +0100 Subject: Fastpath for new String(bytes...) and String.getBytes(...) In-Reply-To: <49C296B4.7030103@sun.com> References: <49C16E46.9040609@sun.com> <49C27D86.3000509@gmx.de> <49C296B4.7030103@sun.com> Message-ID: <49CAC3B2.2090001@gmx.de> Am 19.03.2009 20:02, Xueming Shen schrieb: > Ulf Zibis wrote: >> >> Isn't there any way even to avoid instantiating new ..Array-X-coder >> for each invocation of StringCoding.x-code(Charset cs, ...)? >> Method x-code(byte/char[]) seems to be threadsafe, if replacement >> isn't changed, so I suppose, we could cache the ..Array-X-coder. >> > no. an "external" charset can do whatever it likes, it might be still > the same "object", the de/encoder it "creates" might > be still the same "object' or looks like the same object you might > have cahced, but do total different thing. At first assumption user could think, that String#getBytes(byte[] buf, Charset cs) might be faster than String#getBytes(byte[] buf, String csn), because he assumes, that Charset would be internally created from csn. As this is only true for the first call, there should be a *note* in JavaDoc about cost of those methods in comparision. Don't forget (byte[] ...) constructor's JavaDoc too. Secondly I think, that ASCII and ISO-8859-1 have high percentage here especially for CORBA applications, so why not have a fast shortcut in class String without internally using Charset-X-coder like getASCIIbytes() + getISO_8859_1Bytes(), or more general and sophisticated: int getBytes(byte[] buf, byte mask) { int j = 0; for (int i=0; i from Tom Rodriguez (Mar 25, 4:28pm) Message-ID: <20090326123259.16AD95654E@rebar.astron.com> On Mar 25, 4:28pm, Thomas.Rodriguez at Sun.COM (Tom Rodriguez) wrote: -- Subject: Re: SIGFPE with FPE_FLTRES | That's even more odd to me. x86_64 shouldn't be using the old FP | instructions and the SSE based one don't produce an inexact traps as | far as I can tell. Maybe they are still being emitted somewhere, | possibly for the transcendentals? Actually I can see that the | template interpreter still uses them so maybe something is happening | there with a left over precision exception? | | tom I would just remove the trancendental c implementation. It is not consistent with the java one anyway on amd64: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6539464 It's been 2 years that this is has been open. I don't understand how come nobody else has hit this. My only guess is that people don't compare results from successive runs. christos From volker.simonis at gmail.com Thu Mar 26 09:47:11 2009 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 26 Mar 2009 10:47:11 +0100 Subject: SIGFPE with FPE_FLTRES In-Reply-To: <08D85BD0-E437-44B0-91E1-4D20C9DA47BB@sun.com> References: <49C981C1.1060509@sun.com> <05FF4872-79F6-4009-87ED-9AB2B1627F09@sun.com> <49CAB9CA.1020503@sun.com> <08D85BD0-E437-44B0-91E1-4D20C9DA47BB@sun.com> Message-ID: As far as I can see, "old FP" instructions are still emitted for example for the logarithm (see log10D_reg and logD_reg in x86_64.ad, which use fldlg2, fldln2 and fyl2x). These instructions can interact badly with code generated by the native C/C++ compiler. I had such a problem a while ago under Windows/AMD64 with the new MSVC 2005 compiler (and msvcr80d.dll). The logarithm instructions mentioned above did set the "divide by zero" flag in the FP status word if called with a zero argument. Later on, this led to an error in a reminder operation, because that reminder operation was mapped to the native "fmod()" function by "SharedRuntime::drem()" and "fmod()" in turn used "old FP" instructions in its implementation which failed because of the pending "divide by zero" flag in the FP status word. You could check if the code generated for "cpuTimer::seconds()" contains "old FP" instructions. If yes, they may interact with some other FP instructions, emitted by the JIT (or the template interpreter, as mentioned by Tom). Regards, Volker On 3/26/09, Tom Rodriguez wrote: > That's even more odd to me. x86_64 shouldn't be using the old FP > instructions and the SSE based one don't produce an inexact traps as far as > I can tell. Maybe they are still being emitted somewhere, possibly for the > transcendentals? Actually I can see that the template interpreter still > uses them so maybe something is happening there with a left over precision > exception? > > tom > > > On Mar 25, 2009, at 4:10 PM, David Holmes - Sun Microsystems wrote: > > > > The code was innocuous as far as I can see. One place does some basic > calculations with some values used for GC statistics. The other was a crash > here: > > > > double cpuTimer::seconds() const { > > double count = (double) _counter; > > double freq = (double) os::elapsed_frequency(); > > return count/freq; > > } > > > > and os::elapsed_frquency is a constant (1000*1000*1000) on Solaris. > > > > Both crashes occurs on 64-bit on Solaris AMD64. > > > > Thanks, > > David > > > > Tom Rodriguez said the following on 03/26/09 08:53: > > > > > FPE_FLTRES appears to concern inexact results being produced but these > kinds of exception should always be masked for us. In what kind of code was > this reported? > > > tom > > > On Mar 24, 2009, at 5:58 PM, David Holmes - Sun Microsystems wrote: > > > > > > > Can someone tell me when you can encounter a SIGFPE with si_code > FPE_FLTRES? I'm suspecting this may be a case where a "bad" operation > doesn't in itself fail but the next (innocent) FP operation gets hit with > the FPE. > > > > > > > > Thanks, > > > > David Holmes > > > > > > > > > > > From Thomas.Rodriguez at Sun.COM Thu Mar 26 18:01:19 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 26 Mar 2009 11:01:19 -0700 Subject: SIGFPE with FPE_FLTRES In-Reply-To: <20090326123259.16AD95654E@rebar.astron.com> References: <20090326123259.16AD95654E@rebar.astron.com> Message-ID: <961FAEC2-2B51-4158-BE9E-593B63C38959@Sun.COM> > I would just remove the trancendental c implementation. It is not > consistent > with the java one anyway on amd64: You've got that backwards. The C implementation is actually the correct result as far as the spec goes and it's what is used by StrictMath.log. Math.log is allowed to produce less strict results but it's always correct to use the same implementation as StrictMath.log. > > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6539464 > > It's been 2 years that this is has been open. I don't understand how > come > nobody else has hit this. My only guess is that people don't compare > results > from successive runs. This is actually a bug in hotspot. The interpreter is using the C implementation and compiled code is using the log instructions on x86 but the interpreter and compiler are required to use the same implementation so that Math.log is self consistent. The amd64 interpreter has the code to use the x86 instruction but some code in AbstractInterpreterGenerator::generate_method_entry keep it from getting used. Anyway, I've refiled this into hotspot and it should be fixed in an upcoming hotspot. tom > > > christos From christos at zoulas.com Thu Mar 26 18:34:55 2009 From: christos at zoulas.com (Christos Zoulas) Date: Thu, 26 Mar 2009 14:34:55 -0400 Subject: SIGFPE with FPE_FLTRES In-Reply-To: <961FAEC2-2B51-4158-BE9E-593B63C38959@Sun.COM> from Tom Rodriguez (Mar 26, 11:01am) Message-ID: <20090326183455.A2B4856550@rebar.astron.com> On Mar 26, 11:01am, Thomas.Rodriguez at Sun.COM (Tom Rodriguez) wrote: -- Subject: Re: SIGFPE with FPE_FLTRES | > I would just remove the trancendental c implementation. It is not | > consistent | > with the java one anyway on amd64: | | You've got that backwards. The C implementation is actually the | correct result as far as the spec goes and it's what is used by | StrictMath.log. Math.log is allowed to produce less strict results | but it's always correct to use the same implementation as | StrictMath.log. | | > | > | > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6539464 | > | > It's been 2 years that this is has been open. I don't understand how | > come | > nobody else has hit this. My only guess is that people don't compare | > results | > from successive runs. | | This is actually a bug in hotspot. The interpreter is using the C | implementation and compiled code is using the log instructions on x86 | but the interpreter and compiler are required to use the same | implementation so that Math.log is self consistent. The amd64 | interpreter has the code to use the x86 instruction but some code in | AbstractInterpreterGenerator::generate_method_entry keep it from | getting used. Anyway, I've refiled this into hotspot and it should be | fixed in an upcoming hotspot. Thanks a lot for explanation! christos From martinrb at google.com Thu Mar 26 22:09:22 2009 From: martinrb at google.com (martinrb at google.com) Date: Thu, 26 Mar 2009 22:09:22 +0000 Subject: hg: jdk7/tl/jdk: 6801020: Concurrent Semaphore release may cause some require thread not signaled Message-ID: <20090326220934.CF62DEABA@hg.openjdk.java.net> Changeset: 5303aece2068 Author: dl Date: 2009-03-26 11:59 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5303aece2068 6801020: Concurrent Semaphore release may cause some require thread not signaled Summary: Introduce PROPAGATE waitStatus Reviewed-by: martin ! src/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java ! src/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java + test/java/util/concurrent/Semaphore/RacingReleases.java From martinrb at google.com Fri Mar 27 00:43:42 2009 From: martinrb at google.com (martinrb at google.com) Date: Fri, 27 Mar 2009 00:43:42 +0000 Subject: hg: jdk7/tl/jdk: 6822903: Reliability and documentation improvements for ReentrantReadWriteLock Message-ID: <20090327004354.BD2EBEB1D@hg.openjdk.java.net> Changeset: 4a685f3f3ba8 Author: dl Date: 2009-03-26 17:39 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4a685f3f3ba8 6822903: Reliability and documentation improvements for ReentrantReadWriteLock Summary: Make firstReader a Thread, not a long Reviewed-by: martin ! src/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java From weijun.wang at sun.com Fri Mar 27 03:19:06 2009 From: weijun.wang at sun.com (weijun.wang at sun.com) Date: Fri, 27 Mar 2009 03:19:06 +0000 Subject: hg: jdk7/tl/jdk: 6802846: jarsigner needs enhanced cert validation(options) Message-ID: <20090327031937.B2D13EB5A@hg.openjdk.java.net> Changeset: b752110df530 Author: weijun Date: 2009-03-27 11:05 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b752110df530 6802846: jarsigner needs enhanced cert validation(options) Reviewed-by: xuelei ! src/share/classes/sun/security/tools/JarSigner.java ! src/share/classes/sun/security/tools/JarSignerResources.java ! src/share/classes/sun/security/tools/KeyTool.java + test/sun/security/tools/jarsigner/concise_jarsigner.sh From michal.conos at googlemail.com Fri Mar 27 13:17:56 2009 From: michal.conos at googlemail.com (Michal Conos) Date: Fri, 27 Mar 2009 14:17:56 +0100 Subject: RFE 4735419: File.createTempDirectory() to create a temporary directory Message-ID: Hi, I'd like to work on this RFE: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4735419 It looks like an easy start if I want to contribute to openjdk. Customers are often using a "workaround" described in bug which contains a race. My solution would be something like proposed bellow - but it'd be nice if someone could guide me through the process since I'd like to work on more RFEs. Cheers, Michal ------------- diff --git a/src/share/classes/java/io/File.java b/src/share/classes/java/io/File.java --- a/src/share/classes/java/io/File.java +++ b/src/share/classes/java/io/File.java @@ -2041,6 +2041,42 @@ public class File } } + public static File createTempDirectory(String prefix, String suffix, + File directory) + throws IOException + { + if (prefix.length() < 3) + throw new IllegalArgumentException("Prefix string too short"); + if (suffix == null) + suffix = ".tmp"; + + File tmpdir = (directory != null) ? + directory : TemporaryDirectory.valueAsFile; + SecurityManager sm = System.getSecurityManager(); + File f; + do { + f = TemporaryDirectory.generateFile(prefix, suffix, tmpdir); + if (sm != null) { + try { + sm.checkWrite(f.getPath()); + } catch (SecurityException se) { + // don't reveal temporary directory location + if (directory == null) + throw new SecurityException("Unable to create temporary file"); + throw se; + } + } + } while (!fs.createDirectory(f.getPath())); + return f; + } + + public static File createTempDirectory(String prefix, String suffix) + throws IOException + { + return createTempDirectory(prefix, suffix, null); + } + + /* -- Basic infrastructure -- */ /** -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at Sun.COM Fri Mar 27 14:30:43 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Fri, 27 Mar 2009 14:30:43 +0000 Subject: RFE 4735419: File.createTempDirectory() to create a temporary directory In-Reply-To: References: Message-ID: <49CCE313.9010402@sun.com> Michal Conos wrote: > Hi, > > I'd like to work on this RFE: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4735419 > > It looks like an easy start if I want to contribute to openjdk. > Customers are > often using a "workaround" described in bug which contains a race. > > My solution would be something like proposed bellow - but it'd be nice > if someone could guide me through the process since I'd like to work > on more RFEs. You'll probably want to start with the "How to contribute" page (http://openjdk.java.net/contribute). I agree this could one could be useful but at the same time applications using the system's temporary directory can lead to security issues. -Alan. From Alan.Bateman at Sun.COM Fri Mar 27 14:35:37 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Fri, 27 Mar 2009 14:35:37 +0000 Subject: Review request 6543863, 6429910, 6814948, 6822643 Message-ID: <49CCE439.3050603@sun.com> Sherman, this is your locky day :-) 6543863: (fc) FileLock.release can deadlock with FileChannel.close This is a long-standing deadlock (since 1.4) that can happen when closing a FileChannel and releasing a FileLock (obtained from the channel) at around the same time. Closing locks the FileLock while synchronized on the list of file locks; Release locks the list while holding the FileLock. The cycle is broken by changing the removeAll method to remove and return the list of the channel's file locks. 6429910: (fc) FileChannel.lock() IOException: Bad file number, not AsynchronousCloseException If the FileChannel#lock method is blocked waiting to acquire a lock on the channel's file and the FileChannel is closed then the lock method fails with IOException "Bad file number" whereas it is should throw AsynchronousCloseException. The end method, marking the end of the I/O operation was being invoked with true instead of false and so wasn't suppressing the I/O operation. 6814948: (fc) test/java/nio/channels/AsynchronousFileChannel/Lock.java failed intermittently The asynchronous close sub-test fails intermittently (about 1 per 1000 runs on the machines I tried). It's a timing issue that arises if the preclose is done before the lock attempt, in which case it will appear the file has been acquired (but the channel is closed). The lock and tryLock methods were missing an isOpen check. 6822643: (fc) AsynchronousFileChannel.close does not invalidate FileLocks This is an embarrassing one. The close method attempts to release and invalidate all locks but the "shared" FileLockTable removeAll implementation checked the lock's channel using lock.channel() instead of lock.acquiredBy() (and hence only worked for FileChannel). The webrev is here: http://cr.openjdk.java.net/~alanb/6543863%2b6429910%2b6814948%2b6822643/webrev.00/ Thanks, Alan. From Xueming.Shen at Sun.COM Fri Mar 27 15:58:04 2009 From: Xueming.Shen at Sun.COM (Xueming Shen) Date: Fri, 27 Mar 2009 07:58:04 -0800 Subject: Review request for 6772303 In-Reply-To: <49C9228E.20702@sun.com> References: <49C9228E.20702@sun.com> Message-ID: <49CCF78C.2050305@sun.com> looks good, approved. Alan Bateman wrote: > 6772303: (se) IOException: Invalid argument" thrown on a call to > Selector.select(value) with -d64 > > This is Solaris and 64-bit specific. In summary, the DP_POLL ioctl > used to retrieve events from the /dev/poll driver limits the number of > pollfd entries in the poll array to the maximum number of file > descriptors minus 1. The /dev/poll Selector uses this limit or 8k > (whichever is smaller) to size its poll array. This sizing breaks for > the unlimited case on 64-bit because RLIM64_INFINITY is negative (-3) > and also the code is truncating the limit to a jint. This manifests > with the select method throwing IOException "Invalid argument". There > are many ways to fix this, one of the simplest being to treat infinity > as Integer.MAX_VALUE. > > The webrev is here: > http://cr.openjdk.java.net/~alanb/6772303/webrev.00/ > > Thanks, > Alan. From Alan.Bateman at Sun.COM Fri Mar 27 16:14:18 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Fri, 27 Mar 2009 16:14:18 +0000 Subject: RFE 4519026: (process) Process should support Unicode on Win NT, request for review In-Reply-To: References: Message-ID: <49CCFB5A.2090904@sun.com> Heiko Wagner wrote: > Hi Martin, > > I have updated http://www.apis.de/pub/jdk7/ProcessImpl_md.c and > http://www.apis.de/pub/jdk7/ProcessImpl_md.c.diff. > > Changes: > > - fix block comment style > - remove note about Win95, since minumum system requirement is Win2000 > - replace comment "selected based on exe type" with "creation flags" > > I have also been thinking about adding tests to ProcessBuilder/Basic.java. > My suggestion would be to start from the version Alan made, to get the > environment issue working. I would like to stick with your test pattern of > starting a java process in the test. To show that we are now using > CreateProcessW, I would start a java with Runtime.getRuntime().exec() > having its working dir set to a, previously created, directory containing > unicode characters and do a "pwd" operation in the java child. > > Although it is also possible to have the actual exe reside on a unicode path > and pass unicode command line args, currently it is not possible to use this > test pattern, as it needs additional modifications to the java launcher and > java vm. What would you suggest to test this features, until we have a fully > unicode aware version of java.exe? > It is important to add a test. Your suggestion to use a working directory containing unicode characters is probably the best that can be done at this time. Did you think any more about eliminating getNativePath? It should be possible to move this into src/windows/classes/java/lang/ProcessImpl.java and since the working directory is already normalized it should be simpler too. -Alan. From martinrb at google.com Fri Mar 27 18:10:54 2009 From: martinrb at google.com (Martin Buchholz) Date: Fri, 27 Mar 2009 11:10:54 -0700 Subject: RFE 4519026: (process) Process should support Unicode on Win NT, request for review In-Reply-To: References: <1ccfd1c10903222024x2ba35830r2df1b4e2b9d103f9@mail.gmail.com> Message-ID: <1ccfd1c10903271110y68d6be10gdf7f85c84a408b71@mail.gmail.com> Hi Heiko, I mostly agree with Alan's comments, and add to them as follows: Please remove trailing whitespace, in accordance with Sun coding standards. I agree we should not be trying to invoke our own JDK in a subprocess in a test with Unicode arguments until we fix the launcher. In the meantime, I suggest this testing strategy: - Create a subdirectory named X - Create a bat file in X named Y.BAT which does something like MKDIR %1 - Have the test invoke X/Y.BAT with current dir X, and argument Z. - After the subprocess returns, check that directory X/Z has been created. - Have X, Y, and Z contain the most troublesome Unicode characters available. This avoids encoding issues on any pipes between the process and the subprocess. Communicate only through arguments, working directory, and the file system! Martin On Wed, Mar 25, 2009 at 02:22, Heiko Wagner wrote: > Hi Martin, > > I have updated http://www.apis.de/pub/jdk7/ProcessImpl_md.c and > http://www.apis.de/pub/jdk7/ProcessImpl_md.c.diff. > > Changes: > > - fix block comment style > - remove note about Win95, since minumum system requirement is Win2000 > - replace comment "selected based on exe type" with "creation flags" > > I have also been thinking about adding tests to ProcessBuilder/Basic.java. > My suggestion would be to start from the version Alan made, to get the > environment issue working. I would like to stick with your test pattern of > starting a java process in the test. To show that we are now using > CreateProcessW, I would start a java with Runtime.getRuntime().exec() > having its working dir set to a, previously created, directory containing > unicode characters and do a "pwd" operation in the java child. > > Although it is also possible to have the actual exe reside on a unicode path > and pass unicode command line args, currently it is not possible to use this > test pattern, as it needs additional modifications to the java launcher and > java vm. What would you suggest to test this features, until we have a fully > unicode aware version of java.exe? > > Regards > Heiko > -----Original Message----- > From: Martin Buchholz [mailto:martinrb at google.com] > Sent: Montag, 23. M?rz 2009 04:24 > To: Heiko Wagner > Cc: core-libs-dev at openjdk.java.net; Xueming Shen; Alan Bateman > Subject: Re: RFE 4519026: (process) Process should support Unicode on > Win NT, request for review > > > Heiko, > Thanks for your continuing work on this. > > ProcessBuilder/Basic.java has most of the tests related to > subprocesses. ?I can't explain a return code of 6, > since the test uses 5, 7, and 8. > > ProcessBuilder has a lot of infrastructure to help you write > a test in this area, but it can be intimidating to newcomers > (i.e. anyone but myself). > > The JDK C code is quite inconsistent, but please use the style > > /* > ?* comments > ?* here > ?*/ > > for block comments, and /* inline comments */ like this. > > You need to remove the comment > ?/* selected based on exe type */ > which is no longer correct. > > If you fix the style things, and get the tests to pass, > and add a test for what you're actually trying to fix, > I am ready to approve the change. > > Martin > > From Ulf.Zibis at gmx.de Fri Mar 27 20:29:37 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 27 Mar 2009 21:29:37 +0100 Subject: java-nio-charset-enhanced -- Milestone 4 is released Message-ID: <49CD3731.3060302@gmx.de> Hi folks, milestone 4 of charset enhancement is released. - I reduced the jar-footprint, concerning entire single-byte needs, compared to original JDK 6 binaries, down to 7 %, which also should perform class loading, (not to forget: encoder maps are lazy initialized), even though there are added 21 specialized coder algorithms. - In this release there is only 1 class for all single-byte charsets, which reads decoder mapping + all names including aliases from a small data file (69..731 Bytes, average 250 Bytes). This is possible, because numerous charsets can inherit their mappings (256 2-byte chars) from each other, and empty or 1:1 ranges (especially \u0000..\u007F) are filled by constructor. - Additionally a set of 7 Decoder and 14 Encoder classes do there work, specially speed + memory optimised for the charsets, having diverse character spreading and frequency of occurrence. A special MapCalculator class for playing with different parameters is provided in the test package. - The aliases and historical names should no more statically and entirely loaded, provided and linked from StandardCharsets class. They additionally could be easy edited in files standard-charsets and extended-charsets (refer Bug Id: 6795538 ). If some day they are defined entirely upper-case, they could be omitted completely, as they are redundantly case-standardised existing in the FastCharsetProvider lookup maps. Determining the 'contains()' references by this way would be also reasonable (refer Bug Id: 6761481 ), but containment of ASCII is already calculated automatically. See my projects home: ---> https://java-nio-charset-enhanced.dev.java.net/ I believe, these techniques could also be used for most multi-byte charsets, especially inheriting maps to reduce entire charsets footprint. _Outlook Milestone 5_ : Final performance optimisation by dedicated inlining, exception catching, surrogate handling etc.. *Urgently waiting* for Christian Thalinger's optimization of "widening conversions". Happy easter, -Ulf P.S.: I'm on the way, providing changesets slice by slice for OpenJDK 7. BTW: Is there a way to add author and/or contributor annotation in the sources to _honour the investigation of external collaborators_ (almost 1 year in my case)? -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Fri Mar 27 21:49:24 2009 From: martinrb at google.com (Martin Buchholz) Date: Fri, 27 Mar 2009 14:49:24 -0700 Subject: java-nio-charset-enhanced -- Milestone 4 is released In-Reply-To: <49CD3731.3060302@gmx.de> References: <49CD3731.3060302@gmx.de> Message-ID: <1ccfd1c10903271449s4e17395fl960f99f90a0fb538@mail.gmail.com> Again, Ulf, I love the sort of stuff you're doing. I hope to be able to contribute some enginering to your effort myself someday. In the meantime, we need some infrastructure to guarantee that the behavior of the charsets is completely unchanged as we optimize. I have some code left behind at Sun to do that, i.e. compare different JDKs w.r.t charset compatibility. Hopefully Sun engineers can resurrect that code and perhaps put it into a public mercurial repo somewhere. Another approach is to take the code in tests like my Find{En,De}coderBugs.java tests which compare direct vs. regular buffers, and retarget it to compare two different jdks. It's too difficult to give credit to external contributors. One problem is that the Contributed-by: line is a red flag to lawyers and other folks that might cause the legality of the change to be questioned without end. Let's try to get Ulf a proper commit bit and make sure the legal questions come to an end. Martin On Fri, Mar 27, 2009 at 13:29, Ulf Zibis wrote: > Hi folks, > > milestone 4 of charset enhancement is released. > > - I reduced the jar-footprint, concerning entire single-byte needs, compared > to original JDK 6 binaries, down to 7 %, which also should perform class > loading, (not to forget: encoder maps are lazy initialized), even though > there are added 21 specialized coder algorithms. > - In this release there is only 1 class for all > single-byte charsets, which reads decoder mapping + all names including > aliases from a small data file (69..731 Bytes, average 250 Bytes). This is > possible, because numerous charsets can inherit their mappings (256 2-byte > chars) from each other, and empty or 1:1 ranges (especially \u0000..\u007F) > are filled by constructor. > - Additionally a set of 7 Decoder and 14 Encoder classes do there work, > specially speed + memory optimised for the charsets, having diverse > character spreading and frequency of occurrence. A special MapCalculator > class for playing with different parameters is provided in the test package. > - The aliases and historical names should no more statically and entirely > loaded, provided and linked from StandardCharsets class. They additionally > could be easy edited in files standard-charsets and extended-charsets (refer > Bug Id: 6795538). If some day they are defined entirely upper-case, they > could be omitted completely, as they are redundantly case-standardised > existing in the FastCharsetProvider lookup maps. Determining the > 'contains()' references by this way would be also reasonable (refer Bug Id: > 6761481), but containment of ASCII is already calculated automatically. > > See my projects home: ---> https://java-nio-charset-enhanced.dev.java.net/ > > I believe, these techniques could also be used for most multi-byte charsets, > especially inheriting maps to reduce entire charsets footprint. > > > Outlook Milestone 5 : Final performance optimisation by dedicated inlining, > exception catching, surrogate handling etc.. > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Urgently waiting for Christian Thalinger's > optimization of "widening conversions". > > > Happy easter, > > -Ulf > > P.S.: I'm on the way, providing changesets slice by slice for OpenJDK 7. > BTW: Is there a way to add author and/or contributor annotation in the > sources to honour the investigation of external collaborators (almost 1 year > in my case)? > > > From Ulf.Zibis at gmx.de Fri Mar 27 22:44:54 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 27 Mar 2009 23:44:54 +0100 Subject: java-nio-charset-enhanced -- Milestone 4 is released In-Reply-To: <1ccfd1c10903271449s4e17395fl960f99f90a0fb538@mail.gmail.com> References: <49CD3731.3060302@gmx.de> <1ccfd1c10903271449s4e17395fl960f99f90a0fb538@mail.gmail.com> Message-ID: <49CD56E6.70405@gmx.de> Am 27.03.2009 22:49, Martin Buchholz schrieb: > Again, Ulf, I love the sort of stuff you're doing. > Much thanks again for the flowers. :-) > I hope to be able to contribute some enginering > to your effort myself someday. > > In the meantime, we need some infrastructure to guarantee that > the behavior of the charsets is completely unchanged as we optimize. > I have some code left behind at Sun to do that, i.e. compare different > JDKs w.r.t charset compatibility. > Hopefully Sun engineers can resurrect that code and perhaps put it > into a public mercurial repo somewhere. > > Another approach is to take the code in tests like my > Find{En,De}coderBugs.java tests which compare direct > vs. regular buffers, and retarget it to compare two different jdks. > I also have coded such a test for full-scan comparision: See CharsetsTest + LegacyCharset (it retrieves the legacy charsets by reflection directly from rt.jar of the patched JDK) here: https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/test/sun/nio/cs/ It cost me several nights having all code points equal, faced to my special mixture of range-limited direct maps and full-range indirected map. > It's too difficult to give credit to external contributors. > One problem is that the Contributed-by: line is a red flag to > lawyers and other folks that might cause the legality of the change > to be questioned without end. Let's try to get Ulf a proper commit bit > and make sure the legal questions come to an end. > Aren't "Contributed-by" and "author" comments usual practice in open source products? Even in Sun's JRL source author was mentioned. I think, the lawyer guys and girls from Sun should rethink that subject. Ok, we will see ... > Martin > > On Fri, Mar 27, 2009 at 13:29, Ulf Zibis wrote: > >> Hi folks, >> >> milestone 4 of charset enhancement is released. >> >> - I reduced the jar-footprint, concerning entire single-byte needs, compared >> to original JDK 6 binaries, down to 7 %, which also should perform class >> loading, (not to forget: encoder maps are lazy initialized), even though >> there are added 21 specialized coder algorithms. >> - In this release there is only 1 class for all >> single-byte charsets, which reads decoder mapping + all names including >> aliases from a small data file (69..731 Bytes, average 250 Bytes). This is >> possible, because numerous charsets can inherit their mappings (256 2-byte >> chars) from each other, and empty or 1:1 ranges (especially \u0000..\u007F) >> are filled by constructor. >> - Additionally a set of 7 Decoder and 14 Encoder classes do there work, >> specially speed + memory optimised for the charsets, having diverse >> character spreading and frequency of occurrence. A special MapCalculator >> class for playing with different parameters is provided in the test package. >> - The aliases and historical names should no more statically and entirely >> loaded, provided and linked from StandardCharsets class. They additionally >> could be easy edited in files standard-charsets and extended-charsets (refer >> Bug Id: 6795538). If some day they are defined entirely upper-case, they >> could be omitted completely, as they are redundantly case-standardised >> existing in the FastCharsetProvider lookup maps. Determining the >> 'contains()' references by this way would be also reasonable (refer Bug Id: >> 6761481), but containment of ASCII is already calculated automatically. >> >> See my projects home: ---> https://java-nio-charset-enhanced.dev.java.net/ >> >> I believe, these techniques could also be used for most multi-byte charsets, >> especially inheriting maps to reduce entire charsets footprint. >> >> >> Outlook Milestone 5 : Final performance optimisation by dedicated inlining, >> exception catching, surrogate handling etc.. >> Urgently waiting for Christian Thalinger's >> optimization of "widening conversions". >> >> >> Happy easter, >> >> -Ulf >> >> P.S.: I'm on the way, providing changesets slice by slice for OpenJDK 7. >> BTW: Is there a way to add author and/or contributor annotation in the >> sources to honour the investigation of external collaborators (almost 1 year >> in my case)? >> >> >> >> > > > From martinrb at google.com Sun Mar 29 18:27:26 2009 From: martinrb at google.com (Martin Buchholz) Date: Sun, 29 Mar 2009 11:27:26 -0700 Subject: java-nio-charset-enhanced -- Milestone 4 is released In-Reply-To: <49CD56E6.70405@gmx.de> References: <49CD3731.3060302@gmx.de> <1ccfd1c10903271449s4e17395fl960f99f90a0fb538@mail.gmail.com> <49CD56E6.70405@gmx.de> Message-ID: <1ccfd1c10903291127v198f35det56ac310d0bb8157b@mail.gmail.com> On Fri, Mar 27, 2009 at 15:44, Ulf Zibis wrote: > Am 27.03.2009 22:49, Martin Buchholz schrieb: >> >> Again, Ulf, I love the sort of stuff you're doing. >> > > Much thanks again for the flowers. :-) > >> I hope to be able to contribute some enginering >> to your effort myself someday. >> >> In the meantime, we need some infrastructure to guarantee that >> the behavior of the charsets is completely unchanged as we optimize. >> I have some code left behind at Sun to do that, i.e. compare different >> JDKs w.r.t charset compatibility. >> Hopefully Sun engineers can resurrect that code and perhaps put it >> into a public mercurial repo somewhere. >> >> Another approach is to take the code in tests like my >> Find{En,De}coderBugs.java tests which compare direct >> vs. regular buffers, and retarget it to compare two different jdks. >> > > I also have coded such a test for full-scan comparision: > See CharsetsTest + LegacyCharset (it retrieves the legacy charsets by > reflection directly from rt.jar of the patched JDK) here: > https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/test/sun/nio/cs/ > > It cost me several nights having all code points equal, faced to my special > mixture of range-limited direct maps and full-range indirected map. It does look like you've written a lot of good tests. It would be nice not to have an explicit list of charsets in CharsetsTest.java.PARAMETERS. I guess it's a list of charsets subject to single-byte testing? If so, better documentation would be good. Charsets named ISO-8859-* are guaranteed to be single-byte, it might be good to include those programmatically, by filtering Charsets.availableCharsets(). Why include EUC-JP but not UTF-8? It's probably still a good idea to get inspiration from my Find*Bugs tests which test many other things like complete compatibility of exceptions in case of invalid input. >> It's too difficult to give credit to external contributors. >> One problem is that the Contributed-by: line is a red flag to >> lawyers and other folks that might cause the legality of the change >> to be questioned without end. ?Let's try to get Ulf a proper commit bit >> and make sure the legal questions come to an end. >> > > Aren't "Contributed-by" and "author" comments usual practice in open source > products? > Even in Sun's JRL source author was mentioned. I think, the lawyer guys and > girls from Sun should rethink that subject. > Ok, we will see ... The problem is more human. One would like to give credit for good ideas or good analysis, but the only official way to give credit in a commit message is via a simple Contributed-by: email-address which raises legal doubts even when there is no copyrighted material. I guess one can abuse the Summary: field to squeeze in thank-yous, but it's pretty obvious that you are circumventing the process. Martin From Ulf.Zibis at gmx.de Sun Mar 29 19:49:24 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sun, 29 Mar 2009 21:49:24 +0200 Subject: java-nio-charset-enhanced -- Milestone 4 is released In-Reply-To: <1ccfd1c10903291127v198f35det56ac310d0bb8157b@mail.gmail.com> References: <49CD3731.3060302@gmx.de> <1ccfd1c10903271449s4e17395fl960f99f90a0fb538@mail.gmail.com> <49CD56E6.70405@gmx.de> <1ccfd1c10903291127v198f35det56ac310d0bb8157b@mail.gmail.com> Message-ID: <49CFD0C4.2020200@gmx.de> Am 29.03.2009 20:27, Martin Buchholz schrieb: > On Fri, Mar 27, 2009 at 15:44, Ulf Zibis wrote: > >> >> I also have coded such a test for full-scan comparision: >> See CharsetsTest + LegacyCharset (it retrieves the legacy charsets by >> reflection directly from rt.jar of the patched JDK) here: >> https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/test/sun/nio/cs/ >> >> It cost me several nights having all code points equal, faced to my special >> mixture of range-limited direct maps and full-range indirected map. >> > > It does look like you've written a lot of good tests. > It would be nice not to have an explicit list of charsets in > CharsetsTest.java.PARAMETERS. > The advantage of this list is, that I can disable charsets by line-commenting to speed up the test while debugging special cases. > I guess it's a list of charsets subject to single-byte testing? > Yes, + charsets depending on those. E.g. EUC-JP depends on JIS-X-0201. > If so, better documentation would be good. > Charsets named ISO-8859-* are guaranteed to be single-byte, > it might be good to include those programmatically, > by filtering Charsets.availableCharsets(). > Good idea, but how to catch those, which internally use single-byte charsets e.g. JIS-X-0201? > Why include EUC-JP but not UTF-8? > UTF-8 is not affected of my changes in single-byte charsets. > It's probably still a good idea to get inspiration from my > Find*Bugs I'll keep this in mind. > tests which test many other things like > complete compatibility of exceptions in case of invalid input. > I see, this would affect our discussion about malformed(). Concerning the malformed length on invalid low surrogate, I now have understood your philosophy while hacking the UTF-8 coder. As result I've filed a bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6798515 Concerning \uFFFE and \uFFFF I still think, that they are invalid, as these code points don't have any valid meaning from Java VM side, so why should they be seen as possibly mappable to other char encodings. Handling of BOM etc. should be done otherwise, e.g. by coder initialization or the flush() method. > The problem is more human. One would like to give credit for good ideas > or good analysis, but the only official way to give credit in a commit > message is > via a simple > Contributed-by: email-address > which raises legal doubts even when there is no copyrighted material. > I guess one can abuse the Summary: field to squeeze in thank-yous, > but it's pretty obvious that you are circumventing the process. > The last paragraph is difficult for me to understand in english. Could you please translate it? -Ulf From martinrb at google.com Sun Mar 29 20:43:23 2009 From: martinrb at google.com (Martin Buchholz) Date: Sun, 29 Mar 2009 13:43:23 -0700 Subject: java-nio-charset-enhanced -- Milestone 4 is released In-Reply-To: <49CFD0C4.2020200@gmx.de> References: <49CD3731.3060302@gmx.de> <1ccfd1c10903271449s4e17395fl960f99f90a0fb538@mail.gmail.com> <49CD56E6.70405@gmx.de> <1ccfd1c10903291127v198f35det56ac310d0bb8157b@mail.gmail.com> <49CFD0C4.2020200@gmx.de> Message-ID: <1ccfd1c10903291343k33f7c2f4j15e2e002bee4f22f@mail.gmail.com> On Sun, Mar 29, 2009 at 12:49, Ulf Zibis wrote: > Am 29.03.2009 20:27, Martin Buchholz schrieb: >> >> On Fri, Mar 27, 2009 at 15:44, Ulf Zibis wrote: >> >>> >>> I also have coded such a test for full-scan comparision: >>> See CharsetsTest + LegacyCharset (it retrieves the legacy charsets by >>> reflection directly from rt.jar of the patched JDK) here: >>> >>> https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/test/sun/nio/cs/ >>> >>> It cost me several nights having all code points equal, faced to my >>> special >>> mixture of range-limited direct maps and full-range indirected map. >>> >> >> It does look like you've written a lot of good tests. >> It would be nice not to have an explicit list of charsets in >> CharsetsTest.java.PARAMETERS. >> > > The advantage of this list is, that I can disable charsets by > line-commenting to speed up the test while debugging special cases. See my posted mega-patch for how you can provide a -Dcharset=XXXX flag to FindDecoderBugs.java. I think that's a better solution for the debugging problem. Of course I've had exactly the same problem. >> The problem is more human. ?One would like to give credit for good ideas >> or good analysis, but the only official way to give credit in a commit >> message is >> via a simple >> Contributed-by: email-address >> which raises legal doubts even when there is no copyrighted material. >> I guess one can abuse the Summary: field to squeeze in thank-yous, >> but it's pretty obvious that you are circumventing the process. >> > > The last paragraph is difficult for me to understand in english. Could you > please translate it? Ist in allen Sprachen schwierig zu erklaeren. Sag mal, mein Freund Ralf hat 'ne gute Idee. Ich mach'n Patch darauss. Ich mochte genau dass in meiner commit-message sagen, aber dass ist derzeit verboten, weil das commit-message-format zu beschraenkt ist. Insbesondere, Contributed-by: ist nicht geeignet, weil dann immer wieder gefragt wird, "Hat Ralf das Contributor Agreement unterschrieben?", und nur eine email-Addresse erlaubt ist. Martin From Ulf.Zibis at gmx.de Mon Mar 30 15:42:57 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 30 Mar 2009 17:42:57 +0200 Subject: java-nio-charset-enhanced -- Milestone 4 is released In-Reply-To: <1ccfd1c10903291127v198f35det56ac310d0bb8157b@mail.gmail.com> References: <49CD3731.3060302@gmx.de> <1ccfd1c10903271449s4e17395fl960f99f90a0fb538@mail.gmail.com> <49CD56E6.70405@gmx.de> <1ccfd1c10903291127v198f35det56ac310d0bb8157b@mail.gmail.com> Message-ID: <49D0E881.9090709@gmx.de> I would like to inform you about an older comunication with Ray Gans. See below ... Am 29.03.2009 20:27, Martin Buchholz schrieb: > >> Aren't "Contributed-by" and "author" comments usual practice in open source >> products? >> Even in Sun's JRL source author was mentioned. I think, the lawyer guys and >> girls from Sun should rethink that subject. >> Ok, we will see ... >> > > The problem is more human. One would like to give credit for good ideas > or good analysis, but the only official way to give credit in a commit > message is > via a simple > Contributed-by: email-address > which raises legal doubts even when there is no copyrighted material. > I guess one can abuse the Summary: field to squeeze in thank-yous, > but it's pretty obvious that you are circumventing the process. > > Martin > > -------- Original-Nachricht -------- Betreff: Re: JDK contributions, JavaOne, and you! Datum: Sat, 13 May 2006 22:50:58 -0700 Von: Ray Gans An: Ulf Zibis Referenzen: <909C9233-A43F-48D0-8B1B-6CF63BC74157 at Sun.COM> <15073.1147548305 at www008.gmx.net> Thanks! -Ray On May 13, 2006, at 12:25 PM, Ulf Zibis wrote: > I agree to the terms of this form > > > Regards > > Ulf Zibis > > >> --- Urspr?ngliche Nachricht --- >> Von: Ray Gans >> An: Ulf.Zibis at gmx.de >> Betreff: JDK contributions, JavaOne, and you! >> Datum: Wed, 10 May 2006 22:58:40 -0700 >> >> Hi Ulf, >> >> Thank you for contributing to Mustang and being part of the JDK >> Community. It's been a good year for Java SE and a lot has happened. >> We're preparing for JavaOne now and I have a few things I'd like to >> ask you: >> >> 1) First of all, we made a mistake on our JDK code contribution form >> and forgot to ask permission to use the names of people who provide >> fixes that get included in Mustang. We want to list them (names only) >> in our release notes, on the Mustang project web pages, and in public >> presentations like at JavaOne. To be clear, names will only be used >> to identify people who made code contributions that were accepted >> into a JDK release -- nothing else. >> >> --> Does Sun have your permission to do this? >> If you would prefer to be recognized under a different name, please >> let me know that too. >> >> 2) We also want to honor people like you at JavaOne next week who >> have been involved with Mustang and the JDK Community. For example, >> one thing we'd like to do is to provide a running slideshow of >> pictures of people at JavaOne who have been active in the JDK >> Community. If you want to be featured there (and possibly at some of >> the talks), please send me a hi-res digital picture of yourself >> (headshot -- shoulders and above would be best, but not essential) >> and a short bio describing where you live and your interests in Java. >> Again this material will -only- be used to feature you as a person >> who has been active in the JDK Community as a code contributor. I >> need this immediately to use it -- the request just came in today,so >> I apologize for the rush. >> >> --> To satisfy our legal folks, I have attached a release form that >> explains how we'll use these materials. No need to sign it, just >> reply to this e-mail with the form, your picture and bio attached, >> and the words "I agree to the terms of this form." >> >> 3) Lastly, please let me know if you're coming to JavaOne. If so, >> don't forget to stop by the JDK Community booth in the JavaOne >> Pavilion so Sun's JDK Community team can meet you. We'll be hosting a >> JDK Community BOF (BOF-0178) on Wednesday night at 10:30 in Moscone >> to discuss what's happened in the community this last year and listen >> to what we should do moving forward. It would be great if you could >> attend and let us know your thoughts and experiences with Mustang and >> the JDK Community. >> >> If you are attending JavaOne, I also want to make sure you know about >> the JDK Community party we're having at the Argent Hotel at 8:30 on >> Tuesday the 16th. There will be good food and drink there for you to >> enjoy as well as opportunities to talk with the JDK team. >> >> For more info about the JDK Community at JavaOne, please click the >> JavaOne button here: >> http://community.java.net/jdk/ >> >> Thanks again for your contributions to Mustang. Your passion and >> dedication to the Java platform is making a real difference! >> >> Best regards, >> >> Ray Gans >> Program Manager >> JDK Community >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.bateman at sun.com Mon Mar 30 18:39:55 2009 From: alan.bateman at sun.com (alan.bateman at sun.com) Date: Mon, 30 Mar 2009 18:39:55 +0000 Subject: hg: jdk7/tl/jdk: 3 new changesets Message-ID: <20090330184131.24CBCECBC@hg.openjdk.java.net> Changeset: 7264cacbddaa Author: alanb Date: 2009-03-27 15:24 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7264cacbddaa 6693490: (se) select throws "File exists" IOException under load (lnx) Reviewed-by: sherman ! src/share/classes/sun/nio/ch/SelChImpl.java ! src/solaris/classes/sun/nio/ch/EPollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/EPollSelectorImpl.java + test/java/nio/channels/Selector/RegAfterPreClose.java Changeset: 9fa8b6276b31 Author: alanb Date: 2009-03-27 16:04 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9fa8b6276b31 6772303: (se) IOException: Invalid argument" thrown on a call to Selector.select(value) with -d64 Reviewed-by: sherman ! src/solaris/native/sun/nio/ch/DevPollArrayWrapper.c Changeset: ff0a9e50f033 Author: alanb Date: 2009-03-30 19:22 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ff0a9e50f033 Merge From jonathan.gibbons at sun.com Mon Mar 30 22:12:46 2009 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Mon, 30 Mar 2009 22:12:46 +0000 Subject: hg: jdk7/tl/langtools: 6819246: improve support for decoding instructions in classfile library Message-ID: <20090330221250.A7E48ECD0@hg.openjdk.java.net> Changeset: 07da2ffbb76b Author: jjg Date: 2009-03-30 15:08 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/07da2ffbb76b 6819246: improve support for decoding instructions in classfile library Reviewed-by: ksrini ! src/share/classes/com/sun/tools/classfile/Code_attribute.java + src/share/classes/com/sun/tools/classfile/Instruction.java - src/share/classes/com/sun/tools/classfile/OpCodes.java + src/share/classes/com/sun/tools/classfile/Opcode.java ! src/share/classes/com/sun/tools/javap/CodeWriter.java From mr at sun.com Tue Mar 31 04:51:08 2009 From: mr at sun.com (Mark Reinhold) Date: Mon, 30 Mar 2009 21:51:08 -0700 Subject: java-nio-charset-enhanced -- Milestone 4 is released In-Reply-To: martinrb@google.com; Sun, 29 Mar 2009 11:27:26 PDT; <1ccfd1c10903291127v198f35det56ac310d0bb8157b@mail.gmail.com> Message-ID: <20090331045108.3C73D2665C@callebaut.niobe.net> > Date: Sun, 29 Mar 2009 11:27:26 -0700 > From: Martin Buchholz > On Fri, Mar 27, 2009 at 15:44, ulf.zibis at gmx.de wrote: >> Am 27.03.2009 22:49, Martin Buchholz schrieb: >>> It's too difficult to give credit to external contributors. >>> One problem is that the Contributed-by: line is a red flag to >>> lawyers and other folks that might cause the legality of the change >>> to be questioned without end. ?Let's try to get Ulf a proper commit bit >>> and make sure the legal questions come to an end. >> >> Aren't "Contributed-by" and "author" comments usual practice in open >> source products? Even in Sun's JRL source author was mentioned. I >> think, the lawyer guys and girls from Sun should rethink that subject. >> Ok, we will see ... > > The problem is more human. One would like to give credit for good > ideas or good analysis, but the only official way to give credit in a > commit message is via a simple > Contributed-by: email-address > which raises legal doubts even when there is no copyrighted material. Exactly what sort of legal doubts do you have in mind here? We already require the contributor of any nontrivial change to submit an SCA prior to that change being integrated. Is that not sufficient? > I guess one can abuse the Summary: field to squeeze in thank-yous, > but it's pretty obvious that you are circumventing the process. Perhaps -- but if we need to fix the process, then we can do that. - Mark From jonathan.gibbons at sun.com Tue Mar 31 18:12:29 2009 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Tue, 31 Mar 2009 18:12:29 +0000 Subject: hg: jdk7/tl/langtools: 6817950: refactor ClassReader to improve attribute handling Message-ID: <20090331181233.9958FED5C@hg.openjdk.java.net> Changeset: 89f67512b635 Author: jjg Date: 2009-03-31 11:07 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/89f67512b635 6817950: refactor ClassReader to improve attribute handling Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/jvm/ClassFile.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java From jonathan.gibbons at sun.com Tue Mar 31 18:19:59 2009 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Tue, 31 Mar 2009 18:19:59 +0000 Subject: hg: jdk7/tl/langtools: 6813059: replace use of JavaCompiler.errorCount with shouldContinue Message-ID: <20090331182003.7B912ED61@hg.openjdk.java.net> Changeset: af10262bd031 Author: jjg Date: 2009-03-31 11:16 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/af10262bd031 6813059: replace use of JavaCompiler.errorCount with shouldContinue Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java + test/tools/javac/policy/test3/A.java + test/tools/javac/policy/test3/Test.java From Xueming.Shen at Sun.COM Tue Mar 31 21:16:09 2009 From: Xueming.Shen at Sun.COM (Xueming Shen) Date: Tue, 31 Mar 2009 14:16:09 -0700 Subject: Review request for 6795561 In-Reply-To: <49C89E3E.2020700@sun.com> References: <49C89E3E.2020700@sun.com> Message-ID: <49D28819.7000104@sun.com> looks good; approved. Alan Bateman wrote: > 6795561: (bf) CharBuffer.subSequence() uses wrong capacity value for > new buffer > > Iris, you might want to review this one. > CharBuffer#subSequence(start,end) is specified to return a char buffer > that has a position of position() + start, a limit of position() + > end, and a capacity of capacity(). For buffers created via > CharBuffer#allocate or char buffer views we've always generated code > that return a CharBuffer with a position of 0 and a limit and capacity > that is the length of the subsequence. To my knowledge this hasn't > been noticed, probably because it required casting the result to a > char buffer. In jdk7 this method has been updated to take advantage of > covariant returns so it's more likely to be noticed now. Furthermore, > your old adversary StringCharBuffer (used when wrapping a char > sequence) has been returning a buffer with the incorrect capacity > since 6546113 [1], leading to the IOOBE in the bug report. We should > have caught this but didn't. To that end, I've added coverage to the > unit test. > > The webrev is here: > http://cr.openjdk.java.net/~alanb/6795561/webrev.00/ > > Thanks, > Alan. > > [1] http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c73cb47fe250