インターフェースが要求するメソッドを並べたインターフェーステーブルがあって、

2:32 AM

クラスのインターフェースの充足は事前に静的にわかるので

2:32 AM

そのテーブルは生成されていて

2:33 AM

インターフェースにアップキャストしたオブジェクトっていうのはそれで扱われてるはずです

2:33 AM

この辺の詳細はJVMバイトコードとは独立してJVMランタイム固有の部分みたいだけど

2:33 AM

以前IBMのスライドで見た。

2:33 AM

C++のインターフェースアップキャストも同じような構造でコンパイルされます。

2:33 AM

そうしないと、対応するメソッドの検索がO(1)にできないからです

2:34 AM

こうしておくとインターフェースとメソッド番号(index)でテーブルから一発で引ける。

2:34 AM

で、それが8バイトポインタから間接で引いてるのか、インターフェースキャストしたthisとインターフェーステーブルのペアの16バイトなのか、そもそもペアで扱うのかとかは知らない。

2:35 AM

そのような設計にした理由

これに関しては、こうしておいたほうが「witnessテーブルを引く」実行コストが少ないからだと思います。

2:36 AM

ある型Tがany Pコンテナに格納される部分のコードでは、witness table of T for P はコンパイル時に静的に引けるので

2:36 AM

any Pコンテナへのアップキャストのところで静的にテーブルを格納できて、 any P をopenする側ではもうそこにテーブルがあるので取り出せば呼び出せる。