LMAXのチームがJavaを使用し、GCを一切犠牲にしないようにアーキテクチャを設計したのはなぜですか？
LMAXのチームが LMAX Disruptor in Javaを設計しましたが、すべての設計でGCの使用を最小限に抑えていますか？GCを実行したくない場合は、なぜ使用するのですか？ガベージコレクションされた言語？
彼らの最適化、ハードウェア知識のレベル、そして彼らが置いた考えは素晴らしいですが、なぜJavaなのでしょうか。
私はJava=などに反対しているわけではありませんが、なぜGC言語ですか？GCなしでDや他の言語を使用しませんが、効率的なコードを許可しますか？チームが最もよく知っていますか？ JavaまたはJavaには、私には見られないユニークな利点がありますか？
彼らが手動のメモリ管理でDを使用してそれを開発するとします、違いは何でしょうか？彼らは低レベル（すでにそうであるレベル）を考える必要がありますが、ネイティブであるため、システムから最高のパフォーマンスを引き出すことができます。
巨大パフォーマンスの最適化と完全に安全をオフにするの違いがあるため、
GCの数を減らすことで、フレームワークの応答性が向上し、（おそらく）より速く実行できます。現在、ガベージコレクター用に最適化しても、ガベージコレクションを実行しないということではありません。それは彼らがあまり頻繁にそれをしないことを意味し、彼らがそれをするとき、それは本当に速く走ります。これらの種類の最適化は次のとおりです。
- 小さな使い捨てオブジェクトを使用して、サバイバースペースに移動するオブジェクト（つまり、少なくとも1つのガベージコレクションを生き残ったオブジェクト）の数を最小限に抑える。サバイバースペースに移動したオブジェクトは収集が難しく、ここでのガベージコレクションは、JVM全体をフリーズすることを意味する場合があります。
- 最初から多くのオブジェクトを割り当てないでください。 若い世代のオブジェクトの割り当てと収集は非常に安価であるため、注意しなければ、これは逆効果になる可能性があります。
- 新しいオブジェクトが古いオブジェクトを指していることを確認し（逆ではない）、若いオブジェクトを簡単に収集できるようにします。それらを保持する原因となる参照がないためです。
パフォーマンスを調整するときは、通常、実行頻度の低いコードを無視しながら、特定の「ホットスポット」を調整します。 Javaでこれを行う場合、タイトなループで実行される領域に対して非常に注意深く最適化しながら、ガベージコレクターに暗いコーナーを処理させます（大きな違いはないため）。したがって、次のことができます選択最適化する場所と最適化しない場所。したがって、重要な場所に努力を集中できます。
ここで、完全にガベージコレクションをオフにすると、-できません選択できます。 everyオブジェクトは常に手動で破棄する必要があります。そのメソッドは1日に最大1回呼び出されますか？ Javaでは、パフォーマンスへの影響はごくわずかであるため、そのままにしておくことができます（毎月フルGCを発生させても問題ない場合があります）。 C++では、まだリソースをリークしているため、あいまいなメソッドにも注意する必要があります。したがって、リソース管理の料金はアプリケーションのevery、single、partで支払う必要がありますが、Javaでは集中できます。
しかし、それはさらに悪化します。
バグがある場合、月曜日の満月にのみアクセスされるアプリケーションの暗いコーナーで言ってみましょう。 Java安全性が強力に保証されています。「未定義の動作」はほとんどありません。何かを使用すると、例外がスローされ、プログラムが停止し、データの破損は発生しません。あなたが気付かない限り、何も悪いことが起こらないことを確認してください。
しかし、Dのようなものでは、不正なポインタアクセスまたはバッファオーバーフローが発生し、メモリが破損する可能性がありますが、プログラムはそれを認識せず（安全をオフにしたか、覚えていますか？）、正しくない状態で実行を続けます。データ、そしていくつかのかなり厄介なことをしてデータを破壊します、そしてあなたは知らないです、そしてさらに破壊が起こるにつれて、あなたのデータはますます間違って、それから突然それは壊れ、そしてそれは生命に関わるアプリケーションにありました、そしてロケットの計算で何らかのエラーが発生したため、ロケットが機能せず、ロケットが爆発し、誰かが亡くなり、あなたの会社はすべての新聞の最初のページにあり、上司は指を指しますあなた「あなたは are パフォーマンスを最適化するためにDを使用することを提案したエンジニアですが、どうしてあなたは安全性について考えていませんでしたか？」。そしてそれはあなたのせいです。 あなたあなたの愚かな演技で人々を殺した。
OK、OK、ほとんどの場合、それはそれよりはるかに劇的ではありません。しかし、ビジネスに不可欠なアプリケーションや単なるGPSアプリ、あるいは政府のヘルスケアWebサイトであっても、バグがあるとかなり否定的な結果をもたらす可能性があります。それらを完全に防ぐか、または発生時にフェイルファストする言語を使用することは、通常、非常に良い考えです。
安全装置をオフにするにはコストがかかります。ネイティブになることは必ずしも意味がありません。少し安全な言語を最適化する方がはるかに単純で安全な場合があります。それは、足元で大成功を収めることができる言語にオールインすることです。多くの場合、正確性と安全性は、GCを完全に排除することで廃棄する数ナノ秒よりも優先されます。 Disruptor canはこのような状況で使用されるため、LMAX-Exchangeは正しい呼び出しをしたと思います。
しかし、特にDはどうですか？暗いコーナーが必要な場合はGCを使用し、SafeDサブセット（編集前は知りませんでした）が未定義の動作を削除します（使用することを覚えている場合）。
その場合、まあそれは成熟度の単純な問題です。 Javaエコシステムは、よく書かれたツールと成熟したライブラリで満ちています（開発に適しています）。Dよりもはるかに多くの開発者がJavaを知っています（メンテナンスに適しています）。金融アプリケーションと同じくらい重要なものに対して、あまり人気のない新しい言語を採用することは、良い考えではありませんでした。あまり知られていない言語では、問題が発生した場合に役立つものはほとんどなく、見つけるライブラリは、彼らはより少ない人々にさらされたので、より多くのバグを抱えています。
したがって、私の最後のポイントはまだ保持されています。悲惨な結果の問題を回避したい場合は、安全な選択に固執してください。 Dの人生のこの時点で、その顧客はクレイジーなリスクを取る準備ができている小さな新興企業です。問題に数百万ドルの費用がかかる可能性がある場合は、 イノベーションの鐘型曲線 に留まるほうがよいでしょう。
この質問は、誤った前提を事実として述べ、その誤った前提について議論します。
これを掘り下げてみましょう。「すべての設計ポイントがGCの使用を最小限に抑える」-単に真実ではありません。ディスラプターの革新は、GCとはほとんど関係ありません。ディスラプターが実行するのは、その設計が現代のコンピューターの動作を巧妙に考慮しているためです。議論についてはCliff Clickの講演 http://www.azulsystems.com/events/javaone_2009/session/2009_J1_HardwareCrashCourse.pdf を参照してください。
LMaxがAzulの顧客であることはよく知られています。 175GBのヒープがあっても、Azul GCを使用すれば問題は発生しないことを私は直接知っています。
Javaで書かれている理由は、彼らがJava社内に専門知識を持っているためであり、おそらくC++の前に（まだ活発に開発中ですが）書かれているためです） C++ 0x/11と一緒に動作しました。
彼らのコードは本当にJava名前でのみです、彼らはSun = misc.Unsafeをかなり使用しています=Javaのポイントを打ち負かしており、安全性はおそらく私はDisruptorのC++ポートを作成し、それがJavaコードよりも優れています）（JVMの調整に多くの時間を費やしませんでした）。
そうは言っても、妨害者が従う原則は言語固有ではありません。ヒープから割り当てまたは解放する低レイテンシのC++コードを期待しないでください。
Javaを構文言語として使用し、そのJDKライブラリを回避する場合、コンパイルされた非GC言語と同じくらい高速になる可能性があります。GCはリアルタイムシステムには適していませんが、 Javaでシステムを開発し、ゴミを残さないようにします。その結果、GCがトリガーされることはありません。
Java言語とプラットフォームにはC/C++よりも多くの利点があると考えており、超低レイテンシJavaこの記事では、そのための手法について説明します GCを使用しないJava開発 。
低レベルだと思う
上記はあなたが探している答えの半分になります。 別の半分を見つけて、推論を LMAXブログ よりも遠くなく完了することができます。
非常に効率的ですが、失敗するのは非常に簡単なので、多くのエラーが発生する可能性があります...
LMAX開発者が認めているように、そのようなコードは、たとえJavaであっても、開発、理解、デバッグが非常に難しい場合があります。 Wikipediaの記事 低レベルのプログラミング言語 で指摘されているように、現在の位置よりもさらに低いレベルに移動しても、この問題はさらに悪化します。
低水準言語で書かれたプログラムは、非常に速く、非常に小さなメモリフットプリントで実行できます。高水準言語の同等のプログラムは、より重いものになります。低レベル言語は単純ですが、覚えておかなければならない多数の技術的詳細のために、使用が難しいと考えられていますです。
比較すると、 高水準プログラミング言語 は、コンピューターアーキテクチャの実行セマンティクスをプログラムの仕様から分離します開発を簡素化する ...
LMAXは、高性能のスレッド間メッセージングライブラリです。
役立つためには、他の誰かがコードを記述して、各スレッドが役立つ作業を行うようにする必要があります。コードがJavaまたはC＃である可能性が最も高いため、それらとうまく連動する言語の選択肢がほとんどないことを考えると、.
スレッドモデルが定義されていないため、ユーザーを単一のOSに制限しない限り、CまたはC++の使用は適切なオプションではありません。
最近のJavaは、多くのソフトウェア開発の標準となっているため、特に理由がない限り、Javaを選択する傾向があります。 （ローマにいるときは、ローマ人として行う…）
Java（またはC＃）での高性能ソフトウェアの記述は、要点を証明するためによく行われます…