LMAXのチームがなぜJavaを使用し、GCを避けるためにアーキテクチャを設計したのですか？

LMAXのチームがJavaでLMAX Disruptorを設計したのに、GCの使用を最小限に抑えることがすべての設計ポイントであるのはなぜですか？GCを実行したくない場合、ガベージコレクションされた言語を使用するのはなぜですか？

彼らの最適化、ハードウェアの知識のレベル、そして彼らが置いた思考はただ素晴らしいですが、なぜJavaなのでしょうか？

私はJavaなどに反対ではありませんが、なぜGC言語なのですか？DのようなものやGCを使用しない他の言語を使用して、効率的なコードを使用できるのはなぜですか？チームはJavaに最も精通しているのでしょうか、それともJavaには私には見られない独自の利点がありますか？

手動のメモリ管理でDを使用して開発するとしますが、違いは何でしょうか？低レベル（既にある）を考える必要がありますが、システムがネイティブであるため、システムから最高のパフォーマンスを引き出すことができます。

パフォーマンスを最適化することと安全性を完全にオフにすることには大きな違いがあるため

GCの数を減らすことにより、フレームワークの応答性が向上し、（おそらく）より速く実行できるようになります。現在、ガベージコレクタの最適化は、ガベージコレクションを行わないという意味ではありません。それは彼らがあまり頻繁にそれをしないことを意味し、彼らがそれをするとき、それは本当に速く走ります。これらの種類の最適化には以下が含まれます。

1. 小さなスローアウェイオブジェクトを使用して、サバイバースペースに移動する（つまり、少なくとも1つのガベージコレクションを生き残った）オブジェクトの数を最小限に抑える。サバイバー空間に移動したオブジェクトは収集が難しく、ここでのガベージコレクションはJVM全体の凍結を意味する場合があります。
2. 最初からあまりにも多くのオブジェクトを割り当てないでください。若い世代のオブジェクトは割り当てや収集が非常に安価であるため、注意しないとこれは逆効果になります。
3. 新しいオブジェクトが古いオブジェクトを指していることを確認し（逆ではない）、若いオブジェクトを簡単に収集できるようにします。

パフォーマンスを調整するときは、頻繁に実行されないコードを無視しながら、通常は非常に具体的な「ホットスポット」を調整します。Javaでそれを行う場合、ガベージコレクターにこれらの暗いコーナーを処理させることができます（大きな違いは生じないため）が、タイトループで実行される領域に対して非常に慎重に最適化します。したがって、最適化する場所としない場所を選択できるため、重要な場所に努力を集中できます。

ガベージコレクションを完全にオフにすると、選択できなくなります。これまで、すべてのオブジェクトを手動で廃棄する必要があります。そのメソッドは1日に1回しか呼び出されませんか？Javaでは、パフォーマンスへの影響は無視できるため、そのままにすることができます（完全なGCを毎月発生させてもかまいません）。C ++では、まだリソースがリークしているため、そのあいまいなメソッドにも注意する必要があります。したがって、アプリケーションのすべての部分でリソース管理の料金を支払う必要がありますが、Javaでは集中できます。

しかし、それはさらに悪化します。

バグがある場合は、満月の月曜日にのみアクセスされるアプリケーションの暗いコーナーで言ってみましょう。Javaには強力な安全性保証があります。「未定義の動作」はほとんどありません。間違ったものを使用すると、例外がスローされ、プログラムが停止し、データの破損は発生しません。だから、気づかないうちに何も悪いことは起こらないと確信しています。

しかし、Dのようなものでは、不正なポインタアクセスやバッファオーバーフローが発生する可能性があり、メモリを破損する可能性がありますが、プログラムは認識せず（安全をオフにしたことを覚えていますか？）データ、およびいくつかの非常に厄介なことを実行してデータを破損しますが、あなたは知らない、そしてより多くの破損が発生するにつれて、データはますます間違って、それから突然壊れて、それは人生に不可欠なアプリケーションにありました、そしてその指を、いくつかのエラーは、ロケットの計算に起こった、そしてそれは仕事、そしてロケット爆発、と誰かのダイスをしないように、そしてあなたの会社は、すべての新聞のフロントページにあり、あなたの上司のポイントあなたあなたが「と言っていますパフォーマンスを最適化するためにDを使用することを提案したエンジニアが、なぜ安全性を考えなかったのですか？「そして、それはあなたのせいです。あなたはパフォーマンスへのあなたの愚かな試みでそれらの人々を殺しました。

わかりました、ほとんどの場合、それはそれよりも劇的ではありません。しかし、ビジネスクリティカルなアプリケーションやGPSアプリだけでなく、たとえば政府のヘルスケアWebサイトでも、バグがあるとかなりマイナスの結果をもたらす可能性があります。それらを完全に防ぐか、発生したときにフェイルファーストする言語を使用することは、通常非常に良い考えです。

安全をオフにするのにはコストがかかります。ネイティブになることは必ずしも意味をなさない。時には、少しでも安全な言語を最適化する方がはるかに簡単で安全な場合があります。多くの場合の正確性と安全性は、GCを完全に排除することによって廃棄される数ナノ秒に勝ります。そのような状況ではDisruptor を使用できるため、LMAX-Exchangeが適切な呼び出しを行ったと思います。

しかし、特にDはどうですか？暗いコーナーが必要な場合はGCがあり、SafeDサブセット（編集前には知りませんでした）は未定義の動作を削除します（使用することを忘れない場合！）。

まあその場合、それは単純な成熟度の問題です。Javaエコシステムは、適切に作成されたツールと成熟したライブラリでいっぱいです（開発に適しています）。Dよりも多くの開発者がJavaを知っています（メンテナンスの方が良い）。金融アプリケーションのように重要な何かのために、あまり人気のない新しい言語を選ぶのは良い考えではなかったでしょう。あまり知られていない言語では、問題がある場合、あなたを助けることができるものはほとんどありません。あなたが見つけるライブラリは、より少ない人々にさらされているため、より多くのバグを持つ傾向があります。

ですから、私の最後のポイントはまだ保持しています。あなたが悲惨な結果を伴う問題を避けたいなら、安全な選択を固守してください。Dの人生のこの時点で、顧客は狂ったリスクを取る準備ができている小さな新興企業です。問題に数百万の費用がかかる場合は、イノベーションの鐘型曲線にとどまることをお勧めします。

Javaで書かれている理由は、彼らが社内でJavaの専門知識を持っているためで、おそらくC ++がC ++ 0x / 11と一緒に行動する前に書かれたからだと思われます（まだ開発中です）。

それらのコードは実際には名前だけでJavaであり、sun.misc.Unsafeをかなり使用していますが、これはJavaのポイントを打ち負かし、安全性が与えられると思われます。DisruptorのC ++ポートを作成しましたが、出荷されているJavaコードよりもパフォーマンスが優れています（JVMのチューニングに多くの時間を費やしていません）。

とはいえ、ディスラプターが従う原則は言語固有ではありません。たとえば、ヒープを割り当てたり解放したりする低遅延のC ++コードを期待しないでください。

この質問は、事実として誤った前提を述べてから、その誤った前提について議論します。

これを掘り下げてみましょう。「GCの使用を最小限に抑えるためのすべての設計ポイント」-単に真実ではありません。ディスラプターの革新は、GCとはほとんど関係ありません。破壊器が機能するのは、その設計が最新のコンピューターの動作を巧みに考慮しているためです。議論については、Cliff Clickの講演http://www.azulsystems.com/events/javaone_2009/session/2009_J1_HardwareCrashCourse.pdfを参照してください。

LMaxがAzulの顧客であることはよく知られています。Azul GCの場合、175GBのヒープであっても、問題ではないことを直接知っています。

彼らは低レベルを考えなければなりません

上記はあなたが探している答えの半分になります。LMAXブログと同じように、推論を完了するための半分を見つけることができます。

非常に効率的ですが、簡単に台無しになるため、多くのエラーが発生する可能性があります...

LMAX開発者が認めているように、そのようなコードは、たとえJavaであっても、開発、理解、デバッグが非常に難しい場合があります。低レベルのプログラミング言語に関するウィキペディアの記事で指摘されているように、現在よりもさらに低いレベルに進むと、この問題が悪化するだけです。

低レベル言語で書かれたプログラムは、非常に高速に実行でき、非常に小さなメモリフットプリントで実行できます。高水準言語での同等のプログラムは、より重いものになります。低レベル言語は単純ですが、覚えておく必要のある多くの技術的な詳細のために、使いにくいと考えられています。

比較すると、高レベルのプログラミング言語は、プログラムの仕様からコンピューターアーキテクチャの実行セマンティクスを分離し、開発を簡素化します...

Javaを構文言語として使用し、そのJDKライブラリを使用しない場合、コンパイルされた非GC言語と同じくらい高速になります。GCはリアルタイムシステムには適していませんが、Javaでゴミを残さないシステムを開発することは可能です。その結果、GCはトリガーされません。

Java言語とプラットフォームにはC / C ++よりも多くの利点があると信じており、超低遅延のJavaコンポーネントを開発およびベンチマークして、それを証明しています。この記事では、GCを使用しないJava開発の手法について説明します。

LMAXは、高性能なスレッド間メッセージングライブラリです。

有用であるためには、他の誰かが各スレッドに有用な仕事をさせるコードを書かなければなりません。コードがJavaまたはC＃である可能性が最も高いことを考えると、それらとうまくインターフェースする言語の選択はほとんどありません。

CまたはC ++を使用するのは、スレッドモデルが定義されていないため、ユーザーを単一のOSに制限する場合を除き、適切なオプションではありません。

最近のJavaは多くのソフトウェア開発の標準であるため、特に理由がない限り、Javaを選択するのが最適です。（ローマでローマ人のように…）

Java（またはC＃）での高性能ソフトウェアの作成は、ポイントを証明するためによく行われます…