[OpenJDK 2D-Dev] RFC: 7019861 + workaround + minor optimization

[Denis Lila]

Hi Jim.

> Forgive my ascii art shorthand, "=>" was supposed to be an arrow, not
> a
> comparison operator. I was saying that you use the word "and" on that
> line and it should be changed to the word "or" because a non-compliant
> edge can be invalid by violating either (i.e. "or") condition. In
> other
> words/symbols:
> 
> "and" ===should be===>>>> "or"

Aha, I see. I usually use "==>" for implication.

> Also, in rereading it, you talk about the edges crossing outside of
> the
> range but my brain immediately goes to the fact that when they first
> came in they may have had huge extents, but they were then clipped.
> Perhaps it would be better to use the term "edge fragment stored in
> the
> edges array" or "clipped edge". Also, the word "cross" is a little
> overloaded. What about:
> 
> // Preconditions: Only subpixel scanlines in the range
> // (start <= subpixel_y <= end) will be evaluated. No
> // edge may have a valid (i.e. inside the supplied clip)
> // crossing that would be generated outside that range.

I do like this better.

> Just curious if the "final" attribute on local variables might be
> causing it problems?

No, I don't think so. What's happening is that the compiler is trying
to unswitch the loop by moving one of the switch statements outside
of the loop. Once it does that, the IR graph ends up with many code
paths, and in one of them, a variable that is used for a future
array index is set to a value that makes the index always < 0.
When int to long conversion nodes are created are created by the
parser, we give the node a type of int[0,max_int]. So, when the
index is proven to be <0, that node is killed. However, the control
path that leads to that node's computation is not killed (in this
case, that's because it's an OSR compilation and it doesn't have
enough information to prove it's dead code). So we end up with a
phi node with a control input whose corresponding data input is
dead, and this causes problems in some future dominator computations.
The workaround fixes it by doing the loop unswitching manually.

> I guess I meant the spmin/maxY. The pmin/maxY have been rounded out to
> the next full pixel boundary and then you convert back to sub-pixel
> precision, but in doing so you then force the iterator to iterate
> through any subpixel positions before spminY and after spmaxY. This is
> probably in the noise for any but the smallest shapes, but still -
> isn't
> it wasted effort?

Good point. I completely forgot we had the spm* variables.

I updated the webrev.

Regards,
Denis.

----- Original Message -----
> Hi Denis,
> 
...