Ruby の実装に依存します。
たとえば、Ruby 2.0 MRI (ほとんどのシステムで典型的なもの) は、すべてのオブジェクトをヒープに格納します。短い文字列などの小さなオブジェクトは、ヒープに完全に収まります。大きなオブジェクトの場合、Ruby はヒープの外に追加のメモリを malloc します。
「MRI メモリ割り当て - 開発者向け入門書」および「Ruby GC のわかりやすい解説」を参照してください。
これは、 「Ruby がオブジェクトをメモリに格納する方法を理解する」です。これには、優れた長い説明があります。
「オブジェクトがメモリ内で占有するスペース全体がスロット内に格納されるわけではありません。むしろ、各スロットは小さな固定サイズのスペースであり、Ruby インタープリターがメモリ内の場所を処理すると考えることができます。この場所は Ruby ヒープの外側に存在します。明確にするために、50MB の文字列がある場合、50MB のデータは Ruby のヒープの外に格納されます.50MB のストーリーを本当に知りたい場合は、そのためのスペース実際には、C の malloc コマンドのようなものによって割り当てられ (古き良き Ruby は C で書かれているため)、システム ヒープに格納されます. Ruby ヒープのスロットには、システム ヒープ上のそのメモリ位置への参照が含まれているだけです。 50MBのデータ。」
「Ruby には独自のヒープ管理があり、Ruby プログラムの実行中に作成されたオブジェクトを管理するために、実際にはいくつかの「Ruby ヒープ」で構成されています。これは、オペレーティング システムのシステム ヒープとは別のものです。個々の Ruby ヒープにはそれぞれスロットがあり、各スロットに1 つのオブジェクトを参照できます。
もう 1 つの優れた情報源は、" How Ruby Manages Memory and Garbage Collection " で、" Garbage Collection Slides from LA Ruby Conference " のスライドにリンクしています。
「ガベージ コレクション言語として、Ruby はすべてをヒープに置くという簡単な方法を取ります」。
繊維
各ファイバーは独自の小さなスタックを取得するため、ファイバーは Ruby で特別です。
「他のスタックレス軽量同時実行モデルとは対照的に、各ファイバーには小さな 4KB スタックが付属しています。これにより、ファイバー ブロック内の深くネストされた関数呼び出しからファイバーを一時停止できます。」
動的なファイバー スタックのサイジングに関する長期にわたる機能要求に興味があるかもしれません。
現実世界のソリューションにもっと関心がある場合、機能要求の作成者は次の回避策を推奨しています:「大きなスタックを必要とする操作をリファクタリングして、別のスレッドで実行し、thread.value でブロックする」。
cont.c
ソース ファイルの FIBER_MACHINE_STACK_ALLOCATION_SIZE と FIBER_VM_STACK_SIZE を独自に選択して、カスタム バージョンの Ruby をコンパイルすることも検討できます。このファイルには、ファイバー スタックがどのように割り当てられ、解放されるかなども示されています。