「エンジニアの仕事-主張を与える」-Java Performance TeamのSergey Kuksenkoへのインタビュー

JUG.ruやCodeFreezeの会議に参加したことを想像してください。たとえば、Javaパフォーマンスチームの開発者であるSergey Walrus Kuksenkoが発言したばかりのJava会議に参加したとします。 そして今、何らかの理由で、他のすべてのリスナーが逃げ出し、あなたとセルゲイは一人で放置されました。 そして突然、彼は急いでいない、そして彼はあなたの質問に答える自由な時間を持っている、その多くが蓄積している...







会いましょう：今日、私たちは絶対に排他的です- セルゲイ・ククセンコとの素晴らしいインタビュー ！ インタビューから次のことを学びます。

• Javaパフォーマンスチームの仕組み
• Javaのどの領域でアクティブなパフォーマンス作業が行われているか
• ジグや会議でハードコアが必要なのはなぜですか
• パフォーマンスエンジニアが知っておくべきこと
• 高速道路とは何ですか、国境はどこに行きますか
• Java文字列で現在何が起こっているのか
• ランタイムのチューニングはどの方向に進化しますか

-セルゲイ、あなたは私たちと一緒にプレゼンテーションをすることが多く、毎回あなたのレポートはあなたが話している資料の観点からますます難しく、より複雑になり、あらゆる種類の鉄のものにますます深くなります。 あなたが言うとき、あなたは人々の目で見ます-あなたはそこに何らかの理解を見ますか、あなたが深くなるにつれて理解が失われますか？



Kuksenko：これは、私が一般的にレポートでキャッチしようとする最も重要なフィードバックです。 事実、聴衆の反応を見ると、私のレポートが無駄にされなかったという事実からある程度の喜びを感じます。平均して、少なくとも十数人のアクティブなリスナーを見ると、レポートは成功したと思います。 これは頻繁に起こります。



-それで、あなたはあなたが保持しようとしている特定の割合を持っていますか？



Kuksenko：はい、私は情報を持ち込みます。誰かに連絡するために必要なので、自分だけでなくプレゼンテーションを行います。



-そして、どのようにこの選択をするのですか？視聴者にさまざまなバックグラウンドを持つ人々がいるとき、彼らは異なるレベルの理解を持っていますか？ 事前に「固定された複雑さを伝えます」と言いますか、それとも複雑さを調整しますか？





Kuksenko：事前に、かなり複雑なレポートがあることを発表します。聴衆に関する情報があり、関心のある人が十分にいないことがわかっている場合は、レポートを実施せず、そのような弱い会議には参加しません。



-オーディエンスに関する情報をどのようにして見つけますか？



Kuksenko：原則として、 事後 。



-会議の主催者として、レポートに影響を与える可能性のある聴衆について何をお話しできますか？



Kuksenko：この質問に対する答えがわかりません。 原則として、会議への訪問の聴衆のレベルを評価し、もう一度ここに行くかどうかを自分で決めます。







-あなたは今、ロシアで4年間演奏しています。 2012年に始めましたか？



Kuksenko： 2011年以降のどこか。



-視聴者が増えていると思いますか？ 量ではなく、あなたが話していることの理解度によって？



Kuksenko：正直、いいえ。 少しフィードバックがあります-聴衆は疲れているのがわかります。私たちが年々報告する複雑なレポートにうんざりしているようです。 まあ、少なくともそういう風に思えます。 さまざまな会議で私が覚えている非常に興味深い人々がこの地域を離れていることがわかります。 彼らのキャリアが始まるか、マネージャーに変わるか、他の何かになります。 そして、私はまだ深刻な代替品を見ていません。



おそらく最初のレポートの効果は機能し、人々が技術的なものに飢えたとき、彼らは多くの質問をしました。 今、私は複雑な技術報告書の聴衆からそのような関心の減少を見ています。



-おもしろいのは、あなたとレシャ（アレクセイ・シピレフ-作者のメモ）が自己コピーをしないことを本当に気に入っているからです。 2011年から2012年にパフォーマンスのトピックがあり、その後少し成長しました。



Kuksenko：みんな言った。 なぜ繰り返しますか？ 2012年以降、この分野では何も変わっていません。



-現在、パフォーマンスサイエンスはどの程度活発ですか？特にJavaでのパフォーマンスはおそらく？



Kuksenko：パフォーマンスサイエンスについては何も言いません。 科学で何が起こっているのか分かりません。 おそらく何かが開発中です。 パフォーマンスは応用工学ほど科学ではなく、現実のものがあり、この現実を何らかの時間枠、要件などに押し込まなければなりません。



Javaはさまざまな分野で変更を加えます。 グローバルな計画はありません。「2020年までに、普遍的な幸福が訪れ、1ピコ秒であらゆる操作を実行します。」 製品があり、いくつかの場所を見つけ、ここでそれを引き締めます...新しいものが発明され、新しいハードウェアへの適応が進行中など、つまり、通常のプロセスです。



-パフォーマンスに携わる人々が新しい鉄チップを使用できるように、鉄はどれくらい速く変化しますか？



Kuksenko： Intelは2年ごとに興味深い十分なチップを備えた新しいマイクロアーキテクチャを展開していますが、多かれ少なかれ真剣な研究に目を向けると、ある種の超大型の新機能が登場し、新しいアーキテクチャが登場しました...そして、パフォーマンスの平均的な性質がどれだけ得られたか病院全体の平均気温という点で？ まあ、プラス6％。



ソフトウェアの定期的に新しい機能が表示されます。 ソフトウェア部分はこれに対応していません。 彼女は、特にJavaレベルで、多かれ少なかれアーキテクチャに依存しないソリューションを提示しなければならない状況に追いつくことを試みていますが、これを追う必要があります。



-ベクトル化とベクトル命令は、最新のプロセッサに長年存在していました。 多くの場合、Java仮想マシンはあまり使用していないと非難されています。



Kuksenko：ここには2つの問題があります。原則として、これらのすべての命令は特定のシナリオとユーザーケースに対して研ぎ澄まされており、これらのユーザーケースをこのアーキテクチャに対して研ぎ澄まされていない抽象コードから定義する問題は未解決のままです。 自動ベクトル化は、単純な場合に解決される問題です。 しかし、左へのステップ、右へのステップ-ベクトル化アルゴリズムは機能しなくなります。



ハードウェアでこれが必要な理由は明らかです。なぜなら、特定のプラットフォーム向けのプラットフォームを、一部の組み込み関数やその他のネイティブコードを使用してlaアセンブラレベルまで迅速に研ぎ、必要なものを取得できる開発者が何百万人もいるからです。 Javaでの私たちの目標はわずかに異なる目標ですが、軽視していませんが、最も重要なことはまったく同じ方法で研ぎ澄まされています。



-手動でシャープにする場合の例を挙げてください。



Kuksenko：まず、文字列操作。 それらのほとんどは特定のハードウェアに合わせて調整されており、まもなくこの領域でいくつかの小さな更新が行われ、ますます多くの更新が行われます。 これは1つの領域です。



2番目の領域は、常に古典的に手動で研がれますが、暗号化の領域です。これは、より高速で安全な暗号化に焦点を当てたハードウェアの新しい命令があるためです（たとえば、ランダムジェネレーターは最新のIntel腺で本物です）。 そして、セキュリティの分野での暗号化の観点から、これらの鉄の能力を無視することはあまり良くないことは明らかです。 ただし、ここで同じ暗号化を使用する場合、重要な問題はアプリケーションのパフォーマンスの問題ではなく、アプリケーションのセキュリティの問題です。 実際のランダムジェネレーターを使用して、エントロピーを高め、エンコード自体にcなベクトル化コマンドを使用して保護を強化します。たとえば、より複雑なエンコードアルゴリズムなど、同じ時間枠に詰め込み、セキュリティを向上させます。 ここでは、パフォーマンスが仲介されます。 そして、ここで大きな疑問が生じます。実際のユーザーはどれくらいのベクトル化を必要としますか。



-つまり、必要な事実はまったくありませんか？ すべての会議で、これはJavaとパフォーマンスに関係するものであり、ベクトル化の問題であるため、これはお気に入りの質問です。 誰もが指を突くのが好きで、それを言う...



Kuksenko：そして、シシュニクはどれくらいの頻度で実際に製品の優れたベクトル化を達成していますか？ JPointとJokerのレベルでのプレゼンテーションの歴史を通して、最後のJokerで、「例があります。 オーバークロックします。 そして、ここで小さなベクトル化が起こりました。」 ある男が傍観者として出てきて言った。 「1つの場所を分散させたかったので、今度はそれをベクトル化するように努めます。」 この間ずっと、本当にそれを必要とし、彼の仕事を知っている唯一の人が私に出くわしました。



筋金入りのパフォーマンスについて



-パフォーマンスの基本を伝えるとき、これは多かれ少なかれすべての人にとって必要であることは明らかです。 しかし、あなたが非常に高度なことを言うとき-たとえば、前回のレポートのようにCPUが100％負荷になった場合、実際に必要なのはどの部分ですか？ 100分の1という感覚。



Kuksenko：少なくない場合。 この視聴者に焦点を当てています。



そのようなレポートの教育的側面についてどう思いますか？



Kuksenko：私はそれらを教育的なものとは考えておらず、より慣れ親しんでいると考えており、「できることはたくさんあります」とだけ示しています。 そして、それを必要とする人は、彼がこの方向に動き、停滞しないことを理解します。



-数日前、Highloadカンファレンスを行った友人のOleg Buninと話をし、Highloadの意見を聞いてみたところ、彼はそのようなことを言った。腺で発生します。 実行方法を気にしない限り、それはHighloadではありません。心配し始めるとすぐにHighloadになります。」 この声明についてどのようにコメントできますか？



Kuksenko：私にとって、Highloadはもう1つの流行語です。 私がいつもレポートで言ったように、生産性はバイナリメトリックです：クライアントは不満または満足のいずれかであり、すべての内部キッチンはこれを測定する方法、それに費やす金額、鉄を購入する、またはその逆に始まります、ソフトウェアのノブなどをひねります。 つまり、Highloadが終了する場所、Highloadが開始する場所の問題は、色の境界線をどこで描くかという問題です。 虹のスペクトルは連続的ですが、「これは緑、これは赤です」と言いますが、実際には「ここからは緑、ここからは赤」という境界線を明確に描くことはできません。 ここで、緑と赤は、色覚異常を除いて誰にとっても明らかです。 Highloadを使用して、すべてのものを使用します。 しかし、すべてのレポートで表明する小さな要件があります。「アプリケーションのパフォーマンスに関与したい場合、必要な場合は、すべてが上から下まで、スタック全体、つまり提案の仕組み、アプリケーションサーバーの仕組み、オペレーティングシステム、ハードウェア、イーサネットワイヤなど そして、このすべてがどのように機能するかを知っていれば、この場所で何かを達成し、いくつかの賞金を得ることができます。



-あなたとレシャは、ソフトウェアエンジニアリングとは何か、パフォーマンスエンジニアリングとは何か、そして違いは何かという話で、2011年から2012年にかけて有名な一連のプレゼンテーションを始めました。これは最初のスライドの1つです。 そして、ツールセットで？ Javaエンジニアとして、典型的なJavaエンジニアが持っているもの、そしておそらくJavaエンタープライズエンジニアでさえも大体想像できます。 そして、エンジニアのパフォーマンスのパフォーマンスツールとは何ですか？ どのようなパフォーマンスエンジニアツール、特に日常業務で使用していますか？



Kuksenko：バッシュ！ まず、タスクに依存します。 外部ベンチマークで作業する場合の古典的なツールセット-これは、しがみつくプロファイラーの一種です。 プロファイラーはどのようなものでもかまいませんが、それらはすべて同じであり、概してです。 また、VisualVMやMission ControlなどのOracle製品には利点があることは明らかです。



下位レベルに移動する必要がある場合は、かなり効果的なツールであるOracle Solaris Studio Performance Analyzer（長い名前）と呼ばれるものを標準として使用し始めます。 2つ目は、小さなこと、インタビュー、視点を理解するためのLinuxパフォーマンスです。 実践では、最近私は通常この束を使用していることを示しています。perfは概要を示し、Oracle Solaris Studio Performance Analyzerは多かれ少なかれ真剣に掘ります。 他のユーティリティは不要です。 たぶん、JFRはうまくいかないものを見ることがあります。 JFR、Recorder、Mission Controlですが、Javaのレベルを超えないものだけを見てください。



-アンプについてはどうですか、どう思いますか？



Amplifierを使用したことがないため、Amplifierについては何も言えません。 5〜6年前、単にIntel VTuneと呼ばれていたこの製品を使用しました。Intelハードウェアでの作業の観点からすると、Windowsプラットフォームは当時理想的でした。 しかし、その年には、Intel以外のハードウェアでの作業、およびWindows以外の何かでの作業に問題がありました。 現在、VTuneアンプの担当者は、さまざまな数字や数字などの膨大な数を表示するのをやめ、重要な問題を強調しようとしているという意味で、自動分析で非常に深刻な進歩を遂げたと聞きました。



-それは、実際には、解釈を与えることですか？



Kuksenko：はい、彼はすでにいくつかの会計を行って、発見した問題を分類しようとしています。 私はプレゼンテーションでこれを目の隅から見て、実際には使用しませんでした。



-つまり、これがどれだけ真実か、マーケティングはいくらなのか、はっきりしていませんか？



Kuksenko：プレゼンテーションを信じるなら、これは真実であり、うまくいくはずですが、これはIntelハードウェアの拘束力があります。



-10年前、ラップトップ、デスクトップ、サーバーなど、どこにでもあるようなAMDがありましたが、今ではAMDについて耳にすることが少なくなっています。 毎日の仕事でどのような種類のARMを扱っていますか。また、何か違いはありますか？



Kuksenko：日常業務では、ARMをゼロ回扱っています。 私は一度だけARMで実験を行いました。 プレゼンテーションの1つを行ったとき、ARMで並列測定を行うことに興味がありました。 次に、これらの測定値を取得し、Intelアーキテクチャと単純に比較しました。 したがって、ARMを実際に使用していないので、それについてはまだ何も言いません。プラットフォームは非常に有望であり、Intelをさまざまなニッチから非常に積極的に混雑させていますが、根拠はありません。



-約6％の成長について話したのは、Intelが少し停滞しているという感じだからです。 感覚は、パフォーマンスが成長していないということです。 エネルギー効率は向上している可能性があり、暗号化のような何かが現れますが、その成長は広範に行われているようです。 5年前のラップトップは、関連するパフォーマンスの観点からです。



Kuksenko：エンドユーザーが使用するパフォーマンスに関しては、まったく同じであることがわかりました 。 5年前にYoutubeで映画を見ることができたように、Youtubeで映画を見るようになったので、違いはありません。 5年前のように、あなたはTwitterに行ってメールを書いた。そして今。 違いに気づきません。 実際、ベースプラットフォームは長い間、エンドユーザーが必要とするパフォーマンスを達成してきました。 もちろん、あらゆる種類の3D、Blu-ray、超高精細画像が始まりますが、これはコンピューターのパフォーマンスの領域ではなく、別の領域です。 しかし、本当に、私の同僚のLesha Shipilevのおかげで、彼は最近、彼のTwitterで業界の回顧を評価しました。 彼は、10年前のインテルでの仕事から得たスコアをよく覚えているベンチマークを試したと書いています。 そして彼は、10年前にこのベンチマークがラップトップで10年前のサーバーマシンでの50倍高速になったことに注目しています。 10年間で生産性が50倍に向上するのは、ごく普通の進歩だと思います。



-それは、実際、開発がありますか？ これはどれほど重要ですか？ このベンチマークとは何ですか、例を覚えていますか？



Kuksenko：彼のことはよく覚えていますが、議論はしないと思います。 Alexei Shipilevにインタビューするときは、このベンチマークの代わりを書いたので、このベンチマークの関連性について彼に尋ねた方が良いと思います。



ひも



-文字列について話しましょう。 そこにもっとコンパクトに記録する方法に関連して、現在さまざまな研究がそこで行われていることは秘密ではありません。 近年、このクラスが変化し始めたことは秘密ではありません。 部分文字列（）の置き換え、およびJDK 7u6の内容など。 プラットフォームの基本クラスを変更するのはどれほど愚かですか？ このクラスでの作業は、他のクラスでの作業とどの程度異なりますか。一部のchangsetはどの程度複雑になりますか？ それは非常に目に見えるエリアであり、現在活発な作業が行われているのは驚くべきことだからです。



Kuksenko： 「ここで、ある種のチェンジログを考えて、さらに詳しく見てみましょう」という質問はありませんが、ここから得られる勝利の質問です。 そして、どのアプリケーションでもメモリの50％を占めることがわかっているクラスがある場合は、それ以上ではありませんが、それを使って何かをしましょう。 特に、古い開発、隠されていない実験があったので、それをする時です。



-なぜあなたは以前この分野で働いていましたが、今それを強化していますか？ 長年にわたって、皮ひもに関する多くの質問が蓄積されてきました。



Kuksenko：この分野で仕事があったとは言いません。 完了しました。 おそらく、それらは常に最後までもたらされたわけではなく、実験的なままでしたが、同時に遊びのレベルで利用可能でした。 ビジョンは、それがどのように行われるべきかを形成しました。 10個の使用パターンがある場合に最適化を行うのは非常に簡単で、誰もがこれらの10個のパターンにジャンプします。



座って、これら10個のパターンを解析し、それらの動作を最適化して、勝ちます。

クラスが千、百万通りの方法で使用され、この場所で莫大なエラーが発生した場合、マンションから何かを急いで書いたりしないことは明らかです。 ここでは、まず、これらのゲインがどのようになっているのかを確認する必要があります。悪化していない人にとっては、これは改善され、同時に何も壊れません。 これがすべてのアクション、すべての作業です。



Oracleは、JavaおよびSunの開発にかかる工数の最大コストが開発の分野ではなく、QAの分野であるという事実を決して隠しませんでした。



-今日、あなたの推定によると、パーソナリティに切り替えることなく、QA、Oracle Java、OpenJDKのJavaはどれほど強力ですか？ つまり、あなたはあなたの意見で、しばしば深刻な何かを見逃していますか？ それとも言うのは難しいですか？



Kuksenko：言うのは難しいです。 このエリアには大きすぎるので入らないようにしています。 私たちには素晴らしい専門家がいます。彼らはもっと良く反応すると思います。 QA-, .



— JDK 7 update 6 substring(). : , , , . : , ? , . , , -.



: -, , … -, , . , , : « JDK 7 Update 6, , , », ., , , Offset , , – , .



— ?



: – . , , , , , , . , , , - . , , « , - ». , , , , , , . , – , , . . , .



Stream API



— Java 8. Stream', Stream API, Bulk Data Operations, . ? . , , , , , – , ? Stream' - ?



: , , Java 8, Stream', JDK 9 . , , , , , JDK 8. Stream' , , , . - , .



. , , , , Stream API . , , .



— , Stream API (Collections) API?



: , Stream API API Stream API , , Stream . : , ? , . , , , , , .



, , , , , : 100 ( , — .. apangin ), , , 99%. 100 , . 10 , … .



— 100 – ?



: , . Stream API , . hotspot JDK. , , , , , , , .







— . , , , Oracle , Sun, OpenJDK, . , Oracle , , - , , , , , , , , - , . . – , , , . , , ?



: - , , . , 100 , , . , . , , , , , , , -, , , , . – , , , , , , , , , , , , Java, . , .



— , ?



: , .



— , , ?



: Oracle Labs, , High Performance, High Concurrency . Oracle Labs – , , , , , .



— , , . GC – , – , Stream' – , VM – , JIT – ...



: ? – . — . . computer science, .







— Java, , Oracle Java SE Performance Team. , , , .



: . , , JDK, , . : , . : , , - , . , , .



— – ?



: , .



— ?



: Lambda, Jigsaw, Application Data Sharing. String - . - G1 Garbage Collector.



— performance-, (, , )? , concurrency-interest , . community, ?



: : , . , , Hotspot, - , . - OpenJDK mailing list , . , Hotspot Class Libraries, , . , - , , , , , , .



— …



: , .



— , , , ?



: , , , - Hotspot, , , - , . Oracle, , , , , , , , , , .







— , ? - ? Java, - ?



: .



— ? , , , , Java – , , , . , ?



: . , - Highload, – . , , , . , a) , , b) , , c) , . , . , , . , , Java SE , 10 .



— , , ?



: , , . , , Garbage Collector Class Libraries, , . , - , , , . , . , .



— , Oracle Java , VM? , - , ?



: – . - , , - .







— , , , Java- Rocket Science, , , , , , Google V8, , .NET, ?



: .NET. . Google V8 – .



— , JVM- Dalvik . , – , VM . , Android', VM- ?



: – . , , , - . Java, .



— , - , , , , , - .



: . , .



— , , , .



: API , . , , API, , . , , , . API from scratch, , . .



JVM



— , … , – , - .



: . .



— Oracle ?



: -?



— ? 20 VM , . VM- Oracle JDK? .



: Embedded VM, embedded, , .



— Hotspot?



: Hotspot, Embedded Hotspot, .



— footprint - ?



: , .



— ARM, ?



: ARM VM ARM. , Hotspot. JRockit, - . , , , . , , -, , JRockit Java 6.



— JRockit?



: .



— 2010 – Sun Oracle, JRockit Hotspot, - , , , , ? ?



: Oracle, Oracle , . , . – .



— Hotspot, JRockit.



: .



— ? , , , , , , .



: , .



— , ? , .



: . , , , . . , « Hotspot JRockit», 70-80%, , . : « JRockit, Hotspot», – . : « JRockit Hotspot, ?». , , , , , , . , , Hotspot, QA (00:48:34), , JRockit Hotspot, .



— Metaspace, Flight Recorder Mission Control. , JRockit Hotspot?



: , , , , , , JRockit. 100% , …



— ?



: . , VM .



— , JIT-, C2-, , ? , JIT - .



: , , , JIT , JIT- C2. , - , , . -, , , . – . , , .



— ?



: , , . – -, . .



— ?



: , , , , . C C++ .



— ? Java?



: , Graal – , , , .



— , , , .



: . , Oracle. , GPU , . , – . , , , Hotspot, .

— GC. Shenandoah, RedHat . - , ?



: , .



— ? ?



: , RedHat Shenandoah Hotspot, - .



— , Garbage First Collector, , CMS Collector. , , , , ?



: , , . – «»



— Garbage First , , , , ?



: , Garbage First, , . Java One , Garbage First. Java One, . , , , : « , ?», .



, Garbage First , - . , , - . , Garbage First . , .

? -, CMS- , . , , : «, , , – ». , Garbage First , . , Garbage First, , – - . – Java 7 Java 8, Java 7…



— end of life… , .



: - . – .



— . , .



: : , , « . ? . ».



— , , , , - , , , . GC? , , , . Garbage First , . , . , . ?



: , , . , – «». , . 10 . , , , . , , , , «». , , , , , , . , , . Java Hotspot, Garbage Collector, , , - – , – , , , , .



— . , , . – Hotspot, GC, Runtime, , – , , -, , – , - , , , , . , GC – – , – .



: . , , , , , , - , , , , , - : « 60 /», . ?



— – ?



: . 60 /, 60 /, , ? , . , , , , , - , , CMS- , , -, , .



— , , ...



: . , « , . , ».



— ?



: .



— , , , , , , , «» , , , – - . , , , , , Runtime ?



: , -, , , Runtime , .



. , Runtime, , , , , , , . , 100 . , , : « , , , , , ». , , , , , , . , , , , . . , , - , – .



JPoint



— , JPoint . , . , , ? , ?



: - , . , , , , .



, «», , , , , , , - , .. , , , -. , - , , , . , , , , .



— , , , - ?



: , . , . , , 40% . , , , , , .







— - .



: , : , , , .



PS:

, , .

JPoint — .