Hi Mario, > I implemented the method based approach. What I did was to introduce an > interface that all loops implements, this interface consist of a single > method that returns a boolean. > > I made the implementation final everywhere to try to limit the impact of > it, although I'm not sure this is 100% correct in all cases, but the > impact is still too high. In my opinion we should try to go with the > interface approach, it's really less costly and less complex, basically > no impact at all in all the tests.
.. > Finally, the webrew: > > http://cr.openjdk.java.net/~neugens/100068/webrev.06/ So the short story is the webrev.05 was actually better and we better forget about webrev.06 at this point? Regarding webrev.05, I find the 5x instanceof a bit ugly. I am not sure how to avoid it though. Maybe put the pipe fields in a container. This container could have a (marker) subclass that is instanceof'ed for. Whenever a SD sets up loop based pipes, it uses the subclass. Otherwise it uses the base class. Then you'd only need one instanceof check against the container. But OTOH you would get double field access in a couple of cases, of which I don't know if hotspot optimizes them away somehow. And it's probably not worth thinking about any of this if impact is not noticable already. Maybe the if cascade bails out at the first check already? Maybe it's worth ordering the if cascade so that the most likely case is the first one, etc? > Please, ignore the ".hgignore" changes in the patch. Haha. ;-) Cheers, Roman
