[OpenJDK 2D-Dev] RFR: 8240654 : ZGC can cause severe UI application repaint issues
Jayathirth D v
JAYATHIRTH.D.V at ORACLE.COM
Thu Jun 11 14:10:58 UTC 2020
Yes my machine was at 150% scaling.
If I force uiScale = 1, I see that:
LargeWindowPaintTest fails without patch and passes with patch.
AlphaPrintTest shows instructions without patch also.
@Phil : I think its better if we test at uiScale=1(larger memory footprint). Please clarify.
> On 11-Jun-2020, at 5:53 PM, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
> Do you have a Hi-DPI machine? I do, and had to run with "-Dsun.java2d.uiScale=1" in order to see the failure with LargeWindowPaintTest.
> For AlphaPrintTest, the test deliberately ensures that you print before saying whether it passes or not. FWIW, I verified that the printing test on my system was hitting the fallback code with the patch, but it seemed to print correctly even without the patch.
> -- Kevin
> On 6/11/2020 1:58 AM, Jayathirth D v wrote:
>> Typo : I tried tested -> I tried testing
>>> On 11-Jun-2020, at 2:27 PM, Jayathirth D v <JAYATHIRTH.D.V at ORACLE.COM <mailto:JAYATHIRTH.D.V at ORACLE.COM>> wrote:
>>> Hi Phil,
>>> I tried tested the fix in my Windows 10 machine with Intel integrated UHD Graphics 620.
>>> LargeWindowPaintTest.java passes with/without fix in my machine.
>>> AlphaPrintTest.java without fix just opens up blank frame without any instructions and with fix it shows instructions for the test.
>>> Is this expected behaviour?
>>> AlphaPrintTest.java with fix when it shows instructions if I click on Pass(Since I don’t have printer right now) it doesn’t pass/close the window. Only after I click on Print button and then close print dialog it allows me to click on Pass button.
>>> Also how does these tests behave in our internal CI machines?
>>>> On 11-Jun-2020, at 2:18 AM, Philip Race <philip.race at oracle.com <mailto:philip.race at oracle.com>> wrote:
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8240654 <https://bugs.openjdk.java.net/browse/JDK-8240654>
>>>> Webrev: http://cr.openjdk.java.net/~prr/8240654/index.html <http://cr.openjdk.java.net/~prr/8240654/index.html>
>>>> This is for JDK 15 so review ASAP please since RDP 1 and the test cycle are looming.
>>>> This is not a fix for a JDK bug. It is a bunch of workarounds for a Microsoft Windows bug affecting
>>>> GDI in the context of ZGC (http://openjdk.java.net/jeps/333 <http://openjdk.java.net/jeps/333>).
>>>> Some extra details about the Windows bug at the end, but first the technical details of the fix.
>>>> With ZGC's memory allocation requirement of reserving memory in 2Mb chunks some Windows GDI
>>>> functions, mostly involving some bitmaps APIs may return a failure code (ie fail!)
>>>> This typically occurs when Java heap memory is used for a Java image and then in a JNI
>>>> call we use GetPrimitiveArrayCritical so that Java heap allocated memory is passed to a GDI
>>>> function AND the Java heap memory spans one of the 2Mb boundaries.
>>>> This is very easy to trigger in almost any Java UI app if the window is of a large enough (ie typical) size.
>>>> NB: if you have an Nvidia or ATI card, then you won't see it, because the D3D pipeline doesn't
>>>> call the affected method but if you have an Intel chip as do 90% (?) of laptops you will see it.
>>>> There are also several other places we found that are affected. Printing is the other one
>>>> somewhat easy to trigger. The others : custom cursors and tray icons are less common.
>>>> The painful thing here is that there is no definitive list (a list of the known ones is below) of
>>>> affected Windows GDI APIs and we are just hunting around our code trying to see where it
>>>> might be side-swiped by this bug.
>>>> The basic approach in these workarounds is that for cases where performance does not matter we now copy
>>>> and for cases where performance does matter or larger amounts of memory is involved we check if
>>>> the return value of the GDI function indicates failure and then re-try with a copy of the heap memory.
>>>> Unless GDI was randomly failing already (unlikely) this should be a no-risk solution in the high profile cases.
>>>> We have done performance measurements on the important screen case and the failures
>>>> happen fast so the penalty is then in the re-try which is only if ZGC is enabled.
>>>> Always copying the memory is slower (and memcpy is the slow operation) than an alternative approach
>>>> that "knows" about the memory allocation of ZGC but this coupling and the complexity seem like they aren't
>>>> worth it since I haven't seen any visible performance consequence. That can be revisited
>>>> some day if need be, but for now we have correctness which is the key as well as sufficient performance.
>>>> I've created an automated test for the most important on-screen case.
>>>> Also a manual printing test case which invokes ZGC is provided since there we also only
>>>> conditionally copy. In the other cases we now always copy so existing test cases should over those.
>>>> There is some clean up in this fix - one completely unused (provably so because it was #if'd out)
>>>> JNI method in awt_PrintJob.cpp is removed since it had code that looked like it needed a workaround,
>>>> which would be somewhat of a waste of effort.
>>>> the doPrintBand code and its callee bitsToDevice has code I think we can remove too since
>>>> I don't see how it ever gets executed (the top down case for browserPrint == true) but
>>>> I think I'll save that for a P4 follow-on since it does nothing that would be affected by this
>>>> Windows bug.
>>>> One oddity is the in the printing case I observed that some times the rendering is performed
>>>> even if an error code is returned. I don't know why, but in code we can't tell that it was actually
>>>> rendered and in any case there is no harm in repeating the call with copied memory.
>>>> We are right before the JDK15 stabilisation fork and this fix needs to go there and will
>>>> but the webrev is against jdk/client simply because jdk15 does not exist yet !
>>>> Please test and review ASAP.
>>>> About the bug:
>>>> Microsoft has acknowleged the bug and will publish a knowledge base article about it
>>>> but a fix may show up only in a future version of Windows. Not, it seems, any time soon.
>>>> Below is a list of potentially affected GDI APIs. Per microsoft whether it actually manifests in
>>>> any specific case depends on "branching"
>>>> https://docs.microsoft.com/en-us/previous-versions/windows/desktop/wcs/checkbitmapbits <https://docs.microsoft.com/en-us/previous-versions/windows/desktop/wcs/checkbitmapbits>
>>>> https://docs.microsoft.com/en-us/previous-versions/windows/desktop/wcs/createcolortransform <https://docs.microsoft.com/en-us/previous-versions/windows/desktop/wcs/createcolortransform>
>>>> https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-setdibitstodevice <https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-setdibitstodevice>
>>>> https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-stretchdibits <https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-stretchdibits>
>>>> https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-getbitmapbits <https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-getbitmapbits>
>>>> https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-createdibitmap <https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-createdibitmap>
>>>> https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-createdibsection <https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-createdibsection>
>>>> https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-polydraw <https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-polydraw>
>>>> https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-drawescape <https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-drawescape>
>>>> https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-createbitmap <https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-createbitmap>
>>>> https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-setbitmapbits <https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-setbitmapbits>
>>>> https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-getdibits <https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-getdibits>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the 2d-dev