「優れたシステムエンジニアになるには、5〜10年の経験が必要です」-JavaパフォーマンスチームのAlexei Shipilevとのインタビュー

明日から始まるJava会議Joker 2015を見越して、世界で最もクールで有名なパフォーマンススペシャリストの1人であるOracleのJavaパフォーマンスチームのエンジニアであるAlexei Shipilevとの大規模なインタビューを公開します。 そしてもちろん、素晴らしいスピーカーです。



アレクセイと詳細に話しました。

• Stringクラスの今後の変更。
• 実際に誰がオープンソースを開発するかについて。
• システム開発者とそのキャリアについて。
• 技術交換、「科学」および「製品」開発について。
• 低レベルのタスクの複雑さについて。
• Javaコミュニティの開発とベンチマーク戦争について。
• 可変対不変について
• 安全でないについて;
• JMH、ベンチマーク、および狭い専門分野について。

これが私たちの会話のビデオです。 1時間以上、道路で聞くことができます。







カットシーンの下にあるのは、ビデオが本当に好きではない人のための会話の書き起こしです。

文字列の変更について

-アレクセイ、パフォーマンスについてよく話していましたが、最近はストリングクラスをたくさんやっています。 この理由は何ですか？



-文字列の最適化を目的としたプロジェクトに参加しているため、パフォーマンスの観点から文字列についても説明します。 この領域には毎日多くの小さな最適化がありますが、2つの大きな変更を行っています。



1つ目はCompact Stringsです。 Javaアプリケーションにあるほとんどの文字列のシンボルは、ほとんどASCIIに適合します。 これは、文字列の各文字に対して、char仕様で要求されているように、2バイトではなく1バイトを使用できることを意味します。 現在、ストリング内、ストレージ内は文字配列です。 高度に最適化されており、人々は高いパフォーマンスを期待しています。 したがって、これらの行を圧縮するには、このStringの2つの表現を作成する必要があります。1つの表現は典型的なchar配列で、2番目の表現はバイト配列です。各バイトは特定の文字に対応します。 そして、リリース基準で書いたように、「非回帰」を提供する多くのパフォーマンス作業が必要です。 そのため、Java 8からJava 9に切り替えるユーザーは痛みを感じるだけでなく、この機能の幸福感とパフォーマンスの向上を体験できます。



また、「ライブラリ」がどのように機能するか、文字列連結で何をどのように行うか、ランタイムがこの全体をどのように処理するかについて、さまざまな感動的なものがあります。 一般的に、多くの小さな詳細があります。



-そして、まったく馬鹿ではない？ 文字列クラス-JDK全体を通過します



-バカ！ 実際、クラスライブラリチームのメンバーからの元の提案には、面白いコメントがいくつかあることがわかります。 1つは、JSR-166メンテナーの1人として知られているGoogleのMartin Buchholzからです。 マーティンはかつて「これは難しい仕事だ、幸運だ！」と言っていました。 2番目のコメントは私からのものです。精神のなかの何かです。「まあ、悪魔は知っているので、これができるとは信じていません。文字列はそのようなクラスです。 彼に触れるのは本当に危険です。」



今、私たちはこの変更、正確な測定を慎重にプロトタイピングし、これがパフォーマンスにどのように影響するかを理解し、適切なコード生成戦略を選択するのに6か月を費やしました...このすべての作業の後。 すべての長所と短所を知ることは助けになり、それですべてがうまくいきます。



-そして、コードのパフォーマンスを加速するために、文字列にあるchar配列に大胆に登った人たちは今どうなりますか？



-驚きが待っています。 仕様上、char配列が文字列内にあることを保証する人はいません。 ある種のパフォーマンスを勝ち取るために勇気を出した人は、最初はすべての変化に追随しなければならないという事実にすでに加入していると思います。



-そして、「パフォーマンスの低下なし」とは何ですか？ テストのセットはありますか、それを評価するための基準はありますか？



-これには正式で非公式の態度があります。 非公式の態度は、メジャーリリースが少なくとも最後のメジャーリリースと同じくらい遅く機能するという事実に慣れている大きなコミュニティがあるということです。 そうしないと問題が発生するため、新しいバージョンへの移行方法。 したがって、新しい機能を開発するときは、パフォーマンスに失敗するだけでなく、どこかで勝つ必要があることを覚えています。



そして、そのようなワークロードで非常に多くの割合でパフォーマンスを浪費できるかどうかを示す正式な基準があります。 しかし、これは開発チームの内部問題であり、OpenJDKではありません。 むしろ、態度はそれだけです-私たちは、コミュニティがJavaが退行しないことを望んでいることを理解しています。 また、Javaが退行しないようにします。 この暗黙の仮定に基づいて、開発が行われます。



-回線上の回線や回線が駆動されるエンタープライズサーバーの製造元と、何らかの形で大規模なベンダーと通信しますか？



-とても簡単です。 私たちは大企業で働いており、内部顧客がたくさんいます。 そして、彼らは十分です。 オープンソースは、ハッカー愛好家によって独自に開発された空中に浮遊しているようです...



通常はその逆です。 いくつかの内部的な理由で開発に資金を提供している大企業がいます。 OracleがJavaをSunから購入し、開発に投資し始めたのはなぜですか？



実際、プラットフォームに投資すると、開発組織に大きなボーナスが与えられます。 パフォーマンスの問題がある製品があり、実行時にローカライズされていることがわかっている場合は、開発者のところに来て次のように言うことができます。 すぐに修正してください。」 開発者は、このために給料が支払われていることを理解し、修理に行きます。

システム開発者とそのキャリアについて

「あなたは超有名な男です。」 きっとたくさんのヘッドハンターがLinkedInで毎日あなたに手紙を書いて、あなたを上回ろうとしています。 なぜあなたはまだOracleにいるのですか？



-ご存知のように、私は長い間この質問に自分自身で答えようとし、常に他の人に答えようとしてきました。 ブログや本を読んで、業界で製品層がどのように配置されているかを見ると、ハードウェア、オペレーティングシステム、ライブラリ、アプリケーションなどがあることがわかります。 そして、これらすべてのレイヤーの開発者の人口を見ると、逆ピラミッドになります。

以下は、低レベルの財団に関与している人々です。 そして、これらの人々は非常に少数です。 客観的な理由-入場の十分に高い閾値があるため、そこに合理的な何かをすることができるように多くの経験と良い教育が必要です。



-つまり、Intelプロセッサを改善するには、次のものが必要です...



-あなたは多くを学ぶ必要があります。 たとえば、Androidアプリケーションを作成するだけではありません。 優れたシステムエンジニアになるには、5〜10年の産業経験が必要です。 既にこの経験を積んでいる場合、このエコシステムでのあなたの場所はこの低いレベルにあるようです。 もちろん、このレベルから進んで、ある種のエンタープライズアプリケーションを作成できますが、これは、ここであなたの隣にいるすべての人々を置き換えて、すべてを掘り下げていることを意味します。 以下に大幅なスタッフ不足があります。 たくさんの仕事があります-ただ暗闇。 私は多かれ少なかれ、私たちができる仕事と必要な仕事の比率を評価しようとしています。 そして、この比率は1対10、さらには100です。



-つまり、人々は本当に十分ではありませんか？



-はい、これはJavaの機能ではありません。 これは、このシステムレベルの機能です。 人は少なく、多くの仕事があるので、興味深い面白いパズルがあります。 これにより、実行したいタスクを選択できます。 所有している100のタスクから、次のタスクを選択できます。

• a）コミュニティの利益。
• b）会社の利益。
• c）個人的な利益。

-一般的に、これは非常に興味深い質問です。お金の質問です。 通常、人が少ないほど、彼らはより高価です。 私の業界では、どういうわけかこれはすべて異なって配置されていると感じています。 だから？



-いいえ、システムエンジニアは高価です。 優秀なシステムエンジニアは非常に高価です。 そして最も重要なのは、供給が需要よりも実質的に少ないことです。 そして、競争が著しく少なくなります。 ガレージに座ってスタートアップを見て、次のガレージの誰かがまったく同じスタートアップのアイデアを思い付かないように祈って、そんなことはありません...



私の地域では、私のビジネスに似たものに携わっているすべての人を1つの手紙に数えることができます。 そして、特別な競争はありません。 ですから、同じJVMLSのような楽しい業界カンファレンスは楽しい光景です。



プログラマティックフォーラムを読むとき、たとえば、訴訟-「どの言語が優れているか」、「どのプラットフォームが優れているか」など。 そして、あなたがJVMLSにいるとき、「低レベル」で本当に働いている人々が彼らの隣に座っているとき、同意と相互理解があります。 すべてが同じボートにあるため、誰もが過度に過負荷になり、誰もが同様の問題を抱えています...



これはとても素晴らしい心理療法セッションです。 「胸をかかとで叩く」ことはなく、「私たちはよりよくやった、そしてあなたはすべて吸う」という主張はありません。 そこでは、当然、個人的な好き嫌いを法とする理解と友愛があります。



-そして、現代の学生や最近の卒業生はどこでシステムプログラミングを学ぶことができますか？ 現代の大学では、彼らは80年代の教科書やパターンで教えていると感じています。



-基礎科学は基本的なままであるため、これはそれほど悪くありません。 そして、それは市場の状況に依存しません。 古典的な本、大学のプログラムで古典的になった教科書があります。 ソビエトやロシアの大学にはないかもしれません。 スタンフォード大学やMITのプログラムを受講して、彼らが読んだ教科書に従って、何を読んでいるかを見ることができます。



-たとえば、 Computer Science 101 ？



-Computer Science 101は通常の入門コースです。 そして、彼らのための専門的なコースと教科書があります。 オンラインでコースを見る方法がない場合は、教科書を見つけることができます。これは通常、古典的な作品です。 そして、それから直接学びます。 ロシアでは、これを行う学校をかなり知っています。 たとえば、ノボシビルスクでは、かつてアカデミーのエルショフがまだ行っていた学校、編集者の学校がありました。



-現在の形式でExcelsiorと関係がありますか？



-エクセルシオールは、十分な専門知識を持つ人々がいたからこそ生まれたと思います。 彼らは退屈して、これらの種類の製品を作ることができます...



そして、教科書の後に練習が必要な場合、この種のプログラミングに携わっているほとんどの企業には、インターンやジュニア向けのオープンなポジションがあります。 実際には、教科書に書かれていることと実際に起こっていることの違いを感じることができます。



「あなたと同じくらい起きましたか？」



-はい。 学生の頃、Intelのチームでインターンを取得し、Javaランタイムに従事していました。 一方では、大学で勉強し、ムクニック、 ヘネシー・パターソン 、 タネンバウムなどの本だけを読みました。他方では、教科書からアイデアを移そうとする本物の製品を職場で持っていました。 または、プロジェクトを読んで、これが2か月前に教科書で読んだものであることを理解してください。 これが理論と実践です。



これは、「フィズテックシステム」と呼ばれるものに似ています。学生が最初の3つのコースの基本的な基礎（数学、物理学、コンピューターサイエンス）を与え、その後、それらが科学研究所、工業生産、スーパーバイザーは実際の科学的な仕事をします。



私たちの業界では、効果的なツールはほぼ同じです-学生は大学で基盤を取得し、実際に知識を活用するために組織に参加する必要があります。 私が理解しているように、Yandex、ABBYY、Sberteh、その他の企業はまったく同じ方向に進んでいます。 彼らは学生を連れて行き、彼らを訓練したいと思っています。



-問題は既知です。 業界の赤字は、学術機関が人員を管理するよりも速く成長しています。 業界の成長率は年間約15％です。 そして、それはたくさんあります。



-それにもかかわらず、私は応用ソフトウェアの業界とシステムソフトウェアの業界を共有します。 アプリケーションソフトウェア業界の規模は、市場で起きていることに応じて拡大または縮小しています。特定の分野やスタートアップに投資する投資家の意欲です。



そして、私の知る限り、これはすべてが機能する基盤であるため、システムレベルのプログラミングに対する需要が常にあります。 プラットフォームを作る人は常に必要なので、需要に大きな変動はありません。

技術交換、「科学」および「製品」開発について

-そして、Javaは他の言語のテクノロジー、機能、およびアイデアを積極的に活用していますか？



-ランタイムなどのテクノロジーでは、開発の大部分がアカデミーまたはセミアカデミックR＆Dラボで行われ、科学的記事や「このアイデアをどのように試したか」に関する技術レポートを公開しているため、「tyry」とは呼びません。 焦げた/焦げていない。」 ランタイムを実装する人々は次の記事を読みます。「ええ、それは私たちに合っています。一緒に実装してみましょう。」 異なる言語のランタイムを作成する人々が1つの記事を読むことは明らかです。 この種の開発が行われる主な基盤は、半科学半工業用合金の研究開発です。



-あなたは今ロシアにそのような研究所を持っていますか？



-そのような作業には、独自のスキルセットが必要です。 ロシアに本拠地を置く完全な研究室ではなく、そのような開発に参加している個々の人々を知りません。

業界が資金提供している研究開発研究所について話している場合、研究と応用実施との境界線は非常に不安定です。 多くの場合、これらは同じ人です。



-多くの工学的問題は最終的に科学者によって解決され、多くの科学的問題はエンジニアによって解決されることが知られています。 応用数学では、これは常に起こります。



「Oracle Labsには、科学志向で、製品から分離してソリューションを試す人がいます。」 その結果、技術レポートまたは記事が作成されます。 そして、製品を改善しようとして、そのような科学記事からアイデアを引き出す製品チームがあります。 同時に、非常に多くの場合、いくつかの決定が製品自体の内部で生まれ、それを認識してスキャナーを開発しようとします。 これはそのような共生プロセスです。 これが、研究開発が大企業によって資金提供されている理由です。



-つまり、企業がこれに投資しているという感じですか？

-これは感情ではなく、ただ見ているだけです。

オープンソースを動かす人について

-オープンソース、特にJavaの問題に少し戻ります。 一方では、ベンダーによって開発および移動されます。 一方、Oracleは、組織とは別に存在するコミュニティです。 Javaエコシステムには、同時実行性が大きく影響するDoug Leeがいますが、Oracleでは機能しません。 エリアリーダーが組織外にいる場合、この状況はどの程度ユニークですか？



-ユニークではありません。 たとえば、代替アーキテクチャのポートに関連付けられているものは、Oracleによって積極的に開発されていません。 たとえば、ARM64は主にRed Hatによって起動されます。これは、Red Hatがこのことに関心があるためです。 条件付きIntel、条件付きAMDもまだ存在し、コードジェネレーターの改善にも関心があります。



「まったく見えますか？」 IntelとAMDの人々があなたのところに来ますか？彼らは「ここであなたは私たちの最新のプロセッサのための最適化がある」と言っていますか？



「彼らはそれを言うことができません。」 彼らは言います：「見て、このように共同生成すれば、もっと良くなる。 これがパフォーマンスデータです。」 そして、コンパイラーがこの変更が本当に成功したと言うなら、これはすべて受け入れられます。



-そして、Java組織の何パーセントの人が低レベルのタスクに従事していますか？



-私は数えませんでした。 失礼な場合は、JDKの活動の小さな分野で多かれ少なかれ頻繁に接触する人は、おそらく50人くらいだと思います。 率直に言って、他の機能に関与している人の数は知りません。 もちろん、ワークチャートを見て評価することもできますが、開発を行う人は多くいます。



-数百人？



「何百、2、3、と思う。」



-あなたの意見では、低レベルの作品は大部分の人々ですか？



-はい、素晴らしい。 それでも、このタスクは非常に複雑であるため、これらの人々はまだ十分ではありません。

低レベルのタスクの複雑さについて

-そして、なぜタスクが難しいのですか？



-主に、非常に多くの可動部品があるため。 知っておくべきことがたくさんありますが、そのために準備する必要があります。 たとえば、コンパイラを作成し、プロセッサのエラーを知る必要があります。 まず、それらが存在すること（そして多くの人にとっては、プロセッサにバグがあるということです）を知るには、これらのバグを調べて、コンパイラが常に非標準の動作に罪があるとは限らないことを理解する必要があります。 あなたが今修正しているバグは、あなたが型の責任を負う部分までに作られた過去のコード変換のある種の大きな干渉に関係しているかもしれないことを知って、可能になり、理解するべきです。 このスタックを詳細に知る必要があります。



Ranthime自体は、コンポーネントを大きなセルに分離できる製品ですが、実際、これらのコンポーネントは互いに非常に密接に関連しています。 バグを修正したい場合、これは多くの場合、異なるコンポーネントのバグを修正する必要があることを意味し、パフォーマンスに取り組んでいる場合、間違いなく同時に多数のコンポーネントに関与します。



パフォーマンスパッチが1つのファイルで5行かかる場合は、子供の頃はうれしいです。これは、パフォーマンスのすばらしい変更であり、明らかに正しくて役立ちます。 しかし、大きな、優れたパフォーマンスの変更には、通常、大きな製品全体の小さな場所すべての変更が必要です。 したがって、この製品を知っておく必要があり、製品は巨大です。



-これは、設計が不十分であることを意味しますか？



-いいえ。



「なぜそんなことが起こるのですか？」 局所性は、優れた設計の基準の1つであると考えられています。問題を排除するために、10か所ではなく1か所で掘りたいと考えています。



「それはすべて紙の上でうまく機能します。」 実際には、次の2つのことが起こります。まず、パフォーマンスを追求し始めると、抽象化がいくつかの別々の場所で行われることが必要であることがわかります。 次に、バグが発生します。



プラットフォームについて、プラットフォームがどのように動作するか、たとえば「移動」と言ったときにプロセッサがレジスタからレジスタへ正確に送信することについて知っています。 この仮定に頼れば、美しいコンパイラを書くことができますが、突然、プロセッサにエラーがあることがわかります。 これを修正するにはどうしますか？ 松葉杖をコードジェネレーターに挿入します。 それは実際的な問題に対する実際的な解決策だからです。



-クライアントにファームがあり、ファームに1000個のプロセッサが破損している場合...



-HotSpot JVMのソースを読むと、そこにさまざまな恐怖があります。最も重要なことは、これらの恐怖の多くが署名されていることです。 たとえば、「このコードはいですが、何らかの理由でwrittenい」という精神でコメントに出くわすことがあります。



-そして、この規則は一般的に守られていますか？



-通常は尊重されます。 そのようなバグを修正するとき、あなたが実際にそのようなイエズス会のことをした理由を書くことが期待されます。



そして、そのような場所では、通常、次のようなものが書かれています。 しかし、この場所での変換により、このようなグラフが作成されるため、ここでは別の方法で記述することはできません。 一般に、このリンクからバグを読み、読んでください。そこには、なぜこのことがうまく機能しないのかについての15ページの叙事詩があります。 それは非常に小さな詳細です。

ハードウェアトランザクションメモリ

-エラータとプロセッサに戻る。 HerlichとShavitの古典的な本には、ハードウェアトランザクションメモリに関する別の章があります。 トランザクションメモリとは何かをもう少し教えてください。



-トランザクションメモリの合理性は、メモリ内のいくつかの場所で調整された変更を行う必要がある場合に同期の問題があることです。 メモリーの1つの場所でアトミックな変更を行う必要がある場合は、アトミック操作を行うだけです。



別のことは、いくつかの読み取り、複数のレコードを作成する何らかの自明でない変換を行う必要がある場合、このブロック全体をアトミックにする必要があることです。 「ここでロックを取得し、カーペットの下ですべてを行い、ロックを解除しました」とロックを作成できます。これは機能的な観点から機能します。



別のことは、これらのロックが何になるのかということです。 競合！ したがって、「トランザクションの開始時に、私たちが持っていたものを覚えておいて、カーペットの下でマシンの状態で何かを行い、トランザクションをコミットすると、このマシンのすべての状態が他の全員にアトミックに表示される」というハードウェアメカニズムを取得したい「。 これはすべてトランザクションです。 私は個々の記録や測定値を持っているだけでなく、この状態をすぐに公開するか、まったく公開しないトランザクション全体を持っています。



-これは、リンクを変更するCASに似ています。



-はい、CASで実行できますが、そこで問題が発生します-CASベースのラッパーをそこで実行する必要があります。ここでは、ベアメモリを使用するかのように実行できます。



-そして、ラッパーは、割り当て、メモリトラフィックを伴います...



-はい。 HTMは、ラッピングオブジェクトを不必要に作成することなく、これらすべてを回避するのに役立ちます。 「今、トランザクションを開始し、メモリ内に10のストーリーを作成し、トランザクションをコミットし、これらの10のストーリーをすべて表示するか、表示しないようにしています」と言うことができます。



-データベースはどうですか？



-はい。 したがって、このようなメモリはトランザクションであるため、トランザクションメモリと呼ばれます。 ただし、このためにはハードウェアサポートが必要です。 トランザクションメモリのソフトウェア実装が既にあったためです。



ソフトウェアの実装-それらは非常に遅いため、ハードウェアのサポートが必要です。 「トランザクションを開始する」というコマンドを実行すると、その時点でマシンが「OK、このトランザクションの開始後に行われたすべてのことはまだ誰にも見えないが、コミット時にすべてを公開する」と言うことをハードウォーに説明する必要があります。



-「トランザクションを開始する」などの指示があるのは、アセンブラーコードに正しいですか？



-xstart。 次に、xcommitと言うと、ハードウォーはトランザクションのコミットに成功したか失敗したかを通知します。 xabort。 すべてが完璧です。 誰もがハードトランザクションメモリが表示されるのを待っていました。 Azulは長い間Vegaでトランザクションメモリを作成してきましたが、彼らは言うように、JavaでこのHTM hadhメモリを活用することで成功を収めました。



-今だけベガが死んだ。



-ベガは死んだものではありません。 CTO Azul SystemsのGil Tene氏は、x86_64のパフォーマンス特性がVegaに非常に近くなり、Vegaをサポートすることは経済的に不採算になると述べました。



-はい、鉄のサポートは高価です。



-はい、なぜですか？ 工場を持っており、すべてを小額で販売しているハードウェアベンダーがある場合。 自社のマイクロプロセッサの生産コストと比較すると、これらは単なるペニーです。



そして、誰もが幸せで、自分の小さなプロトタイプを作り始めました。 私たちも。 JavaでHTMを使用できる自然な場所は、たとえば2、3、4の店舗がある同期化された些細なブロックがある場合です。 入力でトランザクションを開始し、出力では省略します。 セマンティクスはまったく同じです。



-つまり、JITは突然、今ではロックを使用せず、そのようなcなトランザクション命令を使用していると言いますか？



-そして、それはほぼ8でも行われました。 しかし、突然、青からのボルトのように、一部の男がHaswellのこの非常にHTMのハードウェア実装にバグを発見したことが判明しました。 そして、私が理解しているように、このバグはすでにシリコンにあったので、修正することはできません。



-それは、シェムカ曲線ですか？



-はい。 そのため、Intelは皆に謝罪し、HTMがオフになっているマイクロコードアップデートをリリースしました。 HTMはオプション機能であり、それを使用するには、プロセッサフ​​ラグを確認する必要があります。 プロセッサマイクロコードのアップデートをリリースできます。これにより、「サポートしていません」と表示されます。 これはハードウェアメーカーの間違いですが、そのようなことは時々起こります。



-Pentium IIIでは、プロセッサの有名なリコールがありました。 どうやら、これは10年ごとに発生します。



-私の意見では、Pentium IIIではなく、Pentiumだけでした。 私のような多くの人々がTSXを試すためにHaswellを購入したという事実にもかかわらず、それから突然あなたのプロセッサがカボチャに変わったことが判明しました...



-最後にスコアまたはマイクロスコアを更新しましたか？



-自動的に更新されます。



「これはどうしてですか？」



-起動時にオペレーティングシステムを更新します。 彼女には、マイクロコードが入っている特別なバッグがあります。



-つまり、このBIOSを更新する必要はありませんか？



-私はそれがBIOS / UEFIを介して行われることを理解しています。オペレーティングシステムはプロセッサに「これが新しいマイクロコードです」と言います。



-誰もがすでにこれを持っていますか？



-はい、メモリを損傷するバグがあったため、これは機能の点で通常の戦略です。 遅くなりますが、より正確です。



-IntelのHTMに関する将来の計画は何ですか？



-彼らは新しいリビジョンを持っています。 私の意見では、スカイレイクと呼ばれます。 Haswellは「トランザクションメモリストレージをサポートするプロセッサ」と宣伝され、Skylakeは「最終的にトランザクションメモリを正しくサポートするプロセッサ」と宣伝されました。 今回はどうなるか見てみましょう。

Javaコミュニティの開発とベンチマーク戦争について

— Sun , , Sun. Oracle , . , Oracle, , Java-. ?



— , . Sun, , , , . , - JavaOne, Sun , , Sun , - . , . ?



— 5 .



— ?



— 2011 .



— Oracle Sun?



— 2009-2010 .



— . Oracle, Sun, : «, , . , JDK 7 JDK 7, ».



— , .



— , Sun, .



— Intel, Harmony, . . JDK, -.



-はい。 OpenJDK 2007 , Harmony 2004 2008. , . , JVM.



Oracle, JRockit , . IBM, J9. SAP , JVM. , .



«-». Java , , , . , .



- — - , , . これは正常です。 -, , , , . , HashMap' , . , , , .



, , - , . OpenJDK - . . , - , , . .



— OpenJDK ?



— GCC, LLVM . , , . , , , . , , OpenJDK .



. , Sun Oracle. . , , . , - , — . , LinkedIn, Twitter . , , , .

— immutable-. , , GC . immutability ? ?



— . , . — . — . , . , , . , by construction , , , , - .



, — . , , , , Scala . , , , , — . : « Scala , , , . , . , » — .



Java . Java, - . , , - , Unsafe … — , . , . , . , «». , , , , — .



— , . Java Tech Days 2011 , , . , immutability City Legend , , …



— . « — , CAS — ». «Java – , Scala – ». . , - — , , . , , , .



, , , , . , , , , . , , , , . . , , , , .



, , , , 100% . , , , ..



, , — , « , ». いや , «», «». , – «» «»? . , , «» «». . ( , , ) .

Unsafe

— Unsafe. . ?



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



, , , , , , , .



, Unsafe . , , . , - unsafe — . Java , .



StackOverflow : «, ! , !». . , Javac , API … «» , , - !



, , Unsafe, - . , JDK. , API , , API , . : « -, ? 8 , , , , , ».



, , . - , , , , . — , . — , , . , , .



— , 2 , . -, , Java . , «Java 8» — , «JDK 8» – . -, , . Sun Oracle, « »?



— , « »? javac : «sun.misc.Unsafe is proprietary API and can be removed in future release». Release Notes , , sun.misc. , API, , . Oracle , Unsafe , API. , unsafe , , , unsafe, fallback', unsafe — .



— Unsafe . - , , , , , Hazelcast. , , … , . , — . , …



— , . , Hazelcast , Oracle, sun.misc.Unsafe , Joker, : « , unsafe!». , Unsafe . , , - -.



, . , , , , , API, . , . , API , .



— . , , , , . – … , -, - .



— , Mechanical Sympathy Unsafe. , : «, . , , API. , -, API, , -, ».



: , ? , API , , API , . API, , - . , API, «» .

JMH、ベンチマークおよびナロースペシャライゼーションについて

-それが問題です。 過去3年間、 Java Microbenchmark Harness （JMH）を積極的に開発しています 。 あなたが行うほとんどのコミットは、これがほとんどあなたのプロジェクトであり、現在はOpenJDKの後援の下にあります。 だから？



-これは、パフォーマンスチームがサービスを提供するプロジェクトです。



「そして彼には1つの問題があります。」 「これはそれより速いです。 そして、これが証明です」-これは証明ではなく、分析はそこで終わりません。 この周りのほとんどの人は単に理解していないようです。



-JMHの場合、ストーリーは次のとおりです。 あなたは常に自分自身に質問する必要があります-誰が恩恵を受けます。 パフォーマンスチームがJMHを行うのはなぜですか？ 彼女は私たち自身の活動を促進するためにそれを行っています。なぜなら、私たちには必然的にベンチマークにつながる研究があるからです。 この調査を行うにはツールが必要ですが、これはすべてツールに限定されません。 実験から得られる主なものは数字ではないからです。 あなたができる主なことは、数字から知識を引き出すことです。 原則として、多かれ少なかれ信頼できる知識を抽出するためには、理論のシステムが必要です。それぞれの理論はこれらの実験によって確認されなければなりません。 これには新しいものは何もありません-あなたは科学の哲学を取り、それはまったく同じです。



製品に関するパフォーマンスは、自然に関する科学者のようなものです。 高レベルのモデルを構築し、実験を通じてこれを行います。 JMHは実験を行うのに役立ちます。このフレーズの主な言葉は「ヘルプ」です。 しかし、あなたのために実験しないでください。 時間を節約し、実験の非自明な特定のものに対処するために、ベンチマークの明らかな熊手に踏み込まないようにするのに役立ちます。 だから、すぐに書くことができます[開始-約。 赤]ベンチマーク、このベンチマークを正しく記述する方法を理解するために残りの時間を費やします。 そして、例えば、デッドコードの除去で愚かな間違いを修正しようとして何時間も費やさないでください。 それが目的です。



各実験で解決する必要がある光の問題を解決するのに役立ちます。 特定の実験の特定の問題を解決する助けにはなりません。 分析は、このデータからどの洞察を提供できるか、この洞察を信頼できるかどうか、この洞察が知識の一般的なシステムのどこにあるかを理解するために必要です。



あなたがブログを書くとき、あなたはいくつかの機能のベンチマークを作成するので、私たちはしばしばこれを罪にします-そして、私たちは特にこの機能を対象とする実験を示します。 実際、この実験の背後にはこれらのリンクのチェーンがまだあります。 たとえば、このハーネスはこのマシンで正常に動作すること、このマシンを較正したこと、サーマルシャットダウンに陥らないことを知っています。 または、テストへのそのようなアプローチが機能することを知っています-個別に検証しました。 原則として、これはブログに書くこともできますが、それはブログではなく、今行っている実験が信頼できることを確認するために、以前にどの段階の実験を行ったかについての本全体になります。 ベンチマークを配置し、デフォルトでベンチマークが正しいと仮定することはできません。 これは起こりません。 ベンチマークは、あなたが既に知っている他のすべてと結びついて洞察を与える場合にのみ正しいです。



-今、何が起こるか見てみましょう。パフォーマンスについて学ぶ必要がありますが、私はこれであまり大きなドックではありません。 たとえば、特定の当局に言及します。 ベンチマークを実行し、測定し、パフォーマンスモデル、具体的な指示についての仮説を立てています。 アセンブラーのリストを取得し、そこにあるアプリケーションからこれらの指示を見つけます（または見つけません）。 秘trickは次のとおりです。このアセンブラーリストでどのような命令を探すべきかを理解するには、背景が必要であり、JMHを使用せずに同じ問題を解決できる必要があります。 だから？



-理解できない複雑なトピックの質問への回答が必要な場合は、このトピックを理解している人を見つけて尋ねる必要があります。



私の会社は1つの簡単なことを教えてくれます。たとえば、法的質問で手紙に答えて「私は弁護士ではありませんが...」と書き始めたら、この手紙を閉じて電話を取り、実際の弁護士に電話しなければなりません。この質問に対する正しい答えを知っている人。 パフォーマンスとまったく同じストーリー。 あなたは言うことができます：「もちろん、私はパフォーマンスアーティストではなく、このことで大きなドックではありませんが、パフォーマンスデータはこれを示しているようです。」 ただし、現時点では、次の2つのいずれかを実行する必要があります。パフォーマンスアーティストになり、これらのデータを通常どおりに解釈するか、この問題を理解している人に意見を求めます。



これが、パフォーマンスに真剣に投資している大規模な組織にパフォーマンスチームがある理由の1つです。 彼らはそのような質問に答える方法を知っている人々を保存するからです。 彼らが非常に賢いからではなく、経験、知識のシステムがあるからです。 彼らの仕事は、この一般的な知識に留意することです。 そして、私は目を閉じて、このデータを見て、彼らは私の仮定を確認します-これは確認バイアスです。



たとえば、どちらのアプリケーションサーバーが優れているかは推測しません。 私はこの質問に対する答えを知りません、オレンジのブタのように、私はこれを理解します。 もちろん、私はアプリケーションサーバーを使用しましたが、そこには多くの明白でないことがあります。 そして、これを煮詰め、そこで何が起こっているかを知っている専門家がおり、彼らはアドバイスを求めることができます。 そして、私にとっては、例えばブログに書くのは虚栄心の高さになるでしょう。「しかし、Glassfishで何か、Weblogicで何かを立ち上げました。Glassfishはそのような実装で落ち、Weblogicはそのような実装で落ちました。 そして、これから、Weblogicの方が優れているか、Glassfishの方が優れていると思います。」 まあこれは愚かです！



いくつかの断片的な情報によると、私は理論的には何十年もの間得たはずの膨大な知識を推定しようとしています。 したがって、できることの最大は、答えが必要な分野の専門家になるか、この分野の専門家に尋ねることです。 それ以外はすべて不安定な土地です。