Re: VM shutdown upon X server termination
So if it returns and exit() is immediately called, how does that cause a
crash ?
It seems to be just the same as if the handler called exit() directly
and so did not return.
I would have thought a crash more likely if it didn't return and tried
to keep the program running,
which might be effectively what you temporarily do if you call JVM_Halt().
-phil.
On 6/7/21 11:21 AM, Maxim Kartashev wrote:
When the X server suddenly dies, Xlib would usually (or maybe always)
discover this as an I/O error. It will then call the function
installed with XSetIOErrorHandler() and expects that the function will
not return ("the called routine should not return" from
https://tronche.com/gui/x/xlib/event-handling/protocol-errors/XSetIOErrorHandler.html
).
If the handler returns, Xlib will simply call ::exit().
AWT installs awt_GraphicsEnv.c`xioerror_handler() as such a function
and it _does_ return. I was wondering if it would be prudent to
properly terminate VM from the handler (with JVM_Halt(), perhaps)? We
are getting many reports of JVM crashes on Linux that seem to be
connected with the sudden disappearance of the X server, but I wasn't
able to reproduce this so can't be sure that this is the issue we are
facing.
VM shutdown upon X server termination
When the X server suddenly dies, Xlib would usually (or maybe always)
discover this as an I/O error. It will then call the function installed
with XSetIOErrorHandler() and expects that the function will not return
("the called routine should not return" from
https://tronche.com/gui/x/xlib/event-handling/protocol-errors/XSetIOErrorHandler.html).
If the handler returns, Xlib will simply call ::exit().
AWT installs awt_GraphicsEnv.c`xioerror_handler() as such a function and it
_does_ return. I was wondering if it would be prudent to properly terminate
VM from the handler (with JVM_Halt(), perhaps)? We are getting many reports
of JVM crashes on Linux that seem to be connected with the sudden
disappearance of the X server, but I wasn't able to reproduce this so can't
be sure that this is the issue we are facing.
Re: RFR: 8267430: GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws AE: Unable to set display mode! [v3]
> There are two issues here, both macOS specific. > First the original reported one that occurs when running on a shared remote > VNC type desktop on macOS. > Only a single supported display mode is returned and it is also the current > mode. > A program that simply enumerates the reported modes and tries to set them, if > it reaches the native layer, > will fail because macOS reports the same display mode it returned as valid as > now being illegal. > It does not appear to be as simple as a user's permission level since it > occurs with an admin user as well > so it probably is the case that macOS simply does not allow this shared > desktop to be changed although > there's no docs I can find > Ordinarily we would not have tried this since we test if the requested > display mode is the same as the native > one and skip it, but the provided test used REFRESH_RATE_UNKNOWN which is > allowed as meaning match > any mode that satisfies W,H,BPP. But this caused it to fail the equals test > so the code is enhanced to check for that > > Second, when creating a test it was discovered that *at least* on the > built-in retina display of a 16" macbook pro, > the system default contig is never in the list of available modes and can be > discovered only by querying the *current* mode > before any modes are changed. This beheaviour is 100% consistent no matter if > the system was just rebooted, has > an external monitor attached as well, or not, activates the discrete card, or > not. > > Since we've had code since at least 2013 that added the default mode I > suspect this has been seen before but nowhere > can I find an explanation. > > It has odd consequences like after you change the display mode, you will no > longer see the default display mode reported, > so the list of available modes is reduced by one. > But for a typical use case which doesn't re-query or more typically caches > the original display mode in order to restore it, it presents a bigger > problem that trying to restore will always fail. > > So the other thing this fix does is detect when we fail to restore the > initial mode and try again in a different way. > Only if that fails do we then throw an exception. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8267430: GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws IAE: Unable to set display mode - Changes: - all: https://git.openjdk.java.net/jdk/pull/4373/files - new: https://git.openjdk.java.net/jdk/pull/4373/files/d93be8fa..3a496412 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4373&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4373&range=01-02 Stats: 18 lines in 1 file changed: 17 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4373.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4373/head:pull/4373 PR: https://git.openjdk.java.net/jdk/pull/4373
Re: RFR: 8267430: GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws AE: Unable to set display mode! [v2]
On Mon, 7 Jun 2021 19:45:49 GMT, Sergey Bylokhov wrote:
>> Phil Race has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8267430: GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws IAE:
>> Unable to set display mode
>
> src/java.desktop/macosx/classes/sun/awt/CGraphicsDevice.java line 72:
>
>> 70: public CGraphicsDevice(final int displayID) {
>> 71: this.displayID = displayID;
>> 72: this.initialMode = getDisplayMode();
>
> This probably should be revalidated when this device is invalidated,
> otherwise deleted device will restore its own old-initial mode, instead of
> the new-mode for the new device.
Ok I've added copying it in invalidate()
> src/java.desktop/macosx/classes/sun/awt/CGraphicsDevice.java line 341:
>
>> 339: * that mode reported and it restores all devices, but
>> 340: * this seems a better compromise than failing to
>> restore
>> 341: */
>
> Would like to highlight that this tradeoff will break the spec, since we
> successfully restore the mode which is not in the list of modes.
So .. it was in the lsit of modes that the app was handed, and it is a bug that
it isn't still there.
But what I've just done is fixed getDIsplayModes() to include it
-
PR: https://git.openjdk.java.net/jdk/pull/4373
Re: RFR: 8267430: GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws AE: Unable to set display mode! [v2]
On Mon, 7 Jun 2021 15:17:48 GMT, Phil Race wrote:
>> There are two issues here, both macOS specific.
>> First the original reported one that occurs when running on a shared remote
>> VNC type desktop on macOS.
>> Only a single supported display mode is returned and it is also the current
>> mode.
>> A program that simply enumerates the reported modes and tries to set them,
>> if it reaches the native layer,
>> will fail because macOS reports the same display mode it returned as valid
>> as now being illegal.
>> It does not appear to be as simple as a user's permission level since it
>> occurs with an admin user as well
>> so it probably is the case that macOS simply does not allow this shared
>> desktop to be changed although
>> there's no docs I can find
>> Ordinarily we would not have tried this since we test if the requested
>> display mode is the same as the native
>> one and skip it, but the provided test used REFRESH_RATE_UNKNOWN which is
>> allowed as meaning match
>> any mode that satisfies W,H,BPP. But this caused it to fail the equals test
>> so the code is enhanced to check for that
>>
>> Second, when creating a test it was discovered that *at least* on the
>> built-in retina display of a 16" macbook pro,
>> the system default contig is never in the list of available modes and can be
>> discovered only by querying the *current* mode
>> before any modes are changed. This beheaviour is 100% consistent no matter
>> if the system was just rebooted, has
>> an external monitor attached as well, or not, activates the discrete card,
>> or not.
>>
>> Since we've had code since at least 2013 that added the default mode I
>> suspect this has been seen before but nowhere
>> can I find an explanation.
>>
>> It has odd consequences like after you change the display mode, you will no
>> longer see the default display mode reported,
>> so the list of available modes is reduced by one.
>> But for a typical use case which doesn't re-query or more typically caches
>> the original display mode in order to restore it, it presents a bigger
>> problem that trying to restore will always fail.
>>
>> So the other thing this fix does is detect when we fail to restore the
>> initial mode and try again in a different way.
>> Only if that fails do we then throw an exception.
>
> Phil Race has updated the pull request incrementally with one additional
> commit since the last revision:
>
> 8267430: GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws IAE:
> Unable to set display mode
src/java.desktop/macosx/classes/sun/awt/CGraphicsDevice.java line 341:
> 339: * that mode reported and it restores all devices, but
> 340: * this seems a better compromise than failing to restore
> 341: */
Would like to highlight that this tradeoff will break the spec, since we
successfully restore the mode which is not in the list of modes.
test/jdk/java/awt/GraphicsDevice/DisplayModes/UnknownRefrshRateTest.java line
67:
> 65: } finally {
> 66: System.out.println("restoring original mode"+odm);
> 67: d.setDisplayMode(odm);
I suggest waiting here as well.
-
PR: https://git.openjdk.java.net/jdk/pull/4373
Re: RFR: 8267430: GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws AE: Unable to set display mode! [v2]
On Mon, 7 Jun 2021 15:17:48 GMT, Phil Race wrote:
>> There are two issues here, both macOS specific.
>> First the original reported one that occurs when running on a shared remote
>> VNC type desktop on macOS.
>> Only a single supported display mode is returned and it is also the current
>> mode.
>> A program that simply enumerates the reported modes and tries to set them,
>> if it reaches the native layer,
>> will fail because macOS reports the same display mode it returned as valid
>> as now being illegal.
>> It does not appear to be as simple as a user's permission level since it
>> occurs with an admin user as well
>> so it probably is the case that macOS simply does not allow this shared
>> desktop to be changed although
>> there's no docs I can find
>> Ordinarily we would not have tried this since we test if the requested
>> display mode is the same as the native
>> one and skip it, but the provided test used REFRESH_RATE_UNKNOWN which is
>> allowed as meaning match
>> any mode that satisfies W,H,BPP. But this caused it to fail the equals test
>> so the code is enhanced to check for that
>>
>> Second, when creating a test it was discovered that *at least* on the
>> built-in retina display of a 16" macbook pro,
>> the system default contig is never in the list of available modes and can be
>> discovered only by querying the *current* mode
>> before any modes are changed. This beheaviour is 100% consistent no matter
>> if the system was just rebooted, has
>> an external monitor attached as well, or not, activates the discrete card,
>> or not.
>>
>> Since we've had code since at least 2013 that added the default mode I
>> suspect this has been seen before but nowhere
>> can I find an explanation.
>>
>> It has odd consequences like after you change the display mode, you will no
>> longer see the default display mode reported,
>> so the list of available modes is reduced by one.
>> But for a typical use case which doesn't re-query or more typically caches
>> the original display mode in order to restore it, it presents a bigger
>> problem that trying to restore will always fail.
>>
>> So the other thing this fix does is detect when we fail to restore the
>> initial mode and try again in a different way.
>> Only if that fails do we then throw an exception.
>
> Phil Race has updated the pull request incrementally with one additional
> commit since the last revision:
>
> 8267430: GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws IAE:
> Unable to set display mode
src/java.desktop/macosx/classes/sun/awt/CGraphicsDevice.java line 72:
> 70: public CGraphicsDevice(final int displayID) {
> 71: this.displayID = displayID;
> 72: this.initialMode = getDisplayMode();
This probably should be revalidated when this device is invalidated, otherwise
deleted device will restore its own old-initial mode, instead of the new-mode
for the new device.
-
PR: https://git.openjdk.java.net/jdk/pull/4373
Re: RFR: 8267430: GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws AE: Unable to set display mode! [v2]
On Mon, 7 Jun 2021 16:07:20 GMT, Alexander Zvegintsev
wrote:
>> Phil Race has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8267430: GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws IAE:
>> Unable to set display mode
>
> test/jdk/java/awt/GraphicsDevice/DisplayModes/UnknownRefrshRateTest.java line
> 44:
>
>> 42: for (GraphicsDevice d : devices) {
>> 43:
>> 44: if (!d.isDisplayChangeSupported()) {
>
> BTW, do we want to run this test on other platforms?
>
> If so, we need to modify test. Because `isDisplayChangeSupported()` may
> return true on Windows and Linux only if we have a fullscreen window showing.
I don't see the harm.
-
PR: https://git.openjdk.java.net/jdk/pull/4373
Re: RFR: 8267430: GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws AE: Unable to set display mode! [v2]
On Mon, 7 Jun 2021 15:17:48 GMT, Phil Race wrote:
>> There are two issues here, both macOS specific.
>> First the original reported one that occurs when running on a shared remote
>> VNC type desktop on macOS.
>> Only a single supported display mode is returned and it is also the current
>> mode.
>> A program that simply enumerates the reported modes and tries to set them,
>> if it reaches the native layer,
>> will fail because macOS reports the same display mode it returned as valid
>> as now being illegal.
>> It does not appear to be as simple as a user's permission level since it
>> occurs with an admin user as well
>> so it probably is the case that macOS simply does not allow this shared
>> desktop to be changed although
>> there's no docs I can find
>> Ordinarily we would not have tried this since we test if the requested
>> display mode is the same as the native
>> one and skip it, but the provided test used REFRESH_RATE_UNKNOWN which is
>> allowed as meaning match
>> any mode that satisfies W,H,BPP. But this caused it to fail the equals test
>> so the code is enhanced to check for that
>>
>> Second, when creating a test it was discovered that *at least* on the
>> built-in retina display of a 16" macbook pro,
>> the system default contig is never in the list of available modes and can be
>> discovered only by querying the *current* mode
>> before any modes are changed. This beheaviour is 100% consistent no matter
>> if the system was just rebooted, has
>> an external monitor attached as well, or not, activates the discrete card,
>> or not.
>>
>> Since we've had code since at least 2013 that added the default mode I
>> suspect this has been seen before but nowhere
>> can I find an explanation.
>>
>> It has odd consequences like after you change the display mode, you will no
>> longer see the default display mode reported,
>> so the list of available modes is reduced by one.
>> But for a typical use case which doesn't re-query or more typically caches
>> the original display mode in order to restore it, it presents a bigger
>> problem that trying to restore will always fail.
>>
>> So the other thing this fix does is detect when we fail to restore the
>> initial mode and try again in a different way.
>> Only if that fails do we then throw an exception.
>
> Phil Race has updated the pull request incrementally with one additional
> commit since the last revision:
>
> 8267430: GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws IAE:
> Unable to set display mode
test/jdk/java/awt/GraphicsDevice/DisplayModes/UnknownRefrshRateTest.java line
44:
> 42: for (GraphicsDevice d : devices) {
> 43:
> 44: if (!d.isDisplayChangeSupported()) {
BTW, do we want to run this test on other platforms?
If so, we need to modify test. Because `isDisplayChangeSupported()` may return
true on Windows and Linux only if we have a fullscreen window showing.
-
PR: https://git.openjdk.java.net/jdk/pull/4373
Re: RFR: 8267430: GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws AE: Unable to set display mode!
On Sat, 5 Jun 2021 15:07:27 GMT, Phil Race wrote: > There are two issues here, both macOS specific. > First the original reported one that occurs when running on a shared remote > VNC type desktop on macOS. > Only a single supported display mode is returned and it is also the current > mode. > A program that simply enumerates the reported modes and tries to set them, if > it reaches the native layer, > will fail because macOS reports the same display mode it returned as valid as > now being illegal. > It does not appear to be as simple as a user's permission level since it > occurs with an admin user as well > so it probably is the case that macOS simply does not allow this shared > desktop to be changed although > there's no docs I can find > Ordinarily we would not have tried this since we test if the requested > display mode is the same as the native > one and skip it, but the provided test used REFRESH_RATE_UNKNOWN which is > allowed as meaning match > any mode that satisfies W,H,BPP. But this caused it to fail the equals test > so the code is enhanced to check for that > > Second, when creating a test it was discovered that *at least* on the > built-in retina display of a 16" macbook pro, > the system default contig is never in the list of available modes and can be > discovered only by querying the *current* mode > before any modes are changed. This beheaviour is 100% consistent no matter if > the system was just rebooted, has > an external monitor attached as well, or not, activates the discrete card, or > not. > > Since we've had code since at least 2013 that added the default mode I > suspect this has been seen before but nowhere > can I find an explanation. > > It has odd consequences like after you change the display mode, you will no > longer see the default display mode reported, > so the list of available modes is reduced by one. > But for a typical use case which doesn't re-query or more typically caches > the original display mode in order to restore it, it presents a bigger > problem that trying to restore will always fail. > > So the other thing this fix does is detect when we fail to restore the > initial mode and try again in a different way. > Only if that fails do we then throw an exception. fixed typo in comment - PR: https://git.openjdk.java.net/jdk/pull/4373
Re: RFR: 8267430: GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws AE: Unable to set display mode! [v2]
> There are two issues here, both macOS specific. > First the original reported one that occurs when running on a shared remote > VNC type desktop on macOS. > Only a single supported display mode is returned and it is also the current > mode. > A program that simply enumerates the reported modes and tries to set them, if > it reaches the native layer, > will fail because macOS reports the same display mode it returned as valid as > now being illegal. > It does not appear to be as simple as a user's permission level since it > occurs with an admin user as well > so it probably is the case that macOS simply does not allow this shared > desktop to be changed although > there's no docs I can find > Ordinarily we would not have tried this since we test if the requested > display mode is the same as the native > one and skip it, but the provided test used REFRESH_RATE_UNKNOWN which is > allowed as meaning match > any mode that satisfies W,H,BPP. But this caused it to fail the equals test > so the code is enhanced to check for that > > Second, when creating a test it was discovered that *at least* on the > built-in retina display of a 16" macbook pro, > the system default contig is never in the list of available modes and can be > discovered only by querying the *current* mode > before any modes are changed. This beheaviour is 100% consistent no matter if > the system was just rebooted, has > an external monitor attached as well, or not, activates the discrete card, or > not. > > Since we've had code since at least 2013 that added the default mode I > suspect this has been seen before but nowhere > can I find an explanation. > > It has odd consequences like after you change the display mode, you will no > longer see the default display mode reported, > so the list of available modes is reduced by one. > But for a typical use case which doesn't re-query or more typically caches > the original display mode in order to restore it, it presents a bigger > problem that trying to restore will always fail. > > So the other thing this fix does is detect when we fail to restore the > initial mode and try again in a different way. > Only if that fails do we then throw an exception. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8267430: GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws IAE: Unable to set display mode - Changes: - all: https://git.openjdk.java.net/jdk/pull/4373/files - new: https://git.openjdk.java.net/jdk/pull/4373/files/d396b068..d93be8fa Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4373&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4373&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4373.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4373/head:pull/4373 PR: https://git.openjdk.java.net/jdk/pull/4373
Re: RFR: 8267430: GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws AE: Unable to set display mode!
On Sat, 5 Jun 2021 15:07:27 GMT, Phil Race wrote: > There are two issues here, both macOS specific. > First the original reported one that occurs when running on a shared remote > VNC type desktop on macOS. > Only a single supported display mode is returned and it is also the current > mode. > A program that simply enumerates the reported modes and tries to set them, if > it reaches the native layer, > will fail because macOS reports the same display mode it returned as valid as > now being illegal. > It does not appear to be as simple as a user's permission level since it > occurs with an admin user as well > so it probably is the case that macOS simply does not allow this shared > desktop to be changed although > there's no docs I can find > Ordinarily we would not have tried this since we test if the requested > display mode is the same as the native > one and skip it, but the provided test used REFRESH_RATE_UNKNOWN which is > allowed as meaning match > any mode that satisfies W,H,BPP. But this caused it to fail the equals test > so the code is enhanced to check for that > > Second, when creating a test it was discovered that *at least* on the > built-in retina display of a 16" macbook pro, > the system default contig is never in the list of available modes and can be > discovered only by querying the *current* mode > before any modes are changed. This beheaviour is 100% consistent no matter if > the system was just rebooted, has > an external monitor attached as well, or not, activates the discrete card, or > not. > > Since we've had code since at least 2013 that added the default mode I > suspect this has been seen before but nowhere > can I find an explanation. > > It has odd consequences like after you change the display mode, you will no > longer see the default display mode reported, > so the list of available modes is reduced by one. > But for a typical use case which doesn't re-query or more typically caches > the original display mode in order to restore it, it presents a bigger > problem that trying to restore will always fail. > > So the other thing this fix does is detect when we fail to restore the > initial mode and try again in a different way. > Only if that fails do we then throw an exception. src/java.desktop/macosx/native/libawt_lwawt/awt/CGraphicsDevice.m line 266: > 264: /* > 265: * Class: sun_awt_CGraphicsDevice > 266: * Method:nativeSetDisplayMode `nativeResetDisplayMode`? - PR: https://git.openjdk.java.net/jdk/pull/4373
Re: RFR: 8267307: Introduce new client property for XAWT: xawt.mwm_decor_title [v2]
On Fri, 4 Jun 2021 21:36:03 GMT, Sergey Bylokhov wrote:
>> Maxim Kartashev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Changed the check for the XFramePeer target being
>> javax.swing.RootPaneContainer in
>> order to avoid unnecessary class loading if it isn't.
>>
>> Also updated the test such that robot.createScreenCapture() is not
>> executed on EDT.
>
> src/java.desktop/unix/classes/sun/awt/X11/XDecoratedPeer.java line 1327:
>
>> 1325: Optional res = Optional.empty();
>> 1326:
>> 1327: if (target instanceof javax.swing.RootPaneContainer) {
>
> Looks like this instanceof will load the Swing as well.
Sorry, missed that one the first time. Corrected now.
-
PR: https://git.openjdk.java.net/jdk/pull/4113
Re: RFR: 8267307: Introduce new client property for XAWT: xawt.mwm_decor_title [v3]
> This commit introduces a new client property xawt.mwm_decor_title > implementing JDK-8267307. The property can be set prior to showing a window > or after the window has been displayed, in which case the window will have to > be hidden/shown (re-mapped) for the property to take effect. > > The general idea is to provide control over the "decorations" part of the X11 > window property called _MOTIF_WM_HINTS. Those "decoration" bits are set to 1 > (XWindowAttributesData.AWT_DECOR_ALL) to show all the decorations or 0 > (XWindowAttributesData.AWT_DECOR_NONE) to ask the window manager (WM) not to > decorate with anything, even borders or resize handles. With > xawt.mwm_decor_title property set to "true", this commit adds the ability to > set the bits to 2 (XWindowAttributesData.AWT_DECOR_BORDER), which some WMs > take as "decorate with only a border", thus effectively removing the window's > title bar, but still leaving the resize capability. > > This feature was tested and works correctly on "vanilla" Ubuntu 20.04 with > the "GNOME Shell" window manager. It was also tested with Xfwm4 and KDE, > where it did not have any effect; these two WMs have limited respected for > the "decorations" bits of the _MOTIF_WM_HINTS window property. Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision: Changed the check for the XDecoratedPeer target being javax.swing.RootPaneContainer in order to avoid unnecessary class loading if it isn't. - Changes: - all: https://git.openjdk.java.net/jdk/pull/4113/files - new: https://git.openjdk.java.net/jdk/pull/4113/files/da9fbfd8..c83c7216 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4113&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4113&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4113.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4113/head:pull/4113 PR: https://git.openjdk.java.net/jdk/pull/4113
