From gnu.andrew at redhat.com Tue Sep 1 02:50:37 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 1 Sep 2020 03:50:37 +0100 Subject: [RAMPDOWN] 8u-dev OPEN for 8u282 (jdk8u-fix-yes required) Message-ID: <20200901025037.GA1375535@stopbrexit> 8u-dev is now open for development on 8u272-b01. Pushes require jdk8u-fix-yes as usual. As previously stated, 8u will be open for jdk8u-critical-yes pushes once promotion of jdk8u272-b06 is complete. Please note that the TLSv1.3 backport was integrated as part of jdk8u272-b06, and so pre-release testing for 8u272 should focus on ensuring this works as intended with no regressions. For further details, including the full timeline and contribution procedure, see the OpenJDK 8u wiki: https://wiki.openjdk.java.net/display/jdk8u/Main Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From aph at redhat.com Tue Sep 1 08:05:20 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 1 Sep 2020 09:05:20 +0100 Subject: [8u] RFR: 8252395: [8u] --with-native-debug-symbols=external doesn't include debuginfo files for binaries In-Reply-To: <920cb027de417118b3522d4ba20baf04c45f9621.camel@redhat.com> References: <920cb027de417118b3522d4ba20baf04c45f9621.camel@redhat.com> Message-ID: <84178a29-89ac-8b17-c304-96606c8b1218@redhat.com> On 31/08/2020 12:44, Severin Gehwolf wrote: > Sorry, wrong webrev. Now corrected. > > On Mon, 2020-08-31 at 10:02 +0200, Severin Gehwolf wrote: >> Hi, >> >> Could I get a reivew of this 8u specific bug please? When configured >> --with-native-debug-symbols=external,zipped the resulting external >> debuginfo files for binaries (in images/bin folder) aren't there. >> >> In OpenJDK 8u there is some special casing involved for bin/java and >> bin/unpack200. Thus, I had to special case them for the debuginfo >> variant files too otherwise those files would be missing in the images >> folders (j2sdk-image, j2re-image). >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8252395 > > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8252395/02/webrev/ > >> >> Testing: Build in configs --with-native-debugsymbols={zipped,external,internal,none} >> on Linux x86 and manually debugging some launcher code. Works now >> with symbols. Symbols were missing before this patch. OK. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From shade at redhat.com Tue Sep 1 09:56:59 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 1 Sep 2020 11:56:59 +0200 Subject: [8u] RFR 8250928: JFR: Improve hash algorithm for stack traces In-Reply-To: References: Message-ID: <8f1d51a2-de4c-35f6-dfe0-076496054aa1@redhat.com> On 8/31/20 7:11 PM, Jaroslav Bachor?k wrote: > Please, review this backport of a hash-collision reducing fix in JFR > stacktrace values from the main line. > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8250928 > Webrev: http://cr.openjdk.java.net/~jbachorik/8250928/8u/webrev/ 8u backport looks fine. -- Thanks, -Aleksey From shade at redhat.com Tue Sep 1 10:01:00 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 1 Sep 2020 12:01:00 +0200 Subject: [8u] RFR 8250928: JFR: Improve hash algorithm for stack traces In-Reply-To: <8f1d51a2-de4c-35f6-dfe0-076496054aa1@redhat.com> References: <8f1d51a2-de4c-35f6-dfe0-076496054aa1@redhat.com> Message-ID: <581363a3-2438-1601-7139-9e6cc68f0671@redhat.com> On 9/1/20 11:56 AM, Aleksey Shipilev wrote: > On 8/31/20 7:11 PM, Jaroslav Bachor?k wrote: >> Please, review this backport of a hash-collision reducing fix in JFR >> stacktrace values from the main line. >> >> JIRA: https://bugs.openjdk.java.net/browse/JDK-8250928 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8250928/8u/webrev/ > > 8u backport looks fine. Oh wait, hold on a sec. The original changeset [1] only changes the bit in JfrStackTrace::record_safe. Why does this backport change JfrStackTrace::record_safe and JfrStackTrace::record_thread? -- Thanks, -Aleksey [1] https://hg.openjdk.java.net/jdk/jdk/file/c3cc9ac0ede2/src/hotspot/share/jfr/recorder/stacktrace/jfrStackTrace.cpp From sgehwolf at redhat.com Tue Sep 1 11:54:05 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 01 Sep 2020 13:54:05 +0200 Subject: [8u] RFR 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect In-Reply-To: References: Message-ID: <6b0a8690a0d829cb283679b62e61001fa027b65f.camel@redhat.com> On Sat, 2020-08-29 at 09:24 -0400, Zhengyu Gu wrote: > I would like to backport this patch for parity with Oracle 8u271. > > The original patch does not apply cleanly. The conflicts on the fixes > are minors, can be easily resolved manually. > > 1) LdapTimeoutTest.java is not in ProblemList.txt in 8u > 2) Copyright lines in LdapTimeoutTest.java do not match > 3) Import lines in BaseLdapServer.java do not match > > > However, LdapTimeoutTest.java uses some new language features and APIs > that do not exist in 8u. It also uses new test library that needs to map > back to 8u test library. > > /* > * @test > - * @library /test/lib > + * @library /lib/testlibrary > * lib/ > * @run testng/othervm LdapTimeoutTest > * @bug 7094377 8000487 6176036 7056489 8151678 > @@ -59,7 +59,7 @@ > import static java.lang.String.format; > import static java.util.concurrent.TimeUnit.MILLISECONDS; > import static java.util.concurrent.TimeUnit.NANOSECONDS; > -import static jdk.test.lib.Utils.adjustTimeout; > +import static jdk.testlibrary.Utils.adjustTimeout; > import static org.testng.Assert.assertTrue; > import static org.testng.Assert.expectThrows; > > @@ -120,7 +120,7 @@ > executorService.shutdown(); > } > int failedCount = 0; > - for (var f : futures) { > + for (Future f : futures) { > try { > f.get(); > } catch (ExecutionException e) { > @@ -283,11 +283,14 @@ > > @Override > protected void beforeAcceptingConnections() { > - starting.completeAsync(() -> null); > + CompletableFuture.supplyAsync(() -> null) > + .whenComplete((input, exception) -> { > + starting.complete(null); > + }); > } > > public CompletableFuture starting() { > - return starting.copy(); > + return starting.toCompletableFuture(); > } > } > > Test: > jdk_other Could you please post a full webrev URL of the patch? Thanks, Severin From zgu at redhat.com Tue Sep 1 12:21:05 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 1 Sep 2020 08:21:05 -0400 Subject: [8u] RFR 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect In-Reply-To: <6b0a8690a0d829cb283679b62e61001fa027b65f.camel@redhat.com> References: <6b0a8690a0d829cb283679b62e61001fa027b65f.camel@redhat.com> Message-ID: <095da0e8-eeb3-c94f-ea2c-078a823c0ad6@redhat.com> Oops, missed that. 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8151678-8u/webrebv.00/ Thanks, -Zhengyu On 9/1/20 7:54 AM, Severin Gehwolf wrote: > On Sat, 2020-08-29 at 09:24 -0400, Zhengyu Gu wrote: >> I would like to backport this patch for parity with Oracle 8u271. >> >> The original patch does not apply cleanly. The conflicts on the fixes >> are minors, can be easily resolved manually. >> >> 1) LdapTimeoutTest.java is not in ProblemList.txt in 8u >> 2) Copyright lines in LdapTimeoutTest.java do not match >> 3) Import lines in BaseLdapServer.java do not match >> >> >> However, LdapTimeoutTest.java uses some new language features and APIs >> that do not exist in 8u. It also uses new test library that needs to map >> back to 8u test library. >> >> /* >> * @test >> - * @library /test/lib >> + * @library /lib/testlibrary >> * lib/ >> * @run testng/othervm LdapTimeoutTest >> * @bug 7094377 8000487 6176036 7056489 8151678 >> @@ -59,7 +59,7 @@ >> import static java.lang.String.format; >> import static java.util.concurrent.TimeUnit.MILLISECONDS; >> import static java.util.concurrent.TimeUnit.NANOSECONDS; >> -import static jdk.test.lib.Utils.adjustTimeout; >> +import static jdk.testlibrary.Utils.adjustTimeout; >> import static org.testng.Assert.assertTrue; >> import static org.testng.Assert.expectThrows; >> >> @@ -120,7 +120,7 @@ >> executorService.shutdown(); >> } >> int failedCount = 0; >> - for (var f : futures) { >> + for (Future f : futures) { >> try { >> f.get(); >> } catch (ExecutionException e) { >> @@ -283,11 +283,14 @@ >> >> @Override >> protected void beforeAcceptingConnections() { >> - starting.completeAsync(() -> null); >> + CompletableFuture.supplyAsync(() -> null) >> + .whenComplete((input, exception) -> { >> + starting.complete(null); >> + }); >> } >> >> public CompletableFuture starting() { >> - return starting.copy(); >> + return starting.toCompletableFuture(); >> } >> } >> >> Test: >> jdk_other > > Could you please post a full webrev URL of the patch? > > Thanks, > Severin > From sgehwolf at redhat.com Tue Sep 1 12:23:32 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 01 Sep 2020 14:23:32 +0200 Subject: [8u] RFR: 8244225: stringop-overflow warning on strncpy call from compile_the_world_in Message-ID: Hi, Could I please get a review of this 8u backport? The JDK 11u patch doesn't apply cleanly since string_ends_with() function isn't in 8u. Therefore, the context is different enough for the patch to not apply cleanly. This is in a NOT_PRODUCT() path of the VM and should be low risk. I'm proposing this for review for JDK 8u parity. Bug: https://bugs.openjdk.java.net/browse/JDK-8244225 webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8244225/01/webrev/ Testing: Manual on a fastdebug build of the JVM. Compiling classLoader.o with -Wstringop-overflow. Warning present before the fix and it's gone after. Thoughts? I'm not sure if this is worth the churn of doing the backport, though. Thanks, Severin From shade at redhat.com Tue Sep 1 12:28:28 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 1 Sep 2020 14:28:28 +0200 Subject: [8u] RFR: 8244225: stringop-overflow warning on strncpy call from compile_the_world_in In-Reply-To: References: Message-ID: <6c991ccd-fbcb-b84d-ff58-92eaa9023756@redhat.com> On 9/1/20 2:23 PM, Severin Gehwolf wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8244225 > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8244225/01/webrev/ 8u backport looks fine. > Thoughts? I'm not sure if this is worth the churn of doing the > backport, though. I'd prefer to fix warnings in non-risky places, because they obscure the warnings in other critical places. -- Thanks, -Aleksey From akashche at redhat.com Tue Sep 1 13:31:43 2020 From: akashche at redhat.com (Alex Kashchenko) Date: Tue, 1 Sep 2020 14:31:43 +0100 Subject: [8u] RFR: 8185500: [TESTBUG] Add keywords headful/printer in java/awt and javax tests. In-Reply-To: <37e50eaf-79ee-48d6-dc8a-2d03dc70073d@redhat.com> References: <37e50eaf-79ee-48d6-dc8a-2d03dc70073d@redhat.com> Message-ID: Hi, On 7/6/20, Alex Kashchenko wrote: > Hi, > > Please review the backport of JDK-8185500 to 8u: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8185500 > > 10 change: https://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/b762aafa34e3 > > 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8185500/webrev.00 > > This change adds "headful" and "printer" keywords to a number of client > test, 129 tests are changed in jdk10, 63 of them are present in 8u. > > Patch is altered for 8u leaving only the tests that are present, some > tests also have required changes to jtreg tags section and copyright > year. There are no changes to test code itself. > > Testing: checked that modified tests can be selected correctly with > "headful" and "printer" keywords: > > Before: > > $ jtreg [...] -l @list.txt > > Tests found: 63 > > After: > > $ jtreg [...] -l -k:headful @list.txt > > Tests found: 53 > > $ jtreg [...] -l -k:printer @list.txt > > Tests found: 10 > > $ jtreg [...] -l -k:"(headful|printer)" @list.txt > > Tests found: 63 > > Note, some tests include "os.family" requirement, so the numbers above > may differ. Adding Jira traces for the tests, that were excluded from this backport: test/java/awt/Choice/ChoiceHiDpi/ChoiceTest.java 8144594: HiDPI: awt.Choice looks improperly (Win 8) test/java/awt/Dialog/NestedDialogs/Modal/NestedModalDialogTest.java test/java/awt/Dialog/NestedDialogs/Modeless/NestedModelessDialogTest.java 8160266: [macosx] NestedModalDialogTest.java and NestedModelessDialogTest.java tests does not run with current JDK codebase after taking the files from MACOSX_PORT test/java/awt/FileDialog/FileDialogIconTest/FileDialogIconTest.java 8157163: AWT FileDialog does not inherit icon image from parent Frame test/java/awt/Focus/FocusTraversalPolicy/ButtonGroupLayoutTraversal/ButtonGroupLayoutTraversalTest.java 8154043: Fields not reachable anymore by tab-key, because of new tabbing behaviour of radio button groups. test/java/awt/Focus/RequestFocusByCause/RequestFocusByCauseTest.java 8154434: Open the request focus methods of the java.awt.Component which accept FocusEvent.Cause test/java/awt/Frame/8158918/SetExtendedState.java 8158918: setExtendedState(1) for maximized Frame results in state==7 test/java/awt/Frame/DecoratedFrameInsets/DecoratedFrameInsetsTest.java 8165619: Frame is not repainted if created in state=MAXIMIZED_BOTH on Unity test/java/awt/Frame/SetMaximizedBounds/MaximizedMovedWindow.java 8065739: [macosx] Frame warps to lower left of screen when displayed test/java/awt/Frame/SetMaximizedBounds/SetMaximizedBounds.java 8039279: Move awt tests to openjdk repository test/java/awt/FullScreen/CurrentDisplayModeTest/CurrentDisplayModeTest.java 8167486: Device.getDisplayMode() doesn't report refresh rate on Linux in case of dual screen test/java/awt/GraphicsDevice/DisplayModes/CompareToXrandrTest.java 8022810: Cannot list all the available display modes on Ubuntu linux in case of two screen devices test/java/awt/Robot/HiDPIMouseClick/HiDPIRobotMouseClick.java test/java/awt/Robot/HiDPIScreenCapture/HiDPIRobotScreenCaptureTest.java 8073320: Windows HiDPI Graphics support test/java/awt/Scrollbar/ScrollbarMouseWheelTest/ScrollbarMouseWheelTest.java 8015900: [TEST_BUG] ScrollbarMouseWheelTest failed on ubuntu 12 with unity and unity 2D test/java/awt/SplashScreen/MultiResolutionSplash/unix/UnixMultiResolutionSplashTest.java 8145174: HiDPI splash screen support on Linux test/java/awt/TextArea/AutoScrollOnSelectAndAppend/AutoScrollOnSelectAndAppend.java 8151588: Press the button first two times, the 'First' and 'Next' didn't show test/java/awt/TextArea/OverScrollTest/OverScrollTest.java 8149636: TextField flicker & over scroll when selection scrolls beyond the bounds of TextField test/java/awt/TextField/OverScrollTest/OverScrollTest.java 8149636: TextField flicker & over scroll when selection scrolls beyond the bounds of TextField test/java/awt/Window/GetScreenLocation/GetScreenLocationTest.java 8036915: setLocationRelativeTo stopped working in Ubuntu 13.10 (Unity) test/java/awt/Window/SetWindowLocationByPlatformTest/SetWindowLocationByPlatformTest.java 8025130: [macosx] Frame setLocationByPlatform has no effect under Mac OS X test/java/awt/hidpi/properties/HiDPIPropertiesWindowsTest.java 8073320: Windows HiDPI Graphics support test/java/awt/image/multiresolution/Corrupted2XImageTest.java 8142406: [TEST] MultiResolution image: need test to cover the case when @2x image is corrupted test/java/awt/keyboard/AllKeyCode/AllKeyCode.java 8149456: [macosx] robot.keyPress do not generate key events (keyPressed and keyReleased) for function keys F13 to F19 test/java/awt/keyboard/AltPlusNumberKeyCombinationsTest/AltPlusNumberKeyCombinationsTest.java 8044172: [TEST_BUG] Move regtests for 4523758 and AltPlusNumberKeyCombinationsTest to jdk test/java/awt/print/PrinterJob/CheckPrivilege.java test/java/awt/print/PrinterJob/PaintText.java test/java/awt/print/PrinterJob/PrintTextPane.java 8038723: Openup some PrinterJob tests test/javax/swing/JButton/8151303/PressedIconTest.java 8151303: [macosx] [hidpi] JButton's low-res. icon is visible when clicking on it test/javax/swing/JComboBox/6567433/UpdateUIRecursionTest.java 6567433: JComponent.updateUI() may create StackOverflowError test/javax/swing/JComboBox/8041909/ActionListenerExceptionTest.java 8041909: Uncaught exceptions in JComboBox listeners cause listener not to receive events test/javax/swing/JComboBox/WindowsComboBoxSize/WindowsComboBoxSizeTest.java 8179027: JComboBox too small under Windows LAF test/javax/swing/JFileChooser/8010718/bug8010718.java 8010718: javax/swing/JFileChooser/8013442/Test8013442.java fails test/javax/swing/JFileChooser/8152677/SelectAllFilesFilterTest.java 8152677: [macosx] All files filter can't be selected in JFileChooser test/javax/swing/JInternalFrame/6288609/TestJInternalFrameDispose.java 6288609: JInternalFrame.setDefaultCloseOperation() interferes with "close" behavior test/javax/swing/JInternalFrame/8075314/bug8075314.java 8075314: All the InternalFrames will be maximized after maximizing only one of the InternalFrame with WindowsLookAndFeel test/javax/swing/JInternalFrame/8145060/TestJInternalFrameMinimize.java 8145060: Minimizing a JInternal frame not shifting focus to frame below it test/javax/swing/JInternalFrame/8160248/JInternalFrameDraggingTest.java 8160248: Dragged internal frame leaves artifacts for floating point ui scale test/javax/swing/JInternalFrame/DockIconRepaint/DockIconRepaint.java 8144166: [macosx] Test java/awt/Component/CompEventOnHiddenComponent/CompEventOnHiddenComponent.java fails test/javax/swing/JList/6567433/UpdateUIRecursionTest.java 6567433: JComponent.updateUI() may create StackOverflowError test/javax/swing/JList/8161483/Bug8161483.java 8161483: Implement AccessibleAction interface in JList.AccessibleJList.AccessibleJListChild test/javax/swing/JMenu/6538132/bug6538132.java 8063107: Change open swing regression tests to avoid sun.awt.SunToolkit.realSync, part 2 test/javax/swing/JMenu/8067346/bug8067346.java 8067346: Swing submenu has a changed starting offset test/javax/swing/JMenuItem/8139169/ScreenMenuBarInputTwice.java 8139169: [macosx] Action registered for keyboard shortcut is called twice test/javax/swing/JMenuItem/8158566/CloseOnMouseClickPropertyTest.java 8158566: Provide a Swing property to not close toggle menu items on mouse click test/javax/swing/JMenuItem/ClickMenuTestManual/ClickMenuTestManual.java 8158230: [macosx] ActionEvent is not fired for menu item with option apple.laf.useScreenMenuBar test/javax/swing/JOptionPane/8081019/bug8081019.java 8081019: Check peer to null in CPlatformWindow.checkZoom() test/javax/swing/JPopupMenu/6217905/bug6217905.java 8063107: Change open swing regression tests to avoid sun.awt.SunToolkit.realSync, part 2 test/javax/swing/JTable/6567433/UpdateUIRecursionTest.java test/javax/swing/JTableHeader/6567433/UpdateUIRecursionTest.java 6567433: JComponent.updateUI() may create StackOverflowError test/javax/swing/JTextArea/ScrollbarFlicker/ScrollFlickerTest.java 8160246: Regression: 4410243 reproducible with GTK LaF test/javax/swing/JTree/6567433/UpdateUIRecursionTest.java 6567433: JComponent.updateUI() may create StackOverflowError test/javax/swing/ProgressMonitor/ProgressMonitorEscapeKeyPress.java 8065861: Pressing Esc does not set 'canceled' property of ProgressMonitor test/javax/swing/UI/UnninstallUIMemoryLeaks/UnninstallUIMemoryLeaks.java 8134947: [macosx] Various memory leaks in Aqua look and feel test/javax/swing/plaf/basic/6866751/bug6866751.java 6866751: J2SE_Swing_Reg: the caret disappears when moving to the end of the line. test/javax/swing/plaf/basic/BasicHTML/4960629/bug4960629.java 8135176: Moving test from javax/swing/plaf/basic/BasicHTML/4960629 to test/javax/swing/plaf/basic/BasicHTML/4960629 test/javax/swing/plaf/windows/6921687/bug6921687.java 6921687: Mnemonic disappears after repeated attempts to open menu items using mnemonics test/javax/swing/text/GlyphPainter2/6427244/bug6427244.java 8144015: [PIT] failures of text layout font tests test/javax/swing/text/Utilities/8142966/SwingFontMetricsTest.java 8142966: Wrong cursor position in text components on HiDPI display test/sun/awt/image/OffScreenImageSource/ImageConsumerUnregisterTest.java 8160421: Regression: JDK-8139192 causes NPE in java.awt.Toolkit.createCustomCursor() test/sun/java2d/xrender/HugeGradientTest.java 8162591: All existing gradient paint implementations have issues with coordinates/sizes larger than Short.MAX_VALUE (exactly) on any Linux systems -- -Alex From akashche at redhat.com Tue Sep 1 13:36:26 2020 From: akashche at redhat.com (Alex Kashchenko) Date: Tue, 1 Sep 2020 14:36:26 +0100 Subject: [8u] RFR: 8191678: [TESTBUG] Add keyword headful in java/awt and javax tests. In-Reply-To: <20200806051736.GB472692@stopbrexit> References: <20200806051736.GB472692@stopbrexit> Message-ID: Hi, On 8/6/20, Andrew Hughes wrote: > On 11:53 Mon 06 Jul , Alex Kashchenko wrote: >> Hi, >> >> Please review the backport of JDK-8191678 to 8u: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8191678 >> >> Original change: https://hg.openjdk.java.net/jdk/jdk/rev/50d61f4b5d1a >> >> 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8191678/webrev.00/ >> >> This change adds "headful" keyword to a number of client tests. Only a >> single test (FocusTransitionTest) from this patch is present in 8u - only >> changes to it are backported. >> >> Testing: checked that changed test can be selected with "headful" >> keyword. >> >> -- >> -Alex >> > > test/jdk/java/awt/Component/GetScreenLocTest/ComponentGetLocationOnScreenNPETest.java: > > JDK-8189204: Possible NPE in Component::getLocationOnScreen(), not flagged > for backport > > test/jdk/java/awt/Dialog/SiblingChildOrder/SiblingChildOrderTest.java: > > JDK-8190230: [macosx] Order of overlapping of modal dialogs is wrong, not > flagged for backport > > jdk/test/javax/swing/DefaultButtonModel/DefaultButtonModelCrashTest.java: > > 8182577: Exception when Tab key moves focus to a JCheckbox with a custom > ButtonModel, not flagged for backport > > test/jdk/javax/swing/GraphicsConfigNotifier/TestMultiScreenGConfigNotify.java: > > 8178025: HiDPI with non-integer scale factor - SPANs in HTML are rendered > overlapping each other, not flagged for backport > > test/jdk/javax/swing/JButton/TestGlyphBreak.java: > > 8191428: Regression: Swing button label wrapping with hidpi, not flagged for > backport > > jdk/test/javax/swing/JComboBox/8182031/ComboPopupTest.java: > > 8182031: Swing's ComboBox Popup opens and closes immediately, not flagged > for backport > > test/jdk/javax/swing/JMenu/8178430/LabelDotTest.java: > > 8178430: JMenu in GridBagLayout flickers when label text shows "..." and is > updated, not flagged for backport > > test/jdk/javax/swing/JTextArea/TestTabSize.java: > > 8187957: Tab Size does not work correctly in JTextArea, not flagged for > backport > > jdk/test/javax/swing/dnd/8139050/NativeErrorsInTableDnD.java: > > 8139050: -[AWTView draggingEnded:]: unrecognized selector message during > drag and drop, not flagged for backport > > jdk/test/javax/swing/plaf/nimbus/TestNimbusOverride.java: > > 8043315: Nimbus: Setting Nimbus.Overrides property affects custom keymap > installation, not flagged for backport > > test/jdk/javax/swing/text/DefaultCaret/HidingSelection/HidingSelectionTest.java: > > 8188081: Text selection does not clear after focus is lost, not flagged for > backport > > So all seem safe to exclude. In future, please provide such evidence > for making such exclusions, especially when the vast majority of the > patch is being dropped, as in this case. > > We don't want to drop such changes if another backport is about to > introduce that test. Thanks for your comments! I've added pointers to Jira for the similar backport of JDK-8185500: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-September/012608.html -- -Alex From sgehwolf at redhat.com Tue Sep 1 13:37:56 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 01 Sep 2020 15:37:56 +0200 Subject: [8u] RFR 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect In-Reply-To: <095da0e8-eeb3-c94f-ea2c-078a823c0ad6@redhat.com> References: <6b0a8690a0d829cb283679b62e61001fa027b65f.camel@redhat.com> <095da0e8-eeb3-c94f-ea2c-078a823c0ad6@redhat.com> Message-ID: On Tue, 2020-09-01 at 08:21 -0400, Zhengyu Gu wrote: > 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8151678-8u/webrebv.00/ This seems OK to me. Thanks, Severin From sgehwolf at redhat.com Tue Sep 1 13:39:10 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 01 Sep 2020 15:39:10 +0200 Subject: [8u] RFR: 8244225: stringop-overflow warning on strncpy call from compile_the_world_in In-Reply-To: <6c991ccd-fbcb-b84d-ff58-92eaa9023756@redhat.com> References: <6c991ccd-fbcb-b84d-ff58-92eaa9023756@redhat.com> Message-ID: <21ec77909064538f5393b65de1ec049fa10c4ba4.camel@redhat.com> On Tue, 2020-09-01 at 14:28 +0200, Aleksey Shipilev wrote: > On 9/1/20 2:23 PM, Severin Gehwolf wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8244225 > > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8244225/01/webrev/ > > 8u backport looks fine. Thanks for the review! Cheers, Severin From zgu at redhat.com Tue Sep 1 14:25:04 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 1 Sep 2020 10:25:04 -0400 Subject: [8u] RFR 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect In-Reply-To: References: <6b0a8690a0d829cb283679b62e61001fa027b65f.camel@redhat.com> <095da0e8-eeb3-c94f-ea2c-078a823c0ad6@redhat.com> Message-ID: <81b5b8e7-915e-e1b4-eb61-67de2e42cea1@redhat.com> Thanks for the review and tagged. -Zhengyu On 9/1/20 9:37 AM, Severin Gehwolf wrote: > On Tue, 2020-09-01 at 08:21 -0400, Zhengyu Gu wrote: >> 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8151678-8u/webrebv.00/ > > This seems OK to me. > > Thanks, > Severin > From hohensee at amazon.com Tue Sep 1 19:44:41 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 1 Sep 2020 19:44:41 +0000 Subject: RFR/RFA (M): 8185003: JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument In-Reply-To: References: Message-ID: <9645ACAC-4A08-4154-B1E1-BF1D9E7CBFA0@amazon.com> Hi, I've re-finalized the CSR after Volker's re-review. See https://bugs.openjdk.java.net/browse/JDK-8251498. It now says we won't update JMM_VERSION. I've also updated the webrevs to reflect the CSR changes and to target 8u282. jdk: http://cr.openjdk.java.net/~phh/8185003/webrev.8u.jdk.07/ hotspot: http://cr.openjdk.java.net/~phh/8185003/webrev.8u.hotspot.07/ Thanks, Paul ?On 8/26/20, 12:22 PM, "jdk8u-dev on behalf of Hohensee, Paul" wrote: +Joe for an opinion. I agree. I've added a comment to the CSR (https://bugs.openjdk.java.net/browse/JDK-8251498) and moved it back to Draft. "Volker Simonis has pointed out in https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-August/012557.html that when we backport a JMM feature, we're actually updating the existing JMM version specification rather than transitioning to a new one. There was a bit of recognition of this in https://bugs.openjdk.java.net/browse/JDK-8249101, where the @since javadoc tag was updated to 11.0.9 rather than 14. Imo, Volker makes a good argument for leaving the JMM version alone when doing JMM backports. If we adopt this approach, the JDK 11 JMM version should also be reverted." Thanks, Paul On 8/26/20, 10:18 AM, "Volker Simonis" wrote: Hi Paul, thanks for adapting your change. Please find my comments in-line below: On Tue, Aug 25, 2020 at 10:28 PM Hohensee, Paul wrote: > > :) > > New webrevs following Volker's suggestion. > > http://cr.openjdk.java.net/~phh/8185003/webrev.8u.jdk.06/ Looks good except JNI_OnLoad() in "management.c" where I'd change the call to "JVM_GetManagement(JMM_VERSION)" back to "JVM_GetManagement(JMM_VERSION_1_0)". See discussion below... > http://cr.openjdk.java.net/~phh/8185003/webrev.8u.hotspot.06/ > Looks good except Management::get_jmm_interface(): 2396 if (version == JMM_VERSION) { 2397 return (void*) &jmm_interface; 2398 } You still check for "JMM_VERSION" which is now "0x20020000" and thus incompatible with the old value of "JMM_VERSION_1 = 0x20010000". This will break compatibility with clients compiled against jmm.h before this change. It should therefore remain unchanged: if (version == JMM_VERSION_1_0) { return (void*) &jmm_interface; } I think the variant "if (version == JMM_VERSION_1_0 || version == JMM_VERSION)" which we've briefly discussed wouldn't work either because a binary "JMM_VERSION_2" client would expect that "DumpThreads" will have the additional "maxDepths" argument and crash. So we can't have binary compatibility with both, old jdk8 clients and new jdk11 clients. Therefore, contrary to my previous mail, I'd also change "jmm_GetVersion()" to return the "old" JMM VERSION (i.e "0x20010203") because that's really the only one we're compatible with. In fact, this makes the whole addition of "JMM_VERSION_2" questionable, because after the proposed changes it wouldn't be used anymore. And after reasoning about it a little more, I think that's correct because we really only have binary compatibility with previous jdk8 clients and that's how it should be. Thank you and best regards, Volker > Passes > > jdk/test/com/sun/management > jdk/test/java/lang/management > jdk/test/sun/management > jdk/test/javax/management > > Paul > > On 8/21/20, 1:39 PM, "serguei.spitsyn at oracle.com" wrote: > > On 8/21/20 11:07, serguei.spitsyn at oracle.com wrote: > > Hi Paul, > > Sorry, Volker, for using this "indirection". > I hope, Paul redirected my "Hi" to you. :) > > Thanks, > Serguei > > > > > Thank you for explanation. > > > > Thanks, > > Serguei > > > > > > On 8/21/20 10:54, Volker Simonis wrote: > >> On Thu, Aug 20, 2020 at 10:06 PM serguei.spitsyn at oracle.com > >> wrote: > >>> Hi Paul, > >>> > >>> I was also wondering if there is a compatibility risk involved with > >>> the JMM_VERSION change. > >>> So, thanks to Volker for asking these questions. > >>> > >>> One more question. > >>> I do not see a backport of the > >>> src/jdk.management/share/native/libmanagement_ext/management_ext.c > >>> change. > >>> Is it intentional, and if so, what is the reason to skip this file? > >>> > >> "libmanagement_ext/management_ext.c" doesn't exist in jdk8. It was > >> introduced with "8042901: Allow com.sun.management to be in a > >> different module to java.lang.management" in jdk9. In jdk8 all the > >> functionality is in "management/management.h" so there's no need to > >> backport the changes from "management_ext.c" . > >> > >> [1] https://bugs.openjdk.java.net/browse/JDK-8042901 > >> > >>> Thanks, > >>> Serguei > >>> > >>> > >>> On 8/20/20 11:30, Volker Simonis wrote: > >>> > >>> On Wed, Aug 19, 2020 at 6:17 PM Hohensee, Paul > >>> wrote: > >>> > >>> Please review this backport to jdk8u. I especially need a CSR > >>> review, since the CSR approval process can be a bottleneck. The > >>> patch significantly reduces fleet profiling overhead, and a version > >>> of it has been in production at Amazon for over 3 years. > >>> > >>> > >>> > >>> Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8185003 > >>> > >>> Original CSR: https://bugs.openjdk.java.net/browse/JDK-8185705 > >>> > >>> Original patch: > >>> http://hg.openjdk.java.net/jdk10/master/rev/68d46cb9be45 > >>> > >>> > >>> > >>> Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8251494 > >>> > >>> Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8251498 > >>> > >>> Backport JDK webrev: > >>> http://cr.openjdk.java.net/~phh/8185003/webrev.8u.jdk.05/ > >>> > >>> JDK part looks good to me. > >>> > >>> Backport Hotspot webrev: > >>> http://cr.openjdk.java.net/~phh/8185003/webrev.8u.hotspot.05/ > >>> > >>> HotSpot part looks good to me but see discussion below. > >>> > >>> > >>> Details of the interface changes needed for the backport are in the > >>> Description of the Backport CSR 8251498. The actual functional > >>> changes are minimal and low risk. > >>> > >>> I've also reviewed the CSR yesterday which I think is fine. But now, > >>> when looking at the implementation, I'm a little concerned about > >>> changing JMM_VERSION from " 0x20010203" to "0x20020000" in "jmm.h". > >>> > >>> This might be especially problematic in combination with the changes > >>> in "Management::get_jmm_interface()" which is called by > >>> JVM_GetManagement(): > >>> > >>> void* Management::get_jmm_interface(int version) { > >>> #if INCLUDE_MANAGEMENT > >>> - if (version == JMM_VERSION_1_0) { > >>> + if (version == JMM_VERSION) { > >>> return (void*) &jmm_interface; > >>> } > >>> #endif // INCLUDE_MANAGEMENT > >>> return NULL; > >>> } > >>> > >>> You've correctly fixed the single caller of "JVM_GetManagement()" in > >>> the JDK (in "JNI_OnLoad()" in "management.c"): > >>> > >>> - jmm_interface = (JmmInterface*) > >>> JVM_GetManagement(JMM_VERSION_1_0); > >>> + jmm_interface = (JmmInterface*) JVM_GetManagement(JMM_VERSION); > >>> > >>> but I wonder if there are other monitoring/serviceability tools out > >>> there which use this interface and which will break after this change. > >>> A quick search revealed at least two StackOverflow entries which > >>> recommend using "JVM_GetManagement(JMM_VERSION_1_0)" [1,2] and there's > >>> a talk and a blog entry doing the same [3, 4]. > >>> > >>> I'm not sure how relevant this is but I think a much safer and > >>> backwards-compatible way of doing this downport would be the > >>> following: > >>> > >>> - don't change "Management::get_jmm_interface()" (i.e. still check for > >>> "JMM_VERSION_1_0") but return the "new" JMM_VERSION in > >>> "jmm_GetVersion()". This won't break anything but will make it > >>> possible for clients to detect the new version if they want. > >>> > >>> - don't change the signature of "DumpThreads()". Instead add a new > >>> version (e.g. "DumpThreadsMaxDepth()/jmm_DumpThreadsMaxDepth()") to > >>> the "JMMInterface" struct and to "jmm_interface" in "management.cpp". > >>> You can do this in one of the two first, reserved fields of > >>> "JMMInterface" so you won't break binary compatibility. > >>> "jmm_DumpThreads()" will then be a simple wrapper which calls > >>> "jmm_DumpThreadsMaxDepth()" with Integer.MAX_VALUE as depth. > >>> > >>> - in the jdk you then simply call "DumpThreadsMaxDepth()" in > >>> "Java_sun_management_ThreadImpl_dumpThreads0()" > >>> > >>> I think this way we can maintain full binary compatibility while still > >>> using the new feature. What do you think? > >>> > >>> Best regards, > >>> Volker > >>> > >>> [1] > >>> https://urldefense.com/v3/__https://stackoverflow.com/questions/23632653/generate-java-heap-dump-on-uncaught-exception__;!!GqivPVa7Brio!LDD5rfKbGz6KCl0LqcAgrFq7kNLkkoDhhN0ZSgHMDvgGMY5bvKJdpoXIAK6N-KqVsyaF$ > >>> [2] > >>> https://urldefense.com/v3/__https://stackoverflow.com/questions/60887816/jvm-options-printnmtstatistics-save-info-to-file__;!!GqivPVa7Brio!LDD5rfKbGz6KCl0LqcAgrFq7kNLkkoDhhN0ZSgHMDvgGMY5bvKJdpoXIAK6N-Ip7MAQ5$ > >>> [3] > >>> https://urldefense.com/v3/__https://sudonull.com/post/25841-JVM-TI-how-to-make-a-plugin-for-a-virtual-machine-Odnoklassniki-company-blog__;!!GqivPVa7Brio!LDD5rfKbGz6KCl0LqcAgrFq7kNLkkoDhhN0ZSgHMDvgGMY5bvKJdpoXIAK6N-ErSjPdD$ > >>> [4] > >>> https://urldefense.com/v3/__https://2019.jpoint.ru/talks/2o8scc5jbaurnqqlsydzxv/__;!!GqivPVa7Brio!LDD5rfKbGz6KCl0LqcAgrFq7kNLkkoDhhN0ZSgHMDvgGMY5bvKJdpoXIAK6N-Oxb5CQ-$ > >>> > >>> Passes the included (suitably modified) test, as well as the tests in > >>> > >>> > >>> > >>> jdk/test/java/lang/management/ThreadMXBean > >>> > >>> jdk/test/com/sun/management/ThreadMXBean > >>> > >>> > >>> > >>> Thanks, > >>> > >>> Paul > >>> > >>> > > > > From mbalao at redhat.com Wed Sep 2 14:49:51 2020 From: mbalao at redhat.com (Martin Balao) Date: Wed, 2 Sep 2020 11:49:51 -0300 Subject: [8u] RFR 8246193: Possible NPE in ENC-PA-REP search in AS-REQ In-Reply-To: References: Message-ID: <07e6d0c7-02c2-330c-23f0-52a744190ba8@redhat.com> Hi, On 7/17/20 10:50 AM, Zhengyu Gu wrote: > > 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8246193-8u/webrev.00/ > 8u Kerberos tests usually use '-Dsun.net.spi.nameservice.provider.1' facility for DNS names resolution. Please have a look at Webrev.01: * http://cr.openjdk.java.net/~mbalao/webrevs/8246193/8246193.webrev.jdk8u.jdk.01/ No regressions observed in 'sun/security/krb5' category: the new 'AlwaysEncPaReq.java' test passes and 'ReplayCacheTestProc.java' fails before 8246193. Thanks, Martin.- From zgu at redhat.com Wed Sep 2 14:55:41 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 2 Sep 2020 10:55:41 -0400 Subject: [8u] RFR 8246193: Possible NPE in ENC-PA-REP search in AS-REQ In-Reply-To: <07e6d0c7-02c2-330c-23f0-52a744190ba8@redhat.com> References: <07e6d0c7-02c2-330c-23f0-52a744190ba8@redhat.com> Message-ID: <088fcd42-0057-f422-b44a-d15804d6f925@redhat.com> Hi Martin, On 9/2/20 10:49 AM, Martin Balao wrote: > Hi, > > On 7/17/20 10:50 AM, Zhengyu Gu wrote: >> >> 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8246193-8u/webrev.00/ >> > > 8u Kerberos tests usually use '-Dsun.net.spi.nameservice.provider.1' > facility for DNS names resolution. Okay, good to know. > > Please have a look at Webrev.01: > > * > http://cr.openjdk.java.net/~mbalao/webrevs/8246193/8246193.webrev.jdk8u.jdk.01/ > > No regressions observed in 'sun/security/krb5' category: the new > 'AlwaysEncPaReq.java' test passes and 'ReplayCacheTestProc.java' fails > before 8246193. Your version looks good to me. Thanks, -Zhengyu > > Thanks, > Martin.- > From zgu at redhat.com Wed Sep 2 15:45:56 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 2 Sep 2020 11:45:56 -0400 Subject: [8u] RFR 8062947: Fix exception message to correctly represent LDAP connection failure Message-ID: I would like to backport this patch to 8u for parity with Oracle 8u271. The original patch applies cleanly on top of JDK-8151678, both are the followups of JDK-8160768. However, included new test uses new language feature 'var' which does not exist in 8u, fixed as follow: diff -r 9c90228fb2d9 -r 96d71ec83814 test/com/sun/jndi/ldap/NamingExceptionMessageTest.java --- a/test/com/sun/jndi/ldap/NamingExceptionMessageTest.java Thu May 07 19:18:22 2020 +0100 +++ b/test/com/sun/jndi/ldap/NamingExceptionMessageTest.java Mon Jul 13 15:46:57 2020 -0400 @@ -51,11 +51,11 @@ @Test public void timeoutMessageTest() throws Exception { - try (var ldapServer = TestLdapServer.newInstance(false)) { + try (TestLdapServer ldapServer = TestLdapServer.newInstance(false)) { ldapServer.start(); ldapServer.awaitStartup(); - var env = ldapServer.getInitialLdapCtxEnvironment(TIMEOUT_VALUE); - var namingException = Assert.expectThrows(NamingException.class, () -> new InitialDirContext(env)); + Hashtable env = ldapServer.getInitialLdapCtxEnvironment(TIMEOUT_VALUE); + Exception namingException = Assert.expectThrows(NamingException.class, () -> new InitialDirContext(env)); System.out.println("Got naming exception:" + namingException); Assert.assertEquals(namingException.getMessage(), EXPECTED_TIMEOUT_MESSAGE); } @@ -63,11 +63,11 @@ @Test public void connectionClosureMessageTest() throws Exception { - try (var ldapServer = TestLdapServer.newInstance(true)) { + try (TestLdapServer ldapServer = TestLdapServer.newInstance(true)) { ldapServer.start(); ldapServer.awaitStartup(); - var env = ldapServer.getInitialLdapCtxEnvironment(0); - var namingException = Assert.expectThrows(NamingException.class, () -> new InitialDirContext(env)); + Hashtable env = ldapServer.getInitialLdapCtxEnvironment(0); + Exception namingException = Assert.expectThrows(NamingException.class, () -> new InitialDirContext(env)); System.out.println("Got naming exception:" + namingException); Assert.assertEquals(namingException.getMessage(), EXPECTED_CLOSURE_MESSAGE); } The original bug: https://bugs.openjdk.java.net/browse/JDK-8062947 The original patch: https://hg.openjdk.java.net/jdk/jdk/rev/868fe697bad4 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8062947-8u/webrev.00/ Test: Included NamingExceptionMessageTest.java test on Linux x86_64 Thanks, -Zhengyu From hohensee at amazon.com Wed Sep 2 15:55:33 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 2 Sep 2020 15:55:33 +0000 Subject: [8u] RFR 8062947: Fix exception message to correctly represent LDAP connection failure Message-ID: <26B2235C-5F92-41A1-A133-B854F1BD0E09@amazon.com> Lgtm. Thanks, Paul ?On 9/2/20, 8:49 AM, "jdk8u-dev on behalf of Zhengyu Gu" wrote: I would like to backport this patch to 8u for parity with Oracle 8u271. The original patch applies cleanly on top of JDK-8151678, both are the followups of JDK-8160768. However, included new test uses new language feature 'var' which does not exist in 8u, fixed as follow: diff -r 9c90228fb2d9 -r 96d71ec83814 test/com/sun/jndi/ldap/NamingExceptionMessageTest.java --- a/test/com/sun/jndi/ldap/NamingExceptionMessageTest.java Thu May 07 19:18:22 2020 +0100 +++ b/test/com/sun/jndi/ldap/NamingExceptionMessageTest.java Mon Jul 13 15:46:57 2020 -0400 @@ -51,11 +51,11 @@ @Test public void timeoutMessageTest() throws Exception { - try (var ldapServer = TestLdapServer.newInstance(false)) { + try (TestLdapServer ldapServer = TestLdapServer.newInstance(false)) { ldapServer.start(); ldapServer.awaitStartup(); - var env = ldapServer.getInitialLdapCtxEnvironment(TIMEOUT_VALUE); - var namingException = Assert.expectThrows(NamingException.class, () -> new InitialDirContext(env)); + Hashtable env = ldapServer.getInitialLdapCtxEnvironment(TIMEOUT_VALUE); + Exception namingException = Assert.expectThrows(NamingException.class, () -> new InitialDirContext(env)); System.out.println("Got naming exception:" + namingException); Assert.assertEquals(namingException.getMessage(), EXPECTED_TIMEOUT_MESSAGE); } @@ -63,11 +63,11 @@ @Test public void connectionClosureMessageTest() throws Exception { - try (var ldapServer = TestLdapServer.newInstance(true)) { + try (TestLdapServer ldapServer = TestLdapServer.newInstance(true)) { ldapServer.start(); ldapServer.awaitStartup(); - var env = ldapServer.getInitialLdapCtxEnvironment(0); - var namingException = Assert.expectThrows(NamingException.class, () -> new InitialDirContext(env)); + Hashtable env = ldapServer.getInitialLdapCtxEnvironment(0); + Exception namingException = Assert.expectThrows(NamingException.class, () -> new InitialDirContext(env)); System.out.println("Got naming exception:" + namingException); Assert.assertEquals(namingException.getMessage(), EXPECTED_CLOSURE_MESSAGE); } The original bug: https://bugs.openjdk.java.net/browse/JDK-8062947 The original patch: https://hg.openjdk.java.net/jdk/jdk/rev/868fe697bad4 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8062947-8u/webrev.00/ Test: Included NamingExceptionMessageTest.java test on Linux x86_64 Thanks, -Zhengyu From zgu at redhat.com Wed Sep 2 15:57:59 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 2 Sep 2020 11:57:59 -0400 Subject: [8u] RFR 8062947: Fix exception message to correctly represent LDAP connection failure In-Reply-To: <26B2235C-5F92-41A1-A133-B854F1BD0E09@amazon.com> References: <26B2235C-5F92-41A1-A133-B854F1BD0E09@amazon.com> Message-ID: <20e5a7f6-32f1-377c-1728-71a4b9405b44@redhat.com> Thanks, Paul -Zhengyu On 9/2/20 11:55 AM, Hohensee, Paul wrote: > Lgtm. > > Thanks, > Paul > > ?On 9/2/20, 8:49 AM, "jdk8u-dev on behalf of Zhengyu Gu" wrote: > > I would like to backport this patch to 8u for parity with Oracle 8u271. > > The original patch applies cleanly on top of JDK-8151678, both are the > followups of JDK-8160768. > > However, included new test uses new language feature 'var' which does > not exist in 8u, fixed as follow: > > diff -r 9c90228fb2d9 -r 96d71ec83814 > test/com/sun/jndi/ldap/NamingExceptionMessageTest.java > --- a/test/com/sun/jndi/ldap/NamingExceptionMessageTest.java Thu May 07 > 19:18:22 2020 +0100 > +++ b/test/com/sun/jndi/ldap/NamingExceptionMessageTest.java Mon Jul 13 > 15:46:57 2020 -0400 > @@ -51,11 +51,11 @@ > > @Test > public void timeoutMessageTest() throws Exception { > - try (var ldapServer = TestLdapServer.newInstance(false)) { > + try (TestLdapServer ldapServer = > TestLdapServer.newInstance(false)) { > ldapServer.start(); > ldapServer.awaitStartup(); > - var env = > ldapServer.getInitialLdapCtxEnvironment(TIMEOUT_VALUE); > - var namingException = > Assert.expectThrows(NamingException.class, () -> new > InitialDirContext(env)); > + Hashtable env = > ldapServer.getInitialLdapCtxEnvironment(TIMEOUT_VALUE); > + Exception namingException = > Assert.expectThrows(NamingException.class, () -> new > InitialDirContext(env)); > System.out.println("Got naming exception:" + namingException); > Assert.assertEquals(namingException.getMessage(), > EXPECTED_TIMEOUT_MESSAGE); > } > @@ -63,11 +63,11 @@ > > @Test > public void connectionClosureMessageTest() throws Exception { > - try (var ldapServer = TestLdapServer.newInstance(true)) { > + try (TestLdapServer ldapServer = > TestLdapServer.newInstance(true)) { > ldapServer.start(); > ldapServer.awaitStartup(); > - var env = ldapServer.getInitialLdapCtxEnvironment(0); > - var namingException = > Assert.expectThrows(NamingException.class, () -> new > InitialDirContext(env)); > + Hashtable env = > ldapServer.getInitialLdapCtxEnvironment(0); > + Exception namingException = > Assert.expectThrows(NamingException.class, () -> new > InitialDirContext(env)); > System.out.println("Got naming exception:" + namingException); > Assert.assertEquals(namingException.getMessage(), > EXPECTED_CLOSURE_MESSAGE); > } > > > The original bug: https://bugs.openjdk.java.net/browse/JDK-8062947 > The original patch: https://hg.openjdk.java.net/jdk/jdk/rev/868fe697bad4 > > > 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8062947-8u/webrev.00/ > > Test: > Included NamingExceptionMessageTest.java test on Linux x86_64 > > Thanks, > > -Zhengyu > > From gnu.andrew at redhat.com Wed Sep 2 16:20:01 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 2 Sep 2020 17:20:01 +0100 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider In-Reply-To: References: <4F5DB0BC-13AB-47C1-A6E3-6684BF66AA28@amazon.com> <10e87c8b-5f56-a973-c401-675dfd1a898c@redhat.com> <89966718-074e-0c91-5990-78f08c6cca34@gmx.net> <7c272c9c92233ec50ebd8e48a67d82a621e153ae.camel@redhat.com> <20200817052648.GA2640315@stopbrexit> <78a1c49794afdf13013a4c3d75efab50f4745870.camel@redhat.com> <20200820171607.GC3112706@stopbrexit> Message-ID: <20200902162001.GA1407872@stopbrexit> On 13:41 Fri 28 Aug , Langer, Christoph wrote: > Hi, > > as for these @since 12 tags... > > While I understand that there are both, arguments pro and con, I'd like to point out one specific thing in the context of this backport: > Classes com.sun.jndi.ldap.spi. LdapDnsProvider and com.sun.jndi.ldap.spi. LdapDnsProviderResult don't even exist in 12 and probably won't ever. In 12 we have javax.naming.ldap.spi.LdapDnsProvider and javax.naming.ldap.spi.LdapDnsProviderResult. So, given that change of package location, I opt to remove the @since 12 tags which I'm proposing in my webrev for 11u as well. > > Andrew, does that convice you or you still insist on the tags? > > Cheers > Christoph > Well, I wasn't aware that I was insisting on this; I don't think it's a huge issue either way. I don't see a case for a general policy of removing these, because I don't see a huge benefit to it. What is the case for removing them, compared with the churn of creating further divergence and potentially turning a clean backport into one that needs to be reviewed because "I went and took out a dozen @since tags"? I'm aware that in this case, the packages are different (and have to be for TCK compliance). To me, the @since is an indicator of why they are different (this is API in 12, we had to shift it elsewhere in 8u). Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From akashche at redhat.com Thu Sep 3 16:32:07 2020 From: akashche at redhat.com (Alex Kashchenko) Date: Thu, 3 Sep 2020 17:32:07 +0100 Subject: [8u] RFR: 8202076: test/jdk/java/io/File/WinSpecialFiles.java on windows with VS2017 Message-ID: Hi, Please review the backport of JDK-8202076 to 8u: Bug: https://bugs.openjdk.java.net/browse/JDK-8202076 Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/7b259287cdd2 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8202076/webrev.00/ Patch has required minor changes: paths, copyright year, "fslash" var declaration moved to the beginning of the block for C89 compat. Testing: jtreg:java/io/File/, jck:api/java_io/File/ . -- -Alex From akashche at redhat.com Thu Sep 3 16:32:23 2020 From: akashche at redhat.com (Alex Kashchenko) Date: Thu, 3 Sep 2020 17:32:23 +0100 Subject: [8u] RFR: 8051853: new URI("x/").resolve("..").getSchemeSpecificPart() returns null! Message-ID: Hi, Please review the fix to 8051853 for 8u. Note, the problem is not reproducible in 9+, it was fixed there as a part of "8146686: Create the schemeSpecificPart for non-opaque URIs lazily" . Bug: https://bugs.openjdk.java.net/browse/JDK-8051853 Related maillist discussion: https://mail.openjdk.java.net/pipermail/net-dev/2016-January/009467.html Related point in 8146686: https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/16296b4145d0#l1.30 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8051853/webrev.00/ If appendSchemeSpecificPart() doesn't append anything to the specified buffer, then defineSchemeSpecificPart() returns early and schemeSpecificPart variable remains null. Proposed change removes "early return" branch. -- -Alex From akashche at redhat.com Thu Sep 3 16:32:37 2020 From: akashche at redhat.com (Alex Kashchenko) Date: Thu, 3 Sep 2020 17:32:37 +0100 Subject: [8u] RFR 8u: Windows build failed after 8222079 backport In-Reply-To: <247e2cb5-bd7a-790e-60ce-242151ff9706@redhat.com> References: <247e2cb5-bd7a-790e-60ce-242151ff9706@redhat.com> Message-ID: Hi Zhengyu, On 8/31/20, Zhengyu Gu wrote: > Please review this small fix for Windows build after JDK-8222079 backport. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8252573 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8252573/webrev.00/ > > Test: > 64-bit and 32-bit builds on Windows The change looks good to me (not a reviewer), I've checked that it fixes the problem with vs2010 compilation. -- -Alex From zgu at redhat.com Thu Sep 3 16:47:19 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 3 Sep 2020 12:47:19 -0400 Subject: [8u] RFR 8u: Windows build failed after 8222079 backport In-Reply-To: References: <247e2cb5-bd7a-790e-60ce-242151ff9706@redhat.com> Message-ID: Thanks, Alex. -Zhengyu On 9/3/20 12:32 PM, Alex Kashchenko wrote: > Hi Zhengyu, > > On 8/31/20, Zhengyu Gu wrote: >> Please review this small fix for Windows build after JDK-8222079 backport. >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8252573 >> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8252573/webrev.00/ >> >> Test: >> 64-bit and 32-bit builds on Windows > > The change looks good to me (not a reviewer), I've checked that it > fixes the problem with vs2010 compilation. > > -- > -Alex > From volker.simonis at gmail.com Thu Sep 3 16:57:11 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 3 Sep 2020 18:57:11 +0200 Subject: RFR/RFA (M): 8185003: JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument In-Reply-To: <9645ACAC-4A08-4154-B1E1-BF1D9E7CBFA0@amazon.com> References: <9645ACAC-4A08-4154-B1E1-BF1D9E7CBFA0@amazon.com> Message-ID: On Tue, Sep 1, 2020 at 9:44 PM Hohensee, Paul wrote: > > Hi, > > I've re-finalized the CSR after Volker's re-review. See https://bugs.openjdk.java.net/browse/JDK-8251498. It now says we won't update JMM_VERSION. I've also updated the webrevs to reflect the CSR changes and to target 8u282. > > jdk: http://cr.openjdk.java.net/~phh/8185003/webrev.8u.jdk.07/ > hotspot: http://cr.openjdk.java.net/~phh/8185003/webrev.8u.hotspot.07/ > Hi Paul, this looks all good now (thanks for going the extra mile :) I have just one small suggestion: when calling "jmm_DumpThreadsMaxDepth(...)" from "jmm_DumpThreads(...)" in "management.cpp" you can use "-1" instead of "INT_MAX" to get the exact behaviour as before without having to rely on INT_MAX being defined correctly. But I leave the decision up to you and even if you update it, there's no need for a new webrev from my side. Thumbs up and best regards, Volker > Thanks, > Paul > > ?On 8/26/20, 12:22 PM, "jdk8u-dev on behalf of Hohensee, Paul" wrote: > > +Joe for an opinion. > > I agree. I've added a comment to the CSR (https://bugs.openjdk.java.net/browse/JDK-8251498) and moved it back to Draft. > > "Volker Simonis has pointed out in https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-August/012557.html that when we backport a JMM feature, we're actually updating the existing JMM version specification rather than transitioning to a new one. There was a bit of recognition of this in https://bugs.openjdk.java.net/browse/JDK-8249101, where the @since javadoc tag was updated to 11.0.9 rather than 14. Imo, Volker makes a good argument for leaving the JMM version alone when doing JMM backports. If we adopt this approach, the JDK 11 JMM version should also be reverted." > > Thanks, > Paul > > On 8/26/20, 10:18 AM, "Volker Simonis" wrote: > > Hi Paul, > > thanks for adapting your change. Please find my comments in-line below: > > On Tue, Aug 25, 2020 at 10:28 PM Hohensee, Paul wrote: > > > > :) > > > > New webrevs following Volker's suggestion. > > > > http://cr.openjdk.java.net/~phh/8185003/webrev.8u.jdk.06/ > > Looks good except JNI_OnLoad() in "management.c" where I'd change the > call to "JVM_GetManagement(JMM_VERSION)" back to > "JVM_GetManagement(JMM_VERSION_1_0)". See discussion below... > > > http://cr.openjdk.java.net/~phh/8185003/webrev.8u.hotspot.06/ > > > > Looks good except Management::get_jmm_interface(): > > 2396 if (version == JMM_VERSION) { > 2397 return (void*) &jmm_interface; > 2398 } > > You still check for "JMM_VERSION" which is now "0x20020000" and thus > incompatible with the old value of "JMM_VERSION_1 = 0x20010000". This > will break compatibility with clients compiled against jmm.h before > this change. It should therefore remain unchanged: > > if (version == JMM_VERSION_1_0) { > return (void*) &jmm_interface; > } > > I think the variant "if (version == JMM_VERSION_1_0 || version == > JMM_VERSION)" which we've briefly discussed wouldn't work either > because a binary "JMM_VERSION_2" client would expect that > "DumpThreads" will have the additional "maxDepths" argument and crash. > > So we can't have binary compatibility with both, old jdk8 clients and > new jdk11 clients. Therefore, contrary to my previous mail, I'd also > change "jmm_GetVersion()" to return the "old" JMM VERSION (i.e > "0x20010203") because that's really the only one we're compatible > with. > > In fact, this makes the whole addition of "JMM_VERSION_2" > questionable, because after the proposed changes it wouldn't be used > anymore. And after reasoning about it a little more, I think that's > correct because we really only have binary compatibility with previous > jdk8 clients and that's how it should be. > > Thank you and best regards, > Volker > > > > Passes > > > > jdk/test/com/sun/management > > jdk/test/java/lang/management > > jdk/test/sun/management > > jdk/test/javax/management > > > > Paul > > > > On 8/21/20, 1:39 PM, "serguei.spitsyn at oracle.com" wrote: > > > > On 8/21/20 11:07, serguei.spitsyn at oracle.com wrote: > > > Hi Paul, > > > > Sorry, Volker, for using this "indirection". > > I hope, Paul redirected my "Hi" to you. :) > > > > Thanks, > > Serguei > > > > > > > > Thank you for explanation. > > > > > > Thanks, > > > Serguei > > > > > > > > > On 8/21/20 10:54, Volker Simonis wrote: > > >> On Thu, Aug 20, 2020 at 10:06 PM serguei.spitsyn at oracle.com > > >> wrote: > > >>> Hi Paul, > > >>> > > >>> I was also wondering if there is a compatibility risk involved with > > >>> the JMM_VERSION change. > > >>> So, thanks to Volker for asking these questions. > > >>> > > >>> One more question. > > >>> I do not see a backport of the > > >>> src/jdk.management/share/native/libmanagement_ext/management_ext.c > > >>> change. > > >>> Is it intentional, and if so, what is the reason to skip this file? > > >>> > > >> "libmanagement_ext/management_ext.c" doesn't exist in jdk8. It was > > >> introduced with "8042901: Allow com.sun.management to be in a > > >> different module to java.lang.management" in jdk9. In jdk8 all the > > >> functionality is in "management/management.h" so there's no need to > > >> backport the changes from "management_ext.c" . > > >> > > >> [1] https://bugs.openjdk.java.net/browse/JDK-8042901 > > >> > > >>> Thanks, > > >>> Serguei > > >>> > > >>> > > >>> On 8/20/20 11:30, Volker Simonis wrote: > > >>> > > >>> On Wed, Aug 19, 2020 at 6:17 PM Hohensee, Paul > > >>> wrote: > > >>> > > >>> Please review this backport to jdk8u. I especially need a CSR > > >>> review, since the CSR approval process can be a bottleneck. The > > >>> patch significantly reduces fleet profiling overhead, and a version > > >>> of it has been in production at Amazon for over 3 years. > > >>> > > >>> > > >>> > > >>> Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8185003 > > >>> > > >>> Original CSR: https://bugs.openjdk.java.net/browse/JDK-8185705 > > >>> > > >>> Original patch: > > >>> http://hg.openjdk.java.net/jdk10/master/rev/68d46cb9be45 > > >>> > > >>> > > >>> > > >>> Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8251494 > > >>> > > >>> Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8251498 > > >>> > > >>> Backport JDK webrev: > > >>> http://cr.openjdk.java.net/~phh/8185003/webrev.8u.jdk.05/ > > >>> > > >>> JDK part looks good to me. > > >>> > > >>> Backport Hotspot webrev: > > >>> http://cr.openjdk.java.net/~phh/8185003/webrev.8u.hotspot.05/ > > >>> > > >>> HotSpot part looks good to me but see discussion below. > > >>> > > >>> > > >>> Details of the interface changes needed for the backport are in the > > >>> Description of the Backport CSR 8251498. The actual functional > > >>> changes are minimal and low risk. > > >>> > > >>> I've also reviewed the CSR yesterday which I think is fine. But now, > > >>> when looking at the implementation, I'm a little concerned about > > >>> changing JMM_VERSION from " 0x20010203" to "0x20020000" in "jmm.h". > > >>> > > >>> This might be especially problematic in combination with the changes > > >>> in "Management::get_jmm_interface()" which is called by > > >>> JVM_GetManagement(): > > >>> > > >>> void* Management::get_jmm_interface(int version) { > > >>> #if INCLUDE_MANAGEMENT > > >>> - if (version == JMM_VERSION_1_0) { > > >>> + if (version == JMM_VERSION) { > > >>> return (void*) &jmm_interface; > > >>> } > > >>> #endif // INCLUDE_MANAGEMENT > > >>> return NULL; > > >>> } > > >>> > > >>> You've correctly fixed the single caller of "JVM_GetManagement()" in > > >>> the JDK (in "JNI_OnLoad()" in "management.c"): > > >>> > > >>> - jmm_interface = (JmmInterface*) > > >>> JVM_GetManagement(JMM_VERSION_1_0); > > >>> + jmm_interface = (JmmInterface*) JVM_GetManagement(JMM_VERSION); > > >>> > > >>> but I wonder if there are other monitoring/serviceability tools out > > >>> there which use this interface and which will break after this change. > > >>> A quick search revealed at least two StackOverflow entries which > > >>> recommend using "JVM_GetManagement(JMM_VERSION_1_0)" [1,2] and there's > > >>> a talk and a blog entry doing the same [3, 4]. > > >>> > > >>> I'm not sure how relevant this is but I think a much safer and > > >>> backwards-compatible way of doing this downport would be the > > >>> following: > > >>> > > >>> - don't change "Management::get_jmm_interface()" (i.e. still check for > > >>> "JMM_VERSION_1_0") but return the "new" JMM_VERSION in > > >>> "jmm_GetVersion()". This won't break anything but will make it > > >>> possible for clients to detect the new version if they want. > > >>> > > >>> - don't change the signature of "DumpThreads()". Instead add a new > > >>> version (e.g. "DumpThreadsMaxDepth()/jmm_DumpThreadsMaxDepth()") to > > >>> the "JMMInterface" struct and to "jmm_interface" in "management.cpp". > > >>> You can do this in one of the two first, reserved fields of > > >>> "JMMInterface" so you won't break binary compatibility. > > >>> "jmm_DumpThreads()" will then be a simple wrapper which calls > > >>> "jmm_DumpThreadsMaxDepth()" with Integer.MAX_VALUE as depth. > > >>> > > >>> - in the jdk you then simply call "DumpThreadsMaxDepth()" in > > >>> "Java_sun_management_ThreadImpl_dumpThreads0()" > > >>> > > >>> I think this way we can maintain full binary compatibility while still > > >>> using the new feature. What do you think? > > >>> > > >>> Best regards, > > >>> Volker > > >>> > > >>> [1] > > >>> https://urldefense.com/v3/__https://stackoverflow.com/questions/23632653/generate-java-heap-dump-on-uncaught-exception__;!!GqivPVa7Brio!LDD5rfKbGz6KCl0LqcAgrFq7kNLkkoDhhN0ZSgHMDvgGMY5bvKJdpoXIAK6N-KqVsyaF$ > > >>> [2] > > >>> https://urldefense.com/v3/__https://stackoverflow.com/questions/60887816/jvm-options-printnmtstatistics-save-info-to-file__;!!GqivPVa7Brio!LDD5rfKbGz6KCl0LqcAgrFq7kNLkkoDhhN0ZSgHMDvgGMY5bvKJdpoXIAK6N-Ip7MAQ5$ > > >>> [3] > > >>> https://urldefense.com/v3/__https://sudonull.com/post/25841-JVM-TI-how-to-make-a-plugin-for-a-virtual-machine-Odnoklassniki-company-blog__;!!GqivPVa7Brio!LDD5rfKbGz6KCl0LqcAgrFq7kNLkkoDhhN0ZSgHMDvgGMY5bvKJdpoXIAK6N-ErSjPdD$ > > >>> [4] > > >>> https://urldefense.com/v3/__https://2019.jpoint.ru/talks/2o8scc5jbaurnqqlsydzxv/__;!!GqivPVa7Brio!LDD5rfKbGz6KCl0LqcAgrFq7kNLkkoDhhN0ZSgHMDvgGMY5bvKJdpoXIAK6N-Oxb5CQ-$ > > >>> > > >>> Passes the included (suitably modified) test, as well as the tests in > > >>> > > >>> > > >>> > > >>> jdk/test/java/lang/management/ThreadMXBean > > >>> > > >>> jdk/test/com/sun/management/ThreadMXBean > > >>> > > >>> > > >>> > > >>> Thanks, > > >>> > > >>> Paul > > >>> > > >>> > > > > > > > > > From zgu at redhat.com Thu Sep 3 17:03:56 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 3 Sep 2020 13:03:56 -0400 Subject: [8u] RFR: 8202076: test/jdk/java/io/File/WinSpecialFiles.java on windows with VS2017 In-Reply-To: References: Message-ID: Looks good to me. -Zhengyu On 9/3/20 12:32 PM, Alex Kashchenko wrote: > Hi, > > Please review the backport of JDK-8202076 to 8u: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8202076 > > Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/7b259287cdd2 > > 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8202076/webrev.00/ > > Patch has required minor changes: paths, copyright year, "fslash" var > declaration moved to the beginning of the block for C89 compat. > Testing: jtreg:java/io/File/, jck:api/java_io/File/ . > > -- > -Alex > From hohensee at amazon.com Thu Sep 3 18:20:24 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 3 Sep 2020 18:20:24 +0000 Subject: RFR/RFA (M): 8185003: JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument Message-ID: <4D5AB54F-DF84-4DAE-8931-1A5FF28EF0EF@amazon.com> Thanks for the re-review and approval, Volker. Now we just have to wait for the CSR to be approved. I'm going to leave INT_MAX because that's the argument the original patch passes to jmm_DumpThreads via the dumpThreads0 native method in ThreadImpl.java. Serguei, do you want to re-review? ?On 9/3/20, 9:58 AM, "Volker Simonis" wrote: On Tue, Sep 1, 2020 at 9:44 PM Hohensee, Paul wrote: > > Hi, > > I've re-finalized the CSR after Volker's re-review. See https://bugs.openjdk.java.net/browse/JDK-8251498. It now says we won't update JMM_VERSION. I've also updated the webrevs to reflect the CSR changes and to target 8u282. > > jdk: http://cr.openjdk.java.net/~phh/8185003/webrev.8u.jdk.07/ > hotspot: http://cr.openjdk.java.net/~phh/8185003/webrev.8u.hotspot.07/ > Hi Paul, this looks all good now (thanks for going the extra mile :) I have just one small suggestion: when calling "jmm_DumpThreadsMaxDepth(...)" from "jmm_DumpThreads(...)" in "management.cpp" you can use "-1" instead of "INT_MAX" to get the exact behaviour as before without having to rely on INT_MAX being defined correctly. But I leave the decision up to you and even if you update it, there's no need for a new webrev from my side. Thumbs up and best regards, Volker > Thanks, > Paul > > On 8/26/20, 12:22 PM, "jdk8u-dev on behalf of Hohensee, Paul" wrote: > > +Joe for an opinion. > > I agree. I've added a comment to the CSR (https://bugs.openjdk.java.net/browse/JDK-8251498) and moved it back to Draft. > > "Volker Simonis has pointed out in https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-August/012557.html that when we backport a JMM feature, we're actually updating the existing JMM version specification rather than transitioning to a new one. There was a bit of recognition of this in https://bugs.openjdk.java.net/browse/JDK-8249101, where the @since javadoc tag was updated to 11.0.9 rather than 14. Imo, Volker makes a good argument for leaving the JMM version alone when doing JMM backports. If we adopt this approach, the JDK 11 JMM version should also be reverted." > > Thanks, > Paul > > On 8/26/20, 10:18 AM, "Volker Simonis" wrote: > > Hi Paul, > > thanks for adapting your change. Please find my comments in-line below: > > On Tue, Aug 25, 2020 at 10:28 PM Hohensee, Paul wrote: > > > > :) > > > > New webrevs following Volker's suggestion. > > > > http://cr.openjdk.java.net/~phh/8185003/webrev.8u.jdk.06/ > > Looks good except JNI_OnLoad() in "management.c" where I'd change the > call to "JVM_GetManagement(JMM_VERSION)" back to > "JVM_GetManagement(JMM_VERSION_1_0)". See discussion below... > > > http://cr.openjdk.java.net/~phh/8185003/webrev.8u.hotspot.06/ > > > > Looks good except Management::get_jmm_interface(): > > 2396 if (version == JMM_VERSION) { > 2397 return (void*) &jmm_interface; > 2398 } > > You still check for "JMM_VERSION" which is now "0x20020000" and thus > incompatible with the old value of "JMM_VERSION_1 = 0x20010000". This > will break compatibility with clients compiled against jmm.h before > this change. It should therefore remain unchanged: > > if (version == JMM_VERSION_1_0) { > return (void*) &jmm_interface; > } > > I think the variant "if (version == JMM_VERSION_1_0 || version == > JMM_VERSION)" which we've briefly discussed wouldn't work either > because a binary "JMM_VERSION_2" client would expect that > "DumpThreads" will have the additional "maxDepths" argument and crash. > > So we can't have binary compatibility with both, old jdk8 clients and > new jdk11 clients. Therefore, contrary to my previous mail, I'd also > change "jmm_GetVersion()" to return the "old" JMM VERSION (i.e > "0x20010203") because that's really the only one we're compatible > with. > > In fact, this makes the whole addition of "JMM_VERSION_2" > questionable, because after the proposed changes it wouldn't be used > anymore. And after reasoning about it a little more, I think that's > correct because we really only have binary compatibility with previous > jdk8 clients and that's how it should be. > > Thank you and best regards, > Volker > > > > Passes > > > > jdk/test/com/sun/management > > jdk/test/java/lang/management > > jdk/test/sun/management > > jdk/test/javax/management > > > > Paul > > > > On 8/21/20, 1:39 PM, "serguei.spitsyn at oracle.com" wrote: > > > > On 8/21/20 11:07, serguei.spitsyn at oracle.com wrote: > > > Hi Paul, > > > > Sorry, Volker, for using this "indirection". > > I hope, Paul redirected my "Hi" to you. :) > > > > Thanks, > > Serguei > > > > > > > > Thank you for explanation. > > > > > > Thanks, > > > Serguei > > > > > > > > > On 8/21/20 10:54, Volker Simonis wrote: > > >> On Thu, Aug 20, 2020 at 10:06 PM serguei.spitsyn at oracle.com > > >> wrote: > > >>> Hi Paul, > > >>> > > >>> I was also wondering if there is a compatibility risk involved with > > >>> the JMM_VERSION change. > > >>> So, thanks to Volker for asking these questions. > > >>> > > >>> One more question. > > >>> I do not see a backport of the > > >>> src/jdk.management/share/native/libmanagement_ext/management_ext.c > > >>> change. > > >>> Is it intentional, and if so, what is the reason to skip this file? > > >>> > > >> "libmanagement_ext/management_ext.c" doesn't exist in jdk8. It was > > >> introduced with "8042901: Allow com.sun.management to be in a > > >> different module to java.lang.management" in jdk9. In jdk8 all the > > >> functionality is in "management/management.h" so there's no need to > > >> backport the changes from "management_ext.c" . > > >> > > >> [1] https://bugs.openjdk.java.net/browse/JDK-8042901 > > >> > > >>> Thanks, > > >>> Serguei > > >>> > > >>> > > >>> On 8/20/20 11:30, Volker Simonis wrote: > > >>> > > >>> On Wed, Aug 19, 2020 at 6:17 PM Hohensee, Paul > > >>> wrote: > > >>> > > >>> Please review this backport to jdk8u. I especially need a CSR > > >>> review, since the CSR approval process can be a bottleneck. The > > >>> patch significantly reduces fleet profiling overhead, and a version > > >>> of it has been in production at Amazon for over 3 years. > > >>> > > >>> > > >>> > > >>> Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8185003 > > >>> > > >>> Original CSR: https://bugs.openjdk.java.net/browse/JDK-8185705 > > >>> > > >>> Original patch: > > >>> http://hg.openjdk.java.net/jdk10/master/rev/68d46cb9be45 > > >>> > > >>> > > >>> > > >>> Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8251494 > > >>> > > >>> Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8251498 > > >>> > > >>> Backport JDK webrev: > > >>> http://cr.openjdk.java.net/~phh/8185003/webrev.8u.jdk.05/ > > >>> > > >>> JDK part looks good to me. > > >>> > > >>> Backport Hotspot webrev: > > >>> http://cr.openjdk.java.net/~phh/8185003/webrev.8u.hotspot.05/ > > >>> > > >>> HotSpot part looks good to me but see discussion below. > > >>> > > >>> > > >>> Details of the interface changes needed for the backport are in the > > >>> Description of the Backport CSR 8251498. The actual functional > > >>> changes are minimal and low risk. > > >>> > > >>> I've also reviewed the CSR yesterday which I think is fine. But now, > > >>> when looking at the implementation, I'm a little concerned about > > >>> changing JMM_VERSION from " 0x20010203" to "0x20020000" in "jmm.h". > > >>> > > >>> This might be especially problematic in combination with the changes > > >>> in "Management::get_jmm_interface()" which is called by > > >>> JVM_GetManagement(): > > >>> > > >>> void* Management::get_jmm_interface(int version) { > > >>> #if INCLUDE_MANAGEMENT > > >>> - if (version == JMM_VERSION_1_0) { > > >>> + if (version == JMM_VERSION) { > > >>> return (void*) &jmm_interface; > > >>> } > > >>> #endif // INCLUDE_MANAGEMENT > > >>> return NULL; > > >>> } > > >>> > > >>> You've correctly fixed the single caller of "JVM_GetManagement()" in > > >>> the JDK (in "JNI_OnLoad()" in "management.c"): > > >>> > > >>> - jmm_interface = (JmmInterface*) > > >>> JVM_GetManagement(JMM_VERSION_1_0); > > >>> + jmm_interface = (JmmInterface*) JVM_GetManagement(JMM_VERSION); > > >>> > > >>> but I wonder if there are other monitoring/serviceability tools out > > >>> there which use this interface and which will break after this change. > > >>> A quick search revealed at least two StackOverflow entries which > > >>> recommend using "JVM_GetManagement(JMM_VERSION_1_0)" [1,2] and there's > > >>> a talk and a blog entry doing the same [3, 4]. > > >>> > > >>> I'm not sure how relevant this is but I think a much safer and > > >>> backwards-compatible way of doing this downport would be the > > >>> following: > > >>> > > >>> - don't change "Management::get_jmm_interface()" (i.e. still check for > > >>> "JMM_VERSION_1_0") but return the "new" JMM_VERSION in > > >>> "jmm_GetVersion()". This won't break anything but will make it > > >>> possible for clients to detect the new version if they want. > > >>> > > >>> - don't change the signature of "DumpThreads()". Instead add a new > > >>> version (e.g. "DumpThreadsMaxDepth()/jmm_DumpThreadsMaxDepth()") to > > >>> the "JMMInterface" struct and to "jmm_interface" in "management.cpp". > > >>> You can do this in one of the two first, reserved fields of > > >>> "JMMInterface" so you won't break binary compatibility. > > >>> "jmm_DumpThreads()" will then be a simple wrapper which calls > > >>> "jmm_DumpThreadsMaxDepth()" with Integer.MAX_VALUE as depth. > > >>> > > >>> - in the jdk you then simply call "DumpThreadsMaxDepth()" in > > >>> "Java_sun_management_ThreadImpl_dumpThreads0()" > > >>> > > >>> I think this way we can maintain full binary compatibility while still > > >>> using the new feature. What do you think? > > >>> > > >>> Best regards, > > >>> Volker > > >>> > > >>> [1] > > >>> https://urldefense.com/v3/__https://stackoverflow.com/questions/23632653/generate-java-heap-dump-on-uncaught-exception__;!!GqivPVa7Brio!LDD5rfKbGz6KCl0LqcAgrFq7kNLkkoDhhN0ZSgHMDvgGMY5bvKJdpoXIAK6N-KqVsyaF$ > > >>> [2] > > >>> https://urldefense.com/v3/__https://stackoverflow.com/questions/60887816/jvm-options-printnmtstatistics-save-info-to-file__;!!GqivPVa7Brio!LDD5rfKbGz6KCl0LqcAgrFq7kNLkkoDhhN0ZSgHMDvgGMY5bvKJdpoXIAK6N-Ip7MAQ5$ > > >>> [3] > > >>> https://urldefense.com/v3/__https://sudonull.com/post/25841-JVM-TI-how-to-make-a-plugin-for-a-virtual-machine-Odnoklassniki-company-blog__;!!GqivPVa7Brio!LDD5rfKbGz6KCl0LqcAgrFq7kNLkkoDhhN0ZSgHMDvgGMY5bvKJdpoXIAK6N-ErSjPdD$ > > >>> [4] > > >>> https://urldefense.com/v3/__https://2019.jpoint.ru/talks/2o8scc5jbaurnqqlsydzxv/__;!!GqivPVa7Brio!LDD5rfKbGz6KCl0LqcAgrFq7kNLkkoDhhN0ZSgHMDvgGMY5bvKJdpoXIAK6N-Oxb5CQ-$ > > >>> > > >>> Passes the included (suitably modified) test, as well as the tests in > > >>> > > >>> > > >>> > > >>> jdk/test/java/lang/management/ThreadMXBean > > >>> > > >>> jdk/test/com/sun/management/ThreadMXBean > > >>> > > >>> > > >>> > > >>> Thanks, > > >>> > > >>> Paul > > >>> > > >>> > > > > > > > > > From akashche at redhat.com Thu Sep 3 23:46:32 2020 From: akashche at redhat.com (Alex Kashchenko) Date: Fri, 4 Sep 2020 00:46:32 +0100 Subject: [8u] RFR 8221408: Windows 32bit build build errors/warnings in hotspot In-Reply-To: <5bd307bf-cdc1-0590-9d6e-8fe8acb8f9cf@redhat.com> References: <5bd307bf-cdc1-0590-9d6e-8fe8acb8f9cf@redhat.com> Message-ID: Hi, On 8/31/20, Zhengyu Gu wrote: > I would like to backport this patch to 8u for parity with Oracle 8u281. > > The backport is based on 11u patch and it does not apply cleanly. > > 1) classFileParser.cpp: change already in 8u via JDK-8205677 > 2) os_windows_x86.cpp: context is slightly different > > The original bug: https://bugs.openjdk.java.net/browse/JDK-8221408 > 11u patch: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/f03e922bfcb8 > > 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8221408-8u/webrev.00/ > > Test: > Built 32-bit JDKs on Windows (release and fastdebug) I am probably missing something, but I cannot reproduce the warnings neither with vs2010 nor with vs2017 fastdebug 32-bit builds. It seems that I am getting the same set of warnings (that doesn't include C4172) before and after the patch. Any specific pointers how the warnings should look like? Or is the change in markOop.hpp is just a cleanup? -- -Alex From akashche at redhat.com Thu Sep 3 23:52:56 2020 From: akashche at redhat.com (Alex Kashchenko) Date: Fri, 4 Sep 2020 00:52:56 +0100 Subject: [8u] RFR: 8202076: test/jdk/java/io/File/WinSpecialFiles.java on windows with VS2017 In-Reply-To: References: Message-ID: On 9/3/20, Zhengyu Gu wrote: > Looks good to me. Thanks for the review! I've added fix request to the bug. > > -Zhengyu > > On 9/3/20 12:32 PM, Alex Kashchenko wrote: >> Hi, >> >> Please review the backport of JDK-8202076 to 8u: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8202076 >> >> Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/7b259287cdd2 >> >> 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8202076/webrev.00/ >> >> Patch has required minor changes: paths, copyright year, "fslash" var >> declaration moved to the beginning of the block for C89 compat. >> Testing: jtreg:java/io/File/, jck:api/java_io/File/ . >> >> -- >> -Alex >> > > From jaroslav.bachorik at datadoghq.com Fri Sep 4 10:35:19 2020 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Fri, 4 Sep 2020 12:35:19 +0200 Subject: [8u] RFR 8250928: JFR: Improve hash algorithm for stack traces In-Reply-To: <581363a3-2438-1601-7139-9e6cc68f0671@redhat.com> References: <8f1d51a2-de4c-35f6-dfe0-076496054aa1@redhat.com> <581363a3-2438-1601-7139-9e6cc68f0671@redhat.com> Message-ID: Now, when https://bugs.openjdk.java.net/browse/JDK-8252754 has been fixed I think we can move on with this backport. Any objections? Cheers, -JB- On Tue, Sep 1, 2020 at 12:01 PM Aleksey Shipilev wrote: > > On 9/1/20 11:56 AM, Aleksey Shipilev wrote: > > On 8/31/20 7:11 PM, Jaroslav Bachor?k wrote: > >> Please, review this backport of a hash-collision reducing fix in JFR > >> stacktrace values from the main line. > >> > >> JIRA: https://bugs.openjdk.java.net/browse/JDK-8250928 > >> Webrev: http://cr.openjdk.java.net/~jbachorik/8250928/8u/webrev/ > > > > 8u backport looks fine. > > Oh wait, hold on a sec. > > The original changeset [1] only changes the bit in JfrStackTrace::record_safe. Why does this > backport change JfrStackTrace::record_safe and JfrStackTrace::record_thread? > > -- > Thanks, > -Aleksey > > [1] > https://hg.openjdk.java.net/jdk/jdk/file/c3cc9ac0ede2/src/hotspot/share/jfr/recorder/stacktrace/jfrStackTrace.cpp > From gnu.andrew at redhat.com Fri Sep 4 14:10:54 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 4 Sep 2020 15:10:54 +0100 Subject: RFR: 8251886: Unable to use --disable-zip-debug-info on JDK8 Windows In-Reply-To: References: <20200817172622.GB2749792@stopbrexit> Message-ID: <20200904141054.GA1479685@stopbrexit> On 13:56 Thu 20 Aug , Andrew Leonard wrote: > Hi Andrew, > I've done a webrev for the backport of > https://bugs.openjdk.java.net/browse/JDK-8025936 > http://cr.openjdk.java.net/~aleonard/8025936/ > Tests on the various platforms are all good. The original patch would not > backport directly since it's quite old, but it didn't take too much to fix > up. The main thing to add was the no_strip conditions. > I have added jdk8u-fix-request to the bug to backport. Would you be able > to sponsor please? > Many thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: andrew_m_leonard at uk.ibm.com > Sorry for the delay. Patch looks good to me. I'll push it now. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Fri Sep 4 16:11:24 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 4 Sep 2020 17:11:24 +0100 Subject: [gnu.andrew@redhat.com: Re: Additional Labels for Backport Work] Message-ID: <20200904161124.GB1550354@stopbrexit> Bringing discussion back to the 8u list. ----- Forwarded message from Andrew Hughes ----- Date: Fri, 4 Sep 2020 17:10:24 +0100 From: Andrew Hughes To: Jesper Wilhelmsson Subject: Re: Additional Labels for Backport Work User-Agent: Mutt/1.10.1 (2018-07-13) On 22:03 Thu 27 Aug , Jesper Wilhelmsson wrote: > > On 27 Aug 2020, at 21:58, Martin Balao wrote: > > > > On 8/27/20 1:48 PM, Mario Torre wrote: > >> After a brief discussion today, it occurred to me that we can create > >> backport bugs manually and assign them directly, wouldn't this be a > >> better approach to track who is working on a specific backport? > > > > Yes, I thought about this idea some time ago and discussing with Andrew > > (@gnu_andrew) he raised a valid concern: end-up with lots of backport > > bug duplicates when those manually created are not automatically > > resolved when pushing the fix -and new ones being created-. We would > > need to know exactly how to manually create bugs that are then resolved > > when pushing. But then we need to rely on everybody getting it right. > > I've seen duplicates already when manually creating backport bugs for CSRs. > > For an 8u backport set the fixVersion to 8-pool to have hg updater resolve the issue. This should be standard practice for all bugs/backports in update releases. Always set fixVersion to X-pool unless you know for sure what release you need it to go into and are requesting that the fix should be included in the release in the rampdown phase. > > /Jesper > Except it doesn't seem to work with OpenJDK 8u at present e.g. https://bugs.openjdk.java.net/browse/JDK-8160768 JDK-8251269 should have been resolved, but JDK-8252535 was created instead. I've mailed ops about this. I think it may be because '8u' is still the Oracle proprietary fork for 8, and openjdk8u is the open version. With 11u, it's the other way around (11.0.7 and 11.0.7-oracle, for example), so hopefully things work as expected there. I went the label route instead because it's less prone to error, easier to correct if errors do occur and intended to be transient (applied when you start work and removed when finished). Also the main bug ID is the one to refer to and use in changesets. I wouldn't like to see the additional confusion of backport IDs being used in mailing list posts and commits. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 ----- End forwarded message ----- -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From neugens at redhat.com Fri Sep 4 16:40:26 2020 From: neugens at redhat.com (Mario Torre) Date: Fri, 4 Sep 2020 18:40:26 +0200 Subject: [gnu.andrew@redhat.com: Re: Additional Labels for Backport Work] In-Reply-To: <20200904161124.GB1550354@stopbrexit> References: <20200904161124.GB1550354@stopbrexit> Message-ID: On Fri, Sep 4, 2020 at 6:12 PM Andrew Hughes wrote: > > Also the main > bug ID is the one to refer to and use in changesets. I wouldn't like > to see the additional confusion of backport IDs being used in mailing > list posts and commits. This is a very good point. Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From gnu.andrew at redhat.com Mon Sep 7 05:50:11 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 7 Sep 2020 06:50:11 +0100 Subject: [8u] RFR 8062947: Fix exception message to correctly represent LDAP connection failure In-Reply-To: References: Message-ID: <20200907055011.GB1707023@stopbrexit> On 11:45 Wed 02 Sep , Zhengyu Gu wrote: snip... > > The original bug: https://bugs.openjdk.java.net/browse/JDK-8062947 > The original patch: https://hg.openjdk.java.net/jdk/jdk/rev/868fe697bad4 > > > 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8062947-8u/webrev.00/ > > Test: > Included NamingExceptionMessageTest.java test on Linux x86_64 > > Thanks, > > -Zhengyu > The posted patch - https://cr.openjdk.java.net/~zgu/JDK-8062947-8u/webrev.00/ - seems to contain multiple changes unrelated to this bug: $ diffstat -p0 8062947.11u b/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java | 65 +-- b/src/java.naming/share/classes/com/sun/jndi/ldap/LdapRequest.java | 27 + b/test/jdk/com/sun/jndi/ldap/NamingExceptionMessageTest.java | 164 ++++++++++ 3 files changed, 205 insertions(+), 51 deletions(-) $ diffstat -p0 8062947.8u b/src/share/classes/com/sun/jndi/ldap/Connection.java | 65 b/src/share/classes/com/sun/jndi/ldap/DefaultLdapDnsProvider.java | 4 b/src/share/classes/com/sun/jndi/ldap/LdapDnsProviderService.java | 25 b/src/share/classes/com/sun/jndi/ldap/LdapRequest.java | 27 b/test/com/sun/jndi/ldap/LdapTimeoutTest.java | 778 +++++----- b/test/com/sun/jndi/ldap/NamingExceptionMessageTest.java | 165 ++ b/test/com/sun/jndi/ldap/lib/BaseLdapServer.java | 27 7 files changed, 668 insertions(+), 423 deletions(-) Please post a webrev just containing this fix. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Mon Sep 7 06:10:57 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 7 Sep 2020 07:10:57 +0100 Subject: [8u] RFR 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect In-Reply-To: References: Message-ID: <20200907061057.GC1707023@stopbrexit> On 09:24 Sat 29 Aug , Zhengyu Gu wrote: > I would like to backport this patch for parity with Oracle 8u271. > > The original patch does not apply cleanly. The conflicts on the fixes > are minors, can be easily resolved manually. > > 1) LdapTimeoutTest.java is not in ProblemList.txt in 8u > 2) Copyright lines in LdapTimeoutTest.java do not match > 3) Import lines in BaseLdapServer.java do not match > > > However, LdapTimeoutTest.java uses some new language features and APIs that > do not exist in 8u. It also uses new test library that needs to map back to > 8u test library. > > /* > * @test > - * @library /test/lib > + * @library /lib/testlibrary > * lib/ > * @run testng/othervm LdapTimeoutTest > * @bug 7094377 8000487 6176036 7056489 8151678 > @@ -59,7 +59,7 @@ > import static java.lang.String.format; > import static java.util.concurrent.TimeUnit.MILLISECONDS; > import static java.util.concurrent.TimeUnit.NANOSECONDS; > -import static jdk.test.lib.Utils.adjustTimeout; > +import static jdk.testlibrary.Utils.adjustTimeout; > import static org.testng.Assert.assertTrue; > import static org.testng.Assert.expectThrows; > > @@ -120,7 +120,7 @@ > executorService.shutdown(); > } > int failedCount = 0; > - for (var f : futures) { > + for (Future f : futures) { > try { > f.get(); > } catch (ExecutionException e) { > @@ -283,11 +283,14 @@ > > @Override > protected void beforeAcceptingConnections() { > - starting.completeAsync(() -> null); > + CompletableFuture.supplyAsync(() -> null) > + .whenComplete((input, exception) -> { > + starting.complete(null); > + }); > } > > public CompletableFuture starting() { > - return starting.copy(); > + return starting.toCompletableFuture(); > } > } > > Test: > jdk_other > > Thanks, > > -Zhengyu > There seem to be a couple of additional copyright header changes in this backport, in src/share/classes/com/sun/jndi/ldap/DefaultLdapDnsProvider.java and src/share/classes/com/sun/jndi/ldap/LdapDnsProviderService.java. Where do these come from? With the changes to LdapTimeoutTest.java, .copy() is not the same as .toCompletableFuture(), as the former creates a new CompleteableFuture (via newInCompleteFuture(), another 9u addition) that relays the result of the original, while the latter would appear to be just the same as returning starting directly. A closer equivalent would appear to be starting.thenApply((x) -> x), as suggested in the documentation of copy(). Do the amended tests complete successfully? Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Mon Sep 7 06:23:51 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 7 Sep 2020 07:23:51 +0100 Subject: [8u] RFR: 8051853: new URI("x/").resolve("..").getSchemeSpecificPart() returns null! In-Reply-To: References: Message-ID: <20200907062351.GD1707023@stopbrexit> On 17:32 Thu 03 Sep , Alex Kashchenko wrote: > Hi, > > Please review the fix to 8051853 for 8u. > > Note, the problem is not reproducible in 9+, it was fixed there as a > part of "8146686: Create the schemeSpecificPart for non-opaque URIs > lazily" . > > Bug: https://bugs.openjdk.java.net/browse/JDK-8051853 > > Related maillist discussion: > https://mail.openjdk.java.net/pipermail/net-dev/2016-January/009467.html > > Related point in 8146686: > https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/16296b4145d0#l1.30 > > 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8051853/webrev.00/ > > If appendSchemeSpecificPart() doesn't append anything to the specified > buffer, then defineSchemeSpecificPart() returns early and > schemeSpecificPart variable remains null. Proposed change removes > "early return" branch. > > -- > -Alex > Looks good to me. A zero length StringBuffer can be converted to an empty String ("") by the toString() method, so there is no need to special case this. Amazes me this has been broken so long! Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Mon Sep 7 06:37:35 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 7 Sep 2020 07:37:35 +0100 Subject: [8u] RFR 8u: Windows build failed after 8222079 backport In-Reply-To: References: <247e2cb5-bd7a-790e-60ce-242151ff9706@redhat.com> Message-ID: <20200907063735.GE1707023@stopbrexit> On 17:32 Thu 03 Sep , Alex Kashchenko wrote: > Hi Zhengyu, > > On 8/31/20, Zhengyu Gu wrote: > > Please review this small fix for Windows build after JDK-8222079 backport. > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8252573 > > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8252573/webrev.00/ > > > > Test: > > 64-bit and 32-bit builds on Windows > > The change looks good to me (not a reviewer), I've checked that it > fixes the problem with vs2010 compilation. > > -- > -Alex > It would help if the error message was given and an explanation of why the patch fixes it. If Alex is happy this fixes the compilation error, that should be ok. Has it being checked on GNU/Linux to make sure it doesn't break things there? Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From akashche at redhat.com Mon Sep 7 11:19:42 2020 From: akashche at redhat.com (Alex Kashchenko) Date: Mon, 7 Sep 2020 12:19:42 +0100 Subject: [8u] RFR: 8051853: new URI("x/").resolve("..").getSchemeSpecificPart() returns null! In-Reply-To: <20200907062351.GD1707023@stopbrexit> References: <20200907062351.GD1707023@stopbrexit> Message-ID: <2dce79b8-32ce-52cd-2653-252fff88fd5f@redhat.com> On 09/07/2020 07:23 AM, Andrew Hughes wrote: > On 17:32 Thu 03 Sep , Alex Kashchenko wrote: >> Hi, >> >> Please review the fix to 8051853 for 8u. >> >> Note, the problem is not reproducible in 9+, it was fixed there as a >> part of "8146686: Create the schemeSpecificPart for non-opaque URIs >> lazily" . >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8051853 >> >> Related maillist discussion: >> https://mail.openjdk.java.net/pipermail/net-dev/2016-January/009467.html >> >> Related point in 8146686: >> https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/16296b4145d0#l1.30 >> >> 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8051853/webrev.00/ >> >> If appendSchemeSpecificPart() doesn't append anything to the specified >> buffer, then defineSchemeSpecificPart() returns early and >> schemeSpecificPart variable remains null. Proposed change removes >> "early return" branch. >> >> -- >> -Alex >> > > Looks good to me. A zero length StringBuffer can be converted to an empty > String ("") by the toString() method, so there is no need to special case > this. Amazes me this has been broken so long! Thanks for the review! I've added fix request to the issue. -- -Alex From sgehwolf at redhat.com Mon Sep 7 15:36:29 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 07 Sep 2020 17:36:29 +0200 Subject: [8u] RFR 8252573: Windows build failed after 8222079 backport In-Reply-To: <247e2cb5-bd7a-790e-60ce-242151ff9706@redhat.com> References: <247e2cb5-bd7a-790e-60ce-242151ff9706@redhat.com> Message-ID: <3360cbc675307ffafb2e525ae1ac82337d41947e.camel@redhat.com> Hi Zhengyu, Adding bug number to subject line. On Mon, 2020-08-31 at 11:38 -0400, Zhengyu Gu wrote: > Please review this small fix for Windows build after JDK-8222079 > backport. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8252573 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8252573/webrev.00/ Looks good. Please flag this fix jdk8u-critical-request so as to get this into 8u272. It's causing Windows vanilla build failures. Thanks, Severin From alexey at azul.com Mon Sep 7 22:01:50 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Mon, 7 Sep 2020 22:01:50 +0000 Subject: [8u] RFR 8252886: [TESTBUG] sun/security/ec/TestEC.java : Compilation failed Message-ID: <68E3FDEB-8400-45F4-920C-7866BA526A84@azul.com> Hi All, Please review a small fix for the jdk/test/sun/security/ec/TestEC.java regression test JBS: https://bugs.openjdk.java.net/browse/JDK-8252886 Webrev: http://cr.openjdk.java.net/~abakhtin/8252886/webrev.v0/ The test starts to fail after regression tests update for the TLSv1.3 implementation [1] [2] [3] [4]. The reason of failure is missed TLSCommon library. Regards Alexey 1 - https://bugs.openjdk.java.net/browse/JDK-8245477 2 - https://bugs.openjdk.java.net/browse/JDK-8245653 3 - https://bugs.openjdk.java.net/browse/JDK-8245681 4 - https://bugs.openjdk.java.net/browse/JDK-8251478 From shade at redhat.com Tue Sep 8 06:22:35 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 8 Sep 2020 08:22:35 +0200 Subject: [8u] RFR 8252886: [TESTBUG] sun/security/ec/TestEC.java : Compilation failed In-Reply-To: <68E3FDEB-8400-45F4-920C-7866BA526A84@azul.com> References: <68E3FDEB-8400-45F4-920C-7866BA526A84@azul.com> Message-ID: <355f8326-0347-e2a8-f8c9-7bd59e6ddf0d@redhat.com> On 9/8/20 12:01 AM, Alexey Bakhtin wrote: > JBS: https://bugs.openjdk.java.net/browse/JDK-8252886 > Webrev: http://cr.openjdk.java.net/~abakhtin/8252886/webrev.v0/ Looks good. -- Thanks, -Aleksey From neugens at redhat.com Tue Sep 8 10:57:07 2020 From: neugens at redhat.com (Mario Torre) Date: Tue, 8 Sep 2020 12:57:07 +0200 Subject: [8u] RFR: 8213448: [TESTBUG] enhance jfr/jvm/TestDumpOnCrash In-Reply-To: <29a2b4bb2c9e40d1b0542ea900826957@azul.com> References: <29a2b4bb2c9e40d1b0542ea900826957@azul.com> Message-ID: Hi Ekaterina, Sorry for dropping the ball on this one. The patch is good! Cheers, Mario On Fri, Aug 14, 2020 at 4:46 PM Ekaterina Vergizova wrote: > > Hello, > I would like to backport JFR test only issue 8213448 to 8u as a prerequisite for JDK-8217362 backport. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8213448 > Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/f0af7fd0c9ca > Webrev for 8u: https://cr.openjdk.java.net/~apetushkov/jfr_backports_katya/8213448/webrev.00/ > > The patch doesn't apply cleanly due to the different context (Crasher.main method content, ProcessTools.createJavaProcessBuilder parameters), reapplied manually. > Then I made the following modifications to adjust the test to 8u: > - ProcessHandle.current().pid() calls are replaced by ProcessTools.getProcessId() > - Process.pid() call is replaced by obtaining pid from the process output due to lack of Process.pid() method in 8u. > > The affected test passed successfully on Linux and Windows. > > Thanks, > Ekaterina > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From andrey at azul.com Tue Sep 8 11:23:55 2020 From: andrey at azul.com (Andrey Petushkov) Date: Tue, 8 Sep 2020 14:23:55 +0300 Subject: [8u] RFR 8252904: VM crashes when JFR is used and JFR event class is transformed Message-ID: Dear All, Please consider the following fix to avoid crash when JFR event class is transformed upon load. The problem is caused by using stale reference to ClassFileStream which is created (conditionally if the class is transformed by JVMTI hook) under ResourceMark in ClassFileParser.parseClassFile(). This dead reference is leaked into caller code, where it is accessed by JFR itself. There is no such problem in jdk11 and above because class loading implementation is completely different and JVMTI hook responsible for transformation is invoked by KlassFactory, not ClassFileParser. Moreover, in jdk11 it's KlassFactory (analog of ClassLoader/SystemDictionary in a sense that it's the caller of ClassFileParser is responsible for placing ResourceMark, just like proposed patch does for jdk8u code) The problem can easily be reproduced on slowdebug build with a test which transforms jdk.jfr.Event class or it's subclasses. In this scenario VM crashes immediately when JFR is activated because ResourceMark destructor clears the freed memory. Webrev is here https://cr.openjdk.java.net/~apetushkov/8252904/ Thanks, Andrey From zgu at redhat.com Tue Sep 8 15:25:04 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 8 Sep 2020 11:25:04 -0400 Subject: [8u] RFR 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect In-Reply-To: <20200907061057.GC1707023@stopbrexit> References: <20200907061057.GC1707023@stopbrexit> Message-ID: Hi Andrew, On 9/7/20 2:10 AM, Andrew Hughes wrote: > On 09:24 Sat 29 Aug , Zhengyu Gu wrote: >> I would like to backport this patch for parity with Oracle 8u271. >> > > There seem to be a couple of additional copyright header changes in > this backport, in > src/share/classes/com/sun/jndi/ldap/DefaultLdapDnsProvider.java and > src/share/classes/com/sun/jndi/ldap/LdapDnsProviderService.java. Where > do these come from? They came from the original JDK-8151678 patch [1] > > With the changes to LdapTimeoutTest.java, .copy() is not the same > as .toCompletableFuture(), as the former creates a new CompleteableFuture > (via newInCompleteFuture(), another 9u addition) that relays the > result of the original, while the latter would appear to be just the > same as returning starting directly. A closer equivalent would appear > to be starting.thenApply((x) -> x), as suggested in the documentation of > copy(). Updated: http://cr.openjdk.java.net/~zgu/JDK-8151678-8u/webrev.01/ > > Do the amended tests complete successfully? > Yes, before and after your suggested change. Test: Reran jdk_other. Thanks, -Zhengyu [1] https://hg.openjdk.java.net/jdk/jdk/rev/1def54255e93 > From zgu at redhat.com Tue Sep 8 15:34:02 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 8 Sep 2020 11:34:02 -0400 Subject: [8u] RFR 8062947: Fix exception message to correctly represent LDAP connection failure In-Reply-To: <20200907055011.GB1707023@stopbrexit> References: <20200907055011.GB1707023@stopbrexit> Message-ID: > > Please post a webrev just containing this fix. Updated: http://cr.openjdk.java.net/~zgu/JDK-8062947-8u/webrev.01/ Thanks, -Zhengyu > > Thanks, > From adinn at redhat.com Tue Sep 8 15:34:38 2020 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 8 Sep 2020 16:34:38 +0100 Subject: [8u] RFR 8252904: VM crashes when JFR is used and JFR event class is transformed In-Reply-To: References: Message-ID: <8254effd-5ec6-867c-efc1-dc9e80cf6999@redhat.com> Hi Andrey, Thanks for debugging this and great work pinning it down. I think this problem is probably responsible for the following Graal issue https://github.com/oracle/graal/issues/2748 On 08/09/2020 12:23, Andrey Petushkov wrote: > Please consider the following fix to avoid crash when JFR event class is > transformed upon load. The problem is caused by using stale reference to > ClassFileStream which is created (conditionally if the class is > transformed by JVMTI hook) under ResourceMark in > ClassFileParser.parseClassFile(). This dead reference is leaked into > caller code, where it is accessed by JFR itself. > > There is no such problem in jdk11 and above because class loading > implementation is completely different and JVMTI hook responsible for > transformation is invoked by KlassFactory, not ClassFileParser. > Moreover, in jdk11 it's KlassFactory (analog of > ClassLoader/SystemDictionary in a sense that it's the caller of > ClassFileParser is responsible for placing ResourceMark, just like > proposed patch does for jdk8u code) > . . .> Webrev is here https://cr.openjdk.java.net/~apetushkov/8252904/ I don't much like this solution because it places the ResourceMark outside of the scope in which the allocations it guards against are performed i.e. at around the call to parseClassFile rather than at the start of that method. I know there is a precedent for this in the way the jdk11u code works. However, it's slightly less opaque in that case as the code that allocates (and, potentially re-allocates) the stream is only ever invoked under a constructor which is located in the same scope as the ResourceMark. That said, I don't see any easy way to achieve the desired outcome without a significant re-ordering of the jdk8u code which risks introducing other problems. We certainly don;t want to backport the significant changes made in jdk11u. So, I guess we are stuck with doing it this way. I have 3 other concerns. You allocated a ResourceMark before the calls to parseClassFile in SystemDictionary::parse_stream and SystemDictionary::resolve_from_stream but not before the call from ClassLoader::load_classfile. Surely that also needs one? Secondly, the ResourceMark in SystemDictionary::parse_stream and SystemDictionary::resolve_from_stream both extend to the end of the method. Clearly, in the second case the scope needs to extend beyond the call to ON_KLASS_CREATION. However, is it necessary to extend to the end of the caller method? I think it would be be better to declare each ResourceMark in a new block that limits the scope to the minimal range that is needed (if you can do that without updating the current indentation that would be even better). Finally, I think you need to add more commentary to explain what is going on. So, you need a comment at each point where a ResourceMark is allocated saying: // Callers are expected to declare a ResourceMark to determine // the lifetime of any updated (resource) allocated under // this call to parseClassFile In the method itself you should say more in the comment which replaces the ResourceMark declaration: // JDK-8252904: // The stream (resource) attached to the instance klass may // be reallocated by this method. When JFR is included the // stream may need to survive beyond the end of the call. So, // the caller is expected to declare the ResourceMark that // determines the lifetime of resources allocated under this // call. Last but not least, what have you done to test this patch? regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From gnu.andrew at redhat.com Tue Sep 8 15:57:13 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 8 Sep 2020 16:57:13 +0100 Subject: [8u] RFR 8252886: [TESTBUG] sun/security/ec/TestEC.java : Compilation failed In-Reply-To: <68E3FDEB-8400-45F4-920C-7866BA526A84@azul.com> References: <68E3FDEB-8400-45F4-920C-7866BA526A84@azul.com> Message-ID: <20200908155713.GC1846517@stopbrexit> On 22:01 Mon 07 Sep , Alexey Bakhtin wrote: > Hi All, > > Please review a small fix for the jdk/test/sun/security/ec/TestEC.java regression test > > JBS: https://bugs.openjdk.java.net/browse/JDK-8252886 > Webrev: http://cr.openjdk.java.net/~abakhtin/8252886/webrev.v0/ > > The test starts to fail after regression tests update for the TLSv1.3 implementation [1] [2] [3] [4]. The reason of failure is missed TLSCommon library. > > Regards > Alexey > > 1 - https://bugs.openjdk.java.net/browse/JDK-8245477 > 2 - https://bugs.openjdk.java.net/browse/JDK-8245653 > 3 - https://bugs.openjdk.java.net/browse/JDK-8245681 > 4 - https://bugs.openjdk.java.net/browse/JDK-8251478 Ok, please flag with jdk8u-critical-request. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Tue Sep 8 16:05:06 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 8 Sep 2020 17:05:06 +0100 Subject: [8u] RFR: 8252395: [8u] --with-native-debug-symbols=external doesn't include debuginfo files for binaries In-Reply-To: <920cb027de417118b3522d4ba20baf04c45f9621.camel@redhat.com> References: <920cb027de417118b3522d4ba20baf04c45f9621.camel@redhat.com> Message-ID: <20200908160506.GD1846517@stopbrexit> On 13:44 Mon 31 Aug , Severin Gehwolf wrote: > Sorry, wrong webrev. Now corrected. > > On Mon, 2020-08-31 at 10:02 +0200, Severin Gehwolf wrote: > > Hi, > > > > Could I get a reivew of this 8u specific bug please? When configured > > --with-native-debug-symbols=external,zipped the resulting external > > debuginfo files for binaries (in images/bin folder) aren't there. > > > > In OpenJDK 8u there is some special casing involved for bin/java and > > bin/unpack200. Thus, I had to special case them for the debuginfo > > variant files too otherwise those files would be missing in the images > > folders (j2sdk-image, j2re-image). > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8252395 > > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8252395/02/webrev/ > > > > > Testing: Build in configs --with-native-debugsymbols={zipped,external,internal,none} > > on Linux x86 and manually debugging some launcher code. Works now > > with symbols. Symbols were missing before this patch. > > > > Thanks, > Severin > Patch looks ok, particularly when there is a comment in the original, "For unknown reason the debuginfo files for executables are not put into images" :) This was all removed on mass in JDK-8049367 for the module system, so there is no obvious backport. Is any follow-on change for Windows necessary? Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From andrey at azul.com Tue Sep 8 16:22:51 2020 From: andrey at azul.com (Andrey Petushkov) Date: Tue, 8 Sep 2020 19:22:51 +0300 Subject: [8u] RFR 8252904: VM crashes when JFR is used and JFR event class is transformed In-Reply-To: <8254effd-5ec6-867c-efc1-dc9e80cf6999@redhat.com> References: <8254effd-5ec6-867c-efc1-dc9e80cf6999@redhat.com> Message-ID: <3d186ed5-97e0-2b62-9a4f-a14bb2417c40@azul.com> Hi Andrew, Thank you very much for your comprehensive review, please see comments inline On 08.09.2020 18:34, Andrew Dinn wrote: > Hi Andrey, > > Thanks for debugging this and great work pinning it down. > > I think this problem is probably responsible for the following Graal issue > > https://github.com/oracle/graal/issues/2748 > > On 08/09/2020 12:23, Andrey Petushkov wrote: >> Please consider the following fix to avoid crash when JFR event class is >> transformed upon load. The problem is caused by using stale reference to >> ClassFileStream which is created (conditionally if the class is >> transformed by JVMTI hook) under ResourceMark in >> ClassFileParser.parseClassFile(). This dead reference is leaked into >> caller code, where it is accessed by JFR itself. >> >> There is no such problem in jdk11 and above because class loading >> implementation is completely different and JVMTI hook responsible for >> transformation is invoked by KlassFactory, not ClassFileParser. >> Moreover, in jdk11 it's KlassFactory (analog of >> ClassLoader/SystemDictionary in a sense that it's the caller of >> ClassFileParser is responsible for placing ResourceMark, just like >> proposed patch does for jdk8u code) >> . . .> Webrev is here https://cr.openjdk.java.net/~apetushkov/8252904/ > I don't much like this solution because it places the ResourceMark > outside of the scope in which the allocations it guards against are > performed i.e. at around the call to parseClassFile rather than at the > start of that method. > > I know there is a precedent for this in the way the jdk11u code works. > However, it's slightly less opaque in that case as the code that > allocates (and, potentially re-allocates) the stream is only ever > invoked under a constructor which is located in the same scope as the > ResourceMark. > > That said, I don't see any easy way to achieve the desired outcome > without a significant re-ordering of the jdk8u code which risks > introducing other problems. We certainly don;t want to backport the > significant changes made in jdk11u. So, I guess we are stuck with doing > it this way. fully agree with you. And given that it's very much unlikely that the files in question be modified significantly in the future so I think the risk of reducing maintainability/adding more opportunities for the bugs by implementing this change is rather very low > > I have 3 other concerns. You allocated a ResourceMark before the calls > to parseClassFile in SystemDictionary::parse_stream and > SystemDictionary::resolve_from_stream but not before the call from > ClassLoader::load_classfile. Surely that also needs one? ClassLoader::load_classfile has it's own ResourceMark in the first line of it's body. Clear it's done for other reasons but I thought it's close enough to parseClassFile() invocation statement so I think it's enough cover maintainability aspects (although adding comment is necessary). >From the memory allocation aspects I also see no reasons to create separate allocation context specifically for ClassFileParser. That's why I did not add another ResourceMark there > > Secondly, the ResourceMark in SystemDictionary::parse_stream and > SystemDictionary::resolve_from_stream both extend to the end of the > method. Clearly, in the second case the scope needs to extend beyond the > call to ON_KLASS_CREATION. However, is it necessary to extend to the end > of the caller method? I think it would be be better to declare each > ResourceMark in a new block that limits the scope to the minimal range > that is needed (if you can do that without updating the current > indentation that would be even better). On a second thought I think the proper way is a bit? different. Given that ClassFileParser instance may hold the reference to memory allocated in parseClassFile I think that: - ResourceMark should be put before invocation of the constructor of ClassFileParser (i.e. declaration of a local variable) - and extend to the whole scope of ClassFileParser instance Given that: - in SystemDictionary::parse_stream I will do exactly as you suggest because really ClassFileParser lifespan is a single statement - in SystemDictionary::resolve_from_stream I have to put ResourceMark one line higher, before introducing `parser` local. However adding an explicit scope end for ResourceMark as you suggest does not seem to make any difference here. If done, it shall happen on line 1171 but there is only debug_only block. So it will anyway span to the end of method (in a product build). However for the purpose of giving a proper message to the developers I have no objections in introducing a block here as well. Please let me know what you think > > Finally, I think you need to add more commentary to explain what is > going on. So, you need a comment at each point where a ResourceMark is > allocated saying: > > // Callers are expected to declare a ResourceMark to determine > // the lifetime of any updated (resource) allocated under > // this call to parseClassFile > > In the method itself you should say more in the comment which replaces > the ResourceMark declaration: > > // JDK-8252904: > // The stream (resource) attached to the instance klass may > // be reallocated by this method. When JFR is included the > // stream may need to survive beyond the end of the call. So, > // the caller is expected to declare the ResourceMark that > // determines the lifetime of resources allocated under this > // call. Will do > > Last but not least, what have you done to test this patch? We have a proprietary though simple test which instruments all the java classes loaded into VM. I've used this test in conjunction with the slowdebug VM to test the fix. As mentioned, the VM crashes reliably without a fix, while successfully working with it (given the nature of the test it in fact verifies not only that JFR event classes can now be instrumented successfully, but also serves some sanity check that all other class loads happened via other code paths are not affected, to the extent the slowdebug VM assertions can verify) I cannot publish the source code of a test but if necessary I can prepare a minimal reproducer Thanks, Andrey > > regards, > > > Andrew Dinn > ----------- > Red Hat Distinguished Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill From neugens at redhat.com Tue Sep 8 16:24:05 2020 From: neugens at redhat.com (Mario Torre) Date: Tue, 8 Sep 2020 18:24:05 +0200 Subject: [RFR]: JDK-8196196: Headful tests should not be run in headless mode In-Reply-To: References: Message-ID: Hi Severin, I got a new version here: https://cr.openjdk.java.net/~neugens/8196196/webrev.01/ It's essentially the same, except a couple of minor things. Cheers, Mario On Fri, Aug 21, 2020 at 3:05 PM Mario Torre wrote: > > Hi Severin, > > Thanks for the review! > > Unfortunately I forgot to add the fix-request label, and I just > realised that there are some changes like BadDisplayTest.java now is > gone. > > This is a trivial change, but I need to go back at it and see if some > of the modifications I did to adapt the patch to 8u are still > necessary, I think I'll need to resubmit the patch for review... > > Cheers, > Mario > > On Fri, Aug 21, 2020 at 2:25 PM Severin Gehwolf wrote: > > > > On Wed, 2020-07-08 at 14:39 +0200, Mario Torre wrote: > > > Hi all, > > > > > > I would like to have a review for the following bug since it doesn't > > > apply cleanly: > > > > > > https://bugs.openjdk.java.net/browse/JDK-8196196 > > > > > > I had to rework a number of them, for example a couple of tests don't > > > exist in JDK8u while other had test code changes that didn't apply to > > > 8u. The new webrev is here: > > > > > > http://cr.openjdk.java.net/~neugens/8196196/webrev.00/ > > > > This looks OK to me. > > > > Thanks, > > Severin > > > > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From sgehwolf at redhat.com Tue Sep 8 16:29:51 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 08 Sep 2020 18:29:51 +0200 Subject: [8u] RFR: 8252395: [8u] --with-native-debug-symbols=external doesn't include debuginfo files for binaries In-Reply-To: <20200908160506.GD1846517@stopbrexit> References: <920cb027de417118b3522d4ba20baf04c45f9621.camel@redhat.com> <20200908160506.GD1846517@stopbrexit> Message-ID: Hi, On Tue, 2020-09-08 at 17:05 +0100, Andrew Hughes wrote: > On 13:44 Mon 31 Aug , Severin Gehwolf wrote: > > Sorry, wrong webrev. Now corrected. > > > > On Mon, 2020-08-31 at 10:02 +0200, Severin Gehwolf wrote: > > > Hi, > > > > > > Could I get a reivew of this 8u specific bug please? When configured > > > --with-native-debug-symbols=external,zipped the resulting external > > > debuginfo files for binaries (in images/bin folder) aren't there. > > > > > > In OpenJDK 8u there is some special casing involved for bin/java and > > > bin/unpack200. Thus, I had to special case them for the debuginfo > > > variant files too otherwise those files would be missing in the images > > > folders (j2sdk-image, j2re-image). > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8252395 > > > > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8252395/02/webrev/ > > > > > Testing: Build in configs --with-native-debugsymbols={zipped,external,internal,none} > > > on Linux x86 and manually debugging some launcher code. Works now > > > with symbols. Symbols were missing before this patch. > > > > > > > Thanks, > > Severin > > > > Patch looks ok Thanks for the review! > Is any follow-on change for Windows necessary? I don't know as I don't have a way to test/develop it. It shouldn't make anything worse on the Windows side, though. Thanks, Severin From gnu.andrew at redhat.com Tue Sep 8 16:36:23 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 8 Sep 2020 17:36:23 +0100 Subject: [8u] RFR 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect In-Reply-To: References: <20200907061057.GC1707023@stopbrexit> Message-ID: <20200908163623.GE1846517@stopbrexit> On 11:25 Tue 08 Sep , Zhengyu Gu wrote: > Hi Andrew, > > On 9/7/20 2:10 AM, Andrew Hughes wrote: > > On 09:24 Sat 29 Aug , Zhengyu Gu wrote: > > > I would like to backport this patch for parity with Oracle 8u271. > > > > > > > There seem to be a couple of additional copyright header changes in > > this backport, in > > src/share/classes/com/sun/jndi/ldap/DefaultLdapDnsProvider.java and > > src/share/classes/com/sun/jndi/ldap/LdapDnsProviderService.java. Where > > do these come from? > > They came from the original JDK-8151678 patch [1] > Ok, I would usually say follow the closest version for backport, to avoid duplicating work, possibly differently (see [0]), but this looks like a bad backport in 11u. They omitted these copyright changes for this patch [1], because they altered these files in the backport of 8160768 [2]. I guess you could say that was because the backport in 8u was not based on 11u's JD-8160768 either, but I think their decision in 11u was wrong here. In future, please try and base backports on the closest version and feel free to raise any issues you think are wrong in that backport on the original thread. > > > > > With the changes to LdapTimeoutTest.java, .copy() is not the same > > as .toCompletableFuture(), as the former creates a new CompleteableFuture > > (via newInCompleteFuture(), another 9u addition) that relays the > > result of the original, while the latter would appear to be just the > > same as returning starting directly. A closer equivalent would appear > > to be starting.thenApply((x) -> x), as suggested in the documentation of > > copy(). > Updated: http://cr.openjdk.java.net/~zgu/JDK-8151678-8u/webrev.01/ > > > > > Do the amended tests complete successfully? > > > Yes, before and after your suggested change. > > Test: > Reran jdk_other. > > Thanks, > > -Zhengyu > > > [1] https://hg.openjdk.java.net/jdk/jdk/rev/1def54255e93 > > > Thanks. This looks good now. Please flag with jdk8-critical-request. [0] https://wiki.openjdk.java.net/display/jdk8u/Main [1] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-August/003706.html [2] https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/d3968414c142 -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Tue Sep 8 16:38:11 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 8 Sep 2020 17:38:11 +0100 Subject: [8u] RFR: 8252395: [8u] --with-native-debug-symbols=external doesn't include debuginfo files for binaries In-Reply-To: References: <920cb027de417118b3522d4ba20baf04c45f9621.camel@redhat.com> <20200908160506.GD1846517@stopbrexit> Message-ID: <20200908163811.GF1846517@stopbrexit> On 18:29 Tue 08 Sep , Severin Gehwolf wrote: snip... > > > Is any follow-on change for Windows necessary? > > I don't know as I don't have a way to test/develop it. It shouldn't > make anything worse on the Windows side, though. > Yes, I can see that and have approved this fix for 8u now. I just wondered if there was work here for someone to fix on that platform as well. > Thanks, > Severin > Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From andrey at azul.com Tue Sep 8 16:39:35 2020 From: andrey at azul.com (Andrey Petushkov) Date: Tue, 8 Sep 2020 19:39:35 +0300 Subject: [8u] RFR 8252904: VM crashes when JFR is used and JFR event class is transformed In-Reply-To: <3d186ed5-97e0-2b62-9a4f-a14bb2417c40@azul.com> References: <8254effd-5ec6-867c-efc1-dc9e80cf6999@redhat.com> <3d186ed5-97e0-2b62-9a4f-a14bb2417c40@azul.com> Message-ID: <6d113b25-728d-22be-858d-61d4500347a4@azul.com> Hi Andrew, updated webrev https://cr.openjdk.java.net/~apetushkov/8252904.01/ Andrey On 08.09.2020 19:22, Andrey Petushkov wrote: > Hi Andrew, > > Thank you very much for your comprehensive review, please see comments > inline > > On 08.09.2020 18:34, Andrew Dinn wrote: >> Hi Andrey, >> >> Thanks for debugging this and great work pinning it down. >> >> I think this problem is probably responsible for the following Graal issue >> >> https://github.com/oracle/graal/issues/2748 >> >> On 08/09/2020 12:23, Andrey Petushkov wrote: >>> Please consider the following fix to avoid crash when JFR event class is >>> transformed upon load. The problem is caused by using stale reference to >>> ClassFileStream which is created (conditionally if the class is >>> transformed by JVMTI hook) under ResourceMark in >>> ClassFileParser.parseClassFile(). This dead reference is leaked into >>> caller code, where it is accessed by JFR itself. >>> >>> There is no such problem in jdk11 and above because class loading >>> implementation is completely different and JVMTI hook responsible for >>> transformation is invoked by KlassFactory, not ClassFileParser. >>> Moreover, in jdk11 it's KlassFactory (analog of >>> ClassLoader/SystemDictionary in a sense that it's the caller of >>> ClassFileParser is responsible for placing ResourceMark, just like >>> proposed patch does for jdk8u code) >>> . . .> Webrev is here https://cr.openjdk.java.net/~apetushkov/8252904/ >> I don't much like this solution because it places the ResourceMark >> outside of the scope in which the allocations it guards against are >> performed i.e. at around the call to parseClassFile rather than at the >> start of that method. >> >> I know there is a precedent for this in the way the jdk11u code works. >> However, it's slightly less opaque in that case as the code that >> allocates (and, potentially re-allocates) the stream is only ever >> invoked under a constructor which is located in the same scope as the >> ResourceMark. >> >> That said, I don't see any easy way to achieve the desired outcome >> without a significant re-ordering of the jdk8u code which risks >> introducing other problems. We certainly don;t want to backport the >> significant changes made in jdk11u. So, I guess we are stuck with doing >> it this way. > fully agree with you. And given that it's very much unlikely that the > files in question be modified significantly in the future so I think the > risk of reducing maintainability/adding more opportunities for the bugs > by implementing this change is rather very low >> I have 3 other concerns. You allocated a ResourceMark before the calls >> to parseClassFile in SystemDictionary::parse_stream and >> SystemDictionary::resolve_from_stream but not before the call from >> ClassLoader::load_classfile. Surely that also needs one? > ClassLoader::load_classfile has it's own ResourceMark in the first line > of it's body. Clear it's done for other reasons but I thought it's close > enough to parseClassFile() invocation statement so I think it's enough > cover maintainability aspects (although adding comment is necessary). > From the memory allocation aspects I also see no reasons to create > separate allocation context specifically for ClassFileParser. That's why > I did not add another ResourceMark there >> Secondly, the ResourceMark in SystemDictionary::parse_stream and >> SystemDictionary::resolve_from_stream both extend to the end of the >> method. Clearly, in the second case the scope needs to extend beyond the >> call to ON_KLASS_CREATION. However, is it necessary to extend to the end >> of the caller method? I think it would be be better to declare each >> ResourceMark in a new block that limits the scope to the minimal range >> that is needed (if you can do that without updating the current >> indentation that would be even better). > On a second thought I think the proper way is a bit? different. Given > that ClassFileParser instance may hold the reference to memory allocated > in parseClassFile I think that: > - ResourceMark should be put before invocation of the constructor of > ClassFileParser (i.e. declaration of a local variable) > - and extend to the whole scope of ClassFileParser instance > > Given that: > - in SystemDictionary::parse_stream I will do exactly as you suggest > because really ClassFileParser lifespan is a single statement > - in SystemDictionary::resolve_from_stream I have to put ResourceMark > one line higher, before introducing `parser` local. However adding an > explicit scope end for ResourceMark as you suggest does not seem to make > any difference here. If done, it shall happen on line 1171 but there is > only debug_only block. So it will anyway span to the end of method (in a > product build). However for the purpose of giving a proper message to > the developers I have no objections in introducing a block here as well. > Please let me know what you think >> Finally, I think you need to add more commentary to explain what is >> going on. So, you need a comment at each point where a ResourceMark is >> allocated saying: >> >> // Callers are expected to declare a ResourceMark to determine >> // the lifetime of any updated (resource) allocated under >> // this call to parseClassFile >> >> In the method itself you should say more in the comment which replaces >> the ResourceMark declaration: >> >> // JDK-8252904: >> // The stream (resource) attached to the instance klass may >> // be reallocated by this method. When JFR is included the >> // stream may need to survive beyond the end of the call. So, >> // the caller is expected to declare the ResourceMark that >> // determines the lifetime of resources allocated under this >> // call. > Will do >> Last but not least, what have you done to test this patch? > We have a proprietary though simple test which instruments all the java > classes loaded into VM. I've used this test in conjunction with the > slowdebug VM to test the fix. As mentioned, the VM crashes reliably > without a fix, while successfully working with it (given the nature of > the test it in fact verifies not only that JFR event classes can now be > instrumented successfully, but also serves some sanity check that all > other class loads happened via other code paths are not affected, to the > extent the slowdebug VM assertions can verify) > > I cannot publish the source code of a test but if necessary I can > prepare a minimal reproducer > > Thanks, > Andrey >> regards, >> >> >> Andrew Dinn >> ----------- >> Red Hat Distinguished Engineer >> Red Hat UK Ltd >> Registered in England and Wales under Company Registration No. 03798903 >> Directors: Michael Cunningham, Michael ("Mike") O'Neill From gnu.andrew at redhat.com Tue Sep 8 16:45:59 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 8 Sep 2020 17:45:59 +0100 Subject: [8u] RFR 8062947: Fix exception message to correctly represent LDAP connection failure In-Reply-To: References: <20200907055011.GB1707023@stopbrexit> Message-ID: <20200908164559.GG1846517@stopbrexit> On 11:34 Tue 08 Sep , Zhengyu Gu wrote: > > > > > Please post a webrev just containing this fix. > > Updated: http://cr.openjdk.java.net/~zgu/JDK-8062947-8u/webrev.01/ > > Thanks, > > -Zhengyu > > > > > Thanks, > > > Thanks. This looks fine. I really don't know why they use this 'var'. It just makes the code less readable IMHO e.g. var env = ldapServer.getInitialLdapCtxEnvironment(0); I have no idea what env is with this. Hashtable env = ldapServer.getInitialLdapCtxEnvironment(0); With this, I do. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From adinn at redhat.com Wed Sep 9 09:50:43 2020 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 9 Sep 2020 10:50:43 +0100 Subject: [8u] RFR 8252904: VM crashes when JFR is used and JFR event class is transformed In-Reply-To: <6d113b25-728d-22be-858d-61d4500347a4@azul.com> References: <8254effd-5ec6-867c-efc1-dc9e80cf6999@redhat.com> <3d186ed5-97e0-2b62-9a4f-a14bb2417c40@azul.com> <6d113b25-728d-22be-858d-61d4500347a4@azul.com> Message-ID: <41344ab4-14f5-d71f-b8b2-ff035505b159@redhat.com> Hi Andrey, On 08/09/2020 17:39, Andrey Petushkov wrote: > updated webrev https://cr.openjdk.java.net/~apetushkov/8252904.01/ Thanks. That looks better. I agree that aligning the resource mark with the lifetime of the ClassFileParser instance is the correct model. Of course, in SystemDictionary::resolve_from_stream that lifetime is longer than it needs to be. However, fixing that is not needed to deal with the bug so I'm more than happy to leave well alone, minimizing perturbation of the existing code. >>> Last but not least, what have you done to test this patch? >> We have a proprietary though simple test which instruments all the java >> classes loaded into VM. I've used this test in conjunction with the >> slowdebug VM to test the fix. As mentioned, the VM crashes reliably >> without a fix, while successfully working with it (given the nature of >> the test it in fact verifies not only that JFR event classes can now be >> instrumented successfully, but also serves some sanity check that all >> other class loads happened via other code paths are not affected, to the >> extent the slowdebug VM assertions can verify) >> >> I cannot publish the source code of a test but if necessary I can >> prepare a minimal reproducer Yes, please. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From zgu at redhat.com Wed Sep 9 13:27:22 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 9 Sep 2020 09:27:22 -0400 Subject: [8u] RFR 8250665: Wrong translation for the month name of May in ar_JO,LB,SY Message-ID: I would like to backport this patch to 8u for parity with Oracle 8u281. The original patch does not apply cleanly, but conflicts are limited on copyright years and bug id lines of LocaleDataTest.java, can be easily resolved manually. The original bug: https://bugs.openjdk.java.net/browse/JDK-8250665 The original patch: https://hg.openjdk.java.net/jdk/jdk/rev/9aa999666ccc 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8250665-8u/webrev.00/ Test: LocaleDataTest.java Thanks, -Zhengyu From hohensee at amazon.com Wed Sep 9 17:44:32 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 9 Sep 2020 17:44:32 +0000 Subject: RFA/RFA (M): 8231209: [REDO] JDK-8207266 ThreadMXBean::getThreadAllocatedBytes() can be quicker for self thread Message-ID: Please review this backport to 8u. It was not clean, and requires a CSR. Please review the CSR as well. The patch has been backported to both 11u and Oracle 11u. Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8231209 Original CSR: https://bugs.openjdk.java.net/browse/JDK-8231374 Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/c29e49148be7 Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8247811 Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8247812 Backport jdk webrev: http://cr.openjdk.java.net/~phh/8231209/webrev.8u.jdk.00/ Backport hotspot webrev: http://cr.openjdk.java.net/~phh/8231209/webrev.8u.hotspot.00/ These webrevs depend on a pending backport for JDK-8185003, see https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-September/012613.html, and if both are approved will be pushed after that backport. GetOneThreadAllocatedMemory, a new JMM interface method referenced in jmm.h, occupies the reserved2 jmmInterface slot rather than its original one, because otherwise the jmmInterface binary interface would not be compatible with 8u. There are minor changes to jmm_GetOneThreadAllocatedMemory in management.cpp to conform to 8u?s internal interfaces. HotspotThreadImpl.java doesn?t exist in 8u. It?s functionality (exposing c.s.m.ThreadMXBean protected methods as public) is replaced by simply declaring those methods public in ThreadImpl.java. The nsk tests don?t exist in 8u, so the updates to BaseBehaviorTest.* and ServerThreadMXBeanNew.java are dropped. A follow-on backport review request for https://bugs.openjdk.java.net/browse/JDK-8231968: getCurrentThreadAllocatedBytes default implementation s/b getThreadAllocatedBytes, will follow to fix a bug in the Original CSR. Thanks, Paul From andrey at azul.com Wed Sep 9 18:00:48 2020 From: andrey at azul.com (Andrey Petushkov) Date: Wed, 9 Sep 2020 21:00:48 +0300 Subject: [8u] RFR 8252904: VM crashes when JFR is used and JFR event class is transformed In-Reply-To: <41344ab4-14f5-d71f-b8b2-ff035505b159@redhat.com> References: <8254effd-5ec6-867c-efc1-dc9e80cf6999@redhat.com> <3d186ed5-97e0-2b62-9a4f-a14bb2417c40@azul.com> <6d113b25-728d-22be-858d-61d4500347a4@azul.com> <41344ab4-14f5-d71f-b8b2-ff035505b159@redhat.com> Message-ID: added jtreg test https://cr.openjdk.java.net/~apetushkov/8252904.jdk/ the test reliably fails on slowdebug VM without the bugfix and reliably passes with a fix. note that the test will not reliably fail on a product VM without fix, only occasionally Andrey On 09.09.2020 12:50, Andrew Dinn wrote: > Hi Andrey, > > On 08/09/2020 17:39, Andrey Petushkov wrote: > >> updated webrev https://cr.openjdk.java.net/~apetushkov/8252904.01/ > Thanks. That looks better. I agree that aligning the resource mark with > the lifetime of the ClassFileParser instance is the correct model. > > Of course, in SystemDictionary::resolve_from_stream that lifetime is > longer than it needs to be. However, fixing that is not needed to deal > with the bug so I'm more than happy to leave well alone, minimizing > perturbation of the existing code. > >>>> Last but not least, what have you done to test this patch? >>> We have a proprietary though simple test which instruments all the java >>> classes loaded into VM. I've used this test in conjunction with the >>> slowdebug VM to test the fix. As mentioned, the VM crashes reliably >>> without a fix, while successfully working with it (given the nature of >>> the test it in fact verifies not only that JFR event classes can now be >>> instrumented successfully, but also serves some sanity check that all >>> other class loads happened via other code paths are not affected, to the >>> extent the slowdebug VM assertions can verify) >>> >>> I cannot publish the source code of a test but if necessary I can >>> prepare a minimal reproducer > Yes, please. > > regards, > > > Andrew Dinn > ----------- > Red Hat Distinguished Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill From sgehwolf at redhat.com Wed Sep 9 18:16:42 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 09 Sep 2020 20:16:42 +0200 Subject: [8u] RFR: 8252975: [8u] JDK-8252395 breaks the build for --with-native-debug-symbols=internal Message-ID: Hi, Please review this 8u (jdk8u/jdk8u-dev tree) fix for JDK-8252395 that I've pushed today. Thanks for Zhengyu Gu for noticing it. The pushed fix added the java.debuginfo and unpack.debuginfo make targets on the condition of ENABLE_DEBUG_SYMBOLS=true, which is insufficient. It needs another check on POST_STRIP_CMD which is set to non-empty for --with- native-debug-symbols={external,zipped}, and is indeed empty for --with- native-debug-symbols=internal. For the --with-native-debug-symbols=none case we have ENABLE_DEBUG_SYMBOLS=false. Bug: https://bugs.openjdk.java.net/browse/JDK-8252975 webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8252975/01/webrev/ Testing: Builds with --with-native-debug-symbols={none,internal,external,zipped} on Linux x86_64 OK? Thanks, Severin From zgu at redhat.com Wed Sep 9 18:26:12 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 9 Sep 2020 14:26:12 -0400 Subject: [8u] RFR: 8252975: [8u] JDK-8252395 breaks the build for --with-native-debug-symbols=internal In-Reply-To: References: Message-ID: <693d409d-f304-9067-5211-121d6a0b283a@redhat.com> Verified, it fixed build. Looks good to me. Thanks for the quick fix. -Zhengyu On 9/9/20 2:16 PM, Severin Gehwolf wrote: > Hi, > > Please review this 8u (jdk8u/jdk8u-dev tree) fix for JDK-8252395 that > I've pushed today. Thanks for Zhengyu Gu for noticing it. The pushed > fix added the java.debuginfo and unpack.debuginfo make targets on the > condition of ENABLE_DEBUG_SYMBOLS=true, which is insufficient. It needs > another check on POST_STRIP_CMD which is set to non-empty for --with- > native-debug-symbols={external,zipped}, and is indeed empty for --with- > native-debug-symbols=internal. For the --with-native-debug-symbols=none > case we have ENABLE_DEBUG_SYMBOLS=false. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8252975 > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8252975/01/webrev/ > > Testing: Builds with --with-native-debug-symbols={none,internal,external,zipped} on Linux x86_64 > > OK? > > Thanks, > Severin > From zgu at redhat.com Wed Sep 9 18:35:01 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 9 Sep 2020 14:35:01 -0400 Subject: [8u] RFR 8245400: Upgrade to LittleCMS 2.11 Message-ID: <58d50501-2265-0747-8cb3-489906656e75@redhat.com> I would like to backport this patch to 8u for parity with Oracle 8u281. The original patch does not apply cleanly. Other than 8u using different files for third party licensing information, there are conflicts in comments with special characters, where hg does not seem to be able to handle (with/without git format). The original bug: https://bugs.openjdk.java.net/browse/JDK-8245400 The original patch: https://hg.openjdk.java.net/jdk/jdk/rev/5105eefa2bd9 8u webrev: main: http://cr.openjdk.java.net/~zgu/JDK-8245400-8u/main/webrev.00/ corba: http://cr.openjdk.java.net/~zgu/JDK-8245400-8u/corba/webrev.00/ hotspot: http://cr.openjdk.java.net/~zgu/JDK-8245400-8u/hotspot/webrev.00/ jaxp: http://cr.openjdk.java.net/~zgu/JDK-8245400-8u/jaxp/webrev.00/ jaxws: http://cr.openjdk.java.net/~zgu/JDK-8245400-8u/jaxws/webrev.00/ jdk: http://cr.openjdk.java.net/~zgu/JDK-8245400-8u/jdk/webrev.00/ langtools: http://cr.openjdk.java.net/~zgu/JDK-8245400-8u/langtools/webrev.00/ nashorn: http://cr.openjdk.java.net/~zgu/JDK-8245400-8u/corba/webrev.00/ Test: jdk_2d Thanks, -Zhengyu From hohensee at amazon.com Wed Sep 9 18:49:11 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 9 Sep 2020 18:49:11 +0000 Subject: RFA/RFA (M): 8231209: [REDO] JDK-8207266 ThreadMXBean::getThreadAllocatedBytes() can be quicker for self thread In-Reply-To: References: Message-ID: Passes: jdk/test/com/sun/management jdk/test/java/lang/management jdk/test/sun/management jdk/test/javax/management ?On 9/9/20, 10:59 AM, "jdk8u-dev on behalf of Hohensee, Paul" wrote: Please review this backport to 8u. It was not clean, and requires a CSR. Please review the CSR as well. The patch has been backported to both 11u and Oracle 11u. Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8231209 Original CSR: https://bugs.openjdk.java.net/browse/JDK-8231374 Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/c29e49148be7 Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8247811 Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8247812 Backport jdk webrev: http://cr.openjdk.java.net/~phh/8231209/webrev.8u.jdk.00/ Backport hotspot webrev: http://cr.openjdk.java.net/~phh/8231209/webrev.8u.hotspot.00/ These webrevs depend on a pending backport for JDK-8185003, see https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-September/012613.html, and if both are approved will be pushed after that backport. GetOneThreadAllocatedMemory, a new JMM interface method referenced in jmm.h, occupies the reserved2 jmmInterface slot rather than its original one, because otherwise the jmmInterface binary interface would not be compatible with 8u. There are minor changes to jmm_GetOneThreadAllocatedMemory in management.cpp to conform to 8u?s internal interfaces. HotspotThreadImpl.java doesn?t exist in 8u. It?s functionality (exposing c.s.m.ThreadMXBean protected methods as public) is replaced by simply declaring those methods public in ThreadImpl.java. The nsk tests don?t exist in 8u, so the updates to BaseBehaviorTest.* and ServerThreadMXBeanNew.java are dropped. A follow-on backport review request for https://bugs.openjdk.java.net/browse/JDK-8231968: getCurrentThreadAllocatedBytes default implementation s/b getThreadAllocatedBytes, will follow to fix a bug in the Original CSR. Thanks, Paul From hohensee at amazon.com Wed Sep 9 18:58:24 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 9 Sep 2020 18:58:24 +0000 Subject: RFR/RFA (S): 8231968: getCurrentThreadAllocatedBytes default implementation s/b getThreadAllocatedBytes Message-ID: <48FB8C63-E3A9-448D-A895-54DE6FC86CA7@amazon.com> Please review this backport to 8u and associated CSR. The backport is clean, but requires a CSR. It?s a follow-on fix (from tip) of the 8u backport of https://bugs.openjdk.java.net/browse/JDK-8231968: [REDO] JDK-8207266 ThreadMXBean::getThreadAllocatedBytes() can be quicker for self thread. Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8231968 Original CSR: https://bugs.openjdk.java.net/browse/JDK-8232072 Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/5bb426e9acc4 Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8247813 Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8247814 Backport webrev: http://cr.openjdk.java.net/~phh/8231968/webrev.8u.jdk.00/ Thanks, Paul From sgehwolf at redhat.com Thu Sep 10 08:02:35 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 10 Sep 2020 10:02:35 +0200 Subject: [8u] RFR: 8252975: [8u] JDK-8252395 breaks the build for --with-native-debug-symbols=internal In-Reply-To: <693d409d-f304-9067-5211-121d6a0b283a@redhat.com> References: <693d409d-f304-9067-5211-121d6a0b283a@redhat.com> Message-ID: On Wed, 2020-09-09 at 14:26 -0400, Zhengyu Gu wrote: > Verified, it fixed build. Looks good to me. > > Thanks for the quick fix. Thanks for the review! Cheers, Severin > -Zhengyu > > On 9/9/20 2:16 PM, Severin Gehwolf wrote: > > Hi, > > > > Please review this 8u (jdk8u/jdk8u-dev tree) fix for JDK-8252395 that > > I've pushed today. Thanks for Zhengyu Gu for noticing it. The pushed > > fix added the java.debuginfo and unpack.debuginfo make targets on the > > condition of ENABLE_DEBUG_SYMBOLS=true, which is insufficient. It needs > > another check on POST_STRIP_CMD which is set to non-empty for --with- > > native-debug-symbols={external,zipped}, and is indeed empty for --with- > > native-debug-symbols=internal. For the --with-native-debug-symbols=none > > case we have ENABLE_DEBUG_SYMBOLS=false. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8252975 > > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8252975/01/webrev/ > > > > Testing: Builds with --with-native-debug-symbols={none,internal,external,zipped} on Linux x86_64 > > > > OK? > > > > Thanks, > > Severin > > From adinn at redhat.com Thu Sep 10 09:53:07 2020 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 10 Sep 2020 10:53:07 +0100 Subject: [8u] RFR 8252904: VM crashes when JFR is used and JFR event class is transformed In-Reply-To: References: <8254effd-5ec6-867c-efc1-dc9e80cf6999@redhat.com> <3d186ed5-97e0-2b62-9a4f-a14bb2417c40@azul.com> <6d113b25-728d-22be-858d-61d4500347a4@azul.com> <41344ab4-14f5-d71f-b8b2-ff035505b159@redhat.com> Message-ID: <0523cc62-07eb-2ead-2af3-abb33afa6a8f@redhat.com> Hi Andrey, On 09/09/2020 19:00, Andrey Petushkov wrote: > added jtreg test https://cr.openjdk.java.net/~apetushkov/8252904.jdk/ > the test reliably fails on slowdebug VM without the bugfix and reliably > passes with a fix. note that the test will not reliably fail on a > product VM without fix, only occasionally Thanks very much. Great work! Reviewed. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From volker.simonis at gmail.com Thu Sep 10 11:44:08 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 10 Sep 2020 13:44:08 +0200 Subject: RFA/RFA (M): 8231209: [REDO] JDK-8207266 ThreadMXBean::getThreadAllocatedBytes() can be quicker for self thread In-Reply-To: References: Message-ID: Hi Paul, In general, the changes and the CSR look good to me. I've only found some minor differences with respect to the original change in the jdk part (see below). Best regards, Volker On Wed, Sep 9, 2020 at 7:58 PM Hohensee, Paul wrote: > > Please review this backport to 8u. It was not clean, and requires a CSR. Please review the CSR as well. The patch has been backported to both 11u and Oracle 11u. > > Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8231209 > Original CSR: https://bugs.openjdk.java.net/browse/JDK-8231374 > Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/c29e49148be7 > > Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8247811 > Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8247812 Reviewed. > Backport jdk webrev: http://cr.openjdk.java.net/~phh/8231209/webrev.8u.jdk.00/ com/sun/management/ThreadMXBean.java - the following hunk is missing: * The returned value is an approximation because some Java virtual machine * implementations may use object allocation mechanisms that result in a * delay between the time an object is allocated and the time its size is * recorded. *

- * If the thread of the specified ID is not alive or does not exist, + * If the thread with the specified ID is not alive or does not exist, * this method returns {@code -1}. If thread memory allocation measurement * is disabled, this method returns {@code -1}. * A thread is alive if it has been started and has not yet died. java/lang/management/ThreadMXBean.java - all the hunks which remove "java.lang." from the "@throws" tags in the JavaDoc are missing. sun/management/ThreadImpl.java - the following part of the second hunk is not part of the original change and isn't required in 8u either: import java.lang.management.ManagementFactory; - import java.lang.management.ThreadInfo; - +import java.lang.management.ThreadMXBean; import javax.management.ObjectName; > Backport hotspot webrev: http://cr.openjdk.java.net/~phh/8231209/webrev.8u.hotspot.00/ > Looks good. > These webrevs depend on a pending backport for JDK-8185003, see https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-September/012613.html, and if both are approved will be pushed after that backport. > > GetOneThreadAllocatedMemory, a new JMM interface method referenced in jmm.h, occupies the reserved2 jmmInterface slot rather than its original one, because otherwise the jmmInterface binary interface would not be compatible with 8u. > > There are minor changes to jmm_GetOneThreadAllocatedMemory in management.cpp to conform to 8u?s internal interfaces. > > HotspotThreadImpl.java doesn?t exist in 8u. It?s functionality (exposing c.s.m.ThreadMXBean protected methods as public) is replaced by simply declaring those methods public in ThreadImpl.java. > > The nsk tests don?t exist in 8u, so the updates to BaseBehaviorTest.* and ServerThreadMXBeanNew.java are dropped. > > A follow-on backport review request for https://bugs.openjdk.java.net/browse/JDK-8231968: getCurrentThreadAllocatedBytes default implementation s/b getThreadAllocatedBytes, will follow to fix a bug in the Original CSR. > > Thanks, > Paul > > From volker.simonis at gmail.com Thu Sep 10 11:47:41 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 10 Sep 2020 13:47:41 +0200 Subject: RFR/RFA (S): 8231968: getCurrentThreadAllocatedBytes default implementation s/b getThreadAllocatedBytes In-Reply-To: <48FB8C63-E3A9-448D-A895-54DE6FC86CA7@amazon.com> References: <48FB8C63-E3A9-448D-A895-54DE6FC86CA7@amazon.com> Message-ID: On Wed, Sep 9, 2020 at 8:58 PM Hohensee, Paul wrote: > > Please review this backport to 8u and associated CSR. The backport is clean, but requires a CSR. It?s a follow-on fix (from tip) of the 8u backport of https://bugs.openjdk.java.net/browse/JDK-8231968: [REDO] JDK-8207266 ThreadMXBean::getThreadAllocatedBytes() can be quicker for self thread. > > Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8231968 > Original CSR: https://bugs.openjdk.java.net/browse/JDK-8232072 > Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/5bb426e9acc4 > > Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8247813 > Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8247814 > Backport webrev: http://cr.openjdk.java.net/~phh/8231968/webrev.8u.jdk.00/ > Looks good to me. > Thanks, > Paul > > > From felix.yang at huawei.com Thu Sep 10 11:59:11 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Thu, 10 Sep 2020 11:59:11 +0000 Subject: RFR Backport 8179083: Uninitialized notifier in Java Monitor Wait tracing event Message-ID: Hi, Please review this one-line change of 8u. Original bug: https://bugs.openjdk.java.net/browse/JDK-8179083 Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/d5610f86423f The original patch does not apply cleanly to jdk8u-dev due to path difference. Webrev for 8u: http://cr.openjdk.java.net/~fyang/8179083-8u/webrev.00/ The following JFR test fails randomly on one of our aarch64 linux platform: $jtreg -othervm jdk/test/jdk/jfr/event/runtime/TestJavaMonitorWaitTimeOut.java When it fails, we have error messages: jdk.JavaMonitorWait { startTime = 10:02:30.341 duration = 10.064 ms monitorClass = jdk.jfr.event.runtime.TestJavaMonitorWaitTimeOut$Lock (classLoader = sun/misc/Launcher$AppClassLoader) notifier = "Finalizer" (javaThreadId = 3) timeout = 10.000 ms timedOut = true address = 0xFFFF380044E0 eventThread = "main" (javaThreadId = 1) } jdk.JavaMonitorWait { startTime = 10:02:30.352 duration = 64.700 us monitorClass = jdk.jfr.event.runtime.TestJavaMonitorWaitTimeOut$Lock (classLoader = sun/misc/Launcher$AppClassLoader) notifier = "Notifier" (javaThreadId = 15) timeout = 40.000 s timedOut = false address = 0xFFFF380044E0 eventThread = "main" (javaThreadId = 1) } jdk.JavaMonitorWait { startTime = 10:02:30.352 duration = 11.062 ms monitorClass = jdk.jfr.event.runtime.TestJavaMonitorWaitTimeOut$Lock (classLoader = sun/misc/Launcher$AppClassLoader) notifier = "Finalizer" (javaThreadId = 3) timeout = 11.000 ms timedOut = true address = 0xFFFF380044E0 eventThread = "main" (javaThreadId = 1) } Exception in thread "main" java.lang.RuntimeException: Invalid thread: expected Finalizer to equal null at jdk.test.lib.Asserts.fail(Asserts.java:594) at jdk.test.lib.Asserts.assertEquals(Asserts.java:205) at jdk.jfr.event.runtime.TestJavaMonitorWaitTimeOut.assertTimeOutEvent(TestJavaMonitorWaitTimeOut.java:119) at jdk.jfr.event.runtime.TestJavaMonitorWaitTimeOut.main(TestJavaMonitorWaitTimeOut.java:98) Here, the notifier field of the first and third item is not correct. "Finalizer" thread is not anticipated here. Performed full jtreg test with release builds both on aarch64-linux and x86_64-linux platforms. OK to backport? Thanks, Felix From sgehwolf at redhat.com Thu Sep 10 12:22:52 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 10 Sep 2020 14:22:52 +0200 Subject: [8u] RFC: 8172695: (scanner) java/util/Scanner/ScanTest.java fails In-Reply-To: References: Message-ID: <6e84276e97cf8df5e8e7b0e8a744649a5b666558.camel@redhat.com> Hi, Sorry, for being late on this. On Mon, 2020-05-25 at 20:48 +0100, Alex Kashchenko wrote: > Hi, > > I'd like to solicit comments and suggestions about the backport of > JDK-8172695 to 8u. > > Jira issue: https://bugs.openjdk.java.net/browse/JDK-8172695 diff stat for this is: $ hg diff -c c9865fee1a6d --stat test/jdk/java/util/Scanner/ScanTest.java | 30 ++++++++--------------- ------- 1 files changed, 8 insertions(+), 22 deletions(-) > There were a number of changes to ScanTest and to Scanner itself in 9+, > so to backport 8172695 cleanly the following issues need to be > backported as well: > > 8132206: move ScanTest.java into OpenJDK > 8132745: TEST_BUG: minor cleanup of java/util/Scanner/ScanTest.java These two bugs are already in jdk8u-dev now. > 8072722: add stream support to Scanner [excluding public API changes] > 8139414: java.util.Scanner hasNext() returns true, next() throws > NoSuchElementException > 8159545: closed/java/io/Console/TestConsole.java failed with exit code 1 > [not public, see: https://hg.openjdk.java.net/jdk/jdk/rev/e5d52546ba3a ] > 8166261: Scanner.nextInt(int) (and similar methods) throws > PatternSyntaxException > 8186157: (scanner) Modify java/util/Scanner/ScanTest.java to fail if > English Locale unavailable > > What would be the preferred way to bring this to 8u? Is it better to > backport these changes one by one, or just take 8172695 and modify it > for 8u? Should bugfixes to Scanner itself (8139414 and 8166261) be > backported in latter case? That's a way too long a bug tail for a simple test-only fix for a stable JDK release! So please could we not make the required test changes of 8172695 now without bringing in any more of these bugs? 8072722 is a major concern. Why bring in an enhancement to Scanner for a test-only backport? Thanks, Severin From mbalao at redhat.com Thu Sep 10 15:55:06 2020 From: mbalao at redhat.com (Martin Balao) Date: Thu, 10 Sep 2020 12:55:06 -0300 Subject: [8u] RFR 8252886: [TESTBUG] sun/security/ec/TestEC.java : Compilation failed In-Reply-To: <20200908155713.GC1846517@stopbrexit> References: <68E3FDEB-8400-45F4-920C-7866BA526A84@azul.com> <20200908155713.GC1846517@stopbrexit> Message-ID: Hi, On Tue, Sep 8, 2020 at 1:00 PM Andrew Hughes wrote: > > Please review a small fix for the jdk/test/sun/security/ec/TestEC.java regression test > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8252886 > > Webrev: http://cr.openjdk.java.net/~abakhtin/8252886/webrev.v0/ Looks good to me too. > > Ok, please flag with jdk8u-critical-request. > This is not really critical as only one test is broken. If you want to include it as critical (given that the risk is minimal), I'm okay. Thanks, Martin.- From hohensee at amazon.com Thu Sep 10 17:14:51 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 10 Sep 2020 17:14:51 +0000 Subject: RFA/RFA (M): 8231209: [REDO] JDK-8207266 ThreadMXBean::getThreadAllocatedBytes() can be quicker for self thread Message-ID: <50E4153C-2197-40C1-B874-F38FA6897BF6@amazon.com> Thanks for the quick review, Volker. New webrev with your issues addressed at http://cr.openjdk.java.net/~phh/8231209/webrev.8u.jdk.01/ Paul ?On 9/10/20, 4:45 AM, "Volker Simonis" wrote: Hi Paul, In general, the changes and the CSR look good to me. I've only found some minor differences with respect to the original change in the jdk part (see below). Best regards, Volker On Wed, Sep 9, 2020 at 7:58 PM Hohensee, Paul wrote: > > Please review this backport to 8u. It was not clean, and requires a CSR. Please review the CSR as well. The patch has been backported to both 11u and Oracle 11u. > > Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8231209 > Original CSR: https://bugs.openjdk.java.net/browse/JDK-8231374 > Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/c29e49148be7 > > Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8247811 > Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8247812 Reviewed. > Backport jdk webrev: http://cr.openjdk.java.net/~phh/8231209/webrev.8u.jdk.00/ com/sun/management/ThreadMXBean.java - the following hunk is missing: * The returned value is an approximation because some Java virtual machine * implementations may use object allocation mechanisms that result in a * delay between the time an object is allocated and the time its size is * recorded. *

- * If the thread of the specified ID is not alive or does not exist, + * If the thread with the specified ID is not alive or does not exist, * this method returns {@code -1}. If thread memory allocation measurement * is disabled, this method returns {@code -1}. * A thread is alive if it has been started and has not yet died. java/lang/management/ThreadMXBean.java - all the hunks which remove "java.lang." from the "@throws" tags in the JavaDoc are missing. sun/management/ThreadImpl.java - the following part of the second hunk is not part of the original change and isn't required in 8u either: import java.lang.management.ManagementFactory; - import java.lang.management.ThreadInfo; - +import java.lang.management.ThreadMXBean; import javax.management.ObjectName; > Backport hotspot webrev: http://cr.openjdk.java.net/~phh/8231209/webrev.8u.hotspot.00/ > Looks good. > These webrevs depend on a pending backport for JDK-8185003, see https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-September/012613.html, and if both are approved will be pushed after that backport. > > GetOneThreadAllocatedMemory, a new JMM interface method referenced in jmm.h, occupies the reserved2 jmmInterface slot rather than its original one, because otherwise the jmmInterface binary interface would not be compatible with 8u. > > There are minor changes to jmm_GetOneThreadAllocatedMemory in management.cpp to conform to 8u?s internal interfaces. > > HotspotThreadImpl.java doesn?t exist in 8u. It?s functionality (exposing c.s.m.ThreadMXBean protected methods as public) is replaced by simply declaring those methods public in ThreadImpl.java. > > The nsk tests don?t exist in 8u, so the updates to BaseBehaviorTest.* and ServerThreadMXBeanNew.java are dropped. > > A follow-on backport review request for https://bugs.openjdk.java.net/browse/JDK-8231968: getCurrentThreadAllocatedBytes default implementation s/b getThreadAllocatedBytes, will follow to fix a bug in the Original CSR. > > Thanks, > Paul > > From volker.simonis at gmail.com Fri Sep 11 10:11:35 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 11 Sep 2020 12:11:35 +0200 Subject: RFA/RFA (M): 8231209: [REDO] JDK-8207266 ThreadMXBean::getThreadAllocatedBytes() can be quicker for self thread In-Reply-To: <50E4153C-2197-40C1-B874-F38FA6897BF6@amazon.com> References: <50E4153C-2197-40C1-B874-F38FA6897BF6@amazon.com> Message-ID: On Thu, Sep 10, 2020 at 7:30 PM Hohensee, Paul wrote: > > Thanks for the quick review, Volker. New webrev with your issues addressed at > > http://cr.openjdk.java.net/~phh/8231209/webrev.8u.jdk.01/ > Thanks Paul, Looks good now! Best regards, Volker > Paul > > ?On 9/10/20, 4:45 AM, "Volker Simonis" wrote: > > Hi Paul, > > In general, the changes and the CSR look good to me. I've only found > some minor differences with respect to the original change in the jdk > part (see below). > > Best regards, > Volker > > On Wed, Sep 9, 2020 at 7:58 PM Hohensee, Paul wrote: > > > > Please review this backport to 8u. It was not clean, and requires a CSR. Please review the CSR as well. The patch has been backported to both 11u and Oracle 11u. > > > > Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8231209 > > Original CSR: https://bugs.openjdk.java.net/browse/JDK-8231374 > > Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/c29e49148be7 > > > > Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8247811 > > Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8247812 > > Reviewed. > > > Backport jdk webrev: http://cr.openjdk.java.net/~phh/8231209/webrev.8u.jdk.00/ > > com/sun/management/ThreadMXBean.java > - the following hunk is missing: > * The returned value is an approximation because some Java virtual machine > * implementations may use object allocation mechanisms that result in a > * delay between the time an object is allocated and the time its size is > * recorded. > *

> - * If the thread of the specified ID is not alive or does not exist, > + * If the thread with the specified ID is not alive or does not exist, > * this method returns {@code -1}. If thread memory allocation measurement > * is disabled, this method returns {@code -1}. > * A thread is alive if it has been started and has not yet died. > > java/lang/management/ThreadMXBean.java > - all the hunks which remove "java.lang." from the "@throws" tags in > the JavaDoc are missing. > > sun/management/ThreadImpl.java > - the following part of the second hunk is not part of the original > change and isn't required in 8u either: > import java.lang.management.ManagementFactory; > - > import java.lang.management.ThreadInfo; > - > +import java.lang.management.ThreadMXBean; > import javax.management.ObjectName; > > > Backport hotspot webrev: http://cr.openjdk.java.net/~phh/8231209/webrev.8u.hotspot.00/ > > > > Looks good. > > > These webrevs depend on a pending backport for JDK-8185003, see https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-September/012613.html, and if both are approved will be pushed after that backport. > > > > GetOneThreadAllocatedMemory, a new JMM interface method referenced in jmm.h, occupies the reserved2 jmmInterface slot rather than its original one, because otherwise the jmmInterface binary interface would not be compatible with 8u. > > > > There are minor changes to jmm_GetOneThreadAllocatedMemory in management.cpp to conform to 8u?s internal interfaces. > > > > HotspotThreadImpl.java doesn?t exist in 8u. It?s functionality (exposing c.s.m.ThreadMXBean protected methods as public) is replaced by simply declaring those methods public in ThreadImpl.java. > > > > The nsk tests don?t exist in 8u, so the updates to BaseBehaviorTest.* and ServerThreadMXBeanNew.java are dropped. > > > > A follow-on backport review request for https://bugs.openjdk.java.net/browse/JDK-8231968: getCurrentThreadAllocatedBytes default implementation s/b getThreadAllocatedBytes, will follow to fix a bug in the Original CSR. > > > > Thanks, > > Paul > > > > > From hohensee at amazon.com Fri Sep 11 13:40:42 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 11 Sep 2020 13:40:42 +0000 Subject: RFA/RFA (M): 8231209: [REDO] JDK-8207266 ThreadMXBean::getThreadAllocatedBytes() can be quicker for self thread In-Reply-To: References: <50E4153C-2197-40C1-B874-F38FA6897BF6@amazon.com> Message-ID: <98891540-55C4-49E2-94D3-C04D8FECE83F@amazon.com> Thanks, Volker. Once we have CSR approval I'll tag the issue (and 8231968 as well). Paul ?On 9/11/20, 3:12 AM, "Volker Simonis" wrote: CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. On Thu, Sep 10, 2020 at 7:30 PM Hohensee, Paul wrote: > > Thanks for the quick review, Volker. New webrev with your issues addressed at > > http://cr.openjdk.java.net/~phh/8231209/webrev.8u.jdk.01/ > Thanks Paul, Looks good now! Best regards, Volker > Paul > > On 9/10/20, 4:45 AM, "Volker Simonis" wrote: > > Hi Paul, > > In general, the changes and the CSR look good to me. I've only found > some minor differences with respect to the original change in the jdk > part (see below). > > Best regards, > Volker > > On Wed, Sep 9, 2020 at 7:58 PM Hohensee, Paul wrote: > > > > Please review this backport to 8u. It was not clean, and requires a CSR. Please review the CSR as well. The patch has been backported to both 11u and Oracle 11u. > > > > Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8231209 > > Original CSR: https://bugs.openjdk.java.net/browse/JDK-8231374 > > Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/c29e49148be7 > > > > Backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8247811 > > Backport CSR: https://bugs.openjdk.java.net/browse/JDK-8247812 > > Reviewed. > > > Backport jdk webrev: http://cr.openjdk.java.net/~phh/8231209/webrev.8u.jdk.00/ > > com/sun/management/ThreadMXBean.java > - the following hunk is missing: > * The returned value is an approximation because some Java virtual machine > * implementations may use object allocation mechanisms that result in a > * delay between the time an object is allocated and the time its size is > * recorded. > *

> - * If the thread of the specified ID is not alive or does not exist, > + * If the thread with the specified ID is not alive or does not exist, > * this method returns {@code -1}. If thread memory allocation measurement > * is disabled, this method returns {@code -1}. > * A thread is alive if it has been started and has not yet died. > > java/lang/management/ThreadMXBean.java > - all the hunks which remove "java.lang." from the "@throws" tags in > the JavaDoc are missing. > > sun/management/ThreadImpl.java > - the following part of the second hunk is not part of the original > change and isn't required in 8u either: > import java.lang.management.ManagementFactory; > - > import java.lang.management.ThreadInfo; > - > +import java.lang.management.ThreadMXBean; > import javax.management.ObjectName; > > > Backport hotspot webrev: http://cr.openjdk.java.net/~phh/8231209/webrev.8u.hotspot.00/ > > > > Looks good. > > > These webrevs depend on a pending backport for JDK-8185003, see https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-September/012613.html, and if both are approved will be pushed after that backport. > > > > GetOneThreadAllocatedMemory, a new JMM interface method referenced in jmm.h, occupies the reserved2 jmmInterface slot rather than its original one, because otherwise the jmmInterface binary interface would not be compatible with 8u. > > > > There are minor changes to jmm_GetOneThreadAllocatedMemory in management.cpp to conform to 8u?s internal interfaces. > > > > HotspotThreadImpl.java doesn?t exist in 8u. It?s functionality (exposing c.s.m.ThreadMXBean protected methods as public) is replaced by simply declaring those methods public in ThreadImpl.java. > > > > The nsk tests don?t exist in 8u, so the updates to BaseBehaviorTest.* and ServerThreadMXBeanNew.java are dropped. > > > > A follow-on backport review request for https://bugs.openjdk.java.net/browse/JDK-8231968: getCurrentThreadAllocatedBytes default implementation s/b getThreadAllocatedBytes, will follow to fix a bug in the Original CSR. > > > > Thanks, > > Paul > > > > > From christoph.langer at sap.com Mon Sep 14 11:47:13 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 14 Sep 2020 11:47:13 +0000 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider In-Reply-To: <20200902162001.GA1407872@stopbrexit> References: <4F5DB0BC-13AB-47C1-A6E3-6684BF66AA28@amazon.com> <10e87c8b-5f56-a973-c401-675dfd1a898c@redhat.com> <89966718-074e-0c91-5990-78f08c6cca34@gmx.net> <7c272c9c92233ec50ebd8e48a67d82a621e153ae.camel@redhat.com> <20200817052648.GA2640315@stopbrexit> <78a1c49794afdf13013a4c3d75efab50f4745870.camel@redhat.com> <20200820171607.GC3112706@stopbrexit> <20200902162001.GA1407872@stopbrexit> Message-ID: Hi Andrew, > > as for these @since 12 tags... > > > > While I understand that there are both, arguments pro and con, I'd like to > point out one specific thing in the context of this backport: > > Classes com.sun.jndi.ldap.spi. LdapDnsProvider and com.sun.jndi.ldap.spi. > LdapDnsProviderResult don't even exist in 12 and probably won't ever. In 12 > we have javax.naming.ldap.spi.LdapDnsProvider and > javax.naming.ldap.spi.LdapDnsProviderResult. So, given that change of > package location, I opt to remove the @since 12 tags which I'm proposing in > my webrev for 11u as well. > > > > Andrew, does that convice you or you still insist on the tags? > > > > Cheers > > Christoph > > > > Well, I wasn't aware that I was insisting on this; I don't think it's > a huge issue either way. > > I don't see a case for a general policy of removing these, because I > don't see a huge benefit to it. What is the case for removing them, > compared with the churn of creating further divergence and potentially > turning a clean backport into one that needs to be reviewed because "I > went and took out a dozen @since tags"? > > I'm aware that in this case, the packages are different (and have to be > for TCK compliance). To me, the @since is an indicator of why they > are different (this is API in 12, we had to shift it elsewhere in 8u). Thanks for getting back on this one. My answer comes late and post mortem, but I agree, one can do it either way ?? Cheers Christoph From jaroslav.bachorik at datadoghq.com Mon Sep 14 13:33:37 2020 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Mon, 14 Sep 2020 15:33:37 +0200 Subject: [8u] RFR 8250928: JFR: Improve hash algorithm for stack traces In-Reply-To: References: <8f1d51a2-de4c-35f6-dfe0-076496054aa1@redhat.com> <581363a3-2438-1601-7139-9e6cc68f0671@redhat.com> Message-ID: Gentle ping? On Fri, Sep 4, 2020 at 12:35 PM Jaroslav Bachor?k wrote: > > Now, when https://bugs.openjdk.java.net/browse/JDK-8252754 has been > fixed I think we can move on with this backport. > > Any objections? > > Cheers, > > -JB- > > On Tue, Sep 1, 2020 at 12:01 PM Aleksey Shipilev wrote: > > > > On 9/1/20 11:56 AM, Aleksey Shipilev wrote: > > > On 8/31/20 7:11 PM, Jaroslav Bachor?k wrote: > > >> Please, review this backport of a hash-collision reducing fix in JFR > > >> stacktrace values from the main line. > > >> > > >> JIRA: https://bugs.openjdk.java.net/browse/JDK-8250928 > > >> Webrev: http://cr.openjdk.java.net/~jbachorik/8250928/8u/webrev/ > > > > > > 8u backport looks fine. > > > > Oh wait, hold on a sec. > > > > The original changeset [1] only changes the bit in JfrStackTrace::record_safe. Why does this > > backport change JfrStackTrace::record_safe and JfrStackTrace::record_thread? > > > > -- > > Thanks, > > -Aleksey > > > > [1] > > https://hg.openjdk.java.net/jdk/jdk/file/c3cc9ac0ede2/src/hotspot/share/jfr/recorder/stacktrace/jfrStackTrace.cpp > > From sgehwolf at redhat.com Mon Sep 14 15:19:23 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 14 Sep 2020 17:19:23 +0200 Subject: [8u] RFR: 8252384: [TESTBUG] Some tests refer to COMPAT provider rather than JRE In-Reply-To: <20200828051215.GC1139317@stopbrexit> References: <20200827150606.bluinrxlprzpdoe2@qusp> <20200828051215.GC1139317@stopbrexit> Message-ID: <71ecf404d386932a87fe8eada162085453c22c31.camel@redhat.com> On Fri, 2020-08-28 at 06:12 +0100, Andrew Hughes wrote: > On 16:06 Thu 27 Aug , Jonathan Dowland wrote: > > Hello again, > > > > Please review the following webrev proposed for jdk8u. This fixes 6 > > backported tests which reference a locale provider name invalid under > > jdk8u. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8252384 > > Webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/jdowland/JDK-8252384/ > > > > > > Thanks, > > > > -- > > Jonathan Dowland > > > > This looks fine to me. > > Severin, if you flag this for approval on Jonathan's behalf, I'll > approve and push. I've added the flags. Thanks, Severin From snazarkin at azul.com Tue Sep 15 18:34:31 2020 From: snazarkin at azul.com (Sergey Nazarkin) Date: Tue, 15 Sep 2020 18:34:31 +0000 Subject: [8u] RFR: 8250636: iso8601_time returns incorrect offset part on MacOS Message-ID: <96C47B35-C6CC-4C5C-854F-147925366FD0@azul.com> Original Bug: https://bugs.openjdk.java.net/browse/JDK-8250636 Review: https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-July/040894.html Please review the backport of the fix for quite specific bug. The fix may be considered as ?too risky to fix? since changes behavior existed for years. It appears Java for BSD-like systems (OSX particularly) prints time in iso8601format (used at GC logs) incorrectly. Example of confused logs: Europe/Moscow (DST isn't in use) 2020-07-30T11:29:10.350+0300 # Linux 2020-07-30T11:29:10.350+0300 # Windows 2020-07-30T11:29:10.350-0300 # MacOS Europe/Berlin (DST is in use) 2020-07-30T10:29:10.350+0200 # Linux 2020-07-30T10:29:10.350+0200 # Windows 2020-07-30T10:29:10.350-0100 # MacOS The patch is not applied cleanly due to missed context and function signature change. Webrev: http://cr.openjdk.java.net/~snazarki/jdk8u-dev-webrev/8250636/ Unfortunately the change breaks AIX build and additional patch need to be applied: https://bugs.openjdk.java.net/browse/JDK-8251365 Will create new review if this backport is considered as accepted. /Sergey From gnu.andrew at redhat.com Wed Sep 16 06:27:19 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 16 Sep 2020 07:27:19 +0100 Subject: [8u] RFR: JDK-8253036: Support building the Zero assembler port on AArch64 Message-ID: <20200916062719.GA255398@stopbrexit> Bug: https://bugs.openjdk.java.net/browse/JDK-8253036 Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8253036/webrev.01/ This patch contains the minimal changes necessary for the Zero assembler port (--with-jvm-variants=zero) to build on AArch64. The changes are a subset of JDK-8064611, which also contains changes for the AArch64 port. I intend to follow this with a single patch to bring in the current state of the AArch64 port. This patch reduces the shared code changes in that upcoming patch and gives us a useful starting point of being able to build 8u on AArch64. Ok for 8u-dev? Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed Sep 16 06:46:03 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 16 Sep 2020 07:46:03 +0100 Subject: [8u] RFR: 8252384: [TESTBUG] Some tests refer to COMPAT provider rather than JRE In-Reply-To: <71ecf404d386932a87fe8eada162085453c22c31.camel@redhat.com> References: <20200827150606.bluinrxlprzpdoe2@qusp> <20200828051215.GC1139317@stopbrexit> <71ecf404d386932a87fe8eada162085453c22c31.camel@redhat.com> Message-ID: <20200916064603.GA256229@stopbrexit> On 17:19 Mon 14 Sep , Severin Gehwolf wrote: > On Fri, 2020-08-28 at 06:12 +0100, Andrew Hughes wrote: > > On 16:06 Thu 27 Aug , Jonathan Dowland wrote: > > > Hello again, > > > > > > Please review the following webrev proposed for jdk8u. This fixes 6 > > > backported tests which reference a locale provider name invalid under > > > jdk8u. > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8252384 > > > Webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/jdowland/JDK-8252384/ > > > > > > > > > Thanks, > > > > > > -- > > > Jonathan Dowland > > > > > > > This looks fine to me. > > > > Severin, if you flag this for approval on Jonathan's behalf, I'll > > approve and push. > > I've added the flags. > > Thanks, > Severin > Approved. Please make sure to add Jonathan in the Contributed-by field. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed Sep 16 06:49:44 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 16 Sep 2020 07:49:44 +0100 Subject: [8u] RFC: 8172695: (scanner) java/util/Scanner/ScanTest.java fails In-Reply-To: <6e84276e97cf8df5e8e7b0e8a744649a5b666558.camel@redhat.com> References: <6e84276e97cf8df5e8e7b0e8a744649a5b666558.camel@redhat.com> Message-ID: <20200916064944.GB256229@stopbrexit> On 14:22 Thu 10 Sep , Severin Gehwolf wrote: > Hi, > > Sorry, for being late on this. > I already replied along similar lines months ago: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-May/011819.html Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed Sep 16 06:53:52 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 16 Sep 2020 07:53:52 +0100 Subject: [8u] RFR 8245400: Upgrade to LittleCMS 2.11 In-Reply-To: <58d50501-2265-0747-8cb3-489906656e75@redhat.com> References: <58d50501-2265-0747-8cb3-489906656e75@redhat.com> Message-ID: <20200916065352.GC256229@stopbrexit> On 14:35 Wed 09 Sep , Zhengyu Gu wrote: > I would like to backport this patch to 8u for parity with Oracle 8u281. > > The original patch does not apply cleanly. Other than 8u using different > files for third party licensing information, there are conflicts in comments > with special characters, where hg does not seem to be able to handle > (with/without git format). > > The original bug: https://bugs.openjdk.java.net/browse/JDK-8245400 > The original patch: https://hg.openjdk.java.net/jdk/jdk/rev/5105eefa2bd9 > > 8u webrev: > main: http://cr.openjdk.java.net/~zgu/JDK-8245400-8u/main/webrev.00/ > corba: http://cr.openjdk.java.net/~zgu/JDK-8245400-8u/corba/webrev.00/ > hotspot: http://cr.openjdk.java.net/~zgu/JDK-8245400-8u/hotspot/webrev.00/ > jaxp: http://cr.openjdk.java.net/~zgu/JDK-8245400-8u/jaxp/webrev.00/ > jaxws: http://cr.openjdk.java.net/~zgu/JDK-8245400-8u/jaxws/webrev.00/ > jdk: http://cr.openjdk.java.net/~zgu/JDK-8245400-8u/jdk/webrev.00/ > langtools: > http://cr.openjdk.java.net/~zgu/JDK-8245400-8u/langtools/webrev.00/ > nashorn: http://cr.openjdk.java.net/~zgu/JDK-8245400-8u/corba/webrev.00/ > > Test: > jdk_2d > > Thanks, > > -Zhengyu > I was planning to backport this myself, but luckily just saw this mail. There's nothing to indicate on the bug that there is an RFR for 8u for this. Please add a link to the RFR and the jdk8u-needs-review label so others know the work is being done. I'll review the patch itself tomorrow. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From shade at redhat.com Wed Sep 16 09:55:26 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 16 Sep 2020 11:55:26 +0200 Subject: [8u] RFR 8250928: JFR: Improve hash algorithm for stack traces In-Reply-To: References: <8f1d51a2-de4c-35f6-dfe0-076496054aa1@redhat.com> <581363a3-2438-1601-7139-9e6cc68f0671@redhat.com> Message-ID: On 9/14/20 3:33 PM, Jaroslav Bachor?k wrote: > On Fri, Sep 4, 2020 at 12:35 PM Jaroslav Bachor?k > wrote: >> >> Now, when https://bugs.openjdk.java.net/browse/JDK-8252754 has been >> fixed I think we can move on with this backport. >> >> Any objections? I'd revert the parts that are not in the original JDK-8250928 -- that was a backporting mistake. Then both JDK-8250928 (this one) and JDK-8252754 (follow-up) should be pushed together. -- Thanks, -Aleksey From shade at redhat.com Wed Sep 16 10:22:51 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 16 Sep 2020 12:22:51 +0200 Subject: [8u] RFR: JDK-8253036: Support building the Zero assembler port on AArch64 In-Reply-To: <20200916062719.GA255398@stopbrexit> References: <20200916062719.GA255398@stopbrexit> Message-ID: On 9/16/20 8:27 AM, Andrew Hughes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8253036 > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8253036/webrev.01/ That's it, no more changes required for Zero? Would be nice to verify that thing is able to "make bootcycle-images" on native AArch64. -- Thanks, -Aleksey From zgu at redhat.com Wed Sep 16 11:47:35 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 16 Sep 2020 07:47:35 -0400 Subject: [8u] RFR 8245400: Upgrade to LittleCMS 2.11 In-Reply-To: <20200916065352.GC256229@stopbrexit> References: <58d50501-2265-0747-8cb3-489906656e75@redhat.com> <20200916065352.GC256229@stopbrexit> Message-ID: Hi Andrew, >> > > I was planning to backport this myself, but luckily just saw this mail. > There's nothing to indicate on the bug that there is an RFR for 8u for > this. Please add a link to the RFR and the jdk8u-needs-review label so > others know the work is being done. Done. I guess it stuck in between the tracking transition. I will go through my pending list, I think there are still a few not yet switched. Thanks, -Zhengyu > > I'll review the patch itself tomorrow. > > Thanks, > From andrew_m_leonard at uk.ibm.com Wed Sep 16 11:47:43 2020 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Wed, 16 Sep 2020 12:47:43 +0100 Subject: RFR backport: 8207766: [testbug] Adapt tests for Aix. Message-ID: Hi, Please can I request a review to backport 8207766: [testbug] Adapt tests for Aix.? https://bugs.openjdk.java.net/browse/JDK-8207766 The patch needs alterations, which I have done and tested here: http://cr.openjdk.java.net/~aleonard/8207766/webrev.00/ This enables the full set of com/sun/jdi to work on AIX. Many thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From felix.yang at huawei.com Wed Sep 16 11:58:02 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Wed, 16 Sep 2020 11:58:02 +0000 Subject: [8u] RFR: JDK-8253036: Support building the Zero assembler port on AArch64 In-Reply-To: References: <20200916062719.GA255398@stopbrexit> Message-ID: Hi, > -----Original Message----- > From: jdk8u-dev [mailto:jdk8u-dev-retn at openjdk.java.net] On Behalf Of > Aleksey Shipilev > Sent: Wednesday, September 16, 2020 6:23 PM > To: Andrew Hughes ; jdk8u- > dev at openjdk.java.net > Subject: Re: [8u] RFR: JDK-8253036: Support building the Zero assembler port > on AArch64 > > On 9/16/20 8:27 AM, Andrew Hughes wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8253036 > > Webrev: > https://cr.openjdk.java.net/~andrew/openjdk8/8253036/webrev.01/ > > That's it, no more changes required for Zero? > > Would be nice to verify that thing is able to "make bootcycle-images" on > native AArch64. I have just created a Zero build on my aarch64 server with the proposed patch by doing: make; make install I tried some trivial workloads and looks like this Zero build works. Also performed "make bootcycle-images" and Zero builds fine. I guess it might be better to incorporate the following change in the same file: #else #error Method os::dll_load requires that one of following is defined:\ - IA32, AMD64, IA64, __sparc, __powerpc__, ARM, S390, ALPHA, MIPS, MIPSEL, PARISC, M68K + IA32, AMD64, IA64, __sparc, __powerpc__, ARM, S390, ALPHA, MIPS, MIPSEL, PARISC, M68K, AARCH64 #endif Hope that helps. Thanks, Felix From martin.doerr at sap.com Wed Sep 16 12:44:59 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 16 Sep 2020 12:44:59 +0000 Subject: RFR backport: 8207766: [testbug] Adapt tests for Aix. In-Reply-To: References: Message-ID: Hi Andrew, looks good to me. Best regards, Martin > -----Original Message----- > From: jdk8u-dev On Behalf Of Andrew > Leonard > Sent: Mittwoch, 16. September 2020 13:48 > To: jdk8u-dev at openjdk.java.net > Subject: RFR backport: 8207766: [testbug] Adapt tests for Aix. > > Hi, > Please can I request a review to backport 8207766: [testbug] Adapt tests > for Aix.? > https://bugs.openjdk.java.net/browse/JDK-8207766 > The patch needs alterations, which I have done and tested here: > http://cr.openjdk.java.net/~aleonard/8207766/webrev.00/ > This enables the full set of com/sun/jdi to work on AIX. > Many thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: andrew_m_leonard at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU From andrew_m_leonard at uk.ibm.com Wed Sep 16 14:11:37 2020 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Wed, 16 Sep 2020 15:11:37 +0100 Subject: RFR backport: 8207766: [testbug] Adapt tests for Aix. In-Reply-To: References: Message-ID: Thanks Martin, I'm also after a "sponsor" as I am not a committer, so if yourself or anyone else is able to sponsor please? Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: "Doerr, Martin" To: Andrew Leonard , "jdk8u-dev at openjdk.java.net" Date: 16/09/2020 13:45 Subject: [EXTERNAL] RE: RFR backport: 8207766: [testbug] Adapt tests for Aix. Hi Andrew, looks good to me. Best regards, Martin > -----Original Message----- > From: jdk8u-dev On Behalf Of Andrew > Leonard > Sent: Mittwoch, 16. September 2020 13:48 > To: jdk8u-dev at openjdk.java.net > Subject: RFR backport: 8207766: [testbug] Adapt tests for Aix. > > Hi, > Please can I request a review to backport 8207766: [testbug] Adapt tests > for Aix.? > https://bugs.openjdk.java.net/browse/JDK-8207766 > The patch needs alterations, which I have done and tested here: > http://cr.openjdk.java.net/~aleonard/8207766/webrev.00/ > This enables the full set of com/sun/jdi to work on AIX. > Many thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: andrew_m_leonard at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From gnu.andrew at redhat.com Wed Sep 16 15:10:26 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 16 Sep 2020 16:10:26 +0100 Subject: [8u] RFR: JDK-8253036: Support building the Zero assembler port on AArch64 In-Reply-To: References: <20200916062719.GA255398@stopbrexit> Message-ID: <20200916151026.GA258227@stopbrexit> On 12:22 Wed 16 Sep , Aleksey Shipilev wrote: > On 9/16/20 8:27 AM, Andrew Hughes wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8253036 > > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8253036/webrev.01/ > > That's it, no more changes required for Zero? > I was surprised too. It seems some required configure/JDK changes got integrated into 8u already. > Would be nice to verify that thing is able to "make bootcycle-images" on native AArch64. > I successfully built the entire thing with this as a bootstrap JDK on native AArch64: checking openjdk-build os-cpu... linux-aarch64 checking openjdk-target os-cpu... linux-aarch64 ... checking for Boot JDK... /home/andrew/build/jdk8.zero checking Boot JDK version... openjdk version "1.8.0-internal" OpenJDK Runtime Environment (build 1.8.0-internal-andre_2020_08_28_18_22-b00) OpenJDK 64-Bit Zero VM (build 25.71-b00, interpreted mode) > -- > Thanks, > -Aleksey > Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed Sep 16 15:19:02 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 16 Sep 2020 16:19:02 +0100 Subject: [8u] RFR 8245400: Upgrade to LittleCMS 2.11 In-Reply-To: <58d50501-2265-0747-8cb3-489906656e75@redhat.com> References: <58d50501-2265-0747-8cb3-489906656e75@redhat.com> Message-ID: <20200916151902.GB258227@stopbrexit> On 14:35 Wed 09 Sep , Zhengyu Gu wrote: > I would like to backport this patch to 8u for parity with Oracle 8u281. > > The original patch does not apply cleanly. Other than 8u using different > files for third party licensing information, there are conflicts in comments > with special characters, where hg does not seem to be able to handle > (with/without git format). > > The original bug: https://bugs.openjdk.java.net/browse/JDK-8245400 > The original patch: https://hg.openjdk.java.net/jdk/jdk/rev/5105eefa2bd9 > > 8u webrev: > main: http://cr.openjdk.java.net/~zgu/JDK-8245400-8u/main/webrev.00/ > corba: http://cr.openjdk.java.net/~zgu/JDK-8245400-8u/corba/webrev.00/ > hotspot: http://cr.openjdk.java.net/~zgu/JDK-8245400-8u/hotspot/webrev.00/ > jaxp: http://cr.openjdk.java.net/~zgu/JDK-8245400-8u/jaxp/webrev.00/ > jaxws: http://cr.openjdk.java.net/~zgu/JDK-8245400-8u/jaxws/webrev.00/ > jdk: http://cr.openjdk.java.net/~zgu/JDK-8245400-8u/jdk/webrev.00/ > langtools: > http://cr.openjdk.java.net/~zgu/JDK-8245400-8u/langtools/webrev.00/ > nashorn: http://cr.openjdk.java.net/~zgu/JDK-8245400-8u/corba/webrev.00/ > > Test: > jdk_2d > > Thanks, > > -Zhengyu > I'm assuming the THIRD_PARTY_README change is the same in all files (just checked root & jdk) The only difference I see is there still seems to be one lingering non-ASCII character in cmsxform.c, whereas it was removed in the 11u version: 11u: - // Float transforms don't use cach\351, always are non-NULL + // Float transforms don't use cache, always are non-NULL 8u: - // Float transforms don't use cach\351, always are non-NULL + // Float transforms don't use cach\357\277\275, always are non-NULL so that one still needs correcting. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From shade at redhat.com Wed Sep 16 15:24:11 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 16 Sep 2020 17:24:11 +0200 Subject: [8u] RFR: JDK-8253036: Support building the Zero assembler port on AArch64 In-Reply-To: <20200916151026.GA258227@stopbrexit> References: <20200916062719.GA255398@stopbrexit> <20200916151026.GA258227@stopbrexit> Message-ID: <4bc5de0b-8ded-fe33-5ee0-aace46c26bac@redhat.com> On 9/16/20 5:10 PM, Andrew Hughes wrote: > On 12:22 Wed 16 Sep , Aleksey Shipilev wrote: >> On 9/16/20 8:27 AM, Andrew Hughes wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8253036 >>> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8253036/webrev.01/ >> >> That's it, no more changes required for Zero? > > I was surprised too. It seems some required configure/JDK changes got > integrated into 8u already. Okay, looks fine for me then! I have also ran bootcycle-images with this patch on AArch64 without problems. -- Thanks, -Aleksey From zgu at redhat.com Wed Sep 16 15:30:23 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 16 Sep 2020 11:30:23 -0400 Subject: [8u] RFR 8245400: Upgrade to LittleCMS 2.11 In-Reply-To: <20200916151902.GB258227@stopbrexit> References: <58d50501-2265-0747-8cb3-489906656e75@redhat.com> <20200916151902.GB258227@stopbrexit> Message-ID: <4882e20c-9eed-81c1-1b3e-60d7d1949606@redhat.com> Hi Andrew, >> > > I'm assuming the THIRD_PARTY_README change is the same in all files > (just checked root & jdk) Yep > > The only difference I see is there still seems to be one lingering > non-ASCII character in cmsxform.c, whereas it was removed in the 11u > version: > > 11u: > > - // Float transforms don't use cach\351, always are non-NULL > + // Float transforms don't use cache, always are non-NULL > > 8u: > > - // Float transforms don't use cach\351, always are non-NULL > + // Float transforms don't use cach\357\277\275, always are non-NULL > Corrected: http://cr.openjdk.java.net/~zgu/JDK-8245400-8u/jdk/webrev.01/ Thanks -Zhengyu > so that one still needs correcting. > > Thanks, > From gnu.andrew at redhat.com Wed Sep 16 15:32:11 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 16 Sep 2020 16:32:11 +0100 Subject: RFR backport: 8207766: [testbug] Adapt tests for Aix. In-Reply-To: References: Message-ID: <20200916153211.GC258227@stopbrexit> On 15:11 Wed 16 Sep , Andrew Leonard wrote: > Thanks Martin, > I'm also after a "sponsor" as I am not a committer, so if yourself or > anyone else is able to sponsor please? > Thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: andrew_m_leonard at uk.ibm.com > The bug needs to be flagged with jdk8u-fix-request and approved before commit. I can do the commit on your behalf once approved. With regard to the patch itself, it seems to be missing the change to jdk/test/sun/security/pkcs11/Secmod/TestNssDbSqlite.java. Was this intentional? The omission of jdk/test/tools/launcher/SourceMode.java makes sense as 8u does not have 8201274: Launch Single-File Source-Code Programs. The changes to use the 8u ProblemList format also look right. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed Sep 16 15:34:10 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 16 Sep 2020 16:34:10 +0100 Subject: [8u] RFR 8245400: Upgrade to LittleCMS 2.11 In-Reply-To: <4882e20c-9eed-81c1-1b3e-60d7d1949606@redhat.com> References: <58d50501-2265-0747-8cb3-489906656e75@redhat.com> <20200916151902.GB258227@stopbrexit> <4882e20c-9eed-81c1-1b3e-60d7d1949606@redhat.com> Message-ID: <20200916153410.GD258227@stopbrexit> On 11:30 Wed 16 Sep , Zhengyu Gu wrote: > Hi Andrew, > > > > > > > I'm assuming the THIRD_PARTY_README change is the same in all files > > (just checked root & jdk) > Yep > > > > > The only difference I see is there still seems to be one lingering > > non-ASCII character in cmsxform.c, whereas it was removed in the 11u > > version: > > > > 11u: > > > > - // Float transforms don't use cach\351, always are non-NULL > > + // Float transforms don't use cache, always are non-NULL > > > > 8u: > > > > - // Float transforms don't use cach\351, always are non-NULL > > + // Float transforms don't use cach\357\277\275, always are non-NULL > > > > Corrected: http://cr.openjdk.java.net/~zgu/JDK-8245400-8u/jdk/webrev.01/ > > Thanks > > -Zhengyu > > > so that one still needs correcting. > > > > Thanks, > > > Looks good. Please flag for approval. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed Sep 16 15:55:45 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 16 Sep 2020 16:55:45 +0100 Subject: [8u] RFR 8250665: Wrong translation for the month name of May in ar_JO,LB,SY In-Reply-To: References: Message-ID: <20200916155545.GE258227@stopbrexit> On 09:27 Wed 09 Sep , Zhengyu Gu wrote: > I would like to backport this patch to 8u for parity with Oracle 8u281. > > The original patch does not apply cleanly, but conflicts are limited on > copyright years and bug id lines of LocaleDataTest.java, can be easily > resolved manually. > > The original bug: https://bugs.openjdk.java.net/browse/JDK-8250665 > The original patch: https://hg.openjdk.java.net/jdk/jdk/rev/9aa999666ccc > > 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8250665-8u/webrev.00/ > > Test: > LocaleDataTest.java > > Thanks, > > -Zhengyu > Looks fine to me. Please flag for approval. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed Sep 16 17:37:56 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 16 Sep 2020 18:37:56 +0100 Subject: RFR: [8u] JDK-8225121 Set JDK_UPDATE_VERSION, JDK_BUILD_NUMBER and MILESTONE to correct values by default In-Reply-To: References: <71acfec6-6173-0a84-bcec-5dd20397682d@ubuntu.com> <22472e65-a958-1bfa-09df-6b20abe35ae3@redhat.com> Message-ID: <20200916173756.GJ258227@stopbrexit> Returning to this issue as it's still in my bug queue. On 03:33 Wed 12 Jun , Gil Tene wrote: > Wait, if I read this right, the proposed changes will: > A) make what used to default to ?-internal? now default to ?-ea? instead. > B) make what used to default to ?-internal? now default to nothing (i.e. fcs) in certain > (quarterly release) versions of the source. > > If so, I don?t see how this is a good thing. I think it will only serve to exacerbate the > sort of problem you are trying to solve. > > IMO "-internal" is much more appropriate and scary (in a good way) default tag than > "-ea" is for what people might randomly build against some random version of sources > 'that they got, using the latest version of glibc on their latest and greatest desktop setup. > > More importantly "-internal" is absolutely the appropriate tag for the thing that comes > out of me downloading the released sources and building them on my desktop today, > with my own hacked version of glibc and associated headers, using my private version > of gcc, with warnings and some annoying errors turned off for expediency. The result > of doing that (right now) shows 1.8.0-internal. That is as it should be. > But there's also nothing to stop you setting the milestone to fcs for that exact same setup. A build calling itself 1.8.0-internal, 1.8.0-ea or just 1.8.0 doesn't tell you anything about the system on which it was built. Indeed, this very issue arises because the tendency for downstream consumers who aren't familiar with the oddities of the OpenJDK build (and it is odd compared to many other FOSS projects) is to find some configuration that works and then leave it at that. There seems to be an expectation in this discussion that someone building OpenJDK is following development, uses source tree checkouts and knows what's a released version and what isn't. That isn't generally true. I still think it shouldn't be necessary for someone downloading a source release to tell the source release what it is. > I?m all for ways to make it more clear that the non-released stuff is EA (and should be > tagged as such if built to be shared with others), but I don't think we should break the > well established developer workflows and the existing safeguards against creating > unintentionally-tagged-as-something-consumable things in order to do so. > Then what do you suggest? I don't see how this breaks any workflow where the developer is already explicitly setting either ea or fcs. The very problem that this discussion arose from shows that these existing safeguards don't work. > IMO "fcs" should *never* show up as a milestone value in the checked-in version of > any files. Using it in a build should be an intentional act, meant to to put that milestone > on a build, in that specific build environment, and not something we encourage > happening "by accident" on every developer desktop around the world that happens > to download the sources. The thing being built from those sources on some random > setup may be very far from the thing you'd want to tag as "fcs" (and may fail many tests) > and there are many new failure scenarios and bad build leakage issues we will create > if we make this the default tag for builds from quarterly released sources? The fundamental disagreement here seems to be that you see what is being released as being a build. However, what we release is primarily source code which is then built by a variety of downstream consumers. By the logic expressed above, it seems we should not even be tagging the repositories with a GA version, because whether something is GA or not is determined not by the source code, but only by the source code in some "specific build environment". This seems to run counter to the very conception of a FOSS project where the release material is the source code. I'm not aware of glibc or gcc's final release status being determined by a build in a specific build environment and I don't think this should be true of OpenJDK either. > > We've had a working flow for a decade+ now, and many different good builds that use > that flow. It tags builds as dangerous by default. It relies on internal builds (and their build > environment) being stabilized, tested, and sanity checked before any "for external > consumption" tag is placed on the output of the "now we really mean it" build that we > produce in the same environment, and repeat the tests on. > > Let's not break that well established flow. > Again, there is nothing in the build to enforce such a workflow. The testing Oracle may do before declaring a release GA is different to the testing Red Hat may do, for example (and there are plenty of occasions when we have found GA builds with breakage) > If we want to *add* an additional, harder to remove "EA" tag (so that it will show both > -internal and the ea thing, and that even with an fcs milestone it will still show EA > unless it was removed (or was not there because the sources are form an actual > release), I'd be supportive. But taking off the belt and suspenders (removing the > default "-internal") and cutting a little into the break lines (making fcs default in > released source versions) because we think the drivers of these build scripts are > experienced enough to run with scissors is something that should be done only > after a lot of more sober introspection and sleeping on things. > This seems little more than derogratory to those who spend many hours building OpenJDK, so it is available for people to use, without them having to do so themselves. It is a simple fact that, with a FOSS project, someone can take the source code and do whatever they want with it. They can label it how they want. They can build it with whatever flags they choose. Indeed, that is freedom 1 of the four essential freedoms [0]. I would prefer that we encourage people with trust and help them to do the right thing out of the box, rather than assuming they are miscreants who needed to be forceably stopped from doing bad things. > ? Gil. > [0] https://www.gnu.org/philosophy/free-sw.html -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed Sep 16 17:47:16 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 16 Sep 2020 18:47:16 +0100 Subject: RFR: [8u] JDK-8225121 Set JDK_UPDATE_VERSION, JDK_BUILD_NUMBER and MILESTONE to correct values by default In-Reply-To: References: <71acfec6-6173-0a84-bcec-5dd20397682d@ubuntu.com> <22472e65-a958-1bfa-09df-6b20abe35ae3@redhat.com> Message-ID: <20200916174716.GK258227@stopbrexit> On 21:48 Tue 25 Jun , Langer, Christoph wrote: snip... > As for b): What's the way for a builder of an "official" binary to classify a GA build of an OpenJDK 8 update release? It is setting "MILESTONE" to "fcs". This will trigger the assembly of a release type version output. You can't then tell from looking at the binary's version output whether the source was really GA level, unless you compare update level and build number with the repository's GA tag. All presupposed, the right update version and build number values were given to the build. So, changing/maintaining default values for update version and build number won't stop anybody who is building a release from a premature source drop. I have an idea, though, on how to fix this. We could implement kind of a fuse which will hit in that case. We'd need to add a GA-MILESTONE indicator, e.g. in version-numbers, that will be set to no/false in the beginning of an update release cycle. Once the GA state is reached, this flag should be set to yes/true. In the build system we need to add logic that would bail out if somebody attempts to do an fcs build while GA-MILESTONE is no/false. It should only work when it's set to true. If we were to build from a mercurial repository, we could evaluate the tags and see if the "ga" tag for the current update level is present. For a source drop, however, a hard coded value in version-numbers would probably be the way to go. > > What do you think? > I don't really see how that's any different to setting MILESTONE=fcs when the GA milestone is reached, and back to ea afterwards. Why would a new flag be needed? We're currently setting MILESTONE=ea/fcs (depending on state) in downstream builds. For RHEL & Fedora, these changes need to be made in just shy of a dozen places, due to all the various active releases that carry OpenJDK 8. To my mind, that process is far more error-prone than just setting it correctly in the source code where it should be. But then, it is not for the builder to classify anything as GA or not. That is a decision for the person making the release. Either way, there is nothing to stop me taking a snapshot of 8u-dev today and building it as 8u292 with the fcs milestone. What we can do is help people who want to do the right thing by giving them sensible defaults in the source code that reflect what is already present in Mercurial tags and source tarball filenames. -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From andrew_m_leonard at uk.ibm.com Thu Sep 17 07:33:25 2020 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Thu, 17 Sep 2020 08:33:25 +0100 Subject: RFR backport: 8207766: [testbug] Adapt tests for Aix. In-Reply-To: <20200916153211.GC258227@stopbrexit> References: <20200916153211.GC258227@stopbrexit> Message-ID: Hi Andrew, I thought I had searched for TestNssDbSqlite.java and not found it in jdk8u, I was wrong!! that's why we have reviews! I'll update the webrev and return... Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: Andrew Hughes To: Andrew Leonard Cc: "Doerr, Martin" , "jdk8u-dev at openjdk.java.net" Date: 16/09/2020 16:32 Subject: [EXTERNAL] Re: RFR backport: 8207766: [testbug] Adapt tests for Aix. On 15:11 Wed 16 Sep , Andrew Leonard wrote: > Thanks Martin, > I'm also after a "sponsor" as I am not a committer, so if yourself or > anyone else is able to sponsor please? > Thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: andrew_m_leonard at uk.ibm.com > The bug needs to be flagged with jdk8u-fix-request and approved before commit. I can do the commit on your behalf once approved. With regard to the patch itself, it seems to be missing the change to jdk/test/sun/security/pkcs11/Secmod/TestNssDbSqlite.java. Was this intentional? The omission of jdk/test/tools/launcher/SourceMode.java makes sense as 8u does not have 8201274: Launch Single-File Source-Code Programs. The changes to use the 8u ProblemList format also look right. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 [attachment "signature.asc" deleted by Andrew Leonard/UK/IBM] Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From andrew_m_leonard at uk.ibm.com Thu Sep 17 08:58:54 2020 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Thu, 17 Sep 2020 09:58:54 +0100 Subject: RFR backport: 8207766: [testbug] Adapt tests for Aix. In-Reply-To: <20200916153211.GC258227@stopbrexit> References: <20200916153211.GC258227@stopbrexit> Message-ID: Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: Andrew Hughes To: Andrew Leonard Cc: "Doerr, Martin" , "jdk8u-dev at openjdk.java.net" Date: 16/09/2020 16:32 Subject: [EXTERNAL] Re: RFR backport: 8207766: [testbug] Adapt tests for Aix. On 15:11 Wed 16 Sep , Andrew Leonard wrote: > Thanks Martin, > I'm also after a "sponsor" as I am not a committer, so if yourself or > anyone else is able to sponsor please? > Thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: andrew_m_leonard at uk.ibm.com > The bug needs to be flagged with jdk8u-fix-request and approved before commit. I can do the commit on your behalf once approved. With regard to the patch itself, it seems to be missing the change to jdk/test/sun/security/pkcs11/Secmod/TestNssDbSqlite.java. Was this intentional? The omission of jdk/test/tools/launcher/SourceMode.java makes sense as 8u does not have 8201274: Launch Single-File Source-Code Programs. The changes to use the 8u ProblemList format also look right. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 [attachment "signature.asc" deleted by Andrew Leonard/UK/IBM] Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From andrew_m_leonard at uk.ibm.com Thu Sep 17 09:00:26 2020 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Thu, 17 Sep 2020 10:00:26 +0100 Subject: RFR backport: 8207766: [testbug] Adapt tests for Aix. In-Reply-To: <20200916153211.GC258227@stopbrexit> References: <20200916153211.GC258227@stopbrexit> Message-ID: Hi Andrew, I've updated the webrev with the TestNssDbSqlite.java change and re-tested, new webrev here: http://cr.openjdk.java.net/~aleonard/8207766/webrev.01 thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: Andrew Hughes To: Andrew Leonard Cc: "Doerr, Martin" , "jdk8u-dev at openjdk.java.net" Date: 16/09/2020 16:32 Subject: [EXTERNAL] Re: RFR backport: 8207766: [testbug] Adapt tests for Aix. On 15:11 Wed 16 Sep , Andrew Leonard wrote: > Thanks Martin, > I'm also after a "sponsor" as I am not a committer, so if yourself or > anyone else is able to sponsor please? > Thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: andrew_m_leonard at uk.ibm.com > The bug needs to be flagged with jdk8u-fix-request and approved before commit. I can do the commit on your behalf once approved. With regard to the patch itself, it seems to be missing the change to jdk/test/sun/security/pkcs11/Secmod/TestNssDbSqlite.java. Was this intentional? The omission of jdk/test/tools/launcher/SourceMode.java makes sense as 8u does not have 8201274: Launch Single-File Source-Code Programs. The changes to use the 8u ProblemList format also look right. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 [attachment "signature.asc" deleted by Andrew Leonard/UK/IBM] Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From aph at redhat.com Thu Sep 17 09:39:40 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 17 Sep 2020 10:39:40 +0100 Subject: [8u] RFR: JDK-8253036: Support building the Zero assembler port on AArch64 In-Reply-To: <4bc5de0b-8ded-fe33-5ee0-aace46c26bac@redhat.com> References: <20200916062719.GA255398@stopbrexit> <20200916151026.GA258227@stopbrexit> <4bc5de0b-8ded-fe33-5ee0-aace46c26bac@redhat.com> Message-ID: <2f57a269-769c-d330-bedf-23b987612f1b@redhat.com> On 16/09/2020 16:24, Aleksey Shipilev wrote: > On 9/16/20 5:10 PM, Andrew Hughes wrote: >> On 12:22 Wed 16 Sep , Aleksey Shipilev wrote: >>> On 9/16/20 8:27 AM, Andrew Hughes wrote: >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8253036 >>>> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8253036/webrev.01/ >>> >>> That's it, no more changes required for Zero? >> >> I was surprised too. It seems some required configure/JDK changes got >> integrated into 8u already. > > Okay, looks fine for me then! > > I have also ran bootcycle-images with this patch on AArch64 without problems. I wouldn't bet on the atomics being correct. It'd be nice to have a jcstress run. Not that we expect anyone to actually use zero on AArch64, but it'd be a very useful sanity check. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From martin.doerr at sap.com Thu Sep 17 09:40:38 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 17 Sep 2020 09:40:38 +0000 Subject: RFR backport: 8207766: [testbug] Adapt tests for Aix. In-Reply-To: References: <20200916153211.GC258227@stopbrexit> Message-ID: Hi Andrews ?? Good catch! I hadn?t noticed this test exists in 8u, either. New webrev looks good. When adding the jdk8u-fix-request, please also prefix your last comment with ?Fix Request?. (See http://openjdk.java.net/projects/jdk-updates/approval.html) Thanks and best regards, Martin From: Andrew Leonard Sent: Donnerstag, 17. September 2020 11:00 To: Andrew Hughes Cc: jdk8u-dev at openjdk.java.net; Doerr, Martin Subject: RE: RFR backport: 8207766: [testbug] Adapt tests for Aix. Hi Andrew, I've updated the webrev with the TestNssDbSqlite.java change and re-tested, new webrev here: http://cr.openjdk.java.net/~aleonard/8207766/webrev.01 thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: Andrew Hughes > To: Andrew Leonard > Cc: "Doerr, Martin" >, "jdk8u-dev at openjdk.java.net" > Date: 16/09/2020 16:32 Subject: [EXTERNAL] Re: RFR backport: 8207766: [testbug] Adapt tests for Aix. ________________________________ On 15:11 Wed 16 Sep , Andrew Leonard wrote: > Thanks Martin, > I'm also after a "sponsor" as I am not a committer, so if yourself or > anyone else is able to sponsor please? > Thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: andrew_m_leonard at uk.ibm.com > The bug needs to be flagged with jdk8u-fix-request and approved before commit. I can do the commit on your behalf once approved. With regard to the patch itself, it seems to be missing the change to jdk/test/sun/security/pkcs11/Secmod/TestNssDbSqlite.java. Was this intentional? The omission of jdk/test/tools/launcher/SourceMode.java makes sense as 8u does not have 8201274: Launch Single-File Source-Code Programs. The changes to use the 8u ProblemList format also look right. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 [attachment "signature.asc" deleted by Andrew Leonard/UK/IBM] Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From shade at redhat.com Thu Sep 17 10:20:23 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 17 Sep 2020 12:20:23 +0200 Subject: [8u] RFR: JDK-8253036: Support building the Zero assembler port on AArch64 In-Reply-To: <2f57a269-769c-d330-bedf-23b987612f1b@redhat.com> References: <20200916062719.GA255398@stopbrexit> <20200916151026.GA258227@stopbrexit> <4bc5de0b-8ded-fe33-5ee0-aace46c26bac@redhat.com> <2f57a269-769c-d330-bedf-23b987612f1b@redhat.com> Message-ID: On 9/17/20 11:39 AM, Andrew Haley wrote: > On 16/09/2020 16:24, Aleksey Shipilev wrote: > > On 9/16/20 5:10 PM, Andrew Hughes wrote: > >> On 12:22 Wed 16 Sep , Aleksey Shipilev wrote: > >>> On 9/16/20 8:27 AM, Andrew Hughes wrote: > >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8253036 > >>>> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8253036/webrev.01/ > >>> > >>> That's it, no more changes required for Zero? > >> > >> I was surprised too. It seems some required configure/JDK changes got > >> integrated into 8u already. > > > > Okay, looks fine for me then! > > > > I have also ran bootcycle-images with this patch on AArch64 without problems. > > I wouldn't bet on the atomics being correct. It'd be nice to have a > jcstress run. Not that we expect anyone to actually use zero on > AArch64, but it'd be a very useful sanity check. Oh. A few tests have failed: [FAILED] o.o.j.t.atomics.longs.AtomicLongPairwiseTests.IncAndGet_CAS [FAILED] o.o.j.t.memeffects.basic.volatiles.volatile_boolean_double [FAILED] o.o.j.t.memeffects.basic.volatiles.volatile_boolean_double [FAILED] o.o.j.t.memeffects.basic.volatiles.volatile_boolean_double [FAILED] o.o.j.t.memeffects.basic.volatiles.volatile_boolean_double [FAILED] o.o.j.t.memeffects.basic.volatiles.volatile_byte_double [FAILED] o.o.j.t.memeffects.basic.volatiles.volatile_byte_long [FAILED] o.o.j.t.memeffects.basic.volatiles.volatile_short_double [FAILED] o.o.j.t.memeffects.basic.volatiles.volatile_short_long [FAILED] o.o.j.t.memeffects.basic.volatiles.volatile_short_long The sample test that fails: @JCStressTest @Outcome(id = "0, 0", expect = Expect.ACCEPTABLE, desc = "Seeing default guard, can see any value") @Outcome(id = "0, 42", expect = Expect.ACCEPTABLE, desc = "Seeing default guard, can see any value") @Outcome(id = "42, 42", expect = Expect.ACCEPTABLE, desc = "Seeing set guard, seeing the updated value") @Outcome(id = "42, 0", expect = Expect.FORBIDDEN, desc = "Seeing set guard, not seeing the updated value") @State public class volatile_short_long { volatile short f; public long a; @Actor public void actor1(SJ_Result r) { a = 42L; f = 42; } @Actor public void actor2(SJ_Result r) { r.r1 = f; // observes 42 here r.r2 = a; // observes "0" here, FAIL } } -- Thanks, -Aleksey From shade at redhat.com Thu Sep 17 10:49:16 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 17 Sep 2020 12:49:16 +0200 Subject: [8u] RFR: JDK-8253036: Support building the Zero assembler port on AArch64 In-Reply-To: References: <20200916062719.GA255398@stopbrexit> <20200916151026.GA258227@stopbrexit> <4bc5de0b-8ded-fe33-5ee0-aace46c26bac@redhat.com> <2f57a269-769c-d330-bedf-23b987612f1b@redhat.com> Message-ID: <1450f40b-9a2a-fb8b-6f32-c3fac03dd155@redhat.com> On 9/17/20 12:20 PM, Aleksey Shipilev wrote: > On 9/17/20 11:39 AM, Andrew Haley wrote: >> On 16/09/2020 16:24, Aleksey Shipilev wrote: >> > On 9/16/20 5:10 PM, Andrew Hughes wrote: >> >> On 12:22 Wed 16 Sep , Aleksey Shipilev wrote: >> >>> On 9/16/20 8:27 AM, Andrew Hughes wrote: >> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8253036 >> >>>> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8253036/webrev.01/ >> >>> >> >>> That's it, no more changes required for Zero? >> >> >> >> I was surprised too. It seems some required configure/JDK changes got >> >> integrated into 8u already. >> > >> > Okay, looks fine for me then! >> > >> > I have also ran bootcycle-images with this patch on AArch64 without problems. >> >> I wouldn't bet on the atomics being correct. It'd be nice to have a >> jcstress run. Not that we expect anyone to actually use zero on >> AArch64, but it'd be a very useful sanity check. > > Oh. A few tests have failed: > > [FAILED] o.o.j.t.atomics.longs.AtomicLongPairwiseTests.IncAndGet_CAS > [FAILED] o.o.j.t.memeffects.basic.volatiles.volatile_boolean_double > [FAILED] o.o.j.t.memeffects.basic.volatiles.volatile_boolean_double > [FAILED] o.o.j.t.memeffects.basic.volatiles.volatile_boolean_double > [FAILED] o.o.j.t.memeffects.basic.volatiles.volatile_boolean_double > [FAILED] o.o.j.t.memeffects.basic.volatiles.volatile_byte_double > [FAILED] o.o.j.t.memeffects.basic.volatiles.volatile_byte_long > [FAILED] o.o.j.t.memeffects.basic.volatiles.volatile_short_double > [FAILED] o.o.j.t.memeffects.basic.volatiles.volatile_short_long > [FAILED] o.o.j.t.memeffects.basic.volatiles.volatile_short_long ...and I wonder if that is because src/os_cpu/linux_zero/vm/orderAccess_linux_zero.inline.hpp misses any mention of AArch64. Which (AFAICS) means OrderAccess barriers are reduced to compiler barriers. But hey, those definitions are missing even in the head JDK! -- Thanks, -Aleksey From shade at redhat.com Thu Sep 17 11:35:54 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 17 Sep 2020 13:35:54 +0200 Subject: [8u] RFR: JDK-8253036: Support building the Zero assembler port on AArch64 In-Reply-To: <1450f40b-9a2a-fb8b-6f32-c3fac03dd155@redhat.com> References: <20200916062719.GA255398@stopbrexit> <20200916151026.GA258227@stopbrexit> <4bc5de0b-8ded-fe33-5ee0-aace46c26bac@redhat.com> <2f57a269-769c-d330-bedf-23b987612f1b@redhat.com> <1450f40b-9a2a-fb8b-6f32-c3fac03dd155@redhat.com> Message-ID: <92a89915-f0e4-2b0e-18ad-7b232b9e7474@redhat.com> On 9/17/20 12:49 PM, Aleksey Shipilev wrote: > But hey, those definitions are missing even in the head JDK! Ha-ha. Oops. I have somewhat of the fix here: https://bugs.openjdk.java.net/browse/JDK-8253284 ...that would have to trickle in separately. -- Thanks, -Aleksey From aph at redhat.com Thu Sep 17 11:41:24 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 17 Sep 2020 12:41:24 +0100 Subject: [8u] RFR: JDK-8253036: Support building the Zero assembler port on AArch64 In-Reply-To: <92a89915-f0e4-2b0e-18ad-7b232b9e7474@redhat.com> References: <20200916062719.GA255398@stopbrexit> <20200916151026.GA258227@stopbrexit> <4bc5de0b-8ded-fe33-5ee0-aace46c26bac@redhat.com> <2f57a269-769c-d330-bedf-23b987612f1b@redhat.com> <1450f40b-9a2a-fb8b-6f32-c3fac03dd155@redhat.com> <92a89915-f0e4-2b0e-18ad-7b232b9e7474@redhat.com> Message-ID: <58624e80-215d-09a2-402a-af0e25494f1b@redhat.com> On 17/09/2020 12:35, Aleksey Shipilev wrote: > On 9/17/20 12:49 PM, Aleksey Shipilev wrote: >> But hey, those definitions are missing even in the head JDK! > > Ha-ha. Oops. I have somewhat of the fix here: > https://bugs.openjdk.java.net/browse/JDK-8253284 > > ...that would have to trickle in separately. OK. It doesn't seem right to me to enable AArch64/Zero in a update version if we know it's incorrect, and quite nastily so. But I don't mind if we can make sure that it gets fixed before it gets released. GCC has all the atomic builtins we need to get this right; I don't believe we need any platform-specific code at all. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From shade at redhat.com Thu Sep 17 13:04:32 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 17 Sep 2020 15:04:32 +0200 Subject: [8u] RFR: JDK-8253036: Support building the Zero assembler port on AArch64 In-Reply-To: <58624e80-215d-09a2-402a-af0e25494f1b@redhat.com> References: <20200916062719.GA255398@stopbrexit> <20200916151026.GA258227@stopbrexit> <4bc5de0b-8ded-fe33-5ee0-aace46c26bac@redhat.com> <2f57a269-769c-d330-bedf-23b987612f1b@redhat.com> <1450f40b-9a2a-fb8b-6f32-c3fac03dd155@redhat.com> <92a89915-f0e4-2b0e-18ad-7b232b9e7474@redhat.com> <58624e80-215d-09a2-402a-af0e25494f1b@redhat.com> Message-ID: On 9/17/20 1:41 PM, Andrew Haley wrote: > On 17/09/2020 12:35, Aleksey Shipilev wrote: > > On 9/17/20 12:49 PM, Aleksey Shipilev wrote: > >> But hey, those definitions are missing even in the head JDK! > > > > Ha-ha. Oops. I have somewhat of the fix here: > > https://bugs.openjdk.java.net/browse/JDK-8253284 > > > > ...that would have to trickle in separately. > > OK. It doesn't seem right to me to enable AArch64/Zero in a update > version if we know it's incorrect, and quite nastily so. But I don't > mind if we can make sure that it gets fixed before it gets released. > GCC has all the atomic builtins we need to get this right; I don't > believe we need any platform-specific code at all. Yeah, JDK-8253284 should trickle down as the usual backports until the Jan CPU. Reviews are appreciated there. I think (thankfully) that most distros ship the aarch64-port 8u bits in their aarch64 distributions, and therefore are not directly affected. -- Thanks, -Aleksey From gnu.andrew at redhat.com Fri Sep 18 01:58:47 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 18 Sep 2020 02:58:47 +0100 Subject: [8u] RFR: JDK-8253036: Support building the Zero assembler port on AArch64 In-Reply-To: References: <20200916062719.GA255398@stopbrexit> <20200916151026.GA258227@stopbrexit> <4bc5de0b-8ded-fe33-5ee0-aace46c26bac@redhat.com> <2f57a269-769c-d330-bedf-23b987612f1b@redhat.com> <1450f40b-9a2a-fb8b-6f32-c3fac03dd155@redhat.com> <92a89915-f0e4-2b0e-18ad-7b232b9e7474@redhat.com> <58624e80-215d-09a2-402a-af0e25494f1b@redhat.com> Message-ID: <20200918015847.GE297700@stopbrexit> On 15:04 Thu 17 Sep , Aleksey Shipilev wrote: > On 9/17/20 1:41 PM, Andrew Haley wrote: > > On 17/09/2020 12:35, Aleksey Shipilev wrote: > > > On 9/17/20 12:49 PM, Aleksey Shipilev wrote: > > >> But hey, those definitions are missing even in the head JDK! > > > > > > Ha-ha. Oops. I have somewhat of the fix here: > > > https://bugs.openjdk.java.net/browse/JDK-8253284 > > > > > > ...that would have to trickle in separately. > > > > OK. It doesn't seem right to me to enable AArch64/Zero in a update > > version if we know it's incorrect, and quite nastily so. But I don't > > mind if we can make sure that it gets fixed before it gets released. > > GCC has all the atomic builtins we need to get this right; I don't > > believe we need any platform-specific code at all. I don't see this as a blocker to this patch. It is an improvement on AArch64/Zero not building at all, a pre-requisite to getting the full AArch64 port into 8u and produces an AArch64/Zero which is the same as that on later JDKs. > > Yeah, JDK-8253284 should trickle down as the usual backports until the Jan > CPU. Reviews are appreciated there. I've taken a look, but it is quite a confusing patch with the cleanup. It's not helped by this new interface linking to five different patches. > > I think (thankfully) that most distros ship the aarch64-port 8u bits in > their aarch64 distributions, and therefore are not directly affected. Well, yes, the plan is to get that into 8u282 as well. The aim of this pre-requisite was to reduce the shared code changes in the AArch64 port patch. As I said before, I was expecting there to be more to this, including changes for other repos to recognise AArch64. > > -- > Thanks, > -Aleksey > Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Fri Sep 18 03:13:34 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 18 Sep 2020 04:13:34 +0100 Subject: RFR backport: 8207766: [testbug] Adapt tests for Aix. In-Reply-To: References: <20200916153211.GC258227@stopbrexit> Message-ID: <20200918031334.GF297700@stopbrexit> On 09:40 Thu 17 Sep , Doerr, Martin wrote: > Hi Andrews ?? > > Good catch! I hadn?t noticed this test exists in 8u, either. > New webrev looks good. > > When adding the jdk8u-fix-request, please also prefix your last comment with ?Fix Request?. > (See http://openjdk.java.net/projects/jdk-updates/approval.html) > > Thanks and best regards, > Martin > It's a very recent addition, 8u272-b06: https://bugs.openjdk.java.net/browse/JDK-8165996 > > From: Andrew Leonard > Sent: Donnerstag, 17. September 2020 11:00 > To: Andrew Hughes > Cc: jdk8u-dev at openjdk.java.net; Doerr, Martin > Subject: RE: RFR backport: 8207766: [testbug] Adapt tests for Aix. > > Hi Andrew, > I've updated the webrev with the TestNssDbSqlite.java change and re-tested, new webrev here: > http://cr.openjdk.java.net/~aleonard/8207766/webrev.01 > thanks > Andrew This looks fine to me too. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Fri Sep 18 03:21:31 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 18 Sep 2020 04:21:31 +0100 Subject: RFR backport: 8207766: [testbug] Adapt tests for Aix. In-Reply-To: References: <20200916153211.GC258227@stopbrexit> Message-ID: <20200918032131.GG297700@stopbrexit> On 10:00 Thu 17 Sep , Andrew Leonard wrote: > Hi Andrew, > I've updated the webrev with the TestNssDbSqlite.java change and > re-tested, new webrev here: > http://cr.openjdk.java.net/~aleonard/8207766/webrev.01 > thanks > Andrew > Approved and pushed: https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/46754d3706d8 Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Fri Sep 18 05:40:22 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 18 Sep 2020 06:40:22 +0100 Subject: [8u] RFR: 8252975: [8u] JDK-8252395 breaks the build for --with-native-debug-symbols=internal In-Reply-To: References: Message-ID: <20200918054022.GA353844@stopbrexit> On 20:16 Wed 09 Sep , Severin Gehwolf wrote: > Hi, > > Please review this 8u (jdk8u/jdk8u-dev tree) fix for JDK-8252395 that > I've pushed today. Thanks for Zhengyu Gu for noticing it. The pushed > fix added the java.debuginfo and unpack.debuginfo make targets on the > condition of ENABLE_DEBUG_SYMBOLS=true, which is insufficient. It needs > another check on POST_STRIP_CMD which is set to non-empty for --with- > native-debug-symbols={external,zipped}, and is indeed empty for --with- > native-debug-symbols=internal. For the --with-native-debug-symbols=none > case we have ENABLE_DEBUG_SYMBOLS=false. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8252975 > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8252975/01/webrev/ > > Testing: Builds with --with-native-debug-symbols={none,internal,external,zipped} on Linux x86_64 > > OK? > > Thanks, > Severin > Build is still broken for me with this patch: /usr/bin/cp /home/ahughes/builder/8u-dev/jdk/objs/java_objs/java.diz /home/ahughes/builder/8u-dev/jdk/bin/java.diz /usr/bin/cp: cannot stat '/home/ahughes/builder/8u-dev/jdk/objs/java_objs/java.diz': No such file or directory where --with-native-debug-symbols is not set (pre-JDK-8207324) The use of these two conditionals seems odd to me. What we want to know is whether zipped debuginfo is in use. This is not the same as debug symbols in general being enabled. Also, DEBUGINFO_EXT is only being set when ZIP_DEBUGINFO_FILES is true! POST_STRIP_CMD seems to only be used in image creation, so I don't think checking this is appropriate either. Instead, we should mirror what is done in make/common/NativeCompilation.gmk when creating the .diz files: -ifeq ($(ENABLE_DEBUG_SYMBOLS), true) - ifneq ($(POST_STRIP_CMD), ) +ifeq ($(ZIP_DEBUGINFO_FILES), true) + ifneq ($(STRIP_POLICY), no_strip) The second check is necessary because ZIP_DEBUGINFO_FILES is set by default, and so may be true even if STRIP_POLICY has been set to no_strip. The attached patch fixed the build for me. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 -------------- next part -------------- diff --git a/make/CompileLaunchers.gmk b/make/CompileLaunchers.gmk --- a/make/CompileLaunchers.gmk +++ b/make/CompileLaunchers.gmk @@ -247,8 +247,8 @@ $(CP) $(JDK_OUTPUTDIR)/objs/java_objs$(OUTPUT_SUBDIR)/java$(DEBUGINFO_EXT) $@ BUILD_LAUNCHERS += $(JDK_OUTPUTDIR)/bin$(OUTPUT_SUBDIR)/java$(EXE_SUFFIX) -ifeq ($(ENABLE_DEBUG_SYMBOLS), true) - ifneq ($(POST_STRIP_CMD), ) +ifeq ($(ZIP_DEBUGINFO_FILES), true) + ifneq ($(STRIP_POLICY), no_strip) BUILD_LAUNCHERS += $(JDK_OUTPUTDIR)/bin$(OUTPUT_SUBDIR)/java$(DEBUGINFO_EXT) endif endif @@ -557,8 +557,8 @@ $(call install-file) BUILD_LAUNCHERS += $(JDK_OUTPUTDIR)/bin$(OUTPUT_SUBDIR)/unpack200$(EXE_SUFFIX) -ifeq ($(ENABLE_DEBUG_SYMBOLS), true) - ifneq ($(POST_STRIP_CMD), ) +ifeq ($(ZIP_DEBUGINFO_FILES), true) + ifneq ($(STRIP_POLICY), no_strip) BUILD_LAUNCHERS += $(JDK_OUTPUTDIR)/bin$(OUTPUT_SUBDIR)/unpack200$(DEBUGINFO_EXT) endif endif From aph at redhat.com Fri Sep 18 08:28:29 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 18 Sep 2020 09:28:29 +0100 Subject: [8u] RFR: JDK-8253036: Support building the Zero assembler port on AArch64 In-Reply-To: <20200918015847.GE297700@stopbrexit> References: <20200916062719.GA255398@stopbrexit> <20200916151026.GA258227@stopbrexit> <4bc5de0b-8ded-fe33-5ee0-aace46c26bac@redhat.com> <2f57a269-769c-d330-bedf-23b987612f1b@redhat.com> <1450f40b-9a2a-fb8b-6f32-c3fac03dd155@redhat.com> <92a89915-f0e4-2b0e-18ad-7b232b9e7474@redhat.com> <58624e80-215d-09a2-402a-af0e25494f1b@redhat.com> <20200918015847.GE297700@stopbrexit> Message-ID: <3294c8a0-7b19-1810-f1cf-d99d3fe8a8cd@redhat.com> On 18/09/2020 02:58, Andrew Hughes wrote: > On 15:04 Thu 17 Sep , Aleksey Shipilev wrote: >> On 9/17/20 1:41 PM, Andrew Haley wrote: >>> On 17/09/2020 12:35, Aleksey Shipilev wrote: >>> > On 9/17/20 12:49 PM, Aleksey Shipilev wrote: >>> >> But hey, those definitions are missing even in the head JDK! >>> > >>> > Ha-ha. Oops. I have somewhat of the fix here: >>> > https://bugs.openjdk.java.net/browse/JDK-8253284 >>> > >>> > ...that would have to trickle in separately. >>> >>> OK. It doesn't seem right to me to enable AArch64/Zero in a update >>> version if we know it's incorrect, and quite nastily so. But I don't >>> mind if we can make sure that it gets fixed before it gets released. >>> GCC has all the atomic builtins we need to get this right; I don't >>> believe we need any platform-specific code at all. > > I don't see this as a blocker to this patch. It is an improvement on > AArch64/Zero not building at all, I disagree. But in practice it doesn't matter because 8253284 is in progress and will be backported soon. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From sgehwolf at redhat.com Fri Sep 18 09:22:10 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 18 Sep 2020 11:22:10 +0200 Subject: [8u] RFR: 8252975: [8u] JDK-8252395 breaks the build for --with-native-debug-symbols=internal In-Reply-To: <20200918054022.GA353844@stopbrexit> References: <20200918054022.GA353844@stopbrexit> Message-ID: Hi Andrew, On Fri, 2020-09-18 at 06:40 +0100, Andrew Hughes wrote: > On 20:16 Wed 09 Sep , Severin Gehwolf wrote: > > Hi, > > > > Please review this 8u (jdk8u/jdk8u-dev tree) fix for JDK-8252395 that > > I've pushed today. Thanks for Zhengyu Gu for noticing it. The pushed > > fix added the java.debuginfo and unpack.debuginfo make targets on the > > condition of ENABLE_DEBUG_SYMBOLS=true, which is insufficient. It needs > > another check on POST_STRIP_CMD which is set to non-empty for --with- > > native-debug-symbols={external,zipped}, and is indeed empty for --with- > > native-debug-symbols=internal. For the --with-native-debug-symbols=none > > case we have ENABLE_DEBUG_SYMBOLS=false. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8252975 > > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8252975/01/webrev/ > > > > Testing: Builds with --with-native-debug-symbols={none,internal,external,zipped} on Linux x86_64 > > > > OK? > > > > Thanks, > > Severin > > > > Build is still broken for me with this patch: > > /usr/bin/cp /home/ahughes/builder/8u-dev/jdk/objs/java_objs/java.diz /home/ahughes/builder/8u-dev/jdk/bin/java.diz > /usr/bin/cp: cannot stat '/home/ahughes/builder/8u-dev/jdk/objs/java_objs/java.diz': No such file or directory > > where --with-native-debug-symbols is not set (pre-JDK-8207324) Hmm, I'm not sure how you are building. I've checked builds with: $ bash configure \ --with-boot-jdk="/some/boot/jdk" \ --with-extra-cflags=-Wno-error \ --disable-zip-debug-info $ make images and $ bash configure \ --with-boot-jdk="/some/boot/jdk" \ --with-extra-cflags=-Wno-error $ make images and $ bash configure \ --with-boot-jdk="/some/boot/jdk" \ --with-extra-cflags=-Wno-error \ --disable-debug-symbols $ make images All seem to work fine for me. Are you sure you are not setting POST_STRIP_CMD or the like explicitly somewhere else. Please post the exact configure/make invocations you are using. FWIW, that bug you've referenced seems wrong: 8207324: aarch64 jtreg: assert in TestOptionsWithRanges.jtr You probably meant JDK-8036003: 8036003: Add --with-native-debug-symbols=[none|internal|external|zipped] > The use of these two conditionals seems odd to me. What we want to know > is whether zipped debuginfo is in use. No. We want to know whether or not external debug symbols (zipped or otherwise) are in use. > This is not the same as debug symbols > in general being enabled. Yes. Correctly so. > Also, DEBUGINFO_EXT is only being set when > ZIP_DEBUGINFO_FILES is true! How so? ifeq ($(ZIP_DEBUGINFO_FILES), true) DEBUGINFO_EXT := .diz else ifeq ($(OPENJDK_TARGET_OS), macosx) DEBUGINFO_EXT := .dSYM else ifeq ($(OPENJDK_TARGET_OS), windows) DEBUGINFO_EXT := .pdb else DEBUGINFO_EXT := .debuginfo endif On Linux with --with-native-debug-symbols=external this ends up with: DEBUGINFO_EXT := .debuginfo > POST_STRIP_CMD seems to only be used in image creation, so I don't > think checking this is appropriate either. Seems debatable. > Instead, we should mirror what is done in make/common/NativeCompilation.gmk when > creating the .diz files: > > -ifeq ($(ENABLE_DEBUG_SYMBOLS), true) > - ifneq ($(POST_STRIP_CMD), ) > +ifeq ($(ZIP_DEBUGINFO_FILES), true) > + ifneq ($(STRIP_POLICY), no_strip) > > The second check is necessary because ZIP_DEBUGINFO_FILES is set by default, > and so may be true even if STRIP_POLICY has been set to no_strip. Your patch won't work for --with-native-debug-symbols=external. In that case no *.debuginfo files for the java and unpack200 launchers would be created. With your patch: $ find build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/ | grep -E 'java\.debuginfo|unpack200\.debuginfo' Expected: $ find build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/ | grep -E 'java\.debuginfo|unpack200\.debuginfo' build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/java.debuginfo build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/unpack200.debuginfo > The attached patch fixed the build for me. Sorry, I don't seem to be able to reproduce your build failure. Thanks, Severin From jaroslav.bachorik at datadoghq.com Fri Sep 18 11:02:32 2020 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Fri, 18 Sep 2020 13:02:32 +0200 Subject: [8u] RFR 8252754: Hash code calculation of JfrStackTrace is inconsistent Message-ID: Please review this simple backport. The patch had to be adjusted for the fact that the stack trace hash code is calculated in jfrStackTraceRepository.cpp instead of the original jfrStackTrace.cpp. The hash code calculation logic remains the same, though. JIRA: https://bugs.openjdk.java.net/browse/JDK-8252754 Webrev: http://cr.openjdk.java.net/~jbachorik/8252754/8u/webrev/ Cheers, -JB- From jaroslav.bachorik at datadoghq.com Fri Sep 18 11:04:50 2020 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Fri, 18 Sep 2020 13:04:50 +0200 Subject: [8u] RFR 8250928: JFR: Improve hash algorithm for stack traces In-Reply-To: References: <8f1d51a2-de4c-35f6-dfe0-076496054aa1@redhat.com> <581363a3-2438-1601-7139-9e6cc68f0671@redhat.com> Message-ID: Done - http://cr.openjdk.java.net/~jbachorik/8250928/8u/01/webrev/ The followup backport of JDK-8252754 is being reviewed at https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-September/012714.html Cheers, -JB- On Wed, Sep 16, 2020 at 11:55 AM Aleksey Shipilev wrote: > > On 9/14/20 3:33 PM, Jaroslav Bachor?k wrote: > > On Fri, Sep 4, 2020 at 12:35 PM Jaroslav Bachor?k > > wrote: > >> > >> Now, when https://bugs.openjdk.java.net/browse/JDK-8252754 has been > >> fixed I think we can move on with this backport. > >> > >> Any objections? > I'd revert the parts that are not in the original JDK-8250928 -- that was a backporting mistake. > > Then both JDK-8250928 (this one) and JDK-8252754 (follow-up) should be pushed together. > > -- > Thanks, > -Aleksey > From shade at redhat.com Fri Sep 18 11:07:22 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 18 Sep 2020 13:07:22 +0200 Subject: [8u] RFR 8252754: Hash code calculation of JfrStackTrace is inconsistent In-Reply-To: References: Message-ID: On 9/18/20 1:02 PM, Jaroslav Bachor?k wrote: > Please review this simple backport. > > The patch had to be adjusted for the fact that the stack trace hash > code is calculated in jfrStackTraceRepository.cpp instead of the > original jfrStackTrace.cpp. The hash code calculation logic remains > the same, though. > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8252754 > Webrev: http://cr.openjdk.java.net/~jbachorik/8252754/8u/webrev/ Looks fine, thanks. -- -Aleksey From gnu.andrew at redhat.com Sat Sep 19 03:48:42 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Sat, 19 Sep 2020 04:48:42 +0100 Subject: No 8u Build Promotion for 2020-09-18 Message-ID: <20200919034842.GA403707@stopbrexit> I see no critical fixes (requested or approved) this week, so we'll skip the promotion. A reminder that a week today, 2020-09-25, is the freeze for 8u272. If there are any critical fixes next week, then that will be 8u272-b09 instead. Otherwise, 8u272-b08 will be the last public build promotion before GA. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Mon Sep 21 22:16:06 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 21 Sep 2020 23:16:06 +0100 Subject: [8u] RFR: JDK-8152545 Use preprocessor instead of compiling a program to generate native nio constants In-Reply-To: References: Message-ID: <20200921221606.GA477897@stopbrexit> On 13:06 Fri 28 Feb , Simon Tooke wrote: > Hello, > > I would like to request approval to backport of JDK-8152545 (Use > preprocessor instead of compiling a program to generate native nio > constants) to jdk8u for buildability reasons.? I've personally encountered > toolchains where the current solution doesn't build. > > I had to modify the original webrev to get rid of the SO_REUSEPORT > definition, as it isn't supported in JDK8. > > I've tested this on Windows and macos. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8152545 > > Original patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e2e318304252 > > Modified webrev: > http://cr.openjdk.java.net/~stooke/webrevs/jdk-8152545-jdk8/02/jdk.02 > > Thank you for your time, > > -Simon > > Looks good, other than this odd indentation + whitespace difference: - GENSRC_MISC += $(GENSRC_UC_FILE) + + GENSRC_JAVA_BASE += $(GENSRC_UC_FILE) Fixed version: https://cr.openjdk.java.net/~andrew/openjdk8/8152545/webrev.01/jdk.patch Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From aph at redhat.com Tue Sep 22 08:54:13 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 22 Sep 2020 09:54:13 +0100 Subject: [8u] RFR: JDK-8152545 Use preprocessor instead of compiling a program to generate native nio constants In-Reply-To: References: Message-ID: <925f4f49-31ea-bc90-579d-03277718c1b7@redhat.com> On 28/02/2020 18:06, Simon Tooke wrote: > Hello, > > I would like to request approval to backport of JDK-8152545 (Use > preprocessor instead of compiling a program to generate native nio > constants) to jdk8u for buildability reasons.? I've personally > encountered toolchains where the current solution doesn't build. > > I had to modify the original webrev to get rid of the SO_REUSEPORT > definition, as it isn't supported in JDK8. > > I've tested this on Windows and macos. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8152545 > > Original patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e2e318304252 > > Modified webrev: > http://cr.openjdk.java.net/~stooke/webrevs/jdk-8152545-jdk8/02/jdk.02 Why is this being backported? There's no explanation in the bug report and it doesn't seem to fit any of the usual criteria for a backport. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From stooke at redhat.com Tue Sep 22 18:32:20 2020 From: stooke at redhat.com (Simon Tooke) Date: Tue, 22 Sep 2020 14:32:20 -0400 Subject: [8u] RFR: JDK-8152545 Use preprocessor instead of compiling a program to generate native nio constants In-Reply-To: <925f4f49-31ea-bc90-579d-03277718c1b7@redhat.com> References: <925f4f49-31ea-bc90-579d-03277718c1b7@redhat.com> Message-ID: <5df3d7d3-db85-5587-c78c-e15fd586305b@redhat.com> On 2020-09-22 4:54 a.m., Andrew Haley wrote: > On 28/02/2020 18:06, Simon Tooke wrote: >> Hello, >> >> I would like to request approval to backport of JDK-8152545 (Use >> preprocessor instead of compiling a program to generate native nio >> constants) to jdk8u for buildability reasons.? I've personally >> encountered toolchains where the current solution doesn't build. >> >> I had to modify the original webrev to get rid of the SO_REUSEPORT >> definition, as it isn't supported in JDK8. >> >> I've tested this on Windows and macos. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8152545 >> >> Original patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e2e318304252 >> >> Modified webrev: >> http://cr.openjdk.java.net/~stooke/webrevs/jdk-8152545-jdk8/02/jdk.02 > Why is this being backported? There's no explanation in the bug report > and it doesn't seem to fit any of the usual criteria for a backport. > The fix removes the need to compile and run a program to get various runtime constants which are later compiled into the JDK. This is an impediment to cross-compiles, as the constants (some of which are admittedly specified by standards) are those of the host, not target platform.? So I think it's a good fix for that alone. In addition, I've run into issues in windows and macos builds that this will fix (see Aleksey Shipilev's comments).? At one time I needed this patch to get the 8u macos build going, but I can't confirm that is still the case due to other build issues. I completely understand if it is rejected; after all the original was priority P4. -Simon From gnu.andrew at redhat.com Tue Sep 22 19:21:00 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 22 Sep 2020 20:21:00 +0100 Subject: [8u] RFR: JDK-8152545 Use preprocessor instead of compiling a program to generate native nio constants In-Reply-To: <925f4f49-31ea-bc90-579d-03277718c1b7@redhat.com> References: <925f4f49-31ea-bc90-579d-03277718c1b7@redhat.com> Message-ID: <20200922192100.GA535691@stopbrexit> On 09:54 Tue 22 Sep , Andrew Haley wrote: > On 28/02/2020 18:06, Simon Tooke wrote: > > Hello, > > > > I would like to request approval to backport of JDK-8152545 (Use > > preprocessor instead of compiling a program to generate native nio > > constants) to jdk8u for buildability reasons.? I've personally > > encountered toolchains where the current solution doesn't build. > > > > I had to modify the original webrev to get rid of the SO_REUSEPORT > > definition, as it isn't supported in JDK8. > > > > I've tested this on Windows and macos. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8152545 > > > > Original patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e2e318304252 > > > > Modified webrev: > > http://cr.openjdk.java.net/~stooke/webrevs/jdk-8152545-jdk8/02/jdk.02 > > Why is this being backported? There's no explanation in the bug report > and it doesn't seem to fit any of the usual criteria for a backport. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > I see explanations for this in both this e-mail and in the comments on the bug report. There is also further detail in the comments of the linked bug, https://bugs.openjdk.java.net/browse/JDK-8072664 and there's also: https://bugs.openjdk.java.net/browse/JDK-8150529 Having to run a C program to generate the native constant files doesn't work when cross-compiling. Just running the preprocessor will work and is all that is needed. I think this is very low-risk (the post-patch output files can be compared against the pre-patch output files) and, as Aleksey says on the bug, avoids the need to try and hack around this when cross-compiling. The aarch64/shenandoah-jdk8u tree has been carrying this hack for JDK-8072664 since December 2013: --- jdk8/jdk/make/gensrc/GensrcMisc.gmk 2019-12-04 15:06:20.035798777 +0000 +++ shenandoah.8/jdk/make/gensrc/GensrcMisc.gmk 2019-12-04 15:29:56.300960990 +0000 @@ -76,7 +76,7 @@ INCLUDE_FILES := $(GENSRC_SOR_SRC_FILE), \ LANG := C, \ CC := $(BUILD_CC), \ - LDEXE := $(BUILD_LD), \ + LDEXE := $(BUILD_CC), \ OBJECT_DIR := $(GENSRC_SOR_BIN), \ OUTPUT_DIR := $(GENSRC_SOR_BIN), \ PROGRAM := genSocketOptionRegistry)) Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From alvdavi at amazon.com Tue Sep 22 23:48:04 2020 From: alvdavi at amazon.com (David Alvarez) Date: Tue, 22 Sep 2020 16:48:04 -0700 Subject: [1/5] RFR (L) 7092821: java.security.Provider.getService() is synchronized and became scalability bottleneck Message-ID: Hi, I've been working on a set of patches for 8u282. In total, there are 6 patches: * [1] 7092821: java.security.Provider.getService() is synchronized and became scalability bottleneck - [2] 8228613: java.security.Provider#getServices order is no longer deterministic - [3] 8246613: Choose the default SecureRandom algo based on registration ordering - [4] 8248505: Unexpected NoSuchAlgorithmException when using secure random impl from BCFIPS provider - [5] 8231387: java.security.Provider.getService returns random result due to race condition with mutating methods in the same class - [6] 8250787: Provider.put no longer registering aliases in FIPS env All these patches are related and should be pushed together. [1] to [5] are backports from tip. For [6] there is no equivalent on tip, but it is the same patch I have submitted for 11.0.9. Only one of them is a clean backport, [5], so the rest will be requiring RFRs. Given that [1] is fairly big, and that the rest don't really make sense without it, I will wait to send the rest until it gets approved. The patch changes how Provider.getService works. It also changes how all default services are registered to make use of putService instead of the old put, so there are plenty of changes. David -- [1] https://bugs.openjdk.java.net/browse/JDK-7092821 [2] https://bugs.openjdk.java.net/browse/JDK-8228613 [3] https://bugs.openjdk.java.net/browse/JDK-8246613 [4] https://bugs.openjdk.java.net/browse/JDK-8248505 [5] https://bugs.openjdk.java.net/browse/JDK-8231387 [6] https://bugs.openjdk.java.net/browse/JDK-8250787 From alvdavi at amazon.com Wed Sep 23 00:34:38 2020 From: alvdavi at amazon.com (David Alvarez) Date: Tue, 22 Sep 2020 17:34:38 -0700 Subject: [1/5] [8u] RFR (L) 7092821: java.security.Provider.getService() is synchronized and became scalability bottleneck In-Reply-To: References: Message-ID: <4692217f-e8c1-cd98-0bb9-f159395cfc37@amazon.com> Sorry, it seems I forgot the webrev link for the first patch: http://cr.openjdk.java.net/~alvdavi/webrevs/7092821/webrev.8u.jdk.00/ David On 2020-09-22 16:48, David Alvarez wrote: > Hi, > > I've been working on a set of patches for 8u282. In total, there are 6 > patches: > > * [1] 7092821: java.security.Provider.getService() is synchronized and > became scalability bottleneck > - [2] 8228613: java.security.Provider#getServices order is no longer > deterministic > - [3] 8246613: Choose the default SecureRandom algo based on > registration ordering > - [4] 8248505: Unexpected NoSuchAlgorithmException when using secure > random impl from BCFIPS provider > - [5] 8231387: java.security.Provider.getService returns random result > due to race condition with mutating methods in the same class > - [6] 8250787: Provider.put no longer registering aliases in FIPS env > > All these patches are related and should be pushed together. [1] to [5] > are backports from tip. For [6] there is no equivalent on tip, but it is > the same patch I have submitted for 11.0.9. Only one of them is a clean > backport, [5], so the rest will be requiring RFRs. Given that [1] is > fairly big, and that the rest don't really make sense without it, I will > wait to send the rest until it gets approved. > > The patch changes how Provider.getService works. It also changes how all > default services are registered to make use of putService instead of the > old put, so there are plenty of changes. > > David > -- > [1] https://bugs.openjdk.java.net/browse/JDK-7092821 > [2] https://bugs.openjdk.java.net/browse/JDK-8228613 > [3] https://bugs.openjdk.java.net/browse/JDK-8246613 > [4] https://bugs.openjdk.java.net/browse/JDK-8248505 > [5] https://bugs.openjdk.java.net/browse/JDK-8231387 > [6] https://bugs.openjdk.java.net/browse/JDK-8250787 > > From gnu.andrew at redhat.com Wed Sep 23 03:29:41 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 23 Sep 2020 04:29:41 +0100 Subject: [1/5] RFR (L) 7092821: java.security.Provider.getService() is synchronized and became scalability bottleneck In-Reply-To: References: Message-ID: <20200923032941.GB577314@stopbrexit> On 16:48 Tue 22 Sep , David Alvarez wrote: > Hi, > > I've been working on a set of patches for 8u282. In total, there are 6 > patches: > > * [1] 7092821: java.security.Provider.getService() is synchronized and > became scalability bottleneck > - [2] 8228613: java.security.Provider#getServices order is no longer > deterministic > - [3] 8246613: Choose the default SecureRandom algo based on registration > ordering > - [4] 8248505: Unexpected NoSuchAlgorithmException when using secure random > impl from BCFIPS provider > - [5] 8231387: java.security.Provider.getService returns random result due > to race condition with mutating methods in the same class > - [6] 8250787: Provider.put no longer registering aliases in FIPS env > > All these patches are related and should be pushed together. [1] to [5] are > backports from tip. For [6] there is no equivalent on tip, but it is the > same patch I have submitted for 11.0.9. Only one of them is a clean > backport, [5], so the rest will be requiring RFRs. Given that [1] is fairly > big, and that the rest don't really make sense without it, I will wait to > send the rest until it gets approved. > > The patch changes how Provider.getService works. It also changes how all > default services are registered to make use of putService instead of the old > put, so there are plenty of changes. > > David > -- > [1] https://bugs.openjdk.java.net/browse/JDK-7092821 > [2] https://bugs.openjdk.java.net/browse/JDK-8228613 > [3] https://bugs.openjdk.java.net/browse/JDK-8246613 > [4] https://bugs.openjdk.java.net/browse/JDK-8248505 > [5] https://bugs.openjdk.java.net/browse/JDK-8231387 > [6] https://bugs.openjdk.java.net/browse/JDK-8250787 > > I'm familiar with this from 11u. I think it's too risky for 8u. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From alvdavi at amazon.com Wed Sep 23 03:32:35 2020 From: alvdavi at amazon.com (David Alvarez) Date: Tue, 22 Sep 2020 20:32:35 -0700 Subject: [1/5] RFR (L) 7092821: java.security.Provider.getService() is synchronized and became scalability bottleneck In-Reply-To: <20200923032941.GB577314@stopbrexit> References: <20200923032941.GB577314@stopbrexit> Message-ID: I understand. This has been included into 8u271. Is the idea to wait or will this change be left out permanently of openjdk8u? David On 2020-09-22 20:29, Andrew Hughes wrote: > On 16:48 Tue 22 Sep , David Alvarez wrote: >> Hi, >> >> I've been working on a set of patches for 8u282. In total, there are 6 >> patches: >> >> * [1] 7092821: java.security.Provider.getService() is synchronized and >> became scalability bottleneck >> - [2] 8228613: java.security.Provider#getServices order is no longer >> deterministic >> - [3] 8246613: Choose the default SecureRandom algo based on registration >> ordering >> - [4] 8248505: Unexpected NoSuchAlgorithmException when using secure random >> impl from BCFIPS provider >> - [5] 8231387: java.security.Provider.getService returns random result due >> to race condition with mutating methods in the same class >> - [6] 8250787: Provider.put no longer registering aliases in FIPS env >> >> All these patches are related and should be pushed together. [1] to [5] are >> backports from tip. For [6] there is no equivalent on tip, but it is the >> same patch I have submitted for 11.0.9. Only one of them is a clean >> backport, [5], so the rest will be requiring RFRs. Given that [1] is fairly >> big, and that the rest don't really make sense without it, I will wait to >> send the rest until it gets approved. >> >> The patch changes how Provider.getService works. It also changes how all >> default services are registered to make use of putService instead of the old >> put, so there are plenty of changes. >> >> David >> -- >> [1] https://bugs.openjdk.java.net/browse/JDK-7092821 >> [2] https://bugs.openjdk.java.net/browse/JDK-8228613 >> [3] https://bugs.openjdk.java.net/browse/JDK-8246613 >> [4] https://bugs.openjdk.java.net/browse/JDK-8248505 >> [5] https://bugs.openjdk.java.net/browse/JDK-8231387 >> [6] https://bugs.openjdk.java.net/browse/JDK-8250787 >> >> > > I'm familiar with this from 11u. I think it's too risky for 8u. > > Thanks, > From gnu.andrew at redhat.com Wed Sep 23 03:39:09 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 23 Sep 2020 04:39:09 +0100 Subject: [8u] RFR: 8252975: [8u] JDK-8252395 breaks the build for --with-native-debug-symbols=internal In-Reply-To: References: <20200918054022.GA353844@stopbrexit> Message-ID: <20200923033909.GC577314@stopbrexit> On 11:22 Fri 18 Sep , Severin Gehwolf wrote: > Hi Andrew, > > > Build is still broken for me with this patch: > > > > /usr/bin/cp /home/ahughes/builder/8u-dev/jdk/objs/java_objs/java.diz /home/ahughes/builder/8u-dev/jdk/bin/java.diz > > /usr/bin/cp: cannot stat '/home/ahughes/builder/8u-dev/jdk/objs/java_objs/java.diz': No such file or directory > > > > where --with-native-debug-symbols is not set (pre-JDK-8207324) > > Hmm, I'm not sure how you are building. I've checked builds with: > > $ bash configure \ > --with-boot-jdk="/some/boot/jdk" \ > --with-extra-cflags=-Wno-error \ > --disable-zip-debug-info > $ make images > > and > > $ bash configure \ > --with-boot-jdk="/some/boot/jdk" \ > --with-extra-cflags=-Wno-error > $ make images > > and > > $ bash configure \ > --with-boot-jdk="/some/boot/jdk" \ > --with-extra-cflags=-Wno-error \ > --disable-debug-symbols > $ make images > > All seem to work fine for me. Are you sure you are not > setting POST_STRIP_CMD or the like explicitly somewhere else. Please > post the exact configure/make invocations you are using. > > FWIW, that bug you've referenced seems wrong: > 8207324: aarch64 jtreg: assert in TestOptionsWithRanges.jtr > > You probably meant JDK-8036003: > 8036003: Add --with-native-debug-symbols=[none|internal|external|zipped] No, JDK-8207234 (must have flipped the digits) as referenced in common/autoconf/jdk-options.m4. This is building with: $ make [...] STRIP_POLICY=no_strip > > > The use of these two conditionals seems odd to me. What we want to know > > is whether zipped debuginfo is in use. > > No. We want to know whether or not external debug symbols (zipped or > otherwise) are in use. > > > This is not the same as debug symbols > > in general being enabled. > > Yes. Correctly so. > > > Also, DEBUGINFO_EXT is only being set when > > ZIP_DEBUGINFO_FILES is true! > > How so? > > ifeq ($(ZIP_DEBUGINFO_FILES), true) > DEBUGINFO_EXT := .diz > else ifeq ($(OPENJDK_TARGET_OS), macosx) > DEBUGINFO_EXT := .dSYM > else ifeq ($(OPENJDK_TARGET_OS), windows) > DEBUGINFO_EXT := .pdb > else > DEBUGINFO_EXT := .debuginfo > endif > > On Linux with --with-native-debug-symbols=external this ends up with: > > DEBUGINFO_EXT := .debuginfo > Right, I misread this. Sorry for the confusion. It was late, and what should have been a simple merge led to an unexpected build failure from this. > > POST_STRIP_CMD seems to only be used in image creation, so I don't > > think checking this is appropriate either. > > Seems debatable. > I don't see how... $ grep -r 'POST_STRIP_CMD' make jdk/make/ jdk/make/Images.gmk:ifneq ($(POST_STRIP_CMD), ) jdk/make/Images.gmk: $(POST_STRIP_CMD) $< That's the only instance, other than in your patch. $ grep -r 'STRIP_POLICY' make jdk/make/ make/common/NativeCompilation.gmk: ifeq ($$($1_STRIP_POLICY),) make/common/NativeCompilation.gmk: $1_STRIP_POLICY:=$$(STRIP_POLICY) make/common/NativeCompilation.gmk: ifneq ($$($1_STRIP_POLICY), no_strip) make/common/NativeCompilation.gmk: ifneq ($$($1_STRIP_POLICY), no_strip) make/common/NativeCompilation.gmk: ifneq ($$($1_STRIP_POLICY), no_strip) make/common/NativeCompilation.gmk: ifneq ($$($1_STRIP_POLICY), no_strip) make/common/NativeCompilation.gmk: ifneq ($$($1_STRIP_POLICY), no_strip) TL;DR: we need a check on STRIP_POLICY in the conditional. It doesn't really matter whether this is in addition to POST_STRIP_CMD or not, but it's needed as STRIP_POLICY=no_strip alone worked before and now it doesn't. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed Sep 23 03:44:34 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 23 Sep 2020 04:44:34 +0100 Subject: [1/5] RFR (L) 7092821: java.security.Provider.getService() is synchronized and became scalability bottleneck In-Reply-To: References: <20200923032941.GB577314@stopbrexit> Message-ID: <20200923034434.GD577314@stopbrexit> On 20:32 Tue 22 Sep , David Alvarez wrote: > I understand. > > This has been included into 8u271. Is the idea to wait or will this change > be left out permanently of openjdk8u? > > David > I'm for leaving it out permanently unless there is a strong reason to put it in. JDK-8248505 was found late in the last 11u release cycle and we had to respin the release for it. Your mail suggests two further changes are needed since that. As you say, this patch makes changes to the provider system. As far as I'm aware, this is not a bug fix, but a performance enhancement, which then broke third-party providers. I don't think something like that should go into a stable release like 8u unless there is a very good reason. That the original fix first went into 12u, but issues were only hit much later when it was backported to 11u, suggests a general problem with changes in the new short term releases not being widely tested. We should keep that in mind for all future backports. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From alvdavi at amazon.com Wed Sep 23 05:03:20 2020 From: alvdavi at amazon.com (David Alvarez) Date: Tue, 22 Sep 2020 22:03:20 -0700 Subject: [1/5] RFR (L) 7092821: java.security.Provider.getService() is synchronized and became scalability bottleneck In-Reply-To: <20200923034434.GD577314@stopbrexit> References: <20200923032941.GB577314@stopbrexit> <20200923034434.GD577314@stopbrexit> Message-ID: <63a1338b-15fd-edf4-71d4-6af6972b0c3c@amazon.com> Hi Andrew, Makes sense. Let me know if the very good reason ever appears. Thanks, David On 2020-09-22 20:44, Andrew Hughes wrote: > On 20:32 Tue 22 Sep , David Alvarez wrote: >> I understand. >> >> This has been included into 8u271. Is the idea to wait or will this change >> be left out permanently of openjdk8u? >> >> David >> > > I'm for leaving it out permanently unless there is a strong reason to > put it in. JDK-8248505 was found late in the last 11u release cycle > and we had to respin the release for it. Your mail suggests two > further changes are needed since that. > > As you say, this patch makes changes to the provider system. As far as > I'm aware, this is not a bug fix, but a performance enhancement, which > then broke third-party providers. I don't think something like that > should go into a stable release like 8u unless there is a very good > reason. > > That the original fix first went into 12u, but issues were only hit > much later when it was backported to 11u, suggests a general problem > with changes in the new short term releases not being widely > tested. We should keep that in mind for all future backports. > > Thanks, > From aph at redhat.com Wed Sep 23 08:55:15 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 23 Sep 2020 09:55:15 +0100 Subject: [8u] RFR: JDK-8152545 Use preprocessor instead of compiling a program to generate native nio constants In-Reply-To: <20200922192100.GA535691@stopbrexit> References: <925f4f49-31ea-bc90-579d-03277718c1b7@redhat.com> <20200922192100.GA535691@stopbrexit> Message-ID: <8a5d32de-0e97-ba25-8863-be9319363cd8@redhat.com> On 22/09/2020 20:21, Andrew Hughes wrote: > On 09:54 Tue 22 Sep , Andrew Haley wrote: >> On 28/02/2020 18:06, Simon Tooke wrote: >>> Hello, >>> >>> I would like to request approval to backport of JDK-8152545 (Use >>> preprocessor instead of compiling a program to generate native nio >>> constants) to jdk8u for buildability reasons. I've personally >>> encountered toolchains where the current solution doesn't build. >>> >>> I had to modify the original webrev to get rid of the SO_REUSEPORT >>> definition, as it isn't supported in JDK8. >>> >>> I've tested this on Windows and macos. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152545 >>> >>> Original patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e2e318304252 >>> >>> Modified webrev: >>> http://cr.openjdk.java.net/~stooke/webrevs/jdk-8152545-jdk8/02/jdk.02 >> >> Why is this being backported? There's no explanation in the bug report >> and it doesn't seem to fit any of the usual criteria for a backport. > > I see explanations for this in both this e-mail and in the comments on > the bug report. There is also further detail in the comments of the > linked bug, Not really, no. JDK 8u is an old release and the build system has, in general, greatly improved since then. The obvious question to ask when someone suggests back-porting a buld fix from 2016 is "Why now?" And my suspicion was that there is no special reason to do it now. Hence the question. > https://bugs.openjdk.java.net/browse/JDK-8072664 > > and there's also: > > https://bugs.openjdk.java.net/browse/JDK-8150529 > > Having to run a C program to generate the native constant files doesn't > work when cross-compiling. Just running the preprocessor will work and > is all that is needed. Of course, yes. > I think this is very low-risk (the post-patch output files can be > compared against the pre-patch output files) and, as Aleksey says > on the bug, avoids the need to try and hack around this when > cross-compiling. That's the reason for the fix, I know. > The aarch64/shenandoah-jdk8u tree has been carrying this hack for > JDK-8072664 since December 2013: Understood. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Wed Sep 23 08:55:45 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 23 Sep 2020 09:55:45 +0100 Subject: [8u] RFR: JDK-8152545 Use preprocessor instead of compiling a program to generate native nio constants In-Reply-To: <5df3d7d3-db85-5587-c78c-e15fd586305b@redhat.com> References: <925f4f49-31ea-bc90-579d-03277718c1b7@redhat.com> <5df3d7d3-db85-5587-c78c-e15fd586305b@redhat.com> Message-ID: On 22/09/2020 19:32, Simon Tooke wrote: > > On 2020-09-22 4:54 a.m., Andrew Haley wrote: >> On 28/02/2020 18:06, Simon Tooke wrote: >>> Hello, >>> >>> I would like to request approval to backport of JDK-8152545 (Use >>> preprocessor instead of compiling a program to generate native nio >>> constants) to jdk8u for buildability reasons.? I've personally >>> encountered toolchains where the current solution doesn't build. >>> >>> I had to modify the original webrev to get rid of the SO_REUSEPORT >>> definition, as it isn't supported in JDK8. >>> >>> I've tested this on Windows and macos. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152545 >>> >>> Original patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e2e318304252 >>> >>> Modified webrev: >>> http://cr.openjdk.java.net/~stooke/webrevs/jdk-8152545-jdk8/02/jdk.02 >> Why is this being backported? There's no explanation in the bug report >> and it doesn't seem to fit any of the usual criteria for a backport. >> > The fix removes the need to compile and run a program to get various > runtime constants which are later compiled into the JDK. OK. > This is an impediment to cross-compiles, as the constants (some of which > are admittedly specified by standards) are those of the host, not target > platform.? So I think it's a good fix for that alone. Ah, right. > In addition, I've run into issues in windows and macos builds that this > will fix (see Aleksey Shipilev's comments).? At one time I needed this > patch to get the 8u macos build going, but I can't confirm that is still > the case due to other build issues. Fair enough. Thanks. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From akashche at redhat.com Wed Sep 23 11:40:33 2020 From: akashche at redhat.com (Alex Kashchenko) Date: Wed, 23 Sep 2020 12:40:33 +0100 Subject: [8u] RFA: 8132664: closed/javax/swing/DataTransfer/DefaultNoDrop/DefaultNoDrop.java locks on Windows Message-ID: Hi, Please approve the backport of JDK-8132664 to 8u-dev: Bug (not public): https://bugs.openjdk.java.net/browse/JDK-8132664 Original changeset: https://hg.openjdk.java.net/jdk/jdk/rev/9bc553d242eb The patch applies cleanly to 8u after changing paths, 8u changeset with original attribution: https://cr.openjdk.java.net/~akasko/jdk8u/8132664/8132664_8u.patch This patch is necessary for backporting the following fixes: 8232114: JVM crashed at imjpapi.dll in native code 8252470: java/awt/dnd/DisposeFrameOnDragCrash/DisposeFrameOnDragTest.java fails on Windows Testing: checked that it compiles with vs2010 and vs2017, ran jck:api/java_awt . -- -Alex From akashche at redhat.com Wed Sep 23 11:46:36 2020 From: akashche at redhat.com (Alex Kashchenko) Date: Wed, 23 Sep 2020 12:46:36 +0100 Subject: [8u] RFR: 8252470: java/awt/dnd/DisposeFrameOnDragCrash/DisposeFrameOnDragTest.java fails on Windows Message-ID: Hi, Please review the backport of JDK-8252470 to 8u-dev: Bug: https://bugs.openjdk.java.net/browse/JDK-8252470 Original changeset: https://hg.openjdk.java.net/jdk/jdk/rev/5870df313be1 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8252470/webrev.00/ Backport depends on: 8132664: closed/javax/swing/DataTransfer/DefaultNoDrop/DefaultNoDrop.java locks on Windows (not public, see: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-September/012731.html ) 8232114: JVM crashed at imjpapi.dll in native code After fixing paths, changes to awt_Toolkit.cpp apply cleanly. Comment-only change to DisposeFrameOnDragTest.java does not apply cleanly, because it depends on: 8198333: ProblemList should be updated for headless mode that seems to be problematic to backport. It is proposed to exclude changes to DisposeFrameOnDragTest.java from the backport. Testing: checked that it compiles with vs2010 and vs2017, ran jck:api/java_awt . PS: it is not clear whether this fix need to be brought to 15/13/11 first before proceeding with 8, please let me know if that is the case. -- -Alex From gnu.andrew at redhat.com Wed Sep 23 16:36:02 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 23 Sep 2020 17:36:02 +0100 Subject: [8u] RFR: JDK-8152545 Use preprocessor instead of compiling a program to generate native nio constants In-Reply-To: <8a5d32de-0e97-ba25-8863-be9319363cd8@redhat.com> References: <925f4f49-31ea-bc90-579d-03277718c1b7@redhat.com> <20200922192100.GA535691@stopbrexit> <8a5d32de-0e97-ba25-8863-be9319363cd8@redhat.com> Message-ID: <20200923163602.GA610675@stopbrexit> On 09:55 Wed 23 Sep , Andrew Haley wrote: > On 22/09/2020 20:21, Andrew Hughes wrote: > > On 09:54 Tue 22 Sep , Andrew Haley wrote: > >> On 28/02/2020 18:06, Simon Tooke wrote: > >>> Hello, > >>> > >>> I would like to request approval to backport of JDK-8152545 (Use > >>> preprocessor instead of compiling a program to generate native nio > >>> constants) to jdk8u for buildability reasons. I've personally > >>> encountered toolchains where the current solution doesn't build. > >>> > >>> I had to modify the original webrev to get rid of the SO_REUSEPORT > >>> definition, as it isn't supported in JDK8. > >>> > >>> I've tested this on Windows and macos. > >>> > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152545 > >>> > >>> Original patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e2e318304252 > >>> > >>> Modified webrev: > >>> http://cr.openjdk.java.net/~stooke/webrevs/jdk-8152545-jdk8/02/jdk.02 > >> > >> Why is this being backported? There's no explanation in the bug report > >> and it doesn't seem to fit any of the usual criteria for a backport. > > > > I see explanations for this in both this e-mail and in the comments on > > the bug report. There is also further detail in the comments of the > > linked bug, > > Not really, no. JDK 8u is an old release and the build system has, in > general, greatly improved since then. The obvious question to ask when > someone suggests back-porting a buld fix from 2016 is "Why now?" And > my suspicion was that there is no special reason to do it now. Hence > the question. > Ah ok. The situation here, as with a number of other fixes, is they have been fixed locally in various downstream repositories and build environments, but never in the upstream tree. I would prefer we try to minimise this divergence and get solutions to these issues upstream where possible. I suspect the reason these fixes weren't backported earlier is because it has not always been as easy as it is now to get fixes upstream. So, particulary with the older releases (6, 7 & 8), there is a legacy of fixes strewn around in various other places. Such fixes have often received much more testing in production environments than backports of newer fixes, by the sheer length of time they have been included in downstream packages. It's also possible that some bug fixes only become relevant as build environments change. Although the production build environment for legacy JDKs is likely to remain stable, the development build environment of those working on maintaining 8u is less so. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed Sep 23 16:40:42 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 23 Sep 2020 17:40:42 +0100 Subject: [8u] RFA: 8132664: closed/javax/swing/DataTransfer/DefaultNoDrop/DefaultNoDrop.java locks on Windows In-Reply-To: References: Message-ID: <20200923164042.GB610675@stopbrexit> On 12:40 Wed 23 Sep , Alex Kashchenko wrote: > Hi, > > Please approve the backport of JDK-8132664 to 8u-dev: > > Bug (not public): https://bugs.openjdk.java.net/browse/JDK-8132664 > > Original changeset: https://hg.openjdk.java.net/jdk/jdk/rev/9bc553d242eb > > The patch applies cleanly to 8u after changing paths, 8u changeset with > original attribution: > > https://cr.openjdk.java.net/~akasko/jdk8u/8132664/8132664_8u.patch > > > This patch is necessary for backporting the following fixes: > > 8232114: JVM crashed at imjpapi.dll in native code > 8252470: java/awt/dnd/DisposeFrameOnDragCrash/DisposeFrameOnDragTest.java > fails on Windows > > Testing: checked that it compiles with vs2010 and vs2017, ran > jck:api/java_awt . > > -- > -Alex > Approved. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed Sep 23 16:44:51 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 23 Sep 2020 17:44:51 +0100 Subject: [8u] RFR: 8252470: java/awt/dnd/DisposeFrameOnDragCrash/DisposeFrameOnDragTest.java fails on Windows In-Reply-To: References: Message-ID: <20200923164451.GC610675@stopbrexit> On 12:46 Wed 23 Sep , Alex Kashchenko wrote: > Hi, > > Please review the backport of JDK-8252470 to 8u-dev: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8252470 > > Original changeset: https://hg.openjdk.java.net/jdk/jdk/rev/5870df313be1 > > 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8252470/webrev.00/ > > > Backport depends on: > > 8132664: closed/javax/swing/DataTransfer/DefaultNoDrop/DefaultNoDrop.java > locks on Windows (not public, see: > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-September/012731.html > ) > 8232114: JVM crashed at imjpapi.dll in native code > > > After fixing paths, changes to awt_Toolkit.cpp apply cleanly. Comment-only > change to DisposeFrameOnDragTest.java does not apply cleanly, because it > depends on: > > 8198333: ProblemList should be updated for headless mode > > that seems to be problematic to backport. It is proposed to exclude changes > to DisposeFrameOnDragTest.java from the backport. > > Testing: checked that it compiles with vs2010 and vs2017, ran > jck:api/java_awt . > > > PS: it is not clear whether this fix need to be brought to 15/13/11 first > before proceeding with 8, please let me know if that is the case. > > -- > -Alex > 11u at least should be in process. Some of the same backporting issues may apply there, so it is better to resolve them in 11u and then base the 8u backport on 11u. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed Sep 23 17:32:38 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 23 Sep 2020 18:32:38 +0100 Subject: [8u] RFR: JDK-8253550: JDK-8252395 breaks the build for make STRIP_POLICY=no_strip Message-ID: <20200923173238.GA654782@stopbrexit> Bug: https://bugs.openjdk.java.net/browse/JDK-8253550 Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8253550/webrev.01/ JDK-8252395 broke the legacy way of disabling the stripping of debuginfo from builds with: $ make STRIP_POLICY=no_strip Adding a check on this value gets the build working again. Ok for 8u-dev? Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From aph at redhat.com Wed Sep 23 18:53:31 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 23 Sep 2020 19:53:31 +0100 Subject: [8u] RFR: JDK-8253550: JDK-8252395 breaks the build for make STRIP_POLICY=no_strip In-Reply-To: <20200923173238.GA654782@stopbrexit> References: <20200923173238.GA654782@stopbrexit> Message-ID: <544fbdca-9fd2-a5ea-e4a3-b53f28d8ac17@redhat.com> On 23/09/2020 18:32, Andrew Hughes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8253550 > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8253550/webrev.01/ > > JDK-8252395 broke the legacy way of disabling the stripping of > debuginfo from builds with: > > $ make STRIP_POLICY=no_strip > > Adding a check on this value gets the build working again. > > Ok for 8u-dev? OK, thanks. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From sgehwolf at redhat.com Thu Sep 24 07:50:06 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 24 Sep 2020 09:50:06 +0200 Subject: [8u] RFR: JDK-8253550: JDK-8252395 breaks the build for make STRIP_POLICY=no_strip In-Reply-To: <20200923173238.GA654782@stopbrexit> References: <20200923173238.GA654782@stopbrexit> Message-ID: <53a3aa6ae684382a977ed00502018b9393892776.camel@redhat.com> On Wed, 2020-09-23 at 18:32 +0100, Andrew Hughes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8253550 > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8253550/webrev.01/ > > JDK-8252395 broke the legacy way of disabling the stripping of > debuginfo from builds with: > > $ make STRIP_POLICY=no_strip Please update your build scripts to not use this any more. JDK-8207852 is in 8u since July 2018. For non-stripped debug symbols, configure option --with-native-debug-symbols=internal should be used instead. The same works as well for later JDKs. > Adding a check on this value gets the build working again. OK. Thanks, Severin From sgehwolf at redhat.com Thu Sep 24 09:30:57 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 24 Sep 2020 11:30:57 +0200 Subject: [8u] RFR: 8081547: Prepare client libs regression tests for running in a concurrent, headless jtreg environment Message-ID: <163c8b5a561084f250da8283beb1b4decd7aba7d.camel@redhat.com> Hi, Please review this 8u backport of test-only changes. The JDK 9 patch didn't apply cleanly, but were manually resolved. The only difference were context changes in the tests (@modules tag not present in JDK 8) which made them different enought for the patch to not apply. Bug: https://bugs.openjdk.java.net/browse/JDK-8081547 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8081547/01/webrev/ Testing: Affected tests on Linux x86_64 with/without -k:headful. Worked correctly after patch. Thanks, Severin From sgehwolf at redhat.com Thu Sep 24 09:39:50 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 24 Sep 2020 11:39:50 +0200 Subject: [8u] RFR(s): 8221342: [TESTBUG] Generate Dockerfile for docker testing In-Reply-To: <577f99d006f1e6808872c7f575baae15fca067a7.camel@redhat.com> References: <921a5acde361aa36cb840cc4ed4a9e3d1ecb29cc.camel@redhat.com> <20200826033840.GF969845@stopbrexit> <577f99d006f1e6808872c7f575baae15fca067a7.camel@redhat.com> Message-ID: <62631347fd194bafcb6858acdd5606a32302ded9.camel@redhat.com> On Mon, 2020-08-31 at 16:35 +0200, Severin Gehwolf wrote: > Hi Andrew, > > On Wed, 2020-08-26 at 04:38 +0100, Andrew Hughes wrote: > > On 15:05 Tue 25 Aug , Severin Gehwolf wrote: > > > Hi! > > > > > > Please review this 8u backport of this test bug which enhances > > > container testing to automatically generate docker files. This is > > > useful if the development platform is not Oracle Linux 7.X (which is > > > the case for me). > > > > > > The JDK 11 patch applies cleanly (after JDK-8220313 which is in the > > > approval queue) > > > > I don't see how this can be said to apply cleanly. Attempting to > > shuffle the patch fails to find a mapping for > > test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java and > > test/lib/jdk/test/lib/containers/docker/DockerfileConfig.java. > > > > It is also beyond the scope of a script to know to duplicate these > > changes between two repositories. So this alone justifies a review. > > OK. > > > This is beyond the scope of this patch, but the proposed patch > > for the JDK tests seems wrong. We seem to have duplication in the > > JDK test tree, caused by the JFR backport. > > Yes, I've noticed it. Question is whether this is worth fixing. Some > tests rely on test/lib/testlibrary/jdk/testlibrary some others > on test/lib/jdk/test/lib. > > > The jdk/test/lib/testlibrary/jdk/testlibrary/containers directory > > would be the correct location for these tests. The JFR backport seems > > to have started an alternate tree at jdk/test/lib/jdk/test/lib with > > duplication of some files in the former directory. This should be > > resolved in the 8u282 lifecycle. > > I'm not sure I agree but wouldn't object a patch which does this. It > seems a significant piece of work and would require some re-testing of > commonly run tests. Either way, this seems beyond the point of this > patch (as you said). > > > > but doesn't compile since Files.writeString() API is > > > not available in JDK 8. Replaced it with: > > > > > > byte[] bytes = dockerFileStr.getBytes(StandardCharsets.UTF_8); > > > Files.write(dockerfile, bytes); > > > > > > > Could this not be simplified to: > > > > Files.write(dockerfile, dockerFileStr.getBytes(StandardCharsets.UTF_8)); > > > > I don't see the need for the intermediate variable. > > Sure. Fixed: > https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8221342/jdk8/02/ > > > Other changes look fine. > > Thanks for the review! Ping? Thanks, Severin From akashche at redhat.com Thu Sep 24 12:23:53 2020 From: akashche at redhat.com (Alex Kashchenko) Date: Thu, 24 Sep 2020 13:23:53 +0100 Subject: [8u] RFA: 8132664: closed/javax/swing/DataTransfer/DefaultNoDrop/DefaultNoDrop.java locks on Windows In-Reply-To: <20200923164042.GB610675@stopbrexit> References: <20200923164042.GB610675@stopbrexit> Message-ID: On 09/23/2020 05:40 PM, Andrew Hughes wrote: > On 12:40 Wed 23 Sep , Alex Kashchenko wrote: >> Hi, >> >> Please approve the backport of JDK-8132664 to 8u-dev: >> >> Bug (not public): https://bugs.openjdk.java.net/browse/JDK-8132664 >> >> Original changeset: https://hg.openjdk.java.net/jdk/jdk/rev/9bc553d242eb >> >> The patch applies cleanly to 8u after changing paths, 8u changeset with >> original attribution: >> >> https://cr.openjdk.java.net/~akasko/jdk8u/8132664/8132664_8u.patch >> >> >> This patch is necessary for backporting the following fixes: >> >> 8232114: JVM crashed at imjpapi.dll in native code >> 8252470: java/awt/dnd/DisposeFrameOnDragCrash/DisposeFrameOnDragTest.java >> fails on Windows >> >> Testing: checked that it compiles with vs2010 and vs2017, ran >> jck:api/java_awt . >> >> -- >> -Alex >> > > Approved. Thanks! Pushed. -- -Alex From gnu.andrew at redhat.com Thu Sep 24 16:56:14 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 24 Sep 2020 17:56:14 +0100 Subject: [8u] RFR: JDK-8253550: JDK-8252395 breaks the build for make STRIP_POLICY=no_strip In-Reply-To: <544fbdca-9fd2-a5ea-e4a3-b53f28d8ac17@redhat.com> References: <20200923173238.GA654782@stopbrexit> <544fbdca-9fd2-a5ea-e4a3-b53f28d8ac17@redhat.com> Message-ID: <20200924165614.GA10752@stopbrexit> On 19:53 Wed 23 Sep , Andrew Haley wrote: > On 23/09/2020 18:32, Andrew Hughes wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8253550 > > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8253550/webrev.01/ > > > > JDK-8252395 broke the legacy way of disabling the stripping of > > debuginfo from builds with: > > > > $ make STRIP_POLICY=no_strip > > > > Adding a check on this value gets the build working again. > > > > Ok for 8u-dev? > > OK, thanks. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > Thanks, Andrew. I've added jdk8u-fix-request to the bug. -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Thu Sep 24 16:59:17 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 24 Sep 2020 17:59:17 +0100 Subject: [8u] RFR: JDK-8253550: JDK-8252395 breaks the build for make STRIP_POLICY=no_strip In-Reply-To: <53a3aa6ae684382a977ed00502018b9393892776.camel@redhat.com> References: <20200923173238.GA654782@stopbrexit> <53a3aa6ae684382a977ed00502018b9393892776.camel@redhat.com> Message-ID: <20200924165917.GB10752@stopbrexit> On 09:50 Thu 24 Sep , Severin Gehwolf wrote: > On Wed, 2020-09-23 at 18:32 +0100, Andrew Hughes wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8253550 > > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8253550/webrev.01/ > > > > JDK-8252395 broke the legacy way of disabling the stripping of > > debuginfo from builds with: > > > > $ make STRIP_POLICY=no_strip > > Please update your build scripts to not use this any more. JDK-8207852 > is in 8u since July 2018. For non-stripped debug symbols, configure > option --with-native-debug-symbols=internal should be used instead. The > same works as well for later JDKs. > No. I'm well aware of the new option. I retain the legacy build for 8u so as to catch breakage like this. It is clearly a regression if something that has worked for years is broken by a new patch. I don't think that's acceptable on a stable JDK. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Sat Sep 26 18:44:05 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Sat, 26 Sep 2020 19:44:05 +0100 Subject: [FREEZE] 8u272 NOW FROZEN Message-ID: <20200926184405.GA101799@stopbrexit> The release forest: https://hg.openjdk.java.net/jdk8u/jdk8u (and friends) is now frozen in preparation for release on 2020-10-20. As there were no further critical fixes this week, there will be no new build promotion and jdk8u272-b08 will be the final pre-release build. The final release tag will be no lower than jdk8u272-b09. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Mon Sep 28 04:42:06 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 28 Sep 2020 05:42:06 +0100 Subject: [FREEZE] 8u272 NOW FROZEN In-Reply-To: <20200926184405.GA101799@stopbrexit> References: <20200926184405.GA101799@stopbrexit> Message-ID: <20200928044206.GA188588@stopbrexit> On 19:44 Sat 26 Sep , Andrew Hughes wrote: > The release forest: > > https://hg.openjdk.java.net/jdk8u/jdk8u (and friends) > > is now frozen in preparation for release on 2020-10-20. > > As there were no further critical fixes this week, there > will be no new build promotion and jdk8u272-b08 will be > the final pre-release build. > > The final release tag will be no lower than jdk8u272-b09. > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > OpenJDK Package Owner > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 It seems there was a commit after b08: https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/77b682e2d679 so the final pre-release will be jdk8u272-b09, and the final release tag will be no lower than jdk8u272-b10. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From akashche at redhat.com Tue Sep 29 20:32:06 2020 From: akashche at redhat.com (Alex Kashchenko) Date: Tue, 29 Sep 2020 21:32:06 +0100 Subject: [8u] RFR: 8249183: JVM crash in "AwtFrame::WmSize" method Message-ID: Hi, Please review the backport of JDK-8249183 to 8u: Bug: https://bugs.openjdk.java.net/browse/JDK-8249183 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/9f529b04be26 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8249183/webrev.00/ Patch doesn't apply cleanly to 8u, besides paths changes, two hunks with import changes in WWindowPeer.java [1] are omitted. These imports were changed by JDK-8221823 [2], these changes to imports are not necessary in 8u because wildcard imports are used there in 8u. Original patch was added in 16, its backport was pushed to 15u and is currently waiting for approval for 11u (both applied cleanly). Testing: checked that "CrashOnMinimizingDialogTest.zip" test (attached to the issue) crashes on unpatched jdk and passes with the patch applied, ran jck:api/java_awt . [1] https://hg.openjdk.java.net/jdk/jdk/rev/9f529b04be26#l1.3 [2] https://hg.openjdk.java.net/jdk/jdk/rev/19adbbca4307#l1.16 -- -Alex From hedongbo at huawei.com Wed Sep 30 03:26:56 2020 From: hedongbo at huawei.com (hedongbo) Date: Wed, 30 Sep 2020 03:26:56 +0000 Subject: 8253752: jdk/test/sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh fails randomly Message-ID: <8FC616E5EC1A774287430B1CC2696FE30448FA49@dggeml533-mbs.china.huawei.com> Hi, Please review this 8u test-only changes. Bug: https://bugs.openjdk.java.net/browse/JDK-8253752 webrev: http://cr.openjdk.java.net/~dongbohe/8253752/webrev.00/ Testing: Worked correctly after patch. Thanks, dongbohe From akashche at redhat.com Wed Sep 30 11:13:37 2020 From: akashche at redhat.com (Alex Kashchenko) Date: Wed, 30 Sep 2020 12:13:37 +0100 Subject: [8u] RFR: 8139414: java.util.Scanner hasNext() returns true, next() throws NoSuchElementException Message-ID: Hi, Please review the backport of JDK-8139414 to 8u: Bug: https://bugs.openjdk.java.net/browse/JDK-8139414 jdk9 change: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/26cb3ae62fd3 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8139414/webrev.00/ This backport is a dependency of the JDK-8172695 (RFC thread [1]). It includes necessary parts of JDK-8072722 (RFR thread [2], rejected) and applies almost cleanly on top of it. The only change to original patch, besides paths, is the removal of two lines that reference "modCount" variable [3][4]. Testing: jtreg:java/util/Scanner , jck:api/java_util/Scanner . [1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-May/011789.html [2] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-June/011854.html [3] https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/26cb3ae62fd3#l1.86 [4] https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/26cb3ae62fd3#l1.98 -- -Alex From zgu at redhat.com Wed Sep 30 12:13:35 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 30 Sep 2020 08:13:35 -0400 Subject: 8253752: jdk/test/sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh fails randomly In-Reply-To: <8FC616E5EC1A774287430B1CC2696FE30448FA49@dggeml533-mbs.china.huawei.com> References: <8FC616E5EC1A774287430B1CC2696FE30448FA49@dggeml533-mbs.china.huawei.com> Message-ID: Looks good to me. -Zhengyu On 9/29/20 11:26 PM, hedongbo wrote: > Hi, > > Please review this 8u test-only changes. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8253752 > webrev: http://cr.openjdk.java.net/~dongbohe/8253752/webrev.00/ > > Testing: Worked correctly after patch. > > Thanks, > dongbohe > From sgehwolf at redhat.com Wed Sep 30 13:59:48 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 30 Sep 2020 15:59:48 +0200 Subject: 8253752: jdk/test/sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh fails randomly In-Reply-To: <8FC616E5EC1A774287430B1CC2696FE30448FA49@dggeml533-mbs.china.huawei.com> References: <8FC616E5EC1A774287430B1CC2696FE30448FA49@dggeml533-mbs.china.huawei.com> Message-ID: Hi, On Wed, 2020-09-30 at 03:26 +0000, hedongbo wrote: > Hi, > > Please review this 8u test-only changes. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8253752 > webrev: http://cr.openjdk.java.net/~dongbohe/8253752/webrev.00/ Looks fine. Note that this code got introduced with JDK-8027058 and fixed with JDK- 7195249 in jdk 9+. I'm OK with this point-fix for JDK 8u. Thanks, Severin