[OpenJDK 2D-Dev] Please review patch for 7105461
james.graham at oracle.com
Wed Oct 10 20:21:54 UTC 2012
Have you done any performance testing to see if the new protections cost
One comment on code style - "if" is not a function call so the style
guidelines specify a space before the parentheses with the conditional
test (line 128 and 135).
The logic looks fine, but I'll point out that width/height can never be
< 0 since they are the output from ClampToUShort so the test looks odd
(but isn't incorrect). You could test for simply == 0 or you could test
for x2,y2 <= x,y before the ClampToUshort, but testing for <= 0 after
certainly isn't hurting anything.
Also, many of these tests are duplicated between the shortcut tests in
the method and the (hidden behind a method call) tests done by the
clamp/clip methods. I'm not sure that hurts performance, though, but if
these changes show up on a microbenchmark then we might want to consider
inlining all of the logic and eliminating duplicate tests. For example,
the ClampToUShort method tests for < 0 so it can clamp to 0, but the
calling method will then short-cut on that same case anyway. The code
might be less obvious if it is all inlined, but fillRect is a fairly
common operation that we don't want to impact too much simply for sake
of having an obvious implementation...
On 10/10/12 12:30 PM, Clemens Eisserer wrote:
> Hi Jim,
> A new version of the patch is available at:
>> If x or y are> MAX_SHORT then you should probably just reject the operation
>> immediately, otherwise you end up with a bunch of math that should end up
>> doing a NOP, but it is tenuous if it actually succeeds in doing so.
> Done. Thanks for pointing that out.
>> Also, if x,y are< MIN_SHORT then when you clamp them to MIN_SHORT they may
>> be> x2,y2 and so when you clamp the dimensions you will end up clamping a
>> massively negative number to Ushort. I don't have the code off hand to see
>> how the method deals with that, but it is probably not 100% kosher in this
>> case (not sure if the subtraction might end up looking like a huge positive
>> number). Thus, it is probably better to reject the op if x2,y2 are<
>> MIN_SHORT as well rather than rely on the processing.
>> Also, rejecting the call here rather than relying on the outcome of the math
>> avoids adding NOP requests to the X protocol stream...
> This would have been handled by the width/height-check later (tested),
> however as you pointed out it's better to exit early.
> Would you prefer combining the MIN/MAX checks after calculating x2/y2
> to improve redability?
> However, I found another problem: clampToUShort returned a short, so
> when a dimension> Short.MAX_VALUE was clamped, the check>=0 later
> saw some negative value and exited for a valid request. As for now
> fillRect is the only consumer, I took the liberty to change its return
> type to int.
> Thanks a lot for the detailed in-depth review (and you patience).
> - Clemens
More information about the 2d-dev