From paul.sandoz at oracle.com Mon Dec 1 08:48:48 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 1 Dec 2014 09:48:48 +0100 Subject: [8u40] Request for review and approval: 8059070 : [TESTBUG] java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java failed - timeout In-Reply-To: <5478AEFE.8010009@oracle.com> References: <5478AEFE.8010009@oracle.com> Message-ID: On Nov 28, 2014, at 6:21 PM, Konstantin Shefov wrote: > Please review and approve backport of JDK-8059070 to 8u40. > > This is the test fix and it is a bit different from that of JDK 9. > Looks ok. Why is it different to the fix in 9? Paul. > Bug: https://bugs.openjdk.java.net/browse/JDK-8059070 > Webrev: http://cr.openjdk.java.net/~kshefov/8059070_8u/webrev.00 > Review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-November/029831.html > Changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1d480d8fcf8c > > > Thanks, > -Konstantin From konstantin.shefov at oracle.com Mon Dec 1 10:53:05 2014 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Mon, 01 Dec 2014 13:53:05 +0300 Subject: [8u40] Request for review and approval: 8059070 : [TESTBUG] java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java failed - timeout In-Reply-To: References: <5478AEFE.8010009@oracle.com> Message-ID: <547C4891.2050906@oracle.com> Paul, On 01.12.2014 11:48, Paul Sandoz wrote: > On Nov 28, 2014, at 6:21 PM, Konstantin Shefov wrote: > >> Please review and approve backport of JDK-8059070 to 8u40. >> >> This is the test fix and it is a bit different from that of JDK 9. >> > Looks ok. > > Why is it different to the fix in 9? It is because in JDK 8u there is no adjustTimeout function in Utils class, so I added it. And I think it will be better to define where to stop interations depending on the iteration with the maximum time, not the average iteration time. If tests still fail with timeout in JDK 9, I will also change average time to maximum in JDK 9. -Konstantin > > Paul. > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8059070 >> Webrev: http://cr.openjdk.java.net/~kshefov/8059070_8u/webrev.00 >> Review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-November/029831.html >> Changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1d480d8fcf8c >> >> >> Thanks, >> -Konstantin From paul.sandoz at oracle.com Mon Dec 1 10:55:08 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 1 Dec 2014 11:55:08 +0100 Subject: [8u40] Request for review and approval: 8059070 : [TESTBUG] java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java failed - timeout In-Reply-To: <547C4891.2050906@oracle.com> References: <5478AEFE.8010009@oracle.com> <547C4891.2050906@oracle.com> Message-ID: On Dec 1, 2014, at 11:53 AM, Konstantin Shefov wrote: > Paul, > > On 01.12.2014 11:48, Paul Sandoz wrote: >> On Nov 28, 2014, at 6:21 PM, Konstantin Shefov wrote: >> >>> Please review and approve backport of JDK-8059070 to 8u40. >>> >>> This is the test fix and it is a bit different from that of JDK 9. >>> >> Looks ok. >> >> Why is it different to the fix in 9? > It is because in JDK 8u there is no adjustTimeout function in Utils class, so I added it. And I think it will be better to define where to stop interations depending on the iteration with the maximum time, not the average iteration time. > If tests still fail with timeout in JDK 9, I will also change average time to maximum in JDK 9. > Ok. I see Igor has factored out similar functionality in a separate patch under review in core-libs. Paul. From konstantin.shefov at oracle.com Mon Dec 1 12:07:23 2014 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Mon, 01 Dec 2014 15:07:23 +0300 Subject: [8u40] Request for review and approval: 8059070 : [TESTBUG] java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java failed - timeout In-Reply-To: References: <5478AEFE.8010009@oracle.com> <547C4891.2050906@oracle.com> Message-ID: <547C59FB.6070304@oracle.com> Paul, Igor On 01.12.2014 13:55, Paul Sandoz wrote: > On Dec 1, 2014, at 11:53 AM, Konstantin Shefov wrote: > >> Paul, >> >> On 01.12.2014 11:48, Paul Sandoz wrote: >>> On Nov 28, 2014, at 6:21 PM, Konstantin Shefov wrote: >>> >>>> Please review and approve backport of JDK-8059070 to 8u40. >>>> >>>> This is the test fix and it is a bit different from that of JDK 9. >>>> >>> Looks ok. >>> >>> Why is it different to the fix in 9? >> It is because in JDK 8u there is no adjustTimeout function in Utils class, so I added it. And I think it will be better to define where to stop interations depending on the iteration with the maximum time, not the average iteration time. >> If tests still fail with timeout in JDK 9, I will also change average iteration time to maximum time in JDK 9. >> > Ok. > > I see Igor has factored out similar functionality in a separate patch under review in core-libs. Well, in this case I can reuse the functionality Igor introduced, but it is going to be in JDK 9. Will it be backported to JDK 8? And there is "maxDuration << 1" in the file "lib/testlibrary/jdk/testlibrary/TimeLimitedRunner.java" but what if we need multiplier greater than 2, e.g. 4? -Konstantin > > Paul. From Sergey.Bylokhov at oracle.com Mon Dec 1 14:23:03 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 01 Dec 2014 17:23:03 +0300 Subject: [8u-dev] Request for approval: 8059944, 8058136, 8059942 Message-ID: <547C79C7.3070008@oracle.com> Hello, These are a direct back ports from jdk 9 to jdk 8u-dev. 8059944: [OGL] Metrics for a method choice copying of texture should be improved Bug: https://bugs.openjdk.java.net/browse/JDK-8059944 Webrev can be found at: http://cr.openjdk.java.net/~serb/8059944/webrev.00 jdk9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/754d2145a54a Review: http://mail.openjdk.java.net/pipermail/2d-dev/2014-November/004963.html Reviewers: Phil Race, Andrew Brygin 8058136: Test api/java_awt/SplashScreen/index.html\#ClosedSplashScreenTests fails because of java.lang.IllegalStateException was not thrown Bug: https://bugs.openjdk.java.net/browse/JDK-8058136 Webrev can be found at: http://cr.openjdk.java.net/~serb/8058136/webrev.00 jdk9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/1749af1d1e0b Review: http://mail.openjdk.java.net/pipermail/awt-dev/2014-September/008493.html Reviewers: Alexander Zvegintsev, Anthony Petrov 8059942: Default implementation of DrawImage.renderImageXform() should be improved for d3d/ogl Bug: https://bugs.openjdk.java.net/browse/JDK-8059942 Webrev can be found at: http://cr.openjdk.java.net/~serb/8059942/webrev.18 jdk9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/785732b1971f Review: http://mail.openjdk.java.net/pipermail/2d-dev/2014-November/004942.html Reviewers: Jim Graham, Phil Race -- Best regards, Sergey. From rob.mckenna at oracle.com Mon Dec 1 15:52:50 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 01 Dec 2014 15:52:50 +0000 Subject: [8u-dev] Request for approval: 8059944, 8058136, 8059942 In-Reply-To: <547C79C7.3070008@oracle.com> References: <547C79C7.3070008@oracle.com> Message-ID: <547C8ED2.4080408@oracle.com> Approved. -Rob On 01/12/14 14:23, Sergey Bylokhov wrote: > Hello, > These are a direct back ports from jdk 9 to jdk 8u-dev. > > 8059944: [OGL] Metrics for a method choice copying of texture should > be improved > Bug: https://bugs.openjdk.java.net/browse/JDK-8059944 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8059944/webrev.00 > jdk9 changeset: > http://hg.openjdk.java.net/jdk9/client/jdk/rev/754d2145a54a > Review: > http://mail.openjdk.java.net/pipermail/2d-dev/2014-November/004963.html > Reviewers: Phil Race, Andrew Brygin > > 8058136: Test > api/java_awt/SplashScreen/index.html\#ClosedSplashScreenTests fails > because of java.lang.IllegalStateException was not thrown > Bug: https://bugs.openjdk.java.net/browse/JDK-8058136 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8058136/webrev.00 > jdk9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/1749af1d1e0b > Review: > http://mail.openjdk.java.net/pipermail/awt-dev/2014-September/008493.html > Reviewers: Alexander Zvegintsev, Anthony Petrov > > 8059942: Default implementation of DrawImage.renderImageXform() should > be improved for d3d/ogl > Bug: https://bugs.openjdk.java.net/browse/JDK-8059942 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8059942/webrev.18 > jdk9 changeset: > http://hg.openjdk.java.net/jdk9/client/jdk/rev/785732b1971f > Review: > http://mail.openjdk.java.net/pipermail/2d-dev/2014-November/004942.html > Reviewers: Jim Graham, Phil Race > From rob.mckenna at oracle.com Mon Dec 1 18:47:20 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 01 Dec 2014 18:47:20 +0000 Subject: [8u40] approval request for 8044146: jdk.nashorn.api.scripting package javadoc should be included in jdk docs In-Reply-To: <547C8E97.2070402@oracle.com> References: <547C58CB.3060300@oracle.com> <547C8E97.2070402@oracle.com> Message-ID: <547CB7B8.7060506@oracle.com> Just noticed this was sent to the wrong alias. Please use jdk8u-dev at openjdk.java.net for approval requests. -Rob On 01/12/14 15:51, Rob McKenna wrote: > Approved. Please add a suitable noreg keyword. > > -Rob > > On 01/12/14 12:02, A. Sundararajan wrote: >> Please approve >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8066146 >> 8u-dev webrev: >> http://cr.openjdk.java.net/~sundar/8066146/8u40/webrev.00/ >> jdk9 review thread: >> http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-November/003922.html >> >> I had to adjust paths in makefile slightly for jdk8u40. CC'ing jdk9 >> reviewers as well... >> >> Thanks, >> -Sundar > From lana.steuck at oracle.com Mon Dec 1 19:36:11 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 1 Dec 2014 11:36:11 -0800 (PST) Subject: jdk8u-b17: jdk8u-dev Message-ID: <201412011936.sB1JaBoa026010@jano-app.us.oracle.com> http://hg.openjdk.java.net/jdk8u/jdk8u/rev/e1c506c8e1db http://hg.openjdk.java.net/jdk8u/jdk8u/nashorn/rev/88e22262fdb2 http://hg.openjdk.java.net/jdk8u/jdk8u/langtools/rev/a12a9932f649 http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/fc4f55464170 http://hg.openjdk.java.net/jdk8u/jdk8u/jaxws/rev/83c4d5aca2ff http://hg.openjdk.java.net/jdk8u/jdk8u/jaxp/rev/cb63029168a5 http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/3562db849018 http://hg.openjdk.java.net/jdk8u/jdk8u/corba/rev/bff1a326ac97 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8058197 client-libs AWT fails on generic non-reparenting window managers JDK-8057830 client-libs Crash in Java2D Queue Flusher, OGLSD_SetScratchSurface JDK-8034085 client-libs Do not prefer indexed properties JDK-8059739 client-libs Dragged and Dropped data is corrupted for two data types JDK-8062164 client-libs Incorrect color conversion, when bicubic interpolation is used JDK-8034164 client-libs Introspector ignores indexed part of the property sometimes JDK-8065098 client-libs JColorChooser no longer supports drag and drop between two JVM instances JDK-8041734 client-libs JFrame in full screen mode leaves empty workspace after close JDK-7169583 client-libs JInternalFrame title not antialiased in Nimbus LaF JDK-6302052 client-libs Reference to nonexistant Class in javadoc JDK-8027148 client-libs SystemFlavorMap.getNativesForFlavor returns list of native formats in incorrect order JDK-8054332 client-libs Test closed/java/awt/image/Raster/IncorrectScanlineStrideTest.java fails always JDK-8059941 client-libs [D3D] The fix for JDK-8029253 should be ported to d3d pipeline JDK-8061456 client-libs [OGL] Incorrect clip is used during sw->surface blit in xor mode JDK-8059943 client-libs [macosx] Aqua LaF should use BI.TYPE_INT_ARGB_PRE for a better performance JDK-7148531 client-libs [macosx] In test, the window does not have time to resize before make a screenshot JDK-8029253 client-libs [macosx] Performance problems with Retina display on Mac OS X JDK-8058193 client-libs [macosx] Potential incomplete fix for JDK-8031485 JDK-8064560 core-libs (tz) Support tzdata2014j JDK-8062771 core-libs Core reflection should use final fields whenever possible JDK-8063135 core-libs Enable full LF sharing by default JDK-8051778 core-libs Function.prototype.bind doesn't work on all callables JDK-8059877 core-libs GWT branch frequencies pollution due to LF sharing JDK-8059880 core-libs Get rid of LambdaForm interpretation JDK-8065985 core-libs Inlining failure of Number.doubleValue() in JSType.toNumeric() causes 15% peak perf regresion on Box2D JDK-8050983 core-libs Misplaced parentheses in sun.net.www.http.HttpClient break HTTP PUT streaming JDK-8066119 core-libs Missing resource type.error.not.an.arraybuffer JDK-8064789 core-libs Nashorn should just warn on code store instantiation error JDK-8062638 core-libs Nashorn: RuntimeException when run command from js with -scripting on Cygwin JDK-8054343 core-libs Nashorn: Some tests fails on windows with AccessControlException JDK-8057779 core-libs Nashorn: Tests failed on Windows when in output contains path to script JDK-8057691 core-libs Nashorn: let & const declarations are not shared between scripts JDK-8055063 core-libs Parameter#toString() fails w/ AIOOBE for ctr of inner class w/ generic type JDK-8049407 core-libs Test NASHORN-377.js fails on Solaris sparc JDK-8065377 core-libs [TEST_BUG] test/closed/java/util/Calendar tests failures with 2014j tzdata JDK-8057980 core-libs let & const: remaining issues with lexical scoping JDK-8061200 core-svc CMM: Commercial feature changes (docs) JDK-8065397 core-svc Remove ExtendedPlatformComponent.java from EXFILES list JDK-8065353 core-svc getPlatformMBeanServer throws NoClassDefFoundError: sun/management/ExtendedPlatformComponent for non-commercial binaries JDK-8061960 core-svc java/lang/instrument/DaemonThread/TestDaemonThread.java regularly fails due to exceeded timeout JDK-8064288 core-svc sun.management.Flag should loadLibrary() JDK-8043227 deploy Launching of unsigned JNLP applet with extensions prints JARSigningException JDK-8060453 globalization JDK-8058671 changed untrusted dialog message key only for default dialog language JDK-8055798 globalization Japanese translation for a warning from javac looks incorrect. JDK-8065069 globalization jdk8u40 l10n resource file translation update 2 JDK-8036614 hotspot AIX: fix adjust-mflags.sh to build with GNU Make 4.0 (adapt 8028407 for AIX) JDK-8065198 hotspot [TESTBUG] Fix typo in arguments in TestAccuracyLevel.java JDK-8065196 hotspot [TESTBUG] Ignore unstable closed/gc/resource/ tests JDK-8028407 hotspot adjust-mflags.sh failed build with GNU Make 4.0 with -I JDK-8062390 hotspot closed/serviceability/resource tests uses GPLv2 licence JDK-8065183 infrastructure Add --with-copyright-year option to configure JDK-8065410 infrastructure additional files still under cmm directory in jle source bundles for 8u40 JDK-8057794 tools Compiler Error when obtaining .class property JDK-8062747 tools Compiler error when anonymous class uses method with parametrized exception JDK-8063052 tools Inference chokes on wildcard derived from method reference JDK-8058112 tools Invalid BootstrapMethod for constructor/method reference JDK-8044748 tools JVM cannot access constructor though ::new reference although can call it directly JDK-8044737 tools Lambda: NPE while obtaining method reference through lambda expression JDK-8059921 tools Missing compile error in Java 8 mode for Interface.super.field access JDK-8065132 tools Parameter annotations not updated when synthetic parameters are prepended JDK-8038776 tools VerifyError when running successfully compiled java class JDK-8062359 tools javac Attr crashes with NPE in TypeAnnotationsValidator visitNewClass JDK-8037404 tools javac NPE or VerifyError for code with constructor reference of inner class JDK-8048121 tools javac complex method references: revamp and simplify JDK-8047341 tools lambda reference to inner class in base class causes LambdaConversionException JDK-8029012 tools parameter_index for type annotation not updated after outer.this added From jeff.dinkins at oracle.com Mon Dec 1 19:42:13 2014 From: jeff.dinkins at oracle.com (Jeff Dinkins) Date: Mon, 1 Dec 2014 13:42:13 -0600 Subject: [8u40] Approval request for 8057629: Update THIRD_PARTY_LICENSE_README for 8u40 Message-ID: Updated Java DB (Derby) version to 10.11.1.2 Note that even though there?s only one file change shown in the webrev, this change will be applied to all repositories. http://cr.openjdk.java.net/~jeff/8057629/ From daniel.fuchs at oracle.com Mon Dec 1 20:28:18 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 01 Dec 2014 21:28:18 +0100 Subject: [8u40] approval request for 8065552: setAccessible(true) on fields of Class may throw a SecurityException Message-ID: <547CCF62.1010806@oracle.com> Hi, This is a request for approval to backport: 8065552: setAccessible(true) on fields of Class may throw a SecurityException This is a clean hg import after unshuffle. bug: https://bugs.openjdk.java.net/browse/JDK-8065552 jdk9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2f22ec7a15c6 jdk9 review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/029942.html best regards, -- daniel From rob.mckenna at oracle.com Mon Dec 1 20:30:37 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 01 Dec 2014 20:30:37 +0000 Subject: [8u40] approval request for 8065552: setAccessible(true) on fields of Class may throw a SecurityException In-Reply-To: <547CCF62.1010806@oracle.com> References: <547CCF62.1010806@oracle.com> Message-ID: <547CCFED.2000604@oracle.com> Approved. -Rob On 01/12/14 20:28, Daniel Fuchs wrote: > Hi, > > This is a request for approval to backport: > > 8065552: setAccessible(true) on fields of Class may throw a > SecurityException > > This is a clean hg import after unshuffle. > > bug: https://bugs.openjdk.java.net/browse/JDK-8065552 > jdk9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2f22ec7a15c6 > jdk9 review thread: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/029942.html > > best regards, > > -- daniel From rob.mckenna at oracle.com Mon Dec 1 20:34:40 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 01 Dec 2014 20:34:40 +0000 Subject: [8u40] Approval request for 8057629: Update THIRD_PARTY_LICENSE_README for 8u40 In-Reply-To: References: Message-ID: <547CD0E0.2050702@oracle.com> Approved. -Rob On 01/12/14 19:42, Jeff Dinkins wrote: > Updated Java DB (Derby) version to 10.11.1.2 > > Note that even though there?s only one file change shown in the webrev, this change will be applied to all repositories. > > http://cr.openjdk.java.net/~jeff/8057629/ From mandy.chung at oracle.com Mon Dec 1 20:53:26 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 01 Dec 2014 12:53:26 -0800 Subject: [8u40] Review Request 8065765: Missing space in output message from -XX:+CheckEndorsedAndExtDirs Message-ID: <547CD546.3020505@oracle.com> This requests code review as well as 8u40 putback approval Webrev: http://cr.openjdk.java.net/~mchung/jdk8u/webrevs/8065765/webrev.00/ JBS issue: https://bugs.openjdk.java.net/browse/JDK-8065765 The test should not run with -XX:+CheckEndorsedAndExtDirs as the default as the test system may have JAR files installed in the system extension directory. A new test case is also added to verify on systems with such extensions. This patch also fixes the missing space in the error message. thanks Mandy From calvin.cheung at oracle.com Tue Dec 2 00:00:15 2014 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Mon, 01 Dec 2014 16:00:15 -0800 Subject: [8u40] Review Request 8065765: Missing space in output message from -XX:+CheckEndorsedAndExtDirs In-Reply-To: <547CD546.3020505@oracle.com> References: <547CD546.3020505@oracle.com> Message-ID: <547D010F.206@oracle.com> Hi Mandy, The fix looks good. thanks, Calvin On 12/1/2014 12:53 PM, Mandy Chung wrote: > This requests code review as well as 8u40 putback approval > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk8u/webrevs/8065765/webrev.00/ > > JBS issue: > https://bugs.openjdk.java.net/browse/JDK-8065765 > > The test should not run with -XX:+CheckEndorsedAndExtDirs as the > default as the test system may have JAR files installed in the > system extension directory. A new test case is also added > to verify on systems with such extensions. > > This patch also fixes the missing space in the error message. > > thanks > Mandy > > From sean.coffey at oracle.com Tue Dec 2 00:03:28 2014 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Tue, 02 Dec 2014 00:03:28 +0000 Subject: [8u40] Review Request 8065765: Missing space in output message from -XX:+CheckEndorsedAndExtDirs In-Reply-To: <547D010F.206@oracle.com> References: <547CD546.3020505@oracle.com> <547D010F.206@oracle.com> Message-ID: <547D01D0.5080401@oracle.com> Mandy - this is probably suitable for integration to the hotspot team forest (hs-dev) - In that case, no approval is required. Consider this approved if you wish to push to jdk8u-dev. regards, Sean. On 02/12/2014 00:00, Calvin Cheung wrote: > Hi Mandy, > > The fix looks good. > > thanks, > Calvin > > On 12/1/2014 12:53 PM, Mandy Chung wrote: >> This requests code review as well as 8u40 putback approval >> >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk8u/webrevs/8065765/webrev.00/ >> >> JBS issue: >> https://bugs.openjdk.java.net/browse/JDK-8065765 >> >> The test should not run with -XX:+CheckEndorsedAndExtDirs as the >> default as the test system may have JAR files installed in the >> system extension directory. A new test case is also added >> to verify on systems with such extensions. >> >> This patch also fixes the missing space in the error message. >> >> thanks >> Mandy >> >> > From harold.seigel at oracle.com Tue Dec 2 14:06:18 2014 From: harold.seigel at oracle.com (harold seigel) Date: Tue, 02 Dec 2014 09:06:18 -0500 Subject: [8u40] Review Request 8065765: Missing space in output message from -XX:+CheckEndorsedAndExtDirs In-Reply-To: <547CD546.3020505@oracle.com> References: <547CD546.3020505@oracle.com> Message-ID: <547DC75A.7090705@oracle.com> Hi Mandy, Your changes look good. Harold On 12/1/2014 3:53 PM, Mandy Chung wrote: > This requests code review as well as 8u40 putback approval > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk8u/webrevs/8065765/webrev.00/ > > JBS issue: > https://bugs.openjdk.java.net/browse/JDK-8065765 > > The test should not run with -XX:+CheckEndorsedAndExtDirs as the > default as the test system may have JAR files installed in the > system extension directory. A new test case is also added > to verify on systems with such extensions. > > This patch also fixes the missing space in the error message. > > thanks > Mandy > > From alejandro.murillo at oracle.com Tue Dec 2 18:50:16 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 02 Dec 2014 11:50:16 -0700 Subject: jdk8u40-b17: HotSpot Message-ID: <547E09E8.1000305@oracle.com> hs25.40-b21 has been integrated into jdk8u40-b17. http://hg.openjdk.java.net/jdk8u/jdk8u/rev/e1c506c8e1db http://hg.openjdk.java.net/jdk8u/jdk8u/corba/rev/bff1a326ac97 http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/fc1f9b67fd8c http://hg.openjdk.java.net/jdk8u/jdk8u/jaxp/rev/cb63029168a5 http://hg.openjdk.java.net/jdk8u/jdk8u/jaxws/rev/83c4d5aca2ff http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/fc4f55464170 http://hg.openjdk.java.net/jdk8u/jdk8u/langtools/rev/a12a9932f649 http://hg.openjdk.java.net/jdk8u/jdk8u/nashorn/rev/88e22262fdb2 Component : VM Status : 0 major failures, 1 minor failures Date : 02/12/2014 at 17:00 MSK Tested By : STT_VM Cost(total man-days): 1 Workspace : 2014-11-27-175342.amurillo.hs25-40-b21-snapshot Bundles : 2014-11-27-175342.amurillo.hs25-40-b21-snapshot Platforms : Others Tests : Log : link Browsers : NA Patches : NA Number of Tests Executed : 437026 passed tests, 4134 failed tests (no new failures) Bug verification status: ====================================== Tested, Pass: Tested, Pass (partial fixes): Tested, Fail: Untested bug fixes: 8050079: crash while compiling java.lang.ref.Finalizer::runFinalizer 8058148: MaxNodeLimit and LiveNodeCountInliningCutoff 8058847: C2: EliminateAutoBox regression after 8042786 8060147: SIGSEGV in Metadata::mark_on_stack() while marking metadata in ciEnv 8064701: Some CDS optimizations should be disabled if bootclasspath is modified by JVMTI 8065346: WB_AddToBootstrapClassLoaderSearch calls JvmtiEnv::create_a_jvmti when not in _thread_in_vm state 8065385: new hotspot build - hs25.40-b21 New bugs filed: Bugs in PIT build: JDK-8066413 [TESTBUG]: hotspot/test/closed/gc/resource/TestPendingData.java timeouts on box with a lot of memory Bugs in earlier promoted build: Number of PIT requested: 1 Integration target J2SE build number: jdk8u40-b17 Issues and Notes: This is PIT for HS25.40-b21 for jdk8u40-b17. Go for integration. -- Alejandro From paul.sandoz at oracle.com Wed Dec 3 11:40:45 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 3 Dec 2014 12:40:45 +0100 Subject: [8u40] RFR 8066397 Remove network-related seed initialization code in ThreadLocal/SplittableRandom Message-ID: Hi, Please approve a backport of 8066397 to 8u40. Review in 9 here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/029996.html Changes apply cleanly to 8udev when shuffled from 9: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0761cc66b983 Paul. From alexandr.scherbatiy at oracle.com Wed Dec 3 11:44:31 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 03 Dec 2014 14:44:31 +0300 Subject: [8u40] Request for approval: 8066142 Edit the value in the text field and then press the tab key, the number don't increase Message-ID: <547EF79F.8090308@oracle.com> Hello, Could you approve the direct backport of the fix to JDK 8u-dev. The bug: https://bugs.openjdk.java.net/browse/JDK-8066142 The webrev: http://cr.openjdk.java.net/~alexsch/8066142/webrev.00 The review thread: http://mail.openjdk.java.net/pipermail/swing-dev/2014-December/004057.html The JDK 9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/3f675a227cb2 Thanks, Alexandr. From rob.mckenna at oracle.com Wed Dec 3 13:00:04 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 03 Dec 2014 13:00:04 +0000 Subject: [8u40] Request for approval: 8066142 Edit the value in the text field and then press the tab key, the number don't increase In-Reply-To: <547EF79F.8090308@oracle.com> References: <547EF79F.8090308@oracle.com> Message-ID: <547F0954.3060203@oracle.com> Approved. -Rob On 03/12/14 11:44, Alexander Scherbatiy wrote: > > Hello, > > Could you approve the direct backport of the fix to JDK 8u-dev. > > The bug: https://bugs.openjdk.java.net/browse/JDK-8066142 > The webrev: http://cr.openjdk.java.net/~alexsch/8066142/webrev.00 > The review thread: > http://mail.openjdk.java.net/pipermail/swing-dev/2014-December/004057.html > The JDK 9 changeset: > http://hg.openjdk.java.net/jdk9/client/jdk/rev/3f675a227cb2 > > Thanks, > Alexandr. > From rob.mckenna at oracle.com Wed Dec 3 13:03:30 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 03 Dec 2014 13:03:30 +0000 Subject: [8u40] Request for approval: 8043477 - java/lang/ProcessBuilder/Basic.java failed with: java.lang.AssertionError: Some tests failed Message-ID: <547F0A22.5000201@oracle.com> Fix applies cleanly. changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/180d3b8322cb bug: https://bugs.openjdk.java.net/browse/JDK-8043477 review: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-November/029625.html -Rob From sean.coffey at oracle.com Wed Dec 3 13:17:32 2014 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Wed, 03 Dec 2014 13:17:32 +0000 Subject: [8u40] RFR 8066397 Remove network-related seed initialization code in ThreadLocal/SplittableRandom In-Reply-To: References: Message-ID: <547F0D6C.4070002@oracle.com> Please add a noreg- label to master bug Paul. Approved. regards, Sean. On 03/12/14 11:40, Paul Sandoz wrote: > Hi, > > Please approve a backport of 8066397 to 8u40. > > Review in 9 here: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/029996.html > > Changes apply cleanly to 8udev when shuffled from 9: > > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0761cc66b983 > > Paul. > > From sean.coffey at oracle.com Wed Dec 3 13:25:46 2014 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Wed, 03 Dec 2014 13:25:46 +0000 Subject: [8u40] Request for approval: 8043477 - java/lang/ProcessBuilder/Basic.java failed with: java.lang.AssertionError: Some tests failed In-Reply-To: <547F0A22.5000201@oracle.com> References: <547F0A22.5000201@oracle.com> Message-ID: <547F0F5A.6060908@oracle.com> Approved. regards, Sean. On 03/12/14 13:03, Rob McKenna wrote: > Fix applies cleanly. > > changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/180d3b8322cb > bug: https://bugs.openjdk.java.net/browse/JDK-8043477 > review: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-November/029625.html > > -Rob > > From hannes.wallnoefer at oracle.com Wed Dec 3 14:05:53 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 03 Dec 2014 15:05:53 +0100 Subject: [8u40] Request for approval: JDK-8065769: OOM on Window/Solaris in test compile-octane-splitter.js Message-ID: <547F18C1.3050706@oracle.com> Please approve backport of JDK-8065769 to 8u40. Changes apply cleanly to 8u40 after shuffling path names. Bug: https://bugs.openjdk.java.net/browse/JDK-8065769 Webrev: http://cr.openjdk.java.net/~hannesw/8065769/ Review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-December/003963.html Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/7437eb72fc4e Thanks, Hannes From rob.mckenna at oracle.com Wed Dec 3 14:25:08 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 03 Dec 2014 14:25:08 +0000 Subject: [8u40] Request for approval: JDK-8065769: OOM on Window/Solaris in test compile-octane-splitter.js In-Reply-To: <547F18C1.3050706@oracle.com> References: <547F18C1.3050706@oracle.com> Message-ID: <547F1D44.2080103@oracle.com> Hi Hannes, This definitely isn't an appropriate use of noreg-trivial (a copyright year change or a typo would be) so please change that. (noreg-hard if need be) Approved. -Rob On 03/12/14 14:05, Hannes Wallnoefer wrote: > Please approve backport of JDK-8065769 to 8u40. > > Changes apply cleanly to 8u40 after shuffling path names. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8065769 > Webrev: http://cr.openjdk.java.net/~hannesw/8065769/ > Review thread: > http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-December/003963.html > Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/7437eb72fc4e > > Thanks, > Hannes From hannes.wallnoefer at oracle.com Wed Dec 3 14:28:53 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 03 Dec 2014 15:28:53 +0100 Subject: [8u40] Request for approval: JDK-8065769: OOM on Window/Solaris in test compile-octane-splitter.js In-Reply-To: <547F1D44.2080103@oracle.com> References: <547F18C1.3050706@oracle.com> <547F1D44.2080103@oracle.com> Message-ID: <547F1E25.4040404@oracle.com> Thanks Rob, I changed the label to noreg-hard and updated the comment. Hannes Am 2014-12-03 um 15:25 schrieb Rob McKenna: > Hi Hannes, > > This definitely isn't an appropriate use of noreg-trivial (a copyright > year change or a typo would be) so please change that. (noreg-hard if > need be) > > Approved. > > -Rob > > On 03/12/14 14:05, Hannes Wallnoefer wrote: >> Please approve backport of JDK-8065769 to 8u40. >> >> Changes apply cleanly to 8u40 after shuffling path names. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8065769 >> Webrev: http://cr.openjdk.java.net/~hannesw/8065769/ >> Review thread: >> http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-December/003963.html >> Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/7437eb72fc4e >> >> Thanks, >> Hannes > From shanliang.jiang at oracle.com Wed Dec 3 15:33:55 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Wed, 03 Dec 2014 16:33:55 +0100 Subject: [8u40] RFR 8065764,javax/management/monitor/CounterMonitorTest.java hangs Message-ID: <547F2D63.4090902@oracle.com> Please approve this clean backport: Review: http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-December/016070.html JDK 9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/712aae89ad32 bug: https://bugs.openjdk.java.net/browse/JDK-8065764 thanks, Shanliang From sean.coffey at oracle.com Wed Dec 3 16:25:15 2014 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Wed, 03 Dec 2014 16:25:15 +0000 Subject: [8u40] RFR 8065764, javax/management/monitor/CounterMonitorTest.java hangs In-Reply-To: <547F2D63.4090902@oracle.com> References: <547F2D63.4090902@oracle.com> Message-ID: <547F396B.7060207@oracle.com> Approved. please use 'approval' in the subject line for such requests in future. http://openjdk.java.net/projects/jdk8u/approval-template.html regards, Sean. On 03/12/14 15:33, shanliang wrote: > Please approve this clean backport: > > Review: > http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-December/016070.html > > JDK 9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/712aae89ad32 > bug: https://bugs.openjdk.java.net/browse/JDK-8065764 > > thanks, > Shanliang > > From daniel.fuchs at oracle.com Wed Dec 3 22:47:30 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 03 Dec 2014 23:47:30 +0100 Subject: [9 + 8u] RFR - 8066612: Add a test that will call getDeclaredFields() on all classes and try to set them accessible. Message-ID: <547F9302.3060309@oracle.com> Hi, This is a review for a new test which has a different implementation for JDK 8 & JDK 9 During the review of JDK-8065552: setAccessible(true) on fields of Class may throw a SecurityException, it was remarked that such a test would be useful. So here is such a test that loads all classes from the BCL, calls getDeclaredFields() for each of them, and attempt to set each field to accessible. On JDK 8 and JDK 9 this is quite fast (~ 3.2sec when a security manager is on). The differences between 8 & 9 are limited to: - ClassLoader: - on 8 we use 'null' (BCL) - on 9 we use the system class loader. - Building the stream of class names: - on 8 we have jars & folders in the boot class path - on 9 we have .jimage files webrev jdk8: http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk8.00/ webrev jdk9: http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.00/ best regards, -- daniel PS: For the curious I have also experimented with a version of this test for JDK 7u [1] (where Streams have been replaced by Lists). On 7 you need to either increase the PermGen size or split the test into several invocations (the method I chose in [1]). [1] don't review the link below - it's just for the record if/when someone wants to backport on 7u... http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk7.00 From david.holmes at oracle.com Thu Dec 4 03:37:22 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 04 Dec 2014 13:37:22 +1000 Subject: [9 + 8u] RFR - 8066612: Add a test that will call getDeclaredFields() on all classes and try to set them accessible. In-Reply-To: <547F9302.3060309@oracle.com> References: <547F9302.3060309@oracle.com> Message-ID: <547FD6F2.5060400@oracle.com> Hi Daniel, Once clarification please ... On 4/12/2014 8:47 AM, Daniel Fuchs wrote: > Hi, > > This is a review for a new test which has a different > implementation for JDK 8 & JDK 9 > > During the review of > JDK-8065552: setAccessible(true) on fields of Class may throw > a SecurityException, > it was remarked that such a test would be useful. > > So here is such a test that loads all classes from the BCL, calls > getDeclaredFields() for each of them, and attempt to set > each field to accessible. > On JDK 8 and JDK 9 this is quite fast (~ 3.2sec when a security > manager is on). > > The differences between 8 & 9 are limited to: > > - ClassLoader: > - on 8 we use 'null' (BCL) > - on 9 we use the system class loader. I haven't seen anything in JEP 220, regarding modules, that indicates that classes currently loaded by the boot-loader will now be loaded by the system classloader ??? Thanks, David > - Building the stream of class names: > - on 8 we have jars & folders in the boot class path > - on 9 we have .jimage files > > > webrev jdk8: > http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk8.00/ > > webrev jdk9: > http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.00/ > > > best regards, > > -- daniel > > PS: For the curious I have also experimented with a version of this > test for JDK 7u [1] (where Streams have been replaced by Lists). > On 7 you need to either increase the PermGen size or split the > test into several invocations (the method I chose in [1]). > > [1] don't review the link below - it's just for the record > if/when someone wants to backport on 7u... > http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk7.00 From daniel.fuchs at oracle.com Thu Dec 4 09:05:20 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 04 Dec 2014 10:05:20 +0100 Subject: [9 + 8u] RFR - 8066612: Add a test that will call getDeclaredFields() on all classes and try to set them accessible. In-Reply-To: <547FD6F2.5060400@oracle.com> References: <547F9302.3060309@oracle.com> <547FD6F2.5060400@oracle.com> Message-ID: <548023D0.4020702@oracle.com> Hi David, On 12/4/14 4:37 AM, David Holmes wrote: > Hi Daniel, > > Once clarification please ... > > On 4/12/2014 8:47 AM, Daniel Fuchs wrote: >> Hi, >> >> This is a review for a new test which has a different >> implementation for JDK 8 & JDK 9 >> >> During the review of >> JDK-8065552: setAccessible(true) on fields of Class may throw >> a SecurityException, >> it was remarked that such a test would be useful. >> >> So here is such a test that loads all classes from the BCL, calls >> getDeclaredFields() for each of them, and attempt to set >> each field to accessible. >> On JDK 8 and JDK 9 this is quite fast (~ 3.2sec when a security >> manager is on). >> >> The differences between 8 & 9 are limited to: >> >> - ClassLoader: >> - on 8 we use 'null' (BCL) >> - on 9 we use the system class loader. > > I haven't seen anything in JEP 220, regarding modules, that indicates > that classes currently loaded by the boot-loader will now be loaded > by the system classloader ??? In [1] towards the end: [1] http://openjdk.java.net/jeps/220 "The defining class loader of the types in some existing packages will change. Existing code that makes assumptions about the class loaders of these types might not work correctly." (then there is a list of specific changes). This test looks up all class names in the image files and attempt to load the corresponding class. But as indicated in [1] some of these classes are now in the Boot CL, some in the Extension CL, and some in the Application CL. So the test uses the System CL to load each class - which ensures that the loading will be delegated to the appropriate ClassLoader. best regards, -- daniel > > Thanks, > David > >> - Building the stream of class names: >> - on 8 we have jars & folders in the boot class path >> - on 9 we have .jimage files >> >> >> webrev jdk8: >> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk8.00/ >> >> webrev jdk9: >> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.00/ >> >> >> best regards, >> >> -- daniel >> >> PS: For the curious I have also experimented with a version of this >> test for JDK 7u [1] (where Streams have been replaced by Lists). >> On 7 you need to either increase the PermGen size or split the >> test into several invocations (the method I chose in [1]). >> >> [1] don't review the link below - it's just for the record >> if/when someone wants to backport on 7u... >> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk7.00 From daniel.fuchs at oracle.com Thu Dec 4 11:38:43 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 04 Dec 2014 12:38:43 +0100 Subject: [9 + 8u] RFR - 8066612: Add a test that will call getDeclaredFields() on all classes and try to set them accessible. In-Reply-To: <548023D0.4020702@oracle.com> References: <547F9302.3060309@oracle.com> <547FD6F2.5060400@oracle.com> <548023D0.4020702@oracle.com> Message-ID: <548047C3.8000400@oracle.com> Hi David, In fact I could use 'null' on JDK 9 as well. My first version of the JDK 9 test was parsing over all the .jimage files under /lib/modules - which explain why I needed to use the System class loader. Then I switched to only parsing the bootmodules.jimage - because I noticed that the results where more coherent with what I had observed on 8 & 7 - but I kept using the System class loader. I am not sure whether we want the test for 9 should iterate over the three .jimage - or continue to test only the boot .jimage. I have updated the JDK 9 test (refreshed the webrev in place) http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.00/ and added support for possibly running the test in the two modes (I added a 'test.boot.only' system property, true by default) as well as additional traces to print the loaded classes by defining loader at the end (test.list.classes, false by default). Thanks for your question, it triggered me into looking deeper into what was happening :-) best regards, -- daniel On 04/12/14 10:05, Daniel Fuchs wrote: >>> The differences between 8 & 9 are limited to: >>> >>> - ClassLoader: >>> - on 8 we use 'null' (BCL) >>> - on 9 we use the system class loader. >> >> I haven't seen anything in JEP 220, regarding modules, that indicates >> that classes currently loaded by the boot-loader will now be loaded >> by the system classloader ??? > > In [1] towards the end: > > [1] http://openjdk.java.net/jeps/220 > > "The defining class loader of the types in some existing packages > will change. Existing code that makes assumptions about the class > loaders of these types might not work correctly." > (then there is a list of specific changes). > > This test looks up all class names in the image files and attempt > to load the corresponding class. But as indicated in [1] > some of these classes are now in the Boot CL, some in the > Extension CL, and some in the Application CL. > > So the test uses the System CL to load each class - which ensures > that the loading will be delegated to the appropriate ClassLoader. > > best regards, > > -- daniel From david.holmes at oracle.com Thu Dec 4 11:50:28 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 04 Dec 2014 21:50:28 +1000 Subject: [9 + 8u] RFR - 8066612: Add a test that will call getDeclaredFields() on all classes and try to set them accessible. In-Reply-To: <548023D0.4020702@oracle.com> References: <547F9302.3060309@oracle.com> <547FD6F2.5060400@oracle.com> <548023D0.4020702@oracle.com> Message-ID: <54804A84.8040504@oracle.com> Hi Daniel, On 4/12/2014 7:05 PM, Daniel Fuchs wrote: > On 12/4/14 4:37 AM, David Holmes wrote: >> >> Once clarification please ... >> >> On 4/12/2014 8:47 AM, Daniel Fuchs wrote: >>> Hi, >>> >>> This is a review for a new test which has a different >>> implementation for JDK 8 & JDK 9 >>> >>> During the review of >>> JDK-8065552: setAccessible(true) on fields of Class may throw >>> a SecurityException, >>> it was remarked that such a test would be useful. >>> >>> So here is such a test that loads all classes from the BCL, calls >>> getDeclaredFields() for each of them, and attempt to set >>> each field to accessible. >>> On JDK 8 and JDK 9 this is quite fast (~ 3.2sec when a security >>> manager is on). >>> >>> The differences between 8 & 9 are limited to: >>> >>> - ClassLoader: >>> - on 8 we use 'null' (BCL) >>> - on 9 we use the system class loader. >> >> I haven't seen anything in JEP 220, regarding modules, that indicates >> that classes currently loaded by the boot-loader will now be loaded >> by the system classloader ??? > > In [1] towards the end: > > [1] http://openjdk.java.net/jeps/220 > > "The defining class loader of the types in some existing packages > will change. Existing code that makes assumptions about the class > loaders of these types might not work correctly." > (then there is a list of specific changes). > > This test looks up all class names in the image files and attempt > to load the corresponding class. But as indicated in [1] > some of these classes are now in the Boot CL, some in the > Extension CL, and some in the Application CL. Yes but that is a small set of specific types. The boot classes are still loaded by the boot loader. > So the test uses the System CL to load each class - which ensures > that the loading will be delegated to the appropriate ClassLoader. It wasn't the use of the system loader to load the classes that I was concerned about but the check whether cls.getClassLoader() was the system loader - as it would not be for the boot classes. David > best regards, > > -- daniel > >> >> Thanks, >> David >> >>> - Building the stream of class names: >>> - on 8 we have jars & folders in the boot class path >>> - on 9 we have .jimage files >>> >>> >>> webrev jdk8: >>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk8.00/ >>> >>> webrev jdk9: >>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.00/ >>> >>> >>> best regards, >>> >>> -- daniel >>> >>> PS: For the curious I have also experimented with a version of this >>> test for JDK 7u [1] (where Streams have been replaced by Lists). >>> On 7 you need to either increase the PermGen size or split the >>> test into several invocations (the method I chose in [1]). >>> >>> [1] don't review the link below - it's just for the record >>> if/when someone wants to backport on 7u... >>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk7.00 > From david.holmes at oracle.com Thu Dec 4 12:06:35 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 04 Dec 2014 22:06:35 +1000 Subject: [9 + 8u] RFR - 8066612: Add a test that will call getDeclaredFields() on all classes and try to set them accessible. In-Reply-To: <548047C3.8000400@oracle.com> References: <547F9302.3060309@oracle.com> <547FD6F2.5060400@oracle.com> <548023D0.4020702@oracle.com> <548047C3.8000400@oracle.com> Message-ID: <54804E4B.2070908@oracle.com> Hi Daniel, On 4/12/2014 9:38 PM, Daniel Fuchs wrote: > Hi David, > > In fact I could use 'null' on JDK 9 as well. > My first version of the JDK 9 test was parsing over all the .jimage > files under /lib/modules - which explain why I needed to > use the System class loader. > > Then I switched to only parsing the bootmodules.jimage - because > I noticed that the results where more coherent with what I had > observed on 8 & 7 - but I kept using the System class loader. > > I am not sure whether we want the test for 9 should iterate over > the three .jimage - or continue to test only the boot .jimage. > > I have updated the JDK 9 test (refreshed the webrev in place) > http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.00/ > and added support for possibly running the test in the two modes > (I added a 'test.boot.only' system property, true by default) > as well as additional traces to print the loaded classes by > defining loader at the end (test.list.classes, false by default). A couple of initial comments: 104 static ClassLoader getClassLoaderFor(String classFileName) { 105 if (restrictToBoot) return null; // only bootmodules 106 return ClassLoaders.systemClassLoader; 107 } I'm not clear the intent here. If it is to return a loader for which loadClass could be invoked then you can always just return the system loader - or just Class.forName. If it is meant to the return the expected defining loader then it isn't doing that as the extensions loader is not allowed for. Similarly for: 128 static ClassLoader getFor(String classFileName) { 129 return systemClassLoader; 130 } Minor nit - In: 135 System.err.println("Unexpected loader for "+c+": "+c.getClassLoader()); c.getClassLoader() can be replaced by cl. Also put spaces around the + operator. David (signing off for the night) > Thanks for your question, it triggered me into looking deeper > into what was happening :-) > > best regards, > > -- daniel > > On 04/12/14 10:05, Daniel Fuchs wrote: >>>> The differences between 8 & 9 are limited to: >>>> >>>> - ClassLoader: >>>> - on 8 we use 'null' (BCL) >>>> - on 9 we use the system class loader. >>> >>> I haven't seen anything in JEP 220, regarding modules, that indicates >>> that classes currently loaded by the boot-loader will now be loaded >>> by the system classloader ??? >> >> In [1] towards the end: >> >> [1] http://openjdk.java.net/jeps/220 >> >> "The defining class loader of the types in some existing packages >> will change. Existing code that makes assumptions about the class >> loaders of these types might not work correctly." >> (then there is a list of specific changes). >> >> This test looks up all class names in the image files and attempt >> to load the corresponding class. But as indicated in [1] >> some of these classes are now in the Boot CL, some in the >> Extension CL, and some in the Application CL. >> >> So the test uses the System CL to load each class - which ensures >> that the loading will be delegated to the appropriate ClassLoader. >> >> best regards, >> >> -- daniel > From konstantin.shefov at oracle.com Thu Dec 4 12:16:16 2014 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Thu, 04 Dec 2014 15:16:16 +0300 Subject: [8u40] Request for review and approval: 8059070 : [TESTBUG] java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java failed - timeout In-Reply-To: <547C59FB.6070304@oracle.com> References: <5478AEFE.8010009@oracle.com> <547C4891.2050906@oracle.com> <547C59FB.6070304@oracle.com> Message-ID: <54805090.6080500@oracle.com> Hello, I have made a new webrev for this fix that uses Igor's timeout tool from JDK 9: http://cr.openjdk.java.net/~kshefov/8059070_8u/webrev.01 This is a fix to test for one of 8u40 features. -Konstantin On 01.12.2014 15:07, Konstantin Shefov wrote: > Paul, Igor > > On 01.12.2014 13:55, Paul Sandoz wrote: >> On Dec 1, 2014, at 11:53 AM, Konstantin Shefov >> wrote: >> >>> Paul, >>> >>> On 01.12.2014 11:48, Paul Sandoz wrote: >>>> On Nov 28, 2014, at 6:21 PM, Konstantin Shefov >>>> wrote: >>>> >>>>> Please review and approve backport of JDK-8059070 to 8u40. >>>>> >>>>> This is the test fix and it is a bit different from that of JDK 9. >>>>> >>>> Looks ok. >>>> >>>> Why is it different to the fix in 9? >>> It is because in JDK 8u there is no adjustTimeout function in Utils >>> class, so I added it. And I think it will be better to define where >>> to stop interations depending on the iteration with the maximum >>> time, not the average iteration time. >>> If tests still fail with timeout in JDK 9, I will also change >>> average iteration time to maximum time in JDK 9. >>> >> Ok. >> >> I see Igor has factored out similar functionality in a separate patch >> under review in core-libs. > Well, in this case I can reuse the functionality Igor introduced, but > it is going to be in JDK 9. Will it be backported to JDK 8? And there > is "maxDuration << 1" in the file > "lib/testlibrary/jdk/testlibrary/TimeLimitedRunner.java" but what if > we need multiplier greater than 2, e.g. 4? > > -Konstantin >> >> Paul. > From daniel.fuchs at oracle.com Thu Dec 4 12:25:03 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 04 Dec 2014 13:25:03 +0100 Subject: [9 + 8u] RFR - 8066612: Add a test that will call getDeclaredFields() on all classes and try to set them accessible. In-Reply-To: <54804E4B.2070908@oracle.com> References: <547F9302.3060309@oracle.com> <547FD6F2.5060400@oracle.com> <548023D0.4020702@oracle.com> <548047C3.8000400@oracle.com> <54804E4B.2070908@oracle.com> Message-ID: <5480529F.1020902@oracle.com> On 04/12/14 13:06, David Holmes wrote: > Hi Daniel, > > On 4/12/2014 9:38 PM, Daniel Fuchs wrote: >> Hi David, >> >> In fact I could use 'null' on JDK 9 as well. >> My first version of the JDK 9 test was parsing over all the .jimage >> files under /lib/modules - which explain why I needed to >> use the System class loader. >> >> Then I switched to only parsing the bootmodules.jimage - because >> I noticed that the results where more coherent with what I had >> observed on 8 & 7 - but I kept using the System class loader. >> >> I am not sure whether we want the test for 9 should iterate over >> the three .jimage - or continue to test only the boot .jimage. >> >> I have updated the JDK 9 test (refreshed the webrev in place) >> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.00/ >> and added support for possibly running the test in the two modes >> (I added a 'test.boot.only' system property, true by default) >> as well as additional traces to print the loaded classes by >> defining loader at the end (test.list.classes, false by default). > > A couple of initial comments: > > 104 static ClassLoader getClassLoaderFor(String classFileName) { > 105 if (restrictToBoot) return null; // only bootmodules > 106 return ClassLoaders.systemClassLoader; > 107 } > > I'm not clear the intent here. If it is to return a loader for which > loadClass could be invoked then you can always just return the system > loader - or just Class.forName. If it is meant to the return the > expected defining loader then it isn't doing that as the extensions > loader is not allowed for. The intent is to return the class loader that will be passed to Class.forName( ). I've been fiddling & experimenting with this test over 3 different platforms while trying to minimize the differences - so that was my attempt at having a good place to experiment with different strategy for loading classes. > Similarly for: > > 128 static ClassLoader getFor(String classFileName) { > 129 return systemClassLoader; > 130 } Oh - that's my mistake. In fact ClassLoader getClassLoaderFor(..) was supposed to simply return ClassLoaders.getFor(...); and all the code should be in ClassLoaders.getFor - my bad. > Minor nit - In: > > 135 System.err.println("Unexpected loader for "+c+": > "+c.getClassLoader()); > > c.getClassLoader() can be replaced by cl. Also put spaces around the + > operator. Good catch. Thanks a lot David! Have a good night! (that's quite late - isn't it?) -- daniel > > David > (signing off for the night) > >> Thanks for your question, it triggered me into looking deeper >> into what was happening :-) >> >> best regards, >> >> -- daniel >> >> On 04/12/14 10:05, Daniel Fuchs wrote: >>>>> The differences between 8 & 9 are limited to: >>>>> >>>>> - ClassLoader: >>>>> - on 8 we use 'null' (BCL) >>>>> - on 9 we use the system class loader. >>>> >>>> I haven't seen anything in JEP 220, regarding modules, that indicates >>>> that classes currently loaded by the boot-loader will now be loaded >>>> by the system classloader ??? >>> >>> In [1] towards the end: >>> >>> [1] http://openjdk.java.net/jeps/220 >>> >>> "The defining class loader of the types in some existing packages >>> will change. Existing code that makes assumptions about the class >>> loaders of these types might not work correctly." >>> (then there is a list of specific changes). >>> >>> This test looks up all class names in the image files and attempt >>> to load the corresponding class. But as indicated in [1] >>> some of these classes are now in the Boot CL, some in the >>> Extension CL, and some in the Application CL. >>> >>> So the test uses the System CL to load each class - which ensures >>> that the loading will be delegated to the appropriate ClassLoader. >>> >>> best regards, >>> >>> -- daniel >> From vladimir.x.ivanov at oracle.com Thu Dec 4 11:27:08 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 04 Dec 2014 15:27:08 +0400 Subject: [8u40] Request for review and approval: 8059070 : [TESTBUG] java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java failed - timeout In-Reply-To: <54805090.6080500@oracle.com> References: <5478AEFE.8010009@oracle.com> <547C4891.2050906@oracle.com> <547C59FB.6070304@oracle.com> <54805090.6080500@oracle.com> Message-ID: <5480450C.7060108@oracle.com> Looks good (not a Reviewer). Best regards, Vladimir Ivanov On 12/4/14, 4:16 PM, Konstantin Shefov wrote: > Hello, > > I have made a new webrev for this fix that uses Igor's timeout tool from > JDK 9: http://cr.openjdk.java.net/~kshefov/8059070_8u/webrev.01 > This is a fix to test for one of 8u40 features. > > -Konstantin > > On 01.12.2014 15:07, Konstantin Shefov wrote: >> Paul, Igor >> >> On 01.12.2014 13:55, Paul Sandoz wrote: >>> On Dec 1, 2014, at 11:53 AM, Konstantin Shefov >>> wrote: >>> >>>> Paul, >>>> >>>> On 01.12.2014 11:48, Paul Sandoz wrote: >>>>> On Nov 28, 2014, at 6:21 PM, Konstantin Shefov >>>>> wrote: >>>>> >>>>>> Please review and approve backport of JDK-8059070 to 8u40. >>>>>> >>>>>> This is the test fix and it is a bit different from that of JDK 9. >>>>>> >>>>> Looks ok. >>>>> >>>>> Why is it different to the fix in 9? >>>> It is because in JDK 8u there is no adjustTimeout function in Utils >>>> class, so I added it. And I think it will be better to define where >>>> to stop interations depending on the iteration with the maximum >>>> time, not the average iteration time. >>>> If tests still fail with timeout in JDK 9, I will also change >>>> average iteration time to maximum time in JDK 9. >>>> >>> Ok. >>> >>> I see Igor has factored out similar functionality in a separate patch >>> under review in core-libs. >> Well, in this case I can reuse the functionality Igor introduced, but >> it is going to be in JDK 9. Will it be backported to JDK 8? And there >> is "maxDuration << 1" in the file >> "lib/testlibrary/jdk/testlibrary/TimeLimitedRunner.java" but what if >> we need multiplier greater than 2, e.g. 4? >> >> -Konstantin >>> >>> Paul. >> > From daniel.fuchs at oracle.com Thu Dec 4 12:29:42 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 04 Dec 2014 13:29:42 +0100 Subject: [8u40] Request for review and approval: 8059070 : [TESTBUG] java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java failed - timeout In-Reply-To: <54805090.6080500@oracle.com> References: <5478AEFE.8010009@oracle.com> <547C4891.2050906@oracle.com> <547C59FB.6070304@oracle.com> <54805090.6080500@oracle.com> Message-ID: <548053B6.7090303@oracle.com> On 04/12/14 13:16, Konstantin Shefov wrote: > Hello, > > I have made a new webrev for this fix that uses Igor's timeout tool from > JDK 9: http://cr.openjdk.java.net/~kshefov/8059070_8u/webrev.01 > This is a fix to test for one of 8u40 features. > > -Konstantin Hi Konstantin, While you're at it, could you move the @ignore tag below the @library tag in those files that have an @ignore? (e.g. LFGarbageCollectedTest.java) Having @ignore before @library makes jtreg complain that @library should come before @run (I learned that @ignore is an @run in disguise). best regards, -- daniel > > On 01.12.2014 15:07, Konstantin Shefov wrote: >> Paul, Igor >> >> On 01.12.2014 13:55, Paul Sandoz wrote: >>> On Dec 1, 2014, at 11:53 AM, Konstantin Shefov >>> wrote: >>> >>>> Paul, >>>> >>>> On 01.12.2014 11:48, Paul Sandoz wrote: >>>>> On Nov 28, 2014, at 6:21 PM, Konstantin Shefov >>>>> wrote: >>>>> >>>>>> Please review and approve backport of JDK-8059070 to 8u40. >>>>>> >>>>>> This is the test fix and it is a bit different from that of JDK 9. >>>>>> >>>>> Looks ok. >>>>> >>>>> Why is it different to the fix in 9? >>>> It is because in JDK 8u there is no adjustTimeout function in Utils >>>> class, so I added it. And I think it will be better to define where >>>> to stop interations depending on the iteration with the maximum >>>> time, not the average iteration time. >>>> If tests still fail with timeout in JDK 9, I will also change >>>> average iteration time to maximum time in JDK 9. >>>> >>> Ok. >>> >>> I see Igor has factored out similar functionality in a separate patch >>> under review in core-libs. >> Well, in this case I can reuse the functionality Igor introduced, but >> it is going to be in JDK 9. Will it be backported to JDK 8? And there >> is "maxDuration << 1" in the file >> "lib/testlibrary/jdk/testlibrary/TimeLimitedRunner.java" but what if >> we need multiplier greater than 2, e.g. 4? >> >> -Konstantin >>> >>> Paul. >> > From konstantin.shefov at oracle.com Thu Dec 4 12:32:35 2014 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Thu, 04 Dec 2014 15:32:35 +0300 Subject: [8u40] Request for review and approval: 8059070 : [TESTBUG] java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java failed - timeout In-Reply-To: <548053B6.7090303@oracle.com> References: <5478AEFE.8010009@oracle.com> <547C4891.2050906@oracle.com> <547C59FB.6070304@oracle.com> <54805090.6080500@oracle.com> <548053B6.7090303@oracle.com> Message-ID: <54805463.2090001@oracle.com> Well, I have put @ignore after @library: http://cr.openjdk.java.net/~kshefov/8059070_8u/webrev.02 On 04.12.2014 15:29, Daniel Fuchs wrote: > On 04/12/14 13:16, Konstantin Shefov wrote: >> Hello, >> >> I have made a new webrev for this fix that uses Igor's timeout tool from >> JDK 9: http://cr.openjdk.java.net/~kshefov/8059070_8u/webrev.01 >> This is a fix to test for one of 8u40 features. >> >> -Konstantin > > Hi Konstantin, > > While you're at it, could you move the @ignore tag below > the @library tag in those files that have an @ignore? > (e.g. LFGarbageCollectedTest.java) > > Having @ignore before @library makes jtreg complain that > @library should come before @run (I learned that @ignore > is an @run in disguise). > > best regards, > > -- daniel > >> >> On 01.12.2014 15:07, Konstantin Shefov wrote: >>> Paul, Igor >>> >>> On 01.12.2014 13:55, Paul Sandoz wrote: >>>> On Dec 1, 2014, at 11:53 AM, Konstantin Shefov >>>> wrote: >>>> >>>>> Paul, >>>>> >>>>> On 01.12.2014 11:48, Paul Sandoz wrote: >>>>>> On Nov 28, 2014, at 6:21 PM, Konstantin Shefov >>>>>> wrote: >>>>>> >>>>>>> Please review and approve backport of JDK-8059070 to 8u40. >>>>>>> >>>>>>> This is the test fix and it is a bit different from that of JDK 9. >>>>>>> >>>>>> Looks ok. >>>>>> >>>>>> Why is it different to the fix in 9? >>>>> It is because in JDK 8u there is no adjustTimeout function in Utils >>>>> class, so I added it. And I think it will be better to define where >>>>> to stop interations depending on the iteration with the maximum >>>>> time, not the average iteration time. >>>>> If tests still fail with timeout in JDK 9, I will also change >>>>> average iteration time to maximum time in JDK 9. >>>>> >>>> Ok. >>>> >>>> I see Igor has factored out similar functionality in a separate patch >>>> under review in core-libs. >>> Well, in this case I can reuse the functionality Igor introduced, but >>> it is going to be in JDK 9. Will it be backported to JDK 8? And there >>> is "maxDuration << 1" in the file >>> "lib/testlibrary/jdk/testlibrary/TimeLimitedRunner.java" but what if >>> we need multiplier greater than 2, e.g. 4? >>> >>> -Konstantin >>>> >>>> Paul. >>> >> > From sean.coffey at oracle.com Thu Dec 4 13:02:21 2014 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Thu, 04 Dec 2014 13:02:21 +0000 Subject: [9 + 8u] RFR - 8066612: Add a test that will call getDeclaredFields() on all classes and try to set them accessible. In-Reply-To: <5480529F.1020902@oracle.com> References: <547F9302.3060309@oracle.com> <547FD6F2.5060400@oracle.com> <548023D0.4020702@oracle.com> <548047C3.8000400@oracle.com> <54804E4B.2070908@oracle.com> <5480529F.1020902@oracle.com> Message-ID: <54805B5D.5020504@oracle.com> Thanks for driving efforts in this area Daniel. I think it's a very useful test and is bound to help test code coverage. If it's currently passing on all JPRT platforms, it's a good measure. Eventually I think we can bulk up the tests that can be run on the Iterable returned from your class search. At moment you just test Field.setAccessible. In the future, I don't see any harm in adding all simple Field method calls so that any corner cases in custom classes like the original issue are caught. e.g Field.getDeclaredAnnotations(), Field.getModifiers(), Field.isEnumConstant() etc., etc. Some methods won't be much value add but they're not a cost either. Same argument for running through all Class methods, e.g Class.getDeclaredClasses(), Class.getDeclaredMethods(). As a result this test might eventually become more general in test goal and might live better one level up in "test/java/lang/Class/" - it can be moved when the time comes. regards, Sean. On 04/12/2014 12:25, Daniel Fuchs wrote: > On 04/12/14 13:06, David Holmes wrote: >> Hi Daniel, >> >> On 4/12/2014 9:38 PM, Daniel Fuchs wrote: >>> Hi David, >>> >>> In fact I could use 'null' on JDK 9 as well. >>> My first version of the JDK 9 test was parsing over all the .jimage >>> files under /lib/modules - which explain why I needed to >>> use the System class loader. >>> >>> Then I switched to only parsing the bootmodules.jimage - because >>> I noticed that the results where more coherent with what I had >>> observed on 8 & 7 - but I kept using the System class loader. >>> >>> I am not sure whether we want the test for 9 should iterate over >>> the three .jimage - or continue to test only the boot .jimage. >>> >>> I have updated the JDK 9 test (refreshed the webrev in place) >>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.00/ >>> and added support for possibly running the test in the two modes >>> (I added a 'test.boot.only' system property, true by default) >>> as well as additional traces to print the loaded classes by >>> defining loader at the end (test.list.classes, false by default). >> >> A couple of initial comments: >> >> 104 static ClassLoader getClassLoaderFor(String classFileName) { >> 105 if (restrictToBoot) return null; // only bootmodules >> 106 return ClassLoaders.systemClassLoader; >> 107 } >> >> I'm not clear the intent here. If it is to return a loader for which >> loadClass could be invoked then you can always just return the system >> loader - or just Class.forName. If it is meant to the return the >> expected defining loader then it isn't doing that as the extensions >> loader is not allowed for. > > The intent is to return the class loader that will be passed to > Class.forName( ). I've been fiddling & experimenting with this > test over 3 different platforms while trying to minimize the > differences - so that was my attempt at having a good place to > experiment with different strategy for loading classes. > >> Similarly for: >> >> 128 static ClassLoader getFor(String classFileName) { >> 129 return systemClassLoader; >> 130 } > > Oh - that's my mistake. In fact ClassLoader getClassLoaderFor(..) > was supposed to simply return ClassLoaders.getFor(...); > and all the code should be in ClassLoaders.getFor - my bad. > >> Minor nit - In: >> >> 135 System.err.println("Unexpected loader for "+c+": >> "+c.getClassLoader()); >> >> c.getClassLoader() can be replaced by cl. Also put spaces around the + >> operator. > > Good catch. > > Thanks a lot David! Have a good night! (that's quite late - isn't it?) > > -- daniel > >> >> David >> (signing off for the night) >> >>> Thanks for your question, it triggered me into looking deeper >>> into what was happening :-) >>> >>> best regards, >>> >>> -- daniel >>> >>> On 04/12/14 10:05, Daniel Fuchs wrote: >>>>>> The differences between 8 & 9 are limited to: >>>>>> >>>>>> - ClassLoader: >>>>>> - on 8 we use 'null' (BCL) >>>>>> - on 9 we use the system class loader. >>>>> >>>>> I haven't seen anything in JEP 220, regarding modules, that indicates >>>>> that classes currently loaded by the boot-loader will now be loaded >>>>> by the system classloader ??? >>>> >>>> In [1] towards the end: >>>> >>>> [1] http://openjdk.java.net/jeps/220 >>>> >>>> "The defining class loader of the types in some existing packages >>>> will change. Existing code that makes assumptions about the class >>>> loaders of these types might not work correctly." >>>> (then there is a list of specific changes). >>>> >>>> This test looks up all class names in the image files and attempt >>>> to load the corresponding class. But as indicated in [1] >>>> some of these classes are now in the Boot CL, some in the >>>> Extension CL, and some in the Application CL. >>>> >>>> So the test uses the System CL to load each class - which ensures >>>> that the loading will be delegated to the appropriate ClassLoader. >>>> >>>> best regards, >>>> >>>> -- daniel >>> > From daniel.fuchs at oracle.com Thu Dec 4 13:58:00 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 04 Dec 2014 14:58:00 +0100 Subject: [8u40] Request for review and approval: 8059070 : [TESTBUG] java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java failed - timeout In-Reply-To: <54805463.2090001@oracle.com> References: <5478AEFE.8010009@oracle.com> <547C4891.2050906@oracle.com> <547C59FB.6070304@oracle.com> <54805090.6080500@oracle.com> <548053B6.7090303@oracle.com> <54805463.2090001@oracle.com> Message-ID: <54806868.5000602@oracle.com> On 04/12/14 13:32, Konstantin Shefov wrote: > Well, I have put @ignore after @library: > http://cr.openjdk.java.net/~kshefov/8059070_8u/webrev.02 Thanks a lot for taking care of it Konstantin :-) Logging an issue for that had been on my todo list for a few days :-) -- daniel > > On 04.12.2014 15:29, Daniel Fuchs wrote: >> On 04/12/14 13:16, Konstantin Shefov wrote: >>> Hello, >>> >>> I have made a new webrev for this fix that uses Igor's timeout tool from >>> JDK 9: http://cr.openjdk.java.net/~kshefov/8059070_8u/webrev.01 >>> This is a fix to test for one of 8u40 features. >>> >>> -Konstantin >> >> Hi Konstantin, >> >> While you're at it, could you move the @ignore tag below >> the @library tag in those files that have an @ignore? >> (e.g. LFGarbageCollectedTest.java) >> >> Having @ignore before @library makes jtreg complain that >> @library should come before @run (I learned that @ignore >> is an @run in disguise). >> >> best regards, >> >> -- daniel >> >>> >>> On 01.12.2014 15:07, Konstantin Shefov wrote: >>>> Paul, Igor >>>> >>>> On 01.12.2014 13:55, Paul Sandoz wrote: >>>>> On Dec 1, 2014, at 11:53 AM, Konstantin Shefov >>>>> wrote: >>>>> >>>>>> Paul, >>>>>> >>>>>> On 01.12.2014 11:48, Paul Sandoz wrote: >>>>>>> On Nov 28, 2014, at 6:21 PM, Konstantin Shefov >>>>>>> wrote: >>>>>>> >>>>>>>> Please review and approve backport of JDK-8059070 to 8u40. >>>>>>>> >>>>>>>> This is the test fix and it is a bit different from that of JDK 9. >>>>>>>> >>>>>>> Looks ok. >>>>>>> >>>>>>> Why is it different to the fix in 9? >>>>>> It is because in JDK 8u there is no adjustTimeout function in Utils >>>>>> class, so I added it. And I think it will be better to define where >>>>>> to stop interations depending on the iteration with the maximum >>>>>> time, not the average iteration time. >>>>>> If tests still fail with timeout in JDK 9, I will also change >>>>>> average iteration time to maximum time in JDK 9. >>>>>> >>>>> Ok. >>>>> >>>>> I see Igor has factored out similar functionality in a separate patch >>>>> under review in core-libs. >>>> Well, in this case I can reuse the functionality Igor introduced, but >>>> it is going to be in JDK 9. Will it be backported to JDK 8? And there >>>> is "maxDuration << 1" in the file >>>> "lib/testlibrary/jdk/testlibrary/TimeLimitedRunner.java" but what if >>>> we need multiplier greater than 2, e.g. 4? >>>> >>>> -Konstantin >>>>> >>>>> Paul. >>>> >>> >> > From daniel.fuchs at oracle.com Thu Dec 4 17:13:11 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 04 Dec 2014 18:13:11 +0100 Subject: [9 + 8u] RFR - 8066612: Add a test that will call getDeclaredFields() on all classes and try to set them accessible. In-Reply-To: <54805B5D.5020504@oracle.com> References: <547F9302.3060309@oracle.com> <547FD6F2.5060400@oracle.com> <548023D0.4020702@oracle.com> <548047C3.8000400@oracle.com> <54804E4B.2070908@oracle.com> <5480529F.1020902@oracle.com> <54805B5D.5020504@oracle.com> Message-ID: <54809627.8070103@oracle.com> On 04/12/14 14:02, Se?n Coffey wrote: > Thanks for driving efforts in this area Daniel. I think it's a very > useful test and is bound to help test code coverage. If it's currently > passing on all JPRT platforms, it's a good measure. It seems to :-) > Eventually I think we can bulk up the tests that can be run on the > Iterable returned from your class search. > At moment you just test Field.setAccessible. Yes. If we change it later to test more, we will probably need to change its name. I was already in lack of inspiration: FieldSetAccessibleTest is not really a great name - but hopefully it can do for now. > In the future, I don't see any harm in adding all simple Field method > calls so that any corner cases in custom classes like the original issue > are caught. e.g Field.getDeclaredAnnotations(), Field.getModifiers(), > Field.isEnumConstant() etc., etc. Some methods won't be much value add > but they're not a cost either. Agreed. > Same argument for running through all Class methods, e.g > Class.getDeclaredClasses(), Class.getDeclaredMethods(). As a result this > test might eventually become more general in test goal and might live > better one level up in "test/java/lang/Class/" - it can be moved when > the time comes. Agreed as well :-) Here is a new revision of the webrev for 9 in which I have incorporated David's comment: http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.01/ best regards, -- daniel > > regards, > Sean. > > On 04/12/2014 12:25, Daniel Fuchs wrote: >> On 04/12/14 13:06, David Holmes wrote: >>> Hi Daniel, >>> >>> On 4/12/2014 9:38 PM, Daniel Fuchs wrote: >>>> Hi David, >>>> >>>> In fact I could use 'null' on JDK 9 as well. >>>> My first version of the JDK 9 test was parsing over all the .jimage >>>> files under /lib/modules - which explain why I needed to >>>> use the System class loader. >>>> >>>> Then I switched to only parsing the bootmodules.jimage - because >>>> I noticed that the results where more coherent with what I had >>>> observed on 8 & 7 - but I kept using the System class loader. >>>> >>>> I am not sure whether we want the test for 9 should iterate over >>>> the three .jimage - or continue to test only the boot .jimage. >>>> >>>> I have updated the JDK 9 test (refreshed the webrev in place) >>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.00/ >>>> and added support for possibly running the test in the two modes >>>> (I added a 'test.boot.only' system property, true by default) >>>> as well as additional traces to print the loaded classes by >>>> defining loader at the end (test.list.classes, false by default). >>> >>> A couple of initial comments: >>> >>> 104 static ClassLoader getClassLoaderFor(String classFileName) { >>> 105 if (restrictToBoot) return null; // only bootmodules >>> 106 return ClassLoaders.systemClassLoader; >>> 107 } >>> >>> I'm not clear the intent here. If it is to return a loader for which >>> loadClass could be invoked then you can always just return the system >>> loader - or just Class.forName. If it is meant to the return the >>> expected defining loader then it isn't doing that as the extensions >>> loader is not allowed for. >> >> The intent is to return the class loader that will be passed to >> Class.forName( ). I've been fiddling & experimenting with this >> test over 3 different platforms while trying to minimize the >> differences - so that was my attempt at having a good place to >> experiment with different strategy for loading classes. >> >>> Similarly for: >>> >>> 128 static ClassLoader getFor(String classFileName) { >>> 129 return systemClassLoader; >>> 130 } >> >> Oh - that's my mistake. In fact ClassLoader getClassLoaderFor(..) >> was supposed to simply return ClassLoaders.getFor(...); >> and all the code should be in ClassLoaders.getFor - my bad. >> >>> Minor nit - In: >>> >>> 135 System.err.println("Unexpected loader for "+c+": >>> "+c.getClassLoader()); >>> >>> c.getClassLoader() can be replaced by cl. Also put spaces around the + >>> operator. >> >> Good catch. >> >> Thanks a lot David! Have a good night! (that's quite late - isn't it?) >> >> -- daniel >> >>> >>> David >>> (signing off for the night) >>> >>>> Thanks for your question, it triggered me into looking deeper >>>> into what was happening :-) >>>> >>>> best regards, >>>> >>>> -- daniel >>>> >>>> On 04/12/14 10:05, Daniel Fuchs wrote: >>>>>>> The differences between 8 & 9 are limited to: >>>>>>> >>>>>>> - ClassLoader: >>>>>>> - on 8 we use 'null' (BCL) >>>>>>> - on 9 we use the system class loader. >>>>>> >>>>>> I haven't seen anything in JEP 220, regarding modules, that indicates >>>>>> that classes currently loaded by the boot-loader will now be loaded >>>>>> by the system classloader ??? >>>>> >>>>> In [1] towards the end: >>>>> >>>>> [1] http://openjdk.java.net/jeps/220 >>>>> >>>>> "The defining class loader of the types in some existing packages >>>>> will change. Existing code that makes assumptions about the class >>>>> loaders of these types might not work correctly." >>>>> (then there is a list of specific changes). >>>>> >>>>> This test looks up all class names in the image files and attempt >>>>> to load the corresponding class. But as indicated in [1] >>>>> some of these classes are now in the Boot CL, some in the >>>>> Extension CL, and some in the Application CL. >>>>> >>>>> So the test uses the System CL to load each class - which ensures >>>>> that the loading will be delegated to the appropriate ClassLoader. >>>>> >>>>> best regards, >>>>> >>>>> -- daniel >>>> >> > From mandy.chung at oracle.com Thu Dec 4 18:56:54 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 04 Dec 2014 10:56:54 -0800 Subject: [8u40] Review request for 8065702+8065675 Deprecate the Endorsed and Extension Mechanisms Message-ID: <5480AE76.80108@oracle.com> This is to request review and approval to putback these spec changes in 8u40. JDK-8065702 Deprecate the Extension Mechanism JDK-8065675 Deprecate the Endorsed-Standards Override Mechanism The endorsed and extension mechanisms are proposed to be removed in JDK 9 [1]. This patch updates the following specifications: 1. javadoc of System.getProperties to deprecate "java.ext.dirs" 2. deprecate three fields injava.util.jar.Attributes.Names EXTENSION_INSTALLATION IMPLEMENTATION_VENDOR_ID IMPLEMENTATION_URL 3. deprecate the ability of a JAR-packaged applet to depend on an installed optional package and trigger downloading of optional packages and its relevant attributes TheMaintenance Review of JSR 337 (Java SE 8) will indicate the above spec changes. There is no implementation change in this patch. The specification of the Class-Path attribute and Sealed attributes are misplaced and they should belong to the JAR file specification. This patch moves them from extensions to the JAR file specification. Webrev at: http://cr.openjdk.java.net/~mchung/jdk8u/webrevs/8065702/webrev.00/ http://cr.openjdk.java.net/~mchung/jdk8u/webrevs/8065702/api-diff/overview-summary.html http://cr.openjdk.java.net/~mchung/jdk8u/webrevs/8065702/specdiff/overview-summary.html Mandy [1] http://openjdk.java.net/jeps/220 [2] http://openjdk.java.net/projects/jdk8/spec/ From Alan.Bateman at oracle.com Thu Dec 4 20:34:22 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 04 Dec 2014 20:34:22 +0000 Subject: [8u40] Review request for 8065702+8065675 Deprecate the Endorsed and Extension Mechanisms In-Reply-To: <5480AE76.80108@oracle.com> References: <5480AE76.80108@oracle.com> Message-ID: <5480C54E.1090303@oracle.com> On 04/12/2014 18:56, Mandy Chung wrote: > This is to request review and approval to putback these spec changes > in 8u40. > JDK-8065702 Deprecate the Extension Mechanism > JDK-8065675 Deprecate the Endorsed-Standards Override Mechanism > > : > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk8u/webrevs/8065702/webrev.00/ This looks good to me and I hope will be approved for 8u40. -Alan From rob.mckenna at oracle.com Thu Dec 4 20:37:17 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 04 Dec 2014 20:37:17 +0000 Subject: [8u40] Review request for 8065702+8065675 Deprecate the Endorsed and Extension Mechanisms In-Reply-To: <5480AE76.80108@oracle.com> References: <5480AE76.80108@oracle.com> Message-ID: <5480C5FD.4070605@oracle.com> Approved. Please add the appropriate noreg keywords. -Rob On 04/12/14 18:56, Mandy Chung wrote: > This is to request review and approval to putback these spec changes > in 8u40. > JDK-8065702 Deprecate the Extension Mechanism > JDK-8065675 Deprecate the Endorsed-Standards Override Mechanism > > The endorsed and extension mechanisms are proposed to be removed > in JDK 9 [1]. This patch updates the following specifications: > > 1. javadoc of System.getProperties to deprecate "java.ext.dirs" > > 2. deprecate three fields injava.util.jar.Attributes.Names > EXTENSION_INSTALLATION > IMPLEMENTATION_VENDOR_ID > IMPLEMENTATION_URL > > 3. deprecate the ability of a JAR-packaged applet to depend on > an installed optional package and trigger downloading of > optional packages and its relevant attributes > > TheMaintenance Review of JSR 337 (Java SE 8) will indicate the > above spec changes. There is no implementation change in this > patch. > > The specification of the Class-Path attribute and Sealed attributes > are misplaced and they should belong to the JAR file specification. > This patch moves them from extensions to the JAR file specification. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk8u/webrevs/8065702/webrev.00/ > http://cr.openjdk.java.net/~mchung/jdk8u/webrevs/8065702/api-diff/overview-summary.html > > http://cr.openjdk.java.net/~mchung/jdk8u/webrevs/8065702/specdiff/overview-summary.html > > > Mandy > [1] http://openjdk.java.net/jeps/220 > [2] http://openjdk.java.net/projects/jdk8/spec/ > From iris.clark at oracle.com Thu Dec 4 22:59:18 2014 From: iris.clark at oracle.com (Iris Clark) Date: Thu, 4 Dec 2014 14:59:18 -0800 (PST) Subject: [8u40] Review request for 8065702+8065675 Deprecate the Endorsed and Extension Mechanisms In-Reply-To: <5480AE76.80108@oracle.com> References: <5480AE76.80108@oracle.com> Message-ID: <843cd133-7e4a-4a94-8090-5616867cf5fc@default> Hi, Mandy. > http://cr.openjdk.java.net/~mchung/jdk8u/webrevs/8065702/webrev.00/ This looks good. Thanks! Iris From david.holmes at oracle.com Thu Dec 4 23:36:08 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 05 Dec 2014 09:36:08 +1000 Subject: [9 + 8u] RFR - 8066612: Add a test that will call getDeclaredFields() on all classes and try to set them accessible. In-Reply-To: <54809627.8070103@oracle.com> References: <547F9302.3060309@oracle.com> <547FD6F2.5060400@oracle.com> <548023D0.4020702@oracle.com> <548047C3.8000400@oracle.com> <54804E4B.2070908@oracle.com> <5480529F.1020902@oracle.com> <54805B5D.5020504@oracle.com> <54809627.8070103@oracle.com> Message-ID: <5480EFE8.3090809@oracle.com> Hi Daniel, I still find your use of the classloader very confusing. You talk about the defining loader but you never check the defining loader against anything. In 146 static void checkFor(Class c, ClassLoader loader) { the loader variable is never used. And if loader is simply the name of the loader passed to forName, then it may not be the defining loader anyway - so the whole use of this loader variable seems superfluous at best, and confusing/misleading at worst. And you can use the simple forName(name) variant rather than passing a loader. David On 5/12/2014 3:13 AM, Daniel Fuchs wrote: > On 04/12/14 14:02, Se?n Coffey wrote: >> Thanks for driving efforts in this area Daniel. I think it's a very >> useful test and is bound to help test code coverage. If it's currently >> passing on all JPRT platforms, it's a good measure. > > It seems to :-) > >> Eventually I think we can bulk up the tests that can be run on the >> Iterable returned from your class search. >> At moment you just test Field.setAccessible. > > Yes. If we change it later to test more, we will probably need to > change its name. I was already in lack of inspiration: > FieldSetAccessibleTest is not really a great name - but hopefully > it can do for now. > >> In the future, I don't see any harm in adding all simple Field method >> calls so that any corner cases in custom classes like the original issue >> are caught. e.g Field.getDeclaredAnnotations(), Field.getModifiers(), >> Field.isEnumConstant() etc., etc. Some methods won't be much value add >> but they're not a cost either. > > Agreed. > >> Same argument for running through all Class methods, e.g >> Class.getDeclaredClasses(), Class.getDeclaredMethods(). As a result this >> test might eventually become more general in test goal and might live >> better one level up in "test/java/lang/Class/" - it can be moved when >> the time comes. > > Agreed as well :-) > > Here is a new revision of the webrev for 9 in which I have > incorporated David's comment: > > http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.01/ > > best regards, > > -- daniel > >> >> regards, >> Sean. >> >> On 04/12/2014 12:25, Daniel Fuchs wrote: >>> On 04/12/14 13:06, David Holmes wrote: >>>> Hi Daniel, >>>> >>>> On 4/12/2014 9:38 PM, Daniel Fuchs wrote: >>>>> Hi David, >>>>> >>>>> In fact I could use 'null' on JDK 9 as well. >>>>> My first version of the JDK 9 test was parsing over all the .jimage >>>>> files under /lib/modules - which explain why I needed to >>>>> use the System class loader. >>>>> >>>>> Then I switched to only parsing the bootmodules.jimage - because >>>>> I noticed that the results where more coherent with what I had >>>>> observed on 8 & 7 - but I kept using the System class loader. >>>>> >>>>> I am not sure whether we want the test for 9 should iterate over >>>>> the three .jimage - or continue to test only the boot .jimage. >>>>> >>>>> I have updated the JDK 9 test (refreshed the webrev in place) >>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.00/ >>>>> and added support for possibly running the test in the two modes >>>>> (I added a 'test.boot.only' system property, true by default) >>>>> as well as additional traces to print the loaded classes by >>>>> defining loader at the end (test.list.classes, false by default). >>>> >>>> A couple of initial comments: >>>> >>>> 104 static ClassLoader getClassLoaderFor(String classFileName) { >>>> 105 if (restrictToBoot) return null; // only bootmodules >>>> 106 return ClassLoaders.systemClassLoader; >>>> 107 } >>>> >>>> I'm not clear the intent here. If it is to return a loader for which >>>> loadClass could be invoked then you can always just return the system >>>> loader - or just Class.forName. If it is meant to the return the >>>> expected defining loader then it isn't doing that as the extensions >>>> loader is not allowed for. >>> >>> The intent is to return the class loader that will be passed to >>> Class.forName( ). I've been fiddling & experimenting with this >>> test over 3 different platforms while trying to minimize the >>> differences - so that was my attempt at having a good place to >>> experiment with different strategy for loading classes. >>> >>>> Similarly for: >>>> >>>> 128 static ClassLoader getFor(String classFileName) { >>>> 129 return systemClassLoader; >>>> 130 } >>> >>> Oh - that's my mistake. In fact ClassLoader getClassLoaderFor(..) >>> was supposed to simply return ClassLoaders.getFor(...); >>> and all the code should be in ClassLoaders.getFor - my bad. >>> >>>> Minor nit - In: >>>> >>>> 135 System.err.println("Unexpected loader for >>>> "+c+": >>>> "+c.getClassLoader()); >>>> >>>> c.getClassLoader() can be replaced by cl. Also put spaces around the + >>>> operator. >>> >>> Good catch. >>> >>> Thanks a lot David! Have a good night! (that's quite late - isn't it?) >>> >>> -- daniel >>> >>>> >>>> David >>>> (signing off for the night) >>>> >>>>> Thanks for your question, it triggered me into looking deeper >>>>> into what was happening :-) >>>>> >>>>> best regards, >>>>> >>>>> -- daniel >>>>> >>>>> On 04/12/14 10:05, Daniel Fuchs wrote: >>>>>>>> The differences between 8 & 9 are limited to: >>>>>>>> >>>>>>>> - ClassLoader: >>>>>>>> - on 8 we use 'null' (BCL) >>>>>>>> - on 9 we use the system class loader. >>>>>>> >>>>>>> I haven't seen anything in JEP 220, regarding modules, that >>>>>>> indicates >>>>>>> that classes currently loaded by the boot-loader will now be loaded >>>>>>> by the system classloader ??? >>>>>> >>>>>> In [1] towards the end: >>>>>> >>>>>> [1] http://openjdk.java.net/jeps/220 >>>>>> >>>>>> "The defining class loader of the types in some existing packages >>>>>> will change. Existing code that makes assumptions about the class >>>>>> loaders of these types might not work correctly." >>>>>> (then there is a list of specific changes). >>>>>> >>>>>> This test looks up all class names in the image files and attempt >>>>>> to load the corresponding class. But as indicated in [1] >>>>>> some of these classes are now in the Boot CL, some in the >>>>>> Extension CL, and some in the Application CL. >>>>>> >>>>>> So the test uses the System CL to load each class - which ensures >>>>>> that the loading will be delegated to the appropriate ClassLoader. >>>>>> >>>>>> best regards, >>>>>> >>>>>> -- daniel >>>>> >>> >> > From Sergey.Bylokhov at oracle.com Fri Dec 5 08:48:06 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 05 Dec 2014 11:48:06 +0300 Subject: [8u-dev] Request for approval: 8029536, 8024626 Message-ID: <54817146.8050803@oracle.com> Hello, These are a direct back ports from jdk 9 to jdk 8u-dev. 8029536: JFileChooser filter uses .toString() instead of getDescription() for filter text on GTK laf Bug: https://bugs.openjdk.java.net/browse/JDK-8029536 Webrev can be found at: http://cr.openjdk.java.net/~serb/8029536/webrev.00 jdk9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/43f4dc0c2489 Review: http://mail.openjdk.java.net/pipermail/swing-dev/2014-November/004053.html Reviewers: Alexander Zvegintsev, Alexander Scherbatiy 8024626: CTW CRASH: SIGSEGV in ctw/jre/lib/rt_jar/preloading_1 and ctw/jre/lib/rt_jar/sun_awt_X11_ListHelper Bug: https://bugs.openjdk.java.net/browse/JDK-8024626 Webrev can be found at: http://cr.openjdk.java.net/~serb/8024626/webrev.00 jdk9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/a01b5719c00b Review: http://mail.openjdk.java.net/pipermail/awt-dev/2014-December/008725.html Reviewers: Alexander Zvegintsev, Alexander Scherbatiy -- Best regards, Sergey. From sean.coffey at oracle.com Fri Dec 5 09:02:50 2014 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Fri, 05 Dec 2014 09:02:50 +0000 Subject: [8u-dev] Request for approval: 8029536, 8024626 In-Reply-To: <54817146.8050803@oracle.com> References: <54817146.8050803@oracle.com> Message-ID: <548174BA.4080509@oracle.com> Please add a noreg label to the 8024626 bug report. Approved. regards, Sean. On 05/12/2014 08:48, Sergey Bylokhov wrote: > Hello, > These are a direct back ports from jdk 9 to jdk 8u-dev. > > 8029536: JFileChooser filter uses .toString() instead of > getDescription() for filter text on GTK laf > Bug: https://bugs.openjdk.java.net/browse/JDK-8029536 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8029536/webrev.00 > jdk9 changeset: > http://hg.openjdk.java.net/jdk9/client/jdk/rev/43f4dc0c2489 > Review: > http://mail.openjdk.java.net/pipermail/swing-dev/2014-November/004053.html > Reviewers: Alexander Zvegintsev, Alexander Scherbatiy > > 8024626: CTW CRASH: SIGSEGV in ctw/jre/lib/rt_jar/preloading_1 and > ctw/jre/lib/rt_jar/sun_awt_X11_ListHelper > Bug: https://bugs.openjdk.java.net/browse/JDK-8024626 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8024626/webrev.00 > jdk9 changeset: > http://hg.openjdk.java.net/jdk9/client/jdk/rev/a01b5719c00b > Review: > http://mail.openjdk.java.net/pipermail/awt-dev/2014-December/008725.html > Reviewers: Alexander Zvegintsev, Alexander Scherbatiy > From chris.hegarty at oracle.com Fri Dec 5 18:48:26 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 5 Dec 2014 18:48:26 +0000 Subject: [8u40] Request for approval for CR 8065072: sun/net/www/http/HttpClient/StreamingRetry.java failed intermittently Message-ID: Hi 8u Maintainers, I would like to request approval for 8065072 for inclusion in 8u40 ( to be pushed to 8u-dev ). This is a testcase stabilisation change. 8065072: sun/net/www/http/HttpClient/StreamingRetry.java failed intermittently https://bugs.openjdk.java.net/browse/JDK-8065072 JDK 9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/291c7b2922b3 JDK 9 Review thread: http://mail.openjdk.java.net/pipermail/net-dev/2014-November/008774.html Thanks, -Chris. From sean.coffey at oracle.com Fri Dec 5 18:56:07 2014 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Fri, 05 Dec 2014 18:56:07 +0000 Subject: [8u40] Request for approval for CR 8065072: sun/net/www/http/HttpClient/StreamingRetry.java failed intermittently In-Reply-To: References: Message-ID: <6CFF1936-7EB4-4FCD-9958-C8F8A747FC41@oracle.com> Approved. Regards, Sean. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. On 5 December 2014 18:48:26 GMT+00:00, Chris Hegarty wrote: >Hi 8u Maintainers, > >I would like to request approval for 8065072 for inclusion in 8u40 ( to >be pushed to 8u-dev ). This is a testcase stabilisation change. > >8065072: sun/net/www/http/HttpClient/StreamingRetry.java failed >intermittently > https://bugs.openjdk.java.net/browse/JDK-8065072 > >JDK 9 changeset: > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/291c7b2922b3 > >JDK 9 Review thread: >http://mail.openjdk.java.net/pipermail/net-dev/2014-November/008774.html > >Thanks, >-Chris. From daniel.fuchs at oracle.com Fri Dec 5 20:06:53 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 05 Dec 2014 21:06:53 +0100 Subject: [9 + 8u] RFR - 8066612: Add a test that will call getDeclaredFields() on all classes and try to set them accessible. In-Reply-To: <5480EFE8.3090809@oracle.com> References: <547F9302.3060309@oracle.com> <547FD6F2.5060400@oracle.com> <548023D0.4020702@oracle.com> <548047C3.8000400@oracle.com> <54804E4B.2070908@oracle.com> <5480529F.1020902@oracle.com> <54805B5D.5020504@oracle.com> <54809627.8070103@oracle.com> <5480EFE8.3090809@oracle.com> Message-ID: <5482105D.40005@oracle.com> Hi David, all, @David: You're right David. The loader parameter is never used - I have removed it. @all: I have received a comment from Alan that it would be better to use the new jrt:/ FileSystem directly, rather than using private APIs. One of the consequence is that the test now loads all the classes in the runtime image (not just the ones in the BCL), and therefore I have removed the toggle that allowed to test the boot classes only. http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.02/ best regards, -- daniel On 05/12/14 00:36, David Holmes wrote: > Hi Daniel, > > I still find your use of the classloader very confusing. You talk about > the defining loader but you never check the defining loader against > anything. In > > 146 static void checkFor(Class c, ClassLoader loader) { > > the loader variable is never used. And if loader is simply the name of > the loader passed to forName, then it may not be the defining loader > anyway - so the whole use of this loader variable seems superfluous at > best, and confusing/misleading at worst. And you can use the simple > forName(name) variant rather than passing a loader. > > David > > On 5/12/2014 3:13 AM, Daniel Fuchs wrote: >> On 04/12/14 14:02, Se?n Coffey wrote: >>> Thanks for driving efforts in this area Daniel. I think it's a very >>> useful test and is bound to help test code coverage. If it's currently >>> passing on all JPRT platforms, it's a good measure. >> >> It seems to :-) >> >>> Eventually I think we can bulk up the tests that can be run on the >>> Iterable returned from your class search. >>> At moment you just test Field.setAccessible. >> >> Yes. If we change it later to test more, we will probably need to >> change its name. I was already in lack of inspiration: >> FieldSetAccessibleTest is not really a great name - but hopefully >> it can do for now. >> >>> In the future, I don't see any harm in adding all simple Field method >>> calls so that any corner cases in custom classes like the original issue >>> are caught. e.g Field.getDeclaredAnnotations(), Field.getModifiers(), >>> Field.isEnumConstant() etc., etc. Some methods won't be much value add >>> but they're not a cost either. >> >> Agreed. >> >>> Same argument for running through all Class methods, e.g >>> Class.getDeclaredClasses(), Class.getDeclaredMethods(). As a result this >>> test might eventually become more general in test goal and might live >>> better one level up in "test/java/lang/Class/" - it can be moved when >>> the time comes. >> >> Agreed as well :-) >> >> Here is a new revision of the webrev for 9 in which I have >> incorporated David's comment: >> >> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.01/ >> >> best regards, >> >> -- daniel >> >>> >>> regards, >>> Sean. >>> >>> On 04/12/2014 12:25, Daniel Fuchs wrote: >>>> On 04/12/14 13:06, David Holmes wrote: >>>>> Hi Daniel, >>>>> >>>>> On 4/12/2014 9:38 PM, Daniel Fuchs wrote: >>>>>> Hi David, >>>>>> >>>>>> In fact I could use 'null' on JDK 9 as well. >>>>>> My first version of the JDK 9 test was parsing over all the .jimage >>>>>> files under /lib/modules - which explain why I needed to >>>>>> use the System class loader. >>>>>> >>>>>> Then I switched to only parsing the bootmodules.jimage - because >>>>>> I noticed that the results where more coherent with what I had >>>>>> observed on 8 & 7 - but I kept using the System class loader. >>>>>> >>>>>> I am not sure whether we want the test for 9 should iterate over >>>>>> the three .jimage - or continue to test only the boot .jimage. >>>>>> >>>>>> I have updated the JDK 9 test (refreshed the webrev in place) >>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.00/ >>>>>> and added support for possibly running the test in the two modes >>>>>> (I added a 'test.boot.only' system property, true by default) >>>>>> as well as additional traces to print the loaded classes by >>>>>> defining loader at the end (test.list.classes, false by default). >>>>> >>>>> A couple of initial comments: >>>>> >>>>> 104 static ClassLoader getClassLoaderFor(String classFileName) { >>>>> 105 if (restrictToBoot) return null; // only bootmodules >>>>> 106 return ClassLoaders.systemClassLoader; >>>>> 107 } >>>>> >>>>> I'm not clear the intent here. If it is to return a loader for which >>>>> loadClass could be invoked then you can always just return the system >>>>> loader - or just Class.forName. If it is meant to the return the >>>>> expected defining loader then it isn't doing that as the extensions >>>>> loader is not allowed for. >>>> >>>> The intent is to return the class loader that will be passed to >>>> Class.forName( ). I've been fiddling & experimenting with this >>>> test over 3 different platforms while trying to minimize the >>>> differences - so that was my attempt at having a good place to >>>> experiment with different strategy for loading classes. >>>> >>>>> Similarly for: >>>>> >>>>> 128 static ClassLoader getFor(String classFileName) { >>>>> 129 return systemClassLoader; >>>>> 130 } >>>> >>>> Oh - that's my mistake. In fact ClassLoader getClassLoaderFor(..) >>>> was supposed to simply return ClassLoaders.getFor(...); >>>> and all the code should be in ClassLoaders.getFor - my bad. >>>> >>>>> Minor nit - In: >>>>> >>>>> 135 System.err.println("Unexpected loader for >>>>> "+c+": >>>>> "+c.getClassLoader()); >>>>> >>>>> c.getClassLoader() can be replaced by cl. Also put spaces around the + >>>>> operator. >>>> >>>> Good catch. >>>> >>>> Thanks a lot David! Have a good night! (that's quite late - isn't it?) >>>> >>>> -- daniel >>>> >>>>> >>>>> David >>>>> (signing off for the night) >>>>> >>>>>> Thanks for your question, it triggered me into looking deeper >>>>>> into what was happening :-) >>>>>> >>>>>> best regards, >>>>>> >>>>>> -- daniel >>>>>> >>>>>> On 04/12/14 10:05, Daniel Fuchs wrote: >>>>>>>>> The differences between 8 & 9 are limited to: >>>>>>>>> >>>>>>>>> - ClassLoader: >>>>>>>>> - on 8 we use 'null' (BCL) >>>>>>>>> - on 9 we use the system class loader. >>>>>>>> >>>>>>>> I haven't seen anything in JEP 220, regarding modules, that >>>>>>>> indicates >>>>>>>> that classes currently loaded by the boot-loader will now be >>>>>>>> loaded >>>>>>>> by the system classloader ??? >>>>>>> >>>>>>> In [1] towards the end: >>>>>>> >>>>>>> [1] http://openjdk.java.net/jeps/220 >>>>>>> >>>>>>> "The defining class loader of the types in some existing packages >>>>>>> will change. Existing code that makes assumptions about the class >>>>>>> loaders of these types might not work correctly." >>>>>>> (then there is a list of specific changes). >>>>>>> >>>>>>> This test looks up all class names in the image files and attempt >>>>>>> to load the corresponding class. But as indicated in [1] >>>>>>> some of these classes are now in the Boot CL, some in the >>>>>>> Extension CL, and some in the Application CL. >>>>>>> >>>>>>> So the test uses the System CL to load each class - which ensures >>>>>>> that the loading will be delegated to the appropriate ClassLoader. >>>>>>> >>>>>>> best regards, >>>>>>> >>>>>>> -- daniel >>>>>> >>>> >>> >> From rob.mckenna at oracle.com Fri Dec 5 20:21:49 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 05 Dec 2014 20:21:49 +0000 Subject: [8u40] Request for approval: 8065238 - javax.naming.NamingException after upgrade to JDK 8 Message-ID: <548213DD.4020403@oracle.com> Hi folks, I'd like to request approval for this unaltered* backport to 8u40. Bug: https://bugs.openjdk.java.net/browse/JDK-8065238 Changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b3620b8c9b47 Review: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030062.html -Rob * aside from path shuffling From daniel.fuchs at oracle.com Fri Dec 5 20:30:46 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 05 Dec 2014 21:30:46 +0100 Subject: [8u40] approval request for 8065991: LogManager unecessarily calls JavaAWTAccess from within a critical section Message-ID: <548215F6.3020601@oracle.com> Hi, This is a request for approval to backport: 8065991: LogManager unecessarily calls JavaAWTAccess from within a critical section This is a clean hg import after unshuffle. bug: https://bugs.openjdk.java.net/browse/JDK-8065991 jdk9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/83f20d8bc13a review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030019.html best regards, -- daniel From jeff.dinkins at oracle.com Fri Dec 5 20:35:52 2014 From: jeff.dinkins at oracle.com (Jeff Dinkins) Date: Fri, 5 Dec 2014 14:35:52 -0600 Subject: [8u40] Request for approval: 8065238 - javax.naming.NamingException after upgrade to JDK 8 In-Reply-To: <548213DD.4020403@oracle.com> References: <548213DD.4020403@oracle.com> Message-ID: <4431DAFC-0F3A-441B-B3CC-73939006BCB6@oracle.com> Hi Rob - Looks good - approved. -jeff > On Dec 5, 2014, at 2:21 PM, Rob McKenna wrote: > > Hi folks, > > I'd like to request approval for this unaltered* backport to 8u40. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8065238 > Changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b3620b8c9b47 > Review: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030062.html > > -Rob > > * aside from path shuffling > From rob.mckenna at oracle.com Fri Dec 5 21:38:43 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 05 Dec 2014 21:38:43 +0000 Subject: [8u40] approval request for 8065991: LogManager unecessarily calls JavaAWTAccess from within a critical section In-Reply-To: <548215F6.3020601@oracle.com> References: <548215F6.3020601@oracle.com> Message-ID: <548225E3.4000805@oracle.com> Approved. -Rob On 05/12/14 20:30, Daniel Fuchs wrote: > Hi, > > This is a request for approval to backport: > > 8065991: LogManager unecessarily calls JavaAWTAccess from within > a critical section > > This is a clean hg import after unshuffle. > > bug: https://bugs.openjdk.java.net/browse/JDK-8065991 > jdk9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/83f20d8bc13a > review thread: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030019.html > > best regards, > > -- daniel From alejandro.murillo at oracle.com Fri Dec 5 22:05:16 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Fri, 05 Dec 2014 15:05:16 -0700 Subject: [8u40] Request for approval for bulk integration of hs25.40-b22 Message-ID: <54822C1C.4030709@oracle.com> Requesting approval to integrate hs25.40-b22 into jdk8u40-b18. A webrev is available at: http://cr.openjdk.java.net/~amurillo/8u40/hs25.40-b22-jdk8u40-b18.webrev/ Pre-integration testing is in progress; the integration will proceed only after SQE has analyzed the results and approved. The fixes in the proposed integration are below. All have undergone nightly testing and are already in a jdk9 repository. 8007993: hotspot.log w/ enabled LogCompilation can be an invalid XML 8035893: JVM_GetVersionInfo fails to zero structure 8042235: redefining method used by multiple MethodHandles crashes VM 8054478: C2: Incorrectly compiled char[] array access crashes JVM 8058448: Disable JPRT submissions from the hotspot repo 8062742: compiler/EliminateAutoBox/UnsignedLoads.java fails with client vm 8065618: C2 RA incorrectly removes kill projections 8065765: Missing space in output message from -XX:+CheckEndorsedAndExtDirs 8066045: opto/node.hpp:355, assert(i < _max) failed: oob: i=1, _max=1 8066061: new hotspot build - hs25.40-b22 8066199: C2 escape analysis prevents VM from exiting quickly 8066649: 8u backport for 8065618 is incorrect -- Alejandro From rob.mckenna at oracle.com Fri Dec 5 23:53:20 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 05 Dec 2014 23:53:20 +0000 Subject: [8u40] Request for approval for bulk integration of hs25.40-b22 In-Reply-To: <54822C1C.4030709@oracle.com> References: <54822C1C.4030709@oracle.com> Message-ID: <54824570.9080208@oracle.com> Approved. -Rob On 05/12/14 22:05, Alejandro E Murillo wrote: > Requesting approval to integrate hs25.40-b22 into jdk8u40-b18. > > A webrev is available at: > > http://cr.openjdk.java.net/~amurillo/8u40/hs25.40-b22-jdk8u40-b18.webrev/ > > Pre-integration testing is in progress; the integration will proceed > only after SQE has analyzed the results and approved. > > The fixes in the proposed integration are below. All have undergone > nightly testing and are already in a jdk9 repository. > > 8007993: hotspot.log w/ enabled LogCompilation can be an invalid XML > 8035893: JVM_GetVersionInfo fails to zero structure > 8042235: redefining method used by multiple MethodHandles crashes VM > 8054478: C2: Incorrectly compiled char[] array access crashes JVM > 8058448: Disable JPRT submissions from the hotspot repo > 8062742: compiler/EliminateAutoBox/UnsignedLoads.java fails with > client vm > 8065618: C2 RA incorrectly removes kill projections > 8065765: Missing space in output message from > -XX:+CheckEndorsedAndExtDirs > 8066045: opto/node.hpp:355, assert(i < _max) failed: oob: i=1, _max=1 > 8066061: new hotspot build - hs25.40-b22 > 8066199: C2 escape analysis prevents VM from exiting quickly > 8066649: 8u backport for 8065618 is incorrect > From peter.levart at gmail.com Sat Dec 6 10:16:28 2014 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 06 Dec 2014 11:16:28 +0100 Subject: [9 + 8u] RFR - 8066612: Add a test that will call getDeclaredFields() on all classes and try to set them accessible. In-Reply-To: <5482105D.40005@oracle.com> References: <547F9302.3060309@oracle.com> <547FD6F2.5060400@oracle.com> <548023D0.4020702@oracle.com> <548047C3.8000400@oracle.com> <54804E4B.2070908@oracle.com> <5480529F.1020902@oracle.com> <54805B5D.5020504@oracle.com> <54809627.8070103@oracle.com> <5480EFE8.3090809@oracle.com> <5482105D.40005@oracle.com> Message-ID: <5482D77C.9030100@gmail.com> On 12/05/2014 09:06 PM, Daniel Fuchs wrote: > Hi David, all, > > @David: You're right David. > The loader parameter is never used - I have removed it. > > @all: I have received a comment from Alan that it would be better to use > the new jrt:/ FileSystem directly, rather than using private APIs. > One of the consequence is that the test now loads all the > classes in the runtime image (not just the ones in the BCL), > and therefore I have removed the toggle that allowed to test > the boot classes only. > > http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.02/ > > best regards, > > -- daniel Hi Daniel, Would it be possible to extract a minimal API for streaming over classes and put that into the testlib so that only this part differs between JDK8 and JDK9 and the guts of the test is identical for both JDK8 and JDK9 ? This would ease backport efforts when the test(s) are later "beefed up" with other functionality. The API could later be extended with other functionality, but just for illustration what might be needed, here's what Martin Buchholz started as a test for finding possible data races in reflection and I just re-packed using Streams. From first glance it seems the tests need similar common functionality: http://cr.openjdk.java.net/~plevart/misc/SunReflectDataRaces/ Regards, Peter > > On 05/12/14 00:36, David Holmes wrote: >> Hi Daniel, >> >> I still find your use of the classloader very confusing. You talk about >> the defining loader but you never check the defining loader against >> anything. In >> >> 146 static void checkFor(Class c, ClassLoader loader) { >> >> the loader variable is never used. And if loader is simply the name of >> the loader passed to forName, then it may not be the defining loader >> anyway - so the whole use of this loader variable seems superfluous at >> best, and confusing/misleading at worst. And you can use the simple >> forName(name) variant rather than passing a loader. >> >> David >> >> On 5/12/2014 3:13 AM, Daniel Fuchs wrote: >>> On 04/12/14 14:02, Se?n Coffey wrote: >>>> Thanks for driving efforts in this area Daniel. I think it's a very >>>> useful test and is bound to help test code coverage. If it's currently >>>> passing on all JPRT platforms, it's a good measure. >>> >>> It seems to :-) >>> >>>> Eventually I think we can bulk up the tests that can be run on the >>>> Iterable returned from your class search. >>>> At moment you just test Field.setAccessible. >>> >>> Yes. If we change it later to test more, we will probably need to >>> change its name. I was already in lack of inspiration: >>> FieldSetAccessibleTest is not really a great name - but hopefully >>> it can do for now. >>> >>>> In the future, I don't see any harm in adding all simple Field method >>>> calls so that any corner cases in custom classes like the original >>>> issue >>>> are caught. e.g Field.getDeclaredAnnotations(), Field.getModifiers(), >>>> Field.isEnumConstant() etc., etc. Some methods won't be much value add >>>> but they're not a cost either. >>> >>> Agreed. >>> >>>> Same argument for running through all Class methods, e.g >>>> Class.getDeclaredClasses(), Class.getDeclaredMethods(). As a result >>>> this >>>> test might eventually become more general in test goal and might live >>>> better one level up in "test/java/lang/Class/" - it can be moved when >>>> the time comes. >>> >>> Agreed as well :-) >>> >>> Here is a new revision of the webrev for 9 in which I have >>> incorporated David's comment: >>> >>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.01/ >>> >>> best regards, >>> >>> -- daniel >>> >>>> >>>> regards, >>>> Sean. >>>> >>>> On 04/12/2014 12:25, Daniel Fuchs wrote: >>>>> On 04/12/14 13:06, David Holmes wrote: >>>>>> Hi Daniel, >>>>>> >>>>>> On 4/12/2014 9:38 PM, Daniel Fuchs wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> In fact I could use 'null' on JDK 9 as well. >>>>>>> My first version of the JDK 9 test was parsing over all the .jimage >>>>>>> files under /lib/modules - which explain why I needed to >>>>>>> use the System class loader. >>>>>>> >>>>>>> Then I switched to only parsing the bootmodules.jimage - because >>>>>>> I noticed that the results where more coherent with what I had >>>>>>> observed on 8 & 7 - but I kept using the System class loader. >>>>>>> >>>>>>> I am not sure whether we want the test for 9 should iterate over >>>>>>> the three .jimage - or continue to test only the boot .jimage. >>>>>>> >>>>>>> I have updated the JDK 9 test (refreshed the webrev in place) >>>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.00/ >>>>>>> and added support for possibly running the test in the two modes >>>>>>> (I added a 'test.boot.only' system property, true by default) >>>>>>> as well as additional traces to print the loaded classes by >>>>>>> defining loader at the end (test.list.classes, false by default). >>>>>> >>>>>> A couple of initial comments: >>>>>> >>>>>> 104 static ClassLoader getClassLoaderFor(String >>>>>> classFileName) { >>>>>> 105 if (restrictToBoot) return null; // only bootmodules >>>>>> 106 return ClassLoaders.systemClassLoader; >>>>>> 107 } >>>>>> >>>>>> I'm not clear the intent here. If it is to return a loader for which >>>>>> loadClass could be invoked then you can always just return the >>>>>> system >>>>>> loader - or just Class.forName. If it is meant to the return the >>>>>> expected defining loader then it isn't doing that as the extensions >>>>>> loader is not allowed for. >>>>> >>>>> The intent is to return the class loader that will be passed to >>>>> Class.forName( ). I've been fiddling & experimenting with this >>>>> test over 3 different platforms while trying to minimize the >>>>> differences - so that was my attempt at having a good place to >>>>> experiment with different strategy for loading classes. >>>>> >>>>>> Similarly for: >>>>>> >>>>>> 128 static ClassLoader getFor(String classFileName) { >>>>>> 129 return systemClassLoader; >>>>>> 130 } >>>>> >>>>> Oh - that's my mistake. In fact ClassLoader getClassLoaderFor(..) >>>>> was supposed to simply return ClassLoaders.getFor(...); >>>>> and all the code should be in ClassLoaders.getFor - my bad. >>>>> >>>>>> Minor nit - In: >>>>>> >>>>>> 135 System.err.println("Unexpected loader for >>>>>> "+c+": >>>>>> "+c.getClassLoader()); >>>>>> >>>>>> c.getClassLoader() can be replaced by cl. Also put spaces around >>>>>> the + >>>>>> operator. >>>>> >>>>> Good catch. >>>>> >>>>> Thanks a lot David! Have a good night! (that's quite late - isn't >>>>> it?) >>>>> >>>>> -- daniel >>>>> >>>>>> >>>>>> David >>>>>> (signing off for the night) >>>>>> >>>>>>> Thanks for your question, it triggered me into looking deeper >>>>>>> into what was happening :-) >>>>>>> >>>>>>> best regards, >>>>>>> >>>>>>> -- daniel >>>>>>> >>>>>>> On 04/12/14 10:05, Daniel Fuchs wrote: >>>>>>>>>> The differences between 8 & 9 are limited to: >>>>>>>>>> >>>>>>>>>> - ClassLoader: >>>>>>>>>> - on 8 we use 'null' (BCL) >>>>>>>>>> - on 9 we use the system class loader. >>>>>>>>> >>>>>>>>> I haven't seen anything in JEP 220, regarding modules, that >>>>>>>>> indicates >>>>>>>>> that classes currently loaded by the boot-loader will now be >>>>>>>>> loaded >>>>>>>>> by the system classloader ??? >>>>>>>> >>>>>>>> In [1] towards the end: >>>>>>>> >>>>>>>> [1] http://openjdk.java.net/jeps/220 >>>>>>>> >>>>>>>> "The defining class loader of the types in some existing packages >>>>>>>> will change. Existing code that makes assumptions about the >>>>>>>> class >>>>>>>> loaders of these types might not work correctly." >>>>>>>> (then there is a list of specific changes). >>>>>>>> >>>>>>>> This test looks up all class names in the image files and attempt >>>>>>>> to load the corresponding class. But as indicated in [1] >>>>>>>> some of these classes are now in the Boot CL, some in the >>>>>>>> Extension CL, and some in the Application CL. >>>>>>>> >>>>>>>> So the test uses the System CL to load each class - which ensures >>>>>>>> that the loading will be delegated to the appropriate ClassLoader. >>>>>>>> >>>>>>>> best regards, >>>>>>>> >>>>>>>> -- daniel >>>>>>> >>>>> >>>> >>> > From daniel.fuchs at oracle.com Sat Dec 6 10:44:47 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Sat, 06 Dec 2014 11:44:47 +0100 Subject: [9 + 8u] RFR - 8066612: Add a test that will call getDeclaredFields() on all classes and try to set them accessible. In-Reply-To: <5482D77C.9030100@gmail.com> References: <547F9302.3060309@oracle.com> <547FD6F2.5060400@oracle.com> <548023D0.4020702@oracle.com> <548047C3.8000400@oracle.com> <54804E4B.2070908@oracle.com> <5480529F.1020902@oracle.com> <54805B5D.5020504@oracle.com> <54809627.8070103@oracle.com> <5480EFE8.3090809@oracle.com> <5482105D.40005@oracle.com> <5482D77C.9030100@gmail.com> Message-ID: <5482DE1F.5070906@oracle.com> Hi Peter, On 12/6/14 11:16 AM, Peter Levart wrote: > > On 12/05/2014 09:06 PM, Daniel Fuchs wrote: >> Hi David, all, >> >> @David: You're right David. >> The loader parameter is never used - I have removed it. >> >> @all: I have received a comment from Alan that it would be better to use >> the new jrt:/ FileSystem directly, rather than using private APIs. >> One of the consequence is that the test now loads all the >> classes in the runtime image (not just the ones in the BCL), >> and therefore I have removed the toggle that allowed to test >> the boot classes only. >> >> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.02/ >> >> best regards, >> >> -- daniel > > Hi Daniel, > > Would it be possible to extract a minimal API for streaming over > classes and put that into the testlib so that only this part differs > between JDK8 and JDK9 and the guts of the test is identical for both > JDK8 and JDK9 ? > > This would ease backport efforts when the test(s) are later "beefed > up" with other functionality. The API could later be extended with > other functionality, but just for illustration what might be needed, > here's what Martin Buchholz started as a test for finding possible > data races in reflection and I just re-packed using Streams. From > first glance it seems the tests need similar common functionality: > > http://cr.openjdk.java.net/~plevart/misc/SunReflectDataRaces/ > > Regards, Peter The test is already built like that: The part that finds the class names is encapsulated in an object which implements Iterable. http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.02/ -> ClassNameJrtStreamBuilder http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk8-00/ -> ClassNameStreamBuilder http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk7.00/ -> ClassNameListBuilder The bulk of the test should be identical (well, almost identical since I only updated 9 after the reviews, and since 9 is the only one that needs the System ClassLoader)... I suppose we could extract these 3 classes and define a library class with something like: public static class ClassNameFinder { public static Iterable findAllClassNames() { jdk9 impl: return new ClassNameJrtStreamBuilder(); jdk8 impl: return new ClassNameStreamBuilder(); jdk7 impl: return new ClassNameListBuilder(); } } As it stands - this corresponds to the static Iterable listAllClassNames() factory method in each version of the test. best regards, -- daniel > >> >> On 05/12/14 00:36, David Holmes wrote: >>> Hi Daniel, >>> >>> I still find your use of the classloader very confusing. You talk about >>> the defining loader but you never check the defining loader against >>> anything. In >>> >>> 146 static void checkFor(Class c, ClassLoader loader) { >>> >>> the loader variable is never used. And if loader is simply the name of >>> the loader passed to forName, then it may not be the defining loader >>> anyway - so the whole use of this loader variable seems superfluous at >>> best, and confusing/misleading at worst. And you can use the simple >>> forName(name) variant rather than passing a loader. >>> >>> David >>> >>> On 5/12/2014 3:13 AM, Daniel Fuchs wrote: >>>> On 04/12/14 14:02, Se?n Coffey wrote: >>>>> Thanks for driving efforts in this area Daniel. I think it's a very >>>>> useful test and is bound to help test code coverage. If it's >>>>> currently >>>>> passing on all JPRT platforms, it's a good measure. >>>> >>>> It seems to :-) >>>> >>>>> Eventually I think we can bulk up the tests that can be run on the >>>>> Iterable returned from your class search. >>>>> At moment you just test Field.setAccessible. >>>> >>>> Yes. If we change it later to test more, we will probably need to >>>> change its name. I was already in lack of inspiration: >>>> FieldSetAccessibleTest is not really a great name - but hopefully >>>> it can do for now. >>>> >>>>> In the future, I don't see any harm in adding all simple Field method >>>>> calls so that any corner cases in custom classes like the original >>>>> issue >>>>> are caught. e.g Field.getDeclaredAnnotations(), Field.getModifiers(), >>>>> Field.isEnumConstant() etc., etc. Some methods won't be much value >>>>> add >>>>> but they're not a cost either. >>>> >>>> Agreed. >>>> >>>>> Same argument for running through all Class methods, e.g >>>>> Class.getDeclaredClasses(), Class.getDeclaredMethods(). As a >>>>> result this >>>>> test might eventually become more general in test goal and might live >>>>> better one level up in "test/java/lang/Class/" - it can be moved when >>>>> the time comes. >>>> >>>> Agreed as well :-) >>>> >>>> Here is a new revision of the webrev for 9 in which I have >>>> incorporated David's comment: >>>> >>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.01/ >>>> >>>> best regards, >>>> >>>> -- daniel >>>> >>>>> >>>>> regards, >>>>> Sean. >>>>> >>>>> On 04/12/2014 12:25, Daniel Fuchs wrote: >>>>>> On 04/12/14 13:06, David Holmes wrote: >>>>>>> Hi Daniel, >>>>>>> >>>>>>> On 4/12/2014 9:38 PM, Daniel Fuchs wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> In fact I could use 'null' on JDK 9 as well. >>>>>>>> My first version of the JDK 9 test was parsing over all the >>>>>>>> .jimage >>>>>>>> files under /lib/modules - which explain why I needed to >>>>>>>> use the System class loader. >>>>>>>> >>>>>>>> Then I switched to only parsing the bootmodules.jimage - because >>>>>>>> I noticed that the results where more coherent with what I had >>>>>>>> observed on 8 & 7 - but I kept using the System class loader. >>>>>>>> >>>>>>>> I am not sure whether we want the test for 9 should iterate over >>>>>>>> the three .jimage - or continue to test only the boot .jimage. >>>>>>>> >>>>>>>> I have updated the JDK 9 test (refreshed the webrev in place) >>>>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.00/ >>>>>>>> and added support for possibly running the test in the two modes >>>>>>>> (I added a 'test.boot.only' system property, true by default) >>>>>>>> as well as additional traces to print the loaded classes by >>>>>>>> defining loader at the end (test.list.classes, false by default). >>>>>>> >>>>>>> A couple of initial comments: >>>>>>> >>>>>>> 104 static ClassLoader getClassLoaderFor(String >>>>>>> classFileName) { >>>>>>> 105 if (restrictToBoot) return null; // only bootmodules >>>>>>> 106 return ClassLoaders.systemClassLoader; >>>>>>> 107 } >>>>>>> >>>>>>> I'm not clear the intent here. If it is to return a loader for >>>>>>> which >>>>>>> loadClass could be invoked then you can always just return the >>>>>>> system >>>>>>> loader - or just Class.forName. If it is meant to the return the >>>>>>> expected defining loader then it isn't doing that as the extensions >>>>>>> loader is not allowed for. >>>>>> >>>>>> The intent is to return the class loader that will be passed to >>>>>> Class.forName( ). I've been fiddling & experimenting with this >>>>>> test over 3 different platforms while trying to minimize the >>>>>> differences - so that was my attempt at having a good place to >>>>>> experiment with different strategy for loading classes. >>>>>> >>>>>>> Similarly for: >>>>>>> >>>>>>> 128 static ClassLoader getFor(String classFileName) { >>>>>>> 129 return systemClassLoader; >>>>>>> 130 } >>>>>> >>>>>> Oh - that's my mistake. In fact ClassLoader getClassLoaderFor(..) >>>>>> was supposed to simply return ClassLoaders.getFor(...); >>>>>> and all the code should be in ClassLoaders.getFor - my bad. >>>>>> >>>>>>> Minor nit - In: >>>>>>> >>>>>>> 135 System.err.println("Unexpected loader for >>>>>>> "+c+": >>>>>>> "+c.getClassLoader()); >>>>>>> >>>>>>> c.getClassLoader() can be replaced by cl. Also put spaces around >>>>>>> the + >>>>>>> operator. >>>>>> >>>>>> Good catch. >>>>>> >>>>>> Thanks a lot David! Have a good night! (that's quite late - isn't >>>>>> it?) >>>>>> >>>>>> -- daniel >>>>>> >>>>>>> >>>>>>> David >>>>>>> (signing off for the night) >>>>>>> >>>>>>>> Thanks for your question, it triggered me into looking deeper >>>>>>>> into what was happening :-) >>>>>>>> >>>>>>>> best regards, >>>>>>>> >>>>>>>> -- daniel >>>>>>>> >>>>>>>> On 04/12/14 10:05, Daniel Fuchs wrote: >>>>>>>>>>> The differences between 8 & 9 are limited to: >>>>>>>>>>> >>>>>>>>>>> - ClassLoader: >>>>>>>>>>> - on 8 we use 'null' (BCL) >>>>>>>>>>> - on 9 we use the system class loader. >>>>>>>>>> >>>>>>>>>> I haven't seen anything in JEP 220, regarding modules, that >>>>>>>>>> indicates >>>>>>>>>> that classes currently loaded by the boot-loader will now be >>>>>>>>>> loaded >>>>>>>>>> by the system classloader ??? >>>>>>>>> >>>>>>>>> In [1] towards the end: >>>>>>>>> >>>>>>>>> [1] http://openjdk.java.net/jeps/220 >>>>>>>>> >>>>>>>>> "The defining class loader of the types in some existing packages >>>>>>>>> will change. Existing code that makes assumptions about the >>>>>>>>> class >>>>>>>>> loaders of these types might not work correctly." >>>>>>>>> (then there is a list of specific changes). >>>>>>>>> >>>>>>>>> This test looks up all class names in the image files and attempt >>>>>>>>> to load the corresponding class. But as indicated in [1] >>>>>>>>> some of these classes are now in the Boot CL, some in the >>>>>>>>> Extension CL, and some in the Application CL. >>>>>>>>> >>>>>>>>> So the test uses the System CL to load each class - which ensures >>>>>>>>> that the loading will be delegated to the appropriate >>>>>>>>> ClassLoader. >>>>>>>>> >>>>>>>>> best regards, >>>>>>>>> >>>>>>>>> -- daniel >>>>>>>> >>>>>> >>>>> >>>> >> > From david.holmes at oracle.com Mon Dec 8 06:56:40 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 08 Dec 2014 16:56:40 +1000 Subject: [9 + 8u] RFR - 8066612: Add a test that will call getDeclaredFields() on all classes and try to set them accessible. In-Reply-To: <5482105D.40005@oracle.com> References: <547F9302.3060309@oracle.com> <547FD6F2.5060400@oracle.com> <548023D0.4020702@oracle.com> <548047C3.8000400@oracle.com> <54804E4B.2070908@oracle.com> <5480529F.1020902@oracle.com> <54805B5D.5020504@oracle.com> <54809627.8070103@oracle.com> <5480EFE8.3090809@oracle.com> <5482105D.40005@oracle.com> Message-ID: <54854BA8.60700@oracle.com> Hi Daniel, On 6/12/2014 6:06 AM, Daniel Fuchs wrote: > Hi David, all, > > @David: You're right David. > The loader parameter is never used - I have removed it. But you still have extraneous loader related stuff that doesn't actually achieve anything. getClassLoaderFor(s) is not needed. Class.forName can be called simply as Class.forName(s). And why the indirection around the ClassLoaders methods ?? David > @all: I have received a comment from Alan that it would be better to use > the new jrt:/ FileSystem directly, rather than using private APIs. > One of the consequence is that the test now loads all the > classes in the runtime image (not just the ones in the BCL), > and therefore I have removed the toggle that allowed to test > the boot classes only. > > http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.02/ > > best regards, > > -- daniel > > On 05/12/14 00:36, David Holmes wrote: >> Hi Daniel, >> >> I still find your use of the classloader very confusing. You talk about >> the defining loader but you never check the defining loader against >> anything. In >> >> 146 static void checkFor(Class c, ClassLoader loader) { >> >> the loader variable is never used. And if loader is simply the name of >> the loader passed to forName, then it may not be the defining loader >> anyway - so the whole use of this loader variable seems superfluous at >> best, and confusing/misleading at worst. And you can use the simple >> forName(name) variant rather than passing a loader. >> >> David >> >> On 5/12/2014 3:13 AM, Daniel Fuchs wrote: >>> On 04/12/14 14:02, Se?n Coffey wrote: >>>> Thanks for driving efforts in this area Daniel. I think it's a very >>>> useful test and is bound to help test code coverage. If it's currently >>>> passing on all JPRT platforms, it's a good measure. >>> >>> It seems to :-) >>> >>>> Eventually I think we can bulk up the tests that can be run on the >>>> Iterable returned from your class search. >>>> At moment you just test Field.setAccessible. >>> >>> Yes. If we change it later to test more, we will probably need to >>> change its name. I was already in lack of inspiration: >>> FieldSetAccessibleTest is not really a great name - but hopefully >>> it can do for now. >>> >>>> In the future, I don't see any harm in adding all simple Field method >>>> calls so that any corner cases in custom classes like the original >>>> issue >>>> are caught. e.g Field.getDeclaredAnnotations(), Field.getModifiers(), >>>> Field.isEnumConstant() etc., etc. Some methods won't be much value add >>>> but they're not a cost either. >>> >>> Agreed. >>> >>>> Same argument for running through all Class methods, e.g >>>> Class.getDeclaredClasses(), Class.getDeclaredMethods(). As a result >>>> this >>>> test might eventually become more general in test goal and might live >>>> better one level up in "test/java/lang/Class/" - it can be moved when >>>> the time comes. >>> >>> Agreed as well :-) >>> >>> Here is a new revision of the webrev for 9 in which I have >>> incorporated David's comment: >>> >>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.01/ >>> >>> best regards, >>> >>> -- daniel >>> >>>> >>>> regards, >>>> Sean. >>>> >>>> On 04/12/2014 12:25, Daniel Fuchs wrote: >>>>> On 04/12/14 13:06, David Holmes wrote: >>>>>> Hi Daniel, >>>>>> >>>>>> On 4/12/2014 9:38 PM, Daniel Fuchs wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> In fact I could use 'null' on JDK 9 as well. >>>>>>> My first version of the JDK 9 test was parsing over all the .jimage >>>>>>> files under /lib/modules - which explain why I needed to >>>>>>> use the System class loader. >>>>>>> >>>>>>> Then I switched to only parsing the bootmodules.jimage - because >>>>>>> I noticed that the results where more coherent with what I had >>>>>>> observed on 8 & 7 - but I kept using the System class loader. >>>>>>> >>>>>>> I am not sure whether we want the test for 9 should iterate over >>>>>>> the three .jimage - or continue to test only the boot .jimage. >>>>>>> >>>>>>> I have updated the JDK 9 test (refreshed the webrev in place) >>>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.00/ >>>>>>> and added support for possibly running the test in the two modes >>>>>>> (I added a 'test.boot.only' system property, true by default) >>>>>>> as well as additional traces to print the loaded classes by >>>>>>> defining loader at the end (test.list.classes, false by default). >>>>>> >>>>>> A couple of initial comments: >>>>>> >>>>>> 104 static ClassLoader getClassLoaderFor(String >>>>>> classFileName) { >>>>>> 105 if (restrictToBoot) return null; // only bootmodules >>>>>> 106 return ClassLoaders.systemClassLoader; >>>>>> 107 } >>>>>> >>>>>> I'm not clear the intent here. If it is to return a loader for which >>>>>> loadClass could be invoked then you can always just return the system >>>>>> loader - or just Class.forName. If it is meant to the return the >>>>>> expected defining loader then it isn't doing that as the extensions >>>>>> loader is not allowed for. >>>>> >>>>> The intent is to return the class loader that will be passed to >>>>> Class.forName( ). I've been fiddling & experimenting with this >>>>> test over 3 different platforms while trying to minimize the >>>>> differences - so that was my attempt at having a good place to >>>>> experiment with different strategy for loading classes. >>>>> >>>>>> Similarly for: >>>>>> >>>>>> 128 static ClassLoader getFor(String classFileName) { >>>>>> 129 return systemClassLoader; >>>>>> 130 } >>>>> >>>>> Oh - that's my mistake. In fact ClassLoader getClassLoaderFor(..) >>>>> was supposed to simply return ClassLoaders.getFor(...); >>>>> and all the code should be in ClassLoaders.getFor - my bad. >>>>> >>>>>> Minor nit - In: >>>>>> >>>>>> 135 System.err.println("Unexpected loader for >>>>>> "+c+": >>>>>> "+c.getClassLoader()); >>>>>> >>>>>> c.getClassLoader() can be replaced by cl. Also put spaces around >>>>>> the + >>>>>> operator. >>>>> >>>>> Good catch. >>>>> >>>>> Thanks a lot David! Have a good night! (that's quite late - isn't it?) >>>>> >>>>> -- daniel >>>>> >>>>>> >>>>>> David >>>>>> (signing off for the night) >>>>>> >>>>>>> Thanks for your question, it triggered me into looking deeper >>>>>>> into what was happening :-) >>>>>>> >>>>>>> best regards, >>>>>>> >>>>>>> -- daniel >>>>>>> >>>>>>> On 04/12/14 10:05, Daniel Fuchs wrote: >>>>>>>>>> The differences between 8 & 9 are limited to: >>>>>>>>>> >>>>>>>>>> - ClassLoader: >>>>>>>>>> - on 8 we use 'null' (BCL) >>>>>>>>>> - on 9 we use the system class loader. >>>>>>>>> >>>>>>>>> I haven't seen anything in JEP 220, regarding modules, that >>>>>>>>> indicates >>>>>>>>> that classes currently loaded by the boot-loader will now be >>>>>>>>> loaded >>>>>>>>> by the system classloader ??? >>>>>>>> >>>>>>>> In [1] towards the end: >>>>>>>> >>>>>>>> [1] http://openjdk.java.net/jeps/220 >>>>>>>> >>>>>>>> "The defining class loader of the types in some existing packages >>>>>>>> will change. Existing code that makes assumptions about the class >>>>>>>> loaders of these types might not work correctly." >>>>>>>> (then there is a list of specific changes). >>>>>>>> >>>>>>>> This test looks up all class names in the image files and attempt >>>>>>>> to load the corresponding class. But as indicated in [1] >>>>>>>> some of these classes are now in the Boot CL, some in the >>>>>>>> Extension CL, and some in the Application CL. >>>>>>>> >>>>>>>> So the test uses the System CL to load each class - which ensures >>>>>>>> that the loading will be delegated to the appropriate ClassLoader. >>>>>>>> >>>>>>>> best regards, >>>>>>>> >>>>>>>> -- daniel >>>>>>> >>>>> >>>> >>> > From attila.szegedi at oracle.com Mon Dec 8 14:24:00 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 8 Dec 2014 15:24:00 +0100 Subject: [8u40] Request for Approval: 8066230: Undefined object type assertion when computing TypeBounds Message-ID: Please approve. Bug: https://bugs.openjdk.java.net/browse/JDK-8066230 jdk9 webrev: http://cr.openjdk.java.net/~attila/8066230/webrev.00 jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-December/003979.html Changes apply cleanly to jdk8u-dev after path reshuffling from modular source code layout. Thanks, Attila. From attila.szegedi at oracle.com Mon Dec 8 14:24:16 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 8 Dec 2014 15:24:16 +0100 Subject: [8u40] Request for Approval: 8066227: CodeGenerator load unitialized slot Message-ID: <46F5CAA6-39C7-4983-9D25-C61FB57F0902@oracle.com> Please approve. Bug: https://bugs.openjdk.java.net/browse/JDK-8066227 jdk9 webrev: http://cr.openjdk.java.net/~attila/8066227/webrev.00 jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-December/003980.html Changes apply cleanly to jdk8u-dev after path reshuffling from modular source code layout. Thanks, Attila. From sergey.bylokhov at oracle.com Mon Dec 8 14:31:36 2014 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 8 Dec 2014 06:31:36 -0800 (PST) Subject: [8u-dev] Request for approval: 8059998 Broken link in java.awt.event Interface KeyListener Message-ID: <641a0745-929b-4328-80f6-969debb03aad@default> Hello, This is a direct back port from jdk 9 to jdk 8u-dev. 8059998: Broken link in java.awt.event Interface KeyListener Bug: https://bugs.openjdk.java.net/browse/JDK-8059998 Webrev can be found at: http://cr.openjdk.java.net/~serb/8059998/webrev.00 jdk9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/e75e73b6d5d7 Review: http://mail.openjdk.java.net/pipermail/awt-dev/2014-December/008738.html Reviewers: Anton V. Tarasov, Alexander Scherbatiy -- Best regards, Sergey. From sean.coffey at oracle.com Mon Dec 8 14:42:18 2014 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Mon, 08 Dec 2014 14:42:18 +0000 Subject: [8u40] Request for Approval: 8066230: Undefined object type assertion when computing TypeBounds In-Reply-To: References: Message-ID: <5485B8CA.1010105@oracle.com> Approved. regards, Sean. On 08/12/14 14:24, Attila Szegedi wrote: > Please approve. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8066230 > jdk9 webrev: http://cr.openjdk.java.net/~attila/8066230/webrev.00 > jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-December/003979.html > > Changes apply cleanly to jdk8u-dev after path reshuffling from modular source code layout. > > Thanks, > Attila. From sean.coffey at oracle.com Mon Dec 8 14:43:31 2014 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Mon, 08 Dec 2014 14:43:31 +0000 Subject: [8u40] Request for Approval: 8066227: CodeGenerator load unitialized slot In-Reply-To: <46F5CAA6-39C7-4983-9D25-C61FB57F0902@oracle.com> References: <46F5CAA6-39C7-4983-9D25-C61FB57F0902@oracle.com> Message-ID: <5485B913.9000603@oracle.com> Approved. regards, Sean. On 08/12/14 14:24, Attila Szegedi wrote: > Please approve. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8066227 > jdk9 webrev: http://cr.openjdk.java.net/~attila/8066227/webrev.00 > jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-December/003980.html > > Changes apply cleanly to jdk8u-dev after path reshuffling from modular source code layout. > > Thanks, > Attila. From sean.coffey at oracle.com Mon Dec 8 14:44:32 2014 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Mon, 08 Dec 2014 14:44:32 +0000 Subject: [8u-dev] Request for approval: 8059998 Broken link in java.awt.event Interface KeyListener In-Reply-To: <641a0745-929b-4328-80f6-969debb03aad@default> References: <641a0745-929b-4328-80f6-969debb03aad@default> Message-ID: <5485B950.8050205@oracle.com> Approved. regards, Sean. On 08/12/14 14:31, Sergey Bylokhov wrote: > Hello, > This is a direct back port from jdk 9 to jdk 8u-dev. > > 8059998: Broken link in java.awt.event Interface KeyListener > Bug: https://bugs.openjdk.java.net/browse/JDK-8059998 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8059998/webrev.00 > jdk9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/e75e73b6d5d7 > Review: http://mail.openjdk.java.net/pipermail/awt-dev/2014-December/008738.html > Reviewers: Anton V. Tarasov, Alexander Scherbatiy > > -- > Best regards, Sergey. From eric.mccorkle at oracle.com Mon Dec 8 19:55:49 2014 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Mon, 08 Dec 2014 14:55:49 -0500 Subject: [8u40] Request to revert JDK-8065132 and JDK-8029012 Message-ID: <54860245.2080605@oracle.com> Hello, JDK-8065132 and JDK-8029012 both cause changes to the content of classfiles (annotations attributes are now generated with synthetic parameters represented). After discussions among the javac team, we have decided it would be better to delay this fix until there is a new classfile version (ie. in JDK9). Also, this causes problems for javac when reading in classfiles (see JDK-8066725). Moreover, the information contained in the current classfile format is insufficient to implement a 100% effective fix (see JDK-8062582), therefore we would like to back these fixes out for 8u40. Thanks, Eric From alexey.ivanov at oracle.com Tue Dec 9 10:53:31 2014 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Tue, 09 Dec 2014 13:53:31 +0300 Subject: [8u40] Request for approval for 8066756: Test test/sun/awt/dnd/8024061/bug8024061.java fails Message-ID: <5486D4AB.3000902@oracle.com> Hello, Could you please approve the following backport of the fix to 8u40? JBS bug: https://bugs.openjdk.java.net/browse/JDK-8066756 Webrev: http://cr.openjdk.java.net/~aivanov/8066756/jdk9/webrev.00/ Review: http://mail.openjdk.java.net/pipermail/awt-dev/2014-December/008742.html JDK9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/d7f7f205f986 Thank you in advance, Alexey From sean.coffey at oracle.com Tue Dec 9 12:20:27 2014 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Tue, 09 Dec 2014 12:20:27 +0000 Subject: [8u40] Request for approval for 8066756: Test test/sun/awt/dnd/8024061/bug8024061.java fails In-Reply-To: <5486D4AB.3000902@oracle.com> References: <5486D4AB.3000902@oracle.com> Message-ID: <5486E90B.8040904@oracle.com> Approved. regards, Sean. On 09/12/2014 10:53, Alexey Ivanov wrote: > Hello, > > Could you please approve the following backport of the fix to 8u40? > > JBS bug: https://bugs.openjdk.java.net/browse/JDK-8066756 > Webrev: http://cr.openjdk.java.net/~aivanov/8066756/jdk9/webrev.00/ > Review: > http://mail.openjdk.java.net/pipermail/awt-dev/2014-December/008742.html > > JDK9 changeset: > http://hg.openjdk.java.net/jdk9/client/jdk/rev/d7f7f205f986 > > > Thank you in advance, > Alexey From sean.coffey at oracle.com Tue Dec 9 12:25:34 2014 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Tue, 09 Dec 2014 12:25:34 +0000 Subject: [8u40] Request to revert JDK-8065132 and JDK-8029012 In-Reply-To: <54860245.2080605@oracle.com> References: <54860245.2080605@oracle.com> Message-ID: <5486EA3E.3040601@oracle.com> Eric, is this an informational email or a request ? No review or approval request seen in subject line. Where's the new bugID ? You need an ID to back out a change. Can you also discuss your plans on the compiler dev OpenJDK mailing list and come back to jdk8u-dev once you have obtained review for your changes. You'll have to follow Phase 2 approval also given that we're just about to enter RDP2 for 8u40. http://openjdk.java.net/projects/jdk8u/phase2/phase2-process.html With process, any change normally needs to be in JDK 9 first before porting to 8u-dev (where applicable) regards, Sean. On 08/12/2014 19:55, Eric McCorkle wrote: > Hello, > > JDK-8065132 and JDK-8029012 both cause changes to the content of > classfiles (annotations attributes are now generated with synthetic > parameters represented). After discussions among the javac team, we > have decided it would be better to delay this fix until there is a new > classfile version (ie. in JDK9). > > Also, this causes problems for javac when reading in classfiles (see > JDK-8066725). Moreover, the information contained in the current > classfile format is insufficient to implement a 100% effective fix (see > JDK-8062582), therefore we would like to back these fixes out for 8u40. > > Thanks, > Eric From sean.coffey at oracle.com Tue Dec 9 15:27:38 2014 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Tue, 09 Dec 2014 15:27:38 +0000 Subject: [8u communication] Plans for creation of 8u40 stabilization forests Message-ID: <548714EA.10208@oracle.com> Following on from my last mail regarding the 8u40 release timeline [1], the current plan is to create the 8u40 stabilization forests once 8u40 b19 is promoted. That's due for build promotion on December 17th. As always, this date is tentative and subject to change. Once the jdk8u40-b19 tags have been added to the master forest, I'd like to propose that the following 8u40 stabilization forests be created : hg.openjdk.java.net/jdk8u/jdk8u40 based on hg.openjdk.java.net/jdk8u/jdk8u/ tag jdk8u40-b19 (master forest) hg.openjdk.java.net/jdk8u/jdk8u40-dev based on hg.openjdk.java.net/jdk8u/jdk8u/ tag jdk8u40-b19 (team forest) Getting fixes into the jdk8u40 stabilization forest will be subject to the Phase 2 stabilization process [2]. Regards, Sean. [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2014-November/002512.html [2] http://openjdk.java.net/projects/jdk8u/phase2/phase2-process.html From alexander.zvegintsev at oracle.com Tue Dec 9 15:50:43 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Tue, 09 Dec 2014 18:50:43 +0300 Subject: [8u40] Request for approval: 8066986 [headless] DataTransferer.getInstance throws ClassCastException in headless mode Message-ID: <54871A53.2000101@oracle.com> Hello, please approve the following fix for 8u40: The webrew: http://cr.openjdk.java.net/~azvegint/jdk/8u/8066986/00/ The review: http://mail.openjdk.java.net/pipermail/awt-dev/2014-December/008751.html It restores JDK-8051588 fix to its initial state (for more info please see the review thread). -- Thanks, Alexander. From rob.mckenna at oracle.com Tue Dec 9 15:53:29 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 09 Dec 2014 15:53:29 +0000 Subject: [8u40] Request for approval: 8066986 [headless] DataTransferer.getInstance throws ClassCastException in headless mode In-Reply-To: <54871A53.2000101@oracle.com> References: <54871A53.2000101@oracle.com> Message-ID: <54871AF9.1050700@oracle.com> Approved. -Rob On 09/12/14 15:50, Alexander Zvegintsev wrote: > Hello, > > please approve the following fix for 8u40: > > The webrew: http://cr.openjdk.java.net/~azvegint/jdk/8u/8066986/00/ > The review: > http://mail.openjdk.java.net/pipermail/awt-dev/2014-December/008751.html > > It restores JDK-8051588 fix to its initial state (for more info please > see the review thread). > From marcins at microsoft.com Tue Dec 9 17:45:19 2014 From: marcins at microsoft.com (Martin Sawicki (MS OPEN TECH)) Date: Tue, 9 Dec 2014 17:45:19 +0000 Subject: Backporting the TCP Loopack fast path (Windows) improvement to JDK 8 Message-ID: Hello, We'd like to propose to backport our TCP loopback fast path improvement for Windows that was recently accepted into JDK9 to JDK8: (JDK9 fix for reference: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/26e6402772c8) Our suggested JDK8 webrev package can be found here: https://openjdkcontrib.blob.core.windows.net/tcploopback/jdk8-webrev-20141105.zip We'd appreciate your review and acceptance of this contribution. Best regards, Martin Sawicki (and Kirk Shoop, and Valeriy Kopylov) Microsoft Open Technologies, Inc. From sean.coffey at oracle.com Tue Dec 9 17:54:28 2014 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Tue, 09 Dec 2014 17:54:28 +0000 Subject: Backporting the TCP Loopack fast path (Windows) improvement to JDK 8 In-Reply-To: References: Message-ID: <54873754.6030007@oracle.com> Martin, does the JDK 9 patch apply cleanly to the jdk8u code base (bar any path name changes) ? The CCC was logged for JDK 9 only - We'd need one approved for JDK 8u before a push can be made. I can help out there if necessary. Also - we can't accept patches hosted on non OpenJDK infrastructure ? Could you reply and append the jdk.patch file (as per webrev generation) to this mail ? Regards, Sean. On 09/12/2014 17:45, Martin Sawicki (MS OPEN TECH) wrote: > Hello, > > We'd like to propose to backport our TCP loopback fast path improvement for Windows that was recently accepted into JDK9 to JDK8: > (JDK9 fix for reference: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/26e6402772c8) > > Our suggested JDK8 webrev package can be found here: > https://openjdkcontrib.blob.core.windows.net/tcploopback/jdk8-webrev-20141105.zip > > We'd appreciate your review and acceptance of this contribution. > > Best regards, > Martin Sawicki (and Kirk Shoop, and Valeriy Kopylov) > Microsoft Open Technologies, Inc. > From alejandro.murillo at oracle.com Tue Dec 9 20:16:13 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 09 Dec 2014 13:16:13 -0700 Subject: jdk8u40-b18: HotSpot Message-ID: <5487588D.20909@oracle.com> hs25.40-b22 has been integrated into jdk8u40-b18. http://hg.openjdk.java.net/jdk8u/jdk8u/rev/83d1d42c3df4 http://hg.openjdk.java.net/jdk8u/jdk8u/corba/rev/a1e2c13de84e http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/31d3306aad29 http://hg.openjdk.java.net/jdk8u/jdk8u/jaxp/rev/6103f5a8119a http://hg.openjdk.java.net/jdk8u/jdk8u/jaxws/rev/fa07311627d0 http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/20a3e2135e08 http://hg.openjdk.java.net/jdk8u/jdk8u/langtools/rev/94f30e5fde53 http://hg.openjdk.java.net/jdk8u/jdk8u/nashorn/rev/653739706172 Component : VM Status : 0 major failures, 2 minor failures Date : 09/12/2014 at 20:30 MSK Tested By : STT_VM Cost(total man-days): 1 Workspace : 2014-12-05-175241.amurillo.hs25-40-b22-snapshot Bundles : 2014-12-05-175241.amurillo.hs25-40-b22-snapshot Platforms : Others Tests : Log : link Browsers : NA Patches : NA Number of Tests Executed : 434460 passed tests, 3994 failed tests (no new failures) Bug verification status: ====================================== Tested, Pass: Tested, Pass (partial fixes): Tested, Fail: Untested bug fixes: 8007993: hotspot.log w/ enabled LogCompilation can be an invalid XML 8035893: JVM_GetVersionInfo fails to zero structure 8042235: redefining method used by multiple MethodHandles crashes VM 8054478: C2: Incorrectly compiled char[] array access crashes JVM 8058448: Disable JPRT submissions from the hotspot repo 8062742: compiler/EliminateAutoBox/UnsignedLoads.java fails with client vm 8065618: C2 RA incorrectly removes kill projections 8065765: Missing space in output message from -XX:+CheckEndorsedAndExtDirs 8066045: opto/node.hpp:355, assert(i < _max) failed: oob: i=1, _max=1 8066061: new hotspot build - hs25.40-b22 8066199: C2 escape analysis prevents VM from exiting quickly 8066649: 8u backport for 8065618 is incorrect New bugs filed: Bugs in PIT build: Bugs in earlier promoted build: JDK-8067014: LinearScan::is_sorted significantly slows down fastdebug builds' performance JDK-8067005: [TESTBUG] Several java/lang/invoke tests fail due to exhausted code cache Number of PIT requested: 1 Integration target J2SE build number: jdk8u40-b18 Issues and Notes: This is PIT for HS25.40-b22 for jdk8u40-b18. Go for integration. -- Alejandro From attila.szegedi at oracle.com Wed Dec 10 11:40:34 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 10 Dec 2014 12:40:34 +0100 Subject: [8u40] Request for Approval: 8066225: NPE in MethodEmitter with duplicate integer switch cases Message-ID: <421F679B-233E-45FE-97C4-A694E76751AF@oracle.com> Please approve. Bug: https://bugs.openjdk.java.net/browse/JDK-8066225 jdk9 webrev: http://cr.openjdk.java.net/~attila/8066225/webrev.00 jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-December/003993.html Changes apply cleanly to jdk8u-dev after path reshuffling from modular source code layout. Thanks, Attila. From attila.szegedi at oracle.com Wed Dec 10 11:40:43 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 10 Dec 2014 12:40:43 +0100 Subject: [8u40] Request for Approval: 8066224: fixes for folding a constant-test ternary operator Message-ID: Please approve. Bug: https://bugs.openjdk.java.net/browse/JDK-8066224 jdk9 webrev: http://cr.openjdk.java.net/~attila/8066224/webrev.00 jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-December/003995.html Changes apply cleanly to jdk8u-dev after path reshuffling from modular source code layout. Thanks, Attila. From attila.szegedi at oracle.com Wed Dec 10 11:40:53 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 10 Dec 2014 12:40:53 +0100 Subject: [8u40] Request for Approval: 8066236: RuntimeNode forces copy creation on visitation Message-ID: Please approve. Bug: https://bugs.openjdk.java.net/browse/JDK-8066236 jdk9 webrev: http://cr.openjdk.java.net/~attila/8066236/webrev.00 jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-December/ Changes apply cleanly to jdk8u-dev after path reshuffling from modular source code layout. Thanks, Attila. From alexandr.scherbatiy at oracle.com Wed Dec 10 11:58:36 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 10 Dec 2014 14:58:36 +0300 Subject: [8u40] Request for approval: 8065627 Animated GIFs fail to display on a HiDPI display Message-ID: <5488356C.5040806@oracle.com> Hello, Could you approve the direct backport of the fix to JDK 8u-dev. The bug: https://bugs.openjdk.java.net/browse/JDK-8065627 The webrev: http://cr.openjdk.java.net/~alexsch/8065627/webrev.00 The review thread: http://mail.openjdk.java.net/pipermail/awt-dev/2014-December/008755.html The JDK 9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/da5c804bda74 Thanks, Alexandr. From sean.coffey at oracle.com Wed Dec 10 12:17:14 2014 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Wed, 10 Dec 2014 12:17:14 +0000 Subject: [8u40] Request for Approval: 8066225: NPE in MethodEmitter with duplicate integer switch cases In-Reply-To: <421F679B-233E-45FE-97C4-A694E76751AF@oracle.com> References: <421F679B-233E-45FE-97C4-A694E76751AF@oracle.com> Message-ID: <548839CA.1090804@oracle.com> Approved. regards, Sean. On 10/12/14 11:40, Attila Szegedi wrote: > Please approve. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8066225 > jdk9 webrev: http://cr.openjdk.java.net/~attila/8066225/webrev.00 > jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-December/003993.html > > Changes apply cleanly to jdk8u-dev after path reshuffling from modular source code layout. > > Thanks, > Attila. From sean.coffey at oracle.com Wed Dec 10 12:17:38 2014 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Wed, 10 Dec 2014 12:17:38 +0000 Subject: [8u40] Request for Approval: 8066224: fixes for folding a constant-test ternary operator In-Reply-To: References: Message-ID: <548839E2.90109@oracle.com> Approved. regards, Sean. On 10/12/14 11:40, Attila Szegedi wrote: > Please approve. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8066224 > jdk9 webrev: http://cr.openjdk.java.net/~attila/8066224/webrev.00 > jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-December/003995.html > > Changes apply cleanly to jdk8u-dev after path reshuffling from modular source code layout. > > Thanks, > Attila. From sean.coffey at oracle.com Wed Dec 10 12:23:57 2014 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Wed, 10 Dec 2014 12:23:57 +0000 Subject: [8u40] Request for Approval: 8066236: RuntimeNode forces copy creation on visitation In-Reply-To: References: Message-ID: <54883B5D.4060503@oracle.com> Approved. Looks like today is the last day for getting fixes in via jdk8u-dev for 8u40. Lana is planning on taking 8u40 b19 PIT snapshot tomorrow. regards, Sean. On 10/12/14 11:40, Attila Szegedi wrote: > Please approve. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8066236 > jdk9 webrev: http://cr.openjdk.java.net/~attila/8066236/webrev.00 > jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-December/ > > Changes apply cleanly to jdk8u-dev after path reshuffling from modular source code layout. > > Thanks, > Attila. From sean.coffey at oracle.com Wed Dec 10 12:31:28 2014 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Wed, 10 Dec 2014 12:31:28 +0000 Subject: [8u40] Request for approval: 8065627 Animated GIFs fail to display on a HiDPI display In-Reply-To: <5488356C.5040806@oracle.com> References: <5488356C.5040806@oracle.com> Message-ID: <54883D20.40204@oracle.com> approved. Like my last mail, it looks like today is the last day for getting fixes in via jdk8u-dev for 8u40. Lana is planning on taking 8u40 b19 PIT snapshot tomorrow. regards, Sean. On 10/12/14 11:58, Alexander Scherbatiy wrote: > > Hello, > > Could you approve the direct backport of the fix to JDK 8u-dev. > > The bug: https://bugs.openjdk.java.net/browse/JDK-8065627 > The webrev: http://cr.openjdk.java.net/~alexsch/8065627/webrev.00 > The review thread: > http://mail.openjdk.java.net/pipermail/awt-dev/2014-December/008755.html > The JDK 9 changeset: > http://hg.openjdk.java.net/jdk9/client/jdk/rev/da5c804bda74 > > Thanks, > Alexandr. > From attila.szegedi at oracle.com Wed Dec 10 12:41:28 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 10 Dec 2014 13:41:28 +0100 Subject: [8u40] Request for Approval: 8066236: RuntimeNode forces copy creation on visitation In-Reply-To: <54883B5D.4060503@oracle.com> References: <54883B5D.4060503@oracle.com> Message-ID: <58E9CEBB-EBCD-4E30-AC64-E165483096C4@oracle.com> Thanks for the heads up, that's good to know. I saw your previous e-mail and was indeed wondering when will b19 be spun. We had a helpful grad student run Nashorn through a "fuzzer"; a system randomly generating syntactically valid programs, and seeing what bugs crawl out from the previously unlit places. They were reported on Dec 1, and I have started earnestly looking into them since last week, and am gradually getting ready with fixes; I'm glad I could have these for 8u40 still with the easier process. I have three more on my plate to triage/fix, I'll likely be done with them after b19, so I'll judge whether they should be significant enough for 8u40 inclusion, and if so, I'll seek stage 2 approval for them. Thanks, Attila. On Dec 10, 2014, at 1:23 PM, Se?n Coffey wrote: > Approved. Looks like today is the last day for getting fixes in via jdk8u-dev for 8u40. Lana is planning on taking 8u40 b19 PIT snapshot tomorrow. > > regards, > Sean. > > On 10/12/14 11:40, Attila Szegedi wrote: >> Please approve. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8066236 >> jdk9 webrev: http://cr.openjdk.java.net/~attila/8066236/webrev.00 >> jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-December/ >> >> Changes apply cleanly to jdk8u-dev after path reshuffling from modular source code layout. >> >> Thanks, >> Attila. > From sundararajan.athijegannathan at oracle.com Wed Dec 10 14:21:26 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Wed, 10 Dec 2014 19:51:26 +0530 Subject: [8u40] approval request for 8067136: BrowserJSObjectLinker does not handle call on JSObjects Message-ID: <548856E6.7070106@oracle.com> Please approve. bug: https://bugs.openjdk.java.net/browse/JDK-8067136 jdk8u-dev webrev: http://cr.openjdk.java.net/~sundar/8067136/8u40/ jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-December/004000.html Fix backported "as is" except for modular source layout changes in 8u-dev. Thanks -Sundar From rob.mckenna at oracle.com Wed Dec 10 14:44:59 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 10 Dec 2014 14:44:59 +0000 Subject: [8u40] approval request for 8067136: BrowserJSObjectLinker does not handle call on JSObjects In-Reply-To: <548856E6.7070106@oracle.com> References: <548856E6.7070106@oracle.com> Message-ID: <54885C6B.5040104@oracle.com> Approved. -Rob On 10/12/14 14:21, A. Sundararajan wrote: > Please approve. > > bug: https://bugs.openjdk.java.net/browse/JDK-8067136 > jdk8u-dev webrev: http://cr.openjdk.java.net/~sundar/8067136/8u40/ > jdk9 review thread: > http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-December/004000.html > > Fix backported "as is" except for modular source layout changes in > 8u-dev. > > Thanks > -Sundar From michael.fang at oracle.com Wed Dec 10 17:15:40 2014 From: michael.fang at oracle.com (Michael Fang) Date: Wed, 10 Dec 2014 09:15:40 -0800 Subject: [8u40] Request for approval for 8065157: jdk8u40 Japanese man page file translation update Message-ID: <54887FBC.90208@oracle.com> Hello JDK8u maintainers, Please approve bug fix 8065157 for 8u40 Bug report: https://bugs.openjdk.java.net/browse/JDK-8065157 Webrev: http://cr.openjdk.java.net/~mfang/8065157/webrev.00/ Review thread: http://mail.openjdk.java.net/pipermail/i18n-dev/2014-December/001594.html thanks, -michael From rob.mckenna at oracle.com Wed Dec 10 18:03:05 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 10 Dec 2014 18:03:05 +0000 Subject: [8u40] Request for approval for 8065157: jdk8u40 Japanese man page file translation update In-Reply-To: <54887FBC.90208@oracle.com> References: <54887FBC.90208@oracle.com> Message-ID: <54888AD9.1010602@oracle.com> Approved. -Rob On 10/12/14 17:15, Michael Fang wrote: > Hello JDK8u maintainers, > > Please approve bug fix 8065157 for 8u40 > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8065157 > Webrev: http://cr.openjdk.java.net/~mfang/8065157/webrev.00/ > Review thread: > http://mail.openjdk.java.net/pipermail/i18n-dev/2014-December/001594.html > > thanks, > > -michael From Sergey.Bylokhov at oracle.com Wed Dec 10 18:58:20 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 10 Dec 2014 21:58:20 +0300 Subject: [8u-dev] Request for approval: 8057788 [macosx] "Pinch to zoom" does not work since jdk7 Message-ID: <548897CC.3090606@oracle.com> Hello, This is a direct back port from jdk 9 to jdk8u-dev. 8057788: [macosx] "Pinch to zoom" does not work since jdk7 Bug: https://bugs.openjdk.java.net/browse/JDK-8057788 Webrev can be found at: http://cr.openjdk.java.net/~serb/denis/8057788/ jdk9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/32c9def19d36 Review: http://mail.openjdk.java.net/pipermail/awt-dev/2014-December/008757.html Reviewers: Sergey Bylokhov, Alexander Scherbatiy -- Best regards, Sergey. From rob.mckenna at oracle.com Wed Dec 10 19:05:42 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 10 Dec 2014 19:05:42 +0000 Subject: [8u-dev] Request for approval: 8057788 [macosx] "Pinch to zoom" does not work since jdk7 In-Reply-To: <548897CC.3090606@oracle.com> References: <548897CC.3090606@oracle.com> Message-ID: <54889986.6030208@oracle.com> Approved. -Rob On 10/12/14 18:58, Sergey Bylokhov wrote: > Hello, > This is a direct back port from jdk 9 to jdk8u-dev. > > 8057788: [macosx] "Pinch to zoom" does not work since jdk7 > Bug: https://bugs.openjdk.java.net/browse/JDK-8057788 > Webrev can be found at: http://cr.openjdk.java.net/~serb/denis/8057788/ > jdk9 changeset: > http://hg.openjdk.java.net/jdk9/client/jdk/rev/32c9def19d36 > Review: > http://mail.openjdk.java.net/pipermail/awt-dev/2014-December/008757.html > Reviewers: Sergey Bylokhov, Alexander Scherbatiy > From sundararajan.athijegannathan at oracle.com Thu Dec 11 03:02:58 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 11 Dec 2014 08:32:58 +0530 Subject: Review request for JDK-8066221 In-Reply-To: <2280434B-F924-4C25-94E5-CF5F73E8A420@oracle.com> References: <1687A366-3107-4CD5-9A8D-9EEE84140E23@oracle.com> <2280434B-F924-4C25-94E5-CF5F73E8A420@oracle.com> Message-ID: <54890962.3030501@oracle.com> +1 On Wednesday 10 December 2014 11:13 PM, Attila Szegedi wrote: > Thanks for the reviews folks. Unfortunately, since this change concerns the parser, I need a separate review for 8u backport at > The difference is around the invocation of the functionBody() from functionExpression(). > > Attila. > > On Dec 10, 2014, at 6:20 PM, Marcus Lagergren wrote: > >> +1 >> >>> On 10 Dec 2014, at 17:57, Attila Szegedi wrote: >>> >>> Please review JDK-8066221 at for >>> >>> Thanks, >>> Attila. From attila.szegedi at oracle.com Thu Dec 11 10:12:00 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Thu, 11 Dec 2014 11:12:00 +0100 Subject: [8u40] Request for Approval: 8066221: anonymous function statement name clashes with another symbol Message-ID: Please approve. Bug: https://bugs.openjdk.java.net/browse/JDK-8066221 jdk9 webrev: http://cr.openjdk.java.net/~attila/8066221/webrev.00 jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-December/004003.html Changes do NOT apply cleanly to jdk8u-dev after path reshuffling from modular source code layout. Further changes were needed because of the divergence of Parser.java code between 8u-dev and 9. jdk8u webrev: http://cr.openjdk.java.net/~attila/8066221/webrev.8u-dev/index.html jdk8u review thread is a follow-up on the jdk9 review thread, starting at: http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-December/004005.html Thanks, Attila. From sean.coffey at oracle.com Thu Dec 11 10:18:05 2014 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Thu, 11 Dec 2014 10:18:05 +0000 Subject: [8u40] Request for Approval: 8066221: anonymous function statement name clashes with another symbol In-Reply-To: References: Message-ID: <54896F5D.2070505@oracle.com> Approved. This should squeeze into 8u40 b19. I believe PIT snapshot occurs at 14:00 Pacific today. regards, Sean. On 11/12/2014 10:12, Attila Szegedi wrote: > Please approve. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8066221 > jdk9 webrev: http://cr.openjdk.java.net/~attila/8066221/webrev.00 > jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-December/004003.html > > Changes do NOT apply cleanly to jdk8u-dev after path reshuffling from modular source code layout. Further changes were needed because of the divergence of Parser.java code between 8u-dev and 9. > > jdk8u webrev: http://cr.openjdk.java.net/~attila/8066221/webrev.8u-dev/index.html > jdk8u review thread is a follow-up on the jdk9 review thread, starting at: http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-December/004005.html > > Thanks, > Attila. From hannes.wallnoefer at oracle.com Thu Dec 11 12:59:16 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 11 Dec 2014 13:59:16 +0100 Subject: [8u40] Request for approval: JDK-8066932: __noSuchMethod__ binds to this-object without proper guard Message-ID: <54899524.4020907@oracle.com> Please approve backport of JDK-8066932 to 8u40. Changes apply cleanly to 8u40 after shuffling path names. Bug: https://bugs.openjdk.java.net/browse/JDK-8066932 Webrev: http://cr.openjdk.java.net/~hannesw/8066932/ Review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-December/004008.html Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/5eab6cf7f697 Thanks, Hannes From sean.coffey at oracle.com Thu Dec 11 13:07:57 2014 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Thu, 11 Dec 2014 13:07:57 +0000 Subject: [8u40] Request for approval: JDK-8066932: __noSuchMethod__ binds to this-object without proper guard In-Reply-To: <54899524.4020907@oracle.com> References: <54899524.4020907@oracle.com> Message-ID: <5489972D.4090606@oracle.com> Approved. regards, Sean. On 11/12/2014 12:59, Hannes Wallnoefer wrote: > Please approve backport of JDK-8066932 to 8u40. > > Changes apply cleanly to 8u40 after shuffling path names. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8066932 > Webrev: http://cr.openjdk.java.net/~hannesw/8066932/ > Review thread: > http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-December/004008.html > Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/5eab6cf7f697 > > Thanks, > Hannes From eric.mccorkle at oracle.com Thu Dec 11 14:43:58 2014 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Thu, 11 Dec 2014 09:43:58 -0500 Subject: [8u40] Request for Approval: 8067039: Revert changes to annotation attribute generation Message-ID: <5489ADAE.9080008@oracle.com> Please approve JDK-8067039, which reverts JDK-8029012 and JDK-8065132, which cause previous versions of javac in 8 not to be able to load some classfiles generated by the current 8u javac. After discussions amongst the langtools team, it was decided that the change should be backed out in 8u, but kept in 9 in order to work towards a more complete solution to the underlying problem (see JDK-8066725 and JDK-8062582 for details) The patch was created cleanly by reverting JDK-8029012 and JDK-8065132. The patch ran cleanly through a JPRT run. Review was conducted on compiler-dev, and it was approved by Jonathan Gibbons. Webrev: http://cr.openjdk.java.net/~emc/8067039/ Bug: https://bugs.openjdk.java.net/browse/JDK-8067039 From sean.coffey at oracle.com Thu Dec 11 14:52:25 2014 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Thu, 11 Dec 2014 14:52:25 +0000 Subject: [8u40] Request for Approval: 8067039: Revert changes to annotation attribute generation In-Reply-To: <5489ADAE.9080008@oracle.com> References: <5489ADAE.9080008@oracle.com> Message-ID: <5489AFA9.6050207@oracle.com> Approved. Please add 9-na to the bug report. I've not sure what bug record policy is in such scenarios but I think the 8u40 records for JDK-8029012 and JDK-8065132 need to be reverted to something like "will not fix" ? regards, Sean. On 11/12/2014 14:43, Eric McCorkle wrote: > Please approve JDK-8067039, which reverts JDK-8029012 and JDK-8065132, > which cause previous versions of javac in 8 not to be able to load some > classfiles generated by the current 8u javac. > > After discussions amongst the langtools team, it was decided that the > change should be backed out in 8u, but kept in 9 in order to work > towards a more complete solution to the underlying problem (see > JDK-8066725 and JDK-8062582 for details) > > The patch was created cleanly by reverting JDK-8029012 and JDK-8065132. > The patch ran cleanly through a JPRT run. Review was conducted on > compiler-dev, and it was approved by Jonathan Gibbons. > > Webrev: http://cr.openjdk.java.net/~emc/8067039/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8067039 From hannes.wallnoefer at oracle.com Thu Dec 11 15:02:25 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 11 Dec 2014 16:02:25 +0100 Subject: [8u40] Request for approval: JDK-8066669: dust.js performance regression caused by primitive field conversion Message-ID: <5489B201.9040508@oracle.com> Please approve backport of JDK-8066669 to 8u40. Changes apply cleanly to 8u40 after shuffling path names except for two hunks in MethodEmitter.java. These changes are currently being reviewed and tested. Bug: https://bugs.openjdk.java.net/browse/JDK-8066669 Webrevs: http://cr.openjdk.java.net/~hannesw/8066669/ Review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-December/004011.html Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/7c1cff3cae2e Thanks, Hannes From eric.mccorkle at oracle.com Thu Dec 11 15:07:59 2014 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Thu, 11 Dec 2014 10:07:59 -0500 Subject: [8u40] Request for Approval: 8067039: Revert changes to annotation attribute generation In-Reply-To: <5489AFA9.6050207@oracle.com> References: <5489ADAE.9080008@oracle.com> <5489AFA9.6050207@oracle.com> Message-ID: <5489B34F.8090707@oracle.com> On 12/11/14 09:52, Se?n Coffey wrote: > Approved. Please add 9-na to the bug report. Done. > I've not sure what bug record policy is in such scenarios but I think the > 8u40 records for JDK-8029012 and JDK-8065132 need to be reverted to > something like "will not fix" ? "Won't fix" seems reasonable, as any fix constitutes a breaking change. > regards, > Sean. > > On 11/12/2014 14:43, Eric McCorkle wrote: >> Please approve JDK-8067039, which reverts JDK-8029012 and JDK-8065132, >> which cause previous versions of javac in 8 not to be able to load some >> classfiles generated by the current 8u javac. >> >> After discussions amongst the langtools team, it was decided that the >> change should be backed out in 8u, but kept in 9 in order to work >> towards a more complete solution to the underlying problem (see >> JDK-8066725 and JDK-8062582 for details) >> >> The patch was created cleanly by reverting JDK-8029012 and JDK-8065132. >> The patch ran cleanly through a JPRT run. Review was conducted on >> compiler-dev, and it was approved by Jonathan Gibbons. >> >> Webrev: http://cr.openjdk.java.net/~emc/8067039/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8067039 > From daniel.daugherty at oracle.com Thu Dec 11 15:24:44 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 11 Dec 2014 08:24:44 -0700 Subject: [8u40] Request for Approval: 8067039: Revert changes to annotation attribute generation In-Reply-To: <5489AFA9.6050207@oracle.com> References: <5489ADAE.9080008@oracle.com> <5489AFA9.6050207@oracle.com> Message-ID: <5489B73C.1030205@oracle.com> On 12/11/14 7:52 AM, Se?n Coffey wrote: > Approved. Please add 9-na to the bug report. > > I've not sure what bug record policy is in such scenarios but I think the > 8u40 records for JDK-8029012 and JDK-8065132 need to be reverted to > something like "will not fix" ? No, they should not. Changesets were pushed using those bug IDs and it would be confusing to change the state of the bugs. However, it would be good to add a note to those two bugs stating that the changes have been reverted/anti-delta'ed using JDK-8067039. Dan > > regards, > Sean. > > On 11/12/2014 14:43, Eric McCorkle wrote: >> Please approve JDK-8067039, which reverts JDK-8029012 and JDK-8065132, >> which cause previous versions of javac in 8 not to be able to load some >> classfiles generated by the current 8u javac. >> >> After discussions amongst the langtools team, it was decided that the >> change should be backed out in 8u, but kept in 9 in order to work >> towards a more complete solution to the underlying problem (see >> JDK-8066725 and JDK-8062582 for details) >> >> The patch was created cleanly by reverting JDK-8029012 and JDK-8065132. >> The patch ran cleanly through a JPRT run. Review was conducted on >> compiler-dev, and it was approved by Jonathan Gibbons. >> >> Webrev: http://cr.openjdk.java.net/~emc/8067039/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8067039 > > > From sean.coffey at oracle.com Thu Dec 11 15:56:41 2014 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Thu, 11 Dec 2014 15:56:41 +0000 Subject: [8u40] Request for Approval: 8067039: Revert changes to annotation attribute generation In-Reply-To: <5489B73C.1030205@oracle.com> References: <5489ADAE.9080008@oracle.com> <5489AFA9.6050207@oracle.com> <5489B73C.1030205@oracle.com> Message-ID: <5489BEB9.4020000@oracle.com> On 11/12/2014 15:24, Daniel D. Daugherty wrote: > > On 12/11/14 7:52 AM, Se?n Coffey wrote: >> Approved. Please add 9-na to the bug report. >> >> I've not sure what bug record policy is in such scenarios but I think >> the >> 8u40 records for JDK-8029012 and JDK-8065132 need to be reverted to >> something like "will not fix" ? > > No, they should not. Changesets were pushed using those bug IDs and > it would be confusing to change the state of the bugs. A user goes to check status of JDK-8029012 and JDK-8065132 in 8u40 and sees "Fixed" - that's equally as confusing and a more normal use case I would think. The net effect of the changesets in 8u-dev is now zero. regards, Sean. > However, it > would be good to add a note to those two bugs stating that the > changes have been reverted/anti-delta'ed using JDK-8067039. > > Dan > > >> >> regards, >> Sean. >> >> On 11/12/2014 14:43, Eric McCorkle wrote: >>> Please approve JDK-8067039, which reverts JDK-8029012 and JDK-8065132, >>> which cause previous versions of javac in 8 not to be able to load some >>> classfiles generated by the current 8u javac. >>> >>> After discussions amongst the langtools team, it was decided that the >>> change should be backed out in 8u, but kept in 9 in order to work >>> towards a more complete solution to the underlying problem (see >>> JDK-8066725 and JDK-8062582 for details) >>> >>> The patch was created cleanly by reverting JDK-8029012 and JDK-8065132. >>> The patch ran cleanly through a JPRT run. Review was conducted on >>> compiler-dev, and it was approved by Jonathan Gibbons. >>> >>> Webrev: http://cr.openjdk.java.net/~emc/8067039/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8067039 >> >> >> > From daniel.daugherty at oracle.com Thu Dec 11 16:17:43 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 11 Dec 2014 09:17:43 -0700 Subject: [8u40] Request for Approval: 8067039: Revert changes to annotation attribute generation In-Reply-To: <5489BEB9.4020000@oracle.com> References: <5489ADAE.9080008@oracle.com> <5489AFA9.6050207@oracle.com> <5489B73C.1030205@oracle.com> <5489BEB9.4020000@oracle.com> Message-ID: <5489C3A7.6030801@oracle.com> On 12/11/14 8:56 AM, Se?n Coffey wrote: > > On 11/12/2014 15:24, Daniel D. Daugherty wrote: >> >> On 12/11/14 7:52 AM, Se?n Coffey wrote: >>> Approved. Please add 9-na to the bug report. >>> >>> I've not sure what bug record policy is in such scenarios but I >>> think the >>> 8u40 records for JDK-8029012 and JDK-8065132 need to be reverted to >>> something like "will not fix" ? >> >> No, they should not. Changesets were pushed using those bug IDs and >> it would be confusing to change the state of the bugs. > A user goes to check status of JDK-8029012 and JDK-8065132 in 8u40 and > sees "Fixed" - that's equally as confusing and a more normal use case > I would think. I recommend checking with Joe Darcy about what the proper process is. The problem that we've seen in JDK9 is from the Mercurial auto-updater as the changesets are pushed to parent repos... the bug gets reresolved as fixed... Why? Because the original changeset is again pushed to a repo followed by the subsequent anti-delta... > The net effect of the changesets in 8u-dev is now zero. No argument there... as long as you are looking at the tip. If are looking at the repo at a specific point in time like the snapshot taken for a particular promoted build... then your answer may be different. Dan > > regards, > Sean. > >> However, it >> would be good to add a note to those two bugs stating that the >> changes have been reverted/anti-delta'ed using JDK-8067039. >> >> Dan >> >> >>> >>> regards, >>> Sean. >>> >>> On 11/12/2014 14:43, Eric McCorkle wrote: >>>> Please approve JDK-8067039, which reverts JDK-8029012 and JDK-8065132, >>>> which cause previous versions of javac in 8 not to be able to load >>>> some >>>> classfiles generated by the current 8u javac. >>>> >>>> After discussions amongst the langtools team, it was decided that the >>>> change should be backed out in 8u, but kept in 9 in order to work >>>> towards a more complete solution to the underlying problem (see >>>> JDK-8066725 and JDK-8062582 for details) >>>> >>>> The patch was created cleanly by reverting JDK-8029012 and >>>> JDK-8065132. >>>> The patch ran cleanly through a JPRT run. Review was conducted on >>>> compiler-dev, and it was approved by Jonathan Gibbons. >>>> >>>> Webrev: http://cr.openjdk.java.net/~emc/8067039/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8067039 >>> >>> >>> >> > > > From sean.coffey at oracle.com Thu Dec 11 16:42:59 2014 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Thu, 11 Dec 2014 16:42:59 +0000 Subject: [8u40] Request for approval: JDK-8066669: dust.js performance regression caused by primitive field conversion In-Reply-To: <5489B201.9040508@oracle.com> References: <5489B201.9040508@oracle.com> Message-ID: <5489C993.5070709@oracle.com> Approved. regards, Sean. On 11/12/2014 15:02, Hannes Wallnoefer wrote: > Please approve backport of JDK-8066669 to 8u40. > > Changes apply cleanly to 8u40 after shuffling path names except for > two hunks in MethodEmitter.java. These changes are currently being > reviewed and tested. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8066669 > Webrevs: http://cr.openjdk.java.net/~hannesw/8066669/ > Review thread: > http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-December/004011.html > Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/7c1cff3cae2e > > Thanks, > Hannes From vladimir.x.ivanov at oracle.com Thu Dec 11 17:37:12 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 11 Dec 2014 20:37:12 +0300 Subject: [8u40] Request for approval: 8066746, 8057020 Message-ID: <5489D648.8050309@oracle.com> Please, approve backport of the following fixes into 8u40: 8066746: "MHs.explicitCastArguments does incorrect type checks for VarargsCollector" https://bugs.openjdk.java.net/browse/JDK-8066746 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/cb475099ceac http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030210.html 8057020: "LambdaForm caches should support eviction" https://bugs.openjdk.java.net/browse/JDK-8057020 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3e6549434acb http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/029961.html Both fixes apply cleanly. Thanks! Best regards, Vladimir Ivanov From rob.mckenna at oracle.com Thu Dec 11 17:56:06 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 11 Dec 2014 17:56:06 +0000 Subject: [8u40] Request for approval: 8066746, 8057020 In-Reply-To: <5489D648.8050309@oracle.com> References: <5489D648.8050309@oracle.com> Message-ID: <5489DAB6.20101@oracle.com> Approved on the condition that you push before 2pm PST -Rob On 11/12/14 17:37, Vladimir Ivanov wrote: > Please, approve backport of the following fixes into 8u40: > > 8066746: "MHs.explicitCastArguments does incorrect type checks for > VarargsCollector" > https://bugs.openjdk.java.net/browse/JDK-8066746 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/cb475099ceac > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030210.html > > > 8057020: "LambdaForm caches should support eviction" > https://bugs.openjdk.java.net/browse/JDK-8057020 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3e6549434acb > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/029961.html > > > Both fixes apply cleanly. > > Thanks! > > Best regards, > Vladimir Ivanov From vladimir.x.ivanov at oracle.com Thu Dec 11 18:16:30 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 11 Dec 2014 21:16:30 +0300 Subject: [8u40] Request for approval: 8066746, 8057020 In-Reply-To: <5489DAB6.20101@oracle.com> References: <5489D648.8050309@oracle.com> <5489DAB6.20101@oracle.com> Message-ID: <5489DF7E.5080003@oracle.com> Thanks, Rob! Best regards, Vladimir Ivanov On 12/11/14, 8:56 PM, Rob McKenna wrote: > Approved on the condition that you push before 2pm PST > > -Rob > > On 11/12/14 17:37, Vladimir Ivanov wrote: >> Please, approve backport of the following fixes into 8u40: >> >> 8066746: "MHs.explicitCastArguments does incorrect type checks for >> VarargsCollector" >> https://bugs.openjdk.java.net/browse/JDK-8066746 >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/cb475099ceac >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030210.html >> >> >> 8057020: "LambdaForm caches should support eviction" >> https://bugs.openjdk.java.net/browse/JDK-8057020 >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3e6549434acb >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/029961.html >> >> >> Both fixes apply cleanly. >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov > From hannes.wallnoefer at oracle.com Thu Dec 11 18:24:02 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 11 Dec 2014 19:24:02 +0100 Subject: [8u40] Request for approval: JDK-8067219: NPE in ScriptObject.clone() when running with object fields Message-ID: <5489E142.80408@oracle.com> Sorry for this last-minute request. I'd like to backport of JDK-8067219 to 8u40. Changes apply cleanly to 8u40 after shuffling path names. Bug: https://bugs.openjdk.java.net/browse/JDK-8067219 Webrev: http://cr.openjdk.java.net/~hannesw/8067219/ Review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-December/004017.html Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/c4c3be2ab854 Thanks, Hannes From rob.mckenna at oracle.com Thu Dec 11 18:27:55 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 11 Dec 2014 18:27:55 +0000 Subject: [8u40] Request for approval: JDK-8067219: NPE in ScriptObject.clone() when running with object fields In-Reply-To: <5489E142.80408@oracle.com> References: <5489E142.80408@oracle.com> Message-ID: <5489E22B.2000300@oracle.com> Approved on the condition that you push before 2pm PST -Rob On 11/12/14 18:24, Hannes Wallnoefer wrote: > Sorry for this last-minute request. I'd like to backport of > JDK-8067219 to 8u40. > > Changes apply cleanly to 8u40 after shuffling path names. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8067219 > Webrev: http://cr.openjdk.java.net/~hannesw/8067219/ > Review thread: > http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-December/004017.html > Changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/c4c3be2ab854 > > Thanks, > Hannes From joe.darcy at oracle.com Fri Dec 12 01:21:10 2014 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 11 Dec 2014 17:21:10 -0800 Subject: [8u40] Request for Approval: 8067039: Revert changes to annotation attribute generation In-Reply-To: <5489AFA9.6050207@oracle.com> References: <5489ADAE.9080008@oracle.com> <5489AFA9.6050207@oracle.com> Message-ID: <548A4306.1050607@oracle.com> Hello, With my JBS designed hat on, I think the resting state of the original bugs being reverted should be as follows: * status = closed * resolution = fixed * verification = fixed-failed This indicates a changeset was pushed for the bug (resolution = fixed), no more action is expected (status = closed), but that the fix was problematic (verification = fixed-failed). The bug should also have a link to the bug for the revision. HTH, -Joe On 12/11/2014 6:52 AM, Se?n Coffey wrote: > Approved. Please add 9-na to the bug report. > > I've not sure what bug record policy is in such scenarios but I think the > 8u40 records for JDK-8029012 and JDK-8065132 need to be reverted to > something like "will not fix" ? > > regards, > Sean. > > On 11/12/2014 14:43, Eric McCorkle wrote: >> Please approve JDK-8067039, which reverts JDK-8029012 and JDK-8065132, >> which cause previous versions of javac in 8 not to be able to load some >> classfiles generated by the current 8u javac. >> >> After discussions amongst the langtools team, it was decided that the >> change should be backed out in 8u, but kept in 9 in order to work >> towards a more complete solution to the underlying problem (see >> JDK-8066725 and JDK-8062582 for details) >> >> The patch was created cleanly by reverting JDK-8029012 and JDK-8065132. >> The patch ran cleanly through a JPRT run. Review was conducted on >> compiler-dev, and it was approved by Jonathan Gibbons. >> >> Webrev: http://cr.openjdk.java.net/~emc/8067039/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8067039 > From sean.coffey at oracle.com Fri Dec 12 15:40:12 2014 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Fri, 12 Dec 2014 15:40:12 +0000 Subject: JBS policy around backing out of bug fixes : was(Re: [8u40] Request for Approval: 8067039: Revert changes to annotation attribute generation) In-Reply-To: <548A4306.1050607@oracle.com> References: <5489ADAE.9080008@oracle.com> <5489AFA9.6050207@oracle.com> <548A4306.1050607@oracle.com> Message-ID: <548B0C5C.4040207@oracle.com> Joe, Thanks for the update. I was not aware of the below process. I have to add that I find it counter-intuitive. Anyone looking at bug x which has status "Fixed" would assume it's fixed! It's dangerous. Could we move resolution to "Fix Failed" instead? - that field also exists. Alot of JIRA queries would have to be rewritten if the below policy remains. Release note generation queries, unresolved bug queries, etc. Backing out bug fixes is rare enough thankfully but it's an important event to capture. regards, Sean. On 12/12/14 01:21, joe darcy wrote: > Hello, > > With my JBS designed hat on, I think the resting state of the original > bugs being reverted should be as follows: > > * status = closed > * resolution = fixed > * verification = fixed-failed > > This indicates a changeset was pushed for the bug (resolution = > fixed), no more action is expected (status = closed), but that the fix > was problematic (verification = fixed-failed). > > The bug should also have a link to the bug for the revision. > > HTH, > > -Joe > > On 12/11/2014 6:52 AM, Se?n Coffey wrote: >> Approved. Please add 9-na to the bug report. >> >> I've not sure what bug record policy is in such scenarios but I think >> the >> 8u40 records for JDK-8029012 and JDK-8065132 need to be reverted to >> something like "will not fix" ? >> >> regards, >> Sean. >> >> On 11/12/2014 14:43, Eric McCorkle wrote: >>> Please approve JDK-8067039, which reverts JDK-8029012 and JDK-8065132, >>> which cause previous versions of javac in 8 not to be able to load some >>> classfiles generated by the current 8u javac. >>> >>> After discussions amongst the langtools team, it was decided that the >>> change should be backed out in 8u, but kept in 9 in order to work >>> towards a more complete solution to the underlying problem (see >>> JDK-8066725 and JDK-8062582 for details) >>> >>> The patch was created cleanly by reverting JDK-8029012 and JDK-8065132. >>> The patch ran cleanly through a JPRT run. Review was conducted on >>> compiler-dev, and it was approved by Jonathan Gibbons. >>> >>> Webrev: http://cr.openjdk.java.net/~emc/8067039/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8067039 >> > From alejandro.murillo at oracle.com Fri Dec 12 21:28:05 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Fri, 12 Dec 2014 14:28:05 -0700 Subject: [8u40] Request for approval for bulk integration of hs25.40-b23 Message-ID: <548B5DE5.3070300@oracle.com> Requesting approval to integrate hs25.40-b23 into jdk8u40-b19. A webrev is available at: http://cr.openjdk.java.net/~amurillo/8u40/hs25.40-b23-jdk8u40-b19.webrev/ Pre-integration testing is in progress; the integration will proceed only after SQE has analyzed the results and approved. The fixes in the proposed integration are below. All have undergone nightly testing and are already in a jdk9 repository. 6898462: The escape analysis with G1 cause crash assertion src/share/vm/runtime/vframeArray.cpp:94 8048170: Test closed/java/text/Normalizer/ConformanceTest.java failed 8065634: Crash in InstanceKlass::clean_method_data when _method is NULL 8066103: C2's range check smearing allows out of bound array accesses 8066647: new hotspot build - hs25.40-b23 8066670: PrintSharedArchiveAndExit does not exit the VM when the archive is invalid 8066775: opto/node.hpp:355, assert(i < _max) failed: oob: i=1, _max=1 8066900: Array Out Of Bounds Exception causes variable corruption 8066964: ppc64: argument and return type profiling, fix problem with popframe 8067144: SIGSEGV with +TraceDeoptimization in Deoptimization::print_objects 8067232: [TESTBUG] runtime/CheckEndorsedAndExtDirs/EndorsedExtDirs.java fails with ClassNotFoundException -- Alejandro From alejandro.murillo at oracle.com Fri Dec 12 21:31:46 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Fri, 12 Dec 2014 14:31:46 -0700 Subject: [8u40] IMPORTANT INFO: Please do not push any changeset to jdk8u/hs-dev until further notice Message-ID: <548B5EC2.4060203@oracle.com> Hotspot developers: I just took the last snapshot of jdk8u/hs-dev [1] before 8u40 enters the RDP2 phase. that repository will become associated to 8u60 next week, after 8u40-b19 is promoted. Until then please refrain from pushing any changes to it. I will reply this email when that happens Going forward, Hotspot changes destined for 8u40 will need to be approved by the releasing team (see [2] for details). Once approved, they should be pushed to jdk8u/hs-dev as usual, and then I will take all 8u40 approved changes from there to the jdk8u40 stabilization repo (see [3]) after going through PIT (if needed). thanks [1] http://hg.openjdk.java.net/jdk8u/hs-dev/ [2] http://openjdk.java.net/projects/jdk8u/phase2/phase2-process.html [3] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2014-December/002677.html -- Alejandro From sean.coffey at oracle.com Fri Dec 12 22:08:07 2014 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Fri, 12 Dec 2014 22:08:07 +0000 Subject: [8u40] Request for approval for bulk integration of hs25.40-b23 In-Reply-To: <548B5DE5.3070300@oracle.com> References: <548B5DE5.3070300@oracle.com> Message-ID: <548B6747.3060400@oracle.com> Approved pending positive PIT results. regards, Sean. On 12/12/14 21:28, Alejandro E Murillo wrote: > Requesting approval to integrate hs25.40-b23 into jdk8u40-b19. > > A webrev is available at: > > http://cr.openjdk.java.net/~amurillo/8u40/hs25.40-b23-jdk8u40-b19.webrev/ > > Pre-integration testing is in progress; the integration will proceed > only after SQE has analyzed the results and approved. > > The fixes in the proposed integration are below. All have undergone > nightly testing and are already in a jdk9 repository. > > 6898462: The escape analysis with G1 cause crash assertion > src/share/vm/runtime/vframeArray.cpp:94 > 8048170: Test closed/java/text/Normalizer/ConformanceTest.java failed > 8065634: Crash in InstanceKlass::clean_method_data when _method is NULL > 8066103: C2's range check smearing allows out of bound array accesses > 8066647: new hotspot build - hs25.40-b23 > 8066670: PrintSharedArchiveAndExit does not exit the VM when the > archive is invalid > 8066775: opto/node.hpp:355, assert(i < _max) failed: oob: i=1, _max=1 > 8066900: Array Out Of Bounds Exception causes variable corruption > 8066964: ppc64: argument and return type profiling, fix problem with > popframe > 8067144: SIGSEGV with +TraceDeoptimization in > Deoptimization::print_objects > 8067232: [TESTBUG] > runtime/CheckEndorsedAndExtDirs/EndorsedExtDirs.java fails with > ClassNotFoundException > From david.holmes at oracle.com Sat Dec 13 00:41:51 2014 From: david.holmes at oracle.com (David Holmes) Date: Sat, 13 Dec 2014 10:41:51 +1000 Subject: JBS policy around backing out of bug fixes : was(Re: [8u40] Request for Approval: 8067039: Revert changes to annotation attribute generation) In-Reply-To: <548B0C5C.4040207@oracle.com> References: <5489ADAE.9080008@oracle.com> <5489AFA9.6050207@oracle.com> <548A4306.1050607@oracle.com> <548B0C5C.4040207@oracle.com> Message-ID: <548B8B4F.8010300@oracle.com> Sean, This issue was discussed at some length when JBS was being set up. David On 13/12/2014 1:40 AM, Se?n Coffey wrote: > Joe, > > Thanks for the update. I was not aware of the below process. I have to > add that I find it counter-intuitive. Anyone looking at bug x which has > status "Fixed" would assume it's fixed! It's dangerous. Could we move > resolution to "Fix Failed" instead? - that field also exists. Alot of > JIRA queries would have to be rewritten if the below policy remains. > Release note generation queries, unresolved bug queries, etc. Backing > out bug fixes is rare enough thankfully but it's an important event to > capture. > > regards, > Sean. > > On 12/12/14 01:21, joe darcy wrote: >> Hello, >> >> With my JBS designed hat on, I think the resting state of the original >> bugs being reverted should be as follows: >> >> * status = closed >> * resolution = fixed >> * verification = fixed-failed >> >> This indicates a changeset was pushed for the bug (resolution = >> fixed), no more action is expected (status = closed), but that the fix >> was problematic (verification = fixed-failed). >> >> The bug should also have a link to the bug for the revision. >> >> HTH, >> >> -Joe >> >> On 12/11/2014 6:52 AM, Se?n Coffey wrote: >>> Approved. Please add 9-na to the bug report. >>> >>> I've not sure what bug record policy is in such scenarios but I think >>> the >>> 8u40 records for JDK-8029012 and JDK-8065132 need to be reverted to >>> something like "will not fix" ? >>> >>> regards, >>> Sean. >>> >>> On 11/12/2014 14:43, Eric McCorkle wrote: >>>> Please approve JDK-8067039, which reverts JDK-8029012 and JDK-8065132, >>>> which cause previous versions of javac in 8 not to be able to load some >>>> classfiles generated by the current 8u javac. >>>> >>>> After discussions amongst the langtools team, it was decided that the >>>> change should be backed out in 8u, but kept in 9 in order to work >>>> towards a more complete solution to the underlying problem (see >>>> JDK-8066725 and JDK-8062582 for details) >>>> >>>> The patch was created cleanly by reverting JDK-8029012 and JDK-8065132. >>>> The patch ran cleanly through a JPRT run. Review was conducted on >>>> compiler-dev, and it was approved by Jonathan Gibbons. >>>> >>>> Webrev: http://cr.openjdk.java.net/~emc/8067039/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8067039 >>> >> > From marcins at microsoft.com Sun Dec 14 15:04:42 2014 From: marcins at microsoft.com (Martin Sawicki (MS OPEN TECH)) Date: Sun, 14 Dec 2014 15:04:42 +0000 Subject: Backporting the TCP Loopack fast path (Windows) improvement to JDK 8 In-Reply-To: <54873754.6030007@oracle.com> References: <54873754.6030007@oracle.com> Message-ID: Hi Sean, As requested, attached is the patch file. To create the patch, the unshuffle_patch.sh script from jdk9 repo was applied to the jdk9 patch to transform the file names back to the jdk8 project structure. The resulting patch was cleanly applied to jdk8u-dev. If you could help with whatever other steps of the process we're missing, that would be appreciated! Best regards Martin (and Kirk and Valeriy) Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corp. -----Original Message----- From: Se?n Coffey [mailto:sean.coffey at oracle.com] Sent: Tuesday, December 09, 2014 9:54 AM To: Martin Sawicki (MS OPEN TECH); jdk8u-dev at openjdk.java.net Cc: Valery Kopylov (Akvelon); Kirk Shoop (MS OPEN TECH) Subject: Re: Backporting the TCP Loopack fast path (Windows) improvement to JDK 8 Martin, does the JDK 9 patch apply cleanly to the jdk8u code base (bar any path name changes) ? The CCC was logged for JDK 9 only - We'd need one approved for JDK 8u before a push can be made. I can help out there if necessary. Also - we can't accept patches hosted on non OpenJDK infrastructure ? Could you reply and append the jdk.patch file (as per webrev generation) to this mail ? Regards, Sean. On 09/12/2014 17:45, Martin Sawicki (MS OPEN TECH) wrote: > Hello, > > We'd like to propose to backport our TCP loopback fast path improvement for Windows that was recently accepted into JDK9 to JDK8: > (JDK9 fix for reference: > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/26e6402772c8) > > Our suggested JDK8 webrev package can be found here: > https://openjdkcontrib.blob.core.windows.net/tcploopback/jdk8-webrev-2 > 0141105.zip > > We'd appreciate your review and acceptance of this contribution. > > Best regards, > Martin Sawicki (and Kirk Shoop, and Valeriy Kopylov) Microsoft Open > Technologies, Inc. > From sean.coffey at oracle.com Sun Dec 14 15:33:33 2014 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Sun, 14 Dec 2014 15:33:33 +0000 Subject: JBS policy around backing out of bug fixes : was(Re: [8u40] Request for Approval: 8067039: Revert changes to annotation attribute generation) In-Reply-To: <548B8B4F.8010300@oracle.com> References: <5489ADAE.9080008@oracle.com> <5489AFA9.6050207@oracle.com> <548A4306.1050607@oracle.com> <548B0C5C.4040207@oracle.com> <548B8B4F.8010300@oracle.com> Message-ID: <548DADCD.3090309@oracle.com> On 13/12/2014 00:41, David Holmes wrote: > Sean, > > This issue was discussed at some length when JBS was being set up. David, I realise there was alot of discussion around JBS process when it was being set up. IIRC, the custom verification field was a request from Quality team to track bug fixes. For that reason, I imagine it's of most interest to quality team. I normally focus on Status/Resolution fields. Could I make a proposal that we mark anit-deltas with Resolution = Fix Failed ? Is there any reason we can't ? It helps to keep JIRA queries more simple and avoids having to look up a 3rd field in order to capture the true state of a bug fix. Here's another example of a bug fix one would think was fixed in JDK 8 : https://bugs.openjdk.java.net/browse/JDK-8025198 regards, Sean. > > David > > On 13/12/2014 1:40 AM, Se?n Coffey wrote: >> Joe, >> >> Thanks for the update. I was not aware of the below process. I have to >> add that I find it counter-intuitive. Anyone looking at bug x which has >> status "Fixed" would assume it's fixed! It's dangerous. Could we move >> resolution to "Fix Failed" instead? - that field also exists. Alot of >> JIRA queries would have to be rewritten if the below policy remains. >> Release note generation queries, unresolved bug queries, etc. Backing >> out bug fixes is rare enough thankfully but it's an important event to >> capture. >> >> regards, >> Sean. >> >> On 12/12/14 01:21, joe darcy wrote: >>> Hello, >>> >>> With my JBS designed hat on, I think the resting state of the original >>> bugs being reverted should be as follows: >>> >>> * status = closed >>> * resolution = fixed >>> * verification = fixed-failed >>> >>> This indicates a changeset was pushed for the bug (resolution = >>> fixed), no more action is expected (status = closed), but that the fix >>> was problematic (verification = fixed-failed). >>> >>> The bug should also have a link to the bug for the revision. >>> >>> HTH, >>> >>> -Joe >>> >>> On 12/11/2014 6:52 AM, Se?n Coffey wrote: >>>> Approved. Please add 9-na to the bug report. >>>> >>>> I've not sure what bug record policy is in such scenarios but I think >>>> the >>>> 8u40 records for JDK-8029012 and JDK-8065132 need to be reverted to >>>> something like "will not fix" ? >>>> >>>> regards, >>>> Sean. >>>> >>>> On 11/12/2014 14:43, Eric McCorkle wrote: >>>>> Please approve JDK-8067039, which reverts JDK-8029012 and >>>>> JDK-8065132, >>>>> which cause previous versions of javac in 8 not to be able to load >>>>> some >>>>> classfiles generated by the current 8u javac. >>>>> >>>>> After discussions amongst the langtools team, it was decided that the >>>>> change should be backed out in 8u, but kept in 9 in order to work >>>>> towards a more complete solution to the underlying problem (see >>>>> JDK-8066725 and JDK-8062582 for details) >>>>> >>>>> The patch was created cleanly by reverting JDK-8029012 and >>>>> JDK-8065132. >>>>> The patch ran cleanly through a JPRT run. Review was conducted on >>>>> compiler-dev, and it was approved by Jonathan Gibbons. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~emc/8067039/ >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8067039 >>>> >>> >> From sean.coffey at oracle.com Sun Dec 14 15:37:17 2014 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Sun, 14 Dec 2014 15:37:17 +0000 Subject: Backporting the TCP Loopack fast path (Windows) improvement to JDK 8 - JDK-8060170 In-Reply-To: References: <54873754.6030007@oracle.com> Message-ID: <548DAEAD.6030906@oracle.com> Thanks for the updates Martin. The CCC has since been approved for porting to JDK 8u. I'll get around to an approval request & push early this week. regards, Sean. On 14/12/2014 15:04, Martin Sawicki (MS OPEN TECH) wrote: > Hi Sean, > As requested, attached is the patch file. > To create the patch, the unshuffle_patch.sh script from jdk9 repo was applied to the jdk9 patch to transform the file names back to the jdk8 project structure. The resulting patch was cleanly applied to jdk8u-dev. > If you could help with whatever other steps of the process we're missing, that would be appreciated! > Best regards > > Martin (and Kirk and Valeriy) > Microsoft Open Technologies, Inc. > A subsidiary of Microsoft Corp. > > -----Original Message----- > From: Se?n Coffey [mailto:sean.coffey at oracle.com] > Sent: Tuesday, December 09, 2014 9:54 AM > To: Martin Sawicki (MS OPEN TECH); jdk8u-dev at openjdk.java.net > Cc: Valery Kopylov (Akvelon); Kirk Shoop (MS OPEN TECH) > Subject: Re: Backporting the TCP Loopack fast path (Windows) improvement to JDK 8 > > Martin, > > does the JDK 9 patch apply cleanly to the jdk8u code base (bar any path name changes) ? > > The CCC was logged for JDK 9 only - We'd need one approved for JDK 8u before a push can be made. I can help out there if necessary. Also - we can't accept patches hosted on non OpenJDK infrastructure ? Could you reply and append the jdk.patch file (as per webrev generation) to this mail ? > > Regards, > Sean. > > On 09/12/2014 17:45, Martin Sawicki (MS OPEN TECH) wrote: >> Hello, >> >> We'd like to propose to backport our TCP loopback fast path improvement for Windows that was recently accepted into JDK9 to JDK8: >> (JDK9 fix for reference: >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/26e6402772c8) >> >> Our suggested JDK8 webrev package can be found here: >> https://openjdkcontrib.blob.core.windows.net/tcploopback/jdk8-webrev-2 >> 0141105.zip >> >> We'd appreciate your review and acceptance of this contribution. >> >> Best regards, >> Martin Sawicki (and Kirk Shoop, and Valeriy Kopylov) Microsoft Open >> Technologies, Inc. >> From david.holmes at oracle.com Mon Dec 15 00:18:34 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 15 Dec 2014 10:18:34 +1000 Subject: JBS policy around backing out of bug fixes : was(Re: [8u40] Request for Approval: 8067039: Revert changes to annotation attribute generation) In-Reply-To: <548DADCD.3090309@oracle.com> References: <5489ADAE.9080008@oracle.com> <5489AFA9.6050207@oracle.com> <548A4306.1050607@oracle.com> <548B0C5C.4040207@oracle.com> <548B8B4F.8010300@oracle.com> <548DADCD.3090309@oracle.com> Message-ID: <548E28DA.2070201@oracle.com> On 15/12/2014 1:33 AM, Se?n Coffey wrote: > > On 13/12/2014 00:41, David Holmes wrote: >> Sean, >> >> This issue was discussed at some length when JBS was being set up. > David, > > I realise there was alot of discussion around JBS process when it was > being set up. IIRC, the custom verification field was a request from > Quality team to track bug fixes. For that reason, I imagine it's of most > interest to quality team. I normally focus on Status/Resolution fields. > Could I make a proposal that we mark anit-deltas with Resolution = Fix > Failed ? Is there any reason we can't ? You mean the bug for which the anti-delta was needed should be marked Resolution=fix-failed? I don't have a problem with that, but these aren't my rules. It helps to keep JIRA queries > more simple and avoids having to look up a 3rd field in order to capture > the true state of a bug fix. > > Here's another example of a bug fix one would think was fixed in JDK 8 : > https://bugs.openjdk.java.net/browse/JDK-8025198 It is fixed in the JDK-8. The "anti-delta" was only a partial anti-delta for the files that had been modified unintentionally. The actual fix is still present. David > regards, > Sean. > >> >> David >> >> On 13/12/2014 1:40 AM, Se?n Coffey wrote: >>> Joe, >>> >>> Thanks for the update. I was not aware of the below process. I have to >>> add that I find it counter-intuitive. Anyone looking at bug x which has >>> status "Fixed" would assume it's fixed! It's dangerous. Could we move >>> resolution to "Fix Failed" instead? - that field also exists. Alot of >>> JIRA queries would have to be rewritten if the below policy remains. >>> Release note generation queries, unresolved bug queries, etc. Backing >>> out bug fixes is rare enough thankfully but it's an important event to >>> capture. >>> >>> regards, >>> Sean. >>> >>> On 12/12/14 01:21, joe darcy wrote: >>>> Hello, >>>> >>>> With my JBS designed hat on, I think the resting state of the original >>>> bugs being reverted should be as follows: >>>> >>>> * status = closed >>>> * resolution = fixed >>>> * verification = fixed-failed >>>> >>>> This indicates a changeset was pushed for the bug (resolution = >>>> fixed), no more action is expected (status = closed), but that the fix >>>> was problematic (verification = fixed-failed). >>>> >>>> The bug should also have a link to the bug for the revision. >>>> >>>> HTH, >>>> >>>> -Joe >>>> >>>> On 12/11/2014 6:52 AM, Se?n Coffey wrote: >>>>> Approved. Please add 9-na to the bug report. >>>>> >>>>> I've not sure what bug record policy is in such scenarios but I think >>>>> the >>>>> 8u40 records for JDK-8029012 and JDK-8065132 need to be reverted to >>>>> something like "will not fix" ? >>>>> >>>>> regards, >>>>> Sean. >>>>> >>>>> On 11/12/2014 14:43, Eric McCorkle wrote: >>>>>> Please approve JDK-8067039, which reverts JDK-8029012 and >>>>>> JDK-8065132, >>>>>> which cause previous versions of javac in 8 not to be able to load >>>>>> some >>>>>> classfiles generated by the current 8u javac. >>>>>> >>>>>> After discussions amongst the langtools team, it was decided that the >>>>>> change should be backed out in 8u, but kept in 9 in order to work >>>>>> towards a more complete solution to the underlying problem (see >>>>>> JDK-8066725 and JDK-8062582 for details) >>>>>> >>>>>> The patch was created cleanly by reverting JDK-8029012 and >>>>>> JDK-8065132. >>>>>> The patch ran cleanly through a JPRT run. Review was conducted on >>>>>> compiler-dev, and it was approved by Jonathan Gibbons. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~emc/8067039/ >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8067039 >>>>> >>>> >>> > From joe.darcy at oracle.com Mon Dec 15 04:42:13 2014 From: joe.darcy at oracle.com (joe darcy) Date: Sun, 14 Dec 2014 20:42:13 -0800 Subject: JBS policy around backing out of bug fixes : was(Re: [8u40] Request for Approval: 8067039: Revert changes to annotation attribute generation) In-Reply-To: <548E28DA.2070201@oracle.com> References: <5489ADAE.9080008@oracle.com> <5489AFA9.6050207@oracle.com> <548A4306.1050607@oracle.com> <548B0C5C.4040207@oracle.com> <548B8B4F.8010300@oracle.com> <548DADCD.3090309@oracle.com> <548E28DA.2070201@oracle.com> Message-ID: <548E66A5.7050002@oracle.com> Hello, On 12/14/2014 4:18 PM, David Holmes wrote: > On 15/12/2014 1:33 AM, Se?n Coffey wrote: >> >> On 13/12/2014 00:41, David Holmes wrote: >>> Sean, >>> >>> This issue was discussed at some length when JBS was being set up. >> David, >> >> I realise there was alot of discussion around JBS process when it was >> being set up. IIRC, the custom verification field was a request from >> Quality team to track bug fixes. For that reason, I imagine it's of most >> interest to quality team. I normally focus on Status/Resolution fields. >> Could I make a proposal that we mark anit-deltas with Resolution = Fix >> Failed ? Is there any reason we can't ? > > You mean the bug for which the anti-delta was needed should be marked > Resolution=fix-failed? I don't have a problem with that, but these > aren't my rules. > > It helps to keep JIRA queries >> more simple and avoids having to look up a 3rd field in order to capture >> the true state of a bug fix. >> >> Here's another example of a bug fix one would think was fixed in JDK 8 : >> https://bugs.openjdk.java.net/browse/JDK-8025198 > > It is fixed in the JDK-8. The "anti-delta" was only a partial > anti-delta for the files that had been modified unintentionally. The > actual fix is still present. > I've checked my JBS notes. "Fix failed" wasn't one of the resolution values available when JBS went live and I'm not sure when it was added. In any case, for the JDK project, I don't think that resolution value should be used; the JBS overview https://wiki.openjdk.java.net/display/general/JBS+Overview documents the field values I mentioned earlier (status = resolved/closed, resolution = fixed, verification = fix failed). A truly failed fix is an exceptional event and I don't really think it is worthwhile to devote a resolution value to that case. Cheers, -Joe From david.holmes at oracle.com Mon Dec 15 05:50:21 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 15 Dec 2014 15:50:21 +1000 Subject: JBS policy around backing out of bug fixes : was(Re: [8u40] Request for Approval: 8067039: Revert changes to annotation attribute generation) In-Reply-To: <548E66A5.7050002@oracle.com> References: <5489ADAE.9080008@oracle.com> <5489AFA9.6050207@oracle.com> <548A4306.1050607@oracle.com> <548B0C5C.4040207@oracle.com> <548B8B4F.8010300@oracle.com> <548DADCD.3090309@oracle.com> <548E28DA.2070201@oracle.com> <548E66A5.7050002@oracle.com> Message-ID: <548E769D.3030503@oracle.com> On 15/12/2014 2:42 PM, joe darcy wrote: > Hello, > > On 12/14/2014 4:18 PM, David Holmes wrote: >> On 15/12/2014 1:33 AM, Se?n Coffey wrote: >>> >>> On 13/12/2014 00:41, David Holmes wrote: >>>> Sean, >>>> >>>> This issue was discussed at some length when JBS was being set up. >>> David, >>> >>> I realise there was alot of discussion around JBS process when it was >>> being set up. IIRC, the custom verification field was a request from >>> Quality team to track bug fixes. For that reason, I imagine it's of most >>> interest to quality team. I normally focus on Status/Resolution fields. >>> Could I make a proposal that we mark anit-deltas with Resolution = Fix >>> Failed ? Is there any reason we can't ? >> >> You mean the bug for which the anti-delta was needed should be marked >> Resolution=fix-failed? I don't have a problem with that, but these >> aren't my rules. >> >> It helps to keep JIRA queries >>> more simple and avoids having to look up a 3rd field in order to capture >>> the true state of a bug fix. >>> >>> Here's another example of a bug fix one would think was fixed in JDK 8 : >>> https://bugs.openjdk.java.net/browse/JDK-8025198 >> >> It is fixed in the JDK-8. The "anti-delta" was only a partial >> anti-delta for the files that had been modified unintentionally. The >> actual fix is still present. >> > > I've checked my JBS notes. "Fix failed" wasn't one of the resolution > values available when JBS went live and I'm not sure when it was added. I thought I didn't recall this being an option from previous discussion. > In any case, for the JDK project, I don't think that resolution value > should be used; the JBS overview > > https://wiki.openjdk.java.net/display/general/JBS+Overview > > documents the field values I mentioned earlier (status = > resolved/closed, resolution = fixed, verification = fix failed). > > A truly failed fix is an exceptional event and I don't really think it > is worthwhile to devote a resolution value to that case. ??? If the value already exists then why shouldn't we use it to reflect a situation that it describes very well ?? Backing out fixes with unintended consequences is something that the hotspot processes are advocating more strongly now - so this might not be as rare as it has been. Cheers, David > Cheers, > > -Joe > From marcins at microsoft.com Mon Dec 15 13:01:36 2014 From: marcins at microsoft.com (Martin Sawicki (MS OPEN TECH)) Date: Mon, 15 Dec 2014 13:01:36 +0000 Subject: Backporting the FileChannel.transferTo (Windows) improvement to JDK 8 Message-ID: Hello, We'd like to propose to backport our FileChannel.transferTo() performance improvement for Windows that was recently accepted into JDK9 to JDK8: (JDK9 fix for reference: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ba6d8f56003b) Our suggested webrev patch is attached. Your review and acceptance of this contribution would be appreciated. Best regards, Martin Sawicki (and Kirk Shoop, and Valeriy Kopylov) Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corp. From marcins at microsoft.com Mon Dec 15 13:03:18 2014 From: marcins at microsoft.com (Martin Sawicki (MS OPEN TECH)) Date: Mon, 15 Dec 2014 13:03:18 +0000 Subject: Backporting the TCP Loopack fast path (Windows) improvement to JDK 8 - JDK-8060170 In-Reply-To: <548DAEAD.6030906@oracle.com> References: <54873754.6030007@oracle.com> <548DAEAD.6030906@oracle.com> Message-ID: Sean Great, thank you for the assistance. I'll start another thread now about the other item we recently fixed in JDK 9. Best regards -----Original Message----- From: Se?n Coffey [mailto:sean.coffey at oracle.com] Sent: Sunday, December 14, 2014 7:37 AM To: Martin Sawicki (MS OPEN TECH); jdk8u-dev at openjdk.java.net Cc: Valery Kopylov (Akvelon); Kirk Shoop (MS OPEN TECH) Subject: Re: Backporting the TCP Loopack fast path (Windows) improvement to JDK 8 - JDK-8060170 Thanks for the updates Martin. The CCC has since been approved for porting to JDK 8u. I'll get around to an approval request & push early this week. regards, Sean. On 14/12/2014 15:04, Martin Sawicki (MS OPEN TECH) wrote: > Hi Sean, > As requested, attached is the patch file. > To create the patch, the unshuffle_patch.sh script from jdk9 repo was applied to the jdk9 patch to transform the file names back to the jdk8 project structure. The resulting patch was cleanly applied to jdk8u-dev. > If you could help with whatever other steps of the process we're missing, that would be appreciated! > Best regards > > Martin (and Kirk and Valeriy) > Microsoft Open Technologies, Inc. > A subsidiary of Microsoft Corp. > > -----Original Message----- > From: Se?n Coffey [mailto:sean.coffey at oracle.com] > Sent: Tuesday, December 09, 2014 9:54 AM > To: Martin Sawicki (MS OPEN TECH); jdk8u-dev at openjdk.java.net > Cc: Valery Kopylov (Akvelon); Kirk Shoop (MS OPEN TECH) > Subject: Re: Backporting the TCP Loopack fast path (Windows) > improvement to JDK 8 > > Martin, > > does the JDK 9 patch apply cleanly to the jdk8u code base (bar any path name changes) ? > > The CCC was logged for JDK 9 only - We'd need one approved for JDK 8u before a push can be made. I can help out there if necessary. Also - we can't accept patches hosted on non OpenJDK infrastructure ? Could you reply and append the jdk.patch file (as per webrev generation) to this mail ? > > Regards, > Sean. > > On 09/12/2014 17:45, Martin Sawicki (MS OPEN TECH) wrote: >> Hello, >> >> We'd like to propose to backport our TCP loopback fast path improvement for Windows that was recently accepted into JDK9 to JDK8: >> (JDK9 fix for reference: >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/26e6402772c8) >> >> Our suggested JDK8 webrev package can be found here: >> https://openjdkcontrib.blob.core.windows.net/tcploopback/jdk8-webrev- >> 2 >> 0141105.zip >> >> We'd appreciate your review and acceptance of this contribution. >> >> Best regards, >> Martin Sawicki (and Kirk Shoop, and Valeriy Kopylov) Microsoft Open >> Technologies, Inc. >> From daniel.fuchs at oracle.com Mon Dec 15 17:48:36 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 15 Dec 2014 18:48:36 +0100 Subject: [9 + 8u] RFR - 8066612: Add a test that will call getDeclaredFields() on all classes and try to set them accessible. In-Reply-To: <5482DE1F.5070906@oracle.com> References: <547F9302.3060309@oracle.com> <547FD6F2.5060400@oracle.com> <548023D0.4020702@oracle.com> <548047C3.8000400@oracle.com> <54804E4B.2070908@oracle.com> <5480529F.1020902@oracle.com> <54805B5D.5020504@oracle.com> <54809627.8070103@oracle.com> <5480EFE8.3090809@oracle.com> <5482105D.40005@oracle.com> <5482D77C.9030100@gmail.com> <5482DE1F.5070906@oracle.com> Message-ID: <548F1EF4.1040007@oracle.com> Hi guys, Do I have approval to push the latest version of the test for JDK 9: http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.02/ or are there still some objections? best regards, -- daniel On 06/12/14 11:44, Daniel Fuchs wrote: > Hi Peter, > > > On 12/6/14 11:16 AM, Peter Levart wrote: >> >> On 12/05/2014 09:06 PM, Daniel Fuchs wrote: >>> Hi David, all, >>> >>> @David: You're right David. >>> The loader parameter is never used - I have removed it. >>> >>> @all: I have received a comment from Alan that it would be better to use >>> the new jrt:/ FileSystem directly, rather than using private APIs. >>> One of the consequence is that the test now loads all the >>> classes in the runtime image (not just the ones in the BCL), >>> and therefore I have removed the toggle that allowed to test >>> the boot classes only. >>> >>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.02/ >>> >>> best regards, >>> >>> -- daniel >> >> Hi Daniel, >> >> Would it be possible to extract a minimal API for streaming over >> classes and put that into the testlib so that only this part differs >> between JDK8 and JDK9 and the guts of the test is identical for both >> JDK8 and JDK9 ? >> >> This would ease backport efforts when the test(s) are later "beefed >> up" with other functionality. The API could later be extended with >> other functionality, but just for illustration what might be needed, >> here's what Martin Buchholz started as a test for finding possible >> data races in reflection and I just re-packed using Streams. From >> first glance it seems the tests need similar common functionality: >> >> http://cr.openjdk.java.net/~plevart/misc/SunReflectDataRaces/ >> >> Regards, Peter > > The test is already built like that: > > The part that finds the class names is encapsulated in an object which > implements Iterable. > > http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.02/ -> > ClassNameJrtStreamBuilder > http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk8-00/ -> > ClassNameStreamBuilder > http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk7.00/ -> > ClassNameListBuilder > > The bulk of the test should be identical (well, almost identical since I > only > updated 9 after the reviews, and since 9 is the only one that needs the > System ClassLoader)... I suppose we could extract these 3 classes and define > a library class with something like: > > public static class ClassNameFinder { > public static Iterable findAllClassNames() { > jdk9 impl: return new ClassNameJrtStreamBuilder(); > jdk8 impl: return new ClassNameStreamBuilder(); > jdk7 impl: return new ClassNameListBuilder(); > } > } > > As it stands - this corresponds to the > > static Iterable listAllClassNames() > > factory method in each version of the test. > > > best regards, > > -- daniel > >> >>> >>> On 05/12/14 00:36, David Holmes wrote: >>>> Hi Daniel, >>>> >>>> I still find your use of the classloader very confusing. You talk about >>>> the defining loader but you never check the defining loader against >>>> anything. In >>>> >>>> 146 static void checkFor(Class c, ClassLoader loader) { >>>> >>>> the loader variable is never used. And if loader is simply the name of >>>> the loader passed to forName, then it may not be the defining loader >>>> anyway - so the whole use of this loader variable seems superfluous at >>>> best, and confusing/misleading at worst. And you can use the simple >>>> forName(name) variant rather than passing a loader. >>>> >>>> David >>>> >>>> On 5/12/2014 3:13 AM, Daniel Fuchs wrote: >>>>> On 04/12/14 14:02, Se?n Coffey wrote: >>>>>> Thanks for driving efforts in this area Daniel. I think it's a very >>>>>> useful test and is bound to help test code coverage. If it's >>>>>> currently >>>>>> passing on all JPRT platforms, it's a good measure. >>>>> >>>>> It seems to :-) >>>>> >>>>>> Eventually I think we can bulk up the tests that can be run on the >>>>>> Iterable returned from your class search. >>>>>> At moment you just test Field.setAccessible. >>>>> >>>>> Yes. If we change it later to test more, we will probably need to >>>>> change its name. I was already in lack of inspiration: >>>>> FieldSetAccessibleTest is not really a great name - but hopefully >>>>> it can do for now. >>>>> >>>>>> In the future, I don't see any harm in adding all simple Field method >>>>>> calls so that any corner cases in custom classes like the original >>>>>> issue >>>>>> are caught. e.g Field.getDeclaredAnnotations(), Field.getModifiers(), >>>>>> Field.isEnumConstant() etc., etc. Some methods won't be much value >>>>>> add >>>>>> but they're not a cost either. >>>>> >>>>> Agreed. >>>>> >>>>>> Same argument for running through all Class methods, e.g >>>>>> Class.getDeclaredClasses(), Class.getDeclaredMethods(). As a >>>>>> result this >>>>>> test might eventually become more general in test goal and might live >>>>>> better one level up in "test/java/lang/Class/" - it can be moved when >>>>>> the time comes. >>>>> >>>>> Agreed as well :-) >>>>> >>>>> Here is a new revision of the webrev for 9 in which I have >>>>> incorporated David's comment: >>>>> >>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.01/ >>>>> >>>>> best regards, >>>>> >>>>> -- daniel >>>>> >>>>>> >>>>>> regards, >>>>>> Sean. >>>>>> >>>>>> On 04/12/2014 12:25, Daniel Fuchs wrote: >>>>>>> On 04/12/14 13:06, David Holmes wrote: >>>>>>>> Hi Daniel, >>>>>>>> >>>>>>>> On 4/12/2014 9:38 PM, Daniel Fuchs wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> In fact I could use 'null' on JDK 9 as well. >>>>>>>>> My first version of the JDK 9 test was parsing over all the >>>>>>>>> .jimage >>>>>>>>> files under /lib/modules - which explain why I needed to >>>>>>>>> use the System class loader. >>>>>>>>> >>>>>>>>> Then I switched to only parsing the bootmodules.jimage - because >>>>>>>>> I noticed that the results where more coherent with what I had >>>>>>>>> observed on 8 & 7 - but I kept using the System class loader. >>>>>>>>> >>>>>>>>> I am not sure whether we want the test for 9 should iterate over >>>>>>>>> the three .jimage - or continue to test only the boot .jimage. >>>>>>>>> >>>>>>>>> I have updated the JDK 9 test (refreshed the webrev in place) >>>>>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.00/ >>>>>>>>> and added support for possibly running the test in the two modes >>>>>>>>> (I added a 'test.boot.only' system property, true by default) >>>>>>>>> as well as additional traces to print the loaded classes by >>>>>>>>> defining loader at the end (test.list.classes, false by default). >>>>>>>> >>>>>>>> A couple of initial comments: >>>>>>>> >>>>>>>> 104 static ClassLoader getClassLoaderFor(String >>>>>>>> classFileName) { >>>>>>>> 105 if (restrictToBoot) return null; // only bootmodules >>>>>>>> 106 return ClassLoaders.systemClassLoader; >>>>>>>> 107 } >>>>>>>> >>>>>>>> I'm not clear the intent here. If it is to return a loader for >>>>>>>> which >>>>>>>> loadClass could be invoked then you can always just return the >>>>>>>> system >>>>>>>> loader - or just Class.forName. If it is meant to the return the >>>>>>>> expected defining loader then it isn't doing that as the extensions >>>>>>>> loader is not allowed for. >>>>>>> >>>>>>> The intent is to return the class loader that will be passed to >>>>>>> Class.forName( ). I've been fiddling & experimenting with this >>>>>>> test over 3 different platforms while trying to minimize the >>>>>>> differences - so that was my attempt at having a good place to >>>>>>> experiment with different strategy for loading classes. >>>>>>> >>>>>>>> Similarly for: >>>>>>>> >>>>>>>> 128 static ClassLoader getFor(String classFileName) { >>>>>>>> 129 return systemClassLoader; >>>>>>>> 130 } >>>>>>> >>>>>>> Oh - that's my mistake. In fact ClassLoader getClassLoaderFor(..) >>>>>>> was supposed to simply return ClassLoaders.getFor(...); >>>>>>> and all the code should be in ClassLoaders.getFor - my bad. >>>>>>> >>>>>>>> Minor nit - In: >>>>>>>> >>>>>>>> 135 System.err.println("Unexpected loader for >>>>>>>> "+c+": >>>>>>>> "+c.getClassLoader()); >>>>>>>> >>>>>>>> c.getClassLoader() can be replaced by cl. Also put spaces around >>>>>>>> the + >>>>>>>> operator. >>>>>>> >>>>>>> Good catch. >>>>>>> >>>>>>> Thanks a lot David! Have a good night! (that's quite late - isn't >>>>>>> it?) >>>>>>> >>>>>>> -- daniel >>>>>>> >>>>>>>> >>>>>>>> David >>>>>>>> (signing off for the night) >>>>>>>> >>>>>>>>> Thanks for your question, it triggered me into looking deeper >>>>>>>>> into what was happening :-) >>>>>>>>> >>>>>>>>> best regards, >>>>>>>>> >>>>>>>>> -- daniel >>>>>>>>> >>>>>>>>> On 04/12/14 10:05, Daniel Fuchs wrote: >>>>>>>>>>>> The differences between 8 & 9 are limited to: >>>>>>>>>>>> >>>>>>>>>>>> - ClassLoader: >>>>>>>>>>>> - on 8 we use 'null' (BCL) >>>>>>>>>>>> - on 9 we use the system class loader. >>>>>>>>>>> >>>>>>>>>>> I haven't seen anything in JEP 220, regarding modules, that >>>>>>>>>>> indicates >>>>>>>>>>> that classes currently loaded by the boot-loader will now be >>>>>>>>>>> loaded >>>>>>>>>>> by the system classloader ??? >>>>>>>>>> >>>>>>>>>> In [1] towards the end: >>>>>>>>>> >>>>>>>>>> [1] http://openjdk.java.net/jeps/220 >>>>>>>>>> >>>>>>>>>> "The defining class loader of the types in some existing packages >>>>>>>>>> will change. Existing code that makes assumptions about the >>>>>>>>>> class >>>>>>>>>> loaders of these types might not work correctly." >>>>>>>>>> (then there is a list of specific changes). >>>>>>>>>> >>>>>>>>>> This test looks up all class names in the image files and attempt >>>>>>>>>> to load the corresponding class. But as indicated in [1] >>>>>>>>>> some of these classes are now in the Boot CL, some in the >>>>>>>>>> Extension CL, and some in the Application CL. >>>>>>>>>> >>>>>>>>>> So the test uses the System CL to load each class - which ensures >>>>>>>>>> that the loading will be delegated to the appropriate >>>>>>>>>> ClassLoader. >>>>>>>>>> >>>>>>>>>> best regards, >>>>>>>>>> >>>>>>>>>> -- daniel >>>>>>>>> >>>>>>> >>>>>> >>>>> >>> >> > From sean.coffey at oracle.com Mon Dec 15 19:31:22 2014 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Mon, 15 Dec 2014 19:31:22 +0000 Subject: [9 + 8u] RFR - 8066612: Add a test that will call getDeclaredFields() on all classes and try to set them accessible. In-Reply-To: <548F1EF4.1040007@oracle.com> References: <547F9302.3060309@oracle.com> <547FD6F2.5060400@oracle.com> <548023D0.4020702@oracle.com> <548047C3.8000400@oracle.com> <54804E4B.2070908@oracle.com> <5480529F.1020902@oracle.com> <54805B5D.5020504@oracle.com> <54809627.8070103@oracle.com> <5480EFE8.3090809@oracle.com> <5482105D.40005@oracle.com> <5482D77C.9030100@gmail.com> <5482DE1F.5070906@oracle.com> <548F1EF4.1040007@oracle.com> Message-ID: <548F370A.8040609@oracle.com> On 15/12/2014 17:48, Daniel Fuchs wrote: > Hi guys, > > Do I have approval to push the latest version of the test for JDK 9: > http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.02/ > or are there still some objections? I'm fine with the test Daniel (as before) - it's a long-life test that can be tweaked and improved upon each iteration. regards, Sean. > > best regards, > > -- daniel > > > On 06/12/14 11:44, Daniel Fuchs wrote: >> Hi Peter, >> >> >> On 12/6/14 11:16 AM, Peter Levart wrote: >>> >>> On 12/05/2014 09:06 PM, Daniel Fuchs wrote: >>>> Hi David, all, >>>> >>>> @David: You're right David. >>>> The loader parameter is never used - I have removed it. >>>> >>>> @all: I have received a comment from Alan that it would be better >>>> to use >>>> the new jrt:/ FileSystem directly, rather than using private >>>> APIs. >>>> One of the consequence is that the test now loads all the >>>> classes in the runtime image (not just the ones in the BCL), >>>> and therefore I have removed the toggle that allowed to test >>>> the boot classes only. >>>> >>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.02/ >>>> >>>> best regards, >>>> >>>> -- daniel >>> >>> Hi Daniel, >>> >>> Would it be possible to extract a minimal API for streaming over >>> classes and put that into the testlib so that only this part differs >>> between JDK8 and JDK9 and the guts of the test is identical for both >>> JDK8 and JDK9 ? >>> >>> This would ease backport efforts when the test(s) are later "beefed >>> up" with other functionality. The API could later be extended with >>> other functionality, but just for illustration what might be needed, >>> here's what Martin Buchholz started as a test for finding possible >>> data races in reflection and I just re-packed using Streams. From >>> first glance it seems the tests need similar common functionality: >>> >>> http://cr.openjdk.java.net/~plevart/misc/SunReflectDataRaces/ >>> >>> Regards, Peter >> >> The test is already built like that: >> >> The part that finds the class names is encapsulated in an object which >> implements Iterable. >> >> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.02/ -> >> ClassNameJrtStreamBuilder >> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk8-00/ -> >> ClassNameStreamBuilder >> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk7.00/ -> >> ClassNameListBuilder >> >> The bulk of the test should be identical (well, almost identical since I >> only >> updated 9 after the reviews, and since 9 is the only one that needs the >> System ClassLoader)... I suppose we could extract these 3 classes and >> define >> a library class with something like: >> >> public static class ClassNameFinder { >> public static Iterable findAllClassNames() { >> jdk9 impl: return new ClassNameJrtStreamBuilder(); >> jdk8 impl: return new ClassNameStreamBuilder(); >> jdk7 impl: return new ClassNameListBuilder(); >> } >> } >> >> As it stands - this corresponds to the >> >> static Iterable listAllClassNames() >> >> factory method in each version of the test. >> >> >> best regards, >> >> -- daniel >> >>> >>>> >>>> On 05/12/14 00:36, David Holmes wrote: >>>>> Hi Daniel, >>>>> >>>>> I still find your use of the classloader very confusing. You talk >>>>> about >>>>> the defining loader but you never check the defining loader against >>>>> anything. In >>>>> >>>>> 146 static void checkFor(Class c, ClassLoader loader) { >>>>> >>>>> the loader variable is never used. And if loader is simply the >>>>> name of >>>>> the loader passed to forName, then it may not be the defining loader >>>>> anyway - so the whole use of this loader variable seems >>>>> superfluous at >>>>> best, and confusing/misleading at worst. And you can use the simple >>>>> forName(name) variant rather than passing a loader. >>>>> >>>>> David >>>>> >>>>> On 5/12/2014 3:13 AM, Daniel Fuchs wrote: >>>>>> On 04/12/14 14:02, Se?n Coffey wrote: >>>>>>> Thanks for driving efforts in this area Daniel. I think it's a very >>>>>>> useful test and is bound to help test code coverage. If it's >>>>>>> currently >>>>>>> passing on all JPRT platforms, it's a good measure. >>>>>> >>>>>> It seems to :-) >>>>>> >>>>>>> Eventually I think we can bulk up the tests that can be run on the >>>>>>> Iterable returned from your class search. >>>>>>> At moment you just test Field.setAccessible. >>>>>> >>>>>> Yes. If we change it later to test more, we will probably need to >>>>>> change its name. I was already in lack of inspiration: >>>>>> FieldSetAccessibleTest is not really a great name - but hopefully >>>>>> it can do for now. >>>>>> >>>>>>> In the future, I don't see any harm in adding all simple Field >>>>>>> method >>>>>>> calls so that any corner cases in custom classes like the original >>>>>>> issue >>>>>>> are caught. e.g Field.getDeclaredAnnotations(), >>>>>>> Field.getModifiers(), >>>>>>> Field.isEnumConstant() etc., etc. Some methods won't be much value >>>>>>> add >>>>>>> but they're not a cost either. >>>>>> >>>>>> Agreed. >>>>>> >>>>>>> Same argument for running through all Class methods, e.g >>>>>>> Class.getDeclaredClasses(), Class.getDeclaredMethods(). As a >>>>>>> result this >>>>>>> test might eventually become more general in test goal and might >>>>>>> live >>>>>>> better one level up in "test/java/lang/Class/" - it can be moved >>>>>>> when >>>>>>> the time comes. >>>>>> >>>>>> Agreed as well :-) >>>>>> >>>>>> Here is a new revision of the webrev for 9 in which I have >>>>>> incorporated David's comment: >>>>>> >>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.01/ >>>>>> >>>>>> best regards, >>>>>> >>>>>> -- daniel >>>>>> >>>>>>> >>>>>>> regards, >>>>>>> Sean. >>>>>>> >>>>>>> On 04/12/2014 12:25, Daniel Fuchs wrote: >>>>>>>> On 04/12/14 13:06, David Holmes wrote: >>>>>>>>> Hi Daniel, >>>>>>>>> >>>>>>>>> On 4/12/2014 9:38 PM, Daniel Fuchs wrote: >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>> In fact I could use 'null' on JDK 9 as well. >>>>>>>>>> My first version of the JDK 9 test was parsing over all the >>>>>>>>>> .jimage >>>>>>>>>> files under /lib/modules - which explain why I needed to >>>>>>>>>> use the System class loader. >>>>>>>>>> >>>>>>>>>> Then I switched to only parsing the bootmodules.jimage - because >>>>>>>>>> I noticed that the results where more coherent with what I had >>>>>>>>>> observed on 8 & 7 - but I kept using the System class loader. >>>>>>>>>> >>>>>>>>>> I am not sure whether we want the test for 9 should iterate over >>>>>>>>>> the three .jimage - or continue to test only the boot .jimage. >>>>>>>>>> >>>>>>>>>> I have updated the JDK 9 test (refreshed the webrev in place) >>>>>>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.00/ >>>>>>>>>> >>>>>>>>>> and added support for possibly running the test in the two modes >>>>>>>>>> (I added a 'test.boot.only' system property, true by default) >>>>>>>>>> as well as additional traces to print the loaded classes by >>>>>>>>>> defining loader at the end (test.list.classes, false by >>>>>>>>>> default). >>>>>>>>> >>>>>>>>> A couple of initial comments: >>>>>>>>> >>>>>>>>> 104 static ClassLoader getClassLoaderFor(String >>>>>>>>> classFileName) { >>>>>>>>> 105 if (restrictToBoot) return null; // only >>>>>>>>> bootmodules >>>>>>>>> 106 return ClassLoaders.systemClassLoader; >>>>>>>>> 107 } >>>>>>>>> >>>>>>>>> I'm not clear the intent here. If it is to return a loader for >>>>>>>>> which >>>>>>>>> loadClass could be invoked then you can always just return the >>>>>>>>> system >>>>>>>>> loader - or just Class.forName. If it is meant to the return the >>>>>>>>> expected defining loader then it isn't doing that as the >>>>>>>>> extensions >>>>>>>>> loader is not allowed for. >>>>>>>> >>>>>>>> The intent is to return the class loader that will be passed to >>>>>>>> Class.forName( ). I've been fiddling & experimenting with this >>>>>>>> test over 3 different platforms while trying to minimize the >>>>>>>> differences - so that was my attempt at having a good place to >>>>>>>> experiment with different strategy for loading classes. >>>>>>>> >>>>>>>>> Similarly for: >>>>>>>>> >>>>>>>>> 128 static ClassLoader getFor(String classFileName) { >>>>>>>>> 129 return systemClassLoader; >>>>>>>>> 130 } >>>>>>>> >>>>>>>> Oh - that's my mistake. In fact ClassLoader getClassLoaderFor(..) >>>>>>>> was supposed to simply return ClassLoaders.getFor(...); >>>>>>>> and all the code should be in ClassLoaders.getFor - my bad. >>>>>>>> >>>>>>>>> Minor nit - In: >>>>>>>>> >>>>>>>>> 135 System.err.println("Unexpected loader for >>>>>>>>> "+c+": >>>>>>>>> "+c.getClassLoader()); >>>>>>>>> >>>>>>>>> c.getClassLoader() can be replaced by cl. Also put spaces around >>>>>>>>> the + >>>>>>>>> operator. >>>>>>>> >>>>>>>> Good catch. >>>>>>>> >>>>>>>> Thanks a lot David! Have a good night! (that's quite late - isn't >>>>>>>> it?) >>>>>>>> >>>>>>>> -- daniel >>>>>>>> >>>>>>>>> >>>>>>>>> David >>>>>>>>> (signing off for the night) >>>>>>>>> >>>>>>>>>> Thanks for your question, it triggered me into looking deeper >>>>>>>>>> into what was happening :-) >>>>>>>>>> >>>>>>>>>> best regards, >>>>>>>>>> >>>>>>>>>> -- daniel >>>>>>>>>> >>>>>>>>>> On 04/12/14 10:05, Daniel Fuchs wrote: >>>>>>>>>>>>> The differences between 8 & 9 are limited to: >>>>>>>>>>>>> >>>>>>>>>>>>> - ClassLoader: >>>>>>>>>>>>> - on 8 we use 'null' (BCL) >>>>>>>>>>>>> - on 9 we use the system class loader. >>>>>>>>>>>> >>>>>>>>>>>> I haven't seen anything in JEP 220, regarding modules, that >>>>>>>>>>>> indicates >>>>>>>>>>>> that classes currently loaded by the boot-loader will now be >>>>>>>>>>>> loaded >>>>>>>>>>>> by the system classloader ??? >>>>>>>>>>> >>>>>>>>>>> In [1] towards the end: >>>>>>>>>>> >>>>>>>>>>> [1] http://openjdk.java.net/jeps/220 >>>>>>>>>>> >>>>>>>>>>> "The defining class loader of the types in some existing >>>>>>>>>>> packages >>>>>>>>>>> will change. Existing code that makes assumptions about the >>>>>>>>>>> class >>>>>>>>>>> loaders of these types might not work correctly." >>>>>>>>>>> (then there is a list of specific changes). >>>>>>>>>>> >>>>>>>>>>> This test looks up all class names in the image files and >>>>>>>>>>> attempt >>>>>>>>>>> to load the corresponding class. But as indicated in [1] >>>>>>>>>>> some of these classes are now in the Boot CL, some in the >>>>>>>>>>> Extension CL, and some in the Application CL. >>>>>>>>>>> >>>>>>>>>>> So the test uses the System CL to load each class - which >>>>>>>>>>> ensures >>>>>>>>>>> that the loading will be delegated to the appropriate >>>>>>>>>>> ClassLoader. >>>>>>>>>>> >>>>>>>>>>> best regards, >>>>>>>>>>> >>>>>>>>>>> -- daniel >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >>> >> > From lana.steuck at oracle.com Mon Dec 15 22:15:32 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 15 Dec 2014 14:15:32 -0800 (PST) Subject: jdk8u-b19: jdk8u-dev Message-ID: <201412152215.sBFMFW5t014199@jano-app.us.oracle.com> http://hg.openjdk.java.net/jdk8u/jdk8u/rev/ae4980d195b6 http://hg.openjdk.java.net/jdk8u/jdk8u/nashorn/rev/6ec61d249428 http://hg.openjdk.java.net/jdk8u/jdk8u/langtools/rev/0c514d1fd006 http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/5c31204d19e5 http://hg.openjdk.java.net/jdk8u/jdk8u/jaxws/rev/c8b402c28fe5 http://hg.openjdk.java.net/jdk8u/jdk8u/jaxp/rev/3b73732d6886 http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/57490e455c30 http://hg.openjdk.java.net/jdk8u/jdk8u/corba/rev/8bbc2bb414b7 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8065627 client-libs Animated GIFs fail to display on a HiDPI display JDK-8059998 client-libs Broken link in java.awt.event Interface KeyListener JDK-8024626 client-libs CTW CRASH: SIGSEGV in ctw/jre/lib/rt_jar/preloading_1 and ctw/jre/lib/rt_jar/sun_awt_X11_ListHelper JDK-8059942 client-libs Default implementation of DrawImage.renderImageXform() should be improved for d3d/ogl JDK-8029536 client-libs JFileChooser filter uses .toString() instead of getDescription() for filter text on GTK laf JDK-8058136 client-libs Test api/java_awt/SplashScreen/index.html\#ClosedSplashScreenTests fails because of java.lang.IllegalStateException was not thrown JDK-8066756 client-libs Test test/sun/awt/dnd/8024061/bug8024061.java fails JDK-8059944 client-libs [OGL] Metrics for a method choice copying of texture should be improved JDK-8066986 client-libs [headless] DataTransferer.getInstance throws ClassCastException in headless mode JDK-8057788 client-libs [macosx] "Pinch to zoom" does not work since jdk7 JDK-8031696 client-libs [macosx] TwentyThousandTest test failed with OOM JDK-8066142 client-libs closed/javax/swing/JComboBox/4212498/bug4212498.java:Edit the value in the text field and then press the tab key, the number don't increase JDK-8067136 core-libs BrowserJSObjectLinker does not handle call on JSObjects JDK-8065675 core-libs Deprecate the Endorsed-Standards Override Mechanism JDK-8065702 core-libs Deprecate the Extension Mechanism JDK-8066221 core-libs Fuzzing bug: Assertion error related to bytecode slots JDK-8066227 core-libs Fuzzing bug: CodeGenerator load unitialized slot JDK-8066236 core-libs Fuzzing bug: StackMapTable error: bad offset, ClassFormatError JDK-8066230 core-libs Fuzzing bug: Undefined object type assertion when computing TypeBounds JDK-8066224 core-libs Fuzzing bug: constant folding of ternary operator and IfNode with constant test JDK-8066225 core-libs Fuzzing bug: duplicate integer switch cases JDK-8057020 core-libs LambdaForm caches should support eviction JDK-8065991 core-libs LogManager unecessarily calls JavaAWTAccess from within a critical section JDK-8066746 core-libs MHs.explicitCastArguments does incorrect type checks for VarargsCollector JDK-8067219 core-libs NPE in ScriptObject.clone() when running with object fields JDK-8065769 core-libs OOM on Window/Solaris in test compile-octane-splitter.js JDK-8066397 core-libs Remove network-related seed initialization code in ThreadLocal/SplittableRandom JDK-8059070 core-libs [TESTBUG] java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java failed - timeout JDK-8066932 core-libs __noSuchMethod__ binds to this-object without proper guard JDK-8066669 core-libs dust.js performance regression caused by primitive field conversion JDK-8043477 core-libs java/lang/ProcessBuilder/Basic.java failed with: java.lang.AssertionError: Some tests failed JDK-8065238 core-libs javax.naming.NamingException after upgrade to JDK 8 JDK-8066146 core-libs jdk.nashorn.api.scripting package javadoc should be included in jdk docs JDK-8065552 core-libs setAccessible(true) on fields of Class may throw a SecurityException JDK-8065072 core-libs sun/net/www/http/HttpClient/StreamingRetry.java failed intermittently JDK-8065764 core-svc javax/management/monitor/CounterMonitorTest.java hangs JDK-8065157 globalization jdk8u40 Japanese man page file translation update JDK-8057629 infrastructure Update THIRD_PARTY_LICENSE_README for 8u40 JDK-8066500 other-libs CMM / ResMan JavaDoc: links to core SE APIs are broken JDK-8067039 tools Revert changes to annotation attribute generation From sean.coffey at oracle.com Mon Dec 15 22:55:49 2014 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Mon, 15 Dec 2014 22:55:49 +0000 Subject: (JDK-8064407) Backporting the FileChannel.transferTo (Windows) improvement to JDK 8 In-Reply-To: References: Message-ID: <548F66F5.3090608@oracle.com> Martin, This shouldn't be a problem. I can sponsor this one also for you. I'll try importing the JDK 9 patch (post path changes). If it applies cleanly, we shouldn't need a review. Hope to get to this on Tuesday. Regards, Sean. On 15/12/2014 13:01, Martin Sawicki (MS OPEN TECH) wrote: > Hello, > > We'd like to propose to backport our FileChannel.transferTo() performance improvement for Windows that was recently accepted into JDK9 to JDK8: > > (JDK9 fix for reference: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ba6d8f56003b) > > > > Our suggested webrev patch is attached. > > Your review and acceptance of this contribution would be appreciated. > > > > Best regards, > > Martin Sawicki (and Kirk Shoop, and Valeriy Kopylov) Microsoft Open Technologies, Inc. > > A subsidiary of Microsoft Corp. > From david.holmes at oracle.com Tue Dec 16 05:20:55 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 16 Dec 2014 15:20:55 +1000 Subject: [9 + 8u] RFR - 8066612: Add a test that will call getDeclaredFields() on all classes and try to set them accessible. In-Reply-To: <548F1EF4.1040007@oracle.com> References: <547F9302.3060309@oracle.com> <547FD6F2.5060400@oracle.com> <548023D0.4020702@oracle.com> <548047C3.8000400@oracle.com> <54804E4B.2070908@oracle.com> <5480529F.1020902@oracle.com> <54805B5D.5020504@oracle.com> <54809627.8070103@oracle.com> <5480EFE8.3090809@oracle.com> <5482105D.40005@oracle.com> <5482D77C.9030100@gmail.com> <5482DE1F.5070906@oracle.com> <548F1EF4.1040007@oracle.com> Message-ID: <548FC137.1080209@oracle.com> On 16/12/2014 3:48 AM, Daniel Fuchs wrote: > Hi guys, > > Do I have approval to push the latest version of the test for JDK 9: > http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.02/ > or are there still some objections? My objections stand - the classloader aspect of the test is overly complicated and not achieving anything. David > best regards, > > -- daniel > > > On 06/12/14 11:44, Daniel Fuchs wrote: >> Hi Peter, >> >> >> On 12/6/14 11:16 AM, Peter Levart wrote: >>> >>> On 12/05/2014 09:06 PM, Daniel Fuchs wrote: >>>> Hi David, all, >>>> >>>> @David: You're right David. >>>> The loader parameter is never used - I have removed it. >>>> >>>> @all: I have received a comment from Alan that it would be better to >>>> use >>>> the new jrt:/ FileSystem directly, rather than using private >>>> APIs. >>>> One of the consequence is that the test now loads all the >>>> classes in the runtime image (not just the ones in the BCL), >>>> and therefore I have removed the toggle that allowed to test >>>> the boot classes only. >>>> >>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.02/ >>>> >>>> best regards, >>>> >>>> -- daniel >>> >>> Hi Daniel, >>> >>> Would it be possible to extract a minimal API for streaming over >>> classes and put that into the testlib so that only this part differs >>> between JDK8 and JDK9 and the guts of the test is identical for both >>> JDK8 and JDK9 ? >>> >>> This would ease backport efforts when the test(s) are later "beefed >>> up" with other functionality. The API could later be extended with >>> other functionality, but just for illustration what might be needed, >>> here's what Martin Buchholz started as a test for finding possible >>> data races in reflection and I just re-packed using Streams. From >>> first glance it seems the tests need similar common functionality: >>> >>> http://cr.openjdk.java.net/~plevart/misc/SunReflectDataRaces/ >>> >>> Regards, Peter >> >> The test is already built like that: >> >> The part that finds the class names is encapsulated in an object which >> implements Iterable. >> >> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.02/ -> >> ClassNameJrtStreamBuilder >> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk8-00/ -> >> ClassNameStreamBuilder >> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk7.00/ -> >> ClassNameListBuilder >> >> The bulk of the test should be identical (well, almost identical since I >> only >> updated 9 after the reviews, and since 9 is the only one that needs the >> System ClassLoader)... I suppose we could extract these 3 classes and >> define >> a library class with something like: >> >> public static class ClassNameFinder { >> public static Iterable findAllClassNames() { >> jdk9 impl: return new ClassNameJrtStreamBuilder(); >> jdk8 impl: return new ClassNameStreamBuilder(); >> jdk7 impl: return new ClassNameListBuilder(); >> } >> } >> >> As it stands - this corresponds to the >> >> static Iterable listAllClassNames() >> >> factory method in each version of the test. >> >> >> best regards, >> >> -- daniel >> >>> >>>> >>>> On 05/12/14 00:36, David Holmes wrote: >>>>> Hi Daniel, >>>>> >>>>> I still find your use of the classloader very confusing. You talk >>>>> about >>>>> the defining loader but you never check the defining loader against >>>>> anything. In >>>>> >>>>> 146 static void checkFor(Class c, ClassLoader loader) { >>>>> >>>>> the loader variable is never used. And if loader is simply the name of >>>>> the loader passed to forName, then it may not be the defining loader >>>>> anyway - so the whole use of this loader variable seems superfluous at >>>>> best, and confusing/misleading at worst. And you can use the simple >>>>> forName(name) variant rather than passing a loader. >>>>> >>>>> David >>>>> >>>>> On 5/12/2014 3:13 AM, Daniel Fuchs wrote: >>>>>> On 04/12/14 14:02, Se?n Coffey wrote: >>>>>>> Thanks for driving efforts in this area Daniel. I think it's a very >>>>>>> useful test and is bound to help test code coverage. If it's >>>>>>> currently >>>>>>> passing on all JPRT platforms, it's a good measure. >>>>>> >>>>>> It seems to :-) >>>>>> >>>>>>> Eventually I think we can bulk up the tests that can be run on the >>>>>>> Iterable returned from your class search. >>>>>>> At moment you just test Field.setAccessible. >>>>>> >>>>>> Yes. If we change it later to test more, we will probably need to >>>>>> change its name. I was already in lack of inspiration: >>>>>> FieldSetAccessibleTest is not really a great name - but hopefully >>>>>> it can do for now. >>>>>> >>>>>>> In the future, I don't see any harm in adding all simple Field >>>>>>> method >>>>>>> calls so that any corner cases in custom classes like the original >>>>>>> issue >>>>>>> are caught. e.g Field.getDeclaredAnnotations(), >>>>>>> Field.getModifiers(), >>>>>>> Field.isEnumConstant() etc., etc. Some methods won't be much value >>>>>>> add >>>>>>> but they're not a cost either. >>>>>> >>>>>> Agreed. >>>>>> >>>>>>> Same argument for running through all Class methods, e.g >>>>>>> Class.getDeclaredClasses(), Class.getDeclaredMethods(). As a >>>>>>> result this >>>>>>> test might eventually become more general in test goal and might >>>>>>> live >>>>>>> better one level up in "test/java/lang/Class/" - it can be moved >>>>>>> when >>>>>>> the time comes. >>>>>> >>>>>> Agreed as well :-) >>>>>> >>>>>> Here is a new revision of the webrev for 9 in which I have >>>>>> incorporated David's comment: >>>>>> >>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.01/ >>>>>> >>>>>> best regards, >>>>>> >>>>>> -- daniel >>>>>> >>>>>>> >>>>>>> regards, >>>>>>> Sean. >>>>>>> >>>>>>> On 04/12/2014 12:25, Daniel Fuchs wrote: >>>>>>>> On 04/12/14 13:06, David Holmes wrote: >>>>>>>>> Hi Daniel, >>>>>>>>> >>>>>>>>> On 4/12/2014 9:38 PM, Daniel Fuchs wrote: >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>> In fact I could use 'null' on JDK 9 as well. >>>>>>>>>> My first version of the JDK 9 test was parsing over all the >>>>>>>>>> .jimage >>>>>>>>>> files under /lib/modules - which explain why I needed to >>>>>>>>>> use the System class loader. >>>>>>>>>> >>>>>>>>>> Then I switched to only parsing the bootmodules.jimage - because >>>>>>>>>> I noticed that the results where more coherent with what I had >>>>>>>>>> observed on 8 & 7 - but I kept using the System class loader. >>>>>>>>>> >>>>>>>>>> I am not sure whether we want the test for 9 should iterate over >>>>>>>>>> the three .jimage - or continue to test only the boot .jimage. >>>>>>>>>> >>>>>>>>>> I have updated the JDK 9 test (refreshed the webrev in place) >>>>>>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.00/ >>>>>>>>>> and added support for possibly running the test in the two modes >>>>>>>>>> (I added a 'test.boot.only' system property, true by default) >>>>>>>>>> as well as additional traces to print the loaded classes by >>>>>>>>>> defining loader at the end (test.list.classes, false by default). >>>>>>>>> >>>>>>>>> A couple of initial comments: >>>>>>>>> >>>>>>>>> 104 static ClassLoader getClassLoaderFor(String >>>>>>>>> classFileName) { >>>>>>>>> 105 if (restrictToBoot) return null; // only bootmodules >>>>>>>>> 106 return ClassLoaders.systemClassLoader; >>>>>>>>> 107 } >>>>>>>>> >>>>>>>>> I'm not clear the intent here. If it is to return a loader for >>>>>>>>> which >>>>>>>>> loadClass could be invoked then you can always just return the >>>>>>>>> system >>>>>>>>> loader - or just Class.forName. If it is meant to the return the >>>>>>>>> expected defining loader then it isn't doing that as the >>>>>>>>> extensions >>>>>>>>> loader is not allowed for. >>>>>>>> >>>>>>>> The intent is to return the class loader that will be passed to >>>>>>>> Class.forName( ). I've been fiddling & experimenting with this >>>>>>>> test over 3 different platforms while trying to minimize the >>>>>>>> differences - so that was my attempt at having a good place to >>>>>>>> experiment with different strategy for loading classes. >>>>>>>> >>>>>>>>> Similarly for: >>>>>>>>> >>>>>>>>> 128 static ClassLoader getFor(String classFileName) { >>>>>>>>> 129 return systemClassLoader; >>>>>>>>> 130 } >>>>>>>> >>>>>>>> Oh - that's my mistake. In fact ClassLoader getClassLoaderFor(..) >>>>>>>> was supposed to simply return ClassLoaders.getFor(...); >>>>>>>> and all the code should be in ClassLoaders.getFor - my bad. >>>>>>>> >>>>>>>>> Minor nit - In: >>>>>>>>> >>>>>>>>> 135 System.err.println("Unexpected loader for >>>>>>>>> "+c+": >>>>>>>>> "+c.getClassLoader()); >>>>>>>>> >>>>>>>>> c.getClassLoader() can be replaced by cl. Also put spaces around >>>>>>>>> the + >>>>>>>>> operator. >>>>>>>> >>>>>>>> Good catch. >>>>>>>> >>>>>>>> Thanks a lot David! Have a good night! (that's quite late - isn't >>>>>>>> it?) >>>>>>>> >>>>>>>> -- daniel >>>>>>>> >>>>>>>>> >>>>>>>>> David >>>>>>>>> (signing off for the night) >>>>>>>>> >>>>>>>>>> Thanks for your question, it triggered me into looking deeper >>>>>>>>>> into what was happening :-) >>>>>>>>>> >>>>>>>>>> best regards, >>>>>>>>>> >>>>>>>>>> -- daniel >>>>>>>>>> >>>>>>>>>> On 04/12/14 10:05, Daniel Fuchs wrote: >>>>>>>>>>>>> The differences between 8 & 9 are limited to: >>>>>>>>>>>>> >>>>>>>>>>>>> - ClassLoader: >>>>>>>>>>>>> - on 8 we use 'null' (BCL) >>>>>>>>>>>>> - on 9 we use the system class loader. >>>>>>>>>>>> >>>>>>>>>>>> I haven't seen anything in JEP 220, regarding modules, that >>>>>>>>>>>> indicates >>>>>>>>>>>> that classes currently loaded by the boot-loader will now be >>>>>>>>>>>> loaded >>>>>>>>>>>> by the system classloader ??? >>>>>>>>>>> >>>>>>>>>>> In [1] towards the end: >>>>>>>>>>> >>>>>>>>>>> [1] http://openjdk.java.net/jeps/220 >>>>>>>>>>> >>>>>>>>>>> "The defining class loader of the types in some existing >>>>>>>>>>> packages >>>>>>>>>>> will change. Existing code that makes assumptions about the >>>>>>>>>>> class >>>>>>>>>>> loaders of these types might not work correctly." >>>>>>>>>>> (then there is a list of specific changes). >>>>>>>>>>> >>>>>>>>>>> This test looks up all class names in the image files and >>>>>>>>>>> attempt >>>>>>>>>>> to load the corresponding class. But as indicated in [1] >>>>>>>>>>> some of these classes are now in the Boot CL, some in the >>>>>>>>>>> Extension CL, and some in the Application CL. >>>>>>>>>>> >>>>>>>>>>> So the test uses the System CL to load each class - which >>>>>>>>>>> ensures >>>>>>>>>>> that the loading will be delegated to the appropriate >>>>>>>>>>> ClassLoader. >>>>>>>>>>> >>>>>>>>>>> best regards, >>>>>>>>>>> >>>>>>>>>>> -- daniel >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >>> >> > From daniel.fuchs at oracle.com Tue Dec 16 10:34:43 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 16 Dec 2014 11:34:43 +0100 Subject: [9 + 8u] RFR - 8066612: Add a test that will call getDeclaredFields() on all classes and try to set them accessible. In-Reply-To: <548FC137.1080209@oracle.com> References: <547F9302.3060309@oracle.com> <547FD6F2.5060400@oracle.com> <548023D0.4020702@oracle.com> <548047C3.8000400@oracle.com> <54804E4B.2070908@oracle.com> <5480529F.1020902@oracle.com> <54805B5D.5020504@oracle.com> <54809627.8070103@oracle.com> <5480EFE8.3090809@oracle.com> <5482105D.40005@oracle.com> <5482D77C.9030100@gmail.com> <5482DE1F.5070906@oracle.com> <548F1EF4.1040007@oracle.com> <548FC137.1080209@oracle.com> Message-ID: <54900AC3.4060208@oracle.com> Hi David, On 12/16/14 6:20 AM, David Holmes wrote: > On 16/12/2014 3:48 AM, Daniel Fuchs wrote: >> Hi guys, >> >> Do I have approval to push the latest version of the test for JDK 9: >> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.02/ >> or are there still some objections? > > My objections stand - the classloader aspect of the test is overly > complicated and not achieving anything. I see. Sorry for misunderstanding. See below: On 12/5/14 12:36 AM, David Holmes wrote: > the loader variable is never used. And if loader is simply the name of > the loader passed to forName, then it may not be the defining loader > anyway - so the whole use of this loader variable seems superfluous at > best, and confusing/misleading at worst. And you can use the simple > forName(name) variant rather than passing a loader. - I thought your objection was only with the loader argument in checkClassLoaderFor, which I removed in webrev-jdk9.02. I have prepared a new webrev. - Using the simple Class.forName(name) is not an option because it forces the static initializers to run at class loading. I don't think we want that in this test. Here is a new version where I have removed all the 'ClassLoaders' stuff. After all it was not instrumental to the test. Is that good to go? best regards, -- daniel > > David > >> best regards, >> >> -- daniel >> >> >> On 06/12/14 11:44, Daniel Fuchs wrote: >>> Hi Peter, >>> >>> >>> On 12/6/14 11:16 AM, Peter Levart wrote: >>>> >>>> On 12/05/2014 09:06 PM, Daniel Fuchs wrote: >>>>> Hi David, all, >>>>> >>>>> @David: You're right David. >>>>> The loader parameter is never used - I have removed it. >>>>> >>>>> @all: I have received a comment from Alan that it would be better to >>>>> use >>>>> the new jrt:/ FileSystem directly, rather than using private >>>>> APIs. >>>>> One of the consequence is that the test now loads all the >>>>> classes in the runtime image (not just the ones in the BCL), >>>>> and therefore I have removed the toggle that allowed to test >>>>> the boot classes only. >>>>> >>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.02/ >>>>> >>>>> best regards, >>>>> >>>>> -- daniel >>>> >>>> Hi Daniel, >>>> >>>> Would it be possible to extract a minimal API for streaming over >>>> classes and put that into the testlib so that only this part differs >>>> between JDK8 and JDK9 and the guts of the test is identical for both >>>> JDK8 and JDK9 ? >>>> >>>> This would ease backport efforts when the test(s) are later "beefed >>>> up" with other functionality. The API could later be extended with >>>> other functionality, but just for illustration what might be needed, >>>> here's what Martin Buchholz started as a test for finding possible >>>> data races in reflection and I just re-packed using Streams. From >>>> first glance it seems the tests need similar common functionality: >>>> >>>> http://cr.openjdk.java.net/~plevart/misc/SunReflectDataRaces/ >>>> >>>> Regards, Peter >>> >>> The test is already built like that: >>> >>> The part that finds the class names is encapsulated in an object which >>> implements Iterable. >>> >>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.02/ -> >>> ClassNameJrtStreamBuilder >>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk8-00/ -> >>> ClassNameStreamBuilder >>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk7.00/ -> >>> ClassNameListBuilder >>> >>> The bulk of the test should be identical (well, almost identical >>> since I >>> only >>> updated 9 after the reviews, and since 9 is the only one that needs the >>> System ClassLoader)... I suppose we could extract these 3 classes and >>> define >>> a library class with something like: >>> >>> public static class ClassNameFinder { >>> public static Iterable findAllClassNames() { >>> jdk9 impl: return new ClassNameJrtStreamBuilder(); >>> jdk8 impl: return new ClassNameStreamBuilder(); >>> jdk7 impl: return new ClassNameListBuilder(); >>> } >>> } >>> >>> As it stands - this corresponds to the >>> >>> static Iterable listAllClassNames() >>> >>> factory method in each version of the test. >>> >>> >>> best regards, >>> >>> -- daniel >>> >>>> >>>>> >>>>> On 05/12/14 00:36, David Holmes wrote: >>>>>> Hi Daniel, >>>>>> >>>>>> I still find your use of the classloader very confusing. You talk >>>>>> about >>>>>> the defining loader but you never check the defining loader against >>>>>> anything. In >>>>>> >>>>>> 146 static void checkFor(Class c, ClassLoader loader) { >>>>>> >>>>>> the loader variable is never used. And if loader is simply the >>>>>> name of >>>>>> the loader passed to forName, then it may not be the defining loader >>>>>> anyway - so the whole use of this loader variable seems >>>>>> superfluous at >>>>>> best, and confusing/misleading at worst. And you can use the simple >>>>>> forName(name) variant rather than passing a loader. >>>>>> >>>>>> David >>>>>> >>>>>> On 5/12/2014 3:13 AM, Daniel Fuchs wrote: >>>>>>> On 04/12/14 14:02, Se?n Coffey wrote: >>>>>>>> Thanks for driving efforts in this area Daniel. I think it's a >>>>>>>> very >>>>>>>> useful test and is bound to help test code coverage. If it's >>>>>>>> currently >>>>>>>> passing on all JPRT platforms, it's a good measure. >>>>>>> >>>>>>> It seems to :-) >>>>>>> >>>>>>>> Eventually I think we can bulk up the tests that can be run on the >>>>>>>> Iterable returned from your class search. >>>>>>>> At moment you just test Field.setAccessible. >>>>>>> >>>>>>> Yes. If we change it later to test more, we will probably need to >>>>>>> change its name. I was already in lack of inspiration: >>>>>>> FieldSetAccessibleTest is not really a great name - but hopefully >>>>>>> it can do for now. >>>>>>> >>>>>>>> In the future, I don't see any harm in adding all simple Field >>>>>>>> method >>>>>>>> calls so that any corner cases in custom classes like the original >>>>>>>> issue >>>>>>>> are caught. e.g Field.getDeclaredAnnotations(), >>>>>>>> Field.getModifiers(), >>>>>>>> Field.isEnumConstant() etc., etc. Some methods won't be much value >>>>>>>> add >>>>>>>> but they're not a cost either. >>>>>>> >>>>>>> Agreed. >>>>>>> >>>>>>>> Same argument for running through all Class methods, e.g >>>>>>>> Class.getDeclaredClasses(), Class.getDeclaredMethods(). As a >>>>>>>> result this >>>>>>>> test might eventually become more general in test goal and might >>>>>>>> live >>>>>>>> better one level up in "test/java/lang/Class/" - it can be moved >>>>>>>> when >>>>>>>> the time comes. >>>>>>> >>>>>>> Agreed as well :-) >>>>>>> >>>>>>> Here is a new revision of the webrev for 9 in which I have >>>>>>> incorporated David's comment: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.01/ >>>>>>> >>>>>>> best regards, >>>>>>> >>>>>>> -- daniel >>>>>>> >>>>>>>> >>>>>>>> regards, >>>>>>>> Sean. >>>>>>>> >>>>>>>> On 04/12/2014 12:25, Daniel Fuchs wrote: >>>>>>>>> On 04/12/14 13:06, David Holmes wrote: >>>>>>>>>> Hi Daniel, >>>>>>>>>> >>>>>>>>>> On 4/12/2014 9:38 PM, Daniel Fuchs wrote: >>>>>>>>>>> Hi David, >>>>>>>>>>> >>>>>>>>>>> In fact I could use 'null' on JDK 9 as well. >>>>>>>>>>> My first version of the JDK 9 test was parsing over all the >>>>>>>>>>> .jimage >>>>>>>>>>> files under /lib/modules - which explain why I needed to >>>>>>>>>>> use the System class loader. >>>>>>>>>>> >>>>>>>>>>> Then I switched to only parsing the bootmodules.jimage - >>>>>>>>>>> because >>>>>>>>>>> I noticed that the results where more coherent with what I had >>>>>>>>>>> observed on 8 & 7 - but I kept using the System class loader. >>>>>>>>>>> >>>>>>>>>>> I am not sure whether we want the test for 9 should iterate >>>>>>>>>>> over >>>>>>>>>>> the three .jimage - or continue to test only the boot .jimage. >>>>>>>>>>> >>>>>>>>>>> I have updated the JDK 9 test (refreshed the webrev in place) >>>>>>>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.00/ >>>>>>>>>>> >>>>>>>>>>> and added support for possibly running the test in the two >>>>>>>>>>> modes >>>>>>>>>>> (I added a 'test.boot.only' system property, true by default) >>>>>>>>>>> as well as additional traces to print the loaded classes by >>>>>>>>>>> defining loader at the end (test.list.classes, false by >>>>>>>>>>> default). >>>>>>>>>> >>>>>>>>>> A couple of initial comments: >>>>>>>>>> >>>>>>>>>> 104 static ClassLoader getClassLoaderFor(String >>>>>>>>>> classFileName) { >>>>>>>>>> 105 if (restrictToBoot) return null; // only >>>>>>>>>> bootmodules >>>>>>>>>> 106 return ClassLoaders.systemClassLoader; >>>>>>>>>> 107 } >>>>>>>>>> >>>>>>>>>> I'm not clear the intent here. If it is to return a loader for >>>>>>>>>> which >>>>>>>>>> loadClass could be invoked then you can always just return the >>>>>>>>>> system >>>>>>>>>> loader - or just Class.forName. If it is meant to the return the >>>>>>>>>> expected defining loader then it isn't doing that as the >>>>>>>>>> extensions >>>>>>>>>> loader is not allowed for. >>>>>>>>> >>>>>>>>> The intent is to return the class loader that will be passed to >>>>>>>>> Class.forName( ). I've been fiddling & experimenting with this >>>>>>>>> test over 3 different platforms while trying to minimize the >>>>>>>>> differences - so that was my attempt at having a good place to >>>>>>>>> experiment with different strategy for loading classes. >>>>>>>>> >>>>>>>>>> Similarly for: >>>>>>>>>> >>>>>>>>>> 128 static ClassLoader getFor(String classFileName) { >>>>>>>>>> 129 return systemClassLoader; >>>>>>>>>> 130 } >>>>>>>>> >>>>>>>>> Oh - that's my mistake. In fact ClassLoader getClassLoaderFor(..) >>>>>>>>> was supposed to simply return ClassLoaders.getFor(...); >>>>>>>>> and all the code should be in ClassLoaders.getFor - my bad. >>>>>>>>> >>>>>>>>>> Minor nit - In: >>>>>>>>>> >>>>>>>>>> 135 System.err.println("Unexpected loader for >>>>>>>>>> "+c+": >>>>>>>>>> "+c.getClassLoader()); >>>>>>>>>> >>>>>>>>>> c.getClassLoader() can be replaced by cl. Also put spaces around >>>>>>>>>> the + >>>>>>>>>> operator. >>>>>>>>> >>>>>>>>> Good catch. >>>>>>>>> >>>>>>>>> Thanks a lot David! Have a good night! (that's quite late - isn't >>>>>>>>> it?) >>>>>>>>> >>>>>>>>> -- daniel >>>>>>>>> >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> (signing off for the night) >>>>>>>>>> >>>>>>>>>>> Thanks for your question, it triggered me into looking deeper >>>>>>>>>>> into what was happening :-) >>>>>>>>>>> >>>>>>>>>>> best regards, >>>>>>>>>>> >>>>>>>>>>> -- daniel >>>>>>>>>>> >>>>>>>>>>> On 04/12/14 10:05, Daniel Fuchs wrote: >>>>>>>>>>>>>> The differences between 8 & 9 are limited to: >>>>>>>>>>>>>> >>>>>>>>>>>>>> - ClassLoader: >>>>>>>>>>>>>> - on 8 we use 'null' (BCL) >>>>>>>>>>>>>> - on 9 we use the system class loader. >>>>>>>>>>>>> >>>>>>>>>>>>> I haven't seen anything in JEP 220, regarding modules, that >>>>>>>>>>>>> indicates >>>>>>>>>>>>> that classes currently loaded by the boot-loader will now be >>>>>>>>>>>>> loaded >>>>>>>>>>>>> by the system classloader ??? >>>>>>>>>>>> >>>>>>>>>>>> In [1] towards the end: >>>>>>>>>>>> >>>>>>>>>>>> [1] http://openjdk.java.net/jeps/220 >>>>>>>>>>>> >>>>>>>>>>>> "The defining class loader of the types in some existing >>>>>>>>>>>> packages >>>>>>>>>>>> will change. Existing code that makes assumptions about the >>>>>>>>>>>> class >>>>>>>>>>>> loaders of these types might not work correctly." >>>>>>>>>>>> (then there is a list of specific changes). >>>>>>>>>>>> >>>>>>>>>>>> This test looks up all class names in the image files and >>>>>>>>>>>> attempt >>>>>>>>>>>> to load the corresponding class. But as indicated in [1] >>>>>>>>>>>> some of these classes are now in the Boot CL, some in the >>>>>>>>>>>> Extension CL, and some in the Application CL. >>>>>>>>>>>> >>>>>>>>>>>> So the test uses the System CL to load each class - which >>>>>>>>>>>> ensures >>>>>>>>>>>> that the loading will be delegated to the appropriate >>>>>>>>>>>> ClassLoader. >>>>>>>>>>>> >>>>>>>>>>>> best regards, >>>>>>>>>>>> >>>>>>>>>>>> -- daniel >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >>> >> From daniel.fuchs at oracle.com Tue Dec 16 10:36:42 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 16 Dec 2014 11:36:42 +0100 Subject: [9 + 8u] RFR - 8066612: Add a test that will call getDeclaredFields() on all classes and try to set them accessible. In-Reply-To: <54900AC3.4060208@oracle.com> References: <547F9302.3060309@oracle.com> <547FD6F2.5060400@oracle.com> <548023D0.4020702@oracle.com> <548047C3.8000400@oracle.com> <54804E4B.2070908@oracle.com> <5480529F.1020902@oracle.com> <54805B5D.5020504@oracle.com> <54809627.8070103@oracle.com> <5480EFE8.3090809@oracle.com> <5482105D.40005@oracle.com> <5482D77C.9030100@gmail.com> <5482DE1F.5070906@oracle.com> <548F1EF4.1040007@oracle.com> <548FC137.1080209@oracle.com> <54900AC3.4060208@oracle.com> Message-ID: <54900B3A.7070703@oracle.com> On 16/12/14 11:34, Daniel Fuchs wrote: > Here is a new version where I have removed all the 'ClassLoaders' stuff. > After all > it was not instrumental to the test. Is that good to go? Forgot the link: http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.03/ sorry for the noise. -- daniel From david.holmes at oracle.com Tue Dec 16 12:01:11 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 16 Dec 2014 22:01:11 +1000 Subject: [9 + 8u] RFR - 8066612: Add a test that will call getDeclaredFields() on all classes and try to set them accessible. In-Reply-To: <54900B3A.7070703@oracle.com> References: <547F9302.3060309@oracle.com> <547FD6F2.5060400@oracle.com> <548023D0.4020702@oracle.com> <548047C3.8000400@oracle.com> <54804E4B.2070908@oracle.com> <5480529F.1020902@oracle.com> <54805B5D.5020504@oracle.com> <54809627.8070103@oracle.com> <5480EFE8.3090809@oracle.com> <5482105D.40005@oracle.com> <5482D77C.9030100@gmail.com> <5482DE1F.5070906@oracle.com> <548F1EF4.1040007@oracle.com> <548FC137.1080209@oracle.com> <54900AC3.4060208@oracle.com> <54900B3A.7070703@oracle.com> Message-ID: <54901F07.5010301@oracle.com> Hi Daniel, Thumbs up from me! Thanks, David On 16/12/2014 8:36 PM, Daniel Fuchs wrote: > On 16/12/14 11:34, Daniel Fuchs wrote: >> Here is a new version where I have removed all the 'ClassLoaders' stuff. >> After all >> it was not instrumental to the test. Is that good to go? > > Forgot the link: > > http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.03/ > > sorry for the noise. > > -- daniel > From sean.coffey at oracle.com Tue Dec 16 17:24:01 2014 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Tue, 16 Dec 2014 17:24:01 +0000 Subject: [8u-dev] Request for review and approval : 8060170 & 8064407 Message-ID: <54906AB1.8040901@oracle.com> Requesting to backport these two enhancements to jdk8u-dev as per request from Martin Sawicki. 8060170: Support SIO_LOOPBACK_FAST_PATH option on Windows JDK 9 changeset : http://hg.openjdk.java.net/jdk9/dev/jdk/rev/26e6402772c8 review thread : http://mail.openjdk.java.net/pipermail/nio-dev/2014-October/002797.html 8064407: (fc) FileChannel transferTo should use TransmitFile on Windows JDK 9 changeset : http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ba6d8f56003b review thread : http://mail.openjdk.java.net/pipermail/nio-dev/2014-November/002824.html There was a minor patch import problem with 8064407 (post unshuffling). The src/java.base/windows/classes/sun/nio/ch/FileDispatcherImpl.java source differs slightly. (append flag removed/modified in JDK 9) Only the first hunk failed. Nothing major. I've posted jdk8u-dev webrev to here : http://cr.openjdk.java.net/~coffeys/webrev.MSBackports.8u/webrev/ Would be good if you can review Alan. JPRT build & tests are green. regards, Sean. From rob.mckenna at oracle.com Tue Dec 16 17:31:57 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 16 Dec 2014 17:31:57 +0000 Subject: [8u-dev] Request for review and approval : 8060170 & 8064407 In-Reply-To: <54906AB1.8040901@oracle.com> References: <54906AB1.8040901@oracle.com> Message-ID: <54906C8D.5020507@oracle.com> Approved pending review. -Rob On 16/12/14 17:24, Se?n Coffey wrote: > Requesting to backport these two enhancements to jdk8u-dev as per > request from Martin Sawicki. > > 8060170: Support SIO_LOOPBACK_FAST_PATH option on Windows > JDK 9 changeset : > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/26e6402772c8 > review thread : > http://mail.openjdk.java.net/pipermail/nio-dev/2014-October/002797.html > > 8064407: (fc) FileChannel transferTo should use TransmitFile on Windows > JDK 9 changeset : > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ba6d8f56003b > review thread : > http://mail.openjdk.java.net/pipermail/nio-dev/2014-November/002824.html > > There was a minor patch import problem with 8064407 (post > unshuffling). The > src/java.base/windows/classes/sun/nio/ch/FileDispatcherImpl.java > source differs slightly. (append flag removed/modified in JDK 9) Only > the first hunk failed. Nothing major. > > I've posted jdk8u-dev webrev to here : > http://cr.openjdk.java.net/~coffeys/webrev.MSBackports.8u/webrev/ > Would be good if you can review Alan. JPRT build & tests are green. > > regards, > Sean. > > From alejandro.murillo at oracle.com Tue Dec 16 18:02:02 2014 From: alejandro.murillo at oracle.com (alejandro murillo) Date: Tue, 16 Dec 2014 11:02:02 -0700 Subject: jdk8u40-b19: HotSpot Message-ID: <5490739A.9050601@oracle.com> hs25.40-b23 has been integrated into jdk8u40-b19. http://hg.openjdk.java.net/jdk8u/jdk8u/rev/ae4980d195b6 http://hg.openjdk.java.net/jdk8u/jdk8u/corba/rev/8bbc2bb414b7 http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/d9349fa88223 http://hg.openjdk.java.net/jdk8u/jdk8u/jaxp/rev/3b73732d6886 http://hg.openjdk.java.net/jdk8u/jdk8u/jaxws/rev/c8b402c28fe5 http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/5c31204d19e5 http://hg.openjdk.java.net/jdk8u/jdk8u/langtools/rev/0c514d1fd006 http://hg.openjdk.java.net/jdk8u/jdk8u/nashorn/rev/6ec61d249428 Component : VM Status : 0 major failures, 1 minor failures Date : 16/12/2014 at 18:00 MSK Tested By : STT_VM Cost(total man-days): 1 Workspace : 2014-12-12-183515.amurillo.hs25-40-b23-snapshot Bundles : 2014-12-12-183515.amurillo.hs25-40-b23-snapshot Platforms : Others Tests :/net/sqenfs-1.sfbay/export1/comp/vm/testbase/ Log : link Browsers : NA Patches : NA Number of Tests Executed : 392232 passed tests, 3550 failed tests (no new failures) Bug verification status: ====================================== Tested, Pass: Tested, Pass (partial fixes): Tested, Fail: Untested bug fixes: 6898462: The escape analysis with G1 cause crash assertion src/share/vm/runtime/vframeArray.cpp:94 8048170: Test closed/java/text/Normalizer/ConformanceTest.java failed 8065634: Crash in InstanceKlass::clean_method_data when _method is NULL 8066103: C2's range check smearing allows out of bound array accesses 8066647: new hotspot build - hs25.40-b23 8066670: PrintSharedArchiveAndExit does not exit the VM when the archive is invalid 8066775: opto/node.hpp:355, assert(i < _max) failed: oob: i=1, _max=1 8066900: Array Out Of Bounds Exception causes variable corruption 8066964: ppc64: argument and return type profiling, fix problem with popframe 8067144: SIGSEGV with +TraceDeoptimization in Deoptimization::print_objects 8067232: [TESTBUG] runtime/CheckEndorsedAndExtDirs/EndorsedExtDirs.java fails with ClassNotFoundException New bugs filed: Bugs in PIT build: Bugs in earlier promoted build: JDK-8067652: ResMan: Kitchensink fails due to difference between expected and actual values for socket.write resource Number of PIT requested: 1 Integration target J2SE build number: jdk8u40-b19 Issues and Notes: This is PIT for HS25.40-b23 for jdk8u40-b19. Go for integration. -- Alejandro From Alan.Bateman at oracle.com Tue Dec 16 21:00:48 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 16 Dec 2014 21:00:48 +0000 Subject: [8u-dev] Request for review and approval : 8060170 & 8064407 In-Reply-To: <54906AB1.8040901@oracle.com> References: <54906AB1.8040901@oracle.com> Message-ID: <54909D80.9050101@oracle.com> On 16/12/2014 17:24, Se?n Coffey wrote: > Requesting to backport these two enhancements to jdk8u-dev as per > request from Martin Sawicki. > > 8060170: Support SIO_LOOPBACK_FAST_PATH option on Windows > JDK 9 changeset : > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/26e6402772c8 > review thread : > http://mail.openjdk.java.net/pipermail/nio-dev/2014-October/002797.html > > 8064407: (fc) FileChannel transferTo should use TransmitFile on Windows > JDK 9 changeset : > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ba6d8f56003b > review thread : > http://mail.openjdk.java.net/pipermail/nio-dev/2014-November/002824.html > > There was a minor patch import problem with 8064407 (post > unshuffling). The > src/java.base/windows/classes/sun/nio/ch/FileDispatcherImpl.java > source differs slightly. (append flag removed/modified in JDK 9) Only > the first hunk failed. Nothing major. > > I've posted jdk8u-dev webrev to here : > http://cr.openjdk.java.net/~coffeys/webrev.MSBackports.8u/webrev/ > Would be good if you can review Alan. JPRT build & tests are green. > Looks good to me. -Alan From sean.coffey at oracle.com Wed Dec 17 09:59:23 2014 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Wed, 17 Dec 2014 09:59:23 +0000 Subject: Backporting the TCP Loopack fast path (Windows) improvement to JDK 8 - JDK-8060170 In-Reply-To: References: <54873754.6030007@oracle.com> <548DAEAD.6030906@oracle.com> Message-ID: <549153FB.7050907@oracle.com> Martin, both fixes have now been integrated into jdk8u-dev. You'll see backports created off the master bug : https://bugs.openjdk.java.net/browse/JDK-8060170 https://bugs.openjdk.java.net/browse/JDK-8064407 Since we're past the rampdown 2 stage for 8u40 [1], the fixes haven't made 8u40 release. If you feel that these fixes are important for 8u40, I can work with you in getting a phase 2 approval request submitted [2]. regards, Sean. [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2014-December/002677.html [2] http://openjdk.java.net/projects/jdk8u/phase2/phase2-process.html On 15/12/2014 13:03, Martin Sawicki (MS OPEN TECH) wrote: > Sean > Great, thank you for the assistance. > I'll start another thread now about the other item we recently fixed in JDK 9. > Best regards > > -----Original Message----- > From: Se?n Coffey [mailto:sean.coffey at oracle.com] > Sent: Sunday, December 14, 2014 7:37 AM > To: Martin Sawicki (MS OPEN TECH); jdk8u-dev at openjdk.java.net > Cc: Valery Kopylov (Akvelon); Kirk Shoop (MS OPEN TECH) > Subject: Re: Backporting the TCP Loopack fast path (Windows) improvement to JDK 8 - JDK-8060170 > > Thanks for the updates Martin. The CCC has since been approved for porting to JDK 8u. I'll get around to an approval request & push early this week. > > regards, > Sean. > > On 14/12/2014 15:04, Martin Sawicki (MS OPEN TECH) wrote: >> Hi Sean, >> As requested, attached is the patch file. >> To create the patch, the unshuffle_patch.sh script from jdk9 repo was applied to the jdk9 patch to transform the file names back to the jdk8 project structure. The resulting patch was cleanly applied to jdk8u-dev. >> If you could help with whatever other steps of the process we're missing, that would be appreciated! >> Best regards >> >> Martin (and Kirk and Valeriy) >> Microsoft Open Technologies, Inc. >> A subsidiary of Microsoft Corp. >> >> -----Original Message----- >> From: Se?n Coffey [mailto:sean.coffey at oracle.com] >> Sent: Tuesday, December 09, 2014 9:54 AM >> To: Martin Sawicki (MS OPEN TECH); jdk8u-dev at openjdk.java.net >> Cc: Valery Kopylov (Akvelon); Kirk Shoop (MS OPEN TECH) >> Subject: Re: Backporting the TCP Loopack fast path (Windows) >> improvement to JDK 8 >> >> Martin, >> >> does the JDK 9 patch apply cleanly to the jdk8u code base (bar any path name changes) ? >> >> The CCC was logged for JDK 9 only - We'd need one approved for JDK 8u before a push can be made. I can help out there if necessary. Also - we can't accept patches hosted on non OpenJDK infrastructure ? Could you reply and append the jdk.patch file (as per webrev generation) to this mail ? >> >> Regards, >> Sean. >> >> On 09/12/2014 17:45, Martin Sawicki (MS OPEN TECH) wrote: >>> Hello, >>> >>> We'd like to propose to backport our TCP loopback fast path improvement for Windows that was recently accepted into JDK9 to JDK8: >>> (JDK9 fix for reference: >>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/26e6402772c8) >>> >>> Our suggested JDK8 webrev package can be found here: >>> https://openjdkcontrib.blob.core.windows.net/tcploopback/jdk8-webrev- >>> 2 >>> 0141105.zip >>> >>> We'd appreciate your review and acceptance of this contribution. >>> >>> Best regards, >>> Martin Sawicki (and Kirk Shoop, and Valeriy Kopylov) Microsoft Open >>> Technologies, Inc. >>> From marcins at microsoft.com Wed Dec 17 17:27:50 2014 From: marcins at microsoft.com (Martin Sawicki (MS OPEN TECH)) Date: Wed, 17 Dec 2014 17:27:50 +0000 Subject: Backporting the TCP Loopack fast path (Windows) improvement to JDK 8 - JDK-8060170 In-Reply-To: <549153FB.7050907@oracle.com> References: <54873754.6030007@oracle.com> <548DAEAD.6030906@oracle.com> <549153FB.7050907@oracle.com> Message-ID: Sean, I do not have a strong reason to argue for pushing these into u40. Thank you for the update. Best regards Martin -----Original Message----- From: Se?n Coffey [mailto:sean.coffey at oracle.com] Sent: Wednesday, December 17, 2014 1:59 AM To: Martin Sawicki (MS OPEN TECH); jdk8u-dev at openjdk.java.net Cc: Valery Kopylov (Akvelon); Kirk Shoop (MS OPEN TECH) Subject: Re: Backporting the TCP Loopack fast path (Windows) improvement to JDK 8 - JDK-8060170 Martin, both fixes have now been integrated into jdk8u-dev. You'll see backports created off the master bug : https://bugs.openjdk.java.net/browse/JDK-8060170 https://bugs.openjdk.java.net/browse/JDK-8064407 Since we're past the rampdown 2 stage for 8u40 [1], the fixes haven't made 8u40 release. If you feel that these fixes are important for 8u40, I can work with you in getting a phase 2 approval request submitted [2]. regards, Sean. [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2014-December/002677.html [2] http://openjdk.java.net/projects/jdk8u/phase2/phase2-process.html On 15/12/2014 13:03, Martin Sawicki (MS OPEN TECH) wrote: > Sean > Great, thank you for the assistance. > I'll start another thread now about the other item we recently fixed in JDK 9. > Best regards > > -----Original Message----- > From: Se?n Coffey [mailto:sean.coffey at oracle.com] > Sent: Sunday, December 14, 2014 7:37 AM > To: Martin Sawicki (MS OPEN TECH); jdk8u-dev at openjdk.java.net > Cc: Valery Kopylov (Akvelon); Kirk Shoop (MS OPEN TECH) > Subject: Re: Backporting the TCP Loopack fast path (Windows) > improvement to JDK 8 - JDK-8060170 > > Thanks for the updates Martin. The CCC has since been approved for porting to JDK 8u. I'll get around to an approval request & push early this week. > > regards, > Sean. > > On 14/12/2014 15:04, Martin Sawicki (MS OPEN TECH) wrote: >> Hi Sean, >> As requested, attached is the patch file. >> To create the patch, the unshuffle_patch.sh script from jdk9 repo was applied to the jdk9 patch to transform the file names back to the jdk8 project structure. The resulting patch was cleanly applied to jdk8u-dev. >> If you could help with whatever other steps of the process we're missing, that would be appreciated! >> Best regards >> >> Martin (and Kirk and Valeriy) >> Microsoft Open Technologies, Inc. >> A subsidiary of Microsoft Corp. >> >> -----Original Message----- >> From: Se?n Coffey [mailto:sean.coffey at oracle.com] >> Sent: Tuesday, December 09, 2014 9:54 AM >> To: Martin Sawicki (MS OPEN TECH); jdk8u-dev at openjdk.java.net >> Cc: Valery Kopylov (Akvelon); Kirk Shoop (MS OPEN TECH) >> Subject: Re: Backporting the TCP Loopack fast path (Windows) >> improvement to JDK 8 >> >> Martin, >> >> does the JDK 9 patch apply cleanly to the jdk8u code base (bar any path name changes) ? >> >> The CCC was logged for JDK 9 only - We'd need one approved for JDK 8u before a push can be made. I can help out there if necessary. Also - we can't accept patches hosted on non OpenJDK infrastructure ? Could you reply and append the jdk.patch file (as per webrev generation) to this mail ? >> >> Regards, >> Sean. >> >> On 09/12/2014 17:45, Martin Sawicki (MS OPEN TECH) wrote: >>> Hello, >>> >>> We'd like to propose to backport our TCP loopback fast path improvement for Windows that was recently accepted into JDK9 to JDK8: >>> (JDK9 fix for reference: >>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/26e6402772c8) >>> >>> Our suggested JDK8 webrev package can be found here: >>> https://openjdkcontrib.blob.core.windows.net/tcploopback/jdk8-webrev >>> - >>> 2 >>> 0141105.zip >>> >>> We'd appreciate your review and acceptance of this contribution. >>> >>> Best regards, >>> Martin Sawicki (and Kirk Shoop, and Valeriy Kopylov) Microsoft Open >>> Technologies, Inc. >>> From alexander.zvegintsev at oracle.com Wed Dec 17 17:28:23 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Wed, 17 Dec 2014 20:28:23 +0300 Subject: [8u60] Request for approval 7155963: Deadlock in SystemFlavorMap.getFlavorsForNative and SunToolkit.awtLock Message-ID: <5491BD37.1040309@oracle.com> Hello, This is a request for approval to backport a fix from the jdk9 to the jdk8u-dev repository. Changes applies cleanly to jdk8u-dev after path reshuffling. The bug: https://bugs.openjdk.java.net/browse/JDK-7155963 The fix: http://hg.openjdk.java.net/jdk9/client/jdk/rev/3c08f7316a87 The review: http://mail.openjdk.java.net/pipermail/awt-dev/2014-December/008770.html -- Thanks, Alexander. From daniel.fuchs at oracle.com Wed Dec 17 18:21:25 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 17 Dec 2014 19:21:25 +0100 Subject: [8u-dev] Request for Review and Approval: 8066612: Add a test that will call getDeclaredFields() on all classes and try to set them accessible. Message-ID: <5491C9A5.6050104@oracle.com> Hi, This is a request for approval to backport: 8066612: Add a test that will call getDeclaredFields() on all classes and try to set them accessible. https://bugs.openjdk.java.net/browse/JDK-8066612 to 8u-dev. The test code is slightly different on 8u compared to 9 so I'm asking for review here as well: On 8u-dev the test is different because it can't use the jrt:/ filesystem that 9 was using. Instead it parses the jars found on the bootclasspath to get the list of classes. The changes are however very limited: - The inner class ClassNameJrtStreamBuilder is replaced with ClassNameStreamBuilder - The class loader passed to Class.forName is now 'null' Here is the webrev for 8: http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk8.01/ To be compared with the changeset pushed in 9: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/70e68970bdee And in case that's needed - the review thread for 9 started here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030078.html best regards -- daniel From sean.coffey at oracle.com Wed Dec 17 18:38:44 2014 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Wed, 17 Dec 2014 18:38:44 +0000 Subject: [8u60] Request for approval 7155963: Deadlock in SystemFlavorMap.getFlavorsForNative and SunToolkit.awtLock In-Reply-To: <5491BD37.1040309@oracle.com> References: <5491BD37.1040309@oracle.com> Message-ID: <5491CDB4.5090300@oracle.com> Approved for jdk8u-dev [8u60] regards, Sean. On 17/12/14 17:28, Alexander Zvegintsev wrote: > Hello, > > This is a request for approval to backport a fix from the jdk9 to the > jdk8u-dev repository. > Changes applies cleanly to jdk8u-dev after path reshuffling. > > The bug: https://bugs.openjdk.java.net/browse/JDK-7155963 > The fix: http://hg.openjdk.java.net/jdk9/client/jdk/rev/3c08f7316a87 > The review: > http://mail.openjdk.java.net/pipermail/awt-dev/2014-December/008770.html > From sean.coffey at oracle.com Wed Dec 17 18:47:22 2014 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Wed, 17 Dec 2014 18:47:22 +0000 Subject: [8u-dev] Request for Review and Approval: 8066612: Add a test that will call getDeclaredFields() on all classes and try to set them accessible. In-Reply-To: <5491C9A5.6050104@oracle.com> References: <5491C9A5.6050104@oracle.com> Message-ID: <5491CFBA.2080001@oracle.com> Looks fine to me Daniel (I'll look at porting this to 7u-dev also) Approved. regards, Sean. On 17/12/14 18:21, Daniel Fuchs wrote: > Hi, > > This is a request for approval to backport: > > 8066612: Add a test that will call getDeclaredFields() on all > classes and try to set them accessible. > https://bugs.openjdk.java.net/browse/JDK-8066612 > > to 8u-dev. > > The test code is slightly different on 8u compared to 9 so I'm asking > for review here as well: > > On 8u-dev the test is different because it can't use the jrt:/ > filesystem that 9 was using. Instead it parses the jars found on > the bootclasspath to get the list of classes. > > The changes are however very limited: > > - The inner class ClassNameJrtStreamBuilder is replaced with > ClassNameStreamBuilder > - The class loader passed to Class.forName is now 'null' > > Here is the webrev for 8: > http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk8.01/ > > To be compared with the changeset pushed in 9: > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/70e68970bdee > > And in case that's needed - the review thread for 9 started here: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030078.html > > > best regards > > -- daniel > From sean.coffey at oracle.com Wed Dec 17 18:53:32 2014 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Wed, 17 Dec 2014 18:53:32 +0000 Subject: [8u communication] Plans for creation of 8u40 stabilization forests In-Reply-To: <548714EA.10208@oracle.com> References: <548714EA.10208@oracle.com> Message-ID: <5491D12C.9060302@oracle.com> Ops Team, the jdk8u40-b19 tags have been added to the master jdk8u forest. can I ask you to spin up jdk8u40 and jdk8u40-dev forests as per plans below ? thanks, Sean. On 09/12/14 15:27, Se?n Coffey wrote: > Following on from my last mail regarding the 8u40 release timeline [1], > the current plan is to create the 8u40 stabilization forests once 8u40 > b19 is promoted. That's due for build promotion on December 17th. As > always, this date is tentative and subject to change. > > Once the jdk8u40-b19 tags have been added to the master forest, I'd > like to > propose that the following 8u40 stabilization forests be created : > > hg.openjdk.java.net/jdk8u/jdk8u40 based on > hg.openjdk.java.net/jdk8u/jdk8u/ tag jdk8u40-b19 (master forest) > hg.openjdk.java.net/jdk8u/jdk8u40-dev based on > hg.openjdk.java.net/jdk8u/jdk8u/ tag jdk8u40-b19 (team forest) > > Getting fixes into the jdk8u40 stabilization forest will be subject to > the Phase 2 stabilization process [2]. > > Regards, > Sean. > > [1] > http://mail.openjdk.java.net/pipermail/jdk8u-dev/2014-November/002512.html > [2] http://openjdk.java.net/projects/jdk8u/phase2/phase2-process.html > From alejandro.murillo at oracle.com Wed Dec 17 19:49:14 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Wed, 17 Dec 2014 12:49:14 -0700 Subject: [8u40] IMPORTANT INFO: Please do not push any changeset to jdk8u/hs-dev until further notice In-Reply-To: <548B5EC2.4060203@oracle.com> References: <548B5EC2.4060203@oracle.com> Message-ID: <5491DE3A.6040609@oracle.com> On 12/12/2014 2:31 PM, Alejandro E Murillo wrote: > > Hotspot developers: > > I just took the last snapshot of jdk8u/hs-dev [1] before 8u40 enters > the RDP2 phase. > that repository will become associated to 8u60 next week, after > 8u40-b19 is promoted. > Until then please refrain from pushing any changes to it. I will > reply this email > when that happens The switch has been done. Repo [1] is now open for changes as explained below, approved changes for 8u40 should also be pushed to this repo Thanks Alejandro > > Going forward, > Hotspot changes destined for 8u40 will need to be approved by the > releasing team (see [2] for details). > Once approved, they should be pushed to jdk8u/hs-dev as usual, and > then I will > take all 8u40 approved changes from there to the jdk8u40 stabilization > repo (see [3]) > after going through PIT (if needed). > > thanks > > [1] http://hg.openjdk.java.net/jdk8u/hs-dev/ > [2] http://openjdk.java.net/projects/jdk8u/phase2/phase2-process.html > [3] > http://mail.openjdk.java.net/pipermail/jdk8u-dev/2014-December/002677.html > -- Alejandro From sean.coffey at oracle.com Wed Dec 17 22:40:59 2014 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Wed, 17 Dec 2014 22:40:59 +0000 Subject: [approval missing] Re: hg: jdk8u/jdk8u-dev/jdk: 8067151: [TESTBUG] com/sun/corba/5036554/TestCorbaBug.sh In-Reply-To: <201412171216.sBHCGdqH013153@aojmv0008> References: <201412171216.sBHCGdqH013153@aojmv0008> Message-ID: <5492067B.4020402@oracle.com> Mark, I didn't see a push request for this issue. Can you please log one retrospectively ? Why wasn't it fixed in JDK 9 first ? http://openjdk.java.net/projects/jdk8u/approval-template.html regards, Sean. On 17/12/2014 12:16, mark.sheppard at oracle.com wrote: > Changeset: 588763e97311 > Author: msheppar > Date: 2014-12-17 12:17 +0000 > URL: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/588763e97311 > > 8067151: [TESTBUG] com/sun/corba/5036554/TestCorbaBug.sh > Summary: changed TESTJAVA to COMPILEJAVA for javac and idlj paths. > Reviewed-by: chegar > > ! test/com/sun/corba/5036554/TestCorbaBug.sh > ! test/com/sun/corba/cachedSocket/7056731.sh > From mark.sheppard at oracle.com Wed Dec 17 23:03:37 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Wed, 17 Dec 2014 23:03:37 +0000 Subject: [approval missing] Re: hg: jdk8u/jdk8u-dev/jdk: 8067151: [TESTBUG] com/sun/corba/5036554/TestCorbaBug.sh In-Reply-To: <5492067B.4020402@oracle.com> References: <201412171216.sBHCGdqH013153@aojmv0008> <5492067B.4020402@oracle.com> Message-ID: <54920BC9.8020504@oracle.com> Hi Sean, aaah! yes, I sent it to core-libs and not 8u-dev, my mistake, sorry about that. Chris reviewed. I'm fixing in 8 first as it was called out at meeting this week as an 8u40 item. It arises in embedded test environment. regards Mark On 17/12/2014 22:40, Se?n Coffey wrote: > Mark, > > I didn't see a push request for this issue. Can you please log one > retrospectively ? Why wasn't it fixed in JDK 9 first ? > http://openjdk.java.net/projects/jdk8u/approval-template.html > > regards, > Sean. > > On 17/12/2014 12:16, mark.sheppard at oracle.com wrote: >> Changeset: 588763e97311 >> Author: msheppar >> Date: 2014-12-17 12:17 +0000 >> URL: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/588763e97311 >> >> 8067151: [TESTBUG] com/sun/corba/5036554/TestCorbaBug.sh >> Summary: changed TESTJAVA to COMPILEJAVA for javac and idlj paths. >> Reviewed-by: chegar >> >> ! test/com/sun/corba/5036554/TestCorbaBug.sh >> ! test/com/sun/corba/cachedSocket/7056731.sh >> > From mark.sheppard at oracle.com Wed Dec 17 23:13:00 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Wed, 17 Dec 2014 23:13:00 +0000 Subject: 8u-dev: request for approval JDK-8067151 - [TESTBUG] com/sun/corba/5036554/TestCorbaBug.sh Message-ID: <54920DFC.6060303@oracle.com> Hi this is a retrospective request for approval for the fix http://cr.openjdk.java.net/~msheppar/8067151/webrev/ to address the issue https://bugs.openjdk.java.net/browse/JDK-8067151 which sees a test failure for JRE only in an embedded environment. the test scripts now use the env variable COMPILEJAVA rather than TESTJAVA regards Mark From sean.coffey at oracle.com Wed Dec 17 23:28:19 2014 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Wed, 17 Dec 2014 23:28:19 +0000 Subject: 8u-dev: request for approval JDK-8067151 - [TESTBUG] com/sun/corba/5036554/TestCorbaBug.sh In-Reply-To: <54920DFC.6060303@oracle.com> References: <54920DFC.6060303@oracle.com> Message-ID: <54921193.9070803@oracle.com> Thanks for following up Mark. You forgot to point to the review thread : http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030393.html If this is not applicable to JDK 9, please add the 9-na label. Otherwise, create a 9 backport record so that it's not forgotten. Approved. regards, Sean. On 17/12/2014 23:13, Mark Sheppard wrote: > Hi > this is a retrospective request for approval for the fix > > http://cr.openjdk.java.net/~msheppar/8067151/webrev/ > > to address the issue > https://bugs.openjdk.java.net/browse/JDK-8067151 > > which sees a test failure for JRE only in an embedded environment. > > the test scripts now use the env variable COMPILEJAVA rather than > TESTJAVA > > regards > Mark > > > From david.holmes at oracle.com Thu Dec 18 01:38:49 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 18 Dec 2014 11:38:49 +1000 Subject: [8u60] Request for Approval 8038189: Add cross-platform compact profiles support Message-ID: <54923029.5040801@oracle.com> This is a feature for 8u only (compact profiles are not applicable to 9 due to the module system). Bug ID (closed): https://bugs.openjdk.java.net/browse/JDK-8038189 Open backport: https://bugs.openjdk.java.net/browse/JDK-8066200 Webrevs: http://cr.openjdk.java.net/~dholmes/8038189/webrevtop.8u60/ http://cr.openjdk.java.net/~dholmes/8038189/webrevjdk.8u60/ Review thread: http://mail.openjdk.java.net/pipermail/build-dev/2014-December/013765.html Thanks, David From sean.coffey at oracle.com Thu Dec 18 09:20:16 2014 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Thu, 18 Dec 2014 09:20:16 +0000 Subject: [8u60] Request for Approval 8038189: Add cross-platform compact profiles support In-Reply-To: <54923029.5040801@oracle.com> References: <54923029.5040801@oracle.com> Message-ID: <54929C50.9030708@oracle.com> Approved. regards, Sean. On 18/12/2014 01:38, David Holmes wrote: > This is a feature for 8u only (compact profiles are not applicable to > 9 due to the module system). > > Bug ID (closed): https://bugs.openjdk.java.net/browse/JDK-8038189 > Open backport: https://bugs.openjdk.java.net/browse/JDK-8066200 > Webrevs: http://cr.openjdk.java.net/~dholmes/8038189/webrevtop.8u60/ > http://cr.openjdk.java.net/~dholmes/8038189/webrevjdk.8u60/ > Review thread: > http://mail.openjdk.java.net/pipermail/build-dev/2014-December/013765.html > > Thanks, > David From david.holmes at oracle.com Thu Dec 18 10:26:05 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 18 Dec 2014 20:26:05 +1000 Subject: [8u60] Request for Approval 8038189: Add cross-platform compact profiles support In-Reply-To: <54929C50.9030708@oracle.com> References: <54923029.5040801@oracle.com> <54929C50.9030708@oracle.com> Message-ID: <5492ABBD.9030205@oracle.com> On 18/12/2014 7:20 PM, Se?n Coffey wrote: > Approved. Thanks. I just pushed it assuming we were all set up for 8u60 but it caused a 8u40 backport to be created when I already had the 8u60 backport created. :( David > regards, > Sean. > > On 18/12/2014 01:38, David Holmes wrote: >> This is a feature for 8u only (compact profiles are not applicable to >> 9 due to the module system). >> >> Bug ID (closed): https://bugs.openjdk.java.net/browse/JDK-8038189 >> Open backport: https://bugs.openjdk.java.net/browse/JDK-8066200 >> Webrevs: http://cr.openjdk.java.net/~dholmes/8038189/webrevtop.8u60/ >> http://cr.openjdk.java.net/~dholmes/8038189/webrevjdk.8u60/ >> Review thread: >> http://mail.openjdk.java.net/pipermail/build-dev/2014-December/013765.html >> >> >> Thanks, >> David > From sean.coffey at oracle.com Thu Dec 18 10:33:27 2014 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Thu, 18 Dec 2014 10:33:27 +0000 Subject: [8u60] Request for Approval 8038189: Add cross-platform compact profiles support In-Reply-To: <5492ABBD.9030205@oracle.com> References: <54923029.5040801@oracle.com> <54929C50.9030708@oracle.com> <5492ABBD.9030205@oracle.com> Message-ID: <5492AD77.1020903@oracle.com> On 18/12/2014 10:26, David Holmes wrote: > On 18/12/2014 7:20 PM, Se?n Coffey wrote: >> Approved. > > Thanks. I just pushed it assuming we were all set up for 8u60 but it > caused a 8u40 backport to be created when I already had the 8u60 > backport created. :( Yes - I was just composing a mail to you. We're in the process of flipping the hgupdater fix version to 8u60 for all team forests. The team forests need to sync up with 8u master first in order to capture latest 8u40 fixes though. I see that an 8u60 fixversion backport record was available. Ideally, that could have been '8-pool' while we flip versions. It'll be completed today in any case. Can I ask you to manually fix up records for your bug ? I guess you can move the 8u40 fixversion one (8067857) to 8u60 and close out the other one. (fix version = na?) regards, Sean. > > David > >> regards, >> Sean. >> >> On 18/12/2014 01:38, David Holmes wrote: >>> This is a feature for 8u only (compact profiles are not applicable to >>> 9 due to the module system). >>> >>> Bug ID (closed): https://bugs.openjdk.java.net/browse/JDK-8038189 >>> Open backport: https://bugs.openjdk.java.net/browse/JDK-8066200 >>> Webrevs: http://cr.openjdk.java.net/~dholmes/8038189/webrevtop.8u60/ >>> http://cr.openjdk.java.net/~dholmes/8038189/webrevjdk.8u60/ >>> Review thread: >>> http://mail.openjdk.java.net/pipermail/build-dev/2014-December/013765.html >>> >>> >>> >>> Thanks, >>> David >> From sundararajan.athijegannathan at oracle.com Thu Dec 18 11:16:26 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 18 Dec 2014 16:46:26 +0530 Subject: [8u60] approval request for 8067854: bound java static method throws NPE when 'null' is used for this argument Message-ID: <5492B78A.2000607@oracle.com> Please approve. Bug: https://bugs.openjdk.java.net/browse/JDK-8067854 jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-December/004054.html jdk8u webrev: http://cr.openjdk.java.net/~sundar/8067854/8u60/ Backported 'as is' except for modular source layout difference. Thanks, -Sundar From attila.szegedi at oracle.com Thu Dec 18 11:18:19 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Thu, 18 Dec 2014 12:18:19 +0100 Subject: [8u60] Request for Approval: 8067774: Use a stack of types when calculating local variable types Message-ID: Please approve. Bug: https://bugs.openjdk.java.net/browse/JDK-8067774 jdk9 webrev: http://cr.openjdk.java.net/~attila/8067774/webrev.00 jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-December/004049.html Changes apply cleanly to jdk8u-dev after path reshuffling from modular source code layout. Thanks, Attila. From sean.coffey at oracle.com Thu Dec 18 11:21:01 2014 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Thu, 18 Dec 2014 11:21:01 +0000 Subject: [8u60] approval request for 8067854: bound java static method throws NPE when 'null' is used for this argument In-Reply-To: <5492B78A.2000607@oracle.com> References: <5492B78A.2000607@oracle.com> Message-ID: <5492B89D.7050108@oracle.com> Approved. regards, Sean. On 18/12/2014 11:16, A. Sundararajan wrote: > Please approve. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8067854 > jdk9 review thread: > http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-December/004054.html > jdk8u webrev: http://cr.openjdk.java.net/~sundar/8067854/8u60/ > > Backported 'as is' except for modular source layout difference. > > Thanks, > -Sundar From sean.coffey at oracle.com Thu Dec 18 11:21:33 2014 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Thu, 18 Dec 2014 11:21:33 +0000 Subject: [8u60] Request for Approval: 8067774: Use a stack of types when calculating local variable types In-Reply-To: References: Message-ID: <5492B8BD.9030801@oracle.com> Approved. regards, Sean. On 18/12/2014 11:18, Attila Szegedi wrote: > Please approve. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8067774 > jdk9 webrev: http://cr.openjdk.java.net/~attila/8067774/webrev.00 > jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-December/004049.html > > Changes apply cleanly to jdk8u-dev after path reshuffling from modular source code layout. > > Thanks, > Attila. From david.holmes at oracle.com Thu Dec 18 12:01:18 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 18 Dec 2014 22:01:18 +1000 Subject: [8u60] Request for Approval 8038189: Add cross-platform compact profiles support In-Reply-To: <5492AD77.1020903@oracle.com> References: <54923029.5040801@oracle.com> <54929C50.9030708@oracle.com> <5492ABBD.9030205@oracle.com> <5492AD77.1020903@oracle.com> Message-ID: <5492C20E.7030607@oracle.com> On 18/12/2014 8:33 PM, Se?n Coffey wrote: > > On 18/12/2014 10:26, David Holmes wrote: >> On 18/12/2014 7:20 PM, Se?n Coffey wrote: >>> Approved. >> >> Thanks. I just pushed it assuming we were all set up for 8u60 but it >> caused a 8u40 backport to be created when I already had the 8u60 >> backport created. :( > Yes - I was just composing a mail to you. We're in the process of > flipping the hgupdater fix version to 8u60 for all team forests. The > team forests need to sync up with 8u master first in order to capture > latest 8u40 fixes though. I see that an 8u60 fixversion backport record > was available. Ideally, that could have been '8-pool' while we flip > versions. It'll be completed today in any case. > > Can I ask you to manually fix up records for your bug ? I guess you can > move the 8u40 fixversion one (8067857) to 8u60 and close out the other > one. (fix version = na?) Okay - new backport moved to 8u60. Original backport closed a dup with blank fix version. Thanks, David > regards, > Sean. > >> >> David >> >>> regards, >>> Sean. >>> >>> On 18/12/2014 01:38, David Holmes wrote: >>>> This is a feature for 8u only (compact profiles are not applicable to >>>> 9 due to the module system). >>>> >>>> Bug ID (closed): https://bugs.openjdk.java.net/browse/JDK-8038189 >>>> Open backport: https://bugs.openjdk.java.net/browse/JDK-8066200 >>>> Webrevs: http://cr.openjdk.java.net/~dholmes/8038189/webrevtop.8u60/ >>>> http://cr.openjdk.java.net/~dholmes/8038189/webrevjdk.8u60/ >>>> Review thread: >>>> http://mail.openjdk.java.net/pipermail/build-dev/2014-December/013765.html >>>> >>>> >>>> >>>> Thanks, >>>> David >>> > From ivan.gerasimov at oracle.com Thu Dec 18 12:05:29 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 18 Dec 2014 15:05:29 +0300 Subject: [8u-dev] Request for Review + Request for Approval to Backport: 8064846: Lazy-init thread safety problems in core reflection Message-ID: <5492C309.9040403@oracle.com> Hello! This is a request to approve the partial backport of the fix JDK-8064846. Some of the changes have already came into 8u repo with other fixes, so I had to adjust the patch a little bit. Now the fix contains mostly changes to formatting and comments, though it should make the upcoming backports easier. Bug: https://bugs.openjdk.java.net/browse/JDK-8064846 jdk8u webrev: http://cr.openjdk.java.net/~igerasim/8064846/0/webrev/ jdk9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/7c1797994c29 jdk9 review: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-November/029654.html Sincerely yours, Ivan From alexander.zvegintsev at oracle.com Thu Dec 18 15:35:53 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Thu, 18 Dec 2014 18:35:53 +0300 Subject: [8u60] Request for approval for parfait fixes 8064698, 8064699, 8064700 Message-ID: <5492F459.8070407@oracle.com> Hello, Please approve the backport of following parfait fixes to JDK8u-dev repository. 8064698 [parfait] JNI exception pending in jdk/src/java/desktop/unix/native: libawt_xawt/awt/, common/awt https://bugs.openjdk.java.net/browse/JDK-8064698 http://hg.openjdk.java.net/jdk9/client/jdk/rev/1d10e21882c1 8064699 [parfait] JNI primitive type mismatch in jdk/src/java/desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c https://bugs.openjdk.java.net/browse/JDK-8064699 http://hg.openjdk.java.net/jdk9/client/jdk/rev/af0700ba5538 8064700 [parfait] Function Call Mismatch in jdk/src/java/desktop/unix/native/libawt_xawt/xawt/XToolkit.c https://bugs.openjdk.java.net/browse/JDK-8064700 http://hg.openjdk.java.net/jdk9/client/jdk/rev/b6001bed0227 -- Thanks, Alexander. From rob.mckenna at oracle.com Thu Dec 18 16:08:07 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 18 Dec 2014 16:08:07 +0000 Subject: [8u60] Request for approval for parfait fixes 8064698, 8064699, 8064700 In-Reply-To: <5492F459.8070407@oracle.com> References: <5492F459.8070407@oracle.com> Message-ID: <5492FBE7.1000606@oracle.com> Approved assuming the fixes apply without alteration. (other than shuffling) Also, please add suitable noreg keywords. -Rob On 18/12/14 15:35, Alexander Zvegintsev wrote: > Hello, > > Please approve the backport of following parfait fixes to JDK8u-dev > repository. > > 8064698 [parfait] JNI exception pending in > jdk/src/java/desktop/unix/native: libawt_xawt/awt/, common/awt > https://bugs.openjdk.java.net/browse/JDK-8064698 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/1d10e21882c1 > > 8064699 [parfait] JNI primitive type mismatch in > jdk/src/java/desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c > https://bugs.openjdk.java.net/browse/JDK-8064699 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/af0700ba5538 > > 8064700 [parfait] Function Call Mismatch in > jdk/src/java/desktop/unix/native/libawt_xawt/xawt/XToolkit.c > https://bugs.openjdk.java.net/browse/JDK-8064700 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/b6001bed0227 > > From martinrb at google.com Thu Dec 18 17:57:22 2014 From: martinrb at google.com (Martin Buchholz) Date: Thu, 18 Dec 2014 09:57:22 -0800 Subject: [8u-dev] Request for Review + Request for Approval to Backport: 8064846: Lazy-init thread safety problems in core reflection In-Reply-To: <5492C309.9040403@oracle.com> References: <5492C309.9040403@oracle.com> Message-ID: I didn't really expect this to get backported, but OK - looks good! On Thu, Dec 18, 2014 at 4:05 AM, Ivan Gerasimov wrote: > Hello! > > This is a request to approve the partial backport of the fix JDK-8064846. > Some of the changes have already came into 8u repo with other fixes, so I > had to adjust the patch a little bit. > > Now the fix contains mostly changes to formatting and comments, though it > should make the upcoming backports easier. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8064846 > jdk8u webrev: http://cr.openjdk.java.net/~igerasim/8064846/0/webrev/ > jdk9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/7c1797994c29 > jdk9 review: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-November/029654.html > > Sincerely yours, > Ivan From rob.mckenna at oracle.com Thu Dec 18 17:58:45 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 18 Dec 2014 17:58:45 +0000 Subject: [8u-dev] Request for Review + Request for Approval to Backport: 8064846: Lazy-init thread safety problems in core reflection In-Reply-To: References: <5492C309.9040403@oracle.com> Message-ID: <549315D5.4010708@oracle.com> Approved. -Rob On 18/12/14 17:57, Martin Buchholz wrote: > I didn't really expect this to get backported, but OK - looks good! > > On Thu, Dec 18, 2014 at 4:05 AM, Ivan Gerasimov > wrote: >> Hello! >> >> This is a request to approve the partial backport of the fix JDK-8064846. >> Some of the changes have already came into 8u repo with other fixes, so I >> had to adjust the patch a little bit. >> >> Now the fix contains mostly changes to formatting and comments, though it >> should make the upcoming backports easier. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8064846 >> jdk8u webrev: http://cr.openjdk.java.net/~igerasim/8064846/0/webrev/ >> jdk9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/7c1797994c29 >> jdk9 review: >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-November/029654.html >> >> Sincerely yours, >> Ivan From iris.clark at oracle.com Thu Dec 18 19:47:31 2014 From: iris.clark at oracle.com (Iris Clark) Date: Thu, 18 Dec 2014 11:47:31 -0800 (PST) Subject: [8u communication] Plans for creation of 8u40 stabilization forests In-Reply-To: <5491D12C.9060302@oracle.com> References: <548714EA.10208@oracle.com> <5491D12C.9060302@oracle.com> Message-ID: <44a7f898-e024-41ff-84f3-7df6f355e0f2@default> Done: http://hg.openjdk.java.net/jdk8u http://hg.openjdk.java.net/jdk8u/jdk8u40/ http://hg.openjdk.java.net/jdk8u/jdk8u40-dev/ The tips are at tag jdk8u40-b19, hgupdater set to 8u40. Thanks, iris -----Original Message----- From: Se?n Coffey Sent: Wednesday, December 17, 2014 10:54 AM To: jdk8u-dev at openjdk.java.net; ops at openjdk.java.net Subject: [8u communication] Plans for creation of 8u40 stabilization forests Ops Team, the jdk8u40-b19 tags have been added to the master jdk8u forest. can I ask you to spin up jdk8u40 and jdk8u40-dev forests as per plans below ? thanks, Sean. On 09/12/14 15:27, Se?n Coffey wrote: > Following on from my last mail regarding the 8u40 release timeline > [1], the current plan is to create the 8u40 stabilization forests once > 8u40 > b19 is promoted. That's due for build promotion on December 17th. As > always, this date is tentative and subject to change. > > Once the jdk8u40-b19 tags have been added to the master forest, I'd > like to propose that the following 8u40 stabilization forests be > created : > > hg.openjdk.java.net/jdk8u/jdk8u40 based on > hg.openjdk.java.net/jdk8u/jdk8u/ tag jdk8u40-b19 (master forest) > hg.openjdk.java.net/jdk8u/jdk8u40-dev based on > hg.openjdk.java.net/jdk8u/jdk8u/ tag jdk8u40-b19 (team forest) > > Getting fixes into the jdk8u40 stabilization forest will be subject to > the Phase 2 stabilization process [2]. > > Regards, > Sean. > > [1] > http://mail.openjdk.java.net/pipermail/jdk8u-dev/2014-November/002512. > html [2] > http://openjdk.java.net/projects/jdk8u/phase2/phase2-process.html > From sean.coffey at oracle.com Thu Dec 18 19:54:42 2014 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Thu, 18 Dec 2014 19:54:42 +0000 Subject: [8u communication] Plans for creation of 8u40 stabilization forests In-Reply-To: <44a7f898-e024-41ff-84f3-7df6f355e0f2@default> References: <548714EA.10208@oracle.com> <5491D12C.9060302@oracle.com> <44a7f898-e024-41ff-84f3-7df6f355e0f2@default> Message-ID: <54933102.8030306@oracle.com> Thanks! Sean. On 18/12/2014 19:47, Iris Clark wrote: > Done: > > http://hg.openjdk.java.net/jdk8u > > http://hg.openjdk.java.net/jdk8u/jdk8u40/ > http://hg.openjdk.java.net/jdk8u/jdk8u40-dev/ > > The tips are at tag jdk8u40-b19, hgupdater set to 8u40. > > Thanks, > iris > > -----Original Message----- > From: Se?n Coffey > Sent: Wednesday, December 17, 2014 10:54 AM > To: jdk8u-dev at openjdk.java.net; ops at openjdk.java.net > Subject: [8u communication] Plans for creation of 8u40 stabilization forests > > Ops Team, > > the jdk8u40-b19 tags have been added to the master jdk8u forest. > > can I ask you to spin up jdk8u40 and jdk8u40-dev forests as per plans below ? > > thanks, > Sean. > > On 09/12/14 15:27, Se?n Coffey wrote: >> Following on from my last mail regarding the 8u40 release timeline >> [1], the current plan is to create the 8u40 stabilization forests once >> 8u40 >> b19 is promoted. That's due for build promotion on December 17th. As >> always, this date is tentative and subject to change. >> >> Once the jdk8u40-b19 tags have been added to the master forest, I'd >> like to propose that the following 8u40 stabilization forests be >> created : >> >> hg.openjdk.java.net/jdk8u/jdk8u40 based on >> hg.openjdk.java.net/jdk8u/jdk8u/ tag jdk8u40-b19 (master forest) >> hg.openjdk.java.net/jdk8u/jdk8u40-dev based on >> hg.openjdk.java.net/jdk8u/jdk8u/ tag jdk8u40-b19 (team forest) >> >> Getting fixes into the jdk8u40 stabilization forest will be subject to >> the Phase 2 stabilization process [2]. >> >> Regards, >> Sean. >> >> [1] >> http://mail.openjdk.java.net/pipermail/jdk8u-dev/2014-November/002512. >> html [2] >> http://openjdk.java.net/projects/jdk8u/phase2/phase2-process.html >> From shanliang.jiang at oracle.com Fri Dec 19 10:46:47 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Fri, 19 Dec 2014 11:46:47 +0100 Subject: [8u60] Request for Approval: 8066952: Use a stack of types when calculating local variable types Message-ID: <54940217.1050205@oracle.com> Please approve this clean backport: Review: http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-December/016207.html JDK 9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f981c65f7951 bug: https://bugs.openjdk.java.net/browse/JDK-8066952 thanks, Shanliang From sean.coffey at oracle.com Fri Dec 19 11:02:26 2014 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Fri, 19 Dec 2014 11:02:26 +0000 Subject: [8u60] Request for Approval: 8066952: Use a stack of types when calculating local variable types In-Reply-To: <54940217.1050205@oracle.com> References: <54940217.1050205@oracle.com> Message-ID: <549405C2.50204@oracle.com> Approved. regards, Sean. On 19/12/14 10:46, shanliang wrote: > Please approve this clean backport: > > Review: > http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-December/016207.html > JDK 9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f981c65f7951 > bug: https://bugs.openjdk.java.net/browse/JDK-8066952 > > thanks, > Shanliang From filipp.zhinkin at oracle.com Fri Dec 19 14:59:02 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Fri, 19 Dec 2014 18:59:02 +0400 Subject: [8u40] Request for approval to backport JDK-8037968 and JDK-8066143 Message-ID: <54943D36.2080001@oracle.com> Hi, please approve backport of following test-only fixes into 8u40: JDK-8037968 Add tests on alignment of objects copied to survivor space: Bug-id: https://bugs.openjdk.java.net/browse/JDK-8037968 Original review thread: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-November/011405.html Original changeset: http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/c196aca52cab JDK-8066143 [TESTBUG] New tests in gc/survivorAlignment/ fails Bug-id: https://bugs.openjdk.java.net/browse/JDK-8066143 Original review thread: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-December/011573.html Original changeset: http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/3c17077e9882 Fix for 8037968 applied with fuzz, but without any changes. Do I need to create a new patch for it? Fix for 8066143 applied cleanly without any changes. I've tested these tests after both fixes were applied, no issues were found. Thanks, Filipp. From ivan.gerasimov at oracle.com Fri Dec 19 19:04:34 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 19 Dec 2014 22:04:34 +0300 Subject: [8u-dev] Request for Approval to Backport: 8065172: More core reflection final and volatile annotations Message-ID: <549476C2.60701@oracle.com> Hello! This is the last one left (at the time of posting) change, adding final/volatile annotations in reflection. After the recent integration of JDK-8064846, the unshuffled patch applied cleanly. Jprt + test subset jdk_lang with no failures. Bug: https://bugs.openjdk.java.net/browse/JDK-8065172 Jdk9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/63c558ffb833 Jdk9 review: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-November/029739.html Sincerely yours, Ivan From martinrb at google.com Fri Dec 19 19:38:43 2014 From: martinrb at google.com (Martin Buchholz) Date: Fri, 19 Dec 2014 11:38:43 -0800 Subject: [8u-dev] Request for Approval to Backport: 8065172: More core reflection final and volatile annotations In-Reply-To: <549476C2.60701@oracle.com> References: <549476C2.60701@oracle.com> Message-ID: Again, this change was originally written without planning for a backport (I might have done things a little differently), but looks good! On Fri, Dec 19, 2014 at 11:04 AM, Ivan Gerasimov wrote: > Hello! > > This is the last one left (at the time of posting) change, adding > final/volatile annotations in reflection. > > After the recent integration of JDK-8064846, the unshuffled patch applied > cleanly. > > Jprt + test subset jdk_lang with no failures. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8065172 > Jdk9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/63c558ffb833 > Jdk9 review: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-November/029739.html > > Sincerely yours, > Ivan From ivan.gerasimov at oracle.com Fri Dec 19 20:50:52 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 19 Dec 2014 23:50:52 +0300 Subject: [8u-dev] Request for Approval to Backport: 8065172: More core reflection final and volatile annotations In-Reply-To: References: <549476C2.60701@oracle.com> Message-ID: <54948FAC.9080503@oracle.com> On 19.12.2014 22:38, Martin Buchholz wrote: > Again, this change was originally written without planning for a > backport (I might have done things a little differently), but looks > good! I though it is in line with 8062771: Core reflection should use final fields whenever possible 8064391: More thread safety problems in core reflection 8064846: Lazy-init thread safety problems in core reflection which had been backported earlier :-) It wouldn't hurt to integrate this also, right? Sincerely yours, Ivan > On Fri, Dec 19, 2014 at 11:04 AM, Ivan Gerasimov > wrote: >> Hello! >> >> This is the last one left (at the time of posting) change, adding >> final/volatile annotations in reflection. >> >> After the recent integration of JDK-8064846, the unshuffled patch applied >> cleanly. >> >> Jprt + test subset jdk_lang with no failures. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8065172 >> Jdk9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/63c558ffb833 >> Jdk9 review: >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-November/029739.html >> >> Sincerely yours, >> Ivan > From martinrb at google.com Fri Dec 19 22:17:38 2014 From: martinrb at google.com (Martin Buchholz) Date: Fri, 19 Dec 2014 14:17:38 -0800 Subject: [8u-dev] Request for Approval to Backport: 8065172: More core reflection final and volatile annotations In-Reply-To: <54948FAC.9080503@oracle.com> References: <549476C2.60701@oracle.com> <54948FAC.9080503@oracle.com> Message-ID: On Fri, Dec 19, 2014 at 12:50 PM, Ivan Gerasimov wrote: > > On 19.12.2014 22:38, Martin Buchholz wrote: >> >> Again, this change was originally written without planning for a >> backport (I might have done things a little differently), but looks >> good! > > > I though it is in line with > 8062771: Core reflection should use final fields whenever possible > 8064391: More thread safety problems in core reflection > 8064846: Lazy-init thread safety problems in core reflection > > which had been backported earlier :-) > > It wouldn't hurt to integrate this also, right? Everything is relative - previous bug fixes actually had an associated failure seen in the wild. And this one has some cleanup in it as well, that would typically not be backported. I am OK with or without a backport. Up to you! From ivan.gerasimov at oracle.com Mon Dec 22 08:44:36 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 22 Dec 2014 11:44:36 +0300 Subject: [8u-dev] Request for Approval to Backport: 8065172: More core reflection final and volatile annotations In-Reply-To: References: <549476C2.60701@oracle.com> <54948FAC.9080503@oracle.com> Message-ID: <5497D9F4.6010907@oracle.com> Thanks Martin for clarification! I'll hold off backporting this fix then. If this is needed later, it can easily be applied. Sincerely yours, Ivan On 20.12.2014 1:17, Martin Buchholz wrote: > On Fri, Dec 19, 2014 at 12:50 PM, Ivan Gerasimov > wrote: >> On 19.12.2014 22:38, Martin Buchholz wrote: >>> Again, this change was originally written without planning for a >>> backport (I might have done things a little differently), but looks >>> good! >> >> I though it is in line with >> 8062771: Core reflection should use final fields whenever possible >> 8064391: More thread safety problems in core reflection >> 8064846: Lazy-init thread safety problems in core reflection >> >> which had been backported earlier :-) >> >> It wouldn't hurt to integrate this also, right? > Everything is relative - previous bug fixes actually had an associated > failure seen in the wild. > And this one has some cleanup in it as well, that would typically not > be backported. > I am OK with or without a backport. Up to you! > > From rob.mckenna at oracle.com Mon Dec 22 12:59:01 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 22 Dec 2014 12:59:01 +0000 Subject: [8u40] Request for approval to backport JDK-8037968 and JDK-8066143 In-Reply-To: <54943D36.2080001@oracle.com> References: <54943D36.2080001@oracle.com> Message-ID: <54981595.4050601@oracle.com> Approved. (Fuzz doesn't require a new patch) -Rob On 19/12/14 14:59, Filipp Zhinkin wrote: > Hi, > > please approve backport of following test-only fixes into 8u40: > > JDK-8037968 Add tests on alignment of objects copied to survivor space: > > Bug-id: https://bugs.openjdk.java.net/browse/JDK-8037968 > Original review thread: > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-November/011405.html > Original changeset: > http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/c196aca52cab > > > JDK-8066143 [TESTBUG] New tests in gc/survivorAlignment/ fails > > Bug-id: https://bugs.openjdk.java.net/browse/JDK-8066143 > Original review thread: > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-December/011573.html > Original changeset: > http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/3c17077e9882 > > > Fix for 8037968 applied with fuzz, but without any changes. Do I need > to create a new patch for it? > Fix for 8066143 applied cleanly without any changes. > > I've tested these tests after both fixes were applied, no issues were > found. > > Thanks, > Filipp. From jaroslav.bachorik at oracle.com Tue Dec 23 09:30:34 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 23 Dec 2014 10:30:34 +0100 Subject: [8u-dev] Request for approval: 8038794 - java/lang/management/ThreadMXBean/SynchronizationStatistics.java fails intermittently Message-ID: <5499363A.1080902@oracle.com> Please, approve this straight backport of a JDK 9 fix. Issue : https://bugs.openjdk.java.net/browse/JDK-8038794 Changeset : http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/4f11e558f9ee Review : http://mail.openjdk.java.net/pipermail/jmx-dev/2014-June/000645.html http://mail.openjdk.java.net/pipermail/jmx-dev/2014-July/000646.html No modifications to the JDK9 changeset are necessary. Thanks, -JB- From sean.coffey at oracle.com Tue Dec 23 09:58:32 2014 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Tue, 23 Dec 2014 09:58:32 +0000 Subject: [8u-dev] Request for approval: 8038794 - java/lang/management/ThreadMXBean/SynchronizationStatistics.java fails intermittently In-Reply-To: <5499363A.1080902@oracle.com> References: <5499363A.1080902@oracle.com> Message-ID: <54993CC8.4050602@oracle.com> Approved. regards, Sean. On 23/12/2014 09:30, Jaroslav Bachorik wrote: > Please, approve this straight backport of a JDK 9 fix. > > Issue : https://bugs.openjdk.java.net/browse/JDK-8038794 > Changeset : http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/4f11e558f9ee > Review : > http://mail.openjdk.java.net/pipermail/jmx-dev/2014-June/000645.html > http://mail.openjdk.java.net/pipermail/jmx-dev/2014-July/000646.html > > No modifications to the JDK9 changeset are necessary. > > Thanks, > > -JB- From shanliang.jiang at oracle.com Tue Dec 23 13:33:33 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Tue, 23 Dec 2014 14:33:33 +0100 Subject: [8u60] Request for Approval: 8067241 DeadlockTest.java failed with negative timeout value Message-ID: <54996F2D.5020008@oracle.com> Please approve this clean backport: Review: http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-December/016200.html JDK 9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/026b9a30e8b2 bug: https://bugs.openjdk.java.net/browse/JDK-8067241 thanks, Shanliang From filipp.zhinkin at oracle.com Tue Dec 23 13:27:33 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Tue, 23 Dec 2014 17:27:33 +0400 Subject: [8u40] Request for approval to backport JDK-8037968 and JDK-8066143 In-Reply-To: <54981595.4050601@oracle.com> References: <54943D36.2080001@oracle.com> <54981595.4050601@oracle.com> Message-ID: <54996DC5.8090701@oracle.com> Thank you for approval, Rob. Regards, Filipp. On 12/22/2014 04:59 PM, Rob McKenna wrote: > Approved. (Fuzz doesn't require a new patch) > > -Rob > > On 19/12/14 14:59, Filipp Zhinkin wrote: >> Hi, >> >> please approve backport of following test-only fixes into 8u40: >> >> JDK-8037968 Add tests on alignment of objects copied to survivor space: >> >> Bug-id: https://bugs.openjdk.java.net/browse/JDK-8037968 >> Original review thread: >> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-November/011405.html >> Original changeset: >> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/c196aca52cab >> >> >> JDK-8066143 [TESTBUG] New tests in gc/survivorAlignment/ fails >> >> Bug-id: https://bugs.openjdk.java.net/browse/JDK-8066143 >> Original review thread: >> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-December/011573.html >> Original changeset: >> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/3c17077e9882 >> >> >> Fix for 8037968 applied with fuzz, but without any changes. Do I need to >> create a new patch for it? >> Fix for 8066143 applied cleanly without any changes. >> >> I've tested these tests after both fixes were applied, no issues were found. >> >> Thanks, >> Filipp. > From jaroslav.bachorik at oracle.com Tue Dec 23 14:20:26 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 23 Dec 2014 15:20:26 +0100 Subject: [8u-dev] Request for bulk approval of backports from JDK9 Message-ID: <54997A2A.2090604@oracle.com> Please, approve this bunch of straight backports of JDK 9 test fixes. Issue : https://bugs.openjdk.java.net/browse/JDK-8034263 (Test java/lang/management/MemoryMXBean/LowMemoryTest.java fails intermittently) Changeset : http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/d4a100cbbb2d Review : http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-December/016124.html Issue : https://bugs.openjdk.java.net/browse/JDK-8064441 (java/lang/management/ThreadMXBean/Locks.java fails intermittently, blocked on wrong object) Changeset : http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/fae1869f4389 Review : http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-December/016069.html Issue : https://bugs.openjdk.java.net/browse/JDK-7132590 (javax/management/remote/mandatory/notif/NotificationAccessControllerTest.java fails in JDK8-B22) Changeset : http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/299e420ebd63 Review : http://mail.openjdk.java.net/pipermail/jmx-dev/2014-August/000662.html No modifications to the JDK9 changesets are necessary. Thanks, -JB- From rob.mckenna at oracle.com Tue Dec 23 15:47:07 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 23 Dec 2014 15:47:07 +0000 Subject: [8u60] Request for Approval: 8067241 DeadlockTest.java failed with negative timeout value In-Reply-To: <54996F2D.5020008@oracle.com> References: <54996F2D.5020008@oracle.com> Message-ID: <54998E7B.1070502@oracle.com> Approved. -Rob On 23/12/14 13:33, shanliang wrote: > Please approve this clean backport: > > Review: > http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-December/016200.html > JDK 9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/026b9a30e8b2 > bug: https://bugs.openjdk.java.net/browse/JDK-8067241 > > thanks, > Shanliang From rob.mckenna at oracle.com Tue Dec 23 15:48:30 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 23 Dec 2014 15:48:30 +0000 Subject: [8u-dev] Request for bulk approval of backports from JDK9 In-Reply-To: <54997A2A.2090604@oracle.com> References: <54997A2A.2090604@oracle.com> Message-ID: <54998ECE.6010806@oracle.com> Approved. May want to add noreg-self to the other bugs too. -Rob On 23/12/14 14:20, Jaroslav Bachorik wrote: > Please, approve this bunch of straight backports of JDK 9 test fixes. > > Issue : https://bugs.openjdk.java.net/browse/JDK-8034263 (Test > java/lang/management/MemoryMXBean/LowMemoryTest.java fails > intermittently) > Changeset : http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/d4a100cbbb2d > Review : > http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-December/016124.html > > Issue : https://bugs.openjdk.java.net/browse/JDK-8064441 > (java/lang/management/ThreadMXBean/Locks.java fails intermittently, > blocked on wrong object) > Changeset : http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/fae1869f4389 > Review : > http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-December/016069.html > > Issue : https://bugs.openjdk.java.net/browse/JDK-7132590 > (javax/management/remote/mandatory/notif/NotificationAccessControllerTest.java > fails in JDK8-B22) > Changeset : http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/299e420ebd63 > Review : > http://mail.openjdk.java.net/pipermail/jmx-dev/2014-August/000662.html > > No modifications to the JDK9 changesets are necessary. > > Thanks, > > -JB- From aleksej.efimov at oracle.com Sun Dec 28 11:02:59 2014 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Sun, 28 Dec 2014 14:02:59 +0300 Subject: [8u-dev] 8051641: Request for Approval: Africa/Casablanca transitions is incorrectly calculated starting from 2027 Message-ID: <549FE363.3030309@oracle.com> Hi, Can I have an approval for the backport of 8051641. The backport slightly differs from JDK9 for ZoneRulesBuilder.java. Adding the original reviewer and alias for review. Testing: All TZ related tests shows PASS result, the JPRT testing shows no failures too. Webrev: http://cr.openjdk.java.net/~aefimov/8051641/8/webrev.00/ JBS bug: https://bugs.openjdk.java.net/browse/JDK-8051641 JDK9 review: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030348.html JDK9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8bb2d5d056bf With Best Wishes, Aleksej From jaroslav.bachorik at oracle.com Mon Dec 29 10:36:20 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 29 Dec 2014 11:36:20 +0100 Subject: [8u-dev] Request for approval: 8058506 - ThreadMXBeanStateTest throws exception Message-ID: <54A12EA4.4010705@oracle.com> Please, approve this backport of a JDK 9 fix. Issue : https://bugs.openjdk.java.net/browse/JDK-8058506 Changeset : http://hg.openjdk.java.net/jdk9/dev/jdk/rev/44c35d768412 Review : http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-November/015848.html In the JDK8 backport the test/ProblemList.txt does not need to be modified as this test hasn't had been put there yet. Thanks, -JB- From rob.mckenna at oracle.com Mon Dec 29 18:08:23 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 29 Dec 2014 18:08:23 +0000 Subject: [8u-dev] 8051641: Request for Approval: Africa/Casablanca transitions is incorrectly calculated starting from 2027 In-Reply-To: <549FE363.3030309@oracle.com> References: <549FE363.3030309@oracle.com> Message-ID: <54A19897.7080906@oracle.com> Approved pending codreview. -Rob On 28/12/14 11:02, Aleksej Efimov wrote: > Hi, > > Can I have an approval for the backport of 8051641. The backport > slightly differs from JDK9 for ZoneRulesBuilder.java. Adding the > original reviewer and alias for review. > Testing: All TZ related tests shows PASS result, the JPRT testing > shows no failures too. > > Webrev: http://cr.openjdk.java.net/~aefimov/8051641/8/webrev.00/ > JBS bug: https://bugs.openjdk.java.net/browse/JDK-8051641 > JDK9 review: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030348.html > JDK9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8bb2d5d056bf > > With Best Wishes, > Aleksej From xueming.shen at oracle.com Mon Dec 29 18:18:42 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 29 Dec 2014 10:18:42 -0800 Subject: [8u-dev] 8051641: Request for Approval: Africa/Casablanca transitions is incorrectly calculated starting from 2027 In-Reply-To: <549FE363.3030309@oracle.com> References: <549FE363.3030309@oracle.com> Message-ID: <54A19B02.8000602@oracle.com> On 12/28/2014 03:02 AM, Aleksej Efimov wrote: > Hi, > > Can I have an approval for the backport of 8051641. The backport slightly differs from JDK9 for ZoneRulesBuilder.java. Adding the original reviewer and alias for review. > Testing: All TZ related tests shows PASS result, the JPRT testing shows no failures too. > > Webrev: http://cr.openjdk.java.net/~aefimov/8051641/8/webrev.00/ > JBS bug: https://bugs.openjdk.java.net/browse/JDK-8051641 > JDK9 review: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030348.html > JDK9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8bb2d5d056bf > > With Best Wishes, > Aleksej looks fine. -Sherman From ivan.gerasimov at oracle.com Mon Dec 29 21:18:14 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 30 Dec 2014 00:18:14 +0300 Subject: [8u-dev] Request for approval to backport: 8068338: Better message about incompatible zlib in Deflater.init Message-ID: <54A1C516.6090803@oracle.com> Hi! Would you please approve backporting of this cleanup fix? Unshuffled patch applies cleanly. Bug: https://bugs.openjdk.java.net/browse/JDK-8068338 Jdk9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/be91019db7bd Review: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030493.html Sincerely yours, Ivan From rob.mckenna at oracle.com Mon Dec 29 22:39:23 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 29 Dec 2014 22:39:23 +0000 Subject: [8u-dev] Request for approval to backport: 8068338: Better message about incompatible zlib in Deflater.init In-Reply-To: <54A1C516.6090803@oracle.com> References: <54A1C516.6090803@oracle.com> Message-ID: <54A1D81B.9070205@oracle.com> Approved. -Rob On 29/12/14 21:18, Ivan Gerasimov wrote: > Hi! > > Would you please approve backporting of this cleanup fix? > Unshuffled patch applies cleanly. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8068338 > Jdk9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/be91019db7bd > Review: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030493.html > > Sincerely yours, > Ivan > From joe.darcy at oracle.com Tue Dec 30 00:25:33 2014 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 29 Dec 2014 16:25:33 -0800 Subject: JBS policy around backing out of bug fixes : was(Re: [8u40] Request for Approval: 8067039: Revert changes to annotation attribute generation) In-Reply-To: <548E769D.3030503@oracle.com> References: <5489ADAE.9080008@oracle.com> <5489AFA9.6050207@oracle.com> <548A4306.1050607@oracle.com> <548B0C5C.4040207@oracle.com> <548B8B4F.8010300@oracle.com> <548DADCD.3090309@oracle.com> <548E28DA.2070201@oracle.com> <548E66A5.7050002@oracle.com> <548E769D.3030503@oracle.com> Message-ID: <54A1F0FD.4060404@oracle.com> Catching up on email, On 12/14/2014 9:50 PM, David Holmes wrote: > On 15/12/2014 2:42 PM, joe darcy wrote: >> Hello, >> >> On 12/14/2014 4:18 PM, David Holmes wrote: >>> On 15/12/2014 1:33 AM, Se?n Coffey wrote: >>>> >>>> On 13/12/2014 00:41, David Holmes wrote: >>>>> Sean, >>>>> >>>>> This issue was discussed at some length when JBS was being set up. >>>> David, >>>> >>>> I realise there was alot of discussion around JBS process when it was >>>> being set up. IIRC, the custom verification field was a request from >>>> Quality team to track bug fixes. For that reason, I imagine it's of >>>> most >>>> interest to quality team. I normally focus on Status/Resolution >>>> fields. >>>> Could I make a proposal that we mark anit-deltas with Resolution = Fix >>>> Failed ? Is there any reason we can't ? >>> >>> You mean the bug for which the anti-delta was needed should be marked >>> Resolution=fix-failed? I don't have a problem with that, but these >>> aren't my rules. >>> >>> It helps to keep JIRA queries >>>> more simple and avoids having to look up a 3rd field in order to >>>> capture >>>> the true state of a bug fix. >>>> >>>> Here's another example of a bug fix one would think was fixed in >>>> JDK 8 : >>>> https://bugs.openjdk.java.net/browse/JDK-8025198 >>> >>> It is fixed in the JDK-8. The "anti-delta" was only a partial >>> anti-delta for the files that had been modified unintentionally. The >>> actual fix is still present. >>> >> >> I've checked my JBS notes. "Fix failed" wasn't one of the resolution >> values available when JBS went live and I'm not sure when it was added. > > I thought I didn't recall this being an option from previous discussion. > >> In any case, for the JDK project, I don't think that resolution value >> should be used; the JBS overview >> >> https://wiki.openjdk.java.net/display/general/JBS+Overview >> >> documents the field values I mentioned earlier (status = >> resolved/closed, resolution = fixed, verification = fix failed). >> >> A truly failed fix is an exceptional event and I don't really think it >> is worthwhile to devote a resolution value to that case. > > ??? If the value already exists then why shouldn't we use it to > reflect a situation that it describes very well ?? I have a different first reaction: we should not be allowing changes to the JBS state model without explicit discussion and consideration. > Backing out fixes with unintended consequences is something that the > hotspot processes are advocating more strongly now - so this might not > be as rare as it has been. > At the time of transitioning to JBS, "Fix failed" was vanishingly rare -- from memory perhaps a dozen instances out of 100,000+ bugs. (This rarity was moreso a reflection of processes that did not use the value rather than the absence of fixes which failed ;-) The use of "fix failed" may become more common with procedural changes. My general thinking is that a resolution of fixed mean "a changeset was pushed for this bug into a release." Coupled with the policy of not re-using bug ids for multiple fixes, "a changeset was pushed for this bug" remains true whether or not it was a good changeset or a bad one and whether or not it had to be modified after being pushed, the largest modification being fully backed out. I would guess a "failed fix" is more often an incomplete or somewhat buggy fix rather than a fix that needs to be anti-delta'ed. My sense fix "give me a list of changes in a release" is closer what people want when doing a query for fixVerion = $RELEASE and resolution = fixed than "give me a list of changes in a release that did not need subsequent revision." Therefore, I don't think "fix failed" (yet) rises to the level of a condition that needs its own resolution value and those interested in identifying such bugs should uses a query with another term. HTH, -Joe From ygaevsky at azulsystems.com Tue Dec 30 11:47:18 2014 From: ygaevsky at azulsystems.com (Yuri Gaevsky) Date: Tue, 30 Dec 2014 11:47:18 +0000 Subject: Request for approval: 6364329: jstat displays "invalid argument count" with usage Message-ID: Please approve backport of JDK-6364329 to 8u. Changes apply cleanly to jdk8u after shuffling path names. Bug: https://bugs.openjdk.java.net/browse/JDK-6364329 Review thread: http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-November/016034.html Changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/59f5ad46377d Webrev: http://cr.openjdk.java.net/~ygaevsky/6364329.jdk8u/ Thank you, -Yuri From rob.mckenna at oracle.com Tue Dec 30 15:09:48 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 30 Dec 2014 15:09:48 +0000 Subject: Request for approval: 6364329: jstat displays "invalid argument count" with usage In-Reply-To: References: Message-ID: <54A2C03C.3030405@oracle.com> Approved. -Rob On 30/12/14 11:47, Yuri Gaevsky wrote: > Please approve backport of JDK-6364329 to 8u. > > Changes apply cleanly to jdk8u after shuffling path names. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-6364329 > Review thread: > http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-November/016034.html > Changeset: > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/59f5ad46377d > Webrev: > http://cr.openjdk.java.net/~ygaevsky/6364329.jdk8u/ > > Thank you, > -Yuri From ygaevsky at azulsystems.com Tue Dec 30 15:43:30 2014 From: ygaevsky at azulsystems.com (Yuri Gaevsky) Date: Tue, 30 Dec 2014 15:43:30 +0000 Subject: Request for approval: 6364329: jstat displays "invalid argument count" with usage In-Reply-To: <54A2C03C.3030405@oracle.com> References: <54A2C03C.3030405@oracle.com> Message-ID: Thanks a lot, Rob. Happy New 2015 Year! Best regards, -Yuri -----Original Message----- From: Rob McKenna [mailto:rob.mckenna at oracle.com] Sent: Tuesday, December 30, 2014 6:10 PM To: Yuri Gaevsky; jdk8u-dev at openjdk.java.net Subject: Re: Request for approval: 6364329: jstat displays "invalid argument count" with usage Approved. -Rob On 30/12/14 11:47, Yuri Gaevsky wrote: > Please approve backport of JDK-6364329 to 8u. > > Changes apply cleanly to jdk8u after shuffling path names. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-6364329 > Review thread: > http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-November/016034.html > Changeset: > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/59f5ad46377d > Webrev: > http://cr.openjdk.java.net/~ygaevsky/6364329.jdk8u/ > > Thank you, > -Yuri From jaroslav.bachorik at oracle.com Wed Dec 31 10:23:29 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 31 Dec 2014 11:23:29 +0100 Subject: [8u-dev] Request for approval: 8062896 - TEST_BUG: java/lang/Thread/ThreadStateTest.java can't compile with change for 8058506 Message-ID: <54A3CEA1.3040702@oracle.com> Please, approve this backport of a JDK 9 fix. Issue : https://bugs.openjdk.java.net/browse/JDK-8062896 Changeset : http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/a8b8a1a9155f Review : http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-November/015877.html No further adjustments to the changeset are necessary. Thanks, -JB- From rob.mckenna at oracle.com Wed Dec 31 14:33:23 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 31 Dec 2014 14:33:23 +0000 Subject: [8u-dev] Request for approval: 8062896 - TEST_BUG: java/lang/Thread/ThreadStateTest.java can't compile with change for 8058506 In-Reply-To: <54A3CEA1.3040702@oracle.com> References: <54A3CEA1.3040702@oracle.com> Message-ID: <54A40933.1000409@oracle.com> Approved. I believe this still needs the noreg-self keyword mind you. -Rob On 31/12/14 10:23, Jaroslav Bachorik wrote: > Please, approve this backport of a JDK 9 fix. > > Issue : https://bugs.openjdk.java.net/browse/JDK-8062896 > Changeset : http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/a8b8a1a9155f > Review : > http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-November/015877.html > > No further adjustments to the changeset are necessary. > > Thanks, > > -JB-