問題タブ [invokedynamic]

最後の課題作品を手に入れることは可能ですか？逆の方法が機能しない:メソッド参照を MethodHandle に変換することは可能ですか?

コピーして貼り付けることができる別の例を次に示します。

現在、このプロジェクトに取り組んでいます。驚くほどうまく機能します。

しかし、もう一度 README を読み直した後、私を悩ませている何かを文書化する方法について疑問に思うようになりました...

例を引用すると、例外がスローされる可能性があることを少し忘れると、次のようになります。

わかった。さて、Path絡み方はこちら。もちろん、 は渡しませんLinkOption。

繰り返しますが、例外がスローされることを少し忘れましょう。

Streamは引数として.map()aを取ります。Functionのこのインターフェイスは、次のFunction<T, R>ように定義されます。

しかし、私が使用しているメソッドは引数を受け入れません。一見、 a と一致しないように見えFunctionますよね？それ以外で...

次のように記述できます。

したがって、メソッド参照に引数がない場合、またはそのようなものがある場合、使用されるメカニズムは「ストリームオブジェクト」でメソッドを呼び出すことができるように見えます...

それに応じてこれを文書化したいのですが、ここに何かが欠けています。

私は何が欠けていますか？

メソッド ハンドルのメソッド パラメータがわかりません。まず、以下に示すように、test メソッド ハンドルを使用してガードを作成します。

私にとっての問題は、パラメーターが 3 つのメソッド ハンドル (test、trueTarget、および faliover) にどのように渡されるかということです。1、invokeExact の最初のパラメーター「result」がレシーバーとしてテスト ガードに渡され、2 番目のパラメーター「data」が startWith に渡されます。

But the these three parameters are passed to the falseTarget as:

So, what's the rule for parameters passing and how do they match to the methods referenced by a method handle?

Java 8 では、第一級関数のサポートが導入され、関数を変数に割り当てることができます。この場合、変数は関数型である必要があり、関数型インターフェイス(抽象メソッドが 1 つだけのインターフェイス)によって定義されます。

したがって、次の定義を持つインターフェイスIとクラスの例を考えてみましょう。A

型の変数にIのインスタンスAまたは のメソッドへのメソッド参照barを割り当てることができますA。I両方とも、次のようなtype の変数に格納できます。

前のコードをコンパイルした結果のバイトコードを分析すると、次のようになります。

それi1 = new A();は、対応する命令がと互換性7: astore_1のある のインスタンスを格納していることは明らかです。しかし、 の結果として、 の結果を保存しています。AIi2 = A::bar8: invokedynamic #4, 0

つまり、 an の結果invokedynamicは常に、メソッド参照で割り当てる変数の型である対象の型のインスタンスになるということです。

Groovy を少しいじっ--indyて、パフォーマンスに顕著な影響があるかどうかを確認するために、バブル ソートの実装を作成しました。

基本的に、1,000 個のランダムな整数のリストを 1,000 回ソートし、リストをソートするための平均実行時間を測定します。

リストの半分はInteger[]で、残りの半分はArrayList<Integer>です。

結果は本当に私を混乱させます：

ベンチマークの実行中の CPU 使用率を見ると、CPU 使用率は、--indyなしでコンパイルした場合よりもはるかに高くなっています。

これに興味をそそられたので、もう一度ベンチマークを実行しましたが、今回は Yourkit エージェントと CPU トレースを有効にして実行しました。記録された呼び出しツリーは次のとおりです。

なし--indy:

と--indy:

パフォーマンス チャートは次のとおり--indyです。コードが非常に遅いため、タイム スケールが異なることに注意してください。

なし--indy(1 秒スケール):

あり ( --indy60 年代スケール):

ご覧のとおり、CPU 使用率は、なしでコンパイルすると 1 つのコアの 100% (グラフでは 12.5%) で安定しますが、でコンパイルする--indyと 12.5% から ~35% の間で大きく変化し--indyます。さらに紛らわしいのは、Yourkit が 1 つのライブ スレッドしか報告しないことです (そして、私のコードはメイン スレッドのみを使用します)。

でコンパイルされたコード--indyも、開始時に多くのカーネル時間を使用しますが、これはしばらくすると低下し、0% で安定します。その時点で、コードは少し高速化され (ヒープ使用率の増加率が増加)、CPU 使用率が増加します。 .

誰かが私にこの動作を説明できますか?

バージョン:

BubbleSort.groovy:

動作に関連しない限り、バブル ソートの実装の最適化には興味がinvokedynamicありません。ここでの目的は、可能な限り最高のパフォーマンスを発揮するバブル ソートを記述することではなく、--indyパフォーマンスに大きな悪影響を与える理由を理解することです。

アップデート：

私はコードを JRuby に変換し、同じことを試してみましたが、結果は似ていますが、JRuby は以下を使用しないとそれほど速くはありませんinvokedynamic。

更新 2:

リストを半分の時間に変更するコードを削除すると、Integer[]パフォーマンスが大幅に向上しますが、なしでも高速--indyです。

JRuby で同じことを行うと、invokedynamicより高速になります。

私は単純なプロジェクトに取り組んでおり、Bean プロパティを取得する必要があります。まず、リフレクションを使用します。次に、パフォーマンスを向上させるために、invokedynamic とメソッド ハンドラーについて調査を行いました。

インボークinvokeExactはリフレクションよりもはるかに高速ですが、リフレクションよりもはるかに低速です。

テスト環境:

• Win7 32ビット
• ジャワ 7 U 80
• コアによるCPU 3.06GHZ

私が得たtp / msはこれについてです：

パフォーマンス テストの出力は次のとおりです (2 回実行しました)。

ここに私のテストコードがあります:

invokeExactコンパイル時に正確な戻り値の型がわからないため、ユース ケースを満たすことができません。リターンの型（強制キャスト）がMethodHandleの性能を左右する重要な鍵のようです。

MethodTypeの戻り値の型が正確であるため、これは予期された結果ではないようです。パフォーマンスを向上させるためにフォースキャストを行うことが依然として重要なのはなぜですか?

これに関する詳細を説明するドキュメントはありますか? また、リフレクションとメソッド ハンドラの使用の impl の詳細を比較するドキュメントはありますか?

動的な型とメソッド ディスパッチをサポートするために、私のプログラミング言語には という型が導入されていdynamicます。型が の呼び出し先でメソッドを呼び出す場合dynamic、コンパイラはまず呼び出し先とすべての引数をスタックにプッシュし、次にinvokedynamic通常の命令の代わりに命令を生成しinvoke*ます。この命令は、 というクラスの特別なブートストラップ メソッドを指していDynamicLinkerますが、呼び出されたときに利用できるのは静的な型だけです。

私の問題invokedynamic:命令に渡された引数の実行時型を取得するにはどうすればよいですか?

概要

Runnable メソッド参照 (System::gc) の 448 インスタンスで null MethodHandle の invokeExact メソッドを呼び出すメイン メソッドを持つインターフェイスをコンパイルできました。

インターフェイスを実行すると、Java ランタイム環境によって致命的なエラーが検出されました。

• pc=0xb71b9bde、pid=12918、tid=3030936432 の SIGSEGV (0xb)
• JRE バージョン: Java(TM) SE ランタイム環境 (8.0_51-b16) (ビルド 1.8.0_51-b16)
• Java VM: Java HotSpot(TM) クライアント VM (25.51-b03 混合モード linux-x86 )
• 問題のあるフレーム:
  • V [libjvm.so+0x507bde] SignatureIterator::parse_type()+0x1ce

ソースコードと実行結果のリンク: http://ideone.com/3oh7Uk

ソース

結果