[OpenJDK 2D-Dev] RFR: 8240654 : ZGC can cause severe UI application repaint issues

Philip Race philip.race at oracle.com
Thu Jun 11 14:44:57 UTC 2020

Can I get clarification here.

 > I do, and had to run with "-Dsun.java2d.uiScale=1" in order to see 
the failure with LargeWindowPaintTest.

So you both mean a JDK 15 promoted build without this fix and without 
this property passes because you have
a hidpi setup. And to see the failure without the fix you needed the 
above property.
If so we could just be looking at a similar anomaly as I saw with 
printing which uses a very large
image - it reported failure but actually worked !

Also - for both of you - with the fix and without forcing uiScale=1 does 
the test pass ?


On 6/11/20, 7:10 AM, Jayathirth D v wrote:
> 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.
> Thanks,
> Jay
>> On 11-Jun-2020, at 5:53 PM, Kevin Rushforth 
>> <kevin.rushforth at oracle.com <mailto: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 
>>>> 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?
>>>> Thanks,
>>>> Jay
>>>>> 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
>>>>> Webrev: 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).
>>>>> 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/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-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-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-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-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-getdibits
>>>>> -phil.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200611/f9d73e89/attachment-0001.htm>

More information about the 2d-dev mailing list