皆にとって良い日、Roman PoborchiyはJUG.ruブログで再びあなたと一緒です。そして今日、エスケープ分析とスカラー化に関するRuslan cheremin Chereminのレポートを分析しています。





スライドはこちらで表示およびダウンロードできます 。 従来の免責事項 ：Javaについては、記事自体ではなく、記事で解析されたレポートのみ。

プロット

ここで私は私の印象の大部分を持っています-肯定的なもの、私はレポートに存在すべきだと思うすべてのものがそこにあります。 提案された変更は、本質的に表面的なものです。

問題の声明

あなたのことは知りませんが、Ruslanは、Javaでエスケープ分析がどのように機能するかを理解することは有益だと確信しました。 この知識を念頭に置いてコードを記述すると、ヒープ上のオブジェクトが少なくなり、gcが少なくなり、一般的に世界は良くなります。 「なぜ」という質問に対する答え。



ただし、03：37に表示されるコミック画像は、統計をわずかに覆い隠します。 最初に見た後、私はこのグラフのみを思い出し、「平均」でどれだけの量を得ることができるかという数字がないことを不満に思っていました。 2回目の表示で、数字（除外できる割り当ての15％まで）が記載されていることがわかりました。 同様の「正常な」ケースを見つけて表示することができた場合は、メモリに保存する方が適切でした。 もちろん、注文の練習からそのようなデータを見つけることは必ずしも簡単ではありません;いいえ、いいえ。

結論

レポートの結論と推奨事項は、ストーリーの論理に基づいており、実用的かつ具体的です。 「小さな」方法で（たとえば小さなメソッドを書くために）何をする必要があるのか​​、なぜこれが正確に実行する必要があるのか​​を理解しているだけではありません。 また、この「良い」ものを使用すると、ほとんどの場合、正確な定量的尺度を見つけ出し、必要に応じて再定義することさえできることがわかりました。 あなたは幸せにこれ以上何を望みますか



聴衆に警告することができない限り：コンパイラのデフォルトを頻繁に、そして無意識に再定義すると、何かが確実に壊れますが、これには例と時間が必要であり、焦点がぼやけます。

省略

ここで不足しているのは、実験手順の説明です：初めて、起動の結果がスライド16（時間13:38）に表示され、すぐに呼び出しの数によって制限された12回の実行が表示されますが、時間によって異なります。 なぜそうですか？ これは理にかなっていますか、または歴史的に起こりましたか？ なぜ場合によっては、時間は5秒（スライド16、17、19、および他のいくつか）、他の3（スライド68、73、および他のいくつか）であり、他ではまったく示されない（スライド89、90、91）のでしょうか？



ここでテクニックを1回説明するだけで十分です。不信を排除するためです。以降のすべての参照では、繰り返しの詳細は必要ありません。これについてはスライドのセクションで詳しく説明します。

ステージに銃がぶら下がっています

散弾銃を掛けたのはスピーカー自身ではなく、視聴者の1人が場違いな叫び声を上げましたが、何らかの形でΦ関数について2回（特に16:40から30分）でした。 コンパイラは理解するために基本的な知識を必要とするものの1つですが、私たちの聴衆は常にこの知識を持っているとは限りません。 理解している人が2人または3 人いるので、一般的な言葉で、それが何であるかを伝え、彼らが困feelしていると感じないようにすることは価値がありました。



事前に準備されたスライドがなかったので、これらのΦ関数が何であるか、そしてそれらが物語の主題にどれほど大雑把に関連しているかを伝えるために、指では不可能かと思いました。 私は自分自身に焦点を当てています。つまり、20年前にコンパイラーに関する特別なコースを通過し、それ以降はユーザーとしてのみコンパイラーを操作した人のレベルに焦点を当てています。 もちろん、レポートを表示した時点で、それが何であるかを覚えていませんでした。 そこで、スライド23を見て、そこで何が起こっているのかを説明しようとしています。









テキストだけではまだ非常に難しいですが、事前に準備しておけば、ダイアグラムを描くことができ、SSA形式について話すことを恐れることはありません。概念レベルでは難しくありません。 実装にはおそらく多くの明白でない詳細があり、一部の聴衆は、内部表現と基本ユニットがだれであるかを説明するために余談をする必要がありますが、それでも。



この投稿が実際のコンパイラーによって読まれた場合、おそらく彼は、おそらくドラゴンブックを手に入れることなく、棚から離れて穴を読んで、エラーを指摘し、同時に正しく伝える方法を説明します。

スライド

ストーリーを追跡するのは簡単です。スライドはこれに役立ちます。 どこかに多くのテキストまたはコンソールユーティリティの大きな出力がある場合、興味深い場所が強調表示されます。 コードには多くの例があり、それらはますます相互に置き換えられています。これに少しうんざりしますが、重要なことは何もありません。 私はまだいくつかのことに注意を引きたいです。

レーザーポインター

以前の分析を読んだ人は、レーザーポインターの使用に関するすべてをすでに知っています。 Ruslanのパフォーマンスは、Sergeyのスクリーンと同じ2つのスクリーンを備えた同じホールで行われ、ターゲットインジケーターは常に3分の1の視聴者に見えません。



いずれの場合も、スライドを修正して、議論の対象がすぐにわかるようにすることができます。 たとえば、スライド13（10:20に表示）は非常に簡単に修復できます。







ここでは、テキスト全体を一度に表示するのではなく、ポイントに達したときに行を順番に開くだけで十分です。

アイテムを複製

パフォーマンスを見るとき、私はいつも同じ形式の多くのスライドで見られる実験の定量的結果で何かをしたかったのです。







それらの何が問題になっていますか？

• これは非常に高密度のテキストであるため、読みたければ読むのは困難です。
• 興味深い瞬間はルーンの間ではなく、ルーン文字の内側のどこか、通常は最初のルーン文字の始まりの近くです。 そのため、実行ごとにグループ化された結果（反復ごとに0.01バイトなど）は異常に見えますが、簡単に取得できます。
• 視聴者は、色から実験の結果に関する情報を即座に受け取ります。 これは正常ですが、赤と緑の色覚障害を持つ人にとっては困難をもたらす可能性があります（運が良ければ、それが最も一般的です）。

これを単純化する方法は？



最も指標となるのは、x軸が呼び出し番号（すべての実行のパススルー）を表し、y軸がこの呼び出しのヒープに割り当てられたバイト数を示すグラフです。 悪いケースでは、チャートは水平になり、良いケースでは、最初のいくつかの（数千）呼び出しが水平になり、その後ゼロになります。 同時に、次のような最適化がどれだけ早くオンになるかを彼から見ることができます。







この形式では、確率関数で起こっていることのダイナミクスを追跡することは興味深いでしょう（スライド98〜91）。 そこでは、おそらく、スケジュールが興味深いものになるはずです。







おそらく私は何かを理解していないので、そのようなスケジュールのデータは、原則としてストレッチマークがあっても取得できません。 次に、run'ovのサイズを大幅に削減し、それらにグラフを作成することができます。

定期的なレビュー

プレゼンテーションに関するフィードバックを受け取りたい場合は、喜んで提供します。