<p dir="ltr">I'd argue that the cacheline fetch is more of an issue when not dealing with array iteration but with the "islands" I was referring to earlier.  In the array iteration scenario, the actual method invoked may be less expensive than the type check.  Yes, the branch will be predicted and all, but that's still extra code that will execute, extra entry in the BTB, etc.</p>
<p dir="ltr">Maybe you guys aren't convinced, but do realize that there's plenty of code out there with the "one impl of an interface loaded" situation.  Every small efficiency gain counts, IMO.</p>
<p dir="ltr">sent from my phone</p>
<div class="gmail_quote">On Apr 16, 2015 2:56 AM, "John Rose" <<a href="mailto:john.r.rose@oracle.com">john.r.rose@oracle.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The real cost of the type check is a cache line fetch. In this case you have a bunch of objects whose code is the same method(s) and data fields are the only way to vary the behavior. So almost any plausible application of this pattern will need the same cache line as the data fields.<br>
<br>
We have yet to see a convincing use case for this CHA (THA) case.  I put some code in the VM to support this once but we never needed it and it was removed.<br>
<br>
(Another opt with a similar flavor would be support for the singleton pattern.)<br>
<br>
– John<br>
<br>
> On Apr 15, 2015, at 8:05 PM, Vitaly Davidovich <<a href="mailto:vitalyd@gmail.com">vitalyd@gmail.com</a>> wrote:<br>
><br>
> That would certainly be a place where removing the type check would be beneficial<br>
</blockquote></div>