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

[Denis Lila]

I also removed the System.exit(1) calls in PiscesTileGenerator.
It doesn't seem like a good idea to shut down the whole VM
because of a rendering bug.

----- Original Message -----
> 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,
> >
> ...