From bhavesh.x.patel at oracle.com Thu Jan 2 10:17:42 2014 From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com) Date: Thu, 02 Jan 2014 10:17:42 +0000 Subject: hg: jdk8/tl/langtools: 8029143: javadoc standard doclet should add Functional Interface blurb when @FunctionalInterface annotation is present Message-ID: <20140102101745.F3C9D62FD7@hg.openjdk.java.net> Changeset: 4a6f853f8721 Author: bpatel Date: 2014-01-02 02:15 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4a6f853f8721 8029143: javadoc standard doclet should add Functional Interface blurb when @FunctionalInterface annotation is present Reviewed-by: jjg ! src/share/classes/com/sun/javadoc/ClassDoc.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/RootDocImpl.java ! test/com/sun/javadoc/testLambdaFeature/TestLambdaFeature.java ! test/com/sun/javadoc/testLambdaFeature/pkg/A.java ! test/com/sun/javadoc/testLambdaFeature/pkg1/FuncInf.java + test/com/sun/javadoc/testLambdaFeature/pkg1/NotAFuncInf.java From chris.hegarty at oracle.com Thu Jan 2 16:03:29 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 2 Jan 2014 16:03:29 +0000 Subject: Using @implSpec in AbstractMap, AbstractCollection, AbstractList, etc In-Reply-To: <52BED67D.3050005@cs.oswego.edu> References: <52BED67D.3050005@cs.oswego.edu> Message-ID: Hi Doug, I agree with your changes to AbstractMap. I?ve taken your patch, removed the superfluous paragraph tags, and generated a webrev. http://cr.openjdk.java.net/~chegar/AbstractMap_implSpec/webrev/ I also ran specdiff to see what else may be impacted by this. It shows that the only spec changes are to AbstractMap itself, and to ConcurrentHashMap size and isEmpty. What we want. http://cr.openjdk.java.net/~chegar/AbstractMap_implSpec/specdiff/overview-summary.html I know it is late in the JDK 8 game, but I see this as a serious bug in the documentation, and it needs to be addressed. Conservatively, one could argue that minimally pasting the appropriate specs into CHM size and isEmpty would be sufficient to resolve the problem, but I think your first proposal is a more complete solution. Given the above specdiff, I would be confident to request this change for inclusion in JDK 8. I filed the following bug to track this issue: https://bugs.openjdk.java.net/browse/JDK-8031133 -Chris. On 28 Dec 2013, at 13:47, Doug Lea
wrote: > > There might have been some mis-communication about whether the > new @implSpec tag would be used in existing java.util.AbstractX > classes. I had assumed that it would be, and pulled out a few > javadoc overrides in java.util.concurrent classes that would > not be needed if @implSpec were used. With @implSpec, you do > not need to paste in the interface-level spec in an overridden > method just to suppress inclusion of (incorrect) doc comments > about the default implementation. > > Is it too late to do this for JDK8? It is easy -- just add a line > with @implSpec for each defined method. AbstractMap diffs > below. (They could be tweaked to get rid of now-unnecessary > paragraph markup, but I don't think this would improve display.) > > If this isn't done, then minimally we'd need to paste in > interface-level specs in ConcurrentHashMap.{size, isEmpty} > since the JDK8 javadocs as they stand are wrong. There > may be other cases as well. > > ... > > > diff -r 8bc258c021a3 src/share/classes/java/util/AbstractMap.java > --- a/src/share/classes/java/util/AbstractMap.java Thu Nov 21 09:23:03 2013 -0800 > +++ b/src/share/classes/java/util/AbstractMap.java Sat Dec 28 08:33:42 2013 -0500 > @@ -78,6 +78,7 @@ > /** > * {@inheritDoc} > * > + * @implSpec > *

This implementation returns entrySet().size(). > */ > public int size() { > @@ -87,6 +88,7 @@ > /** > * {@inheritDoc} > * > + * @implSpec > *

This implementation returns size() == 0. > */ > public boolean isEmpty() { > @@ -96,6 +98,7 @@ > /** > * {@inheritDoc} > * > + * @implSpec > *

This implementation iterates over entrySet() searching > * for an entry with the specified value. If such an entry is found, > * true is returned. If the iteration terminates without > @@ -126,6 +129,7 @@ > /** > * {@inheritDoc} > * > + * @implSpec > *

This implementation iterates over entrySet() searching > * for an entry with the specified key. If such an entry is found, > * true is returned. If the iteration terminates without > @@ -157,6 +161,7 @@ > /** > * {@inheritDoc} > * > + * @implSpec > *

This implementation iterates over entrySet() searching > * for an entry with the specified key. If such an entry is found, > * the entry's value is returned. If the iteration terminates without > @@ -191,6 +196,7 @@ > /** > * {@inheritDoc} > * > + * @implSpec > *

This implementation always throws an > * UnsupportedOperationException. > * > @@ -206,6 +212,7 @@ > /** > * {@inheritDoc} > * > + * @implSpec > *

This implementation iterates over entrySet() searching for an > * entry with the specified key. If such an entry is found, its value is > * obtained with its getValue operation, the entry is removed > @@ -255,6 +262,7 @@ > /** > * {@inheritDoc} > * > + * @implSpec > *

This implementation iterates over the specified map's > * entrySet() collection, and calls this map's put > * operation once for each entry returned by the iteration. > @@ -276,6 +284,7 @@ > /** > * {@inheritDoc} > * > + * @implSpec > *

This implementation calls entrySet().clear(). > * > *

Note that this implementation throws an > @@ -302,6 +311,7 @@ > /** > * {@inheritDoc} > * > + * @implSpec > *

This implementation returns a set that subclasses {@link AbstractSet}. > * The subclass's iterator method returns a "wrapper object" over this > * map's entrySet() iterator. The size method > @@ -358,6 +368,7 @@ > /** > * {@inheritDoc} > * > + * @implSpec > *

This implementation returns a collection that subclasses {@link > * AbstractCollection}. The subclass's iterator method returns a > * "wrapper object" over this map's entrySet() iterator. > @@ -425,6 +436,7 @@ > * equals method works properly across different implementations > * of the Map interface. > * > + * @implSpec > *

This implementation first checks if the specified object is this map; > * if so it returns true. Then, it checks if the specified > * object is a map whose size is identical to the size of this map; if > @@ -478,6 +490,7 @@ > * m1 and m2, as required by the general contract of > * {@link Object#hashCode}. > * > + * @implSpec > *

This implementation iterates over entrySet(), calling > * {@link Map.Entry#hashCode hashCode()} on each element (entry) in the > * set, and adding up the results. From volker.simonis at gmail.com Thu Jan 2 17:22:59 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 2 Jan 2014 18:22:59 +0100 Subject: RFR(S): JDK-8031134 : PPC64: implement printing on AIX Message-ID: Hi, could somebody please review the following small change: http://cr.openjdk.java.net/~simonis/webrevs/8031134/ It's the straight forward implementation of the basic printing infrastructure on AIX and shouldn't have any impact on the existing platforms. As always, this change is intended for the http://hg.openjdk.java.net/ppc-aix-port/stage/jdk repository. Thank you and best regards, Volker From Lance.Andersen at oracle.com Thu Jan 2 18:08:44 2014 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Thu, 2 Jan 2014 13:08:44 -0500 Subject: RFR: JDK-8028712 : Tidy warnings cleanup for java.sql package In-Reply-To: <52B45142.4030103@oracle.com> References: <52A0B6EE.5040207@oracle.com> <52A09C4A.9000902@oracle.com> <43E97AF9-B53D-44EE-9F28-AD561C51F2D2@oracle.com> <52B45142.4030103@oracle.com> Message-ID: Hi Serge, On Dec 20, 2013, at 9:16 AM, Serge wrote: > Hi all. > > Please review a second fix > http://cr.openjdk.java.net/~yan/8028712/webrev.03/ > > for > https://bugs.openjdk.java.net/browse/JDK-8028712 > > I deleted part of java/sql/package.html, I did not see the section below deleted, perhaps the change did not get pushed to where you generated the webrev from? > and replaced "br/" to "br" for compliance with html 3.2 > > > On 12/05/2013 10:39 PM, Lance Andersen - Oracle wrote: >> Hi Serge >> >> >> >> This looks OK. >> >> >> >> For >> >> --- old/src/share/classes/java/sql/package.html 2013-12-05 15:08:50.587885460 +0000 >> +++ new/src/share/classes/java/sql/package.html 2013-12-05 15:08:50.435885464 +0000 >> >> Please remove the following >> >> -------------------- >> Package Specification >> >> . Specification of the JDBC 4.0 API >> Related Documentation >> >> . Getting Started--overviews of the major interfaces >> . Chapters on the JDBC API--from the online version of The Java Tutorial Continued >> . JDBCTMAPI Tutorial and Reference, Third Edition-- a complete reference and tutorial for the JDBC 3.0 API >> >> ---------------- >> >> The above links keep breaking now that we are off of java.sun.com >> >> And I agree with roger, please use
>> >> >> Alan, yes I can look to clean up some of the formatting crud for Java SE 9 once we have access to the workspace >> >> Thank you for doing this Serge. >> >> Best >> Lance >> On Dec 5, 2013, at 10:31 AM, Alan Bateman wrote: >> >>> On 05/12/2013 17:25, Serge wrote: >>>> Hi all, >>>> please review the fix >>>> http://cr.openjdk.java.net/~yan/8028712/webrev.02/ >>>> for >>>> https://bugs.openjdk.java.net/browse/JDK-8028712 >>>> >>>> This patch cleanup tidy warnings for generated html documentation, and do >>>> not affect the appearance of the documentation. >>> The removal of the

tags seems okay. The only thing that I'm not sure about the addition of
to the package docs (is that needed?). >>> >>> Lance - while scanning this patch then it appears that some of the formatting in the javadoc comments is all over the place (java.sql.Connection is one example). It might be good to clean that up once the jdk9 project is open for business. >>> >>> -Alan >>> >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> > -------------- next part -------------- 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 brian.burkhalter at oracle.com Thu Jan 2 19:44:53 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 2 Jan 2014 11:44:53 -0800 Subject: JDK 9 RFR of JDK-8029561: Optimization in Integer to string conversion Message-ID: Following up from this thread of last week http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024162.html with respect to https://bugs.openjdk.java.net/browse/JDK-8029561. The change being suggested in this review request is merely to remove the FIXME comment --- a/src/share/classes/java/lang/Integer.java Mon Dec 30 16:34:06 2013 +0400 +++ b/src/share/classes/java/lang/Integer.java Thu Jan 02 11:21:00 2014 -0800 @@ -376,9 +376,6 @@ // JIT case the dispatch overhead doesn't exist and the // "trick" is considerably faster than the classic code. // - // TODO-FIXME: convert (x * 52429) into the equiv shift-add - // sequence. - // // RE: Division by Invariant Integers using Multiplication // T Gralund, P Montgomery // ACM PLDI 1994 since the code change proposed in the issue report did not show any performance improvement. Thanks, Brian From Alan.Bateman at oracle.com Thu Jan 2 20:15:31 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 02 Jan 2014 20:15:31 +0000 Subject: RFR(S): JDK-8031134 : PPC64: implement printing on AIX In-Reply-To: References: Message-ID: <52C5C8E3.8020503@oracle.com> On 02/01/2014 17:22, Volker Simonis wrote: > Hi, > > could somebody please review the following small change: > > http://cr.openjdk.java.net/~simonis/webrevs/8031134/ > > It's the straight forward implementation of the basic printing > infrastructure on AIX and shouldn't have any impact on the existing > platforms. As always, this change is intended for the > http://hg.openjdk.java.net/ppc-aix-port/stage/jdk repository. > cc'ing 2d-dev as that is where the printing code is maintained. Your changes suggest that this code should probably be refactored at some point to make it easier to add other Unix variants. -Alan From Alan.Bateman at oracle.com Thu Jan 2 20:34:23 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 02 Jan 2014 20:34:23 +0000 Subject: JDK 9 RFR of JDK-8027595: Enable BigInteger overflow tests in JTREG In-Reply-To: References: <27318D5E-147F-455B-866C-E4FCC5F2F6A9@oracle.com> <52BCB2C8.50000@oracle.com> <818EBB73-4640-4EB6-9656-7CB2E211ED77@oracle.com> <93D409F9-3D4D-4C56-A3E2-7BA818BAD7EF@oracle.com> <52BCCA18.4010604@oracle.com> Message-ID: <52C5CD4F.9050009@oracle.com> On 27/12/2013 00:34, Brian Burkhalter wrote: > Sounds reasonable. There was previously mention of this getting in before b01 so I wanted to resurface it now. > > Brian > I see Joe's mail asking me to comment but I don't think I have much to add except that when running in agentvm mode + concurrency then it "normal" to limit the heap of the agent VMs to avoid over committing memory. For example, in jdk/test/Makefile then you'll see that the tests are run with -vmoption:-Xmx512m. One idea would be add an @run so that they run in othervm mode. That way there wouldn't be any question about whether the OOME would cause side effects that would impact tests that run subsequently in the same (agent) VM. Another idea is to just check the heap size in the test so that it skips when the heap size is too small (this approach might be a faster than attempting to test and recovering from the OOME). BTW: Just on the "@ test" then the normal way to exclude tests is to add the @ignore tag or else add the test to the exclude list (ProblemList.txt). Just mentioning it because someone might spot the space and wonder if it is intentional or not. -Alan. From brian.burkhalter at oracle.com Thu Jan 2 20:47:34 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 2 Jan 2014 12:47:34 -0800 Subject: JDK 9 RFR of JDK-8027595: Enable BigInteger overflow tests in JTREG In-Reply-To: <52C5CD4F.9050009@oracle.com> References: <27318D5E-147F-455B-866C-E4FCC5F2F6A9@oracle.com> <52BCB2C8.50000@oracle.com> <818EBB73-4640-4EB6-9656-7CB2E211ED77@oracle.com> <93D409F9-3D4D-4C56-A3E2-7BA818BAD7EF@oracle.com> <52BCCA18.4010604@oracle.com> <52C5CD4F.9050009@oracle.com> Message-ID: Would adding @run main/othervm -Xmx1200M BitLengthOverflow and similarly to the other three tests be acceptable? Brian On Jan 2, 2014, at 12:34 PM, Alan Bateman wrote: > For example, in jdk/test/Makefile then you'll see that the tests are run with -vmoption:-Xmx512m. > > One idea would be add an @run so that they run in othervm mode. That way there wouldn't be any question about whether the OOME would cause side effects that would impact tests that run subsequently in the same (agent) VM. From martinrb at google.com Thu Jan 2 22:02:35 2014 From: martinrb at google.com (Martin Buchholz) Date: Thu, 2 Jan 2014 14:02:35 -0800 Subject: Using @implSpec in AbstractMap, AbstractCollection, AbstractList, etc In-Reply-To: References: <52BED67D.3050005@cs.oswego.edu> Message-ID: As the subject says, these changes should be applied to all of the so-called "skeletal implementations" in java.util. There is a *lot* of (previously unavoidable (painful memories)) javadoc duplication in java.util, some of which could now be undone. On Thu, Jan 2, 2014 at 8:03 AM, Chris Hegarty wrote: > Hi Doug, > > I agree with your changes to AbstractMap. I?ve taken your patch, removed > the superfluous paragraph tags, and generated a webrev. > http://cr.openjdk.java.net/~chegar/AbstractMap_implSpec/webrev/ > > I also ran specdiff to see what else may be impacted by this. It shows > that the only spec changes are to AbstractMap itself, and to > ConcurrentHashMap size and isEmpty. What we want. > > http://cr.openjdk.java.net/~chegar/AbstractMap_implSpec/specdiff/overview-summary.html > > I know it is late in the JDK 8 game, but I see this as a serious bug in > the documentation, and it needs to be addressed. > > Conservatively, one could argue that minimally pasting the appropriate > specs into CHM size and isEmpty would be sufficient to resolve the problem, > but I think your first proposal is a more complete solution. Given the > above specdiff, I would be confident to request this change for inclusion > in JDK 8. > > I filed the following bug to track this issue: > https://bugs.openjdk.java.net/browse/JDK-8031133 > > -Chris. > > On 28 Dec 2013, at 13:47, Doug Lea

wrote: > > > > > There might have been some mis-communication about whether the > > new @implSpec tag would be used in existing java.util.AbstractX > > classes. I had assumed that it would be, and pulled out a few > > javadoc overrides in java.util.concurrent classes that would > > not be needed if @implSpec were used. With @implSpec, you do > > not need to paste in the interface-level spec in an overridden > > method just to suppress inclusion of (incorrect) doc comments > > about the default implementation. > > > > Is it too late to do this for JDK8? It is easy -- just add a line > > with @implSpec for each defined method. AbstractMap diffs > > below. (They could be tweaked to get rid of now-unnecessary > > paragraph markup, but I don't think this would improve display.) > > > > If this isn't done, then minimally we'd need to paste in > > interface-level specs in ConcurrentHashMap.{size, isEmpty} > > since the JDK8 javadocs as they stand are wrong. There > > may be other cases as well. > > > > ... > > > > > > diff -r 8bc258c021a3 src/share/classes/java/util/AbstractMap.java > > --- a/src/share/classes/java/util/AbstractMap.java Thu Nov 21 > 09:23:03 2013 -0800 > > +++ b/src/share/classes/java/util/AbstractMap.java Sat Dec 28 > 08:33:42 2013 -0500 > > @@ -78,6 +78,7 @@ > > /** > > * {@inheritDoc} > > * > > + * @implSpec > > *

This implementation returns entrySet().size(). > > */ > > public int size() { > > @@ -87,6 +88,7 @@ > > /** > > * {@inheritDoc} > > * > > + * @implSpec > > *

This implementation returns size() == 0. > > */ > > public boolean isEmpty() { > > @@ -96,6 +98,7 @@ > > /** > > * {@inheritDoc} > > * > > + * @implSpec > > *

This implementation iterates over entrySet() searching > > * for an entry with the specified value. If such an entry is found, > > * true is returned. If the iteration terminates without > > @@ -126,6 +129,7 @@ > > /** > > * {@inheritDoc} > > * > > + * @implSpec > > *

This implementation iterates over entrySet() searching > > * for an entry with the specified key. If such an entry is found, > > * true is returned. If the iteration terminates without > > @@ -157,6 +161,7 @@ > > /** > > * {@inheritDoc} > > * > > + * @implSpec > > *

This implementation iterates over entrySet() searching > > * for an entry with the specified key. If such an entry is found, > > * the entry's value is returned. If the iteration terminates > without > > @@ -191,6 +196,7 @@ > > /** > > * {@inheritDoc} > > * > > + * @implSpec > > *

This implementation always throws an > > * UnsupportedOperationException. > > * > > @@ -206,6 +212,7 @@ > > /** > > * {@inheritDoc} > > * > > + * @implSpec > > *

This implementation iterates over entrySet() > searching for an > > * entry with the specified key. If such an entry is found, its > value is > > * obtained with its getValue operation, the entry is > removed > > @@ -255,6 +262,7 @@ > > /** > > * {@inheritDoc} > > * > > + * @implSpec > > *

This implementation iterates over the specified map's > > * entrySet() collection, and calls this map's put > > * operation once for each entry returned by the iteration. > > @@ -276,6 +284,7 @@ > > /** > > * {@inheritDoc} > > * > > + * @implSpec > > *

This implementation calls entrySet().clear(). > > * > > *

Note that this implementation throws an > > @@ -302,6 +311,7 @@ > > /** > > * {@inheritDoc} > > * > > + * @implSpec > > *

This implementation returns a set that subclasses {@link > AbstractSet}. > > * The subclass's iterator method returns a "wrapper object" over > this > > * map's entrySet() iterator. The size method > > @@ -358,6 +368,7 @@ > > /** > > * {@inheritDoc} > > * > > + * @implSpec > > *

This implementation returns a collection that subclasses {@link > > * AbstractCollection}. The subclass's iterator method returns a > > * "wrapper object" over this map's entrySet() iterator. > > @@ -425,6 +436,7 @@ > > * equals method works properly across different > implementations > > * of the Map interface. > > * > > + * @implSpec > > *

This implementation first checks if the specified object is > this map; > > * if so it returns true. Then, it checks if the specified > > * object is a map whose size is identical to the size of this map; > if > > @@ -478,6 +490,7 @@ > > * m1 and m2, as required by the general contract > of > > * {@link Object#hashCode}. > > * > > + * @implSpec > > *

This implementation iterates over entrySet(), calling > > * {@link Map.Entry#hashCode hashCode()} on each element (entry) in > the > > * set, and adding up the results. > > From chris.hegarty at oracle.com Thu Jan 2 23:48:42 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 2 Jan 2014 23:48:42 +0000 Subject: Using @implSpec in AbstractMap, AbstractCollection, AbstractList, etc In-Reply-To: References: <52BED67D.3050005@cs.oswego.edu> Message-ID: > On 2 Jan 2014, at 22:02, Martin Buchholz wrote: > > As the subject says, these changes should be applied to all of the so-called "skeletal implementations" in java.util. You may have noticed that I used a different subject line in the bug ;-) > There is a *lot* of (previously unavoidable (painful memories)) javadoc duplication in java.util, some of which could now be undone. If you are agreeable, then I'd like to push just the AbstractMap changes as they are to JDK 9 and JDK 8. We can then immediately follow up with the additional skeletal types, under a different bug number for JDK 9, and evaluate the feasibility of putting it into JDK 8. This is just a matter of timing, it is getting very late in the JDK 8 release cycle. There is a specific problem in CHM stemming from AbstractMap, which I would like to resolve without growing the scope of the changes and risk. -Chris. > > >> On Thu, Jan 2, 2014 at 8:03 AM, Chris Hegarty wrote: >> Hi Doug, >> >> I agree with your changes to AbstractMap. I?ve taken your patch, removed the superfluous paragraph tags, and generated a webrev. >> http://cr.openjdk.java.net/~chegar/AbstractMap_implSpec/webrev/ >> >> I also ran specdiff to see what else may be impacted by this. It shows that the only spec changes are to AbstractMap itself, and to ConcurrentHashMap size and isEmpty. What we want. >> http://cr.openjdk.java.net/~chegar/AbstractMap_implSpec/specdiff/overview-summary.html >> >> I know it is late in the JDK 8 game, but I see this as a serious bug in the documentation, and it needs to be addressed. >> >> Conservatively, one could argue that minimally pasting the appropriate specs into CHM size and isEmpty would be sufficient to resolve the problem, but I think your first proposal is a more complete solution. Given the above specdiff, I would be confident to request this change for inclusion in JDK 8. >> >> I filed the following bug to track this issue: >> https://bugs.openjdk.java.net/browse/JDK-8031133 >> >> -Chris. >> >> On 28 Dec 2013, at 13:47, Doug Lea

wrote: >> >> > >> > There might have been some mis-communication about whether the >> > new @implSpec tag would be used in existing java.util.AbstractX >> > classes. I had assumed that it would be, and pulled out a few >> > javadoc overrides in java.util.concurrent classes that would >> > not be needed if @implSpec were used. With @implSpec, you do >> > not need to paste in the interface-level spec in an overridden >> > method just to suppress inclusion of (incorrect) doc comments >> > about the default implementation. >> > >> > Is it too late to do this for JDK8? It is easy -- just add a line >> > with @implSpec for each defined method. AbstractMap diffs >> > below. (They could be tweaked to get rid of now-unnecessary >> > paragraph markup, but I don't think this would improve display.) >> > >> > If this isn't done, then minimally we'd need to paste in >> > interface-level specs in ConcurrentHashMap.{size, isEmpty} >> > since the JDK8 javadocs as they stand are wrong. There >> > may be other cases as well. >> > >> > ... >> > >> > >> > diff -r 8bc258c021a3 src/share/classes/java/util/AbstractMap.java >> > --- a/src/share/classes/java/util/AbstractMap.java Thu Nov 21 09:23:03 2013 -0800 >> > +++ b/src/share/classes/java/util/AbstractMap.java Sat Dec 28 08:33:42 2013 -0500 >> > @@ -78,6 +78,7 @@ >> > /** >> > * {@inheritDoc} >> > * >> > + * @implSpec >> > *

This implementation returns entrySet().size(). >> > */ >> > public int size() { >> > @@ -87,6 +88,7 @@ >> > /** >> > * {@inheritDoc} >> > * >> > + * @implSpec >> > *

This implementation returns size() == 0. >> > */ >> > public boolean isEmpty() { >> > @@ -96,6 +98,7 @@ >> > /** >> > * {@inheritDoc} >> > * >> > + * @implSpec >> > *

This implementation iterates over entrySet() searching >> > * for an entry with the specified value. If such an entry is found, >> > * true is returned. If the iteration terminates without >> > @@ -126,6 +129,7 @@ >> > /** >> > * {@inheritDoc} >> > * >> > + * @implSpec >> > *

This implementation iterates over entrySet() searching >> > * for an entry with the specified key. If such an entry is found, >> > * true is returned. If the iteration terminates without >> > @@ -157,6 +161,7 @@ >> > /** >> > * {@inheritDoc} >> > * >> > + * @implSpec >> > *

This implementation iterates over entrySet() searching >> > * for an entry with the specified key. If such an entry is found, >> > * the entry's value is returned. If the iteration terminates without >> > @@ -191,6 +196,7 @@ >> > /** >> > * {@inheritDoc} >> > * >> > + * @implSpec >> > *

This implementation always throws an >> > * UnsupportedOperationException. >> > * >> > @@ -206,6 +212,7 @@ >> > /** >> > * {@inheritDoc} >> > * >> > + * @implSpec >> > *

This implementation iterates over entrySet() searching for an >> > * entry with the specified key. If such an entry is found, its value is >> > * obtained with its getValue operation, the entry is removed >> > @@ -255,6 +262,7 @@ >> > /** >> > * {@inheritDoc} >> > * >> > + * @implSpec >> > *

This implementation iterates over the specified map's >> > * entrySet() collection, and calls this map's put >> > * operation once for each entry returned by the iteration. >> > @@ -276,6 +284,7 @@ >> > /** >> > * {@inheritDoc} >> > * >> > + * @implSpec >> > *

This implementation calls entrySet().clear(). >> > * >> > *

Note that this implementation throws an >> > @@ -302,6 +311,7 @@ >> > /** >> > * {@inheritDoc} >> > * >> > + * @implSpec >> > *

This implementation returns a set that subclasses {@link AbstractSet}. >> > * The subclass's iterator method returns a "wrapper object" over this >> > * map's entrySet() iterator. The size method >> > @@ -358,6 +368,7 @@ >> > /** >> > * {@inheritDoc} >> > * >> > + * @implSpec >> > *

This implementation returns a collection that subclasses {@link >> > * AbstractCollection}. The subclass's iterator method returns a >> > * "wrapper object" over this map's entrySet() iterator. >> > @@ -425,6 +436,7 @@ >> > * equals method works properly across different implementations >> > * of the Map interface. >> > * >> > + * @implSpec >> > *

This implementation first checks if the specified object is this map; >> > * if so it returns true. Then, it checks if the specified >> > * object is a map whose size is identical to the size of this map; if >> > @@ -478,6 +490,7 @@ >> > * m1 and m2, as required by the general contract of >> > * {@link Object#hashCode}. >> > * >> > + * @implSpec >> > *

This implementation iterates over entrySet(), calling >> > * {@link Map.Entry#hashCode hashCode()} on each element (entry) in the >> > * set, and adding up the results. > From martinrb at google.com Fri Jan 3 02:14:32 2014 From: martinrb at google.com (Martin Buchholz) Date: Thu, 2 Jan 2014 18:14:32 -0800 Subject: Using @implSpec in AbstractMap, AbstractCollection, AbstractList, etc In-Reply-To: References: <52BED67D.3050005@cs.oswego.edu> Message-ID: OK, as you wish - this change is clear progress! On Thu, Jan 2, 2014 at 3:48 PM, Chris Hegarty wrote: > > On 2 Jan 2014, at 22:02, Martin Buchholz wrote: > > As the subject says, these changes should be applied to all of the > so-called "skeletal implementations" in java.util. > > > You may have noticed that I used a different subject line in the bug ;-) > > There is a *lot* of (previously unavoidable (painful memories)) javadoc > duplication in java.util, some of which could now be undone. > > > If you are agreeable, then I'd like to push just the AbstractMap changes > as they are to JDK 9 and JDK 8. We can then immediately follow up with the > additional skeletal types, under a different bug number for JDK 9, and > evaluate the feasibility of putting it into JDK 8. > > This is just a matter of timing, it is getting very late in the JDK 8 > release cycle. There is a specific problem in CHM stemming from > AbstractMap, which I would like to resolve without growing the scope of the > changes and risk. > > -Chris. > > > > On Thu, Jan 2, 2014 at 8:03 AM, Chris Hegarty wrote: > >> Hi Doug, >> >> I agree with your changes to AbstractMap. I?ve taken your patch, removed >> the superfluous paragraph tags, and generated a webrev. >> http://cr.openjdk.java.net/~chegar/AbstractMap_implSpec/webrev/ >> >> I also ran specdiff to see what else may be impacted by this. It shows >> that the only spec changes are to AbstractMap itself, and to >> ConcurrentHashMap size and isEmpty. What we want. >> >> http://cr.openjdk.java.net/~chegar/AbstractMap_implSpec/specdiff/overview-summary.html >> >> I know it is late in the JDK 8 game, but I see this as a serious bug in >> the documentation, and it needs to be addressed. >> >> Conservatively, one could argue that minimally pasting the appropriate >> specs into CHM size and isEmpty would be sufficient to resolve the problem, >> but I think your first proposal is a more complete solution. Given the >> above specdiff, I would be confident to request this change for inclusion >> in JDK 8. >> >> I filed the following bug to track this issue: >> https://bugs.openjdk.java.net/browse/JDK-8031133 >> >> -Chris. >> >> On 28 Dec 2013, at 13:47, Doug Lea

wrote: >> >> > >> > There might have been some mis-communication about whether the >> > new @implSpec tag would be used in existing java.util.AbstractX >> > classes. I had assumed that it would be, and pulled out a few >> > javadoc overrides in java.util.concurrent classes that would >> > not be needed if @implSpec were used. With @implSpec, you do >> > not need to paste in the interface-level spec in an overridden >> > method just to suppress inclusion of (incorrect) doc comments >> > about the default implementation. >> > >> > Is it too late to do this for JDK8? It is easy -- just add a line >> > with @implSpec for each defined method. AbstractMap diffs >> > below. (They could be tweaked to get rid of now-unnecessary >> > paragraph markup, but I don't think this would improve display.) >> > >> > If this isn't done, then minimally we'd need to paste in >> > interface-level specs in ConcurrentHashMap.{size, isEmpty} >> > since the JDK8 javadocs as they stand are wrong. There >> > may be other cases as well. >> > >> > ... >> > >> > >> > diff -r 8bc258c021a3 src/share/classes/java/util/AbstractMap.java >> > --- a/src/share/classes/java/util/AbstractMap.java Thu Nov 21 >> 09:23:03 2013 -0800 >> > +++ b/src/share/classes/java/util/AbstractMap.java Sat Dec 28 >> 08:33:42 2013 -0500 >> > @@ -78,6 +78,7 @@ >> > /** >> > * {@inheritDoc} >> > * >> > + * @implSpec >> > *

This implementation returns entrySet().size(). >> > */ >> > public int size() { >> > @@ -87,6 +88,7 @@ >> > /** >> > * {@inheritDoc} >> > * >> > + * @implSpec >> > *

This implementation returns size() == 0. >> > */ >> > public boolean isEmpty() { >> > @@ -96,6 +98,7 @@ >> > /** >> > * {@inheritDoc} >> > * >> > + * @implSpec >> > *

This implementation iterates over entrySet() >> searching >> > * for an entry with the specified value. If such an entry is >> found, >> > * true is returned. If the iteration terminates without >> > @@ -126,6 +129,7 @@ >> > /** >> > * {@inheritDoc} >> > * >> > + * @implSpec >> > *

This implementation iterates over entrySet() >> searching >> > * for an entry with the specified key. If such an entry is found, >> > * true is returned. If the iteration terminates without >> > @@ -157,6 +161,7 @@ >> > /** >> > * {@inheritDoc} >> > * >> > + * @implSpec >> > *

This implementation iterates over entrySet() >> searching >> > * for an entry with the specified key. If such an entry is found, >> > * the entry's value is returned. If the iteration terminates >> without >> > @@ -191,6 +196,7 @@ >> > /** >> > * {@inheritDoc} >> > * >> > + * @implSpec >> > *

This implementation always throws an >> > * UnsupportedOperationException. >> > * >> > @@ -206,6 +212,7 @@ >> > /** >> > * {@inheritDoc} >> > * >> > + * @implSpec >> > *

This implementation iterates over entrySet() >> searching for an >> > * entry with the specified key. If such an entry is found, its >> value is >> > * obtained with its getValue operation, the entry is >> removed >> > @@ -255,6 +262,7 @@ >> > /** >> > * {@inheritDoc} >> > * >> > + * @implSpec >> > *

This implementation iterates over the specified map's >> > * entrySet() collection, and calls this map's put >> > * operation once for each entry returned by the iteration. >> > @@ -276,6 +284,7 @@ >> > /** >> > * {@inheritDoc} >> > * >> > + * @implSpec >> > *

This implementation calls entrySet().clear(). >> > * >> > *

Note that this implementation throws an >> > @@ -302,6 +311,7 @@ >> > /** >> > * {@inheritDoc} >> > * >> > + * @implSpec >> > *

This implementation returns a set that subclasses {@link >> AbstractSet}. >> > * The subclass's iterator method returns a "wrapper object" over >> this >> > * map's entrySet() iterator. The size method >> > @@ -358,6 +368,7 @@ >> > /** >> > * {@inheritDoc} >> > * >> > + * @implSpec >> > *

This implementation returns a collection that subclasses >> {@link >> > * AbstractCollection}. The subclass's iterator method returns a >> > * "wrapper object" over this map's entrySet() iterator. >> > @@ -425,6 +436,7 @@ >> > * equals method works properly across different >> implementations >> > * of the Map interface. >> > * >> > + * @implSpec >> > *

This implementation first checks if the specified object is >> this map; >> > * if so it returns true. Then, it checks if the specified >> > * object is a map whose size is identical to the size of this map; >> if >> > @@ -478,6 +490,7 @@ >> > * m1 and m2, as required by the general contract >> of >> > * {@link Object#hashCode}. >> > * >> > + * @implSpec >> > *

This implementation iterates over entrySet(), calling >> > * {@link Map.Entry#hashCode hashCode()} on each element (entry) in >> the >> > * set, and adding up the results. >> >> > From chris.hegarty at oracle.com Fri Jan 3 07:06:09 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 3 Jan 2014 07:06:09 +0000 Subject: Using @implSpec in AbstractMap, AbstractCollection, AbstractList, etc In-Reply-To: References: <52BED67D.3050005@cs.oswego.edu> Message-ID: <42B83A56-82E5-4991-A87A-22BB99AB23D2@oracle.com> On 3 Jan 2014, at 02:14, Martin Buchholz wrote: > OK, as you wish - this change is clear progress! Thanks Martin. I pushed the AbstractMap changes to JDK 8 and JDK 9. 8031142 now tracks the changes to AbstractCollection and AbstractList https://bugs.openjdk.java.net/browse/JDK-8031142 -Chris. > > On Thu, Jan 2, 2014 at 3:48 PM, Chris Hegarty wrote: > > On 2 Jan 2014, at 22:02, Martin Buchholz wrote: > >> As the subject says, these changes should be applied to all of the so-called "skeletal implementations" in java.util. > > You may have noticed that I used a different subject line in the bug ;-) > >> There is a *lot* of (previously unavoidable (painful memories)) javadoc duplication in java.util, some of which could now be undone. > > If you are agreeable, then I'd like to push just the AbstractMap changes as they are to JDK 9 and JDK 8. We can then immediately follow up with the additional skeletal types, under a different bug number for JDK 9, and evaluate the feasibility of putting it into JDK 8. > > This is just a matter of timing, it is getting very late in the JDK 8 release cycle. There is a specific problem in CHM stemming from AbstractMap, which I would like to resolve without growing the scope of the changes and risk. > > -Chris. > >> >> >> On Thu, Jan 2, 2014 at 8:03 AM, Chris Hegarty wrote: >> Hi Doug, >> >> I agree with your changes to AbstractMap. I?ve taken your patch, removed the superfluous paragraph tags, and generated a webrev. >> http://cr.openjdk.java.net/~chegar/AbstractMap_implSpec/webrev/ >> >> I also ran specdiff to see what else may be impacted by this. It shows that the only spec changes are to AbstractMap itself, and to ConcurrentHashMap size and isEmpty. What we want. >> http://cr.openjdk.java.net/~chegar/AbstractMap_implSpec/specdiff/overview-summary.html >> >> I know it is late in the JDK 8 game, but I see this as a serious bug in the documentation, and it needs to be addressed. >> >> Conservatively, one could argue that minimally pasting the appropriate specs into CHM size and isEmpty would be sufficient to resolve the problem, but I think your first proposal is a more complete solution. Given the above specdiff, I would be confident to request this change for inclusion in JDK 8. >> >> I filed the following bug to track this issue: >> https://bugs.openjdk.java.net/browse/JDK-8031133 >> >> -Chris. >> >> On 28 Dec 2013, at 13:47, Doug Lea

wrote: >> >> > >> > There might have been some mis-communication about whether the >> > new @implSpec tag would be used in existing java.util.AbstractX >> > classes. I had assumed that it would be, and pulled out a few >> > javadoc overrides in java.util.concurrent classes that would >> > not be needed if @implSpec were used. With @implSpec, you do >> > not need to paste in the interface-level spec in an overridden >> > method just to suppress inclusion of (incorrect) doc comments >> > about the default implementation. >> > >> > Is it too late to do this for JDK8? It is easy -- just add a line >> > with @implSpec for each defined method. AbstractMap diffs >> > below. (They could be tweaked to get rid of now-unnecessary >> > paragraph markup, but I don't think this would improve display.) >> > >> > If this isn't done, then minimally we'd need to paste in >> > interface-level specs in ConcurrentHashMap.{size, isEmpty} >> > since the JDK8 javadocs as they stand are wrong. There >> > may be other cases as well. >> > >> > ... >> > >> > >> > diff -r 8bc258c021a3 src/share/classes/java/util/AbstractMap.java >> > --- a/src/share/classes/java/util/AbstractMap.java Thu Nov 21 09:23:03 2013 -0800 >> > +++ b/src/share/classes/java/util/AbstractMap.java Sat Dec 28 08:33:42 2013 -0500 >> > @@ -78,6 +78,7 @@ >> > /** >> > * {@inheritDoc} >> > * >> > + * @implSpec >> > *

This implementation returns entrySet().size(). >> > */ >> > public int size() { >> > @@ -87,6 +88,7 @@ >> > /** >> > * {@inheritDoc} >> > * >> > + * @implSpec >> > *

This implementation returns size() == 0. >> > */ >> > public boolean isEmpty() { >> > @@ -96,6 +98,7 @@ >> > /** >> > * {@inheritDoc} >> > * >> > + * @implSpec >> > *

This implementation iterates over entrySet() searching >> > * for an entry with the specified value. If such an entry is found, >> > * true is returned. If the iteration terminates without >> > @@ -126,6 +129,7 @@ >> > /** >> > * {@inheritDoc} >> > * >> > + * @implSpec >> > *

This implementation iterates over entrySet() searching >> > * for an entry with the specified key. If such an entry is found, >> > * true is returned. If the iteration terminates without >> > @@ -157,6 +161,7 @@ >> > /** >> > * {@inheritDoc} >> > * >> > + * @implSpec >> > *

This implementation iterates over entrySet() searching >> > * for an entry with the specified key. If such an entry is found, >> > * the entry's value is returned. If the iteration terminates without >> > @@ -191,6 +196,7 @@ >> > /** >> > * {@inheritDoc} >> > * >> > + * @implSpec >> > *

This implementation always throws an >> > * UnsupportedOperationException. >> > * >> > @@ -206,6 +212,7 @@ >> > /** >> > * {@inheritDoc} >> > * >> > + * @implSpec >> > *

This implementation iterates over entrySet() searching for an >> > * entry with the specified key. If such an entry is found, its value is >> > * obtained with its getValue operation, the entry is removed >> > @@ -255,6 +262,7 @@ >> > /** >> > * {@inheritDoc} >> > * >> > + * @implSpec >> > *

This implementation iterates over the specified map's >> > * entrySet() collection, and calls this map's put >> > * operation once for each entry returned by the iteration. >> > @@ -276,6 +284,7 @@ >> > /** >> > * {@inheritDoc} >> > * >> > + * @implSpec >> > *

This implementation calls entrySet().clear(). >> > * >> > *

Note that this implementation throws an >> > @@ -302,6 +311,7 @@ >> > /** >> > * {@inheritDoc} >> > * >> > + * @implSpec >> > *

This implementation returns a set that subclasses {@link AbstractSet}. >> > * The subclass's iterator method returns a "wrapper object" over this >> > * map's entrySet() iterator. The size method >> > @@ -358,6 +368,7 @@ >> > /** >> > * {@inheritDoc} >> > * >> > + * @implSpec >> > *

This implementation returns a collection that subclasses {@link >> > * AbstractCollection}. The subclass's iterator method returns a >> > * "wrapper object" over this map's entrySet() iterator. >> > @@ -425,6 +436,7 @@ >> > * equals method works properly across different implementations >> > * of the Map interface. >> > * >> > + * @implSpec >> > *

This implementation first checks if the specified object is this map; >> > * if so it returns true. Then, it checks if the specified >> > * object is a map whose size is identical to the size of this map; if >> > @@ -478,6 +490,7 @@ >> > * m1 and m2, as required by the general contract of >> > * {@link Object#hashCode}. >> > * >> > + * @implSpec >> > *

This implementation iterates over entrySet(), calling >> > * {@link Map.Entry#hashCode hashCode()} on each element (entry) in the >> > * set, and adding up the results. >> >> > From chris.hegarty at oracle.com Fri Jan 3 06:58:37 2014 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 03 Jan 2014 06:58:37 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20140103065950.CE6EF62FEB@hg.openjdk.java.net> Changeset: 18080cca998a Author: dl Date: 2014-01-03 06:22 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/18080cca998a 8031133: AbstractMap should specify its default implementation using @implSpec Reviewed-by: chegar, alanb ! src/share/classes/java/util/AbstractMap.java Changeset: 33a60ce1e35d Author: chegar Date: 2014-01-03 06:23 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/33a60ce1e35d Merge ! src/share/classes/java/util/AbstractMap.java From Alan.Bateman at oracle.com Fri Jan 3 12:15:09 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 03 Jan 2014 12:15:09 +0000 Subject: JDK 9 RFR of JDK-8027595: Enable BigInteger overflow tests in JTREG In-Reply-To: References: <27318D5E-147F-455B-866C-E4FCC5F2F6A9@oracle.com> <52BCB2C8.50000@oracle.com> <818EBB73-4640-4EB6-9656-7CB2E211ED77@oracle.com> <93D409F9-3D4D-4C56-A3E2-7BA818BAD7EF@oracle.com> <52BCCA18.4010604@oracle.com> <52C5CD4F.9050009@oracle.com> Message-ID: <52C6A9CD.40207@oracle.com> On 02/01/2014 20:47, Brian Burkhalter wrote: > Would adding > > @run main/othervm -Xmx1200M BitLengthOverflow > > and similarly to the other three tests be acceptable? > > Brian This could potentially be problematic on Windows 32-bit but it would help if you add -Xshare:off so that you don't have the shared archive mapped. Also I assume that if you do this that the code to catch OOME should be removed. That said, I can imagine it causing problems on small memory/embedded targets where this will exceed the total memory on the system. The real issue here of course is that we aren't using keywords or other means that allow filtering and selection of tests. This is something that will need to be tackled some day. -Alan From gunnar at hibernate.org Fri Jan 3 13:14:01 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Fri, 3 Jan 2014 14:14:01 +0100 Subject: (reflect) Accessing members of inner annotations types Message-ID: Hi, In the course of running the Bean Validation TCK on JDK 8, I'm investigating an issue around reflectively accessing members of annotations which are declared as inner type of another, package-private annotation type. The following shows an example: @Retention( RetentionPolicy.RUNTIME ) /*package-private */ @interface Named { @Retention( RetentionPolicy.RUNTIME ) /*package-private */ @interface List { Named[] value(); } } The @List annotation is used as this on a type in the same package: public class Foo { @Named.List( @Named ) public void getBar() {} } I'm then trying to access the @Named annotation using reflection like this: Annotation listAnnotation = Foo.class.getMethod( "getBar" ).getAnnotations()[0]; Method method = listAnnotation.getClass().getMethod( "value" ); method.setAccessible( true ); //fails Annotation namedAnnotation = ( (Annotation[]) method.invoke( listAnnotation ) )[0]; This is the exception I get: IllegalAccessError: tried to access class com.example.Named from class com.sun.proxy.$Proxy3 at com.sun.proxy.$Proxy3.value(Unknown Source) Interestingly, this only occurs when the List annotation is declared as an inner type within the Named type; it works when the List annotation is a top-level package-private type (the Named annotation still being package-private) as well as when it is declared as an inner type within another package-private class. I first thought that this might be related to 8004260 ("dynamic proxy class should have the same Java language access as the proxy interfaces"), but the issue occurs on on JDK 7 as well. Is this a potential issue with the access check implementation or is something wrong here with the way I'm accessing the annotation member? Thanks for any help, --Gunnar From peter.levart at gmail.com Fri Jan 3 14:52:42 2014 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 03 Jan 2014 15:52:42 +0100 Subject: (reflect) Accessing members of inner annotations types In-Reply-To: References: Message-ID: <52C6CEBA.5090006@gmail.com> I think the problem is as follows... Annotations are implemented as Java dynamic Proxy classes. The generated proxy class for a package-private interface is created in the same package as the interface so that it has access to the interface. The top level interface can be package private, but nested interface (nested inside another interface) is by default public (all interface members are by default public). The consequence is that proxy class of an interface nested inside the interface is generated in com.sun.proxy package: package pkg; import java.lang.reflect.Proxy; public class ProxyTest { public static void main(String[] args) throws Exception { Class iClass = Proxy.getProxyClass(I.class.getClassLoader(), new Class[]{I.class}); Class nClass = Proxy.getProxyClass(I.class.getClassLoader(), new Class[]{I.N.class}); System.out.println("iClass: " + iClass); System.out.println("nClass: " + nClass); } } interface I { interface N {} } prints: iClass: class pkg.$Proxy0 nClass: class com.sun.proxy.$Proxy1 This is would be all right until such proxy class (com.sun.proxy.$Proxy1 in our example) has to access some package-private types in some specific package. This happens in your Named.List annotation implementation class. It implements a member method with the following signature: public Named[] value() {... ...where the return type is an array of a package-private type Named. Public class in com.sun.proxy package can not access package-private types in other packages! Your best solution currently is to implement the top-level annotations as public, or have all package-private annotations as top-level annotations. In future, I think the logic to calculate the package of a proxy class could be improved. It currently is as follows: String proxyPkg = null; // package to define proxy class in int accessFlags = Modifier.PUBLIC | Modifier.FINAL; /* * Record the package of a non-public proxy interface so that the * proxy class will be defined in the same package. Verify that * all non-public proxy interfaces are in the same package. */ for (Class intf : interfaces) { int flags = intf.getModifiers(); if (!Modifier.isPublic(flags)) { accessFlags = Modifier.FINAL; String name = intf.getName(); int n = name.lastIndexOf('.'); String pkg = ((n == -1) ? "" : name.substring(0, n + 1)); if (proxyPkg == null) { proxyPkg = pkg; } else if (!pkg.equals(proxyPkg)) { throw new IllegalArgumentException( "non-public interfaces from different packages"); } } } if (proxyPkg == null) { // if no non-public proxy interfaces, use com.sun.proxy package proxyPkg = ReflectUtil.PROXY_PACKAGE + "."; } ...It could be improved to take into account not only all interfaces being implemented but also all types that are encountered in interface method signatures. If any of those types is non-public than all of them should be in the same package and proxy class would be generated in that package... I can file a bug/rfe for this. Regards, Peter On 01/03/2014 02:14 PM, Gunnar Morling wrote: > Hi, > > In the course of running the Bean Validation TCK on JDK 8, I'm > investigating an issue around reflectively accessing members of annotations > which are declared as inner type of another, package-private annotation > type. > > The following shows an example: > > @Retention( RetentionPolicy.RUNTIME ) > /*package-private */ @interface Named { > > @Retention( RetentionPolicy.RUNTIME ) > /*package-private */ @interface List { > Named[] value(); > } > } > > The @List annotation is used as this on a type in the same package: > > public class Foo { > > @Named.List( @Named ) > public void getBar() {} > } > > I'm then trying to access the @Named annotation using reflection like this: > > Annotation listAnnotation = Foo.class.getMethod( "getBar" > ).getAnnotations()[0]; > > Method method = listAnnotation.getClass().getMethod( "value" ); > method.setAccessible( true ); > > //fails > Annotation namedAnnotation = ( (Annotation[]) method.invoke( > listAnnotation ) )[0]; > > This is the exception I get: > > IllegalAccessError: tried to access class com.example.Named from class > com.sun.proxy.$Proxy3 > at com.sun.proxy.$Proxy3.value(Unknown Source) > > Interestingly, this only occurs when the List annotation is declared as an > inner type within the Named type; it works when the List annotation is a > top-level package-private type (the Named annotation still being > package-private) as well as when it is declared as an inner type within > another package-private class. > > I first thought that this might be related to 8004260 ("dynamic proxy class > should have the same Java language access as the proxy interfaces"), but > the issue occurs on on JDK 7 as well. > > Is this a potential issue with the access check implementation or is > something wrong here with the way I'm accessing the annotation member? > > Thanks for any help, > > --Gunnar From peter.levart at gmail.com Fri Jan 3 15:55:28 2014 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 03 Jan 2014 16:55:28 +0100 Subject: (reflect) Accessing members of inner annotations types In-Reply-To: <52C6CEBA.5090006@gmail.com> References: <52C6CEBA.5090006@gmail.com> Message-ID: <52C6DD70.7070802@gmail.com> On 01/03/2014 03:52 PM, Peter Levart wrote: > This is would be all right until such proxy class > (com.sun.proxy.$Proxy1 in our example) has to access some > package-private types in some specific package. This happens in your > Named.List annotation implementation class. It implements a member > method with the following signature: > > public Named[] value() {... > > ...where the return type is an array of a package-private type Named. > Public class in com.sun.proxy package can not access package-private > types in other packages! Investigating this further, I found that the declaration itself is not problematic. It's the code in the implemented proxy method that tries to access the package-private Named class. Here's how the bytecode looks like for such proxy method: public final pkg.Named[] value() throws ; Signature: ()[Lpkg/Named; flags: ACC_PUBLIC, ACC_FINAL Code: stack=10, locals=2, args_size=1 0: aload_0 1: getfield #16 // Field java/lang/reflect/Proxy.h:Ljava/lang/reflect/InvocationHandler; 4: aload_0 5: getstatic #67 // Field m3:Ljava/lang/reflect/Method; 8: aconst_null 9: invokeinterface #28, 4 // InterfaceMethod java/lang/reflect/InvocationHandler.invoke:(Ljava/lang/Object;Ljava/lang/reflect/Method;[Ljava/lang/Object;)Ljava/lang/Object; * 14: checkcast #69 // class "[Lpkg/Named;"* 17: areturn 18: athrow 19: astore_1 20: new #42 // class java/lang/reflect/UndeclaredThrowableException 23: dup 24: aload_1 25: invokespecial #45 // Method java/lang/reflect/UndeclaredThrowableException."":(Ljava/lang/Throwable;)V 28: athrow Exception table: from to target type 0 18 18 Class java/lang/Error 0 18 18 Class java/lang/RuntimeException 0 18 19 Class java/lang/Throwable ... I think the error is thrown at the "checkcast" bytecode. The improvement suggested still holds. If the proxy class was generated in the specific package, error would not be thrown. But the requirement to take into account all implemented interfaces and all types encountered in the interface method signatures to calculate the package of proxy class it too strict. Only implemented interfaces and return types of all interface methods need to be taken into consideration. Here's an example of bytecode that illustrates how method parameters are passed to InvocationHandler: public final void doWith(pkg.Named[]) throws ; Signature: ([Lpkg/Named;)V flags: ACC_PUBLIC, ACC_FINAL Code: stack=10, locals=3, args_size=2 0: aload_0 1: getfield #16 // Field java/lang/reflect/Proxy.h:Ljava/lang/reflect/InvocationHandler; 4: aload_0 5: getstatic #57 // Field m3:Ljava/lang/reflect/Method; 8: iconst_1 9: anewarray #22 // class java/lang/Object 12: dup 13: iconst_0 14: aload_1 15: aastore 16: invokeinterface #28, 4 // InterfaceMethod java/lang/reflect/InvocationHandler.invoke:(Ljava/lang/Object;Ljava/lang/reflect/Method;[Ljava/lang/Object;)Ljava/lang/Object; 21: pop 22: return 23: athrow 24: astore_2 25: new #42 // class java/lang/reflect/UndeclaredThrowableException 28: dup 29: aload_2 30: invokespecial #45 // Method java/lang/reflect/UndeclaredThrowableException."":(Ljava/lang/Throwable;)V 33: athrow Exception table: from to target type 0 23 23 Class java/lang/Error 0 23 23 Class java/lang/RuntimeException 0 23 24 Class java/lang/Throwable ... as can be seen, no parameter types are referenced in order to wrap the parameters with Object[] array. Regards, Peter From sean.coffey at oracle.com Fri Jan 3 16:47:54 2014 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Fri, 03 Jan 2014 16:47:54 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20140103164849.42D2E62FFC@hg.openjdk.java.net> Changeset: 46c727d6ecc2 Author: aefimov Date: 2013-12-30 16:46 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/46c727d6ecc2 8025051: Update resource files for TimeZone display names Reviewed-by: okutsu, mfang ! src/share/classes/sun/util/resources/de/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/es/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/fr/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/it/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/ko/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/pt/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/sv/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_TW.java ! test/java/util/Calendar/GenericTimeZoneNamesTest.sh ! test/sun/util/resources/TimeZone/Bug6317929.java + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNamesTest.java + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_de.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_de_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_es.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_es_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_fr.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_fr_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_it.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_it_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_ja.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_ja_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_ko.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_ko_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_pt_BR.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_pt_BR_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_sv.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_sv_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_zh_CN.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_zh_CN_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_zh_TW.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_zh_TW_short.properties Changeset: c0970860803e Author: coffeys Date: 2014-01-03 16:45 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c0970860803e Merge From tbuktu at hotmail.com Fri Jan 3 17:23:47 2014 From: tbuktu at hotmail.com (Tim Buktu) Date: Fri, 3 Jan 2014 18:23:47 +0100 Subject: Update on 8014320 In-Reply-To: <970CC281-CFD3-4A1D-AA1E-F78E97EA38F5@oracle.com> References: <970CC281-CFD3-4A1D-AA1E-F78E97EA38F5@oracle.com> Message-ID: > On Dec 23, 2013, at 11:37 AM, Tim Buktu wrote: >> * Compact storage of DFT vectors. At the moment, they are stored as >> numbers modulo 2^2^(n+1) when (2^2^n)+1 would suffice. This will save >> memory and may speed up the DFT and IDFT steps. It did indeed improve performance. The latest patched BigInteger.java is at https://github.com/tbuktu/bigint/blob/034daddfad1fd528daa363ed026a58b3ebe389b9/src/main/java/java/math/BigInteger.java >> * Maybe add a multiplyParallel() method, now that dft() and idft() use >> Bailey's algorithm which should make them easy to parallelize. I checked an initial implementation into a separate Git branch: https://github.com/tbuktu/bigint/blob/ef47eef52017c0db2cdda70dbdeda9fe3c8d0861/src/main/java/java/math/BigInteger.java Tim From huizhe.wang at oracle.com Fri Jan 3 18:07:13 2014 From: huizhe.wang at oracle.com (huizhe wang) Date: Fri, 03 Jan 2014 10:07:13 -0800 Subject: RFR (JAXP): 8027359: XML parser returns incorrect parsing results Message-ID: <52C6FC51.7090305@oracle.com> Hi, This is an issue with the XML 1.1 scanner. Any reference to the data buffer needs to be removed, that is, the content copied, when the buffer is reloaded with new data. The fix is to duplicate the solution from the XML 1.0 scanner. webrev: http://cr.openjdk.java.net/~joehw/jdk9/8027359/webrev/ Thanks, Joe From joe.darcy at oracle.com Fri Jan 3 18:23:26 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 03 Jan 2014 10:23:26 -0800 Subject: JDK 9 RFR of JDK-8029561: Optimization in Integer to string conversion In-Reply-To: References: Message-ID: <52C7001E.1090501@oracle.com> On 01/02/2014 11:44 AM, Brian Burkhalter wrote: > Following up from this thread of last week > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024162.html > > with respect to https://bugs.openjdk.java.net/browse/JDK-8029561. > > The change being suggested in this review request is merely to remove the FIXME comment > > --- a/src/share/classes/java/lang/Integer.java Mon Dec 30 16:34:06 2013 +0400 > +++ b/src/share/classes/java/lang/Integer.java Thu Jan 02 11:21:00 2014 -0800 > @@ -376,9 +376,6 @@ > // JIT case the dispatch overhead doesn't exist and the > // "trick" is considerably faster than the classic code. > // > - // TODO-FIXME: convert (x * 52429) into the equiv shift-add > - // sequence. > - // > // RE: Division by Invariant Integers using Multiplication > // T Gralund, P Montgomery > // ACM PLDI 1994 > > since the code change proposed in the issue report did not show any performance improvement. > > Thanks, > > Brian Sounds good to me; thanks, -Joe From brian.burkhalter at oracle.com Fri Jan 3 19:00:51 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 3 Jan 2014 11:00:51 -0800 Subject: JDK 9 RFR of 8030814: Long.parseUnsignedLong should throw exception on too large input Message-ID: <20C5A625-0581-4B4A-A51F-73FE6D87388A@oracle.com> Issue: https://bugs.openjdk.java.net/browse/JDK-8030814 webrev: http://cr.openjdk.java.net/~bpb/8030814/webrev.2/ This review request follows from the discussion of last month in this thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024031.html The contributed patch before my minor tweaking of it is here http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024110.html with a detailed explanation of its logic here http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024136.html I added to the java/lang/Long/Unsigned JTREG test the case from the issue report as well as some other cases which exercise both sides of the A v B overflow test. Thanks, Brian From joe.darcy at oracle.com Fri Jan 3 20:23:43 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 03 Jan 2014 12:23:43 -0800 Subject: JDK 9 RFR of 8030814: Long.parseUnsignedLong should throw exception on too large input In-Reply-To: <20C5A625-0581-4B4A-A51F-73FE6D87388A@oracle.com> References: <20C5A625-0581-4B4A-A51F-73FE6D87388A@oracle.com> Message-ID: <52C71C4F.7090808@oracle.com> Hi Brian, I think more explanation of how the new code works needs to be included in the code (and the commented out code should be deleted). For the test, I would expect something with a bit simpler structure, but perhaps I don't fully understand the boundary cases of the new code. -Joe On 01/03/2014 11:00 AM, Brian Burkhalter wrote: > Issue: https://bugs.openjdk.java.net/browse/JDK-8030814 > webrev: http://cr.openjdk.java.net/~bpb/8030814/webrev.2/ > > This review request follows from the discussion of last month in this thread: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024031.html > > The contributed patch before my minor tweaking of it is here > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024110.html > > with a detailed explanation of its logic here > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024136.html > > I added to the java/lang/Long/Unsigned JTREG test the case from the issue report as well as some other cases which exercise both sides of the A v B overflow test. > > Thanks, > > Brian From joe.darcy at oracle.com Fri Jan 3 19:39:28 2014 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 03 Jan 2014 19:39:28 +0000 Subject: hg: jdk8/tl/jdk: 8030212: Several api.java.util.stream tests got "NaN" value instead of "Infinity" or "-Infinity" Message-ID: <20140103193957.9AB6C6235D@hg.openjdk.java.net> Changeset: 68de5492a06d Author: darcy Date: 2014-01-03 11:38 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/68de5492a06d 8030212: Several api.java.util.stream tests got "NaN" value instead of "Infinity" or "-Infinity" Reviewed-by: mduigou, psandoz ! src/share/classes/java/util/DoubleSummaryStatistics.java ! src/share/classes/java/util/stream/Collectors.java ! src/share/classes/java/util/stream/DoublePipeline.java ! test/java/util/stream/TestDoubleSumAverage.java From lance.andersen at oracle.com Fri Jan 3 22:04:51 2014 From: lance.andersen at oracle.com (Lance @ Oracle) Date: Fri, 3 Jan 2014 17:04:51 -0500 Subject: RFR (JAXP): 8027359: XML parser returns incorrect parsing results In-Reply-To: <52C6FC51.7090305@oracle.com> References: <52C6FC51.7090305@oracle.com> Message-ID: Looks ok joe 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 Sent from my iPad On Jan 3, 2014, at 1:07 PM, huizhe wang wrote: > Hi, > > This is an issue with the XML 1.1 scanner. Any reference to the data buffer needs to be removed, that is, the content copied, when the buffer is reloaded with new data. The fix is to duplicate the solution from the XML 1.0 scanner. > > webrev: > http://cr.openjdk.java.net/~joehw/jdk9/8027359/webrev/ > > Thanks, > Joe > From paul.sandoz at oracle.com Mon Jan 6 10:05:02 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 6 Jan 2014 11:05:02 +0100 Subject: RFR 8031187: DoubleStream.count is incorrect for a stream containing > Integer.MAX_VALUE elements Message-ID: <62587150-5EDA-4C8D-A2D0-E0EE0D6C32B6@oracle.com> Hi, Please review the following which fixes an embarrassing bug in DoubleStream.count: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8031187-DoubleStream-count/webrev/ I included a test CountLargeTest that counts up to Integer.MAX_VALUE + 1. On my mac book this takes about 27s to run from the jtreg command, on a slow machine it could be longer. I would like to retain this test but it does not need to be run regularly, how can i annotate the test to declare that? Also, i think this fix should go back to 8. The risk is low. Thanks, Paul. From martinrb at google.com Mon Jan 6 17:25:02 2014 From: martinrb at google.com (Martin Buchholz) Date: Mon, 6 Jan 2014 09:25:02 -0800 Subject: JDK 9 RFR - 8031142 [was: Re: Using @implSpec in AbstractMap, AbstractCollection, AbstractList, etc] In-Reply-To: <4E57D4E2-B674-431F-9CBC-985E2A275FF3@oracle.com> References: <52BED67D.3050005@cs.oswego.edu> <42B83A56-82E5-4991-A87A-22BB99AB23D2@oracle.com> <52CADE0C.8070700@oracle.com> <4E57D4E2-B674-431F-9CBC-985E2A275FF3@oracle.com> Message-ID: On Mon, Jan 6, 2014 at 9:19 AM, Mike Duigou wrote: > If you navigate through > http://cr.openjdk.java.net/~chegar/8031142/specdiff/java/util/package-summary.htmlit shows just the relevant diffs. It appears that the specdiff was > generated without an explicit --includes option which results in all the > extra chaff. > > Thanks. I see a java/ subdirectory now, but I swear it wasn't there 17 minutes ago. From huizhe.wang at oracle.com Mon Jan 6 03:02:35 2014 From: huizhe.wang at oracle.com (huizhe wang) Date: Sun, 05 Jan 2014 19:02:35 -0800 Subject: RFR (JAXP): 8027359: XML parser returns incorrect parsing results In-Reply-To: References: <52C6FC51.7090305@oracle.com> Message-ID: <52CA1CCB.1060402@oracle.com> Thanks! On 1/3/2014 2:04 PM, Lance @ Oracle wrote: > Looks ok joe > > > 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 > Sent from my iPad > > On Jan 3, 2014, at 1:07 PM, huizhe wang > wrote: > >> Hi, >> >> This is an issue with the XML 1.1 scanner. Any reference to the data >> buffer needs to be removed, that is, the content copied, when the >> buffer is reloaded with new data. The fix is to duplicate the >> solution from the XML 1.0 scanner. >> >> webrev: >> http://cr.openjdk.java.net/~joehw/jdk9/8027359/webrev/ >> >> >> Thanks, >> Joe >> From roger.riggs at oracle.com Mon Jan 6 19:09:14 2014 From: roger.riggs at oracle.com (roger riggs) Date: Mon, 06 Jan 2014 14:09:14 -0500 Subject: RFR java.time.Duration spec correction (8031103) Message-ID: <52CAFF5A.4040106@oracle.com> Please review this minor specification correction to the java.time.Duration.toDays() and toHours() methods. Only the javadoc is corrected, no code or tests are affected. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-duration-javadoc-8031103/ Thanks, Roger JDK-8031103 java.time.Duration has wrong Javadoc Comments in toDays() and toHours() From chris.hegarty at oracle.com Mon Jan 6 18:03:45 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 6 Jan 2014 18:03:45 +0000 Subject: JDK 9 RFR - 8031142 [was: Re: Using @implSpec in AbstractMap, AbstractCollection, AbstractList, etc] In-Reply-To: References: <52BED67D.3050005@cs.oswego.edu> <42B83A56-82E5-4991-A87A-22BB99AB23D2@oracle.com> <52CADE0C.8070700@oracle.com> <4E57D4E2-B674-431F-9CBC-985E2A275FF3@oracle.com> Message-ID: On 6 Jan 2014, at 17:25, Martin Buchholz wrote: > > On Mon, Jan 6, 2014 at 9:19 AM, Mike Duigou wrote: > If you navigate through http://cr.openjdk.java.net/~chegar/8031142/specdiff/java/util/package-summary.html it shows just the relevant diffs. It appears that the specdiff was generated without an explicit --includes option which results in all the extra chaff. > > > Thanks. I see a java/ subdirectory now, but I swear it wasn't there 17 minutes ago. It was possibly still uploading when I sent the mail. Sorry for the confusion. I created a large spec diff, all java.** and javax.**, to ensure that this change didn?t inadvertently affect anything else. -Chris. From joe.darcy at oracle.com Mon Jan 6 19:28:29 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 06 Jan 2014 11:28:29 -0800 Subject: RFR 8031187: DoubleStream.count is incorrect for a stream containing > Integer.MAX_VALUE elements In-Reply-To: <62587150-5EDA-4C8D-A2D0-E0EE0D6C32B6@oracle.com> References: <62587150-5EDA-4C8D-A2D0-E0EE0D6C32B6@oracle.com> Message-ID: <52CB03DD.3060907@oracle.com> Looks good Paul; if not 8 GA, than backported to an early 8 update. Cheers, -Joe On 01/06/2014 02:05 AM, Paul Sandoz wrote: > Hi, > > Please review the following which fixes an embarrassing bug in DoubleStream.count: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8031187-DoubleStream-count/webrev/ > > I included a test CountLargeTest that counts up to Integer.MAX_VALUE + 1. On my mac book this takes about 27s to run from the jtreg command, on a slow machine it could be longer. I would like to retain this test but it does not need to be run regularly, how can i annotate the test to declare that? > > Also, i think this fix should go back to 8. The risk is low. > > Thanks, > Paul. > > From Lance.Andersen at oracle.com Mon Jan 6 19:29:15 2014 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Mon, 6 Jan 2014 14:29:15 -0500 Subject: RFR java.time.Duration spec correction (8031103) In-Reply-To: <52CAFF5A.4040106@oracle.com> References: <52CAFF5A.4040106@oracle.com> Message-ID: looks fine Roger On Jan 6, 2014, at 2:09 PM, roger riggs wrote: > Please review this minor specification correction to the java.time.Duration.toDays() and > toHours() methods. Only the javadoc is corrected, no code or tests are affected. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-duration-javadoc-8031103/ > > Thanks, Roger > > JDK-8031103 java.time.Duration has wrong Javadoc Comments in toDays() and toHours() > -------------- next part -------------- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From chris.hegarty at oracle.com Mon Jan 6 18:11:07 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 6 Jan 2014 18:11:07 +0000 Subject: JDK 9 RFR - 8031142 [was: Re: Using @implSpec in AbstractMap, AbstractCollection, AbstractList, etc] In-Reply-To: References: <52BED67D.3050005@cs.oswego.edu> <42B83A56-82E5-4991-A87A-22BB99AB23D2@oracle.com> <52CADE0C.8070700@oracle.com> Message-ID: On 6 Jan 2014, at 17:05, Martin Buchholz wrote: > On Mon, Jan 6, 2014 at 8:47 AM, Chris Hegarty wrote: > Part 2... > > JDK 9 RFR - 8031142: AbstractCollection and AbstractList should specify their default implementation using @implSpec > > http://cr.openjdk.java.net/~chegar/8031142/webrev/ > http://cr.openjdk.java.net/~chegar/8031142/specdiff/ > > Is that specdiff link what you want? I just get a giant tree with javax files in it... > > --- > > In a sane language, the AbstractFoo classes would be traits - they should never contribute to the *specification* of a concrete class, only to its implementation. Therefore, in Java, all of the methods should have precisely an {@inheritDoc} followed by an @implSpec. In particular, for AbstractCollection.toArray I see: > > 114 /** > 115 * {@inheritDoc} > 116 * > 117 *

This method is equivalent to: > 118 * > 119 *

 {@code
>  120      * List list = new ArrayList(size());
>  121      * for (E e : this)
>  122      *     list.add(e);
>  123      * return list.toArray();
>  124      * }
> 125 * > 126 * @implSpec > 127 * This implementation returns an array containing all the elements > 128 * returned by this collection's iterator, in the same order, stored in > 129 * consecutive elements of the array, starting with index {@code 0}. > 130 * The length of the returned array is equal to the number of elements > 131 * returned by the iterator, even if the size of this collection changes > 132 * during iteration, as might happen if the collection permits > 133 * concurrent modification during iteration. The {@code size} method is > 134 * called only as an optimization hint; the correct result is returned > 135 * even if the iterator returns a different number of elements. > 136 */ > 137 public Object[] toArray() { > > which must be wrong. Either the sample code should be moved into the @implSpec or promoted to Collection.java.toArray. The introduction of default methods ("not quite traits") makes the situation murkier. Looking more closely, the exact wording cannot be promoted to Collection.java because the behavior may in fact differ from the code sample. size() may or may not be called. toArray implementation is more likely to be atomic, etc... So move it into the @implSpec somehow? I wasn?t quite sure about this. ?This method is equivalent to, or, as if the following was invoked ?? without actually specifying the actual implementation. But I agree, AbstractFoo should only have @inheritDoc or @implSpec. Let me see what happens when I move it into @implSpec. -Chris. From daniel.fuchs at oracle.com Mon Jan 6 18:40:18 2014 From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com) Date: Mon, 06 Jan 2014 18:40:18 +0000 Subject: hg: jdk8/tl/jdk: 8030850: Setting .level=FINEST in logging configuration file doesn't work Message-ID: <20140106184132.99103623E5@hg.openjdk.java.net> Changeset: d77a1c9fd5b8 Author: dfuchs Date: 2013-12-22 11:20 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d77a1c9fd5b8 8030850: Setting .level=FINEST in logging configuration file doesn't work Summary: setLevel(INFO) was called too early on root logger, causing the value found in configuration file to be later ignored. Reviewed-by: mchung ! src/share/classes/java/util/logging/LogManager.java + test/java/util/logging/RootLogger/RootLevelInConfigFile.java + test/java/util/logging/RootLogger/rootlogger.properties From mike.duigou at oracle.com Mon Jan 6 17:19:37 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 6 Jan 2014 09:19:37 -0800 Subject: JDK 9 RFR - 8031142 [was: Re: Using @implSpec in AbstractMap, AbstractCollection, AbstractList, etc] In-Reply-To: References: <52BED67D.3050005@cs.oswego.edu> <42B83A56-82E5-4991-A87A-22BB99AB23D2@oracle.com> <52CADE0C.8070700@oracle.com> Message-ID: <4E57D4E2-B674-431F-9CBC-985E2A275FF3@oracle.com> If you navigate through http://cr.openjdk.java.net/~chegar/8031142/specdiff/java/util/package-summary.html it shows just the relevant diffs. It appears that the specdiff was generated without an explicit --includes option which results in all the extra chaff. Mike On Jan 6 2014, at 09:05 , Martin Buchholz wrote: > > > > On Mon, Jan 6, 2014 at 8:47 AM, Chris Hegarty wrote: > Part 2... > > JDK 9 RFR - 8031142: AbstractCollection and AbstractList should specify their default implementation using @implSpec > > http://cr.openjdk.java.net/~chegar/8031142/webrev/ > http://cr.openjdk.java.net/~chegar/8031142/specdiff/ > > Is that specdiff link what you want? I just get a giant tree with javax files in it... > > --- > > In a sane language, the AbstractFoo classes would be traits - they should never contribute to the *specification* of a concrete class, only to its implementation. Therefore, in Java, all of the methods should have precisely an {@inheritDoc} followed by an @implSpec. In particular, for AbstractCollection.toArray I see: > > 114 /** > 115 * {@inheritDoc} > 116 * > 117 *

This method is equivalent to: > 118 * > 119 *

 {@code
>  120      * List list = new ArrayList(size());
>  121      * for (E e : this)
>  122      *     list.add(e);
>  123      * return list.toArray();
>  124      * }
> 125 * > 126 * @implSpec > 127 * This implementation returns an array containing all the elements > 128 * returned by this collection's iterator, in the same order, stored in > 129 * consecutive elements of the array, starting with index {@code 0}. > 130 * The length of the returned array is equal to the number of elements > 131 * returned by the iterator, even if the size of this collection changes > 132 * during iteration, as might happen if the collection permits > 133 * concurrent modification during iteration. The {@code size} method is > 134 * called only as an optimization hint; the correct result is returned > 135 * even if the iterator returns a different number of elements. > 136 */ > 137 public Object[] toArray() { > > which must be wrong. Either the sample code should be moved into the @implSpec or promoted to Collection.java.toArray. The introduction of default methods ("not quite traits") makes the situation murkier. Looking more closely, the exact wording cannot be promoted to Collection.java because the behavior may in fact differ from the code sample. size() may or may not be called. toArray implementation is more likely to be atomic, etc... So move it into the @implSpec somehow... From chris.hegarty at oracle.com Mon Jan 6 16:47:08 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 06 Jan 2014 16:47:08 +0000 Subject: JDK 9 RFR - 8031142 [was: Re: Using @implSpec in AbstractMap, AbstractCollection, AbstractList, etc] In-Reply-To: References: <52BED67D.3050005@cs.oswego.edu> <42B83A56-82E5-4991-A87A-22BB99AB23D2@oracle.com> Message-ID: <52CADE0C.8070700@oracle.com> Part 2... JDK 9 RFR - 8031142: AbstractCollection and AbstractList should specify their default implementation using @implSpec http://cr.openjdk.java.net/~chegar/8031142/webrev/ http://cr.openjdk.java.net/~chegar/8031142/specdiff/ -Chris. On 06/01/14 15:37, Mike Duigou wrote: > Coming in late but this looks like a very good change to me as well. > > Mike > > On Jan 2 2014, at 23:06 , Chris Hegarty wrote: > >> On 3 Jan 2014, at 02:14, Martin Buchholz wrote: >> >>> OK, as you wish - this change is clear progress! >> >> Thanks Martin. >> >> I pushed the AbstractMap changes to JDK 8 and JDK 9. >> >> 8031142 now tracks the changes to AbstractCollection and AbstractList >> https://bugs.openjdk.java.net/browse/JDK-8031142 >> >> -Chris. >> >>> >>> On Thu, Jan 2, 2014 at 3:48 PM, Chris Hegarty wrote: >>> >>> On 2 Jan 2014, at 22:02, Martin Buchholz wrote: >>> >>>> As the subject says, these changes should be applied to all of the so-called "skeletal implementations" in java.util. >>> >>> You may have noticed that I used a different subject line in the bug ;-) >>> >>>> There is a *lot* of (previously unavoidable (painful memories)) javadoc duplication in java.util, some of which could now be undone. >>> >>> If you are agreeable, then I'd like to push just the AbstractMap changes as they are to JDK 9 and JDK 8. We can then immediately follow up with the additional skeletal types, under a different bug number for JDK 9, and evaluate the feasibility of putting it into JDK 8. >>> >>> This is just a matter of timing, it is getting very late in the JDK 8 release cycle. There is a specific problem in CHM stemming from AbstractMap, which I would like to resolve without growing the scope of the changes and risk. >>> >>> -Chris. >>> >>>> >>>> >>>> On Thu, Jan 2, 2014 at 8:03 AM, Chris Hegarty wrote: >>>> Hi Doug, >>>> >>>> I agree with your changes to AbstractMap. I?ve taken your patch, removed the superfluous paragraph tags, and generated a webrev. >>>> http://cr.openjdk.java.net/~chegar/AbstractMap_implSpec/webrev/ >>>> >>>> I also ran specdiff to see what else may be impacted by this. It shows that the only spec changes are to AbstractMap itself, and to ConcurrentHashMap size and isEmpty. What we want. >>>> http://cr.openjdk.java.net/~chegar/AbstractMap_implSpec/specdiff/overview-summary.html >>>> >>>> I know it is late in the JDK 8 game, but I see this as a serious bug in the documentation, and it needs to be addressed. >>>> >>>> Conservatively, one could argue that minimally pasting the appropriate specs into CHM size and isEmpty would be sufficient to resolve the problem, but I think your first proposal is a more complete solution. Given the above specdiff, I would be confident to request this change for inclusion in JDK 8. >>>> >>>> I filed the following bug to track this issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8031133 >>>> >>>> -Chris. >>>> >>>> On 28 Dec 2013, at 13:47, Doug Lea
wrote: >>>> >>>>> >>>>> There might have been some mis-communication about whether the >>>>> new @implSpec tag would be used in existing java.util.AbstractX >>>>> classes. I had assumed that it would be, and pulled out a few >>>>> javadoc overrides in java.util.concurrent classes that would >>>>> not be needed if @implSpec were used. With @implSpec, you do >>>>> not need to paste in the interface-level spec in an overridden >>>>> method just to suppress inclusion of (incorrect) doc comments >>>>> about the default implementation. >>>>> >>>>> Is it too late to do this for JDK8? It is easy -- just add a line >>>>> with @implSpec for each defined method. AbstractMap diffs >>>>> below. (They could be tweaked to get rid of now-unnecessary >>>>> paragraph markup, but I don't think this would improve display.) >>>>> >>>>> If this isn't done, then minimally we'd need to paste in >>>>> interface-level specs in ConcurrentHashMap.{size, isEmpty} >>>>> since the JDK8 javadocs as they stand are wrong. There >>>>> may be other cases as well. >>>>> >>>>> ... >>>>> >>>>> >>>>> diff -r 8bc258c021a3 src/share/classes/java/util/AbstractMap.java >>>>> --- a/src/share/classes/java/util/AbstractMap.java Thu Nov 21 09:23:03 2013 -0800 >>>>> +++ b/src/share/classes/java/util/AbstractMap.java Sat Dec 28 08:33:42 2013 -0500 >>>>> @@ -78,6 +78,7 @@ >>>>> /** >>>>> * {@inheritDoc} >>>>> * >>>>> + * @implSpec >>>>> *

This implementation returns entrySet().size(). >>>>> */ >>>>> public int size() { >>>>> @@ -87,6 +88,7 @@ >>>>> /** >>>>> * {@inheritDoc} >>>>> * >>>>> + * @implSpec >>>>> *

This implementation returns size() == 0. >>>>> */ >>>>> public boolean isEmpty() { >>>>> @@ -96,6 +98,7 @@ >>>>> /** >>>>> * {@inheritDoc} >>>>> * >>>>> + * @implSpec >>>>> *

This implementation iterates over entrySet() searching >>>>> * for an entry with the specified value. If such an entry is found, >>>>> * true is returned. If the iteration terminates without >>>>> @@ -126,6 +129,7 @@ >>>>> /** >>>>> * {@inheritDoc} >>>>> * >>>>> + * @implSpec >>>>> *

This implementation iterates over entrySet() searching >>>>> * for an entry with the specified key. If such an entry is found, >>>>> * true is returned. If the iteration terminates without >>>>> @@ -157,6 +161,7 @@ >>>>> /** >>>>> * {@inheritDoc} >>>>> * >>>>> + * @implSpec >>>>> *

This implementation iterates over entrySet() searching >>>>> * for an entry with the specified key. If such an entry is found, >>>>> * the entry's value is returned. If the iteration terminates without >>>>> @@ -191,6 +196,7 @@ >>>>> /** >>>>> * {@inheritDoc} >>>>> * >>>>> + * @implSpec >>>>> *

This implementation always throws an >>>>> * UnsupportedOperationException. >>>>> * >>>>> @@ -206,6 +212,7 @@ >>>>> /** >>>>> * {@inheritDoc} >>>>> * >>>>> + * @implSpec >>>>> *

This implementation iterates over entrySet() searching for an >>>>> * entry with the specified key. If such an entry is found, its value is >>>>> * obtained with its getValue operation, the entry is removed >>>>> @@ -255,6 +262,7 @@ >>>>> /** >>>>> * {@inheritDoc} >>>>> * >>>>> + * @implSpec >>>>> *

This implementation iterates over the specified map's >>>>> * entrySet() collection, and calls this map's put >>>>> * operation once for each entry returned by the iteration. >>>>> @@ -276,6 +284,7 @@ >>>>> /** >>>>> * {@inheritDoc} >>>>> * >>>>> + * @implSpec >>>>> *

This implementation calls entrySet().clear(). >>>>> * >>>>> *

Note that this implementation throws an >>>>> @@ -302,6 +311,7 @@ >>>>> /** >>>>> * {@inheritDoc} >>>>> * >>>>> + * @implSpec >>>>> *

This implementation returns a set that subclasses {@link AbstractSet}. >>>>> * The subclass's iterator method returns a "wrapper object" over this >>>>> * map's entrySet() iterator. The size method >>>>> @@ -358,6 +368,7 @@ >>>>> /** >>>>> * {@inheritDoc} >>>>> * >>>>> + * @implSpec >>>>> *

This implementation returns a collection that subclasses {@link >>>>> * AbstractCollection}. The subclass's iterator method returns a >>>>> * "wrapper object" over this map's entrySet() iterator. >>>>> @@ -425,6 +436,7 @@ >>>>> * equals method works properly across different implementations >>>>> * of the Map interface. >>>>> * >>>>> + * @implSpec >>>>> *

This implementation first checks if the specified object is this map; >>>>> * if so it returns true. Then, it checks if the specified >>>>> * object is a map whose size is identical to the size of this map; if >>>>> @@ -478,6 +490,7 @@ >>>>> * m1 and m2, as required by the general contract of >>>>> * {@link Object#hashCode}. >>>>> * >>>>> + * @implSpec >>>>> *

This implementation iterates over entrySet(), calling >>>>> * {@link Map.Entry#hashCode hashCode()} on each element (entry) in the >>>>> * set, and adding up the results. >>>> >>>> >>> >> > From mike.duigou at oracle.com Mon Jan 6 15:37:41 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 6 Jan 2014 07:37:41 -0800 Subject: Using @implSpec in AbstractMap, AbstractCollection, AbstractList, etc In-Reply-To: <42B83A56-82E5-4991-A87A-22BB99AB23D2@oracle.com> References: <52BED67D.3050005@cs.oswego.edu> <42B83A56-82E5-4991-A87A-22BB99AB23D2@oracle.com> Message-ID: Coming in late but this looks like a very good change to me as well. Mike On Jan 2 2014, at 23:06 , Chris Hegarty wrote: > On 3 Jan 2014, at 02:14, Martin Buchholz wrote: > >> OK, as you wish - this change is clear progress! > > Thanks Martin. > > I pushed the AbstractMap changes to JDK 8 and JDK 9. > > 8031142 now tracks the changes to AbstractCollection and AbstractList > https://bugs.openjdk.java.net/browse/JDK-8031142 > > -Chris. > >> >> On Thu, Jan 2, 2014 at 3:48 PM, Chris Hegarty wrote: >> >> On 2 Jan 2014, at 22:02, Martin Buchholz wrote: >> >>> As the subject says, these changes should be applied to all of the so-called "skeletal implementations" in java.util. >> >> You may have noticed that I used a different subject line in the bug ;-) >> >>> There is a *lot* of (previously unavoidable (painful memories)) javadoc duplication in java.util, some of which could now be undone. >> >> If you are agreeable, then I'd like to push just the AbstractMap changes as they are to JDK 9 and JDK 8. We can then immediately follow up with the additional skeletal types, under a different bug number for JDK 9, and evaluate the feasibility of putting it into JDK 8. >> >> This is just a matter of timing, it is getting very late in the JDK 8 release cycle. There is a specific problem in CHM stemming from AbstractMap, which I would like to resolve without growing the scope of the changes and risk. >> >> -Chris. >> >>> >>> >>> On Thu, Jan 2, 2014 at 8:03 AM, Chris Hegarty wrote: >>> Hi Doug, >>> >>> I agree with your changes to AbstractMap. I?ve taken your patch, removed the superfluous paragraph tags, and generated a webrev. >>> http://cr.openjdk.java.net/~chegar/AbstractMap_implSpec/webrev/ >>> >>> I also ran specdiff to see what else may be impacted by this. It shows that the only spec changes are to AbstractMap itself, and to ConcurrentHashMap size and isEmpty. What we want. >>> http://cr.openjdk.java.net/~chegar/AbstractMap_implSpec/specdiff/overview-summary.html >>> >>> I know it is late in the JDK 8 game, but I see this as a serious bug in the documentation, and it needs to be addressed. >>> >>> Conservatively, one could argue that minimally pasting the appropriate specs into CHM size and isEmpty would be sufficient to resolve the problem, but I think your first proposal is a more complete solution. Given the above specdiff, I would be confident to request this change for inclusion in JDK 8. >>> >>> I filed the following bug to track this issue: >>> https://bugs.openjdk.java.net/browse/JDK-8031133 >>> >>> -Chris. >>> >>> On 28 Dec 2013, at 13:47, Doug Lea

wrote: >>> >>>> >>>> There might have been some mis-communication about whether the >>>> new @implSpec tag would be used in existing java.util.AbstractX >>>> classes. I had assumed that it would be, and pulled out a few >>>> javadoc overrides in java.util.concurrent classes that would >>>> not be needed if @implSpec were used. With @implSpec, you do >>>> not need to paste in the interface-level spec in an overridden >>>> method just to suppress inclusion of (incorrect) doc comments >>>> about the default implementation. >>>> >>>> Is it too late to do this for JDK8? It is easy -- just add a line >>>> with @implSpec for each defined method. AbstractMap diffs >>>> below. (They could be tweaked to get rid of now-unnecessary >>>> paragraph markup, but I don't think this would improve display.) >>>> >>>> If this isn't done, then minimally we'd need to paste in >>>> interface-level specs in ConcurrentHashMap.{size, isEmpty} >>>> since the JDK8 javadocs as they stand are wrong. There >>>> may be other cases as well. >>>> >>>> ... >>>> >>>> >>>> diff -r 8bc258c021a3 src/share/classes/java/util/AbstractMap.java >>>> --- a/src/share/classes/java/util/AbstractMap.java Thu Nov 21 09:23:03 2013 -0800 >>>> +++ b/src/share/classes/java/util/AbstractMap.java Sat Dec 28 08:33:42 2013 -0500 >>>> @@ -78,6 +78,7 @@ >>>> /** >>>> * {@inheritDoc} >>>> * >>>> + * @implSpec >>>> *

This implementation returns entrySet().size(). >>>> */ >>>> public int size() { >>>> @@ -87,6 +88,7 @@ >>>> /** >>>> * {@inheritDoc} >>>> * >>>> + * @implSpec >>>> *

This implementation returns size() == 0. >>>> */ >>>> public boolean isEmpty() { >>>> @@ -96,6 +98,7 @@ >>>> /** >>>> * {@inheritDoc} >>>> * >>>> + * @implSpec >>>> *

This implementation iterates over entrySet() searching >>>> * for an entry with the specified value. If such an entry is found, >>>> * true is returned. If the iteration terminates without >>>> @@ -126,6 +129,7 @@ >>>> /** >>>> * {@inheritDoc} >>>> * >>>> + * @implSpec >>>> *

This implementation iterates over entrySet() searching >>>> * for an entry with the specified key. If such an entry is found, >>>> * true is returned. If the iteration terminates without >>>> @@ -157,6 +161,7 @@ >>>> /** >>>> * {@inheritDoc} >>>> * >>>> + * @implSpec >>>> *

This implementation iterates over entrySet() searching >>>> * for an entry with the specified key. If such an entry is found, >>>> * the entry's value is returned. If the iteration terminates without >>>> @@ -191,6 +196,7 @@ >>>> /** >>>> * {@inheritDoc} >>>> * >>>> + * @implSpec >>>> *

This implementation always throws an >>>> * UnsupportedOperationException. >>>> * >>>> @@ -206,6 +212,7 @@ >>>> /** >>>> * {@inheritDoc} >>>> * >>>> + * @implSpec >>>> *

This implementation iterates over entrySet() searching for an >>>> * entry with the specified key. If such an entry is found, its value is >>>> * obtained with its getValue operation, the entry is removed >>>> @@ -255,6 +262,7 @@ >>>> /** >>>> * {@inheritDoc} >>>> * >>>> + * @implSpec >>>> *

This implementation iterates over the specified map's >>>> * entrySet() collection, and calls this map's put >>>> * operation once for each entry returned by the iteration. >>>> @@ -276,6 +284,7 @@ >>>> /** >>>> * {@inheritDoc} >>>> * >>>> + * @implSpec >>>> *

This implementation calls entrySet().clear(). >>>> * >>>> *

Note that this implementation throws an >>>> @@ -302,6 +311,7 @@ >>>> /** >>>> * {@inheritDoc} >>>> * >>>> + * @implSpec >>>> *

This implementation returns a set that subclasses {@link AbstractSet}. >>>> * The subclass's iterator method returns a "wrapper object" over this >>>> * map's entrySet() iterator. The size method >>>> @@ -358,6 +368,7 @@ >>>> /** >>>> * {@inheritDoc} >>>> * >>>> + * @implSpec >>>> *

This implementation returns a collection that subclasses {@link >>>> * AbstractCollection}. The subclass's iterator method returns a >>>> * "wrapper object" over this map's entrySet() iterator. >>>> @@ -425,6 +436,7 @@ >>>> * equals method works properly across different implementations >>>> * of the Map interface. >>>> * >>>> + * @implSpec >>>> *

This implementation first checks if the specified object is this map; >>>> * if so it returns true. Then, it checks if the specified >>>> * object is a map whose size is identical to the size of this map; if >>>> @@ -478,6 +490,7 @@ >>>> * m1 and m2, as required by the general contract of >>>> * {@link Object#hashCode}. >>>> * >>>> + * @implSpec >>>> *

This implementation iterates over entrySet(), calling >>>> * {@link Map.Entry#hashCode hashCode()} on each element (entry) in the >>>> * set, and adding up the results. >>> >>> >> > From martinrb at google.com Mon Jan 6 17:05:17 2014 From: martinrb at google.com (Martin Buchholz) Date: Mon, 6 Jan 2014 09:05:17 -0800 Subject: JDK 9 RFR - 8031142 [was: Re: Using @implSpec in AbstractMap, AbstractCollection, AbstractList, etc] In-Reply-To: <52CADE0C.8070700@oracle.com> References: <52BED67D.3050005@cs.oswego.edu> <42B83A56-82E5-4991-A87A-22BB99AB23D2@oracle.com> <52CADE0C.8070700@oracle.com> Message-ID: On Mon, Jan 6, 2014 at 8:47 AM, Chris Hegarty wrote: > Part 2... > > JDK 9 RFR - 8031142: AbstractCollection and AbstractList should specify > their default implementation using @implSpec > > http://cr.openjdk.java.net/~chegar/8031142/webrev/ > http://cr.openjdk.java.net/~chegar/8031142/specdiff/ Is that specdiff link what you want? I just get a giant tree with javax files in it... --- In a sane language, the AbstractFoo classes would be traits - they should never contribute to the *specification* of a concrete class, only to its implementation. Therefore, in Java, all of the methods should have precisely an {@inheritDoc} followed by an @implSpec. In particular, for AbstractCollection.toArray I see: 114 /** 115 * {@inheritDoc} 116 * 117 *

This method is equivalent to: 118 * 119 *

 {@code
 120      * List list = new ArrayList(size());
 121      * for (E e : this)
 122      *     list.add(e);
 123      * return list.toArray();
 124      * }
125 * 126 * @implSpec 127 * This implementation returns an array containing all the elements 128 * returned by this collection's iterator, in the same order, stored in 129 * consecutive elements of the array, starting with index {@code 0}. 130 * The length of the returned array is equal to the number of elements 131 * returned by the iterator, even if the size of this collection changes 132 * during iteration, as might happen if the collection permits 133 * concurrent modification during iteration. The {@code size} method is 134 * called only as an optimization hint; the correct result is returned 135 * even if the iterator returns a different number of elements. 136 */ 137 public Object[] toArray() { which must be wrong. Either the sample code should be moved into the @implSpec or promoted to Collection.java.toArray. The introduction of default methods ("not quite traits") makes the situation murkier. Looking more closely, the exact wording cannot be promoted to Collection.java because the behavior may in fact differ from the code sample. size() may or may not be called. toArray implementation is more likely to be atomic, etc... So move it into the @implSpec somehow... From chris.hegarty at oracle.com Mon Jan 6 11:44:19 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 06 Jan 2014 11:44:19 +0000 Subject: JDK 9 RFR of 8031067:java/util/concurrent/atomic/AtomicUpdaters.java: java.lang.Error: Unexpected reflective access Message-ID: <52CA9713.7080400@oracle.com> The test sets a security manager to ensure that appropriate permission checks are performed. It expects to be denied reflective access to a private field in a different package. Access, to this field, is granted if the code has RuntimePermission "accessDeclaredMembers". This permission is not expected, but the default policy implementation combines the java.home/lib/security/java.policy and user.home/.java.policy. So if a policy file, .java.policy, with RuntimePermission "accessDeclaredMembers", just happens to be in the users home directory when this test is run, it will fail as above. The solution, trivially, is for the test to set its own policy, and remove any dependency on the default policy. diff --git a/test/java/util/concurrent/atomic/AtomicUpdaters.java b/test/java/util/concurrent/atomic/AtomicUpdaters.java --- a/test/java/util/concurrent/atomic/AtomicUpdaters.java +++ b/test/java/util/concurrent/atomic/AtomicUpdaters.java @@ -33,7 +33,7 @@ */ import java.util.concurrent.atomic.*; import java.lang.reflect.*; -import java.security.AccessControlException; +import java.security.*; public class AtomicUpdaters { enum TYPE { INT, LONG, REF } @@ -102,6 +102,8 @@ verbose = true; } else if ("UseSM".equals(arg)) { + // Ensure that the test is not influenced by the default users policy. + Policy.setPolicy(new NoPermissionsPolicy()); SecurityManager m = System.getSecurityManager(); if (m != null) throw new RuntimeException("No security manager should initially be installed"); @@ -186,4 +188,24 @@ throw new Error("Some tests failed - see previous stacktraces"); } } + + /** + * Policy with no permissions. + */ + private static class NoPermissionsPolicy extends Policy { + @Override + public PermissionCollection getPermissions(CodeSource cs) { + return Policy.UNSUPPORTED_EMPTY_COLLECTION; + } + + @Override + public PermissionCollection getPermissions(ProtectionDomain pd) { + return Policy.UNSUPPORTED_EMPTY_COLLECTION; + } + + @Override + public boolean implies(ProtectionDomain pd, Permission p) { + return Policy.UNSUPPORTED_EMPTY_COLLECTION.implies(p); + } + } } -Chris. From martinrb at google.com Mon Jan 6 20:24:07 2014 From: martinrb at google.com (Martin Buchholz) Date: Mon, 6 Jan 2014 12:24:07 -0800 Subject: JDK 9 RFR of 8031067:java/util/concurrent/atomic/AtomicUpdaters.java: java.lang.Error: Unexpected reflective access In-Reply-To: <52CA9713.7080400@oracle.com> References: <52CA9713.7080400@oracle.com> Message-ID: Looks good. On Mon, Jan 6, 2014 at 3:44 AM, Chris Hegarty wrote: > The test sets a security manager to ensure that appropriate permission > checks are performed. It expects to be denied reflective access to a > private field in a different package. Access, to this field, is granted if > the code has RuntimePermission "accessDeclaredMembers". This permission is > not expected, but the default policy implementation combines the > java.home/lib/security/java.policy and user.home/.java.policy. So if a > policy file, .java.policy, with RuntimePermission "accessDeclaredMembers", > just happens to be in the users home directory when this test is run, it > will fail as above. > > The solution, trivially, is for the test to set its own policy, and remove > any dependency on the default policy. > > diff --git a/test/java/util/concurrent/atomic/AtomicUpdaters.java > b/test/java/util/concurrent/atomic/AtomicUpdaters.java > --- a/test/java/util/concurrent/atomic/AtomicUpdaters.java > +++ b/test/java/util/concurrent/atomic/AtomicUpdaters.java > @@ -33,7 +33,7 @@ > */ > import java.util.concurrent.atomic.*; > import java.lang.reflect.*; > -import java.security.AccessControlException; > +import java.security.*; > > public class AtomicUpdaters { > enum TYPE { INT, LONG, REF } > @@ -102,6 +102,8 @@ > verbose = true; > } > else if ("UseSM".equals(arg)) { > + // Ensure that the test is not influenced by the default > users policy. > + Policy.setPolicy(new NoPermissionsPolicy()); > SecurityManager m = System.getSecurityManager(); > if (m != null) > throw new RuntimeException("No security manager > should initially be installed"); > @@ -186,4 +188,24 @@ > throw new Error("Some tests failed - see previous > stacktraces"); > } > } > + > + /** > + * Policy with no permissions. > + */ > + private static class NoPermissionsPolicy extends Policy { > + @Override > + public PermissionCollection getPermissions(CodeSource cs) { > + return Policy.UNSUPPORTED_EMPTY_COLLECTION; > + } > + > + @Override > + public PermissionCollection getPermissions(ProtectionDomain pd) { > + return Policy.UNSUPPORTED_EMPTY_COLLECTION; > + } > + > + @Override > + public boolean implies(ProtectionDomain pd, Permission p) { > + return Policy.UNSUPPORTED_EMPTY_COLLECTION.implies(p); > + } > + } > } > > -Chris. > From chris.hegarty at oracle.com Mon Jan 6 20:49:52 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 6 Jan 2014 20:49:52 +0000 Subject: JDK 9 RFR - 8031142 [was: Re: Using @implSpec in AbstractMap, AbstractCollection, AbstractList, etc] In-Reply-To: References: <52BED67D.3050005@cs.oswego.edu> <42B83A56-82E5-4991-A87A-22BB99AB23D2@oracle.com> <52CADE0C.8070700@oracle.com> Message-ID: <5022A491-F977-4C18-ACEB-9021490ED27B@oracle.com> On 6 Jan 2014, at 18:11, Chris Hegarty wrote: > On 6 Jan 2014, at 17:05, Martin Buchholz wrote: > ??.. >> >> In a sane language, the AbstractFoo classes would be traits - they should never contribute to the *specification* of a concrete class, only to its implementation. Therefore, in Java, all of the methods should have precisely an {@inheritDoc} followed by an @implSpec. In particular, for AbstractCollection.toArray I see: >> >> 114 /** >> 115 * {@inheritDoc} >> 116 * >> 117 *

This method is equivalent to: >> 118 * >> 119 *

 {@code
>> 120      * List list = new ArrayList(size());
>> 121      * for (E e : this)
>> 122      *     list.add(e);
>> 123      * return list.toArray();
>> 124      * }
>> 125 * >> 126 * @implSpec >> 127 * This implementation returns an array containing all the elements >> 128 * returned by this collection's iterator, in the same order, stored in >> 129 * consecutive elements of the array, starting with index {@code 0}. >> 130 * The length of the returned array is equal to the number of elements >> 131 * returned by the iterator, even if the size of this collection changes >> 132 * during iteration, as might happen if the collection permits >> 133 * concurrent modification during iteration. The {@code size} method is >> 134 * called only as an optimization hint; the correct result is returned >> 135 * even if the iterator returns a different number of elements. >> 136 */ >> 137 public Object[] toArray() { >> >> which must be wrong. Either the sample code should be moved into the @implSpec or promoted to Collection.java.toArray. The introduction of default methods ("not quite traits") makes the situation murkier. Looking more closely, the exact wording cannot be promoted to Collection.java because the behavior may in fact differ from the code sample. size() may or may not be called. toArray implementation is more likely to be atomic, etc... So move it into the @implSpec somehow? Done. > > I wasn?t quite sure about this. ?This method is equivalent to, or, as if the following was invoked ?? without actually specifying the actual implementation. But I agree, AbstractFoo should only have @inheritDoc or @implSpec. Let me see what happens when I move it into @implSpec. Updated webrev and spec diff: http://cr.openjdk.java.net/~chegar/8031142/specdiff.01/overview-summary.html http://cr.openjdk.java.net/~chegar/8031142/webrev.01/webrev/ AbstractList retains its copy of the List add(E), clear(), and iterator() method specifications. When I replaced them with {@inheritdoc}, the Collection/AbstractCollection docs were copied in ( but we want the List docs ). I think this is a javadoc bug. I?ll look into this separately. -Chris. > > -Chris. > From joe.darcy at oracle.com Mon Jan 6 20:53:56 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 06 Jan 2014 12:53:56 -0800 Subject: JDK 9 RFR of JDK-8027063 SecurityManger.getClassContext returns a raw type Message-ID: <52CB17E4.5020900@oracle.com> Hello, Please review the simple change to fix JDK-8027063 SecurityManger.getClassContext returns a raw type, which changes a signature of a protected method in SecurityManger to remove a use of raw types in the core libraries: --- a/src/share/classes/java/lang/SecurityManager.java Mon Jan 06 11:48:32 2014 -0800 +++ b/src/share/classes/java/lang/SecurityManager.java Mon Jan 06 12:51:52 2014 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1995, 2011, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1995, 2014, 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 @@ -307,7 +307,7 @@ * * @return the execution stack. */ - protected native Class[] getClassContext(); + protected native Class[] getClassContext(); /** * Returns the class loader of the most recently executing method from A clean build succeeds and the SecurityManager tests pass after this change. Thanks, -Joe From Lance.Andersen at oracle.com Mon Jan 6 20:56:49 2014 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Mon, 6 Jan 2014 15:56:49 -0500 Subject: JDK 9 RFR of JDK-8027063 SecurityManger.getClassContext returns a raw type In-Reply-To: <52CB17E4.5020900@oracle.com> References: <52CB17E4.5020900@oracle.com> Message-ID: <4B42B914-2BE0-452A-B1BF-1BE6C1A523A4@oracle.com> +1 On Jan 6, 2014, at 3:53 PM, Joe Darcy wrote: > Hello, > > Please review the simple change to fix JDK-8027063 SecurityManger.getClassContext returns a raw type, which changes a signature of a protected method in SecurityManger to remove a use of raw types in the core libraries: > > --- a/src/share/classes/java/lang/SecurityManager.java Mon Jan 06 11:48:32 2014 -0800 > +++ b/src/share/classes/java/lang/SecurityManager.java Mon Jan 06 12:51:52 2014 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1995, 2011, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1995, 2014, 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 > @@ -307,7 +307,7 @@ > * > * @return the execution stack. > */ > - protected native Class[] getClassContext(); > + protected native Class[] getClassContext(); > > /** > * Returns the class loader of the most recently executing method from > > A clean build succeeds and the SecurityManager tests pass after this change. > > Thanks, > > -Joe -------------- next part -------------- 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 martinrb at google.com Mon Jan 6 21:06:12 2014 From: martinrb at google.com (Martin Buchholz) Date: Mon, 6 Jan 2014 13:06:12 -0800 Subject: JDK 9 RFR - 8031142 [was: Re: Using @implSpec in AbstractMap, AbstractCollection, AbstractList, etc] In-Reply-To: <5022A491-F977-4C18-ACEB-9021490ED27B@oracle.com> References: <52BED67D.3050005@cs.oswego.edu> <42B83A56-82E5-4991-A87A-22BB99AB23D2@oracle.com> <52CADE0C.8070700@oracle.com> <5022A491-F977-4C18-ACEB-9021490ED27B@oracle.com> Message-ID: - JDK - JDK-6270645 Javadoc comments should be inherited from most derived superinterface or superclass - but that's marked fixed... On Mon, Jan 6, 2014 at 12:49 PM, Chris Hegarty wrote: > > On 6 Jan 2014, at 18:11, Chris Hegarty wrote: > > > On 6 Jan 2014, at 17:05, Martin Buchholz wrote: > > ??.. > >> > >> In a sane language, the AbstractFoo classes would be traits - they > should never contribute to the *specification* of a concrete class, only to > its implementation. Therefore, in Java, all of the methods should have > precisely an {@inheritDoc} followed by an @implSpec. In particular, for > AbstractCollection.toArray I see: > >> > >> 114 /** > >> 115 * {@inheritDoc} > >> 116 * > >> 117 *

This method is equivalent to: > >> 118 * > >> 119 *

 {@code
> >> 120      * List list = new ArrayList(size());
> >> 121      * for (E e : this)
> >> 122      *     list.add(e);
> >> 123      * return list.toArray();
> >> 124      * }
> >> 125 * > >> 126 * @implSpec > >> 127 * This implementation returns an array containing all the > elements > >> 128 * returned by this collection's iterator, in the same order, > stored in > >> 129 * consecutive elements of the array, starting with index > {@code 0}. > >> 130 * The length of the returned array is equal to the number of > elements > >> 131 * returned by the iterator, even if the size of this > collection changes > >> 132 * during iteration, as might happen if the collection permits > >> 133 * concurrent modification during iteration. The {@code size} > method is > >> 134 * called only as an optimization hint; the correct result is > returned > >> 135 * even if the iterator returns a different number of elements. > >> 136 */ > >> 137 public Object[] toArray() { > >> > >> which must be wrong. Either the sample code should be moved into the > @implSpec or promoted to Collection.java.toArray. The introduction of > default methods ("not quite traits") makes the situation murkier. Looking > more closely, the exact wording cannot be promoted to Collection.java > because the behavior may in fact differ from the code sample. size() may > or may not be called. toArray implementation is more likely to be atomic, > etc... So move it into the @implSpec somehow? > > Done. > > > > > I wasn?t quite sure about this. ?This method is equivalent to, or, as if > the following was invoked ?? without actually specifying the actual > implementation. But I agree, AbstractFoo should only have @inheritDoc or > @implSpec. Let me see what happens when I move it into @implSpec. > > Updated webrev and spec diff: > > http://cr.openjdk.java.net/~chegar/8031142/specdiff.01/overview-summary.html > http://cr.openjdk.java.net/~chegar/8031142/webrev.01/webrev/ > > AbstractList retains its copy of the List add(E), clear(), and iterator() > method specifications. When I replaced them with {@inheritdoc}, the > Collection/AbstractCollection docs were copied in ( but we want the List > docs ). I think this is a javadoc bug. I?ll look into this separately. > > -Chris. > > > > > -Chris. > > > > From martinrb at google.com Mon Jan 6 21:15:31 2014 From: martinrb at google.com (Martin Buchholz) Date: Mon, 6 Jan 2014 13:15:31 -0800 Subject: JDK 9 RFR - 8031142 [was: Re: Using @implSpec in AbstractMap, AbstractCollection, AbstractList, etc] In-Reply-To: <5022A491-F977-4C18-ACEB-9021490ED27B@oracle.com> References: <52BED67D.3050005@cs.oswego.edu> <42B83A56-82E5-4991-A87A-22BB99AB23D2@oracle.com> <52CADE0C.8070700@oracle.com> <5022A491-F977-4C18-ACEB-9021490ED27B@oracle.com> Message-ID: I retract my previous message. What's actually happening is that superclasses are preferred to superinterfaces as sources for @inheritDoc. It used to be that javadoc was the only thing in java subject to the dreaded diamond inheritance. Maybe method resolution for default methods vs. superclass methods today works the same way? Anyways, this is one reason I was pessimistic back in 2005 that new mechanisms like @implSpec would actually make java.util maintainers lives much easier. From martinrb at google.com Mon Jan 6 21:19:13 2014 From: martinrb at google.com (Martin Buchholz) Date: Mon, 6 Jan 2014 13:19:13 -0800 Subject: JDK 9 RFR - 8031142 [was: Re: Using @implSpec in AbstractMap, AbstractCollection, AbstractList, etc] In-Reply-To: <5022A491-F977-4C18-ACEB-9021490ED27B@oracle.com> References: <52BED67D.3050005@cs.oswego.edu> <42B83A56-82E5-4991-A87A-22BB99AB23D2@oracle.com> <52CADE0C.8070700@oracle.com> <5022A491-F977-4C18-ACEB-9021490ED27B@oracle.com> Message-ID: Your change looks good, except there's one more trailing

to remove. From joe.darcy at oracle.com Mon Jan 6 21:41:12 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 06 Jan 2014 13:41:12 -0800 Subject: JDK 9 RFR of JDK-8031210 Remove serial warning from java.lang.Enum Message-ID: <52CB22F8.4030809@oracle.com> Hello, Please review the patch below to add a @SuppressWarning("serial") to java.lang.Enum to resolve a lint warning in the core libraries. Thanks, -Joe --- a/src/share/classes/java/lang/Enum.java Mon Jan 06 11:48:32 2014 -0800 +++ b/src/share/classes/java/lang/Enum.java Mon Jan 06 13:37:06 2014 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, 2011, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 2014, 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 @@ -52,6 +52,8 @@ * @see java.util.EnumMap * @since 1.5 */ + at SuppressWarnings("serial") // No serialVersionUID needed due to + // special-casing of enum types. public abstract class Enum> implements Comparable, Serializable { /** From Lance.Andersen at oracle.com Mon Jan 6 21:46:40 2014 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Mon, 6 Jan 2014 16:46:40 -0500 Subject: JDK 9 RFR of JDK-8031210 Remove serial warning from java.lang.Enum In-Reply-To: <52CB22F8.4030809@oracle.com> References: <52CB22F8.4030809@oracle.com> Message-ID: <88F22241-76DE-49D4-BC8D-BF7821D2CCFB@oracle.com> +1 On Jan 6, 2014, at 4:41 PM, Joe Darcy wrote: > Hello, > > Please review the patch below to add a @SuppressWarning("serial") to java.lang.Enum to resolve a lint warning in the core libraries. > > Thanks, > > -Joe > > --- a/src/share/classes/java/lang/Enum.java Mon Jan 06 11:48:32 2014 -0800 > +++ b/src/share/classes/java/lang/Enum.java Mon Jan 06 13:37:06 2014 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2011, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2003, 2014, 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 > @@ -52,6 +52,8 @@ > * @see java.util.EnumMap > * @since 1.5 > */ > + at SuppressWarnings("serial") // No serialVersionUID needed due to > + // special-casing of enum types. > public abstract class Enum> > implements Comparable, Serializable { > /** > -------------- next part -------------- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From mike.duigou at oracle.com Mon Jan 6 21:47:07 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 6 Jan 2014 13:47:07 -0800 Subject: JDK 9 RFR of JDK-8031210 Remove serial warning from java.lang.Enum In-Reply-To: <52CB22F8.4030809@oracle.com> References: <52CB22F8.4030809@oracle.com> Message-ID: <3A0F5230-74DB-4E09-ADFE-511F3F85E6E4@oracle.com> Entirely reasonable. Approved. Mike On Jan 6 2014, at 13:41 , Joe Darcy wrote: > Hello, > > Please review the patch below to add a @SuppressWarning("serial") to java.lang.Enum to resolve a lint warning in the core libraries. > > Thanks, > > -Joe > > --- a/src/share/classes/java/lang/Enum.java Mon Jan 06 11:48:32 2014 -0800 > +++ b/src/share/classes/java/lang/Enum.java Mon Jan 06 13:37:06 2014 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2011, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2003, 2014, 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 > @@ -52,6 +52,8 @@ > * @see java.util.EnumMap > * @since 1.5 > */ > + at SuppressWarnings("serial") // No serialVersionUID needed due to > + // special-casing of enum types. > public abstract class Enum> > implements Comparable, Serializable { > /** > From dan.xu at oracle.com Mon Jan 6 22:29:34 2014 From: dan.xu at oracle.com (Dan Xu) Date: Mon, 06 Jan 2014 14:29:34 -0800 Subject: RFR: JDK-8028726 - (prefs) Check src/solaris/native/java/util/FileSystemPreferences.c for JNI pending exceptions Message-ID: <52CB2E4E.7080200@oracle.com> Hi All, Please review the simple fix for JNI pending exceptions in FileSystemPreferences.c. Thanks! Bug: https://bugs.openjdk.java.net/browse/JDK-8028726 Webrev: http://cr.openjdk.java.net/~dxu/8028726/webrev/ -Dan From Lance.Andersen at oracle.com Mon Jan 6 22:35:01 2014 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Mon, 6 Jan 2014 17:35:01 -0500 Subject: RFR: JDK-8028726 - (prefs) Check src/solaris/native/java/util/FileSystemPreferences.c for JNI pending exceptions In-Reply-To: <52CB2E4E.7080200@oracle.com> References: <52CB2E4E.7080200@oracle.com> Message-ID: Dan, Looks OK, but line 914 which you did not change, notice the comments not sure if that is common in this code but seemed a bit off to me: 914 // // If at first, you don't succeed... On Jan 6, 2014, at 5:29 PM, Dan Xu wrote: > Hi All, > > Please review the simple fix for JNI pending exceptions in FileSystemPreferences.c. Thanks! > > Bug: https://bugs.openjdk.java.net/browse/JDK-8028726 > Webrev: http://cr.openjdk.java.net/~dxu/8028726/webrev/ > > -Dan -------------- next part -------------- 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 dan.xu at oracle.com Mon Jan 6 23:07:23 2014 From: dan.xu at oracle.com (Dan Xu) Date: Mon, 06 Jan 2014 15:07:23 -0800 Subject: RFR: JDK-8028726 - (prefs) Check src/solaris/native/java/util/FileSystemPreferences.c for JNI pending exceptions In-Reply-To: References: <52CB2E4E.7080200@oracle.com> Message-ID: <52CB372B.8040503@oracle.com> Hi Lance, Thanks for your review. My understanding towards the for loop in lockFile() of FileSystemPreferences.java is that it retries if anything fails. So I don't touch L914 to keep its old logic un-changed. Please let me know if you have some good suggestions. Thanks! -Dan On 01/06/2014 02:35 PM, Lance Andersen - Oracle wrote: > Dan, > > Looks OK, but line 914 which you did not change, notice the comments not sure if that is common in this code but seemed a bit off to me: > > 914 // // If at first, you don't succeed... > On Jan 6, 2014, at 5:29 PM, Dan Xu wrote: > >> Hi All, >> >> Please review the simple fix for JNI pending exceptions in FileSystemPreferences.c. Thanks! >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8028726 >> Webrev: http://cr.openjdk.java.net/~dxu/8028726/webrev/ >> >> -Dan > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > From Lance.Andersen at oracle.com Mon Jan 6 23:17:39 2014 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Mon, 6 Jan 2014 18:17:39 -0500 Subject: RFR: JDK-8028726 - (prefs) Check src/solaris/native/java/util/FileSystemPreferences.c for JNI pending exceptions In-Reply-To: <52CB372B.8040503@oracle.com> References: <52CB2E4E.7080200@oracle.com> <52CB372B.8040503@oracle.com> Message-ID: <812F3146-CDBE-43AD-8918-D2597346DC81@oracle.com> H Dan, No comments on the logic, but the comment format seemed a bit strange to me (notice the extra '//') Best Lance On Jan 6, 2014, at 6:07 PM, Dan Xu wrote: > Hi Lance, > > Thanks for your review. > > My understanding towards the for loop in lockFile() of FileSystemPreferences.java is that it retries if anything fails. So I don't touch L914 to keep its old logic un-changed. Please let me know if you have some good suggestions. Thanks! > > -Dan > > > On 01/06/2014 02:35 PM, Lance Andersen - Oracle wrote: >> Dan, >> >> Looks OK, but line 914 which you did not change, notice the comments not sure if that is common in this code but seemed a bit off to me: >> >> 914 // // If at first, you don't succeed... >> On Jan 6, 2014, at 5:29 PM, Dan Xu wrote: >> >>> Hi All, >>> >>> Please review the simple fix for JNI pending exceptions in FileSystemPreferences.c. Thanks! >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8028726 >>> Webrev: http://cr.openjdk.java.net/~dxu/8028726/webrev/ >>> >>> -Dan >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From david.holmes at oracle.com Tue Jan 7 00:40:28 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 07 Jan 2014 10:40:28 +1000 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52B3E86B.3050707@oracle.com> References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> Message-ID: <52CB4CFC.9070405@oracle.com> Back from vacation ... On 20/12/2013 4:49 PM, David Holmes wrote: > On 20/12/2013 12:57 PM, srikalyan chandrashekar wrote: >> Hi David Thanks for your comments, the unguarded part(clean and enqueue) >> in the Reference Handler thread does not seem to create any new objects, >> so it is the application(the test in this case) which is adding objects >> to heap and causing the Reference Handler to die with OOME. > > The ReferenceHandler thread can only get OOME if it allocates (directly > or indirectly) - so there has to be something in the unguarded part that > causes this. Again it may be an implicit action in the VM - similar to > the class load issue for InterruptedException. Run a debug VM with -XX:+TraceExceptions to see where the OOME is triggered. David ----- > David > > I am still >> unsure about the side effects of the code change and agree with your >> thoughts(on memory exhaustion test's reliability). >> >> PS: hotspot dev alias removed from CC. >> >> -- >> Thanks >> kalyan >> >> On 12/19/13 5:08 PM, David Holmes wrote: >>> Hi Kalyan, >>> >>> This is not a hotspot issue so I'm moving this to core-libs, please >>> drop hotspot from any replies. >>> >>> On 20/12/2013 6:26 AM, srikalyan wrote: >>>> Hi all, I have been working on the bug JDK-8022321 >>>> , this is a sporadic >>>> failure and the webrev is available here >>>> http://cr.openjdk.java.net/~srikchan/Regression/JDK-8022321_OOMEInReferenceHandler-webrev/ >>>> >>>> >>> >>> I'm really not sure what to make of this. We have a test that triggers >>> an out-of-memory condition but the OOME can actually turn up in the >>> ReferenceHandler thread causing it to terminate and the test to fail. >>> We previously accounted for the non-obvious occurrences of OOME due to >>> the Object.wait and the possible need to load the InterruptedException >>> class - but still the OOME can appear where we don't want it. So >>> finally you have just placed the whole for(;;) loop in a >>> try/catch(OOME) that ignores the OOME. I'm certain that makes the test >>> happy, but I'm not sure it is really what we want for the >>> ReferenceHandler thread. If the OOME occurs while cleaning, or >>> enqueuing then we will fail to clean and/or enqueue but there would be >>> no indication that has occurred and I think that is a bigger problem >>> than this test failing. >>> >>> There may be no way to make this test 100% reliable. In fact I'd >>> suggest that no memory exhaustion test can be 100% reliable. >>> >>> David >>> >>>> * >>>> **"Root Cause:Still not known"* >>>> 2 places where there is a possibility for OOME >>>> 1) Cleaner.clean() >>>> 2) ReferenceQueue.enqueue() >>>> >>>> 1) The cleanup code in turn has 2 places where there is potential for >>>> throwing OOME, >>>> a) thunk Thread which is run from clean() method. This Runnable is >>>> passed to Cleaner and appears in the following classes >>>> java/nio/DirectByteBuffer.java >>>> sun/misc/Perf.java >>>> sun/nio/fs/NativeBuffer.java >>>> sun/nio/ch/IOVecWrapper.java >>>> sun/misc/Cleaner/ExitOnThrow.java >>>> However none of the above overridden implementations ever create an >>>> object in the clean() code. >>>> b) new PrivilegedAction created in try catch Exception block of >>>> clean() method but for this object to be created and to be held >>>> responsible for OOME an Exception(other than OOME) has to be thrown. >>>> >>>> 2) No new heap objects are created in the enqueue method nor >>>> anywhere in >>>> the deep call stack (VM.addFinalRefCount() etc) so this cannot be a >>>> potential cause. >>>> >>>> *Experimental change to java.lang.Reference.java* : >>>> - Put one more guard (try catch with OOME block) in the Reference >>>> Handler Thread which may give the Reference Handler a chance to >>>> cleanup. >>>> This is fixing the test failure (several 1000 runs with 0 failures) >>>> - Without the above change the test fails atleast 3-5 times for every >>>> 1000 run. >>>> >>>> *PS*: The code change is to a very critical part of JDK and i am fully >>>> not aware of the consequences of the change, hence seeking expert help >>>> here. Appreciate your time and inputs towards this. >>>> >> From srikalyan.chandrashekar at oracle.com Tue Jan 7 02:15:12 2014 From: srikalyan.chandrashekar at oracle.com (srikalyan chandrashekar) Date: Mon, 06 Jan 2014 18:15:12 -0800 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52CB4CFC.9070405@oracle.com> References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> Message-ID: <52CB6330.3090901@oracle.com> Sure David will give that a try, we have so far attempted to 1. Print state data(as per the test creator peter.levart's inputs), 2. Use UEH(uncaught exception handler per Mandy's inputs) -- Thanks kalyan On 1/6/14 4:40 PM, David Holmes wrote: > Back from vacation ... > > On 20/12/2013 4:49 PM, David Holmes wrote: >> On 20/12/2013 12:57 PM, srikalyan chandrashekar wrote: >>> Hi David Thanks for your comments, the unguarded part(clean and >>> enqueue) >>> in the Reference Handler thread does not seem to create any new >>> objects, >>> so it is the application(the test in this case) which is adding objects >>> to heap and causing the Reference Handler to die with OOME. >> >> The ReferenceHandler thread can only get OOME if it allocates (directly >> or indirectly) - so there has to be something in the unguarded part that >> causes this. Again it may be an implicit action in the VM - similar to >> the class load issue for InterruptedException. > > Run a debug VM with -XX:+TraceExceptions to see where the OOME is > triggered. > > David > ----- > >> David >> >> I am still >>> unsure about the side effects of the code change and agree with your >>> thoughts(on memory exhaustion test's reliability). >>> >>> PS: hotspot dev alias removed from CC. >>> >>> -- >>> Thanks >>> kalyan >>> >>> On 12/19/13 5:08 PM, David Holmes wrote: >>>> Hi Kalyan, >>>> >>>> This is not a hotspot issue so I'm moving this to core-libs, please >>>> drop hotspot from any replies. >>>> >>>> On 20/12/2013 6:26 AM, srikalyan wrote: >>>>> Hi all, I have been working on the bug JDK-8022321 >>>>> , this is a >>>>> sporadic >>>>> failure and the webrev is available here >>>>> http://cr.openjdk.java.net/~srikchan/Regression/JDK-8022321_OOMEInReferenceHandler-webrev/ >>>>> >>>>> >>>>> >>>> >>>> I'm really not sure what to make of this. We have a test that triggers >>>> an out-of-memory condition but the OOME can actually turn up in the >>>> ReferenceHandler thread causing it to terminate and the test to fail. >>>> We previously accounted for the non-obvious occurrences of OOME due to >>>> the Object.wait and the possible need to load the InterruptedException >>>> class - but still the OOME can appear where we don't want it. So >>>> finally you have just placed the whole for(;;) loop in a >>>> try/catch(OOME) that ignores the OOME. I'm certain that makes the test >>>> happy, but I'm not sure it is really what we want for the >>>> ReferenceHandler thread. If the OOME occurs while cleaning, or >>>> enqueuing then we will fail to clean and/or enqueue but there would be >>>> no indication that has occurred and I think that is a bigger problem >>>> than this test failing. >>>> >>>> There may be no way to make this test 100% reliable. In fact I'd >>>> suggest that no memory exhaustion test can be 100% reliable. >>>> >>>> David >>>> >>>>> * >>>>> **"Root Cause:Still not known"* >>>>> 2 places where there is a possibility for OOME >>>>> 1) Cleaner.clean() >>>>> 2) ReferenceQueue.enqueue() >>>>> >>>>> 1) The cleanup code in turn has 2 places where there is potential >>>>> for >>>>> throwing OOME, >>>>> a) thunk Thread which is run from clean() method. This >>>>> Runnable is >>>>> passed to Cleaner and appears in the following classes >>>>> java/nio/DirectByteBuffer.java >>>>> sun/misc/Perf.java >>>>> sun/nio/fs/NativeBuffer.java >>>>> sun/nio/ch/IOVecWrapper.java >>>>> sun/misc/Cleaner/ExitOnThrow.java >>>>> However none of the above overridden implementations ever create an >>>>> object in the clean() code. >>>>> b) new PrivilegedAction created in try catch Exception block of >>>>> clean() method but for this object to be created and to be held >>>>> responsible for OOME an Exception(other than OOME) has to be thrown. >>>>> >>>>> 2) No new heap objects are created in the enqueue method nor >>>>> anywhere in >>>>> the deep call stack (VM.addFinalRefCount() etc) so this cannot be a >>>>> potential cause. >>>>> >>>>> *Experimental change to java.lang.Reference.java* : >>>>> - Put one more guard (try catch with OOME block) in the Reference >>>>> Handler Thread which may give the Reference Handler a chance to >>>>> cleanup. >>>>> This is fixing the test failure (several 1000 runs with 0 failures) >>>>> - Without the above change the test fails atleast 3-5 times for every >>>>> 1000 run. >>>>> >>>>> *PS*: The code change is to a very critical part of JDK and i am >>>>> fully >>>>> not aware of the consequences of the change, hence seeking expert >>>>> help >>>>> here. Appreciate your time and inputs towards this. >>>>> >>> From Xuelei.Fan at Oracle.COM Tue Jan 7 06:28:42 2014 From: Xuelei.Fan at Oracle.COM (Xuelei Fan) Date: Tue, 07 Jan 2014 14:28:42 +0800 Subject: JDK 9 RFR of JDK-8027063 SecurityManger.getClassContext returns a raw type In-Reply-To: <52CB17E4.5020900@oracle.com> References: <52CB17E4.5020900@oracle.com> Message-ID: <52CB9E9A.8090007@Oracle.COM> Looks fine to me. Thanks, Xuelei On 1/7/2014 4:53 AM, Joe Darcy wrote: > Hello, > > Please review the simple change to fix JDK-8027063 > SecurityManger.getClassContext returns a raw type, which changes a > signature of a protected method in SecurityManger to remove a use of raw > types in the core libraries: > > --- a/src/share/classes/java/lang/SecurityManager.java Mon Jan 06 > 11:48:32 2014 -0800 > +++ b/src/share/classes/java/lang/SecurityManager.java Mon Jan 06 > 12:51:52 2014 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1995, 2011, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1995, 2014, 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 > @@ -307,7 +307,7 @@ > * > * @return the execution stack. > */ > - protected native Class[] getClassContext(); > + protected native Class[] getClassContext(); > > /** > * Returns the class loader of the most recently executing method > from > > A clean build succeeds and the SecurityManager tests pass after this > change. > > Thanks, > > -Joe From tristan.yan at oracle.com Tue Jan 7 06:43:15 2014 From: tristan.yan at oracle.com (Tristan Yan) Date: Tue, 07 Jan 2014 14:43:15 +0800 Subject: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm Message-ID: <52CBA203.7080706@oracle.com> Hi All Please help to review the code change for JDK-7027502. http://cr.openjdk.java.net/~tyan/JDK-7027502/ Description: This test was failed in JPRT test but recently we test with same binaries run, it doesn't fail any more. The intention for this code change is bringing this test back to normal test and make this test robust and more informative. Change includes 1. Remove this test from ProblemList. 2. Change static member total_turns_taken into a local variable. Please let me know your comment on this. Thank you. Tristan From david.holmes at oracle.com Tue Jan 7 07:10:09 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 07 Jan 2014 17:10:09 +1000 Subject: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm In-Reply-To: <52CBA203.7080706@oracle.com> References: <52CBA203.7080706@oracle.com> Message-ID: <52CBA851.8070008@oracle.com> Hi Tristan, On 7/01/2014 4:43 PM, Tristan Yan wrote: > Hi All > Please help to review the code change for JDK-7027502. > > http://cr.openjdk.java.net/~tyan/JDK-7027502/ > > Description: > This test was failed in JPRT test but recently we test with same > binaries run, it doesn't fail any more. The intention for this code > change is bringing this test back to normal test and make this test > robust and more informative. Change includes > 1. Remove this test from ProblemList. > 2. Change static member total_turns_taken into a local variable. > > Please let me know your comment on this. 2 * Copyright (c) 2004,2014 Oracle and/or its affiliates. All rights reserved. Correct copyright format should have a space before 2014 and a comma after: * Copyright (c) 2004, 2014, Oracle and/or its affiliates. All rights reserved. --- Was this println intended to be left in? 114 System.out.println("total_turns_taken =" + total_turns_taken + 115 ";expected_turns_taken =" + expected_turns_taken); 116 if ( total_turns_taken.get() == expected_turns_taken ) { You only want to read total_turns_taken once otherwise you may see misleading print outs. --- 119 /* Create some monitor contention by sleeping with lock */ 120 if ( default_contention_sleep > 0 ) { 121 System.out.println("Context sleeping, to create contention"); 122 try { 123 turn.wait((long) default_contention_sleep); 124 } catch (InterruptedException ignore) { } 125 } By changing the Thread.sleep to turn.wait you no longer introduce any contention as the wait() will release the monitor. David > Thank you. > Tristan From tristan.yan at oracle.com Tue Jan 7 08:16:00 2014 From: tristan.yan at oracle.com (Tristan Yan) Date: Tue, 07 Jan 2014 16:16:00 +0800 Subject: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm In-Reply-To: <52CBA851.8070008@oracle.com> References: <52CBA203.7080706@oracle.com> <52CBA851.8070008@oracle.com> Message-ID: <52CBB7C0.1040002@oracle.com> Thank you, David I fixed copyright and change back sleep. println was intended to be left in. This test was failed with timeout, printf could help us to detect the value of total_turns_taken and expected_turns_taken. Please review it again http://cr.openjdk.java.net/~tyan/JDK-7027502/webrev.01/ Regards Tristan On 01/07/2014 03:10 PM, David Holmes wrote: > Hi Tristan, > > On 7/01/2014 4:43 PM, Tristan Yan wrote: >> Hi All >> Please help to review the code change for JDK-7027502. >> >> http://cr.openjdk.java.net/~tyan/JDK-7027502/ >> >> Description: >> This test was failed in JPRT test but recently we test with same >> binaries run, it doesn't fail any more. The intention for this code >> change is bringing this test back to normal test and make this test >> robust and more informative. Change includes >> 1. Remove this test from ProblemList. >> 2. Change static member total_turns_taken into a local variable. >> >> Please let me know your comment on this. > > 2 * Copyright (c) 2004,2014 Oracle and/or its affiliates. All > rights reserved. > > Correct copyright format should have a space before 2014 and a comma > after: > > * Copyright (c) 2004, 2014, Oracle and/or its affiliates. All rights > reserved. > > --- > > Was this println intended to be left in? > > 114 System.out.println("total_turns_taken =" + > total_turns_taken + > 115 ";expected_turns_taken =" + > expected_turns_taken); > 116 if ( total_turns_taken.get() == > expected_turns_taken ) { > > > You only want to read total_turns_taken once otherwise you may see > misleading print outs. > > --- > > 119 /* Create some monitor contention by sleeping with > lock */ > 120 if ( default_contention_sleep > 0 ) { > 121 System.out.println("Context sleeping, to > create contention"); > 122 try { > 123 turn.wait((long) default_contention_sleep); > 124 } catch (InterruptedException ignore) { } > 125 } > > By changing the Thread.sleep to turn.wait you no longer introduce any > contention as the wait() will release the monitor. > > David > >> Thank you. >> Tristan From peter.levart at gmail.com Tue Jan 7 08:42:20 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 07 Jan 2014 09:42:20 +0100 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52CB6330.3090901@oracle.com> References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> <52CB6330.3090901@oracle.com> Message-ID: <52CBBDEC.9030702@gmail.com> On 01/07/2014 03:15 AM, srikalyan chandrashekar wrote: > Sure David will give that a try, we have so far attempted to > 1. Print state data(as per the test creator peter.levart's inputs), Hi Kalyan, Have you been able to reproduce the OOME in that set-up? What was the result? Regards, Peter > 2. Use UEH(uncaught exception handler per Mandy's inputs) > > -- > Thanks > kalyan > > On 1/6/14 4:40 PM, David Holmes wrote: >> Back from vacation ... >> >> On 20/12/2013 4:49 PM, David Holmes wrote: >>> On 20/12/2013 12:57 PM, srikalyan chandrashekar wrote: >>>> Hi David Thanks for your comments, the unguarded part(clean and >>>> enqueue) >>>> in the Reference Handler thread does not seem to create any new >>>> objects, >>>> so it is the application(the test in this case) which is adding >>>> objects >>>> to heap and causing the Reference Handler to die with OOME. >>> >>> The ReferenceHandler thread can only get OOME if it allocates (directly >>> or indirectly) - so there has to be something in the unguarded part >>> that >>> causes this. Again it may be an implicit action in the VM - similar to >>> the class load issue for InterruptedException. >> >> Run a debug VM with -XX:+TraceExceptions to see where the OOME is >> triggered. >> >> David >> ----- >> >>> David >>> >>> I am still >>>> unsure about the side effects of the code change and agree with your >>>> thoughts(on memory exhaustion test's reliability). >>>> >>>> PS: hotspot dev alias removed from CC. >>>> >>>> -- >>>> Thanks >>>> kalyan >>>> >>>> On 12/19/13 5:08 PM, David Holmes wrote: >>>>> Hi Kalyan, >>>>> >>>>> This is not a hotspot issue so I'm moving this to core-libs, please >>>>> drop hotspot from any replies. >>>>> >>>>> On 20/12/2013 6:26 AM, srikalyan wrote: >>>>>> Hi all, I have been working on the bug JDK-8022321 >>>>>> , this is a >>>>>> sporadic >>>>>> failure and the webrev is available here >>>>>> http://cr.openjdk.java.net/~srikchan/Regression/JDK-8022321_OOMEInReferenceHandler-webrev/ >>>>>> >>>>>> >>>>>> >>>>> >>>>> I'm really not sure what to make of this. We have a test that >>>>> triggers >>>>> an out-of-memory condition but the OOME can actually turn up in the >>>>> ReferenceHandler thread causing it to terminate and the test to fail. >>>>> We previously accounted for the non-obvious occurrences of OOME >>>>> due to >>>>> the Object.wait and the possible need to load the >>>>> InterruptedException >>>>> class - but still the OOME can appear where we don't want it. So >>>>> finally you have just placed the whole for(;;) loop in a >>>>> try/catch(OOME) that ignores the OOME. I'm certain that makes the >>>>> test >>>>> happy, but I'm not sure it is really what we want for the >>>>> ReferenceHandler thread. If the OOME occurs while cleaning, or >>>>> enqueuing then we will fail to clean and/or enqueue but there >>>>> would be >>>>> no indication that has occurred and I think that is a bigger problem >>>>> than this test failing. >>>>> >>>>> There may be no way to make this test 100% reliable. In fact I'd >>>>> suggest that no memory exhaustion test can be 100% reliable. >>>>> >>>>> David >>>>> >>>>>> * >>>>>> **"Root Cause:Still not known"* >>>>>> 2 places where there is a possibility for OOME >>>>>> 1) Cleaner.clean() >>>>>> 2) ReferenceQueue.enqueue() >>>>>> >>>>>> 1) The cleanup code in turn has 2 places where there is >>>>>> potential for >>>>>> throwing OOME, >>>>>> a) thunk Thread which is run from clean() method. This >>>>>> Runnable is >>>>>> passed to Cleaner and appears in the following classes >>>>>> java/nio/DirectByteBuffer.java >>>>>> sun/misc/Perf.java >>>>>> sun/nio/fs/NativeBuffer.java >>>>>> sun/nio/ch/IOVecWrapper.java >>>>>> sun/misc/Cleaner/ExitOnThrow.java >>>>>> However none of the above overridden implementations ever create an >>>>>> object in the clean() code. >>>>>> b) new PrivilegedAction created in try catch Exception block of >>>>>> clean() method but for this object to be created and to be held >>>>>> responsible for OOME an Exception(other than OOME) has to be thrown. >>>>>> >>>>>> 2) No new heap objects are created in the enqueue method nor >>>>>> anywhere in >>>>>> the deep call stack (VM.addFinalRefCount() etc) so this cannot be a >>>>>> potential cause. >>>>>> >>>>>> *Experimental change to java.lang.Reference.java* : >>>>>> - Put one more guard (try catch with OOME block) in the Reference >>>>>> Handler Thread which may give the Reference Handler a chance to >>>>>> cleanup. >>>>>> This is fixing the test failure (several 1000 runs with 0 failures) >>>>>> - Without the above change the test fails atleast 3-5 times for >>>>>> every >>>>>> 1000 run. >>>>>> >>>>>> *PS*: The code change is to a very critical part of JDK and i am >>>>>> fully >>>>>> not aware of the consequences of the change, hence seeking expert >>>>>> help >>>>>> here. Appreciate your time and inputs towards this. >>>>>> >>>> > From chris.hegarty at oracle.com Tue Jan 7 09:05:54 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 7 Jan 2014 09:05:54 +0000 Subject: ObjectIn/OutputStream improvements In-Reply-To: <91644C57-6E0D-48ED-8E31-6AC217DECCEF@gmx.de> References: <91644C57-6E0D-48ED-8E31-6AC217DECCEF@gmx.de> Message-ID: <1C96B28E-5E20-4D8D-B1FD-8FD5DF193EC8@oracle.com> On 15 Dec 2013, at 10:29, Robert Stupp wrote: > Hi, > > I digged through the object serialization code and found some lines that could be optimized to reduce the number of calls to System.arraycopy() and temporary object allocations especially during string (de)serialization. > In short sentences the changes are: > ObjectInputStream: > - skip primitive/object reading if no primitive/objects in class (defaultReadFields method) > - use shared StringBuilder for string reading (prevent superfluous object allocations of one StingBuilder and one implicit char[] for each string being deserialized) > ObjectOutputStream: > - skip primitive/object writing if no primitive/objects in class (defaultWriteFields method) > - use unsafe access to calculate UTF-length > - use unsafe access in readBytes() and writeChars() methods to access String value field > - removed cbuf field > ObjectStreamClass/ObjectStreamField: > - minor improvement in getClassSignature ; share method code with ObjectStreamField (return constant string for primitives) > > I have tested the changes in a big Java installation at a customer (backported the Java8 ObjectIn/OutputStream including the changes to Java6) and a long running real application performance test resulted in reduced CPU usage (from about 60% per server to 50%). > The changes I made in openjdk8 pass all tests. > > Since I have no experience how to contribute code to openjdk in form of a push/changeset I have added the diff (hg export -g) to this email. Did you attach the diffs? I don?t see any attachment, it may be that the attachment was stripped. Can you try resending inline? You should take a look at the OpenJDK How to Contribute page [1]. Paying particular attention to the OCA, without it we will not be able to move your patch forward. Thanks, -Chris. [1] http://openjdk.java.net/contribute/ > > Robert > > From david.holmes at oracle.com Tue Jan 7 09:18:35 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 07 Jan 2014 19:18:35 +1000 Subject: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm In-Reply-To: <52CBB7C0.1040002@oracle.com> References: <52CBA203.7080706@oracle.com> <52CBA851.8070008@oracle.com> <52CBB7C0.1040002@oracle.com> Message-ID: <52CBC66B.7000003@oracle.com> On 7/01/2014 6:16 PM, Tristan Yan wrote: > Thank you, David > I fixed copyright and change back sleep. > println was intended to be left in. This test was failed with timeout, > printf could help us to detect the value of total_turns_taken and > expected_turns_taken. > Please review it again > > http://cr.openjdk.java.net/~tyan/JDK-7027502/webrev.01/ Comma after 2014 still missing in copyright. You need to read total_turns_taken.get() once and use that value in both the println and the == test, so that you print the value you actually tested. David > Regards > Tristan > > On 01/07/2014 03:10 PM, David Holmes wrote: >> Hi Tristan, >> >> On 7/01/2014 4:43 PM, Tristan Yan wrote: >>> Hi All >>> Please help to review the code change for JDK-7027502. >>> >>> http://cr.openjdk.java.net/~tyan/JDK-7027502/ >>> >>> Description: >>> This test was failed in JPRT test but recently we test with same >>> binaries run, it doesn't fail any more. The intention for this code >>> change is bringing this test back to normal test and make this test >>> robust and more informative. Change includes >>> 1. Remove this test from ProblemList. >>> 2. Change static member total_turns_taken into a local variable. >>> >>> Please let me know your comment on this. >> >> 2 * Copyright (c) 2004,2014 Oracle and/or its affiliates. All >> rights reserved. >> >> Correct copyright format should have a space before 2014 and a comma >> after: >> >> * Copyright (c) 2004, 2014, Oracle and/or its affiliates. All rights >> reserved. >> >> --- >> >> Was this println intended to be left in? >> >> 114 System.out.println("total_turns_taken =" + >> total_turns_taken + >> 115 ";expected_turns_taken =" + >> expected_turns_taken); >> 116 if ( total_turns_taken.get() == >> expected_turns_taken ) { >> >> >> You only want to read total_turns_taken once otherwise you may see >> misleading print outs. >> >> --- >> >> 119 /* Create some monitor contention by sleeping with >> lock */ >> 120 if ( default_contention_sleep > 0 ) { >> 121 System.out.println("Context sleeping, to >> create contention"); >> 122 try { >> 123 turn.wait((long) default_contention_sleep); >> 124 } catch (InterruptedException ignore) { } >> 125 } >> >> By changing the Thread.sleep to turn.wait you no longer introduce any >> contention as the wait() will release the monitor. >> >> David >> >>> Thank you. >>> Tristan > From chris.hegarty at oracle.com Tue Jan 7 09:27:07 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 7 Jan 2014 09:27:07 +0000 Subject: RFR: JDK-8028726 - (prefs) Check src/solaris/native/java/util/FileSystemPreferences.c for JNI pending exceptions In-Reply-To: <52CB2E4E.7080200@oracle.com> References: <52CB2E4E.7080200@oracle.com> Message-ID: <75F1497E-8D42-45A4-BAE0-51FC8738B8B1@oracle.com> On 6 Jan 2014, at 22:29, Dan Xu wrote: > Hi All, > > Please review the simple fix for JNI pending exceptions in FileSystemPreferences.c. Thanks! > > Bug: https://bugs.openjdk.java.net/browse/JDK-8028726 > Webrev: http://cr.openjdk.java.net/~dxu/8028726/webrev/ Looks good to me Dan. Trivially, I don?t think you need the "if (result != null) {?. If the native method ?fails? and returns NULL, there will be a pending exception which will be thrown automatically when transitioning back to Java-land. But, what you have is arguably more robust., so thumbs up from me. -Chris. > -Dan From Alan.Bateman at oracle.com Tue Jan 7 09:36:52 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 07 Jan 2014 09:36:52 +0000 Subject: RFR: JDK-8028726 - (prefs) Check src/solaris/native/java/util/FileSystemPreferences.c for JNI pending exceptions In-Reply-To: <52CB2E4E.7080200@oracle.com> References: <52CB2E4E.7080200@oracle.com> Message-ID: <52CBCAB4.1040700@oracle.com> On 06/01/2014 22:29, Dan Xu wrote: > Hi All, > > Please review the simple fix for JNI pending exceptions in > FileSystemPreferences.c. Thanks! > > Bug: https://bugs.openjdk.java.net/browse/JDK-8028726 > Webrev: http://cr.openjdk.java.net/~dxu/8028726/webrev/ The update to FIleSystemPreferences.c looks okay but if I read it correctly then lockFile0 can never return NULL without a pending exception (meaning that the change to FileSystemPreferences.java could mask an underlying bug if it existed). One passing comment is that this native methods could be completely eliminated here by changing FileSystemPreferences to lock the file via a FileChannel (use a FileLock as the lock handle). Also the chmod usage can be eliminated by mkdirs with Files.createDirectory and specify the permission files when creating the directory. I realize this is beyond the scope of what you are doing here (but an opportunity none the less). -Alan From peter.levart at gmail.com Tue Jan 7 09:42:10 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 07 Jan 2014 10:42:10 +0100 Subject: Theoretical data race on java.util.logging.Handler.sealed In-Reply-To: <52B7C129.2040606@oracle.com> References: <529D9BAC.1020904@gmail.com> <529DA808.7070009@gmail.com>, <529E68E5.7000103@oracle.com> <52A4C659.4020406@gmail.com>, <52AA48BB.7010303@oracle.com> <52AC401B.1010405@gmail.com>, <52AC97AF.4050403@gmail.com>, <52AF6D1B.8030409@oracle.com> <52B07B1C.80806@oracle.com> <52B0839B.6020006@gmail.com> <52B08D2B.7050300@oracle.com> <52B1D575.6010308@gmail.com> <52B227E2.4000809@oracle.com> <52B315A2.7010403@gmail.com> <52B3675B.1030403@oracle.com> <52B6E7C8.1040109@gmail.com> <52B7C129.2040606@oracle.com> Message-ID: <52CBCBF2.9000501@gmail.com> Hi Mandy, Daniel, Thanks for reviews. I just pushed this change to jdk9-dev/jdk ... Regards, Peter On 12/23/2013 05:50 AM, Mandy Chung wrote: > > On 12/22/2013 5:23 AM, Peter Levart wrote: >> Hi Mandy, >> >> On 12/19/2013 10:38 PM, Mandy Chung wrote: >>> On 12/19/13 7:49 AM, Peter Levart wrote: >>>> Hi Mandy, Daniel, >>>> >>>> I didn't like the package-protected getters either. So here's >>>> another variant that replaces Handler.configure() method with a >>>> package-protected constructor which is chained from JDK subclasses: >>>> >>>> http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.07/ >>>> >>>> >>> >>> Looks good. Thanks for making the change and the new test. It'd be >>> good to close the handlers by the test. The test is running in >>> othervm mode and the Cleaner thread will close the handler when VM >>> exits and the test is fine as it is. >> >> Well, not really. The Cleaner only closes Handlers that are attached >> to Loggers but the test just instantiates Handlers and doesn't add >> them to any Loggers. It's harmless as it is, othervm will exit >> nevertheless and resources will be freed... >> >> I tried closing Handlers at the end of test, but that requires >> "control" LoggingPermission and we don't want to run the test with >> "control" permission since we want to check that instantiating >> Handlers (SocketHandler too) doesn't require "control" permission. > > Thanks and the test is fine as it is. > >> >> So should anything else be done before pushing this to jdk9/dev ? > > Fix looks good and have a regression test. It's good to go and push > to jdk9/dev. No other approval needed. > > thanks > Mandy From Alan.Bateman at oracle.com Tue Jan 7 10:14:16 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 07 Jan 2014 10:14:16 +0000 Subject: RFR java.time.Duration spec correction (8031103) In-Reply-To: <52CAFF5A.4040106@oracle.com> References: <52CAFF5A.4040106@oracle.com> Message-ID: <52CBD378.7030303@oracle.com> On 06/01/2014 19:09, roger riggs wrote: > Please review this minor specification correction to the > java.time.Duration.toDays() and > toHours() methods. Only the javadoc is corrected, no code or tests > are affected. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-duration-javadoc-8031103/ This looks okay to me (a cut&paste error I assume). -Alan From tristan.yan at oracle.com Tue Jan 7 10:36:39 2014 From: tristan.yan at oracle.com (Tristan Yan) Date: Tue, 07 Jan 2014 18:36:39 +0800 Subject: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm In-Reply-To: <52CBC66B.7000003@oracle.com> References: <52CBA203.7080706@oracle.com> <52CBA851.8070008@oracle.com> <52CBB7C0.1040002@oracle.com> <52CBC66B.7000003@oracle.com> Message-ID: <52CBD8B7.8050002@oracle.com> Hi David You're totally right. Sorry I ask you review it again. http://cr.openjdk.java.net/~tyan/JDK-7027502/webrev.02/ Thank you very much. Tristan On 01/07/2014 05:18 PM, David Holmes wrote: > On 7/01/2014 6:16 PM, Tristan Yan wrote: >> Thank you, David >> I fixed copyright and change back sleep. >> println was intended to be left in. This test was failed with timeout, >> printf could help us to detect the value of total_turns_taken and >> expected_turns_taken. >> Please review it again >> >> http://cr.openjdk.java.net/~tyan/JDK-7027502/webrev.01/ > > Comma after 2014 still missing in copyright. > > You need to read total_turns_taken.get() once and use that value in > both the println and the == test, so that you print the value you > actually tested. > > David > >> Regards >> Tristan >> >> On 01/07/2014 03:10 PM, David Holmes wrote: >>> Hi Tristan, >>> >>> On 7/01/2014 4:43 PM, Tristan Yan wrote: >>>> Hi All >>>> Please help to review the code change for JDK-7027502. >>>> >>>> http://cr.openjdk.java.net/~tyan/JDK-7027502/ >>>> >>>> Description: >>>> This test was failed in JPRT test but recently we test with same >>>> binaries run, it doesn't fail any more. The intention for this code >>>> change is bringing this test back to normal test and make this test >>>> robust and more informative. Change includes >>>> 1. Remove this test from ProblemList. >>>> 2. Change static member total_turns_taken into a local variable. >>>> >>>> Please let me know your comment on this. >>> >>> 2 * Copyright (c) 2004,2014 Oracle and/or its affiliates. All >>> rights reserved. >>> >>> Correct copyright format should have a space before 2014 and a comma >>> after: >>> >>> * Copyright (c) 2004, 2014, Oracle and/or its affiliates. All rights >>> reserved. >>> >>> --- >>> >>> Was this println intended to be left in? >>> >>> 114 System.out.println("total_turns_taken =" + >>> total_turns_taken + >>> 115 ";expected_turns_taken =" + >>> expected_turns_taken); >>> 116 if ( total_turns_taken.get() == >>> expected_turns_taken ) { >>> >>> >>> You only want to read total_turns_taken once otherwise you may see >>> misleading print outs. >>> >>> --- >>> >>> 119 /* Create some monitor contention by sleeping with >>> lock */ >>> 120 if ( default_contention_sleep > 0 ) { >>> 121 System.out.println("Context sleeping, to >>> create contention"); >>> 122 try { >>> 123 turn.wait((long) >>> default_contention_sleep); >>> 124 } catch (InterruptedException ignore) { } >>> 125 } >>> >>> By changing the Thread.sleep to turn.wait you no longer introduce any >>> contention as the wait() will release the monitor. >>> >>> David >>> >>>> Thank you. >>>> Tristan >> From david.holmes at oracle.com Tue Jan 7 11:29:52 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 07 Jan 2014 21:29:52 +1000 Subject: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm In-Reply-To: <52CBD8B7.8050002@oracle.com> References: <52CBA203.7080706@oracle.com> <52CBA851.8070008@oracle.com> <52CBB7C0.1040002@oracle.com> <52CBC66B.7000003@oracle.com> <52CBD8B7.8050002@oracle.com> Message-ID: <52CBE530.6070105@oracle.com> On 7/01/2014 8:36 PM, Tristan Yan wrote: > Hi David > You're totally right. Sorry I ask you review it again. > > http://cr.openjdk.java.net/~tyan/JDK-7027502/webrev.02/ Looks good now. Thanks, David > Thank you very much. > Tristan > > On 01/07/2014 05:18 PM, David Holmes wrote: >> On 7/01/2014 6:16 PM, Tristan Yan wrote: >>> Thank you, David >>> I fixed copyright and change back sleep. >>> println was intended to be left in. This test was failed with timeout, >>> printf could help us to detect the value of total_turns_taken and >>> expected_turns_taken. >>> Please review it again >>> >>> http://cr.openjdk.java.net/~tyan/JDK-7027502/webrev.01/ >> >> Comma after 2014 still missing in copyright. >> >> You need to read total_turns_taken.get() once and use that value in >> both the println and the == test, so that you print the value you >> actually tested. >> >> David >> >>> Regards >>> Tristan >>> >>> On 01/07/2014 03:10 PM, David Holmes wrote: >>>> Hi Tristan, >>>> >>>> On 7/01/2014 4:43 PM, Tristan Yan wrote: >>>>> Hi All >>>>> Please help to review the code change for JDK-7027502. >>>>> >>>>> http://cr.openjdk.java.net/~tyan/JDK-7027502/ >>>>> >>>>> Description: >>>>> This test was failed in JPRT test but recently we test with same >>>>> binaries run, it doesn't fail any more. The intention for this code >>>>> change is bringing this test back to normal test and make this test >>>>> robust and more informative. Change includes >>>>> 1. Remove this test from ProblemList. >>>>> 2. Change static member total_turns_taken into a local variable. >>>>> >>>>> Please let me know your comment on this. >>>> >>>> 2 * Copyright (c) 2004,2014 Oracle and/or its affiliates. All >>>> rights reserved. >>>> >>>> Correct copyright format should have a space before 2014 and a comma >>>> after: >>>> >>>> * Copyright (c) 2004, 2014, Oracle and/or its affiliates. All rights >>>> reserved. >>>> >>>> --- >>>> >>>> Was this println intended to be left in? >>>> >>>> 114 System.out.println("total_turns_taken =" + >>>> total_turns_taken + >>>> 115 ";expected_turns_taken =" + >>>> expected_turns_taken); >>>> 116 if ( total_turns_taken.get() == >>>> expected_turns_taken ) { >>>> >>>> >>>> You only want to read total_turns_taken once otherwise you may see >>>> misleading print outs. >>>> >>>> --- >>>> >>>> 119 /* Create some monitor contention by sleeping with >>>> lock */ >>>> 120 if ( default_contention_sleep > 0 ) { >>>> 121 System.out.println("Context sleeping, to >>>> create contention"); >>>> 122 try { >>>> 123 turn.wait((long) >>>> default_contention_sleep); >>>> 124 } catch (InterruptedException ignore) { } >>>> 125 } >>>> >>>> By changing the Thread.sleep to turn.wait you no longer introduce any >>>> contention as the wait() will release the monitor. >>>> >>>> David >>>> >>>>> Thank you. >>>>> Tristan >>> > From chris.hegarty at oracle.com Tue Jan 7 11:37:49 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 7 Jan 2014 11:37:49 +0000 Subject: JDK 9 RFR - 8031142 [was: Re: Using @implSpec in AbstractMap, AbstractCollection, AbstractList, etc] In-Reply-To: References: <52BED67D.3050005@cs.oswego.edu> <42B83A56-82E5-4991-A87A-22BB99AB23D2@oracle.com> <52CADE0C.8070700@oracle.com> <5022A491-F977-4C18-ACEB-9021490ED27B@oracle.com> Message-ID: <30D62DAF-3F23-4CA9-8A43-ED6171826496@oracle.com> On 6 Jan 2014, at 21:19, Martin Buchholz wrote: > Your change looks good, except there's one more trailing

to remove. Thanks for the review. I found the trailing

and removed it. -Chris. From sandeep.konchady at oracle.com Tue Jan 7 13:50:07 2014 From: sandeep.konchady at oracle.com (Sandeep Konchady) Date: Tue, 7 Jan 2014 05:50:07 -0800 Subject: RFR for JDK-6772009 Intermittent test failure: java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java test failed with 'Completed != 2' In-Reply-To: <52B88C57.9070105@oracle.com> References: <528B016A.3080408@oracle.com> <528C20FA.9090303@oracle.com> <528D12F4.2070300@oracle.com> <528D716C.3030502@oracle.com> <529CDDCF.6070807@oracle.com> <52A624D7.9090405@oracle.com> <52B3C353.10904@oracle.com> <52B48A3B.8040002@oracle.com> <52B53528.9050704@oracle.com> <52B88C57.9070105@oracle.com> Message-ID: <7C84C46D-A3C3-4A67-A897-CCC6F21DEACE@oracle.com> Hi David/Martin, If you agree with Kalyan's fix for this issue, could one of you please sponsor the push. Thanks, Sandeep On Dec 23, 2013, at 11:17 AM, srikalyan chandrashekar wrote: > Hi David/Martin, could any one of you sponsor this change for me? > > --- > Thanks > kalyan > > On 12/20/2013 10:28 PM, David Holmes wrote: >> On 21/12/2013 4:19 AM, srikalyan wrote: >>> Hi David, i retained only the changes to ITERS, ProbleMList.txt and >>> upstream changes by Doug Lea(as pointed by Martin), could you please >>> review the new change available here >>> http://cr.openjdk.java.net/~srikchan/Regression/6772009-CancelledLockLoop-webrev/ >>> . >> >> Ok. >> >> Thanks, >> David >> >>> -- >>> Thanks >>> kalyan >>> Ph: (408)-585-8040 >>> >>> >>> On 12/19/13, 8:10 PM, David Holmes wrote: >>>> Sorry Kalyan but I don't see the need for all the incidental changes >>>> if the primary change is to just increase the iterations. I also don't >>>> see why you need to do anything for BrokenBarrierException as it is >>>> not expected to happen and the test should just fail if it does. >>>> >>>> David >>>> >>>> On 10/12/2013 6:15 AM, srikalyan wrote: >>>>> Hi David/Martin a gentle reminder for review. >>>>> >>>>> -- >>>>> Thanks >>>>> kalyan >>>>> Ph: (408)-585-8040 >>>>> >>>>> >>>>> On 12/2/13, 11:21 AM, srikalyan wrote: >>>>>> Hi David, Thanks for the review, the new webrev is hosted at >>>>>> http://cr.openjdk.java.net/~cl/host_for_kal/6772009-CancelledLockLoop/ >>>>>> . Please see inline text. >>>>>> >>>>>> On 11/20/13, 6:35 PM, David Holmes wrote: >>>>>>> On 21/11/2013 10:28 AM, Martin Buchholz wrote: >>>>>>>> I again tried and failed to reproduce a failure. Even if I go whole >>>>>>>> hog >>>>>>>> and multiply TIMEOUT by 100 and divide ITERS by 100, the test >>>>>>>> continues to >>>>>>>> PASS. Is it just me?! >>>>>>> >>>>>>> I think you are going the wrong way Martin - you want the timeout to >>>>>>> be smaller than the time it takes to execute ITERS. >>>>>>> >>>>>>>> I don't think there's any reason to make result long. It's not even >>>>>>>> used >>>>>>>> except to inhibit hotspot optimizations. >>>>>>>> >>>>>>>> + private volatile long result = 17;//Can get int overflow,so >>>>>>>> using long >>>>>>> >>>>>>> Further the subsequent use of += is incorrect as it is not an atomic >>>>>>> operation. Even if we don't care about the value, it looks bad. >>>>>> Made the necessary changes for atomic update. >>>>>>> >>>>>>> I'm not sure result must be updated if we get a >>>>>>> BrokenBarrierException either. Probably harmless, but necessary? >>>>>> I retained it in the fix for completeness in updating the numbers, >>>>>> please let me know if you still think otherwise. >>>>>>> >>>>>>>> need to fix spelling and spacing below. >>>>>>>> >>>>>>>> + barrier.await();//If a BrokeBarrierException happens >>>>>>>> here(due to >>>>>>> >>>>>>> There are a number of style issues with spacing around comments. >>>>>> Fixed the spelling error and styling issues. >>>>>>> >>>>>>> And I don't think this change is sufficient to claim co-author status >>>>>>> with Doug either ;-) >>>>>> Removed the claim :) >>>>>>> >>>>>>> The additional tracing may be useful but seems stylistically >>>>>>> different from the rest of the code. >>>>>> Retained the tracking to understand if it is again the timing issue >>>>>> which is the cause in an event of a failure, however i can remove it >>>>>> if you think it is not necessary (OR) include an alternate solution as >>>>>> you may want to suggest. >>>>>>> >>>>>>> Overall I'm suspicious that the changed timeout actually fixes >>>>>>> anything - normally we need to add longer timeouts not shorter ones. >>>>>>> Does this fail on a range of machines or only specific ones? Have we >>>>>>> verified that the clocks/timers are behaving properly on those >>>>>>> systems? >>>>>> Here the time out is not about waiting for threads to complete >>>>>> something but to "be interrupted" before being considered done, so we >>>>>> decreased the timeout. However we now chose to increase the number of >>>>>> iterations to 5000000 from 1000000(thanks to tristan for the >>>>>> suggestion) instead of decreasing the timeout as done earlier because >>>>>> the increasing iterations ensures the threads are busy for long time >>>>>> curtailing the need to touch the timeout. >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>> >>>>>> -- >>>>>> Thanks >>>>>> kalyan >>>>>> Ph: (408)-585-8040 >>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Nov 20, 2013 at 11:52 AM, srikalyan < >>>>>>>> srikalyan.chandrashekar at oracle.com> wrote: >>>>>>>> >>>>>>>>> Hi Martin , apologies for the delay , was trying to get help for >>>>>>>>> hosting >>>>>>>>> my webrev. . Please see inline text. >>>>>>>>> >>>>>>>>> >>>>>>>>> On 11/19/13, 10:35 PM, Martin Buchholz wrote: >>>>>>>>> >>>>>>>>> Hi Kalyan, >>>>>>>>> >>>>>>>>> None of us can review your changes yet because you haven't given >>>>>>>>> us a >>>>>>>>> URL of your webrev. >>>>>>>>> >>>>>>>>> It is located here >>>>>>>>> http://cr.openjdk.java.net/~cl/host_for_srikalyan_6772009_CancelledLockLoops/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I've tried to make the jsr166 copy of CancelledLockLoops fail by >>>>>>>>> adjusting ITERS and TIMEOUT radically up and down, but the test >>>>>>>>> just keeps >>>>>>>>> on passing for me. Hints appreciated. >>>>>>>>> >>>>>>>>> Bump up the timeout to 500ms and you will see a failure (i can >>>>>>>>> see it >>>>>>>>> consistently on my machine Linux 64bit,8GBRAM,dual cores, with >>>>>>>>> JDK 1.8 >>>>>>>>> latest any promoted build). >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Nov 19, 2013 at 6:39 PM, srikalyan chandrashekar < >>>>>>>>> srikalyan.chandrashekar at oracle.com> wrote: >>>>>>>>> >>>>>>>>>> Suggested Fix: >>>>>>>>>>> a) Decrease the timeout from 100 to 50ms which will ensure that >>>>>>>>>>> the test >>>>>>>>>>> will pass even on faster machines >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> This doesn't look like a permanent fix - it just makes the >>>>>>>>> failing case >>>>>>>>> rarer. >>>>>>>>> >>>>>>>>> Thats true , the other way is to make the main thread wait on >>>>>>>>> TIMEOUT >>>>>>>>> after firing the interrupts instead of other way round, but that >>>>>>>>> would be >>>>>>>>> over-optimization which probably is not desirable as well. The 50 >>>>>>>>> ms was >>>>>>>>> arrived at empirically after running several 100 times on multiple >>>>>>>>> configurations and did not cause failures. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Thanks >>>>>>>>> kalyan >>>>>>>>> Ph: (408)-585-8040 >>>>>>>>> >>>>>>>>> >>>>>>>>> > From jason_mehrens at hotmail.com Tue Jan 7 15:07:09 2014 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Tue, 7 Jan 2014 09:07:09 -0600 Subject: Optimization in collections API In-Reply-To: References: Message-ID: Robert, If you can create a micro benchmark that fools all of the core-libs-dev or real world benchmark that actually shows performance improvements you might be able to get this patch in to the source code. Previous attempts are covered under https://bugs.openjdk.java.net/browse/JDK-4375522 and https://bugs.openjdk.java.net/browse/JDK-6383986. Looks like this latest version is covered under https://bugs.openjdk.java.net/browse/JDK-8025706. If 8025706 arrives at the same conclusion as the previous attempts maybe some comments should be added to explain what is not present in the code. Jason > From: snazy at gmx.de > Subject: Optimization in collections API > Date: Sun, 15 Dec 2013 11:34:01 +0100 > To: core-libs-dev at openjdk.java.net > > Hello, > > many real business applications make intensive use of the collections api. I have spend some time and tried to improve it a bit: > I've added a shared empty array instances to java.util.Arrays and use Arrays.EMPTY_OBJECT_ARRAY where appropriate in collection classes and reduce use of new java.util.Iterator instances where possible > > The changes pass the existing tests in openjdk8 build (make test). > > Robert > From martinrb at google.com Tue Jan 7 16:55:44 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 7 Jan 2014 08:55:44 -0800 Subject: RFR for JDK-6772009 Intermittent test failure: java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java test failed with 'Completed != 2' In-Reply-To: <7C84C46D-A3C3-4A67-A897-CCC6F21DEACE@oracle.com> References: <528B016A.3080408@oracle.com> <528C20FA.9090303@oracle.com> <528D12F4.2070300@oracle.com> <528D716C.3030502@oracle.com> <529CDDCF.6070807@oracle.com> <52A624D7.9090405@oracle.com> <52B3C353.10904@oracle.com> <52B48A3B.8040002@oracle.com> <52B53528.9050704@oracle.com> <52B88C57.9070105@oracle.com> <7C84C46D-A3C3-4A67-A897-CCC6F21DEACE@oracle.com> Message-ID: Sorry, I am not volunteering to be a sponsor at this time. Chris or David? On Tue, Jan 7, 2014 at 5:50 AM, Sandeep Konchady < sandeep.konchady at oracle.com> wrote: > Hi David/Martin, > > If you agree with Kalyan's fix for this issue, could one of you please > sponsor the push. > > Thanks, > Sandeep > > On Dec 23, 2013, at 11:17 AM, srikalyan chandrashekar < > srikalyan.chandrashekar at oracle.com> wrote: > > > Hi David/Martin, could any one of you sponsor this change for me? > > > > --- > > Thanks > > kalyan > > > > On 12/20/2013 10:28 PM, David Holmes wrote: > >> On 21/12/2013 4:19 AM, srikalyan wrote: > >>> Hi David, i retained only the changes to ITERS, ProbleMList.txt and > >>> upstream changes by Doug Lea(as pointed by Martin), could you please > >>> review the new change available here > >>> > http://cr.openjdk.java.net/~srikchan/Regression/6772009-CancelledLockLoop-webrev/ > >>> . > >> > >> Ok. > >> > >> Thanks, > >> David > >> > >>> -- > >>> Thanks > >>> kalyan > >>> Ph: (408)-585-8040 > >>> > >>> > >>> On 12/19/13, 8:10 PM, David Holmes wrote: > >>>> Sorry Kalyan but I don't see the need for all the incidental changes > >>>> if the primary change is to just increase the iterations. I also don't > >>>> see why you need to do anything for BrokenBarrierException as it is > >>>> not expected to happen and the test should just fail if it does. > >>>> > >>>> David > >>>> > >>>> On 10/12/2013 6:15 AM, srikalyan wrote: > >>>>> Hi David/Martin a gentle reminder for review. > >>>>> > >>>>> -- > >>>>> Thanks > >>>>> kalyan > >>>>> Ph: (408)-585-8040 > >>>>> > >>>>> > >>>>> On 12/2/13, 11:21 AM, srikalyan wrote: > >>>>>> Hi David, Thanks for the review, the new webrev is hosted at > >>>>>> > http://cr.openjdk.java.net/~cl/host_for_kal/6772009-CancelledLockLoop/ > >>>>>> . Please see inline text. > >>>>>> > >>>>>> On 11/20/13, 6:35 PM, David Holmes wrote: > >>>>>>> On 21/11/2013 10:28 AM, Martin Buchholz wrote: > >>>>>>>> I again tried and failed to reproduce a failure. Even if I go > whole > >>>>>>>> hog > >>>>>>>> and multiply TIMEOUT by 100 and divide ITERS by 100, the test > >>>>>>>> continues to > >>>>>>>> PASS. Is it just me?! > >>>>>>> > >>>>>>> I think you are going the wrong way Martin - you want the timeout > to > >>>>>>> be smaller than the time it takes to execute ITERS. > >>>>>>> > >>>>>>>> I don't think there's any reason to make result long. It's not > even > >>>>>>>> used > >>>>>>>> except to inhibit hotspot optimizations. > >>>>>>>> > >>>>>>>> + private volatile long result = 17;//Can get int > overflow,so > >>>>>>>> using long > >>>>>>> > >>>>>>> Further the subsequent use of += is incorrect as it is not an > atomic > >>>>>>> operation. Even if we don't care about the value, it looks bad. > >>>>>> Made the necessary changes for atomic update. > >>>>>>> > >>>>>>> I'm not sure result must be updated if we get a > >>>>>>> BrokenBarrierException either. Probably harmless, but necessary? > >>>>>> I retained it in the fix for completeness in updating the numbers, > >>>>>> please let me know if you still think otherwise. > >>>>>>> > >>>>>>>> need to fix spelling and spacing below. > >>>>>>>> > >>>>>>>> + barrier.await();//If a BrokeBarrierException > happens > >>>>>>>> here(due to > >>>>>>> > >>>>>>> There are a number of style issues with spacing around comments. > >>>>>> Fixed the spelling error and styling issues. > >>>>>>> > >>>>>>> And I don't think this change is sufficient to claim co-author > status > >>>>>>> with Doug either ;-) > >>>>>> Removed the claim :) > >>>>>>> > >>>>>>> The additional tracing may be useful but seems stylistically > >>>>>>> different from the rest of the code. > >>>>>> Retained the tracking to understand if it is again the timing issue > >>>>>> which is the cause in an event of a failure, however i can remove it > >>>>>> if you think it is not necessary (OR) include an alternate solution > as > >>>>>> you may want to suggest. > >>>>>>> > >>>>>>> Overall I'm suspicious that the changed timeout actually fixes > >>>>>>> anything - normally we need to add longer timeouts not shorter > ones. > >>>>>>> Does this fail on a range of machines or only specific ones? Have > we > >>>>>>> verified that the clocks/timers are behaving properly on those > >>>>>>> systems? > >>>>>> Here the time out is not about waiting for threads to complete > >>>>>> something but to "be interrupted" before being considered done, so > we > >>>>>> decreased the timeout. However we now chose to increase the number > of > >>>>>> iterations to 5000000 from 1000000(thanks to tristan for the > >>>>>> suggestion) instead of decreasing the timeout as done earlier > because > >>>>>> the increasing iterations ensures the threads are busy for long time > >>>>>> curtailing the need to touch the timeout. > >>>>>> > >>>>>>> > >>>>>>> Thanks, > >>>>>>> David > >>>>>> > >>>>>> -- > >>>>>> Thanks > >>>>>> kalyan > >>>>>> Ph: (408)-585-8040 > >>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> On Wed, Nov 20, 2013 at 11:52 AM, srikalyan < > >>>>>>>> srikalyan.chandrashekar at oracle.com> wrote: > >>>>>>>> > >>>>>>>>> Hi Martin , apologies for the delay , was trying to get help for > >>>>>>>>> hosting > >>>>>>>>> my webrev. . Please see inline text. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On 11/19/13, 10:35 PM, Martin Buchholz wrote: > >>>>>>>>> > >>>>>>>>> Hi Kalyan, > >>>>>>>>> > >>>>>>>>> None of us can review your changes yet because you haven't given > >>>>>>>>> us a > >>>>>>>>> URL of your webrev. > >>>>>>>>> > >>>>>>>>> It is located here > >>>>>>>>> > http://cr.openjdk.java.net/~cl/host_for_srikalyan_6772009_CancelledLockLoops/ > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> I've tried to make the jsr166 copy of CancelledLockLoops fail by > >>>>>>>>> adjusting ITERS and TIMEOUT radically up and down, but the test > >>>>>>>>> just keeps > >>>>>>>>> on passing for me. Hints appreciated. > >>>>>>>>> > >>>>>>>>> Bump up the timeout to 500ms and you will see a failure (i can > >>>>>>>>> see it > >>>>>>>>> consistently on my machine Linux 64bit,8GBRAM,dual cores, with > >>>>>>>>> JDK 1.8 > >>>>>>>>> latest any promoted build). > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On Tue, Nov 19, 2013 at 6:39 PM, srikalyan chandrashekar < > >>>>>>>>> srikalyan.chandrashekar at oracle.com> wrote: > >>>>>>>>> > >>>>>>>>>> Suggested Fix: > >>>>>>>>>>> a) Decrease the timeout from 100 to 50ms which will ensure that > >>>>>>>>>>> the test > >>>>>>>>>>> will pass even on faster machines > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> This doesn't look like a permanent fix - it just makes the > >>>>>>>>> failing case > >>>>>>>>> rarer. > >>>>>>>>> > >>>>>>>>> Thats true , the other way is to make the main thread wait on > >>>>>>>>> TIMEOUT > >>>>>>>>> after firing the interrupts instead of other way round, but that > >>>>>>>>> would be > >>>>>>>>> over-optimization which probably is not desirable as well. The > 50 > >>>>>>>>> ms was > >>>>>>>>> arrived at empirically after running several 100 times on > multiple > >>>>>>>>> configurations and did not cause failures. > >>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> Thanks > >>>>>>>>> kalyan > >>>>>>>>> Ph: (408)-585-8040 > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > > > > From roger.riggs at oracle.com Tue Jan 7 17:29:07 2014 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Tue, 07 Jan 2014 17:29:07 +0000 Subject: hg: jdk8/tl/jdk: 8031103: java.time.Duration has wrong Javadoc Comments in toDays() and toHours() Message-ID: <20140107172936.C23DA6242B@hg.openjdk.java.net> Changeset: 1b503dd54b95 Author: rriggs Date: 2014-01-07 11:50 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1b503dd54b95 8031103: java.time.Duration has wrong Javadoc Comments in toDays() and toHours() Summary: Correct specification for Duration.toDays, toHours Reviewed-by: lancea, alanb ! src/share/classes/java/time/Duration.java From joe.darcy at oracle.com Tue Jan 7 20:30:12 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 07 Jan 2014 12:30:12 -0800 Subject: JDK 9 RFR of raw type lint fix to java.lang.management Message-ID: <52CC63D4.2010104@oracle.com> Hello, Please review another minor lint fix of a raw type issues in the core libraries: diff -r 2647b91dbc2a src/share/classes/java/lang/management/ManagementFactory.java --- a/src/share/classes/java/lang/management/ManagementFactory.java Tue Jan 07 09:58:16 2014 -0800 +++ b/src/share/classes/java/lang/management/ManagementFactory.java Tue Jan 07 12:29:22 2014 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 2014, 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 @@ -612,7 +612,7 @@ " is not an instance of " + mxbeanInterface); } - final Class[] interfaces; + final Class[] interfaces; // check if the registered MBean is a notification emitter boolean emitter = connection.isInstanceOf(objName, NOTIF_EMITTER); Thanks, -Joe From paul.sandoz at oracle.com Tue Jan 7 20:40:09 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 7 Jan 2014 21:40:09 +0100 Subject: JDK 9 RFR of raw type lint fix to java.lang.management In-Reply-To: <52CC63D4.2010104@oracle.com> References: <52CC63D4.2010104@oracle.com> Message-ID: <1720D8A2-17CE-4651-8394-B6B9EE1D79A5@oracle.com> +1 Paul. On Jan 7, 2014, at 9:30 PM, Joe Darcy wrote: > Hello, > > Please review another minor lint fix of a raw type issues in the core libraries: > > diff -r 2647b91dbc2a src/share/classes/java/lang/management/ManagementFactory.java > --- a/src/share/classes/java/lang/management/ManagementFactory.java Tue Jan 07 09:58:16 2014 -0800 > +++ b/src/share/classes/java/lang/management/ManagementFactory.java Tue Jan 07 12:29:22 2014 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2003, 2014, 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 > @@ -612,7 +612,7 @@ > " is not an instance of " + mxbeanInterface); > } > > - final Class[] interfaces; > + final Class[] interfaces; > // check if the registered MBean is a notification emitter > boolean emitter = connection.isInstanceOf(objName, NOTIF_EMITTER); > > > Thanks, > > -Joe From Lance.Andersen at oracle.com Tue Jan 7 20:41:47 2014 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Tue, 7 Jan 2014 15:41:47 -0500 Subject: JDK 9 RFR of raw type lint fix to java.lang.management In-Reply-To: <52CC63D4.2010104@oracle.com> References: <52CC63D4.2010104@oracle.com> Message-ID: <7F0224B5-C5A8-48B7-B822-D21D3F71350C@oracle.com> +1 On Jan 7, 2014, at 3:30 PM, Joe Darcy wrote: > Hello, > > Please review another minor lint fix of a raw type issues in the core libraries: > > diff -r 2647b91dbc2a src/share/classes/java/lang/management/ManagementFactory.java > --- a/src/share/classes/java/lang/management/ManagementFactory.java Tue Jan 07 09:58:16 2014 -0800 > +++ b/src/share/classes/java/lang/management/ManagementFactory.java Tue Jan 07 12:29:22 2014 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2003, 2014, 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 > @@ -612,7 +612,7 @@ > " is not an instance of " + mxbeanInterface); > } > > - final Class[] interfaces; > + final Class[] interfaces; > // check if the registered MBean is a notification emitter > boolean emitter = connection.isInstanceOf(objName, NOTIF_EMITTER); > > > Thanks, > > -Joe -------------- next part -------------- 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 srikalyan.chandrashekar at oracle.com Tue Jan 7 20:55:41 2014 From: srikalyan.chandrashekar at oracle.com (srikalyan chandrashekar) Date: Tue, 07 Jan 2014 12:55:41 -0800 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52CBBDEC.9030702@gmail.com> References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> <52CB6330.3090901@oracle.com> <52CBBDEC.9030702@gmail.com> Message-ID: <52CC69CD.2090600@oracle.com> Peter, getting state info out(to console or otherwise) from within Reference Handler's exceptions handlers have been unsuccessful. However David's suggestion produced some useful trace with fast debug build and could get some information , see the log here . --- Thanks kalyan On 01/07/2014 12:42 AM, Peter Levart wrote: > On 01/07/2014 03:15 AM, srikalyan chandrashekar wrote: >> Sure David will give that a try, we have so far attempted to >> 1. Print state data(as per the test creator peter.levart's inputs), > > Hi Kalyan, > > Have you been able to reproduce the OOME in that set-up? What was the > result? > > Regards, Peter > >> 2. Use UEH(uncaught exception handler per Mandy's inputs) >> >> -- >> Thanks >> kalyan >> >> On 1/6/14 4:40 PM, David Holmes wrote: >>> Back from vacation ... >>> >>> On 20/12/2013 4:49 PM, David Holmes wrote: >>>> On 20/12/2013 12:57 PM, srikalyan chandrashekar wrote: >>>>> Hi David Thanks for your comments, the unguarded part(clean and >>>>> enqueue) >>>>> in the Reference Handler thread does not seem to create any new >>>>> objects, >>>>> so it is the application(the test in this case) which is adding >>>>> objects >>>>> to heap and causing the Reference Handler to die with OOME. >>>> >>>> The ReferenceHandler thread can only get OOME if it allocates >>>> (directly >>>> or indirectly) - so there has to be something in the unguarded part >>>> that >>>> causes this. Again it may be an implicit action in the VM - similar to >>>> the class load issue for InterruptedException. >>> >>> Run a debug VM with -XX:+TraceExceptions to see where the OOME is >>> triggered. >>> >>> David >>> ----- >>> >>>> David >>>> >>>> I am still >>>>> unsure about the side effects of the code change and agree with your >>>>> thoughts(on memory exhaustion test's reliability). >>>>> >>>>> PS: hotspot dev alias removed from CC. >>>>> >>>>> -- >>>>> Thanks >>>>> kalyan >>>>> >>>>> On 12/19/13 5:08 PM, David Holmes wrote: >>>>>> Hi Kalyan, >>>>>> >>>>>> This is not a hotspot issue so I'm moving this to core-libs, please >>>>>> drop hotspot from any replies. >>>>>> >>>>>> On 20/12/2013 6:26 AM, srikalyan wrote: >>>>>>> Hi all, I have been working on the bug JDK-8022321 >>>>>>> , this is a >>>>>>> sporadic >>>>>>> failure and the webrev is available here >>>>>>> http://cr.openjdk.java.net/~srikchan/Regression/JDK-8022321_OOMEInReferenceHandler-webrev/ >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> I'm really not sure what to make of this. We have a test that >>>>>> triggers >>>>>> an out-of-memory condition but the OOME can actually turn up in the >>>>>> ReferenceHandler thread causing it to terminate and the test to >>>>>> fail. >>>>>> We previously accounted for the non-obvious occurrences of OOME >>>>>> due to >>>>>> the Object.wait and the possible need to load the >>>>>> InterruptedException >>>>>> class - but still the OOME can appear where we don't want it. So >>>>>> finally you have just placed the whole for(;;) loop in a >>>>>> try/catch(OOME) that ignores the OOME. I'm certain that makes the >>>>>> test >>>>>> happy, but I'm not sure it is really what we want for the >>>>>> ReferenceHandler thread. If the OOME occurs while cleaning, or >>>>>> enqueuing then we will fail to clean and/or enqueue but there >>>>>> would be >>>>>> no indication that has occurred and I think that is a bigger problem >>>>>> than this test failing. >>>>>> >>>>>> There may be no way to make this test 100% reliable. In fact I'd >>>>>> suggest that no memory exhaustion test can be 100% reliable. >>>>>> >>>>>> David >>>>>> >>>>>>> * >>>>>>> **"Root Cause:Still not known"* >>>>>>> 2 places where there is a possibility for OOME >>>>>>> 1) Cleaner.clean() >>>>>>> 2) ReferenceQueue.enqueue() >>>>>>> >>>>>>> 1) The cleanup code in turn has 2 places where there is >>>>>>> potential for >>>>>>> throwing OOME, >>>>>>> a) thunk Thread which is run from clean() method. This >>>>>>> Runnable is >>>>>>> passed to Cleaner and appears in the following classes >>>>>>> java/nio/DirectByteBuffer.java >>>>>>> sun/misc/Perf.java >>>>>>> sun/nio/fs/NativeBuffer.java >>>>>>> sun/nio/ch/IOVecWrapper.java >>>>>>> sun/misc/Cleaner/ExitOnThrow.java >>>>>>> However none of the above overridden implementations ever create an >>>>>>> object in the clean() code. >>>>>>> b) new PrivilegedAction created in try catch Exception >>>>>>> block of >>>>>>> clean() method but for this object to be created and to be held >>>>>>> responsible for OOME an Exception(other than OOME) has to be >>>>>>> thrown. >>>>>>> >>>>>>> 2) No new heap objects are created in the enqueue method nor >>>>>>> anywhere in >>>>>>> the deep call stack (VM.addFinalRefCount() etc) so this cannot be a >>>>>>> potential cause. >>>>>>> >>>>>>> *Experimental change to java.lang.Reference.java* : >>>>>>> - Put one more guard (try catch with OOME block) in the Reference >>>>>>> Handler Thread which may give the Reference Handler a chance to >>>>>>> cleanup. >>>>>>> This is fixing the test failure (several 1000 runs with 0 failures) >>>>>>> - Without the above change the test fails atleast 3-5 times for >>>>>>> every >>>>>>> 1000 run. >>>>>>> >>>>>>> *PS*: The code change is to a very critical part of JDK and i am >>>>>>> fully >>>>>>> not aware of the consequences of the change, hence seeking >>>>>>> expert help >>>>>>> here. Appreciate your time and inputs towards this. >>>>>>> >>>>> >> > From Alan.Bateman at oracle.com Tue Jan 7 20:50:34 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 07 Jan 2014 20:50:34 +0000 Subject: JDK 9 RFR of raw type lint fix to java.lang.management In-Reply-To: <52CC63D4.2010104@oracle.com> References: <52CC63D4.2010104@oracle.com> Message-ID: <52CC689A.3070201@oracle.com> On 07/01/2014 20:30, Joe Darcy wrote: > Hello, > > Please review another minor lint fix of a raw type issues in the core > libraries: Looks good. -Alan. From srikalyan.chandrashekar at oracle.com Tue Jan 7 21:33:31 2014 From: srikalyan.chandrashekar at oracle.com (srikalyan chandrashekar) Date: Tue, 07 Jan 2014 13:33:31 -0800 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52CB4CFC.9070405@oracle.com> References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> Message-ID: <52CC72AB.2020104@oracle.com> Hi David, TraceExceptions with fastdebug build produced some nice trace . The native method wait(long) is where the OOME if being thrown, the deepest call is in src/share/vm/gc_interface/collectedHeap.inline.hpp, line 157 ------------------- Excerpt Begins --------------------- 147 if (!gc_overhead_limit_was_exceeded) { 148 // -XX:+HeapDumpOnOutOfMemoryError and -XX:OnOutOfMemoryError support 149 report_java_out_of_memory("Java heap space"); 150 151 if (JvmtiExport::should_post_resource_exhausted()) { 152 JvmtiExport::post_resource_exhausted( 153 JVMTI_RESOURCE_EXHAUSTED_OOM_ERROR | JVMTI_RESOURCE_EXHAUSTED_JAVA_HEAP, 154 "Java heap space"); 155 } 156 157 THROW_OOP_0(Universe::out_of_memory_error_java_heap()); 158 } else { ------------------- Excerpt Ends --------------------- Would be helpful if David/some one else in the team could explain the latent aspects/probable cause. --- Thanks kalyan On 01/06/2014 04:40 PM, David Holmes wrote: > Back from vacation ... > > On 20/12/2013 4:49 PM, David Holmes wrote: >> On 20/12/2013 12:57 PM, srikalyan chandrashekar wrote: >>> Hi David Thanks for your comments, the unguarded part(clean and >>> enqueue) >>> in the Reference Handler thread does not seem to create any new >>> objects, >>> so it is the application(the test in this case) which is adding objects >>> to heap and causing the Reference Handler to die with OOME. >> >> The ReferenceHandler thread can only get OOME if it allocates (directly >> or indirectly) - so there has to be something in the unguarded part that >> causes this. Again it may be an implicit action in the VM - similar to >> the class load issue for InterruptedException. > > Run a debug VM with -XX:+TraceExceptions to see where the OOME is > triggered. > > David > ----- > >> David >> >> I am still >>> unsure about the side effects of the code change and agree with your >>> thoughts(on memory exhaustion test's reliability). >>> >>> PS: hotspot dev alias removed from CC. >>> >>> -- >>> Thanks >>> kalyan >>> >>> On 12/19/13 5:08 PM, David Holmes wrote: >>>> Hi Kalyan, >>>> >>>> This is not a hotspot issue so I'm moving this to core-libs, please >>>> drop hotspot from any replies. >>>> >>>> On 20/12/2013 6:26 AM, srikalyan wrote: >>>>> Hi all, I have been working on the bug JDK-8022321 >>>>> , this is a >>>>> sporadic >>>>> failure and the webrev is available here >>>>> http://cr.openjdk.java.net/~srikchan/Regression/JDK-8022321_OOMEInReferenceHandler-webrev/ >>>>> >>>>> >>>>> >>>> >>>> I'm really not sure what to make of this. We have a test that triggers >>>> an out-of-memory condition but the OOME can actually turn up in the >>>> ReferenceHandler thread causing it to terminate and the test to fail. >>>> We previously accounted for the non-obvious occurrences of OOME due to >>>> the Object.wait and the possible need to load the InterruptedException >>>> class - but still the OOME can appear where we don't want it. So >>>> finally you have just placed the whole for(;;) loop in a >>>> try/catch(OOME) that ignores the OOME. I'm certain that makes the test >>>> happy, but I'm not sure it is really what we want for the >>>> ReferenceHandler thread. If the OOME occurs while cleaning, or >>>> enqueuing then we will fail to clean and/or enqueue but there would be >>>> no indication that has occurred and I think that is a bigger problem >>>> than this test failing. >>>> >>>> There may be no way to make this test 100% reliable. In fact I'd >>>> suggest that no memory exhaustion test can be 100% reliable. >>>> >>>> David >>>> >>>>> * >>>>> **"Root Cause:Still not known"* >>>>> 2 places where there is a possibility for OOME >>>>> 1) Cleaner.clean() >>>>> 2) ReferenceQueue.enqueue() >>>>> >>>>> 1) The cleanup code in turn has 2 places where there is potential >>>>> for >>>>> throwing OOME, >>>>> a) thunk Thread which is run from clean() method. This >>>>> Runnable is >>>>> passed to Cleaner and appears in the following classes >>>>> java/nio/DirectByteBuffer.java >>>>> sun/misc/Perf.java >>>>> sun/nio/fs/NativeBuffer.java >>>>> sun/nio/ch/IOVecWrapper.java >>>>> sun/misc/Cleaner/ExitOnThrow.java >>>>> However none of the above overridden implementations ever create an >>>>> object in the clean() code. >>>>> b) new PrivilegedAction created in try catch Exception block of >>>>> clean() method but for this object to be created and to be held >>>>> responsible for OOME an Exception(other than OOME) has to be thrown. >>>>> >>>>> 2) No new heap objects are created in the enqueue method nor >>>>> anywhere in >>>>> the deep call stack (VM.addFinalRefCount() etc) so this cannot be a >>>>> potential cause. >>>>> >>>>> *Experimental change to java.lang.Reference.java* : >>>>> - Put one more guard (try catch with OOME block) in the Reference >>>>> Handler Thread which may give the Reference Handler a chance to >>>>> cleanup. >>>>> This is fixing the test failure (several 1000 runs with 0 failures) >>>>> - Without the above change the test fails atleast 3-5 times for every >>>>> 1000 run. >>>>> >>>>> *PS*: The code change is to a very critical part of JDK and i am >>>>> fully >>>>> not aware of the consequences of the change, hence seeking expert >>>>> help >>>>> here. Appreciate your time and inputs towards this. >>>>> >>> From mandy.chung at oracle.com Tue Jan 7 22:25:15 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 07 Jan 2014 14:25:15 -0800 Subject: JDK 9 RFR of raw type lint fix to java.lang.management In-Reply-To: <52CC63D4.2010104@oracle.com> References: <52CC63D4.2010104@oracle.com> Message-ID: <52CC7ECB.1080309@oracle.com> On 1/7/2014 12:30 PM, Joe Darcy wrote: > Hello, > > Please review another minor lint fix of a raw type issues in the core > libraries: Looks good. cc'ing serviceability-dev as java.lang.management is owned by the serviceability team. Mandy From joe.darcy at oracle.com Tue Jan 7 22:26:00 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 07 Jan 2014 14:26:00 -0800 Subject: JDK 9 proposal: remove sun.misc.Ref Message-ID: <52CC7EF8.8040208@oracle.com> Hello, As part of the lint clean up of core libraries, I noticed a number of warnings in the class sun.misc.Ref. Notable excerpts from the file: > > /* > * Copyright (c) 1995, 2004, Oracle and/or its affiliates. All rights > reserved. > ... > * @deprecated This class has been replaced by > * java.util.SoftReference. > * > ... > * > */ > @Deprecated > > public abstract class Ref { So the type has been deprecated for at least 10 years. Rather than fixing the warning in the class, I think the best course of action is to remove the file in JDK 9. A build of OpenJDK without this file builds fine; if a build of the closed sources goes fine to, I think that should be sufficient justification for this type to be removed. Using code search engines, there are just a handful of references to sun.misc.Ref in the wihld, but any such uses will have several years to migrate to the standard java.util.SoftReference before JDK 9 ships. Comments? -Joe From joe.darcy at oracle.com Tue Jan 7 23:58:12 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 07 Jan 2014 15:58:12 -0800 Subject: JDK 9 RFR of JDK-8031369: Fix raw types warnings in sun.misc.{Cache, SoftCache} Message-ID: <52CC9494.7020003@oracle.com> Hello, Please review the fix below to address JDK-8031369: Fix raw types warnings in sun.misc.{Cache, SoftCache} by a quick-and-dirty generification and deprecation of some very old classes http://cr.openjdk.java.net/~darcy/8031369.0/ Corresponding patch below. In the fullness of time, these classes should probably be removed from the platform, but for the moment I'm more concerned with eliminating the several dozen lint warnings in this code. Thanks, -Joe --- old/src/share/classes/sun/misc/Cache.java 2014-01-07 15:51:32.000000000 -0800 +++ new/src/share/classes/sun/misc/Cache.java 2014-01-07 15:51:32.000000000 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1995, 1996, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1995, 2014, 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 @@ -74,8 +74,9 @@ * @see java.lang.Object#equals * @see sun.misc.Ref */ + at Deprecated public -class Cache extends Dictionary { + class Cache extends Dictionary { /** * The hash table data. */ @@ -163,7 +164,7 @@ * @see Cache#elements * @see Enumeration */ - public synchronized Enumeration keys() { + public synchronized Enumeration keys() { return new CacheEnumerator(table, true); } @@ -173,7 +174,7 @@ * @see Cache#keys * @see Enumeration */ - public synchronized Enumeration elements() { + public synchronized Enumeration elements() { return new CacheEnumerator(table, false); } @@ -305,7 +306,7 @@ * A Cache enumerator class. This class should remain opaque * to the client. It will use the Enumeration interface. */ -class CacheEnumerator implements Enumeration { +class CacheEnumerator implements Enumeration { boolean keys; int index; CacheEntry table[]; --- old/src/share/classes/sun/misc/SoftCache.java 2014-01-07 15:51:33.000000000 -0800 +++ new/src/share/classes/sun/misc/SoftCache.java 2014-01-07 15:51:33.000000000 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1998, 2006, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1998, 2014, 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 @@ -101,8 +101,8 @@ * @see java.lang.ref.SoftReference */ - -public class SoftCache extends AbstractMap implements Map { + at Deprecated +public class SoftCache extends AbstractMap implements Map { /* The basic idea of this implementation is to maintain an internal HashMap that maps keys to soft references whose referents are the keys' values; @@ -115,18 +115,18 @@ */ - static private class ValueCell extends SoftReference { + static private class ValueCell extends SoftReference { static private Object INVALID_KEY = new Object(); static private int dropped = 0; private Object key; - private ValueCell(Object key, Object value, ReferenceQueue queue) { + private ValueCell(Object key, Object value, ReferenceQueue queue) { super(value, queue); this.key = key; } private static ValueCell create(Object key, Object value, - ReferenceQueue queue) + ReferenceQueue queue) { if (value == null) return null; return new ValueCell(key, value, queue); @@ -154,10 +154,10 @@ /* Hash table mapping keys to ValueCells */ - private Map hash; + private Map hash; /* Reference queue for cleared ValueCells */ - private ReferenceQueue queue = new ReferenceQueue(); + private ReferenceQueue queue = new ReferenceQueue<>(); /* Process any ValueCells that have been cleared and enqueued by the @@ -189,7 +189,7 @@ * factor is less than zero */ public SoftCache(int initialCapacity, float loadFactor) { - hash = new HashMap(initialCapacity, loadFactor); + hash = new HashMap<>(initialCapacity, loadFactor); } /** @@ -202,7 +202,7 @@ * or equal to zero */ public SoftCache(int initialCapacity) { - hash = new HashMap(initialCapacity); + hash = new HashMap<>(initialCapacity); } /** @@ -210,7 +210,7 @@ * capacity and the default load factor. */ public SoftCache() { - hash = new HashMap(); + hash = new HashMap<>(); } @@ -348,13 +348,13 @@ /* Internal class for entries. Because it uses SoftCache.this.queue, this class cannot be static. */ - private class Entry implements Map.Entry { - private Map.Entry ent; + private class Entry implements Map.Entry { + private Map.Entry ent; private Object value; /* Strong reference to value, to prevent the GC from flushing the value while this Entry exists */ - Entry(Map.Entry ent, Object value) { + Entry(Map.Entry ent, Object value) { this.ent = ent; this.value = value; } @@ -371,9 +371,10 @@ return ent.setValue(ValueCell.create(ent.getKey(), value, queue)); } + @SuppressWarnings("unchecked") public boolean equals(Object o) { if (! (o instanceof Map.Entry)) return false; - Map.Entry e = (Map.Entry)o; + Map.Entry e = (Map.Entry)o; return (valEquals(ent.getKey(), e.getKey()) && valEquals(value, e.getValue())); } @@ -388,18 +389,18 @@ /* Internal class for entry sets */ - private class EntrySet extends AbstractSet { - Set hashEntries = hash.entrySet(); + private class EntrySet extends AbstractSet> { + Set> hashEntries = hash.entrySet(); - public Iterator iterator() { + public Iterator> iterator() { - return new Iterator() { - Iterator hashIterator = hashEntries.iterator(); + return new Iterator>() { + Iterator> hashIterator = hashEntries.iterator(); Entry next = null; public boolean hasNext() { while (hashIterator.hasNext()) { - Map.Entry ent = (Map.Entry)hashIterator.next(); + Map.Entry ent = hashIterator.next(); ValueCell vc = (ValueCell)ent.getValue(); Object v = null; if ((vc != null) && ((v = vc.get()) == null)) { @@ -412,7 +413,7 @@ return false; } - public Object next() { + public Map.Entry next() { if ((next == null) && !hasNext()) throw new NoSuchElementException(); Entry e = next; @@ -433,7 +434,7 @@ public int size() { int j = 0; - for (Iterator i = iterator(); i.hasNext(); i.next()) j++; + for (Iterator> i = iterator(); i.hasNext(); i.next()) j++; return j; } @@ -446,12 +447,12 @@ } - private Set entrySet = null; + private Set> entrySet = null; /** * Return a Set view of the mappings in this cache. */ - public Set entrySet() { + public Set> entrySet() { if (entrySet == null) entrySet = new EntrySet(); return entrySet; } From dan.xu at oracle.com Wed Jan 8 00:50:28 2014 From: dan.xu at oracle.com (Dan Xu) Date: Tue, 07 Jan 2014 16:50:28 -0800 Subject: RFR: JDK-8028726 - (prefs) Check src/solaris/native/java/util/FileSystemPreferences.c for JNI pending exceptions In-Reply-To: <52CBCAB4.1040700@oracle.com> References: <52CB2E4E.7080200@oracle.com> <52CBCAB4.1040700@oracle.com> Message-ID: <52CCA0D4.3040907@oracle.com> Hi All, Thanks for your good review. I have dropped the change in FileSystemPreferences.java , and created the new webrev which only changes FileSystemPreferences.c. Please help review it. Thanks! Webrev: http://cr.openjdk.java.net/~dxu/8028726/webrev.01/ When changing FileSystemPreferences.c, I noticed the code like "JNU_GetStringPlatformChars(env, java_fname, JNI_FALSE)". Because JNI_FALSE is passed into this function, I am wondering why our code still release string by calling JNU_ReleaseStringPlatformChars(env, java_fname, fname). Thanks! -Dan On 01/07/2014 01:36 AM, Alan Bateman wrote: > On 06/01/2014 22:29, Dan Xu wrote: >> Hi All, >> >> Please review the simple fix for JNI pending exceptions in >> FileSystemPreferences.c. Thanks! >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8028726 >> Webrev: http://cr.openjdk.java.net/~dxu/8028726/webrev/ > The update to FIleSystemPreferences.c looks okay but if I read it > correctly then lockFile0 can never return NULL without a pending > exception (meaning that the change to FileSystemPreferences.java could > mask an underlying bug if it existed). > > One passing comment is that this native methods could be completely > eliminated here by changing FileSystemPreferences to lock the file via > a FileChannel (use a FileLock as the lock handle). Also the chmod > usage can be eliminated by mkdirs with Files.createDirectory and > specify the permission files when creating the directory. I realize > this is beyond the scope of what you are doing here (but an > opportunity none the less). > > -Alan From mike.duigou at oracle.com Wed Jan 8 01:23:35 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 7 Jan 2014 17:23:35 -0800 Subject: JDK 9 RFR of JDK-8031369: Fix raw types warnings in sun.misc.{Cache, SoftCache} In-Reply-To: <52CC9494.7020003@oracle.com> References: <52CC9494.7020003@oracle.com> Message-ID: <4DF19DFF-249D-4FAA-A5E8-D8458BF1CC55@oracle.com> Can you add the javadoc @deprecated deprecation notice as well? Otherwise looks good. Mike On Jan 7 2014, at 15:58 , Joe Darcy wrote: > Hello, > > Please review the fix below to address > > JDK-8031369: Fix raw types warnings in sun.misc.{Cache, SoftCache} > > by a quick-and-dirty generification and deprecation of some very old classes > > http://cr.openjdk.java.net/~darcy/8031369.0/ > > Corresponding patch below. > > In the fullness of time, these classes should probably be removed from the platform, but for the moment I'm more concerned with eliminating the several dozen lint warnings in this code. > > Thanks, > > -Joe > > --- old/src/share/classes/sun/misc/Cache.java 2014-01-07 15:51:32.000000000 -0800 > +++ new/src/share/classes/sun/misc/Cache.java 2014-01-07 15:51:32.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1995, 1996, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1995, 2014, 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 > @@ -74,8 +74,9 @@ > * @see java.lang.Object#equals > * @see sun.misc.Ref > */ > + at Deprecated > public > -class Cache extends Dictionary { > + class Cache extends Dictionary { > /** > * The hash table data. > */ > @@ -163,7 +164,7 @@ > * @see Cache#elements > * @see Enumeration > */ > - public synchronized Enumeration keys() { > + public synchronized Enumeration keys() { > return new CacheEnumerator(table, true); > } > > @@ -173,7 +174,7 @@ > * @see Cache#keys > * @see Enumeration > */ > - public synchronized Enumeration elements() { > + public synchronized Enumeration elements() { > return new CacheEnumerator(table, false); > } > > @@ -305,7 +306,7 @@ > * A Cache enumerator class. This class should remain opaque > * to the client. It will use the Enumeration interface. > */ > -class CacheEnumerator implements Enumeration { > +class CacheEnumerator implements Enumeration { > boolean keys; > int index; > CacheEntry table[]; > --- old/src/share/classes/sun/misc/SoftCache.java 2014-01-07 15:51:33.000000000 -0800 > +++ new/src/share/classes/sun/misc/SoftCache.java 2014-01-07 15:51:33.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1998, 2006, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1998, 2014, 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 > @@ -101,8 +101,8 @@ > * @see java.lang.ref.SoftReference > */ > > - > -public class SoftCache extends AbstractMap implements Map { > + at Deprecated > +public class SoftCache extends AbstractMap implements Map { > > /* The basic idea of this implementation is to maintain an internal HashMap > that maps keys to soft references whose referents are the keys' values; > @@ -115,18 +115,18 @@ > */ > > > - static private class ValueCell extends SoftReference { > + static private class ValueCell extends SoftReference { > static private Object INVALID_KEY = new Object(); > static private int dropped = 0; > private Object key; > > - private ValueCell(Object key, Object value, ReferenceQueue queue) { > + private ValueCell(Object key, Object value, ReferenceQueue queue) { > super(value, queue); > this.key = key; > } > > private static ValueCell create(Object key, Object value, > - ReferenceQueue queue) > + ReferenceQueue queue) > { > if (value == null) return null; > return new ValueCell(key, value, queue); > @@ -154,10 +154,10 @@ > > > /* Hash table mapping keys to ValueCells */ > - private Map hash; > + private Map hash; > > /* Reference queue for cleared ValueCells */ > - private ReferenceQueue queue = new ReferenceQueue(); > + private ReferenceQueue queue = new ReferenceQueue<>(); > > > /* Process any ValueCells that have been cleared and enqueued by the > @@ -189,7 +189,7 @@ > * factor is less than zero > */ > public SoftCache(int initialCapacity, float loadFactor) { > - hash = new HashMap(initialCapacity, loadFactor); > + hash = new HashMap<>(initialCapacity, loadFactor); > } > > /** > @@ -202,7 +202,7 @@ > * or equal to zero > */ > public SoftCache(int initialCapacity) { > - hash = new HashMap(initialCapacity); > + hash = new HashMap<>(initialCapacity); > } > > /** > @@ -210,7 +210,7 @@ > * capacity and the default load factor. > */ > public SoftCache() { > - hash = new HashMap(); > + hash = new HashMap<>(); > } > > > @@ -348,13 +348,13 @@ > /* Internal class for entries. > Because it uses SoftCache.this.queue, this class cannot be static. > */ > - private class Entry implements Map.Entry { > - private Map.Entry ent; > + private class Entry implements Map.Entry { > + private Map.Entry ent; > private Object value; /* Strong reference to value, to prevent the GC > from flushing the value while this Entry > exists */ > > - Entry(Map.Entry ent, Object value) { > + Entry(Map.Entry ent, Object value) { > this.ent = ent; > this.value = value; > } > @@ -371,9 +371,10 @@ > return ent.setValue(ValueCell.create(ent.getKey(), value, queue)); > } > > + @SuppressWarnings("unchecked") > public boolean equals(Object o) { > if (! (o instanceof Map.Entry)) return false; > - Map.Entry e = (Map.Entry)o; > + Map.Entry e = (Map.Entry)o; > return (valEquals(ent.getKey(), e.getKey()) > && valEquals(value, e.getValue())); > } > @@ -388,18 +389,18 @@ > > > /* Internal class for entry sets */ > - private class EntrySet extends AbstractSet { > - Set hashEntries = hash.entrySet(); > + private class EntrySet extends AbstractSet> { > + Set> hashEntries = hash.entrySet(); > > - public Iterator iterator() { > + public Iterator> iterator() { > > - return new Iterator() { > - Iterator hashIterator = hashEntries.iterator(); > + return new Iterator>() { > + Iterator> hashIterator = hashEntries.iterator(); > Entry next = null; > > public boolean hasNext() { > while (hashIterator.hasNext()) { > - Map.Entry ent = (Map.Entry)hashIterator.next(); > + Map.Entry ent = hashIterator.next(); > ValueCell vc = (ValueCell)ent.getValue(); > Object v = null; > if ((vc != null) && ((v = vc.get()) == null)) { > @@ -412,7 +413,7 @@ > return false; > } > > - public Object next() { > + public Map.Entry next() { > if ((next == null) && !hasNext()) > throw new NoSuchElementException(); > Entry e = next; > @@ -433,7 +434,7 @@ > > public int size() { > int j = 0; > - for (Iterator i = iterator(); i.hasNext(); i.next()) j++; > + for (Iterator> i = iterator(); i.hasNext(); i.next()) j++; > return j; > } > > @@ -446,12 +447,12 @@ > } > > > - private Set entrySet = null; > + private Set> entrySet = null; > > /** > * Return a Set view of the mappings in this cache. > */ > - public Set entrySet() { > + public Set> entrySet() { > if (entrySet == null) entrySet = new EntrySet(); > return entrySet; > } > From joe.darcy at oracle.com Wed Jan 8 01:39:16 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 07 Jan 2014 17:39:16 -0800 Subject: JDK 9 RFR of JDK-8031369: Fix raw types warnings in sun.misc.{Cache, SoftCache} In-Reply-To: <4DF19DFF-249D-4FAA-A5E8-D8458BF1CC55@oracle.com> References: <52CC9494.7020003@oracle.com> <4DF19DFF-249D-4FAA-A5E8-D8458BF1CC55@oracle.com> Message-ID: <52CCAC44.50404@oracle.com> Hi Mike, On 01/07/2014 05:23 PM, Mike Duigou wrote: > Can you add the javadoc @deprecated deprecation notice as well? Sure; for Cache I'll point to LinkedHashMap and I'll look into finding a alternative to SoftCache. Thanks for the review, -Joe > > Otherwise looks good. > > Mike > On Jan 7 2014, at 15:58 , Joe Darcy wrote: > >> Hello, >> >> Please review the fix below to address >> >> JDK-8031369: Fix raw types warnings in sun.misc.{Cache, SoftCache} >> >> by a quick-and-dirty generification and deprecation of some very old classes >> >> http://cr.openjdk.java.net/~darcy/8031369.0/ >> >> Corresponding patch below. >> >> In the fullness of time, these classes should probably be removed from the platform, but for the moment I'm more concerned with eliminating the several dozen lint warnings in this code. >> >> Thanks, >> >> -Joe >> >> --- old/src/share/classes/sun/misc/Cache.java 2014-01-07 15:51:32.000000000 -0800 >> +++ new/src/share/classes/sun/misc/Cache.java 2014-01-07 15:51:32.000000000 -0800 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 1995, 1996, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 1995, 2014, 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 >> @@ -74,8 +74,9 @@ >> * @see java.lang.Object#equals >> * @see sun.misc.Ref >> */ >> + at Deprecated >> public >> -class Cache extends Dictionary { >> + class Cache extends Dictionary { >> /** >> * The hash table data. >> */ >> @@ -163,7 +164,7 @@ >> * @see Cache#elements >> * @see Enumeration >> */ >> - public synchronized Enumeration keys() { >> + public synchronized Enumeration keys() { >> return new CacheEnumerator(table, true); >> } >> >> @@ -173,7 +174,7 @@ >> * @see Cache#keys >> * @see Enumeration >> */ >> - public synchronized Enumeration elements() { >> + public synchronized Enumeration elements() { >> return new CacheEnumerator(table, false); >> } >> >> @@ -305,7 +306,7 @@ >> * A Cache enumerator class. This class should remain opaque >> * to the client. It will use the Enumeration interface. >> */ >> -class CacheEnumerator implements Enumeration { >> +class CacheEnumerator implements Enumeration { >> boolean keys; >> int index; >> CacheEntry table[]; >> --- old/src/share/classes/sun/misc/SoftCache.java 2014-01-07 15:51:33.000000000 -0800 >> +++ new/src/share/classes/sun/misc/SoftCache.java 2014-01-07 15:51:33.000000000 -0800 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 1998, 2006, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 1998, 2014, 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 >> @@ -101,8 +101,8 @@ >> * @see java.lang.ref.SoftReference >> */ >> >> - >> -public class SoftCache extends AbstractMap implements Map { >> + at Deprecated >> +public class SoftCache extends AbstractMap implements Map { >> >> /* The basic idea of this implementation is to maintain an internal HashMap >> that maps keys to soft references whose referents are the keys' values; >> @@ -115,18 +115,18 @@ >> */ >> >> >> - static private class ValueCell extends SoftReference { >> + static private class ValueCell extends SoftReference { >> static private Object INVALID_KEY = new Object(); >> static private int dropped = 0; >> private Object key; >> >> - private ValueCell(Object key, Object value, ReferenceQueue queue) { >> + private ValueCell(Object key, Object value, ReferenceQueue queue) { >> super(value, queue); >> this.key = key; >> } >> >> private static ValueCell create(Object key, Object value, >> - ReferenceQueue queue) >> + ReferenceQueue queue) >> { >> if (value == null) return null; >> return new ValueCell(key, value, queue); >> @@ -154,10 +154,10 @@ >> >> >> /* Hash table mapping keys to ValueCells */ >> - private Map hash; >> + private Map hash; >> >> /* Reference queue for cleared ValueCells */ >> - private ReferenceQueue queue = new ReferenceQueue(); >> + private ReferenceQueue queue = new ReferenceQueue<>(); >> >> >> /* Process any ValueCells that have been cleared and enqueued by the >> @@ -189,7 +189,7 @@ >> * factor is less than zero >> */ >> public SoftCache(int initialCapacity, float loadFactor) { >> - hash = new HashMap(initialCapacity, loadFactor); >> + hash = new HashMap<>(initialCapacity, loadFactor); >> } >> >> /** >> @@ -202,7 +202,7 @@ >> * or equal to zero >> */ >> public SoftCache(int initialCapacity) { >> - hash = new HashMap(initialCapacity); >> + hash = new HashMap<>(initialCapacity); >> } >> >> /** >> @@ -210,7 +210,7 @@ >> * capacity and the default load factor. >> */ >> public SoftCache() { >> - hash = new HashMap(); >> + hash = new HashMap<>(); >> } >> >> >> @@ -348,13 +348,13 @@ >> /* Internal class for entries. >> Because it uses SoftCache.this.queue, this class cannot be static. >> */ >> - private class Entry implements Map.Entry { >> - private Map.Entry ent; >> + private class Entry implements Map.Entry { >> + private Map.Entry ent; >> private Object value; /* Strong reference to value, to prevent the GC >> from flushing the value while this Entry >> exists */ >> >> - Entry(Map.Entry ent, Object value) { >> + Entry(Map.Entry ent, Object value) { >> this.ent = ent; >> this.value = value; >> } >> @@ -371,9 +371,10 @@ >> return ent.setValue(ValueCell.create(ent.getKey(), value, queue)); >> } >> >> + @SuppressWarnings("unchecked") >> public boolean equals(Object o) { >> if (! (o instanceof Map.Entry)) return false; >> - Map.Entry e = (Map.Entry)o; >> + Map.Entry e = (Map.Entry)o; >> return (valEquals(ent.getKey(), e.getKey()) >> && valEquals(value, e.getValue())); >> } >> @@ -388,18 +389,18 @@ >> >> >> /* Internal class for entry sets */ >> - private class EntrySet extends AbstractSet { >> - Set hashEntries = hash.entrySet(); >> + private class EntrySet extends AbstractSet> { >> + Set> hashEntries = hash.entrySet(); >> >> - public Iterator iterator() { >> + public Iterator> iterator() { >> >> - return new Iterator() { >> - Iterator hashIterator = hashEntries.iterator(); >> + return new Iterator>() { >> + Iterator> hashIterator = hashEntries.iterator(); >> Entry next = null; >> >> public boolean hasNext() { >> while (hashIterator.hasNext()) { >> - Map.Entry ent = (Map.Entry)hashIterator.next(); >> + Map.Entry ent = hashIterator.next(); >> ValueCell vc = (ValueCell)ent.getValue(); >> Object v = null; >> if ((vc != null) && ((v = vc.get()) == null)) { >> @@ -412,7 +413,7 @@ >> return false; >> } >> >> - public Object next() { >> + public Map.Entry next() { >> if ((next == null) && !hasNext()) >> throw new NoSuchElementException(); >> Entry e = next; >> @@ -433,7 +434,7 @@ >> >> public int size() { >> int j = 0; >> - for (Iterator i = iterator(); i.hasNext(); i.next()) j++; >> + for (Iterator> i = iterator(); i.hasNext(); i.next()) j++; >> return j; >> } >> >> @@ -446,12 +447,12 @@ >> } >> >> >> - private Set entrySet = null; >> + private Set> entrySet = null; >> >> /** >> * Return a Set view of the mappings in this cache. >> */ >> - public Set entrySet() { >> + public Set> entrySet() { >> if (entrySet == null) entrySet = new EntrySet(); >> return entrySet; >> } >> From stuart.marks at oracle.com Wed Jan 8 02:26:36 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 07 Jan 2014 18:26:36 -0800 Subject: JDK 9 proposal: remove sun.misc.Ref In-Reply-To: <52CC7EF8.8040208@oracle.com> References: <52CC7EF8.8040208@oracle.com> Message-ID: <52CCB75C.2060402@oracle.com> On 1/7/14 2:26 PM, Joe Darcy wrote: >> public abstract class Ref { > > So the type has been deprecated for at least 10 years. Rather than fixing the > warning in the class, I think the best course of action is to remove the file in > JDK 9. A build of OpenJDK without this file builds fine; if a build of the > closed sources goes fine to, I think that should be sufficient justification for > this type to be removed. > > Using code search engines, there are just a handful of references to > sun.misc.Ref in the wihld, but any such uses will have several years to migrate > to the standard java.util.SoftReference before JDK 9 ships. When in doubt, take it out. I had a small concern about whether sun.misc.Ref still might have had some dependencies from the JVM (i.e. special support like the java.lang.ref classes), but it looks like sun.misc.Ref itself is entirely implemented in terms of java.lang.ref.SoftReference. I did a quick search of hotspot and I couldn't find any mentions of sun.misc.Ref, so I think we're clear. s'marks From tristan.yan at oracle.com Wed Jan 8 02:38:54 2014 From: tristan.yan at oracle.com (Tristan Yan) Date: Wed, 08 Jan 2014 10:38:54 +0800 Subject: RFR for JDK-8030089: java/util/zip/ZipFile/FinalizeZipFile.java intermittently fails with fastdebug builds Message-ID: <52CCBA3E.1040909@oracle.com> Hi All Please help to review code fix for bug JDK-8030089. http://cr.openjdk.java.net/~tyan/JDK-8030089/webrev.00/ Description: 1. Set test running on othervm mode. 2. Use infinite wait to the CountDownLatch. Thank you Tristan From Lance.Andersen at oracle.com Wed Jan 8 02:41:42 2014 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Tue, 7 Jan 2014 21:41:42 -0500 Subject: JDK 9 RFR of JDK-8031369: Fix raw types warnings in sun.misc.{Cache, SoftCache} In-Reply-To: <52CC9494.7020003@oracle.com> References: <52CC9494.7020003@oracle.com> Message-ID: looks good Joe On Jan 7, 2014, at 6:58 PM, Joe Darcy wrote: > Hello, > > Please review the fix below to address > > JDK-8031369: Fix raw types warnings in sun.misc.{Cache, SoftCache} > > by a quick-and-dirty generification and deprecation of some very old classes > > http://cr.openjdk.java.net/~darcy/8031369.0/ > > Corresponding patch below. > > In the fullness of time, these classes should probably be removed from the platform, but for the moment I'm more concerned with eliminating the several dozen lint warnings in this code. > > Thanks, > > -Joe > > --- old/src/share/classes/sun/misc/Cache.java 2014-01-07 15:51:32.000000000 -0800 > +++ new/src/share/classes/sun/misc/Cache.java 2014-01-07 15:51:32.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1995, 1996, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1995, 2014, 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 > @@ -74,8 +74,9 @@ > * @see java.lang.Object#equals > * @see sun.misc.Ref > */ > + at Deprecated > public > -class Cache extends Dictionary { > + class Cache extends Dictionary { > /** > * The hash table data. > */ > @@ -163,7 +164,7 @@ > * @see Cache#elements > * @see Enumeration > */ > - public synchronized Enumeration keys() { > + public synchronized Enumeration keys() { > return new CacheEnumerator(table, true); > } > > @@ -173,7 +174,7 @@ > * @see Cache#keys > * @see Enumeration > */ > - public synchronized Enumeration elements() { > + public synchronized Enumeration elements() { > return new CacheEnumerator(table, false); > } > > @@ -305,7 +306,7 @@ > * A Cache enumerator class. This class should remain opaque > * to the client. It will use the Enumeration interface. > */ > -class CacheEnumerator implements Enumeration { > +class CacheEnumerator implements Enumeration { > boolean keys; > int index; > CacheEntry table[]; > --- old/src/share/classes/sun/misc/SoftCache.java 2014-01-07 15:51:33.000000000 -0800 > +++ new/src/share/classes/sun/misc/SoftCache.java 2014-01-07 15:51:33.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1998, 2006, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1998, 2014, 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 > @@ -101,8 +101,8 @@ > * @see java.lang.ref.SoftReference > */ > > - > -public class SoftCache extends AbstractMap implements Map { > + at Deprecated > +public class SoftCache extends AbstractMap implements Map { > > /* The basic idea of this implementation is to maintain an internal HashMap > that maps keys to soft references whose referents are the keys' values; > @@ -115,18 +115,18 @@ > */ > > > - static private class ValueCell extends SoftReference { > + static private class ValueCell extends SoftReference { > static private Object INVALID_KEY = new Object(); > static private int dropped = 0; > private Object key; > > - private ValueCell(Object key, Object value, ReferenceQueue queue) { > + private ValueCell(Object key, Object value, ReferenceQueue queue) { > super(value, queue); > this.key = key; > } > > private static ValueCell create(Object key, Object value, > - ReferenceQueue queue) > + ReferenceQueue queue) > { > if (value == null) return null; > return new ValueCell(key, value, queue); > @@ -154,10 +154,10 @@ > > > /* Hash table mapping keys to ValueCells */ > - private Map hash; > + private Map hash; > > /* Reference queue for cleared ValueCells */ > - private ReferenceQueue queue = new ReferenceQueue(); > + private ReferenceQueue queue = new ReferenceQueue<>(); > > > /* Process any ValueCells that have been cleared and enqueued by the > @@ -189,7 +189,7 @@ > * factor is less than zero > */ > public SoftCache(int initialCapacity, float loadFactor) { > - hash = new HashMap(initialCapacity, loadFactor); > + hash = new HashMap<>(initialCapacity, loadFactor); > } > > /** > @@ -202,7 +202,7 @@ > * or equal to zero > */ > public SoftCache(int initialCapacity) { > - hash = new HashMap(initialCapacity); > + hash = new HashMap<>(initialCapacity); > } > > /** > @@ -210,7 +210,7 @@ > * capacity and the default load factor. > */ > public SoftCache() { > - hash = new HashMap(); > + hash = new HashMap<>(); > } > > > @@ -348,13 +348,13 @@ > /* Internal class for entries. > Because it uses SoftCache.this.queue, this class cannot be static. > */ > - private class Entry implements Map.Entry { > - private Map.Entry ent; > + private class Entry implements Map.Entry { > + private Map.Entry ent; > private Object value; /* Strong reference to value, to prevent the GC > from flushing the value while this Entry > exists */ > > - Entry(Map.Entry ent, Object value) { > + Entry(Map.Entry ent, Object value) { > this.ent = ent; > this.value = value; > } > @@ -371,9 +371,10 @@ > return ent.setValue(ValueCell.create(ent.getKey(), value, queue)); > } > > + @SuppressWarnings("unchecked") > public boolean equals(Object o) { > if (! (o instanceof Map.Entry)) return false; > - Map.Entry e = (Map.Entry)o; > + Map.Entry e = (Map.Entry)o; > return (valEquals(ent.getKey(), e.getKey()) > && valEquals(value, e.getValue())); > } > @@ -388,18 +389,18 @@ > > > /* Internal class for entry sets */ > - private class EntrySet extends AbstractSet { > - Set hashEntries = hash.entrySet(); > + private class EntrySet extends AbstractSet> { > + Set> hashEntries = hash.entrySet(); > > - public Iterator iterator() { > + public Iterator> iterator() { > > - return new Iterator() { > - Iterator hashIterator = hashEntries.iterator(); > + return new Iterator>() { > + Iterator> hashIterator = hashEntries.iterator(); > Entry next = null; > > public boolean hasNext() { > while (hashIterator.hasNext()) { > - Map.Entry ent = (Map.Entry)hashIterator.next(); > + Map.Entry ent = hashIterator.next(); > ValueCell vc = (ValueCell)ent.getValue(); > Object v = null; > if ((vc != null) && ((v = vc.get()) == null)) { > @@ -412,7 +413,7 @@ > return false; > } > > - public Object next() { > + public Map.Entry next() { > if ((next == null) && !hasNext()) > throw new NoSuchElementException(); > Entry e = next; > @@ -433,7 +434,7 @@ > > public int size() { > int j = 0; > - for (Iterator i = iterator(); i.hasNext(); i.next()) j++; > + for (Iterator> i = iterator(); i.hasNext(); i.next()) j++; > return j; > } > > @@ -446,12 +447,12 @@ > } > > > - private Set entrySet = null; > + private Set> entrySet = null; > > /** > * Return a Set view of the mappings in this cache. > */ > - public Set entrySet() { > + public Set> entrySet() { > if (entrySet == null) entrySet = new EntrySet(); > return entrySet; > } > -------------- next part -------------- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From david.holmes at oracle.com Wed Jan 8 06:19:12 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 08 Jan 2014 16:19:12 +1000 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52CC72AB.2020104@oracle.com> References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> <52CC72AB.2020104@oracle.com> Message-ID: <52CCEDE0.8000809@oracle.com> On 8/01/2014 7:33 AM, srikalyan chandrashekar wrote: > Hi David, TraceExceptions with fastdebug build produced some nice trace > . The > native method wait(long) is where the OOME if being thrown, the deepest > call is in > > src/share/vm/gc_interface/collectedHeap.inline.hpp, line 157 Yes but it is the caller that is of interest: Exception (0x00000000d6a01840) thrown [/HUDSON/workspace/8-2-build-linux-amd64/jdk8/1317/hotspot/src/share/vm/runtime/objectMonitor.cpp, line 1649] for thread 0x00007f78c40d2800 Exception (0x00000000d6a01840) thrown in interpreter method <{method} {0x00007f78b4800ae0} 'wait' '(J)V' in 'java/lang/Object'> at bci 0 for thread 0x00007f78c40d2800 The ReferenceHandler thread gets the OOME trying to allocate the InterruptedException. David ----- > ------------------- Excerpt Begins --------------------- > > 147 if (!gc_overhead_limit_was_exceeded) { > 148 // -XX:+HeapDumpOnOutOfMemoryError and -XX:OnOutOfMemoryError > support > 149 report_java_out_of_memory("Java heap space"); > 150 > 151 if (JvmtiExport::should_post_resource_exhausted()) { > 152 JvmtiExport::post_resource_exhausted( > 153 JVMTI_RESOURCE_EXHAUSTED_OOM_ERROR | > JVMTI_RESOURCE_EXHAUSTED_JAVA_HEAP, > 154 "Java heap space"); > 155 } > 156 > 157 THROW_OOP_0(Universe::out_of_memory_error_java_heap()); > 158 } else { > > ------------------- Excerpt Ends --------------------- > > > Would be helpful if David/some one else in the team could explain the > latent aspects/probable cause. > > --- > Thanks > kalyan > > On 01/06/2014 04:40 PM, David Holmes wrote: >> Back from vacation ... >> >> On 20/12/2013 4:49 PM, David Holmes wrote: >>> On 20/12/2013 12:57 PM, srikalyan chandrashekar wrote: >>>> Hi David Thanks for your comments, the unguarded part(clean and >>>> enqueue) >>>> in the Reference Handler thread does not seem to create any new >>>> objects, >>>> so it is the application(the test in this case) which is adding objects >>>> to heap and causing the Reference Handler to die with OOME. >>> >>> The ReferenceHandler thread can only get OOME if it allocates (directly >>> or indirectly) - so there has to be something in the unguarded part that >>> causes this. Again it may be an implicit action in the VM - similar to >>> the class load issue for InterruptedException. >> >> Run a debug VM with -XX:+TraceExceptions to see where the OOME is >> triggered. >> >> David >> ----- >> >>> David >>> >>> I am still >>>> unsure about the side effects of the code change and agree with your >>>> thoughts(on memory exhaustion test's reliability). >>>> >>>> PS: hotspot dev alias removed from CC. >>>> >>>> -- >>>> Thanks >>>> kalyan >>>> >>>> On 12/19/13 5:08 PM, David Holmes wrote: >>>>> Hi Kalyan, >>>>> >>>>> This is not a hotspot issue so I'm moving this to core-libs, please >>>>> drop hotspot from any replies. >>>>> >>>>> On 20/12/2013 6:26 AM, srikalyan wrote: >>>>>> Hi all, I have been working on the bug JDK-8022321 >>>>>> , this is a >>>>>> sporadic >>>>>> failure and the webrev is available here >>>>>> http://cr.openjdk.java.net/~srikchan/Regression/JDK-8022321_OOMEInReferenceHandler-webrev/ >>>>>> >>>>>> >>>>>> >>>>> >>>>> I'm really not sure what to make of this. We have a test that triggers >>>>> an out-of-memory condition but the OOME can actually turn up in the >>>>> ReferenceHandler thread causing it to terminate and the test to fail. >>>>> We previously accounted for the non-obvious occurrences of OOME due to >>>>> the Object.wait and the possible need to load the InterruptedException >>>>> class - but still the OOME can appear where we don't want it. So >>>>> finally you have just placed the whole for(;;) loop in a >>>>> try/catch(OOME) that ignores the OOME. I'm certain that makes the test >>>>> happy, but I'm not sure it is really what we want for the >>>>> ReferenceHandler thread. If the OOME occurs while cleaning, or >>>>> enqueuing then we will fail to clean and/or enqueue but there would be >>>>> no indication that has occurred and I think that is a bigger problem >>>>> than this test failing. >>>>> >>>>> There may be no way to make this test 100% reliable. In fact I'd >>>>> suggest that no memory exhaustion test can be 100% reliable. >>>>> >>>>> David >>>>> >>>>>> * >>>>>> **"Root Cause:Still not known"* >>>>>> 2 places where there is a possibility for OOME >>>>>> 1) Cleaner.clean() >>>>>> 2) ReferenceQueue.enqueue() >>>>>> >>>>>> 1) The cleanup code in turn has 2 places where there is potential >>>>>> for >>>>>> throwing OOME, >>>>>> a) thunk Thread which is run from clean() method. This >>>>>> Runnable is >>>>>> passed to Cleaner and appears in the following classes >>>>>> java/nio/DirectByteBuffer.java >>>>>> sun/misc/Perf.java >>>>>> sun/nio/fs/NativeBuffer.java >>>>>> sun/nio/ch/IOVecWrapper.java >>>>>> sun/misc/Cleaner/ExitOnThrow.java >>>>>> However none of the above overridden implementations ever create an >>>>>> object in the clean() code. >>>>>> b) new PrivilegedAction created in try catch Exception block of >>>>>> clean() method but for this object to be created and to be held >>>>>> responsible for OOME an Exception(other than OOME) has to be thrown. >>>>>> >>>>>> 2) No new heap objects are created in the enqueue method nor >>>>>> anywhere in >>>>>> the deep call stack (VM.addFinalRefCount() etc) so this cannot be a >>>>>> potential cause. >>>>>> >>>>>> *Experimental change to java.lang.Reference.java* : >>>>>> - Put one more guard (try catch with OOME block) in the Reference >>>>>> Handler Thread which may give the Reference Handler a chance to >>>>>> cleanup. >>>>>> This is fixing the test failure (several 1000 runs with 0 failures) >>>>>> - Without the above change the test fails atleast 3-5 times for every >>>>>> 1000 run. >>>>>> >>>>>> *PS*: The code change is to a very critical part of JDK and i am >>>>>> fully >>>>>> not aware of the consequences of the change, hence seeking expert >>>>>> help >>>>>> here. Appreciate your time and inputs towards this. >>>>>> >>>> > From david.holmes at oracle.com Wed Jan 8 06:30:17 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 08 Jan 2014 16:30:17 +1000 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52CCEDE0.8000809@oracle.com> References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> <52CC72AB.2020104@oracle.com> <52CCEDE0.8000809@oracle.com> Message-ID: <52CCF079.4090301@oracle.com> On 8/01/2014 4:19 PM, David Holmes wrote: > On 8/01/2014 7:33 AM, srikalyan chandrashekar wrote: >> Hi David, TraceExceptions with fastdebug build produced some nice trace >> . The >> native method wait(long) is where the OOME if being thrown, the deepest >> call is in >> >> src/share/vm/gc_interface/collectedHeap.inline.hpp, line 157 > > Yes but it is the caller that is of interest: > > Exception (0x00000000d6a01840) > thrown > [/HUDSON/workspace/8-2-build-linux-amd64/jdk8/1317/hotspot/src/share/vm/runtime/objectMonitor.cpp, > line 1649] > for thread 0x00007f78c40d2800 > Exception (0x00000000d6a01840) > thrown in interpreter method <{method} {0x00007f78b4800ae0} 'wait' > '(J)V' in 'java/lang/Object'> > at bci 0 for thread 0x00007f78c40d2800 > > The ReferenceHandler thread gets the OOME trying to allocate the > InterruptedException. However we already have a catch block around the wait() so how is this OOME getting through? A bug in exception handling in the interpreter ?? David > David > ----- > >> ------------------- Excerpt Begins --------------------- >> >> 147 if (!gc_overhead_limit_was_exceeded) { >> 148 // -XX:+HeapDumpOnOutOfMemoryError and -XX:OnOutOfMemoryError >> support >> 149 report_java_out_of_memory("Java heap space"); >> 150 >> 151 if (JvmtiExport::should_post_resource_exhausted()) { >> 152 JvmtiExport::post_resource_exhausted( >> 153 JVMTI_RESOURCE_EXHAUSTED_OOM_ERROR | >> JVMTI_RESOURCE_EXHAUSTED_JAVA_HEAP, >> 154 "Java heap space"); >> 155 } >> 156 >> 157 THROW_OOP_0(Universe::out_of_memory_error_java_heap()); >> 158 } else { >> >> ------------------- Excerpt Ends --------------------- >> >> >> Would be helpful if David/some one else in the team could explain the >> latent aspects/probable cause. >> >> --- >> Thanks >> kalyan >> >> On 01/06/2014 04:40 PM, David Holmes wrote: >>> Back from vacation ... >>> >>> On 20/12/2013 4:49 PM, David Holmes wrote: >>>> On 20/12/2013 12:57 PM, srikalyan chandrashekar wrote: >>>>> Hi David Thanks for your comments, the unguarded part(clean and >>>>> enqueue) >>>>> in the Reference Handler thread does not seem to create any new >>>>> objects, >>>>> so it is the application(the test in this case) which is adding >>>>> objects >>>>> to heap and causing the Reference Handler to die with OOME. >>>> >>>> The ReferenceHandler thread can only get OOME if it allocates (directly >>>> or indirectly) - so there has to be something in the unguarded part >>>> that >>>> causes this. Again it may be an implicit action in the VM - similar to >>>> the class load issue for InterruptedException. >>> >>> Run a debug VM with -XX:+TraceExceptions to see where the OOME is >>> triggered. >>> >>> David >>> ----- >>> >>>> David >>>> >>>> I am still >>>>> unsure about the side effects of the code change and agree with your >>>>> thoughts(on memory exhaustion test's reliability). >>>>> >>>>> PS: hotspot dev alias removed from CC. >>>>> >>>>> -- >>>>> Thanks >>>>> kalyan >>>>> >>>>> On 12/19/13 5:08 PM, David Holmes wrote: >>>>>> Hi Kalyan, >>>>>> >>>>>> This is not a hotspot issue so I'm moving this to core-libs, please >>>>>> drop hotspot from any replies. >>>>>> >>>>>> On 20/12/2013 6:26 AM, srikalyan wrote: >>>>>>> Hi all, I have been working on the bug JDK-8022321 >>>>>>> , this is a >>>>>>> sporadic >>>>>>> failure and the webrev is available here >>>>>>> http://cr.openjdk.java.net/~srikchan/Regression/JDK-8022321_OOMEInReferenceHandler-webrev/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> I'm really not sure what to make of this. We have a test that >>>>>> triggers >>>>>> an out-of-memory condition but the OOME can actually turn up in the >>>>>> ReferenceHandler thread causing it to terminate and the test to fail. >>>>>> We previously accounted for the non-obvious occurrences of OOME >>>>>> due to >>>>>> the Object.wait and the possible need to load the >>>>>> InterruptedException >>>>>> class - but still the OOME can appear where we don't want it. So >>>>>> finally you have just placed the whole for(;;) loop in a >>>>>> try/catch(OOME) that ignores the OOME. I'm certain that makes the >>>>>> test >>>>>> happy, but I'm not sure it is really what we want for the >>>>>> ReferenceHandler thread. If the OOME occurs while cleaning, or >>>>>> enqueuing then we will fail to clean and/or enqueue but there >>>>>> would be >>>>>> no indication that has occurred and I think that is a bigger problem >>>>>> than this test failing. >>>>>> >>>>>> There may be no way to make this test 100% reliable. In fact I'd >>>>>> suggest that no memory exhaustion test can be 100% reliable. >>>>>> >>>>>> David >>>>>> >>>>>>> * >>>>>>> **"Root Cause:Still not known"* >>>>>>> 2 places where there is a possibility for OOME >>>>>>> 1) Cleaner.clean() >>>>>>> 2) ReferenceQueue.enqueue() >>>>>>> >>>>>>> 1) The cleanup code in turn has 2 places where there is potential >>>>>>> for >>>>>>> throwing OOME, >>>>>>> a) thunk Thread which is run from clean() method. This >>>>>>> Runnable is >>>>>>> passed to Cleaner and appears in the following classes >>>>>>> java/nio/DirectByteBuffer.java >>>>>>> sun/misc/Perf.java >>>>>>> sun/nio/fs/NativeBuffer.java >>>>>>> sun/nio/ch/IOVecWrapper.java >>>>>>> sun/misc/Cleaner/ExitOnThrow.java >>>>>>> However none of the above overridden implementations ever create an >>>>>>> object in the clean() code. >>>>>>> b) new PrivilegedAction created in try catch Exception block of >>>>>>> clean() method but for this object to be created and to be held >>>>>>> responsible for OOME an Exception(other than OOME) has to be thrown. >>>>>>> >>>>>>> 2) No new heap objects are created in the enqueue method nor >>>>>>> anywhere in >>>>>>> the deep call stack (VM.addFinalRefCount() etc) so this cannot be a >>>>>>> potential cause. >>>>>>> >>>>>>> *Experimental change to java.lang.Reference.java* : >>>>>>> - Put one more guard (try catch with OOME block) in the Reference >>>>>>> Handler Thread which may give the Reference Handler a chance to >>>>>>> cleanup. >>>>>>> This is fixing the test failure (several 1000 runs with 0 failures) >>>>>>> - Without the above change the test fails atleast 3-5 times for >>>>>>> every >>>>>>> 1000 run. >>>>>>> >>>>>>> *PS*: The code change is to a very critical part of JDK and i am >>>>>>> fully >>>>>>> not aware of the consequences of the change, hence seeking expert >>>>>>> help >>>>>>> here. Appreciate your time and inputs towards this. >>>>>>> >>>>> >> From forax at univ-mlv.fr Wed Jan 8 08:02:49 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 08 Jan 2014 09:02:49 +0100 Subject: JDK 9 proposal: remove sun.misc.Ref In-Reply-To: <52CCB75C.2060402@oracle.com> References: <52CC7EF8.8040208@oracle.com> <52CCB75C.2060402@oracle.com> Message-ID: <52CD0629.8070005@univ-mlv.fr> On 01/08/2014 03:26 AM, Stuart Marks wrote: > On 1/7/14 2:26 PM, Joe Darcy wrote: >>> public abstract class Ref { >> >> So the type has been deprecated for at least 10 years. Rather than >> fixing the >> warning in the class, I think the best course of action is to remove >> the file in >> JDK 9. A build of OpenJDK without this file builds fine; if a build >> of the >> closed sources goes fine to, I think that should be sufficient >> justification for >> this type to be removed. >> >> Using code search engines, there are just a handful of references to >> sun.misc.Ref in the wihld, but any such uses will have several years >> to migrate >> to the standard java.util.SoftReference before JDK 9 ships. > > When in doubt, take it out. > > I had a small concern about whether sun.misc.Ref still might have had > some dependencies from the JVM (i.e. special support like the > java.lang.ref classes), but it looks like sun.misc.Ref itself is > entirely implemented in terms of java.lang.ref.SoftReference. I did a > quick search of hotspot and I couldn't find any mentions of > sun.misc.Ref, so I think we're clear. > > s'marks yes, delete it. R?mi From Alan.Bateman at oracle.com Wed Jan 8 09:06:14 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 08 Jan 2014 09:06:14 +0000 Subject: JDK 9 proposal: remove sun.misc.Ref In-Reply-To: <52CC7EF8.8040208@oracle.com> References: <52CC7EF8.8040208@oracle.com> Message-ID: <52CD1506.5030605@oracle.com> On 07/01/2014 22:26, Joe Darcy wrote: > > So the type has been deprecated for at least 10 years. Rather than > fixing the warning in the class, I think the best course of action is > to remove the file in JDK 9. A build of OpenJDK without this file > builds fine; if a build of the closed sources goes fine to, I think > that should be sufficient justification for this type to be removed. > > Using code search engines, there are just a handful of references to > sun.misc.Ref in the wihld, but any such uses will have several years > to migrate to the standard java.util.SoftReference before JDK 9 ships. > > Comments? See also JDK-6852936 [1] for other candidates to remove. We've always been a bit hesitant to remove sun.misc classes out of concern as to what/who it might break. As regards sun.misc.Ref then it would be good to remove it but I think the appletviewer code needs to be checked first as it does appear to be using it. Another point to mention is that if do modules right in JDK 9 then the access control rules will be extended to support encapsulation and therefore it wouldn't be possible to link directly to JDK-internal classes. This should allow us to be a bit more aggressive about removing unused sun.misc classes. -Alan [1] https://bugs.openjdk.java.net/browse/JDK-6852936 From Alan.Bateman at oracle.com Wed Jan 8 09:24:27 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 08 Jan 2014 09:24:27 +0000 Subject: RFR: JDK-8028726 - (prefs) Check src/solaris/native/java/util/FileSystemPreferences.c for JNI pending exceptions In-Reply-To: <52CCA0D4.3040907@oracle.com> References: <52CB2E4E.7080200@oracle.com> <52CBCAB4.1040700@oracle.com> <52CCA0D4.3040907@oracle.com> Message-ID: <52CD194B.6090407@oracle.com> On 08/01/2014 00:50, Dan Xu wrote: > Hi All, > > Thanks for your good review. I have dropped the change in > FileSystemPreferences.java , and created the new webrev which only > changes FileSystemPreferences.c. Please help review it. Thanks! > > Webrev: http://cr.openjdk.java.net/~dxu/8028726/webrev.01/ > > When changing FileSystemPreferences.c, I noticed the code like > "JNU_GetStringPlatformChars(env, java_fname, JNI_FALSE)". Because > JNI_FALSE is passed into this function, I am wondering why our code > still release string by calling JNU_ReleaseStringPlatformChars(env, > java_fname, fname). Thanks! This is the isCopy parameter to allow the function return whether it has returned a copy or not. So the JNU_ReleaseStringPlatformChars is needed. However the JNI_FALSE isn't right, it does happens to work because JNI_FALSE is defined as 0, same as NULL. Do you mind changing these to NULL as part of the change so that it's a bit more obvious? (no need to publish a new webrev if there are no other changes). Otherwise looks fine to me. -Alan. From Alan.Bateman at oracle.com Wed Jan 8 09:58:49 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 08 Jan 2014 09:58:49 +0000 Subject: RFR for JDK-8030089: java/util/zip/ZipFile/FinalizeZipFile.java intermittently fails with fastdebug builds In-Reply-To: <52CCBA3E.1040909@oracle.com> References: <52CCBA3E.1040909@oracle.com> Message-ID: <52CD2159.1040800@oracle.com> On 08/01/2014 02:38, Tristan Yan wrote: > Hi All > > Please help to review code fix for bug JDK-8030089. > > http://cr.openjdk.java.net/~tyan/JDK-8030089/webrev.00/ > > > Description: > 1. Set test running on othervm mode. > 2. Use infinite wait to the CountDownLatch. Changing it to use await looks fine. I'm curious about the reason for changing the test to run in othervm mode as I assume this is not strictly necessary (right?). (In any case, I can sponsor this one as we need our tests to be stable when running with a fastdebug build). -Alan From tristan.yan at oracle.com Wed Jan 8 10:09:32 2014 From: tristan.yan at oracle.com (Tristan Yan) Date: Wed, 08 Jan 2014 18:09:32 +0800 Subject: RFR for JDK-8030089: java/util/zip/ZipFile/FinalizeZipFile.java intermittently fails with fastdebug builds In-Reply-To: <52CD2159.1040800@oracle.com> References: <52CCBA3E.1040909@oracle.com> <52CD2159.1040800@oracle.com> Message-ID: <52CD23DC.2040708@oracle.com> Thank you Alan. I am appreciated that you sponsor this. The reason I changed it to othervm is I don't want System.gc do any impact to other tests, assume in concurrent mode. Regards Tristan On 01/08/2014 05:58 PM, Alan Bateman wrote: > On 08/01/2014 02:38, Tristan Yan wrote: >> Hi All >> >> Please help to review code fix for bug JDK-8030089. >> >> http://cr.openjdk.java.net/~tyan/JDK-8030089/webrev.00/ >> >> >> Description: >> 1. Set test running on othervm mode. >> 2. Use infinite wait to the CountDownLatch. > Changing it to use await looks fine. I'm curious about the reason for > changing the test to run in othervm mode as I assume this is not > strictly necessary (right?). > > (In any case, I can sponsor this one as we need our tests to be stable > when running with a fastdebug build). > > -Alan From Alan.Bateman at oracle.com Wed Jan 8 10:45:49 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 08 Jan 2014 10:45:49 +0000 Subject: RFR for JDK-8030089: java/util/zip/ZipFile/FinalizeZipFile.java intermittently fails with fastdebug builds In-Reply-To: <52CD23DC.2040708@oracle.com> References: <52CCBA3E.1040909@oracle.com> <52CD2159.1040800@oracle.com> <52CD23DC.2040708@oracle.com> Message-ID: <52CD2C5D.1040706@oracle.com> On 08/01/2014 10:09, Tristan Yan wrote: > Thank you Alan. I am appreciated that you sponsor this. > The reason I changed it to othervm is I don't want System.gc do any > impact to other tests, assume in concurrent mode. With concurrency then an agent VM still only runs one test at a time, it's just that there is a pool of agent VMs running concurrently. So the System.gc doesn't impact other agent VMs. -Alan. From tristan.yan at oracle.com Wed Jan 8 11:01:59 2014 From: tristan.yan at oracle.com (Tristan Yan) Date: Wed, 08 Jan 2014 19:01:59 +0800 Subject: RFR for JDK-8030089: java/util/zip/ZipFile/FinalizeZipFile.java intermittently fails with fastdebug builds In-Reply-To: <52CD2C5D.1040706@oracle.com> References: <52CCBA3E.1040909@oracle.com> <52CD2159.1040800@oracle.com> <52CD23DC.2040708@oracle.com> <52CD2C5D.1040706@oracle.com> Message-ID: <52CD3027.1000601@oracle.com> Hi Alan Maybe my understanding is wrong. Are you saying even in agentvm mode, there will be still different VM for every test. If the answer is yes, when should we use othervm mode? Thank you Tristan On 01/08/2014 06:45 PM, Alan Bateman wrote: > On 08/01/2014 10:09, Tristan Yan wrote: >> Thank you Alan. I am appreciated that you sponsor this. >> The reason I changed it to othervm is I don't want System.gc do any >> impact to other tests, assume in concurrent mode. > With concurrency then an agent VM still only runs one test at a time, > it's just that there is a pool of agent VMs running concurrently. So > the System.gc doesn't impact other agent VMs. > > -Alan. From joel.franck at oracle.com Wed Jan 8 12:00:56 2014 From: joel.franck at oracle.com (Joel Borggren-Franck) Date: Wed, 8 Jan 2014 13:00:56 +0100 Subject: (reflect) Accessing members of inner annotations types In-Reply-To: <52C6DD70.7070802@gmail.com> References: <52C6CEBA.5090006@gmail.com> <52C6DD70.7070802@gmail.com> Message-ID: <20140108120056.GF2996@oracle.com> Hi Peter, On 2014-01-03, Peter Levart wrote: > On 01/03/2014 03:52 PM, Peter Levart wrote: > >This is would be all right until such proxy class > >(com.sun.proxy.$Proxy1 in our example) has to access some > >package-private types in some specific package. This happens in > >your Named.List annotation implementation class. It implements a > >member method with the following signature: > > > >public Named[] value() {... > > > >...where the return type is an array of a package-private type > >Named. Public class in com.sun.proxy package can not access > >package-private types in other packages! > > Investigating this further, I found that the declaration itself is > not problematic. It's the code in the implemented proxy method that > tries to access the package-private Named class. Here's how the > bytecode looks like for such proxy method: > ... I think the error is thrown at the "checkcast" bytecode. The > improvement suggested still holds. If the proxy class was generated > in the specific package, error would not be thrown. But the > requirement to take into account all implemented interfaces and all > types encountered in the interface method signatures to calculate > the package of proxy class it too strict. Only implemented > interfaces and return types of all interface methods need to be > taken into consideration. Here's an example of bytecode that > illustrates how method parameters are passed to InvocationHandler: > Perhaps an alternative would be to check if the interface a proxy is proxying is nested. In that case use the outermost interface's access level for the package calculation. This would probably lead to a few more proxies being generated into the "real" package compared to your proposal. I don't know if that is ok or not. cheers /Joel From peter.levart at gmail.com Wed Jan 8 12:34:47 2014 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 08 Jan 2014 13:34:47 +0100 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52CCF079.4090301@oracle.com> References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> <52CC72AB.2020104@oracle.com> <52CCEDE0.8000809@oracle.com> <52CCF079.4090301@oracle.com> Message-ID: <52CD45E7.7010203@gmail.com> On 01/08/2014 07:30 AM, David Holmes wrote: > On 8/01/2014 4:19 PM, David Holmes wrote: >> On 8/01/2014 7:33 AM, srikalyan chandrashekar wrote: >>> Hi David, TraceExceptions with fastdebug build produced some nice trace >>> . The >>> native method wait(long) is where the OOME if being thrown, the deepest >>> call is in >>> >>> src/share/vm/gc_interface/collectedHeap.inline.hpp, line 157 >> >> Yes but it is the caller that is of interest: >> >> Exception (0x00000000d6a01840) >> thrown >> [/HUDSON/workspace/8-2-build-linux-amd64/jdk8/1317/hotspot/src/share/vm/runtime/objectMonitor.cpp, >> >> line 1649] >> for thread 0x00007f78c40d2800 >> Exception (0x00000000d6a01840) >> thrown in interpreter method <{method} {0x00007f78b4800ae0} 'wait' >> '(J)V' in 'java/lang/Object'> >> at bci 0 for thread 0x00007f78c40d2800 >> >> The ReferenceHandler thread gets the OOME trying to allocate the >> InterruptedException. > > However we already have a catch block around the wait() so how is this > OOME getting through? A bug in exception handling in the interpreter ?? > Might be. And it may have something to do with the fact that the Thread.run() method is the 1st call frame on the thread's stack (seems like corner case). The last few meaningful TraceExceptions records are: Exception (0x00000000d6a01840) thrown [/HUDSON/workspace/8-2-build-linux-amd64/jdk8/1317/hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp, line 157] for thread 0x00007f78c40d2800 Exception (0x00000000d6a01840) thrown [/HUDSON/workspace/8-2-build-linux-amd64/jdk8/1317/hotspot/src/share/vm/runtime/objectMonitor.cpp, line 1649] for thread 0x00007f78c40d2800 Exception (0x00000000d6a01840) thrown in interpreter method <{method} {0x00007f78b4800ae0} 'wait' '(J)V' in 'java/lang/Object'> at bci 0 for thread 0x00007f78c40d2800 Exception (0x00000000d6a01840) thrown in interpreter method <{method} {0x00007f78b4800ca8} 'wait' '()V' in 'java/lang/Object'> at *bci 2* for thread 0x00007f78c40d2800 Exception (0x00000000d6a01840) thrown in interpreter method <{method} {0x00007f78b48d2250} 'run' '()V' in 'java/lang/ref/Reference$ReferenceHandler'> at *bci 36* for thread 0x00007f78c40d2800 Here's the relevant bytecodes: public class java.lang.Object public final void wait() throws java.lang.InterruptedException; descriptor: ()V flags: ACC_PUBLIC, ACC_FINAL Code: stack=3, locals=1, args_size=1 0: aload_0 1: lconst_0 * 2: invokevirtual #73 // Method wait:(J)V* 5: return LineNumberTable: line 502: 0 line 503: 5 Exceptions: throws java.lang.InterruptedException class java.lang.ref.Reference$ReferenceHandler extends java.lang.Thread public void run(); descriptor: ()V flags: ACC_PUBLIC Code: stack=2, locals=5, args_size=1 0: invokestatic #62 // Method java/lang/ref/Reference.access$100:()Ljava/lang/ref/Reference$Lock; 3: dup 4: astore_2 5: monitorenter 6: invokestatic #61 // Method java/lang/ref/Reference.access$200:()Ljava/lang/ref/Reference; 9: ifnull 33 12: invokestatic #61 // Method java/lang/ref/Reference.access$200:()Ljava/lang/ref/Reference; 15: astore_1 16: aload_1 17: invokestatic #64 // Method java/lang/ref/Reference.access$300:(Ljava/lang/ref/Reference;)Ljava/lang/ref/Reference; 20: invokestatic #63 // Method java/lang/ref/Reference.access$202:(Ljava/lang/ref/Reference;)Ljava/lang/ref/Reference; 23: pop 24: aload_1 25: aconst_null 26: invokestatic #65 // Method java/lang/ref/Reference.access$302:(Ljava/lang/ref/Reference;Ljava/lang/ref/Reference;)Ljava/lang/ref/Reference; 29: pop 30: goto 52 33: invokestatic #62 // Method java/lang/ref/Reference.access$100:()Ljava/lang/ref/Reference$Lock; * 36: invokevirtual #59 // Method java/lang/Object.wait:()V* 39: goto 43 42: astore_3 43: goto 47 46: astore_3 47: aload_2 48: monitorexit 49: goto 0 52: aload_2 53: monitorexit 54: goto 64 57: astore 4 59: aload_2 60: monitorexit 61: aload 4 63: athrow 64: aload_1 65: instanceof #38 // class sun/misc/Cleaner 68: ifeq 81 71: aload_1 72: checkcast #38 // class sun/misc/Cleaner 75: invokevirtual #67 // Method sun/misc/Cleaner.clean:()V 78: goto 0 81: aload_1 82: getfield #57 // Field java/lang/ref/Reference.queue:Ljava/lang/ref/ReferenceQueue; 85: astore_2 86: aload_2 87: getstatic #58 // Field java/lang/ref/ReferenceQueue.NULL:Ljava/lang/ref/ReferenceQueue; 90: if_acmpeq 99 93: aload_2 94: aload_1 95: invokevirtual #66 // Method java/lang/ref/ReferenceQueue.enqueue:(Ljava/lang/ref/Reference;)Z 98: pop 99: goto 0 Exception table: from to target type * 33 39 42 Class java/lang/OutOfMemoryError* 33 43 46 Class java/lang/InterruptedException 6 49 57 any 52 54 57 any 57 61 57 any StackMapTable: number_of_entries = 11 frame_type = 0 /* same */ frame_type = 253 /* append */ offset_delta = 32 locals = [ top, class java/lang/Object ] frame_type = 72 /* same_locals_1_stack_item */ stack = [ class java/lang/OutOfMemoryError ] frame_type = 0 /* same */ frame_type = 66 /* same_locals_1_stack_item */ stack = [ class java/lang/InterruptedException ] frame_type = 0 /* same */ frame_type = 255 /* full_frame */ offset_delta = 4 locals = [ class java/lang/ref/Reference$ReferenceHandler, class java/lang/ref/Reference, class java/lang/Object ] stack = [] frame_type = 255 /* full_frame */ offset_delta = 4 locals = [ class java/lang/ref/Reference$ReferenceHandler, top, class java/lang/Object ] stack = [ class java/lang/Throwable ] frame_type = 255 /* full_frame */ offset_delta = 6 locals = [ class java/lang/ref/Reference$ReferenceHandler, class java/lang/ref/Reference ] stack = [] frame_type = 16 /* same */ frame_type = 250 /* chop */ offset_delta = 17 LineNumberTable: line 136: 0 line 137: 6 line 138: 12 line 139: 16 line 140: 24 line 157: 33 line 158: 39 line 159: 43 line 160: 47 line 162: 52 line 165: 64 line 166: 71 line 167: 78 line 170: 81 line 171: 86 line 172: 99 } ... if I understand correctly the TraceExceptions' output, one record is printed for each abruptly completed method. The last record printed shows that Object.wait() method completed abruptly by throwing OOME. Even if the OOME was caught and ignored, we would still get this TraceExceptions record. Am I right? There's no record of abruptly terminated ReferenceHandler.run() method in the output. This might be because there's no method "calling" the ReferenceHandler.run() method, since it is the 1st method on the call-stack. Are you sure the output is from a failed test? Can we make the following adjustment to the ReferenceHandler and see what gets printed and/or whether we still get uncaught OOME: private static class ReferenceHandler extends Thread { ... public void run() { runImpl(); } private void runImpl() { // ... the content of the original run() method } ... Regards, Peter > David > >> David >> ----- >> >>> ------------------- Excerpt Begins --------------------- >>> >>> 147 if (!gc_overhead_limit_was_exceeded) { >>> 148 // -XX:+HeapDumpOnOutOfMemoryError and -XX:OnOutOfMemoryError >>> support >>> 149 report_java_out_of_memory("Java heap space"); >>> 150 >>> 151 if (JvmtiExport::should_post_resource_exhausted()) { >>> 152 JvmtiExport::post_resource_exhausted( >>> 153 JVMTI_RESOURCE_EXHAUSTED_OOM_ERROR | >>> JVMTI_RESOURCE_EXHAUSTED_JAVA_HEAP, >>> 154 "Java heap space"); >>> 155 } >>> 156 >>> 157 THROW_OOP_0(Universe::out_of_memory_error_java_heap()); >>> 158 } else { >>> >>> ------------------- Excerpt Ends --------------------- >>> >>> >>> Would be helpful if David/some one else in the team could explain the >>> latent aspects/probable cause. >>> >>> --- >>> Thanks >>> kalyan >>> >>> On 01/06/2014 04:40 PM, David Holmes wrote: >>>> Back from vacation ... >>>> >>>> On 20/12/2013 4:49 PM, David Holmes wrote: >>>>> On 20/12/2013 12:57 PM, srikalyan chandrashekar wrote: >>>>>> Hi David Thanks for your comments, the unguarded part(clean and >>>>>> enqueue) >>>>>> in the Reference Handler thread does not seem to create any new >>>>>> objects, >>>>>> so it is the application(the test in this case) which is adding >>>>>> objects >>>>>> to heap and causing the Reference Handler to die with OOME. >>>>> >>>>> The ReferenceHandler thread can only get OOME if it allocates >>>>> (directly >>>>> or indirectly) - so there has to be something in the unguarded part >>>>> that >>>>> causes this. Again it may be an implicit action in the VM - >>>>> similar to >>>>> the class load issue for InterruptedException. >>>> >>>> Run a debug VM with -XX:+TraceExceptions to see where the OOME is >>>> triggered. >>>> >>>> David >>>> ----- >>>> >>>>> David >>>>> >>>>> I am still >>>>>> unsure about the side effects of the code change and agree with your >>>>>> thoughts(on memory exhaustion test's reliability). >>>>>> >>>>>> PS: hotspot dev alias removed from CC. >>>>>> >>>>>> -- >>>>>> Thanks >>>>>> kalyan >>>>>> >>>>>> On 12/19/13 5:08 PM, David Holmes wrote: >>>>>>> Hi Kalyan, >>>>>>> >>>>>>> This is not a hotspot issue so I'm moving this to core-libs, please >>>>>>> drop hotspot from any replies. >>>>>>> >>>>>>> On 20/12/2013 6:26 AM, srikalyan wrote: >>>>>>>> Hi all, I have been working on the bug JDK-8022321 >>>>>>>> , this is a >>>>>>>> sporadic >>>>>>>> failure and the webrev is available here >>>>>>>> http://cr.openjdk.java.net/~srikchan/Regression/JDK-8022321_OOMEInReferenceHandler-webrev/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> I'm really not sure what to make of this. We have a test that >>>>>>> triggers >>>>>>> an out-of-memory condition but the OOME can actually turn up in the >>>>>>> ReferenceHandler thread causing it to terminate and the test to >>>>>>> fail. >>>>>>> We previously accounted for the non-obvious occurrences of OOME >>>>>>> due to >>>>>>> the Object.wait and the possible need to load the >>>>>>> InterruptedException >>>>>>> class - but still the OOME can appear where we don't want it. So >>>>>>> finally you have just placed the whole for(;;) loop in a >>>>>>> try/catch(OOME) that ignores the OOME. I'm certain that makes the >>>>>>> test >>>>>>> happy, but I'm not sure it is really what we want for the >>>>>>> ReferenceHandler thread. If the OOME occurs while cleaning, or >>>>>>> enqueuing then we will fail to clean and/or enqueue but there >>>>>>> would be >>>>>>> no indication that has occurred and I think that is a bigger >>>>>>> problem >>>>>>> than this test failing. >>>>>>> >>>>>>> There may be no way to make this test 100% reliable. In fact I'd >>>>>>> suggest that no memory exhaustion test can be 100% reliable. >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> * >>>>>>>> **"Root Cause:Still not known"* >>>>>>>> 2 places where there is a possibility for OOME >>>>>>>> 1) Cleaner.clean() >>>>>>>> 2) ReferenceQueue.enqueue() >>>>>>>> >>>>>>>> 1) The cleanup code in turn has 2 places where there is potential >>>>>>>> for >>>>>>>> throwing OOME, >>>>>>>> a) thunk Thread which is run from clean() method. This >>>>>>>> Runnable is >>>>>>>> passed to Cleaner and appears in the following classes >>>>>>>> java/nio/DirectByteBuffer.java >>>>>>>> sun/misc/Perf.java >>>>>>>> sun/nio/fs/NativeBuffer.java >>>>>>>> sun/nio/ch/IOVecWrapper.java >>>>>>>> sun/misc/Cleaner/ExitOnThrow.java >>>>>>>> However none of the above overridden implementations ever >>>>>>>> create an >>>>>>>> object in the clean() code. >>>>>>>> b) new PrivilegedAction created in try catch Exception >>>>>>>> block of >>>>>>>> clean() method but for this object to be created and to be held >>>>>>>> responsible for OOME an Exception(other than OOME) has to be >>>>>>>> thrown. >>>>>>>> >>>>>>>> 2) No new heap objects are created in the enqueue method nor >>>>>>>> anywhere in >>>>>>>> the deep call stack (VM.addFinalRefCount() etc) so this cannot >>>>>>>> be a >>>>>>>> potential cause. >>>>>>>> >>>>>>>> *Experimental change to java.lang.Reference.java* : >>>>>>>> - Put one more guard (try catch with OOME block) in the Reference >>>>>>>> Handler Thread which may give the Reference Handler a chance to >>>>>>>> cleanup. >>>>>>>> This is fixing the test failure (several 1000 runs with 0 >>>>>>>> failures) >>>>>>>> - Without the above change the test fails atleast 3-5 times for >>>>>>>> every >>>>>>>> 1000 run. >>>>>>>> >>>>>>>> *PS*: The code change is to a very critical part of JDK and i am >>>>>>>> fully >>>>>>>> not aware of the consequences of the change, hence seeking expert >>>>>>>> help >>>>>>>> here. Appreciate your time and inputs towards this. >>>>>>>> >>>>>> >>> From Alan.Bateman at oracle.com Wed Jan 8 12:51:18 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 08 Jan 2014 12:51:18 +0000 Subject: RFR for JDK-8030089: java/util/zip/ZipFile/FinalizeZipFile.java intermittently fails with fastdebug builds In-Reply-To: <52CD3027.1000601@oracle.com> References: <52CCBA3E.1040909@oracle.com> <52CD2159.1040800@oracle.com> <52CD23DC.2040708@oracle.com> <52CD2C5D.1040706@oracle.com> <52CD3027.1000601@oracle.com> Message-ID: <52CD49C6.9020805@oracle.com> On 08/01/2014 11:01, Tristan Yan wrote: > Hi Alan > Maybe my understanding is wrong. Are you saying even in agentvm mode, > there will be still different VM for every test. If the answer is yes, > when should we use othervm mode? The purpose of -agentvm is to speed up the test execution by eliding the VM startup that otherwise dominates the execution of many short running tests. Tests are still executed sequentially, it's just that there isn't a VM started up for each test. With concurrency then the tests don't execute concurrently in the same VM, instead there is a pool of independent VMs that run concurrently. We still need othervm for some tests and for varied reasons. One reason is tests that can't restore things or clean up, another reason is tests that require special VM options. We moved to -agentvm a few years ago but we still periodically find issues where a test does something that causes a test that runs subsequently to have a problem. Anyway, for this test then my point was that it probably doesn't need to run in othervm mode, just changing it to await indefinitely should be fine (as it's await will timeout would require a long timeout when running with a fastdebug build). -Alan. From tristan.yan at oracle.com Wed Jan 8 12:57:51 2014 From: tristan.yan at oracle.com (Tristan Yan) Date: Wed, 08 Jan 2014 20:57:51 +0800 Subject: RFR for JDK-8030089: java/util/zip/ZipFile/FinalizeZipFile.java intermittently fails with fastdebug builds In-Reply-To: <52CD49C6.9020805@oracle.com> References: <52CCBA3E.1040909@oracle.com> <52CD2159.1040800@oracle.com> <52CD23DC.2040708@oracle.com> <52CD2C5D.1040706@oracle.com> <52CD3027.1000601@oracle.com> <52CD49C6.9020805@oracle.com> Message-ID: <52CD4B4F.7060108@oracle.com> Thank you. This is a very detailed explanation. I had new webrev with removing othervm. http://cr.openjdk.java.net/~tyan/JDK-8030089/webrev.01/ Regards Tristan On 01/08/2014 08:51 PM, Alan Bateman wrote: > On 08/01/2014 11:01, Tristan Yan wrote: >> Hi Alan >> Maybe my understanding is wrong. Are you saying even in agentvm mode, >> there will be still different VM for every test. If the answer is >> yes, when should we use othervm mode? > The purpose of -agentvm is to speed up the test execution by eliding > the VM startup that otherwise dominates the execution of many short > running tests. Tests are still executed sequentially, it's just that > there isn't a VM started up for each test. With concurrency then the > tests don't execute concurrently in the same VM, instead there is a > pool of independent VMs that run concurrently. We still need othervm > for some tests and for varied reasons. One reason is tests that can't > restore things or clean up, another reason is tests that require > special VM options. We moved to -agentvm a few years ago but we still > periodically find issues where a test does something that causes a > test that runs subsequently to have a problem. > > Anyway, for this test then my point was that it probably doesn't need > to run in othervm mode, just changing it to await indefinitely should > be fine (as it's await will timeout would require a long timeout when > running with a fastdebug build). > > -Alan. > From peter.levart at gmail.com Wed Jan 8 13:06:12 2014 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 08 Jan 2014 14:06:12 +0100 Subject: (reflect) Accessing members of inner annotations types In-Reply-To: <20140108120056.GF2996@oracle.com> References: <52C6CEBA.5090006@gmail.com> <52C6DD70.7070802@gmail.com> <20140108120056.GF2996@oracle.com> Message-ID: <52CD4D44.5000508@gmail.com> On 01/08/2014 01:00 PM, Joel Borggren-Franck wrote: > Hi Peter, > > On 2014-01-03, Peter Levart wrote: >> On 01/03/2014 03:52 PM, Peter Levart wrote: >>> This is would be all right until such proxy class >>> (com.sun.proxy.$Proxy1 in our example) has to access some >>> package-private types in some specific package. This happens in >>> your Named.List annotation implementation class. It implements a >>> member method with the following signature: >>> >>> public Named[] value() {... >>> >>> ...where the return type is an array of a package-private type >>> Named. Public class in com.sun.proxy package can not access >>> package-private types in other packages! >> Investigating this further, I found that the declaration itself is >> not problematic. It's the code in the implemented proxy method that >> tries to access the package-private Named class. Here's how the >> bytecode looks like for such proxy method: >> ... I think the error is thrown at the "checkcast" bytecode. The >> improvement suggested still holds. If the proxy class was generated >> in the specific package, error would not be thrown. But the >> requirement to take into account all implemented interfaces and all >> types encountered in the interface method signatures to calculate >> the package of proxy class it too strict. Only implemented >> interfaces and return types of all interface methods need to be >> taken into consideration. Here's an example of bytecode that >> illustrates how method parameters are passed to InvocationHandler: >> > Perhaps an alternative would be to check if the interface a proxy is > proxying is nested. In that case use the outermost interface's access > level for the package calculation. > > This would probably lead to a few more proxies being generated into the > "real" package compared to your proposal. I don't know if that is ok or > not. Hi Joel, The nested public interface need not be referencing the outer class/interface. In this case, proxy class can be generated in com.sun.proxy. More importantly, even if the outer interface/class was public, the nested interface could be referencing some other package-private type. For example: public class Outer { @Retention(RUNTIME) @interface PkgPrivate {} @Retention(RUNTIME) public @interface Public { PkgPrivate value(); } @Public(@PkgPrivate) public void m() {} } I think the criteria for package selection should be closely tied to requirements of the generated proxy class code. And the generated code references the return type of the method. Regards, Peter > > cheers > /Joel From Alan.Bateman at oracle.com Wed Jan 8 13:06:18 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 08 Jan 2014 13:06:18 +0000 Subject: RFR for JDK-8030089: java/util/zip/ZipFile/FinalizeZipFile.java intermittently fails with fastdebug builds In-Reply-To: <52CD4B4F.7060108@oracle.com> References: <52CCBA3E.1040909@oracle.com> <52CD2159.1040800@oracle.com> <52CD23DC.2040708@oracle.com> <52CD2C5D.1040706@oracle.com> <52CD3027.1000601@oracle.com> <52CD49C6.9020805@oracle.com> <52CD4B4F.7060108@oracle.com> Message-ID: <52CD4D4A.4090406@oracle.com> On 08/01/2014 12:57, Tristan Yan wrote: > Thank you. This is a very detailed explanation. > I had new webrev with removing othervm. Thanks, looks good. I've pushed it to jdk9/dev/jdk for you. -Alan From joel.franck at oracle.com Wed Jan 8 13:26:57 2014 From: joel.franck at oracle.com (Joel Borggren-Franck) Date: Wed, 8 Jan 2014 14:26:57 +0100 Subject: (reflect) Accessing members of inner annotations types In-Reply-To: <52CD4D44.5000508@gmail.com> References: <52C6CEBA.5090006@gmail.com> <52C6DD70.7070802@gmail.com> <20140108120056.GF2996@oracle.com> <52CD4D44.5000508@gmail.com> Message-ID: <20140108132657.GA8851@oracle.com> On 2014-01-08, Peter Levart wrote: > On 01/08/2014 01:00 PM, Joel Borggren-Franck wrote: > >> > >Perhaps an alternative would be to check if the interface a proxy is > >proxying is nested. In that case use the outermost interface's access > >level for the package calculation. > > > >This would probably lead to a few more proxies being generated into the > >"real" package compared to your proposal. I don't know if that is ok or > >not. > The nested public interface need not be referencing the outer > class/interface. In this case, proxy class can be generated in > com.sun.proxy. Yes, this is the reason for my remark about more proxies being generated into the real package. I'm not sure this is a problem, however it is moot considering you second point. > More importantly, even if the outer interface/class > was public, the nested interface could be referencing some other > package-private type. For example: > Ugh. Acknowledged. (This feels like a really bad practice but that doesn't matter here.) cheers /Joel From peter.levart at gmail.com Wed Jan 8 13:53:21 2014 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 08 Jan 2014 14:53:21 +0100 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52CC69CD.2090600@oracle.com> References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> <52CB6330.3090901@oracle.com> <52CBBDEC.9030702@gmail.com> <52CC69CD.2090600@oracle.com> Message-ID: <52CD5851.7010702@gmail.com> Hi Kalyan, What hardware/OS/JVM and what JVM options are you using to reproduce this failure. I would really like to reproduce this myself, but all attempts on my PC have so far been unsuccessful. I might be able to get access to a machine that is similar to yours... Regards, Peter On 01/07/2014 09:55 PM, srikalyan chandrashekar wrote: > Peter, getting state info out(to console or otherwise) from within > Reference Handler's exceptions handlers have been unsuccessful. > However David's suggestion produced some useful trace with fast debug > build and could get some information , see the log here > . > --- > Thanks > kalyan > On 01/07/2014 12:42 AM, Peter Levart wrote: >> On 01/07/2014 03:15 AM, srikalyan chandrashekar wrote: >>> Sure David will give that a try, we have so far attempted to >>> 1. Print state data(as per the test creator peter.levart's inputs), >> >> Hi Kalyan, >> >> Have you been able to reproduce the OOME in that set-up? What was the >> result? >> >> Regards, Peter >> >>> 2. Use UEH(uncaught exception handler per Mandy's inputs) >>> >>> -- >>> Thanks >>> kalyan >>> >>> On 1/6/14 4:40 PM, David Holmes wrote: >>>> Back from vacation ... >>>> >>>> On 20/12/2013 4:49 PM, David Holmes wrote: >>>>> On 20/12/2013 12:57 PM, srikalyan chandrashekar wrote: >>>>>> Hi David Thanks for your comments, the unguarded part(clean and >>>>>> enqueue) >>>>>> in the Reference Handler thread does not seem to create any new >>>>>> objects, >>>>>> so it is the application(the test in this case) which is adding >>>>>> objects >>>>>> to heap and causing the Reference Handler to die with OOME. >>>>> >>>>> The ReferenceHandler thread can only get OOME if it allocates >>>>> (directly >>>>> or indirectly) - so there has to be something in the unguarded >>>>> part that >>>>> causes this. Again it may be an implicit action in the VM - >>>>> similar to >>>>> the class load issue for InterruptedException. >>>> >>>> Run a debug VM with -XX:+TraceExceptions to see where the OOME is >>>> triggered. >>>> >>>> David >>>> ----- >>>> >>>>> David >>>>> >>>>> I am still >>>>>> unsure about the side effects of the code change and agree with your >>>>>> thoughts(on memory exhaustion test's reliability). >>>>>> >>>>>> PS: hotspot dev alias removed from CC. >>>>>> >>>>>> -- >>>>>> Thanks >>>>>> kalyan >>>>>> >>>>>> On 12/19/13 5:08 PM, David Holmes wrote: >>>>>>> Hi Kalyan, >>>>>>> >>>>>>> This is not a hotspot issue so I'm moving this to core-libs, please >>>>>>> drop hotspot from any replies. >>>>>>> >>>>>>> On 20/12/2013 6:26 AM, srikalyan wrote: >>>>>>>> Hi all, I have been working on the bug JDK-8022321 >>>>>>>> , this is a >>>>>>>> sporadic >>>>>>>> failure and the webrev is available here >>>>>>>> http://cr.openjdk.java.net/~srikchan/Regression/JDK-8022321_OOMEInReferenceHandler-webrev/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> I'm really not sure what to make of this. We have a test that >>>>>>> triggers >>>>>>> an out-of-memory condition but the OOME can actually turn up in the >>>>>>> ReferenceHandler thread causing it to terminate and the test to >>>>>>> fail. >>>>>>> We previously accounted for the non-obvious occurrences of OOME >>>>>>> due to >>>>>>> the Object.wait and the possible need to load the >>>>>>> InterruptedException >>>>>>> class - but still the OOME can appear where we don't want it. So >>>>>>> finally you have just placed the whole for(;;) loop in a >>>>>>> try/catch(OOME) that ignores the OOME. I'm certain that makes >>>>>>> the test >>>>>>> happy, but I'm not sure it is really what we want for the >>>>>>> ReferenceHandler thread. If the OOME occurs while cleaning, or >>>>>>> enqueuing then we will fail to clean and/or enqueue but there >>>>>>> would be >>>>>>> no indication that has occurred and I think that is a bigger >>>>>>> problem >>>>>>> than this test failing. >>>>>>> >>>>>>> There may be no way to make this test 100% reliable. In fact I'd >>>>>>> suggest that no memory exhaustion test can be 100% reliable. >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> * >>>>>>>> **"Root Cause:Still not known"* >>>>>>>> 2 places where there is a possibility for OOME >>>>>>>> 1) Cleaner.clean() >>>>>>>> 2) ReferenceQueue.enqueue() >>>>>>>> >>>>>>>> 1) The cleanup code in turn has 2 places where there is >>>>>>>> potential for >>>>>>>> throwing OOME, >>>>>>>> a) thunk Thread which is run from clean() method. This >>>>>>>> Runnable is >>>>>>>> passed to Cleaner and appears in the following classes >>>>>>>> java/nio/DirectByteBuffer.java >>>>>>>> sun/misc/Perf.java >>>>>>>> sun/nio/fs/NativeBuffer.java >>>>>>>> sun/nio/ch/IOVecWrapper.java >>>>>>>> sun/misc/Cleaner/ExitOnThrow.java >>>>>>>> However none of the above overridden implementations ever >>>>>>>> create an >>>>>>>> object in the clean() code. >>>>>>>> b) new PrivilegedAction created in try catch Exception >>>>>>>> block of >>>>>>>> clean() method but for this object to be created and to be held >>>>>>>> responsible for OOME an Exception(other than OOME) has to be >>>>>>>> thrown. >>>>>>>> >>>>>>>> 2) No new heap objects are created in the enqueue method nor >>>>>>>> anywhere in >>>>>>>> the deep call stack (VM.addFinalRefCount() etc) so this cannot >>>>>>>> be a >>>>>>>> potential cause. >>>>>>>> >>>>>>>> *Experimental change to java.lang.Reference.java* : >>>>>>>> - Put one more guard (try catch with OOME block) in the Reference >>>>>>>> Handler Thread which may give the Reference Handler a chance to >>>>>>>> cleanup. >>>>>>>> This is fixing the test failure (several 1000 runs with 0 >>>>>>>> failures) >>>>>>>> - Without the above change the test fails atleast 3-5 times for >>>>>>>> every >>>>>>>> 1000 run. >>>>>>>> >>>>>>>> *PS*: The code change is to a very critical part of JDK and i >>>>>>>> am fully >>>>>>>> not aware of the consequences of the change, hence seeking >>>>>>>> expert help >>>>>>>> here. Appreciate your time and inputs towards this. >>>>>>>> >>>>>> >>> >> > From erik.joelsson at oracle.com Wed Jan 8 14:24:24 2014 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Wed, 08 Jan 2014 14:24:24 +0000 Subject: hg: jdk8/tl: 8030781: System.setProperties(null) drops all system properties (RELEASE not set) Message-ID: <20140108142425.364A862461@hg.openjdk.java.net> Changeset: 53d74b77ee53 Author: erikj Date: 2014-01-08 14:02 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/53d74b77ee53 8030781: System.setProperties(null) drops all system properties (RELEASE not set) Reviewed-by: alanb, ihse, tbell ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 From erik.joelsson at oracle.com Wed Jan 8 14:24:48 2014 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Wed, 08 Jan 2014 14:24:48 +0000 Subject: hg: jdk8/tl/jdk: 8030781: System.setProperties(null) drops all system properties (RELEASE not set) Message-ID: <20140108142555.A4F0B62462@hg.openjdk.java.net> Changeset: 2437ccbf3504 Author: erikj Date: 2014-01-08 14:04 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2437ccbf3504 8030781: System.setProperties(null) drops all system properties (RELEASE not set) Reviewed-by: alanb + test/java/lang/System/SetPropertiesNull.java From michael.fang at oracle.com Wed Jan 8 14:58:52 2014 From: michael.fang at oracle.com (michael.fang at oracle.com) Date: Wed, 08 Jan 2014 14:58:52 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20140108145930.428F162463@hg.openjdk.java.net> Changeset: 5d05be02629c Author: mfang Date: 2014-01-07 21:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5d05be02629c 8029239: jdk8 l10n resource file translation update - localenames Reviewed-by: okutsu ! src/share/classes/sun/util/resources/de/LocaleNames_de.properties ! src/share/classes/sun/util/resources/es/LocaleNames_es.properties ! src/share/classes/sun/util/resources/fr/LocaleNames_fr.properties ! src/share/classes/sun/util/resources/it/LocaleNames_it.properties ! src/share/classes/sun/util/resources/ja/LocaleNames_ja.properties ! src/share/classes/sun/util/resources/ko/LocaleNames_ko.properties ! src/share/classes/sun/util/resources/sv/LocaleNames_sv.properties ! src/share/classes/sun/util/resources/zh/LocaleNames_zh.properties ! src/share/classes/sun/util/resources/zh/LocaleNames_zh_TW.properties Changeset: b7e7d7ad6f68 Author: mfang Date: 2014-01-07 22:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b7e7d7ad6f68 8026570: NLS: jdk8 man page update Reviewed-by: naoto, okutsu ! make/Images.gmk ! src/linux/doc/man/ja/appletviewer.1 ! src/linux/doc/man/ja/extcheck.1 ! src/linux/doc/man/ja/idlj.1 ! src/linux/doc/man/ja/jar.1 ! src/linux/doc/man/ja/jarsigner.1 ! src/linux/doc/man/ja/java.1 ! src/linux/doc/man/ja/javac.1 ! src/linux/doc/man/ja/javadoc.1 ! src/linux/doc/man/ja/javah.1 ! src/linux/doc/man/ja/javap.1 ! src/linux/doc/man/ja/javaws.1 + src/linux/doc/man/ja/jcmd.1 ! src/linux/doc/man/ja/jconsole.1 ! src/linux/doc/man/ja/jdb.1 + src/linux/doc/man/ja/jdeps.1 ! src/linux/doc/man/ja/jhat.1 ! src/linux/doc/man/ja/jinfo.1 + src/linux/doc/man/ja/jjs.1 ! src/linux/doc/man/ja/jmap.1 ! src/linux/doc/man/ja/jps.1 ! src/linux/doc/man/ja/jrunscript.1 ! src/linux/doc/man/ja/jsadebugd.1 ! src/linux/doc/man/ja/jstack.1 ! src/linux/doc/man/ja/jstat.1 ! src/linux/doc/man/ja/jstatd.1 ! src/linux/doc/man/ja/jvisualvm.1 ! src/linux/doc/man/ja/keytool.1 ! src/linux/doc/man/ja/native2ascii.1 ! src/linux/doc/man/ja/orbd.1 ! src/linux/doc/man/ja/pack200.1 ! src/linux/doc/man/ja/policytool.1 ! src/linux/doc/man/ja/rmic.1 ! src/linux/doc/man/ja/rmid.1 ! src/linux/doc/man/ja/rmiregistry.1 ! src/linux/doc/man/ja/schemagen.1 ! src/linux/doc/man/ja/serialver.1 ! src/linux/doc/man/ja/servertool.1 ! src/linux/doc/man/ja/tnameserv.1 ! src/linux/doc/man/ja/unpack200.1 ! src/linux/doc/man/ja/wsgen.1 ! src/linux/doc/man/ja/wsimport.1 ! src/linux/doc/man/ja/xjc.1 ! src/solaris/doc/sun/man/man1/ja/appletviewer.1 ! src/solaris/doc/sun/man/man1/ja/extcheck.1 ! src/solaris/doc/sun/man/man1/ja/idlj.1 ! src/solaris/doc/sun/man/man1/ja/jar.1 ! src/solaris/doc/sun/man/man1/ja/jarsigner.1 ! src/solaris/doc/sun/man/man1/ja/java.1 ! src/solaris/doc/sun/man/man1/ja/javac.1 ! src/solaris/doc/sun/man/man1/ja/javadoc.1 ! src/solaris/doc/sun/man/man1/ja/javah.1 ! src/solaris/doc/sun/man/man1/ja/javap.1 + src/solaris/doc/sun/man/man1/ja/jcmd.1 ! src/solaris/doc/sun/man/man1/ja/jconsole.1 ! src/solaris/doc/sun/man/man1/ja/jdb.1 + src/solaris/doc/sun/man/man1/ja/jdeps.1 ! src/solaris/doc/sun/man/man1/ja/jhat.1 ! src/solaris/doc/sun/man/man1/ja/jinfo.1 + src/solaris/doc/sun/man/man1/ja/jjs.1 ! src/solaris/doc/sun/man/man1/ja/jmap.1 ! src/solaris/doc/sun/man/man1/ja/jps.1 ! src/solaris/doc/sun/man/man1/ja/jrunscript.1 ! src/solaris/doc/sun/man/man1/ja/jsadebugd.1 ! src/solaris/doc/sun/man/man1/ja/jstack.1 ! src/solaris/doc/sun/man/man1/ja/jstat.1 ! src/solaris/doc/sun/man/man1/ja/jstatd.1 ! src/solaris/doc/sun/man/man1/ja/jvisualvm.1 ! src/solaris/doc/sun/man/man1/ja/keytool.1 ! src/solaris/doc/sun/man/man1/ja/native2ascii.1 ! src/solaris/doc/sun/man/man1/ja/orbd.1 ! src/solaris/doc/sun/man/man1/ja/pack200.1 ! src/solaris/doc/sun/man/man1/ja/policytool.1 ! src/solaris/doc/sun/man/man1/ja/rmic.1 ! src/solaris/doc/sun/man/man1/ja/rmid.1 ! src/solaris/doc/sun/man/man1/ja/rmiregistry.1 ! src/solaris/doc/sun/man/man1/ja/schemagen.1 ! src/solaris/doc/sun/man/man1/ja/serialver.1 ! src/solaris/doc/sun/man/man1/ja/servertool.1 ! src/solaris/doc/sun/man/man1/ja/tnameserv.1 ! src/solaris/doc/sun/man/man1/ja/unpack200.1 ! src/solaris/doc/sun/man/man1/ja/wsgen.1 ! src/solaris/doc/sun/man/man1/ja/wsimport.1 ! src/solaris/doc/sun/man/man1/ja/xjc.1 Changeset: 7c8f4610a23d Author: mfang Date: 2014-01-08 06:50 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7c8f4610a23d Merge From daniel.fuchs at oracle.com Wed Jan 8 17:34:57 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 08 Jan 2014 18:34:57 +0100 Subject: JDK 9 RFR for 8031068: java/util/logging/ParentLoggersTest.java: checkLoggers: getLoggerNames() returned unexpected loggers Message-ID: <52CD8C41.9030701@oracle.com> Hi, Please find below a patch for a test bug: 8031068: java/util/logging/ParentLoggersTest.java: checkLoggers: getLoggerNames() returned unexpected loggers https://bugs.openjdk.java.net/browse/JDK-8031068 As usual - the issue is that the test creates loggers without keeping any strong reference - thus allowing for the possibility that they will be garbage collected too soon. I managed to reproduce systematically by adding a call to System.gc() between the creation of the two loggers - and passing -Xcomp -server to the VM. With the fix the test no longer fails in that configuration. best regards, -- daniel From chris.hegarty at oracle.com Wed Jan 8 17:48:16 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 8 Jan 2014 17:48:16 +0000 Subject: JDK 9 RFR for 8031068: java/util/logging/ParentLoggersTest.java: checkLoggers: getLoggerNames() returned unexpected loggers In-Reply-To: <52CD8C41.9030701@oracle.com> References: <52CD8C41.9030701@oracle.com> Message-ID: <53375542-C096-496D-AFA7-E0234FA8891F@oracle.com> The cleanup looks fine to me, and the retaining of strong refs to the loggers. Is the weak ref guaranteed to be cleared at some point? -Chris > On 8 Jan 2014, at 17:34, Daniel Fuchs wrote: > > Hi, > > Please find below a patch for a test bug: > 8031068: java/util/logging/ParentLoggersTest.java: > checkLoggers: getLoggerNames() returned unexpected loggers > > https://bugs.openjdk.java.net/browse/JDK-8031068 > > > > > As usual - the issue is that the test creates loggers without > keeping any strong reference - thus allowing for the possibility > that they will be garbage collected too soon. > > I managed to reproduce systematically by adding a call to > System.gc() between the creation of the two loggers - and > passing -Xcomp -server to the VM. > With the fix the test no longer fails in that configuration. > > best regards, > > -- daniel From daniel.fuchs at oracle.com Wed Jan 8 17:55:05 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 08 Jan 2014 18:55:05 +0100 Subject: JDK 9 RFR for 8031068: java/util/logging/ParentLoggersTest.java: checkLoggers: getLoggerNames() returned unexpected loggers In-Reply-To: <53375542-C096-496D-AFA7-E0234FA8891F@oracle.com> References: <52CD8C41.9030701@oracle.com> <53375542-C096-496D-AFA7-E0234FA8891F@oracle.com> Message-ID: <52CD90F9.5030902@oracle.com> On 1/8/14 6:48 PM, Chris Hegarty wrote: > The cleanup looks fine to me, and the retaining of strong refs to the loggers. > > Is the weak ref guaranteed to be cleared at some point? Hopefully yes - my experiments show that it's cleared at the first iteration. Do you think I should add a counter - or remove that call to System.gc() altogether? This was just a means of triggering 8031068 and making the test fail more consistently (it just validates that this is the right fix for 8031068). -- daniel > > -Chris > >> On 8 Jan 2014, at 17:34, Daniel Fuchs wrote: >> >> Hi, >> >> Please find below a patch for a test bug: >> 8031068: java/util/logging/ParentLoggersTest.java: >> checkLoggers: getLoggerNames() returned unexpected loggers >> >> https://bugs.openjdk.java.net/browse/JDK-8031068 >> >> >> >> >> As usual - the issue is that the test creates loggers without >> keeping any strong reference - thus allowing for the possibility >> that they will be garbage collected too soon. >> >> I managed to reproduce systematically by adding a call to >> System.gc() between the creation of the two loggers - and >> passing -Xcomp -server to the VM. >> With the fix the test no longer fails in that configuration. >> >> best regards, >> >> -- daniel From dan.xu at oracle.com Wed Jan 8 17:56:40 2014 From: dan.xu at oracle.com (Dan Xu) Date: Wed, 08 Jan 2014 09:56:40 -0800 Subject: RFR: JDK-8028726 - (prefs) Check src/solaris/native/java/util/FileSystemPreferences.c for JNI pending exceptions In-Reply-To: <52CD194B.6090407@oracle.com> References: <52CB2E4E.7080200@oracle.com> <52CBCAB4.1040700@oracle.com> <52CCA0D4.3040907@oracle.com> <52CD194B.6090407@oracle.com> Message-ID: <52CD9158.7010907@oracle.com> Thank you, Alan. I will add this change into my fix and push it today. Thanks! -Dan On 01/08/2014 01:24 AM, Alan Bateman wrote: > On 08/01/2014 00:50, Dan Xu wrote: >> Hi All, >> >> Thanks for your good review. I have dropped the change in >> FileSystemPreferences.java , and created the new webrev which only >> changes FileSystemPreferences.c. Please help review it. Thanks! >> >> Webrev: http://cr.openjdk.java.net/~dxu/8028726/webrev.01/ >> >> When changing FileSystemPreferences.c, I noticed the code like >> "JNU_GetStringPlatformChars(env, java_fname, JNI_FALSE)". Because >> JNI_FALSE is passed into this function, I am wondering why our code >> still release string by calling JNU_ReleaseStringPlatformChars(env, >> java_fname, fname). Thanks! > This is the isCopy parameter to allow the function return whether it > has returned a copy or not. So the JNU_ReleaseStringPlatformChars is > needed. However the JNI_FALSE isn't right, it does happens to work > because JNI_FALSE is defined as 0, same as NULL. Do you mind changing > these to NULL as part of the change so that it's a bit more obvious? > (no need to publish a new webrev if there are no other changes). > > Otherwise looks fine to me. > > -Alan. From dan.xu at oracle.com Wed Jan 8 18:48:18 2014 From: dan.xu at oracle.com (Dan Xu) Date: Wed, 08 Jan 2014 10:48:18 -0800 Subject: RFR: JDK-8028726 - (prefs) Check src/solaris/native/java/util/FileSystemPreferences.c for JNI pending exceptions In-Reply-To: <52CD9158.7010907@oracle.com> References: <52CB2E4E.7080200@oracle.com> <52CBCAB4.1040700@oracle.com> <52CCA0D4.3040907@oracle.com> <52CD194B.6090407@oracle.com> <52CD9158.7010907@oracle.com> Message-ID: <52CD9D72.3010501@oracle.com> Hi Alan, Btw, I am wondering whether I need pass a variable to see if the returned char* is a copy or not, and basing on that to do the release. For example, jboolean isCopy; const char *fname = JNU_GetStringPlatformChars(env, java_fname, &isCopy); if (isCopy == JNI_TRUE) JNU_ReleaseStringPlatformChars(env, java_fname, fname); But according to the definition of JNU_GetStringPlatformChars(), it seems always to set *isCopy to JNI_TRUE currently. Because nativeGetStringPlatformChars() does nothing now. Thanks, -Dan On Wed 08 Jan 2014 09:56:40 AM PST, Dan Xu wrote: > Thank you, Alan. I will add this change into my fix and push it today. > Thanks! > > -Dan > > > On 01/08/2014 01:24 AM, Alan Bateman wrote: >> On 08/01/2014 00:50, Dan Xu wrote: >>> Hi All, >>> >>> Thanks for your good review. I have dropped the change in >>> FileSystemPreferences.java , and created the new webrev which only >>> changes FileSystemPreferences.c. Please help review it. Thanks! >>> >>> Webrev: http://cr.openjdk.java.net/~dxu/8028726/webrev.01/ >>> >>> When changing FileSystemPreferences.c, I noticed the code like >>> "JNU_GetStringPlatformChars(env, java_fname, JNI_FALSE)". Because >>> JNI_FALSE is passed into this function, I am wondering why our code >>> still release string by calling JNU_ReleaseStringPlatformChars(env, >>> java_fname, fname). Thanks! >> This is the isCopy parameter to allow the function return whether it >> has returned a copy or not. So the JNU_ReleaseStringPlatformChars is >> needed. However the JNI_FALSE isn't right, it does happens to work >> because JNI_FALSE is defined as 0, same as NULL. Do you mind changing >> these to NULL as part of the change so that it's a bit more obvious? >> (no need to publish a new webrev if there are no other changes). >> >> Otherwise looks fine to me. >> >> -Alan. > From Alan.Bateman at oracle.com Wed Jan 8 18:59:29 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 08 Jan 2014 18:59:29 +0000 Subject: RFR: JDK-8028726 - (prefs) Check src/solaris/native/java/util/FileSystemPreferences.c for JNI pending exceptions In-Reply-To: <52CD9D72.3010501@oracle.com> References: <52CB2E4E.7080200@oracle.com> <52CBCAB4.1040700@oracle.com> <52CCA0D4.3040907@oracle.com> <52CD194B.6090407@oracle.com> <52CD9158.7010907@oracle.com> <52CD9D72.3010501@oracle.com> Message-ID: <52CDA011.6080304@oracle.com> On 08/01/2014 18:48, Dan Xu wrote: > Hi Alan, > > Btw, I am wondering whether I need pass a variable to see if the > returned char* is a copy or not, and basing on that to do the release. > > For example, > > jboolean isCopy; > const char *fname = JNU_GetStringPlatformChars(env, java_fname, &isCopy); > if (isCopy == JNI_TRUE) > JNU_ReleaseStringPlatformChars(env, java_fname, fname); > > But according to the definition of JNU_GetStringPlatformChars(), it > seems always to set *isCopy to JNI_TRUE currently. Because > nativeGetStringPlatformChars() does nothing now. As things stand then JNU_GetStringPlatformChars always returned a copy. If it were changed to conditionally return a copy then every usage would need to specify isCopy and handle as you suggest. So it doesn't matter if you specify NULL or &isCopy, both will work here. -Alan From daniel.fuchs at oracle.com Wed Jan 8 19:30:43 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 08 Jan 2014 20:30:43 +0100 Subject: JDK 9 RFR for 8031068: java/util/logging/ParentLoggersTest.java: checkLoggers: getLoggerNames() returned unexpected loggers In-Reply-To: <53375542-C096-496D-AFA7-E0234FA8891F@oracle.com> References: <52CD8C41.9030701@oracle.com> <53375542-C096-496D-AFA7-E0234FA8891F@oracle.com> Message-ID: <52CDA763.3010805@oracle.com> On 1/8/14 6:48 PM, Chris Hegarty wrote: > The cleanup looks fine to me, and the retaining of strong refs to the loggers. > > Is the weak ref guaranteed to be cleared at some point? Hi Chris, I added a counter to the loop just to make sure it won't loop infinitely. Note that the goal of the loop is just to make 8031068 more likely to happen - if you add -server -Xcomp to the VM command line and add createdLoggers.clear() just before entering the loop (which 'unfixes' the test) then the test fails immediately with the same error than that revealed by 8031068. best regards, -- daniel > > -Chris > >> On 8 Jan 2014, at 17:34, Daniel Fuchs wrote: >> >> Hi, >> >> Please find below a patch for a test bug: >> 8031068: java/util/logging/ParentLoggersTest.java: >> checkLoggers: getLoggerNames() returned unexpected loggers >> >> https://bugs.openjdk.java.net/browse/JDK-8031068 >> >> >> >> >> As usual - the issue is that the test creates loggers without >> keeping any strong reference - thus allowing for the possibility >> that they will be garbage collected too soon. >> >> I managed to reproduce systematically by adding a call to >> System.gc() between the creation of the two loggers - and >> passing -Xcomp -server to the VM. >> With the fix the test no longer fails in that configuration. >> >> best regards, >> >> -- daniel From srikalyan.chandrashekar at oracle.com Wed Jan 8 20:08:15 2014 From: srikalyan.chandrashekar at oracle.com (srikalyan chandrashekar) Date: Wed, 08 Jan 2014 12:08:15 -0800 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52CD5851.7010702@gmail.com> References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> <52CB6330.3090901@oracle.com> <52CBBDEC.9030702@gmail.com> <52CC69CD.2090600@oracle.com> <52CD5851.7010702@gmail.com> Message-ID: <52CDB02F.2070908@oracle.com> Hi Peter, the jtreg test configuration is @run main/othervm -Xmx24M -XX:-UseTLAB OOMEInReferenceHandler. With this option you still have to run the test several times(like a 1000 runs) to capture 1(OR) more failures. Platform may not have an affect, however i used a 64 bit Ubuntu 12.04 LTS , 8GB, 2 core workstation and any JDK(7/8). --- Thanks kalyan On 01/08/2014 05:53 AM, Peter Levart wrote: > Hi Kalyan, > > What hardware/OS/JVM and what JVM options are you using to reproduce > this failure. I would really like to reproduce this myself, but all > attempts on my PC have so far been unsuccessful. I might be able to > get access to a machine that is similar to yours... > > Regards, Peter > > On 01/07/2014 09:55 PM, srikalyan chandrashekar wrote: >> Peter, getting state info out(to console or otherwise) from within >> Reference Handler's exceptions handlers have been unsuccessful. >> However David's suggestion produced some useful trace with fast debug >> build and could get some information , see the log here >> . >> --- >> Thanks >> kalyan >> On 01/07/2014 12:42 AM, Peter Levart wrote: >>> On 01/07/2014 03:15 AM, srikalyan chandrashekar wrote: >>>> Sure David will give that a try, we have so far attempted to >>>> 1. Print state data(as per the test creator peter.levart's inputs), >>> >>> Hi Kalyan, >>> >>> Have you been able to reproduce the OOME in that set-up? What was >>> the result? >>> >>> Regards, Peter >>> >>>> 2. Use UEH(uncaught exception handler per Mandy's inputs) >>>> >>>> -- >>>> Thanks >>>> kalyan >>>> >>>> On 1/6/14 4:40 PM, David Holmes wrote: >>>>> Back from vacation ... >>>>> >>>>> On 20/12/2013 4:49 PM, David Holmes wrote: >>>>>> On 20/12/2013 12:57 PM, srikalyan chandrashekar wrote: >>>>>>> Hi David Thanks for your comments, the unguarded part(clean and >>>>>>> enqueue) >>>>>>> in the Reference Handler thread does not seem to create any new >>>>>>> objects, >>>>>>> so it is the application(the test in this case) which is adding >>>>>>> objects >>>>>>> to heap and causing the Reference Handler to die with OOME. >>>>>> >>>>>> The ReferenceHandler thread can only get OOME if it allocates >>>>>> (directly >>>>>> or indirectly) - so there has to be something in the unguarded >>>>>> part that >>>>>> causes this. Again it may be an implicit action in the VM - >>>>>> similar to >>>>>> the class load issue for InterruptedException. >>>>> >>>>> Run a debug VM with -XX:+TraceExceptions to see where the OOME is >>>>> triggered. >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> David >>>>>> >>>>>> I am still >>>>>>> unsure about the side effects of the code change and agree with >>>>>>> your >>>>>>> thoughts(on memory exhaustion test's reliability). >>>>>>> >>>>>>> PS: hotspot dev alias removed from CC. >>>>>>> >>>>>>> -- >>>>>>> Thanks >>>>>>> kalyan >>>>>>> >>>>>>> On 12/19/13 5:08 PM, David Holmes wrote: >>>>>>>> Hi Kalyan, >>>>>>>> >>>>>>>> This is not a hotspot issue so I'm moving this to core-libs, >>>>>>>> please >>>>>>>> drop hotspot from any replies. >>>>>>>> >>>>>>>> On 20/12/2013 6:26 AM, srikalyan wrote: >>>>>>>>> Hi all, I have been working on the bug JDK-8022321 >>>>>>>>> , this is a >>>>>>>>> sporadic >>>>>>>>> failure and the webrev is available here >>>>>>>>> http://cr.openjdk.java.net/~srikchan/Regression/JDK-8022321_OOMEInReferenceHandler-webrev/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> I'm really not sure what to make of this. We have a test that >>>>>>>> triggers >>>>>>>> an out-of-memory condition but the OOME can actually turn up in >>>>>>>> the >>>>>>>> ReferenceHandler thread causing it to terminate and the test to >>>>>>>> fail. >>>>>>>> We previously accounted for the non-obvious occurrences of OOME >>>>>>>> due to >>>>>>>> the Object.wait and the possible need to load the >>>>>>>> InterruptedException >>>>>>>> class - but still the OOME can appear where we don't want it. So >>>>>>>> finally you have just placed the whole for(;;) loop in a >>>>>>>> try/catch(OOME) that ignores the OOME. I'm certain that makes >>>>>>>> the test >>>>>>>> happy, but I'm not sure it is really what we want for the >>>>>>>> ReferenceHandler thread. If the OOME occurs while cleaning, or >>>>>>>> enqueuing then we will fail to clean and/or enqueue but there >>>>>>>> would be >>>>>>>> no indication that has occurred and I think that is a bigger >>>>>>>> problem >>>>>>>> than this test failing. >>>>>>>> >>>>>>>> There may be no way to make this test 100% reliable. In fact I'd >>>>>>>> suggest that no memory exhaustion test can be 100% reliable. >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>>> * >>>>>>>>> **"Root Cause:Still not known"* >>>>>>>>> 2 places where there is a possibility for OOME >>>>>>>>> 1) Cleaner.clean() >>>>>>>>> 2) ReferenceQueue.enqueue() >>>>>>>>> >>>>>>>>> 1) The cleanup code in turn has 2 places where there is >>>>>>>>> potential for >>>>>>>>> throwing OOME, >>>>>>>>> a) thunk Thread which is run from clean() method. This >>>>>>>>> Runnable is >>>>>>>>> passed to Cleaner and appears in the following classes >>>>>>>>> java/nio/DirectByteBuffer.java >>>>>>>>> sun/misc/Perf.java >>>>>>>>> sun/nio/fs/NativeBuffer.java >>>>>>>>> sun/nio/ch/IOVecWrapper.java >>>>>>>>> sun/misc/Cleaner/ExitOnThrow.java >>>>>>>>> However none of the above overridden implementations ever >>>>>>>>> create an >>>>>>>>> object in the clean() code. >>>>>>>>> b) new PrivilegedAction created in try catch Exception >>>>>>>>> block of >>>>>>>>> clean() method but for this object to be created and to be held >>>>>>>>> responsible for OOME an Exception(other than OOME) has to be >>>>>>>>> thrown. >>>>>>>>> >>>>>>>>> 2) No new heap objects are created in the enqueue method nor >>>>>>>>> anywhere in >>>>>>>>> the deep call stack (VM.addFinalRefCount() etc) so this cannot >>>>>>>>> be a >>>>>>>>> potential cause. >>>>>>>>> >>>>>>>>> *Experimental change to java.lang.Reference.java* : >>>>>>>>> - Put one more guard (try catch with OOME block) in the Reference >>>>>>>>> Handler Thread which may give the Reference Handler a chance to >>>>>>>>> cleanup. >>>>>>>>> This is fixing the test failure (several 1000 runs with 0 >>>>>>>>> failures) >>>>>>>>> - Without the above change the test fails atleast 3-5 times >>>>>>>>> for every >>>>>>>>> 1000 run. >>>>>>>>> >>>>>>>>> *PS*: The code change is to a very critical part of JDK and i >>>>>>>>> am fully >>>>>>>>> not aware of the consequences of the change, hence seeking >>>>>>>>> expert help >>>>>>>>> here. Appreciate your time and inputs towards this. >>>>>>>>> >>>>>>> >>>> >>> >> > From sandeep.konchady at oracle.com Wed Jan 8 19:58:51 2014 From: sandeep.konchady at oracle.com (Sandeep Konchady) Date: Wed, 8 Jan 2014 11:58:51 -0800 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52CDB02F.2070908@oracle.com> References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> <52CB6330.3090901@oracle.com> <52CBBDEC.9030702@gmail.com> <52CC69CD.2090600@oracle.com> <52CD5851.7010702@gmail.com> <52CDB02F.2070908@oracle.com> Message-ID: Kal, Can you give access to Peter to the machine where you ran this test. Please send the details to him privately. Thanks, Sandeep On Jan 8, 2014, at 12:08 PM, srikalyan chandrashekar wrote: > Hi Peter, the jtreg test configuration is @run main/othervm -Xmx24M -XX:-UseTLAB OOMEInReferenceHandler. With this option you still have to run the test several times(like a 1000 runs) to capture 1(OR) more failures. Platform may not have an affect, however i used a 64 bit Ubuntu 12.04 LTS , 8GB, 2 core workstation and any JDK(7/8). > > --- > Thanks > kalyan > > On 01/08/2014 05:53 AM, Peter Levart wrote: >> Hi Kalyan, >> >> What hardware/OS/JVM and what JVM options are you using to reproduce this failure. I would really like to reproduce this myself, but all attempts on my PC have so far been unsuccessful. I might be able to get access to a machine that is similar to yours... >> >> Regards, Peter >> >> On 01/07/2014 09:55 PM, srikalyan chandrashekar wrote: >>> Peter, getting state info out(to console or otherwise) from within Reference Handler's exceptions handlers have been unsuccessful. However David's suggestion produced some useful trace with fast debug build and could get some information , see the log here . >>> --- >>> Thanks >>> kalyan >>> On 01/07/2014 12:42 AM, Peter Levart wrote: >>>> On 01/07/2014 03:15 AM, srikalyan chandrashekar wrote: >>>>> Sure David will give that a try, we have so far attempted to >>>>> 1. Print state data(as per the test creator peter.levart's inputs), >>>> >>>> Hi Kalyan, >>>> >>>> Have you been able to reproduce the OOME in that set-up? What was the result? >>>> >>>> Regards, Peter >>>> >>>>> 2. Use UEH(uncaught exception handler per Mandy's inputs) >>>>> >>>>> -- >>>>> Thanks >>>>> kalyan >>>>> >>>>> On 1/6/14 4:40 PM, David Holmes wrote: >>>>>> Back from vacation ... >>>>>> >>>>>> On 20/12/2013 4:49 PM, David Holmes wrote: >>>>>>> On 20/12/2013 12:57 PM, srikalyan chandrashekar wrote: >>>>>>>> Hi David Thanks for your comments, the unguarded part(clean and enqueue) >>>>>>>> in the Reference Handler thread does not seem to create any new objects, >>>>>>>> so it is the application(the test in this case) which is adding objects >>>>>>>> to heap and causing the Reference Handler to die with OOME. >>>>>>> >>>>>>> The ReferenceHandler thread can only get OOME if it allocates (directly >>>>>>> or indirectly) - so there has to be something in the unguarded part that >>>>>>> causes this. Again it may be an implicit action in the VM - similar to >>>>>>> the class load issue for InterruptedException. >>>>>> >>>>>> Run a debug VM with -XX:+TraceExceptions to see where the OOME is triggered. >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> David >>>>>>> >>>>>>> I am still >>>>>>>> unsure about the side effects of the code change and agree with your >>>>>>>> thoughts(on memory exhaustion test's reliability). >>>>>>>> >>>>>>>> PS: hotspot dev alias removed from CC. >>>>>>>> >>>>>>>> -- >>>>>>>> Thanks >>>>>>>> kalyan >>>>>>>> >>>>>>>> On 12/19/13 5:08 PM, David Holmes wrote: >>>>>>>>> Hi Kalyan, >>>>>>>>> >>>>>>>>> This is not a hotspot issue so I'm moving this to core-libs, please >>>>>>>>> drop hotspot from any replies. >>>>>>>>> >>>>>>>>> On 20/12/2013 6:26 AM, srikalyan wrote: >>>>>>>>>> Hi all, I have been working on the bug JDK-8022321 >>>>>>>>>> , this is a sporadic >>>>>>>>>> failure and the webrev is available here >>>>>>>>>> http://cr.openjdk.java.net/~srikchan/Regression/JDK-8022321_OOMEInReferenceHandler-webrev/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> I'm really not sure what to make of this. We have a test that triggers >>>>>>>>> an out-of-memory condition but the OOME can actually turn up in the >>>>>>>>> ReferenceHandler thread causing it to terminate and the test to fail. >>>>>>>>> We previously accounted for the non-obvious occurrences of OOME due to >>>>>>>>> the Object.wait and the possible need to load the InterruptedException >>>>>>>>> class - but still the OOME can appear where we don't want it. So >>>>>>>>> finally you have just placed the whole for(;;) loop in a >>>>>>>>> try/catch(OOME) that ignores the OOME. I'm certain that makes the test >>>>>>>>> happy, but I'm not sure it is really what we want for the >>>>>>>>> ReferenceHandler thread. If the OOME occurs while cleaning, or >>>>>>>>> enqueuing then we will fail to clean and/or enqueue but there would be >>>>>>>>> no indication that has occurred and I think that is a bigger problem >>>>>>>>> than this test failing. >>>>>>>>> >>>>>>>>> There may be no way to make this test 100% reliable. In fact I'd >>>>>>>>> suggest that no memory exhaustion test can be 100% reliable. >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>>> * >>>>>>>>>> **"Root Cause:Still not known"* >>>>>>>>>> 2 places where there is a possibility for OOME >>>>>>>>>> 1) Cleaner.clean() >>>>>>>>>> 2) ReferenceQueue.enqueue() >>>>>>>>>> >>>>>>>>>> 1) The cleanup code in turn has 2 places where there is potential for >>>>>>>>>> throwing OOME, >>>>>>>>>> a) thunk Thread which is run from clean() method. This Runnable is >>>>>>>>>> passed to Cleaner and appears in the following classes >>>>>>>>>> java/nio/DirectByteBuffer.java >>>>>>>>>> sun/misc/Perf.java >>>>>>>>>> sun/nio/fs/NativeBuffer.java >>>>>>>>>> sun/nio/ch/IOVecWrapper.java >>>>>>>>>> sun/misc/Cleaner/ExitOnThrow.java >>>>>>>>>> However none of the above overridden implementations ever create an >>>>>>>>>> object in the clean() code. >>>>>>>>>> b) new PrivilegedAction created in try catch Exception block of >>>>>>>>>> clean() method but for this object to be created and to be held >>>>>>>>>> responsible for OOME an Exception(other than OOME) has to be thrown. >>>>>>>>>> >>>>>>>>>> 2) No new heap objects are created in the enqueue method nor >>>>>>>>>> anywhere in >>>>>>>>>> the deep call stack (VM.addFinalRefCount() etc) so this cannot be a >>>>>>>>>> potential cause. >>>>>>>>>> >>>>>>>>>> *Experimental change to java.lang.Reference.java* : >>>>>>>>>> - Put one more guard (try catch with OOME block) in the Reference >>>>>>>>>> Handler Thread which may give the Reference Handler a chance to >>>>>>>>>> cleanup. >>>>>>>>>> This is fixing the test failure (several 1000 runs with 0 failures) >>>>>>>>>> - Without the above change the test fails atleast 3-5 times for every >>>>>>>>>> 1000 run. >>>>>>>>>> >>>>>>>>>> *PS*: The code change is to a very critical part of JDK and i am fully >>>>>>>>>> not aware of the consequences of the change, hence seeking expert help >>>>>>>>>> here. Appreciate your time and inputs towards this. >>>>>>>>>> >>>>>>>> >>>>> >>>> >>> >> > From mandy.chung at oracle.com Wed Jan 8 20:04:48 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 08 Jan 2014 12:04:48 -0800 Subject: JDK 9 RFR for 8031068: java/util/logging/ParentLoggersTest.java: checkLoggers: getLoggerNames() returned unexpected loggers In-Reply-To: <52CDA763.3010805@oracle.com> References: <52CD8C41.9030701@oracle.com> <53375542-C096-496D-AFA7-E0234FA8891F@oracle.com> <52CDA763.3010805@oracle.com> Message-ID: <52CDAF60.3030601@oracle.com> On 1/8/2014 11:30 AM, Daniel Fuchs wrote: > > The fix looks fine. The WeakReference and System.gc() call was to help reproduce the test failure. I wonder if it's really needed to be retained in the test (or better to remove it). There has been a few test failures due to this eager GC issue running in -server -Xcomp mode (I guess they are from the hotspot nightly testing). It might worth to run all logging tests with -server -Xcomp to find out if all test failures due to this issue are reported and fix them all together. Mandy From dl at cs.oswego.edu Wed Jan 8 21:28:24 2014 From: dl at cs.oswego.edu (Doug Lea) Date: Wed, 08 Jan 2014 16:28:24 -0500 Subject: JMM9 Project (Java Memory Model revisions for JDK9) Message-ID: <52CDC2F8.8060408@cs.oswego.edu> [to hotspot-dev, cross-post to core-libs-dev] We are proposing the creation of the JMM9 Project with Doug Lea as the Lead and Hotspot as the sponsoring Group. JMM9 is unusual as a Project in that it will not produce software, so there is no suggested initial list of Authors. The sponsoring Group is also somewhat arbitrary, but Hotspot seems most directly impacted. The main participants include academics and researchers expert in the formal specification of shared-memory concurrency, along with hardware and software engineers. The tentative participants are already making progress on identifying problems and solutions in ad-hoc discussions, so would be grateful to have an approved home base and mailing list to continue on. I expect that the Hotspot group lead will send out a Call For Votes shortly. For now, here is a paste of the JMM9 JEP that might be posted soon. Title: JMM9: Java Memory Model for JDK9 Author: Doug Lea [... other metadata omitted ...] Summary ------- This JEP serves to provide information and guidance for JDK9-related efforts bearing on shared-memory concurrency, including those on specification updates, JVM concurrency support, JDK components, testing, and tools. Engineering and release efforts in these areas will be subject to other JEPs, that will in turn become components of one or more JSRs targetted for JDK9. In particular, JLS (chapter 17) updates require such a JSR. Motivation ---------- Specifying shared memory consistency models, and developing and maintaining features and components that operate in accord with them, are among the most central yet difficult issues in engineering concurrent and parallel platforms. Specification limitations, errors, and unintended consequences become apparent over time; new hardware platforms, programming techniques, and software components and tools emerge that escape existing boundaries. This JEP addresses problems and extends coverage of the Java Memory Model (JMM), last revised for JDK5 (JSR133). Description ----------- Products of this JEP will be placed on the OpenJDK Wiki (https://wiki.openjdk.java.net/). The process will mainly take place on a dedicated openjdk mailing list (jmm9 at openjdk.java.net). We expect results to include the following: 1. Improved formalization. Parts of the underlying model will be reformulated. We aim for the revised model to be mechanically checkable, as well as more readily humanly understandable. When phrased in terms of JLS chapter 17 updates, this will also address existing errors pointed out in a number of academic papers. (For the earliest, see http://groups.inf.ed.ac.uk/request/jmmexamples.pdf "Java Memory Model Examples: Good, Bad and Ugly" by David Aspinall and Jaroslav Sevc?k.) 2. JVM coverage. Existing specifications focus on language-level constructs. This leaves some issues (for example initialization) incompletely defined, especially for other languages running on JVMs. These will be addressed, possibly by basing a core model on a minimal set of byte codes and intrinsics. 3. Extended scope. Existing specifications explicitly cover Java Threads, locks, monitors, and volatile and final fields. However, since JDK5, features have been added that cannot be rigorously specified in these terms (for example, AtomicX.weakCompareAndSet). These must be addressed. We also anticipate that further extensions may arise in the course of other JDK9 JEPs; possibly including forms of Atomics that can be embedded into other objects. 4. C11/C++11 compatibility. The C++11 and C11 standards adapted ideas from the JSR133 JMM spec effort. However, they also extended them to cover constructs that have been (or may be) added to Java only after JSR133 (see above). In part because Java programs may call C native libraries, it should be the case that equivalent constructs have compatible specifications across languages. We will further explore whether cross-language conventions can be established to ensure that low-level implementations of these constructs are compatible on common platforms. 5. Implementation guidance. JVM implementors, JDK library developers, and developers as a whole often find it useful to rely on documents explaining how the JMM impacts particular problems and solutions. We intend to provide such documents. 6. Testing support. Conformance to memory model requirements is difficult to test. We expect to work with engineers designing and implementing tests with clear bases in specifications. 7. Tool support. The reformulated model will be amenable for use by software development tools that analytically check for errors such as race conditions, as well as those checking that security properties hold across concurrent execution. While design and construction of tools themselves are out of scope, this JEP may contribute guidelines for annotations that would enable high quality static and dynamic analysis. Risks and Assumptions --------------------- Success requires contributions by concurrency experts in formal specification, hardware and software engineering, and software development tools. We have pre-arranged a core of expertise by obtaining tentative agreements to participate by academics, researchers, and engineers with extensive experience and knowledge in these areas. We will continue to encourage other experts to participate as well. If successful, we expect that this effort may lead to various enhancements, adjustments, and bugfixes across the platform. It is also possible that some uncommon borderline programming constructions will be shown to be problematic. However, we do not expect any further impact on backwards compatibility, or on unrelated specifications or APIs. If this work fails to achieve its goals, then the current state of affairs will continue to hold. Dependences ----------- The JEP does not depend on any others. We anticipate that future JEPs related to concurrency will depend on this one. From mandy.chung at oracle.com Wed Jan 8 22:09:42 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 08 Jan 2014 14:09:42 -0800 Subject: JDK 9 proposal: remove sun.misc.Ref In-Reply-To: <52CD1506.5030605@oracle.com> References: <52CC7EF8.8040208@oracle.com> <52CD1506.5030605@oracle.com> Message-ID: <52CDCCA6.6010608@oracle.com> On 1/8/2014 1:06 AM, Alan Bateman wrote: > On 07/01/2014 22:26, Joe Darcy wrote: >> >> So the type has been deprecated for at least 10 years. Rather than >> fixing the warning in the class, I think the best course of action is >> to remove the file in JDK 9. A build of OpenJDK without this file >> builds fine; if a build of the closed sources goes fine to, I think >> that should be sufficient justification for this type to be removed. >> >> Using code search engines, there are just a handful of references to >> sun.misc.Ref in the wihld, but any such uses will have several years >> to migrate to the standard java.util.SoftReference before JDK 9 ships. >> >> Comments? > See also JDK-6852936 [1] for other candidates to remove. We've always > been a bit hesitant to remove sun.misc classes out of concern as to > what/who it might break. > > As regards sun.misc.Ref then it would be good to remove it but I think > the appletviewer code needs to be checked first as it does appear to > be using it. I also think it's good to remove sun.misc.Ref and existing usages should be replaced with java.lang.ref.SoftReference where appropriate. In addition to appletviewer code using it, sun.misc.Cache extends sun.misc.Ref that will need to be updated which should be easy. Mandy From chris.hegarty at oracle.com Wed Jan 8 22:37:53 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 8 Jan 2014 22:37:53 +0000 Subject: JDK 9 RFR for 8031068: java/util/logging/ParentLoggersTest.java: checkLoggers: getLoggerNames() returned unexpected loggers In-Reply-To: <52CDAF60.3030601@oracle.com> References: <52CD8C41.9030701@oracle.com> <53375542-C096-496D-AFA7-E0234FA8891F@oracle.com> <52CDA763.3010805@oracle.com> <52CDAF60.3030601@oracle.com> Message-ID: <9CF0B317-AAE5-4BF3-B7B4-7996D7881DE8@oracle.com> > On 8 Jan 2014, at 20:04, Mandy Chung wrote: > > >> On 1/8/2014 11:30 AM, Daniel Fuchs wrote: >> >> > > The fix looks fine. The WeakReference and System.gc() call was to help reproduce the test failure. I wonder if it's really needed to be retained in the test (or better to remove it). Sounds like the most reasonable solution. -Chris. > There has been a few test failures due to this eager GC issue running in -server -Xcomp mode (I guess they are from the hotspot nightly testing). It might worth to run all logging tests with -server -Xcomp to find out if all test failures due to this issue are reported and fix them all together. > > Mandy > From david.holmes at oracle.com Thu Jan 9 07:22:21 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 09 Jan 2014 17:22:21 +1000 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52CD45E7.7010203@gmail.com> References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> <52CC72AB.2020104@oracle.com> <52CCEDE0.8000809@oracle.com> <52CCF079.4090301@oracle.com> <52CD45E7.7010203@gmail.com> Message-ID: <52CE4E2D.300@oracle.com> Thanks Peter. Kalyan: Can you confirm, as Peter asked, that the TraceExceptions output came from a failed run? AFAICS the Trace info is printed after each bytecode where there is a pending exception - though I'm not 100% sure on the printing within the VM runtime. Based on that I think we see the Trace output in run() at the point where wait() returns, so it may well be caught after that - in which case this was not a failing run. I also can't reproduce the problem :( David On 8/01/2014 10:34 PM, Peter Levart wrote: > On 01/08/2014 07:30 AM, David Holmes wrote: >> On 8/01/2014 4:19 PM, David Holmes wrote: >>> On 8/01/2014 7:33 AM, srikalyan chandrashekar wrote: >>>> Hi David, TraceExceptions with fastdebug build produced some nice trace >>>> . The >>>> native method wait(long) is where the OOME if being thrown, the deepest >>>> call is in >>>> >>>> src/share/vm/gc_interface/collectedHeap.inline.hpp, line 157 >>> >>> Yes but it is the caller that is of interest: >>> >>> Exception (0x00000000d6a01840) >>> thrown >>> [/HUDSON/workspace/8-2-build-linux-amd64/jdk8/1317/hotspot/src/share/vm/runtime/objectMonitor.cpp, >>> >>> line 1649] >>> for thread 0x00007f78c40d2800 >>> Exception (0x00000000d6a01840) >>> thrown in interpreter method <{method} {0x00007f78b4800ae0} 'wait' >>> '(J)V' in 'java/lang/Object'> >>> at bci 0 for thread 0x00007f78c40d2800 >>> >>> The ReferenceHandler thread gets the OOME trying to allocate the >>> InterruptedException. >> >> However we already have a catch block around the wait() so how is this >> OOME getting through? A bug in exception handling in the interpreter ?? >> > > Might be. And it may have something to do with the fact that the > Thread.run() method is the 1st call frame on the thread's stack (seems > like corner case). The last few meaningful TraceExceptions records are: > > > Exception (0x00000000d6a01840) > thrown > [/HUDSON/workspace/8-2-build-linux-amd64/jdk8/1317/hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp, > line 157] > for thread 0x00007f78c40d2800 > Exception (0x00000000d6a01840) > thrown > [/HUDSON/workspace/8-2-build-linux-amd64/jdk8/1317/hotspot/src/share/vm/runtime/objectMonitor.cpp, > line 1649] > for thread 0x00007f78c40d2800 > Exception (0x00000000d6a01840) > thrown in interpreter method <{method} {0x00007f78b4800ae0} 'wait' > '(J)V' in 'java/lang/Object'> > at bci 0 for thread 0x00007f78c40d2800 > Exception (0x00000000d6a01840) > thrown in interpreter method <{method} {0x00007f78b4800ca8} 'wait' > '()V' in 'java/lang/Object'> > at *bci 2* for thread 0x00007f78c40d2800 > Exception (0x00000000d6a01840) > thrown in interpreter method <{method} {0x00007f78b48d2250} 'run' > '()V' in 'java/lang/ref/Reference$ReferenceHandler'> > at *bci 36* for thread 0x00007f78c40d2800 > > > Here's the relevant bytecodes: > > > public class java.lang.Object > > public final void wait() throws java.lang.InterruptedException; > descriptor: ()V > flags: ACC_PUBLIC, ACC_FINAL > Code: > stack=3, locals=1, args_size=1 > 0: aload_0 > 1: lconst_0 > * 2: invokevirtual #73 // Method wait:(J)V* > 5: return > LineNumberTable: > line 502: 0 > line 503: 5 > Exceptions: > throws java.lang.InterruptedException > > > class java.lang.ref.Reference$ReferenceHandler extends java.lang.Thread > > public void run(); > descriptor: ()V > flags: ACC_PUBLIC > Code: > stack=2, locals=5, args_size=1 > 0: invokestatic #62 // Method > java/lang/ref/Reference.access$100:()Ljava/lang/ref/Reference$Lock; > 3: dup > 4: astore_2 > 5: monitorenter > 6: invokestatic #61 // Method > java/lang/ref/Reference.access$200:()Ljava/lang/ref/Reference; > 9: ifnull 33 > 12: invokestatic #61 // Method > java/lang/ref/Reference.access$200:()Ljava/lang/ref/Reference; > 15: astore_1 > 16: aload_1 > 17: invokestatic #64 // Method > java/lang/ref/Reference.access$300:(Ljava/lang/ref/Reference;)Ljava/lang/ref/Reference; > 20: invokestatic #63 // Method > java/lang/ref/Reference.access$202:(Ljava/lang/ref/Reference;)Ljava/lang/ref/Reference; > 23: pop > 24: aload_1 > 25: aconst_null > 26: invokestatic #65 // Method > java/lang/ref/Reference.access$302:(Ljava/lang/ref/Reference;Ljava/lang/ref/Reference;)Ljava/lang/ref/Reference; > 29: pop > 30: goto 52 > 33: invokestatic #62 // Method > java/lang/ref/Reference.access$100:()Ljava/lang/ref/Reference$Lock; > * 36: invokevirtual #59 // Method > java/lang/Object.wait:()V* > 39: goto 43 > 42: astore_3 > 43: goto 47 > 46: astore_3 > 47: aload_2 > 48: monitorexit > 49: goto 0 > 52: aload_2 > 53: monitorexit > 54: goto 64 > 57: astore 4 > 59: aload_2 > 60: monitorexit > 61: aload 4 > 63: athrow > 64: aload_1 > 65: instanceof #38 // class sun/misc/Cleaner > 68: ifeq 81 > 71: aload_1 > 72: checkcast #38 // class sun/misc/Cleaner > 75: invokevirtual #67 // Method > sun/misc/Cleaner.clean:()V > 78: goto 0 > 81: aload_1 > 82: getfield #57 // Field > java/lang/ref/Reference.queue:Ljava/lang/ref/ReferenceQueue; > 85: astore_2 > 86: aload_2 > 87: getstatic #58 // Field > java/lang/ref/ReferenceQueue.NULL:Ljava/lang/ref/ReferenceQueue; > 90: if_acmpeq 99 > 93: aload_2 > 94: aload_1 > 95: invokevirtual #66 // Method > java/lang/ref/ReferenceQueue.enqueue:(Ljava/lang/ref/Reference;)Z > 98: pop > 99: goto 0 > Exception table: > from to target type > * 33 39 42 Class java/lang/OutOfMemoryError* > 33 43 46 Class java/lang/InterruptedException > 6 49 57 any > 52 54 57 any > 57 61 57 any > StackMapTable: number_of_entries = 11 > frame_type = 0 /* same */ > frame_type = 253 /* append */ > offset_delta = 32 > locals = [ top, class java/lang/Object ] > frame_type = 72 /* same_locals_1_stack_item */ > stack = [ class java/lang/OutOfMemoryError ] > frame_type = 0 /* same */ > frame_type = 66 /* same_locals_1_stack_item */ > stack = [ class java/lang/InterruptedException ] > frame_type = 0 /* same */ > frame_type = 255 /* full_frame */ > offset_delta = 4 > locals = [ class java/lang/ref/Reference$ReferenceHandler, > class java/lang/ref/Reference, class java/lang/Object ] > stack = [] > frame_type = 255 /* full_frame */ > offset_delta = 4 > locals = [ class java/lang/ref/Reference$ReferenceHandler, > top, class java/lang/Object ] > stack = [ class java/lang/Throwable ] > frame_type = 255 /* full_frame */ > offset_delta = 6 > locals = [ class java/lang/ref/Reference$ReferenceHandler, > class java/lang/ref/Reference ] > stack = [] > frame_type = 16 /* same */ > frame_type = 250 /* chop */ > offset_delta = 17 > > LineNumberTable: > line 136: 0 > line 137: 6 > line 138: 12 > line 139: 16 > line 140: 24 > line 157: 33 > line 158: 39 > line 159: 43 > line 160: 47 > line 162: 52 > line 165: 64 > line 166: 71 > line 167: 78 > line 170: 81 > line 171: 86 > line 172: 99 > } > > > ... if I understand correctly the TraceExceptions' output, one record is > printed for each abruptly completed method. The last record printed > shows that Object.wait() method completed abruptly by throwing OOME. > Even if the OOME was caught and ignored, we would still get this > TraceExceptions record. Am I right? There's no record of abruptly > terminated ReferenceHandler.run() method in the output. This might be > because there's no method "calling" the ReferenceHandler.run() method, > since it is the 1st method on the call-stack. Are you sure the output is > from a failed test? > > Can we make the following adjustment to the ReferenceHandler and see > what gets printed and/or whether we still get uncaught OOME: > > > private static class ReferenceHandler extends Thread { > ... > public void run() { > runImpl(); > } > > private void runImpl() { > // ... the content of the original run() method > } > ... > > > > > Regards, Peter > >> David >> >>> David >>> ----- >>> >>>> ------------------- Excerpt Begins --------------------- >>>> >>>> 147 if (!gc_overhead_limit_was_exceeded) { >>>> 148 // -XX:+HeapDumpOnOutOfMemoryError and -XX:OnOutOfMemoryError >>>> support >>>> 149 report_java_out_of_memory("Java heap space"); >>>> 150 >>>> 151 if (JvmtiExport::should_post_resource_exhausted()) { >>>> 152 JvmtiExport::post_resource_exhausted( >>>> 153 JVMTI_RESOURCE_EXHAUSTED_OOM_ERROR | >>>> JVMTI_RESOURCE_EXHAUSTED_JAVA_HEAP, >>>> 154 "Java heap space"); >>>> 155 } >>>> 156 >>>> 157 THROW_OOP_0(Universe::out_of_memory_error_java_heap()); >>>> 158 } else { >>>> >>>> ------------------- Excerpt Ends --------------------- >>>> >>>> >>>> Would be helpful if David/some one else in the team could explain the >>>> latent aspects/probable cause. >>>> >>>> --- >>>> Thanks >>>> kalyan >>>> >>>> On 01/06/2014 04:40 PM, David Holmes wrote: >>>>> Back from vacation ... >>>>> >>>>> On 20/12/2013 4:49 PM, David Holmes wrote: >>>>>> On 20/12/2013 12:57 PM, srikalyan chandrashekar wrote: >>>>>>> Hi David Thanks for your comments, the unguarded part(clean and >>>>>>> enqueue) >>>>>>> in the Reference Handler thread does not seem to create any new >>>>>>> objects, >>>>>>> so it is the application(the test in this case) which is adding >>>>>>> objects >>>>>>> to heap and causing the Reference Handler to die with OOME. >>>>>> >>>>>> The ReferenceHandler thread can only get OOME if it allocates >>>>>> (directly >>>>>> or indirectly) - so there has to be something in the unguarded part >>>>>> that >>>>>> causes this. Again it may be an implicit action in the VM - >>>>>> similar to >>>>>> the class load issue for InterruptedException. >>>>> >>>>> Run a debug VM with -XX:+TraceExceptions to see where the OOME is >>>>> triggered. >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> David >>>>>> >>>>>> I am still >>>>>>> unsure about the side effects of the code change and agree with your >>>>>>> thoughts(on memory exhaustion test's reliability). >>>>>>> >>>>>>> PS: hotspot dev alias removed from CC. >>>>>>> >>>>>>> -- >>>>>>> Thanks >>>>>>> kalyan >>>>>>> >>>>>>> On 12/19/13 5:08 PM, David Holmes wrote: >>>>>>>> Hi Kalyan, >>>>>>>> >>>>>>>> This is not a hotspot issue so I'm moving this to core-libs, please >>>>>>>> drop hotspot from any replies. >>>>>>>> >>>>>>>> On 20/12/2013 6:26 AM, srikalyan wrote: >>>>>>>>> Hi all, I have been working on the bug JDK-8022321 >>>>>>>>> , this is a >>>>>>>>> sporadic >>>>>>>>> failure and the webrev is available here >>>>>>>>> http://cr.openjdk.java.net/~srikchan/Regression/JDK-8022321_OOMEInReferenceHandler-webrev/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> I'm really not sure what to make of this. We have a test that >>>>>>>> triggers >>>>>>>> an out-of-memory condition but the OOME can actually turn up in the >>>>>>>> ReferenceHandler thread causing it to terminate and the test to >>>>>>>> fail. >>>>>>>> We previously accounted for the non-obvious occurrences of OOME >>>>>>>> due to >>>>>>>> the Object.wait and the possible need to load the >>>>>>>> InterruptedException >>>>>>>> class - but still the OOME can appear where we don't want it. So >>>>>>>> finally you have just placed the whole for(;;) loop in a >>>>>>>> try/catch(OOME) that ignores the OOME. I'm certain that makes the >>>>>>>> test >>>>>>>> happy, but I'm not sure it is really what we want for the >>>>>>>> ReferenceHandler thread. If the OOME occurs while cleaning, or >>>>>>>> enqueuing then we will fail to clean and/or enqueue but there >>>>>>>> would be >>>>>>>> no indication that has occurred and I think that is a bigger >>>>>>>> problem >>>>>>>> than this test failing. >>>>>>>> >>>>>>>> There may be no way to make this test 100% reliable. In fact I'd >>>>>>>> suggest that no memory exhaustion test can be 100% reliable. >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>>> * >>>>>>>>> **"Root Cause:Still not known"* >>>>>>>>> 2 places where there is a possibility for OOME >>>>>>>>> 1) Cleaner.clean() >>>>>>>>> 2) ReferenceQueue.enqueue() >>>>>>>>> >>>>>>>>> 1) The cleanup code in turn has 2 places where there is potential >>>>>>>>> for >>>>>>>>> throwing OOME, >>>>>>>>> a) thunk Thread which is run from clean() method. This >>>>>>>>> Runnable is >>>>>>>>> passed to Cleaner and appears in the following classes >>>>>>>>> java/nio/DirectByteBuffer.java >>>>>>>>> sun/misc/Perf.java >>>>>>>>> sun/nio/fs/NativeBuffer.java >>>>>>>>> sun/nio/ch/IOVecWrapper.java >>>>>>>>> sun/misc/Cleaner/ExitOnThrow.java >>>>>>>>> However none of the above overridden implementations ever >>>>>>>>> create an >>>>>>>>> object in the clean() code. >>>>>>>>> b) new PrivilegedAction created in try catch Exception >>>>>>>>> block of >>>>>>>>> clean() method but for this object to be created and to be held >>>>>>>>> responsible for OOME an Exception(other than OOME) has to be >>>>>>>>> thrown. >>>>>>>>> >>>>>>>>> 2) No new heap objects are created in the enqueue method nor >>>>>>>>> anywhere in >>>>>>>>> the deep call stack (VM.addFinalRefCount() etc) so this cannot >>>>>>>>> be a >>>>>>>>> potential cause. >>>>>>>>> >>>>>>>>> *Experimental change to java.lang.Reference.java* : >>>>>>>>> - Put one more guard (try catch with OOME block) in the Reference >>>>>>>>> Handler Thread which may give the Reference Handler a chance to >>>>>>>>> cleanup. >>>>>>>>> This is fixing the test failure (several 1000 runs with 0 >>>>>>>>> failures) >>>>>>>>> - Without the above change the test fails atleast 3-5 times for >>>>>>>>> every >>>>>>>>> 1000 run. >>>>>>>>> >>>>>>>>> *PS*: The code change is to a very critical part of JDK and i am >>>>>>>>> fully >>>>>>>>> not aware of the consequences of the change, hence seeking expert >>>>>>>>> help >>>>>>>>> here. Appreciate your time and inputs towards this. >>>>>>>>> >>>>>>> >>>> > From paul.sandoz at oracle.com Thu Jan 9 09:48:17 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 9 Jan 2014 10:48:17 +0100 Subject: JDK 9 RFR of 8030814: Long.parseUnsignedLong should throw exception on too large input In-Reply-To: <20C5A625-0581-4B4A-A51F-73FE6D87388A@oracle.com> References: <20C5A625-0581-4B4A-A51F-73FE6D87388A@oracle.com> Message-ID: <379DEFA2-47CE-4426-AECA-8C3C4E7F287B@oracle.com> Hi Brian, This generally looks good, rather clever trick, i prefer it to using a cache. I agree with Joe some comments are required as it is not immediately obvious how this works. The additional tests seem adequate (overflow of the overflow), it's easy to go overboard e.g. you could test: BigInteger b = quotient.multiply(BigInteger.valueOf(radix + N)); for some range of N according to the radix under test. However, it might be useful to accurately test boundary conditions. Paul. On Jan 3, 2014, at 8:00 PM, Brian Burkhalter wrote: > Issue: https://bugs.openjdk.java.net/browse/JDK-8030814 > webrev: http://cr.openjdk.java.net/~bpb/8030814/webrev.2/ > > This review request follows from the discussion of last month in this thread: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024031.html > > The contributed patch before my minor tweaking of it is here > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024110.html > > with a detailed explanation of its logic here > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024136.html > > I added to the java/lang/Long/Unsigned JTREG test the case from the issue report as well as some other cases which exercise both sides of the A v B overflow test. > > Thanks, > > Brian From tristan.yan at oracle.com Thu Jan 9 09:52:49 2014 From: tristan.yan at oracle.com (Tristan Yan) Date: Thu, 09 Jan 2014 17:52:49 +0800 Subject: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm In-Reply-To: <52CBE530.6070105@oracle.com> References: <52CBA203.7080706@oracle.com> <52CBA851.8070008@oracle.com> <52CBB7C0.1040002@oracle.com> <52CBC66B.7000003@oracle.com> <52CBD8B7.8050002@oracle.com> <52CBE530.6070105@oracle.com> Message-ID: <52CE7171.1080407@oracle.com> Can someone else give a second review on this. Thank you Tristan On 01/07/2014 07:29 PM, David Holmes wrote: > On 7/01/2014 8:36 PM, Tristan Yan wrote: >> Hi David >> You're totally right. Sorry I ask you review it again. >> >> http://cr.openjdk.java.net/~tyan/JDK-7027502/webrev.02/ > > Looks good now. > > Thanks, > David > >> Thank you very much. >> Tristan >> >> On 01/07/2014 05:18 PM, David Holmes wrote: >>> On 7/01/2014 6:16 PM, Tristan Yan wrote: >>>> Thank you, David >>>> I fixed copyright and change back sleep. >>>> println was intended to be left in. This test was failed with timeout, >>>> printf could help us to detect the value of total_turns_taken and >>>> expected_turns_taken. >>>> Please review it again >>>> >>>> http://cr.openjdk.java.net/~tyan/JDK-7027502/webrev.01/ >>> >>> Comma after 2014 still missing in copyright. >>> >>> You need to read total_turns_taken.get() once and use that value in >>> both the println and the == test, so that you print the value you >>> actually tested. >>> >>> David >>> >>>> Regards >>>> Tristan >>>> >>>> On 01/07/2014 03:10 PM, David Holmes wrote: >>>>> Hi Tristan, >>>>> >>>>> On 7/01/2014 4:43 PM, Tristan Yan wrote: >>>>>> Hi All >>>>>> Please help to review the code change for JDK-7027502. >>>>>> >>>>>> http://cr.openjdk.java.net/~tyan/JDK-7027502/ >>>>>> >>>>>> Description: >>>>>> This test was failed in JPRT test but recently we test with same >>>>>> binaries run, it doesn't fail any more. The intention for this code >>>>>> change is bringing this test back to normal test and make this test >>>>>> robust and more informative. Change includes >>>>>> 1. Remove this test from ProblemList. >>>>>> 2. Change static member total_turns_taken into a local variable. >>>>>> >>>>>> Please let me know your comment on this. >>>>> >>>>> 2 * Copyright (c) 2004,2014 Oracle and/or its affiliates. All >>>>> rights reserved. >>>>> >>>>> Correct copyright format should have a space before 2014 and a comma >>>>> after: >>>>> >>>>> * Copyright (c) 2004, 2014, Oracle and/or its affiliates. All rights >>>>> reserved. >>>>> >>>>> --- >>>>> >>>>> Was this println intended to be left in? >>>>> >>>>> 114 System.out.println("total_turns_taken =" + >>>>> total_turns_taken + >>>>> 115 ";expected_turns_taken =" + >>>>> expected_turns_taken); >>>>> 116 if ( total_turns_taken.get() == >>>>> expected_turns_taken ) { >>>>> >>>>> >>>>> You only want to read total_turns_taken once otherwise you may see >>>>> misleading print outs. >>>>> >>>>> --- >>>>> >>>>> 119 /* Create some monitor contention by sleeping >>>>> with >>>>> lock */ >>>>> 120 if ( default_contention_sleep > 0 ) { >>>>> 121 System.out.println("Context sleeping, to >>>>> create contention"); >>>>> 122 try { >>>>> 123 turn.wait((long) >>>>> default_contention_sleep); >>>>> 124 } catch (InterruptedException ignore) { } >>>>> 125 } >>>>> >>>>> By changing the Thread.sleep to turn.wait you no longer introduce any >>>>> contention as the wait() will release the monitor. >>>>> >>>>> David >>>>> >>>>>> Thank you. >>>>>> Tristan >>>> >> From paul.sandoz at oracle.com Thu Jan 9 10:28:40 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 9 Jan 2014 11:28:40 +0100 Subject: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm In-Reply-To: <52CE7171.1080407@oracle.com> References: <52CBA203.7080706@oracle.com> <52CBA851.8070008@oracle.com> <52CBB7C0.1040002@oracle.com> <52CBC66B.7000003@oracle.com> <52CBD8B7.8050002@oracle.com> <52CBE530.6070105@oracle.com> <52CE7171.1080407@oracle.com> Message-ID: <2BD1713F-655F-429A-9FC0-A14832D32C9D@oracle.com> On Jan 9, 2014, at 10:52 AM, Tristan Yan wrote: > Can someone else give a second review on this. In a comment the bug you state: "here total_turns_taken is a static variable, it could affect by other tests" I don't quite know under what test circumstances that can happen, but if so is the following also an issue: 52 private final static TurnChecker turn = new TurnChecker(-1); ? FWIW an alternative to using an AtomicInteger would be for the main loop to sum up thread_turns of each Context, since read/writes are all performed in a synchronized block. Paul. From paul.sandoz at oracle.com Thu Jan 9 10:50:48 2014 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Thu, 09 Jan 2014 10:50:48 +0000 Subject: hg: jdk8/tl/jdk: 8031187: DoubleStream.count is incorrect for a stream containing > Integer.MAX_VALUE elements Message-ID: <20140109105107.5E7D86248A@hg.openjdk.java.net> Changeset: 630a92015993 Author: psandoz Date: 2014-01-09 10:52 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/630a92015993 8031187: DoubleStream.count is incorrect for a stream containing > Integer.MAX_VALUE elements Reviewed-by: darcy ! src/share/classes/java/util/stream/DoublePipeline.java ! src/share/classes/java/util/stream/IntPipeline.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/CountLargeTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/CountTest.java From tristan.yan at oracle.com Thu Jan 9 11:07:51 2014 From: tristan.yan at oracle.com (Tristan Yan) Date: Thu, 09 Jan 2014 19:07:51 +0800 Subject: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm In-Reply-To: <2BD1713F-655F-429A-9FC0-A14832D32C9D@oracle.com> References: <52CBA203.7080706@oracle.com> <52CBA851.8070008@oracle.com> <52CBB7C0.1040002@oracle.com> <52CBC66B.7000003@oracle.com> <52CBD8B7.8050002@oracle.com> <52CBE530.6070105@oracle.com> <52CE7171.1080407@oracle.com> <2BD1713F-655F-429A-9FC0-A14832D32C9D@oracle.com> Message-ID: <52CE8307.6040606@oracle.com> Thank you Paul I change turn to local variable as well. http://cr.openjdk.java.net/~tyan/JDK-7027502/webrev.03/ I am not sure I understand your second suggestion here, sum up thread_turns of each Context(This is a fixed value) doesn't equal total_turns_taken. Regards Tristan On 01/09/2014 06:28 PM, Paul Sandoz wrote: > On Jan 9, 2014, at 10:52 AM, Tristan Yan wrote: > >> Can someone else give a second review on this. >> > In a comment the bug you state: "here total_turns_taken is a static > variable, it could affect by other tests" I don't quite know under > what test circumstances that can happen, but if so is the following > also an issue: 52 private final static TurnChecker turn = new > TurnChecker(-1); ? FWIW an alternative to using an AtomicInteger would > be for the main loop to sum up thread_turns of each Context, since > read/writes are all performed in a synchronized block. Paul. > From david.holmes at oracle.com Thu Jan 9 11:12:46 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 09 Jan 2014 21:12:46 +1000 Subject: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm In-Reply-To: <2BD1713F-655F-429A-9FC0-A14832D32C9D@oracle.com> References: <52CBA203.7080706@oracle.com> <52CBA851.8070008@oracle.com> <52CBB7C0.1040002@oracle.com> <52CBC66B.7000003@oracle.com> <52CBD8B7.8050002@oracle.com> <52CBE530.6070105@oracle.com> <52CE7171.1080407@oracle.com> <2BD1713F-655F-429A-9FC0-A14832D32C9D@oracle.com> Message-ID: <52CE842E.2060702@oracle.com> On 9/01/2014 8:28 PM, Paul Sandoz wrote: > > On Jan 9, 2014, at 10:52 AM, Tristan Yan wrote: > >> Can someone else give a second review on this. > > In a comment the bug you state: > > "here total_turns_taken is a static variable, it could affect by other tests" > > I don't quite know under what test circumstances that can happen, but if so is the following also an issue: > > 52 private final static TurnChecker turn = new TurnChecker(-1); > > ? > > FWIW an alternative to using an AtomicInteger would be for the main loop to sum up thread_turns of each Context, since read/writes are all performed in a synchronized block. Now that you mention it ... I had mistakenly thought the switch to an AtomicInteger was to ensure the ++ was actually atomic, but as you note these updates all take place within a synchronized block that locks the same "turn" instance of TurnChecker. So now I'm confused by the change. Tristan what was the basis of making the change that you did ? If the issue was that concurrent hprof tests all used the same Context class in the same VM (how??) then as Paul says the TurnChecker instance would also be a problem. Otherwise the change makes no real difference to the semantics of the test as far as I can see. David > Paul. > From paul.sandoz at oracle.com Thu Jan 9 11:24:01 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 9 Jan 2014 12:24:01 +0100 Subject: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm In-Reply-To: <52CE8307.6040606@oracle.com> References: <52CBA203.7080706@oracle.com> <52CBA851.8070008@oracle.com> <52CBB7C0.1040002@oracle.com> <52CBC66B.7000003@oracle.com> <52CBD8B7.8050002@oracle.com> <52CBE530.6070105@oracle.com> <52CE7171.1080407@oracle.com> <2BD1713F-655F-429A-9FC0-A14832D32C9D@oracle.com> <52CE8307.6040606@oracle.com> Message-ID: <361A9C71-0F1D-4D1E-AB9D-EB08E2DDE25C@oracle.com> On Jan 9, 2014, at 12:07 PM, Tristan Yan wrote: > Thank you Paul > > I change turn to local variable as well. > > http://cr.openjdk.java.net/~tyan/JDK-7027502/webrev.03/ > > I am not sure I understand your second suggestion here, sum up thread_turns of each Context(This is a fixed value) doesn't equal total_turns_taken. > The suggestion (feel free to ignore it!) was to take the local variable: 161 int turns_taken = 0; and move it to a field on Context. Then in the synchronized block of the main loop sum 'em up. e.g.: List cs = ; ... int current_total_turns_taken = cs.stream().mapToInt(c -> c.turns_taken).sum(); Obviously that is less efficient but it does separate concerns. Paul. From david.holmes at oracle.com Thu Jan 9 11:27:28 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 09 Jan 2014 21:27:28 +1000 Subject: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm In-Reply-To: <52CE8307.6040606@oracle.com> References: <52CBA203.7080706@oracle.com> <52CBA851.8070008@oracle.com> <52CBB7C0.1040002@oracle.com> <52CBC66B.7000003@oracle.com> <52CBD8B7.8050002@oracle.com> <52CBE530.6070105@oracle.com> <52CE7171.1080407@oracle.com> <2BD1713F-655F-429A-9FC0-A14832D32C9D@oracle.com> <52CE8307.6040606@oracle.com> Message-ID: <52CE87A0.90504@oracle.com> On 9/01/2014 9:07 PM, Tristan Yan wrote: > Thank you Paul > > I change turn to local variable as well. > > http://cr.openjdk.java.net/~tyan/JDK-7027502/webrev.03/ > Okay I think I get it now. Both MonitorTest and WaitersTest use the Context class, so if both tests run in the same VM the second test will see the static total_turns_taken and "turn" in the state they were left from the first test - hence the second test will always fail. The bug report suggests making the tests othervm to avoid the problem but instead you have changed from using static state to instance state so that there is no interference. But you can't pass a reference to a simple int, for total_turns_taken, hence you turned it into the only mutable Integer type: AtomicInteger. I'm okay with this final form of the change. othervm would have been simpler :) These are ugly tests even with your changes. BTW: 107 Thread.yield(); 108 Thread.sleep(sleepTime); The yield() before the sleep is completely pointless. David ----- > I am not sure I understand your second suggestion here, sum up > thread_turns of each Context(This is a fixed value) doesn't equal > total_turns_taken. > > Regards > > Tristan > > On 01/09/2014 06:28 PM, Paul Sandoz wrote: > >> On Jan 9, 2014, at 10:52 AM, Tristan Yan wrote: >> >>> Can someone else give a second review on this. >>> >> In a comment the bug you state: "here total_turns_taken is a static >> variable, it could affect by other tests" I don't quite know under >> what test circumstances that can happen, but if so is the following >> also an issue: 52 private final static TurnChecker turn = new >> TurnChecker(-1); ? FWIW an alternative to using an AtomicInteger would >> be for the main loop to sum up thread_turns of each Context, since >> read/writes are all performed in a synchronized block. Paul. >> From david.holmes at oracle.com Thu Jan 9 11:34:40 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 09 Jan 2014 21:34:40 +1000 Subject: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm In-Reply-To: <52CE87A0.90504@oracle.com> References: <52CBA203.7080706@oracle.com> <52CBA851.8070008@oracle.com> <52CBB7C0.1040002@oracle.com> <52CBC66B.7000003@oracle.com> <52CBD8B7.8050002@oracle.com> <52CBE530.6070105@oracle.com> <52CE7171.1080407@oracle.com> <2BD1713F-655F-429A-9FC0-A14832D32C9D@oracle.com> <52CE8307.6040606@oracle.com> <52CE87A0.90504@oracle.com> Message-ID: <52CE8950.1010204@oracle.com> On 9/01/2014 9:27 PM, David Holmes wrote: > On 9/01/2014 9:07 PM, Tristan Yan wrote: >> Thank you Paul >> >> I change turn to local variable as well. >> >> http://cr.openjdk.java.net/~tyan/JDK-7027502/webrev.03/ >> > > Okay I think I get it now. Both MonitorTest and WaitersTest use the > Context class, so if both tests run in the same VM the second test will > see the static total_turns_taken and "turn" in the state they were left > from the first test - hence the second test will always fail. The bug > report suggests making the tests othervm to avoid the problem but > instead you have changed from using static state to instance state so > that there is no interference. > > But you can't pass a reference to a simple int, for total_turns_taken, > hence you turned it into the only mutable Integer type: AtomicInteger. > > I'm okay with this final form of the change. othervm would have been > simpler :) These are ugly tests even with your changes. > > BTW: > > 107 Thread.yield(); > 108 Thread.sleep(sleepTime); > > The yield() before the sleep is completely pointless. Ditto for: 126 Thread.yield(); 127 Thread.sleep((long)default_contention_sleep); David ----- > David > ----- > >> I am not sure I understand your second suggestion here, sum up >> thread_turns of each Context(This is a fixed value) doesn't equal >> total_turns_taken. >> >> Regards >> >> Tristan >> >> On 01/09/2014 06:28 PM, Paul Sandoz wrote: >> >>> On Jan 9, 2014, at 10:52 AM, Tristan Yan wrote: >>> >>>> Can someone else give a second review on this. >>>> >>> In a comment the bug you state: "here total_turns_taken is a static >>> variable, it could affect by other tests" I don't quite know under >>> what test circumstances that can happen, but if so is the following >>> also an issue: 52 private final static TurnChecker turn = new >>> TurnChecker(-1); ? FWIW an alternative to using an AtomicInteger would >>> be for the main loop to sum up thread_turns of each Context, since >>> read/writes are all performed in a synchronized block. Paul. >>> From tristan.yan at oracle.com Thu Jan 9 11:53:33 2014 From: tristan.yan at oracle.com (Tristan Yan) Date: Thu, 09 Jan 2014 19:53:33 +0800 Subject: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm In-Reply-To: <52CE8950.1010204@oracle.com> References: <52CBA203.7080706@oracle.com> <52CBA851.8070008@oracle.com> <52CBB7C0.1040002@oracle.com> <52CBC66B.7000003@oracle.com> <52CBD8B7.8050002@oracle.com> <52CBE530.6070105@oracle.com> <52CE7171.1080407@oracle.com> <2BD1713F-655F-429A-9FC0-A14832D32C9D@oracle.com> <52CE8307.6040606@oracle.com> <52CE87A0.90504@oracle.com> <52CE8950.1010204@oracle.com> Message-ID: <52CE8DBD.4010702@oracle.com> Thanks David I removed those pointless yield, is it okay you can sponsor this for me? http://cr.openjdk.java.net/~tyan/JDK-7027502/webrev.04/ Regards Tristan On 01/09/2014 07:34 PM, David Holmes wrote: > On 9/01/2014 9:27 PM, David Holmes wrote: >> On 9/01/2014 9:07 PM, Tristan Yan wrote: >>> Thank you Paul >>> >>> I change turn to local variable as well. >>> >>> http://cr.openjdk.java.net/~tyan/JDK-7027502/webrev.03/ >>> >> >> Okay I think I get it now. Both MonitorTest and WaitersTest use the >> Context class, so if both tests run in the same VM the second test will >> see the static total_turns_taken and "turn" in the state they were left >> from the first test - hence the second test will always fail. The bug >> report suggests making the tests othervm to avoid the problem but >> instead you have changed from using static state to instance state so >> that there is no interference. >> >> But you can't pass a reference to a simple int, for total_turns_taken, >> hence you turned it into the only mutable Integer type: AtomicInteger. >> >> I'm okay with this final form of the change. othervm would have been >> simpler :) These are ugly tests even with your changes. >> >> BTW: >> >> 107 Thread.yield(); >> 108 Thread.sleep(sleepTime); >> >> The yield() before the sleep is completely pointless. > > Ditto for: > > 126 Thread.yield(); > 127 Thread.sleep((long)default_contention_sleep); > > David > ----- > >> David >> ----- >> >>> I am not sure I understand your second suggestion here, sum up >>> thread_turns of each Context(This is a fixed value) doesn't equal >>> total_turns_taken. >>> >>> Regards >>> >>> Tristan >>> >>> On 01/09/2014 06:28 PM, Paul Sandoz wrote: >>> >>>> On Jan 9, 2014, at 10:52 AM, Tristan Yan >>>> wrote: >>>> >>>>> Can someone else give a second review on this. >>>>> >>>> In a comment the bug you state: "here total_turns_taken is a static >>>> variable, it could affect by other tests" I don't quite know under >>>> what test circumstances that can happen, but if so is the following >>>> also an issue: 52 private final static TurnChecker turn = new >>>> TurnChecker(-1); ? FWIW an alternative to using an AtomicInteger would >>>> be for the main loop to sum up thread_turns of each Context, since >>>> read/writes are all performed in a synchronized block. Paul. >>>> From Alan.Bateman at oracle.com Thu Jan 9 12:14:44 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 09 Jan 2014 12:14:44 +0000 Subject: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm In-Reply-To: <52CE87A0.90504@oracle.com> References: <52CBA203.7080706@oracle.com> <52CBA851.8070008@oracle.com> <52CBB7C0.1040002@oracle.com> <52CBC66B.7000003@oracle.com> <52CBD8B7.8050002@oracle.com> <52CBE530.6070105@oracle.com> <52CE7171.1080407@oracle.com> <2BD1713F-655F-429A-9FC0-A14832D32C9D@oracle.com> <52CE8307.6040606@oracle.com> <52CE87A0.90504@oracle.com> Message-ID: <52CE92B4.4020009@oracle.com> On 09/01/2014 11:27, David Holmes wrote: > > Okay I think I get it now. Both MonitorTest and WaitersTest use the > Context class, so if both tests run in the same VM the second test > will see the static total_turns_taken and "turn" in the state they > were left from the first test - hence the second test will always > fail. The bug report suggests making the tests othervm to avoid the > problem but instead you have changed from using static state to > instance state so that there is no interference. I haven't been following this one closely but I thought that jtreg created a class loader for each test (irrespective of mode) so I wouldn't expect statics to be an issue. -Alan. From brian.burkhalter at oracle.com Thu Jan 9 15:32:31 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 9 Jan 2014 07:32:31 -0800 Subject: JDK 9 RFR of 8030814: Long.parseUnsignedLong should throw exception on too large input In-Reply-To: <379DEFA2-47CE-4426-AECA-8C3C4E7F287B@oracle.com> References: <20C5A625-0581-4B4A-A51F-73FE6D87388A@oracle.com> <379DEFA2-47CE-4426-AECA-8C3C4E7F287B@oracle.com> Message-ID: On Jan 9, 2014, at 1:48 AM, Paul Sandoz wrote: > This generally looks good, rather clever trick, i prefer it to using a cache. > > I agree with Joe some comments are required as it is not immediately obvious how this works. I have some simpler comments almost done being redacted. > The additional tests seem adequate (overflow of the overflow), it's easy to go overboard e.g. you could test: > > BigInteger b = quotient.multiply(BigInteger.valueOf(radix + N)); > > for some range of N according to the radix under test. However, it might be useful to accurately test boundary conditions. Working on that also. Thanks, Brian From daniel.fuchs at oracle.com Thu Jan 9 18:18:55 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 09 Jan 2014 19:18:55 +0100 Subject: JDK 9 RFR for 8031068: java/util/logging/ParentLoggersTest.java: checkLoggers: getLoggerNames() returned unexpected loggers In-Reply-To: <9CF0B317-AAE5-4BF3-B7B4-7996D7881DE8@oracle.com> References: <52CD8C41.9030701@oracle.com> <53375542-C096-496D-AFA7-E0234FA8891F@oracle.com> <52CDA763.3010805@oracle.com> <52CDAF60.3030601@oracle.com> <9CF0B317-AAE5-4BF3-B7B4-7996D7881DE8@oracle.com> Message-ID: <52CEE80F.1090708@oracle.com> On 1/8/14 11:37 PM, Chris Hegarty wrote: > >> On 8 Jan 2014, at 20:04, Mandy Chung wrote: >> >> >>> On 1/8/2014 11:30 AM, Daniel Fuchs wrote: >>> >>> >> >> The fix looks fine. The WeakReference and System.gc() call was to help reproduce the test failure. I wonder if it's really needed to be retained in the test (or better to remove it). > > Sounds like the most reasonable solution. OK - I removed the unnecessary calls. http://cr.openjdk.java.net/~dfuchs/webrev_8031068-jdk9/webrev.02/ -- daniel > > -Chris. > >> There has been a few test failures due to this eager GC issue running in -server -Xcomp mode (I guess they are from the hotspot nightly testing). It might worth to run all logging tests with -server -Xcomp to find out if all test failures due to this issue are reported and fix them all together. >> >> Mandy >> From mandy.chung at oracle.com Thu Jan 9 18:38:51 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 09 Jan 2014 10:38:51 -0800 Subject: JDK 9 RFR for 8031068: java/util/logging/ParentLoggersTest.java: checkLoggers: getLoggerNames() returned unexpected loggers In-Reply-To: <52CEE80F.1090708@oracle.com> References: <52CD8C41.9030701@oracle.com> <53375542-C096-496D-AFA7-E0234FA8891F@oracle.com> <52CDA763.3010805@oracle.com> <52CDAF60.3030601@oracle.com> <9CF0B317-AAE5-4BF3-B7B4-7996D7881DE8@oracle.com> <52CEE80F.1090708@oracle.com> Message-ID: <52CEECBB.6080007@oracle.com> On 1/9/2014 10:18 AM, Daniel Fuchs wrote: > OK - I removed the unnecessary calls. > > http://cr.openjdk.java.net/~dfuchs/webrev_8031068-jdk9/webrev.02/ Thumbs up! Thanks for the update. You have fixed a few test failures of this issue. Do you know if there is any other logging test that should be fixed? Mandy From chris.hegarty at oracle.com Thu Jan 9 18:49:45 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 9 Jan 2014 18:49:45 +0000 Subject: JDK 9 RFR for 8031068: java/util/logging/ParentLoggersTest.java: checkLoggers: getLoggerNames() returned unexpected loggers In-Reply-To: <52CEE80F.1090708@oracle.com> References: <52CD8C41.9030701@oracle.com> <53375542-C096-496D-AFA7-E0234FA8891F@oracle.com> <52CDA763.3010805@oracle.com> <52CDAF60.3030601@oracle.com> <9CF0B317-AAE5-4BF3-B7B4-7996D7881DE8@oracle.com> <52CEE80F.1090708@oracle.com> Message-ID: > On 9 Jan 2014, at 18:18, Daniel Fuchs wrote: > >> On 1/8/14 11:37 PM, Chris Hegarty wrote: >> >>> On 8 Jan 2014, at 20:04, Mandy Chung wrote: >>> >>> >>>> On 1/8/2014 11:30 AM, Daniel Fuchs wrote: >>>> >>>> >>> >>> The fix looks fine. The WeakReference and System.gc() call was to help reproduce the test failure. I wonder if it's really needed to be retained in the test (or better to remove it). >> >> Sounds like the most reasonable solution. > > OK - I removed the unnecessary calls. > > http://cr.openjdk.java.net/~dfuchs/webrev_8031068-jdk9/webrev.02/ Thanks. Look good to me. -Chris. > > -- daniel > >> >> -Chris. >> >>> There has been a few test failures due to this eager GC issue running in -server -Xcomp mode (I guess they are from the hotspot nightly testing). It might worth to run all logging tests with -server -Xcomp to find out if all test failures due to this issue are reported and fix them all together. >>> >>> Mandy > From daniel.fuchs at oracle.com Thu Jan 9 22:12:54 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 09 Jan 2014 23:12:54 +0100 Subject: JDK 9 RFR for 8031068: java/util/logging/ParentLoggersTest.java: checkLoggers: getLoggerNames() returned unexpected loggers In-Reply-To: <52CEECBB.6080007@oracle.com> References: <52CD8C41.9030701@oracle.com> <53375542-C096-496D-AFA7-E0234FA8891F@oracle.com> <52CDA763.3010805@oracle.com> <52CDAF60.3030601@oracle.com> <9CF0B317-AAE5-4BF3-B7B4-7996D7881DE8@oracle.com> <52CEE80F.1090708@oracle.com> <52CEECBB.6080007@oracle.com> Message-ID: <52CF1EE6.10300@oracle.com> On 1/9/14 7:38 PM, Mandy Chung wrote: > On 1/9/2014 10:18 AM, Daniel Fuchs wrote: >> OK - I removed the unnecessary calls. >> >> http://cr.openjdk.java.net/~dfuchs/webrev_8031068-jdk9/webrev.02/ > > Thumbs up! Thanks for the update. > > You have fixed a few test failures of this issue. Do you know if > there is any other logging test that should be fixed? Yeah. That's what of the tests that had been identified by Se?n in https://bugs.openjdk.java.net/browse/JDK-8029595. Hopefully there's only one left now - though I may have to review my analysis as I did it before discovering that holding the logger in a local variable was not enough to prevent garbage collection... -- daniel > > Mandy > From david.holmes at oracle.com Thu Jan 9 22:35:36 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 10 Jan 2014 08:35:36 +1000 Subject: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm In-Reply-To: <52CE92B4.4020009@oracle.com> References: <52CBA203.7080706@oracle.com> <52CBA851.8070008@oracle.com> <52CBB7C0.1040002@oracle.com> <52CBC66B.7000003@oracle.com> <52CBD8B7.8050002@oracle.com> <52CBE530.6070105@oracle.com> <52CE7171.1080407@oracle.com> <2BD1713F-655F-429A-9FC0-A14832D32C9D@oracle.com> <52CE8307.6040606@oracle.com> <52CE87A0.90504@oracle.com> <52CE92B4.4020009@oracle.com> Message-ID: <52CF2438.4090604@oracle.com> On 9/01/2014 10:14 PM, Alan Bateman wrote: > On 09/01/2014 11:27, David Holmes wrote: >> >> Okay I think I get it now. Both MonitorTest and WaitersTest use the >> Context class, so if both tests run in the same VM the second test >> will see the static total_turns_taken and "turn" in the state they >> were left from the first test - hence the second test will always >> fail. The bug report suggests making the tests othervm to avoid the >> problem but instead you have changed from using static state to >> instance state so that there is no interference. > I haven't been following this one closely but I thought that jtreg > created a class loader for each test (irrespective of mode) so I > wouldn't expect statics to be an issue. That aside DemoRun forks off its own JVM to run a given test anyway! So I don't understand how the proposed fixes could actually be addressing the hangs that are occurring. Even if the statics were being shared I don't see how that leads to the failure mode in the bug report. David > -Alan. From tristan.yan at oracle.com Thu Jan 9 23:20:03 2014 From: tristan.yan at oracle.com (Tristan Yan) Date: Fri, 10 Jan 2014 07:20:03 +0800 Subject: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm In-Reply-To: <52CF2438.4090604@oracle.com> References: <52CBA203.7080706@oracle.com> <52CBA851.8070008@oracle.com> <52CBB7C0.1040002@oracle.com> <52CBC66B.7000003@oracle.com> <52CBD8B7.8050002@oracle.com> <52CBE530.6070105@oracle.com> <52CE7171.1080407@oracle.com> <2BD1713F-655F-429A-9FC0-A14832D32C9D@oracle.com> <52CE8307.6040606@oracle.com> <52CE87A0.90504@oracle.com> <52CE92B4.4020009@oracle.com> <52CF2438.4090604@oracle.com> Message-ID: <52CF2EA3.9060504@oracle.com> Hi David I wasn't able to reproduce this failure either in local or in our same binaries running(This is a continuous running with same JDK binaries). So intention for this code change is bringing this test back; add some debug info and try to avoid possible issues in this test. I agree this code change won't solve the failure happened. But this test was put into ProblemList two years ago better move for this is move out it from ProblemList and trace down the issue in our normal nightly. Thank you Tristan On 01/10/2014 06:35 AM, David Holmes wrote: > On 9/01/2014 10:14 PM, Alan Bateman wrote: >> On 09/01/2014 11:27, David Holmes wrote: >>> >>> Okay I think I get it now. Both MonitorTest and WaitersTest use the >>> Context class, so if both tests run in the same VM the second test >>> will see the static total_turns_taken and "turn" in the state they >>> were left from the first test - hence the second test will always >>> fail. The bug report suggests making the tests othervm to avoid the >>> problem but instead you have changed from using static state to >>> instance state so that there is no interference. >> I haven't been following this one closely but I thought that jtreg >> created a class loader for each test (irrespective of mode) so I >> wouldn't expect statics to be an issue. > > That aside DemoRun forks off its own JVM to run a given test anyway! > > So I don't understand how the proposed fixes could actually be > addressing the hangs that are occurring. Even if the statics were > being shared I don't see how that leads to the failure mode in the bug > report. > > David > >> -Alan. From srikalyan.chandrashekar at oracle.com Thu Jan 9 23:59:02 2014 From: srikalyan.chandrashekar at oracle.com (srikalyan chandrashekar) Date: Thu, 09 Jan 2014 15:59:02 -0800 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52CE4E2D.300@oracle.com> References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> <52CC72AB.2020104@oracle.com> <52CCEDE0.8000809@oracle.com> <52CCF079.4090301@oracle.com> <52CD45E7.7010203@gmail.com> <52CE4E2D.300@oracle.com> Message-ID: <52CF37C6.1070605@oracle.com> David/Peter you are right, the logs trace came from passed run, i am trying to simulate the failure and get the logs for failed runs(2000+ runs done and still no failure), will get back to you once i have the data from failed run. Sorry for the confusion. --- Thanks kalyan On 01/08/2014 11:22 PM, David Holmes wrote: > Thanks Peter. > > Kalyan: Can you confirm, as Peter asked, that the TraceExceptions > output came from a failed run? > > AFAICS the Trace info is printed after each bytecode where there is a > pending exception - though I'm not 100% sure on the printing within > the VM runtime. Based on that I think we see the Trace output in run() > at the point where wait() returns, so it may well be caught after that > - in which case this was not a failing run. > > I also can't reproduce the problem :( > > David > > On 8/01/2014 10:34 PM, Peter Levart wrote: >> On 01/08/2014 07:30 AM, David Holmes wrote: >>> On 8/01/2014 4:19 PM, David Holmes wrote: >>>> On 8/01/2014 7:33 AM, srikalyan chandrashekar wrote: >>>>> Hi David, TraceExceptions with fastdebug build produced some nice >>>>> trace >>>>> >>>>> . The >>>>> native method wait(long) is where the OOME if being thrown, the >>>>> deepest >>>>> call is in >>>>> >>>>> src/share/vm/gc_interface/collectedHeap.inline.hpp, line 157 >>>> >>>> Yes but it is the caller that is of interest: >>>> >>>> Exception (0x00000000d6a01840) >>>> thrown >>>> [/HUDSON/workspace/8-2-build-linux-amd64/jdk8/1317/hotspot/src/share/vm/runtime/objectMonitor.cpp, >>>> >>>> >>>> line 1649] >>>> for thread 0x00007f78c40d2800 >>>> Exception (0x00000000d6a01840) >>>> thrown in interpreter method <{method} {0x00007f78b4800ae0} 'wait' >>>> '(J)V' in 'java/lang/Object'> >>>> at bci 0 for thread 0x00007f78c40d2800 >>>> >>>> The ReferenceHandler thread gets the OOME trying to allocate the >>>> InterruptedException. >>> >>> However we already have a catch block around the wait() so how is this >>> OOME getting through? A bug in exception handling in the interpreter ?? >>> >> >> Might be. And it may have something to do with the fact that the >> Thread.run() method is the 1st call frame on the thread's stack (seems >> like corner case). The last few meaningful TraceExceptions records are: >> >> >> Exception (0x00000000d6a01840) >> thrown >> [/HUDSON/workspace/8-2-build-linux-amd64/jdk8/1317/hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp, >> >> line 157] >> for thread 0x00007f78c40d2800 >> Exception (0x00000000d6a01840) >> thrown >> [/HUDSON/workspace/8-2-build-linux-amd64/jdk8/1317/hotspot/src/share/vm/runtime/objectMonitor.cpp, >> >> line 1649] >> for thread 0x00007f78c40d2800 >> Exception (0x00000000d6a01840) >> thrown in interpreter method <{method} {0x00007f78b4800ae0} 'wait' >> '(J)V' in 'java/lang/Object'> >> at bci 0 for thread 0x00007f78c40d2800 >> Exception (0x00000000d6a01840) >> thrown in interpreter method <{method} {0x00007f78b4800ca8} 'wait' >> '()V' in 'java/lang/Object'> >> at *bci 2* for thread 0x00007f78c40d2800 >> Exception (0x00000000d6a01840) >> thrown in interpreter method <{method} {0x00007f78b48d2250} 'run' >> '()V' in 'java/lang/ref/Reference$ReferenceHandler'> >> at *bci 36* for thread 0x00007f78c40d2800 >> >> >> Here's the relevant bytecodes: >> >> >> public class java.lang.Object >> >> public final void wait() throws java.lang.InterruptedException; >> descriptor: ()V >> flags: ACC_PUBLIC, ACC_FINAL >> Code: >> stack=3, locals=1, args_size=1 >> 0: aload_0 >> 1: lconst_0 >> * 2: invokevirtual #73 // Method wait:(J)V* >> 5: return >> LineNumberTable: >> line 502: 0 >> line 503: 5 >> Exceptions: >> throws java.lang.InterruptedException >> >> >> class java.lang.ref.Reference$ReferenceHandler extends java.lang.Thread >> >> public void run(); >> descriptor: ()V >> flags: ACC_PUBLIC >> Code: >> stack=2, locals=5, args_size=1 >> 0: invokestatic #62 // Method >> java/lang/ref/Reference.access$100:()Ljava/lang/ref/Reference$Lock; >> 3: dup >> 4: astore_2 >> 5: monitorenter >> 6: invokestatic #61 // Method >> java/lang/ref/Reference.access$200:()Ljava/lang/ref/Reference; >> 9: ifnull 33 >> 12: invokestatic #61 // Method >> java/lang/ref/Reference.access$200:()Ljava/lang/ref/Reference; >> 15: astore_1 >> 16: aload_1 >> 17: invokestatic #64 // Method >> java/lang/ref/Reference.access$300:(Ljava/lang/ref/Reference;)Ljava/lang/ref/Reference; >> >> 20: invokestatic #63 // Method >> java/lang/ref/Reference.access$202:(Ljava/lang/ref/Reference;)Ljava/lang/ref/Reference; >> >> 23: pop >> 24: aload_1 >> 25: aconst_null >> 26: invokestatic #65 // Method >> java/lang/ref/Reference.access$302:(Ljava/lang/ref/Reference;Ljava/lang/ref/Reference;)Ljava/lang/ref/Reference; >> >> 29: pop >> 30: goto 52 >> 33: invokestatic #62 // Method >> java/lang/ref/Reference.access$100:()Ljava/lang/ref/Reference$Lock; >> * 36: invokevirtual #59 // Method >> java/lang/Object.wait:()V* >> 39: goto 43 >> 42: astore_3 >> 43: goto 47 >> 46: astore_3 >> 47: aload_2 >> 48: monitorexit >> 49: goto 0 >> 52: aload_2 >> 53: monitorexit >> 54: goto 64 >> 57: astore 4 >> 59: aload_2 >> 60: monitorexit >> 61: aload 4 >> 63: athrow >> 64: aload_1 >> 65: instanceof #38 // class sun/misc/Cleaner >> 68: ifeq 81 >> 71: aload_1 >> 72: checkcast #38 // class sun/misc/Cleaner >> 75: invokevirtual #67 // Method >> sun/misc/Cleaner.clean:()V >> 78: goto 0 >> 81: aload_1 >> 82: getfield #57 // Field >> java/lang/ref/Reference.queue:Ljava/lang/ref/ReferenceQueue; >> 85: astore_2 >> 86: aload_2 >> 87: getstatic #58 // Field >> java/lang/ref/ReferenceQueue.NULL:Ljava/lang/ref/ReferenceQueue; >> 90: if_acmpeq 99 >> 93: aload_2 >> 94: aload_1 >> 95: invokevirtual #66 // Method >> java/lang/ref/ReferenceQueue.enqueue:(Ljava/lang/ref/Reference;)Z >> 98: pop >> 99: goto 0 >> Exception table: >> from to target type >> * 33 39 42 Class java/lang/OutOfMemoryError* >> 33 43 46 Class java/lang/InterruptedException >> 6 49 57 any >> 52 54 57 any >> 57 61 57 any >> StackMapTable: number_of_entries = 11 >> frame_type = 0 /* same */ >> frame_type = 253 /* append */ >> offset_delta = 32 >> locals = [ top, class java/lang/Object ] >> frame_type = 72 /* same_locals_1_stack_item */ >> stack = [ class java/lang/OutOfMemoryError ] >> frame_type = 0 /* same */ >> frame_type = 66 /* same_locals_1_stack_item */ >> stack = [ class java/lang/InterruptedException ] >> frame_type = 0 /* same */ >> frame_type = 255 /* full_frame */ >> offset_delta = 4 >> locals = [ class java/lang/ref/Reference$ReferenceHandler, >> class java/lang/ref/Reference, class java/lang/Object ] >> stack = [] >> frame_type = 255 /* full_frame */ >> offset_delta = 4 >> locals = [ class java/lang/ref/Reference$ReferenceHandler, >> top, class java/lang/Object ] >> stack = [ class java/lang/Throwable ] >> frame_type = 255 /* full_frame */ >> offset_delta = 6 >> locals = [ class java/lang/ref/Reference$ReferenceHandler, >> class java/lang/ref/Reference ] >> stack = [] >> frame_type = 16 /* same */ >> frame_type = 250 /* chop */ >> offset_delta = 17 >> >> LineNumberTable: >> line 136: 0 >> line 137: 6 >> line 138: 12 >> line 139: 16 >> line 140: 24 >> line 157: 33 >> line 158: 39 >> line 159: 43 >> line 160: 47 >> line 162: 52 >> line 165: 64 >> line 166: 71 >> line 167: 78 >> line 170: 81 >> line 171: 86 >> line 172: 99 >> } >> >> >> ... if I understand correctly the TraceExceptions' output, one record is >> printed for each abruptly completed method. The last record printed >> shows that Object.wait() method completed abruptly by throwing OOME. >> Even if the OOME was caught and ignored, we would still get this >> TraceExceptions record. Am I right? There's no record of abruptly >> terminated ReferenceHandler.run() method in the output. This might be >> because there's no method "calling" the ReferenceHandler.run() method, >> since it is the 1st method on the call-stack. Are you sure the output is >> from a failed test? >> >> Can we make the following adjustment to the ReferenceHandler and see >> what gets printed and/or whether we still get uncaught OOME: >> >> >> private static class ReferenceHandler extends Thread { >> ... >> public void run() { >> runImpl(); >> } >> >> private void runImpl() { >> // ... the content of the original run() method >> } >> ... >> >> >> >> >> Regards, Peter >> >>> David >>> >>>> David >>>> ----- >>>> >>>>> ------------------- Excerpt Begins --------------------- >>>>> >>>>> 147 if (!gc_overhead_limit_was_exceeded) { >>>>> 148 // -XX:+HeapDumpOnOutOfMemoryError and -XX:OnOutOfMemoryError >>>>> support >>>>> 149 report_java_out_of_memory("Java heap space"); >>>>> 150 >>>>> 151 if (JvmtiExport::should_post_resource_exhausted()) { >>>>> 152 JvmtiExport::post_resource_exhausted( >>>>> 153 JVMTI_RESOURCE_EXHAUSTED_OOM_ERROR | >>>>> JVMTI_RESOURCE_EXHAUSTED_JAVA_HEAP, >>>>> 154 "Java heap space"); >>>>> 155 } >>>>> 156 >>>>> 157 THROW_OOP_0(Universe::out_of_memory_error_java_heap()); >>>>> 158 } else { >>>>> >>>>> ------------------- Excerpt Ends --------------------- >>>>> >>>>> >>>>> Would be helpful if David/some one else in the team could explain the >>>>> latent aspects/probable cause. >>>>> >>>>> --- >>>>> Thanks >>>>> kalyan >>>>> >>>>> On 01/06/2014 04:40 PM, David Holmes wrote: >>>>>> Back from vacation ... >>>>>> >>>>>> On 20/12/2013 4:49 PM, David Holmes wrote: >>>>>>> On 20/12/2013 12:57 PM, srikalyan chandrashekar wrote: >>>>>>>> Hi David Thanks for your comments, the unguarded part(clean and >>>>>>>> enqueue) >>>>>>>> in the Reference Handler thread does not seem to create any new >>>>>>>> objects, >>>>>>>> so it is the application(the test in this case) which is adding >>>>>>>> objects >>>>>>>> to heap and causing the Reference Handler to die with OOME. >>>>>>> >>>>>>> The ReferenceHandler thread can only get OOME if it allocates >>>>>>> (directly >>>>>>> or indirectly) - so there has to be something in the unguarded part >>>>>>> that >>>>>>> causes this. Again it may be an implicit action in the VM - >>>>>>> similar to >>>>>>> the class load issue for InterruptedException. >>>>>> >>>>>> Run a debug VM with -XX:+TraceExceptions to see where the OOME is >>>>>> triggered. >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> David >>>>>>> >>>>>>> I am still >>>>>>>> unsure about the side effects of the code change and agree with >>>>>>>> your >>>>>>>> thoughts(on memory exhaustion test's reliability). >>>>>>>> >>>>>>>> PS: hotspot dev alias removed from CC. >>>>>>>> >>>>>>>> -- >>>>>>>> Thanks >>>>>>>> kalyan >>>>>>>> >>>>>>>> On 12/19/13 5:08 PM, David Holmes wrote: >>>>>>>>> Hi Kalyan, >>>>>>>>> >>>>>>>>> This is not a hotspot issue so I'm moving this to core-libs, >>>>>>>>> please >>>>>>>>> drop hotspot from any replies. >>>>>>>>> >>>>>>>>> On 20/12/2013 6:26 AM, srikalyan wrote: >>>>>>>>>> Hi all, I have been working on the bug JDK-8022321 >>>>>>>>>> , this is a >>>>>>>>>> sporadic >>>>>>>>>> failure and the webrev is available here >>>>>>>>>> http://cr.openjdk.java.net/~srikchan/Regression/JDK-8022321_OOMEInReferenceHandler-webrev/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> I'm really not sure what to make of this. We have a test that >>>>>>>>> triggers >>>>>>>>> an out-of-memory condition but the OOME can actually turn up >>>>>>>>> in the >>>>>>>>> ReferenceHandler thread causing it to terminate and the test to >>>>>>>>> fail. >>>>>>>>> We previously accounted for the non-obvious occurrences of OOME >>>>>>>>> due to >>>>>>>>> the Object.wait and the possible need to load the >>>>>>>>> InterruptedException >>>>>>>>> class - but still the OOME can appear where we don't want it. So >>>>>>>>> finally you have just placed the whole for(;;) loop in a >>>>>>>>> try/catch(OOME) that ignores the OOME. I'm certain that makes the >>>>>>>>> test >>>>>>>>> happy, but I'm not sure it is really what we want for the >>>>>>>>> ReferenceHandler thread. If the OOME occurs while cleaning, or >>>>>>>>> enqueuing then we will fail to clean and/or enqueue but there >>>>>>>>> would be >>>>>>>>> no indication that has occurred and I think that is a bigger >>>>>>>>> problem >>>>>>>>> than this test failing. >>>>>>>>> >>>>>>>>> There may be no way to make this test 100% reliable. In fact I'd >>>>>>>>> suggest that no memory exhaustion test can be 100% reliable. >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>>> * >>>>>>>>>> **"Root Cause:Still not known"* >>>>>>>>>> 2 places where there is a possibility for OOME >>>>>>>>>> 1) Cleaner.clean() >>>>>>>>>> 2) ReferenceQueue.enqueue() >>>>>>>>>> >>>>>>>>>> 1) The cleanup code in turn has 2 places where there is >>>>>>>>>> potential >>>>>>>>>> for >>>>>>>>>> throwing OOME, >>>>>>>>>> a) thunk Thread which is run from clean() method. This >>>>>>>>>> Runnable is >>>>>>>>>> passed to Cleaner and appears in the following classes >>>>>>>>>> java/nio/DirectByteBuffer.java >>>>>>>>>> sun/misc/Perf.java >>>>>>>>>> sun/nio/fs/NativeBuffer.java >>>>>>>>>> sun/nio/ch/IOVecWrapper.java >>>>>>>>>> sun/misc/Cleaner/ExitOnThrow.java >>>>>>>>>> However none of the above overridden implementations ever >>>>>>>>>> create an >>>>>>>>>> object in the clean() code. >>>>>>>>>> b) new PrivilegedAction created in try catch Exception >>>>>>>>>> block of >>>>>>>>>> clean() method but for this object to be created and to be held >>>>>>>>>> responsible for OOME an Exception(other than OOME) has to be >>>>>>>>>> thrown. >>>>>>>>>> >>>>>>>>>> 2) No new heap objects are created in the enqueue method nor >>>>>>>>>> anywhere in >>>>>>>>>> the deep call stack (VM.addFinalRefCount() etc) so this cannot >>>>>>>>>> be a >>>>>>>>>> potential cause. >>>>>>>>>> >>>>>>>>>> *Experimental change to java.lang.Reference.java* : >>>>>>>>>> - Put one more guard (try catch with OOME block) in the >>>>>>>>>> Reference >>>>>>>>>> Handler Thread which may give the Reference Handler a chance to >>>>>>>>>> cleanup. >>>>>>>>>> This is fixing the test failure (several 1000 runs with 0 >>>>>>>>>> failures) >>>>>>>>>> - Without the above change the test fails atleast 3-5 times for >>>>>>>>>> every >>>>>>>>>> 1000 run. >>>>>>>>>> >>>>>>>>>> *PS*: The code change is to a very critical part of JDK and i am >>>>>>>>>> fully >>>>>>>>>> not aware of the consequences of the change, hence seeking >>>>>>>>>> expert >>>>>>>>>> help >>>>>>>>>> here. Appreciate your time and inputs towards this. >>>>>>>>>> >>>>>>>> >>>>> >> From dan.xu at oracle.com Fri Jan 10 06:31:30 2014 From: dan.xu at oracle.com (Dan Xu) Date: Thu, 09 Jan 2014 22:31:30 -0800 Subject: RFR: JDK-8029007, Check src/share/native/sun/misc code for JNI pending exceptions Message-ID: <52CF93C2.3080602@oracle.com> Hi All, Please review the fix for JNI pending exception issues reported in jdk-8029007. Thanks! Webrev: http://cr.openjdk.java.net/~dxu/8029007/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8029007 -Dan From chris.hegarty at oracle.com Fri Jan 10 07:49:31 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 10 Jan 2014 07:49:31 +0000 Subject: RFR: JDK-8029007, Check src/share/native/sun/misc code for JNI pending exceptions In-Reply-To: <52CF93C2.3080602@oracle.com> References: <52CF93C2.3080602@oracle.com> Message-ID: <91A54394-A96C-42BF-8569-7B9E16AA93DE@oracle.com> Looks ok to me. I presume getThreadStateValues is simply no longer needed. -Chris. > On 10 Jan 2014, at 06:31, Dan Xu wrote: > > Hi All, > > Please review the fix for JNI pending exception issues reported in jdk-8029007. Thanks! > > Webrev: http://cr.openjdk.java.net/~dxu/8029007/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8029007 > > -Dan From peter.levart at gmail.com Fri Jan 10 08:31:39 2014 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 10 Jan 2014 09:31:39 +0100 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52CF37C6.1070605@oracle.com> References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> <52CC72AB.2020104@oracle.com> <52CCEDE0.8000809@oracle.com> <52CCF079.4090301@oracle.com> <52CD45E7.7010203@gmail.com> <52CE4E2D.300@oracle.com> <52CF37C6.1070605@oracle.com> Message-ID: <52CFAFEB.9090703@gmail.com> On 01/10/2014 12:59 AM, srikalyan chandrashekar wrote: > David/Peter you are right, the logs trace came from passed run, i am > trying to simulate the failure and get the logs for failed runs(2000+ > runs done and still no failure), will get back to you once i have the > data from failed run. Sorry for the confusion. I doubt the logs will be any different. A simple test that throws an exception inside Thread.run() without catching it shows that TraceExceptions doesn't report the fact that Thread.run() terminates abruptly (as David pointed out, pending exception is reported after every bytecode executed and there's no bytecode that invoked Thread.run()). While you're at it, testing, could you also test the modified ReferenceHandler (the one that calls private runImpl() from it's run() method) so that we get a proof of incorrect behaviour. Since we suspect there's something wrong with exception handling in interpreter, I devised a hypothetical reproducer that tries to simulate ReferenceHandler in many aspects, but doesn't require to be a ReferenceHandler: http://cr.openjdk.java.net/~plevart/misc/OOME/OOMECatchingTest.java This is designed to run indefinitely and only terminate if/when thread dies. Could you run this program in the environment that causes the OOMEInReferenceHandler test to fail and see if it terminates? Regards, Peter > > --- > Thanks > kalyan > > On 01/08/2014 11:22 PM, David Holmes wrote: >> Thanks Peter. >> >> Kalyan: Can you confirm, as Peter asked, that the TraceExceptions >> output came from a failed run? >> >> AFAICS the Trace info is printed after each bytecode where there is a >> pending exception - though I'm not 100% sure on the printing within >> the VM runtime. Based on that I think we see the Trace output in >> run() at the point where wait() returns, so it may well be caught >> after that - in which case this was not a failing run. >> >> I also can't reproduce the problem :( >> >> David >> >> On 8/01/2014 10:34 PM, Peter Levart wrote: >>> On 01/08/2014 07:30 AM, David Holmes wrote: >>>> On 8/01/2014 4:19 PM, David Holmes wrote: >>>>> On 8/01/2014 7:33 AM, srikalyan chandrashekar wrote: >>>>>> Hi David, TraceExceptions with fastdebug build produced some nice >>>>>> trace >>>>>> >>>>>> . The >>>>>> native method wait(long) is where the OOME if being thrown, the >>>>>> deepest >>>>>> call is in >>>>>> >>>>>> src/share/vm/gc_interface/collectedHeap.inline.hpp, line 157 >>>>> >>>>> Yes but it is the caller that is of interest: >>>>> >>>>> Exception (0x00000000d6a01840) >>>>> thrown >>>>> [/HUDSON/workspace/8-2-build-linux-amd64/jdk8/1317/hotspot/src/share/vm/runtime/objectMonitor.cpp, >>>>> >>>>> >>>>> line 1649] >>>>> for thread 0x00007f78c40d2800 >>>>> Exception (0x00000000d6a01840) >>>>> thrown in interpreter method <{method} {0x00007f78b4800ae0} 'wait' >>>>> '(J)V' in 'java/lang/Object'> >>>>> at bci 0 for thread 0x00007f78c40d2800 >>>>> >>>>> The ReferenceHandler thread gets the OOME trying to allocate the >>>>> InterruptedException. >>>> >>>> However we already have a catch block around the wait() so how is this >>>> OOME getting through? A bug in exception handling in the >>>> interpreter ?? >>>> >>> >>> Might be. And it may have something to do with the fact that the >>> Thread.run() method is the 1st call frame on the thread's stack (seems >>> like corner case). The last few meaningful TraceExceptions records are: >>> >>> >>> Exception (0x00000000d6a01840) >>> thrown >>> [/HUDSON/workspace/8-2-build-linux-amd64/jdk8/1317/hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp, >>> >>> line 157] >>> for thread 0x00007f78c40d2800 >>> Exception (0x00000000d6a01840) >>> thrown >>> [/HUDSON/workspace/8-2-build-linux-amd64/jdk8/1317/hotspot/src/share/vm/runtime/objectMonitor.cpp, >>> >>> line 1649] >>> for thread 0x00007f78c40d2800 >>> Exception (0x00000000d6a01840) >>> thrown in interpreter method <{method} {0x00007f78b4800ae0} 'wait' >>> '(J)V' in 'java/lang/Object'> >>> at bci 0 for thread 0x00007f78c40d2800 >>> Exception (0x00000000d6a01840) >>> thrown in interpreter method <{method} {0x00007f78b4800ca8} 'wait' >>> '()V' in 'java/lang/Object'> >>> at *bci 2* for thread 0x00007f78c40d2800 >>> Exception (0x00000000d6a01840) >>> thrown in interpreter method <{method} {0x00007f78b48d2250} 'run' >>> '()V' in 'java/lang/ref/Reference$ReferenceHandler'> >>> at *bci 36* for thread 0x00007f78c40d2800 >>> >>> >>> Here's the relevant bytecodes: >>> >>> >>> public class java.lang.Object >>> >>> public final void wait() throws java.lang.InterruptedException; >>> descriptor: ()V >>> flags: ACC_PUBLIC, ACC_FINAL >>> Code: >>> stack=3, locals=1, args_size=1 >>> 0: aload_0 >>> 1: lconst_0 >>> * 2: invokevirtual #73 // Method wait:(J)V* >>> 5: return >>> LineNumberTable: >>> line 502: 0 >>> line 503: 5 >>> Exceptions: >>> throws java.lang.InterruptedException >>> >>> >>> class java.lang.ref.Reference$ReferenceHandler extends java.lang.Thread >>> >>> public void run(); >>> descriptor: ()V >>> flags: ACC_PUBLIC >>> Code: >>> stack=2, locals=5, args_size=1 >>> 0: invokestatic #62 // Method >>> java/lang/ref/Reference.access$100:()Ljava/lang/ref/Reference$Lock; >>> 3: dup >>> 4: astore_2 >>> 5: monitorenter >>> 6: invokestatic #61 // Method >>> java/lang/ref/Reference.access$200:()Ljava/lang/ref/Reference; >>> 9: ifnull 33 >>> 12: invokestatic #61 // Method >>> java/lang/ref/Reference.access$200:()Ljava/lang/ref/Reference; >>> 15: astore_1 >>> 16: aload_1 >>> 17: invokestatic #64 // Method >>> java/lang/ref/Reference.access$300:(Ljava/lang/ref/Reference;)Ljava/lang/ref/Reference; >>> >>> 20: invokestatic #63 // Method >>> java/lang/ref/Reference.access$202:(Ljava/lang/ref/Reference;)Ljava/lang/ref/Reference; >>> >>> 23: pop >>> 24: aload_1 >>> 25: aconst_null >>> 26: invokestatic #65 // Method >>> java/lang/ref/Reference.access$302:(Ljava/lang/ref/Reference;Ljava/lang/ref/Reference;)Ljava/lang/ref/Reference; >>> >>> 29: pop >>> 30: goto 52 >>> 33: invokestatic #62 // Method >>> java/lang/ref/Reference.access$100:()Ljava/lang/ref/Reference$Lock; >>> * 36: invokevirtual #59 // Method >>> java/lang/Object.wait:()V* >>> 39: goto 43 >>> 42: astore_3 >>> 43: goto 47 >>> 46: astore_3 >>> 47: aload_2 >>> 48: monitorexit >>> 49: goto 0 >>> 52: aload_2 >>> 53: monitorexit >>> 54: goto 64 >>> 57: astore 4 >>> 59: aload_2 >>> 60: monitorexit >>> 61: aload 4 >>> 63: athrow >>> 64: aload_1 >>> 65: instanceof #38 // class >>> sun/misc/Cleaner >>> 68: ifeq 81 >>> 71: aload_1 >>> 72: checkcast #38 // class >>> sun/misc/Cleaner >>> 75: invokevirtual #67 // Method >>> sun/misc/Cleaner.clean:()V >>> 78: goto 0 >>> 81: aload_1 >>> 82: getfield #57 // Field >>> java/lang/ref/Reference.queue:Ljava/lang/ref/ReferenceQueue; >>> 85: astore_2 >>> 86: aload_2 >>> 87: getstatic #58 // Field >>> java/lang/ref/ReferenceQueue.NULL:Ljava/lang/ref/ReferenceQueue; >>> 90: if_acmpeq 99 >>> 93: aload_2 >>> 94: aload_1 >>> 95: invokevirtual #66 // Method >>> java/lang/ref/ReferenceQueue.enqueue:(Ljava/lang/ref/Reference;)Z >>> 98: pop >>> 99: goto 0 >>> Exception table: >>> from to target type >>> * 33 39 42 Class java/lang/OutOfMemoryError* >>> 33 43 46 Class java/lang/InterruptedException >>> 6 49 57 any >>> 52 54 57 any >>> 57 61 57 any >>> StackMapTable: number_of_entries = 11 >>> frame_type = 0 /* same */ >>> frame_type = 253 /* append */ >>> offset_delta = 32 >>> locals = [ top, class java/lang/Object ] >>> frame_type = 72 /* same_locals_1_stack_item */ >>> stack = [ class java/lang/OutOfMemoryError ] >>> frame_type = 0 /* same */ >>> frame_type = 66 /* same_locals_1_stack_item */ >>> stack = [ class java/lang/InterruptedException ] >>> frame_type = 0 /* same */ >>> frame_type = 255 /* full_frame */ >>> offset_delta = 4 >>> locals = [ class java/lang/ref/Reference$ReferenceHandler, >>> class java/lang/ref/Reference, class java/lang/Object ] >>> stack = [] >>> frame_type = 255 /* full_frame */ >>> offset_delta = 4 >>> locals = [ class java/lang/ref/Reference$ReferenceHandler, >>> top, class java/lang/Object ] >>> stack = [ class java/lang/Throwable ] >>> frame_type = 255 /* full_frame */ >>> offset_delta = 6 >>> locals = [ class java/lang/ref/Reference$ReferenceHandler, >>> class java/lang/ref/Reference ] >>> stack = [] >>> frame_type = 16 /* same */ >>> frame_type = 250 /* chop */ >>> offset_delta = 17 >>> >>> LineNumberTable: >>> line 136: 0 >>> line 137: 6 >>> line 138: 12 >>> line 139: 16 >>> line 140: 24 >>> line 157: 33 >>> line 158: 39 >>> line 159: 43 >>> line 160: 47 >>> line 162: 52 >>> line 165: 64 >>> line 166: 71 >>> line 167: 78 >>> line 170: 81 >>> line 171: 86 >>> line 172: 99 >>> } >>> >>> >>> ... if I understand correctly the TraceExceptions' output, one >>> record is >>> printed for each abruptly completed method. The last record printed >>> shows that Object.wait() method completed abruptly by throwing OOME. >>> Even if the OOME was caught and ignored, we would still get this >>> TraceExceptions record. Am I right? There's no record of abruptly >>> terminated ReferenceHandler.run() method in the output. This might be >>> because there's no method "calling" the ReferenceHandler.run() method, >>> since it is the 1st method on the call-stack. Are you sure the >>> output is >>> from a failed test? >>> >>> Can we make the following adjustment to the ReferenceHandler and see >>> what gets printed and/or whether we still get uncaught OOME: >>> >>> >>> private static class ReferenceHandler extends Thread { >>> ... >>> public void run() { >>> runImpl(); >>> } >>> >>> private void runImpl() { >>> // ... the content of the original run() method >>> } >>> ... >>> >>> >>> >>> >>> Regards, Peter >>> >>>> David >>>> >>>>> David >>>>> ----- >>>>> >>>>>> ------------------- Excerpt Begins --------------------- >>>>>> >>>>>> 147 if (!gc_overhead_limit_was_exceeded) { >>>>>> 148 // -XX:+HeapDumpOnOutOfMemoryError and -XX:OnOutOfMemoryError >>>>>> support >>>>>> 149 report_java_out_of_memory("Java heap space"); >>>>>> 150 >>>>>> 151 if (JvmtiExport::should_post_resource_exhausted()) { >>>>>> 152 JvmtiExport::post_resource_exhausted( >>>>>> 153 JVMTI_RESOURCE_EXHAUSTED_OOM_ERROR | >>>>>> JVMTI_RESOURCE_EXHAUSTED_JAVA_HEAP, >>>>>> 154 "Java heap space"); >>>>>> 155 } >>>>>> 156 >>>>>> 157 THROW_OOP_0(Universe::out_of_memory_error_java_heap()); >>>>>> 158 } else { >>>>>> >>>>>> ------------------- Excerpt Ends --------------------- >>>>>> >>>>>> >>>>>> Would be helpful if David/some one else in the team could explain >>>>>> the >>>>>> latent aspects/probable cause. >>>>>> >>>>>> --- >>>>>> Thanks >>>>>> kalyan >>>>>> >>>>>> On 01/06/2014 04:40 PM, David Holmes wrote: >>>>>>> Back from vacation ... >>>>>>> >>>>>>> On 20/12/2013 4:49 PM, David Holmes wrote: >>>>>>>> On 20/12/2013 12:57 PM, srikalyan chandrashekar wrote: >>>>>>>>> Hi David Thanks for your comments, the unguarded part(clean and >>>>>>>>> enqueue) >>>>>>>>> in the Reference Handler thread does not seem to create any new >>>>>>>>> objects, >>>>>>>>> so it is the application(the test in this case) which is adding >>>>>>>>> objects >>>>>>>>> to heap and causing the Reference Handler to die with OOME. >>>>>>>> >>>>>>>> The ReferenceHandler thread can only get OOME if it allocates >>>>>>>> (directly >>>>>>>> or indirectly) - so there has to be something in the unguarded >>>>>>>> part >>>>>>>> that >>>>>>>> causes this. Again it may be an implicit action in the VM - >>>>>>>> similar to >>>>>>>> the class load issue for InterruptedException. >>>>>>> >>>>>>> Run a debug VM with -XX:+TraceExceptions to see where the OOME is >>>>>>> triggered. >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> I am still >>>>>>>>> unsure about the side effects of the code change and agree >>>>>>>>> with your >>>>>>>>> thoughts(on memory exhaustion test's reliability). >>>>>>>>> >>>>>>>>> PS: hotspot dev alias removed from CC. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Thanks >>>>>>>>> kalyan >>>>>>>>> >>>>>>>>> On 12/19/13 5:08 PM, David Holmes wrote: >>>>>>>>>> Hi Kalyan, >>>>>>>>>> >>>>>>>>>> This is not a hotspot issue so I'm moving this to core-libs, >>>>>>>>>> please >>>>>>>>>> drop hotspot from any replies. >>>>>>>>>> >>>>>>>>>> On 20/12/2013 6:26 AM, srikalyan wrote: >>>>>>>>>>> Hi all, I have been working on the bug JDK-8022321 >>>>>>>>>>> , this is a >>>>>>>>>>> sporadic >>>>>>>>>>> failure and the webrev is available here >>>>>>>>>>> http://cr.openjdk.java.net/~srikchan/Regression/JDK-8022321_OOMEInReferenceHandler-webrev/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I'm really not sure what to make of this. We have a test that >>>>>>>>>> triggers >>>>>>>>>> an out-of-memory condition but the OOME can actually turn up >>>>>>>>>> in the >>>>>>>>>> ReferenceHandler thread causing it to terminate and the test to >>>>>>>>>> fail. >>>>>>>>>> We previously accounted for the non-obvious occurrences of OOME >>>>>>>>>> due to >>>>>>>>>> the Object.wait and the possible need to load the >>>>>>>>>> InterruptedException >>>>>>>>>> class - but still the OOME can appear where we don't want it. So >>>>>>>>>> finally you have just placed the whole for(;;) loop in a >>>>>>>>>> try/catch(OOME) that ignores the OOME. I'm certain that makes >>>>>>>>>> the >>>>>>>>>> test >>>>>>>>>> happy, but I'm not sure it is really what we want for the >>>>>>>>>> ReferenceHandler thread. If the OOME occurs while cleaning, or >>>>>>>>>> enqueuing then we will fail to clean and/or enqueue but there >>>>>>>>>> would be >>>>>>>>>> no indication that has occurred and I think that is a bigger >>>>>>>>>> problem >>>>>>>>>> than this test failing. >>>>>>>>>> >>>>>>>>>> There may be no way to make this test 100% reliable. In fact I'd >>>>>>>>>> suggest that no memory exhaustion test can be 100% reliable. >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> * >>>>>>>>>>> **"Root Cause:Still not known"* >>>>>>>>>>> 2 places where there is a possibility for OOME >>>>>>>>>>> 1) Cleaner.clean() >>>>>>>>>>> 2) ReferenceQueue.enqueue() >>>>>>>>>>> >>>>>>>>>>> 1) The cleanup code in turn has 2 places where there is >>>>>>>>>>> potential >>>>>>>>>>> for >>>>>>>>>>> throwing OOME, >>>>>>>>>>> a) thunk Thread which is run from clean() method. This >>>>>>>>>>> Runnable is >>>>>>>>>>> passed to Cleaner and appears in the following classes >>>>>>>>>>> java/nio/DirectByteBuffer.java >>>>>>>>>>> sun/misc/Perf.java >>>>>>>>>>> sun/nio/fs/NativeBuffer.java >>>>>>>>>>> sun/nio/ch/IOVecWrapper.java >>>>>>>>>>> sun/misc/Cleaner/ExitOnThrow.java >>>>>>>>>>> However none of the above overridden implementations ever >>>>>>>>>>> create an >>>>>>>>>>> object in the clean() code. >>>>>>>>>>> b) new PrivilegedAction created in try catch Exception >>>>>>>>>>> block of >>>>>>>>>>> clean() method but for this object to be created and to be held >>>>>>>>>>> responsible for OOME an Exception(other than OOME) has to be >>>>>>>>>>> thrown. >>>>>>>>>>> >>>>>>>>>>> 2) No new heap objects are created in the enqueue method nor >>>>>>>>>>> anywhere in >>>>>>>>>>> the deep call stack (VM.addFinalRefCount() etc) so this cannot >>>>>>>>>>> be a >>>>>>>>>>> potential cause. >>>>>>>>>>> >>>>>>>>>>> *Experimental change to java.lang.Reference.java* : >>>>>>>>>>> - Put one more guard (try catch with OOME block) in the >>>>>>>>>>> Reference >>>>>>>>>>> Handler Thread which may give the Reference Handler a chance to >>>>>>>>>>> cleanup. >>>>>>>>>>> This is fixing the test failure (several 1000 runs with 0 >>>>>>>>>>> failures) >>>>>>>>>>> - Without the above change the test fails atleast 3-5 times for >>>>>>>>>>> every >>>>>>>>>>> 1000 run. >>>>>>>>>>> >>>>>>>>>>> *PS*: The code change is to a very critical part of JDK and >>>>>>>>>>> i am >>>>>>>>>>> fully >>>>>>>>>>> not aware of the consequences of the change, hence seeking >>>>>>>>>>> expert >>>>>>>>>>> help >>>>>>>>>>> here. Appreciate your time and inputs towards this. >>>>>>>>>>> >>>>>>>>> >>>>>> >>> > From Alan.Bateman at oracle.com Fri Jan 10 08:34:18 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 10 Jan 2014 08:34:18 +0000 Subject: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm In-Reply-To: <52CF2EA3.9060504@oracle.com> References: <52CBA203.7080706@oracle.com> <52CBA851.8070008@oracle.com> <52CBB7C0.1040002@oracle.com> <52CBC66B.7000003@oracle.com> <52CBD8B7.8050002@oracle.com> <52CBE530.6070105@oracle.com> <52CE7171.1080407@oracle.com> <2BD1713F-655F-429A-9FC0-A14832D32C9D@oracle.com> <52CE8307.6040606@oracle.com> <52CE87A0.90504@oracle.com> <52CE92B4.4020009@oracle.com> <52CF2438.4090604@oracle.com> <52CF2EA3.9060504@oracle.com> Message-ID: <52CFB08A.5040400@oracle.com> On 09/01/2014 23:20, Tristan Yan wrote: > Hi David > I wasn't able to reproduce this failure either in local or in our same > binaries running(This is a continuous running with same JDK binaries). > So intention for this code change is bringing this test back; add > some debug info and try to avoid possible issues in this test. I agree > this code change won't solve the failure happened. But this test was > put into ProblemList two years ago better move for this is move out it > from ProblemList and trace down the issue in our normal nightly. If we can't duplicate it now, and the output from previously reported failures (in 2011) is insufficient to diagnose it properly, then it seems reasonable to add better output so as to improve our chances of understanding if it fails again. So better output + removing from the exclude list seems fine here. (cc'ing serviceability-dev as that is actually the mailing list for the HPROF and JVM TI areas). -Alan From staffan.larsen at oracle.com Fri Jan 10 08:40:17 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 10 Jan 2014 09:40:17 +0100 Subject: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm In-Reply-To: <52CFB08A.5040400@oracle.com> References: <52CBA203.7080706@oracle.com> <52CBA851.8070008@oracle.com> <52CBB7C0.1040002@oracle.com> <52CBC66B.7000003@oracle.com> <52CBD8B7.8050002@oracle.com> <52CBE530.6070105@oracle.com> <52CE7171.1080407@oracle.com> <2BD1713F-655F-429A-9FC0-A14832D32C9D@oracle.com> <52CE8307.6040606@oracle.com> <52CE87A0.90504@oracle.com> <52CE92B4.4020009@oracle.com> <52CF2438.4090604@oracle.com> <52CF2EA3.9060504@oracle.com> <52CFB08A.5040400@oracle.com> Message-ID: <2637E9FC-1CE2-4774-AD41-E760BAAFB30C@oracle.com> On 10 jan 2014, at 09:34, Alan Bateman wrote: > On 09/01/2014 23:20, Tristan Yan wrote: >> Hi David >> I wasn't able to reproduce this failure either in local or in our same binaries running(This is a continuous running with same JDK binaries). So intention for this code change is bringing this test back; add some debug info and try to avoid possible issues in this test. I agree this code change won't solve the failure happened. But this test was put into ProblemList two years ago better move for this is move out it from ProblemList and trace down the issue in our normal nightly. > If we can't duplicate it now, and the output from previously reported failures (in 2011) is insufficient to diagnose it properly, then it seems reasonable to add better output so as to improve our chances of understanding if it fails again. So better output + removing from the exclude list seems fine here. (cc'ing serviceability-dev as that is actually the mailing list for the HPROF and JVM TI areas). Sounds good to me, /Staffan > > -Alan From paul.sandoz at oracle.com Fri Jan 10 10:01:17 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 10 Jan 2014 11:01:17 +0100 Subject: RFR 8031428 CountTest causes lambda Ser/Derialization tests to fail Message-ID: Hi, A small tweak is required to a recent Stream-based test i added to stop some internal lambda-based ser/derialization (SAND) tests barfing since the test is hostile to ser/derialization, and infact i should have probably written the test like below in the first place. Kumar has verified it fixes the SAND test failures. Paul. https://bugs.openjdk.java.net/browse/JDK-8031428 diff -r e332a6819993 test/java/util/stream/test/org/openjdk/tests/java/util/stream/CountTest.java --- a/test/java/util/stream/test/org/openjdk/tests/java/util/stream/CountTest.java Fri Jan 10 08:22:00 2014 +0100 +++ b/test/java/util/stream/test/org/openjdk/tests/java/util/stream/CountTest.java Fri Jan 10 10:58:06 2014 +0100 @@ -29,7 +29,6 @@ package org.openjdk.tests.java.util.stream; -import java.util.concurrent.atomic.AtomicLong; import java.util.stream.DoubleStream; import java.util.stream.DoubleStreamTestDataProvider; import java.util.stream.IntStream; @@ -47,45 +46,41 @@ @Test(dataProvider = "StreamTestData", dataProviderClass = StreamTestDataProvider.class) public void testOps(String name, TestData.OfRef data) { - AtomicLong expectedCount = new AtomicLong(); - data.stream().forEach(e -> expectedCount.incrementAndGet()); + long expectedCount = data.size(); withData(data). terminal(Stream::count). - expectedResult(expectedCount.get()). + expectedResult(expectedCount). exercise(); } @Test(dataProvider = "IntStreamTestData", dataProviderClass = IntStreamTestDataProvider.class) public void testOps(String name, TestData.OfInt data) { - AtomicLong expectedCount = new AtomicLong(); - data.stream().forEach(e -> expectedCount.incrementAndGet()); + long expectedCount = data.size(); withData(data). terminal(IntStream::count). - expectedResult(expectedCount.get()). + expectedResult(expectedCount). exercise(); } @Test(dataProvider = "LongStreamTestData", dataProviderClass = LongStreamTestDataProvider.class) public void testOps(String name, TestData.OfLong data) { - AtomicLong expectedCount = new AtomicLong(); - data.stream().forEach(e -> expectedCount.incrementAndGet()); + long expectedCount = data.size(); withData(data). terminal(LongStream::count). - expectedResult(expectedCount.get()). + expectedResult(expectedCount). exercise(); } @Test(dataProvider = "DoubleStreamTestData", dataProviderClass = DoubleStreamTestDataProvider.class) public void testOps(String name, TestData.OfDouble data) { - AtomicLong expectedCount = new AtomicLong(); - data.stream().forEach(e -> expectedCount.incrementAndGet()); + long expectedCount = data.size(); withData(data). terminal(DoubleStream::count). - expectedResult(expectedCount.get()). + expectedResult(expectedCount). exercise(); } } From Alan.Bateman at oracle.com Fri Jan 10 10:32:44 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 10 Jan 2014 10:32:44 +0000 Subject: RFR: JDK-8029007, Check src/share/native/sun/misc code for JNI pending exceptions In-Reply-To: <52CF93C2.3080602@oracle.com> References: <52CF93C2.3080602@oracle.com> Message-ID: <52CFCC4C.6090600@oracle.com> On 10/01/2014 06:31, Dan Xu wrote: > Hi All, > > Please review the fix for JNI pending exception issues reported in > jdk-8029007. Thanks! > > Webrev: http://cr.openjdk.java.net/~dxu/8029007/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8029007 This looks good, the only one that isn't clear (to me) is the GetStringLength usage in MessageUtil.c where I don't think it is possible to ever get < 0. This may be a case where you need to use ExceptionOccured instead. -Alan. From david.holmes at oracle.com Fri Jan 10 10:37:21 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 10 Jan 2014 20:37:21 +1000 Subject: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm In-Reply-To: <2637E9FC-1CE2-4774-AD41-E760BAAFB30C@oracle.com> References: <52CBA203.7080706@oracle.com> <52CBA851.8070008@oracle.com> <52CBB7C0.1040002@oracle.com> <52CBC66B.7000003@oracle.com> <52CBD8B7.8050002@oracle.com> <52CBE530.6070105@oracle.com> <52CE7171.1080407@oracle.com> <2BD1713F-655F-429A-9FC0-A14832D32C9D@oracle.com> <52CE8307.6040606@oracle.com> <52CE87A0.90504@oracle.com> <52CE92B4.4020009@oracle.com> <52CF2438.4090604@oracle.com> <52CF2EA3.9060504@oracle.com> <52CFB08A.5040400@oracle.com> <2637E9FC-1CE2-4774-AD41-E760BAAFB30C@oracle.com> Message-ID: <52CFCD61.5070907@oracle.com> On 10/01/2014 6:40 PM, Staffan Larsen wrote: > > On 10 jan 2014, at 09:34, Alan Bateman wrote: > >> On 09/01/2014 23:20, Tristan Yan wrote: >>> Hi David >>> I wasn't able to reproduce this failure either in local or in our same binaries running(This is a continuous running with same JDK binaries). So intention for this code change is bringing this test back; add some debug info and try to avoid possible issues in this test. I agree this code change won't solve the failure happened. But this test was put into ProblemList two years ago better move for this is move out it from ProblemList and trace down the issue in our normal nightly. >> If we can't duplicate it now, and the output from previously reported failures (in 2011) is insufficient to diagnose it properly, then it seems reasonable to add better output so as to improve our chances of understanding if it fails again. So better output + removing from the exclude list seems fine here. (cc'ing serviceability-dev as that is actually the mailing list for the HPROF and JVM TI areas). > > Sounds good to me, I'm not sure what is actually being proposed. I don't really see anything that would help diagnoze the original issue. But bring back the test - maybe this was a bug elsewhere that has now been fixed. David > /Staffan > >> >> -Alan > From Alan.Bateman at oracle.com Fri Jan 10 10:43:00 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 10 Jan 2014 10:43:00 +0000 Subject: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm In-Reply-To: <52CFCD61.5070907@oracle.com> References: <52CBA203.7080706@oracle.com> <52CBA851.8070008@oracle.com> <52CBB7C0.1040002@oracle.com> <52CBC66B.7000003@oracle.com> <52CBD8B7.8050002@oracle.com> <52CBE530.6070105@oracle.com> <52CE7171.1080407@oracle.com> <2BD1713F-655F-429A-9FC0-A14832D32C9D@oracle.com> <52CE8307.6040606@oracle.com> <52CE87A0.90504@oracle.com> <52CE92B4.4020009@oracle.com> <52CF2438.4090604@oracle.com> <52CF2EA3.9060504@oracle.com> <52CFB08A.5040400@oracle.com> <2637E9FC-1CE2-4774-AD41-E760BAAFB30C@oracle.com> <52CFCD61.5070907@oracle.com> Message-ID: <52CFCEB4.7080603@oracle.com> On 10/01/2014 10:37, David Holmes wrote: > > I'm not sure what is actually being proposed. I don't really see > anything that would help diagnoze the original issue. But bring back > the test - maybe this was a bug elsewhere that has now been fixed. I think the proposal is as we said, more diagnostic output + remove from exclude list. If Tristan's agrees then I'm sure he'll update the patch. On your second point then you may be right, there were a number of issues during JDK 8 and it's very possible that the ghost being chasing now is gone. -Alan. From peter.levart at gmail.com Fri Jan 10 10:57:28 2014 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 10 Jan 2014 11:57:28 +0100 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52CFAFEB.9090703@gmail.com> References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> <52CC72AB.2020104@oracle.com> <52CCEDE0.8000809@oracle.com> <52CCF079.4090301@oracle.com> <52CD45E7.7010203@gmail.com> <52CE4E2D.300@oracle.com> <52CF37C6.1070605@oracle.com> <52CFAFEB.9090703@gmail.com> Message-ID: <52CFD218.2060101@gmail.com> On 01/10/2014 09:31 AM, Peter Levart wrote: > Since we suspect there's something wrong with exception handling in > interpreter, I devised a hypothetical reproducer that tries to > simulate ReferenceHandler in many aspects, but doesn't require to be a > ReferenceHandler: > > http://cr.openjdk.java.net/~plevart/misc/OOME/OOMECatchingTest.java > > This is designed to run indefinitely and only terminate if/when thread > dies. Could you run this program in the environment that causes the > OOMEInReferenceHandler test to fail and see if it terminates? I forgot to mention that in order for this long-running program to exhibit interpreter behaviour, it should be run with -Xint option. So I suggest: -Xmx24M -XX:-UseTLAB -Xint Regards, Peter From paul.sandoz at oracle.com Fri Jan 10 11:21:45 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 10 Jan 2014 12:21:45 +0100 Subject: RFR 8030848: Collections.sort(List l, Comparator) should defer to List.sort(Comparator ) Message-ID: Hi, When we added the List.sort method the default implementation deferred to Collections.sort. This is the wrong way around, since any existing use of Collections.sort say with ArrayList will not avail of the optimal implementation provided by ArrayList.sort. To resolve this the implementation of Collections.sort can be moved to List.sort and Collections.sort can defer to List.sort. Code changes are here: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8030848-Collections-sort/webrev/ I made some tweaks to Arrays.sort to preserve cases when the Comparator is null. Existing tests provide good coverage and there are no regressions when i run j.u. tests locally. I am not happy with the current documentation though, i think that also requires some refactoring, moving stuff from Collections.sort to List.sort and explicitly stating what the current implementation of Collections.sort does. I believe this requires no spec changes even though it may appear so. Thoughts? Also, i am concerned that this change could cause stack overflows for list implementations that override sort and still defer to Collections.sort. Implying we should fix this for 8 or quickly in an 8u. Paul. From chris.hegarty at oracle.com Fri Jan 10 11:48:17 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 10 Jan 2014 11:48:17 +0000 Subject: RFR 8031428 CountTest causes lambda Ser/Derialization tests to fail In-Reply-To: References: Message-ID: <52CFDE01.3040602@oracle.com> Looks fine to me. I don't think AtomicLong was ever needed here. -Chris. On 10/01/14 10:01, Paul Sandoz wrote: > Hi, > > A small tweak is required to a recent Stream-based test i added to stop some internal lambda-based ser/derialization (SAND) tests barfing since the test is hostile to ser/derialization, and infact i should have probably written the test like below in the first place. > > Kumar has verified it fixes the SAND test failures. > > Paul. > > https://bugs.openjdk.java.net/browse/JDK-8031428 > > diff -r e332a6819993 test/java/util/stream/test/org/openjdk/tests/java/util/stream/CountTest.java > --- a/test/java/util/stream/test/org/openjdk/tests/java/util/stream/CountTest.java Fri Jan 10 08:22:00 2014 +0100 > +++ b/test/java/util/stream/test/org/openjdk/tests/java/util/stream/CountTest.java Fri Jan 10 10:58:06 2014 +0100 > @@ -29,7 +29,6 @@ > > package org.openjdk.tests.java.util.stream; > > -import java.util.concurrent.atomic.AtomicLong; > import java.util.stream.DoubleStream; > import java.util.stream.DoubleStreamTestDataProvider; > import java.util.stream.IntStream; > @@ -47,45 +46,41 @@ > > @Test(dataProvider = "StreamTestData", dataProviderClass = StreamTestDataProvider.class) > public void testOps(String name, TestData.OfRef data) { > - AtomicLong expectedCount = new AtomicLong(); > - data.stream().forEach(e -> expectedCount.incrementAndGet()); > + long expectedCount = data.size(); > > withData(data). > terminal(Stream::count). > - expectedResult(expectedCount.get()). > + expectedResult(expectedCount). > exercise(); > } > > @Test(dataProvider = "IntStreamTestData", dataProviderClass = IntStreamTestDataProvider.class) > public void testOps(String name, TestData.OfInt data) { > - AtomicLong expectedCount = new AtomicLong(); > - data.stream().forEach(e -> expectedCount.incrementAndGet()); > + long expectedCount = data.size(); > > withData(data). > terminal(IntStream::count). > - expectedResult(expectedCount.get()). > + expectedResult(expectedCount). > exercise(); > } > > @Test(dataProvider = "LongStreamTestData", dataProviderClass = LongStreamTestDataProvider.class) > public void testOps(String name, TestData.OfLong data) { > - AtomicLong expectedCount = new AtomicLong(); > - data.stream().forEach(e -> expectedCount.incrementAndGet()); > + long expectedCount = data.size(); > > withData(data). > terminal(LongStream::count). > - expectedResult(expectedCount.get()). > + expectedResult(expectedCount). > exercise(); > } > > @Test(dataProvider = "DoubleStreamTestData", dataProviderClass = DoubleStreamTestDataProvider.class) > public void testOps(String name, TestData.OfDouble data) { > - AtomicLong expectedCount = new AtomicLong(); > - data.stream().forEach(e -> expectedCount.incrementAndGet()); > + long expectedCount = data.size(); > > withData(data). > terminal(DoubleStream::count). > - expectedResult(expectedCount.get()). > + expectedResult(expectedCount). > exercise(); > } > } > From paul.sandoz at oracle.com Fri Jan 10 11:48:57 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 10 Jan 2014 12:48:57 +0100 Subject: RFR 8031428 CountTest causes lambda Ser/Derialization tests to fail In-Reply-To: <52CFDE01.3040602@oracle.com> References: <52CFDE01.3040602@oracle.com> Message-ID: <9D2F1ECE-489E-4188-A98F-B2FBC8C462C2@oracle.com> On Jan 10, 2014, at 12:48 PM, Chris Hegarty wrote: > Looks fine to me. Thanks. > I don't think AtomicLong was ever needed here. > It was crudely used as a holder of the count, since captured refs are (effectively) final, and not for it's concurrent properties as i wanted to avoid using any higher-level operations such as sum(). Paul. From gunnar at hibernate.org Fri Jan 10 12:33:33 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Fri, 10 Jan 2014 13:33:33 +0100 Subject: (reflect) Accessing members of inner annotations types In-Reply-To: <20140108132657.GA8851@oracle.com> References: <52C6CEBA.5090006@gmail.com> <52C6DD70.7070802@gmail.com> <20140108120056.GF2996@oracle.com> <52CD4D44.5000508@gmail.com> <20140108132657.GA8851@oracle.com> Message-ID: Hi, Many thanks for the investigation and suggested workarounds. Bean Validation recommends to declare an inner @List annotation to specify several constraints of the same type on a given element, but its ok to deviate from that pattern in the rare cases of package-private constraint types. > I can file a bug/rfe for this. I think that would be great; Taking the referenced types into account when determining the package for generated proxy classes sounds reasonable to me. Thanks again, --Gunnar 2014/1/8 Joel Borggren-Franck > On 2014-01-08, Peter Levart wrote: > > On 01/08/2014 01:00 PM, Joel Borggren-Franck wrote: > > >> > > >Perhaps an alternative would be to check if the interface a proxy is > > >proxying is nested. In that case use the outermost interface's access > > >level for the package calculation. > > > > > >This would probably lead to a few more proxies being generated into the > > >"real" package compared to your proposal. I don't know if that is ok or > > >not. > > > The nested public interface need not be referencing the outer > > class/interface. In this case, proxy class can be generated in > > com.sun.proxy. > > Yes, this is the reason for my remark about more proxies being generated > into the real package. I'm not sure this is a problem, however it is > moot considering you second point. > > > More importantly, even if the outer interface/class > > was public, the nested interface could be referencing some other > > package-private type. For example: > > > > Ugh. Acknowledged. (This feels like a really bad practice but that > doesn't matter here.) > > cheers > /Joel > From erik.joelsson at oracle.com Fri Jan 10 12:29:57 2014 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Fri, 10 Jan 2014 12:29:57 +0000 Subject: hg: jdk8/tl/jdk: 8031300: No jdeps.1 and jjs.1 man pages in jdk8 b122 build and jvisualvm.1 and jcmd.1 missing on macosx; ... Message-ID: <20140110123036.99DB6624BC@hg.openjdk.java.net> Changeset: 6f3a3bd78c57 Author: erikj Date: 2014-01-10 10:25 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6f3a3bd78c57 8031300: No jdeps.1 and jjs.1 man pages in jdk8 b122 build and jvisualvm.1 and jcmd.1 missing on macosx 8030946: No jmc.1 for man page of JMC Reviewed-by: ihse, tbell ! make/Images.gmk + src/bsd/doc/man/ja/jcmd.1 + src/bsd/doc/man/ja/jdeps.1 + src/bsd/doc/man/ja/jjs.1 - src/bsd/doc/man/ja/kinit.1 - src/bsd/doc/man/ja/klist.1 - src/bsd/doc/man/ja/ktab.1 From paul.sandoz at oracle.com Fri Jan 10 13:42:49 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 10 Jan 2014 14:42:49 +0100 Subject: RFR 8029452: Fork/Join task ForEachOps.ForEachOrderedTask clarifications and minor improvements Message-ID: <6F2D7451-6826-4CC5-AE55-62BD97EB5264@oracle.com> Hi, Some tweaks to the Stream forEachOrdered operation: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8029452-ForEachOrdered/webrev/ The first tweak is to size the CHM used in ForEachOrderedTask, this avoids concurrent resizes and the costs associated with those. The second tweak is to consolidate the reporting of elements to within the ForEachOrderedTask.tryComplete method. I have also removed the inconsistently applied synchronized block. Either we apply it consistently to reporting or not at all. It was originally there because we were not sure that the "happens-before" relationship [1] between elements would be guaranteed. However, ForEachOrderedTask sets up such a relationship via completion counts to ensure leaf nodes complete in encounter order (if any) where only one leaf can be completing (which was left most leaf that was not completed), hence stamping a fence in the ground at these point seems redundant (at least i cannot see its value but could be missing something subtle). Paul. [1] *

This operation processes the elements one at a time, in encounter * order if one exists. Performing the action for one element * happens-before * performing the action for subsequent elements, but for any given element, * the action may be performed in whatever thread the library chooses. * * @param action a * non-interfering action to perform on the elements * @see #forEach(Consumer) */ void forEachOrdered(Consumer action); From Alan.Bateman at oracle.com Fri Jan 10 14:01:27 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 10 Jan 2014 14:01:27 +0000 Subject: RFR 8030848: Collections.sort(List l, Comparator) should defer to List.sort(Comparator ) In-Reply-To: References: Message-ID: <52CFFD37.7050603@oracle.com> On 10/01/2014 11:21, Paul Sandoz wrote: > Hi, > > When we added the List.sort method the default implementation deferred to Collections.sort. > > This is the wrong way around, since any existing use of Collections.sort say with ArrayList will not avail of the optimal implementation provided by ArrayList.sort. > > To resolve this the implementation of Collections.sort can be moved to List.sort and Collections.sort can defer to List.sort. > > Code changes are here: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8030848-Collections-sort/webrev/ > > I made some tweaks to Arrays.sort to preserve cases when the Comparator is null. > > Existing tests provide good coverage and there are no regressions when i run j.u. tests locally. > > I am not happy with the current documentation though, i think that also requires some refactoring, moving stuff from Collections.sort to List.sort and explicitly stating what the current implementation of Collections.sort does. I believe this requires no spec changes even though it may appear so. Thoughts? > > Also, i am concerned that this change could cause stack overflows for list implementations that override sort and still defer to Collections.sort. Implying we should fix this for 8 or quickly in an 8u. > > Paul. The implementation changes look good. I agree that the javadoc needs changing as it's otherwise misleading as to what the implementation actually does. I would think that this should go with the implementation change rather than as a separate change. So is the stack overflow concern with List implementations that were originally developed to target JDK 7 or older? In any case, this is the type of change more suitable to a major release. -Alan. From paul.sandoz at oracle.com Fri Jan 10 14:13:03 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 10 Jan 2014 15:13:03 +0100 Subject: RFR 8030848: Collections.sort(List l, Comparator) should defer to List.sort(Comparator ) In-Reply-To: <52CFFD37.7050603@oracle.com> References: <52CFFD37.7050603@oracle.com> Message-ID: <975C496A-7C3D-4AAD-818F-629275822765@oracle.com> On Jan 10, 2014, at 3:01 PM, Alan Bateman wrote: > The implementation changes look good. I agree that the javadoc needs changing as it's otherwise misleading as to what the implementation actually does. I would think that this should go with the implementation change rather than as a separate change. > Yes, i did the easy bit first :-) > So is the stack overflow concern with List implementations that were originally developed to target JDK 7 or older? No, i think that case is OK, since those implementations will automatically inherit the correct defaults when run with 8. I am referring to following situation: a class developed against 8 that extends List and for some reason overrides List.sort with an implementation that defers to Collection.sort. Such an instance of a class executed in 9 with this fix would barf on sort, hence it is better to close the gap sooner rather than later, even though this is admittedly a rare scenario. Paul. > In any case, this is the type of change more suitable to a major release. > From iaroslav.savytskyi at oracle.com Fri Jan 10 14:26:32 2014 From: iaroslav.savytskyi at oracle.com (Iaroslav Savytskyi) Date: Fri, 10 Jan 2014 15:26:32 +0100 Subject: Request for approval for bug #8031488 References: <49A6E316-0B59-4E17-B171-93FC7E98E79B@oracle.com> Message-ID: <5D15DDF1-421C-4A80-9A42-A5D408BD7838@oracle.com> Hello, I would like to request for approval for this fix. This is simple revert of the changes which caused the issue. I?ve returned back synchronization and removed volatile. So now serialVersionUID is the same as before. Bug: https://bugs.openjdk.java.net/browse/JDK-8031488 Webrev: http://cr.openjdk.java.net/~mkos/8027908/webrev.00 Thank you. ? Best regards? Iaroslav From Alan.Bateman at oracle.com Fri Jan 10 14:52:27 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 10 Jan 2014 14:52:27 +0000 Subject: Request for approval for bug #8031488 In-Reply-To: <5D15DDF1-421C-4A80-9A42-A5D408BD7838@oracle.com> References: <49A6E316-0B59-4E17-B171-93FC7E98E79B@oracle.com> <5D15DDF1-421C-4A80-9A42-A5D408BD7838@oracle.com> Message-ID: <52D0092B.5@oracle.com> On 10/01/2014 14:26, Iaroslav Savytskyi wrote: > Hello, > > I would like to request for approval for this fix. This is simple revert of the changes which caused the issue. I?ve returned back synchronization and removed volatile. So now serialVersionUID is the same as before. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8031488 > > Webrev: > http://cr.openjdk.java.net/~mkos/8027908/webrev.00 > If these are changed to use synchronization then maybe you want to change getLinkedException too. In any case, isn't the right thing to just add the serialVersionUID? That is, I assume the issue that the missing serialVersionUID meant the default SUID changed when you changed a field modifier. -Alan. From iaroslav.savytskyi at oracle.com Fri Jan 10 15:08:33 2014 From: iaroslav.savytskyi at oracle.com (Iaroslav Savytskyi) Date: Fri, 10 Jan 2014 16:08:33 +0100 Subject: Request for approval for bug #8031488 In-Reply-To: <52D0092B.5@oracle.com> References: <49A6E316-0B59-4E17-B171-93FC7E98E79B@oracle.com> <5D15DDF1-421C-4A80-9A42-A5D408BD7838@oracle.com> <52D0092B.5@oracle.com> Message-ID: Hi, Alan, You are absolutely right. Unfortunately the things a little bit more complicated. The reason why I?m fixing this now is, that some time ago I fix this synchronization issue (synchronized setter without synchronized getter). After that I got this bug. We had internal discussions if I can leave my changes and the short answer is ?no? :| Because it?s JAXB API and I can?t change signatures within the same version. So I have to revert my changes and leave it as it was before. We will fix this in the next MR for JAXB API. -- Regards. Iaroslav On 10 Jan 2014, at 15:52, Alan Bateman wrote: > On 10/01/2014 14:26, Iaroslav Savytskyi wrote: >> Hello, >> >> I would like to request for approval for this fix. This is simple revert of the changes which caused the issue. I?ve returned back synchronization and removed volatile. So now serialVersionUID is the same as before. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8031488 >> >> Webrev: >> http://cr.openjdk.java.net/~mkos/8027908/webrev.00 >> > If these are changed to use synchronization then maybe you want to change getLinkedException too. > > In any case, isn't the right thing to just add the serialVersionUID? That is, I assume the issue that the missing serialVersionUID meant the default SUID changed when you changed a field modifier. > > -Alan. From Alan.Bateman at oracle.com Fri Jan 10 15:36:03 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 10 Jan 2014 15:36:03 +0000 Subject: Request for approval for bug #8031488 In-Reply-To: References: <49A6E316-0B59-4E17-B171-93FC7E98E79B@oracle.com> <5D15DDF1-421C-4A80-9A42-A5D408BD7838@oracle.com> <52D0092B.5@oracle.com> Message-ID: <52D01363.8010504@oracle.com> On 10/01/2014 15:08, Iaroslav Savytskyi wrote: > Hi, Alan, > > You are absolutely right. Unfortunately the things a little bit more complicated. The reason why I?m fixing this now is, that some time ago I fix this synchronization issue (synchronized setter without synchronized getter). After that I got this bug. We had internal discussions if I can leave my changes and the short answer is ?no? :| Because it?s JAXB API and I can?t change signatures within the same version. So I have to revert my changes and leave it as it was before. We will fix this in the next MR for JAXB API. It looks to me that JAXBException has always defined its SUID so I assume this means there isn't really any need to revert that, right? For TypeConstraintException then adding the SUID to the value that it has always been doesn't change anything except that it now appears in the serialization form that javadoc reports. So any implementation of this exception type would need to use that value. That might be why you need to do a MR. If it is required then your change is okay although I think it would be better if getLinkedException was synchronized. You can use synchronized (this) { ... } around the read to avoid changing the modifiers (and hence SUID). -Alan. From roger.riggs at oracle.com Fri Jan 10 15:37:29 2014 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 10 Jan 2014 10:37:29 -0500 Subject: RFR: (8030875) Macros for checking and returning on exceptions Message-ID: <52D013B9.40101@oracle.com> Please review: To enable native code checking consistently for thrown exceptions, the macros in net_util.h and java/util/jar/pack/coding.cpp are made consolidated and promoted to jni_util.h webrev: http://cr.openjdk.java.net/~rriggs/webrev-check-exception-8030875/ [1] https://bugs.openjdk.java.net/browse/JDK-8030875 From chris.hegarty at oracle.com Fri Jan 10 15:49:17 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 10 Jan 2014 15:49:17 +0000 Subject: RFR: (8030875) Macros for checking and returning on exceptions In-Reply-To: <52D013B9.40101@oracle.com> References: <52D013B9.40101@oracle.com> Message-ID: <52D0167D.2000003@oracle.com> Thank you Roger, much appreciated. I think Dan has a change in flight that could be simplified a bit by using these. -Chris. On 10/01/14 15:37, roger riggs wrote: > Please review: > > To enable native code checking consistently for thrown exceptions, > the macros in net_util.h and java/util/jar/pack/coding.cpp are > made consolidated and promoted to jni_util.h > > webrev: > http://cr.openjdk.java.net/~rriggs/webrev-check-exception-8030875/ > > [1] https://bugs.openjdk.java.net/browse/JDK-8030875 From iaroslav.savytskyi at oracle.com Fri Jan 10 16:28:24 2014 From: iaroslav.savytskyi at oracle.com (Iaroslav Savytskyi) Date: Fri, 10 Jan 2014 17:28:24 +0100 Subject: Request for approval for bug #8031488 In-Reply-To: <52D01363.8010504@oracle.com> References: <49A6E316-0B59-4E17-B171-93FC7E98E79B@oracle.com> <5D15DDF1-421C-4A80-9A42-A5D408BD7838@oracle.com> <52D0092B.5@oracle.com> <52D01363.8010504@oracle.com> Message-ID: <41ECA632-F6A6-45DD-B9AB-6DEC3D9A9565@oracle.com> On 10 Jan 2014, at 16:36, Alan Bateman wrote: > On 10/01/2014 15:08, Iaroslav Savytskyi wrote: >> Hi, Alan, >> >> You are absolutely right. Unfortunately the things a little bit more complicated. The reason why I?m fixing this now is, that some time ago I fix this synchronization issue (synchronized setter without synchronized getter). After that I got this bug. We had internal discussions if I can leave my changes and the short answer is ?no? :| Because it?s JAXB API and I can?t change signatures within the same version. So I have to revert my changes and leave it as it was before. We will fix this in the next MR for JAXB API. > It looks to me that JAXBException has always defined its SUID so I assume this means there isn't really any need to revert that, right? Yes, JAXBException has SUID. The reason I?ve reverted my changes is that I?m going to fix both files at once in MR. > > For TypeConstraintException then adding the SUID to the value that it has always been doesn't change anything except that it now appears in the serialization form that javadoc reports. So any implementation of this exception type would need to use that value. That might be why you need to do a MR. If it is required then your change is okay although I think it would be better if getLinkedException was synchronized. You can use synchronized (this) { ... } around the read to avoid changing the modifiers (and hence SUID). > > -Alan. There are 3 possibilities: 1) Because it was my own initiative to fix this potential synchronization bug and nobody didn?t report it, we can approve my fix and leave this 2 classes without synchronized getters. And fix it in MR. 2) Fix it as you propose. But later we will definitely need to change it again to volatile for performance reasons. 3) Leave classes with volatile as they are now. And only add SUID to TypeConstraintException class. ? Iaroslav From roger.riggs at oracle.com Fri Jan 10 16:40:49 2014 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 10 Jan 2014 11:40:49 -0500 Subject: RFR: JDK-8029007, Check src/share/native/sun/misc code for JNI pending exceptions In-Reply-To: <52CF93C2.3080602@oracle.com> References: <52CF93C2.3080602@oracle.com> Message-ID: <52D02291.1000801@oracle.com> Hi Dan, Just pushed are macros in jni_util.h to do the same function as your new macros. Please update to use the common macros instead of introducing new ones. Style wise, I would avoid mixing binary operators (!) with pointers. it is clearer to compare with NULL. (The CHECK_NULL macro will do the check and return). (Not a Reviewer) Thanks, Roger On 1/10/2014 1:31 AM, Dan Xu wrote: > Hi All, > > Please review the fix for JNI pending exception issues reported in > jdk-8029007. Thanks! > > Webrev: http://cr.openjdk.java.net/~dxu/8029007/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8029007 > > -Dan From Alan.Bateman at oracle.com Fri Jan 10 16:45:04 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 10 Jan 2014 16:45:04 +0000 Subject: RFR: (8030875) Macros for checking and returning on exceptions In-Reply-To: <52D013B9.40101@oracle.com> References: <52D013B9.40101@oracle.com> Message-ID: <52D02390.60403@oracle.com> On 10/01/2014 15:37, roger riggs wrote: > Please review: > > To enable native code checking consistently for thrown exceptions, > the macros in net_util.h and java/util/jar/pack/coding.cpp are > made consolidated and promoted to jni_util.h > > webrev: > http://cr.openjdk.java.net/~rriggs/webrev-check-exception-8030875/ This looks okay to me. It would be good if Kumar takes a look at this too because it results in a mix of macros in the pack code. -Alan From miroslav.kos at oracle.com Fri Jan 10 17:05:47 2014 From: miroslav.kos at oracle.com (Miroslav Kos) Date: Fri, 10 Jan 2014 18:05:47 +0100 Subject: JDK8 RFR JDK-8029237 Update copyright year to match last edit in jdk8 jaxws repository for 2013 Message-ID: <52D0286B.9020108@oracle.com> Hi, this is about fixing copyright years for jdk8 (!); the incorrect years found for both 2012 and 2013, so not to confuse script jdk8/make/scripts/update_copyright_year.sh it is necessary to use option -d "" for commit. I tested that and it seems to work perfect. I used following: [2012 modifications] hg commit -u mkos -l ../2012-msg.txt -d "2012-12-30" [2013 modifications] hg commit -u mkos -l ../2013-msg.txt -d "2013-12-30" When commits performed with past date, update_copyright_year.sh script finds those in proper years. Since I am not familiar with using webrev for pushing changes, I exported both revisions into separate patches: 2012: http://cr.openjdk.java.net/~mkos/8029237/copyrights-2012.patch 2013: http://cr.openjdk.java.net/~mkos/8029237/copyrights-2013.patch all changes webrev: http://cr.openjdk.java.net/~mkos/8029237/webrev-all.00/ (upload still in progress, I hope it doesn't take more than 30 mins) bug: https://bugs.openjdk.java.net/browse/JDK-8029237 Regards Miran From michael.x.mcmahon at oracle.com Fri Jan 10 17:20:49 2014 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 10 Jan 2014 17:20:49 +0000 Subject: RFR: (8030875) Macros for checking and returning on exceptions In-Reply-To: <52D013B9.40101@oracle.com> References: <52D013B9.40101@oracle.com> Message-ID: <52D02BF1.4080908@oracle.com> On 10/01/14 15:37, roger riggs wrote: > Please review: > > To enable native code checking consistently for thrown exceptions, > the macros in net_util.h and java/util/jar/pack/coding.cpp are > made consolidated and promoted to jni_util.h > > webrev: > http://cr.openjdk.java.net/~rriggs/webrev-check-exception-8030875/ > > [1] https://bugs.openjdk.java.net/browse/JDK-8030875 Looks fine to me Michael. From dan.xu at oracle.com Fri Jan 10 17:40:05 2014 From: dan.xu at oracle.com (Dan Xu) Date: Fri, 10 Jan 2014 09:40:05 -0800 Subject: RFR: JDK-8029007, Check src/share/native/sun/misc code for JNI pending exceptions In-Reply-To: <91A54394-A96C-42BF-8569-7B9E16AA93DE@oracle.com> References: <52CF93C2.3080602@oracle.com> <91A54394-A96C-42BF-8569-7B9E16AA93DE@oracle.com> Message-ID: <52D03075.2010507@oracle.com> Thanks, Chris. Right, I don't find any usage of getThreadStateValues, so it is simpler to just remove it. -Dan On 01/09/2014 11:49 PM, Chris Hegarty wrote: > Looks ok to me. > > I presume getThreadStateValues is simply no longer needed. > > -Chris. > >> On 10 Jan 2014, at 06:31, Dan Xu wrote: >> >> Hi All, >> >> Please review the fix for JNI pending exception issues reported in jdk-8029007. Thanks! >> >> Webrev: http://cr.openjdk.java.net/~dxu/8029007/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8029007 >> >> -Dan From mandy.chung at oracle.com Fri Jan 10 17:41:40 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 10 Jan 2014 09:41:40 -0800 Subject: RFR: (8030875) Macros for checking and returning on exceptions In-Reply-To: <52D013B9.40101@oracle.com> References: <52D013B9.40101@oracle.com> Message-ID: <52D030D4.6020800@oracle.com> On 1/10/2014 7:37 AM, roger riggs wrote: > Please review: > > To enable native code checking consistently for thrown exceptions, > the macros in net_util.h and java/util/jar/pack/coding.cpp are > made consolidated and promoted to jni_util.h > > webrev: > http://cr.openjdk.java.net/~rriggs/webrev-check-exception-8030875/ > Looks good. Thanks for doing this Roger. Minor nit: the convention in jni.h seems to name functions that take JNIEnv* parameter with the "JNU_" prefix and so might be better to rename CHECK_EXCEPTION to JNU_CheckedException. Mandy From dan.xu at oracle.com Fri Jan 10 17:46:18 2014 From: dan.xu at oracle.com (Dan Xu) Date: Fri, 10 Jan 2014 09:46:18 -0800 Subject: RFR: JDK-8029007, Check src/share/native/sun/misc code for JNI pending exceptions In-Reply-To: <52CFCC4C.6090600@oracle.com> References: <52CF93C2.3080602@oracle.com> <52CFCC4C.6090600@oracle.com> Message-ID: <52D031EA.8040400@oracle.com> On 01/10/2014 02:32 AM, Alan Bateman wrote: > On 10/01/2014 06:31, Dan Xu wrote: >> Hi All, >> >> Please review the fix for JNI pending exception issues reported in >> jdk-8029007. Thanks! >> >> Webrev: http://cr.openjdk.java.net/~dxu/8029007/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8029007 > This looks good, the only one that isn't clear (to me) is the > GetStringLength usage in MessageUtil.c where I don't think it is > possible to ever get < 0. This may be a case where you need to use > ExceptionOccured instead. > > -Alan. According to jni.cpp, GetStringLength() will always return positive value or 0. For simplicity, I will change "<= 0" to "== 0". Thanks, Alan. -Dan From daniel.fuchs at oracle.com Fri Jan 10 17:47:43 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 10 Jan 2014 18:47:43 +0100 Subject: JDK-9 RFR for 8031525: Logger created in test/tools/jar/UpdateManifest.java might get gc'ed too early. Message-ID: <52D0323F.90708@oracle.com> Hi, Please find below a trivial fix for 8031525: Logger created in test/tools/jar/UpdateManifest.java might get gc'ed too early. https://bugs.openjdk.java.net/browse/JDK-8031525 Hopefully that's the last of its kind - (see https://bugs.openjdk.java.net/browse/JDK-8029595). webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8031525-jdk9/webrev.00/ best regards, -- daniel From chris.hegarty at oracle.com Fri Jan 10 17:55:35 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 10 Jan 2014 17:55:35 +0000 Subject: JDK-9 RFR for 8031525: Logger created in test/tools/jar/UpdateManifest.java might get gc'ed too early. In-Reply-To: <52D0323F.90708@oracle.com> References: <52D0323F.90708@oracle.com> Message-ID: Looks good to me Daniel. -Chris. On 10 Jan 2014, at 17:47, Daniel Fuchs wrote: > Hi, > > Please find below a trivial fix for > 8031525: Logger created in test/tools/jar/UpdateManifest.java might > get gc'ed too early. > > https://bugs.openjdk.java.net/browse/JDK-8031525 > > Hopefully that's the last of its kind - (see https://bugs.openjdk.java.net/browse/JDK-8029595). > > webrev: > > http://cr.openjdk.java.net/~dfuchs/webrev_8031525-jdk9/webrev.00/ > > best regards, > > -- daniel From mike.duigou at oracle.com Fri Jan 10 17:56:38 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 10 Jan 2014 09:56:38 -0800 Subject: RFR 8030848: Collections.sort(List l, Comparator) should defer to List.sort(Comparator ) In-Reply-To: References: Message-ID: <62CA56D8-F360-46C3-9B06-888634F73DB6@oracle.com> The implementation looks good. I would move construction of the listIterator to before the toArray() for detection of concurrent modification (growing of the list). I believe we should fix this for 8 if possible. Mike On Jan 10 2014, at 03:21 , Paul Sandoz wrote: > Hi, > > When we added the List.sort method the default implementation deferred to Collections.sort. > > This is the wrong way around, since any existing use of Collections.sort say with ArrayList will not avail of the optimal implementation provided by ArrayList.sort. > > To resolve this the implementation of Collections.sort can be moved to List.sort and Collections.sort can defer to List.sort. > > Code changes are here: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8030848-Collections-sort/webrev/ > > I made some tweaks to Arrays.sort to preserve cases when the Comparator is null. > > Existing tests provide good coverage and there are no regressions when i run j.u. tests locally. > > I am not happy with the current documentation though, i think that also requires some refactoring, moving stuff from Collections.sort to List.sort and explicitly stating what the current implementation of Collections.sort does. I believe this requires no spec changes even though it may appear so. Thoughts? > > Also, i am concerned that this change could cause stack overflows for list implementations that override sort and still defer to Collections.sort. Implying we should fix this for 8 or quickly in an 8u. > > Paul. From roger.riggs at oracle.com Fri Jan 10 17:59:22 2014 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 10 Jan 2014 12:59:22 -0500 Subject: RFR: (8030875) Macros for checking and returning on exceptions In-Reply-To: <52D030D4.6020800@oracle.com> References: <52D013B9.40101@oracle.com> <52D030D4.6020800@oracle.com> Message-ID: <52D034FA.5090301@oracle.com> Hi Mandy, Good point; I'll create another issue to do that update. (I should have waited a bit longer for comments.) Roger On 1/10/2014 12:41 PM, Mandy Chung wrote: > On 1/10/2014 7:37 AM, roger riggs wrote: >> Please review: >> >> To enable native code checking consistently for thrown exceptions, >> the macros in net_util.h and java/util/jar/pack/coding.cpp are >> made consolidated and promoted to jni_util.h >> >> webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-check-exception-8030875/ >> > > Looks good. Thanks for doing this Roger. Minor nit: the convention > in jni.h seems to name functions that take JNIEnv* parameter with the > "JNU_" prefix and so might be better to rename CHECK_EXCEPTION to > JNU_CheckedException. > > Mandy > From roger.riggs at oracle.com Fri Jan 10 17:59:57 2014 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 10 Jan 2014 12:59:57 -0500 Subject: RFR: JDK-8029007, Check src/share/native/sun/misc code for JNI pending exceptions In-Reply-To: <52D02291.1000801@oracle.com> References: <52CF93C2.3080602@oracle.com> <52D02291.1000801@oracle.com> Message-ID: <52D0351D.7090906@oracle.com> Hi Dan, One other comment, instead of changing the return type of the setStaticIntField just return and the caller should check for exceptions and return. See jni.h: CHECK_EXCEPTION(env) Roger On 1/10/2014 11:40 AM, roger riggs wrote: > Hi Dan, > > Just pushed are macros in jni_util.h to do the same function as your > new macros. > Please update to use the common macros instead of introducing new ones. > > Style wise, I would avoid mixing binary operators (!) with pointers. > it is clearer to compare with NULL. (The CHECK_NULL macro will do the > check and return). > > (Not a Reviewer) > > Thanks, Roger > > > > On 1/10/2014 1:31 AM, Dan Xu wrote: >> Hi All, >> >> Please review the fix for JNI pending exception issues reported in >> jdk-8029007. Thanks! >> >> Webrev: http://cr.openjdk.java.net/~dxu/8029007/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8029007 >> >> -Dan > From dan.xu at oracle.com Fri Jan 10 18:05:35 2014 From: dan.xu at oracle.com (Dan Xu) Date: Fri, 10 Jan 2014 10:05:35 -0800 Subject: RFR: JDK-8029007, Check src/share/native/sun/misc code for JNI pending exceptions In-Reply-To: <52D02291.1000801@oracle.com> References: <52CF93C2.3080602@oracle.com> <52D02291.1000801@oracle.com> Message-ID: <52D0366F.4040202@oracle.com> Hi Roger, My macro is a little different from yours, which compares with -1 instead of NULL. I also see CHECK_EXCEPTION macro. Thanks for adding them, which are useful when I cannot decide the pending exception state by just using return values. As for the style, actually I prefer the (!pointer) to (pointer == NULL) because it is more concise and also make me avoid the typo like (pointer = NULL), which I cannot find from the compilation. Thanks! -Dan On 01/10/2014 08:40 AM, roger riggs wrote: > Hi Dan, > > Just pushed are macros in jni_util.h to do the same function as your > new macros. > Please update to use the common macros instead of introducing new ones. > > Style wise, I would avoid mixing binary operators (!) with pointers. > it is clearer to compare with NULL. (The CHECK_NULL macro will do the > check and return). > > (Not a Reviewer) > > Thanks, Roger > > > > On 1/10/2014 1:31 AM, Dan Xu wrote: >> Hi All, >> >> Please review the fix for JNI pending exception issues reported in >> jdk-8029007. Thanks! >> >> Webrev: http://cr.openjdk.java.net/~dxu/8029007/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8029007 >> >> -Dan > From dan.xu at oracle.com Fri Jan 10 18:07:08 2014 From: dan.xu at oracle.com (Dan Xu) Date: Fri, 10 Jan 2014 10:07:08 -0800 Subject: RFR: JDK-8029007, Check src/share/native/sun/misc code for JNI pending exceptions In-Reply-To: <52D0351D.7090906@oracle.com> References: <52CF93C2.3080602@oracle.com> <52D02291.1000801@oracle.com> <52D0351D.7090906@oracle.com> Message-ID: <52D036CC.7040902@oracle.com> Yes, you are right. I just found this macro. It looks very handy to use. Thanks! -Dan On 01/10/2014 09:59 AM, roger riggs wrote: > Hi Dan, > > One other comment, instead of changing the return type of the > setStaticIntField > just return and the caller should check for exceptions and return. > See jni.h: CHECK_EXCEPTION(env) > > Roger > > On 1/10/2014 11:40 AM, roger riggs wrote: >> Hi Dan, >> >> Just pushed are macros in jni_util.h to do the same function as your >> new macros. >> Please update to use the common macros instead of introducing new ones. >> >> Style wise, I would avoid mixing binary operators (!) with pointers. >> it is clearer to compare with NULL. (The CHECK_NULL macro will do >> the check and return). >> >> (Not a Reviewer) >> >> Thanks, Roger >> >> >> >> On 1/10/2014 1:31 AM, Dan Xu wrote: >>> Hi All, >>> >>> Please review the fix for JNI pending exception issues reported in >>> jdk-8029007. Thanks! >>> >>> Webrev: http://cr.openjdk.java.net/~dxu/8029007/webrev.00/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8029007 >>> >>> -Dan >> > From chris.hegarty at oracle.com Fri Jan 10 18:09:26 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 10 Jan 2014 18:09:26 +0000 Subject: RFR: JDK-8029007, Check src/share/native/sun/misc code for JNI pending exceptions In-Reply-To: <52D0366F.4040202@oracle.com> References: <52CF93C2.3080602@oracle.com> <52D02291.1000801@oracle.com> <52D0366F.4040202@oracle.com> Message-ID: <9702122F-4D2B-4EB9-BE62-21A49A378B8B@oracle.com> On 10 Jan 2014, at 18:05, Dan Xu wrote: > Hi Roger, > > My macro is a little different from yours, which compares with -1 instead of NULL. I also see CHECK_EXCEPTION macro. Thanks for adding them, which are useful when I cannot decide the pending exception state by just using return values. > > As for the style, actually I prefer the (!pointer) to (pointer == NULL) because it is more concise and also make me avoid the typo like (pointer = NULL), which I cannot find from the compilation. Thanks! Not that it matters, but my preference is to == NULL. -Chris. > > -Dan > > > On 01/10/2014 08:40 AM, roger riggs wrote: >> Hi Dan, >> >> Just pushed are macros in jni_util.h to do the same function as your new macros. >> Please update to use the common macros instead of introducing new ones. >> >> Style wise, I would avoid mixing binary operators (!) with pointers. >> it is clearer to compare with NULL. (The CHECK_NULL macro will do the check and return). >> >> (Not a Reviewer) >> >> Thanks, Roger >> >> >> >> On 1/10/2014 1:31 AM, Dan Xu wrote: >>> Hi All, >>> >>> Please review the fix for JNI pending exception issues reported in jdk-8029007. Thanks! >>> >>> Webrev: http://cr.openjdk.java.net/~dxu/8029007/webrev.00/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8029007 >>> >>> -Dan >> > From mike.duigou at oracle.com Fri Jan 10 18:11:53 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 10 Jan 2014 10:11:53 -0800 Subject: RFR 8029452: Fork/Join task ForEachOps.ForEachOrderedTask clarifications and minor improvements In-Reply-To: <6F2D7451-6826-4CC5-AE55-62BD97EB5264@oracle.com> References: <6F2D7451-6826-4CC5-AE55-62BD97EB5264@oracle.com> Message-ID: <609B51BD-A124-4A71-8C5D-AA28DA845792@oracle.com> On Jan 10 2014, at 05:42 , Paul Sandoz wrote: > Hi, > > Some tweaks to the Stream forEachOrdered operation: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8029452-ForEachOrdered/webrev/ > > The first tweak is to size the CHM used in ForEachOrderedTask, this avoids concurrent resizes and the costs associated with those. +1 > > The second tweak is to consolidate the reporting of elements to within the ForEachOrderedTask.tryComplete method. > > I have also removed the inconsistently applied synchronized block. Either we apply it consistently to reporting or not at all. It was originally there because we were not sure that the "happens-before" relationship [1] between elements would be guaranteed. However, ForEachOrderedTask sets up such a relationship via completion counts to ensure leaf nodes complete in encounter order (if any) where only one leaf can be completing (which was left most leaf that was not completed), hence stamping a fence in the ground at these point seems redundant (at least i cannot see its value but could be missing something subtle). Coud not the lock object be removed? Mike > > Paul. > > [1] > *

This operation processes the elements one at a time, in encounter > * order if one exists. Performing the action for one element > * happens-before > * performing the action for subsequent elements, but for any given element, > * the action may be performed in whatever thread the library chooses. > * > * @param action a > * non-interfering action to perform on the elements > * @see #forEach(Consumer) > */ > void forEachOrdered(Consumer action); > From paul.sandoz at oracle.com Fri Jan 10 18:18:31 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 10 Jan 2014 19:18:31 +0100 Subject: RFR 8029452: Fork/Join task ForEachOps.ForEachOrderedTask clarifications and minor improvements In-Reply-To: <609B51BD-A124-4A71-8C5D-AA28DA845792@oracle.com> References: <6F2D7451-6826-4CC5-AE55-62BD97EB5264@oracle.com> <609B51BD-A124-4A71-8C5D-AA28DA845792@oracle.com> Message-ID: <3A96C219-5EF9-432F-B544-7BF06E39845A@oracle.com> On Jan 10, 2014, at 7:11 PM, Mike Duigou wrote: >> >> The second tweak is to consolidate the reporting of elements to within the ForEachOrderedTask.tryComplete method. >> >> I have also removed the inconsistently applied synchronized block. Either we apply it consistently to reporting or not at all. It was originally there because we were not sure that the "happens-before" relationship [1] between elements would be guaranteed. However, ForEachOrderedTask sets up such a relationship via completion counts to ensure leaf nodes complete in encounter order (if any) where only one leaf can be completing (which was left most leaf that was not completed), hence stamping a fence in the ground at these point seems redundant (at least i cannot see its value but could be missing something subtle). > > Coud not the lock object be removed? > Doh, yes, thanks, updated, Paul. From mike.duigou at oracle.com Fri Jan 10 18:21:03 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 10 Jan 2014 10:21:03 -0800 Subject: RFR: JDK-8029007, Check src/share/native/sun/misc code for JNI pending exceptions In-Reply-To: <9702122F-4D2B-4EB9-BE62-21A49A378B8B@oracle.com> References: <52CF93C2.3080602@oracle.com> <52D02291.1000801@oracle.com> <52D0366F.4040202@oracle.com> <9702122F-4D2B-4EB9-BE62-21A49A378B8B@oracle.com> Message-ID: <4E1AD280-1B5A-40D2-BCFE-C87EB81CBBCF@oracle.com> On Jan 10 2014, at 10:09 , Chris Hegarty wrote: > On 10 Jan 2014, at 18:05, Dan Xu wrote: > >> Hi Roger, >> >> My macro is a little different from yours, which compares with -1 instead of NULL. I also see CHECK_EXCEPTION macro. Thanks for adding them, which are useful when I cannot decide the pending exception state by just using return values. >> >> As for the style, actually I prefer the (!pointer) to (pointer == NULL) because it is more concise and also make me avoid the typo like (pointer = NULL), which I cannot find from the compilation. Thanks! There's always "yoda conditions" https://en.wikipedia.org/wiki/Yoda_conditions, (NULL == pointer), but that's not likely to make anyone (besides me) happy. Mike > > Not that it matters, but my preference is to == NULL. > > -Chris. > >> >> -Dan >> >> >> On 01/10/2014 08:40 AM, roger riggs wrote: >>> Hi Dan, >>> >>> Just pushed are macros in jni_util.h to do the same function as your new macros. >>> Please update to use the common macros instead of introducing new ones. >>> >>> Style wise, I would avoid mixing binary operators (!) with pointers. >>> it is clearer to compare with NULL. (The CHECK_NULL macro will do the check and return). >>> >>> (Not a Reviewer) >>> >>> Thanks, Roger >>> >>> >>> >>> On 1/10/2014 1:31 AM, Dan Xu wrote: >>>> Hi All, >>>> >>>> Please review the fix for JNI pending exception issues reported in jdk-8029007. Thanks! >>>> >>>> Webrev: http://cr.openjdk.java.net/~dxu/8029007/webrev.00/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8029007 >>>> >>>> -Dan >>> >> > From dan.xu at oracle.com Fri Jan 10 19:40:29 2014 From: dan.xu at oracle.com (Dan Xu) Date: Fri, 10 Jan 2014 11:40:29 -0800 Subject: RFR: JDK-8029007, Check src/share/native/sun/misc code for JNI pending exceptions In-Reply-To: <4E1AD280-1B5A-40D2-BCFE-C87EB81CBBCF@oracle.com> References: <52CF93C2.3080602@oracle.com> <52D02291.1000801@oracle.com> <52D0366F.4040202@oracle.com> <9702122F-4D2B-4EB9-BE62-21A49A378B8B@oracle.com> <4E1AD280-1B5A-40D2-BCFE-C87EB81CBBCF@oracle.com> Message-ID: <52D04CAD.2020506@oracle.com> Thank you for all the feedback. I have updated my changes to use "CHECK_EXCEPTION_RETURN" and "CHECK_EXCEPTION" macro recently added into jni_util.h. I also removed else block in function setStaticIntField() in Version.c since (*env)->GetStaticFieldID will throw a same exception if the field cannot be found. Here is the new webrev: http://cr.openjdk.java.net/~dxu/8029007/webrev.01/. Thanks! -Dan On 01/10/2014 10:21 AM, Mike Duigou wrote: > On Jan 10 2014, at 10:09 , Chris Hegarty wrote: > >> On 10 Jan 2014, at 18:05, Dan Xu wrote: >> >>> Hi Roger, >>> >>> My macro is a little different from yours, which compares with -1 instead of NULL. I also see CHECK_EXCEPTION macro. Thanks for adding them, which are useful when I cannot decide the pending exception state by just using return values. >>> >>> As for the style, actually I prefer the (!pointer) to (pointer == NULL) because it is more concise and also make me avoid the typo like (pointer = NULL), which I cannot find from the compilation. Thanks! > There's always "yoda conditions" https://en.wikipedia.org/wiki/Yoda_conditions, (NULL == pointer), but that's not likely to make anyone (besides me) happy. > > Mike > >> Not that it matters, but my preference is to == NULL. >> >> -Chris. >> >>> -Dan >>> >>> >>> On 01/10/2014 08:40 AM, roger riggs wrote: >>>> Hi Dan, >>>> >>>> Just pushed are macros in jni_util.h to do the same function as your new macros. >>>> Please update to use the common macros instead of introducing new ones. >>>> >>>> Style wise, I would avoid mixing binary operators (!) with pointers. >>>> it is clearer to compare with NULL. (The CHECK_NULL macro will do the check and return). >>>> >>>> (Not a Reviewer) >>>> >>>> Thanks, Roger >>>> >>>> >>>> >>>> On 1/10/2014 1:31 AM, Dan Xu wrote: >>>>> Hi All, >>>>> >>>>> Please review the fix for JNI pending exception issues reported in jdk-8029007. Thanks! >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~dxu/8029007/webrev.00/ >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8029007 >>>>> >>>>> -Dan From srikalyan.chandrashekar at oracle.com Fri Jan 10 21:51:44 2014 From: srikalyan.chandrashekar at oracle.com (srikalyan chandrashekar) Date: Fri, 10 Jan 2014 13:51:44 -0800 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52CFD218.2060101@gmail.com> References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> <52CC72AB.2020104@oracle.com> <52CCEDE0.8000809@oracle.com> <52CCF079.4090301@oracle.com> <52CD45E7.7010203@gmail.com> <52CE4E2D.300@oracle.com> <52CF37C6.1070605@oracle.com> <52CFAFEB.9090703@gmail.com> <52CFD218.2060101@gmail.com> Message-ID: <52D06B70.60001@oracle.com> Hi Peter the version you provided ran indefinitely(i put a 10 minute timeout) and the program got interrupted(no error), even if there were to be an error you cannot print the "string" of thread to console(these have been attempted earlier). - The test's running on interpreter mode, what i am watching for is one error with trace. Without fastdebug build and -XX:+TraceExceptions i am able to reproduce failure atleast 5 failures out of 1000 runs but with fastdebug+Trace no luck yet(already past few 1000 runs). --- Thanks kalyan On 01/10/2014 02:57 AM, Peter Levart wrote: > On 01/10/2014 09:31 AM, Peter Levart wrote: >> Since we suspect there's something wrong with exception handling in >> interpreter, I devised a hypothetical reproducer that tries to >> simulate ReferenceHandler in many aspects, but doesn't require to be >> a ReferenceHandler: >> >> http://cr.openjdk.java.net/~plevart/misc/OOME/OOMECatchingTest.java >> >> This is designed to run indefinitely and only terminate if/when >> thread dies. Could you run this program in the environment that >> causes the OOMEInReferenceHandler test to fail and see if it terminates? > > I forgot to mention that in order for this long-running program to > exhibit interpreter behaviour, it should be run with -Xint option. So > I suggest: > > -Xmx24M -XX:-UseTLAB -Xint > > Regards, Peter > From kumar.x.srinivasan at oracle.com Sat Jan 11 00:55:43 2014 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Fri, 10 Jan 2014 16:55:43 -0800 Subject: 8031494: [launcher] java launcher should check for JNI Pending exceptions. Message-ID: <52D0968F.6090702@oracle.com> Hi, Please review fixes for launcher correctness wrt. JNI calls. http://cr.openjdk.java.net/~ksrini/8031494/webrev.0/ Thanks Kumar From chris.hegarty at oracle.com Sat Jan 11 07:59:44 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sat, 11 Jan 2014 07:59:44 +0000 Subject: 8031494: [launcher] java launcher should check for JNI Pending exceptions. In-Reply-To: <52D0968F.6090702@oracle.com> References: <52D0968F.6090702@oracle.com> Message-ID: <829FFF26-736D-4EF5-9966-6CF9F4E48CDA@oracle.com> Looks ok to me Kumar. -Chris. > On 11 Jan 2014, at 00:55, Kumar Srinivasan wrote: > > Hi, > > Please review fixes for launcher correctness wrt. JNI calls. > > http://cr.openjdk.java.net/~ksrini/8031494/webrev.0/ > > Thanks > Kumar > From chris.hegarty at oracle.com Sat Jan 11 08:10:49 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sat, 11 Jan 2014 08:10:49 +0000 Subject: RFR: JDK-8029007, Check src/share/native/sun/misc code for JNI pending exceptions In-Reply-To: <52D04CAD.2020506@oracle.com> References: <52CF93C2.3080602@oracle.com> <52D02291.1000801@oracle.com> <52D0366F.4040202@oracle.com> <9702122F-4D2B-4EB9-BE62-21A49A378B8B@oracle.com> <4E1AD280-1B5A-40D2-BCFE-C87EB81CBBCF@oracle.com> <52D04CAD.2020506@oracle.com> Message-ID: <0C5C5A58-27A3-4E3C-9B63-9BF8EEC621F4@oracle.com> > On 10 Jan 2014, at 19:40, Dan Xu wrote: > > Thank you for all the feedback. I have updated my changes to use "CHECK_EXCEPTION_RETURN" and "CHECK_EXCEPTION" macro recently added into jni_util.h. I also removed else block in function setStaticIntField() in Version.c since (*env)->GetStaticFieldID will throw a same exception if the field cannot be found. > > Here is the new webrev: http://cr.openjdk.java.net/~dxu/8029007/webrev.01/. Thanks! Looks good to me Dan. -Chris. > > -Dan > > >> On 01/10/2014 10:21 AM, Mike Duigou wrote: >>> On Jan 10 2014, at 10:09 , Chris Hegarty wrote: >>> >>>> On 10 Jan 2014, at 18:05, Dan Xu wrote: >>>> >>>> Hi Roger, >>>> >>>> My macro is a little different from yours, which compares with -1 instead of NULL. I also see CHECK_EXCEPTION macro. Thanks for adding them, which are useful when I cannot decide the pending exception state by just using return values. >>>> >>>> As for the style, actually I prefer the (!pointer) to (pointer == NULL) because it is more concise and also make me avoid the typo like (pointer = NULL), which I cannot find from the compilation. Thanks! >> There's always "yoda conditions" https://en.wikipedia.org/wiki/Yoda_conditions, (NULL == pointer), but that's not likely to make anyone (besides me) happy. >> >> Mike >> >>> Not that it matters, but my preference is to == NULL. >>> >>> -Chris. >>> >>>> -Dan >>>> >>>> >>>> On 01/10/2014 08:40 AM, roger riggs wrote: >>>>> Hi Dan, >>>>> >>>>> Just pushed are macros in jni_util.h to do the same function as your new macros. >>>>> Please update to use the common macros instead of introducing new ones. >>>>> >>>>> Style wise, I would avoid mixing binary operators (!) with pointers. >>>>> it is clearer to compare with NULL. (The CHECK_NULL macro will do the check and return). >>>>> >>>>> (Not a Reviewer) >>>>> >>>>> Thanks, Roger >>>>> >>>>> >>>>> >>>>> On 1/10/2014 1:31 AM, Dan Xu wrote: >>>>>> Hi All, >>>>>> >>>>>> Please review the fix for JNI pending exception issues reported in jdk-8029007. Thanks! >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~dxu/8029007/webrev.00/ >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8029007 >>>>>> >>>>>> -Dan > From peter.levart at gmail.com Sat Jan 11 14:15:29 2014 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 11 Jan 2014 15:15:29 +0100 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52D06B70.60001@oracle.com> References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> <52CC72AB.2020104@oracle.com> <52CCEDE0.8000809@oracle.com> <52CCF079.4090301@oracle.com> <52CD45E7.7010203@gmail.com> <52CE4E2D.300@oracle.com> <52CF37C6.1070605@oracle.com> <52CFAFEB.9090703@gmail.com> <52CFD218.2060101@gmail.com> <52D06B70.60001@oracle.com> Message-ID: <52D15201.90109@gmail.com> On 01/10/2014 10:51 PM, srikalyan chandrashekar wrote: > Hi Peter the version you provided ran indefinitely(i put a 10 minute > timeout) and the program got interrupted(no error), Did you run it with or without fastedbug & -XX:+TraceExceptions ? If with, it might be that fastdebug and/or -XX:+TraceExceptions changes the execution a bit so that we can no longer reproduce the wrong behaviour. > even if there were to be an error you cannot print the "string" of > thread to console(these have been attempted earlier). ...it has been attempted to print toString in uncaught exception handler. At that time, the heap is still full. I'm printing it after the GC has cleared the heap. You can try that it works by commenting out the "try {" and corresponding "} catch (OOME x) {}" exception handler... > - The test's running on interpreter mode, what i am watching for is > one error with trace. Without fastdebug build and -XX:+TraceExceptions > i am able to reproduce failure atleast 5 failures out of 1000 runs but > with fastdebug+Trace no luck yet(already past few 1000 runs). It might be interesting to try with fastebug build but without the -XX:+TraceExceptions option to see what has an effect on it. It might also be interesting to try the modified ReferenceHandler (the one with private runImpl() method called from run()) and with normal non-fastdebug JDK. This info might be useful when one starts to inspect the exception handling code in interpreter... Regards, Peter > > --- > Thanks > kalyan > > On 01/10/2014 02:57 AM, Peter Levart wrote: >> On 01/10/2014 09:31 AM, Peter Levart wrote: >>> Since we suspect there's something wrong with exception handling in >>> interpreter, I devised a hypothetical reproducer that tries to >>> simulate ReferenceHandler in many aspects, but doesn't require to be >>> a ReferenceHandler: >>> >>> http://cr.openjdk.java.net/~plevart/misc/OOME/OOMECatchingTest.java >>> >>> This is designed to run indefinitely and only terminate if/when >>> thread dies. Could you run this program in the environment that >>> causes the OOMEInReferenceHandler test to fail and see if it >>> terminates? >> >> I forgot to mention that in order for this long-running program to >> exhibit interpreter behaviour, it should be run with -Xint option. So >> I suggest: >> >> -Xmx24M -XX:-UseTLAB -Xint >> >> Regards, Peter >> > From Alan.Bateman at oracle.com Sat Jan 11 16:25:22 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 11 Jan 2014 16:25:22 +0000 Subject: 8031494: [launcher] java launcher should check for JNI Pending exceptions. In-Reply-To: <52D0968F.6090702@oracle.com> References: <52D0968F.6090702@oracle.com> Message-ID: <52D17072.3020602@oracle.com> On 11/01/2014 00:55, Kumar Srinivasan wrote: > Hi, > > Please review fixes for launcher correctness wrt. JNI calls. > > http://cr.openjdk.java.net/~ksrini/8031494/webrev.0/ Looks okay, the only thing that isn't clear is whether the calls to the static methods defined by the launcher helper class can complete with an exception or not. -Alan From Alan.Bateman at oracle.com Sat Jan 11 16:41:11 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 11 Jan 2014 16:41:11 +0000 Subject: Request for approval for bug #8031488 In-Reply-To: <41ECA632-F6A6-45DD-B9AB-6DEC3D9A9565@oracle.com> References: <49A6E316-0B59-4E17-B171-93FC7E98E79B@oracle.com> <5D15DDF1-421C-4A80-9A42-A5D408BD7838@oracle.com> <52D0092B.5@oracle.com> <52D01363.8010504@oracle.com> <41ECA632-F6A6-45DD-B9AB-6DEC3D9A9565@oracle.com> Message-ID: <52D17427.8020509@oracle.com> On 10/01/2014 16:28, Iaroslav Savytskyi wrote: > : > There are 3 possibilities: > 1) Because it was my own initiative to fix this potential synchronization bug and nobody didn?t report it, we can approve my fix and leave this 2 classes without synchronized getters. And fix it in MR. > 2) Fix it as you propose. But later we will definitely need to change it again to volatile for performance reasons. > 3) Leave classes with volatile as they are now. And only add SUID to TypeConstraintException class. > I know this is a blocker for JDK 8 and I don't want to waste time debating the options. So I think #1 or #2 are okay (with a slight prefer for #2 because it doesn't require bring back the original bug in JAXBException). #3 is of course the best but from the previous mails then I thought this wasn't an option. So you choose and one of us will help you get this in. -Alan. From tristan.yan at oracle.com Mon Jan 13 06:21:05 2014 From: tristan.yan at oracle.com (Tristan Yan) Date: Mon, 13 Jan 2014 14:21:05 +0800 Subject: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm In-Reply-To: <52CF2EA3.9060504@oracle.com> References: <52CBA203.7080706@oracle.com> <52CBA851.8070008@oracle.com> <52CBB7C0.1040002@oracle.com> <52CBC66B.7000003@oracle.com> <52CBD8B7.8050002@oracle.com> <52CBE530.6070105@oracle.com> <52CE7171.1080407@oracle.com> <2BD1713F-655F-429A-9FC0-A14832D32C9D@oracle.com> <52CE8307.6040606@oracle.com> <52CE87A0.90504@oracle.com> <52CE92B4.4020009@oracle.com> <52CF2438.4090604@oracle.com> <52CF2EA3.9060504@oracle.com> Message-ID: <52D385D1.9020604@oracle.com> Hi All I add more trace output to track down possible reason of this failure. Please help to review it again. http://cr.openjdk.java.net/~tyan/JDK-7027502/webrev.05/ Thank you Tristan On 01/10/2014 07:20 AM, Tristan Yan wrote: > Hi David > I wasn't able to reproduce this failure either in local or in our same > binaries running(This is a continuous running with same JDK binaries). > So intention for this code change is bringing this test back; add > some debug info and try to avoid possible issues in this test. I agree > this code change won't solve the failure happened. But this test was > put into ProblemList two years ago better move for this is move out it > from ProblemList and trace down the issue in our normal nightly. > Thank you > Tristan > > On 01/10/2014 06:35 AM, David Holmes wrote: >> On 9/01/2014 10:14 PM, Alan Bateman wrote: >>> On 09/01/2014 11:27, David Holmes wrote: >>>> >>>> Okay I think I get it now. Both MonitorTest and WaitersTest use the >>>> Context class, so if both tests run in the same VM the second test >>>> will see the static total_turns_taken and "turn" in the state they >>>> were left from the first test - hence the second test will always >>>> fail. The bug report suggests making the tests othervm to avoid the >>>> problem but instead you have changed from using static state to >>>> instance state so that there is no interference. >>> I haven't been following this one closely but I thought that jtreg >>> created a class loader for each test (irrespective of mode) so I >>> wouldn't expect statics to be an issue. >> >> That aside DemoRun forks off its own JVM to run a given test anyway! >> >> So I don't understand how the proposed fixes could actually be >> addressing the hangs that are occurring. Even if the statics were >> being shared I don't see how that leads to the failure mode in the >> bug report. >> >> David >> >>> -Alan. > From staffan.larsen at oracle.com Mon Jan 13 09:08:46 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 13 Jan 2014 10:08:46 +0100 Subject: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm In-Reply-To: <52D385D1.9020604@oracle.com> References: <52CBA203.7080706@oracle.com> <52CBA851.8070008@oracle.com> <52CBB7C0.1040002@oracle.com> <52CBC66B.7000003@oracle.com> <52CBD8B7.8050002@oracle.com> <52CBE530.6070105@oracle.com> <52CE7171.1080407@oracle.com> <2BD1713F-655F-429A-9FC0-A14832D32C9D@oracle.com> <52CE8307.6040606@oracle.com> <52CE87A0.90504@oracle.com> <52CE92B4.4020009@oracle.com> <52CF2438.4090604@oracle.com> <52CF2EA3.9060504@oracle.com> <52D385D1.9020604@oracle.com> Message-ID: <4EBB6830-61A8-42E9-A25C-C26E06AA6CBC@oracle.com> Looks good! Thanks, /Staffan On 13 jan 2014, at 07:21, Tristan Yan wrote: > Hi All > I add more trace output to track down possible reason of this failure. Please help to review it again. > > http://cr.openjdk.java.net/~tyan/JDK-7027502/webrev.05/ > Thank you > Tristan > > On 01/10/2014 07:20 AM, Tristan Yan wrote: >> Hi David >> I wasn't able to reproduce this failure either in local or in our same binaries running(This is a continuous running with same JDK binaries). So intention for this code change is bringing this test back; add some debug info and try to avoid possible issues in this test. I agree this code change won't solve the failure happened. But this test was put into ProblemList two years ago better move for this is move out it from ProblemList and trace down the issue in our normal nightly. >> Thank you >> Tristan >> >> On 01/10/2014 06:35 AM, David Holmes wrote: >>> On 9/01/2014 10:14 PM, Alan Bateman wrote: >>>> On 09/01/2014 11:27, David Holmes wrote: >>>>> >>>>> Okay I think I get it now. Both MonitorTest and WaitersTest use the >>>>> Context class, so if both tests run in the same VM the second test >>>>> will see the static total_turns_taken and "turn" in the state they >>>>> were left from the first test - hence the second test will always >>>>> fail. The bug report suggests making the tests othervm to avoid the >>>>> problem but instead you have changed from using static state to >>>>> instance state so that there is no interference. >>>> I haven't been following this one closely but I thought that jtreg >>>> created a class loader for each test (irrespective of mode) so I >>>> wouldn't expect statics to be an issue. >>> >>> That aside DemoRun forks off its own JVM to run a given test anyway! >>> >>> So I don't understand how the proposed fixes could actually be addressing the hangs that are occurring. Even if the statics were being shared I don't see how that leads to the failure mode in the bug report. >>> >>> David >>> >>>> -Alan. >> > From paul.sandoz at oracle.com Mon Jan 13 11:19:38 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 13 Jan 2014 12:19:38 +0100 Subject: RFR 8030848: Collections.sort(List l, Comparator) should defer to List.sort(Comparator ) In-Reply-To: <62CA56D8-F360-46C3-9B06-888634F73DB6@oracle.com> References: <62CA56D8-F360-46C3-9B06-888634F73DB6@oracle.com> Message-ID: <4DB22EE1-39B1-4992-A1A8-4AF1A44F127C@oracle.com> On Jan 10, 2014, at 6:56 PM, Mike Duigou wrote: > The implementation looks good. I would move construction of the listIterator to before the toArray() for detection of concurrent modification (growing of the list). > If there is another thread concurrently operating on a non-current list during invocation of the sort method then it's gonna produce weird results, and any concurrent-like list should be overriding this impl and locking the sort (e.g. COWAL). For single threaded execution i suppose the Comparator could monkey around with the list, it's a long shot but is that what you are getting at? Paul. > I believe we should fix this for 8 if possible. > > Mike From paul.sandoz at oracle.com Mon Jan 13 13:39:21 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 13 Jan 2014 14:39:21 +0100 Subject: Doc updates Re: RFR 8030848: Collections.sort(List l, Comparator) should defer to List.sort(Comparator ) In-Reply-To: <52CFFD37.7050603@oracle.com> References: <52CFFD37.7050603@oracle.com> Message-ID: <958A34DB-EA57-4A1D-8744-4C7DBADD7F5D@oracle.com> On Jan 10, 2014, at 3:01 PM, Alan Bateman wrote: > The implementation changes look good. I agree that the javadoc needs changing as it's otherwise misleading as to what the implementation actually does. I would think that this should go with the implementation change rather than as a separate change. > See here for patch layered on top of code changes (to be folded after review into one patch): http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8030848-Collections-sort-docs/webrev/ Paul. From iaroslav.savytskyi at oracle.com Mon Jan 13 15:00:48 2014 From: iaroslav.savytskyi at oracle.com (Iaroslav Savytskyi) Date: Mon, 13 Jan 2014 16:00:48 +0100 Subject: Review request for JDK-8027908 In-Reply-To: <52D17427.8020509@oracle.com> References: <49A6E316-0B59-4E17-B171-93FC7E98E79B@oracle.com> <5D15DDF1-421C-4A80-9A42-A5D408BD7838@oracle.com> <52D0092B.5@oracle.com> <52D01363.8010504@oracle.com> <41ECA632-F6A6-45DD-B9AB-6DEC3D9A9565@oracle.com> <52D17427.8020509@oracle.com> Message-ID: Hi, I have created new fix version for https://bugs.openjdk.java.net/browse/JDK-8027908 Fix: From the previous discussion I?ve choosen 3rd option - to add SUID. Webrev: http://cr.openjdk.java.net/~mkos/8027908/webrev.01/ Thanks. ? Best regards, Iaroslav On 11 Jan 2014, at 17:41, Alan Bateman wrote: > On 10/01/2014 16:28, Iaroslav Savytskyi wrote: >> : >> There are 3 possibilities: >> 1) Because it was my own initiative to fix this potential synchronization bug and nobody didn?t report it, we can approve my fix and leave this 2 classes without synchronized getters. And fix it in MR. >> 2) Fix it as you propose. But later we will definitely need to change it again to volatile for performance reasons. >> 3) Leave classes with volatile as they are now. And only add SUID to TypeConstraintException class. >> > I know this is a blocker for JDK 8 and I don't want to waste time debating the options. So I think #1 or #2 are okay (with a slight prefer for #2 because it doesn't require bring back the original bug in JAXBException). > > #3 is of course the best but from the previous mails then I thought this wasn't an option. > > So you choose and one of us will help you get this in. > > -Alan. From Alan.Bateman at oracle.com Mon Jan 13 15:29:09 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 13 Jan 2014 15:29:09 +0000 Subject: Review request for JDK-8027908 In-Reply-To: References: <49A6E316-0B59-4E17-B171-93FC7E98E79B@oracle.com> <5D15DDF1-421C-4A80-9A42-A5D408BD7838@oracle.com> <52D0092B.5@oracle.com> <52D01363.8010504@oracle.com> <41ECA632-F6A6-45DD-B9AB-6DEC3D9A9565@oracle.com> <52D17427.8020509@oracle.com> Message-ID: <52D40645.9020309@oracle.com> On 13/01/2014 15:00, Iaroslav Savytskyi wrote: > Hi, > > I have created new fix version for https://bugs.openjdk.java.net/browse/JDK-8027908 > > Fix: From the previous discussion I?ve choosen 3rd option - to add SUID. > > Webrev: > http://cr.openjdk.java.net/~mkos/8027908/webrev.01/ > > Good! Do you have a sponsor for this? If not then I don't mind pushing for you to get it out of the way. -Alan From kumar.x.srinivasan at oracle.com Mon Jan 13 16:18:08 2014 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Mon, 13 Jan 2014 08:18:08 -0800 Subject: 8031494: [launcher] java launcher should check for JNI Pending exceptions. In-Reply-To: <52D17072.3020602@oracle.com> References: <52D0968F.6090702@oracle.com> <52D17072.3020602@oracle.com> Message-ID: <52D411C0.206@oracle.com> Hi Alan, Chris, > On 11/01/2014 00:55, Kumar Srinivasan wrote: >> Hi, >> >> Please review fixes for launcher correctness wrt. JNI calls. >> >> http://cr.openjdk.java.net/~ksrini/8031494/webrev.0/ > Looks okay, the only thing that isn't clear is whether the calls to > the static methods defined by the launcher helper class can complete > with an exception or not. The launcher helpers call System.exit via the abort call, however while double checking this, I noticed a couple of spots that might need these checks. I will post another webrev. Kumar > > -Alan From alan.bateman at oracle.com Mon Jan 13 16:21:07 2014 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 13 Jan 2014 16:21:07 +0000 Subject: hg: jdk8/tl/jaxws: 8027908: serialVersionUID of javax.xml.bind.TypeConstraintException accidently changed Message-ID: <20140113162119.3F8986240B@hg.openjdk.java.net> Changeset: bd943bdbce05 Author: alanb Date: 2014-01-13 16:17 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/bd943bdbce05 8027908: serialVersionUID of javax.xml.bind.TypeConstraintException accidently changed Reviewed-by: alanb Contributed-by: iaroslav.savytskyi at oracle.com ! src/share/jaxws_classes/javax/xml/bind/TypeConstraintException.java From iaroslav.savytskyi at oracle.com Mon Jan 13 16:47:53 2014 From: iaroslav.savytskyi at oracle.com (Iaroslav Savytskyi) Date: Mon, 13 Jan 2014 17:47:53 +0100 Subject: Review request for JDK-8027908 In-Reply-To: <52D40645.9020309@oracle.com> References: <49A6E316-0B59-4E17-B171-93FC7E98E79B@oracle.com> <5D15DDF1-421C-4A80-9A42-A5D408BD7838@oracle.com> <52D0092B.5@oracle.com> <52D01363.8010504@oracle.com> <41ECA632-F6A6-45DD-B9AB-6DEC3D9A9565@oracle.com> <52D17427.8020509@oracle.com> <52D40645.9020309@oracle.com> Message-ID: Hi, Alan, Miroslav told me to send such text block. ??? 8027908: Serialization of the j.x.b.TypeConstraintException is incompatible starts from the jdk8b112 Reviewed-by: alanb Contributed-by: iaroslav.savytskyi at oracle.com ?? On 13 Jan 2014, at 16:29, Alan Bateman wrote: > On 13/01/2014 15:00, Iaroslav Savytskyi wrote: >> Hi, >> >> I have created new fix version for https://bugs.openjdk.java.net/browse/JDK-8027908 >> >> Fix: From the previous discussion I?ve choosen 3rd option - to add SUID. >> >> Webrev: >> http://cr.openjdk.java.net/~mkos/8027908/webrev.01/ >> >> > Good! > > Do you have a sponsor for this? If not then I don't mind pushing for you to get it out of the way. > > -Alan > > From kumar.x.srinivasan at oracle.com Mon Jan 13 22:44:46 2014 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Mon, 13 Jan 2014 14:44:46 -0800 Subject: 8031494: [launcher] java launcher should check for JNI Pending exceptions. In-Reply-To: <52D411C0.206@oracle.com> References: <52D0968F.6090702@oracle.com> <52D17072.3020602@oracle.com> <52D411C0.206@oracle.com> Message-ID: <52D46C5E.1030800@oracle.com> As for the launcher helper calls, they all call abort/System.exit and bale out, they are also guarded by ExceptionOccurred in the native-land. Here is the updated version: The delta webrev since the last reviewed changes: http://cr.openjdk.java.net/~ksrini/8031494/webrev.1/webrev.delta/index.html The full webrev: http://cr.openjdk.java.net/~ksrini/8031494/webrev.1/ Thanks for the review. Kumar > Hi Alan, Chris, > >> On 11/01/2014 00:55, Kumar Srinivasan wrote: >>> Hi, >>> >>> Please review fixes for launcher correctness wrt. JNI calls. >>> >>> http://cr.openjdk.java.net/~ksrini/8031494/webrev.0/ >> Looks okay, the only thing that isn't clear is whether the calls to >> the static methods defined by the launcher helper class can complete >> with an exception or not. > > The launcher helpers call System.exit via the abort call, however while > double checking this, I noticed a couple of spots that might need > these checks. I will post another webrev. > > Kumar > >> >> -Alan > From mandy.chung at oracle.com Mon Jan 13 23:02:39 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 13 Jan 2014 15:02:39 -0800 Subject: Review request for 6516909: (cl spec) ClassLoader.loadClass() clarification to indicate it shouldn't be used for array classes Message-ID: <52D4708F.8030703@oracle.com> Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/6516909/webrev.00/ This patch is to fix: 6516909: (cl spec) ClassLoader.loadClass() clarification to indicate it shouldn't be used for array classes 4932272: (cl) Remove declaration of the unused private method ClassLoader.defineClass0 In JDK 5, parameter checking of ClassLoader.loadClass and other methods was modified to validate if the given class name is a binary name. ClassLoader.loadClass cannot be used to load an array class; instead it should use Class.forName. This patch adds a sentence in the "Binary Name" section in the ClassLoader class description to clarify that. This patch also removes the "sun.lang.ClassLoader.allowArraySyntax" system property that was added in JDK 5 to allow existing code to workaround the incompatibility issue. It was disabled by default in JDK 6. It's over 7 years and it's time to remove it. Also remove the unused private ClassLoader.defineClass0. Mandy [1] http://www.oracle.com/technetwork/java/javase/compatibility-137462.html From mandy.chung at oracle.com Mon Jan 13 23:34:16 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 13 Jan 2014 15:34:16 -0800 Subject: 8031494: [launcher] java launcher should check for JNI Pending exceptions. In-Reply-To: <52D46C5E.1030800@oracle.com> References: <52D0968F.6090702@oracle.com> <52D17072.3020602@oracle.com> <52D411C0.206@oracle.com> <52D46C5E.1030800@oracle.com> Message-ID: <52D477F8.60505@oracle.com> On 1/13/2014 2:44 PM, Kumar Srinivasan wrote: > The full webrev: > http://cr.openjdk.java.net/~ksrini/8031494/webrev.1/ This looks good. Should it also check if there is any pending exception after the call to CallStaticVoidMethod that has no return value? It's fine with me if you want to follow up the calls to CallStaticVoidMethod in a separate bug. Mandy From srikalyan.chandrashekar at oracle.com Mon Jan 13 23:57:13 2014 From: srikalyan.chandrashekar at oracle.com (srikalyan) Date: Mon, 13 Jan 2014 15:57:13 -0800 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52D15201.90109@gmail.com> References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> <52CC72AB.2020104@oracle.com> <52CCEDE0.8000809@oracle.com> <52CCF079.4090301@oracle.com> <52CD45E7.7010203@gmail.com> <52CE4E2D.300@oracle.com> <52CF37C6.1070605@oracle.com> <52CFAFEB.9090703@gmail.com> <52CFD218.2060101@gmail.com> <52D06B70.60001@oracle.com> <52D15201.90109@gmail.com> Message-ID: <52D47D59.8040905@oracle.com> On 1/11/14, 6:15 AM, Peter Levart wrote: > > On 01/10/2014 10:51 PM, srikalyan chandrashekar wrote: >> Hi Peter the version you provided ran indefinitely(i put a 10 minute >> timeout) and the program got interrupted(no error), > > Did you run it with or without fastedbug & -XX:+TraceExceptions ? If > with, it might be that fastdebug and/or -XX:+TraceExceptions changes > the execution a bit so that we can no longer reproduce the wrong > behaviour. With fastdebug & -XX:TraceExceptions. I will try combination of possible options(i.e without -XX:TraceEception on debug build etc) soon. > >> even if there were to be an error you cannot print the "string" of >> thread to console(these have been attempted earlier). > > ...it has been attempted to print toString in uncaught exception > handler. At that time, the heap is still full. I'm printing it after > the GC has cleared the heap. You can try that it works by commenting > out the "try {" and corresponding "} catch (OOME x) {}" exception > handler... Since there is a GC call prior to printing string i will give that a shot with non-debug build. > >> - The test's running on interpreter mode, what i am watching for is >> one error with trace. Without fastdebug build and >> -XX:+TraceExceptions i am able to reproduce failure atleast 5 >> failures out of 1000 runs but with fastdebug+Trace no luck >> yet(already past few 1000 runs). > > It might be interesting to try with fastebug build but without the > -XX:+TraceExceptions option to see what has an effect on it. It might > also be interesting to try the modified ReferenceHandler (the one with > private runImpl() method called from run()) and with normal > non-fastdebug JDK. This info might be useful when one starts to > inspect the exception handling code in interpreter... > > Regards, Peter > -- Thanks kalyan Ph: (408)-585-8040 >> >> --- >> Thanks >> kalyan >> >> On 01/10/2014 02:57 AM, Peter Levart wrote: >>> On 01/10/2014 09:31 AM, Peter Levart wrote: >>>> Since we suspect there's something wrong with exception handling in >>>> interpreter, I devised a hypothetical reproducer that tries to >>>> simulate ReferenceHandler in many aspects, but doesn't require to >>>> be a ReferenceHandler: >>>> >>>> http://cr.openjdk.java.net/~plevart/misc/OOME/OOMECatchingTest.java >>>> >>>> This is designed to run indefinitely and only terminate if/when >>>> thread dies. Could you run this program in the environment that >>>> causes the OOMEInReferenceHandler test to fail and see if it >>>> terminates? >>> >>> I forgot to mention that in order for this long-running program to >>> exhibit interpreter behaviour, it should be run with -Xint option. >>> So I suggest: >>> >>> -Xmx24M -XX:-UseTLAB -Xint >>> >>> Regards, Peter >>> >> > From mark.reinhold at oracle.com Tue Jan 14 00:26:59 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 13 Jan 2014 16:26:59 -0800 (PST) Subject: JEP 187: Serialization 2.0 Message-ID: <20140114002659.6AC0BD7C2@eggemoggin.niobe.net> Posted: http://openjdk.java.net/jeps/187 - Mark From joe.darcy at oracle.com Tue Jan 14 01:11:20 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 13 Jan 2014 17:11:20 -0800 Subject: JDK 9 RFR of JDK-8031651: Remove unneeded -source and -target flags in jdk repo regression tests Message-ID: <52D48EB8.70009@oracle.com> Hello, Per the policy set forth in JEP 182: Policy for Retiring javac -source and -target Options http://openjdk.java.net/jeps/182 in JDK 9, javac will only recognize javac source and target value of 6/1.6 and higher. Therefore, uses of earlier options in the JDK regression tests need to be modified. Please review the first pass at fixing this before support for the old source and target values is removed: JDK-8031651 : Remove unneeded -source and -target flags in jdk repo regression tests http://cr.openjdk.java.net/~darcy/8031651.2/ Patch also below. A few comments on the changes. In java/security/cert/* the tests were intentionally creating a corrupted set to make sure it was rejected properly. Chris, do the changes in java/util/concurrent need to go into Doug's repo first? I had to wrestle a bit for the code in javax/imageio/metadata/GetObjectMinValue to make the generics work out. For test/java/util/Locale/Bug4175998Test.java, as of source 6, an encoding error, even in a comment is a javac error. Therefore, a non-ASCKII character is replaced by a Unicode escape. Kumar, the pack200 tests uses "-target 5"; can you look into updating this to target 6 or later? Thanks, -Joe --- old/test/demo/jvmti/hprof/StackMapTableTest.java 2014-01-13 16:54:09.000000000 -0800 +++ new/test/demo/jvmti/hprof/StackMapTableTest.java 2014-01-13 16:54:09.000000000 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2005, 2009, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2005, 2014, 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 @@ -27,7 +27,7 @@ * @summary Test jvmti hprof and java_crw_demo with StackMapTable attributes * * @compile ../DemoRun.java - * @compile -source 7 -g:lines HelloWorld.java + * @compile -g:lines HelloWorld.java * @build StackMapTableTest * @run main StackMapTableTest HelloWorld */ --- old/test/java/lang/reflect/OldenCompilingWithDefaults.java 2014-01-13 16:54:10.000000000 -0800 +++ new/test/java/lang/reflect/OldenCompilingWithDefaults.java 2014-01-13 16:54:10.000000000 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2013, 2014, 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 @@ -25,7 +25,6 @@ * @test * @bug 8009267 * @summary Verify uses of isAnnotationPresent compile under older source versions - * @compile -source 1.5 -target 1.5 OldenCompilingWithDefaults.java * @compile -source 1.6 -target 1.6 OldenCompilingWithDefaults.java * @compile -source 1.7 -target 1.7 OldenCompilingWithDefaults.java * @compile OldenCompilingWithDefaults.java --- old/test/java/security/cert/PKIXBuilderParameters/InvalidParameters.java 2014-01-13 16:54:10.000000000 -0800 +++ new/test/java/security/cert/PKIXBuilderParameters/InvalidParameters.java 2014-01-13 16:54:10.000000000 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2001, 2004, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2001, 2014, 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 @@ -21,16 +21,17 @@ * questions. */ -/** +/* * @test * @test 4422738 - * @compile -source 1.4 InvalidParameters.java + * @compile InvalidParameters.java * @run main InvalidParameters * @summary Make sure PKIXBuilderParameters(Set) detects invalid * parameters and throws correct exceptions */ import java.security.InvalidAlgorithmParameterException; import java.security.cert.PKIXBuilderParameters; +import java.security.cert.TrustAnchor; import java.util.Collections; import java.util.Set; @@ -53,8 +54,10 @@ // make sure Set of invalid objects throws ClassCastException try { + @SuppressWarnings("unchecked") // Knowingly do something bad + Set badSet = (Set) (Set) Collections.singleton(new String()); PKIXBuilderParameters p = - new PKIXBuilderParameters(Collections.singleton(new String()), null); + new PKIXBuilderParameters(badSet, null); throw new Exception("should have thrown ClassCastException"); } catch (ClassCastException cce) { } } --- old/test/java/security/cert/PKIXParameters/InvalidParameters.java 2014-01-13 16:54:11.000000000 -0800 +++ new/test/java/security/cert/PKIXParameters/InvalidParameters.java 2014-01-13 16:54:10.000000000 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2001, 2004, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2001, 2014, 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 @@ -24,7 +24,7 @@ /** * @test * @test 4422738 - * @compile -source 1.4 InvalidParameters.java + * @compile InvalidParameters.java * @run main InvalidParameters * @summary Make sure PKIXParameters(Set) and setTrustAnchors() detects invalid * parameters and throws correct exceptions @@ -64,12 +64,14 @@ } catch (NullPointerException npe) { } // make sure Set of invalid objects throws ClassCastException + @SuppressWarnings("unchecked") // Knowingly do something bad + Set badSet = (Set) (Set) Collections.singleton(new String()); try { - PKIXParameters p = new PKIXParameters(Collections.singleton(new String())); + PKIXParameters p = new PKIXParameters(badSet); throw new Exception("should have thrown ClassCastException"); } catch (ClassCastException cce) { } try { - params.setTrustAnchors(Collections.singleton(new String())); + params.setTrustAnchors(badSet); throw new Exception("should have thrown ClassCastException"); } catch (ClassCastException cce) { } } --- old/test/java/util/Locale/Bug4175998Test.java 2014-01-13 16:54:11.000000000 -0800 +++ new/test/java/util/Locale/Bug4175998Test.java 2014-01-13 16:54:11.000000000 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2007, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2007, 2014, 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 @@ -20,13 +20,15 @@ * or visit www.oracle.com if you need additional information or have any * questions. */ + /* - @test - @summary test ISO639-2 language codes - @compile -encoding ascii -source 5 Bug4175998Test.java - @run main Bug4175998Test - @bug 4175998 -*/ + * @test + * @summary test ISO639-2 language codes + * @compile -encoding ascii Bug4175998Test.java + * @run main Bug4175998Test + * @bug 4175998 + */ + /* * * @@ -731,7 +733,7 @@ pon pon Pohnpeian por por Portuguese pra pra Prakrit languages -pro pro Proven?al, Old (to 1500) +pro pro Proven\u00E7al, Old (to 1500) pus pus Pushto qaa-qtz qaa-qtz Reserved for local use que que Quechua --- old/test/java/util/concurrent/BlockingQueue/CancelledProducerConsumerLoops.java 2014-01-13 16:54:12.000000000 -0800 +++ new/test/java/util/concurrent/BlockingQueue/CancelledProducerConsumerLoops.java 2014-01-13 16:54:11.000000000 -0800 @@ -34,7 +34,7 @@ /* * @test * @bug 4486658 - * @compile -source 1.5 CancelledProducerConsumerLoops.java + * @compile CancelledProducerConsumerLoops.java * @run main/timeout=7000 CancelledProducerConsumerLoops * @summary Checks for responsiveness of blocking queues to cancellation. * Runs under the assumption that ITERS computations require more than --- old/test/java/util/concurrent/BlockingQueue/MultipleProducersSingleConsumerLoops.java 2014-01-13 16:54:12.000000000 -0800 +++ new/test/java/util/concurrent/BlockingQueue/MultipleProducersSingleConsumerLoops.java 2014-01-13 16:54:12.000000000 -0800 @@ -34,7 +34,7 @@ /* * @test * @bug 4486658 - * @compile -source 1.5 MultipleProducersSingleConsumerLoops.java + * @compile MultipleProducersSingleConsumerLoops.java * @run main/timeout=3600 MultipleProducersSingleConsumerLoops * @summary multiple producers and single consumer using blocking queues */ --- old/test/java/util/concurrent/BlockingQueue/ProducerConsumerLoops.java 2014-01-13 16:54:12.000000000 -0800 +++ new/test/java/util/concurrent/BlockingQueue/ProducerConsumerLoops.java 2014-01-13 16:54:12.000000000 -0800 @@ -34,7 +34,7 @@ /* * @test * @bug 4486658 - * @compile -source 1.5 ProducerConsumerLoops.java + * @compile ProducerConsumerLoops.java * @run main/timeout=3600 ProducerConsumerLoops * @summary multiple producers and consumers using blocking queues */ --- old/test/java/util/concurrent/BlockingQueue/SingleProducerMultipleConsumerLoops.java 2014-01-13 16:54:13.000000000 -0800 +++ new/test/java/util/concurrent/BlockingQueue/SingleProducerMultipleConsumerLoops.java 2014-01-13 16:54:13.000000000 -0800 @@ -34,7 +34,7 @@ /* * @test * @bug 4486658 - * @compile -source 1.5 SingleProducerMultipleConsumerLoops.java + * @compile SingleProducerMultipleConsumerLoops.java * @run main/timeout=600 SingleProducerMultipleConsumerLoops * @summary check ordering for blocking queues with 1 producer and multiple consumers */ --- old/test/java/util/concurrent/ConcurrentHashMap/MapCheck.java 2014-01-13 16:54:14.000000000 -0800 +++ new/test/java/util/concurrent/ConcurrentHashMap/MapCheck.java 2014-01-13 16:54:13.000000000 -0800 @@ -34,7 +34,7 @@ /* * @test * @bug 4486658 - * @compile -source 1.5 MapCheck.java + * @compile MapCheck.java * @run main/timeout=240 MapCheck * @summary Times and checks basic map operations */ --- old/test/java/util/concurrent/ConcurrentHashMap/MapLoops.java 2014-01-13 16:54:14.000000000 -0800 +++ new/test/java/util/concurrent/ConcurrentHashMap/MapLoops.java 2014-01-13 16:54:14.000000000 -0800 @@ -34,7 +34,7 @@ /* * @test * @bug 4486658 - * @compile -source 1.5 MapLoops.java + * @compile MapLoops.java * @run main/timeout=1600 MapLoops * @summary Exercise multithreaded maps, by default ConcurrentHashMap. * Multithreaded hash table test. Each thread does a random walk --- old/test/java/util/concurrent/Exchanger/ExchangeLoops.java 2014-01-13 16:54:15.000000000 -0800 +++ new/test/java/util/concurrent/Exchanger/ExchangeLoops.java 2014-01-13 16:54:14.000000000 -0800 @@ -34,7 +34,7 @@ /* * @test * @bug 4486658 - * @compile -source 1.5 ExchangeLoops.java + * @compile ExchangeLoops.java * @run main/timeout=720 ExchangeLoops * @summary checks to make sure a pipeline of exchangers passes data. */ --- old/test/java/util/concurrent/ExecutorCompletionService/ExecutorCompletionServiceLoops.java 2014-01-13 16:54:15.000000000 -0800 +++ new/test/java/util/concurrent/ExecutorCompletionService/ExecutorCompletionServiceLoops.java 2014-01-13 16:54:15.000000000 -0800 @@ -34,7 +34,7 @@ /* * @test * @bug 4965960 - * @compile -source 1.5 ExecutorCompletionServiceLoops.java + * @compile ExecutorCompletionServiceLoops.java * @run main/timeout=3600 ExecutorCompletionServiceLoops * @summary Exercise ExecutorCompletionServiceLoops */ --- old/test/java/util/concurrent/FutureTask/CancelledFutureLoops.java 2014-01-13 16:54:16.000000000 -0800 +++ new/test/java/util/concurrent/FutureTask/CancelledFutureLoops.java 2014-01-13 16:54:15.000000000 -0800 @@ -34,7 +34,7 @@ /* * @test * @bug 4486658 - * @compile -source 1.5 CancelledFutureLoops.java + * @compile CancelledFutureLoops.java * @run main/timeout=2000 CancelledFutureLoops * @summary Checks for responsiveness of futures to cancellation. * Runs under the assumption that ITERS computations require more than --- old/test/java/util/concurrent/atomic/VMSupportsCS8.java 2014-01-13 16:54:16.000000000 -0800 +++ new/test/java/util/concurrent/atomic/VMSupportsCS8.java 2014-01-13 16:54:16.000000000 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2004, 2010, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2004, 2014, 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 @@ -24,7 +24,7 @@ /* * @test * @bug 4992443 4994819 - * @compile -source 1.5 VMSupportsCS8.java + * @compile VMSupportsCS8.java * @run main VMSupportsCS8 * @summary Checks that the value of VMSupportsCS8 matches system properties. */ --- old/test/java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java 2014-01-13 16:54:16.000000000 -0800 +++ new/test/java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java 2014-01-13 16:54:16.000000000 -0800 @@ -34,7 +34,7 @@ /* * @test * @bug 4486658 - * @compile -source 1.5 CancelledLockLoops.java + * @compile CancelledLockLoops.java * @run main/timeout=2800 CancelledLockLoops * @summary tests lockInterruptibly. * Checks for responsiveness of locks to interrupts. Runs under that --- old/test/java/util/concurrent/locks/ReentrantLock/LockOncePerThreadLoops.java 2014-01-13 16:54:17.000000000 -0800 +++ new/test/java/util/concurrent/locks/ReentrantLock/LockOncePerThreadLoops.java 2014-01-13 16:54:17.000000000 -0800 @@ -34,7 +34,7 @@ /* * @test * @bug 4486658 - * @compile -source 1.5 LockOncePerThreadLoops.java + * @compile LockOncePerThreadLoops.java * @run main/timeout=15000 LockOncePerThreadLoops * @summary Checks for missed signals by locking and unlocking each of an array of locks once per thread */ --- old/test/java/util/concurrent/locks/ReentrantLock/SimpleReentrantLockLoops.java 2014-01-13 16:54:17.000000000 -0800 +++ new/test/java/util/concurrent/locks/ReentrantLock/SimpleReentrantLockLoops.java 2014-01-13 16:54:17.000000000 -0800 @@ -34,7 +34,7 @@ /* * @test * @bug 4486658 - * @compile -source 1.5 SimpleReentrantLockLoops.java + * @compile SimpleReentrantLockLoops.java * @run main/timeout=4500 SimpleReentrantLockLoops * @summary multiple threads using a single lock */ --- old/test/java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java 2014-01-13 16:54:18.000000000 -0800 +++ new/test/java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java 2014-01-13 16:54:17.000000000 -0800 @@ -34,7 +34,7 @@ /* * @test * @bug 4486658 5031862 - * @compile -source 1.5 TimeoutLockLoops.java + * @compile TimeoutLockLoops.java * @run main TimeoutLockLoops * @summary Checks for responsiveness of locks to timeouts. * Runs under the assumption that ITERS computations require more than --- old/test/java/util/concurrent/locks/ReentrantReadWriteLock/MapLoops.java 2014-01-13 16:54:18.000000000 -0800 +++ new/test/java/util/concurrent/locks/ReentrantReadWriteLock/MapLoops.java 2014-01-13 16:54:18.000000000 -0800 @@ -34,7 +34,7 @@ /* * @test * @bug 4486658 - * @compile -source 1.5 MapLoops.java + * @compile MapLoops.java * @run main/timeout=4700 MapLoops * @summary Exercise multithreaded maps, by default ConcurrentHashMap. * Multithreaded hash table test. Each thread does a random walk --- old/test/javax/imageio/metadata/GetObjectMinValue.java 2014-01-13 16:54:20.000000000 -0800 +++ new/test/javax/imageio/metadata/GetObjectMinValue.java 2014-01-13 16:54:19.000000000 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2012, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2012, 2014, 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 @@ -24,14 +24,12 @@ /* * @test * @bug 4429875 7186799 - * @compile -source 1.4 GetObjectMinValue.java + * @compile GetObjectMinValue.java * @run main GetObjectMinValue * @summary Tests the getObject{Min,Max}Value method of * IIOMetadataFormatImpl for an inclusive range */ -// Compiled with -source 1.4 to work around javac bug 5041233 - import javax.imageio.metadata.IIOMetadataFormatImpl; import javax.imageio.ImageTypeSpecifier; @@ -79,13 +77,13 @@ } public void addObjectValue(String elementName, - Class classType, Object defaultValue, + Class classType, Integer defaultValue, Comparable minValue, Comparable maxValue, boolean minInclusive, boolean maxInclusive) { - super.addObjectValue(elementName, - classType, defaultValue, - minValue, maxValue, - minInclusive, maxInclusive); + super.addObjectValue(elementName, + (Class)classType, defaultValue, + (Comparable) minValue, (Comparable) maxValue, + minInclusive, maxInclusive); } public boolean canNodeAppear(String elementName, --- old/test/javax/sound/midi/MidiDeviceConnectors/TestAllDevices.java 2014-01-13 16:54:20.000000000 -0800 +++ new/test/javax/sound/midi/MidiDeviceConnectors/TestAllDevices.java 2014-01-13 16:54:20.000000000 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2010, 2014, 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 @@ -25,7 +25,7 @@ * @test * @bug 4933700 * @summary Tests that default devices return MidiDeviceTransmitter/Receiver and returned objects return correct MidiDevice - * @compile -source 1.7 TestAllDevices.java + * @compile TestAllDevices.java * @run main TestAllDevices * @author Alex Menkov */ --- old/test/javax/sound/sampled/AudioFormat/PCM_FLOAT_support.java 2014-01-13 16:54:20.000000000 -0800 +++ new/test/javax/sound/sampled/AudioFormat/PCM_FLOAT_support.java 2014-01-13 16:54:20.000000000 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2010, 2014, 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 @@ -25,7 +25,7 @@ * @test * @bug 6944033 * @summary Tests that PCM_FLOAT encoding is supported - * @compile -source 1.7 PCM_FLOAT_support.java + * @compile PCM_FLOAT_support.java * @run main PCM_FLOAT_support * @author Alex Menkov * --- old/test/sun/management/jmxremote/LocalRMIServerSocketFactoryTest.java 2014-01-13 16:54:21.000000000 -0800 +++ new/test/sun/management/jmxremote/LocalRMIServerSocketFactoryTest.java 2014-01-13 16:54:21.000000000 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2008, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2008, 2014, 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 @@ -28,7 +28,7 @@ * * @author Daniel Fuchs * - * @run compile -XDignore.symbol.file=true -source 1.6 -g LocalRMIServerSocketFactoryTest.java + * @run compile -XDignore.symbol.file=true -g LocalRMIServerSocketFactoryTest.java * @run main LocalRMIServerSocketFactoryTest */ From martinrb at google.com Tue Jan 14 02:30:50 2014 From: martinrb at google.com (Martin Buchholz) Date: Mon, 13 Jan 2014 18:30:50 -0800 Subject: JDK 9 RFR of JDK-8031651: Remove unneeded -source and -target flags in jdk repo regression tests In-Reply-To: <52D48EB8.70009@oracle.com> References: <52D48EB8.70009@oracle.com> Message-ID: All occurrences of @compile -source 1.5 have been removed from jsr166 CVS. On Mon, Jan 13, 2014 at 5:11 PM, Joe Darcy wrote: > Hello, > > Per the policy set forth in > > JEP 182: Policy for Retiring javac -source and -target Options > http://openjdk.java.net/jeps/182 > > in JDK 9, javac will only recognize javac source and target value of 6/1.6 > and higher. Therefore, uses of earlier options in the JDK regression tests > need to be modified. > > Please review the first pass at fixing this before support for the old > source and target values is removed: > > JDK-8031651 : Remove unneeded -source and -target flags in jdk repo > regression tests > http://cr.openjdk.java.net/~darcy/8031651.2/ > > Patch also below. > > A few comments on the changes. In java/security/cert/* the tests were > intentionally creating a corrupted set to make sure it was rejected > properly. > > Chris, do the changes in java/util/concurrent need to go into Doug's repo > first? > > I had to wrestle a bit for the code in javax/imageio/metadata/GetObjectMinValue > to make the generics work out. > > For test/java/util/Locale/Bug4175998Test.java, as of source 6, an > encoding error, even in a comment is a javac error. Therefore, a non-ASCKII > character is replaced by a Unicode escape. > > Kumar, the pack200 tests uses "-target 5"; can you look into updating this > to target 6 or later? > > Thanks, > > -Joe > > --- old/test/demo/jvmti/hprof/StackMapTableTest.java 2014-01-13 > 16:54:09.000000000 -0800 > +++ new/test/demo/jvmti/hprof/StackMapTableTest.java 2014-01-13 > 16:54:09.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2005, 2009, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2005, 2014, 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 > @@ -27,7 +27,7 @@ > * @summary Test jvmti hprof and java_crw_demo with StackMapTable > attributes > * > * @compile ../DemoRun.java > - * @compile -source 7 -g:lines HelloWorld.java > + * @compile -g:lines HelloWorld.java > * @build StackMapTableTest > * @run main StackMapTableTest HelloWorld > */ > --- old/test/java/lang/reflect/OldenCompilingWithDefaults.java 2014-01-13 > 16:54:10.000000000 -0800 > +++ new/test/java/lang/reflect/OldenCompilingWithDefaults.java 2014-01-13 > 16:54:10.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2013, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2013, 2014, 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 > @@ -25,7 +25,6 @@ > * @test > * @bug 8009267 > * @summary Verify uses of isAnnotationPresent compile under older source > versions > - * @compile -source 1.5 -target 1.5 OldenCompilingWithDefaults.java > * @compile -source 1.6 -target 1.6 OldenCompilingWithDefaults.java > * @compile -source 1.7 -target 1.7 OldenCompilingWithDefaults.java > * @compile OldenCompilingWithDefaults.java > --- old/test/java/security/cert/PKIXBuilderParameters/InvalidParameters.java > 2014-01-13 16:54:10.000000000 -0800 > +++ new/test/java/security/cert/PKIXBuilderParameters/InvalidParameters.java > 2014-01-13 16:54:10.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2001, 2004, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2001, 2014, 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 > @@ -21,16 +21,17 @@ > * questions. > */ > > -/** > +/* > * @test > * @test 4422738 > - * @compile -source 1.4 InvalidParameters.java > + * @compile InvalidParameters.java > * @run main InvalidParameters > * @summary Make sure PKIXBuilderParameters(Set) detects invalid > * parameters and throws correct exceptions > */ > import java.security.InvalidAlgorithmParameterException; > import java.security.cert.PKIXBuilderParameters; > +import java.security.cert.TrustAnchor; > import java.util.Collections; > import java.util.Set; > > @@ -53,8 +54,10 @@ > > // make sure Set of invalid objects throws ClassCastException > try { > + @SuppressWarnings("unchecked") // Knowingly do something bad > + Set badSet = (Set) (Set) > Collections.singleton(new String()); > PKIXBuilderParameters p = > - new PKIXBuilderParameters(Collections.singleton(new > String()), null); > + new PKIXBuilderParameters(badSet, null); > throw new Exception("should have thrown ClassCastException"); > } catch (ClassCastException cce) { } > } > --- old/test/java/security/cert/PKIXParameters/InvalidParameters.java > 2014-01-13 16:54:11.000000000 -0800 > +++ new/test/java/security/cert/PKIXParameters/InvalidParameters.java > 2014-01-13 16:54:10.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2001, 2004, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2001, 2014, 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 > @@ -24,7 +24,7 @@ > /** > * @test > * @test 4422738 > - * @compile -source 1.4 InvalidParameters.java > + * @compile InvalidParameters.java > * @run main InvalidParameters > * @summary Make sure PKIXParameters(Set) and setTrustAnchors() detects > invalid > * parameters and throws correct exceptions > @@ -64,12 +64,14 @@ > } catch (NullPointerException npe) { } > > // make sure Set of invalid objects throws ClassCastException > + @SuppressWarnings("unchecked") // Knowingly do something bad > + Set badSet = (Set) (Set) > Collections.singleton(new String()); > try { > - PKIXParameters p = new PKIXParameters(Collections.singleton(new > String())); > + PKIXParameters p = new PKIXParameters(badSet); > throw new Exception("should have thrown ClassCastException"); > } catch (ClassCastException cce) { } > try { > - params.setTrustAnchors(Collections.singleton(new String())); > + params.setTrustAnchors(badSet); > throw new Exception("should have thrown ClassCastException"); > } catch (ClassCastException cce) { } > } > --- old/test/java/util/Locale/Bug4175998Test.java 2014-01-13 > 16:54:11.000000000 -0800 > +++ new/test/java/util/Locale/Bug4175998Test.java 2014-01-13 > 16:54:11.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2007, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2007, 2014, 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 > @@ -20,13 +20,15 @@ > * or visit www.oracle.com if you need additional information or have any > * questions. > */ > + > /* > - @test > - @summary test ISO639-2 language codes > - @compile -encoding ascii -source 5 Bug4175998Test.java > - @run main Bug4175998Test > - @bug 4175998 > -*/ > + * @test > + * @summary test ISO639-2 language codes > + * @compile -encoding ascii Bug4175998Test.java > + * @run main Bug4175998Test > + * @bug 4175998 > + */ > + > /* > * > * > @@ -731,7 +733,7 @@ > pon pon Pohnpeian > por por Portuguese > pra pra Prakrit languages > -pro pro Proven?al, Old (to 1500) > +pro pro Proven\u00E7al, Old (to 1500) > pus pus Pushto > qaa-qtz qaa-qtz Reserved for local use > que que Quechua > --- old/test/java/util/concurrent/BlockingQueue/ > CancelledProducerConsumerLoops.java 2014-01-13 16:54:12.000000000 -0800 > +++ new/test/java/util/concurrent/BlockingQueue/ > CancelledProducerConsumerLoops.java 2014-01-13 16:54:11.000000000 -0800 > @@ -34,7 +34,7 @@ > /* > * @test > * @bug 4486658 > - * @compile -source 1.5 CancelledProducerConsumerLoops.java > + * @compile CancelledProducerConsumerLoops.java > * @run main/timeout=7000 CancelledProducerConsumerLoops > * @summary Checks for responsiveness of blocking queues to cancellation. > * Runs under the assumption that ITERS computations require more than > --- old/test/java/util/concurrent/BlockingQueue/ > MultipleProducersSingleConsumerLoops.java 2014-01-13 16:54:12.000000000 > -0800 > +++ new/test/java/util/concurrent/BlockingQueue/ > MultipleProducersSingleConsumerLoops.java 2014-01-13 16:54:12.000000000 > -0800 > @@ -34,7 +34,7 @@ > /* > * @test > * @bug 4486658 > - * @compile -source 1.5 MultipleProducersSingleConsumerLoops.java > + * @compile MultipleProducersSingleConsumerLoops.java > * @run main/timeout=3600 MultipleProducersSingleConsumerLoops > * @summary multiple producers and single consumer using blocking queues > */ > --- old/test/java/util/concurrent/BlockingQueue/ProducerConsumerLoops.java > 2014-01-13 16:54:12.000000000 -0800 > +++ new/test/java/util/concurrent/BlockingQueue/ProducerConsumerLoops.java > 2014-01-13 16:54:12.000000000 -0800 > @@ -34,7 +34,7 @@ > /* > * @test > * @bug 4486658 > - * @compile -source 1.5 ProducerConsumerLoops.java > + * @compile ProducerConsumerLoops.java > * @run main/timeout=3600 ProducerConsumerLoops > * @summary multiple producers and consumers using blocking queues > */ > --- old/test/java/util/concurrent/BlockingQueue/ > SingleProducerMultipleConsumerLoops.java 2014-01-13 16:54:13.000000000 > -0800 > +++ new/test/java/util/concurrent/BlockingQueue/ > SingleProducerMultipleConsumerLoops.java 2014-01-13 16:54:13.000000000 > -0800 > @@ -34,7 +34,7 @@ > /* > * @test > * @bug 4486658 > - * @compile -source 1.5 SingleProducerMultipleConsumerLoops.java > + * @compile SingleProducerMultipleConsumerLoops.java > * @run main/timeout=600 SingleProducerMultipleConsumerLoops > * @summary check ordering for blocking queues with 1 producer and > multiple consumers > */ > --- old/test/java/util/concurrent/ConcurrentHashMap/MapCheck.java > 2014-01-13 16:54:14.000000000 -0800 > +++ new/test/java/util/concurrent/ConcurrentHashMap/MapCheck.java > 2014-01-13 16:54:13.000000000 -0800 > @@ -34,7 +34,7 @@ > /* > * @test > * @bug 4486658 > - * @compile -source 1.5 MapCheck.java > + * @compile MapCheck.java > * @run main/timeout=240 MapCheck > * @summary Times and checks basic map operations > */ > --- old/test/java/util/concurrent/ConcurrentHashMap/MapLoops.java > 2014-01-13 16:54:14.000000000 -0800 > +++ new/test/java/util/concurrent/ConcurrentHashMap/MapLoops.java > 2014-01-13 16:54:14.000000000 -0800 > @@ -34,7 +34,7 @@ > /* > * @test > * @bug 4486658 > - * @compile -source 1.5 MapLoops.java > + * @compile MapLoops.java > * @run main/timeout=1600 MapLoops > * @summary Exercise multithreaded maps, by default ConcurrentHashMap. > * Multithreaded hash table test. Each thread does a random walk > --- old/test/java/util/concurrent/Exchanger/ExchangeLoops.java 2014-01-13 > 16:54:15.000000000 -0800 > +++ new/test/java/util/concurrent/Exchanger/ExchangeLoops.java 2014-01-13 > 16:54:14.000000000 -0800 > @@ -34,7 +34,7 @@ > /* > * @test > * @bug 4486658 > - * @compile -source 1.5 ExchangeLoops.java > + * @compile ExchangeLoops.java > * @run main/timeout=720 ExchangeLoops > * @summary checks to make sure a pipeline of exchangers passes data. > */ > --- old/test/java/util/concurrent/ExecutorCompletionService/ > ExecutorCompletionServiceLoops.java 2014-01-13 16:54:15.000000000 -0800 > +++ new/test/java/util/concurrent/ExecutorCompletionService/ > ExecutorCompletionServiceLoops.java 2014-01-13 16:54:15.000000000 -0800 > @@ -34,7 +34,7 @@ > /* > * @test > * @bug 4965960 > - * @compile -source 1.5 ExecutorCompletionServiceLoops.java > + * @compile ExecutorCompletionServiceLoops.java > * @run main/timeout=3600 ExecutorCompletionServiceLoops > * @summary Exercise ExecutorCompletionServiceLoops > */ > --- old/test/java/util/concurrent/FutureTask/CancelledFutureLoops.java > 2014-01-13 16:54:16.000000000 -0800 > +++ new/test/java/util/concurrent/FutureTask/CancelledFutureLoops.java > 2014-01-13 16:54:15.000000000 -0800 > @@ -34,7 +34,7 @@ > /* > * @test > * @bug 4486658 > - * @compile -source 1.5 CancelledFutureLoops.java > + * @compile CancelledFutureLoops.java > * @run main/timeout=2000 CancelledFutureLoops > * @summary Checks for responsiveness of futures to cancellation. > * Runs under the assumption that ITERS computations require more than > --- old/test/java/util/concurrent/atomic/VMSupportsCS8.java 2014-01-13 > 16:54:16.000000000 -0800 > +++ new/test/java/util/concurrent/atomic/VMSupportsCS8.java 2014-01-13 > 16:54:16.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2004, 2010, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2004, 2014, 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 > @@ -24,7 +24,7 @@ > /* > * @test > * @bug 4992443 4994819 > - * @compile -source 1.5 VMSupportsCS8.java > + * @compile VMSupportsCS8.java > * @run main VMSupportsCS8 > * @summary Checks that the value of VMSupportsCS8 matches system > properties. > */ > --- old/test/java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java > 2014-01-13 16:54:16.000000000 -0800 > +++ new/test/java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java > 2014-01-13 16:54:16.000000000 -0800 > @@ -34,7 +34,7 @@ > /* > * @test > * @bug 4486658 > - * @compile -source 1.5 CancelledLockLoops.java > + * @compile CancelledLockLoops.java > * @run main/timeout=2800 CancelledLockLoops > * @summary tests lockInterruptibly. > * Checks for responsiveness of locks to interrupts. Runs under that > --- old/test/java/util/concurrent/locks/ReentrantLock/LockOncePerThreadLoops.java > 2014-01-13 16:54:17.000000000 -0800 > +++ new/test/java/util/concurrent/locks/ReentrantLock/LockOncePerThreadLoops.java > 2014-01-13 16:54:17.000000000 -0800 > @@ -34,7 +34,7 @@ > /* > * @test > * @bug 4486658 > - * @compile -source 1.5 LockOncePerThreadLoops.java > + * @compile LockOncePerThreadLoops.java > * @run main/timeout=15000 LockOncePerThreadLoops > * @summary Checks for missed signals by locking and unlocking each of an > array of locks once per thread > */ > --- old/test/java/util/concurrent/locks/ReentrantLock/SimpleReentrantLockLoops.java > 2014-01-13 16:54:17.000000000 -0800 > +++ new/test/java/util/concurrent/locks/ReentrantLock/SimpleReentrantLockLoops.java > 2014-01-13 16:54:17.000000000 -0800 > @@ -34,7 +34,7 @@ > /* > * @test > * @bug 4486658 > - * @compile -source 1.5 SimpleReentrantLockLoops.java > + * @compile SimpleReentrantLockLoops.java > * @run main/timeout=4500 SimpleReentrantLockLoops > * @summary multiple threads using a single lock > */ > --- old/test/java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java > 2014-01-13 16:54:18.000000000 -0800 > +++ new/test/java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java > 2014-01-13 16:54:17.000000000 -0800 > @@ -34,7 +34,7 @@ > /* > * @test > * @bug 4486658 5031862 > - * @compile -source 1.5 TimeoutLockLoops.java > + * @compile TimeoutLockLoops.java > * @run main TimeoutLockLoops > * @summary Checks for responsiveness of locks to timeouts. > * Runs under the assumption that ITERS computations require more than > --- old/test/java/util/concurrent/locks/ReentrantReadWriteLock/MapLoops.java > 2014-01-13 16:54:18.000000000 -0800 > +++ new/test/java/util/concurrent/locks/ReentrantReadWriteLock/MapLoops.java > 2014-01-13 16:54:18.000000000 -0800 > @@ -34,7 +34,7 @@ > /* > * @test > * @bug 4486658 > - * @compile -source 1.5 MapLoops.java > + * @compile MapLoops.java > * @run main/timeout=4700 MapLoops > * @summary Exercise multithreaded maps, by default ConcurrentHashMap. > * Multithreaded hash table test. Each thread does a random walk > --- old/test/javax/imageio/metadata/GetObjectMinValue.java 2014-01-13 > 16:54:20.000000000 -0800 > +++ new/test/javax/imageio/metadata/GetObjectMinValue.java 2014-01-13 > 16:54:19.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2012, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2012, 2014, 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 > @@ -24,14 +24,12 @@ > /* > * @test > * @bug 4429875 7186799 > - * @compile -source 1.4 GetObjectMinValue.java > + * @compile GetObjectMinValue.java > * @run main GetObjectMinValue > * @summary Tests the getObject{Min,Max}Value method of > * IIOMetadataFormatImpl for an inclusive range > */ > > -// Compiled with -source 1.4 to work around javac bug 5041233 > - > import javax.imageio.metadata.IIOMetadataFormatImpl; > import javax.imageio.ImageTypeSpecifier; > > @@ -79,13 +77,13 @@ > } > > public void addObjectValue(String elementName, > - Class classType, Object defaultValue, > + Class classType, Integer > defaultValue, > Comparable minValue, Comparable > maxValue, > boolean minInclusive, boolean > maxInclusive) { > - super.addObjectValue(elementName, > - classType, defaultValue, > - minValue, maxValue, > - minInclusive, maxInclusive); > + super.addObjectValue(elementName, > + (Class)classType, defaultValue, > + (Comparable) > minValue, (Comparable) maxValue, > + minInclusive, maxInclusive); > } > > public boolean canNodeAppear(String elementName, > --- old/test/javax/sound/midi/MidiDeviceConnectors/TestAllDevices.java > 2014-01-13 16:54:20.000000000 -0800 > +++ new/test/javax/sound/midi/MidiDeviceConnectors/TestAllDevices.java > 2014-01-13 16:54:20.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2010, 2014, 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 > @@ -25,7 +25,7 @@ > * @test > * @bug 4933700 > * @summary Tests that default devices return > MidiDeviceTransmitter/Receiver and returned objects return correct > MidiDevice > - * @compile -source 1.7 TestAllDevices.java > + * @compile TestAllDevices.java > * @run main TestAllDevices > * @author Alex Menkov > */ > --- old/test/javax/sound/sampled/AudioFormat/PCM_FLOAT_support.java > 2014-01-13 16:54:20.000000000 -0800 > +++ new/test/javax/sound/sampled/AudioFormat/PCM_FLOAT_support.java > 2014-01-13 16:54:20.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2010, 2014, 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 > @@ -25,7 +25,7 @@ > * @test > * @bug 6944033 > * @summary Tests that PCM_FLOAT encoding is supported > - * @compile -source 1.7 PCM_FLOAT_support.java > + * @compile PCM_FLOAT_support.java > * @run main PCM_FLOAT_support > * @author Alex Menkov > * > --- old/test/sun/management/jmxremote/LocalRMIServerSocketFactoryTest.java > 2014-01-13 16:54:21.000000000 -0800 > +++ new/test/sun/management/jmxremote/LocalRMIServerSocketFactoryTest.java > 2014-01-13 16:54:21.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2008, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2008, 2014, 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 > @@ -28,7 +28,7 @@ > * > * @author Daniel Fuchs > * > - * @run compile -XDignore.symbol.file=true -source 1.6 -g > LocalRMIServerSocketFactoryTest.java > + * @run compile -XDignore.symbol.file=true -g > LocalRMIServerSocketFactoryTest.java > * @run main LocalRMIServerSocketFactoryTest > */ > > > From joe.darcy at oracle.com Tue Jan 14 02:35:35 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 13 Jan 2014 18:35:35 -0800 Subject: JDK 9 RFR of JDK-8031651: Remove unneeded -source and -target flags in jdk repo regression tests In-Reply-To: References: <52D48EB8.70009@oracle.com> Message-ID: <52D4A277.6050505@oracle.com> Thanks Martin; I'll remove the java/util/concurrent/* files from my patch. -Joe On 01/13/2014 06:30 PM, Martin Buchholz wrote: > All occurrences of > @compile -source 1.5 > have been removed from jsr166 CVS. > > > On Mon, Jan 13, 2014 at 5:11 PM, Joe Darcy > wrote: > > Hello, > > Per the policy set forth in > > JEP 182: Policy for Retiring javac -source and -target Options > http://openjdk.java.net/jeps/182 > > in JDK 9, javac will only recognize javac source and target value > of 6/1.6 and higher. Therefore, uses of earlier options in the JDK > regression tests need to be modified. > > Please review the first pass at fixing this before support for the > old source and target values is removed: > > JDK-8031651 : Remove unneeded -source and -target flags in jdk > repo regression tests > http://cr.openjdk.java.net/~darcy/8031651.2/ > > > Patch also below. > > A few comments on the changes. In java/security/cert/* the tests > were intentionally creating a corrupted set to make sure it was > rejected properly. > > Chris, do the changes in java/util/concurrent need to go into > Doug's repo first? > > I had to wrestle a bit for the code in > javax/imageio/metadata/GetObjectMinValue to make the generics work > out. > > For test/java/util/Locale/Bug4175998Test.java, as of source 6, an > encoding error, even in a comment is a javac error. Therefore, a > non-ASCKII character is replaced by a Unicode escape. > > Kumar, the pack200 tests uses "-target 5"; can you look into > updating this to target 6 or later? > > Thanks, > > -Joe > > --- old/test/demo/jvmti/hprof/StackMapTableTest.java 2014-01-13 > 16:54:09.000000000 -0800 > +++ new/test/demo/jvmti/hprof/StackMapTableTest.java 2014-01-13 > 16:54:09.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2005, 2009, Oracle and/or its affiliates. All > rights reserved. > + * Copyright (c) 2005, 2014, 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 > @@ -27,7 +27,7 @@ > * @summary Test jvmti hprof and java_crw_demo with StackMapTable > attributes > * > * @compile ../DemoRun.java > - * @compile -source 7 -g:lines HelloWorld.java > + * @compile -g:lines HelloWorld.java > * @build StackMapTableTest > * @run main StackMapTableTest HelloWorld > */ > --- old/test/java/lang/reflect/OldenCompilingWithDefaults.java > 2014-01-13 16:54:10.000000000 -0800 > +++ new/test/java/lang/reflect/OldenCompilingWithDefaults.java > 2014-01-13 16:54:10.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2013, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2013, 2014, 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 > @@ -25,7 +25,6 @@ > * @test > * @bug 8009267 > * @summary Verify uses of isAnnotationPresent compile under > older source versions > - * @compile -source 1.5 -target 1.5 OldenCompilingWithDefaults.java > * @compile -source 1.6 -target 1.6 OldenCompilingWithDefaults.java > * @compile -source 1.7 -target 1.7 OldenCompilingWithDefaults.java > * @compile OldenCompilingWithDefaults.java > --- > old/test/java/security/cert/PKIXBuilderParameters/InvalidParameters.java > 2014-01-13 16:54:10.000000000 -0800 > +++ > new/test/java/security/cert/PKIXBuilderParameters/InvalidParameters.java > 2014-01-13 16:54:10.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2001, 2004, Oracle and/or its affiliates. All > rights reserved. > + * Copyright (c) 2001, 2014, 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 > @@ -21,16 +21,17 @@ > * questions. > */ > > -/** > +/* > * @test > * @test 4422738 > - * @compile -source 1.4 InvalidParameters.java > + * @compile InvalidParameters.java > * @run main InvalidParameters > * @summary Make sure PKIXBuilderParameters(Set) detects invalid > * parameters and throws correct exceptions > */ > import java.security.InvalidAlgorithmParameterException; > import java.security.cert.PKIXBuilderParameters; > +import java.security.cert.TrustAnchor; > import java.util.Collections; > import java.util.Set; > > @@ -53,8 +54,10 @@ > > // make sure Set of invalid objects throws ClassCastException > try { > + @SuppressWarnings("unchecked") // Knowingly do > something bad > + Set badSet = (Set) (Set) > Collections.singleton(new String()); > PKIXBuilderParameters p = > - new > PKIXBuilderParameters(Collections.singleton(new String()), null); > + new PKIXBuilderParameters(badSet, null); > throw new Exception("should have thrown > ClassCastException"); > } catch (ClassCastException cce) { } > } > --- > old/test/java/security/cert/PKIXParameters/InvalidParameters.java > 2014-01-13 16:54:11.000000000 -0800 > +++ > new/test/java/security/cert/PKIXParameters/InvalidParameters.java > 2014-01-13 16:54:10.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2001, 2004, Oracle and/or its affiliates. All > rights reserved. > + * Copyright (c) 2001, 2014, 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 > @@ -24,7 +24,7 @@ > /** > * @test > * @test 4422738 > - * @compile -source 1.4 InvalidParameters.java > + * @compile InvalidParameters.java > * @run main InvalidParameters > * @summary Make sure PKIXParameters(Set) and setTrustAnchors() > detects invalid > * parameters and throws correct exceptions > @@ -64,12 +64,14 @@ > } catch (NullPointerException npe) { } > > // make sure Set of invalid objects throws ClassCastException > + @SuppressWarnings("unchecked") // Knowingly do something bad > + Set badSet = (Set) (Set) > Collections.singleton(new String()); > try { > - PKIXParameters p = new > PKIXParameters(Collections.singleton(new String())); > + PKIXParameters p = new PKIXParameters(badSet); > throw new Exception("should have thrown > ClassCastException"); > } catch (ClassCastException cce) { } > try { > - params.setTrustAnchors(Collections.singleton(new > String())); > + params.setTrustAnchors(badSet); > throw new Exception("should have thrown > ClassCastException"); > } catch (ClassCastException cce) { } > } > --- old/test/java/util/Locale/Bug4175998Test.java 2014-01-13 > 16:54:11.000000000 -0800 > +++ new/test/java/util/Locale/Bug4175998Test.java 2014-01-13 > 16:54:11.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2007, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2007, 2014, 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 > @@ -20,13 +20,15 @@ > * or visit www.oracle.com if you need > additional information or have any > * questions. > */ > + > /* > - @test > - @summary test ISO639-2 language codes > - @compile -encoding ascii -source 5 Bug4175998Test.java > - @run main Bug4175998Test > - @bug 4175998 > -*/ > + * @test > + * @summary test ISO639-2 language codes > + * @compile -encoding ascii Bug4175998Test.java > + * @run main Bug4175998Test > + * @bug 4175998 > + */ > + > /* > * > * > @@ -731,7 +733,7 @@ > pon pon Pohnpeian > por por Portuguese > pra pra Prakrit languages > -pro pro Proven?al, Old (to 1500) > +pro pro Proven\u00E7al, Old (to 1500) > pus pus Pushto > qaa-qtz qaa-qtz Reserved for local use > que que Quechua > --- > old/test/java/util/concurrent/BlockingQueue/CancelledProducerConsumerLoops.java > 2014-01-13 16:54:12.000000000 -0800 > +++ > new/test/java/util/concurrent/BlockingQueue/CancelledProducerConsumerLoops.java > 2014-01-13 16:54:11.000000000 -0800 > @@ -34,7 +34,7 @@ > /* > * @test > * @bug 4486658 > - * @compile -source 1.5 CancelledProducerConsumerLoops.java > + * @compile CancelledProducerConsumerLoops.java > * @run main/timeout=7000 CancelledProducerConsumerLoops > * @summary Checks for responsiveness of blocking queues to > cancellation. > * Runs under the assumption that ITERS computations require more > than > --- > old/test/java/util/concurrent/BlockingQueue/MultipleProducersSingleConsumerLoops.java > 2014-01-13 16:54:12.000000000 -0800 > +++ > new/test/java/util/concurrent/BlockingQueue/MultipleProducersSingleConsumerLoops.java > 2014-01-13 16:54:12.000000000 -0800 > @@ -34,7 +34,7 @@ > /* > * @test > * @bug 4486658 > - * @compile -source 1.5 MultipleProducersSingleConsumerLoops.java > + * @compile MultipleProducersSingleConsumerLoops.java > * @run main/timeout=3600 MultipleProducersSingleConsumerLoops > * @summary multiple producers and single consumer using > blocking queues > */ > --- > old/test/java/util/concurrent/BlockingQueue/ProducerConsumerLoops.java > 2014-01-13 16:54:12.000000000 -0800 > +++ > new/test/java/util/concurrent/BlockingQueue/ProducerConsumerLoops.java > 2014-01-13 16:54:12.000000000 -0800 > @@ -34,7 +34,7 @@ > /* > * @test > * @bug 4486658 > - * @compile -source 1.5 ProducerConsumerLoops.java > + * @compile ProducerConsumerLoops.java > * @run main/timeout=3600 ProducerConsumerLoops > * @summary multiple producers and consumers using blocking queues > */ > --- > old/test/java/util/concurrent/BlockingQueue/SingleProducerMultipleConsumerLoops.java > 2014-01-13 16:54:13.000000000 -0800 > +++ > new/test/java/util/concurrent/BlockingQueue/SingleProducerMultipleConsumerLoops.java > 2014-01-13 16:54:13.000000000 -0800 > @@ -34,7 +34,7 @@ > /* > * @test > * @bug 4486658 > - * @compile -source 1.5 SingleProducerMultipleConsumerLoops.java > + * @compile SingleProducerMultipleConsumerLoops.java > * @run main/timeout=600 SingleProducerMultipleConsumerLoops > * @summary check ordering for blocking queues with 1 producer > and multiple consumers > */ > --- old/test/java/util/concurrent/ConcurrentHashMap/MapCheck.java > 2014-01-13 16:54:14.000000000 -0800 > +++ new/test/java/util/concurrent/ConcurrentHashMap/MapCheck.java > 2014-01-13 16:54:13.000000000 -0800 > @@ -34,7 +34,7 @@ > /* > * @test > * @bug 4486658 > - * @compile -source 1.5 MapCheck.java > + * @compile MapCheck.java > * @run main/timeout=240 MapCheck > * @summary Times and checks basic map operations > */ > --- old/test/java/util/concurrent/ConcurrentHashMap/MapLoops.java > 2014-01-13 16:54:14.000000000 -0800 > +++ new/test/java/util/concurrent/ConcurrentHashMap/MapLoops.java > 2014-01-13 16:54:14.000000000 -0800 > @@ -34,7 +34,7 @@ > /* > * @test > * @bug 4486658 > - * @compile -source 1.5 MapLoops.java > + * @compile MapLoops.java > * @run main/timeout=1600 MapLoops > * @summary Exercise multithreaded maps, by default > ConcurrentHashMap. > * Multithreaded hash table test. Each thread does a random walk > --- old/test/java/util/concurrent/Exchanger/ExchangeLoops.java > 2014-01-13 16:54:15.000000000 -0800 > +++ new/test/java/util/concurrent/Exchanger/ExchangeLoops.java > 2014-01-13 16:54:14.000000000 -0800 > @@ -34,7 +34,7 @@ > /* > * @test > * @bug 4486658 > - * @compile -source 1.5 ExchangeLoops.java > + * @compile ExchangeLoops.java > * @run main/timeout=720 ExchangeLoops > * @summary checks to make sure a pipeline of exchangers passes data. > */ > --- > old/test/java/util/concurrent/ExecutorCompletionService/ExecutorCompletionServiceLoops.java > 2014-01-13 16:54:15.000000000 -0800 > +++ > new/test/java/util/concurrent/ExecutorCompletionService/ExecutorCompletionServiceLoops.java > 2014-01-13 16:54:15.000000000 -0800 > @@ -34,7 +34,7 @@ > /* > * @test > * @bug 4965960 > - * @compile -source 1.5 ExecutorCompletionServiceLoops.java > + * @compile ExecutorCompletionServiceLoops.java > * @run main/timeout=3600 ExecutorCompletionServiceLoops > * @summary Exercise ExecutorCompletionServiceLoops > */ > --- > old/test/java/util/concurrent/FutureTask/CancelledFutureLoops.java > 2014-01-13 16:54:16.000000000 -0800 > +++ > new/test/java/util/concurrent/FutureTask/CancelledFutureLoops.java > 2014-01-13 16:54:15.000000000 -0800 > @@ -34,7 +34,7 @@ > /* > * @test > * @bug 4486658 > - * @compile -source 1.5 CancelledFutureLoops.java > + * @compile CancelledFutureLoops.java > * @run main/timeout=2000 CancelledFutureLoops > * @summary Checks for responsiveness of futures to cancellation. > * Runs under the assumption that ITERS computations require more > than > --- old/test/java/util/concurrent/atomic/VMSupportsCS8.java > 2014-01-13 16:54:16.000000000 -0800 > +++ new/test/java/util/concurrent/atomic/VMSupportsCS8.java > 2014-01-13 16:54:16.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2004, 2010, Oracle and/or its affiliates. All > rights reserved. > + * Copyright (c) 2004, 2014, 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 > @@ -24,7 +24,7 @@ > /* > * @test > * @bug 4992443 4994819 > - * @compile -source 1.5 VMSupportsCS8.java > + * @compile VMSupportsCS8.java > * @run main VMSupportsCS8 > * @summary Checks that the value of VMSupportsCS8 matches system > properties. > */ > --- > old/test/java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java > 2014-01-13 16:54:16.000000000 -0800 > +++ > new/test/java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java > 2014-01-13 16:54:16.000000000 -0800 > @@ -34,7 +34,7 @@ > /* > * @test > * @bug 4486658 > - * @compile -source 1.5 CancelledLockLoops.java > + * @compile CancelledLockLoops.java > * @run main/timeout=2800 CancelledLockLoops > * @summary tests lockInterruptibly. > * Checks for responsiveness of locks to interrupts. Runs under that > --- > old/test/java/util/concurrent/locks/ReentrantLock/LockOncePerThreadLoops.java > 2014-01-13 16:54:17.000000000 -0800 > +++ > new/test/java/util/concurrent/locks/ReentrantLock/LockOncePerThreadLoops.java > 2014-01-13 16:54:17.000000000 -0800 > @@ -34,7 +34,7 @@ > /* > * @test > * @bug 4486658 > - * @compile -source 1.5 LockOncePerThreadLoops.java > + * @compile LockOncePerThreadLoops.java > * @run main/timeout=15000 LockOncePerThreadLoops > * @summary Checks for missed signals by locking and unlocking > each of an array of locks once per thread > */ > --- > old/test/java/util/concurrent/locks/ReentrantLock/SimpleReentrantLockLoops.java > 2014-01-13 16:54:17.000000000 -0800 > +++ > new/test/java/util/concurrent/locks/ReentrantLock/SimpleReentrantLockLoops.java > 2014-01-13 16:54:17.000000000 -0800 > @@ -34,7 +34,7 @@ > /* > * @test > * @bug 4486658 > - * @compile -source 1.5 SimpleReentrantLockLoops.java > + * @compile SimpleReentrantLockLoops.java > * @run main/timeout=4500 SimpleReentrantLockLoops > * @summary multiple threads using a single lock > */ > --- > old/test/java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java > 2014-01-13 16:54:18.000000000 -0800 > +++ > new/test/java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java > 2014-01-13 16:54:17.000000000 -0800 > @@ -34,7 +34,7 @@ > /* > * @test > * @bug 4486658 5031862 > - * @compile -source 1.5 TimeoutLockLoops.java > + * @compile TimeoutLockLoops.java > * @run main TimeoutLockLoops > * @summary Checks for responsiveness of locks to timeouts. > * Runs under the assumption that ITERS computations require more > than > --- > old/test/java/util/concurrent/locks/ReentrantReadWriteLock/MapLoops.java > 2014-01-13 16:54:18.000000000 -0800 > +++ > new/test/java/util/concurrent/locks/ReentrantReadWriteLock/MapLoops.java > 2014-01-13 16:54:18.000000000 -0800 > @@ -34,7 +34,7 @@ > /* > * @test > * @bug 4486658 > - * @compile -source 1.5 MapLoops.java > + * @compile MapLoops.java > * @run main/timeout=4700 MapLoops > * @summary Exercise multithreaded maps, by default > ConcurrentHashMap. > * Multithreaded hash table test. Each thread does a random walk > --- old/test/javax/imageio/metadata/GetObjectMinValue.java > 2014-01-13 16:54:20.000000000 -0800 > +++ new/test/javax/imageio/metadata/GetObjectMinValue.java > 2014-01-13 16:54:19.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2012, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2012, 2014, 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 > @@ -24,14 +24,12 @@ > /* > * @test > * @bug 4429875 7186799 > - * @compile -source 1.4 GetObjectMinValue.java > + * @compile GetObjectMinValue.java > * @run main GetObjectMinValue > * @summary Tests the getObject{Min,Max}Value method of > * IIOMetadataFormatImpl for an inclusive range > */ > > -// Compiled with -source 1.4 to work around javac bug 5041233 > - > import javax.imageio.metadata.IIOMetadataFormatImpl; > import javax.imageio.ImageTypeSpecifier; > > @@ -79,13 +77,13 @@ > } > > public void addObjectValue(String elementName, > - Class classType, Object > defaultValue, > + Class classType, Integer > defaultValue, > Comparable minValue, > Comparable maxValue, > boolean minInclusive, boolean > maxInclusive) { > - super.addObjectValue(elementName, > - classType, defaultValue, > - minValue, maxValue, > - minInclusive, maxInclusive); > + super.addObjectValue(elementName, > + (Class)classType, defaultValue, > + (Comparable Integer>) minValue, (Comparable) maxValue, > + minInclusive, > maxInclusive); > } > > public boolean canNodeAppear(String elementName, > --- > old/test/javax/sound/midi/MidiDeviceConnectors/TestAllDevices.java > 2014-01-13 16:54:20.000000000 -0800 > +++ > new/test/javax/sound/midi/MidiDeviceConnectors/TestAllDevices.java > 2014-01-13 16:54:20.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2010, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2010, 2014, 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 > @@ -25,7 +25,7 @@ > * @test > * @bug 4933700 > * @summary Tests that default devices return > MidiDeviceTransmitter/Receiver and returned objects return correct > MidiDevice > - * @compile -source 1.7 TestAllDevices.java > + * @compile TestAllDevices.java > * @run main TestAllDevices > * @author Alex Menkov > */ > --- > old/test/javax/sound/sampled/AudioFormat/PCM_FLOAT_support.java > 2014-01-13 16:54:20.000000000 -0800 > +++ > new/test/javax/sound/sampled/AudioFormat/PCM_FLOAT_support.java > 2014-01-13 16:54:20.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2010, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2010, 2014, 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 > @@ -25,7 +25,7 @@ > * @test > * @bug 6944033 > * @summary Tests that PCM_FLOAT encoding is supported > - * @compile -source 1.7 PCM_FLOAT_support.java > + * @compile PCM_FLOAT_support.java > * @run main PCM_FLOAT_support > * @author Alex Menkov > * > --- > old/test/sun/management/jmxremote/LocalRMIServerSocketFactoryTest.java > 2014-01-13 16:54:21.000000000 -0800 > +++ > new/test/sun/management/jmxremote/LocalRMIServerSocketFactoryTest.java > 2014-01-13 16:54:21.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2008, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2008, 2014, 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 > @@ -28,7 +28,7 @@ > * > * @author Daniel Fuchs > * > - * @run compile -XDignore.symbol.file=true -source 1.6 -g > LocalRMIServerSocketFactoryTest.java > + * @run compile -XDignore.symbol.file=true -g > LocalRMIServerSocketFactoryTest.java > * @run main LocalRMIServerSocketFactoryTest > */ > > > From kumar.x.srinivasan at oracle.com Tue Jan 14 02:35:40 2014 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Mon, 13 Jan 2014 18:35:40 -0800 Subject: 8031494: [launcher] java launcher should check for JNI Pending exceptions. In-Reply-To: <52D477F8.60505@oracle.com> References: <52D0968F.6090702@oracle.com> <52D17072.3020602@oracle.com> <52D411C0.206@oracle.com> <52D46C5E.1030800@oracle.com> <52D477F8.60505@oracle.com> Message-ID: <52D4A27C.2020709@oracle.com> Mandy, > On 1/13/2014 2:44 PM, Kumar Srinivasan wrote: >> The full webrev: >> http://cr.openjdk.java.net/~ksrini/8031494/webrev.1/ > > This looks good. Should it also check if there is any pending > exception after the call to CallStaticVoidMethod that has no return > value? It's fine with me if you want to follow up the calls to > CallStaticVoidMethod in a separate bug. No not necessary, there are already guards for pending exceptions from CallStaticVoidMethod, all of them are in JavaMain, and these macros end with "LEAVE". Thanks Kumar > > Mandy From david.holmes at oracle.com Tue Jan 14 02:39:08 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 Jan 2014 12:39:08 +1000 Subject: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm In-Reply-To: <52D385D1.9020604@oracle.com> References: <52CBA203.7080706@oracle.com> <52CBA851.8070008@oracle.com> <52CBB7C0.1040002@oracle.com> <52CBC66B.7000003@oracle.com> <52CBD8B7.8050002@oracle.com> <52CBE530.6070105@oracle.com> <52CE7171.1080407@oracle.com> <2BD1713F-655F-429A-9FC0-A14832D32C9D@oracle.com> <52CE8307.6040606@oracle.com> <52CE87A0.90504@oracle.com> <52CE92B4.4020009@oracle.com> <52CF2438.4090604@oracle.com> <52CF2EA3.9060504@oracle.com> <52D385D1.9020604@oracle.com> Message-ID: <52D4A34C.8070502@oracle.com> On 13/01/2014 4:21 PM, Tristan Yan wrote: > Hi All > I add more trace output to track down possible reason of this failure. > Please help to review it again. > > http://cr.openjdk.java.net/~tyan/JDK-7027502/webrev.05/ You seem to have dragged in some unrelated changes to ProblemList.txt Also I don't see much in the way of trace output. I see two potentially useful printlns (and one unnecessary one). Further all the changes from the static variables are still there but we already determined that they should have no affect on the running of the test, nor did they explain the failure mode. So other than reenabling this test to see if it actually still fails, I don't see the point of the functional changes. Sorry. David > Thank you > Tristan > > On 01/10/2014 07:20 AM, Tristan Yan wrote: >> Hi David >> I wasn't able to reproduce this failure either in local or in our same >> binaries running(This is a continuous running with same JDK binaries). >> So intention for this code change is bringing this test back; add >> some debug info and try to avoid possible issues in this test. I agree >> this code change won't solve the failure happened. But this test was >> put into ProblemList two years ago better move for this is move out it >> from ProblemList and trace down the issue in our normal nightly. >> Thank you >> Tristan >> >> On 01/10/2014 06:35 AM, David Holmes wrote: >>> On 9/01/2014 10:14 PM, Alan Bateman wrote: >>>> On 09/01/2014 11:27, David Holmes wrote: >>>>> >>>>> Okay I think I get it now. Both MonitorTest and WaitersTest use the >>>>> Context class, so if both tests run in the same VM the second test >>>>> will see the static total_turns_taken and "turn" in the state they >>>>> were left from the first test - hence the second test will always >>>>> fail. The bug report suggests making the tests othervm to avoid the >>>>> problem but instead you have changed from using static state to >>>>> instance state so that there is no interference. >>>> I haven't been following this one closely but I thought that jtreg >>>> created a class loader for each test (irrespective of mode) so I >>>> wouldn't expect statics to be an issue. >>> >>> That aside DemoRun forks off its own JVM to run a given test anyway! >>> >>> So I don't understand how the proposed fixes could actually be >>> addressing the hangs that are occurring. Even if the statics were >>> being shared I don't see how that leads to the failure mode in the >>> bug report. >>> >>> David >>> >>>> -Alan. >> > From david.holmes at oracle.com Tue Jan 14 02:51:46 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 Jan 2014 12:51:46 +1000 Subject: RFR: (8030875) Macros for checking and returning on exceptions In-Reply-To: <52D013B9.40101@oracle.com> References: <52D013B9.40101@oracle.com> Message-ID: <52D4A642.7090404@oracle.com> Hi Roger, On 11/01/2014 1:37 AM, roger riggs wrote: > Please review: > > To enable native code checking consistently for thrown exceptions, > the macros in net_util.h and java/util/jar/pack/coding.cpp are > made consolidated and promoted to jni_util.h > > webrev: > http://cr.openjdk.java.net/~rriggs/webrev-check-exception-8030875/ Do these macro definitions not cause "empty statement" warnings from the compiler? (Existing ones have the same problem I guess) Also I don't see any use of the CHECK_EXCEPTION macros? In fact the bulk of changes here seem completely unrelated to the "exception" aspect of this CR. Cheers, David > [1] https://bugs.openjdk.java.net/browse/JDK-8030875 From mandy.chung at oracle.com Tue Jan 14 03:35:04 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 13 Jan 2014 19:35:04 -0800 Subject: 8031494: [launcher] java launcher should check for JNI Pending exceptions. In-Reply-To: <52D4A27C.2020709@oracle.com> References: <52D0968F.6090702@oracle.com> <52D17072.3020602@oracle.com> <52D411C0.206@oracle.com> <52D46C5E.1030800@oracle.com> <52D477F8.60505@oracle.com> <52D4A27C.2020709@oracle.com> Message-ID: <52D4B068.6050509@oracle.com> On 1/13/2014 6:35 PM, Kumar Srinivasan wrote: > Mandy, > > >> On 1/13/2014 2:44 PM, Kumar Srinivasan wrote: >>> The full webrev: >>> http://cr.openjdk.java.net/~ksrini/8031494/webrev.1/ >> >> This looks good. Should it also check if there is any pending >> exception after the call to CallStaticVoidMethod that has no return >> value? It's fine with me if you want to follow up the calls to >> CallStaticVoidMethod in a separate bug. > > No not necessary, there are already guards for pending exceptions from > CallStaticVoidMethod, > all of them are in JavaMain, and these macros end with "LEAVE". I'm referring to multiple calls to CallStaticVoidMethod within the same function e.g. PrintUsage (maybe that's the only one) where I believe no LEAVE macro call in between. Mandy From volker.simonis at gmail.com Tue Jan 14 08:40:55 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 14 Jan 2014 09:40:55 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests Message-ID: Hi, could you please review the following changes for the ppc-aix-port stage/stage-9 repositories (the changes are planned for integration into ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): http://cr.openjdk.java.net/~simonis/webrevs/8031581/ I've build and smoke tested without any problems on Linux/x86_64 and PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64. With these changes (and together with the changes from "8028537: PPC64: Updated jdk/test scripts to understand the AIX os and environment" and "8031134 : PPC64: implement printing on AIX") our port passes all but the following 7 jtreg regression tests on AIX (compared to the Linux/x86_64 baseline from www.java.net/download/jdk8/testresults/testresults.html?): java/net/Inet6Address/B6558853.java java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically) java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically) java/nio/channels/Selector/RacyDeregister.java sun/security/krb5/auto/Unreachable.java (only on IPv6) Thank you and best regards, Volker Following a detailed description of the various changes: src/share/native/java/util/zip/zip_util.c src/share/native/sun/management/DiagnosticCommandImpl.c - According to ISO C it is perfectly legal for malloc to return zero if called with a zero argument. Fix various places where malloc can potentially correctly return zero because it was called with a zero argument. - Also fixed DiagnosticCommandImpl.c to include stdlib.h. This only fixes a compiler warning on Linux, but on AIX it prevents a VM crash later on because the return value of malloc() will be casted to int which is especially bad if that pointer was bigger than 32-bit. make/CompileJavaClasses.gmk - Also use PollingWatchService on AIX. make/lib/NioLibraries.gmk src/aix/native/sun/nio/ch/AixNativeThread.c - Put the implementation for the native methods of NativeThread into AixNativeThread.c on AIX. src/solaris/native/sun/nio/ch/PollArrayWrapper.c src/solaris/native/sun/nio/ch/Net.c src/aix/classes/sun/nio/ch/AixPollPort.java src/aix/native/sun/nio/ch/AixPollPort.c src/aix/native/java/net/aix_close.c - On AIX, the constants used for the polling events (i.e. POLLIN, POLLOUT, ...) are defined to different values than on other operating systems. The problem is however, that these constants are hardcoded as public final static members of various, shared Java classes. We therefore have to map them from Java to native every time before calling one of the native poll functions and back to Java after the call on AIX in order to get the right semantics. src/share/classes/java/nio/file/CopyMoveHelper.java - As discussed on the core-libs mailing list (see http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024119.html) it is not necessary to call Files.getFileAttributeView() with any linkOptions because at that place we've already checked that the target file can not be a symbolic link. This change makes the implementation more robust on platforms which support symbolic links but do not support the O_NOFOLLOW flag to the open system call. It also makes the JDK pass the demo/zipfs/basic.sh test on AIX. src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java - Support "compound text" on AIX in the same way like on other Unix platforms. src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider - Define the correct attach provider for AIX. src/solaris/native/java/net/net_util_md.h src/solaris/native/sun/nio/ch/FileDispatcherImpl.c src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c - AIX needs a workaround for I/O cancellation (see: http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/close.htm). "..The close() subroutine is blocked until all subroutines which use the file descriptor return to usr space. For example, when a thread is calling close and another thread is calling select with the same file descriptor, the close subroutine does not return until the select call returns...". To fix this problem, we have to use the various NET_ wrappers which are declared in net_util_md.h and defined in aix_close.c and we also need some additional wrappers for fcntl(), read() and write() on AIX. While the current solution isn't really nice because it introduces some more AIX-specifc sections in shared code, I think it is the best way to go for JDK 8 because it imposes the smallest possible changes and risks for the existing platforms. I'm ready to change the code to unconditionally use the wrappers for all platforms and implement the wrappers empty on platforms which don't need any wrapping. I think it would also be nice to clean up the names (e.g. NET_Read() is currently a wrapper for recv()and the NET_ prefix is probably not appropriate any more so maybe change it to something like IO_). But again, I'll prefer to keep that as a follow up change for JDK9. - Calling fsync() on a "read-only" file descriptor on AIX will result in an error (i.e. "EBADF: The FileDescriptor parameter is not a valid file descriptor open for writing."). To prevent this error we have to query if the corresponding file descriptor is writeable. Notice that at that point we can not access the writable attribute of the corresponding file channel so we have to use fcntl(). src/solaris/classes/java/lang/UNIXProcess.java.aix - On AIX the implementation is especially tricky, because the close()system call will block if another thread is at the same time blocked in a file operation (e.g. 'read()') on the same file descriptor. We therefore combine the AIX ProcessPipeInputStream implemenatation with the DeferredCloseInputStream approach used on Solaris (see UNIXProcess.java.solaris). This means that every potentially blocking operation on the file descriptor increments a counter before it is executed and decrements it once it finishes. The 'close()' operation will only be executed if there are no pending operations. Otherwise it is deferred after the last pending operation has finished. src/share/transport/socket/socketTransport.c - On AIX we have to call shutdown() on a socket descriptor before closing it, otherwise the close() call may be blocked. This is the same problem as described before. Unfortunately the JDI framework doesn't use the same IO wrappers like other class library components so we can not easily use the NET_ abstractions from aix_close.c here. - Without this small change all JDI regression tests will fail on AIX because of the way how the tests act as a "debugger" which launches another VM (the "debugge") which connects itself back to the debugger. In this scenario the "debugge" can not shut down itself because one thread will always be blocked in the close() call on one of the communication sockets. src/solaris/native/java/net/NetworkInterface.c - Set the scope identifier for IPv6 addresses on AIX. src/solaris/native/java/net/net_util_md.c - It turns out that we do not always have to replace SO_REUSEADDR on AIX by SO_REUSEPORT. Instead we can simply use the same approach like BSD and only use SO_REUSEPORT additionally, if several datagram sockets try to bind to the same port. - Also fixed a comment and removed unused local variables. - Fixed the obviously inverted assignment newTime = prevTime; which should read prevTime = newTime;. Otherwise prevTime will never change and the timeout will be potential reached too fast. src/solaris/native/sun/management/OperatingSystemImpl.c - AIX does not understand /proc/self so we have to query the real process ID to access the proc file system. src/solaris/native/sun/nio/ch/DatagramChannelImpl.c - On AIX, connect() may legally return EAFNOSUPPORT if called on a socket with the address family set to AF_UNSPEC. From Alan.Bateman at oracle.com Tue Jan 14 09:19:20 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 Jan 2014 09:19:20 +0000 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: Message-ID: <52D50118.3080000@oracle.com> On 14/01/2014 08:40, Volker Simonis wrote: > Hi, > > could you please review the following changes for the ppc-aix-port > stage/stage-9 repositories (the changes are planned for integration > into ppc-aix-port/stage-9 and subsequent backporting to > ppc-aix-port/stage): I'd like to review this but I won't have time until later in the week. From an initial look then there are a few things are not pretty (the changes to fix the AIX problems with I/O cancellation in particular) and I suspect that some refactoring is going to be required to handle some of this cleanly. A minor comment is that bug synopsis doesn't really communicate what these changes are about. -Alan. From Alan.Bateman at oracle.com Tue Jan 14 09:40:05 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 Jan 2014 09:40:05 +0000 Subject: JDK 9 RFR of JDK-8031651: Remove unneeded -source and -target flags in jdk repo regression tests In-Reply-To: <52D48EB8.70009@oracle.com> References: <52D48EB8.70009@oracle.com> Message-ID: <52D505F5.3000504@oracle.com> On 14/01/2014 01:11, Joe Darcy wrote: > : > > A few comments on the changes. In java/security/cert/* the tests were > intentionally creating a corrupted set to make sure it was rejected > properly. > See JDK-8005937 [1] for a previous attempt to remove the the -source 1.4 from these tests. -Alan [1] https://bugs.openjdk.java.net/browse/JDK-8005937 From volker.simonis at gmail.com Tue Jan 14 09:56:55 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 14 Jan 2014 10:56:55 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: <52D50118.3080000@oracle.com> References: <52D50118.3080000@oracle.com> Message-ID: Hi Alan, On Tue, Jan 14, 2014 at 10:19 AM, Alan Bateman wrote: > On 14/01/2014 08:40, Volker Simonis wrote: > >> Hi, >> >> could you please review the following changes for the ppc-aix-port >> stage/stage-9 repositories (the changes are planned for integration into >> ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): >> > > I'd like to review this but I won't have time until later in the week. Thanks, that would be great. > From an initial look then there are a few things are not pretty (the > changes to fix the AIX problems with I/O cancellation in particular) and I > suspect that some refactoring is going to be required to handle some of > this cleanly. I agree, but as I wrote, this change is intended to finally go into both jdk9 and jkd8u and I didn't wanted to do to much refactoring for jdk8u. Once its in and we have a working port I'd be happy to work on refactoring the code but I think this should be done in jdk9 where we have more time and less risks of changing the behaviour on the existing platforms. > A minor comment is that bug synopsis doesn't really communicate what these > changes are about. > > This is the last "bulk change" which address issues in several different areas of the class library. Follow up changes will be more specific with better bug synopsis (I promise :). Regards, Volker > -Alan. > From Alan.Bateman at oracle.com Tue Jan 14 10:13:59 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 Jan 2014 10:13:59 +0000 Subject: Review request for 6516909: (cl spec) ClassLoader.loadClass() clarification to indicate it shouldn't be used for array classes In-Reply-To: <52D4708F.8030703@oracle.com> References: <52D4708F.8030703@oracle.com> Message-ID: <52D50DE7.6090404@oracle.com> On 13/01/2014 23:02, Mandy Chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/6516909/webrev.00/ > > This patch is to fix: > > 6516909: (cl spec) ClassLoader.loadClass() clarification to indicate > it shouldn't be used for array classes > 4932272: (cl) Remove declaration of the unused private method > ClassLoader.defineClass0 > > In JDK 5, parameter checking of ClassLoader.loadClass and other > methods was modified to validate if the given class name is a binary > name. ClassLoader.loadClass cannot be used to load an array class; > instead it should use Class.forName. This patch adds a sentence in > the "Binary Name" section in the ClassLoader class description to > clarify that. > > This patch also removes the "sun.lang.ClassLoader.allowArraySyntax" > system property that was added in JDK 5 to allow existing code to > workaround the incompatibility issue. It was disabled by default in > JDK 6. It's over 7 years and it's time to remove it. Also remove the > unused private ClassLoader.defineClass0. > > Mandy > > [1] > http://www.oracle.com/technetwork/java/javase/compatibility-137462.html This looks good to me, I assume JDK-6434149 can finally be closed too. -Alan. From daniel.fuchs at oracle.com Tue Jan 14 11:16:18 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 14 Jan 2014 12:16:18 +0100 Subject: JDK 9 RFR of JDK-8031651: Remove unneeded -source and -target flags in jdk repo regression tests In-Reply-To: <52D48EB8.70009@oracle.com> References: <52D48EB8.70009@oracle.com> Message-ID: <52D51C82.2020301@oracle.com> On 1/14/14 2:11 AM, Joe Darcy wrote: > Hello, > > Per the policy set forth in > > JEP 182: Policy for Retiring javac -source and -target Options > http://openjdk.java.net/jeps/182 > > in JDK 9, javac will only recognize javac source and target value of > 6/1.6 and higher. Therefore, uses of earlier options in the JDK > regression tests need to be modified. > > Please review the first pass at fixing this before support for the old > source and target values is removed: > > JDK-8031651 : Remove unneeded -source and -target flags in jdk > repo regression tests > http://cr.openjdk.java.net/~darcy/8031651.2/ > > Patch also below. > > [snip] Hi Joe, The changes to test/sun/management/jmxremote/LocalRMIServerSocketFactoryTest.java look good. best regards, -- daniel > --- > old/test/sun/management/jmxremote/LocalRMIServerSocketFactoryTest.java > 2014-01-13 16:54:21.000000000 -0800 > +++ > new/test/sun/management/jmxremote/LocalRMIServerSocketFactoryTest.java > 2014-01-13 16:54:21.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2008, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2008, 2014, 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 > @@ -28,7 +28,7 @@ > * > * @author Daniel Fuchs > * > - * @run compile -XDignore.symbol.file=true -source 1.6 -g > LocalRMIServerSocketFactoryTest.java > + * @run compile -XDignore.symbol.file=true -g > LocalRMIServerSocketFactoryTest.java > * @run main LocalRMIServerSocketFactoryTest > */ > > From chris.hegarty at oracle.com Tue Jan 14 11:27:53 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 14 Jan 2014 11:27:53 +0000 Subject: JDK 9 RFR of JDK-8031651: Remove unneeded -source and -target flags in jdk repo regression tests In-Reply-To: References: <52D48EB8.70009@oracle.com> Message-ID: <781B81A3-A854-4346-AF9D-DB372AC02B59@oracle.com> Since Martin has removed completely the '@compile -source 1.5 XXX? lines from the 166 CVS, you can amend your patch to do the same, or we can file a separate bug to bring in these change. Whatever suits you, just let me know. -Chris. On 14 Jan 2014, at 02:30, Martin Buchholz wrote: > All occurrences of > @compile -source 1.5 > have been removed from jsr166 CVS. > > > On Mon, Jan 13, 2014 at 5:11 PM, Joe Darcy wrote: > Hello, > > Per the policy set forth in > > JEP 182: Policy for Retiring javac -source and -target Options > http://openjdk.java.net/jeps/182 > > in JDK 9, javac will only recognize javac source and target value of 6/1.6 and higher. Therefore, uses of earlier options in the JDK regression tests need to be modified. > > Please review the first pass at fixing this before support for the old source and target values is removed: > > JDK-8031651 : Remove unneeded -source and -target flags in jdk repo regression tests > http://cr.openjdk.java.net/~darcy/8031651.2/ > > Patch also below. > > A few comments on the changes. In java/security/cert/* the tests were intentionally creating a corrupted set to make sure it was rejected properly. > > Chris, do the changes in java/util/concurrent need to go into Doug's repo first? > > I had to wrestle a bit for the code in javax/imageio/metadata/GetObjectMinValue to make the generics work out. > > For test/java/util/Locale/Bug4175998Test.java, as of source 6, an encoding error, even in a comment is a javac error. Therefore, a non-ASCKII character is replaced by a Unicode escape. > > Kumar, the pack200 tests uses "-target 5"; can you look into updating this to target 6 or later? > > Thanks, > > -Joe > > --- old/test/demo/jvmti/hprof/StackMapTableTest.java 2014-01-13 16:54:09.000000000 -0800 > +++ new/test/demo/jvmti/hprof/StackMapTableTest.java 2014-01-13 16:54:09.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2005, 2009, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2005, 2014, 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 > @@ -27,7 +27,7 @@ > * @summary Test jvmti hprof and java_crw_demo with StackMapTable attributes > * > * @compile ../DemoRun.java > - * @compile -source 7 -g:lines HelloWorld.java > + * @compile -g:lines HelloWorld.java > * @build StackMapTableTest > * @run main StackMapTableTest HelloWorld > */ > --- old/test/java/lang/reflect/OldenCompilingWithDefaults.java 2014-01-13 16:54:10.000000000 -0800 > +++ new/test/java/lang/reflect/OldenCompilingWithDefaults.java 2014-01-13 16:54:10.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2013, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2013, 2014, 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 > @@ -25,7 +25,6 @@ > * @test > * @bug 8009267 > * @summary Verify uses of isAnnotationPresent compile under older source versions > - * @compile -source 1.5 -target 1.5 OldenCompilingWithDefaults.java > * @compile -source 1.6 -target 1.6 OldenCompilingWithDefaults.java > * @compile -source 1.7 -target 1.7 OldenCompilingWithDefaults.java > * @compile OldenCompilingWithDefaults.java > --- old/test/java/security/cert/PKIXBuilderParameters/InvalidParameters.java 2014-01-13 16:54:10.000000000 -0800 > +++ new/test/java/security/cert/PKIXBuilderParameters/InvalidParameters.java 2014-01-13 16:54:10.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2001, 2004, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2001, 2014, 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 > @@ -21,16 +21,17 @@ > * questions. > */ > > -/** > +/* > * @test > * @test 4422738 > - * @compile -source 1.4 InvalidParameters.java > + * @compile InvalidParameters.java > * @run main InvalidParameters > * @summary Make sure PKIXBuilderParameters(Set) detects invalid > * parameters and throws correct exceptions > */ > import java.security.InvalidAlgorithmParameterException; > import java.security.cert.PKIXBuilderParameters; > +import java.security.cert.TrustAnchor; > import java.util.Collections; > import java.util.Set; > > @@ -53,8 +54,10 @@ > > // make sure Set of invalid objects throws ClassCastException > try { > + @SuppressWarnings("unchecked") // Knowingly do something bad > + Set badSet = (Set) (Set) Collections.singleton(new String()); > PKIXBuilderParameters p = > - new PKIXBuilderParameters(Collections.singleton(new String()), null); > + new PKIXBuilderParameters(badSet, null); > throw new Exception("should have thrown ClassCastException"); > } catch (ClassCastException cce) { } > } > --- old/test/java/security/cert/PKIXParameters/InvalidParameters.java 2014-01-13 16:54:11.000000000 -0800 > +++ new/test/java/security/cert/PKIXParameters/InvalidParameters.java 2014-01-13 16:54:10.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2001, 2004, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2001, 2014, 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 > @@ -24,7 +24,7 @@ > /** > * @test > * @test 4422738 > - * @compile -source 1.4 InvalidParameters.java > + * @compile InvalidParameters.java > * @run main InvalidParameters > * @summary Make sure PKIXParameters(Set) and setTrustAnchors() detects invalid > * parameters and throws correct exceptions > @@ -64,12 +64,14 @@ > } catch (NullPointerException npe) { } > > // make sure Set of invalid objects throws ClassCastException > + @SuppressWarnings("unchecked") // Knowingly do something bad > + Set badSet = (Set) (Set) Collections.singleton(new String()); > try { > - PKIXParameters p = new PKIXParameters(Collections.singleton(new String())); > + PKIXParameters p = new PKIXParameters(badSet); > throw new Exception("should have thrown ClassCastException"); > } catch (ClassCastException cce) { } > try { > - params.setTrustAnchors(Collections.singleton(new String())); > + params.setTrustAnchors(badSet); > throw new Exception("should have thrown ClassCastException"); > } catch (ClassCastException cce) { } > } > --- old/test/java/util/Locale/Bug4175998Test.java 2014-01-13 16:54:11.000000000 -0800 > +++ new/test/java/util/Locale/Bug4175998Test.java 2014-01-13 16:54:11.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2007, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2007, 2014, 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 > @@ -20,13 +20,15 @@ > * or visit www.oracle.com if you need additional information or have any > * questions. > */ > + > /* > - @test > - @summary test ISO639-2 language codes > - @compile -encoding ascii -source 5 Bug4175998Test.java > - @run main Bug4175998Test > - @bug 4175998 > -*/ > + * @test > + * @summary test ISO639-2 language codes > + * @compile -encoding ascii Bug4175998Test.java > + * @run main Bug4175998Test > + * @bug 4175998 > + */ > + > /* > * > * > @@ -731,7 +733,7 @@ > pon pon Pohnpeian > por por Portuguese > pra pra Prakrit languages > -pro pro Proven?al, Old (to 1500) > +pro pro Proven\u00E7al, Old (to 1500) > pus pus Pushto > qaa-qtz qaa-qtz Reserved for local use > que que Quechua > --- old/test/java/util/concurrent/BlockingQueue/CancelledProducerConsumerLoops.java 2014-01-13 16:54:12.000000000 -0800 > +++ new/test/java/util/concurrent/BlockingQueue/CancelledProducerConsumerLoops.java 2014-01-13 16:54:11.000000000 -0800 > @@ -34,7 +34,7 @@ > /* > * @test > * @bug 4486658 > - * @compile -source 1.5 CancelledProducerConsumerLoops.java > + * @compile CancelledProducerConsumerLoops.java > * @run main/timeout=7000 CancelledProducerConsumerLoops > * @summary Checks for responsiveness of blocking queues to cancellation. > * Runs under the assumption that ITERS computations require more than > --- old/test/java/util/concurrent/BlockingQueue/MultipleProducersSingleConsumerLoops.java 2014-01-13 16:54:12.000000000 -0800 > +++ new/test/java/util/concurrent/BlockingQueue/MultipleProducersSingleConsumerLoops.java 2014-01-13 16:54:12.000000000 -0800 > @@ -34,7 +34,7 @@ > /* > * @test > * @bug 4486658 > - * @compile -source 1.5 MultipleProducersSingleConsumerLoops.java > + * @compile MultipleProducersSingleConsumerLoops.java > * @run main/timeout=3600 MultipleProducersSingleConsumerLoops > * @summary multiple producers and single consumer using blocking queues > */ > --- old/test/java/util/concurrent/BlockingQueue/ProducerConsumerLoops.java 2014-01-13 16:54:12.000000000 -0800 > +++ new/test/java/util/concurrent/BlockingQueue/ProducerConsumerLoops.java 2014-01-13 16:54:12.000000000 -0800 > @@ -34,7 +34,7 @@ > /* > * @test > * @bug 4486658 > - * @compile -source 1.5 ProducerConsumerLoops.java > + * @compile ProducerConsumerLoops.java > * @run main/timeout=3600 ProducerConsumerLoops > * @summary multiple producers and consumers using blocking queues > */ > --- old/test/java/util/concurrent/BlockingQueue/SingleProducerMultipleConsumerLoops.java 2014-01-13 16:54:13.000000000 -0800 > +++ new/test/java/util/concurrent/BlockingQueue/SingleProducerMultipleConsumerLoops.java 2014-01-13 16:54:13.000000000 -0800 > @@ -34,7 +34,7 @@ > /* > * @test > * @bug 4486658 > - * @compile -source 1.5 SingleProducerMultipleConsumerLoops.java > + * @compile SingleProducerMultipleConsumerLoops.java > * @run main/timeout=600 SingleProducerMultipleConsumerLoops > * @summary check ordering for blocking queues with 1 producer and multiple consumers > */ > --- old/test/java/util/concurrent/ConcurrentHashMap/MapCheck.java 2014-01-13 16:54:14.000000000 -0800 > +++ new/test/java/util/concurrent/ConcurrentHashMap/MapCheck.java 2014-01-13 16:54:13.000000000 -0800 > @@ -34,7 +34,7 @@ > /* > * @test > * @bug 4486658 > - * @compile -source 1.5 MapCheck.java > + * @compile MapCheck.java > * @run main/timeout=240 MapCheck > * @summary Times and checks basic map operations > */ > --- old/test/java/util/concurrent/ConcurrentHashMap/MapLoops.java 2014-01-13 16:54:14.000000000 -0800 > +++ new/test/java/util/concurrent/ConcurrentHashMap/MapLoops.java 2014-01-13 16:54:14.000000000 -0800 > @@ -34,7 +34,7 @@ > /* > * @test > * @bug 4486658 > - * @compile -source 1.5 MapLoops.java > + * @compile MapLoops.java > * @run main/timeout=1600 MapLoops > * @summary Exercise multithreaded maps, by default ConcurrentHashMap. > * Multithreaded hash table test. Each thread does a random walk > --- old/test/java/util/concurrent/Exchanger/ExchangeLoops.java 2014-01-13 16:54:15.000000000 -0800 > +++ new/test/java/util/concurrent/Exchanger/ExchangeLoops.java 2014-01-13 16:54:14.000000000 -0800 > @@ -34,7 +34,7 @@ > /* > * @test > * @bug 4486658 > - * @compile -source 1.5 ExchangeLoops.java > + * @compile ExchangeLoops.java > * @run main/timeout=720 ExchangeLoops > * @summary checks to make sure a pipeline of exchangers passes data. > */ > --- old/test/java/util/concurrent/ExecutorCompletionService/ExecutorCompletionServiceLoops.java 2014-01-13 16:54:15.000000000 -0800 > +++ new/test/java/util/concurrent/ExecutorCompletionService/ExecutorCompletionServiceLoops.java 2014-01-13 16:54:15.000000000 -0800 > @@ -34,7 +34,7 @@ > /* > * @test > * @bug 4965960 > - * @compile -source 1.5 ExecutorCompletionServiceLoops.java > + * @compile ExecutorCompletionServiceLoops.java > * @run main/timeout=3600 ExecutorCompletionServiceLoops > * @summary Exercise ExecutorCompletionServiceLoops > */ > --- old/test/java/util/concurrent/FutureTask/CancelledFutureLoops.java 2014-01-13 16:54:16.000000000 -0800 > +++ new/test/java/util/concurrent/FutureTask/CancelledFutureLoops.java 2014-01-13 16:54:15.000000000 -0800 > @@ -34,7 +34,7 @@ > /* > * @test > * @bug 4486658 > - * @compile -source 1.5 CancelledFutureLoops.java > + * @compile CancelledFutureLoops.java > * @run main/timeout=2000 CancelledFutureLoops > * @summary Checks for responsiveness of futures to cancellation. > * Runs under the assumption that ITERS computations require more than > --- old/test/java/util/concurrent/atomic/VMSupportsCS8.java 2014-01-13 16:54:16.000000000 -0800 > +++ new/test/java/util/concurrent/atomic/VMSupportsCS8.java 2014-01-13 16:54:16.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2004, 2010, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2004, 2014, 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 > @@ -24,7 +24,7 @@ > /* > * @test > * @bug 4992443 4994819 > - * @compile -source 1.5 VMSupportsCS8.java > + * @compile VMSupportsCS8.java > * @run main VMSupportsCS8 > * @summary Checks that the value of VMSupportsCS8 matches system properties. > */ > --- old/test/java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java 2014-01-13 16:54:16.000000000 -0800 > +++ new/test/java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java 2014-01-13 16:54:16.000000000 -0800 > @@ -34,7 +34,7 @@ > /* > * @test > * @bug 4486658 > - * @compile -source 1.5 CancelledLockLoops.java > + * @compile CancelledLockLoops.java > * @run main/timeout=2800 CancelledLockLoops > * @summary tests lockInterruptibly. > * Checks for responsiveness of locks to interrupts. Runs under that > --- old/test/java/util/concurrent/locks/ReentrantLock/LockOncePerThreadLoops.java 2014-01-13 16:54:17.000000000 -0800 > +++ new/test/java/util/concurrent/locks/ReentrantLock/LockOncePerThreadLoops.java 2014-01-13 16:54:17.000000000 -0800 > @@ -34,7 +34,7 @@ > /* > * @test > * @bug 4486658 > - * @compile -source 1.5 LockOncePerThreadLoops.java > + * @compile LockOncePerThreadLoops.java > * @run main/timeout=15000 LockOncePerThreadLoops > * @summary Checks for missed signals by locking and unlocking each of an array of locks once per thread > */ > --- old/test/java/util/concurrent/locks/ReentrantLock/SimpleReentrantLockLoops.java 2014-01-13 16:54:17.000000000 -0800 > +++ new/test/java/util/concurrent/locks/ReentrantLock/SimpleReentrantLockLoops.java 2014-01-13 16:54:17.000000000 -0800 > @@ -34,7 +34,7 @@ > /* > * @test > * @bug 4486658 > - * @compile -source 1.5 SimpleReentrantLockLoops.java > + * @compile SimpleReentrantLockLoops.java > * @run main/timeout=4500 SimpleReentrantLockLoops > * @summary multiple threads using a single lock > */ > --- old/test/java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java 2014-01-13 16:54:18.000000000 -0800 > +++ new/test/java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java 2014-01-13 16:54:17.000000000 -0800 > @@ -34,7 +34,7 @@ > /* > * @test > * @bug 4486658 5031862 > - * @compile -source 1.5 TimeoutLockLoops.java > + * @compile TimeoutLockLoops.java > * @run main TimeoutLockLoops > * @summary Checks for responsiveness of locks to timeouts. > * Runs under the assumption that ITERS computations require more than > --- old/test/java/util/concurrent/locks/ReentrantReadWriteLock/MapLoops.java 2014-01-13 16:54:18.000000000 -0800 > +++ new/test/java/util/concurrent/locks/ReentrantReadWriteLock/MapLoops.java 2014-01-13 16:54:18.000000000 -0800 > @@ -34,7 +34,7 @@ > /* > * @test > * @bug 4486658 > - * @compile -source 1.5 MapLoops.java > + * @compile MapLoops.java > * @run main/timeout=4700 MapLoops > * @summary Exercise multithreaded maps, by default ConcurrentHashMap. > * Multithreaded hash table test. Each thread does a random walk > --- old/test/javax/imageio/metadata/GetObjectMinValue.java 2014-01-13 16:54:20.000000000 -0800 > +++ new/test/javax/imageio/metadata/GetObjectMinValue.java 2014-01-13 16:54:19.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2012, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2012, 2014, 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 > @@ -24,14 +24,12 @@ > /* > * @test > * @bug 4429875 7186799 > - * @compile -source 1.4 GetObjectMinValue.java > + * @compile GetObjectMinValue.java > * @run main GetObjectMinValue > * @summary Tests the getObject{Min,Max}Value method of > * IIOMetadataFormatImpl for an inclusive range > */ > > -// Compiled with -source 1.4 to work around javac bug 5041233 > - > import javax.imageio.metadata.IIOMetadataFormatImpl; > import javax.imageio.ImageTypeSpecifier; > > @@ -79,13 +77,13 @@ > } > > public void addObjectValue(String elementName, > - Class classType, Object defaultValue, > + Class classType, Integer defaultValue, > Comparable minValue, Comparable maxValue, > boolean minInclusive, boolean maxInclusive) { > - super.addObjectValue(elementName, > - classType, defaultValue, > - minValue, maxValue, > - minInclusive, maxInclusive); > + super.addObjectValue(elementName, > + (Class)classType, defaultValue, > + (Comparable) minValue, (Comparable) maxValue, > + minInclusive, maxInclusive); > } > > public boolean canNodeAppear(String elementName, > --- old/test/javax/sound/midi/MidiDeviceConnectors/TestAllDevices.java 2014-01-13 16:54:20.000000000 -0800 > +++ new/test/javax/sound/midi/MidiDeviceConnectors/TestAllDevices.java 2014-01-13 16:54:20.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2010, 2014, 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 > @@ -25,7 +25,7 @@ > * @test > * @bug 4933700 > * @summary Tests that default devices return MidiDeviceTransmitter/Receiver and returned objects return correct MidiDevice > - * @compile -source 1.7 TestAllDevices.java > + * @compile TestAllDevices.java > * @run main TestAllDevices > * @author Alex Menkov > */ > --- old/test/javax/sound/sampled/AudioFormat/PCM_FLOAT_support.java 2014-01-13 16:54:20.000000000 -0800 > +++ new/test/javax/sound/sampled/AudioFormat/PCM_FLOAT_support.java 2014-01-13 16:54:20.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2010, 2014, 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 > @@ -25,7 +25,7 @@ > * @test > * @bug 6944033 > * @summary Tests that PCM_FLOAT encoding is supported > - * @compile -source 1.7 PCM_FLOAT_support.java > + * @compile PCM_FLOAT_support.java > * @run main PCM_FLOAT_support > * @author Alex Menkov > * > --- old/test/sun/management/jmxremote/LocalRMIServerSocketFactoryTest.java 2014-01-13 16:54:21.000000000 -0800 > +++ new/test/sun/management/jmxremote/LocalRMIServerSocketFactoryTest.java 2014-01-13 16:54:21.000000000 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2008, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2008, 2014, 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 > @@ -28,7 +28,7 @@ > * > * @author Daniel Fuchs > * > - * @run compile -XDignore.symbol.file=true -source 1.6 -g LocalRMIServerSocketFactoryTest.java > + * @run compile -XDignore.symbol.file=true -g LocalRMIServerSocketFactoryTest.java > * @run main LocalRMIServerSocketFactoryTest > */ > > > From david.holmes at oracle.com Tue Jan 14 11:29:48 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 Jan 2014 21:29:48 +1000 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: Message-ID: <52D51FAC.8060800@oracle.com> Just a note on this part (I havent looked at the code): > On AIX, the constants used for the polling events (i.e. POLLIN, POLLOUT, ...) are defined to different values than on other operating systems. The problem is however, that these constants are hardcoded as public final static members of various, shared Java classes. Sounds like this should be handled the same way that the other "system constants" are handled - you can either store a platform file in the repo (for cross-compiling) or you generate the class containing the constants at build time. David On 14/01/2014 6:40 PM, Volker Simonis wrote: > Hi, > > could you please review the following changes for the ppc-aix-port > stage/stage-9 repositories (the changes are planned for integration into > ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): > > http://cr.openjdk.java.net/~simonis/webrevs/8031581/ > > I've build and smoke tested without any problems on Linux/x86_64 and > PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64. > > With these changes (and together with the changes from "8028537: PPC64: > Updated jdk/test scripts to understand the AIX os and environment" and > "8031134 : PPC64: implement printing on AIX") our port passes all but > the following 7 jtreg regression tests on AIX (compared to the > Linux/x86_64 baseline from > www.java.net/download/jdk8/testresults/testresults.html > ?): > > java/net/Inet6Address/B6558853.java > java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically) > java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java > java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically) > java/nio/channels/Selector/RacyDeregister.java > sun/security/krb5/auto/Unreachable.java (only on IPv6) > > Thank you and best regards, > Volker > > > Following a detailed description of the various changes: > > > src/share/native/java/util/zip/zip_util.c > src/share/native/sun/management/DiagnosticCommandImpl.c > > * According to ISO C it is perfectly legal for malloc to return zero > if called with a zero argument. Fix various places where malloc can > potentially correctly return zero because it was called with a zero > argument. > * Also fixed |DiagnosticCommandImpl.c| to include |stdlib.h|. This > only fixes a compiler warning on Linux, but on AIX it prevents a VM > crash later on because the return value of |malloc()| will be casted > to |int| which is especially bad if that pointer was bigger than > 32-bit. > > > make/CompileJavaClasses.gmk > > * Also use |PollingWatchService| on AIX. > > > make/lib/NioLibraries.gmk > src/aix/native/sun/nio/ch/AixNativeThread.c > > * Put the implementation for the native methods of |NativeThread| into > |AixNativeThread.c| on AIX. > > > src/solaris/native/sun/nio/ch/PollArrayWrapper.c > src/solaris/native/sun/nio/ch/Net.c > src/aix/classes/sun/nio/ch/AixPollPort.java > src/aix/native/sun/nio/ch/AixPollPort.c > src/aix/native/java/net/aix_close.c > > * On AIX, the constants used for the polling events (i.e. |POLLIN|, > |POLLOUT|, ...) are defined to different values than on other > operating systems. The problem is however, that these constants are > hardcoded as public final static members of various, shared Java > classes. We therefore have to map them from Java to native every > time before calling one of the native poll functions and back to > Java after the call on AIX in order to get the right semantics. > > > src/share/classes/java/nio/file/CopyMoveHelper.java > > * As discussed on the core-libs mailing list (see > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024119.html) > it is not necessary to call |Files.getFileAttributeView()| with any > |linkOptions| because at that place we've already checked that the > target file can not be a symbolic link. This change makes the > implementation more robust on platforms which support symbolic links > but do not support the |O_NOFOLLOW| flag to the |open| system call. > It also makes the JDK pass the |demo/zipfs/basic.sh| test on AIX. > > > src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java > > * Support "compound text" on AIX in the same way like on other Unix > platforms. > > > src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider > > * Define the correct attach provider for AIX. > > > src/solaris/native/java/net/net_util_md.h > src/solaris/native/sun/nio/ch/FileDispatcherImpl.c > src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c > > * AIX needs a workaround for I/O cancellation (see: > http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/close.htm). > "..The |close()| subroutine is blocked until all subroutines which > use the file descriptor return to usr space. For example, when a > thread is calling close and another thread is calling select with > the same file descriptor, the close subroutine does not return until > the select call returns...". To fix this problem, we have to use the > various |NET_| wrappers which are declared in |net_util_md.h| and > defined in |aix_close.c| and we also need some additional wrappers > for |fcntl()|, |read()| and |write()| on AIX. > While the current solution isn't really nice because it introduces > some more AIX-specifc sections in shared code, I think it is the > best way to go for JDK 8 because it imposes the smallest possible > changes and risks for the existing platforms. I'm ready to change > the code to unconditionally use the wrappers for all platforms and > implement the wrappers empty on platforms which don't need any > wrapping. I think it would also be nice to clean up the names (e.g. > |NET_Read()| is currently a wrapper for |recv()| and the |NET_| > prefix is probably not appropriate any more so maybe change it to > something like |IO_|). But again, I'll prefer to keep that as a > follow up change for JDK9. > * Calling |fsync()| on a "read-only" file descriptor on AIX will > result in an error (i.e. "EBADF: The FileDescriptor parameter is not > a valid file descriptor open for writing."). To prevent this error > we have to query if the corresponding file descriptor is writeable. > Notice that at that point we can not access the |writable| attribute > of the corresponding file channel so we have to use |fcntl()|. > > > src/solaris/classes/java/lang/UNIXProcess.java.aix > > * On AIX the implementation is especially tricky, because the > |close()| system call will block if another thread is at the same > time blocked in a file operation (e.g. 'read()') on the same file > descriptor. We therefore combine the AIX |ProcessPipeInputStream| > implemenatation with the |DeferredCloseInputStream| approach used on > Solaris (see |UNIXProcess.java.solaris|). This means that every > potentially blocking operation on the file descriptor increments a > counter before it is executed and decrements it once it finishes. > The 'close()' operation will only be executed if there are no > pending operations. Otherwise it is deferred after the last pending > operation has finished. > > > src/share/transport/socket/socketTransport.c > > * On AIX we have to call |shutdown()| on a socket descriptor before > closing it, otherwise the |close()| call may be blocked. This is the > same problem as described before. Unfortunately the JDI framework > doesn't use the same IO wrappers like other class library components > so we can not easily use the |NET_| abstractions from |aix_close.c| > here. > * Without this small change all JDI regression tests will fail on AIX > because of the way how the tests act as a "debugger" which launches > another VM (the "debugge") which connects itself back to the > debugger. In this scenario the "debugge" can not shut down itself > because one thread will always be blocked in the |close()| call on > one of the communication sockets. > > > src/solaris/native/java/net/NetworkInterface.c > > * Set the scope identifier for IPv6 addresses on AIX. > > > src/solaris/native/java/net/net_util_md.c > > * It turns out that we do not always have to replace |SO_REUSEADDR| on > AIX by |SO_REUSEPORT|. Instead we can simply use the same approach > like BSD and only use |SO_REUSEPORT| additionally, if several > datagram sockets try to bind to the same port. > * Also fixed a comment and removed unused local variables. > * Fixed the obviously inverted assignment |newTime = prevTime;| which > should read |prevTime = newTime;|. Otherwise |prevTime| will never > change and the timeout will be potential reached too fast. > > > src/solaris/native/sun/management/OperatingSystemImpl.c > > * AIX does not understand |/proc/self| so we have to query the real > process ID to access the proc file system. > > > src/solaris/native/sun/nio/ch/DatagramChannelImpl.c > > * On AIX, |connect()| may legally return |EAFNOSUPPORT| if called on a > socket with the address family set to |AF_UNSPEC|. > > From tristan.yan at oracle.com Tue Jan 14 12:40:52 2014 From: tristan.yan at oracle.com (Tristan Yan) Date: Tue, 14 Jan 2014 20:40:52 +0800 Subject: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm In-Reply-To: <52D4A34C.8070502@oracle.com> References: <52CBA203.7080706@oracle.com> <52CBA851.8070008@oracle.com> <52CBB7C0.1040002@oracle.com> <52CBC66B.7000003@oracle.com> <52CBD8B7.8050002@oracle.com> <52CBE530.6070105@oracle.com> <52CE7171.1080407@oracle.com> <2BD1713F-655F-429A-9FC0-A14832D32C9D@oracle.com> <52CE8307.6040606@oracle.com> <52CE87A0.90504@oracle.com> <52CE92B4.4020009@oracle.com> <52CF2438.4090604@oracle.com> <52CF2EA3.9060504@oracle.com> <52D385D1.9020604@oracle.com> <52D4A34C.8070502@oracle.com> Message-ID: <52D53054.9080908@oracle.com> Okay. But I think we all agree we should at least bring this test back for further tacking. http://cr.openjdk.java.net/~tyan/JDK-7027502/webrev.06/ Thank you. Tristan On 01/14/2014 10:39 AM, David Holmes wrote: > On 13/01/2014 4:21 PM, Tristan Yan wrote: >> Hi All >> I add more trace output to track down possible reason of this failure. >> Please help to review it again. >> >> http://cr.openjdk.java.net/~tyan/JDK-7027502/webrev.05/ > > You seem to have dragged in some unrelated changes to ProblemList.txt > > Also I don't see much in the way of trace output. I see two > potentially useful printlns (and one unnecessary one). Further all the > changes from the static variables are still there but we already > determined that they should have no affect on the running of the test, > nor did they explain the failure mode. > > So other than reenabling this test to see if it actually still fails, > I don't see the point of the functional changes. > > Sorry. > David > >> Thank you >> Tristan >> >> On 01/10/2014 07:20 AM, Tristan Yan wrote: >>> Hi David >>> I wasn't able to reproduce this failure either in local or in our same >>> binaries running(This is a continuous running with same JDK binaries). >>> So intention for this code change is bringing this test back; add >>> some debug info and try to avoid possible issues in this test. I agree >>> this code change won't solve the failure happened. But this test was >>> put into ProblemList two years ago better move for this is move out it >>> from ProblemList and trace down the issue in our normal nightly. >>> Thank you >>> Tristan >>> >>> On 01/10/2014 06:35 AM, David Holmes wrote: >>>> On 9/01/2014 10:14 PM, Alan Bateman wrote: >>>>> On 09/01/2014 11:27, David Holmes wrote: >>>>>> >>>>>> Okay I think I get it now. Both MonitorTest and WaitersTest use the >>>>>> Context class, so if both tests run in the same VM the second test >>>>>> will see the static total_turns_taken and "turn" in the state they >>>>>> were left from the first test - hence the second test will always >>>>>> fail. The bug report suggests making the tests othervm to avoid the >>>>>> problem but instead you have changed from using static state to >>>>>> instance state so that there is no interference. >>>>> I haven't been following this one closely but I thought that jtreg >>>>> created a class loader for each test (irrespective of mode) so I >>>>> wouldn't expect statics to be an issue. >>>> >>>> That aside DemoRun forks off its own JVM to run a given test anyway! >>>> >>>> So I don't understand how the proposed fixes could actually be >>>> addressing the hangs that are occurring. Even if the statics were >>>> being shared I don't see how that leads to the failure mode in the >>>> bug report. >>>> >>>> David >>>> >>>>> -Alan. >>> >> From paul.sandoz at oracle.com Tue Jan 14 13:26:38 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 14 Jan 2014 14:26:38 +0100 Subject: Demo for Parallel Core Collection API In-Reply-To: <301A54AB-CD30-4763-8370-540C3B6D1914@oracle.com> References: <2CFB5F41-3C49-42A4-8C80-84F622C230E8@oracle.com> <36B4EDF7-15DE-482C-AFB7-511A03BCDC92@oracle.com> <52B2E3A5.3070807@oracle.com> <301A54AB-CD30-4763-8370-540C3B6D1914@oracle.com> Message-ID: <0BB78F00-5446-4071-B797-083F6BFB9932@oracle.com> Hi Tristan, See below for a patch. The location of the code seems a little out of place with the other code. I would have expected a structure such as: stream/parallel/*.java where the source code is in the default no-package. I am not yet convinced of the value of the RandomPrimeNumber example. In your original code you had a parallel stream invoking another parallel stream in the filter (the simple division to return a prime), this has the effect of actually slowing down the computation due to each calculation fighting for F/J resources and threads. Remove the additional parallelism and it is not clear when eyeballing the execution time that parallel is faster than sequential (it probably is, but it is handy to have obvious examples). A simpler example is to generate a list of probable primes of a certain bit length. IMHO a better example in the category of "slightly more complex" is the rendering of the Mandelbrot set, parallelized along the real or imaginary axis. Once can easily generate some nice ASCII-like art :-) Paul. On Dec 20, 2013, at 6:25 PM, Paul Sandoz wrote: > Thanks, I need to look at this in more detail, but here are some quick comments. > > - recommend you try and avoid using limit with parallel ops, for example the Pi example cam be reformulated as: > > long M = LongStream.range(0, N).parallel().filter(sr -> { > double x = ThreadLocalRandom.current().nextDouble(-1, 1); > double y = ThreadLocalRandom.current().nextDouble(-1, 1); > > return x * x + y * y < R * R; // Don't use need to use sqrt > }).count(); > double pi = (M / N) * 4.0; > > the Primes example could be reformulated as: > > LongStream.range(0, limit).parallel().map(/odd values/).filter(RandomPrimeNumber::isPrime).findAny(); > > you don't need to declare unordered() since findAny implicitly makes the stream unordered by definition. > > The key message here is range has better decomposition characteristics than generate or iterate. > > More later, probably after the break, > Paul. diff -r d56cd0872ec4 src/share/sample/demo/parallel/MonteCarloPI.java --- a/src/share/sample/demo/parallel/MonteCarloPI.java Tue Jan 14 13:34:22 2014 +0100 +++ b/src/share/sample/demo/parallel/MonteCarloPI.java Tue Jan 14 14:15:22 2014 +0100 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2013 Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2014 Oracle and/or its affiliates. All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions @@ -36,16 +36,14 @@ * input validation and proper error handling, might not be present in * this sample code. */ -package demo.parallel; import java.util.concurrent.ThreadLocalRandom; import java.util.stream.LongStream; /** - * This demo shows how to use the parallel mode and the Monte Carlo method to - * calculate the value of PI + * This demo shows how to use parallel streams to approximately calculate the + * value of ? using the Monte Carlo method. * - * @author tyan */ public class MonteCarloPI { @@ -62,39 +60,32 @@ } /** - * Use the Monte Carlo method to calculate the value of PI. basic algorithm + * Use the Monte Carlo method to calculate the value of ?. basic algorithm * is: 1. Draw a square on the ground, then inscribe a circle within it. 2. * Scatter some objects of uniform size (grains of rice or sand) over the * square. 3. Count the total number of objects inside the circle and the - * total number of objects overall. 4. The ratio of the two total is an - * estimate of the ratio of the two areas, which is PI/4. Multiply the - * result by 4 to estimate PI. + * total number of objects overall. 4. The ratio of the two totals is an + * estimate of the ratio of the two areas, which is pi/4. Multiply the + * result by 4 to estimate ?. * - * @param x how many times randomly selected a point - * @return value of ? by x times calculation + * @param n how many times to randomly selected a point + * @return the approximate value of ? */ - private static double pi(long x) { - return LongStream.generate(() -> hit()). - // using parallel mode - parallel(). - // select only x elements - limit(x).sum() - // perform division before multiplication to reduce ovefflow - // risk - / (double) x * 4; + private static double pi(long n) { + long m = LongStream.range(0, n).parallel().filter(i -> hit()).count(); + return (m / (double) n) * 4.0; } /** - * Use ThreadLocalRandom to simulate that whether a point is inside the - * circle or outside the circle + * Use ThreadLocalRandom to simulate that whether a point is inside a + * circle, of radius 1, or outside. * - * @return 1 randomly selected point is inside the circle 0 randomly - * selected point is outside the circle + * @return true if within the circle, otherwise false */ - private static long hit() { + private static boolean hit() { ThreadLocalRandom lr = ThreadLocalRandom.current(); - double x = lr.nextDouble(1.0); - double y = lr.nextDouble(1.0); - return Math.sqrt(y * y + x * x) <= 1.0 ? 1 : 0; + double x = lr.nextDouble(-1.0, 1.0); + double y = lr.nextDouble(-1.0, 1.0); + return x * x + y * y <= 1.0; } } diff -r d56cd0872ec4 src/share/sample/demo/parallel/RandomPrimeNumber.java --- a/src/share/sample/demo/parallel/RandomPrimeNumber.java Tue Jan 14 13:34:22 2014 +0100 +++ b/src/share/sample/demo/parallel/RandomPrimeNumber.java Tue Jan 14 14:15:22 2014 +0100 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2013 Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2014 Oracle and/or its affiliates. All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions @@ -36,19 +36,19 @@ * input validation and proper error handling, might not be present in * this sample code. */ -package demo.parallel; import java.math.BigInteger; import static java.math.BigInteger.ONE; import java.util.BitSet; import java.util.OptionalLong; import java.util.Random; +import java.util.concurrent.ThreadLocalRandom; import java.util.stream.LongStream; /** - * This demo shows how to use the parallel mode to find an unknown length?s - * prime number. The process includes dividing the computation area to an m * n - * segment and then randomly selecting mth and nth segments to try to find a + * This demo shows how to use parallel streams to find a prime number. + * The process includes dividing the computation area to an m * n + * segments and then randomly selecting mth and nth segments to try to find a * prime number in the computation area. If there is no prime number in this * segment, then this process is repeated until the entire segment has been * examined. Either there will be no prime number in this area, or the first @@ -91,7 +91,7 @@ + "prime number"); return; } - Random random = new Random(System.currentTimeMillis()); + Random random = ThreadLocalRandom.current(); /* * Prime number can not be a even number; it must be odd number. */ @@ -140,23 +140,15 @@ long start = first_number.longValue() + randomHighSeg * LOW_BIT_SEGMENT * SEGMENT_SIZE + randomLowSeg * SEGMENT_SIZE; - OptionalLong anyPrime = LongStream.iterate(start, l -> l + 2). - // You must first specify the limit to guarantee that - // the length of the number is an acceptable length. - limit(limit). - // From this point, use parallel(). - // You have to find only one prime number, so the - // order is not important. Also, an unordered stream - // is more efficient than an ordered stream. + + OptionalLong anyPrime = LongStream.range(0, limit). parallel(). - // we only need find one prime number, so keeping - // order is not needed. Also unordered stream is - // more efficient than ordered stream. - unordered(). + // Generate a sequence of limit elements as as follows + // start, start + 2, start + 4, start + 6 + map(n -> n * 2 + start). // Filter only the prime number filter(RandomPrimeNumber::isPrime). - //Stop the process as soon as you find a prime - //number. + // Stop the process as soon as you find a prime number. findAny(); if (anyPrime.isPresent()) { System.out.println(String.format( @@ -176,13 +168,12 @@ /** * Decide if a BigInteger is a prime number * - * @param integer a number + * @param number a number * @return true if integer is a prime number false if integer is not a prime * number */ private static boolean isPrime(long number) { - //This is a parall version that checks if a number is a prime number - return !LongStream.range(2L, Math.round(Math.sqrt(number))).parallel(). + return !LongStream.range(2L, Math.round(Math.sqrt(number))). anyMatch(divisor -> number % divisor == 0); } From Alan.Bateman at oracle.com Tue Jan 14 13:48:42 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 Jan 2014 13:48:42 +0000 Subject: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm In-Reply-To: <52D53054.9080908@oracle.com> References: <52CBA203.7080706@oracle.com> <52CBA851.8070008@oracle.com> <52CBB7C0.1040002@oracle.com> <52CBC66B.7000003@oracle.com> <52CBD8B7.8050002@oracle.com> <52CBE530.6070105@oracle.com> <52CE7171.1080407@oracle.com> <2BD1713F-655F-429A-9FC0-A14832D32C9D@oracle.com> <52CE8307.6040606@oracle.com> <52CE87A0.90504@oracle.com> <52CE92B4.4020009@oracle.com> <52CF2438.4090604@oracle.com> <52CF2EA3.9060504@oracle.com> <52D385D1.9020604@oracle.com> <52D4A34C.8070502@oracle.com> <52D53054.9080908@oracle.com> Message-ID: <52D5403A.10608@oracle.com> On 14/01/2014 12:40, Tristan Yan wrote: > Okay. But I think we all agree we should at least bring this test back > for further tacking. > > http://cr.openjdk.java.net/~tyan/JDK-7027502/webrev.06/ > This make sense so I think this should be pushed. If JDK-7027502 is used for this then the synopsis should be changed as it would otherwise not reflect the fact that this is not fixing the issue, rather just liberating the test with some additional output to help in the event that it fails in the future. -Alan From chris.hegarty at oracle.com Tue Jan 14 13:56:59 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 14 Jan 2014 13:56:59 +0000 Subject: RFR 9 8031708: Windows x86 build failure: JNU_ThrowOutOfMemoryError undefined Message-ID: <2BC1025E-9D37-48E0-B030-F4D4F2AAE8C3@oracle.com> A recent change, JDK-8029007 introduced JNU_ThrowOutOfMemoryError into MessageUtils. The Windows x86 build subsequently fails as follows: Warning (shows the root cause): c:/jprt/T/P1/113753.chhegar/s/jdk/src/share/native/sun/misc/MessageUtils.c(58) : warning C4013: 'JNU_ThrowOutOfMemoryError' undefined; assuming extern returning int Actual linkage failure: ... Creating library c:/cygwin/home/chhegar/sbdata/repos/jdk9/dev/dev/build/windows-x86-normal-server-release/jdk/objs/libjava/java.lib and object c:/cygwin/home/chhegar/sbdata/repos/jdk9/dev/dev/build/windows-x86-normal-server-release/jdk/objs/libjava/java.exp MessageUtils.obj : error LNK2019: unresolved external symbol _JNU_ThrowOutOfMemoryError referenced in function _printToFile c:/cygwin/home/chhegar/sbdata/repos/jdk9/dev/dev/build/windows-x86-normal-server-release/jdk/bin/java.dll : fatal error LNK1120: 1 unresolved externals lib/CoreLibraries.gmk:185: recipe for target `/cygdrive/c/cygwin/home/chhegar/sbdata/repos/jdk9/dev/dev/build/windows-x86-normal-server-release/jdk/bin/java.dll' failed make[2]: *** [/cygdrive/c/cygwin/home/chhegar/sbdata/repos/jdk9/dev/dev/build/windows-x86-normal-server-release/jdk/bin/java.dll] Error 96 BuildJdk.gmk:70: recipe for target `libs-only' failed make[1]: *** [libs-only] Error 2 /cygdrive/c/cygwin/home/chhegar/sbdata/repos/jdk9/dev/dev//make/Main.gmk:115: recipe for target `jdk-only' failed make: *** [jdk-only] Error 2 Trivial fix. Include the header that defines the function ( whose return type is void ): diff --git a/src/share/native/sun/misc/MessageUtils.c b/src/share/native/sun/misc/MessageUtils.c --- a/src/share/native/sun/misc/MessageUtils.c +++ b/src/share/native/sun/misc/MessageUtils.c @@ -25,6 +25,7 @@ #include #include +#include #include #include #include -Chris. From tristan.yan at oracle.com Tue Jan 14 13:57:45 2014 From: tristan.yan at oracle.com (Tristan Yan) Date: Tue, 14 Jan 2014 21:57:45 +0800 Subject: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm In-Reply-To: <52D5403A.10608@oracle.com> References: <52CBA203.7080706@oracle.com> <52CBA851.8070008@oracle.com> <52CBB7C0.1040002@oracle.com> <52CBC66B.7000003@oracle.com> <52CBD8B7.8050002@oracle.com> <52CBE530.6070105@oracle.com> <52CE7171.1080407@oracle.com> <2BD1713F-655F-429A-9FC0-A14832D32C9D@oracle.com> <52CE8307.6040606@oracle.com> <52CE87A0.90504@oracle.com> <52CE92B4.4020009@oracle.com> <52CF2438.4090604@oracle.com> <52CF2EA3.9060504@oracle.com> <52D385D1.9020604@oracle.com> <52D4A34C.8070502@oracle.com> <52D53054.9080908@oracle.com> <52D5403A.10608@oracle.com> Message-ID: <52D54259.6000509@oracle.com> Thank you Alan. I have changed this bug's synopsis. Is it okay you could push this? Tristan On 01/14/2014 09:48 PM, Alan Bateman wrote: > On 14/01/2014 12:40, Tristan Yan wrote: >> Okay. But I think we all agree we should at least bring this test >> back for further tacking. >> >> http://cr.openjdk.java.net/~tyan/JDK-7027502/webrev.06/ >> > This make sense so I think this should be pushed. If JDK-7027502 is > used for this then the synopsis should be changed as it would > otherwise not reflect the fact that this is not fixing the issue, > rather just liberating the test with some additional output to help in > the event that it fails in the future. > > -Alan > From Alan.Bateman at oracle.com Tue Jan 14 14:03:15 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 Jan 2014 14:03:15 +0000 Subject: RFR 9 8031708: Windows x86 build failure: JNU_ThrowOutOfMemoryError undefined In-Reply-To: <2BC1025E-9D37-48E0-B030-F4D4F2AAE8C3@oracle.com> References: <2BC1025E-9D37-48E0-B030-F4D4F2AAE8C3@oracle.com> Message-ID: <52D543A3.2010400@oracle.com> On 14/01/2014 13:56, Chris Hegarty wrote: > A recent change, JDK-8029007 introduced JNU_ThrowOutOfMemoryError into MessageUtils. The Windows x86 build subsequently fails as follows: > > Warning (shows the root cause): > c:/jprt/T/P1/113753.chhegar/s/jdk/src/share/native/sun/misc/MessageUtils.c(58) : warning C4013: 'JNU_ThrowOutOfMemoryError' undefined; assuming extern returning int > > This looks okay, I assume there must be a different version of VC++ being used here. -Alan From chris.hegarty at oracle.com Tue Jan 14 14:06:42 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 14 Jan 2014 14:06:42 +0000 Subject: RFR 9 8031708: Windows x86 build failure: JNU_ThrowOutOfMemoryError undefined In-Reply-To: <52D543A3.2010400@oracle.com> References: <2BC1025E-9D37-48E0-B030-F4D4F2AAE8C3@oracle.com> <52D543A3.2010400@oracle.com> Message-ID: <30A6C401-16AB-41EA-A867-F1B4639E2303@oracle.com> On 14 Jan 2014, at 14:03, Alan Bateman wrote: > On 14/01/2014 13:56, Chris Hegarty wrote: >> A recent change, JDK-8029007 introduced JNU_ThrowOutOfMemoryError into MessageUtils. The Windows x86 build subsequently fails as follows: >> >> Warning (shows the root cause): >> c:/jprt/T/P1/113753.chhegar/s/jdk/src/share/native/sun/misc/MessageUtils.c(58) : warning C4013: 'JNU_ThrowOutOfMemoryError' undefined; assuming extern returning int >> >> > This looks okay, I assume there must be a different version of VC++ being used here. Thanks of the review Alan. A warning about the implicit definition is outputted on all platforms, but only seems fatal during linking on Windows x86. I assume it is related to different compiler/linker versions. Either way, the fix is trivial and gets us back up and running on Windows. -Chris. > > -Alan From volker.simonis at gmail.com Tue Jan 14 14:10:27 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 14 Jan 2014 15:10:27 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: <52D51FAC.8060800@oracle.com> References: <52D51FAC.8060800@oracle.com> Message-ID: On Tue, Jan 14, 2014 at 12:29 PM, David Holmes wrote: > Just a note on this part (I havent looked at the code): > > > On AIX, the constants used for the polling events (i.e. POLLIN, POLLOUT, >> ...) are defined to different values than on other operating systems. The >> problem is however, that these constants are hardcoded as public final >> static members of various, shared Java classes. >> > > Sounds like this should be handled the same way that the other "system > constants" are handled - you can either store a platform file in the repo > (for cross-compiling) or you generate the class containing the constants at > build time. > > Hi David, thanks for your comments. That sound like a good idea but I'm not sure if it would make sense to duplicate the following files: src/share/classes/sun/nio/ch/AbstractPollArrayWrapper.java: src/solaris/classes/sun/nio/ch/Port.java because of this. Do you have a concrete example where Java-classes are being generated with different constants in the class library build? Both solutions would result in different class files on Aix and other Unix variants. What do you think about assigning the concrete values depending on 'os.name' in the static initializers of the corresponding classes? I think that shouldn't introduce too much overhead and I could get rid of all the ugly conversion code. Regards, Volker > David > > > On 14/01/2014 6:40 PM, Volker Simonis wrote: > >> Hi, >> >> could you please review the following changes for the ppc-aix-port >> stage/stage-9 repositories (the changes are planned for integration into >> ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): >> >> http://cr.openjdk.java.net/~simonis/webrevs/8031581/ >> >> I've build and smoke tested without any problems on Linux/x86_64 and >> PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64. >> >> With these changes (and together with the changes from "8028537: PPC64: >> Updated jdk/test scripts to understand the AIX os and environment" and >> "8031134 : PPC64: implement printing on AIX") our port passes all but >> the following 7 jtreg regression tests on AIX (compared to the >> Linux/x86_64 baseline from >> www.java.net/download/jdk8/testresults/testresults.html >> ?): >> >> >> java/net/Inet6Address/B6558853.java >> java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically) >> java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java >> java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically) >> java/nio/channels/Selector/RacyDeregister.java >> sun/security/krb5/auto/Unreachable.java (only on IPv6) >> >> Thank you and best regards, >> Volker >> >> >> Following a detailed description of the various changes: >> >> >> src/share/native/java/util/zip/zip_util.c >> src/share/native/sun/management/DiagnosticCommandImpl.c >> >> * According to ISO C it is perfectly legal for malloc to return zero >> >> if called with a zero argument. Fix various places where malloc can >> potentially correctly return zero because it was called with a zero >> argument. >> * Also fixed |DiagnosticCommandImpl.c| to include |stdlib.h|. This >> >> only fixes a compiler warning on Linux, but on AIX it prevents a VM >> crash later on because the return value of |malloc()| will be casted >> to |int| which is especially bad if that pointer was bigger than >> 32-bit. >> >> >> make/CompileJavaClasses.gmk >> >> * Also use |PollingWatchService| on AIX. >> >> >> make/lib/NioLibraries.gmk >> src/aix/native/sun/nio/ch/AixNativeThread.c >> >> * Put the implementation for the native methods of |NativeThread| into >> >> |AixNativeThread.c| on AIX. >> >> >> src/solaris/native/sun/nio/ch/PollArrayWrapper.c >> src/solaris/native/sun/nio/ch/Net.c >> src/aix/classes/sun/nio/ch/AixPollPort.java >> src/aix/native/sun/nio/ch/AixPollPort.c >> src/aix/native/java/net/aix_close.c >> >> * On AIX, the constants used for the polling events (i.e. |POLLIN|, >> |POLLOUT|, ...) are defined to different values than on other >> >> operating systems. The problem is however, that these constants are >> hardcoded as public final static members of various, shared Java >> classes. We therefore have to map them from Java to native every >> time before calling one of the native poll functions and back to >> Java after the call on AIX in order to get the right semantics. >> >> >> src/share/classes/java/nio/file/CopyMoveHelper.java >> >> * As discussed on the core-libs mailing list (see >> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013- >> December/024119.html) >> it is not necessary to call |Files.getFileAttributeView()| with any >> |linkOptions| because at that place we've already checked that the >> target file can not be a symbolic link. This change makes the >> implementation more robust on platforms which support symbolic links >> but do not support the |O_NOFOLLOW| flag to the |open| system call. >> It also makes the JDK pass the |demo/zipfs/basic.sh| test on AIX. >> >> >> src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java >> >> * Support "compound text" on AIX in the same way like on other Unix >> platforms. >> >> >> src/share/classes/sun/tools/attach/META-INF/services/com. >> sun.tools.attach.spi.AttachProvider >> >> * Define the correct attach provider for AIX. >> >> >> src/solaris/native/java/net/net_util_md.h >> src/solaris/native/sun/nio/ch/FileDispatcherImpl.c >> src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c >> >> * AIX needs a workaround for I/O cancellation (see: >> >> http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index. >> jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/close.htm). >> "..The |close()| subroutine is blocked until all subroutines which >> use the file descriptor return to usr space. For example, when a >> thread is calling close and another thread is calling select with >> the same file descriptor, the close subroutine does not return until >> the select call returns...". To fix this problem, we have to use the >> various |NET_| wrappers which are declared in |net_util_md.h| and >> defined in |aix_close.c| and we also need some additional wrappers >> for |fcntl()|, |read()| and |write()| on AIX. >> >> While the current solution isn't really nice because it introduces >> some more AIX-specifc sections in shared code, I think it is the >> best way to go for JDK 8 because it imposes the smallest possible >> changes and risks for the existing platforms. I'm ready to change >> the code to unconditionally use the wrappers for all platforms and >> implement the wrappers empty on platforms which don't need any >> wrapping. I think it would also be nice to clean up the names (e.g. >> |NET_Read()| is currently a wrapper for |recv()| and the |NET_| >> prefix is probably not appropriate any more so maybe change it to >> something like |IO_|). But again, I'll prefer to keep that as a >> >> follow up change for JDK9. >> * Calling |fsync()| on a "read-only" file descriptor on AIX will >> >> result in an error (i.e. "EBADF: The FileDescriptor parameter is not >> a valid file descriptor open for writing."). To prevent this error >> we have to query if the corresponding file descriptor is writeable. >> Notice that at that point we can not access the |writable| attribute >> of the corresponding file channel so we have to use |fcntl()|. >> >> >> src/solaris/classes/java/lang/UNIXProcess.java.aix >> >> * On AIX the implementation is especially tricky, because the >> >> |close()| system call will block if another thread is at the same >> time blocked in a file operation (e.g. 'read()') on the same file >> descriptor. We therefore combine the AIX |ProcessPipeInputStream| >> implemenatation with the |DeferredCloseInputStream| approach used on >> Solaris (see |UNIXProcess.java.solaris|). This means that every >> >> potentially blocking operation on the file descriptor increments a >> counter before it is executed and decrements it once it finishes. >> The 'close()' operation will only be executed if there are no >> pending operations. Otherwise it is deferred after the last pending >> operation has finished. >> >> >> src/share/transport/socket/socketTransport.c >> >> * On AIX we have to call |shutdown()| on a socket descriptor before >> >> closing it, otherwise the |close()| call may be blocked. This is the >> same problem as described before. Unfortunately the JDI framework >> doesn't use the same IO wrappers like other class library components >> so we can not easily use the |NET_| abstractions from |aix_close.c| >> here. >> * Without this small change all JDI regression tests will fail on AIX >> >> because of the way how the tests act as a "debugger" which launches >> another VM (the "debugge") which connects itself back to the >> debugger. In this scenario the "debugge" can not shut down itself >> because one thread will always be blocked in the |close()| call on >> one of the communication sockets. >> >> >> src/solaris/native/java/net/NetworkInterface.c >> >> * Set the scope identifier for IPv6 addresses on AIX. >> >> >> src/solaris/native/java/net/net_util_md.c >> >> * It turns out that we do not always have to replace |SO_REUSEADDR| on >> AIX by |SO_REUSEPORT|. Instead we can simply use the same approach >> >> like BSD and only use |SO_REUSEPORT| additionally, if several >> datagram sockets try to bind to the same port. >> * Also fixed a comment and removed unused local variables. >> * Fixed the obviously inverted assignment |newTime = prevTime;| which >> >> should read |prevTime = newTime;|. Otherwise |prevTime| will never >> change and the timeout will be potential reached too fast. >> >> >> src/solaris/native/sun/management/OperatingSystemImpl.c >> >> * AIX does not understand |/proc/self| so we have to query the real >> >> process ID to access the proc file system. >> >> >> src/solaris/native/sun/nio/ch/DatagramChannelImpl.c >> >> * On AIX, |connect()| may legally return |EAFNOSUPPORT| if called on a >> >> socket with the address family set to |AF_UNSPEC|. >> >> >> From dan.xu at oracle.com Tue Jan 14 15:52:44 2014 From: dan.xu at oracle.com (Dan Xu) Date: Tue, 14 Jan 2014 07:52:44 -0800 Subject: RFR 9 8031708: Windows x86 build failure: JNU_ThrowOutOfMemoryError undefined In-Reply-To: <30A6C401-16AB-41EA-A867-F1B4639E2303@oracle.com> References: <2BC1025E-9D37-48E0-B030-F4D4F2AAE8C3@oracle.com> <52D543A3.2010400@oracle.com> <30A6C401-16AB-41EA-A867-F1B4639E2303@oracle.com> Message-ID: <52D55D4C.7000502@oracle.com> Hi Chris, Sorry that I did not check my previous change carefully on Windows. Thanks for fixing the issue. The change looks good to me. -Dan On 01/14/2014 06:06 AM, Chris Hegarty wrote: > On 14 Jan 2014, at 14:03, Alan Bateman wrote: > >> On 14/01/2014 13:56, Chris Hegarty wrote: >>> A recent change, JDK-8029007 introduced JNU_ThrowOutOfMemoryError into MessageUtils. The Windows x86 build subsequently fails as follows: >>> >>> Warning (shows the root cause): >>> c:/jprt/T/P1/113753.chhegar/s/jdk/src/share/native/sun/misc/MessageUtils.c(58) : warning C4013: 'JNU_ThrowOutOfMemoryError' undefined; assuming extern returning int >>> >>> >> This looks okay, I assume there must be a different version of VC++ being used here. > Thanks of the review Alan. > > A warning about the implicit definition is outputted on all platforms, but only seems fatal during linking on Windows x86. I assume it is related to different compiler/linker versions. Either way, the fix is trivial and gets us back up and running on Windows. > > -Chris. > >> -Alan From roger.riggs at oracle.com Tue Jan 14 15:54:37 2014 From: roger.riggs at oracle.com (roger riggs) Date: Tue, 14 Jan 2014 10:54:37 -0500 Subject: RFR: (8030875) Macros for checking and returning on exceptions In-Reply-To: <52D4A642.7090404@oracle.com> References: <52D013B9.40101@oracle.com> <52D4A642.7090404@oracle.com> Message-ID: <52D55DBD.3030502@oracle.com> Hi David, The CHECK_RETURN macros have existed in java.net for some time and I have not seen any empty statement warnings. The CHECK_EXCEPTION macros are new and does not have any uses yet. I don't plan to do any wholesale modification of current sources. The macros always produce a valid statement; (though my c/c++ may be a bit rusty). (Note that it has been requested to rename the macros to include a JNU_prefix to be consistent with other macros in jni_util.h. I will propose a separate set of changes for that). Roger On 1/13/2014 9:51 PM, David Holmes wrote: > Hi Roger, > >> webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-check-exception-8030875/ > > Do these macro definitions not cause "empty statement" warnings from > the compiler? (Existing ones have the same problem I guess) > > Also I don't see any use of the CHECK_EXCEPTION macros? In fact the > bulk of changes here seem completely unrelated to the "exception" > aspect of this CR. > > Cheers, > David > >> [1] https://bugs.openjdk.java.net/browse/JDK-8030875 From joe.darcy at oracle.com Tue Jan 14 16:45:00 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 14 Jan 2014 08:45:00 -0800 Subject: JDK 9 RFR of JDK-8031651: Remove unneeded -source and -target flags in jdk repo regression tests In-Reply-To: <781B81A3-A854-4346-AF9D-DB372AC02B59@oracle.com> References: <52D48EB8.70009@oracle.com> <781B81A3-A854-4346-AF9D-DB372AC02B59@oracle.com> Message-ID: <52D5698C.4090300@oracle.com> Hi Chris, I think it is easier to use the exact version of the change in the 166 CVS. I've reverted the java/util/concurrent parts of my patch so a separate bug can be used for the next sync with 166. Thanks, -Joe On 01/14/2014 03:27 AM, Chris Hegarty wrote: > Since Martin has removed completely the '@compile -source 1.5 XXX? lines from the 166 CVS, you can amend your patch to do the same, or we can file a separate bug to bring in these change. Whatever suits you, just let me know. > > -Chris. > > On 14 Jan 2014, at 02:30, Martin Buchholz wrote: > >> All occurrences of >> @compile -source 1.5 >> have been removed from jsr166 CVS. >> >> >> On Mon, Jan 13, 2014 at 5:11 PM, Joe Darcy wrote: >> Hello, >> >> Per the policy set forth in >> >> JEP 182: Policy for Retiring javac -source and -target Options >> http://openjdk.java.net/jeps/182 >> >> in JDK 9, javac will only recognize javac source and target value of 6/1.6 and higher. Therefore, uses of earlier options in the JDK regression tests need to be modified. >> >> Please review the first pass at fixing this before support for the old source and target values is removed: >> >> JDK-8031651 : Remove unneeded -source and -target flags in jdk repo regression tests >> http://cr.openjdk.java.net/~darcy/8031651.2/ >> >> Patch also below. >> >> A few comments on the changes. In java/security/cert/* the tests were intentionally creating a corrupted set to make sure it was rejected properly. >> >> Chris, do the changes in java/util/concurrent need to go into Doug's repo first? >> >> I had to wrestle a bit for the code in javax/imageio/metadata/GetObjectMinValue to make the generics work out. >> >> For test/java/util/Locale/Bug4175998Test.java, as of source 6, an encoding error, even in a comment is a javac error. Therefore, a non-ASCKII character is replaced by a Unicode escape. >> >> Kumar, the pack200 tests uses "-target 5"; can you look into updating this to target 6 or later? >> >> Thanks, >> >> -Joe >> >> --- old/test/demo/jvmti/hprof/StackMapTableTest.java 2014-01-13 16:54:09.000000000 -0800 >> +++ new/test/demo/jvmti/hprof/StackMapTableTest.java 2014-01-13 16:54:09.000000000 -0800 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2005, 2009, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2005, 2014, 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 >> @@ -27,7 +27,7 @@ >> * @summary Test jvmti hprof and java_crw_demo with StackMapTable attributes >> * >> * @compile ../DemoRun.java >> - * @compile -source 7 -g:lines HelloWorld.java >> + * @compile -g:lines HelloWorld.java >> * @build StackMapTableTest >> * @run main StackMapTableTest HelloWorld >> */ >> --- old/test/java/lang/reflect/OldenCompilingWithDefaults.java 2014-01-13 16:54:10.000000000 -0800 >> +++ new/test/java/lang/reflect/OldenCompilingWithDefaults.java 2014-01-13 16:54:10.000000000 -0800 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2013, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2013, 2014, 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 >> @@ -25,7 +25,6 @@ >> * @test >> * @bug 8009267 >> * @summary Verify uses of isAnnotationPresent compile under older source versions >> - * @compile -source 1.5 -target 1.5 OldenCompilingWithDefaults.java >> * @compile -source 1.6 -target 1.6 OldenCompilingWithDefaults.java >> * @compile -source 1.7 -target 1.7 OldenCompilingWithDefaults.java >> * @compile OldenCompilingWithDefaults.java >> --- old/test/java/security/cert/PKIXBuilderParameters/InvalidParameters.java 2014-01-13 16:54:10.000000000 -0800 >> +++ new/test/java/security/cert/PKIXBuilderParameters/InvalidParameters.java 2014-01-13 16:54:10.000000000 -0800 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2001, 2004, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2001, 2014, 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 >> @@ -21,16 +21,17 @@ >> * questions. >> */ >> >> -/** >> +/* >> * @test >> * @test 4422738 >> - * @compile -source 1.4 InvalidParameters.java >> + * @compile InvalidParameters.java >> * @run main InvalidParameters >> * @summary Make sure PKIXBuilderParameters(Set) detects invalid >> * parameters and throws correct exceptions >> */ >> import java.security.InvalidAlgorithmParameterException; >> import java.security.cert.PKIXBuilderParameters; >> +import java.security.cert.TrustAnchor; >> import java.util.Collections; >> import java.util.Set; >> >> @@ -53,8 +54,10 @@ >> >> // make sure Set of invalid objects throws ClassCastException >> try { >> + @SuppressWarnings("unchecked") // Knowingly do something bad >> + Set badSet = (Set) (Set) Collections.singleton(new String()); >> PKIXBuilderParameters p = >> - new PKIXBuilderParameters(Collections.singleton(new String()), null); >> + new PKIXBuilderParameters(badSet, null); >> throw new Exception("should have thrown ClassCastException"); >> } catch (ClassCastException cce) { } >> } >> --- old/test/java/security/cert/PKIXParameters/InvalidParameters.java 2014-01-13 16:54:11.000000000 -0800 >> +++ new/test/java/security/cert/PKIXParameters/InvalidParameters.java 2014-01-13 16:54:10.000000000 -0800 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2001, 2004, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2001, 2014, 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 >> @@ -24,7 +24,7 @@ >> /** >> * @test >> * @test 4422738 >> - * @compile -source 1.4 InvalidParameters.java >> + * @compile InvalidParameters.java >> * @run main InvalidParameters >> * @summary Make sure PKIXParameters(Set) and setTrustAnchors() detects invalid >> * parameters and throws correct exceptions >> @@ -64,12 +64,14 @@ >> } catch (NullPointerException npe) { } >> >> // make sure Set of invalid objects throws ClassCastException >> + @SuppressWarnings("unchecked") // Knowingly do something bad >> + Set badSet = (Set) (Set) Collections.singleton(new String()); >> try { >> - PKIXParameters p = new PKIXParameters(Collections.singleton(new String())); >> + PKIXParameters p = new PKIXParameters(badSet); >> throw new Exception("should have thrown ClassCastException"); >> } catch (ClassCastException cce) { } >> try { >> - params.setTrustAnchors(Collections.singleton(new String())); >> + params.setTrustAnchors(badSet); >> throw new Exception("should have thrown ClassCastException"); >> } catch (ClassCastException cce) { } >> } >> --- old/test/java/util/Locale/Bug4175998Test.java 2014-01-13 16:54:11.000000000 -0800 >> +++ new/test/java/util/Locale/Bug4175998Test.java 2014-01-13 16:54:11.000000000 -0800 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2007, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2007, 2014, 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 >> @@ -20,13 +20,15 @@ >> * or visit www.oracle.com if you need additional information or have any >> * questions. >> */ >> + >> /* >> - @test >> - @summary test ISO639-2 language codes >> - @compile -encoding ascii -source 5 Bug4175998Test.java >> - @run main Bug4175998Test >> - @bug 4175998 >> -*/ >> + * @test >> + * @summary test ISO639-2 language codes >> + * @compile -encoding ascii Bug4175998Test.java >> + * @run main Bug4175998Test >> + * @bug 4175998 >> + */ >> + >> /* >> * >> * >> @@ -731,7 +733,7 @@ >> pon pon Pohnpeian >> por por Portuguese >> pra pra Prakrit languages >> -pro pro Proven?al, Old (to 1500) >> +pro pro Proven\u00E7al, Old (to 1500) >> pus pus Pushto >> qaa-qtz qaa-qtz Reserved for local use >> que que Quechua >> --- old/test/java/util/concurrent/BlockingQueue/CancelledProducerConsumerLoops.java 2014-01-13 16:54:12.000000000 -0800 >> +++ new/test/java/util/concurrent/BlockingQueue/CancelledProducerConsumerLoops.java 2014-01-13 16:54:11.000000000 -0800 >> @@ -34,7 +34,7 @@ >> /* >> * @test >> * @bug 4486658 >> - * @compile -source 1.5 CancelledProducerConsumerLoops.java >> + * @compile CancelledProducerConsumerLoops.java >> * @run main/timeout=7000 CancelledProducerConsumerLoops >> * @summary Checks for responsiveness of blocking queues to cancellation. >> * Runs under the assumption that ITERS computations require more than >> --- old/test/java/util/concurrent/BlockingQueue/MultipleProducersSingleConsumerLoops.java 2014-01-13 16:54:12.000000000 -0800 >> +++ new/test/java/util/concurrent/BlockingQueue/MultipleProducersSingleConsumerLoops.java 2014-01-13 16:54:12.000000000 -0800 >> @@ -34,7 +34,7 @@ >> /* >> * @test >> * @bug 4486658 >> - * @compile -source 1.5 MultipleProducersSingleConsumerLoops.java >> + * @compile MultipleProducersSingleConsumerLoops.java >> * @run main/timeout=3600 MultipleProducersSingleConsumerLoops >> * @summary multiple producers and single consumer using blocking queues >> */ >> --- old/test/java/util/concurrent/BlockingQueue/ProducerConsumerLoops.java 2014-01-13 16:54:12.000000000 -0800 >> +++ new/test/java/util/concurrent/BlockingQueue/ProducerConsumerLoops.java 2014-01-13 16:54:12.000000000 -0800 >> @@ -34,7 +34,7 @@ >> /* >> * @test >> * @bug 4486658 >> - * @compile -source 1.5 ProducerConsumerLoops.java >> + * @compile ProducerConsumerLoops.java >> * @run main/timeout=3600 ProducerConsumerLoops >> * @summary multiple producers and consumers using blocking queues >> */ >> --- old/test/java/util/concurrent/BlockingQueue/SingleProducerMultipleConsumerLoops.java 2014-01-13 16:54:13.000000000 -0800 >> +++ new/test/java/util/concurrent/BlockingQueue/SingleProducerMultipleConsumerLoops.java 2014-01-13 16:54:13.000000000 -0800 >> @@ -34,7 +34,7 @@ >> /* >> * @test >> * @bug 4486658 >> - * @compile -source 1.5 SingleProducerMultipleConsumerLoops.java >> + * @compile SingleProducerMultipleConsumerLoops.java >> * @run main/timeout=600 SingleProducerMultipleConsumerLoops >> * @summary check ordering for blocking queues with 1 producer and multiple consumers >> */ >> --- old/test/java/util/concurrent/ConcurrentHashMap/MapCheck.java 2014-01-13 16:54:14.000000000 -0800 >> +++ new/test/java/util/concurrent/ConcurrentHashMap/MapCheck.java 2014-01-13 16:54:13.000000000 -0800 >> @@ -34,7 +34,7 @@ >> /* >> * @test >> * @bug 4486658 >> - * @compile -source 1.5 MapCheck.java >> + * @compile MapCheck.java >> * @run main/timeout=240 MapCheck >> * @summary Times and checks basic map operations >> */ >> --- old/test/java/util/concurrent/ConcurrentHashMap/MapLoops.java 2014-01-13 16:54:14.000000000 -0800 >> +++ new/test/java/util/concurrent/ConcurrentHashMap/MapLoops.java 2014-01-13 16:54:14.000000000 -0800 >> @@ -34,7 +34,7 @@ >> /* >> * @test >> * @bug 4486658 >> - * @compile -source 1.5 MapLoops.java >> + * @compile MapLoops.java >> * @run main/timeout=1600 MapLoops >> * @summary Exercise multithreaded maps, by default ConcurrentHashMap. >> * Multithreaded hash table test. Each thread does a random walk >> --- old/test/java/util/concurrent/Exchanger/ExchangeLoops.java 2014-01-13 16:54:15.000000000 -0800 >> +++ new/test/java/util/concurrent/Exchanger/ExchangeLoops.java 2014-01-13 16:54:14.000000000 -0800 >> @@ -34,7 +34,7 @@ >> /* >> * @test >> * @bug 4486658 >> - * @compile -source 1.5 ExchangeLoops.java >> + * @compile ExchangeLoops.java >> * @run main/timeout=720 ExchangeLoops >> * @summary checks to make sure a pipeline of exchangers passes data. >> */ >> --- old/test/java/util/concurrent/ExecutorCompletionService/ExecutorCompletionServiceLoops.java 2014-01-13 16:54:15.000000000 -0800 >> +++ new/test/java/util/concurrent/ExecutorCompletionService/ExecutorCompletionServiceLoops.java 2014-01-13 16:54:15.000000000 -0800 >> @@ -34,7 +34,7 @@ >> /* >> * @test >> * @bug 4965960 >> - * @compile -source 1.5 ExecutorCompletionServiceLoops.java >> + * @compile ExecutorCompletionServiceLoops.java >> * @run main/timeout=3600 ExecutorCompletionServiceLoops >> * @summary Exercise ExecutorCompletionServiceLoops >> */ >> --- old/test/java/util/concurrent/FutureTask/CancelledFutureLoops.java 2014-01-13 16:54:16.000000000 -0800 >> +++ new/test/java/util/concurrent/FutureTask/CancelledFutureLoops.java 2014-01-13 16:54:15.000000000 -0800 >> @@ -34,7 +34,7 @@ >> /* >> * @test >> * @bug 4486658 >> - * @compile -source 1.5 CancelledFutureLoops.java >> + * @compile CancelledFutureLoops.java >> * @run main/timeout=2000 CancelledFutureLoops >> * @summary Checks for responsiveness of futures to cancellation. >> * Runs under the assumption that ITERS computations require more than >> --- old/test/java/util/concurrent/atomic/VMSupportsCS8.java 2014-01-13 16:54:16.000000000 -0800 >> +++ new/test/java/util/concurrent/atomic/VMSupportsCS8.java 2014-01-13 16:54:16.000000000 -0800 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2004, 2010, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2004, 2014, 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 >> @@ -24,7 +24,7 @@ >> /* >> * @test >> * @bug 4992443 4994819 >> - * @compile -source 1.5 VMSupportsCS8.java >> + * @compile VMSupportsCS8.java >> * @run main VMSupportsCS8 >> * @summary Checks that the value of VMSupportsCS8 matches system properties. >> */ >> --- old/test/java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java 2014-01-13 16:54:16.000000000 -0800 >> +++ new/test/java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java 2014-01-13 16:54:16.000000000 -0800 >> @@ -34,7 +34,7 @@ >> /* >> * @test >> * @bug 4486658 >> - * @compile -source 1.5 CancelledLockLoops.java >> + * @compile CancelledLockLoops.java >> * @run main/timeout=2800 CancelledLockLoops >> * @summary tests lockInterruptibly. >> * Checks for responsiveness of locks to interrupts. Runs under that >> --- old/test/java/util/concurrent/locks/ReentrantLock/LockOncePerThreadLoops.java 2014-01-13 16:54:17.000000000 -0800 >> +++ new/test/java/util/concurrent/locks/ReentrantLock/LockOncePerThreadLoops.java 2014-01-13 16:54:17.000000000 -0800 >> @@ -34,7 +34,7 @@ >> /* >> * @test >> * @bug 4486658 >> - * @compile -source 1.5 LockOncePerThreadLoops.java >> + * @compile LockOncePerThreadLoops.java >> * @run main/timeout=15000 LockOncePerThreadLoops >> * @summary Checks for missed signals by locking and unlocking each of an array of locks once per thread >> */ >> --- old/test/java/util/concurrent/locks/ReentrantLock/SimpleReentrantLockLoops.java 2014-01-13 16:54:17.000000000 -0800 >> +++ new/test/java/util/concurrent/locks/ReentrantLock/SimpleReentrantLockLoops.java 2014-01-13 16:54:17.000000000 -0800 >> @@ -34,7 +34,7 @@ >> /* >> * @test >> * @bug 4486658 >> - * @compile -source 1.5 SimpleReentrantLockLoops.java >> + * @compile SimpleReentrantLockLoops.java >> * @run main/timeout=4500 SimpleReentrantLockLoops >> * @summary multiple threads using a single lock >> */ >> --- old/test/java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java 2014-01-13 16:54:18.000000000 -0800 >> +++ new/test/java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java 2014-01-13 16:54:17.000000000 -0800 >> @@ -34,7 +34,7 @@ >> /* >> * @test >> * @bug 4486658 5031862 >> - * @compile -source 1.5 TimeoutLockLoops.java >> + * @compile TimeoutLockLoops.java >> * @run main TimeoutLockLoops >> * @summary Checks for responsiveness of locks to timeouts. >> * Runs under the assumption that ITERS computations require more than >> --- old/test/java/util/concurrent/locks/ReentrantReadWriteLock/MapLoops.java 2014-01-13 16:54:18.000000000 -0800 >> +++ new/test/java/util/concurrent/locks/ReentrantReadWriteLock/MapLoops.java 2014-01-13 16:54:18.000000000 -0800 >> @@ -34,7 +34,7 @@ >> /* >> * @test >> * @bug 4486658 >> - * @compile -source 1.5 MapLoops.java >> + * @compile MapLoops.java >> * @run main/timeout=4700 MapLoops >> * @summary Exercise multithreaded maps, by default ConcurrentHashMap. >> * Multithreaded hash table test. Each thread does a random walk >> --- old/test/javax/imageio/metadata/GetObjectMinValue.java 2014-01-13 16:54:20.000000000 -0800 >> +++ new/test/javax/imageio/metadata/GetObjectMinValue.java 2014-01-13 16:54:19.000000000 -0800 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2012, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2012, 2014, 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 >> @@ -24,14 +24,12 @@ >> /* >> * @test >> * @bug 4429875 7186799 >> - * @compile -source 1.4 GetObjectMinValue.java >> + * @compile GetObjectMinValue.java >> * @run main GetObjectMinValue >> * @summary Tests the getObject{Min,Max}Value method of >> * IIOMetadataFormatImpl for an inclusive range >> */ >> >> -// Compiled with -source 1.4 to work around javac bug 5041233 >> - >> import javax.imageio.metadata.IIOMetadataFormatImpl; >> import javax.imageio.ImageTypeSpecifier; >> >> @@ -79,13 +77,13 @@ >> } >> >> public void addObjectValue(String elementName, >> - Class classType, Object defaultValue, >> + Class classType, Integer defaultValue, >> Comparable minValue, Comparable maxValue, >> boolean minInclusive, boolean maxInclusive) { >> - super.addObjectValue(elementName, >> - classType, defaultValue, >> - minValue, maxValue, >> - minInclusive, maxInclusive); >> + super.addObjectValue(elementName, >> + (Class)classType, defaultValue, >> + (Comparable) minValue, (Comparable) maxValue, >> + minInclusive, maxInclusive); >> } >> >> public boolean canNodeAppear(String elementName, >> --- old/test/javax/sound/midi/MidiDeviceConnectors/TestAllDevices.java 2014-01-13 16:54:20.000000000 -0800 >> +++ new/test/javax/sound/midi/MidiDeviceConnectors/TestAllDevices.java 2014-01-13 16:54:20.000000000 -0800 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2010, 2014, 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 >> @@ -25,7 +25,7 @@ >> * @test >> * @bug 4933700 >> * @summary Tests that default devices return MidiDeviceTransmitter/Receiver and returned objects return correct MidiDevice >> - * @compile -source 1.7 TestAllDevices.java >> + * @compile TestAllDevices.java >> * @run main TestAllDevices >> * @author Alex Menkov >> */ >> --- old/test/javax/sound/sampled/AudioFormat/PCM_FLOAT_support.java 2014-01-13 16:54:20.000000000 -0800 >> +++ new/test/javax/sound/sampled/AudioFormat/PCM_FLOAT_support.java 2014-01-13 16:54:20.000000000 -0800 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2010, 2014, 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 >> @@ -25,7 +25,7 @@ >> * @test >> * @bug 6944033 >> * @summary Tests that PCM_FLOAT encoding is supported >> - * @compile -source 1.7 PCM_FLOAT_support.java >> + * @compile PCM_FLOAT_support.java >> * @run main PCM_FLOAT_support >> * @author Alex Menkov >> * >> --- old/test/sun/management/jmxremote/LocalRMIServerSocketFactoryTest.java 2014-01-13 16:54:21.000000000 -0800 >> +++ new/test/sun/management/jmxremote/LocalRMIServerSocketFactoryTest.java 2014-01-13 16:54:21.000000000 -0800 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2008, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2008, 2014, 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 >> @@ -28,7 +28,7 @@ >> * >> * @author Daniel Fuchs >> * >> - * @run compile -XDignore.symbol.file=true -source 1.6 -g LocalRMIServerSocketFactoryTest.java >> + * @run compile -XDignore.symbol.file=true -g LocalRMIServerSocketFactoryTest.java >> * @run main LocalRMIServerSocketFactoryTest >> */ >> >> >> From chris.hegarty at oracle.com Tue Jan 14 16:46:39 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 14 Jan 2014 16:46:39 +0000 Subject: JDK 9 RFR of JDK-8031651: Remove unneeded -source and -target flags in jdk repo regression tests In-Reply-To: <52D5698C.4090300@oracle.com> References: <52D48EB8.70009@oracle.com> <781B81A3-A854-4346-AF9D-DB372AC02B59@oracle.com> <52D5698C.4090300@oracle.com> Message-ID: On 14 Jan 2014, at 16:45, Joe Darcy wrote: > Hi Chris, > > I think it is easier to use the exact version of the change in the 166 CVS. I've reverted the java/util/concurrent parts of my patch so a separate bug can be used for the next sync with 166. No problem. I?ll file a bug and bring in these changes. -Chris. > > Thanks, > > -Joe > > On 01/14/2014 03:27 AM, Chris Hegarty wrote: >> Since Martin has removed completely the '@compile -source 1.5 XXX? lines from the 166 CVS, you can amend your patch to do the same, or we can file a separate bug to bring in these change. Whatever suits you, just let me know. >> >> -Chris. >> >> On 14 Jan 2014, at 02:30, Martin Buchholz wrote: >> >>> All occurrences of >>> @compile -source 1.5 >>> have been removed from jsr166 CVS. >>> >>> >>> On Mon, Jan 13, 2014 at 5:11 PM, Joe Darcy wrote: >>> Hello, >>> >>> Per the policy set forth in >>> >>> JEP 182: Policy for Retiring javac -source and -target Options >>> http://openjdk.java.net/jeps/182 >>> >>> in JDK 9, javac will only recognize javac source and target value of 6/1.6 and higher. Therefore, uses of earlier options in the JDK regression tests need to be modified. >>> >>> Please review the first pass at fixing this before support for the old source and target values is removed: >>> >>> JDK-8031651 : Remove unneeded -source and -target flags in jdk repo regression tests >>> http://cr.openjdk.java.net/~darcy/8031651.2/ >>> >>> Patch also below. >>> >>> A few comments on the changes. In java/security/cert/* the tests were intentionally creating a corrupted set to make sure it was rejected properly. >>> >>> Chris, do the changes in java/util/concurrent need to go into Doug's repo first? >>> >>> I had to wrestle a bit for the code in javax/imageio/metadata/GetObjectMinValue to make the generics work out. >>> >>> For test/java/util/Locale/Bug4175998Test.java, as of source 6, an encoding error, even in a comment is a javac error. Therefore, a non-ASCKII character is replaced by a Unicode escape. >>> >>> Kumar, the pack200 tests uses "-target 5"; can you look into updating this to target 6 or later? >>> >>> Thanks, >>> >>> -Joe >>> >>> --- old/test/demo/jvmti/hprof/StackMapTableTest.java 2014-01-13 16:54:09.000000000 -0800 >>> +++ new/test/demo/jvmti/hprof/StackMapTableTest.java 2014-01-13 16:54:09.000000000 -0800 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2005, 2009, Oracle and/or its affiliates. All rights reserved. >>> + * Copyright (c) 2005, 2014, 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 >>> @@ -27,7 +27,7 @@ >>> * @summary Test jvmti hprof and java_crw_demo with StackMapTable attributes >>> * >>> * @compile ../DemoRun.java >>> - * @compile -source 7 -g:lines HelloWorld.java >>> + * @compile -g:lines HelloWorld.java >>> * @build StackMapTableTest >>> * @run main StackMapTableTest HelloWorld >>> */ >>> --- old/test/java/lang/reflect/OldenCompilingWithDefaults.java 2014-01-13 16:54:10.000000000 -0800 >>> +++ new/test/java/lang/reflect/OldenCompilingWithDefaults.java 2014-01-13 16:54:10.000000000 -0800 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2013, Oracle and/or its affiliates. All rights reserved. >>> + * Copyright (c) 2013, 2014, 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 >>> @@ -25,7 +25,6 @@ >>> * @test >>> * @bug 8009267 >>> * @summary Verify uses of isAnnotationPresent compile under older source versions >>> - * @compile -source 1.5 -target 1.5 OldenCompilingWithDefaults.java >>> * @compile -source 1.6 -target 1.6 OldenCompilingWithDefaults.java >>> * @compile -source 1.7 -target 1.7 OldenCompilingWithDefaults.java >>> * @compile OldenCompilingWithDefaults.java >>> --- old/test/java/security/cert/PKIXBuilderParameters/InvalidParameters.java 2014-01-13 16:54:10.000000000 -0800 >>> +++ new/test/java/security/cert/PKIXBuilderParameters/InvalidParameters.java 2014-01-13 16:54:10.000000000 -0800 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2001, 2004, Oracle and/or its affiliates. All rights reserved. >>> + * Copyright (c) 2001, 2014, 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 >>> @@ -21,16 +21,17 @@ >>> * questions. >>> */ >>> >>> -/** >>> +/* >>> * @test >>> * @test 4422738 >>> - * @compile -source 1.4 InvalidParameters.java >>> + * @compile InvalidParameters.java >>> * @run main InvalidParameters >>> * @summary Make sure PKIXBuilderParameters(Set) detects invalid >>> * parameters and throws correct exceptions >>> */ >>> import java.security.InvalidAlgorithmParameterException; >>> import java.security.cert.PKIXBuilderParameters; >>> +import java.security.cert.TrustAnchor; >>> import java.util.Collections; >>> import java.util.Set; >>> >>> @@ -53,8 +54,10 @@ >>> >>> // make sure Set of invalid objects throws ClassCastException >>> try { >>> + @SuppressWarnings("unchecked") // Knowingly do something bad >>> + Set badSet = (Set) (Set) Collections.singleton(new String()); >>> PKIXBuilderParameters p = >>> - new PKIXBuilderParameters(Collections.singleton(new String()), null); >>> + new PKIXBuilderParameters(badSet, null); >>> throw new Exception("should have thrown ClassCastException"); >>> } catch (ClassCastException cce) { } >>> } >>> --- old/test/java/security/cert/PKIXParameters/InvalidParameters.java 2014-01-13 16:54:11.000000000 -0800 >>> +++ new/test/java/security/cert/PKIXParameters/InvalidParameters.java 2014-01-13 16:54:10.000000000 -0800 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2001, 2004, Oracle and/or its affiliates. All rights reserved. >>> + * Copyright (c) 2001, 2014, 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 >>> @@ -24,7 +24,7 @@ >>> /** >>> * @test >>> * @test 4422738 >>> - * @compile -source 1.4 InvalidParameters.java >>> + * @compile InvalidParameters.java >>> * @run main InvalidParameters >>> * @summary Make sure PKIXParameters(Set) and setTrustAnchors() detects invalid >>> * parameters and throws correct exceptions >>> @@ -64,12 +64,14 @@ >>> } catch (NullPointerException npe) { } >>> >>> // make sure Set of invalid objects throws ClassCastException >>> + @SuppressWarnings("unchecked") // Knowingly do something bad >>> + Set badSet = (Set) (Set) Collections.singleton(new String()); >>> try { >>> - PKIXParameters p = new PKIXParameters(Collections.singleton(new String())); >>> + PKIXParameters p = new PKIXParameters(badSet); >>> throw new Exception("should have thrown ClassCastException"); >>> } catch (ClassCastException cce) { } >>> try { >>> - params.setTrustAnchors(Collections.singleton(new String())); >>> + params.setTrustAnchors(badSet); >>> throw new Exception("should have thrown ClassCastException"); >>> } catch (ClassCastException cce) { } >>> } >>> --- old/test/java/util/Locale/Bug4175998Test.java 2014-01-13 16:54:11.000000000 -0800 >>> +++ new/test/java/util/Locale/Bug4175998Test.java 2014-01-13 16:54:11.000000000 -0800 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2007, Oracle and/or its affiliates. All rights reserved. >>> + * Copyright (c) 2007, 2014, 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 >>> @@ -20,13 +20,15 @@ >>> * or visit www.oracle.com if you need additional information or have any >>> * questions. >>> */ >>> + >>> /* >>> - @test >>> - @summary test ISO639-2 language codes >>> - @compile -encoding ascii -source 5 Bug4175998Test.java >>> - @run main Bug4175998Test >>> - @bug 4175998 >>> -*/ >>> + * @test >>> + * @summary test ISO639-2 language codes >>> + * @compile -encoding ascii Bug4175998Test.java >>> + * @run main Bug4175998Test >>> + * @bug 4175998 >>> + */ >>> + >>> /* >>> * >>> * >>> @@ -731,7 +733,7 @@ >>> pon pon Pohnpeian >>> por por Portuguese >>> pra pra Prakrit languages >>> -pro pro Proven?al, Old (to 1500) >>> +pro pro Proven\u00E7al, Old (to 1500) >>> pus pus Pushto >>> qaa-qtz qaa-qtz Reserved for local use >>> que que Quechua >>> --- old/test/java/util/concurrent/BlockingQueue/CancelledProducerConsumerLoops.java 2014-01-13 16:54:12.000000000 -0800 >>> +++ new/test/java/util/concurrent/BlockingQueue/CancelledProducerConsumerLoops.java 2014-01-13 16:54:11.000000000 -0800 >>> @@ -34,7 +34,7 @@ >>> /* >>> * @test >>> * @bug 4486658 >>> - * @compile -source 1.5 CancelledProducerConsumerLoops.java >>> + * @compile CancelledProducerConsumerLoops.java >>> * @run main/timeout=7000 CancelledProducerConsumerLoops >>> * @summary Checks for responsiveness of blocking queues to cancellation. >>> * Runs under the assumption that ITERS computations require more than >>> --- old/test/java/util/concurrent/BlockingQueue/MultipleProducersSingleConsumerLoops.java 2014-01-13 16:54:12.000000000 -0800 >>> +++ new/test/java/util/concurrent/BlockingQueue/MultipleProducersSingleConsumerLoops.java 2014-01-13 16:54:12.000000000 -0800 >>> @@ -34,7 +34,7 @@ >>> /* >>> * @test >>> * @bug 4486658 >>> - * @compile -source 1.5 MultipleProducersSingleConsumerLoops.java >>> + * @compile MultipleProducersSingleConsumerLoops.java >>> * @run main/timeout=3600 MultipleProducersSingleConsumerLoops >>> * @summary multiple producers and single consumer using blocking queues >>> */ >>> --- old/test/java/util/concurrent/BlockingQueue/ProducerConsumerLoops.java 2014-01-13 16:54:12.000000000 -0800 >>> +++ new/test/java/util/concurrent/BlockingQueue/ProducerConsumerLoops.java 2014-01-13 16:54:12.000000000 -0800 >>> @@ -34,7 +34,7 @@ >>> /* >>> * @test >>> * @bug 4486658 >>> - * @compile -source 1.5 ProducerConsumerLoops.java >>> + * @compile ProducerConsumerLoops.java >>> * @run main/timeout=3600 ProducerConsumerLoops >>> * @summary multiple producers and consumers using blocking queues >>> */ >>> --- old/test/java/util/concurrent/BlockingQueue/SingleProducerMultipleConsumerLoops.java 2014-01-13 16:54:13.000000000 -0800 >>> +++ new/test/java/util/concurrent/BlockingQueue/SingleProducerMultipleConsumerLoops.java 2014-01-13 16:54:13.000000000 -0800 >>> @@ -34,7 +34,7 @@ >>> /* >>> * @test >>> * @bug 4486658 >>> - * @compile -source 1.5 SingleProducerMultipleConsumerLoops.java >>> + * @compile SingleProducerMultipleConsumerLoops.java >>> * @run main/timeout=600 SingleProducerMultipleConsumerLoops >>> * @summary check ordering for blocking queues with 1 producer and multiple consumers >>> */ >>> --- old/test/java/util/concurrent/ConcurrentHashMap/MapCheck.java 2014-01-13 16:54:14.000000000 -0800 >>> +++ new/test/java/util/concurrent/ConcurrentHashMap/MapCheck.java 2014-01-13 16:54:13.000000000 -0800 >>> @@ -34,7 +34,7 @@ >>> /* >>> * @test >>> * @bug 4486658 >>> - * @compile -source 1.5 MapCheck.java >>> + * @compile MapCheck.java >>> * @run main/timeout=240 MapCheck >>> * @summary Times and checks basic map operations >>> */ >>> --- old/test/java/util/concurrent/ConcurrentHashMap/MapLoops.java 2014-01-13 16:54:14.000000000 -0800 >>> +++ new/test/java/util/concurrent/ConcurrentHashMap/MapLoops.java 2014-01-13 16:54:14.000000000 -0800 >>> @@ -34,7 +34,7 @@ >>> /* >>> * @test >>> * @bug 4486658 >>> - * @compile -source 1.5 MapLoops.java >>> + * @compile MapLoops.java >>> * @run main/timeout=1600 MapLoops >>> * @summary Exercise multithreaded maps, by default ConcurrentHashMap. >>> * Multithreaded hash table test. Each thread does a random walk >>> --- old/test/java/util/concurrent/Exchanger/ExchangeLoops.java 2014-01-13 16:54:15.000000000 -0800 >>> +++ new/test/java/util/concurrent/Exchanger/ExchangeLoops.java 2014-01-13 16:54:14.000000000 -0800 >>> @@ -34,7 +34,7 @@ >>> /* >>> * @test >>> * @bug 4486658 >>> - * @compile -source 1.5 ExchangeLoops.java >>> + * @compile ExchangeLoops.java >>> * @run main/timeout=720 ExchangeLoops >>> * @summary checks to make sure a pipeline of exchangers passes data. >>> */ >>> --- old/test/java/util/concurrent/ExecutorCompletionService/ExecutorCompletionServiceLoops.java 2014-01-13 16:54:15.000000000 -0800 >>> +++ new/test/java/util/concurrent/ExecutorCompletionService/ExecutorCompletionServiceLoops.java 2014-01-13 16:54:15.000000000 -0800 >>> @@ -34,7 +34,7 @@ >>> /* >>> * @test >>> * @bug 4965960 >>> - * @compile -source 1.5 ExecutorCompletionServiceLoops.java >>> + * @compile ExecutorCompletionServiceLoops.java >>> * @run main/timeout=3600 ExecutorCompletionServiceLoops >>> * @summary Exercise ExecutorCompletionServiceLoops >>> */ >>> --- old/test/java/util/concurrent/FutureTask/CancelledFutureLoops.java 2014-01-13 16:54:16.000000000 -0800 >>> +++ new/test/java/util/concurrent/FutureTask/CancelledFutureLoops.java 2014-01-13 16:54:15.000000000 -0800 >>> @@ -34,7 +34,7 @@ >>> /* >>> * @test >>> * @bug 4486658 >>> - * @compile -source 1.5 CancelledFutureLoops.java >>> + * @compile CancelledFutureLoops.java >>> * @run main/timeout=2000 CancelledFutureLoops >>> * @summary Checks for responsiveness of futures to cancellation. >>> * Runs under the assumption that ITERS computations require more than >>> --- old/test/java/util/concurrent/atomic/VMSupportsCS8.java 2014-01-13 16:54:16.000000000 -0800 >>> +++ new/test/java/util/concurrent/atomic/VMSupportsCS8.java 2014-01-13 16:54:16.000000000 -0800 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2004, 2010, Oracle and/or its affiliates. All rights reserved. >>> + * Copyright (c) 2004, 2014, 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 >>> @@ -24,7 +24,7 @@ >>> /* >>> * @test >>> * @bug 4992443 4994819 >>> - * @compile -source 1.5 VMSupportsCS8.java >>> + * @compile VMSupportsCS8.java >>> * @run main VMSupportsCS8 >>> * @summary Checks that the value of VMSupportsCS8 matches system properties. >>> */ >>> --- old/test/java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java 2014-01-13 16:54:16.000000000 -0800 >>> +++ new/test/java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java 2014-01-13 16:54:16.000000000 -0800 >>> @@ -34,7 +34,7 @@ >>> /* >>> * @test >>> * @bug 4486658 >>> - * @compile -source 1.5 CancelledLockLoops.java >>> + * @compile CancelledLockLoops.java >>> * @run main/timeout=2800 CancelledLockLoops >>> * @summary tests lockInterruptibly. >>> * Checks for responsiveness of locks to interrupts. Runs under that >>> --- old/test/java/util/concurrent/locks/ReentrantLock/LockOncePerThreadLoops.java 2014-01-13 16:54:17.000000000 -0800 >>> +++ new/test/java/util/concurrent/locks/ReentrantLock/LockOncePerThreadLoops.java 2014-01-13 16:54:17.000000000 -0800 >>> @@ -34,7 +34,7 @@ >>> /* >>> * @test >>> * @bug 4486658 >>> - * @compile -source 1.5 LockOncePerThreadLoops.java >>> + * @compile LockOncePerThreadLoops.java >>> * @run main/timeout=15000 LockOncePerThreadLoops >>> * @summary Checks for missed signals by locking and unlocking each of an array of locks once per thread >>> */ >>> --- old/test/java/util/concurrent/locks/ReentrantLock/SimpleReentrantLockLoops.java 2014-01-13 16:54:17.000000000 -0800 >>> +++ new/test/java/util/concurrent/locks/ReentrantLock/SimpleReentrantLockLoops.java 2014-01-13 16:54:17.000000000 -0800 >>> @@ -34,7 +34,7 @@ >>> /* >>> * @test >>> * @bug 4486658 >>> - * @compile -source 1.5 SimpleReentrantLockLoops.java >>> + * @compile SimpleReentrantLockLoops.java >>> * @run main/timeout=4500 SimpleReentrantLockLoops >>> * @summary multiple threads using a single lock >>> */ >>> --- old/test/java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java 2014-01-13 16:54:18.000000000 -0800 >>> +++ new/test/java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java 2014-01-13 16:54:17.000000000 -0800 >>> @@ -34,7 +34,7 @@ >>> /* >>> * @test >>> * @bug 4486658 5031862 >>> - * @compile -source 1.5 TimeoutLockLoops.java >>> + * @compile TimeoutLockLoops.java >>> * @run main TimeoutLockLoops >>> * @summary Checks for responsiveness of locks to timeouts. >>> * Runs under the assumption that ITERS computations require more than >>> --- old/test/java/util/concurrent/locks/ReentrantReadWriteLock/MapLoops.java 2014-01-13 16:54:18.000000000 -0800 >>> +++ new/test/java/util/concurrent/locks/ReentrantReadWriteLock/MapLoops.java 2014-01-13 16:54:18.000000000 -0800 >>> @@ -34,7 +34,7 @@ >>> /* >>> * @test >>> * @bug 4486658 >>> - * @compile -source 1.5 MapLoops.java >>> + * @compile MapLoops.java >>> * @run main/timeout=4700 MapLoops >>> * @summary Exercise multithreaded maps, by default ConcurrentHashMap. >>> * Multithreaded hash table test. Each thread does a random walk >>> --- old/test/javax/imageio/metadata/GetObjectMinValue.java 2014-01-13 16:54:20.000000000 -0800 >>> +++ new/test/javax/imageio/metadata/GetObjectMinValue.java 2014-01-13 16:54:19.000000000 -0800 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2012, Oracle and/or its affiliates. All rights reserved. >>> + * Copyright (c) 2012, 2014, 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 >>> @@ -24,14 +24,12 @@ >>> /* >>> * @test >>> * @bug 4429875 7186799 >>> - * @compile -source 1.4 GetObjectMinValue.java >>> + * @compile GetObjectMinValue.java >>> * @run main GetObjectMinValue >>> * @summary Tests the getObject{Min,Max}Value method of >>> * IIOMetadataFormatImpl for an inclusive range >>> */ >>> >>> -// Compiled with -source 1.4 to work around javac bug 5041233 >>> - >>> import javax.imageio.metadata.IIOMetadataFormatImpl; >>> import javax.imageio.ImageTypeSpecifier; >>> >>> @@ -79,13 +77,13 @@ >>> } >>> >>> public void addObjectValue(String elementName, >>> - Class classType, Object defaultValue, >>> + Class classType, Integer defaultValue, >>> Comparable minValue, Comparable maxValue, >>> boolean minInclusive, boolean maxInclusive) { >>> - super.addObjectValue(elementName, >>> - classType, defaultValue, >>> - minValue, maxValue, >>> - minInclusive, maxInclusive); >>> + super.addObjectValue(elementName, >>> + (Class)classType, defaultValue, >>> + (Comparable) minValue, (Comparable) maxValue, >>> + minInclusive, maxInclusive); >>> } >>> >>> public boolean canNodeAppear(String elementName, >>> --- old/test/javax/sound/midi/MidiDeviceConnectors/TestAllDevices.java 2014-01-13 16:54:20.000000000 -0800 >>> +++ new/test/javax/sound/midi/MidiDeviceConnectors/TestAllDevices.java 2014-01-13 16:54:20.000000000 -0800 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. >>> + * Copyright (c) 2010, 2014, 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 >>> @@ -25,7 +25,7 @@ >>> * @test >>> * @bug 4933700 >>> * @summary Tests that default devices return MidiDeviceTransmitter/Receiver and returned objects return correct MidiDevice >>> - * @compile -source 1.7 TestAllDevices.java >>> + * @compile TestAllDevices.java >>> * @run main TestAllDevices >>> * @author Alex Menkov >>> */ >>> --- old/test/javax/sound/sampled/AudioFormat/PCM_FLOAT_support.java 2014-01-13 16:54:20.000000000 -0800 >>> +++ new/test/javax/sound/sampled/AudioFormat/PCM_FLOAT_support.java 2014-01-13 16:54:20.000000000 -0800 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. >>> + * Copyright (c) 2010, 2014, 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 >>> @@ -25,7 +25,7 @@ >>> * @test >>> * @bug 6944033 >>> * @summary Tests that PCM_FLOAT encoding is supported >>> - * @compile -source 1.7 PCM_FLOAT_support.java >>> + * @compile PCM_FLOAT_support.java >>> * @run main PCM_FLOAT_support >>> * @author Alex Menkov >>> * >>> --- old/test/sun/management/jmxremote/LocalRMIServerSocketFactoryTest.java 2014-01-13 16:54:21.000000000 -0800 >>> +++ new/test/sun/management/jmxremote/LocalRMIServerSocketFactoryTest.java 2014-01-13 16:54:21.000000000 -0800 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2008, Oracle and/or its affiliates. All rights reserved. >>> + * Copyright (c) 2008, 2014, 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 >>> @@ -28,7 +28,7 @@ >>> * >>> * @author Daniel Fuchs >>> * >>> - * @run compile -XDignore.symbol.file=true -source 1.6 -g LocalRMIServerSocketFactoryTest.java >>> + * @run compile -XDignore.symbol.file=true -g LocalRMIServerSocketFactoryTest.java >>> * @run main LocalRMIServerSocketFactoryTest >>> */ >>> >>> >>> > From volker.simonis at gmail.com Tue Jan 14 16:57:48 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 14 Jan 2014 17:57:48 +0100 Subject: RFR(S/L): 8028537: PPC64: Updated the JDK regression tests to run on AIX Message-ID: Hi, could you please review the following change: http://cr.openjdk.java.net/~simonis/webrevs/8028537/ which, together with the changes from "8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests" and "8031134 : PPC64: implement printing on AIX" enables our our port to pass all but the following 7 jtreg regression tests on AIX (compared to the Linux/x86_64 baseline from www.java.net/download/jdk8/testresults/testresults.html?): java/net/Inet6Address/B6558853.java java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically) java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically) java/nio/channels/Selector/RacyDeregister.java sun/security/krb5/auto/Unreachable.java (only on IPv6) The change is only big in the amount of files it touches but rather small in the amount of actual code changes so I flagged it with S/L. Most changes simply add AIX as a known platform to the OS detection sections of the various tests. The are either of the form: case "$OS" in - SunOS | Linux | Darwin ) + SunOS | Linux | Darwin | AIX ) PATHSEP=":" or: isSolaris=true ;; + AIX ) + OS="AIX" + isAIX=true + ;; Windows* ) OS="Windows" The following explanations only mention test with changes different to the ones above: test/ProblemList.txt - Added three tests which currently don't work on AIX. test/com/sun/java/swing/plaf/windows/8016551/bug8016551.java - This test calls JFrame.setDefaultCloseOperation() which is not allowed under the security manager which is active if the test are running in agentvm mode. So better always run this test in othervm mode. test/com/sun/jdi/PrivateTransportTest.sh - On AIX, we have to use LIBPATH instead of LD_LIBRARY_PATH. test/com/sun/nio/sctp/SctpChannel/Util.java test/com/sun/nio/sctp/SctpMultiChannel/Util.java test/com/sun/nio/sctp/SctpServerChannel/Util.java - On AIX, we currently haven't implemented SCTP but we nevertheless compile the shared SCTP classes into the runtime class library. This way the AIX JDK can at least compile SCTP applications altough it can not run them. To support this scenario, the runtime check for the availability of SCTP has to be extended to catch UnsatisfiedLinkError and NoClassDefFoundError. UnsatisfiedLinkError will be thrown the first time when the class SctpChannelImpl will be loaded because it cannot load the its native support library in the static initialisation section. On the next load attempt of the class, a NoClassDefFoundError will be thrown because of the previously failed initialisation. test/java/net/DatagramSocket/Send12k.java - AIX throws an IOException: Message too long if the message is too long. DatagramSocket.send() is specified to throw an IOException so better don't be too specific in the catch clause. test/java/nio/file/Files/SBC.java - AIX actually supports symbolic links, but it does not support NOFOLLOW_LINKS, or more exactly the O_NOFOLLOW flag to the open() system call which is tested here. test/java/nio/file/Files/walkFileTree/find.sh - On AIX find -follow may core dump on recursive links without '-L' (see http://www-01.ibm.com/support/docview.wss?uid=isg1IV28143). test/java/util/logging/AnonLoggerWeakRefLeak.sh test/java/util/logging/LoggerWeakRefLeak.sh - Only treat missing jmap options as warnings and not as errors. test/sun/rmi/rmic/newrmic/equivalence/batch.sh - On AIX the diff utility doesn't detect binary files and thus outputs the full diff of different class files which makes the test fail. Because the generated class files aren?t used or checked anyway we can completely omit the generation of class files by always using the -nowrite option. - Also reformatted the command lines to make the differences more apparent. test/tools/launcher/ExecutionEnvironment.java - On AIX, we have to use LIBPATH instead of LD_LIBRARY_PATH. - AIX does not support the -rpath linker options so the launchers have to prepend the jdk library path to LIBPATH. test/tools/launcher/Settings.java - On PPC64 we need a bigger stack size. Thank you and best regards, Volker From mandy.chung at oracle.com Tue Jan 14 17:32:35 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 14 Jan 2014 09:32:35 -0800 Subject: Review request for 6516909: (cl spec) ClassLoader.loadClass() clarification to indicate it shouldn't be used for array classes In-Reply-To: <52D50DE7.6090404@oracle.com> References: <52D4708F.8030703@oracle.com> <52D50DE7.6090404@oracle.com> Message-ID: <52D574B3.4060602@oracle.com> On 1/14/2014 2:13 AM, Alan Bateman wrote: > This looks good to me, I assume JDK-6434149 can finally be closed too. > Thanks for the review. Yes JDK-6434149 will be closed. Mandy From mike.duigou at oracle.com Tue Jan 14 17:39:53 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 14 Jan 2014 09:39:53 -0800 Subject: Doc updates Re: RFR 8030848: Collections.sort(List l, Comparator) should defer to List.sort(Comparator ) In-Reply-To: <958A34DB-EA57-4A1D-8744-4C7DBADD7F5D@oracle.com> References: <52CFFD37.7050603@oracle.com> <958A34DB-EA57-4A1D-8744-4C7DBADD7F5D@oracle.com> Message-ID: The docs changes look good to me. Mike On Jan 13 2014, at 05:39 , Paul Sandoz wrote: > On Jan 10, 2014, at 3:01 PM, Alan Bateman wrote: >> The implementation changes look good. I agree that the javadoc needs changing as it's otherwise misleading as to what the implementation actually does. I would think that this should go with the implementation change rather than as a separate change. >> > > See here for patch layered on top of code changes (to be folded after review into one patch): > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8030848-Collections-sort-docs/webrev/ > > Paul. > From alexander.zuev at oracle.com Tue Jan 14 18:04:26 2014 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Tue, 14 Jan 2014 22:04:26 +0400 Subject: JDK9 RFR of JDK-8029646: [pack200] should support the new zip64 format. Message-ID: <52D57C2A.4010906@oracle.com> Please review my fix for JDK-8029646: [pack200] should support the new zip64 format. The fix can be found at http://cr.openjdk.java.net/~kizune/8029646/webrev.00/ Bug description is: https://bugs.openjdk.java.net/browse/JDK-8029646 /Alex From kumar.x.srinivasan at oracle.com Tue Jan 14 18:17:35 2014 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 14 Jan 2014 10:17:35 -0800 Subject: 8031494: [launcher] java launcher should check for JNI Pending exceptions. In-Reply-To: <52D4B068.6050509@oracle.com> References: <52D0968F.6090702@oracle.com> <52D17072.3020602@oracle.com> <52D411C0.206@oracle.com> <52D46C5E.1030800@oracle.com> <52D477F8.60505@oracle.com> <52D4A27C.2020709@oracle.com> <52D4B068.6050509@oracle.com> Message-ID: <52D57F3F.6000809@oracle.com> Good catch on the CallStaticVoidMethod, fixed these as well, here is the updated webrev: http://cr.openjdk.java.net/~ksrini/8031494/webrev.2/ delta webrev to the last: http://cr.openjdk.java.net/~ksrini/8031494/webrev.2/webrev.delta/index.html Thanks Kumar > > On 1/13/2014 6:35 PM, Kumar Srinivasan wrote: >> Mandy, >> >> >>> On 1/13/2014 2:44 PM, Kumar Srinivasan wrote: >>>> The full webrev: >>>> http://cr.openjdk.java.net/~ksrini/8031494/webrev.1/ >>> >>> This looks good. Should it also check if there is any pending >>> exception after the call to CallStaticVoidMethod that has no return >>> value? It's fine with me if you want to follow up the calls to >>> CallStaticVoidMethod in a separate bug. >> >> No not necessary, there are already guards for pending exceptions >> from CallStaticVoidMethod, >> all of them are in JavaMain, and these macros end with "LEAVE". > > I'm referring to multiple calls to CallStaticVoidMethod within the > same function e.g. PrintUsage (maybe that's the only one) where I > believe no LEAVE macro call in between. > > Mandy From Lance.Andersen at oracle.com Tue Jan 14 18:39:56 2014 From: Lance.Andersen at oracle.com (Lance Andersen) Date: Tue, 14 Jan 2014 13:39:56 -0500 Subject: Review request: 8031721: Remove non-existent test from TEST.groups Message-ID: <749F0C24-277A-4F59-ADB0-400A74836BF9@oracle.com> Hi, Need a reviewer for this simple change to remove an entry for a test that does not exist from TEST.groups: hg diff diff -r 6744e0c2459f test/TEST.groups --- a/test/TEST.groups Tue Jan 14 10:08:24 2014 -0800 +++ b/test/TEST.groups Tue Jan 14 13:35:22 2014 -0500 @@ -379,7 +379,6 @@ java/util/ResourceBundle/Control/Bug6530694.java \ java/text/Bidi/BidiConformance.java \ java/text/Bidi/BidiEmbeddingTest.java \ - java/text/Bidi/Bug6665028.java \ java/text/Bidi/Bug7042148.java \ java/text/Bidi/Bug7051769.java \ javax/crypto/Cipher/CipherStreamClose.java \ Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From mandy.chung at oracle.com Tue Jan 14 19:04:25 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 14 Jan 2014 11:04:25 -0800 Subject: 8031494: [launcher] java launcher should check for JNI Pending exceptions. In-Reply-To: <52D57F3F.6000809@oracle.com> References: <52D0968F.6090702@oracle.com> <52D17072.3020602@oracle.com> <52D411C0.206@oracle.com> <52D46C5E.1030800@oracle.com> <52D477F8.60505@oracle.com> <52D4A27C.2020709@oracle.com> <52D4B068.6050509@oracle.com> <52D57F3F.6000809@oracle.com> Message-ID: <52D58A39.8080904@oracle.com> On 1/14/2014 10:17 AM, Kumar Srinivasan wrote: > > Good catch on the CallStaticVoidMethod, fixed these as well, here is the > updated webrev: > http://cr.openjdk.java.net/~ksrini/8031494/webrev.2/ > > delta webrev to the last: > http://cr.openjdk.java.net/~ksrini/8031494/webrev.2/webrev.delta/index.html > > Looks good. Mandy > Thanks > Kumar > >> >> On 1/13/2014 6:35 PM, Kumar Srinivasan wrote: >>> Mandy, >>> >>> >>>> On 1/13/2014 2:44 PM, Kumar Srinivasan wrote: >>>>> The full webrev: >>>>> http://cr.openjdk.java.net/~ksrini/8031494/webrev.1/ >>>> >>>> This looks good. Should it also check if there is any pending >>>> exception after the call to CallStaticVoidMethod that has no return >>>> value? It's fine with me if you want to follow up the calls to >>>> CallStaticVoidMethod in a separate bug. >>> >>> No not necessary, there are already guards for pending exceptions >>> from CallStaticVoidMethod, >>> all of them are in JavaMain, and these macros end with "LEAVE". >> >> I'm referring to multiple calls to CallStaticVoidMethod within the >> same function e.g. PrintUsage (maybe that's the only one) where I >> believe no LEAVE macro call in between. >> >> Mandy > From Alan.Bateman at oracle.com Tue Jan 14 19:13:25 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 Jan 2014 19:13:25 +0000 Subject: RFR(S/L): 8028537: PPC64: Updated the JDK regression tests to run on AIX In-Reply-To: References: Message-ID: <52D58C55.6070004@oracle.com> On 14/01/2014 16:57, Volker Simonis wrote: > : > > test/com/sun/nio/sctp/SctpChannel/Util.java > test/com/sun/nio/sctp/SctpMultiChannel/Util.java > test/com/sun/nio/sctp/SctpServerChannel/Util.java > > - On AIX, we currently haven't implemented SCTP but we nevertheless > compile the shared SCTP classes into the runtime class library. This way > the AIX JDK can at least compile SCTP applications altough it can not run > them. To support this scenario, the runtime check for the availability of > SCTP has to be extended to catch UnsatisfiedLinkError and > NoClassDefFoundError. UnsatisfiedLinkError will be thrown the first time > when the class SctpChannelImpl will be loaded because it cannot load the > its native support library in the static initialisation section. On the > next load attempt of the class, a NoClassDefFoundError will be thrown > because of the previously failed initialisation. > OS X has the same issue and the solution used there are stub implementations that just throw UOE. Details in jdk/src/macosx/classes/sun/nio/ch/sctp and that maybe that would work for AIX too. -Alan. From mandy.chung at oracle.com Tue Jan 14 19:14:08 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 14 Jan 2014 11:14:08 -0800 Subject: Review request: 8031721: Remove non-existent test from TEST.groups In-Reply-To: <749F0C24-277A-4F59-ADB0-400A74836BF9@oracle.com> References: <749F0C24-277A-4F59-ADB0-400A74836BF9@oracle.com> Message-ID: <52D58C80.6090901@oracle.com> Thumbs up. Mandy On 1/14/2014 10:39 AM, Lance Andersen wrote: > Hi, > > Need a reviewer for this simple change to remove an entry for a test that does not exist from TEST.groups: > > hg diff > diff -r 6744e0c2459f test/TEST.groups > --- a/test/TEST.groups Tue Jan 14 10:08:24 2014 -0800 > +++ b/test/TEST.groups Tue Jan 14 13:35:22 2014 -0500 > @@ -379,7 +379,6 @@ > java/util/ResourceBundle/Control/Bug6530694.java \ > java/text/Bidi/BidiConformance.java \ > java/text/Bidi/BidiEmbeddingTest.java \ > - java/text/Bidi/Bug6665028.java \ > java/text/Bidi/Bug7042148.java \ > java/text/Bidi/Bug7051769.java \ > javax/crypto/Cipher/CipherStreamClose.java \ > > > > 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 alexander.zuev at oracle.com Tue Jan 14 19:17:52 2014 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Tue, 14 Jan 2014 19:17:52 +0000 Subject: hg: jdk8/tl: 3 new changesets Message-ID: <20140114191752.B1DC66242B@hg.openjdk.java.net> Changeset: ff1478785e43 Author: katleman Date: 2014-01-03 11:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/ff1478785e43 Added tag jdk8-b122 for changeset 347009c58816 ! .hgtags Changeset: c330fa67c4da Author: katleman Date: 2014-01-10 08:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/c330fa67c4da Added tag jdk8-b123 for changeset ff1478785e43 ! .hgtags Changeset: fd869d9f3ca7 Author: kizune Date: 2014-01-14 23:10 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/fd869d9f3ca7 Merge From alexander.zuev at oracle.com Tue Jan 14 19:18:03 2014 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Tue, 14 Jan 2014 19:18:03 +0000 Subject: hg: jdk8/tl/corba: 10 new changesets Message-ID: <20140114191809.3B0F76242C@hg.openjdk.java.net> Changeset: 98a5caae1990 Author: chegar Date: 2013-11-03 07:32 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/98a5caae1990 Merge Changeset: 880514b576d5 Author: msheppar Date: 2013-11-12 17:56 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/880514b576d5 8026193: Enhance CORBA stub factories Summary: modify com.sun.corba.se.impl.presenetation.rmi.StubFactoryDynamicBase inheritance structure. Reviewed-by: alanb, coffeys, ahgross ! src/share/classes/com/sun/corba/se/impl/presentation/rmi/StubFactoryDynamicBase.java ! src/share/classes/com/sun/corba/se/impl/presentation/rmi/StubFactoryFactoryProxyImpl.java Changeset: b083590cb088 Author: msheppar Date: 2013-11-12 18:04 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/b083590cb088 8025767: Enhance IIOP Streams Summary: modify org.omg.CORBA_2_3.portable.InputStream inheritance structure. Reviewed-by: alanb, coffeys, skoivu ! src/share/classes/com/sun/corba/se/impl/corba/AnyImpl.java ! src/share/classes/com/sun/corba/se/impl/encoding/EncapsInputStream.java ! src/share/classes/com/sun/corba/se/impl/encoding/EncapsOutputStream.java ! src/share/classes/com/sun/corba/se/impl/encoding/TypeCodeInputStream.java ! src/share/classes/com/sun/corba/se/impl/encoding/TypeCodeOutputStream.java ! src/share/classes/com/sun/corba/se/impl/interceptors/CDREncapsCodec.java ! src/share/classes/com/sun/corba/se/impl/io/IIOPInputStream.java ! src/share/classes/com/sun/corba/se/impl/io/InputStreamHook.java ! src/share/classes/com/sun/corba/se/impl/ior/EncapsulationUtility.java ! src/share/classes/com/sun/corba/se/impl/ior/ObjectKeyFactoryImpl.java ! src/share/classes/com/sun/corba/se/impl/ior/iiop/IIOPProfileImpl.java ! src/share/classes/com/sun/corba/se/impl/protocol/CorbaClientRequestDispatcherImpl.java ! src/share/classes/com/sun/corba/se/impl/protocol/SharedCDRClientRequestDispatcherImpl.java ! src/share/classes/com/sun/corba/se/impl/resolver/INSURLOperationImpl.java ! src/share/classes/com/sun/corba/se/spi/servicecontext/ServiceContexts.java ! src/share/classes/org/omg/CORBA_2_3/portable/InputStream.java + src/share/classes/sun/corba/EncapsInputStreamFactory.java Changeset: 6b9b31f2298b Author: kizune Date: 2013-12-03 14:13 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/6b9b31f2298b Merge Changeset: d05c64360b6c Author: kizune Date: 2013-12-05 16:37 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/d05c64360b6c Merge - make/com/Makefile - make/com/sun/Makefile - make/com/sun/corba/Makefile - make/com/sun/corba/minclude/com_sun_corba_se_PortableActivationIDL.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_activation.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_corba.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_core.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_dynamicany.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_encoding.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_interceptors.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_io.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_ior.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_legacy.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_logging.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_monitoring.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_naming_cosnaming.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_naming_namingutil.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_naming_pcosnaming.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_oa_poa.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_oa_toa.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_orb.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_orbutil.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_presentation_rmi.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_protocol.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_resolver.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_transport.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_util.jmk - make/com/sun/corba/minclude/com_sun_corba_se_internal_LegacyFiles.jmk - make/com/sun/corba/minclude/com_sun_corba_se_pept.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_activation.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_copyobject.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_encoding.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_extension.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_ior.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_legacy_connection.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_legacy_interceptor.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_logging.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_monitoring.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_oa.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_orb.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_orbutil.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_presentation_rmi.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_protocol.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_resolver.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_servicecontext.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_transport.jmk - make/com/sun/corba/minclude/com_sun_tools_corba_se_idl_toJavaPortable.jmk - make/com/sun/corba/minclude/javax_activity.jmk - make/com/sun/corba/minclude/javax_rmi.jmk - make/com/sun/corba/minclude/javax_rmi_CORBA.jmk - make/com/sun/corba/minclude/javax_transaction.jmk - make/com/sun/corba/minclude/org_omg_CORBA.jmk - make/com/sun/corba/minclude/org_omg_CORBAX.jmk - make/com/sun/corba/minclude/org_omg_CORBA_2_3.jmk - make/com/sun/corba/minclude/org_omg_CosNaming.jmk - make/com/sun/corba/minclude/org_omg_DynamicAny.jmk - make/com/sun/corba/minclude/org_omg_IOP.jmk - make/com/sun/corba/minclude/org_omg_Messaging.jmk - make/com/sun/corba/minclude/org_omg_PortableInterceptor.jmk - make/com/sun/corba/minclude/org_omg_PortableServer.jmk - make/com/sun/corba/minclude/org_omg_SendingContext.jmk - make/com/sun/corba/minclude/sun_corba.jmk - make/com/sun/corba/se/Makefile - make/com/sun/corba/se/PortableActivationIDL/Makefile - make/com/sun/corba/se/connection/FILES_java.gmk - make/com/sun/corba/se/connection/Makefile - make/com/sun/corba/se/core/Makefile - make/com/sun/corba/se/corespi/Makefile - make/com/sun/corba/se/impl/Makefile - make/com/sun/corba/se/impl/activation/Makefile - make/com/sun/corba/se/impl/activation/orbd/Makefile - make/com/sun/corba/se/impl/activation/servertool/Makefile - make/com/sun/corba/se/impl/interceptors/Makefile - make/com/sun/corba/se/impl/logging/Makefile - make/com/sun/corba/se/impl/monitoring/Makefile - make/com/sun/corba/se/impl/naming/Makefile - make/com/sun/corba/se/impl/naming/cosnaming/Makefile - make/com/sun/corba/se/impl/naming/namingutil/Makefile - make/com/sun/corba/se/impl/naming/pcosnaming/Makefile - make/com/sun/corba/se/impl/oa/Makefile - make/com/sun/corba/se/impl/oa/poa/Makefile - make/com/sun/corba/se/impl/oa/toa/Makefile - make/com/sun/corba/se/interceptor/FILES_java.gmk - make/com/sun/corba/se/interceptor/Makefile - make/com/sun/corba/se/pept/Makefile - make/com/sun/corba/se/rmi/Makefile - make/com/sun/corba/se/rmi/rmic/Makefile - make/com/sun/corba/se/rmi/rmic/SUN_RMI_RMIC_IIOP_java.gmk - make/com/sun/corba/se/sources/Makefile - make/com/sun/corba/se/spi/Makefile - make/com/sun/corba/se/spi/activation/Makefile - make/com/sun/corba/se/spi/copyobject/Makefile - make/com/sun/corba/se/spi/encoding/Makefile - make/com/sun/corba/se/spi/extension/Makefile - make/com/sun/corba/se/spi/legacy/Makefile - make/com/sun/corba/se/spi/legacy/connection/Makefile - make/com/sun/corba/se/spi/legacy/interceptor/Makefile - make/com/sun/corba/se/spi/logging/Makefile - make/com/sun/corba/se/spi/monitoring/Makefile - make/common/BuildToolJar.gmk - make/common/CancelImplicits.gmk - make/common/Classes.gmk - make/common/Defs-bsd.gmk - make/common/Defs-linux.gmk - make/common/Defs-solaris.gmk - make/common/Defs-windows.gmk - make/common/Defs.gmk - make/common/Rules.gmk - make/common/internal/Resources.gmk - make/common/shared/Defs-bsd.gmk - make/common/shared/Defs-java.gmk - make/common/shared/Defs-linux.gmk - make/common/shared/Defs-solaris.gmk - make/common/shared/Defs-utils.gmk - make/common/shared/Defs-windows.gmk - make/common/shared/Defs.gmk - make/common/shared/Platform.gmk - make/javax/Makefile - make/javax/xa/Makefile - make/jprt.properties - make/org/Makefile - make/org/omg/CORBA/Makefile - make/org/omg/CORBAX_java.gmk - make/org/omg/CosNaming/Makefile - make/org/omg/DynamicAny/Makefile - make/org/omg/Makefile - make/org/omg/PortableInterceptor/Makefile - make/org/omg/PortableServer/Makefile - make/org/omg/idl/FILES_java.gmk - make/org/omg/idl/Makefile - make/org/omg/sources/Makefile - make/sun/Makefile - make/sun/corba/Makefile - make/sun/corba/core/Makefile - make/sun/corba/org/Makefile - make/sun/corba/org/omg/FILES_java.gmk - make/sun/corba/org/omg/Makefile - make/sun/rmi/Makefile - make/sun/rmi/corbalogcompile/Makefile - make/sun/rmi/corbalogsources/Makefile - make/sun/rmi/rmic/FILES.gmk - make/sun/rmi/rmic/Makefile - make/tools/Makefile - make/tools/idlj/Makefile - make/tools/logutil/Makefile - make/tools/strip_properties/Makefile - makefiles/BuildCorba.gmk - makefiles/Makefile Changeset: dae8ee5b71d9 Author: kizune Date: 2013-12-13 22:13 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/dae8ee5b71d9 Merge Changeset: 0354055127f5 Author: asaha Date: 2013-12-20 07:40 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/0354055127f5 Merge Changeset: 7ec1c16f6fb8 Author: asaha Date: 2014-01-02 15:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/7ec1c16f6fb8 Merge ! src/share/classes/com/sun/corba/se/impl/io/IIOPInputStream.java ! src/share/classes/com/sun/corba/se/impl/io/InputStreamHook.java ! src/share/classes/com/sun/corba/se/impl/ior/EncapsulationUtility.java Changeset: 1ecd4619f60c Author: katleman Date: 2014-01-03 11:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/1ecd4619f60c Added tag jdk8-b122 for changeset 0cd687347540 ! .hgtags Changeset: 9240e4c6b107 Author: asaha Date: 2014-01-03 15:57 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/9240e4c6b107 Merge From alexander.zuev at oracle.com Tue Jan 14 19:25:32 2014 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Tue, 14 Jan 2014 19:25:32 +0000 Subject: hg: jdk8/tl/hotspot: 21 new changesets Message-ID: <20140114192621.73DC36242F@hg.openjdk.java.net> Changeset: 7ccce1a6fa4d Author: coleenp Date: 2013-09-05 10:29 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7ccce1a6fa4d 8021266: Better life cycle for objects Summary: Improve life cycle for objects Reviewed-by: art, hseigel Contributed-by: gerard.ziemski at oracle.com ! src/share/vm/runtime/os.cpp Changeset: 2a907fd129cb Author: chegar Date: 2013-09-06 09:55 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2a907fd129cb Merge ! src/share/vm/runtime/os.cpp - test/runtime/7051189/Xchecksig.sh Changeset: 9b4ce069642e Author: chegar Date: 2013-09-14 20:40 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9b4ce069642e Merge ! src/share/vm/classfile/classFileParser.cpp - src/share/vm/classfile/genericSignatures.cpp - src/share/vm/classfile/genericSignatures.hpp ! src/share/vm/runtime/os.cpp Changeset: 6fa574bfd32a Author: chegar Date: 2013-10-03 19:13 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6fa574bfd32a Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/runtime/os.cpp - test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java - test/runtime/6878713/Test6878713.sh - test/runtime/6878713/testcase.jar - test/runtime/7020373/Test7020373.sh - test/runtime/7020373/testcase.jar Changeset: 6795fcebbf42 Author: chegar Date: 2013-10-21 14:08 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6795fcebbf42 Merge ! src/share/vm/classfile/classFileParser.cpp - test/testlibrary/AssertsTest.java - test/testlibrary/OutputAnalyzerReportingTest.java - test/testlibrary/OutputAnalyzerTest.java Changeset: c31f0cbe6d9e Author: chegar Date: 2013-11-03 07:50 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c31f0cbe6d9e Merge - src/share/vm/memory/metablock.cpp - src/share/vm/memory/metablock.hpp - test/compiler/8013496/Test8013496.sh - test/compiler/intrinsics/mathexact/CondTest.java - test/compiler/intrinsics/mathexact/ConstantTest.java - test/compiler/intrinsics/mathexact/LoadTest.java - test/compiler/intrinsics/mathexact/LoopDependentTest.java - test/compiler/intrinsics/mathexact/NonConstantTest.java - test/gc/7168848/HumongousAlloc.java Changeset: 0611ce949aaa Author: kizune Date: 2013-12-03 14:13 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0611ce949aaa Merge ! src/share/vm/classfile/classFileParser.cpp Changeset: e254e5940c19 Author: kizune Date: 2013-12-05 16:37 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e254e5940c19 Merge ! src/share/vm/classfile/classFileParser.cpp - test/compiler/jsr292/methodHandleExceptions/C.java - test/compiler/jsr292/methodHandleExceptions/I.java Changeset: 9063bd8808a7 Author: jrose Date: 2013-12-05 00:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9063bd8808a7 8029507: Enhance JVM method processing Summary: update MemberName.clazz correctly in MemberName.resolve; also pass lookupClass to MethodHandles::resolve_MemberName Reviewed-by: acorn, vlivanov ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp Changeset: 1b46c3672650 Author: kizune Date: 2013-12-13 22:13 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1b46c3672650 Merge Changeset: 8dbd61445631 Author: asaha Date: 2013-12-17 15:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8dbd61445631 Merge Changeset: ddff10b13587 Author: asaha Date: 2013-12-20 07:41 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ddff10b13587 Merge Changeset: 0b9c7eb6658b Author: amurillo Date: 2013-12-20 08:48 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0b9c7eb6658b 8030752: new hotspot build - hs25-b65 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 5832cdaf89c6 Author: hseigel Date: 2013-12-16 08:24 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5832cdaf89c6 8027804: JCK resolveMethod test fails expecting AbstractMethodError Summary: Create AME overpass methods and fix method search logic Reviewed-by: kamg, acorn, lfoltan, coleenp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klassVtable.cpp Changeset: 62e87648a4be Author: coleenp Date: 2013-12-19 20:28 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/62e87648a4be 8030633: nsk/jvmti/RedefineClasses/StressRedefine failed invalid method ordering length on Solaris Summary: A method with no declared methods was getting an AME overpass method with the latest change. The method_ordering array was not updated for the new methods. Reviewed-by: dcubed, acorn, dsamersoff, lfoltan, hseigel ! src/share/vm/classfile/defaultMethods.cpp Changeset: be840d0078bc Author: coleenp Date: 2013-12-20 14:03 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/be840d0078bc Merge Changeset: 55fb97c4c58d Author: mikael Date: 2013-12-24 11:48 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/55fb97c4c58d 8029233: Update copyright year to match last edit in jdk8 hotspot repository for 2013 Summary: Copyright year updated for files modified during 2013 Reviewed-by: twisti, iveresov ! agent/make/Makefile ! agent/src/os/linux/libproc.h ! agent/src/os/linux/salibelf.c ! agent/src/os/linux/symtab.c ! agent/src/os/solaris/proc/saproc.cpp ! agent/src/os/win32/windbg/sawindbg.cpp ! agent/src/share/classes/sun/jvm/hotspot/CLHSDB.java ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java ! agent/src/share/classes/sun/jvm/hotspot/HSDB.java ! agent/src/share/classes/sun/jvm/hotspot/LinuxVtblAccess.java ! agent/src/share/classes/sun/jvm/hotspot/asm/Disassembler.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciEnv.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciMethod.java ! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java ! agent/src/share/classes/sun/jvm/hotspot/compiler/CompileTask.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxOopHandle.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/amd64/LinuxAMD64CFrame.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/x86/LinuxX86CFrame.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgCDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windows/amd64/WindowsAMD64CFrame.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windows/x86/WindowsX86CFrame.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/JVMTIThreadState.java ! agent/src/share/classes/sun/jvm/hotspot/memory/CMSCollector.java ! agent/src/share/classes/sun/jvm/hotspot/memory/DictionaryEntry.java ! agent/src/share/classes/sun/jvm/hotspot/memory/SymbolTable.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ArrayKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Klass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/MethodCounters.java ! agent/src/share/classes/sun/jvm/hotspot/oops/MethodData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java ! agent/src/share/classes/sun/jvm/hotspot/opto/PhaseCFG.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/ThreadLocalAllocBuffer.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/bsd_amd64/BsdAMD64JavaThreadPDAccess.java ! agent/src/share/classes/sun/jvm/hotspot/tools/FinalizerInfo.java ! agent/src/share/classes/sun/jvm/hotspot/tools/FlagDumper.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapDumper.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JInfo.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JSnap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JStack.java ! agent/src/share/classes/sun/jvm/hotspot/tools/ObjectHistogram.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PMap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/StackTrace.java ! agent/src/share/classes/sun/jvm/hotspot/tools/SysPropsDumper.java ! agent/src/share/classes/sun/jvm/hotspot/tools/Tool.java ! agent/src/share/classes/sun/jvm/hotspot/tools/soql/JSDB.java ! agent/src/share/classes/sun/jvm/hotspot/tools/soql/SOQL.java ! agent/src/share/classes/sun/jvm/hotspot/types/basic/BasicTypeDataBase.java ! agent/src/share/classes/sun/jvm/hotspot/ui/SAPanel.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/AbstractHeapGraphWriter.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HeapGXLWriter.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/JSJavaInstanceKlass.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/sa.js ! make/bsd/makefiles/adlc.make ! make/bsd/makefiles/minimal1.make ! make/hotspot.script ! make/linux/makefiles/adlc.make ! make/linux/makefiles/jsig.make ! make/linux/makefiles/minimal1.make ! make/linux/makefiles/saproc.make ! make/sa.files ! make/solaris/makefiles/adlc.make ! make/solaris/makefiles/gcc.make ! make/windows/build_vm_def.sh ! make/windows/makefiles/adlc.make ! make/windows/makefiles/debug.make ! make/windows/makefiles/product.make ! make/windows/makefiles/rules.make ! make/windows/makefiles/sa.make ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_FrameMap_sparc.cpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/c1_globals_sparc.hpp ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/sparc/vm/c2_init_sparc.cpp ! src/cpu/sparc/vm/disassembler_sparc.hpp ! src/cpu/sparc/vm/frame_sparc.inline.hpp ! src/cpu/sparc/vm/globalDefinitions_sparc.hpp ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/sparc/vm/jni_sparc.h ! src/cpu/sparc/vm/nativeInst_sparc.hpp ! src/cpu/sparc/vm/register_sparc.hpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/stubRoutines_sparc.cpp ! src/cpu/sparc/vm/stubRoutines_sparc.hpp ! src/cpu/sparc/vm/vmStructs_sparc.hpp ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/cpu/x86/vm/bytecodeInterpreter_x86.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_FrameMap_x86.cpp ! src/cpu/x86/vm/c1_FrameMap_x86.hpp ! src/cpu/x86/vm/c1_LinearScan_x86.cpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/c1_globals_x86.hpp ! src/cpu/x86/vm/c2_globals_x86.hpp ! src/cpu/x86/vm/frame_x86.hpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/cpu/x86/vm/globalDefinitions_x86.hpp ! src/cpu/x86/vm/register_definitions_x86.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86.hpp ! src/cpu/x86/vm/vmStructs_x86.hpp ! src/cpu/x86/vm/vtableStubs_x86_32.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/cpu/zero/vm/assembler_zero.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/entryFrame_zero.hpp ! src/cpu/zero/vm/frame_zero.cpp ! src/cpu/zero/vm/frame_zero.inline.hpp ! src/cpu/zero/vm/globals_zero.hpp ! src/cpu/zero/vm/icBuffer_zero.cpp ! src/cpu/zero/vm/interp_masm_zero.hpp ! src/cpu/zero/vm/interpreter_zero.cpp ! src/cpu/zero/vm/jni_zero.h ! src/cpu/zero/vm/nativeInst_zero.hpp ! src/cpu/zero/vm/register_zero.cpp ! src/cpu/zero/vm/relocInfo_zero.cpp ! src/cpu/zero/vm/sharedRuntime_zero.cpp ! src/cpu/zero/vm/sharkFrame_zero.hpp ! src/cpu/zero/vm/stubGenerator_zero.cpp ! src/cpu/zero/vm/vmStructs_zero.hpp ! src/cpu/zero/vm/vtableStubs_zero.cpp ! src/os/bsd/dtrace/jvm_dtrace.c ! src/os/posix/vm/os_posix.hpp ! src/os/solaris/dtrace/jvm_dtrace.c ! src/os/solaris/vm/globals_solaris.hpp ! src/os/windows/vm/decoder_windows.hpp ! src/os_cpu/bsd_x86/vm/bsd_x86_32.s ! src/os_cpu/bsd_x86/vm/bsd_x86_64.s ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/bsd_x86/vm/vmStructs_bsd_x86.hpp ! src/os_cpu/bsd_zero/vm/globals_bsd_zero.hpp ! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp ! src/os_cpu/bsd_zero/vm/thread_bsd_zero.hpp ! src/os_cpu/bsd_zero/vm/vmStructs_bsd_zero.hpp ! src/os_cpu/linux_sparc/vm/globals_linux_sparc.hpp ! src/os_cpu/linux_sparc/vm/linux_sparc.s ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_sparc/vm/vmStructs_linux_sparc.hpp ! src/os_cpu/linux_x86/vm/globals_linux_x86.hpp ! src/os_cpu/linux_x86/vm/linux_x86_32.s ! src/os_cpu/linux_x86/vm/linux_x86_64.s ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.hpp ! src/os_cpu/linux_x86/vm/vmStructs_linux_x86.hpp ! src/os_cpu/linux_zero/vm/globals_linux_zero.hpp ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp ! src/os_cpu/linux_zero/vm/vmStructs_linux_zero.hpp ! src/os_cpu/solaris_sparc/vm/globals_solaris_sparc.hpp ! src/os_cpu/solaris_sparc/vm/solaris_sparc.il ! src/os_cpu/solaris_sparc/vm/solaris_sparc.s ! src/os_cpu/solaris_sparc/vm/vmStructs_solaris_sparc.hpp ! src/os_cpu/solaris_x86/vm/globals_solaris_x86.hpp ! src/os_cpu/solaris_x86/vm/solaris_x86_32.s ! src/os_cpu/solaris_x86/vm/solaris_x86_64.s ! src/os_cpu/solaris_x86/vm/vmStructs_solaris_x86.hpp ! src/os_cpu/windows_x86/vm/globals_windows_x86.hpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.hpp ! src/os_cpu/windows_x86/vm/vmStructs_windows_x86.hpp ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/CallSite.java ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogParser.java ! src/share/tools/ProjectCreator/WinGammaPlatformVC7.java ! src/share/tools/hsdis/hsdis.c ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/dfa.cpp ! src/share/vm/adlc/dict2.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/asm/macroAssembler.hpp ! src/share/vm/asm/macroAssembler.inline.hpp ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Canonicalizer.hpp ! src/share/vm/c1/c1_CodeStubs.hpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_Compiler.cpp ! src/share/vm/c1/c1_Compiler.hpp ! src/share/vm/c1/c1_FrameMap.cpp ! src/share/vm/c1/c1_FrameMap.hpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_IR.cpp ! src/share/vm/c1/c1_IR.hpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_InstructionPrinter.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_RangeCheckElimination.cpp ! src/share/vm/c1/c1_RangeCheckElimination.hpp ! src/share/vm/c1/c1_Runtime1.hpp ! src/share/vm/c1/c1_ValueMap.cpp ! src/share/vm/c1/c1_ValueMap.hpp ! src/share/vm/c1/c1_globals.cpp ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/bcEscapeAnalyzer.hpp ! src/share/vm/ci/ciArray.cpp ! src/share/vm/ci/ciArray.hpp ! src/share/vm/ci/ciClassList.hpp ! src/share/vm/ci/ciConstant.hpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciFlags.hpp ! src/share/vm/ci/ciInstance.cpp ! src/share/vm/ci/ciInstanceKlass.hpp ! src/share/vm/ci/ciKlass.cpp ! src/share/vm/ci/ciKlass.hpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/ci/ciObjArrayKlass.cpp ! src/share/vm/ci/ciObjArrayKlass.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciObjectFactory.hpp ! src/share/vm/ci/ciStreams.hpp ! src/share/vm/ci/ciType.cpp ! src/share/vm/ci/ciType.hpp ! src/share/vm/ci/ciTypeArray.cpp ! src/share/vm/ci/ciTypeArrayKlass.hpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/ci/ciUtilities.hpp ! src/share/vm/classfile/bytecodeAssembler.cpp ! src/share/vm/classfile/classFileStream.cpp ! src/share/vm/classfile/classFileStream.hpp ! src/share/vm/classfile/classLoaderData.inline.hpp ! src/share/vm/classfile/vmSymbols.cpp ! src/share/vm/code/compiledIC.hpp ! src/share/vm/code/compressedStream.cpp ! src/share/vm/code/debugInfo.hpp ! src/share/vm/code/icBuffer.hpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/code/stubs.cpp ! src/share/vm/code/stubs.hpp ! src/share/vm/compiler/abstractCompiler.cpp ! src/share/vm/compiler/abstractCompiler.hpp ! src/share/vm/compiler/compileLog.cpp ! src/share/vm/compiler/compileLog.hpp ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/compiler/disassembler.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/adaptiveFreeList.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/adaptiveFreeList.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.hpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp ! src/share/vm/gc_implementation/g1/g1AllocRegion.hpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1EvacFailure.hpp ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.inline.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp ! src/share/vm/gc_implementation/g1/vmStructs_g1.hpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/gc_implementation/parallelScavenge/adjoiningGenerations.cpp ! src/share/vm/gc_implementation/parallelScavenge/adjoiningGenerations.hpp ! src/share/vm/gc_implementation/parallelScavenge/asPSOldGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/asPSOldGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/asPSYoungGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskThread.cpp ! src/share/vm/gc_implementation/parallelScavenge/objectStartArray.cpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.cpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.hpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.cpp ! src/share/vm/gc_implementation/shared/allocationStats.cpp ! src/share/vm/gc_implementation/shared/concurrentGCThread.hpp ! src/share/vm/gc_implementation/shared/gSpaceCounters.cpp ! src/share/vm/gc_implementation/shared/gSpaceCounters.hpp ! src/share/vm/gc_implementation/shared/gcAdaptivePolicyCounters.hpp ! src/share/vm/gc_implementation/shared/immutableSpace.cpp ! src/share/vm/gc_implementation/shared/isGCActiveMark.hpp ! src/share/vm/gc_implementation/shared/markSweep.inline.hpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.hpp ! src/share/vm/gc_implementation/shared/mutableSpace.cpp ! src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp ! src/share/vm/gc_implementation/shared/spaceCounters.cpp ! src/share/vm/gc_implementation/shared/spaceCounters.hpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/gc_interface/gcCause.cpp ! src/share/vm/gc_interface/gcCause.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/cppInterpreter.hpp ! src/share/vm/interpreter/interpreter.hpp ! src/share/vm/interpreter/templateInterpreter.hpp ! src/share/vm/interpreter/templateInterpreterGenerator.hpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/memory/binaryTreeDictionary.hpp ! src/share/vm/memory/blockOffsetTable.cpp ! src/share/vm/memory/freeBlockDictionary.cpp ! src/share/vm/memory/freeList.cpp ! src/share/vm/memory/freeList.hpp ! src/share/vm/memory/gcLocker.cpp ! src/share/vm/memory/gcLocker.hpp ! src/share/vm/memory/genRemSet.cpp ! src/share/vm/memory/genRemSet.hpp ! src/share/vm/memory/generation.hpp ! src/share/vm/memory/generationSpec.cpp ! src/share/vm/memory/heap.hpp ! src/share/vm/memory/iterator.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/memory/metaspaceCounters.cpp ! src/share/vm/memory/metaspaceCounters.hpp ! src/share/vm/memory/sharedHeap.hpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/memory/specialized_oop_closures.hpp ! src/share/vm/memory/tenuredGeneration.cpp ! src/share/vm/memory/tenuredGeneration.hpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/arrayOop.hpp ! src/share/vm/oops/compiledICHolder.cpp ! src/share/vm/oops/fieldInfo.hpp ! src/share/vm/oops/instanceClassLoaderKlass.cpp ! src/share/vm/oops/instanceClassLoaderKlass.hpp ! src/share/vm/oops/instanceMirrorKlass.cpp ! src/share/vm/oops/instanceOop.hpp ! src/share/vm/oops/instanceRefKlass.hpp ! src/share/vm/oops/klassPS.hpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/objArrayKlass.hpp ! src/share/vm/oops/objArrayKlass.inline.hpp ! src/share/vm/oops/oop.pcgc.inline.hpp ! src/share/vm/oops/oop.psgc.inline.hpp ! src/share/vm/oops/typeArrayKlass.cpp ! src/share/vm/oops/typeArrayKlass.hpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/buildOopMap.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/c2compiler.hpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/classes.cpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/coalesce.hpp ! src/share/vm/opto/connode.cpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/domgraph.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/generateOptoStub.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/idealKit.hpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/live.hpp ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/macro.hpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/multnode.cpp ! src/share/vm/opto/multnode.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/optoreg.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/output.hpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/phase.cpp ! src/share/vm/opto/phase.hpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/postaloc.cpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/opto/regalloc.cpp ! src/share/vm/opto/regalloc.hpp ! src/share/vm/opto/subnode.cpp ! src/share/vm/opto/subnode.hpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/superword.hpp ! src/share/vm/precompiled/precompiled.hpp ! src/share/vm/prims/forte.cpp ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jvm_misc.hpp ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.hpp ! src/share/vm/prims/jvmtiEnter.xsl ! src/share/vm/prims/jvmtiEnvBase.hpp ! src/share/vm/prims/jvmtiEnvThreadState.cpp ! src/share/vm/prims/jvmtiEventController.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiGetLoadedClasses.cpp ! src/share/vm/prims/jvmtiTrace.hpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/prims/perf.cpp ! src/share/vm/prims/wbtestmethods/parserTests.hpp ! src/share/vm/prims/whitebox.hpp ! src/share/vm/runtime/advancedThresholdPolicy.hpp ! src/share/vm/runtime/atomic.cpp ! src/share/vm/runtime/atomic.hpp ! src/share/vm/runtime/compilationPolicy.hpp ! src/share/vm/runtime/fprofiler.hpp ! src/share/vm/runtime/globals_extension.hpp ! src/share/vm/runtime/handles.inline.hpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/jniHandles.cpp ! src/share/vm/runtime/mutex.cpp ! src/share/vm/runtime/perfData.hpp ! src/share/vm/runtime/reflection.hpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/signature.cpp ! src/share/vm/runtime/signature.hpp ! src/share/vm/runtime/stubCodeGenerator.cpp ! src/share/vm/runtime/synchronizer.hpp ! src/share/vm/runtime/unhandledOops.hpp ! src/share/vm/runtime/vframe.cpp ! src/share/vm/runtime/vframe.hpp ! src/share/vm/runtime/vframeArray.hpp ! src/share/vm/runtime/virtualspace.hpp ! src/share/vm/runtime/vm_version.hpp ! src/share/vm/services/classLoadingService.hpp ! src/share/vm/services/dtraceAttacher.cpp ! src/share/vm/services/g1MemoryPool.hpp ! src/share/vm/services/memReporter.cpp ! src/share/vm/services/memReporter.hpp ! src/share/vm/services/memSnapshot.hpp ! src/share/vm/services/memoryManager.hpp ! src/share/vm/services/memoryPool.hpp ! src/share/vm/services/memoryService.cpp ! src/share/vm/services/memoryService.hpp ! src/share/vm/services/memoryUsage.hpp ! src/share/vm/services/psMemoryPool.hpp ! src/share/vm/services/threadService.hpp ! src/share/vm/shark/sharkBlock.cpp ! src/share/vm/shark/sharkBuilder.cpp ! src/share/vm/shark/sharkCompiler.cpp ! src/share/vm/shark/sharkCompiler.hpp ! src/share/vm/shark/sharkConstant.cpp ! src/share/vm/shark/sharkFunction.cpp ! src/share/vm/shark/sharkInliner.cpp ! src/share/vm/shark/sharkInvariants.hpp ! src/share/vm/shark/sharkTopLevelBlock.cpp ! src/share/vm/utilities/bitMap.cpp ! src/share/vm/utilities/bitMap.hpp ! src/share/vm/utilities/bitMap.inline.hpp ! src/share/vm/utilities/decoder.cpp ! src/share/vm/utilities/decoder.hpp ! src/share/vm/utilities/elfFile.cpp ! src/share/vm/utilities/elfFile.hpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/globalDefinitions.cpp ! src/share/vm/utilities/globalDefinitions_visCPP.hpp ! src/share/vm/utilities/growableArray.hpp ! src/share/vm/utilities/hashtable.hpp ! src/share/vm/utilities/macros.hpp ! src/share/vm/utilities/numberSeq.cpp ! src/share/vm/utilities/ostream.hpp ! src/share/vm/utilities/top.hpp ! src/share/vm/utilities/yieldingWorkgroup.cpp ! test/Makefile ! test/TEST.ROOT ! test/compiler/5091921/Test7005594.sh ! test/compiler/6431242/Test.java ! test/compiler/6589834/Test_ia32.java ! test/compiler/6636138/Test1.java ! test/compiler/6636138/Test2.java ! test/compiler/6795161/Test.java ! test/compiler/6857159/Test6857159.sh ! test/compiler/7068051/Test7068051.sh ! test/compiler/7070134/Test7070134.sh ! test/compiler/7200264/Test7200264.sh ! test/compiler/8000805/Test8000805.java ! test/compiler/8005419/Test8005419.java ! test/gc/6941923/Test6941923.java ! test/gc/g1/TestHumongousAllocInitialMark.java ! test/runtime/6626217/Test6626217.sh ! test/runtime/7110720/Test7110720.sh ! test/runtime/7162488/Test7162488.sh ! test/runtime/RedefineObject/Agent.java ! test/runtime/RedefineObject/TestRedefineObject.java Changeset: d3521d8e562a Author: amurillo Date: 2013-12-27 07:32 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d3521d8e562a Added tag hs25-b65 for changeset 55fb97c4c58d ! .hgtags Changeset: a902f789ea1f Author: asaha Date: 2014-01-02 15:19 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a902f789ea1f Merge Changeset: 591135a7d6f9 Author: katleman Date: 2014-01-03 11:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/591135a7d6f9 Added tag jdk8-b122 for changeset d3521d8e562a ! .hgtags Changeset: 3b69a859e3f9 Author: asaha Date: 2014-01-03 15:58 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3b69a859e3f9 Merge From alexander.zuev at oracle.com Tue Jan 14 19:30:13 2014 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Tue, 14 Jan 2014 19:30:13 +0000 Subject: hg: jdk8/tl/jaxp: 18 new changesets Message-ID: <20140114193052.B889062431@hg.openjdk.java.net> Changeset: 51bbdd517b93 Author: joehw Date: 2013-08-26 21:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/51bbdd517b93 8022935: Enhance Apache resolver classes Reviewed-by: alanb, mchung, skoivu ! src/com/sun/org/apache/xml/internal/resolver/CatalogManager.java ! src/com/sun/org/apache/xml/internal/resolver/readers/DOMCatalogReader.java ! src/com/sun/org/apache/xml/internal/resolver/readers/SAXCatalogReader.java Changeset: d6d8302ecf8f Author: chegar Date: 2013-08-30 10:15 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/d6d8302ecf8f Merge ! src/com/sun/org/apache/xerces/internal/parsers/DTDConfiguration.java ! src/com/sun/org/apache/xerces/internal/parsers/NonValidatingConfiguration.java ! src/com/sun/org/apache/xerces/internal/parsers/SAXParser.java Changeset: aef8ae2fcec4 Author: chegar Date: 2013-09-06 09:55 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/aef8ae2fcec4 Merge Changeset: 0ce80229af71 Author: chegar Date: 2013-09-14 20:43 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/0ce80229af71 Merge Changeset: 5e6bf44f3b7d Author: chegar Date: 2013-10-03 19:18 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/5e6bf44f3b7d Merge Changeset: 54a0dd196acd Author: chegar Date: 2013-10-21 14:27 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/54a0dd196acd Merge Changeset: 10b3a127b1fc Author: joehw Date: 2013-10-22 13:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/10b3a127b1fc 8025018: Enhance JAX-P set up Reviewed-by: alanb, dfuchs, lancea, ahgross ! src/com/sun/org/apache/xalan/internal/lib/ExsltStrings.java ! src/com/sun/org/apache/xalan/internal/lib/Extensions.java Changeset: ef71f2353352 Author: chegar Date: 2013-10-25 09:32 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/ef71f2353352 Merge Changeset: e68f3e585d7d Author: chegar Date: 2013-11-03 07:32 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/e68f3e585d7d Merge Changeset: fb51ed270f53 Author: joehw Date: 2013-11-14 10:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/fb51ed270f53 8027201: Enhance JAX-P set up Reviewed-by: alanb, dfuchs, lancea, hawtin ! src/com/sun/org/apache/xalan/internal/lib/ExsltStrings.java ! src/com/sun/org/apache/xalan/internal/lib/Extensions.java Changeset: 932684ede1c6 Author: joehw Date: 2013-11-27 14:28 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/932684ede1c6 8028111: XML readers share the same entity expansion counter Reviewed-by: alanb, lancea, dfuchs, ahgross ! src/com/sun/org/apache/xalan/internal/XalanConstants.java ! src/com/sun/org/apache/xalan/internal/utils/XMLSecurityManager.java ! src/com/sun/org/apache/xerces/internal/impl/Constants.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDTDScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java ! src/com/sun/org/apache/xerces/internal/impl/XMLNSDocumentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/utils/XMLLimitAnalyzer.java ! src/com/sun/org/apache/xerces/internal/utils/XMLSecurityManager.java ! src/com/sun/org/apache/xerces/internal/xni/parser/XMLDTDScanner.java Changeset: 2a8fce63503a Author: kizune Date: 2013-12-03 14:13 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/2a8fce63503a Merge ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java Changeset: 5be9182ceb48 Author: kizune Date: 2013-12-05 16:37 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/5be9182ceb48 Merge - make/jprt.properties - make/scripts/update_src.sh - makefiles/BuildJaxp.gmk - makefiles/Makefile Changeset: 41068d69fe3e Author: kizune Date: 2013-12-13 22:13 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/41068d69fe3e Merge Changeset: f2c9c0f64280 Author: asaha Date: 2013-12-20 07:42 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/f2c9c0f64280 Merge Changeset: 01b611e0c341 Author: asaha Date: 2014-01-02 15:20 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/01b611e0c341 Merge ! src/com/sun/org/apache/xalan/internal/XalanConstants.java ! src/com/sun/org/apache/xerces/internal/impl/Constants.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDTDScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentScannerImpl.java Changeset: 4e35b5b6d2e5 Author: katleman Date: 2014-01-03 11:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/4e35b5b6d2e5 Added tag jdk8-b122 for changeset 93bf25903af0 ! .hgtags Changeset: 985376a77c4c Author: asaha Date: 2014-01-03 15:58 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/985376a77c4c Merge From alexander.zuev at oracle.com Tue Jan 14 19:31:06 2014 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Tue, 14 Jan 2014 19:31:06 +0000 Subject: hg: jdk8/tl/jaxws: 8 new changesets Message-ID: <20140114193123.8797F62432@hg.openjdk.java.net> Changeset: b0c2840e2513 Author: mkos Date: 2013-11-22 21:11 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/b0c2840e2513 8010935: Better XML handling 8027378: Two closed/javax/xml/8005432 fails with jdk7u51b04 8028382: Two javax/xml/8005433 tests still fail after the fix JDK-8028147 Summary: base fix + fixes for test regressions; fix also reviewed by Maxim Soloviev, Alexander Fomin Reviewed-by: mchung, mgrebac, mullan ! src/share/jaxws_classes/com/sun/tools/internal/jxc/model/nav/ApNavigator.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/model/nav/EagerNType.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/model/nav/NavigatorImpl.java + src/share/jaxws_classes/com/sun/tools/internal/xjc/model/nav/Utils.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/api/JAXBRIContext.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/api/TypeReference.java + src/share/jaxws_classes/com/sun/xml/internal/bind/api/Utils.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/ModelBuilder.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeAnyTypeImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeBuiltinLeafInfoImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeElementInfoImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeModelBuilder.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeTypeInfoSetImpl.java + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/Utils.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/nav/Navigator.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/nav/ReflectionNavigator.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeTypeInfoSet.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/ClassBeanInfoImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/ElementBeanInfoImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/JAXBContextImpl.java + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/Utils.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/property/ArrayProperty.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/property/SingleMapNodeProperty.java + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/property/Utils.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/Accessor.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/Lister.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/TransducedAccessor.java + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/Utils.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/fault/SOAPFaultBuilder.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/RuntimeModeler.java + src/share/jaxws_classes/com/sun/xml/internal/ws/model/Utils.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/WrapperBeanGenerator.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/BindingHelper.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/TypeInfo.java + src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/Utils.java Changeset: f80c37c168f7 Author: kizune Date: 2013-12-03 14:13 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/f80c37c168f7 Merge Changeset: c99140027351 Author: kizune Date: 2013-12-05 16:37 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/c99140027351 Merge - make/jprt.properties - make/scripts/update_src.sh - makefiles/BuildJaxws.gmk - makefiles/Makefile Changeset: ca6bb6b558a6 Author: kizune Date: 2013-12-13 22:13 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/ca6bb6b558a6 Merge Changeset: d4b785ac4079 Author: asaha Date: 2013-12-20 07:42 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/d4b785ac4079 Merge Changeset: 91f5c542ccad Author: katleman Date: 2014-01-03 11:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/91f5c542ccad Added tag jdk8-b122 for changeset bc622ba563f9 ! .hgtags Changeset: c07fc967624b Author: asaha Date: 2014-01-03 15:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/c07fc967624b Merge Changeset: 6547da5c3277 Author: kizune Date: 2014-01-14 23:10 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/6547da5c3277 Merge From alexander.zuev at oracle.com Tue Jan 14 19:35:25 2014 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Tue, 14 Jan 2014 19:35:25 +0000 Subject: hg: jdk8/tl/jdk: 53 new changesets Message-ID: <20140114194639.1F1C362434@hg.openjdk.java.net> Changeset: 75142ce752da Author: malenkov Date: 2013-12-23 16:24 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/75142ce752da 8030118: Document listeners fired outside document lock Reviewed-by: art, serb ! src/share/classes/javax/swing/text/AbstractDocument.java - test/javax/swing/text/AbstractDocument/7146146/bug7146146.java + test/javax/swing/text/AbstractDocument/8030118/Test8030118.java Changeset: 8b5985f1a0b5 Author: lana Date: 2013-12-25 11:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8b5985f1a0b5 Merge - src/share/classes/sun/util/resources/pt/LocaleNames_pt_BR.properties - test/sun/security/ssl/javax/net/ssl/SSLContextVersion.java Changeset: e1499442453b Author: lana Date: 2013-12-26 22:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e1499442453b Merge ! src/share/classes/javax/swing/text/AbstractDocument.java Changeset: 7e10ee00fe41 Author: katleman Date: 2014-01-03 11:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7e10ee00fe41 Added tag jdk8-b122 for changeset e1499442453b ! .hgtags Changeset: 484e16c0a040 Author: nikgor Date: 2014-01-07 12:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/484e16c0a040 8004562: Better support for crossdomain.xml Reviewed-by: herrick, ngthomas, chegar ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java Changeset: 0dfcc99c6f5d Author: weijun Date: 2013-08-16 17:57 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0dfcc99c6f5d 8022945: Enhance JNDI implementation classes Reviewed-by: xuelei, ahgross, skoivu ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! test/java/lang/SecurityManager/CheckPackageAccess.java Changeset: 46c8720ef36f Author: lancea Date: 2013-08-21 11:05 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/46c8720ef36f 8022904: Enhance JDBC Parsers Reviewed-by: alanb, skoivu ! src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java ! src/share/classes/javax/sql/rowset/spi/SyncFactory.java Changeset: 428288ee9c99 Author: valeriep Date: 2013-08-21 11:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/428288ee9c99 8022927: Input validation for byte/endian conversions Summary: Add additional boundary checks Reviewed-by: ascarpino ! src/share/classes/sun/security/provider/ByteArrayAccess.java Changeset: 24a7024bd86b Author: bae Date: 2013-08-23 12:41 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/24a7024bd86b 8021394: Better color profiles Reviewed-by: prr, vadim, mschoene ! src/share/native/sun/java2d/cmm/lcms/cmsintrp.c Changeset: ff2792868d89 Author: chegar Date: 2013-08-23 12:32 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ff2792868d89 Merge Changeset: 036ad7864d35 Author: chegar Date: 2013-08-30 09:38 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/036ad7864d35 Merge ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: 2ae5cf0805de Author: malenkov Date: 2013-09-02 11:41 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2ae5cf0805de 8023245: Enhance Beans decoding Reviewed-by: art, skoivu, alanb ! src/share/classes/com/sun/beans/decoder/DocumentHandler.java Changeset: 9bc1411d0223 Author: coleenp Date: 2013-09-05 10:29 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9bc1411d0223 8021266: Better life cycle for objects Summary: Improve life cycle for objects Reviewed-by: art, hseigel Contributed-by: gerard.ziemski at oracle.com ! make/common/Release.gmk ! make/java/Makefile ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CreateJars.gmk ! makefiles/GenerateJavaSources.gmk ! makefiles/Images.gmk ! makefiles/Profiles.gmk Changeset: 46e86a9402ab Author: chegar Date: 2013-09-06 13:36 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/46e86a9402ab Merge ! makefiles/Profiles.gmk ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! test/java/lang/SecurityManager/CheckPackageAccess.java Changeset: 4cab5eb93124 Author: xuelei Date: 2013-09-07 20:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4cab5eb93124 8023069: Enhance TLS connections Summary: Also reviewed by Alexander Fomin and Andrew Gross Reviewed-by: wetmore ! src/share/classes/com/sun/crypto/provider/TlsRsaPremasterSecretGenerator.java ! src/share/classes/sun/security/internal/spec/TlsRsaPremasterSecretParameterSpec.java ! src/share/classes/sun/security/pkcs11/P11RSACipher.java ! src/share/classes/sun/security/pkcs11/P11TlsRsaPremasterSecretGenerator.java ! src/share/classes/sun/security/rsa/RSAPadding.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/RSAClientKeyExchange.java Changeset: ac3e7b3c1a00 Author: weijun Date: 2013-09-13 15:37 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ac3e7b3c1a00 8024306: Enhance Subject consistency Summary: Also reviewed by Alexander Fomin Reviewed-by: mullan, ahgross ! src/share/classes/javax/security/auth/Subject.java Changeset: 4b74f9ad3dd7 Author: weijun Date: 2013-09-13 15:37 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4b74f9ad3dd7 8023672: Enhance jar file validation Summary: Also reviewed by Chris Ries and Alexander Fomin Reviewed-by: mullan, sherman ! src/share/classes/java/util/jar/JarVerifier.java Changeset: 432c348e15bc Author: vadim Date: 2013-09-13 13:17 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/432c348e15bc 8023057: Enhance start up image display Reviewed-by: anthony, serb, mschoene ! src/macosx/native/sun/awt/splashscreen/splashscreen_sys.m ! src/share/native/sun/awt/splashscreen/splashscreen_impl.c ! src/solaris/native/sun/awt/splashscreen/splashscreen_sys.c Changeset: ca700a3c1708 Author: chegar Date: 2013-09-14 19:23 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ca700a3c1708 Merge Changeset: d931b672bfa9 Author: prr Date: 2013-09-19 08:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d931b672bfa9 8025034: Improve layout lookups Reviewed-by: mschoene, vadim, srl ! src/share/native/sun/font/layout/LookupProcessor.cpp Changeset: a90e9b3c99b8 Author: weijun Date: 2013-09-19 10:40 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a90e9b3c99b8 8024302: Clarify jar verifications 8023338: Update jarsigner to encourage timestamping Reviewed-by: mullan, ahgross ! src/share/classes/sun/security/tools/jarsigner/Main.java ! src/share/classes/sun/security/tools/jarsigner/Resources.java ! test/sun/security/tools/jarsigner/TimestampCheck.java ! test/sun/security/tools/jarsigner/concise_jarsigner.sh ! test/sun/security/tools/jarsigner/ts.sh + test/sun/security/tools/jarsigner/warnings.sh Changeset: f996a185e9a1 Author: weijun Date: 2013-09-19 10:41 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f996a185e9a1 8024659: Clarify JarFile API Reviewed-by: mullan, ahgross ! src/share/classes/java/util/jar/JarFile.java Changeset: f8b097b01270 Author: chegar Date: 2013-10-03 19:07 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f8b097b01270 Merge ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CreateJars.gmk ! makefiles/Images.gmk ! src/share/classes/javax/security/auth/Subject.java ! src/share/classes/sun/security/ssl/Handshaker.java Changeset: 1e3216123667 Author: chegar Date: 2013-10-04 14:51 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1e3216123667 Merge Changeset: 282c5e92d9a0 Author: malenkov Date: 2013-10-04 19:23 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/282c5e92d9a0 8025448: Enhance listening events Reviewed-by: art, skoivu ! src/share/classes/javax/swing/event/EventListenerList.java Changeset: 146dd44703f7 Author: chegar Date: 2013-10-07 11:32 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/146dd44703f7 Merge Changeset: 3cd01bc784b2 Author: dfuchs Date: 2013-10-07 12:09 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3cd01bc784b2 8024867: Enhance logging start up Reviewed-by: mchung, hawtin ! src/share/classes/java/util/logging/LogManager.java Changeset: d0a5383a63ad Author: weijun Date: 2013-10-09 18:58 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d0a5383a63ad 8026037: [TESTBUG] sun/security/tools/jarsigner/warnings.sh test fails on Solaris Reviewed-by: chegar Contributed-by: Artem Smotrakov ! test/sun/security/tools/jarsigner/warnings.sh Changeset: b90047350153 Author: jfranck Date: 2013-10-11 13:14 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b90047350153 8023301: Enhance generic classes Reviewed-by: mchung, hawtin ! src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java ! src/share/classes/sun/reflect/misc/ReflectUtil.java Changeset: eafa41f4e9fd Author: weijun Date: 2013-10-12 10:22 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eafa41f4e9fd 8026304: jarsigner output bad grammar Reviewed-by: chegar, coffeys Contributed-by: Artem Smotrakov ! src/share/classes/sun/security/tools/jarsigner/Resources.java Changeset: 62a8a26dca09 Author: xuelei Date: 2013-10-12 20:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/62a8a26dca09 8025026: Enhance canonicalization Summary: Don't use cached null xmlns definition. Also reviewed by Alexander Fomin Reviewed-by: mullan, hawtin ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer11.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315Excl.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/CanonicalizerBase.java Changeset: c1f6ed408492 Author: prr Date: 2013-10-14 16:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c1f6ed408492 8026176: Enhance document printing Reviewed-by: bae, jgodinez ! src/share/classes/javax/print/SimpleDoc.java Changeset: 5cb70d52ae61 Author: xuelei Date: 2013-10-15 18:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5cb70d52ae61 8026204: Enhance auth login contexts Summary: Enforce package access control with current context. Also reviewed by Alexander Fomin Reviewed-by: weijun, ahgross ! src/share/classes/javax/security/auth/login/LoginContext.java Changeset: 48dc2eacb0e5 Author: malenkov Date: 2013-10-16 13:26 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/48dc2eacb0e5 8026172: Enhance UI Management Reviewed-by: art, skoivu ! src/share/classes/javax/swing/SwingUtilities.java Changeset: 76262685781c Author: xuelei Date: 2013-10-16 18:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/76262685781c 8025758: Enhance Naming management Summary: Enforce package access control with current context. Also reviewed by Alexander Fomin Reviewed-by: weijun, ahgross ! src/share/classes/com/sun/naming/internal/FactoryEnumeration.java ! src/share/classes/com/sun/naming/internal/VersionHelper12.java Changeset: d4f4a9915357 Author: prr Date: 2013-10-17 09:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d4f4a9915357 8024530: Enhance font process resilience Reviewed-by: mschoene, bae, srl, prr ! src/share/native/sun/font/layout/AlternateSubstSubtables.cpp ! src/share/native/sun/font/layout/AnchorTables.cpp ! src/share/native/sun/font/layout/AnchorTables.h ! src/share/native/sun/font/layout/ArabicLayoutEngine.cpp ! src/share/native/sun/font/layout/ArabicShaping.cpp ! src/share/native/sun/font/layout/CanonShaping.cpp ! src/share/native/sun/font/layout/CharSubstitutionFilter.h ! src/share/native/sun/font/layout/ClassDefinitionTables.h ! src/share/native/sun/font/layout/ContextualSubstSubtables.cpp ! src/share/native/sun/font/layout/ContextualSubstSubtables.h ! src/share/native/sun/font/layout/CoverageTables.cpp ! src/share/native/sun/font/layout/CoverageTables.h ! src/share/native/sun/font/layout/CursiveAttachmentSubtables.cpp ! src/share/native/sun/font/layout/DeviceTables.cpp ! src/share/native/sun/font/layout/DeviceTables.h ! src/share/native/sun/font/layout/ExtensionSubtables.cpp ! src/share/native/sun/font/layout/ExtensionSubtables.h ! src/share/native/sun/font/layout/GDEFMarkFilter.cpp ! src/share/native/sun/font/layout/GDEFMarkFilter.h ! src/share/native/sun/font/layout/GlyphIterator.cpp ! src/share/native/sun/font/layout/GlyphIterator.h ! src/share/native/sun/font/layout/GlyphPosnLookupProc.cpp ! src/share/native/sun/font/layout/GlyphSubstLookupProc.cpp ! src/share/native/sun/font/layout/IndicLayoutEngine.cpp ! src/share/native/sun/font/layout/IndicReordering.cpp ! src/share/native/sun/font/layout/KernTable.cpp ! src/share/native/sun/font/layout/LEFontInstance.h ! src/share/native/sun/font/layout/LEGlyphFilter.h ! src/share/native/sun/font/layout/LEGlyphStorage.cpp ! src/share/native/sun/font/layout/LEGlyphStorage.h ! src/share/native/sun/font/layout/LEScripts.h ! src/share/native/sun/font/layout/LEStandalone.h ! src/share/native/sun/font/layout/LETableReference.h ! src/share/native/sun/font/layout/LETypes.h ! src/share/native/sun/font/layout/LayoutEngine.cpp ! src/share/native/sun/font/layout/LayoutEngine.h ! src/share/native/sun/font/layout/LigatureSubstProc2.cpp ! src/share/native/sun/font/layout/LigatureSubstSubtables.cpp ! src/share/native/sun/font/layout/LookupProcessor.cpp ! src/share/native/sun/font/layout/Lookups.cpp ! src/share/native/sun/font/layout/MarkArrays.cpp ! src/share/native/sun/font/layout/MarkArrays.h ! src/share/native/sun/font/layout/MarkToBasePosnSubtables.cpp ! src/share/native/sun/font/layout/MarkToLigaturePosnSubtables.cpp ! src/share/native/sun/font/layout/MarkToMarkPosnSubtables.cpp ! src/share/native/sun/font/layout/MultipleSubstSubtables.cpp ! src/share/native/sun/font/layout/OpenTypeLayoutEngine.cpp ! src/share/native/sun/font/layout/OpenTypeUtilities.h ! src/share/native/sun/font/layout/PairPositioningSubtables.cpp ! src/share/native/sun/font/layout/PairPositioningSubtables.h ! src/share/native/sun/font/layout/ScriptAndLanguage.cpp ! src/share/native/sun/font/layout/ScriptAndLanguageTags.cpp ! src/share/native/sun/font/layout/ScriptAndLanguageTags.h ! src/share/native/sun/font/layout/SegmentArrayProcessor2.cpp ! src/share/native/sun/font/layout/SinglePositioningSubtables.cpp ! src/share/native/sun/font/layout/SingleSubstitutionSubtables.cpp ! src/share/native/sun/font/layout/TibetanReordering.h ! src/share/native/sun/font/layout/ValueRecords.cpp ! src/share/native/sun/font/layout/ValueRecords.h Changeset: b8008a2bf4fe Author: sjiang Date: 2013-10-21 09:56 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b8008a2bf4fe 7068126: Enhance SNMP statuses Reviewed-by: dfuchs, hawtin ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibEntry.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibNode.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibOid.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibTable.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpRequestHandler.java Changeset: d7ef65d3ee57 Author: chegar Date: 2013-10-21 15:00 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d7ef65d3ee57 Merge ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CreateJars.gmk - makefiles/GendataBreakIterator.gmk - makefiles/GendataFontConfig.gmk - makefiles/GendataHtml32dtd.gmk - makefiles/GendataTZDB.gmk - makefiles/GendataTimeZone.gmk - makefiles/GenerateJavaSources.gmk + makefiles/GenerateSources.gmk - makefiles/GensrcBuffer.gmk - makefiles/GensrcCLDR.gmk - makefiles/GensrcCharacterData.gmk - makefiles/GensrcCharsetCoder.gmk - makefiles/GensrcCharsetMapping.gmk - makefiles/GensrcExceptions.gmk - makefiles/GensrcIcons.gmk - makefiles/GensrcJDWP.gmk - makefiles/GensrcJObjC.gmk - makefiles/GensrcLocaleDataMetaInfo.gmk - makefiles/GensrcMisc.gmk - makefiles/GensrcProperties.gmk - makefiles/GensrcSwing.gmk - makefiles/GensrcX11Wrappers.gmk ! makefiles/Images.gmk ! makefiles/Profiles.gmk - src/share/classes/com/sun/jdi/connect/package.html - src/share/classes/com/sun/jdi/connect/spi/package.html - src/share/classes/com/sun/jdi/event/package.html - src/share/classes/com/sun/jdi/package.html - src/share/classes/com/sun/jdi/request/package.html - src/share/classes/com/sun/management/package.html - src/share/classes/com/sun/tools/attach/package.html - src/share/classes/com/sun/tools/attach/spi/package.html - src/share/classes/com/sun/tools/jconsole/package.html - src/share/classes/java/lang/invoke/InvokeGeneric.java - src/share/classes/java/lang/invoke/MagicLambdaImpl.java - src/share/classes/java/net/HttpURLPermission.java - src/share/classes/java/time/chrono/ChronoDateImpl.java ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/javax/sql/rowset/spi/SyncFactory.java ! src/share/classes/javax/swing/SwingUtilities.java ! src/share/classes/javax/swing/event/EventListenerList.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/tools/jarsigner/Main.java ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-windows - src/solaris/doc/sun/man/man1/ja/javaws.1 - src/solaris/doc/sun/man/man1/javaws.1 - test/com/oracle/security/ucrypto/TestAES.java - test/com/oracle/security/ucrypto/TestDigest.java - test/com/oracle/security/ucrypto/TestRSA.java - test/com/oracle/security/ucrypto/UcryptoTest.java ! test/java/lang/SecurityManager/CheckPackageAccess.java - test/java/net/HttpURLPermission/HttpURLPermissionTest.java - test/java/net/HttpURLPermission/URLTest.java - test/java/net/HttpURLPermission/policy.1 - test/java/net/HttpURLPermission/policy.2 - test/java/net/HttpURLPermission/policy.3 - test/java/time/tck/java/time/chrono/TCKChronologySerialization.java Changeset: 1c85f50e2622 Author: chegar Date: 2013-10-22 12:33 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1c85f50e2622 Merge ! src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! test/java/lang/SecurityManager/CheckPackageAccess.java Changeset: ad808fe39337 Author: weijun Date: 2013-10-17 09:58 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ad808fe39337 8025014: Enhance Security Policy 6727821: Enhance JAAS Configuration Reviewed-by: xuelei, hawtin ! src/share/classes/javax/security/auth/Policy.java ! src/share/classes/javax/security/auth/login/Configuration.java Changeset: f87d59557049 Author: chegar Date: 2013-10-22 14:55 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f87d59557049 Merge Changeset: d92379723173 Author: asaha Date: 2013-12-07 16:15 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d92379723173 Merge ! make/CompileJavaClasses.gmk ! make/CompileNativeLibraries.gmk ! make/CreateJars.gmk ! make/CreateSecurityJars.gmk ! make/GenerateSources.gmk ! make/Images.gmk ! make/Profiles.gmk ! make/lib/Awt2dLibraries.gmk ! make/lib/CoreLibraries.gmk ! make/lib/NetworkingLibraries.gmk ! make/lib/NioLibraries.gmk ! make/lib/PlatformLibraries.gmk ! make/lib/SecurityLibraries.gmk ! make/lib/ServiceabilityLibraries.gmk ! make/lib/SoundLibraries.gmk ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibTable.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpRequestHandler.java ! src/share/classes/javax/sql/rowset/spi/SyncFactory.java ! src/share/classes/javax/swing/SwingUtilities.java ! src/share/classes/sun/reflect/misc/ReflectUtil.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/tools/jarsigner/Main.java ! test/sun/security/tools/jarsigner/TimestampCheck.java ! test/sun/security/tools/jarsigner/ts.sh Changeset: ef2352bf3dfe Author: xuelei Date: 2013-10-23 21:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ef2352bf3dfe 8026417: Enhance XML canonicalization Summary: Copy before use mutable byte arrays. Also reviewed by Alexander Fomin Reviewed-by: mullan, hawtin, ahgross ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/CanonicalizerBase.java Changeset: fe1707a836b4 Author: xuelei Date: 2013-10-24 10:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fe1707a836b4 8027204: Revise the update of 8026204 and 8025758 Summary: Rivise the update to use system class loader with null TCCL. Also reviewed by Alexander Fomin Reviewed-by: mchung, ahgross ! src/share/classes/com/sun/naming/internal/FactoryEnumeration.java ! src/share/classes/com/sun/naming/internal/VersionHelper12.java ! src/share/classes/javax/security/auth/login/LoginContext.java Changeset: a147b2084bc3 Author: michaelm Date: 2013-10-24 20:39 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a147b2084bc3 8011786: Better applet networking Reviewed-by: alanb, chegar ! src/share/classes/com/sun/nio/sctp/SctpChannel.java ! src/share/classes/java/lang/SecurityManager.java ! src/share/classes/java/net/Socket.java ! src/share/classes/java/net/SocketPermission.java ! src/share/classes/java/nio/channels/AsynchronousSocketChannel.java ! src/share/classes/java/nio/channels/SocketChannel.java ! src/share/classes/sun/nio/ch/AsynchronousSocketChannelImpl.java ! src/share/classes/sun/nio/ch/SocketChannelImpl.java ! src/share/classes/sun/rmi/registry/RegistryImpl.java ! src/share/classes/sun/security/util/SecurityConstants.java ! src/share/lib/security/java.policy ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! src/solaris/classes/sun/nio/ch/sctp/SctpChannelImpl.java Changeset: a0b6e5895464 Author: michaelm Date: 2013-11-20 23:33 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a0b6e5895464 8028453: AsynchronousSocketChannel.connect() requires SocketPermission due to bind to local address (win) Reviewed-by: alanb, chegar ! src/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java Changeset: d5107c804de5 Author: michaelm Date: 2013-11-26 10:06 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d5107c804de5 8028293: Check local configuration for actual ephemeral port range Reviewed-by: alanb, chegar, smarks ! make/lib/NetworkingLibraries.gmk ! make/mapfiles/libnet/mapfile-vers ! src/share/classes/java/net/SocketPermission.java ! src/share/classes/sun/rmi/registry/RegistryImpl.java ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows + src/solaris/classes/sun/net/PortConfig.java ! src/solaris/native/java/net/net_util_md.c ! src/solaris/native/java/net/net_util_md.h + src/solaris/native/sun/net/portconfig.c + src/windows/classes/sun/net/PortConfig.java + src/windows/native/sun/net/portconfig.c ! test/java/rmi/activation/rmidViaInheritedChannel/RmidViaInheritedChannel.java ! test/java/rmi/registry/readTest/readTest.sh ! test/java/rmi/testlibrary/TestLibrary.java Changeset: ac1c8e892877 Author: kizune Date: 2013-12-13 22:13 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ac1c8e892877 Merge ! make/CreateSecurityJars.gmk - make/data/cryptopolicy/limited/LIMITED - make/data/cryptopolicy/unlimited/UNLIMITED ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/javax/security/auth/login/LoginContext.java - test/com/sun/jmx/snmp/NoInfoLeakTest.java - test/com/sun/tools/attach/AgentSetup.sh - test/com/sun/tools/attach/ApplicationSetup.sh - test/com/sun/tools/attach/BasicTests.sh - test/com/sun/tools/attach/CommonSetup.sh - test/com/sun/tools/attach/PermissionTests.sh - test/com/sun/tools/attach/ProviderTests.sh - test/java/lang/management/MemoryMXBean/CollectionUsageThresholdConcMarkSweepGC.sh - test/java/lang/management/MemoryMXBean/CollectionUsageThresholdParallelGC.sh - test/java/lang/management/MemoryMXBean/CollectionUsageThresholdSerialGC.sh - test/java/rmi/reliability/benchmark/runRmiBench.sh - test/java/rmi/reliability/benchmark/runSerialBench.sh Changeset: db6e25fee0f7 Author: asaha Date: 2014-01-08 12:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/db6e25fee0f7 Merge ! make/CompileJavaClasses.gmk ! make/mapfiles/libnet/mapfile-vers ! src/macosx/native/sun/awt/splashscreen/splashscreen_sys.m ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibOid.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibTable.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpRequestHandler.java ! src/share/classes/com/sun/nio/sctp/SctpChannel.java ! src/share/classes/java/lang/SecurityManager.java ! src/share/classes/java/nio/channels/AsynchronousSocketChannel.java ! src/share/classes/java/nio/channels/SocketChannel.java ! src/share/classes/java/util/jar/JarVerifier.java ! src/share/classes/javax/swing/SwingUtilities.java ! src/share/classes/javax/swing/event/EventListenerList.java ! src/share/classes/sun/nio/ch/AsynchronousSocketChannelImpl.java ! src/share/classes/sun/nio/ch/SocketChannelImpl.java ! src/share/classes/sun/security/tools/jarsigner/Main.java ! src/share/classes/sun/security/tools/jarsigner/Resources.java ! src/share/classes/sun/security/util/SecurityConstants.java - src/share/classes/sun/util/resources/pt/LocaleNames_pt_BR.properties ! src/solaris/classes/sun/nio/ch/sctp/SctpChannelImpl.java ! src/solaris/native/java/net/net_util_md.c ! src/solaris/native/sun/awt/splashscreen/splashscreen_sys.c ! src/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java ! test/java/rmi/registry/readTest/readTest.sh - test/javax/swing/text/AbstractDocument/7146146/bug7146146.java - test/sun/security/ssl/javax/net/ssl/SSLContextVersion.java ! test/sun/security/tools/jarsigner/TimestampCheck.java ! test/sun/security/tools/jarsigner/concise_jarsigner.sh ! test/sun/security/tools/jarsigner/ts.sh Changeset: f251cb144366 Author: erikj Date: 2014-01-08 13:25 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f251cb144366 8029254: Build error when javadoc generates beaninfo for javax.swing.beans Reviewed-by: alanb, ihse, michaelm ! make/gensrc/GensrcSwing.gmk Changeset: 13b28cffa140 Author: katleman Date: 2014-01-10 08:32 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/13b28cffa140 Added tag jdk8-b123 for changeset 484e16c0a040 ! .hgtags Changeset: e4c9787cae89 Author: asaha Date: 2014-01-10 09:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e4c9787cae89 Merge Changeset: a110ff64efa0 Author: kizune Date: 2014-01-14 23:10 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a110ff64efa0 Merge ! make/Images.gmk - src/bsd/doc/man/ja/kinit.1 - src/bsd/doc/man/ja/klist.1 - src/bsd/doc/man/ja/ktab.1 ! src/share/classes/java/util/logging/LogManager.java From brian.burkhalter at oracle.com Tue Jan 14 19:56:11 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 14 Jan 2014 11:56:11 -0800 Subject: JDK 9 RFR of 8030814: Long.parseUnsignedLong should throw exception on too large input In-Reply-To: References: <20C5A625-0581-4B4A-A51F-73FE6D87388A@oracle.com> <379DEFA2-47CE-4426-AECA-8C3C4E7F287B@oracle.com> Message-ID: <86B817C2-95FD-483A-BA98-CA45B31407E4@oracle.com> Please see the updated webrev http://cr.openjdk.java.net/~bpb/8030814/webrev.3/. Hopefully my verbose description of the very clever overflow test is accurate and understandable. Also, I cleaned up the JTREG test a bit and added some tests based on the boundary values which split the range of the quantity "guard." Thanks, Brian From alexander.zuev at oracle.com Tue Jan 14 19:58:03 2014 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Tue, 14 Jan 2014 19:58:03 +0000 Subject: hg: jdk8/tl/nashorn: 10 new changesets Message-ID: <20140114195813.D4DC562437@hg.openjdk.java.net> Changeset: b9fdc55a6e28 Author: chegar Date: 2013-11-03 07:33 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/b9fdc55a6e28 Merge Changeset: c1049f63d4f5 Author: kizune Date: 2013-12-03 14:13 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/c1049f63d4f5 Merge Changeset: 39a3e5a4d6d4 Author: kizune Date: 2013-12-05 16:37 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/39a3e5a4d6d4 Merge - makefiles/BuildNashorn.gmk - makefiles/Makefile Changeset: dd59e60accdd Author: kizune Date: 2013-12-13 22:13 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/dd59e60accdd Merge Changeset: 89f838ccd186 Author: asaha Date: 2013-12-20 07:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/89f838ccd186 Merge Changeset: a9d41a8055ca Author: asaha Date: 2014-01-02 15:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/a9d41a8055ca Merge Changeset: 688f4167f921 Author: katleman Date: 2014-01-03 11:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/688f4167f921 Added tag jdk8-b122 for changeset 9d112a0e7df7 ! .hgtags Changeset: 98e7379a4345 Author: asaha Date: 2014-01-03 16:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/98e7379a4345 Merge Changeset: 0b4301c79225 Author: katleman Date: 2014-01-10 08:32 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/0b4301c79225 Added tag jdk8-b123 for changeset 688f4167f921 ! .hgtags Changeset: 2334772d5292 Author: asaha Date: 2014-01-10 17:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/2334772d5292 Merge From alexander.zuev at oracle.com Tue Jan 14 19:57:23 2014 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Tue, 14 Jan 2014 19:57:23 +0000 Subject: hg: jdk8/tl/langtools: 9 new changesets Message-ID: <20140114195751.0CCF762435@hg.openjdk.java.net> Changeset: 53dd31d3c5d7 Author: chegar Date: 2013-11-03 07:33 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/53dd31d3c5d7 Merge Changeset: aaea3a69fa6c Author: kizune Date: 2013-12-03 14:13 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/aaea3a69fa6c Merge - test/tools/javac/ArraysInIntersections.java - test/tools/javac/ExtDirs/ext1/pkg1.jar - test/tools/javac/ExtDirs/ext2/pkg2.jar - test/tools/javac/ExtDirs/ext3/pkg1.jar - test/tools/javac/ExtDirs/ext3/pkg2.jar - test/tools/javac/InferArraysInIntersections.java - test/tools/javac/diags/examples/InterfaceOrArrayExpected.java Changeset: 48367e6de872 Author: kizune Date: 2013-12-05 16:37 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/48367e6de872 Merge - make/jprt.properties - makefiles/BuildLangtools.gmk - makefiles/Makefile Changeset: f06c0dcf251f Author: kizune Date: 2013-12-13 22:13 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f06c0dcf251f Merge Changeset: b07b8c077482 Author: asaha Date: 2013-12-20 07:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b07b8c077482 Merge Changeset: efc18829e3a6 Author: asaha Date: 2014-01-02 15:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/efc18829e3a6 Merge - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/activetitlebar.gif - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/activetitlebar_end.gif - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/background.gif - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/tab.gif - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/titlebar.gif - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/titlebar_end.gif Changeset: a345cf28faca Author: katleman Date: 2014-01-03 11:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a345cf28faca Added tag jdk8-b122 for changeset 232b9cf6303a ! .hgtags Changeset: 8712cc6441db Author: asaha Date: 2014-01-03 16:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8712cc6441db Merge Changeset: 1f135528db7c Author: kizune Date: 2014-01-14 23:10 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1f135528db7c Merge From kumar.x.srinivasan at oracle.com Tue Jan 14 22:10:07 2014 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 14 Jan 2014 14:10:07 -0800 Subject: JDK9 RFR of JDK-8029646: [pack200] should support the new zip64 format. In-Reply-To: <52D57C2A.4010906@oracle.com> References: <52D57C2A.4010906@oracle.com> Message-ID: <52D5B5BF.2010104@oracle.com> Hi Alex, zip.cpp: (nit) I would keep the hex values to be in upper case just like the others for consistency, not a big deal. typo: + // Zip64 END sugnature PackTestZip64.java: shouldn't we test a jar with 64K+ entries ? Kumar On 1/14/2014 10:04 AM, Alexander Zuev wrote: > Please review my fix for > JDK-8029646: [pack200] should support the new zip64 format. > > The fix can be found at > http://cr.openjdk.java.net/~kizune/8029646/webrev.00/ > > Bug description is: https://bugs.openjdk.java.net/browse/JDK-8029646 > > /Alex From martinrb at google.com Tue Jan 14 22:20:27 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 14 Jan 2014 14:20:27 -0800 Subject: RFR: (8030875) Macros for checking and returning on exceptions In-Reply-To: <52D55DBD.3030502@oracle.com> References: <52D013B9.40101@oracle.com> <52D4A642.7090404@oracle.com> <52D55DBD.3030502@oracle.com> Message-ID: On Tue, Jan 14, 2014 at 7:54 AM, roger riggs wrote: > Hi David, > > The CHECK_RETURN macros have existed in java.net for some time and > I have not seen any empty statement warnings. > > The CHECK_EXCEPTION macros are new and does not have any uses yet. > I don't plan to do any wholesale modification of current sources. > > The macros always produce a valid statement; (though my c/c++ may be a > bit rusty). > > Macros should not generally be complete statements, including semicolons; then the source code looks like this: FOO() which looks (including to emacs) like someone forgot the trailing semicolon. Instead, these macros should be written using the "well-known" do ( ... ) while (0) idiom, e.g. #define CHECK_NULL(x) do { if ((x) == NULL) return; } while (0) > (Note that it has been requested to rename the macros to include a > JNU_prefix > to be consistent with other macros in jni_util.h. I will propose a > separate set of changes for that). > > Roger > > > On 1/13/2014 9:51 PM, David Holmes wrote: > >> Hi Roger, >> >> >> webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-check-exception-8030875/ >>> >> >> Do these macro definitions not cause "empty statement" warnings from the >> compiler? (Existing ones have the same problem I guess) >> >> Also I don't see any use of the CHECK_EXCEPTION macros? In fact the bulk >> of changes here seem completely unrelated to the "exception" aspect of this >> CR. >> >> Cheers, >> David >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8030875 >>> >> > From joe.darcy at oracle.com Wed Jan 15 03:31:25 2014 From: joe.darcy at oracle.com (Joseph Darcy) Date: Tue, 14 Jan 2014 19:31:25 -0800 Subject: JDK 9 RFR of 8030814: Long.parseUnsignedLong should throw exception on too large input In-Reply-To: <86B817C2-95FD-483A-BA98-CA45B31407E4@oracle.com> References: <20C5A625-0581-4B4A-A51F-73FE6D87388A@oracle.com> <379DEFA2-47CE-4426-AECA-8C3C4E7F287B@oracle.com> <86B817C2-95FD-483A-BA98-CA45B31407E4@oracle.com> Message-ID: <52D6010D.2060700@oracle.com> Hi Brian, Lots good other than a few quibbles: We usually use /* * */ for long multi-line comments rather than // // // In the test update, we don't usually include mention of the bug id other than the @bug line. Thanks, -Joe On 1/14/2014 11:56 AM, Brian Burkhalter wrote: > Please see the updated webrev http://cr.openjdk.java.net/~bpb/8030814/webrev.3/. > > Hopefully my verbose description of the very clever overflow test is accurate and understandable. Also, I cleaned up the JTREG test a bit and added some tests based on the boundary values which split the range of the quantity "guard." > > Thanks, > > Brian From xueming.shen at oracle.com Wed Jan 15 04:58:49 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 14 Jan 2014 20:58:49 -0800 Subject: JDK9 RFR of JDK-8029646: [pack200] should support the new zip64 format. In-Reply-To: <52D57C2A.4010906@oracle.com> References: <52D57C2A.4010906@oracle.com> Message-ID: <52D61589.1090901@oracle.com> Hi Alex, (1) what's the bits are you setting into the general flags fields as below? header[4] = ( store ) ? SWAP_BYTES(0x0800) : 0x0808; (2) why do you want to use extra data descriptor to set crc/size/csize? while I understand that Jar/ZipOutputStream does that, but that is because they don't have the choice given the nature of "stream", which means they don't know the csize and crc value until all bits get compressed/crc-ed. In case of unpack, all bits should have already be compressed and the crc value has been calculated, I don't see any compelling reason we need to sue the extra data descriptor here. (3) to add the "cafe" jar magic is interesting. that is really an old implementation details of "jar on solaris". any request to add this one into the unpack tool? (4) I dont think the changeset is tryin to support ZIP64 extra fields tag in LOC and CEN tables (I kinda understand why, given the unpack does all "unpacking" work in memory, it is practically unrealistic to have a >4G memory to hold all > 4G data). It appears most of the changes other than the zip64 end table is really not related to "support the new zip64 format" (5) flag "jdk.util.zip.inhibitZip64" is introduced in jdk8 to support a "old" behavior for > 64K total entries. You guys might want to consider if it is also worth considering to have this flag supported in unpack200. -Sherman On 1/14/14 10:04 AM, Alexander Zuev wrote: > Please review my fix for > JDK-8029646: [pack200] should support the new zip64 format. > > The fix can be found at > http://cr.openjdk.java.net/~kizune/8029646/webrev.00/ > > Bug description is: https://bugs.openjdk.java.net/browse/JDK-8029646 > > /Alex From david.holmes at oracle.com Wed Jan 15 06:24:32 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 Jan 2014 16:24:32 +1000 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <52D51FAC.8060800@oracle.com> Message-ID: <52D629A0.4080806@oracle.com> On 15/01/2014 12:10 AM, Volker Simonis wrote: > On Tue, Jan 14, 2014 at 12:29 PM, David Holmes > wrote: > > Just a note on this part (I havent looked at the code): > > > On AIX, the constants used for the polling events (i.e. POLLIN, > POLLOUT, ...) are defined to different values than on other > operating systems. The problem is however, that these constants > are hardcoded as public final static members of various, shared > Java classes. > > > Sounds like this should be handled the same way that the other > "system constants" are handled - you can either store a platform > file in the repo (for cross-compiling) or you generate the class > containing the constants at build time. > > > Hi David, > > thanks for your comments. That sound like a good idea but I'm not sure > if it would make sense to duplicate the following files: > > src/share/classes/sun/nio/ch/AbstractPollArrayWrapper.java: > src/solaris/classes/sun/nio/ch/Port.java > > because of this. Do you have a concrete example where Java-classes are > being generated with different constants in the class library build? There are two files generated: UnixConstants.java (or SolarisConstants.java) for general I/O type values SocketOptionRegistry.java for socket options. See jdk/make/gensrc/GensrcMisc.gmk. > Both solutions would result in different class files on Aix and other > Unix variants. What do you think about assigning the concrete values > depending on 'os.name ' in the static initializers of > the corresponding classes? I think that shouldn't introduce too much > overhead and I could get rid of all the ugly conversion code. I'm not a fan of runtime checks of this kind though if it is only a very samll number of values it might be okay. Another option would be to make those classes into "templates" as done with Version.java.template and substitute the right values at build time. But I'll let Alan and net-dev folk come back with their preferred technique for this. Cheers, David > > Regards, > Volker > > David > > > On 14/01/2014 6:40 PM, Volker Simonis wrote: > > Hi, > > could you please review the following changes for the ppc-aix-port > stage/stage-9 repositories (the changes are planned for > integration into > ppc-aix-port/stage-9 and subsequent backporting to > ppc-aix-port/stage): > > http://cr.openjdk.java.net/~__simonis/webrevs/8031581/ > > > I've build and smoke tested without any problems on Linux/x86_64 and > PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64. > > With these changes (and together with the changes from "8028537: > PPC64: > Updated jdk/test scripts to understand the AIX os and > environment" and > "8031134 : PPC64: implement printing on AIX") our port passes > all but > the following 7 jtreg regression tests on AIX (compared to the > Linux/x86_64 baseline from > www.java.net/download/jdk8/__testresults/testresults.html > > >?): > > > java/net/Inet6Address/__B6558853.java > java/nio/channels/__AsynchronousChannelGroup/__Basic.java > (sporadically) > java/nio/channels/__AsynchronousChannelGroup/__GroupOfOne.java > java/nio/channels/__AsynchronousChannelGroup/__Unbounded.java > (sporadically) > java/nio/channels/Selector/__RacyDeregister.java > sun/security/krb5/auto/__Unreachable.java (only on IPv6) > > Thank you and best regards, > Volker > > > Following a detailed description of the various changes: > > > src/share/native/java/util/__zip/zip_util.c > src/share/native/sun/__management/__DiagnosticCommandImpl.c > > * According to ISO C it is perfectly legal for malloc to > return zero > > if called with a zero argument. Fix various places where > malloc can > potentially correctly return zero because it was called > with a zero > argument. > * Also fixed |DiagnosticCommandImpl.c| to include |stdlib.h|. > This > > only fixes a compiler warning on Linux, but on AIX it > prevents a VM > crash later on because the return value of |malloc()| will > be casted > to |int| which is especially bad if that pointer was bigger > than > 32-bit. > > > make/CompileJavaClasses.gmk > > * Also use |PollingWatchService| on AIX. > > > make/lib/NioLibraries.gmk > src/aix/native/sun/nio/ch/__AixNativeThread.c > > * Put the implementation for the native methods of > |NativeThread| into > > |AixNativeThread.c| on AIX. > > > src/solaris/native/sun/nio/ch/__PollArrayWrapper.c > src/solaris/native/sun/nio/ch/__Net.c > src/aix/classes/sun/nio/ch/__AixPollPort.java > src/aix/native/sun/nio/ch/__AixPollPort.c > src/aix/native/java/net/aix___close.c > > * On AIX, the constants used for the polling events (i.e. > |POLLIN|, > |POLLOUT|, ...) are defined to different values than on other > > operating systems. The problem is however, that these > constants are > hardcoded as public final static members of various, shared > Java > classes. We therefore have to map them from Java to native > every > time before calling one of the native poll functions and > back to > Java after the call on AIX in order to get the right semantics. > > > src/share/classes/java/nio/__file/CopyMoveHelper.java > > * As discussed on the core-libs mailing list (see > > http://mail.openjdk.java.net/__pipermail/core-libs-dev/2013-__December/024119.html > ) > it is not necessary to call |Files.getFileAttributeView()| > with any > |linkOptions| because at that place we've already checked > that the > target file can not be a symbolic link. This change makes the > implementation more robust on platforms which support > symbolic links > but do not support the |O_NOFOLLOW| flag to the |open| > system call. > It also makes the JDK pass the |demo/zipfs/basic.sh| test > on AIX. > > > src/share/classes/sun/nio/cs/__ext/ExtendedCharsets.java > > * Support "compound text" on AIX in the same way like on > other Unix > platforms. > > > > src/share/classes/sun/tools/__attach/META-INF/services/com.__sun.tools.attach.spi.__AttachProvider > > * Define the correct attach provider for AIX. > > > src/solaris/native/java/net/__net_util_md.h > src/solaris/native/sun/nio/ch/__FileDispatcherImpl.c > src/solaris/native/sun/nio/ch/__ServerSocketChannelImpl.c > > * AIX needs a workaround for I/O cancellation (see: > > http://publib.boulder.ibm.com/__infocenter/pseries/v5r3/index.__jsp?topic=/com.ibm.aix.__basetechref/doc/basetrf1/__close.htm > ). > "..The |close()| subroutine is blocked until all > subroutines which > use the file descriptor return to usr space. For example, > when a > thread is calling close and another thread is calling > select with > the same file descriptor, the close subroutine does not > return until > the select call returns...". To fix this problem, we have > to use the > various |NET_| wrappers which are declared in > |net_util_md.h| and > defined in |aix_close.c| and we also need some additional > wrappers > for |fcntl()|, |read()| and |write()| on AIX. > > While the current solution isn't really nice because it > introduces > some more AIX-specifc sections in shared code, I think it > is the > best way to go for JDK 8 because it imposes the smallest > possible > changes and risks for the existing platforms. I'm ready to > change > the code to unconditionally use the wrappers for all > platforms and > implement the wrappers empty on platforms which don't need any > wrapping. I think it would also be nice to clean up the > names (e.g. > |NET_Read()| is currently a wrapper for |recv()| and the |NET_| > prefix is probably not appropriate any more so maybe change > it to > something like |IO_|). But again, I'll prefer to keep that as a > > follow up change for JDK9. > * Calling |fsync()| on a "read-only" file descriptor on AIX will > > result in an error (i.e. "EBADF: The FileDescriptor > parameter is not > a valid file descriptor open for writing."). To prevent > this error > we have to query if the corresponding file descriptor is > writeable. > Notice that at that point we can not access the |writable| > attribute > of the corresponding file channel so we have to use |fcntl()|. > > > src/solaris/classes/java/lang/__UNIXProcess.java.aix > > * On AIX the implementation is especially tricky, because the > > |close()| system call will block if another thread is at > the same > time blocked in a file operation (e.g. 'read()') on the > same file > descriptor. We therefore combine the AIX > |ProcessPipeInputStream| > implemenatation with the |DeferredCloseInputStream| > approach used on > Solaris (see |UNIXProcess.java.solaris|). This means that every > > potentially blocking operation on the file descriptor > increments a > counter before it is executed and decrements it once it > finishes. > The 'close()' operation will only be executed if there are no > pending operations. Otherwise it is deferred after the last > pending > operation has finished. > > > src/share/transport/socket/__socketTransport.c > > * On AIX we have to call |shutdown()| on a socket descriptor > before > > closing it, otherwise the |close()| call may be blocked. > This is the > same problem as described before. Unfortunately the JDI > framework > doesn't use the same IO wrappers like other class library > components > so we can not easily use the |NET_| abstractions from > |aix_close.c| > here. > * Without this small change all JDI regression tests will > fail on AIX > > because of the way how the tests act as a "debugger" which > launches > another VM (the "debugge") which connects itself back to the > debugger. In this scenario the "debugge" can not shut down > itself > because one thread will always be blocked in the |close()| > call on > one of the communication sockets. > > > src/solaris/native/java/net/__NetworkInterface.c > > * Set the scope identifier for IPv6 addresses on AIX. > > > src/solaris/native/java/net/__net_util_md.c > > * It turns out that we do not always have to replace > |SO_REUSEADDR| on > AIX by |SO_REUSEPORT|. Instead we can simply use the same > approach > > like BSD and only use |SO_REUSEPORT| additionally, if several > datagram sockets try to bind to the same port. > * Also fixed a comment and removed unused local variables. > * Fixed the obviously inverted assignment |newTime = > prevTime;| which > > should read |prevTime = newTime;|. Otherwise |prevTime| > will never > change and the timeout will be potential reached too fast. > > > src/solaris/native/sun/__management/__OperatingSystemImpl.c > > * AIX does not understand |/proc/self| so we have to query > the real > > process ID to access the proc file system. > > > src/solaris/native/sun/nio/ch/__DatagramChannelImpl.c > > * On AIX, |connect()| may legally return |EAFNOSUPPORT| if > called on a > > socket with the address family set to |AF_UNSPEC|. > > > From staffan.larsen at oracle.com Wed Jan 15 08:57:31 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 15 Jan 2014 09:57:31 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: Message-ID: <94ABE61E-10BC-407E-92D0-B528165F3460@oracle.com> Volker, I?ve look at the following files: src/share/native/sun/management/DiagnosticCommandImpl.c: nit: ?legel? -> ?legal? (two times) In Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo() if you allow dcmd_info_array to become NULL, then jmm_interface->GetDiagnosticCommandInfo() will throw an NPE and you need to check that. src/solaris/native/sun/management/OperatingSystemImpl.c No comments. src/share/transport/socket/socketTransport.c No comments. src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider No comments. Thanks, /Staffan On 14 jan 2014, at 09:40, Volker Simonis wrote: > Hi, > > could you please review the following changes for the ppc-aix-port stage/stage-9 repositories (the changes are planned for integration into ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): > > http://cr.openjdk.java.net/~simonis/webrevs/8031581/ > > I've build and smoke tested without any problems on Linux/x86_64 and PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64. > > With these changes (and together with the changes from "8028537: PPC64: Updated jdk/test scripts to understand the AIX os and environment" and "8031134 : PPC64: implement printing on AIX") our port passes all but the following 7 jtreg regression tests on AIX (compared to the Linux/x86_64 baseline from www.java.net/download/jdk8/testresults/testresults.html?): > > java/net/Inet6Address/B6558853.java > java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically) > java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java > java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically) > java/nio/channels/Selector/RacyDeregister.java > sun/security/krb5/auto/Unreachable.java (only on IPv6) > > Thank you and best regards, > Volker > > > Following a detailed description of the various changes: > src/share/native/java/util/zip/zip_util.c > src/share/native/sun/management/DiagnosticCommandImpl.c > > According to ISO C it is perfectly legal for malloc to return zero if called with a zero argument. Fix various places where malloc can potentially correctly return zero because it was called with a zero argument. > Also fixed DiagnosticCommandImpl.c to include stdlib.h. This only fixes a compiler warning on Linux, but on AIX it prevents a VM crash later on because the return value of malloc() will be casted to int which is especially bad if that pointer was bigger than 32-bit. > make/CompileJavaClasses.gmk > > Also use PollingWatchService on AIX. > make/lib/NioLibraries.gmk > src/aix/native/sun/nio/ch/AixNativeThread.c > > Put the implementation for the native methods of NativeThread into AixNativeThread.c on AIX. > src/solaris/native/sun/nio/ch/PollArrayWrapper.c > src/solaris/native/sun/nio/ch/Net.c > src/aix/classes/sun/nio/ch/AixPollPort.java > src/aix/native/sun/nio/ch/AixPollPort.c > src/aix/native/java/net/aix_close.c > > On AIX, the constants used for the polling events (i.e. POLLIN, POLLOUT, ...) are defined to different values than on other operating systems. The problem is however, that these constants are hardcoded as public final static members of various, shared Java classes. We therefore have to map them from Java to native every time before calling one of the native poll functions and back to Java after the call on AIX in order to get the right semantics. > src/share/classes/java/nio/file/CopyMoveHelper.java > > As discussed on the core-libs mailing list (see http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024119.html) it is not necessary to call Files.getFileAttributeView() with any linkOptions because at that place we've already checked that the target file can not be a symbolic link. This change makes the implementation more robust on platforms which support symbolic links but do not support the O_NOFOLLOW flag to the open system call. It also makes the JDK pass the demo/zipfs/basic.sh test on AIX. > src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java > > Support "compound text" on AIX in the same way like on other Unix platforms. > src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider > > Define the correct attach provider for AIX. > src/solaris/native/java/net/net_util_md.h > src/solaris/native/sun/nio/ch/FileDispatcherImpl.c > src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c > > AIX needs a workaround for I/O cancellation (see: http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/close.htm). "..The close() subroutine is blocked until all subroutines which use the file descriptor return to usr space. For example, when a thread is calling close and another thread is calling select with the same file descriptor, the close subroutine does not return until the select call returns...". To fix this problem, we have to use the various NET_ wrappers which are declared in net_util_md.h and defined in aix_close.c and we also need some additional wrappers for fcntl(), read() and write() on AIX. > While the current solution isn't really nice because it introduces some more AIX-specifc sections in shared code, I think it is the best way to go for JDK 8 because it imposes the smallest possible changes and risks for the existing platforms. I'm ready to change the code to unconditionally use the wrappers for all platforms and implement the wrappers empty on platforms which don't need any wrapping. I think it would also be nice to clean up the names (e.g. NET_Read() is currently a wrapper for recv() and the NET_ prefix is probably not appropriate any more so maybe change it to something like IO_). But again, I'll prefer to keep that as a follow up change for JDK9. > Calling fsync() on a "read-only" file descriptor on AIX will result in an error (i.e. "EBADF: The FileDescriptor parameter is not a valid file descriptor open for writing."). To prevent this error we have to query if the corresponding file descriptor is writeable. Notice that at that point we can not access the writable attribute of the corresponding file channel so we have to use fcntl(). > src/solaris/classes/java/lang/UNIXProcess.java.aix > > On AIX the implementation is especially tricky, because the close() system call will block if another thread is at the same time blocked in a file operation (e.g. 'read()') on the same file descriptor. We therefore combine the AIX ProcessPipeInputStream implemenatation with the DeferredCloseInputStream approach used on Solaris (see UNIXProcess.java.solaris). This means that every potentially blocking operation on the file descriptor increments a counter before it is executed and decrements it once it finishes. The 'close()' operation will only be executed if there are no pending operations. Otherwise it is deferred after the last pending operation has finished. > src/share/transport/socket/socketTransport.c > > On AIX we have to call shutdown() on a socket descriptor before closing it, otherwise the close() call may be blocked. This is the same problem as described before. Unfortunately the JDI framework doesn't use the same IO wrappers like other class library components so we can not easily use the NET_ abstractions from aix_close.c here. > Without this small change all JDI regression tests will fail on AIX because of the way how the tests act as a "debugger" which launches another VM (the "debugge") which connects itself back to the debugger. In this scenario the "debugge" can not shut down itself because one thread will always be blocked in the close() call on one of the communication sockets. > src/solaris/native/java/net/NetworkInterface.c > > Set the scope identifier for IPv6 addresses on AIX. > src/solaris/native/java/net/net_util_md.c > > It turns out that we do not always have to replace SO_REUSEADDR on AIX by SO_REUSEPORT. Instead we can simply use the same approach like BSD and only use SO_REUSEPORT additionally, if several datagram sockets try to bind to the same port. > Also fixed a comment and removed unused local variables. > Fixed the obviously inverted assignment newTime = prevTime; which should read prevTime = newTime;. Otherwise prevTime will never change and the timeout will be potential reached too fast. > src/solaris/native/sun/management/OperatingSystemImpl.c > > AIX does not understand /proc/self so we have to query the real process ID to access the proc file system. > src/solaris/native/sun/nio/ch/DatagramChannelImpl.c > > On AIX, connect() may legally return EAFNOSUPPORT if called on a socket with the address family set to AF_UNSPEC. > From Alan.Bateman at oracle.com Wed Jan 15 09:03:17 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 15 Jan 2014 09:03:17 +0000 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: <52D629A0.4080806@oracle.com> References: <52D51FAC.8060800@oracle.com> <52D629A0.4080806@oracle.com> Message-ID: <52D64ED5.4020409@oracle.com> On 15/01/2014 06:24, David Holmes wrote: > > I'm not a fan of runtime checks of this kind though if it is only a > very samll number of values it might be okay. > > Another option would be to make those classes into "templates" as done > with Version.java.template and substitute the right values at build time. > > But I'll let Alan and net-dev folk come back with their preferred > technique for this. > I plan to spend time on Volker's webrev later in the week (just too busy with other things right now). For the translation issue then it's an oversight in the original implementation, it just hasn't come up before (to my knowledge anyway). The simplest solution here maybe to to just move them to sun.net.ch.Net and have them initialized to their native value. In general then I'm not too concerned about that one, it's the changes to support async close on AIX that are leaping out at me. -Alan From paul.sandoz at oracle.com Wed Jan 15 10:56:40 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 15 Jan 2014 11:56:40 +0100 Subject: JDK 9 RFR of 8030814: Long.parseUnsignedLong should throw exception on too large input In-Reply-To: <86B817C2-95FD-483A-BA98-CA45B31407E4@oracle.com> References: <20C5A625-0581-4B4A-A51F-73FE6D87388A@oracle.com> <379DEFA2-47CE-4426-AECA-8C3C4E7F287B@oracle.com> <86B817C2-95FD-483A-BA98-CA45B31407E4@oracle.com> Message-ID: On Jan 14, 2014, at 8:56 PM, Brian Burkhalter wrote: > Please see the updated webrev http://cr.openjdk.java.net/~bpb/8030814/webrev.3/. > > Hopefully my verbose description of the very clever overflow test is accurate and understandable. Also, I cleaned up the JTREG test a bit and added some tests based on the boundary values which split the range of the quantity "guard." > +1 a high comment to code ratio :-) I agree with Joe's comments. Paul. From volker.simonis at gmail.com Wed Jan 15 11:05:14 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 15 Jan 2014 12:05:14 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: <52D64ED5.4020409@oracle.com> References: <52D51FAC.8060800@oracle.com> <52D629A0.4080806@oracle.com> <52D64ED5.4020409@oracle.com> Message-ID: On Wed, Jan 15, 2014 at 10:03 AM, Alan Bateman wrote: > On 15/01/2014 06:24, David Holmes wrote: > >> >> I'm not a fan of runtime checks of this kind though if it is only a very >> samll number of values it might be okay. >> >> Another option would be to make those classes into "templates" as done >> with Version.java.template and substitute the right values at build time. >> >> But I'll let Alan and net-dev folk come back with their preferred >> technique for this. >> >> I plan to spend time on Volker's webrev later in the week (just too busy > with other things right now). For the translation issue then it's an > oversight in the original implementation, it just hasn't come up before (to > my knowledge anyway). The simplest solution here maybe to to just move them > to sun.net.ch.Net and have them initialized to their native value. Do you mean sun.nio.ch.Net right? Do you propose to completely remove the definitions of the POLL constants from: src/share/classes/sun/nio/ch/AbstractPollArrayWrapper.java src/solaris/classes/sun/nio/ch/Port.java and replace all their usages by Net.POLL* ? > In general then I'm not too concerned about that one, it's the changes to > support async close on AIX that are leaping out at me. > > -Alan > From alexander.zuev at oracle.com Wed Jan 15 14:26:34 2014 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Wed, 15 Jan 2014 18:26:34 +0400 Subject: JDK9 RFR of JDK-8029646: [pack200] should support the new zip64 format. In-Reply-To: <52D61589.1090901@oracle.com> References: <52D57C2A.4010906@oracle.com> <52D61589.1090901@oracle.com> Message-ID: <52D69A9A.1010506@oracle.com> Hi Sherman, Thanks for comments, here are some answers: the answer to (1)-(3) is that i do whatever the JarOutputStream/ZipOutputStream of the current JDK does and for a reason - there was a request from couple of customers to make native unpack200 results binary identical to the results taken from Java version. The bits set in the general flags are "reserved by PKWARE" or "Currently unused" according to the Zip specification but ZipOutputStream sets them this way. Same goes to the extraction of crc/size/csize into separate header - just to be compatible with Java implementation. We indeed do not support large (>4GB) files due to the limitations of in-memory unpacking so yes, i omitted the logic of creation of the extended Zip64 LOC and CEN entries because there will be no case when they might be called upon. The only Zip64 feature is the support of the archives with >64K files - the rest id the Java JarOutputStream compatibility tweaks. At this moment i don't think that supporting old JDK behavior for the jars with >64K files is required - the older unpack200 wouldn't handle the situation correctly anyways. If the request for such option will emerge then implementing it will be a whole new task. /Alex On 1/15/14 8:58, Xueming Shen wrote: > Hi Alex, > > (1) what's the bits are you setting into the general flags fields as > below? > > header[4] = ( store ) ? SWAP_BYTES(0x0800) : 0x0808; > > (2) why do you want to use extra data descriptor to set crc/size/csize? > while I understand that Jar/ZipOutputStream does that, but that is > because > they don't have the choice given the nature of "stream", which means they > don't know the csize and crc value until all bits get > compressed/crc-ed. In > case of unpack, all bits should have already be compressed and the crc > value > has been calculated, I don't see any compelling reason we need to sue the > extra data descriptor here. > > (3) to add the "cafe" jar magic is interesting. that is really an old > implementation > details of "jar on solaris". any request to add this one into the > unpack tool? > > (4) I dont think the changeset is tryin to support ZIP64 extra fields > tag in > LOC and CEN tables (I kinda understand why, given the unpack does all > "unpacking" work in memory, it is practically unrealistic to have a >4G > memory to hold all > 4G data). It appears most of the changes other > than the > zip64 end table is really not related to "support the new zip64 format" > > (5) flag "jdk.util.zip.inhibitZip64" is introduced in jdk8 to support > a "old" > behavior for > 64K total entries. You guys might want to consider if > it is > also worth considering to have this flag supported in unpack200. > > -Sherman > > On 1/14/14 10:04 AM, Alexander Zuev wrote: >> Please review my fix for >> JDK-8029646: [pack200] should support the new zip64 format. >> >> The fix can be found at >> http://cr.openjdk.java.net/~kizune/8029646/webrev.00/ >> >> Bug description is: https://bugs.openjdk.java.net/browse/JDK-8029646 >> >> /Alex > From alexander.zuev at oracle.com Wed Jan 15 14:34:06 2014 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Wed, 15 Jan 2014 18:34:06 +0400 Subject: JDK9 RFR of JDK-8029646: [pack200] should support the new zip64 format. In-Reply-To: <52D69A9A.1010506@oracle.com> References: <52D57C2A.4010906@oracle.com> <52D61589.1090901@oracle.com> <52D69A9A.1010506@oracle.com> Message-ID: <52D69C5E.9020407@oracle.com> Sherman et all, self-correction regarding the flags, i misread the specification so flags are: always support UTF-8 file encoding (bit 11) and using EOS marker for the compressed files(bit 4). /Alex On 1/15/14 18:26, Alexander Zuev wrote: > Hi Sherman, > > Thanks for comments, here are some answers: > > the answer to (1)-(3) is that i do whatever the > JarOutputStream/ZipOutputStream > of the current JDK does and for a reason - there was a request from > couple of customers > to make native unpack200 results binary identical to the results taken > from Java > version. The bits set in the general flags are "reserved by PKWARE" or > "Currently unused" > according to the Zip specification but ZipOutputStream sets them this > way. Same goes to the > extraction of crc/size/csize into separate header - just to be > compatible with Java > implementation. > > We indeed do not support large (>4GB) files due to the limitations of > in-memory > unpacking so yes, i omitted the logic of creation of the extended > Zip64 LOC > and CEN entries because there will be no case when they might be > called upon. > The only Zip64 feature is the support of the archives with >64K files > - the > rest id the Java JarOutputStream compatibility tweaks. > > At this moment i don't think that supporting old JDK behavior for > the jars > with >64K files is required - the older unpack200 wouldn't handle the > situation > correctly anyways. If the request for such option will emerge then > implementing > it will be a whole new task. > > /Alex > > On 1/15/14 8:58, Xueming Shen wrote: >> Hi Alex, >> >> (1) what's the bits are you setting into the general flags fields as >> below? >> >> header[4] = ( store ) ? SWAP_BYTES(0x0800) : 0x0808; >> >> (2) why do you want to use extra data descriptor to set crc/size/csize? >> while I understand that Jar/ZipOutputStream does that, but that is >> because >> they don't have the choice given the nature of "stream", which means >> they >> don't know the csize and crc value until all bits get >> compressed/crc-ed. In >> case of unpack, all bits should have already be compressed and the >> crc value >> has been calculated, I don't see any compelling reason we need to sue >> the >> extra data descriptor here. >> >> (3) to add the "cafe" jar magic is interesting. that is really an old >> implementation >> details of "jar on solaris". any request to add this one into the >> unpack tool? >> >> (4) I dont think the changeset is tryin to support ZIP64 extra fields >> tag in >> LOC and CEN tables (I kinda understand why, given the unpack does all >> "unpacking" work in memory, it is practically unrealistic to have a >4G >> memory to hold all > 4G data). It appears most of the changes other >> than the >> zip64 end table is really not related to "support the new zip64 format" >> >> (5) flag "jdk.util.zip.inhibitZip64" is introduced in jdk8 to support >> a "old" >> behavior for > 64K total entries. You guys might want to consider if >> it is >> also worth considering to have this flag supported in unpack200. >> >> -Sherman >> >> On 1/14/14 10:04 AM, Alexander Zuev wrote: >>> Please review my fix for >>> JDK-8029646: [pack200] should support the new zip64 format. >>> >>> The fix can be found at >>> http://cr.openjdk.java.net/~kizune/8029646/webrev.00/ >>> >>> Bug description is: https://bugs.openjdk.java.net/browse/JDK-8029646 >>> >>> /Alex >> > From alexander.zuev at oracle.com Wed Jan 15 14:44:31 2014 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Wed, 15 Jan 2014 18:44:31 +0400 Subject: JDK9 RFR of JDK-8029646: [pack200] should support the new zip64 format. In-Reply-To: <52D69C5E.9020407@oracle.com> References: <52D57C2A.4010906@oracle.com> <52D61589.1090901@oracle.com> <52D69A9A.1010506@oracle.com> <52D69C5E.9020407@oracle.com> Message-ID: <52D69ECF.2090205@oracle.com> On 1/15/14 18:34, Alexander Zuev wrote: > Sherman et all, > > self-correction regarding the flags, i misread the specification so > flags are: always support UTF-8 file encoding (bit 11) and using EOS > marker for the compressed files(bit 4). Damn my fast fingers - not bit 4, bit 3 and it tells we are separating crc/size/csize into the separate header record for deflated files. I will update the comments with the description. Sorry for the confusion. /Alex From alexander.zuev at oracle.com Wed Jan 15 14:55:46 2014 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Wed, 15 Jan 2014 18:55:46 +0400 Subject: JDK9 RFR of JDK-8029646: [pack200] should support the new zip64 format. In-Reply-To: <52D5B5BF.2010104@oracle.com> References: <52D57C2A.4010906@oracle.com> <52D5B5BF.2010104@oracle.com> Message-ID: <52D6A172.6050003@oracle.com> Kumar, thanks for your findings. See my comments inline. On 1/15/14 2:10, Kumar Srinivasan wrote: > Hi Alex, > > zip.cpp: (nit) I would keep the hex values to be in upper case just > like the others for > consistency, not a big deal. Fixed. > > typo: + // Zip64 END sugnature Also fixed. > > > PackTestZip64.java: shouldn't we test a jar with 64K+ entries ? Do we really have to do so? Creating, repacking, packing, unpacking and comparing of such jar file would take a lot of testing time. Right now i'm just testing that we are producing binary identical jar after we normalized it. If you think creating of large jar file is necessary i can easily do so. /Alex > > Kumar > > > > On 1/14/2014 10:04 AM, Alexander Zuev wrote: >> Please review my fix for >> JDK-8029646: [pack200] should support the new zip64 format. >> >> The fix can be found at >> http://cr.openjdk.java.net/~kizune/8029646/webrev.00/ >> >> Bug description is: https://bugs.openjdk.java.net/browse/JDK-8029646 >> >> /Alex > From alexander.zuev at oracle.com Wed Jan 15 15:01:21 2014 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Wed, 15 Jan 2014 19:01:21 +0400 Subject: JDK9 RFR of JDK-8029646: [pack200] should support the new zip64 format. In-Reply-To: <52D69C5E.9020407@oracle.com> References: <52D57C2A.4010906@oracle.com> <52D61589.1090901@oracle.com> <52D69A9A.1010506@oracle.com> <52D69C5E.9020407@oracle.com> Message-ID: <52D6A2C1.2000802@oracle.com> Hello, the new webrev with all the typos and comments fixed can be found at http://cr.openjdk.java.net/~kizune/8029646/webrev.01/ /Alex From vladimir.x.ivanov at oracle.com Wed Jan 15 15:31:04 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 15 Jan 2014 19:31:04 +0400 Subject: [JDK8] RFR (XS): JSR292: IncompatibleClassChangeError in LambdaForm for CharSequence.toString() method handle type converter Message-ID: <52D6A9B8.2040906@oracle.com> http://cr.openjdk.java.net/~vlivanov/8031502/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8031502 InvokeBytecodeGenerator can produce incorrect bytecode for a LambdaForm when invoking a method from Object declared in an interface. The problem is the following: (1) java.lang.CharSequence interface declares abstract method "String toString()"; (2) after 8014013 fix, VM resolves CharSequence::toString()/invokeInterface to CharSequence::toString()/invokeVirtual; (3) during LambdaForm compilation, CharSequence is considered statically invocable (see InvokeBytecodeGenerator::isStaticallyInvocable) and invokevirtual for CharSequence::toString() is issued, which is wrong (invokevirtual throws ICCE if it references an interface); The fix is straightforward: during LambdaForm compilation, switch back from invokevirtual to invokeinterface instruction when invoking a method on an interface. The fix is targeted for 8. Will be also integrated into 9. Testing: regression test, jdk/test/java/lang/invoke, vm.mlvm.testlist, nashorn, jruby. Thanks! Best regards, Vladimir Ivanov From david.r.chase at oracle.com Wed Jan 15 15:44:54 2014 From: david.r.chase at oracle.com (David Chase) Date: Wed, 15 Jan 2014 10:44:54 -0500 Subject: [JDK8] RFR (XS): JSR292: IncompatibleClassChangeError in LambdaForm for CharSequence.toString() method handle type converter In-Reply-To: <52D6A9B8.2040906@oracle.com> References: <52D6A9B8.2040906@oracle.com> Message-ID: <40D7D8F4-7909-46F5-B4FD-9481E8889F47@oracle.com> On 2014-01-15, at 10:31 AM, Vladimir Ivanov wrote: > The fix is targeted for 8. Will be also integrated into 9. > > Testing: regression test, jdk/test/java/lang/invoke, vm.mlvm.testlist, > nashorn, jruby. Vladimir, Did you test also on defmeth, or has that been incorporated into one of the other test suites? David From sundararajan.athijegannathan at oracle.com Wed Jan 15 15:48:22 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Wed, 15 Jan 2014 21:18:22 +0530 Subject: [JDK8] RFR (XS): JSR292: IncompatibleClassChangeError in LambdaForm for CharSequence.toString() method handle type converter In-Reply-To: <52D6A9B8.2040906@oracle.com> References: <52D6A9B8.2040906@oracle.com> Message-ID: <52D6ADC6.4060408@oracle.com> Looks good to me -Sundar On Wednesday 15 January 2014 09:01 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8031502/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8031502 > > InvokeBytecodeGenerator can produce incorrect bytecode for a > LambdaForm when invoking a method from Object declared in an interface. > > The problem is the following: > (1) java.lang.CharSequence interface declares abstract method > "String toString()"; > > (2) after 8014013 fix, VM resolves > CharSequence::toString()/invokeInterface to > CharSequence::toString()/invokeVirtual; > > (3) during LambdaForm compilation, CharSequence is considered > statically invocable (see > InvokeBytecodeGenerator::isStaticallyInvocable) and invokevirtual for > CharSequence::toString() is issued, which is wrong (invokevirtual > throws ICCE if it references an interface); > > The fix is straightforward: during LambdaForm compilation, switch back > from invokevirtual to invokeinterface instruction when invoking a > method on an interface. > > The fix is targeted for 8. Will be also integrated into 9. > > Testing: regression test, jdk/test/java/lang/invoke, vm.mlvm.testlist, > nashorn, jruby. > > Thanks! > > Best regards, > Vladimir Ivanov From brian.burkhalter at oracle.com Wed Jan 15 16:04:22 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 15 Jan 2014 08:04:22 -0800 (PST) Subject: JDK 9 RFR of 8030814: Long.parseUnsignedLong should throw exception on too large input Message-ID: <462b2152-e94c-4b35-9e17-cd5dcfe7b4c9@default> Given the identified items are changed accordingly is this approved? Thanks, Brian ----- Original Message ----- From: joe.darcy at oracle.com To: brian.burkhalter at oracle.com Cc: core-libs-dev at openjdk.java.net Sent: Tuesday, January 14, 2014 7:28:11 PM GMT -08:00 US/Canada Pacific Subject: Re: JDK 9 RFR of 8030814: Long.parseUnsignedLong should throw exception on too large input Hi Brian, Lots good other than a few quibbles: We usually use /* * */ for long multi-line comments rather than // // // In the test update, we don't usually include mention of the bug id other than the @bug line. Thanks, -Joe On 1/14/2014 11:56 AM, Brian Burkhalter wrote: > Please see the updated webrev http://cr.openjdk.java.net/~bpb/8030814/webrev.3/. > > Hopefully my verbose description of the very clever overflow test is accurate and understandable. Also, I cleaned up the JTREG test a bit and added some tests based on the boundary values which split the range of the quantity "guard." > > Thanks, > > Brian From vladimir.x.ivanov at oracle.com Wed Jan 15 16:09:27 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 15 Jan 2014 20:09:27 +0400 Subject: [JDK8] RFR (XS): JSR292: IncompatibleClassChangeError in LambdaForm for CharSequence.toString() method handle type converter In-Reply-To: <40D7D8F4-7909-46F5-B4FD-9481E8889F47@oracle.com> References: <52D6A9B8.2040906@oracle.com> <40D7D8F4-7909-46F5-B4FD-9481E8889F47@oracle.com> Message-ID: <52D6B2B7.8030004@oracle.com> David, thanks for looking at the fix. Good suggestion. Just ran tests on default methods - all pass. Best regards, Vladimir Ivanov On 1/15/14 7:44 PM, David Chase wrote: > > On 2014-01-15, at 10:31 AM, Vladimir Ivanov wrote: >> The fix is targeted for 8. Will be also integrated into 9. >> >> Testing: regression test, jdk/test/java/lang/invoke, vm.mlvm.testlist, >> nashorn, jruby. > > > Vladimir, > > Did you test also on defmeth, or has that been incorporated into one of the other test suites? > > David > > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From vladimir.x.ivanov at oracle.com Wed Jan 15 16:09:49 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 15 Jan 2014 20:09:49 +0400 Subject: [JDK8] RFR (XS): JSR292: IncompatibleClassChangeError in LambdaForm for CharSequence.toString() method handle type converter In-Reply-To: <52D6ADC6.4060408@oracle.com> References: <52D6A9B8.2040906@oracle.com> <52D6ADC6.4060408@oracle.com> Message-ID: <52D6B2CD.3070209@oracle.com> Sundar, thank you. Best regards, Vladimir Ivanov On 1/15/14 7:48 PM, A. Sundararajan wrote: > Looks good to me > > -Sundar > > On Wednesday 15 January 2014 09:01 PM, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~vlivanov/8031502/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8031502 >> >> InvokeBytecodeGenerator can produce incorrect bytecode for a >> LambdaForm when invoking a method from Object declared in an interface. >> >> The problem is the following: >> (1) java.lang.CharSequence interface declares abstract method >> "String toString()"; >> >> (2) after 8014013 fix, VM resolves >> CharSequence::toString()/invokeInterface to >> CharSequence::toString()/invokeVirtual; >> >> (3) during LambdaForm compilation, CharSequence is considered >> statically invocable (see >> InvokeBytecodeGenerator::isStaticallyInvocable) and invokevirtual for >> CharSequence::toString() is issued, which is wrong (invokevirtual >> throws ICCE if it references an interface); >> >> The fix is straightforward: during LambdaForm compilation, switch back >> from invokevirtual to invokeinterface instruction when invoking a >> method on an interface. >> >> The fix is targeted for 8. Will be also integrated into 9. >> >> Testing: regression test, jdk/test/java/lang/invoke, vm.mlvm.testlist, >> nashorn, jruby. >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov > From volker.simonis at gmail.com Wed Jan 15 16:34:58 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 15 Jan 2014 17:34:58 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: <94ABE61E-10BC-407E-92D0-B528165F3460@oracle.com> References: <94ABE61E-10BC-407E-92D0-B528165F3460@oracle.com> Message-ID: Hi Staffan, thanks for the review. Please find my comments inline: On Wed, Jan 15, 2014 at 9:57 AM, Staffan Larsen wrote: > Volker, > > I?ve look at the following files: > > src/share/native/sun/management/DiagnosticCommandImpl.c: > nit: ?legel? -> ?legal? (two times) > In Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo() if > you allow dcmd_info_array to become NULL, > then jmm_interface->GetDiagnosticCommandInfo() will throw an NPE and you > need to check that. > Good catch. I actually had problems with malloc returning NULL in 'getDiagnosticCommandArgumentInfoArray()' and then changed all other potentially dangerous locations which used the same pattern. However I think if the 'dcmd_info_array' has zero length it would be perfectly fine to return a zero length array. So what about the following solution: dcmdInfoCls = (*env)->FindClass(env, "sun/management/DiagnosticCommandInfo"); num_commands = (*env)->GetArrayLength(env, commands); if (num_commands = 0) { result = (*env)->NewObjectArray(env, 0, dcmdInfoCls, NULL); if (result == NULL) { JNU_ThrowOutOfMemoryError(env, 0); } else { return result; } } dcmd_info_array = (dcmdInfo*) malloc(num_commands * sizeof(dcmdInfo)); if (dcmd_info_array == NULL) { JNU_ThrowOutOfMemoryError(env, NULL); } jmm_interface->GetDiagnosticCommandInfo(env, commands, dcmd_info_array); result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL); That seems easier and saves me from handling the exception. What do you think? src/solaris/native/sun/management/OperatingSystemImpl.c > No comments. > > src/share/transport/socket/socketTransport.c > No comments. > > > src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider > No comments. > > > Thanks, > /Staffan > > > > On 14 jan 2014, at 09:40, Volker Simonis wrote: > > Hi, > > could you please review the following changes for the ppc-aix-port > stage/stage-9 repositories (the changes are planned for integration into > ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): > > http://cr.openjdk.java.net/~simonis/webrevs/8031581/ > > I've build and smoke tested without any problems on Linux/x86_64 and > PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64. > > With these changes (and together with the changes from "8028537: PPC64: > Updated jdk/test scripts to understand the AIX os and environment" and > "8031134 : PPC64: implement printing on AIX") our port passes all but the > following 7 jtreg regression tests on AIX (compared to the Linux/x86_64 > baseline from www.java.net/download/jdk8/testresults/testresults.html?): > > java/net/Inet6Address/B6558853.java > java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically) > java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java > java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically) > java/nio/channels/Selector/RacyDeregister.java > sun/security/krb5/auto/Unreachable.java (only on IPv6) > > Thank you and best regards, > Volker > > > Following a detailed description of the various changes: > src/share/native/java/util/zip/zip_util.c > src/share/native/sun/management/DiagnosticCommandImpl.c > > - According to ISO C it is perfectly legal for malloc to return zero > if called with a zero argument. Fix various places where malloc can > potentially correctly return zero because it was called with a zero > argument. > - Also fixed DiagnosticCommandImpl.c to include stdlib.h. This only > fixes a compiler warning on Linux, but on AIX it prevents a VM crash later > on because the return value of malloc() will be casted to int which is > especially bad if that pointer was bigger than 32-bit. > > make/CompileJavaClasses.gmk > > - Also use PollingWatchService on AIX. > > make/lib/NioLibraries.gmk > src/aix/native/sun/nio/ch/AixNativeThread.c > > - Put the implementation for the native methods of NativeThread into > AixNativeThread.c on AIX. > > src/solaris/native/sun/nio/ch/PollArrayWrapper.c > src/solaris/native/sun/nio/ch/Net.c > src/aix/classes/sun/nio/ch/AixPollPort.java > src/aix/native/sun/nio/ch/AixPollPort.c > src/aix/native/java/net/aix_close.c > > - On AIX, the constants used for the polling events (i.e. POLLIN, > POLLOUT, ...) are defined to different values than on other operating > systems. The problem is however, that these constants are hardcoded as > public final static members of various, shared Java classes. We therefore > have to map them from Java to native every time before calling one of the > native poll functions and back to Java after the call on AIX in order to > get the right semantics. > > src/share/classes/java/nio/file/CopyMoveHelper.java > > - As discussed on the core-libs mailing list (see > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024119.html) > it is not necessary to call Files.getFileAttributeView() with any > linkOptions because at that place we've already checked that the > target file can not be a symbolic link. This change makes the > implementation more robust on platforms which support symbolic links but do > not support the O_NOFOLLOW flag to the open system call. It also makes > the JDK pass the demo/zipfs/basic.sh test on AIX. > > src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java > > - Support "compound text" on AIX in the same way like on other Unix > platforms. > > > src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider > > - Define the correct attach provider for AIX. > > src/solaris/native/java/net/net_util_md.h > src/solaris/native/sun/nio/ch/FileDispatcherImpl.c > src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c > > - AIX needs a workaround for I/O cancellation (see: > http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/close.htm). > "..The close() subroutine is blocked until all subroutines which use > the file descriptor return to usr space. For example, when a thread is > calling close and another thread is calling select with the same file > descriptor, the close subroutine does not return until the select call > returns...". To fix this problem, we have to use the various NET_wrappers which are declared in > net_util_md.h and defined in aix_close.c and we also need some > additional wrappers for fcntl(), read() and write() on AIX. > While the current solution isn't really nice because it introduces > some more AIX-specifc sections in shared code, I think it is the best way > to go for JDK 8 because it imposes the smallest possible changes and risks > for the existing platforms. I'm ready to change the code to unconditionally > use the wrappers for all platforms and implement the wrappers empty on > platforms which don't need any wrapping. I think it would also be nice to > clean up the names (e.g. NET_Read() is currently a wrapper for recv()and the > NET_ prefix is probably not appropriate any more so maybe change it to > something like IO_). But again, I'll prefer to keep that as a follow > up change for JDK9. > - Calling fsync() on a "read-only" file descriptor on AIX will result > in an error (i.e. "EBADF: The FileDescriptor parameter is not a valid file > descriptor open for writing."). To prevent this error we have to query if > the corresponding file descriptor is writeable. Notice that at that point > we can not access the writable attribute of the corresponding file > channel so we have to use fcntl(). > > src/solaris/classes/java/lang/UNIXProcess.java.aix > > - On AIX the implementation is especially tricky, because the close()system call will block if another thread is at the same time blocked in a > file operation (e.g. 'read()') on the same file descriptor. We therefore > combine the AIX ProcessPipeInputStream implemenatation with the > DeferredCloseInputStream approach used on Solaris (see > UNIXProcess.java.solaris). This means that every potentially blocking > operation on the file descriptor increments a counter before it is executed > and decrements it once it finishes. The 'close()' operation will only be > executed if there are no pending operations. Otherwise it is deferred after > the last pending operation has finished. > > src/share/transport/socket/socketTransport.c > > - On AIX we have to call shutdown() on a socket descriptor before > closing it, otherwise the close() call may be blocked. This is the > same problem as described before. Unfortunately the JDI framework doesn't > use the same IO wrappers like other class library components so we can not > easily use the NET_ abstractions from aix_close.c here. > - Without this small change all JDI regression tests will fail on AIX > because of the way how the tests act as a "debugger" which launches another > VM (the "debugge") which connects itself back to the debugger. In this > scenario the "debugge" can not shut down itself because one thread will > always be blocked in the close() call on one of the communication > sockets. > > src/solaris/native/java/net/NetworkInterface.c > > - Set the scope identifier for IPv6 addresses on AIX. > > src/solaris/native/java/net/net_util_md.c > > - It turns out that we do not always have to replace SO_REUSEADDR on > AIX by SO_REUSEPORT. Instead we can simply use the same approach like > BSD and only use SO_REUSEPORT additionally, if several datagram > sockets try to bind to the same port. > - Also fixed a comment and removed unused local variables. > - Fixed the obviously inverted assignment newTime = prevTime; which > should read prevTime = newTime;. Otherwise prevTime will never change > and the timeout will be potential reached too fast. > > src/solaris/native/sun/management/OperatingSystemImpl.c > > - AIX does not understand /proc/self so we have to query the real > process ID to access the proc file system. > > src/solaris/native/sun/nio/ch/DatagramChannelImpl.c > > - On AIX, connect() may legally return EAFNOSUPPORT if called on a > socket with the address family set to AF_UNSPEC. > > > > From volker.simonis at gmail.com Wed Jan 15 16:42:47 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 15 Jan 2014 17:42:47 +0100 Subject: RFR(S/L): 8028537: PPC64: Updated the JDK regression tests to run on AIX In-Reply-To: <52D58C55.6070004@oracle.com> References: <52D58C55.6070004@oracle.com> Message-ID: Hi Alan, thanks for the suggestion. That's fine for me. I've copied the empty SCTP stubs from the macosx to the aix directory as well and updated the make file accordingly (in the patch for "8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests"). Therefore, the changes to the three tests: test/com/sun/nio/sctp/SctpChannel/Util.java test/com/sun/nio/sctp/SctpMultiChannel/Util.java test/com/sun/nio/sctp/SctpServerChannel/Util.java can be considered obsolete. Regards, Volker On Tue, Jan 14, 2014 at 8:13 PM, Alan Bateman wrote: > On 14/01/2014 16:57, Volker Simonis wrote: > >> : >> >> test/com/sun/nio/sctp/SctpChannel/Util.java >> test/com/sun/nio/sctp/SctpMultiChannel/Util.java >> test/com/sun/nio/sctp/SctpServerChannel/Util.java >> >> - On AIX, we currently haven't implemented SCTP but we nevertheless >> >> compile the shared SCTP classes into the runtime class library. This >> way >> the AIX JDK can at least compile SCTP applications altough it can not >> run >> them. To support this scenario, the runtime check for the >> availability of >> SCTP has to be extended to catch UnsatisfiedLinkError and >> NoClassDefFoundError. UnsatisfiedLinkError will be thrown the first >> time >> when the class SctpChannelImpl will be loaded because it cannot load >> the >> its native support library in the static initialisation section. On >> the >> next load attempt of the class, a NoClassDefFoundError will be thrown >> because of the previously failed initialisation. >> >> OS X has the same issue and the solution used there are stub > implementations that just throw UOE. Details in jdk/src/macosx/classes/sun/nio/ch/sctp > and that maybe that would work for AIX too. > > -Alan. > From volker.simonis at gmail.com Wed Jan 15 17:27:01 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 15 Jan 2014 18:27:01 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <94ABE61E-10BC-407E-92D0-B528165F3460@oracle.com> Message-ID: On Wed, Jan 15, 2014 at 5:34 PM, Volker Simonis wrote: > Hi Staffan, > > thanks for the review. Please find my comments inline: > > On Wed, Jan 15, 2014 at 9:57 AM, Staffan Larsen > wrote: >> >> Volker, >> >> I?ve look at the following files: >> >> src/share/native/sun/management/DiagnosticCommandImpl.c: >> nit: ?legel? -> ?legal? (two times) >> In Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo() if >> you allow dcmd_info_array to become NULL, then >> jmm_interface->GetDiagnosticCommandInfo() will throw an NPE and you need to >> check that. > > > Good catch. I actually had problems with malloc returning NULL in > 'getDiagnosticCommandArgumentInfoArray()' and then changed all other > potentially dangerous locations which used the same pattern. > > However I think if the 'dcmd_info_array' has zero length it would be > perfectly fine to return a zero length array. So what about the following > solution: > > dcmdInfoCls = (*env)->FindClass(env, > "sun/management/DiagnosticCommandInfo"); > num_commands = (*env)->GetArrayLength(env, commands); Sorry, of course I wanted to say "if (num_commands == 0)" here! > if (num_commands = 0) { > result = (*env)->NewObjectArray(env, 0, dcmdInfoCls, NULL); > if (result == NULL) { > JNU_ThrowOutOfMemoryError(env, 0); > } > else { > return result; > } > } > dcmd_info_array = (dcmdInfo*) malloc(num_commands * sizeof(dcmdInfo)); > if (dcmd_info_array == NULL) { > JNU_ThrowOutOfMemoryError(env, NULL); > } > jmm_interface->GetDiagnosticCommandInfo(env, commands, dcmd_info_array); > result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL); > > That seems easier and saves me from handling the exception. > > What do you think? > >> src/solaris/native/sun/management/OperatingSystemImpl.c >> No comments. >> >> src/share/transport/socket/socketTransport.c >> No comments. >> >> >> src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider >> No comments. >> >> >> Thanks, >> /Staffan >> >> >> >> On 14 jan 2014, at 09:40, Volker Simonis wrote: >> >> Hi, >> >> could you please review the following changes for the ppc-aix-port >> stage/stage-9 repositories (the changes are planned for integration into >> ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): >> >> http://cr.openjdk.java.net/~simonis/webrevs/8031581/ >> >> I've build and smoke tested without any problems on Linux/x86_64 and >> PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64. >> >> With these changes (and together with the changes from "8028537: PPC64: >> Updated jdk/test scripts to understand the AIX os and environment" and >> "8031134 : PPC64: implement printing on AIX") our port passes all but the >> following 7 jtreg regression tests on AIX (compared to the Linux/x86_64 >> baseline from www.java.net/download/jdk8/testresults/testresults.html?): >> >> java/net/Inet6Address/B6558853.java >> java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically) >> java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java >> java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically) >> java/nio/channels/Selector/RacyDeregister.java >> sun/security/krb5/auto/Unreachable.java (only on IPv6) >> >> Thank you and best regards, >> Volker >> >> >> Following a detailed description of the various changes: >> >> src/share/native/java/util/zip/zip_util.c >> src/share/native/sun/management/DiagnosticCommandImpl.c >> >> According to ISO C it is perfectly legal for malloc to return zero if >> called with a zero argument. Fix various places where malloc can potentially >> correctly return zero because it was called with a zero argument. >> Also fixed DiagnosticCommandImpl.c to include stdlib.h. This only fixes a >> compiler warning on Linux, but on AIX it prevents a VM crash later on >> because the return value of malloc() will be casted to int which is >> especially bad if that pointer was bigger than 32-bit. >> >> make/CompileJavaClasses.gmk >> >> Also use PollingWatchService on AIX. >> >> make/lib/NioLibraries.gmk >> src/aix/native/sun/nio/ch/AixNativeThread.c >> >> Put the implementation for the native methods of NativeThread into >> AixNativeThread.c on AIX. >> >> src/solaris/native/sun/nio/ch/PollArrayWrapper.c >> src/solaris/native/sun/nio/ch/Net.c >> src/aix/classes/sun/nio/ch/AixPollPort.java >> src/aix/native/sun/nio/ch/AixPollPort.c >> src/aix/native/java/net/aix_close.c >> >> On AIX, the constants used for the polling events (i.e. POLLIN, POLLOUT, >> ...) are defined to different values than on other operating systems. The >> problem is however, that these constants are hardcoded as public final >> static members of various, shared Java classes. We therefore have to map >> them from Java to native every time before calling one of the native poll >> functions and back to Java after the call on AIX in order to get the right >> semantics. >> >> src/share/classes/java/nio/file/CopyMoveHelper.java >> >> As discussed on the core-libs mailing list (see >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024119.html) >> it is not necessary to call Files.getFileAttributeView() with any >> linkOptions because at that place we've already checked that the target file >> can not be a symbolic link. This change makes the implementation more robust >> on platforms which support symbolic links but do not support the O_NOFOLLOW >> flag to the open system call. It also makes the JDK pass the >> demo/zipfs/basic.sh test on AIX. >> >> src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java >> >> Support "compound text" on AIX in the same way like on other Unix >> platforms. >> >> >> src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider >> >> Define the correct attach provider for AIX. >> >> src/solaris/native/java/net/net_util_md.h >> src/solaris/native/sun/nio/ch/FileDispatcherImpl.c >> src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c >> >> AIX needs a workaround for I/O cancellation (see: >> http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/close.htm). >> "..The close() subroutine is blocked until all subroutines which use the >> file descriptor return to usr space. For example, when a thread is calling >> close and another thread is calling select with the same file descriptor, >> the close subroutine does not return until the select call returns...". To >> fix this problem, we have to use the various NET_ wrappers which are >> declared in net_util_md.h and defined in aix_close.c and we also need some >> additional wrappers for fcntl(), read() and write() on AIX. >> While the current solution isn't really nice because it introduces some >> more AIX-specifc sections in shared code, I think it is the best way to go >> for JDK 8 because it imposes the smallest possible changes and risks for the >> existing platforms. I'm ready to change the code to unconditionally use the >> wrappers for all platforms and implement the wrappers empty on platforms >> which don't need any wrapping. I think it would also be nice to clean up the >> names (e.g. NET_Read() is currently a wrapper for recv() and the NET_ prefix >> is probably not appropriate any more so maybe change it to something like >> IO_). But again, I'll prefer to keep that as a follow up change for JDK9. >> Calling fsync() on a "read-only" file descriptor on AIX will result in an >> error (i.e. "EBADF: The FileDescriptor parameter is not a valid file >> descriptor open for writing."). To prevent this error we have to query if >> the corresponding file descriptor is writeable. Notice that at that point we >> can not access the writable attribute of the corresponding file channel so >> we have to use fcntl(). >> >> src/solaris/classes/java/lang/UNIXProcess.java.aix >> >> On AIX the implementation is especially tricky, because the close() system >> call will block if another thread is at the same time blocked in a file >> operation (e.g. 'read()') on the same file descriptor. We therefore combine >> the AIX ProcessPipeInputStream implemenatation with the >> DeferredCloseInputStream approach used on Solaris (see >> UNIXProcess.java.solaris). This means that every potentially blocking >> operation on the file descriptor increments a counter before it is executed >> and decrements it once it finishes. The 'close()' operation will only be >> executed if there are no pending operations. Otherwise it is deferred after >> the last pending operation has finished. >> >> src/share/transport/socket/socketTransport.c >> >> On AIX we have to call shutdown() on a socket descriptor before closing >> it, otherwise the close() call may be blocked. This is the same problem as >> described before. Unfortunately the JDI framework doesn't use the same IO >> wrappers like other class library components so we can not easily use the >> NET_ abstractions from aix_close.c here. >> Without this small change all JDI regression tests will fail on AIX >> because of the way how the tests act as a "debugger" which launches another >> VM (the "debugge") which connects itself back to the debugger. In this >> scenario the "debugge" can not shut down itself because one thread will >> always be blocked in the close() call on one of the communication sockets. >> >> src/solaris/native/java/net/NetworkInterface.c >> >> Set the scope identifier for IPv6 addresses on AIX. >> >> src/solaris/native/java/net/net_util_md.c >> >> It turns out that we do not always have to replace SO_REUSEADDR on AIX by >> SO_REUSEPORT. Instead we can simply use the same approach like BSD and only >> use SO_REUSEPORT additionally, if several datagram sockets try to bind to >> the same port. >> Also fixed a comment and removed unused local variables. >> Fixed the obviously inverted assignment newTime = prevTime; which should >> read prevTime = newTime;. Otherwise prevTime will never change and the >> timeout will be potential reached too fast. >> >> src/solaris/native/sun/management/OperatingSystemImpl.c >> >> AIX does not understand /proc/self so we have to query the real process ID >> to access the proc file system. >> >> src/solaris/native/sun/nio/ch/DatagramChannelImpl.c >> >> On AIX, connect() may legally return EAFNOSUPPORT if called on a socket >> with the address family set to AF_UNSPEC. >> >> >> > From joe.darcy at oracle.com Wed Jan 15 17:31:20 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 15 Jan 2014 09:31:20 -0800 Subject: JDK 9 RFR of 8030814: Long.parseUnsignedLong should throw exception on too large input In-Reply-To: <462b2152-e94c-4b35-9e17-cd5dcfe7b4c9@default> References: <462b2152-e94c-4b35-9e17-cd5dcfe7b4c9@default> Message-ID: <52D6C5E8.6020007@oracle.com> Yes :-) -Joe On 01/15/2014 08:04 AM, Brian Burkhalter wrote: > Given the identified items are changed accordingly is this approved? > > Thanks, > > Brian > > ----- Original Message ----- > From: joe.darcy at oracle.com > To: brian.burkhalter at oracle.com > Cc: core-libs-dev at openjdk.java.net > Sent: Tuesday, January 14, 2014 7:28:11 PM GMT -08:00 US/Canada Pacific > Subject: Re: JDK 9 RFR of 8030814: Long.parseUnsignedLong should throw exception on too large input > > Hi Brian, > > Lots good other than a few quibbles: > > We usually use > > /* > * > */ > > for long multi-line comments rather than > > // > // > // > > In the test update, we don't usually include mention of the bug id other > than the @bug line. > > Thanks, > > -Joe > > On 1/14/2014 11:56 AM, Brian Burkhalter wrote: >> Please see the updated webrev http://cr.openjdk.java.net/~bpb/8030814/webrev.3/. >> >> Hopefully my verbose description of the very clever overflow test is accurate and understandable. Also, I cleaned up the JTREG test a bit and added some tests based on the boundary values which split the range of the quantity "guard." >> >> Thanks, >> >> Brian From xueming.shen at oracle.com Wed Jan 15 17:34:40 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 15 Jan 2014 09:34:40 -0800 Subject: JDK9 RFR of JDK-8029646: [pack200] should support the new zip64 format. In-Reply-To: <52D6A2C1.2000802@oracle.com> References: <52D57C2A.4010906@oracle.com> <52D61589.1090901@oracle.com> <52D69A9A.1010506@oracle.com> <52D69C5E.9020407@oracle.com> <52D6A2C1.2000802@oracle.com> Message-ID: <52D6C6B0.3020508@oracle.com> On 1/15/14 7:01 AM, Alexander Zuev wrote: > Hello, > > the new webrev with all the typos and comments fixed can be found at > http://cr.openjdk.java.net/~kizune/8029646/webrev.01/ > > /Alex (1) jarmagic can be just a static constant somewhere or a stack variable. not big deal though. (2) the test only "tests" EOF for s. there is possibility that the newly created has more extra bytes at the end...though in theory this should not happen, it might be better just add an extra line to check the sizes of two first first? (3) the rest of the change looks good, but I agreed with Kumar that you may need to add a regression test for a jar file with > 64k entries. otherwise the code for zip64 end is not being tested. the code looks fine, but I would trust a regression test more than my eyes:-) Thanks! -Sherman From eric.mccorkle at oracle.com Wed Jan 15 17:47:32 2014 From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com) Date: Wed, 15 Jan 2014 17:47:32 +0000 Subject: hg: jdk8/tl/jdk: 8031502: JSR292: IncompatibleClassChangeError in LambdaForm for CharSequence.toString() method handle type converter Message-ID: <20140115174752.A89E762486@hg.openjdk.java.net> Changeset: 9e91793fd516 Author: vlivanov Date: 2014-01-15 20:48 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9e91793fd516 8031502: JSR292: IncompatibleClassChangeError in LambdaForm for CharSequence.toString() method handle type converter Reviewed-by: sundar, lagergren, drchase ! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java + test/java/lang/invoke/ObjectMethodInInterfaceTest.java From christian.thalinger at oracle.com Wed Jan 15 17:51:09 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 15 Jan 2014 09:51:09 -0800 Subject: [JDK8] RFR (XS): JSR292: IncompatibleClassChangeError in LambdaForm for CharSequence.toString() method handle type converter In-Reply-To: <52D6A9B8.2040906@oracle.com> References: <52D6A9B8.2040906@oracle.com> Message-ID: <0DA570E9-814A-44B5-8CDA-6F7C9A92B423@oracle.com> [I?m resending something I sent earlier today to Vladimir directly.] On Jan 15, 2014, at 7:31 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8031502/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8031502 > > InvokeBytecodeGenerator can produce incorrect bytecode for a LambdaForm > when invoking a method from Object declared in an interface. > > The problem is the following: > (1) java.lang.CharSequence interface declares abstract method "String > toString()"; > > (2) after 8014013 fix, VM resolves > CharSequence::toString()/invokeInterface to > CharSequence::toString()/invokeVirtual; Without having looked at the changes of 8014013, why did the invoke type change? Is it an optimization that was added? > > (3) during LambdaForm compilation, CharSequence is considered > statically invocable (see > InvokeBytecodeGenerator::isStaticallyInvocable) and invokevirtual for > CharSequence::toString() is issued, which is wrong (invokevirtual throws > ICCE if it references an interface); > > The fix is straightforward: during LambdaForm compilation, switch back > from invokevirtual to invokeinterface instruction when invoking a method > on an interface. I find this risky. Right now MemberName is only used in a couple places in java.lang.invoke but in the future it might be used for other things (e.g. java.lang.reflect). The information MemberName contains should be correct and usable without changing. Otherwise all users have to patch the information the same way as you do in your patch. I would like to see the VM passing correct information (whatever the definition of correct is here). > > The fix is targeted for 8. Will be also integrated into 9. > > Testing: regression test, jdk/test/java/lang/invoke, vm.mlvm.testlist, > nashorn, jruby. > > Thanks! > > Best regards, > Vladimir Ivanov > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From volker.simonis at gmail.com Wed Jan 15 17:52:39 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 15 Jan 2014 18:52:39 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <94ABE61E-10BC-407E-92D0-B528165F3460@oracle.com> Message-ID: On Wed, Jan 15, 2014 at 6:27 PM, Volker Simonis wrote: > On Wed, Jan 15, 2014 at 5:34 PM, Volker Simonis > wrote: >> Hi Staffan, >> >> thanks for the review. Please find my comments inline: >> >> On Wed, Jan 15, 2014 at 9:57 AM, Staffan Larsen < staffan.larsen at oracle.com> >> wrote: >>> >>> Volker, >>> >>> I?ve look at the following files: >>> >>> src/share/native/sun/management/DiagnosticCommandImpl.c: >>> nit: ?legel? -> ?legal? (two times) >>> In Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo() if >>> you allow dcmd_info_array to become NULL, then >>> jmm_interface->GetDiagnosticCommandInfo() will throw an NPE and you need to >>> check that. >> >> >> Good catch. I actually had problems with malloc returning NULL in >> 'getDiagnosticCommandArgumentInfoArray()' and then changed all other >> potentially dangerous locations which used the same pattern. >> >> However I think if the 'dcmd_info_array' has zero length it would be >> perfectly fine to return a zero length array. So what about the following >> solution: >> Sorry for the noise - it seems I was a little indisposed during the last mails:) So this is the simple change I'd like to propose for Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo(): @@ -117,19 +119,23 @@ return NULL; } num_commands = (*env)->GetArrayLength(env, commands); - dcmd_info_array = (dcmdInfo*) malloc(num_commands * - sizeof(dcmdInfo)); + dcmdInfoCls = (*env)->FindClass(env, + "sun/management/DiagnosticCommandInfo"); + result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL); + if (result == NULL) { + JNU_ThrowOutOfMemoryError(env, 0); + } + if (num_commands == 0) { + /* Handle the 'zero commands' case specially to avoid calling 'malloc()' */ + /* with a zero argument because that may legally return a NULL pointer. */ + return result; + } + dcmd_info_array = (dcmdInfo*) malloc(num_commands * sizeof(dcmdInfo)); if (dcmd_info_array == NULL) { JNU_ThrowOutOfMemoryError(env, NULL); } jmm_interface->GetDiagnosticCommandInfo(env, commands, dcmd_info_array); - dcmdInfoCls = (*env)->FindClass(env, - "sun/management/DiagnosticCommandInfo"); - result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL); - if (result == NULL) { - free(dcmd_info_array); - JNU_ThrowOutOfMemoryError(env, 0); - } for (i=0; iGetObjectArrayElement(env,commands,i), If the 'commands' input array is of zero length just return a zero length array. OK? >> dcmdInfoCls = (*env)->FindClass(env, >> "sun/management/DiagnosticCommandInfo"); >> num_commands = (*env)->GetArrayLength(env, commands); > > Sorry, of course I wanted to say "if (num_commands == 0)" here! > >> if (num_commands = 0) { >> result = (*env)->NewObjectArray(env, 0, dcmdInfoCls, NULL); >> if (result == NULL) { >> JNU_ThrowOutOfMemoryError(env, 0); >> } >> else { >> return result; >> } >> } >> dcmd_info_array = (dcmdInfo*) malloc(num_commands * sizeof(dcmdInfo)); >> if (dcmd_info_array == NULL) { >> JNU_ThrowOutOfMemoryError(env, NULL); >> } >> jmm_interface->GetDiagnosticCommandInfo(env, commands, dcmd_info_array); >> result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL); >> >> That seems easier and saves me from handling the exception. >> >> What do you think? >> >>> src/solaris/native/sun/management/OperatingSystemImpl.c >>> No comments. >>> >>> src/share/transport/socket/socketTransport.c >>> No comments. >>> >>> >>> src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider >>> No comments. >>> >>> >>> Thanks, >>> /Staffan >>> >>> >>> >>> On 14 jan 2014, at 09:40, Volker Simonis wrote: >>> >>> Hi, >>> >>> could you please review the following changes for the ppc-aix-port >>> stage/stage-9 repositories (the changes are planned for integration into >>> ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/8031581/ >>> >>> I've build and smoke tested without any problems on Linux/x86_64 and >>> PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64. >>> >>> With these changes (and together with the changes from "8028537: PPC64: >>> Updated jdk/test scripts to understand the AIX os and environment" and >>> "8031134 : PPC64: implement printing on AIX") our port passes all but the >>> following 7 jtreg regression tests on AIX (compared to the Linux/x86_64 >>> baseline from www.java.net/download/jdk8/testresults/testresults.html?): >>> >>> java/net/Inet6Address/B6558853.java >>> java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically) >>> java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java >>> java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically) >>> java/nio/channels/Selector/RacyDeregister.java >>> sun/security/krb5/auto/Unreachable.java (only on IPv6) >>> >>> Thank you and best regards, >>> Volker >>> >>> >>> Following a detailed description of the various changes: >>> >>> src/share/native/java/util/zip/zip_util.c >>> src/share/native/sun/management/DiagnosticCommandImpl.c >>> >>> According to ISO C it is perfectly legal for malloc to return zero if >>> called with a zero argument. Fix various places where malloc can potentially >>> correctly return zero because it was called with a zero argument. >>> Also fixed DiagnosticCommandImpl.c to include stdlib.h. This only fixes a >>> compiler warning on Linux, but on AIX it prevents a VM crash later on >>> because the return value of malloc() will be casted to int which is >>> especially bad if that pointer was bigger than 32-bit. >>> >>> make/CompileJavaClasses.gmk >>> >>> Also use PollingWatchService on AIX. >>> >>> make/lib/NioLibraries.gmk >>> src/aix/native/sun/nio/ch/AixNativeThread.c >>> >>> Put the implementation for the native methods of NativeThread into >>> AixNativeThread.c on AIX. >>> >>> src/solaris/native/sun/nio/ch/PollArrayWrapper.c >>> src/solaris/native/sun/nio/ch/Net.c >>> src/aix/classes/sun/nio/ch/AixPollPort.java >>> src/aix/native/sun/nio/ch/AixPollPort.c >>> src/aix/native/java/net/aix_close.c >>> >>> On AIX, the constants used for the polling events (i.e. POLLIN, POLLOUT, >>> ...) are defined to different values than on other operating systems. The >>> problem is however, that these constants are hardcoded as public final >>> static members of various, shared Java classes. We therefore have to map >>> them from Java to native every time before calling one of the native poll >>> functions and back to Java after the call on AIX in order to get the right >>> semantics. >>> >>> src/share/classes/java/nio/file/CopyMoveHelper.java >>> >>> As discussed on the core-libs mailing list (see >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024119.html ) >>> it is not necessary to call Files.getFileAttributeView() with any >>> linkOptions because at that place we've already checked that the target file >>> can not be a symbolic link. This change makes the implementation more robust >>> on platforms which support symbolic links but do not support the O_NOFOLLOW >>> flag to the open system call. It also makes the JDK pass the >>> demo/zipfs/basic.sh test on AIX. >>> >>> src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java >>> >>> Support "compound text" on AIX in the same way like on other Unix >>> platforms. >>> >>> >>> src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider >>> >>> Define the correct attach provider for AIX. >>> >>> src/solaris/native/java/net/net_util_md.h >>> src/solaris/native/sun/nio/ch/FileDispatcherImpl.c >>> src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c >>> >>> AIX needs a workaround for I/O cancellation (see: >>> http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/close.htm ). >>> "..The close() subroutine is blocked until all subroutines which use the >>> file descriptor return to usr space. For example, when a thread is calling >>> close and another thread is calling select with the same file descriptor, >>> the close subroutine does not return until the select call returns...". To >>> fix this problem, we have to use the various NET_ wrappers which are >>> declared in net_util_md.h and defined in aix_close.c and we also need some >>> additional wrappers for fcntl(), read() and write() on AIX. >>> While the current solution isn't really nice because it introduces some >>> more AIX-specifc sections in shared code, I think it is the best way to go >>> for JDK 8 because it imposes the smallest possible changes and risks for the >>> existing platforms. I'm ready to change the code to unconditionally use the >>> wrappers for all platforms and implement the wrappers empty on platforms >>> which don't need any wrapping. I think it would also be nice to clean up the >>> names (e.g. NET_Read() is currently a wrapper for recv() and the NET_ prefix >>> is probably not appropriate any more so maybe change it to something like >>> IO_). But again, I'll prefer to keep that as a follow up change for JDK9. >>> Calling fsync() on a "read-only" file descriptor on AIX will result in an >>> error (i.e. "EBADF: The FileDescriptor parameter is not a valid file >>> descriptor open for writing."). To prevent this error we have to query if >>> the corresponding file descriptor is writeable. Notice that at that point we >>> can not access the writable attribute of the corresponding file channel so >>> we have to use fcntl(). >>> >>> src/solaris/classes/java/lang/UNIXProcess.java.aix >>> >>> On AIX the implementation is especially tricky, because the close() system >>> call will block if another thread is at the same time blocked in a file >>> operation (e.g. 'read()') on the same file descriptor. We therefore combine >>> the AIX ProcessPipeInputStream implemenatation with the >>> DeferredCloseInputStream approach used on Solaris (see >>> UNIXProcess.java.solaris). This means that every potentially blocking >>> operation on the file descriptor increments a counter before it is executed >>> and decrements it once it finishes. The 'close()' operation will only be >>> executed if there are no pending operations. Otherwise it is deferred after >>> the last pending operation has finished. >>> >>> src/share/transport/socket/socketTransport.c >>> >>> On AIX we have to call shutdown() on a socket descriptor before closing >>> it, otherwise the close() call may be blocked. This is the same problem as >>> described before. Unfortunately the JDI framework doesn't use the same IO >>> wrappers like other class library components so we can not easily use the >>> NET_ abstractions from aix_close.c here. >>> Without this small change all JDI regression tests will fail on AIX >>> because of the way how the tests act as a "debugger" which launches another >>> VM (the "debugge") which connects itself back to the debugger. In this >>> scenario the "debugge" can not shut down itself because one thread will >>> always be blocked in the close() call on one of the communication sockets. >>> >>> src/solaris/native/java/net/NetworkInterface.c >>> >>> Set the scope identifier for IPv6 addresses on AIX. >>> >>> src/solaris/native/java/net/net_util_md.c >>> >>> It turns out that we do not always have to replace SO_REUSEADDR on AIX by >>> SO_REUSEPORT. Instead we can simply use the same approach like BSD and only >>> use SO_REUSEPORT additionally, if several datagram sockets try to bind to >>> the same port. >>> Also fixed a comment and removed unused local variables. >>> Fixed the obviously inverted assignment newTime = prevTime; which should >>> read prevTime = newTime;. Otherwise prevTime will never change and the >>> timeout will be potential reached too fast. >>> >>> src/solaris/native/sun/management/OperatingSystemImpl.c >>> >>> AIX does not understand /proc/self so we have to query the real process ID >>> to access the proc file system. >>> >>> src/solaris/native/sun/nio/ch/DatagramChannelImpl.c >>> >>> On AIX, connect() may legally return EAFNOSUPPORT if called on a socket >>> with the address family set to AF_UNSPEC. >>> >>> >>> >> From alexander.zuev at oracle.com Wed Jan 15 18:51:49 2014 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Wed, 15 Jan 2014 22:51:49 +0400 Subject: JDK9 RFR of JDK-8029646: [pack200] should support the new zip64 format. In-Reply-To: <52D6C6B0.3020508@oracle.com> References: <52D57C2A.4010906@oracle.com> <52D61589.1090901@oracle.com> <52D69A9A.1010506@oracle.com> <52D69C5E.9020407@oracle.com> <52D6A2C1.2000802@oracle.com> <52D6C6B0.3020508@oracle.com> Message-ID: <52D6D8C5.5060308@oracle.com> On 1/15/14 21:34, Xueming Shen wrote: > On 1/15/14 7:01 AM, Alexander Zuev wrote: >> Hello, >> >> the new webrev with all the typos and comments fixed can be found >> at http://cr.openjdk.java.net/~kizune/8029646/webrev.01/ >> >> /Alex > > (1) jarmagic can be just a static constant somewhere or a stack > variable. not big deal though. Ok, i'll see to it. > (2) the test only "tests" EOF for s. there is possibility that the > newly created has more extra > bytes at the end...though in theory this should not happen, it > might be better just add an > extra line to check the sizes of two first first? The test tests for EOF only for s because if s is -1 (EOF) and d is not (more extra bytes in newly created jar) due to the check at line 99 - if (s != d) the exception will be thrown for files content mismatch. > (3) the rest of the change looks good, but I agreed with Kumar that > you may need to add a > regression test for a jar file with > 64k entries. otherwise > the code for zip64 end is not > being tested. the code looks fine, but I would trust a > regression test more than my eyes:-) All right, i'll modify the regression test. /Alex From staffan.larsen at oracle.com Wed Jan 15 19:02:26 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 15 Jan 2014 20:02:26 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <94ABE61E-10BC-407E-92D0-B528165F3460@oracle.com> Message-ID: Yes, that looks like a good solution. /Staffan On 15 jan 2014, at 17:34, Volker Simonis wrote: > Hi Staffan, > > thanks for the review. Please find my comments inline: > > On Wed, Jan 15, 2014 at 9:57 AM, Staffan Larsen wrote: > Volker, > > I?ve look at the following files: > > src/share/native/sun/management/DiagnosticCommandImpl.c: > nit: ?legel? -> ?legal? (two times) > In Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo() if you allow dcmd_info_array to become NULL, then jmm_interface->GetDiagnosticCommandInfo() will throw an NPE and you need to check that. > > Good catch. I actually had problems with malloc returning NULL in 'getDiagnosticCommandArgumentInfoArray()' and then changed all other potentially dangerous locations which used the same pattern. > > However I think if the 'dcmd_info_array' has zero length it would be perfectly fine to return a zero length array. So what about the following solution: > > dcmdInfoCls = (*env)->FindClass(env, > "sun/management/DiagnosticCommandInfo"); > num_commands = (*env)->GetArrayLength(env, commands); > if (num_commands = 0) { > result = (*env)->NewObjectArray(env, 0, dcmdInfoCls, NULL); > if (result == NULL) { > JNU_ThrowOutOfMemoryError(env, 0); > } > else { > return result; > } > } > dcmd_info_array = (dcmdInfo*) malloc(num_commands * sizeof(dcmdInfo)); > if (dcmd_info_array == NULL) { > JNU_ThrowOutOfMemoryError(env, NULL); > } > jmm_interface->GetDiagnosticCommandInfo(env, commands, dcmd_info_array); > result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL); > > That seems easier and saves me from handling the exception. > > What do you think? > > src/solaris/native/sun/management/OperatingSystemImpl.c > No comments. > > src/share/transport/socket/socketTransport.c > No comments. > > src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider > No comments. > > > Thanks, > /Staffan > > > > On 14 jan 2014, at 09:40, Volker Simonis wrote: > >> Hi, >> >> could you please review the following changes for the ppc-aix-port stage/stage-9 repositories (the changes are planned for integration into ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): >> >> http://cr.openjdk.java.net/~simonis/webrevs/8031581/ >> >> I've build and smoke tested without any problems on Linux/x86_64 and PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64. >> >> With these changes (and together with the changes from "8028537: PPC64: Updated jdk/test scripts to understand the AIX os and environment" and "8031134 : PPC64: implement printing on AIX") our port passes all but the following 7 jtreg regression tests on AIX (compared to the Linux/x86_64 baseline from www.java.net/download/jdk8/testresults/testresults.html?): >> >> java/net/Inet6Address/B6558853.java >> java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically) >> java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java >> java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically) >> java/nio/channels/Selector/RacyDeregister.java >> sun/security/krb5/auto/Unreachable.java (only on IPv6) >> >> Thank you and best regards, >> Volker >> >> >> Following a detailed description of the various changes: >> src/share/native/java/util/zip/zip_util.c >> src/share/native/sun/management/DiagnosticCommandImpl.c >> >> According to ISO C it is perfectly legal for malloc to return zero if called with a zero argument. Fix various places where malloc can potentially correctly return zero because it was called with a zero argument. >> Also fixed DiagnosticCommandImpl.c to include stdlib.h. This only fixes a compiler warning on Linux, but on AIX it prevents a VM crash later on because the return value of malloc() will be casted to int which is especially bad if that pointer was bigger than 32-bit. >> make/CompileJavaClasses.gmk >> >> Also use PollingWatchService on AIX. >> make/lib/NioLibraries.gmk >> src/aix/native/sun/nio/ch/AixNativeThread.c >> >> Put the implementation for the native methods of NativeThread into AixNativeThread.c on AIX. >> src/solaris/native/sun/nio/ch/PollArrayWrapper.c >> src/solaris/native/sun/nio/ch/Net.c >> src/aix/classes/sun/nio/ch/AixPollPort.java >> src/aix/native/sun/nio/ch/AixPollPort.c >> src/aix/native/java/net/aix_close.c >> >> On AIX, the constants used for the polling events (i.e. POLLIN, POLLOUT, ...) are defined to different values than on other operating systems. The problem is however, that these constants are hardcoded as public final static members of various, shared Java classes. We therefore have to map them from Java to native every time before calling one of the native poll functions and back to Java after the call on AIX in order to get the right semantics. >> src/share/classes/java/nio/file/CopyMoveHelper.java >> >> As discussed on the core-libs mailing list (see http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024119.html) it is not necessary to call Files.getFileAttributeView() with any linkOptions because at that place we've already checked that the target file can not be a symbolic link. This change makes the implementation more robust on platforms which support symbolic links but do not support the O_NOFOLLOW flag to the open system call. It also makes the JDK pass the demo/zipfs/basic.sh test on AIX. >> src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java >> >> Support "compound text" on AIX in the same way like on other Unix platforms. >> src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider >> >> Define the correct attach provider for AIX. >> src/solaris/native/java/net/net_util_md.h >> src/solaris/native/sun/nio/ch/FileDispatcherImpl.c >> src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c >> >> AIX needs a workaround for I/O cancellation (see: http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/close.htm). "..The close() subroutine is blocked until all subroutines which use the file descriptor return to usr space. For example, when a thread is calling close and another thread is calling select with the same file descriptor, the close subroutine does not return until the select call returns...". To fix this problem, we have to use the various NET_ wrappers which are declared in net_util_md.h and defined in aix_close.c and we also need some additional wrappers for fcntl(), read() and write() on AIX. >> While the current solution isn't really nice because it introduces some more AIX-specifc sections in shared code, I think it is the best way to go for JDK 8 because it imposes the smallest possible changes and risks for the existing platforms. I'm ready to change the code to unconditionally use the wrappers for all platforms and implement the wrappers empty on platforms which don't need any wrapping. I think it would also be nice to clean up the names (e.g. NET_Read() is currently a wrapper for recv() and the NET_ prefix is probably not appropriate any more so maybe change it to something like IO_). But again, I'll prefer to keep that as a follow up change for JDK9. >> Calling fsync() on a "read-only" file descriptor on AIX will result in an error (i.e. "EBADF: The FileDescriptor parameter is not a valid file descriptor open for writing."). To prevent this error we have to query if the corresponding file descriptor is writeable. Notice that at that point we can not access the writable attribute of the corresponding file channel so we have to use fcntl(). >> src/solaris/classes/java/lang/UNIXProcess.java.aix >> >> On AIX the implementation is especially tricky, because the close() system call will block if another thread is at the same time blocked in a file operation (e.g. 'read()') on the same file descriptor. We therefore combine the AIX ProcessPipeInputStream implemenatation with the DeferredCloseInputStream approach used on Solaris (see UNIXProcess.java.solaris). This means that every potentially blocking operation on the file descriptor increments a counter before it is executed and decrements it once it finishes. The 'close()' operation will only be executed if there are no pending operations. Otherwise it is deferred after the last pending operation has finished. >> src/share/transport/socket/socketTransport.c >> >> On AIX we have to call shutdown() on a socket descriptor before closing it, otherwise the close() call may be blocked. This is the same problem as described before. Unfortunately the JDI framework doesn't use the same IO wrappers like other class library components so we can not easily use the NET_ abstractions from aix_close.c here. >> Without this small change all JDI regression tests will fail on AIX because of the way how the tests act as a "debugger" which launches another VM (the "debugge") which connects itself back to the debugger. In this scenario the "debugge" can not shut down itself because one thread will always be blocked in the close() call on one of the communication sockets. >> src/solaris/native/java/net/NetworkInterface.c >> >> Set the scope identifier for IPv6 addresses on AIX. >> src/solaris/native/java/net/net_util_md.c >> >> It turns out that we do not always have to replace SO_REUSEADDR on AIX by SO_REUSEPORT. Instead we can simply use the same approach like BSD and only use SO_REUSEPORT additionally, if several datagram sockets try to bind to the same port. >> Also fixed a comment and removed unused local variables. >> Fixed the obviously inverted assignment newTime = prevTime; which should read prevTime = newTime;. Otherwise prevTime will never change and the timeout will be potential reached too fast. >> src/solaris/native/sun/management/OperatingSystemImpl.c >> >> AIX does not understand /proc/self so we have to query the real process ID to access the proc file system. >> src/solaris/native/sun/nio/ch/DatagramChannelImpl.c >> >> On AIX, connect() may legally return EAFNOSUPPORT if called on a socket with the address family set to AF_UNSPEC. >> > > From staffan.larsen at oracle.com Wed Jan 15 19:03:01 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 15 Jan 2014 20:03:01 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <94ABE61E-10BC-407E-92D0-B528165F3460@oracle.com> Message-ID: <9DE753A4-E6E0-435D-8FB9-5C93CD3184D4@oracle.com> On 15 jan 2014, at 18:27, Volker Simonis wrote: > On Wed, Jan 15, 2014 at 5:34 PM, Volker Simonis > wrote: >> Hi Staffan, >> >> thanks for the review. Please find my comments inline: >> >> On Wed, Jan 15, 2014 at 9:57 AM, Staffan Larsen >> wrote: >>> >>> Volker, >>> >>> I?ve look at the following files: >>> >>> src/share/native/sun/management/DiagnosticCommandImpl.c: >>> nit: ?legel? -> ?legal? (two times) >>> In Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo() if >>> you allow dcmd_info_array to become NULL, then >>> jmm_interface->GetDiagnosticCommandInfo() will throw an NPE and you need to >>> check that. >> >> >> Good catch. I actually had problems with malloc returning NULL in >> 'getDiagnosticCommandArgumentInfoArray()' and then changed all other >> potentially dangerous locations which used the same pattern. >> >> However I think if the 'dcmd_info_array' has zero length it would be >> perfectly fine to return a zero length array. So what about the following >> solution: >> >> dcmdInfoCls = (*env)->FindClass(env, >> "sun/management/DiagnosticCommandInfo"); >> num_commands = (*env)->GetArrayLength(env, commands); > > Sorry, of course I wanted to say "if (num_commands == 0)" here! I understood as much :-) > >> if (num_commands = 0) { >> result = (*env)->NewObjectArray(env, 0, dcmdInfoCls, NULL); >> if (result == NULL) { >> JNU_ThrowOutOfMemoryError(env, 0); >> } >> else { >> return result; >> } >> } >> dcmd_info_array = (dcmdInfo*) malloc(num_commands * sizeof(dcmdInfo)); >> if (dcmd_info_array == NULL) { >> JNU_ThrowOutOfMemoryError(env, NULL); >> } >> jmm_interface->GetDiagnosticCommandInfo(env, commands, dcmd_info_array); >> result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL); >> >> That seems easier and saves me from handling the exception. >> >> What do you think? >> >>> src/solaris/native/sun/management/OperatingSystemImpl.c >>> No comments. >>> >>> src/share/transport/socket/socketTransport.c >>> No comments. >>> >>> >>> src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider >>> No comments. >>> >>> >>> Thanks, >>> /Staffan >>> >>> >>> >>> On 14 jan 2014, at 09:40, Volker Simonis wrote: >>> >>> Hi, >>> >>> could you please review the following changes for the ppc-aix-port >>> stage/stage-9 repositories (the changes are planned for integration into >>> ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/8031581/ >>> >>> I've build and smoke tested without any problems on Linux/x86_64 and >>> PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64. >>> >>> With these changes (and together with the changes from "8028537: PPC64: >>> Updated jdk/test scripts to understand the AIX os and environment" and >>> "8031134 : PPC64: implement printing on AIX") our port passes all but the >>> following 7 jtreg regression tests on AIX (compared to the Linux/x86_64 >>> baseline from www.java.net/download/jdk8/testresults/testresults.html?): >>> >>> java/net/Inet6Address/B6558853.java >>> java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically) >>> java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java >>> java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically) >>> java/nio/channels/Selector/RacyDeregister.java >>> sun/security/krb5/auto/Unreachable.java (only on IPv6) >>> >>> Thank you and best regards, >>> Volker >>> >>> >>> Following a detailed description of the various changes: >>> >>> src/share/native/java/util/zip/zip_util.c >>> src/share/native/sun/management/DiagnosticCommandImpl.c >>> >>> According to ISO C it is perfectly legal for malloc to return zero if >>> called with a zero argument. Fix various places where malloc can potentially >>> correctly return zero because it was called with a zero argument. >>> Also fixed DiagnosticCommandImpl.c to include stdlib.h. This only fixes a >>> compiler warning on Linux, but on AIX it prevents a VM crash later on >>> because the return value of malloc() will be casted to int which is >>> especially bad if that pointer was bigger than 32-bit. >>> >>> make/CompileJavaClasses.gmk >>> >>> Also use PollingWatchService on AIX. >>> >>> make/lib/NioLibraries.gmk >>> src/aix/native/sun/nio/ch/AixNativeThread.c >>> >>> Put the implementation for the native methods of NativeThread into >>> AixNativeThread.c on AIX. >>> >>> src/solaris/native/sun/nio/ch/PollArrayWrapper.c >>> src/solaris/native/sun/nio/ch/Net.c >>> src/aix/classes/sun/nio/ch/AixPollPort.java >>> src/aix/native/sun/nio/ch/AixPollPort.c >>> src/aix/native/java/net/aix_close.c >>> >>> On AIX, the constants used for the polling events (i.e. POLLIN, POLLOUT, >>> ...) are defined to different values than on other operating systems. The >>> problem is however, that these constants are hardcoded as public final >>> static members of various, shared Java classes. We therefore have to map >>> them from Java to native every time before calling one of the native poll >>> functions and back to Java after the call on AIX in order to get the right >>> semantics. >>> >>> src/share/classes/java/nio/file/CopyMoveHelper.java >>> >>> As discussed on the core-libs mailing list (see >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024119.html) >>> it is not necessary to call Files.getFileAttributeView() with any >>> linkOptions because at that place we've already checked that the target file >>> can not be a symbolic link. This change makes the implementation more robust >>> on platforms which support symbolic links but do not support the O_NOFOLLOW >>> flag to the open system call. It also makes the JDK pass the >>> demo/zipfs/basic.sh test on AIX. >>> >>> src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java >>> >>> Support "compound text" on AIX in the same way like on other Unix >>> platforms. >>> >>> >>> src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider >>> >>> Define the correct attach provider for AIX. >>> >>> src/solaris/native/java/net/net_util_md.h >>> src/solaris/native/sun/nio/ch/FileDispatcherImpl.c >>> src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c >>> >>> AIX needs a workaround for I/O cancellation (see: >>> http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/close.htm). >>> "..The close() subroutine is blocked until all subroutines which use the >>> file descriptor return to usr space. For example, when a thread is calling >>> close and another thread is calling select with the same file descriptor, >>> the close subroutine does not return until the select call returns...". To >>> fix this problem, we have to use the various NET_ wrappers which are >>> declared in net_util_md.h and defined in aix_close.c and we also need some >>> additional wrappers for fcntl(), read() and write() on AIX. >>> While the current solution isn't really nice because it introduces some >>> more AIX-specifc sections in shared code, I think it is the best way to go >>> for JDK 8 because it imposes the smallest possible changes and risks for the >>> existing platforms. I'm ready to change the code to unconditionally use the >>> wrappers for all platforms and implement the wrappers empty on platforms >>> which don't need any wrapping. I think it would also be nice to clean up the >>> names (e.g. NET_Read() is currently a wrapper for recv() and the NET_ prefix >>> is probably not appropriate any more so maybe change it to something like >>> IO_). But again, I'll prefer to keep that as a follow up change for JDK9. >>> Calling fsync() on a "read-only" file descriptor on AIX will result in an >>> error (i.e. "EBADF: The FileDescriptor parameter is not a valid file >>> descriptor open for writing."). To prevent this error we have to query if >>> the corresponding file descriptor is writeable. Notice that at that point we >>> can not access the writable attribute of the corresponding file channel so >>> we have to use fcntl(). >>> >>> src/solaris/classes/java/lang/UNIXProcess.java.aix >>> >>> On AIX the implementation is especially tricky, because the close() system >>> call will block if another thread is at the same time blocked in a file >>> operation (e.g. 'read()') on the same file descriptor. We therefore combine >>> the AIX ProcessPipeInputStream implemenatation with the >>> DeferredCloseInputStream approach used on Solaris (see >>> UNIXProcess.java.solaris). This means that every potentially blocking >>> operation on the file descriptor increments a counter before it is executed >>> and decrements it once it finishes. The 'close()' operation will only be >>> executed if there are no pending operations. Otherwise it is deferred after >>> the last pending operation has finished. >>> >>> src/share/transport/socket/socketTransport.c >>> >>> On AIX we have to call shutdown() on a socket descriptor before closing >>> it, otherwise the close() call may be blocked. This is the same problem as >>> described before. Unfortunately the JDI framework doesn't use the same IO >>> wrappers like other class library components so we can not easily use the >>> NET_ abstractions from aix_close.c here. >>> Without this small change all JDI regression tests will fail on AIX >>> because of the way how the tests act as a "debugger" which launches another >>> VM (the "debugge") which connects itself back to the debugger. In this >>> scenario the "debugge" can not shut down itself because one thread will >>> always be blocked in the close() call on one of the communication sockets. >>> >>> src/solaris/native/java/net/NetworkInterface.c >>> >>> Set the scope identifier for IPv6 addresses on AIX. >>> >>> src/solaris/native/java/net/net_util_md.c >>> >>> It turns out that we do not always have to replace SO_REUSEADDR on AIX by >>> SO_REUSEPORT. Instead we can simply use the same approach like BSD and only >>> use SO_REUSEPORT additionally, if several datagram sockets try to bind to >>> the same port. >>> Also fixed a comment and removed unused local variables. >>> Fixed the obviously inverted assignment newTime = prevTime; which should >>> read prevTime = newTime;. Otherwise prevTime will never change and the >>> timeout will be potential reached too fast. >>> >>> src/solaris/native/sun/management/OperatingSystemImpl.c >>> >>> AIX does not understand /proc/self so we have to query the real process ID >>> to access the proc file system. >>> >>> src/solaris/native/sun/nio/ch/DatagramChannelImpl.c >>> >>> On AIX, connect() may legally return EAFNOSUPPORT if called on a socket >>> with the address family set to AF_UNSPEC. From staffan.larsen at oracle.com Wed Jan 15 19:04:50 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 15 Jan 2014 20:04:50 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <94ABE61E-10BC-407E-92D0-B528165F3460@oracle.com> Message-ID: <5F6D2785-23EF-4F43-9E0E-649BEF50F204@oracle.com> On 15 jan 2014, at 18:52, Volker Simonis wrote: > > > On Wed, Jan 15, 2014 at 6:27 PM, Volker Simonis wrote: > > On Wed, Jan 15, 2014 at 5:34 PM, Volker Simonis > > wrote: > >> Hi Staffan, > >> > >> thanks for the review. Please find my comments inline: > >> > >> On Wed, Jan 15, 2014 at 9:57 AM, Staffan Larsen > >> wrote: > >>> > >>> Volker, > >>> > >>> I?ve look at the following files: > >>> > >>> src/share/native/sun/management/DiagnosticCommandImpl.c: > >>> nit: ?legel? -> ?legal? (two times) > >>> In Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo() if > >>> you allow dcmd_info_array to become NULL, then > >>> jmm_interface->GetDiagnosticCommandInfo() will throw an NPE and you need to > >>> check that. > >> > >> > >> Good catch. I actually had problems with malloc returning NULL in > >> 'getDiagnosticCommandArgumentInfoArray()' and then changed all other > >> potentially dangerous locations which used the same pattern. > >> > >> However I think if the 'dcmd_info_array' has zero length it would be > >> perfectly fine to return a zero length array. So what about the following > >> solution: > >> > > Sorry for the noise - it seems I was a little indisposed during the last mails:) > So this is the simple change I'd like to propose for Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo(): > > > @@ -117,19 +119,23 @@ > return NULL; > } > num_commands = (*env)->GetArrayLength(env, commands); > - dcmd_info_array = (dcmdInfo*) malloc(num_commands * > - sizeof(dcmdInfo)); > + dcmdInfoCls = (*env)->FindClass(env, > + "sun/management/DiagnosticCommandInfo"); > + result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL); > + if (result == NULL) { > + JNU_ThrowOutOfMemoryError(env, 0); > + } > + if (num_commands == 0) { > + /* Handle the 'zero commands' case specially to avoid calling 'malloc()' */ > + /* with a zero argument because that may legally return a NULL pointer. */ > + return result; > + } > + dcmd_info_array = (dcmdInfo*) malloc(num_commands * sizeof(dcmdInfo)); > if (dcmd_info_array == NULL) { > JNU_ThrowOutOfMemoryError(env, NULL); > } > jmm_interface->GetDiagnosticCommandInfo(env, commands, dcmd_info_array); > - dcmdInfoCls = (*env)->FindClass(env, > - "sun/management/DiagnosticCommandInfo"); > - result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL); > - if (result == NULL) { > - free(dcmd_info_array); > - JNU_ThrowOutOfMemoryError(env, 0); > - } > for (i=0; i args = getDiagnosticCommandArgumentInfoArray(env, > (*env)->GetObjectArrayElement(env,commands,i), > > If the 'commands' input array is of zero length just return a zero length array. > OK? Yes, this looks good (still :-) ) /Staffan > > >> dcmdInfoCls = (*env)->FindClass(env, > >> "sun/management/DiagnosticCommandInfo"); > >> num_commands = (*env)->GetArrayLength(env, commands); > > > > Sorry, of course I wanted to say "if (num_commands == 0)" here! > > > >> if (num_commands = 0) { > >> result = (*env)->NewObjectArray(env, 0, dcmdInfoCls, NULL); > >> if (result == NULL) { > >> JNU_ThrowOutOfMemoryError(env, 0); > >> } > >> else { > >> return result; > >> } > >> } > >> dcmd_info_array = (dcmdInfo*) malloc(num_commands * sizeof(dcmdInfo)); > >> if (dcmd_info_array == NULL) { > >> JNU_ThrowOutOfMemoryError(env, NULL); > >> } > >> jmm_interface->GetDiagnosticCommandInfo(env, commands, dcmd_info_array); > >> result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL); > >> > >> That seems easier and saves me from handling the exception. > >> > >> What do you think? > >> > >>> src/solaris/native/sun/management/OperatingSystemImpl.c > >>> No comments. > >>> > >>> src/share/transport/socket/socketTransport.c > >>> No comments. > >>> > >>> > >>> src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider > >>> No comments. > >>> > >>> > >>> Thanks, > >>> /Staffan > >>> > >>> > >>> > >>> On 14 jan 2014, at 09:40, Volker Simonis wrote: > >>> > >>> Hi, > >>> > >>> could you please review the following changes for the ppc-aix-port > >>> stage/stage-9 repositories (the changes are planned for integration into > >>> ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): > >>> > >>> http://cr.openjdk.java.net/~simonis/webrevs/8031581/ > >>> > >>> I've build and smoke tested without any problems on Linux/x86_64 and > >>> PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64. > >>> > >>> With these changes (and together with the changes from "8028537: PPC64: > >>> Updated jdk/test scripts to understand the AIX os and environment" and > >>> "8031134 : PPC64: implement printing on AIX") our port passes all but the > >>> following 7 jtreg regression tests on AIX (compared to the Linux/x86_64 > >>> baseline from www.java.net/download/jdk8/testresults/testresults.html?): > >>> > >>> java/net/Inet6Address/B6558853.java > >>> java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically) > >>> java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java > >>> java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically) > >>> java/nio/channels/Selector/RacyDeregister.java > >>> sun/security/krb5/auto/Unreachable.java (only on IPv6) > >>> > >>> Thank you and best regards, > >>> Volker > >>> > >>> > >>> Following a detailed description of the various changes: > >>> > >>> src/share/native/java/util/zip/zip_util.c > >>> src/share/native/sun/management/DiagnosticCommandImpl.c > >>> > >>> According to ISO C it is perfectly legal for malloc to return zero if > >>> called with a zero argument. Fix various places where malloc can potentially > >>> correctly return zero because it was called with a zero argument. > >>> Also fixed DiagnosticCommandImpl.c to include stdlib.h. This only fixes a > >>> compiler warning on Linux, but on AIX it prevents a VM crash later on > >>> because the return value of malloc() will be casted to int which is > >>> especially bad if that pointer was bigger than 32-bit. > >>> > >>> make/CompileJavaClasses.gmk > >>> > >>> Also use PollingWatchService on AIX. > >>> > >>> make/lib/NioLibraries.gmk > >>> src/aix/native/sun/nio/ch/AixNativeThread.c > >>> > >>> Put the implementation for the native methods of NativeThread into > >>> AixNativeThread.c on AIX. > >>> > >>> src/solaris/native/sun/nio/ch/PollArrayWrapper.c > >>> src/solaris/native/sun/nio/ch/Net.c > >>> src/aix/classes/sun/nio/ch/AixPollPort.java > >>> src/aix/native/sun/nio/ch/AixPollPort.c > >>> src/aix/native/java/net/aix_close.c > >>> > >>> On AIX, the constants used for the polling events (i.e. POLLIN, POLLOUT, > >>> ...) are defined to different values than on other operating systems. The > >>> problem is however, that these constants are hardcoded as public final > >>> static members of various, shared Java classes. We therefore have to map > >>> them from Java to native every time before calling one of the native poll > >>> functions and back to Java after the call on AIX in order to get the right > >>> semantics. > >>> > >>> src/share/classes/java/nio/file/CopyMoveHelper.java > >>> > >>> As discussed on the core-libs mailing list (see > >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024119.html) > >>> it is not necessary to call Files.getFileAttributeView() with any > >>> linkOptions because at that place we've already checked that the target file > >>> can not be a symbolic link. This change makes the implementation more robust > >>> on platforms which support symbolic links but do not support the O_NOFOLLOW > >>> flag to the open system call. It also makes the JDK pass the > >>> demo/zipfs/basic.sh test on AIX. > >>> > >>> src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java > >>> > >>> Support "compound text" on AIX in the same way like on other Unix > >>> platforms. > >>> > >>> > >>> src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider > >>> > >>> Define the correct attach provider for AIX. > >>> > >>> src/solaris/native/java/net/net_util_md.h > >>> src/solaris/native/sun/nio/ch/FileDispatcherImpl.c > >>> src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c > >>> > >>> AIX needs a workaround for I/O cancellation (see: > >>> http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/close.htm). > >>> "..The close() subroutine is blocked until all subroutines which use the > >>> file descriptor return to usr space. For example, when a thread is calling > >>> close and another thread is calling select with the same file descriptor, > >>> the close subroutine does not return until the select call returns...". To > >>> fix this problem, we have to use the various NET_ wrappers which are > >>> declared in net_util_md.h and defined in aix_close.c and we also need some > >>> additional wrappers for fcntl(), read() and write() on AIX. > >>> While the current solution isn't really nice because it introduces some > >>> more AIX-specifc sections in shared code, I think it is the best way to go > >>> for JDK 8 because it imposes the smallest possible changes and risks for the > >>> existing platforms. I'm ready to change the code to unconditionally use the > >>> wrappers for all platforms and implement the wrappers empty on platforms > >>> which don't need any wrapping. I think it would also be nice to clean up the > >>> names (e.g. NET_Read() is currently a wrapper for recv() and the NET_ prefix > >>> is probably not appropriate any more so maybe change it to something like > >>> IO_). But again, I'll prefer to keep that as a follow up change for JDK9. > >>> Calling fsync() on a "read-only" file descriptor on AIX will result in an > >>> error (i.e. "EBADF: The FileDescriptor parameter is not a valid file > >>> descriptor open for writing."). To prevent this error we have to query if > >>> the corresponding file descriptor is writeable. Notice that at that point we > >>> can not access the writable attribute of the corresponding file channel so > >>> we have to use fcntl(). > >>> > >>> src/solaris/classes/java/lang/UNIXProcess.java.aix > >>> > >>> On AIX the implementation is especially tricky, because the close() system > >>> call will block if another thread is at the same time blocked in a file > >>> operation (e.g. 'read()') on the same file descriptor. We therefore combine > >>> the AIX ProcessPipeInputStream implemenatation with the > >>> DeferredCloseInputStream approach used on Solaris (see > >>> UNIXProcess.java.solaris). This means that every potentially blocking > >>> operation on the file descriptor increments a counter before it is executed > >>> and decrements it once it finishes. The 'close()' operation will only be > >>> executed if there are no pending operations. Otherwise it is deferred after > >>> the last pending operation has finished. > >>> > >>> src/share/transport/socket/socketTransport.c > >>> > >>> On AIX we have to call shutdown() on a socket descriptor before closing > >>> it, otherwise the close() call may be blocked. This is the same problem as > >>> described before. Unfortunately the JDI framework doesn't use the same IO > >>> wrappers like other class library components so we can not easily use the > >>> NET_ abstractions from aix_close.c here. > >>> Without this small change all JDI regression tests will fail on AIX > >>> because of the way how the tests act as a "debugger" which launches another > >>> VM (the "debugge") which connects itself back to the debugger. In this > >>> scenario the "debugge" can not shut down itself because one thread will > >>> always be blocked in the close() call on one of the communication sockets. > >>> > >>> src/solaris/native/java/net/NetworkInterface.c > >>> > >>> Set the scope identifier for IPv6 addresses on AIX. > >>> > >>> src/solaris/native/java/net/net_util_md.c > >>> > >>> It turns out that we do not always have to replace SO_REUSEADDR on AIX by > >>> SO_REUSEPORT. Instead we can simply use the same approach like BSD and only > >>> use SO_REUSEPORT additionally, if several datagram sockets try to bind to > >>> the same port. > >>> Also fixed a comment and removed unused local variables. > >>> Fixed the obviously inverted assignment newTime = prevTime; which should > >>> read prevTime = newTime;. Otherwise prevTime will never change and the > >>> timeout will be potential reached too fast. > >>> > >>> src/solaris/native/sun/management/OperatingSystemImpl.c > >>> > >>> AIX does not understand /proc/self so we have to query the real process ID > >>> to access the proc file system. > >>> > >>> src/solaris/native/sun/nio/ch/DatagramChannelImpl.c > >>> > >>> On AIX, connect() may legally return EAFNOSUPPORT if called on a socket > >>> with the address family set to AF_UNSPEC. > >>> > >>> > >>> > >> From vladimir.x.ivanov at oracle.com Wed Jan 15 19:41:09 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 15 Jan 2014 23:41:09 +0400 Subject: [JDK8] RFR (XS): JSR292: IncompatibleClassChangeError in LambdaForm for CharSequence.toString() method handle type converter In-Reply-To: <0DA570E9-814A-44B5-8CDA-6F7C9A92B423@oracle.com> References: <52D6A9B8.2040906@oracle.com> <0DA570E9-814A-44B5-8CDA-6F7C9A92B423@oracle.com> Message-ID: <52D6E455.4050607@oracle.com> Chris, Thanks for looking into this. See my answers inline. Best regards, Vladimir Ivanov On 1/15/14 9:51 PM, Christian Thalinger wrote: > [I?m resending something I sent earlier today to Vladimir directly.] > > On Jan 15, 2014, at 7:31 AM, Vladimir Ivanov wrote: > >> http://cr.openjdk.java.net/~vlivanov/8031502/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8031502 >> >> InvokeBytecodeGenerator can produce incorrect bytecode for a LambdaForm >> when invoking a method from Object declared in an interface. >> >> The problem is the following: >> (1) java.lang.CharSequence interface declares abstract method "String >> toString()"; >> >> (2) after 8014013 fix, VM resolves >> CharSequence::toString()/invokeInterface to >> CharSequence::toString()/invokeVirtual; > > Without having looked at the changes of 8014013, why did the invoke type change? Is it an optimization that was added? > After 8014013, LinkResolver::resolve_interface_call returns virtual (_call_kind = CallInfo::vtable_call), instead of interface method and MethodHandles::init_method_MemberName uses it as is (without any fine tuning, which was done before). It's caused by the following: - LinkResolver::linktime_resolve_interface_method returns CharSequence::toString method, but it has vtable index, instead of itable index; - LinkResolver::runtime_resolve_interface_method looks at resolved method and sets _call_kind to vtable_call, since resolved method doesn't have itable index. - then MethodHandles::init_method_MemberName looks at CallInfo passed in and sets the reference kind flag to JVM_REF_invokeVirtual. That's how the conversion from invokeInterface to invokeVirtual occurs. I did a quick debugging session with pre-8014013 hotspot to check how it worked before, but don't remember all the details now. >> >> (3) during LambdaForm compilation, CharSequence is considered >> statically invocable (see >> InvokeBytecodeGenerator::isStaticallyInvocable) and invokevirtual for >> CharSequence::toString() is issued, which is wrong (invokevirtual throws >> ICCE if it references an interface); >> >> The fix is straightforward: during LambdaForm compilation, switch back >> from invokevirtual to invokeinterface instruction when invoking a method >> on an interface. > > I find this risky. Right now MemberName is only used in a couple places in java.lang.invoke but in the future it might be used for other things (e.g. java.lang.reflect). The information MemberName contains should be correct and usable without changing. Otherwise all users have to patch the information the same way as you do in your patch. > > I would like to see the VM passing correct information (whatever the definition of correct is here). > It's an interesting question what kind of correctness is required for MemberName and I don't know the answer. Looking through the code, I got an impression MemberName isn't designed to provide information to be used "as is" for bytecode generation, because, at least: - MemberName::referenceKindIsConsistent already expects (clazz.isInterface() && refKind == REF_invokeVirtual && isObjectPublicMethod()) case; - InvokeBytecodeGenerator::emitStaticInvoke already has a special case for REF_invokeSpecial referenceKind, converting it to REF_invokeVirtual; Best regards, Vladimir Ivanov From roger.riggs at oracle.com Wed Jan 15 20:52:12 2014 From: roger.riggs at oracle.com (roger riggs) Date: Wed, 15 Jan 2014 15:52:12 -0500 Subject: RFR: (8030875) Macros for checking and returning on exceptions In-Reply-To: References: <52D013B9.40101@oracle.com> <52D4A642.7090404@oracle.com> <52D55DBD.3030502@oracle.com> Message-ID: <52D6F4FC.3040209@oracle.com> Hi Martin, A followup, what is the subtlety that makes it beneficial to wrap even a single statement in a do {} while (0)? It makes sense for macros with multiple statements but not for a single statement substitution of expressions. For a single statement (w/o ';'), it seems like a redundant overhead that does not solve an issue. Thanks, Roger On 1/14/2014 5:20 PM, Martin Buchholz wrote: > > > > On Tue, Jan 14, 2014 at 7:54 AM, roger riggs > wrote: > > Hi David, > > The CHECK_RETURN macros have existed in java.net > for some time and > I have not seen any empty statement warnings. > > The CHECK_EXCEPTION macros are new and does not have any uses yet. > I don't plan to do any wholesale modification of current sources. > > The macros always produce a valid statement; (though my c/c++ may > be a bit rusty). > > > Macros should not generally be complete statements, including > semicolons; then the source code looks like this: > > FOO() > > which looks (including to emacs) like someone forgot the trailing > semicolon. > > Instead, these macros should be written using the "well-known" do ( > ... ) while (0) idiom, e.g. > > #define CHECK_NULL(x) do { if ((x) == NULL) return; } while (0) > > (Note that it has been requested to rename the macros to include a > JNU_prefix > to be consistent with other macros in jni_util.h. I will propose a > separate set of changes for that). > > Roger > > > On 1/13/2014 9:51 PM, David Holmes wrote: > > Hi Roger, > > > webrev: > http://cr.openjdk.java.net/~rriggs/webrev-check-exception-8030875/ > > > > Do these macro definitions not cause "empty statement" > warnings from the compiler? (Existing ones have the same > problem I guess) > > Also I don't see any use of the CHECK_EXCEPTION macros? In > fact the bulk of changes here seem completely unrelated to the > "exception" aspect of this CR. > > Cheers, > David > > [1] https://bugs.openjdk.java.net/browse/JDK-8030875 > > > From martinrb at google.com Wed Jan 15 21:13:22 2014 From: martinrb at google.com (Martin Buchholz) Date: Wed, 15 Jan 2014 13:13:22 -0800 Subject: RFR: (8030875) Macros for checking and returning on exceptions In-Reply-To: <52D6F4FC.3040209@oracle.com> References: <52D013B9.40101@oracle.com> <52D4A642.7090404@oracle.com> <52D55DBD.3030502@oracle.com> <52D6F4FC.3040209@oracle.com> Message-ID: On Wed, Jan 15, 2014 at 12:52 PM, roger riggs wrote: > Hi Martin, > > A followup, what is the subtlety that makes it beneficial to wrap > even a single statement in a do {} while (0)? > > It ensures that a macro call FOO() has the same semantics as a regular non-macro void function call, e.g. FOO() is an unfinished statement until the terminating semicolon is added. > It makes sense for macros with multiple statements but not for a single > statement substitution of expressions. > > For a single statement (w/o ';'), it seems like a redundant overhead > that does not solve an issue. > > If your compiler cannot optimize away while (false) it might be time to get a new one. > Thanks, Roger > > > On 1/14/2014 5:20 PM, Martin Buchholz wrote: > > > > > On Tue, Jan 14, 2014 at 7:54 AM, roger riggs wrote: > >> Hi David, >> >> The CHECK_RETURN macros have existed in java.net for some time and >> I have not seen any empty statement warnings. >> >> The CHECK_EXCEPTION macros are new and does not have any uses yet. >> I don't plan to do any wholesale modification of current sources. >> >> The macros always produce a valid statement; (though my c/c++ may be a >> bit rusty). >> >> > Macros should not generally be complete statements, including > semicolons; then the source code looks like this: > > FOO() > > which looks (including to emacs) like someone forgot the trailing > semicolon. > > Instead, these macros should be written using the "well-known" do ( ... > ) while (0) idiom, e.g. > > #define CHECK_NULL(x) do { if ((x) == NULL) return; } while (0) > > >> (Note that it has been requested to rename the macros to include a >> JNU_prefix >> to be consistent with other macros in jni_util.h. I will propose a >> separate set of changes for that). >> >> Roger >> >> >> On 1/13/2014 9:51 PM, David Holmes wrote: >> >>> Hi Roger, >>> >>> >>> webrev: >>>> http://cr.openjdk.java.net/~rriggs/webrev-check-exception-8030875/ >>>> >>> >>> Do these macro definitions not cause "empty statement" warnings from the >>> compiler? (Existing ones have the same problem I guess) >>> >>> Also I don't see any use of the CHECK_EXCEPTION macros? In fact the bulk >>> of changes here seem completely unrelated to the "exception" aspect of this >>> CR. >>> >>> Cheers, >>> David >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8030875 >>>> >>> >> > > From brian.burkhalter at oracle.com Wed Jan 15 21:28:41 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 15 Jan 2014 13:28:41 -0800 Subject: JDK 9 RFC on 6667086: Double.doubleToLongBits(final double value) contains inefficient test for NaN Message-ID: Issue: https://bugs.openjdk.java.net/browse/JDK-6667086 Webrev: http://cr.openjdk.java.net/~bpb/6667086/webrev/ According to micro-benckmarks, there is no statistically significant performance change due to applying this patch but the code definitely looks cleaner. Thanks, Brian From kumar.x.srinivasan at oracle.com Wed Jan 15 23:21:08 2014 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 15 Jan 2014 15:21:08 -0800 Subject: JDK9 RFR of JDK-8029646: [pack200] should support the new zip64 format. In-Reply-To: <52D6A172.6050003@oracle.com> References: <52D57C2A.4010906@oracle.com> <52D5B5BF.2010104@oracle.com> <52D6A172.6050003@oracle.com> Message-ID: <52D717E4.9080702@oracle.com> Hi Alex, > Kumar, > > thanks for your findings. See my comments inline. > > On 1/15/14 2:10, Kumar Srinivasan wrote: >> Hi Alex, >> >> zip.cpp: (nit) I would keep the hex values to be in upper case just >> like the others for >> consistency, not a big deal. > Fixed. >> >> typo: + // Zip64 END sugnature > Also fixed. >> >> >> PackTestZip64.java: shouldn't we test a jar with 64K+ entries ? > Do we really have to do so? Creating, repacking, packing, unpacking > and comparing of such jar > file would take a lot of testing time. Right now i'm just testing that > we are producing binary > identical jar after we normalized it. If you think creating of large > jar file is necessary i can easily do so. We must have a test!, it is not necessary that we should execute this all the time, but having this in place, will enable SQ to run this test periodically, and we can run it as well during development. You can copy most of the logic from here, and use the system property/strategy to enable the time consuming one. http://hg.openjdk.java.net/jdk9/dev/jdk/file/3b4ac8d1b76f/test/tools/launcher/BigJar.java I think it would be good to test jars created by the JDK (tools.jar or some suitable one), using the golden jar may not be appropriate, since it is a pre-canned binary. Also I am not sure if we should test jars created by JarOutputStream as well as JarFile, there are some nuances with these APIs and how they write out the jar file. Kumar > > /Alex >> >> Kumar >> >> >> >> On 1/14/2014 10:04 AM, Alexander Zuev wrote: >>> Please review my fix for >>> JDK-8029646: [pack200] should support the new zip64 format. >>> >>> The fix can be found at >>> http://cr.openjdk.java.net/~kizune/8029646/webrev.00/ >>> >>> Bug description is: https://bugs.openjdk.java.net/browse/JDK-8029646 >>> >>> /Alex >> > From srikalyan.chandrashekar at oracle.com Thu Jan 16 00:19:03 2014 From: srikalyan.chandrashekar at oracle.com (srikalyan chandrashekar) Date: Wed, 15 Jan 2014 16:19:03 -0800 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52D47D59.8040905@oracle.com> References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> <52CC72AB.2020104@oracle.com> <52CCEDE0.8000809@oracle.com> <52CCF079.4090301@oracle.com> <52CD45E7.7010203@gmail.com> <52CE4E2D.300@oracle.com> <52CF37C6.1070605@oracle.com> <52CFAFEB.9090703@gmail.com> <52CFD218.2060101@gmail.com> <52D06B70.60001@oracle.com> <52D15201.90109@gmail.com> <52D47D59.8040905@oracle.com> Message-ID: <52D72577.1050506@oracle.com> Hi Peter/David, we could finally get a trace of exception with fastdebug build and ReferenceHandler modified (with runImpl() added and called from run()). The logs, disassembled code is available in JIRA as attachments. Observations from the log: Root Cause: 1) UncaughtException is being dispatched from Reference.java:143 141 Reference r; 142 synchronized (lock) { 143 if (pending != null) { 144 r = pending; 145 pending = r.discovered; 146 r.discovered = null; pending field in Reference is touched and updated by the collector, so at line 143 when the execution context is in Reference handler there might have been an Exception pending due to allocation done by collector which causes ReferenceHandler thread to die. Suggested fix: - As proposed earlier putting an outer guard(try-catch on OOME) in the ReferenceHandler will fix the issue, if ReferenceHandler is considered as part of the GC sub system then it should be alive even in the midst of an OOME so i feel that the additional guard should be allowed, however i might still be ignorant of vital implications. - Apart from the above changes, Peter's suggestion to create and call a private runImpl() from run() in ReferenceHandler makes sense to me. --- Thanks kalyan On 01/13/2014 03:57 PM, srikalyan wrote: > > On 1/11/14, 6:15 AM, Peter Levart wrote: >> >> On 01/10/2014 10:51 PM, srikalyan chandrashekar wrote: >>> Hi Peter the version you provided ran indefinitely(i put a 10 minute >>> timeout) and the program got interrupted(no error), >> >> Did you run it with or without fastedbug & -XX:+TraceExceptions ? If >> with, it might be that fastdebug and/or -XX:+TraceExceptions changes >> the execution a bit so that we can no longer reproduce the wrong >> behaviour. > With fastdebug & -XX:TraceExceptions. I will try combination of > possible options(i.e without -XX:TraceEception on debug build etc) soon. >> >>> even if there were to be an error you cannot print the "string" of >>> thread to console(these have been attempted earlier). >> >> ...it has been attempted to print toString in uncaught exception >> handler. At that time, the heap is still full. I'm printing it after >> the GC has cleared the heap. You can try that it works by commenting >> out the "try {" and corresponding "} catch (OOME x) {}" exception >> handler... > Since there is a GC call prior to printing string i will give that a > shot with non-debug build. >> >>> - The test's running on interpreter mode, what i am watching for is >>> one error with trace. Without fastdebug build and >>> -XX:+TraceExceptions i am able to reproduce failure atleast 5 >>> failures out of 1000 runs but with fastdebug+Trace no luck >>> yet(already past few 1000 runs). >> >> It might be interesting to try with fastebug build but without the >> -XX:+TraceExceptions option to see what has an effect on it. It might >> also be interesting to try the modified ReferenceHandler (the one >> with private runImpl() method called from run()) and with normal >> non-fastdebug JDK. This info might be useful when one starts to >> inspect the exception handling code in interpreter... >> >> Regards, Peter >> > > -- > Thanks > kalyan > Ph: (408)-585-8040 > >>> >>> --- >>> Thanks >>> kalyan >>> >>> On 01/10/2014 02:57 AM, Peter Levart wrote: >>>> On 01/10/2014 09:31 AM, Peter Levart wrote: >>>>> Since we suspect there's something wrong with exception handling >>>>> in interpreter, I devised a hypothetical reproducer that tries to >>>>> simulate ReferenceHandler in many aspects, but doesn't require to >>>>> be a ReferenceHandler: >>>>> >>>>> http://cr.openjdk.java.net/~plevart/misc/OOME/OOMECatchingTest.java >>>>> >>>>> This is designed to run indefinitely and only terminate if/when >>>>> thread dies. Could you run this program in the environment that >>>>> causes the OOMEInReferenceHandler test to fail and see if it >>>>> terminates? >>>> >>>> I forgot to mention that in order for this long-running program to >>>> exhibit interpreter behaviour, it should be run with -Xint option. >>>> So I suggest: >>>> >>>> -Xmx24M -XX:-UseTLAB -Xint >>>> >>>> Regards, Peter >>>> >>> >> From mandy.chung at oracle.com Thu Jan 16 01:27:35 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 15 Jan 2014 17:27:35 -0800 Subject: Review request for JDK-6760902: inconsistent behavior in bootstrap class loader for classes and resources Message-ID: <52D73587.30104@oracle.com> There is an inconsistency in searching classes vs resources if bootclasspath contains an empty path. Empty path on bootclasspath is skipped by the bootstrap class loader when searching classes while it defaults to current working directory when searching resources as the application class loader. This fixes sun.misc.Launcher to skip empty path when constructing the paths from bootclasspath for resource lookup. Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/6760902/webrev.00/ There is some incompatibility risk that may impact existing code depending on this behavior to search resources from the current working directory if empty path (rather than explicit) is set. I think most application using bootclasspath is to add their paths to load their classes and likely expect the resources are looked in the consistent way (i.e. skips the empty path). So I expect the incompatibility risk is low. thanks Mandy From christian.thalinger at oracle.com Thu Jan 16 02:49:30 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 15 Jan 2014 18:49:30 -0800 Subject: [JDK8] RFR (XS): JSR292: IncompatibleClassChangeError in LambdaForm for CharSequence.toString() method handle type converter In-Reply-To: <52D6E455.4050607@oracle.com> References: <52D6A9B8.2040906@oracle.com> <0DA570E9-814A-44B5-8CDA-6F7C9A92B423@oracle.com> <52D6E455.4050607@oracle.com> Message-ID: On Jan 15, 2014, at 11:41 AM, Vladimir Ivanov wrote: > Chris, > > Thanks for looking into this. See my answers inline. > > Best regards, > Vladimir Ivanov > > On 1/15/14 9:51 PM, Christian Thalinger wrote: >> [I?m resending something I sent earlier today to Vladimir directly.] >> >> On Jan 15, 2014, at 7:31 AM, Vladimir Ivanov wrote: >> >>> http://cr.openjdk.java.net/~vlivanov/8031502/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8031502 >>> >>> InvokeBytecodeGenerator can produce incorrect bytecode for a LambdaForm >>> when invoking a method from Object declared in an interface. >>> >>> The problem is the following: >>> (1) java.lang.CharSequence interface declares abstract method "String >>> toString()"; >>> >>> (2) after 8014013 fix, VM resolves >>> CharSequence::toString()/invokeInterface to >>> CharSequence::toString()/invokeVirtual; >> >> Without having looked at the changes of 8014013, why did the invoke type change? Is it an optimization that was added? >> > > After 8014013, LinkResolver::resolve_interface_call returns virtual > (_call_kind = CallInfo::vtable_call), instead of interface method and > MethodHandles::init_method_MemberName uses it as is (without any fine > tuning, which was done before). > > It's caused by the following: > - LinkResolver::linktime_resolve_interface_method returns > CharSequence::toString method, but it has vtable index, instead of > itable index; > > - LinkResolver::runtime_resolve_interface_method looks at resolved > method and sets _call_kind to vtable_call, since resolved method doesn't > have itable index. > > - then MethodHandles::init_method_MemberName looks at CallInfo passed > in and sets the reference kind flag to JVM_REF_invokeVirtual. > > That's how the conversion from invokeInterface to invokeVirtual occurs. > > I did a quick debugging session with pre-8014013 hotspot to check how it > worked before, but don't remember all the details now. > >>> >>> (3) during LambdaForm compilation, CharSequence is considered >>> statically invocable (see >>> InvokeBytecodeGenerator::isStaticallyInvocable) and invokevirtual for >>> CharSequence::toString() is issued, which is wrong (invokevirtual throws >>> ICCE if it references an interface); >>> >>> The fix is straightforward: during LambdaForm compilation, switch back >>> from invokevirtual to invokeinterface instruction when invoking a method >>> on an interface. >> >> I find this risky. Right now MemberName is only used in a couple places in java.lang.invoke but in the future it might be used for other things (e.g. java.lang.reflect). The information MemberName contains should be correct and usable without changing. Otherwise all users have to patch the information the same way as you do in your patch. >> >> I would like to see the VM passing correct information (whatever the definition of correct is here). >> > > It's an interesting question what kind of correctness is required for > MemberName and I don't know the answer. Looking through the code, I got > an impression MemberName isn't designed to provide information to be > used "as is" for bytecode generation, because, at least: > - MemberName::referenceKindIsConsistent already expects > (clazz.isInterface() && refKind == REF_invokeVirtual && > isObjectPublicMethod()) case; > > - InvokeBytecodeGenerator::emitStaticInvoke already has a special > case for REF_invokeSpecial referenceKind, converting it to > REF_invokeVirtual; John would know the answer. Given this change should go into JDK 8 I think we should push for now. If we can come up with a better way to handle these situations we can push another change for 9 or 8u20. > > Best regards, > Vladimir Ivanov > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From Roger.Riggs at Oracle.com Thu Jan 16 03:22:46 2014 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 15 Jan 2014 22:22:46 -0500 Subject: RFR 8031961 ProcessBuilder.Basic should use NIO Files to copy files Message-ID: <52D75086.5050200@Oracle.com> Please review this minor test improvement to replace spawning /bin/cp to copy files with NIO Files.copy. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-process-cp-8031961/ Thanks, Roger [1] https://bugs.openjdk.java.net/browse/JDK-8031961 From david.holmes at oracle.com Thu Jan 16 05:04:25 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 Jan 2014 15:04:25 +1000 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52D72577.1050506@oracle.com> References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> <52CC72AB.2020104@oracle.com> <52CCEDE0.8000809@oracle.com> <52CCF079.4090301@oracle.com> <52CD45E7.7010203@gmail.com> <52CE4E2D.300@oracle.com> <52CF37C6.1070605@oracle.com> <52CFAFEB.9090703@gmail.com> <52CFD218.2060101@gmail.com> <52D06B70.60001@oracle.com> <52D15201.90109@gmail.com> <52D47D59.8040905@oracle.com> <52D72577.1050506@oracle.com> Message-ID: <52D76859.2030502@oracle.com> On 16/01/2014 10:19 AM, srikalyan chandrashekar wrote: > Hi Peter/David, we could finally get a trace of exception with fastdebug > build and ReferenceHandler modified (with runImpl() added and called > from run()). The logs, disassembled code is available in JIRA > as attachments. All I can see is the log for the OOMECatchingTest program not one for the actual ReferenceHandler ?? > Observations from the log: > > Root Cause: > 1) UncaughtException is being dispatched from Reference.java:143 > 141 Reference r; > 142 synchronized (lock) { > 143 if (pending != null) { > 144 r = pending; > 145 pending = r.discovered; > 146 r.discovered = null; > > pending field in Reference is touched and updated by the collector, so > at line 143 when the execution context is in Reference handler there > might have been an Exception pending due to allocation done by collector > which causes ReferenceHandler thread to die. Sorry but the GC does not trigger asynchronous exceptions so this explanation does not make any sense to me. What part of the log led you to this conclusion? > Suggested fix: > - As proposed earlier putting an outer guard(try-catch on OOME) in the > ReferenceHandler will fix the issue, if ReferenceHandler is considered > as part of the GC sub system then it should be alive even in the midst > of an OOME so i feel that the additional guard should be allowed, > however i might still be ignorant of vital implications. > - Apart from the above changes, Peter's suggestion to create and call a > private runImpl() from run() in ReferenceHandler makes sense to me. Why would we need this? David ----- > > --- > Thanks > kalyan > > On 01/13/2014 03:57 PM, srikalyan wrote: >> >> On 1/11/14, 6:15 AM, Peter Levart wrote: >>> >>> On 01/10/2014 10:51 PM, srikalyan chandrashekar wrote: >>>> Hi Peter the version you provided ran indefinitely(i put a 10 minute >>>> timeout) and the program got interrupted(no error), >>> >>> Did you run it with or without fastedbug & -XX:+TraceExceptions ? If >>> with, it might be that fastdebug and/or -XX:+TraceExceptions changes >>> the execution a bit so that we can no longer reproduce the wrong >>> behaviour. >> With fastdebug & -XX:TraceExceptions. I will try combination of >> possible options(i.e without -XX:TraceEception on debug build etc) soon. >>> >>>> even if there were to be an error you cannot print the "string" of >>>> thread to console(these have been attempted earlier). >>> >>> ...it has been attempted to print toString in uncaught exception >>> handler. At that time, the heap is still full. I'm printing it after >>> the GC has cleared the heap. You can try that it works by commenting >>> out the "try {" and corresponding "} catch (OOME x) {}" exception >>> handler... >> Since there is a GC call prior to printing string i will give that a >> shot with non-debug build. >>> >>>> - The test's running on interpreter mode, what i am watching for is >>>> one error with trace. Without fastdebug build and >>>> -XX:+TraceExceptions i am able to reproduce failure atleast 5 >>>> failures out of 1000 runs but with fastdebug+Trace no luck >>>> yet(already past few 1000 runs). >>> >>> It might be interesting to try with fastebug build but without the >>> -XX:+TraceExceptions option to see what has an effect on it. It might >>> also be interesting to try the modified ReferenceHandler (the one >>> with private runImpl() method called from run()) and with normal >>> non-fastdebug JDK. This info might be useful when one starts to >>> inspect the exception handling code in interpreter... >>> >>> Regards, Peter >>> >> >> -- >> Thanks >> kalyan >> Ph: (408)-585-8040 >> >>>> >>>> --- >>>> Thanks >>>> kalyan >>>> >>>> On 01/10/2014 02:57 AM, Peter Levart wrote: >>>>> On 01/10/2014 09:31 AM, Peter Levart wrote: >>>>>> Since we suspect there's something wrong with exception handling >>>>>> in interpreter, I devised a hypothetical reproducer that tries to >>>>>> simulate ReferenceHandler in many aspects, but doesn't require to >>>>>> be a ReferenceHandler: >>>>>> >>>>>> http://cr.openjdk.java.net/~plevart/misc/OOME/OOMECatchingTest.java >>>>>> >>>>>> This is designed to run indefinitely and only terminate if/when >>>>>> thread dies. Could you run this program in the environment that >>>>>> causes the OOMEInReferenceHandler test to fail and see if it >>>>>> terminates? >>>>> >>>>> I forgot to mention that in order for this long-running program to >>>>> exhibit interpreter behaviour, it should be run with -Xint option. >>>>> So I suggest: >>>>> >>>>> -Xmx24M -XX:-UseTLAB -Xint >>>>> >>>>> Regards, Peter >>>>> >>>> >>> > From martinrb at google.com Thu Jan 16 05:12:59 2014 From: martinrb at google.com (Martin Buchholz) Date: Wed, 15 Jan 2014 21:12:59 -0800 Subject: RFR 8031961 ProcessBuilder.Basic should use NIO Files to copy files In-Reply-To: <52D75086.5050200@Oracle.com> References: <52D75086.5050200@Oracle.com> Message-ID: Looks Good To Me! On Wed, Jan 15, 2014 at 7:22 PM, Roger Riggs wrote: > Please review this minor test improvement to replace spawning /bin/cp > to copy files with NIO Files.copy. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-process-cp-8031961/ > > Thanks, Roger > > [1] https://bugs.openjdk.java.net/browse/JDK-8031961 > From blackdrag at gmx.org Thu Jan 16 08:40:32 2014 From: blackdrag at gmx.org (Jochen Theodorou) Date: Thu, 16 Jan 2014 09:40:32 +0100 Subject: [JDK8] RFR (XS): JSR292: IncompatibleClassChangeError in LambdaForm for CharSequence.toString() method handle type converter In-Reply-To: <52D6A9B8.2040906@oracle.com> References: <52D6A9B8.2040906@oracle.com> Message-ID: <52D79B00.5080804@gmx.org> Hi, since I am indirectly the reporter of this bug I have one remark for the test. The error happens only for compiled lambda forms. The given test does imho not use a compiled lambda form. In other words, afaik the test would pass without the fix. As such it would be useless as regression test. Am 15.01.2014 16:31, schrieb Vladimir Ivanov: > http://cr.openjdk.java.net/~vlivanov/8031502/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8031502 > > InvokeBytecodeGenerator can produce incorrect bytecode for a LambdaForm > when invoking a method from Object declared in an interface. > > The problem is the following: > (1) java.lang.CharSequence interface declares abstract method "String > toString()"; > > (2) after 8014013 fix, VM resolves > CharSequence::toString()/invokeInterface to > CharSequence::toString()/invokeVirtual; > > (3) during LambdaForm compilation, CharSequence is considered > statically invocable (see > InvokeBytecodeGenerator::isStaticallyInvocable) and invokevirtual for > CharSequence::toString() is issued, which is wrong (invokevirtual throws > ICCE if it references an interface); > > The fix is straightforward: during LambdaForm compilation, switch back > from invokevirtual to invokeinterface instruction when invoking a method > on an interface. > > The fix is targeted for 8. Will be also integrated into 9. > > Testing: regression test, jdk/test/java/lang/invoke, vm.mlvm.testlist, > nashorn, jruby. > > Thanks! > > Best regards, > Vladimir Ivanov > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org From Alan.Bateman at oracle.com Thu Jan 16 08:45:49 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 16 Jan 2014 08:45:49 +0000 Subject: RFR 8031961 ProcessBuilder.Basic should use NIO Files to copy files In-Reply-To: <52D75086.5050200@Oracle.com> References: <52D75086.5050200@Oracle.com> Message-ID: <52D79C3D.8010300@oracle.com> On 16/01/2014 03:22, Roger Riggs wrote: > Please review this minor test improvement to replace spawning /bin/cp > to copy files with NIO Files.copy. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-process-cp-8031961/ Just looking at JDK-6686751 and it's not clear what the issue was with -p. I assume we want the permissions copied (so COPY_ATTRIBUTES is right), it's just not clear what the "Invalid argument" was about and whether this was an older version of Solaris or a cp version that didn't support these options? -Alan. From sundararajan.athijegannathan at oracle.com Thu Jan 16 08:48:36 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 16 Jan 2014 14:18:36 +0530 Subject: [JDK8] RFR (XS): JSR292: IncompatibleClassChangeError in LambdaForm for CharSequence.toString() method handle type converter In-Reply-To: <52D79B00.5080804@gmx.org> References: <52D6A9B8.2040906@oracle.com> <52D79B00.5080804@gmx.org> Message-ID: <52D79CE4.3010409@oracle.com> The test sets compile threshold to be zero (-Djava.lang.invoke.MethodHandle.COMPILE_THRESHOLD=0 ). I think compilation occurs on the first invoke. Also, I ran the test on a jdk8 build without Vladimir's fix - I saw the exception being thrown. I ran it by passing the above option in the command line (outside jtreg). -Sundar On Thursday 16 January 2014 02:10 PM, Jochen Theodorou wrote: > Hi, > > since I am indirectly the reporter of this bug I have one remark for > the test. The error happens only for compiled lambda forms. The given > test does imho not use a compiled lambda form. In other words, afaik > the test would pass without the fix. As such it would be useless as > regression test. > > Am 15.01.2014 16:31, schrieb Vladimir Ivanov: >> http://cr.openjdk.java.net/~vlivanov/8031502/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8031502 >> >> InvokeBytecodeGenerator can produce incorrect bytecode for a LambdaForm >> when invoking a method from Object declared in an interface. >> >> The problem is the following: >> (1) java.lang.CharSequence interface declares abstract method >> "String >> toString()"; >> >> (2) after 8014013 fix, VM resolves >> CharSequence::toString()/invokeInterface to >> CharSequence::toString()/invokeVirtual; >> >> (3) during LambdaForm compilation, CharSequence is considered >> statically invocable (see >> InvokeBytecodeGenerator::isStaticallyInvocable) and invokevirtual for >> CharSequence::toString() is issued, which is wrong (invokevirtual throws >> ICCE if it references an interface); >> >> The fix is straightforward: during LambdaForm compilation, switch back >> from invokevirtual to invokeinterface instruction when invoking a method >> on an interface. >> >> The fix is targeted for 8. Will be also integrated into 9. >> >> Testing: regression test, jdk/test/java/lang/invoke, vm.mlvm.testlist, >> nashorn, jruby. >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> > > From blackdrag at gmx.org Thu Jan 16 08:52:51 2014 From: blackdrag at gmx.org (Jochen Theodorou) Date: Thu, 16 Jan 2014 09:52:51 +0100 Subject: [JDK8] RFR (XS): JSR292: IncompatibleClassChangeError in LambdaForm for CharSequence.toString() method handle type converter In-Reply-To: <52D79CE4.3010409@oracle.com> References: <52D6A9B8.2040906@oracle.com> <52D79B00.5080804@gmx.org> <52D79CE4.3010409@oracle.com> Message-ID: <52D79DE3.3080609@gmx.org> Am 16.01.2014 09:48, schrieb A. Sundararajan: > The test sets compile threshold to be zero > (-Djava.lang.invoke.MethodHandle.COMPILE_THRESHOLD=0 ). I think > compilation occurs on the first invoke. > > Also, I ran the test on a jdk8 build without Vladimir's fix - I saw the > exception being thrown. I ran it by passing the above option in the > command line (outside jtreg). ah, ok, thank you very much -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org From vladimir.x.ivanov at oracle.com Thu Jan 16 09:37:43 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 16 Jan 2014 13:37:43 +0400 Subject: [JDK8] RFR (XS): JSR292: IncompatibleClassChangeError in LambdaForm for CharSequence.toString() method handle type converter In-Reply-To: <52D79B00.5080804@gmx.org> References: <52D6A9B8.2040906@oracle.com> <52D79B00.5080804@gmx.org> Message-ID: <52D7A867.8070008@oracle.com> Jochen, The test provokes the bug, since it sets compilation threshold to 0: -Djava.lang.invoke.MethodHandle.COMPILE_THRESHOLD=0 Best regards, Vladimir Ivanov On 1/16/14 12:40 PM, Jochen Theodorou wrote: > Hi, > > since I am indirectly the reporter of this bug I have one remark for the > test. The error happens only for compiled lambda forms. The given test > does imho not use a compiled lambda form. In other words, afaik the test > would pass without the fix. As such it would be useless as regression test. > > Am 15.01.2014 16:31, schrieb Vladimir Ivanov: >> http://cr.openjdk.java.net/~vlivanov/8031502/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8031502 >> >> InvokeBytecodeGenerator can produce incorrect bytecode for a LambdaForm >> when invoking a method from Object declared in an interface. >> >> The problem is the following: >> (1) java.lang.CharSequence interface declares abstract method "String >> toString()"; >> >> (2) after 8014013 fix, VM resolves >> CharSequence::toString()/invokeInterface to >> CharSequence::toString()/invokeVirtual; >> >> (3) during LambdaForm compilation, CharSequence is considered >> statically invocable (see >> InvokeBytecodeGenerator::isStaticallyInvocable) and invokevirtual for >> CharSequence::toString() is issued, which is wrong (invokevirtual throws >> ICCE if it references an interface); >> >> The fix is straightforward: during LambdaForm compilation, switch back >> from invokevirtual to invokeinterface instruction when invoking a method >> on an interface. >> >> The fix is targeted for 8. Will be also integrated into 9. >> >> Testing: regression test, jdk/test/java/lang/invoke, vm.mlvm.testlist, >> nashorn, jruby. >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> > > From volker.simonis at gmail.com Thu Jan 16 09:38:55 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 16 Jan 2014 10:38:55 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <52D51FAC.8060800@oracle.com> <52D629A0.4080806@oracle.com> <52D64ED5.4020409@oracle.com> Message-ID: On Wed, Jan 15, 2014 at 12:05 PM, Volker Simonis wrote: > > > > On Wed, Jan 15, 2014 at 10:03 AM, Alan Bateman wrote: > >> On 15/01/2014 06:24, David Holmes wrote: >> >>> >>> I'm not a fan of runtime checks of this kind though if it is only a very >>> samll number of values it might be okay. >>> >>> Another option would be to make those classes into "templates" as done >>> with Version.java.template and substitute the right values at build time. >>> >>> But I'll let Alan and net-dev folk come back with their preferred >>> technique for this. >>> >>> I plan to spend time on Volker's webrev later in the week (just too >> busy with other things right now). For the translation issue then it's an >> oversight in the original implementation, it just hasn't come up before (to >> my knowledge anyway). The simplest solution here maybe to to just move them >> to sun.net.ch.Net and have them initialized to their native value. > > > Do you mean sun.nio.ch.Net right? > > Do you propose to completely remove the definitions of the POLL constants > from: > > src/share/classes/sun/nio/ch/AbstractPollArrayWrapper.java > src/solaris/classes/sun/nio/ch/Port.java > > and replace all their usages by Net.POLL* ? > > Hi Alan, I think sun.nio.ch.IOUtil seems even more appropriate to me for these constants. What do you think? Would it be OK for you if I initialize them right in the static initializer of IOUtil based on "os.name" or do you prefer to have native methods which return the right constants? Regards, Volker > In general then I'm not too concerned about that one, it's the changes to >> support async close on AIX that are leaping out at me. >> >> -Alan >> > > From Alan.Bateman at oracle.com Thu Jan 16 10:05:44 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 16 Jan 2014 10:05:44 +0000 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <52D51FAC.8060800@oracle.com> <52D629A0.4080806@oracle.com> <52D64ED5.4020409@oracle.com> Message-ID: <52D7AEF8.8090502@oracle.com> On 16/01/2014 09:38, Volker Simonis wrote: > > > Hi Alan, > > I think sun.nio.ch.IOUtil seems even more appropriate to me for these > constants. What do you think? > > Would it be OK for you if I initialize them right in the static > initializer of IOUtil based on "os.name " or do you > prefer to have native methods which return the right constants? I have a small preference for sun.nio.ch.Net because these constants are used with Net.poll. Would you be open to separating this one from the AIX changes? The reason is that it isn't AIX specific, rather just an oversight that hasn't been an issue because it doesn't impact other platforms. Using os.name initially would be okay although we could change that over time. -Alan From volker.simonis at gmail.com Thu Jan 16 10:34:03 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 16 Jan 2014 11:34:03 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: <52D7AEF8.8090502@oracle.com> References: <52D51FAC.8060800@oracle.com> <52D629A0.4080806@oracle.com> <52D64ED5.4020409@oracle.com> <52D7AEF8.8090502@oracle.com> Message-ID: On Thu, Jan 16, 2014 at 11:05 AM, Alan Bateman wrote: > On 16/01/2014 09:38, Volker Simonis wrote: > > > > Hi Alan, > > I think sun.nio.ch.IOUtil seems even more appropriate to me for these > constants. What do you think? > > Would it be OK for you if I initialize them right in the static initializer > of IOUtil based on "os.name" or do you prefer to have native methods which > return the right constants? > > I have a small preference for sun.nio.ch.Net because these constants are > used with Net.poll. I just thought because poll is more file-descriptor oriented and not network specific. And the constants are also used for example in: src/macosx/classes/sun/nio/ch/KQueueArrayWrapper.java: src/solaris/classes/sun/nio/ch/sctp/Sctp* src/solaris/classes/sun/nio/ch/Port.java But actually I have no prefernece here so I can put them just as well to sun.nio.ch.Net > Would you be open to separating this one from the AIX > changes? The reason is that it isn't AIX specific, rather just an oversight > that hasn't been an issue because it doesn't impact other platforms. Sure, no problem. Although I still would like to push this to ppc-aix-port/stage-9 and ppc-aix-port/stage first because that's where we really need it. Anyway, the current plan is to merge ppc-aix-port/stage-9 into jdk9 mainline by the end of January and ppc-aix-port/stage into 8u-dev by the end of March (for 8u20). Would that be ok? > Using > os.name initially would be okay although we could change that over time. I've already written the native methods:) > > -Alan From paul.sandoz at oracle.com Thu Jan 16 11:26:17 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 16 Jan 2014 12:26:17 +0100 Subject: RFR 8029452: Fork/Join task ForEachOps.ForEachOrderedTask clarifications and minor improvements In-Reply-To: <6F2D7451-6826-4CC5-AE55-62BD97EB5264@oracle.com> References: <6F2D7451-6826-4CC5-AE55-62BD97EB5264@oracle.com> Message-ID: <2684FFB7-EA1D-4498-854B-43AA40A43D74@oracle.com> On Jan 10, 2014, at 2:42 PM, Paul Sandoz wrote: > I have also removed the inconsistently applied synchronized block. Either we apply it consistently to reporting or not at all. It was originally there because we were not sure that the "happens-before" relationship [1] between elements would be guaranteed. However, ForEachOrderedTask sets up such a relationship via completion counts to ensure leaf nodes complete in encounter order (if any) where only one leaf can be completing (which was left most leaf that was not completed), hence stamping a fence in the ground at these point seems redundant (at least i cannot see its value but could be missing something subtle). > I updated with some more comments explaining how the "happens-before" is preserved: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8029452-ForEachOrdered/webrev/ Paul. From roger.riggs at oracle.com Thu Jan 16 14:12:58 2014 From: roger.riggs at oracle.com (roger riggs) Date: Thu, 16 Jan 2014 09:12:58 -0500 Subject: RFR 8031961 ProcessBuilder.Basic should use NIO Files to copy files In-Reply-To: <52D79C3D.8010300@oracle.com> References: <52D75086.5050200@Oracle.com> <52D79C3D.8010300@oracle.com> Message-ID: <52D7E8EA.4020701@oracle.com> Hi Alan, I suspect that Solaris didn't support -p (as per the comment) but it was not worth a lot of investigation for an old issue and old SE 6. Roger On 1/16/2014 3:45 AM, Alan Bateman wrote: > On 16/01/2014 03:22, Roger Riggs wrote: >> Please review this minor test improvement to replace spawning /bin/cp >> to copy files with NIO Files.copy. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-process-cp-8031961/ > Just looking at JDK-6686751 and it's not clear what the issue was with > -p. I assume we want the permissions copied (so COPY_ATTRIBUTES is > right), it's just not clear what the "Invalid argument" was about and > whether this was an older version of Solaris or a cp version that > didn't support these options? > > -Alan. From paul.sandoz at oracle.com Thu Jan 16 14:42:23 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 16 Jan 2014 15:42:23 +0100 Subject: JDK 9 RFC on 6667086: Double.doubleToLongBits(final double value) contains inefficient test for NaN In-Reply-To: References: Message-ID: <02119D4F-6B3F-43C3-98C4-C33B840F1E67@oracle.com> On Jan 15, 2014, at 10:28 PM, Brian Burkhalter wrote: > Issue: https://bugs.openjdk.java.net/browse/JDK-6667086 > Webrev: http://cr.openjdk.java.net/~bpb/6667086/webrev/ > > According to micro-benckmarks, there is no statistically significant performance change due to applying this patch but the code definitely looks cleaner. > Looks OK. I would hope at least the generated machine code from your updated method would be simpler. In a comment of the bug there are some optimizations proposed to other methods (Math.nextAfter/nextUp), might be useful to fix those too or capture in another bug if the intention is to evaluate? Paul. From paul.sandoz at oracle.com Thu Jan 16 15:39:28 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 16 Jan 2014 16:39:28 +0100 Subject: Review request for JDK-6760902: inconsistent behavior in bootstrap class loader for classes and resources In-Reply-To: <52D73587.30104@oracle.com> References: <52D73587.30104@oracle.com> Message-ID: On Jan 16, 2014, at 2:27 AM, Mandy Chung wrote: > There is an inconsistency in searching classes vs resources if bootclasspath contains an empty path. Empty path on bootclasspath is skipped by the bootstrap class loader when searching classes while it defaults to current working directory when searching resources as the application class loader. Just curious, where is the code that skips empty paths in the bootclasspath when loading classes? Is that in the VM? > This fixes sun.misc.Launcher to skip empty path when constructing the paths from bootclasspath for resource lookup. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/6760902/webrev.00/ > Perhaps it is better to merge GetResource2.sh into GetResource.sh. I am so tempted to change this too :-) 423 if (pos - lastPos > 0) { Paul. > There is some incompatibility risk that may impact existing code depending on this behavior to search resources from the current working directory if empty path (rather than explicit) is set. I think most application using bootclasspath is to add their paths to load their classes and likely expect the resources are looked in the consistent way (i.e. skips the empty path). So I expect the incompatibility risk is low. > > thanks > Mandy From brian.burkhalter at oracle.com Thu Jan 16 15:47:20 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 16 Jan 2014 07:47:20 -0800 (PST) Subject: JDK 9 RFC on 6667086: Double.doubleToLongBits(final double value) contains inefficient test for NaN Message-ID: <38195822-2686-44b4-b0f6-7e254381f5e2@default> Oh I forgot to mention about the optimizations in the comments. I also read about those and was thinking to capture them in a separate issue for clarity. Thanks, Brian ----- Original Message ----- From: paul.sandoz at oracle.com Cc: core-libs-dev at openjdk.java.net Sent: Thursday, January 16, 2014 6:43:47 AM GMT -08:00 US/Canada Pacific Subject: Re: JDK 9 RFC on 6667086: Double.doubleToLongBits(final double value) contains inefficient test for NaN On Jan 15, 2014, at 10:28 PM, Brian Burkhalter wrote: > Issue: https://bugs.openjdk.java.net/browse/JDK-6667086 > Webrev: http://cr.openjdk.java.net/~bpb/6667086/webrev/ > > According to micro-benckmarks, there is no statistically significant performance change due to applying this patch but the code definitely looks cleaner. > Looks OK. I would hope at least the generated machine code from your updated method would be simpler. In a comment of the bug there are some optimizations proposed to other methods (Math.nextAfter/nextUp), might be useful to fix those too or capture in another bug if the intention is to evaluate? Paul. From mandy.chung at oracle.com Thu Jan 16 15:51:30 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 16 Jan 2014 07:51:30 -0800 Subject: Review request for JDK-6760902: inconsistent behavior in bootstrap class loader for classes and resources In-Reply-To: References: <52D73587.30104@oracle.com> Message-ID: <52D80002.4080604@oracle.com> On 1/16/2014 7:39 AM, Paul Sandoz wrote: > On Jan 16, 2014, at 2:27 AM, Mandy Chung wrote: > >> There is an inconsistency in searching classes vs resources if bootclasspath contains an empty path. Empty path on bootclasspath is skipped by the bootstrap class loader when searching classes while it defaults to current working directory when searching resources as the application class loader. > Just curious, where is the code that skips empty paths in the bootclasspath when loading classes? Is that in the VM? Yes it's in the VM which implements the class loading. I don't know the history and I guess splitting the implementation of class loading vs resource lookup in the VM and jdk could be due to no actual ClassLoader implementation (null instead). >> This fixes sun.misc.Launcher to skip empty path when constructing the paths from bootclasspath for resource lookup. >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/6760902/webrev.00/ >> > Perhaps it is better to merge GetResource2.sh into GetResource.sh. I was considering if merging them would be better and separating it makes it clear for what it tests for. On the other hand, I don't like duplication and I probably can merge them and clean > I am so tempted to change this too :-) > > 423 if (pos - lastPos > 0) { Me too and time to do it. Will post another webrev. Mandy > > Paul. > > >> There is some incompatibility risk that may impact existing code depending on this behavior to search resources from the current working directory if empty path (rather than explicit) is set. I think most application using bootclasspath is to add their paths to load their classes and likely expect the resources are looked in the consistent way (i.e. skips the empty path). So I expect the incompatibility risk is low. >> >> thanks >> Mandy From paul.sandoz at oracle.com Thu Jan 16 15:59:26 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 16 Jan 2014 16:59:26 +0100 Subject: Review request for JDK-6760902: inconsistent behavior in bootstrap class loader for classes and resources In-Reply-To: <52D80002.4080604@oracle.com> References: <52D73587.30104@oracle.com> <52D80002.4080604@oracle.com> Message-ID: On Jan 16, 2014, at 4:51 PM, Mandy Chung wrote: > > On 1/16/2014 7:39 AM, Paul Sandoz wrote: >> On Jan 16, 2014, at 2:27 AM, Mandy Chung wrote: >> >>> There is an inconsistency in searching classes vs resources if bootclasspath contains an empty path. Empty path on bootclasspath is skipped by the bootstrap class loader when searching classes while it defaults to current working directory when searching resources as the application class loader. >> Just curious, where is the code that skips empty paths in the bootclasspath when loading classes? Is that in the VM? > > Yes it's in the VM which implements the class loading. I don't know the history and I guess splitting the implementation of class loading vs resource lookup in the VM and jdk could be due to no actual ClassLoader implementation (null instead). > OK. >>> This fixes sun.misc.Launcher to skip empty path when constructing the paths from bootclasspath for resource lookup. >>> >>> Webrev at: >>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/6760902/webrev.00/ >>> >> Perhaps it is better to merge GetResource2.sh into GetResource.sh. > > I was considering if merging them would be better and separating it makes it clear for what it tests for. On the other hand, I don't like duplication and I probably can merge them and clean > OK, the echo statements make things quite clear IMHO. >> I am so tempted to change this too :-) >> >> 423 if (pos - lastPos > 0) { > > Me too and time to do it. Will post another webrev. > While you are at it, there is a JavaDoc error for the method ref: /** * This class loader supports dynamic additions to the class path * at runtime. * * @see java.lang.instrument.Instrumentation#appendToSystemClassPathSearch */ private void appendToClassPathForInstrumentation(String path) { Even though it is a private method that JavaDoc is useful since one can click through via the IDE. Paul. From alexander.zuev at oracle.com Thu Jan 16 16:21:30 2014 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Thu, 16 Jan 2014 20:21:30 +0400 Subject: JDK9 RFR of JDK-8029646: [pack200] should support the new zip64 format. In-Reply-To: <52D6C6B0.3020508@oracle.com> References: <52D57C2A.4010906@oracle.com> <52D61589.1090901@oracle.com> <52D69A9A.1010506@oracle.com> <52D69C5E.9020407@oracle.com> <52D6A2C1.2000802@oracle.com> <52D6C6B0.3020508@oracle.com> Message-ID: <52D8070A.8030804@oracle.com> Sherman, Kumar, i have fixed the glitches you have found and changed the test so it creates a new jar based on the golden.jar content (to have a reasonable set of various data to start with), then adding to it 65536 empty files to test how we cope with such a huge jars. The testing time is less than a 30 seconds on my machine (not the top-of-the-line) so i decided not to bother with conditional testing, lets test our behavior every time in full. The updated webrev can be found at http://cr.openjdk.java.net/~kizune/8029646/webrev.02 /Alex On 1/15/14 21:34, Xueming Shen wrote: > On 1/15/14 7:01 AM, Alexander Zuev wrote: >> Hello, >> >> the new webrev with all the typos and comments fixed can be found >> at http://cr.openjdk.java.net/~kizune/8029646/webrev.01/ >> >> /Alex > > (1) jarmagic can be just a static constant somewhere or a stack > variable. not big deal though. > (2) the test only "tests" EOF for s. there is possibility that the > newly created has more extra > bytes at the end...though in theory this should not happen, it > might be better just add an > extra line to check the sizes of two first first? > (3) the rest of the change looks good, but I agreed with Kumar that > you may need to add a > regression test for a jar file with > 64k entries. otherwise > the code for zip64 end is not > being tested. the code looks fine, but I would trust a > regression test more than my eyes:-) > > Thanks! > -Sherman From roger.riggs at oracle.com Thu Jan 16 16:26:55 2014 From: roger.riggs at oracle.com (roger riggs) Date: Thu, 16 Jan 2014 11:26:55 -0500 Subject: RFR: (8031737) rename jni_util.h macros for checking and returning on exceptions Message-ID: <52D8084F.5060801@oracle.com> Please review: The native macros for checking and returning when exceptions are thrown have been renamed to include the "JNU_" prefix consistent with other functions in jni_util.h. The macros have been renamed and existing uses in the jdk repository for networking, pack200, and have been updated. A jprt run has passed (except for unrelated failures). webrev: http://cr.openjdk.java.net/~rriggs/webrev-jnu-check-rename-8031737/ Thanks, Roger [1] https://bugs.openjdk.java.net/browse/JDK-8031737 From Alan.Bateman at oracle.com Thu Jan 16 16:41:10 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 16 Jan 2014 16:41:10 +0000 Subject: RFR: (8031737) rename jni_util.h macros for checking and returning on exceptions In-Reply-To: <52D8084F.5060801@oracle.com> References: <52D8084F.5060801@oracle.com> Message-ID: <52D80BA6.2060002@oracle.com> On 16/01/2014 16:26, roger riggs wrote: > Please review: > > The native macros for checking and returning when exceptions > are thrown have been renamed to include the "JNU_" prefix > consistent with other functions in jni_util.h. > > The macros have been renamed and existing uses in the jdk repository > for networking, pack200, and have been updated. A jprt run has passed > (except for unrelated failures). > > webrev: > http://cr.openjdk.java.net/~rriggs/webrev-jnu-check-rename-8031737/ Did you mean to rename the CHECK_NULL and CHECK_NULL_RETURN macros? They don't require a JNIEnv so I'm wondering if JNU_* really make sense here. -Alan. From martinrb at google.com Thu Jan 16 16:45:45 2014 From: martinrb at google.com (Martin Buchholz) Date: Thu, 16 Jan 2014 08:45:45 -0800 Subject: RFR: (8031737) rename jni_util.h macros for checking and returning on exceptions In-Reply-To: <52D8084F.5060801@oracle.com> References: <52D8084F.5060801@oracle.com> Message-ID: Your backslashes are not aligned; you can fix them using: C-c C-\ runs `c-backslash-region' Documentation: Insert, align, or delete end-of-line backslashes on the lines in the region. On Thu, Jan 16, 2014 at 8:26 AM, roger riggs wrote: > Please review: > > The native macros for checking and returning when exceptions > are thrown have been renamed to include the "JNU_" prefix > consistent with other functions in jni_util.h. > > The macros have been renamed and existing uses in the jdk repository > for networking, pack200, and have been updated. A jprt run has passed > (except for unrelated failures). > > webrev: > http://cr.openjdk.java.net/~rriggs/webrev-jnu-check-rename-8031737/ > > Thanks, Roger > > [1] https://bugs.openjdk.java.net/browse/JDK-8031737 > From roger.riggs at oracle.com Thu Jan 16 16:48:38 2014 From: roger.riggs at oracle.com (roger riggs) Date: Thu, 16 Jan 2014 11:48:38 -0500 Subject: RFR: (8031737) rename jni_util.h macros for checking and returning on exceptions In-Reply-To: <52D80BA6.2060002@oracle.com> References: <52D8084F.5060801@oracle.com> <52D80BA6.2060002@oracle.com> Message-ID: <52D80D66.7090105@oracle.com> Hi Alan, The macros are generally useful even without being used on a method that involves jni. An overly aggressive find caught the uses in java/util/jar/pack. But yes, it might be better to limit their scope to functions that involve jni. Roger On 1/16/2014 11:41 AM, Alan Bateman wrote: > On 16/01/2014 16:26, roger riggs wrote: >> Please review: >> >> The native macros for checking and returning when exceptions >> are thrown have been renamed to include the "JNU_" prefix >> consistent with other functions in jni_util.h. >> >> The macros have been renamed and existing uses in the jdk repository >> for networking, pack200, and have been updated. A jprt run has passed >> (except for unrelated failures). >> >> webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-jnu-check-rename-8031737/ > Did you mean to rename the CHECK_NULL and CHECK_NULL_RETURN macros? > They don't require a JNIEnv so I'm wondering if JNU_* really make > sense here. > > -Alan. From Alan.Bateman at oracle.com Thu Jan 16 16:51:55 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 16 Jan 2014 16:51:55 +0000 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <52D51FAC.8060800@oracle.com> <52D629A0.4080806@oracle.com> <52D64ED5.4020409@oracle.com> <52D7AEF8.8090502@oracle.com> Message-ID: <52D80E2B.5000608@oracle.com> On 16/01/2014 10:34, Volker Simonis wrote: > : > I just thought because poll is more file-descriptor oriented and not > network specific. And the constants are also used for example in: > > src/macosx/classes/sun/nio/ch/KQueueArrayWrapper.java: > src/solaris/classes/sun/nio/ch/sctp/Sctp* > src/solaris/classes/sun/nio/ch/Port.java > > But actually I have no prefernece here so I can put them just as well > to sun.nio.ch.Net It's not used for anything except sockets here (there aren't any selectable channels that aren't also network channels). So I think sun.nio.ch.Net is marginly cleaner here. > : > > Sure, no problem. Although I still would like to push this to > ppc-aix-port/stage-9 and ppc-aix-port/stage first because that's where > we really need it. Anyway, the current plan is to merge > ppc-aix-port/stage-9 into jdk9 mainline by the end of January and > ppc-aix-port/stage into 8u-dev by the end of March (for 8u20). Would > that be ok? > I see you've created a bug for this. I guess it's okay if comes via the ppc port although would still be good to get it into jdk9/dev early as it impacts all platforms. -Alan. From joe.darcy at oracle.com Thu Jan 16 17:23:08 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 16 Jan 2014 09:23:08 -0800 Subject: JDK 9 RFC on 6667086: Double.doubleToLongBits(final double value) contains inefficient test for NaN In-Reply-To: References: Message-ID: <52D8157C.2080402@oracle.com> On 01/15/2014 01:28 PM, Brian Burkhalter wrote: > Issue: https://bugs.openjdk.java.net/browse/JDK-6667086 > Webrev: http://cr.openjdk.java.net/~bpb/6667086/webrev/ > > According to micro-benckmarks, there is no statistically significant performance change due to applying this patch but the code definitely looks cleaner. > > Thanks, > > Brian Hi Brian, A few comments here. If you are making this change in Double, you would make the corresponding change in Float too. Some explanation on why I wrote these methods with the integer-field-based null check, some processors are implemented such that operating on the IEEE non-finite value of NaN and +/- infinity runs much more slowly than operating on normal value, sometimes orders of magnitude more slowly. For the bitwise conversion methods, since we were biting the bullet to do the conversion anyway, I thought I would avoid the worst-case cost of tripping over a NaN by doing the NaN check on the integer value. However, I will vote to approve the replacement of that code with "isNaN" checks as long as Float and Double are both converted. Cheers, -Joe From kumar.x.srinivasan at oracle.com Thu Jan 16 17:30:38 2014 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 16 Jan 2014 09:30:38 -0800 Subject: RFR: (8031737) rename jni_util.h macros for checking and returning on exceptions In-Reply-To: <52D80D66.7090105@oracle.com> References: <52D8084F.5060801@oracle.com> <52D80BA6.2060002@oracle.com> <52D80D66.7090105@oracle.com> Message-ID: <52D8173E.9000700@oracle.com> Hi Roger, Its confusing to use a JNU_ prefixed macro on a method not involvng jni, why not rename these to modulo JNU_ ? I am cc'ing Alex as he has a related bug fix in his queue for pack's jni code. Kumar > Hi Alan, > > The macros are generally useful even without being used on a method that > involves jni. An overly aggressive find caught the uses in > java/util/jar/pack. > > But yes, it might be better to limit their scope to functions that > involve jni. > > Roger > > > On 1/16/2014 11:41 AM, Alan Bateman wrote: >> On 16/01/2014 16:26, roger riggs wrote: >>> Please review: >>> >>> The native macros for checking and returning when exceptions >>> are thrown have been renamed to include the "JNU_" prefix >>> consistent with other functions in jni_util.h. >>> >>> The macros have been renamed and existing uses in the jdk repository >>> for networking, pack200, and have been updated. A jprt run has >>> passed (except for unrelated failures). >>> >>> webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-jnu-check-rename-8031737/ >> Did you mean to rename the CHECK_NULL and CHECK_NULL_RETURN macros? >> They don't require a JNIEnv so I'm wondering if JNU_* really make >> sense here. >> >> -Alan. > From Ulf.Zibis at CoSoCo.de Thu Jan 16 17:56:59 2014 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Thu, 16 Jan 2014 18:56:59 +0100 Subject: RFR: (8031737) rename jni_util.h macros for checking and returning on exceptions In-Reply-To: <52D8084F.5060801@oracle.com> References: <52D8084F.5060801@oracle.com> Message-ID: <52D81D6B.6090209@CoSoCo.de> Am 16.01.2014 17:26, schrieb roger riggs: > Please review: > > webrev: > http://cr.openjdk.java.net/~rriggs/webrev-jnu-check-rename-8031737/ I more would like a "while (true)" loop, rather than a "do" loop. -Ulf From roger.riggs at oracle.com Thu Jan 16 18:13:23 2014 From: roger.riggs at oracle.com (roger riggs) Date: Thu, 16 Jan 2014 13:13:23 -0500 Subject: RFR: (8031737) rename jni_util.h macros for checking and returning on exceptions In-Reply-To: <52D81D6B.6090209@CoSoCo.de> References: <52D8084F.5060801@oracle.com> <52D81D6B.6090209@CoSoCo.de> Message-ID: <52D82143.9000707@oracle.com> Hi, The current do {...} while(0) is the established idiom in the jdk. It does not have the potential problem of unintentionally allowing an infinite loop if the body contains a 'continue'. Roger On 1/16/2014 12:56 PM, Ulf Zibis wrote: > Am 16.01.2014 17:26, schrieb roger riggs: >> Please review: >> >> webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-jnu-check-rename-8031737/ > > I more would like a "while (true)" loop, rather than a "do" loop. > > -Ulf > From xueming.shen at oracle.com Thu Jan 16 18:08:19 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 16 Jan 2014 10:08:19 -0800 Subject: RFR: JDK-8032012, , String.toLowerCase/toUpperCase performance improvement Message-ID: <52D82013.7020009@oracle.com> Hi, The proposed changeset is to improve the performance (both speed and memory usage) of String.toLowerCase/toUpperCase, by (1) to separate the "most likely" use scenario (non supplementary character, no special case mapping handling) into simple/quick iteration loop code path (2) to use the package private constructor String(char[], boolean) to avoid unnecessary target char[] copy in fast-path case. (3) some tiny code cleanup. Since it's supposed to be a simple/quick round of code cleanup, I did not go too far to optimize the supplementary/special mapping code. The webrev is http://cr.openjdk.java.net/~sherman/8032012/ My small non-scientific speed measurement test suggests we can get 25% to 40% speed boost. http://cr.openjdk.java.net/~sherman/str_toCase/TestToCase.java Thanks! -Sherman From srikalyan.chandrashekar at oracle.com Thu Jan 16 18:48:08 2014 From: srikalyan.chandrashekar at oracle.com (srikalyan) Date: Thu, 16 Jan 2014 10:48:08 -0800 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52D76859.2030502@oracle.com> References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> <52CC72AB.2020104@oracle.com> <52CCEDE0.8000809@oracle.com> <52CCF079.4090301@oracle.com> <52CD45E7.7010203@gmail.com> <52CE4E2D.300@oracle.com> <52CF37C6.1070605@oracle.com> <52CFAFEB.9090703@gmail.com> <52CFD218.2060101@gmail.com> <52D06B70.60001@oracle.com> <52D15201.90109@gmail.com> <52D47D59.8040905@oracle.com> <52D72577.1050506@oracle.com> <52D76859.2030502@oracle.com> Message-ID: <52D82968.4030608@oracle.com> Hi David On 1/15/14, 9:04 PM, David Holmes wrote: > On 16/01/2014 10:19 AM, srikalyan chandrashekar wrote: >> Hi Peter/David, we could finally get a trace of exception with fastdebug >> build and ReferenceHandler modified (with runImpl() added and called >> from run()). The logs, disassembled code is available in JIRA >> as attachments. > > All I can see is the log for the OOMECatchingTest program not one for > the actual ReferenceHandler ?? > Please search for ReferenceHandler in the log. >> Observations from the log: >> >> Root Cause: >> 1) UncaughtException is being dispatched from Reference.java:143 >> 141 Reference r; >> 142 synchronized (lock) { >> 143 if (pending != null) { >> 144 r = pending; >> 145 pending = r.discovered; >> 146 r.discovered = null; >> >> pending field in Reference is touched and updated by the collector, so >> at line 143 when the execution context is in Reference handler there >> might have been an Exception pending due to allocation done by collector >> which causes ReferenceHandler thread to die. > > Sorry but the GC does not trigger asynchronous exceptions so this > explanation does not make any sense to me. What part of the log led > you to this conclusion? ------------------ Log Excerpt begins ------------------ Exception (0x00000000ff7808e8) thrown [/home/srikalyc/work/ora2013/infracleanup/jdk8/hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp, line 168] for thread 0x00007feed80cf800 Exception (0x00000000ff7808e8) thrown in interpreter method <{method} {0x00007feeddd3c600} 'runImpl' '()V' in 'java/lang/ref/Reference$ReferenceHandler'> at bci 65 for thread 0x00007feed80cf800 Exception (0x00000000ff7808e8) thrown in interpreter method <{method} {0x00007feeddd3c478} 'run' '()V' in 'java/lang/ref/Reference$ReferenceHandler'> at bci 1 for thread 0x00007feed80cf800 Exception (0x00000000ff780868) thrown [/home/srikalyc/work/ora2013/infracleanup/jdk8/hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp, line 157] for thread 0x00007feed80cf800 Exception (0x00000000ff780868) thrown in interpreter method <{method} {0x00007feeddcaaf90} 'uncaughtException' '(Ljava/lang/Thread;Ljava/lang/Throwable;)V' in '> at bci 48 for thread 0x00007feed80cf800 Exception (0x00000000ff780868) thrown in interpreter method <{method} {0x00007feeddca7298} 'dispatchUncaughtException' '(Ljava/lang/Throwable;)V' in 'java/lang/> at bci 6 for thread 0x00007feed80cf800 ------------------ Log Excerpt ends ------------------ Sorry if it is a wrong understanding. > >> Suggested fix: >> - As proposed earlier putting an outer guard(try-catch on OOME) in the >> ReferenceHandler will fix the issue, if ReferenceHandler is considered >> as part of the GC sub system then it should be alive even in the midst >> of an OOME so i feel that the additional guard should be allowed, >> however i might still be ignorant of vital implications. >> - Apart from the above changes, Peter's suggestion to create and call a >> private runImpl() from run() in ReferenceHandler makes sense to me. > > Why would we need this? > > David > ----- > >> >> --- >> Thanks >> kalyan >> >> On 01/13/2014 03:57 PM, srikalyan wrote: >>> >>> On 1/11/14, 6:15 AM, Peter Levart wrote: >>>> >>>> On 01/10/2014 10:51 PM, srikalyan chandrashekar wrote: >>>>> Hi Peter the version you provided ran indefinitely(i put a 10 minute >>>>> timeout) and the program got interrupted(no error), >>>> >>>> Did you run it with or without fastedbug & -XX:+TraceExceptions ? If >>>> with, it might be that fastdebug and/or -XX:+TraceExceptions changes >>>> the execution a bit so that we can no longer reproduce the wrong >>>> behaviour. >>> With fastdebug & -XX:TraceExceptions. I will try combination of >>> possible options(i.e without -XX:TraceEception on debug build etc) >>> soon. >>>> >>>>> even if there were to be an error you cannot print the "string" of >>>>> thread to console(these have been attempted earlier). >>>> >>>> ...it has been attempted to print toString in uncaught exception >>>> handler. At that time, the heap is still full. I'm printing it after >>>> the GC has cleared the heap. You can try that it works by commenting >>>> out the "try {" and corresponding "} catch (OOME x) {}" exception >>>> handler... >>> Since there is a GC call prior to printing string i will give that a >>> shot with non-debug build. >>>> >>>>> - The test's running on interpreter mode, what i am watching for is >>>>> one error with trace. Without fastdebug build and >>>>> -XX:+TraceExceptions i am able to reproduce failure atleast 5 >>>>> failures out of 1000 runs but with fastdebug+Trace no luck >>>>> yet(already past few 1000 runs). >>>> >>>> It might be interesting to try with fastebug build but without the >>>> -XX:+TraceExceptions option to see what has an effect on it. It might >>>> also be interesting to try the modified ReferenceHandler (the one >>>> with private runImpl() method called from run()) and with normal >>>> non-fastdebug JDK. This info might be useful when one starts to >>>> inspect the exception handling code in interpreter... >>>> >>>> Regards, Peter >>>> >>> >>> -- >>> Thanks >>> kalyan >>> Ph: (408)-585-8040 >>> >>>>> >>>>> --- >>>>> Thanks >>>>> kalyan >>>>> >>>>> On 01/10/2014 02:57 AM, Peter Levart wrote: >>>>>> On 01/10/2014 09:31 AM, Peter Levart wrote: >>>>>>> Since we suspect there's something wrong with exception handling >>>>>>> in interpreter, I devised a hypothetical reproducer that tries to >>>>>>> simulate ReferenceHandler in many aspects, but doesn't require to >>>>>>> be a ReferenceHandler: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~plevart/misc/OOME/OOMECatchingTest.java >>>>>>> >>>>>>> This is designed to run indefinitely and only terminate if/when >>>>>>> thread dies. Could you run this program in the environment that >>>>>>> causes the OOMEInReferenceHandler test to fail and see if it >>>>>>> terminates? >>>>>> >>>>>> I forgot to mention that in order for this long-running program to >>>>>> exhibit interpreter behaviour, it should be run with -Xint option. >>>>>> So I suggest: >>>>>> >>>>>> -Xmx24M -XX:-UseTLAB -Xint >>>>>> >>>>>> Regards, Peter >>>>>> >>>>> >>>> >> From brian.burkhalter at oracle.com Thu Jan 16 18:51:34 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 16 Jan 2014 10:51:34 -0800 Subject: JDK 9 RFC on 6667086: Double.doubleToLongBits(final double value) contains inefficient test for NaN In-Reply-To: <52D8157C.2080402@oracle.com> References: <52D8157C.2080402@oracle.com> Message-ID: Hi Joe, On Jan 16, 2014, at 9:23 AM, Joe Darcy wrote: > A few comments here. If you are making this change in Double, you would make the corresponding change in Float too. Please see the updated webrev http://cr.openjdk.java.net/~bpb/6667086/webrev.2/. > Some explanation on why I wrote these methods with the integer-field-based null check, some processors are implemented such that operating on the IEEE non-finite value of NaN and +/- infinity runs much more slowly than operating on normal value, sometimes orders of magnitude more slowly. > > For the bitwise conversion methods, since we were biting the bullet to do the conversion anyway, I thought I would avoid the worst-case cost of tripping over a NaN by doing the NaN check on the integer value. Thanks for the explanation. Would {Double,Float}.isNaN() perhaps be good candidates for VM intrinsics? > However, I will vote to approve the replacement of that code with "isNaN" checks as long as Float and Double are both converted. This has been done in the patch linked above. Thanks, Brian From kumar.x.srinivasan at oracle.com Thu Jan 16 18:57:03 2014 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 16 Jan 2014 10:57:03 -0800 Subject: RFR: (8031737) rename jni_util.h macros for checking and returning on exceptions In-Reply-To: <52D8173E.9000700@oracle.com> References: <52D8084F.5060801@oracle.com> <52D80BA6.2060002@oracle.com> <52D80D66.7090105@oracle.com> <52D8173E.9000700@oracle.com> Message-ID: <52D82B7F.8030905@oracle.com> Roger, one more thing, shouldn't the parameters be unique ? I think Martin had me do this for all macros in the java launcher for example please see this changeset, I recently pushed. http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6c50c972a101 Kumar On 1/16/2014 9:30 AM, Kumar Srinivasan wrote: > Hi Roger, > > Its confusing to use a JNU_ prefixed macro on a method not involvng jni, > why not rename these to modulo JNU_ ? > > I am cc'ing Alex as he has a related bug fix in his queue for pack's > jni code. > > Kumar > >> Hi Alan, >> >> The macros are generally useful even without being used on a method that >> involves jni. An overly aggressive find caught the uses in >> java/util/jar/pack. >> >> But yes, it might be better to limit their scope to functions that >> involve jni. >> >> Roger >> >> >> On 1/16/2014 11:41 AM, Alan Bateman wrote: >>> On 16/01/2014 16:26, roger riggs wrote: >>>> Please review: >>>> >>>> The native macros for checking and returning when exceptions >>>> are thrown have been renamed to include the "JNU_" prefix >>>> consistent with other functions in jni_util.h. >>>> >>>> The macros have been renamed and existing uses in the jdk repository >>>> for networking, pack200, and have been updated. A jprt run has >>>> passed (except for unrelated failures). >>>> >>>> webrev: >>>> http://cr.openjdk.java.net/~rriggs/webrev-jnu-check-rename-8031737/ >>> Did you mean to rename the CHECK_NULL and CHECK_NULL_RETURN macros? >>> They don't require a JNIEnv so I'm wondering if JNU_* really make >>> sense here. >>> >>> -Alan. >> > From Ulf.Zibis at CoSoCo.de Thu Jan 16 18:57:49 2014 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Thu, 16 Jan 2014 19:57:49 +0100 Subject: RFR: (8031737) rename jni_util.h macros for checking and returning on exceptions In-Reply-To: <52D82143.9000707@oracle.com> References: <52D8084F.5060801@oracle.com> <52D81D6B.6090209@CoSoCo.de> <52D82143.9000707@oracle.com> Message-ID: <52D82BAD.7000100@CoSoCo.de> Hi, thanks, I thought this is an endless loop until the inner condition is fulfilled, not really noting, that 0==false (one more reason to use true/false instead 1/0, IMHO). Can you explain the trick, why you use a one-time-loop instead of a single statement? -Ulf Am 16.01.2014 19:13, schrieb roger riggs: > Hi, > > The current do {...} while(0) is the established idiom in the jdk. > > It does not have the potential problem of unintentionally allowing > an infinite loop if the body contains a 'continue'. > > Roger > > On 1/16/2014 12:56 PM, Ulf Zibis wrote: >> Am 16.01.2014 17:26, schrieb roger riggs: >>> Please review: >>> >>> webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-jnu-check-rename-8031737/ >> >> I more would like a "while (true)" loop, rather than a "do" loop. >> >> -Ulf >> > > From Ulf.Zibis at CoSoCo.de Thu Jan 16 19:42:13 2014 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Thu, 16 Jan 2014 20:42:13 +0100 Subject: RFR: JDK-8032012, , String.toLowerCase/toUpperCase performance improvement In-Reply-To: <52D82013.7020009@oracle.com> References: <52D82013.7020009@oracle.com> Message-ID: <52D83615.7000505@CoSoCo.de> Hi Sherman, nice performance trick :-) Do you remember the discussion about : https://bugs.openjdk.java.net/browse/JDK-6939278 ;-) (this bug was originally filed by me!) -Ulf Am 16.01.2014 19:08, schrieb Xueming Shen: > Hi, > > The proposed changeset is to improve the performance (both speed and memory > usage) of String.toLowerCase/toUpperCase, by > > (1) to separate the "most likely" use scenario (non supplementary character, no special > case mapping handling) into simple/quick iteration loop code path > (2) to use the package private constructor String(char[], boolean) to avoid unnecessary > target char[] copy in fast-path case. > (3) some tiny code cleanup. > > Since it's supposed to be a simple/quick round of code cleanup, I did not go too far to > optimize the supplementary/special mapping code. > > The webrev is > > http://cr.openjdk.java.net/~sherman/8032012/ > > My small non-scientific speed measurement test suggests we can get 25% to 40% > speed boost. > > http://cr.openjdk.java.net/~sherman/str_toCase/TestToCase.java > > Thanks! > -Sherman > From roger.riggs at oracle.com Thu Jan 16 19:44:05 2014 From: roger.riggs at oracle.com (roger riggs) Date: Thu, 16 Jan 2014 14:44:05 -0500 Subject: RFR: (8031737) rename jni_util.h macros for checking and returning on exceptions In-Reply-To: <52D82BAD.7000100@CoSoCo.de> References: <52D8084F.5060801@oracle.com> <52D81D6B.6090209@CoSoCo.de> <52D82143.9000707@oracle.com> <52D82BAD.7000100@CoSoCo.de> Message-ID: <52D83685.2020007@oracle.com> Check out the stackoverflow.com and bytes.com for explanations with examples. Using the pattern gives consistent results in a wide range of source contexts and parameter strings. Macros are textual substitutions; the c compiler only sees it after all the substitutions are done. "The |do ... while| and |if ... else| are there to make it so that a semicolon after your macro always means the same thing. Let's say you had something like your second macro." http://stackoverflow.com/questions/154136/do-while-and-if-else-statements-in-c-c-macros The whole idea of using 'do/while' version is to make a macro which will expand into a regular statement, not into a compound statement. This is done in order to make the use of function-style macros uniform with the use of ordinary functions in all contexts. [2] http://bytes.com/topic/c/answers/219859-do-while-0-macro-substitutions On 1/16/2014 1:57 PM, Ulf Zibis wrote: > Hi, > > thanks, I thought this is an endless loop until the inner condition is > fulfilled, not really noting, that 0==false (one more reason to use > true/false instead 1/0, IMHO). > > Can you explain the trick, why you use a one-time-loop instead of a > single statement? > > -Ulf > > > Am 16.01.2014 19:13, schrieb roger riggs: >> Hi, >> >> The current do {...} while(0) is the established idiom in the jdk. >> >> It does not have the potential problem of unintentionally allowing >> an infinite loop if the body contains a 'continue'. >> >> Roger >> >> On 1/16/2014 12:56 PM, Ulf Zibis wrote: >>> Am 16.01.2014 17:26, schrieb roger riggs: >>>> Please review: >>>> >>>> webrev: >>>> http://cr.openjdk.java.net/~rriggs/webrev-jnu-check-rename-8031737/ >>> >>> I more would like a "while (true)" loop, rather than a "do" loop. >>> >>> -Ulf >>> >> >> > From roger.riggs at oracle.com Thu Jan 16 19:51:09 2014 From: roger.riggs at oracle.com (roger riggs) Date: Thu, 16 Jan 2014 14:51:09 -0500 Subject: RFR: (8031737) rename jni_util.h macros for checking and returning on exceptions In-Reply-To: <52D82B7F.8030905@oracle.com> References: <52D8084F.5060801@oracle.com> <52D80BA6.2060002@oracle.com> <52D80D66.7090105@oracle.com> <52D8173E.9000700@oracle.com> <52D82B7F.8030905@oracle.com> Message-ID: <52D8382D.3060100@oracle.com> Hi Kumar, The parameter names are purely local to the macro. They do not need to be unique. If the macro was longer (though it is now a lot longer than the original), it might make the code more readable. (Though I'm sure someone has a different convention). Roger On 1/16/2014 1:57 PM, Kumar Srinivasan wrote: > Roger, > > one more thing, shouldn't the parameters be unique ? > I think Martin had me do this for all macros in the java launcher > for example please see this changeset, I recently pushed. > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6c50c972a101 > > Kumar > > On 1/16/2014 9:30 AM, Kumar Srinivasan wrote: >> Hi Roger, >> >> Its confusing to use a JNU_ prefixed macro on a method not involvng jni, >> why not rename these to modulo JNU_ ? >> >> I am cc'ing Alex as he has a related bug fix in his queue for pack's >> jni code. >> >> Kumar >> >>> Hi Alan, >>> >>> The macros are generally useful even without being used on a method >>> that >>> involves jni. An overly aggressive find caught the uses in >>> java/util/jar/pack. >>> >>> But yes, it might be better to limit their scope to functions that >>> involve jni. >>> >>> Roger >>> >>> >>> On 1/16/2014 11:41 AM, Alan Bateman wrote: >>>> On 16/01/2014 16:26, roger riggs wrote: >>>>> Please review: >>>>> >>>>> The native macros for checking and returning when exceptions >>>>> are thrown have been renamed to include the "JNU_" prefix >>>>> consistent with other functions in jni_util.h. >>>>> >>>>> The macros have been renamed and existing uses in the jdk repository >>>>> for networking, pack200, and have been updated. A jprt run has >>>>> passed (except for unrelated failures). >>>>> >>>>> webrev: >>>>> http://cr.openjdk.java.net/~rriggs/webrev-jnu-check-rename-8031737/ >>>> Did you mean to rename the CHECK_NULL and CHECK_NULL_RETURN macros? >>>> They don't require a JNIEnv so I'm wondering if JNU_* really make >>>> sense here. >>>> >>>> -Alan. >>> >> > From Ulf.Zibis at CoSoCo.de Thu Jan 16 20:15:19 2014 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Thu, 16 Jan 2014 21:15:19 +0100 Subject: RFR: (8031737) rename jni_util.h macros for checking and returning on exceptions In-Reply-To: <52D83685.2020007@oracle.com> References: <52D8084F.5060801@oracle.com> <52D81D6B.6090209@CoSoCo.de> <52D82143.9000707@oracle.com> <52D82BAD.7000100@CoSoCo.de> <52D83685.2020007@oracle.com> Message-ID: <52D83DD7.5000709@CoSoCo.de> Very much thanks Roger. I still would prefer "false" over "0" to avoid misinterpretation like I did :-( -Ulf Am 16.01.2014 20:44, schrieb roger riggs: > Check out the stackoverflow.com and bytes.com for explanations with examples. > Using the pattern gives consistent results in a wide range of source contexts > and parameter strings. Macros are textual substitutions; the c compiler > only sees it after all the substitutions are done. > > "The |do ... while| and |if ... else| are there to make it so that a semicolon after your macro > always means the same thing. Let's say you had something like your second macro." > > http://stackoverflow.com/questions/154136/do-while-and-if-else-statements-in-c-c-macros > > The whole idea of using 'do/while' version is to make a macro which will > expand into a regular statement, not into a compound statement. This is > done in order to make the use of function-style macros uniform with the > use of ordinary functions in all contexts. > > [2] http://bytes.com/topic/c/answers/219859-do-while-0-macro-substitutions > > > On 1/16/2014 1:57 PM, Ulf Zibis wrote: >> Hi, >> >> thanks, I thought this is an endless loop until the inner condition is fulfilled, not really >> noting, that 0==false (one more reason to use true/false instead 1/0, IMHO). >> >> Can you explain the trick, why you use a one-time-loop instead of a single statement? >> >> -Ulf >> >> >> Am 16.01.2014 19:13, schrieb roger riggs: >>> Hi, >>> >>> The current do {...} while(0) is the established idiom in the jdk. >>> >>> It does not have the potential problem of unintentionally allowing >>> an infinite loop if the body contains a 'continue'. >>> >>> Roger >>> >>> On 1/16/2014 12:56 PM, Ulf Zibis wrote: >>>> Am 16.01.2014 17:26, schrieb roger riggs: >>>>> Please review: >>>>> >>>>> webrev: >>>>> http://cr.openjdk.java.net/~rriggs/webrev-jnu-check-rename-8031737/ >>>> >>>> I more would like a "while (true)" loop, rather than a "do" loop. >>>> >>>> -Ulf >>>> >>> >>> >> > > From roger.riggs at oracle.com Thu Jan 16 21:49:41 2014 From: roger.riggs at oracle.com (roger riggs) Date: Thu, 16 Jan 2014 16:49:41 -0500 Subject: RFR: (8031737) rename jni_util.h macros for checking and returning on exceptions In-Reply-To: References: <52D8084F.5060801@oracle.com> Message-ID: <52D853F5.8060500@oracle.com> The webrev has been updated to revert the java.util.jar/pack CHECK_* macros and to clean up the macro definitions in jni_util.h. I plan to give the review some more time in case there are more comments coming. Roger > On Thu, Jan 16, 2014 at 8:26 AM, roger riggs > wrote: > > Please review: > > The native macros for checking and returning when exceptions > are thrown have been renamed to include the "JNU_" prefix > consistent with other functions in jni_util.h. > > The macros have been renamed and existing uses in the jdk repository > for networking, pack200, and have been updated. A jprt run has > passed (except for unrelated failures). > > webrev: > http://cr.openjdk.java.net/~rriggs/webrev-jnu-check-rename-8031737/ > > Thanks, Roger > > [1] https://bugs.openjdk.java.net/browse/JDK-8031737 > > From mike.duigou at oracle.com Thu Jan 16 22:44:08 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 16 Jan 2014 14:44:08 -0800 Subject: RFR 8029452: Fork/Join task ForEachOps.ForEachOrderedTask clarifications and minor improvements In-Reply-To: <2684FFB7-EA1D-4498-854B-43AA40A43D74@oracle.com> References: <6F2D7451-6826-4CC5-AE55-62BD97EB5264@oracle.com> <2684FFB7-EA1D-4498-854B-43AA40A43D74@oracle.com> Message-ID: Very helpful. Thank you for adding the comments. Mike On Jan 16 2014, at 03:26 , Paul Sandoz wrote: > > On Jan 10, 2014, at 2:42 PM, Paul Sandoz wrote: >> I have also removed the inconsistently applied synchronized block. Either we apply it consistently to reporting or not at all. It was originally there because we were not sure that the "happens-before" relationship [1] between elements would be guaranteed. However, ForEachOrderedTask sets up such a relationship via completion counts to ensure leaf nodes complete in encounter order (if any) where only one leaf can be completing (which was left most leaf that was not completed), hence stamping a fence in the ground at these point seems redundant (at least i cannot see its value but could be missing something subtle). >> > > I updated with some more comments explaining how the "happens-before" is preserved: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8029452-ForEachOrdered/webrev/ > > Paul. From joe.darcy at oracle.com Thu Jan 16 22:54:48 2014 From: joe.darcy at oracle.com (Joseph Darcy) Date: Thu, 16 Jan 2014 14:54:48 -0800 Subject: JDK 9 RFC on 6667086: Double.doubleToLongBits(final double value) contains inefficient test for NaN In-Reply-To: References: <52D8157C.2080402@oracle.com> Message-ID: <52D86338.8040308@oracle.com> Hi Brian, On 1/16/2014 10:51 AM, Brian Burkhalter wrote: > Hi Joe, > > On Jan 16, 2014, at 9:23 AM, Joe Darcy wrote: > >> A few comments here. If you are making this change in Double, you would make the corresponding change in Float too. > Please see the updated webrev http://cr.openjdk.java.net/~bpb/6667086/webrev.2/. New webrev looks good. > >> Some explanation on why I wrote these methods with the integer-field-based null check, some processors are implemented such that operating on the IEEE non-finite value of NaN and +/- infinity runs much more slowly than operating on normal value, sometimes orders of magnitude more slowly. >> >> For the bitwise conversion methods, since we were biting the bullet to do the conversion anyway, I thought I would avoid the worst-case cost of tripping over a NaN by doing the NaN check on the integer value. > Thanks for the explanation. Would {Double,Float}.isNaN() perhaps be good candidates for VM intrinsics? I don't think so. The canonical isNaN idiom is just (x != x) so normal inlining should cover it, assuming the processor has decent NaN support. -Joe From brian.burkhalter at oracle.com Fri Jan 17 00:18:35 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 16 Jan 2014 16:18:35 -0800 Subject: JDK 9 RFC on 6667086: Double.doubleToLongBits(final double value) contains inefficient test for NaN In-Reply-To: <52D86338.8040308@oracle.com> References: <52D8157C.2080402@oracle.com> <52D86338.8040308@oracle.com> Message-ID: <46364277-866D-42F0-831B-EC786777AAFC@oracle.com> Hi Joe, On Jan 16, 2014, at 2:54 PM, Joseph Darcy wrote: >> Please see the updated webrevhttp://cr.openjdk.java.net/~bpb/6667086/webrev.2/. > > New webrev looks good. The change has been pushed. Note that I filed this linked issue to capture the Math.next{After,Up}({float,double}) changes suggested in the comments on JDK-6667086: https://bugs.openjdk.java.net/browse/JDK-8032016 Thanks, Brian From david.holmes at oracle.com Fri Jan 17 02:16:59 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 Jan 2014 12:16:59 +1000 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52D82968.4030608@oracle.com> References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> <52CC72AB.2020104@oracle.com> <52CCEDE0.8000809@oracle.com> <52CCF079.4090301@oracle.com> <52CD45E7.7010203@gmail.com> <52CE4E2D.300@oracle.com> <52CF37C6.1070605@oracle.com> <52CFAFEB.9090703@gmail.com> <52CFD218.2060101@gmail.com> <52D06B70.60001@oracle.com> <52D15201.90109@gmail.com> <52D47D59.8040905@oracle.com> <52D72577.1050506@oracle.com> <52D76859.2030502@oracle.com> <52D82968.4030608@oracle.com> Message-ID: <52D8929B.2020905@oracle.com> On 17/01/2014 4:48 AM, srikalyan wrote: > Hi David > > On 1/15/14, 9:04 PM, David Holmes wrote: >> On 16/01/2014 10:19 AM, srikalyan chandrashekar wrote: >>> Hi Peter/David, we could finally get a trace of exception with fastdebug >>> build and ReferenceHandler modified (with runImpl() added and called >>> from run()). The logs, disassembled code is available in JIRA >>> as attachments. >> >> All I can see is the log for the OOMECatchingTest program not one for >> the actual ReferenceHandler ?? >> > Please search for ReferenceHandler in the log. >>> Observations from the log: >>> >>> Root Cause: >>> 1) UncaughtException is being dispatched from Reference.java:143 >>> 141 Reference r; >>> 142 synchronized (lock) { >>> 143 if (pending != null) { >>> 144 r = pending; >>> 145 pending = r.discovered; >>> 146 r.discovered = null; >>> >>> pending field in Reference is touched and updated by the collector, so >>> at line 143 when the execution context is in Reference handler there >>> might have been an Exception pending due to allocation done by collector >>> which causes ReferenceHandler thread to die. >> >> Sorry but the GC does not trigger asynchronous exceptions so this >> explanation does not make any sense to me. What part of the log led >> you to this conclusion? > ------------------ Log Excerpt begins ------------------ > Exception (0x00000000ff7808e8) > thrown > [/home/srikalyc/work/ora2013/infracleanup/jdk8/hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp, > line 168] > for thread 0x00007feed80cf800 > Exception (0x00000000ff7808e8) > thrown in interpreter method <{method} {0x00007feeddd3c600} 'runImpl' > '()V' in 'java/lang/ref/Reference$ReferenceHandler'> > at bci 65 for thread 0x00007feed80cf800 > Exception (0x00000000ff7808e8) > thrown in interpreter method <{method} {0x00007feeddd3c478} 'run' > '()V' in 'java/lang/ref/Reference$ReferenceHandler'> > at bci 1 for thread 0x00007feed80cf800 > Exception (0x00000000ff780868) > thrown > [/home/srikalyc/work/ora2013/infracleanup/jdk8/hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp, > line 157] > for thread 0x00007feed80cf800 > Exception (0x00000000ff780868) > thrown in interpreter method <{method} {0x00007feeddcaaf90} > 'uncaughtException' '(Ljava/lang/Thread;Ljava/lang/Throwable;)V' in '> > at bci 48 for thread 0x00007feed80cf800 > Exception (0x00000000ff780868) > thrown in interpreter method <{method} {0x00007feeddca7298} > 'dispatchUncaughtException' '(Ljava/lang/Throwable;)V' in 'java/lang/> > at bci 6 for thread 0x00007feed80cf800 > ------------------ Log Excerpt ends ------------------ > Sorry if it is a wrong understanding. What you are seeing there is an OOME escaping the run() method which will cause the uncaughtExceptionHandler to be run which then triggers a second OOME (likely as it tries to report information about the first OOME). The first exception occurred in runImpl at BCI 65. Can you disassemble (javap -c) the class you used so we can see what is at BCI 65. Thanks, David >> >>> Suggested fix: >>> - As proposed earlier putting an outer guard(try-catch on OOME) in the >>> ReferenceHandler will fix the issue, if ReferenceHandler is considered >>> as part of the GC sub system then it should be alive even in the midst >>> of an OOME so i feel that the additional guard should be allowed, >>> however i might still be ignorant of vital implications. >>> - Apart from the above changes, Peter's suggestion to create and call a >>> private runImpl() from run() in ReferenceHandler makes sense to me. >> >> Why would we need this? >> >> David >> ----- >> >>> >>> --- >>> Thanks >>> kalyan >>> >>> On 01/13/2014 03:57 PM, srikalyan wrote: >>>> >>>> On 1/11/14, 6:15 AM, Peter Levart wrote: >>>>> >>>>> On 01/10/2014 10:51 PM, srikalyan chandrashekar wrote: >>>>>> Hi Peter the version you provided ran indefinitely(i put a 10 minute >>>>>> timeout) and the program got interrupted(no error), >>>>> >>>>> Did you run it with or without fastedbug & -XX:+TraceExceptions ? If >>>>> with, it might be that fastdebug and/or -XX:+TraceExceptions changes >>>>> the execution a bit so that we can no longer reproduce the wrong >>>>> behaviour. >>>> With fastdebug & -XX:TraceExceptions. I will try combination of >>>> possible options(i.e without -XX:TraceEception on debug build etc) >>>> soon. >>>>> >>>>>> even if there were to be an error you cannot print the "string" of >>>>>> thread to console(these have been attempted earlier). >>>>> >>>>> ...it has been attempted to print toString in uncaught exception >>>>> handler. At that time, the heap is still full. I'm printing it after >>>>> the GC has cleared the heap. You can try that it works by commenting >>>>> out the "try {" and corresponding "} catch (OOME x) {}" exception >>>>> handler... >>>> Since there is a GC call prior to printing string i will give that a >>>> shot with non-debug build. >>>>> >>>>>> - The test's running on interpreter mode, what i am watching for is >>>>>> one error with trace. Without fastdebug build and >>>>>> -XX:+TraceExceptions i am able to reproduce failure atleast 5 >>>>>> failures out of 1000 runs but with fastdebug+Trace no luck >>>>>> yet(already past few 1000 runs). >>>>> >>>>> It might be interesting to try with fastebug build but without the >>>>> -XX:+TraceExceptions option to see what has an effect on it. It might >>>>> also be interesting to try the modified ReferenceHandler (the one >>>>> with private runImpl() method called from run()) and with normal >>>>> non-fastdebug JDK. This info might be useful when one starts to >>>>> inspect the exception handling code in interpreter... >>>>> >>>>> Regards, Peter >>>>> >>>> >>>> -- >>>> Thanks >>>> kalyan >>>> Ph: (408)-585-8040 >>>> >>>>>> >>>>>> --- >>>>>> Thanks >>>>>> kalyan >>>>>> >>>>>> On 01/10/2014 02:57 AM, Peter Levart wrote: >>>>>>> On 01/10/2014 09:31 AM, Peter Levart wrote: >>>>>>>> Since we suspect there's something wrong with exception handling >>>>>>>> in interpreter, I devised a hypothetical reproducer that tries to >>>>>>>> simulate ReferenceHandler in many aspects, but doesn't require to >>>>>>>> be a ReferenceHandler: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~plevart/misc/OOME/OOMECatchingTest.java >>>>>>>> >>>>>>>> This is designed to run indefinitely and only terminate if/when >>>>>>>> thread dies. Could you run this program in the environment that >>>>>>>> causes the OOMEInReferenceHandler test to fail and see if it >>>>>>>> terminates? >>>>>>> >>>>>>> I forgot to mention that in order for this long-running program to >>>>>>> exhibit interpreter behaviour, it should be run with -Xint option. >>>>>>> So I suggest: >>>>>>> >>>>>>> -Xmx24M -XX:-UseTLAB -Xint >>>>>>> >>>>>>> Regards, Peter >>>>>>> >>>>>> >>>>> >>> From srikalyan.chandrashekar at oracle.com Fri Jan 17 03:31:54 2014 From: srikalyan.chandrashekar at oracle.com (srikalyan chandrashekar) Date: Thu, 16 Jan 2014 19:31:54 -0800 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52D8929B.2020905@oracle.com> References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> <52CC72AB.2020104@oracle.com> <52CCEDE0.8000809@oracle.com> <52CCF079.4090301@oracle.com> <52CD45E7.7010203@gmail.com> <52CE4E2D.300@oracle.com> <52CF37C6.1070605@oracle.com> <52CFAFEB.9090703@gmail.com> <52CFD218.2060101@gmail.com> <52D06B70.60001@oracle.com> <52D15201.90109@gmail.com> <52D47D59.8040905@oracle.com> <52D72577.1050506@oracle.com> <52D76859.2030502@oracle.com> <52D82968.4030608@oracle.com> <52D8929B.2020905@oracle.com> Message-ID: <52D8A42A.4020906@oracle.com> Hi David, the disassembled code is also attached to the bug. Per my analysis the exception was thrown when Reference Handler was on line 143 as put in the earlier email. -- Thanks kalyan On 1/16/14 6:16 PM, David Holmes wrote: > On 17/01/2014 4:48 AM, srikalyan wrote: >> Hi David >> >> On 1/15/14, 9:04 PM, David Holmes wrote: >>> On 16/01/2014 10:19 AM, srikalyan chandrashekar wrote: >>>> Hi Peter/David, we could finally get a trace of exception with >>>> fastdebug >>>> build and ReferenceHandler modified (with runImpl() added and called >>>> from run()). The logs, disassembled code is available in JIRA >>>> as attachments. >>> >>> All I can see is the log for the OOMECatchingTest program not one for >>> the actual ReferenceHandler ?? >>> >> Please search for ReferenceHandler in the log. >>>> Observations from the log: >>>> >>>> Root Cause: >>>> 1) UncaughtException is being dispatched from Reference.java:143 >>>> 141 Reference r; >>>> 142 synchronized (lock) { >>>> 143 if (pending != null) { >>>> 144 r = pending; >>>> 145 pending = r.discovered; >>>> 146 r.discovered = null; >>>> >>>> pending field in Reference is touched and updated by the collector, so >>>> at line 143 when the execution context is in Reference handler there >>>> might have been an Exception pending due to allocation done by >>>> collector >>>> which causes ReferenceHandler thread to die. >>> >>> Sorry but the GC does not trigger asynchronous exceptions so this >>> explanation does not make any sense to me. What part of the log led >>> you to this conclusion? >> ------------------ Log Excerpt begins ------------------ >> Exception (0x00000000ff7808e8) >> thrown >> [/home/srikalyc/work/ora2013/infracleanup/jdk8/hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp, >> >> line 168] >> for thread 0x00007feed80cf800 >> Exception (0x00000000ff7808e8) >> thrown in interpreter method <{method} {0x00007feeddd3c600} 'runImpl' >> '()V' in 'java/lang/ref/Reference$ReferenceHandler'> >> at bci 65 for thread 0x00007feed80cf800 >> Exception (0x00000000ff7808e8) >> thrown in interpreter method <{method} {0x00007feeddd3c478} 'run' >> '()V' in 'java/lang/ref/Reference$ReferenceHandler'> >> at bci 1 for thread 0x00007feed80cf800 >> Exception (0x00000000ff780868) >> thrown >> [/home/srikalyc/work/ora2013/infracleanup/jdk8/hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp, >> >> line 157] >> for thread 0x00007feed80cf800 >> Exception (0x00000000ff780868) >> thrown in interpreter method <{method} {0x00007feeddcaaf90} >> 'uncaughtException' '(Ljava/lang/Thread;Ljava/lang/Throwable;)V' in '> >> at bci 48 for thread 0x00007feed80cf800 >> Exception (0x00000000ff780868) >> thrown in interpreter method <{method} {0x00007feeddca7298} >> 'dispatchUncaughtException' '(Ljava/lang/Throwable;)V' in 'java/lang/> >> at bci 6 for thread 0x00007feed80cf800 >> ------------------ Log Excerpt ends ------------------ >> Sorry if it is a wrong understanding. > > What you are seeing there is an OOME escaping the run() method which > will cause the uncaughtExceptionHandler to be run which then triggers > a second OOME (likely as it tries to report information about the > first OOME). The first exception occurred in runImpl at BCI 65. Can > you disassemble (javap -c) the class you used so we can see what is at > BCI 65. > > Thanks, > David > >>> >>>> Suggested fix: >>>> - As proposed earlier putting an outer guard(try-catch on OOME) in the >>>> ReferenceHandler will fix the issue, if ReferenceHandler is considered >>>> as part of the GC sub system then it should be alive even in the midst >>>> of an OOME so i feel that the additional guard should be allowed, >>>> however i might still be ignorant of vital implications. >>>> - Apart from the above changes, Peter's suggestion to create and >>>> call a >>>> private runImpl() from run() in ReferenceHandler makes sense to me. >>> >>> Why would we need this? >>> >>> David >>> ----- >>> >>>> >>>> --- >>>> Thanks >>>> kalyan >>>> >>>> On 01/13/2014 03:57 PM, srikalyan wrote: >>>>> >>>>> On 1/11/14, 6:15 AM, Peter Levart wrote: >>>>>> >>>>>> On 01/10/2014 10:51 PM, srikalyan chandrashekar wrote: >>>>>>> Hi Peter the version you provided ran indefinitely(i put a 10 >>>>>>> minute >>>>>>> timeout) and the program got interrupted(no error), >>>>>> >>>>>> Did you run it with or without fastedbug & -XX:+TraceExceptions ? If >>>>>> with, it might be that fastdebug and/or -XX:+TraceExceptions changes >>>>>> the execution a bit so that we can no longer reproduce the wrong >>>>>> behaviour. >>>>> With fastdebug & -XX:TraceExceptions. I will try combination of >>>>> possible options(i.e without -XX:TraceEception on debug build etc) >>>>> soon. >>>>>> >>>>>>> even if there were to be an error you cannot print the "string" of >>>>>>> thread to console(these have been attempted earlier). >>>>>> >>>>>> ...it has been attempted to print toString in uncaught exception >>>>>> handler. At that time, the heap is still full. I'm printing it after >>>>>> the GC has cleared the heap. You can try that it works by commenting >>>>>> out the "try {" and corresponding "} catch (OOME x) {}" exception >>>>>> handler... >>>>> Since there is a GC call prior to printing string i will give that a >>>>> shot with non-debug build. >>>>>> >>>>>>> - The test's running on interpreter mode, what i am watching for is >>>>>>> one error with trace. Without fastdebug build and >>>>>>> -XX:+TraceExceptions i am able to reproduce failure atleast 5 >>>>>>> failures out of 1000 runs but with fastdebug+Trace no luck >>>>>>> yet(already past few 1000 runs). >>>>>> >>>>>> It might be interesting to try with fastebug build but without the >>>>>> -XX:+TraceExceptions option to see what has an effect on it. It >>>>>> might >>>>>> also be interesting to try the modified ReferenceHandler (the one >>>>>> with private runImpl() method called from run()) and with normal >>>>>> non-fastdebug JDK. This info might be useful when one starts to >>>>>> inspect the exception handling code in interpreter... >>>>>> >>>>>> Regards, Peter >>>>>> >>>>> >>>>> -- >>>>> Thanks >>>>> kalyan >>>>> Ph: (408)-585-8040 >>>>> >>>>>>> >>>>>>> --- >>>>>>> Thanks >>>>>>> kalyan >>>>>>> >>>>>>> On 01/10/2014 02:57 AM, Peter Levart wrote: >>>>>>>> On 01/10/2014 09:31 AM, Peter Levart wrote: >>>>>>>>> Since we suspect there's something wrong with exception handling >>>>>>>>> in interpreter, I devised a hypothetical reproducer that tries to >>>>>>>>> simulate ReferenceHandler in many aspects, but doesn't require to >>>>>>>>> be a ReferenceHandler: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~plevart/misc/OOME/OOMECatchingTest.java >>>>>>>>> >>>>>>>>> >>>>>>>>> This is designed to run indefinitely and only terminate if/when >>>>>>>>> thread dies. Could you run this program in the environment that >>>>>>>>> causes the OOMEInReferenceHandler test to fail and see if it >>>>>>>>> terminates? >>>>>>>> >>>>>>>> I forgot to mention that in order for this long-running program to >>>>>>>> exhibit interpreter behaviour, it should be run with -Xint option. >>>>>>>> So I suggest: >>>>>>>> >>>>>>>> -Xmx24M -XX:-UseTLAB -Xint >>>>>>>> >>>>>>>> Regards, Peter >>>>>>>> >>>>>>> >>>>>> >>>> From david.holmes at oracle.com Fri Jan 17 04:38:14 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 Jan 2014 14:38:14 +1000 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52D8A42A.4020906@oracle.com> References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> <52CC72AB.2020104@oracle.com> <52CCEDE0.8000809@oracle.com> <52CCF079.4090301@oracle.com> <52CD45E7.7010203@gmail.com> <52CE4E2D.300@oracle.com> <52CF37C6.1070605@oracle.com> <52CFAFEB.9090703@gmail.com> <52CFD218.2060101@gmail.com> <52D06B70.60001@oracle.com> <52D15201.90109@gmail.com> <52D47D59.8040905@oracle.com> <52D72577.1050506@oracle.com> <52D76859.2030502@oracle.com> <52D82968.4030608@oracle.com> <52D8929B.2020905@oracle.com> <52D8A42A.4020906@oracle.com> Message-ID: <52D8B3B6.3030202@oracle.com> On 17/01/2014 1:31 PM, srikalyan chandrashekar wrote: > Hi David, the disassembled code is also attached to the bug. Per my Sorry missed that. > analysis the exception was thrown when Reference Handler was on line 143 > as put in the earlier email. But if the numbers in the dissassembly match the BCI then 65 shows: 65: instanceof #11 // class sun/misc/Cleaner which makes more sense, the runtime instanceof check might encounter an OOME condition. I wish there was some easy way to trace into the full call chain as TraceExceptions doesn't show you any runtime frames :( Still, it is easy enough to check: // Fast path for cleaners boolean isCleaner = false; try { isCleaner = r instanceof Cleaner; } catch (OutofMemoryError oome) { continue; } if (isCleaner) { ((Cleaner)r).clean(); continue; } Thanks, David > -- > Thanks > kalyan > > On 1/16/14 6:16 PM, David Holmes wrote: >> On 17/01/2014 4:48 AM, srikalyan wrote: >>> Hi David >>> >>> On 1/15/14, 9:04 PM, David Holmes wrote: >>>> On 16/01/2014 10:19 AM, srikalyan chandrashekar wrote: >>>>> Hi Peter/David, we could finally get a trace of exception with >>>>> fastdebug >>>>> build and ReferenceHandler modified (with runImpl() added and called >>>>> from run()). The logs, disassembled code is available in JIRA >>>>> as attachments. >>>> >>>> All I can see is the log for the OOMECatchingTest program not one for >>>> the actual ReferenceHandler ?? >>>> >>> Please search for ReferenceHandler in the log. >>>>> Observations from the log: >>>>> >>>>> Root Cause: >>>>> 1) UncaughtException is being dispatched from Reference.java:143 >>>>> 141 Reference r; >>>>> 142 synchronized (lock) { >>>>> 143 if (pending != null) { >>>>> 144 r = pending; >>>>> 145 pending = r.discovered; >>>>> 146 r.discovered = null; >>>>> >>>>> pending field in Reference is touched and updated by the collector, so >>>>> at line 143 when the execution context is in Reference handler there >>>>> might have been an Exception pending due to allocation done by >>>>> collector >>>>> which causes ReferenceHandler thread to die. >>>> >>>> Sorry but the GC does not trigger asynchronous exceptions so this >>>> explanation does not make any sense to me. What part of the log led >>>> you to this conclusion? >>> ------------------ Log Excerpt begins ------------------ >>> Exception (0x00000000ff7808e8) >>> thrown >>> [/home/srikalyc/work/ora2013/infracleanup/jdk8/hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp, >>> >>> line 168] >>> for thread 0x00007feed80cf800 >>> Exception (0x00000000ff7808e8) >>> thrown in interpreter method <{method} {0x00007feeddd3c600} 'runImpl' >>> '()V' in 'java/lang/ref/Reference$ReferenceHandler'> >>> at bci 65 for thread 0x00007feed80cf800 >>> Exception (0x00000000ff7808e8) >>> thrown in interpreter method <{method} {0x00007feeddd3c478} 'run' >>> '()V' in 'java/lang/ref/Reference$ReferenceHandler'> >>> at bci 1 for thread 0x00007feed80cf800 >>> Exception (0x00000000ff780868) >>> thrown >>> [/home/srikalyc/work/ora2013/infracleanup/jdk8/hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp, >>> >>> line 157] >>> for thread 0x00007feed80cf800 >>> Exception (0x00000000ff780868) >>> thrown in interpreter method <{method} {0x00007feeddcaaf90} >>> 'uncaughtException' '(Ljava/lang/Thread;Ljava/lang/Throwable;)V' in '> >>> at bci 48 for thread 0x00007feed80cf800 >>> Exception (0x00000000ff780868) >>> thrown in interpreter method <{method} {0x00007feeddca7298} >>> 'dispatchUncaughtException' '(Ljava/lang/Throwable;)V' in 'java/lang/> >>> at bci 6 for thread 0x00007feed80cf800 >>> ------------------ Log Excerpt ends ------------------ >>> Sorry if it is a wrong understanding. >> >> What you are seeing there is an OOME escaping the run() method which >> will cause the uncaughtExceptionHandler to be run which then triggers >> a second OOME (likely as it tries to report information about the >> first OOME). The first exception occurred in runImpl at BCI 65. Can >> you disassemble (javap -c) the class you used so we can see what is at >> BCI 65. >> >> Thanks, >> David >> >>>> >>>>> Suggested fix: >>>>> - As proposed earlier putting an outer guard(try-catch on OOME) in the >>>>> ReferenceHandler will fix the issue, if ReferenceHandler is considered >>>>> as part of the GC sub system then it should be alive even in the midst >>>>> of an OOME so i feel that the additional guard should be allowed, >>>>> however i might still be ignorant of vital implications. >>>>> - Apart from the above changes, Peter's suggestion to create and >>>>> call a >>>>> private runImpl() from run() in ReferenceHandler makes sense to me. >>>> >>>> Why would we need this? >>>> >>>> David >>>> ----- >>>> >>>>> >>>>> --- >>>>> Thanks >>>>> kalyan >>>>> >>>>> On 01/13/2014 03:57 PM, srikalyan wrote: >>>>>> >>>>>> On 1/11/14, 6:15 AM, Peter Levart wrote: >>>>>>> >>>>>>> On 01/10/2014 10:51 PM, srikalyan chandrashekar wrote: >>>>>>>> Hi Peter the version you provided ran indefinitely(i put a 10 >>>>>>>> minute >>>>>>>> timeout) and the program got interrupted(no error), >>>>>>> >>>>>>> Did you run it with or without fastedbug & -XX:+TraceExceptions ? If >>>>>>> with, it might be that fastdebug and/or -XX:+TraceExceptions changes >>>>>>> the execution a bit so that we can no longer reproduce the wrong >>>>>>> behaviour. >>>>>> With fastdebug & -XX:TraceExceptions. I will try combination of >>>>>> possible options(i.e without -XX:TraceEception on debug build etc) >>>>>> soon. >>>>>>> >>>>>>>> even if there were to be an error you cannot print the "string" of >>>>>>>> thread to console(these have been attempted earlier). >>>>>>> >>>>>>> ...it has been attempted to print toString in uncaught exception >>>>>>> handler. At that time, the heap is still full. I'm printing it after >>>>>>> the GC has cleared the heap. You can try that it works by commenting >>>>>>> out the "try {" and corresponding "} catch (OOME x) {}" exception >>>>>>> handler... >>>>>> Since there is a GC call prior to printing string i will give that a >>>>>> shot with non-debug build. >>>>>>> >>>>>>>> - The test's running on interpreter mode, what i am watching for is >>>>>>>> one error with trace. Without fastdebug build and >>>>>>>> -XX:+TraceExceptions i am able to reproduce failure atleast 5 >>>>>>>> failures out of 1000 runs but with fastdebug+Trace no luck >>>>>>>> yet(already past few 1000 runs). >>>>>>> >>>>>>> It might be interesting to try with fastebug build but without the >>>>>>> -XX:+TraceExceptions option to see what has an effect on it. It >>>>>>> might >>>>>>> also be interesting to try the modified ReferenceHandler (the one >>>>>>> with private runImpl() method called from run()) and with normal >>>>>>> non-fastdebug JDK. This info might be useful when one starts to >>>>>>> inspect the exception handling code in interpreter... >>>>>>> >>>>>>> Regards, Peter >>>>>>> >>>>>> >>>>>> -- >>>>>> Thanks >>>>>> kalyan >>>>>> Ph: (408)-585-8040 >>>>>> >>>>>>>> >>>>>>>> --- >>>>>>>> Thanks >>>>>>>> kalyan >>>>>>>> >>>>>>>> On 01/10/2014 02:57 AM, Peter Levart wrote: >>>>>>>>> On 01/10/2014 09:31 AM, Peter Levart wrote: >>>>>>>>>> Since we suspect there's something wrong with exception handling >>>>>>>>>> in interpreter, I devised a hypothetical reproducer that tries to >>>>>>>>>> simulate ReferenceHandler in many aspects, but doesn't require to >>>>>>>>>> be a ReferenceHandler: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~plevart/misc/OOME/OOMECatchingTest.java >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> This is designed to run indefinitely and only terminate if/when >>>>>>>>>> thread dies. Could you run this program in the environment that >>>>>>>>>> causes the OOMEInReferenceHandler test to fail and see if it >>>>>>>>>> terminates? >>>>>>>>> >>>>>>>>> I forgot to mention that in order for this long-running program to >>>>>>>>> exhibit interpreter behaviour, it should be run with -Xint option. >>>>>>>>> So I suggest: >>>>>>>>> >>>>>>>>> -Xmx24M -XX:-UseTLAB -Xint >>>>>>>>> >>>>>>>>> Regards, Peter >>>>>>>>> >>>>>>>> >>>>>>> >>>>> > From srikalyan.chandrashekar at oracle.com Fri Jan 17 06:01:41 2014 From: srikalyan.chandrashekar at oracle.com (srikalyan chandrashekar) Date: Thu, 16 Jan 2014 22:01:41 -0800 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52D8B3B6.3030202@oracle.com> References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> <52CC72AB.2020104@oracle.com> <52CCEDE0.8000809@oracle.com> <52CCF079.4090301@oracle.com> <52CD45E7.7010203@gmail.com> <52CE4E2D.300@oracle.com> <52CF37C6.1070605@oracle.com> <52CFAFEB.9090703@gmail.com> <52CFD218.2060101@gmail.com> <52D06B70.60001@oracle.com> <52D15201.90109@gmail.com> <52D47D59.8040905@oracle.com> <52D72577.1050506@oracle.com> <52D76859.2030502@oracle.com> <52D82968.4030608@oracle.com> <52D8929B.2020905@oracle.com> <52D8A42A.4020906@oracle.com> <52D8B3B6.3030202@oracle.com> Message-ID: <52D8C745.3090004@oracle.com> On 1/16/14 8:38 PM, David Holmes wrote: > On 17/01/2014 1:31 PM, srikalyan chandrashekar wrote: >> Hi David, the disassembled code is also attached to the bug. Per my > > Sorry missed that. > >> analysis the exception was thrown when Reference Handler was on line 143 >> as put in the earlier email. > > But if the numbers in the dissassembly match the BCI then 65 shows: > > 65: instanceof #11 // class sun/misc/Cleaner > > which makes more sense, the runtime instanceof check might encounter > an OOME condition. I wish there was some easy way to trace into the > full call chain as TraceExceptions doesn't show you any runtime frames :( > > Still, it is easy enough to check: > > // Fast path for cleaners > boolean isCleaner = false; > try { > isCleaner = r instanceof Cleaner; > } catch (OutofMemoryError oome) { > continue; > } Will get this into build and give a shot soon, in the log if you see bci 6 and bci 48 are where dispatch and uncaught exceptions are raised(please correct me if i am wrong), i assumed its from ReferenceHandler thread as it says the same thread Id 0x00007feed80cf800. > > if (isCleaner) { > ((Cleaner)r).clean(); > continue; > } > > Thanks, > David > >> -- >> Thanks >> kalyan >> >> On 1/16/14 6:16 PM, David Holmes wrote: >>> On 17/01/2014 4:48 AM, srikalyan wrote: >>>> Hi David >>>> >>>> On 1/15/14, 9:04 PM, David Holmes wrote: >>>>> On 16/01/2014 10:19 AM, srikalyan chandrashekar wrote: >>>>>> Hi Peter/David, we could finally get a trace of exception with >>>>>> fastdebug >>>>>> build and ReferenceHandler modified (with runImpl() added and called >>>>>> from run()). The logs, disassembled code is available in JIRA >>>>>> as attachments. >>>>> >>>>> All I can see is the log for the OOMECatchingTest program not one for >>>>> the actual ReferenceHandler ?? >>>>> >>>> Please search for ReferenceHandler in the log. >>>>>> Observations from the log: >>>>>> >>>>>> Root Cause: >>>>>> 1) UncaughtException is being dispatched from Reference.java:143 >>>>>> 141 Reference r; >>>>>> 142 synchronized (lock) { >>>>>> 143 if (pending != null) { >>>>>> 144 r = pending; >>>>>> 145 pending = r.discovered; >>>>>> 146 r.discovered = null; >>>>>> >>>>>> pending field in Reference is touched and updated by the >>>>>> collector, so >>>>>> at line 143 when the execution context is in Reference handler there >>>>>> might have been an Exception pending due to allocation done by >>>>>> collector >>>>>> which causes ReferenceHandler thread to die. >>>>> >>>>> Sorry but the GC does not trigger asynchronous exceptions so this >>>>> explanation does not make any sense to me. What part of the log led >>>>> you to this conclusion? >>>> ------------------ Log Excerpt begins ------------------ >>>> Exception (0x00000000ff7808e8) >>>> thrown >>>> [/home/srikalyc/work/ora2013/infracleanup/jdk8/hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp, >>>> >>>> >>>> line 168] >>>> for thread 0x00007feed80cf800 >>>> Exception (0x00000000ff7808e8) >>>> thrown in interpreter method <{method} {0x00007feeddd3c600} >>>> 'runImpl' >>>> '()V' in 'java/lang/ref/Reference$ReferenceHandler'> >>>> at bci 65 for thread 0x00007feed80cf800 >>>> Exception (0x00000000ff7808e8) >>>> thrown in interpreter method <{method} {0x00007feeddd3c478} 'run' >>>> '()V' in 'java/lang/ref/Reference$ReferenceHandler'> >>>> at bci 1 for thread 0x00007feed80cf800 >>>> Exception (0x00000000ff780868) >>>> thrown >>>> [/home/srikalyc/work/ora2013/infracleanup/jdk8/hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp, >>>> >>>> >>>> line 157] >>>> for thread 0x00007feed80cf800 >>>> Exception (0x00000000ff780868) >>>> thrown in interpreter method <{method} {0x00007feeddcaaf90} >>>> 'uncaughtException' '(Ljava/lang/Thread;Ljava/lang/Throwable;)V' in '> >>>> at bci 48 for thread 0x00007feed80cf800 >>>> Exception (0x00000000ff780868) >>>> thrown in interpreter method <{method} {0x00007feeddca7298} >>>> 'dispatchUncaughtException' '(Ljava/lang/Throwable;)V' in 'java/lang/> >>>> at bci 6 for thread 0x00007feed80cf800 >>>> ------------------ Log Excerpt ends ------------------ >>>> Sorry if it is a wrong understanding. >>> >>> What you are seeing there is an OOME escaping the run() method which >>> will cause the uncaughtExceptionHandler to be run which then triggers >>> a second OOME (likely as it tries to report information about the >>> first OOME). The first exception occurred in runImpl at BCI 65. Can >>> you disassemble (javap -c) the class you used so we can see what is at >>> BCI 65. >>> >>> Thanks, >>> David >>> >>>>> >>>>>> Suggested fix: >>>>>> - As proposed earlier putting an outer guard(try-catch on OOME) >>>>>> in the >>>>>> ReferenceHandler will fix the issue, if ReferenceHandler is >>>>>> considered >>>>>> as part of the GC sub system then it should be alive even in the >>>>>> midst >>>>>> of an OOME so i feel that the additional guard should be allowed, >>>>>> however i might still be ignorant of vital implications. >>>>>> - Apart from the above changes, Peter's suggestion to create and >>>>>> call a >>>>>> private runImpl() from run() in ReferenceHandler makes sense to me. >>>>> >>>>> Why would we need this? >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> >>>>>> --- >>>>>> Thanks >>>>>> kalyan >>>>>> >>>>>> On 01/13/2014 03:57 PM, srikalyan wrote: >>>>>>> >>>>>>> On 1/11/14, 6:15 AM, Peter Levart wrote: >>>>>>>> >>>>>>>> On 01/10/2014 10:51 PM, srikalyan chandrashekar wrote: >>>>>>>>> Hi Peter the version you provided ran indefinitely(i put a 10 >>>>>>>>> minute >>>>>>>>> timeout) and the program got interrupted(no error), >>>>>>>> >>>>>>>> Did you run it with or without fastedbug & -XX:+TraceExceptions >>>>>>>> ? If >>>>>>>> with, it might be that fastdebug and/or -XX:+TraceExceptions >>>>>>>> changes >>>>>>>> the execution a bit so that we can no longer reproduce the wrong >>>>>>>> behaviour. >>>>>>> With fastdebug & -XX:TraceExceptions. I will try combination of >>>>>>> possible options(i.e without -XX:TraceEception on debug build etc) >>>>>>> soon. >>>>>>>> >>>>>>>>> even if there were to be an error you cannot print the >>>>>>>>> "string" of >>>>>>>>> thread to console(these have been attempted earlier). >>>>>>>> >>>>>>>> ...it has been attempted to print toString in uncaught exception >>>>>>>> handler. At that time, the heap is still full. I'm printing it >>>>>>>> after >>>>>>>> the GC has cleared the heap. You can try that it works by >>>>>>>> commenting >>>>>>>> out the "try {" and corresponding "} catch (OOME x) {}" exception >>>>>>>> handler... >>>>>>> Since there is a GC call prior to printing string i will give >>>>>>> that a >>>>>>> shot with non-debug build. >>>>>>>> >>>>>>>>> - The test's running on interpreter mode, what i am watching >>>>>>>>> for is >>>>>>>>> one error with trace. Without fastdebug build and >>>>>>>>> -XX:+TraceExceptions i am able to reproduce failure atleast 5 >>>>>>>>> failures out of 1000 runs but with fastdebug+Trace no luck >>>>>>>>> yet(already past few 1000 runs). >>>>>>>> >>>>>>>> It might be interesting to try with fastebug build but without the >>>>>>>> -XX:+TraceExceptions option to see what has an effect on it. It >>>>>>>> might >>>>>>>> also be interesting to try the modified ReferenceHandler (the one >>>>>>>> with private runImpl() method called from run()) and with normal >>>>>>>> non-fastdebug JDK. This info might be useful when one starts to >>>>>>>> inspect the exception handling code in interpreter... >>>>>>>> >>>>>>>> Regards, Peter >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Thanks >>>>>>> kalyan >>>>>>> Ph: (408)-585-8040 >>>>>>> >>>>>>>>> >>>>>>>>> --- >>>>>>>>> Thanks >>>>>>>>> kalyan >>>>>>>>> >>>>>>>>> On 01/10/2014 02:57 AM, Peter Levart wrote: >>>>>>>>>> On 01/10/2014 09:31 AM, Peter Levart wrote: >>>>>>>>>>> Since we suspect there's something wrong with exception >>>>>>>>>>> handling >>>>>>>>>>> in interpreter, I devised a hypothetical reproducer that >>>>>>>>>>> tries to >>>>>>>>>>> simulate ReferenceHandler in many aspects, but doesn't >>>>>>>>>>> require to >>>>>>>>>>> be a ReferenceHandler: >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~plevart/misc/OOME/OOMECatchingTest.java >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This is designed to run indefinitely and only terminate if/when >>>>>>>>>>> thread dies. Could you run this program in the environment that >>>>>>>>>>> causes the OOMEInReferenceHandler test to fail and see if it >>>>>>>>>>> terminates? >>>>>>>>>> >>>>>>>>>> I forgot to mention that in order for this long-running >>>>>>>>>> program to >>>>>>>>>> exhibit interpreter behaviour, it should be run with -Xint >>>>>>>>>> option. >>>>>>>>>> So I suggest: >>>>>>>>>> >>>>>>>>>> -Xmx24M -XX:-UseTLAB -Xint >>>>>>>>>> >>>>>>>>>> Regards, Peter >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >> From Alan.Bateman at oracle.com Fri Jan 17 09:48:46 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 17 Jan 2014 09:48:46 +0000 Subject: RFR(S/L): 8028537: PPC64: Updated the JDK regression tests to run on AIX In-Reply-To: References: <52D58C55.6070004@oracle.com> Message-ID: <52D8FC7E.5080908@oracle.com> On 15/01/2014 16:42, Volker Simonis wrote: > Hi Alan, > > thanks for the suggestion. That's fine for me. I've copied the empty > SCTP stubs from the macosx to the aix directory as well and updated > the make file accordingly (in the patch for "8031581: PPC64: Addons > and fixes for AIX to pass the jdk regression tests"). > > Therefore, the changes to the three tests: > > test/com/sun/nio/sctp/SctpChannel/Util.java > test/com/sun/nio/sctp/SctpMultiChannel/Util.java > test/com/sun/nio/sctp/SctpServerChannel/Util.java > > can be considered obsolete. Thanks, I think this makes the most sense. I looked through the rest of this webrev and the update to the tests looks fine. One general comment is that for many of these shell tests (that survive the current effort to replace them) is that we could move the Unix handling into the match any case so that we don't have to list each of Linux, SunOS, Darwin, ... I think this came up when the OS X port was brought in but there wasn't any follow-up on it. I am not suggesting you do this here, it's just a comment as I see same change to so many tests. A minor comment on SBC.java is that it could just catch UnsupportedOperationException on L238, that would avoid needing to check os.name. A really minor comment on the updates to ProblemList.txt is that the JMX test should probably be in the jdk_jmx section (it's just a convention that we've been using, it doesn't of course really matter where tests are listed). -Alan From miroslav.kos at oracle.com Fri Jan 17 09:57:29 2014 From: miroslav.kos at oracle.com (Miroslav Kos) Date: Fri, 17 Jan 2014 10:57:29 +0100 Subject: JDK8 RFR JDK-8029237 Update copyright year to match last edit in jdk8 jaxws repository for 2013 In-Reply-To: <52D0286B.9020108@oracle.com> References: <52D0286B.9020108@oracle.com> Message-ID: <52D8FE89.9080603@oracle.com> Hi Steve and Alan, I just reminding this issue - I have no response from anybody yet and it would really simplify our integration if I could handle copyright years inconsistencies this way - I see this issue in many jdk branches and these "each-branch-different" changes make each integration much more pain. Thanks for any idea on this. Miran On 10/01/14 18:05, Miroslav Kos wrote: > Hi, > this is about fixing copyright years for jdk8 (!); the incorrect years > found for both 2012 and 2013, so not to confuse script > jdk8/make/scripts/update_copyright_year.sh > it is necessary to use option -d "" for commit. I tested that > and it seems to work perfect. > I used following: > > [2012 modifications] > hg commit -u mkos -l ../2012-msg.txt -d "2012-12-30" > > [2013 modifications] > hg commit -u mkos -l ../2013-msg.txt -d "2013-12-30" > > When commits performed with past date, update_copyright_year.sh script > finds those in proper years. Since I am not familiar with using webrev > for pushing changes, I exported both revisions into separate patches: > > 2012: http://cr.openjdk.java.net/~mkos/8029237/copyrights-2012.patch > 2013: http://cr.openjdk.java.net/~mkos/8029237/copyrights-2013.patch > all changes webrev: > http://cr.openjdk.java.net/~mkos/8029237/webrev-all.00/ (upload > still in progress, I hope it doesn't take more than 30 mins) > bug: https://bugs.openjdk.java.net/browse/JDK-8029237 > > Regards > Miran From volker.simonis at gmail.com Fri Jan 17 11:25:24 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 17 Jan 2014 12:25:24 +0100 Subject: RFR(M): 8031997: PPC64: Make the various POLL constants system dependant Message-ID: Hi, could you please review the following change which makes the various POLL constants used in sun.nio.ch platform dependant: http://cr.openjdk.java.net/~simonis/webrevs/8031997/ These changes are currently targeted for the ppc-aix-port/stage-9 repository but it is planned to merge them soon into jdk9 and jdk8u-dev (for 8u20). Currently, various constants used for the poll/epoll/pollset system calls are defined multiple times as public static final short constants in various Java files: src/share/classes/sun/nio/ch/AbstractPollArrayWrapper.java src/solaris/classes/sun/nio/ch/Port.java Until now, this has not been a problem because on Linux, Solaris and MacOSX these constants have the same values. However on Windows and AIX they are different. While this hasn't been a problem on Windows either, because as far as I can see, we don't directly use WSAPoll() until now and the POLL constants are only used 'symbolically' on Windows, it became a real problem for the AIX port. To avoid a mapping of the Java constants to the native ones every time we go from Java to Native and back, this change replaces the currently used constants with a single instance of constants which is placed in src/share/classes/sun/nio/ch/Net.java and which are dynamically initialized from native methods with the correct, platfrom-specific values. So this change replaces every occurrence of POLL*, Port.POLL* or AbstractPollArrayWrapper.POLL* in Java code with the corresponding Net.POLL* constants. However, there's one exception to this rule: I haven't changed the POLL constants in src/solaris/classes/sun/nio/ch/DevPollArrayWrapper.java. That is not only because DevPollArrayWrapper is Solaris-specific and only used there, but mainly because it uses several, non-standard POLL constants which are only available and meaningful on Solaris and I didn't wanted to bloat the amount of generic constants defined in Net.java. I also didn't updated the constants under src/solaris/demo/jni/Poller because that's a Solaris-specific demo anyway. With Windows, I was a little confused in the beginning. I think until now we don't really use the WSAPoll() functionality there. That's probably because it is only available since Windows Vista / Windows Server 2008 (see http://msdn.microsoft.com/en-us/library/windows/desktop/ms741669%28v=vs.85%29.aspx). As far as I understand, the constants are only used "symbolically", to drive the underlying, select() based implementation. I've therefore decided to use the "true" POLL constants on Windows if they are available. Otherwise I'll use the hard-wired (Solaris-based) values. Another Windows peculiarity is the fact that POLLCONN is defined with a value different to all other constants while it equals to POLLOUT on the Unix platforms. I don't know if this is really necessary, but I kept this behaviour in my change. Notice that his change will allow us to directly used the WSAPoll() functionality on Windows in the future. I've compiled and smoke-tested the changes on Linux/x86_64/PPC64, Windows/x86_64, Solaris/SPARC, MacOS X and AIX. On all these platforms they pass all the java/nio JTREG tests in the same way like without this change. This means that on Linux/MacOS they pass all 261/256 tests, on Windows, they pass 258 tests while the following two tests fail: java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java java/nio/channels/DatagramChannel/Promiscuous.java But as I wrote before, these two test also fail without my changes applied, so I'm confident that the failures aren't related to this change. On Solaris, 258 test pass and only the java/nio/charset/Charset/default.sh test fails which isn't related to these changes either. Thank you and best regards, Volker From Alan.Bateman at oracle.com Fri Jan 17 11:44:48 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 17 Jan 2014 11:44:48 +0000 Subject: RFR(M): 8031997: PPC64: Make the various POLL constants system dependant In-Reply-To: References: Message-ID: <52D917B0.9090407@oracle.com> On 17/01/2014 11:25, Volker Simonis wrote: > : > > I've compiled and smoke-tested the changes on Linux/x86_64/PPC64, > Windows/x86_64, Solaris/SPARC, MacOS X and AIX. On all these platforms > they pass all the java/nio JTREG tests in the same way like without > this change. This means that on Linux/MacOS they pass all 261/256 > tests, on Windows, they pass 258 tests while the following two tests > fail: > > java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java > java/nio/channels/DatagramChannel/Promiscuous.java > > But as I wrote before, these two test also fail without my changes > applied, so I'm confident that the failures aren't related to this > change. Any chance that this is firewall configuration or VPN that might be cause packets to be dropped? These tests should otherwise pass consistently on all platforms. If you have output from Linux or Solaris or OS X that you could send then it might help to diagnose this. -Alan From peter.levart at gmail.com Fri Jan 17 13:00:13 2014 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 17 Jan 2014 14:00:13 +0100 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52D8B3B6.3030202@oracle.com> References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> <52CC72AB.2020104@oracle.com> <52CCEDE0.8000809@oracle.com> <52CCF079.4090301@oracle.com> <52CD45E7.7010203@gmail.com> <52CE4E2D.300@oracle.com> <52CF37C6.1070605@oracle.com> <52CFAFEB.9090703@gmail.com> <52CFD218.2060101@gmail.com> <52D06B70.60001@oracle.com> <52D15201.90109@gmail.com> <52D47D59.8040905@oracle.com> <52D72577.1050506@oracle.com> <52D76859.2030502@oracle.com> <52D82968.4030608@oracle.com> <52D8929B.2020905@oracle.com> <52D8A42A.4020906@oracle.com> <52D8B3B6.3030202@oracle.com> Message-ID: <52D9295D.6080106@gmail.com> On 01/17/2014 05:38 AM, David Holmes wrote: > On 17/01/2014 1:31 PM, srikalyan chandrashekar wrote: >> Hi David, the disassembled code is also attached to the bug. Per my > > Sorry missed that. > >> analysis the exception was thrown when Reference Handler was on line 143 >> as put in the earlier email. > > But if the numbers in the dissassembly match the BCI then 65 shows: > > 65: instanceof #11 // class sun/misc/Cleaner > > which makes more sense, the runtime instanceof check might encounter > an OOME condition. I wish there was some easy way to trace into the > full call chain as TraceExceptions doesn't show you any runtime frames :( > > Still, it is easy enough to check: > > // Fast path for cleaners > boolean isCleaner = false; > try { > isCleaner = r instanceof Cleaner; > } catch (OutofMemoryError oome) { > continue; > } > > if (isCleaner) { > ((Cleaner)r).clean(); > continue; > } > Hi David, Kalyan, I've caught-up now. Just thinking: is "instanceof Cleaner" throwing OOME as a result of loading the Cleaner class? Wouldn't the above code then throw some error also in ((Cleaner)r) - the checkcast, since Cleaner class would not be successfully initialized? Perhaps we should pre-load and initialize the Cleaner class as part of ReferenceHandler initialization... Regards, Peter > Thanks, > David > >> -- >> Thanks >> kalyan >> >> On 1/16/14 6:16 PM, David Holmes wrote: >>> On 17/01/2014 4:48 AM, srikalyan wrote: >>>> Hi David >>>> >>>> On 1/15/14, 9:04 PM, David Holmes wrote: >>>>> On 16/01/2014 10:19 AM, srikalyan chandrashekar wrote: >>>>>> Hi Peter/David, we could finally get a trace of exception with >>>>>> fastdebug >>>>>> build and ReferenceHandler modified (with runImpl() added and called >>>>>> from run()). The logs, disassembled code is available in JIRA >>>>>> as attachments. >>>>> >>>>> All I can see is the log for the OOMECatchingTest program not one for >>>>> the actual ReferenceHandler ?? >>>>> >>>> Please search for ReferenceHandler in the log. >>>>>> Observations from the log: >>>>>> >>>>>> Root Cause: >>>>>> 1) UncaughtException is being dispatched from Reference.java:143 >>>>>> 141 Reference r; >>>>>> 142 synchronized (lock) { >>>>>> 143 if (pending != null) { >>>>>> 144 r = pending; >>>>>> 145 pending = r.discovered; >>>>>> 146 r.discovered = null; >>>>>> >>>>>> pending field in Reference is touched and updated by the >>>>>> collector, so >>>>>> at line 143 when the execution context is in Reference handler there >>>>>> might have been an Exception pending due to allocation done by >>>>>> collector >>>>>> which causes ReferenceHandler thread to die. >>>>> >>>>> Sorry but the GC does not trigger asynchronous exceptions so this >>>>> explanation does not make any sense to me. What part of the log led >>>>> you to this conclusion? >>>> ------------------ Log Excerpt begins ------------------ >>>> Exception (0x00000000ff7808e8) >>>> thrown >>>> [/home/srikalyc/work/ora2013/infracleanup/jdk8/hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp, >>>> >>>> >>>> line 168] >>>> for thread 0x00007feed80cf800 >>>> Exception (0x00000000ff7808e8) >>>> thrown in interpreter method <{method} {0x00007feeddd3c600} >>>> 'runImpl' >>>> '()V' in 'java/lang/ref/Reference$ReferenceHandler'> >>>> at bci 65 for thread 0x00007feed80cf800 >>>> Exception (0x00000000ff7808e8) >>>> thrown in interpreter method <{method} {0x00007feeddd3c478} 'run' >>>> '()V' in 'java/lang/ref/Reference$ReferenceHandler'> >>>> at bci 1 for thread 0x00007feed80cf800 >>>> Exception (0x00000000ff780868) >>>> thrown >>>> [/home/srikalyc/work/ora2013/infracleanup/jdk8/hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp, >>>> >>>> >>>> line 157] >>>> for thread 0x00007feed80cf800 >>>> Exception (0x00000000ff780868) >>>> thrown in interpreter method <{method} {0x00007feeddcaaf90} >>>> 'uncaughtException' '(Ljava/lang/Thread;Ljava/lang/Throwable;)V' in '> >>>> at bci 48 for thread 0x00007feed80cf800 >>>> Exception (0x00000000ff780868) >>>> thrown in interpreter method <{method} {0x00007feeddca7298} >>>> 'dispatchUncaughtException' '(Ljava/lang/Throwable;)V' in 'java/lang/> >>>> at bci 6 for thread 0x00007feed80cf800 >>>> ------------------ Log Excerpt ends ------------------ >>>> Sorry if it is a wrong understanding. >>> >>> What you are seeing there is an OOME escaping the run() method which >>> will cause the uncaughtExceptionHandler to be run which then triggers >>> a second OOME (likely as it tries to report information about the >>> first OOME). The first exception occurred in runImpl at BCI 65. Can >>> you disassemble (javap -c) the class you used so we can see what is at >>> BCI 65. >>> >>> Thanks, >>> David >>> >>>>> >>>>>> Suggested fix: >>>>>> - As proposed earlier putting an outer guard(try-catch on OOME) >>>>>> in the >>>>>> ReferenceHandler will fix the issue, if ReferenceHandler is >>>>>> considered >>>>>> as part of the GC sub system then it should be alive even in the >>>>>> midst >>>>>> of an OOME so i feel that the additional guard should be allowed, >>>>>> however i might still be ignorant of vital implications. >>>>>> - Apart from the above changes, Peter's suggestion to create and >>>>>> call a >>>>>> private runImpl() from run() in ReferenceHandler makes sense to me. >>>>> >>>>> Why would we need this? >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> >>>>>> --- >>>>>> Thanks >>>>>> kalyan >>>>>> >>>>>> On 01/13/2014 03:57 PM, srikalyan wrote: >>>>>>> >>>>>>> On 1/11/14, 6:15 AM, Peter Levart wrote: >>>>>>>> >>>>>>>> On 01/10/2014 10:51 PM, srikalyan chandrashekar wrote: >>>>>>>>> Hi Peter the version you provided ran indefinitely(i put a 10 >>>>>>>>> minute >>>>>>>>> timeout) and the program got interrupted(no error), >>>>>>>> >>>>>>>> Did you run it with or without fastedbug & -XX:+TraceExceptions >>>>>>>> ? If >>>>>>>> with, it might be that fastdebug and/or -XX:+TraceExceptions >>>>>>>> changes >>>>>>>> the execution a bit so that we can no longer reproduce the wrong >>>>>>>> behaviour. >>>>>>> With fastdebug & -XX:TraceExceptions. I will try combination of >>>>>>> possible options(i.e without -XX:TraceEception on debug build etc) >>>>>>> soon. >>>>>>>> >>>>>>>>> even if there were to be an error you cannot print the >>>>>>>>> "string" of >>>>>>>>> thread to console(these have been attempted earlier). >>>>>>>> >>>>>>>> ...it has been attempted to print toString in uncaught exception >>>>>>>> handler. At that time, the heap is still full. I'm printing it >>>>>>>> after >>>>>>>> the GC has cleared the heap. You can try that it works by >>>>>>>> commenting >>>>>>>> out the "try {" and corresponding "} catch (OOME x) {}" exception >>>>>>>> handler... >>>>>>> Since there is a GC call prior to printing string i will give >>>>>>> that a >>>>>>> shot with non-debug build. >>>>>>>> >>>>>>>>> - The test's running on interpreter mode, what i am watching >>>>>>>>> for is >>>>>>>>> one error with trace. Without fastdebug build and >>>>>>>>> -XX:+TraceExceptions i am able to reproduce failure atleast 5 >>>>>>>>> failures out of 1000 runs but with fastdebug+Trace no luck >>>>>>>>> yet(already past few 1000 runs). >>>>>>>> >>>>>>>> It might be interesting to try with fastebug build but without the >>>>>>>> -XX:+TraceExceptions option to see what has an effect on it. It >>>>>>>> might >>>>>>>> also be interesting to try the modified ReferenceHandler (the one >>>>>>>> with private runImpl() method called from run()) and with normal >>>>>>>> non-fastdebug JDK. This info might be useful when one starts to >>>>>>>> inspect the exception handling code in interpreter... >>>>>>>> >>>>>>>> Regards, Peter >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Thanks >>>>>>> kalyan >>>>>>> Ph: (408)-585-8040 >>>>>>> >>>>>>>>> >>>>>>>>> --- >>>>>>>>> Thanks >>>>>>>>> kalyan >>>>>>>>> >>>>>>>>> On 01/10/2014 02:57 AM, Peter Levart wrote: >>>>>>>>>> On 01/10/2014 09:31 AM, Peter Levart wrote: >>>>>>>>>>> Since we suspect there's something wrong with exception >>>>>>>>>>> handling >>>>>>>>>>> in interpreter, I devised a hypothetical reproducer that >>>>>>>>>>> tries to >>>>>>>>>>> simulate ReferenceHandler in many aspects, but doesn't >>>>>>>>>>> require to >>>>>>>>>>> be a ReferenceHandler: >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~plevart/misc/OOME/OOMECatchingTest.java >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This is designed to run indefinitely and only terminate if/when >>>>>>>>>>> thread dies. Could you run this program in the environment that >>>>>>>>>>> causes the OOMEInReferenceHandler test to fail and see if it >>>>>>>>>>> terminates? >>>>>>>>>> >>>>>>>>>> I forgot to mention that in order for this long-running >>>>>>>>>> program to >>>>>>>>>> exhibit interpreter behaviour, it should be run with -Xint >>>>>>>>>> option. >>>>>>>>>> So I suggest: >>>>>>>>>> >>>>>>>>>> -Xmx24M -XX:-UseTLAB -Xint >>>>>>>>>> >>>>>>>>>> Regards, Peter >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >> From peter.levart at gmail.com Fri Jan 17 13:13:23 2014 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 17 Jan 2014 14:13:23 +0100 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52D9295D.6080106@gmail.com> References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> <52CC72AB.2020104@oracle.com> <52CCEDE0.8000809@oracle.com> <52CCF079.4090301@oracle.com> <52CD45E7.7010203@gmail.com> <52CE4E2D.300@oracle.com> <52CF37C6.1070605@oracle.com> <52CFAFEB.9090703@gmail.com> <52CFD218.2060101@gmail.com> <52D06B70.60001@oracle.com> <52D15201.90109@gmail.com> <52D47D59.8040905@oracle.com> <52D72577.1050506@oracle.com> <52D76859.2030502@oracle.com> <52D82968.4030608@oracle.com> <52D8929B.2020905@oracle.com> <52D8A42A.4020906@oracle.com> <52D8B3B6.3030202@oracle.com> <52D9295D.6080106@gmail.com> Message-ID: <52D92C73.2020309@gmail.com> On 01/17/2014 02:00 PM, Peter Levart wrote: > On 01/17/2014 05:38 AM, David Holmes wrote: >> On 17/01/2014 1:31 PM, srikalyan chandrashekar wrote: >>> Hi David, the disassembled code is also attached to the bug. Per my >> >> Sorry missed that. >> >>> analysis the exception was thrown when Reference Handler was on line >>> 143 >>> as put in the earlier email. >> >> But if the numbers in the dissassembly match the BCI then 65 shows: >> >> 65: instanceof #11 // class sun/misc/Cleaner >> >> which makes more sense, the runtime instanceof check might encounter >> an OOME condition. I wish there was some easy way to trace into the >> full call chain as TraceExceptions doesn't show you any runtime >> frames :( >> >> Still, it is easy enough to check: >> >> // Fast path for cleaners >> boolean isCleaner = false; >> try { >> isCleaner = r instanceof Cleaner; >> } catch (OutofMemoryError oome) { >> continue; >> } >> >> if (isCleaner) { >> ((Cleaner)r).clean(); >> continue; >> } >> > > Hi David, Kalyan, > > I've caught-up now. Just thinking: is "instanceof Cleaner" throwing > OOME as a result of loading the Cleaner class? Wouldn't the above code > then throw some error also in ((Cleaner)r) - the checkcast, since > Cleaner class would not be successfully initialized? Well, no. The above code would just skip Cleaner processing in this situation. And will never be doing it again after the heap is freed... So it might be good to load and initialize Cleaner class as part of ReferenceHandler initialization to ensure correct operation... Peter > Perhaps we should pre-load and initialize the Cleaner class as part of > ReferenceHandler initialization... > > Regards, Peter > >> Thanks, >> David >> >>> -- >>> Thanks >>> kalyan >>> >>> On 1/16/14 6:16 PM, David Holmes wrote: >>>> On 17/01/2014 4:48 AM, srikalyan wrote: >>>>> Hi David >>>>> >>>>> On 1/15/14, 9:04 PM, David Holmes wrote: >>>>>> On 16/01/2014 10:19 AM, srikalyan chandrashekar wrote: >>>>>>> Hi Peter/David, we could finally get a trace of exception with >>>>>>> fastdebug >>>>>>> build and ReferenceHandler modified (with runImpl() added and >>>>>>> called >>>>>>> from run()). The logs, disassembled code is available in JIRA >>>>>>> as attachments. >>>>>> >>>>>> All I can see is the log for the OOMECatchingTest program not one >>>>>> for >>>>>> the actual ReferenceHandler ?? >>>>>> >>>>> Please search for ReferenceHandler in the log. >>>>>>> Observations from the log: >>>>>>> >>>>>>> Root Cause: >>>>>>> 1) UncaughtException is being dispatched from Reference.java:143 >>>>>>> 141 Reference r; >>>>>>> 142 synchronized (lock) { >>>>>>> 143 if (pending != null) { >>>>>>> 144 r = pending; >>>>>>> 145 pending = r.discovered; >>>>>>> 146 r.discovered = null; >>>>>>> >>>>>>> pending field in Reference is touched and updated by the >>>>>>> collector, so >>>>>>> at line 143 when the execution context is in Reference handler >>>>>>> there >>>>>>> might have been an Exception pending due to allocation done by >>>>>>> collector >>>>>>> which causes ReferenceHandler thread to die. >>>>>> >>>>>> Sorry but the GC does not trigger asynchronous exceptions so this >>>>>> explanation does not make any sense to me. What part of the log led >>>>>> you to this conclusion? >>>>> ------------------ Log Excerpt begins ------------------ >>>>> Exception (0x00000000ff7808e8) >>>>> thrown >>>>> [/home/srikalyc/work/ora2013/infracleanup/jdk8/hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp, >>>>> >>>>> >>>>> line 168] >>>>> for thread 0x00007feed80cf800 >>>>> Exception (0x00000000ff7808e8) >>>>> thrown in interpreter method <{method} {0x00007feeddd3c600} >>>>> 'runImpl' >>>>> '()V' in 'java/lang/ref/Reference$ReferenceHandler'> >>>>> at bci 65 for thread 0x00007feed80cf800 >>>>> Exception (0x00000000ff7808e8) >>>>> thrown in interpreter method <{method} {0x00007feeddd3c478} 'run' >>>>> '()V' in 'java/lang/ref/Reference$ReferenceHandler'> >>>>> at bci 1 for thread 0x00007feed80cf800 >>>>> Exception (0x00000000ff780868) >>>>> thrown >>>>> [/home/srikalyc/work/ora2013/infracleanup/jdk8/hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp, >>>>> >>>>> >>>>> line 157] >>>>> for thread 0x00007feed80cf800 >>>>> Exception (0x00000000ff780868) >>>>> thrown in interpreter method <{method} {0x00007feeddcaaf90} >>>>> 'uncaughtException' '(Ljava/lang/Thread;Ljava/lang/Throwable;)V' >>>>> in '> >>>>> at bci 48 for thread 0x00007feed80cf800 >>>>> Exception (0x00000000ff780868) >>>>> thrown in interpreter method <{method} {0x00007feeddca7298} >>>>> 'dispatchUncaughtException' '(Ljava/lang/Throwable;)V' in >>>>> 'java/lang/> >>>>> at bci 6 for thread 0x00007feed80cf800 >>>>> ------------------ Log Excerpt ends ------------------ >>>>> Sorry if it is a wrong understanding. >>>> >>>> What you are seeing there is an OOME escaping the run() method which >>>> will cause the uncaughtExceptionHandler to be run which then triggers >>>> a second OOME (likely as it tries to report information about the >>>> first OOME). The first exception occurred in runImpl at BCI 65. Can >>>> you disassemble (javap -c) the class you used so we can see what is at >>>> BCI 65. >>>> >>>> Thanks, >>>> David >>>> >>>>>> >>>>>>> Suggested fix: >>>>>>> - As proposed earlier putting an outer guard(try-catch on OOME) >>>>>>> in the >>>>>>> ReferenceHandler will fix the issue, if ReferenceHandler is >>>>>>> considered >>>>>>> as part of the GC sub system then it should be alive even in the >>>>>>> midst >>>>>>> of an OOME so i feel that the additional guard should be allowed, >>>>>>> however i might still be ignorant of vital implications. >>>>>>> - Apart from the above changes, Peter's suggestion to create and >>>>>>> call a >>>>>>> private runImpl() from run() in ReferenceHandler makes sense to me. >>>>>> >>>>>> Why would we need this? >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> >>>>>>> --- >>>>>>> Thanks >>>>>>> kalyan >>>>>>> >>>>>>> On 01/13/2014 03:57 PM, srikalyan wrote: >>>>>>>> >>>>>>>> On 1/11/14, 6:15 AM, Peter Levart wrote: >>>>>>>>> >>>>>>>>> On 01/10/2014 10:51 PM, srikalyan chandrashekar wrote: >>>>>>>>>> Hi Peter the version you provided ran indefinitely(i put a 10 >>>>>>>>>> minute >>>>>>>>>> timeout) and the program got interrupted(no error), >>>>>>>>> >>>>>>>>> Did you run it with or without fastedbug & >>>>>>>>> -XX:+TraceExceptions ? If >>>>>>>>> with, it might be that fastdebug and/or -XX:+TraceExceptions >>>>>>>>> changes >>>>>>>>> the execution a bit so that we can no longer reproduce the wrong >>>>>>>>> behaviour. >>>>>>>> With fastdebug & -XX:TraceExceptions. I will try combination of >>>>>>>> possible options(i.e without -XX:TraceEception on debug build etc) >>>>>>>> soon. >>>>>>>>> >>>>>>>>>> even if there were to be an error you cannot print the >>>>>>>>>> "string" of >>>>>>>>>> thread to console(these have been attempted earlier). >>>>>>>>> >>>>>>>>> ...it has been attempted to print toString in uncaught exception >>>>>>>>> handler. At that time, the heap is still full. I'm printing it >>>>>>>>> after >>>>>>>>> the GC has cleared the heap. You can try that it works by >>>>>>>>> commenting >>>>>>>>> out the "try {" and corresponding "} catch (OOME x) {}" exception >>>>>>>>> handler... >>>>>>>> Since there is a GC call prior to printing string i will give >>>>>>>> that a >>>>>>>> shot with non-debug build. >>>>>>>>> >>>>>>>>>> - The test's running on interpreter mode, what i am watching >>>>>>>>>> for is >>>>>>>>>> one error with trace. Without fastdebug build and >>>>>>>>>> -XX:+TraceExceptions i am able to reproduce failure atleast 5 >>>>>>>>>> failures out of 1000 runs but with fastdebug+Trace no luck >>>>>>>>>> yet(already past few 1000 runs). >>>>>>>>> >>>>>>>>> It might be interesting to try with fastebug build but without >>>>>>>>> the >>>>>>>>> -XX:+TraceExceptions option to see what has an effect on it. It >>>>>>>>> might >>>>>>>>> also be interesting to try the modified ReferenceHandler (the one >>>>>>>>> with private runImpl() method called from run()) and with normal >>>>>>>>> non-fastdebug JDK. This info might be useful when one starts to >>>>>>>>> inspect the exception handling code in interpreter... >>>>>>>>> >>>>>>>>> Regards, Peter >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Thanks >>>>>>>> kalyan >>>>>>>> Ph: (408)-585-8040 >>>>>>>> >>>>>>>>>> >>>>>>>>>> --- >>>>>>>>>> Thanks >>>>>>>>>> kalyan >>>>>>>>>> >>>>>>>>>> On 01/10/2014 02:57 AM, Peter Levart wrote: >>>>>>>>>>> On 01/10/2014 09:31 AM, Peter Levart wrote: >>>>>>>>>>>> Since we suspect there's something wrong with exception >>>>>>>>>>>> handling >>>>>>>>>>>> in interpreter, I devised a hypothetical reproducer that >>>>>>>>>>>> tries to >>>>>>>>>>>> simulate ReferenceHandler in many aspects, but doesn't >>>>>>>>>>>> require to >>>>>>>>>>>> be a ReferenceHandler: >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~plevart/misc/OOME/OOMECatchingTest.java >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> This is designed to run indefinitely and only terminate >>>>>>>>>>>> if/when >>>>>>>>>>>> thread dies. Could you run this program in the environment >>>>>>>>>>>> that >>>>>>>>>>>> causes the OOMEInReferenceHandler test to fail and see if it >>>>>>>>>>>> terminates? >>>>>>>>>>> >>>>>>>>>>> I forgot to mention that in order for this long-running >>>>>>>>>>> program to >>>>>>>>>>> exhibit interpreter behaviour, it should be run with -Xint >>>>>>>>>>> option. >>>>>>>>>>> So I suggest: >>>>>>>>>>> >>>>>>>>>>> -Xmx24M -XX:-UseTLAB -Xint >>>>>>>>>>> >>>>>>>>>>> Regards, Peter >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>> > From fweimer at redhat.com Fri Jan 17 13:23:08 2014 From: fweimer at redhat.com (Florian Weimer) Date: Fri, 17 Jan 2014 14:23:08 +0100 Subject: RFR(M): 8031997: PPC64: Make the various POLL constants system dependant In-Reply-To: References: Message-ID: <52D92EBC.1040500@redhat.com> On 01/17/2014 12:25 PM, Volker Simonis wrote: > To avoid a mapping of the Java constants to the native ones every time > we go from Java to Native and back, this change replaces the currently > used constants with a single instance of constants which is placed in > src/share/classes/sun/nio/ch/Net.java and which are dynamically > initialized from native methods with the correct, platfrom-specific > values. Previously, the constants where inlined at the class file level. Is there a downside to not doing this? -- Florian Weimer / Red Hat Product Security Team From peter.levart at gmail.com Fri Jan 17 13:24:42 2014 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 17 Jan 2014 14:24:42 +0100 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52D92C73.2020309@gmail.com> References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> <52CC72AB.2020104@oracle.com> <52CCEDE0.8000809@oracle.com> <52CCF079.4090301@oracle.com> <52CD45E7.7010203@gmail.com> <52CE4E2D.300@oracle.com> <52CF37C6.1070605@oracle.com> <52CFAFEB.9090703@gmail.com> <52CFD218.2060101@gmail.com> <52D06B70.60001@oracle.com> <52D15201.90109@gmail.com> <52D47D59.8040905@oracle.com> <52D72577.1050506@oracle.com> <52D76859.2030502@oracle.com> <52D82968.4030608@oracle.com> <52D8929B.2020905@oracle.com> <52D8A42A.4020906@oracle.com> <52D8B3B6.3030202@oracle.com> <52D9295D.6080106@gmail.com> <52D92C73.2020309@gmail.com> Message-ID: <52D92F1A.4040400@gmail.com> On 01/17/2014 02:13 PM, Peter Levart wrote: >>> // Fast path for cleaners >>> boolean isCleaner = false; >>> try { >>> isCleaner = r instanceof Cleaner; >>> } catch (OutofMemoryError oome) { >>> continue; >>> } >>> >>> if (isCleaner) { >>> ((Cleaner)r).clean(); >>> continue; >>> } >>> >> >> Hi David, Kalyan, >> >> I've caught-up now. Just thinking: is "instanceof Cleaner" throwing >> OOME as a result of loading the Cleaner class? Wouldn't the above >> code then throw some error also in ((Cleaner)r) - the checkcast, >> since Cleaner class would not be successfully initialized? > > Well, no. The above code would just skip Cleaner processing in this > situation. And will never be doing it again after the heap is freed... > So it might be good to load and initialize Cleaner class as part of > ReferenceHandler initialization to ensure correct operation... Well, yes and no. Let me try once more: Above code will skip Cleaner processing if the 1st time "instanceof Cleaner" is executed, OOME is thrown as a consequence of full heap while loading and initializing the Cleaner class. The 2nd time the "instanceof Cleaner" is executed after such OOME, the same line would throw NoClassDefFoundError as a consequence of referencing a class that failed initialization. Am I right? Regards, Peter From volker.simonis at gmail.com Fri Jan 17 13:45:26 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 17 Jan 2014 14:45:26 +0100 Subject: RFR(M): 8031997: PPC64: Make the various POLL constants system dependant In-Reply-To: <52D917B0.9090407@oracle.com> References: <52D917B0.9090407@oracle.com> Message-ID: On Fri, Jan 17, 2014 at 12:44 PM, Alan Bateman wrote: > On 17/01/2014 11:25, Volker Simonis wrote: >> >> : >> >> I've compiled and smoke-tested the changes on Linux/x86_64/PPC64, >> Windows/x86_64, Solaris/SPARC, MacOS X and AIX. On all these platforms >> they pass all the java/nio JTREG tests in the same way like without >> this change. This means that on Linux/MacOS they pass all 261/256 >> tests, on Windows, they pass 258 tests while the following two tests >> fail: >> >> java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java >> java/nio/channels/DatagramChannel/Promiscuous.java >> >> But as I wrote before, these two test also fail without my changes >> applied, so I'm confident that the failures aren't related to this >> change. > > Any chance that this is firewall configuration or VPN that might be cause > packets to be dropped? These tests should otherwise pass consistently on all > platforms. If you have output from Linux or Solaris or OS X that you could > send then it might help to diagnose this. > Yes, you're right - it was because of a "VirtualBox Host-Only Network" network device which seems to fool the test. After I disabled it, all tests passed successfully! And what about the change itself :) > -Alan From volker.simonis at gmail.com Fri Jan 17 14:04:42 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 17 Jan 2014 15:04:42 +0100 Subject: RFR(M): 8031997: PPC64: Make the various POLL constants system dependant In-Reply-To: <52D92EBC.1040500@redhat.com> References: <52D92EBC.1040500@redhat.com> Message-ID: On Fri, Jan 17, 2014 at 2:23 PM, Florian Weimer wrote: > On 01/17/2014 12:25 PM, Volker Simonis wrote: >> >> To avoid a mapping of the Java constants to the native ones every time >> we go from Java to Native and back, this change replaces the currently >> used constants with a single instance of constants which is placed in >> src/share/classes/sun/nio/ch/Net.java and which are dynamically >> initialized from native methods with the correct, platfrom-specific >> values. > > > Previously, the constants where inlined at the class file level. Is there a > downside to not doing this? > Hi Florian, I already thought about this. From a performance perspective, I don't think it will have any impact considering that these constants will be used for doing native system calls anyway. It could be of course a problem on AIX (and only there) if third-party code had previously inlined these constants. But as these are internal classes (i.e. sun.nio.ch) which should be only used by the JDK itself, I hope there's not too such much code outside there. Regards, Volker > -- > Florian Weimer / Red Hat Product Security Team From fweimer at redhat.com Fri Jan 17 14:14:12 2014 From: fweimer at redhat.com (Florian Weimer) Date: Fri, 17 Jan 2014 15:14:12 +0100 Subject: RFR(M): 8031997: PPC64: Make the various POLL constants system dependant In-Reply-To: References: <52D92EBC.1040500@redhat.com> Message-ID: <52D93AB4.50402@redhat.com> On 01/17/2014 03:04 PM, Volker Simonis wrote: > On Fri, Jan 17, 2014 at 2:23 PM, Florian Weimer wrote: >> On 01/17/2014 12:25 PM, Volker Simonis wrote: >>> >>> To avoid a mapping of the Java constants to the native ones every time >>> we go from Java to Native and back, this change replaces the currently >>> used constants with a single instance of constants which is placed in >>> src/share/classes/sun/nio/ch/Net.java and which are dynamically >>> initialized from native methods with the correct, platfrom-specific >>> values. >> >> >> Previously, the constants where inlined at the class file level. Is there a >> downside to not doing this? > I already thought about this. From a performance perspective, I don't > think it will have any impact considering that these constants will be > used for doing native system calls anyway. True, and the few extra bytes of class data hopefully don't matter (although they keep adding up). > It could be of course a problem on AIX (and only there) if third-party > code had previously inlined these constants. But as these are internal > classes (i.e. sun.nio.ch) which should be only used by the JDK itself, > I hope there's not too such much code outside there. Some of the classes weren't even public until 8, so this risk is even reduced further. -- Florian Weimer / Red Hat Product Security Team From daniel.fuchs at oracle.com Fri Jan 17 14:51:24 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 17 Jan 2014 15:51:24 +0100 Subject: JDK 9 RFR for 8031980: Add new j.u.l deadlock test for JDK-8027670 and JDK-8029281 Message-ID: <52D9436C.7090306@oracle.com> Hi, Please find below a webrev for: 8031980: Add new j.u.l deadlock test for JDK-8027670 and JDK-8029281 https://bugs.openjdk.java.net/browse/JDK-8031980 Thread dumps that were sent to me after recent sighting of JDK-8027670 have allowed me to find a much better test for verifying the JDK-8029281 fix. The new test (TestLogConfigurationDeadLockWithConf) is similar to the old one (TestLogConfigurationDeadLock) except that it creates loggers from a configuration which is much more prone to excite the deadlock. The new test almost always fail on a platform/build that doesn't have the fix for JDK-8029281. best regards, -- daniel From Alan.Bateman at oracle.com Fri Jan 17 15:16:54 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 17 Jan 2014 15:16:54 +0000 Subject: RFR(M): 8031997: PPC64: Make the various POLL constants system dependant In-Reply-To: References: <52D917B0.9090407@oracle.com> Message-ID: <52D94966.8090407@oracle.com> On 17/01/2014 13:45, Volker Simonis wrote: > : > Yes, you're right - it was because of a "VirtualBox Host-Only Network" > network device which seems to fool the test. After I disabled it, all > tests passed successfully! > > And what about the change itself :) > The change itself looks mostly okay. For naming then I think I would have a slight preference for something like pollinValue to getNatvePollin so that it somewhat consistent with the other places where we do this (like in epoll code with eventSize, eventsOffset, ...). Naming is subjective of course so this isn't a big issue. I suspect you can drop POLLREMOVE, that is only used in the /dev/poll Selector and it has its own definition (and shouldn't be compiled on anything other than Solaris anyway). A minor comment on DatagramChannelImpl, SourceChannelImpl and a few more where the replacing PollArrayWrapper.POLL* with Net.POLL* means it is no longer necessary to split lines (just might be neater to bring these cases back on the one line again). I suspect we will be able to drop the changes to the Windows nio_util.h soon as these older versions of Windows are not long for this world. I assume that by taking on newer VC++ that it won't even be possible to build or run either. -Alan. From Alan.Bateman at oracle.com Fri Jan 17 15:50:27 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 17 Jan 2014 15:50:27 +0000 Subject: RFR(S/L): 8028537: PPC64: Updated the JDK regression tests to run on AIX In-Reply-To: References: Message-ID: <52D95143.6080601@oracle.com> On 14/01/2014 16:57, Volker Simonis wrote: > Hi, > > could you please review the following change: > > http://cr.openjdk.java.net/~simonis/webrevs/8028537/ > > which, together with the changes from "8031581: PPC64: Addons and fixes for > AIX to pass the jdk regression tests" and "8031134 : PPC64: implement > printing on AIX" enables our our port to pass all but the following 7 jtreg > regression tests on AIX (compared to the Linux/x86_64 baseline from > www.java.net/download/jdk8/testresults/testresults.html?): > I've finally got to this one. As the event translation issue is now a separate issue then I've ignored that part. I'm not comfortable with the changes to FileDispatcherImpl.c as I don't think we shouldn't be calling into IO_ or NET_* functions here. I think I get the issue that you have on AIX (and assume it's the preClose/dup2 that blocks rather than close) but need a bit of time to suggest alternatives. It may be that it will require an AIX specific SocketDispatcher. Do you happen to know which tests fail due to this part? The other changes look okay. There is a typo in the change to zip_util.c, s/legel/legal/. In DatagramChannelImpl.c then you handle connect failing with EAFNOSUPPORT. I would be tempted to replace the comment to say that it EAFNOSUPPORT can be ignored on AIX. A minor comment but the indentation for rv = errno can be fixed (I see the BSD code has it wrong too). -Alan. From brian.goetz at oracle.com Fri Jan 17 16:09:12 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 17 Jan 2014 11:09:12 -0500 Subject: RFR: JDK-8031373 and 8030079 -- lint warnings in java.util.stream and java.lang.invoke Message-ID: <52D955A8.3090001@oracle.com> Webrev at: http://cr.openjdk.java.net/~briangoetz/JDK-8031373/webrev/ If someone with ASM fu (Remi?) could sanity check the JLI changes, that would be appreciated. From paul.sandoz at oracle.com Fri Jan 17 16:42:07 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 17 Jan 2014 17:42:07 +0100 Subject: RFR: JDK-8031373 and 8030079 -- lint warnings in java.util.stream and java.lang.invoke In-Reply-To: <52D955A8.3090001@oracle.com> References: <52D955A8.3090001@oracle.com> Message-ID: <1EE2EB27-A684-4AA2-BD12-4FF633857187@oracle.com> On Jan 17, 2014, at 5:09 PM, Brian Goetz wrote: > Webrev at: > http://cr.openjdk.java.net/~briangoetz/JDK-8031373/webrev/ > > If someone with ASM fu (Remi?) could sanity check the JLI changes, that would be appreciated. > Stream code looks good. I notice some other things in StreamSpliterators that could potentially be cleaned up too: - Might be a redundant cast: 312 ph.wrapAndCopyInto((Sink) consumer::accept, spliterator); - Error in JavaDoc: 1324 * The {@coe tryAdvance} method always returns true. -- IIUC the ASM related updates are due to the deprecated method. The new method allows for invokespecial/static on methods of interfaces and placing the correct data in the constant pool. In which case i would expect all the updates to have a false as the last parameter, which is so. Still, as say Remi's eyes would be useful on this one. Paul. From forax at univ-mlv.fr Fri Jan 17 16:56:53 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 17 Jan 2014 17:56:53 +0100 Subject: RFR: JDK-8031373 and 8030079 -- lint warnings in java.util.stream and java.lang.invoke In-Reply-To: <1EE2EB27-A684-4AA2-BD12-4FF633857187@oracle.com> References: <52D955A8.3090001@oracle.com> <1EE2EB27-A684-4AA2-BD12-4FF633857187@oracle.com> Message-ID: <52D960D5.1090300@univ-mlv.fr> On 01/17/2014 05:42 PM, Paul Sandoz wrote: > On Jan 17, 2014, at 5:09 PM, Brian Goetz wrote: > >> Webrev at: >> http://cr.openjdk.java.net/~briangoetz/JDK-8031373/webrev/ >> >> If someone with ASM fu (Remi?) could sanity check the JLI changes, that would be appreciated. >> > > Stream code looks good. > > I notice some other things in StreamSpliterators that could potentially be cleaned up too: > > - Might be a redundant cast: > > 312 ph.wrapAndCopyInto((Sink) consumer::accept, spliterator); > > - Error in JavaDoc: > > 1324 * The {@coe tryAdvance} method always returns true. > > -- > > IIUC the ASM related updates are due to the deprecated method. The new method allows for invokespecial/static on methods of interfaces and placing the correct data in the constant pool. In which case i would expect all the updates to have a false as the last parameter, which is so. Still, as say Remi's eyes would be useful on this one. > > Paul. The ASM part is fine. As Paul said, the last parameter should be true if the owner of the method call is an interface, so in case of an INVOKEVIRTUAL, it's always false, in case of an INVOKEINTERFACE, it's always true, for INVOKESPECIAL, if it's a call to a constructor (""), it's always false. Given that the code either create classes or call wrapper classes (for boxing/unboxing). All calls should use false. in TypeConvertingMethodAdapter, I think it's better if false was written on its own line like the other parameters. visitMethodInsn(Opcodes.INVOKESTATIC, wrapperName(w), NAME_BOX_METHOD, - boxingDescriptor(w)); + boxingDescriptor(w), + false); cheers, R?mi From volker.simonis at gmail.com Fri Jan 17 17:42:26 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 17 Jan 2014 18:42:26 +0100 Subject: RFR(M): 8031997: PPC64: Make the various POLL constants system dependant In-Reply-To: <52D94966.8090407@oracle.com> References: <52D917B0.9090407@oracle.com> <52D94966.8090407@oracle.com> Message-ID: On Fri, Jan 17, 2014 at 4:16 PM, Alan Bateman wrote: > On 17/01/2014 13:45, Volker Simonis wrote: >> >> : >> Yes, you're right - it was because of a "VirtualBox Host-Only Network" >> network device which seems to fool the test. After I disabled it, all >> tests passed successfully! >> >> And what about the change itself :) >> > The change itself looks mostly okay. > > For naming then I think I would have a slight preference for something like > pollinValue to getNatvePollin so that it somewhat consistent with the other > places where we do this (like in epoll code with eventSize, eventsOffset, > ...). Naming is subjective of course so this isn't a big issue. > Done. > I suspect you can drop POLLREMOVE, that is only used in the /dev/poll > Selector and it has its own definition (and shouldn't be compiled on > anything other than Solaris anyway). > Removed POLLREMOVE from sun.nio.ch.Net. > A minor comment on DatagramChannelImpl, SourceChannelImpl and a few more > where the replacing PollArrayWrapper.POLL* with Net.POLL* means it is no > longer necessary to split lines (just might be neater to bring these cases > back on the one line again). > Done. > I suspect we will be able to drop the changes to the Windows nio_util.h soon > as these older versions of Windows are not long for this world. I assume > that by taking on newer VC++ that it won't even be possible to build or run > either. > We still support Server 2003 :( > -Alan. Here's the new webrev: http://cr.openjdk.java.net/~simonis/webrevs/8031997_2/ Built and tested like before. Everything OK. Is this now ready for push into ppc-aix-port/stage-9? Regards, Volker PS: I've added you as reviewer, but unfortunately after I created the webrev. From mandy.chung at oracle.com Fri Jan 17 21:10:01 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 17 Jan 2014 13:10:01 -0800 Subject: Review request for JDK-6760902: inconsistent behavior in bootstrap class loader for classes and resources In-Reply-To: <52D73587.30104@oracle.com> References: <52D73587.30104@oracle.com> Message-ID: <52D99C29.3020206@oracle.com> Paul, Here is the updated webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/6760902/webrev.01/ This cleans up GetResource.sh and merges with GetResource2.sh. Also fixed "if (pos - lastPoc > 0)" line and javadoc typo. thanks Mandy On 1/15/2014 5:27 PM, Mandy Chung wrote: > There is an inconsistency in searching classes vs resources if > bootclasspath contains an empty path. Empty path on bootclasspath is > skipped by the bootstrap class loader when searching classes while it > defaults to current working directory when searching resources as the > application class loader. This fixes sun.misc.Launcher to skip empty > path when constructing the paths from bootclasspath for resource lookup. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/6760902/webrev.00/ > > There is some incompatibility risk that may impact existing code > depending on this behavior to search resources from the current > working directory if empty path (rather than explicit) is set. I > think most application using bootclasspath is to add their paths to > load their classes and likely expect the resources are looked in the > consistent way (i.e. skips the empty path). So I expect the > incompatibility risk is low. > > thanks > Mandy From volker.simonis at gmail.com Fri Jan 17 21:10:22 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 17 Jan 2014 22:10:22 +0100 Subject: RFR(S/L): 8028537: PPC64: Updated the JDK regression tests to run on AIX In-Reply-To: <52D8FC7E.5080908@oracle.com> References: <52D58C55.6070004@oracle.com> <52D8FC7E.5080908@oracle.com> Message-ID: Hi Alan, thanks for looking at this. Please find may comments inline: On Fri, Jan 17, 2014 at 10:48 AM, Alan Bateman wrote: > On 15/01/2014 16:42, Volker Simonis wrote: >> >> Hi Alan, >> >> thanks for the suggestion. That's fine for me. I've copied the empty SCTP >> stubs from the macosx to the aix directory as well and updated the make file >> accordingly (in the patch for "8031581: PPC64: Addons and fixes for AIX to >> pass the jdk regression tests"). >> >> Therefore, the changes to the three tests: >> >> test/com/sun/nio/sctp/SctpChannel/Util.java >> test/com/sun/nio/sctp/SctpMultiChannel/Util.java >> test/com/sun/nio/sctp/SctpServerChannel/Util.java >> >> can be considered obsolete. > > Thanks, I think this makes the most sense. > > I looked through the rest of this webrev and the update to the tests looks > fine. > Great, thanks. > One general comment is that for many of these shell tests (that survive the > current effort to replace them) is that we could move the Unix handling into > the match any case so that we don't have to list each of Linux, SunOS, > Darwin, ... I think this came up when the OS X port was brought in but > there wasn't any follow-up on it. I am not suggesting you do this here, it's > just a comment as I see same change to so many tests. > > A minor comment on SBC.java is that it could just catch > UnsupportedOperationException on L238, that would avoid needing to check > os.name. > I agree, that looks much nicer. Done as requested. > A really minor comment on the updates to ProblemList.txt is that the JMX > test should probably be in the jdk_jmx section (it's just a convention that > we've been using, it doesn't of course really matter where tests are > listed). Done. Moved the excluded tests down to the jdk_jmx section. Here's the new webrev: http://cr.openjdk.java.net/~simonis/webrevs/8028537_2/ Can I push this now to ppc-aix-port/stage-9? Thank you and best regards, Volker > > -Alan From volker.simonis at gmail.com Fri Jan 17 21:15:08 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 17 Jan 2014 22:15:08 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: <52D50118.3080000@oracle.com> References: <52D50118.3080000@oracle.com> Message-ID: On Tue, Jan 14, 2014 at 10:19 AM, Alan Bateman wrote: > On 14/01/2014 08:40, Volker Simonis wrote: >> >> Hi, >> >> could you please review the following changes for the ppc-aix-port >> stage/stage-9 repositories (the changes are planned for integration into >> ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): > > I'd like to review this but I won't have time until later in the week. From > an initial look then there are a few things are not pretty (the changes to > fix the AIX problems with I/O cancellation in particular) and I suspect that > some refactoring is going to be required to handle some of this cleanly. A > minor comment is that bug synopsis doesn't really communicate what these > changes are about. > > -Alan. Just forwarded the following message from another thread here where it belongs: On 17/01/2014 16:57, Alan Bateman wrote: I've finally got to this one. As the event translation issue is now a separate issue then I've ignored that part. I'm not comfortable with the changes to FileDispatcherImpl.c as I don't think we shouldn't be calling into IO_ or NET_* functions here. I think I get the issue that you have on AIX (and assume it's the preClose/dup2 that blocks rather than close) but need a bit of time to suggest alternatives. It may be that it will require an AIX specific SocketDispatcher. Do you happen to know which tests fail due to this part? The other changes look okay. There is a typo in the change to zip_util.c, s/legel/legal/. In DatagramChannelImpl.c then you handle connect failing with EAFNOSUPPORT. I would be tempted to replace the comment to say that it EAFNOSUPPORT can be ignored on AIX. A minor comment but the indentation for rv = errno can be fixed (I see the BSD code has it wrong too). From Alan.Bateman at oracle.com Fri Jan 17 21:21:26 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 17 Jan 2014 21:21:26 +0000 Subject: RFR(M): 8031997: PPC64: Make the various POLL constants system dependant In-Reply-To: References: <52D917B0.9090407@oracle.com> <52D94966.8090407@oracle.com> Message-ID: <52D99ED6.1070806@oracle.com> On 17/01/2014 17:42, Volker Simonis wrote: > : > Here's the new webrev: > > http://cr.openjdk.java.net/~simonis/webrevs/8031997_2/ > > Built and tested like before. Everything OK. > > Is this now ready for push into ppc-aix-port/stage-9? > Thanks the updates, this looks good to me. -Alan. From Alan.Bateman at oracle.com Fri Jan 17 21:24:56 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 17 Jan 2014 21:24:56 +0000 Subject: RFR(S/L): 8028537: PPC64: Updated the JDK regression tests to run on AIX In-Reply-To: References: <52D58C55.6070004@oracle.com> <52D8FC7E.5080908@oracle.com> Message-ID: <52D99FA8.1060108@oracle.com> On 17/01/2014 21:10, Volker Simonis wrote: > : > Done. Moved the excluded tests down to the jdk_jmx section. > > Here's the new webrev: > > http://cr.openjdk.java.net/~simonis/webrevs/8028537_2/ > > Can I push this now to ppc-aix-port/stage-9? > The SBC change looks good. I can't see the move of the excluded test but it's not important anyway. So I think this one is good to go. -Alan. From david.holmes at oracle.com Mon Jan 20 01:51:40 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 20 Jan 2014 11:51:40 +1000 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52D92F1A.4040400@gmail.com> References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> <52CC72AB.2020104@oracle.com> <52CCEDE0.8000809@oracle.com> <52CCF079.4090301@oracle.com> <52CD45E7.7010203@gmail.com> <52CE4E2D.300@oracle.com> <52CF37C6.1070605@oracle.com> <52CFAFEB.9090703@gmail.com> <52CFD218.2060101@gmail.com> <52D06B70.60001@oracle.com> <52D15201.90109@gmail.com> <52D47D59.8040905@oracle.com> <52D72577.1050506@oracle.com> <52D76859.2030502@oracle.com> <52D82968.4030608@oracle.com> <52D8929B.2020905@oracle.com> <52D8A42A.4020906@oracle.com> <52D8B3B6.3030202@oracle.com> <52D9295D.6080106@gmail.com> <52D92C73.2020309@gmail.com> <52D92F1A.4040400@gmail.com> Message-ID: <52DC812C.1000607@oracle.com> Hi Peter, On 17/01/2014 11:24 PM, Peter Levart wrote: > On 01/17/2014 02:13 PM, Peter Levart wrote: >>>> // Fast path for cleaners >>>> boolean isCleaner = false; >>>> try { >>>> isCleaner = r instanceof Cleaner; >>>> } catch (OutofMemoryError oome) { >>>> continue; >>>> } >>>> >>>> if (isCleaner) { >>>> ((Cleaner)r).clean(); >>>> continue; >>>> } >>>> >>> >>> Hi David, Kalyan, >>> >>> I've caught-up now. Just thinking: is "instanceof Cleaner" throwing >>> OOME as a result of loading the Cleaner class? Wouldn't the above >>> code then throw some error also in ((Cleaner)r) - the checkcast, >>> since Cleaner class would not be successfully initialized? >> >> Well, no. The above code would just skip Cleaner processing in this >> situation. And will never be doing it again after the heap is freed... >> So it might be good to load and initialize Cleaner class as part of >> ReferenceHandler initialization to ensure correct operation... > > Well, yes and no. Let me try once more: > > Above code will skip Cleaner processing if the 1st time "instanceof > Cleaner" is executed, OOME is thrown as a consequence of full heap while > loading and initializing the Cleaner class. Yes - I was assuming that this would not fail the very first time and so the Cleaner class would already be loaded. Failing to be able to load the Cleaner class was one of the potential issues flagged earlier with this problem. I was actually assuming that Cleaner would be loaded already due to some actual Cleaner subclasses being used, but this does not happen as part of the default initialization. :( The irony being that if the Cleaner class is not loaded then r can not be an instance of Cleaner and so we would fail to load the class in a case where we didn't need it anyway. What I wanted to focus on here was an OOME from the instanceof itself, but as you say that might trigger classloading of Cleaner (which is not what I was interested in). > The 2nd time the "instanceof > Cleaner" is executed after such OOME, the same line would throw > NoClassDefFoundError as a consequence of referencing a class that failed > initialization. Am I right? instanceof is not one of the class initialization triggers, so we should not see an OOME generated due to a class initialization exception and so the class will not be put into the Erroneous state and so subsequent attempts to use the class will not automatically trigger NoClassdefFoundError. If OOME occurs during actual loading/linking of the class Cleaner it is unclear what would happen on subsequent attempts. OOME is not a LinkageError that must be rethrown on subsequent attempts, and it is potentially a transient condition, so I would expect a re-load attempt to be allowed. However we are now deep into the details of the VM and it may well depend on the exact place from which the OOME originates. The bottom line with the current problem is that there are multiple non-obvious paths by which the ReferenceHandler can encounter an OOME. In such cases we do not want the ReferenceHandler to terminate - which implies catching the OOME and continuing. However we also do not want to silently skip Cleaner processing or reference queue processing - as that would lead to hard to diagnoze bugs. But trying to report the problem may not be possible due to being out-of-memory. It may be that we need to break things up into multiple try/catch blocks, where each catch does a System.gc() and then reports that the OOME occurred. Of course the reporting must still be in a try/catch for the OOME. Though at some point letting the ReferenceHandler die may be the only way to "report" a major memory problem. David David > Regards, Peter > From peter.levart at gmail.com Mon Jan 20 08:00:14 2014 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 20 Jan 2014 09:00:14 +0100 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52DC812C.1000607@oracle.com> References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> <52CC72AB.2020104@oracle.com> <52CCEDE0.8000809@oracle.com> <52CCF079.4090301@oracle.com> <52CD45E7.7010203@gmail.com> <52CE4E2D.300@oracle.com> <52CF37C6.1070605@oracle.com> <52CFAFEB.9090703@gmail.com> <52CFD218.2060101@gmail.com> <52D06B70.60001@oracle.com> <52D15201.90109@gmail.com> <52D47D59.8040905@oracle.com> <52D72577.1050506@oracle.com> <52D76859.2030502@oracle.com> <52D82968.4030608@oracle.com> <52D8929B.2020905@oracle.com> <52D8A42A.4020906@oracle.com> <52D8B3B6.3030202@oracle.com> <52D9295D.6080106@gmail.com> <52D92C73.2020309@gmail.com> <52D92F1A.4040400@gmail.com> <52DC812C.1000607@oracle.com> Message-ID: <52DCD78E.8050404@gmail.com> On 01/20/2014 02:51 AM, David Holmes wrote: > Hi Peter, > > On 17/01/2014 11:24 PM, Peter Levart wrote: >> On 01/17/2014 02:13 PM, Peter Levart wrote: >>>>> // Fast path for cleaners >>>>> boolean isCleaner = false; >>>>> try { >>>>> isCleaner = r instanceof Cleaner; >>>>> } catch (OutofMemoryError oome) { >>>>> continue; >>>>> } >>>>> >>>>> if (isCleaner) { >>>>> ((Cleaner)r).clean(); >>>>> continue; >>>>> } >>>>> >>>> >>>> Hi David, Kalyan, >>>> >>>> I've caught-up now. Just thinking: is "instanceof Cleaner" throwing >>>> OOME as a result of loading the Cleaner class? Wouldn't the above >>>> code then throw some error also in ((Cleaner)r) - the checkcast, >>>> since Cleaner class would not be successfully initialized? >>> >>> Well, no. The above code would just skip Cleaner processing in this >>> situation. And will never be doing it again after the heap is freed... >>> So it might be good to load and initialize Cleaner class as part of >>> ReferenceHandler initialization to ensure correct operation... >> >> Well, yes and no. Let me try once more: >> >> Above code will skip Cleaner processing if the 1st time "instanceof >> Cleaner" is executed, OOME is thrown as a consequence of full heap while >> loading and initializing the Cleaner class. > > Yes - I was assuming that this would not fail the very first time and > so the Cleaner class would already be loaded. Failing to be able to > load the Cleaner class was one of the potential issues flagged earlier > with this problem. I was actually assuming that Cleaner would be > loaded already due to some actual Cleaner subclasses being used, but > this does not happen as part of the default initialization. :( The > irony being that if the Cleaner class is not loaded then r can not be > an instance of Cleaner and so we would fail to load the class in a > case where we didn't need it anyway. > > What I wanted to focus on here was an OOME from the instanceof itself, > but as you say that might trigger classloading of Cleaner (which is > not what I was interested in). > >> The 2nd time the "instanceof >> Cleaner" is executed after such OOME, the same line would throw >> NoClassDefFoundError as a consequence of referencing a class that failed >> initialization. Am I right? > > instanceof is not one of the class initialization triggers, so we > should not see an OOME generated due to a class initialization > exception and so the class will not be put into the Erroneous state > and so subsequent attempts to use the class will not automatically > trigger NoClassdefFoundError. > > If OOME occurs during actual loading/linking of the class Cleaner it > is unclear what would happen on subsequent attempts. OOME is not a > LinkageError that must be rethrown on subsequent attempts, and it is > potentially a transient condition, so I would expect a re-load attempt > to be allowed. However we are now deep into the details of the VM and > it may well depend on the exact place from which the OOME originates. > > The bottom line with the current problem is that there are multiple > non-obvious paths by which the ReferenceHandler can encounter an OOME. > In such cases we do not want the ReferenceHandler to terminate - which > implies catching the OOME and continuing. However we also do not want > to silently skip Cleaner processing or reference queue processing - as > that would lead to hard to diagnoze bugs. But trying to report the > problem may not be possible due to being out-of-memory. It may be that > we need to break things up into multiple try/catch blocks, where each > catch does a System.gc() and then reports that the OOME occurred. Of > course the reporting must still be in a try/catch for the OOME. Though > at some point letting the ReferenceHandler die may be the only way to > "report" a major memory problem. > > David Hm... If I give -verbose:class option to run a simple test program: public class Test { public static void main(String... a) {} } I see Cleaner class being loaded before Test class. I don't see by which tread or if it might get loaded after main() starts, but I suspect that loading of Cleaner is not a problem here. Initialization of Cleaner class is not performed by ReferenceHandler thread as you pointed out. The instanceof does not trigger it and if it returns true then Cleaner has already been initialized. So there must be some other cause for instanceof throwing OOME... What do you say about this variant of ReferenceHandler.run() method: public void run() { for (;;) { Reference r; Cleaner c; synchronized (lock) { r = pending; if (r != null) { // instanceof operator might throw OOME sometimes. Just retry after // yielding - might have better luck next time... try { c = r instanceof Cleaner ? (Cleaner) r : null; } catch (OutOfMemoryError x) { Thread.yield(); continue; } pending = r.discovered; r.discovered = null; } else { // The waiting on the lock may cause an OOME because it may try to allocate // exception objects, so also catch OOME here to avoid silent exit of the // reference handler thread. // // Explicitly define the order of the two exceptions we catch here // when waiting for the lock. // // We do not want to try to potentially load the InterruptedException class // (which would be done if this was its first use, and InterruptedException // were checked first) in this situation. // // This may lead to the VM not ever trying to load the InterruptedException // class again. try { try { lock.wait(); } catch (OutOfMemoryError x) { } } catch (InterruptedException x) { } continue; } } // Fast path for cleaners if (c != null) { c.clean(); continue; } ReferenceQueue q = r.queue; if (q != ReferenceQueue.NULL) q.enqueue(r); } } ... it tries to not consume and skip Cleaner instances when OOME is caught. I don't think ReferenceHandler is to make responsible for reporting OOMEs. Full heap is a global condition and ReferenceHandler is the last to accuse for it. Regards, Peter > > David > >> Regards, Peter >> From peter.levart at gmail.com Mon Jan 20 08:42:35 2014 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 20 Jan 2014 09:42:35 +0100 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52DCD78E.8050404@gmail.com> References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> <52CC72AB.2020104@oracle.com> <52CCEDE0.8000809@oracle.com> <52CCF079.4090301@oracle.com> <52CD45E7.7010203@gmail.com> <52CE4E2D.300@oracle.com> <52CF37C6.1070605@oracle.com> <52CFAFEB.9090703@gmail.com> <52CFD218.2060101@gmail.com> <52D06B70.60001@oracle.com> <52D15201.90109@gmail.com> <52D47D59.8040905@oracle.com> <52D72577.1050506@oracle.com> <52D76859.2030502@oracle.com> <52D82968.4030608@oracle.com> <52D8929B.2020905@oracle.com> <52D8A42A.4020906@oracle.com> <52D8B3B6.3030202@oracle.com> <52D9295D.6080106@gmail.com> <52D92C73.2020309@gmail.com> <52D92F1A.4040400@gmail.com> <52DC812C.1000607@oracle.com> <52DCD78E.8050404@gmail.com> Message-ID: <52DCE17B.4050708@gmail.com> On 01/20/2014 09:00 AM, Peter Levart wrote: > On 01/20/2014 02:51 AM, David Holmes wrote: >> Hi Peter, >> >> On 17/01/2014 11:24 PM, Peter Levart wrote: >>> On 01/17/2014 02:13 PM, Peter Levart wrote: >>>>>> // Fast path for cleaners >>>>>> boolean isCleaner = false; >>>>>> try { >>>>>> isCleaner = r instanceof Cleaner; >>>>>> } catch (OutofMemoryError oome) { >>>>>> continue; >>>>>> } >>>>>> >>>>>> if (isCleaner) { >>>>>> ((Cleaner)r).clean(); >>>>>> continue; >>>>>> } >>>>>> >>>>> >>>>> Hi David, Kalyan, >>>>> >>>>> I've caught-up now. Just thinking: is "instanceof Cleaner" throwing >>>>> OOME as a result of loading the Cleaner class? Wouldn't the above >>>>> code then throw some error also in ((Cleaner)r) - the checkcast, >>>>> since Cleaner class would not be successfully initialized? >>>> >>>> Well, no. The above code would just skip Cleaner processing in this >>>> situation. And will never be doing it again after the heap is freed... >>>> So it might be good to load and initialize Cleaner class as part of >>>> ReferenceHandler initialization to ensure correct operation... >>> >>> Well, yes and no. Let me try once more: >>> >>> Above code will skip Cleaner processing if the 1st time "instanceof >>> Cleaner" is executed, OOME is thrown as a consequence of full heap >>> while >>> loading and initializing the Cleaner class. >> >> Yes - I was assuming that this would not fail the very first time and >> so the Cleaner class would already be loaded. Failing to be able to >> load the Cleaner class was one of the potential issues flagged >> earlier with this problem. I was actually assuming that Cleaner would >> be loaded already due to some actual Cleaner subclasses being used, >> but this does not happen as part of the default initialization. :( >> The irony being that if the Cleaner class is not loaded then r can >> not be an instance of Cleaner and so we would fail to load the class >> in a case where we didn't need it anyway. >> >> What I wanted to focus on here was an OOME from the instanceof >> itself, but as you say that might trigger classloading of Cleaner >> (which is not what I was interested in). >> >>> The 2nd time the "instanceof >>> Cleaner" is executed after such OOME, the same line would throw >>> NoClassDefFoundError as a consequence of referencing a class that >>> failed >>> initialization. Am I right? >> >> instanceof is not one of the class initialization triggers, so we >> should not see an OOME generated due to a class initialization >> exception and so the class will not be put into the Erroneous state >> and so subsequent attempts to use the class will not automatically >> trigger NoClassdefFoundError. >> >> If OOME occurs during actual loading/linking of the class Cleaner it >> is unclear what would happen on subsequent attempts. OOME is not a >> LinkageError that must be rethrown on subsequent attempts, and it is >> potentially a transient condition, so I would expect a re-load >> attempt to be allowed. However we are now deep into the details of >> the VM and it may well depend on the exact place from which the OOME >> originates. >> >> The bottom line with the current problem is that there are multiple >> non-obvious paths by which the ReferenceHandler can encounter an >> OOME. In such cases we do not want the ReferenceHandler to terminate >> - which implies catching the OOME and continuing. However we also do >> not want to silently skip Cleaner processing or reference queue >> processing - as that would lead to hard to diagnoze bugs. But trying >> to report the problem may not be possible due to being out-of-memory. >> It may be that we need to break things up into multiple try/catch >> blocks, where each catch does a System.gc() and then reports that the >> OOME occurred. Of course the reporting must still be in a try/catch >> for the OOME. Though at some point letting the ReferenceHandler die >> may be the only way to "report" a major memory problem. >> >> David > > Hm... If I give -verbose:class option to run a simple test program: > > public class Test { public static void main(String... a) {} } > > I see Cleaner class being loaded before Test class. I don't see by > which tread or if it might get loaded after main() starts, but I > suspect that loading of Cleaner is not a problem here. Initialization > of Cleaner class is not performed by ReferenceHandler thread as you > pointed out. The instanceof does not trigger it and if it returns true > then Cleaner has already been initialized. So there must be some other > cause for instanceof throwing OOME... > > What do you say about this variant of ReferenceHandler.run() method: > > public void run() { > for (;;) { > Reference r; > Cleaner c; > synchronized (lock) { > r = pending; > if (r != null) { > // instanceof operator might throw OOME > sometimes. Just retry after > // yielding - might have better luck next time... > try { > c = r instanceof Cleaner ? (Cleaner) r : > null; > } catch (OutOfMemoryError x) { > Thread.yield(); > continue; > } > pending = r.discovered; > r.discovered = null; > } else { > // The waiting on the lock may cause an OOME > because it may try to allocate > // exception objects, so also catch OOME here > to avoid silent exit of the > // reference handler thread. > // > // Explicitly define the order of the two > exceptions we catch here > // when waiting for the lock. > // > // We do not want to try to potentially load > the InterruptedException class > // (which would be done if this was its first > use, and InterruptedException > // were checked first) in this situation. > // > // This may lead to the VM not ever trying to > load the InterruptedException > // class again. > try { > try { > lock.wait(); > } catch (OutOfMemoryError x) { } > } catch (InterruptedException x) { } > continue; > } > } > > // Fast path for cleaners > if (c != null) { > c.clean(); > continue; > } > > ReferenceQueue q = r.queue; > if (q != ReferenceQueue.NULL) q.enqueue(r); > } > } > > > > ... it tries to not consume and skip Cleaner instances when OOME is > caught. > > I don't think ReferenceHandler is to make responsible for reporting > OOMEs. Full heap is a global condition and ReferenceHandler is the > last to accuse for it. > > Regards, Peter Hi David, I think the following variation is even better. It executes Thread.yield() after catching OOME but outside synchronized block so that given CPU slice can be used by GC threads to make progress enqueueing pending References (they are not able to enqueue them while ReferenceHandler is holding the lock): public void run() { for (;;) { Reference r; Cleaner c; try { try { synchronized (lock) { r = pending; if (r != null) { // 'instanceof' might throw OOME sometimes so do this before // unlinking 'r' from the 'pending' chain... c = r instanceof Cleaner ? (Cleaner) r : null; // unlink 'r' from 'pending' chain pending = r.discovered; r.discovered = null; } else { // The waiting on the lock may cause an OOME because it may try to allocate // exception objects. lock.wait(); continue; } } } catch (OutOfMemoryError x) { // Catch OOME from 'r instanceof Cleaner' or 'lock.wait()' 1st so that we don't // try to potentially load the InterruptedException class // (which would be done if this was its first use, and InterruptedException // were checked first) in this situation. // Give other threads CPU time so they hopefully release some objects and GC // clears some heap. // Also prevent CPU intensive spinning in case 'r instanceof Cleaner' above // persistently throws OOME for some time... Thread.yield(); // retry continue; } } catch (InterruptedException x) { // Catch InterruptedException from 'lock.wait()' and retry continue; } // Fast path for cleaners if (c != null) { c.clean(); continue; } ReferenceQueue q = r.queue; if (q != ReferenceQueue.NULL) q.enqueue(r); } } Regards, Peter From paul.sandoz at oracle.com Mon Jan 20 09:32:25 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 20 Jan 2014 10:32:25 +0100 Subject: Review request for JDK-6760902: inconsistent behavior in bootstrap class loader for classes and resources In-Reply-To: <52D99C29.3020206@oracle.com> References: <52D73587.30104@oracle.com> <52D99C29.3020206@oracle.com> Message-ID: On Jan 17, 2014, at 10:10 PM, Mandy Chung wrote: > Paul, > > Here is the updated webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/6760902/webrev.01/ > > This cleans up GetResource.sh and merges with GetResource2.sh. Also fixed "if (pos - lastPoc > 0)" line and javadoc typo. > Looks good. -- In GetResource.sh: 89 GetResource $expected || exit 10 Should it be "exit $count" ?, i suppose it does not matter. Regardless no need for another review round for that. Paul. From volker.simonis at gmail.com Mon Jan 20 09:59:13 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 20 Jan 2014 10:59:13 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <52D50118.3080000@oracle.com> Message-ID: On Fri, Jan 17, 2014 at 10:15 PM, Volker Simonis wrote: > On Tue, Jan 14, 2014 at 10:19 AM, Alan Bateman wrote: >> On 14/01/2014 08:40, Volker Simonis wrote: >>> >>> Hi, >>> >>> could you please review the following changes for the ppc-aix-port >>> stage/stage-9 repositories (the changes are planned for integration into >>> ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): >> >> I'd like to review this but I won't have time until later in the week. From >> an initial look then there are a few things are not pretty (the changes to >> fix the AIX problems with I/O cancellation in particular) and I suspect that >> some refactoring is going to be required to handle some of this cleanly. A >> minor comment is that bug synopsis doesn't really communicate what these >> changes are about. >> >> -Alan. > > Just forwarded the following message from another thread here where it belongs: > > On 17/01/2014 16:57, Alan Bateman wrote: > > I've finally got to this one. As the event translation issue is now a > separate issue then I've ignored that part. > > I'm not comfortable with the changes to FileDispatcherImpl.c as I > don't think we shouldn't be calling into IO_ or NET_* functions here. > I think I get the issue that you have on AIX (and assume it's the > preClose/dup2 that blocks rather than close) but need a bit of time to > suggest alternatives. It may be that it will require an AIX specific > SocketDispatcher. Do you happen to know which tests fail due to this > part? > > The other changes look okay. There is a typo in the change to > zip_util.c, s/legel/legal/. > > In DatagramChannelImpl.c then you handle connect failing with > EAFNOSUPPORT. I would be tempted to replace the comment to say that it > EAFNOSUPPORT can be ignored on AIX. A minor comment but the > indentation for rv = errno can be fixed (I see the BSD code has it > wrong too). > On 17/01/2014 21:23, Volker Simonis wrote: > > > You're right, one race is with preClose/dup2 but also with other calls > > like read/fcntl/... > > > > There were several tests that failed and once I fixed it they all > > succeeded. But I can recreate some of the failures for you. The > > symptoms are always the same: the VMis locked. If you trigger a stack > > trace you can see that at least on thread is blocked in a I/O > > operation on a file descriptor like fcntl (e.g. for file locking), > > read, etc. while another thread is trying to close that socket. > > > > As it happens, we have some carry over issues from the Mac port, > one of which is that async close of FileChannels will block > indefinitely in dup2 when there is another thread blocked (on > fnctl or reading from a pipe ...). I haven't time time to work on > it but this discussion has reminded me that we need to sort it > out. I've put a preliminary webrev with the changes here: > > http://cr.openjdk.java.net/~alanb/7133499/webrev/ > > The important part is that it's using signal consistently on > Linux/Solaris/OSX so that any blocked threads are interrupted. My > guess is that if NativeThread.c is updated to define a signal on > AIX they this should resolve some of the issues on AIX. > > I would like to see the list of tests failing. If there is an > issue with dup2 with sockets (and OS X doesn't seem to have that > issue) then it will require further work but I would at least > like to start by understanding if this patch will help with the > FileChannel issues. Hi Alan, yes, that's interesting. Sounds like a very similar problem on Mac. I would suggest the following: I cut out the "Async Close AIX FIX" stuff from this change (i.e. "8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests" and send out a new webrev for the remaining part. I think that the remaining part was more or less reviewed and we can then push it faster. In the mean time, I'll recheck which tests exactly fail with my missing "Async Close AIX FIX" stuff and which of these tests will be fixed by your 7133499 webrev. Maybe we can really get trough with it or with it and a few enhancements. I'll let you know my results later today. By the way, my webrev already contained a AixNativeThread.c implementation in src/aix/native/sun/nio/ch. The only remaining problem I see with this approach is that we would need to downport your 7133499 change to 8u-dev in the 8u20 time frame to make our AIX port work. Would this be OK for you? Regards, Volker From paul.sandoz at oracle.com Mon Jan 20 10:38:18 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 20 Jan 2014 11:38:18 +0100 Subject: RFR: 8032190 It's unclear that flatMap will ensure each stream will be closed. Message-ID: <2A77FAFB-7F05-41AE-A73D-1C1B1E2D703C@oracle.com> Hi, For the flatMap operations of streams we forgot to say what it does with the mapped streams after it has processed them i.e. closes them, which is important for I/O backed streams (e.g. map Path -> Stream for lines of a file). The following patch fixes that omission in the docs: https://bugs.openjdk.java.net/browse/JDK-8032190 I think this should be backported to 8. Paul. diff -r 9bf43f25eacd src/share/classes/java/util/stream/DoubleStream.java --- a/src/share/classes/java/util/stream/DoubleStream.java Sat Jan 18 10:57:41 2014 -0800 +++ b/src/share/classes/java/util/stream/DoubleStream.java Mon Jan 20 11:34:17 2014 +0100 @@ -150,10 +150,11 @@ /** * Returns a stream consisting of the results of replacing each element of - * this stream with the contents of the stream produced by applying the - * provided mapping function to each element. (If the result of the mapping - * function is {@code null}, this is treated as if the result was an empty - * stream.) + * this stream with the contents of a mapped stream produced by applying + * the provided mapping function to each element. Each mapped stream is + * closed (see {@link java.util.stream.BaseStream#close()}) after its + * contents have been placed into this stream. (If a mapped stream is + * {@code null} then it treated as if it was an empty stream.) * *

This is an intermediate * operation. diff -r 9bf43f25eacd src/share/classes/java/util/stream/IntStream.java --- a/src/share/classes/java/util/stream/IntStream.java Sat Jan 18 10:57:41 2014 -0800 +++ b/src/share/classes/java/util/stream/IntStream.java Mon Jan 20 11:34:17 2014 +0100 @@ -146,10 +146,11 @@ /** * Returns a stream consisting of the results of replacing each element of - * this stream with the contents of the stream produced by applying the - * provided mapping function to each element. (If the result of the mapping - * function is {@code null}, this is treated as if the result was an empty - * stream.) + * this stream with the contents of a mapped stream produced by applying + * the provided mapping function to each element. Each mapped stream is + * closed (see {@link java.util.stream.BaseStream#close()}) after its + * contents have been placed into this stream. (If a mapped stream is + * {@code null} then it treated as if it was an empty stream.) * *

This is an intermediate * operation. diff -r 9bf43f25eacd src/share/classes/java/util/stream/LongStream.java --- a/src/share/classes/java/util/stream/LongStream.java Sat Jan 18 10:57:41 2014 -0800 +++ b/src/share/classes/java/util/stream/LongStream.java Mon Jan 20 11:34:17 2014 +0100 @@ -151,10 +151,11 @@ /** * Returns a stream consisting of the results of replacing each element of - * this stream with the contents of the stream produced by applying the - * provided mapping function to each element. (If the result of the mapping - * function is {@code null}, this is treated as if the result was an empty - * stream.) + * this stream with the contents of a mapped stream produced by applying + * the provided mapping function to each element. Each mapped stream is + * closed (see {@link java.util.stream.BaseStream#close()}) after its + * contents have been placed into this stream. (If a mapped stream is + * {@code null} then it treated as if it was an empty stream.) * *

This is an intermediate * operation. diff -r 9bf43f25eacd src/share/classes/java/util/stream/Stream.java --- a/src/share/classes/java/util/stream/Stream.java Sat Jan 18 10:57:41 2014 -0800 +++ b/src/share/classes/java/util/stream/Stream.java Mon Jan 20 11:34:17 2014 +0100 @@ -227,10 +227,11 @@ /** * Returns a stream consisting of the results of replacing each element of - * this stream with the contents of the stream produced by applying the - * provided mapping function to each element. (If the result of the mapping - * function is {@code null}, this is treated as if the result was an empty - * stream.) + * this stream with the contents of a mapped stream produced by applying + * the provided mapping function to each element. Each mapped stream is + * closed (see {@link java.util.stream.BaseStream#close()}) after its + * contents have been placed into this stream. (If a mapped stream is + * {@code null} then it treated as if it was an empty stream.) * *

This is an intermediate * operation. @@ -270,10 +271,11 @@ /** * Returns an {@code IntStream} consisting of the results of replacing each - * element of this stream with the contents of the stream produced by - * applying the provided mapping function to each element. (If the result - * of the mapping function is {@code null}, this is treated as if the result - * was an empty stream.) + * element of this stream with the contents of a mapped stream produced by + * applying the provided mapping function to each element. Each mapped + * stream is closed (see {@link java.util.stream.BaseStream#close()}) after + * its contents have been placed into this stream. (If a mapped stream is + * {@code null} then it treated as if it was an empty stream.) * *

This is an intermediate * operation. @@ -288,11 +290,12 @@ IntStream flatMapToInt(Function mapper); /** - * Returns a {@code LongStream} consisting of the results of replacing each - * element of this stream with the contents of the stream produced - * by applying the provided mapping function to each element. (If the result - * of the mapping function is {@code null}, this is treated as if the result - * was an empty stream.) + * Returns an {@code LongStream} consisting of the results of replacing each + * element of this stream with the contents of a mapped stream produced by + * applying the provided mapping function to each element. Each mapped + * stream is closed (see {@link java.util.stream.BaseStream#close()}) after + * its contents have been placed into this stream. (If a mapped stream is + * {@code null} then it treated as if it was an empty stream.) * *

This is an intermediate * operation. @@ -307,11 +310,12 @@ LongStream flatMapToLong(Function mapper); /** - * Returns a {@code DoubleStream} consisting of the results of replacing each - * element of this stream with the contents of the stream produced - * by applying the provided mapping function to each element. (If the result - * of the mapping function is {@code null}, this is treated as if the result - * was an empty stream.) + * Returns an {@code DoubleStream} consisting of the results of replacing + * each element of this stream with the contents of a mapped stream produced + * by applying the provided mapping function to each element. Each mapped + * stream is closed (see {@link java.util.stream.BaseStream#close()}) after + * its contents have placed been into this stream. (If a mapped stream is + * {@code null} then it treated as if it was an empty stream.) * *

This is an intermediate * operation. From Alan.Bateman at oracle.com Mon Jan 20 11:41:48 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 20 Jan 2014 11:41:48 +0000 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <52D50118.3080000@oracle.com> Message-ID: <52DD0B7C.4090605@oracle.com> On 20/01/2014 09:59, Volker Simonis wrote: > : > Hi Alan, > > yes, that's interesting. Sounds like a very similar problem on Mac. > > I would suggest the following: > > I cut out the "Async Close AIX FIX" stuff from this change (i.e. > "8031581: PPC64: Addons and fixes for AIX to pass the jdk regression > tests" and send out a new webrev for the remaining part. I think that > the remaining part was more or less reviewed and we can then push it > faster. > > In the mean time, I'll recheck which tests exactly fail with my > missing "Async Close AIX FIX" stuff and which of these tests will be > fixed by your 7133499 webrev. Maybe we can really get trough with it > or with it and a few enhancements. I'll let you know my results later > today. By the way, my webrev already contained a AixNativeThread.c > implementation in src/aix/native/sun/nio/ch. > > The only remaining problem I see with this approach is that we would > need to downport your 7133499 change to 8u-dev in the 8u20 time frame > to make our AIX port work. Would this be OK for you? > I'm okay with this plan and if you re-generate the webrev without the async close changes then I can look at it quickly so that you can get it into the stage-9 forest. On 7133499 then it would be a good candidate for 8u-dev too, I don't expect any problems but we will need to get it approved on the jdk8u-dev list. -Alan. From volker.simonis at gmail.com Mon Jan 20 13:45:12 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 20 Jan 2014 14:45:12 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: <52DD0B7C.4090605@oracle.com> References: <52D50118.3080000@oracle.com> <52DD0B7C.4090605@oracle.com> Message-ID: On Mon, Jan 20, 2014 at 12:41 PM, Alan Bateman wrote: > On 20/01/2014 09:59, Volker Simonis wrote: >> >> : >> Hi Alan, >> >> yes, that's interesting. Sounds like a very similar problem on Mac. >> >> I would suggest the following: >> >> I cut out the "Async Close AIX FIX" stuff from this change (i.e. >> "8031581: PPC64: Addons and fixes for AIX to pass the jdk regression >> tests" and send out a new webrev for the remaining part. I think that >> the remaining part was more or less reviewed and we can then push it >> faster. >> >> In the mean time, I'll recheck which tests exactly fail with my >> missing "Async Close AIX FIX" stuff and which of these tests will be >> fixed by your 7133499 webrev. Maybe we can really get trough with it >> or with it and a few enhancements. I'll let you know my results later >> today. By the way, my webrev already contained a AixNativeThread.c >> implementation in src/aix/native/sun/nio/ch. >> >> The only remaining problem I see with this approach is that we would >> need to downport your 7133499 change to 8u-dev in the 8u20 time frame >> to make our AIX port work. Would this be OK for you? >> > I'm okay with this plan and if you re-generate the webrev without the async > close changes then I can look at it quickly so that you can get it into the > stage-9 forest. > > On 7133499 then it would be a good candidate for 8u-dev too, I don't expect > any problems but we will need to get it approved on the jdk8u-dev list. > > -Alan. Hi everybody, so here's the second version of this webrev: http://cr.openjdk.java.net/~simonis/webrevs/8031581_2/ The main changes compared to the first webrew are as follows: - the POLL-constants related stuff has been factored out into its own webrev ("8031997: PPC64: Make the various POLL constants system dependant" - https://bugs.openjdk.java.net/browse/JDK-8031997). - the "Async close on AIX" workarounds have been taken out as well and will be handled separately (probably together with Alans fix for http://cr.openjdk.java.net/~alanb/7133499/webrev/). - in the remaining files I've applied the changes suggested by Staffan, so I think the changes to the following files can be considered as reviewed: src/share/native/sun/management/DiagnosticCommandImpl.c src/solaris/native/sun/management/OperatingSystemImpl.c src/share/transport/socket/socketTransport.c src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider - I've added the following additional files to the change: src/aix/classes/sun/nio/ch/sctp/SctpChannelImpl.java src/aix/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java src/aix/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java which are just empty stub implementations of the SCTP classes needed to pass the SCTP jtreg tests. All other changes should be the same like in the first review round. Thanks, Volker From chris.hegarty at oracle.com Mon Jan 20 14:18:46 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 20 Jan 2014 14:18:46 +0000 Subject: RFR: 8032190 It's unclear that flatMap will ensure each stream will be closed. In-Reply-To: <2A77FAFB-7F05-41AE-A73D-1C1B1E2D703C@oracle.com> References: <2A77FAFB-7F05-41AE-A73D-1C1B1E2D703C@oracle.com> Message-ID: <52DD3046.1070500@oracle.com> It is good to clarify that the streams are closed. I find the following updated wording a little odd, "If a mapped stream is {@code null} then it treated as if it was an empty stream." I thought the previous wording was better, but that could be just me. -Chris. On 20/01/14 10:38, Paul Sandoz wrote: > Hi, > > For the flatMap operations of streams we forgot to say what it does with the mapped streams after it has processed them i.e. closes them, which is important for I/O backed streams (e.g. map Path -> Stream for lines of a file). The following patch fixes that omission in the docs: > > https://bugs.openjdk.java.net/browse/JDK-8032190 > > I think this should be backported to 8. > > Paul. > > diff -r 9bf43f25eacd src/share/classes/java/util/stream/DoubleStream.java > --- a/src/share/classes/java/util/stream/DoubleStream.java Sat Jan 18 10:57:41 2014 -0800 > +++ b/src/share/classes/java/util/stream/DoubleStream.java Mon Jan 20 11:34:17 2014 +0100 > @@ -150,10 +150,11 @@ > > /** > * Returns a stream consisting of the results of replacing each element of > - * this stream with the contents of the stream produced by applying the > - * provided mapping function to each element. (If the result of the mapping > - * function is {@code null}, this is treated as if the result was an empty > - * stream.) > + * this stream with the contents of a mapped stream produced by applying > + * the provided mapping function to each element. Each mapped stream is > + * closed (see {@link java.util.stream.BaseStream#close()}) after its > + * contents have been placed into this stream. (If a mapped stream is > + * {@code null} then it treated as if it was an empty stream.) > * > *

This is an intermediate > * operation. > diff -r 9bf43f25eacd src/share/classes/java/util/stream/IntStream.java > --- a/src/share/classes/java/util/stream/IntStream.java Sat Jan 18 10:57:41 2014 -0800 > +++ b/src/share/classes/java/util/stream/IntStream.java Mon Jan 20 11:34:17 2014 +0100 > @@ -146,10 +146,11 @@ > > /** > * Returns a stream consisting of the results of replacing each element of > - * this stream with the contents of the stream produced by applying the > - * provided mapping function to each element. (If the result of the mapping > - * function is {@code null}, this is treated as if the result was an empty > - * stream.) > + * this stream with the contents of a mapped stream produced by applying > + * the provided mapping function to each element. Each mapped stream is > + * closed (see {@link java.util.stream.BaseStream#close()}) after its > + * contents have been placed into this stream. (If a mapped stream is > + * {@code null} then it treated as if it was an empty stream.) > * > *

This is an intermediate > * operation. > diff -r 9bf43f25eacd src/share/classes/java/util/stream/LongStream.java > --- a/src/share/classes/java/util/stream/LongStream.java Sat Jan 18 10:57:41 2014 -0800 > +++ b/src/share/classes/java/util/stream/LongStream.java Mon Jan 20 11:34:17 2014 +0100 > @@ -151,10 +151,11 @@ > > /** > * Returns a stream consisting of the results of replacing each element of > - * this stream with the contents of the stream produced by applying the > - * provided mapping function to each element. (If the result of the mapping > - * function is {@code null}, this is treated as if the result was an empty > - * stream.) > + * this stream with the contents of a mapped stream produced by applying > + * the provided mapping function to each element. Each mapped stream is > + * closed (see {@link java.util.stream.BaseStream#close()}) after its > + * contents have been placed into this stream. (If a mapped stream is > + * {@code null} then it treated as if it was an empty stream.) > * > *

This is an intermediate > * operation. > diff -r 9bf43f25eacd src/share/classes/java/util/stream/Stream.java > --- a/src/share/classes/java/util/stream/Stream.java Sat Jan 18 10:57:41 2014 -0800 > +++ b/src/share/classes/java/util/stream/Stream.java Mon Jan 20 11:34:17 2014 +0100 > @@ -227,10 +227,11 @@ > > /** > * Returns a stream consisting of the results of replacing each element of > - * this stream with the contents of the stream produced by applying the > - * provided mapping function to each element. (If the result of the mapping > - * function is {@code null}, this is treated as if the result was an empty > - * stream.) > + * this stream with the contents of a mapped stream produced by applying > + * the provided mapping function to each element. Each mapped stream is > + * closed (see {@link java.util.stream.BaseStream#close()}) after its > + * contents have been placed into this stream. (If a mapped stream is > + * {@code null} then it treated as if it was an empty stream.) > * > *

This is an intermediate > * operation. > @@ -270,10 +271,11 @@ > > /** > * Returns an {@code IntStream} consisting of the results of replacing each > - * element of this stream with the contents of the stream produced by > - * applying the provided mapping function to each element. (If the result > - * of the mapping function is {@code null}, this is treated as if the result > - * was an empty stream.) > + * element of this stream with the contents of a mapped stream produced by > + * applying the provided mapping function to each element. Each mapped > + * stream is closed (see {@link java.util.stream.BaseStream#close()}) after > + * its contents have been placed into this stream. (If a mapped stream is > + * {@code null} then it treated as if it was an empty stream.) > * > *

This is an intermediate > * operation. > @@ -288,11 +290,12 @@ > IntStream flatMapToInt(Function mapper); > > /** > - * Returns a {@code LongStream} consisting of the results of replacing each > - * element of this stream with the contents of the stream produced > - * by applying the provided mapping function to each element. (If the result > - * of the mapping function is {@code null}, this is treated as if the result > - * was an empty stream.) > + * Returns an {@code LongStream} consisting of the results of replacing each > + * element of this stream with the contents of a mapped stream produced by > + * applying the provided mapping function to each element. Each mapped > + * stream is closed (see {@link java.util.stream.BaseStream#close()}) after > + * its contents have been placed into this stream. (If a mapped stream is > + * {@code null} then it treated as if it was an empty stream.) > * > *

This is an intermediate > * operation. > @@ -307,11 +310,12 @@ > LongStream flatMapToLong(Function mapper); > > /** > - * Returns a {@code DoubleStream} consisting of the results of replacing each > - * element of this stream with the contents of the stream produced > - * by applying the provided mapping function to each element. (If the result > - * of the mapping function is {@code null}, this is treated as if the result > - * was an empty stream.) > + * Returns an {@code DoubleStream} consisting of the results of replacing > + * each element of this stream with the contents of a mapped stream produced > + * by applying the provided mapping function to each element. Each mapped > + * stream is closed (see {@link java.util.stream.BaseStream#close()}) after > + * its contents have placed been into this stream. (If a mapped stream is > + * {@code null} then it treated as if it was an empty stream.) > * > *

This is an intermediate > * operation. > From ivan.gerasimov at oracle.com Mon Jan 20 14:53:23 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 20 Jan 2014 18:53:23 +0400 Subject: RFR [8027348] (process) Enhancement of handling async close of ProcessInputStream In-Reply-To: References: <528BCD2E.5090209@oracle.com> Message-ID: <52DD3863.8050405@oracle.com> Hello everybody! Can I consider this change approved for jdk9? Thanks in advance, Ivan Gerasimov On 20.11.2013 0:56, Martin Buchholz wrote: > Ivan, > Thanks for taking ownership of my proposed change. Looks good to me! > > (I can't actually push changes like this myself because I only do > Linux these days) > > > On Tue, Nov 19, 2013 at 12:42 PM, Ivan Gerasimov > > wrote: > > Hello all! > > May I have a review for the improvement contributed by Martin > Buchholz? > https://bugs.openjdk.java.net/browse/JDK-8027348 > > First, it the change performs the code cleanup, and second it > makes the test much faster. > This should also help to resolve the issue with the current > version of the test, which was reported to fail intermittently by > timeout. > https://bugs.openjdk.java.net/browse/JDK-8028574 > > Here's the webrev with the change: > http://cr.openjdk.java.net/~igerasim/8027348/0/webrev/ > > > Sincerely yours, > Ivan Gerasimov > > From paul.sandoz at oracle.com Mon Jan 20 15:18:57 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 20 Jan 2014 16:18:57 +0100 Subject: RFR: 8032190 It's unclear that flatMap will ensure each stream will be closed. In-Reply-To: <52DD3046.1070500@oracle.com> References: <2A77FAFB-7F05-41AE-A73D-1C1B1E2D703C@oracle.com> <52DD3046.1070500@oracle.com> Message-ID: <945CCAF6-375D-41E3-A24A-9BE7328A8D3B@oracle.com> On Jan 20, 2014, at 3:18 PM, Chris Hegarty wrote: > It is good to clarify that the streams are closed. > > I find the following updated wording a little odd, "If a mapped stream is {@code null} then it treated as if it was an empty stream." I thought the previous wording was better, but that could be just me. > I was hopping to use the term "mapped stream" to avoid some repetition for "the result of the mapping function" etc, but wording seems a little garbled. How about: If a mapped stream is {@code null} an empty stream is used, instead. Paul. From Alan.Bateman at oracle.com Mon Jan 20 15:24:01 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 20 Jan 2014 15:24:01 +0000 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <52D50118.3080000@oracle.com> <52DD0B7C.4090605@oracle.com> Message-ID: <52DD3F91.7020202@oracle.com> On 20/01/2014 13:45, Volker Simonis wrote: > : > Hi everybody, > > so here's the second version of this webrev: > > http://cr.openjdk.java.net/~simonis/webrevs/8031581_2/ This looks okay to me. The typo ("legel" -> "legal") still exists in zip_util.c and maybe that can be fixed before you push this (no need to generate a few webrev of course). For the JDWP socket transport then it's interesting that shutdown is being used to cause the reader thread to be preempted. That may be useful when it comes to addressing the bigger async close issue. > > The main changes compared to the first webrew are as follows: > > - the POLL-constants related stuff has been factored out into its own > webrev ("8031997: PPC64: Make the various POLL constants system > dependant" - https://bugs.openjdk.java.net/browse/JDK-8031997). I see this has been pushed to ppc-aix-port/stage-9. Would you have any objection if I brought this into jdk9/dev (minus the AixPollPort change)? We can use a different bug number so as not to cause duplicate bug issues. It should trivially merge when you come to sync'ing up the staging forest. > - the "Async close on AIX" workarounds have been taken out as well > and will be handled separately Thanks for separating this one out as I suspect this that doing this cleanly is going to involve changes for all platforms. -Alan. From volker.simonis at gmail.com Mon Jan 20 16:29:13 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 20 Jan 2014 17:29:13 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: <52DD3F91.7020202@oracle.com> References: <52D50118.3080000@oracle.com> <52DD0B7C.4090605@oracle.com> <52DD3F91.7020202@oracle.com> Message-ID: On Mon, Jan 20, 2014 at 4:24 PM, Alan Bateman wrote: > On 20/01/2014 13:45, Volker Simonis wrote: >> >> : >> Hi everybody, >> >> so here's the second version of this webrev: >> >> http://cr.openjdk.java.net/~simonis/webrevs/8031581_2/ > > This looks okay to me. Thanks. > > The typo ("legel" -> "legal") still exists in zip_util.c and maybe that can > be fixed before you push this (no need to generate a few webrev of course). > Sorry, I've just fixed it in my patch queue and will used the fixed version for pushing. @Vladimir: could you please run this change (http://cr.openjdk.java.net/~simonis/webrevs/8031581_2) through JPRT as well. I'll push it (together with the fixed typo in the comment) if everything is OK. > For the JDWP socket transport then it's interesting that shutdown is being > used to cause the reader thread to be preempted. That may be useful when it > comes to addressing the bigger async close issue. > > >> >> The main changes compared to the first webrew are as follows: >> >> - the POLL-constants related stuff has been factored out into its own >> webrev ("8031997: PPC64: Make the various POLL constants system >> dependant" - https://bugs.openjdk.java.net/browse/JDK-8031997). > > I see this has been pushed to ppc-aix-port/stage-9. Would you have any > objection if I brought this into jdk9/dev (minus the AixPollPort change)? We > can use a different bug number so as not to cause duplicate bug issues. It > should trivially merge when you come to sync'ing up the staging forest. > I have no objections of course. I'm just not sure what exact implications this will have. @Vladimir: what do you think - can Alan push "8031997: PPC64: Make the various POLL constants system dependant" minus the Aix-specific stuff to jdk9/dev now, without causing you any harm during integration. @Alan: on the other hand, the bulk integration from ppc-aix-port/stage-9 to jdk9/dev is planned for next week anyway, so maybe you could wait until that happens? Thanks, Volker > >> - the "Async close on AIX" workarounds have been taken out as well >> and will be handled separately > > Thanks for separating this one out as I suspect this that doing this cleanly > is going to involve changes for all platforms. > > -Alan. From Alan.Bateman at oracle.com Mon Jan 20 16:42:39 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 20 Jan 2014 16:42:39 +0000 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <52D50118.3080000@oracle.com> <52DD0B7C.4090605@oracle.com> <52DD3F91.7020202@oracle.com> Message-ID: <52DD51FF.7060502@oracle.com> On 20/01/2014 16:29, Volker Simonis wrote: > : > > @Alan: on the other hand, the bulk integration from > ppc-aix-port/stage-9 to jdk9/dev is planned for next week anyway, so > maybe you could wait until that happens? > In that case then ignore my request, I assumed it would not be pushed to jdk9/dev until end-Feb. -Alan From paul.sandoz at oracle.com Mon Jan 20 17:24:39 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 20 Jan 2014 18:24:39 +0100 Subject: RFR: JDK-8032012, , String.toLowerCase/toUpperCase performance improvement In-Reply-To: <52D82013.7020009@oracle.com> References: <52D82013.7020009@oracle.com> Message-ID: On Jan 16, 2014, at 7:08 PM, Xueming Shen wrote: > Hi, > > The proposed changeset is to improve the performance (both speed and memory > usage) of String.toLowerCase/toUpperCase, by > > (1) to separate the "most likely" use scenario (non supplementary character, no special > case mapping handling) into simple/quick iteration loop code path > (2) to use the package private constructor String(char[], boolean) to avoid unnecessary > target char[] copy in fast-path case. > (3) some tiny code cleanup. > > Since it's supposed to be a simple/quick round of code cleanup, I did not go too far to > optimize the supplementary/special mapping code. > > The webrev is > > http://cr.openjdk.java.net/~sherman/8032012/ > Some quick comments. In String.toLowerCase: - it would be nice to get rid of the pseudo goto using the "scan" labelled block. - there is no need for the "localeDependent" local variable. - you might be able to optimize by doing (could depend on the answer to the next point): int c = (int)value[i]; int lc = Character.toLowerCase(c); if (.....) { result[i] = (char)lc; } else { return toLowerCaseEx(result, i, locale, localeDependent); } - Do you need to check ERROR for the result of toLowerCase? 2586 if (c == Character.ERROR || Paul. From mandy.chung at oracle.com Mon Jan 20 18:17:18 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 20 Jan 2014 10:17:18 -0800 Subject: JDK 9 RFR for 8031980: Add new j.u.l deadlock test for JDK-8027670 and JDK-8029281 In-Reply-To: <52D9436C.7090306@oracle.com> References: <52D9436C.7090306@oracle.com> Message-ID: <52DD682E.8020900@oracle.com> On 1/17/2014 6:51 AM, Daniel Fuchs wrote: > Hi, > > Please find below a webrev for: > > 8031980: Add new j.u.l deadlock test for JDK-8027670 and JDK-8029281 > https://bugs.openjdk.java.net/browse/JDK-8031980 > > The new test looks reasonable. "foo.bar5.level = INFO" is commented out in deadlock.conf.properties. Is this intentional? The test runs in the same VM first without security manager and then with security manager. The loggers have been created and may/may not be GC'ed. I wonder if it's worth breaking them into two separate runs so that each run starts with no logger. Have you also tried running this with -Xcomp and see if any intermittent failure due to GC? It looks fine when reviewing the test but better to verify it. Mandy From daniel.fuchs at oracle.com Mon Jan 20 18:35:28 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 20 Jan 2014 19:35:28 +0100 Subject: JDK 9 RFR for 8031980: Add new j.u.l deadlock test for JDK-8027670 and JDK-8029281 In-Reply-To: <52DD682E.8020900@oracle.com> References: <52D9436C.7090306@oracle.com> <52DD682E.8020900@oracle.com> Message-ID: <52DD6C70.2000405@oracle.com> On 1/20/14 7:17 PM, Mandy Chung wrote: > On 1/17/2014 6:51 AM, Daniel Fuchs wrote: >> Hi, >> >> Please find below a webrev for: >> >> 8031980: Add new j.u.l deadlock test for JDK-8027670 and JDK-8029281 >> https://bugs.openjdk.java.net/browse/JDK-8031980 >> >> > > The new test looks reasonable. "foo.bar5.level = INFO" is commented > out in deadlock.conf.properties. Is this intentional? Yes - I still wanted to have a case where a logger wouldn't have a parent in the configuration file - just in case (although that should already be tested by the 'old' test). > The test runs in > the same VM first without security manager and then with security > manager. The loggers have been created and may/may not be GC'ed. I > wonder if it's worth breaking them into two separate runs so that each > run starts with no logger. hmm. good point. I don't think it really needs to though. Most of the time the deadlock will happen with "with no security", but sometimes you have to wait for the "with security" before it does happen. And sometime you have to rerun the test - but that is rare. IMHO a bit of randomness is not bad for that kind of test. > Have you also tried running this with > -Xcomp and see if any intermittent failure due to GC? It looks fine > when reviewing the test but better to verify it. No - haven't tried yet. Will do. However I saw it fail with errors indicating that loggers which should not have been gc'ed had been gc'ed when I ran it on a platform that didn't have JDK-8029281, which means that it's also a good test for the changes in LoggerWeakRef.dispose() from JDK-8029281. May I push after verifying that it doesn't fail with -Xcomp? best regards, -- daniel > > Mandy From mandy.chung at oracle.com Mon Jan 20 20:49:22 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 20 Jan 2014 12:49:22 -0800 Subject: JDK 9 RFR for 8031980: Add new j.u.l deadlock test for JDK-8027670 and JDK-8029281 In-Reply-To: <52DD6C70.2000405@oracle.com> References: <52D9436C.7090306@oracle.com> <52DD682E.8020900@oracle.com> <52DD6C70.2000405@oracle.com> Message-ID: <52DD8BD2.4040907@oracle.com> On 1/20/2014 10:35 AM, Daniel Fuchs wrote: > On 1/20/14 7:17 PM, Mandy Chung wrote: >> On 1/17/2014 6:51 AM, Daniel Fuchs wrote: >>> Hi, >>> >>> Please find below a webrev for: >>> >>> 8031980: Add new j.u.l deadlock test for JDK-8027670 and JDK-8029281 >>> https://bugs.openjdk.java.net/browse/JDK-8031980 >>> >>> >> >> The new test looks reasonable. "foo.bar5.level = INFO" is commented >> out in deadlock.conf.properties. Is this intentional? > > Yes - I still wanted to have a case where a logger wouldn't > have a parent in the configuration file - just in case > (although that should already be tested by the 'old' test). > That's what I suspect too - I suggest adding a comment to make it clear. > >> Have you also tried running this with >> -Xcomp and see if any intermittent failure due to GC? It looks fine >> when reviewing the test but better to verify it. > > No - haven't tried yet. Will do. However I saw it fail with errors > indicating that loggers which should not have been gc'ed had been > gc'ed when I ran it on a platform that didn't have JDK-8029281, > which means that it's also a good test for the changes in > LoggerWeakRef.dispose() from JDK-8029281. > > May I push after verifying that it doesn't fail with -Xcomp? > Yes and thanks for being proactive to verify that. Mandy From Alan.Bateman at oracle.com Mon Jan 20 22:16:08 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 20 Jan 2014 22:16:08 +0000 Subject: RFR: 8032190 It's unclear that flatMap will ensure each stream will be closed. In-Reply-To: <2A77FAFB-7F05-41AE-A73D-1C1B1E2D703C@oracle.com> References: <2A77FAFB-7F05-41AE-A73D-1C1B1E2D703C@oracle.com> Message-ID: <52DDA028.8090006@oracle.com> On 20/01/2014 10:38, Paul Sandoz wrote: > Hi, > > For the flatMap operations of streams we forgot to say what it does with the mapped streams after it has processed them i.e. closes them, which is important for I/O backed streams (e.g. map Path -> Stream for lines of a file). The following patch fixes that omission in the docs: > > https://bugs.openjdk.java.net/browse/JDK-8032190 > > I think this should be backported to 8. > > Paul. This is important to add. A minor comment is to just link "closed" to BaseStream#close rather than adding "see ...". "If a mapper stream is null then an empty stream is used" seems okay to me. -Alan From chris.hegarty at oracle.com Mon Jan 20 22:26:56 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 20 Jan 2014 22:26:56 +0000 Subject: RFR: 8032190 It's unclear that flatMap will ensure each stream will be closed. In-Reply-To: <945CCAF6-375D-41E3-A24A-9BE7328A8D3B@oracle.com> References: <2A77FAFB-7F05-41AE-A73D-1C1B1E2D703C@oracle.com> <52DD3046.1070500@oracle.com> <945CCAF6-375D-41E3-A24A-9BE7328A8D3B@oracle.com> Message-ID: <310163E9-DD56-4401-A920-BB14BFE42CA2@oracle.com> > On 20 Jan 2014, at 15:18, Paul Sandoz wrote: > > >> On Jan 20, 2014, at 3:18 PM, Chris Hegarty wrote: >> >> It is good to clarify that the streams are closed. >> >> I find the following updated wording a little odd, "If a mapped stream is {@code null} then it treated as if it was an empty stream." I thought the previous wording was better, but that could be just me. > > I was hopping to use the term "mapped stream" to avoid some repetition for "the result of the mapping function" etc, but wording seems a little garbled. > > How about: > > If a mapped stream is {@code null} an empty stream is used, instead. Thanks Paul. Seems fine to me. -Chris. > Paul. > > > > From david.holmes at oracle.com Tue Jan 21 02:22:43 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 Jan 2014 12:22:43 +1000 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52DCE17B.4050708@gmail.com> References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> <52CC72AB.2020104@oracle.com> <52CCEDE0.8000809@oracle.com> <52CCF079.4090301@oracle.com> <52CD45E7.7010203@gmail.com> <52CE4E2D.300@oracle.com> <52CF37C6.1070605@oracle.com> <52CFAFEB.9090703@gmail.com> <52CFD218.2060101@gmail.com> <52D06B70.60001@oracle.com> <52D15201.90109@gmail.com> <52D47D59.8040905@oracle.com> <52D72577.1050506@oracle.com> <52D76859.2030502@oracle.com> <52D82968.4030608@oracle.com> <52D8929B.2020905@oracle.com> <52D8A42A.4020906@oracle.com> <52D8B3B6.3030202@oracle.com> <52D9295D.6080106@gmail.com> <52D92C73.2020309@gmail.com> <52D92F1A.4040400@gmail.com> <52DC812C.1000607@oracle.com> <52DCD78E.8050404@gmail.com> <52DCE17B.4050708@gmail.com> Message-ID: <52DDD9F3.1050201@oracle.com> Hi Peter, I do not see Cleaner being loaded prior to the main class on either Windows or Linux. Which platform are you on? Did you see it loaded before the main class or as part of executing it? Also, it is not that I think ReferenceHandler is responsible for reporting OOME, but that it is responsible for reporting that it was unable to perform a clean or enqueue because of OOME. Your suggested approach seems okay though I'm not sure why we shouldn't help things along by calling System.gc() ourselves rather than just yielding and hoping things will get cleaned up elsewhere. But for the present purposes your approach will suffice I think. Thanks, David On 20/01/2014 6:42 PM, Peter Levart wrote: > On 01/20/2014 09:00 AM, Peter Levart wrote: >> On 01/20/2014 02:51 AM, David Holmes wrote: >>> Hi Peter, >>> >>> On 17/01/2014 11:24 PM, Peter Levart wrote: >>>> On 01/17/2014 02:13 PM, Peter Levart wrote: >>>>>>> // Fast path for cleaners >>>>>>> boolean isCleaner = false; >>>>>>> try { >>>>>>> isCleaner = r instanceof Cleaner; >>>>>>> } catch (OutofMemoryError oome) { >>>>>>> continue; >>>>>>> } >>>>>>> >>>>>>> if (isCleaner) { >>>>>>> ((Cleaner)r).clean(); >>>>>>> continue; >>>>>>> } >>>>>>> >>>>>> >>>>>> Hi David, Kalyan, >>>>>> >>>>>> I've caught-up now. Just thinking: is "instanceof Cleaner" throwing >>>>>> OOME as a result of loading the Cleaner class? Wouldn't the above >>>>>> code then throw some error also in ((Cleaner)r) - the checkcast, >>>>>> since Cleaner class would not be successfully initialized? >>>>> >>>>> Well, no. The above code would just skip Cleaner processing in this >>>>> situation. And will never be doing it again after the heap is freed... >>>>> So it might be good to load and initialize Cleaner class as part of >>>>> ReferenceHandler initialization to ensure correct operation... >>>> >>>> Well, yes and no. Let me try once more: >>>> >>>> Above code will skip Cleaner processing if the 1st time "instanceof >>>> Cleaner" is executed, OOME is thrown as a consequence of full heap >>>> while >>>> loading and initializing the Cleaner class. >>> >>> Yes - I was assuming that this would not fail the very first time and >>> so the Cleaner class would already be loaded. Failing to be able to >>> load the Cleaner class was one of the potential issues flagged >>> earlier with this problem. I was actually assuming that Cleaner would >>> be loaded already due to some actual Cleaner subclasses being used, >>> but this does not happen as part of the default initialization. :( >>> The irony being that if the Cleaner class is not loaded then r can >>> not be an instance of Cleaner and so we would fail to load the class >>> in a case where we didn't need it anyway. >>> >>> What I wanted to focus on here was an OOME from the instanceof >>> itself, but as you say that might trigger classloading of Cleaner >>> (which is not what I was interested in). >>> >>>> The 2nd time the "instanceof >>>> Cleaner" is executed after such OOME, the same line would throw >>>> NoClassDefFoundError as a consequence of referencing a class that >>>> failed >>>> initialization. Am I right? >>> >>> instanceof is not one of the class initialization triggers, so we >>> should not see an OOME generated due to a class initialization >>> exception and so the class will not be put into the Erroneous state >>> and so subsequent attempts to use the class will not automatically >>> trigger NoClassdefFoundError. >>> >>> If OOME occurs during actual loading/linking of the class Cleaner it >>> is unclear what would happen on subsequent attempts. OOME is not a >>> LinkageError that must be rethrown on subsequent attempts, and it is >>> potentially a transient condition, so I would expect a re-load >>> attempt to be allowed. However we are now deep into the details of >>> the VM and it may well depend on the exact place from which the OOME >>> originates. >>> >>> The bottom line with the current problem is that there are multiple >>> non-obvious paths by which the ReferenceHandler can encounter an >>> OOME. In such cases we do not want the ReferenceHandler to terminate >>> - which implies catching the OOME and continuing. However we also do >>> not want to silently skip Cleaner processing or reference queue >>> processing - as that would lead to hard to diagnoze bugs. But trying >>> to report the problem may not be possible due to being out-of-memory. >>> It may be that we need to break things up into multiple try/catch >>> blocks, where each catch does a System.gc() and then reports that the >>> OOME occurred. Of course the reporting must still be in a try/catch >>> for the OOME. Though at some point letting the ReferenceHandler die >>> may be the only way to "report" a major memory problem. >>> >>> David >> >> Hm... If I give -verbose:class option to run a simple test program: >> >> public class Test { public static void main(String... a) {} } >> >> I see Cleaner class being loaded before Test class. I don't see by >> which tread or if it might get loaded after main() starts, but I >> suspect that loading of Cleaner is not a problem here. Initialization >> of Cleaner class is not performed by ReferenceHandler thread as you >> pointed out. The instanceof does not trigger it and if it returns true >> then Cleaner has already been initialized. So there must be some other >> cause for instanceof throwing OOME... >> >> What do you say about this variant of ReferenceHandler.run() method: >> >> public void run() { >> for (;;) { >> Reference r; >> Cleaner c; >> synchronized (lock) { >> r = pending; >> if (r != null) { >> // instanceof operator might throw OOME >> sometimes. Just retry after >> // yielding - might have better luck next time... >> try { >> c = r instanceof Cleaner ? (Cleaner) r : >> null; >> } catch (OutOfMemoryError x) { >> Thread.yield(); >> continue; >> } >> pending = r.discovered; >> r.discovered = null; >> } else { >> // The waiting on the lock may cause an OOME >> because it may try to allocate >> // exception objects, so also catch OOME here >> to avoid silent exit of the >> // reference handler thread. >> // >> // Explicitly define the order of the two >> exceptions we catch here >> // when waiting for the lock. >> // >> // We do not want to try to potentially load >> the InterruptedException class >> // (which would be done if this was its first >> use, and InterruptedException >> // were checked first) in this situation. >> // >> // This may lead to the VM not ever trying to >> load the InterruptedException >> // class again. >> try { >> try { >> lock.wait(); >> } catch (OutOfMemoryError x) { } >> } catch (InterruptedException x) { } >> continue; >> } >> } >> >> // Fast path for cleaners >> if (c != null) { >> c.clean(); >> continue; >> } >> >> ReferenceQueue q = r.queue; >> if (q != ReferenceQueue.NULL) q.enqueue(r); >> } >> } >> >> >> >> ... it tries to not consume and skip Cleaner instances when OOME is >> caught. >> >> I don't think ReferenceHandler is to make responsible for reporting >> OOMEs. Full heap is a global condition and ReferenceHandler is the >> last to accuse for it. >> >> Regards, Peter > > Hi David, > > I think the following variation is even better. It executes > Thread.yield() after catching OOME but outside synchronized block so > that given CPU slice can be used by GC threads to make progress > enqueueing pending References (they are not able to enqueue them while > ReferenceHandler is holding the lock): > > > public void run() { > for (;;) { > Reference r; > Cleaner c; > try { > try { > synchronized (lock) { > r = pending; > if (r != null) { > // 'instanceof' might throw OOME > sometimes so do this before > // unlinking 'r' from the 'pending' > chain... > c = r instanceof Cleaner ? (Cleaner) r > : null; > // unlink 'r' from 'pending' chain > pending = r.discovered; > r.discovered = null; > } else { > // The waiting on the lock may cause an > OOME because it may try to allocate > // exception objects. > lock.wait(); > continue; > } > } > } catch (OutOfMemoryError x) { > // Catch OOME from 'r instanceof Cleaner' or > 'lock.wait()' 1st so that we don't > // try to potentially load the > InterruptedException class > // (which would be done if this was its first > use, and InterruptedException > // were checked first) in this situation. > // Give other threads CPU time so they > hopefully release some objects and GC > // clears some heap. > // Also prevent CPU intensive spinning in case > 'r instanceof Cleaner' above > // persistently throws OOME for some time... > Thread.yield(); > // retry > continue; > } > } catch (InterruptedException x) { > // Catch InterruptedException from 'lock.wait()' > and retry > continue; > } > > // Fast path for cleaners > if (c != null) { > c.clean(); > continue; > } > > ReferenceQueue q = r.queue; > if (q != ReferenceQueue.NULL) q.enqueue(r); > } > } > > > Regards, Peter > From peter.levart at gmail.com Tue Jan 21 06:54:57 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 21 Jan 2014 07:54:57 +0100 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52DDD9F3.1050201@oracle.com> References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> <52CC72AB.2020104@oracle.com> <52CCEDE0.8000809@oracle.com> <52CCF079.4090301@oracle.com> <52CD45E7.7010203@gmail.com> <52CE4E2D.300@oracle.com> <52CF37C6.1070605@oracle.com> <52CFAFEB.9090703@gmail.com> <52CFD218.2060101@gmail.com> <52D06B70.60001@oracle.com> <52D15201.90109@gmail.com> <52D47D59.8040905@oracle.com> <52D72577.1050506@oracle.com> <52D76859.2030502@oracle.com> <52D82968.4030608@oracle.com> <52D8929B.2020905@oracle.com> <52D8A42A.4020906@oracle.com> <52D8B3B6.3030202@oracle.com> <52D9295D.6080106@gmail.com> <52D92C73.2020309@gmail.com> <52D92F1A.4040400@gmail.com> <52DC812C.1000607@oracle.com> <52DCD78E.8050404@gmail.com> <52DCE17B.4050708@gmail.com> <52DDD9F3.1050201@oracle.com> Message-ID: <52DE19C1.2070302@gmail.com> On 01/21/2014 03:22 AM, David Holmes wrote: > Hi Peter, > > I do not see Cleaner being loaded prior to the main class on either > Windows or Linux. Which platform are you on? Did you see it loaded > before the main class or as part of executing it? Before. The main class is empty: public class Test { public static void main(String... a) {} } Here's last few lines of -verbose:class: [Loaded java.util.TimeZone from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] [Loaded sun.util.calendar.ZoneInfo from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] [Loaded sun.util.calendar.ZoneInfoFile from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] [Loaded sun.util.calendar.ZoneInfoFile$1 from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] [Loaded java.io.DataInput from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] [Loaded java.io.DataInputStream from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] *[Loaded sun.misc.Cleaner from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar]* [Loaded java.io.ByteArrayInputStream from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] [Loaded sun.util.calendar.ZoneInfoFile$ZoneOffsetTransitionRule from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] [Loaded java.util.zip.Checksum from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] [Loaded java.util.zip.CRC32 from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] [Loaded sun.util.calendar.ZoneInfoFile$Checksum from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] [Loaded java.util.TimeZone$1 from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] [Loaded sun.util.calendar.CalendarDate from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] [Loaded sun.util.calendar.BaseCalendar$Date from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] [Loaded sun.util.calendar.Gregorian$Date from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] [Loaded sun.util.calendar.CalendarUtils from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] [Loaded java.util.jar.JarEntry from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] [Loaded java.util.jar.JarFile$JarFileEntry from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] [Loaded java.util.zip.ZipFile$ZipFileInputStream from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] [Loaded java.util.AbstractSequentialList from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] [Loaded java.util.LinkedList from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] [Loaded java.util.LinkedList$Node from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] [Loaded java.security.PrivilegedActionException from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] [Loaded sun.misc.URLClassPath$FileLoader from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] [Loaded sun.misc.Resource from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] [Loaded sun.misc.URLClassPath$FileLoader$1 from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] [Loaded sun.nio.ByteBuffered from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] [Loaded java.security.PermissionCollection from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] [Loaded java.security.Permissions from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] [Loaded java.net.URLConnection from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] [Loaded sun.net.www.URLConnection from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] [Loaded sun.net.www.protocol.file.FileURLConnection from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] [Loaded sun.net.www.MessageHeader from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] [Loaded java.io.FilePermission from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] [Loaded java.io.FilePermission$1 from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] [Loaded java.io.FilePermissionCollection from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] [Loaded java.security.AllPermission from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] [Loaded java.security.UnresolvedPermission from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] [Loaded java.security.BasicPermissionCollection from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] *[Loaded Test from file:/tmp/]* [Loaded sun.launcher.LauncherHelper$FXHelper from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] [Loaded java.lang.Shutdown from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] [Loaded java.lang.Shutdown$Lock from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] I'm on linux, 64bit and using official EA build 121 of JDK 8... But if I try with JDK 7u45, I don't see it. So perhaps it would be good to trigger Cleaner loading and initialization as part of ReferenceHandler initialization to play things safe. > > Also, it is not that I think ReferenceHandler is responsible for > reporting OOME, but that it is responsible for reporting that it was > unable to perform a clean or enqueue because of OOME. This would be necessary if we skipped a Reference because of OOME, but if we just re-try until we eventually succeed, nothing is lost, nothing to report (but a slow response)... > > Your suggested approach seems okay though I'm not sure why we > shouldn't help things along by calling System.gc() ourselves rather > than just yielding and hoping things will get cleaned up elsewhere. > But for the present purposes your approach will suffice I think. Maybe my understanding is wrong but isn't the fact that OOME is rised a consequence of that VM has already attempted to clear things up (executing a GC round synchronously) but didn't succeed to make enough free space to satisfy the allocation request? If this is only how some collectors/allocators are implemented and not a general rule, then we should put a System.gc() in place of Thread.yield(). Should we also combine that with Thread.yield()? I'm concerned of a possibility that we spin, consume too much CPU (ReferenceHandler thread has MAX priority) so that other threads dont' get enough CPU time to proceed and clean things up (we hope other threads will also get OOME and release things as their stacks unwind...). Regards, Peter > > Thanks, > David > > On 20/01/2014 6:42 PM, Peter Levart wrote: >> On 01/20/2014 09:00 AM, Peter Levart wrote: >>> On 01/20/2014 02:51 AM, David Holmes wrote: >>>> Hi Peter, >>>> >>>> On 17/01/2014 11:24 PM, Peter Levart wrote: >>>>> On 01/17/2014 02:13 PM, Peter Levart wrote: >>>>>>>> // Fast path for cleaners >>>>>>>> boolean isCleaner = false; >>>>>>>> try { >>>>>>>> isCleaner = r instanceof Cleaner; >>>>>>>> } catch (OutofMemoryError oome) { >>>>>>>> continue; >>>>>>>> } >>>>>>>> >>>>>>>> if (isCleaner) { >>>>>>>> ((Cleaner)r).clean(); >>>>>>>> continue; >>>>>>>> } >>>>>>>> >>>>>>> >>>>>>> Hi David, Kalyan, >>>>>>> >>>>>>> I've caught-up now. Just thinking: is "instanceof Cleaner" throwing >>>>>>> OOME as a result of loading the Cleaner class? Wouldn't the above >>>>>>> code then throw some error also in ((Cleaner)r) - the checkcast, >>>>>>> since Cleaner class would not be successfully initialized? >>>>>> >>>>>> Well, no. The above code would just skip Cleaner processing in this >>>>>> situation. And will never be doing it again after the heap is >>>>>> freed... >>>>>> So it might be good to load and initialize Cleaner class as part of >>>>>> ReferenceHandler initialization to ensure correct operation... >>>>> >>>>> Well, yes and no. Let me try once more: >>>>> >>>>> Above code will skip Cleaner processing if the 1st time "instanceof >>>>> Cleaner" is executed, OOME is thrown as a consequence of full heap >>>>> while >>>>> loading and initializing the Cleaner class. >>>> >>>> Yes - I was assuming that this would not fail the very first time and >>>> so the Cleaner class would already be loaded. Failing to be able to >>>> load the Cleaner class was one of the potential issues flagged >>>> earlier with this problem. I was actually assuming that Cleaner would >>>> be loaded already due to some actual Cleaner subclasses being used, >>>> but this does not happen as part of the default initialization. :( >>>> The irony being that if the Cleaner class is not loaded then r can >>>> not be an instance of Cleaner and so we would fail to load the class >>>> in a case where we didn't need it anyway. >>>> >>>> What I wanted to focus on here was an OOME from the instanceof >>>> itself, but as you say that might trigger classloading of Cleaner >>>> (which is not what I was interested in). >>>> >>>>> The 2nd time the "instanceof >>>>> Cleaner" is executed after such OOME, the same line would throw >>>>> NoClassDefFoundError as a consequence of referencing a class that >>>>> failed >>>>> initialization. Am I right? >>>> >>>> instanceof is not one of the class initialization triggers, so we >>>> should not see an OOME generated due to a class initialization >>>> exception and so the class will not be put into the Erroneous state >>>> and so subsequent attempts to use the class will not automatically >>>> trigger NoClassdefFoundError. >>>> >>>> If OOME occurs during actual loading/linking of the class Cleaner it >>>> is unclear what would happen on subsequent attempts. OOME is not a >>>> LinkageError that must be rethrown on subsequent attempts, and it is >>>> potentially a transient condition, so I would expect a re-load >>>> attempt to be allowed. However we are now deep into the details of >>>> the VM and it may well depend on the exact place from which the OOME >>>> originates. >>>> >>>> The bottom line with the current problem is that there are multiple >>>> non-obvious paths by which the ReferenceHandler can encounter an >>>> OOME. In such cases we do not want the ReferenceHandler to terminate >>>> - which implies catching the OOME and continuing. However we also do >>>> not want to silently skip Cleaner processing or reference queue >>>> processing - as that would lead to hard to diagnoze bugs. But trying >>>> to report the problem may not be possible due to being out-of-memory. >>>> It may be that we need to break things up into multiple try/catch >>>> blocks, where each catch does a System.gc() and then reports that the >>>> OOME occurred. Of course the reporting must still be in a try/catch >>>> for the OOME. Though at some point letting the ReferenceHandler die >>>> may be the only way to "report" a major memory problem. >>>> >>>> David >>> >>> Hm... If I give -verbose:class option to run a simple test program: >>> >>> public class Test { public static void main(String... a) {} } >>> >>> I see Cleaner class being loaded before Test class. I don't see by >>> which tread or if it might get loaded after main() starts, but I >>> suspect that loading of Cleaner is not a problem here. Initialization >>> of Cleaner class is not performed by ReferenceHandler thread as you >>> pointed out. The instanceof does not trigger it and if it returns true >>> then Cleaner has already been initialized. So there must be some other >>> cause for instanceof throwing OOME... >>> >>> What do you say about this variant of ReferenceHandler.run() method: >>> >>> public void run() { >>> for (;;) { >>> Reference r; >>> Cleaner c; >>> synchronized (lock) { >>> r = pending; >>> if (r != null) { >>> // instanceof operator might throw OOME >>> sometimes. Just retry after >>> // yielding - might have better luck next >>> time... >>> try { >>> c = r instanceof Cleaner ? (Cleaner) r : >>> null; >>> } catch (OutOfMemoryError x) { >>> Thread.yield(); >>> continue; >>> } >>> pending = r.discovered; >>> r.discovered = null; >>> } else { >>> // The waiting on the lock may cause an OOME >>> because it may try to allocate >>> // exception objects, so also catch OOME here >>> to avoid silent exit of the >>> // reference handler thread. >>> // >>> // Explicitly define the order of the two >>> exceptions we catch here >>> // when waiting for the lock. >>> // >>> // We do not want to try to potentially load >>> the InterruptedException class >>> // (which would be done if this was its first >>> use, and InterruptedException >>> // were checked first) in this situation. >>> // >>> // This may lead to the VM not ever trying to >>> load the InterruptedException >>> // class again. >>> try { >>> try { >>> lock.wait(); >>> } catch (OutOfMemoryError x) { } >>> } catch (InterruptedException x) { } >>> continue; >>> } >>> } >>> >>> // Fast path for cleaners >>> if (c != null) { >>> c.clean(); >>> continue; >>> } >>> >>> ReferenceQueue q = r.queue; >>> if (q != ReferenceQueue.NULL) q.enqueue(r); >>> } >>> } >>> >>> >>> >>> ... it tries to not consume and skip Cleaner instances when OOME is >>> caught. >>> >>> I don't think ReferenceHandler is to make responsible for reporting >>> OOMEs. Full heap is a global condition and ReferenceHandler is the >>> last to accuse for it. >>> >>> Regards, Peter >> >> Hi David, >> >> I think the following variation is even better. It executes >> Thread.yield() after catching OOME but outside synchronized block so >> that given CPU slice can be used by GC threads to make progress >> enqueueing pending References (they are not able to enqueue them while >> ReferenceHandler is holding the lock): >> >> >> public void run() { >> for (;;) { >> Reference r; >> Cleaner c; >> try { >> try { >> synchronized (lock) { >> r = pending; >> if (r != null) { >> // 'instanceof' might throw OOME >> sometimes so do this before >> // unlinking 'r' from the 'pending' >> chain... >> c = r instanceof Cleaner ? (Cleaner) r >> : null; >> // unlink 'r' from 'pending' chain >> pending = r.discovered; >> r.discovered = null; >> } else { >> // The waiting on the lock may cause an >> OOME because it may try to allocate >> // exception objects. >> lock.wait(); >> continue; >> } >> } >> } catch (OutOfMemoryError x) { >> // Catch OOME from 'r instanceof Cleaner' or >> 'lock.wait()' 1st so that we don't >> // try to potentially load the >> InterruptedException class >> // (which would be done if this was its first >> use, and InterruptedException >> // were checked first) in this situation. >> // Give other threads CPU time so they >> hopefully release some objects and GC >> // clears some heap. >> // Also prevent CPU intensive spinning in case >> 'r instanceof Cleaner' above >> // persistently throws OOME for some time... >> Thread.yield(); >> // retry >> continue; >> } >> } catch (InterruptedException x) { >> // Catch InterruptedException from 'lock.wait()' >> and retry >> continue; >> } >> >> // Fast path for cleaners >> if (c != null) { >> c.clean(); >> continue; >> } >> >> ReferenceQueue q = r.queue; >> if (q != ReferenceQueue.NULL) q.enqueue(r); >> } >> } >> >> >> Regards, Peter >> From david.holmes at oracle.com Tue Jan 21 07:57:55 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 Jan 2014 17:57:55 +1000 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52DE19C1.2070302@gmail.com> References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> <52CC72AB.2020104@oracle.com> <52CCEDE0.8000809@oracle.com> <52CCF079.4090301@oracle.com> <52CD45E7.7010203@gmail.com> <52CE4E2D.300@oracle.com> <52CF37C6.1070605@oracle.com> <52CFAFEB.9090703@gmail.com> <52CFD218.2060101@gmail.com> <52D06B70.60001@oracle.com> <52D15201.90109@gmail.com> <52D47D59.8040905@oracle.com> <52D72577.1050506@oracle.com> <52D76859.2030502@oracle.com> <52D82968.4030608@oracle.com> <52D8929B.2020905@oracle.com> <52D8A42A.4020906@oracle.com> <52D8B3B6.3030202@oracle.com> <52D9295D.6080106@gmail.com> <52D92C73.2020309@gmail.com> <52D92F1A.4040400@gmail.com> <52DC812C.1000607@oracle.com> <52DCD78E.8050404@gmail.com> <52DCE17B.4050708@gmail.com> <52DDD9F3.1050201@oracle.com> <52DE19C1.2070302@gmail.com> Message-ID: <52DE2883.5010100@oracle.com> On 21/01/2014 4:54 PM, Peter Levart wrote: > > On 01/21/2014 03:22 AM, David Holmes wrote: >> Hi Peter, >> >> I do not see Cleaner being loaded prior to the main class on either >> Windows or Linux. Which platform are you on? Did you see it loaded >> before the main class or as part of executing it? > > Before. The main class is empty: > > public class Test { public static void main(String... a) {} } > > Here's last few lines of -verbose:class: > > [Loaded java.util.TimeZone from > /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] > [Loaded sun.util.calendar.ZoneInfo from > /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] > [Loaded sun.util.calendar.ZoneInfoFile from > /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] > [Loaded sun.util.calendar.ZoneInfoFile$1 from > /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] > [Loaded java.io.DataInput from > /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] > [Loaded java.io.DataInputStream from > /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] > *[Loaded sun.misc.Cleaner from > /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar]* Curious. I wonder what the controlling factor is ?? > > I'm on linux, 64bit and using official EA build 121 of JDK 8... > > But if I try with JDK 7u45, I don't see it. So perhaps it would be good > to trigger Cleaner loading and initialization as part of > ReferenceHandler initialization to play things safe. If we do that for Cleaner we may as well do it for InterruptedException too. >> Also, it is not that I think ReferenceHandler is responsible for >> reporting OOME, but that it is responsible for reporting that it was >> unable to perform a clean or enqueue because of OOME. > > This would be necessary if we skipped a Reference because of OOME, but > if we just re-try until we eventually succeed, nothing is lost, nothing > to report (but a slow response)... Agreed - just trying to clarify things. >> >> Your suggested approach seems okay though I'm not sure why we >> shouldn't help things along by calling System.gc() ourselves rather >> than just yielding and hoping things will get cleaned up elsewhere. >> But for the present purposes your approach will suffice I think. > > Maybe my understanding is wrong but isn't the fact that OOME is rised a > consequence of that VM has already attempted to clear things up > (executing a GC round synchronously) but didn't succeed to make enough > free space to satisfy the allocation request? If this is only how some > collectors/allocators are implemented and not a general rule, then we > should put a System.gc() in place of Thread.yield(). Should we also > combine that with Thread.yield()? I'm concerned of a possibility that we > spin, consume too much CPU (ReferenceHandler thread has MAX priority) so > that other threads dont' get enough CPU time to proceed and clean things > up (we hope other threads will also get OOME and release things as their > stacks unwind...). You are probably right about the System.gc() - OOME should be thrown after GC fails to create space, so it really needs some other thread to drop live references to allow further space to be reclaimed. But note that Thread.yield() can behave badly on some linux systems too, so spinning is still a possibility - but either way this would only be "really bad" on a uniprocessor system where yield() is unlikely to misbehave. David ----- > > Regards, Peter > >> >> Thanks, >> David >> >> On 20/01/2014 6:42 PM, Peter Levart wrote: >>> On 01/20/2014 09:00 AM, Peter Levart wrote: >>>> On 01/20/2014 02:51 AM, David Holmes wrote: >>>>> Hi Peter, >>>>> >>>>> On 17/01/2014 11:24 PM, Peter Levart wrote: >>>>>> On 01/17/2014 02:13 PM, Peter Levart wrote: >>>>>>>>> // Fast path for cleaners >>>>>>>>> boolean isCleaner = false; >>>>>>>>> try { >>>>>>>>> isCleaner = r instanceof Cleaner; >>>>>>>>> } catch (OutofMemoryError oome) { >>>>>>>>> continue; >>>>>>>>> } >>>>>>>>> >>>>>>>>> if (isCleaner) { >>>>>>>>> ((Cleaner)r).clean(); >>>>>>>>> continue; >>>>>>>>> } >>>>>>>>> >>>>>>>> >>>>>>>> Hi David, Kalyan, >>>>>>>> >>>>>>>> I've caught-up now. Just thinking: is "instanceof Cleaner" throwing >>>>>>>> OOME as a result of loading the Cleaner class? Wouldn't the above >>>>>>>> code then throw some error also in ((Cleaner)r) - the checkcast, >>>>>>>> since Cleaner class would not be successfully initialized? >>>>>>> >>>>>>> Well, no. The above code would just skip Cleaner processing in this >>>>>>> situation. And will never be doing it again after the heap is >>>>>>> freed... >>>>>>> So it might be good to load and initialize Cleaner class as part of >>>>>>> ReferenceHandler initialization to ensure correct operation... >>>>>> >>>>>> Well, yes and no. Let me try once more: >>>>>> >>>>>> Above code will skip Cleaner processing if the 1st time "instanceof >>>>>> Cleaner" is executed, OOME is thrown as a consequence of full heap >>>>>> while >>>>>> loading and initializing the Cleaner class. >>>>> >>>>> Yes - I was assuming that this would not fail the very first time and >>>>> so the Cleaner class would already be loaded. Failing to be able to >>>>> load the Cleaner class was one of the potential issues flagged >>>>> earlier with this problem. I was actually assuming that Cleaner would >>>>> be loaded already due to some actual Cleaner subclasses being used, >>>>> but this does not happen as part of the default initialization. :( >>>>> The irony being that if the Cleaner class is not loaded then r can >>>>> not be an instance of Cleaner and so we would fail to load the class >>>>> in a case where we didn't need it anyway. >>>>> >>>>> What I wanted to focus on here was an OOME from the instanceof >>>>> itself, but as you say that might trigger classloading of Cleaner >>>>> (which is not what I was interested in). >>>>> >>>>>> The 2nd time the "instanceof >>>>>> Cleaner" is executed after such OOME, the same line would throw >>>>>> NoClassDefFoundError as a consequence of referencing a class that >>>>>> failed >>>>>> initialization. Am I right? >>>>> >>>>> instanceof is not one of the class initialization triggers, so we >>>>> should not see an OOME generated due to a class initialization >>>>> exception and so the class will not be put into the Erroneous state >>>>> and so subsequent attempts to use the class will not automatically >>>>> trigger NoClassdefFoundError. >>>>> >>>>> If OOME occurs during actual loading/linking of the class Cleaner it >>>>> is unclear what would happen on subsequent attempts. OOME is not a >>>>> LinkageError that must be rethrown on subsequent attempts, and it is >>>>> potentially a transient condition, so I would expect a re-load >>>>> attempt to be allowed. However we are now deep into the details of >>>>> the VM and it may well depend on the exact place from which the OOME >>>>> originates. >>>>> >>>>> The bottom line with the current problem is that there are multiple >>>>> non-obvious paths by which the ReferenceHandler can encounter an >>>>> OOME. In such cases we do not want the ReferenceHandler to terminate >>>>> - which implies catching the OOME and continuing. However we also do >>>>> not want to silently skip Cleaner processing or reference queue >>>>> processing - as that would lead to hard to diagnoze bugs. But trying >>>>> to report the problem may not be possible due to being out-of-memory. >>>>> It may be that we need to break things up into multiple try/catch >>>>> blocks, where each catch does a System.gc() and then reports that the >>>>> OOME occurred. Of course the reporting must still be in a try/catch >>>>> for the OOME. Though at some point letting the ReferenceHandler die >>>>> may be the only way to "report" a major memory problem. >>>>> >>>>> David >>>> >>>> Hm... If I give -verbose:class option to run a simple test program: >>>> >>>> public class Test { public static void main(String... a) {} } >>>> >>>> I see Cleaner class being loaded before Test class. I don't see by >>>> which tread or if it might get loaded after main() starts, but I >>>> suspect that loading of Cleaner is not a problem here. Initialization >>>> of Cleaner class is not performed by ReferenceHandler thread as you >>>> pointed out. The instanceof does not trigger it and if it returns true >>>> then Cleaner has already been initialized. So there must be some other >>>> cause for instanceof throwing OOME... >>>> >>>> What do you say about this variant of ReferenceHandler.run() method: >>>> >>>> public void run() { >>>> for (;;) { >>>> Reference r; >>>> Cleaner c; >>>> synchronized (lock) { >>>> r = pending; >>>> if (r != null) { >>>> // instanceof operator might throw OOME >>>> sometimes. Just retry after >>>> // yielding - might have better luck next >>>> time... >>>> try { >>>> c = r instanceof Cleaner ? (Cleaner) r : >>>> null; >>>> } catch (OutOfMemoryError x) { >>>> Thread.yield(); >>>> continue; >>>> } >>>> pending = r.discovered; >>>> r.discovered = null; >>>> } else { >>>> // The waiting on the lock may cause an OOME >>>> because it may try to allocate >>>> // exception objects, so also catch OOME here >>>> to avoid silent exit of the >>>> // reference handler thread. >>>> // >>>> // Explicitly define the order of the two >>>> exceptions we catch here >>>> // when waiting for the lock. >>>> // >>>> // We do not want to try to potentially load >>>> the InterruptedException class >>>> // (which would be done if this was its first >>>> use, and InterruptedException >>>> // were checked first) in this situation. >>>> // >>>> // This may lead to the VM not ever trying to >>>> load the InterruptedException >>>> // class again. >>>> try { >>>> try { >>>> lock.wait(); >>>> } catch (OutOfMemoryError x) { } >>>> } catch (InterruptedException x) { } >>>> continue; >>>> } >>>> } >>>> >>>> // Fast path for cleaners >>>> if (c != null) { >>>> c.clean(); >>>> continue; >>>> } >>>> >>>> ReferenceQueue q = r.queue; >>>> if (q != ReferenceQueue.NULL) q.enqueue(r); >>>> } >>>> } >>>> >>>> >>>> >>>> ... it tries to not consume and skip Cleaner instances when OOME is >>>> caught. >>>> >>>> I don't think ReferenceHandler is to make responsible for reporting >>>> OOMEs. Full heap is a global condition and ReferenceHandler is the >>>> last to accuse for it. >>>> >>>> Regards, Peter >>> >>> Hi David, >>> >>> I think the following variation is even better. It executes >>> Thread.yield() after catching OOME but outside synchronized block so >>> that given CPU slice can be used by GC threads to make progress >>> enqueueing pending References (they are not able to enqueue them while >>> ReferenceHandler is holding the lock): >>> >>> >>> public void run() { >>> for (;;) { >>> Reference r; >>> Cleaner c; >>> try { >>> try { >>> synchronized (lock) { >>> r = pending; >>> if (r != null) { >>> // 'instanceof' might throw OOME >>> sometimes so do this before >>> // unlinking 'r' from the 'pending' >>> chain... >>> c = r instanceof Cleaner ? (Cleaner) r >>> : null; >>> // unlink 'r' from 'pending' chain >>> pending = r.discovered; >>> r.discovered = null; >>> } else { >>> // The waiting on the lock may cause an >>> OOME because it may try to allocate >>> // exception objects. >>> lock.wait(); >>> continue; >>> } >>> } >>> } catch (OutOfMemoryError x) { >>> // Catch OOME from 'r instanceof Cleaner' or >>> 'lock.wait()' 1st so that we don't >>> // try to potentially load the >>> InterruptedException class >>> // (which would be done if this was its first >>> use, and InterruptedException >>> // were checked first) in this situation. >>> // Give other threads CPU time so they >>> hopefully release some objects and GC >>> // clears some heap. >>> // Also prevent CPU intensive spinning in case >>> 'r instanceof Cleaner' above >>> // persistently throws OOME for some time... >>> Thread.yield(); >>> // retry >>> continue; >>> } >>> } catch (InterruptedException x) { >>> // Catch InterruptedException from 'lock.wait()' >>> and retry >>> continue; >>> } >>> >>> // Fast path for cleaners >>> if (c != null) { >>> c.clean(); >>> continue; >>> } >>> >>> ReferenceQueue q = r.queue; >>> if (q != ReferenceQueue.NULL) q.enqueue(r); >>> } >>> } >>> >>> >>> Regards, Peter >>> > From paul.sandoz at oracle.com Tue Jan 21 09:46:53 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 21 Jan 2014 10:46:53 +0100 Subject: RFR: 8032190 It's unclear that flatMap will ensure each stream will be closed. In-Reply-To: <52DDA028.8090006@oracle.com> References: <2A77FAFB-7F05-41AE-A73D-1C1B1E2D703C@oracle.com> <52DDA028.8090006@oracle.com> Message-ID: On Jan 20, 2014, at 11:16 PM, Alan Bateman wrote: > On 20/01/2014 10:38, Paul Sandoz wrote: >> Hi, >> >> For the flatMap operations of streams we forgot to say what it does with the mapped streams after it has processed them i.e. closes them, which is important for I/O backed streams (e.g. map Path -> Stream for lines of a file). The following patch fixes that omission in the docs: >> >> https://bugs.openjdk.java.net/browse/JDK-8032190 >> >> I think this should be backported to 8. >> >> Paul. > This is important to add. A minor comment is to just link "closed" to BaseStream#close rather than adding "see ...". > Good idea, i updated to do that. Paul. From aleksej.efimov at oracle.com Tue Jan 21 13:17:50 2014 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Tue, 21 Jan 2014 17:17:50 +0400 Subject: RFR: 8030822: (tz) Support tzdata2013i Message-ID: <52DE737E.2030200@oracle.com> Hi, Can I have a review for 2013i timezone data integration [1] to JDK9. There is one change in tzdb that affects naming for "Asia/Amman" timezone: "The Jordan switches back to standard time at 00:00 on December 20, 2013." All changes in TimeZoneNames*.java and TimeZoneNames*.properties files are related to this one tzdb change. The list of executed regression test sets: test/sun/util/calendar test/java/util/Calendar test/sun/util/resources/TimeZone test/sun/util/calendar test/java/util/TimeZone test/java/time test/java/util/Formatter test/closed/java/util/Calendar test/closed/java/util/TimeZone All tests gave PASS result. Webrev location: http://cr.openjdk.java.net/~aefimov/8030822/9/webrev.00/ Thank you, Aleksej [1] https://bugs.openjdk.java.net/browse/JDK-8030822 From peter.levart at gmail.com Tue Jan 21 14:00:26 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 21 Jan 2014 15:00:26 +0100 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52DE2883.5010100@oracle.com> References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> <52CC72AB.2020104@oracle.com> <52CCEDE0.8000809@oracle.com> <52CCF079.4090301@oracle.com> <52CD45E7.7010203@gmail.com> <52CE4E2D.300@oracle.com> <52CF37C6.1070605@oracle.com> <52CFAFEB.9090703@gmail.com> <52CFD218.2060101@gmail.com> <52D06B70.60001@oracle.com> <52D15201.90109@gmail.com> <52D47D59.8040905@oracle.com> <52D72577.1050506@oracle.com> <52D76859.2030502@oracle.com> <52D82968.4030608@oracle.com> <52D8929B.2020905@oracle.com> <52D8A42A.4020906@oracle.com> <52D8B3B6.3030202@oracle.com> <52D9295D.6080106@gmail.com> <52D92C73.2020309@gmail.com> <52D92F1A.4040400@gmail.com> <52DC812C.1000607@oracle.com> <52DCD78E.8050404@gmail.com> <52DCE17B.4050708@gmail.com> <52DDD9F3.1050201@oracle.com> <52DE19C1.2070302@gmail.com> <52DE2883.5010100@oracle.com> Message-ID: <52DE7D7A.80501@gmail.com> Hi, David, Kalyan, Summing up the discussion, I propose the following patch for ReferenceHandler: http://cr.openjdk.java.net/~plevart/jdk9-dev/OOMEInReferenceHandler/webrev.01/ all 10 java/lang/ref tests pass on my PC (including OOMEInReferenceHandler). I kindly ask Kalyan to try to re-run the OOMEInReferenceHandler test with this code and report any failure. Thanks, Peter On 01/21/2014 08:57 AM, David Holmes wrote: > On 21/01/2014 4:54 PM, Peter Levart wrote: >> >> On 01/21/2014 03:22 AM, David Holmes wrote: >>> Hi Peter, >>> >>> I do not see Cleaner being loaded prior to the main class on either >>> Windows or Linux. Which platform are you on? Did you see it loaded >>> before the main class or as part of executing it? >> >> Before. The main class is empty: >> >> public class Test { public static void main(String... a) {} } >> >> Here's last few lines of -verbose:class: >> >> [Loaded java.util.TimeZone from >> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >> [Loaded sun.util.calendar.ZoneInfo from >> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >> [Loaded sun.util.calendar.ZoneInfoFile from >> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >> [Loaded sun.util.calendar.ZoneInfoFile$1 from >> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >> [Loaded java.io.DataInput from >> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >> [Loaded java.io.DataInputStream from >> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >> *[Loaded sun.misc.Cleaner from >> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar]* > > Curious. I wonder what the controlling factor is ?? > >> >> I'm on linux, 64bit and using official EA build 121 of JDK 8... >> >> But if I try with JDK 7u45, I don't see it. So perhaps it would be good >> to trigger Cleaner loading and initialization as part of >> ReferenceHandler initialization to play things safe. > > > If we do that for Cleaner we may as well do it for > InterruptedException too. > >>> Also, it is not that I think ReferenceHandler is responsible for >>> reporting OOME, but that it is responsible for reporting that it was >>> unable to perform a clean or enqueue because of OOME. >> >> This would be necessary if we skipped a Reference because of OOME, but >> if we just re-try until we eventually succeed, nothing is lost, nothing >> to report (but a slow response)... > > Agreed - just trying to clarify things. > >>> >>> Your suggested approach seems okay though I'm not sure why we >>> shouldn't help things along by calling System.gc() ourselves rather >>> than just yielding and hoping things will get cleaned up elsewhere. >>> But for the present purposes your approach will suffice I think. >> >> Maybe my understanding is wrong but isn't the fact that OOME is rised a >> consequence of that VM has already attempted to clear things up >> (executing a GC round synchronously) but didn't succeed to make enough >> free space to satisfy the allocation request? If this is only how some >> collectors/allocators are implemented and not a general rule, then we >> should put a System.gc() in place of Thread.yield(). Should we also >> combine that with Thread.yield()? I'm concerned of a possibility that we >> spin, consume too much CPU (ReferenceHandler thread has MAX priority) so >> that other threads dont' get enough CPU time to proceed and clean things >> up (we hope other threads will also get OOME and release things as their >> stacks unwind...). > > You are probably right about the System.gc() - OOME should be thrown > after GC fails to create space, so it really needs some other thread > to drop live references to allow further space to be reclaimed. > > But note that Thread.yield() can behave badly on some linux systems > too, so spinning is still a possibility - but either way this would > only be "really bad" on a uniprocessor system where yield() is > unlikely to misbehave. > > David > ----- > >> >> Regards, Peter >> >>> >>> Thanks, >>> David >>> >>> On 20/01/2014 6:42 PM, Peter Levart wrote: >>>> On 01/20/2014 09:00 AM, Peter Levart wrote: >>>>> On 01/20/2014 02:51 AM, David Holmes wrote: >>>>>> Hi Peter, >>>>>> >>>>>> On 17/01/2014 11:24 PM, Peter Levart wrote: >>>>>>> On 01/17/2014 02:13 PM, Peter Levart wrote: >>>>>>>>>> // Fast path for cleaners >>>>>>>>>> boolean isCleaner = false; >>>>>>>>>> try { >>>>>>>>>> isCleaner = r instanceof Cleaner; >>>>>>>>>> } catch (OutofMemoryError oome) { >>>>>>>>>> continue; >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> if (isCleaner) { >>>>>>>>>> ((Cleaner)r).clean(); >>>>>>>>>> continue; >>>>>>>>>> } >>>>>>>>>> >>>>>>>>> >>>>>>>>> Hi David, Kalyan, >>>>>>>>> >>>>>>>>> I've caught-up now. Just thinking: is "instanceof Cleaner" >>>>>>>>> throwing >>>>>>>>> OOME as a result of loading the Cleaner class? Wouldn't the above >>>>>>>>> code then throw some error also in ((Cleaner)r) - the checkcast, >>>>>>>>> since Cleaner class would not be successfully initialized? >>>>>>>> >>>>>>>> Well, no. The above code would just skip Cleaner processing in >>>>>>>> this >>>>>>>> situation. And will never be doing it again after the heap is >>>>>>>> freed... >>>>>>>> So it might be good to load and initialize Cleaner class as >>>>>>>> part of >>>>>>>> ReferenceHandler initialization to ensure correct operation... >>>>>>> >>>>>>> Well, yes and no. Let me try once more: >>>>>>> >>>>>>> Above code will skip Cleaner processing if the 1st time "instanceof >>>>>>> Cleaner" is executed, OOME is thrown as a consequence of full heap >>>>>>> while >>>>>>> loading and initializing the Cleaner class. >>>>>> >>>>>> Yes - I was assuming that this would not fail the very first time >>>>>> and >>>>>> so the Cleaner class would already be loaded. Failing to be able to >>>>>> load the Cleaner class was one of the potential issues flagged >>>>>> earlier with this problem. I was actually assuming that Cleaner >>>>>> would >>>>>> be loaded already due to some actual Cleaner subclasses being used, >>>>>> but this does not happen as part of the default initialization. :( >>>>>> The irony being that if the Cleaner class is not loaded then r can >>>>>> not be an instance of Cleaner and so we would fail to load the class >>>>>> in a case where we didn't need it anyway. >>>>>> >>>>>> What I wanted to focus on here was an OOME from the instanceof >>>>>> itself, but as you say that might trigger classloading of Cleaner >>>>>> (which is not what I was interested in). >>>>>> >>>>>>> The 2nd time the "instanceof >>>>>>> Cleaner" is executed after such OOME, the same line would throw >>>>>>> NoClassDefFoundError as a consequence of referencing a class that >>>>>>> failed >>>>>>> initialization. Am I right? >>>>>> >>>>>> instanceof is not one of the class initialization triggers, so we >>>>>> should not see an OOME generated due to a class initialization >>>>>> exception and so the class will not be put into the Erroneous state >>>>>> and so subsequent attempts to use the class will not automatically >>>>>> trigger NoClassdefFoundError. >>>>>> >>>>>> If OOME occurs during actual loading/linking of the class Cleaner it >>>>>> is unclear what would happen on subsequent attempts. OOME is not a >>>>>> LinkageError that must be rethrown on subsequent attempts, and it is >>>>>> potentially a transient condition, so I would expect a re-load >>>>>> attempt to be allowed. However we are now deep into the details of >>>>>> the VM and it may well depend on the exact place from which the OOME >>>>>> originates. >>>>>> >>>>>> The bottom line with the current problem is that there are multiple >>>>>> non-obvious paths by which the ReferenceHandler can encounter an >>>>>> OOME. In such cases we do not want the ReferenceHandler to terminate >>>>>> - which implies catching the OOME and continuing. However we also do >>>>>> not want to silently skip Cleaner processing or reference queue >>>>>> processing - as that would lead to hard to diagnoze bugs. But trying >>>>>> to report the problem may not be possible due to being >>>>>> out-of-memory. >>>>>> It may be that we need to break things up into multiple try/catch >>>>>> blocks, where each catch does a System.gc() and then reports that >>>>>> the >>>>>> OOME occurred. Of course the reporting must still be in a try/catch >>>>>> for the OOME. Though at some point letting the ReferenceHandler die >>>>>> may be the only way to "report" a major memory problem. >>>>>> >>>>>> David >>>>> >>>>> Hm... If I give -verbose:class option to run a simple test program: >>>>> >>>>> public class Test { public static void main(String... a) {} } >>>>> >>>>> I see Cleaner class being loaded before Test class. I don't see by >>>>> which tread or if it might get loaded after main() starts, but I >>>>> suspect that loading of Cleaner is not a problem here. Initialization >>>>> of Cleaner class is not performed by ReferenceHandler thread as you >>>>> pointed out. The instanceof does not trigger it and if it returns >>>>> true >>>>> then Cleaner has already been initialized. So there must be some >>>>> other >>>>> cause for instanceof throwing OOME... >>>>> >>>>> What do you say about this variant of ReferenceHandler.run() method: >>>>> >>>>> public void run() { >>>>> for (;;) { >>>>> Reference r; >>>>> Cleaner c; >>>>> synchronized (lock) { >>>>> r = pending; >>>>> if (r != null) { >>>>> // instanceof operator might throw OOME >>>>> sometimes. Just retry after >>>>> // yielding - might have better luck next >>>>> time... >>>>> try { >>>>> c = r instanceof Cleaner ? (Cleaner) r : >>>>> null; >>>>> } catch (OutOfMemoryError x) { >>>>> Thread.yield(); >>>>> continue; >>>>> } >>>>> pending = r.discovered; >>>>> r.discovered = null; >>>>> } else { >>>>> // The waiting on the lock may cause an OOME >>>>> because it may try to allocate >>>>> // exception objects, so also catch OOME here >>>>> to avoid silent exit of the >>>>> // reference handler thread. >>>>> // >>>>> // Explicitly define the order of the two >>>>> exceptions we catch here >>>>> // when waiting for the lock. >>>>> // >>>>> // We do not want to try to potentially load >>>>> the InterruptedException class >>>>> // (which would be done if this was its first >>>>> use, and InterruptedException >>>>> // were checked first) in this situation. >>>>> // >>>>> // This may lead to the VM not ever trying to >>>>> load the InterruptedException >>>>> // class again. >>>>> try { >>>>> try { >>>>> lock.wait(); >>>>> } catch (OutOfMemoryError x) { } >>>>> } catch (InterruptedException x) { } >>>>> continue; >>>>> } >>>>> } >>>>> >>>>> // Fast path for cleaners >>>>> if (c != null) { >>>>> c.clean(); >>>>> continue; >>>>> } >>>>> >>>>> ReferenceQueue q = r.queue; >>>>> if (q != ReferenceQueue.NULL) q.enqueue(r); >>>>> } >>>>> } >>>>> >>>>> >>>>> >>>>> ... it tries to not consume and skip Cleaner instances when OOME is >>>>> caught. >>>>> >>>>> I don't think ReferenceHandler is to make responsible for reporting >>>>> OOMEs. Full heap is a global condition and ReferenceHandler is the >>>>> last to accuse for it. >>>>> >>>>> Regards, Peter >>>> >>>> Hi David, >>>> >>>> I think the following variation is even better. It executes >>>> Thread.yield() after catching OOME but outside synchronized block so >>>> that given CPU slice can be used by GC threads to make progress >>>> enqueueing pending References (they are not able to enqueue them while >>>> ReferenceHandler is holding the lock): >>>> >>>> >>>> public void run() { >>>> for (;;) { >>>> Reference r; >>>> Cleaner c; >>>> try { >>>> try { >>>> synchronized (lock) { >>>> r = pending; >>>> if (r != null) { >>>> // 'instanceof' might throw OOME >>>> sometimes so do this before >>>> // unlinking 'r' from the 'pending' >>>> chain... >>>> c = r instanceof Cleaner ? >>>> (Cleaner) r >>>> : null; >>>> // unlink 'r' from 'pending' chain >>>> pending = r.discovered; >>>> r.discovered = null; >>>> } else { >>>> // The waiting on the lock may >>>> cause an >>>> OOME because it may try to allocate >>>> // exception objects. >>>> lock.wait(); >>>> continue; >>>> } >>>> } >>>> } catch (OutOfMemoryError x) { >>>> // Catch OOME from 'r instanceof Cleaner' or >>>> 'lock.wait()' 1st so that we don't >>>> // try to potentially load the >>>> InterruptedException class >>>> // (which would be done if this was its first >>>> use, and InterruptedException >>>> // were checked first) in this situation. >>>> // Give other threads CPU time so they >>>> hopefully release some objects and GC >>>> // clears some heap. >>>> // Also prevent CPU intensive spinning in >>>> case >>>> 'r instanceof Cleaner' above >>>> // persistently throws OOME for some time... >>>> Thread.yield(); >>>> // retry >>>> continue; >>>> } >>>> } catch (InterruptedException x) { >>>> // Catch InterruptedException from 'lock.wait()' >>>> and retry >>>> continue; >>>> } >>>> >>>> // Fast path for cleaners >>>> if (c != null) { >>>> c.clean(); >>>> continue; >>>> } >>>> >>>> ReferenceQueue q = r.queue; >>>> if (q != ReferenceQueue.NULL) q.enqueue(r); >>>> } >>>> } >>>> >>>> >>>> Regards, Peter >>>> >> From peter.levart at gmail.com Tue Jan 21 15:19:44 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 21 Jan 2014 16:19:44 +0100 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52DE2883.5010100@oracle.com> References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> <52CC72AB.2020104@oracle.com> <52CCEDE0.8000809@oracle.com> <52CCF079.4090301@oracle.com> <52CD45E7.7010203@gmail.com> <52CE4E2D.300@oracle.com> <52CF37C6.1070605@oracle.com> <52CFAFEB.9090703@gmail.com> <52CFD218.2060101@gmail.com> <52D06B70.60001@oracle.com> <52D15201.90109@gmail.com> <52D47D59.8040905@oracle.com> <52D72577.1050506@oracle.com> <52D76859.2030502@oracle.com> <52D82968.4030608@oracle.com> <52D8929B.2020905@oracle.com> <52D8A42A.4020906@oracle.com> <52D8B3B6.3030202@oracle.com> <52D9295D.6080106@gmail.com> <52D92C73.2020309@gmail.com> <52D92F1A.4040400@gmail.com> <52DC812C.1000607@oracle.com> <52DCD78E.8050404@gmail.com> <52DCE17B.4050708@gmail.com> <52DDD9F3.1050201@oracle.com> <52DE19C1.2070302@gmail.com> <52DE2883.5010100@oracle.com> Message-ID: <52DE9010.30700@gmail.com> On 01/21/2014 08:57 AM, David Holmes wrote: >> [Loaded java.util.TimeZone from >> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >> [Loaded sun.util.calendar.ZoneInfo from >> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >> [Loaded sun.util.calendar.ZoneInfoFile from >> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >> [Loaded sun.util.calendar.ZoneInfoFile$1 from >> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >> [Loaded java.io.DataInput from >> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >> [Loaded java.io.DataInputStream from >> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >> *[Loaded sun.misc.Cleaner from >> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar]* > > Curious. I wonder what the controlling factor is ?? The Cleaner is usually loaded by ReferenceHandler in JDK8 in the 1st execution of it's loop. It looks like JDK8 system initialization produces at least one XXXReference that is cleared before main() method is entered (debugging, I found it's a Finalizer for a FileInputStream - perhaps of the stream that loads the TimeZone data), so ReferenceHandler thread is woken-up, executes the instanceof Cleaner check and this loads the class. I put the following printfs in an original ReferenceHandler: System.out.println("Before using Cleaner..."); // Fast path for cleaners if (r instanceof Cleaner) { ((Cleaner)r).clean(); continue; } System.out.println("After using Cleaner..."); ...and the empty main() test with -verbose:class prints: ... [Loaded java.io.DataInput from /home/peter/work/hg/jdk8-tl/build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/rt.jar] [Loaded java.io.DataInputStream from /home/peter/work/hg/jdk8-tl/build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/rt.jar] *Before using Cleaner...** **[Loaded sun.misc.Cleaner from out/production/jdk]** **After using Cleaner...* [Loaded java.io.ByteArrayInputStream from /home/peter/work/hg/jdk8-tl/build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/rt.jar] [Loaded sun.util.calendar.ZoneInfoFile$ZoneOffsetTransitionRule from /home/peter/work/hg/jdk8-tl/build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/rt.jar] ... But sometimes, It seems, the VM is not so quick in clearing the early XXXReferences and/or the ReferenceHandler start-up is delayed and the 1st iteration of the loop is executed after the OOMEInReferenceHandler test already fills the heap and consequently loading of Cleaner class throws OOME in instanceof check... My proposed fix is very aggressive. It pre-loads classes, initializes them and watches for OOMEs thrown in all ocasions. It might be that pre-loading Cleaner class in ReferenceHandler initialization would be sufficient to fix this intermittent failure. Or do you think instanceof check could throw OOME for some other reason besides loading of the class? Regards, Peter From peter.levart at gmail.com Tue Jan 21 15:24:55 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 21 Jan 2014 16:24:55 +0100 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52DE19C1.2070302@gmail.com> References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> <52CC72AB.2020104@oracle.com> <52CCEDE0.8000809@oracle.com> <52CCF079.4090301@oracle.com> <52CD45E7.7010203@gmail.com> <52CE4E2D.300@oracle.com> <52CF37C6.1070605@oracle.com> <52CFAFEB.9090703@gmail.com> <52CFD218.2060101@gmail.com> <52D06B70.60001@oracle.com> <52D15201.90109@gmail.com> <52D47D59.8040905@oracle.com> <52D72577.1050506@oracle.com> <52D76859.2030502@oracle.com> <52D82968.4030608@oracle.com> <52D8929B.2020905@oracle.com> <52D8A42A.4020906@oracle.com> <52D8B3B6.3030202@oracle.com> <52D9295D.6080106@gmail.com> <52D92C73.2020309@gmail.com> <52D92F1A.4040400@gmail.com> <52DC812C.1000607@oracle.com> <52DCD78E.8050404@gmail.com> <52DCE17B.4050708@gmail.com> <52DDD9F3.1050201@oracle.com> <52DE19C1.2070302@gmail.com> Message-ID: <52DE9147.4030305@gmail.com> On 01/21/2014 07:54 AM, Peter Levart wrote: > *[Loaded sun.misc.Cleaner from > /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar]* > [Loaded java.io.ByteArrayInputStream from > /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] > [Loaded sun.util.calendar.ZoneInfoFile$ZoneOffsetTransitionRule from > /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] > ... > > > I'm on linux, 64bit and using official EA build 121 of JDK 8... > > But if I try with JDK 7u45, I don't see it. So what changed between JDK 7 and JDK 8? I suspect the following: 8007572: Replace existing jdk timezone data at /lib/zi with JSR310's tzdb Regards, Peter From kumar.x.srinivasan at oracle.com Tue Jan 21 16:11:19 2014 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 21 Jan 2014 08:11:19 -0800 Subject: JDK9 RFR of JDK-8029646: [pack200] should support the new zip64 format. In-Reply-To: <52D8070A.8030804@oracle.com> References: <52D57C2A.4010906@oracle.com> <52D61589.1090901@oracle.com> <52D69A9A.1010506@oracle.com> <52D69C5E.9020407@oracle.com> <52D6A2C1.2000802@oracle.com> <52D6C6B0.3020508@oracle.com> <52D8070A.8030804@oracle.com> Message-ID: <52DE9C27.7020106@oracle.com> Alex, Thanks for adding the test, few comments: PackTestZip64.java: 1. compareTwoFile, I would read the entire file into ByteArrayInputStream, compare the total first ie. fast fail, but what you have is also ok. 2. generateLargeJar: I would replace lines 126,127 and 128 using for-each loop, by using Collections.list e); will make it more compact. Though you are usign Try-With-Resources on the input jar, how about 3. Though the test might not take too long on your system, I am concerned it may take too long on our Jprt system. Otherwise looks good. Kumar On 1/16/2014 8:21 AM, Alexander Zuev wrote: > Sherman, Kumar, > > i have fixed the glitches you have found and changed the test so it > creates a new jar > based on the golden.jar content (to have a reasonable set of various > data to start with), > then adding to it 65536 empty files to test how we cope with such a > huge jars. > > The testing time is less than a 30 seconds on my machine (not the > top-of-the-line) so i > decided not to bother with conditional testing, lets test our behavior > every time in full. > > The updated webrev can be found at > http://cr.openjdk.java.net/~kizune/8029646/webrev.02 > > /Alex > > On 1/15/14 21:34, Xueming Shen wrote: >> On 1/15/14 7:01 AM, Alexander Zuev wrote: >>> Hello, >>> >>> the new webrev with all the typos and comments fixed can be found >>> at http://cr.openjdk.java.net/~kizune/8029646/webrev.01/ >>> >>> /Alex >> >> (1) jarmagic can be just a static constant somewhere or a stack >> variable. not big deal though. >> (2) the test only "tests" EOF for s. there is possibility that the >> newly created has more extra >> bytes at the end...though in theory this should not happen, it >> might be better just add an >> extra line to check the sizes of two first first? >> (3) the rest of the change looks good, but I agreed with Kumar that >> you may need to add a >> regression test for a jar file with > 64k entries. otherwise >> the code for zip64 end is not >> being tested. the code looks fine, but I would trust a >> regression test more than my eyes:-) >> >> Thanks! >> -Sherman > From martinrb at google.com Tue Jan 21 16:35:39 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 21 Jan 2014 08:35:39 -0800 Subject: RFR [8027348] (process) Enhancement of handling async close of ProcessInputStream In-Reply-To: <52DD3863.8050405@oracle.com> References: <528BCD2E.5090209@oracle.com> <52DD3863.8050405@oracle.com> Message-ID: Approved for jdk9! On Mon, Jan 20, 2014 at 6:53 AM, Ivan Gerasimov wrote: > Hello everybody! > > Can I consider this change approved for jdk9? > > Thanks in advance, > Ivan Gerasimov > > > On 20.11.2013 0:56, Martin Buchholz wrote: > > Ivan, > Thanks for taking ownership of my proposed change. Looks good to me! > > (I can't actually push changes like this myself because I only do Linux > these days) > > > On Tue, Nov 19, 2013 at 12:42 PM, Ivan Gerasimov < > ivan.gerasimov at oracle.com> wrote: > >> Hello all! >> >> May I have a review for the improvement contributed by Martin Buchholz? >> https://bugs.openjdk.java.net/browse/JDK-8027348 >> >> First, it the change performs the code cleanup, and second it makes the >> test much faster. >> This should also help to resolve the issue with the current version of >> the test, which was reported to fail intermittently by timeout. >> https://bugs.openjdk.java.net/browse/JDK-8028574 >> >> Here's the webrev with the change: >> http://cr.openjdk.java.net/~igerasim/8027348/0/webrev/ >> >> Sincerely yours, >> Ivan Gerasimov >> >> > > From srikalyan.chandrashekar at oracle.com Tue Jan 21 18:17:40 2014 From: srikalyan.chandrashekar at oracle.com (srikalyan) Date: Tue, 21 Jan 2014 10:17:40 -0800 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52DE9147.4030305@gmail.com> References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> <52CC72AB.2020104@oracle.com> <52CCEDE0.8000809@oracle.com> <52CCF079.4090301@oracle.com> <52CD45E7.7010203@gmail.com> <52CE4E2D.300@oracle.com> <52CF37C6.1070605@oracle.com> <52CFAFEB.9090703@gmail.com> <52CFD218.2060101@gmail.com> <52D06B70.60001@oracle.com> <52D15201.90109@gmail.com> <52D47D59.8040905@oracle.com> <52D72577.1050506@oracle.com> <52D76859.2030502@oracle.com> <52D82968.4030608@oracle.com> <52D8929B.2020905@oracle.com> <52D8A42A.4020906@oracle.com> <52D8B3B6.3030202@oracle.com> <52D9295D.6080106@gmail.com> <52D92C73.2020309@gmail.com> <52D92F1A.4040400@gmail.com> <52DC812C.1000607@oracle.com> <52DCD78E.8050404@gmail.com> <52DCE17B.4050708@gmail.com> <52DDD9F3.1050201@oracle.com> <52DE19C1.2070302@gmail.com> <52DE9147.4030305@gmail.com> Message-ID: <52DEB9C4.4030606@oracle.com> Hi Peter/David, catching up after long weekend. Why would there be an OOME in object heap due to class loading in perm gen space ? Please correct if i am missing something here. Meanwhile i will give the version of Reference Handler you both agreed on a try. -- Thanks kalyan Ph: (408)-585-8040 On 1/21/14, 7:24 AM, Peter Levart wrote: > On 01/21/2014 07:54 AM, Peter Levart wrote: >> *[Loaded sun.misc.Cleaner from >> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar]* >> [Loaded java.io.ByteArrayInputStream from >> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >> [Loaded sun.util.calendar.ZoneInfoFile$ZoneOffsetTransitionRule from >> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >> ... >> >> >> I'm on linux, 64bit and using official EA build 121 of JDK 8... >> >> But if I try with JDK 7u45, I don't see it. > > So what changed between JDK 7 and JDK 8? > > I suspect the following: 8007572: Replace existing jdk timezone data > at /lib/zi with JSR310's tzdb > > > Regards, Peter > From joe.darcy at oracle.com Tue Jan 21 18:28:21 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 21 Jan 2014 10:28:21 -0800 Subject: JDK 9 RFR of 8032397: Remove sun.misc.Ref Message-ID: <52DEBC45.6080207@oracle.com> Hello, Following up from an earlier discussion on core-libs [1], I've gone through the exercise of purging sun.misc.Ref from the JDK repo. Patch below (having difficulties uploading the webrev to cr.openjdk at the time of writing.) For the change associated with removing sun.misc.Ref, I was aiming to minimize the alteration of surrounding code. For sun.misc.Cache, the CacheEntry class that subclasses Ref before now instead has an internal SoftReference and a few short methods that Ref used to define. In the Applet area, since the functionality of sun.misc.Ref over and above SoftReference was being used, I copied and partially generified the sun.misc.Ref code into AppletImageRef. Semantically, AppletImageRef is now a sun.misc.Ref. The purge of Ref required removing a method from AppletResourceLoader, a class which looks like it should have long ago been deprecated. A clean build of the jdk repo works after sun.misc.Ref has been deleted. Before pushing the change, I'll do a jprt job to make sure there aren't any other stray uses of Ref. Thanks, -Joe [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-January/024249.html diff -r 9bf43f25eacd src/share/classes/sun/applet/AppletImageRef.java --- a/src/share/classes/sun/applet/AppletImageRef.java Sat Jan 18 10:57:41 2014 -0800 +++ b/src/share/classes/sun/applet/AppletImageRef.java Tue Jan 21 10:15:15 2014 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1996, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1995, 2014, 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 @@ -27,27 +27,71 @@ import java.awt.Toolkit; import java.awt.Image; +import java.lang.ref.SoftReference; import sun.awt.image.URLImageSource; import java.net.URL; -class AppletImageRef extends sun.misc.Ref { +class AppletImageRef { + private SoftReference soft = null; + URL url; /** + * Returns a pointer to the object referenced by this Ref. If the object + * has been thrown away by the garbage collector, it will be + * reconstituted. This method does everything necessary to ensure that the garbage + * collector throws things away in Least Recently Used(LRU) order. Applications should + * never override this method. The get() method effectively caches calls to + * reconstitute(). + */ + public synchronized Image get() { + Image t = check(); + if (t == null) { + t = reconstitute(); + setThing(t); + } + return t; + } + + /** * Create the Ref */ AppletImageRef(URL url) { this.url = url; } - public void flush() { - super.flush(); + /** + * Flushes the cached object. Forces the next invocation of get() to + * invoke reconstitute(). + */ + public synchronized void flush() { + SoftReference s = soft; + if (s != null) s.clear(); + soft = null; + } + + /** + * Sets the thing to the specified object. + * @param thing the specified object + */ + public synchronized void setThing(Object thing) { + flush(); + soft = new SoftReference(thing); + } + + /** + * Checks to see what object is being pointed at by this Ref and returns it. + */ + public synchronized Image check() { + SoftReference s = soft; + if (s == null) return null; + return s.get(); } /** * Reconsitute the image. Only called when the ref has been flushed. */ - public Object reconstitute() { + public Image reconstitute() { Image img = Toolkit.getDefaultToolkit().createImage(new URLImageSource(url)); return img; } diff -r 9bf43f25eacd src/share/classes/sun/applet/AppletResourceLoader.java --- a/src/share/classes/sun/applet/AppletResourceLoader.java Sat Jan 18 10:57:41 2014 -0800 +++ b/src/share/classes/sun/applet/AppletResourceLoader.java Tue Jan 21 10:15:15 2014 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1996, 1998, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1996, 2014, 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 @@ -27,21 +27,17 @@ import java.net.URL; import java.awt.Image; -import sun.misc.Ref; /** * Part of this class still remains only to support legacy, 100%-impure * applications such as HotJava 1.0.1. */ + at Deprecated public class AppletResourceLoader { public static Image getImage(URL url) { return AppletViewer.getCachedImage(url); } - public static Ref getImageRef(URL url) { - return AppletViewer.getCachedImageRef(url); - } - public static void flushImages() { AppletViewer.flushImageCache(); } diff -r 9bf43f25eacd src/share/classes/sun/applet/AppletViewer.java --- a/src/share/classes/sun/applet/AppletViewer.java Sat Jan 18 10:57:41 2014 -0800 +++ b/src/share/classes/sun/applet/AppletViewer.java Tue Jan 21 10:15:15 2014 -0800 @@ -35,7 +35,6 @@ import java.net.URL; import java.net.MalformedURLException; import java.net.SocketPermission; -import sun.misc.Ref; import java.security.AccessController; import java.security.PrivilegedAction; import java.lang.reflect.InvocationTargetException; @@ -390,22 +389,18 @@ return getCachedImage(url); } + /** + * Get an image. + */ static Image getCachedImage(URL url) { // System.getSecurityManager().checkConnection(url.getHost(), url.getPort()); - return (Image)getCachedImageRef(url).get(); - } - - /** - * Get an image ref. - */ - static Ref getCachedImageRef(URL url) { synchronized (imageRefs) { AppletImageRef ref = (AppletImageRef)imageRefs.get(url); if (ref == null) { ref = new AppletImageRef(url); imageRefs.put(url, ref); } - return ref; + return ref.get(); } } diff -r 9bf43f25eacd src/share/classes/sun/misc/Cache.java --- a/src/share/classes/sun/misc/Cache.java Sat Jan 18 10:57:41 2014 -0800 +++ b/src/share/classes/sun/misc/Cache.java Tue Jan 21 10:15:15 2014 -0800 @@ -25,6 +25,7 @@ package sun.misc; +import java.lang.ref.SoftReference; import java.util.Dictionary; import java.util.Enumeration; import java.util.NoSuchElementException; @@ -32,12 +33,26 @@ /** * Caches the collision list. */ -class CacheEntry extends Ref { +class CacheEntry { int hash; Object key; CacheEntry next; - public Object reconstitute() { - return null; + SoftReference value; + + public CacheEntry() { + value = null; + } + + public CacheEntry(Object o) { + value = new SoftReference<>(o); + } + + public Object get() { + return value.get(); + } + + public void setThing(Object thing) { + value = new SoftReference<>(thing); } } @@ -192,7 +207,7 @@ int index = (hash & 0x7FFFFFFF) % tab.length; for (CacheEntry e = tab[index]; e != null; e = e.next) { if ((e.hash == hash) && e.key.equals(key)) { - return e.check(); + return e.get(); } } return null; @@ -220,7 +235,7 @@ for (CacheEntry old = oldTable[i]; old != null;) { CacheEntry e = old; old = old.next; - if (e.check() != null) { + if (e.get() != null) { int index = (e.hash & 0x7FFFFFFF) % newCapacity; e.next = newTable[index]; newTable[index] = e; @@ -253,10 +268,10 @@ CacheEntry ne = null; for (CacheEntry e = tab[index]; e != null; e = e.next) { if ((e.hash == hash) && e.key.equals(key)) { - Object old = e.check(); + Object old = e.get(); e.setThing(value); return old; - } else if (e.check() == null) + } else if (e.get() == null) ne = e; /* reuse old flushed value */ } @@ -296,7 +311,7 @@ tab[index] = e.next; } count--; - return e.check(); + return e.get(); } } return null; @@ -322,7 +337,7 @@ public boolean hasMoreElements() { while (index >= 0) { while (entry != null) - if (entry.check() != null) + if (entry.get() != null) return true; else entry = entry.next; @@ -338,8 +353,8 @@ if (entry != null) { CacheEntry e = entry; entry = e.next; - if (e.check() != null) - return keys ? e.key : e.check(); + if (e.get() != null) + return keys ? e.key : e.get(); } } throw new NoSuchElementException("CacheEnumerator"); # Deletion of sun.misc.Ref elided. From lana.steuck at oracle.com Tue Jan 21 19:03:11 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 21 Jan 2014 19:03:11 +0000 Subject: hg: jdk8/tl: 5 new changesets Message-ID: <20140121190312.C650E625FA@hg.openjdk.java.net> Changeset: ca4612164195 Author: lana Date: 2014-01-08 11:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/ca4612164195 Merge Changeset: b5e1dad69605 Author: jeff Date: 2014-01-13 14:41 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/b5e1dad69605 7129980: Third Party License Readme update for JDK8 Reviewed-by: lana, tbell ! THIRD_PARTY_README Changeset: 6ac7d4011e8a Author: lana Date: 2014-01-13 22:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/6ac7d4011e8a Merge Changeset: 790bbd46b201 Author: lana Date: 2014-01-15 10:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/790bbd46b201 Merge Changeset: 0623ae55afff Author: katleman Date: 2014-01-17 15:52 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/0623ae55afff Added tag jdk8-b124 for changeset 790bbd46b201 ! .hgtags From lana.steuck at oracle.com Tue Jan 21 19:03:15 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 21 Jan 2014 19:03:15 +0000 Subject: hg: jdk8/tl/langtools: 6 new changesets Message-ID: <20140121190344.1A946625FF@hg.openjdk.java.net> Changeset: d5aab8300d3b Author: katleman Date: 2014-01-10 08:32 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d5aab8300d3b Added tag jdk8-b123 for changeset a345cf28faca ! .hgtags Changeset: 4a5e16002234 Author: lana Date: 2014-01-08 11:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4a5e16002234 Merge Changeset: e90611913bb1 Author: jeff Date: 2014-01-13 14:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e90611913bb1 7129980: Third Party License Readme update for JDK8 Reviewed-by: lana, tbell ! THIRD_PARTY_README Changeset: 91e6cd536c34 Author: lana Date: 2014-01-13 22:33 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/91e6cd536c34 Merge Changeset: 436176151e85 Author: lana Date: 2014-01-15 10:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/436176151e85 Merge Changeset: 9e35f82eec22 Author: katleman Date: 2014-01-17 15:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9e35f82eec22 Added tag jdk8-b124 for changeset 436176151e85 ! .hgtags From lana.steuck at oracle.com Tue Jan 21 19:03:11 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 21 Jan 2014 19:03:11 +0000 Subject: hg: jdk8/tl/corba: 5 new changesets Message-ID: <20140121190318.21207625FB@hg.openjdk.java.net> Changeset: afecd2878aee Author: katleman Date: 2014-01-10 08:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/afecd2878aee Added tag jdk8-b123 for changeset 1ecd4619f60c ! .hgtags Changeset: b509e2e0fc41 Author: jeff Date: 2014-01-13 14:42 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/b509e2e0fc41 7129980: Third Party License Readme update for JDK8 Reviewed-by: lana, tbell ! THIRD_PARTY_README Changeset: 33e3d3425095 Author: lana Date: 2014-01-13 22:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/33e3d3425095 Merge Changeset: 7b45151c7a05 Author: lana Date: 2014-01-15 10:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/7b45151c7a05 Merge Changeset: 6b66ffd36885 Author: katleman Date: 2014-01-17 15:52 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/6b66ffd36885 Added tag jdk8-b124 for changeset 7b45151c7a05 ! .hgtags From lana.steuck at oracle.com Tue Jan 21 19:03:11 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 21 Jan 2014 19:03:11 +0000 Subject: hg: jdk8/tl/nashorn: 4 new changesets Message-ID: <20140121190322.3C85A625FC@hg.openjdk.java.net> Changeset: 3356919b1639 Author: jeff Date: 2014-01-13 14:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/3356919b1639 7129980: Third Party License Readme update for JDK8 Reviewed-by: lana, tbell ! THIRD_PARTY_README Changeset: aefba9e5e35c Author: lana Date: 2014-01-13 22:33 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/aefba9e5e35c Merge Changeset: 7346abe2ea03 Author: lana Date: 2014-01-15 10:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/7346abe2ea03 Merge Changeset: 40192ec6af87 Author: katleman Date: 2014-01-17 15:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/40192ec6af87 Added tag jdk8-b124 for changeset 7346abe2ea03 ! .hgtags From lana.steuck at oracle.com Tue Jan 21 19:03:17 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 21 Jan 2014 19:03:17 +0000 Subject: hg: jdk8/tl/jaxws: 5 new changesets Message-ID: <20140121190335.DFCF8625FE@hg.openjdk.java.net> Changeset: 241e4effed6d Author: katleman Date: 2014-01-10 08:32 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/241e4effed6d Added tag jdk8-b123 for changeset 91f5c542ccad ! .hgtags Changeset: c71b6b41a2a1 Author: jeff Date: 2014-01-13 14:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/c71b6b41a2a1 7129980: Third Party License Readme update for JDK8 Reviewed-by: lana, tbell ! THIRD_PARTY_README Changeset: 9ed8a0577511 Author: lana Date: 2014-01-13 22:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/9ed8a0577511 Merge Changeset: ef71ecbcd7bc Author: lana Date: 2014-01-15 10:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/ef71ecbcd7bc Merge Changeset: b14885a461b3 Author: katleman Date: 2014-01-17 15:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/b14885a461b3 Added tag jdk8-b124 for changeset ef71ecbcd7bc ! .hgtags From lana.steuck at oracle.com Tue Jan 21 19:03:11 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 21 Jan 2014 19:03:11 +0000 Subject: hg: jdk8/tl/jaxp: 5 new changesets Message-ID: <20140121190335.3FF2F625FD@hg.openjdk.java.net> Changeset: 1a28f773c894 Author: katleman Date: 2014-01-10 08:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/1a28f773c894 Added tag jdk8-b123 for changeset 4e35b5b6d2e5 ! .hgtags Changeset: d906d69e24a3 Author: jeff Date: 2014-01-13 14:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/d906d69e24a3 7129980: Third Party License Readme update for JDK8 Reviewed-by: lana, tbell ! THIRD_PARTY_README Changeset: a7c0452ab987 Author: lana Date: 2014-01-13 22:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/a7c0452ab987 Merge Changeset: 83bb924238f8 Author: lana Date: 2014-01-15 10:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/83bb924238f8 Merge Changeset: 5a4e9ef8673d Author: katleman Date: 2014-01-17 15:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/5a4e9ef8673d Added tag jdk8-b124 for changeset 83bb924238f8 ! .hgtags From lana.steuck at oracle.com Tue Jan 21 19:03:12 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 21 Jan 2014 19:03:12 +0000 Subject: hg: jdk8/tl/hotspot: 10 new changesets Message-ID: <20140121190346.1F25862600@hg.openjdk.java.net> Changeset: c89630a122b4 Author: katleman Date: 2014-01-10 08:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c89630a122b4 Added tag jdk8-b123 for changeset 591135a7d6f9 ! .hgtags Changeset: f898fdfc08a5 Author: jeff Date: 2014-01-13 14:42 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f898fdfc08a5 7129980: Third Party License Readme update for JDK8 Reviewed-by: lana, tbell ! THIRD_PARTY_README Changeset: b99955ea4b91 Author: lana Date: 2014-01-13 22:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b99955ea4b91 Merge Changeset: 9d39e8a8ff61 Author: amurillo Date: 2013-12-27 07:51 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9d39e8a8ff61 8031060: new hotspot build - hs25-b66 Reviewed-by: jcoomes ! make/hotspot_version Changeset: c3f3cfd39184 Author: hseigel Date: 2014-01-10 12:11 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c3f3cfd39184 8031059: invokestatic: ICCE trying to invoke static method when it clashes with an abstract method inherited from an interface Summary: Do not create AME overpass if there is a matching static method Reviewed-by: lfoltan, coleenp, kamg ! src/share/vm/classfile/defaultMethods.cpp Changeset: 9b9816164447 Author: amurillo Date: 2014-01-13 15:52 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9b9816164447 Merge Changeset: ac902fca803b Author: amurillo Date: 2014-01-13 15:52 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ac902fca803b Added tag hs25-b66 for changeset 9b9816164447 ! .hgtags Changeset: 2c3130311ffa Author: amurillo Date: 2014-01-14 11:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2c3130311ffa Merge Changeset: df333ee12bba Author: lana Date: 2014-01-15 10:48 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/df333ee12bba Merge Changeset: e2e6ca7e0ea6 Author: katleman Date: 2014-01-17 15:52 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e2e6ca7e0ea6 Added tag jdk8-b124 for changeset df333ee12bba ! .hgtags From lana.steuck at oracle.com Tue Jan 21 19:04:00 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 21 Jan 2014 19:04:00 +0000 Subject: hg: jdk8/tl/jdk: 8 new changesets Message-ID: <20140121190556.93AC862601@hg.openjdk.java.net> Changeset: 9683419eddef Author: lana Date: 2014-01-08 11:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9683419eddef Merge Changeset: 2551e7290450 Author: jeff Date: 2014-01-13 14:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2551e7290450 7129980: Third Party License Readme update for JDK8 Reviewed-by: lana, tbell ! THIRD_PARTY_README Changeset: 01a6b4654550 Author: lana Date: 2014-01-13 22:32 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/01a6b4654550 Merge Changeset: 2a3afe1ec514 Author: rgallard Date: 2014-01-09 16:10 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2a3afe1ec514 8026909: Retire Some Rarely Used GC Combintations Summary: Fix only affects java command, nroff page, OpenJDK Reviewed-by: maxelsso ! src/bsd/doc/man/java.1 ! src/linux/doc/man/java.1 ! src/solaris/doc/sun/man/man1/java.1 Changeset: acc59aae7992 Author: katleman Date: 2014-01-14 11:56 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/acc59aae7992 Merge Changeset: f1f3596239a4 Author: lana Date: 2014-01-15 10:57 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f1f3596239a4 Merge - src/bsd/doc/man/ja/kinit.1 - src/bsd/doc/man/ja/klist.1 - src/bsd/doc/man/ja/ktab.1 Changeset: ae303640bc1c Author: lana Date: 2014-01-16 10:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ae303640bc1c Merge - src/bsd/doc/man/ja/kinit.1 - src/bsd/doc/man/ja/klist.1 - src/bsd/doc/man/ja/ktab.1 Changeset: 3e9b46280c16 Author: katleman Date: 2014-01-17 15:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3e9b46280c16 Added tag jdk8-b124 for changeset ae303640bc1c ! .hgtags From john.r.rose at oracle.com Tue Jan 21 19:25:32 2014 From: john.r.rose at oracle.com (John Rose) Date: Tue, 21 Jan 2014 11:25:32 -0800 Subject: [JDK8] RFR (XS): JSR292: IncompatibleClassChangeError in LambdaForm for CharSequence.toString() method handle type converter In-Reply-To: References: <52D6A9B8.2040906@oracle.com> <0DA570E9-814A-44B5-8CDA-6F7C9A92B423@oracle.com> <52D6E455.4050607@oracle.com> Message-ID: On Jan 15, 2014, at 6:49 PM, Christian Thalinger wrote: > John would know the answer. > > Given this change should go into JDK 8 I think we should push for now. If we can come up with a better way to handle these situations we can push another change for 9 or 8u20. (Back from vacation.) Vladimir's change for bytecode generation is safe. It assumes something stable, which is that virtual invocation mode can apply to interfaces only because they inherit Object. Therefore we can back off from invokevirtual to invokeinterface, without changing behavior. FTR, this fix may be redundant with this changeset: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/9063bd8808a7 ...and specifically with the line of code which says "m_klass = m_klass_non_interface". This redundancy is of the belt-and-suspenders kind; it could be changed to an assert, but is fine the way it is. Thanks for fixing this! ? John From mike.duigou at oracle.com Tue Jan 21 20:03:09 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 21 Jan 2014 12:03:09 -0800 Subject: RFR: 8032190 It's unclear that flatMap will ensure each stream will be closed. In-Reply-To: <945CCAF6-375D-41E3-A24A-9BE7328A8D3B@oracle.com> References: <2A77FAFB-7F05-41AE-A73D-1C1B1E2D703C@oracle.com> <52DD3046.1070500@oracle.com> <945CCAF6-375D-41E3-A24A-9BE7328A8D3B@oracle.com> Message-ID: <3B5FBD01-2F68-43A5-BB48-3AADD36DDEFA@oracle.com> On Jan 20 2014, at 07:18 , Paul Sandoz wrote: > > On Jan 20, 2014, at 3:18 PM, Chris Hegarty wrote: > >> It is good to clarify that the streams are closed. >> >> I find the following updated wording a little odd, "If a mapped stream is {@code null} then it treated as if it was an empty stream." I thought the previous wording was better, but that could be just me. >> > > I was hopping to use the term "mapped stream" to avoid some repetition for "the result of the mapping function" etc, but wording seems a little garbled. > > How about: > > If a mapped stream is {@code null} an empty stream is used, instead. The comma seems extraneous. Mike From Alan.Bateman at oracle.com Tue Jan 21 21:02:19 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 21 Jan 2014 21:02:19 +0000 Subject: JDK 9 RFR of 8032397: Remove sun.misc.Ref In-Reply-To: <52DEBC45.6080207@oracle.com> References: <52DEBC45.6080207@oracle.com> Message-ID: <52DEE05B.3030808@oracle.com> On 21/01/2014 18:28, Joe Darcy wrote: > Hello, > > Following up from an earlier discussion on core-libs [1], I've gone > through the exercise of purging sun.misc.Ref from the JDK repo. Patch > below (having difficulties uploading the webrev to cr.openjdk at the > time of writing.) > > For the change associated with removing sun.misc.Ref, I was aiming to > minimize the alteration of surrounding code. > > For sun.misc.Cache, the CacheEntry class that subclasses Ref before > now instead has an internal SoftReference and a few short methods that > Ref used to define. > > In the Applet area, since the functionality of sun.misc.Ref over and > above SoftReference was being used, I copied and partially generified > the sun.misc.Ref code into AppletImageRef. Semantically, > AppletImageRef is now a sun.misc.Ref. > > The purge of Ref required removing a method from AppletResourceLoader, > a class which looks like it should have long ago been deprecated. > > A clean build of the jdk repo works after sun.misc.Ref has been > deleted. Before pushing the change, I'll do a jprt job to make sure > there aren't any other stray uses of Ref. > > Thanks, > > -Joe I think this is okay, just took me a few seconds to see what had moved from Ref (along with the javadoc comments). A minor comment is that Cache has an @see sun.misc.Ref in its class description that should be removed. I searched the forest and I see there are two RMI tests that reference it, one directly, the other seems to be just a comment. I also see that jhat looks for sun.misc.Ref in the heap. I guess someone could use a JDK 9 build and run jhat to look at a heap dump from a older JDK where sun.misc.Ref is used so maybe there is an argument to leaving this in. If you do then maybe it needs a comment. -Alan. From joe.darcy at oracle.com Tue Jan 21 21:44:23 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 21 Jan 2014 13:44:23 -0800 Subject: JDK 9 RFR of 8032397: Remove sun.misc.Ref In-Reply-To: <52DEBC45.6080207@oracle.com> References: <52DEBC45.6080207@oracle.com> Message-ID: <52DEEA37.8070708@oracle.com> PS Webrev now posted at: http://cr.openjdk.java.net/~darcy/8032397.0/ -Joe On 01/21/2014 10:28 AM, Joe Darcy wrote: > Hello, > > Following up from an earlier discussion on core-libs [1], I've gone > through the exercise of purging sun.misc.Ref from the JDK repo. Patch > below (having difficulties uploading the webrev to cr.openjdk at the > time of writing.) > > For the change associated with removing sun.misc.Ref, I was aiming to > minimize the alteration of surrounding code. > > For sun.misc.Cache, the CacheEntry class that subclasses Ref before > now instead has an internal SoftReference and a few short methods that > Ref used to define. > > In the Applet area, since the functionality of sun.misc.Ref over and > above SoftReference was being used, I copied and partially generified > the sun.misc.Ref code into AppletImageRef. Semantically, > AppletImageRef is now a sun.misc.Ref. > > The purge of Ref required removing a method from AppletResourceLoader, > a class which looks like it should have long ago been deprecated. > > A clean build of the jdk repo works after sun.misc.Ref has been > deleted. Before pushing the change, I'll do a jprt job to make sure > there aren't any other stray uses of Ref. > > Thanks, > > -Joe > > [1] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-January/024249.html > > diff -r 9bf43f25eacd src/share/classes/sun/applet/AppletImageRef.java > --- a/src/share/classes/sun/applet/AppletImageRef.java Sat Jan 18 > 10:57:41 2014 -0800 > +++ b/src/share/classes/sun/applet/AppletImageRef.java Tue Jan 21 > 10:15:15 2014 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1996, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1995, 2014, 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 > @@ -27,27 +27,71 @@ > > import java.awt.Toolkit; > import java.awt.Image; > +import java.lang.ref.SoftReference; > import sun.awt.image.URLImageSource; > import java.net.URL; > > -class AppletImageRef extends sun.misc.Ref { > +class AppletImageRef { > + private SoftReference soft = null; > + > URL url; > > /** > + * Returns a pointer to the object referenced by this Ref. If the > object > + * has been thrown away by the garbage collector, it will be > + * reconstituted. This method does everything necessary to ensure > that the garbage > + * collector throws things away in Least Recently Used(LRU) > order. Applications should > + * never override this method. The get() method effectively > caches calls to > + * reconstitute(). > + */ > + public synchronized Image get() { > + Image t = check(); > + if (t == null) { > + t = reconstitute(); > + setThing(t); > + } > + return t; > + } > + > + /** > * Create the Ref > */ > AppletImageRef(URL url) { > this.url = url; > } > > - public void flush() { > - super.flush(); > + /** > + * Flushes the cached object. Forces the next invocation of > get() to > + * invoke reconstitute(). > + */ > + public synchronized void flush() { > + SoftReference s = soft; > + if (s != null) s.clear(); > + soft = null; > + } > + > + /** > + * Sets the thing to the specified object. > + * @param thing the specified object > + */ > + public synchronized void setThing(Object thing) { > + flush(); > + soft = new SoftReference(thing); > + } > + > + /** > + * Checks to see what object is being pointed at by this Ref and > returns it. > + */ > + public synchronized Image check() { > + SoftReference s = soft; > + if (s == null) return null; > + return s.get(); > } > > /** > * Reconsitute the image. Only called when the ref has been > flushed. > */ > - public Object reconstitute() { > + public Image reconstitute() { > Image img = Toolkit.getDefaultToolkit().createImage(new > URLImageSource(url)); > return img; > } > diff -r 9bf43f25eacd > src/share/classes/sun/applet/AppletResourceLoader.java > --- a/src/share/classes/sun/applet/AppletResourceLoader.java Sat Jan > 18 10:57:41 2014 -0800 > +++ b/src/share/classes/sun/applet/AppletResourceLoader.java Tue Jan > 21 10:15:15 2014 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1996, 1998, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1996, 2014, 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 > @@ -27,21 +27,17 @@ > > import java.net.URL; > import java.awt.Image; > -import sun.misc.Ref; > > /** > * Part of this class still remains only to support legacy, 100%-impure > * applications such as HotJava 1.0.1. > */ > + at Deprecated > public class AppletResourceLoader { > public static Image getImage(URL url) { > return AppletViewer.getCachedImage(url); > } > > - public static Ref getImageRef(URL url) { > - return AppletViewer.getCachedImageRef(url); > - } > - > public static void flushImages() { > AppletViewer.flushImageCache(); > } > diff -r 9bf43f25eacd src/share/classes/sun/applet/AppletViewer.java > --- a/src/share/classes/sun/applet/AppletViewer.java Sat Jan 18 > 10:57:41 2014 -0800 > +++ b/src/share/classes/sun/applet/AppletViewer.java Tue Jan 21 > 10:15:15 2014 -0800 > @@ -35,7 +35,6 @@ > import java.net.URL; > import java.net.MalformedURLException; > import java.net.SocketPermission; > -import sun.misc.Ref; > import java.security.AccessController; > import java.security.PrivilegedAction; > import java.lang.reflect.InvocationTargetException; > @@ -390,22 +389,18 @@ > return getCachedImage(url); > } > > + /** > + * Get an image. > + */ > static Image getCachedImage(URL url) { > // System.getSecurityManager().checkConnection(url.getHost(), > url.getPort()); > - return (Image)getCachedImageRef(url).get(); > - } > - > - /** > - * Get an image ref. > - */ > - static Ref getCachedImageRef(URL url) { > synchronized (imageRefs) { > AppletImageRef ref = (AppletImageRef)imageRefs.get(url); > if (ref == null) { > ref = new AppletImageRef(url); > imageRefs.put(url, ref); > } > - return ref; > + return ref.get(); > } > } > > diff -r 9bf43f25eacd src/share/classes/sun/misc/Cache.java > --- a/src/share/classes/sun/misc/Cache.java Sat Jan 18 10:57:41 > 2014 -0800 > +++ b/src/share/classes/sun/misc/Cache.java Tue Jan 21 10:15:15 > 2014 -0800 > @@ -25,6 +25,7 @@ > > package sun.misc; > > +import java.lang.ref.SoftReference; > import java.util.Dictionary; > import java.util.Enumeration; > import java.util.NoSuchElementException; > @@ -32,12 +33,26 @@ > /** > * Caches the collision list. > */ > -class CacheEntry extends Ref { > +class CacheEntry { > int hash; > Object key; > CacheEntry next; > - public Object reconstitute() { > - return null; > + SoftReference value; > + > + public CacheEntry() { > + value = null; > + } > + > + public CacheEntry(Object o) { > + value = new SoftReference<>(o); > + } > + > + public Object get() { > + return value.get(); > + } > + > + public void setThing(Object thing) { > + value = new SoftReference<>(thing); > } > } > > @@ -192,7 +207,7 @@ > int index = (hash & 0x7FFFFFFF) % tab.length; > for (CacheEntry e = tab[index]; e != null; e = e.next) { > if ((e.hash == hash) && e.key.equals(key)) { > - return e.check(); > + return e.get(); > } > } > return null; > @@ -220,7 +235,7 @@ > for (CacheEntry old = oldTable[i]; old != null;) { > CacheEntry e = old; > old = old.next; > - if (e.check() != null) { > + if (e.get() != null) { > int index = (e.hash & 0x7FFFFFFF) % newCapacity; > e.next = newTable[index]; > newTable[index] = e; > @@ -253,10 +268,10 @@ > CacheEntry ne = null; > for (CacheEntry e = tab[index]; e != null; e = e.next) { > if ((e.hash == hash) && e.key.equals(key)) { > - Object old = e.check(); > + Object old = e.get(); > e.setThing(value); > return old; > - } else if (e.check() == null) > + } else if (e.get() == null) > ne = e; /* reuse old flushed value */ > } > > @@ -296,7 +311,7 @@ > tab[index] = e.next; > } > count--; > - return e.check(); > + return e.get(); > } > } > return null; > @@ -322,7 +337,7 @@ > public boolean hasMoreElements() { > while (index >= 0) { > while (entry != null) > - if (entry.check() != null) > + if (entry.get() != null) > return true; > else > entry = entry.next; > @@ -338,8 +353,8 @@ > if (entry != null) { > CacheEntry e = entry; > entry = e.next; > - if (e.check() != null) > - return keys ? e.key : e.check(); > + if (e.get() != null) > + return keys ? e.key : e.get(); > } > } > throw new NoSuchElementException("CacheEnumerator"); > > > # Deletion of sun.misc.Ref elided. From joe.darcy at oracle.com Tue Jan 21 21:47:00 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 21 Jan 2014 13:47:00 -0800 Subject: JDK 9 RFR of 8032397: Remove sun.misc.Ref In-Reply-To: <52DEE05B.3030808@oracle.com> References: <52DEBC45.6080207@oracle.com> <52DEE05B.3030808@oracle.com> Message-ID: <52DEEAD4.1080901@oracle.com> Hi Alan, On 01/21/2014 01:02 PM, Alan Bateman wrote: > On 21/01/2014 18:28, Joe Darcy wrote: >> Hello, >> >> Following up from an earlier discussion on core-libs [1], I've gone >> through the exercise of purging sun.misc.Ref from the JDK repo. Patch >> below (having difficulties uploading the webrev to cr.openjdk at the >> time of writing.) >> >> For the change associated with removing sun.misc.Ref, I was aiming to >> minimize the alteration of surrounding code. >> >> For sun.misc.Cache, the CacheEntry class that subclasses Ref before >> now instead has an internal SoftReference and a few short methods >> that Ref used to define. >> >> In the Applet area, since the functionality of sun.misc.Ref over and >> above SoftReference was being used, I copied and partially generified >> the sun.misc.Ref code into AppletImageRef. Semantically, >> AppletImageRef is now a sun.misc.Ref. >> >> The purge of Ref required removing a method from >> AppletResourceLoader, a class which looks like it should have long >> ago been deprecated. >> >> A clean build of the jdk repo works after sun.misc.Ref has been >> deleted. Before pushing the change, I'll do a jprt job to make sure >> there aren't any other stray uses of Ref. >> >> Thanks, >> >> -Joe > I think this is okay, just took me a few seconds to see what had moved > from Ref (along with the javadoc comments). A minor comment is that > Cache has an @see sun.misc.Ref in its class description that should be > removed. I'll remove that in the next iteration of the webrev. > > I searched the forest and I see there are two RMI tests that reference > it, one directly, the other seems to be just a comment. I'll try those down and make the necessary updates. > > I also see that jhat looks for sun.misc.Ref in the heap. I guess > someone could use a JDK 9 build and run jhat to look at a heap dump > from a older JDK where sun.misc.Ref is used so maybe there is an > argument to leaving this in. If you do then maybe it needs a comment. > > I'd prefer to remove sun.misc.Ref now and if it is a severe problem, restore it later in JDK 9. Thanks for the review, -Joe From xueming.shen at oracle.com Tue Jan 21 22:05:57 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 21 Jan 2014 14:05:57 -0800 Subject: RFR: JDK-8032012, , String.toLowerCase/toUpperCase performance improvement In-Reply-To: References: <52D82013.7020009@oracle.com> Message-ID: <52DEEF45.7060506@oracle.com> Hi Paul, thanks for reviewing the changeset, comment inlined below. On 01/20/2014 09:24 AM, Paul Sandoz wrote: > > Some quick comments. > > In String.toLowerCase: > > - it would be nice to get rid of the pseudo goto using the "scan" labelled block. > webrev has been updated to remove the pseudo goto by checking the "first" against "len" after the loop break. > - there is no need for the "localeDependent" local variable. > I just tried to not throw away the result of this "localeDependent", which is still needed in the toXCaseEx() methods. > - you might be able to optimize by doing (could depend on the answer to the next point): > > int c = (int)value[i]; > int lc = Character.toLowerCase(c); > if (.....) { result[i] = (char)lc; } else { return toLowerCaseEx(result, i, locale, localeDependent); } > > - Do you need to check ERROR for the result of toLowerCase? > > 2586 if (c == Character.ERROR || > Yes, Character.toLowerCase() should never return ERROR (while the package private Character.toUpperCaseEx() will). In theory there is no need to check if the return value of Character.toUpperCase(int) > min_supplementary_code_point in our loop, because there is no bmp character returns a supplementary code point as its lower case. But since it's a data driven mapping table, there is no guarantee the unicode data table is not going to change in the "future", so I still keep the check. The webrev has been updated to use one single "if" inside the loop. I have a "single if" implementation for the toUpperCase() as well, though don't sure which one is better/faster :-) http://cr.openjdk.java.net/~sherman/8032012/ -Sherman From peter.levart at gmail.com Tue Jan 21 22:31:24 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 21 Jan 2014 23:31:24 +0100 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52DEB9C4.4030606@oracle.com> References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> <52CC72AB.2020104@oracle.com> <52CCEDE0.8000809@oracle.com> <52CCF079.4090301@oracle.com> <52CD45E7.7010203@gmail.com> <52CE4E2D.300@oracle.com> <52CF37C6.1070605@oracle.com> <52CFAFEB.9090703@gmail.com> <52CFD218.2060101@gmail.com> <52D06B70.60001@oracle.com> <52D15201.90109@gmail.com> <52D47D59.8040905@oracle.com> <52D72577.1050506@oracle.com> <52D76859.2030502@oracle.com> <52D82968.4030608@oracle.com> <52D8929B.2020905@oracle.com> <52D8A42A.4020906@oracle.com> <52D8B3B6.3030202@oracle.com> <52D9295D.6080106@gmail.com> <52D92C73.2020309@gmail.com> <52D92F1A.4040400@gmail.com> <52DC812C.1000607@oracle.com> <52DCD78E.8050404@gmail.com> <52DCE17B.4050708@gmail.com> <52DDD9F3.1050201@oracle.com> <52DE19C1.2070302@gmail.com> <52DE9147.4030305@gmail.com> <52DEB9C4.4030606@oracle.com> Message-ID: <52DEF53C.3050905@gmail.com> On 01/21/2014 07:17 PM, srikalyan wrote: > Hi Peter/David, catching up after long weekend. Why would there be an > OOME in object heap due to class loading in perm gen space ? The perm gen is not a problem her (JDK 8 does not have it and we see OOME on JDK8 too). Each time a class is loaded, new java.lang.Class object is allocated on heap. Regards, Peter > Please correct if i am missing something here. Meanwhile i will give > the version of Reference Handler you both agreed on a try. > -- > Thanks > kalyan > Ph: (408)-585-8040 > > On 1/21/14, 7:24 AM, Peter Levart wrote: >> On 01/21/2014 07:54 AM, Peter Levart wrote: >>> *[Loaded sun.misc.Cleaner from >>> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar]* >>> [Loaded java.io.ByteArrayInputStream from >>> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >>> [Loaded sun.util.calendar.ZoneInfoFile$ZoneOffsetTransitionRule from >>> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >>> ... >>> >>> >>> I'm on linux, 64bit and using official EA build 121 of JDK 8... >>> >>> But if I try with JDK 7u45, I don't see it. >> >> So what changed between JDK 7 and JDK 8? >> >> I suspect the following: 8007572: Replace existing jdk timezone data >> at /lib/zi with JSR310's tzdb >> >> >> Regards, Peter >> From tristan.yan at oracle.com Wed Jan 22 00:26:12 2014 From: tristan.yan at oracle.com (Tristan Yan) Date: Wed, 22 Jan 2014 08:26:12 +0800 Subject: Move forward for JDK-8029891 Message-ID: <8A88F4E7-6B3C-4542-9270-FA331E5EAE8F@oracle.com> Hi Mandy We have discussed bug https://bugs.openjdk.java.net/browse/JDK-8029891 in JBS. And we don't think this is a good time to fix it. I suggest we do two things for this bug if it's okay for you. 1. We open a new JDK bug for tracking down future JDK change. Also link JDK-8029891 to this new jdk bug. 2. We put java/lang/ClassLoader/deadlock/GetResource.java to ProblemList. Please let know if you agree this. Thank you. Tristan From mandy.chung at oracle.com Wed Jan 22 00:52:15 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 21 Jan 2014 16:52:15 -0800 Subject: Move forward for JDK-8029891 In-Reply-To: <8A88F4E7-6B3C-4542-9270-FA331E5EAE8F@oracle.com> References: <8A88F4E7-6B3C-4542-9270-FA331E5EAE8F@oracle.com> Message-ID: <52DF163F.5020502@oracle.com> Hi Tristan, On 1/21/2014 4:26 PM, Tristan Yan wrote: > Hi Mandy > > We have discussed bug https://bugs.openjdk.java.net/browse/JDK-8029891 > in JBS. And we don't think this is a good time to fix it. I suggest we > do two things for this bug if it's okay for you. > 1. We open a new JDK bug for tracking down future JDK change. Also > link JDK-8029891 to this new jdk bug. Why do we need a new JDK bug? I think we should use JDK-8029891 and fix it in JDK 9. > 2. We put java/lang/ClassLoader/deadlock/GetResource.java to ProblemList. Is this intermittent? I believe it's not. Since this is a bug, it's more appropriate to add @ignore to the test as I think I won't fix this soon. Mandy > Please let know if you agree this. > Thank you. > Tristan From tristan.yan at oracle.com Wed Jan 22 01:03:53 2014 From: tristan.yan at oracle.com (Tristan Yan) Date: Wed, 22 Jan 2014 09:03:53 +0800 Subject: Move forward for JDK-8029891 In-Reply-To: <52DF163F.5020502@oracle.com> References: <8A88F4E7-6B3C-4542-9270-FA331E5EAE8F@oracle.com> <52DF163F.5020502@oracle.com> Message-ID: <0C871456-09DF-4A9F-BC89-B5F400F405DD@oracle.com> Thank you Mandy If you want to fix it soon. I am okay to use this bug as the one tracking the fix. BTW This is an intermittent failure. Regards Tristan On Jan 22, 2014, at 8:52 AM, Mandy Chung wrote: > Hi Tristan, > > On 1/21/2014 4:26 PM, Tristan Yan wrote: >> Hi Mandy >> >> We have discussed bug https://bugs.openjdk.java.net/browse/JDK-8029891 in JBS. And we don't think this is a good time to fix it. I suggest we do two things for this bug if it's okay for you. >> 1. We open a new JDK bug for tracking down future JDK change. Also link JDK-8029891 to this new jdk bug. > > Why do we need a new JDK bug? I think we should use JDK-8029891 and fix it in JDK 9. > >> 2. We put java/lang/ClassLoader/deadlock/GetResource.java to ProblemList. > > Is this intermittent? I believe it's not. Since this is a bug, it's more appropriate to add @ignore to the test as I think I won't fix this soon. > > Mandy > >> Please let know if you agree this. >> Thank you. >> Tristan > From joe.darcy at oracle.com Wed Jan 22 01:17:06 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 21 Jan 2014 17:17:06 -0800 Subject: JDK 9 RFR of 8032397: Remove sun.misc.Ref In-Reply-To: <52DEEAD4.1080901@oracle.com> References: <52DEBC45.6080207@oracle.com> <52DEE05B.3030808@oracle.com> <52DEEAD4.1080901@oracle.com> Message-ID: <52DF1C12.7000508@oracle.com> Hi Alan, Updated webrev at http://cr.openjdk.java.net/~darcy/8032397.1/ @see in sun.misc.Ref removed. Regression tests updated to not refer to sun.misc.Ref. I looked at the use of Ref in jhat and it is only used if java.lang.ref.Reference is not found reflectively, so I think the existing code can stay in place. Thanks, -Joe On 01/21/2014 01:47 PM, Joe Darcy wrote: > Hi Alan, > > On 01/21/2014 01:02 PM, Alan Bateman wrote: >> On 21/01/2014 18:28, Joe Darcy wrote: >>> Hello, >>> >>> Following up from an earlier discussion on core-libs [1], I've gone >>> through the exercise of purging sun.misc.Ref from the JDK repo. >>> Patch below (having difficulties uploading the webrev to cr.openjdk >>> at the time of writing.) >>> >>> For the change associated with removing sun.misc.Ref, I was aiming >>> to minimize the alteration of surrounding code. >>> >>> For sun.misc.Cache, the CacheEntry class that subclasses Ref before >>> now instead has an internal SoftReference and a few short methods >>> that Ref used to define. >>> >>> In the Applet area, since the functionality of sun.misc.Ref over and >>> above SoftReference was being used, I copied and partially >>> generified the sun.misc.Ref code into AppletImageRef. Semantically, >>> AppletImageRef is now a sun.misc.Ref. >>> >>> The purge of Ref required removing a method from >>> AppletResourceLoader, a class which looks like it should have long >>> ago been deprecated. >>> >>> A clean build of the jdk repo works after sun.misc.Ref has been >>> deleted. Before pushing the change, I'll do a jprt job to make sure >>> there aren't any other stray uses of Ref. >>> >>> Thanks, >>> >>> -Joe >> I think this is okay, just took me a few seconds to see what had >> moved from Ref (along with the javadoc comments). A minor comment is >> that Cache has an @see sun.misc.Ref in its class description that >> should be removed. > > I'll remove that in the next iteration of the webrev. > >> >> I searched the forest and I see there are two RMI tests that >> reference it, one directly, the other seems to be just a comment. > > I'll try those down and make the necessary updates. > >> >> I also see that jhat looks for sun.misc.Ref in the heap. I guess >> someone could use a JDK 9 build and run jhat to look at a heap dump >> from a older JDK where sun.misc.Ref is used so maybe there is an >> argument to leaving this in. If you do then maybe it needs a comment. >> >> > > I'd prefer to remove sun.misc.Ref now and if it is a severe problem, > restore it later in JDK 9. > > Thanks for the review, > > -Joe > From david.holmes at oracle.com Wed Jan 22 01:56:45 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Jan 2014 11:56:45 +1000 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52DE9147.4030305@gmail.com> References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> <52CC72AB.2020104@oracle.com> <52CCEDE0.8000809@oracle.com> <52CCF079.4090301@oracle.com> <52CD45E7.7010203@gmail.com> <52CE4E2D.300@oracle.com> <52CF37C6.1070605@oracle.com> <52CFAFEB.9090703@gmail.com> <52CFD218.2060101@gmail.com> <52D06B70.60001@oracle.com> <52D15201.90109@gmail.com> <52D47D59.8040905@oracle.com> <52D72577.1050506@oracle.com> <52D76859.2030502@oracle.com> <52D82968.4030608@oracle.com> <52D8929B.2020905@oracle.com> <52D8A42A.4020906@oracle.com> <52D8B3B6.3030202@oracle.com> <52D9295D.6080106@gmail.com> <52D92C73.2020309@gmail.com> <52D92F1A.4040400@gmail.com> <52DC812C.1000607@oracle.com> <52DCD78E.8050404@gmail.com> <52DCE17B.4050708@gmail.com> <52DDD9F3.1050201@oracle.com> <52DE19C1.2070302@gmail.com> <52DE9147.4030305@gmail.com> Message-ID: <52DF255D.5000300@oracle.com> On 22/01/2014 1:24 AM, Peter Levart wrote: > On 01/21/2014 07:54 AM, Peter Levart wrote: >> *[Loaded sun.misc.Cleaner from >> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar]* >> [Loaded java.io.ByteArrayInputStream from >> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >> [Loaded sun.util.calendar.ZoneInfoFile$ZoneOffsetTransitionRule from >> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >> ... >> >> >> I'm on linux, 64bit and using official EA build 121 of JDK 8... >> >> But if I try with JDK 7u45, I don't see it. > > So what changed between JDK 7 and JDK 8? > > I suspect the following: 8007572: Replace existing jdk timezone data at > /lib/zi with JSR310's tzdb I suspect it also depends on your TZ environment too as I do not see this on my systems. David > > Regards, Peter > From david.holmes at oracle.com Wed Jan 22 01:59:13 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Jan 2014 11:59:13 +1000 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52DEF53C.3050905@gmail.com> References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> <52CC72AB.2020104@oracle.com> <52CCEDE0.8000809@oracle.com> <52CCF079.4090301@oracle.com> <52CD45E7.7010203@gmail.com> <52CE4E2D.300@oracle.com> <52CF37C6.1070605@oracle.com> <52CFAFEB.9090703@gmail.com> <52CFD218.2060101@gmail.com> <52D06B70.60001@oracle.com> <52D15201.90109@gmail.com> <52D47D59.8040905@oracle.com> <52D72577.1050506@oracle.com> <52D76859.2030502@oracle.com> <52D82968.4030608@oracle.com> <52D8929B.2020905@oracle.com> <52D8A42A.4020906@oracle.com> <52D8B3B6.3030202@oracle.com> <52D9295D.6080106@gmail.com> <52D92C73.2020309@gmail.com> <52D92F1A.4040400@gmail.com> <52DC812C.1000607@oracle.com> <52DCD78E.8050404@gmail.com> <52DCE17B.4050708@gmail.com> <52DDD9F3.1050201@oracle.com> <52DE19C1.2070302@gmail.com> <52DE9147.4030305@gmail.com> <52DEB9C4.4030606@oracle.com> <52DEF53C.3050905@gmail.com> Message-ID: <52DF25F1.1090903@oracle.com> On 22/01/2014 8:31 AM, Peter Levart wrote: > > On 01/21/2014 07:17 PM, srikalyan wrote: >> Hi Peter/David, catching up after long weekend. Why would there be an >> OOME in object heap due to class loading in perm gen space ? > > The perm gen is not a problem her (JDK 8 does not have it and we see > OOME on JDK8 too). Each time a class is loaded, new java.lang.Class > object is allocated on heap. For the bootloader classes I thought, but could easily be wrong, that the Class mirror did indeed go into the PermGen. But still this is not relevant on JDK8 where there is no PermGen. It maybe that changed as part of the early PermGen removal prep work that did go into 7u. David > Regards, Peter > >> Please correct if i am missing something here. Meanwhile i will give >> the version of Reference Handler you both agreed on a try. >> -- >> Thanks >> kalyan >> Ph: (408)-585-8040 >> >> On 1/21/14, 7:24 AM, Peter Levart wrote: >>> On 01/21/2014 07:54 AM, Peter Levart wrote: >>>> *[Loaded sun.misc.Cleaner from >>>> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar]* >>>> [Loaded java.io.ByteArrayInputStream from >>>> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >>>> [Loaded sun.util.calendar.ZoneInfoFile$ZoneOffsetTransitionRule from >>>> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >>>> ... >>>> >>>> >>>> I'm on linux, 64bit and using official EA build 121 of JDK 8... >>>> >>>> But if I try with JDK 7u45, I don't see it. >>> >>> So what changed between JDK 7 and JDK 8? >>> >>> I suspect the following: 8007572: Replace existing jdk timezone data >>> at /lib/zi with JSR310's tzdb >>> >>> >>> Regards, Peter >>> > From david.holmes at oracle.com Wed Jan 22 02:19:05 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Jan 2014 12:19:05 +1000 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52DE7D7A.80501@gmail.com> References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> <52CC72AB.2020104@oracle.com> <52CCEDE0.8000809@oracle.com> <52CCF079.4090301@oracle.com> <52CD45E7.7010203@gmail.com> <52CE4E2D.300@oracle.com> <52CF37C6.1070605@oracle.com> <52CFAFEB.9090703@gmail.com> <52CFD218.2060101@gmail.com> <52D06B70.60001@oracle.com> <52D15201.90109@gmail.com> <52D47D59.8040905@oracle.com> <52D72577.1050506@oracle.com> <52D76859.2030502@oracle.com> <52D82968.4030608@oracle.com> <52D8929B.2020905@oracle.com> <52D8A42A.4020906@oracle.com> <52D8B3B6.3030202@oracle.com> <52D9295D.6080106@gmail.com> <52D92C73.2020309@gmail.com> <52D92F1A.4040400@gmail.com> <52DC812C.1000607@oracle.com> <52DCD78E.8050404@gmail.com> <52DCE17B.4050708@gmail.com> <52DDD9F3.1050201@oracle.com> <52DE19C1.2070302@gmail.com> <52DE2883.5010100@oracle.com> <52DE7D7A.80501@gmail.com> Message-ID: <52DF2A99.6010805@oracle.com> Hi Peter, On 22/01/2014 12:00 AM, Peter Levart wrote: > Hi, David, Kalyan, > > Summing up the discussion, I propose the following patch for > ReferenceHandler: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/OOMEInReferenceHandler/webrev.01/ I can live with it, though it maybe that once Cleaner has been preloaded instanceof can no longer throw OOME. Can't be 100% sure. And there's some duplication/verbosity in the commentary that could be trimmed down :) Any specific reason to use Unsafe to do the preload rather than Class.forName ? Does this force Unsafe to be loaded earlier than it otherwise would? Thanks, David > > all 10 java/lang/ref tests pass on my PC (including > OOMEInReferenceHandler). > > I kindly ask Kalyan to try to re-run the OOMEInReferenceHandler test > with this code and report any failure. > > > Thanks, Peter > > On 01/21/2014 08:57 AM, David Holmes wrote: >> On 21/01/2014 4:54 PM, Peter Levart wrote: >>> >>> On 01/21/2014 03:22 AM, David Holmes wrote: >>>> Hi Peter, >>>> >>>> I do not see Cleaner being loaded prior to the main class on either >>>> Windows or Linux. Which platform are you on? Did you see it loaded >>>> before the main class or as part of executing it? >>> >>> Before. The main class is empty: >>> >>> public class Test { public static void main(String... a) {} } >>> >>> Here's last few lines of -verbose:class: >>> >>> [Loaded java.util.TimeZone from >>> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >>> [Loaded sun.util.calendar.ZoneInfo from >>> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >>> [Loaded sun.util.calendar.ZoneInfoFile from >>> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >>> [Loaded sun.util.calendar.ZoneInfoFile$1 from >>> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >>> [Loaded java.io.DataInput from >>> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >>> [Loaded java.io.DataInputStream from >>> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >>> *[Loaded sun.misc.Cleaner from >>> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar]* >> >> Curious. I wonder what the controlling factor is ?? >> >>> >>> I'm on linux, 64bit and using official EA build 121 of JDK 8... >>> >>> But if I try with JDK 7u45, I don't see it. So perhaps it would be good >>> to trigger Cleaner loading and initialization as part of >>> ReferenceHandler initialization to play things safe. >> >> >> If we do that for Cleaner we may as well do it for >> InterruptedException too. >> >>>> Also, it is not that I think ReferenceHandler is responsible for >>>> reporting OOME, but that it is responsible for reporting that it was >>>> unable to perform a clean or enqueue because of OOME. >>> >>> This would be necessary if we skipped a Reference because of OOME, but >>> if we just re-try until we eventually succeed, nothing is lost, nothing >>> to report (but a slow response)... >> >> Agreed - just trying to clarify things. >> >>>> >>>> Your suggested approach seems okay though I'm not sure why we >>>> shouldn't help things along by calling System.gc() ourselves rather >>>> than just yielding and hoping things will get cleaned up elsewhere. >>>> But for the present purposes your approach will suffice I think. >>> >>> Maybe my understanding is wrong but isn't the fact that OOME is rised a >>> consequence of that VM has already attempted to clear things up >>> (executing a GC round synchronously) but didn't succeed to make enough >>> free space to satisfy the allocation request? If this is only how some >>> collectors/allocators are implemented and not a general rule, then we >>> should put a System.gc() in place of Thread.yield(). Should we also >>> combine that with Thread.yield()? I'm concerned of a possibility that we >>> spin, consume too much CPU (ReferenceHandler thread has MAX priority) so >>> that other threads dont' get enough CPU time to proceed and clean things >>> up (we hope other threads will also get OOME and release things as their >>> stacks unwind...). >> >> You are probably right about the System.gc() - OOME should be thrown >> after GC fails to create space, so it really needs some other thread >> to drop live references to allow further space to be reclaimed. >> >> But note that Thread.yield() can behave badly on some linux systems >> too, so spinning is still a possibility - but either way this would >> only be "really bad" on a uniprocessor system where yield() is >> unlikely to misbehave. >> >> David >> ----- >> >>> >>> Regards, Peter >>> >>>> >>>> Thanks, >>>> David >>>> >>>> On 20/01/2014 6:42 PM, Peter Levart wrote: >>>>> On 01/20/2014 09:00 AM, Peter Levart wrote: >>>>>> On 01/20/2014 02:51 AM, David Holmes wrote: >>>>>>> Hi Peter, >>>>>>> >>>>>>> On 17/01/2014 11:24 PM, Peter Levart wrote: >>>>>>>> On 01/17/2014 02:13 PM, Peter Levart wrote: >>>>>>>>>>> // Fast path for cleaners >>>>>>>>>>> boolean isCleaner = false; >>>>>>>>>>> try { >>>>>>>>>>> isCleaner = r instanceof Cleaner; >>>>>>>>>>> } catch (OutofMemoryError oome) { >>>>>>>>>>> continue; >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> if (isCleaner) { >>>>>>>>>>> ((Cleaner)r).clean(); >>>>>>>>>>> continue; >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi David, Kalyan, >>>>>>>>>> >>>>>>>>>> I've caught-up now. Just thinking: is "instanceof Cleaner" >>>>>>>>>> throwing >>>>>>>>>> OOME as a result of loading the Cleaner class? Wouldn't the above >>>>>>>>>> code then throw some error also in ((Cleaner)r) - the checkcast, >>>>>>>>>> since Cleaner class would not be successfully initialized? >>>>>>>>> >>>>>>>>> Well, no. The above code would just skip Cleaner processing in >>>>>>>>> this >>>>>>>>> situation. And will never be doing it again after the heap is >>>>>>>>> freed... >>>>>>>>> So it might be good to load and initialize Cleaner class as >>>>>>>>> part of >>>>>>>>> ReferenceHandler initialization to ensure correct operation... >>>>>>>> >>>>>>>> Well, yes and no. Let me try once more: >>>>>>>> >>>>>>>> Above code will skip Cleaner processing if the 1st time "instanceof >>>>>>>> Cleaner" is executed, OOME is thrown as a consequence of full heap >>>>>>>> while >>>>>>>> loading and initializing the Cleaner class. >>>>>>> >>>>>>> Yes - I was assuming that this would not fail the very first time >>>>>>> and >>>>>>> so the Cleaner class would already be loaded. Failing to be able to >>>>>>> load the Cleaner class was one of the potential issues flagged >>>>>>> earlier with this problem. I was actually assuming that Cleaner >>>>>>> would >>>>>>> be loaded already due to some actual Cleaner subclasses being used, >>>>>>> but this does not happen as part of the default initialization. :( >>>>>>> The irony being that if the Cleaner class is not loaded then r can >>>>>>> not be an instance of Cleaner and so we would fail to load the class >>>>>>> in a case where we didn't need it anyway. >>>>>>> >>>>>>> What I wanted to focus on here was an OOME from the instanceof >>>>>>> itself, but as you say that might trigger classloading of Cleaner >>>>>>> (which is not what I was interested in). >>>>>>> >>>>>>>> The 2nd time the "instanceof >>>>>>>> Cleaner" is executed after such OOME, the same line would throw >>>>>>>> NoClassDefFoundError as a consequence of referencing a class that >>>>>>>> failed >>>>>>>> initialization. Am I right? >>>>>>> >>>>>>> instanceof is not one of the class initialization triggers, so we >>>>>>> should not see an OOME generated due to a class initialization >>>>>>> exception and so the class will not be put into the Erroneous state >>>>>>> and so subsequent attempts to use the class will not automatically >>>>>>> trigger NoClassdefFoundError. >>>>>>> >>>>>>> If OOME occurs during actual loading/linking of the class Cleaner it >>>>>>> is unclear what would happen on subsequent attempts. OOME is not a >>>>>>> LinkageError that must be rethrown on subsequent attempts, and it is >>>>>>> potentially a transient condition, so I would expect a re-load >>>>>>> attempt to be allowed. However we are now deep into the details of >>>>>>> the VM and it may well depend on the exact place from which the OOME >>>>>>> originates. >>>>>>> >>>>>>> The bottom line with the current problem is that there are multiple >>>>>>> non-obvious paths by which the ReferenceHandler can encounter an >>>>>>> OOME. In such cases we do not want the ReferenceHandler to terminate >>>>>>> - which implies catching the OOME and continuing. However we also do >>>>>>> not want to silently skip Cleaner processing or reference queue >>>>>>> processing - as that would lead to hard to diagnoze bugs. But trying >>>>>>> to report the problem may not be possible due to being >>>>>>> out-of-memory. >>>>>>> It may be that we need to break things up into multiple try/catch >>>>>>> blocks, where each catch does a System.gc() and then reports that >>>>>>> the >>>>>>> OOME occurred. Of course the reporting must still be in a try/catch >>>>>>> for the OOME. Though at some point letting the ReferenceHandler die >>>>>>> may be the only way to "report" a major memory problem. >>>>>>> >>>>>>> David >>>>>> >>>>>> Hm... If I give -verbose:class option to run a simple test program: >>>>>> >>>>>> public class Test { public static void main(String... a) {} } >>>>>> >>>>>> I see Cleaner class being loaded before Test class. I don't see by >>>>>> which tread or if it might get loaded after main() starts, but I >>>>>> suspect that loading of Cleaner is not a problem here. Initialization >>>>>> of Cleaner class is not performed by ReferenceHandler thread as you >>>>>> pointed out. The instanceof does not trigger it and if it returns >>>>>> true >>>>>> then Cleaner has already been initialized. So there must be some >>>>>> other >>>>>> cause for instanceof throwing OOME... >>>>>> >>>>>> What do you say about this variant of ReferenceHandler.run() method: >>>>>> >>>>>> public void run() { >>>>>> for (;;) { >>>>>> Reference r; >>>>>> Cleaner c; >>>>>> synchronized (lock) { >>>>>> r = pending; >>>>>> if (r != null) { >>>>>> // instanceof operator might throw OOME >>>>>> sometimes. Just retry after >>>>>> // yielding - might have better luck next >>>>>> time... >>>>>> try { >>>>>> c = r instanceof Cleaner ? (Cleaner) r : >>>>>> null; >>>>>> } catch (OutOfMemoryError x) { >>>>>> Thread.yield(); >>>>>> continue; >>>>>> } >>>>>> pending = r.discovered; >>>>>> r.discovered = null; >>>>>> } else { >>>>>> // The waiting on the lock may cause an OOME >>>>>> because it may try to allocate >>>>>> // exception objects, so also catch OOME here >>>>>> to avoid silent exit of the >>>>>> // reference handler thread. >>>>>> // >>>>>> // Explicitly define the order of the two >>>>>> exceptions we catch here >>>>>> // when waiting for the lock. >>>>>> // >>>>>> // We do not want to try to potentially load >>>>>> the InterruptedException class >>>>>> // (which would be done if this was its first >>>>>> use, and InterruptedException >>>>>> // were checked first) in this situation. >>>>>> // >>>>>> // This may lead to the VM not ever trying to >>>>>> load the InterruptedException >>>>>> // class again. >>>>>> try { >>>>>> try { >>>>>> lock.wait(); >>>>>> } catch (OutOfMemoryError x) { } >>>>>> } catch (InterruptedException x) { } >>>>>> continue; >>>>>> } >>>>>> } >>>>>> >>>>>> // Fast path for cleaners >>>>>> if (c != null) { >>>>>> c.clean(); >>>>>> continue; >>>>>> } >>>>>> >>>>>> ReferenceQueue q = r.queue; >>>>>> if (q != ReferenceQueue.NULL) q.enqueue(r); >>>>>> } >>>>>> } >>>>>> >>>>>> >>>>>> >>>>>> ... it tries to not consume and skip Cleaner instances when OOME is >>>>>> caught. >>>>>> >>>>>> I don't think ReferenceHandler is to make responsible for reporting >>>>>> OOMEs. Full heap is a global condition and ReferenceHandler is the >>>>>> last to accuse for it. >>>>>> >>>>>> Regards, Peter >>>>> >>>>> Hi David, >>>>> >>>>> I think the following variation is even better. It executes >>>>> Thread.yield() after catching OOME but outside synchronized block so >>>>> that given CPU slice can be used by GC threads to make progress >>>>> enqueueing pending References (they are not able to enqueue them while >>>>> ReferenceHandler is holding the lock): >>>>> >>>>> >>>>> public void run() { >>>>> for (;;) { >>>>> Reference r; >>>>> Cleaner c; >>>>> try { >>>>> try { >>>>> synchronized (lock) { >>>>> r = pending; >>>>> if (r != null) { >>>>> // 'instanceof' might throw OOME >>>>> sometimes so do this before >>>>> // unlinking 'r' from the 'pending' >>>>> chain... >>>>> c = r instanceof Cleaner ? >>>>> (Cleaner) r >>>>> : null; >>>>> // unlink 'r' from 'pending' chain >>>>> pending = r.discovered; >>>>> r.discovered = null; >>>>> } else { >>>>> // The waiting on the lock may >>>>> cause an >>>>> OOME because it may try to allocate >>>>> // exception objects. >>>>> lock.wait(); >>>>> continue; >>>>> } >>>>> } >>>>> } catch (OutOfMemoryError x) { >>>>> // Catch OOME from 'r instanceof Cleaner' or >>>>> 'lock.wait()' 1st so that we don't >>>>> // try to potentially load the >>>>> InterruptedException class >>>>> // (which would be done if this was its first >>>>> use, and InterruptedException >>>>> // were checked first) in this situation. >>>>> // Give other threads CPU time so they >>>>> hopefully release some objects and GC >>>>> // clears some heap. >>>>> // Also prevent CPU intensive spinning in >>>>> case >>>>> 'r instanceof Cleaner' above >>>>> // persistently throws OOME for some time... >>>>> Thread.yield(); >>>>> // retry >>>>> continue; >>>>> } >>>>> } catch (InterruptedException x) { >>>>> // Catch InterruptedException from 'lock.wait()' >>>>> and retry >>>>> continue; >>>>> } >>>>> >>>>> // Fast path for cleaners >>>>> if (c != null) { >>>>> c.clean(); >>>>> continue; >>>>> } >>>>> >>>>> ReferenceQueue q = r.queue; >>>>> if (q != ReferenceQueue.NULL) q.enqueue(r); >>>>> } >>>>> } >>>>> >>>>> >>>>> Regards, Peter >>>>> >>> > From Alan.Bateman at oracle.com Wed Jan 22 08:49:01 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 22 Jan 2014 08:49:01 +0000 Subject: JDK 9 RFR of 8032397: Remove sun.misc.Ref In-Reply-To: <52DF1C12.7000508@oracle.com> References: <52DEBC45.6080207@oracle.com> <52DEE05B.3030808@oracle.com> <52DEEAD4.1080901@oracle.com> <52DF1C12.7000508@oracle.com> Message-ID: <52DF85FD.6050902@oracle.com> On 22/01/2014 01:17, Joe Darcy wrote: > Hi Alan, > > Updated webrev at > > http://cr.openjdk.java.net/~darcy/8032397.1/ > > @see in sun.misc.Ref removed. > > Regression tests updated to not refer to sun.misc.Ref. > > I looked at the use of Ref in jhat and it is only used if > java.lang.ref.Reference is not found reflectively, so I think the > existing code can stay in place. Looks good to me. A minor comment on AppletImageRef is that url can be final. (My comment on jhat was just wondering whether the lookup of sun.misc.Ref should be removed or not. It's harmless of course and seems to a relic of the past). -Alan. From erik.joelsson at oracle.com Wed Jan 22 11:13:55 2014 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Wed, 22 Jan 2014 11:13:55 +0000 Subject: hg: jdk8/tl/jdk: 8032217: failure in man page processing Message-ID: <20140122111510.5171762655@hg.openjdk.java.net> Changeset: ff56039c4870 Author: erikj Date: 2014-01-22 12:13 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ff56039c4870 8032217: failure in man page processing Reviewed-by: dholmes, tbell ! make/Images.gmk From alexander.zuev at oracle.com Wed Jan 22 13:39:05 2014 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Wed, 22 Jan 2014 17:39:05 +0400 Subject: JDK9 RFR of JDK-8029646: [pack200] should support the new zip64 format. In-Reply-To: <52DE9C27.7020106@oracle.com> References: <52D57C2A.4010906@oracle.com> <52D61589.1090901@oracle.com> <52D69A9A.1010506@oracle.com> <52D69C5E.9020407@oracle.com> <52D6A2C1.2000802@oracle.com> <52D6C6B0.3020508@oracle.com> <52D8070A.8030804@oracle.com> <52DE9C27.7020106@oracle.com> Message-ID: <52DFC9F9.2010704@oracle.com> Kumar, see my notes inline. On 1/21/14 20:11, Kumar Srinivasan wrote: > Alex, > > Thanks for adding the test, few comments: > > PackTestZip64.java: > > 1. compareTwoFile, I would read the entire file into > ByteArrayInputStream, compare > the total first ie. fast fail, but what you have is also ok. I've tried the approach of reading the entire file into memory and it doesn't seem to speed up the process so much, so i'd left it as it is. > 2. generateLargeJar: I would replace lines 126,127 and 128 using > for-each loop, > by using Collections.list e); will make it more compact. Done. > 3. Though the test might not take too long on your system, I am > concerned it may > take too long on our Jprt system. I tested it on JPRT - there's no system on which test takes more than a minute - actually the longest test run time was on the solaris-sparc and it's 44 seconds, so it seems it's Ok. The updated webrev can be found at: http://cr.openjdk.java.net/~kizune/8029646/webrev.03 /Alex > Kumar > > > On 1/16/2014 8:21 AM, Alexander Zuev wrote: >> Sherman, Kumar, >> >> i have fixed the glitches you have found and changed the test so it >> creates a new jar >> based on the golden.jar content (to have a reasonable set of various >> data to start with), >> then adding to it 65536 empty files to test how we cope with such a >> huge jars. >> >> The testing time is less than a 30 seconds on my machine (not the >> top-of-the-line) so i >> decided not to bother with conditional testing, lets test our >> behavior every time in full. >> >> The updated webrev can be found at >> http://cr.openjdk.java.net/~kizune/8029646/webrev.02 >> >> /Alex >> >> On 1/15/14 21:34, Xueming Shen wrote: >>> On 1/15/14 7:01 AM, Alexander Zuev wrote: >>>> Hello, >>>> >>>> the new webrev with all the typos and comments fixed can be found >>>> at http://cr.openjdk.java.net/~kizune/8029646/webrev.01/ >>>> >>>> /Alex >>> >>> (1) jarmagic can be just a static constant somewhere or a stack >>> variable. not big deal though. >>> (2) the test only "tests" EOF for s. there is possibility that the >>> newly created has more extra >>> bytes at the end...though in theory this should not happen, it >>> might be better just add an >>> extra line to check the sizes of two first first? >>> (3) the rest of the change looks good, but I agreed with Kumar that >>> you may need to add a >>> regression test for a jar file with > 64k entries. otherwise >>> the code for zip64 end is not >>> being tested. the code looks fine, but I would trust a >>> regression test more than my eyes:-) >>> >>> Thanks! >>> -Sherman >> > From fweimer at redhat.com Wed Jan 22 13:57:20 2014 From: fweimer at redhat.com (Florian Weimer) Date: Wed, 22 Jan 2014 14:57:20 +0100 Subject: JEP 187: Serialization 2.0 In-Reply-To: <20140114002659.6AC0BD7C2@eggemoggin.niobe.net> References: <20140114002659.6AC0BD7C2@eggemoggin.niobe.net> Message-ID: <52DFCE40.4010108@redhat.com> On 01/14/2014 01:26 AM, mark.reinhold at oracle.com wrote: > Posted: http://openjdk.java.net/jeps/187 There's another aspect of the current approach to serialization that is not mentioned: the type information does not come from the calling context, but exclusively from the input stream. This means that all serializable classes can be instantiated, and not just those the context is prepared to deal with. I don't know if this is worth changing, but I do think it's something to consider. -- Florian Weimer / Red Hat Product Security Team From chris.hegarty at oracle.com Wed Jan 22 14:47:35 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 22 Jan 2014 14:47:35 +0000 Subject: JEP 187: Serialization 2.0 In-Reply-To: <52DFCE40.4010108@redhat.com> References: <20140114002659.6AC0BD7C2@eggemoggin.niobe.net> <52DFCE40.4010108@redhat.com> Message-ID: <52DFDA07.2020307@oracle.com> On 22/01/14 13:57, Florian Weimer wrote: > On 01/14/2014 01:26 AM, mark.reinhold at oracle.com wrote: >> Posted: http://openjdk.java.net/jeps/187 > > There's another aspect of the current approach to serialization that is > not mentioned: the type information does not come from the calling > context, but exclusively from the input stream. Have you overlooked resolveClass [1], or are you looking for additional context? -Chris. [1] http://download.java.net/jdk8/docs/api/java/io/ObjectInputStream.html#resolveClass-java.io.ObjectStreamClass- > This means that all > serializable classes can be instantiated, and not just those the context > is prepared to deal with. I don't know if this is worth changing, but I > do think it's something to consider. > From fweimer at redhat.com Wed Jan 22 15:14:34 2014 From: fweimer at redhat.com (Florian Weimer) Date: Wed, 22 Jan 2014 16:14:34 +0100 Subject: JEP 187: Serialization 2.0 In-Reply-To: <52DFDA07.2020307@oracle.com> References: <20140114002659.6AC0BD7C2@eggemoggin.niobe.net> <52DFCE40.4010108@redhat.com> <52DFDA07.2020307@oracle.com> Message-ID: <52DFE05A.40901@redhat.com> On 01/22/2014 03:47 PM, Chris Hegarty wrote: > On 22/01/14 13:57, Florian Weimer wrote: >> On 01/14/2014 01:26 AM, mark.reinhold at oracle.com wrote: >>> Posted: http://openjdk.java.net/jeps/187 >> >> There's another aspect of the current approach to serialization that is >> not mentioned: the type information does not come from the calling >> context, but exclusively from the input stream. > > Have you overlooked resolveClass [1], or are you looking for additional > context? I mean something slightly different, so here's a concrete example: Assume we are deserializing an instance of a class with a String field. The current framework deserializes whatever is in the input stream, and will bail out with a ClassCastException if the deserialized object turns out unusable. Contrast this with an alternative approach that uses the knowledge that the field String and will refuse to read anything else from the input stream. -- Florian Weimer / Red Hat Product Security Team From paul.sandoz at oracle.com Wed Jan 22 15:20:56 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 22 Jan 2014 16:20:56 +0100 Subject: RFR: JDK-8032012, , String.toLowerCase/toUpperCase performance improvement In-Reply-To: <52DEEF45.7060506@oracle.com> References: <52D82013.7020009@oracle.com> <52DEEF45.7060506@oracle.com> Message-ID: <3ACAF47E-0B56-4D17-B322-506EAB79A168@oracle.com> On Jan 21, 2014, at 11:05 PM, Xueming Shen wrote: > Hi Paul, thanks for reviewing the changeset, comment inlined below. > > On 01/20/2014 09:24 AM, Paul Sandoz wrote: >> >> Some quick comments. >> >> In String.toLowerCase: >> >> - it would be nice to get rid of the pseudo goto using the "scan" labelled block. >> > > webrev has been updated to remove the pseudo goto by checking the "first" against > "len" after the loop break. > Much for readable :-) >> - there is no need for the "localeDependent" local variable. >> > > I just tried to not throw away the result of this "localeDependent", which is still needed > in the toXCaseEx() methods. > if (lang == "tr" || lang == "az" || lang == "lt") { // local dependent return toLowerCaseEx(result, firstUpper, locale, true); } // otherwise false is passed to subsequent calls to toLowerCaseEx ? >> - you might be able to optimize by doing (could depend on the answer to the next point): >> >> int c = (int)value[i]; >> int lc = Character.toLowerCase(c); >> if (.....) { result[i] = (char)lc; } else { return toLowerCaseEx(result, i, locale, localeDependent); } >> >> - Do you need to check ERROR for the result of toLowerCase? >> >> 2586 if (c == Character.ERROR || >> > > Yes, Character.toLowerCase() should never return ERROR (while the package private > Character.toUpperCaseEx() will). In theory there is no need to check if the return > value of Character.toUpperCase(int) > min_supplementary_code_point in our loop, > because there is no bmp character returns a supplementary code point as its lower > case. But since it's a data driven mapping table, there is no guarantee the unicode > data table is not going to change in the "future", so I still keep the check. The webrev > has been updated to use one single "if" inside the loop. > > I have a "single if" implementation for the toUpperCase() as well, though don't sure > which one is better/faster :-) > OK, i suppose one could measure :-) Not sure how much it is worth obsessing over but... int c = (int)value[i]; if (c < '\u03A3') { result[i] = (char)Character.toLowerCase(c); // Is that safe? } else if (c < Character.MIN_HIGH_SURROGATE && c != 'u03A3' && (c = Character.toLowerCase(c)) < Character.MIN_SUPPLEMENTARY_CODE_POINT)) { result[i] = (char)c; } else { return toLowerCaseEx(result, i, locale, localeDependent); } or: int c = (int)value[i]; int lc = Character.toLowerCase(c); // is that safe? if (c < '\u03A3') { result[i] = (char)lc; } else if (c < Character.MIN_HIGH_SURROGATE && c != 'u03A3' && lc < Character.MIN_SUPPLEMENTARY_CODE_POINT)) { result[i] = (char)lc; } else { return toLowerCaseEx(result, i, locale, localeDependent); } or: int c = (int)value[i]; int lc = Character.toLowerCase(c); // is that safe? if (c < '\u03A3' || (c < Character.MIN_HIGH_SURROGATE && c != 'u03A3' && lc < Character.MIN_SUPPLEMENTARY_CODE_POINT))) { result[i] = (char)lc; } else { return toLowerCaseEx(result, i, locale, localeDependent); } FWIW i personally find those solutions easier to read, if they are safe w.r.t. Character.toLowerCase and that annoying greek character. Paul. > http://cr.openjdk.java.net/~sherman/8032012/ > > -Sherman > From david.lloyd at redhat.com Wed Jan 22 16:33:24 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 22 Jan 2014 10:33:24 -0600 Subject: JEP 187: Serialization 2.0 & Serialization-aware constructors In-Reply-To: <20140114002659.6AC0BD7C2@eggemoggin.niobe.net> References: <20140114002659.6AC0BD7C2@eggemoggin.niobe.net> Message-ID: <52DFF2D4.2050209@redhat.com> On 01/13/2014 06:26 PM, mark.reinhold at oracle.com wrote: > Posted: http://openjdk.java.net/jeps/187 The concept of explicit deserialization constructors is interesting and is something I've explored a little bit in the context of JBoss Marshalling. The way construction works today (simple version!), the framework will magic up a new Constructor instance which can construct a partially-initialized object. By "partially initialized" I mean, only the classes in the non-serializable "top half" of the class hierarchy are initialized, subclass-first like always. At this point it relies on the language constraints that require that the superclass be initialized as the first step (more or less) of construction, thus effectively reversing initialization order to be superclass-first. Now at this point there is an object that was (more or less) initialized from the top (Object) down to the last non-serializable class in the hierarchy (which is often also Object, as it happens). From here, the deserialization mechanism takes over, using stream information to acquire values and "stuff" them into fields (even final fields) using reflection, in superclass-first order. Some reflection magic makes sure that final field publication works more or less as expected; some other magic ensures that sensible action is taken for certain types of differences in the sending and receiving class structures. No initializers are ever invoked for these classes, though you can define a private readObject() method which is a close approximation (as long as you don't have final fields, else you're stuck using reflection too). The idea with a serialization-aware constructor is that each serializable class constructor can read the stream information itself and initialize fields the "normal" way, with "normal" validation. The simplest/most naive implementation of this is to simply pass in an ObjectInputStream to these constructors. This approach seems to work fairly well actually, from the user's perspective: each constructor calls to the superclass first, then it acquires (for example) a GetField object for itself and then pulls field data out of it and populates its real fields, much like a readObject() method might do. The problem here is that the actual serialization implementation normally gets to hook in between calls to readObject(); it cannot do this for constructors, because each constructor calls the superclass' immediately in a chain. The framework would have to examine the call stack to know who the actual caller is, and there is also the possibility that the constructors would abuse this contract in various ways, taking advantage of the framework's lack of control. In an ideal world (for serialization implementations anyway), constructors would be wholly isolated, which would allow the framework to call each one in sequence with only its safely isolated bit of the stream. But in the real world, this isn't really possible within the framework of the existing language. One concept that might be interesting would be to introduce such isolated instance initializers which do not call up to the superclass but which otherwise follow the general constructor contract. This would present a very simple solution from the perspective of serialization, though the complexity of such a solution is potentially great. Another option is to establish a tighter API which constructors can consume. The constructor would be able to read field information out of the API but only for its own class, possibly even enforced by call stack inspection. The constructor would be contractually obligated to propagate the API object to the superclass; the framework would have to enforce that the propagation happened correctly for the class hierarchy (which it would have knowledge of), i.e. ensure the object didn't "cheat" by calling a non-serialization constructor for a serializable superclass. Other ideas may be possible as well. I found this to be an interesting problem when I was exploring it myself, and I still find it pretty interesting. -- - DML From sean.coffey at oracle.com Wed Jan 22 17:07:22 2014 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Wed, 22 Jan 2014 17:07:22 +0000 Subject: RFR: 8030822: (tz) Support tzdata2013i In-Reply-To: <52DE737E.2030200@oracle.com> References: <52DE737E.2030200@oracle.com> Message-ID: <52DFFACA.9000208@oracle.com> Looks good to me Aleksej. Hopefully you can get a reviewer from the i18n dev team also. regards, Sean. On 21/01/14 13:17, Aleksej Efimov wrote: > Hi, > Can I have a review for 2013i timezone data integration [1] to JDK9. > There is one change in tzdb that affects naming for "Asia/Amman" > timezone: > "The Jordan switches back to standard time at 00:00 on December > 20, 2013." > All changes in TimeZoneNames*.java and TimeZoneNames*.properties files > are related to this one tzdb change. > > The list of executed regression test sets: test/sun/util/calendar > test/java/util/Calendar test/sun/util/resources/TimeZone > test/sun/util/calendar test/java/util/TimeZone test/java/time > test/java/util/Formatter test/closed/java/util/Calendar > test/closed/java/util/TimeZone > All tests gave PASS result. > > Webrev location: http://cr.openjdk.java.net/~aefimov/8030822/9/webrev.00/ > > Thank you, > Aleksej > > [1] https://bugs.openjdk.java.net/browse/JDK-8030822 From kumar.x.srinivasan at oracle.com Wed Jan 22 17:54:39 2014 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 22 Jan 2014 09:54:39 -0800 Subject: JDK9 RFR of JDK-8029646: [pack200] should support the new zip64 format. In-Reply-To: <52DFC9F9.2010704@oracle.com> References: <52D57C2A.4010906@oracle.com> <52D61589.1090901@oracle.com> <52D69A9A.1010506@oracle.com> <52D69C5E.9020407@oracle.com> <52D6A2C1.2000802@oracle.com> <52D6C6B0.3020508@oracle.com> <52D8070A.8030804@oracle.com> <52DE9C27.7020106@oracle.com> <52DFC9F9.2010704@oracle.com> Message-ID: <52E005DF.8030002@oracle.com> Alex, I am satisfied. Thanks Kumar > Kumar, > > see my notes inline. > > On 1/21/14 20:11, Kumar Srinivasan wrote: >> Alex, >> >> Thanks for adding the test, few comments: >> >> PackTestZip64.java: >> >> 1. compareTwoFile, I would read the entire file into >> ByteArrayInputStream, compare >> the total first ie. fast fail, but what you have is also ok. > I've tried the approach of reading the entire file into memory and it > doesn't seem to > speed up the process so much, so i'd left it as it is. >> 2. generateLargeJar: I would replace lines 126,127 and 128 using >> for-each loop, >> by using Collections.list e); will make it more compact. > Done. >> 3. Though the test might not take too long on your system, I am >> concerned it may >> take too long on our Jprt system. > I tested it on JPRT - there's no system on which test takes more than > a minute - actually > the longest test run time was on the solaris-sparc and it's 44 > seconds, so it seems it's Ok. > > The updated webrev can be found at: > http://cr.openjdk.java.net/~kizune/8029646/webrev.03 > > /Alex >> Kumar >> >> >> On 1/16/2014 8:21 AM, Alexander Zuev wrote: >>> Sherman, Kumar, >>> >>> i have fixed the glitches you have found and changed the test so >>> it creates a new jar >>> based on the golden.jar content (to have a reasonable set of various >>> data to start with), >>> then adding to it 65536 empty files to test how we cope with such a >>> huge jars. >>> >>> The testing time is less than a 30 seconds on my machine (not the >>> top-of-the-line) so i >>> decided not to bother with conditional testing, lets test our >>> behavior every time in full. >>> >>> The updated webrev can be found at >>> http://cr.openjdk.java.net/~kizune/8029646/webrev.02 >>> >>> /Alex >>> >>> On 1/15/14 21:34, Xueming Shen wrote: >>>> On 1/15/14 7:01 AM, Alexander Zuev wrote: >>>>> Hello, >>>>> >>>>> the new webrev with all the typos and comments fixed can be >>>>> found at http://cr.openjdk.java.net/~kizune/8029646/webrev.01/ >>>>> >>>>> /Alex >>>> >>>> (1) jarmagic can be just a static constant somewhere or a stack >>>> variable. not big deal though. >>>> (2) the test only "tests" EOF for s. there is possibility that the >>>> newly created has more extra >>>> bytes at the end...though in theory this should not happen, >>>> it might be better just add an >>>> extra line to check the sizes of two first first? >>>> (3) the rest of the change looks good, but I agreed with Kumar >>>> that you may need to add a >>>> regression test for a jar file with > 64k entries. otherwise >>>> the code for zip64 end is not >>>> being tested. the code looks fine, but I would trust a >>>> regression test more than my eyes:-) >>>> >>>> Thanks! >>>> -Sherman >>> >> > From roger.riggs at oracle.com Wed Jan 22 21:26:36 2014 From: roger.riggs at oracle.com (roger riggs) Date: Wed, 22 Jan 2014 16:26:36 -0500 Subject: RFR JDK 9: 8032502: java.time add @param tags to readObject Message-ID: <52E0378C.7020806@oracle.com> Please review this javadoc improvement to add @param tags to readObject Webrev: http://cr.openjdk.java.net/~rriggs/webrev-time-param-8032502/ Thanks, Roger From Lance.Andersen at oracle.com Wed Jan 22 21:31:22 2014 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Wed, 22 Jan 2014 16:31:22 -0500 Subject: RFR JDK 9: 8032502: java.time add @param tags to readObject In-Reply-To: <52E0378C.7020806@oracle.com> References: <52E0378C.7020806@oracle.com> Message-ID: looks fine Roger as am sure this will make the doclint warnings less On Jan 22, 2014, at 4:26 PM, roger riggs wrote: > Please review this javadoc improvement to add @param tags to readObject > > Webrev: > > http://cr.openjdk.java.net/~rriggs/webrev-time-param-8032502/ > > Thanks, Roger > -------------- next part -------------- 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 joe.darcy at oracle.com Wed Jan 22 21:33:17 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 22 Jan 2014 13:33:17 -0800 Subject: RFR JDK 9: 8032502: java.time add @param tags to readObject In-Reply-To: <52E0378C.7020806@oracle.com> References: <52E0378C.7020806@oracle.com> Message-ID: <52E0391D.6080602@oracle.com> On 01/22/2014 01:26 PM, roger riggs wrote: > Please review this javadoc improvement to add @param tags to readObject > > Webrev: > > http://cr.openjdk.java.net/~rriggs/webrev-time-param-8032502/ > > Thanks, Roger > Hi Roger, I'll approve this if you either * replace "ObjectInputStream" with "{@code ObjectInputStream} * replace "ObjectInputStream" with "stream" Cheers, -Joe From snazy at snazy.de Wed Jan 22 21:35:54 2014 From: snazy at snazy.de (Robert Stupp) Date: Wed, 22 Jan 2014 22:35:54 +0100 Subject: Aw: JEP 187: Serialization 2.0 & Serialization-aware constructors In-Reply-To: References: Message-ID: <62AB6B18-CF2D-4DE2-B9A6-CE466AB3D2F8@snazy.de> Am 22.01.2014 um 17:33 schrieb "David M. Lloyd" : > The concept of explicit deserialization constructors is interesting and is something I've explored a little bit in the context of JBoss Marshalling. ... > The idea with a serialization-aware constructor is that each serializable class constructor can read the stream information itself and initialize fields the "normal" way, with "normal" validation. I agree with David. One thing to think about might be to introduce a special kind of constructor by extending the JLS - to introduce a special "deserialization constructor" that behaves a bit different than "normal" constructors. Deserialization-constructors are called "top-down" (java.lang.Object first) - the deserialization code is responsible to call the deserialization-constructors for each individual class. The deserialization-constructor receives information only for deserialized fields that the class "owns" (not for fields of any superclass or subclass). But: deserialization-constructors should not be callable from "normal" code. Maybe there could be multiple "deserialization constructors" - one per serialVersionUID. This should completely eliminate "spaghetti code" in "readObject()" and the need for "readObject()" at all. Another idea is to introduce a kind of "protocol" how to deal with incompatible class changes or serial-version-uid mismatches. This gets important when existing applications grow: how shall a new field be initialized, when it's not present in input stream? Maybe this could be handled by the "deserialization constructor". Regarding the situation when an older implementation reads data from a newer implementation (with more fields or changed fields) ... I think that special situation cannot be handled. But it might be possible to serialize objects explicitly for older versions - for example if the implementation knows that it creating an RPC response for an older client. writeObject() could be replaced with "serialization methods" - multiple "serialization methods" could be used to address different versions. A new serialization framework should also add support for classes with "factory methods" like those with static "valueOf(...)" methods - maybe in combination to replace readResolve/writeReplace. Serialization should also respect immutable objects like String, Byte/Integer/Long/..., InetAddress, UUID - this reduces the serialized payload and amount of (unnecessary) objects during deserialization. Maybe serialization should move a bit deeper into the JVM itself - to optimize the reflection/unsafe stuff. IMHO the explicit serialFields support should not be supported for "serialization 2.0" - maybe I'm wrong, but I do not know any code that uses this (except some core JDK classes) - for me it looks like a workaround to deal with incompatible class changes. Transport and serialization might be separated in "serialization 2.0". Current OOS/OIS implementations perform a lot of System.arraycopy operations and allocate a lot of temporary objects (e.g. during string (de)serialization). It should be possible to "feed" deserialization with ByteBuffers - for example by using NIO. For example: the current internal "readPrimitives()" method could directly operate on a ByteBuffer without any copy operation - maybe with native support from the JVM. Robert From roger.riggs at oracle.com Wed Jan 22 21:39:35 2014 From: roger.riggs at oracle.com (roger riggs) Date: Wed, 22 Jan 2014 16:39:35 -0500 Subject: RFR JDK 9: 8032502: java.time add @param tags to readObject In-Reply-To: <52E0391D.6080602@oracle.com> References: <52E0378C.7020806@oracle.com> <52E0391D.6080602@oracle.com> Message-ID: <52E03A97.3090007@oracle.com> Thanks for the reminder Joe, I updated the webrev with the 2nd, shorter version. Roger On 1/22/2014 4:33 PM, Joe Darcy wrote: > On 01/22/2014 01:26 PM, roger riggs wrote: >> Please review this javadoc improvement to add @param tags to readObject >> >> Webrev: >> >> http://cr.openjdk.java.net/~rriggs/webrev-time-param-8032502/ >> >> Thanks, Roger >> > > Hi Roger, > > I'll approve this if you either > > * replace "ObjectInputStream" with "{@code > ObjectInputStream} > * replace "ObjectInputStream" with "stream" > > Cheers, > > -Joe From brent.christian at oracle.com Wed Jan 22 21:48:45 2014 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 22 Jan 2014 13:48:45 -0800 Subject: (7u backport) RFR: 7199674 - (props) user.home property does not return an accessible location in sandboxed environment [macosx] Message-ID: <52E03CBD.1070402@oracle.com> Hi, I would like to backport this fix from 8 to 7u. https://bugs.openjdk.java.net/browse/JDK-7199674 The source code changes apply cleanly to 7u from the 8 changeset, however the makefile changes needed to be tweaked. makefiles/CompileNativeLibraries.gmk did not exist in 7, so equivalent changes are made in make/java/java/Makefile instead. Since it's not a direct port of the 8 changes, my understanding is that the 7-specific changes should be reviewed. 7u40 webrev is here: http://cr.openjdk.java.net/~bchristi/7199674/7u/webrev.0/ Again, the only difference from the 8 fix is in make/java/java/Makefile. For reference: * JDK 8 changeset: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5f81a12fed4d * JDK 8 review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-September/020699.html Thanks, -Brent From joe.darcy at oracle.com Wed Jan 22 21:51:43 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 22 Jan 2014 13:51:43 -0800 Subject: RFR JDK 9: 8032502: java.time add @param tags to readObject In-Reply-To: <52E03A97.3090007@oracle.com> References: <52E0378C.7020806@oracle.com> <52E0391D.6080602@oracle.com> <52E03A97.3090007@oracle.com> Message-ID: <52E03D6F.3010005@oracle.com> On 01/22/2014 01:39 PM, roger riggs wrote: > Thanks for the reminder Joe, I updated the webrev with the 2nd, > shorter version. Ship it :-) -Joe > > Roger > > On 1/22/2014 4:33 PM, Joe Darcy wrote: >> On 01/22/2014 01:26 PM, roger riggs wrote: >>> Please review this javadoc improvement to add @param tags to readObject >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~rriggs/webrev-time-param-8032502/ >>> >>> Thanks, Roger >>> >> >> Hi Roger, >> >> I'll approve this if you either >> >> * replace "ObjectInputStream" with "{@code >> ObjectInputStream} >> * replace "ObjectInputStream" with "stream" >> >> Cheers, >> >> -Joe > From Ulf.Zibis at CoSoCo.de Wed Jan 22 22:10:56 2014 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Wed, 22 Jan 2014 23:10:56 +0100 Subject: RFR: JDK-8032012, , String.toLowerCase/toUpperCase performance improvement In-Reply-To: <3ACAF47E-0B56-4D17-B322-506EAB79A168@oracle.com> References: <52D82013.7020009@oracle.com> <52DEEF45.7060506@oracle.com> <3ACAF47E-0B56-4D17-B322-506EAB79A168@oracle.com> Message-ID: <52E041F0.8070804@CoSoCo.de> Am 22.01.2014 16:20, schrieb Paul Sandoz: > On Jan 21, 2014, at 11:05 PM, Xueming Shen wrote: >> On 01/20/2014 09:24 AM, Paul Sandoz wrote: >>> - it would be nice to get rid of the pseudo goto using the "scan" labelled block. >> webrev has been updated to remove the pseudo goto by checking the "first" against >> "len" after the loop break. > Much for readable :-) I think, you should compare the performance of both versions on modern + 32-bit CPUs. >>> - you might be able to optimize by doing (could depend on the answer to the next point): >>> >>> int c = (int)value[i]; >>> int lc = Character.toLowerCase(c); >>> if (.....) { result[i] = (char)lc; } else { return toLowerCaseEx(result, i, locale, localeDependent); } >>> >>> - Do you need to check ERROR for the result of toLowerCase? >>> >>> 2586 if (c == Character.ERROR || >>> >> Yes, Character.toLowerCase() should never return ERROR (while the package private >> Character.toUpperCaseEx() will). In theory there is no need to check if the return >> value of Character.toUpperCase(int) > min_supplementary_code_point in our loop, >> because there is no bmp character returns a supplementary code point as its lower >> case. But since it's a data driven mapping table, there is no guarantee the unicode >> data table is not going to change in the "future", so I still keep the check. In my opinion this check should be subject of JDK's build test, but not of runtime code. > or: > > int c = (int)value[i]; > int lc = Character.toLowerCase(c); // is that safe? > if (c < '\u03A3' || (c < Character.MIN_HIGH_SURROGATE && c != 'u03A3' && lc < Character.MIN_SUPPLEMENTARY_CODE_POINT))) { > result[i] = (char)lc; > } else { > return toLowerCaseEx(result, i, locale, localeDependent); > } > > FWIW i personally find those solutions easier to read, if they are safe w.r.t. Character.toLowerCase and that annoying greek character. I would like the 3rd version. -Ulf From snazy at snazy.de Wed Jan 22 22:11:59 2014 From: snazy at snazy.de (Robert Stupp) Date: Wed, 22 Jan 2014 23:11:59 +0100 Subject: ObjectIn/OutputStream improvements In-Reply-To: <1C96B28E-5E20-4D8D-B1FD-8FD5DF193EC8@oracle.com> References: <91644C57-6E0D-48ED-8E31-6AC217DECCEF@gmx.de> <1C96B28E-5E20-4D8D-B1FD-8FD5DF193EC8@oracle.com> Message-ID: <0F45AC34-B16C-4AA3-846A-43C93383FA6D@snazy.de> I found another location in OOS code that might be an optimization point: In java.io.ObjectOutputStream.BlockDataOutputStream#write(byte[], int, int, boolean) the first lines look like this: if (!(copy || blkmode)) { // write directly drain(); out.write(b, off, len); return; } The block is executed a lot and prevents effective buffering in the internal "byte[] buf" field. I've replaced it with if (!(copy || blkmode)) { // write directly if (len + pos <= MAX_BLOCK_SIZE) { System.arraycopy(b, off, buf, pos, len); pos += len; } else { drain(); out.write(b, off, len); } return; } and it works - at least for our application. I've no idea what that "if" was originally for. Another point of optimization would be to either introduce "readResolve()" in primitive wrapper classes (Boolean, Byte, Character, Short, Integer, Long) or add some support to handle primitive wrapper classes in java.io.ObjectInputStream#readOrdinaryObject. The current implementation creates new (senseless?) instances of these wrapper classes. This changes deserialization semantics (no distinct object references for those classes) - maybe it should be delayed to "serialization 2.0"? -Robert Am 07.01.2014 um 10:05 schrieb Chris Hegarty : > Did you attach the diffs? I don?t see any attachment, it may be that the attachment was stripped. Can you try resending inline? From snazy at snazy.de Wed Jan 22 22:37:16 2014 From: snazy at snazy.de (Robert Stupp) Date: Wed, 22 Jan 2014 23:37:16 +0100 Subject: Which optimizations does Hotspot apply? Message-ID: <09548E95-EA91-4986-A692-EC2DCE0944BB@snazy.de> Is there any documentation available which optimizations Hotspot can perform and what "collecting a garbage" object costs? I know that these are two completely different areas ;) I was inspecting whether the following code for (Object o : someArrayList) { ... } would be faster than for (int i=0, l=someArrayList.size(); i (forgot to include macosx-port-dev at openjdk.java.net) Hi, I would like to backport this fix from 8 to 7u. https://bugs.openjdk.java.net/browse/JDK-7199674 The source code changes apply cleanly to 7u from the 8 changeset, however the makefile changes needed to be tweaked. makefiles/CompileNativeLibraries.gmk did not exist in 7, so equivalent changes are made in make/java/java/Makefile instead. Since it's not a direct port of the 8 changes, my understanding is that the 7-specific changes should be reviewed. 7u40 webrev is here: http://cr.openjdk.java.net/~bchristi/7199674/7u/webrev.0/ Again, the only difference from the 8 fix is in make/java/java/Makefile. For reference: * JDK 8 changeset: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5f81a12fed4d * JDK 8 review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-September/020699.html Thanks, -Brent From vitalyd at gmail.com Wed Jan 22 22:55:17 2014 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 22 Jan 2014 17:55:17 -0500 Subject: Which optimizations does Hotspot apply? In-Reply-To: <09548E95-EA91-4986-A692-EC2DCE0944BB@snazy.de> References: <09548E95-EA91-4986-A692-EC2DCE0944BB@snazy.de> Message-ID: You can start here: wikis.oracle.com/display/hotspotinternals/performancetechniques Sent from my phone On Jan 22, 2014 5:37 PM, "Robert Stupp" wrote: > Is there any documentation available which optimizations Hotspot can > perform and what "collecting a garbage" object costs? > I know that these are two completely different areas ;) > > I was inspecting whether the following code > for (Object o : someArrayList) { ... } > would be faster than > for (int i=0, l=someArrayList.size(); i o=someArrayList.get(i); } > for RandomAccessList implementations. The challenge here is not just to > track the CPU time spent creating & using the iterator vs. size() & get() > calls but also track GC effort (which is at least complicated if not > impossible due to the variety of GC configuration options). > > For example: > - Does it help Hotspot to declare parameters/variables as "final" or can > Hotspot identify that? > - When does Hotspot inline method calls in general and getters/setters > especially? > > I think such a piece of documentation (just what Hotspot can do in which > release) would be really helpful when someone tries to optimize code - want > to say: the question is: "Is something worth to spend time on or is this > special situation handled by Hotspot?" > > -Robert From mandy.chung at oracle.com Wed Jan 22 23:12:09 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 22 Jan 2014 15:12:09 -0800 Subject: JDK 9 RFR of 8032397: Remove sun.misc.Ref In-Reply-To: <52DF1C12.7000508@oracle.com> References: <52DEBC45.6080207@oracle.com> <52DEE05B.3030808@oracle.com> <52DEEAD4.1080901@oracle.com> <52DF1C12.7000508@oracle.com> Message-ID: <52E05049.9050302@oracle.com> On 1/21/2014 5:17 PM, Joe Darcy wrote: > Hi Alan, > > Updated webrev at > > http://cr.openjdk.java.net/~darcy/8032397.1/ > Looks good to me. > @see in sun.misc.Ref removed. > > Regression tests updated to not refer to sun.misc.Ref. > > I looked at the use of Ref in jhat and it is only used if > java.lang.ref.Reference is not found reflectively, so I think the > existing code can stay in place. > I think it's actually better to update jhat and take out the fallback to lookup sun.misc.Ref class as it was there to handle 1.1.x heap dump so that sun.misc.Ref is "entirely" removed. Mandy From forax at univ-mlv.fr Wed Jan 22 23:37:36 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 23 Jan 2014 00:37:36 +0100 Subject: Which optimizations does Hotspot apply? In-Reply-To: <09548E95-EA91-4986-A692-EC2DCE0944BB@snazy.de> References: <09548E95-EA91-4986-A692-EC2DCE0944BB@snazy.de> Message-ID: <52E05640.3020000@univ-mlv.fr> On 01/22/2014 11:37 PM, Robert Stupp wrote: > Is there any documentation available which optimizations Hotspot can perform and what "collecting a garbage" object costs? > I know that these are two completely different areas ;) > > I was inspecting whether the following code > for (Object o : someArrayList) { ... } > would be faster than > for (int i=0, l=someArrayList.size(); i for RandomAccessList implementations. The challenge here is not just to track the CPU time spent creating & using the iterator vs. size() & get() calls but also track GC effort (which is at least complicated if not impossible due to the variety of GC configuration options). For a long time, using a for with an index (if you are *sure* that it's an ArrayList) was faster. With latest jdk8, it's not true anymore. (and most of the time the iterator object is not created anymore at least with jdk7+). > > For example: > - Does it help Hotspot to declare parameters/variables as "final" or can Hotspot identify that? no, it's an urban myth. You can test it by yourself, if you declare a local variable final or not the exact same bytecode is produced by javac. The keyword final for a local variable (or a parameter) is not stored in the bytecode. BTW, final was introduced in 1.1 mostly to allow to capture the value of a variable to be used by an anonymous class, Java 8 doesn't require this kind of variable to be declared final anymore. > - When does Hotspot inline method calls in general and getters/setters especially? In general, up to a depth of 10 by default and 1 for a recursive method. Roughly, a method call is not inlined either if the call is virtual and can call too many implementations or if the generated assembly code will be too big. > > I think such a piece of documentation (just what Hotspot can do in which release) would be really helpful when someone tries to optimize code - want to say: the question is: "Is something worth to spend time on or is this special situation handled by Hotspot?" It never worth it. Choose the right algorithms and shape your data to be easily consumed by your algorithms is enough. > > -Robert R?mi From vladimir.kozlov at oracle.com Wed Jan 22 23:53:03 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Jan 2014 15:53:03 -0800 Subject: Problem to build jdk on Mac OS X from ppc64 stage after sync with jdk9 Message-ID: <52E059DF.50600@oracle.com> I need help. I am trying to do control build in JPRT after I merged latest jdk9 source: http://hg.openjdk.java.net/jdk9/jdk9 to latest ppc64 sources: http://hg.openjdk.java.net/ppc-aix-port/stage-9 I have build failure on Mac OS X (on other platforms it passed). See the output below. I tried different JPRT queues - the same problem. During sync I had to merge common/autoconf/toolchain.m4 (merged automatically) and regenerate generated-configure.sh. The latest changes to toolchain.m4 was: http://hg.openjdk.java.net/jdk9/jdk9/rev/50669e45cec4 Next jdk files merge was resolved automatically: merging make/CompileDemos.gmk merging src/solaris/bin/java_md_solinux.c merging test/ProblemList.txt merging test/tools/launcher/ExecutionEnvironment.java 291 files updated, 4 files merged, 14 files removed, 0 files unresolved Thanks, Vladimir The build failure on Mac OS X: Cleaning up: /opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/src Outputting classes to: /opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/src Searching for bridged frameworks in: /opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/bridge found 3 frameworks Parsing XML Exception in thread "main" java.lang.UnsatisfiedLinkError: no JObjC in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1857) at java.lang.Runtime.loadLibrary0(Runtime.java:870) at java.lang.System.loadLibrary(System.java:1119) at com.apple.jobjc.Coder.(Coder.java:60) at com.apple.internal.jobjc.generator.model.coders.CoderDescriptor.(CoderDescriptor.java:38) at com.apple.internal.jobjc.generator.model.types.NType$NPrimitive.(NType.java:117) at com.apple.internal.jobjc.generator.model.types.Type.(Type.java:57) at com.apple.internal.jobjc.generator.model.Element.(Element.java:47) at com.apple.internal.jobjc.generator.model.Framework.(Framework.java:99) at com.apple.internal.jobjc.generator.FrameworkGenerator.parseFrameworksFrom(FrameworkGenerator.java:56) at com.apple.internal.jobjc.generator.Generator.main(Generator.java:57) make[2]: *** [/opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/_the.generator] Error 1 make[1]: *** [gensrc-only] Error 2 make: *** [jdk-only] Error 2 From sean.mullan at oracle.com Thu Jan 23 00:12:58 2014 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Thu, 23 Jan 2014 00:12:58 +0000 Subject: hg: jdk8/tl/jdk: 8031825: OCSP client can't find responder cert if it uses a different subject key id algorithm than responderID Message-ID: <20140123001311.1048B6269C@hg.openjdk.java.net> Changeset: 57c26829deb6 Author: mullan Date: 2014-01-22 19:06 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/57c26829deb6 8031825: OCSP client can't find responder cert if it uses a different subject key id algorithm than responderID Reviewed-by: vinnie, xuelei ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java From henry.jen at oracle.com Thu Jan 23 00:18:22 2014 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 22 Jan 2014 16:18:22 -0800 Subject: Problem to build jdk on Mac OS X from ppc64 stage after sync with jdk9 In-Reply-To: <52E059DF.50600@oracle.com> References: <52E059DF.50600@oracle.com> Message-ID: <52E05FCE.1040901@oracle.com> I haven't tried this, but Tim Bell mentioned this in an email inquiry I had earlier, > This will be cured when the fix for 8021266 is pushed to JDK 9 (see > attached). > > In the meantime, the workaround in JPRT is to submit your JDK 9 jobs > with '-bootproduct jdk7u7' since the 7u51 release can not serve as a > boot JDK. Cheers, Henry On 01/22/2014 03:53 PM, Vladimir Kozlov wrote: > I need help. > > I am trying to do control build in JPRT after I merged latest jdk9 source: > > http://hg.openjdk.java.net/jdk9/jdk9 > > to latest ppc64 sources: > > http://hg.openjdk.java.net/ppc-aix-port/stage-9 > > I have build failure on Mac OS X (on other platforms it passed). See the > output below. I tried different JPRT queues - the same problem. > > During sync I had to merge common/autoconf/toolchain.m4 (merged > automatically) and regenerate generated-configure.sh. > > The latest changes to toolchain.m4 was: > > http://hg.openjdk.java.net/jdk9/jdk9/rev/50669e45cec4 > > Next jdk files merge was resolved automatically: > > merging make/CompileDemos.gmk > merging src/solaris/bin/java_md_solinux.c > merging test/ProblemList.txt > merging test/tools/launcher/ExecutionEnvironment.java > 291 files updated, 4 files merged, 14 files removed, 0 files unresolved > > Thanks, > Vladimir > > The build failure on Mac OS X: > > Cleaning up: > /opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/src > > Outputting classes to: > /opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/src > > Searching for bridged frameworks in: > /opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/bridge > > found 3 frameworks > Parsing XML > Exception in thread "main" java.lang.UnsatisfiedLinkError: no JObjC in > java.library.path > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1857) > at java.lang.Runtime.loadLibrary0(Runtime.java:870) > at java.lang.System.loadLibrary(System.java:1119) > at com.apple.jobjc.Coder.(Coder.java:60) > at > com.apple.internal.jobjc.generator.model.coders.CoderDescriptor.(CoderDescriptor.java:38) > > at > com.apple.internal.jobjc.generator.model.types.NType$NPrimitive.(NType.java:117) > > at > com.apple.internal.jobjc.generator.model.types.Type.(Type.java:57) > at > com.apple.internal.jobjc.generator.model.Element.(Element.java:47) > at > com.apple.internal.jobjc.generator.model.Framework.(Framework.java:99) > > at > com.apple.internal.jobjc.generator.FrameworkGenerator.parseFrameworksFrom(FrameworkGenerator.java:56) > > at > com.apple.internal.jobjc.generator.Generator.main(Generator.java:57) > make[2]: *** > [/opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/_the.generator] > Error 1 > make[1]: *** [gensrc-only] Error 2 > make: *** [jdk-only] Error 2 From vitalyd at gmail.com Thu Jan 23 00:39:36 2014 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 22 Jan 2014 19:39:36 -0500 Subject: Which optimizations does Hotspot apply? In-Reply-To: <52E05640.3020000@univ-mlv.fr> References: <09548E95-EA91-4986-A692-EC2DCE0944BB@snazy.de> <52E05640.3020000@univ-mlv.fr> Message-ID: Remi, Regarding your last point - picking correct data structures and algos is of course step 1 in any optimization. But, provided that's taken care of, there're plausible reasons to attempt to cater to hotspot as well (if that's the jvm in use). There are certainly code shapes that it prefers. There's a whole slew of inlining heuristics and rules to be aware of. There's a set of intrinsics, in some cases covering only a subset of an API of a class. These things are always subject to change, but saying "never worth it" isn't right either :). Sent from my phone On Jan 22, 2014 6:38 PM, "Remi Forax" wrote: > On 01/22/2014 11:37 PM, Robert Stupp wrote: > >> Is there any documentation available which optimizations Hotspot can >> perform and what "collecting a garbage" object costs? >> I know that these are two completely different areas ;) >> >> I was inspecting whether the following code >> for (Object o : someArrayList) { ... } >> would be faster than >> for (int i=0, l=someArrayList.size(); i> o=someArrayList.get(i); } >> for RandomAccessList implementations. The challenge here is not just to >> track the CPU time spent creating & using the iterator vs. size() & get() >> calls but also track GC effort (which is at least complicated if not >> impossible due to the variety of GC configuration options). >> > > For a long time, using a for with an index (if you are *sure* that it's an > ArrayList) was faster. > With latest jdk8, it's not true anymore. > (and most of the time the iterator object is not created anymore at least > with jdk7+). > > >> For example: >> - Does it help Hotspot to declare parameters/variables as "final" or can >> Hotspot identify that? >> > > no, it's an urban myth. > You can test it by yourself, if you declare a local variable final or not > the exact same bytecode is produced by javac. The keyword final for a local > variable (or a parameter) is not stored in the bytecode. > > BTW, final was introduced in 1.1 mostly to allow to capture the value of a > variable to be used by an anonymous class, Java 8 doesn't require this kind > of variable to be declared final anymore. > > - When does Hotspot inline method calls in general and getters/setters >> especially? >> > > In general, up to a depth of 10 by default and 1 for a recursive method. > Roughly, a method call is not inlined either if the call is virtual and > can call too many implementations or if the generated assembly code will be > too big. > > >> I think such a piece of documentation (just what Hotspot can do in which >> release) would be really helpful when someone tries to optimize code - want >> to say: the question is: "Is something worth to spend time on or is this >> special situation handled by Hotspot?" >> > > It never worth it. > Choose the right algorithms and shape your data to be easily consumed by > your algorithms is enough. > > >> -Robert >> > > R?mi > > From vladimir.kozlov at oracle.com Thu Jan 23 01:17:51 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Jan 2014 17:17:51 -0800 Subject: Problem to build jdk on Mac OS X from ppc64 stage after sync with jdk9 In-Reply-To: <52E05FCE.1040901@oracle.com> References: <52E059DF.50600@oracle.com> <52E05FCE.1040901@oracle.com> Message-ID: <52E06DBF.2020000@oracle.com> Thank you very much, Henry The suggested workaround helped! Thanks, Vladimir On 1/22/14 4:18 PM, Henry Jen wrote: > I haven't tried this, but Tim Bell mentioned this in an email inquiry I > had earlier, > >> This will be cured when the fix for 8021266 is pushed to JDK 9 (see >> attached). >> >> In the meantime, the workaround in JPRT is to submit your JDK 9 jobs >> with '-bootproduct jdk7u7' since the 7u51 release can not serve as a >> boot JDK. > > Cheers, > Henry > > > On 01/22/2014 03:53 PM, Vladimir Kozlov wrote: >> I need help. >> >> I am trying to do control build in JPRT after I merged latest jdk9 >> source: >> >> http://hg.openjdk.java.net/jdk9/jdk9 >> >> to latest ppc64 sources: >> >> http://hg.openjdk.java.net/ppc-aix-port/stage-9 >> >> I have build failure on Mac OS X (on other platforms it passed). See the >> output below. I tried different JPRT queues - the same problem. >> >> During sync I had to merge common/autoconf/toolchain.m4 (merged >> automatically) and regenerate generated-configure.sh. >> >> The latest changes to toolchain.m4 was: >> >> http://hg.openjdk.java.net/jdk9/jdk9/rev/50669e45cec4 >> >> Next jdk files merge was resolved automatically: >> >> merging make/CompileDemos.gmk >> merging src/solaris/bin/java_md_solinux.c >> merging test/ProblemList.txt >> merging test/tools/launcher/ExecutionEnvironment.java >> 291 files updated, 4 files merged, 14 files removed, 0 files unresolved >> >> Thanks, >> Vladimir >> >> The build failure on Mac OS X: >> >> Cleaning up: >> /opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/src >> >> >> Outputting classes to: >> /opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/src >> >> >> Searching for bridged frameworks in: >> /opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/bridge >> >> >> found 3 frameworks >> Parsing XML >> Exception in thread "main" java.lang.UnsatisfiedLinkError: no JObjC in >> java.library.path >> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1857) >> at java.lang.Runtime.loadLibrary0(Runtime.java:870) >> at java.lang.System.loadLibrary(System.java:1119) >> at com.apple.jobjc.Coder.(Coder.java:60) >> at >> com.apple.internal.jobjc.generator.model.coders.CoderDescriptor.(CoderDescriptor.java:38) >> >> >> at >> com.apple.internal.jobjc.generator.model.types.NType$NPrimitive.(NType.java:117) >> >> >> at >> com.apple.internal.jobjc.generator.model.types.Type.(Type.java:57) >> >> at >> com.apple.internal.jobjc.generator.model.Element.(Element.java:47) >> at >> com.apple.internal.jobjc.generator.model.Framework.(Framework.java:99) >> >> >> at >> com.apple.internal.jobjc.generator.FrameworkGenerator.parseFrameworksFrom(FrameworkGenerator.java:56) >> >> >> at >> com.apple.internal.jobjc.generator.Generator.main(Generator.java:57) >> make[2]: *** >> [/opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/_the.generator] >> >> Error 1 >> make[1]: *** [gensrc-only] Error 2 >> make: *** [jdk-only] Error 2 From masayoshi.okutsu at oracle.com Thu Jan 23 04:43:21 2014 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Thu, 23 Jan 2014 13:43:21 +0900 Subject: RFR: 8030822: (tz) Support tzdata2013i In-Reply-To: <52DE737E.2030200@oracle.com> References: <52DE737E.2030200@oracle.com> Message-ID: <52E09DE9.20300@oracle.com> Hi Aleksej, I think this one is the first tzdata change for JDK9. So I'd suggest that all the TimeZoneNames*.properties files, which were temporarily created for the translation work, be removed. Thanks, Masayoshi On 1/21/2014 10:17 PM, Aleksej Efimov wrote: > Hi, > Can I have a review for 2013i timezone data integration [1] to JDK9. > There is one change in tzdb that affects naming for "Asia/Amman" > timezone: > "The Jordan switches back to standard time at 00:00 on December > 20, 2013." > All changes in TimeZoneNames*.java and TimeZoneNames*.properties files > are related to this one tzdb change. > > The list of executed regression test sets: test/sun/util/calendar > test/java/util/Calendar test/sun/util/resources/TimeZone > test/sun/util/calendar test/java/util/TimeZone test/java/time > test/java/util/Formatter test/closed/java/util/Calendar > test/closed/java/util/TimeZone > All tests gave PASS result. > > Webrev location: http://cr.openjdk.java.net/~aefimov/8030822/9/webrev.00/ > > Thank you, > Aleksej > > [1] https://bugs.openjdk.java.net/browse/JDK-8030822 From volker.simonis at gmail.com Thu Jan 23 08:22:39 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 23 Jan 2014 09:22:39 +0100 Subject: Problem to build jdk on Mac OS X from ppc64 stage after sync with jdk9 In-Reply-To: <52E05FCE.1040901@oracle.com> References: <52E059DF.50600@oracle.com> <52E05FCE.1040901@oracle.com> Message-ID: Hi, I've reported this last week on the build-dev list ("Build error on Mac with 7u51 boot jdk because JObjC.jar was removed from 7u51", http://mail.openjdk.java.net/pipermail/build-dev/2014-January/011566.html), but didn't get any answer yet. The only workaround seems to be to use an older boot JDK as already mentioned by Henry. Unfortunately the problem is a little obscure because both, 8021271 which caused the problem as well as 8021266 which according to Henry will solve the problem are not visible because they are considered "security relevant". Regards, Volker On Thu, Jan 23, 2014 at 1:18 AM, Henry Jen wrote: > I haven't tried this, but Tim Bell mentioned this in an email inquiry I had > earlier, > >> This will be cured when the fix for 8021266 is pushed to JDK 9 (see >> attached). >> >> In the meantime, the workaround in JPRT is to submit your JDK 9 jobs >> with '-bootproduct jdk7u7' since the 7u51 release can not serve as a >> boot JDK. > > > Cheers, > Henry > > > > On 01/22/2014 03:53 PM, Vladimir Kozlov wrote: >> >> I need help. >> >> I am trying to do control build in JPRT after I merged latest jdk9 source: >> >> http://hg.openjdk.java.net/jdk9/jdk9 >> >> to latest ppc64 sources: >> >> http://hg.openjdk.java.net/ppc-aix-port/stage-9 >> >> I have build failure on Mac OS X (on other platforms it passed). See the >> output below. I tried different JPRT queues - the same problem. >> >> During sync I had to merge common/autoconf/toolchain.m4 (merged >> automatically) and regenerate generated-configure.sh. >> >> The latest changes to toolchain.m4 was: >> >> http://hg.openjdk.java.net/jdk9/jdk9/rev/50669e45cec4 >> >> Next jdk files merge was resolved automatically: >> >> merging make/CompileDemos.gmk >> merging src/solaris/bin/java_md_solinux.c >> merging test/ProblemList.txt >> merging test/tools/launcher/ExecutionEnvironment.java >> 291 files updated, 4 files merged, 14 files removed, 0 files unresolved >> >> Thanks, >> Vladimir >> >> The build failure on Mac OS X: >> >> Cleaning up: >> >> /opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/src >> >> Outputting classes to: >> >> /opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/src >> >> Searching for bridged frameworks in: >> >> /opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/bridge >> >> found 3 frameworks >> Parsing XML >> Exception in thread "main" java.lang.UnsatisfiedLinkError: no JObjC in >> java.library.path >> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1857) >> at java.lang.Runtime.loadLibrary0(Runtime.java:870) >> at java.lang.System.loadLibrary(System.java:1119) >> at com.apple.jobjc.Coder.(Coder.java:60) >> at >> >> com.apple.internal.jobjc.generator.model.coders.CoderDescriptor.(CoderDescriptor.java:38) >> >> at >> >> com.apple.internal.jobjc.generator.model.types.NType$NPrimitive.(NType.java:117) >> >> at >> com.apple.internal.jobjc.generator.model.types.Type.(Type.java:57) >> at >> com.apple.internal.jobjc.generator.model.Element.(Element.java:47) >> at >> >> com.apple.internal.jobjc.generator.model.Framework.(Framework.java:99) >> >> at >> >> com.apple.internal.jobjc.generator.FrameworkGenerator.parseFrameworksFrom(FrameworkGenerator.java:56) >> >> at >> com.apple.internal.jobjc.generator.Generator.main(Generator.java:57) >> make[2]: *** >> >> [/opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/_the.generator] >> Error 1 >> make[1]: *** [gensrc-only] Error 2 >> make: *** [jdk-only] Error 2 From Sergey.Bylokhov at oracle.com Thu Jan 23 08:32:37 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 23 Jan 2014 12:32:37 +0400 Subject: Problem to build jdk on Mac OS X from ppc64 stage after sync with jdk9 In-Reply-To: <52E059DF.50600@oracle.com> References: <52E059DF.50600@oracle.com> Message-ID: <52E0D3A5.7050100@oracle.com> On 23.01.2014 3:53, Vladimir Kozlov wrote: > I need help. > > I am trying to do control build in JPRT after I merged latest jdk9 > source: > > http://hg.openjdk.java.net/jdk9/jdk9 Looks like the problem is that 8032348 is not pushed to the master workspace of jdk9, but the bootjdk have this fix. > > to latest ppc64 sources: > > http://hg.openjdk.java.net/ppc-aix-port/stage-9 > > I have build failure on Mac OS X (on other platforms it passed). See > the output below. I tried different JPRT queues - the same problem. > > During sync I had to merge common/autoconf/toolchain.m4 (merged > automatically) and regenerate generated-configure.sh. > > The latest changes to toolchain.m4 was: > > http://hg.openjdk.java.net/jdk9/jdk9/rev/50669e45cec4 > > Next jdk files merge was resolved automatically: > > merging make/CompileDemos.gmk > merging src/solaris/bin/java_md_solinux.c > merging test/ProblemList.txt > merging test/tools/launcher/ExecutionEnvironment.java > 291 files updated, 4 files merged, 14 files removed, 0 files unresolved > > Thanks, > Vladimir > > The build failure on Mac OS X: > > Cleaning up: > /opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/src > Outputting classes to: > /opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/src > Searching for bridged frameworks in: > /opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/bridge > found 3 frameworks > Parsing XML > Exception in thread "main" java.lang.UnsatisfiedLinkError: no JObjC in > java.library.path > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1857) > at java.lang.Runtime.loadLibrary0(Runtime.java:870) > at java.lang.System.loadLibrary(System.java:1119) > at com.apple.jobjc.Coder.(Coder.java:60) > at > com.apple.internal.jobjc.generator.model.coders.CoderDescriptor.(CoderDescriptor.java:38) > at > com.apple.internal.jobjc.generator.model.types.NType$NPrimitive.(NType.java:117) > at > com.apple.internal.jobjc.generator.model.types.Type.(Type.java:57) > at > com.apple.internal.jobjc.generator.model.Element.(Element.java:47) > at > com.apple.internal.jobjc.generator.model.Framework.(Framework.java:99) > at > com.apple.internal.jobjc.generator.FrameworkGenerator.parseFrameworksFrom(FrameworkGenerator.java:56) > at > com.apple.internal.jobjc.generator.Generator.main(Generator.java:57) > make[2]: *** > [/opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/_the.generator] > Error 1 > make[1]: *** [gensrc-only] Error 2 > make: *** [jdk-only] Error 2 -- Best regards, Sergey. From erik.joelsson at oracle.com Thu Jan 23 08:43:10 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 23 Jan 2014 09:43:10 +0100 Subject: Problem to build jdk on Mac OS X from ppc64 stage after sync with jdk9 In-Reply-To: <52E0D3A5.7050100@oracle.com> References: <52E059DF.50600@oracle.com> <52E0D3A5.7050100@oracle.com> Message-ID: <52E0D61E.4090100@oracle.com> On 2014-01-23 09:32, Sergey Bylokhov wrote: > On 23.01.2014 3:53, Vladimir Kozlov wrote: >> I need help. >> >> I am trying to do control build in JPRT after I merged latest jdk9 >> source: >> >> http://hg.openjdk.java.net/jdk9/jdk9 > Looks like the problem is that 8032348 is not pushed to the master > workspace of jdk9, but the bootjdk have this fix. This is correct. The bootjdk in this case is the latest build of jdk8, which has the fix. As soon as the fix is pushed to 9, this will resolve itself. /Erik From martin.grebac at oracle.com Thu Jan 23 08:53:22 2014 From: martin.grebac at oracle.com (Martin Grebac) Date: Thu, 23 Jan 2014 09:53:22 +0100 Subject: JDK8 RFR JDK-8029237 Update copyright year to match last edit in jdk8 jaxws repository for 2013 In-Reply-To: <52D8FE89.9080603@oracle.com> References: <52D0286B.9020108@oracle.com> <52D8FE89.9080603@oracle.com> Message-ID: <52E0D882.2060904@oracle.com> Hi Miran, did you get any response on this yet? MartiNG On 17/01/14 10:57, Miroslav Kos wrote: > Hi Steve and Alan, > I just reminding this issue - I have no response from anybody yet and > it would really simplify our integration if I could handle copyright > years inconsistencies this way - I see this issue in many jdk branches > and these "each-branch-different" changes make each integration much > more pain. > > Thanks for any idea on this. > > Miran > > > On 10/01/14 18:05, Miroslav Kos wrote: >> Hi, >> this is about fixing copyright years for jdk8 (!); the incorrect >> years found for both 2012 and 2013, so not to confuse script >> jdk8/make/scripts/update_copyright_year.sh >> it is necessary to use option -d "" for commit. I tested that >> and it seems to work perfect. >> I used following: >> >> [2012 modifications] >> hg commit -u mkos -l ../2012-msg.txt -d "2012-12-30" >> >> [2013 modifications] >> hg commit -u mkos -l ../2013-msg.txt -d "2013-12-30" >> >> When commits performed with past date, update_copyright_year.sh >> script finds those in proper years. Since I am not familiar with >> using webrev for pushing changes, I exported both revisions into >> separate patches: >> >> 2012: http://cr.openjdk.java.net/~mkos/8029237/copyrights-2012.patch >> 2013: http://cr.openjdk.java.net/~mkos/8029237/copyrights-2013.patch >> all changes webrev: >> http://cr.openjdk.java.net/~mkos/8029237/webrev-all.00/ (upload still >> in progress, I hope it doesn't take more than 30 mins) >> bug: https://bugs.openjdk.java.net/browse/JDK-8029237 >> >> Regards >> Miran > > > -- Martin Grebac, SW Engineering Manager Oracle Czech, Prague From chris.hegarty at oracle.com Thu Jan 23 09:07:49 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 23 Jan 2014 09:07:49 +0000 Subject: JDK8 RFR JDK-8029237 Update copyright year to match last edit in jdk8 jaxws repository for 2013 In-Reply-To: <52E0D882.2060904@oracle.com> References: <52D0286B.9020108@oracle.com> <52D8FE89.9080603@oracle.com> <52E0D882.2060904@oracle.com> Message-ID: <598CAECC-C344-4B5D-8AEF-3B755E5BD3EA@oracle.com> On 23 Jan 2014, at 08:53, Martin Grebac wrote: > Hi Miran, did you get any response on this yet? > MartiNG > > On 17/01/14 10:57, Miroslav Kos wrote: >> Hi Steve and Alan, >> I just reminding this issue - I have no response from anybody yet and it would really simplify our integration if I could handle copyright years inconsistencies this way - I see this issue in many jdk branches and these "each-branch-different" changes make each integration much more pain. >> >> Thanks for any idea on this. >> >> Miran >> >> >> On 10/01/14 18:05, Miroslav Kos wrote: >>> Hi, >>> this is about fixing copyright years for jdk8 (!); the incorrect years found for both 2012 and 2013, so not to confuse script >>> jdk8/make/scripts/update_copyright_year.sh >>> it is necessary to use option -d "" for commit. I tested that and it seems to work perfect. >>> I used following: >>> >>> [2012 modifications] >>> hg commit -u mkos -l ../2012-msg.txt -d "2012-12-30" >>> >>> [2013 modifications] >>> hg commit -u mkos -l ../2013-msg.txt -d "2013-12-30" >>> >>> When commits performed with past date, update_copyright_year.sh script finds those in proper years. Since I am not familiar with using webrev for pushing changes, I exported both revisions into separate patches: >>> >>> 2012: http://cr.openjdk.java.net/~mkos/8029237/copyrights-2012.patch I skimmed the patch and it looks ok to me. Trivially, it contains a 2013 update (which it should probably be in the 2013 patch) diff -r 91f5c542ccad -r d6aec26c9771 make/Makefile --- a/make/Makefile Fri Jan 03 11:54:55 2014 -0800 +++ b/make/Makefile Sun Dec 30 00:00:00 2012 +0100 @@ -1,5 +1,5 @@ # -# Copyright (c) 2012, Oracle and/or its affiliates. All rights reserved. +# Copyright (c) 2012, 2013, Oracle and/or its affiliates. All rights reserved. # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. # >>> 2013: http://cr.openjdk.java.net/~mkos/8029237/copyrights-2013.patch Looks ok to me. -Chris. >>> all changes webrev: http://cr.openjdk.java.net/~mkos/8029237/webrev-all.00/ (upload still in progress, I hope it doesn't take more than 30 mins) >>> bug: https://bugs.openjdk.java.net/browse/JDK-8029237 >>> >>> Regards >>> Miran >> >> >> > > -- > Martin Grebac, SW Engineering Manager > Oracle Czech, Prague > From fweimer at redhat.com Thu Jan 23 09:22:42 2014 From: fweimer at redhat.com (Florian Weimer) Date: Thu, 23 Jan 2014 10:22:42 +0100 Subject: RFR: 8028816: Add value-type notice to Optional* classes In-Reply-To: <29971AF0-994C-430D-BF34-DDA47AA6949B@oracle.com> References: <29971AF0-994C-430D-BF34-DDA47AA6949B@oracle.com> Message-ID: <52E0DF62.4050904@redhat.com> On 12/03/2013 11:21 PM, Mike Duigou wrote: > There's been a discussion on the lambda spec experts list (http://mail.openjdk.java.net/pipermail/lambda-spec-experts/) about adding a notice to the Optional classes about implications of their likely future as values. This discussion recently completed so now there's a doc patch to review: > > http://cr.openjdk.java.net/~mduigou/JDK-8028816/0/webrev/ > > I have already reviewed this but will hold off pushing it for a few hours in case someone notices a mistake that I did not. Would it make sense to have an annotation (with class file retention) to express this? -- Florian Weimer / Red Hat Product Security Team From paul.sandoz at oracle.com Thu Jan 23 10:08:33 2014 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Thu, 23 Jan 2014 10:08:33 +0000 Subject: hg: jdk8/tl/jdk: 8032190: Specifications of stream flatMap methods should require mapped streams to be closed Message-ID: <20140123100901.4C12D626BF@hg.openjdk.java.net> Changeset: 68eb0c55a8c0 Author: psandoz Date: 2014-01-21 10:49 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/68eb0c55a8c0 8032190: Specifications of stream flatMap methods should require mapped streams to be closed Reviewed-by: chegar, alanb ! src/share/classes/java/util/stream/DoubleStream.java ! src/share/classes/java/util/stream/IntStream.java ! src/share/classes/java/util/stream/LongStream.java ! src/share/classes/java/util/stream/Stream.java From chris.hegarty at oracle.com Thu Jan 23 14:30:03 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 23 Jan 2014 14:30:03 +0000 Subject: JEP 187: Serialization 2.0 In-Reply-To: <52DFE05A.40901@redhat.com> References: <20140114002659.6AC0BD7C2@eggemoggin.niobe.net> <52DFCE40.4010108@redhat.com> <52DFDA07.2020307@oracle.com> <52DFE05A.40901@redhat.com> Message-ID: <9CBDDD37-0DA1-4B9B-BA2F-0391E568227A@oracle.com> On 22 Jan 2014, at 15:14, Florian Weimer wrote: > On 01/22/2014 03:47 PM, Chris Hegarty wrote: >> On 22/01/14 13:57, Florian Weimer wrote: >>> On 01/14/2014 01:26 AM, mark.reinhold at oracle.com wrote: >>>> Posted: http://openjdk.java.net/jeps/187 >>> >>> There's another aspect of the current approach to serialization that is >>> not mentioned: the type information does not come from the calling >>> context, but exclusively from the input stream. >> >> Have you overlooked resolveClass [1], or are you looking for additional >> context? > > I mean something slightly different, so here's a concrete example: Assume we are deserializing an instance of a class with a String field. The current framework deserializes whatever is in the input stream, and will bail out with a ClassCastException if the deserialized object turns out unusable. Contrast this with an alternative approach that uses the knowledge that the field String and will refuse to read anything else from the input stream. Sorry, but I may still be missing your point. From my reading of the code, CCE will only be thrown if the object being deserialized contains a field with a type that does not match the type of the similarly named field in the class loaded by the deserializing context. If there is no value assigned to said field, then it is just ignored. Also, if the type of a field changes, from one version of the class to another, but the name remains the same, then the serialVersionUID will differ. Are you thinking specifically about corrupt/malicious streams, or evolving serializable types? Or a performance optimisation? -Chris. > > -- > Florian Weimer / Red Hat Product Security Team From chris.hegarty at oracle.com Thu Jan 23 15:18:45 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 23 Jan 2014 15:18:45 +0000 Subject: JEP 187: Serialization 2.0 & Serialization-aware constructors In-Reply-To: <52DFF2D4.2050209@redhat.com> References: <20140114002659.6AC0BD7C2@eggemoggin.niobe.net> <52DFF2D4.2050209@redhat.com> Message-ID: <3F4A79BB-6C01-43D6-A09D-9B09EFE9B525@oracle.com> Hi David, This is a nice summary of how object deserialization is working today, and some interesting ideas around serialisation-aware constructors. It seems there is just too much magic in the construction of deserialized objects. All the field values required to fully construct the object are known, or are in the stream, but the instance is constructed without giving them any consideration, and the stuffing happens after the fact. It would seem that if these fields were made available to a ?special? deserializer that the class being reconstructed would have the possibility of constructing itself in a more normal manner ( assuming constructor cooperation up the class hierarchy ). -Chris. On 22 Jan 2014, at 16:33, David M. Lloyd wrote: > On 01/13/2014 06:26 PM, mark.reinhold at oracle.com wrote: >> Posted: http://openjdk.java.net/jeps/187 > > The concept of explicit deserialization constructors is interesting and is something I've explored a little bit in the context of JBoss Marshalling. > > The way construction works today (simple version!), the framework will magic up a new Constructor instance which can construct a partially-initialized object. By "partially initialized" I mean, only the classes in the non-serializable "top half" of the class hierarchy are initialized, subclass-first like always. At this point it relies on the language constraints that require that the superclass be initialized as the first step (more or less) of construction, thus effectively reversing initialization order to be superclass-first. > > Now at this point there is an object that was (more or less) initialized from the top (Object) down to the last non-serializable class in the hierarchy (which is often also Object, as it happens). From here, the deserialization mechanism takes over, using stream information to acquire values and "stuff" them into fields (even final fields) using reflection, in superclass-first order. Some reflection magic makes sure that final field publication works more or less as expected; some other magic ensures that sensible action is taken for certain types of differences in the sending and receiving class structures. No initializers are ever invoked for these classes, though you can define a private readObject() method which is a close approximation (as long as you don't have final fields, else you're stuck using reflection too). > > The idea with a serialization-aware constructor is that each serializable class constructor can read the stream information itself and initialize fields the "normal" way, with "normal" validation. > > The simplest/most naive implementation of this is to simply pass in an ObjectInputStream to these constructors. This approach seems to work fairly well actually, from the user's perspective: each constructor calls to the superclass first, then it acquires (for example) a GetField object for itself and then pulls field data out of it and populates its real fields, much like a readObject() method might do. > > The problem here is that the actual serialization implementation normally gets to hook in between calls to readObject(); it cannot do this for constructors, because each constructor calls the superclass' immediately in a chain. The framework would have to examine the call stack to know who the actual caller is, and there is also the possibility that the constructors would abuse this contract in various ways, taking advantage of the framework's lack of control. > > In an ideal world (for serialization implementations anyway), constructors would be wholly isolated, which would allow the framework to call each one in sequence with only its safely isolated bit of the stream. But in the real world, this isn't really possible within the framework of the existing language. > > One concept that might be interesting would be to introduce such isolated instance initializers which do not call up to the superclass but which otherwise follow the general constructor contract. This would present a very simple solution from the perspective of serialization, though the complexity of such a solution is potentially great. > > Another option is to establish a tighter API which constructors can consume. The constructor would be able to read field information out of the API but only for its own class, possibly even enforced by call stack inspection. The constructor would be contractually obligated to propagate the API object to the superclass; the framework would have to enforce that the propagation happened correctly for the class hierarchy (which it would have knowledge of), i.e. ensure the object didn't "cheat" by calling a non-serialization constructor for a serializable superclass. > > Other ideas may be possible as well. I found this to be an interesting problem when I was exploring it myself, and I still find it pretty interesting. > -- > - DML From pbenedict at apache.org Thu Jan 23 16:13:32 2014 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 23 Jan 2014 10:13:32 -0600 Subject: RFR: 8028816: Add value-type notice to Optional* classes Message-ID: Florian, it's an idea I also broached but did not receive any feedback: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-observers/2013-December/002585.html The only downside to adding the annotation is that it makes it "the" official way to denote a value type. Based on some JEPs and Lambda mailings, I think there's some heavy discussions behind the scenes to explore this design space. I don't know if committing to an annotation at this point is the "right" solution. -- Cheers, Paul >* There's been a discussion on the lambda spec experts list (http://mail.openjdk.java.net/pipermail/lambda-spec-experts/ ) about adding a notice to the Optional classes about implications of their likely future as values. This discussion recently completed so now there's a doc patch to review: *>>* http://cr.openjdk.java.net/~mduigou/JDK-8028816/0/webrev/ *>>* I have already reviewed this but will hold off pushing it for a few hours in case someone notices a mistake that I did not. * Would it make sense to have an annotation (with class file retention) to express this? -- Florian Weimer / Red Hat Product Security Team From Alan.Bateman at oracle.com Thu Jan 23 16:17:19 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 23 Jan 2014 16:17:19 +0000 Subject: (7u backport) RFR: 7199674 - (props) user.home property does not return an accessible location in sandboxed environment [macosx] In-Reply-To: <52E03CBD.1070402@oracle.com> References: <52E03CBD.1070402@oracle.com> Message-ID: <52E1408F.9050209@oracle.com> On 22/01/2014 21:48, Brent Christian wrote: > Hi, > > I would like to backport this fix from 8 to 7u. > > https://bugs.openjdk.java.net/browse/JDK-7199674 > > The source code changes apply cleanly to 7u from the 8 changeset, > however the makefile changes needed to be tweaked. > makefiles/CompileNativeLibraries.gmk did not exist in 7, so equivalent > changes are made in make/java/java/Makefile instead. > > Since it's not a direct port of the 8 changes, my understanding is > that the 7-specific changes should be reviewed. I looked at the make file changes (as that it the only part that is different) and it okay to me. You'll need to request approval on jdk7u-dev and probably best to do that soon if you are looking for this in 7u60 as I think they are close to forking the stabilization forest. -Alan From brian.goetz at oracle.com Thu Jan 23 18:16:31 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 23 Jan 2014 13:16:31 -0500 Subject: RFR: 8028816: Add value-type notice to Optional* classes In-Reply-To: References: Message-ID: <517A08AB-4E24-4A7A-869A-0C6E9EEC2376@oracle.com> A future version of Java will hopefully have value types. The disclaimers about "value-based" are intended as a stake in the ground, to preserve the option to migrate these specific new-to-Java-8 types to value types in the future. (Older sort-of-valueish-like-but-not-quite types, like Integer, are a hopeless cause.) When "value type" is a real thing, it will have linguistic support. Until then, he best we can do is capture the design intent for specific library classes in their specification to preserve clarity and flexibility. On Jan 23, 2014, at 11:13 AM, Paul Benedict wrote: > Florian, it's an idea I also broached but did not receive any feedback: > http://mail.openjdk.java.net/pipermail/lambda-libs-spec-observers/2013-December/002585.html > > The only downside to adding the annotation is that it makes it "the" > official way to denote a value type. Based on some JEPs and Lambda > mailings, I think there's some heavy discussions behind the scenes to > explore this design space. I don't know if committing to an annotation > at this point is the "right" solution. > > -- > > Cheers, > Paul > > >> * There's been a discussion on the lambda spec experts list (http://mail.openjdk.java.net/pipermail/lambda-spec-experts/ ) about adding a notice to the Optional classes about implications of their likely future as values. This discussion recently completed so now there's a doc patch to review: > *>>* http://cr.openjdk.java.net/~mduigou/JDK-8028816/0/webrev/ > > *>>* I have already reviewed this but will hold off pushing it for a > few hours in case someone notices a mistake that I did not. > * > Would it make sense to have an annotation (with class file retention) to > express this? > > -- > Florian Weimer / Red Hat Product Security Team From srikalyan.chandrashekar at oracle.com Thu Jan 23 20:10:18 2014 From: srikalyan.chandrashekar at oracle.com (srikalyan) Date: Thu, 23 Jan 2014 12:10:18 -0800 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52DEF53C.3050905@gmail.com> References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> <52CC72AB.2020104@oracle.com> <52CCEDE0.8000809@oracle.com> <52CCF079.4090301@oracle.com> <52CD45E7.7010203@gmail.com> <52CE4E2D.300@oracle.com> <52CF37C6.1070605@oracle.com> <52CFAFEB.9090703@gmail.com> <52CFD218.2060101@gmail.com> <52D06B70.60001@oracle.com> <52D15201.90109@gmail.com> <52D47D59.8040905@oracle.com> <52D72577.1050506@oracle.com> <52D76859.2030502@oracle.com> <52D82968.4030608@oracle.com> <52D8929B.2020905@oracle.com> <52D8A42A.4020906@oracle.com> <52D8B3B6.3030202@oracle.com> <52D9295D.6080106@gmail.com> <52D92C73.2020309@gmail.com> <52D92F1A.4040400@gmail.com> <52DC812C.1000607@oracle.com> <52DCD78E.8050404@gmail.com> <52DCE17B.4050708@gmail.com> <52DDD9F3.1050201@oracle.com> <52DE19C1.2070302@gmail.com> <52DE9147.4030305@gmail.com> <52DEB9C4.4030606@oracle.com> <52DEF53C.3050905@gmail.com> Message-ID: <52E1772A.1050608@oracle.com> Hi Peter, i have modified your code from r = pending; if (r != null) { ...... TO if (pending != null) { r = pending; This is because the r is used later in the code and must not be assigned pending unless it is not null(this was as is earlier). The new webrev is posted here http://cr.openjdk.java.net/~srikchan/Regression/JDK-8022321_OOMEInReferenceHandler-webrev-V2/ . I ran a 1000 run and no failures so far, however i would like to run a couple more 1000 runs to assert the fix. PS: The description section of JEP-122 (http://openjdk.java.net/jeps/122) says meta-data would be in native memory(not heap). -- Thanks kalyan Ph: (408)-585-8040 On 1/21/14, 2:31 PM, Peter Levart wrote: > > On 01/21/2014 07:17 PM, srikalyan wrote: >> Hi Peter/David, catching up after long weekend. Why would there be an >> OOME in object heap due to class loading in perm gen space ? > > The perm gen is not a problem her (JDK 8 does not have it and we see > OOME on JDK8 too). Each time a class is loaded, new java.lang.Class > object is allocated on heap. > > Regards, Peter > >> Please correct if i am missing something here. Meanwhile i will give >> the version of Reference Handler you both agreed on a try. >> -- >> Thanks >> kalyan >> Ph: (408)-585-8040 >> >> On 1/21/14, 7:24 AM, Peter Levart wrote: >>> On 01/21/2014 07:54 AM, Peter Levart wrote: >>>> *[Loaded sun.misc.Cleaner from >>>> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar]* >>>> [Loaded java.io.ByteArrayInputStream from >>>> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >>>> [Loaded sun.util.calendar.ZoneInfoFile$ZoneOffsetTransitionRule >>>> from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >>>> ... >>>> >>>> >>>> I'm on linux, 64bit and using official EA build 121 of JDK 8... >>>> >>>> But if I try with JDK 7u45, I don't see it. >>> >>> So what changed between JDK 7 and JDK 8? >>> >>> I suspect the following: 8007572: Replace existing jdk timezone data >>> at /lib/zi with JSR310's tzdb >>> >>> >>> Regards, Peter >>> > From christian.thalinger at oracle.com Thu Jan 23 20:16:30 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 23 Jan 2014 12:16:30 -0800 Subject: [9] RFR (XXS): 8031043: ClassValue's backing map should have a smaller initial size Message-ID: <063B6F8B-C7BF-4AD4-AF74-30445B1E8294@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8031043 http://cr.openjdk.java.net/~twisti/8031043/webrev.00 8031043: ClassValue's backing map should have a smaller initial size Reviewed-by: The current initial size for ClassValue's backing WeakHashMap (ClassValueMap) is: private static final int INITIAL_ENTRIES = 32; This is too big and wastes a lot of memory. Usually a dynamic language or other users of ClassValue associate only one value with a Class. Even if users need more entries it's better to start small and grow as needed since adding new values to a Class is a one-time thing and not performance critical. Here is some discussion on the mlvm-dev list: http://mail.openjdk.java.net/pipermail/mlvm-dev/2014-January/005597.html From Miroslaw.Niemiec at Oracle.COM Thu Jan 23 22:55:12 2014 From: Miroslaw.Niemiec at Oracle.COM (Miroslaw Niemiec) Date: Thu, 23 Jan 2014 14:55:12 -0800 Subject: [8011944] Sort fails with ArrayIndexOutOfBoundsException Message-ID: <52E19DD0.7020001@Oracle.COM> Hello! This is a simple backport from 8 to 7. Looking for a review of this even though it only requires a testcase change due to the use of lambda expressions. Since this is the first of these I've encountered I thought I better play it safe, but generally speaking, are we ok to skip the review process for backports like this? (minor lambda related testcase changes - if the lambda's are in the actual fix it probably makes sense to re-review). The fix: src/share/classes/java/util/ComparableTimSort.java src/share/classes/java/util/TimSort.java applied with no modification to 7 The only simple change was to replace a lambda expression in test case test/java/util/Arrays/TimSortStackSize.java: Arrays.sort(genData(), Integer::compare); got replaced with Arrays.sort(genData(), new java.util.Comparator() { public int compare(Integer a1, Integer a2){ return Integer.compare(a1.intValue(), a2.intValue()); } }); Jdk bug: https://bugs.openjdk.java.net/browse/JDK-8011944 Original fix for 8: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/07585a2483fa Fix for 7: http://cr.openjdk.java.net/~miroslawzn/801144/webrev.01/ Thank you Miroslaw From srikalyan.chandrashekar at oracle.com Fri Jan 24 00:02:21 2014 From: srikalyan.chandrashekar at oracle.com (srikalyan) Date: Thu, 23 Jan 2014 16:02:21 -0800 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52E1772A.1050608@oracle.com> References: <52B3568B.5050905@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> <52CC72AB.2020104@oracle.com> <52CCEDE0.8000809@oracle.com> <52CCF079.4090301@oracle.com> <52CD45E7.7010203@gmail.com> <52CE4E2D.300@oracle.com> <52CF37C6.1070605@oracle.com> <52CFAFEB.9090703@gmail.com> <52CFD218.2060101@gmail.com> <52D06B70.60001@oracle.com> <52D15201.90109@gmail.com> <52D47D59.8040905@oracle.com> <52D72577.1050506@oracle.com> <52D76859.2030502@oracle.com> <52D82968.4030608@oracle.com> <52D8929B.2020905@oracle.com> <52D8A42A.4020906@oracle.com> <52D8B3B6.3030202@oracle.com> <52D9295D.6080106@gmail.com> <52D92C73.2020309@gmail.com> <52D92F1A.4040400@gmail.com> <52DC812C.1000607@oracle.com> <52DCD78E.8050404@gmail.com> <52DCE17B.4050708@gmail.com> <52DDD9F3.1050201@oracle.com> <52DE19C1.2070302@gmail.com> <52DE9147.4030305@gmail.com> <52DEB9C4.4030606@oracle.com> <52DEF53C.3050905@gmail.com> <52E1772A.1050608@oracle.com> Message-ID: <52E1AD8D.7000509@oracle.com> Hi Peter/David, we have 2000 runs without a single failure. -- Thanks kalyan Ph: (408)-585-8040 On 1/23/14, 12:10 PM, srikalyan wrote: > Hi Peter, i have modified your code from > r = pending; > if (r != null) { > ...... > > > TO > > > if (pending != null) { > r = pending; > This is because the r is used later in the code and must not be > assigned pending unless it is not null(this was as is earlier). The > new webrev is posted here > http://cr.openjdk.java.net/~srikchan/Regression/JDK-8022321_OOMEInReferenceHandler-webrev-V2/ > . I ran a 1000 run and no failures so far, however i would like to run > a couple more 1000 runs to assert the fix. > > PS: The description section of JEP-122 > (http://openjdk.java.net/jeps/122) says meta-data would be in native > memory(not heap). > -- > Thanks > kalyan > Ph: (408)-585-8040 > > On 1/21/14, 2:31 PM, Peter Levart wrote: >> >> On 01/21/2014 07:17 PM, srikalyan wrote: >>> Hi Peter/David, catching up after long weekend. Why would there be >>> an OOME in object heap due to class loading in perm gen space ? >> >> The perm gen is not a problem her (JDK 8 does not have it and we see >> OOME on JDK8 too). Each time a class is loaded, new java.lang.Class >> object is allocated on heap. >> >> Regards, Peter >> >>> Please correct if i am missing something here. Meanwhile i will give >>> the version of Reference Handler you both agreed on a try. >>> -- >>> Thanks >>> kalyan >>> Ph: (408)-585-8040 >>> >>> On 1/21/14, 7:24 AM, Peter Levart wrote: >>>> On 01/21/2014 07:54 AM, Peter Levart wrote: >>>>> *[Loaded sun.misc.Cleaner from >>>>> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar]* >>>>> [Loaded java.io.ByteArrayInputStream from >>>>> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >>>>> [Loaded sun.util.calendar.ZoneInfoFile$ZoneOffsetTransitionRule >>>>> from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >>>>> ... >>>>> >>>>> >>>>> I'm on linux, 64bit and using official EA build 121 of JDK 8... >>>>> >>>>> But if I try with JDK 7u45, I don't see it. >>>> >>>> So what changed between JDK 7 and JDK 8? >>>> >>>> I suspect the following: 8007572: Replace existing jdk timezone >>>> data at /lib/zi with JSR310's tzdb >>>> >>>> >>>> Regards, Peter >>>> >> From david.holmes at oracle.com Fri Jan 24 00:33:09 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 Jan 2014 10:33:09 +1000 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52E1772A.1050608@oracle.com> References: <52B3568B.5050905@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> <52CC72AB.2020104@oracle.com> <52CCEDE0.8000809@oracle.com> <52CCF079.4090301@oracle.com> <52CD45E7.7010203@gmail.com> <52CE4E2D.300@oracle.com> <52CF37C6.1070605@oracle.com> <52CFAFEB.9090703@gmail.com> <52CFD218.2060101@gmail.com> <52D06B70.60001@oracle.com> <52D15201.90109@gmail.com> <52D47D59.8040905@oracle.com> <52D72577.1050506@oracle.com> <52D76859.2030502@oracle.com> <52D82968.4030608@oracle.com> <52D8929B.2020905@oracle.com> <52D8A42A.4020906@oracle.com> <52D8B3B6.3030202@oracle.com> <52D9295D.6080106@gmail.com> <52D92C73.2020309@gmail.com> <52D92F1A.4040400@gmail.com> <52DC812C.1000607@oracle.com> <52DCD78E.8050404@gmail.com> <52DCE17B.4050708@gmail.com> <52DDD9F3.1050201@oracle.com> <52DE19C1.2070302@gmail.com> <52DE9147.4030305@gmail.com> <52DEB9C4.4030606@oracle.com> <52DEF53C.3050905@gmail.com> <52E1772A.1050608@oracle.com> Message-ID: <52E1B4C5.8050807@oracle.com> On 24/01/2014 6:10 AM, srikalyan wrote: > Hi Peter, i have modified your code from > > r = pending; > if (r != null) { > ...... > TO > if (pending != null) { > r = pending; > > This is because the r is used later in the code and must not be assigned > pending unless it is not null(this was as is earlier). If r is null, because pending is null then you perform the wait() and then continue - back to the top of the loop. There is no bug in Peter's code. The new webrev is > posted here > http://cr.openjdk.java.net/~srikchan/Regression/JDK-8022321_OOMEInReferenceHandler-webrev-V2/ > . I ran a 1000 run and no failures so far, however i would like to run a > couple more 1000 runs to assert the fix. > > PS: The description section of JEP-122 > (http://openjdk.java.net/jeps/122) says meta-data would be in native > memory(not heap). The class_mirror is a Java object not meta-data. David > -- > Thanks > kalyan > Ph: (408)-585-8040 > > > On 1/21/14, 2:31 PM, Peter Levart wrote: >> >> On 01/21/2014 07:17 PM, srikalyan wrote: >>> Hi Peter/David, catching up after long weekend. Why would there be an >>> OOME in object heap due to class loading in perm gen space ? >> >> The perm gen is not a problem her (JDK 8 does not have it and we see >> OOME on JDK8 too). Each time a class is loaded, new java.lang.Class >> object is allocated on heap. >> >> Regards, Peter >> >>> Please correct if i am missing something here. Meanwhile i will give >>> the version of Reference Handler you both agreed on a try. >>> -- >>> Thanks >>> kalyan >>> Ph: (408)-585-8040 >>> >>> On 1/21/14, 7:24 AM, Peter Levart wrote: >>>> On 01/21/2014 07:54 AM, Peter Levart wrote: >>>>> *[Loaded sun.misc.Cleaner from >>>>> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar]* >>>>> [Loaded java.io.ByteArrayInputStream from >>>>> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >>>>> [Loaded sun.util.calendar.ZoneInfoFile$ZoneOffsetTransitionRule >>>>> from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >>>>> ... >>>>> >>>>> >>>>> I'm on linux, 64bit and using official EA build 121 of JDK 8... >>>>> >>>>> But if I try with JDK 7u45, I don't see it. >>>> >>>> So what changed between JDK 7 and JDK 8? >>>> >>>> I suspect the following: 8007572: Replace existing jdk timezone data >>>> at /lib/zi with JSR310's tzdb >>>> >>>> >>>> Regards, Peter >>>> >> From srikalyan.chandrashekar at oracle.com Fri Jan 24 01:53:49 2014 From: srikalyan.chandrashekar at oracle.com (srikalyan chandrashekar) Date: Thu, 23 Jan 2014 17:53:49 -0800 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52E1B4C5.8050807@oracle.com> References: <52B3568B.5050905@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> <52CC72AB.2020104@oracle.com> <52CCEDE0.8000809@oracle.com> <52CCF079.4090301@oracle.com> <52CD45E7.7010203@gmail.com> <52CE4E2D.300@oracle.com> <52CF37C6.1070605@oracle.com> <52CFAFEB.9090703@gmail.com> <52CFD218.2060101@gmail.com> <52D06B70.60001@oracle.com> <52D15201.90109@gmail.com> <52D47D59.8040905@oracle.com> <52D72577.1050506@oracle.com> <52D76859.2030502@oracle.com> <52D82968.4030608@oracle.com> <52D8929B.2020905@oracle.com> <52D8A42A.4020906@oracle.com> <52D8B3B6.3030202@oracle.com> <52D9295D.6080106@gmail.com> <52D92C73.2020309@gmail.com> <52D92F1A.4040400@gmail.com> <52DC812C.1000607@oracle.com> <52DCD78E.8050404@gmail.com> <52DCE17B.4050708@gmail.com> <52DDD9F3.1050201@oracle.com> <52DE19C1.2070302@gmail.com> <52DE9147.4030305@gmail.com> <52DEB9C4.4030606@oracle.com> <52DEF53C.3050905@gmail.com> <52E1772A.1050608@oracle.com> <52E1B4C5.8050807@oracle.com> Message-ID: <52E1C7AD.8090100@oracle.com> Hi David, yes thats right, only benefit i see is we can avoid assignment to 'r' if pending is null. -- Thanks kalyan On 1/23/14 4:33 PM, David Holmes wrote: > On 24/01/2014 6:10 AM, srikalyan wrote: >> Hi Peter, i have modified your code from >> >> r = pending; >> if (r != null) { >> ...... >> TO >> if (pending != null) { >> r = pending; >> >> This is because the r is used later in the code and must not be assigned >> pending unless it is not null(this was as is earlier). > > If r is null, because pending is null then you perform the wait() and > then continue - back to the top of the loop. There is no bug in > Peter's code. > > The new webrev is >> posted here >> http://cr.openjdk.java.net/~srikchan/Regression/JDK-8022321_OOMEInReferenceHandler-webrev-V2/ >> >> . I ran a 1000 run and no failures so far, however i would like to run a >> couple more 1000 runs to assert the fix. >> >> PS: The description section of JEP-122 >> (http://openjdk.java.net/jeps/122) says meta-data would be in native >> memory(not heap). > > The class_mirror is a Java object not meta-data. > > David > >> -- >> Thanks >> kalyan >> Ph: (408)-585-8040 >> >> >> On 1/21/14, 2:31 PM, Peter Levart wrote: >>> >>> On 01/21/2014 07:17 PM, srikalyan wrote: >>>> Hi Peter/David, catching up after long weekend. Why would there be an >>>> OOME in object heap due to class loading in perm gen space ? >>> >>> The perm gen is not a problem her (JDK 8 does not have it and we see >>> OOME on JDK8 too). Each time a class is loaded, new java.lang.Class >>> object is allocated on heap. >>> >>> Regards, Peter >>> >>>> Please correct if i am missing something here. Meanwhile i will give >>>> the version of Reference Handler you both agreed on a try. >>>> -- >>>> Thanks >>>> kalyan >>>> Ph: (408)-585-8040 >>>> >>>> On 1/21/14, 7:24 AM, Peter Levart wrote: >>>>> On 01/21/2014 07:54 AM, Peter Levart wrote: >>>>>> *[Loaded sun.misc.Cleaner from >>>>>> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar]* >>>>>> [Loaded java.io.ByteArrayInputStream from >>>>>> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >>>>>> [Loaded sun.util.calendar.ZoneInfoFile$ZoneOffsetTransitionRule >>>>>> from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >>>>>> ... >>>>>> >>>>>> >>>>>> I'm on linux, 64bit and using official EA build 121 of JDK 8... >>>>>> >>>>>> But if I try with JDK 7u45, I don't see it. >>>>> >>>>> So what changed between JDK 7 and JDK 8? >>>>> >>>>> I suspect the following: 8007572: Replace existing jdk timezone data >>>>> at /lib/zi with JSR310's tzdb >>>>> >>>>> >>>>> Regards, Peter >>>>> >>> From david.holmes at oracle.com Fri Jan 24 01:58:52 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 Jan 2014 11:58:52 +1000 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52E1C7AD.8090100@oracle.com> References: <52B3568B.5050905@oracle.com> <52CB4CFC.9070405@oracle.com> <52CC72AB.2020104@oracle.com> <52CCEDE0.8000809@oracle.com> <52CCF079.4090301@oracle.com> <52CD45E7.7010203@gmail.com> <52CE4E2D.300@oracle.com> <52CF37C6.1070605@oracle.com> <52CFAFEB.9090703@gmail.com> <52CFD218.2060101@gmail.com> <52D06B70.60001@oracle.com> <52D15201.90109@gmail.com> <52D47D59.8040905@oracle.com> <52D72577.1050506@oracle.com> <52D76859.2030502@oracle.com> <52D82968.4030608@oracle.com> <52D8929B.2020905@oracle.com> <52D8A42A.4020906@oracle.com> <52D8B3B6.3030202@oracle.com> <52D9295D.6080106@gmail.com> <52D92C73.2020309@gmail.com> <52D92F1A.4040400@gmail.com> <52DC812C.1000607@oracle.com> <52DCD78E.8050404@gmail.com> <52DCE17B.4050708@gmail.com> <52DDD9F3.1050201@oracle.com> <52DE19C1.2070302@gmail.com> <52DE9147.4030305@gmail.com> <52DEB9C4.4030606@oracle.com> <52DEF53C.3050905@gmail.com> <52E1772A.1050608@oracle.com> <52E1B4C5.8050807@oracle.com> <52E1C7AD.8090100@oracle.com> Message-ID: <52E1C8DC.2020009@oracle.com> On 24/01/2014 11:53 AM, srikalyan chandrashekar wrote: > Hi David, yes thats right, only benefit i see is we can avoid assignment > to 'r' if pending is null. I'm okay with either version. David > -- > Thanks > kalyan > > On 1/23/14 4:33 PM, David Holmes wrote: >> On 24/01/2014 6:10 AM, srikalyan wrote: >>> Hi Peter, i have modified your code from >>> >>> r = pending; >>> if (r != null) { >>> ...... >>> TO >>> if (pending != null) { >>> r = pending; >>> >>> This is because the r is used later in the code and must not be assigned >>> pending unless it is not null(this was as is earlier). >> >> If r is null, because pending is null then you perform the wait() and >> then continue - back to the top of the loop. There is no bug in >> Peter's code. >> >> The new webrev is >>> posted here >>> http://cr.openjdk.java.net/~srikchan/Regression/JDK-8022321_OOMEInReferenceHandler-webrev-V2/ >>> >>> . I ran a 1000 run and no failures so far, however i would like to run a >>> couple more 1000 runs to assert the fix. >>> >>> PS: The description section of JEP-122 >>> (http://openjdk.java.net/jeps/122) says meta-data would be in native >>> memory(not heap). >> >> The class_mirror is a Java object not meta-data. >> >> David >> >>> -- >>> Thanks >>> kalyan >>> Ph: (408)-585-8040 >>> >>> >>> On 1/21/14, 2:31 PM, Peter Levart wrote: >>>> >>>> On 01/21/2014 07:17 PM, srikalyan wrote: >>>>> Hi Peter/David, catching up after long weekend. Why would there be an >>>>> OOME in object heap due to class loading in perm gen space ? >>>> >>>> The perm gen is not a problem her (JDK 8 does not have it and we see >>>> OOME on JDK8 too). Each time a class is loaded, new java.lang.Class >>>> object is allocated on heap. >>>> >>>> Regards, Peter >>>> >>>>> Please correct if i am missing something here. Meanwhile i will give >>>>> the version of Reference Handler you both agreed on a try. >>>>> -- >>>>> Thanks >>>>> kalyan >>>>> Ph: (408)-585-8040 >>>>> >>>>> On 1/21/14, 7:24 AM, Peter Levart wrote: >>>>>> On 01/21/2014 07:54 AM, Peter Levart wrote: >>>>>>> *[Loaded sun.misc.Cleaner from >>>>>>> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar]* >>>>>>> [Loaded java.io.ByteArrayInputStream from >>>>>>> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >>>>>>> [Loaded sun.util.calendar.ZoneInfoFile$ZoneOffsetTransitionRule >>>>>>> from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >>>>>>> ... >>>>>>> >>>>>>> >>>>>>> I'm on linux, 64bit and using official EA build 121 of JDK 8... >>>>>>> >>>>>>> But if I try with JDK 7u45, I don't see it. >>>>>> >>>>>> So what changed between JDK 7 and JDK 8? >>>>>> >>>>>> I suspect the following: 8007572: Replace existing jdk timezone data >>>>>> at /lib/zi with JSR310's tzdb >>>>>> >>>>>> >>>>>> Regards, Peter >>>>>> >>>> > From tristan.yan at oracle.com Fri Jan 24 06:34:28 2014 From: tristan.yan at oracle.com (Tristan Yan) Date: Fri, 24 Jan 2014 14:34:28 +0800 Subject: RFR: JDK-8032050: TEST_BUG: java/rmi/activation/Activatable/shutdownGracefully/ShutdownGracefully.java fails intermittently Message-ID: <52E20974.7060706@oracle.com> Hi All Could you review the bug fix for JDK-8032050. http://cr.openjdk.java.net/~tyan/JDK-8032050/webrev.00/ Description: This rare happened failure caused because when RMID starts. It don't guarantee sun.rmi.server.Activation.startActivation finishes. Fix by adding a iterative getSystem with a 5 seconds timeout. Thank you. Tristan From yiming.wang at oracle.com Fri Jan 24 07:14:07 2014 From: yiming.wang at oracle.com (Eric Wang) Date: Fri, 24 Jan 2014 15:14:07 +0800 Subject: Question about the bug https://bugs.openjdk.java.net/browse/JDK-8031179 In-Reply-To: <52D9CE99.5050404@oracle.com> References: <52D7F2D6.7090007@oracle.com> <52D7F83B.8060900@oracle.com> <52D9CE99.5050404@oracle.com> Message-ID: <52E212BF.7030103@oracle.com> Hi Stuart, Thanks for the suggestion! sorry for reply this mail late as i was busy on other tasks The webrev has been in the internal review process. Based on the suggestion, here is a summary of changes: 1. Add othervm options to tests: java/rmi/Naming/DefaultRegistryPort.java java/rmi/Naming/legalRegistryNames/LegalRegistryNames.java java/rmi/Naming/LookupNameWithColon.java java/rmi/server/UnicastRemoteObject/exportObject/GcDuringExport.java sun/rmi/rmic/RMIGenerator/RmicDefault.java java/rmi/MarshalledObject/compare/Compare.java java/rmi/MarshalledObject/compare/HashCode.java 2. Remove java/rmi and sun/rmi from othervm.dirs of TEST.ROOT 3. Filed a another bug https://bugs.openjdk.java.net/browse/JDK-8032629 for exclusiveAccess.dirs Thanks, Eric On 2014/1/18 8:45, Stuart Marks wrote: > Hi Eric, > > Thanks for doing the analysis of the tests that need /othervm. The > list of tests that don't need /othervm looks good. One subtlety is > this one: > > java/rmi/activation/ActivationGroupDesc/checkDefaultGroupName/CheckDefaultGroupName.java > > > Most activation tests do need /othervm, but this one doesn't, since > all it does is create an ActivationGroupDesc instance, which has no > side effects. This is unusual for the activation APIs, since most of > them are quite intertwined with the rest of the activation subsystem. > So, for this test, the lack of /othervm warrants a comment explaining > why /othervm is unnecessary. > > Regarding merging of the tests > java/rmi/MarshalledObject/compare/Compare.java and HashCode.java, this > is fairly subtle and not obviously wrong, but it's not obviously right > either. Note that different jtreg tests -- even in agentvm or samevm > mode -- load the test class in a fresh classloader, which means that > the statics are reinitialized. This provides some degree of isolation > of the tests even when they're reusing the same JVM. By contrast, > calling the two different methods from within the same test exposes > the second one to initializations left from the first one. In addition > (though I'm not too concerned about this) if the first test fails the > second won't be run at all. Merging these tests is kind of out of > scope for this particular bug, and since I wasn't fully able to > convince myself that the merged tests have the same semantics as the > unmerged tests, I'd prefer not to see the merging of these tests as > part of this changeset. > > (Some cleanup of these two tests is probably warranted eventually. I'd > take a different approach of merging and refactoring the sources but > keeping them as separate test runs, using two @run tags. But we should > work on that separately. Meanwhile, the overhead of having these as > separate tests is minimal, especially if they're not run in /othervm > mode.) > > I don't think the removal of java/rmi/Naming from exclusiveAccess.dirs > is safe at this point. The DefaultRegistryPort.java test uses the > default registry port, not a unique one. Conceptually it would need to > be converted to use the TestLibrary unique port stuff, but the test is > actually about using the default port. So, the solution here isn't > obvious. > > In addition, the > java/rmi/Naming/legalRegistryNames/LegalRegistryNames.java test also > uses the default registry port. It too will need to converted before > java/rmi/Naming is removed from exclusiveAccess.dirs. > > The java/rmi/Naming/LookupIPv6.java test was converted to use the > TestLibrary unique port technique, but only partially. The registry is > created on the unique port, but the Naming.lookup() call on the last > line of the test doesn't provide a port number, so it does the lookup > on the default port instead. This will cause the test to fail in > almost all cases. > > I have to ask, did you run this test with your modifications? > > (Well, the test would pass if IPv6 is not enabled on the machine > running the test, but it only passes because the part of the test that > creates and uses the registry is bypassed entirely if IPv6 is not > enabled. If you're modifying code, you need to take responsibility for > ensuring that the code being modified is actually being run and is > doing what you expect.) > > LookupIPv6.java also needs to have these lines added to the test tags: > * @bug 4402708 > + * @library ../testlibrary > + * @build TestLibrary > * @run main/othervm -Djava.net.preferIPv6Addresses=true LookupIPv6 > (Their absence will cause the test also to fail in a clean build, but > the test will find a TestLibrary class if one had been compiled by a > previous test that had required it.) > > Maybe we should separate the othervm changes (removal of the rmi dirs > from othervm.dirs, and addition of /othervm) from the > exclusiveAccess.dirs changes. A separate bug would be filed for > exclusiveAccess.dirs. I know this means the bug count won't go down, > but dealing with exclusiveAccess.dirs means that the logic of various > tests will need to be change to use the unique port mechanism. This is > a fair chunk of work and it's logically distinct from the othervm work. > > If we also remove the merging of the MarshalledObject tests, I think > we can proceed with the othervm changes. > > Eric, can you make these changes and send out another webrev? > > Thanks. > > s'marks > > > > On 1/16/14 7:18 AM, Eric Wang wrote: >> Hi Stuart, >> >> I have generated a webrev for review, can you please help to check >> whether the changes are OK. >> http://cr.openjdk.java.net/~ewang/JDK-8031179/webrev.00/ >> >> >> Also need your help to confirm that the rest 9 tests in previous mail >> don't need the /othervm option indeed. >> >> Thanks, >> Eric >> On 2014/1/16 22:55, Eric Wang wrote: >>> Hi Stuart, >>> >>> I'm working on the bug >>> https://bugs.openjdk.java.net/browse/JDK-8031179 to add /othervm >>> option to rmi tests, so they can removed from the item othervm.dir >>> and exclusiveAccess.dirs. >>> By searching the directories java/rmi, sun/rmi and java/rmi/Naming, >>> there are 14 tests without othervm option, but only 5 tests need to >>> the /othervm tag. they are: >>> >>> Tests need /othervm option: >>> java/rmi/Naming/DefaultRegistryPort.java >>> java/rmi/Naming/legalRegistryNames/LegalRegistryNames.java >>> java/rmi/Naming/LookupNameWithColon.java >>> java/rmi/server/UnicastRemoteObject/exportObject/GcDuringExport.java >>> sun/rmi/rmic/RMIGenerator/RmicDefault.java >>> >>> Tests don't need the /othervm option: >>> java/rmi/activation/ActivationGroupDesc/checkDefaultGroupName/CheckDefaultGroupName.java >>> >>> java/rmi/MarshalledObject/compare/Compare.java >>> java/rmi/MarshalledObject/compare/HashCode.java >>> java/rmi/MarshalledObject/compare/NullReference.java >>> java/rmi/server/Unmarshal/PrimitiveClasses.java >>> sun/rmi/log/ReliableLog/LogAlignmentTest.java >>> sun/rmi/log/ReliableLog/Recovery.java >>> sun/rmi/log/ReliableLog/SnapshotSize.java >>> sun/rmi/rmic/classpath/RMICClassPathTest.java >>> >>> Also i have a bit confuse about the test Compare.java and >>> HashCode.java in java/rmi/MarshalledObject/compare directory, as >>> they should be merged into one test so that we don't need to add >>> additional /othervm option for 2 test. >>> >>> Thanks, >>> Eric >>> >> > From fweimer at redhat.com Fri Jan 24 08:06:35 2014 From: fweimer at redhat.com (Florian Weimer) Date: Fri, 24 Jan 2014 09:06:35 +0100 Subject: [8011944] Sort fails with ArrayIndexOutOfBoundsException In-Reply-To: <52E19DD0.7020001@Oracle.COM> References: <52E19DD0.7020001@Oracle.COM> Message-ID: <52E21F0B.4040200@redhat.com> On 01/23/2014 11:55 PM, Miroslaw Niemiec wrote: > Fix for 7: > http://cr.openjdk.java.net/~miroslawzn/801144/webrev.01/ The new test lacks a license header. -- Florian Weimer / Red Hat Product Security Team From paul.sandoz at oracle.com Fri Jan 24 09:07:27 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 24 Jan 2014 10:07:27 +0100 Subject: [8011944] Sort fails with ArrayIndexOutOfBoundsException In-Reply-To: <52E19DD0.7020001@Oracle.COM> References: <52E19DD0.7020001@Oracle.COM> Message-ID: <74E83076-D64B-4828-B8C7-40FC8B6F22CF@oracle.com> On Jan 23, 2014, at 11:55 PM, Miroslaw Niemiec wrote: > Hello! > > This is a simple backport from 8 to 7. Looks good to me (as Florian points out the test requires a license and updates to dates on those source files). > Looking for a review of this even though it only requires a testcase change due to the use of lambda expressions. > Since this is the first of these I've encountered I thought I better play it safe, but generally speaking, are we ok > to skip the review process for backports like this? (minor lambda related testcase changes - if the lambda's are in the actual fix it probably makes sense to re-review). > I am not entirely sure of the process but here are my thoughts: - if the patch applies/compiles/runs/tests cleanly on a previous release then there is probably no need for a review in most cases. - if the patch requires explicit merging or updates then a review is probably required. Sometimes a patch could be contextual and have some implicit (and not direct) dependency on something else not in the patch, so i think we have to exercise our judgment on a per-patch basis. Paul. From Alan.Bateman at oracle.com Fri Jan 24 09:33:13 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 24 Jan 2014 09:33:13 +0000 Subject: [8011944] Sort fails with ArrayIndexOutOfBoundsException In-Reply-To: <52E19DD0.7020001@Oracle.COM> References: <52E19DD0.7020001@Oracle.COM> Message-ID: <52E23359.3050705@oracle.com> On 23/01/2014 22:55, Miroslaw Niemiec wrote: > Hello! > > This is a simple backport from 8 to 7. > Looking for a review of this even though it only requires a testcase > change due to the use of lambda expressions. > Since this is the first of these I've encountered I thought I better > play it safe, but generally speaking, are we ok > to skip the review process for backports like this? (minor lambda > related testcase changes - if the lambda's are in the actual fix it > probably makes sense to re-review). It often happens that "small adjustments" are required when back-porting. To date then it's been a mix of just highlighting in the approval request to jdk7u-dev, sometimes the mailing list where the issue was originally reviewed is included. It's really just a judgement call as sometimes the adjustments are trivial, sometimes a bit more. The jdk7u maintainers are good about asking for additional review where it might be needed. For cases like this one then it's best to start with the test pushed to the jdk8 forest and then just replace the use of new language features so that it compiles/runs on jdk7u. In this this case it seems okay, just make sure (as others have pointed out) not to remove the copyright header. -Alan. From erik.joelsson at oracle.com Fri Jan 24 09:40:30 2014 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Fri, 24 Jan 2014 09:40:30 +0000 Subject: hg: jdk8/tl: 8032632: Wrong version for the first jdk8 fcs build Message-ID: <20140124094031.71A1062744@hg.openjdk.java.net> Changeset: 7238a870ddb7 Author: erikj Date: 2014-01-24 10:39 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/7238a870ddb7 8032632: Wrong version for the first jdk8 fcs build Reviewed-by: katleman ! common/autoconf/spec.gmk.in From miroslav.kos at oracle.com Fri Jan 24 09:41:58 2014 From: miroslav.kos at oracle.com (Miroslav Kos) Date: Fri, 24 Jan 2014 10:41:58 +0100 Subject: JDK8 RFR JDK-8029237 Update copyright year to match last edit in jdk8 jaxws repository for 2013 In-Reply-To: <598CAECC-C344-4B5D-8AEF-3B755E5BD3EA@oracle.com> References: <52D0286B.9020108@oracle.com> <52D8FE89.9080603@oracle.com> <52E0D882.2060904@oracle.com> <598CAECC-C344-4B5D-8AEF-3B755E5BD3EA@oracle.com> Message-ID: <52E23566.1030506@oracle.com> Hi Chris, thanks for reviewing - I generated the patches today again so now it should be ok: http://cr.openjdk.java.net/~mkos/8029237/copyrights-2012-v02.patch http://cr.openjdk.java.net/~mkos/8029237/copyrights-2013-v02.patch Could you push it for me? I have no rights for jdk8. I suppose the commit dates (must be in the past) would be imported correctly: copyrights-2012-v02.patch: -d "2012-12-30" copyrights-2013-v02.patch: -d "2013-12-30" Thanks Miran On 23/01/14 10:07, Chris Hegarty wrote: > On 23 Jan 2014, at 08:53, Martin Grebac wrote: > >> Hi Miran, did you get any response on this yet? >> MartiNG >> >> On 17/01/14 10:57, Miroslav Kos wrote: >>> Hi Steve and Alan, >>> I just reminding this issue - I have no response from anybody yet and it would really simplify our integration if I could handle copyright years inconsistencies this way - I see this issue in many jdk branches and these "each-branch-different" changes make each integration much more pain. >>> >>> Thanks for any idea on this. >>> >>> Miran >>> >>> >>> On 10/01/14 18:05, Miroslav Kos wrote: >>>> Hi, >>>> this is about fixing copyright years for jdk8 (!); the incorrect years found for both 2012 and 2013, so not to confuse script >>>> jdk8/make/scripts/update_copyright_year.sh >>>> it is necessary to use option -d "" for commit. I tested that and it seems to work perfect. >>>> I used following: >>>> >>>> [2012 modifications] >>>> hg commit -u mkos -l ../2012-msg.txt -d "2012-12-30" >>>> >>>> [2013 modifications] >>>> hg commit -u mkos -l ../2013-msg.txt -d "2013-12-30" >>>> >>>> When commits performed with past date, update_copyright_year.sh script finds those in proper years. Since I am not familiar with using webrev for pushing changes, I exported both revisions into separate patches: >>>> >>>> 2012: http://cr.openjdk.java.net/~mkos/8029237/copyrights-2012.patch > I skimmed the patch and it looks ok to me. > > Trivially, it contains a 2013 update (which it should probably be in the 2013 patch) > > diff -r 91f5c542ccad -r d6aec26c9771 make/Makefile > --- a/make/Makefile Fri Jan 03 11:54:55 2014 -0800 > +++ b/make/Makefile Sun Dec 30 00:00:00 2012 +0100 > @@ -1,5 +1,5 @@ > # > -# Copyright (c) 2012, Oracle and/or its affiliates. All rights reserved. > +# Copyright (c) 2012, 2013, Oracle and/or its affiliates. All rights reserved. > # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > # > >>>> 2013: http://cr.openjdk.java.net/~mkos/8029237/copyrights-2013.patch > Looks ok to me. > > -Chris. > >>>> all changes webrev: http://cr.openjdk.java.net/~mkos/8029237/webrev-all.00/ (upload still in progress, I hope it doesn't take more than 30 mins) >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8029237 >>>> >>>> Regards >>>> Miran >>> >>> >> -- >> Martin Grebac, SW Engineering Manager >> Oracle Czech, Prague >> From yiming.wang at oracle.com Fri Jan 24 09:43:26 2014 From: yiming.wang at oracle.com (Eric Wang) Date: Fri, 24 Jan 2014 17:43:26 +0800 Subject: Question about the bug https://bugs.openjdk.java.net/browse/JDK-8031179 In-Reply-To: <52E212BF.7030103@oracle.com> References: <52D7F2D6.7090007@oracle.com> <52D7F83B.8060900@oracle.com> <52D9CE99.5050404@oracle.com> <52E212BF.7030103@oracle.com> Message-ID: <52E235BE.2040304@oracle.com> Hi Stuart, Please review the webrev http://cr.openjdk.java.net/~ewang/JDK-8031179/webrev.00/, if you are OK with the changes, could you please be my sponsor? Thanks, Eric On 2014/1/24 15:14, Eric Wang wrote: > Hi Stuart, > Thanks for the suggestion! sorry for reply this mail late as i was > busy on other tasks > The webrev has been in the internal review process. Based on the > suggestion, here is a summary of changes: > > 1. Add othervm options to tests: > java/rmi/Naming/DefaultRegistryPort.java > java/rmi/Naming/legalRegistryNames/LegalRegistryNames.java > java/rmi/Naming/LookupNameWithColon.java > java/rmi/server/UnicastRemoteObject/exportObject/GcDuringExport.java > sun/rmi/rmic/RMIGenerator/RmicDefault.java > java/rmi/MarshalledObject/compare/Compare.java > java/rmi/MarshalledObject/compare/HashCode.java > > 2. Remove java/rmi and sun/rmi from othervm.dirs of TEST.ROOT > > 3. Filed a another bug > https://bugs.openjdk.java.net/browse/JDK-8032629 for exclusiveAccess.dirs > > Thanks, > Eric > > On 2014/1/18 8:45, Stuart Marks wrote: >> Hi Eric, >> >> Thanks for doing the analysis of the tests that need /othervm. The >> list of tests that don't need /othervm looks good. One subtlety is >> this one: >> >> java/rmi/activation/ActivationGroupDesc/checkDefaultGroupName/CheckDefaultGroupName.java >> >> >> Most activation tests do need /othervm, but this one doesn't, since >> all it does is create an ActivationGroupDesc instance, which has no >> side effects. This is unusual for the activation APIs, since most of >> them are quite intertwined with the rest of the activation subsystem. >> So, for this test, the lack of /othervm warrants a comment explaining >> why /othervm is unnecessary. >> >> Regarding merging of the tests >> java/rmi/MarshalledObject/compare/Compare.java and HashCode.java, >> this is fairly subtle and not obviously wrong, but it's not obviously >> right either. Note that different jtreg tests -- even in agentvm or >> samevm mode -- load the test class in a fresh classloader, which >> means that the statics are reinitialized. This provides some degree >> of isolation of the tests even when they're reusing the same JVM. By >> contrast, calling the two different methods from within the same test >> exposes the second one to initializations left from the first one. In >> addition (though I'm not too concerned about this) if the first test >> fails the second won't be run at all. Merging these tests is kind of >> out of scope for this particular bug, and since I wasn't fully able >> to convince myself that the merged tests have the same semantics as >> the unmerged tests, I'd prefer not to see the merging of these tests >> as part of this changeset. >> >> (Some cleanup of these two tests is probably warranted eventually. >> I'd take a different approach of merging and refactoring the sources >> but keeping them as separate test runs, using two @run tags. But we >> should work on that separately. Meanwhile, the overhead of having >> these as separate tests is minimal, especially if they're not run in >> /othervm mode.) >> >> I don't think the removal of java/rmi/Naming from >> exclusiveAccess.dirs is safe at this point. The >> DefaultRegistryPort.java test uses the default registry port, not a >> unique one. Conceptually it would need to be converted to use the >> TestLibrary unique port stuff, but the test is actually about using >> the default port. So, the solution here isn't obvious. >> >> In addition, the >> java/rmi/Naming/legalRegistryNames/LegalRegistryNames.java test also >> uses the default registry port. It too will need to converted before >> java/rmi/Naming is removed from exclusiveAccess.dirs. >> >> The java/rmi/Naming/LookupIPv6.java test was converted to use the >> TestLibrary unique port technique, but only partially. The registry >> is created on the unique port, but the Naming.lookup() call on the >> last line of the test doesn't provide a port number, so it does the >> lookup on the default port instead. This will cause the test to fail >> in almost all cases. >> >> I have to ask, did you run this test with your modifications? >> >> (Well, the test would pass if IPv6 is not enabled on the machine >> running the test, but it only passes because the part of the test >> that creates and uses the registry is bypassed entirely if IPv6 is >> not enabled. If you're modifying code, you need to take >> responsibility for ensuring that the code being modified is actually >> being run and is doing what you expect.) >> >> LookupIPv6.java also needs to have these lines added to the test tags: >> * @bug 4402708 >> + * @library ../testlibrary >> + * @build TestLibrary >> * @run main/othervm -Djava.net.preferIPv6Addresses=true LookupIPv6 >> (Their absence will cause the test also to fail in a clean build, but >> the test will find a TestLibrary class if one had been compiled by a >> previous test that had required it.) >> >> Maybe we should separate the othervm changes (removal of the rmi dirs >> from othervm.dirs, and addition of /othervm) from the >> exclusiveAccess.dirs changes. A separate bug would be filed for >> exclusiveAccess.dirs. I know this means the bug count won't go down, >> but dealing with exclusiveAccess.dirs means that the logic of various >> tests will need to be change to use the unique port mechanism. This >> is a fair chunk of work and it's logically distinct from the othervm >> work. >> >> If we also remove the merging of the MarshalledObject tests, I think >> we can proceed with the othervm changes. >> >> Eric, can you make these changes and send out another webrev? >> >> Thanks. >> >> s'marks >> >> >> >> On 1/16/14 7:18 AM, Eric Wang wrote: >>> Hi Stuart, >>> >>> I have generated a webrev for review, can you please help to check >>> whether the changes are OK. >>> http://cr.openjdk.java.net/~ewang/JDK-8031179/webrev.00/ >>> >>> >>> Also need your help to confirm that the rest 9 tests in previous >>> mail don't need the /othervm option indeed. >>> >>> Thanks, >>> Eric >>> On 2014/1/16 22:55, Eric Wang wrote: >>>> Hi Stuart, >>>> >>>> I'm working on the bug >>>> https://bugs.openjdk.java.net/browse/JDK-8031179 to add /othervm >>>> option to rmi tests, so they can removed from the item othervm.dir >>>> and exclusiveAccess.dirs. >>>> By searching the directories java/rmi, sun/rmi and java/rmi/Naming, >>>> there are 14 tests without othervm option, but only 5 tests need to >>>> the /othervm tag. they are: >>>> >>>> Tests need /othervm option: >>>> java/rmi/Naming/DefaultRegistryPort.java >>>> java/rmi/Naming/legalRegistryNames/LegalRegistryNames.java >>>> java/rmi/Naming/LookupNameWithColon.java >>>> java/rmi/server/UnicastRemoteObject/exportObject/GcDuringExport.java >>>> sun/rmi/rmic/RMIGenerator/RmicDefault.java >>>> >>>> Tests don't need the /othervm option: >>>> java/rmi/activation/ActivationGroupDesc/checkDefaultGroupName/CheckDefaultGroupName.java >>>> >>>> java/rmi/MarshalledObject/compare/Compare.java >>>> java/rmi/MarshalledObject/compare/HashCode.java >>>> java/rmi/MarshalledObject/compare/NullReference.java >>>> java/rmi/server/Unmarshal/PrimitiveClasses.java >>>> sun/rmi/log/ReliableLog/LogAlignmentTest.java >>>> sun/rmi/log/ReliableLog/Recovery.java >>>> sun/rmi/log/ReliableLog/SnapshotSize.java >>>> sun/rmi/rmic/classpath/RMICClassPathTest.java >>>> >>>> Also i have a bit confuse about the test Compare.java and >>>> HashCode.java in java/rmi/MarshalledObject/compare directory, as >>>> they should be merged into one test so that we don't need to add >>>> additional /othervm option for 2 test. >>>> >>>> Thanks, >>>> Eric >>>> >>> >> > From chris.hegarty at oracle.com Fri Jan 24 10:12:38 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 24 Jan 2014 10:12:38 +0000 Subject: JDK8 RFR JDK-8029237 Update copyright year to match last edit in jdk8 jaxws repository for 2013 In-Reply-To: <52E23566.1030506@oracle.com> References: <52D0286B.9020108@oracle.com> <52D8FE89.9080603@oracle.com> <52E0D882.2060904@oracle.com> <598CAECC-C344-4B5D-8AEF-3B755E5BD3EA@oracle.com> <52E23566.1030506@oracle.com> Message-ID: <52E23C96.1020809@oracle.com> Miran, This bug has not been approved for JDK 8, in fact it was considered and rejected. The fix should be pushed to jdk9/dev, if applicable. If the patches apply cleanly I can push it for you. Do you want it in JDK 9? -Chris. On 24/01/14 09:41, Miroslav Kos wrote: > Hi Chris, > thanks for reviewing - I generated the patches today again so now it > should be ok: > http://cr.openjdk.java.net/~mkos/8029237/copyrights-2012-v02.patch > http://cr.openjdk.java.net/~mkos/8029237/copyrights-2013-v02.patch > > Could you push it for me? I have no rights for jdk8. > > I suppose the commit dates (must be in the past) would be imported > correctly: > > copyrights-2012-v02.patch: -d "2012-12-30" > copyrights-2013-v02.patch: -d "2013-12-30" > > Thanks > Miran > > > > On 23/01/14 10:07, Chris Hegarty wrote: >> On 23 Jan 2014, at 08:53, Martin Grebac wrote: >> >>> Hi Miran, did you get any response on this yet? >>> MartiNG >>> >>> On 17/01/14 10:57, Miroslav Kos wrote: >>>> Hi Steve and Alan, >>>> I just reminding this issue - I have no response from anybody yet >>>> and it would really simplify our integration if I could handle >>>> copyright years inconsistencies this way - I see this issue in many >>>> jdk branches and these "each-branch-different" changes make each >>>> integration much more pain. >>>> >>>> Thanks for any idea on this. >>>> >>>> Miran >>>> >>>> >>>> On 10/01/14 18:05, Miroslav Kos wrote: >>>>> Hi, >>>>> this is about fixing copyright years for jdk8 (!); the incorrect >>>>> years found for both 2012 and 2013, so not to confuse script >>>>> jdk8/make/scripts/update_copyright_year.sh >>>>> it is necessary to use option -d "" for commit. I tested that >>>>> and it seems to work perfect. >>>>> I used following: >>>>> >>>>> [2012 modifications] >>>>> hg commit -u mkos -l ../2012-msg.txt -d "2012-12-30" >>>>> >>>>> [2013 modifications] >>>>> hg commit -u mkos -l ../2013-msg.txt -d "2013-12-30" >>>>> >>>>> When commits performed with past date, update_copyright_year.sh >>>>> script finds those in proper years. Since I am not familiar with >>>>> using webrev for pushing changes, I exported both revisions into >>>>> separate patches: >>>>> >>>>> 2012: http://cr.openjdk.java.net/~mkos/8029237/copyrights-2012.patch >> I skimmed the patch and it looks ok to me. >> >> Trivially, it contains a 2013 update (which it should probably be in >> the 2013 patch) >> >> diff -r 91f5c542ccad -r d6aec26c9771 make/Makefile >> --- a/make/Makefile Fri Jan 03 11:54:55 2014 -0800 >> +++ b/make/Makefile Sun Dec 30 00:00:00 2012 +0100 >> @@ -1,5 +1,5 @@ >> # >> -# Copyright (c) 2012, Oracle and/or its affiliates. All rights reserved. >> +# Copyright (c) 2012, 2013, Oracle and/or its affiliates. All rights >> reserved. >> # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> # >> >>>>> 2013: http://cr.openjdk.java.net/~mkos/8029237/copyrights-2013.patch >> Looks ok to me. >> >> -Chris. >> >>>>> all changes webrev: >>>>> http://cr.openjdk.java.net/~mkos/8029237/webrev-all.00/ (upload >>>>> still in progress, I hope it doesn't take more than 30 mins) >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8029237 >>>>> >>>>> Regards >>>>> Miran >>>> >>>> >>> -- >>> Martin Grebac, SW Engineering Manager >>> Oracle Czech, Prague >>> > From miroslav.kos at oracle.com Fri Jan 24 10:50:37 2014 From: miroslav.kos at oracle.com (Miroslav Kos) Date: Fri, 24 Jan 2014 11:50:37 +0100 Subject: JDK8 RFR JDK-8029237 Update copyright year to match last edit in jdk8 jaxws repository for 2013 In-Reply-To: <52E23C96.1020809@oracle.com> References: <52D0286B.9020108@oracle.com> <52D8FE89.9080603@oracle.com> <52E0D882.2060904@oracle.com> <598CAECC-C344-4B5D-8AEF-3B755E5BD3EA@oracle.com> <52E23566.1030506@oracle.com> <52E23C96.1020809@oracle.com> Message-ID: <52E2457D.2070009@oracle.com> Hi Chris, I missed that, sorry. Yes please push it to jdk9, it will do the job there too... Thanks Miran On 24/01/14 11:12, Chris Hegarty wrote: > Miran, > > This bug has not been approved for JDK 8, in fact it was considered > and rejected. The fix should be pushed to jdk9/dev, if applicable. If > the patches apply cleanly I can push it for you. Do you want it in JDK 9? > > -Chris. > > > On 24/01/14 09:41, Miroslav Kos wrote: >> Hi Chris, >> thanks for reviewing - I generated the patches today again so now it >> should be ok: >> http://cr.openjdk.java.net/~mkos/8029237/copyrights-2012-v02.patch >> http://cr.openjdk.java.net/~mkos/8029237/copyrights-2013-v02.patch >> >> Could you push it for me? I have no rights for jdk8. >> >> I suppose the commit dates (must be in the past) would be imported >> correctly: >> >> copyrights-2012-v02.patch: -d "2012-12-30" >> copyrights-2013-v02.patch: -d "2013-12-30" >> >> Thanks >> Miran >> >> >> >> On 23/01/14 10:07, Chris Hegarty wrote: >>> On 23 Jan 2014, at 08:53, Martin Grebac >>> wrote: >>> >>>> Hi Miran, did you get any response on this yet? >>>> MartiNG >>>> >>>> On 17/01/14 10:57, Miroslav Kos wrote: >>>>> Hi Steve and Alan, >>>>> I just reminding this issue - I have no response from anybody yet >>>>> and it would really simplify our integration if I could handle >>>>> copyright years inconsistencies this way - I see this issue in many >>>>> jdk branches and these "each-branch-different" changes make each >>>>> integration much more pain. >>>>> >>>>> Thanks for any idea on this. >>>>> >>>>> Miran >>>>> >>>>> >>>>> On 10/01/14 18:05, Miroslav Kos wrote: >>>>>> Hi, >>>>>> this is about fixing copyright years for jdk8 (!); the incorrect >>>>>> years found for both 2012 and 2013, so not to confuse script >>>>>> jdk8/make/scripts/update_copyright_year.sh >>>>>> it is necessary to use option -d "" for commit. I tested that >>>>>> and it seems to work perfect. >>>>>> I used following: >>>>>> >>>>>> [2012 modifications] >>>>>> hg commit -u mkos -l ../2012-msg.txt -d "2012-12-30" >>>>>> >>>>>> [2013 modifications] >>>>>> hg commit -u mkos -l ../2013-msg.txt -d "2013-12-30" >>>>>> >>>>>> When commits performed with past date, update_copyright_year.sh >>>>>> script finds those in proper years. Since I am not familiar with >>>>>> using webrev for pushing changes, I exported both revisions into >>>>>> separate patches: >>>>>> >>>>>> 2012: http://cr.openjdk.java.net/~mkos/8029237/copyrights-2012.patch >>> I skimmed the patch and it looks ok to me. >>> >>> Trivially, it contains a 2013 update (which it should probably be in >>> the 2013 patch) >>> >>> diff -r 91f5c542ccad -r d6aec26c9771 make/Makefile >>> --- a/make/Makefile Fri Jan 03 11:54:55 2014 -0800 >>> +++ b/make/Makefile Sun Dec 30 00:00:00 2012 +0100 >>> @@ -1,5 +1,5 @@ >>> # >>> -# Copyright (c) 2012, Oracle and/or its affiliates. All rights >>> reserved. >>> +# Copyright (c) 2012, 2013, Oracle and/or its affiliates. All rights >>> reserved. >>> # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> # >>> >>>>>> 2013: http://cr.openjdk.java.net/~mkos/8029237/copyrights-2013.patch >>> Looks ok to me. >>> >>> -Chris. >>> >>>>>> all changes webrev: >>>>>> http://cr.openjdk.java.net/~mkos/8029237/webrev-all.00/ (upload >>>>>> still in progress, I hope it doesn't take more than 30 mins) >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8029237 >>>>>> >>>>>> Regards >>>>>> Miran >>>>> >>>>> >>>> -- >>>> Martin Grebac, SW Engineering Manager >>>> Oracle Czech, Prague >>>> >> From Alan.Bateman at oracle.com Fri Jan 24 11:00:36 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 24 Jan 2014 11:00:36 +0000 Subject: 8032456: vm/jni/Miscellaneous/misc001/misc00101m1/misc00101m1.html failing on OS X Message-ID: <52E247D4.9050202@oracle.com> I need a reviewer to fix an issue with the changes in JDK 8 to support statically linked JNI libraries. The issue arises with tests that have both JNI_OnLoad and JNI_OnLoad_libname functions defined, and code attempts to load the library more than once. In that scenario then both functions are called. Staffan Larsen did the hard work in JDK-8031968 where he observed that dlopen(NULL, RTLD_LAZY) behaves differently on OS X and that we should be using dlopen(NULL, RTLD_FIRST) to get the handle of the main program. Staffan has fixed this in the hotspot repository for JVM TI agent libraries, we need to do the same in the libjava code used by ClassLoader's native methods. Note that the include of string.h is not directly part of the issue here, instead it's just a drive-by fix to the warning related to the strcat usages. -Alan diff --git a/src/solaris/native/common/jni_util_md.c b/src/solaris/native/common/jni_util_md.c --- a/src/solaris/native/common/jni_util_md.c +++ b/src/solaris/native/common/jni_util_md.c @@ -23,6 +23,8 @@ * questions. */ +#include + #include "jni.h" #include "jni_util.h" #include "dlfcn.h" @@ -40,7 +42,11 @@ if (procHandle != NULL) { return procHandle; } - procHandle = (void*)dlopen(NULL, RTLD_LAZY); +#ifdef __APPLE__ + procHandle = (void*)dlopen(NULL, RTLD_FIRST); +#else + procHandle = (void*)dlopen(NULL, RTLD_LAZY); +#endif return procHandle; } From staffan.larsen at oracle.com Fri Jan 24 11:14:59 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 24 Jan 2014 12:14:59 +0100 Subject: 8032456: vm/jni/Miscellaneous/misc001/misc00101m1/misc00101m1.html failing on OS X In-Reply-To: <52E247D4.9050202@oracle.com> References: <52E247D4.9050202@oracle.com> Message-ID: Looks good! :-) Thanks, /Staffan On 24 jan 2014, at 12:00, Alan Bateman wrote: > > I need a reviewer to fix an issue with the changes in JDK 8 to support statically linked JNI libraries. The issue arises with tests that have both JNI_OnLoad and JNI_OnLoad_libname functions defined, and code attempts to load the library more than once. In that scenario then both functions are called. > > Staffan Larsen did the hard work in JDK-8031968 where he observed that dlopen(NULL, RTLD_LAZY) behaves differently on OS X and that we should be using dlopen(NULL, RTLD_FIRST) to get the handle of the main program. Staffan has fixed this in the hotspot repository for JVM TI agent libraries, we need to do the same in the libjava code used by ClassLoader's native methods. > > Note that the include of string.h is not directly part of the issue here, instead it's just a drive-by fix to the warning related to the strcat usages. > > -Alan > > > diff --git a/src/solaris/native/common/jni_util_md.c b/src/solaris/native/common/jni_util_md.c > --- a/src/solaris/native/common/jni_util_md.c > +++ b/src/solaris/native/common/jni_util_md.c > @@ -23,6 +23,8 @@ > * questions. > */ > > +#include > + > #include "jni.h" > #include "jni_util.h" > #include "dlfcn.h" > @@ -40,7 +42,11 @@ > if (procHandle != NULL) { > return procHandle; > } > - procHandle = (void*)dlopen(NULL, RTLD_LAZY); > +#ifdef __APPLE__ > + procHandle = (void*)dlopen(NULL, RTLD_FIRST); > +#else > + procHandle = (void*)dlopen(NULL, RTLD_LAZY); > +#endif > return procHandle; > } > From chris.hegarty at oracle.com Fri Jan 24 11:17:04 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 24 Jan 2014 11:17:04 +0000 Subject: 8032456: vm/jni/Miscellaneous/misc001/misc00101m1/misc00101m1.html failing on OS X In-Reply-To: <52E247D4.9050202@oracle.com> References: <52E247D4.9050202@oracle.com> Message-ID: <52E24BB0.3080402@oracle.com> The change looks good to me Alan. -Chris. On 24/01/14 11:00, Alan Bateman wrote: > > I need a reviewer to fix an issue with the changes in JDK 8 to support > statically linked JNI libraries. The issue arises with tests that have > both JNI_OnLoad and JNI_OnLoad_libname functions defined, and code > attempts to load the library more than once. In that scenario then both > functions are called. > > Staffan Larsen did the hard work in JDK-8031968 where he observed that > dlopen(NULL, RTLD_LAZY) behaves differently on OS X and that we should > be using dlopen(NULL, RTLD_FIRST) to get the handle of the main program. > Staffan has fixed this in the hotspot repository for JVM TI agent > libraries, we need to do the same in the libjava code used by > ClassLoader's native methods. > > Note that the include of string.h is not directly part of the issue > here, instead it's just a drive-by fix to the warning related to the > strcat usages. > > -Alan > > > diff --git a/src/solaris/native/common/jni_util_md.c > b/src/solaris/native/common/jni_util_md.c > --- a/src/solaris/native/common/jni_util_md.c > +++ b/src/solaris/native/common/jni_util_md.c > @@ -23,6 +23,8 @@ > * questions. > */ > > +#include > + > #include "jni.h" > #include "jni_util.h" > #include "dlfcn.h" > @@ -40,7 +42,11 @@ > if (procHandle != NULL) { > return procHandle; > } > - procHandle = (void*)dlopen(NULL, RTLD_LAZY); > +#ifdef __APPLE__ > + procHandle = (void*)dlopen(NULL, RTLD_FIRST); > +#else > + procHandle = (void*)dlopen(NULL, RTLD_LAZY); > +#endif > return procHandle; > } > From paul.sandoz at oracle.com Fri Jan 24 11:19:09 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 24 Jan 2014 12:19:09 +0100 Subject: 8032456: vm/jni/Miscellaneous/misc001/misc00101m1/misc00101m1.html failing on OS X In-Reply-To: <52E247D4.9050202@oracle.com> References: <52E247D4.9050202@oracle.com> Message-ID: On Jan 24, 2014, at 12:00 PM, Alan Bateman wrote: > > I need a reviewer to fix an issue with the changes in JDK 8 to support statically linked JNI libraries. The issue arises with tests that have both JNI_OnLoad and JNI_OnLoad_libname functions defined, and code attempts to load the library more than once. In that scenario then both functions are called. > > Staffan Larsen did the hard work in JDK-8031968 where he observed that dlopen(NULL, RTLD_LAZY) behaves differently on OS X and that we should be using dlopen(NULL, RTLD_FIRST) to get the handle of the main program. Staffan has fixed this in the hotspot repository for JVM TI agent libraries, we need to do the same in the libjava code used by ClassLoader's native methods. > IIUC from reading the docs: https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man3/dlopen.3.html ... discovered during the call to dlopen(). If neither RTLD_LAZY nor RTLD_NOW is specified, the default is RTLD_LAZY. ... RTLD_FIRST The retuned handle is tagged so that any dlsym() calls on the handle will only search the image specified, and not subsequent images. If path is NULL and the option RTLD_FIRST is used, the handle returned will only search the main executable. So more precisely that is "RTLD_LAZY | RTLD_FIRST" ? Paul. > Note that the include of string.h is not directly part of the issue here, instead it's just a drive-by fix to the warning related to the strcat usages. > > -Alan > > > diff --git a/src/solaris/native/common/jni_util_md.c b/src/solaris/native/common/jni_util_md.c > --- a/src/solaris/native/common/jni_util_md.c > +++ b/src/solaris/native/common/jni_util_md.c > @@ -23,6 +23,8 @@ > * questions. > */ > > +#include > + > #include "jni.h" > #include "jni_util.h" > #include "dlfcn.h" > @@ -40,7 +42,11 @@ > if (procHandle != NULL) { > return procHandle; > } > - procHandle = (void*)dlopen(NULL, RTLD_LAZY); > +#ifdef __APPLE__ > + procHandle = (void*)dlopen(NULL, RTLD_FIRST); > +#else > + procHandle = (void*)dlopen(NULL, RTLD_LAZY); > +#endif > return procHandle; > } > From Alan.Bateman at oracle.com Fri Jan 24 11:39:35 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 24 Jan 2014 11:39:35 +0000 Subject: 8032456: vm/jni/Miscellaneous/misc001/misc00101m1/misc00101m1.html failing on OS X In-Reply-To: References: <52E247D4.9050202@oracle.com> Message-ID: <52E250F7.8080604@oracle.com> On 24/01/2014 11:19, Paul Sandoz wrote: > : > > So more precisely that is "RTLD_LAZY | RTLD_FIRST" ? > > Either will do, I went for RTLD_FIRST to be consistent with the hotspot change. -Alan From chris.hegarty at oracle.com Fri Jan 24 11:44:47 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 24 Jan 2014 11:44:47 +0000 Subject: JDK8 RFR JDK-8029237 Update copyright year to match last edit in jdk8 jaxws repository for 2013 In-Reply-To: <52E2457D.2070009@oracle.com> References: <52D0286B.9020108@oracle.com> <52D8FE89.9080603@oracle.com> <52E0D882.2060904@oracle.com> <598CAECC-C344-4B5D-8AEF-3B755E5BD3EA@oracle.com> <52E23566.1030506@oracle.com> <52E23C96.1020809@oracle.com> <52E2457D.2070009@oracle.com> Message-ID: <52E2522F.7030108@oracle.com> Miran, Since you have two separate changesets, I created a subtask and pushed the 2013 updates under that bugId. The changes are now in jdk9/dev. -Chris. On 24/01/14 10:50, Miroslav Kos wrote: > Hi Chris, > I missed that, sorry. Yes please push it to jdk9, it will do the job > there too... > > Thanks > Miran > > On 24/01/14 11:12, Chris Hegarty wrote: >> Miran, >> >> This bug has not been approved for JDK 8, in fact it was considered >> and rejected. The fix should be pushed to jdk9/dev, if applicable. If >> the patches apply cleanly I can push it for you. Do you want it in JDK 9? >> >> -Chris. >> >> >> On 24/01/14 09:41, Miroslav Kos wrote: >>> Hi Chris, >>> thanks for reviewing - I generated the patches today again so now it >>> should be ok: >>> http://cr.openjdk.java.net/~mkos/8029237/copyrights-2012-v02.patch >>> http://cr.openjdk.java.net/~mkos/8029237/copyrights-2013-v02.patch >>> >>> Could you push it for me? I have no rights for jdk8. >>> >>> I suppose the commit dates (must be in the past) would be imported >>> correctly: >>> >>> copyrights-2012-v02.patch: -d "2012-12-30" >>> copyrights-2013-v02.patch: -d "2013-12-30" >>> >>> Thanks >>> Miran >>> >>> >>> >>> On 23/01/14 10:07, Chris Hegarty wrote: >>>> On 23 Jan 2014, at 08:53, Martin Grebac >>>> wrote: >>>> >>>>> Hi Miran, did you get any response on this yet? >>>>> MartiNG >>>>> >>>>> On 17/01/14 10:57, Miroslav Kos wrote: >>>>>> Hi Steve and Alan, >>>>>> I just reminding this issue - I have no response from anybody yet >>>>>> and it would really simplify our integration if I could handle >>>>>> copyright years inconsistencies this way - I see this issue in many >>>>>> jdk branches and these "each-branch-different" changes make each >>>>>> integration much more pain. >>>>>> >>>>>> Thanks for any idea on this. >>>>>> >>>>>> Miran >>>>>> >>>>>> >>>>>> On 10/01/14 18:05, Miroslav Kos wrote: >>>>>>> Hi, >>>>>>> this is about fixing copyright years for jdk8 (!); the incorrect >>>>>>> years found for both 2012 and 2013, so not to confuse script >>>>>>> jdk8/make/scripts/update_copyright_year.sh >>>>>>> it is necessary to use option -d "" for commit. I tested that >>>>>>> and it seems to work perfect. >>>>>>> I used following: >>>>>>> >>>>>>> [2012 modifications] >>>>>>> hg commit -u mkos -l ../2012-msg.txt -d "2012-12-30" >>>>>>> >>>>>>> [2013 modifications] >>>>>>> hg commit -u mkos -l ../2013-msg.txt -d "2013-12-30" >>>>>>> >>>>>>> When commits performed with past date, update_copyright_year.sh >>>>>>> script finds those in proper years. Since I am not familiar with >>>>>>> using webrev for pushing changes, I exported both revisions into >>>>>>> separate patches: >>>>>>> >>>>>>> 2012: http://cr.openjdk.java.net/~mkos/8029237/copyrights-2012.patch >>>> I skimmed the patch and it looks ok to me. >>>> >>>> Trivially, it contains a 2013 update (which it should probably be in >>>> the 2013 patch) >>>> >>>> diff -r 91f5c542ccad -r d6aec26c9771 make/Makefile >>>> --- a/make/Makefile Fri Jan 03 11:54:55 2014 -0800 >>>> +++ b/make/Makefile Sun Dec 30 00:00:00 2012 +0100 >>>> @@ -1,5 +1,5 @@ >>>> # >>>> -# Copyright (c) 2012, Oracle and/or its affiliates. All rights >>>> reserved. >>>> +# Copyright (c) 2012, 2013, Oracle and/or its affiliates. All rights >>>> reserved. >>>> # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>> # >>>> >>>>>>> 2013: http://cr.openjdk.java.net/~mkos/8029237/copyrights-2013.patch >>>> Looks ok to me. >>>> >>>> -Chris. >>>> >>>>>>> all changes webrev: >>>>>>> http://cr.openjdk.java.net/~mkos/8029237/webrev-all.00/ (upload >>>>>>> still in progress, I hope it doesn't take more than 30 mins) >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8029237 >>>>>>> >>>>>>> Regards >>>>>>> Miran >>>>>> >>>>>> >>>>> -- >>>>> Martin Grebac, SW Engineering Manager >>>>> Oracle Czech, Prague >>>>> >>> > From paul.sandoz at oracle.com Fri Jan 24 11:47:26 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 24 Jan 2014 12:47:26 +0100 Subject: 8032456: vm/jni/Miscellaneous/misc001/misc00101m1/misc00101m1.html failing on OS X In-Reply-To: <52E250F7.8080604@oracle.com> References: <52E247D4.9050202@oracle.com> <52E250F7.8080604@oracle.com> Message-ID: <38D531E7-A33B-4AA2-82C0-AD66E52F46C8@oracle.com> On Jan 24, 2014, at 12:39 PM, Alan Bateman wrote: > On 24/01/2014 11:19, Paul Sandoz wrote: >> : >> >> So more precisely that is "RTLD_LAZY | RTLD_FIRST" ? >> >> > Either will do, I went for RTLD_FIRST to be consistent with the hotspot change. > OK, i don't have much experience of this area so my opinion lacks weight, but given the subtly of this bug it might help future readers if we are as explicit as possible. Anyway, don't wanna block this things over that point. Paul. From paul.sandoz at oracle.com Fri Jan 24 14:45:58 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 24 Jan 2014 15:45:58 +0100 Subject: RFR: Update code in java.lang to use new language features Message-ID: Hi, Here are some patches that update code in java.lang to use newer language features. I will log a bug and fold into one patch once reviewed. Locally run java.lang tests all pass, but i will also kick off a JPRT test. Paul. -- http://cr.openjdk.java.net/~psandoz/jdk9/java.lang-diamonds/ -- http://cr.openjdk.java.net/~psandoz/jdk9/java.lang-foreach/ I think the update to java.lang.invoke.MutableCallSite.java should be safe: public static void syncAll(MutableCallSite[] sites) { if (sites.length == 0) return; STORE_BARRIER.lazySet(0); - for (int i = 0; i < sites.length; i++) { - sites[i].getClass(); // trigger NPE on first null + for (MutableCallSite site : sites) { + site.getClass(); // trigger NPE on first null } // FIXME: NYI } However, that got me wondering about that STORE_BARRIER. IIUC it is using a static AtomicInteger and a call to lazySet to in effect emulate a StoreStore (release) barrier or the equivalent of Unsafe.storeFence, so the AtomicInteger could be replaced with Unsafe. (When there is an update to the JMM it might be possible to update docs on syncAll.) -- http://cr.openjdk.java.net/~psandoz/jdk9/java.lang-StringBuilder/ -- http://cr.openjdk.java.net/~psandoz/jdk9/java.lang-collapse-catches/ -- http://cr.openjdk.java.net/~psandoz/jdk9/java.lang-boxing/ From aleksey.shipilev at oracle.com Fri Jan 24 15:01:24 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 24 Jan 2014 19:01:24 +0400 Subject: MutableCallSite.syncAll() (Re: RFR: Update code in java.lang to use new language features) In-Reply-To: References: Message-ID: <52E28044.5030307@oracle.com> On 01/24/2014 06:45 PM, Paul Sandoz wrote: > I think the update to java.lang.invoke.MutableCallSite.java should be safe: > > public static void syncAll(MutableCallSite[] sites) { > if (sites.length == 0) return; > STORE_BARRIER.lazySet(0); > - for (int i = 0; i < sites.length; i++) { > - sites[i].getClass(); // trigger NPE on first null > + for (MutableCallSite site : sites) { > + site.getClass(); // trigger NPE on first null > } > // FIXME: NYI > } > > However, that got me wondering about that STORE_BARRIER. IIUC it is > using a static AtomicInteger and a call to lazySet to in effect > emulate a StoreStore (release) barrier or the equivalent of > Unsafe.storeFence, so the AtomicInteger could be replaced with > Unsafe. (When there is an update to the JMM it might be possible to > update docs on syncAll.) Thanks for reminding me about this. The "JMM Details" outlined in Javadoc for MutableCallSite.syncAll() [1] seem wishful thinking to me. Particularly the part when the notion of SO totality somehow transforms into visibility for non-synchronization-action reads. The point about "synchronization-order consistency" is a moot, because it is only spec-ed for volatile actions. The visibility guarantees for everything else are provided by HB, which is not applicable here. That is, spec-wise, without the paired volatile read of the same AtomicInteger observing the written value, we are not guaranteed to see the updated MutableCallSite value. Since JEP 188 tries to also rigorously spec fences, I'll ping Doug to add this into JEP 188 tally. -Aleksey. [1] http://docs.oracle.com/javase/7/docs/api/java/lang/invoke/MutableCallSite.html#syncAll(java.lang.invoke.MutableCallSite[]) From paul.sandoz at oracle.com Fri Jan 24 15:35:37 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 24 Jan 2014 16:35:37 +0100 Subject: Survey on sun.misc.Unsafe Message-ID: <1229496F-0624-436A-A08F-8127CB4FE065@oracle.com> Hi, We are gathering feedback on sun.misc.Unsafe usage. If you have ever used it please consider taking this survey and helping us out: https://www.surveymonkey.com/s/sun-misc-Unsafe -- We also plan to trawl stuff on repos. I have done a selective bit of that already, running with a little tool spitting out method usage stats. I would have included a link to that tool but it is dependent on Java 8. If anyone still wants to use it let me know and i can put that code on GitHub. Paul. From joe.darcy at oracle.com Fri Jan 24 16:00:06 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 24 Jan 2014 08:00:06 -0800 Subject: RFR: Update code in java.lang to use new language features In-Reply-To: References: Message-ID: <52E28E06.3070206@oracle.com> On 01/24/2014 06:45 AM, Paul Sandoz wrote: > Hi, > > Here are some patches that update code in java.lang to use newer language features. I will log a bug and fold into one patch once reviewed. > > Locally run java.lang tests all pass, but i will also kick off a JPRT test. > > Paul. > > -- > http://cr.openjdk.java.net/~psandoz/jdk9/java.lang-diamonds/ > > -- > http://cr.openjdk.java.net/~psandoz/jdk9/java.lang-foreach/ I've looked over diamond and for-each and they both look good; approved to go back :-) -Joe From Alan.Bateman at oracle.com Fri Jan 24 17:02:46 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 24 Jan 2014 17:02:46 +0000 Subject: RFR: Update code in java.lang to use new language features In-Reply-To: References: Message-ID: <52E29CB6.9010404@oracle.com> On 24/01/2014 14:45, Paul Sandoz wrote: > > -- > http://cr.openjdk.java.net/~psandoz/jdk9/java.lang-StringBuilder/ > > -- > http://cr.openjdk.java.net/~psandoz/jdk9/java.lang-collapse-catches/ > > -- > http://cr.openjdk.java.net/~psandoz/jdk9/java.lang-boxing/ > I looked through the StringBuilder, multi-catch and the improvement to ConditionalSpecialCasing's initializer. Looks okay to me. -Alan. From volker.simonis at gmail.com Fri Jan 24 17:04:27 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 24 Jan 2014 18:04:27 +0100 Subject: RFR(XS): 8032678: [TESTBUG] sun/misc/Version/Version.java doesn't understand two-digit HotSpot minor version numbers Message-ID: Hi, could you please review the following trivial change: http://cr.openjdk.java.net/~simonis/webrevs/8032678/ which fixes the JDK test jdk/test/sun/misc/Version/Version.java to correctly handle two-digit HotSpot minor version numbers. This became necessary after change "8031552: Update the Hotspot version numbers in Hotspot for JDK 8U" bumped the minor HS version to '20' in jdk8u. This webrev is for jdk9 but it will have to be backported to jdk8u because there?s where the current problem happens. Thanks, Volker From paul.sandoz at oracle.com Fri Jan 24 17:10:15 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 24 Jan 2014 18:10:15 +0100 Subject: RFR: Update code in java.lang to use new language features In-Reply-To: <52E29CB6.9010404@oracle.com> References: <52E29CB6.9010404@oracle.com> Message-ID: <6F62748D-66A2-40D2-9069-F6829B66316D@oracle.com> Hi Joe, Alan, Many thanks! Before folding/committing i will kick off a JPRT job (if i can get it to work on 9!) -- BTW if one uses IntelliJ it is very easy to make such changes, review and tweak them. Select menu item "Analyze -> Run Inspection By Name..". and type in "migration". Hint hint for anyone else who wants to have a go on other packages :-) Paul. On Jan 24, 2014, at 6:02 PM, Alan Bateman wrote: > On 24/01/2014 14:45, Paul Sandoz wrote: >> >> -- >> http://cr.openjdk.java.net/~psandoz/jdk9/java.lang-StringBuilder/ >> >> -- >> http://cr.openjdk.java.net/~psandoz/jdk9/java.lang-collapse-catches/ >> >> -- >> http://cr.openjdk.java.net/~psandoz/jdk9/java.lang-boxing/ >> > I looked through the StringBuilder, multi-catch and the improvement to ConditionalSpecialCasing's initializer. Looks okay to me. > > -Alan. From vladimir.kozlov at oracle.com Fri Jan 24 17:13:15 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 24 Jan 2014 09:13:15 -0800 Subject: RFR(XS): 8032678: [TESTBUG] sun/misc/Version/Version.java doesn't understand two-digit HotSpot minor version numbers In-Reply-To: References: Message-ID: <52E29F2B.4000402@oracle.com> Good change. I got this failure too. Thanks, Vladimir On 1/24/14 9:04 AM, Volker Simonis wrote: > Hi, > > could you please review the following trivial change: > > http://cr.openjdk.java.net/~simonis/webrevs/8032678/ > > which fixes the JDK test jdk/test/sun/misc/Version/Version.java to > correctly handle two-digit HotSpot minor version numbers. This became > necessary after change "8031552: Update the Hotspot version numbers in > Hotspot for JDK 8U" bumped the minor HS version to '20' in jdk8u. > > This webrev is for jdk9 but it will have to be backported to jdk8u > because there?s where the current problem happens. > > Thanks, > Volker > From mandy.chung at oracle.com Fri Jan 24 17:43:16 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 24 Jan 2014 09:43:16 -0800 Subject: 8032456: vm/jni/Miscellaneous/misc001/misc00101m1/misc00101m1.html failing on OS X In-Reply-To: <52E247D4.9050202@oracle.com> References: <52E247D4.9050202@oracle.com> Message-ID: <52E2A634.1000602@oracle.com> This patch looks fine. For JDK 9, it might be worth considering using the common code via JVM functions to replace getProcessHandle, JDK_FindJvmEntry, JDK_InitJvmEntry for native symbol lookup (jni_util.h and jdk_util.h) Mandy On 1/24/2014 3:00 AM, Alan Bateman wrote: > > I need a reviewer to fix an issue with the changes in JDK 8 to support > statically linked JNI libraries. The issue arises with tests that have > both JNI_OnLoad and JNI_OnLoad_libname functions defined, and code > attempts to load the library more than once. In that scenario then > both functions are called. > > Staffan Larsen did the hard work in JDK-8031968 where he observed that > dlopen(NULL, RTLD_LAZY) behaves differently on OS X and that we should > be using dlopen(NULL, RTLD_FIRST) to get the handle of the main > program. Staffan has fixed this in the hotspot repository for JVM TI > agent libraries, we need to do the same in the libjava code used by > ClassLoader's native methods. > > Note that the include of string.h is not directly part of the issue > here, instead it's just a drive-by fix to the warning related to the > strcat usages. > > -Alan > > > diff --git a/src/solaris/native/common/jni_util_md.c > b/src/solaris/native/common/jni_util_md.c > --- a/src/solaris/native/common/jni_util_md.c > +++ b/src/solaris/native/common/jni_util_md.c > @@ -23,6 +23,8 @@ > * questions. > */ > > +#include > + > #include "jni.h" > #include "jni_util.h" > #include "dlfcn.h" > @@ -40,7 +42,11 @@ > if (procHandle != NULL) { > return procHandle; > } > - procHandle = (void*)dlopen(NULL, RTLD_LAZY); > +#ifdef __APPLE__ > + procHandle = (void*)dlopen(NULL, RTLD_FIRST); > +#else > + procHandle = (void*)dlopen(NULL, RTLD_LAZY); > +#endif > return procHandle; > } > From volker.simonis at gmail.com Fri Jan 24 18:39:14 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 24 Jan 2014 19:39:14 +0100 Subject: RFR(XS): 8032678: [TESTBUG] sun/misc/Version/Version.java doesn't understand two-digit HotSpot minor version numbers In-Reply-To: <52E29F2B.4000402@oracle.com> References: <52E29F2B.4000402@oracle.com> Message-ID: Hi Vladimir, I've just pushed this to jdk9/dev. I also received an email stating that "this bug needs to be updated, please request to defer or upgrade to P1 and request for approval". I assume that's because I entered "8-pool, 9" as "Fix versions". Now I actually don't know what to do. It seems strange to upgrade this to P1 because it is only a test bug. On the other hand it is needed in 8u because there's where we have the trouble. So should I upgrade it to P1 and request approval for jdk8u-dev (or directly jdk8u)? The actual problem occurs in jdk8u only, because jdk8u-dev doesn't yet has change 8032678 which bumps the HS minor number to 20. Can I push directly to jdk8u or does the change has to go trough jdk8u-dev? Thanks, Volker On Fri, Jan 24, 2014 at 6:13 PM, Vladimir Kozlov wrote: > Good change. I got this failure too. > > Thanks, > Vladimir > > > On 1/24/14 9:04 AM, Volker Simonis wrote: >> >> Hi, >> >> could you please review the following trivial change: >> >> http://cr.openjdk.java.net/~simonis/webrevs/8032678/ >> >> which fixes the JDK test jdk/test/sun/misc/Version/Version.java to >> correctly handle two-digit HotSpot minor version numbers. This became >> necessary after change "8031552: Update the Hotspot version numbers in >> Hotspot for JDK 8U" bumped the minor HS version to '20' in jdk8u. >> >> This webrev is for jdk9 but it will have to be backported to jdk8u >> because there?s where the current problem happens. >> >> Thanks, >> Volker >> > From joe.darcy at oracle.com Fri Jan 24 18:47:54 2014 From: joe.darcy at oracle.com (Joseph Darcy) Date: Fri, 24 Jan 2014 10:47:54 -0800 Subject: RFR(XS): 8032678: [TESTBUG] sun/misc/Version/Version.java doesn't understand two-digit HotSpot minor version numbers In-Reply-To: References: <52E29F2B.4000402@oracle.com> Message-ID: <52E2B55A.1000807@oracle.com> I've removed the incorrect-for-JBS multiple release values of "8-pool, 9" in the fixVersion field of the main bug record. -Joe On 1/24/2014 10:39 AM, Volker Simonis wrote: > Hi Vladimir, > > I've just pushed this to jdk9/dev. > > I also received an email stating that "this bug needs to be updated, > please request to defer or upgrade to P1 and request for approval". I > assume that's because I entered "8-pool, 9" as "Fix versions". > > Now I actually don't know what to do. It seems strange to upgrade this > to P1 because it is only a test bug. On the other hand it is needed in > 8u because there's where we have the trouble. > > So should I upgrade it to P1 and request approval for jdk8u-dev (or > directly jdk8u)? The actual problem occurs in jdk8u only, because > jdk8u-dev doesn't yet has change 8032678 which bumps the HS minor > number to 20. > > Can I push directly to jdk8u or does the change has to go trough jdk8u-dev? > > Thanks, > Volker > > On Fri, Jan 24, 2014 at 6:13 PM, Vladimir Kozlov > wrote: >> Good change. I got this failure too. >> >> Thanks, >> Vladimir >> >> >> On 1/24/14 9:04 AM, Volker Simonis wrote: >>> Hi, >>> >>> could you please review the following trivial change: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/8032678/ >>> >>> which fixes the JDK test jdk/test/sun/misc/Version/Version.java to >>> correctly handle two-digit HotSpot minor version numbers. This became >>> necessary after change "8031552: Update the Hotspot version numbers in >>> Hotspot for JDK 8U" bumped the minor HS version to '20' in jdk8u. >>> >>> This webrev is for jdk9 but it will have to be backported to jdk8u >>> because there?s where the current problem happens. >>> >>> Thanks, >>> Volker >>> From volker.simonis at gmail.com Fri Jan 24 18:44:24 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 24 Jan 2014 19:44:24 +0100 Subject: RFR(XS): 8032678: [TESTBUG] sun/misc/Version/Version.java doesn't understand two-digit HotSpot minor version numbers In-Reply-To: References: <52E29F2B.4000402@oracle.com> Message-ID: And I just noticed from Alejandro's mail that there also exists hs24.60 for 7u60 now. So if somebody is interested in cleanly passing the jtreg tests on 7u60 this change will also has to be backported to 7u. On Fri, Jan 24, 2014 at 7:39 PM, Volker Simonis wrote: > Hi Vladimir, > > I've just pushed this to jdk9/dev. > > I also received an email stating that "this bug needs to be updated, > please request to defer or upgrade to P1 and request for approval". I > assume that's because I entered "8-pool, 9" as "Fix versions". > > Now I actually don't know what to do. It seems strange to upgrade this > to P1 because it is only a test bug. On the other hand it is needed in > 8u because there's where we have the trouble. > > So should I upgrade it to P1 and request approval for jdk8u-dev (or > directly jdk8u)? The actual problem occurs in jdk8u only, because > jdk8u-dev doesn't yet has change 8032678 which bumps the HS minor > number to 20. > > Can I push directly to jdk8u or does the change has to go trough jdk8u-dev? > > Thanks, > Volker > > On Fri, Jan 24, 2014 at 6:13 PM, Vladimir Kozlov > wrote: >> Good change. I got this failure too. >> >> Thanks, >> Vladimir >> >> >> On 1/24/14 9:04 AM, Volker Simonis wrote: >>> >>> Hi, >>> >>> could you please review the following trivial change: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/8032678/ >>> >>> which fixes the JDK test jdk/test/sun/misc/Version/Version.java to >>> correctly handle two-digit HotSpot minor version numbers. This became >>> necessary after change "8031552: Update the Hotspot version numbers in >>> Hotspot for JDK 8U" bumped the minor HS version to '20' in jdk8u. >>> >>> This webrev is for jdk9 but it will have to be backported to jdk8u >>> because there?s where the current problem happens. >>> >>> Thanks, >>> Volker >>> >> From vladimir.kozlov at oracle.com Fri Jan 24 18:52:17 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 24 Jan 2014 10:52:17 -0800 Subject: RFR(XS): 8032678: [TESTBUG] sun/misc/Version/Version.java doesn't understand two-digit HotSpot minor version numbers In-Reply-To: References: <52E29F2B.4000402@oracle.com> Message-ID: <52E2B661.2080300@oracle.com> I updated Fix versions to 8u20. No need to upgrade since you are not pushing to jdk8. You need to send request for approval to push into 8u20 to jdk8u-dev at openjdk.java.net I attached example. After approval, you can push to: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk Regards, Vladimir On 1/24/14 10:39 AM, Volker Simonis wrote: > Hi Vladimir, > > I've just pushed this to jdk9/dev. > > I also received an email stating that "this bug needs to be updated, > please request to defer or upgrade to P1 and request for approval". I > assume that's because I entered "8-pool, 9" as "Fix versions". > > Now I actually don't know what to do. It seems strange to upgrade this > to P1 because it is only a test bug. On the other hand it is needed in > 8u because there's where we have the trouble. > > So should I upgrade it to P1 and request approval for jdk8u-dev (or > directly jdk8u)? The actual problem occurs in jdk8u only, because > jdk8u-dev doesn't yet has change 8032678 which bumps the HS minor > number to 20. > > Can I push directly to jdk8u or does the change has to go trough jdk8u-dev? > > Thanks, > Volker > > On Fri, Jan 24, 2014 at 6:13 PM, Vladimir Kozlov > wrote: >> Good change. I got this failure too. >> >> Thanks, >> Vladimir >> >> >> On 1/24/14 9:04 AM, Volker Simonis wrote: >>> >>> Hi, >>> >>> could you please review the following trivial change: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/8032678/ >>> >>> which fixes the JDK test jdk/test/sun/misc/Version/Version.java to >>> correctly handle two-digit HotSpot minor version numbers. This became >>> necessary after change "8031552: Update the Hotspot version numbers in >>> Hotspot for JDK 8U" bumped the minor HS version to '20' in jdk8u. >>> >>> This webrev is for jdk9 but it will have to be backported to jdk8u >>> because there?s where the current problem happens. >>> >>> Thanks, >>> Volker >>> >> -------------- next part -------------- An embedded message was scrubbed... From: Jaroslav Bachorik Subject: [8u20] request for approval to backport 8022221: Intermittent test failures in sun/management/jmxremote/startstop/JMXStartStopTest.sh Date: Wed, 22 Jan 2014 14:43:23 +0100 Size: 3487 URL: From huizhe.wang at oracle.com Fri Jan 24 20:31:00 2014 From: huizhe.wang at oracle.com (huizhe wang) Date: Fri, 24 Jan 2014 12:31:00 -0800 Subject: RFR (JAXP): 8032392 : Spec: javax.xml.stream.XMLEventFactory/XMLOutputFactory/XMLInputFactory.newFactory(String, ClassLoader) referring to ServiceLoader.load(Class, ClassLoader) Message-ID: <52E2CD84.1030303@oracle.com> Hi, Please review a javadoc change to javax.xml.stream factories. This change makes it clear that the two args ServiceLoader#load method is used when the specified classLoader is not null. http://cr.openjdk.java.net/~joehw/jdk9/8032392/webrev/ Thanks, Joe From daniel.fuchs at oracle.com Fri Jan 24 20:51:14 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 24 Jan 2014 21:51:14 +0100 Subject: RFR (JAXP): 8032392 : Spec: javax.xml.stream.XMLEventFactory/XMLOutputFactory/XMLInputFactory.newFactory(String, ClassLoader) referring to ServiceLoader.load(Class, ClassLoader) In-Reply-To: <52E2CD84.1030303@oracle.com> References: <52E2CD84.1030303@oracle.com> Message-ID: <52E2D242.40705@oracle.com> Hi, It looks fine to me Joe. best regards, -- daniel On 1/24/14 9:31 PM, huizhe wang wrote: > Hi, > > Please review a javadoc change to javax.xml.stream factories. This > change makes it clear that the two args ServiceLoader#load method is > used when the specified classLoader is not null. > > http://cr.openjdk.java.net/~joehw/jdk9/8032392/webrev/ > > Thanks, > Joe > From Lance.Andersen at oracle.com Fri Jan 24 20:53:50 2014 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Fri, 24 Jan 2014 15:53:50 -0500 Subject: RFR (JAXP): 8032392 : Spec: javax.xml.stream.XMLEventFactory/XMLOutputFactory/XMLInputFactory.newFactory(String, ClassLoader) referring to ServiceLoader.load(Class, ClassLoader) In-Reply-To: <52E2CD84.1030303@oracle.com> References: <52E2CD84.1030303@oracle.com> Message-ID: +1 On Jan 24, 2014, at 3:31 PM, huizhe wang wrote: > Hi, > > Please review a javadoc change to javax.xml.stream factories. This change makes it clear that the two args ServiceLoader#load method is used when the specified classLoader is not null. > > http://cr.openjdk.java.net/~joehw/jdk9/8032392/webrev/ > > Thanks, > Joe > -------------- next part -------------- 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 huizhe.wang at oracle.com Fri Jan 24 21:31:45 2014 From: huizhe.wang at oracle.com (huizhe wang) Date: Fri, 24 Jan 2014 13:31:45 -0800 Subject: RFR (JAXP): 8032392 : Spec: javax.xml.stream.XMLEventFactory/XMLOutputFactory/XMLInputFactory.newFactory(String, ClassLoader) referring to ServiceLoader.load(Class, ClassLoader) In-Reply-To: References: <52E2CD84.1030303@oracle.com> Message-ID: <52E2DBC1.8000909@oracle.com> Thanks Lance, Daniel. On 1/24/2014 12:53 PM, Lance Andersen - Oracle wrote: > +1 > On Jan 24, 2014, at 3:31 PM, huizhe wang wrote: > >> Hi, >> >> Please review a javadoc change to javax.xml.stream factories. This change makes it clear that the two args ServiceLoader#load method is used when the specified classLoader is not null. >> >> http://cr.openjdk.java.net/~joehw/jdk9/8032392/webrev/ >> >> Thanks, >> Joe >> > > > 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 golovnin at gmx.net Fri Jan 24 21:36:01 2014 From: golovnin at gmx.net (Andrej Golovnin) Date: Fri, 24 Jan 2014 22:36:01 +0100 Subject: Which optimizations does Hotspot apply? In-Reply-To: References: <09548E95-EA91-4986-A692-EC2DCE0944BB@snazy.de> <52E05640.3020000@univ-mlv.fr> Message-ID: Hi R?mi, > With latest jdk8, it's not true anymore. > (and most of the time the iterator object is not created anymore at least with jdk7+). Could you please explain it a little bit more? When is that optimization applied, e.g. what conditions are required for this optimization, since which version of JDK/Hotspot it is supported, where it is implemented in JDK? When I take look at a product I'm working on, I see a lot instances of ArrayList$Itr objects, which are created by for-each loops (we use JDK 7u51). Thanks in advance! Best regards, Andrej Golovnin From vitalyd at gmail.com Fri Jan 24 22:01:49 2014 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 24 Jan 2014 17:01:49 -0500 Subject: Which optimizations does Hotspot apply? In-Reply-To: References: <09548E95-EA91-4986-A692-EC2DCE0944BB@snazy.de> <52E05640.3020000@univ-mlv.fr> Message-ID: This would be predicated on escape analysis, whose effectiveness is in turn driven by sufficient inlining whereby compiler can see that instance doesn't escape. Inlining, in turn, can be screwed up by (amongst other things) polymorphic call sites. So in the end, it's all quite brittle and sensitive :). Personally, in places where it matters, I try to allocate as little as possible explicitly - a lot of times much more effective than hoping compiler helps out and/or turning GC knobs. Sent from my phone On Jan 24, 2014 4:36 PM, "Andrej Golovnin" wrote: > Hi R?mi, > > > With latest jdk8, it's not true anymore. > > (and most of the time the iterator object is not created anymore at > least with jdk7+). > > Could you please explain it a little bit more? When is that optimization > applied, > e.g. what conditions are required for this optimization, since which > version > of JDK/Hotspot it is supported, where it is implemented in JDK? > > When I take look at a product I'm working on, I see a lot instances of > ArrayList$Itr objects, > which are created by for-each loops (we use JDK 7u51). > > Thanks in advance! > > Best regards, > Andrej Golovnin > > > From peter.levart at gmail.com Sat Jan 25 00:05:54 2014 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 25 Jan 2014 01:05:54 +0100 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52E1C7AD.8090100@oracle.com> References: <52B3568B.5050905@oracle.com> <52CB4CFC.9070405@oracle.com> <52CC72AB.2020104@oracle.com> <52CCEDE0.8000809@oracle.com> <52CCF079.4090301@oracle.com> <52CD45E7.7010203@gmail.com> <52CE4E2D.300@oracle.com> <52CF37C6.1070605@oracle.com> <52CFAFEB.9090703@gmail.com> <52CFD218.2060101@gmail.com> <52D06B70.60001@oracle.com> <52D15201.90109@gmail.com> <52D47D59.8040905@oracle.com> <52D72577.1050506@oracle.com> <52D76859.2030502@oracle.com> <52D82968.4030608@oracle.com> <52D8929B.2020905@oracle.com> <52D8A42A.4020906@oracle.com> <52D8B3B6.3030202@oracle.com> <52D9295D.6080106@gmail.com> <52D92C73.2020309@gmail.com> <52D92F1A.4040400@gmail.com> <52DC812C.1000607@oracle.com> <52DCD78E.8050404@gmail.com> <52DCE17B.4050708@gmail.com> <52DDD9F3.1050201@oracle.com> <52DE19C1.2070302@gmail.com> <52DE9147.4030305@gmail.com> <52DEB9C4.4030606@oracle.com> <52DEF53C.3050905@gmail.com> <52E1772A.1050608@oracle.com> <52E1B4C5.8050807@oracle.com> <52E1C7AD.8090100@oracle.com> Message-ID: <52E2FFE2.7000600@gmail.com> On 01/24/2014 02:53 AM, srikalyan chandrashekar wrote: > Hi David, yes thats right, only benefit i see is we can avoid > assignment to 'r' if pending is null. Hi Kalyan, Good to hear that test runs without failures so far. Regarding assignment of 'r'. What I tried to accomplish with the change was eliminate double reading of 'pending' field. I have a mental model of local variable being a register and field being a memory location. This may be important if the field is volatile, but for normal fields, I guess the optimizer knows how to compile such code most optimally in either case. The old (your) version is better from logical perspective, since it guarantees that dereferencing the 'r', wherever it is possible, will never throw NPE (dereferencing where 'r' is not assigned is not possible because of definitive assignment rules). So I support going back to your version... Regards, Peter > > -- > Thanks > kalyan > > On 1/23/14 4:33 PM, David Holmes wrote: >> On 24/01/2014 6:10 AM, srikalyan wrote: >>> Hi Peter, i have modified your code from >>> >>> r = pending; >>> if (r != null) { >>> ...... >>> TO >>> if (pending != null) { >>> r = pending; >>> >>> This is because the r is used later in the code and must not be >>> assigned >>> pending unless it is not null(this was as is earlier). >> >> If r is null, because pending is null then you perform the wait() and >> then continue - back to the top of the loop. There is no bug in >> Peter's code. >> >> The new webrev is >>> posted here >>> http://cr.openjdk.java.net/~srikchan/Regression/JDK-8022321_OOMEInReferenceHandler-webrev-V2/ >>> >>> . I ran a 1000 run and no failures so far, however i would like to >>> run a >>> couple more 1000 runs to assert the fix. >>> >>> PS: The description section of JEP-122 >>> (http://openjdk.java.net/jeps/122) says meta-data would be in native >>> memory(not heap). >> >> The class_mirror is a Java object not meta-data. >> >> David >> >>> -- >>> Thanks >>> kalyan >>> Ph: (408)-585-8040 >>> >>> >>> On 1/21/14, 2:31 PM, Peter Levart wrote: >>>> >>>> On 01/21/2014 07:17 PM, srikalyan wrote: >>>>> Hi Peter/David, catching up after long weekend. Why would there be an >>>>> OOME in object heap due to class loading in perm gen space ? >>>> >>>> The perm gen is not a problem her (JDK 8 does not have it and we see >>>> OOME on JDK8 too). Each time a class is loaded, new java.lang.Class >>>> object is allocated on heap. >>>> >>>> Regards, Peter >>>> >>>>> Please correct if i am missing something here. Meanwhile i will give >>>>> the version of Reference Handler you both agreed on a try. >>>>> -- >>>>> Thanks >>>>> kalyan >>>>> Ph: (408)-585-8040 >>>>> >>>>> On 1/21/14, 7:24 AM, Peter Levart wrote: >>>>>> On 01/21/2014 07:54 AM, Peter Levart wrote: >>>>>>> *[Loaded sun.misc.Cleaner from >>>>>>> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar]* >>>>>>> [Loaded java.io.ByteArrayInputStream from >>>>>>> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >>>>>>> [Loaded sun.util.calendar.ZoneInfoFile$ZoneOffsetTransitionRule >>>>>>> from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >>>>>>> ... >>>>>>> >>>>>>> >>>>>>> I'm on linux, 64bit and using official EA build 121 of JDK 8... >>>>>>> >>>>>>> But if I try with JDK 7u45, I don't see it. >>>>>> >>>>>> So what changed between JDK 7 and JDK 8? >>>>>> >>>>>> I suspect the following: 8007572: Replace existing jdk timezone data >>>>>> at /lib/zi with JSR310's tzdb >>>>>> >>>>>> >>>>>> Regards, Peter >>>>>> >>>> > From peter.levart at gmail.com Sat Jan 25 00:44:41 2014 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 25 Jan 2014 01:44:41 +0100 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52DF2A99.6010805@oracle.com> References: <52B3568B.5050905@oracle.com> <52B398A2.8030307@oracle.com> <52B3B22C.20701@oracle.com> <52B3E86B.3050707@oracle.com> <52CB4CFC.9070405@oracle.com> <52CC72AB.2020104@oracle.com> <52CCEDE0.8000809@oracle.com> <52CCF079.4090301@oracle.com> <52CD45E7.7010203@gmail.com> <52CE4E2D.300@oracle.com> <52CF37C6.1070605@oracle.com> <52CFAFEB.9090703@gmail.com> <52CFD218.2060101@gmail.com> <52D06B70.60001@oracle.com> <52D15201.90109@gmail.com> <52D47D59.8040905@oracle.com> <52D72577.1050506@oracle.com> <52D76859.2030502@oracle.com> <52D82968.4030608@oracle.com> <52D8929B.2020905@oracle.com> <52D8A42A.4020906@oracle.com> <52D8B3B6.3030202@oracle.com> <52D9295D.6080106@gmail.com> <52D92C73.2020309@gmail.com> <52D92F1A.4040400@gmail.com> <52DC812C.1000607@oracle.com> <52DCD78E.8050404@gmail.com> <52DCE17B.4050708@gmail.com> <52DDD9F3.1050201@oracle.com> <52DE19C1.2070302@gmail.com> <52DE2883.5010100@oracle.com> <52DE7D7A.80501@gmail.com> <52DF2A99.6010805@oracle.com> Message-ID: <52E308F9.7000305@gmail.com> On 01/22/2014 03:19 AM, David Holmes wrote: > Hi Peter, > > On 22/01/2014 12:00 AM, Peter Levart wrote: >> Hi, David, Kalyan, >> >> Summing up the discussion, I propose the following patch for >> ReferenceHandler: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/OOMEInReferenceHandler/webrev.01/ >> > > I can live with it, though it maybe that once Cleaner has been > preloaded instanceof can no longer throw OOME. Can't be 100% sure. And > there's some duplication/verbosity in the commentary that could be > trimmed down :) > > Any specific reason to use Unsafe to do the preload rather than > Class.forName ? Does this force Unsafe to be loaded earlier than it > otherwise would? Good question. In systemDictionary.hpp they are both on the preloaded list in this order: do_klass(Reference_klass, java_lang_ref_Reference, Pre ) \ ... do_klass(misc_Unsafe_klass, sun_misc_Unsafe, Pre ) \ So when Reference is initialized, the Unsafe is already loaded. But I don't know if it is already initialized. This should be studied. I'll try to find out what is the case and get back to you. Regards, Peter > > Thanks, > David > >> >> all 10 java/lang/ref tests pass on my PC (including >> OOMEInReferenceHandler). >> >> I kindly ask Kalyan to try to re-run the OOMEInReferenceHandler test >> with this code and report any failure. >> >> >> Thanks, Peter >> >> On 01/21/2014 08:57 AM, David Holmes wrote: >>> On 21/01/2014 4:54 PM, Peter Levart wrote: >>>> >>>> On 01/21/2014 03:22 AM, David Holmes wrote: >>>>> Hi Peter, >>>>> >>>>> I do not see Cleaner being loaded prior to the main class on either >>>>> Windows or Linux. Which platform are you on? Did you see it loaded >>>>> before the main class or as part of executing it? >>>> >>>> Before. The main class is empty: >>>> >>>> public class Test { public static void main(String... a) {} } >>>> >>>> Here's last few lines of -verbose:class: >>>> >>>> [Loaded java.util.TimeZone from >>>> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >>>> [Loaded sun.util.calendar.ZoneInfo from >>>> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >>>> [Loaded sun.util.calendar.ZoneInfoFile from >>>> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >>>> [Loaded sun.util.calendar.ZoneInfoFile$1 from >>>> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >>>> [Loaded java.io.DataInput from >>>> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >>>> [Loaded java.io.DataInputStream from >>>> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >>>> *[Loaded sun.misc.Cleaner from >>>> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar]* >>> >>> Curious. I wonder what the controlling factor is ?? >>> >>>> >>>> I'm on linux, 64bit and using official EA build 121 of JDK 8... >>>> >>>> But if I try with JDK 7u45, I don't see it. So perhaps it would be >>>> good >>>> to trigger Cleaner loading and initialization as part of >>>> ReferenceHandler initialization to play things safe. >>> >>> >>> If we do that for Cleaner we may as well do it for >>> InterruptedException too. >>> >>>>> Also, it is not that I think ReferenceHandler is responsible for >>>>> reporting OOME, but that it is responsible for reporting that it was >>>>> unable to perform a clean or enqueue because of OOME. >>>> >>>> This would be necessary if we skipped a Reference because of OOME, but >>>> if we just re-try until we eventually succeed, nothing is lost, >>>> nothing >>>> to report (but a slow response)... >>> >>> Agreed - just trying to clarify things. >>> >>>>> >>>>> Your suggested approach seems okay though I'm not sure why we >>>>> shouldn't help things along by calling System.gc() ourselves rather >>>>> than just yielding and hoping things will get cleaned up elsewhere. >>>>> But for the present purposes your approach will suffice I think. >>>> >>>> Maybe my understanding is wrong but isn't the fact that OOME is >>>> rised a >>>> consequence of that VM has already attempted to clear things up >>>> (executing a GC round synchronously) but didn't succeed to make enough >>>> free space to satisfy the allocation request? If this is only how some >>>> collectors/allocators are implemented and not a general rule, then we >>>> should put a System.gc() in place of Thread.yield(). Should we also >>>> combine that with Thread.yield()? I'm concerned of a possibility >>>> that we >>>> spin, consume too much CPU (ReferenceHandler thread has MAX >>>> priority) so >>>> that other threads dont' get enough CPU time to proceed and clean >>>> things >>>> up (we hope other threads will also get OOME and release things as >>>> their >>>> stacks unwind...). >>> >>> You are probably right about the System.gc() - OOME should be thrown >>> after GC fails to create space, so it really needs some other thread >>> to drop live references to allow further space to be reclaimed. >>> >>> But note that Thread.yield() can behave badly on some linux systems >>> too, so spinning is still a possibility - but either way this would >>> only be "really bad" on a uniprocessor system where yield() is >>> unlikely to misbehave. >>> >>> David >>> ----- >>> >>>> >>>> Regards, Peter >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 20/01/2014 6:42 PM, Peter Levart wrote: >>>>>> On 01/20/2014 09:00 AM, Peter Levart wrote: >>>>>>> On 01/20/2014 02:51 AM, David Holmes wrote: >>>>>>>> Hi Peter, >>>>>>>> >>>>>>>> On 17/01/2014 11:24 PM, Peter Levart wrote: >>>>>>>>> On 01/17/2014 02:13 PM, Peter Levart wrote: >>>>>>>>>>>> // Fast path for cleaners >>>>>>>>>>>> boolean isCleaner = false; >>>>>>>>>>>> try { >>>>>>>>>>>> isCleaner = r instanceof Cleaner; >>>>>>>>>>>> } catch (OutofMemoryError oome) { >>>>>>>>>>>> continue; >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> if (isCleaner) { >>>>>>>>>>>> ((Cleaner)r).clean(); >>>>>>>>>>>> continue; >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hi David, Kalyan, >>>>>>>>>>> >>>>>>>>>>> I've caught-up now. Just thinking: is "instanceof Cleaner" >>>>>>>>>>> throwing >>>>>>>>>>> OOME as a result of loading the Cleaner class? Wouldn't the >>>>>>>>>>> above >>>>>>>>>>> code then throw some error also in ((Cleaner)r) - the >>>>>>>>>>> checkcast, >>>>>>>>>>> since Cleaner class would not be successfully initialized? >>>>>>>>>> >>>>>>>>>> Well, no. The above code would just skip Cleaner processing in >>>>>>>>>> this >>>>>>>>>> situation. And will never be doing it again after the heap is >>>>>>>>>> freed... >>>>>>>>>> So it might be good to load and initialize Cleaner class as >>>>>>>>>> part of >>>>>>>>>> ReferenceHandler initialization to ensure correct operation... >>>>>>>>> >>>>>>>>> Well, yes and no. Let me try once more: >>>>>>>>> >>>>>>>>> Above code will skip Cleaner processing if the 1st time >>>>>>>>> "instanceof >>>>>>>>> Cleaner" is executed, OOME is thrown as a consequence of full >>>>>>>>> heap >>>>>>>>> while >>>>>>>>> loading and initializing the Cleaner class. >>>>>>>> >>>>>>>> Yes - I was assuming that this would not fail the very first time >>>>>>>> and >>>>>>>> so the Cleaner class would already be loaded. Failing to be >>>>>>>> able to >>>>>>>> load the Cleaner class was one of the potential issues flagged >>>>>>>> earlier with this problem. I was actually assuming that Cleaner >>>>>>>> would >>>>>>>> be loaded already due to some actual Cleaner subclasses being >>>>>>>> used, >>>>>>>> but this does not happen as part of the default initialization. :( >>>>>>>> The irony being that if the Cleaner class is not loaded then r can >>>>>>>> not be an instance of Cleaner and so we would fail to load the >>>>>>>> class >>>>>>>> in a case where we didn't need it anyway. >>>>>>>> >>>>>>>> What I wanted to focus on here was an OOME from the instanceof >>>>>>>> itself, but as you say that might trigger classloading of Cleaner >>>>>>>> (which is not what I was interested in). >>>>>>>> >>>>>>>>> The 2nd time the "instanceof >>>>>>>>> Cleaner" is executed after such OOME, the same line would throw >>>>>>>>> NoClassDefFoundError as a consequence of referencing a class that >>>>>>>>> failed >>>>>>>>> initialization. Am I right? >>>>>>>> >>>>>>>> instanceof is not one of the class initialization triggers, so we >>>>>>>> should not see an OOME generated due to a class initialization >>>>>>>> exception and so the class will not be put into the Erroneous >>>>>>>> state >>>>>>>> and so subsequent attempts to use the class will not automatically >>>>>>>> trigger NoClassdefFoundError. >>>>>>>> >>>>>>>> If OOME occurs during actual loading/linking of the class >>>>>>>> Cleaner it >>>>>>>> is unclear what would happen on subsequent attempts. OOME is not a >>>>>>>> LinkageError that must be rethrown on subsequent attempts, and >>>>>>>> it is >>>>>>>> potentially a transient condition, so I would expect a re-load >>>>>>>> attempt to be allowed. However we are now deep into the details of >>>>>>>> the VM and it may well depend on the exact place from which the >>>>>>>> OOME >>>>>>>> originates. >>>>>>>> >>>>>>>> The bottom line with the current problem is that there are >>>>>>>> multiple >>>>>>>> non-obvious paths by which the ReferenceHandler can encounter an >>>>>>>> OOME. In such cases we do not want the ReferenceHandler to >>>>>>>> terminate >>>>>>>> - which implies catching the OOME and continuing. However we >>>>>>>> also do >>>>>>>> not want to silently skip Cleaner processing or reference queue >>>>>>>> processing - as that would lead to hard to diagnoze bugs. But >>>>>>>> trying >>>>>>>> to report the problem may not be possible due to being >>>>>>>> out-of-memory. >>>>>>>> It may be that we need to break things up into multiple try/catch >>>>>>>> blocks, where each catch does a System.gc() and then reports that >>>>>>>> the >>>>>>>> OOME occurred. Of course the reporting must still be in a >>>>>>>> try/catch >>>>>>>> for the OOME. Though at some point letting the ReferenceHandler >>>>>>>> die >>>>>>>> may be the only way to "report" a major memory problem. >>>>>>>> >>>>>>>> David >>>>>>> >>>>>>> Hm... If I give -verbose:class option to run a simple test program: >>>>>>> >>>>>>> public class Test { public static void main(String... a) {} } >>>>>>> >>>>>>> I see Cleaner class being loaded before Test class. I don't see by >>>>>>> which tread or if it might get loaded after main() starts, but I >>>>>>> suspect that loading of Cleaner is not a problem here. >>>>>>> Initialization >>>>>>> of Cleaner class is not performed by ReferenceHandler thread as you >>>>>>> pointed out. The instanceof does not trigger it and if it returns >>>>>>> true >>>>>>> then Cleaner has already been initialized. So there must be some >>>>>>> other >>>>>>> cause for instanceof throwing OOME... >>>>>>> >>>>>>> What do you say about this variant of ReferenceHandler.run() >>>>>>> method: >>>>>>> >>>>>>> public void run() { >>>>>>> for (;;) { >>>>>>> Reference r; >>>>>>> Cleaner c; >>>>>>> synchronized (lock) { >>>>>>> r = pending; >>>>>>> if (r != null) { >>>>>>> // instanceof operator might throw OOME >>>>>>> sometimes. Just retry after >>>>>>> // yielding - might have better luck next >>>>>>> time... >>>>>>> try { >>>>>>> c = r instanceof Cleaner ? (Cleaner) >>>>>>> r : >>>>>>> null; >>>>>>> } catch (OutOfMemoryError x) { >>>>>>> Thread.yield(); >>>>>>> continue; >>>>>>> } >>>>>>> pending = r.discovered; >>>>>>> r.discovered = null; >>>>>>> } else { >>>>>>> // The waiting on the lock may cause an >>>>>>> OOME >>>>>>> because it may try to allocate >>>>>>> // exception objects, so also catch OOME >>>>>>> here >>>>>>> to avoid silent exit of the >>>>>>> // reference handler thread. >>>>>>> // >>>>>>> // Explicitly define the order of the two >>>>>>> exceptions we catch here >>>>>>> // when waiting for the lock. >>>>>>> // >>>>>>> // We do not want to try to potentially >>>>>>> load >>>>>>> the InterruptedException class >>>>>>> // (which would be done if this was its >>>>>>> first >>>>>>> use, and InterruptedException >>>>>>> // were checked first) in this situation. >>>>>>> // >>>>>>> // This may lead to the VM not ever >>>>>>> trying to >>>>>>> load the InterruptedException >>>>>>> // class again. >>>>>>> try { >>>>>>> try { >>>>>>> lock.wait(); >>>>>>> } catch (OutOfMemoryError x) { } >>>>>>> } catch (InterruptedException x) { } >>>>>>> continue; >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> // Fast path for cleaners >>>>>>> if (c != null) { >>>>>>> c.clean(); >>>>>>> continue; >>>>>>> } >>>>>>> >>>>>>> ReferenceQueue q = r.queue; >>>>>>> if (q != ReferenceQueue.NULL) q.enqueue(r); >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> >>>>>>> >>>>>>> ... it tries to not consume and skip Cleaner instances when OOME is >>>>>>> caught. >>>>>>> >>>>>>> I don't think ReferenceHandler is to make responsible for reporting >>>>>>> OOMEs. Full heap is a global condition and ReferenceHandler is the >>>>>>> last to accuse for it. >>>>>>> >>>>>>> Regards, Peter >>>>>> >>>>>> Hi David, >>>>>> >>>>>> I think the following variation is even better. It executes >>>>>> Thread.yield() after catching OOME but outside synchronized block so >>>>>> that given CPU slice can be used by GC threads to make progress >>>>>> enqueueing pending References (they are not able to enqueue them >>>>>> while >>>>>> ReferenceHandler is holding the lock): >>>>>> >>>>>> >>>>>> public void run() { >>>>>> for (;;) { >>>>>> Reference r; >>>>>> Cleaner c; >>>>>> try { >>>>>> try { >>>>>> synchronized (lock) { >>>>>> r = pending; >>>>>> if (r != null) { >>>>>> // 'instanceof' might throw OOME >>>>>> sometimes so do this before >>>>>> // unlinking 'r' from the 'pending' >>>>>> chain... >>>>>> c = r instanceof Cleaner ? >>>>>> (Cleaner) r >>>>>> : null; >>>>>> // unlink 'r' from 'pending' chain >>>>>> pending = r.discovered; >>>>>> r.discovered = null; >>>>>> } else { >>>>>> // The waiting on the lock may >>>>>> cause an >>>>>> OOME because it may try to allocate >>>>>> // exception objects. >>>>>> lock.wait(); >>>>>> continue; >>>>>> } >>>>>> } >>>>>> } catch (OutOfMemoryError x) { >>>>>> // Catch OOME from 'r instanceof >>>>>> Cleaner' or >>>>>> 'lock.wait()' 1st so that we don't >>>>>> // try to potentially load the >>>>>> InterruptedException class >>>>>> // (which would be done if this was its >>>>>> first >>>>>> use, and InterruptedException >>>>>> // were checked first) in this situation. >>>>>> // Give other threads CPU time so they >>>>>> hopefully release some objects and GC >>>>>> // clears some heap. >>>>>> // Also prevent CPU intensive spinning in >>>>>> case >>>>>> 'r instanceof Cleaner' above >>>>>> // persistently throws OOME for some >>>>>> time... >>>>>> Thread.yield(); >>>>>> // retry >>>>>> continue; >>>>>> } >>>>>> } catch (InterruptedException x) { >>>>>> // Catch InterruptedException from >>>>>> 'lock.wait()' >>>>>> and retry >>>>>> continue; >>>>>> } >>>>>> >>>>>> // Fast path for cleaners >>>>>> if (c != null) { >>>>>> c.clean(); >>>>>> continue; >>>>>> } >>>>>> >>>>>> ReferenceQueue q = r.queue; >>>>>> if (q != ReferenceQueue.NULL) q.enqueue(r); >>>>>> } >>>>>> } >>>>>> >>>>>> >>>>>> Regards, Peter >>>>>> >>>> >> From stuart.marks at oracle.com Sat Jan 25 00:53:48 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 24 Jan 2014 16:53:48 -0800 Subject: Question about the bug https://bugs.openjdk.java.net/browse/JDK-8031179 In-Reply-To: <52E235BE.2040304@oracle.com> References: <52D7F2D6.7090007@oracle.com> <52D7F83B.8060900@oracle.com> <52D9CE99.5050404@oracle.com> <52E212BF.7030103@oracle.com> <52E235BE.2040304@oracle.com> Message-ID: <52E30B1C.4070701@oracle.com> Hi Eric, OK, overall this looks good. There are a few adjustments I'd like you to make before I push it for you. Part of this is to get you to do a more complete job of preparing changesets, and part of it is to make my job as a sponsor easier. :-) Oh, and there a couple style issues as well. 1. In the LookupIPv6 test, REGISTRY_PORT is capitalized, making it appear to be a constant, when in fact it's a variable that contains the result of calling getUnusedRandomPort(). It's also unclear why it needs to be a static. Just make it a local variable with a typical variable name, e.g. int port = TestLibrary.getUnusedRandomPort(); and of course make corresponding name changes where it's used. 2. The creation of the URL string for Naming.lookup() concatenates two string literals "]" + ":". It's probably better to combine these into a single literal "]:". Actually I think it would be preferable to create this URL string using String.format(), so please do this instead. 3. Prepare a complete changeset that's committed locally to your repository before running webrev. This changeset should include properly formatted commit comments, including the bugid line and Reviewed-by line, and optionally a Summary line. Recent versions of webrev will export a mercurial changeset and include it in the webrev output, instead of just diffs. Using the changeset I can just import and push it, instead of having to edit the changeset myself manually. 4. When you post the webrev, you should post updated webrevs under a directory with an incremented sequence number (in this case, webrev.01). That way, links to, and comments on, previous webrevs will not be invalidated. Thanks, s'marks On 1/24/14 1:43 AM, Eric Wang wrote: > Hi Stuart, > > Please review the webrev > http://cr.openjdk.java.net/~ewang/JDK-8031179/webrev.00/, if you are OK with the > changes, could you please be my sponsor? > > Thanks, > Eric > On 2014/1/24 15:14, Eric Wang wrote: >> Hi Stuart, >> Thanks for the suggestion! sorry for reply this mail late as i was busy on >> other tasks >> The webrev has been in the internal review process. Based on the suggestion, >> here is a summary of changes: >> >> 1. Add othervm options to tests: >> java/rmi/Naming/DefaultRegistryPort.java >> java/rmi/Naming/legalRegistryNames/LegalRegistryNames.java >> java/rmi/Naming/LookupNameWithColon.java >> java/rmi/server/UnicastRemoteObject/exportObject/GcDuringExport.java >> sun/rmi/rmic/RMIGenerator/RmicDefault.java >> java/rmi/MarshalledObject/compare/Compare.java >> java/rmi/MarshalledObject/compare/HashCode.java >> >> 2. Remove java/rmi and sun/rmi from othervm.dirs of TEST.ROOT >> >> 3. Filed a another bug https://bugs.openjdk.java.net/browse/JDK-8032629 for >> exclusiveAccess.dirs >> >> Thanks, >> Eric >> >> On 2014/1/18 8:45, Stuart Marks wrote: >>> Hi Eric, >>> >>> Thanks for doing the analysis of the tests that need /othervm. The list of >>> tests that don't need /othervm looks good. One subtlety is this one: >>> >>> java/rmi/activation/ActivationGroupDesc/checkDefaultGroupName/CheckDefaultGroupName.java >>> >>> >>> Most activation tests do need /othervm, but this one doesn't, since all it >>> does is create an ActivationGroupDesc instance, which has no side effects. >>> This is unusual for the activation APIs, since most of them are quite >>> intertwined with the rest of the activation subsystem. So, for this test, the >>> lack of /othervm warrants a comment explaining why /othervm is unnecessary. >>> >>> Regarding merging of the tests java/rmi/MarshalledObject/compare/Compare.java >>> and HashCode.java, this is fairly subtle and not obviously wrong, but it's >>> not obviously right either. Note that different jtreg tests -- even in >>> agentvm or samevm mode -- load the test class in a fresh classloader, which >>> means that the statics are reinitialized. This provides some degree of >>> isolation of the tests even when they're reusing the same JVM. By contrast, >>> calling the two different methods from within the same test exposes the >>> second one to initializations left from the first one. In addition (though >>> I'm not too concerned about this) if the first test fails the second won't be >>> run at all. Merging these tests is kind of out of scope for this particular >>> bug, and since I wasn't fully able to convince myself that the merged tests >>> have the same semantics as the unmerged tests, I'd prefer not to see the >>> merging of these tests as part of this changeset. >>> >>> (Some cleanup of these two tests is probably warranted eventually. I'd take a >>> different approach of merging and refactoring the sources but keeping them as >>> separate test runs, using two @run tags. But we should work on that >>> separately. Meanwhile, the overhead of having these as separate tests is >>> minimal, especially if they're not run in /othervm mode.) >>> >>> I don't think the removal of java/rmi/Naming from exclusiveAccess.dirs is >>> safe at this point. The DefaultRegistryPort.java test uses the default >>> registry port, not a unique one. Conceptually it would need to be converted >>> to use the TestLibrary unique port stuff, but the test is actually about >>> using the default port. So, the solution here isn't obvious. >>> >>> In addition, the java/rmi/Naming/legalRegistryNames/LegalRegistryNames.java >>> test also uses the default registry port. It too will need to converted >>> before java/rmi/Naming is removed from exclusiveAccess.dirs. >>> >>> The java/rmi/Naming/LookupIPv6.java test was converted to use the TestLibrary >>> unique port technique, but only partially. The registry is created on the >>> unique port, but the Naming.lookup() call on the last line of the test >>> doesn't provide a port number, so it does the lookup on the default port >>> instead. This will cause the test to fail in almost all cases. >>> >>> I have to ask, did you run this test with your modifications? >>> >>> (Well, the test would pass if IPv6 is not enabled on the machine running the >>> test, but it only passes because the part of the test that creates and uses >>> the registry is bypassed entirely if IPv6 is not enabled. If you're modifying >>> code, you need to take responsibility for ensuring that the code being >>> modified is actually being run and is doing what you expect.) >>> >>> LookupIPv6.java also needs to have these lines added to the test tags: >>> * @bug 4402708 >>> + * @library ../testlibrary >>> + * @build TestLibrary >>> * @run main/othervm -Djava.net.preferIPv6Addresses=true LookupIPv6 >>> (Their absence will cause the test also to fail in a clean build, but the >>> test will find a TestLibrary class if one had been compiled by a previous >>> test that had required it.) >>> >>> Maybe we should separate the othervm changes (removal of the rmi dirs from >>> othervm.dirs, and addition of /othervm) from the exclusiveAccess.dirs >>> changes. A separate bug would be filed for exclusiveAccess.dirs. I know this >>> means the bug count won't go down, but dealing with exclusiveAccess.dirs >>> means that the logic of various tests will need to be change to use the >>> unique port mechanism. This is a fair chunk of work and it's logically >>> distinct from the othervm work. >>> >>> If we also remove the merging of the MarshalledObject tests, I think we can >>> proceed with the othervm changes. >>> >>> Eric, can you make these changes and send out another webrev? >>> >>> Thanks. >>> >>> s'marks >>> >>> >>> >>> On 1/16/14 7:18 AM, Eric Wang wrote: >>>> Hi Stuart, >>>> >>>> I have generated a webrev for review, can you please help to check whether >>>> the changes are OK. >>>> http://cr.openjdk.java.net/~ewang/JDK-8031179/webrev.00/ >>>> >>>> >>>> Also need your help to confirm that the rest 9 tests in previous mail don't >>>> need the /othervm option indeed. >>>> >>>> Thanks, >>>> Eric >>>> On 2014/1/16 22:55, Eric Wang wrote: >>>>> Hi Stuart, >>>>> >>>>> I'm working on the bug https://bugs.openjdk.java.net/browse/JDK-8031179 to >>>>> add /othervm option to rmi tests, so they can removed from the item >>>>> othervm.dir and exclusiveAccess.dirs. >>>>> By searching the directories java/rmi, sun/rmi and java/rmi/Naming, there >>>>> are 14 tests without othervm option, but only 5 tests need to the /othervm >>>>> tag. they are: >>>>> >>>>> Tests need /othervm option: >>>>> java/rmi/Naming/DefaultRegistryPort.java >>>>> java/rmi/Naming/legalRegistryNames/LegalRegistryNames.java >>>>> java/rmi/Naming/LookupNameWithColon.java >>>>> java/rmi/server/UnicastRemoteObject/exportObject/GcDuringExport.java >>>>> sun/rmi/rmic/RMIGenerator/RmicDefault.java >>>>> >>>>> Tests don't need the /othervm option: >>>>> java/rmi/activation/ActivationGroupDesc/checkDefaultGroupName/CheckDefaultGroupName.java >>>>> >>>>> java/rmi/MarshalledObject/compare/Compare.java >>>>> java/rmi/MarshalledObject/compare/HashCode.java >>>>> java/rmi/MarshalledObject/compare/NullReference.java >>>>> java/rmi/server/Unmarshal/PrimitiveClasses.java >>>>> sun/rmi/log/ReliableLog/LogAlignmentTest.java >>>>> sun/rmi/log/ReliableLog/Recovery.java >>>>> sun/rmi/log/ReliableLog/SnapshotSize.java >>>>> sun/rmi/rmic/classpath/RMICClassPathTest.java >>>>> >>>>> Also i have a bit confuse about the test Compare.java and HashCode.java in >>>>> java/rmi/MarshalledObject/compare directory, as they should be merged into >>>>> one test so that we don't need to add additional /othervm option for 2 test. >>>>> >>>>> Thanks, >>>>> Eric >>>>> >>>> >>> >> > From stuart.marks at oracle.com Sat Jan 25 02:20:03 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 24 Jan 2014 18:20:03 -0800 Subject: RFR: JDK-8032050: TEST_BUG: java/rmi/activation/Activatable/shutdownGracefully/ShutdownGracefully.java fails intermittently In-Reply-To: <52E20974.7060706@oracle.com> References: <52E20974.7060706@oracle.com> Message-ID: <52E31F53.3070702@oracle.com> On 1/23/14 10:34 PM, Tristan Yan wrote: > Hi All > Could you review the bug fix for JDK-8032050. > > http://cr.openjdk.java.net/~tyan/JDK-8032050/webrev.00/ > > Description: > This rare happened failure caused because when RMID starts. It don't guarantee > sun.rmi.server.Activation.startActivation finishes. > Fix by adding a iterative getSystem with a 5 seconds timeout. Hi Tristan, Adding a timing/retry loop into this test isn't the correct approach for fixing this test. The timing loop isn't necessary because there is already a timing loop in RMID.start() in the RMI test library. (There's another timing loop in ActivationLibrary.rmidRunning() which should probably be removed.) So the intent of this library call is that it start rmid and wait for it to become ready. That logic doesn't need to be added to the test. In the bug report JDK-8032050 you had mentioned that the NullPointerException was suspicious. You're right! I took a look and it seemed like it was related to JDK-8023541, and I added a note to this effect to the bug report. The problem here is that rmid can come up and transiently return null instead of the stub of the activation system. That's what JDK-8023541 covers. I think that rmid itself needs to be fixed, though modifying the timing loop in the RMI test library to wait for rmid to come up *and* for the lookup to return non-null is an easy way to fix the problem. (Or at least cover it up.) The next step in the analysis is to determine, given that ActivationLibrary.getSystem can sometimes return null, whether this has actually caused this test failure. This is pretty easy to determine; just hack in a line "system = null" in the right place and run the test. I've done this, and the test times out and the output log is pretty much identical to the one in the bug report. (I recommend you try this yourself.) So I think it's fairly safe to say that the problem in JDK-8023541 has caused the failure listed in JDK-8032050. I can see a couple ways to proceed here. One way is just to close this out as a duplicate of JDK-8023541 since that bug caused this failure. Another is that this test could use some cleaning up. This bug certainly covers a failure, but the messages emitted are confusing and in some cases completely wrong. For example, the "rmid has shutdown" message at line 180 is incorrect, because in this case rmid is still running and the wait() call has timed out. Most of the code here can be replaced with calls to various bits of the RMI test library. There are a bunch of other things in this test that could be cleaned up as well. It's up to you how you'd like to proceed. s'marks From srikalyan.chandrashekar at oracle.com Sat Jan 25 04:35:29 2014 From: srikalyan.chandrashekar at oracle.com (srikalyan chandrashekar) Date: Fri, 24 Jan 2014 20:35:29 -0800 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52E2FFE2.7000600@gmail.com> References: <52B3568B.5050905@oracle.com> <52CC72AB.2020104@oracle.com> <52CCEDE0.8000809@oracle.com> <52CCF079.4090301@oracle.com> <52CD45E7.7010203@gmail.com> <52CE4E2D.300@oracle.com> <52CF37C6.1070605@oracle.com> <52CFAFEB.9090703@gmail.com> <52CFD218.2060101@gmail.com> <52D06B70.60001@oracle.com> <52D15201.90109@gmail.com> <52D47D59.8040905@oracle.com> <52D72577.1050506@oracle.com> <52D76859.2030502@oracle.com> <52D82968.4030608@oracle.com> <52D8929B.2020905@oracle.com> <52D8A42A.4020906@oracle.com> <52D8B3B6.3030202@oracle.com> <52D9295D.6080106@gmail.com> <52D92C73.2020309@gmail.com> <52D92F1A.4040400@gmail.com> <52DC812C.1000607@oracle.com> <52DCD78E.8050404@gmail.com> <52DCE17B.4050708@gmail.com> <52DDD9F3.1050201@oracle.com> <52DE19C1.2070302@gmail.com> <52DE9147.4030305@gmail.com> <52DEB9C4.4030606@oracle.com> <52DEF53C.3050905@gmail.com> <52E1772A.1050608@oracle.com> <52E1B4C5.8050807@oracle.com> <52E1C7AD.8090100@oracle.com> <52E2FFE2.7000600@gmail.com> Message-ID: <52E33F11.8000804@oracle.com> Hi Peter, if you are a committer would you like to take this further (OR) perhaps david could sponsor this change. -- Thanks kalyan On 1/24/14 4:05 PM, Peter Levart wrote: > > On 01/24/2014 02:53 AM, srikalyan chandrashekar wrote: >> Hi David, yes thats right, only benefit i see is we can avoid >> assignment to 'r' if pending is null. > > Hi Kalyan, > > Good to hear that test runs without failures so far. > > Regarding assignment of 'r'. What I tried to accomplish with the > change was eliminate double reading of 'pending' field. I have a > mental model of local variable being a register and field being a > memory location. This may be important if the field is volatile, but > for normal fields, I guess the optimizer knows how to compile such > code most optimally in either case. The old (your) version is better > from logical perspective, since it guarantees that dereferencing the > 'r', wherever it is possible, will never throw NPE (dereferencing > where 'r' is not assigned is not possible because of definitive > assignment rules). So I support going back to your version... > > Regards, Peter > >> >> -- >> Thanks >> kalyan >> >> On 1/23/14 4:33 PM, David Holmes wrote: >>> On 24/01/2014 6:10 AM, srikalyan wrote: >>>> Hi Peter, i have modified your code from >>>> >>>> r = pending; >>>> if (r != null) { >>>> ...... >>>> TO >>>> if (pending != null) { >>>> r = pending; >>>> >>>> This is because the r is used later in the code and must not be >>>> assigned >>>> pending unless it is not null(this was as is earlier). >>> >>> If r is null, because pending is null then you perform the wait() >>> and then continue - back to the top of the loop. There is no bug in >>> Peter's code. >>> >>> The new webrev is >>>> posted here >>>> http://cr.openjdk.java.net/~srikchan/Regression/JDK-8022321_OOMEInReferenceHandler-webrev-V2/ >>>> >>>> . I ran a 1000 run and no failures so far, however i would like to >>>> run a >>>> couple more 1000 runs to assert the fix. >>>> >>>> PS: The description section of JEP-122 >>>> (http://openjdk.java.net/jeps/122) says meta-data would be in native >>>> memory(not heap). >>> >>> The class_mirror is a Java object not meta-data. >>> >>> David >>> >>>> -- >>>> Thanks >>>> kalyan >>>> Ph: (408)-585-8040 >>>> >>>> >>>> On 1/21/14, 2:31 PM, Peter Levart wrote: >>>>> >>>>> On 01/21/2014 07:17 PM, srikalyan wrote: >>>>>> Hi Peter/David, catching up after long weekend. Why would there >>>>>> be an >>>>>> OOME in object heap due to class loading in perm gen space ? >>>>> >>>>> The perm gen is not a problem her (JDK 8 does not have it and we see >>>>> OOME on JDK8 too). Each time a class is loaded, new java.lang.Class >>>>> object is allocated on heap. >>>>> >>>>> Regards, Peter >>>>> >>>>>> Please correct if i am missing something here. Meanwhile i will give >>>>>> the version of Reference Handler you both agreed on a try. >>>>>> -- >>>>>> Thanks >>>>>> kalyan >>>>>> Ph: (408)-585-8040 >>>>>> >>>>>> On 1/21/14, 7:24 AM, Peter Levart wrote: >>>>>>> On 01/21/2014 07:54 AM, Peter Levart wrote: >>>>>>>> *[Loaded sun.misc.Cleaner from >>>>>>>> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar]* >>>>>>>> [Loaded java.io.ByteArrayInputStream from >>>>>>>> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >>>>>>>> [Loaded sun.util.calendar.ZoneInfoFile$ZoneOffsetTransitionRule >>>>>>>> from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >>>>>>>> ... >>>>>>>> >>>>>>>> >>>>>>>> I'm on linux, 64bit and using official EA build 121 of JDK 8... >>>>>>>> >>>>>>>> But if I try with JDK 7u45, I don't see it. >>>>>>> >>>>>>> So what changed between JDK 7 and JDK 8? >>>>>>> >>>>>>> I suspect the following: 8007572: Replace existing jdk timezone >>>>>>> data >>>>>>> at /lib/zi with JSR310's tzdb >>>>>>> >>>>>>> >>>>>>> Regards, Peter >>>>>>> >>>>> >> > From yiming.wang at oracle.com Sat Jan 25 09:24:59 2014 From: yiming.wang at oracle.com (Eric Wang) Date: Sat, 25 Jan 2014 17:24:59 +0800 Subject: Question about the bug https://bugs.openjdk.java.net/browse/JDK-8031179 In-Reply-To: <52E30B1C.4070701@oracle.com> References: <52D7F2D6.7090007@oracle.com> <52D7F83B.8060900@oracle.com> <52D9CE99.5050404@oracle.com> <52E212BF.7030103@oracle.com> <52E235BE.2040304@oracle.com> <52E30B1C.4070701@oracle.com> Message-ID: <52E382EB.1070403@oracle.com> Hi Stuart, I have made changes based on your comments. Can you please review again? Thanks a lot! http://cr.openjdk.java.net/~ewang/JDK-8031179/webrev.01/ Eric On 2014/1/25 8:53, Stuart Marks wrote: > Hi Eric, > > OK, overall this looks good. There are a few adjustments I'd like you > to make before I push it for you. Part of this is to get you to do a > more complete job of preparing changesets, and part of it is to make > my job as a sponsor easier. :-) Oh, and there a couple style issues as > well. > > 1. In the LookupIPv6 test, REGISTRY_PORT is capitalized, making it > appear to be a constant, when in fact it's a variable that contains > the result of calling getUnusedRandomPort(). It's also unclear why it > needs to be a static. Just make it a local variable with a typical > variable name, e.g. > > int port = TestLibrary.getUnusedRandomPort(); > > and of course make corresponding name changes where it's used. > > 2. The creation of the URL string for Naming.lookup() concatenates two > string literals "]" + ":". It's probably better to combine these into > a single literal "]:". Actually I think it would be preferable to > create this URL string using String.format(), so please do this instead. > > 3. Prepare a complete changeset that's committed locally to your > repository before running webrev. This changeset should include > properly formatted commit comments, including the bugid line and > Reviewed-by line, and optionally a Summary line. Recent versions of > webrev will export a mercurial changeset and include it in the webrev > output, instead of just diffs. Using the changeset I can just import > and push it, instead of having to edit the changeset myself manually. > > 4. When you post the webrev, you should post updated webrevs under a > directory with an incremented sequence number (in this case, > webrev.01). That way, links to, and comments on, previous webrevs will > not be invalidated. > > Thanks, > > s'marks > > On 1/24/14 1:43 AM, Eric Wang wrote: >> Hi Stuart, >> >> Please review the webrev >> http://cr.openjdk.java.net/~ewang/JDK-8031179/webrev.00/, if you are >> OK with the >> changes, could you please be my sponsor? >> >> Thanks, >> Eric >> On 2014/1/24 15:14, Eric Wang wrote: >>> Hi Stuart, >>> Thanks for the suggestion! sorry for reply this mail late as i was >>> busy on >>> other tasks >>> The webrev has been in the internal review process. Based on the >>> suggestion, >>> here is a summary of changes: >>> >>> 1. Add othervm options to tests: >>> java/rmi/Naming/DefaultRegistryPort.java >>> java/rmi/Naming/legalRegistryNames/LegalRegistryNames.java >>> java/rmi/Naming/LookupNameWithColon.java >>> java/rmi/server/UnicastRemoteObject/exportObject/GcDuringExport.java >>> sun/rmi/rmic/RMIGenerator/RmicDefault.java >>> java/rmi/MarshalledObject/compare/Compare.java >>> java/rmi/MarshalledObject/compare/HashCode.java >>> >>> 2. Remove java/rmi and sun/rmi from othervm.dirs of TEST.ROOT >>> >>> 3. Filed a another bug >>> https://bugs.openjdk.java.net/browse/JDK-8032629 for >>> exclusiveAccess.dirs >>> >>> Thanks, >>> Eric >>> >>> On 2014/1/18 8:45, Stuart Marks wrote: >>>> Hi Eric, >>>> >>>> Thanks for doing the analysis of the tests that need /othervm. The >>>> list of >>>> tests that don't need /othervm looks good. One subtlety is this one: >>>> >>>> java/rmi/activation/ActivationGroupDesc/checkDefaultGroupName/CheckDefaultGroupName.java >>>> >>>> >>>> >>>> Most activation tests do need /othervm, but this one doesn't, since >>>> all it >>>> does is create an ActivationGroupDesc instance, which has no side >>>> effects. >>>> This is unusual for the activation APIs, since most of them are quite >>>> intertwined with the rest of the activation subsystem. So, for this >>>> test, the >>>> lack of /othervm warrants a comment explaining why /othervm is >>>> unnecessary. >>>> >>>> Regarding merging of the tests >>>> java/rmi/MarshalledObject/compare/Compare.java >>>> and HashCode.java, this is fairly subtle and not obviously wrong, >>>> but it's >>>> not obviously right either. Note that different jtreg tests -- even in >>>> agentvm or samevm mode -- load the test class in a fresh >>>> classloader, which >>>> means that the statics are reinitialized. This provides some degree of >>>> isolation of the tests even when they're reusing the same JVM. By >>>> contrast, >>>> calling the two different methods from within the same test exposes >>>> the >>>> second one to initializations left from the first one. In addition >>>> (though >>>> I'm not too concerned about this) if the first test fails the >>>> second won't be >>>> run at all. Merging these tests is kind of out of scope for this >>>> particular >>>> bug, and since I wasn't fully able to convince myself that the >>>> merged tests >>>> have the same semantics as the unmerged tests, I'd prefer not to >>>> see the >>>> merging of these tests as part of this changeset. >>>> >>>> (Some cleanup of these two tests is probably warranted eventually. >>>> I'd take a >>>> different approach of merging and refactoring the sources but >>>> keeping them as >>>> separate test runs, using two @run tags. But we should work on that >>>> separately. Meanwhile, the overhead of having these as separate >>>> tests is >>>> minimal, especially if they're not run in /othervm mode.) >>>> >>>> I don't think the removal of java/rmi/Naming from >>>> exclusiveAccess.dirs is >>>> safe at this point. The DefaultRegistryPort.java test uses the default >>>> registry port, not a unique one. Conceptually it would need to be >>>> converted >>>> to use the TestLibrary unique port stuff, but the test is actually >>>> about >>>> using the default port. So, the solution here isn't obvious. >>>> >>>> In addition, the >>>> java/rmi/Naming/legalRegistryNames/LegalRegistryNames.java >>>> test also uses the default registry port. It too will need to >>>> converted >>>> before java/rmi/Naming is removed from exclusiveAccess.dirs. >>>> >>>> The java/rmi/Naming/LookupIPv6.java test was converted to use the >>>> TestLibrary >>>> unique port technique, but only partially. The registry is created >>>> on the >>>> unique port, but the Naming.lookup() call on the last line of the test >>>> doesn't provide a port number, so it does the lookup on the default >>>> port >>>> instead. This will cause the test to fail in almost all cases. >>>> >>>> I have to ask, did you run this test with your modifications? >>>> >>>> (Well, the test would pass if IPv6 is not enabled on the machine >>>> running the >>>> test, but it only passes because the part of the test that creates >>>> and uses >>>> the registry is bypassed entirely if IPv6 is not enabled. If you're >>>> modifying >>>> code, you need to take responsibility for ensuring that the code being >>>> modified is actually being run and is doing what you expect.) >>>> >>>> LookupIPv6.java also needs to have these lines added to the test tags: >>>> * @bug 4402708 >>>> + * @library ../testlibrary >>>> + * @build TestLibrary >>>> * @run main/othervm -Djava.net.preferIPv6Addresses=true LookupIPv6 >>>> (Their absence will cause the test also to fail in a clean build, >>>> but the >>>> test will find a TestLibrary class if one had been compiled by a >>>> previous >>>> test that had required it.) >>>> >>>> Maybe we should separate the othervm changes (removal of the rmi >>>> dirs from >>>> othervm.dirs, and addition of /othervm) from the exclusiveAccess.dirs >>>> changes. A separate bug would be filed for exclusiveAccess.dirs. I >>>> know this >>>> means the bug count won't go down, but dealing with >>>> exclusiveAccess.dirs >>>> means that the logic of various tests will need to be change to use >>>> the >>>> unique port mechanism. This is a fair chunk of work and it's logically >>>> distinct from the othervm work. >>>> >>>> If we also remove the merging of the MarshalledObject tests, I >>>> think we can >>>> proceed with the othervm changes. >>>> >>>> Eric, can you make these changes and send out another webrev? >>>> >>>> Thanks. >>>> >>>> s'marks >>>> >>>> >>>> >>>> On 1/16/14 7:18 AM, Eric Wang wrote: >>>>> Hi Stuart, >>>>> >>>>> I have generated a webrev for review, can you please help to check >>>>> whether >>>>> the changes are OK. >>>>> http://cr.openjdk.java.net/~ewang/JDK-8031179/webrev.00/ >>>>> >>>>> >>>>> Also need your help to confirm that the rest 9 tests in previous >>>>> mail don't >>>>> need the /othervm option indeed. >>>>> >>>>> Thanks, >>>>> Eric >>>>> On 2014/1/16 22:55, Eric Wang wrote: >>>>>> Hi Stuart, >>>>>> >>>>>> I'm working on the bug >>>>>> https://bugs.openjdk.java.net/browse/JDK-8031179 to >>>>>> add /othervm option to rmi tests, so they can removed from the item >>>>>> othervm.dir and exclusiveAccess.dirs. >>>>>> By searching the directories java/rmi, sun/rmi and >>>>>> java/rmi/Naming, there >>>>>> are 14 tests without othervm option, but only 5 tests need to the >>>>>> /othervm >>>>>> tag. they are: >>>>>> >>>>>> Tests need /othervm option: >>>>>> java/rmi/Naming/DefaultRegistryPort.java >>>>>> java/rmi/Naming/legalRegistryNames/LegalRegistryNames.java >>>>>> java/rmi/Naming/LookupNameWithColon.java >>>>>> java/rmi/server/UnicastRemoteObject/exportObject/GcDuringExport.java >>>>>> sun/rmi/rmic/RMIGenerator/RmicDefault.java >>>>>> >>>>>> Tests don't need the /othervm option: >>>>>> java/rmi/activation/ActivationGroupDesc/checkDefaultGroupName/CheckDefaultGroupName.java >>>>>> >>>>>> >>>>>> java/rmi/MarshalledObject/compare/Compare.java >>>>>> java/rmi/MarshalledObject/compare/HashCode.java >>>>>> java/rmi/MarshalledObject/compare/NullReference.java >>>>>> java/rmi/server/Unmarshal/PrimitiveClasses.java >>>>>> sun/rmi/log/ReliableLog/LogAlignmentTest.java >>>>>> sun/rmi/log/ReliableLog/Recovery.java >>>>>> sun/rmi/log/ReliableLog/SnapshotSize.java >>>>>> sun/rmi/rmic/classpath/RMICClassPathTest.java >>>>>> >>>>>> Also i have a bit confuse about the test Compare.java and >>>>>> HashCode.java in >>>>>> java/rmi/MarshalledObject/compare directory, as they should be >>>>>> merged into >>>>>> one test so that we don't need to add additional /othervm option >>>>>> for 2 test. >>>>>> >>>>>> Thanks, >>>>>> Eric >>>>>> >>>>> >>>> >>> >> From forax at univ-mlv.fr Sat Jan 25 09:56:38 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 25 Jan 2014 10:56:38 +0100 Subject: Which optimizations does Hotspot apply? In-Reply-To: References: <09548E95-EA91-4986-A692-EC2DCE0944BB@snazy.de> <52E05640.3020000@univ-mlv.fr> Message-ID: <52E38A56.6010900@univ-mlv.fr> On 01/23/2014 01:39 AM, Vitaly Davidovich wrote: > > Remi, > > Regarding your last point - picking correct data structures and algos > is of course step 1 in any optimization. > No, step 1 is to be sure that your problem is CPU bound. > But, provided that's taken care of, there're plausible reasons to > attempt to cater to hotspot as well (if that's the jvm in use). There > are certainly code shapes that it prefers. > yes, any JITs have preferred code shapes. The thing is that to know if a new optimization will be included, the perf tests will be done using benchmarks that usually use dumb codes, as a logical consequence JITs are trained to recognize dumb codes. That's why trying to do any micro-optimization using 'smart' code shape usually result in a code that is slower. > There's a whole slew of inlining heuristics and rules to be aware of. > Those rules change. > There's a set of intrinsics, in some cases covering only a subset of > an API of a class. These things are always subject to change, but > saying "never worth it" isn't right either :). > yes, yo're right it's not right, let say it almost right :) R?mi > Sent from my phone > > On Jan 22, 2014 6:38 PM, "Remi Forax" > wrote: > > On 01/22/2014 11:37 PM, Robert Stupp wrote: > > Is there any documentation available which optimizations > Hotspot can perform and what "collecting a garbage" object costs? > I know that these are two completely different areas ;) > > I was inspecting whether the following code > for (Object o : someArrayList) { ... } > would be faster than > for (int i=0, l=someArrayList.size(); i o=someArrayList.get(i); } > for RandomAccessList implementations. The challenge here is > not just to track the CPU time spent creating & using the > iterator vs. size() & get() calls but also track GC effort > (which is at least complicated if not impossible due to the > variety of GC configuration options). > > > For a long time, using a for with an index (if you are *sure* that > it's an ArrayList) was faster. > With latest jdk8, it's not true anymore. > (and most of the time the iterator object is not created anymore > at least with jdk7+). > > > For example: > - Does it help Hotspot to declare parameters/variables as > "final" or can Hotspot identify that? > > > no, it's an urban myth. > You can test it by yourself, if you declare a local variable final > or not the exact same bytecode is produced by javac. The keyword > final for a local variable (or a parameter) is not stored in the > bytecode. > > BTW, final was introduced in 1.1 mostly to allow to capture the > value of a variable to be used by an anonymous class, Java 8 > doesn't require this kind of variable to be declared final anymore. > > - When does Hotspot inline method calls in general and > getters/setters especially? > > > In general, up to a depth of 10 by default and 1 for a recursive > method. > Roughly, a method call is not inlined either if the call is > virtual and can call too many implementations or if the generated > assembly code will be too big. > > > I think such a piece of documentation (just what Hotspot can > do in which release) would be really helpful when someone > tries to optimize code - want to say: the question is: "Is > something worth to spend time on or is this special situation > handled by Hotspot?" > > > It never worth it. > Choose the right algorithms and shape your data to be easily > consumed by your algorithms is enough. > > > -Robert > > > R?mi > From forax at univ-mlv.fr Sat Jan 25 10:14:01 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 25 Jan 2014 11:14:01 +0100 Subject: Which optimizations does Hotspot apply? In-Reply-To: References: <09548E95-EA91-4986-A692-EC2DCE0944BB@snazy.de> <52E05640.3020000@univ-mlv.fr> Message-ID: <52E38E69.3070409@univ-mlv.fr> On 01/24/2014 11:01 PM, Vitaly Davidovich wrote: > This would be predicated on escape analysis, whose effectiveness is in turn > driven by sufficient inlining whereby compiler can see that instance > doesn't escape. Inlining, in turn, can be screwed up by (amongst other > things) polymorphic call sites. So in the end, it's all quite brittle and > sensitive :). Personally, in places where it matters, I try to allocate as > little as possible explicitly - a lot of times much more effective than > hoping compiler helps out and/or turning GC knobs. > > Sent from my phone Hi Andrej, if you see a lot of instances of ArrayList iterator it means that you have a code path that create an iterator and use it later and the JIT is not able to see the creation and the use in the same inlining horizon. As Vitaly said, it's perhaps because you have the same code called with several different kinds of List (teach your programmer to stop to use LinkedList :) or because the code create an Iterator too far from where you use it (by example if the iterator is stored in a List or a Map). If you use -XX:+PrintInlining, the VM will print the reason why something is not inlined. cheers, R?mi > On Jan 24, 2014 4:36 PM, "Andrej Golovnin" wrote: > >> Hi R?mi, >> >>> With latest jdk8, it's not true anymore. >>> (and most of the time the iterator object is not created anymore at >> least with jdk7+). >> >> Could you please explain it a little bit more? When is that optimization >> applied, >> e.g. what conditions are required for this optimization, since which >> version >> of JDK/Hotspot it is supported, where it is implemented in JDK? >> >> When I take look at a product I'm working on, I see a lot instances of >> ArrayList$Itr objects, >> which are created by for-each loops (we use JDK 7u51). >> >> Thanks in advance! >> >> Best regards, >> Andrej Golovnin >> >> >> From aph at redhat.com Sat Jan 25 10:14:44 2014 From: aph at redhat.com (Andrew Haley) Date: Sat, 25 Jan 2014 10:14:44 +0000 Subject: Which optimizations does Hotspot apply? In-Reply-To: References: <09548E95-EA91-4986-A692-EC2DCE0944BB@snazy.de> <52E05640.3020000@univ-mlv.fr> Message-ID: <52E38E94.8090006@redhat.com> On 01/24/2014 09:36 PM, Andrej Golovnin wrote: > Could you please explain it a little bit more? When is that > optimization applied, e.g. what conditions are required for this > optimization, since which version of JDK/Hotspot it is supported, > where it is implemented in JDK? > > When I take look at a product I'm working on, I see a lot instances > of ArrayList$Itr objects, which are created by for-each loops (we > use JDK 7u51). Rather than asking these questions, you should have a look: Read the bytecode javac generates. Build a debug JVM and look at the assembly code HotSpot produces. Turn on GC tracing and have a look. Use a system profiling tool (e.g. oprofile) to measure the time taken. Don't believe what anyone tells you: find out for yourself. Then you'll know. Andrew. From weijun.wang at oracle.com Sat Jan 25 13:32:19 2014 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Sat, 25 Jan 2014 13:32:19 +0000 Subject: hg: jdk8/tl/jdk: 8031572: jarsigner -verify exits with 0 when a jar file is not properly signed Message-ID: <20140125133414.AA45C62795@hg.openjdk.java.net> Changeset: 4d891c8db5c1 Author: weijun Date: 2014-01-21 12:08 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4d891c8db5c1 8031572: jarsigner -verify exits with 0 when a jar file is not properly signed Reviewed-by: mullan ! src/share/classes/java/util/jar/JarFile.java + test/sun/security/tools/jarsigner/EntriesOrder.java From vitalyd at gmail.com Sat Jan 25 17:35:34 2014 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Sat, 25 Jan 2014 12:35:34 -0500 Subject: Which optimizations does Hotspot apply? In-Reply-To: <52E38E69.3070409@univ-mlv.fr> References: <09548E95-EA91-4986-A692-EC2DCE0944BB@snazy.de> <52E05640.3020000@univ-mlv.fr> <52E38E69.3070409@univ-mlv.fr> Message-ID: One thing that would be very useful (and I've asked Vladimir Kozlov for it) is to expose a product flag (I believe there's one now but it's develop) to trace EA decisions/reasons. Maybe that's already planned, but if not, hopefully it makes it at some point. Sent from my phone On Jan 25, 2014 5:15 AM, "Remi Forax" wrote: > On 01/24/2014 11:01 PM, Vitaly Davidovich wrote: > >> This would be predicated on escape analysis, whose effectiveness is in >> turn >> driven by sufficient inlining whereby compiler can see that instance >> doesn't escape. Inlining, in turn, can be screwed up by (amongst other >> things) polymorphic call sites. So in the end, it's all quite brittle and >> sensitive :). Personally, in places where it matters, I try to allocate >> as >> little as possible explicitly - a lot of times much more effective than >> hoping compiler helps out and/or turning GC knobs. >> >> Sent from my phone >> > > Hi Andrej, > if you see a lot of instances of ArrayList iterator it means that you have > a code path that create an iterator and use it later and the JIT is not > able to see the creation and the use in the same inlining horizon. As > Vitaly said, it's perhaps because you have the same code called with > several different kinds of List (teach your programmer to stop to use > LinkedList :) or because the code create an Iterator too far from where you > use it (by example if the iterator is stored in a List or a Map). > > If you use -XX:+PrintInlining, the VM will print the reason why something > is not inlined. > > cheers, > R?mi > > > On Jan 24, 2014 4:36 PM, "Andrej Golovnin" wrote: >> >> Hi R?mi, >>> >>> With latest jdk8, it's not true anymore. >>>> (and most of the time the iterator object is not created anymore at >>>> >>> least with jdk7+). >>> >>> Could you please explain it a little bit more? When is that optimization >>> applied, >>> e.g. what conditions are required for this optimization, since which >>> version >>> of JDK/Hotspot it is supported, where it is implemented in JDK? >>> >>> When I take look at a product I'm working on, I see a lot instances of >>> ArrayList$Itr objects, >>> which are created by for-each loops (we use JDK 7u51). >>> >>> Thanks in advance! >>> >>> Best regards, >>> Andrej Golovnin >>> >>> >>> >>> > From alan.bateman at oracle.com Sat Jan 25 20:05:49 2014 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 25 Jan 2014 20:05:49 +0000 Subject: hg: jdk8/tl/jdk: 8032456: vm/jni/Miscellaneous/misc001/misc00101m1/misc00101m1.html failing on OS X Message-ID: <20140125200603.4D4F962798@hg.openjdk.java.net> Changeset: b56ff7d30a72 Author: alanb Date: 2014-01-24 11:50 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b56ff7d30a72 8032456: vm/jni/Miscellaneous/misc001/misc00101m1/misc00101m1.html failing on OS X Reviewed-by: sla, chegar, psandoz ! src/solaris/native/common/jni_util_md.c From tristan.yan at oracle.com Sun Jan 26 04:57:00 2014 From: tristan.yan at oracle.com (Tristan Yan) Date: Sun, 26 Jan 2014 12:57:00 +0800 Subject: RFR: JDK-8032050: TEST_BUG: java/rmi/activation/Activatable/shutdownGracefully/ShutdownGracefully.java fails intermittently In-Reply-To: <52E31F53.3070702@oracle.com> References: <52E20974.7060706@oracle.com> <52E31F53.3070702@oracle.com> Message-ID: <52E4959C.3020907@oracle.com> Hi Stuart Thank you for your review and suggestion. Yes, since this failure mode is very hard to be reproduced. I guess it's make sense to do some hack. And I also noticed in ActivationLibrary.rmidRunning. It does try to look up ActivationSystem but doesn't check if it's null. So I add the logic to make sure we will look up the non-null ActivationSystem. Also I did some cleanup if you don't mind. Add a waitFor(long timeout, TimeUnit unit) for JavaVM. Which we can have a better waitFor control. I appreciate you can review the code again. http://cr.openjdk.java.net/~tyan/JDK-8032050/webrev.01/ Thank you Tristan On 01/25/2014 10:20 AM, Stuart Marks wrote: > On 1/23/14 10:34 PM, Tristan Yan wrote: >> Hi All >> Could you review the bug fix for JDK-8032050. >> >> http://cr.openjdk.java.net/~tyan/JDK-8032050/webrev.00/ >> >> Description: >> This rare happened failure caused because when RMID starts. It don't >> guarantee >> sun.rmi.server.Activation.startActivation finishes. >> Fix by adding a iterative getSystem with a 5 seconds timeout. > > Hi Tristan, > > Adding a timing/retry loop into this test isn't the correct approach > for fixing this test. > > The timing loop isn't necessary because there is already a timing loop > in RMID.start() in the RMI test library. (There's another timing loop > in ActivationLibrary.rmidRunning() which should probably be removed.) > So the intent of this library call is that it start rmid and wait for > it to become ready. That logic doesn't need to be added to the test. > > In the bug report JDK-8032050 you had mentioned that the > NullPointerException was suspicious. You're right! I took a look and > it seemed like it was related to JDK-8023541, and I added a note to > this effect to the bug report. The problem here is that rmid can come > up and transiently return null instead of the stub of the activation > system. That's what JDK-8023541 covers. I think that rmid itself needs > to be fixed, though modifying the timing loop in the RMI test library > to wait for rmid to come up *and* for the lookup to return non-null is > an easy way to fix the problem. (Or at least cover it up.) > > The next step in the analysis is to determine, given that > ActivationLibrary.getSystem can sometimes return null, whether this > has actually caused this test failure. This is pretty easy to > determine; just hack in a line "system = null" in the right place and > run the test. I've done this, and the test times out and the output > log is pretty much identical to the one in the bug report. (I > recommend you try this yourself.) So I think it's fairly safe to say > that the problem in JDK-8023541 has caused the failure listed in > JDK-8032050. > > I can see a couple ways to proceed here. One way is just to close this > out as a duplicate of JDK-8023541 since that bug caused this failure. > > Another is that this test could use some cleaning up. This bug > certainly covers a failure, but the messages emitted are confusing and > in some cases completely wrong. For example, the "rmid has shutdown" > message at line 180 is incorrect, because in this case rmid is still > running and the wait() call has timed out. Most of the code here can > be replaced with calls to various bits of the RMI test library. There > are a bunch of other things in this test that could be cleaned up as > well. > > It's up to you how you'd like to proceed. > > s'marks From michael.cui at oracle.com Sun Jan 26 08:10:16 2014 From: michael.cui at oracle.com (michael cui) Date: Sun, 26 Jan 2014 16:10:16 +0800 Subject: RFR for JDK-8028711: TEST_BUG: Tests should pass through VM options: corelibs tests Message-ID: <52E4C2E8.1060605@oracle.com> Hi, Please review the following code changes for https://bugs.openjdk.java.net/browse/JDK-8028711 The bug and fix are for enforcing the following rules: launch java from shell script, ${TESTVMOPTS} and ${TESTJAVAOPTS} should be passed in. launch javac from shell script, ${TESTTOOLVMOPTS} and ${TESTJAVACOPTS} should be passed in. So almost all the scripts who failed to follow above rules are touched by this fix. There are very few exceptions since test cases explicitly state that they are intended to launch java without any vm options. webrev http://cr.openjdk.java.net/~tyan/michael/JDK-8028711/webrev.01/ Thanks, Michael Cui From Alan.Bateman at oracle.com Sun Jan 26 09:14:26 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 26 Jan 2014 09:14:26 +0000 Subject: RFR for JDK-8028711: TEST_BUG: Tests should pass through VM options: corelibs tests In-Reply-To: <52E4C2E8.1060605@oracle.com> References: <52E4C2E8.1060605@oracle.com> Message-ID: <52E4D1F2.4030406@oracle.com> On 26/01/2014 08:10, michael cui wrote: > Hi, > > Please review the following code changes for > > https://bugs.openjdk.java.net/browse/JDK-8028711 > > The bug and fix are for enforcing the following rules: > > launch java from shell script, ${TESTVMOPTS} and ${TESTJAVAOPTS} > should be passed in. > launch javac from shell script, ${TESTTOOLVMOPTS} and ${TESTJAVACOPTS} > should be passed in. > > So almost all the scripts who failed to follow above rules are touched > by this fix. > > There are very few exceptions since test cases explicitly state that > they are intended to launch java without any vm options. > > > webrev > http://cr.openjdk.java.net/~tyan/michael/JDK-8028711/webrev.01/ You might be aware of this area but we've had two previous efforts ([1] [2]) to update these tests to pass through options. I have to admit that I wasn't aware of TESTJAVAOPTS or TESTJAVACOPTS. Looking at the" jtreg -help all" page then these seem to correspond to -javaoption and -javacoption. I see -vmoption used all the time to specify options, I don't think I've seen -javaoption being used but I see your point. One thing that might be helpful here is some guidance or examples as it confusing to have so many options that initially appear to do the same thing. Mike Duigou might want to have a quick look to see if jdk/Makefile needs to be updated to support -javacoption. As these tests aren't really testing javac (except incidentally) then it might not be important but it's yet another place where you can loose a finger. I haven't looked at all the files but just notice that you've updated the genXXX scripts. They are used to generate tests, they aren't tests themselves and so aren't run by jtreg. So are you planning to also update the java tests that create VMs to pass through the options? This point came up during previous efforts (and some test infrastructure has been added) but it isn't clear to me where we are on that. -Alan. [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ae5d04dbacd6 [2] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7da291690aa0 From peter.levart at gmail.com Sun Jan 26 19:07:35 2014 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 26 Jan 2014 20:07:35 +0100 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52E33F11.8000804@oracle.com> References: <52B3568B.5050905@oracle.com> <52CCEDE0.8000809@oracle.com> <52CCF079.4090301@oracle.com> <52CD45E7.7010203@gmail.com> <52CE4E2D.300@oracle.com> <52CF37C6.1070605@oracle.com> <52CFAFEB.9090703@gmail.com> <52CFD218.2060101@gmail.com> <52D06B70.60001@oracle.com> <52D15201.90109@gmail.com> <52D47D59.8040905@oracle.com> <52D72577.1050506@oracle.com> <52D76859.2030502@oracle.com> <52D82968.4030608@oracle.com> <52D8929B.2020905@oracle.com> <52D8A42A.4020906@oracle.com> <52D8B3B6.3030202@oracle.com> <52D9295D.6080106@gmail.com> <52D92C73.2020309@gmail.com> <52D92F1A.4040400@gmail.com> <52DC812C.1000607@oracle.com> <52DCD78E.8050404@gmail.com> <52DCE17B.4050708@gmail.com> <52DDD9F3.1050201@oracle.com> <52DE19C1.2070302@gmail.com> <52DE9147.4030305@gmail.com> <52DEB9C4.4030606@oracle.com> <52DEF53C.3050905@gmail.com> <52E1772A.1050608@oracle.com> <52E1B4C5.8050807@oracle.com> <52E1C7AD.8090100@oracle.com> <52E2FFE2.7000600@gmail.com> <52E33F11.8000804@oracle.com> Message-ID: <52E55CF7.6050400@gmail.com> On 01/25/2014 05:35 AM, srikalyan chandrashekar wrote: > Hi Peter, if you are a committer would you like to take this further > (OR) perhaps david could sponsor this change. Hi, Here's new webrev that takes into account Kaylan's and David's review comments: cr.openjdk.java.net/~plevart/jdk9-dev/OOMEInReferenceHandler/webrev.02/ I changed into using Class.forName() instead of Unsafe for class preloading and initialization just to be on the safe side regarding unwanted premature initialization of Unsafe class. I also took the liberty of removing an unneeded semicolon (line 114) and fixing a JDK 8 compile time error in generics (line 189): incompatible types: java.lang.ref.ReferenceQueue cannot be converted to java.lang.ref.ReferenceQueue I re-ran the java/lang/ref tests and they pass. Can I count you as a reviewer, Kalyan? If I get a "go" also from David, I'll commit this to jdk9/dev... Regards, Peter > -- > Thanks > kalyan > On 1/24/14 4:05 PM, Peter Levart wrote: >> >> On 01/24/2014 02:53 AM, srikalyan chandrashekar wrote: >>> Hi David, yes thats right, only benefit i see is we can avoid >>> assignment to 'r' if pending is null. >> >> Hi Kalyan, >> >> Good to hear that test runs without failures so far. >> >> Regarding assignment of 'r'. What I tried to accomplish with the >> change was eliminate double reading of 'pending' field. I have a >> mental model of local variable being a register and field being a >> memory location. This may be important if the field is volatile, but >> for normal fields, I guess the optimizer knows how to compile such >> code most optimally in either case. The old (your) version is better >> from logical perspective, since it guarantees that dereferencing the >> 'r', wherever it is possible, will never throw NPE (dereferencing >> where 'r' is not assigned is not possible because of definitive >> assignment rules). So I support going back to your version... >> >> Regards, Peter >> >>> >>> -- >>> Thanks >>> kalyan >>> >>> On 1/23/14 4:33 PM, David Holmes wrote: >>>> On 24/01/2014 6:10 AM, srikalyan wrote: >>>>> Hi Peter, i have modified your code from >>>>> >>>>> r = pending; >>>>> if (r != null) { >>>>> ...... >>>>> TO >>>>> if (pending != null) { >>>>> r = pending; >>>>> >>>>> This is because the r is used later in the code and must not be >>>>> assigned >>>>> pending unless it is not null(this was as is earlier). >>>> >>>> If r is null, because pending is null then you perform the wait() >>>> and then continue - back to the top of the loop. There is no bug in >>>> Peter's code. >>>> >>>> The new webrev is >>>>> posted here >>>>> http://cr.openjdk.java.net/~srikchan/Regression/JDK-8022321_OOMEInReferenceHandler-webrev-V2/ >>>>> >>>>> . I ran a 1000 run and no failures so far, however i would like to >>>>> run a >>>>> couple more 1000 runs to assert the fix. >>>>> >>>>> PS: The description section of JEP-122 >>>>> (http://openjdk.java.net/jeps/122) says meta-data would be in native >>>>> memory(not heap). >>>> >>>> The class_mirror is a Java object not meta-data. >>>> >>>> David >>>> >>>>> -- >>>>> Thanks >>>>> kalyan >>>>> Ph: (408)-585-8040 >>>>> >>>>> >>>>> On 1/21/14, 2:31 PM, Peter Levart wrote: >>>>>> >>>>>> On 01/21/2014 07:17 PM, srikalyan wrote: >>>>>>> Hi Peter/David, catching up after long weekend. Why would there >>>>>>> be an >>>>>>> OOME in object heap due to class loading in perm gen space ? >>>>>> >>>>>> The perm gen is not a problem her (JDK 8 does not have it and we see >>>>>> OOME on JDK8 too). Each time a class is loaded, new java.lang.Class >>>>>> object is allocated on heap. >>>>>> >>>>>> Regards, Peter >>>>>> >>>>>>> Please correct if i am missing something here. Meanwhile i will >>>>>>> give >>>>>>> the version of Reference Handler you both agreed on a try. >>>>>>> -- >>>>>>> Thanks >>>>>>> kalyan >>>>>>> Ph: (408)-585-8040 >>>>>>> >>>>>>> On 1/21/14, 7:24 AM, Peter Levart wrote: >>>>>>>> On 01/21/2014 07:54 AM, Peter Levart wrote: >>>>>>>>> *[Loaded sun.misc.Cleaner from >>>>>>>>> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar]* >>>>>>>>> [Loaded java.io.ByteArrayInputStream from >>>>>>>>> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >>>>>>>>> [Loaded sun.util.calendar.ZoneInfoFile$ZoneOffsetTransitionRule >>>>>>>>> from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >>>>>>>>> ... >>>>>>>>> >>>>>>>>> >>>>>>>>> I'm on linux, 64bit and using official EA build 121 of JDK 8... >>>>>>>>> >>>>>>>>> But if I try with JDK 7u45, I don't see it. >>>>>>>> >>>>>>>> So what changed between JDK 7 and JDK 8? >>>>>>>> >>>>>>>> I suspect the following: 8007572: Replace existing jdk timezone >>>>>>>> data >>>>>>>> at /lib/zi with JSR310's tzdb >>>>>>>> >>>>>>>> >>>>>>>> Regards, Peter >>>>>>>> >>>>>> >>> >> > From srikalyan.chandrashekar at oracle.com Sun Jan 26 21:21:59 2014 From: srikalyan.chandrashekar at oracle.com (srikalyan chandrashekar) Date: Sun, 26 Jan 2014 13:21:59 -0800 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52E55CF7.6050400@gmail.com> References: <52B3568B.5050905@oracle.com> <52CCF079.4090301@oracle.com> <52CD45E7.7010203@gmail.com> <52CE4E2D.300@oracle.com> <52CF37C6.1070605@oracle.com> <52CFAFEB.9090703@gmail.com> <52CFD218.2060101@gmail.com> <52D06B70.60001@oracle.com> <52D15201.90109@gmail.com> <52D47D59.8040905@oracle.com> <52D72577.1050506@oracle.com> <52D76859.2030502@oracle.com> <52D82968.4030608@oracle.com> <52D8929B.2020905@oracle.com> <52D8A42A.4020906@oracle.com> <52D8B3B6.3030202@oracle.com> <52D9295D.6080106@gmail.com> <52D92C73.2020309@gmail.com> <52D92F1A.4040400@gmail.com> <52DC812C.1000607@oracle.com> <52DCD78E.8050404@gmail.com> <52DCE17B.4050708@gmail.com> <52DDD9F3.1050201@oracle.com> <52DE19C1.2070302@gmail.com> <52DE9147.4030305@gmail.com> <52DEB9C4.4030606@oracle.com> <52DEF53C.3050905@gmail.com> <52E1772A.1050608@oracle.com> <52E1B4C5.8050807@oracle.com> <52E1C7AD.8090100@oracle.com> <52E2FFE2.7000600@gmail.com> <52E33F11.8000804@oracle.com> <52E55CF7.6050400@gmail.com> Message-ID: <52E57C77.8030203@oracle.com> On 1/26/14 11:07 AM, Peter Levart wrote: > > On 01/25/2014 05:35 AM, srikalyan chandrashekar wrote: >> Hi Peter, if you are a committer would you like to take this further >> (OR) perhaps david could sponsor this change. > > Hi, > > Here's new webrev that takes into account Kaylan's and David's review > comments: > > cr.openjdk.java.net/~plevart/jdk9-dev/OOMEInReferenceHandler/webrev.02/ > > > I changed into using Class.forName() instead of Unsafe for class > preloading and initialization just to be on the safe side regarding > unwanted premature initialization of Unsafe class. I also took the > liberty of removing an unneeded semicolon (line 114) and fixing a JDK > 8 compile time error in generics (line 189): > > incompatible types: java.lang.ref.ReferenceQueue super java.lang.Object> cannot be converted to > java.lang.ref.ReferenceQueue > > I re-ran the java/lang/ref tests and they pass. > > Can I count you as a reviewer, Kalyan? If I get a "go" also from > David, I'll commit this to jdk9/dev... Hi Peter, I do not have review rights. So it has to be someone else from core-libs-dev. > > Regards, Peter -- Thanks kalyan > >> -- >> Thanks >> kalyan >> On 1/24/14 4:05 PM, Peter Levart wrote: >>> >>> On 01/24/2014 02:53 AM, srikalyan chandrashekar wrote: >>>> Hi David, yes thats right, only benefit i see is we can avoid >>>> assignment to 'r' if pending is null. >>> >>> Hi Kalyan, >>> >>> Good to hear that test runs without failures so far. >>> >>> Regarding assignment of 'r'. What I tried to accomplish with the >>> change was eliminate double reading of 'pending' field. I have a >>> mental model of local variable being a register and field being a >>> memory location. This may be important if the field is volatile, but >>> for normal fields, I guess the optimizer knows how to compile such >>> code most optimally in either case. The old (your) version is better >>> from logical perspective, since it guarantees that dereferencing the >>> 'r', wherever it is possible, will never throw NPE (dereferencing >>> where 'r' is not assigned is not possible because of definitive >>> assignment rules). So I support going back to your version... >>> >>> Regards, Peter >>> >>>> >>>> -- >>>> Thanks >>>> kalyan >>>> >>>> On 1/23/14 4:33 PM, David Holmes wrote: >>>>> On 24/01/2014 6:10 AM, srikalyan wrote: >>>>>> Hi Peter, i have modified your code from >>>>>> >>>>>> r = pending; >>>>>> if (r != null) { >>>>>> ...... >>>>>> TO >>>>>> if (pending != null) { >>>>>> r = pending; >>>>>> >>>>>> This is because the r is used later in the code and must not be >>>>>> assigned >>>>>> pending unless it is not null(this was as is earlier). >>>>> >>>>> If r is null, because pending is null then you perform the wait() >>>>> and then continue - back to the top of the loop. There is no bug >>>>> in Peter's code. >>>>> >>>>> The new webrev is >>>>>> posted here >>>>>> http://cr.openjdk.java.net/~srikchan/Regression/JDK-8022321_OOMEInReferenceHandler-webrev-V2/ >>>>>> >>>>>> . I ran a 1000 run and no failures so far, however i would like >>>>>> to run a >>>>>> couple more 1000 runs to assert the fix. >>>>>> >>>>>> PS: The description section of JEP-122 >>>>>> (http://openjdk.java.net/jeps/122) says meta-data would be in native >>>>>> memory(not heap). >>>>> >>>>> The class_mirror is a Java object not meta-data. >>>>> >>>>> David >>>>> >>>>>> -- >>>>>> Thanks >>>>>> kalyan >>>>>> Ph: (408)-585-8040 >>>>>> >>>>>> >>>>>> On 1/21/14, 2:31 PM, Peter Levart wrote: >>>>>>> >>>>>>> On 01/21/2014 07:17 PM, srikalyan wrote: >>>>>>>> Hi Peter/David, catching up after long weekend. Why would there >>>>>>>> be an >>>>>>>> OOME in object heap due to class loading in perm gen space ? >>>>>>> >>>>>>> The perm gen is not a problem her (JDK 8 does not have it and we >>>>>>> see >>>>>>> OOME on JDK8 too). Each time a class is loaded, new java.lang.Class >>>>>>> object is allocated on heap. >>>>>>> >>>>>>> Regards, Peter >>>>>>> >>>>>>>> Please correct if i am missing something here. Meanwhile i will >>>>>>>> give >>>>>>>> the version of Reference Handler you both agreed on a try. >>>>>>>> -- >>>>>>>> Thanks >>>>>>>> kalyan >>>>>>>> Ph: (408)-585-8040 >>>>>>>> >>>>>>>> On 1/21/14, 7:24 AM, Peter Levart wrote: >>>>>>>>> On 01/21/2014 07:54 AM, Peter Levart wrote: >>>>>>>>>> *[Loaded sun.misc.Cleaner from >>>>>>>>>> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar]* >>>>>>>>>> [Loaded java.io.ByteArrayInputStream from >>>>>>>>>> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >>>>>>>>>> [Loaded sun.util.calendar.ZoneInfoFile$ZoneOffsetTransitionRule >>>>>>>>>> from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I'm on linux, 64bit and using official EA build 121 of JDK 8... >>>>>>>>>> >>>>>>>>>> But if I try with JDK 7u45, I don't see it. >>>>>>>>> >>>>>>>>> So what changed between JDK 7 and JDK 8? >>>>>>>>> >>>>>>>>> I suspect the following: 8007572: Replace existing jdk >>>>>>>>> timezone data >>>>>>>>> at /lib/zi with JSR310's tzdb >>>>>>>>> >>>>>>>>> >>>>>>>>> Regards, Peter >>>>>>>>> >>>>>>> >>>> >>> >> > From michael.cui at oracle.com Mon Jan 27 01:22:11 2014 From: michael.cui at oracle.com (michael cui) Date: Mon, 27 Jan 2014 09:22:11 +0800 Subject: RFR for JDK-8028711: TEST_BUG: Tests should pass through VM options: corelibs tests In-Reply-To: <52E4D1F2.4030406@oracle.com> References: <52E4C2E8.1060605@oracle.com> <52E4D1F2.4030406@oracle.com> Message-ID: <52E5B4C3.6080405@oracle.com> On 01/26/2014 05:14 PM, Alan Bateman wrote: > On 26/01/2014 08:10, michael cui wrote: >> Hi, >> >> Please review the following code changes for >> >> https://bugs.openjdk.java.net/browse/JDK-8028711 >> >> The bug and fix are for enforcing the following rules: >> >> launch java from shell script, ${TESTVMOPTS} and ${TESTJAVAOPTS} >> should be passed in. >> launch javac from shell script, ${TESTTOOLVMOPTS} and >> ${TESTJAVACOPTS} should be passed in. >> >> So almost all the scripts who failed to follow above rules are >> touched by this fix. >> >> There are very few exceptions since test cases explicitly state that >> they are intended to launch java without any vm options. >> >> >> webrev >> http://cr.openjdk.java.net/~tyan/michael/JDK-8028711/webrev.01/ > You might be aware of this area but we've had two previous efforts > ([1] [2]) to update these tests to pass through options. I am aware of efforts [1] JDK-8003890. Initially JDK-8028711 is opened for double check the result of JDK-8003890 and fix them if there are uncovered scripts. Initial list scripts need to touch are : java/lang/Thread/UncaughtExceptions.sh sun/tools/common/ApplicationSetup.sh sun/tools/jrunscript/jrunscript-argsTest.sh sun/tools/jrunscript/jrunscript-cpTest.sh sun/tools/jrunscript/jrunscript-DTest.sh sun/tools/jrunscript/jrunscript-eTest.sh sun/tools/jrunscript/jrunscript-fTest.sh sun/tools/jrunscript/jrunscriptTest.sh Later on, by reading http://openjdk.java.net/jtreg/vmoptions.html and current last comments of JDK-8019502 (which is the parent of JDK-8028711), also by exploring current existing usage (I mean large part of scripts passing TESTJAVAOPTS or TESTJAVACOPTS.), I feel that we might want to make the consistent usage of these two env variables as well. I am not aware of efforts [2]. Thanks for the link. > I have to admit that I wasn't aware of TESTJAVAOPTS or TESTJAVACOPTS. > Looking at the" jtreg -help all" page then these seem to correspond to > -javaoption and -javacoption. I see -vmoption used all the time to > specify options, I don't think I've seen -javaoption being used but I > see your point. One thing that might be helpful here is some guidance > or examples as it confusing to have so many options that initially > appear to do the same thing. I just attached a very simple example to show the behaviours described at http://openjdk.java.net/jtreg/vmoptions.html. Sample can download it from https://bugs.openjdk.java.net/secure/attachment/18467/sample.zip My understanding of options is : When we start jtreg with "-vmoptions" , jtreg will set its value to TESTVMOPTS and TESTTOOLVMOPTS before running shell script test (shell scripts identified by jtreg tags @test and @run shell ). So if we call java with TESTVMOPTS and call javac with TESTTOOLVMOPTS in shell script, then it impact to both. If we want to set some options only for launching java without impact other javac or other java tools, then we need to use "-javaoptions" with jtreg. (Precondition : TESTJAVAOPTS was passed) Similarly, "-javacoptions" will only impact launching javac from all shell scripts. (Precondition : TESTJAVACOPTS was passed) It would be less confusing if we could keep use them in a consistent way. > > Mike Duigou might want to have a quick look to see if jdk/Makefile > needs to be updated to support -javacoption. As these tests aren't > really testing javac (except incidentally) then it might not be > important but it's yet another place where you can loose a finger. > > I haven't looked at all the files but just notice that you've updated > the genXXX scripts. They are used to generate tests, they aren't tests > themselves and so aren't run by jtreg. Then I will rollback those changes. I found three scripts belongs to these category. test/java/nio/Buffer/genBasic.sh test/java/nio/Buffer/genCopyDirectMemory.sh test/java/util/Formatter/genBasic.sh > > So are you planning to also update the java tests that create VMs to > pass through the options? This point came up during previous efforts > (and some test infrastructure has been added) but it isn't clear to me > where we are on that. > I don't plan to cover that in this bug fix. I though it will be covered by JDK-8019502. I could work on that bug if you want me to cover that as well. > -Alan. > > [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ae5d04dbacd6 > [2] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7da291690aa0 -Michael Cui From vladimir.x.ivanov at oracle.com Mon Jan 27 16:05:32 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 27 Jan 2014 20:05:32 +0400 Subject: [8] RFR (XS): 8032585: JSR292: IllegalAccessError when attempting to invoke protected method from different package Message-ID: <52E683CC.9020300@oracle.com> http://cr.openjdk.java.net/~vlivanov/8032585/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8032585 JSR292 access verification logic refuses method handle lookup access to methods which are defined on inaccessible classes. This is usually correct, but in the corner case of inheritance through a public class, it is wrong. 8029507 makes the JVM provide more correct information about the defining class of a looked-up method and this corrected information is causing the old and wrong checks to fail where they didn't fail before. The fix is to relax the check: don't require the class where protected member is declared to be public. It is enough to check that defining class is a super class of the class lookup request comes from to ensure there are enough privileges to access protected member. Testing: regression test, enumeration tests on access checks, jdk/test/java/lang/invoke, vm.mlvm.testlist Thanks! Best regards, Vladimir Ivanov From mike.duigou at oracle.com Mon Jan 27 17:44:04 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 27 Jan 2014 09:44:04 -0800 Subject: StringJoiner: detect or fix delimiter collision? In-Reply-To: <5ACEEEB3-A1D3-4F45-9D78-FDFE567A65B0@bluewin.ch> References: <51673A45.8060908@oracle.com> <1374608627412-145039.post@n7.nabble.com> <52218FE6.7000804@bluewin.ch> <7916219F-E651-4939-BFB2-7D7CC38C9EEF@bluewin.ch> <5ACEEEB3-A1D3-4F45-9D78-FDFE567A65B0@bluewin.ch> Message-ID: <54010BC7-BDB8-4471-AC2F-20C9449FB85B@oracle.com> On Jan 26 2014, at 17:12 , Philip Hodges wrote: > Please please please drop StringJoiner from Java 1.8 before it is too late. It is well past "too late". The API has been frozen since August for all but the most exceptional cases. >>> At first I thought they were cool. Then I tried to use them in anger. >>> And was forced to roll my own. >> >> I would encourage you to share your implementation or the javadocs as grist for discussion. An actual alternative is the *only* thing that is likely to be persuasive. You seem to be very much in the minority on this issue by the silence from other responders on this list and elsewhere. The concerns you've highlighted with regard to delimiter management, while certainly valid, have not been of sufficient concern to suggest a change in the proposal. The prediction that using StringJoiner will become Java's sprintf seems unlikely to be be true. The reception we've seen thus far for StringJoiner has been otherwise exclusively enthusiastic and positive. Alternatives, refinements and counterproposals are always welcome in the discussion. Doomsaying unfortunately adds little. Mike From christian.thalinger at oracle.com Mon Jan 27 18:54:25 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 27 Jan 2014 10:54:25 -0800 Subject: [8] RFR (XS): 8032585: JSR292: IllegalAccessError when attempting to invoke protected method from different package In-Reply-To: <52E683CC.9020300@oracle.com> References: <52E683CC.9020300@oracle.com> Message-ID: <7CBAE4B0-6BF6-4ED1-85D3-D089B1609F75@oracle.com> Looks good. On Jan 27, 2014, at 8:05 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8032585/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8032585 > > JSR292 access verification logic refuses method handle lookup access to > methods which are defined on inaccessible classes. This is usually > correct, but in the corner case of inheritance through a public class, > it is wrong. 8029507 makes the JVM provide more correct information > about the defining class of a looked-up method and this corrected > information is causing the old and wrong checks to fail where they > didn't fail before. > > The fix is to relax the check: don't require the class where protected > member is declared to be public. It is enough to check that defining > class is a super class of the class lookup request comes from to ensure > there are enough privileges to access protected member. > > Testing: regression test, enumeration tests on access checks, > jdk/test/java/lang/invoke, vm.mlvm.testlist > > Thanks! > > Best regards, > Vladimir Ivanov > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From mike.duigou at oracle.com Mon Jan 27 20:17:05 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 27 Jan 2014 12:17:05 -0800 Subject: RFR: 8022854 : (s) Cleaner re-initialization of System properties Message-ID: <71B48C6D-1534-477F-82BA-1B9A155FF41E@oracle.com> Hello all; This is a bit of cleanup I did back during Java 8 that got deferred due to it's late arrival during the development cycle. I've updated it for Java 9. http://cr.openjdk.java.net/~mduigou/JDK-8022854/0/webrev/ This change improves the implementation of System.setProperties(null) which restores the system properties to their boot time defaults. The existing semantics are preserved. Mike From golovnin at gmx.net Mon Jan 27 22:04:51 2014 From: golovnin at gmx.net (Andrej Golovnin) Date: Mon, 27 Jan 2014 23:04:51 +0100 Subject: Which optimizations does Hotspot apply? In-Reply-To: <52E38E69.3070409@univ-mlv.fr> References: <09548E95-EA91-4986-A692-EC2DCE0944BB@snazy.de> <52E05640.3020000@univ-mlv.fr> <52E38E69.3070409@univ-mlv.fr> Message-ID: Hi R?mi, Vitaly, Thank you for your explanation and for the tips! > if you see a lot of instances of ArrayList iterator it means that you have a code path that create an iterator and use it later and the JIT is not able to see the creation and the use in the same inlining horizon. As Vitaly said, it's perhaps because you have the same code called with several different kinds of List (teach your programmer to stop to use LinkedList :) or because the code create an Iterator too far from where you use it (by example if the iterator is stored in a List or a Map). I fight the LinkedList all the time. :-) Cheers, Andrej From john.r.rose at oracle.com Tue Jan 28 00:50:23 2014 From: john.r.rose at oracle.com (John Rose) Date: Mon, 27 Jan 2014 16:50:23 -0800 Subject: [8] RFR (XS): 8032585: JSR292: IllegalAccessError when attempting to invoke protected method from different package In-Reply-To: <52E683CC.9020300@oracle.com> References: <52E683CC.9020300@oracle.com> Message-ID: <6D29FC61-61AA-44EB-B7E2-2DB2E169D81A@oracle.com> This is safe as a point fix, since (a) Lookup.checkSymbolicClass vets 'refc' before checkMemberAccess is called, and (b) the JVMS does not in fact call for 'defc' to also be accessible, if it is inherited via 'refc'. There is a slightly different problem here, a code cleanup problem. The javadoc for checkMemberAccess does not seem to accurately reflect what the method does or how it works. We need to re-align the javadoc, the JVM spec., and (if necessary) the code. For example, I would prefer either an explicit call from checkMemberAccess to isClassAccessible, or at least have an assert in there. This will take a little more time and care to do right. I see two choices; either are OK with me as a reviewer: 1. Do the point fix as proposed and file a followup bug. 2. Fix the javadoc, add the assert, and re-review correspondence between checkMemberAccess (javadoc+code) and the JVM spec. for member access. ? John On Jan 27, 2014, at 8:05 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8032585/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8032585 > > JSR292 access verification logic refuses method handle lookup access to > methods which are defined on inaccessible classes. This is usually > correct, but in the corner case of inheritance through a public class, > it is wrong. 8029507 makes the JVM provide more correct information > about the defining class of a looked-up method and this corrected > information is causing the old and wrong checks to fail where they > didn't fail before. > > The fix is to relax the check: don't require the class where protected > member is declared to be public. It is enough to check that defining > class is a super class of the class lookup request comes from to ensure > there are enough privileges to access protected member. > > Testing: regression test, enumeration tests on access checks, > jdk/test/java/lang/invoke, vm.mlvm.testlist > > Thanks! > > Best regards, > Vladimir Ivanov > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From david.holmes at oracle.com Tue Jan 28 02:17:50 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 Jan 2014 12:17:50 +1000 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52E55CF7.6050400@gmail.com> References: <52B3568B.5050905@oracle.com> <52CCF079.4090301@oracle.com> <52CD45E7.7010203@gmail.com> <52CE4E2D.300@oracle.com> <52CF37C6.1070605@oracle.com> <52CFAFEB.9090703@gmail.com> <52CFD218.2060101@gmail.com> <52D06B70.60001@oracle.com> <52D15201.90109@gmail.com> <52D47D59.8040905@oracle.com> <52D72577.1050506@oracle.com> <52D76859.2030502@oracle.com> <52D82968.4030608@oracle.com> <52D8929B.2020905@oracle.com> <52D8A42A.4020906@oracle.com> <52D8B3B6.3030202@oracle.com> <52D9295D.6080106@gmail.com> <52D92C73.2020309@gmail.com> <52D92F1A.4040400@gmail.com> <52DC812C.1000607@oracle.com> <52DCD78E.8050404@gmail.com> <52DCE17B.4050708@gmail.com> <52DDD9F3.1050201@oracle.com> <52DE19C1.2070302@gmail.com> <52DE9147.4030305@gmail.com> <52DEB9C4.4030606@oracle.com> <52DEF53C.3050905@gmail.com> <52E1772A.1050608@oracle.com> <52E1B4C5.8050807@oracle.com> <52E1C7AD.8090100@oracle.com> <52E2FFE2.7000600@gmail.com> <52E33F11.8000804@oracle.com> <52E55CF7.6050400@gmail.com> Message-ID: <52E7134E.9070606@oracle.com> On 27/01/2014 5:07 AM, Peter Levart wrote: > > On 01/25/2014 05:35 AM, srikalyan chandrashekar wrote: >> Hi Peter, if you are a committer would you like to take this further >> (OR) perhaps david could sponsor this change. > > Hi, > > Here's new webrev that takes into account Kaylan's and David's review > comments: > > cr.openjdk.java.net/~plevart/jdk9-dev/OOMEInReferenceHandler/webrev.02/ > > > I changed into using Class.forName() instead of Unsafe for class > preloading and initialization just to be on the safe side regarding > unwanted premature initialization of Unsafe class. I also took the > liberty of removing an unneeded semicolon (line 114) and fixing a JDK 8 > compile time error in generics (line 189): > > incompatible types: java.lang.ref.ReferenceQueue super java.lang.Object> cannot be converted to > java.lang.ref.ReferenceQueue Seems somewhat odd given there is no supertype for Object but it is consistent with the field declaration: ReferenceQueue queue; The generics here is a little odd as we don't really know the type of T we just play fast-and-loose by declaring: Reference r; Which only works because of erasure. I guess it wouldn't work to try and use a simple wildcard '?' for both 'r' and 'q' as they would be different captures to javac. > I re-ran the java/lang/ref tests and they pass. > > Can I count you as a reviewer, Kalyan? If I get a "go" also from David, > I'll commit this to jdk9/dev... I can be counted as the Reviewer. Kalyan can be listed as a reviewer. Thanks Peter. David ----- > Regards, Peter > >> -- >> Thanks >> kalyan >> On 1/24/14 4:05 PM, Peter Levart wrote: >>> >>> On 01/24/2014 02:53 AM, srikalyan chandrashekar wrote: >>>> Hi David, yes thats right, only benefit i see is we can avoid >>>> assignment to 'r' if pending is null. >>> >>> Hi Kalyan, >>> >>> Good to hear that test runs without failures so far. >>> >>> Regarding assignment of 'r'. What I tried to accomplish with the >>> change was eliminate double reading of 'pending' field. I have a >>> mental model of local variable being a register and field being a >>> memory location. This may be important if the field is volatile, but >>> for normal fields, I guess the optimizer knows how to compile such >>> code most optimally in either case. The old (your) version is better >>> from logical perspective, since it guarantees that dereferencing the >>> 'r', wherever it is possible, will never throw NPE (dereferencing >>> where 'r' is not assigned is not possible because of definitive >>> assignment rules). So I support going back to your version... >>> >>> Regards, Peter >>> >>>> >>>> -- >>>> Thanks >>>> kalyan >>>> >>>> On 1/23/14 4:33 PM, David Holmes wrote: >>>>> On 24/01/2014 6:10 AM, srikalyan wrote: >>>>>> Hi Peter, i have modified your code from >>>>>> >>>>>> r = pending; >>>>>> if (r != null) { >>>>>> ...... >>>>>> TO >>>>>> if (pending != null) { >>>>>> r = pending; >>>>>> >>>>>> This is because the r is used later in the code and must not be >>>>>> assigned >>>>>> pending unless it is not null(this was as is earlier). >>>>> >>>>> If r is null, because pending is null then you perform the wait() >>>>> and then continue - back to the top of the loop. There is no bug in >>>>> Peter's code. >>>>> >>>>> The new webrev is >>>>>> posted here >>>>>> http://cr.openjdk.java.net/~srikchan/Regression/JDK-8022321_OOMEInReferenceHandler-webrev-V2/ >>>>>> >>>>>> . I ran a 1000 run and no failures so far, however i would like to >>>>>> run a >>>>>> couple more 1000 runs to assert the fix. >>>>>> >>>>>> PS: The description section of JEP-122 >>>>>> (http://openjdk.java.net/jeps/122) says meta-data would be in native >>>>>> memory(not heap). >>>>> >>>>> The class_mirror is a Java object not meta-data. >>>>> >>>>> David >>>>> >>>>>> -- >>>>>> Thanks >>>>>> kalyan >>>>>> Ph: (408)-585-8040 >>>>>> >>>>>> >>>>>> On 1/21/14, 2:31 PM, Peter Levart wrote: >>>>>>> >>>>>>> On 01/21/2014 07:17 PM, srikalyan wrote: >>>>>>>> Hi Peter/David, catching up after long weekend. Why would there >>>>>>>> be an >>>>>>>> OOME in object heap due to class loading in perm gen space ? >>>>>>> >>>>>>> The perm gen is not a problem her (JDK 8 does not have it and we see >>>>>>> OOME on JDK8 too). Each time a class is loaded, new java.lang.Class >>>>>>> object is allocated on heap. >>>>>>> >>>>>>> Regards, Peter >>>>>>> >>>>>>>> Please correct if i am missing something here. Meanwhile i will >>>>>>>> give >>>>>>>> the version of Reference Handler you both agreed on a try. >>>>>>>> -- >>>>>>>> Thanks >>>>>>>> kalyan >>>>>>>> Ph: (408)-585-8040 >>>>>>>> >>>>>>>> On 1/21/14, 7:24 AM, Peter Levart wrote: >>>>>>>>> On 01/21/2014 07:54 AM, Peter Levart wrote: >>>>>>>>>> *[Loaded sun.misc.Cleaner from >>>>>>>>>> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar]* >>>>>>>>>> [Loaded java.io.ByteArrayInputStream from >>>>>>>>>> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >>>>>>>>>> [Loaded sun.util.calendar.ZoneInfoFile$ZoneOffsetTransitionRule >>>>>>>>>> from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I'm on linux, 64bit and using official EA build 121 of JDK 8... >>>>>>>>>> >>>>>>>>>> But if I try with JDK 7u45, I don't see it. >>>>>>>>> >>>>>>>>> So what changed between JDK 7 and JDK 8? >>>>>>>>> >>>>>>>>> I suspect the following: 8007572: Replace existing jdk timezone >>>>>>>>> data >>>>>>>>> at /lib/zi with JSR310's tzdb >>>>>>>>> >>>>>>>>> >>>>>>>>> Regards, Peter >>>>>>>>> >>>>>>> >>>> >>> >> > From mandy.chung at oracle.com Tue Jan 28 03:45:52 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 27 Jan 2014 19:45:52 -0800 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52E55CF7.6050400@gmail.com> References: <52B3568B.5050905@oracle.com> <52CCF079.4090301@oracle.com> <52CD45E7.7010203@gmail.com> <52CE4E2D.300@oracle.com> <52CF37C6.1070605@oracle.com> <52CFAFEB.9090703@gmail.com> <52CFD218.2060101@gmail.com> <52D06B70.60001@oracle.com> <52D15201.90109@gmail.com> <52D47D59.8040905@oracle.com> <52D72577.1050506@oracle.com> <52D76859.2030502@oracle.com> <52D82968.4030608@oracle.com> <52D8929B.2020905@oracle.com> <52D8A42A.4020906@oracle.com> <52D8B3B6.3030202@oracle.com> <52D9295D.6080106@gmail.com> <52D92C73.2020309@gmail.com> <52D92F1A.4040400@gmail.com> <52DC812C.1000607@oracle.com> <52DCD78E.8050404@gmail.com> <52DCE17B.4050708@gmail.com> <52DDD9F3.1050201@oracle.com> <52DE19C1.2070302@gmail.com> <52DE9147.4030305@gmail.com> <52DEB9C4.4030606@oracle.com> <52DEF53C.3050905@gmail.com> <52E1772A.1050608@oracle.com> <52E1B4C5.8050807@oracle.com> <52E1C7AD.8090100@oracle.com> <52E2FFE2.7000600@gmail.com> <52E33F11.8000804@oracle.com> <52E55CF7.6050400@gmail.com> Message-ID: <52E727F0.8080207@oracle.com> On 1/26/2014 11:07 AM, Peter Levart wrote: > > On 01/25/2014 05:35 AM, srikalyan chandrashekar wrote: >> Hi Peter, if you are a committer would you like to take this further >> (OR) perhaps david could sponsor this change. > > Hi, > > Here's new webrev that takes into account Kaylan's and David's review > comments: > > cr.openjdk.java.net/~plevart/jdk9-dev/OOMEInReferenceHandler/webrev.02/ > This looks good to me. Sorry I have been behind in following the discussion of this thread. It's good to see this problem be diagnosed and fixed (thank you all). I also prefer using Class.forName to do the preloading and initialization. Mandy From peter.levart at gmail.com Tue Jan 28 08:44:21 2014 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 28 Jan 2014 09:44:21 +0100 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52E7134E.9070606@oracle.com> References: <52B3568B.5050905@oracle.com> <52CD45E7.7010203@gmail.com> <52CE4E2D.300@oracle.com> <52CF37C6.1070605@oracle.com> <52CFAFEB.9090703@gmail.com> <52CFD218.2060101@gmail.com> <52D06B70.60001@oracle.com> <52D15201.90109@gmail.com> <52D47D59.8040905@oracle.com> <52D72577.1050506@oracle.com> <52D76859.2030502@oracle.com> <52D82968.4030608@oracle.com> <52D8929B.2020905@oracle.com> <52D8A42A.4020906@oracle.com> <52D8B3B6.3030202@oracle.com> <52D9295D.6080106@gmail.com> <52D92C73.2020309@gmail.com> <52D92F1A.4040400@gmail.com> <52DC812C.1000607@oracle.com> <52DCD78E.8050404@gmail.com> <52DCE17B.4050708@gmail.com> <52DDD9F3.1050201@oracle.com> <52DE19C1.2070302@gmail.com> <52DE9147.4030305@gmail.com> <52DEB9C4.4030606@oracle.com> <52DEF53C.3050905@gmail.com> <52E1772A.1050608@oracle.com> <52E1B4C5.8050807@oracle.com> <52E1C7AD.8090100@oracle.com> <52E2FFE2.7000600@gmail.com> <52E33F11.8000804@oracle.com> <52E55CF7.6050400@gmail.com> <52E7134E.9070606@oracle.com> Message-ID: <52E76DE5.1000300@gmail.com> On 01/28/2014 03:17 AM, David Holmes wrote: > On 27/01/2014 5:07 AM, Peter Levart wrote: >> >> On 01/25/2014 05:35 AM, srikalyan chandrashekar wrote: >>> Hi Peter, if you are a committer would you like to take this further >>> (OR) perhaps david could sponsor this change. >> >> Hi, >> >> Here's new webrev that takes into account Kaylan's and David's review >> comments: >> >> cr.openjdk.java.net/~plevart/jdk9-dev/OOMEInReferenceHandler/webrev.02/ >> >> >> I changed into using Class.forName() instead of Unsafe for class >> preloading and initialization just to be on the safe side regarding >> unwanted premature initialization of Unsafe class. I also took the >> liberty of removing an unneeded semicolon (line 114) and fixing a JDK 8 >> compile time error in generics (line 189): >> >> incompatible types: java.lang.ref.ReferenceQueue> super java.lang.Object> cannot be converted to >> java.lang.ref.ReferenceQueue > > Seems somewhat odd given there is no supertype for Object but it is > consistent with the field declaration: > > ReferenceQueue queue; > > The generics here is a little odd as we don't really know the type of > T we just play fast-and-loose by declaring: > > Reference r; > > Which only works because of erasure. I guess it wouldn't work to try > and use a simple wildcard '?' for both 'r' and 'q' as they would be > different captures to javac. Yes, I tried that too and it results in even more unsafe casts. It's odd yes, since the compile-time error is not present when building via OpenJDK build system make files (using "make images" in top directory for example) but only if I compile the class from command line (using javac directly) or from IDEA. I use JDK 8 ea-b121 in all cases as a build JDK. Are there any special options passed to javac for compiling those classes in JDK build system that allow such code? Regards, Peter > >> I re-ran the java/lang/ref tests and they pass. >> >> Can I count you as a reviewer, Kalyan? If I get a "go" also from David, >> I'll commit this to jdk9/dev... > > I can be counted as the Reviewer. Kalyan can be listed as a reviewer. > > Thanks Peter. > > David > ----- > >> Regards, Peter >> >>> -- >>> Thanks >>> kalyan >>> On 1/24/14 4:05 PM, Peter Levart wrote: >>>> >>>> On 01/24/2014 02:53 AM, srikalyan chandrashekar wrote: >>>>> Hi David, yes thats right, only benefit i see is we can avoid >>>>> assignment to 'r' if pending is null. >>>> >>>> Hi Kalyan, >>>> >>>> Good to hear that test runs without failures so far. >>>> >>>> Regarding assignment of 'r'. What I tried to accomplish with the >>>> change was eliminate double reading of 'pending' field. I have a >>>> mental model of local variable being a register and field being a >>>> memory location. This may be important if the field is volatile, but >>>> for normal fields, I guess the optimizer knows how to compile such >>>> code most optimally in either case. The old (your) version is better >>>> from logical perspective, since it guarantees that dereferencing the >>>> 'r', wherever it is possible, will never throw NPE (dereferencing >>>> where 'r' is not assigned is not possible because of definitive >>>> assignment rules). So I support going back to your version... >>>> >>>> Regards, Peter >>>> >>>>> >>>>> -- >>>>> Thanks >>>>> kalyan >>>>> >>>>> On 1/23/14 4:33 PM, David Holmes wrote: >>>>>> On 24/01/2014 6:10 AM, srikalyan wrote: >>>>>>> Hi Peter, i have modified your code from >>>>>>> >>>>>>> r = pending; >>>>>>> if (r != null) { >>>>>>> ...... >>>>>>> TO >>>>>>> if (pending != null) { >>>>>>> r = pending; >>>>>>> >>>>>>> This is because the r is used later in the code and must not be >>>>>>> assigned >>>>>>> pending unless it is not null(this was as is earlier). >>>>>> >>>>>> If r is null, because pending is null then you perform the wait() >>>>>> and then continue - back to the top of the loop. There is no bug in >>>>>> Peter's code. >>>>>> >>>>>> The new webrev is >>>>>>> posted here >>>>>>> http://cr.openjdk.java.net/~srikchan/Regression/JDK-8022321_OOMEInReferenceHandler-webrev-V2/ >>>>>>> >>>>>>> >>>>>>> . I ran a 1000 run and no failures so far, however i would like to >>>>>>> run a >>>>>>> couple more 1000 runs to assert the fix. >>>>>>> >>>>>>> PS: The description section of JEP-122 >>>>>>> (http://openjdk.java.net/jeps/122) says meta-data would be in >>>>>>> native >>>>>>> memory(not heap). >>>>>> >>>>>> The class_mirror is a Java object not meta-data. >>>>>> >>>>>> David >>>>>> >>>>>>> -- >>>>>>> Thanks >>>>>>> kalyan >>>>>>> Ph: (408)-585-8040 >>>>>>> >>>>>>> >>>>>>> On 1/21/14, 2:31 PM, Peter Levart wrote: >>>>>>>> >>>>>>>> On 01/21/2014 07:17 PM, srikalyan wrote: >>>>>>>>> Hi Peter/David, catching up after long weekend. Why would there >>>>>>>>> be an >>>>>>>>> OOME in object heap due to class loading in perm gen space ? >>>>>>>> >>>>>>>> The perm gen is not a problem her (JDK 8 does not have it and >>>>>>>> we see >>>>>>>> OOME on JDK8 too). Each time a class is loaded, new >>>>>>>> java.lang.Class >>>>>>>> object is allocated on heap. >>>>>>>> >>>>>>>> Regards, Peter >>>>>>>> >>>>>>>>> Please correct if i am missing something here. Meanwhile i will >>>>>>>>> give >>>>>>>>> the version of Reference Handler you both agreed on a try. >>>>>>>>> -- >>>>>>>>> Thanks >>>>>>>>> kalyan >>>>>>>>> Ph: (408)-585-8040 >>>>>>>>> >>>>>>>>> On 1/21/14, 7:24 AM, Peter Levart wrote: >>>>>>>>>> On 01/21/2014 07:54 AM, Peter Levart wrote: >>>>>>>>>>> *[Loaded sun.misc.Cleaner from >>>>>>>>>>> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar]* >>>>>>>>>>> [Loaded java.io.ByteArrayInputStream from >>>>>>>>>>> /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >>>>>>>>>>> [Loaded sun.util.calendar.ZoneInfoFile$ZoneOffsetTransitionRule >>>>>>>>>>> from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] >>>>>>>>>>> ... >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I'm on linux, 64bit and using official EA build 121 of JDK 8... >>>>>>>>>>> >>>>>>>>>>> But if I try with JDK 7u45, I don't see it. >>>>>>>>>> >>>>>>>>>> So what changed between JDK 7 and JDK 8? >>>>>>>>>> >>>>>>>>>> I suspect the following: 8007572: Replace existing jdk timezone >>>>>>>>>> data >>>>>>>>>> at /lib/zi with JSR310's tzdb >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Regards, Peter >>>>>>>>>> >>>>>>>> >>>>> >>>> >>> >> From vladimir.x.ivanov at oracle.com Tue Jan 28 09:39:47 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 28 Jan 2014 13:39:47 +0400 Subject: [8] RFR (XS): 8032585: JSR292: IllegalAccessError when attempting to invoke protected method from different package In-Reply-To: <6D29FC61-61AA-44EB-B7E2-2DB2E169D81A@oracle.com> References: <52E683CC.9020300@oracle.com> <6D29FC61-61AA-44EB-B7E2-2DB2E169D81A@oracle.com> Message-ID: <52E77AE3.8090308@oracle.com> Chris, John, thank you for reviewing the fix. I'll proceed with choice #1 then. Filed a bug [1] to track cleanup activities. Best regards, Vladimir Ivanov [1] https://bugs.openjdk.java.net/browse/JDK-8032881 On 1/28/14 4:50 AM, John Rose wrote: > This is safe as a point fix, since (a) Lookup.checkSymbolicClass vets 'refc' before checkMemberAccess is called, and (b) the JVMS does not in fact call for 'defc' to also be accessible, if it is inherited via 'refc'. > > There is a slightly different problem here, a code cleanup problem. The javadoc for checkMemberAccess does not seem to accurately reflect what the method does or how it works. We need to re-align the javadoc, the JVM spec., and (if necessary) the code. For example, I would prefer either an explicit call from checkMemberAccess to isClassAccessible, or at least have an assert in there. This will take a little more time and care to do right. > > I see two choices; either are OK with me as a reviewer: > 1. Do the point fix as proposed and file a followup bug. > 2. Fix the javadoc, add the assert, and re-review correspondence between checkMemberAccess (javadoc+code) and the JVM spec. for member access. > > ? John > > On Jan 27, 2014, at 8:05 AM, Vladimir Ivanov wrote: > >> http://cr.openjdk.java.net/~vlivanov/8032585/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8032585 >> >> JSR292 access verification logic refuses method handle lookup access to >> methods which are defined on inaccessible classes. This is usually >> correct, but in the corner case of inheritance through a public class, >> it is wrong. 8029507 makes the JVM provide more correct information >> about the defining class of a looked-up method and this corrected >> information is causing the old and wrong checks to fail where they >> didn't fail before. >> >> The fix is to relax the check: don't require the class where protected >> member is declared to be public. It is enough to check that defining >> class is a super class of the class lookup request comes from to ensure >> there are enough privileges to access protected member. >> >> Testing: regression test, enumeration tests on access checks, >> jdk/test/java/lang/invoke, vm.mlvm.testlist >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From paul.sandoz at oracle.com Tue Jan 28 12:06:03 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 28 Jan 2014 13:06:03 +0100 Subject: RFR: 8022854 : (s) Cleaner re-initialization of System properties In-Reply-To: <71B48C6D-1534-477F-82BA-1B9A155FF41E@oracle.com> References: <71B48C6D-1534-477F-82BA-1B9A155FF41E@oracle.com> Message-ID: <92ACF6D1-2020-4597-A380-78CBCE5FFA47@oracle.com> Hi Mike, Your patch is slightly out of sync with 9: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c8c4f441fc76 http://hg.openjdk.java.net/jdk9/dev/jdk/file/tip/src/share/classes/sun/misc/VM.java -- Generally looks OK. Bikeshed-wise i prefer something like getPublicSavedProperties rather than getSanitizedSavedProperties. Paul. On Jan 27, 2014, at 9:17 PM, Mike Duigou wrote: > Hello all; > > This is a bit of cleanup I did back during Java 8 that got deferred due to it's late arrival during the development cycle. I've updated it for Java 9. > > http://cr.openjdk.java.net/~mduigou/JDK-8022854/0/webrev/ > > This change improves the implementation of System.setProperties(null) which restores the system properties to their boot time defaults. The existing semantics are preserved. > > Mike From eric.mccorkle at oracle.com Tue Jan 28 13:53:05 2014 From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com) Date: Tue, 28 Jan 2014 13:53:05 +0000 Subject: hg: jdk8/tl/jdk: 8032585: JSR292: IllegalAccessError when attempting to invoke protected method from different package Message-ID: <20140128135328.E3A1662802@hg.openjdk.java.net> Changeset: 56d05f260123 Author: vlivanov Date: 2014-01-28 13:46 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/56d05f260123 8032585: JSR292: IllegalAccessError when attempting to invoke protected method from different package Reviewed-by: twisti, jrose ! src/share/classes/sun/invoke/util/VerifyAccess.java + test/java/lang/invoke/ProtectedMemberDifferentPackage/Test.java + test/java/lang/invoke/ProtectedMemberDifferentPackage/p1/T2.java + test/java/lang/invoke/ProtectedMemberDifferentPackage/p2/T3.java From Alan.Bateman at oracle.com Tue Jan 28 15:27:13 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 28 Jan 2014 15:27:13 +0000 Subject: RFR: 8022854 : (s) Cleaner re-initialization of System properties In-Reply-To: <71B48C6D-1534-477F-82BA-1B9A155FF41E@oracle.com> References: <71B48C6D-1534-477F-82BA-1B9A155FF41E@oracle.com> Message-ID: <52E7CC51.6000608@oracle.com> On 27/01/2014 20:17, Mike Duigou wrote: > Hello all; > > This is a bit of cleanup I did back during Java 8 that got deferred due to it's late arrival during the development cycle. I've updated it for Java 9. > > http://cr.openjdk.java.net/~mduigou/JDK-8022854/0/webrev/ > > This change improves the implementation of System.setProperties(null) which restores the system properties to their boot time defaults. The existing semantics are preserved. > > Mike I agree with Paul on the naming, getSanitizedSavedProperties is a bit odd (but not a big deal as it's internal). On the wording then "reloaded" is better than "is forgotten" but I wonder if it could be a bit clearer, like "reset to the default system properties". On the test then I remember Erik's late change to fix a build issue [1]. He added a simple test as part of that and maybe we should remove that one now and maybe beef up your test to check the properties listed System.getProperties's table are present. A minor comment is that the date in the header suggests you wrote this test in 2013. Also just to keep things consistent then you might want a space in "if(". -Alan. [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2437ccbf3504 From Alan.Bateman at oracle.com Tue Jan 28 15:46:37 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 28 Jan 2014 15:46:37 +0000 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52E76DE5.1000300@gmail.com> References: <52B3568B.5050905@oracle.com> <52CE4E2D.300@oracle.com> <52CF37C6.1070605@oracle.com> <52CFAFEB.9090703@gmail.com> <52CFD218.2060101@gmail.com> <52D06B70.60001@oracle.com> <52D15201.90109@gmail.com> <52D47D59.8040905@oracle.com> <52D72577.1050506@oracle.com> <52D76859.2030502@oracle.com> <52D82968.4030608@oracle.com> <52D8929B.2020905@oracle.com> <52D8A42A.4020906@oracle.com> <52D8B3B6.3030202@oracle.com> <52D9295D.6080106@gmail.com> <52D92C73.2020309@gmail.com> <52D92F1A.4040400@gmail.com> <52DC812C.1000607@oracle.com> <52DCD78E.8050404@gmail.com> <52DCE17B.4050708@gmail.com> <52DDD9F3.1050201@oracle.com> <52DE19C1.2070302@gmail.com> <52DE9147.4030305@gmail.com> <52DEB9C4.4030606@oracle.com> <52DEF53C.3050905@gmail.com> <52E1772A.1050608@oracle.com> <52E1B4C5.8050807@oracle.com> <52E1C7AD.8090100@oracle.com> <52E2FFE2.7000600@gmail.com> <52E33F11.8000804@oracle.com> <52E55CF7.6050400@gmail.com> <52E7134E.9070606@oracle.com> <52E76DE5.1000300@gmail.com> Message-ID: <52E7D0DD.5030507@oracle.com> On 28/01/2014 08:44, Peter Levart wrote: > > Yes, I tried that too and it results in even more unsafe casts. > > It's odd yes, since the compile-time error is not present when > building via OpenJDK build system make files (using "make images" in > top directory for example) but only if I compile the class from > command line (using javac directly) or from IDEA. I use JDK 8 ea-b121 > in all cases as a build JDK. Are there any special options passed to > javac for compiling those classes in JDK build system that allow such > code? > jdk/make/Setup.gmk has the -Xlint options that are used in the build but I suspect it more than that all the classes in java/lang/ref are compiled together. -Alan From mandy.chung at oracle.com Tue Jan 28 17:38:18 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 28 Jan 2014 09:38:18 -0800 Subject: RFR: 8022854 : (s) Cleaner re-initialization of System properties In-Reply-To: <92ACF6D1-2020-4597-A380-78CBCE5FFA47@oracle.com> References: <71B48C6D-1534-477F-82BA-1B9A155FF41E@oracle.com> <92ACF6D1-2020-4597-A380-78CBCE5FFA47@oracle.com> Message-ID: <52E7EB0A.3010700@oracle.com> On 1/28/14 4:06 AM, Paul Sandoz wrote: > Hi Mike, > > Your patch is slightly out of sync with 9: > > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c8c4f441fc76 This was the changeset I pushed yesterday causing this and removed "sun.lang.ClassLoader.allowArraySyntax". Sorry for the timing. > http://hg.openjdk.java.net/jdk9/dev/jdk/file/tip/src/share/classes/sun/misc/VM.java > > -- > > Generally looks OK. > > Bikeshed-wise i prefer something like getPublicSavedProperties rather than getSanitizedSavedProperties. Would getDefaultSystemProperties() be better? I never like the savedProps name and the related method names that I added and thanks for doing the clean up. Mandy > Paul. > > On Jan 27, 2014, at 9:17 PM, Mike Duigou wrote: > >> Hello all; >> >> This is a bit of cleanup I did back during Java 8 that got deferred due to it's late arrival during the development cycle. I've updated it for Java 9. >> >> http://cr.openjdk.java.net/~mduigou/JDK-8022854/0/webrev/ >> >> This change improves the implementation of System.setProperties(null) which restores the system properties to their boot time defaults. The existing semantics are preserved. >> >> Mike From jeff.dinkins at oracle.com Tue Jan 28 20:40:59 2014 From: jeff.dinkins at oracle.com (jeff.dinkins at oracle.com) Date: Tue, 28 Jan 2014 20:40:59 +0000 Subject: hg: jdk8/tl/hotspot: 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Message-ID: <20140128204101.F2B7262824@hg.openjdk.java.net> Changeset: ce0320cdb075 Author: jeff Date: 2014-01-28 20:09 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ce0320cdb075 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Reviewed-by: lana ! THIRD_PARTY_README From jeff.dinkins at oracle.com Tue Jan 28 20:40:07 2014 From: jeff.dinkins at oracle.com (jeff.dinkins at oracle.com) Date: Tue, 28 Jan 2014 20:40:07 +0000 Subject: hg: jdk8/tl/corba: 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Message-ID: <20140128204007.AA92D62823@hg.openjdk.java.net> Changeset: 6d40c0d49c7a Author: jeff Date: 2014-01-28 20:09 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/6d40c0d49c7a 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Reviewed-by: lana ! THIRD_PARTY_README From jeff.dinkins at oracle.com Tue Jan 28 20:41:28 2014 From: jeff.dinkins at oracle.com (jeff.dinkins at oracle.com) Date: Tue, 28 Jan 2014 20:41:28 +0000 Subject: hg: jdk8/tl/jaxp: 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Message-ID: <20140128204131.5EC6762825@hg.openjdk.java.net> Changeset: 60c2c003fa11 Author: jeff Date: 2014-01-28 20:09 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/60c2c003fa11 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Reviewed-by: lana ! THIRD_PARTY_README From jeff.dinkins at oracle.com Tue Jan 28 20:41:46 2014 From: jeff.dinkins at oracle.com (jeff.dinkins at oracle.com) Date: Tue, 28 Jan 2014 20:41:46 +0000 Subject: hg: jdk8/tl/jaxws: 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Message-ID: <20140128204148.F3F7962826@hg.openjdk.java.net> Changeset: 2b44c111e153 Author: jeff Date: 2014-01-28 20:09 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/2b44c111e153 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Reviewed-by: lana ! THIRD_PARTY_README From jeff.dinkins at oracle.com Tue Jan 28 20:42:29 2014 From: jeff.dinkins at oracle.com (jeff.dinkins at oracle.com) Date: Tue, 28 Jan 2014 20:42:29 +0000 Subject: hg: jdk8/tl/jdk: 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Message-ID: <20140128204248.3844C62827@hg.openjdk.java.net> Changeset: 72d0cc723560 Author: jeff Date: 2014-01-28 20:10 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/72d0cc723560 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Reviewed-by: lana ! THIRD_PARTY_README From jeff.dinkins at oracle.com Tue Jan 28 20:44:50 2014 From: jeff.dinkins at oracle.com (jeff.dinkins at oracle.com) Date: Tue, 28 Jan 2014 20:44:50 +0000 Subject: hg: jdk8/tl/langtools: 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Message-ID: <20140128204454.0BE4B62828@hg.openjdk.java.net> Changeset: afa91c54ff00 Author: jeff Date: 2014-01-28 20:10 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/afa91c54ff00 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Reviewed-by: lana ! THIRD_PARTY_README From jeff.dinkins at oracle.com Tue Jan 28 20:45:07 2014 From: jeff.dinkins at oracle.com (jeff.dinkins at oracle.com) Date: Tue, 28 Jan 2014 20:45:07 +0000 Subject: hg: jdk8/tl/nashorn: 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Message-ID: <20140128204508.980F662829@hg.openjdk.java.net> Changeset: d3b293a4d554 Author: jeff Date: 2014-01-28 20:10 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d3b293a4d554 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Reviewed-by: lana ! THIRD_PARTY_README From robert.field at oracle.com Tue Jan 28 21:03:07 2014 From: robert.field at oracle.com (robert.field at oracle.com) Date: Tue, 28 Jan 2014 21:03:07 +0000 Subject: hg: jdk8/tl/jdk: 8032711: Issue with Lambda in handling; ... Message-ID: <20140128210319.AFAB66282B@hg.openjdk.java.net> Changeset: c8d9cdc6445c Author: rfield Date: 2014-01-28 13:02 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c8d9cdc6445c 8032711: Issue with Lambda in handling 8032704: Issues with lib perm in Lambda Reviewed-by: jrose, ahgross, briangoetz ! src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java + test/java/lang/invoke/lambda/T8032704.java + test/java/lang/invoke/lambda/T8032711.java From jeff.dinkins at oracle.com Tue Jan 28 20:39:31 2014 From: jeff.dinkins at oracle.com (jeff.dinkins at oracle.com) Date: Tue, 28 Jan 2014 20:39:31 +0000 Subject: hg: jdk8/tl: 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Message-ID: <20140128203931.DC82E62821@hg.openjdk.java.net> Changeset: 4f590c2cec75 Author: jeff Date: 2014-01-28 20:09 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/rev/4f590c2cec75 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Reviewed-by: lana ! THIRD_PARTY_README From robert.field at oracle.com Wed Jan 29 01:25:00 2014 From: robert.field at oracle.com (robert.field at oracle.com) Date: Wed, 29 Jan 2014 01:25:00 +0000 Subject: hg: jdk8/tl/jdk: 8032697: Issues with Lambda Message-ID: <20140129012512.8FE0E62837@hg.openjdk.java.net> Changeset: e385bd6f7338 Author: rfield Date: 2014-01-28 17:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e385bd6f7338 8032697: Issues with Lambda Reviewed-by: ahgross, briangoetz, dlsmith, rfield Contributed-by: daniel.smith at oracle.com ! src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java + test/java/lang/invoke/lambda/T8032697.java + test/java/lang/invoke/lambda/T8032697_anotherpkg/T8032697_A.java From stuart.marks at oracle.com Wed Jan 29 06:51:11 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 28 Jan 2014 22:51:11 -0800 Subject: RFR(s): 8023541 Race condition in rmid initialization Message-ID: <52E8A4DF.4010804@oracle.com> Hi all, Please review this fix to a race condition in rmid initialization. Briefly, rmid subclasses the RMI registry implementation and provides special handling for its own stub. Unfortunately the registry is exported in the super() call, making remote calls possible before rmid's stub initialization is complete. The fix is to ensure that all remote calls wait for initialization before proceeding. Bug: https://bugs.openjdk.java.net/browse/JDK-8023541 Webrev: http://cr.openjdk.java.net/~smarks/reviews/8023541/webrev.0/ Thanks, s'marks From stuart.marks at oracle.com Wed Jan 29 07:16:46 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 28 Jan 2014 23:16:46 -0800 Subject: RFR: JDK-8032050: TEST_BUG: java/rmi/activation/Activatable/shutdownGracefully/ShutdownGracefully.java fails intermittently In-Reply-To: <52E4959C.3020907@oracle.com> References: <52E20974.7060706@oracle.com> <52E31F53.3070702@oracle.com> <52E4959C.3020907@oracle.com> Message-ID: <52E8AADE.6000300@oracle.com> Hi Tristan, I don't want to put the workaround into ActivationLibrary.rmidRunning() for a null return from the lookup, because this is only a workaround for an actual bug in rmid initialization. See the review I just posted for JDK-8023541. Adding JavaVM.waitFor(timeout) is something that would be useful in general, but it needs to be handled carefully. It uses the new Process.waitFor(timeout, unit) which is new in Java SE 8; this makes backporting to 7 more complicated. Not clear whether we'll do so, but I don't want to forclose the opportunity without discussion. It's also not clear how one can get the vm's exit status after JavaVM.waitFor() has returned true. With the Process API it's possible simply to call waitFor() or exitValue(). With JavaVM, a new API needs to be created, or the rule has to be established that one must call JavaVM.waitFor() to collect the exit status as well as to close the pipes from the subprocess. If JavaVM.waitFor(timeout, unit) is called without subsequently calling JavaVM.waitFor(), the pipes are leaked. In ShutdownGracefully.java, the finally-block needs to check to see if rmid is still running, and if it is, to shut it down. Simply calling waitFor(timeout, unit) isn't sufficient, because if the rmid process is still running, it will be left running. The straightforward approach would be to call ActivationLibrary.rmidRunning() to test if it's still running. Unfortunately this isn't quite right, because rmidRunning() has a timeout loop in it -- which should probably be removed. (I think there's a bug for this.) Another approach would be simply to call rmid.destroy(). This calls rmid's shutdown() method first, which is reasonable, but I'm not sure it kills the process if that fails. In any case, this already has a timeout loop waiting for the process to die, so ShutdownGracefully.java needn't use a new waitFor(timeout, unit) call. Removing the commented-out code that starts with "no longer needed" is good, and removing the ShutdownDetectThread is also good, since that's unnecessary. There are some more cleanups I have in mind here but I'd like to see a revised webrev before proceeding. Thanks, s'marks On 1/25/14 8:57 PM, Tristan Yan wrote: > Hi Stuart > Thank you for your review and suggestion. > Yes, since this failure mode is very hard to be reproduced. I guess it's make > sense to do some hack. And I also noticed in ActivationLibrary.rmidRunning. > It does try to look up ActivationSystem but doesn't check if it's null. So I > add the logic to make sure we will look up the non-null ActivationSystem. Also > I did some cleanup if you don't mind. Add a waitFor(long timeout, TimeUnit > unit) for JavaVM. Which we can have a better waitFor control. > I appreciate you can review the code again. > http://cr.openjdk.java.net/~tyan/JDK-8032050/webrev.01/ > Thank you > Tristan > > > On 01/25/2014 10:20 AM, Stuart Marks wrote: >> On 1/23/14 10:34 PM, Tristan Yan wrote: >>> Hi All >>> Could you review the bug fix for JDK-8032050. >>> >>> http://cr.openjdk.java.net/~tyan/JDK-8032050/webrev.00/ >>> >>> Description: >>> This rare happened failure caused because when RMID starts. It don't guarantee >>> sun.rmi.server.Activation.startActivation finishes. >>> Fix by adding a iterative getSystem with a 5 seconds timeout. >> >> Hi Tristan, >> >> Adding a timing/retry loop into this test isn't the correct approach for >> fixing this test. >> >> The timing loop isn't necessary because there is already a timing loop in >> RMID.start() in the RMI test library. (There's another timing loop in >> ActivationLibrary.rmidRunning() which should probably be removed.) So the >> intent of this library call is that it start rmid and wait for it to become >> ready. That logic doesn't need to be added to the test. >> >> In the bug report JDK-8032050 you had mentioned that the NullPointerException >> was suspicious. You're right! I took a look and it seemed like it was related >> to JDK-8023541, and I added a note to this effect to the bug report. The >> problem here is that rmid can come up and transiently return null instead of >> the stub of the activation system. That's what JDK-8023541 covers. I think >> that rmid itself needs to be fixed, though modifying the timing loop in the >> RMI test library to wait for rmid to come up *and* for the lookup to return >> non-null is an easy way to fix the problem. (Or at least cover it up.) >> >> The next step in the analysis is to determine, given that >> ActivationLibrary.getSystem can sometimes return null, whether this has >> actually caused this test failure. This is pretty easy to determine; just >> hack in a line "system = null" in the right place and run the test. I've done >> this, and the test times out and the output log is pretty much identical to >> the one in the bug report. (I recommend you try this yourself.) So I think >> it's fairly safe to say that the problem in JDK-8023541 has caused the >> failure listed in JDK-8032050. >> >> I can see a couple ways to proceed here. One way is just to close this out as >> a duplicate of JDK-8023541 since that bug caused this failure. >> >> Another is that this test could use some cleaning up. This bug certainly >> covers a failure, but the messages emitted are confusing and in some cases >> completely wrong. For example, the "rmid has shutdown" message at line 180 is >> incorrect, because in this case rmid is still running and the wait() call has >> timed out. Most of the code here can be replaced with calls to various bits >> of the RMI test library. There are a bunch of other things in this test that >> could be cleaned up as well. >> >> It's up to you how you'd like to proceed. >> >> s'marks > From tristan.yan at oracle.com Wed Jan 29 07:23:13 2014 From: tristan.yan at oracle.com (Tristan Yan) Date: Wed, 29 Jan 2014 15:23:13 +0800 Subject: RFR(s): 8023541 Race condition in rmid initialization In-Reply-To: <52E8A4DF.4010804@oracle.com> References: <52E8A4DF.4010804@oracle.com> Message-ID: <3957301B-49C4-4123-A39D-11E4770C3817@oracle.com> Hi Stuart Should variable initialized be volatile here? Otherwise looks good. Thank you Tristan On Jan 29, 2014, at 2:51 PM, Stuart Marks wrote: > Hi all, > > Please review this fix to a race condition in rmid initialization. Briefly, rmid subclasses the RMI registry implementation and provides special handling for its own stub. Unfortunately the registry is exported in the super() call, making remote calls possible before rmid's stub initialization is complete. The fix is to ensure that all remote calls wait for initialization before proceeding. > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8023541 > > Webrev: > > http://cr.openjdk.java.net/~smarks/reviews/8023541/webrev.0/ > > Thanks, > > s'marks From david.holmes at oracle.com Wed Jan 29 09:05:13 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 Jan 2014 19:05:13 +1000 Subject: RFR(s): 8023541 Race condition in rmid initialization In-Reply-To: <52E8A4DF.4010804@oracle.com> References: <52E8A4DF.4010804@oracle.com> Message-ID: <52E8C449.3020000@oracle.com> Hi Stuart, This looks fine to me. Tristan: the initialized field is only accessed under synchronization so does not need to be volatile. Cheers, David On 29/01/2014 4:51 PM, Stuart Marks wrote: > Hi all, > > Please review this fix to a race condition in rmid initialization. > Briefly, rmid subclasses the RMI registry implementation and provides > special handling for its own stub. Unfortunately the registry is > exported in the super() call, making remote calls possible before rmid's > stub initialization is complete. The fix is to ensure that all remote > calls wait for initialization before proceeding. > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8023541 > > Webrev: > > http://cr.openjdk.java.net/~smarks/reviews/8023541/webrev.0/ > > Thanks, > > s'marks From Alan.Bateman at oracle.com Wed Jan 29 09:29:26 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 29 Jan 2014 09:29:26 +0000 Subject: RFR(s): 8023541 Race condition in rmid initialization In-Reply-To: <52E8A4DF.4010804@oracle.com> References: <52E8A4DF.4010804@oracle.com> Message-ID: <52E8C9F6.10905@oracle.com> On 29/01/2014 06:51, Stuart Marks wrote: > Hi all, > > Please review this fix to a race condition in rmid initialization. > Briefly, rmid subclasses the RMI registry implementation and provides > special handling for its own stub. Unfortunately the registry is > exported in the super() call, making remote calls possible before > rmid's stub initialization is complete. The fix is to ensure that all > remote calls wait for initialization before proceeding. > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8023541 > > Webrev: > > http://cr.openjdk.java.net/~smarks/reviews/8023541/webrev.0/ > This looks okay as an initial fix but I just wonder about every bind and lookup now needing to synchronize in order to check if has initialized. I don't know the full background to this one and maybe you have experimented with other solutions. I just wonder if you could change initialized to volatile and only synchronize/wait when false? That way you would only be adding a read of a volatile. I assume the stub can never be null so maybe it could be changed to volatile and only wait if null (the initialized flag could go away then). One other comment (assuming the current approach goes ahead) is that you could change lookup, bind, unbind so that they only await when the name is not ActivationSystem. Also list doesn't appear to need the stub so maybe the await is not needed there. -Alan. From paul.sandoz at oracle.com Wed Jan 29 10:04:40 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 29 Jan 2014 11:04:40 +0100 Subject: RFR(s): 8023541 Race condition in rmid initialization In-Reply-To: <52E8C9F6.10905@oracle.com> References: <52E8A4DF.4010804@oracle.com> <52E8C9F6.10905@oracle.com> Message-ID: <000FCE6A-376E-4CBC-A63B-9D11B99DD387@oracle.com> On Jan 29, 2014, at 10:29 AM, Alan Bateman wrote: > I just wonder if you could change initialized to volatile and only synchronize/wait when false? That way you would only be adding a read of a volatile. I assume the stub can never be null so maybe it could be changed to volatile and only wait if null (the initialized flag could go away then). > I was wondering the same thing. > One other comment (assuming the current approach goes ahead) is that you could change lookup, bind, unbind so that they only await when the name is not ActivationSystem. Also list doesn't appear to need the stub so maybe the await is not needed there. > This is rather mysterious. The only direct reference to systemStub is in lookup if name.equals(NAME) and the bind/unbind/rebind all barf on that condition, does either the throwing of the exception to the call to the super method result in a call to lookup(NAME) ? Paul. From peter.levart at gmail.com Wed Jan 29 10:22:12 2014 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 29 Jan 2014 11:22:12 +0100 Subject: RFR(s): 8023541 Race condition in rmid initialization In-Reply-To: <52E8A4DF.4010804@oracle.com> References: <52E8A4DF.4010804@oracle.com> Message-ID: <52E8D654.4010103@gmail.com> Hi Stuart, My eye was caught by the following new method: 328 private synchronized void awaitInitialized() { 329 try { 330 while (!initialized) { 331 wait(); 332 } 333 } catch (InterruptedException ie) { 334 Thread.currentThread().interrupt(); 335 } 336 } ...if the thread calling this method is interrupted while waiting, it will set the interrupted status of the thread back, but will terminate the waiting loop. So the initialization race is still possible. Why not wait until initialized like: boolean interrupted = false; while (!initialized) { try { wait(); } catch (InterruptedException ie) { interrupted = true; } } if (interrupted) { Thread.currentThread().interrupt(); } Regards, Peter boolean interrupted = false; On 01/29/2014 07:51 AM, Stuart Marks wrote: > Hi all, > > Please review this fix to a race condition in rmid initialization. > Briefly, rmid subclasses the RMI registry implementation and provides > special handling for its own stub. Unfortunately the registry is > exported in the super() call, making remote calls possible before > rmid's stub initialization is complete. The fix is to ensure that all > remote calls wait for initialization before proceeding. > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8023541 > > Webrev: > > http://cr.openjdk.java.net/~smarks/reviews/8023541/webrev.0/ > > Thanks, > > s'marks From peter.levart at gmail.com Wed Jan 29 13:09:45 2014 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 29 Jan 2014 14:09:45 +0100 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52E7D0DD.5030507@oracle.com> References: <52B3568B.5050905@oracle.com> <52CF37C6.1070605@oracle.com> <52CFAFEB.9090703@gmail.com> <52CFD218.2060101@gmail.com> <52D06B70.60001@oracle.com> <52D15201.90109@gmail.com> <52D47D59.8040905@oracle.com> <52D72577.1050506@oracle.com> <52D76859.2030502@oracle.com> <52D82968.4030608@oracle.com> <52D8929B.2020905@oracle.com> <52D8A42A.4020906@oracle.com> <52D8B3B6.3030202@oracle.com> <52D9295D.6080106@gmail.com> <52D92C73.2020309@gmail.com> <52D92F1A.4040400@gmail.com> <52DC812C.1000607@oracle.com> <52DCD78E.8050404@gmail.com> <52DCE17B.4050708@gmail.com> <52DDD9F3.1050201@oracle.com> <52DE19C1.2070302@gmail.com> <52DE9147.4030305@gmail.com> <52DEB9C4.4030606@oracle.com> <52DEF53C.3050905@gmail.com> <52E1772A.1050608@oracle.com> <52E1B4C5.8050807@oracle.com> <52E1C7AD.8090100@oracle.com> <52E2FFE2.7000600@gmail.com> <52E33F11.8000804@oracle.com> <52E55CF7.6050400@gmail.com> <52E7134E.9070606@oracle.com> <52E76DE5.1000300@gmail.com> <52E7D0DD.5030507@oracle.com> Message-ID: <52E8FD99.2050901@gmail.com> On 01/28/2014 04:46 PM, Alan Bateman wrote: > On 28/01/2014 08:44, Peter Levart wrote: >> >> Yes, I tried that too and it results in even more unsafe casts. >> >> It's odd yes, since the compile-time error is not present when >> building via OpenJDK build system make files (using "make images" in >> top directory for example) but only if I compile the class from >> command line (using javac directly) or from IDEA. I use JDK 8 ea-b121 >> in all cases as a build JDK. Are there any special options passed to >> javac for compiling those classes in JDK build system that allow such >> code? >> > jdk/make/Setup.gmk has the -Xlint options that are used in the build > but I suspect it more than that all the classes in java/lang/ref are > compiled together. > > -Alan That's right. If I add the source for ReferenceQueue.java into a directory where Reference.java resides and then compile with: javac -d /tmp Reference.java ...then Reference as well as ReferenceQueue gets compiled and there's no error. If there is sole Reference.java in the directory, a compile time error is emitted. I checked the source of ReferenceQueue.java in JDK 8 ea-b121 (the JDK used for compiling) and it only differs in copyright year from the source in jdk9-dev. So there seems to be inconsistency in javac's handling of types that are read from .class vs. .java files. I'll try to create a reproducer example and post it to compiler-dev. Since I don't know what should be the correct behaviour of javac, I can leave the Reference.java changes as proposed since it compiles in both cases. Or should I revert the change to declaration of local variable 'q' ? Regards, Peter From volker.simonis at gmail.com Wed Jan 29 17:59:27 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 29 Jan 2014 18:59:27 +0100 Subject: RFR(S): 8033154: PPC64: Fix AIX build after integration into jdk9/dev Message-ID: Hi, please review the following small change: http://cr.openjdk.java.net/~simonis/webrevs/8033154/ which fixes the AIX build after the integration of ppc-aix-port/stage-9/jdk to jdk9/dev/jdk. I would ideally like to push this change to jdk9/hs-comp/jdk because that's the only repository where there's currently a complete AIX port. However if that is not possible, I'll push it to jdk9/dev/jdk and wait until it gets synced with jdk9/hs-comp again. Please notice that this change is also intended for downport into 8u, but I don't expect this to be a problem because it only contains AIX-specific coding. The main problem with the integration was caused by change "8032451: (dc) DatagramChannel.join should support include-mode filtering on OS X" which was already in jdk9/dev/jdk but not in ppc-aix-port/stage-9/jdk. It caused some issues which will be solved with this change: make/lib/NioLibraries.gmk src/aix/native/sun/nio/ch/AixNativeThread.c 8032451 did some changes to NativeThread.c. Instead of adding another platform specific section to that file I've moved the AIX implementation to it's own file which will only be used during the AIX port. Notice that the changes in the makefile are in a AIX-specific section and won't affect any other platform. src/solaris/native/sun/nio/ch/Net.c 8032451 removed some specific coding which was used by AIX as well. To re-enable the build on AIX 5.3 we have to define the two structures 'ip_mreq_source' and 'group_source_req' on that platform. src/solaris/classes/sun/net/PortConfig.java This is another file which wasn't present in our stage-9/jdk repository but in the new jdk9/dev/jdk. Just added the required, AIX-specific section to the file. src/share/lib/security/java.security-aix Recent changes have updated the various src/share/lib/security/java.security* files. Without these changes, the JDK failes to pass the java/lang/SecurityManager/CheckPackageAccess.java jtreg regression test. I've just updated java.security-aix to be the same like the corresponding Linux version (as this was done - and agreed upon that it is OK - in the initial AIX change). Regards, Volker From vladimir.kozlov at oracle.com Wed Jan 29 18:10:11 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 29 Jan 2014 10:10:11 -0800 Subject: RFR(S): 8033154: PPC64: Fix AIX build after integration into jdk9/dev In-Reply-To: References: Message-ID: <52E94403.60704@oracle.com> On 1/29/14 9:59 AM, Volker Simonis wrote: > Hi, > > please review the following small change: > > http://cr.openjdk.java.net/~simonis/webrevs/8033154/ > > which fixes the AIX build after the integration of > ppc-aix-port/stage-9/jdk to jdk9/dev/jdk. > > I would ideally like to push this change to jdk9/hs-comp/jdk because > that's the only repository where there's currently a complete AIX > port. However if that is not possible, I'll push it to jdk9/dev/jdk > and wait until it gets synced with jdk9/hs-comp again. I don't see a problem to push into jdk9/hs-comp/jdk. It is even better for me since I have to prepare new control builds of whole forest for testing and I can get sources for that from one place. The only reason to push fix into jdk9/dev/jdk if something breaks builds on our platforms, I think. You can pushed into jdk9/hs-comp/jdk after reviews. Thanks, Vladimir > > Please notice that this change is also intended for downport into 8u, > but I don't expect this to be a problem because it only contains > AIX-specific coding. > > The main problem with the integration was caused by change "8032451: > (dc) DatagramChannel.join should support include-mode filtering on OS > X" which was already in jdk9/dev/jdk but not in > ppc-aix-port/stage-9/jdk. It caused some issues which will be solved > with this change: > > > make/lib/NioLibraries.gmk > src/aix/native/sun/nio/ch/AixNativeThread.c > > 8032451 did some changes to NativeThread.c. Instead of adding another > platform specific section to that file I've moved the AIX > implementation to it's own file which will only be used during the AIX > port. Notice that the changes in the makefile are in a AIX-specific > section and won't affect any other platform. > > > src/solaris/native/sun/nio/ch/Net.c > > 8032451 removed some specific coding which was used by AIX as well. To > re-enable the build on AIX 5.3 we have to define the two structures > 'ip_mreq_source' and 'group_source_req' on that platform. > > > src/solaris/classes/sun/net/PortConfig.java > > This is another file which wasn't present in our stage-9/jdk > repository but in the new jdk9/dev/jdk. Just added the required, > AIX-specific section to the file. > > > src/share/lib/security/java.security-aix > > Recent changes have updated the various > src/share/lib/security/java.security* files. Without these changes, > the JDK failes to pass the > java/lang/SecurityManager/CheckPackageAccess.java jtreg regression > test. I've just updated java.security-aix to be the same like the > corresponding Linux version (as this was done - and agreed upon that > it is OK - in the initial AIX change). > > Regards, > Volker > From mandy.chung at oracle.com Wed Jan 29 19:10:10 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 29 Jan 2014 11:10:10 -0800 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52E8FD99.2050901@gmail.com> References: <52B3568B.5050905@oracle.com> <52CFAFEB.9090703@gmail.com> <52CFD218.2060101@gmail.com> <52D06B70.60001@oracle.com> <52D15201.90109@gmail.com> <52D47D59.8040905@oracle.com> <52D72577.1050506@oracle.com> <52D76859.2030502@oracle.com> <52D82968.4030608@oracle.com> <52D8929B.2020905@oracle.com> <52D8A42A.4020906@oracle.com> <52D8B3B6.3030202@oracle.com> <52D9295D.6080106@gmail.com> <52D92C73.2020309@gmail.com> <52D92F1A.4040400@gmail.com> <52DC812C.1000607@oracle.com> <52DCD78E.8050404@gmail.com> <52DCE17B.4050708@gmail.com> <52DDD9F3.1050201@oracle.com> <52DE19C1.2070302@gmail.com> <52DE9147.4030305@gmail.com> <52DEB9C4.4030606@oracle.com> <52DEF53C.3050905@gmail.com> <52E1772A.1050608@oracle.com> <52E1B4C5.8050807@oracle.com> <52E1C7AD.8090100@oracle.com> <52E2FFE2.7000600@gmail.com> <52E33F11.8000804@oracle.com> <52E55CF7.6050400@gmail.com> <52E7134E.9070606@oracle.com> <52E76DE5.1000300@gmail.com> <52E7D0DD.5030507@oracle.com> <52E8FD99.2050901@gmail.com> Message-ID: <52E95212.3040803@oracle.com> On 1/29/2014 5:09 AM, Peter Levart wrote: > > Since I don't know what should be the correct behaviour of javac, I > can leave the Reference.java changes as proposed since it compiles in > both cases. Or should I revert the change to declaration of local > variable 'q' ? I slightly prefer to revert the change to ReferenceQueue for now as there is no supertype for Object and this looks a little odd. We can clean this up as a separate fix after we get clarification from compiler-dev. Mandy From Alan.Bateman at oracle.com Wed Jan 29 19:32:19 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 29 Jan 2014 19:32:19 +0000 Subject: RFR(S): 8033154: PPC64: Fix AIX build after integration into jdk9/dev In-Reply-To: References: Message-ID: <52E95743.7050708@oracle.com> On 29/01/2014 17:59, Volker Simonis wrote: > Hi, > > please review the following small change: > > http://cr.openjdk.java.net/~simonis/webrevs/8033154/ > > which fixes the AIX build after the integration of > ppc-aix-port/stage-9/jdk to jdk9/dev/jdk. > > I would ideally like to push this change to jdk9/hs-comp/jdk because > that's the only repository where there's currently a complete AIX > port. However if that is not possible, I'll push it to jdk9/dev/jdk > and wait until it gets synced with jdk9/hs-comp again. > The changes look okay to me. An alternative to introducing AixNativeThread.c would be to just put an ifdef AIX in NativeThread.c to defined INTERRUPT_SIGNAL. I don't see any issue with this being pushed to jdk9/hs-comp. -Alan From sean.mullan at oracle.com Wed Jan 29 19:52:08 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 29 Jan 2014 14:52:08 -0500 Subject: RFR(S): 8033154: PPC64: Fix AIX build after integration into jdk9/dev In-Reply-To: References: Message-ID: <52E95BE8.1020806@oracle.com> The java.security-aix file looks fine to me. --Sean On 01/29/2014 12:59 PM, Volker Simonis wrote: > Hi, > > please review the following small change: > > http://cr.openjdk.java.net/~simonis/webrevs/8033154/ > > which fixes the AIX build after the integration of > ppc-aix-port/stage-9/jdk to jdk9/dev/jdk. > > I would ideally like to push this change to jdk9/hs-comp/jdk because > that's the only repository where there's currently a complete AIX > port. However if that is not possible, I'll push it to jdk9/dev/jdk > and wait until it gets synced with jdk9/hs-comp again. > > Please notice that this change is also intended for downport into 8u, > but I don't expect this to be a problem because it only contains > AIX-specific coding. > > The main problem with the integration was caused by change "8032451: > (dc) DatagramChannel.join should support include-mode filtering on OS > X" which was already in jdk9/dev/jdk but not in > ppc-aix-port/stage-9/jdk. It caused some issues which will be solved > with this change: > > > make/lib/NioLibraries.gmk > src/aix/native/sun/nio/ch/AixNativeThread.c > > 8032451 did some changes to NativeThread.c. Instead of adding another > platform specific section to that file I've moved the AIX > implementation to it's own file which will only be used during the AIX > port. Notice that the changes in the makefile are in a AIX-specific > section and won't affect any other platform. > > > src/solaris/native/sun/nio/ch/Net.c > > 8032451 removed some specific coding which was used by AIX as well. To > re-enable the build on AIX 5.3 we have to define the two structures > 'ip_mreq_source' and 'group_source_req' on that platform. > > > src/solaris/classes/sun/net/PortConfig.java > > This is another file which wasn't present in our stage-9/jdk > repository but in the new jdk9/dev/jdk. Just added the required, > AIX-specific section to the file. > > > src/share/lib/security/java.security-aix > > Recent changes have updated the various > src/share/lib/security/java.security* files. Without these changes, > the JDK failes to pass the > java/lang/SecurityManager/CheckPackageAccess.java jtreg regression > test. I've just updated java.security-aix to be the same like the > corresponding Linux version (as this was done - and agreed upon that > it is OK - in the initial AIX change). > > Regards, > Volker > From aleksej.efimov at oracle.com Wed Jan 29 20:31:21 2014 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Thu, 30 Jan 2014 00:31:21 +0400 Subject: RFR: 8030822: (tz) Support tzdata2013i In-Reply-To: <52E09DE9.20300@oracle.com> References: <52DE737E.2030200@oracle.com> <52E09DE9.20300@oracle.com> Message-ID: <52E96519.6020006@oracle.com> Masayoshi, Sean, Thank you for the review and your comments. I have prepared a second version of the fix [1] without the .properties files. These files are used in test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNamesTest.java test and because of that this test was removed also. Thank you, Aleksej [1] http://cr.openjdk.java.net/~aefimov/8030822/9/webrev.01/ On 01/23/2014 08:43 AM, Masayoshi Okutsu wrote: > Hi Aleksej, > > I think this one is the first tzdata change for JDK9. So I'd suggest > that all the TimeZoneNames*.properties files, which were temporarily > created for the translation work, be removed. > > Thanks, > Masayoshi > > On 1/21/2014 10:17 PM, Aleksej Efimov wrote: >> Hi, >> Can I have a review for 2013i timezone data integration [1] to JDK9. >> There is one change in tzdb that affects naming for "Asia/Amman" >> timezone: >> "The Jordan switches back to standard time at 00:00 on December >> 20, 2013." >> All changes in TimeZoneNames*.java and TimeZoneNames*.properties >> files are related to this one tzdb change. >> >> The list of executed regression test sets: test/sun/util/calendar >> test/java/util/Calendar test/sun/util/resources/TimeZone >> test/sun/util/calendar test/java/util/TimeZone test/java/time >> test/java/util/Formatter test/closed/java/util/Calendar >> test/closed/java/util/TimeZone >> All tests gave PASS result. >> >> Webrev location: >> http://cr.openjdk.java.net/~aefimov/8030822/9/webrev.00/ >> >> Thank you, >> Aleksej >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8030822 > From Miroslaw.Niemiec at Oracle.COM Thu Jan 30 02:34:03 2014 From: Miroslaw.Niemiec at Oracle.COM (Miroslaw Niemiec) Date: Wed, 29 Jan 2014 18:34:03 -0800 Subject: [8011944] Sort fails with ArrayIndexOutOfBoundsException In-Reply-To: <52E23359.3050705@oracle.com> References: <52E19DD0.7020001@Oracle.COM> <52E23359.3050705@oracle.com> Message-ID: <52E9BA1B.8000706@Oracle.COM> On 1/24/2014 1:33 AM, Alan Bateman wrote: > On 23/01/2014 22:55, Miroslaw Niemiec wrote: >> Hello! >> >> This is a simple backport from 8 to 7. >> Looking for a review of this even though it only requires a testcase >> change due to the use of lambda expressions. >> Since this is the first of these I've encountered I thought I better >> play it safe, but generally speaking, are we ok >> to skip the review process for backports like this? (minor lambda >> related testcase changes - if the lambda's are in the actual fix it >> probably makes sense to re-review). > It often happens that "small adjustments" are required when > back-porting. To date then it's been a mix of just highlighting in the > approval request to jdk7u-dev, sometimes the mailing list where the > issue was originally reviewed is included. It's really just a > judgement call as sometimes the adjustments are trivial, sometimes a > bit more. The jdk7u maintainers are good about asking for additional > review where it might be needed. > > For cases like this one then it's best to start with the test pushed > to the jdk8 forest and then just replace the use of new language > features so that it compiles/runs on jdk7u. In this this case it seems > okay, just make sure (as others have pointed out) not to remove the > copyright header. > > -Alan. The copyright header added to test/java/util/Arrays/TimSortStackSize.java: http://cr.openjdk.java.net/~miroslawzn/8011944/webrev.02/ - Miroslaw From stuart.marks at oracle.com Thu Jan 30 02:57:23 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 29 Jan 2014 18:57:23 -0800 Subject: RFR(s): 8023541 Race condition in rmid initialization In-Reply-To: <52E8D654.4010103@gmail.com> References: <52E8A4DF.4010804@oracle.com> <52E8D654.4010103@gmail.com> Message-ID: <52E9BF93.5040200@oracle.com> Hi all, wow, lots of comments on this. Let me see if I can tackle them in one message. Quick aside before I get to the issues: my priorities for this code are correctness and maintainability, possibly at the expense of performance. In other words I'm willing to make the code more complex so that it's correct, but I'm less willing to make it more complex in order to make it go faster. (Tristan, David) Making 'initialized' be volatile. As things stand, as David has pointed out (thanks!) it's not necessary for it to be volatile. There are other circumstances (see below) where it would be necessary to make it volatile, though. (Alan, Paul) We could convert to double-checked locking and avoid a synchronization in the common case, paying only a volatile read. Something like, volatile boolean initialized = false; ... private void awaitInitialized() { if (!initialized) { synchronized (this) { try { while (!initialized) { wait(); } catch (InterruptedException ie) { Thread.currentThread().interrupt(); } } } } I *think* that's right. (Is it?) I don't know whether this performs any better, or if it does, whether it's worth the additional complexity. I had to squint at this for a while to convince myself it's correct. I am fairly sure this is not a performance-critical area of code. (Famous last words, I know.) The other threads that can be active here are handling remote calls, so they're already doing network I/O, unmarshalling, and dispatching to the RMI thread pool. Compared to this, the incremental cost of a synchronization block seems inconsequential. I don't have much intuition about how much we'd save by substituting a volatile read for a full synchronization in the common case, but given that this is within the context of a fairly expensive operation, it doesn't seem like it's worth it to me. (Alan, Paul) Calling awaitInitialized isn't strictly necessary anywhere except for the equals(NAME) case of lookup(). Yes, that's right. I added it everywhere because of a possibly misguided sense of completeness and consistency. One could essentially redefine awaitInitialized() to protect just the systemStub field, not the "entire" object, whose only state is that field anyway. Also, see below regarding renaming this method. (Alan) Use systemStub == null as the condition instead of !initialized. I considered at first this but it got confusing really fast. Take a look: private final ActivationSystem systemStub; SystemRegistryImpl(..., systemStub) { ... this.systemStub = systemStub; notifyAll(); ... } private synchronized void awaitInitialized() { ... while (systemStub == null) { wait(); } ... } We rely on systemStub to be initialized at object creation time (before construction!) to its default value of null. I think this is right. The constructor then initializes the blank final to non-null and notifies. Then, awaitInitialized seems straightforward until you see that the condition is waiting for the value of a final variable to change! JLS sec 17.5 [1] allows all sorts of optimizations for final fields, but they all are qualified with what is essentially a safe publication requirement on the reference: An object is considered to be completely initialized when its constructor finishes. A thread that can only see a reference to an object after that object has been completely initialized is guaranteed to see the correctly initialized values for that object's final fields. [1] http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.5 Unfortunately this code *unsafely* publishes a reference to 'this' which is the root of this whole problem. Under these circumstances I'd prefer to be really conservative about the code here. I can't quite convince myself that a condition loop waiting for a final field to change value is safe. That's why I added a separate field. I can see removing the boolean and using systemStub == null as the condition making things simpler, since there are fewer variables to reason about, but only if systemStub is made non-final. Making it non-final prevents any unwanted optimizations resulting from it being final. Having it be final doesn't add much anyway. I'll also move all accesses to systemStub within synchronized blocks so there is no question about visibility. (As a result, awaitInitialized now gets turned into getSystemStub.) (Peter) Should the interrupt break out of the loop even though the condition isn't satisfied? This is a good point. Usually I think of interrupt as wanting to avoid waiting indefinitely for the condition to become true (which is the point of supporting interruption) but in this case the condition will always occur in a timely fashion. So I'll accept the suggestion to save the interrupt state and let the condition loop terminate. Updated webrev here: http://cr.openjdk.java.net/~smarks/reviews/8023541/webrev.1/ Thanks, s'marks From david.holmes at oracle.com Thu Jan 30 03:24:31 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 30 Jan 2014 13:24:31 +1000 Subject: RFR(s): 8023541 Race condition in rmid initialization In-Reply-To: <52E9BF93.5040200@oracle.com> References: <52E8A4DF.4010804@oracle.com> <52E8D654.4010103@gmail.com> <52E9BF93.5040200@oracle.com> Message-ID: <52E9C5EF.3090903@oracle.com> This simpler form, with the interruption logic corrected, seems fine to me. David On 30/01/2014 12:57 PM, Stuart Marks wrote: > Hi all, wow, lots of comments on this. Let me see if I can tackle them > in one message. > > Quick aside before I get to the issues: my priorities for this code are > correctness and maintainability, possibly at the expense of performance. > In other words I'm willing to make the code more complex so that it's > correct, but I'm less willing to make it more complex in order to make > it go faster. > > (Tristan, David) Making 'initialized' be volatile. As things stand, as > David has pointed out (thanks!) it's not necessary for it to be > volatile. There are other circumstances (see below) where it would be > necessary to make it volatile, though. > > (Alan, Paul) We could convert to double-checked locking and avoid a > synchronization in the common case, paying only a volatile read. > Something like, > > volatile boolean initialized = false; > ... > private void awaitInitialized() { > if (!initialized) { > synchronized (this) { > try { > while (!initialized) { > wait(); > } catch (InterruptedException ie) { > Thread.currentThread().interrupt(); > } > } > } > } > > I *think* that's right. (Is it?) I don't know whether this performs any > better, or if it does, whether it's worth the additional complexity. I > had to squint at this for a while to convince myself it's correct. > > I am fairly sure this is not a performance-critical area of code. > (Famous last words, I know.) The other threads that can be active here > are handling remote calls, so they're already doing network I/O, > unmarshalling, and dispatching to the RMI thread pool. Compared to this, > the incremental cost of a synchronization block seems inconsequential. I > don't have much intuition about how much we'd save by substituting a > volatile read for a full synchronization in the common case, but given > that this is within the context of a fairly expensive operation, it > doesn't seem like it's worth it to me. > > (Alan, Paul) Calling awaitInitialized isn't strictly necessary anywhere > except for the equals(NAME) case of lookup(). Yes, that's right. I added > it everywhere because of a possibly misguided sense of completeness and > consistency. One could essentially redefine awaitInitialized() to > protect just the systemStub field, not the "entire" object, whose only > state is that field anyway. Also, see below regarding renaming this method. > > (Alan) Use systemStub == null as the condition instead of !initialized. > I considered at first this but it got confusing really fast. Take a look: > > private final ActivationSystem systemStub; > > SystemRegistryImpl(..., systemStub) { > ... > this.systemStub = systemStub; > notifyAll(); > ... > } > > private synchronized void awaitInitialized() { > ... > while (systemStub == null) { > wait(); > } > ... > } > > We rely on systemStub to be initialized at object creation time (before > construction!) to its default value of null. I think this is right. The > constructor then initializes the blank final to non-null and notifies. > > Then, awaitInitialized seems straightforward until you see that the > condition is waiting for the value of a final variable to change! JLS > sec 17.5 [1] allows all sorts of optimizations for final fields, but > they all are qualified with what is essentially a safe publication > requirement on the reference: > > An object is considered to be completely initialized when its > constructor > finishes. A thread that can only see a reference to an object after > that > object has been completely initialized is guaranteed to see the > correctly > initialized values for that object's final fields. > > [1] http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.5 > > Unfortunately this code *unsafely* publishes a reference to 'this' which > is the root of this whole problem. Under these circumstances I'd prefer > to be really conservative about the code here. I can't quite convince > myself that a condition loop waiting for a final field to change value > is safe. That's why I added a separate field. > > I can see removing the boolean and using systemStub == null as the > condition making things simpler, since there are fewer variables to > reason about, but only if systemStub is made non-final. Making it > non-final prevents any unwanted optimizations resulting from it being > final. Having it be final doesn't add much anyway. I'll also move all > accesses to systemStub within synchronized blocks so there is no > question about visibility. (As a result, awaitInitialized now gets > turned into getSystemStub.) > > (Peter) Should the interrupt break out of the loop even though the > condition isn't satisfied? This is a good point. Usually I think of > interrupt as wanting to avoid waiting indefinitely for the condition to > become true (which is the point of supporting interruption) but in this > case the condition will always occur in a timely fashion. So I'll accept > the suggestion to save the interrupt state and let the condition loop > terminate. > > Updated webrev here: > > http://cr.openjdk.java.net/~smarks/reviews/8023541/webrev.1/ > > Thanks, > > s'marks From tristan.yan at oracle.com Thu Jan 30 04:50:07 2014 From: tristan.yan at oracle.com (Tristan Yan) Date: Thu, 30 Jan 2014 12:50:07 +0800 Subject: RFR(s): 8023541 Race condition in rmid initialization In-Reply-To: <52E9BF93.5040200@oracle.com> References: <52E8A4DF.4010804@oracle.com> <52E8D654.4010103@gmail.com> <52E9BF93.5040200@oracle.com> Message-ID: <4D7464F4-27AB-4B91-B986-2C4A13C8EDB3@oracle.com> Hi Stuart Looks like in you new webrev. The wait will continue to go loop until systemStub is not null. If it?s what you meant to do that? Thank you Tristan On Jan 30, 2014, at 10:57 AM, Stuart Marks wrote: > Hi all, wow, lots of comments on this. Let me see if I can tackle them in one message. > > Quick aside before I get to the issues: my priorities for this code are correctness and maintainability, possibly at the expense of performance. In other words I'm willing to make the code more complex so that it's correct, but I'm less willing to make it more complex in order to make it go faster. > > (Tristan, David) Making 'initialized' be volatile. As things stand, as David has pointed out (thanks!) it's not necessary for it to be volatile. There are other circumstances (see below) where it would be necessary to make it volatile, though. > > (Alan, Paul) We could convert to double-checked locking and avoid a synchronization in the common case, paying only a volatile read. Something like, > > volatile boolean initialized = false; > ... > private void awaitInitialized() { > if (!initialized) { > synchronized (this) { > try { > while (!initialized) { > wait(); > } catch (InterruptedException ie) { > Thread.currentThread().interrupt(); > } > } > } > } > > I *think* that's right. (Is it?) I don't know whether this performs any better, or if it does, whether it's worth the additional complexity. I had to squint at this for a while to convince myself it's correct. > > I am fairly sure this is not a performance-critical area of code. (Famous last words, I know.) The other threads that can be active here are handling remote calls, so they're already doing network I/O, unmarshalling, and dispatching to the RMI thread pool. Compared to this, the incremental cost of a synchronization block seems inconsequential. I don't have much intuition about how much we'd save by substituting a volatile read for a full synchronization in the common case, but given that this is within the context of a fairly expensive operation, it doesn't seem like it's worth it to me. > > (Alan, Paul) Calling awaitInitialized isn't strictly necessary anywhere except for the equals(NAME) case of lookup(). Yes, that's right. I added it everywhere because of a possibly misguided sense of completeness and consistency. One could essentially redefine awaitInitialized() to protect just the systemStub field, not the "entire" object, whose only state is that field anyway. Also, see below regarding renaming this method. > > (Alan) Use systemStub == null as the condition instead of !initialized. I considered at first this but it got confusing really fast. Take a look: > > private final ActivationSystem systemStub; > > SystemRegistryImpl(..., systemStub) { > ... > this.systemStub = systemStub; > notifyAll(); > ... > } > > private synchronized void awaitInitialized() { > ... > while (systemStub == null) { > wait(); > } > ... > } > > We rely on systemStub to be initialized at object creation time (before construction!) to its default value of null. I think this is right. The constructor then initializes the blank final to non-null and notifies. > > Then, awaitInitialized seems straightforward until you see that the condition is waiting for the value of a final variable to change! JLS sec 17.5 [1] allows all sorts of optimizations for final fields, but they all are qualified with what is essentially a safe publication requirement on the reference: > > An object is considered to be completely initialized when its constructor > finishes. A thread that can only see a reference to an object after that > object has been completely initialized is guaranteed to see the correctly > initialized values for that object's final fields. > > [1] http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.5 > > Unfortunately this code *unsafely* publishes a reference to 'this' which is the root of this whole problem. Under these circumstances I'd prefer to be really conservative about the code here. I can't quite convince myself that a condition loop waiting for a final field to change value is safe. That's why I added a separate field. > > I can see removing the boolean and using systemStub == null as the condition making things simpler, since there are fewer variables to reason about, but only if systemStub is made non-final. Making it non-final prevents any unwanted optimizations resulting from it being final. Having it be final doesn't add much anyway. I'll also move all accesses to systemStub within synchronized blocks so there is no question about visibility. (As a result, awaitInitialized now gets turned into getSystemStub.) > > (Peter) Should the interrupt break out of the loop even though the condition isn't satisfied? This is a good point. Usually I think of interrupt as wanting to avoid waiting indefinitely for the condition to become true (which is the point of supporting interruption) but in this case the condition will always occur in a timely fashion. So I'll accept the suggestion to save the interrupt state and let the condition loop terminate. > > Updated webrev here: > > http://cr.openjdk.java.net/~smarks/reviews/8023541/webrev.1/ > > Thanks, > > s'marks From masayoshi.okutsu at oracle.com Thu Jan 30 06:14:51 2014 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Thu, 30 Jan 2014 15:14:51 +0900 Subject: RFR: 8030822: (tz) Support tzdata2013i In-Reply-To: <52E96519.6020006@oracle.com> References: <52DE737E.2030200@oracle.com> <52E09DE9.20300@oracle.com> <52E96519.6020006@oracle.com> Message-ID: <52E9EDDB.4050709@oracle.com> Looks good. Masayoshi On 1/30/2014 5:31 AM, Aleksej Efimov wrote: > Masayoshi, Sean, > Thank you for the review and your comments. > > I have prepared a second version of the fix [1] without the > .properties files. These files are used in > test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNamesTest.java > test and because of that this test was removed also. > > Thank you, > Aleksej > > [1] http://cr.openjdk.java.net/~aefimov/8030822/9/webrev.01/ > > > > On 01/23/2014 08:43 AM, Masayoshi Okutsu wrote: >> Hi Aleksej, >> >> I think this one is the first tzdata change for JDK9. So I'd suggest >> that all the TimeZoneNames*.properties files, which were temporarily >> created for the translation work, be removed. >> >> Thanks, >> Masayoshi >> >> On 1/21/2014 10:17 PM, Aleksej Efimov wrote: >>> Hi, >>> Can I have a review for 2013i timezone data integration [1] to JDK9. >>> There is one change in tzdb that affects naming for "Asia/Amman" >>> timezone: >>> "The Jordan switches back to standard time at 00:00 on December >>> 20, 2013." >>> All changes in TimeZoneNames*.java and TimeZoneNames*.properties >>> files are related to this one tzdb change. >>> >>> The list of executed regression test sets: test/sun/util/calendar >>> test/java/util/Calendar test/sun/util/resources/TimeZone >>> test/sun/util/calendar test/java/util/TimeZone test/java/time >>> test/java/util/Formatter test/closed/java/util/Calendar >>> test/closed/java/util/TimeZone >>> All tests gave PASS result. >>> >>> Webrev location: >>> http://cr.openjdk.java.net/~aefimov/8030822/9/webrev.00/ >>> >>> Thank you, >>> Aleksej >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8030822 >> > From stuart.marks at oracle.com Thu Jan 30 06:31:56 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 29 Jan 2014 22:31:56 -0800 Subject: Question about the bug https://bugs.openjdk.java.net/browse/JDK-8031179 In-Reply-To: <52E382EB.1070403@oracle.com> References: <52D7F2D6.7090007@oracle.com> <52D7F83B.8060900@oracle.com> <52D9CE99.5050404@oracle.com> <52E212BF.7030103@oracle.com> <52E235BE.2040304@oracle.com> <52E30B1C.4070701@oracle.com> <52E382EB.1070403@oracle.com> Message-ID: <52E9F1DC.8070707@oracle.com> Hi Eric, Thanks for the updates. I've pushed this changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/97dc93591ae7 A few comments and minor corrections. 1. There was no changeset in the webrev; it was still just a plain patch. Depending on how you ran webrev, you might have stumbled over a bug in webrev. I use webrev -r and there's a bug that causes that mode not to generate a changeset. I've filed a bug CODETOOLS-7900311 on this and have posted a webrev to fix webrev. :-) Meanwhile, it was helpful that you wrote out the changeset comments so that I didn't have to. 2. You're a JDK9 Author, so I put your OpenJDK name (ewang) for the changeset author and removed the Contributed-by line. (A little-known mercurial fact is that anyone can create a changeset and name anyone else as the author of that changeset, and push that changeset if they have rights to do so.) 3. I removed some trailing whitespace from the change. The jcheck extension will reject changesets that have trailing whitespace (and other issues like tabs, malformed changeset comments, invalid usernames, etc.) Henceforth, please make sure future patches are jcheck clean. 4. The format string for creating the URL in LookupIPv6.java uses the explicit argument index form of the format specifier ("%1$s") which is unnecessary since the primary use for this form is to enable reordering of strings for localization purposes. I've removed these. In addition, the "port" argument used the string format specifier %s instead of the integral numeric format specifier %d. Th %s works, but it's surprising. I've corrected this as well. s'marks On 1/25/14 1:24 AM, Eric Wang wrote: > Hi Stuart, > > I have made changes based on your comments. Can you please review again? Thanks > a lot! > http://cr.openjdk.java.net/~ewang/JDK-8031179/webrev.01/ > > > Eric > On 2014/1/25 8:53, Stuart Marks wrote: >> Hi Eric, >> >> OK, overall this looks good. There are a few adjustments I'd like you to make >> before I push it for you. Part of this is to get you to do a more complete job >> of preparing changesets, and part of it is to make my job as a sponsor easier. >> :-) Oh, and there a couple style issues as well. >> >> 1. In the LookupIPv6 test, REGISTRY_PORT is capitalized, making it appear to >> be a constant, when in fact it's a variable that contains the result of >> calling getUnusedRandomPort(). It's also unclear why it needs to be a static. >> Just make it a local variable with a typical variable name, e.g. >> >> int port = TestLibrary.getUnusedRandomPort(); >> >> and of course make corresponding name changes where it's used. >> >> 2. The creation of the URL string for Naming.lookup() concatenates two string >> literals "]" + ":". It's probably better to combine these into a single >> literal "]:". Actually I think it would be preferable to create this URL >> string using String.format(), so please do this instead. >> >> 3. Prepare a complete changeset that's committed locally to your repository >> before running webrev. This changeset should include properly formatted commit >> comments, including the bugid line and Reviewed-by line, and optionally a >> Summary line. Recent versions of webrev will export a mercurial changeset and >> include it in the webrev output, instead of just diffs. Using the changeset I >> can just import and push it, instead of having to edit the changeset myself >> manually. >> >> 4. When you post the webrev, you should post updated webrevs under a directory >> with an incremented sequence number (in this case, webrev.01). That way, links >> to, and comments on, previous webrevs will not be invalidated. >> >> Thanks, >> >> s'marks >> >> On 1/24/14 1:43 AM, Eric Wang wrote: >>> Hi Stuart, >>> >>> Please review the webrev >>> http://cr.openjdk.java.net/~ewang/JDK-8031179/webrev.00/, if you are OK with the >>> changes, could you please be my sponsor? >>> >>> Thanks, >>> Eric >>> On 2014/1/24 15:14, Eric Wang wrote: >>>> Hi Stuart, >>>> Thanks for the suggestion! sorry for reply this mail late as i was busy on >>>> other tasks >>>> The webrev has been in the internal review process. Based on the suggestion, >>>> here is a summary of changes: >>>> >>>> 1. Add othervm options to tests: >>>> java/rmi/Naming/DefaultRegistryPort.java >>>> java/rmi/Naming/legalRegistryNames/LegalRegistryNames.java >>>> java/rmi/Naming/LookupNameWithColon.java >>>> java/rmi/server/UnicastRemoteObject/exportObject/GcDuringExport.java >>>> sun/rmi/rmic/RMIGenerator/RmicDefault.java >>>> java/rmi/MarshalledObject/compare/Compare.java >>>> java/rmi/MarshalledObject/compare/HashCode.java >>>> >>>> 2. Remove java/rmi and sun/rmi from othervm.dirs of TEST.ROOT >>>> >>>> 3. Filed a another bug https://bugs.openjdk.java.net/browse/JDK-8032629 for >>>> exclusiveAccess.dirs >>>> >>>> Thanks, >>>> Eric >>>> >>>> On 2014/1/18 8:45, Stuart Marks wrote: >>>>> Hi Eric, >>>>> >>>>> Thanks for doing the analysis of the tests that need /othervm. The list of >>>>> tests that don't need /othervm looks good. One subtlety is this one: >>>>> >>>>> java/rmi/activation/ActivationGroupDesc/checkDefaultGroupName/CheckDefaultGroupName.java >>>>> >>>>> >>>>> >>>>> Most activation tests do need /othervm, but this one doesn't, since all it >>>>> does is create an ActivationGroupDesc instance, which has no side effects. >>>>> This is unusual for the activation APIs, since most of them are quite >>>>> intertwined with the rest of the activation subsystem. So, for this test, the >>>>> lack of /othervm warrants a comment explaining why /othervm is unnecessary. >>>>> >>>>> Regarding merging of the tests java/rmi/MarshalledObject/compare/Compare.java >>>>> and HashCode.java, this is fairly subtle and not obviously wrong, but it's >>>>> not obviously right either. Note that different jtreg tests -- even in >>>>> agentvm or samevm mode -- load the test class in a fresh classloader, which >>>>> means that the statics are reinitialized. This provides some degree of >>>>> isolation of the tests even when they're reusing the same JVM. By contrast, >>>>> calling the two different methods from within the same test exposes the >>>>> second one to initializations left from the first one. In addition (though >>>>> I'm not too concerned about this) if the first test fails the second won't be >>>>> run at all. Merging these tests is kind of out of scope for this particular >>>>> bug, and since I wasn't fully able to convince myself that the merged tests >>>>> have the same semantics as the unmerged tests, I'd prefer not to see the >>>>> merging of these tests as part of this changeset. >>>>> >>>>> (Some cleanup of these two tests is probably warranted eventually. I'd take a >>>>> different approach of merging and refactoring the sources but keeping them as >>>>> separate test runs, using two @run tags. But we should work on that >>>>> separately. Meanwhile, the overhead of having these as separate tests is >>>>> minimal, especially if they're not run in /othervm mode.) >>>>> >>>>> I don't think the removal of java/rmi/Naming from exclusiveAccess.dirs is >>>>> safe at this point. The DefaultRegistryPort.java test uses the default >>>>> registry port, not a unique one. Conceptually it would need to be converted >>>>> to use the TestLibrary unique port stuff, but the test is actually about >>>>> using the default port. So, the solution here isn't obvious. >>>>> >>>>> In addition, the java/rmi/Naming/legalRegistryNames/LegalRegistryNames.java >>>>> test also uses the default registry port. It too will need to converted >>>>> before java/rmi/Naming is removed from exclusiveAccess.dirs. >>>>> >>>>> The java/rmi/Naming/LookupIPv6.java test was converted to use the TestLibrary >>>>> unique port technique, but only partially. The registry is created on the >>>>> unique port, but the Naming.lookup() call on the last line of the test >>>>> doesn't provide a port number, so it does the lookup on the default port >>>>> instead. This will cause the test to fail in almost all cases. >>>>> >>>>> I have to ask, did you run this test with your modifications? >>>>> >>>>> (Well, the test would pass if IPv6 is not enabled on the machine running the >>>>> test, but it only passes because the part of the test that creates and uses >>>>> the registry is bypassed entirely if IPv6 is not enabled. If you're modifying >>>>> code, you need to take responsibility for ensuring that the code being >>>>> modified is actually being run and is doing what you expect.) >>>>> >>>>> LookupIPv6.java also needs to have these lines added to the test tags: >>>>> * @bug 4402708 >>>>> + * @library ../testlibrary >>>>> + * @build TestLibrary >>>>> * @run main/othervm -Djava.net.preferIPv6Addresses=true LookupIPv6 >>>>> (Their absence will cause the test also to fail in a clean build, but the >>>>> test will find a TestLibrary class if one had been compiled by a previous >>>>> test that had required it.) >>>>> >>>>> Maybe we should separate the othervm changes (removal of the rmi dirs from >>>>> othervm.dirs, and addition of /othervm) from the exclusiveAccess.dirs >>>>> changes. A separate bug would be filed for exclusiveAccess.dirs. I know this >>>>> means the bug count won't go down, but dealing with exclusiveAccess.dirs >>>>> means that the logic of various tests will need to be change to use the >>>>> unique port mechanism. This is a fair chunk of work and it's logically >>>>> distinct from the othervm work. >>>>> >>>>> If we also remove the merging of the MarshalledObject tests, I think we can >>>>> proceed with the othervm changes. >>>>> >>>>> Eric, can you make these changes and send out another webrev? >>>>> >>>>> Thanks. >>>>> >>>>> s'marks >>>>> >>>>> >>>>> >>>>> On 1/16/14 7:18 AM, Eric Wang wrote: >>>>>> Hi Stuart, >>>>>> >>>>>> I have generated a webrev for review, can you please help to check whether >>>>>> the changes are OK. >>>>>> http://cr.openjdk.java.net/~ewang/JDK-8031179/webrev.00/ >>>>>> >>>>>> >>>>>> Also need your help to confirm that the rest 9 tests in previous mail don't >>>>>> need the /othervm option indeed. >>>>>> >>>>>> Thanks, >>>>>> Eric >>>>>> On 2014/1/16 22:55, Eric Wang wrote: >>>>>>> Hi Stuart, >>>>>>> >>>>>>> I'm working on the bug https://bugs.openjdk.java.net/browse/JDK-8031179 to >>>>>>> add /othervm option to rmi tests, so they can removed from the item >>>>>>> othervm.dir and exclusiveAccess.dirs. >>>>>>> By searching the directories java/rmi, sun/rmi and java/rmi/Naming, there >>>>>>> are 14 tests without othervm option, but only 5 tests need to the /othervm >>>>>>> tag. they are: >>>>>>> >>>>>>> Tests need /othervm option: >>>>>>> java/rmi/Naming/DefaultRegistryPort.java >>>>>>> java/rmi/Naming/legalRegistryNames/LegalRegistryNames.java >>>>>>> java/rmi/Naming/LookupNameWithColon.java >>>>>>> java/rmi/server/UnicastRemoteObject/exportObject/GcDuringExport.java >>>>>>> sun/rmi/rmic/RMIGenerator/RmicDefault.java >>>>>>> >>>>>>> Tests don't need the /othervm option: >>>>>>> java/rmi/activation/ActivationGroupDesc/checkDefaultGroupName/CheckDefaultGroupName.java >>>>>>> >>>>>>> >>>>>>> java/rmi/MarshalledObject/compare/Compare.java >>>>>>> java/rmi/MarshalledObject/compare/HashCode.java >>>>>>> java/rmi/MarshalledObject/compare/NullReference.java >>>>>>> java/rmi/server/Unmarshal/PrimitiveClasses.java >>>>>>> sun/rmi/log/ReliableLog/LogAlignmentTest.java >>>>>>> sun/rmi/log/ReliableLog/Recovery.java >>>>>>> sun/rmi/log/ReliableLog/SnapshotSize.java >>>>>>> sun/rmi/rmic/classpath/RMICClassPathTest.java >>>>>>> >>>>>>> Also i have a bit confuse about the test Compare.java and HashCode.java in >>>>>>> java/rmi/MarshalledObject/compare directory, as they should be merged into >>>>>>> one test so that we don't need to add additional /othervm option for 2 test. >>>>>>> >>>>>>> Thanks, >>>>>>> Eric >>>>>>> >>>>>> >>>>> >>>> >>> > From stuart.marks at oracle.com Thu Jan 30 06:54:14 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 29 Jan 2014 22:54:14 -0800 Subject: RFR(s): 8023541 Race condition in rmid initialization In-Reply-To: <4D7464F4-27AB-4B91-B986-2C4A13C8EDB3@oracle.com> References: <52E8A4DF.4010804@oracle.com> <52E8D654.4010103@gmail.com> <52E9BF93.5040200@oracle.com> <4D7464F4-27AB-4B91-B986-2C4A13C8EDB3@oracle.com> Message-ID: <52E9F716.6010307@oracle.com> On 1/29/14 8:50 PM, Tristan Yan wrote: > Looks like in you new webrev. The wait will continue to go loop until > systemStub is not null. If it?s what you meant to do that? Yes. In the previous webrev, systemStub started off as null and made a single transition to non-null. The boolean 'initialized' started off as false and made a single transition to true, at the same time. If you set aside the issue of systemStub being final (which I've removed in this webrev) these states are redundant. That is, systemStub == null <==> initialized == false systemStub != null <==> initialized == true (Where <==> is read as "if and only if" meaning that the implication goes both ways.) The while-loop in the old webrev was while (!initialized) which is the same as while (initialized == false) Therefore, the loop condition can be replaced with while (systemStub == null) and the initialized field can be removed. Restated in perhaps a more intuitive way, the bug was that lookup() sometimes returned null. So the condition on systemStub that we want to reach before returning from getSystemStub() is that systemStub be non-null. To do this we have to write the inverse of the condition in the while loop. Thus, we want systemStub to be non-null, so we have to keep waiting while it is null. s'marks From tristan.yan at oracle.com Thu Jan 30 07:34:55 2014 From: tristan.yan at oracle.com (Tristan Yan) Date: Thu, 30 Jan 2014 15:34:55 +0800 Subject: RFR(s): 8023541 Race condition in rmid initialization In-Reply-To: <52E9C5EF.3090903@oracle.com> References: <52E8A4DF.4010804@oracle.com> <52E8D654.4010103@gmail.com> <52E9BF93.5040200@oracle.com> <52E9C5EF.3090903@oracle.com> Message-ID: <3459E006-52CF-4260-B3EC-175077F98B59@oracle.com> Hi Stuart I didn?t make my comment clear. You set interrupted as true when thread gets interrupted. Here it's still going to wait until systemStub is not null. Why do you still need interrupt current thread in this case. Thank you Tristan On Jan 30, 2014, at 11:24 AM, David Holmes wrote: >> http://cr.openjdk.java.net/~smarks/reviews/8023541/webrev.1/ From daniel.fuchs at oracle.com Thu Jan 30 09:09:33 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 30 Jan 2014 10:09:33 +0100 Subject: RFR(s): 8023541 Race condition in rmid initialization In-Reply-To: <52E9BF93.5040200@oracle.com> References: <52E8A4DF.4010804@oracle.com> <52E8D654.4010103@gmail.com> <52E9BF93.5040200@oracle.com> Message-ID: <52EA16CD.4000301@oracle.com> Hi Stuart, I wonder whether you should replace the assert in the constructor by an explicit null check: - assert systemStub != null + if (systemStub == null) throw new NullPointerException(); The reason I see is that before your change, an object constructed with a null systemStub would have sooner or later failed in NPE. Now with your change, an object constructed with a null system stub will block - waiting forever for system stub to become not null. The question of course is whether throwing NPE in the constructor would cause any compatibility issues. Passing the JCK might help to figure it out. Best regards, -- daniel On 1/30/14 3:57 AM, Stuart Marks wrote: > Hi all, wow, lots of comments on this. Let me see if I can tackle them > in one message. > > Quick aside before I get to the issues: my priorities for this code > are correctness and maintainability, possibly at the expense of > performance. In other words I'm willing to make the code more complex > so that it's correct, but I'm less willing to make it more complex in > order to make it go faster. > > (Tristan, David) Making 'initialized' be volatile. As things stand, as > David has pointed out (thanks!) it's not necessary for it to be > volatile. There are other circumstances (see below) where it would be > necessary to make it volatile, though. > > (Alan, Paul) We could convert to double-checked locking and avoid a > synchronization in the common case, paying only a volatile read. > Something like, > > volatile boolean initialized = false; > ... > private void awaitInitialized() { > if (!initialized) { > synchronized (this) { > try { > while (!initialized) { > wait(); > } catch (InterruptedException ie) { > Thread.currentThread().interrupt(); > } > } > } > } > > I *think* that's right. (Is it?) I don't know whether this performs > any better, or if it does, whether it's worth the additional > complexity. I had to squint at this for a while to convince myself > it's correct. > > I am fairly sure this is not a performance-critical area of code. > (Famous last words, I know.) The other threads that can be active here > are handling remote calls, so they're already doing network I/O, > unmarshalling, and dispatching to the RMI thread pool. Compared to > this, the incremental cost of a synchronization block seems > inconsequential. I don't have much intuition about how much we'd save > by substituting a volatile read for a full synchronization in the > common case, but given that this is within the context of a fairly > expensive operation, it doesn't seem like it's worth it to me. > > (Alan, Paul) Calling awaitInitialized isn't strictly necessary > anywhere except for the equals(NAME) case of lookup(). Yes, that's > right. I added it everywhere because of a possibly misguided sense of > completeness and consistency. One could essentially redefine > awaitInitialized() to protect just the systemStub field, not the > "entire" object, whose only state is that field anyway. Also, see > below regarding renaming this method. > > (Alan) Use systemStub == null as the condition instead of > !initialized. I considered at first this but it got confusing really > fast. Take a look: > > private final ActivationSystem systemStub; > > SystemRegistryImpl(..., systemStub) { > ... > this.systemStub = systemStub; > notifyAll(); > ... > } > > private synchronized void awaitInitialized() { > ... > while (systemStub == null) { > wait(); > } > ... > } > > We rely on systemStub to be initialized at object creation time > (before construction!) to its default value of null. I think this is > right. The constructor then initializes the blank final to non-null > and notifies. > > Then, awaitInitialized seems straightforward until you see that the > condition is waiting for the value of a final variable to change! JLS > sec 17.5 [1] allows all sorts of optimizations for final fields, but > they all are qualified with what is essentially a safe publication > requirement on the reference: > > An object is considered to be completely initialized when its > constructor > finishes. A thread that can only see a reference to an object > after that > object has been completely initialized is guaranteed to see the > correctly > initialized values for that object's final fields. > > [1] http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.5 > > Unfortunately this code *unsafely* publishes a reference to 'this' > which is the root of this whole problem. Under these circumstances I'd > prefer to be really conservative about the code here. I can't quite > convince myself that a condition loop waiting for a final field to > change value is safe. That's why I added a separate field. > > I can see removing the boolean and using systemStub == null as the > condition making things simpler, since there are fewer variables to > reason about, but only if systemStub is made non-final. Making it > non-final prevents any unwanted optimizations resulting from it being > final. Having it be final doesn't add much anyway. I'll also move all > accesses to systemStub within synchronized blocks so there is no > question about visibility. (As a result, awaitInitialized now gets > turned into getSystemStub.) > > (Peter) Should the interrupt break out of the loop even though the > condition isn't satisfied? This is a good point. Usually I think of > interrupt as wanting to avoid waiting indefinitely for the condition > to become true (which is the point of supporting interruption) but in > this case the condition will always occur in a timely fashion. So I'll > accept the suggestion to save the interrupt state and let the > condition loop terminate. > > Updated webrev here: > > http://cr.openjdk.java.net/~smarks/reviews/8023541/webrev.1/ > > Thanks, > > s'marks From david.holmes at oracle.com Thu Jan 30 10:35:35 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 30 Jan 2014 20:35:35 +1000 Subject: RFR(s): 8023541 Race condition in rmid initialization In-Reply-To: <3459E006-52CF-4260-B3EC-175077F98B59@oracle.com> References: <52E8A4DF.4010804@oracle.com> <52E8D654.4010103@gmail.com> <52E9BF93.5040200@oracle.com> <52E9C5EF.3090903@oracle.com> <3459E006-52CF-4260-B3EC-175077F98B59@oracle.com> Message-ID: <52EA2AF7.8040904@oracle.com> On 30/01/2014 5:34 PM, Tristan Yan wrote: > Hi Stuart > I didn?t make my comment clear. You set interrupted as true when thread > gets interrupted. Here it's still going to wait until systemStub is not > null. Why do you still need interrupt current thread in this case. Because the golden rule of interrupt handling is you either throw InterruptedException or you re-assert the interrupted state. This allows code further up the stack to respond to interrupts. David > Thank you > Tristan > > On Jan 30, 2014, at 11:24 AM, David Holmes > wrote: > >>> http://cr.openjdk.java.net/~smarks/reviews/8023541/webrev.1/ > From Paul.Sandoz at oracle.com Thu Jan 30 11:13:10 2014 From: Paul.Sandoz at oracle.com (Paul Sandoz) Date: Thu, 30 Jan 2014 12:13:10 +0100 Subject: RFR(s): 8023541 Race condition in rmid initialization In-Reply-To: <52E9BF93.5040200@oracle.com> References: <52E8A4DF.4010804@oracle.com> <52E8D654.4010103@gmail.com> <52E9BF93.5040200@oracle.com> Message-ID: <2C3EDEE3-BFF2-4A39-BF90-2EC023D3BEEC@oracle.com> On Jan 30, 2014, at 3:57 AM, Stuart Marks wrote: > > Then, awaitInitialized seems straightforward until you see that the condition is waiting for the value of a final variable to change! JLS sec 17.5 [1] allows all sorts of optimizations for final fields, but they all are qualified with what is essentially a safe publication requirement on the reference: > > An object is considered to be completely initialized when its constructor > finishes. A thread that can only see a reference to an object after that > object has been completely initialized is guaranteed to see the correctly > initialized values for that object's final fields. > > [1] http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.5 > > Unfortunately this code *unsafely* publishes a reference to 'this' which is the root of this whole problem. Under these circumstances I'd prefer to be really conservative about the code here. I can't quite convince myself that a condition loop waiting for a final field to change value is safe. That's why I added a separate field. > I think you have done the right thing in the latest webrev, even though i suspect the runtime does not fully optimize final fields as constants (since it is still possible to update final fields, e.g. see System.out). It should not be this hard to reason about this stuff, right? Hopefully updates to the JMM will make this easier to grok, even though this is a naughty case. Paul. From sundararajan.athijegannathan at oracle.com Thu Jan 30 13:04:53 2014 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Thu, 30 Jan 2014 13:04:53 +0000 Subject: hg: jdk8/tl/nashorn: 8032944: Improve reflection in Nashorn Message-ID: <20140130130504.4BA5D628AC@hg.openjdk.java.net> Changeset: a43c125b03dc Author: sundar Date: 2014-01-30 18:34 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/a43c125b03dc 8032944: Improve reflection in Nashorn Reviewed-by: jlaskey, attila, ahgross ! src/jdk/nashorn/internal/objects/NativeObject.java + test/script/sandbox/classbind.js From sundararajan.athijegannathan at oracle.com Thu Jan 30 13:34:14 2014 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Thu, 30 Jan 2014 13:34:14 +0000 Subject: hg: jdk8/tl/nashorn: 8032954: Nashorn: extend Java.extend Message-ID: <20140130133415.A25F4628B0@hg.openjdk.java.net> Changeset: eca774d33fa4 Author: sundar Date: 2014-01-30 19:04 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/eca774d33fa4 8032954: Nashorn: extend Java.extend Reviewed-by: attila, jlaskey, ahgross ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! test/script/sandbox/classbind.js ! test/script/sandbox/classloader.js ! test/script/sandbox/classloader.js.EXPECTED From Alan.Bateman at oracle.com Thu Jan 30 13:46:42 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 30 Jan 2014 13:46:42 +0000 Subject: [8011944] Sort fails with ArrayIndexOutOfBoundsException In-Reply-To: <52E9BA1B.8000706@Oracle.COM> References: <52E19DD0.7020001@Oracle.COM> <52E23359.3050705@oracle.com> <52E9BA1B.8000706@Oracle.COM> Message-ID: <52EA57C2.1090703@oracle.com> On 30/01/2014 02:34, Miroslaw Niemiec wrote: > The copyright header added to > test/java/util/Arrays/TimSortStackSize.java: > http://cr.openjdk.java.net/~miroslawzn/8011944/webrev.02/ > > - Miroslaw Thanks, just a few minor nits to look at before you push this: - The import at L30 is mis-aligned. - The creation of the Compatator at L49 looks like a new statement, not immediately obvious that it's a parameter to sort (so best to reformat it). - The copyright date says 2005 so I assume it was copied from another file. -Alan From Alan.Bateman at oracle.com Thu Jan 30 14:23:21 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 30 Jan 2014 14:23:21 +0000 Subject: RFR(s): 8023541 Race condition in rmid initialization In-Reply-To: <52EA16CD.4000301@oracle.com> References: <52E8A4DF.4010804@oracle.com> <52E8D654.4010103@gmail.com> <52E9BF93.5040200@oracle.com> <52EA16CD.4000301@oracle.com> Message-ID: <52EA6059.6090107@oracle.com> On 30/01/2014 09:09, Daniel Fuchs wrote: > Hi Stuart, > > I wonder whether you should replace the assert in the > constructor by an explicit null check: > > - assert systemStub != null > + if (systemStub == null) throw new NullPointerException(); > > The reason I see is that before your change, an object constructed > with a null systemStub would have sooner or later failed in NPE. > Now with your change, an object constructed with a null system > stub will block - waiting forever for system stub to become not > null. I suspect the system stub can never be null but I agree it should be checked before creating the RegistryImpl. One way to do that is by going through another constructor, something like this: private SystemRegistryImpl(int port, RMIClientSocketFactory csf, RMIServerSocketFactory ssf, ActivationSystem systemStub, Void unused) throws RemoteException { super(port, csf, ssf); synchronized (this) { this.systemStub = systemStub; notifyAll(); } } SystemRegistryImpl(int port, RMIClientSocketFactory csf, RMIServerSocketFactory ssf, ActivationSystem systemStub) throws RemoteException { this(port, csf, ssf, Objects.requireNonNull(systemStub), null); } but maybe that it too subtle. -Alan From Alan.Bateman at oracle.com Thu Jan 30 14:46:20 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 30 Jan 2014 14:46:20 +0000 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52E95212.3040803@oracle.com> References: <52B3568B.5050905@oracle.com> <52CFD218.2060101@gmail.com> <52D06B70.60001@oracle.com> <52D15201.90109@gmail.com> <52D47D59.8040905@oracle.com> <52D72577.1050506@oracle.com> <52D76859.2030502@oracle.com> <52D82968.4030608@oracle.com> <52D8929B.2020905@oracle.com> <52D8A42A.4020906@oracle.com> <52D8B3B6.3030202@oracle.com> <52D9295D.6080106@gmail.com> <52D92C73.2020309@gmail.com> <52D92F1A.4040400@gmail.com> <52DC812C.1000607@oracle.com> <52DCD78E.8050404@gmail.com> <52DCE17B.4050708@gmail.com> <52DDD9F3.1050201@oracle.com> <52DE19C1.2070302@gmail.com> <52DE9147.4030305@gmail.com> <52DEB9C4.4030606@oracle.com> <52DEF53C.3050905@gmail.com> <52E1772A.1050608@oracle.com> <52E1B4C5.8050807@oracle.com> <52E1C7AD.8090100@oracle.com> <52E2FFE2.7000600@gmail.com> <52E33F11.8000804@oracle.com> <52E55CF7.6050400@gmail.com> <52E7134E.9070606@oracle.com> <52E76DE5.1000300@gmail.com> <52E7D0DD.5030507@oracle.com> <52E8FD99.2050901@gmail.com> <52E95212.3040803@oracle.com> Message-ID: <52EA65BC.4070509@oracle.com> On 29/01/2014 19:10, Mandy Chung wrote: > > On 1/29/2014 5:09 AM, Peter Levart wrote: >> >> Since I don't know what should be the correct behaviour of javac, I >> can leave the Reference.java changes as proposed since it compiles in >> both cases. Or should I revert the change to declaration of local >> variable 'q' ? > > I slightly prefer to revert the change to ReferenceQueue Object> for now as there is no supertype for Object and this looks a > little odd. We can clean this up as a separate fix after we get > clarification from compiler-dev. I see Peter has posted a question to compiler-dev on this and it can always be re-visited once it clear why it compiles when both Reference and ReferenceQueue are in the same compilation unit. -Alan From peter.levart at gmail.com Thu Jan 30 14:51:16 2014 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 30 Jan 2014 15:51:16 +0100 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52EA65BC.4070509@oracle.com> References: <52B3568B.5050905@oracle.com> <52D06B70.60001@oracle.com> <52D15201.90109@gmail.com> <52D47D59.8040905@oracle.com> <52D72577.1050506@oracle.com> <52D76859.2030502@oracle.com> <52D82968.4030608@oracle.com> <52D8929B.2020905@oracle.com> <52D8A42A.4020906@oracle.com> <52D8B3B6.3030202@oracle.com> <52D9295D.6080106@gmail.com> <52D92C73.2020309@gmail.com> <52D92F1A.4040400@gmail.com> <52DC812C.1000607@oracle.com> <52DCD78E.8050404@gmail.com> <52DCE17B.4050708@gmail.com> <52DDD9F3.1050201@oracle.com> <52DE19C1.2070302@gmail.com> <52DE9147.4030305@gmail.com> <52DEB9C4.4030606@oracle.com> <52DEF53C.3050905@gmail.com> <52E1772A.1050608@oracle.com> <52E1B4C5.8050807@oracle.com> <52E1C7AD.8090100@oracle.com> <52E2FFE2.7000600@gmail.com> <52E33F11.8000804@oracle.com> <52E55CF7.6050400@gmail.com> <52E7134E.9070606@oracle.com> <52E76DE5.1000300@gmail.com> <52E7D0DD.5030507@oracle.com> <52E8FD99.2050901@gmail.com> <52E95212.3040803@oracle.com> <52EA65BC.4070509@oracle.com> Message-ID: <52EA66E4.1010205@gmail.com> On 01/30/2014 03:46 PM, Alan Bateman wrote: > On 29/01/2014 19:10, Mandy Chung wrote: >> >> On 1/29/2014 5:09 AM, Peter Levart wrote: >>> >>> Since I don't know what should be the correct behaviour of javac, I >>> can leave the Reference.java changes as proposed since it compiles >>> in both cases. Or should I revert the change to declaration of local >>> variable 'q' ? >> >> I slightly prefer to revert the change to ReferenceQueue> Object> for now as there is no supertype for Object and this looks a >> little odd. We can clean this up as a separate fix after we get >> clarification from compiler-dev. > I see Peter has posted a question to compiler-dev on this and it can > always be re-visited once it clear why it compiles when both Reference > and ReferenceQueue are in the same compilation unit. > > -Alan I Just commited the version with no change to ReferenceQueue line to jdk9/dev. If there is a bug in javac and the code would not compile as is, the change to this line should be committed as part of javac fix, right? Regards, Peter From sundararajan.athijegannathan at oracle.com Thu Jan 30 14:15:53 2014 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Thu, 30 Jan 2014 14:15:53 +0000 Subject: hg: jdk8/tl/nashorn: 8032949: Nashorn linkages awry Message-ID: <20140130141554.BFDAE628B3@hg.openjdk.java.net> Changeset: c59fb10cb0b5 Author: sundar Date: 2014-01-30 19:45 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/c59fb10cb0b5 8032949: Nashorn linkages awry Reviewed-by: jlaskey, attila, ahgross ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java ! src/jdk/nashorn/internal/runtime/linker/ReflectionCheckLinker.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineSecurityTest.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java From Miroslaw.Niemiec at Oracle.COM Thu Jan 30 15:36:27 2014 From: Miroslaw.Niemiec at Oracle.COM (Miroslaw Niemiec) Date: Thu, 30 Jan 2014 07:36:27 -0800 Subject: [8011944] Sort fails with ArrayIndexOutOfBoundsException In-Reply-To: <52EA57C2.1090703@oracle.com> References: <52E19DD0.7020001@Oracle.COM> <52E23359.3050705@oracle.com> <52E9BA1B.8000706@Oracle.COM> <52EA57C2.1090703@oracle.com> Message-ID: <52EA717B.7040405@Oracle.COM> On 1/30/2014 5:46 AM, Alan Bateman wrote: > On 30/01/2014 02:34, Miroslaw Niemiec wrote: >> The copyright header added to >> test/java/util/Arrays/TimSortStackSize.java: >> http://cr.openjdk.java.net/~miroslawzn/8011944/webrev.02/ >> >> - Miroslaw > Thanks, just a few minor nits to look at before you push this: > > - The import at L30 is mis-aligned. > - The creation of the Compatator at L49 looks like a new statement, > not immediately obvious that it's a parameter to sort (so best to > reformat it). > - The copyright date says 2005 so I assume it was copied from another > file. > > -Alan Hi Alan, I have corrected the test file according to your suggestions The new webrev: http://cr.openjdk.java.net/~miroslawzn/8011944/webrev.03/ From Alan.Bateman at oracle.com Thu Jan 30 15:59:28 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 30 Jan 2014 15:59:28 +0000 Subject: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently In-Reply-To: <52EA66E4.1010205@gmail.com> References: <52B3568B.5050905@oracle.com> <52D15201.90109@gmail.com> <52D47D59.8040905@oracle.com> <52D72577.1050506@oracle.com> <52D76859.2030502@oracle.com> <52D82968.4030608@oracle.com> <52D8929B.2020905@oracle.com> <52D8A42A.4020906@oracle.com> <52D8B3B6.3030202@oracle.com> <52D9295D.6080106@gmail.com> <52D92C73.2020309@gmail.com> <52D92F1A.4040400@gmail.com> <52DC812C.1000607@oracle.com> <52DCD78E.8050404@gmail.com> <52DCE17B.4050708@gmail.com> <52DDD9F3.1050201@oracle.com> <52DE19C1.2070302@gmail.com> <52DE9147.4030305@gmail.com> <52DEB9C4.4030606@oracle.com> <52DEF53C.3050905@gmail.com> <52E1772A.1050608@oracle.com> <52E1B4C5.8050807@oracle.com> <52E1C7AD.8090100@oracle.com> <52E2FFE2.7000600@gmail.com> <52E33F11.8000804@oracle.com> <52E55CF7.6050400@gmail.com> <52E7134E.9070606@oracle.com> <52E76DE5.1000300@gmail.com> <52E7D0DD.5030507@oracle.com> <52E8FD99.2050901@gmail.com> <52E95212.3040803@oracle.com> <52EA65BC.4070509@oracle.com> <52EA66E4.1010205@gmail.com> Message-ID: <52EA76E0.2090303@oracle.com> On 30/01/2014 14:51, Peter Levart wrote: > > I Just commited the version with no change to ReferenceQueue > line to jdk9/dev. If there is a bug in javac and the code would not > compile as is, the change to this line should be committed as part of > javac fix, right? > It's good to get this change in. If javac were to be changed to reject this code then it need to be changed at the same time (but I guess we wait to see if this is case as it's just not obvious yet). -Alan From Alan.Bateman at oracle.com Thu Jan 30 16:02:45 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 30 Jan 2014 16:02:45 +0000 Subject: [8011944] Sort fails with ArrayIndexOutOfBoundsException In-Reply-To: <52EA717B.7040405@Oracle.COM> References: <52E19DD0.7020001@Oracle.COM> <52E23359.3050705@oracle.com> <52E9BA1B.8000706@Oracle.COM> <52EA57C2.1090703@oracle.com> <52EA717B.7040405@Oracle.COM> Message-ID: <52EA77A5.3070701@oracle.com> On 30/01/2014 15:36, Miroslaw Niemiec wrote: > Hi Alan, > > I have corrected the test file according to your suggestions > The new webrev: > http://cr.openjdk.java.net/~miroslawzn/8011944/webrev.03/ > Looks good, thanks for this. This backport reminds me that maybe it is time to consider removing the merge sort code (and the system property to select it) in 9. -Alan. From michael.fang at oracle.com Thu Jan 30 17:20:34 2014 From: michael.fang at oracle.com (Michael Fang) Date: Thu, 30 Jan 2014 09:20:34 -0800 Subject: RFR: 8030822: (tz) Support tzdata2013i In-Reply-To: <52E9EDDB.4050709@oracle.com> References: <52DE737E.2030200@oracle.com> <52E09DE9.20300@oracle.com> <52E96519.6020006@oracle.com> <52E9EDDB.4050709@oracle.com> Message-ID: <52EA89E2.9060904@oracle.com> Looks good to me too. thanks, -michael On 14?01?29? 10:14 ??, Masayoshi Okutsu wrote: > Looks good. > > Masayoshi > > On 1/30/2014 5:31 AM, Aleksej Efimov wrote: >> Masayoshi, Sean, >> Thank you for the review and your comments. >> >> I have prepared a second version of the fix [1] without the >> .properties files. These files are used in >> test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNamesTest.java >> test and because of that this test was removed also. >> >> Thank you, >> Aleksej >> >> [1] http://cr.openjdk.java.net/~aefimov/8030822/9/webrev.01/ >> >> >> >> On 01/23/2014 08:43 AM, Masayoshi Okutsu wrote: >>> Hi Aleksej, >>> >>> I think this one is the first tzdata change for JDK9. So I'd suggest >>> that all the TimeZoneNames*.properties files, which were temporarily >>> created for the translation work, be removed. >>> >>> Thanks, >>> Masayoshi >>> >>> On 1/21/2014 10:17 PM, Aleksej Efimov wrote: >>>> Hi, >>>> Can I have a review for 2013i timezone data integration [1] to JDK9. >>>> There is one change in tzdb that affects naming for "Asia/Amman" >>>> timezone: >>>> "The Jordan switches back to standard time at 00:00 on December 20, >>>> 2013." >>>> All changes in TimeZoneNames*.java and TimeZoneNames*.properties >>>> files are related to this one tzdb change. >>>> >>>> The list of executed regression test sets: test/sun/util/calendar >>>> test/java/util/Calendar test/sun/util/resources/TimeZone >>>> test/sun/util/calendar test/java/util/TimeZone test/java/time >>>> test/java/util/Formatter test/closed/java/util/Calendar >>>> test/closed/java/util/TimeZone >>>> All tests gave PASS result. >>>> >>>> Webrev location: >>>> http://cr.openjdk.java.net/~aefimov/8030822/9/webrev.00/ >>>> >>>> Thank you, >>>> Aleksej >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8030822 >>> >> > From snazy at gmx.de Wed Jan 22 21:34:13 2014 From: snazy at gmx.de (Robert Stupp) Date: Wed, 22 Jan 2014 22:34:13 +0100 Subject: JEP 187: Serialization 2.0 & Serialization-aware constructors In-Reply-To: References: Message-ID: Am 22.01.2014 um 17:33 schrieb "David M. Lloyd" : > The concept of explicit deserialization constructors is interesting and is something I've explored a little bit in the context of JBoss Marshalling. ... > The idea with a serialization-aware constructor is that each serializable class constructor can read the stream information itself and initialize fields the "normal" way, with "normal" validation. I agree with David. One thing to think about might be to introduce a special kind of constructor by extending the JLS - to introduce a special "deserialization constructor" that behaves a bit different than "normal" constructors. Deserialization-constructors are called "top-down" (java.lang.Object first) - the deserialization code is responsible to call the deserialization-constructors for each individual class. The deserialization-constructor receives information only for deserialized fields that the class "owns" (not for fields of any superclass or subclass). But: deserialization-constructors should not be callable from "normal" code. Maybe there could be multiple "deserialization constructors" - one per serialVersionUID. This should completely eliminate "spaghetti code" in "readObject()" and the need for "readObject()" at all. Another idea is to introduce a kind of "protocol" how to deal with incompatible class changes or serial-version-uid mismatches. This gets important when existing applications grow: how shall a new field be initialized, when it's not present in input stream? Maybe this could be handled by the "deserialization constructor". Regarding the situation when an older implementation reads data from a newer implementation (with more fields or changed fields) ... I think that special situation cannot be handled. But it might be possible to serialize objects explicitly for older versions - for example if the implementation knows that it creating an RPC response for an older client. writeObject() could be replaced with "serialization methods" - multiple "serialization methods" could be used to address different versions. A new serialization framework should also add support for classes with "factory methods" like those with static "valueOf(...)" methods - maybe in combination to replace readResolve/writeReplace. Serialization should also respect immutable objects like String, Byte/Integer/Long/..., InetAddress, UUID - this reduces the serialized payload and amount of (unnecessary) objects during deserialization. Maybe serialization should move a bit deeper into the JVM itself - to optimize the reflection/unsafe stuff. IMHO the explicit serialFields support should not be supported for "serialization 2.0" - maybe I'm wrong, but I do not know any code that uses this (except some core JDK classes) - for me it looks like a workaround to deal with incompatible class changes. Transport and serialization might be separated in "serialization 2.0". Current OOS/OIS implementations perform a lot of System.arraycopy operations and allocate a lot of temporary objects (e.g. during string (de)serialization). It should be possible to "feed" deserialization with ByteBuffers - for example by using NIO. For example: the current internal "readPrimitives()" method could directly operate on a ByteBuffer without any copy operation - maybe with native support from the JVM. Robert From Miroslaw.Niemiec at Oracle.COM Thu Jan 23 22:06:56 2014 From: Miroslaw.Niemiec at Oracle.COM (Miroslaw Niemiec) Date: Thu, 23 Jan 2014 14:06:56 -0800 Subject: [8011944] Sort fails with ArrayIndexOutOfBoundsException Message-ID: <52E19280.9070201@Oracle.COM> Hello! This is a simple backport from 8 to 7. Looking for a review of this even though it only requires a testcase change due to the use of lambda expressions. Since this is the first of these I've encountered I thought I better play it safe, but generally speaking, are we ok to skip the review process for backports like this? (minor lambda related testcase changes - if the lambda's are in the actual fix it probably makes sense to re-review). The fix: src/share/classes/java/util/ComparableTimSort.java src/share/classes/java/util/TimSort.java applied with no modification to 7 The only simple change was to replace a lambda expression in test case test/java/util/Arrays/TimSortStackSize.java: Arrays.sort(genData(), Integer::compare); got replaced with Arrays.sort(genData(), new java.util.Comparator() { public int compare(Integer a1, Integer a2){ return Integer.compare(a1.intValue(), a2.intValue()); } }); Jdk bug: https://bugs.openjdk.java.net/browse/JDK-8011944 Original fix for 8: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/07585a2483fa Fix for 7: http://cr.openjdk.java.net/~miroslawzn/801144/webrev.01/ Thank you Miroslaw From andrej.golovnin at gmail.com Fri Jan 24 21:33:46 2014 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Fri, 24 Jan 2014 22:33:46 +0100 Subject: Which optimizations does Hotspot apply? In-Reply-To: <52E05640.3020000@univ-mlv.fr> References: <09548E95-EA91-4986-A692-EC2DCE0944BB@snazy.de> <52E05640.3020000@univ-mlv.fr> Message-ID: Hi R?mi, > With latest jdk8, it's not true anymore. > (and most of the time the iterator object is not created anymore at least with jdk7+). Could you please explain it a little bit more? When is that optimization applied, e.g. what conditions are required for this optimization, since which version of JDK/Hotspot it is supported, where it is implemented in JDK? When I take look at a product I'm working on, I see a lot instances of ArrayList$Itr objects, which are created by for-each loops (we use JDK 7u51). Thanks in advance! Best regards, Andrej Golovnin From philip.hodges at bluewin.ch Mon Jan 27 01:12:28 2014 From: philip.hodges at bluewin.ch (Philip Hodges) Date: Mon, 27 Jan 2014 02:12:28 +0100 Subject: StringJoiner: detect or fix delimiter collision? In-Reply-To: <7916219F-E651-4939-BFB2-7D7CC38C9EEF@bluewin.ch> References: <51673A45.8060908@oracle.com> <1374608627412-145039.post@n7.nabble.com> <52218FE6.7000804@bluewin.ch> <7916219F-E651-4939-BFB2-7D7CC38C9EEF@bluewin.ch> Message-ID: <5ACEEEB3-A1D3-4F45-9D78-FDFE567A65B0@bluewin.ch> Please please please drop StringJoiner from Java 1.8 before it is too late. It is not needed. It does not add value. It is an embarrassment. We did without it for years. It is not long long overdue. We do not need it now. It does not need to be in the very first Java 1.8 release. Try leaving it out, and see if people even complain. Most people won't even notice it, let alone be ready to misuse it straight away. String.join is slower than Arrays.toString() or Collections.toString(). Test failed. String.join(delimiter, iterable) needs extra code to call toString() if elements are not already CharSequence. Convenience? Test failed. StringJoiner does not force or even remind the developer to consider delimiter collisions. Test failed. It is a perfect complement for split: the hard to use interface that can't split the joined input reliably because it might have too many delimiters. It will be the newest star on java antipattern web sites. A good place would be just after the item about not "Assembling XML with String operations" because the text parts might contain special characters. Even if it ever did appear that StringJoiner and String.join did what we wanted, I would still much rather roll my own than use the new StringJoiner in the library. Then I could set the initial capacity of the StringBuilder, skip the defensive copies and null checks, and above all, introduce some extra mandatory method call to force the developer to tell the compiler what is being done about delimiter collisions, even if it is to add an assert that there are no delimiters in the added CharSequences, or to waive that check because numbers never never contain comma delimiters (hold on ... better check the locale to see if comma is used as a decimal point or grouping character after all). I came across this non-justification [with my additions] on a blog: "StringJoiner and String.join(...) are long, long overdue. They are so long overdue that the vast majority of Java developers likely have already written or have found [or have had to mend] utilities for joining strings [to make an unsplittable delimiter collision], but it is nice [or at least well-meant] for the JDK to finally provide this itself. Everyone has encountered situations where joining strings is required [and they forgot all about escaping, or should have used a PreparedStatement instead], and it is a Good Thing? that we can now express that [bug opportunity] through a standard API that every [no, just some] Java developer (eventually) will know [of, but not actually use, and even if they do they will need an IDE to tell them that the prefix comes *after* the delimiter]." > To quote Joshua Bloch on good API design: 'When in doubt leave it out' (or 'You can always add, but you can never remove') > > > On 31 Aug 2013, at 23:13, Mike Duigou wrote: > > > On Aug 30 2013, at 23:40 , Philip Hodges wrote: >> ... >> >> Why is there such a bandwagon rolling for this "convenience" feature? > > Perhaps others just don't agree with you. The choice of functionality offered in the JDK 8 StringJoiner was not arbitrary or haphazardly chosen. If it doesn't meet your particular needs, I am sorry to hear that. Our belief as the proposers is that it offers a reasonable mix of functionality and simplicity to cover useful number of requirements. Our intent was certainly not to create the kitchen magician [1] of string joiners that attempted to incorporate every conceivable option. In particular your concerns about escaping are out of scope for the joiner in part because > > Collection strings; > > String concat = strings.stream().map(MyUtils::escape).collect(Collections.joining(",")); > > seems like an adequate and flexible solution to most people. > >> We already have joiners in apache commons and guava. > > This is the reason that StringJoiner was considered for JDK--that many others were "rolling their own". > >> At first I thought they were cool. Then I tried to use them in anger. >> And was forced to roll my own. > > I would encourage you to share your implementation or the javadocs as grist for discussion. An actual alternative is the *only* thing that is likely to be persuasive. > >> That can't be right. > > Sometimes it is. The JDK doesn't make any attempt to satisfy everyone (or anyone). We all end up writing lots of non-business logic utility functions to bridge gaps in what JDK offers. This is normal. And, if it turns out to be something lots of people need then it's entirely possible that it could be added to the JDK. > > Mike > > [1] https://www.youtube.com/watch?v=cGVG9xLHb84 > >> >> A more elaborate offically blessed feature that >> only does half the job is worse than useless. >> Without the extra complex ability to detect or avoid collisions >> it is neither "nice", nor a "Good Thing". >> >> Phil >> >> http://www.techempower.com/blog/2013/03/26/everything-about-java-8/ >> >> "StringJoiner and String.join(...) are long, long overdue. They are so long overdue that the vast majority of Java developers likely have already written or have found utilities for joining strings, but it is nice for the JDK to finally provide this itself. Everyone has encountered situations where joining strings is required, and it is a Good Thing? that we can now express that through a standard API that every Java developer (eventually) will know. " >> >> >> On 2013-07-23 22:09, Mike Duigou wrote: >>> >>> On Jul 23 2013, at 12:43 , ph wrote: >>> >>>> didn't see delimiter collision mentioned anywhere - are you really offering >>>> an interface that only joins a list of entries without escaping or quoting >>>> or even checking for separators (or escape or quote sequences) that might >>>> occur in the entries? >>> >>> Correct. StringJoiner makes no effort to address escaping/quoting. >>> Doing so would add a lot of complexity that would not >>> useful interesting to most users and probably still wouldn't satisfy everyone. >> >>> If you wish some form of escaping or quoting you can pre-processed entries however you like before joining them. >>> >>> Mike >>> > > From philip.hodges at bluewin.ch Mon Jan 27 20:31:09 2014 From: philip.hodges at bluewin.ch (Philip Hodges) Date: Mon, 27 Jan 2014 21:31:09 +0100 Subject: StringJoiner: detect or fix delimiter collision? In-Reply-To: <54010BC7-BDB8-4471-AC2F-20C9449FB85B@oracle.com> References: <51673A45.8060908@oracle.com> <1374608627412-145039.post@n7.nabble.com> <52218FE6.7000804@bluewin.ch> <7916219F-E651-4939-BFB2-7D7CC38C9EEF@bluewin.ch> <5ACEEEB3-A1D3-4F45-9D78-FDFE567A65B0@bluewin.ch> <54010BC7-BDB8-4471-AC2F-20C9449FB85B@oracle.com> Message-ID: <0F878BF8-2179-49F4-ADF0-95ECBE4FE727@bluewin.ch> I did not predict that it would be a "sprintf". It's not going to be consistently misused anything like so frequently. I compared it to the unescaped XML generation antipattern. I have not seen any technical justifications whatsoever so far, just inexplicable enthusiasm. It is like giving young drivers a faster car with no seat belts. The trouble is, unlike in Google guava, this is the JDK, you can't just drop flawed beta interfaces two versions later. All you can do is add them to static review tool blacklists and deprecate them to cause a warning at compile time, and hope that people will give them a wide berth. Even if you hide them in an unoffical sun.com package. By the way, I'm looking forward to the proprietary Base64 being changed to simply call the new official one. You can't even modify an equals method in an undocumented reflection implementation in 1.7.0.51 without breaking production applications. Wow. I am raising doubt and you are ignoring it. Don't you have the guts to say whoa, stop the bandwagon, there could just be a real problem with this, it really will make it easier to create bugs without any warning from the compiler and without making anyone's code better *in any way at all*? I am picking on String.join precisely because I have seen way too many delimiter collision bugs, not just in Java but in several other languages, and because this interface perpetuates a real world problem by preventing future interface changes to detect them. [I am not always a doomsayer. For example, I am not picking on JSR310 because Date and Calendar and SimpleDateFormat are well known disaster areas and the people working on their replacement have a deep understanding of the issues, have really taken their time, and nothing whatsoever that I have read about it jumped out at me and said this is *wrong*. It might not even be completely perfect. But I am confident it will be so much better than what we have now, and it's a shame that I won't have time to migrate existing apps to it.] The counterproposal, no, proposal refinement, wafting around inside my head, is to somehow compel programmers to make just one more method call before that final toString(). It will be difficult to find good names, especially ones that will be understood by programmers for whom English is not a first language. Something like: String.join(delimiter, joinables).assertNoUnescapedDelimiters().toString(); String.join(delimiter, joinables).neverMindDelimiterCollisions().toString(); String.join(delimiter, joinables).promiseNoUnescapedDelimiters().toString(); String.join(delimiter, joinables).escapeDelimiters(escapeChar).toString(); String.join(delimiter, joinables).quoteElements(quoteChar).toString(); The vital thing is that String.join has to return an unjoinable, that needs an adapter method to make it safely joinable. If you get that right, then we can forgive this first shot being a little slow, and enjoy the triumph of CharSequence over immutability. Yes, ultimately the goal should be to add full support for at least the most popular csv generation recipes. I'm really sorry I couldn't carry on arguing the case before August. As a minority, I only have one person's quota of energy. I will try to get some more people to look at it. On 27 Jan 2014, at 18:44, Mike Duigou wrote: > > On Jan 26 2014, at 17:12 , Philip Hodges wrote: > >> Please please please drop StringJoiner from Java 1.8 before it is too late. > > It is well past "too late". The API has been frozen since August for all but the most exceptional cases. > >>>> At first I thought they were cool. Then I tried to use them in anger. >>>> And was forced to roll my own. >>> >>> I would encourage you to share your implementation or the javadocs as grist for discussion. An actual alternative is the *only* thing that is likely to be persuasive. > > You seem to be very much in the minority on this issue by the silence from other responders on this list and elsewhere. The concerns you've highlighted with regard to delimiter management, while certainly valid, have not been of sufficient concern to suggest a change in the proposal. The prediction that using StringJoiner will become Java's sprintf seems unlikely to be be true. The reception we've seen thus far for StringJoiner has been otherwise exclusively enthusiastic and positive. > > Alternatives, refinements and counterproposals are always welcome in the discussion. Doomsaying unfortunately adds little. > > Mike From david.holmes at oracle.com Thu Jan 23 06:24:45 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Jan 2014 16:24:45 +1000 Subject: Which optimizations does Hotspot apply? In-Reply-To: <52E05640.3020000@univ-mlv.fr> References: <09548E95-EA91-4986-A692-EC2DCE0944BB@snazy.de> <52E05640.3020000@univ-mlv.fr> Message-ID: <52E0B5AD.8070601@oracle.com> Hotspot questions belong on hotspot lists. cc'ing hotspot-dev and (trying to) bcc core-libs-dev. David On 23/01/2014 9:37 AM, Remi Forax wrote: > On 01/22/2014 11:37 PM, Robert Stupp wrote: >> Is there any documentation available which optimizations Hotspot can >> perform and what "collecting a garbage" object costs? >> I know that these are two completely different areas ;) >> >> I was inspecting whether the following code >> for (Object o : someArrayList) { ... } >> would be faster than >> for (int i=0, l=someArrayList.size(); i> o=someArrayList.get(i); } >> for RandomAccessList implementations. The challenge here is not just >> to track the CPU time spent creating & using the iterator vs. size() & >> get() calls but also track GC effort (which is at least complicated if >> not impossible due to the variety of GC configuration options). > > For a long time, using a for with an index (if you are *sure* that it's > an ArrayList) was faster. > With latest jdk8, it's not true anymore. > (and most of the time the iterator object is not created anymore at > least with jdk7+). > >> >> For example: >> - Does it help Hotspot to declare parameters/variables as "final" or >> can Hotspot identify that? > > no, it's an urban myth. > You can test it by yourself, if you declare a local variable final or > not the exact same bytecode is produced by javac. The keyword final for > a local variable (or a parameter) is not stored in the bytecode. > > BTW, final was introduced in 1.1 mostly to allow to capture the value of > a variable to be used by an anonymous class, Java 8 doesn't require this > kind of variable to be declared final anymore. > >> - When does Hotspot inline method calls in general and getters/setters >> especially? > > In general, up to a depth of 10 by default and 1 for a recursive method. > Roughly, a method call is not inlined either if the call is virtual and > can call too many implementations or if the generated assembly code will > be too big. > >> >> I think such a piece of documentation (just what Hotspot can do in >> which release) would be really helpful when someone tries to optimize >> code - want to say: the question is: "Is something worth to spend time >> on or is this special situation handled by Hotspot?" > > It never worth it. > Choose the right algorithms and shape your data to be easily consumed by > your algorithms is enough. > >> >> -Robert > > R?mi > From stuart.marks at oracle.com Thu Jan 30 18:51:27 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 30 Jan 2014 10:51:27 -0800 Subject: RFR(s): 8023541 Race condition in rmid initialization In-Reply-To: <52EA2AF7.8040904@oracle.com> References: <52E8A4DF.4010804@oracle.com> <52E8D654.4010103@gmail.com> <52E9BF93.5040200@oracle.com> <52E9C5EF.3090903@oracle.com> <3459E006-52CF-4260-B3EC-175077F98B59@oracle.com> <52EA2AF7.8040904@oracle.com> Message-ID: <52EA9F2F.7010901@oracle.com> On 1/30/14 2:35 AM, David Holmes wrote: > On 30/01/2014 5:34 PM, Tristan Yan wrote: >> Hi Stuart >> I didn?t make my comment clear. You set interrupted as true when thread >> gets interrupted. Here it's still going to wait until systemStub is not >> null. Why do you still need interrupt current thread in this case. > > Because the golden rule of interrupt handling is you either throw > InterruptedException or you re-assert the interrupted state. This allows code > further up the stack to respond to interrupts. Right, thanks David. While it's often acceptable to let InterruptedException propagate, or to catch and rethrow it, IE is a checked exception so this isn't always allowed. That's the case with this code. The only alternative in this case is to re-assert the interrupted state before returning. There's some discussion of this in Goetz, et. al. "Java Concurrency In Practice", section 5.4. There's an example here of catching IE and reasserting the thread's interrupted state. Get this book if you don't have it already. The *worst* thing to do is something like, try { ... wait or sleep or something that throws IE ... } catch (InterruptedException ie) { // ignored } I write this all the time in toy programs, but product code and even test code should follow the golden rule. s'marks From stuart.marks at oracle.com Thu Jan 30 19:00:17 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 30 Jan 2014 11:00:17 -0800 Subject: RFR(s): 8023541 Race condition in rmid initialization In-Reply-To: <52EA16CD.4000301@oracle.com> References: <52E8A4DF.4010804@oracle.com> <52E8D654.4010103@gmail.com> <52E9BF93.5040200@oracle.com> <52EA16CD.4000301@oracle.com> Message-ID: <52EAA141.5000506@oracle.com> On 1/30/14 1:09 AM, Daniel Fuchs wrote: > I wonder whether you should replace the assert in the > constructor by an explicit null check: > > - assert systemStub != null > + if (systemStub == null) throw new NullPointerException(); > > The reason I see is that before your change, an object constructed > with a null systemStub would have sooner or later failed in NPE. > Now with your change, an object constructed with a null system > stub will block - waiting forever for system stub to become not > null. > > The question of course is whether throwing NPE in the constructor > would cause any compatibility issues. Passing the JCK might help > to figure it out. I considered an explicit null test, or something like Objects.requireNonNull, but decided against them. The reason is that this is a private nested class, and there is only one caller elsewhere in the containing class. We just need to make sure this is right, and there's no use checking at runtime. I was going to add a comment saying "systemStub must be non-null" but then I realized Hey! That's what assert statements are for. Rmid creation always goes through this path, and this is done repeatedly by the tests. Tests are run with assertions enabled so I think we're well covered here. s'marks From eric.mccorkle at oracle.com Thu Jan 30 19:28:02 2014 From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com) Date: Thu, 30 Jan 2014 19:28:02 +0000 Subject: hg: jdk8/tl/nashorn: 8032681: Issues with Nashorn Message-ID: <20140130192804.0C5A1628D4@hg.openjdk.java.net> Changeset: 11b83c913cca Author: attila Date: 2014-01-30 20:14 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/11b83c913cca 8032681: Issues with Nashorn Reviewed-by: ahgross, jlaskey, sundar + src/jdk/internal/dynalink/linker/GuardedTypeConversion.java ! src/jdk/internal/dynalink/linker/GuardingTypeConverterFactory.java ! src/jdk/internal/dynalink/support/LinkerServicesImpl.java ! src/jdk/internal/dynalink/support/TypeConverterFactory.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/objects/NativeJavaImporter.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/NativeJavaPackage.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/linker/AdaptationResult.java ! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterClassLoader.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterServices.java ! src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties ! test/script/basic/JDK-8014647.js ! test/script/basic/JDK-8014647.js.EXPECTED ! test/script/basic/javaclassoverrides.js ! test/script/basic/javaclassoverrides.js.EXPECTED ! test/script/sandbox/javaextend.js ! test/script/sandbox/javaextend.js.EXPECTED ! test/src/jdk/nashorn/api/scripting/ScriptEngineSecurityTest.java + test/src/jdk/nashorn/test/models/ClassWithFinalFinalizer.java + test/src/jdk/nashorn/test/models/ClassWithInheritedFinalFinalizer.java From stuart.marks at oracle.com Thu Jan 30 22:02:38 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 30 Jan 2014 14:02:38 -0800 Subject: RFR(s): 8023541 Race condition in rmid initialization In-Reply-To: <2C3EDEE3-BFF2-4A39-BF90-2EC023D3BEEC@oracle.com> References: <52E8A4DF.4010804@oracle.com> <52E8D654.4010103@gmail.com> <52E9BF93.5040200@oracle.com> <2C3EDEE3-BFF2-4A39-BF90-2EC023D3BEEC@oracle.com> Message-ID: <52EACBFE.5010401@oracle.com> On 1/30/14 3:13 AM, Paul Sandoz wrote: > On Jan 30, 2014, at 3:57 AM, Stuart Marks wrote: >> >> Then, awaitInitialized seems straightforward until you see that the >> condition is waiting for the value of a final variable to change! JLS sec >> 17.5 [1] allows all sorts of optimizations for final fields.... > > I think you have done the right thing in the latest webrev, even though i > suspect the runtime does not fully optimize final fields as constants (since > it is still possible to update final fields, e.g. see System.out). It might not optimize final fields now (I tried running a test with several JVM options, but I'm sure there are ones I haven't tried) so things do seem to work. However, I couldn't convince myself that a *future* optimization wouldn't cause a problem. I envisioned either a protracted email discussion/argument or a hairy debugging session. At that point I decided to remove final. :-) (I'm reminded of the test failures introduced by more-aggressive GC of narrowly-scoped local variables.) > It should not be this hard to reason about this stuff, right? > > Hopefully updates to the JMM will make this easier to grok, even though this > is a naughty case. Maybe. I'd guess that the new JMM will stick to covering well-behaved programs (e.g. ones that adhere to safe publication). The difficulty with issues like this one is that once publication has occurred unsafely, we have to figure out how to drag it back into the safe area. There are probably too many ways to write unsafe programs for the JMM to cover them in a simple fashion. s'marks From henry.jen at oracle.com Thu Jan 30 23:49:46 2014 From: henry.jen at oracle.com (Henry Jen) Date: Thu, 30 Jan 2014 15:49:46 -0800 Subject: StringJoiner: detect or fix delimiter collision? In-Reply-To: <0F878BF8-2179-49F4-ADF0-95ECBE4FE727@bluewin.ch> References: <51673A45.8060908@oracle.com> <1374608627412-145039.post@n7.nabble.com> <52218FE6.7000804@bluewin.ch> <7916219F-E651-4939-BFB2-7D7CC38C9EEF@bluewin.ch> <5ACEEEB3-A1D3-4F45-9D78-FDFE567A65B0@bluewin.ch> <54010BC7-BDB8-4471-AC2F-20C9449FB85B@oracle.com> <0F878BF8-2179-49F4-ADF0-95ECBE4FE727@bluewin.ch> Message-ID: <52EAE51A.8080104@oracle.com> On 01/27/2014 12:31 PM, Philip Hodges wrote: > I did not predict that it would be a "sprintf". It's not going to be consistently misused anything like so frequently. > I compared it to the unescaped XML generation antipattern. > > I have not seen any technical justifications whatsoever so far, just inexplicable enthusiasm. > > It is like giving young drivers a faster car with no seat belts. > As Mike had said, delimiter collision is a valid concern, and I think your metaphore is quite vivid. Anyhow, there is need for fast and simply join operation, and this is what JDK is intend to provide. Nothing prohibit developer to - choose a better delimiter for the data - escape the element before sending to joiner Since we expect more complicate use case is more likely to be used in stream API, such escaping can be easily done by adding a map step. elements.stream() .map(escapeFunction) .collect(joining()) Cheers, Henry From vladimir.x.ivanov at oracle.com Fri Jan 31 00:58:49 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 31 Jan 2014 04:58:49 +0400 Subject: [8] RFR (S): 8033278: Missed access checks for Lookup.unreflect* after 8032585 Message-ID: <52EAF549.4070604@oracle.com> http://cr.openjdk.java.net/~vlivanov/8033278/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8033278 The fix for 8032585 [1] introduced a regression: in some cases access check on a reference class is omitted. The fix is to ensure that access check on a reference class is always performed. Testing: regression test, jdk/test/java/lang/invoke/, jdk/test/java/util/stream, vm.defmeth.testlist, vm.mlvm.testlist, nashorn (unit tests, octane), groovy Thanks! Best regards, Vladimir Ivanov [1] http://cr.openjdk.java.net/~vlivanov/8032585/webrev.00/ From tristan.yan at oracle.com Fri Jan 31 08:36:56 2014 From: tristan.yan at oracle.com (Tristan Yan) Date: Fri, 31 Jan 2014 16:36:56 +0800 Subject: RFR: JDK-8032050: TEST_BUG: java/rmi/activation/Activatable/shutdownGracefully/ShutdownGracefully.java fails intermittently In-Reply-To: <52E8AADE.6000300@oracle.com> References: <52E20974.7060706@oracle.com> <52E31F53.3070702@oracle.com> <52E4959C.3020907@oracle.com> <52E8AADE.6000300@oracle.com> Message-ID: <52EB60A8.7070307@oracle.com> Thank you for fixing JDK-8023541. Then I leave ActivationLibrary.java for now. I still did some clean up following your suggestion. 1. I changed waitFor(long timeout) method, this method is going to use code like Process.waitFor(timeout, unit). This can be backported to JDK7. Also exitValue is kept as a return value. For making sure there is no Pipe leak, a cleanup thread will start when timeout happens. 2. Change in ShutdownGracefully is a little tricky. I think we should just destroy JVM once exception is thrown. So I move the wait logic into try block instead keep them in finally block. Can you receive it again. http://cr.openjdk.java.net/~tyan/JDK-8032050/webrev.02/ Thank you Tristan On 01/29/2014 03:16 PM, Stuart Marks wrote: > Hi Tristan, > > I don't want to put the workaround into > ActivationLibrary.rmidRunning() for a null return from the lookup, > because this is only a workaround for an actual bug in rmid > initialization. See the review I just posted for JDK-8023541. > > Adding JavaVM.waitFor(timeout) is something that would be useful in > general, but it needs to be handled carefully. It uses the new > Process.waitFor(timeout, unit) which is new in Java SE 8; this makes > backporting to 7 more complicated. Not clear whether we'll do so, but > I don't want to forclose the opportunity without discussion. It's also > not clear how one can get the vm's exit status after JavaVM.waitFor() > has returned true. With the Process API it's possible simply to call > waitFor() or exitValue(). With JavaVM, a new API needs to be created, > or the rule has to be established that one must call JavaVM.waitFor() > to collect the exit status as well as to close the pipes from the > subprocess. If JavaVM.waitFor(timeout, unit) is called without > subsequently calling JavaVM.waitFor(), the pipes are leaked. > > In ShutdownGracefully.java, the finally-block needs to check to see if > rmid is still running, and if it is, to shut it down. Simply calling > waitFor(timeout, unit) isn't sufficient, because if the rmid process > is still running, it will be left running. > > The straightforward approach would be to call > ActivationLibrary.rmidRunning() to test if it's still running. > Unfortunately this isn't quite right, because rmidRunning() has a > timeout loop in it -- which should probably be removed. (I think > there's a bug for this.) Another approach would be simply to call > rmid.destroy(). This calls rmid's shutdown() method first, which is > reasonable, but I'm not sure it kills the process if that fails. In > any case, this already has a timeout loop waiting for the process to > die, so ShutdownGracefully.java needn't use a new waitFor(timeout, > unit) call. > > Removing the commented-out code that starts with "no longer needed" is > good, and removing the ShutdownDetectThread is also good, since that's > unnecessary. > > There are some more cleanups I have in mind here but I'd like to see a > revised webrev before proceeding. > > Thanks, > > s'marks > > On 1/25/14 8:57 PM, Tristan Yan wrote: >> Hi Stuart >> Thank you for your review and suggestion. >> Yes, since this failure mode is very hard to be reproduced. I guess >> it's make sense to do some hack. And I also noticed in >> ActivationLibrary.rmidRunning. It does try to look up >> ActivationSystem but doesn't check if it's null. So I add the logic >> to make sure we will look up the non-null ActivationSystem. Also I >> did some cleanup if you don't mind. Add a waitFor(long timeout, >> TimeUnit unit) for JavaVM. Which we can have a better waitFor control. >> I appreciate you can review the code again. >> http://cr.openjdk.java.net/~tyan/JDK-8032050/webrev.01/ >> Thank you >> Tristan >> >> >> On 01/25/2014 10:20 AM, Stuart Marks wrote: >>> On 1/23/14 10:34 PM, Tristan Yan wrote: >>>> Hi All >>>> Could you review the bug fix for JDK-8032050. >>>> >>>> http://cr.openjdk.java.net/~tyan/JDK-8032050/webrev.00/ >>>> >>>> Description: >>>> This rare happened failure caused because when RMID starts. It >>>> don't guarantee >>>> sun.rmi.server.Activation.startActivation finishes. >>>> Fix by adding a iterative getSystem with a 5 seconds timeout. >>> >>> Hi Tristan, >>> >>> Adding a timing/retry loop into this test isn't the correct approach >>> for fixing this test. >>> >>> The timing loop isn't necessary because there is already a timing >>> loop in RMID.start() in the RMI test library. (There's another >>> timing loop in ActivationLibrary.rmidRunning() which should probably >>> be removed.) So the intent of this library call is that it start >>> rmid and wait for it to become ready. That logic doesn't need to be >>> added to the test. >>> >>> In the bug report JDK-8032050 you had mentioned that the >>> NullPointerException was suspicious. You're right! I took a look and >>> it seemed like it was related to JDK-8023541, and I added a note to >>> this effect to the bug report. The problem here is that rmid can >>> come up and transiently return null instead of the stub of the >>> activation system. That's what JDK-8023541 covers. I think that rmid >>> itself needs to be fixed, though modifying the timing loop in the >>> RMI test library to wait for rmid to come up *and* for the lookup to >>> return non-null is an easy way to fix the problem. (Or at least >>> cover it up.) >>> >>> The next step in the analysis is to determine, given that >>> ActivationLibrary.getSystem can sometimes return null, whether this >>> has actually caused this test failure. This is pretty easy to >>> determine; just hack in a line "system = null" in the right place >>> and run the test. I've done this, and the test times out and the >>> output log is pretty much identical to the one in the bug report. (I >>> recommend you try this yourself.) So I think it's fairly safe to say >>> that the problem in JDK-8023541 has caused the failure listed in >>> JDK-8032050. >>> >>> I can see a couple ways to proceed here. One way is just to close >>> this out as a duplicate of JDK-8023541 since that bug caused this >>> failure. >>> >>> Another is that this test could use some cleaning up. This bug >>> certainly covers a failure, but the messages emitted are confusing >>> and in some cases completely wrong. For example, the "rmid has >>> shutdown" message at line 180 is incorrect, because in this case >>> rmid is still running and the wait() call has timed out. Most of the >>> code here can be replaced with calls to various bits of the RMI test >>> library. There are a bunch of other things in this test that could >>> be cleaned up as well. >>> >>> It's up to you how you'd like to proceed. >>> >>> s'marks >> > From paul.sandoz at oracle.com Fri Jan 31 09:31:10 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 31 Jan 2014 10:31:10 +0100 Subject: [8] RFR (S): 8033278: Missed access checks for Lookup.unreflect* after 8032585 In-Reply-To: <52EAF549.4070604@oracle.com> References: <52EAF549.4070604@oracle.com> Message-ID: On Jan 31, 2014, at 1:58 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8033278/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8033278 > > The fix for 8032585 [1] introduced a regression: in some cases access check on a reference class is omitted. > > The fix is to ensure that access check on a reference class is always performed. > 104 case PROTECTED: 105 if ((allowedModes & PROTECTED_OR_PACKAGE_ALLOWED) != 0 && 106 isSamePackage(defc, lookupClass)) 107 return true; 108 if ((allowedModes & PROTECTED) == 0) 109 return false; 110 if ((mods & STATIC) != 0 && 111 !isRelatedClass(refc, lookupClass)) 112 return false; 113 if ((allowedModes & PROTECTED) != 0 && 114 isSuperClass(defc, lookupClass)) 115 return true; 116 return false; Can lines 113 to 116 be reduced to: return isSuperClass(defc, lookupClass)); ? The shuffling of the code looks correct (and simpler), but i am fuzzy on the nuances of access control. Paul. > Testing: regression test, jdk/test/java/lang/invoke/, jdk/test/java/util/stream, vm.defmeth.testlist, vm.mlvm.testlist, nashorn (unit tests, octane), groovy > > Thanks! > > Best regards, > Vladimir Ivanov > > [1] http://cr.openjdk.java.net/~vlivanov/8032585/webrev.00/ From paul.sandoz at oracle.com Fri Jan 31 11:24:09 2014 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Fri, 31 Jan 2014 11:24:09 +0000 Subject: hg: jdk8/tl/jdk: 4 new changesets Message-ID: <20140131112700.AFEF362911@hg.openjdk.java.net> Changeset: 9f098aed44c0 Author: anazarov Date: 2014-01-31 12:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9f098aed44c0 8032025: Update repeating annotations demo Reviewed-by: jfranck + src/share/sample/annotations/DependencyChecker/PluginChecker/src/checker/Device.java + src/share/sample/annotations/DependencyChecker/PluginChecker/src/checker/Kettle.xml + src/share/sample/annotations/DependencyChecker/PluginChecker/src/checker/Module.java + src/share/sample/annotations/DependencyChecker/PluginChecker/src/checker/PluginChecker.java + src/share/sample/annotations/DependencyChecker/PluginChecker/src/checker/Require.java + src/share/sample/annotations/DependencyChecker/PluginChecker/src/checker/RequireContainer.java + src/share/sample/annotations/DependencyChecker/Plugins/src/plugins/BoilerPlugin.java + src/share/sample/annotations/DependencyChecker/Plugins/src/plugins/ExtendedBoilerPlugin.java + src/share/sample/annotations/DependencyChecker/Plugins/src/plugins/TimerPlugin.java + src/share/sample/annotations/Validator/src/PositiveIntegerSupplier.java + src/share/sample/annotations/Validator/src/SupplierValidator.java + src/share/sample/annotations/Validator/src/Validate.java + src/share/sample/annotations/Validator/src/Validator.java + src/share/sample/annotations/index.html Changeset: f72a8df6a2ed Author: anazarov Date: 2014-01-31 12:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f72a8df6a2ed 8031650: Update bulk operation demo Reviewed-by: psandoz, mduigou + src/share/sample/lambda/BulkDataOperations/index.html + src/share/sample/lambda/BulkDataOperations/src/CSVProcessor.java + src/share/sample/lambda/BulkDataOperations/src/Grep.java + src/share/sample/lambda/BulkDataOperations/src/PasswordGenerator.java + src/share/sample/lambda/BulkDataOperations/src/WC.java Changeset: 4574011c1689 Author: anazarov Date: 2014-01-31 12:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4574011c1689 8032020: Update try-with-resources demo Reviewed-by: darcy, alanb, smarks + src/share/sample/try-with-resources/index.html + src/share/sample/try-with-resources/src/CustomAutoCloseableSample.java + src/share/sample/try-with-resources/src/Unzip.java + src/share/sample/try-with-resources/src/ZipCat.java Changeset: a4f68fc5f353 Author: psandoz Date: 2014-01-31 12:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a4f68fc5f353 8032056: Create demo to illustrate new practices of the default methods usage Reviewed-by: briangoetz, rfield, psandoz Contributed-by: taras.ledkov at oracle.com + src/share/sample/lambda/DefaultMethods/ArrayIterator.java + src/share/sample/lambda/DefaultMethods/DiamondInheritance.java + src/share/sample/lambda/DefaultMethods/Inheritance.java + src/share/sample/lambda/DefaultMethods/MixIn.java + src/share/sample/lambda/DefaultMethods/Reflection.java + src/share/sample/lambda/DefaultMethods/SimplestUsage.java From Ulf.Zibis at CoSoCo.de Fri Jan 31 13:27:07 2014 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Fri, 31 Jan 2014 14:27:07 +0100 Subject: StringJoiner: detect or fix delimiter collision? In-Reply-To: <5ACEEEB3-A1D3-4F45-9D78-FDFE567A65B0@bluewin.ch> References: <51673A45.8060908@oracle.com> <1374608627412-145039.post@n7.nabble.com> <52218FE6.7000804@bluewin.ch> <7916219F-E651-4939-BFB2-7D7CC38C9EEF@bluewin.ch> <5ACEEEB3-A1D3-4F45-9D78-FDFE567A65B0@bluewin.ch> Message-ID: <52EBA4AB.60100@CoSoCo.de> Hi Philip, Am 27.01.2014 02:12, schrieb Philip Hodges: > Please please please drop StringJoiner from Java 1.8 before it is too late. > I have not seen any technical justifications whatsoever so far, just inexplicable enthusiasm. > > It is like giving young drivers a faster car with no seat belts. +++1 I'm also with you with all your arguments against this API. > I'm really sorry I couldn't carry on arguing the case before August. As a minority, I only have one person's quota of energy. I will try to get some more people to look at it. You are not alone. Although I missed the delimiter/escaping problem those days, it was April 18 I posted my different concerns about StringJoiner in this list: <<<<<<<<<< I'm wondering, that StringJoiner has some logic for pre/suffix, but nothing to loop the elements themselves To me, StringJoiner is a useless complicated box around StringBuilder, and imagine, someone needs thread-safety. It also slows down performance, as it needs additional instances and additional class to be loaded (critical at VM startup). Instead please add to StringBuilder and StringBuffer: append(CharSequence... elements); append(char delimiter, CharSequence... elements); append(char delimiter, Iterable elements); cut(int len); // removes len chars at the end of the sequence optional: append(CharSequence delimiter, CharSequence... elements); append(CharSequence delimiter, Iterable elements); For performance reasons, append() should always append the trailing delimiter, which could be cut at the end. It's questionable, if class string needs a static (=no relation to an existing string in contrast to non-static split()) join method, as it seduces to "[" + String.join(...) + "]" which needs some effort from javac side to optimize to a single StringBuilder task. IMO we better had StringBuilder.join(...), so javac could easily optimize to: new StringBuilder().append('[').append(',', someStrings).cut(1).append(']').toString() THe current proposed implementation has: 1 class with 7 methods 2 additional methods in String To cover the same functionality, above approach basically only needs 2 additional methods in StringBuilder, has better performance, so what is complicated on that? >>>>>>>>>> Am 27.01.2014 18:44, schrieb Mike Duigou: > The reception we've seen thus far for StringJoiner has been otherwise exclusively enthusiastic and positive. Where are those people, they don't speak up in this list, seem to don't know about the performance issues and the traps which are mentioned here. We don't know how they will deal with the problems in practical if they occur in real world. On the other hand, the "doomsayers" also could refer to others out there which see no win in this API. -Ulf From Paul.Sandoz at oracle.com Fri Jan 31 13:32:36 2014 From: Paul.Sandoz at oracle.com (Paul Sandoz) Date: Fri, 31 Jan 2014 14:32:36 +0100 Subject: RFR(s): 8023541 Race condition in rmid initialization In-Reply-To: <52EACBFE.5010401@oracle.com> References: <52E8A4DF.4010804@oracle.com> <52E8D654.4010103@gmail.com> <52E9BF93.5040200@oracle.com> <2C3EDEE3-BFF2-4A39-BF90-2EC023D3BEEC@oracle.com> <52EACBFE.5010401@oracle.com> Message-ID: <2D260BC1-F11C-4247-B706-E9AB56613B79@oracle.com> On Jan 30, 2014, at 11:02 PM, Stuart Marks wrote: > Maybe. I'd guess that the new JMM will stick to covering well-behaved programs (e.g. ones that adhere to safe publication). The difficulty with issues like this one is that once publication has occurred unsafely, we have to figure out how to drag it back into the safe area. There are probably too many ways to write unsafe programs for the JMM to cover them in a simple fashion. > For your delectation: http://www.cliffc.org/blog/2011/10/17/writing-to-final-fields-via-reflection/ http://www.cliffc.org/blog/2011/10/27/final-fields-part-2/ Paul. From dl at cs.oswego.edu Fri Jan 31 13:49:41 2014 From: dl at cs.oswego.edu (Doug Lea) Date: Fri, 31 Jan 2014 08:49:41 -0500 Subject: RFR(s): 8023541 Race condition in rmid initialization In-Reply-To: <2D260BC1-F11C-4247-B706-E9AB56613B79@oracle.com> References: <52E8A4DF.4010804@oracle.com> <52E8D654.4010103@gmail.com> <52E9BF93.5040200@oracle.com> <2C3EDEE3-BFF2-4A39-BF90-2EC023D3BEEC@oracle.com> <52EACBFE.5010401@oracle.com> <2D260BC1-F11C-4247-B706-E9AB56613B79@oracle.com> Message-ID: <52EBA9F5.7070807@cs.oswego.edu> On 01/31/2014 08:32 AM, Paul Sandoz wrote: > On Jan 30, 2014, at 11:02 PM, Stuart Marks wrote: >> Maybe. I'd guess that the new JMM will stick to covering well-behaved programs (e.g. ones that adhere to safe publication). The difficulty with issues like this one is that once publication has occurred unsafely, we have to figure out how to drag it back into the safe area. There are probably too many ways to write unsafe programs for the JMM to cover them in a simple fashion. >> > > For your delectation: > > http://www.cliffc.org/blog/2011/10/17/writing-to-final-fields-via-reflection/ > > http://www.cliffc.org/blog/2011/10/27/final-fields-part-2/ > Simplifying final field rules is definitely on the agenda for JMM9 revisions. My guess is that the JMM per se will specify only the memory ordering effects, and for the most part leave the question of when reloads are suppressed as a JVM quality of implementation issue. While I'm at it, I think Stuart's current approach seems fine. Whenever you have no choice except to leak/publish in a constructor, use volatiles to track initialization. -Doug From vladimir.x.ivanov at oracle.com Fri Jan 31 14:21:09 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 31 Jan 2014 18:21:09 +0400 Subject: [8] RFR (S): 8033278: Missed access checks for Lookup.unreflect* after 8032585 In-Reply-To: References: <52EAF549.4070604@oracle.com> Message-ID: <52EBB155.40007@oracle.com> Paul, The transformation you suggest is equivalent, but I reluctant to apply it. IMO, it doesn't add much value and current version is easier to read. Considering the current level of complexity in VA.isMemberAccessible I don't want to increase it even further :-) Best regards, Vladimir Ivanov PS: thanks for looking into the fix. On 1/31/14 1:31 PM, Paul Sandoz wrote: > > On Jan 31, 2014, at 1:58 AM, Vladimir Ivanov wrote: > >> http://cr.openjdk.java.net/~vlivanov/8033278/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8033278 >> >> The fix for 8032585 [1] introduced a regression: in some cases access check on a reference class is omitted. >> >> The fix is to ensure that access check on a reference class is always performed. >> > > 104 case PROTECTED: > 105 if ((allowedModes & PROTECTED_OR_PACKAGE_ALLOWED) != 0 && > 106 isSamePackage(defc, lookupClass)) > 107 return true; > 108 if ((allowedModes & PROTECTED) == 0) > 109 return false; > 110 if ((mods & STATIC) != 0 && > 111 !isRelatedClass(refc, lookupClass)) > 112 return false; > 113 if ((allowedModes & PROTECTED) != 0 && > 114 isSuperClass(defc, lookupClass)) > 115 return true; > 116 return false; > > Can lines 113 to 116 be reduced to: > > return isSuperClass(defc, lookupClass)); > > ? > > The shuffling of the code looks correct (and simpler), but i am fuzzy on the nuances of access control. > > Paul. > >> Testing: regression test, jdk/test/java/lang/invoke/, jdk/test/java/util/stream, vm.defmeth.testlist, vm.mlvm.testlist, nashorn (unit tests, octane), groovy >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov >> >> [1] http://cr.openjdk.java.net/~vlivanov/8032585/webrev.00/ > From paul.sandoz at oracle.com Fri Jan 31 14:44:53 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 31 Jan 2014 15:44:53 +0100 Subject: [8] RFR (S): 8033278: Missed access checks for Lookup.unreflect* after 8032585 In-Reply-To: <52EBB155.40007@oracle.com> References: <52EAF549.4070604@oracle.com> <52EBB155.40007@oracle.com> Message-ID: On Jan 31, 2014, at 3:21 PM, Vladimir Ivanov wrote: > Paul, > > The transformation you suggest is equivalent, but I reluctant to apply it. IMO, it doesn't add much value and current version is easier to read. OK, i guess we will just have to agree to disagree on that small point as i think the opposite :-) but I don't wanna block the review. Paul. > Considering the current level of complexity in VA.isMemberAccessible I don't want to increase it even further :-) > > Best regards, > Vladimir Ivanov > > PS: thanks for looking into the fix. From chris.hegarty at oracle.com Fri Jan 31 16:23:37 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 31 Jan 2014 16:23:37 +0000 Subject: RFR [9] 8011645: CopyOnWriteArrayList.COWSubList.subList does not validate range properly Message-ID: <52EBCE09.1030609@oracle.com> Trivial change to CopyOnWriteArrayList.COWSubList.subList to catch the case where the fromIndex is greater that the toIndex. http://cr.openjdk.java.net/~chegar/8011645/webrev.00/webrev/ -Chris. From paul.sandoz at oracle.com Fri Jan 31 17:05:48 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 31 Jan 2014 18:05:48 +0100 Subject: RFR [9] 8011645: CopyOnWriteArrayList.COWSubList.subList does not validate range properly In-Reply-To: <52EBCE09.1030609@oracle.com> References: <52EBCE09.1030609@oracle.com> Message-ID: On Jan 31, 2014, at 5:23 PM, Chris Hegarty wrote: > Trivial change to CopyOnWriteArrayList.COWSubList.subList to catch the case where the fromIndex is greater that the toIndex. > > http://cr.openjdk.java.net/~chegar/8011645/webrev.00/webrev/ > Looks ok to me. -- Shame it's awkward to share this code from ArrayList: static void subListRangeCheck(int fromIndex, int toIndex, int size) { if (fromIndex < 0) throw new IndexOutOfBoundsException("fromIndex = " + fromIndex); if (toIndex > size) throw new IndexOutOfBoundsException("toIndex = " + toIndex); if (fromIndex > toIndex) throw new IllegalArgumentException("fromIndex(" + fromIndex + ") > toIndex(" + toIndex + ")"); } Paul. From eric.mccorkle at oracle.com Fri Jan 31 17:13:33 2014 From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com) Date: Fri, 31 Jan 2014 17:13:33 +0000 Subject: hg: jdk8/tl/jdk: 8033278: Missed access checks for Lookup.unreflect* after 8032585 Message-ID: <20140131171358.56F0A62926@hg.openjdk.java.net> Changeset: f684c9773858 Author: vlivanov Date: 2014-01-31 21:07 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f684c9773858 8033278: Missed access checks for Lookup.unreflect* after 8032585 Reviewed-by: jrose, twisti ! src/share/classes/sun/invoke/util/VerifyAccess.java ! test/java/lang/invoke/ProtectedMemberDifferentPackage/Test.java ! test/java/lang/invoke/ProtectedMemberDifferentPackage/p1/T2.java ! test/java/lang/invoke/ProtectedMemberDifferentPackage/p2/T3.java From martinrb at google.com Fri Jan 31 17:30:57 2014 From: martinrb at google.com (Martin Buchholz) Date: Fri, 31 Jan 2014 09:30:57 -0800 Subject: RFR [9] 8011645: CopyOnWriteArrayList.COWSubList.subList does not validate range properly In-Reply-To: <52EBCE09.1030609@oracle.com> References: <52EBCE09.1030609@oracle.com> Message-ID: jsr166 CVS fix in progress. On Fri, Jan 31, 2014 at 8:23 AM, Chris Hegarty wrote: > Trivial change to CopyOnWriteArrayList.COWSubList.subList to catch the > case where the fromIndex is greater that the toIndex. > > http://cr.openjdk.java.net/~chegar/8011645/webrev.00/webrev/ > > -Chris. > From martinrb at google.com Fri Jan 31 18:01:27 2014 From: martinrb at google.com (Martin Buchholz) Date: Fri, 31 Jan 2014 10:01:27 -0800 Subject: RFR [9] 8011645: CopyOnWriteArrayList.COWSubList.subList does not validate range properly In-Reply-To: <52EBCE09.1030609@oracle.com> References: <52EBCE09.1030609@oracle.com> Message-ID: jsr166 CVS is now updated with this fix, and also adds some missing tck tests. Index: src/jdk7/java/util/concurrent/CopyOnWriteArrayList.java =================================================================== RCS file: /export/home/jsr166/jsr166/jsr166/src/jdk7/java/util/concurrent/CopyOnWriteArrayList.java,v retrieving revision 1.6 diff -u -r1.6 CopyOnWriteArrayList.java --- src/jdk7/java/util/concurrent/CopyOnWriteArrayList.java 4 Nov 2013 00:00:39 -0000 1.6 +++ src/jdk7/java/util/concurrent/CopyOnWriteArrayList.java 31 Jan 2014 17:50:14 -0000 @@ -1232,7 +1232,7 @@ lock.lock(); try { checkForComodification(); - if (fromIndex < 0 || toIndex > size) + if (fromIndex < 0 || toIndex > size || fromIndex > toIndex) throw new IndexOutOfBoundsException(); return new COWSubList(l, fromIndex + offset, toIndex + offset); Index: src/main/java/util/concurrent/CopyOnWriteArrayList.java =================================================================== RCS file: /export/home/jsr166/jsr166/jsr166/src/main/java/util/concurrent/CopyOnWriteArrayList.java,v retrieving revision 1.114 diff -u -r1.114 CopyOnWriteArrayList.java --- src/main/java/util/concurrent/CopyOnWriteArrayList.java 4 Nov 2013 00:00:39 -0000 1.114 +++ src/main/java/util/concurrent/CopyOnWriteArrayList.java 31 Jan 2014 17:50:15 -0000 @@ -1371,7 +1371,7 @@ lock.lock(); try { checkForComodification(); - if (fromIndex < 0 || toIndex > size) + if (fromIndex < 0 || toIndex > size || fromIndex > toIndex) throw new IndexOutOfBoundsException(); return new COWSubList(l, fromIndex + offset, toIndex + offset); Index: src/test/tck/CopyOnWriteArrayListTest.java =================================================================== RCS file: /export/home/jsr166/jsr166/jsr166/src/test/tck/CopyOnWriteArrayListTest.java,v retrieving revision 1.29 diff -u -r1.29 CopyOnWriteArrayListTest.java --- src/test/tck/CopyOnWriteArrayListTest.java 30 May 2013 03:28:55 -0000 1.29 +++ src/test/tck/CopyOnWriteArrayListTest.java 31 Jan 2014 17:50:15 -0000 @@ -500,10 +500,10 @@ * can not store the objects inside the list */ public void testToArray_ArrayStoreException() { + CopyOnWriteArrayList c = new CopyOnWriteArrayList(); + c.add("zfasdfsdf"); + c.add("asdadasd"); try { - CopyOnWriteArrayList c = new CopyOnWriteArrayList(); - c.add("zfasdfsdf"); - c.add("asdadasd"); c.toArray(new Long[5]); shouldThrow(); } catch (ArrayStoreException success) {} @@ -513,167 +513,196 @@ * get throws an IndexOutOfBoundsException on a negative index */ public void testGet1_IndexOutOfBoundsException() { - try { - CopyOnWriteArrayList c = new CopyOnWriteArrayList(); - c.get(-1); - shouldThrow(); - } catch (IndexOutOfBoundsException success) {} + CopyOnWriteArrayList c = populatedArray(5); + List[] lists = { c, c.subList(1, c.size() - 1) }; + for (List list : lists) { + try { + list.get(-1); + shouldThrow(); + } catch (IndexOutOfBoundsException success) {} + } } /** * get throws an IndexOutOfBoundsException on a too high index */ public void testGet2_IndexOutOfBoundsException() { - try { - CopyOnWriteArrayList c = new CopyOnWriteArrayList(); - c.add("asdasd"); - c.add("asdad"); - c.get(100); - shouldThrow(); - } catch (IndexOutOfBoundsException success) {} + CopyOnWriteArrayList c = populatedArray(5); + List[] lists = { c, c.subList(1, c.size() - 1) }; + for (List list : lists) { + try { + list.get(list.size()); + shouldThrow(); + } catch (IndexOutOfBoundsException success) {} + } } /** * set throws an IndexOutOfBoundsException on a negative index */ public void testSet1_IndexOutOfBoundsException() { - try { - CopyOnWriteArrayList c = new CopyOnWriteArrayList(); - c.set(-1,"qwerty"); - shouldThrow(); - } catch (IndexOutOfBoundsException success) {} + CopyOnWriteArrayList c = populatedArray(5); + List[] lists = { c, c.subList(1, c.size() - 1) }; + for (List list : lists) { + try { + list.set(-1, "qwerty"); + shouldThrow(); + } catch (IndexOutOfBoundsException success) {} + } } /** * set throws an IndexOutOfBoundsException on a too high index */ public void testSet2() { - try { - CopyOnWriteArrayList c = new CopyOnWriteArrayList(); - c.add("asdasd"); - c.add("asdad"); - c.set(100, "qwerty"); - shouldThrow(); - } catch (IndexOutOfBoundsException success) {} + CopyOnWriteArrayList c = populatedArray(5); + List[] lists = { c, c.subList(1, c.size() - 1) }; + for (List list : lists) { + try { + list.set(list.size(), "qwerty"); + shouldThrow(); + } catch (IndexOutOfBoundsException success) {} + } } /** * add throws an IndexOutOfBoundsException on a negative index */ public void testAdd1_IndexOutOfBoundsException() { - try { - CopyOnWriteArrayList c = new CopyOnWriteArrayList(); - c.add(-1,"qwerty"); - shouldThrow(); - } catch (IndexOutOfBoundsException success) {} + CopyOnWriteArrayList c = populatedArray(5); + List[] lists = { c, c.subList(1, c.size() - 1) }; + for (List list : lists) { + try { + list.add(-1,"qwerty"); + shouldThrow(); + } catch (IndexOutOfBoundsException success) {} + } } /** * add throws an IndexOutOfBoundsException on a too high index */ public void testAdd2_IndexOutOfBoundsException() { - try { - CopyOnWriteArrayList c = new CopyOnWriteArrayList(); - c.add("asdasd"); - c.add("asdasdasd"); - c.add(100, "qwerty"); - shouldThrow(); - } catch (IndexOutOfBoundsException success) {} + CopyOnWriteArrayList c = populatedArray(5); + List[] lists = { c, c.subList(1, c.size() - 1) }; + for (List list : lists) { + try { + list.add(list.size() + 1, "qwerty"); + shouldThrow(); + } catch (IndexOutOfBoundsException success) {} + } } /** * remove throws an IndexOutOfBoundsException on a negative index */ public void testRemove1_IndexOutOfBounds() { - try { - CopyOnWriteArrayList c = new CopyOnWriteArrayList(); - c.remove(-1); - shouldThrow(); - } catch (IndexOutOfBoundsException success) {} + CopyOnWriteArrayList c = populatedArray(5); + List[] lists = { c, c.subList(1, c.size() - 1) }; + for (List list : lists) { + try { + list.remove(-1); + shouldThrow(); + } catch (IndexOutOfBoundsException success) {} + } } /** * remove throws an IndexOutOfBoundsException on a too high index */ public void testRemove2_IndexOutOfBounds() { - try { - CopyOnWriteArrayList c = new CopyOnWriteArrayList(); - c.add("asdasd"); - c.add("adasdasd"); - c.remove(100); - shouldThrow(); - } catch (IndexOutOfBoundsException success) {} + CopyOnWriteArrayList c = populatedArray(5); + List[] lists = { c, c.subList(1, c.size() - 1) }; + for (List list : lists) { + try { + list.remove(list.size()); + shouldThrow(); + } catch (IndexOutOfBoundsException success) {} + } } /** * addAll throws an IndexOutOfBoundsException on a negative index */ public void testAddAll1_IndexOutOfBoundsException() { - try { - CopyOnWriteArrayList c = new CopyOnWriteArrayList(); - c.addAll(-1,new LinkedList()); - shouldThrow(); - } catch (IndexOutOfBoundsException success) {} + CopyOnWriteArrayList c = populatedArray(5); + List[] lists = { c, c.subList(1, c.size() - 1) }; + for (List list : lists) { + try { + list.addAll(-1,new LinkedList()); + shouldThrow(); + } catch (IndexOutOfBoundsException success) {} + } } /** * addAll throws an IndexOutOfBoundsException on a too high index */ public void testAddAll2_IndexOutOfBoundsException() { - try { - CopyOnWriteArrayList c = new CopyOnWriteArrayList(); - c.add("asdasd"); - c.add("asdasdasd"); - c.addAll(100, new LinkedList()); - shouldThrow(); - } catch (IndexOutOfBoundsException success) {} + CopyOnWriteArrayList c = populatedArray(5); + List[] lists = { c, c.subList(1, c.size() - 1) }; + for (List list : lists) { + try { + list.addAll(list.size() + 1, new LinkedList()); + shouldThrow(); + } catch (IndexOutOfBoundsException success) {} + } } /** * listIterator throws an IndexOutOfBoundsException on a negative index */ public void testListIterator1_IndexOutOfBoundsException() { - try { - CopyOnWriteArrayList c = new CopyOnWriteArrayList(); - c.listIterator(-1); - shouldThrow(); - } catch (IndexOutOfBoundsException success) {} + CopyOnWriteArrayList c = populatedArray(5); + List[] lists = { c, c.subList(1, c.size() - 1) }; + for (List list : lists) { + try { + list.listIterator(-1); + shouldThrow(); + } catch (IndexOutOfBoundsException success) {} + } } /** * listIterator throws an IndexOutOfBoundsException on a too high index */ public void testListIterator2_IndexOutOfBoundsException() { - try { - CopyOnWriteArrayList c = new CopyOnWriteArrayList(); - c.add("adasd"); - c.add("asdasdas"); - c.listIterator(100); - shouldThrow(); - } catch (IndexOutOfBoundsException success) {} + CopyOnWriteArrayList c = populatedArray(5); + List[] lists = { c, c.subList(1, c.size() - 1) }; + for (List list : lists) { + try { + list.listIterator(list.size() + 1); + shouldThrow(); + } catch (IndexOutOfBoundsException success) {} + } } /** * subList throws an IndexOutOfBoundsException on a negative index */ public void testSubList1_IndexOutOfBoundsException() { - try { - CopyOnWriteArrayList c = new CopyOnWriteArrayList(); - c.subList(-1,100); - shouldThrow(); - } catch (IndexOutOfBoundsException success) {} + CopyOnWriteArrayList c = populatedArray(5); + List[] lists = { c, c.subList(1, c.size() - 1) }; + for (List list : lists) { + try { + list.subList(-1, list.size()); + shouldThrow(); + } catch (IndexOutOfBoundsException success) {} + } } /** * subList throws an IndexOutOfBoundsException on a too high index */ public void testSubList2_IndexOutOfBoundsException() { - try { - CopyOnWriteArrayList c = new CopyOnWriteArrayList(); - c.add("asdasd"); - c.subList(1,100); - shouldThrow(); - } catch (IndexOutOfBoundsException success) {} + CopyOnWriteArrayList c = populatedArray(5); + List[] lists = { c, c.subList(1, c.size() - 1) }; + for (List list : lists) { + try { + list.subList(0, list.size() + 1); + shouldThrow(); + } catch (IndexOutOfBoundsException success) {} + } } /** @@ -681,11 +710,14 @@ * is lower then the first */ public void testSubList3_IndexOutOfBoundsException() { - try { - CopyOnWriteArrayList c = new CopyOnWriteArrayList(); - c.subList(3,1); - shouldThrow(); - } catch (IndexOutOfBoundsException success) {} + CopyOnWriteArrayList c = populatedArray(5); + List[] lists = { c, c.subList(1, c.size() - 1) }; + for (List list : lists) { + try { + list.subList(list.size() - 1, 1); + shouldThrow(); + } catch (IndexOutOfBoundsException success) {} + } } /** On Fri, Jan 31, 2014 at 8:23 AM, Chris Hegarty wrote: > Trivial change to CopyOnWriteArrayList.COWSubList.subList to catch the > case where the fromIndex is greater that the toIndex. > > http://cr.openjdk.java.net/~chegar/8011645/webrev.00/webrev/ > > -Chris. > From dl at cs.oswego.edu Fri Jan 31 18:07:06 2014 From: dl at cs.oswego.edu (Doug Lea) Date: Fri, 31 Jan 2014 13:07:06 -0500 Subject: RFR [9] 8011645: CopyOnWriteArrayList.COWSubList.subList does not validate range properly In-Reply-To: References: <52EBCE09.1030609@oracle.com> Message-ID: <52EBE64A.1090507@cs.oswego.edu> Thanks Martin and Chris! -Doug On 01/31/2014 01:01 PM, Martin Buchholz wrote: > jsr166 CVS is now updated with this fix, and also adds some missing tck tests. > > Index: src/jdk7/java/util/concurrent/CopyOnWriteArrayList.java > =================================================================== > RCS file: > /export/home/jsr166/jsr166/jsr166/src/jdk7/java/util/concurrent/CopyOnWriteArrayList.java,v > retrieving revision 1.6 > diff -u -r1.6 CopyOnWriteArrayList.java > --- src/jdk7/java/util/concurrent/CopyOnWriteArrayList.java4 Nov 2013 00:00:39 > -00001.6 > +++ src/jdk7/java/util/concurrent/CopyOnWriteArrayList.java31 Jan 2014 17:50:14 > -0000 > @@ -1232,7 +1232,7 @@ > lock.lock(); > try { > checkForComodification(); > - if (fromIndex < 0 || toIndex > size) > + if (fromIndex < 0 || toIndex > size || fromIndex > toIndex) > throw new IndexOutOfBoundsException(); > return new COWSubList(l, fromIndex + offset, > toIndex + offset); > Index: src/main/java/util/concurrent/CopyOnWriteArrayList.java > =================================================================== > RCS file: > /export/home/jsr166/jsr166/jsr166/src/main/java/util/concurrent/CopyOnWriteArrayList.java,v > retrieving revision 1.114 > diff -u -r1.114 CopyOnWriteArrayList.java > --- src/main/java/util/concurrent/CopyOnWriteArrayList.java4 Nov 2013 00:00:39 > -00001.114 > +++ src/main/java/util/concurrent/CopyOnWriteArrayList.java31 Jan 2014 17:50:15 > -0000 > @@ -1371,7 +1371,7 @@ > lock.lock(); > try { > checkForComodification(); > - if (fromIndex < 0 || toIndex > size) > + if (fromIndex < 0 || toIndex > size || fromIndex > toIndex) > throw new IndexOutOfBoundsException(); > return new COWSubList(l, fromIndex + offset, > toIndex + offset); > Index: src/test/tck/CopyOnWriteArrayListTest.java > =================================================================== > RCS file: > /export/home/jsr166/jsr166/jsr166/src/test/tck/CopyOnWriteArrayListTest.java,v > retrieving revision 1.29 > diff -u -r1.29 CopyOnWriteArrayListTest.java > --- src/test/tck/CopyOnWriteArrayListTest.java30 May 2013 03:28:55 -00001.29 > +++ src/test/tck/CopyOnWriteArrayListTest.java31 Jan 2014 17:50:15 -0000 > @@ -500,10 +500,10 @@ > * can not store the objects inside the list > */ > public void testToArray_ArrayStoreException() { > + CopyOnWriteArrayList c = new CopyOnWriteArrayList(); > + c.add("zfasdfsdf"); > + c.add("asdadasd"); > try { > - CopyOnWriteArrayList c = new CopyOnWriteArrayList(); > - c.add("zfasdfsdf"); > - c.add("asdadasd"); > c.toArray(new Long[5]); > shouldThrow(); > } catch (ArrayStoreException success) {} > @@ -513,167 +513,196 @@ > * get throws an IndexOutOfBoundsException on a negative index > */ > public void testGet1_IndexOutOfBoundsException() { > - try { > - CopyOnWriteArrayList c = new CopyOnWriteArrayList(); > - c.get(-1); > - shouldThrow(); > - } catch (IndexOutOfBoundsException success) {} > + CopyOnWriteArrayList c = populatedArray(5); > + List[] lists = { c, c.subList(1, c.size() - 1) }; > + for (List list : lists) { > + try { > + list.get(-1); > + shouldThrow(); > + } catch (IndexOutOfBoundsException success) {} > + } > } > /** > * get throws an IndexOutOfBoundsException on a too high index > */ > public void testGet2_IndexOutOfBoundsException() { > - try { > - CopyOnWriteArrayList c = new CopyOnWriteArrayList(); > - c.add("asdasd"); > - c.add("asdad"); > - c.get(100); > - shouldThrow(); > - } catch (IndexOutOfBoundsException success) {} > + CopyOnWriteArrayList c = populatedArray(5); > + List[] lists = { c, c.subList(1, c.size() - 1) }; > + for (List list : lists) { > + try { > + list.get(list.size()); > + shouldThrow(); > + } catch (IndexOutOfBoundsException success) {} > + } > } > /** > * set throws an IndexOutOfBoundsException on a negative index > */ > public void testSet1_IndexOutOfBoundsException() { > - try { > - CopyOnWriteArrayList c = new CopyOnWriteArrayList(); > - c.set(-1,"qwerty"); > - shouldThrow(); > - } catch (IndexOutOfBoundsException success) {} > + CopyOnWriteArrayList c = populatedArray(5); > + List[] lists = { c, c.subList(1, c.size() - 1) }; > + for (List list : lists) { > + try { > + list.set(-1, "qwerty"); > + shouldThrow(); > + } catch (IndexOutOfBoundsException success) {} > + } > } > /** > * set throws an IndexOutOfBoundsException on a too high index > */ > public void testSet2() { > - try { > - CopyOnWriteArrayList c = new CopyOnWriteArrayList(); > - c.add("asdasd"); > - c.add("asdad"); > - c.set(100, "qwerty"); > - shouldThrow(); > - } catch (IndexOutOfBoundsException success) {} > + CopyOnWriteArrayList c = populatedArray(5); > + List[] lists = { c, c.subList(1, c.size() - 1) }; > + for (List list : lists) { > + try { > + list.set(list.size(), "qwerty"); > + shouldThrow(); > + } catch (IndexOutOfBoundsException success) {} > + } > } > /** > * add throws an IndexOutOfBoundsException on a negative index > */ > public void testAdd1_IndexOutOfBoundsException() { > - try { > - CopyOnWriteArrayList c = new CopyOnWriteArrayList(); > - c.add(-1,"qwerty"); > - shouldThrow(); > - } catch (IndexOutOfBoundsException success) {} > + CopyOnWriteArrayList c = populatedArray(5); > + List[] lists = { c, c.subList(1, c.size() - 1) }; > + for (List list : lists) { > + try { > + list.add(-1,"qwerty"); > + shouldThrow(); > + } catch (IndexOutOfBoundsException success) {} > + } > } > /** > * add throws an IndexOutOfBoundsException on a too high index > */ > public void testAdd2_IndexOutOfBoundsException() { > - try { > - CopyOnWriteArrayList c = new CopyOnWriteArrayList(); > - c.add("asdasd"); > - c.add("asdasdasd"); > - c.add(100, "qwerty"); > - shouldThrow(); > - } catch (IndexOutOfBoundsException success) {} > + CopyOnWriteArrayList c = populatedArray(5); > + List[] lists = { c, c.subList(1, c.size() - 1) }; > + for (List list : lists) { > + try { > + list.add(list.size() + 1, "qwerty"); > + shouldThrow(); > + } catch (IndexOutOfBoundsException success) {} > + } > } > /** > * remove throws an IndexOutOfBoundsException on a negative index > */ > public void testRemove1_IndexOutOfBounds() { > - try { > - CopyOnWriteArrayList c = new CopyOnWriteArrayList(); > - c.remove(-1); > - shouldThrow(); > - } catch (IndexOutOfBoundsException success) {} > + CopyOnWriteArrayList c = populatedArray(5); > + List[] lists = { c, c.subList(1, c.size() - 1) }; > + for (List list : lists) { > + try { > + list.remove(-1); > + shouldThrow(); > + } catch (IndexOutOfBoundsException success) {} > + } > } > /** > * remove throws an IndexOutOfBoundsException on a too high index > */ > public void testRemove2_IndexOutOfBounds() { > - try { > - CopyOnWriteArrayList c = new CopyOnWriteArrayList(); > - c.add("asdasd"); > - c.add("adasdasd"); > - c.remove(100); > - shouldThrow(); > - } catch (IndexOutOfBoundsException success) {} > + CopyOnWriteArrayList c = populatedArray(5); > + List[] lists = { c, c.subList(1, c.size() - 1) }; > + for (List list : lists) { > + try { > + list.remove(list.size()); > + shouldThrow(); > + } catch (IndexOutOfBoundsException success) {} > + } > } > /** > * addAll throws an IndexOutOfBoundsException on a negative index > */ > public void testAddAll1_IndexOutOfBoundsException() { > - try { > - CopyOnWriteArrayList c = new CopyOnWriteArrayList(); > - c.addAll(-1,new LinkedList()); > - shouldThrow(); > - } catch (IndexOutOfBoundsException success) {} > + CopyOnWriteArrayList c = populatedArray(5); > + List[] lists = { c, c.subList(1, c.size() - 1) }; > + for (List list : lists) { > + try { > + list.addAll(-1,new LinkedList()); > + shouldThrow(); > + } catch (IndexOutOfBoundsException success) {} > + } > } > /** > * addAll throws an IndexOutOfBoundsException on a too high index > */ > public void testAddAll2_IndexOutOfBoundsException() { > - try { > - CopyOnWriteArrayList c = new CopyOnWriteArrayList(); > - c.add("asdasd"); > - c.add("asdasdasd"); > - c.addAll(100, new LinkedList()); > - shouldThrow(); > - } catch (IndexOutOfBoundsException success) {} > + CopyOnWriteArrayList c = populatedArray(5); > + List[] lists = { c, c.subList(1, c.size() - 1) }; > + for (List list : lists) { > + try { > + list.addAll(list.size() + 1, new LinkedList()); > + shouldThrow(); > + } catch (IndexOutOfBoundsException success) {} > + } > } > /** > * listIterator throws an IndexOutOfBoundsException on a negative index > */ > public void testListIterator1_IndexOutOfBoundsException() { > - try { > - CopyOnWriteArrayList c = new CopyOnWriteArrayList(); > - c.listIterator(-1); > - shouldThrow(); > - } catch (IndexOutOfBoundsException success) {} > + CopyOnWriteArrayList c = populatedArray(5); > + List[] lists = { c, c.subList(1, c.size() - 1) }; > + for (List list : lists) { > + try { > + list.listIterator(-1); > + shouldThrow(); > + } catch (IndexOutOfBoundsException success) {} > + } > } > /** > * listIterator throws an IndexOutOfBoundsException on a too high index > */ > public void testListIterator2_IndexOutOfBoundsException() { > - try { > - CopyOnWriteArrayList c = new CopyOnWriteArrayList(); > - c.add("adasd"); > - c.add("asdasdas"); > - c.listIterator(100); > - shouldThrow(); > - } catch (IndexOutOfBoundsException success) {} > + CopyOnWriteArrayList c = populatedArray(5); > + List[] lists = { c, c.subList(1, c.size() - 1) }; > + for (List list : lists) { > + try { > + list.listIterator(list.size() + 1); > + shouldThrow(); > + } catch (IndexOutOfBoundsException success) {} > + } > } > /** > * subList throws an IndexOutOfBoundsException on a negative index > */ > public void testSubList1_IndexOutOfBoundsException() { > - try { > - CopyOnWriteArrayList c = new CopyOnWriteArrayList(); > - c.subList(-1,100); > - shouldThrow(); > - } catch (IndexOutOfBoundsException success) {} > + CopyOnWriteArrayList c = populatedArray(5); > + List[] lists = { c, c.subList(1, c.size() - 1) }; > + for (List list : lists) { > + try { > + list.subList(-1, list.size()); > + shouldThrow(); > + } catch (IndexOutOfBoundsException success) {} > + } > } > /** > * subList throws an IndexOutOfBoundsException on a too high index > */ > public void testSubList2_IndexOutOfBoundsException() { > - try { > - CopyOnWriteArrayList c = new CopyOnWriteArrayList(); > - c.add("asdasd"); > - c.subList(1,100); > - shouldThrow(); > - } catch (IndexOutOfBoundsException success) {} > + CopyOnWriteArrayList c = populatedArray(5); > + List[] lists = { c, c.subList(1, c.size() - 1) }; > + for (List list : lists) { > + try { > + list.subList(0, list.size() + 1); > + shouldThrow(); > + } catch (IndexOutOfBoundsException success) {} > + } > } > /** > @@ -681,11 +710,14 @@ > * is lower then the first > */ > public void testSubList3_IndexOutOfBoundsException() { > - try { > - CopyOnWriteArrayList c = new CopyOnWriteArrayList(); > - c.subList(3,1); > - shouldThrow(); > - } catch (IndexOutOfBoundsException success) {} > + CopyOnWriteArrayList c = populatedArray(5); > + List[] lists = { c, c.subList(1, c.size() - 1) }; > + for (List list : lists) { > + try { > + list.subList(list.size() - 1, 1); > + shouldThrow(); > + } catch (IndexOutOfBoundsException success) {} > + } > } > /** > > > > On Fri, Jan 31, 2014 at 8:23 AM, Chris Hegarty > wrote: > > Trivial change to CopyOnWriteArrayList.__COWSubList.subList to catch the > case where the fromIndex is greater that the toIndex. > > http://cr.openjdk.java.net/~__chegar/8011645/webrev.00/__webrev/ > > > -Chris. > > From martinrb at google.com Fri Jan 31 18:07:31 2014 From: martinrb at google.com (Martin Buchholz) Date: Fri, 31 Jan 2014 10:07:31 -0800 Subject: RFR [9] 8011645: CopyOnWriteArrayList.COWSubList.subList does not validate range properly In-Reply-To: <52EBCE09.1030609@oracle.com> References: <52EBCE09.1030609@oracle.com> Message-ID: The jtreg test is fine, but: s/IOBE/IOOBE/ When I created MOAT.java many years ago, I intended tests such as this to get added to that, so that all of the List implementations could share the same test code. jsr166 does not have the same concern, since it only has one List implementation at the moment. Today, there are other choices, like sharing test infrastructure with Guava e.g. ListTestSuiteBuilder. More generally, openjdk core libraries can benefit from all the great testing work that guava folk have done. On Fri, Jan 31, 2014 at 8:23 AM, Chris Hegarty wrote: > Trivial change to CopyOnWriteArrayList.COWSubList.subList to catch the > case where the fromIndex is greater that the toIndex. > > http://cr.openjdk.java.net/~chegar/8011645/webrev.00/webrev/ > > -Chris. > From chris.hegarty at oracle.com Fri Jan 31 18:11:13 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 31 Jan 2014 18:11:13 +0000 Subject: RFR [9] 8011645: CopyOnWriteArrayList.COWSubList.subList does not validate range properly In-Reply-To: References: <52EBCE09.1030609@oracle.com> Message-ID: <49D5EB0E-C706-4DBD-9841-C4F8B9FED3BC@oracle.com> Thanks I?ll update the test before pushing. I know you have tests in the TCK for this now, but I?ll add the trivial jtreg test to OpenJDK to ensure this doesn?t creep back. -Chris. On 31 Jan 2014, at 18:07, Martin Buchholz wrote: > The jtreg test is fine, but: > > s/IOBE/IOOBE/ > > When I created MOAT.java many years ago, I intended tests such as this to get added to that, so that all of the List implementations could share the same test code. jsr166 does not have the same concern, since it only has one List implementation at the moment. Today, there are other choices, like sharing test infrastructure with Guava e.g. ListTestSuiteBuilder. More generally, openjdk core libraries can benefit from all the great testing work that guava folk have done. > > > On Fri, Jan 31, 2014 at 8:23 AM, Chris Hegarty wrote: > Trivial change to CopyOnWriteArrayList.COWSubList.subList to catch the case where the fromIndex is greater that the toIndex. > > http://cr.openjdk.java.net/~chegar/8011645/webrev.00/webrev/ > > -Chris. > From roger.riggs at oracle.com Fri Jan 31 18:33:26 2014 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 31 Jan 2014 13:33:26 -0500 Subject: RFR 8032221 Typo in java.util.date Message-ID: <52EBEC76.9000603@oracle.com> Please review a typo and javadoc cleanup for java.util.Date webrev: http://cr.openjdk.java.net/~rriggs/webrev-date-typo-8032221/ Thanks, Roger From joe.darcy at oracle.com Fri Jan 31 18:37:44 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 31 Jan 2014 10:37:44 -0800 Subject: RFR 8032221 Typo in java.util.date In-Reply-To: <52EBEC76.9000603@oracle.com> References: <52EBEC76.9000603@oracle.com> Message-ID: <52EBED78.8070907@oracle.com> On 01/31/2014 10:33 AM, roger riggs wrote: > Please review a typo and javadoc cleanup for java.util.Date > > webrev: > http://cr.openjdk.java.net/~rriggs/webrev-date-typo-8032221/ > > Thanks, Roger > Looks good Roger. Cheers, -Joe From chris.hegarty at oracle.com Fri Jan 31 18:40:03 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 31 Jan 2014 18:40:03 +0000 Subject: RFR 8032221 Typo in java.util.date In-Reply-To: <52EBEC76.9000603@oracle.com> References: <52EBEC76.9000603@oracle.com> Message-ID: trancate -> truncate . Other cleanups look good too. -Chris. On 31 Jan 2014, at 18:33, roger riggs wrote: > Please review a typo and javadoc cleanup for java.util.Date > > webrev: > http://cr.openjdk.java.net/~rriggs/webrev-date-typo-8032221/ > > Thanks, Roger > From Lance.Andersen at oracle.com Fri Jan 31 18:44:52 2014 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Fri, 31 Jan 2014 13:44:52 -0500 Subject: RFR 8032221 Typo in java.util.date In-Reply-To: <52EBEC76.9000603@oracle.com> References: <52EBEC76.9000603@oracle.com> Message-ID: looks fine. getting rid of and , is something I guess we should look to do throughout all of our code? On Jan 31, 2014, at 1:33 PM, roger riggs wrote: > Please review a typo and javadoc cleanup for java.util.Date > > webrev: > http://cr.openjdk.java.net/~rriggs/webrev-date-typo-8032221/ > > Thanks, Roger > -------------- next part -------------- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From chris.hegarty at oracle.com Fri Jan 31 18:46:07 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 31 Jan 2014 18:46:07 +0000 Subject: ObjectIn/OutputStream improvements In-Reply-To: <52EBB1B8.2030401@oracle.com> References: <91644C57-6E0D-48ED-8E31-6AC217DECCEF@gmx.de>, <1C96B28E-5E20-4D8D-B1FD-8FD5DF193EC8@oracle.com> <52EBB1B8.2030401@oracle.com> Message-ID: Forwarding to correct core-libs-dev list. -Chris. On 31 Jan 2014, at 14:22, Chris Hegarty wrote: > Hi Robert, > > I think your patch can be split into two logical, independent, parts. The first is the use of unsafe to access the String UTF length. The seconds is to reuse, where possible, the existing StringBuilder instances, skipping of primitive/object reading/writing where applicable, and general cleanup. > > Since this is a very sensitive area I would like to consider these separately. To that end, I have taken the changes that are applicable to the latter, removed any subjective stylistic changes, and made some additional cleanup improvements. > > http://cr.openjdk.java.net/~chegar/serial_stupp.00/webrev/ > > Specifically, > * I think for clarify and readability SerialCallbackContext > checkAndSetUsed() should be invoked directly. It makes it very > clear what the intent is. > * Skip primitive/object reading/writing if no primitives/objects in > the stream/class. ( I personally don't see any benefit of rounding > up the size of the array, it just seems to add unnecessary > complexity ) > * Move primitive types into getPrimitiveSignature for better reuse > of code. This retains your change to not create the additional > StringBuilder when it is not necessary. > > I am currently running tests on this change. > > -Chris. > > On 07/01/14 13:03, Robert Stupp wrote: >> Hi, >> I've attached the diff to the original email - it has been stripped. >> Here's a second try (inline). >> I've already signed the OCA and it has been approved :) >> Robert >> # HG changeset patch >> # User snazy >> # Date 1387101091 -3600 >> # Sun Dec 15 10:51:31 2013 +0100 >> # Node ID 6d46d99212453017c88417678d08dc8f10da9606 >> # Parent 9e1be800420265e5dcf264a7ed4abb6f230dd19d >> Removed some unnecessary variable assignments. >> ObjectInputStream: >> - skip primitive/object reading if no primitive/objects in class >> - use shared StringBuilder for string reading (prevent superfluous >> object allocations) >> ObjectOutputStream: >> - skip primitive/object writing if no primitive/objects in class >> - use unsafe access to calculate UTF-length >> - use unsafe access in readBytes() and writeChars() methods to access >> String value field >> - removed cbuf field >> ObjectStreamClass/ObjectStreamField: >> - minor improvement in getClassSignature ; share method code with >> ObjectStreamField >> diff --git a/src/share/classes/java/io/ObjectInputStream.java >> b/src/share/classes/java/io/ObjectInputStream.java >> --- a/src/share/classes/java/io/ObjectInputStream.java >> +++ b/src/share/classes/java/io/ObjectInputStream.java >> @@ -39,8 +39,8 @@ >> import java.util.HashMap; >> import java.util.concurrent.ConcurrentHashMap; >> import java.util.concurrent.ConcurrentMap; >> -import java.util.concurrent.atomic.AtomicBoolean; >> import static java.io.ObjectStreamClass.processQueue; >> + >> import sun.reflect.misc.ReflectUtil; >> >> /** >> @@ -534,7 +534,7 @@ >> if (ctx == null) { >> throw new NotActiveException("not in call to readObject"); >> } >> - Object curObj = ctx.getObj(); >> + ctx.getObj(); >> ObjectStreamClass curDesc = ctx.getDesc(); >> bin.setBlockDataMode(false); >> GetFieldImpl getField = new GetFieldImpl(curDesc); >> @@ -1597,7 +1597,7 @@ >> int descHandle = handles.assign(unshared ? unsharedMarker : desc); >> passHandle = NULL_HANDLE; >> >> - ObjectStreamClass readDesc = null; >> + ObjectStreamClass readDesc; >> try { >> readDesc = readClassDescriptor(); >> } catch (ClassNotFoundException ex) { >> @@ -1976,29 +1976,34 @@ >> } >> >> int primDataSize = desc.getPrimDataSize(); >> - if (primVals == null || primVals.length < primDataSize) { >> - primVals = new byte[primDataSize]; >> - } >> - bin.readFully(primVals, 0, primDataSize, false); >> - if (obj != null) { >> - desc.setPrimFieldValues(obj, primVals); >> - } >> - >> - int objHandle = passHandle; >> - ObjectStreamField[] fields = desc.getFields(false); >> - Object[] objVals = new Object[desc.getNumObjFields()]; >> - int numPrimFields = fields.length - objVals.length; >> - for (int i = 0; i < objVals.length; i++) { >> - ObjectStreamField f = fields[numPrimFields + i]; >> - objVals[i] = readObject0(f.isUnshared()); >> - if (f.getField() != null) { >> - handles.markDependency(objHandle, passHandle); >> + if (primDataSize > 0) { >> + if (primVals == null || primVals.length < primDataSize) { >> + primVals = new byte[ ((primDataSize>>4)+1)<<4 ]; >> + } >> + bin.readFully(primVals, 0, primDataSize, false); >> + if (obj != null) { >> + desc.setPrimFieldValues(obj, primVals); >> } >> } >> - if (obj != null) { >> - desc.setObjFieldValues(obj, objVals); >> + >> + int numObjFields = desc.getNumObjFields(); >> + if (numObjFields > 0) { >> + int objHandle = passHandle; >> + ObjectStreamField[] fields = desc.getFields(false); >> + Object[] objVals = new Object[numObjFields]; >> + int numPrimFields = fields.length - objVals.length; >> + for (int i = 0; i < objVals.length; i++) { >> + ObjectStreamField f = fields[numPrimFields + i]; >> + objVals[i] = readObject0(f.isUnshared()); >> + if (f.getField() != null) { >> + handles.markDependency(objHandle, passHandle); >> + } >> + } >> + if (obj != null) { >> + desc.setObjFieldValues(obj, objVals); >> + } >> + passHandle = objHandle; >> } >> - passHandle = objHandle; >> } >> >> /** >> @@ -2377,8 +2382,10 @@ >> private final byte[] buf = new byte[MAX_BLOCK_SIZE]; >> /** buffer for reading block data headers */ >> private final byte[] hbuf = new byte[MAX_HEADER_SIZE]; >> - /** char buffer for fast string reads */ >> + /** char buffer for fast string reads - used by {@link >> #readUTFSpan(long)} */ >> private final char[] cbuf = new char[CHAR_BUF_SIZE]; >> + /** shared string builder for less object allocations - used by >> {@link #readUTFBody(long)}, {@link #readUTFChar(long)} and {@link >> #readUTFSpan(long)} */ >> + private final StringBuilder sbuf = new >> StringBuilder(CHAR_BUF_SIZE); >> >> /** block data mode */ >> private boolean blkmode = false; >> @@ -3044,19 +3051,19 @@ >> * utflen bytes. >> */ >> private String readUTFBody(long utflen) throws IOException { >> - StringBuilder sbuf = new StringBuilder(); >> if (!blkmode) { >> end = pos = 0; >> } >> >> + sbuf.setLength(0); >> while (utflen > 0) { >> int avail = end - pos; >> if (avail >= 3 || (long) avail == utflen) { >> - utflen -= readUTFSpan(sbuf, utflen); >> + utflen -= readUTFSpan(utflen); >> } else { >> if (blkmode) { >> // near block boundary, read one byte at a time >> - utflen -= readUTFChar(sbuf, utflen); >> + utflen -= readUTFChar(utflen); >> } else { >> // shift and refill buffer manually >> if (avail > 0) { >> @@ -3076,10 +3083,10 @@ >> * Reads span of UTF-encoded characters out of internal buffer >> * (starting at offset pos and ending at or before offset end), >> * consuming no more than utflen bytes. Appends read >> characters to >> - * sbuf. Returns the number of bytes consumed. >> + * {@link #sbuf}. Returns the number of bytes consumed. >> */ >> - private long readUTFSpan(StringBuilder sbuf, long utflen) >> - throws IOException >> + private long readUTFSpan(long utflen) >> + throws IOException >> { >> int cpos = 0; >> int start = pos; >> @@ -3111,19 +3118,19 @@ >> throw new UTFDataFormatException(); >> } >> cbuf[cpos++] = (char) (((b1 & 0x1F) << 6) | >> - ((b2 & 0x3F) << 0)); >> + (b2 & 0x3F)); >> break; >> >> case 14: // 3 byte format: 1110xxxx 10xxxxxx >> 10xxxxxx >> b3 = buf[pos + 1]; >> - b2 = buf[pos + 0]; >> + b2 = buf[pos ]; >> pos += 2; >> if ((b2 & 0xC0) != 0x80 || (b3 & 0xC0) != >> 0x80) { >> throw new UTFDataFormatException(); >> } >> cbuf[cpos++] = (char) (((b1 & 0x0F) << 12) | >> - ((b2 & 0x3F) << 6) | >> - ((b3 & 0x3F) << 0)); >> + ((b2 & 0x3F) << 6) | >> + (b3 & 0x3F)); >> break; >> >> default: // 10xx xxxx, 1111 xxxx >> @@ -3150,12 +3157,12 @@ >> >> /** >> * Reads in single UTF-encoded character one byte at a time, >> appends >> - * the character to sbuf, and returns the number of bytes consumed. >> + * the character to {@link #sbuf}, and returns the number of >> bytes consumed. >> * This method is used when reading in UTF strings written in >> block >> * data mode to handle UTF-encoded characters which (potentially) >> * straddle block-data boundaries. >> */ >> - private int readUTFChar(StringBuilder sbuf, long utflen) >> + private int readUTFChar(long utflen) >> throws IOException >> { >> int b1, b2, b3; >> @@ -3181,8 +3188,7 @@ >> if ((b2 & 0xC0) != 0x80) { >> throw new UTFDataFormatException(); >> } >> - sbuf.append((char) (((b1 & 0x1F) << 6) | >> - ((b2 & 0x3F) << 0))); >> + sbuf.append((char) (((b1 & 0x1F) << 6) | (b2 & 0x3F))); >> return 2; >> >> case 14: // 3 byte format: 1110xxxx 10xxxxxx 10xxxxxx >> @@ -3198,8 +3204,8 @@ >> throw new UTFDataFormatException(); >> } >> sbuf.append((char) (((b1 & 0x0F) << 12) | >> - ((b2 & 0x3F) << 6) | >> - ((b3 & 0x3F) << 0))); >> + ((b2 & 0x3F) << 6) | >> + (b3 & 0x3F))); >> return 3; >> >> default: // 10xx xxxx, 1111 xxxx >> diff --git a/src/share/classes/java/io/ObjectOutputStream.java >> b/src/share/classes/java/io/ObjectOutputStream.java >> --- a/src/share/classes/java/io/ObjectOutputStream.java >> +++ b/src/share/classes/java/io/ObjectOutputStream.java >> @@ -35,7 +35,8 @@ >> import java.util.concurrent.ConcurrentHashMap; >> import java.util.concurrent.ConcurrentMap; >> import static java.io.ObjectStreamClass.processQueue; >> -import java.io.SerialCallbackContext; >> + >> +import sun.misc.Unsafe; >> import sun.reflect.misc.ReflectUtil; >> >> /** >> @@ -458,7 +459,7 @@ >> if (ctx == null) { >> throw new NotActiveException("not in call to >> writeObject"); >> } >> - Object curObj = ctx.getObj(); >> + ctx.getObj(); >> ObjectStreamClass curDesc = ctx.getDesc(); >> curPut = new PutFieldImpl(curDesc); >> } >> @@ -1300,7 +1301,7 @@ >> */ >> private void writeString(String str, boolean unshared) throws >> IOException { >> handles.assign(unshared ? null : str); >> - long utflen = bout.getUTFLength(str); >> + long utflen = BlockDataOutputStream.getUTFLength(str); >> if (utflen <= 0xFFFF) { >> bout.writeByte(TC_STRING); >> bout.writeUTF(str, utflen); >> @@ -1527,29 +1528,34 @@ >> desc.checkDefaultSerialize(); >> >> int primDataSize = desc.getPrimDataSize(); >> - if (primVals == null || primVals.length < primDataSize) { >> - primVals = new byte[primDataSize]; >> + if (primDataSize > 0) { >> + if (primVals == null || primVals.length < primDataSize) { >> + primVals = new byte[ ((primDataSize>>4)+1)<<4 ]; >> + } >> + desc.getPrimFieldValues(obj, primVals); >> + bout.write(primVals, 0, primDataSize, false); >> } >> - desc.getPrimFieldValues(obj, primVals); >> - bout.write(primVals, 0, primDataSize, false); >> >> - ObjectStreamField[] fields = desc.getFields(false); >> - Object[] objVals = new Object[desc.getNumObjFields()]; >> - int numPrimFields = fields.length - objVals.length; >> - desc.getObjFieldValues(obj, objVals); >> - for (int i = 0; i < objVals.length; i++) { >> - if (extendedDebugInfo) { >> - debugInfoStack.push( >> - "field (class \"" + desc.getName() + "\", name: \"" + >> - fields[numPrimFields + i].getName() + "\", type: \"" + >> - fields[numPrimFields + i].getType() + "\")"); >> - } >> - try { >> - writeObject0(objVals[i], >> - fields[numPrimFields + i].isUnshared()); >> - } finally { >> + int numObjFields = desc.getNumObjFields(); >> + if (numObjFields > 0) { >> + ObjectStreamField[] fields = desc.getFields(false); >> + Object[] objVals = new Object[numObjFields]; >> + int numPrimFields = fields.length - objVals.length; >> + desc.getObjFieldValues(obj, objVals); >> + for (int i = 0; i < objVals.length; i++) { >> if (extendedDebugInfo) { >> - debugInfoStack.pop(); >> + debugInfoStack.push( >> + "field (class \"" + desc.getName() + "\", name: >> \"" + >> + fields[numPrimFields + i].getName() + "\", >> type: \"" + >> + fields[numPrimFields + i].getType() + "\")"); >> + } >> + try { >> + writeObject0(objVals[i], >> + fields[numPrimFields + i].isUnshared()); >> + } finally { >> + if (extendedDebugInfo) { >> + debugInfoStack.pop(); >> + } >> } >> } >> } >> @@ -1743,15 +1749,11 @@ >> private static final int MAX_BLOCK_SIZE = 1024; >> /** maximum data block header length */ >> private static final int MAX_HEADER_SIZE = 5; >> - /** (tunable) length of char buffer (for writing strings) */ >> - private static final int CHAR_BUF_SIZE = 256; >> >> /** buffer for writing general/block data */ >> private final byte[] buf = new byte[MAX_BLOCK_SIZE]; >> /** buffer for writing block data headers */ >> private final byte[] hbuf = new byte[MAX_HEADER_SIZE]; >> - /** char buffer for fast string writes */ >> - private final char[] cbuf = new char[CHAR_BUF_SIZE]; >> >> /** block data mode */ >> private boolean blkmode = false; >> @@ -1763,6 +1765,18 @@ >> /** loopback stream (for data writes that span data blocks) */ >> private final DataOutputStream dout; >> >> + /** use unsafe to directly access value field in >> java.lang.String */ >> + private static final Unsafe unsafe = Unsafe.getUnsafe(); >> + /** use field offset to directly access value field in >> java.lang.String */ >> + private static final long stringValueOffset; >> + static { >> + try { >> + stringValueOffset = >> unsafe.objectFieldOffset(String.class.getDeclaredField("value")); >> + } catch (NoSuchFieldException e) { >> + throw new InternalError(e); >> + } >> + } >> + >> /** >> * Creates new BlockDataOutputStream on top of given >> underlying stream. >> * Block data mode is turned off by default. >> @@ -1972,35 +1986,23 @@ >> } >> >> public void writeBytes(String s) throws IOException { >> - int endoff = s.length(); >> - int cpos = 0; >> - int csize = 0; >> + char[] sChars = (char[])unsafe.getObject(s, stringValueOffset); >> + int endoff = sChars.length; >> for (int off = 0; off < endoff; ) { >> - if (cpos >= csize) { >> - cpos = 0; >> - csize = Math.min(endoff - off, CHAR_BUF_SIZE); >> - s.getChars(off, off + csize, cbuf, 0); >> - } >> if (pos >= MAX_BLOCK_SIZE) { >> drain(); >> } >> - int n = Math.min(csize - cpos, MAX_BLOCK_SIZE - pos); >> + int n = Math.min(endoff - off, MAX_BLOCK_SIZE - pos); >> int stop = pos + n; >> while (pos < stop) { >> - buf[pos++] = (byte) cbuf[cpos++]; >> + buf[pos++] = (byte) sChars[off++]; >> } >> - off += n; >> } >> } >> >> public void writeChars(String s) throws IOException { >> - int endoff = s.length(); >> - for (int off = 0; off < endoff; ) { >> - int csize = Math.min(endoff - off, CHAR_BUF_SIZE); >> - s.getChars(off, off + csize, cbuf, 0); >> - writeChars(cbuf, 0, csize); >> - off += csize; >> - } >> + char[] sChars = (char[])unsafe.getObject(s, stringValueOffset); >> + writeChars(sChars, 0, sChars.length); >> } >> >> public void writeUTF(String s) throws IOException { >> @@ -2130,25 +2132,21 @@ >> } >> >> /** >> - * Returns the length in bytes of the UTF encoding of the given >> string. >> + * Returns the length in bytes of the UTF encoding of this >> given string. >> */ >> - long getUTFLength(String s) { >> - int len = s.length(); >> + static long getUTFLength(String s) { >> + char[] value = (char[])unsafe.getObject(s, stringValueOffset); >> + int len = value.length; >> long utflen = 0; >> for (int off = 0; off < len; ) { >> - int csize = Math.min(len - off, CHAR_BUF_SIZE); >> - s.getChars(off, off + csize, cbuf, 0); >> - for (int cpos = 0; cpos < csize; cpos++) { >> - char c = cbuf[cpos]; >> - if (c >= 0x0001 && c <= 0x007F) { >> - utflen++; >> - } else if (c > 0x07FF) { >> - utflen += 3; >> - } else { >> - utflen += 2; >> - } >> + char c = value[off++]; >> + if (c >= 0x0001 && c <= 0x007F) { >> + utflen++; >> + } else if (c > 0x07FF) { >> + utflen += 3; >> + } else { >> + utflen += 2; >> } >> - off += csize; >> } >> return utflen; >> } >> @@ -2198,40 +2196,36 @@ >> * 8-byte length header) of the UTF encoding for the given string. >> */ >> private void writeUTFBody(String s) throws IOException { >> + char[] sChars = (char[])unsafe.getObject(s, stringValueOffset); >> + int len = sChars.length; >> int limit = MAX_BLOCK_SIZE - 3; >> - int len = s.length(); >> for (int off = 0; off < len; ) { >> - int csize = Math.min(len - off, CHAR_BUF_SIZE); >> - s.getChars(off, off + csize, cbuf, 0); >> - for (int cpos = 0; cpos < csize; cpos++) { >> - char c = cbuf[cpos]; >> - if (pos <= limit) { >> - if (c <= 0x007F && c != 0) { >> - buf[pos++] = (byte) c; >> - } else if (c > 0x07FF) { >> - buf[pos + 2] = (byte) (0x80 | ((c >> 0) & >> 0x3F)); >> - buf[pos + 1] = (byte) (0x80 | ((c >> 6) & >> 0x3F)); >> - buf[pos + 0] = (byte) (0xE0 | ((c >> 12) & >> 0x0F)); >> - pos += 3; >> - } else { >> - buf[pos + 1] = (byte) (0x80 | ((c >> 0) & >> 0x3F)); >> - buf[pos + 0] = (byte) (0xC0 | ((c >> 6) & >> 0x1F)); >> - pos += 2; >> - } >> - } else { // write one byte at a time to >> normalize block >> - if (c <= 0x007F && c != 0) { >> - write(c); >> - } else if (c > 0x07FF) { >> - write(0xE0 | ((c >> 12) & 0x0F)); >> - write(0x80 | ((c >> 6) & 0x3F)); >> - write(0x80 | ((c >> 0) & 0x3F)); >> - } else { >> - write(0xC0 | ((c >> 6) & 0x1F)); >> - write(0x80 | ((c >> 0) & 0x3F)); >> - } >> + char c = sChars[off++]; >> + if (pos <= limit) { >> + if (c <= 0x007F && c != 0) { >> + buf[pos++] = (byte) c; >> + } else if (c > 0x07FF) { >> + buf[pos + 2] = (byte) (0x80 | ( c & 0x3F)); >> + buf[pos + 1] = (byte) (0x80 | ((c >> 6) & 0x3F)); >> + buf[pos ] = (byte) (0xE0 | ((c >> 12) & 0x0F)); >> + pos += 3; >> + } else { >> + buf[pos + 1] = (byte) (0x80 | ( c & 0x3F)); >> + buf[pos ] = (byte) (0xC0 | ((c >> 6) & 0x1F)); >> + pos += 2; >> + } >> + } else { // write one byte at a time to normalize block >> + if (c <= 0x007F && c != 0) { >> + write(c); >> + } else if (c > 0x07FF) { >> + write(0xE0 | ((c >> 12) & 0x0F)); >> + write(0x80 | ((c >> 6) & 0x3F)); >> + write(0x80 | ( c & 0x3F)); >> + } else { >> + write(0xC0 | ((c >> 6) & 0x1F)); >> + write(0x80 | ( c & 0x3F)); >> } >> } >> - off += csize; >> } >> } >> } >> @@ -2464,7 +2458,10 @@ >> StringBuilder buffer = new StringBuilder(); >> if (!stack.isEmpty()) { >> for(int i = stack.size(); i > 0; i-- ) { >> - buffer.append(stack.get(i-1) + ((i != 1) ? "\n" : "")); >> + buffer.append(stack.get(i - 1)); >> + if (i!=1) { >> + buffer.append('\n'); >> + } >> } >> } >> return buffer.toString(); >> diff --git a/src/share/classes/java/io/ObjectStreamClass.java >> b/src/share/classes/java/io/ObjectStreamClass.java >> --- a/src/share/classes/java/io/ObjectStreamClass.java >> +++ b/src/share/classes/java/io/ObjectStreamClass.java >> @@ -1474,7 +1474,28 @@ >> /** >> * Returns JVM type signature for given class. >> */ >> - private static String getClassSignature(Class cl) { >> + static String getClassSignature(Class cl) { >> + if (cl.isPrimitive()) >> + if (cl == Integer.TYPE) { >> + return "I"; >> + } else if (cl == Byte.TYPE) { >> + return "B"; >> + } else if (cl == Long.TYPE) { >> + return "J"; >> + } else if (cl == Float.TYPE) { >> + return "F"; >> + } else if (cl == Double.TYPE) { >> + return "D"; >> + } else if (cl == Short.TYPE) { >> + return "S"; >> + } else if (cl == Character.TYPE) { >> + return "C"; >> + } else if (cl == Boolean.TYPE) { >> + return "Z"; >> + } else if (cl == Void.TYPE) { >> + return "V"; >> + } >> + >> StringBuilder sbuf = new StringBuilder(); >> while (cl.isArray()) { >> sbuf.append('['); >> @@ -1503,7 +1524,7 @@ >> throw new InternalError(); >> } >> } else { >> - sbuf.append('L' + cl.getName().replace('.', '/') + ';'); >> + sbuf.append('L').append(cl.getName().replace('.', >> '/')).append(';'); >> } >> return sbuf.toString(); >> } >> diff --git a/src/share/classes/java/io/ObjectStreamField.java >> b/src/share/classes/java/io/ObjectStreamField.java >> --- a/src/share/classes/java/io/ObjectStreamField.java >> +++ b/src/share/classes/java/io/ObjectStreamField.java >> @@ -91,7 +91,7 @@ >> this.name = name; >> this.type = type; >> this.unshared = unshared; >> - signature = getClassSignature(type).intern(); >> + signature = ObjectStreamClass.getClassSignature(type).intern(); >> field = null; >> } >> >> @@ -137,7 +137,7 @@ >> name = field.getName(); >> Class ftype = field.getType(); >> type = (showType || ftype.isPrimitive()) ? ftype : Object.class; >> - signature = getClassSignature(ftype).intern(); >> + signature = ObjectStreamClass.getClassSignature(ftype).intern(); >> } >> >> /** >> @@ -286,41 +286,4 @@ >> String getSignature() { >> return signature; >> } >> - >> - /** >> - * Returns JVM type signature for given class. >> - */ >> - private static String getClassSignature(Class cl) { >> - StringBuilder sbuf = new StringBuilder(); >> - while (cl.isArray()) { >> - sbuf.append('['); >> - cl = cl.getComponentType(); >> - } >> - if (cl.isPrimitive()) { >> - if (cl == Integer.TYPE) { >> - sbuf.append('I'); >> - } else if (cl == Byte.TYPE) { >> - sbuf.append('B'); >> - } else if (cl == Long.TYPE) { >> - sbuf.append('J'); >> - } else if (cl == Float.TYPE) { >> - sbuf.append('F'); >> - } else if (cl == Double.TYPE) { >> - sbuf.append('D'); >> - } else if (cl == Short.TYPE) { >> - sbuf.append('S'); >> - } else if (cl == Character.TYPE) { >> - sbuf.append('C'); >> - } else if (cl == Boolean.TYPE) { >> - sbuf.append('Z'); >> - } else if (cl == Void.TYPE) { >> - sbuf.append('V'); >> - } else { >> - throw new InternalError(); >> - } >> - } else { >> - sbuf.append('L' + cl.getName().replace('.', '/') + ';'); >> - } >> - return sbuf.toString(); >> - } >> } >> *Gesendet:* Dienstag, 07. Januar 2014 um 10:05 Uhr >> *Von:* "Chris Hegarty" >> *An:* "Robert Stupp" >> *Cc:* "core-libs-dev at openjdk.java.net Libs" >> *Betreff:* Re: ObjectIn/OutputStream improvements >> On 15 Dec 2013, at 10:29, Robert Stupp wrote: >> >> > Hi, >> > >> > I digged through the object serialization code and found some lines >> that could be optimized to reduce the number of calls to >> System.arraycopy() and temporary object allocations especially during >> string (de)serialization. >> > In short sentences the changes are: >> > ObjectInputStream: >> > - skip primitive/object reading if no primitive/objects in class >> (defaultReadFields method) >> > - use shared StringBuilder for string reading (prevent superfluous >> object allocations of one StingBuilder and one implicit char[] for each >> string being deserialized) >> > ObjectOutputStream: >> > - skip primitive/object writing if no primitive/objects in class >> (defaultWriteFields method) >> > - use unsafe access to calculate UTF-length >> > - use unsafe access in readBytes() and writeChars() methods to access >> String value field >> > - removed cbuf field >> > ObjectStreamClass/ObjectStreamField: >> > - minor improvement in getClassSignature ; share method code with >> ObjectStreamField (return constant string for primitives) >> > >> > I have tested the changes in a big Java installation at a customer >> (backported the Java8 ObjectIn/OutputStream including the changes to >> Java6) and a long running real application performance test resulted in >> reduced CPU usage (from about 60% per server to 50%). >> > The changes I made in openjdk8 pass all tests. >> > >> > Since I have no experience how to contribute code to openjdk in form >> of a push/changeset I have added the diff (hg export -g) to this email. >> >> Did you attach the diffs? I don?t see any attachment, it may be that the >> attachment was stripped. Can you try resending inline? >> >> You should take a look at the OpenJDK How to Contribute page [1]. Paying >> particular attention to the OCA, without it we will not be able to move >> your patch forward. >> >> Thanks, >> -Chris. >> >> [1] http://openjdk.java.net/contribute/ >> >> > >> > Robert >> > >> > From chris.hegarty at oracle.com Fri Jan 31 18:47:05 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 31 Jan 2014 18:47:05 +0000 Subject: ObjectIn/OutputStream improvements In-Reply-To: References: <91644C57-6E0D-48ED-8E31-6AC217DECCEF@gmx.de>, <1C96B28E-5E20-4D8D-B1FD-8FD5DF193EC8@oracle.com> , <52EBB1B8.2030401@oracle.com> Message-ID: Forwarding for correct core-libs-dev list. -Chris. On 31 Jan 2014, at 15:26, Robert Stupp wrote: > Hi Chris, > > fine. I'm a bit proud that my 5ct help to improve JDK9 :) > > The primitive buffer array size rounding was there to reduce the number of re-allocations when a class requires a slightly bigger primitive buffer than another. Maybe we can introduce some minimum buffer size - e.g. 64 or 128 bytes? This should be enough for most classes. Classes that require a bigger buffer will always force an extend of the buffer - rounded or not. > > Robert > > > Gesendet: Freitag, 31. Januar 2014 um 15:22 Uhr > Von: "Chris Hegarty" > An: "Robert Stupp" , core-libs-dev-request > Betreff: Re: Aw: Re: ObjectIn/OutputStream improvements > Hi Robert, > > I think your patch can be split into two logical, independent, parts. > The first is the use of unsafe to access the String UTF length. The > seconds is to reuse, where possible, the existing StringBuilder > instances, skipping of primitive/object reading/writing where > applicable, and general cleanup. > > Since this is a very sensitive area I would like to consider these > separately. To that end, I have taken the changes that are applicable to > the latter, removed any subjective stylistic changes, and made some > additional cleanup improvements. > > http://cr.openjdk.java.net/~chegar/serial_stupp.00/webrev/ > > Specifically, > * I think for clarify and readability SerialCallbackContext > checkAndSetUsed() should be invoked directly. It makes it very > clear what the intent is. > * Skip primitive/object reading/writing if no primitives/objects in > the stream/class. ( I personally don't see any benefit of rounding > up the size of the array, it just seems to add unnecessary > complexity ) > * Move primitive types into getPrimitiveSignature for better reuse > of code. This retains your change to not create the additional > StringBuilder when it is not necessary. > > I am currently running tests on this change. > > -Chris. > > On 07/01/14 13:03, Robert Stupp wrote: > > Hi, > > I've attached the diff to the original email - it has been stripped. > > Here's a second try (inline). > > I've already signed the OCA and it has been approved :) > > Robert > > # HG changeset patch > > # User snazy > > # Date 1387101091 -3600 > > # Sun Dec 15 10:51:31 2013 +0100 > > # Node ID 6d46d99212453017c88417678d08dc8f10da9606 > > # Parent 9e1be800420265e5dcf264a7ed4abb6f230dd19d > > Removed some unnecessary variable assignments. > > ObjectInputStream: > > - skip primitive/object reading if no primitive/objects in class > > - use shared StringBuilder for string reading (prevent superfluous > > object allocations) > > ObjectOutputStream: > > - skip primitive/object writing if no primitive/objects in class > > - use unsafe access to calculate UTF-length > > - use unsafe access in readBytes() and writeChars() methods to access > > String value field > > - removed cbuf field > > ObjectStreamClass/ObjectStreamField: > > - minor improvement in getClassSignature ; share method code with > > ObjectStreamField > > diff --git a/src/share/classes/java/io/ObjectInputStream.java > > b/src/share/classes/java/io/ObjectInputStream.java > > --- a/src/share/classes/java/io/ObjectInputStream.java > > +++ b/src/share/classes/java/io/ObjectInputStream.java > > @@ -39,8 +39,8 @@ > > import java.util.HashMap; > > import java.util.concurrent.ConcurrentHashMap; > > import java.util.concurrent.ConcurrentMap; > > -import java.util.concurrent.atomic.AtomicBoolean; > > import static java.io.ObjectStreamClass.processQueue; > > + > > import sun.reflect.misc.ReflectUtil; > > > > /** > > @@ -534,7 +534,7 @@ > > if (ctx == null) { > > throw new NotActiveException("not in call to readObject"); > > } > > - Object curObj = ctx.getObj(); > > + ctx.getObj(); > > ObjectStreamClass curDesc = ctx.getDesc(); > > bin.setBlockDataMode(false); > > GetFieldImpl getField = new GetFieldImpl(curDesc); > > @@ -1597,7 +1597,7 @@ > > int descHandle = handles.assign(unshared ? unsharedMarker : desc); > > passHandle = NULL_HANDLE; > > > > - ObjectStreamClass readDesc = null; > > + ObjectStreamClass readDesc; > > try { > > readDesc = readClassDescriptor(); > > } catch (ClassNotFoundException ex) { > > @@ -1976,29 +1976,34 @@ > > } > > > > int primDataSize = desc.getPrimDataSize(); > > - if (primVals == null || primVals.length < primDataSize) { > > - primVals = new byte[primDataSize]; > > - } > > - bin.readFully(primVals, 0, primDataSize, false); > > - if (obj != null) { > > - desc.setPrimFieldValues(obj, primVals); > > - } > > - > > - int objHandle = passHandle; > > - ObjectStreamField[] fields = desc.getFields(false); > > - Object[] objVals = new Object[desc.getNumObjFields()]; > > - int numPrimFields = fields.length - objVals.length; > > - for (int i = 0; i < objVals.length; i++) { > > - ObjectStreamField f = fields[numPrimFields + i]; > > - objVals[i] = readObject0(f.isUnshared()); > > - if (f.getField() != null) { > > - handles.markDependency(objHandle, passHandle); > > + if (primDataSize > 0) { > > + if (primVals == null || primVals.length < primDataSize) { > > + primVals = new byte[ ((primDataSize>>4)+1)<<4 ]; > > + } > > + bin.readFully(primVals, 0, primDataSize, false); > > + if (obj != null) { > > + desc.setPrimFieldValues(obj, primVals); > > } > > } > > - if (obj != null) { > > - desc.setObjFieldValues(obj, objVals); > > + > > + int numObjFields = desc.getNumObjFields(); > > + if (numObjFields > 0) { > > + int objHandle = passHandle; > > + ObjectStreamField[] fields = desc.getFields(false); > > + Object[] objVals = new Object[numObjFields]; > > + int numPrimFields = fields.length - objVals.length; > > + for (int i = 0; i < objVals.length; i++) { > > + ObjectStreamField f = fields[numPrimFields + i]; > > + objVals[i] = readObject0(f.isUnshared()); > > + if (f.getField() != null) { > > + handles.markDependency(objHandle, passHandle); > > + } > > + } > > + if (obj != null) { > > + desc.setObjFieldValues(obj, objVals); > > + } > > + passHandle = objHandle; > > } > > - passHandle = objHandle; > > } > > > > /** > > @@ -2377,8 +2382,10 @@ > > private final byte[] buf = new byte[MAX_BLOCK_SIZE]; > > /** buffer for reading block data headers */ > > private final byte[] hbuf = new byte[MAX_HEADER_SIZE]; > > - /** char buffer for fast string reads */ > > + /** char buffer for fast string reads - used by {@link > > #readUTFSpan(long)} */ > > private final char[] cbuf = new char[CHAR_BUF_SIZE]; > > + /** shared string builder for less object allocations - used by > > {@link #readUTFBody(long)}, {@link #readUTFChar(long)} and {@link > > #readUTFSpan(long)} */ > > + private final StringBuilder sbuf = new > > StringBuilder(CHAR_BUF_SIZE); > > > > /** block data mode */ > > private boolean blkmode = false; > > @@ -3044,19 +3051,19 @@ > > * utflen bytes. > > */ > > private String readUTFBody(long utflen) throws IOException { > > - StringBuilder sbuf = new StringBuilder(); > > if (!blkmode) { > > end = pos = 0; > > } > > > > + sbuf.setLength(0); > > while (utflen > 0) { > > int avail = end - pos; > > if (avail >= 3 || (long) avail == utflen) { > > - utflen -= readUTFSpan(sbuf, utflen); > > + utflen -= readUTFSpan(utflen); > > } else { > > if (blkmode) { > > // near block boundary, read one byte at a time > > - utflen -= readUTFChar(sbuf, utflen); > > + utflen -= readUTFChar(utflen); > > } else { > > // shift and refill buffer manually > > if (avail > 0) { > > @@ -3076,10 +3083,10 @@ > > * Reads span of UTF-encoded characters out of internal buffer > > * (starting at offset pos and ending at or before offset end), > > * consuming no more than utflen bytes. Appends read > > characters to > > - * sbuf. Returns the number of bytes consumed. > > + * {@link #sbuf}. Returns the number of bytes consumed. > > */ > > - private long readUTFSpan(StringBuilder sbuf, long utflen) > > - throws IOException > > + private long readUTFSpan(long utflen) > > + throws IOException > > { > > int cpos = 0; > > int start = pos; > > @@ -3111,19 +3118,19 @@ > > throw new UTFDataFormatException(); > > } > > cbuf[cpos++] = (char) (((b1 & 0x1F) << 6) | > > - ((b2 & 0x3F) << 0)); > > + (b2 & 0x3F)); > > break; > > > > case 14: // 3 byte format: 1110xxxx 10xxxxxx > > 10xxxxxx > > b3 = buf[pos + 1]; > > - b2 = buf[pos + 0]; > > + b2 = buf[pos ]; > > pos += 2; > > if ((b2 & 0xC0) != 0x80 || (b3 & 0xC0) != > > 0x80) { > > throw new UTFDataFormatException(); > > } > > cbuf[cpos++] = (char) (((b1 & 0x0F) << 12) | > > - ((b2 & 0x3F) << 6) | > > - ((b3 & 0x3F) << 0)); > > + ((b2 & 0x3F) << 6) | > > + (b3 & 0x3F)); > > break; > > > > default: // 10xx xxxx, 1111 xxxx > > @@ -3150,12 +3157,12 @@ > > > > /** > > * Reads in single UTF-encoded character one byte at a time, > > appends > > - * the character to sbuf, and returns the number of bytes consumed. > > + * the character to {@link #sbuf}, and returns the number of > > bytes consumed. > > * This method is used when reading in UTF strings written in > > block > > * data mode to handle UTF-encoded characters which (potentially) > > * straddle block-data boundaries. > > */ > > - private int readUTFChar(StringBuilder sbuf, long utflen) > > + private int readUTFChar(long utflen) > > throws IOException > > { > > int b1, b2, b3; > > @@ -3181,8 +3188,7 @@ > > if ((b2 & 0xC0) != 0x80) { > > throw new UTFDataFormatException(); > > } > > - sbuf.append((char) (((b1 & 0x1F) << 6) | > > - ((b2 & 0x3F) << 0))); > > + sbuf.append((char) (((b1 & 0x1F) << 6) | (b2 & 0x3F))); > > return 2; > > > > case 14: // 3 byte format: 1110xxxx 10xxxxxx 10xxxxxx > > @@ -3198,8 +3204,8 @@ > > throw new UTFDataFormatException(); > > } > > sbuf.append((char) (((b1 & 0x0F) << 12) | > > - ((b2 & 0x3F) << 6) | > > - ((b3 & 0x3F) << 0))); > > + ((b2 & 0x3F) << 6) | > > + (b3 & 0x3F))); > > return 3; > > > > default: // 10xx xxxx, 1111 xxxx > > diff --git a/src/share/classes/java/io/ObjectOutputStream.java > > b/src/share/classes/java/io/ObjectOutputStream.java > > --- a/src/share/classes/java/io/ObjectOutputStream.java > > +++ b/src/share/classes/java/io/ObjectOutputStream.java > > @@ -35,7 +35,8 @@ > > import java.util.concurrent.ConcurrentHashMap; > > import java.util.concurrent.ConcurrentMap; > > import static java.io.ObjectStreamClass.processQueue; > > -import java.io.SerialCallbackContext; > > + > > +import sun.misc.Unsafe; > > import sun.reflect.misc.ReflectUtil; > > > > /** > > @@ -458,7 +459,7 @@ > > if (ctx == null) { > > throw new NotActiveException("not in call to > > writeObject"); > > } > > - Object curObj = ctx.getObj(); > > + ctx.getObj(); > > ObjectStreamClass curDesc = ctx.getDesc(); > > curPut = new PutFieldImpl(curDesc); > > } > > @@ -1300,7 +1301,7 @@ > > */ > > private void writeString(String str, boolean unshared) throws > > IOException { > > handles.assign(unshared ? null : str); > > - long utflen = bout.getUTFLength(str); > > + long utflen = BlockDataOutputStream.getUTFLength(str); > > if (utflen <= 0xFFFF) { > > bout.writeByte(TC_STRING); > > bout.writeUTF(str, utflen); > > @@ -1527,29 +1528,34 @@ > > desc.checkDefaultSerialize(); > > > > int primDataSize = desc.getPrimDataSize(); > > - if (primVals == null || primVals.length < primDataSize) { > > - primVals = new byte[primDataSize]; > > + if (primDataSize > 0) { > > + if (primVals == null || primVals.length < primDataSize) { > > + primVals = new byte[ ((primDataSize>>4)+1)<<4 ]; > > + } > > + desc.getPrimFieldValues(obj, primVals); > > + bout.write(primVals, 0, primDataSize, false); > > } > > - desc.getPrimFieldValues(obj, primVals); > > - bout.write(primVals, 0, primDataSize, false); > > > > - ObjectStreamField[] fields = desc.getFields(false); > > - Object[] objVals = new Object[desc.getNumObjFields()]; > > - int numPrimFields = fields.length - objVals.length; > > - desc.getObjFieldValues(obj, objVals); > > - for (int i = 0; i < objVals.length; i++) { > > - if (extendedDebugInfo) { > > - debugInfoStack.push( > > - "field (class \"" + desc.getName() + "\", name: \"" + > > - fields[numPrimFields + i].getName() + "\", type: \"" + > > - fields[numPrimFields + i].getType() + "\")"); > > - } > > - try { > > - writeObject0(objVals[i], > > - fields[numPrimFields + i].isUnshared()); > > - } finally { > > + int numObjFields = desc.getNumObjFields(); > > + if (numObjFields > 0) { > > + ObjectStreamField[] fields = desc.getFields(false); > > + Object[] objVals = new Object[numObjFields]; > > + int numPrimFields = fields.length - objVals.length; > > + desc.getObjFieldValues(obj, objVals); > > + for (int i = 0; i < objVals.length; i++) { > > if (extendedDebugInfo) { > > - debugInfoStack.pop(); > > + debugInfoStack.push( > > + "field (class \"" + desc.getName() + "\", name: > > \"" + > > + fields[numPrimFields + i].getName() + "\", > > type: \"" + > > + fields[numPrimFields + i].getType() + "\")"); > > + } > > + try { > > + writeObject0(objVals[i], > > + fields[numPrimFields + i].isUnshared()); > > + } finally { > > + if (extendedDebugInfo) { > > + debugInfoStack.pop(); > > + } > > } > > } > > } > > @@ -1743,15 +1749,11 @@ > > private static final int MAX_BLOCK_SIZE = 1024; > > /** maximum data block header length */ > > private static final int MAX_HEADER_SIZE = 5; > > - /** (tunable) length of char buffer (for writing strings) */ > > - private static final int CHAR_BUF_SIZE = 256; > > > > /** buffer for writing general/block data */ > > private final byte[] buf = new byte[MAX_BLOCK_SIZE]; > > /** buffer for writing block data headers */ > > private final byte[] hbuf = new byte[MAX_HEADER_SIZE]; > > - /** char buffer for fast string writes */ > > - private final char[] cbuf = new char[CHAR_BUF_SIZE]; > > > > /** block data mode */ > > private boolean blkmode = false; > > @@ -1763,6 +1765,18 @@ > > /** loopback stream (for data writes that span data blocks) */ > > private final DataOutputStream dout; > > > > + /** use unsafe to directly access value field in > > java.lang.String */ > > + private static final Unsafe unsafe = Unsafe.getUnsafe(); > > + /** use field offset to directly access value field in > > java.lang.String */ > > + private static final long stringValueOffset; > > + static { > > + try { > > + stringValueOffset = > > unsafe.objectFieldOffset(String.class.getDeclaredField("value")); > > + } catch (NoSuchFieldException e) { > > + throw new InternalError(e); > > + } > > + } > > + > > /** > > * Creates new BlockDataOutputStream on top of given > > underlying stream. > > * Block data mode is turned off by default. > > @@ -1972,35 +1986,23 @@ > > } > > > > public void writeBytes(String s) throws IOException { > > - int endoff = s.length(); > > - int cpos = 0; > > - int csize = 0; > > + char[] sChars = (char[])unsafe.getObject(s, stringValueOffset); > > + int endoff = sChars.length; > > for (int off = 0; off < endoff; ) { > > - if (cpos >= csize) { > > - cpos = 0; > > - csize = Math.min(endoff - off, CHAR_BUF_SIZE); > > - s.getChars(off, off + csize, cbuf, 0); > > - } > > if (pos >= MAX_BLOCK_SIZE) { > > drain(); > > } > > - int n = Math.min(csize - cpos, MAX_BLOCK_SIZE - pos); > > + int n = Math.min(endoff - off, MAX_BLOCK_SIZE - pos); > > int stop = pos + n; > > while (pos < stop) { > > - buf[pos++] = (byte) cbuf[cpos++]; > > + buf[pos++] = (byte) sChars[off++]; > > } > > - off += n; > > } > > } > > > > public void writeChars(String s) throws IOException { > > - int endoff = s.length(); > > - for (int off = 0; off < endoff; ) { > > - int csize = Math.min(endoff - off, CHAR_BUF_SIZE); > > - s.getChars(off, off + csize, cbuf, 0); > > - writeChars(cbuf, 0, csize); > > - off += csize; > > - } > > + char[] sChars = (char[])unsafe.getObject(s, stringValueOffset); > > + writeChars(sChars, 0, sChars.length); > > } > > > > public void writeUTF(String s) throws IOException { > > @@ -2130,25 +2132,21 @@ > > } > > > > /** > > - * Returns the length in bytes of the UTF encoding of the given > > string. > > + * Returns the length in bytes of the UTF encoding of this > > given string. > > */ > > - long getUTFLength(String s) { > > - int len = s.length(); > > + static long getUTFLength(String s) { > > + char[] value = (char[])unsafe.getObject(s, stringValueOffset); > > + int len = value.length; > > long utflen = 0; > > for (int off = 0; off < len; ) { > > - int csize = Math.min(len - off, CHAR_BUF_SIZE); > > - s.getChars(off, off + csize, cbuf, 0); > > - for (int cpos = 0; cpos < csize; cpos++) { > > - char c = cbuf[cpos]; > > - if (c >= 0x0001 && c <= 0x007F) { > > - utflen++; > > - } else if (c > 0x07FF) { > > - utflen += 3; > > - } else { > > - utflen += 2; > > - } > > + char c = value[off++]; > > + if (c >= 0x0001 && c <= 0x007F) { > > + utflen++; > > + } else if (c > 0x07FF) { > > + utflen += 3; > > + } else { > > + utflen += 2; > > } > > - off += csize; > > } > > return utflen; > > } > > @@ -2198,40 +2196,36 @@ > > * 8-byte length header) of the UTF encoding for the given string. > > */ > > private void writeUTFBody(String s) throws IOException { > > + char[] sChars = (char[])unsafe.getObject(s, stringValueOffset); > > + int len = sChars.length; > > int limit = MAX_BLOCK_SIZE - 3; > > - int len = s.length(); > > for (int off = 0; off < len; ) { > > - int csize = Math.min(len - off, CHAR_BUF_SIZE); > > - s.getChars(off, off + csize, cbuf, 0); > > - for (int cpos = 0; cpos < csize; cpos++) { > > - char c = cbuf[cpos]; > > - if (pos <= limit) { > > - if (c <= 0x007F && c != 0) { > > - buf[pos++] = (byte) c; > > - } else if (c > 0x07FF) { > > - buf[pos + 2] = (byte) (0x80 | ((c >> 0) & > > 0x3F)); > > - buf[pos + 1] = (byte) (0x80 | ((c >> 6) & > > 0x3F)); > > - buf[pos + 0] = (byte) (0xE0 | ((c >> 12) & > > 0x0F)); > > - pos += 3; > > - } else { > > - buf[pos + 1] = (byte) (0x80 | ((c >> 0) & > > 0x3F)); > > - buf[pos + 0] = (byte) (0xC0 | ((c >> 6) & > > 0x1F)); > > - pos += 2; > > - } > > - } else { // write one byte at a time to > > normalize block > > - if (c <= 0x007F && c != 0) { > > - write(c); > > - } else if (c > 0x07FF) { > > - write(0xE0 | ((c >> 12) & 0x0F)); > > - write(0x80 | ((c >> 6) & 0x3F)); > > - write(0x80 | ((c >> 0) & 0x3F)); > > - } else { > > - write(0xC0 | ((c >> 6) & 0x1F)); > > - write(0x80 | ((c >> 0) & 0x3F)); > > - } > > + char c = sChars[off++]; > > + if (pos <= limit) { > > + if (c <= 0x007F && c != 0) { > > + buf[pos++] = (byte) c; > > + } else if (c > 0x07FF) { > > + buf[pos + 2] = (byte) (0x80 | ( c & 0x3F)); > > + buf[pos + 1] = (byte) (0x80 | ((c >> 6) & 0x3F)); > > + buf[pos ] = (byte) (0xE0 | ((c >> 12) & 0x0F)); > > + pos += 3; > > + } else { > > + buf[pos + 1] = (byte) (0x80 | ( c & 0x3F)); > > + buf[pos ] = (byte) (0xC0 | ((c >> 6) & 0x1F)); > > + pos += 2; > > + } > > + } else { // write one byte at a time to normalize block > > + if (c <= 0x007F && c != 0) { > > + write(c); > > + } else if (c > 0x07FF) { > > + write(0xE0 | ((c >> 12) & 0x0F)); > > + write(0x80 | ((c >> 6) & 0x3F)); > > + write(0x80 | ( c & 0x3F)); > > + } else { > > + write(0xC0 | ((c >> 6) & 0x1F)); > > + write(0x80 | ( c & 0x3F)); > > } > > } > > - off += csize; > > } > > } > > } > > @@ -2464,7 +2458,10 @@ > > StringBuilder buffer = new StringBuilder(); > > if (!stack.isEmpty()) { > > for(int i = stack.size(); i > 0; i-- ) { > > - buffer.append(stack.get(i-1) + ((i != 1) ? "\n" : "")); > > + buffer.append(stack.get(i - 1)); > > + if (i!=1) { > > + buffer.append('\n'); > > + } > > } > > } > > return buffer.toString(); > > diff --git a/src/share/classes/java/io/ObjectStreamClass.java > > b/src/share/classes/java/io/ObjectStreamClass.java > > --- a/src/share/classes/java/io/ObjectStreamClass.java > > +++ b/src/share/classes/java/io/ObjectStreamClass.java > > @@ -1474,7 +1474,28 @@ > > /** > > * Returns JVM type signature for given class. > > */ > > - private static String getClassSignature(Class cl) { > > + static String getClassSignature(Class cl) { > > + if (cl.isPrimitive()) > > + if (cl == Integer.TYPE) { > > + return "I"; > > + } else if (cl == Byte.TYPE) { > > + return "B"; > > + } else if (cl == Long.TYPE) { > > + return "J"; > > + } else if (cl == Float.TYPE) { > > + return "F"; > > + } else if (cl == Double.TYPE) { > > + return "D"; > > + } else if (cl == Short.TYPE) { > > + return "S"; > > + } else if (cl == Character.TYPE) { > > + return "C"; > > + } else if (cl == Boolean.TYPE) { > > + return "Z"; > > + } else if (cl == Void.TYPE) { > > + return "V"; > > + } > > + > > StringBuilder sbuf = new StringBuilder(); > > while (cl.isArray()) { > > sbuf.append('['); > > @@ -1503,7 +1524,7 @@ > > throw new InternalError(); > > } > > } else { > > - sbuf.append('L' + cl.getName().replace('.', '/') + ';'); > > + sbuf.append('L').append(cl.getName().replace('.', > > '/')).append(';'); > > } > > return sbuf.toString(); > > } > > diff --git a/src/share/classes/java/io/ObjectStreamField.java > > b/src/share/classes/java/io/ObjectStreamField.java > > --- a/src/share/classes/java/io/ObjectStreamField.java > > +++ b/src/share/classes/java/io/ObjectStreamField.java > > @@ -91,7 +91,7 @@ > > this.name = name; > > this.type = type; > > this.unshared = unshared; > > - signature = getClassSignature(type).intern(); > > + signature = ObjectStreamClass.getClassSignature(type).intern(); > > field = null; > > } > > > > @@ -137,7 +137,7 @@ > > name = field.getName(); > > Class ftype = field.getType(); > > type = (showType || ftype.isPrimitive()) ? ftype : Object.class; > > - signature = getClassSignature(ftype).intern(); > > + signature = ObjectStreamClass.getClassSignature(ftype).intern(); > > } > > > > /** > > @@ -286,41 +286,4 @@ > > String getSignature() { > > return signature; > > } > > - > > - /** > > - * Returns JVM type signature for given class. > > - */ > > - private static String getClassSignature(Class cl) { > > - StringBuilder sbuf = new StringBuilder(); > > - while (cl.isArray()) { > > - sbuf.append('['); > > - cl = cl.getComponentType(); > > - } > > - if (cl.isPrimitive()) { > > - if (cl == Integer.TYPE) { > > - sbuf.append('I'); > > - } else if (cl == Byte.TYPE) { > > - sbuf.append('B'); > > - } else if (cl == Long.TYPE) { > > - sbuf.append('J'); > > - } else if (cl == Float.TYPE) { > > - sbuf.append('F'); > > - } else if (cl == Double.TYPE) { > > - sbuf.append('D'); > > - } else if (cl == Short.TYPE) { > > - sbuf.append('S'); > > - } else if (cl == Character.TYPE) { > > - sbuf.append('C'); > > - } else if (cl == Boolean.TYPE) { > > - sbuf.append('Z'); > > - } else if (cl == Void.TYPE) { > > - sbuf.append('V'); > > - } else { > > - throw new InternalError(); > > - } > > - } else { > > - sbuf.append('L' + cl.getName().replace('.', '/') + ';'); > > - } > > - return sbuf.toString(); > > - } > > } > > *Gesendet:* Dienstag, 07. Januar 2014 um 10:05 Uhr > > *Von:* "Chris Hegarty" > > *An:* "Robert Stupp" > > *Cc:* "core-libs-dev at openjdk.java.net Libs" > > *Betreff:* Re: ObjectIn/OutputStream improvements > > On 15 Dec 2013, at 10:29, Robert Stupp wrote: > > > > > Hi, > > > > > > I digged through the object serialization code and found some lines > > that could be optimized to reduce the number of calls to > > System.arraycopy() and temporary object allocations especially during > > string (de)serialization. > > > In short sentences the changes are: > > > ObjectInputStream: > > > - skip primitive/object reading if no primitive/objects in class > > (defaultReadFields method) > > > - use shared StringBuilder for string reading (prevent superfluous > > object allocations of one StingBuilder and one implicit char[] for each > > string being deserialized) > > > ObjectOutputStream: > > > - skip primitive/object writing if no primitive/objects in class > > (defaultWriteFields method) > > > - use unsafe access to calculate UTF-length > > > - use unsafe access in readBytes() and writeChars() methods to access > > String value field > > > - removed cbuf field > > > ObjectStreamClass/ObjectStreamField: > > > - minor improvement in getClassSignature ; share method code with > > ObjectStreamField (return constant string for primitives) > > > > > > I have tested the changes in a big Java installation at a customer > > (backported the Java8 ObjectIn/OutputStream including the changes to > > Java6) and a long running real application performance test resulted in > > reduced CPU usage (from about 60% per server to 50%). > > > The changes I made in openjdk8 pass all tests. > > > > > > Since I have no experience how to contribute code to openjdk in form > > of a push/changeset I have added the diff (hg export -g) to this email. > > > > Did you attach the diffs? I don?t see any attachment, it may be that the > > attachment was stripped. Can you try resending inline? > > > > You should take a look at the OpenJDK How to Contribute page [1]. Paying > > particular attention to the OCA, without it we will not be able to move > > your patch forward. > > > > Thanks, > > -Chris. > > > > [1] http://openjdk.java.net/contribute/ > > > > > > > > Robert > > > > > > From stuart.marks at oracle.com Fri Jan 31 19:07:48 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 31 Jan 2014 11:07:48 -0800 Subject: ObjectIn/OutputStream improvements In-Reply-To: References: <91644C57-6E0D-48ED-8E31-6AC217DECCEF@gmx.de>, <1C96B28E-5E20-4D8D-B1FD-8FD5DF193EC8@oracle.com> <52EBB1B8.2030401@oracle.com> Message-ID: <52EBF484.9070909@oracle.com> On 1/31/14 10:46 AM, Chris Hegarty wrote: > I think your patch can be split into two logical, independent, parts. The > first is the use of unsafe to access the String UTF length. The seconds is > to reuse, where possible, the existing StringBuilder instances, skipping of > primitive/object reading/writing where applicable, and general cleanup. > > Since this is a very sensitive area I would like to consider these > separately. To that end, I have taken the changes that are applicable to the > latter, removed any subjective stylistic changes, and made some additional > cleanup improvements. > > http://cr.openjdk.java.net/~chegar/serial_stupp.00/webrev/ I agree with splitting the Unsafe usages so they can be reviewed separately. New and changed usage of Unsafe will require exacting scrutiny. In general, the cleanups and refactorings look fine. I have a question about the change to reuse StringBuilder instances. This replaces freshly allocated StringBuilders stored in local variables with reuse of a StringBuilder stored in a field of BlockDataInputStream, which in turn is stored in a field of ObjectInputStream. Thus, instead of creating of lots of temporaries that become gc-eligible very quickly, this creates a single long-lived object whose size is the high-water mark of the longest string that's been read. The change does reduce allocation pressure, but the point of generational GC is to make allocation and collection of temporaries quite inexpensive. Is this the right tradeoff? s'marks From christian.thalinger at oracle.com Fri Jan 31 19:22:18 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 31 Jan 2014 11:22:18 -0800 Subject: [8] RFR (S): 8033278: Missed access checks for Lookup.unreflect* after 8032585 In-Reply-To: <52EAF549.4070604@oracle.com> References: <52EAF549.4070604@oracle.com> Message-ID: <429800DA-0A50-4212-82C6-D7BAB24D1344@oracle.com> Looks good. On Jan 30, 2014, at 4:58 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8033278/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8033278 > > The fix for 8032585 [1] introduced a regression: in some cases access > check on a reference class is omitted. > > The fix is to ensure that access check on a reference class is always > performed. > > Testing: regression test, jdk/test/java/lang/invoke/, > jdk/test/java/util/stream, vm.defmeth.testlist, vm.mlvm.testlist, > nashorn (unit tests, octane), groovy > > Thanks! > > Best regards, > Vladimir Ivanov > > [1] http://cr.openjdk.java.net/~vlivanov/8032585/webrev.00/ > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From vladimir.x.ivanov at oracle.com Fri Jan 31 19:26:25 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 31 Jan 2014 23:26:25 +0400 Subject: [8] RFR (S): 8033278: Missed access checks for Lookup.unreflect* after 8032585 In-Reply-To: <429800DA-0A50-4212-82C6-D7BAB24D1344@oracle.com> References: <52EAF549.4070604@oracle.com> <429800DA-0A50-4212-82C6-D7BAB24D1344@oracle.com> Message-ID: <52EBF8E1.3080404@oracle.com> Chris, thank you. Best regards, Vladimir Ivanov On 1/31/14 11:22 PM, Christian Thalinger wrote: > Looks good. > > On Jan 30, 2014, at 4:58 PM, Vladimir Ivanov wrote: > >> http://cr.openjdk.java.net/~vlivanov/8033278/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8033278 >> >> The fix for 8032585 [1] introduced a regression: in some cases access >> check on a reference class is omitted. >> >> The fix is to ensure that access check on a reference class is always >> performed. >> >> Testing: regression test, jdk/test/java/lang/invoke/, >> jdk/test/java/util/stream, vm.defmeth.testlist, vm.mlvm.testlist, >> nashorn (unit tests, octane), groovy >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov >> >> [1] http://cr.openjdk.java.net/~vlivanov/8032585/webrev.00/ >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From chris.hegarty at oracle.com Fri Jan 31 19:26:36 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 31 Jan 2014 19:26:36 +0000 Subject: ObjectIn/OutputStream improvements In-Reply-To: <52EBF484.9070909@oracle.com> References: <91644C57-6E0D-48ED-8E31-6AC217DECCEF@gmx.de>, <1C96B28E-5E20-4D8D-B1FD-8FD5DF193EC8@oracle.com> <52EBB1B8.2030401@oracle.com> <52EBF484.9070909@oracle.com> Message-ID: On 31 Jan 2014, at 19:07, Stuart Marks wrote: > On 1/31/14 10:46 AM, Chris Hegarty wrote: >> I think your patch can be split into two logical, independent, parts. The >> first is the use of unsafe to access the String UTF length. The seconds is >> to reuse, where possible, the existing StringBuilder instances, skipping of >> primitive/object reading/writing where applicable, and general cleanup. >> >> Since this is a very sensitive area I would like to consider these >> separately. To that end, I have taken the changes that are applicable to the >> latter, removed any subjective stylistic changes, and made some additional >> cleanup improvements. >> >> http://cr.openjdk.java.net/~chegar/serial_stupp.00/webrev/ > > I agree with splitting the Unsafe usages so they can be reviewed separately. New > and changed usage of Unsafe will require exacting scrutiny. > > In general, the cleanups and refactorings look fine. > > I have a question about the change to reuse StringBuilder instances. This replaces freshly allocated StringBuilders stored in local variables with reuse of a StringBuilder stored in a field of BlockDataInputStream, which in turn is stored in a field of ObjectInputStream. Thus, instead of creating of lots of temporaries that become gc-eligible very quickly, this creates a single long-lived object whose size is the high-water mark of the longest string that's been read. The change does reduce allocation pressure, but the point of generational GC is to make allocation and collection of temporaries quite inexpensive. Is this the right tradeoff? Good point Stuart. I can?t imagine that reusing is a problem, provided we can release. It may be that we should look at clearing the reference, and others, in close(). -Chris. > > s'marks > From jason_mehrens at hotmail.com Fri Jan 31 19:43:22 2014 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Fri, 31 Jan 2014 13:43:22 -0600 Subject: RFR [9] 8011645: CopyOnWriteArrayList.COWSubList.subList does not validate range properly In-Reply-To: References: <52EBCE09.1030609@oracle.com>, Message-ID: Martin, Unifying the List testing code might be kind of tricky with https://bugs.openjdk.java.net/browse/JDK-4506427 as unresolved. http://docs.oracle.com/javase/7/docs/api/java/util/List.html http://docs.oracle.com/javase/7/docs/api/java/util/AbstractList.html The patch looks good though. Cheers, Jason > Date: Fri, 31 Jan 2014 10:07:31 -0800 > Subject: Re: RFR [9] 8011645: CopyOnWriteArrayList.COWSubList.subList does not validate range properly > From: martinrb at google.com > To: chris.hegarty at oracle.com > CC: core-libs-dev at openjdk.java.net > > The jtreg test is fine, but: > > s/IOBE/IOOBE/ > > When I created MOAT.java many years ago, I intended tests such as this to > get added to that, so that all of the List implementations could share the > same test code. jsr166 does not have the same concern, since it only has > one List implementation at the moment. Today, there are other choices, > like sharing test infrastructure with Guava e.g. ListTestSuiteBuilder. > More generally, openjdk core libraries can benefit from all the great > testing work that guava folk have done. > > > On Fri, Jan 31, 2014 at 8:23 AM, Chris Hegarty wrote: > > > Trivial change to CopyOnWriteArrayList.COWSubList.subList to catch the > > case where the fromIndex is greater that the toIndex. > > > > http://cr.openjdk.java.net/~chegar/8011645/webrev.00/webrev/ > > > > -Chris. > > From martinrb at google.com Fri Jan 31 19:50:39 2014 From: martinrb at google.com (Martin Buchholz) Date: Fri, 31 Jan 2014 11:50:39 -0800 Subject: RFR [9] 8011645: CopyOnWriteArrayList.COWSubList.subList does not validate range properly In-Reply-To: References: <52EBCE09.1030609@oracle.com> Message-ID: Jason, Thanks for pointing that out. I'm sure I have seen those bugs before (when I owned them!) but had suppressed the memory. I probably didn't try fixing them because there is no clean way out, and I was afraid of getting bogged down in compatibility hell for what is a non-issue for real-world users. On Fri, Jan 31, 2014 at 11:43 AM, Jason Mehrens wrote: > Martin, > > Unifying the List testing code might be kind of tricky with > https://bugs.openjdk.java.net/browse/JDK-4506427 as unresolved. > > http://docs.oracle.com/javase/7/docs/api/java/util/List.html > http://docs.oracle.com/javase/7/docs/api/java/util/AbstractList.html > > The patch looks good though. > > Cheers, > > Jason > > > Date: Fri, 31 Jan 2014 10:07:31 -0800 > > Subject: Re: RFR [9] 8011645: CopyOnWriteArrayList.COWSubList.subList > does not validate range properly > > From: martinrb at google.com > > To: chris.hegarty at oracle.com > > CC: core-libs-dev at openjdk.java.net > > > > > The jtreg test is fine, but: > > > > s/IOBE/IOOBE/ > > > > When I created MOAT.java many years ago, I intended tests such as this to > > get added to that, so that all of the List implementations could share > the > > same test code. jsr166 does not have the same concern, since it only has > > one List implementation at the moment. Today, there are other choices, > > like sharing test infrastructure with Guava e.g. ListTestSuiteBuilder. > > More generally, openjdk core libraries can benefit from all the great > > testing work that guava folk have done. > > > > > > On Fri, Jan 31, 2014 at 8:23 AM, Chris Hegarty >wrote: > > > > > Trivial change to CopyOnWriteArrayList.COWSubList.subList to catch the > > > case where the fromIndex is greater that the toIndex. > > > > > > http://cr.openjdk.java.net/~chegar/8011645/webrev.00/webrev/ > > > > > > -Chris. > > > > From mike.duigou at oracle.com Fri Jan 31 20:06:16 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 31 Jan 2014 12:06:16 -0800 Subject: RFR [9] 8011645: CopyOnWriteArrayList.COWSubList.subList does not validate range properly In-Reply-To: References: <52EBCE09.1030609@oracle.com> Message-ID: <84224D71-68C1-44EC-A539-1E38F4A9E4D9@oracle.com> On Jan 31 2014, at 11:50 , Martin Buchholz wrote: > Jason, > Thanks for pointing that out. I'm sure I have seen those bugs before (when > I owned them!) but had suppressed the memory. I'm currently the assignee for this bug. > I probably didn't try fixing them because there is no clean way out, and I > was afraid of getting bogged down in compatibility hell for what is a > non-issue for real-world users. Indeed. That's exactly why they still haven't been addressed. Suggestions are, of course, always welcome. Mike > > On Fri, Jan 31, 2014 at 11:43 AM, Jason Mehrens > wrote: > >> Martin, >> >> Unifying the List testing code might be kind of tricky with >> https://bugs.openjdk.java.net/browse/JDK-4506427 as unresolved. >> >> http://docs.oracle.com/javase/7/docs/api/java/util/List.html >> http://docs.oracle.com/javase/7/docs/api/java/util/AbstractList.html >> >> The patch looks good though. >> >> Cheers, >> >> Jason >> >>> Date: Fri, 31 Jan 2014 10:07:31 -0800 >>> Subject: Re: RFR [9] 8011645: CopyOnWriteArrayList.COWSubList.subList >> does not validate range properly >>> From: martinrb at google.com >>> To: chris.hegarty at oracle.com >>> CC: core-libs-dev at openjdk.java.net >> >>> >>> The jtreg test is fine, but: >>> >>> s/IOBE/IOOBE/ >>> >>> When I created MOAT.java many years ago, I intended tests such as this to >>> get added to that, so that all of the List implementations could share >> the >>> same test code. jsr166 does not have the same concern, since it only has >>> one List implementation at the moment. Today, there are other choices, >>> like sharing test infrastructure with Guava e.g. ListTestSuiteBuilder. >>> More generally, openjdk core libraries can benefit from all the great >>> testing work that guava folk have done. >>> >>> >>> On Fri, Jan 31, 2014 at 8:23 AM, Chris Hegarty >> wrote: >>> >>>> Trivial change to CopyOnWriteArrayList.COWSubList.subList to catch the >>>> case where the fromIndex is greater that the toIndex. >>>> >>>> http://cr.openjdk.java.net/~chegar/8011645/webrev.00/webrev/ >>>> >>>> -Chris. >>>> >> From mike.duigou at oracle.com Fri Jan 31 20:27:36 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 31 Jan 2014 12:27:36 -0800 Subject: ObjectIn/OutputStream improvements In-Reply-To: References: <91644C57-6E0D-48ED-8E31-6AC217DECCEF@gmx.de>, <1C96B28E-5E20-4D8D-B1FD-8FD5DF193EC8@oracle.com> <52EBB1B8.2030401@oracle.com> Message-ID: <9A31C421-CBDC-4196-A74C-0CB5E2447CB6@oracle.com> Seems like good changes. ObjectStreamClass.java:: - Why not have getClassSignature() return an interned string? (that's if interning is actually essential. Are we sure it's not just overhead?) On Jan 31 2014, at 10:46 , Chris Hegarty wrote: > Forwarding to correct core-libs-dev list. > > -Chris. > > On 31 Jan 2014, at 14:22, Chris Hegarty wrote: > >> Hi Robert, >> >> I think your patch can be split into two logical, independent, parts. The first is the use of unsafe to access the String UTF length. The seconds is to reuse, where possible, the existing StringBuilder instances, skipping of primitive/object reading/writing where applicable, and general cleanup. >> >> Since this is a very sensitive area I would like to consider these separately. To that end, I have taken the changes that are applicable to the latter, removed any subjective stylistic changes, and made some additional cleanup improvements. >> >> http://cr.openjdk.java.net/~chegar/serial_stupp.00/webrev/ >> >> Specifically, >> * I think for clarify and readability SerialCallbackContext >> checkAndSetUsed() should be invoked directly. It makes it very >> clear what the intent is. >> * Skip primitive/object reading/writing if no primitives/objects in >> the stream/class. ( I personally don't see any benefit of rounding >> up the size of the array, it just seems to add unnecessary >> complexity ) >> * Move primitive types into getPrimitiveSignature for better reuse >> of code. This retains your change to not create the additional >> StringBuilder when it is not necessary. >> >> I am currently running tests on this change. >> >> -Chris. >> >> On 07/01/14 13:03, Robert Stupp wrote: >>> Hi, >>> I've attached the diff to the original email - it has been stripped. >>> Here's a second try (inline). >>> I've already signed the OCA and it has been approved :) >>> Robert >>> # HG changeset patch >>> # User snazy >>> # Date 1387101091 -3600 >>> # Sun Dec 15 10:51:31 2013 +0100 >>> # Node ID 6d46d99212453017c88417678d08dc8f10da9606 >>> # Parent 9e1be800420265e5dcf264a7ed4abb6f230dd19d >>> Removed some unnecessary variable assignments. >>> ObjectInputStream: >>> - skip primitive/object reading if no primitive/objects in class >>> - use shared StringBuilder for string reading (prevent superfluous >>> object allocations) >>> ObjectOutputStream: >>> - skip primitive/object writing if no primitive/objects in class >>> - use unsafe access to calculate UTF-length >>> - use unsafe access in readBytes() and writeChars() methods to access >>> String value field >>> - removed cbuf field >>> ObjectStreamClass/ObjectStreamField: >>> - minor improvement in getClassSignature ; share method code with >>> ObjectStreamField >>> diff --git a/src/share/classes/java/io/ObjectInputStream.java >>> b/src/share/classes/java/io/ObjectInputStream.java >>> --- a/src/share/classes/java/io/ObjectInputStream.java >>> +++ b/src/share/classes/java/io/ObjectInputStream.java >>> @@ -39,8 +39,8 @@ >>> import java.util.HashMap; >>> import java.util.concurrent.ConcurrentHashMap; >>> import java.util.concurrent.ConcurrentMap; >>> -import java.util.concurrent.atomic.AtomicBoolean; >>> import static java.io.ObjectStreamClass.processQueue; >>> + >>> import sun.reflect.misc.ReflectUtil; >>> >>> /** >>> @@ -534,7 +534,7 @@ >>> if (ctx == null) { >>> throw new NotActiveException("not in call to readObject"); >>> } >>> - Object curObj = ctx.getObj(); >>> + ctx.getObj(); >>> ObjectStreamClass curDesc = ctx.getDesc(); >>> bin.setBlockDataMode(false); >>> GetFieldImpl getField = new GetFieldImpl(curDesc); >>> @@ -1597,7 +1597,7 @@ >>> int descHandle = handles.assign(unshared ? unsharedMarker : desc); >>> passHandle = NULL_HANDLE; >>> >>> - ObjectStreamClass readDesc = null; >>> + ObjectStreamClass readDesc; >>> try { >>> readDesc = readClassDescriptor(); >>> } catch (ClassNotFoundException ex) { >>> @@ -1976,29 +1976,34 @@ >>> } >>> >>> int primDataSize = desc.getPrimDataSize(); >>> - if (primVals == null || primVals.length < primDataSize) { >>> - primVals = new byte[primDataSize]; >>> - } >>> - bin.readFully(primVals, 0, primDataSize, false); >>> - if (obj != null) { >>> - desc.setPrimFieldValues(obj, primVals); >>> - } >>> - >>> - int objHandle = passHandle; >>> - ObjectStreamField[] fields = desc.getFields(false); >>> - Object[] objVals = new Object[desc.getNumObjFields()]; >>> - int numPrimFields = fields.length - objVals.length; >>> - for (int i = 0; i < objVals.length; i++) { >>> - ObjectStreamField f = fields[numPrimFields + i]; >>> - objVals[i] = readObject0(f.isUnshared()); >>> - if (f.getField() != null) { >>> - handles.markDependency(objHandle, passHandle); >>> + if (primDataSize > 0) { >>> + if (primVals == null || primVals.length < primDataSize) { >>> + primVals = new byte[ ((primDataSize>>4)+1)<<4 ]; >>> + } >>> + bin.readFully(primVals, 0, primDataSize, false); >>> + if (obj != null) { >>> + desc.setPrimFieldValues(obj, primVals); >>> } >>> } >>> - if (obj != null) { >>> - desc.setObjFieldValues(obj, objVals); >>> + >>> + int numObjFields = desc.getNumObjFields(); >>> + if (numObjFields > 0) { >>> + int objHandle = passHandle; >>> + ObjectStreamField[] fields = desc.getFields(false); >>> + Object[] objVals = new Object[numObjFields]; >>> + int numPrimFields = fields.length - objVals.length; >>> + for (int i = 0; i < objVals.length; i++) { >>> + ObjectStreamField f = fields[numPrimFields + i]; >>> + objVals[i] = readObject0(f.isUnshared()); >>> + if (f.getField() != null) { >>> + handles.markDependency(objHandle, passHandle); >>> + } >>> + } >>> + if (obj != null) { >>> + desc.setObjFieldValues(obj, objVals); >>> + } >>> + passHandle = objHandle; >>> } >>> - passHandle = objHandle; >>> } >>> >>> /** >>> @@ -2377,8 +2382,10 @@ >>> private final byte[] buf = new byte[MAX_BLOCK_SIZE]; >>> /** buffer for reading block data headers */ >>> private final byte[] hbuf = new byte[MAX_HEADER_SIZE]; >>> - /** char buffer for fast string reads */ >>> + /** char buffer for fast string reads - used by {@link >>> #readUTFSpan(long)} */ >>> private final char[] cbuf = new char[CHAR_BUF_SIZE]; >>> + /** shared string builder for less object allocations - used by >>> {@link #readUTFBody(long)}, {@link #readUTFChar(long)} and {@link >>> #readUTFSpan(long)} */ >>> + private final StringBuilder sbuf = new >>> StringBuilder(CHAR_BUF_SIZE); >>> >>> /** block data mode */ >>> private boolean blkmode = false; >>> @@ -3044,19 +3051,19 @@ >>> * utflen bytes. >>> */ >>> private String readUTFBody(long utflen) throws IOException { >>> - StringBuilder sbuf = new StringBuilder(); >>> if (!blkmode) { >>> end = pos = 0; >>> } >>> >>> + sbuf.setLength(0); >>> while (utflen > 0) { >>> int avail = end - pos; >>> if (avail >= 3 || (long) avail == utflen) { >>> - utflen -= readUTFSpan(sbuf, utflen); >>> + utflen -= readUTFSpan(utflen); >>> } else { >>> if (blkmode) { >>> // near block boundary, read one byte at a time >>> - utflen -= readUTFChar(sbuf, utflen); >>> + utflen -= readUTFChar(utflen); >>> } else { >>> // shift and refill buffer manually >>> if (avail > 0) { >>> @@ -3076,10 +3083,10 @@ >>> * Reads span of UTF-encoded characters out of internal buffer >>> * (starting at offset pos and ending at or before offset end), >>> * consuming no more than utflen bytes. Appends read >>> characters to >>> - * sbuf. Returns the number of bytes consumed. >>> + * {@link #sbuf}. Returns the number of bytes consumed. >>> */ >>> - private long readUTFSpan(StringBuilder sbuf, long utflen) >>> - throws IOException >>> + private long readUTFSpan(long utflen) >>> + throws IOException >>> { >>> int cpos = 0; >>> int start = pos; >>> @@ -3111,19 +3118,19 @@ >>> throw new UTFDataFormatException(); >>> } >>> cbuf[cpos++] = (char) (((b1 & 0x1F) << 6) | >>> - ((b2 & 0x3F) << 0)); >>> + (b2 & 0x3F)); >>> break; >>> >>> case 14: // 3 byte format: 1110xxxx 10xxxxxx >>> 10xxxxxx >>> b3 = buf[pos + 1]; >>> - b2 = buf[pos + 0]; >>> + b2 = buf[pos ]; >>> pos += 2; >>> if ((b2 & 0xC0) != 0x80 || (b3 & 0xC0) != >>> 0x80) { >>> throw new UTFDataFormatException(); >>> } >>> cbuf[cpos++] = (char) (((b1 & 0x0F) << 12) | >>> - ((b2 & 0x3F) << 6) | >>> - ((b3 & 0x3F) << 0)); >>> + ((b2 & 0x3F) << 6) | >>> + (b3 & 0x3F)); >>> break; >>> >>> default: // 10xx xxxx, 1111 xxxx >>> @@ -3150,12 +3157,12 @@ >>> >>> /** >>> * Reads in single UTF-encoded character one byte at a time, >>> appends >>> - * the character to sbuf, and returns the number of bytes consumed. >>> + * the character to {@link #sbuf}, and returns the number of >>> bytes consumed. >>> * This method is used when reading in UTF strings written in >>> block >>> * data mode to handle UTF-encoded characters which (potentially) >>> * straddle block-data boundaries. >>> */ >>> - private int readUTFChar(StringBuilder sbuf, long utflen) >>> + private int readUTFChar(long utflen) >>> throws IOException >>> { >>> int b1, b2, b3; >>> @@ -3181,8 +3188,7 @@ >>> if ((b2 & 0xC0) != 0x80) { >>> throw new UTFDataFormatException(); >>> } >>> - sbuf.append((char) (((b1 & 0x1F) << 6) | >>> - ((b2 & 0x3F) << 0))); >>> + sbuf.append((char) (((b1 & 0x1F) << 6) | (b2 & 0x3F))); >>> return 2; >>> >>> case 14: // 3 byte format: 1110xxxx 10xxxxxx 10xxxxxx >>> @@ -3198,8 +3204,8 @@ >>> throw new UTFDataFormatException(); >>> } >>> sbuf.append((char) (((b1 & 0x0F) << 12) | >>> - ((b2 & 0x3F) << 6) | >>> - ((b3 & 0x3F) << 0))); >>> + ((b2 & 0x3F) << 6) | >>> + (b3 & 0x3F))); >>> return 3; >>> >>> default: // 10xx xxxx, 1111 xxxx >>> diff --git a/src/share/classes/java/io/ObjectOutputStream.java >>> b/src/share/classes/java/io/ObjectOutputStream.java >>> --- a/src/share/classes/java/io/ObjectOutputStream.java >>> +++ b/src/share/classes/java/io/ObjectOutputStream.java >>> @@ -35,7 +35,8 @@ >>> import java.util.concurrent.ConcurrentHashMap; >>> import java.util.concurrent.ConcurrentMap; >>> import static java.io.ObjectStreamClass.processQueue; >>> -import java.io.SerialCallbackContext; >>> + >>> +import sun.misc.Unsafe; >>> import sun.reflect.misc.ReflectUtil; >>> >>> /** >>> @@ -458,7 +459,7 @@ >>> if (ctx == null) { >>> throw new NotActiveException("not in call to >>> writeObject"); >>> } >>> - Object curObj = ctx.getObj(); >>> + ctx.getObj(); >>> ObjectStreamClass curDesc = ctx.getDesc(); >>> curPut = new PutFieldImpl(curDesc); >>> } >>> @@ -1300,7 +1301,7 @@ >>> */ >>> private void writeString(String str, boolean unshared) throws >>> IOException { >>> handles.assign(unshared ? null : str); >>> - long utflen = bout.getUTFLength(str); >>> + long utflen = BlockDataOutputStream.getUTFLength(str); >>> if (utflen <= 0xFFFF) { >>> bout.writeByte(TC_STRING); >>> bout.writeUTF(str, utflen); >>> @@ -1527,29 +1528,34 @@ >>> desc.checkDefaultSerialize(); >>> >>> int primDataSize = desc.getPrimDataSize(); >>> - if (primVals == null || primVals.length < primDataSize) { >>> - primVals = new byte[primDataSize]; >>> + if (primDataSize > 0) { >>> + if (primVals == null || primVals.length < primDataSize) { >>> + primVals = new byte[ ((primDataSize>>4)+1)<<4 ]; >>> + } >>> + desc.getPrimFieldValues(obj, primVals); >>> + bout.write(primVals, 0, primDataSize, false); >>> } >>> - desc.getPrimFieldValues(obj, primVals); >>> - bout.write(primVals, 0, primDataSize, false); >>> >>> - ObjectStreamField[] fields = desc.getFields(false); >>> - Object[] objVals = new Object[desc.getNumObjFields()]; >>> - int numPrimFields = fields.length - objVals.length; >>> - desc.getObjFieldValues(obj, objVals); >>> - for (int i = 0; i < objVals.length; i++) { >>> - if (extendedDebugInfo) { >>> - debugInfoStack.push( >>> - "field (class \"" + desc.getName() + "\", name: \"" + >>> - fields[numPrimFields + i].getName() + "\", type: \"" + >>> - fields[numPrimFields + i].getType() + "\")"); >>> - } >>> - try { >>> - writeObject0(objVals[i], >>> - fields[numPrimFields + i].isUnshared()); >>> - } finally { >>> + int numObjFields = desc.getNumObjFields(); >>> + if (numObjFields > 0) { >>> + ObjectStreamField[] fields = desc.getFields(false); >>> + Object[] objVals = new Object[numObjFields]; >>> + int numPrimFields = fields.length - objVals.length; >>> + desc.getObjFieldValues(obj, objVals); >>> + for (int i = 0; i < objVals.length; i++) { >>> if (extendedDebugInfo) { >>> - debugInfoStack.pop(); >>> + debugInfoStack.push( >>> + "field (class \"" + desc.getName() + "\", name: >>> \"" + >>> + fields[numPrimFields + i].getName() + "\", >>> type: \"" + >>> + fields[numPrimFields + i].getType() + "\")"); >>> + } >>> + try { >>> + writeObject0(objVals[i], >>> + fields[numPrimFields + i].isUnshared()); >>> + } finally { >>> + if (extendedDebugInfo) { >>> + debugInfoStack.pop(); >>> + } >>> } >>> } >>> } >>> @@ -1743,15 +1749,11 @@ >>> private static final int MAX_BLOCK_SIZE = 1024; >>> /** maximum data block header length */ >>> private static final int MAX_HEADER_SIZE = 5; >>> - /** (tunable) length of char buffer (for writing strings) */ >>> - private static final int CHAR_BUF_SIZE = 256; >>> >>> /** buffer for writing general/block data */ >>> private final byte[] buf = new byte[MAX_BLOCK_SIZE]; >>> /** buffer for writing block data headers */ >>> private final byte[] hbuf = new byte[MAX_HEADER_SIZE]; >>> - /** char buffer for fast string writes */ >>> - private final char[] cbuf = new char[CHAR_BUF_SIZE]; >>> >>> /** block data mode */ >>> private boolean blkmode = false; >>> @@ -1763,6 +1765,18 @@ >>> /** loopback stream (for data writes that span data blocks) */ >>> private final DataOutputStream dout; >>> >>> + /** use unsafe to directly access value field in >>> java.lang.String */ >>> + private static final Unsafe unsafe = Unsafe.getUnsafe(); >>> + /** use field offset to directly access value field in >>> java.lang.String */ >>> + private static final long stringValueOffset; >>> + static { >>> + try { >>> + stringValueOffset = >>> unsafe.objectFieldOffset(String.class.getDeclaredField("value")); >>> + } catch (NoSuchFieldException e) { >>> + throw new InternalError(e); >>> + } >>> + } >>> + >>> /** >>> * Creates new BlockDataOutputStream on top of given >>> underlying stream. >>> * Block data mode is turned off by default. >>> @@ -1972,35 +1986,23 @@ >>> } >>> >>> public void writeBytes(String s) throws IOException { >>> - int endoff = s.length(); >>> - int cpos = 0; >>> - int csize = 0; >>> + char[] sChars = (char[])unsafe.getObject(s, stringValueOffset); >>> + int endoff = sChars.length; >>> for (int off = 0; off < endoff; ) { >>> - if (cpos >= csize) { >>> - cpos = 0; >>> - csize = Math.min(endoff - off, CHAR_BUF_SIZE); >>> - s.getChars(off, off + csize, cbuf, 0); >>> - } >>> if (pos >= MAX_BLOCK_SIZE) { >>> drain(); >>> } >>> - int n = Math.min(csize - cpos, MAX_BLOCK_SIZE - pos); >>> + int n = Math.min(endoff - off, MAX_BLOCK_SIZE - pos); >>> int stop = pos + n; >>> while (pos < stop) { >>> - buf[pos++] = (byte) cbuf[cpos++]; >>> + buf[pos++] = (byte) sChars[off++]; >>> } >>> - off += n; >>> } >>> } >>> >>> public void writeChars(String s) throws IOException { >>> - int endoff = s.length(); >>> - for (int off = 0; off < endoff; ) { >>> - int csize = Math.min(endoff - off, CHAR_BUF_SIZE); >>> - s.getChars(off, off + csize, cbuf, 0); >>> - writeChars(cbuf, 0, csize); >>> - off += csize; >>> - } >>> + char[] sChars = (char[])unsafe.getObject(s, stringValueOffset); >>> + writeChars(sChars, 0, sChars.length); >>> } >>> >>> public void writeUTF(String s) throws IOException { >>> @@ -2130,25 +2132,21 @@ >>> } >>> >>> /** >>> - * Returns the length in bytes of the UTF encoding of the given >>> string. >>> + * Returns the length in bytes of the UTF encoding of this >>> given string. >>> */ >>> - long getUTFLength(String s) { >>> - int len = s.length(); >>> + static long getUTFLength(String s) { >>> + char[] value = (char[])unsafe.getObject(s, stringValueOffset); >>> + int len = value.length; >>> long utflen = 0; >>> for (int off = 0; off < len; ) { >>> - int csize = Math.min(len - off, CHAR_BUF_SIZE); >>> - s.getChars(off, off + csize, cbuf, 0); >>> - for (int cpos = 0; cpos < csize; cpos++) { >>> - char c = cbuf[cpos]; >>> - if (c >= 0x0001 && c <= 0x007F) { >>> - utflen++; >>> - } else if (c > 0x07FF) { >>> - utflen += 3; >>> - } else { >>> - utflen += 2; >>> - } >>> + char c = value[off++]; >>> + if (c >= 0x0001 && c <= 0x007F) { >>> + utflen++; >>> + } else if (c > 0x07FF) { >>> + utflen += 3; >>> + } else { >>> + utflen += 2; >>> } >>> - off += csize; >>> } >>> return utflen; >>> } >>> @@ -2198,40 +2196,36 @@ >>> * 8-byte length header) of the UTF encoding for the given string. >>> */ >>> private void writeUTFBody(String s) throws IOException { >>> + char[] sChars = (char[])unsafe.getObject(s, stringValueOffset); >>> + int len = sChars.length; >>> int limit = MAX_BLOCK_SIZE - 3; >>> - int len = s.length(); >>> for (int off = 0; off < len; ) { >>> - int csize = Math.min(len - off, CHAR_BUF_SIZE); >>> - s.getChars(off, off + csize, cbuf, 0); >>> - for (int cpos = 0; cpos < csize; cpos++) { >>> - char c = cbuf[cpos]; >>> - if (pos <= limit) { >>> - if (c <= 0x007F && c != 0) { >>> - buf[pos++] = (byte) c; >>> - } else if (c > 0x07FF) { >>> - buf[pos + 2] = (byte) (0x80 | ((c >> 0) & >>> 0x3F)); >>> - buf[pos + 1] = (byte) (0x80 | ((c >> 6) & >>> 0x3F)); >>> - buf[pos + 0] = (byte) (0xE0 | ((c >> 12) & >>> 0x0F)); >>> - pos += 3; >>> - } else { >>> - buf[pos + 1] = (byte) (0x80 | ((c >> 0) & >>> 0x3F)); >>> - buf[pos + 0] = (byte) (0xC0 | ((c >> 6) & >>> 0x1F)); >>> - pos += 2; >>> - } >>> - } else { // write one byte at a time to >>> normalize block >>> - if (c <= 0x007F && c != 0) { >>> - write(c); >>> - } else if (c > 0x07FF) { >>> - write(0xE0 | ((c >> 12) & 0x0F)); >>> - write(0x80 | ((c >> 6) & 0x3F)); >>> - write(0x80 | ((c >> 0) & 0x3F)); >>> - } else { >>> - write(0xC0 | ((c >> 6) & 0x1F)); >>> - write(0x80 | ((c >> 0) & 0x3F)); >>> - } >>> + char c = sChars[off++]; >>> + if (pos <= limit) { >>> + if (c <= 0x007F && c != 0) { >>> + buf[pos++] = (byte) c; >>> + } else if (c > 0x07FF) { >>> + buf[pos + 2] = (byte) (0x80 | ( c & 0x3F)); >>> + buf[pos + 1] = (byte) (0x80 | ((c >> 6) & 0x3F)); >>> + buf[pos ] = (byte) (0xE0 | ((c >> 12) & 0x0F)); >>> + pos += 3; >>> + } else { >>> + buf[pos + 1] = (byte) (0x80 | ( c & 0x3F)); >>> + buf[pos ] = (byte) (0xC0 | ((c >> 6) & 0x1F)); >>> + pos += 2; >>> + } >>> + } else { // write one byte at a time to normalize block >>> + if (c <= 0x007F && c != 0) { >>> + write(c); >>> + } else if (c > 0x07FF) { >>> + write(0xE0 | ((c >> 12) & 0x0F)); >>> + write(0x80 | ((c >> 6) & 0x3F)); >>> + write(0x80 | ( c & 0x3F)); >>> + } else { >>> + write(0xC0 | ((c >> 6) & 0x1F)); >>> + write(0x80 | ( c & 0x3F)); >>> } >>> } >>> - off += csize; >>> } >>> } >>> } >>> @@ -2464,7 +2458,10 @@ >>> StringBuilder buffer = new StringBuilder(); >>> if (!stack.isEmpty()) { >>> for(int i = stack.size(); i > 0; i-- ) { >>> - buffer.append(stack.get(i-1) + ((i != 1) ? "\n" : "")); >>> + buffer.append(stack.get(i - 1)); >>> + if (i!=1) { >>> + buffer.append('\n'); >>> + } >>> } >>> } >>> return buffer.toString(); >>> diff --git a/src/share/classes/java/io/ObjectStreamClass.java >>> b/src/share/classes/java/io/ObjectStreamClass.java >>> --- a/src/share/classes/java/io/ObjectStreamClass.java >>> +++ b/src/share/classes/java/io/ObjectStreamClass.java >>> @@ -1474,7 +1474,28 @@ >>> /** >>> * Returns JVM type signature for given class. >>> */ >>> - private static String getClassSignature(Class cl) { >>> + static String getClassSignature(Class cl) { >>> + if (cl.isPrimitive()) >>> + if (cl == Integer.TYPE) { >>> + return "I"; >>> + } else if (cl == Byte.TYPE) { >>> + return "B"; >>> + } else if (cl == Long.TYPE) { >>> + return "J"; >>> + } else if (cl == Float.TYPE) { >>> + return "F"; >>> + } else if (cl == Double.TYPE) { >>> + return "D"; >>> + } else if (cl == Short.TYPE) { >>> + return "S"; >>> + } else if (cl == Character.TYPE) { >>> + return "C"; >>> + } else if (cl == Boolean.TYPE) { >>> + return "Z"; >>> + } else if (cl == Void.TYPE) { >>> + return "V"; >>> + } >>> + >>> StringBuilder sbuf = new StringBuilder(); >>> while (cl.isArray()) { >>> sbuf.append('['); >>> @@ -1503,7 +1524,7 @@ >>> throw new InternalError(); >>> } >>> } else { >>> - sbuf.append('L' + cl.getName().replace('.', '/') + ';'); >>> + sbuf.append('L').append(cl.getName().replace('.', >>> '/')).append(';'); >>> } >>> return sbuf.toString(); >>> } >>> diff --git a/src/share/classes/java/io/ObjectStreamField.java >>> b/src/share/classes/java/io/ObjectStreamField.java >>> --- a/src/share/classes/java/io/ObjectStreamField.java >>> +++ b/src/share/classes/java/io/ObjectStreamField.java >>> @@ -91,7 +91,7 @@ >>> this.name = name; >>> this.type = type; >>> this.unshared = unshared; >>> - signature = getClassSignature(type).intern(); >>> + signature = ObjectStreamClass.getClassSignature(type).intern(); >>> field = null; >>> } >>> >>> @@ -137,7 +137,7 @@ >>> name = field.getName(); >>> Class ftype = field.getType(); >>> type = (showType || ftype.isPrimitive()) ? ftype : Object.class; >>> - signature = getClassSignature(ftype).intern(); >>> + signature = ObjectStreamClass.getClassSignature(ftype).intern(); >>> } >>> >>> /** >>> @@ -286,41 +286,4 @@ >>> String getSignature() { >>> return signature; >>> } >>> - >>> - /** >>> - * Returns JVM type signature for given class. >>> - */ >>> - private static String getClassSignature(Class cl) { >>> - StringBuilder sbuf = new StringBuilder(); >>> - while (cl.isArray()) { >>> - sbuf.append('['); >>> - cl = cl.getComponentType(); >>> - } >>> - if (cl.isPrimitive()) { >>> - if (cl == Integer.TYPE) { >>> - sbuf.append('I'); >>> - } else if (cl == Byte.TYPE) { >>> - sbuf.append('B'); >>> - } else if (cl == Long.TYPE) { >>> - sbuf.append('J'); >>> - } else if (cl == Float.TYPE) { >>> - sbuf.append('F'); >>> - } else if (cl == Double.TYPE) { >>> - sbuf.append('D'); >>> - } else if (cl == Short.TYPE) { >>> - sbuf.append('S'); >>> - } else if (cl == Character.TYPE) { >>> - sbuf.append('C'); >>> - } else if (cl == Boolean.TYPE) { >>> - sbuf.append('Z'); >>> - } else if (cl == Void.TYPE) { >>> - sbuf.append('V'); >>> - } else { >>> - throw new InternalError(); >>> - } >>> - } else { >>> - sbuf.append('L' + cl.getName().replace('.', '/') + ';'); >>> - } >>> - return sbuf.toString(); >>> - } >>> } >>> *Gesendet:* Dienstag, 07. Januar 2014 um 10:05 Uhr >>> *Von:* "Chris Hegarty" >>> *An:* "Robert Stupp" >>> *Cc:* "core-libs-dev at openjdk.java.net Libs" >>> *Betreff:* Re: ObjectIn/OutputStream improvements >>> On 15 Dec 2013, at 10:29, Robert Stupp wrote: >>> >>>> Hi, >>>> >>>> I digged through the object serialization code and found some lines >>> that could be optimized to reduce the number of calls to >>> System.arraycopy() and temporary object allocations especially during >>> string (de)serialization. >>>> In short sentences the changes are: >>>> ObjectInputStream: >>>> - skip primitive/object reading if no primitive/objects in class >>> (defaultReadFields method) >>>> - use shared StringBuilder for string reading (prevent superfluous >>> object allocations of one StingBuilder and one implicit char[] for each >>> string being deserialized) >>>> ObjectOutputStream: >>>> - skip primitive/object writing if no primitive/objects in class >>> (defaultWriteFields method) >>>> - use unsafe access to calculate UTF-length >>>> - use unsafe access in readBytes() and writeChars() methods to access >>> String value field >>>> - removed cbuf field >>>> ObjectStreamClass/ObjectStreamField: >>>> - minor improvement in getClassSignature ; share method code with >>> ObjectStreamField (return constant string for primitives) >>>> >>>> I have tested the changes in a big Java installation at a customer >>> (backported the Java8 ObjectIn/OutputStream including the changes to >>> Java6) and a long running real application performance test resulted in >>> reduced CPU usage (from about 60% per server to 50%). >>>> The changes I made in openjdk8 pass all tests. >>>> >>>> Since I have no experience how to contribute code to openjdk in form >>> of a push/changeset I have added the diff (hg export -g) to this email. >>> >>> Did you attach the diffs? I don?t see any attachment, it may be that the >>> attachment was stripped. Can you try resending inline? >>> >>> You should take a look at the OpenJDK How to Contribute page [1]. Paying >>> particular attention to the OCA, without it we will not be able to move >>> your patch forward. >>> >>> Thanks, >>> -Chris. >>> >>> [1] http://openjdk.java.net/contribute/ >>> >>>> >>>> Robert >>>> >>>> > From joe.darcy at oracle.com Fri Jan 31 21:39:45 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 31 Jan 2014 13:39:45 -0800 Subject: RFR 8032221 Typo in java.util.date In-Reply-To: References: <52EBEC76.9000603@oracle.com> Message-ID: <52EC1821.1030701@oracle.com> On 01/31/2014 10:44 AM, Lance Andersen - Oracle wrote: > looks fine. getting rid of and , is something I guess we should look to do throughout all of our code? Yes :-) In the core libraries, Jason did some bulk conversions along those lines in JDK 8: JDK-8017324 Cleanup of the javadoc tag in java.security.* etc. For JDK 9, normalizing to {@code} has been proposed earlier: http://mail.openjdk.java.net/pipermail/jdk9-dev/2013-December/000141.html Thanks, -Joe > On Jan 31, 2014, at 1:33 PM, roger riggs wrote: > >> Please review a typo and javadoc cleanup for java.util.Date >> >> webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-date-typo-8032221/ >> >> Thanks, Roger >> > > > 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 jason_mehrens at hotmail.com Fri Jan 31 23:09:46 2014 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Fri, 31 Jan 2014 17:09:46 -0600 Subject: RFR [9] 8011645: CopyOnWriteArrayList.COWSubList.subList does not validate range properly In-Reply-To: <84224D71-68C1-44EC-A539-1E38F4A9E4D9@oracle.com> References: <52EBCE09.1030609@oracle.com> , <84224D71-68C1-44EC-A539-1E38F4A9E4D9@oracle.com> Message-ID: Martin, Mike, Totally agree with everything that has been said on this. Leaving it 'unresolved' or 'closed as will not fix' won't bother me. Mike has it listed as a 'doc clarification only' so my suggestion toward a resolution would be to modify AbstractList.subList documentation with a spec implementation note. Might be worth adding to the bug report that AbstractList.removeRange doesn't detect or specify that exceptions are thrown when 'to' is less than 'from' but, ArrayList.removeRange overrides AbstactList.removeRange with an implementation that detects and throws IOOBE. Might want to add an optional IOOBE exception to AbstractList.removeRange documentation when this patch is attempted. Jason > Subject: Re: RFR [9] 8011645: CopyOnWriteArrayList.COWSubList.subList does not validate range properly > From: mike.duigou at oracle.com > Date: Fri, 31 Jan 2014 12:06:16 -0800 > CC: jason_mehrens at hotmail.com; core-libs-dev at openjdk.java.net > To: martinrb at google.com > > > On Jan 31 2014, at 11:50 , Martin Buchholz wrote: > >> Jason, >> Thanks for pointing that out. I'm sure I have seen those bugs before (when >> I owned them!) but had suppressed the memory. > > I'm currently the assignee for this bug. > >> I probably didn't try fixing them because there is no clean way out, and I >> was afraid of getting bogged down in compatibility hell for what is a >> non-issue for real-world users. > > Indeed. That's exactly why they still haven't been addressed. Suggestions are, of course, always welcome. > > Mike From mike.duigou at oracle.com Fri Jan 31 23:31:05 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 31 Jan 2014 15:31:05 -0800 Subject: RFR [9] 8011645: CopyOnWriteArrayList.COWSubList.subList does not validate range properly In-Reply-To: References: <52EBCE09.1030609@oracle.com> , <84224D71-68C1-44EC-A539-1E38F4A9E4D9@oracle.com> Message-ID: On Jan 31 2014, at 15:09 , Jason Mehrens wrote: > Martin, Mike, > > Totally agree with everything that has been said on this. Leaving it 'unresolved' or 'closed as will not fix' won't bother me. > > Mike has it listed as a 'doc clarification only' so my suggestion toward a resolution would be to modify AbstractList.subList documentation with a spec implementation note. > > Might be worth adding to the bug report that AbstractList.removeRange doesn't detect or specify that exceptions are thrown when 'to' is less than 'from' but, ArrayList.removeRange overrides AbstactList.removeRange with an implementation that detects and throws IOOBE. Might want to add an optional IOOBE exception to AbstractList.removeRange documentation when this patch is attempted. Added to the bug so that it doesn't get forgotten. Mike > Jason > >> Subject: Re: RFR [9] 8011645: CopyOnWriteArrayList.COWSubList.subList does not validate range properly >> From: mike.duigou at oracle.com >> Date: Fri, 31 Jan 2014 12:06:16 -0800 >> CC: jason_mehrens at hotmail.com; core-libs-dev at openjdk.java.net >> To: martinrb at google.com >> >> >> On Jan 31 2014, at 11:50 , Martin Buchholz wrote: >> >>> Jason, >>> Thanks for pointing that out. I'm sure I have seen those bugs before (when >>> I owned them!) but had suppressed the memory. >> >> I'm currently the assignee for this bug. >> >>> I probably didn't try fixing them because there is no clean way out, and I >>> was afraid of getting bogged down in compatibility hell for what is a >>> non-issue for real-world users. >> >> Indeed. That's exactly why they still haven't been addressed. Suggestions are, of course, always welcome. >> >> Mike