From stuart.marks at oracle.com Tue May 1 01:52:54 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 30 Apr 2012 18:52:54 -0700 Subject: Proposed refactoring: introduce JLS7 language features to core libs In-Reply-To: <5FA2ABE2-4272-4F7A-8880-74E426C04346@mac.com> References: <7BCF83EB-75F1-46A6-917E-2619974A4545@mac.com> <5FA2ABE2-4272-4F7A-8880-74E426C04346@mac.com> Message-ID: <4F9F41F6.40609@oracle.com> On 4/25/12 12:07 PM, Stefan Reich wrote: > Hello, > > is there any interest to accept change sets based on OpenJDK 7 that update the java classes in jdk/src/share/classes to use > > * multi-catch > * string switch statements as opposed to nested if statements when comparing strings with string literals > * type inference by removing duplicative type information in the constructor when using generics > * indexOf(int) when indexOf(String) is used with a String literal that contains only one character, and similar small-scale improvements? > > The proposed change sets would pass all jtreg tests. If there is interest, what would be next steps? Hi, yes, there is interest! Thanks for raising this topic. In some respects this seems similar to the "Coinification" work [1] I did during JDK7 development, that is, to use the then-new Project Coin features in the code base of the JDK itself. The goal of that effort was to put some of the Coin features to use in production code, so as to gain experience with them, but not necessarily to "coinify" the entire source base. In fact I've been asked how much of the code base was converted to use the new features. The answer is, I don't know. I'm pretty sure that there is a lot remaining to be done, though. (As an aside, most of the warnings work we've been doing over the past several months is to clean warnings that result from the use of raw types instead of generics. That is, there is lots of code lying around that hasn't been updated to Java 5 generics yet! There are similar refactorings one could apply for Java 5 language features, such as the enhanced-for loop, enums, covariant overrides, autoboxing, etc.) Probably the easiest feature to get started with is diamond (formally known as "type inference for generic instance creation"). It should be fairly simple to find lots of examples where this can be put to use, now that there are bulk change hints available in NetBeans. (Bulk changes are probably also available in Eclipse and IntelliJ Idea.) The good thing about diamond is that it is practically impossible to bugs when doing diamond conversion. In fact, the resulting class files should be byte-for-byte identical to the previous versions. In practice, though, I did join lines where appropriate, since using diamond often shortened the code enough to fit on a single line where it had to be split across lines before. There are a small number of stylistic issues that occur when using diamond; see [2] and [3]. Different people have different styles, and unfortunately different styles have emerged in different areas of code. The main difference seems to be whether diamond is used in assignment and return statements, where the use of diamond is separated from the variable declaration that contains the complete type. In practice what this means is that you should break down your changesets to apply to different functional areas, and then find the right people and the right mailing list to discuss the changes beforehand. (Actually this is probably good practice for any change, not just diamond.) Turning to the other suggestions, I'd say that multi-catch and strings-in-switch are also fairly safe refactorings to propose, although they probably occur much less frequently than diamond. There are some subtleties with applying these refactorings, which will require more scrutiny than applying diamond changes. For example, in some cases there is a catch of Exception that is better expressed as a multi-catch of several Exception subtypes. This might make for better code, but it subtly changes the behavior of the code. For strings-in-switch, a null value of the switch expression results in NPE, whereas (depending on the details, of course) a cascade of if-elses may end up handling null differently. I'm not sure about the indexOf() cases you refer to. I guess I'd have to see some examples before deciding whether these are worthwhile to pursue. In any case, thanks for taking the initiative to work on this stuff. Looking forward to seeing what you come up with. s'marks [1] http://stuartmarks.wordpress.com/2010/12/23/jdk7-coin-and-making-libraries-fresh-and-minty/ [2] http://stuartmarks.wordpress.com/2011/01/24/where-can-diamond-be-used/ [3] http://stuartmarks.wordpress.com/2011/04/29/when-should-diamond-be-used/ From martijnverburg at gmail.com Tue May 1 09:33:36 2012 From: martijnverburg at gmail.com (Martijn Verburg) Date: Tue, 1 May 2012 10:33:36 +0100 Subject: Proposed refactoring: introduce JLS7 language features to core libs In-Reply-To: <4F9F41F6.40609@oracle.com> References: <7BCF83EB-75F1-46A6-917E-2619974A4545@mac.com> <5FA2ABE2-4272-4F7A-8880-74E426C04346@mac.com> <4F9F41F6.40609@oracle.com> Message-ID: Hi all, > On 4/25/12 12:07 PM, Stefan Reich wrote: >> >> Hello, >> >> is there any interest to accept change sets based on OpenJDK 7 that update >> the java classes in jdk/src/share/classes to use >> >> * multi-catch >> * string switch statements as opposed to nested if statements when >> comparing strings with string literals >> * type inference by removing duplicative type information in the >> constructor when using generics >> * indexOf(int) when indexOf(String) is used with a String literal that >> contains only one character, and similar small-scale improvements? >> >> The proposed change sets would pass all jtreg tests. If there is interest, >> what would be next steps? > > > Hi, yes, there is interest! Thanks for raising this topic. > > In some respects this seems similar to the "Coinification" work [1] I did > during JDK7 development, that is, to use the then-new Project Coin features > in the code base of the JDK itself. The goal of that effort was to put some > of the Coin features to use in production code, so as to gain experience > with them, but not necessarily to "coinify" the entire source base. In fact > I've been asked how much of the code base was converted to use the new > features. The answer is, I don't know. I'm pretty sure that there is a lot > remaining to be done, though. > > (As an aside, most of the warnings work we've been doing over the past > several months is to clean warnings that result from the use of raw types > instead of generics. That is, there is lots of code lying around that hasn't > been updated to Java 5 generics yet! There are similar refactorings one > could apply for Java 5 language features, such as the enhanced-for loop, > enums, covariant overrides, autoboxing, etc.) > > Probably the easiest feature to get started with is diamond (formally known > as "type inference for generic instance creation"). It should be fairly > simple to find lots of examples where this can be put to use, now that there > are bulk change hints available in NetBeans. (Bulk changes are probably also > available in Eclipse and IntelliJ Idea.) The good thing about diamond is > that it is practically impossible to bugs when doing diamond conversion. In > fact, the resulting class files should be byte-for-byte identical to the > previous versions. In practice, though, I did join lines where appropriate, > since using diamond often shortened the code enough to fit on a single line > where it had to be split across lines before. > > There are a small number of stylistic issues that occur when using diamond; > see [2] and [3]. Different people have different styles, and unfortunately > different styles have emerged in different areas of code. The main > difference seems to be whether diamond is used in assignment and return > statements, where the use of diamond is separated from the variable > declaration that contains the complete type. > > In practice what this means is that you should break down your changesets to > apply to different functional areas, and then find the right people and the > right mailing list to discuss the changes beforehand. (Actually this is > probably good practice for any change, not just diamond.) > > Turning to the other suggestions, I'd say that multi-catch and > strings-in-switch are also fairly safe refactorings to propose, although > they probably occur much less frequently than diamond. There are some > subtleties with applying these refactorings, which will require more > scrutiny than applying diamond changes. > > For example, in some cases there is a catch of Exception that is better > expressed as a multi-catch of several Exception subtypes. This might make > for better code, but it subtly changes the behavior of the code. For > strings-in-switch, a null value of the switch expression results in NPE, > whereas (depending on the details, of course) a cascade of if-elses may end > up handling null differently. > > I'm not sure about the indexOf() cases you refer to. I guess I'd have to see > some examples before deciding whether these are worthwhile to pursue. > > In any case, thanks for taking the initiative to work on this stuff. Looking > forward to seeing what you come up with. > > s'marks > > [1] > http://stuartmarks.wordpress.com/2010/12/23/jdk7-coin-and-making-libraries-fresh-and-minty/ > [2] http://stuartmarks.wordpress.com/2011/01/24/where-can-diamond-be-used/ > [3] http://stuartmarks.wordpress.com/2011/04/29/when-should-diamond-be-used/ FYI, Stefan has kindly offered to join the Adopt OpenJDK program (http://java.net/projects/jugs/pages/AdoptOpenJDK) and we'll all work together of pre-review of patches, with Stuart's comments as a starting guideline. Cheers, Martijn From alan.bateman at oracle.com Tue May 1 10:19:40 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 01 May 2012 10:19:40 +0000 Subject: hg: jdk8/tl/jdk: 7164570: (fs) WatchService queues CREATE event but not DELETE event for very short lived files [sol11] Message-ID: <20120501102003.7E06F470B3@hg.openjdk.java.net> Changeset: c22b2f9066dd Author: alanb Date: 2012-05-01 11:17 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c22b2f9066dd 7164570: (fs) WatchService queues CREATE event but not DELETE event for very short lived files [sol11] Reviewed-by: chegar ! src/solaris/classes/sun/nio/fs/SolarisWatchService.java + test/java/nio/file/WatchService/MayFlies.java From forax at univ-mlv.fr Tue May 1 10:53:17 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 01 May 2012 12:53:17 +0200 Subject: RFR: 5015163 "(str) String merge/join that is the inverse of String.split()" into JDK 8 In-Reply-To: References: <4F9B1C05.1080101@oracle.com> <4F9B2551.9070506@univ-mlv.fr> Message-ID: <4F9FC09D.80803@univ-mlv.fr> On 04/30/2012 11:03 AM, Paul Sandoz wrote: > On Apr 28, 2012, at 1:01 AM, R?mi Forax wrote: > >> Hi Jim, >> Yes, I've basically try to submit a patch each time I've written a method join >> in one of my application :) >> >> The funny think (in fact it's even not funny) is that I think that this methods >> should not be in String anymore. In Java 8, we will have defender methods >> so you can write join directly on an Iterable. And there is some discussion >> to also allow defender methods on arrays too, >> so we may can write a method join on Object[] too >> (on an interface inherited from Object[] to be precise). >> >> I really think that list.join(",") is better than "".join(",", list) and >> ["foo", "bar"].join(",") is better than "".join(",", ["foo", "bar"]). >> but maybe I'm wrong. >> > Good point. Although i don't see the harm with such methods on String that defer, or are required if say defender methods on arrays never come about. > > There are also more general cases of interpose and interleave (see Clojure's functions as an example) since join can be implemented using interpose which can be implemented using interleave. Implementing interpose with interleave requires to remove the last element, which is not so easy in lazy mode. It's easier to implement it directly. > Not saying join should be implemented that way (not so optimal for Strings only) but i think such functions are very useful. I am not tracking the lambda library work very closely, have such functions been considered? Yes, we discuss about zip/unzip, and what we call BiStream. unzip is the other name of interleave. > > Paul. R?mi From xuelei.fan at oracle.com Tue May 1 10:53:55 2012 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Tue, 01 May 2012 10:53:55 +0000 Subject: hg: jdk8/tl/jdk: 7158688: Typo in SSLContext Spec Message-ID: <20120501105406.79860470B4@hg.openjdk.java.net> Changeset: 71fdf32fdc65 Author: xuelei Date: 2012-05-01 03:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/71fdf32fdc65 7158688: Typo in SSLContext Spec Reviewed-by: weijun, wetmore ! src/share/classes/javax/net/ssl/SSLContext.java From forax at univ-mlv.fr Tue May 1 11:02:15 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 01 May 2012 13:02:15 +0200 Subject: RFR: 5015163 "(str) String merge/join that is the inverse of String.split()" into JDK 8 In-Reply-To: <4F9EA05E.6020401@oracle.com> References: <4F9B1C05.1080101@oracle.com> <4F9B2551.9070506@univ-mlv.fr> <4F9EA05E.6020401@oracle.com> Message-ID: <4F9FC2B7.2080000@univ-mlv.fr> On 04/30/2012 04:23 PM, Jim Gish wrote: > Thanks R?mi, > > I'll take a look at defender methods on Iterable. > > As far as the parameter checks on String -- I had the same "Aha!" > moment as soon as I got in my car to drive home on Friday. :) > However, it does come down to a philosophy of style in that I'm in > favor of (1) catching and reporting errors as soon as possible, and > (2) not depending on the implementation details of other methods > (particularly other classes) of which I'm a client. These checks are part of the spec of the method then part of the implementation, that's why I think it's Ok tu use them. > On the other hand, given this is "core" I realize that performance > matters as well as locality of reference, so there is a trade off > between deferring the check and sharing the static result message string. The main issue with sharing static strings is that slowdown the startup of the VM. The core classes do already too much static initialization for very little benefit, by example, loading a string requires to initialize String.CASE_INSENSITIVE_ORDER even if this comparator is not actually used. BTW, a good project should be to try to remove most of the private static fields from the public java.lang classes in order to defer their initializations. > > Let's see what others think. > > As far as transient on the static field -- I also realized as I was > driving away that statics might not be serialized so transient is > unnecessary. > > Thanks, > Jim cheers, R?mi From forax at univ-mlv.fr Tue May 1 11:15:49 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 01 May 2012 13:15:49 +0200 Subject: Remove the assert in Integer.valueOf() In-Reply-To: <4F9F0D82.301@gmx.de> References: <4F9592ED.3040309@univ-mlv.fr> <4F9A8D92.6080407@gmx.de> <4F9B20E8.8090409@univ-mlv.fr> <4F9F0D82.301@gmx.de> Message-ID: <4F9FC5E5.4030106@univ-mlv.fr> On 05/01/2012 12:09 AM, Ulf Zibis wrote: > Hi R?mi, > > Am 28.04.2012 00:42, schrieb R?mi Forax: >>> While you are there: >>> IntegerCache.cache/high/low are static final, so should be named >>> _upper case_. >> >> Not done because the system property is also spelled in lower case. > Hm, but does that justify violating very common code conventions? > IMO it's inconvenient while reading the code. Yes and no. I agree that it's again the code convention but I think that it better outline the relation with the system property. Given that all IDEs can be tweaked to display static finals with a different color/stroke, I think this code should not be changed. > >> >>> >>> Another optimization: >>> public static Integer valueOf(int i) { >>> if (i >= 0) { >>> if (i <= IntegerCache.HIGH) >>> return IntegerCache.POS[i]; >>> } else { >>> if (i >= IntegerCache.LOW) >>> return IntegerCache.NEG[~i]; >>> } >>> return new Integer(i); >>> } >>> >> >> Can you explain a little bit more why it's more efficient ? > 1. Compare against 0 is little faster than against a constant which > must be loaded as operand. Ok, less bytecode but no impact when JITed > 2. As positive arguments should be more frequent, my version prevents > from calculating the index every time: > IntegerCache.cache[i + (-IntegerCache.low)] I believe the JIT can emit a mov in that case, I will check. > 3. Client VM would profit from less bytecode instructions to go > through, as there is less inlining. Again, I need to test. > >> Given that low and high are constant for the JIT, I'm not sure the >> current code >> do bounds checking at all. > I do not understand this. 'i' is not constant, so should be checked. I was thinking about the array bound checking. > > ========================================== > > We must be careful with Integer.MAX_VALUE as maximum array size. > See: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7153247 > and: java.lang.AbstractCollection.MAX_ARRAY_SIZE This one is another bug, but you will have trouble with Integer.MAX_VALUE - (-low). R?mi > > Additionally, I think, *the assert is superfluous at all*, as 'high' > can never be smaller than 127. > You can see this, if you compact the code: > > static { > // high value may be configured by property > String cacheHigh = > > sun.misc.VM.getSavedProperty("java.lang.Integer.IntegerCache.high"); > /********** no need for variable i : **********/ > int h = 127; > if (cacheHigh != null) { > h = Math.max(parseInt(cacheHigh), 127); > // Maximum array size is Integer.MAX_VALUE > h = Math.min(h, Integer.MAX_VALUE - (-low)); > /********** little shorter : **********/ > // Maximum array size is Integer.MAX_VALUE > h = Math.min(Integer.MAX_VALUE - (-low), > Math.max(parseInt(cacheHigh), 127)); > } > high = h; > /********** more simple : **********/ > int h = 0; > if (cacheHigh != null) { > // Maximum array size is Integer.MAX_VALUE > h = Math.min(Integer.MAX_VALUE - (-low), > parseInt(cacheHigh)); > } > high = Math.max(h, 127); > /********** no need for variable h : **********/ > if (cacheHigh != null) > // Maximum array size is Integer.MAX_VALUE > high = Math.min(Integer.MAX_VALUE - (-low), > Math.max(parseInt(cacheHigh), 127)); > else > high = 127; > /********** shorter : **********/ > high = (cacheHigh == null) ? 127 : > // Maximum array size is Integer.MAX_VALUE > Math.min(Integer.MAX_VALUE - (-low), > Math.max(parseInt(cacheHigh), 127)); > /********** most short : **********/ > // Maximum array size is Integer.MAX_VALUE > high = Math.max(127, Math.min((cacheHigh == null) ? 127 : > parseInt(cacheHigh), Integer.MAX_VALUE - (-low))); > > assert IntegerCache.high >= 127; > > // range [-128, 127] must be interned (JLS7 5.1.7) > cache = new Integer[(high - low) + 1]; > for(int j = low, k = 0; k < cache.length; k++, j++) > cache[k] = new Integer(j); > } > > > -Ulf > From forax at univ-mlv.fr Tue May 1 11:28:35 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 01 May 2012 13:28:35 +0200 Subject: RFR: 7165102 Only run assertion on Integer autoboxing cache size once In-Reply-To: <4F9EB92C.3080406@oracle.com> References: <4F9592ED.3040309@univ-mlv.fr> <4F95EFDC.9090100@gmx.de> <4F96B108.70406@univ-mlv.fr> <4F96C05E.6040001@oracle.com> <4F9A12AA.8000605@oracle.com> <4F9B1FDC.60507@univ-mlv.fr> <4F9EB92C.3080406@oracle.com> Message-ID: <4F9FC8E3.2080908@univ-mlv.fr> Here is the new webrev with the assert move after line 777 as Joe ask. http://cr.openjdk.java.net/~forax/integer_valueof2/ Alan or Joe, it let you commit it if there is no new issue. R?mi On 04/30/2012 06:09 PM, Alan Bateman wrote: > On 27/04/2012 23:38, R?mi Forax wrote: >> : >> I have moved the assert into the static block of IntegerCache. >> For Alan, because IntegerCache is loaded when Integer.valueOf() is >> called the first time >> the assert code is checked around the same time so after the system >> init but only once. >> >> webrev is here: >> http://cr.openjdk.java.net/~forax/integer_valueof/ >> and I need a bug for it :) > Looks fine me as the initialization is now different compared to when > this property was introduced (when introduced the IntegerCache was > initialized via System.initializeSystemClass). On 04/28/2012 01:32 AM, Joseph Darcy wrote: > > Here is your bug: > > 7165102 Only run assertion on Integer autoboxing cache size once > > However, I'd prefer the assert appear right after the > > 777 high = h; > > assignment. > > Cheers, > > -Joe From paul.sandoz at oracle.com Tue May 1 11:37:05 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 1 May 2012 13:37:05 +0200 Subject: RFR: 5015163 "(str) String merge/join that is the inverse of String.split()" into JDK 8 In-Reply-To: <4F9FC09D.80803@univ-mlv.fr> References: <4F9B1C05.1080101@oracle.com> <4F9B2551.9070506@univ-mlv.fr> <4F9FC09D.80803@univ-mlv.fr> Message-ID: <2669F0CE-32B4-4ED4-8A24-59A1BE3DC559@oracle.com> On May 1, 2012, at 12:53 PM, R?mi Forax wrote: > On 04/30/2012 11:03 AM, Paul Sandoz wrote: >> On Apr 28, 2012, at 1:01 AM, R?mi Forax wrote: >> >>> Hi Jim, >>> Yes, I've basically try to submit a patch each time I've written a method join >>> in one of my application :) >>> >>> The funny think (in fact it's even not funny) is that I think that this methods >>> should not be in String anymore. In Java 8, we will have defender methods >>> so you can write join directly on an Iterable. And there is some discussion >>> to also allow defender methods on arrays too, >>> so we may can write a method join on Object[] too >>> (on an interface inherited from Object[] to be precise). >>> >>> I really think that list.join(",") is better than "".join(",", list) and >>> ["foo", "bar"].join(",") is better than "".join(",", ["foo", "bar"]). >>> but maybe I'm wrong. >>> >> Good point. Although i don't see the harm with such methods on String that defer, or are required if say defender methods on arrays never come about. >> >> There are also more general cases of interpose and interleave (see Clojure's functions as an example) since join can be implemented using interpose which can be implemented using interleave. > > Implementing interpose with interleave requires to remove the last element, > which is not so easy in lazy mode. It's easier to implement it directly. > Or the first e.g.: http://clojuredocs.org/clojure_core/clojure.core/interpose (defn interpose "Returns a lazy seq of the elements of coll separated by sep" {:added "1.0" :static true} [sep coll] (drop 1 (interleave (repeat sep) coll))) >> Not saying join should be implemented that way (not so optimal for Strings only) but i think such functions are very useful. I am not tracking the lambda library work very closely, have such functions been considered? > > Yes, we discuss about zip/unzip, and what we call BiStream. > unzip is the other name of interleave. > Would that require the creation of an intermediate object that holds two values? Paul. From forax at univ-mlv.fr Tue May 1 12:40:43 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 01 May 2012 14:40:43 +0200 Subject: RFR: 5015163 "(str) String merge/join that is the inverse of String.split()" into JDK 8 In-Reply-To: <2669F0CE-32B4-4ED4-8A24-59A1BE3DC559@oracle.com> References: <4F9B1C05.1080101@oracle.com> <4F9B2551.9070506@univ-mlv.fr> <4F9FC09D.80803@univ-mlv.fr> <2669F0CE-32B4-4ED4-8A24-59A1BE3DC559@oracle.com> Message-ID: <4F9FD9CB.4050706@univ-mlv.fr> On 05/01/2012 01:37 PM, Paul Sandoz wrote: > > On May 1, 2012, at 12:53 PM, R?mi Forax wrote: > >> On 04/30/2012 11:03 AM, Paul Sandoz wrote: >>> On Apr 28, 2012, at 1:01 AM, R?mi Forax wrote: >>> >>>> Hi Jim, >>>> Yes, I've basically try to submit a patch each time I've written a >>>> method join >>>> in one of my application :) >>>> >>>> The funny think (in fact it's even not funny) is that I think that >>>> this methods >>>> should not be in String anymore. In Java 8, we will have defender >>>> methods >>>> so you can write join directly on an Iterable. And there is some >>>> discussion >>>> to also allow defender methods on arrays too, >>>> so we may can write a method join on Object[] too >>>> (on an interface inherited from Object[] to be precise). >>>> >>>> I really think that list.join(",") is better than "".join(",", >>>> list) and >>>> ["foo", "bar"].join(",") is better than "".join(",", ["foo", "bar"]). >>>> but maybe I'm wrong. >>>> >>> Good point. Although i don't see the harm with such methods on >>> String that defer, or are required if say defender methods on arrays >>> never come about. >>> >>> There are also more general cases of interpose and interleave (see >>> Clojure's functions as an example) since join can be implemented >>> using interpose which can be implemented using interleave. >> >> Implementing interpose with interleave requires to remove the last >> element, >> which is not so easy in lazy mode. It's easier to implement it directly. >> > > Or the first e.g.: > http://clojuredocs.org/clojure_core/clojure.core/interpose > (defn interpose > "Returns a lazy seq of the elements of coll separated by sep" > {:added "1.0" > :static true} > [sep coll] (drop 1 (interleave (repeat sep) coll))) yes, it's better ! > > >>> Not saying join should be implemented that way (not so optimal for >>> Strings only) but i think such functions are very useful. I am not >>> tracking the lambda library work very closely, have such functions >>> been considered? >> >> Yes, we discuss about zip/unzip, and what we call BiStream. >> unzip is the other name of interleave. >> > > Would that require the creation of an intermediate object that holds > two values? or reuse Map.Entry. That are the two reasonable choices. Paul, I think this discussion should be moved to lambda-dev. It will be more fruitful. > > Paul. cheers, R?mi From jim.gish at oracle.com Tue May 1 15:50:50 2012 From: jim.gish at oracle.com (Jim Gish) Date: Tue, 01 May 2012 11:50:50 -0400 Subject: RFR: 5015163 "(str) String merge/join that is the inverse of String.split()" into JDK 8 In-Reply-To: <4F9FC2B7.2080000@univ-mlv.fr> References: <4F9B1C05.1080101@oracle.com> <4F9B2551.9070506@univ-mlv.fr> <4F9EA05E.6020401@oracle.com> <4F9FC2B7.2080000@univ-mlv.fr> Message-ID: <4FA0065A.80002@oracle.com> Thanks - Should I proceed with improvements to String.join() or wait, for example, until the lambda array support is there? Jim On 05/01/2012 07:02 AM, R?mi Forax wrote: > On 04/30/2012 04:23 PM, Jim Gish wrote: >> Thanks R?mi, >> >> I'll take a look at defender methods on Iterable. >> >> As far as the parameter checks on String -- I had the same "Aha!" >> moment as soon as I got in my car to drive home on Friday. > > :) > >> However, it does come down to a philosophy of style in that I'm in >> favor of (1) catching and reporting errors as soon as possible, and >> (2) not depending on the implementation details of other methods >> (particularly other classes) of which I'm a client. > > These checks are part of the spec of the method then part of the > implementation, > that's why I think it's Ok tu use them. > >> On the other hand, given this is "core" I realize that performance >> matters as well as locality of reference, so there is a trade off >> between deferring the check and sharing the static result message >> string. > > The main issue with sharing static strings is that slowdown the > startup of the VM. > The core classes do already too much static initialization for very > little benefit, > by example, loading a string requires to initialize > String.CASE_INSENSITIVE_ORDER > even if this comparator is not actually used. > > BTW, a good project should be to try to remove most of the private > static fields > from the public java.lang classes in order to defer their > initializations. > >> >> Let's see what others think. >> >> As far as transient on the static field -- I also realized as I was >> driving away that statics might not be serialized so transient is >> unnecessary. >> >> Thanks, >> Jim > > cheers, > R?mi > From martijnverburg at gmail.com Tue May 1 16:08:26 2012 From: martijnverburg at gmail.com (Martijn Verburg) Date: Tue, 1 May 2012 17:08:26 +0100 Subject: Proposed refactoring: introduce JLS7 language features to core libs In-Reply-To: References: <7BCF83EB-75F1-46A6-917E-2619974A4545@mac.com> <5FA2ABE2-4272-4F7A-8880-74E426C04346@mac.com> <4F9F41F6.40609@oracle.com> Message-ID: Hi all, On 1 May 2012 10:33, Martijn Verburg wrote: > Hi all, > >> On 4/25/12 12:07 PM, Stefan Reich wrote: >>> >>> Hello, >>> >>> is there any interest to accept change sets based on OpenJDK 7 that update >>> the java classes in jdk/src/share/classes to use >>> >>> * multi-catch >>> * string switch statements as opposed to nested if statements when >>> comparing strings with string literals >>> * type inference by removing duplicative type information in the >>> constructor when using generics >>> * indexOf(int) when indexOf(String) is used with a String literal that >>> contains only one character, and similar small-scale improvements? >>> >>> The proposed change sets would pass all jtreg tests. If there is interest, >>> what would be next steps? >> >> >> Hi, yes, there is interest! Thanks for raising this topic. >> >> In some respects this seems similar to the "Coinification" work [1] I did >> during JDK7 development, that is, to use the then-new Project Coin features >> in the code base of the JDK itself. The goal of that effort was to put some >> of the Coin features to use in production code, so as to gain experience >> with them, but not necessarily to "coinify" the entire source base. In fact >> I've been asked how much of the code base was converted to use the new >> features. The answer is, I don't know. I'm pretty sure that there is a lot >> remaining to be done, though. >> >> (As an aside, most of the warnings work we've been doing over the past >> several months is to clean warnings that result from the use of raw types >> instead of generics. That is, there is lots of code lying around that hasn't >> been updated to Java 5 generics yet! There are similar refactorings one >> could apply for Java 5 language features, such as the enhanced-for loop, >> enums, covariant overrides, autoboxing, etc.) >> >> Probably the easiest feature to get started with is diamond (formally known >> as "type inference for generic instance creation"). It should be fairly >> simple to find lots of examples where this can be put to use, now that there >> are bulk change hints available in NetBeans. (Bulk changes are probably also >> available in Eclipse and IntelliJ Idea.) The good thing about diamond is >> that it is practically impossible to bugs when doing diamond conversion. In >> fact, the resulting class files should be byte-for-byte identical to the >> previous versions. In practice, though, I did join lines where appropriate, >> since using diamond often shortened the code enough to fit on a single line >> where it had to be split across lines before. >> >> There are a small number of stylistic issues that occur when using diamond; >> see [2] and [3]. Different people have different styles, and unfortunately >> different styles have emerged in different areas of code. The main >> difference seems to be whether diamond is used in assignment and return >> statements, where the use of diamond is separated from the variable >> declaration that contains the complete type. >> >> In practice what this means is that you should break down your changesets to >> apply to different functional areas, and then find the right people and the >> right mailing list to discuss the changes beforehand. (Actually this is >> probably good practice for any change, not just diamond.) >> >> Turning to the other suggestions, I'd say that multi-catch and >> strings-in-switch are also fairly safe refactorings to propose, although >> they probably occur much less frequently than diamond. There are some >> subtleties with applying these refactorings, which will require more >> scrutiny than applying diamond changes. >> >> For example, in some cases there is a catch of Exception that is better >> expressed as a multi-catch of several Exception subtypes. This might make >> for better code, but it subtly changes the behavior of the code. For >> strings-in-switch, a null value of the switch expression results in NPE, >> whereas (depending on the details, of course) a cascade of if-elses may end >> up handling null differently. >> >> I'm not sure about the indexOf() cases you refer to. I guess I'd have to see >> some examples before deciding whether these are worthwhile to pursue. >> >> In any case, thanks for taking the initiative to work on this stuff. Looking >> forward to seeing what you come up with. >> >> s'marks >> >> [1] >> http://stuartmarks.wordpress.com/2010/12/23/jdk7-coin-and-making-libraries-fresh-and-minty/ >> [2] http://stuartmarks.wordpress.com/2011/01/24/where-can-diamond-be-used/ >> [3] http://stuartmarks.wordpress.com/2011/04/29/when-should-diamond-be-used/ > > FYI, Stefan has kindly offered to join the Adopt OpenJDK program > (http://java.net/projects/jugs/pages/AdoptOpenJDK) and we'll all work > together of pre-review of patches, with Stuart's comments as a > starting guideline. > > Cheers, > Martijn Further to this I've added a page (http://java.net/projects/jugs/pages/CoinificationOfTheOpenJDK) to cover our efforts in this area. Comments/Questions very welcome. Cheers, Martijn From forax at univ-mlv.fr Tue May 1 17:16:38 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 01 May 2012 19:16:38 +0200 Subject: RFR: 5015163 "(str) String merge/join that is the inverse of String.split()" into JDK 8 In-Reply-To: <4FA0065A.80002@oracle.com> References: <4F9B1C05.1080101@oracle.com> <4F9B2551.9070506@univ-mlv.fr> <4F9EA05E.6020401@oracle.com> <4F9FC2B7.2080000@univ-mlv.fr> <4FA0065A.80002@oracle.com> Message-ID: <4FA01A76.5090904@univ-mlv.fr> On 05/01/2012 05:50 PM, Jim Gish wrote: > Thanks - > > Should I proceed with improvements to String.join() or wait, for > example, until the lambda array support is there? > > Jim better to ask Brian Goetz :) R?mi > > On 05/01/2012 07:02 AM, R?mi Forax wrote: >> On 04/30/2012 04:23 PM, Jim Gish wrote: >>> Thanks R?mi, >>> >>> I'll take a look at defender methods on Iterable. >>> >>> As far as the parameter checks on String -- I had the same "Aha!" >>> moment as soon as I got in my car to drive home on Friday. >> >> :) >> >>> However, it does come down to a philosophy of style in that I'm in >>> favor of (1) catching and reporting errors as soon as possible, and >>> (2) not depending on the implementation details of other methods >>> (particularly other classes) of which I'm a client. >> >> These checks are part of the spec of the method then part of the >> implementation, >> that's why I think it's Ok tu use them. >> >>> On the other hand, given this is "core" I realize that performance >>> matters as well as locality of reference, so there is a trade off >>> between deferring the check and sharing the static result message >>> string. >> >> The main issue with sharing static strings is that slowdown the >> startup of the VM. >> The core classes do already too much static initialization for very >> little benefit, >> by example, loading a string requires to initialize >> String.CASE_INSENSITIVE_ORDER >> even if this comparator is not actually used. >> >> BTW, a good project should be to try to remove most of the private >> static fields >> from the public java.lang classes in order to defer their >> initializations. >> >>> >>> Let's see what others think. >>> >>> As far as transient on the static field -- I also realized as I was >>> driving away that statics might not be serialized so transient is >>> unnecessary. >>> >>> Thanks, >>> Jim >> >> cheers, >> R?mi >> > From xueming.shen at oracle.com Tue May 1 18:06:55 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 01 May 2012 11:06:55 -0700 Subject: Codereview request for 7014640: To add a metachar \R for line ending and character classes for vertical/horizontal ws \v \V \h \H In-Reply-To: <4F92681D.5090608@oracle.com> References: <4F92681D.5090608@oracle.com> Message-ID: <4FA0263F.6040600@oracle.com> Hi, Just noticed that webrev url was pointing to the blenderrev. The webrev is at http://cr.openjdk.java.net/~sherman/7014640/webrev Btw, this one has been approved by CCC. thanks, -Sherman On 04/21/2012 12:56 AM, Xueming Shen wrote: > Hi > > Here are the webrev and blenderrev for the proposed change to add 5 > new regex constructs \R \v \V \h \V. > > \R: recommended by Unicode Regex TR#18 for matching all line ending > characters and sequences, is equivalent to > ( \u000D\u000A | [\u000A\u000B\u000C\u000D\u0085\u2028\u2029] ) > > \h, \v, \H and \V: > matches any character considered to (not) be horizontal/vertical > whitespace. > > Webrev: > http://cr.openjdk.java.net/~sherman/7014640/blenderrev.html > > Blenderrev: > http://cr.openjdk.java.net/~sherman/7014640/blenderrev.html > > new Pattern api > http://cr.openjdk.java.net/~sherman/7014640/Pattern.html > > Here are couple notes regarding the spec/implementation. > > (1) \v was implemented as \u000B ('\013'), but not documented (did not > appear in our API > doc as one supported construct, such as \t \r \n...). To define \v as > a "general" construct for > all vertical whitespace characters might trigger some compatibility > concerns (more characters > are now matched by \v). But given this is a never documented > implementation detail and the > \u000B is still being matched by \v, I would consider this as an > acceptable behavior change. > > (2) a predefined character class can appear inside another character > class, for example > you can have [...\v...], however, since it represents a "class" of > character, so it can't be > a start or end code point of a range inside a class, so you can have > [a-b], but you can't > have [\h-...] or [...-\h] (exception will be thrown). But for \v, > since it was implemented > as \u000B (VT), you were able to put it as a start or end value of a > range, I feel it'd be > better still keep it the way it worked before, so [\v-\v] works and > will match the VT in > this implementation. > > (3) The newly added \h\v\H\V constructs are all "Unicode version" of > character classes, the > rest of the "predefined character class" family (\d\D\s\S\w\W) are > ASCII only, you will have to > turn on flag UNICODE_CHARACTER_CLASS to get the Unicode version of > these constructs. This > is kinda of inconsistent. Perl's corresponding constructs work in a > similar way, all Perl's \d\D\s\S > \w\W\v\V\h\H work in Unicode version, and to have a \a modifier to > turn the \d\D\s\S\w\W > back to ASCII mode but not for \h\v\H\V. We had the discussion back > into JDK7 regarding the > ASCII vs Unicode for these constructs, the decision then was to keep > these predefined character > classes (and POSIX character classes) ASCII by default, to have a flag > UNICODE_CHARACTER_CLASS > to turn them into Unicode version. Given there is NOT an ASCII version > in Perl and we didn't > have ASCII version in Java regex to trigger compatibility concern, I > feel it might be better to > just have a simple Unicode version of \h\v\H\V. > > (4)\R is not a character class, since it matched \r\n. > > This one will need to go through ccc process. > > Thanks, > -Sherman From sreich at mac.com Tue May 1 18:23:27 2012 From: sreich at mac.com (Stefan Reich) Date: Tue, 01 May 2012 11:23:27 -0700 Subject: Proposed refactoring: introduce JLS7 language features to core libs In-Reply-To: <4F9F41F6.40609@oracle.com> References: <7BCF83EB-75F1-46A6-917E-2619974A4545@mac.com> <5FA2ABE2-4272-4F7A-8880-74E426C04346@mac.com> <4F9F41F6.40609@oracle.com> Message-ID: <9591BB2C-260A-4C23-A2F9-72BA4A297664@mac.com> Hi Stuart, thank you for your reply. I sent a patch to the adopt-openjdk group that uses multi-catch for catch clauses with duplicate code blocks in the same try statement (message and patch attached). That patch covers all code in src/shared/classes. Martijn will help coordinating the effort with all individual component owners, since I don't know anyone over at the OpenJDK team. The string switch conversion is relatively straight forward, too. The more complicated case that you mention: String s; if("literal1".equals(s)) { } else if("literal2".equals(s)) { } else { // s is null or some other value } is very rare in the OpenJDK code base. I saw only a handful of occurrences out of 95 files affected by this refactoring (in src/share/classes). If there is interest, I'd review the changes and create a patch, but I wanted to see how things are going with my first submission before investing more time. How far are you with type inference? Are you going to write a NetBeans plugin? Stefan -------------- next part -------------- An embedded message was scrubbed... From: Stefan Reich Subject: Refactoring OpenJDK to leverage multi-catch statements Date: Sat, 28 Apr 2012 16:09:12 -0700 Size: 6549 URL: -------------- next part -------------- On Apr 30, 2012, at 6:52 PM, Stuart Marks wrote: > On 4/25/12 12:07 PM, Stefan Reich wrote: >> Hello, >> >> is there any interest to accept change sets based on OpenJDK 7 that update the java classes in jdk/src/share/classes to use >> >> * multi-catch >> * string switch statements as opposed to nested if statements when comparing strings with string literals >> * type inference by removing duplicative type information in the constructor when using generics >> * indexOf(int) when indexOf(String) is used with a String literal that contains only one character, and similar small-scale improvements? >> >> The proposed change sets would pass all jtreg tests. If there is interest, what would be next steps? > > Hi, yes, there is interest! Thanks for raising this topic. > > In some respects this seems similar to the "Coinification" work [1] I did during JDK7 development, that is, to use the then-new Project Coin features in the code base of the JDK itself. The goal of that effort was to put some of the Coin features to use in production code, so as to gain experience with them, but not necessarily to "coinify" the entire source base. In fact I've been asked how much of the code base was converted to use the new features. The answer is, I don't know. I'm pretty sure that there is a lot remaining to be done, though. > > (As an aside, most of the warnings work we've been doing over the past several months is to clean warnings that result from the use of raw types instead of generics. That is, there is lots of code lying around that hasn't been updated to Java 5 generics yet! There are similar refactorings one could apply for Java 5 language features, such as the enhanced-for loop, enums, covariant overrides, autoboxing, etc.) > > Probably the easiest feature to get started with is diamond (formally known as "type inference for generic instance creation"). It should be fairly simple to find lots of examples where this can be put to use, now that there are bulk change hints available in NetBeans. (Bulk changes are probably also available in Eclipse and IntelliJ Idea.) The good thing about diamond is that it is practically impossible to bugs when doing diamond conversion. In fact, the resulting class files should be byte-for-byte identical to the previous versions. In practice, though, I did join lines where appropriate, since using diamond often shortened the code enough to fit on a single line where it had to be split across lines before. > > There are a small number of stylistic issues that occur when using diamond; see [2] and [3]. Different people have different styles, and unfortunately different styles have emerged in different areas of code. The main difference seems to be whether diamond is used in assignment and return statements, where the use of diamond is separated from the variable declaration that contains the complete type. > > In practice what this means is that you should break down your changesets to apply to different functional areas, and then find the right people and the right mailing list to discuss the changes beforehand. (Actually this is probably good practice for any change, not just diamond.) > > Turning to the other suggestions, I'd say that multi-catch and strings-in-switch are also fairly safe refactorings to propose, although they probably occur much less frequently than diamond. There are some subtleties with applying these refactorings, which will require more scrutiny than applying diamond changes. > > For example, in some cases there is a catch of Exception that is better expressed as a multi-catch of several Exception subtypes. This might make for better code, but it subtly changes the behavior of the code. For strings-in-switch, a null value of the switch expression results in NPE, whereas (depending on the details, of course) a cascade of if-elses may end up handling null differently. > > I'm not sure about the indexOf() cases you refer to. I guess I'd have to see some examples before deciding whether these are worthwhile to pursue. > > In any case, thanks for taking the initiative to work on this stuff. Looking forward to seeing what you come up with. > > s'marks > > > > [1] http://stuartmarks.wordpress.com/2010/12/23/jdk7-coin-and-making-libraries-fresh-and-minty/ > > [2] http://stuartmarks.wordpress.com/2011/01/24/where-can-diamond-be-used/ > > [3] http://stuartmarks.wordpress.com/2011/04/29/when-should-diamond-be-used/ > > From lana.steuck at oracle.com Tue May 1 18:44:05 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 01 May 2012 18:44:05 +0000 Subject: hg: jdk8/tl: Added tag jdk8-b36 for changeset 6a6ba0a07f33 Message-ID: <20120501184406.02FD6470BA@hg.openjdk.java.net> Changeset: 47aa0ddc9126 Author: katleman Date: 2012-04-26 14:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/47aa0ddc9126 Added tag jdk8-b36 for changeset 6a6ba0a07f33 ! .hgtags From lana.steuck at oracle.com Tue May 1 18:44:07 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 01 May 2012 18:44:07 +0000 Subject: hg: jdk8/tl/corba: 2 new changesets Message-ID: <20120501184410.489D0470BB@hg.openjdk.java.net> Changeset: 83fac66442cf Author: katleman Date: 2012-04-26 14:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/83fac66442cf Added tag jdk8-b36 for changeset a5a61f259961 ! .hgtags Changeset: 4a653e435441 Author: lana Date: 2012-05-01 11:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/4a653e435441 Merge From lana.steuck at oracle.com Tue May 1 18:44:09 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 01 May 2012 18:44:09 +0000 Subject: hg: jdk8/tl/jaxws: Added tag jdk8-b36 for changeset 89b36c658e39 Message-ID: <20120501184414.AD2B9470BC@hg.openjdk.java.net> Changeset: b05a948db1b6 Author: katleman Date: 2012-04-26 14:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/b05a948db1b6 Added tag jdk8-b36 for changeset 89b36c658e39 ! .hgtags From lana.steuck at oracle.com Tue May 1 18:44:10 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 01 May 2012 18:44:10 +0000 Subject: hg: jdk8/tl/hotspot: Added tag jdk8-b36 for changeset 50b4400ca1ec Message-ID: <20120501184416.9C575470BD@hg.openjdk.java.net> Changeset: bfcf92bfefb8 Author: katleman Date: 2012-04-26 14:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bfcf92bfefb8 Added tag jdk8-b36 for changeset 50b4400ca1ec ! .hgtags From lana.steuck at oracle.com Tue May 1 18:44:11 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 01 May 2012 18:44:11 +0000 Subject: hg: jdk8/tl/jaxp: Added tag jdk8-b36 for changeset cfd288fe1d3e Message-ID: <20120501184416.9FA7C470BE@hg.openjdk.java.net> Changeset: c388369cf4da Author: katleman Date: 2012-04-26 14:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/c388369cf4da Added tag jdk8-b36 for changeset cfd288fe1d3e ! .hgtags From lana.steuck at oracle.com Tue May 1 18:44:14 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 01 May 2012 18:44:14 +0000 Subject: hg: jdk8/tl/langtools: Added tag jdk8-b36 for changeset 94bbaa67686f Message-ID: <20120501184417.45665470C1@hg.openjdk.java.net> Changeset: 5891b38985e8 Author: katleman Date: 2012-04-26 14:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/5891b38985e8 Added tag jdk8-b36 for changeset 94bbaa67686f ! .hgtags From lana.steuck at oracle.com Tue May 1 18:44:17 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 01 May 2012 18:44:17 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20120501184444.65216470C2@hg.openjdk.java.net> Changeset: 9e82ac15ab80 Author: katleman Date: 2012-04-26 14:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9e82ac15ab80 Added tag jdk8-b36 for changeset 45da9cb055ee ! .hgtags Changeset: 6c9c3d7ce9e2 Author: lana Date: 2012-05-01 11:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6c9c3d7ce9e2 Merge From kurchi.subhra.hazra at oracle.com Tue May 1 19:01:37 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Tue, 01 May 2012 12:01:37 -0700 Subject: Code Review Request: 7165118: (prefs) AbstractPreferences.remove(null) does not throw NPE Message-ID: <4FA03311.1070907@oracle.com> Hi, This is a simple fix to enable AbstractPreferences.remove() to check for a null argument and throw a NullPointerException if required. I have also modified test/java/util/prefs/RemoveNullKeyCheck.java to cover this case. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7165118 Webrev: http://cr.openjdk.java.net/~khazra/7165118/webrev.00/ Thanks, Kurchi From golovnin at gmx.net Tue May 1 19:33:52 2012 From: golovnin at gmx.net (Andrej Golovnin) Date: Tue, 1 May 2012 21:33:52 +0200 Subject: [PATCH] Use #valueOf()-methods in Unsafe-based FieldAccessors Message-ID: Hi all, Is there some reason for not using #valueOf-methods from wrapper classes in Unsafe-based FieldAccessors in sun.reflect-package (see the attached patch)? The main motivation for this patch is to reduce memory consumption in applications which make heavy use of reflection API (e.g. apps which use ORM solutions). The patch does not modify Unsafe-based FieldAccessors for double and float fields as the wrapper classes does not provide caching for fields of this types. Best regards Andrej Golovnin From forax at univ-mlv.fr Tue May 1 21:54:43 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 01 May 2012 23:54:43 +0200 Subject: [PATCH] Use #valueOf()-methods in Unsafe-based FieldAccessors In-Reply-To: References: Message-ID: <4FA05BA3.1000707@univ-mlv.fr> On 05/01/2012 09:33 PM, Andrej Golovnin wrote: > Hi all, Hi Andrej, your far from Swing :) (I remember you from the glorious appframework time) > > Is there some reason for not using #valueOf-methods from wrapper classes > in Unsafe-based FieldAccessors in sun.reflect-package (see the attached patch)? The main reason, I think, is that these code was written during 1.4 time frame and not updated for 1.5. And the mailer deamon (or mailer imp ?) remove attachment, so you have to repost it inlined. > > The main motivation for this patch is to reduce memory consumption in applications > which make heavy use of reflection API (e.g. apps which use ORM solutions). and your ORM doesn't use neither field.getInt() (and variants) instead of field.get() nor do bytecode enhancement ? Also, because currently the escape analysis done by Hotspot is a little bit broken you may introduce a slowdown/more memory consumption because the JIT may be able to remove new Integer()/Integer.intValue() pair but not Integer.valueOf()/Integer.intValue() pair. But I know that someone is working on this :) > > The patch does not modify Unsafe-based FieldAccessors for double and float > fields as the wrapper classes does not provide caching for fields of this types. > > Best regards > Andrej Golovnin > regards, R?mi From mandy.chung at oracle.com Wed May 2 02:47:40 2012 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 02 May 2012 02:47:40 +0000 Subject: hg: jdk8/tl/jdk: 7164376: Replace use of sun.security.action.LoadLibraryAction with System.loadLibrary Message-ID: <20120502024757.A5CE9470D8@hg.openjdk.java.net> Changeset: 46e0bd218fcc Author: mchung Date: 2012-05-01 19:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/46e0bd218fcc 7164376: Replace use of sun.security.action.LoadLibraryAction with System.loadLibrary Reviewed-by: alanb, mullan, prr ! src/macosx/classes/apple/launcher/JavaAppLauncher.java ! src/macosx/classes/apple/security/KeychainStore.java ! src/macosx/classes/com/apple/concurrent/LibDispatchNative.java ! src/macosx/classes/com/apple/eawt/Application.java ! src/macosx/classes/com/apple/eio/FileManager.java ! src/macosx/classes/com/apple/laf/AquaFileView.java ! src/macosx/classes/com/apple/laf/AquaLookAndFeel.java ! src/macosx/classes/com/apple/laf/AquaNativeResources.java ! src/macosx/classes/com/apple/laf/ScreenMenu.java ! src/macosx/classes/com/apple/laf/ScreenPopupFactory.java ! src/macosx/classes/java/util/prefs/MacOSXPreferencesFile.java ! src/macosx/classes/sun/awt/CGraphicsEnvironment.java ! src/macosx/classes/sun/lwawt/macosx/CAccessibility.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageWriter.java ! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java ! src/share/classes/java/awt/SplashScreen.java ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/java/awt/event/NativeLibLoader.java ! src/share/classes/java/awt/image/ColorModel.java ! src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java ! src/share/classes/java/net/AbstractPlainSocketImpl.java ! src/share/classes/java/net/DatagramPacket.java ! src/share/classes/java/net/InetAddress.java ! src/share/classes/java/net/NetworkInterface.java ! src/share/classes/sun/awt/NativeLibLoader.java ! src/share/classes/sun/awt/image/JPEGImageDecoder.java ! src/share/classes/sun/awt/image/NativeLibLoader.java ! src/share/classes/sun/java2d/Disposer.java ! src/share/classes/sun/management/ManagementFactoryHelper.java ! src/share/classes/sun/net/sdp/SdpSupport.java ! src/share/classes/sun/net/spi/DefaultProxySelector.java ! src/share/classes/sun/nio/ch/Util.java - src/share/classes/sun/security/action/LoadLibraryAction.java ! src/share/classes/sun/security/krb5/SCDynamicStoreConfig.java ! src/share/classes/sun/security/smartcardio/PCSC.java ! src/share/classes/sun/tracing/dtrace/JVM.java ! src/solaris/classes/sun/management/FileSystemImpl.java ! src/solaris/classes/sun/net/dns/ResolverConfigurationImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java ! src/solaris/classes/sun/print/CUPSPrinter.java ! src/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java ! src/windows/classes/sun/awt/windows/WToolkit.java ! src/windows/classes/sun/management/FileSystemImpl.java ! src/windows/classes/sun/net/dns/ResolverConfigurationImpl.java ! src/windows/classes/sun/print/Win32PrintServiceLookup.java ! src/windows/classes/sun/security/smartcardio/PlatformPCSC.java From david.holmes at oracle.com Wed May 2 03:54:03 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 02 May 2012 13:54:03 +1000 Subject: Code Review Request: 7165118: (prefs) AbstractPreferences.remove(null) does not throw NPE In-Reply-To: <4FA03311.1070907@oracle.com> References: <4FA03311.1070907@oracle.com> Message-ID: <4FA0AFDB.4040004@oracle.com> Hi Kurchi, You should also add: @throws NullPointerException {@inheritDoc} to the method spec so that the docs re-instate the fact that it is supposed to throw NPE. As it stands I could argue that AbstractPreferences.remove has chosen not to throw NPE for a null key - leaving it up to removeSpi to do that if needed. CCC may be needed for this. David On 2/05/2012 5:01 AM, Kurchi Hazra wrote: > Hi, > > This is a simple fix to enable AbstractPreferences.remove() to check for > a null argument and > throw a NullPointerException if required. > I have also modified test/java/util/prefs/RemoveNullKeyCheck.java to > cover this case. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7165118 > Webrev: http://cr.openjdk.java.net/~khazra/7165118/webrev.00/ > > Thanks, > Kurchi From stuart.marks at oracle.com Wed May 2 06:39:22 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 01 May 2012 23:39:22 -0700 Subject: RFR: 5015163 "(str) String merge/join that is the inverse of String.split()" into JDK 8 In-Reply-To: <4FA01A76.5090904@univ-mlv.fr> References: <4F9B1C05.1080101@oracle.com> <4F9B2551.9070506@univ-mlv.fr> <4F9EA05E.6020401@oracle.com> <4F9FC2B7.2080000@univ-mlv.fr> <4FA0065A.80002@oracle.com> <4FA01A76.5090904@univ-mlv.fr> Message-ID: <4FA0D69A.9030302@oracle.com> On 5/1/12 10:16 AM, R?mi Forax wrote: > On 05/01/2012 05:50 PM, Jim Gish wrote: >> Should I proceed with improvements to String.join() or wait, for example, >> until the lambda array support is there? > > better to ask Brian Goetz :) Hi guys, this came back around to me internally to Oracle since I've been kicking around some similar ideas in the context of lambda, though nothing has made it to the lambda repos yet. Unfortunately, while I don't think there is a direct dependency of String.join on any of the lambda stuff, we will probably want to coordinate the creation of these APIs. We don't want to put stuff into the mainline now, and then pull it out or retrofit it when the lambda stuff gets integrated later. So, strange as it may seem, it may be better to work on this in the lambda forest. It's not clear to me that we have to move the discussion over to lambda-dev though. This is at least as much about libraries as it is about lambda. (For those watching at home, the background regarding how this relates to lambda is described in [1] with some discussion starting at [2]. In a nutshell, the "lambdafied" libraries approach we're taking is to use lambda expressions to operate on streams of values. Right now streams look like Iterables but this is going to change. We want to be able to join streams of stringy things as well as arrays and collections.) It's fun to think about how joining would work in a lambda/streamy kind of world, e.g. stream.infix(",").join(new StringBuilder()).toString() or some such. There are a bunch of issues to consider here though, such as special-casing of types in the input stream, e.g., append CharSequence directly instead of calling toString(), treat int value as a Unicode code point, etc. There are also issues about the result type: StringBuilder? String? Appendable? As much as I like the lambda stuff, though, I don't think having stream-based joining will supplant the need to have a good old-fashioned String.join(",", ...bunch of strings...) s'marks [1] http://cr.openjdk.java.net/~briangoetz/lambda/collections-overview.html [2] http://mail.openjdk.java.net/pipermail/lambda-dev/2012-April/004758.html From zhouyx at linux.vnet.ibm.com Wed May 2 08:01:45 2012 From: zhouyx at linux.vnet.ibm.com (Sean Chou) Date: Wed, 2 May 2012 16:01:45 +0800 Subject: Request for review: updated 2 files to use generic type Message-ID: Hi all, I updated 2 files(src/share/classes/sun/font/StrikeCache.java, src/share/classes/sun/java2d/Disposer.java) to use generic type, but I'm not sure if I modified too much. Especially I changed the return type of Disposer.getQueue from ReferenceQueue to ReferenceQueue . The webrev is: http://cr.openjdk.java.net/~zhouyx/OJDK-389/webrev.00/ Please take a look. -- Best Regards, Sean Chou From Alan.Bateman at oracle.com Wed May 2 08:30:09 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 02 May 2012 09:30:09 +0100 Subject: Request for review: updated 2 files to use generic type In-Reply-To: References: Message-ID: <4FA0F091.7040808@oracle.com> On 02/05/2012 09:01, Sean Chou wrote: > Hi all, > > I updated 2 files(src/share/classes/sun/font/StrikeCache.java, > src/share/classes/sun/java2d/Disposer.java) to use generic type, but I'm > not sure if I modified too much. Especially I changed the return type of > Disposer.getQueue from ReferenceQueue to ReferenceQueue . > > > The webrev is: http://cr.openjdk.java.net/~zhouyx/OJDK-389/webrev.00/ > > Please take a look. > Sean - I think it would be better to bring this to 2d-dev. -Alan. From Alan.Bateman at oracle.com Wed May 2 09:33:23 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 02 May 2012 10:33:23 +0100 Subject: Codereview request for 7014640: To add a metachar \R for line ending and character classes for vertical/horizontal ws \v \V \h \H In-Reply-To: <4FA0263F.6040600@oracle.com> References: <4F92681D.5090608@oracle.com> <4FA0263F.6040600@oracle.com> Message-ID: <4FA0FF63.8060704@oracle.com> On 01/05/2012 19:06, Xueming Shen wrote: > Hi, > > Just noticed that webrev url was pointing to the blenderrev. The > webrev is at > > http://cr.openjdk.java.net/~sherman/7014640/webrev > I went through the webrev and don't see any issues. The slight behavior change with the previously undocumented \v seems reasonable for a major release. Also thanks for sorting out the issue with the IAE test that came up after 7067045 was pushed. -Alan. From david.holmes at oracle.com Wed May 2 09:41:48 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 02 May 2012 19:41:48 +1000 Subject: Request for review: updated 2 files to use generic type In-Reply-To: <4FA0F091.7040808@oracle.com> References: <4FA0F091.7040808@oracle.com> Message-ID: <4FA1015C.4010700@oracle.com> On 2/05/2012 6:30 PM, Alan Bateman wrote: > On 02/05/2012 09:01, Sean Chou wrote: >> Hi all, >> >> I updated 2 files(src/share/classes/sun/font/StrikeCache.java, >> src/share/classes/sun/java2d/Disposer.java) to use generic type, but I'm >> not sure if I modified too much. Especially I changed the return type of >> Disposer.getQueue from ReferenceQueue to ReferenceQueue . >> >> >> The webrev is: http://cr.openjdk.java.net/~zhouyx/OJDK-389/webrev.00/ >> >> Please take a look. >> > Sean - I think it would be better to bring this to 2d-dev. I second that. The signature changes will require additional approvals. The basic rawtype removals might also be targetted on one of the cleanup days. Also diamond <> should be used where applicable. David > -Alan. From chris.hegarty at oracle.com Wed May 2 09:53:16 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 02 May 2012 10:53:16 +0100 Subject: Code Review Request: 7165118: (prefs) AbstractPreferences.remove(null) does not throw NPE In-Reply-To: <4FA0AFDB.4040004@oracle.com> References: <4FA03311.1070907@oracle.com> <4FA0AFDB.4040004@oracle.com> Message-ID: <4FA1040C.4030509@oracle.com> On 02/05/2012 04:54, David Holmes wrote: > Hi Kurchi, > > You should also add: > > @throws NullPointerException {@inheritDoc} Right, it would be best to clarify this in the AbstractPreferences specification, similar to the other putXXX, getXXX methods. > to the method spec so that the docs re-instate the fact that it is > supposed to throw NPE. As it stands I could argue that > AbstractPreferences.remove has chosen not to throw NPE for a null key - > leaving it up to removeSpi to do that if needed. > > CCC may be needed for this. Yes, we should track this minor spec clarification (to document existing behavior). If we have agreement on list, then we can take this offline and complete the paper work ;-) Oh, nice to see a test added for this too. -Chris. > > David > > > On 2/05/2012 5:01 AM, Kurchi Hazra wrote: >> Hi, >> >> This is a simple fix to enable AbstractPreferences.remove() to check for >> a null argument and >> throw a NullPointerException if required. >> I have also modified test/java/util/prefs/RemoveNullKeyCheck.java to >> cover this case. >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7165118 >> Webrev: http://cr.openjdk.java.net/~khazra/7165118/webrev.00/ >> >> Thanks, >> Kurchi From david.holmes at oracle.com Wed May 2 09:55:26 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 02 May 2012 19:55:26 +1000 Subject: Code Review Request: 7165118: (prefs) AbstractPreferences.remove(null) does not throw NPE In-Reply-To: <4FA1040C.4030509@oracle.com> References: <4FA03311.1070907@oracle.com> <4FA0AFDB.4040004@oracle.com> <4FA1040C.4030509@oracle.com> Message-ID: <4FA1048E.8060901@oracle.com> On 2/05/2012 7:53 PM, Chris Hegarty wrote: > On 02/05/2012 04:54, David Holmes wrote: >> Hi Kurchi, >> >> You should also add: >> >> @throws NullPointerException {@inheritDoc} > > Right, it would be best to clarify this in the AbstractPreferences > specification, similar to the other putXXX, getXXX methods. > >> to the method spec so that the docs re-instate the fact that it is >> supposed to throw NPE. As it stands I could argue that >> AbstractPreferences.remove has chosen not to throw NPE for a null key - >> leaving it up to removeSpi to do that if needed. >> >> CCC may be needed for this. > > Yes, we should track this minor spec clarification (to document existing > behavior). If we have agreement on list, then we can take this offline > and complete the paper work ;-) It's not actually documenting existing behaviour as currently we don't throw the NPE. The assumption is that we should have been throwing the NPE. So this is a spec and behaviour change. David > Oh, nice to see a test added for this too. > > -Chris. > >> >> David >> >> >> On 2/05/2012 5:01 AM, Kurchi Hazra wrote: >>> Hi, >>> >>> This is a simple fix to enable AbstractPreferences.remove() to check for >>> a null argument and >>> throw a NullPointerException if required. >>> I have also modified test/java/util/prefs/RemoveNullKeyCheck.java to >>> cover this case. >>> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7165118 >>> Webrev: http://cr.openjdk.java.net/~khazra/7165118/webrev.00/ >>> >>> Thanks, >>> Kurchi From Alan.Bateman at oracle.com Wed May 2 09:55:53 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 02 May 2012 10:55:53 +0100 Subject: Code Review Request: 7165118: (prefs) AbstractPreferences.remove(null) does not throw NPE In-Reply-To: <4FA0AFDB.4040004@oracle.com> References: <4FA03311.1070907@oracle.com> <4FA0AFDB.4040004@oracle.com> Message-ID: <4FA104A9.3080403@oracle.com> On 02/05/2012 04:54, David Holmes wrote: > Hi Kurchi, > > You should also add: > > @throws NullPointerException {@inheritDoc} > > to the method spec so that the docs re-instate the fact that it is > supposed to throw NPE. As it stands I could argue that > AbstractPreferences.remove has chosen not to throw NPE for a null key > - leaving it up to removeSpi to do that if needed. I think it would be an error to delegate null to the SPI method as it specified to guarantee that the key is non-null. So as AbstractPreferences is providing a default implementation of remove(String) then I think it should do the null check as proposed and it's javadoc should make it clear that NPE can be thrown (so I agree we should add @throws NullPointerException). -Alan. From chris.hegarty at oracle.com Wed May 2 09:57:24 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 02 May 2012 10:57:24 +0100 Subject: Code Review Request: 7165118: (prefs) AbstractPreferences.remove(null) does not throw NPE In-Reply-To: <4FA1048E.8060901@oracle.com> References: <4FA03311.1070907@oracle.com> <4FA0AFDB.4040004@oracle.com> <4FA1040C.4030509@oracle.com> <4FA1048E.8060901@oracle.com> Message-ID: <4FA10504.5070405@oracle.com> On 02/05/2012 10:55, David Holmes wrote: > On 2/05/2012 7:53 PM, Chris Hegarty wrote: >> On 02/05/2012 04:54, David Holmes wrote: >>> Hi Kurchi, >>> >>> You should also add: >>> >>> @throws NullPointerException {@inheritDoc} >> >> Right, it would be best to clarify this in the AbstractPreferences >> specification, similar to the other putXXX, getXXX methods. >> >>> to the method spec so that the docs re-instate the fact that it is >>> supposed to throw NPE. As it stands I could argue that >>> AbstractPreferences.remove has chosen not to throw NPE for a null key - >>> leaving it up to removeSpi to do that if needed. >>> >>> CCC may be needed for this. >> >> Yes, we should track this minor spec clarification (to document existing >> behavior). If we have agreement on list, then we can take this offline >> and complete the paper work ;-) > > It's not actually documenting existing behaviour as currently we don't > throw the NPE. The assumption is that we should have been throwing the > NPE. So this is a spec and behaviour change. D'oh, sorry obviously you're right. Somehow I overlooked most important line of this change! Anyway, you are right we should update the docs. -Chris. > > David > >> Oh, nice to see a test added for this too. >> >> -Chris. >> >>> >>> David >>> >>> >>> On 2/05/2012 5:01 AM, Kurchi Hazra wrote: >>>> Hi, >>>> >>>> This is a simple fix to enable AbstractPreferences.remove() to check >>>> for >>>> a null argument and >>>> throw a NullPointerException if required. >>>> I have also modified test/java/util/prefs/RemoveNullKeyCheck.java to >>>> cover this case. >>>> >>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7165118 >>>> Webrev: http://cr.openjdk.java.net/~khazra/7165118/webrev.00/ >>>> >>>> Thanks, >>>> Kurchi From forax at univ-mlv.fr Wed May 2 10:32:49 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 02 May 2012 12:32:49 +0200 Subject: Request for review: updated 2 files to use generic type In-Reply-To: <4FA1015C.4010700@oracle.com> References: <4FA0F091.7040808@oracle.com> <4FA1015C.4010700@oracle.com> Message-ID: <4FA10D51.40102@univ-mlv.fr> On 05/02/2012 11:41 AM, David Holmes wrote: > On 2/05/2012 6:30 PM, Alan Bateman wrote: >> On 02/05/2012 09:01, Sean Chou wrote: >>> Hi all, >>> >>> I updated 2 files(src/share/classes/sun/font/StrikeCache.java, >>> src/share/classes/sun/java2d/Disposer.java) to use generic type, but >>> I'm >>> not sure if I modified too much. Especially I changed the return >>> type of >>> Disposer.getQueue from ReferenceQueue to ReferenceQueue . >>> >>> >>> The webrev is: http://cr.openjdk.java.net/~zhouyx/OJDK-389/webrev.00/ >>> >>> Please take a look. >>> >> Sean - I think it would be better to bring this to 2d-dev. > > I second that. The signature changes will require additional > approvals. The basic rawtype removals might also be targetted on one > of the cleanup days. > > Also diamond <> should be used where applicable. ReferenceQueue is Ok for me given that the singleton Disposer is used for many different objects, but I've trouble to understand why the Disposer doesn't manage it's own queue. Also there also a bunch (almost all) of static fields that should be static final. > > David > >> -Alan. R?mi From vincent.x.ryan at oracle.com Wed May 2 13:51:19 2012 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Wed, 02 May 2012 13:51:19 +0000 Subject: hg: jdk8/tl/jdk: 7087021: TEST: com/sun/crypto/provider/Mac/MacClone.java failed on Solaris sparc 5.10 Message-ID: <20120502135137.7263B470E8@hg.openjdk.java.net> Changeset: d78c6095dc98 Author: vinnie Date: 2012-05-02 14:50 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d78c6095dc98 7087021: TEST: com/sun/crypto/provider/Mac/MacClone.java failed on Solaris sparc 5.10 Reviewed-by: mullan ! test/com/sun/crypto/provider/Mac/MacClone.java From kurchi.subhra.hazra at oracle.com Wed May 2 17:47:14 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Wed, 02 May 2012 10:47:14 -0700 Subject: Code Review Request: 7165118: (prefs) AbstractPreferences.remove(null) does not throw NPE In-Reply-To: <4FA10504.5070405@oracle.com> References: <4FA03311.1070907@oracle.com> <4FA0AFDB.4040004@oracle.com> <4FA1040C.4030509@oracle.com> <4FA1048E.8060901@oracle.com> <4FA10504.5070405@oracle.com> Message-ID: <4FA17322.905@oracle.com> Thanks all for the review. A webrev with the doc change: http://cr.openjdk.java.net/~khazra/7165118/webrev.01/ I will go ahead and file a CCC for this. Thanks, Kurchi On 5/2/2012 2:57 AM, Chris Hegarty wrote: > > > On 02/05/2012 10:55, David Holmes wrote: >> On 2/05/2012 7:53 PM, Chris Hegarty wrote: >>> On 02/05/2012 04:54, David Holmes wrote: >>>> Hi Kurchi, >>>> >>>> You should also add: >>>> >>>> @throws NullPointerException {@inheritDoc} >>> >>> Right, it would be best to clarify this in the AbstractPreferences >>> specification, similar to the other putXXX, getXXX methods. >>> >>>> to the method spec so that the docs re-instate the fact that it is >>>> supposed to throw NPE. As it stands I could argue that >>>> AbstractPreferences.remove has chosen not to throw NPE for a null >>>> key - >>>> leaving it up to removeSpi to do that if needed. >>>> >>>> CCC may be needed for this. >>> >>> Yes, we should track this minor spec clarification (to document >>> existing >>> behavior). If we have agreement on list, then we can take this offline >>> and complete the paper work ;-) >> >> It's not actually documenting existing behaviour as currently we don't >> throw the NPE. The assumption is that we should have been throwing the >> NPE. So this is a spec and behaviour change. > > D'oh, sorry obviously you're right. Somehow I overlooked most > important line of this change! Anyway, you are right we should update > the docs. > > -Chris. > >> >> David >> >>> Oh, nice to see a test added for this too. >>> >>> -Chris. >>> >>>> >>>> David >>>> >>>> >>>> On 2/05/2012 5:01 AM, Kurchi Hazra wrote: >>>>> Hi, >>>>> >>>>> This is a simple fix to enable AbstractPreferences.remove() to check >>>>> for >>>>> a null argument and >>>>> throw a NullPointerException if required. >>>>> I have also modified test/java/util/prefs/RemoveNullKeyCheck.java to >>>>> cover this case. >>>>> >>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7165118 >>>>> Webrev: http://cr.openjdk.java.net/~khazra/7165118/webrev.00/ >>>>> >>>>> Thanks, >>>>> Kurchi -- -Kurchi From mandy.chung at oracle.com Wed May 2 18:30:30 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 02 May 2012 11:30:30 -0700 Subject: Review Request: 7164376 Replace use of sun.security.action.LoadLibraryAction In-Reply-To: <4FA1783C.7030809@oracle.com> References: <4F9998CF.9000308@oracle.com> <4FA1783C.7030809@oracle.com> Message-ID: <4FA17D46.1070805@oracle.com> On 5/2/2012 11:09 AM, Artem Ananiev wrote: > Hi, Mandy, > > the client part of the fix looks fine. Thanks for the review. I have pushed the changeset and hope you don't mind I couldn't fix the changeset comment to add you as a reviewer. > Let me ask a naive question, though. > > From your explanation, I see that System.loadLibrary() is now aware of > modules. What prevents us to change LoadLibraryAction the same way? > "FROM" code looks much more elegant than the new (the old?) "TO" one. > I would say the old code is little compact than the new one and both versions look elegant to me. The fix here is to get the caller of System.loadLibrary be in the same class loader as the native library being loaded (see ClassLoader.findLibrary). Another alternative is that each component can have its own copy of LoadLibraryAction (e.g. sun.awt.LoadLibraryAction) and so you can modify the old code like this: java.security.AccessController.doPrivileged(new sun.awt.LoadLibraryAction("awt")); provided that sun.awt.LoadLibraryAction is loaded by the same class loader with whom awt.dll is associated. Adding one copy of this simple LoadLibraryAction utility class for each component seems overkill and also error-prone e.g. refactoring a module into two modules require adding another copy of this per-module utility class if both have native libraries. This is certainly an option if the component team prefers to use the utility class. Mandy > Thanks, > > Artem > > On 4/26/2012 10:49 PM, Mandy Chung wrote: >> 7164376 Replace use of sun.security.action.LoadLibraryAction >> with direct call of System.loadLibrary >> >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7164376/webrev.00/ >> >> This change is required for jdk modularization. High level summary: >> it replaces the use of LoadLibraryAction: >> >> FROM: >> java.security.AccessController.doPrivileged(new >> LoadLibraryAction("net")); >> >> TO: >> AccessController.doPrivileged( >> new java.security.PrivilegedAction() { >> public Void run() { >> System.loadLibrary("net"); >> return null; >> } >> }); >> >> It touches files in awt, security and serviceability area (cc'ed). >> For this type of simple change, I think 1-2 reviewers can >> review all files (simpler to review jdk.patch) and no need >> for all teams to do the reviews. >> >> System.loadLibrary and Runtime.loadLibrary loads a system library of the >> given >> library name that requires RuntimePermission("loadLibrary."+lib) >> permission. >> Many places in the JDK code loading a system native library is using the >> sun.security.action.LoadLibraryAction convenient class that will load >> the >> system library as a privileged action: >> java.security.AccessController.doPrivileged(new >> LoadLibraryAction("net")); >> >> The search path of native libraries are coupled with an associated class >> loader. >> For example, the application class loader uses the path specified in the >> "java.library.path" system property for native library lookup. The >> loadLibrary >> implementation uses the caller's class loader for finding the native >> library being >> requested. For system libraries, the class loader is null and the system >> library >> lookup is handled as a special case. When the >> sun.security.action.LoadLibraryAction >> class is used that is the caller of System.loadLibrary, the caller's >> class loader >> in this case is "null" loader and thus it always finds the native >> library from >> the system library path. >> >> In a modular world, JDK modules may be loaded by multiple different >> module class >> loader. The following code would not work if it is expected to load a >> native >> library from a module which is not the module where the >> sun.security.action.LoadLibraryAction lives. >> >> For example, the management module is trying to load libmanagement.so. >> Calling >> the following will fail to find libmanagement.so because the caller of >> System.loadLibrary is the LoadLibraryAction which is in the base module >> and search the library from the base module only. To prepare for jdk >> modularization, the use of LoadLibraryAction should be replaced with >> a direct call of System.loadLibrary. >> >> This patch also removes sun.security.action.LoadLibraryAction >> class to avoid regression. >> >> Thanks >> Mandy >> From kurchi.subhra.hazra at oracle.com Wed May 2 19:10:19 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Wed, 02 May 2012 12:10:19 -0700 Subject: [7u6] Request for approval: 7118100: (prefs) Inconsistency when using system and user preference on OSX Lion In-Reply-To: <4FA050A8.8040605@oracle.com> References: <4FA050A8.8040605@oracle.com> Message-ID: <4FA1869B.6020501@oracle.com> Requesting approval to commit fix for CR 7118100. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7118100 Webrev: http://cr.openjdk.java.net/~khazra/7118100/webrev.01/ This had been reviewed by Alan Bateman. [1] This fix has been pushed into jdk8 [2] Thanks, Kurchi [1] http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-February/003081.html [2] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/108a02a57b75 From alan.bateman at oracle.com Wed May 2 19:15:24 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 02 May 2012 19:15:24 +0000 Subject: hg: jdk8/tl/jdk: 7165102: Only run assertion on Integer autoboxing cache size once Message-ID: <20120502191548.7B127470F1@hg.openjdk.java.net> Changeset: bb2cefc89bc0 Author: forax Date: 2012-05-02 20:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bb2cefc89bc0 7165102: Only run assertion on Integer autoboxing cache size once Reviewed-by: darcy, alanb ! src/share/classes/java/lang/Integer.java From alan.bateman at oracle.com Wed May 2 20:47:22 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 02 May 2012 20:47:22 +0000 Subject: hg: jdk8/tl/jdk: 7160714: Strange or obsolete @see tags in some exception java.util javadoc Message-ID: <20120502204733.6B314470F7@hg.openjdk.java.net> Changeset: 531ebfd8eb65 Author: jgish Date: 2012-05-02 21:46 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/531ebfd8eb65 7160714: Strange or obsolete @see tags in some exception java.util javadoc Reviewed-by: mduigou, dholmes, alanb ! src/share/classes/java/util/NoSuchElementException.java From golovnin at gmx.net Wed May 2 21:04:51 2012 From: golovnin at gmx.net (Andrej Golovnin) Date: Wed, 2 May 2012 23:04:51 +0200 Subject: [PATCH] Use #valueOf()-methods in Unsafe-based FieldAccessors In-Reply-To: <4FA05BA3.1000707@univ-mlv.fr> References: <4FA05BA3.1000707@univ-mlv.fr> Message-ID: <0132EC39-CDF8-4AB7-9D13-629D151C8F1D@gmx.net> Hi R?mi, > your far from Swing :) > (I remember you from the glorious appframework time) I still do some Swing stuff. :) > And the mailer deamon (or mailer imp ?) remove attachment, so you have to repost it inlined. Some one should mention this fact on this site: http://openjdk.java.net/contribute/ > and your ORM doesn't use neither field.getInt() (and variants) instead of field.get() > nor do bytecode enhancement ? Hibernate uses for example field.get() if you use @AccessType(FIELD) for JPA entities: https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/property/DirectPropertyAccessor.java > Also, because currently the escape analysis done by Hotspot is a little bit broken > you may introduce a slowdown/more memory consumption because the JIT > may be able to remove new Integer()/Integer.intValue() pair but not > Integer.valueOf()/Integer.intValue() pair. > > But I know that someone is working on this :) I know it too. :) When I analyze memory dumps from production systems, I see often a lot of Boolean and Integer objects which were created from classes in sun.reflect package. One part of objects is created by Unsafe-based FieldAccessors and the other part is created by classes generated by sub-classes of AccessorGenerator. So my idea was/is: - first to change the Unsafe-based FieldAccessors to use #valueOf()-methods (very simple patch) - and then to change AccessorGenerator and its sub-classes to use #valueOf()-methods. What do you think about it? Best regards Andrej Golovnin PS: here is the inlined patch # HG changeset patch # User golovnin # Date 1335989617 -7200 # Node ID 13e3638f723582d1df0b7c45c6aa983d4c2eed17 # Parent cfd7602f5c5247d551290ccf2cb2f5cd13fd8ce2 - use #valueOf()-methods in Unsafe-based FieldAccessors diff --git a/src/share/classes/sun/reflect/UnsafeBooleanFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeBooleanFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeBooleanFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeBooleanFieldAccessorImpl.java @@ -33,7 +33,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Boolean(getBoolean(obj)); + return Boolean.valueOf(getBoolean(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeByteFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeByteFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeByteFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeByteFieldAccessorImpl.java @@ -33,7 +33,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Byte(getByte(obj)); + return Byte.valueOf(getByte(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeCharacterFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeCharacterFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeCharacterFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeCharacterFieldAccessorImpl.java @@ -33,7 +33,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Character(getChar(obj)); + return Character.valueOf(getChar(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeIntegerFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeIntegerFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeIntegerFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeIntegerFieldAccessorImpl.java @@ -33,7 +33,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Integer(getInt(obj)); + return Integer.valueOf(getInt(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeLongFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeLongFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeLongFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeLongFieldAccessorImpl.java @@ -33,7 +33,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Long(getLong(obj)); + return Long.valueOf(getLong(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeQualifiedBooleanFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeQualifiedBooleanFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeQualifiedBooleanFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeQualifiedBooleanFieldAccessorImpl.java @@ -35,7 +35,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Boolean(getBoolean(obj)); + return Boolean.valueOf(getBoolean(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeQualifiedByteFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeQualifiedByteFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeQualifiedByteFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeQualifiedByteFieldAccessorImpl.java @@ -35,7 +35,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Byte(getByte(obj)); + return Byte.valueOf(getByte(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeQualifiedCharacterFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeQualifiedCharacterFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeQualifiedCharacterFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeQualifiedCharacterFieldAccessorImpl.java @@ -35,7 +35,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Character(getChar(obj)); + return Character.valueOf(getChar(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeQualifiedIntegerFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeQualifiedIntegerFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeQualifiedIntegerFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeQualifiedIntegerFieldAccessorImpl.java @@ -35,7 +35,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Integer(getInt(obj)); + return Integer.valueOf(getInt(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeQualifiedLongFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeQualifiedLongFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeQualifiedLongFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeQualifiedLongFieldAccessorImpl.java @@ -35,7 +35,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Long(getLong(obj)); + return Long.valueOf(getLong(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeQualifiedShortFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeQualifiedShortFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeQualifiedShortFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeQualifiedShortFieldAccessorImpl.java @@ -35,7 +35,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Short(getShort(obj)); + return Short.valueOf(getShort(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeQualifiedStaticBooleanFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeQualifiedStaticBooleanFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeQualifiedStaticBooleanFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeQualifiedStaticBooleanFieldAccessorImpl.java @@ -35,7 +35,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Boolean(getBoolean(obj)); + return Boolean.valueOf(getBoolean(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeQualifiedStaticByteFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeQualifiedStaticByteFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeQualifiedStaticByteFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeQualifiedStaticByteFieldAccessorImpl.java @@ -35,7 +35,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Byte(getByte(obj)); + return Byte.valueOf(getByte(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeQualifiedStaticCharacterFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeQualifiedStaticCharacterFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeQualifiedStaticCharacterFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeQualifiedStaticCharacterFieldAccessorImpl.java @@ -35,7 +35,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Character(getChar(obj)); + return Character.valueOf(getChar(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeQualifiedStaticIntegerFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeQualifiedStaticIntegerFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeQualifiedStaticIntegerFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeQualifiedStaticIntegerFieldAccessorImpl.java @@ -35,7 +35,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Integer(getInt(obj)); + return Integer.valueOf(getInt(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeQualifiedStaticLongFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeQualifiedStaticLongFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeQualifiedStaticLongFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeQualifiedStaticLongFieldAccessorImpl.java @@ -35,7 +35,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Long(getLong(obj)); + return Long.valueOf(getLong(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeQualifiedStaticShortFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeQualifiedStaticShortFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeQualifiedStaticShortFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeQualifiedStaticShortFieldAccessorImpl.java @@ -35,7 +35,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Short(getShort(obj)); + return Short.valueOf(getShort(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeShortFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeShortFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeShortFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeShortFieldAccessorImpl.java @@ -33,7 +33,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Short(getShort(obj)); + return Short.valueOf(getShort(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeStaticBooleanFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeStaticBooleanFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeStaticBooleanFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeStaticBooleanFieldAccessorImpl.java @@ -33,7 +33,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Boolean(getBoolean(obj)); + return Boolean.valueOf(getBoolean(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeStaticByteFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeStaticByteFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeStaticByteFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeStaticByteFieldAccessorImpl.java @@ -33,7 +33,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Byte(getByte(obj)); + return Byte.valueOf(getByte(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeStaticCharacterFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeStaticCharacterFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeStaticCharacterFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeStaticCharacterFieldAccessorImpl.java @@ -33,7 +33,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Character(getChar(obj)); + return Character.valueOf(getChar(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeStaticIntegerFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeStaticIntegerFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeStaticIntegerFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeStaticIntegerFieldAccessorImpl.java @@ -33,7 +33,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Integer(getInt(obj)); + return Integer.valueOf(getInt(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeStaticLongFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeStaticLongFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeStaticLongFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeStaticLongFieldAccessorImpl.java @@ -33,7 +33,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Long(getLong(obj)); + return Long.valueOf(getLong(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeStaticShortFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeStaticShortFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeStaticShortFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeStaticShortFieldAccessorImpl.java @@ -33,7 +33,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Short(getShort(obj)); + return Short.valueOf(getShort(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { From stuart.marks at oracle.com Wed May 2 21:57:29 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 02 May 2012 14:57:29 -0700 Subject: Proposed refactoring: introduce JLS7 language features to core libs In-Reply-To: <9591BB2C-260A-4C23-A2F9-72BA4A297664@mac.com> References: <7BCF83EB-75F1-46A6-917E-2619974A4545@mac.com> <5FA2ABE2-4272-4F7A-8880-74E426C04346@mac.com> <4F9F41F6.40609@oracle.com> <9591BB2C-260A-4C23-A2F9-72BA4A297664@mac.com> Message-ID: <4FA1ADC9.1010306@oracle.com> On 5/1/12 11:23 AM, Stefan Reich wrote: > Hi Stuart, > > thank you for your reply. I sent a patch to the adopt-openjdk group that uses multi-catch for catch clauses with duplicate code blocks in the same try statement (message and patch attached). That patch covers all code in src/shared/classes. Martijn will help coordinating the effort with all individual component owners, since I don't know anyone over at the OpenJDK team. OK great, glad to hear you're coordinating this with Martijn and the Adopt OpenJDK gang. > The string switch conversion is relatively straight forward, too. The more complicated case that you mention: > String s; > if("literal1".equals(s)) { > } else if("literal2".equals(s)) { > } else { > // s is null or some other value > } > > is very rare in the OpenJDK code base. I saw only a handful of occurrences out of 95 files affected by this refactoring (in src/share/classes). If there is interest, I'd review the changes and create a patch, but I wanted to see how things are going with my first submission before investing more time. I'm surprised there are that many occurrences in the JDK. It's good to know that the null issue comes up only rarely. In any case, it might make sense to see how the multi-catch changes go before inundating the group with too many patches. > How far are you with type inference? Are you going to write a NetBeans plugin? By "type inference" I assume you mean "type inference for generic instance creation" -- which we usually refer to as diamond -- and not type inference in general. There is already a NetBeans facility to do this kind of refactoring. It wasn't available when I was doing coinification work in 2010 and 2011. It was introduced in NetBeans 7.1 I believe. It's available under the Refactoring > Inspect and Transform dialog. Look for "Can Use Diamond" in the "JDK 1.5 and Later" category. I'm not actively working on coinification, so if you (or somebody else in Adopt OpenJDK) wants to pursue diamond conversion, by all means go ahead. s'marks From littlee at linux.vnet.ibm.com Thu May 3 06:52:21 2012 From: littlee at linux.vnet.ibm.com (Charles Lee) Date: Thu, 03 May 2012 14:52:21 +0800 Subject: [doc]Small modification on the WeakHashMap doc Message-ID: <4FA22B25.2090201@linux.vnet.ibm.com> Hi guys, In the Implementation notes of WeakHashMap[1], says: /One way to deal with this is to wrap values themselves within WeakReferences before inserting, as in: m.put(key, new WeakReference(value)), and then unwrapping upon each get./ However, it is not concise and a little misleading. Because the value in the WeakReference can be GC'd if there are no strong reference to it. This behaviour surprises some customers. How about add a statement like [2]: /However, as the use of WeakReference in this manner will not prevent value objects from being GC'd, this approach is only useful when entries in the map are not relied upon for keeping the underlying value objects "live"./ [1]: http://docs.oracle.com/javase/7/docs/api/java/util/WeakHashMap.html [2]: http://cr.openjdk.java.net/~littlee/7166055/webrev.00/ -- Yours Charles From paul.sandoz at oracle.com Thu May 3 08:38:23 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 3 May 2012 10:38:23 +0200 Subject: RFR: 5015163 "(str) String merge/join that is the inverse of String.split()" into JDK 8 In-Reply-To: <4FA0D69A.9030302@oracle.com> References: <4F9B1C05.1080101@oracle.com> <4F9B2551.9070506@univ-mlv.fr> <4F9EA05E.6020401@oracle.com> <4F9FC2B7.2080000@univ-mlv.fr> <4FA0065A.80002@oracle.com> <4FA01A76.5090904@univ-mlv.fr> <4FA0D69A.9030302@oracle.com> Message-ID: On May 2, 2012, at 8:39 AM, Stuart Marks wrote: > > It's fun to think about how joining would work in a lambda/streamy kind of world, e.g. > > stream.infix(",").join(new StringBuilder()).toString() > Indeed :-) [Paul ducks as he makes up stuff!]: String s = stream.interpose(",").reduce(new ToStringReducer()); since join can be considered a reduce operation, and the above could be equivalent to: String s = stream.interleave(repeat(",")).drop(1).reduce(new ToStringReducer()); [*] As well as: String s = stream.join(",") // can be optimal implementation specific to strings, String.join could defer to this > or some such. There are a bunch of issues to consider here though, such as special-casing of types in the input stream, e.g., append CharSequence directly instead of calling toString(), treat int value as a Unicode code point, etc. There are also issues about the result type: StringBuilder? String? Appendable? > > As much as I like the lambda stuff, though, I don't think having stream-based joining will supplant the need to have a good old-fashioned > > String.join(",", ...bunch of strings...) > Yes. Paul. [*] interleave could support one or more streams From paul.sandoz at oracle.com Thu May 3 08:49:55 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 3 May 2012 10:49:55 +0200 Subject: RFR: 5015163 "(str) String merge/join that is the inverse of String.split()" into JDK 8 In-Reply-To: <4F9FD9CB.4050706@univ-mlv.fr> References: <4F9B1C05.1080101@oracle.com> <4F9B2551.9070506@univ-mlv.fr> <4F9FC09D.80803@univ-mlv.fr> <2669F0CE-32B4-4ED4-8A24-59A1BE3DC559@oracle.com> <4F9FD9CB.4050706@univ-mlv.fr> Message-ID: On May 1, 2012, at 2:40 PM, R?mi Forax wrote: >>>> Not saying join should be implemented that way (not so optimal for Strings only) but i think such functions are very useful. I am not tracking the lambda library work very closely, have such functions been considered? >>> >>> Yes, we discuss about zip/unzip, and what we call BiStream. >>> unzip is the other name of interleave. >>> >> >> Would that require the creation of an intermediate object that holds two values? > > or reuse Map.Entry. > That are the two reasonable choices. > I was questioning whether the creation of such objects are necessary, not the definition of a class of such an object. i.e. while zip/unzip could be used it does not seem particular efficient for the interleave use-case (especially when three or more streams are interleaved). > Paul, I think this discussion should be moved to lambda-dev. > It will be more fruitful. > Given the context with core libraries i kept it on the same list for now. Paul. From olivier.lagneau at oracle.com Thu May 3 13:09:45 2012 From: olivier.lagneau at oracle.com (Olivier Lagneau) Date: Thu, 03 May 2012 15:09:45 +0200 Subject: Review Request for CR : 7144861 RMI activation tests are too slow Message-ID: <4FA28399.9000601@oracle.com> Please review this fix for making the jdk regression tests for rmi activation run faster. It brings a near to x2 speed factor on a Solaris/SPARC machine. The webrev for the fix is here: http://cr.openjdk.java.net/~olagneau/7144861/webrev.00/ This is a speedup only fix that does not attempt to cleanup the rmi/testlibrary code and minimizes the changes. The fix consists in applying what is described as suggestedFix(Entry 1) in bug page(see http://monaco.sfbay.sun.com/detail.jsf?cr=7144861). It mainly reduces long (seconds) waiting times steps by several much shorter ones (second tenthes) that have been chosen to minimize and keep usefull the waiting loops. These waiting time values are hardcoded, as were before the fix. The additional possible fixes described in suggestFix/Entry2 (grouping jtreg @build tags, and reducing waiting time in tests) are *not* applied here. Below is the detailed list of changes. Thanks, Olivier. Here are the details of the changes I did: ---------------------------------------------b. - testlibrary/JavaVM.java : rather than waiting once for an "hopefully sufficient" time of 2secs at the end of start() method, a way to know when the vm is really started has been added with the help of redirected buffers in StreamPipe : in StreamPipe.run(), as soon as we have something to read in the vm output buffer, it means the distant vm can be considered started, and thus a synchronized JavaVM.started() method that sets-up a javaVM "started" status is called. We force such an output in the default case (most used one) by prepending "-showversion" flag in the command line running distant vm process. At the end of JavaVM.start(), we loop and wait by steps of 100msecs to check for the "started" status until the started status is set or max bound time is reached (keeping the initial max of 2secs bound). If bound is reached without seeing started flag set, vm is consiedered started anyway. We keep the previously existing way of starting the vm and using streamPipe for the cases where we don't want child vm to output anything or if we don't have any control of child process (when started without using JavaVM constructor/start). In a usual jtreg env, 3 loops are most often enough (300msecs), with a max of 700msecs seen from numerous trials. - testlibrary/StreamPipe : this is all described here above. - testlibray/RMID : start() method: the existing waiting time slices have been reduced to 100msecs, before calling rmidRunning(). These were/are useless since rmidRunning() also does such waiting loops, but the intention is not to cleanup testlibrary code to avoid confusion and mixing things. So just reduced the waiting time slices. Most of the times 1 such waiting step is enough, since rmidRunning does the same kind of loops. So we most often see rmid running after 300msecs most often, with an observed max of 1.1sec. shutdown() : suppressed useless sleep(5000) which is better handled in destroy() method. Provide additional status on communication status with distant rmid. destroy() : Added a waiting loop on process.exitvalue() (by steps of 200msecs) to have more chances to see distant rmid process terminates gracefully, while being faster. The max waiting time bound here is 60secs (300 steps). Observed needed time varies between 600msecs and 3secs. - testlibrary/ActivationLibrary : deactivate(): Waiting time steps reduced from 1000msecs to 100, enlarging the number of steps to 50 (kept total waiitng time of 5secs). In almost all cases 1 waiting step is enough, sometimes up to 5, and only for CheckImplClassLoader we occasionnally never see inactive call succeeding. rmidRunning() : Reduced the waiting time slice to 100msecs and added some communication/exception status info. Kept the max waiting time bound of 7.5secs. In most cases 300msecs (3 steps) is enough. - CheckUsage test: main() : suppressed useless sleep of 7secs. - NoConsoleOutput test: main() : the only observed test to expect no output from distant vm. Thus using previously existing method for instantiating/starting distant vm, with a fixed waiting time of 2secs. -----------------------------------------------------------e. From Alan.Bateman at oracle.com Thu May 3 17:53:09 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 03 May 2012 18:53:09 +0100 Subject: Review Request for CR : 7144861 RMI activation tests are too slow In-Reply-To: <4FA28399.9000601@oracle.com> References: <4FA28399.9000601@oracle.com> Message-ID: <4FA2C605.7010908@oracle.com> On 03/05/2012 14:09, Olivier Lagneau wrote: > Please review this fix for making the jdk regression tests for rmi > activation run faster. > It brings a near to x2 speed factor on a Solaris/SPARC machine. > > The webrev for the fix is here: > http://cr.openjdk.java.net/~olagneau/7144861/webrev.00/ It's great to see patches like this, thank you! The RMI tests have always been really slow, the activation tests in particular so I'm looking forward to seeing this patch go in. I'm also looking forward to trying it out in conjunction with Darryl Mocek's patch as the combined patches should mean we get much better overall through-put. I think Stuart is going to do the detailed review and help you get this over the finish line. I've just scanned the webrev (I didn't do a detailed review) and I didn't see anything obviously wrong, looks like the changes are in the right places. -Alan. From jim.gish at oracle.com Thu May 3 18:22:05 2012 From: jim.gish at oracle.com (Jim Gish) Date: Thu, 03 May 2012 14:22:05 -0400 Subject: RFR: 5015163 "(str) String merge/join that is the inverse of String.split()" into JDK 8 In-Reply-To: References: <4F9B1C05.1080101@oracle.com> <4F9B2551.9070506@univ-mlv.fr> <4F9EA05E.6020401@oracle.com> <4F9FC2B7.2080000@univ-mlv.fr> <4FA0065A.80002@oracle.com> <4FA01A76.5090904@univ-mlv.fr> <4FA0D69A.9030302@oracle.com> Message-ID: <4FA2CCCD.9000607@oracle.com> I'm just now reading "State of the Lambda" and beginning to get a handle on this discussion, which makes sense to me today (and didn't yesterday morning). (All this stuff about "reduce" is definitely taking me back to my APL days. "s <- ./list" -- a concat/reduce operation (sans the delimiter of course)) Once I come up to speed more thoroughly I'll take a shot at this with join. Your comments are definitely giving me food for thought. Thanks, JIm On 05/03/2012 04:38 AM, Paul Sandoz wrote: > On May 2, 2012, at 8:39 AM, Stuart Marks wrote: >> >> It's fun to think about how joining would work in a lambda/streamy >> kind of world, e.g. >> >> stream.infix(",").join(new StringBuilder()).toString() >> > > Indeed :-) [Paul ducks as he makes up stuff!]: > > String s = stream.interpose(",").reduce(new ToStringReducer()); > > since join can be considered a reduce operation, and the above could > be equivalent to: > > String s > = stream.interleave(repeat(",")).drop(1).reduce(new ToStringReducer()); [*] > > As well as: > > String s = stream.join(",") // can be optimal implementation > specific to strings, String.join could defer to this > > >> or some such. There are a bunch of issues to consider here though, >> such as special-casing of types in the input stream, e.g., append >> CharSequence directly instead of calling toString(), treat int value >> as a Unicode code point, etc. There are also issues about the result >> type: StringBuilder? String? Appendable? >> >> As much as I like the lambda stuff, though, I don't think having >> stream-based joining will supplant the need to have a good old-fashioned >> >> String.join(",", ...bunch of strings...) >> > > Yes. > > Paul. > > [*] interleave could support one or more streams > From Alan.Bateman at oracle.com Thu May 3 20:49:06 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 03 May 2012 21:49:06 +0100 Subject: Code Review Request: 7165118: (prefs) AbstractPreferences.remove(null) does not throw NPE In-Reply-To: <4FA17322.905@oracle.com> References: <4FA03311.1070907@oracle.com> <4FA0AFDB.4040004@oracle.com> <4FA1040C.4030509@oracle.com> <4FA1048E.8060901@oracle.com> <4FA10504.5070405@oracle.com> <4FA17322.905@oracle.com> Message-ID: <4FA2EF42.9000400@oracle.com> On 02/05/2012 18:47, Kurchi Hazra wrote: > Thanks all for the review. A webrev with the doc change: > http://cr.openjdk.java.net/~khazra/7165118/webrev.01/ This looks fine to me. -Alan From kumar.x.srinivasan at oracle.com Fri May 4 16:00:57 2012 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Fri, 04 May 2012 16:00:57 +0000 Subject: hg: jdk8/tl/langtools: 7166010: (javac) JavacMessager incorrectly restores log source file Message-ID: <20120504160059.9C88647156@hg.openjdk.java.net> Changeset: d10db3576c08 Author: ksrini Date: 2012-05-04 07:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d10db3576c08 7166010: (javac) JavacMessager incorrectly restores log source file Reviewed-by: jjg Contributed-by: jan.lahoda at oracle.com ! src/share/classes/com/sun/tools/javac/processing/JavacMessager.java + test/tools/javac/processing/messager/MessagerDiags.java From lance.andersen at oracle.com Fri May 4 20:02:17 2012 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Fri, 04 May 2012 20:02:17 +0000 Subject: hg: jdk8/tl/jdk: 7166598: FilteredRowSetImpl can result in Invalid Cursor Position Message-ID: <20120504200228.53CE747161@hg.openjdk.java.net> Changeset: 4580652d9828 Author: lancea Date: 2012-05-04 16:00 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4580652d9828 7166598: FilteredRowSetImpl can result in Invalid Cursor Position Reviewed-by: lancea Contributed-by: Knut Anders Hatlen ! src/share/classes/com/sun/rowset/FilteredRowSetImpl.java From xuelei.fan at oracle.com Sat May 5 00:31:24 2012 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Sat, 05 May 2012 00:31:24 +0000 Subject: hg: jdk8/tl/jdk: 7153184: NullPointerException when calling SSLEngineImpl.getSupportedCipherSuites Message-ID: <20120505003134.C962847165@hg.openjdk.java.net> Changeset: 41d3f7509e00 Author: xuelei Date: 2012-05-04 17:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/41d3f7509e00 7153184: NullPointerException when calling SSLEngineImpl.getSupportedCipherSuites Reviewed-by: weijun ! src/share/classes/sun/security/ssl/SSLContextImpl.java From stuart.marks at oracle.com Sat May 5 01:50:56 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 04 May 2012 18:50:56 -0700 Subject: Review Request for CR : 7144861 RMI activation tests are too slow In-Reply-To: <4FA2C605.7010908@oracle.com> References: <4FA28399.9000601@oracle.com> <4FA2C605.7010908@oracle.com> Message-ID: <4FA48780.3030901@oracle.com> On 5/3/12 10:53 AM, Alan Bateman wrote: > On 03/05/2012 14:09, Olivier Lagneau wrote: >> Please review this fix for making the jdk regression tests for rmi activation >> run faster. >> It brings a near to x2 speed factor on a Solaris/SPARC machine. >> >> The webrev for the fix is here: >> http://cr.openjdk.java.net/~olagneau/7144861/webrev.00/ > It's great to see patches like this, thank you! The RMI tests have always been > really slow, the activation tests in particular so I'm looking forward to > seeing this patch go in. I'm also looking forward to trying it out in > conjunction with Darryl Mocek's patch as the combined patches should mean we > get much better overall through-put. > > I think Stuart is going to do the detailed review and help you get this over > the finish line. I've just scanned the webrev (I didn't do a detailed review) > and I didn't see anything obviously wrong, looks like the changes are in the > right places. Yes, good stuff. The tests don't get nearly enough maintenance, and a 2x speedup just by managing timeouts better is great. A few relatively minor comments. ActivationLibrary.java -- If we catch an InterruptedException while sleeping, we reassert the interrupt bit by interrupting the current thread. This is usually good practice. In this case though we go around the loop again, retry, and sleep again. But if we call sleep() when the interrupt bit is set, it returns immediately. As it stands, after being interrupted, this code will retry a bunch of times effectively without sleeping and will then return false. I guess if we're going to go to the trouble of reasserting the interrupt bit we might as well return false immediately. JavaVM.java -- The started() method is synchronized because it needs to set shared state (the started field) from another thread. However, code here uses the started field without any synchronization. Since the state is just a boolean probably the easiest thing to do is to is to make it volatile, in which case the started() method doesn't need to be synchronized. The maxTrials variable isn't actually the maximum number of trials, it's the current number of trials. A small thing but it would be good if it were renamed. Urgh. The addOptions/addArguments methods concatenate all the arguments and options into a single string, and then the start() method tokenizes them out again into an array of strings. Heaven forbid somebody pass a filename with a space. I don't expect you to fix this. I just had to say something. :-( RMID.java -- In the start() method, as before, the thread is reasserting the interrupt bit on itself when it's interrupted. If it does this it should just return immediately, otherwise it will spin around the loop without sleeping until waitTime gets to zero. I observe that the timer loop in start() doesn't necessarily wait for an accurate amount of time, as sleep() can return early or late. There are better techniques for dealing with this, but it's not clear to me it's worth rewriting the code. This is something to bear in mind when writing more time-critical code, however. In destroy() I see that the maxTrials variable here really is the maximum number of trials, which is good. :-) The timing loop here suffers from similar problems as the above. I mean, it mostly works, but it could probably be simplified by calling vm.waitFor() and having a task interrupt that call after a timeout period. But it's probably not worth rewriting at this point. * * * So, overall I'd like to see the interrupt handling changed and the started field made volatile and maxTrials renamed in JavaVM.java. The other issues probably should be taken care of at some point at some point in the future; I think we all want the benefits of faster tests now! :-) Thanks. s'marks From david.holmes at oracle.com Sun May 6 12:30:11 2012 From: david.holmes at oracle.com (David Holmes) Date: Sun, 06 May 2012 22:30:11 +1000 Subject: Review Request for CR : 7144861 RMI activation tests are too slow In-Reply-To: <4FA48780.3030901@oracle.com> References: <4FA28399.9000601@oracle.com> <4FA2C605.7010908@oracle.com> <4FA48780.3030901@oracle.com> Message-ID: <4FA66ED3.7030209@oracle.com> On 5/05/2012 11:50 AM, Stuart Marks wrote: >> On 03/05/2012 14:09, Olivier Lagneau wrote: >>> Please review this fix for making the jdk regression tests for rmi >>> activation >>> run faster. >>> It brings a near to x2 speed factor on a Solaris/SPARC machine. >>> >>> The webrev for the fix is here: >>> http://cr.openjdk.java.net/~olagneau/7144861/webrev.00/ > ActivationLibrary.java -- > > If we catch an InterruptedException while sleeping, we reassert the > interrupt bit by interrupting the current thread. This is usually good > practice. In this case though we go around the loop again, retry, and > sleep again. But if we call sleep() when the interrupt bit is set, it > returns immediately. As it stands, after being interrupted, this code > will retry a bunch of times effectively without sleeping and will then > return false. > > I guess if we're going to go to the trouble of reasserting the interrupt > bit we might as well return false immediately. Does anything in this testing framework actually interrupt any threads? Elsewhere in this test the interrupt, should it be possible, just skips to the next loop iteration without being re-asserted. So either we need to re-assert always or never - and I suspect never. > JavaVM.java -- > > The started() method is synchronized because it needs to set shared > state (the started field) from another thread. However, code here uses > the started field without any synchronization. Since the state is just a > boolean probably the easiest thing to do is to is to make it volatile, > in which case the started() method doesn't need to be synchronized. And naming wise setStarted() would be better than started() IMHO. David ----- > The maxTrials variable isn't actually the maximum number of trials, it's > the current number of trials. A small thing but it would be good if it > were renamed. > > Urgh. The addOptions/addArguments methods concatenate all the arguments > and options into a single string, and then the start() method tokenizes > them out again into an array of strings. Heaven forbid somebody pass a > filename with a space. I don't expect you to fix this. I just had to say > something. :-( > > RMID.java -- > > In the start() method, as before, the thread is reasserting the > interrupt bit on itself when it's interrupted. If it does this it should > just return immediately, otherwise it will spin around the loop without > sleeping until waitTime gets to zero. > > I observe that the timer loop in start() doesn't necessarily wait for an > accurate amount of time, as sleep() can return early or late. There are > better techniques for dealing with this, but it's not clear to me it's > worth rewriting the code. This is something to bear in mind when writing > more time-critical code, however. > > In destroy() I see that the maxTrials variable here really is the > maximum number of trials, which is good. :-) > > The timing loop here suffers from similar problems as the above. I mean, > it mostly works, but it could probably be simplified by calling > vm.waitFor() and having a task interrupt that call after a timeout > period. But it's probably not worth rewriting at this point. > > * * * > > So, overall I'd like to see the interrupt handling changed and the > started field made volatile and maxTrials renamed in JavaVM.java. The > other issues probably should be taken care of at some point at some > point in the future; I think we all want the benefits of faster tests > now! :-) > > Thanks. > > s'marks From littlee at linux.vnet.ibm.com Mon May 7 03:05:02 2012 From: littlee at linux.vnet.ibm.com (Charles Lee) Date: Mon, 07 May 2012 11:05:02 +0800 Subject: [doc]Small modification on the WeakHashMap doc In-Reply-To: <4FA22B25.2090201@linux.vnet.ibm.com> References: <4FA22B25.2090201@linux.vnet.ibm.com> Message-ID: <4FA73BDE.1040309@linux.vnet.ibm.com> Hi guys, Does anyone interested in this issue? On 05/03/2012 02:52 PM, Charles Lee wrote: > Hi guys, > > In the Implementation notes of WeakHashMap[1], says: > > /One way to deal with this is to wrap values themselves within > WeakReferences before inserting, as in: m.put(key, new > WeakReference(value)), and then unwrapping upon each get./ > > However, it is not concise and a little misleading. Because the value > in the WeakReference can be GC'd if there are no strong reference to > it. This behaviour surprises some customers. > How about add a statement like [2]: > > /However, as the use of WeakReference in this manner will not prevent > value objects from being GC'd, this approach is only useful when > entries in the map are not relied upon for keeping the underlying > value objects "live"./ > > > > > [1]: http://docs.oracle.com/javase/7/docs/api/java/util/WeakHashMap.html > [2]: http://cr.openjdk.java.net/~littlee/7166055/webrev.00/ > > -- Yours Charles From david.holmes at oracle.com Mon May 7 03:45:11 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 07 May 2012 13:45:11 +1000 Subject: [doc]Small modification on the WeakHashMap doc In-Reply-To: <4FA73BDE.1040309@linux.vnet.ibm.com> References: <4FA22B25.2090201@linux.vnet.ibm.com> <4FA73BDE.1040309@linux.vnet.ibm.com> Message-ID: <4FA74547.7040901@oracle.com> Hi Charles, On 7/05/2012 1:05 PM, Charles Lee wrote: > Does anyone interested in this issue? Interest and time are two different things :) A shorter form would be: "If the values in the map do not rely on the map holding strong references to them, then one way to deal with this is ... David > On 05/03/2012 02:52 PM, Charles Lee wrote: >> Hi guys, >> >> In the Implementation notes of WeakHashMap[1], says: >> >> /One way to deal with this is to wrap values themselves within >> WeakReferences before inserting, as in: m.put(key, new >> WeakReference(value)), and then unwrapping upon each get./ >> >> However, it is not concise and a little misleading. Because the value >> in the WeakReference can be GC'd if there are no strong reference to >> it. This behaviour surprises some customers. >> How about add a statement like [2]: >> >> /However, as the use of WeakReference in this manner will not prevent >> value objects from being GC'd, this approach is only useful when >> entries in the map are not relied upon for keeping the underlying >> value objects "live"./ >> >> >> >> >> [1]: http://docs.oracle.com/javase/7/docs/api/java/util/WeakHashMap.html >> [2]: http://cr.openjdk.java.net/~littlee/7166055/webrev.00/ >> >> > > From littlee at linux.vnet.ibm.com Mon May 7 08:43:51 2012 From: littlee at linux.vnet.ibm.com (littlee at linux.vnet.ibm.com) Date: Mon, 07 May 2012 08:43:51 +0000 Subject: hg: jdk8/tl/jdk: 7166048: Remove the embeded epoll data structure. Message-ID: <20120507084420.528C94718B@hg.openjdk.java.net> Changeset: 62557a1336c0 Author: zhouyx Date: 2012-05-07 16:43 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/62557a1336c0 7166048: Remove the embeded epoll data structure. Reviewed-by: alanb ! src/solaris/native/sun/nio/ch/EPollArrayWrapper.c From littlee at linux.vnet.ibm.com Mon May 7 08:50:52 2012 From: littlee at linux.vnet.ibm.com (Charles Lee) Date: Mon, 07 May 2012 16:50:52 +0800 Subject: [doc]Small modification on the WeakHashMap doc In-Reply-To: <4FA74547.7040901@oracle.com> References: <4FA22B25.2090201@linux.vnet.ibm.com> <4FA73BDE.1040309@linux.vnet.ibm.com> <4FA74547.7040901@oracle.com> Message-ID: <4FA78CEC.6000603@linux.vnet.ibm.com> Thanks David :-) On 05/07/2012 11:45 AM, David Holmes wrote: > Hi Charles, > > On 7/05/2012 1:05 PM, Charles Lee wrote: >> Does anyone interested in this issue? > > Interest and time are two different things :) > > A shorter form would be: > > "If the values in the map do not rely on the map holding strong > references to them, then one way to deal with this is ... > > David > >> On 05/03/2012 02:52 PM, Charles Lee wrote: >>> Hi guys, >>> >>> In the Implementation notes of WeakHashMap[1], says: >>> >>> /One way to deal with this is to wrap values themselves within >>> WeakReferences before inserting, as in: m.put(key, new >>> WeakReference(value)), and then unwrapping upon each get./ >>> >>> However, it is not concise and a little misleading. Because the value >>> in the WeakReference can be GC'd if there are no strong reference to >>> it. This behaviour surprises some customers. >>> How about add a statement like [2]: >>> >>> /However, as the use of WeakReference in this manner will not prevent >>> value objects from being GC'd, this approach is only useful when >>> entries in the map are not relied upon for keeping the underlying >>> value objects "live"./ >>> >>> >>> >>> >>> [1]: >>> http://docs.oracle.com/javase/7/docs/api/java/util/WeakHashMap.html >>> [2]: http://cr.openjdk.java.net/~littlee/7166055/webrev.00/ >>> >>> >> >> > -- Yours Charles From youdwei at linux.vnet.ibm.com Mon May 7 09:38:46 2012 From: youdwei at linux.vnet.ibm.com (Deven You) Date: Mon, 07 May 2012 17:38:46 +0800 Subject: Pass a pointer to JNI_GetCreatedJavaVMs() instead of null Message-ID: <4FA79826.2030900@linux.vnet.ibm.com> Hi All, There is a potential problem in jdk/src/share/native/com/sun/java/util/jar/pack/jni.cpp. (Maybe it is not suitable for posting this on core-lib, anyone could tell me which mailing list is prefer?) L85: JNI_GetCreatedJavaVMs(&vm, 1, null) in which the 3rd parameter is a pointer to an integer. See[1], the latest JNI Invocation API spec does not say anything about allowing a null as the last parameter. I think it is more reasonable to change null to an integer variable. Here is my fix[2] [1] http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/invocation.html#wp633 [2] http://cr.openjdk.java.net/~littlee/ojdk-432/webrev.00/ Please review this mail! Thanks a lot! -- Best Regards, Deven From david.holmes at oracle.com Mon May 7 10:39:40 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 07 May 2012 20:39:40 +1000 Subject: Pass a pointer to JNI_GetCreatedJavaVMs() instead of null In-Reply-To: <4FA79826.2030900@linux.vnet.ibm.com> References: <4FA79826.2030900@linux.vnet.ibm.com> Message-ID: <4FA7A66C.2000206@oracle.com> On 7/05/2012 7:38 PM, Deven You wrote: > Hi All, > > There is a potential problem in > jdk/src/share/native/com/sun/java/util/jar/pack/jni.cpp. > > (Maybe it is not suitable for posting this on core-lib, anyone could > tell me which mailing list is prefer?) > > L85: > > JNI_GetCreatedJavaVMs(&vm, 1, null) in which the 3rd parameter is a > pointer to an integer. See[1], the latest JNI Invocation API spec does > not say anything about allowing a null as the last parameter. The spec doesn't say anything but the implementation does check for NULL. I think this is a spec issue rather than a code issue (and I think hotspot-runtime owns the JNI spec so cc'ed). It is common practice for API's that take pointers like this to say "if buf is not NULL then the value of XXX is written into buf". Particularly as in this case there will only ever be at most 1 VM created per-process anyway. I'm more concerned about the fact that the code doesn't even check if JNI_GetCreatedVMs returns successfully! David ----- > I think it is more reasonable to change null to an integer variable. > Here is my fix[2] > > [1] > http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/invocation.html#wp633 > > > [2] http://cr.openjdk.java.net/~littlee/ojdk-432/webrev.00/ > > > > Please review this mail! > > Thanks a lot! > From rob.mckenna at oracle.com Mon May 7 12:33:32 2012 From: rob.mckenna at oracle.com (rob.mckenna at oracle.com) Date: Mon, 07 May 2012 12:33:32 +0000 Subject: hg: jdk8/tl/jdk: 7166687: InetAddress.getLocalHost().getHostName() returns FQDN Message-ID: <20120507123402.865554718C@hg.openjdk.java.net> Changeset: b26c04717735 Author: robm Date: 2012-05-07 13:34 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b26c04717735 7166687: InetAddress.getLocalHost().getHostName() returns FQDN Reviewed-by: chegar ! src/solaris/native/java/net/Inet6AddressImpl.c From Alan.Bateman at oracle.com Mon May 7 13:27:43 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 07 May 2012 14:27:43 +0100 Subject: Pass a pointer to JNI_GetCreatedJavaVMs() instead of null In-Reply-To: <4FA7A66C.2000206@oracle.com> References: <4FA79826.2030900@linux.vnet.ibm.com> <4FA7A66C.2000206@oracle.com> Message-ID: <4FA7CDCF.2070005@oracle.com> On 07/05/2012 11:39, David Holmes wrote: > > The spec doesn't say anything but the implementation does check for > NULL. I think this is a spec issue rather than a code issue (and I > think hotspot-runtime owns the JNI spec so cc'ed). It is common > practice for API's that take pointers like this to say "if buf is not > NULL then the value of XXX is written into buf". Particularly as in > this case there will only ever be at most 1 VM created per-process > anyway. > > I'm more concerned about the fact that the code doesn't even check if > JNI_GetCreatedVMs returns successfully! I agree that the JNI spec needs clarification and it would be inconsistent if this function didn't allow this parameter to be NULL. In addition it would be incompatible change (and would likely break existing code) if the spec were clarified to disallow NULL. Another point about this JNI function is that it's not clear (to me anyway) how it should behave when there isn't a VM. I think HotSpot currently returns JNI_OK and sets *nVMs to 0 (if non-NULL). Assuming the JNI spec is clarified to specify existing behavior then passing the parameter as NULL just doesn't make sense, meaning JNI_OK does not imply that vmBuf[0] is valid. -Alan. From kumar.x.srinivasan at oracle.COM Mon May 7 15:45:27 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Mon, 07 May 2012 08:45:27 -0700 Subject: Pass a pointer to JNI_GetCreatedJavaVMs() instead of null In-Reply-To: <4FA7A66C.2000206@oracle.com> References: <4FA79826.2030900@linux.vnet.ibm.com> <4FA7A66C.2000206@oracle.com> Message-ID: <4FA7EE17.5050802@oracle.COM> Hi David, Deven, Alan, > The spec doesn't say anything but the implementation does check for > NULL. I think this is a spec issue rather than a code issue (and I > think hotspot-runtime owns the JNI spec so cc'ed). It is common > practice for API's that take pointers like this to say "if buf is not > NULL then the value of XXX is written into buf". Particularly as in > this case there will only ever be at most 1 VM created per-process > anyway. > > I'm more concerned about the fact that the code doesn't even check if > JNI_GetCreatedVMs returns successfully! Ouch!, I will file a CR and fix this. Kumar > > David > ----- > >> I think it is more reasonable to change null to an integer variable. >> Here is my fix[2] >> >> [1] >> http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/invocation.html#wp633 >> >> >> >> [2] http://cr.openjdk.java.net/~littlee/ojdk-432/webrev.00/ >> >> >> >> Please review this mail! >> >> Thanks a lot! >> From Alan.Bateman at oracle.com Mon May 7 15:53:36 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 07 May 2012 16:53:36 +0100 Subject: Pass a pointer to JNI_GetCreatedJavaVMs() instead of null In-Reply-To: <4FA7EE17.5050802@oracle.COM> References: <4FA79826.2030900@linux.vnet.ibm.com> <4FA7A66C.2000206@oracle.com> <4FA7EE17.5050802@oracle.COM> Message-ID: <4FA7F000.3040902@oracle.com> On 07/05/2012 16:45, Kumar Srinivasan wrote: > Hi David, Deven, Alan, >> The spec doesn't say anything but the implementation does check for >> NULL. I think this is a spec issue rather than a code issue (and I >> think hotspot-runtime owns the JNI spec so cc'ed). It is common >> practice for API's that take pointers like this to say "if buf is not >> NULL then the value of XXX is written into buf". Particularly as in >> this case there will only ever be at most 1 VM created per-process >> anyway. >> >> I'm more concerned about the fact that the code doesn't even check if >> JNI_GetCreatedVMs returns successfully! > > Ouch!, I will file a CR and fix this. I think HotSpot can only ever return JNI_OK so it may only be a potential issue when running with another VM. -Alan From olivier.lagneau at oracle.com Mon May 7 16:30:58 2012 From: olivier.lagneau at oracle.com (Olivier Lagneau) Date: Mon, 07 May 2012 18:30:58 +0200 Subject: Review Request for CR : 7144861 RMI activation tests are too slow In-Reply-To: <4FA48780.3030901@oracle.com> References: <4FA28399.9000601@oracle.com> <4FA2C605.7010908@oracle.com> <4FA48780.3030901@oracle.com> Message-ID: <4FA7F8C2.1000108@oracle.com> Hi Stuart, Thanks for reviewing. Please see comments inlined. Stuart Marks said on date 5/5/2012 3:50 AM: > On 5/3/12 10:53 AM, Alan Bateman wrote: >> On 03/05/2012 14:09, Olivier Lagneau wrote: >>> Please review this fix for making the jdk regression tests for rmi >>> activation >>> run faster. >>> It brings a near to x2 speed factor on a Solaris/SPARC machine. >>> >>> The webrev for the fix is here: >>> http://cr.openjdk.java.net/~olagneau/7144861/webrev.00/ >> It's great to see patches like this, thank you! The RMI tests have >> always been >> really slow, the activation tests in particular so I'm looking >> forward to >> seeing this patch go in. I'm also looking forward to trying it out in >> conjunction with Darryl Mocek's patch as the combined patches should >> mean we >> get much better overall through-put. >> >> I think Stuart is going to do the detailed review and help you get >> this over >> the finish line. I've just scanned the webrev (I didn't do a detailed >> review) >> and I didn't see anything obviously wrong, looks like the changes are >> in the >> right places. > > Yes, good stuff. The tests don't get nearly enough maintenance, and a > 2x speedup just by managing timeouts better is great. > > A few relatively minor comments. > > ActivationLibrary.java -- > > If we catch an InterruptedException while sleeping, we reassert the > interrupt bit by interrupting the current thread. This is usually good > practice. In this case though we go around the loop again, retry, and > sleep again. But if we call sleep() when the interrupt bit is set, it > returns immediately. As it stands, after being interrupted, this code > will retry a bunch of times effectively without sleeping and will then > return false. > > I guess if we're going to go to the trouble of reasserting the > interrupt bit we might as well return false immediately. Guess you are mentioning rmidRunning() method. You are right, reasserting the interrupt should not be done. My mistake. But I think we should just ignore the InterruptedException and just move on next loop, I could not find any other thread that may interrupt that one, neither in the testlibrary, nor in all rmi tests. > > JavaVM.java -- > > The started() method is synchronized because it needs to set shared > state (the started field) from another thread. However, code here uses > the started field without any synchronization. Since the state is just > a boolean probably the easiest thing to do is to is to make it > volatile, in which case the started() method doesn't need to be > synchronized. Right. I will just use a volatile instead. Cleaner and simpler. > > The maxTrials variable isn't actually the maximum number of trials, > it's the current number of trials. A small thing but it would be good > if it were renamed. Sorry for that unnoticed misnaming. will fix it. > > Urgh. The addOptions/addArguments methods concatenate all the > arguments and options into a single string, and then the start() > method tokenizes them out again into an array of strings. Heaven > forbid somebody pass a filename with a space. I don't expect you to > fix this. I just had to say something. :-( +1 ;-) As I said in the request mail. I just did not want to fix the rmi+testlibrary code. I have noticed many places where the code is not clean. In an ideal world, an overall cleanup of all this code would be needed. I did not fix the bad things I found because I did not want to mix the fix with cleanup. > > RMID.java -- > > In the start() method, as before, the thread is reasserting the > interrupt bit on itself when it's interrupted. If it does this it > should just return immediately, otherwise it will spin around the loop > without sleeping until waitTime gets to zero. Agreed. In this case I just wanted to minimize changes and kept that interrupt reassert. For the same reason as before, I think we can just ignore it. > > I observe that the timer loop in start() doesn't necessarily wait for > an accurate amount of time, as sleep() can return early or late. There > are better techniques for dealing with this, but it's not clear to me > it's worth rewriting the code. This is something to bear in mind when > writing more time-critical code, however. Thanks for the remark. Guess the problem is the same for all usage of sleep in loops. > > In destroy() I see that the maxTrials variable here really is the > maximum number of trials, which is good. :-) I am usually trying to avoid misnaming of identifier ;-) > > The timing loop here suffers from similar problems as the above. I > mean, it mostly works, but it could probably be simplified by calling > vm.waitFor() and having a task interrupt that call after a timeout > period. But it's probably not worth rewriting at this point. Agreed for the two. > > * * * > > So, overall I'd like to see the interrupt handling changed and the > started field made volatile and maxTrials renamed in JavaVM.java. The > other issues probably should be taken care of at some point at some > point in the future; I think we all want the benefits of faster tests > now! :-) Ok. will fix all of asap. Hope to have another webrev Wednesday morning pdt (public holiday tomorrow). Thanks, Olivier. From olivier.lagneau at oracle.com Mon May 7 17:35:09 2012 From: olivier.lagneau at oracle.com (Olivier Lagneau) Date: Mon, 07 May 2012 19:35:09 +0200 Subject: Review Request for CR : 7144861 RMI activation tests are too slow In-Reply-To: <4FA66ED3.7030209@oracle.com> References: <4FA28399.9000601@oracle.com> <4FA2C605.7010908@oracle.com> <4FA48780.3030901@oracle.com> <4FA66ED3.7030209@oracle.com> Message-ID: <4FA807CD.1050906@oracle.com> Thanks david for reviewing too. Please see comments inlined. David Holmes said on date 5/6/2012 2:30 PM: > On 5/05/2012 11:50 AM, Stuart Marks wrote: >>> On 03/05/2012 14:09, Olivier Lagneau wrote: >>>> Please review this fix for making the jdk regression tests for rmi >>>> activation >>>> run faster. >>>> It brings a near to x2 speed factor on a Solaris/SPARC machine. >>>> >>>> The webrev for the fix is here: >>>> http://cr.openjdk.java.net/~olagneau/7144861/webrev.00/ >> ActivationLibrary.java -- >> >> If we catch an InterruptedException while sleeping, we reassert the >> interrupt bit by interrupting the current thread. This is usually good >> practice. In this case though we go around the loop again, retry, and >> sleep again. But if we call sleep() when the interrupt bit is set, it >> returns immediately. As it stands, after being interrupted, this code >> will retry a bunch of times effectively without sleeping and will then >> return false. >> >> I guess if we're going to go to the trouble of reasserting the interrupt >> bit we might as well return false immediately. > > Does anything in this testing framework actually interrupt any > threads? Elsewhere in this test the interrupt, should it be possible, > just skips to the next loop iteration without being re-asserted. So > either we need to re-assert always or never - and I suspect never. Agreed. I think we should just ignore these interrupts since I don't think any rmi test of code in framework might interrupts threads running that code. So thin we never need to re-assert. > >> JavaVM.java -- >> >> The started() method is synchronized because it needs to set shared >> state (the started field) from another thread. However, code here uses >> the started field without any synchronization. Since the state is just a >> boolean probably the easiest thing to do is to is to make it volatile, >> in which case the started() method doesn't need to be synchronized. > > And naming wise setStarted() would be better than started() IMHO. Ok. I will go for volatile field however. Thanks, Olivier. > > David > ----- > > >> The maxTrials variable isn't actually the maximum number of trials, it's >> the current number of trials. A small thing but it would be good if it >> were renamed. >> >> Urgh. The addOptions/addArguments methods concatenate all the arguments >> and options into a single string, and then the start() method tokenizes >> them out again into an array of strings. Heaven forbid somebody pass a >> filename with a space. I don't expect you to fix this. I just had to say >> something. :-( >> >> RMID.java -- >> >> In the start() method, as before, the thread is reasserting the >> interrupt bit on itself when it's interrupted. If it does this it should >> just return immediately, otherwise it will spin around the loop without >> sleeping until waitTime gets to zero. >> >> I observe that the timer loop in start() doesn't necessarily wait for an >> accurate amount of time, as sleep() can return early or late. There are >> better techniques for dealing with this, but it's not clear to me it's >> worth rewriting the code. This is something to bear in mind when writing >> more time-critical code, however. >> >> In destroy() I see that the maxTrials variable here really is the >> maximum number of trials, which is good. :-) >> >> The timing loop here suffers from similar problems as the above. I mean, >> it mostly works, but it could probably be simplified by calling >> vm.waitFor() and having a task interrupt that call after a timeout >> period. But it's probably not worth rewriting at this point. >> >> * * * >> >> So, overall I'd like to see the interrupt handling changed and the >> started field made volatile and maxTrials renamed in JavaVM.java. The >> other issues probably should be taken care of at some point at some >> point in the future; I think we all want the benefits of faster tests >> now! :-) >> >> Thanks. >> >> s'marks From kumar.x.srinivasan at oracle.COM Mon May 7 20:21:03 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Mon, 07 May 2012 13:21:03 -0700 Subject: Pass a pointer to JNI_GetCreatedJavaVMs() instead of null / review please In-Reply-To: <4FA7F000.3040902@oracle.com> References: <4FA79826.2030900@linux.vnet.ibm.com> <4FA7A66C.2000206@oracle.com> <4FA7EE17.5050802@oracle.COM> <4FA7F000.3040902@oracle.com> Message-ID: <4FA82EAF.206@oracle.COM> Hi, Please review http://cr.openjdk.java.net/~ksrini/7166955 Thanks Kumar > On 07/05/2012 16:45, Kumar Srinivasan wrote: >> Hi David, Deven, Alan, >>> The spec doesn't say anything but the implementation does check for >>> NULL. I think this is a spec issue rather than a code issue (and I >>> think hotspot-runtime owns the JNI spec so cc'ed). It is common >>> practice for API's that take pointers like this to say "if buf is >>> not NULL then the value of XXX is written into buf". Particularly as >>> in this case there will only ever be at most 1 VM created >>> per-process anyway. >>> >>> I'm more concerned about the fact that the code doesn't even check >>> if JNI_GetCreatedVMs returns successfully! >> >> Ouch!, I will file a CR and fix this. > I think HotSpot can only ever return JNI_OK so it may only be a > potential issue when running with another VM. > > -Alan From vitalyd at gmail.com Mon May 7 21:16:46 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 7 May 2012 17:16:46 -0400 Subject: Pass a pointer to JNI_GetCreatedJavaVMs() instead of null / review please In-Reply-To: <4FA82EAF.206@oracle.COM> References: <4FA79826.2030900@linux.vnet.ibm.com> <4FA7A66C.2000206@oracle.com> <4FA7EE17.5050802@oracle.COM> <4FA7F000.3040902@oracle.com> <4FA82EAF.206@oracle.COM> Message-ID: Hi Kumar, Based on the discussion, should it check for a (retval != JNI_OK || vm == null) instead of (retval < 0 || vm == null)? Regards, Vitaly Sent from my phone On May 7, 2012 4:23 PM, "Kumar Srinivasan" wrote: > Hi, > > Please review > > http://cr.openjdk.java.net/~**ksrini/7166955 > > > Thanks > Kumar > > On 07/05/2012 16:45, Kumar Srinivasan wrote: >> >>> Hi David, Deven, Alan, >>> >>>> The spec doesn't say anything but the implementation does check for >>>> NULL. I think this is a spec issue rather than a code issue (and I think >>>> hotspot-runtime owns the JNI spec so cc'ed). It is common practice for >>>> API's that take pointers like this to say "if buf is not NULL then the >>>> value of XXX is written into buf". Particularly as in this case there will >>>> only ever be at most 1 VM created per-process anyway. >>>> >>>> I'm more concerned about the fact that the code doesn't even check if >>>> JNI_GetCreatedVMs returns successfully! >>>> >>> >>> Ouch!, I will file a CR and fix this. >>> >> I think HotSpot can only ever return JNI_OK so it may only be a potential >> issue when running with another VM. >> >> -Alan >> > > From kumar.x.srinivasan at oracle.COM Mon May 7 21:32:55 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Mon, 07 May 2012 14:32:55 -0700 Subject: Pass a pointer to JNI_GetCreatedJavaVMs() instead of null / review please In-Reply-To: References: <4FA79826.2030900@linux.vnet.ibm.com> <4FA7A66C.2000206@oracle.com> <4FA7EE17.5050802@oracle.COM> <4FA7F000.3040902@oracle.com> <4FA82EAF.206@oracle.COM> Message-ID: <4FA83F87.9030704@oracle.COM> Hi Vitaly, The JNI Spec says the following: "Returns |JNI_OK| on success; returns a suitable JNI error code (a negative number) on failure." It doesn't really matter, if others feel strongly about it, I will change it. Kumar > Hi Kumar, > > Based on the discussion, should it check for a (retval != JNI_OK || vm > == null) instead of (retval < 0 || vm == null)? > > Regards, > Vitaly > > Sent from my phone > > On May 7, 2012 4:23 PM, "Kumar Srinivasan" > > > wrote: > > Hi, > > Please review > > http://cr.openjdk.java.net/~ksrini/7166955 > > > > Thanks > Kumar > > On 07/05/2012 16:45, Kumar Srinivasan wrote: > > Hi David, Deven, Alan, > > The spec doesn't say anything but the implementation > does check for NULL. I think this is a spec issue > rather than a code issue (and I think hotspot-runtime > owns the JNI spec so cc'ed). It is common practice for > API's that take pointers like this to say "if buf is > not NULL then the value of XXX is written into buf". > Particularly as in this case there will only ever be > at most 1 VM created per-process anyway. > > I'm more concerned about the fact that the code > doesn't even check if JNI_GetCreatedVMs returns > successfully! > > > Ouch!, I will file a CR and fix this. > > I think HotSpot can only ever return JNI_OK so it may only be > a potential issue when running with another VM. > > -Alan > > From vitalyd at gmail.com Mon May 7 21:52:47 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 7 May 2012 17:52:47 -0400 Subject: Pass a pointer to JNI_GetCreatedJavaVMs() instead of null / review please In-Reply-To: <4FA83F87.9030704@oracle.COM> References: <4FA79826.2030900@linux.vnet.ibm.com> <4FA7A66C.2000206@oracle.com> <4FA7EE17.5050802@oracle.COM> <4FA7F000.3040902@oracle.com> <4FA82EAF.206@oracle.COM> <4FA83F87.9030704@oracle.COM> Message-ID: I agree it doesn't really matter; using JNI_OK is arguably slightly better as it (1) doesn't assume anything about what non negative value it'll assume and (2) uses the constant defined specifically for this, but I agree it's insignificant in the grand scheme of things. Cheers Sent from my phone On May 7, 2012 5:34 PM, "Kumar Srinivasan" wrote: > Hi Vitaly, > > The JNI Spec says the following: > > "Returns JNI_OK on success; returns a suitable JNI error code (a negative > number) on failure." > > It doesn't really matter, if others feel strongly about it, I will change > it. > > Kumar > > > Hi Kumar, > > Based on the discussion, should it check for a (retval != JNI_OK || vm == > null) instead of (retval < 0 || vm == null)? > > Regards, > Vitaly > > Sent from my phone > On May 7, 2012 4:23 PM, "Kumar Srinivasan" > wrote: > >> Hi, >> >> Please review >> >> http://cr.openjdk.java.net/~ksrini/7166955 >> >> >> Thanks >> Kumar >> >> On 07/05/2012 16:45, Kumar Srinivasan wrote: >>> >>>> Hi David, Deven, Alan, >>>> >>>>> The spec doesn't say anything but the implementation does check for >>>>> NULL. I think this is a spec issue rather than a code issue (and I think >>>>> hotspot-runtime owns the JNI spec so cc'ed). It is common practice for >>>>> API's that take pointers like this to say "if buf is not NULL then the >>>>> value of XXX is written into buf". Particularly as in this case there will >>>>> only ever be at most 1 VM created per-process anyway. >>>>> >>>>> I'm more concerned about the fact that the code doesn't even check if >>>>> JNI_GetCreatedVMs returns successfully! >>>>> >>>> >>>> Ouch!, I will file a CR and fix this. >>>> >>> I think HotSpot can only ever return JNI_OK so it may only be a >>> potential issue when running with another VM. >>> >>> -Alan >>> >> >> > From stuart.marks at oracle.com Mon May 7 22:29:13 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 07 May 2012 15:29:13 -0700 Subject: Review Request for CR : 7144861 RMI activation tests are too slow In-Reply-To: <4FA807CD.1050906@oracle.com> References: <4FA28399.9000601@oracle.com> <4FA2C605.7010908@oracle.com> <4FA48780.3030901@oracle.com> <4FA66ED3.7030209@oracle.com> <4FA807CD.1050906@oracle.com> Message-ID: <4FA84CB9.6010606@oracle.com> Hi Olivier, I think we agree that there's a lot more cleanup that could be done here, but that we should just press forward with this and postpone the cleanup until later. I don't really like postponing things but I don't want to hold up the nice optimizations you've done. I do have one point to resolve, however, regarding InterruptedException: On 5/7/12 10:35 AM, Olivier Lagneau wrote: > David Holmes said on date 5/6/2012 2:30 PM: >> On 5/05/2012 11:50 AM, Stuart Marks wrote: >>> If we catch an InterruptedException while sleeping, we reassert the >>> interrupt bit by interrupting the current thread. This is usually good >>> practice. In this case though we go around the loop again, retry, and >>> sleep again. But if we call sleep() when the interrupt bit is set, it >>> returns immediately. As it stands, after being interrupted, this code >>> will retry a bunch of times effectively without sleeping and will then >>> return false. >>> >>> I guess if we're going to go to the trouble of reasserting the interrupt >>> bit we might as well return false immediately. >> >> Does anything in this testing framework actually interrupt any threads? >> Elsewhere in this test the interrupt, should it be possible, just skips to >> the next loop iteration without being re-asserted. So either we need to >> re-assert always or never - and I suspect never. > Agreed. I think we should just ignore these interrupts since I don't think any > rmi test of code in framework > might interrupts threads running that code. So thin we never need to re-assert. There are several places in the existing code where it catches IE and re-asserts the interrupt bit. This makes sense for cases like ActivationLibrary.safeDestroy() where the only thing it can do is return (i.e., there's no loop here). The caller can distinguish the interrupted case from the normal case by checking the thread's interrupt bit. In other cases the existing code catches IE and either continues around the loop (ActivationLibrary.deactivate) or reasserts the interrupt bit before continuing around the loop (e.g., RMID.start). I think both of these are wrong. Basically these loops are waiting for something to happen. If the code gets an IE it should terminate the loop. The only question in my mind is whether it should reassert the interrupt bit before doing so. David, I know you know this stuff pretty well, what do you think? Offhand I don't know whether this test framework uses interruption or not. If it doesn't, it seems reasonable that it might be added in the future. It just bugs me that there's code to catch IE that just ignores it. I don't think we should go out of our way to do something special in the case of IE, but returning or breaking out of the loop instead of ignoring IE seems pretty sensible. BTW a good background article on threads and interrupts is here: [1]. s'marks [1] http://www.ibm.com/developerworks/java/library/j-jtp05236/index.html From david.holmes at oracle.com Tue May 8 03:06:52 2012 From: david.holmes at oracle.com (David Holmes) Date: Tue, 08 May 2012 13:06:52 +1000 Subject: Pass a pointer to JNI_GetCreatedJavaVMs() instead of null / review please In-Reply-To: <4FA82EAF.206@oracle.COM> References: <4FA79826.2030900@linux.vnet.ibm.com> <4FA7A66C.2000206@oracle.com> <4FA7EE17.5050802@oracle.COM> <4FA7F000.3040902@oracle.com> <4FA82EAF.206@oracle.COM> Message-ID: <4FA88DCC.4050508@oracle.com> Hi Kumar, On 8/05/2012 6:21 AM, Kumar Srinivasan wrote: > Hi, > > Please review > > http://cr.openjdk.java.net/~ksrini/7166955 Thanks for jumping on checking the return value. Actually hotspot can never return an error here so it was much less of an issue than I thought. David ----- > > Thanks > Kumar > >> On 07/05/2012 16:45, Kumar Srinivasan wrote: >>> Hi David, Deven, Alan, >>>> The spec doesn't say anything but the implementation does check for >>>> NULL. I think this is a spec issue rather than a code issue (and I >>>> think hotspot-runtime owns the JNI spec so cc'ed). It is common >>>> practice for API's that take pointers like this to say "if buf is >>>> not NULL then the value of XXX is written into buf". Particularly as >>>> in this case there will only ever be at most 1 VM created >>>> per-process anyway. >>>> >>>> I'm more concerned about the fact that the code doesn't even check >>>> if JNI_GetCreatedVMs returns successfully! >>> >>> Ouch!, I will file a CR and fix this. >> I think HotSpot can only ever return JNI_OK so it may only be a >> potential issue when running with another VM. >> >> -Alan > From david.holmes at oracle.com Tue May 8 03:14:33 2012 From: david.holmes at oracle.com (David Holmes) Date: Tue, 08 May 2012 13:14:33 +1000 Subject: Pass a pointer to JNI_GetCreatedJavaVMs() instead of null In-Reply-To: <4FA7CDCF.2070005@oracle.com> References: <4FA79826.2030900@linux.vnet.ibm.com> <4FA7A66C.2000206@oracle.com> <4FA7CDCF.2070005@oracle.com> Message-ID: <4FA88F99.3060705@oracle.com> On 7/05/2012 11:27 PM, Alan Bateman wrote: > On 07/05/2012 11:39, David Holmes wrote: >> >> The spec doesn't say anything but the implementation does check for >> NULL. I think this is a spec issue rather than a code issue (and I >> think hotspot-runtime owns the JNI spec so cc'ed). It is common >> practice for API's that take pointers like this to say "if buf is not >> NULL then the value of XXX is written into buf". Particularly as in >> this case there will only ever be at most 1 VM created per-process >> anyway. >> >> I'm more concerned about the fact that the code doesn't even check if >> JNI_GetCreatedVMs returns successfully! > I agree that the JNI spec needs clarification and it would be > inconsistent if this function didn't allow this parameter to be NULL. In > addition it would be incompatible change (and would likely break > existing code) if the spec were clarified to disallow NULL. > > Another point about this JNI function is that it's not clear (to me > anyway) how it should behave when there isn't a VM. I think HotSpot > currently returns JNI_OK and sets *nVMs to 0 (if non-NULL). Assuming the > JNI spec is clarified to specify existing behavior then passing the > parameter as NULL just doesn't make sense, meaning JNI_OK does not imply > that vmBuf[0] is valid. I think it is clear that if there are no VMs then *nVMs is set to zero and JNI_OK is returned. So any code calling this that isn't bothering to ask for the number of VMs is assuming there is at least one based on the previous actions of the code. Seems to be a no-win situation from the spec side. Allowing NULL in the spec encourages people to not check the value. Disallowing NULL in the spec breaks backward compatibility. With that in mind Kumar's proposed extension to Deven's fix would seem the best way forward. Though perhaps with the additional check that nVMs == 1. David ----- > -Alan. From david.holmes at oracle.com Tue May 8 05:32:02 2012 From: david.holmes at oracle.com (David Holmes) Date: Tue, 08 May 2012 15:32:02 +1000 Subject: Review Request for CR : 7144861 RMI activation tests are too slow In-Reply-To: <4FA84CB9.6010606@oracle.com> References: <4FA28399.9000601@oracle.com> <4FA2C605.7010908@oracle.com> <4FA48780.3030901@oracle.com> <4FA66ED3.7030209@oracle.com> <4FA807CD.1050906@oracle.com> <4FA84CB9.6010606@oracle.com> Message-ID: <4FA8AFD2.5090004@oracle.com> On 8/05/2012 8:29 AM, Stuart Marks wrote: > I think we agree that there's a lot more cleanup that could be done > here, but that we should just press forward with this and postpone the > cleanup until later. I don't really like postponing things but I don't > want to hold up the nice optimizations you've done. Right - some things take too much cleaning :) > I do have one point to resolve, however, regarding InterruptedException: > > On 5/7/12 10:35 AM, Olivier Lagneau wrote: >> David Holmes said on date 5/6/2012 2:30 PM: >>> On 5/05/2012 11:50 AM, Stuart Marks wrote: >>>> If we catch an InterruptedException while sleeping, we reassert the >>>> interrupt bit by interrupting the current thread. This is usually good >>>> practice. In this case though we go around the loop again, retry, and >>>> sleep again. But if we call sleep() when the interrupt bit is set, it >>>> returns immediately. As it stands, after being interrupted, this code >>>> will retry a bunch of times effectively without sleeping and will then >>>> return false. >>>> >>>> I guess if we're going to go to the trouble of reasserting the >>>> interrupt >>>> bit we might as well return false immediately. >>> >>> Does anything in this testing framework actually interrupt any threads? >>> Elsewhere in this test the interrupt, should it be possible, just >>> skips to >>> the next loop iteration without being re-asserted. So either we need to >>> re-assert always or never - and I suspect never. >> Agreed. I think we should just ignore these interrupts since I don't >> think any >> rmi test of code in framework >> might interrupts threads running that code. So thin we never need to >> re-assert. > > There are several places in the existing code where it catches IE and > re-asserts the interrupt bit. This makes sense for cases like > ActivationLibrary.safeDestroy() where the only thing it can do is return > (i.e., there's no loop here). The caller can distinguish the interrupted > case from the normal case by checking the thread's interrupt bit. > > In other cases the existing code catches IE and either continues around > the loop (ActivationLibrary.deactivate) or reasserts the interrupt bit > before continuing around the loop (e.g., RMID.start). I think both of > these are wrong. Basically these loops are waiting for something to > happen. If the code gets an IE it should terminate the loop. The only > question in my mind is whether it should reassert the interrupt bit > before doing so. > > David, I know you know this stuff pretty well, what do you think? As a general principle library code that catches IE and doesn't rethrow it should re-assert the interrupt state. But this isn't library code it is a stand-alone test framework as I understand it. So if the framework doesn't use interruption at all then the response is somewhat arbitrary. As you point out this code is all over the place with regard to IE handling at present. The clean solution would assume interrupts were used to signify cancellation and code accordingly, but doing that consistently all through may be a larger cleanup than Olivier wants to try now. David ----- > Offhand I don't know whether this test framework uses interruption or > not. If it doesn't, it seems reasonable that it might be added in the > future. It just bugs me that there's code to catch IE that just ignores > it. I don't think we should go out of our way to do something special in > the case of IE, but returning or breaking out of the loop instead of > ignoring IE seems pretty sensible. > > BTW a good background article on threads and interrupts is here: [1]. > > s'marks > > > [1] http://www.ibm.com/developerworks/java/library/j-jtp05236/index.html > From david.holmes at oracle.com Tue May 8 07:36:44 2012 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Tue, 08 May 2012 07:36:44 +0000 Subject: hg: jdk8/tl/jdk: 7103570: AtomicIntegerFieldUpdater does not work when SecurityManager is installed Message-ID: <20120508073706.E5A36471B4@hg.openjdk.java.net> Changeset: 48513d156965 Author: dholmes Date: 2012-05-08 02:59 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/48513d156965 7103570: AtomicIntegerFieldUpdater does not work when SecurityManager is installed Summary: Perform class.getField inside a doPrivileged block Reviewed-by: chegar, psandoz ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java + test/java/util/concurrent/atomic/AtomicUpdaters.java From Alan.Bateman at oracle.com Tue May 8 08:28:12 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 08 May 2012 09:28:12 +0100 Subject: Pass a pointer to JNI_GetCreatedJavaVMs() instead of null In-Reply-To: <4FA88F99.3060705@oracle.com> References: <4FA79826.2030900@linux.vnet.ibm.com> <4FA7A66C.2000206@oracle.com> <4FA7CDCF.2070005@oracle.com> <4FA88F99.3060705@oracle.com> Message-ID: <4FA8D91C.9080001@oracle.com> On 08/05/2012 04:14, David Holmes wrote: > > I think it is clear that if there are no VMs then *nVMs is set to zero > and JNI_OK is returned. I don't think it is clear and it should be made explicit in the spec. BTW: Did you create a bug for the JNI spec work? I'll create one if you haven't I just want to make sure that it isn't forgotten. -Alan From Alan.Bateman at oracle.com Tue May 8 08:29:27 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 08 May 2012 09:29:27 +0100 Subject: Pass a pointer to JNI_GetCreatedJavaVMs() instead of null / review please In-Reply-To: <4FA82EAF.206@oracle.COM> References: <4FA79826.2030900@linux.vnet.ibm.com> <4FA7A66C.2000206@oracle.com> <4FA7EE17.5050802@oracle.COM> <4FA7F000.3040902@oracle.com> <4FA82EAF.206@oracle.COM> Message-ID: <4FA8D967.5060900@oracle.com> On 07/05/2012 21:21, Kumar Srinivasan wrote: > Hi, > > Please review > > http://cr.openjdk.java.net/~ksrini/7166955 I think the check needs to be: if (retval < 0 || nVM != 1) (checking if retval == JNI_OK is okay too but amounts to the same thing). -Alan From Ulf.Zibis at gmx.de Tue May 8 10:02:51 2012 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 08 May 2012 12:02:51 +0200 Subject: hg: jdk8/tl/jdk: 7103570: AtomicIntegerFieldUpdater does not work when SecurityManager is installed In-Reply-To: <20120508073706.E5A36471B4@hg.openjdk.java.net> References: <20120508073706.E5A36471B4@hg.openjdk.java.net> Message-ID: <4FA8EF4B.5070508@gmx.de> Hi all, I'm a little bit late, but I just have seen: (1) some indentations in the patch are broken (2) following code snipped is repeated many times: + ClassLoader cl = tclass.getClassLoader(); + ClassLoader ccl = caller.getClassLoader(); + if ((ccl != null) && (ccl != cl) && + ((cl == null) || !isAncestor(cl, ccl))) { + sun.reflect.misc.ReflectUtil.checkPackageAccess(tclass); + } Wouldn't it be better, to move it in a method, maybe in sun.reflect.misc.ReflectUtil ? -Ulf Am 08.05.2012 09:36, schrieb david.holmes at oracle.com: > Changeset: 48513d156965 > Author: dholmes > Date: 2012-05-08 02:59 -0400 > URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/48513d156965 > > 7103570: AtomicIntegerFieldUpdater does not work when SecurityManager is installed > Summary: Perform class.getField inside a doPrivileged block > Reviewed-by: chegar, psandoz > > ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java > ! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java > ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java > + test/java/util/concurrent/atomic/AtomicUpdaters.java > > From david.holmes at oracle.com Tue May 8 10:22:24 2012 From: david.holmes at oracle.com (David Holmes) Date: Tue, 08 May 2012 20:22:24 +1000 Subject: hg: jdk8/tl/jdk: 7103570: AtomicIntegerFieldUpdater does not work when SecurityManager is installed In-Reply-To: <4FA8EF4B.5070508@gmx.de> References: <20120508073706.E5A36471B4@hg.openjdk.java.net> <4FA8EF4B.5070508@gmx.de> Message-ID: <4FA8F3E0.2000604@oracle.com> Hi Ulf, On 8/05/2012 8:02 PM, Ulf Zibis wrote: > Hi all, > > I'm a little bit late, but I just have seen: > (1) some indentations in the patch are broken I missed a couple of indent-2 that should be indent-4. And something went awry with indentation in ensureProtectedAccess. Unfortunately the webrev didn't show this and it isn't code that was functionally modified (I had a tab-to-space conversion issue, which is how this got touched at all). > (2) following code snipped is repeated many times: 4 times. > + ClassLoader cl = tclass.getClassLoader(); > + ClassLoader ccl = caller.getClassLoader(); > + if ((ccl != null) && (ccl != cl) && > + ((cl == null) || !isAncestor(cl, ccl))) { > + sun.reflect.misc.ReflectUtil.checkPackageAccess(tclass); > + } > Wouldn't it be better, to move it in a method, maybe in > sun.reflect.misc.ReflectUtil ? It didn't seem quite worth the effort of factoring out. The isAncestor method is also repeated but again was not considered a worthwhile factorization. Now that I'm writing that I'm having my doubts, but at the time it was expedient. Looking forward this code will likely have to change again to suit a modular world. David ----- > -Ulf > > > Am 08.05.2012 09:36, schrieb david.holmes at oracle.com: >> Changeset: 48513d156965 >> Author: dholmes >> Date: 2012-05-08 02:59 -0400 >> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/48513d156965 >> >> 7103570: AtomicIntegerFieldUpdater does not work when SecurityManager >> is installed >> Summary: Perform class.getField inside a doPrivileged block >> Reviewed-by: chegar, psandoz >> >> ! >> src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java >> >> ! >> src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java >> ! >> src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java >> >> + test/java/util/concurrent/atomic/AtomicUpdaters.java >> >> From david.holmes at oracle.com Tue May 8 10:30:07 2012 From: david.holmes at oracle.com (David Holmes) Date: Tue, 08 May 2012 20:30:07 +1000 Subject: hg: jdk8/tl/jdk: 7103570: AtomicIntegerFieldUpdater does not work when SecurityManager is installed In-Reply-To: <4FA8F3E0.2000604@oracle.com> References: <20120508073706.E5A36471B4@hg.openjdk.java.net> <4FA8EF4B.5070508@gmx.de> <4FA8F3E0.2000604@oracle.com> Message-ID: <4FA8F5AF.1080904@oracle.com> On 8/05/2012 8:22 PM, David Holmes wrote: > > > Hi Ulf, > > On 8/05/2012 8:02 PM, Ulf Zibis wrote: >> Hi all, >> >> I'm a little bit late, but I just have seen: >> (1) some indentations in the patch are broken > > I missed a couple of indent-2 that should be indent-4. > > And something went awry with indentation in ensureProtectedAccess. > Unfortunately the webrev didn't show this and it isn't code that was > functionally modified (I had a tab-to-space conversion issue, which is > how this got touched at all). > >> (2) following code snipped is repeated many times: > > 4 times. > >> + ClassLoader cl = tclass.getClassLoader(); >> + ClassLoader ccl = caller.getClassLoader(); >> + if ((ccl != null) && (ccl != cl) && >> + ((cl == null) || !isAncestor(cl, ccl))) { >> + sun.reflect.misc.ReflectUtil.checkPackageAccess(tclass); >> + } >> Wouldn't it be better, to move it in a method, maybe in >> sun.reflect.misc.ReflectUtil ? > > It didn't seem quite worth the effort of factoring out. > > The isAncestor method is also repeated but again was not considered a > worthwhile factorization. > > Now that I'm writing that I'm having my doubts, but at the time it was > expedient. Looking forward this code will likely have to change again to > suit a modular world. I was forgetting there's another major consideration here too, and that is that this code sync's up with Doug Lea's JSR-166 CVS repository. The changes I made are independent of the JDK used, but if I refactored things into ReflectUtil then the code would only be valid on a JDK with that update - which means Doug would need to maintain a different version of this fix for older JDKs. David ----- > David > ----- > > >> -Ulf >> >> >> Am 08.05.2012 09:36, schrieb david.holmes at oracle.com: >>> Changeset: 48513d156965 >>> Author: dholmes >>> Date: 2012-05-08 02:59 -0400 >>> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/48513d156965 >>> >>> 7103570: AtomicIntegerFieldUpdater does not work when SecurityManager >>> is installed >>> Summary: Perform class.getField inside a doPrivileged block >>> Reviewed-by: chegar, psandoz >>> >>> ! >>> src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java >>> >>> >>> ! >>> src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java >>> >>> ! >>> src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java >>> >>> >>> + test/java/util/concurrent/atomic/AtomicUpdaters.java >>> >>> From chris.hegarty at oracle.com Tue May 8 13:10:42 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 08 May 2012 14:10:42 +0100 Subject: hg: jdk8/tl/jdk: 7103570: AtomicIntegerFieldUpdater does not work when SecurityManager is installed In-Reply-To: <4FA8F5AF.1080904@oracle.com> References: <20120508073706.E5A36471B4@hg.openjdk.java.net> <4FA8EF4B.5070508@gmx.de> <4FA8F3E0.2000604@oracle.com> <4FA8F5AF.1080904@oracle.com> Message-ID: <4FA91B52.7050708@oracle.com> On 08/05/2012 11:30, David Holmes wrote: > .... > > I was forgetting there's another major consideration here too, and that > is that this code sync's up with Doug Lea's JSR-166 CVS repository. The > changes I made are independent of the JDK used, but if I refactored > things into ReflectUtil then the code would only be valid on a JDK with > that update - which means Doug would need to maintain a different > version of this fix for older JDKs. Right, unless there is a good reason we should try not to maintain a separate fork here. Sync'ing is already a pain! -Chris. > > David > ----- > >> David >> ----- >> >> >>> -Ulf >>> >>> >>> Am 08.05.2012 09:36, schrieb david.holmes at oracle.com: >>>> Changeset: 48513d156965 >>>> Author: dholmes >>>> Date: 2012-05-08 02:59 -0400 >>>> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/48513d156965 >>>> >>>> 7103570: AtomicIntegerFieldUpdater does not work when SecurityManager >>>> is installed >>>> Summary: Perform class.getField inside a doPrivileged block >>>> Reviewed-by: chegar, psandoz >>>> >>>> ! >>>> src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java >>>> >>>> >>>> >>>> ! >>>> src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java >>>> >>>> >>>> ! >>>> src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java >>>> >>>> >>>> >>>> + test/java/util/concurrent/atomic/AtomicUpdaters.java >>>> >>>> From kumar.x.srinivasan at oracle.COM Tue May 8 14:25:33 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Tue, 08 May 2012 07:25:33 -0700 Subject: Pass a pointer to JNI_GetCreatedJavaVMs() instead of null / review please In-Reply-To: <4FA8D967.5060900@oracle.com> References: <4FA79826.2030900@linux.vnet.ibm.com> <4FA7A66C.2000206@oracle.com> <4FA7EE17.5050802@oracle.COM> <4FA7F000.3040902@oracle.com> <4FA82EAF.206@oracle.COM> <4FA8D967.5060900@oracle.com> Message-ID: <4FA92CDD.6060700@oracle.COM> Hi Alan, David, Vitaly, Ok I will make these changes and push. Thanks Kumar > On 07/05/2012 21:21, Kumar Srinivasan wrote: >> Hi, >> >> Please review >> >> http://cr.openjdk.java.net/~ksrini/7166955 > I think the check needs to be: > > if (retval < 0 || nVM != 1) > > (checking if retval == JNI_OK is okay too but amounts to the same thing). > > -Alan From Ulf.Zibis at gmx.de Tue May 8 15:03:52 2012 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 08 May 2012 17:03:52 +0200 Subject: hg: jdk8/tl/jdk: 7103570: AtomicIntegerFieldUpdater does not work when SecurityManager is installed In-Reply-To: <4FA8F5AF.1080904@oracle.com> References: <20120508073706.E5A36471B4@hg.openjdk.java.net> <4FA8EF4B.5070508@gmx.de> <4FA8F3E0.2000604@oracle.com> <4FA8F5AF.1080904@oracle.com> Message-ID: <4FA935D8.1000500@gmx.de> Am 08.05.2012 12:30, schrieb David Holmes: > On 8/05/2012 8:22 PM, David Holmes wrote: >> >> >> Hi Ulf, >> >> On 8/05/2012 8:02 PM, Ulf Zibis wrote: >>> Hi all, >>> >>> I'm a little bit late, but I just have seen: >>> (1) some indentations in the patch are broken >> >> I missed a couple of indent-2 that should be indent-4. >> >> And something went awry with indentation in ensureProtectedAccess. >> Unfortunately the webrev didn't show this and it isn't code that was >> functionally modified (I had a tab-to-space conversion issue, which is >> how this got touched at all). Did you also noticed it in test class ? >> >>> (2) following code snipped is repeated many times: >> >> 4 times. >> >>> + ClassLoader cl = tclass.getClassLoader(); >>> + ClassLoader ccl = caller.getClassLoader(); >>> + if ((ccl != null) && (ccl != cl) && >>> + ((cl == null) || !isAncestor(cl, ccl))) { >>> + sun.reflect.misc.ReflectUtil.checkPackageAccess(tclass); >>> + } >>> Wouldn't it be better, to move it in a method, maybe in >>> sun.reflect.misc.ReflectUtil ? >> >> It didn't seem quite worth the effort of factoring out. >> >> The isAncestor method is also repeated but again was not considered a >> worthwhile factorization. >> >> Now that I'm writing that I'm having my doubts, but at the time it was >> expedient. Looking forward this code will likely have to change again to >> suit a modular world. > > I was forgetting there's another major consideration here too, and that is that this code sync's > up with Doug Lea's JSR-166 CVS repository. The changes I made are independent of the JDK used, but > if I refactored things into ReflectUtil then the code would only be valid on a JDK with that > update - which means Doug would need to maintain a different version of this fix for older JDKs. Class ReflectUtil was just a suggestion. as it will be loaded anyway. Looking in detail maybe whole AtomicXyzFieldUpdaterImpl constructors could be factored out. Same for the code snippet: if (obj == null || obj.getClass() != tclass || cclass != null) fullCheck(obj); -Ulf From xueming.shen at oracle.com Tue May 8 17:55:29 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Tue, 08 May 2012 17:55:29 +0000 Subject: hg: jdk8/tl/jdk: 7014640: To add a metachar \R for line ending and character classes for vertical/horizontal ws \v \V \h \H Message-ID: <20120508175547.56E86471C5@hg.openjdk.java.net> Changeset: af209a223b6b Author: sherman Date: 2012-05-08 10:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/af209a223b6b 7014640: To add a metachar \R for line ending and character classes for vertical/horizontal ws \v \V \h \H Summary: added propsoed constructs Reviewed-by: alanb ! src/share/classes/java/util/regex/Pattern.java ! test/java/util/regex/RegExTest.java From xueming.shen at oracle.com Tue May 8 18:14:46 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Tue, 08 May 2012 18:14:46 +0000 Subject: hg: jdk8/tl/jdk: 7157656: (zipfs) SeekableByteChannel to entry in zip file always reports its position as 0 Message-ID: <20120508181456.B16E4471C6@hg.openjdk.java.net> Changeset: 1ece20885be4 Author: sherman Date: 2012-05-08 11:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1ece20885be4 7157656: (zipfs) SeekableByteChannel to entry in zip file always reports its position as 0 Summary: updated SeekableByteChannel.read() to count the bytes read correctly Reviewed-by: sherman Contributed-by: paul.sandoz at oracle.com ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java ! test/demo/zipfs/ZipFSTester.java ! test/demo/zipfs/basic.sh From david.holmes at oracle.com Tue May 8 21:13:26 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 09 May 2012 07:13:26 +1000 Subject: hg: jdk8/tl/jdk: 7103570: AtomicIntegerFieldUpdater does not work when SecurityManager is installed In-Reply-To: <4FA935D8.1000500@gmx.de> References: <20120508073706.E5A36471B4@hg.openjdk.java.net> <4FA8EF4B.5070508@gmx.de> <4FA8F3E0.2000604@oracle.com> <4FA8F5AF.1080904@oracle.com> <4FA935D8.1000500@gmx.de> Message-ID: <4FA98C76.9060906@oracle.com> On 9/05/2012 1:03 AM, Ulf Zibis wrote: > Am 08.05.2012 12:30, schrieb David Holmes: >> On 8/05/2012 8:22 PM, David Holmes wrote: >>> >>> >>> On 8/05/2012 8:02 PM, Ulf Zibis wrote: >>>> >>>> I'm a little bit late, but I just have seen: >>>> (1) some indentations in the patch are broken >>> >>> I missed a couple of indent-2 that should be indent-4. >>> >>> And something went awry with indentation in ensureProtectedAccess. >>> Unfortunately the webrev didn't show this and it isn't code that was >>> functionally modified (I had a tab-to-space conversion issue, which is >>> how this got touched at all). > Did you also noticed it in test class ? I don't see anything wrong in the test class. Indent is 4. ?? >>> >>>> (2) following code snipped is repeated many times: >>> >>> 4 times. >>> >>>> + ClassLoader cl = tclass.getClassLoader(); >>>> + ClassLoader ccl = caller.getClassLoader(); >>>> + if ((ccl != null) && (ccl != cl) && >>>> + ((cl == null) || !isAncestor(cl, ccl))) { >>>> + sun.reflect.misc.ReflectUtil.checkPackageAccess(tclass); >>>> + } >>>> Wouldn't it be better, to move it in a method, maybe in >>>> sun.reflect.misc.ReflectUtil ? >>> >>> It didn't seem quite worth the effort of factoring out. >>> >>> The isAncestor method is also repeated but again was not considered a >>> worthwhile factorization. >>> >>> Now that I'm writing that I'm having my doubts, but at the time it was >>> expedient. Looking forward this code will likely have to change again to >>> suit a modular world. >> >> I was forgetting there's another major consideration here too, and >> that is that this code sync's up with Doug Lea's JSR-166 CVS >> repository. The changes I made are independent of the JDK used, but if >> I refactored things into ReflectUtil then the code would only be valid >> on a JDK with that update - which means Doug would need to maintain a >> different version of this fix for older JDKs. > Class ReflectUtil was just a suggestion. as it will be loaded anyway. > Looking in detail maybe whole AtomicXyzFieldUpdaterImpl constructors > could be factored out. Factored out to where? There's no shared superclass here, so where would it get factored to? > Same for the code snippet: > if (obj == null || obj.getClass() != tclass || cclass != null) > fullCheck(obj); Not part of my changes. David ----- > -Ulf > From Ulf.Zibis at gmx.de Tue May 8 23:57:51 2012 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Wed, 09 May 2012 01:57:51 +0200 Subject: hg: jdk8/tl/jdk: 7103570: AtomicIntegerFieldUpdater does not work when SecurityManager is installed In-Reply-To: <4FA98C76.9060906@oracle.com> References: <20120508073706.E5A36471B4@hg.openjdk.java.net> <4FA8EF4B.5070508@gmx.de> <4FA8F3E0.2000604@oracle.com> <4FA8F5AF.1080904@oracle.com> <4FA935D8.1000500@gmx.de> <4FA98C76.9060906@oracle.com> Message-ID: <4FA9B2FF.9030405@gmx.de> Am 08.05.2012 23:13, schrieb David Holmes: > On 9/05/2012 1:03 AM, Ulf Zibis wrote: >> Did you also noticed it in test class ? > > I don't see anything wrong in the test class. Indent is 4. ?? Oops sorry, I was in wrong line. > >> Class ReflectUtil was just a suggestion. as it will be loaded anyway. >> Looking in detail maybe whole AtomicXyzFieldUpdaterImpl constructors >> could be factored out. > > Factored out to where? There's no shared superclass here, so where would it get factored to? I was thinking, there *could* be a superclass for all of them. -Ulf From xuelei.fan at oracle.com Wed May 9 00:57:37 2012 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Wed, 09 May 2012 00:57:37 +0000 Subject: hg: jdk8/tl/jdk: 7167092: Need to put the return clause in the synchronized block Message-ID: <20120509005747.AADC5471D5@hg.openjdk.java.net> Changeset: fbf98cbd2e6b Author: xuelei Date: 2012-05-08 17:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fbf98cbd2e6b 7167092: Need to put the return clause in the synchronized block Summary: a regression fix for bug 7153184 Reviewed-by: wetmore ! src/share/classes/sun/security/ssl/SSLContextImpl.java From xuelei.fan at oracle.com Wed May 9 01:09:36 2012 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Wed, 09 May 2012 01:09:36 +0000 Subject: hg: jdk8/tl/jdk: 7166570: JSSE certificate validation has started to fail for certificate chains Message-ID: <20120509010947.4AC6B471D8@hg.openjdk.java.net> Changeset: 0f63f3390ac9 Author: xuelei Date: 2012-05-08 18:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0f63f3390ac9 7166570: JSSE certificate validation has started to fail for certificate chains Reviewed-by: wetmore ! src/share/classes/sun/security/validator/SimpleValidator.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/BasicConstraints.java From stuart.marks at oracle.com Wed May 9 02:53:33 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 08 May 2012 19:53:33 -0700 Subject: Review Request for CR : 7144861 RMI activation tests are too slow In-Reply-To: <4FA8AFD2.5090004@oracle.com> References: <4FA28399.9000601@oracle.com> <4FA2C605.7010908@oracle.com> <4FA48780.3030901@oracle.com> <4FA66ED3.7030209@oracle.com> <4FA807CD.1050906@oracle.com> <4FA84CB9.6010606@oracle.com> <4FA8AFD2.5090004@oracle.com> Message-ID: <4FA9DC2D.4030107@oracle.com> On 5/7/12 10:32 PM, David Holmes wrote: > As a general principle library code that catches IE and doesn't rethrow it > should re-assert the interrupt state. > > But this isn't library code it is a stand-alone test framework as I understand > it. So if the framework doesn't use interruption at all then the response is > somewhat arbitrary. As you point out this code is all over the place with > regard to IE handling at present. The clean solution would assume interrupts > were used to signify cancellation and code accordingly, but doing that > consistently all through may be a larger cleanup than Olivier wants to try now. This is indeed test code, but just as library code should be decoupled from the caller, test code should be decoupled from its framework. So I think the general principle applies. I'm not asking that the all code be audited to make sure handles IE properly everywhere. But Olivier's changes did touch some code that handles IE, which naturally raises the question of the proper way to handle IE. Reasserting the interrupt bit and continuing around the loop just causes it to spin until the loop is exhausted, which doesn't seem sensible. Returning early seems sensible. Applying the rule says that the code should reassert the interrupt bit before returning. An alternative would be to have the code rethrow or propagate IE, but this requires additional refactoring and probably adding throws clauses to methods, so it's probably not warranted. My recommendation to Olivier is to run through the files in the changeset and modify the catch blocks as follows: catch (InterruptedException ie) { Thread.currentThread().interrupt(); // maybe print a log message return; // or break, as appropriate } s'marks From littlee at linux.vnet.ibm.com Wed May 9 03:21:27 2012 From: littlee at linux.vnet.ibm.com (littlee at linux.vnet.ibm.com) Date: Wed, 09 May 2012 03:21:27 +0000 Subject: hg: jdk8/tl/jdk: 7165722: Invalid path in MemoryMonitor demo's README.txt Message-ID: <20120509032146.D6D62471DD@hg.openjdk.java.net> Changeset: abb63b7357a1 Author: luchsh Date: 2012-05-09 11:19 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/abb63b7357a1 7165722: Invalid path in MemoryMonitor demo's README.txt Reviewed-by: alanb, sla ! src/share/demo/management/MemoryMonitor/README.txt From david.holmes at oracle.com Wed May 9 03:53:03 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 09 May 2012 13:53:03 +1000 Subject: Review Request for CR : 7144861 RMI activation tests are too slow In-Reply-To: <4FA9DC2D.4030107@oracle.com> References: <4FA28399.9000601@oracle.com> <4FA2C605.7010908@oracle.com> <4FA48780.3030901@oracle.com> <4FA66ED3.7030209@oracle.com> <4FA807CD.1050906@oracle.com> <4FA84CB9.6010606@oracle.com> <4FA8AFD2.5090004@oracle.com> <4FA9DC2D.4030107@oracle.com> Message-ID: <4FA9EA1F.7060103@oracle.com> On 9/05/2012 12:53 PM, Stuart Marks wrote: > On 5/7/12 10:32 PM, David Holmes wrote: >> As a general principle library code that catches IE and doesn't >> rethrow it >> should re-assert the interrupt state. >> >> But this isn't library code it is a stand-alone test framework as I >> understand >> it. So if the framework doesn't use interruption at all then the >> response is >> somewhat arbitrary. As you point out this code is all over the place with >> regard to IE handling at present. The clean solution would assume >> interrupts >> were used to signify cancellation and code accordingly, but doing that >> consistently all through may be a larger cleanup than Olivier wants to >> try now. > > This is indeed test code, but just as library code should be decoupled > from the caller, test code should be decoupled from its framework. So I > think the general principle applies. > > I'm not asking that the all code be audited to make sure handles IE > properly everywhere. But Olivier's changes did touch some code that > handles IE, which naturally raises the question of the proper way to > handle IE. Reasserting the interrupt bit and continuing around the loop > just causes it to spin until the loop is exhausted, which doesn't seem > sensible. Right - that certainly has to be changed. > Returning early seems sensible. Applying the rule says that > the code should reassert the interrupt bit before returning. If interruptible code is looping around an interruptible method that must be re-executed then the usual approach is to re-assert the interrupt outside the loop eg: boolean wasInterrupted = false; while (cond) { try { interruptibleOp(); } catch (InterruptedException ie) { wasInterrupted = true; continue; } } if (wasInterrupted) Thread.currentThread().interrupt(); In this case however this seems more like a fail-fast situation so immediate return seems in order - though the fact the test was interrupted does have to be reported to the test harness somehow. David ----- > An alternative would be to have the code rethrow or propagate IE, but > this requires additional refactoring and probably adding throws clauses > to methods, so it's probably not warranted. > > My recommendation to Olivier is to run through the files in the > changeset and modify the catch blocks as follows: > > catch (InterruptedException ie) { > Thread.currentThread().interrupt(); > // maybe print a log message > return; // or break, as appropriate > } > > s'marks From olivier.lagneau at oracle.com Wed May 9 15:26:27 2012 From: olivier.lagneau at oracle.com (Olivier Lagneau) Date: Wed, 09 May 2012 17:26:27 +0200 Subject: Review Request for CR : 7144861 RMI activation tests are too slow In-Reply-To: <4FA9EA1F.7060103@oracle.com> References: <4FA28399.9000601@oracle.com> <4FA2C605.7010908@oracle.com> <4FA48780.3030901@oracle.com> <4FA66ED3.7030209@oracle.com> <4FA807CD.1050906@oracle.com> <4FA84CB9.6010606@oracle.com> <4FA8AFD2.5090004@oracle.com> <4FA9DC2D.4030107@oracle.com> <4FA9EA1F.7060103@oracle.com> Message-ID: <4FAA8CA3.70502@oracle.com> Hi Stuarts, David, I agree with your arguments/points discussed below. I understand the argument against swallowing or only reasserting the interrupt when catching IE. I have gone again quickly through all the rmi tests and don't think this code takes into account interuption, or intend to manage properly cancellation/termination. Cumulating all the tests case, there is even between 1 and 2 min spent in Thread.sleep() call that are not managed properly (IE mostly swallowed). So IE is not correctly handled in [almost all] these rmi tests. The tests can in addition be run with -samevm option of jtreg, and it is also certainly meaningfull to manage correctly IE in that case too. > On 5/7/12 10:32 PM, David Holmes wrote: > The clean solution would assume interrupts were used to signify > cancellation and code accordingly, > but doing that consistently all through may be a larger cleanup than > Olivier wants to try now. Given that we want to push the code quickly, I don't think I should go for such a large IE cleanup for this fix, which is meant to provide better exceution speed only. I suggest to follow Stuart's proposal first (i.e. reassert and return immediately in my code changes) , and create a dedicated new CR regarding proper handling of IE in all the rmi tests (low priority). Do you agree with this ? Thanks, Olivier. David Holmes said on date 5/9/2012 5:53 AM: > On 9/05/2012 12:53 PM, Stuart Marks wrote: >> On 5/7/12 10:32 PM, David Holmes wrote: >>> As a general principle library code that catches IE and doesn't >>> rethrow it >>> should re-assert the interrupt state. >>> >>> But this isn't library code it is a stand-alone test framework as I >>> understand >>> it. So if the framework doesn't use interruption at all then the >>> response is >>> somewhat arbitrary. As you point out this code is all over the place >>> with >>> regard to IE handling at present. The clean solution would assume >>> interrupts >>> were used to signify cancellation and code accordingly, but doing that >>> consistently all through may be a larger cleanup than Olivier wants to >>> try now. >> >> This is indeed test code, but just as library code should be decoupled >> from the caller, test code should be decoupled from its framework. So I >> think the general principle applies. >> >> I'm not asking that the all code be audited to make sure handles IE >> properly everywhere. But Olivier's changes did touch some code that >> handles IE, which naturally raises the question of the proper way to >> handle IE. Reasserting the interrupt bit and continuing around the loop >> just causes it to spin until the loop is exhausted, which doesn't seem >> sensible. > > Right - that certainly has to be changed. > >> Returning early seems sensible. Applying the rule says that >> the code should reassert the interrupt bit before returning. > > If interruptible code is looping around an interruptible method that > must be re-executed then the usual approach is to re-assert the > interrupt outside the loop eg: > > boolean wasInterrupted = false; > while (cond) { > try { > interruptibleOp(); > } > catch (InterruptedException ie) { > wasInterrupted = true; > continue; > } > } > if (wasInterrupted) > Thread.currentThread().interrupt(); > > In this case however this seems more like a fail-fast situation so > immediate return seems in order - though the fact the test was > interrupted does have to be reported to the test harness somehow. > > David > ----- > >> An alternative would be to have the code rethrow or propagate IE, but >> this requires additional refactoring and probably adding throws clauses >> to methods, so it's probably not warranted. >> >> My recommendation to Olivier is to run through the files in the >> changeset and modify the catch blocks as follows: >> >> catch (InterruptedException ie) { >> Thread.currentThread().interrupt(); >> // maybe print a log message >> return; // or break, as appropriate >> } >> >> s'marks From kumar.x.srinivasan at oracle.COM Wed May 9 15:28:14 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Wed, 09 May 2012 08:28:14 -0700 Subject: Pass a pointer to JNI_GetCreatedJavaVMs() instead of null In-Reply-To: <4FA8D91C.9080001@oracle.com> References: <4FA79826.2030900@linux.vnet.ibm.com> <4FA7A66C.2000206@oracle.com> <4FA7CDCF.2070005@oracle.com> <4FA88F99.3060705@oracle.com> <4FA8D91C.9080001@oracle.com> Message-ID: <4FAA8D0E.3060103@oracle.COM> On 5/8/2012 1:28 AM, Alan Bateman wrote: > On 08/05/2012 04:14, David Holmes wrote: >> >> I think it is clear that if there are no VMs then *nVMs is set to >> zero and JNI_OK is returned. > I don't think it is clear and it should be made explicit in the spec. > > BTW: Did you create a bug for the JNI spec work? I'll create one if > you haven't I just want to make sure that it isn't forgotten. If you are creating a CR please add a ref to 7166955 for the record. one other nit in the spec, it is somewhat confusing the description of bufLen. The "Description" is correct, explicitly it says the number of entries, however the parameter description says: bufLen: the length of the buffer I think this should be explicit as well, and also suggest renaming bufLen to nvmBuf or something along these lines. Kumar > > -Alan From kumar.x.srinivasan at oracle.com Wed May 9 16:29:07 2012 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Wed, 09 May 2012 16:29:07 +0000 Subject: hg: jdk8/tl/jdk: 7166955: (pack200) JNI_GetCreatedJavaVMs needs additional checking Message-ID: <20120509162917.E58A2471F0@hg.openjdk.java.net> Changeset: 5e8caf6984f5 Author: ksrini Date: 2012-05-09 07:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5e8caf6984f5 7166955: (pack200) JNI_GetCreatedJavaVMs needs additional checking Reviewed-by: alanb, dholmes, ksrini Contributed-by: youdwei at linux.vnet.ibm.com ! src/share/native/com/sun/java/util/jar/pack/jni.cpp From kurchi.subhra.hazra at oracle.com Wed May 9 18:15:02 2012 From: kurchi.subhra.hazra at oracle.com (kurchi.subhra.hazra at oracle.com) Date: Wed, 09 May 2012 18:15:02 +0000 Subject: hg: jdk8/tl/jdk: 7165118: (prefs) AbstractPreferences.remove(null) does not throw NPE Message-ID: <20120509181511.CE5FB471F8@hg.openjdk.java.net> Changeset: 59121a4c71c6 Author: khazra Date: 2012-05-09 11:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/59121a4c71c6 7165118: (prefs) AbstractPreferences.remove(null) does not throw NPE Summary: Insert null argument check in AbstractPreferences.remove() Reviewed-by: dholmes, chegar, alanb ! src/share/classes/java/util/prefs/AbstractPreferences.java ! test/java/util/prefs/RemoveNullKeyCheck.java From bradford.wetmore at oracle.com Wed May 9 23:34:25 2012 From: bradford.wetmore at oracle.com (bradford.wetmore at oracle.com) Date: Wed, 09 May 2012 23:34:25 +0000 Subject: hg: jdk8/tl/jdk: 7167362: SecureRandom.init should be converted, amendment to 7084245 Message-ID: <20120509233435.8C5CB47206@hg.openjdk.java.net> Changeset: 6438f1277df6 Author: wetmore Date: 2012-05-09 16:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6438f1277df6 7167362: SecureRandom.init should be converted, amendment to 7084245 Reviewed-by: sherman ! src/share/classes/sun/security/provider/SecureRandom.java From kurchi.subhra.hazra at oracle.com Wed May 9 23:57:06 2012 From: kurchi.subhra.hazra at oracle.com (kurchi.subhra.hazra at oracle.com) Date: Wed, 09 May 2012 23:57:06 +0000 Subject: hg: jdk8/tl/jdk: 7096436: (sc) SocketChannel.connect fails on Windows 8 when channel configured non-blocking Message-ID: <20120509235717.1BB084720C@hg.openjdk.java.net> Changeset: 5152c832745a Author: khazra Date: 2012-05-09 16:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5152c832745a 7096436: (sc) SocketChannel.connect fails on Windows 8 when channel configured non-blocking Summary: Set localAddress only when connection is established Reviewed-by: alanb ! src/share/classes/sun/nio/ch/SocketChannelImpl.java From david.holmes at oracle.com Thu May 10 03:22:50 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 May 2012 13:22:50 +1000 Subject: Review Request for CR : 7144861 RMI activation tests are too slow In-Reply-To: <4FAA8CA3.70502@oracle.com> References: <4FA28399.9000601@oracle.com> <4FA2C605.7010908@oracle.com> <4FA48780.3030901@oracle.com> <4FA66ED3.7030209@oracle.com> <4FA807CD.1050906@oracle.com> <4FA84CB9.6010606@oracle.com> <4FA8AFD2.5090004@oracle.com> <4FA9DC2D.4030107@oracle.com> <4FA9EA1F.7060103@oracle.com> <4FAA8CA3.70502@oracle.com> Message-ID: <4FAB348A.1090106@oracle.com> On 10/05/2012 1:26 AM, Olivier Lagneau wrote: > I suggest to follow Stuart's proposal first (i.e. reassert and return > immediately in my code changes) , > and create a dedicated new CR regarding proper handling of IE in all the > rmi tests (low priority). > Do you agree with this ? Yes. Thanks, David From stuart.marks at oracle.com Thu May 10 04:28:13 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 09 May 2012 21:28:13 -0700 Subject: Review Request for CR : 7144861 RMI activation tests are too slow In-Reply-To: <4FAA8CA3.70502@oracle.com> References: <4FA28399.9000601@oracle.com> <4FA2C605.7010908@oracle.com> <4FA48780.3030901@oracle.com> <4FA66ED3.7030209@oracle.com> <4FA807CD.1050906@oracle.com> <4FA84CB9.6010606@oracle.com> <4FA8AFD2.5090004@oracle.com> <4FA9DC2D.4030107@oracle.com> <4FA9EA1F.7060103@oracle.com> <4FAA8CA3.70502@oracle.com> Message-ID: <4FAB43DD.5060206@oracle.com> On 5/9/12 8:26 AM, Olivier Lagneau wrote: > Given that we want to push the code quickly, I don't think I should go for such > a large IE cleanup for this fix, > which is meant to provide better exceution speed only. > > I suggest to follow Stuart's proposal first (i.e. reassert and return > immediately in my code changes) , > and create a dedicated new CR regarding proper handling of IE in all the rmi > tests (low priority). > Do you agree with this ? Yes, this seems like a sensible approach. The new CR might also cover the cleaning/unification of all the retry-repeatedly-with-time-limit loops that are spread through this code. Thanks. s'marks From sean.coffey at oracle.com Thu May 10 09:43:45 2012 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Thu, 10 May 2012 09:43:45 +0000 Subject: hg: jdk8/tl/jdk: 7163470: Build fails if javax.crypto src files not present Message-ID: <20120510094414.56FE047220@hg.openjdk.java.net> Changeset: fdf5e15293e6 Author: coffeys Date: 2012-05-10 10:45 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fdf5e15293e6 7163470: Build fails if javax.crypto src files not present Reviewed-by: valeriep ! make/com/oracle/security/ucrypto/Makefile ! make/common/shared/Defs-java.gmk ! make/sun/security/ec/Makefile ! make/sun/security/mscapi/Makefile ! make/sun/security/pkcs11/Makefile ! makefiles/com/oracle/security/ucrypto/Makefile ! makefiles/common/shared/Defs-java.gmk ! makefiles/sun/security/ec/Makefile ! makefiles/sun/security/mscapi/Makefile ! makefiles/sun/security/pkcs11/Makefile From valerie.peng at oracle.com Thu May 10 18:40:00 2012 From: valerie.peng at oracle.com (valerie.peng at oracle.com) Date: Thu, 10 May 2012 18:40:00 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20120510184042.669D047234@hg.openjdk.java.net> Changeset: 3e3017eba8ac Author: valeriep Date: 2012-05-08 17:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3e3017eba8ac 4963723: Implement SHA-224 Summary: Add support for SHA-224, SHA224withRSA, SHA224withECDSA, HmacSHA224 and OAEPwithSHA-224AndMGF1Padding. Reviewed-by: vinnie ! src/share/classes/com/sun/crypto/provider/HmacCore.java ! src/share/classes/com/sun/crypto/provider/HmacMD5.java ! src/share/classes/com/sun/crypto/provider/HmacPKCS12PBESHA1.java ! src/share/classes/com/sun/crypto/provider/HmacSHA1.java ! src/share/classes/com/sun/crypto/provider/KeyGeneratorCore.java ! src/share/classes/com/sun/crypto/provider/OAEPParameters.java ! src/share/classes/com/sun/crypto/provider/SunJCE.java ! src/share/classes/java/security/spec/MGF1ParameterSpec.java ! src/share/classes/java/security/spec/PSSParameterSpec.java ! src/share/classes/sun/security/ec/ECDSASignature.java ! src/share/classes/sun/security/ec/SunECEntries.java ! src/share/classes/sun/security/pkcs11/P11Digest.java ! src/share/classes/sun/security/pkcs11/P11Mac.java ! src/share/classes/sun/security/pkcs11/P11Signature.java ! src/share/classes/sun/security/pkcs11/SunPKCS11.java ! src/share/classes/sun/security/pkcs11/wrapper/Functions.java ! src/share/classes/sun/security/provider/DigestBase.java ! src/share/classes/sun/security/provider/MD2.java ! src/share/classes/sun/security/provider/MD4.java ! src/share/classes/sun/security/provider/MD5.java ! src/share/classes/sun/security/provider/SHA.java ! src/share/classes/sun/security/provider/SHA2.java ! src/share/classes/sun/security/provider/SHA5.java ! src/share/classes/sun/security/provider/SunEntries.java ! src/share/classes/sun/security/rsa/RSASignature.java ! src/share/classes/sun/security/rsa/SunRsaSignEntries.java ! src/share/classes/sun/security/x509/AlgorithmId.java ! src/windows/classes/sun/security/mscapi/RSASignature.java ! src/windows/classes/sun/security/mscapi/SunMSCAPI.java ! test/com/sun/crypto/provider/Cipher/RSA/TestOAEP.java ! test/com/sun/crypto/provider/Cipher/RSA/TestOAEPParameterSpec.java ! test/com/sun/crypto/provider/Cipher/RSA/TestOAEPWithParams.java ! test/com/sun/crypto/provider/KeyGenerator/Test4628062.java ! test/com/sun/crypto/provider/Mac/MacClone.java ! test/com/sun/crypto/provider/Mac/MacKAT.java ! test/sun/security/mscapi/SignUsingNONEwithRSA.java ! test/sun/security/mscapi/SignUsingSHA2withRSA.java ! test/sun/security/pkcs11/MessageDigest/DigestKAT.java ! test/sun/security/pkcs11/MessageDigest/TestCloning.java ! test/sun/security/pkcs11/Signature/TestRSAKeyLength.java ! test/sun/security/pkcs11/ec/TestCurves.java ! test/sun/security/pkcs11/rsa/TestKeyPairGenerator.java ! test/sun/security/pkcs11/rsa/TestSignatures.java ! test/sun/security/provider/MessageDigest/DigestKAT.java ! test/sun/security/provider/MessageDigest/Offsets.java ! test/sun/security/provider/MessageDigest/TestSHAClone.java ! test/sun/security/rsa/TestKeyPairGenerator.java ! test/sun/security/rsa/TestSignatures.java Changeset: dfce31760a2f Author: valeriep Date: 2012-05-08 18:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dfce31760a2f Merge Changeset: 9f8210f23773 Author: valeriep Date: 2012-05-10 11:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9f8210f23773 Merge From rob.mckenna at oracle.com Thu May 10 18:56:31 2012 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 10 May 2012 19:56:31 +0100 Subject: review request: 4244896: (process) Provide System.getPid(), System.killProcess(String pid) In-Reply-To: <4F8FF15E.9080408@oracle.com> References: <4F861847.5080308@oracle.com> <4F869AD6.7010903@oracle.com>, <4F8D849E.8090607@oracle.com> <4F8F56E0.6020009@oracle.com> <4F8FF15E.9080408@oracle.com> Message-ID: <4FAC0F5F.3090508@oracle.com> Hi folks, The latest version is at: http://cr.openjdk.java.net/~robm/4244896/webrev.03/ Feedback greatly appreciated. -Rob On 19/04/12 12:05, Alan Bateman wrote: > On 19/04/2012 01:05, David Holmes wrote: >> On 18/04/2012 11:44 PM, Jason Mehrens wrote: >>> >>> Rob, >>> >>> It looks like waitFor is calling Object.wait(long) without owning >>> this objects monitor. If I pass Long.MAX_VALUE to waitFor, >>> shouldn't waitFor return if the early if the process ends? >> >> Also waitFor doesn't call wait() under the guard of a looping >> predicate so it will suffer from lost signals and potentially >> spurious wakeups. I also don't see anything calling notify[All] to >> indicate the process has now terminated. It would appear that >> wait(timeout) is being used as a sleep mechanism and that is wrong on >> a number of levels. > I assume waitFor(timout) will require 3 distinct implementations, one > for Solaris/Linux/Mac, another for Windows, and a default > implementations for Process implementations that exist outside of the > JDK. > > It's likely the Solaris/Linux/Mac implementation will involve two > threads, one to block in waitpid and the other to interrupt it via a > signal if the timeout elapses before the child terminates. The Windows > implementation should be trivial because it can be a timed wait. > > I assume the default implementation (which is what is being discussed > here) will need to loop calling exitValue until the timeout elapses or > the child terminates. Not very efficient but at least it won't be used > when when creating Processes via Runtime.exec or ProcessBuilder. > > I think the question we need to consider is whether waitFor(timeout) > is really needed. If it's something that it pushed out for another day > then it brings up the question as to whether to include isAlive now or > not (as waitFor without timeout gives us an isAlive equivalent too). > > -Alan. > > > > From kumar.x.srinivasan at oracle.com Thu May 10 20:53:31 2012 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Thu, 10 May 2012 20:53:31 +0000 Subject: hg: jdk8/tl/langtools: 7159445: (javac) emits inaccurate diagnostics for enhanced for-loops Message-ID: <20120510205333.D760047244@hg.openjdk.java.net> Changeset: 833bab705918 Author: ksrini Date: 2012-05-10 12:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/833bab705918 7159445: (javac) emits inaccurate diagnostics for enhanced for-loops Reviewed-by: jjg Contributed-by: jan.lahoda at oracle.com ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/ForeachBadInitialization.java ! test/tools/javac/parser/JavacParserTest.java From olivier.lagneau at oracle.com Thu May 10 22:13:12 2012 From: olivier.lagneau at oracle.com (Olivier Lagneau) Date: Fri, 11 May 2012 00:13:12 +0200 Subject: Review Request for CR : 7144861 RMI activation tests are too slow In-Reply-To: <4FAB43DD.5060206@oracle.com> References: <4FA28399.9000601@oracle.com> <4FA2C605.7010908@oracle.com> <4FA48780.3030901@oracle.com> <4FA66ED3.7030209@oracle.com> <4FA807CD.1050906@oracle.com> <4FA84CB9.6010606@oracle.com> <4FA8AFD2.5090004@oracle.com> <4FA9DC2D.4030107@oracle.com> <4FA9EA1F.7060103@oracle.com> <4FAA8CA3.70502@oracle.com> <4FAB43DD.5060206@oracle.com> Message-ID: <4FAC3D78.1030807@oracle.com> Please find the second webrev with your remarks applied here: http://cr.openjdk.java.net/~olagneau/7144861/webrev.01/ In addition to the way we have agreed (see below) to handle InterruptedException in this fix, I have applied all the other requests for change. Regarding RMID.start() with outer and inner timer loops, I have kept the current structure of the code, but for sure this should be totally rewritten in a further cleanup of the code. Thanks, Olivier. Stuart Marks said on date 5/10/2012 6:28 AM: > On 5/9/12 8:26 AM, Olivier Lagneau wrote: >> Given that we want to push the code quickly, I don't think I should >> go for such >> a large IE cleanup for this fix, >> which is meant to provide better exceution speed only. >> >> I suggest to follow Stuart's proposal first (i.e. reassert and return >> immediately in my code changes) , >> and create a dedicated new CR regarding proper handling of IE in all >> the rmi >> tests (low priority). >> Do you agree with this ? > > Yes, this seems like a sensible approach. The new CR might also cover > the cleaning/unification of all the retry-repeatedly-with-time-limit > loops that are spread through this code. > > Thanks. > > s'marks From olivier.lagneau at oracle.com Thu May 10 22:16:55 2012 From: olivier.lagneau at oracle.com (Olivier Lagneau) Date: Fri, 11 May 2012 00:16:55 +0200 Subject: Review Request for CR : 7144861 RMI activation tests are too slow In-Reply-To: <4FAC3D78.1030807@oracle.com> References: <4FA28399.9000601@oracle.com> <4FA2C605.7010908@oracle.com> <4FA48780.3030901@oracle.com> <4FA66ED3.7030209@oracle.com> <4FA807CD.1050906@oracle.com> <4FA84CB9.6010606@oracle.com> <4FA8AFD2.5090004@oracle.com> <4FA9DC2D.4030107@oracle.com> <4FA9EA1F.7060103@oracle.com> <4FAA8CA3.70502@oracle.com> <4FAB43DD.5060206@oracle.com> <4FAC3D78.1030807@oracle.com> Message-ID: <4FAC3E57.2080505@oracle.com> Olivier Lagneau said on date 5/11/2012 12:13 AM: > Please find the second webrev with your remarks applied here: > http://cr.openjdk.java.net/~olagneau/7144861/webrev.01/ > > In addition to the way we have agreed (see below) to handle > InterruptedException in this fix, > I have applied all the other requests for change. > Regarding RMID.start() with outer and inner timer loops, I have kept > the current structure of the code, > but for sure this should be totally rewritten in a further cleanup of > the code. > > Thanks, > Olivier. > > > > Stuart Marks said on date 5/10/2012 6:28 AM: >> On 5/9/12 8:26 AM, Olivier Lagneau wrote: >>> Given that we want to push the code quickly, I don't think I should >>> go for such >>> a large IE cleanup for this fix, >>> which is meant to provide better exceution speed only. >>> >>> I suggest to follow Stuart's proposal first (i.e. reassert and return >>> immediately in my code changes) , >>> and create a dedicated new CR regarding proper handling of IE in all >>> the rmi >>> tests (low priority). >>> Do you agree with this ? >> >> Yes, this seems like a sensible approach. The new CR might also cover >> the cleaning/unification of all the retry-repeatedly-with-time-limit >> loops that are spread through this code. >> >> Thanks. >> >> s'marks > From olivier.lagneau at oracle.com Thu May 10 22:20:25 2012 From: olivier.lagneau at oracle.com (Olivier Lagneau) Date: Fri, 11 May 2012 00:20:25 +0200 Subject: Review Request for CR : 7144861 RMI activation tests are too slow (wrong webev link fixed) In-Reply-To: <4FAC3D78.1030807@oracle.com> References: <4FA28399.9000601@oracle.com> <4FA2C605.7010908@oracle.com> <4FA48780.3030901@oracle.com> <4FA66ED3.7030209@oracle.com> <4FA807CD.1050906@oracle.com> <4FA84CB9.6010606@oracle.com> <4FA8AFD2.5090004@oracle.com> <4FA9DC2D.4030107@oracle.com> <4FA9EA1F.7060103@oracle.com> <4FAA8CA3.70502@oracle.com> <4FAB43DD.5060206@oracle.com> <4FAC3D78.1030807@oracle.com> Message-ID: <4FAC3F29.6040905@oracle.com> Olivier Lagneau said on date 5/11/2012 12:13 AM: > Please find the second webrev with your remarks applied here: > http://cr.openjdk.java.net/~olagneau/7144861/webrev.01/ Html link above is buggy. Please go to this correct location: http://cr.openjdk.java.net/~olagneau/7144861/webrev.01 > > In addition to the way we have agreed (see below) to handle > InterruptedException in this fix, > I have applied all the other requests for change. > Regarding RMID.start() with outer and inner timer loops, I have kept > the current structure of the code, > but for sure this should be totally rewritten in a further cleanup of > the code. > > Thanks, > Olivier. > > > > Stuart Marks said on date 5/10/2012 6:28 AM: >> On 5/9/12 8:26 AM, Olivier Lagneau wrote: >>> Given that we want to push the code quickly, I don't think I should >>> go for such >>> a large IE cleanup for this fix, >>> which is meant to provide better exceution speed only. >>> >>> I suggest to follow Stuart's proposal first (i.e. reassert and return >>> immediately in my code changes) , >>> and create a dedicated new CR regarding proper handling of IE in all >>> the rmi >>> tests (low priority). >>> Do you agree with this ? >> >> Yes, this seems like a sensible approach. The new CR might also cover >> the cleaning/unification of all the retry-repeatedly-with-time-limit >> loops that are spread through this code. >> >> Thanks. >> >> s'marks > From mike.duigou at oracle.com Thu May 10 23:11:30 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 10 May 2012 16:11:30 -0700 Subject: Review Request : 7071826 : Avoid benign race condition in initialization of UUID Message-ID: <08019B0C-627E-4FF3-B9CC-EFF865D7963F@oracle.com> Hello all; A benign but potentially expensive race condition was discovered in java.util.UUID. The initialization of numberGenerator may cause the creation of a number of SecureRandom instances if multiple threads are attempting to initialize the field at the same time. This can happen because creation of the SecureRandom instances, depending upon system configuration and state, may take a significant amount of time. Using a shared SecureRandom instance for the numberGenerator is an optimization--nothing bad happens as a result of each thread using it's own instance. However, creation of multiple SecureRandom instances, especially during system startup, may be expensive or have high latency if no previous SecureRandom instances have been created. Accordingly, a holder class is used to ensure that only a single SecureRandom instance is created. The holder also serves to defer initialization of numberGenerator until randomUUID() is first called. Webrev: http://cr.openjdk.java.net/~mduigou/7071826/0/webrev/ This issue will be proposed for backport to Java 7u6 once integrated into Java 8 Thanks, Mike From stuart.marks at oracle.com Fri May 11 01:04:38 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 10 May 2012 18:04:38 -0700 Subject: Review Request for CR : 7144861 RMI activation tests are too slow (wrong webev link fixed) In-Reply-To: <4FAC3F29.6040905@oracle.com> References: <4FA28399.9000601@oracle.com> <4FA2C605.7010908@oracle.com> <4FA48780.3030901@oracle.com> <4FA66ED3.7030209@oracle.com> <4FA807CD.1050906@oracle.com> <4FA84CB9.6010606@oracle.com> <4FA8AFD2.5090004@oracle.com> <4FA9DC2D.4030107@oracle.com> <4FA9EA1F.7060103@oracle.com> <4FAA8CA3.70502@oracle.com> <4FAB43DD.5060206@oracle.com> <4FAC3D78.1030807@oracle.com> <4FAC3F29.6040905@oracle.com> Message-ID: <4FAC65A6.9010109@oracle.com> Looks good. Just one thing: in JavaVM.java, the declaration line for "boolean started" still has a comment that says "updated by started() method". That method has been renamed to setStarted(). Either fix the comment or perhaps better, remove it entirely. It's pretty easy to find uses of private variables. If the comment isn't there it won't get out of date! :-) BTW I ran before-and-after tests of the java/rmi/activation tests (32 tests), and the results are as follows: before: 18m21s after: 7m52s This is great! If the comment typo is the only change then I don't think you need another webrev before you push. Oh wait, you can't push, can you. OK, I'll do the push then, and I can apply the comment fix if there aren't any other changes. I'll wait overnight to hear from Alan or David, and if there's nothing else, I'll go ahead with it tomorrow. Thanks!! s'marks On 5/10/12 3:20 PM, Olivier Lagneau wrote: > > Olivier Lagneau said on date 5/11/2012 12:13 AM: >> Please find the second webrev with your remarks applied here: >> http://cr.openjdk.java.net/~olagneau/7144861/webrev.01/ > > Html link above is buggy. Please go to this correct location: > http://cr.openjdk.java.net/~olagneau/7144861/webrev.01 > > >> >> In addition to the way we have agreed (see below) to handle >> InterruptedException in this fix, >> I have applied all the other requests for change. >> Regarding RMID.start() with outer and inner timer loops, I have kept the >> current structure of the code, >> but for sure this should be totally rewritten in a further cleanup of the code. >> >> Thanks, >> Olivier. >> >> >> >> Stuart Marks said on date 5/10/2012 6:28 AM: >>> On 5/9/12 8:26 AM, Olivier Lagneau wrote: >>>> Given that we want to push the code quickly, I don't think I should go for >>>> such >>>> a large IE cleanup for this fix, >>>> which is meant to provide better exceution speed only. >>>> >>>> I suggest to follow Stuart's proposal first (i.e. reassert and return >>>> immediately in my code changes) , >>>> and create a dedicated new CR regarding proper handling of IE in all the rmi >>>> tests (low priority). >>>> Do you agree with this ? >>> >>> Yes, this seems like a sensible approach. The new CR might also cover the >>> cleaning/unification of all the retry-repeatedly-with-time-limit loops that >>> are spread through this code. >>> >>> Thanks. >>> >>> s'marks >> > From david.holmes at oracle.com Fri May 11 01:14:57 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 May 2012 11:14:57 +1000 Subject: Review Request for CR : 7144861 RMI activation tests are too slow (wrong webev link fixed) In-Reply-To: <4FAC65A6.9010109@oracle.com> References: <4FA28399.9000601@oracle.com> <4FA2C605.7010908@oracle.com> <4FA48780.3030901@oracle.com> <4FA66ED3.7030209@oracle.com> <4FA807CD.1050906@oracle.com> <4FA84CB9.6010606@oracle.com> <4FA8AFD2.5090004@oracle.com> <4FA9DC2D.4030107@oracle.com> <4FA9EA1F.7060103@oracle.com> <4FAA8CA3.70502@oracle.com> <4FAB43DD.5060206@oracle.com> <4FAC3D78.1030807@oracle.com> <4FAC3F29.6040905@oracle.com> <4FAC65A6.9010109@oracle.com> Message-ID: <4FAC6811.7090005@oracle.com> IE handling seems fine. No further comments from me. Note I was not a full reviewer of this. David On 11/05/2012 11:04 AM, Stuart Marks wrote: > Looks good. Just one thing: in JavaVM.java, the declaration line for > "boolean started" still has a comment that says "updated by started() > method". That method has been renamed to setStarted(). Either fix the > comment or perhaps better, remove it entirely. It's pretty easy to find > uses of private variables. If the comment isn't there it won't get out > of date! :-) > > BTW I ran before-and-after tests of the java/rmi/activation tests (32 > tests), and the results are as follows: > > before: 18m21s > after: 7m52s > > This is great! > > If the comment typo is the only change then I don't think you need > another webrev before you push. Oh wait, you can't push, can you. OK, > I'll do the push then, and I can apply the comment fix if there aren't > any other changes. I'll wait overnight to hear from Alan or David, and > if there's nothing else, I'll go ahead with it tomorrow. > > Thanks!! > > s'marks > > On 5/10/12 3:20 PM, Olivier Lagneau wrote: >> >> Olivier Lagneau said on date 5/11/2012 12:13 AM: >>> Please find the second webrev with your remarks applied here: >>> http://cr.openjdk.java.net/~olagneau/7144861/webrev.01/ >> >> Html link above is buggy. Please go to this correct location: >> http://cr.openjdk.java.net/~olagneau/7144861/webrev.01 >> >> >>> >>> In addition to the way we have agreed (see below) to handle >>> InterruptedException in this fix, >>> I have applied all the other requests for change. >>> Regarding RMID.start() with outer and inner timer loops, I have kept the >>> current structure of the code, >>> but for sure this should be totally rewritten in a further cleanup of >>> the code. >>> >>> Thanks, >>> Olivier. >>> >>> >>> >>> Stuart Marks said on date 5/10/2012 6:28 AM: >>>> On 5/9/12 8:26 AM, Olivier Lagneau wrote: >>>>> Given that we want to push the code quickly, I don't think I should >>>>> go for >>>>> such >>>>> a large IE cleanup for this fix, >>>>> which is meant to provide better exceution speed only. >>>>> >>>>> I suggest to follow Stuart's proposal first (i.e. reassert and return >>>>> immediately in my code changes) , >>>>> and create a dedicated new CR regarding proper handling of IE in >>>>> all the rmi >>>>> tests (low priority). >>>>> Do you agree with this ? >>>> >>>> Yes, this seems like a sensible approach. The new CR might also >>>> cover the >>>> cleaning/unification of all the retry-repeatedly-with-time-limit >>>> loops that >>>> are spread through this code. >>>> >>>> Thanks. >>>> >>>> s'marks >>> >> From littlee at linux.vnet.ibm.com Fri May 11 08:22:15 2012 From: littlee at linux.vnet.ibm.com (littlee at linux.vnet.ibm.com) Date: Fri, 11 May 2012 08:22:15 +0000 Subject: hg: jdk8/tl/jdk: 7163874: InetAddress.isReachable should support pinging 0.0.0.0 Message-ID: <20120511082234.A2A0F47277@hg.openjdk.java.net> Changeset: c5a07e3dca63 Author: youdwei Date: 2012-05-11 16:20 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c5a07e3dca63 7163874: InetAddress.isReachable should support pinging 0.0.0.0 Reviewed-by: alanb, chegar ! src/share/native/java/net/net_util.h ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/Inet6AddressImpl.c ! src/solaris/native/java/net/net_util_md.c + test/java/net/Inet4Address/PingThis.java From sean.coffey at oracle.com Fri May 11 09:09:22 2012 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Fri, 11 May 2012 09:09:22 +0000 Subject: hg: jdk8/tl/jdk: 7167359: (tz) SEGV on solaris if TZ variable not set Message-ID: <20120511090932.BD28847278@hg.openjdk.java.net> Changeset: 3e83229a3779 Author: coffeys Date: 2012-05-11 10:09 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3e83229a3779 7167359: (tz) SEGV on solaris if TZ variable not set Reviewed-by: okutsu ! src/solaris/native/java/util/TimeZone_md.c From chris.hegarty at oracle.com Fri May 11 10:05:33 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 11 May 2012 11:05:33 +0100 Subject: Review Request : 7071826 : Avoid benign race condition in initialization of UUID In-Reply-To: <08019B0C-627E-4FF3-B9CC-EFF865D7963F@oracle.com> References: <08019B0C-627E-4FF3-B9CC-EFF865D7963F@oracle.com> Message-ID: <4FACE46D.7040407@oracle.com> The changes look good to me. -Chris. On 11/05/12 00:11, Mike Duigou wrote: > Hello all; > > A benign but potentially expensive race condition was discovered in java.util.UUID. The initialization of numberGenerator may cause the creation of a number of SecureRandom instances if multiple threads are attempting to initialize the field at the same time. This can happen because creation of the SecureRandom instances, depending upon system configuration and state, may take a significant amount of time. > > Using a shared SecureRandom instance for the numberGenerator is an optimization--nothing bad happens as a result of each thread using it's own instance. However, creation of multiple SecureRandom instances, especially during system startup, may be expensive or have high latency if no previous SecureRandom instances have been created. > > Accordingly, a holder class is used to ensure that only a single SecureRandom instance is created. The holder also serves to defer initialization of numberGenerator until randomUUID() is first called. > > Webrev: > > http://cr.openjdk.java.net/~mduigou/7071826/0/webrev/ > > This issue will be proposed for backport to Java 7u6 once integrated into Java 8 > > Thanks, > > Mike From Alan.Bateman at oracle.com Fri May 11 10:12:15 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 11 May 2012 11:12:15 +0100 Subject: Review Request : 7071826 : Avoid benign race condition in initialization of UUID In-Reply-To: <08019B0C-627E-4FF3-B9CC-EFF865D7963F@oracle.com> References: <08019B0C-627E-4FF3-B9CC-EFF865D7963F@oracle.com> Message-ID: <4FACE5FF.4060401@oracle.com> On 11/05/2012 00:11, Mike Duigou wrote: > Hello all; > > A benign but potentially expensive race condition was discovered in java.util.UUID. The initialization of numberGenerator may cause the creation of a number of SecureRandom instances if multiple threads are attempting to initialize the field at the same time. This can happen because creation of the SecureRandom instances, depending upon system configuration and state, may take a significant amount of time. > > Using a shared SecureRandom instance for the numberGenerator is an optimization--nothing bad happens as a result of each thread using it's own instance. However, creation of multiple SecureRandom instances, especially during system startup, may be expensive or have high latency if no previous SecureRandom instances have been created. > > Accordingly, a holder class is used to ensure that only a single SecureRandom instance is created. The holder also serves to defer initialization of numberGenerator until randomUUID() is first called. > > Webrev: > > http://cr.openjdk.java.net/~mduigou/7071826/0/webrev/ > > This issue will be proposed for backport to Java 7u6 once integrated into Java 8 > The implementation change looks good to me. For the javadoc change then could you link to RFC 4122 on the IEFT site? I don't quite get the test update, it improves the test but I don't see how it might demonstrate the race condition. Minor consistency comment is that the if statements use braces whereas the existing code doesn't, also missing space in "if(". -Alan. From olivier.lagneau at oracle.com Fri May 11 10:18:35 2012 From: olivier.lagneau at oracle.com (Olivier Lagneau) Date: Fri, 11 May 2012 12:18:35 +0200 Subject: Review Request for CR : 7144861 RMI activation tests are too slow (wrong webev link fixed) In-Reply-To: <4FAC65A6.9010109@oracle.com> References: <4FA28399.9000601@oracle.com> <4FA2C605.7010908@oracle.com> <4FA48780.3030901@oracle.com> <4FA66ED3.7030209@oracle.com> <4FA807CD.1050906@oracle.com> <4FA84CB9.6010606@oracle.com> <4FA8AFD2.5090004@oracle.com> <4FA9DC2D.4030107@oracle.com> <4FA9EA1F.7060103@oracle.com> <4FAA8CA3.70502@oracle.com> <4FAB43DD.5060206@oracle.com> <4FAC3D78.1030807@oracle.com> <4FAC3F29.6040905@oracle.com> <4FAC65A6.9010109@oracle.com> Message-ID: <4FACE77B.5090003@oracle.com> Stuart Marks said on date 5/11/2012 3:04 AM: > Looks good. Just one thing: in JavaVM.java, the declaration line for > "boolean started" still has a comment that says "updated by started() > method". That method has been renamed to setStarted(). Either fix the > comment or perhaps better, remove it entirely. It's pretty easy to > find uses of private variables. If the comment isn't there it won't > get out of date! :-) Ok given Darryl's additional comment (see below), I will suppress this comment. > Darryl Mocek said on date 5/11/2012 12:51 AM: >> Olivier, >> >> a minor comment...I would make the StreamPipe constructor private >> since only the plugTogether method is supposed to call it. >> > > BTW I ran before-and-after tests of the java/rmi/activation tests (32 > tests), and the results are as follows: > > before: 18m21s > after: 7m52s > > This is great! > > If the comment typo is the only change then I don't think you need > another webrev before you push. Oh wait, you can't push, can you. OK, > I'll do the push then, and I can apply the comment fix if there aren't > any other changes. I'll wait overnight to hear from Alan or David, and > if there's nothing else, I'll go ahead with it tomorrow. I am going to provide another webrev containing Darryl's plus your change requests within a couple of hours. Olivier. > > On 5/10/12 3:20 PM, Olivier Lagneau wrote: >> >> Olivier Lagneau said on date 5/11/2012 12:13 AM: >>> Please find the second webrev with your remarks applied here: >>> http://cr.openjdk.java.net/~olagneau/7144861/webrev.01/ >> >> Html link above is buggy. Please go to this correct location: >> http://cr.openjdk.java.net/~olagneau/7144861/webrev.01 >> >> >>> >>> In addition to the way we have agreed (see below) to handle >>> InterruptedException in this fix, >>> I have applied all the other requests for change. >>> Regarding RMID.start() with outer and inner timer loops, I have kept >>> the >>> current structure of the code, >>> but for sure this should be totally rewritten in a further cleanup >>> of the code. >>> >>> Thanks, >>> Olivier. >>> >>> >>> >>> Stuart Marks said on date 5/10/2012 6:28 AM: >>>> On 5/9/12 8:26 AM, Olivier Lagneau wrote: >>>>> Given that we want to push the code quickly, I don't think I >>>>> should go for >>>>> such >>>>> a large IE cleanup for this fix, >>>>> which is meant to provide better exceution speed only. >>>>> >>>>> I suggest to follow Stuart's proposal first (i.e. reassert and return >>>>> immediately in my code changes) , >>>>> and create a dedicated new CR regarding proper handling of IE in >>>>> all the rmi >>>>> tests (low priority). >>>>> Do you agree with this ? >>>> >>>> Yes, this seems like a sensible approach. The new CR might also >>>> cover the >>>> cleaning/unification of all the retry-repeatedly-with-time-limit >>>> loops that >>>> are spread through this code. >>>> >>>> Thanks. >>>> >>>> s'marks >>> >> From paul.sandoz at oracle.com Fri May 11 11:29:17 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 11 May 2012 13:29:17 +0200 Subject: review request: 4244896: (process) Provide System.getPid(), System.killProcess(String pid) In-Reply-To: <4FAC0F5F.3090508@oracle.com> References: <4F861847.5080308@oracle.com> <4F869AD6.7010903@oracle.com>, <4F8D849E.8090607@oracle.com> <4F8F56E0.6020009@oracle.com> <4F8FF15E.9080408@oracle.com> <4FAC0F5F.3090508@oracle.com> Message-ID: <006C8895-809F-4E3F-BB35-2C3C3C604C41@oracle.com> Hi Rob, I dunno if the following has been pointed out before. It's hard to track review comments. The implementation of Process.waitFor normalizes the end time and duration remaining time to nano seconds. However, the Thread.sleep method expects a duration in units of milliseconds. You could use: http://docs.oracle.com/javase/7/docs/api/java/lang/Thread.html#sleep(long, int) Or just round things up to the nearest millisecond: Thread.sleep(Math.min(TimeUnit.NANOSECONDS.toMillis(rem) + 1, 100)); That would be more consistent and wait for less time over that of the requested duration. For the following code: 227 long rem = end - now; 228 while (!hasExited && (rem > 0)) { 229 wait(TimeUnit.NANOSECONDS.toMillis(rem)); 230 rem = end - System.nanoTime(); 231 } Can the above go into a spin loop once the duration is less than 1 millisecond for the rest of that duration? If so you may want to round it up to the nearest millisecond. Paul. On May 10, 2012, at 8:56 PM, Rob McKenna wrote: > Hi folks, > > The latest version is at: > > http://cr.openjdk.java.net/~robm/4244896/webrev.03/ > > Feedback greatly appreciated. > > -Rob > > On 19/04/12 12:05, Alan Bateman wrote: >> On 19/04/2012 01:05, David Holmes wrote: >>> On 18/04/2012 11:44 PM, Jason Mehrens wrote: >>>> >>>> Rob, >>>> >>>> It looks like waitFor is calling Object.wait(long) without owning this objects monitor. If I pass Long.MAX_VALUE to waitFor, shouldn't waitFor return if the early if the process ends? >>> >>> Also waitFor doesn't call wait() under the guard of a looping predicate so it will suffer from lost signals and potentially spurious wakeups. I also don't see anything calling notify[All] to indicate the process has now terminated. It would appear that wait(timeout) is being used as a sleep mechanism and that is wrong on a number of levels. >> I assume waitFor(timout) will require 3 distinct implementations, one for Solaris/Linux/Mac, another for Windows, and a default implementations for Process implementations that exist outside of the JDK. >> >> It's likely the Solaris/Linux/Mac implementation will involve two threads, one to block in waitpid and the other to interrupt it via a signal if the timeout elapses before the child terminates. The Windows implementation should be trivial because it can be a timed wait. >> >> I assume the default implementation (which is what is being discussed here) will need to loop calling exitValue until the timeout elapses or the child terminates. Not very efficient but at least it won't be used when when creating Processes via Runtime.exec or ProcessBuilder. >> >> I think the question we need to consider is whether waitFor(timeout) is really needed. If it's something that it pushed out for another day then it brings up the question as to whether to include isAlive now or not (as waitFor without timeout gives us an isAlive equivalent too). >> >> -Alan. >> >> >> >> From olivier.lagneau at oracle.com Fri May 11 14:09:17 2012 From: olivier.lagneau at oracle.com (Olivier Lagneau) Date: Fri, 11 May 2012 16:09:17 +0200 Subject: Request for CR : 7144861 RMI activation tests are too slow (webrev.02) In-Reply-To: <4FACE77B.5090003@oracle.com> References: <4FA28399.9000601@oracle.com> <4FA2C605.7010908@oracle.com> <4FA48780.3030901@oracle.com> <4FA66ED3.7030209@oracle.com> <4FA807CD.1050906@oracle.com> <4FA84CB9.6010606@oracle.com> <4FA8AFD2.5090004@oracle.com> <4FA9DC2D.4030107@oracle.com> <4FA9EA1F.7060103@oracle.com> <4FAA8CA3.70502@oracle.com> <4FAB43DD.5060206@oracle.com> <4FAC3D78.1030807@oracle.com> <4FAC3F29.6040905@oracle.com> <4FAC65A6.9010109@oracle.com> <4FACE77B.5090003@oracle.com> Message-ID: <4FAD1D8D.9050509@oracle.com> I made the changes below and checked again all the rmi regression test. This updated webrev is here : http://cr.openjdk.java.net/~olagneau/7144861/webrev.02/ Olivier Olivier Lagneau said on date 5/11/2012 12:18 PM: > Stuart Marks said on date 5/11/2012 3:04 AM: >> Looks good. Just one thing: in JavaVM.java, the declaration line for >> "boolean started" still has a comment that says "updated by started() >> method". That method has been renamed to setStarted(). Either fix the >> comment or perhaps better, remove it entirely. It's pretty easy to >> find uses of private variables. If the comment isn't there it won't >> get out of date! :-) > Ok given Darryl's additional comment (see below), I will suppress this > comment. > >> Darryl Mocek said on date 5/11/2012 12:51 AM: >>> Olivier, >>> >>> a minor comment...I would make the StreamPipe constructor private >>> since only the plugTogether method is supposed to call it. >>> > >> >> BTW I ran before-and-after tests of the java/rmi/activation tests (32 >> tests), and the results are as follows: >> >> before: 18m21s >> after: 7m52s >> >> This is great! >> >> If the comment typo is the only change then I don't think you need >> another webrev before you push. Oh wait, you can't push, can you. OK, >> I'll do the push then, and I can apply the comment fix if there >> aren't any other changes. I'll wait overnight to hear from Alan or >> David, and if there's nothing else, I'll go ahead with it tomorrow. > I am going to provide another webrev containing Darryl's plus your > change requests within a couple of hours. > > Olivier. From sundararajan.athijegannathan at oracle.com Fri May 11 14:34:46 2012 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Fri, 11 May 2012 14:34:46 +0000 Subject: hg: jdk8/tl/langtools: 7166990: java/compiler Inherited interfaces using generics sometimes looses the generic type Message-ID: <20120511143449.B11294728C@hg.openjdk.java.net> Changeset: 96a8278e323c Author: sundar Date: 2012-05-11 20:06 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/96a8278e323c 7166990: java/compiler Inherited interfaces using generics sometimes looses the generic type Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/TryWithResources/T7164542.java From rob.mckenna at oracle.com Fri May 11 15:24:18 2012 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 11 May 2012 16:24:18 +0100 Subject: review request: 4244896: (process) Provide System.getPid(), System.killProcess(String pid) In-Reply-To: <006C8895-809F-4E3F-BB35-2C3C3C604C41@oracle.com> References: <4F861847.5080308@oracle.com> <4F869AD6.7010903@oracle.com>, <4F8D849E.8090607@oracle.com> <4F8F56E0.6020009@oracle.com> <4F8FF15E.9080408@oracle.com> <4FAC0F5F.3090508@oracle.com> <006C8895-809F-4E3F-BB35-2C3C3C604C41@oracle.com> Message-ID: <4FAD2F22.7050305@oracle.com> Hi Paul, Comments inline: On 11/05/12 12:29, Paul Sandoz wrote: > Hi Rob, > > I dunno if the following has been pointed out before. It's hard to track review comments. > > > The implementation of Process.waitFor normalizes the end time and duration remaining time to nano seconds. However, the Thread.sleep method expects a duration in units of milliseconds. > > You could use: > > http://docs.oracle.com/javase/7/docs/api/java/lang/Thread.html#sleep(long, int) > > Or just round things up to the nearest millisecond: > > Thread.sleep(Math.min(TimeUnit.NANOSECONDS.toMillis(rem) + 1, 100)); > > That would be more consistent and wait for less time over that of the requested duration. Thanks for catching that. > > For the following code: > > 227 long rem = end - now; > 228 while (!hasExited&& (rem> 0)) { > 229 wait(TimeUnit.NANOSECONDS.toMillis(rem)); > 230 rem = end - System.nanoTime(); > 231 } > > Can the above go into a spin loop once the duration is less than 1 millisecond for the rest of that duration? If so you may want to round it up to the nearest millisecond. Eesh. wait(0) will wait until notified so we could end up waiting past our timeout expiry. Would: wait(Math.max(TimeUnit.NANOSECONDS.toMillis(rem), 1)); alleviate all concerns here? -Rob > Paul. > > On May 10, 2012, at 8:56 PM, Rob McKenna wrote: > >> Hi folks, >> >> The latest version is at: >> >> http://cr.openjdk.java.net/~robm/4244896/webrev.03/ >> >> Feedback greatly appreciated. >> >> -Rob >> >> On 19/04/12 12:05, Alan Bateman wrote: >>> On 19/04/2012 01:05, David Holmes wrote: >>>> On 18/04/2012 11:44 PM, Jason Mehrens wrote: >>>>> Rob, >>>>> >>>>> It looks like waitFor is calling Object.wait(long) without owning this objects monitor. If I pass Long.MAX_VALUE to waitFor, shouldn't waitFor return if the early if the process ends? >>>> Also waitFor doesn't call wait() under the guard of a looping predicate so it will suffer from lost signals and potentially spurious wakeups. I also don't see anything calling notify[All] to indicate the process has now terminated. It would appear that wait(timeout) is being used as a sleep mechanism and that is wrong on a number of levels. >>> I assume waitFor(timout) will require 3 distinct implementations, one for Solaris/Linux/Mac, another for Windows, and a default implementations for Process implementations that exist outside of the JDK. >>> >>> It's likely the Solaris/Linux/Mac implementation will involve two threads, one to block in waitpid and the other to interrupt it via a signal if the timeout elapses before the child terminates. The Windows implementation should be trivial because it can be a timed wait. >>> >>> I assume the default implementation (which is what is being discussed here) will need to loop calling exitValue until the timeout elapses or the child terminates. Not very efficient but at least it won't be used when when creating Processes via Runtime.exec or ProcessBuilder. >>> >>> I think the question we need to consider is whether waitFor(timeout) is really needed. If it's something that it pushed out for another day then it brings up the question as to whether to include isAlive now or not (as waitFor without timeout gives us an isAlive equivalent too). >>> >>> -Alan. >>> >>> >>> >>> From paul.sandoz at oracle.com Fri May 11 15:51:15 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 11 May 2012 17:51:15 +0200 Subject: review request: 4244896: (process) Provide System.getPid(), System.killProcess(String pid) In-Reply-To: <4FAD2F22.7050305@oracle.com> References: <4F861847.5080308@oracle.com> <4F869AD6.7010903@oracle.com>, <4F8D849E.8090607@oracle.com> <4F8F56E0.6020009@oracle.com> <4F8FF15E.9080408@oracle.com> <4FAC0F5F.3090508@oracle.com> <006C8895-809F-4E3F-BB35-2C3C3C604C41@oracle.com> <4FAD2F22.7050305@oracle.com> Message-ID: On May 11, 2012, at 5:24 PM, Rob McKenna wrote: > >> >> For the following code: >> >> 227 long rem = end - now; >> 228 while (!hasExited&& (rem> 0)) { >> 229 wait(TimeUnit.NANOSECONDS.toMillis(rem)); >> 230 rem = end - System.nanoTime(); >> 231 } >> >> Can the above go into a spin loop once the duration is less than 1 millisecond for the rest of that duration? If so you may want to round it up to the nearest millisecond. > Eesh. wait(0) will wait until notified so we could end up waiting past our timeout expiry. Would: > > wait(Math.max(TimeUnit.NANOSECONDS.toMillis(rem), 1)); > > alleviate all concerns here? > Yes, or you could use: wait(long timeout, int nanos) Paul. From mike.duigou at oracle.com Fri May 11 18:13:10 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 11 May 2012 11:13:10 -0700 Subject: Review Request : 7071826 : Avoid benign race condition in initialization of UUID In-Reply-To: <4FACE5FF.4060401@oracle.com> References: <08019B0C-627E-4FF3-B9CC-EFF865D7963F@oracle.com> <4FACE5FF.4060401@oracle.com> Message-ID: <32D81E45-B51B-49E9-9430-8CDF982A6ED8@oracle.com> On May 11 2012, at 03:12 , Alan Bateman wrote: > On 11/05/2012 00:11, Mike Duigou wrote: >> >> Hello all; >> >> A benign but potentially expensive race condition was discovered in java.util.UUID. The initialization of numberGenerator may cause the creation of a number of SecureRandom instances if multiple threads are attempting to initialize the field at the same time. This can happen because creation of the SecureRandom instances, depending upon system configuration and state, may take a significant amount of time. >> >> Using a shared SecureRandom instance for the numberGenerator is an optimization--nothing bad happens as a result of each thread using it's own instance. However, creation of multiple SecureRandom instances, especially during system startup, may be expensive or have high latency if no previous SecureRandom instances have been created. >> >> Accordingly, a holder class is used to ensure that only a single SecureRandom instance is created. The holder also serves to defer initialization of numberGenerator until randomUUID() is first called. >> >> Webrev: >> >> http://cr.openjdk.java.net/~mduigou/7071826/0/webrev/ >> >> This issue will be proposed for backport to Java 7u6 once integrated into Java 8 >> > The implementation change looks good to me. For the javadoc change then could you link to RFC 4122 on the IEFT site? Yes. > > I don't quite get the test update, it improves the test but I don't see how it might demonstrate the race condition. It doesn't demonstrate the race condition. The test changes are mostly just a result of reviewing the tests while I planned the changes. > Minor consistency comment is that the if statements use braces whereas the existing code doesn't, According to javastyle guidelines we're supposed to always use braces. I've not modified existing cases where braces are not present unless modifying the if expression. > also missing space in "if(". Fixed. > > -Alan. > From mike.duigou at oracle.com Fri May 11 18:33:09 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Fri, 11 May 2012 18:33:09 +0000 Subject: hg: jdk8/tl/jdk: 7071826: Avoid benign race condition in initialization of UUID Message-ID: <20120511183329.C6DDD47296@hg.openjdk.java.net> Changeset: 944676ef3c58 Author: mduigou Date: 2012-05-11 11:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/944676ef3c58 7071826: Avoid benign race condition in initialization of UUID Summary: Avoids mostly benign but sometimes expensive race condition on initialization of UUID.numberGenerator which is used by UUID.randomUUID() Reviewed-by: alanb, chegar ! src/share/classes/java/util/UUID.java ! test/java/util/UUID/UUIDTest.java From lana.steuck at oracle.com Fri May 11 20:24:19 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 11 May 2012 20:24:19 +0000 Subject: hg: jdk8/tl: 6 new changesets Message-ID: <20120511202419.87820472A2@hg.openjdk.java.net> Changeset: afeeed8e5f8c Author: ihse Date: 2012-04-30 12:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/afeeed8e5f8c 7165277: Fix missing execute permission issue running logger.sh Reviewed-by: ohair ! common/autoconf/configure ! common/autoconf/configure.ac Changeset: b2972095a4b1 Author: katleman Date: 2012-05-02 15:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/b2972095a4b1 Merge Changeset: 2eeb9fac7dfc Author: katleman Date: 2012-05-09 13:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/2eeb9fac7dfc Added tag jdk8-b37 for changeset b2972095a4b1 ! .hgtags Changeset: 2f06b15e2439 Author: ewendeli Date: 2012-05-03 14:17 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/2f06b15e2439 7154130: Add Mac OS X Instructions to README-builds.html Reviewed-by: ohair Contributed-by: edvard.wendelin at oracle.com ! README-builds.html Changeset: d939bd0ab13c Author: katleman Date: 2012-05-09 16:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/d939bd0ab13c Merge Changeset: b67bdaca36c2 Author: katleman Date: 2012-05-10 10:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/b67bdaca36c2 Added tag jdk8-b38 for changeset d939bd0ab13c ! .hgtags From lana.steuck at oracle.com Fri May 11 20:24:17 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 11 May 2012 20:24:17 +0000 Subject: hg: jdk8/tl/corba: 3 new changesets Message-ID: <20120511202421.7AE32472A3@hg.openjdk.java.net> Changeset: 2d2f6b0f855b Author: katleman Date: 2012-05-09 13:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/2d2f6b0f855b Added tag jdk8-b37 for changeset 83fac66442cf ! .hgtags Changeset: b8cbfb31139f Author: katleman Date: 2012-05-09 13:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/b8cbfb31139f Merge Changeset: 785af00e2827 Author: katleman Date: 2012-05-10 10:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/785af00e2827 Added tag jdk8-b38 for changeset b8cbfb31139f ! .hgtags From lana.steuck at oracle.com Fri May 11 20:24:24 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 11 May 2012 20:24:24 +0000 Subject: hg: jdk8/tl/jaxws: 2 new changesets Message-ID: <20120511202431.A4534472A4@hg.openjdk.java.net> Changeset: ac1ba3b56775 Author: katleman Date: 2012-05-09 13:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/ac1ba3b56775 Added tag jdk8-b37 for changeset b05a948db1b6 ! .hgtags Changeset: 7f6b44fd3034 Author: katleman Date: 2012-05-10 10:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/7f6b44fd3034 Added tag jdk8-b38 for changeset ac1ba3b56775 ! .hgtags From lana.steuck at oracle.com Fri May 11 20:24:28 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 11 May 2012 20:24:28 +0000 Subject: hg: jdk8/tl/langtools: 3 new changesets Message-ID: <20120511202437.85022472A5@hg.openjdk.java.net> Changeset: 1f224f160aa8 Author: katleman Date: 2012-05-09 13:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1f224f160aa8 Added tag jdk8-b37 for changeset 5891b38985e8 ! .hgtags Changeset: a9f547c218d9 Author: katleman Date: 2012-05-10 10:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a9f547c218d9 Added tag jdk8-b38 for changeset 1f224f160aa8 ! .hgtags Changeset: 885806e74240 Author: lana Date: 2012-05-11 12:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/885806e74240 Merge From lana.steuck at oracle.com Fri May 11 20:24:27 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 11 May 2012 20:24:27 +0000 Subject: hg: jdk8/tl/jaxp: 4 new changesets Message-ID: <20120511202441.17C96472A6@hg.openjdk.java.net> Changeset: aabc08ea546f Author: ohair Date: 2012-04-30 16:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/aabc08ea546f 7165312: Fix jaxp source movement for new build-infra Reviewed-by: ohrstrom ! makefiles/Makefile Changeset: 90204bfab4e2 Author: katleman Date: 2012-05-02 15:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/90204bfab4e2 Merge Changeset: 5bbe0cb6f2f2 Author: katleman Date: 2012-05-09 13:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/5bbe0cb6f2f2 Added tag jdk8-b37 for changeset 90204bfab4e2 ! .hgtags Changeset: f95fdbe525c8 Author: katleman Date: 2012-05-10 10:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/f95fdbe525c8 Added tag jdk8-b38 for changeset 5bbe0cb6f2f2 ! .hgtags From lana.steuck at oracle.com Fri May 11 20:24:32 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 11 May 2012 20:24:32 +0000 Subject: hg: jdk8/tl/hotspot: 21 new changesets Message-ID: <20120511202518.77CC9472A7@hg.openjdk.java.net> Changeset: 4ee58fcab520 Author: katleman Date: 2012-05-09 13:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4ee58fcab520 Added tag jdk8-b37 for changeset bfcf92bfefb8 ! .hgtags Changeset: 3c91f2c9fd21 Author: amurillo Date: 2012-04-20 17:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3c91f2c9fd21 7163193: new hotspot build - hs24-b09 Reviewed-by: jcoomes ! make/hotspot_version Changeset: f3a4ee95783b Author: kevinw Date: 2012-04-20 14:55 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f3a4ee95783b 7162488: VM not printing unknown -XX options Reviewed-by: dholmes, kamg ! src/share/vm/runtime/arguments.cpp + test/runtime/7162488/Test7162488.sh Changeset: 29ee40a082d3 Author: sla Date: 2012-04-23 13:30 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/29ee40a082d3 7162063: libsaproc debug print should format size_t correctly on 64bit platform Reviewed-by: rbackman, mgronlun, dholmes ! agent/src/os/linux/ps_core.c Changeset: f33c4d0f4c9e Author: dcubed Date: 2012-04-23 11:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f33c4d0f4c9e Merge Changeset: d652a62d6e03 Author: dcubed Date: 2012-03-23 11:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d652a62d6e03 7102323: RFE: enable Full Debug Symbols Phase 1 on Solaris Summary: Add support for ENABLE_FULL_DEBUG_SYMBOLS and ZIP_DEBUGINFO_FILES build flags. Add support for .diz files. Reviewed-by: dholmes, ohair, sspitsyn ! make/Makefile ! make/linux/Makefile ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/defs.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/jsig.make ! make/linux/makefiles/saproc.make ! make/linux/makefiles/vm.make ! make/solaris/Makefile ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/defs.make ! make/solaris/makefiles/dtrace.make ! make/solaris/makefiles/jsig.make ! make/solaris/makefiles/saproc.make ! make/solaris/makefiles/sparcWorks.make ! make/solaris/makefiles/vm.make ! make/windows/build.make ! make/windows/makefiles/compile.make ! make/windows/makefiles/debug.make ! make/windows/makefiles/defs.make ! make/windows/makefiles/fastdebug.make ! make/windows/makefiles/product.make ! make/windows/makefiles/sa.make Changeset: 744728c16316 Author: dcubed Date: 2012-04-03 09:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/744728c16316 7158067: FDS: ENABLE_FULL_DEBUG_SYMBOLS flag should only affect product builds Summary: Build option FULL_DEBUG_SYMBOLS=0 only affects product builds. Reviewed-by: ohair, jmelvin, sspitsyn ! make/Makefile ! make/linux/Makefile ! make/linux/makefiles/defs.make ! make/solaris/Makefile ! make/solaris/makefiles/defs.make ! make/windows/makefiles/defs.make Changeset: 74c359c4a9e5 Author: dcubed Date: 2012-04-24 15:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/74c359c4a9e5 Merge ! make/Makefile ! make/linux/Makefile ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/defs.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/defs.make ! make/solaris/makefiles/sparcWorks.make ! make/solaris/makefiles/vm.make ! make/windows/build.make ! make/windows/makefiles/compile.make ! make/windows/makefiles/debug.make ! make/windows/makefiles/defs.make ! make/windows/makefiles/fastdebug.make ! make/windows/makefiles/product.make Changeset: d6c393b0164b Author: dcubed Date: 2012-04-25 15:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d6c393b0164b 7164344: enabling ZIP_DEBUGINFO_FILES causes unexpected test failures on Solaris and Windows Summary: Disable FDS by default on Solaris; disable ZIP_DEBUGINFO_FILES by default on Windows. Reviewed-by: acorn, sspitsyn ! make/solaris/makefiles/defs.make ! make/windows/makefiles/defs.make Changeset: 973046802b6f Author: dlong Date: 2012-04-26 16:24 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/973046802b6f 7162955: Attach api on Solaris, too many open files Summary: Release server-side socket after client receives it. Reviewed-by: sla, dsamersoff, dcubed, acorn Contributed-by: dean.long at oracle.com ! src/os/solaris/vm/attachListener_solaris.cpp Changeset: 6f0612ea55ce Author: jprovino Date: 2012-05-02 15:47 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6f0612ea55ce Merge Changeset: 9f059abe8cf2 Author: jmasa Date: 2012-03-29 19:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9f059abe8cf2 7131629: Generalize the CMS free list code Summary: Make the FreeChunk, FreeList, TreeList, and BinaryTreeDictionary classes usable outside CMS. Reviewed-by: brutisso, johnc, jwilhelm Contributed-by: coleen.phillimore at oracle.com - src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.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/concurrentMarkSweep/freeBlockDictionary.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeList.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeList.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp + src/share/vm/memory/binaryTreeDictionary.cpp + src/share/vm/memory/binaryTreeDictionary.hpp + src/share/vm/memory/freeBlockDictionary.cpp + src/share/vm/memory/freeBlockDictionary.hpp + src/share/vm/memory/freeList.cpp + src/share/vm/memory/freeList.hpp ! src/share/vm/memory/generationSpec.cpp ! src/share/vm/precompiled/precompiled.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 8a2e5a6a19a4 Author: johnc Date: 2012-04-25 10:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8a2e5a6a19a4 7143490: G1: Remove HeapRegion::_top_at_conc_mark_count Summary: Removed the HeapRegion::_top_at_conc_mark_count field. It is no longer needed as a result of the changes for 6888336 and 7127706. Refactored the closures that finalize and verify the liveness counting data so that common functionality was placed into a base class. Reviewed-by: brutisso, tonyp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegion.inline.hpp Changeset: f69a5d43dc19 Author: jmasa Date: 2012-04-25 09:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f69a5d43dc19 7164144: Fix variable naming style in freeBlockDictionary.* and binaryTreeDictionary* Summary: Fix naming style to be consistent with the predominant hotspot style. Reviewed-by: ysr, brutisso ! 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/freeChunk.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/promotionInfo.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/promotionInfo.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp ! src/share/vm/gc_implementation/shared/allocationStats.hpp ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/memory/binaryTreeDictionary.hpp ! src/share/vm/memory/freeBlockDictionary.cpp ! src/share/vm/memory/freeBlockDictionary.hpp ! src/share/vm/memory/freeList.cpp ! src/share/vm/memory/freeList.hpp Changeset: ee89f2110312 Author: jmasa Date: 2012-04-25 15:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ee89f2110312 Merge Changeset: 48fac5d60c3c Author: brutisso Date: 2012-04-25 12:36 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/48fac5d60c3c 7163848: G1: Log GC Cause for a GC Reviewed-by: johnc, jwilhelm, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp Changeset: bb18e8eecb7e Author: jcoomes Date: 2012-05-04 10:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bb18e8eecb7e Merge - src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.hpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.hpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeList.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeList.hpp Changeset: 7d5ec8bf38d1 Author: amurillo Date: 2012-05-04 14:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7d5ec8bf38d1 Merge - src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.hpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.hpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeList.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeList.hpp Changeset: 4e6554041847 Author: amurillo Date: 2012-05-04 14:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4e6554041847 Added tag hs24-b09 for changeset 7d5ec8bf38d1 ! .hgtags Changeset: 637c3f5f068f Author: amurillo Date: 2012-05-09 14:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/637c3f5f068f Merge ! .hgtags Changeset: 3c394919ca69 Author: katleman Date: 2012-05-10 10:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3c394919ca69 Added tag jdk8-b38 for changeset 637c3f5f068f ! .hgtags From lana.steuck at oracle.com Fri May 11 20:26:12 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 11 May 2012 20:26:12 +0000 Subject: hg: jdk8/tl/jdk: 26 new changesets Message-ID: <20120511203038.395E8472A8@hg.openjdk.java.net> Changeset: 8e3fb7dd21cd Author: skovatch Date: 2012-04-25 12:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8e3fb7dd21cd 7128699: Fix bundle name so it contains the bugfix number in the name. Reviewed-by: robilad ! make/common/Release-macosx.gmk Changeset: 919be2f7fd6e Author: cgruszka Date: 2012-04-27 14:37 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/919be2f7fd6e Merge Changeset: 762661efef30 Author: jgodinez Date: 2012-04-24 13:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/762661efef30 7157659: [macosx] Landscape Printing orientation doesn't work Reviewed-by: bae, prr ! src/macosx/native/sun/awt/PrinterView.m Changeset: cdaadcc2c6a4 Author: jgodinez Date: 2012-04-26 13:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cdaadcc2c6a4 7013850: Please change the mnemonic assignment system to avoid translation issue Reviewed-by: prr, mfang ! src/share/classes/sun/print/ServiceDialog.java ! src/share/classes/sun/print/resources/serviceui.properties ! src/share/classes/sun/print/resources/serviceui_de.properties ! src/share/classes/sun/print/resources/serviceui_es.properties ! src/share/classes/sun/print/resources/serviceui_fr.properties ! src/share/classes/sun/print/resources/serviceui_it.properties ! src/share/classes/sun/print/resources/serviceui_ja.properties ! src/share/classes/sun/print/resources/serviceui_ko.properties ! src/share/classes/sun/print/resources/serviceui_pt_BR.properties ! src/share/classes/sun/print/resources/serviceui_sv.properties ! src/share/classes/sun/print/resources/serviceui_zh_CN.properties ! src/share/classes/sun/print/resources/serviceui_zh_TW.properties Changeset: c2d29a375871 Author: lana Date: 2012-04-26 18:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c2d29a375871 Merge Changeset: 4a19075bb989 Author: lana Date: 2012-05-02 09:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4a19075bb989 Merge Changeset: 44beb8a52aec Author: zhouyx Date: 2012-04-20 10:34 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/44beb8a52aec 7129742: Unable to view focus in Non-Editable TextArea Summary: Make sure the cursor is visible by setVisible(true) Reviewed-by: rupashka, alexp ! src/solaris/classes/sun/awt/X11/XTextAreaPeer.java ! src/solaris/classes/sun/awt/X11/XTextFieldPeer.java + test/java/awt/TextArea/TextAreaCaretVisibilityTest/bug7129742.java Changeset: dfa2ea47257d Author: luchsh Date: 2012-04-20 13:13 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dfa2ea47257d 7055065: NullPointerException when sorting JTable with empty cell Reviewed-by: rupashka ! src/share/classes/javax/swing/JTable.java + test/javax/swing/JTable/7055065/bug7055065.java Changeset: 738b32fc3ef1 Author: anthony Date: 2012-04-24 17:47 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/738b32fc3ef1 7150109: [macosx] the Frame showed incomplete. Summary: Open-source the tests Reviewed-by: art + test/java/awt/Frame/FrameStateTest/FrameStateTest.html + test/java/awt/Frame/FrameStateTest/FrameStateTest.java Changeset: 9ed029a0326d Author: anthony Date: 2012-04-24 19:12 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9ed029a0326d 7163898: add isLoggable() check to doLog() Summary: Add the check and return immediately if it's false Reviewed-by: anthony, mchung, sla Contributed-by: Nicolas Carranza ! src/share/classes/sun/util/logging/PlatformLogger.java Changeset: 4a0f6ef43a09 Author: anthony Date: 2012-04-24 20:39 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4a0f6ef43a09 7131021: [macosx] Consider using system properties to pass arguments from the launcher to AWT/SplashScreen Summary: Document the environment variables and add tests Reviewed-by: ksrini ! src/macosx/bin/java_md_macosx.c + test/tools/launcher/EnvironmentVariables.java ! test/tools/launcher/TestHelper.java + test/tools/launcher/TestSpecialArgs.java Changeset: 36fd5078198b Author: alexsch Date: 2012-04-25 16:48 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/36fd5078198b 7163482: [macosx] Regtest closed/javax/swing/JTree/4908142/bug4908142.java intermittent failure Reviewed-by: rupashka + test/javax/swing/JTree/4908142/bug4908142.java Changeset: f1d1dab11a06 Author: leonidr Date: 2012-04-25 18:15 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f1d1dab11a06 7154480: [macosx] Not all popup menu items are visible Reviewed-by: art ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/share/classes/javax/swing/JPopupMenu.java ! src/share/classes/sun/awt/SunToolkit.java Changeset: 340cda7e1430 Author: luchsh Date: 2012-04-26 12:39 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/340cda7e1430 7154030: java.awt.Component.hide() does not repaint parent component Reviewed-by: rupashka ! src/share/classes/javax/swing/JComponent.java + test/javax/swing/JComponent/7154030/bug7154030.java Changeset: 6314933aeaa9 Author: alexp Date: 2012-04-26 21:16 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6314933aeaa9 7124210: [macosx] Replacing text in a TextField does generate an extra TextEvent Reviewed-by: serb ! src/macosx/classes/sun/lwawt/LWTextAreaPeer.java ! src/macosx/classes/sun/lwawt/LWTextComponentPeer.java ! src/macosx/classes/sun/lwawt/LWTextFieldPeer.java Changeset: 4184e5cbf46e Author: alexp Date: 2012-04-26 21:25 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4184e5cbf46e 7124328: [macosx] javax.swing.JDesktopPane.getAllFramesInLayer returns unexpected value Reviewed-by: anthony ! src/share/classes/javax/swing/JDesktopPane.java Changeset: d148d3d194af Author: lana Date: 2012-04-26 18:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d148d3d194af Merge Changeset: bbbf4e63562b Author: dcherepanov Date: 2012-05-02 13:53 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bbbf4e63562b 7154062: [macosx] Mouse cursor isn't updated in applets Reviewed-by: anthony, art ! src/macosx/classes/sun/lwawt/macosx/CCursorManager.java ! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java ! src/macosx/native/sun/awt/CCursorManager.m Changeset: 0fad89bd606b Author: alexsch Date: 2012-05-02 17:54 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0fad89bd606b 7154048: [macosx] At least drag twice, the toolbar can be dragged to the left side Reviewed-by: anthony, leonidr ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTView.h ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/awt/AWTWindow.h ! src/macosx/native/sun/awt/AWTWindow.m + test/java/awt/Mouse/EnterExitEvents/DragWindowOutOfFrameTest.java + test/java/awt/Mouse/EnterExitEvents/DragWindowTest.java + test/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java ! test/java/awt/regtesthelpers/Util.java Changeset: f906d6068b43 Author: lana Date: 2012-05-02 09:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f906d6068b43 Merge Changeset: 717582c056f3 Author: lana Date: 2012-05-02 10:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/717582c056f3 Merge - src/macosx/bin/amd64/jvm.cfg - src/share/classes/sun/security/action/LoadLibraryAction.java ! test/tools/launcher/TestHelper.java - test/tools/pack200/dyn.jar - test/tools/pack200/pack200-verifier/src/xmlkit/ClassSyntax.java - test/tools/pack200/pack200-verifier/src/xmlkit/ClassWriter.java - test/tools/pack200/pack200-verifier/src/xmlkit/InstructionAssembler.java - test/tools/pack200/pack200-verifier/src/xmlkit/InstructionSyntax.java Changeset: bc0f9e693620 Author: lana Date: 2012-05-08 13:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bc0f9e693620 Merge - src/macosx/bin/amd64/jvm.cfg - src/share/classes/sun/security/action/LoadLibraryAction.java - test/tools/pack200/dyn.jar - test/tools/pack200/pack200-verifier/src/xmlkit/ClassSyntax.java - test/tools/pack200/pack200-verifier/src/xmlkit/ClassWriter.java - test/tools/pack200/pack200-verifier/src/xmlkit/InstructionAssembler.java - test/tools/pack200/pack200-verifier/src/xmlkit/InstructionSyntax.java Changeset: 185821106403 Author: katleman Date: 2012-05-09 13:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/185821106403 Added tag jdk8-b37 for changeset 9e82ac15ab80 ! .hgtags Changeset: c45f3509a707 Author: katleman Date: 2012-05-09 13:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c45f3509a707 Merge - src/macosx/bin/amd64/jvm.cfg - src/share/classes/sun/security/action/LoadLibraryAction.java - test/tools/pack200/dyn.jar - test/tools/pack200/pack200-verifier/src/xmlkit/ClassSyntax.java - test/tools/pack200/pack200-verifier/src/xmlkit/ClassWriter.java - test/tools/pack200/pack200-verifier/src/xmlkit/InstructionAssembler.java - test/tools/pack200/pack200-verifier/src/xmlkit/InstructionSyntax.java Changeset: b5726775b0d8 Author: katleman Date: 2012-05-10 10:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b5726775b0d8 Added tag jdk8-b38 for changeset c45f3509a707 ! .hgtags Changeset: 85d7677a75bf Author: lana Date: 2012-05-11 12:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/85d7677a75bf Merge From stuart.marks at oracle.com Fri May 11 21:26:25 2012 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Fri, 11 May 2012 21:26:25 +0000 Subject: hg: jdk8/tl/jdk: 7144861: speed up RMI activation tests Message-ID: <20120511212644.C182F472AA@hg.openjdk.java.net> Changeset: f131d4361faf Author: olagneau Date: 2012-05-11 14:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f131d4361faf 7144861: speed up RMI activation tests Reviewed-by: alanb, smarks, dholmes, dmocek ! test/java/rmi/activation/checkusage/CheckUsage.java ! test/java/rmi/testlibrary/ActivationLibrary.java ! test/java/rmi/testlibrary/JavaVM.java ! test/java/rmi/testlibrary/RMID.java ! test/java/rmi/testlibrary/StreamPipe.java ! test/sun/rmi/runtime/Log/6409194/NoConsoleOutput.java From kurchi.subhra.hazra at oracle.com Fri May 11 21:46:21 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Fri, 11 May 2012 14:46:21 -0700 Subject: Code Review Request: 7164636: (prefs) Cleanup src/macosx/classes/java/util/prefs Message-ID: <4FAD88AD.4010002@oracle.com> Hi, This change aims at removing some rawtype usages in src/macosx/classes/java/util/prefs that were brought into jdk8 with the macport. I have added @Override tags too where applicable. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7164636 Webrev: http://cr.openjdk.java.net/~khazra/7164636/webrev.00/ Thanks, Kurchi From brian.goetz at oracle.com Sat May 12 18:57:34 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Sat, 12 May 2012 14:57:34 -0400 Subject: Review Request : 7071826 : Avoid benign race condition in initialization of UUID In-Reply-To: <08019B0C-627E-4FF3-B9CC-EFF865D7963F@oracle.com> References: <08019B0C-627E-4FF3-B9CC-EFF865D7963F@oracle.com> Message-ID: <4FAEB29E.8070308@oracle.com> Farther afield: the "Holder" idiom for thread-safe lazy initialization is one that we could now replace with invokedynamic (since a ConstantCallSize acts as a lazily initialize cache), if there were only a way to actually express the indy code from Java. This would let us replace a class with a call site. On 5/10/2012 7:11 PM, Mike Duigou wrote: > Hello all; > > A benign but potentially expensive race condition was discovered in java.util.UUID. The initialization of numberGenerator may cause the creation of a number of SecureRandom instances if multiple threads are attempting to initialize the field at the same time. This can happen because creation of the SecureRandom instances, depending upon system configuration and state, may take a significant amount of time. > > Using a shared SecureRandom instance for the numberGenerator is an optimization--nothing bad happens as a result of each thread using it's own instance. However, creation of multiple SecureRandom instances, especially during system startup, may be expensive or have high latency if no previous SecureRandom instances have been created. > > Accordingly, a holder class is used to ensure that only a single SecureRandom instance is created. The holder also serves to defer initialization of numberGenerator until randomUUID() is first called. > > Webrev: > > http://cr.openjdk.java.net/~mduigou/7071826/0/webrev/ > > This issue will be proposed for backport to Java 7u6 once integrated into Java 8 > > Thanks, > > Mike From brian.goetz at oracle.com Sat May 12 18:58:36 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Sat, 12 May 2012 14:58:36 -0400 Subject: Review Request : 7071826 : Avoid benign race condition in initialization of UUID In-Reply-To: <08019B0C-627E-4FF3-B9CC-EFF865D7963F@oracle.com> References: <08019B0C-627E-4FF3-B9CC-EFF865D7963F@oracle.com> Message-ID: <4FAEB2DC.2070304@oracle.com> Oops, forgot to actually review the patch: approved. On 5/10/2012 7:11 PM, Mike Duigou wrote: > Hello all; > > A benign but potentially expensive race condition was discovered in java.util.UUID. The initialization of numberGenerator may cause the creation of a number of SecureRandom instances if multiple threads are attempting to initialize the field at the same time. This can happen because creation of the SecureRandom instances, depending upon system configuration and state, may take a significant amount of time. > > Using a shared SecureRandom instance for the numberGenerator is an optimization--nothing bad happens as a result of each thread using it's own instance. However, creation of multiple SecureRandom instances, especially during system startup, may be expensive or have high latency if no previous SecureRandom instances have been created. > > Accordingly, a holder class is used to ensure that only a single SecureRandom instance is created. The holder also serves to defer initialization of numberGenerator until randomUUID() is first called. > > Webrev: > > http://cr.openjdk.java.net/~mduigou/7071826/0/webrev/ > > This issue will be proposed for backport to Java 7u6 once integrated into Java 8 > > Thanks, > > Mike From david.holmes at oracle.com Mon May 14 06:22:39 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 May 2012 16:22:39 +1000 Subject: review request: 4244896: (process) Provide System.getPid(), System.killProcess(String pid) In-Reply-To: <4FAC0F5F.3090508@oracle.com> References: <4F861847.5080308@oracle.com> <4F869AD6.7010903@oracle.com>, <4F8D849E.8090607@oracle.com> <4F8F56E0.6020009@oracle.com> <4F8FF15E.9080408@oracle.com> <4FAC0F5F.3090508@oracle.com> Message-ID: <4FB0A4AF.1090401@oracle.com> Hi Rob, Your specification for Process.waitFor(long timeout, TimeUnit unit) has a conflict. You presently say: "If the subprocess has already exited then this method returns immediately with the value {@code true}" and you also say: "If the current thread: has its interrupted status set on entry to this method; or ... then {@link InterruptedException} is thrown and the current thread's interrupted status is cleared." It can't do both. The code implements the first statement. The IE will only be thrown if the thread will actually invoke sleep(). I suggest: + *

If the current thread: + *

    + *
  • has its interrupted status set when it would wait; or + *
  • is {@linkplain Thread#interrupt interrupted} while waiting, Also note that the documentation for: public abstract int waitFor() throws InterruptedException; should be updated to properly document its interruption response, in line with what is said for the waitFor(timeout) method. --- In UNIXProcess.java as noted already you haqve to deal with the fact that TimeUnit conversion routines truncate rather than round. I agree with your suggestion to use Math.max(TimeUnit.NANOSECONDS.toMillis(rem), 1). It's not worth splitting out into millis+nanos to use the other form of Object.wait(), and that form simply rounds to a millis value anyway. --- In ProcessImpl.java you should also apply suitable rounding rather than using waitForTimeoutInterruptibly(handle, unit.toMillis(timeout)); Also, as destroy() now states that its behaviour is implementation-dependent, the overriding destroy() should update its spec to clearly state that it does forceful termination. Hmmmm but that is useless as we are not dealing with public types ... Okay there is a slight problem here. You declared that destroy() has implementation-specific behaviour but there are no public subclasses that can clarify what actual behaviour is provided. In a similar vein, Process.waitFor(timeout) states that subclasses should override it to avoid the polling loop, and the implementations do, but they are non-public and so again there is no documention that the implementation is actually improved. I'm not sure what can be done about this. Perhaps add further implementation notes in Process.java to clarify what the JDK platform specific sub-class implementations so ??? --- In the test: 50 if ((isOS("sol") && p.exitValue() != 9) || 51 ((isOS("lin") || isOS("mac")) && p.exitValue() != 137)) How reliable are these exit values for each OS? And should we be checking for "mac" or "bsd", or both? Plus this test should fail if run on an unknown OS to indicate the test needs updating. 83 if(isOS("sol") || isOS("lin")) 84 test.killProc(false); // make sure the SIGTERM is trapped Where is the mac/bsd case? Should the platform specific parts be factored out -it would make the overall logic clearer I think. In ProcessKillTest.sh: - should this be used for windows? It's unclear to me if the logic here works given that we don't send a SIGTERM on windows. - I'm unclear if OSX/BSD are being handled correctly here too. Is "Darwin" always the right value to check?? - Regarding this fragment 64 if [ -f ${FILE_LOCATION}${FS}JDK64BIT -a ${OS} = "SunOS" ] 65 then 66 BIT_FLAG=`cat ${FILE_LOCATION}${FS}JDK64BIT` I seem to recall a recent discussion that indicated that JDK64BIT never exists and that this is some old construct that has fallen into disuse. Cheers, David ----- On 11/05/2012 4:56 AM, Rob McKenna wrote: > Hi folks, > > The latest version is at: > > http://cr.openjdk.java.net/~robm/4244896/webrev.03/ > > > Feedback greatly appreciated. > > -Rob > > On 19/04/12 12:05, Alan Bateman wrote: >> On 19/04/2012 01:05, David Holmes wrote: >>> On 18/04/2012 11:44 PM, Jason Mehrens wrote: >>>> >>>> Rob, >>>> >>>> It looks like waitFor is calling Object.wait(long) without owning >>>> this objects monitor. If I pass Long.MAX_VALUE to waitFor, shouldn't >>>> waitFor return if the early if the process ends? >>> >>> Also waitFor doesn't call wait() under the guard of a looping >>> predicate so it will suffer from lost signals and potentially >>> spurious wakeups. I also don't see anything calling notify[All] to >>> indicate the process has now terminated. It would appear that >>> wait(timeout) is being used as a sleep mechanism and that is wrong on >>> a number of levels. >> I assume waitFor(timout) will require 3 distinct implementations, one >> for Solaris/Linux/Mac, another for Windows, and a default >> implementations for Process implementations that exist outside of the >> JDK. >> >> It's likely the Solaris/Linux/Mac implementation will involve two >> threads, one to block in waitpid and the other to interrupt it via a >> signal if the timeout elapses before the child terminates. The Windows >> implementation should be trivial because it can be a timed wait. >> >> I assume the default implementation (which is what is being discussed >> here) will need to loop calling exitValue until the timeout elapses or >> the child terminates. Not very efficient but at least it won't be used >> when when creating Processes via Runtime.exec or ProcessBuilder. >> >> I think the question we need to consider is whether waitFor(timeout) >> is really needed. If it's something that it pushed out for another day >> then it brings up the question as to whether to include isAlive now or >> not (as waitFor without timeout gives us an isAlive equivalent too). >> >> -Alan. >> >> >> >> From chris.hegarty at oracle.com Mon May 14 09:28:32 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 14 May 2012 10:28:32 +0100 Subject: Code Review Request: 7164636: (prefs) Cleanup src/macosx/classes/java/util/prefs In-Reply-To: <4FAD88AD.4010002@oracle.com> References: <4FAD88AD.4010002@oracle.com> Message-ID: <4FB0D040.3070507@oracle.com> This change looks fine to me. Trivially, changedFiles and cachedFiles do not need to be set to null (I believe this will generate a little less bytecode), as this is the default reference value. Since you are in clean-up mode ;-) -Chris. On 11/05/2012 22:46, Kurchi Hazra wrote: > Hi, > > This change aims at removing some rawtype usages in > src/macosx/classes/java/util/prefs that were brought > into jdk8 with the macport. I have added @Override tags too where > applicable. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7164636 > Webrev: http://cr.openjdk.java.net/~khazra/7164636/webrev.00/ > > > Thanks, > Kurchi > From xuelei.fan at oracle.com Mon May 14 14:27:51 2012 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Mon, 14 May 2012 14:27:51 +0000 Subject: hg: jdk8/tl/jdk: 7167988: PKIX CertPathBuilder in reverse mode doesn't work if more than one trust anchor is specified Message-ID: <20120514142802.3D861472EA@hg.openjdk.java.net> Changeset: df3152beef2f Author: xuelei Date: 2012-05-14 07:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/df3152beef2f 7167988: PKIX CertPathBuilder in reverse mode doesn't work if more than one trust anchor is specified Reviewed-by: mullan ! src/share/classes/sun/security/provider/certpath/SunCertPathBuilder.java + test/sun/security/provider/certpath/ReverseBuilder/ReverseBuild.java From brian.goetz at oracle.com Mon May 14 16:41:54 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 14 May 2012 12:41:54 -0400 Subject: Code Review Request: 7164636: (prefs) Cleanup src/macosx/classes/java/util/prefs In-Reply-To: <4FB0D040.3070507@oracle.com> References: <4FAD88AD.4010002@oracle.com> <4FB0D040.3070507@oracle.com> Message-ID: <4FB135D2.8060803@oracle.com> From a concurrency perspective it is also preferable to NOT initialize variables to their default values, as doing so can cause some weird problems. For example: class A { public int x = 0; public void increment() { ++x; } public int get() { return x; } } // Thread X // Assume: Thread X never touches 'a' again A a = new A(); // Thread Y // Assume: No other thread than Y touches 'a' if (a != null) { a.increment(); System.out.println(a.get()); } With the explicit initialization, this code could print zero (because the set of writes to 'x' contains two writes, one by X to zero and one by Y to 1), whereas without the explicit initialization, it would always print one. Now, this is an example of "improper publication" of the A by Thread X, but this is the sort of improper publication (where an object was initialized by one thread and then "handed off" to another) that was widely thought to be safe a long time ago and was enshrined in many examples, particularly Swing examples. The sharing here is clearly wrong, but the approach of not unnecessarily initializing non-final fields eliminates a path to tickling the improper publication into actually producing the wrong result. On 5/14/2012 5:28 AM, Chris Hegarty wrote: > This change looks fine to me. > > Trivially, changedFiles and cachedFiles do not need to be set to null (I > believe this will generate a little less bytecode), as this is the > default reference value. Since you are in clean-up mode ;-) > > -Chris. > > On 11/05/2012 22:46, Kurchi Hazra wrote: >> Hi, >> >> This change aims at removing some rawtype usages in >> src/macosx/classes/java/util/prefs that were brought >> into jdk8 with the macport. I have added @Override tags too where >> applicable. >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7164636 >> Webrev: http://cr.openjdk.java.net/~khazra/7164636/webrev.00/ >> >> >> Thanks, >> Kurchi >> From chris.hegarty at oracle.com Mon May 14 17:07:46 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 14 May 2012 18:07:46 +0100 Subject: Code Review Request: 7164636: (prefs) Cleanup src/macosx/classes/java/util/prefs In-Reply-To: <4FB135D2.8060803@oracle.com> References: <4FAD88AD.4010002@oracle.com> <4FB0D040.3070507@oracle.com> <4FB135D2.8060803@oracle.com> Message-ID: <4FB13BE2.9040008@oracle.com> I always thought that removing these superfluous "default" values would be a good clean up opportunity. Maybe one to be added to the warnings/StringBuilder potential cleanup targets for external folks? -Chris. On 14/05/12 17:41, Brian Goetz wrote: > From a concurrency perspective it is also preferable to NOT initialize > variables to their default values, as doing so can cause some weird > problems. For example: > > class A { > public int x = 0; > > public void increment() { ++x; } > public int get() { return x; } > } > > // Thread X > // Assume: Thread X never touches 'a' again > A a = new A(); > > // Thread Y > // Assume: No other thread than Y touches 'a' > if (a != null) { > a.increment(); > System.out.println(a.get()); > } > > With the explicit initialization, this code could print zero (because > the set of writes to 'x' contains two writes, one by X to zero and one > by Y to 1), whereas without the explicit initialization, it would always > print one. > > Now, this is an example of "improper publication" of the A by Thread X, > but this is the sort of improper publication (where an object was > initialized by one thread and then "handed off" to another) that was > widely thought to be safe a long time ago and was enshrined in many > examples, particularly Swing examples. > > The sharing here is clearly wrong, but the approach of not unnecessarily > initializing non-final fields eliminates a path to tickling the improper > publication into actually producing the wrong result. > > On 5/14/2012 5:28 AM, Chris Hegarty wrote: >> This change looks fine to me. >> >> Trivially, changedFiles and cachedFiles do not need to be set to null (I >> believe this will generate a little less bytecode), as this is the >> default reference value. Since you are in clean-up mode ;-) >> >> -Chris. >> >> On 11/05/2012 22:46, Kurchi Hazra wrote: >>> Hi, >>> >>> This change aims at removing some rawtype usages in >>> src/macosx/classes/java/util/prefs that were brought >>> into jdk8 with the macport. I have added @Override tags too where >>> applicable. >>> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7164636 >>> Webrev: http://cr.openjdk.java.net/~khazra/7164636/webrev.00/ >>> >>> >>> Thanks, >>> Kurchi >>> From kurchi.subhra.hazra at oracle.com Mon May 14 20:00:11 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Mon, 14 May 2012 13:00:11 -0700 Subject: Code Review Request: 7164636: (prefs) Cleanup src/macosx/classes/java/util/prefs In-Reply-To: <4FB13BE2.9040008@oracle.com> References: <4FAD88AD.4010002@oracle.com> <4FB0D040.3070507@oracle.com> <4FB135D2.8060803@oracle.com> <4FB13BE2.9040008@oracle.com> Message-ID: <4FB1644B.4000905@oracle.com> Thanks for the detailed explanation. I have removed the default initializations: http://cr.openjdk.java.net/~khazra/7164636/webrev.01/ - Kurchi On 5/14/2012 10:07 AM, Chris Hegarty wrote: > I always thought that removing these superfluous "default" values > would be a good clean up opportunity. > > Maybe one to be added to the warnings/StringBuilder potential cleanup > targets for external folks? > > -Chris. > > On 14/05/12 17:41, Brian Goetz wrote: >> From a concurrency perspective it is also preferable to NOT initialize >> variables to their default values, as doing so can cause some weird >> problems. For example: >> >> class A { >> public int x = 0; >> >> public void increment() { ++x; } >> public int get() { return x; } >> } >> >> // Thread X >> // Assume: Thread X never touches 'a' again >> A a = new A(); >> >> // Thread Y >> // Assume: No other thread than Y touches 'a' >> if (a != null) { >> a.increment(); >> System.out.println(a.get()); >> } >> >> With the explicit initialization, this code could print zero (because >> the set of writes to 'x' contains two writes, one by X to zero and one >> by Y to 1), whereas without the explicit initialization, it would always >> print one. >> >> Now, this is an example of "improper publication" of the A by Thread X, >> but this is the sort of improper publication (where an object was >> initialized by one thread and then "handed off" to another) that was >> widely thought to be safe a long time ago and was enshrined in many >> examples, particularly Swing examples. >> >> The sharing here is clearly wrong, but the approach of not unnecessarily >> initializing non-final fields eliminates a path to tickling the improper >> publication into actually producing the wrong result. >> >> On 5/14/2012 5:28 AM, Chris Hegarty wrote: >>> This change looks fine to me. >>> >>> Trivially, changedFiles and cachedFiles do not need to be set to >>> null (I >>> believe this will generate a little less bytecode), as this is the >>> default reference value. Since you are in clean-up mode ;-) >>> >>> -Chris. >>> >>> On 11/05/2012 22:46, Kurchi Hazra wrote: >>>> Hi, >>>> >>>> This change aims at removing some rawtype usages in >>>> src/macosx/classes/java/util/prefs that were brought >>>> into jdk8 with the macport. I have added @Override tags too where >>>> applicable. >>>> >>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7164636 >>>> Webrev: http://cr.openjdk.java.net/~khazra/7164636/webrev.00/ >>>> >>>> >>>> Thanks, >>>> Kurchi >>>> -- -Kurchi From Roger.Riggs at oracle.com Mon May 14 20:40:33 2012 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 14 May 2012 16:40:33 -0400 Subject: JSR 310 Date and Time Method naming In-Reply-To: References: Message-ID: <4FB16DC1.1000301@oracle.com> Hi, JSR 310 is developing a new date and time API expected to be included in the JDK. We would appreciate your input to help refine the method naming alternatives. Please a take few minutes to give your input. http://www.rationalsurvey.com/s/3775 Thanks, Roger From david.holmes at oracle.com Tue May 15 02:24:33 2012 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 May 2012 12:24:33 +1000 Subject: Code Review Request: 7164636: (prefs) Cleanup src/macosx/classes/java/util/prefs In-Reply-To: <4FB135D2.8060803@oracle.com> References: <4FAD88AD.4010002@oracle.com> <4FB0D040.3070507@oracle.com> <4FB135D2.8060803@oracle.com> Message-ID: <4FB1BE61.5080501@oracle.com> On 15/05/2012 2:41 AM, Brian Goetz wrote: > From a concurrency perspective it is also preferable to NOT initialize > variables to their default values, as doing so can cause some weird > problems. For example: > > class A { > public int x = 0; > > public void increment() { ++x; } > public int get() { return x; } > } > > // Thread X > // Assume: Thread X never touches 'a' again > A a = new A(); > > // Thread Y > // Assume: No other thread than Y touches 'a' > if (a != null) { > a.increment(); > System.out.println(a.get()); > } > > With the explicit initialization, this code could print zero (because > the set of writes to 'x' contains two writes, one by X to zero and one > by Y to 1), whereas without the explicit initialization, it would always > print one. I do not agree. The above can only print zero if program-order is violated, which I don't believe it can or should be. But the "set of writes" is the same regardless of whether default or explicit initialization is used. The JMM explicitly states (17.4.4) that the write of the default value synchronizes with the first action in every thread and acts as-if each object were allocated and initialized to default values when the VM starts. > Now, this is an example of "improper publication" of the A by Thread X, > but this is the sort of improper publication (where an object was > initialized by one thread and then "handed off" to another) that was > widely thought to be safe a long time ago and was enshrined in many > examples, particularly Swing examples. > > The sharing here is clearly wrong, but the approach of not unnecessarily > initializing non-final fields eliminates a path to tickling the improper > publication into actually producing the wrong result. Initializing to a default value should be a no-op. I had thought javac already optimized these away but perhaps it is only the JIT. David ----- > On 5/14/2012 5:28 AM, Chris Hegarty wrote: >> This change looks fine to me. >> >> Trivially, changedFiles and cachedFiles do not need to be set to null (I >> believe this will generate a little less bytecode), as this is the >> default reference value. Since you are in clean-up mode ;-) >> >> -Chris. >> >> On 11/05/2012 22:46, Kurchi Hazra wrote: >>> Hi, >>> >>> This change aims at removing some rawtype usages in >>> src/macosx/classes/java/util/prefs that were brought >>> into jdk8 with the macport. I have added @Override tags too where >>> applicable. >>> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7164636 >>> Webrev: http://cr.openjdk.java.net/~khazra/7164636/webrev.00/ >>> >>> >>> Thanks, >>> Kurchi >>> From dmitriy.samersoff at oracle.com Tue May 15 12:49:20 2012 From: dmitriy.samersoff at oracle.com (dmitriy.samersoff at oracle.com) Date: Tue, 15 May 2012 12:49:20 +0000 Subject: hg: jdk8/tl/jdk: 7164191: properties.putAll API may fail with ConcurrentModifcationException on multi-thread scenario Message-ID: <20120515124941.2EF834731A@hg.openjdk.java.net> Changeset: df33f5f750ec Author: dsamersoff Date: 2012-05-15 16:46 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/df33f5f750ec 7164191: properties.putAll API may fail with ConcurrentModifcationException on multi-thread scenario Reviewed-by: dholmes, sla Contributed-by: Deven You ! src/share/classes/sun/management/Agent.java + test/sun/management/AgentCMETest.java From chris.hegarty at oracle.com Tue May 15 18:00:24 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 15 May 2012 19:00:24 +0100 Subject: Code Review Request: 7164636: (prefs) Cleanup src/macosx/classes/java/util/prefs In-Reply-To: <4FB1644B.4000905@oracle.com> References: <4FAD88AD.4010002@oracle.com> <4FB0D040.3070507@oracle.com> <4FB135D2.8060803@oracle.com> <4FB13BE2.9040008@oracle.com> <4FB1644B.4000905@oracle.com> Message-ID: <4FB299B8.5040306@oracle.com> On 14/05/12 21:00, Kurchi Hazra wrote: > Thanks for the detailed explanation. > I have removed the default initializations: > http://cr.openjdk.java.net/~khazra/7164636/webrev.01/ This looks fine to me. -Chris. > > - Kurchi > > On 5/14/2012 10:07 AM, Chris Hegarty wrote: >> I always thought that removing these superfluous "default" values >> would be a good clean up opportunity. >> >> Maybe one to be added to the warnings/StringBuilder potential cleanup >> targets for external folks? >> >> -Chris. >> >> On 14/05/12 17:41, Brian Goetz wrote: >>> From a concurrency perspective it is also preferable to NOT initialize >>> variables to their default values, as doing so can cause some weird >>> problems. For example: >>> >>> class A { >>> public int x = 0; >>> >>> public void increment() { ++x; } >>> public int get() { return x; } >>> } >>> >>> // Thread X >>> // Assume: Thread X never touches 'a' again >>> A a = new A(); >>> >>> // Thread Y >>> // Assume: No other thread than Y touches 'a' >>> if (a != null) { >>> a.increment(); >>> System.out.println(a.get()); >>> } >>> >>> With the explicit initialization, this code could print zero (because >>> the set of writes to 'x' contains two writes, one by X to zero and one >>> by Y to 1), whereas without the explicit initialization, it would always >>> print one. >>> >>> Now, this is an example of "improper publication" of the A by Thread X, >>> but this is the sort of improper publication (where an object was >>> initialized by one thread and then "handed off" to another) that was >>> widely thought to be safe a long time ago and was enshrined in many >>> examples, particularly Swing examples. >>> >>> The sharing here is clearly wrong, but the approach of not unnecessarily >>> initializing non-final fields eliminates a path to tickling the improper >>> publication into actually producing the wrong result. >>> >>> On 5/14/2012 5:28 AM, Chris Hegarty wrote: >>>> This change looks fine to me. >>>> >>>> Trivially, changedFiles and cachedFiles do not need to be set to >>>> null (I >>>> believe this will generate a little less bytecode), as this is the >>>> default reference value. Since you are in clean-up mode ;-) >>>> >>>> -Chris. >>>> >>>> On 11/05/2012 22:46, Kurchi Hazra wrote: >>>>> Hi, >>>>> >>>>> This change aims at removing some rawtype usages in >>>>> src/macosx/classes/java/util/prefs that were brought >>>>> into jdk8 with the macport. I have added @Override tags too where >>>>> applicable. >>>>> >>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7164636 >>>>> Webrev: http://cr.openjdk.java.net/~khazra/7164636/webrev.00/ >>>>> >>>>> >>>>> Thanks, >>>>> Kurchi >>>>> > From kurchi.subhra.hazra at oracle.com Tue May 15 18:52:37 2012 From: kurchi.subhra.hazra at oracle.com (kurchi.subhra.hazra at oracle.com) Date: Tue, 15 May 2012 18:52:37 +0000 Subject: hg: jdk8/tl/jdk: 7164636: (prefs) Cleanup src/macosx/classes/java/util/prefs Message-ID: <20120515185255.5F19F47323@hg.openjdk.java.net> Changeset: 9a18e318f95a Author: khazra Date: 2012-05-15 11:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9a18e318f95a 7164636: (prefs) Cleanup src/macosx/classes/java/util/prefs Summary: Remove rawtype usages and other code cleanup Reviewed-by: chegar, briangoetz ! src/macosx/classes/java/util/prefs/MacOSXPreferences.java ! src/macosx/classes/java/util/prefs/MacOSXPreferencesFactory.java ! src/macosx/classes/java/util/prefs/MacOSXPreferencesFile.java From alan.bateman at oracle.com Wed May 16 11:45:16 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 16 May 2012 11:45:16 +0000 Subject: hg: jdk8/tl/jdk: 7168505: (bf) MappedByteBuffer.load does not load buffer's content into memory Message-ID: <20120516114536.A425D4734C@hg.openjdk.java.net> Changeset: 332bebb463d1 Author: alanb Date: 2012-05-16 12:43 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/332bebb463d1 7168505: (bf) MappedByteBuffer.load does not load buffer's content into memory Reviewed-by: mduigou, forax ! src/share/classes/java/nio/MappedByteBuffer.java From Dmitry.Samersoff at oracle.com Thu May 17 07:44:37 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 17 May 2012 11:44:37 +0400 Subject: sun.management.Agent: the properties.putAll API may fail with ConcurrentModifcationException on multi-thread scenario In-Reply-To: <4F98A320.2030803@linux.vnet.ibm.com> References: <4F853485.7020607@linux.vnet.ibm.com> <4F863945.7020701@oracle.com> <4F8D1CBC.5040205@linux.vnet.ibm.com> <4F8E5282.3070507@oracle.com> <4F8E5D34.8050901@linux.vnet.ibm.com> <4F94EE8B.8070101@linux.vnet.ibm.com> <4F94F70D.1060906@oracle.com> <4F94F880.2020206@oracle.com> <4F95080C.7090007@linux.vnet.ibm.com> <4F969953.9090107@oracle.com> <4F97EEDE.7050102@oracle.com> <4F98A320.2030803@linux.vnet.ibm.com> Message-ID: <4FB4AC65.7090906@oracle.com> Deven, The fix is submitted to openjdk tl workspace http://hg.openjdk.java.net/jdk8/tl/jdk/rev/df33f5f750ec -Dmitry On 2012-04-26 05:21, Deven You wrote: > Hi Dmitry, > > Thanks for your help. I have created a CR with internal id 2236492 which > hasn't be published yet. So please set this internal CR id as duplicate > to 716419 as well. > > This is the original mail for this problem: > > > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Hi core-libs-devs, > > I am not sure if sun.management.Agent belongs to jmx-dev mailing list, > if so please anyone tell me. > > This issue is that the sun.management.Agent.loadManagementProperties() > will invoke properties.putAll which will throw > ConcurrentModifcationException if there are other threads which modify > the properties concurrently. > > I have made a patch[1] which synchronize the sysProps so that putAll can > work on multi-thread scenario. The test case is also available in [1]. > > Thanks a lot! > > [1] http://cr.openjdk.java.net/~littlee/OJDK-256/webrev.00 > > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > > Thanks a lot! > > > > On 04/25/2012 08:32 PM, Dmitry Samersoff wrote: >> Deven, >> >> CR number is 7164191 . >> >> Could you re-send me your original e-mail with problem description and >> webrev link. >> >> I'll put it to CR comment field. >> >> >> -Dmitry >> >> >> >> On 2012-04-24 16:15, Dmitry Samersoff wrote: >>> Deven, >>> >>> After close look and off-line discussion with David Holmes, >>> the changes looks good for me. >>> >>> I'll take care of the rest. >>> >>> We have one more place in Agent.java executing exactly the same code >>> so I'll change both of them on your behalf. >>> >>> -Dmitry >>> >>> >>> On 2012-04-23 11:43, Deven You wrote: >>>> Thanks David, >>>> >>>> So is it ok for you to contribute this patch? >>>> >>>> On 04/23/2012 02:36 PM, David Holmes wrote: >>>>> Except of course that Properties is a Hashtable and synchronizes on >>>>> 'this' for all public methods. So locking the properties object in the >>>>> client code will guarantee exclusive access to it. >>>>> >>>>> Sorry about that. >>>>> >>>>> David >>>>> ----- >>>>> >>>>> On 23/04/2012 4:30 PM, David Holmes wrote: >>>>>> Deven, >>>>>> >>>>>> On 23/04/2012 3:54 PM, Deven You wrote: >>>>>>> On 04/18/2012 02:20 PM, Deven You wrote: >>>>>>>> On 04/18/2012 01:34 PM, Mandy Chung wrote: >>>>>>>>> >>>>>>>>> I think this could still run into CME. System Properties is not a >>>>>>>>> synchronized map and the setter methods (System.setProperty or >>>>>>>>> Properties.put method) doesn't synchronize on the Properties >>>>>>>>> object. >>>>>>>>> >>>>>>>>> >>>>>>>>> The setter methods I'm referring to are System.setProperty and >>>>>>>>> System.getProperties().put(). >>>>>>>>> >>>>>>>> I have gone through the Agent.java, I think other set/put methods >>>>>>>> related to properties are protected properly. >>>>>>>> >>>>>>>> public static void agentmain using parseString(args) which return a >>>>>>>> properties which is a local var and is not possible to cause >>>>>>>> concurrent problem when call config_props.putAll(arg_props). >>>>>>>> >>>>>>>> private static synchronized void startLocalManagementAgent() is >>>>>>>> synchronized already. >>>>>>>> >>>>>>>> private static synchronized void startRemoteManagementAgent(String >>>>>>>> args) is synchronized also. >>>>>>>> >>>>>>>> Could you point where the CME may ocurr? >>>>>>> Is there any suggestion from the mailing list? >>>>>> The problem is that System.getProperties() returns a globally >>>>>> accessible >>>>>> set of properties. So even if you prevent the Agent code from >>>>>> modifying >>>>>> those properties concurrently with other use in the Agent, you >>>>>> have no >>>>>> such guard for any other piece of code in the system which might also >>>>>> modify the properties. So the race condition you were trying to fix >>>>>> still exists. I don't see any way to fix this. No matter what you do >>>>>> another thread can modify the system properties while you are >>>>>> iterating >>>>>> them. Instead you need to anticipate the CME and try to recover >>>>>> from it >>>>>> (also non-trivial). >>>>>> >>>>>> Cheers, >>>>>> David Holmes >>>> >>> >> > > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From youdwei at linux.vnet.ibm.com Thu May 17 07:58:39 2012 From: youdwei at linux.vnet.ibm.com (Deven You) Date: Thu, 17 May 2012 15:58:39 +0800 Subject: sun.management.Agent: the properties.putAll API may fail with ConcurrentModifcationException on multi-thread scenario In-Reply-To: <4FB4AC65.7090906@oracle.com> References: <4F853485.7020607@linux.vnet.ibm.com> <4F863945.7020701@oracle.com> <4F8D1CBC.5040205@linux.vnet.ibm.com> <4F8E5282.3070507@oracle.com> <4F8E5D34.8050901@linux.vnet.ibm.com> <4F94EE8B.8070101@linux.vnet.ibm.com> <4F94F70D.1060906@oracle.com> <4F94F880.2020206@oracle.com> <4F95080C.7090007@linux.vnet.ibm.com> <4F969953.9090107@oracle.com> <4F97EEDE.7050102@oracle.com> <4F98A320.2030803@linux.vnet.ibm.com> <4FB4AC65.7090906@oracle.com> Message-ID: <4FB4AFAF.5030709@linux.vnet.ibm.com> Hi Dmitry, I have verified the change set. Thanks for your commit! On 05/17/2012 03:44 PM, Dmitry Samersoff wrote: > Deven, > > The fix is submitted to openjdk tl workspace > > http://hg.openjdk.java.net/jdk8/tl/jdk/rev/df33f5f750ec > > -Dmitry > > > On 2012-04-26 05:21, Deven You wrote: >> Hi Dmitry, >> >> Thanks for your help. I have created a CR with internal id 2236492 which >> hasn't be published yet. So please set this internal CR id as duplicate >> to 716419 as well. >> >> This is the original mail for this problem: >> >> >> >> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >> >> Hi core-libs-devs, >> >> I am not sure if sun.management.Agent belongs to jmx-dev mailing list, >> if so please anyone tell me. >> >> This issue is that the sun.management.Agent.loadManagementProperties() >> will invoke properties.putAll which will throw >> ConcurrentModifcationException if there are other threads which modify >> the properties concurrently. >> >> I have made a patch[1] which synchronize the sysProps so that putAll can >> work on multi-thread scenario. The test case is also available in [1]. >> >> Thanks a lot! >> >> [1] http://cr.openjdk.java.net/~littlee/OJDK-256/webrev.00 >> >> >> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >> >> >> Thanks a lot! >> >> >> >> On 04/25/2012 08:32 PM, Dmitry Samersoff wrote: >>> Deven, >>> >>> CR number is 7164191 . >>> >>> Could you re-send me your original e-mail with problem description and >>> webrev link. >>> >>> I'll put it to CR comment field. >>> >>> >>> -Dmitry >>> >>> >>> >>> On 2012-04-24 16:15, Dmitry Samersoff wrote: >>>> Deven, >>>> >>>> After close look and off-line discussion with David Holmes, >>>> the changes looks good for me. >>>> >>>> I'll take care of the rest. >>>> >>>> We have one more place in Agent.java executing exactly the same code >>>> so I'll change both of them on your behalf. >>>> >>>> -Dmitry >>>> >>>> >>>> On 2012-04-23 11:43, Deven You wrote: >>>>> Thanks David, >>>>> >>>>> So is it ok for you to contribute this patch? >>>>> >>>>> On 04/23/2012 02:36 PM, David Holmes wrote: >>>>>> Except of course that Properties is a Hashtable and synchronizes on >>>>>> 'this' for all public methods. So locking the properties object in the >>>>>> client code will guarantee exclusive access to it. >>>>>> >>>>>> Sorry about that. >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>> On 23/04/2012 4:30 PM, David Holmes wrote: >>>>>>> Deven, >>>>>>> >>>>>>> On 23/04/2012 3:54 PM, Deven You wrote: >>>>>>>> On 04/18/2012 02:20 PM, Deven You wrote: >>>>>>>>> On 04/18/2012 01:34 PM, Mandy Chung wrote: >>>>>>>>>> I think this could still run into CME. System Properties is not a >>>>>>>>>> synchronized map and the setter methods (System.setProperty or >>>>>>>>>> Properties.put method) doesn't synchronize on the Properties >>>>>>>>>> object. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The setter methods I'm referring to are System.setProperty and >>>>>>>>>> System.getProperties().put(). >>>>>>>>>> >>>>>>>>> I have gone through the Agent.java, I think other set/put methods >>>>>>>>> related to properties are protected properly. >>>>>>>>> >>>>>>>>> public static void agentmain using parseString(args) which return a >>>>>>>>> properties which is a local var and is not possible to cause >>>>>>>>> concurrent problem when call config_props.putAll(arg_props). >>>>>>>>> >>>>>>>>> private static synchronized void startLocalManagementAgent() is >>>>>>>>> synchronized already. >>>>>>>>> >>>>>>>>> private static synchronized void startRemoteManagementAgent(String >>>>>>>>> args) is synchronized also. >>>>>>>>> >>>>>>>>> Could you point where the CME may ocurr? >>>>>>>> Is there any suggestion from the mailing list? >>>>>>> The problem is that System.getProperties() returns a globally >>>>>>> accessible >>>>>>> set of properties. So even if you prevent the Agent code from >>>>>>> modifying >>>>>>> those properties concurrently with other use in the Agent, you >>>>>>> have no >>>>>>> such guard for any other piece of code in the system which might also >>>>>>> modify the properties. So the race condition you were trying to fix >>>>>>> still exists. I don't see any way to fix this. No matter what you do >>>>>>> another thread can modify the system properties while you are >>>>>>> iterating >>>>>>> them. Instead you need to anticipate the CME and try to recover >>>>>>> from it >>>>>>> (also non-trivial). >>>>>>> >>>>>>> Cheers, >>>>>>> David Holmes >> > -- Best Regards, Deven From daniel.daugherty at oracle.com Thu May 17 14:59:51 2012 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Thu, 17 May 2012 14:59:51 +0000 Subject: hg: jdk8/tl/jdk: 7168520: No jdk8 TL Nightly linux builds due to broken link in b39-2012-05-13_231 Message-ID: <20120517150002.474624738B@hg.openjdk.java.net> Changeset: ce165aa48dcb Author: dcubed Date: 2012-05-17 06:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ce165aa48dcb 7168520: No jdk8 TL Nightly linux builds due to broken link in b39-2012-05-13_231 Summary: ZIP libjsig.debuginfo links into libjsig.diz files since aurora doesn't like dangling symlinks Reviewed-by: katleman ! make/java/redist/Makefile From rob.mckenna at oracle.com Thu May 17 21:40:58 2012 From: rob.mckenna at oracle.com (rob.mckenna at oracle.com) Date: Thu, 17 May 2012 21:40:58 +0000 Subject: hg: jdk8/tl/jdk: 7168110: Misleading jstack error message Message-ID: <20120517214108.601F94739F@hg.openjdk.java.net> Changeset: 178c480998b1 Author: robm Date: 2012-05-17 22:42 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/178c480998b1 7168110: Misleading jstack error message Reviewed-by: alanb, dsamersoff ! src/windows/native/sun/tools/attach/WindowsVirtualMachine.c From xuelei.fan at oracle.com Fri May 18 05:00:42 2012 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Fri, 18 May 2012 05:00:42 +0000 Subject: hg: jdk8/tl/jdk: 7145960: sun/security/mscapi/ShortRSAKey1024.sh failing on windows Message-ID: <20120518050052.B838E473D0@hg.openjdk.java.net> Changeset: 9fe6ebbe5895 Author: xuelei Date: 2012-05-17 21:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9fe6ebbe5895 7145960: sun/security/mscapi/ShortRSAKey1024.sh failing on windows Reviewed-by: vinnie, wetmore ! test/sun/security/mscapi/ShortRSAKey1024.sh ! test/sun/security/mscapi/ShortRSAKey512.sh ! test/sun/security/mscapi/ShortRSAKey768.sh From valerie.peng at oracle.com Fri May 18 19:49:05 2012 From: valerie.peng at oracle.com (valerie.peng at oracle.com) Date: Fri, 18 May 2012 19:49:05 +0000 Subject: hg: jdk8/tl/jdk: 7169496: Problem with the SHA-224 support for SunMSCAPI provider Message-ID: <20120518194916.6B505473ED@hg.openjdk.java.net> Changeset: af1030be726a Author: valeriep Date: 2012-05-18 12:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/af1030be726a 7169496: Problem with the SHA-224 support for SunMSCAPI provider Summary: Remove SHA224withRSA signature from SunMSCAPI provider due to lack of windows support. Reviewed-by: vinnie ! src/windows/classes/sun/security/mscapi/RSASignature.java ! src/windows/classes/sun/security/mscapi/SunMSCAPI.java ! test/sun/security/mscapi/SignUsingNONEwithRSA.java ! test/sun/security/mscapi/SignUsingSHA2withRSA.java From kumar.x.srinivasan at oracle.COM Fri May 18 22:04:14 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Fri, 18 May 2012 15:04:14 -0700 Subject: Please review (EZ): 7170087: tools/launcher/Arrghs.java test has wrong bugID for 7151434 Message-ID: <4FB6C75E.6070801@oracle.COM> Hi, Fixed CR reference in test. http://cr.openjdk.java.net/~ksrini/7170087/ The original changset for reference. http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f68c854fa584 Thanks in advance. Kumar From kelly.ohair at oracle.com Fri May 18 23:39:31 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Fri, 18 May 2012 16:39:31 -0700 Subject: Please review (EZ): 7170087: tools/launcher/Arrghs.java test has wrong bugID for 7151434 In-Reply-To: <4FB6C75E.6070801@oracle.COM> References: <4FB6C75E.6070801@oracle.COM> Message-ID: Change looks fine to me. -kto On May 18, 2012, at 3:04 PM, Kumar Srinivasan wrote: > Hi, > > Fixed CR reference in test. > > http://cr.openjdk.java.net/~ksrini/7170087/ > > The original changset for reference. > http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f68c854fa584 > > Thanks in advance. > > Kumar > From i30817 at gmail.com Mon May 21 07:13:04 2012 From: i30817 at gmail.com (Paulo Levi) Date: Mon, 21 May 2012 08:13:04 +0100 Subject: Long standing String.trim() bug Message-ID: Just hit me now, from a utf-8 document http://closingbraces.net/2008/11/11/javastringtrim/ Anyway, any plans to deprecate trim() and add a new one? I for one would refactor all my projects with it. From weijun.wang at oracle.com Mon May 21 07:41:17 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Mon, 21 May 2012 07:41:17 +0000 Subject: hg: jdk8/tl/jdk: 7170308: timing error in the krb5 test SSL.java Message-ID: <20120521074127.D574B47424@hg.openjdk.java.net> Changeset: 72af24348b2b Author: weijun Date: 2012-05-21 15:40 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/72af24348b2b 7170308: timing error in the krb5 test SSL.java Reviewed-by: xuelei ! test/sun/security/krb5/auto/SSL.java From alan.bateman at oracle.com Mon May 21 09:42:42 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 21 May 2012 09:42:42 +0000 Subject: hg: jdk8/tl/jdk: 7170203: TEST_BUG: test/java/nio/MappedByteBuffer/Truncate.java failing intermittently Message-ID: <20120521094309.40EA347426@hg.openjdk.java.net> Changeset: 9cb304dd71d4 Author: alanb Date: 2012-05-21 10:41 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9cb304dd71d4 7170203: TEST_BUG: test/java/nio/MappedByteBuffer/Truncate.java failing intermittently Reviewed-by: chegar ! test/java/nio/MappedByteBuffer/Truncate.java From kumar.x.srinivasan at oracle.com Mon May 21 16:41:15 2012 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Mon, 21 May 2012 16:41:15 +0000 Subject: hg: jdk8/tl/jdk: 7170087: tools/launcher/Arrghs.java test has wrong bugID for 7151434 Message-ID: <20120521164139.5E9C747444@hg.openjdk.java.net> Changeset: f109feb13698 Author: ksrini Date: 2012-05-21 09:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f109feb13698 7170087: tools/launcher/Arrghs.java test has wrong bugID for 7151434 Reviewed-by: ohair ! test/tools/launcher/Arrrghs.java From staffan.larsen at oracle.com Mon May 21 17:29:21 2012 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Mon, 21 May 2012 17:29:21 +0000 Subject: hg: jdk8/tl/jdk: 7167157: jcmd command file parsing does not respect the "stop" command Message-ID: <20120521172931.4584047447@hg.openjdk.java.net> Changeset: 0a1ef7e07e01 Author: sla Date: 2012-05-21 19:28 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0a1ef7e07e01 7167157: jcmd command file parsing does not respect the "stop" command Reviewed-by: alanb, dsamersoff, nloodin ! src/share/classes/sun/tools/jcmd/JCmd.java From kurchi.subhra.hazra at oracle.com Wed May 23 01:32:23 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Tue, 22 May 2012 18:32:23 -0700 Subject: Code Review Request: 7170169: (props) System.getProperty("os.name") should return "Windows 8" when run on Windows 8 Message-ID: <4FBC3E27.7000106@oracle.com> Hi, This is a minor change to java_props_md.c to return "Windows 8" as the "os.name" for Windows version 6.2. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7170169 Webrev: http://cr.openjdk.java.net/~khazra/7170169/webrev.00/ Thanks, Kurchi From joe.darcy at oracle.com Wed May 23 01:57:28 2012 From: joe.darcy at oracle.com (Joseph Darcy) Date: Tue, 22 May 2012 18:57:28 -0700 Subject: Code Review Request: 7170169: (props) System.getProperty("os.name") should return "Windows 8" when run on Windows 8 In-Reply-To: <4FBC3E27.7000106@oracle.com> References: <4FBC3E27.7000106@oracle.com> Message-ID: <4FBC4408.5050204@oracle.com> Hi Kurchi, Looks fine, -Joe On 5/22/2012 6:32 PM, Kurchi Hazra wrote: > Hi, > > This is a minor change to java_props_md.c to return "Windows 8" as > the "os.name" for Windows version 6.2. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7170169 > Webrev: http://cr.openjdk.java.net/~khazra/7170169/webrev.00/ > > Thanks, > Kurchi > From david.holmes at oracle.com Wed May 23 02:33:48 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 23 May 2012 12:33:48 +1000 Subject: Code Review Request: 7170169: (props) System.getProperty("os.name") should return "Windows 8" when run on Windows 8 In-Reply-To: <4FBC3E27.7000106@oracle.com> References: <4FBC3E27.7000106@oracle.com> Message-ID: <4FBC4C8C.70506@oracle.com> On 23/05/2012 11:32 AM, Kurchi Hazra wrote: > Hi, > > This is a minor change to java_props_md.c to return "Windows 8" as the > "os.name" for Windows version 6.2. Is there any windows version specific code that might also need updating to allow for Windows 8 aka 6.2? David > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7170169 > Webrev: http://cr.openjdk.java.net/~khazra/7170169/webrev.00/ > > Thanks, > Kurchi > From kurchi.subhra.hazra at oracle.com Wed May 23 03:02:30 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Subhra Hazra) Date: Tue, 22 May 2012 20:02:30 -0700 Subject: Code Review Request: 7170169: (props) System.getProperty("os.name") should return "Windows 8" when run on Windows 8 In-Reply-To: <4FBC4C8C.70506@oracle.com> References: <4FBC3E27.7000106@oracle.com> <4FBC4C8C.70506@oracle.com> Message-ID: <4FBC5346.7020404@oracle.com> I ran the tests in jdk/test/java/lang and they all pass. Let me know if you think some other tests should also be run. - Kurchi On 5/22/12 7:33 PM, David Holmes wrote: > On 23/05/2012 11:32 AM, Kurchi Hazra wrote: >> Hi, >> >> This is a minor change to java_props_md.c to return "Windows 8" as the >> "os.name" for Windows version 6.2. > > Is there any windows version specific code that might also need > updating to allow for Windows 8 aka 6.2? > > David > >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7170169 >> Webrev: http://cr.openjdk.java.net/~khazra/7170169/webrev.00/ >> >> Thanks, >> Kurchi >> From david.holmes at oracle.com Wed May 23 03:04:57 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 23 May 2012 13:04:57 +1000 Subject: Code Review Request: 7170169: (props) System.getProperty("os.name") should return "Windows 8" when run on Windows 8 In-Reply-To: <4FBC5346.7020404@oracle.com> References: <4FBC3E27.7000106@oracle.com> <4FBC4C8C.70506@oracle.com> <4FBC5346.7020404@oracle.com> Message-ID: <4FBC53D9.7090404@oracle.com> On 23/05/2012 1:02 PM, Kurchi Subhra Hazra wrote: > I ran the tests in jdk/test/java/lang and they all pass. Let me know if > you think some other tests should also be run. I would think AWT/Swing is the place most likely to have version specific workarounds. David > > - Kurchi > > On 5/22/12 7:33 PM, David Holmes wrote: >> On 23/05/2012 11:32 AM, Kurchi Hazra wrote: >>> Hi, >>> >>> This is a minor change to java_props_md.c to return "Windows 8" as the >>> "os.name" for Windows version 6.2. >> >> Is there any windows version specific code that might also need >> updating to allow for Windows 8 aka 6.2? >> >> David >> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7170169 >>> Webrev: http://cr.openjdk.java.net/~khazra/7170169/webrev.00/ >>> >>> Thanks, >>> Kurchi >>> > From mike.duigou at oracle.com Wed May 23 05:16:18 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 22 May 2012 22:16:18 -0700 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps Message-ID: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> Dear OpenJDK CoreLibs community, A significant enhancement to the Java SE hashing-based Map implementations in planned for inclusion in Java SE 7u6. All of the hashing based Map implementations: HashMap, Hashtable, LinkedHashMap, WeakHashMap and ConcurrentHashMap will now use an enhanced hashing algorithm for string keys when the capacity of the hash table has ever grown beyond 512 entries. The enhanced hashing implementation uses the murmur3 hashing algorithm[1] along with random hash seeds and index masks. These enhancements mitigate cases where colliding String hash values could result in a performance bottleneck. In order to provide the greatest opportunity for developers to test compatibility with their applications this change will be incorporated into JDK7u6 build 12 and JDK8 build 39. Both builds are planned for release next week. ***For 7u6 build 12 only, the alternative hashing will be unconditionally enabled (always on).*** The threshold default will be reset to the intended release default (512) for 7u6 build 13. The quick promotion of this change into builds with limited opportunity for public review and the special behaviour for build 12 is intended to make it easier for developers to test their application compatibility. Feedback on the approach, implementation, compatibility and performance is eagerly sought and encouraged both before *and after* this change is incorporated into the OpenJDK repositories. A new system property, jdk.map.althashing.threshold, allows adjustment of the threshold for enabling the enhanced hashing algorithm. If changed from the default value of 512, the enhanced hashing will be invoked any time after map capacity exceeds the value of jdk.map.althashing.threshold. To completely disable the enhanced hashing (not recommended), set jdk.map.althashing.threshold to -1 or a very large number such as 2^31 -1 (Integer.MAX_VALUE). The iteration order of keys, values and entries for hash-based maps where the new algorithm has been invoked will vary for each HashMap instance. While the Java SE Map documentation makes no promises that iteration order of items returned from Maps will be consistent, developers should check if their applications have incorrectly created a dependency on the iteration order of Map entries, keys or values. Webrevs for the Java 7u6 and 8 changes are available for download at [2] and [3] for your review. There are some important differences between the Java 7 and 8 implementations of this enhancement. Most specifically in the Java 8 implementation alternative string hashing is always enabled--no threshold is used for enablement and alternative hashing cannot be disabled. (The Java 8 implementation completely ignores the jdk.map.althashing.threshold system property). The Java 8 implementation is also subject to additional refinement as Java 8 develops. If you have any questions or concerns with this planned enhancement, please use the corelibs development mailing list, , or you may also respond privately to me if you prefer. Thanks, Mike [1] Murmur3 : https://code.google.com/p/smhasher/wiki/MurmurHash3 [2] althashing "7" webrev : http://cr.openjdk.java.net/~mduigou/althashing7/8/webrev/ [3] althashing "8" webrev : http://cr.openjdk.java.net/~mduigou/althashing8/8/webrev/ From mike.skells at talk21.com Wed May 23 07:38:39 2012 From: mike.skells at talk21.com (Mike Skells) Date: Wed, 23 May 2012 08:38:39 +0100 (BST) Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps In-Reply-To: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> Message-ID: <1337758719.27301.YahooMailNeo@web87704.mail.ir2.yahoo.com> Hi Mike, I have a query, why is this implementation limitted to String? Is this by intent? in HashMap the patch for hash calculation is? ?290 ? ? final int hash(Object k) { ?291 ? ? ? ? int h = hashMask; ?292 ? ? ? ? if ((0 != h) && (k instanceof String)) { ?293 ? ? ? ? ? ? return h ^ ((String)k).hash32(); .... whereas I would have thought that it should be? ?290 ? ? final int hash(Object k) { ?291 ? ? ? ? int h = hashMask; ?292 ? ? ? ? if ((0 != h) && (k instanceof Hash32)) { ?293 ? ? ? ? ? ? return h ^ ((Hash32)k).hash32(); .... As a more flexible improvement could you supply a HashCode and Equals delegate, and then the user can supply either a custom delegate, suitable for that application (e.g.one that iterates through array content, or any other application data structure that needs to be handled differently like c# uses http://msdn.microsoft.com/en-us/library/system.collections.iequalitycomparer ) Regards Mike From Alan.Bateman at oracle.com Wed May 23 07:49:32 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 May 2012 08:49:32 +0100 Subject: Code Review Request: 7170169: (props) System.getProperty("os.name") should return "Windows 8" when run on Windows 8 In-Reply-To: <4FBC4C8C.70506@oracle.com> References: <4FBC3E27.7000106@oracle.com> <4FBC4C8C.70506@oracle.com> Message-ID: <4FBC968C.4070900@oracle.com> On 23/05/2012 03:33, David Holmes wrote: > On 23/05/2012 11:32 AM, Kurchi Hazra wrote: >> Hi, >> >> This is a minor change to java_props_md.c to return "Windows 8" as the >> "os.name" for Windows version 6.2. > > Is there any windows version specific code that might also need > updating to allow for Windows 8 aka 6.2? The changes look fine to me. David - I'm sure that Windows 8 will bring surprises but so far the only one that we know of for the "core" area is: 7096436: (sc) SocketChannel.connect fails on Windows 8 when channel configured non-blocking Kurchi pushed a fix for that a few weeks ago. I'm sure other issues (client area in particular) will be found once folks start to run tests and use Windows 8 in anger. -Alan. From weijun.wang at oracle.com Wed May 23 07:52:32 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Wed, 23 May 2012 07:52:32 +0000 Subject: hg: jdk8/tl/jdk: 7162687: enhance KDC server availability detection Message-ID: <20120523075252.C982747490@hg.openjdk.java.net> Changeset: a2fc04c2dfc8 Author: weijun Date: 2012-05-23 15:51 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a2fc04c2dfc8 7162687: enhance KDC server availability detection Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/KdcComm.java ! src/share/classes/sun/security/krb5/internal/NetClient.java ! test/ProblemList.txt ! test/sun/security/krb5/auto/BadKdc.java ! test/sun/security/krb5/auto/MaxRetries.java ! test/sun/security/krb5/auto/TcpTimeout.java + test/sun/security/krb5/auto/Unreachable.java + test/sun/security/krb5/auto/unreachable.krb5.conf From paul.sandoz at oracle.com Wed May 23 08:27:51 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 23 May 2012 10:27:51 +0200 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps In-Reply-To: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> Message-ID: <162AF8B1-40FF-412C-B964-16FD9DD5C435@oracle.com> Hi Mike, On May 23, 2012, at 7:16 AM, Mike Duigou wrote: > [3] althashing "8" webrev : http://cr.openjdk.java.net/~mduigou/althashing8/8/webrev/ Can the private method HashMap.getForNullKey be removed? Paul. From chris.hegarty at oracle.com Wed May 23 08:56:35 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 23 May 2012 09:56:35 +0100 Subject: Code Review Request: 7170169: (props) System.getProperty("os.name") should return "Windows 8" when run on Windows 8 In-Reply-To: <4FBC3E27.7000106@oracle.com> References: <4FBC3E27.7000106@oracle.com> Message-ID: <4FBCA643.7070901@oracle.com> Looks fine to me. -Chris. On 23/05/2012 02:32, Kurchi Hazra wrote: > Hi, > > This is a minor change to java_props_md.c to return "Windows 8" as the > "os.name" for Windows version 6.2. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7170169 > Webrev: http://cr.openjdk.java.net/~khazra/7170169/webrev.00/ > > Thanks, > Kurchi > From forax at univ-mlv.fr Wed May 23 10:42:31 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 23 May 2012 12:42:31 +0200 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps In-Reply-To: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> Message-ID: <4FBCBF17.4030403@univ-mlv.fr> Hi Mike, these comments are for jdk8, I have no time currently to take a look to jdk7 counterpart. First, why do you change make/java/java/Makefile ? In java.lang.String, when you compute the HASHING_SEED in the static block, you should ensure that it's never zero in the static block instead of doing it in hash32(). In HashMap, the class Holder should not declare the static final fields 'private' because the compiler will generate an accessor in that case, again musn.misc.Hashing.makeHashMask should never return 0 to avoid the check in hashObject(). I suppose that the cast to j.l.String in hashObject() should be a cast to Hashable32 otherwise I don't see the purpose to introduce such interface (note that WeakHashMap used Hashable32 correctly). Also, this change - return h ^ (h>>> 7) ^ (h>>> 4); + h ^= (h>>> 7) ^ (h>>> 4); + + return h; will make the compiler generates an additional iload/istore pair. While the Jitted code will be the same, it may bother the inlining heuristic. I think the code in get() was explicitly hand-inlined to avoid perf glitch, that's why the current code is not Entry entry = getEntry(key); return null == entry ? null : entry.getValue(); but may be this is not needed anymore. i don't know. In transfer, we are not in C++, you can write while(e != null) instead of while(null != e) with no fear :) I've a kind of meta-question, why you have one HASHMASK_OFFSET by hash map implementations instead of one to rule them all. Can you explain why you don't need to resize anymore in LinkedHashMap.addEntry(), I'm too lazy to figure this out by myself. In WeakHashMap.Entry, why hash is not declared 'final' anymore ? cheers, R?mi On 05/23/2012 07:16 AM, Mike Duigou wrote: > Dear OpenJDK CoreLibs community, > > A significant enhancement to the Java SE hashing-based Map implementations in planned for inclusion in Java SE 7u6. All of the hashing based Map implementations: HashMap, Hashtable, LinkedHashMap, WeakHashMap and ConcurrentHashMap will now use an enhanced hashing algorithm for string keys when the capacity of the hash table has ever grown beyond 512 entries. The enhanced hashing implementation uses the murmur3 hashing algorithm[1] along with random hash seeds and index masks. These enhancements mitigate cases where colliding String hash values could result in a performance bottleneck. > > In order to provide the greatest opportunity for developers to test compatibility with their applications this change will be incorporated into JDK7u6 build 12 and JDK8 build 39. Both builds are planned for release next week. ***For 7u6 build 12 only, the alternative hashing will be unconditionally enabled (always on).*** The threshold default will be reset to the intended release default (512) for 7u6 build 13. > > The quick promotion of this change into builds with limited opportunity for public review and the special behaviour for build 12 is intended to make it easier for developers to test their application compatibility. Feedback on the approach, implementation, compatibility and performance is eagerly sought and encouraged both before *and after* this change is incorporated into the OpenJDK repositories. > > A new system property, jdk.map.althashing.threshold, allows adjustment of the threshold for enabling the enhanced hashing algorithm. If changed from the default value of 512, the enhanced hashing will be invoked any time after map capacity exceeds the value of jdk.map.althashing.threshold. To completely disable the enhanced hashing (not recommended), set jdk.map.althashing.threshold to -1 or a very large number such as 2^31 -1 (Integer.MAX_VALUE). > > The iteration order of keys, values and entries for hash-based maps where the new algorithm has been invoked will vary for each HashMap instance. While the Java SE Map documentation makes no promises that iteration order of items returned from Maps will be consistent, developers should check if their applications have incorrectly created a dependency on the iteration order of Map entries, keys or values. > > Webrevs for the Java 7u6 and 8 changes are available for download at [2] and [3] for your review. There are some important differences between the Java 7 and 8 implementations of this enhancement. Most specifically in the Java 8 implementation alternative string hashing is always enabled--no threshold is used for enablement and alternative hashing cannot be disabled. (The Java 8 implementation completely ignores the jdk.map.althashing.threshold system property). The Java 8 implementation is also subject to additional refinement as Java 8 develops. > > If you have any questions or concerns with this planned enhancement, please use the corelibs development mailing list,, or you may also respond privately to me if you prefer. > > Thanks, > > Mike > > [1] Murmur3 : https://code.google.com/p/smhasher/wiki/MurmurHash3 > [2] althashing "7" webrev : http://cr.openjdk.java.net/~mduigou/althashing7/8/webrev/ > [3] althashing "8" webrev : http://cr.openjdk.java.net/~mduigou/althashing8/8/webrev/ From mike.duigou at oracle.com Wed May 23 16:24:28 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 23 May 2012 09:24:28 -0700 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps In-Reply-To: <1337758719.27301.YahooMailNeo@web87704.mail.ir2.yahoo.com> References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> <1337758719.27301.YahooMailNeo@web87704.mail.ir2.yahoo.com> Message-ID: Hi Mike; The problem with using instanceof Hashable32 is that is much slower (often more than 25X) than instanceof String. It's slow enough that we won't reasonably consider using instanceof Hashable32 in JDK 8. We have considered making Object implement Hashable32 and add a virtual extension method to Object for hash32(). The extension method would just call hashCode(). A compiler that supports extension methods is not yet part of the JDK mainline repo yet (It is still in the Lambda repo). This approach would mean that we can avoid an instanceof check but there is a *lot* of entirely reasonable reservations about having Object implement an interface and gain a new method. Opinions and insights welcome, Mike On May 23 2012, at 00:38 , Mike Skells wrote: > Hi Mike, > > I have a query, why is this implementation limitted to String? > Is this by intent? > > in HashMap the patch for hash calculation is > 290 final int hash(Object k) { > 291 int h = hashMask; > 292 if ((0 != h) && (k instanceof String)) { > 293 return h ^ ((String)k).hash32(); > .... > whereas I would have thought that it should be > 290 final int hash(Object k) { > 291 int h = hashMask; > 292 if ((0 != h) && (k instanceof Hash32)) { > 293 return h ^ ((Hash32)k).hash32(); > .... > > As a more flexible improvement could you supply a HashCode and Equals delegate, and then the user can supply either a custom delegate, suitable for that application (e.g.one that iterates through array content, or any other application data structure that needs to be handled differently like c# uses http://msdn.microsoft.com/en-us/library/system.collections.iequalitycomparer ) > > Regards > > Mike From kurchi.subhra.hazra at oracle.com Wed May 23 17:42:35 2012 From: kurchi.subhra.hazra at oracle.com (kurchi.subhra.hazra at oracle.com) Date: Wed, 23 May 2012 17:42:35 +0000 Subject: hg: jdk8/tl/jdk: 7170169: (props) System.getProperty("os.name") should return "Windows 8" when run on Windows 8 Message-ID: <20120523174245.9C036474A0@hg.openjdk.java.net> Changeset: 0c3d9050c918 Author: khazra Date: 2012-05-23 10:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0c3d9050c918 7170169: (props) System.getProperty("os.name") should return "Windows 8" when run on Windows 8 Summary: Enable Windows Version 6.2 to be recognized as Windows 8 Reviewed-by: darcy, dholmes, alanb, chegar ! src/windows/native/java/lang/java_props_md.c From mike.duigou at oracle.com Wed May 23 19:03:03 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 23 May 2012 12:03:03 -0700 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps In-Reply-To: <4FBCBF17.4030403@univ-mlv.fr> References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> <4FBCBF17.4030403@univ-mlv.fr> Message-ID: Hi Remi; As always, thank you for the valuable feedback. On May 23 2012, at 03:42 , R?mi Forax wrote: > Hi Mike, > these comments are for jdk8, I have no time currently to take a look to jdk7 counterpart. > > First, why do you change make/java/java/Makefile ? It was temporary and should no longer be needed. There was skew between my patch and the java.utils warnings cleanup for a while. I will make sure that this change can be removed. I won't commit without making sure that the Makefile change is not required. > > In java.lang.String, when you compute the HASHING_SEED in the static block, > you should ensure that it's never zero in the static block instead of doing it > in hash32(). These are different seeds. The zero value is a signal that alternative hashing is disabled. > In HashMap, the class Holder should not declare the static final fields 'private' > because the compiler will generate an accessor in that case, I will fix this. > again musn.misc.Hashing.makeHashMask should never return 0 to avoid > the check in hashObject(). > > I suppose that the cast to j.l.String in hashObject() should be a cast to Hashable32 > otherwise I don't see the purpose to introduce such interface > (note that WeakHashMap used Hashable32 correctly). I responded to this issue to Mike Skells question. Repeating that response: The problem with using instanceof Hashable32 is that is much slower (often more than 25X) than instanceof String. It's slow enough that we won't reasonably consider using instanceof Hashable32 in JDK 8. We have considered making Object implement Hashable32 and add a virtual extension method to Object for hash32(). The extension method would just call hashCode(). A compiler that supports extension methods is not yet part of the JDK mainline repo yet (It is still in the Lambda repo). This approach would mean that we can avoid an instanceof check but there is a *lot* of entirely reasonable reservations about having Object implement an interface and gain a new method. The actually solution which will be used in Java 8 is TBD. Using instanceof String is interim solution. > Also, this change > > - return h ^ (h>>> 7) ^ (h>>> 4); > + h ^= (h>>> 7) ^ (h>>> 4); > + > + return h; > > will make the compiler generates an additional iload/istore pair. > While the Jitted code will be the same, it may bother the inlining heuristic. I will fix this. > > I think the code in get() was explicitly hand-inlined to avoid perf glitch, > that's why the current code is not > > Entry entry = getEntry(key); > return null == entry ? null : entry.getValue(); > > but may be this is not needed anymore. i don't know. I did microbenchmarking early in the development of this patch which showed that getForNullKey() was not needed. > > In transfer, we are not in C++, you can write > > while(e != null) > > instead of > > while(null != e) > > with no fear :) Habit. I still accidentally use 'if (e = null)' once every year or so and hate myself when I discover that was the problem. I know that some people hate these "Yoda" style expressions checks. (http://wiert.me/2010/05/25/yoda-conditions-from-stackoverflow-new-programming-jargon-you-coined/) > I've a kind of meta-question, why you have one HASHMASK_OFFSET by hash map > implementations instead of one to rule them all. I am not sure how they can be unified except to put the field into AbstractMap which would be unacceptable. > Can you explain why you don't need to resize anymore in LinkedHashMap.addEntry(), > I'm too lazy to figure this out by myself. The location of the resize check moved slightly. > In WeakHashMap.Entry, why hash is not declared 'final' anymore ? Mis-port from JDK 7 version which needs it to be non-final for rehashing. It can be final in the JDK 8 version. > > cheers, > R?mi > > On 05/23/2012 07:16 AM, Mike Duigou wrote: >> Dear OpenJDK CoreLibs community, >> >> A significant enhancement to the Java SE hashing-based Map implementations in planned for inclusion in Java SE 7u6. All of the hashing based Map implementations: HashMap, Hashtable, LinkedHashMap, WeakHashMap and ConcurrentHashMap will now use an enhanced hashing algorithm for string keys when the capacity of the hash table has ever grown beyond 512 entries. The enhanced hashing implementation uses the murmur3 hashing algorithm[1] along with random hash seeds and index masks. These enhancements mitigate cases where colliding String hash values could result in a performance bottleneck. >> >> In order to provide the greatest opportunity for developers to test compatibility with their applications this change will be incorporated into JDK7u6 build 12 and JDK8 build 39. Both builds are planned for release next week. ***For 7u6 build 12 only, the alternative hashing will be unconditionally enabled (always on).*** The threshold default will be reset to the intended release default (512) for 7u6 build 13. >> >> The quick promotion of this change into builds with limited opportunity for public review and the special behaviour for build 12 is intended to make it easier for developers to test their application compatibility. Feedback on the approach, implementation, compatibility and performance is eagerly sought and encouraged both before *and after* this change is incorporated into the OpenJDK repositories. >> >> A new system property, jdk.map.althashing.threshold, allows adjustment of the threshold for enabling the enhanced hashing algorithm. If changed from the default value of 512, the enhanced hashing will be invoked any time after map capacity exceeds the value of jdk.map.althashing.threshold. To completely disable the enhanced hashing (not recommended), set jdk.map.althashing.threshold to -1 or a very large number such as 2^31 -1 (Integer.MAX_VALUE). >> >> The iteration order of keys, values and entries for hash-based maps where the new algorithm has been invoked will vary for each HashMap instance. While the Java SE Map documentation makes no promises that iteration order of items returned from Maps will be consistent, developers should check if their applications have incorrectly created a dependency on the iteration order of Map entries, keys or values. >> >> Webrevs for the Java 7u6 and 8 changes are available for download at [2] and [3] for your review. There are some important differences between the Java 7 and 8 implementations of this enhancement. Most specifically in the Java 8 implementation alternative string hashing is always enabled--no threshold is used for enablement and alternative hashing cannot be disabled. (The Java 8 implementation completely ignores the jdk.map.althashing.threshold system property). The Java 8 implementation is also subject to additional refinement as Java 8 develops. >> >> If you have any questions or concerns with this planned enhancement, please use the corelibs development mailing list,, or you may also respond privately to me if you prefer. >> >> Thanks, >> >> Mike >> >> [1] Murmur3 : https://code.google.com/p/smhasher/wiki/MurmurHash3 >> [2] althashing "7" webrev : http://cr.openjdk.java.net/~mduigou/althashing7/8/webrev/ >> [3] althashing "8" webrev : http://cr.openjdk.java.net/~mduigou/althashing8/8/webrev/ > From david.holmes at oracle.com Wed May 23 23:31:44 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 24 May 2012 09:31:44 +1000 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps In-Reply-To: References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> <1337758719.27301.YahooMailNeo@web87704.mail.ir2.yahoo.com> Message-ID: <4FBD7360.4050306@oracle.com> On 24/05/2012 2:24 AM, Mike Duigou wrote: > Hi Mike; > > The problem with using instanceof Hashable32 is that is much slower (often more than 25X) than instanceof String. It's slow enough that we won't reasonably consider using instanceof Hashable32 in JDK 8. We have considered making Object implement Hashable32 and add a virtual extension method to Object for hash32(). The extension method would just call hashCode(). A compiler that supports extension methods is not yet part of the JDK mainline repo yet (It is still in the Lambda repo). This approach would mean that we can avoid an instanceof check but there is a *lot* of entirely reasonable reservations about having Object implement an interface and gain a new method. Is it worth using: && (k instanceof String || k instanceof Hash32) to deal with that. What would be the penalty on non-String Hash32's? David > Opinions and insights welcome, > > Mike > > On May 23 2012, at 00:38 , Mike Skells wrote: > >> Hi Mike, >> >> I have a query, why is this implementation limitted to String? >> Is this by intent? >> >> in HashMap the patch for hash calculation is >> 290 final int hash(Object k) { >> 291 int h = hashMask; >> 292 if ((0 != h)&& (k instanceof String)) { >> 293 return h ^ ((String)k).hash32(); >> .... >> whereas I would have thought that it should be >> 290 final int hash(Object k) { >> 291 int h = hashMask; >> 292 if ((0 != h)&& (k instanceof Hash32)) { >> 293 return h ^ ((Hash32)k).hash32(); >> .... >> >> As a more flexible improvement could you supply a HashCode and Equals delegate, and then the user can supply either a custom delegate, suitable for that application (e.g.one that iterates through array content, or any other application data structure that needs to be handled differently like c# uses http://msdn.microsoft.com/en-us/library/system.collections.iequalitycomparer ) >> >> Regards >> >> Mike > From Ulf.Zibis at gmx.de Wed May 23 23:58:07 2012 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 24 May 2012 01:58:07 +0200 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps In-Reply-To: References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> <4FBCBF17.4030403@univ-mlv.fr> Message-ID: <4FBD798F.5010009@gmx.de> Hi, What about making this approach a little bit more general? See: Bug 6812862 - provide customizable hash() algorithm in HashMap for speed tuning + all later comments. Then you additionally could save: if ((0 != h) && (k instanceof String)) Looking at the codes of many charsets, the main variance seems to be in the lower 8 bits of a character, especially if the strings belong to the same language. So if we would compose the initial 32-bit values from 4 chars then the murmur3 algorithm could perform almost twice faster. If you alter all hash maps in JDK to use a new hash value, which noteworthy use cases remain to use the legacy hashcode()? Do we really need 2 hash fields in String? In project coin, we have set in stone to use compile time hashes for Strings_in_switch extension. So it never can't profit from the murmur3 optimization. IMO: what a pity! (Prominent people have said, it will never make sense to change the String's hash algorithm.) See: http://markmail.org/message/ig3nzmfinfuvgbwz http://markmail.org/message/h3nlhhae5qlmf37a Am 23.05.2012 21:03, schrieb Mike Duigou: >> Also, this change >> >> - return h ^ (h>>> 7) ^ (h>>> 4); >> + h ^= (h>>> 7) ^ (h>>> 4); >> + >> + return h; >> >> will make the compiler generates an additional iload/istore pair. >> While the Jitted code will be the same, it may bother the inlining heuristic. Wouldn' t return (h ^= (h>>> 7) ^ (h>>> 4)); have the same effect ? Anyway, please add a comment for later readers. -Ulf From mike.duigou at oracle.com Thu May 24 00:22:53 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 23 May 2012 17:22:53 -0700 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps In-Reply-To: <4FBD798F.5010009@gmx.de> References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> <4FBCBF17.4030403@univ-mlv.fr> <4FBD798F.5010009@gmx.de> Message-ID: <67A0646D-0E50-4FFF-9D60-E063E94445CF@oracle.com> On May 23 2012, at 16:58 , Ulf Zibis wrote: > Hi, > > What about making this approach a little bit more general? > See: Bug 6812862 - provide customizable hash() algorithm in HashMap for speed tuning It is possible for JDK 8. One option is to provide the hash() method as a virtual extension method on Map allowing implementations to override it. > + all later comments. > Then you additionally could save: > if ((0 != h) && (k instanceof String)) > > Looking at the codes of many charsets, the main variance seems to be in the lower 8 bits of a character, especially if the strings belong to the same language. So if we would compose the initial 32-bit values from 4 chars then the murmur3 algorithm could perform almost twice faster. Interesting idea. The description specifically avoids defining the behaviour so implementations can do this kind of optimization. For 7u6, unless there are technical problems, the proposed. implementation is sufficient. The important message though is that it can be changed later. > > If you alter all hash maps in JDK to use a new hash value, which noteworthy use cases remain to use the legacy hashcode()? Compatibility (which is of paramount importance). Part of the difficulty is that the String.hashCode() calculation method is part of the specification. Changing the specification is possible but probably not practical. > Do we really need 2 hash fields in String? Performance without caching the hash code result is unacceptable. (I've tried it). > In project coin, we have set in stone to use compile time hashes for Strings_in_switch extension. So it never can't profit from the murmur3 optimization. IMO: what a pity! > (Prominent people have said, it will never make sense to change the String's hash algorithm.) > See: http://markmail.org/message/ig3nzmfinfuvgbwz > http://markmail.org/message/h3nlhhae5qlmf37a Yes, there other other reasons as well. Mike > > > Am 23.05.2012 21:03, schrieb Mike Duigou: >> >>> Also, this change >>> >>> - return h ^ (h>>> 7) ^ (h>>> 4); >>> + h ^= (h>>> 7) ^ (h>>> 4); >>> + >>> + return h; >>> >>> will make the compiler generates an additional iload/istore pair. >>> While the Jitted code will be the same, it may bother the inlining heuristic. > Wouldn' t > return (h ^= (h>>> 7) ^ (h>>> 4)); > have the same effect ? > > Anyway, please add a comment for later readers. > > -Ulf > From Ulf.Zibis at gmx.de Thu May 24 00:46:31 2012 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 24 May 2012 02:46:31 +0200 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps In-Reply-To: <67A0646D-0E50-4FFF-9D60-E063E94445CF@oracle.com> References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> <4FBCBF17.4030403@univ-mlv.fr> <4FBD798F.5010009@gmx.de> <67A0646D-0E50-4FFF-9D60-E063E94445CF@oracle.com> Message-ID: <4FBD84E7.6020107@gmx.de> Am 24.05.2012 02:22, schrieb Mike Duigou: > > On May 23 2012, at 16:58 , Ulf Zibis wrote: > >> Hi, >> >> What about making this approach a little bit more general? >> See: Bug 6812862 >> - provide customizable hash() >> algorithm in HashMap for speed tuning > > It is possible for JDK 8. One option is to provide the hash() method as a virtual extension method > on Map allowing implementations to override it. Oh, these are good news. But I don't think all Maps need such a method, e.g. TreeMap. >> If you alter all hash maps in JDK to use a new hash value, which noteworthy use cases remain to >> use the legacy hashcode()? > > Compatibility (which is of paramount importance). Part of the difficulty is that the > String.hashCode() calculation method is part of the specification. Changing the specification is > possible but probably not practical. > >> Do we really need 2 hash fields in String? > > Performance without caching the hash code result is unacceptable. (I've tried it). I didn't think about saving the cashing, I thought about cashing the new hash in the existing old field in context of my upper question. Maybe we could drop caching the legacy one, if now rarely used. > >> In project coin, we have set in stone to use compile time hashes for Strings_in_switch extension. >> So it never can't profit from the murmur3 optimization. IMO: what a pity! >> (Prominent people have said, it will never make sense to change the String's hash algorithm.) >> See: http://markmail.org/message/ig3nzmfinfuvgbwz >> http://markmail.org/message/h3nlhhae5qlmf37a > > Yes, there other other reasons as well. I was one of those, who objected the compile time hashes O:-) -Ulf P.S.: have you seen my question + suggestion on the very bottom ... > > Mike > >> >> >> Am 23.05.2012 21:03, schrieb Mike Duigou: >>>> Also, this change >>>> >>>> - return h ^ (h>>> 7) ^ (h>>> 4); >>>> + h ^= (h>>> 7) ^ (h>>> 4); >>>> + >>>> + return h; >>>> >>>> will make the compiler generates an additional iload/istore pair. >>>> While the Jitted code will be the same, it may bother the inlining heuristic. >> Wouldn' t >> return (h ^= (h>>> 7) ^ (h>>> 4)); >> have the same effect ? >> >> Anyway, please add a comment for later readers. >> >> -Ulf >> > From Ulf.Zibis at gmx.de Thu May 24 01:03:15 2012 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 24 May 2012 03:03:15 +0200 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps In-Reply-To: <67A0646D-0E50-4FFF-9D60-E063E94445CF@oracle.com> References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> <4FBCBF17.4030403@univ-mlv.fr> <4FBD798F.5010009@gmx.de> <67A0646D-0E50-4FFF-9D60-E063E94445CF@oracle.com> Message-ID: <4FBD88D3.8060003@gmx.de> Am 24.05.2012 02:22, schrieb Mike Duigou: >> Looking at the codes of many charsets, the main variance seems to be in the lower 8 bits of a >> character, especially if the strings belong to the same language. So if we would compose the >> initial 32-bit values from 4 chars then the murmur3 algorithm could perform almost twice faster. > > Interesting idea. The description specifically avoids defining the behaviour so implementations > can do this kind of optimization. For 7u6, unless there are technical problems, the proposed. > implementation is sufficient. The important message though is that it can be changed later. And as improvement for the following: 58 int k1 = (data[offset] & 0x0FF) 59 | (data[offset + 1] & 0x0FF) << 8 60 | (data[offset + 2] & 0x0FF) << 16 61 | data[offset + 3] << 24; See: Bug 6914113 - Copy int to byte[] in 1 step -Ulf From alan.bateman at oracle.com Thu May 24 12:44:52 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 24 May 2012 12:44:52 +0000 Subject: hg: jdk8/tl/jdk: 7169050: (se) Selector.select slow on Solaris due to insertion of POLLREMOVE and 0 events Message-ID: <20120524124502.74760474C1@hg.openjdk.java.net> Changeset: 21703d431217 Author: alanb Date: 2012-05-24 10:57 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/21703d431217 7169050: (se) Selector.select slow on Solaris due to insertion of POLLREMOVE and 0 events Reviewed-by: chegar, coffeys ! src/solaris/classes/sun/nio/ch/DevPollArrayWrapper.java ! src/solaris/native/sun/nio/ch/DevPollArrayWrapper.c From alan.bateman at oracle.com Thu May 24 13:45:35 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 24 May 2012 13:45:35 +0000 Subject: hg: jdk8/tl/jdk: 7160725: Strange or obsolete @see tags in some exception java.lang javadoc Message-ID: <20120524134553.D7082474C5@hg.openjdk.java.net> Changeset: a11c964d1319 Author: jgish Date: 2012-05-24 14:44 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a11c964d1319 7160725: Strange or obsolete @see tags in some exception java.lang javadoc Summary: update javadoc for IllegalArgumentException and NumberFormatException Reviewed-by: alanb ! src/share/classes/java/lang/IllegalArgumentException.java From nils.loodin at oracle.com Thu May 24 14:21:40 2012 From: nils.loodin at oracle.com (nils.loodin at oracle.com) Date: Thu, 24 May 2012 14:21:40 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20120524142201.04CAA474C6@hg.openjdk.java.net> Changeset: 5ec5588c733d Author: nloodin Date: 2012-05-24 09:32 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5ec5588c733d 7143353: -Xrunhprof fails in Java 7 due to bad switch Reviewed-by: jrose, sspitsyn ! src/share/demo/jvmti/java_crw_demo/java_crw_demo.c ! src/share/javavm/export/classfile_constants.h Changeset: 1c869c799ef9 Author: nloodin Date: 2012-05-24 10:20 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1c869c799ef9 Merge From mike.duigou at oracle.com Thu May 24 19:34:32 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 24 May 2012 12:34:32 -0700 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps In-Reply-To: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> Message-ID: <94E7336B-91D6-4191-84EA-C9B668B0D172@oracle.com> Hello All; I have updated the webrevs for alternative hashing for String with feedback from Remi, Doug, Ulf and internal reviewers. Additional feedback is welcome. Mike [1] althashing "7" webrev : http://cr.openjdk.java.net/~mduigou/althashing7/9/webrev/ [2] althashing "8" webrev : http://cr.openjdk.java.net/~mduigou/althashing8/9/webrev/ On May 22 2012, at 22:16 , Mike Duigou wrote: > Dear OpenJDK CoreLibs community, > > A significant enhancement to the Java SE hashing-based Map implementations in planned for inclusion in Java SE 7u6. All of the hashing based Map implementations: HashMap, Hashtable, LinkedHashMap, WeakHashMap and ConcurrentHashMap will now use an enhanced hashing algorithm for string keys when the capacity of the hash table has ever grown beyond 512 entries. The enhanced hashing implementation uses the murmur3 hashing algorithm[1] along with random hash seeds and index masks. These enhancements mitigate cases where colliding String hash values could result in a performance bottleneck. > > In order to provide the greatest opportunity for developers to test compatibility with their applications this change will be incorporated into JDK7u6 build 12 and JDK8 build 39. Both builds are planned for release next week. ***For 7u6 build 12 only, the alternative hashing will be unconditionally enabled (always on).*** The threshold default will be reset to the intended release default (512) for 7u6 build 13. > > The quick promotion of this change into builds with limited opportunity for public review and the special behaviour for build 12 is intended to make it easier for developers to test their application compatibility. Feedback on the approach, implementation, compatibility and performance is eagerly sought and encouraged both before *and after* this change is incorporated into the OpenJDK repositories. > > A new system property, jdk.map.althashing.threshold, allows adjustment of the threshold for enabling the enhanced hashing algorithm. If changed from the default value of 512, the enhanced hashing will be invoked any time after map capacity exceeds the value of jdk.map.althashing.threshold. To completely disable the enhanced hashing (not recommended), set jdk.map.althashing.threshold to -1 or a very large number such as 2^31 -1 (Integer.MAX_VALUE). > > The iteration order of keys, values and entries for hash-based maps where the new algorithm has been invoked will vary for each HashMap instance. While the Java SE Map documentation makes no promises that iteration order of items returned from Maps will be consistent, developers should check if their applications have incorrectly created a dependency on the iteration order of Map entries, keys or values. > > Webrevs for the Java 7u6 and 8 changes are available for download at [2] and [3] for your review. There are some important differences between the Java 7 and 8 implementations of this enhancement. Most specifically in the Java 8 implementation alternative string hashing is always enabled--no threshold is used for enablement and alternative hashing cannot be disabled. (The Java 8 implementation completely ignores the jdk.map.althashing.threshold system property). The Java 8 implementation is also subject to additional refinement as Java 8 develops. > > If you have any questions or concerns with this planned enhancement, please use the corelibs development mailing list, , or you may also respond privately to me if you prefer. > > Thanks, > > Mike > > [1] Murmur3 : https://code.google.com/p/smhasher/wiki/MurmurHash3 > [2] althashing "7" webrev : http://cr.openjdk.java.net/~mduigou/althashing7/8/webrev/ > [3] althashing "8" webrev : http://cr.openjdk.java.net/~mduigou/althashing8/8/webrev/ From mike.duigou at oracle.com Thu May 24 20:45:09 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 24 May 2012 13:45:09 -0700 Subject: Request for Review : CR#6924259: Remove String.count/String.offset Message-ID: <1D5C5BC1-C6E8-4807-9D5B-2530CDEAD479@oracle.com> Hello all; For a long time preparations and planing have been underway to remove the offset and count fields from java.lang.String. These two fields enable multiple String instances to share the same backing character buffer. Shared character buffers were an important optimization for old benchmarks but with current real world code and benchmarks it's actually better to not share backing buffers. Shared char array backing buffers only "win" with very heavy use of String.substring. The negatively impacted situations can include parsers and compilers however current testing shows that overall this change is beneficial. The current plan is to commit this change to jdk8 before build 40 followed by jdk7u6. Removing offset/count is a complicated process because HotSpot has special case code for String that depends upon the two fields. Vladimir Kozlov has committed the required HotSpot changes already (http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/8f972594effc). A patch of the changes to java.lang.String for JDK 8 are at . The changes for JDK 7 have only superficial differences (line offsets in the patch). Comments are welcome. Mike From mike.duigou at oracle.com Thu May 24 21:26:08 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 24 May 2012 14:26:08 -0700 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps In-Reply-To: <4FBD7360.4050306@oracle.com> References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> <1337758719.27301.YahooMailNeo@web87704.mail.ir2.yahoo.com> <4FBD7360.4050306@oracle.com> Message-ID: On May 23 2012, at 16:31 , David Holmes wrote: > On 24/05/2012 2:24 AM, Mike Duigou wrote: >> Hi Mike; >> >> The problem with using instanceof Hashable32 is that is much slower (often more than 25X) than instanceof String. It's slow enough that we won't reasonably consider using instanceof Hashable32 in JDK 8. We have considered making Object implement Hashable32 and add a virtual extension method to Object for hash32(). The extension method would just call hashCode(). A compiler that supports extension methods is not yet part of the JDK mainline repo yet (It is still in the Lambda repo). This approach would mean that we can avoid an instanceof check but there is a *lot* of entirely reasonable reservations about having Object implement an interface and gain a new method. > > Is it worth using: > > && (k instanceof String || k instanceof Hash32) > > to deal with that. What would be the penalty on non-String Hash32's? The problem in this case would be the k instances that are neither String nor Hash32. They would be severely impacted. Using Doug Lea's "loops" Map microbenchmark, "k instanceof Hash32" was up to 25 times more expensive than calling "k instanceof String". I suspect that it could be even higher with classes that have deep inheritance hierarchies. My non-Hash32 keys were all instances of Number (Float, Double, Integer and Long) so each had a single interface. Mike > David > >> Opinions and insights welcome, >> >> Mike >> >> On May 23 2012, at 00:38 , Mike Skells wrote: >> >>> Hi Mike, >>> >>> I have a query, why is this implementation limitted to String? >>> Is this by intent? >>> >>> in HashMap the patch for hash calculation is >>> 290 final int hash(Object k) { >>> 291 int h = hashMask; >>> 292 if ((0 != h)&& (k instanceof String)) { >>> 293 return h ^ ((String)k).hash32(); >>> .... >>> whereas I would have thought that it should be >>> 290 final int hash(Object k) { >>> 291 int h = hashMask; >>> 292 if ((0 != h)&& (k instanceof Hash32)) { >>> 293 return h ^ ((Hash32)k).hash32(); >>> .... >>> >>> As a more flexible improvement could you supply a HashCode and Equals delegate, and then the user can supply either a custom delegate, suitable for that application (e.g.one that iterates through array content, or any other application data structure that needs to be handled differently like c# uses http://msdn.microsoft.com/en-us/library/system.collections.iequalitycomparer ) >>> >>> Regards >>> >>> Mike >> From Ulf.Zibis at gmx.de Thu May 24 22:56:05 2012 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 25 May 2012 00:56:05 +0200 Subject: Request for Review : CR#6924259: Remove String.count/String.offset In-Reply-To: <1D5C5BC1-C6E8-4807-9D5B-2530CDEAD479@oracle.com> References: <1D5C5BC1-C6E8-4807-9D5B-2530CDEAD479@oracle.com> Message-ID: <4FBEBC85.4050104@gmx.de> Am 24.05.2012 22:45, schrieb Mike Duigou: > A patch of the changes to java.lang.String for JDK 8 are at. The changes for JDK 7 have only superficial differences (line offsets in the patch). Correct Copyright date. 157 public String(String original) { 158 this.value = (original.value.length> 0) 159 ? original.value 160 : EMPTY_STRING_VALUE; 145 161 } Does the last case ever occur?, if you have: 143 public String() { 144 this.value = EMPTY_STRING_VALUE; 145 } -Ulf From mike.duigou at oracle.com Thu May 24 23:11:40 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 24 May 2012 16:11:40 -0700 Subject: Request for Review : CR#6924259: Remove String.count/String.offset In-Reply-To: <4FBEBC85.4050104@gmx.de> References: <1D5C5BC1-C6E8-4807-9D5B-2530CDEAD479@oracle.com> <4FBEBC85.4050104@gmx.de> Message-ID: On May 24 2012, at 15:56 , Ulf Zibis wrote: > Am 24.05.2012 22:45, schrieb Mike Duigou: >> A patch of the changes to java.lang.String for JDK 8 are at. The changes for JDK 7 have only superficial differences (line offsets in the patch). > Correct Copyright date. > > 157 public String(String original) { > 158 this.value = (original.value.length> 0) > 159 ? original.value > 160 : EMPTY_STRING_VALUE; 145 > 161 } > > Does the last case ever occur?, if you have: It can occur in cases where original is - a deserialized string - a string from a class file constant pool - the string constant "" - (new StringBuilder()).toString() and other empty string generators. From vitalyd at gmail.com Thu May 24 23:32:11 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 24 May 2012 19:32:11 -0400 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps In-Reply-To: References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> <1337758719.27301.YahooMailNeo@web87704.mail.ir2.yahoo.com> <4FBD7360.4050306@oracle.com> Message-ID: That's a bit odd as I thought the Klass object in the VM stored something like 7 supers, which includes interfaces (if I'm not mistaken). I know that instanceof checks against final classes are optimized into a simple cmp against an address, but I'm surprised that a check against an interface for classes in a very shallow type hierarchy is up to x25 slower. Do you know why that is Mike? Did you ask the compiler guys by chance? Thanks Sent from my phone On May 24, 2012 5:26 PM, "Mike Duigou" wrote: > > On May 23 2012, at 16:31 , David Holmes wrote: > > > On 24/05/2012 2:24 AM, Mike Duigou wrote: > >> Hi Mike; > >> > >> The problem with using instanceof Hashable32 is that is much slower > (often more than 25X) than instanceof String. It's slow enough that we > won't reasonably consider using instanceof Hashable32 in JDK 8. We have > considered making Object implement Hashable32 and add a virtual extension > method to Object for hash32(). The extension method would just call > hashCode(). A compiler that supports extension methods is not yet part of > the JDK mainline repo yet (It is still in the Lambda repo). This approach > would mean that we can avoid an instanceof check but there is a *lot* of > entirely reasonable reservations about having Object implement an interface > and gain a new method. > > > > Is it worth using: > > > > && (k instanceof String || k instanceof Hash32) > > > > to deal with that. What would be the penalty on non-String Hash32's? > > The problem in this case would be the k instances that are neither String > nor Hash32. They would be severely impacted. Using Doug Lea's "loops" Map > microbenchmark, "k instanceof Hash32" was up to 25 times more expensive > than calling "k instanceof String". I suspect that it could be even higher > with classes that have deep inheritance hierarchies. My non-Hash32 keys > were all instances of Number (Float, Double, Integer and Long) so each had > a single interface. > > Mike > > > David > > > >> Opinions and insights welcome, > >> > >> Mike > >> > >> On May 23 2012, at 00:38 , Mike Skells wrote: > >> > >>> Hi Mike, > >>> > >>> I have a query, why is this implementation limitted to String? > >>> Is this by intent? > >>> > >>> in HashMap the patch for hash calculation is > >>> 290 final int hash(Object k) { > >>> 291 int h = hashMask; > >>> 292 if ((0 != h)&& (k instanceof String)) { > >>> 293 return h ^ ((String)k).hash32(); > >>> .... > >>> whereas I would have thought that it should be > >>> 290 final int hash(Object k) { > >>> 291 int h = hashMask; > >>> 292 if ((0 != h)&& (k instanceof Hash32)) { > >>> 293 return h ^ ((Hash32)k).hash32(); > >>> .... > >>> > >>> As a more flexible improvement could you supply a HashCode and Equals > delegate, and then the user can supply either a custom delegate, suitable > for that application (e.g.one that iterates through array content, or any > other application data structure that needs to be handled differently like > c# uses > http://msdn.microsoft.com/en-us/library/system.collections.iequalitycomparer) > >>> > >>> Regards > >>> > >>> Mike > >> > > From mike.duigou at oracle.com Fri May 25 02:12:57 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 24 May 2012 19:12:57 -0700 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps In-Reply-To: References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> <1337758719.27301.YahooMailNeo@web87704.mail.ir2.yahoo.com> <4FBD7360.4050306@oracle.com> Message-ID: <7BB1802F-0642-4133-B39C-3430335503B8@oracle.com> On May 24 2012, at 16:32 , Vitaly Davidovich wrote: > That's a bit odd as I thought the Klass object in the VM stored something like 7 supers, which includes interfaces (if I'm not mistaken). I know that instanceof checks against final classes are optimized into a simple cmp against an address, but I'm surprised that a check against an interface for classes in a very shallow type hierarchy is up to x25 slower. Do you know why that is Mike? Did you ask the compiler guys by chance? > I didn't actually look much further into it other than to write a small microbenchmark to make sure it was the instanceof check. I tested a couple of different configs of classes and interfaces and supers. I was able to validate that 'x instanceof String' was as fast as 'x.getClass() == String.class' and that other cases were slower. Inheritance checks seemed faster than checks on interfaces. That was enough to tell me that I was on the wrong track with 'x instanceof Hashable' as a way to determine which hash algorithm to use. At least for C2 server compiler. If there is a thorough exploration or explanation of which dispatching techniques have good performance and an explanation of which idioms will never be fast I'd be interested to read it. Mike > Thanks > > Sent from my phone > > On May 24, 2012 5:26 PM, "Mike Duigou" wrote: > > On May 23 2012, at 16:31 , David Holmes wrote: > > > On 24/05/2012 2:24 AM, Mike Duigou wrote: > >> Hi Mike; > >> > >> The problem with using instanceof Hashable32 is that is much slower (often more than 25X) than instanceof String. It's slow enough that we won't reasonably consider using instanceof Hashable32 in JDK 8. We have considered making Object implement Hashable32 and add a virtual extension method to Object for hash32(). The extension method would just call hashCode(). A compiler that supports extension methods is not yet part of the JDK mainline repo yet (It is still in the Lambda repo). This approach would mean that we can avoid an instanceof check but there is a *lot* of entirely reasonable reservations about having Object implement an interface and gain a new method. > > > > Is it worth using: > > > > && (k instanceof String || k instanceof Hash32) > > > > to deal with that. What would be the penalty on non-String Hash32's? > > The problem in this case would be the k instances that are neither String nor Hash32. They would be severely impacted. Using Doug Lea's "loops" Map microbenchmark, "k instanceof Hash32" was up to 25 times more expensive than calling "k instanceof String". I suspect that it could be even higher with classes that have deep inheritance hierarchies. My non-Hash32 keys were all instances of Number (Float, Double, Integer and Long) so each had a single interface. > > Mike > > > David > > > >> Opinions and insights welcome, > >> > >> Mike > >> > >> On May 23 2012, at 00:38 , Mike Skells wrote: > >> > >>> Hi Mike, > >>> > >>> I have a query, why is this implementation limitted to String? > >>> Is this by intent? > >>> > >>> in HashMap the patch for hash calculation is > >>> 290 final int hash(Object k) { > >>> 291 int h = hashMask; > >>> 292 if ((0 != h)&& (k instanceof String)) { > >>> 293 return h ^ ((String)k).hash32(); > >>> .... > >>> whereas I would have thought that it should be > >>> 290 final int hash(Object k) { > >>> 291 int h = hashMask; > >>> 292 if ((0 != h)&& (k instanceof Hash32)) { > >>> 293 return h ^ ((Hash32)k).hash32(); > >>> .... > >>> > >>> As a more flexible improvement could you supply a HashCode and Equals delegate, and then the user can supply either a custom delegate, suitable for that application (e.g.one that iterates through array content, or any other application data structure that needs to be handled differently like c# uses http://msdn.microsoft.com/en-us/library/system.collections.iequalitycomparer ) > >>> > >>> Regards > >>> > >>> Mike > >> > From stuart.marks at oracle.com Fri May 25 02:28:41 2012 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Fri, 25 May 2012 02:28:41 +0000 Subject: hg: jdk8/tl/jdk: 7117230: clean up warnings in java.text Message-ID: <20120525022852.9EB87474E4@hg.openjdk.java.net> Changeset: e309917fb9af Author: dbhole Date: 2012-05-24 19:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e309917fb9af 7117230: clean up warnings in java.text Reviewed-by: jrose, smarks ! src/share/classes/java/text/AttributedCharacterIterator.java ! src/share/classes/java/text/AttributedString.java ! src/share/classes/java/text/BreakDictionary.java ! src/share/classes/java/text/BreakIterator.java ! src/share/classes/java/text/CharacterIteratorFieldDelegate.java ! src/share/classes/java/text/ChoiceFormat.java ! src/share/classes/java/text/CollationElementIterator.java ! src/share/classes/java/text/DateFormat.java ! src/share/classes/java/text/DecimalFormat.java ! src/share/classes/java/text/DictionaryBasedBreakIterator.java ! src/share/classes/java/text/MergeCollation.java ! src/share/classes/java/text/MessageFormat.java ! src/share/classes/java/text/NumberFormat.java ! src/share/classes/java/text/ParseException.java ! src/share/classes/java/text/RBCollationTables.java ! src/share/classes/java/text/RBTableBuilder.java ! src/share/classes/java/text/RuleBasedBreakIterator.java From rednaxelafx at gmail.com Fri May 25 02:41:24 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Fri, 25 May 2012 10:41:24 +0800 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps In-Reply-To: <7BB1802F-0642-4133-B39C-3430335503B8@oracle.com> References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> <1337758719.27301.YahooMailNeo@web87704.mail.ir2.yahoo.com> <4FBD7360.4050306@oracle.com> <7BB1802F-0642-4133-B39C-3430335503B8@oracle.com> Message-ID: Hi Mike, On Fri, May 25, 2012 at 10:12 AM, Mike Duigou wrote: > > On May 24 2012, at 16:32 , Vitaly Davidovich wrote: > > > That's a bit odd as I thought the Klass object in the VM stored > something like 7 supers, which includes interfaces (if I'm not mistaken). > I know that instanceof checks against final classes are optimized into a > simple cmp against an address, but I'm surprised that a check against an > interface for classes in a very shallow type hierarchy is up to x25 slower. > Do you know why that is Mike? Did you ask the compiler guys by chance? > > > I didn't actually look much further into it other than to write a small > microbenchmark to make sure it was the instanceof check. I tested a couple > of different configs of classes and interfaces and supers. I was able to > validate that 'x instanceof String' was as fast as 'x.getClass() == > String.class' and that other cases were slower. Inheritance checks seemed > faster than checks on interfaces. That was enough to tell me that I was on > the wrong track with 'x instanceof Hashable' as a way to determine which > hash algorithm to use. At least for C2 server compiler. > > FYI, "x.getClass() == String.class" will be just as fast when 7170463 [1] is in. @Vitaly The fast subtype checking algorithm in HotSpot treats interfaces as "secondary supers", which goes through a slow path. The super type display in instanceKlass is only for "primary supers", which does not include interfaces for instance classes. You may want to check out the details in this paper [2]. > Definition 5: A class T is a secondary type iff T is an interface or > an array of a secondary type. Every type is either a primary > type or a secondary type but not both. Regards, Kris [1]: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-May/007730.html [2]: http://dl.acm.org/citation.cfm?id=583821 > If there is a thorough exploration or explanation of which dispatching > techniques have good performance and an explanation of which idioms will > never be fast I'd be interested to read it. > > Mike > > Thanks > > > > Sent from my phone > > > > On May 24, 2012 5:26 PM, "Mike Duigou" wrote: > > > > On May 23 2012, at 16:31 , David Holmes wrote: > > > > > On 24/05/2012 2:24 AM, Mike Duigou wrote: > > >> Hi Mike; > > >> > > >> The problem with using instanceof Hashable32 is that is much slower > (often more than 25X) than instanceof String. It's slow enough that we > won't reasonably consider using instanceof Hashable32 in JDK 8. We have > considered making Object implement Hashable32 and add a virtual extension > method to Object for hash32(). The extension method would just call > hashCode(). A compiler that supports extension methods is not yet part of > the JDK mainline repo yet (It is still in the Lambda repo). This approach > would mean that we can avoid an instanceof check but there is a *lot* of > entirely reasonable reservations about having Object implement an interface > and gain a new method. > > > > > > Is it worth using: > > > > > > && (k instanceof String || k instanceof Hash32) > > > > > > to deal with that. What would be the penalty on non-String Hash32's? > > > > The problem in this case would be the k instances that are neither > String nor Hash32. They would be severely impacted. Using Doug Lea's > "loops" Map microbenchmark, "k instanceof Hash32" was up to 25 times more > expensive than calling "k instanceof String". I suspect that it could be > even higher with classes that have deep inheritance hierarchies. My > non-Hash32 keys were all instances of Number (Float, Double, Integer and > Long) so each had a single interface. > > > > Mike > > > > > David > > > > > >> Opinions and insights welcome, > > >> > > >> Mike > > >> > > >> On May 23 2012, at 00:38 , Mike Skells wrote: > > >> > > >>> Hi Mike, > > >>> > > >>> I have a query, why is this implementation limitted to String? > > >>> Is this by intent? > > >>> > > >>> in HashMap the patch for hash calculation is > > >>> 290 final int hash(Object k) { > > >>> 291 int h = hashMask; > > >>> 292 if ((0 != h)&& (k instanceof String)) { > > >>> 293 return h ^ ((String)k).hash32(); > > >>> .... > > >>> whereas I would have thought that it should be > > >>> 290 final int hash(Object k) { > > >>> 291 int h = hashMask; > > >>> 292 if ((0 != h)&& (k instanceof Hash32)) { > > >>> 293 return h ^ ((Hash32)k).hash32(); > > >>> .... > > >>> > > >>> As a more flexible improvement could you supply a HashCode and > Equals delegate, and then the user can supply either a custom delegate, > suitable for that application (e.g.one that iterates through array content, > or any other application data structure that needs to be handled > differently like c# uses > http://msdn.microsoft.com/en-us/library/system.collections.iequalitycomparer) > > >>> > > >>> Regards > > >>> > > >>> Mike > > >> > > > > From vitalyd at gmail.com Fri May 25 03:33:10 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 24 May 2012 23:33:10 -0400 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps In-Reply-To: References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> <1337758719.27301.YahooMailNeo@web87704.mail.ir2.yahoo.com> <4FBD7360.4050306@oracle.com> <7BB1802F-0642-4133-B39C-3430335503B8@oracle.com> Message-ID: Thanks Kris, good to know. As much as instanceof checks are usually a code smell, it sure would be nice if the interface version could be optimized somewhat (at least for shallow hierarchies). Cheers Sent from my phone On May 24, 2012 10:41 PM, "Krystal Mok" wrote: > Hi Mike, > > On Fri, May 25, 2012 at 10:12 AM, Mike Duigou wrote: > >> >> On May 24 2012, at 16:32 , Vitaly Davidovich wrote: >> >> > That's a bit odd as I thought the Klass object in the VM stored >> something like 7 supers, which includes interfaces (if I'm not mistaken). >> I know that instanceof checks against final classes are optimized into a >> simple cmp against an address, but I'm surprised that a check against an >> interface for classes in a very shallow type hierarchy is up to x25 slower. >> Do you know why that is Mike? Did you ask the compiler guys by chance? >> > >> I didn't actually look much further into it other than to write a small >> microbenchmark to make sure it was the instanceof check. I tested a couple >> of different configs of classes and interfaces and supers. I was able to >> validate that 'x instanceof String' was as fast as 'x.getClass() == >> String.class' and that other cases were slower. Inheritance checks seemed >> faster than checks on interfaces. That was enough to tell me that I was on >> the wrong track with 'x instanceof Hashable' as a way to determine which >> hash algorithm to use. At least for C2 server compiler. >> >> FYI, "x.getClass() == String.class" will be just as fast when 7170463 [1] > is in. > > @Vitaly > > The fast subtype checking algorithm in HotSpot treats interfaces as > "secondary supers", which goes through a slow path. The super type display > in instanceKlass is only for "primary supers", which does not include > interfaces for instance classes. You may want to check out the details in > this paper [2]. > > > Definition 5: A class T is a secondary type iff T is an interface or > > an array of a secondary type. Every type is either a primary > > type or a secondary type but not both. > > Regards, > Kris > > [1]: > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-May/007730.html > [2]: http://dl.acm.org/citation.cfm?id=583821 > > >> If there is a thorough exploration or explanation of which dispatching >> techniques have good performance and an explanation of which idioms will >> never be fast I'd be interested to read it. >> >> Mike >> > Thanks >> > >> > Sent from my phone >> > >> > On May 24, 2012 5:26 PM, "Mike Duigou" wrote: >> > >> > On May 23 2012, at 16:31 , David Holmes wrote: >> > >> > > On 24/05/2012 2:24 AM, Mike Duigou wrote: >> > >> Hi Mike; >> > >> >> > >> The problem with using instanceof Hashable32 is that is much slower >> (often more than 25X) than instanceof String. It's slow enough that we >> won't reasonably consider using instanceof Hashable32 in JDK 8. We have >> considered making Object implement Hashable32 and add a virtual extension >> method to Object for hash32(). The extension method would just call >> hashCode(). A compiler that supports extension methods is not yet part of >> the JDK mainline repo yet (It is still in the Lambda repo). This approach >> would mean that we can avoid an instanceof check but there is a *lot* of >> entirely reasonable reservations about having Object implement an interface >> and gain a new method. >> > > >> > > Is it worth using: >> > > >> > > && (k instanceof String || k instanceof Hash32) >> > > >> > > to deal with that. What would be the penalty on non-String Hash32's? >> > >> > The problem in this case would be the k instances that are neither >> String nor Hash32. They would be severely impacted. Using Doug Lea's >> "loops" Map microbenchmark, "k instanceof Hash32" was up to 25 times more >> expensive than calling "k instanceof String". I suspect that it could be >> even higher with classes that have deep inheritance hierarchies. My >> non-Hash32 keys were all instances of Number (Float, Double, Integer and >> Long) so each had a single interface. >> > >> > Mike >> > >> > > David >> > > >> > >> Opinions and insights welcome, >> > >> >> > >> Mike >> > >> >> > >> On May 23 2012, at 00:38 , Mike Skells wrote: >> > >> >> > >>> Hi Mike, >> > >>> >> > >>> I have a query, why is this implementation limitted to String? >> > >>> Is this by intent? >> > >>> >> > >>> in HashMap the patch for hash calculation is >> > >>> 290 final int hash(Object k) { >> > >>> 291 int h = hashMask; >> > >>> 292 if ((0 != h)&& (k instanceof String)) { >> > >>> 293 return h ^ ((String)k).hash32(); >> > >>> .... >> > >>> whereas I would have thought that it should be >> > >>> 290 final int hash(Object k) { >> > >>> 291 int h = hashMask; >> > >>> 292 if ((0 != h)&& (k instanceof Hash32)) { >> > >>> 293 return h ^ ((Hash32)k).hash32(); >> > >>> .... >> > >>> >> > >>> As a more flexible improvement could you supply a HashCode and >> Equals delegate, and then the user can supply either a custom delegate, >> suitable for that application (e.g.one that iterates through array content, >> or any other application data structure that needs to be handled >> differently like c# uses >> http://msdn.microsoft.com/en-us/library/system.collections.iequalitycomparer) >> > >>> >> > >>> Regards >> > >>> >> > >>> Mike >> > >> >> > >> >> > From littlee at linux.vnet.ibm.com Fri May 25 05:31:53 2012 From: littlee at linux.vnet.ibm.com (littlee at linux.vnet.ibm.com) Date: Fri, 25 May 2012 05:31:53 +0000 Subject: hg: jdk8/tl/jdk: 7094176: (tz) Incorrect TimeZone display name when DST not applicable / disabled Message-ID: <20120525053212.D046D47505@hg.openjdk.java.net> Changeset: 71cf74329a9e Author: youdwei Date: 2012-05-25 13:28 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/71cf74329a9e 7094176: (tz) Incorrect TimeZone display name when DST not applicable / disabled Reviewed-by: okutsu ! src/windows/native/java/util/TimeZone_md.c + test/java/util/TimeZone/DstTzTest.java From littlee at linux.vnet.ibm.com Fri May 25 06:34:09 2012 From: littlee at linux.vnet.ibm.com (littlee at linux.vnet.ibm.com) Date: Fri, 25 May 2012 06:34:09 +0000 Subject: hg: jdk8/tl/jdk: 7171028: dots are missed in the datetime for Slovanian Message-ID: <20120525063429.F2FEF47507@hg.openjdk.java.net> Changeset: 85696e57d447 Author: youdwei Date: 2012-05-25 14:32 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/85696e57d447 7171028: dots are missed in the datetime for Slovanian Reviewed-by: yhuang ! src/share/classes/sun/text/resources/FormatData_sl.java ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java From Alan.Bateman at oracle.com Fri May 25 07:27:04 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 25 May 2012 08:27:04 +0100 Subject: hg: jdk8/tl/jdk: 7094176: (tz) Incorrect TimeZone display name when DST not applicable / disabled In-Reply-To: <20120525053212.D046D47505@hg.openjdk.java.net> References: <20120525053212.D046D47505@hg.openjdk.java.net> Message-ID: <4FBF3448.2050602@oracle.com> Deven, The test with this fix seems to be a manual test but doesn't seem to be tagged as such (/manual). I assume this means it will fail on all platforms. Do you mind re-examining it? Masayoshi may have some advice on how configuration like this can be tested. It may be that it's just not possible to test this in an automated way, in which case the path of least pain may be to just remove it. -Alan. On 25/05/2012 06:31, littlee at linux.vnet.ibm.com wrote: > Changeset: 71cf74329a9e > Author: youdwei > Date: 2012-05-25 13:28 +0800 > URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/71cf74329a9e > > 7094176: (tz) Incorrect TimeZone display name when DST not applicable / disabled > Reviewed-by: okutsu > > ! src/windows/native/java/util/TimeZone_md.c > + test/java/util/TimeZone/DstTzTest.java > From youdwei at linux.vnet.ibm.com Fri May 25 07:41:25 2012 From: youdwei at linux.vnet.ibm.com (Deven You) Date: Fri, 25 May 2012 15:41:25 +0800 Subject: hg: jdk8/tl/jdk: 7094176: (tz) Incorrect TimeZone display name when DST not applicable / disabled In-Reply-To: <4FBF3448.2050602@oracle.com> References: <20120525053212.D046D47505@hg.openjdk.java.net> <4FBF3448.2050602@oracle.com> Message-ID: <4FBF37A5.1060705@linux.vnet.ibm.com> Hi Alan, Thanks for your reminder, I was going to point that this a manual test case and need someone guide me how to configure it as manual with jtreg. But I missed it by chance. So Masayoshi or someone else, I'd very appreciate if you could guide me how to configure a test case as manual in the jtreg? Thanks a lot! On 05/25/2012 03:27 PM, Alan Bateman wrote: > Deven, > > The test with this fix seems to be a manual test but doesn't seem to > be tagged as such (/manual). I assume this means it will fail on all > platforms. Do you mind re-examining it? Masayoshi may have some advice > on how configuration like this can be tested. It may be that it's just > not possible to test this in an automated way, in which case the path > of least pain may be to just remove it. > > -Alan. > > On 25/05/2012 06:31, littlee at linux.vnet.ibm.com wrote: >> Changeset: 71cf74329a9e >> Author: youdwei >> Date: 2012-05-25 13:28 +0800 >> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/71cf74329a9e >> >> 7094176: (tz) Incorrect TimeZone display name when DST not applicable >> / disabled >> Reviewed-by: okutsu >> >> ! src/windows/native/java/util/TimeZone_md.c >> + test/java/util/TimeZone/DstTzTest.java >> > -- Best Regards, Deven From masayoshi.okutsu at oracle.com Fri May 25 09:32:37 2012 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Fri, 25 May 2012 18:32:37 +0900 Subject: hg: jdk8/tl/jdk: 7094176: (tz) Incorrect TimeZone display name when DST not applicable / disabled In-Reply-To: <4FBF37A5.1060705@linux.vnet.ibm.com> References: <20120525053212.D046D47505@hg.openjdk.java.net> <4FBF3448.2050602@oracle.com> <4FBF37A5.1060705@linux.vnet.ibm.com> Message-ID: <4FBF51B5.8020908@oracle.com> Hi Deven, Sorry. I didn't review the test case... You can use applet to write a manual test. You will find some manual tests under test/java/awt such as: test/java/awt/TextField/ScrollSelectionTest/ScrollSelectionTest.{html,java} Thanks, Masayoshi On 5/25/2012 4:41 PM, Deven You wrote: > Hi Alan, > > Thanks for your reminder, I was going to point that this a manual test > case and need someone guide me how to configure it as manual with > jtreg. But I missed it by chance. > > So Masayoshi or someone else, I'd very appreciate if you could guide > me how to configure a test case as manual in the jtreg? > > Thanks a lot! > > On 05/25/2012 03:27 PM, Alan Bateman wrote: >> Deven, >> >> The test with this fix seems to be a manual test but doesn't seem to >> be tagged as such (/manual). I assume this means it will fail on all >> platforms. Do you mind re-examining it? Masayoshi may have some >> advice on how configuration like this can be tested. It may be that >> it's just not possible to test this in an automated way, in which >> case the path of least pain may be to just remove it. >> >> -Alan. >> >> On 25/05/2012 06:31, littlee at linux.vnet.ibm.com wrote: >>> Changeset: 71cf74329a9e >>> Author: youdwei >>> Date: 2012-05-25 13:28 +0800 >>> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/71cf74329a9e >>> >>> 7094176: (tz) Incorrect TimeZone display name when DST not >>> applicable / disabled >>> Reviewed-by: okutsu >>> >>> ! src/windows/native/java/util/TimeZone_md.c >>> + test/java/util/TimeZone/DstTzTest.java >>> >> > > From Alan.Bateman at oracle.com Fri May 25 09:37:17 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 25 May 2012 10:37:17 +0100 Subject: hg: jdk8/tl/jdk: 7094176: (tz) Incorrect TimeZone display name when DST not applicable / disabled In-Reply-To: <4FBF51B5.8020908@oracle.com> References: <20120525053212.D046D47505@hg.openjdk.java.net> <4FBF3448.2050602@oracle.com> <4FBF37A5.1060705@linux.vnet.ibm.com> <4FBF51B5.8020908@oracle.com> Message-ID: <4FBF52CD.6060706@oracle.com> On 25/05/2012 10:32, Masayoshi Okutsu wrote: > Hi Deven, > > Sorry. I didn't review the test case... > > You can use applet to write a manual test. You will find some manual > tests under test/java/awt such as: > > test/java/awt/TextField/ScrollSelectionTest/ScrollSelectionTest.{html,java} > > > Thanks, > Masayoshi Masayoshi - I think we need to strongly discourage adding any manual tests to the java/util/ tree. -Alan. From Ulf.Zibis at gmx.de Fri May 25 09:57:07 2012 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 25 May 2012 11:57:07 +0200 Subject: Request for Review : CR#6924259: Remove String.count/String.offset In-Reply-To: References: <1D5C5BC1-C6E8-4807-9D5B-2530CDEAD479@oracle.com> <4FBEBC85.4050104@gmx.de> Message-ID: <4FBF5773.8030000@gmx.de> Am 25.05.2012 01:11, schrieb Mike Duigou: > On May 24 2012, at 15:56 , Ulf Zibis wrote: > >> Am 24.05.2012 22:45, schrieb Mike Duigou: >>> A patch of the changes to java.lang.String for JDK 8 are at. The changes for JDK 7 have only superficial differences (line offsets in the patch). >> Correct Copyright date. >> >> 157 public String(String original) { >> 158 this.value = (original.value.length> 0) >> 159 ? original.value >> 160 : EMPTY_STRING_VALUE; >> 161 } >> >> Does the last case ever occur?, if you have: > It can occur in cases where original is > - a deserialized string If not interned yes. But stop, see argumentation for StringBuilder below... > - a string from a class file constant pool I think, they become interned, so all should be identical. > - the string constant "" same > - (new StringBuilder()).toString() and other empty string generators. Hm, StringBuilder uses one of the constructors from String, so if we guarantee by all String constructors to refer to interned EMPTY_STRING_VALUE, then this should not occur -Ulf From masayoshi.okutsu at oracle.com Fri May 25 10:05:30 2012 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Fri, 25 May 2012 19:05:30 +0900 Subject: hg: jdk8/tl/jdk: 7094176: (tz) Incorrect TimeZone display name when DST not applicable / disabled In-Reply-To: <4FBF52CD.6060706@oracle.com> References: <20120525053212.D046D47505@hg.openjdk.java.net> <4FBF3448.2050602@oracle.com> <4FBF37A5.1060705@linux.vnet.ibm.com> <4FBF51B5.8020908@oracle.com> <4FBF52CD.6060706@oracle.com> Message-ID: <4FBF596A.4080300@oracle.com> On 5/25/2012 6:37 PM, Alan Bateman wrote: > On 25/05/2012 10:32, Masayoshi Okutsu wrote: >> Hi Deven, >> >> Sorry. I didn't review the test case... >> >> You can use applet to write a manual test. You will find some manual >> tests under test/java/awt such as: >> >> test/java/awt/TextField/ScrollSelectionTest/ScrollSelectionTest.{html,java} >> >> >> Thanks, >> Masayoshi > Masayoshi - I think we need to strongly discourage adding any manual > tests to the java/util/ tree. Another option would be to write a native program to change the system setup and run a Java program to detect the change. But it requires the administrator privilege and is a bit risky. A test failure may leave a test machine in an unusual state. Any other options? Thanks, Masayoshi From Alan.Bateman at oracle.com Fri May 25 10:53:31 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 25 May 2012 11:53:31 +0100 Subject: hg: jdk8/tl/jdk: 7094176: (tz) Incorrect TimeZone display name when DST not applicable / disabled In-Reply-To: <4FBF596A.4080300@oracle.com> References: <20120525053212.D046D47505@hg.openjdk.java.net> <4FBF3448.2050602@oracle.com> <4FBF37A5.1060705@linux.vnet.ibm.com> <4FBF51B5.8020908@oracle.com> <4FBF52CD.6060706@oracle.com> <4FBF596A.4080300@oracle.com> Message-ID: <4FBF64AB.7000609@oracle.com> On 25/05/2012 11:05, Masayoshi Okutsu wrote: > > Another option would be to write a native program to change the system > setup and run a Java program to detect the change. But it requires the > administrator privilege and is a bit risky. A test failure may leave a > test machine in an unusual state. > > Any other options? Changing the system configuration would also likely cause problems when running tests concurrently. I think the only option is to just remove the test. -Alan. From Alan.Bateman at oracle.com Fri May 25 12:08:26 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 25 May 2012 13:08:26 +0100 Subject: Request for Review : CR#6924259: Remove String.count/String.offset In-Reply-To: <1D5C5BC1-C6E8-4807-9D5B-2530CDEAD479@oracle.com> References: <1D5C5BC1-C6E8-4807-9D5B-2530CDEAD479@oracle.com> Message-ID: <4FBF763A.6050202@oracle.com> On 24/05/2012 21:45, Mike Duigou wrote: > Hello all; > > For a long time preparations and planing have been underway to remove the offset and count fields from java.lang.String. These two fields enable multiple String instances to share the same backing character buffer. Shared character buffers were an important optimization for old benchmarks but with current real world code and benchmarks it's actually better to not share backing buffers. Shared char array backing buffers only "win" with very heavy use of String.substring. The negatively impacted situations can include parsers and compilers however current testing shows that overall this change is beneficial. > > The current plan is to commit this change to jdk8 before build 40 followed by jdk7u6. Removing offset/count is a complicated process because HotSpot has special case code for String that depends upon the two fields. Vladimir Kozlov has committed the required HotSpot changes already (http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/8f972594effc). > > A patch of the changes to java.lang.String for JDK 8 are at. The changes for JDK 7 have only superficial differences (line offsets in the patch). > > Comments are welcome. > > Mike I went through the latest webrev and don't see anything obviously wrong. EMPTY_STRING_VALUE is new, at least to me, as I don't think it was there when removing these fields was prototyped a few years ago. A minor point in the String(char[]) constructor is that you could move the "int len = .." to the top of the method to be consistent with other places where a local holds the value.length. The "use name version for caching" comment in StringCoding.java might be confusing to readers, maybe "use charset name as this is faster due to caching". A non-material comment is that there are a couple of style changes that I found annoying. Everyone is an expert on such matters, I'm not, but the one that bugged me a bit was adding the space after the cast, eg: (toffset > (long) value.length - len) I found myself needing to re-read it to see if the cast applied to value.length or value.length-len. It's a minor point but you know what I mean. -Alan. From nils.loodin at oracle.com Fri May 25 12:57:17 2012 From: nils.loodin at oracle.com (nils.loodin at oracle.com) Date: Fri, 25 May 2012 12:57:17 +0000 Subject: hg: jdk8/tl/jdk: 7017818: NLS: JConsoleResources.java cannot be handled by translation team Message-ID: <20120525125738.14B7647513@hg.openjdk.java.net> Changeset: 1def6b6bfbd9 Author: egahlin Date: 2012-05-25 12:24 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1def6b6bfbd9 7017818: NLS: JConsoleResources.java cannot be handled by translation team Reviewed-by: mchung, mfang ! make/netbeans/jconsole/build.xml ! make/sun/jconsole/FILES.gmk ! make/sun/jconsole/Makefile ! src/share/classes/sun/tools/jconsole/AboutDialog.java ! src/share/classes/sun/tools/jconsole/BorderedComponent.java ! src/share/classes/sun/tools/jconsole/ClassTab.java ! src/share/classes/sun/tools/jconsole/ConnectDialog.java ! src/share/classes/sun/tools/jconsole/CreateMBeanDialog.java ! src/share/classes/sun/tools/jconsole/Formatter.java ! src/share/classes/sun/tools/jconsole/HTMLPane.java ! src/share/classes/sun/tools/jconsole/InternalDialog.java ! src/share/classes/sun/tools/jconsole/JConsole.java ! src/share/classes/sun/tools/jconsole/LabeledComponent.java ! src/share/classes/sun/tools/jconsole/LocalVirtualMachine.java ! src/share/classes/sun/tools/jconsole/MBeansTab.java ! src/share/classes/sun/tools/jconsole/MaximizableInternalFrame.java ! src/share/classes/sun/tools/jconsole/MemoryPoolProxy.java ! src/share/classes/sun/tools/jconsole/MemoryPoolStat.java ! src/share/classes/sun/tools/jconsole/MemoryTab.java + src/share/classes/sun/tools/jconsole/Messages.java ! src/share/classes/sun/tools/jconsole/OverviewPanel.java ! src/share/classes/sun/tools/jconsole/OverviewTab.java ! src/share/classes/sun/tools/jconsole/Plotter.java ! src/share/classes/sun/tools/jconsole/PlotterPanel.java ! src/share/classes/sun/tools/jconsole/ProxyClient.java ! src/share/classes/sun/tools/jconsole/Resources.java ! src/share/classes/sun/tools/jconsole/SummaryTab.java ! src/share/classes/sun/tools/jconsole/Tab.java ! src/share/classes/sun/tools/jconsole/ThreadTab.java ! src/share/classes/sun/tools/jconsole/VMInternalFrame.java ! src/share/classes/sun/tools/jconsole/VMPanel.java ! src/share/classes/sun/tools/jconsole/VariableGridLayout.java ! src/share/classes/sun/tools/jconsole/Version.java.template ! src/share/classes/sun/tools/jconsole/inspector/OperationEntry.java ! src/share/classes/sun/tools/jconsole/inspector/TableSorter.java ! src/share/classes/sun/tools/jconsole/inspector/ThreadDialog.java ! src/share/classes/sun/tools/jconsole/inspector/Utils.java ! src/share/classes/sun/tools/jconsole/inspector/XArrayDataViewer.java ! src/share/classes/sun/tools/jconsole/inspector/XDataViewer.java ! src/share/classes/sun/tools/jconsole/inspector/XMBeanAttributes.java ! src/share/classes/sun/tools/jconsole/inspector/XMBeanInfo.java ! src/share/classes/sun/tools/jconsole/inspector/XMBeanNotifications.java ! src/share/classes/sun/tools/jconsole/inspector/XObject.java ! src/share/classes/sun/tools/jconsole/inspector/XOpenTypeViewer.java ! src/share/classes/sun/tools/jconsole/inspector/XOperations.java ! src/share/classes/sun/tools/jconsole/inspector/XPlotter.java ! src/share/classes/sun/tools/jconsole/inspector/XPlottingViewer.java ! src/share/classes/sun/tools/jconsole/inspector/XSheet.java ! src/share/classes/sun/tools/jconsole/inspector/XTable.java ! src/share/classes/sun/tools/jconsole/inspector/XTextField.java ! src/share/classes/sun/tools/jconsole/inspector/XTree.java ! src/share/classes/sun/tools/jconsole/inspector/XTreeRenderer.java - src/share/classes/sun/tools/jconsole/resources/JConsoleResources.java - src/share/classes/sun/tools/jconsole/resources/JConsoleResources_ja.java - src/share/classes/sun/tools/jconsole/resources/JConsoleResources_zh_CN.java + src/share/classes/sun/tools/jconsole/resources/messages.properties + src/share/classes/sun/tools/jconsole/resources/messages_ja.properties + src/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties From Ulf.Zibis at gmx.de Fri May 25 13:15:25 2012 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 25 May 2012 15:15:25 +0200 Subject: Space notation for cast In-Reply-To: <4FBF763A.6050202@oracle.com> References: <1D5C5BC1-C6E8-4807-9D5B-2530CDEAD479@oracle.com> <4FBF763A.6050202@oracle.com> Message-ID: <4FBF85ED.5070602@gmx.de> Am 25.05.2012 14:08, schrieb Alan Bateman: > A non-material comment is that there are a couple of style changes that I found annoying. Everyone > is an expert on such matters, I'm not, but the one that bugged me a bit was adding the space after > the cast, eg: > (toffset > (long) value.length - len) I don't like the space notation too, justification see: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6939278 -Ulf From mike.duigou at oracle.com Fri May 25 13:48:55 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 25 May 2012 06:48:55 -0700 Subject: Request for Review : CR#6924259: Remove String.count/String.offset In-Reply-To: <4FBF763A.6050202@oracle.com> References: <1D5C5BC1-C6E8-4807-9D5B-2530CDEAD479@oracle.com> <4FBF763A.6050202@oracle.com> Message-ID: > A non-material comment is that there are a couple of style changes that I found annoying. Everyone is an expert on such matters, I'm not, but the one that bugged me a bit was adding the space after the cast, eg: > (toffset > (long) value.length - len) > I found myself needing to re-read it to see if the cast applied to value.length or value.length-len. It's a minor point but you know what I mean. I too mostly prefer casts without a space. The code was reformatted with an IDE because I'm actually terrible about being consistent in my formatting. Mechanically formatted code, like mechanically separated meat, lacks any sense of what is readable to a human. I will remove some of the spaces. Mike From forax at univ-mlv.fr Fri May 25 13:57:22 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 25 May 2012 15:57:22 +0200 Subject: Request for Review : CR#6924259: Remove String.count/String.offset In-Reply-To: <4FBF763A.6050202@oracle.com> References: <1D5C5BC1-C6E8-4807-9D5B-2530CDEAD479@oracle.com> <4FBF763A.6050202@oracle.com> Message-ID: <4FBF8FC2.1030608@univ-mlv.fr> Hi Mike, Hi Alan, Hi all, in my opinion, EMPTY_STRING_VALUE is a premature optimization, the idea is, I think, to avoid to create an empty char but if you want to do that, it's better to do that in StringBuilder.toString() to avoid to create the String at all. I'm worried about one pathological case where a lot of non empty String will be created and then one empty will be created after the code will be JITed, in that case Hotspot will deoptimize all codes that have inlined the constructor call. I think it's better to have a simple implementation first, with no if at all and see if using EMPTY_STRING_VALUE is better after. Also, the changeset remplace several usages of this.value = Arrays.copyOf(value, size); by this.value = new char[len]; System.arraycopy(value, 0, this.value, 0, len); I think it's not a good idea, Arrays.copyOf is recognized as an intrinsics and avoid to initialize the array with zeroes. I know that c2 is able to transform new + arraycopy to copyOf but I don't think c1 does that. String(StringBuilder) and String(StringBuffer) can be simplified by using length() and getValue() (AbstractStringBuilder.getValue()) to extract the info. this.value = Arrays.copyOf(builder.getValue(), builder.length()); and avoid to create a temporary String. String(char value[], boolean share) should be String(char[] value, boolean share) and is there a perf reason to not use a static method like createSharedString() instead. Removing String(int offset, int count, char value[]) will create trouble, I've seen several libraries that use it by reflection to avoid to create a copy of the array. I think this method should not disappear but use Arrays.copyOfRange if the offset is not 0. This method should be marked deprecated, and removed in Java 9. Recently, _getChars(char[], int) was replaced by getChars(char[],int). It was a stupid change because now one can think that getChar(char[], int) and getChar(int,int,char[],int) do the same things. but getChat(char[],int) don't do any bounds check. So concat() and toCharArray() doesn't do any bound check ! toCharArray() should use Arrays.copyOf() Overloads of encode in StringCoding are in my opinion not necessary because each method is called once. So this doesn't really share code but just add one level to the depth of the call stack. cheers, R?mi On 05/25/2012 02:08 PM, Alan Bateman wrote: > On 24/05/2012 21:45, Mike Duigou wrote: >> Hello all; >> >> For a long time preparations and planing have been underway to remove >> the offset and count fields from java.lang.String. These two fields >> enable multiple String instances to share the same backing character >> buffer. Shared character buffers were an important optimization for >> old benchmarks but with current real world code and benchmarks it's >> actually better to not share backing buffers. Shared char array >> backing buffers only "win" with very heavy use of String.substring. >> The negatively impacted situations can include parsers and compilers >> however current testing shows that overall this change is beneficial. >> >> The current plan is to commit this change to jdk8 before build 40 >> followed by jdk7u6. Removing offset/count is a complicated process >> because HotSpot has special case code for String that depends upon >> the two fields. Vladimir Kozlov has committed the required HotSpot >> changes already >> (http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/8f972594effc). >> >> A patch of the changes to java.lang.String for JDK 8 are >> at. The >> changes for JDK 7 have only superficial differences (line offsets in >> the patch). >> >> Comments are welcome. >> >> Mike > I went through the latest webrev and don't see anything obviously > wrong. EMPTY_STRING_VALUE is new, at least to me, as I don't think it > was there when removing these fields was prototyped a few years ago. > > A minor point in the String(char[]) constructor is that you could move > the "int len = .." to the top of the method to be consistent with > other places where a local holds the value.length. > > The "use name version for caching" comment in StringCoding.java might > be confusing to readers, maybe "use charset name as this is faster due > to caching". > > A non-material comment is that there are a couple of style changes > that I found annoying. Everyone is an expert on such matters, I'm not, > but the one that bugged me a bit was adding the space after the cast, eg: > (toffset > (long) value.length - len) > I found myself needing to re-read it to see if the cast applied to > value.length or value.length-len. It's a minor point but you know what > I mean. > > -Alan. From alan.bateman at oracle.com Fri May 25 13:56:22 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 25 May 2012 13:56:22 +0000 Subject: hg: jdk8/tl/jdk: 7171474: Incorrect @see tags in java.lang.NumberFormatException javadoc Message-ID: <20120525135643.C02C047518@hg.openjdk.java.net> Changeset: f92325f12654 Author: jgish Date: 2012-05-24 11:11 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f92325f12654 7171474: Incorrect @see tags in java.lang.NumberFormatException javadoc Summary: update javadoc for NumberFormatException Reviewed-by: alanb ! src/share/classes/java/lang/NumberFormatException.java From jim.gish at oracle.com Fri May 25 15:05:22 2012 From: jim.gish at oracle.com (Jim Gish) Date: Fri, 25 May 2012 11:05:22 -0400 Subject: Request for Review : CR#6924259: Remove String.count/String.offset In-Reply-To: References: <1D5C5BC1-C6E8-4807-9D5B-2530CDEAD479@oracle.com> <4FBF763A.6050202@oracle.com> Message-ID: <4FBF9FB2.2010705@oracle.com> On 05/25/2012 09:48 AM, Mike Duigou wrote: >> A non-material comment is that there are a couple of style changes that I found annoying. Everyone is an expert on such matters, I'm not, but the one that bugged me a bit was adding the space after the cast, eg: >> (toffset> (long) value.length - len) >> I found myself needing to re-read it to see if the cast applied to value.length or value.length-len. It's a minor point but you know what I mean. > I too mostly prefer casts without a space. The code was reformatted with an IDE because I'm actually terrible about being consistent in my formatting. Mechanically formatted code, like mechanically separated meat, lacks any sense of what is readable to a human. I will remove some of the spaces. > > Mike I realize this is an aside, but it would be helpful to maintain consistency in the code base if we had IDE-specific formatting profiles that we could post on the openjdk dev site that everyone could simply download and use with their favorite IDEs. I'm sure that these discussions probably come up all the time during reviews. Does anyone have one or more of these already? If not, I'll volunteer to put one together for both Netbeans and Eclipse. (I also realize that this is probably better posted on a different e-mail list, but I didn't want to do so out of context. I'll move it elsewhere, but being new to this community, not sure where to do that, so please let me know). From kumar.x.srinivasan at oracle.COM Fri May 25 15:31:03 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Fri, 25 May 2012 08:31:03 -0700 Subject: Please review: 7168401: pack200 does not produce a compatible pack file Message-ID: <4FBFA5B7.5020408@oracle.COM> Hi, Please review, changes has been internally reviewed by John. http://cr.openjdk.java.net/~ksrini/7168401/webrev.0/ Thanks Kumar From forax at univ-mlv.fr Fri May 25 16:25:49 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 25 May 2012 18:25:49 +0200 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps In-Reply-To: References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> <1337758719.27301.YahooMailNeo@web87704.mail.ir2.yahoo.com> <4FBD7360.4050306@oracle.com> <7BB1802F-0642-4133-B39C-3430335503B8@oracle.com> Message-ID: <4FBFB28D.7090101@univ-mlv.fr> On 05/25/2012 04:41 AM, Krystal Mok wrote: > Hi Mike, > > On Fri, May 25, 2012 at 10:12 AM, Mike Duigouwrote: > >> On May 24 2012, at 16:32 , Vitaly Davidovich wrote: >> >>> That's a bit odd as I thought the Klass object in the VM stored >> something like 7 supers, which includes interfaces (if I'm not mistaken). >> I know that instanceof checks against final classes are optimized into a >> simple cmp against an address, but I'm surprised that a check against an >> interface for classes in a very shallow type hierarchy is up to x25 slower. >> Do you know why that is Mike? Did you ask the compiler guys by chance? >> I didn't actually look much further into it other than to write a small >> microbenchmark to make sure it was the instanceof check. I tested a couple >> of different configs of classes and interfaces and supers. I was able to >> validate that 'x instanceof String' was as fast as 'x.getClass() == >> String.class' and that other cases were slower. Inheritance checks seemed >> faster than checks on interfaces. That was enough to tell me that I was on >> the wrong track with 'x instanceof Hashable' as a way to determine which >> hash algorithm to use. At least for C2 server compiler. >> >> FYI, "x.getClass() == String.class" will be just as fast when 7170463 [1] > is in. > > @Vitaly > > The fast subtype checking algorithm in HotSpot treats interfaces as > "secondary supers", which goes through a slow path. The super type display > in instanceKlass is only for "primary supers", which does not include > interfaces for instance classes. You may want to check out the details in > this paper [2]. Also the code of HashMap is used from too many callsites so the JIT will not be able to use any profiling information. > >> Definition 5: A class T is a secondary type iff T is an interface or >> an array of a secondary type. Every type is either a primary >> type or a secondary type but not both. > Regards, > Kris > > [1]: > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-May/007730.html > [2]: http://dl.acm.org/citation.cfm?id=583821 cheers, R?mi From schlosna at gmail.com Fri May 25 17:24:46 2012 From: schlosna at gmail.com (David Schlosnagle) Date: Fri, 25 May 2012 13:24:46 -0400 Subject: Request for Review : CR#6924259: Remove String.count/String.offset In-Reply-To: <4FBF8FC2.1030608@univ-mlv.fr> References: <1D5C5BC1-C6E8-4807-9D5B-2530CDEAD479@oracle.com> <4FBF763A.6050202@oracle.com> <4FBF8FC2.1030608@univ-mlv.fr> Message-ID: >> On 24/05/2012 21:45, Mike Duigou wrote: >>> >>> Hello all; >>> >>> For a long time preparations and planing have been underway to remove the >>> offset and count fields from java.lang.String. These two fields enable >>> multiple String instances to share the same backing character buffer. Shared >>> character buffers were an important optimization for old benchmarks but with >>> current real world code and benchmarks it's actually better to not share >>> backing buffers. Shared char array backing buffers only "win" with very >>> heavy use of String.substring. The negatively impacted situations can >>> include parsers and compilers however current testing shows that overall >>> this change is beneficial. >>> >>> The current plan is to commit this change to jdk8 before build 40 >>> followed by jdk7u6. Removing offset/count is a complicated process because >>> HotSpot has special case code for String that depends upon the two fields. >>> Vladimir Kozlov has committed the required HotSpot changes already >>> (http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/8f972594effc). >>> >>> A patch of the changes to java.lang.String for JDK 8 are >>> at. The changes for >>> JDK 7 have only superficial differences (line offsets in the patch). >>> >>> Comments are welcome. >>> >>> Mike Hi Mike, I had a few quick comments that I didn't see exactly covered so far: Should we extract original.value to a local to avoid multiple getfield instructions in the non-empty case? public String(String original) { char[] originalValue = original.value; this.value = (originalValue.length > 0) ? originalValue : EMPTY_STRING_VALUE; this.hash = original.hash; } Should the len be moved outside of the if condition in the following, and use Arrays.copyOf (or value.clone()) to simplify the code and hopefully be intrinsified? public String(char value[]) { final int len = value.length; this.value = (len > 0) ? Arrays.copyOf(value, len); : EMPTY_STRING_VALUE; } [1] http://markmail.org/message/ubg6s5dyvsidjipj Thanks, Dave From forax at univ-mlv.fr Fri May 25 17:38:53 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 25 May 2012 19:38:53 +0200 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps In-Reply-To: <94E7336B-91D6-4191-84EA-C9B668B0D172@oracle.com> References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> <94E7336B-91D6-4191-84EA-C9B668B0D172@oracle.com> Message-ID: <4FBFC3AD.5020709@univ-mlv.fr> On 05/24/2012 09:34 PM, Mike Duigou wrote: > Hello All; > > I have updated the webrevs for alternative hashing for String with feedback from Remi, Doug, Ulf and internal reviewers. > > Additional feedback is welcome. > > Mike > > [1] althashing "7" webrev : http://cr.openjdk.java.net/~mduigou/althashing7/9/webrev/ > [2] althashing "8" webrev : http://cr.openjdk.java.net/~mduigou/althashing8/9/webrev/ Hello Mike, just two small issues. In WeakHashMap.hash(), the null check should be done at callsite, the call to hash32() should be directly returned like in HashMap. Is Hashable32 is used anymore ? R?mi > > On May 22 2012, at 22:16 , Mike Duigou wrote: > >> Dear OpenJDK CoreLibs community, >> >> A significant enhancement to the Java SE hashing-based Map implementations in planned for inclusion in Java SE 7u6. All of the hashing based Map implementations: HashMap, Hashtable, LinkedHashMap, WeakHashMap and ConcurrentHashMap will now use an enhanced hashing algorithm for string keys when the capacity of the hash table has ever grown beyond 512 entries. The enhanced hashing implementation uses the murmur3 hashing algorithm[1] along with random hash seeds and index masks. These enhancements mitigate cases where colliding String hash values could result in a performance bottleneck. >> >> In order to provide the greatest opportunity for developers to test compatibility with their applications this change will be incorporated into JDK7u6 build 12 and JDK8 build 39. Both builds are planned for release next week. ***For 7u6 build 12 only, the alternative hashing will be unconditionally enabled (always on).*** The threshold default will be reset to the intended release default (512) for 7u6 build 13. >> >> The quick promotion of this change into builds with limited opportunity for public review and the special behaviour for build 12 is intended to make it easier for developers to test their application compatibility. Feedback on the approach, implementation, compatibility and performance is eagerly sought and encouraged both before *and after* this change is incorporated into the OpenJDK repositories. >> >> A new system property, jdk.map.althashing.threshold, allows adjustment of the threshold for enabling the enhanced hashing algorithm. If changed from the default value of 512, the enhanced hashing will be invoked any time after map capacity exceeds the value of jdk.map.althashing.threshold. To completely disable the enhanced hashing (not recommended), set jdk.map.althashing.threshold to -1 or a very large number such as 2^31 -1 (Integer.MAX_VALUE). >> >> The iteration order of keys, values and entries for hash-based maps where the new algorithm has been invoked will vary for each HashMap instance. While the Java SE Map documentation makes no promises that iteration order of items returned from Maps will be consistent, developers should check if their applications have incorrectly created a dependency on the iteration order of Map entries, keys or values. >> >> Webrevs for the Java 7u6 and 8 changes are available for download at [2] and [3] for your review. There are some important differences between the Java 7 and 8 implementations of this enhancement. Most specifically in the Java 8 implementation alternative string hashing is always enabled--no threshold is used for enablement and alternative hashing cannot be disabled. (The Java 8 implementation completely ignores the jdk.map.althashing.threshold system property). The Java 8 implementation is also subject to additional refinement as Java 8 develops. >> >> If you have any questions or concerns with this planned enhancement, please use the corelibs development mailing list,, or you may also respond privately to me if you prefer. >> >> Thanks, >> >> Mike >> >> [1] Murmur3 : https://code.google.com/p/smhasher/wiki/MurmurHash3 >> [2] althashing "7" webrev : http://cr.openjdk.java.net/~mduigou/althashing7/8/webrev/ >> [3] althashing "8" webrev : http://cr.openjdk.java.net/~mduigou/althashing8/8/webrev/ From daniel.daugherty at oracle.com Fri May 25 17:38:51 2012 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Fri, 25 May 2012 17:38:51 +0000 Subject: hg: jdk8/tl/jdk: 7170449: Management is completely broken at least on Solaris 11 X86 Message-ID: <20120525173901.EA8F14751F@hg.openjdk.java.net> Changeset: 82134992123c Author: dcubed Date: 2012-05-25 08:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/82134992123c 7170449: Management is completely broken at least on Solaris 11 X86 Summary: Work around 'gobjcopy' failures on Solaris by adding temporary tools to add the '.gnu_debuglink' section and remove the SHF_ALLOC flag from "empty" section headers. Reviewed-by: sspitsyn, acorn ! make/common/Defs-solaris.gmk ! make/common/Defs.gmk ! make/common/Library.gmk ! make/common/Program.gmk ! make/tools/Makefile + make/tools/add_gnu_debuglink/Makefile + make/tools/add_gnu_debuglink/add_gnu_debuglink.c + make/tools/fix_empty_sec_hdr_flags/Makefile + make/tools/fix_empty_sec_hdr_flags/fix_empty_sec_hdr_flags.c From Lance.Andersen at oracle.com Fri May 25 19:50:39 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Fri, 25 May 2012 15:50:39 -0400 Subject: Review request for CR 171917 CachedRowSetImpl.populate does not handle map properly Message-ID: Attached is the fix for bug 171917 . The populate() method needs to check for a size of 0 for the map in case a webrowset xml file has an empty map tag, which would result in calling setobject specifying a map and not all databases/drivers support this. simple 1 line change: hg diff CachedRowSetImpl.java diff -r 4580652d9828 src/share/classes/com/sun/rowset/CachedRowSetImpl.java --- a/src/share/classes/com/sun/rowset/CachedRowSetImpl.java Fri May 04 16:00:47 2012 -0400 +++ b/src/share/classes/com/sun/rowset/CachedRowSetImpl.java Fri May 25 15:45:29 2012 -0400 @@ -659,7 +659,7 @@ * us work with drivers that do not support * getObject with a map in fairly sensible way */ - if (map == null) { + if (map == null || map.size() == 0) { obj = data.getObject(i); } else { obj = data.getObject(i, map); Best Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From Lance.Andersen at oracle.com Fri May 25 19:56:41 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Fri, 25 May 2012 15:56:41 -0400 Subject: Review request CR 7171918 XmlReaderContentHandler.endElement does not handle a Delete Tag properly Message-ID: <8967800E-31D0-41C2-A320-9EA35685E0EE@oracle.com> Attached is the fix for 7171918. If a WebRowSet is written to disk that contains a row marked for deletion and then read back into a WebRowSet, it was not marked again as a deleted row. Here is the fix to endElement() to address this. hg diff XmlReaderContentHandler.java diff -r 4580652d9828 src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java --- a/src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java Fri May 04 16:00:47 2012 -0400 +++ b/src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java Fri May 25 15:52:21 2012 -0400 @@ -764,6 +764,7 @@ rs.next(); rs.setOriginalRow(); applyUpdates(); + rs.deleteRow(); } catch (SQLException ex) { throw new SAXException(MessageFormat.format(resBundle.handleGetObject("xmlrch.errdel").toString() , ex.getMessage())); Best, Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From jeffhain at rocketmail.com Fri May 25 20:30:55 2012 From: jeffhain at rocketmail.com (Jeff Hain) Date: Fri, 25 May 2012 21:30:55 +0100 (BST) Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps [private fields] In-Reply-To: <4FBCBF17.4030403@univ-mlv.fr> References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> <4FBCBF17.4030403@univ-mlv.fr> Message-ID: <1337977855.79766.YahooMailNeo@web132104.mail.ird.yahoo.com> Hello. >In HashMap, the class Holder should not declare the static final fields >'private' because the compiler will generate an accessor in that case, I wasn't aware that making fields private could have a downside (other than making them non-visible). Could you, or anyone, please give (a link to) more info about this? Thanks. -Jeff From Ulf.Zibis at gmx.de Fri May 25 21:22:31 2012 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 25 May 2012 23:22:31 +0200 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps [private fields] In-Reply-To: <1337977855.79766.YahooMailNeo@web132104.mail.ird.yahoo.com> References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> <4FBCBF17.4030403@univ-mlv.fr> <1337977855.79766.YahooMailNeo@web132104.mail.ird.yahoo.com> Message-ID: <4FBFF817.9070000@gmx.de> Am 25.05.2012 22:30, schrieb Jeff Hain: > Hello. > >> In HashMap, the class Holder should not declare the static final fields >> 'private' because the compiler will generate an accessor in that case, > I wasn't aware that making fields private could have a downside > (other than making them non-visible). > > Could you, or anyone, please give (a link to) more info about this? I'm interested too. -Ulf From vitalyd at gmail.com Fri May 25 21:50:06 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 25 May 2012 17:50:06 -0400 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps [private fields] In-Reply-To: <4FBFF817.9070000@gmx.de> References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> <4FBCBF17.4030403@univ-mlv.fr> <1337977855.79766.YahooMailNeo@web132104.mail.ird.yahoo.com> <4FBFF817.9070000@gmx.de> Message-ID: This is specific to private fields in inner classes - java allows access to them from the outer class, but the JVM doesn't so javac generates synthetic accessor methods for them. Don't think it's a problem for JIT compiler though as it should inline them. Sent from my phone On May 25, 2012 5:23 PM, "Ulf Zibis" wrote: > Am 25.05.2012 22:30, schrieb Jeff Hain: > >> Hello. >> >> In HashMap, the class Holder should not declare the static final fields >>> 'private' because the compiler will generate an accessor in that case, >>> >> I wasn't aware that making fields private could have a downside >> (other than making them non-visible). >> >> Could you, or anyone, please give (a link to) more info about this? >> > I'm interested too. > > -Ulf > > From vitalyd at gmail.com Fri May 25 21:55:34 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 25 May 2012 17:55:34 -0400 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps [private fields] In-Reply-To: References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> <4FBCBF17.4030403@univ-mlv.fr> <1337977855.79766.YahooMailNeo@web132104.mail.ird.yahoo.com> <4FBFF817.9070000@gmx.de> Message-ID: In case it's not clear, by JVM not allowing them I simply mean that it doesn't know about nested classes (not a first class concept), so since it's emulated by javac, javac creates these package private synthetic accessors. Sent from my phone On May 25, 2012 5:50 PM, "Vitaly Davidovich" wrote: > This is specific to private fields in inner classes - java allows access > to them from the outer class, but the JVM doesn't so javac generates > synthetic accessor methods for them. Don't think it's a problem for JIT > compiler though as it should inline them. > > Sent from my phone > On May 25, 2012 5:23 PM, "Ulf Zibis" wrote: > >> Am 25.05.2012 22:30, schrieb Jeff Hain: >> >>> Hello. >>> >>> In HashMap, the class Holder should not declare the static final fields >>>> 'private' because the compiler will generate an accessor in that case, >>>> >>> I wasn't aware that making fields private could have a downside >>> (other than making them non-visible). >>> >>> Could you, or anyone, please give (a link to) more info about this? >>> >> I'm interested too. >> >> -Ulf >> >> From forax at univ-mlv.fr Fri May 25 22:04:52 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sat, 26 May 2012 00:04:52 +0200 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps [private fields] In-Reply-To: References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> <4FBCBF17.4030403@univ-mlv.fr> <1337977855.79766.YahooMailNeo@web132104.mail.ird.yahoo.com> <4FBFF817.9070000@gmx.de> Message-ID: <4FC00204.4010105@univ-mlv.fr> On 05/25/2012 11:50 PM, Vitaly Davidovich wrote: > This is specific to private fields in inner classes - and methods and constructors > java allows access to > them from the outer class, but the JVM doesn't so javac generates synthetic > accessor methods for them. Don't think it's a problem for JIT compiler > though as it should inline them. yes, there are unconditionally inlined so performance is not the problem. The issues are more that the compiler generates unnecessary code, unnecessary class metadata, stack pollution and stacktrace pollution too. R?mi > > Sent from my phone > On May 25, 2012 5:23 PM, "Ulf Zibis" wrote: > >> Am 25.05.2012 22:30, schrieb Jeff Hain: >> >>> Hello. >>> >>> In HashMap, the class Holder should not declare the static final fields >>>> 'private' because the compiler will generate an accessor in that case, >>>> >>> I wasn't aware that making fields private could have a downside >>> (other than making them non-visible). >>> >>> Could you, or anyone, please give (a link to) more info about this? >>> >> I'm interested too. >> >> -Ulf >> >> From forax at univ-mlv.fr Fri May 25 22:08:28 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sat, 26 May 2012 00:08:28 +0200 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps [private fields] In-Reply-To: References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> <4FBCBF17.4030403@univ-mlv.fr> <1337977855.79766.YahooMailNeo@web132104.mail.ird.yahoo.com> <4FBFF817.9070000@gmx.de> Message-ID: <4FC002DC.7040001@univ-mlv.fr> On 05/25/2012 11:55 PM, Vitaly Davidovich wrote: > In case it's not clear, by JVM not allowing them I simply mean that it > doesn't know about nested classes (not a first class concept), so since > it's emulated by javac, javac creates these package private synthetic > accessors. BTW, the VM knows what an anonymous class is (there is an host class field in the runtime class meta-data), it's more a class format issue now, i.e. the class format doesn't support to put more than one class in a .class classfile. R?mi > > Sent from my phone > On May 25, 2012 5:50 PM, "Vitaly Davidovich" wrote: > >> This is specific to private fields in inner classes - java allows access >> to them from the outer class, but the JVM doesn't so javac generates >> synthetic accessor methods for them. Don't think it's a problem for JIT >> compiler though as it should inline them. >> >> Sent from my phone >> On May 25, 2012 5:23 PM, "Ulf Zibis" wrote: >> >>> Am 25.05.2012 22:30, schrieb Jeff Hain: >>> >>>> Hello. >>>> >>>> In HashMap, the class Holder should not declare the static final fields >>>>> 'private' because the compiler will generate an accessor in that case, >>>>> >>>> I wasn't aware that making fields private could have a downside >>>> (other than making them non-visible). >>>> >>>> Could you, or anyone, please give (a link to) more info about this? >>>> >>> I'm interested too. >>> >>> -Ulf >>> >>> From mike.duigou at oracle.com Fri May 25 22:09:28 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 25 May 2012 15:09:28 -0700 Subject: Request for Review : CR#6924259: Remove String.count/String.offset In-Reply-To: <4FBF8FC2.1030608@univ-mlv.fr> References: <1D5C5BC1-C6E8-4807-9D5B-2530CDEAD479@oracle.com> <4FBF763A.6050202@oracle.com> <4FBF8FC2.1030608@univ-mlv.fr> Message-ID: <48E4C36B-5014-4EAE-845F-65A6852A3F25@oracle.com> On May 25 2012, at 06:57 , R?mi Forax wrote: > Hi Mike, Hi Alan, Hi all, > in my opinion, EMPTY_STRING_VALUE is a premature optimization, > the idea is, I think, to avoid to create an empty char but if you want to do that, > it's better to do that in StringBuilder.toString() to avoid to create the String at all. I have removed most of the use of EMPTY_STRING_VALUE. It remains for the empty constructor only. > > I'm worried about one pathological case where a lot of non empty String > will be created and then one empty will be created after the code will be JITed, > in that case Hotspot will deoptimize all codes that have inlined the constructor call. Reasonable and confirmed with Valdimir Kozlov. > String(StringBuilder) and String(StringBuffer) can be simplified > by using length() and getValue() (AbstractStringBuilder.getValue()) > to extract the info. > this.value = Arrays.copyOf(builder.getValue(), builder.length()); > and avoid to create a temporary String. Good optimization. I had to add a sync around the buffer version. > > String(char value[], boolean share) should be > String(char[] value, boolean share) and is there a perf reason to > not use a static method like createSharedString() instead. none. I will leave for a later change. > > Removing String(int offset, int count, char value[]) will create trouble, > I've seen several libraries that use it by reflection to avoid to create > a copy of the array. I think this method should not disappear > but use Arrays.copyOfRange if the offset is not 0. > This method should be marked deprecated, and removed in Java 9. Restored but deprecated. > > Recently, _getChars(char[], int) was replaced by > getChars(char[],int). It was a stupid change because now > one can think that getChar(char[], int) and getChar(int,int,char[],int) > do the same things. but getChat(char[],int) don't do any bounds check. > So concat() and toCharArray() doesn't do any bound check ! I don't see where either of them need to do any checking. > toCharArray() should use Arrays.copyOf() Done. > Overloads of encode in StringCoding are in my opinion not necessary > because each method is called once. Reasonable. I opted not to add the 3rd variant ([] count) because it wasn't used. I've reverted to using the 3 param version. > So this doesn't really share code > but just add one level to the depth of the call stack. > > cheers, > R?mi > > On 05/25/2012 02:08 PM, Alan Bateman wrote: >> On 24/05/2012 21:45, Mike Duigou wrote: >>> Hello all; >>> >>> For a long time preparations and planing have been underway to remove the offset and count fields from java.lang.String. These two fields enable multiple String instances to share the same backing character buffer. Shared character buffers were an important optimization for old benchmarks but with current real world code and benchmarks it's actually better to not share backing buffers. Shared char array backing buffers only "win" with very heavy use of String.substring. The negatively impacted situations can include parsers and compilers however current testing shows that overall this change is beneficial. >>> >>> The current plan is to commit this change to jdk8 before build 40 followed by jdk7u6. Removing offset/count is a complicated process because HotSpot has special case code for String that depends upon the two fields. Vladimir Kozlov has committed the required HotSpot changes already (http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/8f972594effc). >>> >>> A patch of the changes to java.lang.String for JDK 8 are at. The changes for JDK 7 have only superficial differences (line offsets in the patch). >>> >>> Comments are welcome. >>> >>> Mike >> I went through the latest webrev and don't see anything obviously wrong. EMPTY_STRING_VALUE is new, at least to me, as I don't think it was there when removing these fields was prototyped a few years ago. >> >> A minor point in the String(char[]) constructor is that you could move the "int len = .." to the top of the method to be consistent with other places where a local holds the value.length. >> >> The "use name version for caching" comment in StringCoding.java might be confusing to readers, maybe "use charset name as this is faster due to caching". >> >> A non-material comment is that there are a couple of style changes that I found annoying. Everyone is an expert on such matters, I'm not, but the one that bugged me a bit was adding the space after the cast, eg: >> (toffset > (long) value.length - len) >> I found myself needing to re-read it to see if the cast applied to value.length or value.length-len. It's a minor point but you know what I mean. >> >> -Alan. > From vitalyd at gmail.com Fri May 25 22:09:36 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 25 May 2012 18:09:36 -0400 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps [private fields] In-Reply-To: <4FC00204.4010105@univ-mlv.fr> References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> <4FBCBF17.4030403@univ-mlv.fr> <1337977855.79766.YahooMailNeo@web132104.mail.ird.yahoo.com> <4FBFF817.9070000@gmx.de> <4FC00204.4010105@univ-mlv.fr> Message-ID: Yes, methods/constructors as well - I should've pointed that out but only answered the field question that was originally asked. Valid points on metadata and stack pollution, although a bit pedantic for real code :). Thanks Sent from my phone On May 25, 2012 6:03 PM, "R?mi Forax" wrote: > On 05/25/2012 11:50 PM, Vitaly Davidovich wrote: > >> This is specific to private fields in inner classes - >> > > and methods and constructors > > java allows access to >> them from the outer class, but the JVM doesn't so javac generates >> synthetic >> accessor methods for them. Don't think it's a problem for JIT compiler >> though as it should inline them. >> > > yes, there are unconditionally inlined so performance is not the problem. > The issues are more that the compiler generates unnecessary code, > unnecessary class metadata, stack pollution and stacktrace pollution too. > > R?mi > > >> Sent from my phone >> On May 25, 2012 5:23 PM, "Ulf Zibis" wrote: >> >> Am 25.05.2012 22:30, schrieb Jeff Hain: >>> >>> Hello. >>>> >>>> In HashMap, the class Holder should not declare the static final fields >>>> >>>>> 'private' because the compiler will generate an accessor in that case, >>>>> >>>>> I wasn't aware that making fields private could have a downside >>>> (other than making them non-visible). >>>> >>>> Could you, or anyone, please give (a link to) more info about this? >>>> >>>> I'm interested too. >>> >>> -Ulf >>> >>> >>> > From vitalyd at gmail.com Fri May 25 22:17:58 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 25 May 2012 18:17:58 -0400 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps [private fields] In-Reply-To: <4FC002DC.7040001@univ-mlv.fr> References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> <4FBCBF17.4030403@univ-mlv.fr> <1337977855.79766.YahooMailNeo@web132104.mail.ird.yahoo.com> <4FBFF817.9070000@gmx.de> <4FC002DC.7040001@univ-mlv.fr> Message-ID: I assume you're referring to instanceKlass::_host_klass? The comment on that field says it's only non-null for an anonymous class, no mention of named inner classes. Are you sure it's used for named inner classes to point back to their parent? Cheers Sent from my phone On May 25, 2012 6:06 PM, "R?mi Forax" wrote: > On 05/25/2012 11:55 PM, Vitaly Davidovich wrote: > >> In case it's not clear, by JVM not allowing them I simply mean that it >> doesn't know about nested classes (not a first class concept), so since >> it's emulated by javac, javac creates these package private synthetic >> accessors. >> > > BTW, the VM knows what an anonymous class is > (there is an host class field in the runtime class meta-data), > it's more a class format issue now, i.e. the class format > doesn't support to put more than one class in a .class > classfile. > > R?mi > > >> Sent from my phone >> On May 25, 2012 5:50 PM, "Vitaly Davidovich" wrote: >> >> This is specific to private fields in inner classes - java allows access >>> to them from the outer class, but the JVM doesn't so javac generates >>> synthetic accessor methods for them. Don't think it's a problem for JIT >>> compiler though as it should inline them. >>> >>> Sent from my phone >>> On May 25, 2012 5:23 PM, "Ulf Zibis" wrote: >>> >>> Am 25.05.2012 22:30, schrieb Jeff Hain: >>>> >>>> Hello. >>>>> >>>>> In HashMap, the class Holder should not declare the static final >>>>> fields >>>>> >>>>>> 'private' because the compiler will generate an accessor in that case, >>>>>> >>>>>> I wasn't aware that making fields private could have a downside >>>>> (other than making them non-visible). >>>>> >>>>> Could you, or anyone, please give (a link to) more info about this? >>>>> >>>>> I'm interested too. >>>> >>>> -Ulf >>>> >>>> >>>> > From forax at univ-mlv.fr Fri May 25 22:20:26 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sat, 26 May 2012 00:20:26 +0200 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps [private fields] In-Reply-To: References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> <4FBCBF17.4030403@univ-mlv.fr> <1337977855.79766.YahooMailNeo@web132104.mail.ird.yahoo.com> <4FBFF817.9070000@gmx.de> <4FC00204.4010105@univ-mlv.fr> Message-ID: <4FC005AA.6050107@univ-mlv.fr> On 05/26/2012 12:09 AM, Vitaly Davidovich wrote: > > Yes, methods/constructors as well - I should've pointed that out but > only answered the field question that was originally asked. > > Valid points on metadata and stack pollution, although a bit pedantic > for real code :). > given that this code is in java.lang, thus use by millions, I have no problem to agree that when I review this kind of code, I switch myself in pedandic-mode. > Thanks > cheers, R?mi > Sent from my phone > > On May 25, 2012 6:03 PM, "R?mi Forax" > wrote: > > On 05/25/2012 11:50 PM, Vitaly Davidovich wrote: > > This is specific to private fields in inner classes - > > > and methods and constructors > > java allows access to > them from the outer class, but the JVM doesn't so javac > generates synthetic > accessor methods for them. Don't think it's a problem for JIT > compiler > though as it should inline them. > > > yes, there are unconditionally inlined so performance is not the > problem. > The issues are more that the compiler generates unnecessary code, > unnecessary class metadata, stack pollution and stacktrace > pollution too. > > R?mi > > > Sent from my phone > On May 25, 2012 5:23 PM, "Ulf Zibis" > wrote: > > Am 25.05.2012 22 :30, schrieb Jeff Hain: > > Hello. > > In HashMap, the class Holder should not declare the > static final fields > > 'private' because the compiler will generate an > accessor in that case, > > I wasn't aware that making fields private could have a > downside > (other than making them non-visible). > > Could you, or anyone, please give (a link to) more > info about this? > > I'm interested too. > > -Ulf > > > From forax at univ-mlv.fr Fri May 25 22:21:16 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sat, 26 May 2012 00:21:16 +0200 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps [private fields] In-Reply-To: References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> <4FBCBF17.4030403@univ-mlv.fr> <1337977855.79766.YahooMailNeo@web132104.mail.ird.yahoo.com> <4FBFF817.9070000@gmx.de> <4FC002DC.7040001@univ-mlv.fr> Message-ID: <4FC005DC.6080703@univ-mlv.fr> On 05/26/2012 12:17 AM, Vitaly Davidovich wrote: > > I assume you're referring to instanceKlass::_host_klass? The comment > on that field says it's only non-null for an anonymous class, no > mention of named inner classes. Are you sure it's used for named > inner classes to point back to their parent? > I'm sure it's not used but it can be. > Cheers > cheers, R?mi From forax at univ-mlv.fr Fri May 25 22:33:21 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sat, 26 May 2012 00:33:21 +0200 Subject: Request for Review : CR#6924259: Remove String.count/String.offset In-Reply-To: <48E4C36B-5014-4EAE-845F-65A6852A3F25@oracle.com> References: <1D5C5BC1-C6E8-4807-9D5B-2530CDEAD479@oracle.com> <4FBF763A.6050202@oracle.com> <4FBF8FC2.1030608@univ-mlv.fr> <48E4C36B-5014-4EAE-845F-65A6852A3F25@oracle.com> Message-ID: <4FC008B1.4020500@univ-mlv.fr> On 05/26/2012 12:09 AM, Mike Duigou wrote: > On May 25 2012, at 06:57 , R?mi Forax wrote: > >> Hi Mike, Hi Alan, Hi all, >> in my opinion, EMPTY_STRING_VALUE is a premature optimization, >> the idea is, I think, to avoid to create an empty char but if you want to do that, >> it's better to do that in StringBuilder.toString() to avoid to create the String at all. > I have removed most of the use of EMPTY_STRING_VALUE. It remains for the empty constructor only. I may be wrong but this constructor is used rarely so for me it's like you add one static field that will be never used. [...] > >> Recently, _getChars(char[], int) was replaced by >> getChars(char[],int). It was a stupid change because now >> one can think that getChar(char[], int) and getChar(int,int,char[],int) >> do the same things. but getChat(char[],int) don't do any bounds check. >> So concat() and toCharArray() doesn't do any bound check ! > I don't see where either of them need to do any checking. duh, sorry, I've forgotten the basics. You're right. > >> toCharArray() should use Arrays.copyOf() > Done. > >> Overloads of encode in StringCoding are in my opinion not necessary >> because each method is called once. > Reasonable. I opted not to add the 3rd variant ([] count) because it wasn't used. I've reverted to using the 3 param version. > >> So this doesn't really share code >> but just add one level to the depth of the call stack. >> >> cheers, >> R?mi regards, R?mi From Ulf.Zibis at gmx.de Fri May 25 22:36:06 2012 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 26 May 2012 00:36:06 +0200 Subject: Request for Review : CR#6924259: Remove String.count/String.offset In-Reply-To: <4FBF9FB2.2010705@oracle.com> References: <1D5C5BC1-C6E8-4807-9D5B-2530CDEAD479@oracle.com> <4FBF763A.6050202@oracle.com> <4FBF9FB2.2010705@oracle.com> Message-ID: <4FC00956.9030201@gmx.de> Am 25.05.2012 17:05, schrieb Jim Gish: > On 05/25/2012 09:48 AM, Mike Duigou wrote: >> I too mostly prefer casts without a space. The code was reformatted with an IDE because I'm >> actually terrible about being consistent in my formatting. Mechanically formatted code, like >> mechanically separated meat, lacks any sense of what is readable to a human. I will remove some >> of the spaces. >> >> Mike > I realize this is an aside, but it would be helpful to maintain consistency in the code base if we > had IDE-specific formatting profiles that we could post on the openjdk dev site that everyone > could simply download and use with their favorite IDEs. I'm sure that these discussions probably > come up all the time during reviews. Does anyone have one or more of these already? If not, I'll > volunteer to put one together for both Netbeans and Eclipse. (I also realize that this is probably > better posted on a different e-mail list, but I didn't want to do so out of context. I'll move it > elsewhere, but being new to this community, not sure where to do that, so please let me know). I believe IDE implementers refer to the "Code Conventions for the JavaTM Programming Language", 8.2 by default. So simply fixing this bug would help: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6939278 -Ulf From vitalyd at gmail.com Fri May 25 22:36:27 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 25 May 2012 18:36:27 -0400 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps [private fields] In-Reply-To: <4FC005AA.6050107@univ-mlv.fr> References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> <4FBCBF17.4030403@univ-mlv.fr> <1337977855.79766.YahooMailNeo@web132104.mail.ird.yahoo.com> <4FBFF817.9070000@gmx.de> <4FC00204.4010105@univ-mlv.fr> <4FC005AA.6050107@univ-mlv.fr> Message-ID: Agreed on JDK code, but since accessors are also generated for access to outer class' private fields/methods from inner class, wouldn't want people to increase visibility of those fields/methods just to get rid of the accessors in their own code thinking that there are serious problems associated with them. Anyway, we're in agreement. :) Sent from my phone On May 25, 2012 6:18 PM, "R?mi Forax" wrote: > On 05/26/2012 12:09 AM, Vitaly Davidovich wrote: > >> >> Yes, methods/constructors as well - I should've pointed that out but only >> answered the field question that was originally asked. >> >> Valid points on metadata and stack pollution, although a bit pedantic for >> real code :). >> >> > given that this code is in java.lang, thus use by millions, > I have no problem to agree that when I review this kind of code, > I switch myself in pedandic-mode. > > Thanks >> >> > cheers, > R?mi > > Sent from my phone >> >> On May 25, 2012 6:03 PM, "R?mi Forax" > forax at univ-mlv.fr>> wrote: >> >> On 05/25/2012 11:50 PM, Vitaly Davidovich wrote: >> >> This is specific to private fields in inner classes - >> >> >> and methods and constructors >> >> java allows access to >> them from the outer class, but the JVM doesn't so javac >> generates synthetic >> accessor methods for them. Don't think it's a problem for JIT >> compiler >> though as it should inline them. >> >> >> yes, there are unconditionally inlined so performance is not the >> problem. >> The issues are more that the compiler generates unnecessary code, >> unnecessary class metadata, stack pollution and stacktrace >> pollution too. >> >> R?mi >> >> >> Sent from my phone >> On May 25, 2012 5:23 PM, "Ulf Zibis"> > wrote: >> >> Am 25.05.2012 22 :30, schrieb Jeff Hain: >> >> Hello. >> >> In HashMap, the class Holder should not declare the >> static final fields >> >> 'private' because the compiler will generate an >> accessor in that case, >> >> I wasn't aware that making fields private could have a >> downside >> (other than making them non-visible). >> >> Could you, or anyone, please give (a link to) more >> info about this? >> >> I'm interested too. >> >> -Ulf >> >> >> >> > From schlosna at gmail.com Fri May 25 23:35:56 2012 From: schlosna at gmail.com (David Schlosnagle) Date: Fri, 25 May 2012 19:35:56 -0400 Subject: Review request for CR 171917 CachedRowSetImpl.populate does not handle map properly In-Reply-To: References: Message-ID: On Fri, May 25, 2012 at 3:50 PM, Lance Andersen - Oracle wrote: > The populate() method needs to check for a size of 0 for the map in case a webrowset xml file has an empty map tag, ?which would result in calling setobject specifying a map and not all databases/drivers support this. > > simple 1 line change: > > hg diff CachedRowSetImpl.java > diff -r 4580652d9828 src/share/classes/com/sun/rowset/CachedRowSetImpl.java > --- a/src/share/classes/com/sun/rowset/CachedRowSetImpl.java ? ?Fri May 04 16:00:47 2012 -0400 > +++ b/src/share/classes/com/sun/rowset/CachedRowSetImpl.java ? ?Fri May 25 15:45:29 2012 -0400 > @@ -659,7 +659,7 @@ > ? ? ? ? ? ? ? ? ?* us work with drivers that do not support > ? ? ? ? ? ? ? ? ?* getObject with a map in fairly sensible way > ? ? ? ? ? ? ? ? ?*/ > - ? ? ? ? ? ? ? ?if (map == null) { > + ? ? ? ? ? ? ? ?if (map == null || map.size() == 0) { Lance, Is there any reason not to use Map.isEmpty() which would be useful if the Map has an expensive size() method? - ? ? ? ? ? ? ? ?if (map == null) { + ? ? ? ? ? ? ? ?if (map == null || map.isEmpty()) { Thanks, Dave From Lance.Andersen at oracle.com Fri May 25 23:43:21 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Fri, 25 May 2012 19:43:21 -0400 Subject: Review request for CR 171917 CachedRowSetImpl.populate does not handle map properly In-Reply-To: References: Message-ID: <7A4ED504-193D-405B-8536-FB8CD817BBAD@oracle.com> Hi Dave, No, I should be able to make that change. Thanks for the suggestion. Once I do and rerun the unit tests, jck and sqe, I will send the diff back out. Best Lance On May 25, 2012, at 7:35 PM, David Schlosnagle wrote: > On Fri, May 25, 2012 at 3:50 PM, Lance Andersen - Oracle > wrote: >> The populate() method needs to check for a size of 0 for the map in case a webrowset xml file has an empty map tag, which would result in calling setobject specifying a map and not all databases/drivers support this. >> >> simple 1 line change: >> >> hg diff CachedRowSetImpl.java >> diff -r 4580652d9828 src/share/classes/com/sun/rowset/CachedRowSetImpl.java >> --- a/src/share/classes/com/sun/rowset/CachedRowSetImpl.java Fri May 04 16:00:47 2012 -0400 >> +++ b/src/share/classes/com/sun/rowset/CachedRowSetImpl.java Fri May 25 15:45:29 2012 -0400 >> @@ -659,7 +659,7 @@ >> * us work with drivers that do not support >> * getObject with a map in fairly sensible way >> */ >> - if (map == null) { >> + if (map == null || map.size() == 0) { > > Lance, > > Is there any reason not to use Map.isEmpty() which would be useful if > the Map has an expensive size() method? > > - if (map == null) { > + if (map == null || map.isEmpty()) { > > Thanks, > Dave Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From Ulf.Zibis at gmx.de Sat May 26 01:43:40 2012 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 26 May 2012 03:43:40 +0200 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps In-Reply-To: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> Message-ID: <4FC0354C.4010207@gmx.de> Am 23.05.2012 07:16, schrieb Mike Duigou: > Webrevs for the Java 7u6 and 8 changes are available for download at [2] and [3] for your review. There are some important differences between the Java 7 and 8 implementations of this enhancement. Most specifically in the Java 8 implementation alternative string hashing is always enabled--no threshold is used for enablement and alternative hashing cannot be disabled. (The Java 8 implementation completely ignores the jdk.map.althashing.threshold system property). The Java 8 implementation is also subject to additional refinement as Java 8 develops. To me it seems, that computing the murmur hash is more expensive, especially on short strings, than the old hash algorithm. So I think, a developer should have an influence on the hash algorithm to be used by a hash map, especially for strings, see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6812862. So I propose a public accessible field in String: public int customHash; Then the HashMap should have an overrideable hash method: protected int hash(K key) { h = key.hashCode(); h ^= (h >>> 20) ^ (h >>> 12); return h ^ (h >>> 7) ^ (h >>> 4); } Then we should have a new class: public class MurmurHashMap extends HashMap { protected final int hash(String key) { int h = key.customHash; if (h == 0) { // harmless data race on customHash here. h = Hashing.murmur3_32(HASHING_SEED, key); // ensure result is not zero to avoid recalculating h = (h != 0) ? h : 1; key.customHash = h; } return hashMask ^ h; } In class Hashing we need: public static int murmur3_32(int seed, String key) { int h1 = seed; int count = key.length(); // body for (int off = 0; count >= 2;) { int k1 = (key.charAt(off++) & 0xFFFF) | key.charAt(off++) << 16); // alternative: for (int off = 0; count >= 4;) { int k1 = (key.charAt(off) & 0x0FF) | (key.charAt(off + 1) & 0x0FF) << 8 | (key.charAt(off + 2) & 0x0FF) << 16 | key.charAt(off + 3) << 24; ... } ... } For other use cases see: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6812862 -Ulf From lana.steuck at oracle.com Sat May 26 02:13:27 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 26 May 2012 02:13:27 +0000 Subject: hg: jdk8/tl: 5 new changesets Message-ID: <20120526021328.54F6347537@hg.openjdk.java.net> Changeset: 955a3e8ed4f0 Author: ohair Date: 2012-05-10 08:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/955a3e8ed4f0 7167593: Changed get_source.sh to allow for getting full oracle jdk repo forest Reviewed-by: erikj, asaha, chegar, sla, dholmes, mbykov, coleenp ! get_source.sh ! make/scripts/hgforest.sh Changeset: 8a4e92c10a9a Author: ohair Date: 2012-05-11 17:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/8a4e92c10a9a 7167976: Fix broken get_source.sh script Reviewed-by: tbell ! make/scripts/hgforest.sh Changeset: 8927dd68aee3 Author: katleman Date: 2012-05-16 22:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/8927dd68aee3 Merge Changeset: a2b2d435f1d2 Author: katleman Date: 2012-05-17 06:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/a2b2d435f1d2 Added tag jdk8-b39 for changeset 8927dd68aee3 ! .hgtags Changeset: 1a8c7c530f8a Author: katleman Date: 2012-05-24 16:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/1a8c7c530f8a Added tag jdk8-b40 for changeset a2b2d435f1d2 ! .hgtags From lana.steuck at oracle.com Sat May 26 02:13:25 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 26 May 2012 02:13:25 +0000 Subject: hg: jdk8/tl/corba: 2 new changesets Message-ID: <20120526021328.2A6F647536@hg.openjdk.java.net> Changeset: 56d030e5035f Author: katleman Date: 2012-05-17 06:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/56d030e5035f Added tag jdk8-b39 for changeset 785af00e2827 ! .hgtags Changeset: 113f0d5f0a08 Author: katleman Date: 2012-05-24 16:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/113f0d5f0a08 Added tag jdk8-b40 for changeset 56d030e5035f ! .hgtags From lana.steuck at oracle.com Sat May 26 02:13:28 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 26 May 2012 02:13:28 +0000 Subject: hg: jdk8/tl/jaxws: 2 new changesets Message-ID: <20120526021336.2978F47538@hg.openjdk.java.net> Changeset: 09a0ddda03cb Author: katleman Date: 2012-05-17 06:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/09a0ddda03cb Added tag jdk8-b39 for changeset 7f6b44fd3034 ! .hgtags Changeset: f2072b164b05 Author: katleman Date: 2012-05-24 16:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/f2072b164b05 Added tag jdk8-b40 for changeset 09a0ddda03cb ! .hgtags From lana.steuck at oracle.com Sat May 26 02:13:39 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 26 May 2012 02:13:39 +0000 Subject: hg: jdk8/tl/jaxp: 2 new changesets Message-ID: <20120526021344.6E9DA47539@hg.openjdk.java.net> Changeset: 9ecfdbd6aed4 Author: katleman Date: 2012-05-17 06:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/9ecfdbd6aed4 Added tag jdk8-b39 for changeset f95fdbe525c8 ! .hgtags Changeset: 6f5c0e17415d Author: katleman Date: 2012-05-24 16:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/6f5c0e17415d Added tag jdk8-b40 for changeset 9ecfdbd6aed4 ! .hgtags From lana.steuck at oracle.com Sat May 26 02:13:39 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 26 May 2012 02:13:39 +0000 Subject: hg: jdk8/tl/langtools: 4 new changesets Message-ID: <20120526021348.100DA4753A@hg.openjdk.java.net> Changeset: 8b869afd2eb4 Author: katleman Date: 2012-05-17 06:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8b869afd2eb4 Added tag jdk8-b39 for changeset a9f547c218d9 ! .hgtags Changeset: 86e0dad6aadf Author: lana Date: 2012-05-21 11:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/86e0dad6aadf Merge Changeset: 179fa85aeefa Author: katleman Date: 2012-05-24 16:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/179fa85aeefa Added tag jdk8-b40 for changeset 86e0dad6aadf ! .hgtags Changeset: f43aded513e7 Author: lana Date: 2012-05-25 16:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f43aded513e7 Merge From lana.steuck at oracle.com Sat May 26 02:13:35 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 26 May 2012 02:13:35 +0000 Subject: hg: jdk8/tl/hotspot: 32 new changesets Message-ID: <20120526021441.28B774753B@hg.openjdk.java.net> Changeset: 36538fd1225e Author: amurillo Date: 2012-05-04 15:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/36538fd1225e 7166615: new hotspot build - hs24-b10 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 8bafad97cd26 Author: jiangli Date: 2012-05-02 13:21 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8bafad97cd26 7158552: The instanceKlsss::_host_klass is only needed for anonymous class for JSR 292 support. Summary: Change the _host_klass to be conditionally created embedded instanceKlass field. Reviewed-by: jrose, coleenp, dholmes ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/instanceKlassKlass.hpp Changeset: 38b4116b6766 Author: jprovino Date: 2012-05-05 10:24 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/38b4116b6766 Merge Changeset: c7ed11779ce8 Author: jiangli Date: 2012-04-10 09:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c7ed11779ce8 7159772: instanceKlass::all_fields_count() returns incorrect total field count Summary: Fix instanceKlass::all_fields_count() bug. Reviewed-by: kvn, never Contributed-by: Jiangli Zhou ! src/share/vm/oops/instanceKlass.hpp Changeset: 3576af4cb939 Author: iveresov Date: 2012-04-11 19:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3576af4cb939 7160539: JDeveloper crashes on 64-bit Windows Summary: x64 C1 needs to zero upper 32bits when doing l2i conversion Reviewed-by: never, kvn ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Changeset: 847da049d62f Author: never Date: 2012-04-17 11:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/847da049d62f 7162094: LateInlineCallGenerator::do_late_inline crashed on uninitialized _call_node Reviewed-by: never, twisti Contributed-by: nils.eliasson at oracle.com ! src/share/vm/opto/callGenerator.cpp Changeset: df3d4a91f7f6 Author: never Date: 2012-04-18 16:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/df3d4a91f7f6 7161796: PhaseStringOpts::fetch_static_field tries to fetch field from the Klass instead of the mirror Reviewed-by: twisti ! src/share/vm/opto/stringopts.cpp Changeset: ec15e8f6e4f1 Author: twisti Date: 2012-04-24 12:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ec15e8f6e4f1 7157695: Add windows implementation of socket interface Reviewed-by: kvn, dholmes, twisti Contributed-by: Nils Eliasson ! src/os/windows/vm/jvm_windows.h ! src/os/windows/vm/os_windows.cpp Changeset: dc682d9431f3 Author: kvn Date: 2012-05-07 12:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dc682d9431f3 7160610: Unknown Native Code compilation issue Summary: When constructing input vector use type of vector's operation which use it since element's sizes should match. Reviewed-by: never, twisti ! src/share/vm/opto/superword.cpp + test/compiler/7160610/Test7160610.java Changeset: 3a97daec1b34 Author: kvn Date: 2012-05-08 15:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3a97daec1b34 7167266: missing copyright notes in 3rd party code Summary: add missing copyright notes to the regression test file. Reviewed-by: twisti, johnc ! test/compiler/7070134/Stemmer.java Changeset: 2766551175a0 Author: kvn Date: 2012-05-09 10:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2766551175a0 Merge ! src/share/vm/oops/instanceKlass.hpp Changeset: a05a695ea044 Author: stefank Date: 2012-05-10 11:27 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a05a695ea044 7167437: Can't build on linux without precompiled headers Reviewed-by: brutisso, mgerdin ! src/share/vm/memory/space.hpp ! src/share/vm/memory/space.inline.hpp Changeset: f47478089efc Author: brutisso Date: 2012-05-10 14:16 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f47478089efc 7167069: 6 VM flags crash the VM when queried via jinfo Summary: Added missing double format to Flag::print_as_flag() Reviewed-by: dholmes, stefank, coleenp ! src/share/vm/runtime/globals.cpp + test/runtime/7167069/PrintAsFlag.java Changeset: 5799726c54d7 Author: jcoomes Date: 2012-05-11 06:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5799726c54d7 Merge Changeset: 73147e6c4881 Author: amurillo Date: 2012-05-11 14:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/73147e6c4881 Merge Changeset: 96a403721094 Author: amurillo Date: 2012-05-11 14:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/96a403721094 Added tag hs24-b10 for changeset 73147e6c4881 ! .hgtags Changeset: 26423ef693ac Author: katleman Date: 2012-05-17 06:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/26423ef693ac Added tag jdk8-b39 for changeset 96a403721094 ! .hgtags Changeset: 56d1af561395 Author: amurillo Date: 2012-05-11 14:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/56d1af561395 7168247: new hotspot build - hs24-b11 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 35e504cb49a6 Author: collins Date: 2012-05-11 11:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/35e504cb49a6 7167625: Adjustments for SE-Embedded build process Summary: Simple change to the SE-Embedded build rules that should not affect any other OpenJDK users. Reviewed-by: kvn, dholmes ! make/linux/makefiles/vm.make ! src/share/vm/runtime/arguments.cpp Changeset: fada85d11d92 Author: jprovino Date: 2012-05-16 13:33 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fada85d11d92 Merge Changeset: 8f972594effc Author: kvn Date: 2012-05-14 09:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8f972594effc 6924259: Remove String.count/String.offset Summary: Allow a version of String class that doesn't have count and offset fields. Reviewed-by: never, coleenp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/memory/dump.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/stringopts.cpp ! src/share/vm/opto/stringopts.hpp Changeset: de0cc3dd9f10 Author: kvn Date: 2012-05-17 09:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/de0cc3dd9f10 Merge Changeset: 3a22b77e755a Author: brutisso Date: 2012-05-14 17:32 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3a22b77e755a 7161545: G1: Minor cleanups to the G1 logging Summary: Rename "to-space-overflow" to "to-space-exhausted", Introduce one decimal point in the size format, Add Sum to the aggregate and re-order the entries, Add number of GC workers to the log output Reviewed-by: johnc, jwilhelm ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 78a1b285cda8 Author: mikael Date: 2012-05-15 00:56 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/78a1b285cda8 7158457: division by zero in adaptiveweightedaverage Summary: Add ceiling to AdaptiveWeightedAverage Reviewed-by: ysr, iveresov ! src/share/vm/gc_implementation/shared/gcUtil.cpp ! src/share/vm/gc_implementation/shared/gcUtil.hpp Changeset: 33e366609904 Author: johnc Date: 2012-05-14 21:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/33e366609904 Merge Changeset: 1096fc5a52eb Author: johnc Date: 2012-05-15 09:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1096fc5a52eb 7168294: G1: Some Full GCs incorrectly report GC cause as "No GC" Summary: GC cause was not being set by the VM_G1CollectForAllocation VM operation. Reviewed-by: jmasa, ysr, brutisso ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp Changeset: cdfa5139bd58 Author: brutisso Date: 2012-05-15 22:26 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cdfa5139bd58 7169056: Add gigabyte unit to proper_unit_for_byte_size() and byte_size_in_proper_unit() Reviewed-by: jwilhelm, johnc, dholmes ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 9d679effd28c Author: brutisso Date: 2012-05-15 10:25 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9d679effd28c 7166894: Add gc cause to GC logging for all collectors Reviewed-by: mgerdin, johnc ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_interface/gcCause.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.hpp Changeset: cdeda3fd141e Author: jcoomes Date: 2012-05-18 10:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cdeda3fd141e Merge ! src/share/vm/runtime/arguments.cpp Changeset: 14b0e07ab9a6 Author: amurillo Date: 2012-05-18 14:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/14b0e07ab9a6 Merge Changeset: ff9decc8235d Author: amurillo Date: 2012-05-18 14:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ff9decc8235d Added tag hs24-b11 for changeset 14b0e07ab9a6 ! .hgtags Changeset: 48064e53e997 Author: katleman Date: 2012-05-24 16:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/48064e53e997 Added tag jdk8-b40 for changeset ff9decc8235d ! .hgtags From lana.steuck at oracle.com Sat May 26 02:14:31 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 26 May 2012 02:14:31 +0000 Subject: hg: jdk8/tl/jdk: 39 new changesets Message-ID: <20120526022105.9185D4753C@hg.openjdk.java.net> Changeset: c2d9166f3284 Author: ihse Date: 2012-05-11 08:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c2d9166f3284 7168208: Change use of @ in one sed command involving paths to different character Reviewed-by: ohair ! make/common/Release.gmk Changeset: 8d665b69ebf1 Author: mfang Date: 2012-05-15 11:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8d665b69ebf1 7157855: jvisualvm.1 not included in binaries Reviewed-by: katleman, thurka ! make/common/Release.gmk Changeset: b6f529117521 Author: katleman Date: 2012-05-16 22:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b6f529117521 Merge Changeset: 47cd90bf0f66 Author: katleman Date: 2012-05-17 06:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/47cd90bf0f66 Added tag jdk8-b39 for changeset b6f529117521 ! .hgtags Changeset: 7c4eed4b6c19 Author: bae Date: 2012-05-21 14:04 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7c4eed4b6c19 7124400: [macosx] CGraphicsDevice.getConfigurations() returns reference to member (does not copy configs) Reviewed-by: anthony, kizune ! src/macosx/classes/sun/awt/CGraphicsDevice.java ! test/java/awt/GraphicsDevice/CloneConfigsTest.java Changeset: 416b3a498e71 Author: bae Date: 2012-05-21 14:53 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/416b3a498e71 7154088: [macosx] Regression: Component.createImage do not inherits component attributes Reviewed-by: art, kizune ! src/macosx/classes/sun/lwawt/LWComponentPeer.java Changeset: 1b90a0113359 Author: lana Date: 2012-05-21 11:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1b90a0113359 Merge Changeset: c31eeeda3ed1 Author: serb Date: 2012-05-03 18:29 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c31eeeda3ed1 7160623: [macosx] Editable TextArea/TextField are blocking GUI applications from exit Reviewed-by: anthony, art ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWTextComponentPeer.java Changeset: a420895ee2c3 Author: leonidr Date: 2012-05-03 19:22 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a420895ee2c3 7124376: [macosx] Modal dialog lost focus Reviewed-by: anthony ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/PlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/awt/AWTWindow.h ! src/macosx/native/sun/awt/AWTWindow.m Changeset: 95c8b63a3c47 Author: kizune Date: 2012-05-03 21:54 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/95c8b63a3c47 7148289: [macosx] Deadlock in sun.lwawt.macosx.CWrapper$NSScreen.visibleFrame Reviewed-by: leonidr ! src/macosx/classes/sun/lwawt/macosx/CToolkitThreadBlockedHandler.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/macosx/native/sun/awt/LWCToolkit.m Changeset: a714e2e2b257 Author: alexsch Date: 2012-05-04 13:15 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a714e2e2b257 7024963: Notepad demo: remove non-translatable resources from Notepad.properties file Reviewed-by: rupashka ! src/share/demo/jfc/Notepad/Notepad.java ! src/share/demo/jfc/Notepad/resources/Notepad.properties + src/share/demo/jfc/Notepad/resources/system.properties Changeset: 4cc873e28c78 Author: bagiras Date: 2012-05-04 18:42 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4cc873e28c78 7146237: closed/java/awt/Focus/SetFocusTraversalKeysTest/SetFocusTraversalTest.html failed since 1.8.0b19 Reviewed-by: art, anthony ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/KeyboardFocusManager.java ! src/share/classes/javax/swing/JComponent.java Changeset: 0feee4541f67 Author: serb Date: 2012-05-04 21:25 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0feee4541f67 7147055: [macosx] Cursors are changing over a blocked window; also blinking Reviewed-by: art, kizune ! src/macosx/classes/sun/lwawt/LWCursorManager.java Changeset: 912e666b4e1d Author: serb Date: 2012-05-10 20:05 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/912e666b4e1d 7080109: Dialog.show() lacks doPrivileged() to access system event queue Reviewed-by: art, anthony ! src/share/classes/java/awt/Dialog.java + test/java/awt/Dialog/ModalDialogPermission/ModalDialogPermission.java + test/java/awt/Dialog/ModalDialogPermission/java.policy Changeset: 18842bb6676a Author: lana Date: 2012-05-10 11:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/18842bb6676a Merge - src/macosx/bin/amd64/jvm.cfg - src/share/classes/sun/security/action/LoadLibraryAction.java - test/tools/pack200/dyn.jar - test/tools/pack200/pack200-verifier/src/xmlkit/ClassSyntax.java - test/tools/pack200/pack200-verifier/src/xmlkit/ClassWriter.java - test/tools/pack200/pack200-verifier/src/xmlkit/InstructionAssembler.java - test/tools/pack200/pack200-verifier/src/xmlkit/InstructionSyntax.java Changeset: 4f39a13e74c6 Author: anthony Date: 2012-05-11 16:11 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4f39a13e74c6 7166437: [macosx] Support for Window.Type.UTILITY on the Mac Summary: Apply the native UTILITY style for UTILITY Java windows Reviewed-by: art ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java Changeset: 689c0cd214e8 Author: anthony Date: 2012-05-11 20:37 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/689c0cd214e8 7149062: [macosx] dock menu don't show available frames Summary: Inherit from either NSWindow for normal windows or NSPanel for utility windows Reviewed-by: skovatch, swingler ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/awt/AWTWindow.h ! src/macosx/native/sun/awt/AWTWindow.m Changeset: 3b8635e357e9 Author: alexsch Date: 2012-05-12 12:01 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3b8635e357e9 7024965: Stylepad demo: remove non-translatable resources from Stylepad.properties file Reviewed-by: alexp ! src/share/demo/jfc/Notepad/Notepad.java + src/share/demo/jfc/Notepad/resources/NotepadSystem.properties - src/share/demo/jfc/Notepad/resources/system.properties Changeset: cc8d1cc533bf Author: alexp Date: 2012-05-12 17:46 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cc8d1cc533bf 7149005: [macosx] Java Control Panel's UI controls are distorted when draging scroll bar. Reviewed-by: serb ! src/macosx/classes/com/apple/laf/AquaButtonLabeledUI.java Changeset: 69301efaac91 Author: ant Date: 2012-05-12 18:50 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/69301efaac91 7110683: Issues with some KeyboardFocusManager method Reviewed-by: ahgross ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/DefaultKeyboardFocusManager.java ! src/share/classes/java/awt/KeyboardFocusManager.java ! src/share/classes/java/awt/Window.java Changeset: 28ec5b811aa2 Author: dcherepanov Date: 2012-05-15 15:04 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/28ec5b811aa2 7168550: [macosx] duplicate OGL context state changes related to vertex cache Reviewed-by: bae, swingler ! src/macosx/native/sun/java2d/opengl/CGLSurfaceData.m ! src/share/native/sun/java2d/opengl/OGLContext.h ! src/share/native/sun/java2d/opengl/OGLTextRenderer.c ! src/share/native/sun/java2d/opengl/OGLVertexCache.c ! src/share/native/sun/java2d/opengl/OGLVertexCache.h Changeset: cad0bb1a9bdb Author: dcherepanov Date: 2012-05-16 13:15 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cad0bb1a9bdb 7124337: [macosx] FileDialog fails to select multiple files Reviewed-by: anthony, swingler ! src/macosx/classes/sun/lwawt/macosx/CFileDialog.java ! src/macosx/native/sun/awt/CFileDialog.h ! src/macosx/native/sun/awt/CFileDialog.m ! src/share/classes/java/awt/FileDialog.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/solaris/classes/sun/awt/X11/GtkFileDialogPeer.java ! src/solaris/classes/sun/awt/X11/XFileDialogPeer.java ! src/windows/classes/sun/awt/windows/WFileDialogPeer.java Changeset: 7c0b390ab5f9 Author: anthony Date: 2012-05-16 14:28 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7c0b390ab5f9 7168851: [macosx] Netbeans crashes in CImage.nativeCreateNSImageFromArray Summary: Eliminate unnecessary -release call Reviewed-by: dcherepanov ! src/macosx/native/sun/awt/CImage.m Changeset: 3c819d638e36 Author: alexsch Date: 2012-05-16 16:27 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3c819d638e36 7169226: NLS: Please change the mnemonic assignment system for windows and motif properties Reviewed-by: rupashka ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_de.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_es.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_fr.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_it.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_ja.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_ko.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_pt_BR.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_sv.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_zh_CN.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_zh_TW.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_de.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_es.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_fr.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_it.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_ja.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_ko.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_pt_BR.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_sv.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_CN.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_TW.properties Changeset: 19edcc438203 Author: alexsch Date: 2012-05-16 18:11 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/19edcc438203 7158928: [macosx] NLS: Please change the mnemonic assignment system Reviewed-by: rupashka, serb ! make/com/apple/osxui/Makefile ! make/common/internal/Resources.gmk ! src/macosx/classes/com/apple/laf/AquaLookAndFeel.java ! src/macosx/classes/com/apple/laf/resources/aqua.properties Changeset: 731ee59c6ba2 Author: alexsch Date: 2012-05-17 14:27 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/731ee59c6ba2 7148281: [macosx] JTabbedPane tabs with HTML text do not render correctly Reviewed-by: kizune ! src/macosx/classes/com/apple/laf/AquaTabbedPaneUI.java Changeset: f9217bd87199 Author: rupashka Date: 2012-05-17 15:41 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f9217bd87199 7166322: closed/javax/swing/text/html/HTMLEditorKit/4242228/bug4242228.java failed since 1.8.0b36 Reviewed-by: alexsch + test/javax/swing/text/html/HTMLEditorKit/4242228/bug4242228.java Changeset: c00d6508afce Author: ant Date: 2012-05-17 21:27 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c00d6508afce 7142565: [macosx] Many special keys processed twice in text fields Summary: forward port from 7u4 Reviewed-by: anthony ! src/macosx/native/sun/awt/AWTView.m Changeset: 17c5e1a12965 Author: ant Date: 2012-05-17 21:31 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/17c5e1a12965 7154072: [macosx] swallowing key events Summary: forward posrt from 7u4 Reviewed-by: anthony ! src/macosx/native/sun/awt/AWTView.m Changeset: ef77fa799b34 Author: ant Date: 2012-05-17 21:48 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ef77fa799b34 7125044: [macosx] Test failure because Component.transferFocus() works differently in applet and application. Summary: forward port from 7u4 Reviewed-by: art ! src/share/classes/java/awt/Dialog.java ! src/share/classes/java/awt/Frame.java ! src/share/classes/java/awt/Window.java ! src/share/classes/javax/swing/JApplet.java ! src/share/classes/javax/swing/JDialog.java ! src/share/classes/javax/swing/JFrame.java ! src/share/classes/javax/swing/JInternalFrame.java ! src/share/classes/javax/swing/JWindow.java ! src/share/classes/javax/swing/UIManager.java ! src/share/classes/sun/awt/SunToolkit.java + test/java/awt/Focus/FocusTraversalPolicy/InitialFTP.java + test/java/awt/Focus/FocusTraversalPolicy/InitialFTP_AWT.java + test/java/awt/Focus/FocusTraversalPolicy/InitialFTP_Swing.java + test/java/awt/event/KeyEvent/SwallowKeyEvents/SwallowKeyEvents.java Changeset: 5976b5848554 Author: ant Date: 2012-05-17 22:10 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5976b5848554 7145768: [macosx] Regression: failure in b11 of ModalDialogInFocusEventTest Summary: forward port from 7u4 Reviewed-by: art ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java Changeset: 1d75ff45586e Author: ant Date: 2012-05-17 22:21 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1d75ff45586e 7145827: [macosx] JCK failure in b11: FocusableWindow3 Summary: forward posrt from 7u4 Reviewed-by: art ! src/macosx/classes/sun/lwawt/LWWindowPeer.java Changeset: 2eca75e0a063 Author: dcherepanov Date: 2012-05-18 19:39 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2eca75e0a063 7156191: [macosx] Can't type into applet demos in Pivot Reviewed-by: art ! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java Changeset: 1ee12bca4823 Author: rupashka Date: 2012-05-21 18:55 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1ee12bca4823 7168144: No appropriate CCC request for changes introduced by 7154030 Reviewed-by: alexsch ! src/share/classes/javax/swing/JComponent.java Changeset: 967b38bfd5c1 Author: ant Date: 2012-05-22 01:12 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/967b38bfd5c1 7170427: setGlobalCurrentFocusCycleRoot unexpectedly throws SecurityException Reviewed-by: art ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/KeyboardFocusManager.java Changeset: 5b2095d7a60b Author: lana Date: 2012-05-21 11:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5b2095d7a60b Merge ! src/macosx/classes/sun/lwawt/LWComponentPeer.java Changeset: b88fc3359dc7 Author: lana Date: 2012-05-21 11:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b88fc3359dc7 Merge Changeset: 7def50698e78 Author: katleman Date: 2012-05-24 16:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7def50698e78 Added tag jdk8-b40 for changeset b88fc3359dc7 ! .hgtags Changeset: 7abdd3cb14ed Author: lana Date: 2012-05-25 16:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7abdd3cb14ed Merge From dl at cs.oswego.edu Sat May 26 11:29:25 2012 From: dl at cs.oswego.edu (Doug Lea) Date: Sat, 26 May 2012 07:29:25 -0400 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps In-Reply-To: <94E7336B-91D6-4191-84EA-C9B668B0D172@oracle.com> References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> <94E7336B-91D6-4191-84EA-C9B668B0D172@oracle.com> Message-ID: <4FC0BE95.2090406@cs.oswego.edu> On 05/24/12 15:34, Mike Duigou wrote: > Hello All; > > I have updated the webrevs for alternative hashing for String > > [2] althashing "8" webrev : http://cr.openjdk.java.net/~mduigou/althashing8/9/webrev/ > Not that it matters at all since they will be changed anyway for JDK8 CHM, but all of the ConcurrentHashMap diffs of (old) int h = hash(key.hashCode()); could instead be changed to int h = (k instanceof String)? k.hash32() ^ hashSeed : hash(k.hashCode()); without changing hash() method. Which as Remi mentioned, is likely to have more benefit than you might expect vs offloading mechanics into revised version of hash(), in part by unburying a megamorphic call and nullcheck by one level. (This is why it was done this way in the first place.) Perhaps this applies elsewhere. (Sometime this summer, I hope to write up something on the various "little" coding issues that may be applicable for improving performance of library code. As people mentioned wrt the similar private accessor case, most of these issues are not interesting/useful for application code, but there's no reason not to address them inside heavily used core libraries. The effects are difficult to measure in any small set of tests using these library components, so usually the best course of action is to avoid known potential performance issues.) -Doug From Lance.Andersen at oracle.com Sat May 26 13:33:40 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Sat, 26 May 2012 09:33:40 -0400 Subject: Review request for CR 171917 CachedRowSetImpl.populate does not handle map properly In-Reply-To: References: Message-ID: <73689F85-1321-4642-9F0B-75598029AD00@oracle.com> Here is the revised change with David's suggestion. All tests continue to pass new-host-4:rowset lanceandersen$ !hg hg diff CachedRowSetImpl.java diff -r 4580652d9828 src/share/classes/com/sun/rowset/CachedRowSetImpl.java --- a/src/share/classes/com/sun/rowset/CachedRowSetImpl.java Fri May 04 16:00:47 2012 -0400 +++ b/src/share/classes/com/sun/rowset/CachedRowSetImpl.java Sat May 26 08:43:15 2012 -0400 @@ -659,7 +659,7 @@ * us work with drivers that do not support * getObject with a map in fairly sensible way */ - if (map == null) { + if (map == null || map.isEmpty()) { obj = data.getObject(i); } else { obj = data.getObject(i, map); Best Lance On May 25, 2012, at 7:35 PM, David Schlosnagle wrote: > On Fri, May 25, 2012 at 3:50 PM, Lance Andersen - Oracle > wrote: >> The populate() method needs to check for a size of 0 for the map in case a webrowset xml file has an empty map tag, which would result in calling setobject specifying a map and not all databases/drivers support this. >> >> simple 1 line change: >> >> hg diff CachedRowSetImpl.java >> diff -r 4580652d9828 src/share/classes/com/sun/rowset/CachedRowSetImpl.java >> --- a/src/share/classes/com/sun/rowset/CachedRowSetImpl.java Fri May 04 16:00:47 2012 -0400 >> +++ b/src/share/classes/com/sun/rowset/CachedRowSetImpl.java Fri May 25 15:45:29 2012 -0400 >> @@ -659,7 +659,7 @@ >> * us work with drivers that do not support >> * getObject with a map in fairly sensible way >> */ >> - if (map == null) { >> + if (map == null || map.size() == 0) { > > Lance, > > Is there any reason not to use Map.isEmpty() which would be useful if > the Map has an expensive size() method? > > - if (map == null) { > + if (map == null || map.isEmpty()) { > > Thanks, > Dave Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From Ulf.Zibis at gmx.de Sat May 26 15:43:51 2012 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 26 May 2012 17:43:51 +0200 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps In-Reply-To: <94E7336B-91D6-4191-84EA-C9B668B0D172@oracle.com> References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> <94E7336B-91D6-4191-84EA-C9B668B0D172@oracle.com> Message-ID: <4FC0FA37.3020606@gmx.de> Am 24.05.2012 21:34, schrieb Mike Duigou: > Hello All; > > I have updated the webrevs for alternative hashing for String with feedback from Remi, Doug, Ulf and internal reviewers. > > Additional feedback is welcome. Javadoc of String.hash32(): To where refers {@inheritDoc} ? I think, the javadoc should mention the term 'Murmur hash' and include a web link to the original author. And additionally IMO we should rename hash32() to something like murmurHash32(). But I still think, we should implement a more general approach according my last post. Correction: the variable customHash should be transient. Enhancement: again more general for all CharSequence types: public class MurmurHashMap extends HashMap {...} Additionally it would be interesting to add a customHash field to plain Java arrays. This would allow a real hash over the array values, which is not existent now. -Ulf From mike.duigou at oracle.com Sat May 26 18:15:25 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Sat, 26 May 2012 11:15:25 -0700 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps In-Reply-To: <4FC0FA37.3020606@gmx.de> References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> <94E7336B-91D6-4191-84EA-C9B668B0D172@oracle.com> <4FC0FA37.3020606@gmx.de> Message-ID: On May 26 2012, at 08:43 , Ulf Zibis wrote: > Am 24.05.2012 21:34, schrieb Mike Duigou: >> Hello All; >> >> I have updated the webrevs for alternative hashing for String with feedback from Remi, Doug, Ulf and internal reviewers. >> >> Additional feedback is welcome. > > Javadoc of String.hash32(): > To where refers {@inheritDoc} ? To the new interface java.lang.Hashable32.hash32() > I think, the javadoc should mention the term 'Murmur hash' and include a web link to the original author. Explicitly NO. This new hashing interface will not document it's algorithm so that unlike String.hashCode() we can change it in the future if we need to. > And additionally IMO we should rename hash32() to something like murmurHash32(). No, for the previous reason. > But I still think, we should implement a more general approach according my last post. It seems to be overkill to me and of very limited value. New Map implementations could be created by third parties if this is useful to some users. Mike From forax at univ-mlv.fr Sat May 26 18:54:43 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sat, 26 May 2012 20:54:43 +0200 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps In-Reply-To: References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> <94E7336B-91D6-4191-84EA-C9B668B0D172@oracle.com> <4FC0FA37.3020606@gmx.de> Message-ID: <4FC126F3.2080306@univ-mlv.fr> On 05/26/2012 08:15 PM, Mike Duigou wrote: > On May 26 2012, at 08:43 , Ulf Zibis wrote: > >> Am 24.05.2012 21:34, schrieb Mike Duigou: >>> Hello All; >>> >>> I have updated the webrevs for alternative hashing for String with feedback from Remi, Doug, Ulf and internal reviewers. >>> >>> Additional feedback is welcome. >> Javadoc of String.hash32(): > >> To where refers {@inheritDoc} ? > To the new interface java.lang.Hashable32.hash32() What is the point of having an interface now, that all checks test String explicitly ? R?mi From Ulf.Zibis at gmx.de Sat May 26 19:00:54 2012 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 26 May 2012 21:00:54 +0200 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps In-Reply-To: References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> <94E7336B-91D6-4191-84EA-C9B668B0D172@oracle.com> <4FC0FA37.3020606@gmx.de> Message-ID: <4FC12866.10708@gmx.de> Am 26.05.2012 20:15, schrieb Mike Duigou: > On May 26 2012, at 08:43 , Ulf Zibis wrote: >> To where refers {@inheritDoc} ? > To the new interface java.lang.Hashable32.hash32() Hm, but your String class in webrev 8/9 doesn't implement it. >> I think, the javadoc should mention the term 'Murmur hash' and include a web link to the original author. > Explicitly NO. This new hashing interface will not document it's algorithm so that unlike String.hashCode() we can change it in the future if we need to. I don't mean the interface, I mean the class. As HashMap doc describes it's internal structure in contrast to e.g. TreeMap, String.hash32() doc could mention it's internal implementation, and when to prefer it over hashCode(). If the inner algorithm becomes changed, the doc could be changed either. >> And additionally IMO we should rename hash32() to something like murmurHash32(). > No, for the previous reason. Here I'm with you. >> But I still think, we should implement a more general approach according my last post. > It seems to be overkill to me and of very limited value. New Map implementations could be created by third parties if this is useful to some users. The big problem for all later implementations would be, that they can't profit from an internal cache field in String, if it is not publicly accessible, as class String can't be subclassed, same for Java arrays. Additionally, if HashMap.hash() can't be overridden, one should duplicate the whole code of HashMap for an alternative implementation. -Ulf From Ulf.Zibis at gmx.de Sat May 26 19:05:59 2012 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 26 May 2012 21:05:59 +0200 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps In-Reply-To: <4FC12866.10708@gmx.de> References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> <94E7336B-91D6-4191-84EA-C9B668B0D172@oracle.com> <4FC0FA37.3020606@gmx.de> <4FC12866.10708@gmx.de> Message-ID: <4FC12997.6090605@gmx.de> Am 26.05.2012 21:00, schrieb Ulf Zibis: >>> But I still think, we should implement a more general approach according my last post. >> It seems to be overkill to me and of very limited value. New Map implementations could be created >> by third parties if this is useful to some users. > The big problem for all later implementations would be, that they can't profit from an internal > cache field in String, if it is not publicly accessible, as class String can't be subclassed, same > for Java arrays. > Additionally, if HashMap.hash() can't be overridden, one should duplicate the whole code of > HashMap for an alternative implementation. Additionally we would get rid from the instanceof problem by my approach. > > -Ulf > > > From dbelfer at gmail.com Sat May 26 19:30:59 2012 From: dbelfer at gmail.com (Diego Belfer) Date: Sat, 26 May 2012 16:30:59 -0300 Subject: [PATCH] 7164256 : EnumMap.clone doesn't clear the entrySet field, keeping a reference to the original Map Message-ID: Hello, I have reported a bug in the implementation of the clone method of the EnumMap class. The instance field entrySet is not being cleared, so the entrySet field of the new instance references to the original EnumMap. I am providing a simple patch for review. It adds one line to the clone method that sets the entrySet field to null. This is my first contribution to the OpenJDK, so let me know if I am missing some step of the process. Thanks, Diego Belfer [muralx] From aph at redhat.com Mon May 28 07:13:23 2012 From: aph at redhat.com (Andrew Haley) Date: Mon, 28 May 2012 08:13:23 +0100 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps In-Reply-To: <4FC0BE95.2090406@cs.oswego.edu> References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> <94E7336B-91D6-4191-84EA-C9B668B0D172@oracle.com> <4FC0BE95.2090406@cs.oswego.edu> Message-ID: <4FC32593.2040300@redhat.com> On 05/26/2012 12:29 PM, Doug Lea wrote: > (Sometime this summer, I hope to write up something on > the various "little" coding issues that may be applicable > for improving performance of library code. As people > mentioned wrt the similar private accessor case, > most of these issues are not interesting/useful for > application code, but there's no reason not to address > them inside heavily used core libraries. The effects > are difficult to measure in any small set of tests using > these library components, so usually the best course of action > is to avoid known potential performance issues.) The thing that bothers me about this is that such optimizations may be rather VM-specific, sometimes to the extent of depending on how HotSpot generates code for a particular case. Given that the OpenJDK libraries are now used more widely, and hopefully this will increase, what shall we do? Andrew. From littlee at linux.vnet.ibm.com Mon May 28 07:36:09 2012 From: littlee at linux.vnet.ibm.com (Charles Lee) Date: Mon, 28 May 2012 15:36:09 +0800 Subject: [doc]Small modification on the WeakHashMap doc In-Reply-To: <4FA74547.7040901@oracle.com> References: <4FA22B25.2090201@linux.vnet.ibm.com> <4FA73BDE.1040309@linux.vnet.ibm.com> <4FA74547.7040901@oracle.com> Message-ID: <4FC32AE9.2060703@linux.vnet.ibm.com> Hi devs, I'd like to propose a new minor change for the WeakHashMap doc, which I got it from David :-) Would anyone got some time to take a look this fix[1]? 1. http://cr.openjdk.java.net/~littlee/7166055/webrev.01/ On 05/07/2012 11:45 AM, David Holmes wrote: > Hi Charles, > > On 7/05/2012 1:05 PM, Charles Lee wrote: >> Does anyone interested in this issue? > > Interest and time are two different things :) > > A shorter form would be: > > "If the values in the map do not rely on the map holding strong > references to them, then one way to deal with this is ... > > David > >> On 05/03/2012 02:52 PM, Charles Lee wrote: >>> Hi guys, >>> >>> In the Implementation notes of WeakHashMap[1], says: >>> >>> /One way to deal with this is to wrap values themselves within >>> WeakReferences before inserting, as in: m.put(key, new >>> WeakReference(value)), and then unwrapping upon each get./ >>> >>> However, it is not concise and a little misleading. Because the value >>> in the WeakReference can be GC'd if there are no strong reference to >>> it. This behaviour surprises some customers. >>> How about add a statement like [2]: >>> >>> /However, as the use of WeakReference in this manner will not prevent >>> value objects from being GC'd, this approach is only useful when >>> entries in the map are not relied upon for keeping the underlying >>> value objects "live"./ >>> >>> >>> >>> >>> [1]: >>> http://docs.oracle.com/javase/7/docs/api/java/util/WeakHashMap.html >>> [2]: http://cr.openjdk.java.net/~littlee/7166055/webrev.00/ >>> >>> >> >> > -- Yours Charles From forax at univ-mlv.fr Mon May 28 08:36:09 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 28 May 2012 10:36:09 +0200 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps In-Reply-To: <4FC32593.2040300@redhat.com> References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> <94E7336B-91D6-4191-84EA-C9B668B0D172@oracle.com> <4FC0BE95.2090406@cs.oswego.edu> <4FC32593.2040300@redhat.com> Message-ID: <4FC338F9.1040105@univ-mlv.fr> On 05/28/2012 09:13 AM, Andrew Haley wrote: > On 05/26/2012 12:29 PM, Doug Lea wrote: >> (Sometime this summer, I hope to write up something on >> the various "little" coding issues that may be applicable >> for improving performance of library code. As people >> mentioned wrt the similar private accessor case, >> most of these issues are not interesting/useful for >> application code, but there's no reason not to address >> them inside heavily used core libraries. The effects >> are difficult to measure in any small set of tests using >> these library components, so usually the best course of action >> is to avoid known potential performance issues.) > The thing that bothers me about this is that such optimizations may be > rather VM-specific, sometimes to the extent of depending on how > HotSpot generates code for a particular case. Given that the OpenJDK > libraries are now used more widely, and hopefully this will increase, > what shall we do? > > Andrew. Usually it's more to avoid common pitfalls than trying to trigger a specific VM optimization. R?mi From Ulf.Zibis at gmx.de Mon May 28 14:50:22 2012 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 28 May 2012 16:50:22 +0200 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps In-Reply-To: <4FC32593.2040300@redhat.com> References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> <94E7336B-91D6-4191-84EA-C9B668B0D172@oracle.com> <4FC0BE95.2090406@cs.oswego.edu> <4FC32593.2040300@redhat.com> Message-ID: <4FC390AE.3030202@gmx.de> Am 28.05.2012 09:13, schrieb Andrew Haley: > On 05/26/2012 12:29 PM, Doug Lea wrote: >> (Sometime this summer, I hope to write up something on >> the various "little" coding issues that may be applicable >> for improving performance of library code. As people >> mentioned wrt the similar private accessor case, >> most of these issues are not interesting/useful for >> application code, but there's no reason not to address >> them inside heavily used core libraries. The effects >> are difficult to measure in any small set of tests using >> these library components, so usually the best course of action >> is to avoid known potential performance issues.) > The thing that bothers me about this is that such optimizations may be > rather VM-specific, sometimes to the extent of depending on how > HotSpot generates code for a particular case. Given that the OpenJDK > libraries are now used more widely, and hopefully this will increase, > what shall we do? One more justification to not set this alternative hash code fixed in class String. (Remember my alternative more general approach some posts ago) -Ulf From dbelfer at gmail.com Mon May 28 19:31:20 2012 From: dbelfer at gmail.com (Diego Belfer) Date: Mon, 28 May 2012 16:31:20 -0300 Subject: [PATCH] 7164256 : EnumMap.clone doesn't clear the entrySet field, keeping a reference to the original Map In-Reply-To: References: Message-ID: Hi, The patch seems to have been removed by the mailer. I am adding it inline. Best, Diego Belfer [muralx] # HG changeset patch # User muralx # Date 1338059940 10800 # Node ID 05cb9ae575a6fb4262d46dcd4d4c56c23594cdcb # Parent 9b8c96f96a0f9a5801b55530a387fefbe50482a3 PATCH 7164256 : EnumMap.clone does not clear the instance field entrySet diff --git a/src/share/classes/java/util/EnumMap.java b/src/share/classes/java/util/EnumMap.java --- a/src/share/classes/java/util/EnumMap.java +++ b/src/share/classes/java/util/EnumMap.java @@ -721,6 +721,7 @@ throw new AssertionError(); } result.vals = result.vals.clone(); + result.entrySet = null; return result; } ---------- Forwarded message ---------- From: Diego Belfer Date: Sat, May 26, 2012 at 4:30 PM Subject: [PATCH] 7164256 : EnumMap.clone doesn't clear the entrySet field, keeping a reference to the original Map To: core-libs-dev at openjdk.java.net Hello, I have reported a bug in the implementation of the clone method of the EnumMap class. The instance field entrySet is not being cleared, so the entrySet field of the new instance references to the original EnumMap. I am providing a simple patch for review. It adds one line to the clone method that sets the entrySet field to null. This is my first contribution to the OpenJDK, so let me know if I am missing some step of the process. Thanks, Diego Belfer [muralx] From Alan.Bateman at oracle.com Mon May 28 20:02:59 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 28 May 2012 21:02:59 +0100 Subject: [PATCH] 7164256 : EnumMap.clone doesn't clear the entrySet field, keeping a reference to the original Map In-Reply-To: References: Message-ID: <4FC3D9F3.4040602@oracle.com> On 28/05/2012 20:31, Diego Belfer wrote: > Hi, > > The patch seems to have been removed by the mailer. I am adding it inline. > > Best, > Diego Belfer > [muralx] > Thanks for the bug report and patch. I think mailman is configured to drop certain types of attachments which would explain why it was missing from your first mail. As you are contributing a fix then I would suggesting going through this page first: http://openjdk.java.net/contribute/ This explains how to be a contributor. Also note in section 3 that a unit or regression tests should be included where practical. I realize this will be more work than the fix itself but that is often the case. You can find some examples of tests for this area in jdk/test/java/util/EnumMap. -Alan. From littlee at linux.vnet.ibm.com Tue May 29 01:43:59 2012 From: littlee at linux.vnet.ibm.com (littlee at linux.vnet.ibm.com) Date: Tue, 29 May 2012 01:43:59 +0000 Subject: hg: jdk8/tl/jdk: 7172177: test/java/util/TimeZone/DstTzTest.java failing on all platforms Message-ID: <20120529014409.398D14757F@hg.openjdk.java.net> Changeset: 60033ab79213 Author: littlee Date: 2012-05-29 09:42 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/60033ab79213 7172177: test/java/util/TimeZone/DstTzTest.java failing on all platforms Reviewed-by: alanb, okutsu - test/java/util/TimeZone/DstTzTest.java From dbelfer at gmail.com Tue May 29 02:37:58 2012 From: dbelfer at gmail.com (Diego Belfer) Date: Mon, 28 May 2012 23:37:58 -0300 Subject: [PATCH] 7164256 : EnumMap.clone doesn't clear the entrySet field, keeping a reference to the original Map In-Reply-To: <4FC3D9F3.4040602@oracle.com> References: <4FC3D9F3.4040602@oracle.com> Message-ID: Hi Alan, Thanks for your reply. I am attaching a new patch and it contains the test case now. I have read the contents of the link you sent me and I believe the OCA signature is the only thing that is pending. I will send a signed copy of the OCA tomorrow so my change can be applied to the repository once it gets approved. Let me know if I'm missing something. Best, Diego # HG changeset patch # User muralx # Date 1338257674 10800 # Node ID f61b94fd7aca738353177fcf3cc3972ddf36cf36 # Parent 9b8c96f96a0f9a5801b55530a387fefbe50482a3 PATCH 7164256 : EnumMap.clone does not clear the instance field entrySet diff --git a/src/share/classes/java/util/EnumMap.java b/src/share/classes/java/util/EnumMap.java --- a/src/share/classes/java/util/EnumMap.java +++ b/src/share/classes/java/util/EnumMap.java @@ -721,6 +721,7 @@ throw new AssertionError(); } result.vals = result.vals.clone(); + result.entrySet = null; return result; } diff --git a/test/java/util/EnumMap/ProperEntrySetOnClone.java b/test/java/util/EnumMap/ProperEntrySetOnClone.java new file mode 100644 --- /dev/null +++ b/test/java/util/EnumMap/ProperEntrySetOnClone.java @@ -0,0 +1,58 @@ +/* + * Copyright (c) 2012, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/* + * @test + * @bug 7164256 + * @summary EnumMap.entrySet() returns an entrySet referencing to the cloned instance + * @author Diego Belfer + */ + +import java.util.EnumMap; + +public class ProperEntrySetOnClone { + public enum Test { + ONE, TWO + } + + public static void main(String[] args) { + EnumMap map1 = new EnumMap(Test.class); + map1.put(Test.ONE, "1"); + map1.put(Test.TWO, "2"); + + // We need to force creation of the map1.entrySet + int size = map1.entrySet().size(); + if (size != 2) { + throw new RuntimeException( + "Invalid size in original map. Expected: 2 was: " + size); + } + + EnumMap map2 = map1.clone(); + map2.remove(Test.ONE); + size = map2.entrySet().size(); + if (size != 1) { + throw new RuntimeException( + "Invalid size in cloned instance. Expected: 1 was: " + size); + } + } +} On Mon, May 28, 2012 at 5:02 PM, Alan Bateman wrote: > On 28/05/2012 20:31, Diego Belfer wrote: > >> Hi, >> >> The patch seems to have been removed by the mailer. I am adding it inline. >> >> Best, >> Diego Belfer >> [muralx] >> >> Thanks for the bug report and patch. I think mailman is configured to > drop certain types of attachments which would explain why it was missing > from your first mail. > > As you are contributing a fix then I would suggesting going through this > page first: > > http://openjdk.java.net/**contribute/ > > This explains how to be a contributor. Also note in section 3 that a unit > or regression tests should be included where practical. I realize this will > be more work than the fix itself but that is often the case. You can find > some examples of tests for this area in jdk/test/java/util/EnumMap. > > -Alan. > > -------------- next part -------------- # HG changeset patch # User muralx # Date 1338257674 10800 # Node ID f61b94fd7aca738353177fcf3cc3972ddf36cf36 # Parent 9b8c96f96a0f9a5801b55530a387fefbe50482a3 PATCH 7164256 : EnumMap.clone does not clear the instance field entrySet diff --git a/src/share/classes/java/util/EnumMap.java b/src/share/classes/java/util/EnumMap.java --- a/src/share/classes/java/util/EnumMap.java +++ b/src/share/classes/java/util/EnumMap.java @@ -721,6 +721,7 @@ throw new AssertionError(); } result.vals = result.vals.clone(); + result.entrySet = null; return result; } diff --git a/test/java/util/EnumMap/ProperEntrySetOnClone.java b/test/java/util/EnumMap/ProperEntrySetOnClone.java new file mode 100644 --- /dev/null +++ b/test/java/util/EnumMap/ProperEntrySetOnClone.java @@ -0,0 +1,58 @@ +/* + * Copyright (c) 2012, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/* + * @test + * @bug 7164256 + * @summary EnumMap.entrySet() returns an entrySet referencing to the cloned instance + * @author Diego Belfer + */ + +import java.util.EnumMap; + +public class ProperEntrySetOnClone { + public enum Test { + ONE, TWO + } + + public static void main(String[] args) { + EnumMap map1 = new EnumMap(Test.class); + map1.put(Test.ONE, "1"); + map1.put(Test.TWO, "2"); + + // We need to force creation of the map1.entrySet + int size = map1.entrySet().size(); + if (size != 2) { + throw new RuntimeException( + "Invalid size in original map. Expected: 2 was: " + size); + } + + EnumMap map2 = map1.clone(); + map2.remove(Test.ONE); + size = map2.entrySet().size(); + if (size != 1) { + throw new RuntimeException( + "Invalid size in cloned instance. Expected: 1 was: " + size); + } + } +} From mike.duigou at oracle.com Tue May 29 18:55:12 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 29 May 2012 11:55:12 -0700 Subject: Request for Review : CR#6924259: Remove String.count/String.offset In-Reply-To: <48E4C36B-5014-4EAE-845F-65A6852A3F25@oracle.com> References: <1D5C5BC1-C6E8-4807-9D5B-2530CDEAD479@oracle.com> <4FBF763A.6050202@oracle.com> <4FBF8FC2.1030608@univ-mlv.fr> <48E4C36B-5014-4EAE-845F-65A6852A3F25@oracle.com> Message-ID: <208DA4FB-7A6F-4B46-B855-87052554A3EA@oracle.com> I have posted a new webrev to: > Removing String(int offset, int count, char value[]) will create trouble, >> I've seen several libraries that use it by reflection to avoid to create >> a copy of the array. I think this method should not disappear >> but use Arrays.copyOfRange if the offset is not 0. >> This method should be marked deprecated, and removed in Java 9. > > Restored but deprecated. On further discussion I would like to deprecate this method in the Java 7 implementation and remove this method for Java 8. It is not part of the public API and developers have at least a year to remove it from their applications. Having it be absent from Java 8 pre-release builds will also hopefully provide them a non-ignorable heads-up to replace their usage with the public (char[], int, int) variant. Mike From kurchi.subhra.hazra at oracle.com Tue May 29 20:17:07 2012 From: kurchi.subhra.hazra at oracle.com (kurchi.subhra.hazra at oracle.com) Date: Tue, 29 May 2012 20:17:07 +0000 Subject: hg: jdk8/tl/jdk: 7171591: getDefaultScopeID() in src/solaris/native/java/net/net_util_md.c should return a value Message-ID: <20120529201726.3F0474759D@hg.openjdk.java.net> Changeset: eb441933f6fe Author: khazra Date: 2012-05-29 13:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eb441933f6fe 7171591: getDefaultScopeID() in src/solaris/native/java/net/net_util_md.c should return a value Summary: Use CHECK_NULL_RETURN instead of CHECK_NULL Reviewed-by: alanb ! src/solaris/native/java/net/net_util_md.c From kurchi.subhra.hazra at oracle.com Tue May 29 20:35:57 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Tue, 29 May 2012 13:35:57 -0700 Subject: [7u6] Request for approval: 7170169: (props) System.getProperty("os.name") should return "Windows 8" when run on Windows Message-ID: <4FC5332D.5020506@oracle.com> Requesting approval to commit fix for CR 7170169. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7170169 Webrev: http://cr.openjdk.java.net/~khazra/7170169/7u6/webrev.00/ This had been reviewed by darcy, dholmes, alanb, chegar. [1] This fix has been pushed into jdk8 [2] Thanks, Kurchi [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-May/010233.html [2] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0c3d9050c918 From mike.duigou at oracle.com Tue May 29 21:25:25 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 29 May 2012 14:25:25 -0700 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps In-Reply-To: <4FC3D33E.3060407@cs.oswego.edu> References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> <4FC0354C.4010207@gmx.de> <4FC3D33E.3060407@cs.oswego.edu> Message-ID: <64B6FF09-FF0C-46E9-BAE6-6C9A4CE9F779@oracle.com> On May 28 2012, at 12:34 , Doug Lea wrote: > On 05/25/12 21:43, Ulf Zibis wrote: >> To me it seems, that computing the murmur hash is more expensive, especially on >> short strings, than the old hash algorithm. > > It is definitely slower, but also definitely has better statistical > properties (fewer collisions when used in hash tables). > > In its original (C) context, Murmur hash is often about as fast as other > string hashes, because it operates on 4byte words rather than 1-byte > elements at a time. So even though the per-element cost is much higher, it > takes 1/4 the steps. When done on Java char[]'s though, it can only > process 2 chars at a time. (Plus, we cannot necessarily read 32bitsat a > time because of possible byteswapping.) So it is a struggle to make > it only twice as slow. An intrinsic and/or native version might be added later if it turns out that the Java murmur3 implementation is a performance bottleneck. So far it hasn't been a particular bottleneck. Implementations are also free to change to a different algorithm for performance, security or scalability reasons as they see fit. > This means that any application that hashes strings only once will > be slower than using (old) hashCode. but any application that > uses the (cached) hashes more than a few times will tend to run > faster than old hashCode version because of higher quality hash codes. > A few tests so far confirm this. This was my result as well. Caching makes most of the differences between String.hashCode (legacy algorithm) and String.hash32 (the murmur3 implementation) disappear. I actually tested with a version of hashCode that recalculated the result 2X, 5X and 10X times in a loop to look at the impact of caching. The conclusion was that even a 5X more expensive hashing algorithm was bearable as long as caching was present. There are still many cases where caching can't be present, such as parsing, where all of the items being hashed are new objects with no previously cached hash value. These cases require that we provide a reasonably performing hash algorithm. Murmur3 is slower than the legacy algorithm but not enough slower to cripple overall usage and it's better distribution really shines on larger tables. >> So I think, a developer should have an influence on the hash algorithm to be >> used by a hash map, > > I've had to make a lot of internal adjustments in hash tables to > counteract crummy user hashCode() algorithms over the years, > so I think that the less control, the better :-) I am in agreement with Doug. I've seen checked in code with "return 0;" as the hashCode implementation for classes used as hash keys. One example that clearly didn't understand hashes had a different random number as the hashCode result for each class.... Mike From mike.duigou at oracle.com Tue May 29 23:05:14 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 29 May 2012 16:05:14 -0700 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps In-Reply-To: <4FBFC3AD.5020709@univ-mlv.fr> References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> <94E7336B-91D6-4191-84EA-C9B668B0D172@oracle.com> <4FBFC3AD.5020709@univ-mlv.fr> Message-ID: Another round of updates for Java 7 [1] and Java 8 [2] implementations. This revision incorporates Remi's suggestions and some feedback from Doug Lea regarding applying the per-instance seed to the result of String.hash32() [1] althashing "7" webrev : http://cr.openjdk.java.net/~mduigou/althashing7/10/webrev/ [2] althashing "8" webrev : http://cr.openjdk.java.net/~mduigou/althashing8/10/webrev/ Barring any emergencies this will be integrated to both Java 7 and Java 8 on Wednesday May 30th, 2012. Thanks to all who provided feedback! Mike On May 25 2012, at 10:38 , R?mi Forax wrote: > On 05/24/2012 09:34 PM, Mike Duigou wrote: >> Hello All; >> >> I have updated the webrevs for alternative hashing for String with feedback from Remi, Doug, Ulf and internal reviewers. >> >> Additional feedback is welcome. >> >> Mike >> >> [1] althashing "7" webrev : http://cr.openjdk.java.net/~mduigou/althashing7/9/webrev/ >> [2] althashing "8" webrev : http://cr.openjdk.java.net/~mduigou/althashing8/9/webrev/ > > Hello Mike, > just two small issues. > > In WeakHashMap.hash(), the null check should be done at callsite, It's not even needed at the callsite as it always follows a maskNull call. > the call to hash32() should be directly returned like in HashMap. Fixed. > Is Hashable32 is used anymore ? It's the "source" of the hash32 method that String now implements and hopefully more later. This bit is sort of unfinished in this patch but I would like to leave it in for now. Mike > R?mi > >> >> On May 22 2012, at 22:16 , Mike Duigou wrote: >> >>> Dear OpenJDK CoreLibs community, >>> >>> A significant enhancement to the Java SE hashing-based Map implementations in planned for inclusion in Java SE 7u6. All of the hashing based Map implementations: HashMap, Hashtable, LinkedHashMap, WeakHashMap and ConcurrentHashMap will now use an enhanced hashing algorithm for string keys when the capacity of the hash table has ever grown beyond 512 entries. The enhanced hashing implementation uses the murmur3 hashing algorithm[1] along with random hash seeds and index masks. These enhancements mitigate cases where colliding String hash values could result in a performance bottleneck. >>> >>> In order to provide the greatest opportunity for developers to test compatibility with their applications this change will be incorporated into JDK7u6 build 12 and JDK8 build 39. Both builds are planned for release next week. ***For 7u6 build 12 only, the alternative hashing will be unconditionally enabled (always on).*** The threshold default will be reset to the intended release default (512) for 7u6 build 13. >>> >>> The quick promotion of this change into builds with limited opportunity for public review and the special behaviour for build 12 is intended to make it easier for developers to test their application compatibility. Feedback on the approach, implementation, compatibility and performance is eagerly sought and encouraged both before *and after* this change is incorporated into the OpenJDK repositories. >>> >>> A new system property, jdk.map.althashing.threshold, allows adjustment of the threshold for enabling the enhanced hashing algorithm. If changed from the default value of 512, the enhanced hashing will be invoked any time after map capacity exceeds the value of jdk.map.althashing.threshold. To completely disable the enhanced hashing (not recommended), set jdk.map.althashing.threshold to -1 or a very large number such as 2^31 -1 (Integer.MAX_VALUE). >>> >>> The iteration order of keys, values and entries for hash-based maps where the new algorithm has been invoked will vary for each HashMap instance. While the Java SE Map documentation makes no promises that iteration order of items returned from Maps will be consistent, developers should check if their applications have incorrectly created a dependency on the iteration order of Map entries, keys or values. >>> >>> Webrevs for the Java 7u6 and 8 changes are available for download at [2] and [3] for your review. There are some important differences between the Java 7 and 8 implementations of this enhancement. Most specifically in the Java 8 implementation alternative string hashing is always enabled--no threshold is used for enablement and alternative hashing cannot be disabled. (The Java 8 implementation completely ignores the jdk.map.althashing.threshold system property). The Java 8 implementation is also subject to additional refinement as Java 8 develops. >>> >>> If you have any questions or concerns with this planned enhancement, please use the corelibs development mailing list,, or you may also respond privately to me if you prefer. >>> >>> Thanks, >>> >>> Mike >>> >>> [1] Murmur3 : https://code.google.com/p/smhasher/wiki/MurmurHash3 >>> [2] althashing "7" webrev : http://cr.openjdk.java.net/~mduigou/althashing7/8/webrev/ >>> [3] althashing "8" webrev : http://cr.openjdk.java.net/~mduigou/althashing8/8/webrev/ > From edvard.wendelin at oracle.com Wed May 30 07:27:51 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Wed, 30 May 2012 09:27:51 +0200 Subject: [7u6] Request for approval: 7170169: (props) System.getProperty("os.name") should return "Windows 8" when run on Windows In-Reply-To: <4FC5332D.5020506@oracle.com> References: <4FC5332D.5020506@oracle.com> Message-ID: <4380B2E6-6E81-4E1C-B825-4E11831BA86B@oracle.com> Approved! On May 29, 2012, at 10:35 PM, Kurchi Hazra wrote: > > Requesting approval to commit fix for CR 7170169. > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7170169 > Webrev: http://cr.openjdk.java.net/~khazra/7170169/7u6/webrev.00/ > > This had been reviewed by darcy, dholmes, alanb, chegar. [1] > > This fix has been pushed into jdk8 [2] > > Thanks, > Kurchi > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-May/010233.html > [2] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0c3d9050c918 > > From dl at cs.oswego.edu Wed May 30 13:49:08 2012 From: dl at cs.oswego.edu (Doug Lea) Date: Wed, 30 May 2012 09:49:08 -0400 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps In-Reply-To: <64B6FF09-FF0C-46E9-BAE6-6C9A4CE9F779@oracle.com> References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> <4FC0354C.4010207@gmx.de> <4FC3D33E.3060407@cs.oswego.edu> <64B6FF09-FF0C-46E9-BAE6-6C9A4CE9F779@oracle.com> Message-ID: <4FC62554.90207@cs.oswego.edu> On 05/29/12 17:25, Mike Duigou wrote: > An intrinsic and/or native version might be added later if it turns out that > the Java murmur3 implementation is a performance bottleneck. I don't think that going native will make much difference. The main disadvantages of using Murmur3 for char[]s are that it takes twice as long as for byte[]s (for which it was developed), and that its statistical collision properties when using chars in which the top byte is usually 0 (as is the case) are probably weaker than otherwise. Backing up: There's a history of obsession with these sorts of details in JDK hash table classes. Here's some background. Many small-looking factors can make a big difference in application-level performance, and even more so in some "important" but poorly conceived benchmarks (most notably, the previous version of specJBB). Some of this is due to to the fact that some user and JDK hashCode algorithms (e.g. for class Float) are so poorly distributed that some intervention is required inside the hash table classes to avoid horrible performance. The added wrinkle in the current efforts is to also avoid horrible performance when Strings are based on external inputs that may be crafted to cause collisions. The use of a random seed for String hashing addresses this pretty well. But since this cannot (per the JLS) be done for all uses of String.hashCode(), it opens up further exploration of exactly which random-seeded algorithm to use. This is similar to previous efforts that took the hashCode() as a given, and then looked at: cost(convertHashToIndexAndLoadBin) + sum(i=0, inf, cost(compareElement) * prob >= i collisions)) Here, the main question is how much effort to expend to convert poorly distributed hash codes via techniques that spread bits across a 32bit hash, resolved to an index via a power-of-two mask. Bit-spreading (via those shifts, xors, etc you see in hash classes) gives fewer collisions, but with diminishing returns with more effort, in part because this code occurs at a choke-point: Loading the bin (and key) at the index may entail a cache miss, stalling the processor, so the code leading up to this point is on a critical path. You can model some of this analytically, as deviations from ideal Poisson distribution, where the probability of at least one collision is roughly 1 / (8 * N), where N is number of elements, under default resizing policies and pure random keys. But models don't give you any answer beyond illustrating that the tradeoff between mixing cost and collision rates generally favors cheaper mixing. Beyond that, the best you can do is empirically evaluate particular choices against a wide range of key types and use cases, (There are other non-analytic concerns here as well. For example, the current bit-spreading in class HashMap additionally has the property of bounding cache miss rates during traversal when used for adjacent consecutive integer keys. Yes, this is a weird consideration but was important to some people at the time.) The new String efforts differ in that the hashCode function is up for grabs, and additionally is cacheable. So the costs have both one-time initial hash computation, and recurring (for, say, "U" usages of a key) components. But because we are in control of initial hash, we can ensure that we don't need further bit-spreading. so, for U usages, the cost is: cost(initialHash(key)) + U * sum(i=0, inf, cost(compareElement) * prob >= i collisions)) Back-of-envelope analytic modeling shows that the tradeoffs between initial cost and collision rate depend on both U (usages per key) and N (number of elements). There are too many unknown constants to make any absolute conclusions about choice of algorithm. But plugging in a few sample values shows that the break even point for increasing initial hash cost vs better collision rate is further out than you might expect. For example, guestimating that the murmur code in current patch is twice as expensive as the "DJB" algorithm in String hashCode (which I think is a lower bound) but gives 10% lower collision probability (which I think is upper bound), you'd only choose it if U > c * N, where "c" absorbs a lot of slop but is likely greater than 1. Which indicates that this is probably not the most common use case. (But it is a common case in most benchmarks, that reuse keys a lot to get better time estimates.) So it does seem worth exploring algorithms with different speed/quality tradeoffs. For example, some similar guestimation (and a bit of empirical confirmation) suggests that a good choice might be a random-seeded version of the well-established Jenkins "one-time" algorithm (http://en.wikipedia.org/wiki/Jenkins_hash_function), which is only a little more expensive as DJB but doesn't have as good collision rates as Murmur3. (Although I'm not at all sure it is not as good because of the top-byte-usually-zero issue for Murmur3 on char[]). In fact, it is not clear to me at the moment whether just using random-seeded version of current DJB would be about as good as any other choice. If that were the case, some of the upcoming changes could be further simplified. And could be vastly simplified if it were OK to have a VM switch -UseRandomStringHashSeed. If so, the main impact would be to change one line in String.hashCode. I'm sure the JLS purists out there would not be happy about this though. (BTW, see some related discussions on StackExchange: http://programmers.stackexchange.com/questions/49550/which-hashing-algorithm-is-best-for-uniqueness-and-speed/) There are other, completely different, approaches to dealing with bad user hash codes, such as the use of separate data structures to handle colliding codes. We've rejected them in the past, but I'm trying some out in the in-progress overhaul of ConcurrentHashMap. Aside: I discovered while investigating some of this that explicitly omitting the bit-spreading step for String keys in hash table classes under any of these algorithms works well if you are going to explicitly do a (key instanceof String) check anyway. (This partially accounts for results I noted in previous mail about impact of Murmur3.) While it doesn't hurt to further bit-spread any of these String hash codes, it doesn't help, and since the test is there anyway, it is better to also use it to skip spread step. It may be is worth adding this check even if not otherwise needed because it helps compilers resolve the hashCode call along this path, and Strings are the most common kinds of keys anyway. -Doug From Ulf.Zibis at gmx.de Wed May 30 14:05:15 2012 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Wed, 30 May 2012 16:05:15 +0200 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps In-Reply-To: References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> <94E7336B-91D6-4191-84EA-C9B668B0D172@oracle.com> <4FBFC3AD.5020709@univ-mlv.fr> Message-ID: <4FC6291B.6030205@gmx.de> Hi, there are still some "Yoda" style expressions in String, HashMap, maybe more... there is still {@inheritDoc} in String.hash32(), which points to nowhere, since interface Hashable32 is not implemented. -Ulf Am 30.05.2012 01:05, schrieb Mike Duigou: > Another round of updates for Java 7 [1] and Java 8 [2] implementations. This revision incorporates Remi's suggestions and some feedback from Doug Lea regarding applying the per-instance seed to the result of String.hash32() > > [1] althashing "7" webrev : http://cr.openjdk.java.net/~mduigou/althashing7/10/webrev/ > [2] althashing "8" webrev : http://cr.openjdk.java.net/~mduigou/althashing8/10/webrev/ > > Barring any emergencies this will be integrated to both Java 7 and Java 8 on Wednesday May 30th, 2012. > > Thanks to all who provided feedback! > > Mike > > > On May 25 2012, at 10:38 , R?mi Forax wrote: > >> On 05/24/2012 09:34 PM, Mike Duigou wrote: >>> Hello All; >>> >>> I have updated the webrevs for alternative hashing for String with feedback from Remi, Doug, Ulf and internal reviewers. >>> >>> Additional feedback is welcome. >>> >>> Mike >>> >>> [1] althashing "7" webrev : http://cr.openjdk.java.net/~mduigou/althashing7/9/webrev/ >>> [2] althashing "8" webrev : http://cr.openjdk.java.net/~mduigou/althashing8/9/webrev/ >> Hello Mike, >> just two small issues. >> >> In WeakHashMap.hash(), the null check should be done at callsite, > It's not even needed at the callsite as it always follows a maskNull call. > >> the call to hash32() should be directly returned like in HashMap. > Fixed. > >> Is Hashable32 is used anymore ? > It's the "source" of the hash32 method that String now implements and hopefully more later. This bit is sort of unfinished in this patch but I would like to leave it in for now. > > Mike > > >> R?mi >> >>> On May 22 2012, at 22:16 , Mike Duigou wrote: >>> >>>> Dear OpenJDK CoreLibs community, >>>> >>>> A significant enhancement to the Java SE hashing-based Map implementations in planned for inclusion in Java SE 7u6. All of the hashing based Map implementations: HashMap, Hashtable, LinkedHashMap, WeakHashMap and ConcurrentHashMap will now use an enhanced hashing algorithm for string keys when the capacity of the hash table has ever grown beyond 512 entries. The enhanced hashing implementation uses the murmur3 hashing algorithm[1] along with random hash seeds and index masks. These enhancements mitigate cases where colliding String hash values could result in a performance bottleneck. >>>> >>>> In order to provide the greatest opportunity for developers to test compatibility with their applications this change will be incorporated into JDK7u6 build 12 and JDK8 build 39. Both builds are planned for release next week. ***For 7u6 build 12 only, the alternative hashing will be unconditionally enabled (always on).*** The threshold default will be reset to the intended release default (512) for 7u6 build 13. >>>> >>>> The quick promotion of this change into builds with limited opportunity for public review and the special behaviour for build 12 is intended to make it easier for developers to test their application compatibility. Feedback on the approach, implementation, compatibility and performance is eagerly sought and encouraged both before *and after* this change is incorporated into the OpenJDK repositories. >>>> >>>> A new system property, jdk.map.althashing.threshold, allows adjustment of the threshold for enabling the enhanced hashing algorithm. If changed from the default value of 512, the enhanced hashing will be invoked any time after map capacity exceeds the value of jdk.map.althashing.threshold. To completely disable the enhanced hashing (not recommended), set jdk.map.althashing.threshold to -1 or a very large number such as 2^31 -1 (Integer.MAX_VALUE). >>>> >>>> The iteration order of keys, values and entries for hash-based maps where the new algorithm has been invoked will vary for each HashMap instance. While the Java SE Map documentation makes no promises that iteration order of items returned from Maps will be consistent, developers should check if their applications have incorrectly created a dependency on the iteration order of Map entries, keys or values. >>>> >>>> Webrevs for the Java 7u6 and 8 changes are available for download at [2] and [3] for your review. There are some important differences between the Java 7 and 8 implementations of this enhancement. Most specifically in the Java 8 implementation alternative string hashing is always enabled--no threshold is used for enablement and alternative hashing cannot be disabled. (The Java 8 implementation completely ignores the jdk.map.althashing.threshold system property). The Java 8 implementation is also subject to additional refinement as Java 8 develops. >>>> >>>> If you have any questions or concerns with this planned enhancement, please use the corelibs development mailing list,, or you may also respond privately to me if you prefer. >>>> >>>> Thanks, >>>> >>>> Mike >>>> >>>> [1] Murmur3 : https://code.google.com/p/smhasher/wiki/MurmurHash3 >>>> [2] althashing "7" webrev : http://cr.openjdk.java.net/~mduigou/althashing7/8/webrev/ >>>> [3] althashing "8" webrev : http://cr.openjdk.java.net/~mduigou/althashing8/8/webrev/ > From Ulf.Zibis at gmx.de Wed May 30 14:05:22 2012 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Wed, 30 May 2012 16:05:22 +0200 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps In-Reply-To: <64B6FF09-FF0C-46E9-BAE6-6C9A4CE9F779@oracle.com> References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> <4FC0354C.4010207@gmx.de> <4FC3D33E.3060407@cs.oswego.edu> <64B6FF09-FF0C-46E9-BAE6-6C9A4CE9F779@oracle.com> Message-ID: <4FC62922.6030309@gmx.de> Am 29.05.2012 23:25, schrieb Mike Duigou: > On May 28 2012, at 12:34 , Doug Lea wrote: >> On 05/25/12 21:43, Ulf Zibis wrote: >>> To me it seems, that computing the murmur hash is more expensive, especially on >>> short strings, than the old hash algorithm. >> It is definitely slower, but also definitely has better statistical >> properties (fewer collisions when used in hash tables). Thanks for your confirmation. > Implementations are also free to change to a different algorithm for performance, security or scalability reasons as they see fit. How should that work, if HashMap.hash() is not overrideable? >> This means that any application that hashes strings only once will >> be slower than using (old) hashCode. but any application that >> uses the (cached) hashes more than a few times will tend to run >> faster than old hashCode version because of higher quality hash codes. >> A few tests so far confirm this. > This was my result as well. Caching makes most of the differences between String.hashCode (legacy algorithm) and String.hash32 (the murmur3 implementation) disappear. I actually tested with a version of hashCode that recalculated the result 2X, 5X and 10X times in a loop to look at the impact of caching. The conclusion was that even a 5X more expensive hashing algorithm was bearable as long as caching was present. There are still many cases where caching can't be present, such as parsing, where all of the items being hashed are new objects with no previously cached hash value. These cases require that we provide a reasonably performing hash algorithm. Murmur3 is slower than the legacy algorithm but not enough slower to cripple overall usage and it's better distribution really shines on larger tables. So applications, which mostly process new strings from I/O, must live with the slower performance in future? Especially, if the developer knows about the nature of the expected strings, there could be a significant performance gain from customizing the hash algorithm, see example: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6812862 Please additionally note, that my more general "overkill" approach has less instructions to execute for calculating the hash32 and does not need the instanceof processing, which can be potentially slow on some VM's. May be someone knows about a better code architecture than my given approach to allow custom hash algorithms, let us know. In case of often using the same strings, developer should intern them for benefitting from the already calculated VM-internal hash. BTW, wouldn't it make sense, to use the Murmur hash also there? -Ulf From forax at univ-mlv.fr Wed May 30 14:38:33 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 30 May 2012 16:38:33 +0200 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps In-Reply-To: References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> <94E7336B-91D6-4191-84EA-C9B668B0D172@oracle.com> <4FBFC3AD.5020709@univ-mlv.fr> Message-ID: <4FC630E9.3090200@univ-mlv.fr> On 05/30/2012 01:05 AM, Mike Duigou wrote: > Another round of updates for Java 7 [1] and Java 8 [2] implementations. This revision incorporates Remi's suggestions and some feedback from Doug Lea regarding applying the per-instance seed to the result of String.hash32() > > [1] althashing "7" webrev : http://cr.openjdk.java.net/~mduigou/althashing7/10/webrev/ > [2] althashing "8" webrev : http://cr.openjdk.java.net/~mduigou/althashing8/10/webrev/ > > Barring any emergencies this will be integrated to both Java 7 and Java 8 on Wednesday May 30th, 2012. > > Thanks to all who provided feedback! > > Mike Hi Mike, I've still trouble to understand why you want to expose something which is not used. We know that the implementation of String.hashCode() is broken but we can't change it because the implementation is part of the spec. We can't do an instanceof check on an interface in the implementations of Map because the VM implementations (not only Hotspot by the way) are not able to transform it to a quick class check. String.hash32 is not a polymorphic method but just a method used to fix the fact that we can't change the implementation of String.hashCode() so there is no need for a interface like Hashable32. as a proof, as Ulf said, String even doesn't implement Hashable32. R?mi > > > On May 25 2012, at 10:38 , R?mi Forax wrote: > >> On 05/24/2012 09:34 PM, Mike Duigou wrote: >>> Hello All; >>> >>> I have updated the webrevs for alternative hashing for String with feedback from Remi, Doug, Ulf and internal reviewers. >>> >>> Additional feedback is welcome. >>> >>> Mike >>> >>> [1] althashing "7" webrev : http://cr.openjdk.java.net/~mduigou/althashing7/9/webrev/ >>> [2] althashing "8" webrev : http://cr.openjdk.java.net/~mduigou/althashing8/9/webrev/ >> Hello Mike, >> just two small issues. >> >> In WeakHashMap.hash(), the null check should be done at callsite, > It's not even needed at the callsite as it always follows a maskNull call. > >> the call to hash32() should be directly returned like in HashMap. > Fixed. > >> Is Hashable32 is used anymore ? > It's the "source" of the hash32 method that String now implements and hopefully more later. This bit is sort of unfinished in this patch but I would like to leave it in for now. > > Mike > > >> R?mi >> >>> On May 22 2012, at 22:16 , Mike Duigou wrote: >>> >>>> Dear OpenJDK CoreLibs community, >>>> >>>> A significant enhancement to the Java SE hashing-based Map implementations in planned for inclusion in Java SE 7u6. All of the hashing based Map implementations: HashMap, Hashtable, LinkedHashMap, WeakHashMap and ConcurrentHashMap will now use an enhanced hashing algorithm for string keys when the capacity of the hash table has ever grown beyond 512 entries. The enhanced hashing implementation uses the murmur3 hashing algorithm[1] along with random hash seeds and index masks. These enhancements mitigate cases where colliding String hash values could result in a performance bottleneck. >>>> >>>> In order to provide the greatest opportunity for developers to test compatibility with their applications this change will be incorporated into JDK7u6 build 12 and JDK8 build 39. Both builds are planned for release next week. ***For 7u6 build 12 only, the alternative hashing will be unconditionally enabled (always on).*** The threshold default will be reset to the intended release default (512) for 7u6 build 13. >>>> >>>> The quick promotion of this change into builds with limited opportunity for public review and the special behaviour for build 12 is intended to make it easier for developers to test their application compatibility. Feedback on the approach, implementation, compatibility and performance is eagerly sought and encouraged both before *and after* this change is incorporated into the OpenJDK repositories. >>>> >>>> A new system property, jdk.map.althashing.threshold, allows adjustment of the threshold for enabling the enhanced hashing algorithm. If changed from the default value of 512, the enhanced hashing will be invoked any time after map capacity exceeds the value of jdk.map.althashing.threshold. To completely disable the enhanced hashing (not recommended), set jdk.map.althashing.threshold to -1 or a very large number such as 2^31 -1 (Integer.MAX_VALUE). >>>> >>>> The iteration order of keys, values and entries for hash-based maps where the new algorithm has been invoked will vary for each HashMap instance. While the Java SE Map documentation makes no promises that iteration order of items returned from Maps will be consistent, developers should check if their applications have incorrectly created a dependency on the iteration order of Map entries, keys or values. >>>> >>>> Webrevs for the Java 7u6 and 8 changes are available for download at [2] and [3] for your review. There are some important differences between the Java 7 and 8 implementations of this enhancement. Most specifically in the Java 8 implementation alternative string hashing is always enabled--no threshold is used for enablement and alternative hashing cannot be disabled. (The Java 8 implementation completely ignores the jdk.map.althashing.threshold system property). The Java 8 implementation is also subject to additional refinement as Java 8 develops. >>>> >>>> If you have any questions or concerns with this planned enhancement, please use the corelibs development mailing list,, or you may also respond privately to me if you prefer. >>>> >>>> Thanks, >>>> >>>> Mike >>>> >>>> [1] Murmur3 : https://code.google.com/p/smhasher/wiki/MurmurHash3 >>>> [2] althashing "7" webrev : http://cr.openjdk.java.net/~mduigou/althashing7/8/webrev/ >>>> [3] althashing "8" webrev : http://cr.openjdk.java.net/~mduigou/althashing8/8/webrev/ From mike.duigou at oracle.com Wed May 30 16:23:22 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 30 May 2012 09:23:22 -0700 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps In-Reply-To: <4FC630E9.3090200@univ-mlv.fr> References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> <94E7336B-91D6-4191-84EA-C9B668B0D172@oracle.com> <4FBFC3AD.5020709@univ-mlv.fr> <4FC630E9.3090200@univ-mlv.fr> Message-ID: <96961476-384D-43D7-8FCE-7B63AA6EA418@oracle.com> On May 30 2012, at 07:38 , R?mi Forax wrote: > On 05/30/2012 01:05 AM, Mike Duigou wrote: >> Another round of updates for Java 7 [1] and Java 8 [2] implementations. This revision incorporates Remi's suggestions and some feedback from Doug Lea regarding applying the per-instance seed to the result of String.hash32() >> >> [1] althashing "7" webrev : http://cr.openjdk.java.net/~mduigou/althashing7/10/webrev/ >> [2] althashing "8" webrev : http://cr.openjdk.java.net/~mduigou/althashing8/10/webrev/ >> >> Barring any emergencies this will be integrated to both Java 7 and Java 8 on Wednesday May 30th, 2012. >> >> Thanks to all who provided feedback! >> >> Mike > > Hi Mike, > I've still trouble to understand why you want to expose something > which is not used. > > We know that the implementation of String.hashCode() > is broken but we can't change it because the implementation > is part of the spec. > We can't do an instanceof check on an interface in the implementations > of Map because the VM implementations (not only Hotspot by the way) > are not able to transform it to a quick class check. > String.hash32 is not a polymorphic method but just a method > used to fix the fact that we can't change the implementation > of String.hashCode() so there is no need for a interface like Hashable32. > > as a proof, as Ulf said, String even doesn't implement Hashable32. It's a mistake that String doesn't implement Hashable32 in the java 8 patch. That line somehow got lost with multiple revisions. (most likely due to constant merge conflicts with the String offset/count patch) I will restore it. The current proposal for Java 8: - A new interface Hashable32 is introduced. - Hashable32 provides a method hash32() - String implements Hashable32 and hash32() method - HashMap et al recognize String and invoke hash32() rather than hashCode() - ** End of current implementation ** - When the mainline javac supports extensions methods the implementation will be extended. - Add extension method to Hashable32.hash32() that calls hashCode() - Object implements Hashable32 [controversial idea] - HashMap et al unconditionally call hash32(). Other JDK code may also switch to call hash32() instead of hashCode() Mike > R?mi > >> >> >> On May 25 2012, at 10:38 , R?mi Forax wrote: >> >>> On 05/24/2012 09:34 PM, Mike Duigou wrote: >>>> Hello All; >>>> >>>> I have updated the webrevs for alternative hashing for String with feedback from Remi, Doug, Ulf and internal reviewers. >>>> >>>> Additional feedback is welcome. >>>> >>>> Mike >>>> >>>> [1] althashing "7" webrev : http://cr.openjdk.java.net/~mduigou/althashing7/9/webrev/ >>>> [2] althashing "8" webrev : http://cr.openjdk.java.net/~mduigou/althashing8/9/webrev/ >>> Hello Mike, >>> just two small issues. >>> >>> In WeakHashMap.hash(), the null check should be done at callsite, >> It's not even needed at the callsite as it always follows a maskNull call. >> >>> the call to hash32() should be directly returned like in HashMap. >> Fixed. >> >>> Is Hashable32 is used anymore ? >> It's the "source" of the hash32 method that String now implements and hopefully more later. This bit is sort of unfinished in this patch but I would like to leave it in for now. >> >> Mike >> >> >>> R?mi >>> >>>> On May 22 2012, at 22:16 , Mike Duigou wrote: >>>> >>>>> Dear OpenJDK CoreLibs community, >>>>> >>>>> A significant enhancement to the Java SE hashing-based Map implementations in planned for inclusion in Java SE 7u6. All of the hashing based Map implementations: HashMap, Hashtable, LinkedHashMap, WeakHashMap and ConcurrentHashMap will now use an enhanced hashing algorithm for string keys when the capacity of the hash table has ever grown beyond 512 entries. The enhanced hashing implementation uses the murmur3 hashing algorithm[1] along with random hash seeds and index masks. These enhancements mitigate cases where colliding String hash values could result in a performance bottleneck. >>>>> >>>>> In order to provide the greatest opportunity for developers to test compatibility with their applications this change will be incorporated into JDK7u6 build 12 and JDK8 build 39. Both builds are planned for release next week. ***For 7u6 build 12 only, the alternative hashing will be unconditionally enabled (always on).*** The threshold default will be reset to the intended release default (512) for 7u6 build 13. >>>>> >>>>> The quick promotion of this change into builds with limited opportunity for public review and the special behaviour for build 12 is intended to make it easier for developers to test their application compatibility. Feedback on the approach, implementation, compatibility and performance is eagerly sought and encouraged both before *and after* this change is incorporated into the OpenJDK repositories. >>>>> >>>>> A new system property, jdk.map.althashing.threshold, allows adjustment of the threshold for enabling the enhanced hashing algorithm. If changed from the default value of 512, the enhanced hashing will be invoked any time after map capacity exceeds the value of jdk.map.althashing.threshold. To completely disable the enhanced hashing (not recommended), set jdk.map.althashing.threshold to -1 or a very large number such as 2^31 -1 (Integer.MAX_VALUE). >>>>> >>>>> The iteration order of keys, values and entries for hash-based maps where the new algorithm has been invoked will vary for each HashMap instance. While the Java SE Map documentation makes no promises that iteration order of items returned from Maps will be consistent, developers should check if their applications have incorrectly created a dependency on the iteration order of Map entries, keys or values. >>>>> >>>>> Webrevs for the Java 7u6 and 8 changes are available for download at [2] and [3] for your review. There are some important differences between the Java 7 and 8 implementations of this enhancement. Most specifically in the Java 8 implementation alternative string hashing is always enabled--no threshold is used for enablement and alternative hashing cannot be disabled. (The Java 8 implementation completely ignores the jdk.map.althashing.threshold system property). The Java 8 implementation is also subject to additional refinement as Java 8 develops. >>>>> >>>>> If you have any questions or concerns with this planned enhancement, please use the corelibs development mailing list,, or you may also respond privately to me if you prefer. >>>>> >>>>> Thanks, >>>>> >>>>> Mike >>>>> >>>>> [1] Murmur3 : https://code.google.com/p/smhasher/wiki/MurmurHash3 >>>>> [2] althashing "7" webrev : http://cr.openjdk.java.net/~mduigou/althashing7/8/webrev/ >>>>> [3] althashing "8" webrev : http://cr.openjdk.java.net/~mduigou/althashing8/8/webrev/ > From kumar.x.srinivasan at oracle.com Wed May 30 16:42:50 2012 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Wed, 30 May 2012 16:42:50 +0000 Subject: hg: jdk8/tl/jdk: 7168401: pack200 does not produce a compatible pack file for JDK7 classes if indy is not present Message-ID: <20120530164309.E6A5D475C4@hg.openjdk.java.net> Changeset: 41dcfdbf8f07 Author: ksrini Date: 2012-05-29 14:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/41dcfdbf8f07 7168401: pack200 does not produce a compatible pack file for JDK7 classes if indy is not present Reviewed-by: jrose ! src/share/classes/com/sun/java/util/jar/pack/Attribute.java ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/com/sun/java/util/jar/pack/ClassReader.java ! src/share/classes/com/sun/java/util/jar/pack/ClassWriter.java ! src/share/classes/com/sun/java/util/jar/pack/Constants.java ! src/share/classes/com/sun/java/util/jar/pack/Package.java ! src/share/classes/com/sun/java/util/jar/pack/PackageReader.java ! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java ! src/share/classes/com/sun/java/util/jar/pack/PackerImpl.java ! src/share/classes/com/sun/java/util/jar/pack/PropMap.java ! src/share/classes/com/sun/java/util/jar/pack/Utils.java ! test/tools/pack200/PackageVersionTest.java From forax at univ-mlv.fr Thu May 31 00:59:57 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 31 May 2012 02:59:57 +0200 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps In-Reply-To: <96961476-384D-43D7-8FCE-7B63AA6EA418@oracle.com> References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> <94E7336B-91D6-4191-84EA-C9B668B0D172@oracle.com> <4FBFC3AD.5020709@univ-mlv.fr> <4FC630E9.3090200@univ-mlv.fr> <96961476-384D-43D7-8FCE-7B63AA6EA418@oracle.com> Message-ID: <4FC6C28D.6040303@univ-mlv.fr> On 05/30/2012 06:23 PM, Mike Duigou wrote: > On May 30 2012, at 07:38 , R?mi Forax wrote: > >> On 05/30/2012 01:05 AM, Mike Duigou wrote: >>> Another round of updates for Java 7 [1] and Java 8 [2] implementations. This revision incorporates Remi's suggestions and some feedback from Doug Lea regarding applying the per-instance seed to the result of String.hash32() >>> >>> [1] althashing "7" webrev : http://cr.openjdk.java.net/~mduigou/althashing7/10/webrev/ >>> [2] althashing "8" webrev : http://cr.openjdk.java.net/~mduigou/althashing8/10/webrev/ >>> >>> Barring any emergencies this will be integrated to both Java 7 and Java 8 on Wednesday May 30th, 2012. >>> >>> Thanks to all who provided feedback! >>> >>> Mike >> Hi Mike, >> I've still trouble to understand why you want to expose something >> which is not used. >> >> We know that the implementation of String.hashCode() >> is broken but we can't change it because the implementation >> is part of the spec. >> We can't do an instanceof check on an interface in the implementations >> of Map because the VM implementations (not only Hotspot by the way) >> are not able to transform it to a quick class check. >> String.hash32 is not a polymorphic method but just a method >> used to fix the fact that we can't change the implementation >> of String.hashCode() so there is no need for a interface like Hashable32. >> >> as a proof, as Ulf said, String even doesn't implement Hashable32. > > It's a mistake that String doesn't implement Hashable32 in the java 8 patch. That line somehow got lost with multiple revisions. (most likely due to constant merge conflicts with the String offset/count patch) I will restore it. > > The current proposal for Java 8: > > - A new interface Hashable32 is introduced. > - Hashable32 provides a method hash32() > - String implements Hashable32 and hash32() method > - HashMap et al recognize String and invoke hash32() rather than hashCode() > - ** End of current implementation ** > - When the mainline javac supports extensions methods the implementation will be extended. > - Add extension method to Hashable32.hash32() that calls hashCode() > - Object implements Hashable32 [controversial idea] > - HashMap et al unconditionally call hash32(). Other JDK code may also switch to call hash32() instead of hashCode() this item is controversial too because HashMap specifies that it use hashCode() not hash32. Anyway, Hashable32 is not needed for this patch and can be introduced later without any problem. So I prefer to postpone the introduction of Hashable32 until we will be able to see if it's the a good idea or not > > Mike R?mi From mike.duigou at oracle.com Thu May 31 00:59:29 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 30 May 2012 17:59:29 -0700 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps In-Reply-To: <4FC6C28D.6040303@univ-mlv.fr> References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> <94E7336B-91D6-4191-84EA-C9B668B0D172@oracle.com> <4FBFC3AD.5020709@univ-mlv.fr> <4FC630E9.3090200@univ-mlv.fr> <96961476-384D-43D7-8FCE-7B63AA6EA418@oracle.com> <4FC6C28D.6040303@univ-mlv.fr> Message-ID: <3F12F61D-420C-41B4-86C0-4B96E774CF3E@oracle.com> On May 30 2012, at 17:59 , R?mi Forax wrote: > On 05/30/2012 06:23 PM, Mike Duigou wrote: >> On May 30 2012, at 07:38 , R?mi Forax wrote: >> >>> On 05/30/2012 01:05 AM, Mike Duigou wrote: >>>> Another round of updates for Java 7 [1] and Java 8 [2] implementations. This revision incorporates Remi's suggestions and some feedback from Doug Lea regarding applying the per-instance seed to the result of String.hash32() >>>> >>>> [1] althashing "7" webrev : http://cr.openjdk.java.net/~mduigou/althashing7/10/webrev/ >>>> [2] althashing "8" webrev : http://cr.openjdk.java.net/~mduigou/althashing8/10/webrev/ >>>> >>>> Barring any emergencies this will be integrated to both Java 7 and Java 8 on Wednesday May 30th, 2012. >>>> >>>> Thanks to all who provided feedback! >>>> >>>> Mike >>> Hi Mike, >>> I've still trouble to understand why you want to expose something >>> which is not used. >>> >>> We know that the implementation of String.hashCode() >>> is broken but we can't change it because the implementation >>> is part of the spec. >>> We can't do an instanceof check on an interface in the implementations >>> of Map because the VM implementations (not only Hotspot by the way) >>> are not able to transform it to a quick class check. >>> String.hash32 is not a polymorphic method but just a method >>> used to fix the fact that we can't change the implementation >>> of String.hashCode() so there is no need for a interface like Hashable32. >>> >>> as a proof, as Ulf said, String even doesn't implement Hashable32. >> >> It's a mistake that String doesn't implement Hashable32 in the java 8 patch. That line somehow got lost with multiple revisions. (most likely due to constant merge conflicts with the String offset/count patch) I will restore it. >> >> The current proposal for Java 8: >> >> - A new interface Hashable32 is introduced. >> - Hashable32 provides a method hash32() >> - String implements Hashable32 and hash32() method >> - HashMap et al recognize String and invoke hash32() rather than hashCode() >> - ** End of current implementation ** >> - When the mainline javac supports extensions methods the implementation will be extended. >> - Add extension method to Hashable32.hash32() that calls hashCode() >> - Object implements Hashable32 [controversial idea] >> - HashMap et al unconditionally call hash32(). Other JDK code may also switch to call hash32() instead of hashCode() > this item is controversial too because HashMap specifies that it use hashCode() not hash32. > > Anyway, Hashable32 is not needed for this patch and can be introduced later without any problem. > So I prefer to postpone the introduction of Hashable32 until we will be able to see if it's the a good idea or not Fair enough. I am eager to get this patch in so I will remove it if that is the only remaining objection. Mike From mike.duigou at oracle.com Thu May 31 03:39:06 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 30 May 2012 20:39:06 -0700 Subject: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps In-Reply-To: <4FC6291B.6030205@gmx.de> References: <7AF40196-1CEA-4BFC-82C7-8AF9C4535D03@oracle.com> <94E7336B-91D6-4191-84EA-C9B668B0D172@oracle.com> <4FBFC3AD.5020709@univ-mlv.fr> <4FC6291B.6030205@gmx.de> Message-ID: On May 30 2012, at 07:05 , Ulf Zibis wrote: > Hi, > > there are still some "Yoda" style expressions in String, HashMap, maybe more... They can be slightly surprising but aren't a bug. Nothing in the style guidelines suggests that they shouldn't be used. > there is still {@inheritDoc} in String.hash32(), which points to nowhere, since interface Hashable32 is not implemented. Now corrected. > -Ulf > > Am 30.05.2012 01:05, schrieb Mike Duigou: >> Another round of updates for Java 7 [1] and Java 8 [2] implementations. This revision incorporates Remi's suggestions and some feedback from Doug Lea regarding applying the per-instance seed to the result of String.hash32() >> >> [1] althashing "7" webrev : http://cr.openjdk.java.net/~mduigou/althashing7/10/webrev/ >> [2] althashing "8" webrev : http://cr.openjdk.java.net/~mduigou/althashing8/10/webrev/ >> >> Barring any emergencies this will be integrated to both Java 7 and Java 8 on Wednesday May 30th, 2012. >> >> Thanks to all who provided feedback! >> >> Mike >> >> >> On May 25 2012, at 10:38 , R?mi Forax wrote: >> >>> On 05/24/2012 09:34 PM, Mike Duigou wrote: >>>> Hello All; >>>> >>>> I have updated the webrevs for alternative hashing for String with feedback from Remi, Doug, Ulf and internal reviewers. >>>> >>>> Additional feedback is welcome. >>>> >>>> Mike >>>> >>>> [1] althashing "7" webrev : http://cr.openjdk.java.net/~mduigou/althashing7/9/webrev/ >>>> [2] althashing "8" webrev : http://cr.openjdk.java.net/~mduigou/althashing8/9/webrev/ >>> Hello Mike, >>> just two small issues. >>> >>> In WeakHashMap.hash(), the null check should be done at callsite, >> It's not even needed at the callsite as it always follows a maskNull call. >> >>> the call to hash32() should be directly returned like in HashMap. >> Fixed. >> >>> Is Hashable32 is used anymore ? >> It's the "source" of the hash32 method that String now implements and hopefully more later. This bit is sort of unfinished in this patch but I would like to leave it in for now. >> >> Mike >> >> >>> R?mi >>> >>>> On May 22 2012, at 22:16 , Mike Duigou wrote: >>>> >>>>> Dear OpenJDK CoreLibs community, >>>>> >>>>> A significant enhancement to the Java SE hashing-based Map implementations in planned for inclusion in Java SE 7u6. All of the hashing based Map implementations: HashMap, Hashtable, LinkedHashMap, WeakHashMap and ConcurrentHashMap will now use an enhanced hashing algorithm for string keys when the capacity of the hash table has ever grown beyond 512 entries. The enhanced hashing implementation uses the murmur3 hashing algorithm[1] along with random hash seeds and index masks. These enhancements mitigate cases where colliding String hash values could result in a performance bottleneck. >>>>> >>>>> In order to provide the greatest opportunity for developers to test compatibility with their applications this change will be incorporated into JDK7u6 build 12 and JDK8 build 39. Both builds are planned for release next week. ***For 7u6 build 12 only, the alternative hashing will be unconditionally enabled (always on).*** The threshold default will be reset to the intended release default (512) for 7u6 build 13. >>>>> >>>>> The quick promotion of this change into builds with limited opportunity for public review and the special behaviour for build 12 is intended to make it easier for developers to test their application compatibility. Feedback on the approach, implementation, compatibility and performance is eagerly sought and encouraged both before *and after* this change is incorporated into the OpenJDK repositories. >>>>> >>>>> A new system property, jdk.map.althashing.threshold, allows adjustment of the threshold for enabling the enhanced hashing algorithm. If changed from the default value of 512, the enhanced hashing will be invoked any time after map capacity exceeds the value of jdk.map.althashing.threshold. To completely disable the enhanced hashing (not recommended), set jdk.map.althashing.threshold to -1 or a very large number such as 2^31 -1 (Integer.MAX_VALUE). >>>>> >>>>> The iteration order of keys, values and entries for hash-based maps where the new algorithm has been invoked will vary for each HashMap instance. While the Java SE Map documentation makes no promises that iteration order of items returned from Maps will be consistent, developers should check if their applications have incorrectly created a dependency on the iteration order of Map entries, keys or values. >>>>> >>>>> Webrevs for the Java 7u6 and 8 changes are available for download at [2] and [3] for your review. There are some important differences between the Java 7 and 8 implementations of this enhancement. Most specifically in the Java 8 implementation alternative string hashing is always enabled--no threshold is used for enablement and alternative hashing cannot be disabled. (The Java 8 implementation completely ignores the jdk.map.althashing.threshold system property). The Java 8 implementation is also subject to additional refinement as Java 8 develops. >>>>> >>>>> If you have any questions or concerns with this planned enhancement, please use the corelibs development mailing list,, or you may also respond privately to me if you prefer. >>>>> >>>>> Thanks, >>>>> >>>>> Mike >>>>> >>>>> [1] Murmur3 : https://code.google.com/p/smhasher/wiki/MurmurHash3 >>>>> [2] althashing "7" webrev : http://cr.openjdk.java.net/~mduigou/althashing7/8/webrev/ >>>>> [3] althashing "8" webrev : http://cr.openjdk.java.net/~mduigou/althashing8/8/webrev/ >> From mike.duigou at oracle.com Thu May 31 03:22:35 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Thu, 31 May 2012 03:22:35 +0000 Subject: hg: jdk8/tl/jdk: 6924259: Remove offset and count fields from java.lang.String Message-ID: <20120531032252.A69774763C@hg.openjdk.java.net> Changeset: 2c773daa825d Author: mduigou Date: 2012-05-17 10:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c773daa825d 6924259: Remove offset and count fields from java.lang.String Summary: Removes the use of shared character array buffers by String along with the two fields needed to support the use of shared buffers. Reviewed-by: alanb, mduigou, forax, briangoetz Contributed-by: brian.doherty at oracle.com ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/String.java ! src/share/classes/java/lang/StringCoding.java From mike.duigou at oracle.com Thu May 31 05:19:10 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Thu, 31 May 2012 05:19:10 +0000 Subject: hg: jdk8/tl/jdk: 7126277: Alternative String hashing implementation Message-ID: <20120531051930.AA11E47640@hg.openjdk.java.net> Changeset: 43bd5ee0205e Author: mduigou Date: 2012-05-30 22:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/43bd5ee0205e 7126277: Alternative String hashing implementation Summary: All of the hashing based Map implementations: HashMap, Hashtable, LinkedHashMap, WeakHashMap and ConcurrentHashMap are modified to use an enhanced hashing algorithm for string keys when the capacity of the hash table has ever grown beyond 512 entries. The enhanced hashing implementation uses the murmur3 hashing algorithm along with random hash seeds and index masks. These enhancements mitigate cases where colliding String hash values could result in a performance bottleneck. Reviewed-by: alanb, forax, dl ! make/java/java/FILES_java.gmk ! src/share/classes/java/lang/String.java ! src/share/classes/java/util/HashMap.java ! src/share/classes/java/util/Hashtable.java ! src/share/classes/java/util/LinkedHashMap.java ! src/share/classes/java/util/WeakHashMap.java ! src/share/classes/java/util/concurrent/ConcurrentHashMap.java + src/share/classes/sun/misc/Hashing.java ! test/java/util/Collection/BiggernYours.java ! test/java/util/Hashtable/HashCode.java ! test/java/util/Hashtable/SimpleSerialization.java + test/java/util/Map/Collisions.java ! test/java/util/Map/Get.java + test/sun/misc/Hashing.java From Ulf.Zibis at gmx.de Thu May 31 08:40:38 2012 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 31 May 2012 10:40:38 +0200 Subject: hg: jdk8/tl/jdk: 7126277: Alternative String hashing implementation In-Reply-To: <20120531051930.AA11E47640@hg.openjdk.java.net> References: <20120531051930.AA11E47640@hg.openjdk.java.net> Message-ID: <4FC72E86.8070401@gmx.de> Hi Mike, some more questions: public class Hashmap { + int hash(Object k) { + int h = hashSeed; + if (k instanceof String) { + return ((String) k).hash32(); + } else { + h ^= k.hashCode(); + } + + // This function ensures that hashCodes that differ only by + // constant multiples at each bit position have a bounded + // number of collisions (approximately 8 at default load factor). + h ^= (h >>> 20) ^ (h >>> 12); + return h ^ (h >>> 7) ^ (h >>> 4); } Why you declare and assign variable h before the if statement? And why you set h ^= k.hashCode(); in the else branch, but not the remaining instructions to complete the calculation? Similar (but why little different?) for: Hashtable WeakHashMap ConcurrentHashMap So couldn't method hash(Object) be moved to AbstractMap? Why in WeakHashMap method hash(Object) is not final? (In this case I could exceptionally override it for a custom implementation as former desired for all hash maps.) -Ulf Am 31.05.2012 07:19, schrieb mike.duigou at oracle.com: > Changeset: 43bd5ee0205e > Author: mduigou > Date: 2012-05-30 22:18 -0700 > URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/43bd5ee0205e > > 7126277: Alternative String hashing implementation > Summary: All of the hashing based Map implementations: HashMap, Hashtable, LinkedHashMap, WeakHashMap and ConcurrentHashMap are modified to use an enhanced hashing algorithm for string keys when the capacity of the hash table has ever grown beyond 512 entries. The enhanced hashing implementation uses the murmur3 hashing algorithm along with random hash seeds and index masks. These enhancements mitigate cases where colliding String hash values could result in a performance bottleneck. > Reviewed-by: alanb, forax, dl > > ! make/java/java/FILES_java.gmk > ! src/share/classes/java/lang/String.java > ! src/share/classes/java/util/HashMap.java > ! src/share/classes/java/util/Hashtable.java > ! src/share/classes/java/util/LinkedHashMap.java > ! src/share/classes/java/util/WeakHashMap.java > ! src/share/classes/java/util/concurrent/ConcurrentHashMap.java > + src/share/classes/sun/misc/Hashing.java > ! test/java/util/Collection/BiggernYours.java > ! test/java/util/Hashtable/HashCode.java > ! test/java/util/Hashtable/SimpleSerialization.java > + test/java/util/Map/Collisions.java > ! test/java/util/Map/Get.java > + test/sun/misc/Hashing.java > > From rob.mckenna at oracle.com Thu May 31 15:05:47 2012 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 31 May 2012 16:05:47 +0100 Subject: review request: 4244896: (process) Provide System.getPid(), System.killProcess(String pid) In-Reply-To: <4FAC0F5F.3090508@oracle.com> References: <4F861847.5080308@oracle.com> <4F869AD6.7010903@oracle.com>, <4F8D849E.8090607@oracle.com> <4F8F56E0.6020009@oracle.com> <4F8FF15E.9080408@oracle.com> <4FAC0F5F.3090508@oracle.com> Message-ID: <4FC788CB.9070900@oracle.com> Latest version including work on the spec language: http://cr.openjdk.java.net/~robm/4244896/webrev.04/ -Rob On 10/05/12 19:56, Rob McKenna wrote: > Hi folks, > > The latest version is at: > > http://cr.openjdk.java.net/~robm/4244896/webrev.03/ > > > Feedback greatly appreciated. > > -Rob > > On 19/04/12 12:05, Alan Bateman wrote: >> On 19/04/2012 01:05, David Holmes wrote: >>> On 18/04/2012 11:44 PM, Jason Mehrens wrote: >>>> >>>> Rob, >>>> >>>> It looks like waitFor is calling Object.wait(long) without owning >>>> this objects monitor. If I pass Long.MAX_VALUE to waitFor, >>>> shouldn't waitFor return if the early if the process ends? >>> >>> Also waitFor doesn't call wait() under the guard of a looping >>> predicate so it will suffer from lost signals and potentially >>> spurious wakeups. I also don't see anything calling notify[All] to >>> indicate the process has now terminated. It would appear that >>> wait(timeout) is being used as a sleep mechanism and that is wrong >>> on a number of levels. >> I assume waitFor(timout) will require 3 distinct implementations, one >> for Solaris/Linux/Mac, another for Windows, and a default >> implementations for Process implementations that exist outside of the >> JDK. >> >> It's likely the Solaris/Linux/Mac implementation will involve two >> threads, one to block in waitpid and the other to interrupt it via a >> signal if the timeout elapses before the child terminates. The >> Windows implementation should be trivial because it can be a timed wait. >> >> I assume the default implementation (which is what is being discussed >> here) will need to loop calling exitValue until the timeout elapses >> or the child terminates. Not very efficient but at least it won't be >> used when when creating Processes via Runtime.exec or ProcessBuilder. >> >> I think the question we need to consider is whether waitFor(timeout) >> is really needed. If it's something that it pushed out for another >> day then it brings up the question as to whether to include isAlive >> now or not (as waitFor without timeout gives us an isAlive equivalent >> too). >> >> -Alan. >> >> >> >> From rob.mckenna at oracle.com Thu May 31 16:48:54 2012 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 31 May 2012 17:48:54 +0100 Subject: review request: 4244896: (process) Provide System.getPid(), System.killProcess(String pid) In-Reply-To: <4FC788CB.9070900@oracle.com> References: <4F861847.5080308@oracle.com> <4F869AD6.7010903@oracle.com>, <4F8D849E.8090607@oracle.com> <4F8F56E0.6020009@oracle.com> <4F8FF15E.9080408@oracle.com> <4FAC0F5F.3090508@oracle.com> <4FC788CB.9070900@oracle.com> Message-ID: <4FC7A0F6.7000402@oracle.com> That link should be: http://cr.openjdk.java.net/~robm/4244896/webrev.04/ -Rob On 31/05/12 16:05, Rob McKenna wrote: > Latest version including work on the spec language: > > http://cr.openjdk.java.net/~robm/4244896/webrev.04/ > > > -Rob > > On 10/05/12 19:56, Rob McKenna wrote: >> Hi folks, >> >> The latest version is at: >> >> http://cr.openjdk.java.net/~robm/4244896/webrev.03/ >> >> >> Feedback greatly appreciated. >> >> -Rob >> >> On 19/04/12 12:05, Alan Bateman wrote: >>> On 19/04/2012 01:05, David Holmes wrote: >>>> On 18/04/2012 11:44 PM, Jason Mehrens wrote: >>>>> >>>>> Rob, >>>>> >>>>> It looks like waitFor is calling Object.wait(long) without owning >>>>> this objects monitor. If I pass Long.MAX_VALUE to waitFor, >>>>> shouldn't waitFor return if the early if the process ends? >>>> >>>> Also waitFor doesn't call wait() under the guard of a looping >>>> predicate so it will suffer from lost signals and potentially >>>> spurious wakeups. I also don't see anything calling notify[All] to >>>> indicate the process has now terminated. It would appear that >>>> wait(timeout) is being used as a sleep mechanism and that is wrong >>>> on a number of levels. >>> I assume waitFor(timout) will require 3 distinct implementations, >>> one for Solaris/Linux/Mac, another for Windows, and a default >>> implementations for Process implementations that exist outside of >>> the JDK. >>> >>> It's likely the Solaris/Linux/Mac implementation will involve two >>> threads, one to block in waitpid and the other to interrupt it via a >>> signal if the timeout elapses before the child terminates. The >>> Windows implementation should be trivial because it can be a timed >>> wait. >>> >>> I assume the default implementation (which is what is being >>> discussed here) will need to loop calling exitValue until the >>> timeout elapses or the child terminates. Not very efficient but at >>> least it won't be used when when creating Processes via Runtime.exec >>> or ProcessBuilder. >>> >>> I think the question we need to consider is whether waitFor(timeout) >>> is really needed. If it's something that it pushed out for another >>> day then it brings up the question as to whether to include isAlive >>> now or not (as waitFor without timeout gives us an isAlive >>> equivalent too). >>> >>> -Alan. >>> >>> >>> >>> From maurizio.cimadamore at oracle.com Thu May 31 16:53:34 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 31 May 2012 16:53:34 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20120531165338.65BF84764F@hg.openjdk.java.net> Changeset: af6a4c24f4e3 Author: mcimadamore Date: 2012-05-31 17:42 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/af6a4c24f4e3 7166552: Inference: cleanup usage of Type.ForAll Summary: Remove hack to callback into type-inference from assignment context Reviewed-by: dlsmith, jjg ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/AttrContext.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/6758789/T6758789b.out ! test/tools/javac/diags/examples.not-yet.txt ! test/tools/javac/diags/examples/ApplicableMethodFound1.java ! test/tools/javac/diags/examples/CantApplyDiamond1.java - test/tools/javac/diags/examples/FullInstSig.java ! test/tools/javac/diags/examples/IncompatibleTypes1.java ! test/tools/javac/diags/examples/InferredDoNotConformToLower.java - test/tools/javac/diags/examples/InvalidInferredTypes.java + test/tools/javac/diags/examples/NoUniqueMaximalInstance.java - test/tools/javac/diags/examples/UndeterminedType1.java ! test/tools/javac/diags/examples/WhereFreshTvar.java ! test/tools/javac/generics/7015430/T7015430.out ! test/tools/javac/generics/7151802/T7151802.out ! test/tools/javac/generics/inference/6315770/T6315770.out ! test/tools/javac/generics/inference/6638712/T6638712b.out ! test/tools/javac/generics/inference/6638712/T6638712e.out ! test/tools/javac/generics/inference/6650759/T6650759m.out ! test/tools/javac/generics/inference/7154127/T7154127.out ! test/tools/javac/varargs/6313164/T6313164.out Changeset: 37dc15c68760 Author: mcimadamore Date: 2012-05-31 17:44 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/37dc15c68760 7160084: javac fails to compile an apparently valid class/interface combination Summary: javac generates wrong syntetized trees for nested enum constants Reviewed-by: dlsmith, jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java + test/tools/javac/enum/7160084/T7160084a.java + test/tools/javac/enum/7160084/T7160084b.java From mike.duigou at oracle.com Thu May 31 16:58:53 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 31 May 2012 09:58:53 -0700 Subject: hg: jdk8/tl/jdk: 7126277: Alternative String hashing implementation In-Reply-To: <4FC72E86.8070401@gmx.de> References: <20120531051930.AA11E47640@hg.openjdk.java.net> <4FC72E86.8070401@gmx.de> Message-ID: On May 31 2012, at 01:40 , Ulf Zibis wrote: > Hi Mike, > > some more questions: > > public class Hashmap { > + int hash(Object k) { > + int h = hashSeed; > + if (k instanceof String) { > + return ((String) k).hash32(); > + } else { > + h ^= k.hashCode(); > + } > + > + // This function ensures that hashCodes that differ only by > + // constant multiples at each bit position have a bounded > + // number of collisions (approximately 8 at default load factor). > + h ^= (h >>> 20) ^ (h >>> 12); > + return h ^ (h >>> 7) ^ (h >>> 4); > } > > Why you declare and assign variable h before the if statement? It used to be referenced in the String case. It could be moved. I will move it in the followon patch. > And why you set h ^= k.hashCode(); in the else branch, but not the remaining instructions to complete the calculation? > Similar (but why little different?) for: > Hashtable I will move the read of hashSeed as per HashMap in the followon patch. Compatibility with legacy behaviour. > WeakHashMap Will be the same as HashMap. > ConcurrentHashMap Improved behaviour. > So couldn't method hash(Object) be moved to AbstractMap? The differences in the avalanche (XOR scrambling) preclude this. It could be decided for Java 8 to use a consistent scrambling implementation. I would want to hear from Doug Lea whether he thinks this is reasonable/worthwhile. Presumably there is a reason that Hashtable, HashMap and ConcurrentHashMap use different scrambling solutions. > Why in WeakHashMap method hash(Object) is not final? Oversight. I will fix this in the followon patch. Thank you for the observant feedback! Mike > (In this case I could exceptionally override it for a custom implementation as former desired for all hash maps.) > > -Ulf > > > Am 31.05.2012 07:19, schrieb mike.duigou at oracle.com: >> Changeset: 43bd5ee0205e >> Author: mduigou >> Date: 2012-05-30 22:18 -0700 >> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/43bd5ee0205e >> >> 7126277: Alternative String hashing implementation >> Summary: All of the hashing based Map implementations: HashMap, Hashtable, LinkedHashMap, WeakHashMap and ConcurrentHashMap are modified to use an enhanced hashing algorithm for string keys when the capacity of the hash table has ever grown beyond 512 entries. The enhanced hashing implementation uses the murmur3 hashing algorithm along with random hash seeds and index masks. These enhancements mitigate cases where colliding String hash values could result in a performance bottleneck. >> Reviewed-by: alanb, forax, dl >> >> ! make/java/java/FILES_java.gmk >> ! src/share/classes/java/lang/String.java >> ! src/share/classes/java/util/HashMap.java >> ! src/share/classes/java/util/Hashtable.java >> ! src/share/classes/java/util/LinkedHashMap.java >> ! src/share/classes/java/util/WeakHashMap.java >> ! src/share/classes/java/util/concurrent/ConcurrentHashMap.java >> + src/share/classes/sun/misc/Hashing.java >> ! test/java/util/Collection/BiggernYours.java >> ! test/java/util/Hashtable/HashCode.java >> ! test/java/util/Hashtable/SimpleSerialization.java >> + test/java/util/Map/Collisions.java >> ! test/java/util/Map/Get.java >> + test/sun/misc/Hashing.java >> >> From Lance.Andersen at oracle.com Thu May 31 17:50:53 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Thu, 31 May 2012 13:50:53 -0400 Subject: Review request for 7145913 CachedRowSetSwriter.insertNewRow() throws SQLException Message-ID: <475A155E-4B22-4A51-B2DC-ACF034F048D0@oracle.com> Hi, Looking for a reviewer for 7145913. This addresses an issue with where a SQLException could be thrown when writing a row back with an auto-incremented column on some databases. Webrev is http://cr.openjdk.java.net/~lancea/7145913/webrev.00/. RowSet TCK, sqe tests and unit tests all pass with this fix. Best Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From schlosna at gmail.com Thu May 31 19:10:34 2012 From: schlosna at gmail.com (David Schlosnagle) Date: Thu, 31 May 2012 15:10:34 -0400 Subject: Review request for 7145913 CachedRowSetSwriter.insertNewRow() throws SQLException In-Reply-To: <475A155E-4B22-4A51-B2DC-ACF034F048D0@oracle.com> References: <475A155E-4B22-4A51-B2DC-ACF034F048D0@oracle.com> Message-ID: On Thu, May 31, 2012 at 1:50 PM, Lance Andersen - Oracle wrote: > Hi, > > Looking for a reviewer for 7145913. ?This addresses an issue with where a SQLException could be thrown when writing a row back with an auto-incremented column on some databases. > > Webrev is http://cr.openjdk.java.net/~lancea/7145913/webrev.00/. ?RowSet TCK, sqe tests and unit tests all pass with this fix. Hi Lance, I had a few quick comments: * Do you need the multiple calls to CachedResultSet.getObject for the primary key, or would it be worthwhile to store the result in a local variable? * This seems to be pre-existing before your changes, but the PreparedStatement pstmtSel and ResultSet rs, rs2 used within the insertNewRow method are never closed, which could lead to resource leaks. * Minor nit, the indentation in this file seems off, especially for the method JavaDoc. I've included a minor cleanup below of the insertNewRow method using try-with-resources. Thanks, Dave /** * Inserts a row that has been inserted into the given * CachedRowSet object into the data source from which * the rowset is derived, returning false if the insertion * was successful. * * @param crs the CachedRowSet object that has had a row inserted * and to whose underlying data source the row will be inserted * @param pstmt the PreparedStatement object that will be used * to execute the insertion * @return false to indicate that the insertion was successful; * true otherwise * @throws SQLException if a database access error occurs */ private boolean insertNewRow(CachedRowSet crs, PreparedStatement pstmt, CachedRowSetImpl crsRes) throws SQLException { boolean returnVal = false; try (PreparedStatement pstmtSel = con.prepareStatement(selectCmd, ResultSet.TYPE_SCROLL_SENSITIVE, ResultSet.CONCUR_READ_ONLY); ResultSet rs = pstmtSel.executeQuery(); ResultSet rs2 = con.getMetaData().getPrimaryKeys(null, null, crs.getTableName()) ) { ResultSetMetaData rsmd = crs.getMetaData(); int icolCount = rsmd.getColumnCount(); String[] primaryKeys = new String[icolCount]; int k = 0; while (rs2.next()) { primaryKeys[k] = rs2.getString("COLUMN_NAME"); k++; } if (rs.next()) { for (String pkName : primaryKeys) { if (!isPKNameValid(pkName, rsmd)) { /* We came here as one of the the primary keys * of the table is not present in the cached * rowset object, it should be an autoincrement column * and not included while creating CachedRowSet * Object, proceed to check for other primary keys */ continue; } Object crsPK = crs.getObject(pkName); if (crsPK == null) { /* * It is possible that the PK is null on some databases * and will be filled in at insert time (MySQL for example) */ break; } String rsPK = rs.getObject(pkName).toString(); if (crsPK.toString().equals(rsPK)) { returnVal = true; this.crsResolve.moveToInsertRow(); for (int i = 1; i <= icolCount; i++) { String colname = (rs.getMetaData()).getColumnName(i); if (colname.equals(pkName)) this.crsResolve.updateObject(i,rsPK); else this.crsResolve.updateNull(i); } this.crsResolve.insertRow(); this.crsResolve.moveToCurrentRow(); } } } if (returnVal) { return returnVal; } try { int i; for (i = 1; i <= icolCount; i++) { Object obj = crs.getObject(i); if (obj != null) { pstmt.setObject(i, obj); } else { pstmt.setNull(i,crs.getMetaData().getColumnType(i)); } } i = pstmt.executeUpdate(); return false; } catch (SQLException ex) { /* * Cursor will come here if executeUpdate fails. * There can be many reasons why the insertion failed, * one can be violation of primary key. * Hence we cannot exactly identify why the insertion failed * Present the current row as a null row to the user. **/ this.crsResolve.moveToInsertRow(); for (int i = 1; i <= icolCount; i++) { this.crsResolve.updateNull(i); } this.crsResolve.insertRow(); this.crsResolve.moveToCurrentRow(); return true; } } } From Lance.Andersen at oracle.com Thu May 31 19:48:13 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Thu, 31 May 2012 15:48:13 -0400 Subject: Review request for 7145913 CachedRowSetSwriter.insertNewRow() throws SQLException In-Reply-To: References: <475A155E-4B22-4A51-B2DC-ACF034F048D0@oracle.com> Message-ID: Hi David, Thanks for the feedback On May 31, 2012, at 3:10 PM, David Schlosnagle wrote: > On Thu, May 31, 2012 at 1:50 PM, Lance Andersen - Oracle > wrote: >> Hi, >> >> Looking for a reviewer for 7145913. This addresses an issue with where a SQLException could be thrown when writing a row back with an auto-incremented column on some databases. >> >> Webrev is http://cr.openjdk.java.net/~lancea/7145913/webrev.00/. RowSet TCK, sqe tests and unit tests all pass with this fix. > > Hi Lance, > > I had a few quick comments: > > * Do you need the multiple calls to CachedResultSet.getObject for the primary > key, or would it be worthwhile to store the result in a local variable? I do not think it will be a huge performance gain as typically there is just 1 column for the PK, occasionally 2 seldom more. > > * This seems to be pre-existing before your changes, but the PreparedStatement > pstmtSel and ResultSet rs, rs2 used within the insertNewRow method are never > closed, which could lead to resource leaks. Yep, that dates back to when this method was written and should be cleaned up as part of this change. > > * Minor nit, the indentation in this file seems off, especially for the method > JavaDoc. True. I do not want to touch the entire class via this bug but makes sense to clean up the indentation for the comments for this method. I can address other formatting via another bug as it keeps it cleaner as to why changes are being made. > > I've included a minor cleanup below of the insertNewRow method using > try-with-resources. Thanks for the suggestion and tweak Best Lance > > Thanks, > Dave > > > /** > * Inserts a row that has been inserted into the given > * CachedRowSet object into the data source from which > * the rowset is derived, returning false if the insertion > * was successful. > * > * @param crs the CachedRowSet object that has had a > row inserted > * and to whose underlying data source the row will be inserted > * @param pstmt the PreparedStatement object that will be used > * to execute the insertion > * @return false to indicate that the insertion was successful; > * true otherwise > * @throws SQLException if a database access error occurs > */ > private boolean insertNewRow(CachedRowSet crs, > PreparedStatement pstmt, CachedRowSetImpl crsRes) throws SQLException { > > boolean returnVal = false; > > try (PreparedStatement pstmtSel = con.prepareStatement(selectCmd, > ResultSet.TYPE_SCROLL_SENSITIVE, > ResultSet.CONCUR_READ_ONLY); > ResultSet rs = pstmtSel.executeQuery(); > ResultSet rs2 = con.getMetaData().getPrimaryKeys(null, null, > crs.getTableName()) > ) { > > ResultSetMetaData rsmd = crs.getMetaData(); > int icolCount = rsmd.getColumnCount(); > String[] primaryKeys = new String[icolCount]; > int k = 0; > while (rs2.next()) { > primaryKeys[k] = rs2.getString("COLUMN_NAME"); > k++; > } > > if (rs.next()) { > for (String pkName : primaryKeys) { > if (!isPKNameValid(pkName, rsmd)) { > > /* We came here as one of the the primary keys > * of the table is not present in the cached > * rowset object, it should be an autoincrement column > * and not included while creating CachedRowSet > * Object, proceed to check for other primary keys > */ > continue; > } > > Object crsPK = crs.getObject(pkName); > if (crsPK == null) { > /* > * It is possible that the PK is null on some databases > * and will be filled in at insert time (MySQL > for example) > */ > break; > } > > String rsPK = rs.getObject(pkName).toString(); > if (crsPK.toString().equals(rsPK)) { > returnVal = true; > this.crsResolve.moveToInsertRow(); > for (int i = 1; i <= icolCount; i++) { > String colname = > (rs.getMetaData()).getColumnName(i); > if (colname.equals(pkName)) > this.crsResolve.updateObject(i,rsPK); > else > this.crsResolve.updateNull(i); > } > this.crsResolve.insertRow(); > this.crsResolve.moveToCurrentRow(); > } > } > } > > if (returnVal) { > return returnVal; > } > > try { > int i; > for (i = 1; i <= icolCount; i++) { > Object obj = crs.getObject(i); > if (obj != null) { > pstmt.setObject(i, obj); > } else { > pstmt.setNull(i,crs.getMetaData().getColumnType(i)); > } > } > > i = pstmt.executeUpdate(); > return false; > > } catch (SQLException ex) { > /* > * Cursor will come here if executeUpdate fails. > * There can be many reasons why the insertion failed, > * one can be violation of primary key. > * Hence we cannot exactly identify why the insertion failed > * Present the current row as a null row to the user. > **/ > this.crsResolve.moveToInsertRow(); > > for (int i = 1; i <= icolCount; i++) { > this.crsResolve.updateNull(i); > } > > this.crsResolve.insertRow(); > this.crsResolve.moveToCurrentRow(); > > return true; > } > } > } Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From dl at cs.oswego.edu Thu May 31 20:23:41 2012 From: dl at cs.oswego.edu (Doug Lea) Date: Thu, 31 May 2012 16:23:41 -0400 Subject: hg: jdk8/tl/jdk: 7126277: Alternative String hashing implementation In-Reply-To: References: <20120531051930.AA11E47640@hg.openjdk.java.net> <4FC72E86.8070401@gmx.de> Message-ID: <4FC7D34D.7020608@cs.oswego.edu> On 05/31/12 12:58, Mike Duigou wrote: >> So couldn't method hash(Object) be moved to AbstractMap? > > The differences in the avalanche (XOR scrambling) preclude this. It could be > decided for Java 8 to use a consistent scrambling implementation. I would > want to hear from Doug Lea whether he thinks this is reasonable/worthwhile. I think a lot more (mainly empirical) performance analysis is needed to make this call. But I also think that the forms of JDK8 versions (and probably backports) are likely to change a lot anyway (ConcurrentHashMap for sure). So doing this anytime soon is likely a bad idea. -Doug From sean.mullan at oracle.com Thu May 31 21:10:51 2012 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Thu, 31 May 2012 21:10:51 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20120531211128.69A6447659@hg.openjdk.java.net> Changeset: 0c6830e7241f Author: mullan Date: 2012-05-30 17:19 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0c6830e7241f 6854712: Revocation checking enhancements (JEP-124) 6637288: Add OCSP support to PKIX CertPathBuilder implementation 7126011: ReverseBuilder.getMatchingCACerts may throws NPE Reviewed-by: xuelei ! src/share/classes/java/security/cert/CertPathBuilder.java ! src/share/classes/java/security/cert/CertPathBuilderSpi.java + src/share/classes/java/security/cert/CertPathChecker.java ! src/share/classes/java/security/cert/CertPathValidator.java ! src/share/classes/java/security/cert/CertPathValidatorSpi.java ! src/share/classes/java/security/cert/PKIXCertPathChecker.java + src/share/classes/java/security/cert/PKIXRevocationChecker.java ! src/share/classes/java/security/cert/package.html ! src/share/classes/sun/security/provider/certpath/AdjacencyList.java ! src/share/classes/sun/security/provider/certpath/BasicChecker.java ! src/share/classes/sun/security/provider/certpath/BuildStep.java ! src/share/classes/sun/security/provider/certpath/Builder.java ! src/share/classes/sun/security/provider/certpath/CertStoreHelper.java ! src/share/classes/sun/security/provider/certpath/CollectionCertStore.java ! src/share/classes/sun/security/provider/certpath/ConstraintsChecker.java - src/share/classes/sun/security/provider/certpath/CrlRevocationChecker.java ! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java ! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java ! src/share/classes/sun/security/provider/certpath/ForwardState.java ! src/share/classes/sun/security/provider/certpath/IndexedCollectionCertStore.java ! src/share/classes/sun/security/provider/certpath/KeyChecker.java ! src/share/classes/sun/security/provider/certpath/OCSP.java - src/share/classes/sun/security/provider/certpath/OCSPChecker.java ! src/share/classes/sun/security/provider/certpath/OCSPRequest.java ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java + src/share/classes/sun/security/provider/certpath/PKIX.java ! src/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java ! src/share/classes/sun/security/provider/certpath/PKIXMasterCertPathValidator.java ! src/share/classes/sun/security/provider/certpath/PolicyChecker.java ! src/share/classes/sun/security/provider/certpath/PolicyNodeImpl.java ! src/share/classes/sun/security/provider/certpath/ReverseBuilder.java ! src/share/classes/sun/security/provider/certpath/ReverseState.java + src/share/classes/sun/security/provider/certpath/RevocationChecker.java ! src/share/classes/sun/security/provider/certpath/SunCertPathBuilder.java ! src/share/classes/sun/security/provider/certpath/SunCertPathBuilderParameters.java ! src/share/classes/sun/security/provider/certpath/URICertStore.java ! src/share/classes/sun/security/provider/certpath/Vertex.java ! src/share/classes/sun/security/provider/certpath/X509CertPath.java ! src/share/classes/sun/security/provider/certpath/X509CertificatePair.java ! src/share/classes/sun/security/x509/X509CRLEntryImpl.java + test/java/security/cert/PKIXRevocationChecker/UnitTest.java Changeset: 3192e73394fe Author: mullan Date: 2012-05-31 17:07 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3192e73394fe Merge - src/share/classes/sun/security/provider/certpath/CrlRevocationChecker.java ! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java ! src/share/classes/sun/security/provider/certpath/ForwardState.java - src/share/classes/sun/security/provider/certpath/OCSPChecker.java ! src/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java ! src/share/classes/sun/security/provider/certpath/ReverseBuilder.java ! src/share/classes/sun/security/provider/certpath/ReverseState.java ! src/share/classes/sun/security/provider/certpath/SunCertPathBuilder.java Changeset: 48dfc0df61d0 Author: mullan Date: 2012-05-31 17:10 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/48dfc0df61d0 Merge From Lance.Andersen at oracle.com Thu May 31 22:16:16 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Thu, 31 May 2012 18:16:16 -0400 Subject: Review request for 7145913 CachedRowSetSwriter.insertNewRow() throws SQLException In-Reply-To: References: <475A155E-4B22-4A51-B2DC-ACF034F048D0@oracle.com> Message-ID: <7A0C9C7C-48E4-422A-9A42-1DAF5263C47C@oracle.com> Here is the revision using the try with resources as David suggested http://cr.openjdk.java.net/~lancea/7145913/webrev.01/ Best Lance On May 31, 2012, at 3:10 PM, David Schlosnagle wrote: > On Thu, May 31, 2012 at 1:50 PM, Lance Andersen - Oracle > wrote: >> Hi, >> >> Looking for a reviewer for 7145913. This addresses an issue with where a SQLException could be thrown when writing a row back with an auto-incremented column on some databases. >> >> Webrev is http://cr.openjdk.java.net/~lancea/7145913/webrev.00/. RowSet TCK, sqe tests and unit tests all pass with this fix. > > Hi Lance, > > I had a few quick comments: > > * Do you need the multiple calls to CachedResultSet.getObject for the primary > key, or would it be worthwhile to store the result in a local variable? > > * This seems to be pre-existing before your changes, but the PreparedStatement > pstmtSel and ResultSet rs, rs2 used within the insertNewRow method are never > closed, which could lead to resource leaks. > > * Minor nit, the indentation in this file seems off, especially for the method > JavaDoc. > > I've included a minor cleanup below of the insertNewRow method using > try-with-resources. > > Thanks, > Dave > > > /** > * Inserts a row that has been inserted into the given > * CachedRowSet object into the data source from which > * the rowset is derived, returning false if the insertion > * was successful. > * > * @param crs the CachedRowSet object that has had a > row inserted > * and to whose underlying data source the row will be inserted > * @param pstmt the PreparedStatement object that will be used > * to execute the insertion > * @return false to indicate that the insertion was successful; > * true otherwise > * @throws SQLException if a database access error occurs > */ > private boolean insertNewRow(CachedRowSet crs, > PreparedStatement pstmt, CachedRowSetImpl crsRes) throws SQLException { > > boolean returnVal = false; > > try (PreparedStatement pstmtSel = con.prepareStatement(selectCmd, > ResultSet.TYPE_SCROLL_SENSITIVE, > ResultSet.CONCUR_READ_ONLY); > ResultSet rs = pstmtSel.executeQuery(); > ResultSet rs2 = con.getMetaData().getPrimaryKeys(null, null, > crs.getTableName()) > ) { > > ResultSetMetaData rsmd = crs.getMetaData(); > int icolCount = rsmd.getColumnCount(); > String[] primaryKeys = new String[icolCount]; > int k = 0; > while (rs2.next()) { > primaryKeys[k] = rs2.getString("COLUMN_NAME"); > k++; > } > > if (rs.next()) { > for (String pkName : primaryKeys) { > if (!isPKNameValid(pkName, rsmd)) { > > /* We came here as one of the the primary keys > * of the table is not present in the cached > * rowset object, it should be an autoincrement column > * and not included while creating CachedRowSet > * Object, proceed to check for other primary keys > */ > continue; > } > > Object crsPK = crs.getObject(pkName); > if (crsPK == null) { > /* > * It is possible that the PK is null on some databases > * and will be filled in at insert time (MySQL > for example) > */ > break; > } > > String rsPK = rs.getObject(pkName).toString(); > if (crsPK.toString().equals(rsPK)) { > returnVal = true; > this.crsResolve.moveToInsertRow(); > for (int i = 1; i <= icolCount; i++) { > String colname = > (rs.getMetaData()).getColumnName(i); > if (colname.equals(pkName)) > this.crsResolve.updateObject(i,rsPK); > else > this.crsResolve.updateNull(i); > } > this.crsResolve.insertRow(); > this.crsResolve.moveToCurrentRow(); > } > } > } > > if (returnVal) { > return returnVal; > } > > try { > int i; > for (i = 1; i <= icolCount; i++) { > Object obj = crs.getObject(i); > if (obj != null) { > pstmt.setObject(i, obj); > } else { > pstmt.setNull(i,crs.getMetaData().getColumnType(i)); > } > } > > i = pstmt.executeUpdate(); > return false; > > } catch (SQLException ex) { > /* > * Cursor will come here if executeUpdate fails. > * There can be many reasons why the insertion failed, > * one can be violation of primary key. > * Hence we cannot exactly identify why the insertion failed > * Present the current row as a null row to the user. > **/ > this.crsResolve.moveToInsertRow(); > > for (int i = 1; i <= icolCount; i++) { > this.crsResolve.updateNull(i); > } > > this.crsResolve.insertRow(); > this.crsResolve.moveToCurrentRow(); > > return true; > } > } > } Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From artem.ananiev at oracle.com Wed May 2 18:05:25 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 02 May 2012 18:05:25 -0000 Subject: Review Request: 7164376 Replace use of sun.security.action.LoadLibraryAction In-Reply-To: <4F9998CF.9000308@oracle.com> References: <4F9998CF.9000308@oracle.com> Message-ID: <4FA1783C.7030809@oracle.com> Hi, Mandy, the client part of the fix looks fine. Let me ask a naive question, though. From your explanation, I see that System.loadLibrary() is now aware of modules. What prevents us to change LoadLibraryAction the same way? "FROM" code looks much more elegant than the new (the old?) "TO" one. Thanks, Artem On 4/26/2012 10:49 PM, Mandy Chung wrote: > 7164376 Replace use of sun.security.action.LoadLibraryAction > with direct call of System.loadLibrary > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7164376/webrev.00/ > > This change is required for jdk modularization. High level summary: > it replaces the use of LoadLibraryAction: > > FROM: > java.security.AccessController.doPrivileged(new LoadLibraryAction("net")); > > TO: > AccessController.doPrivileged( > new java.security.PrivilegedAction() { > public Void run() { > System.loadLibrary("net"); > return null; > } > }); > > It touches files in awt, security and serviceability area (cc'ed). > For this type of simple change, I think 1-2 reviewers can > review all files (simpler to review jdk.patch) and no need > for all teams to do the reviews. > > System.loadLibrary and Runtime.loadLibrary loads a system library of the > given > library name that requires RuntimePermission("loadLibrary."+lib) > permission. > Many places in the JDK code loading a system native library is using the > sun.security.action.LoadLibraryAction convenient class that will load the > system library as a privileged action: > java.security.AccessController.doPrivileged(new LoadLibraryAction("net")); > > The search path of native libraries are coupled with an associated class > loader. > For example, the application class loader uses the path specified in the > "java.library.path" system property for native library lookup. The > loadLibrary > implementation uses the caller's class loader for finding the native > library being > requested. For system libraries, the class loader is null and the system > library > lookup is handled as a special case. When the > sun.security.action.LoadLibraryAction > class is used that is the caller of System.loadLibrary, the caller's > class loader > in this case is "null" loader and thus it always finds the native > library from > the system library path. > > In a modular world, JDK modules may be loaded by multiple different > module class > loader. The following code would not work if it is expected to load a > native > library from a module which is not the module where the > sun.security.action.LoadLibraryAction lives. > > For example, the management module is trying to load libmanagement.so. > Calling > the following will fail to find libmanagement.so because the caller of > System.loadLibrary is the LoadLibraryAction which is in the base module > and search the library from the base module only. To prepare for jdk > modularization, the use of LoadLibraryAction should be replaced with > a direct call of System.loadLibrary. > > This patch also removes sun.security.action.LoadLibraryAction > class to avoid regression. > > Thanks > Mandy > From edvard.wendelin at oracle.com Thu May 3 08:24:46 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Thu, 03 May 2012 08:24:46 -0000 Subject: [7u6] Request for approval: 7118100: (prefs) Inconsistency when using system and user preference on OSX Lion In-Reply-To: <4FA1869B.6020501@oracle.com> References: <4FA050A8.8040605@oracle.com> <4FA1869B.6020501@oracle.com> Message-ID: <4FA240AD.90002@oracle.com> Approved. On 05/02/2012 09:10 PM, Kurchi Hazra wrote: > > Requesting approval to commit fix for CR 7118100. > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7118100 > Webrev: http://cr.openjdk.java.net/~khazra/7118100/webrev.01/ > > This had been reviewed by Alan Bateman. [1] > > This fix has been pushed into jdk8 [2] > > Thanks, > Kurchi > > [1] > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-February/003081.html > [2] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/108a02a57b75 From james.holmlund at oracle.com Mon May 21 23:16:49 2012 From: james.holmlund at oracle.com (james.holmlund at oracle.com) Date: Mon, 21 May 2012 23:16:49 -0000 Subject: hg: jdk8/tl/langtools: 7157798: Add 6 test scenarios for testing inheritance of multiple same-name methods from mulitple interfaces Message-ID: <20120521231643.477004744C@hg.openjdk.java.net> Changeset: f5dbd6895994 Author: jjh Date: 2012-05-21 16:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f5dbd6895994 7157798: Add 6 test scenarios for testing inheritance of multiple same-name methods from mulitple interfaces Reviewed-by: mcimadamore Contributed-by: sue.wei at oracle.com + test/tools/javac/generics/rawOverride/7157798/Test1.java + test/tools/javac/generics/rawOverride/7157798/Test2.java + test/tools/javac/generics/rawOverride/7157798/Test3.java + test/tools/javac/generics/rawOverride/7157798/Test3.out + test/tools/javac/generics/rawOverride/7157798/Test4.java + test/tools/javac/generics/rawOverride/7157798/Test4.out From james.holmlund at oracle.com Thu May 31 22:08:26 2012 From: james.holmlund at oracle.com (james.holmlund at oracle.com) Date: Thu, 31 May 2012 22:08:26 +0000 Subject: hg: jdk8/tl/langtools: 7159016: Static import of member in processor-generated class fails in JDK 7 Message-ID: <20120531220829.D825B4766E@hg.openjdk.java.net> Changeset: 844478076c25 Author: jjh Date: 2012-05-31 15:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/844478076c25 7159016: Static import of member in processor-generated class fails in JDK 7 Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java + test/tools/javac/T7159016.java