Rust: アロケータの特性とstd :: heap

残念ながら、RFCの議論でこれについて言及するのに十分な注意を払っていませんでしたが、 realloc_in_placeを2つの関数grow_in_placeとshrink_in_placeに置き換える必要があると思います。理由：

• 割り当てのサイズが増加しているか減少しているかが不明な単一のユースケース（ reallocまたはrealloc_in_placeを実装する以外）は考えられません。 より専門的な方法を使用すると、何が起こっているのかが少し明確になります。
• 割り当ての拡大と縮小のコードパスは根本的に異なる傾向があります。拡大には、隣接するメモリブロックが空いているかどうかをテストして要求するのに対し、縮小には、適切なサイズのサブブロックを切り取って解放することが含まれます。 realloc_in_place内のブランチのコストは非常に小さいですが、 growとshrinkすると、アロケーターが実行する必要のある個別のタスクをより適切にキャプチャできます。

これらは後方に追加できます-互換性のあるrealloc_in_place隣に追加できますが、これにより、デフォルトで実装される関数が他の関数に関して制約されます。

一貫性を保つために、 reallocもgrowとsplitに分割する必要がありますが、私が知っているオーバーロード可能なrealloc関数を持つことの唯一の利点はmmapのリマップオプションを使用できるようにすることですが、このような区別はありません。

さらに、 reallocとrealloc_in_placeのデフォルトの実装は、わずかに調整する必要があると思います- usable_sizeに対してチェックする代わりに、 reallocは最初にrealloc_in_place 。 次に、 realloc_in_placeは、デフォルトで使用可能なサイズをチェックし、小さな変更の場合は、普遍的に失敗を返すのではなく、成功を返す必要があります。

これにより、 realloc高性能実装を簡単に作成できます。必要なのはrealloc_in_place改善することだけです。 ただし、 usable_sizeに対するチェックは引き続き実行されるため、デフォルトのパフォーマンスreallocは影響を受けません。

別の問題： fn realloc_in_placeのドキュメントには、Okが返された場合、 ptr new_layout 「適合する」ことが保証されていると書かれています。

私にとってこれは、指定されたアドレスの配置がnew_layoutによって暗示される制約と一致することを確認する必要があることを意味します。

ただし、基になるfn reallocate_inplace関数の仕様は、_it_がそのようなチェックを実行することを意味するとは思いません。

• さらに、 fn realloc_in_place使用に飛び込んだクライアントは、それ自体がアライメントが機能することを保証するのが妥当だと思われます（実際には、特定のユースケースではどこでも同じアライメントが必要になると思います...）

それで、 fn realloc_in_placeの実装は、与えられたptrがnew_layoutと互換性があることを確認することで本当に負担をかけられるべきでしょうか？ （この場合は）その要件を呼び出し元にプッシュバックする方がおそらく良いでしょう...

@gereeterあなたは良い点を作ります。 問題の説明に蓄積しているチェックリストにそれらを追加します。

（この時点で、 #[may_dangle]サポートが電車に乗ってbetaチャネルに入るのを待っています。これにより、アロケーター統合の一部としてstdコレクションに使用できるようになります）

私はRustを初めて使用するので、これが他の場所で議論されている場合はご容赦ください。

オブジェクト固有のアロケータをサポートする方法について何か考えはありますか？ スラブアロケータやマガジンアロケータなどの一部のアロケータは特定のタイプにバインドされ、新しいオブジェクトの構築、「解放」された構築オブジェクトのキャッシュ（実際に削除するのではなく）、構築済みのキャッシュオブジェクトの返却、および必要に応じて、基になるメモリを基になるアロケータに解放する前にオブジェクトをドロップします。

現在、この提案にはObjectAllocator<T>に沿ったものは何も含まれていませんが、非常に役立ちます。 特に、私はマガジンアロケーターオブジェクトキャッシングレイヤー（上記のリンク）の実装に取り​​組んでいますが、これはAllocatorをラップして、キャッシングでオブジェクトを構築およびドロップする作業のみを行うことができますレイヤー自体、これで他のオブジェクトアロケーター（スラブアロケーターなど）をラップして、本当に汎用のキャッシングレイヤーにすることができれば素晴らしいと思います。

オブジェクトアロケータのタイプまたは特性は、この提案のどこに当てはまりますか？ それは将来のRFCのために残されますか？ 他に何かありますか？

これについてはまだ議論されていないと思います。

独自のObjectAllocator<T>記述してから、 impl<T: Allocator, U> ObjectAllocator<U> for T { .. }を実行すると、すべての通常のアロケーターがすべてのオブジェクトのオブジェクト固有のアロケーターとして機能できるようになります。

将来の作業は、単純なole '（汎用）アロケーターではなく、ノードに特性を使用するようにコレクションを変更することです。

@pnkfelix

（この時点で、＃[may_dangle]サポートが列車をベータチャネルに乗せるのを待っています。これにより、アロケーター統合の一部としてstdコレクションに使用できるようになります）

私はこれが起こったと思いますか？

@ Ericson2314ええ、自分で書くことは実験目的のオプションですが、相互運用性の観点から標準化する方がはるかにメリットがあると思います（たとえば、スラブアロケーターも実装する予定ですが、私のコードのサードパーティユーザーが私の雑誌のキャッシュレイヤーで誰か_else's_スラブアロケーターを使用できれば素晴らしいです）。 私の質問は、単にObjectAllocator<T>特性またはそのようなものが議論する価値があるかどうかです。 別のRFCに最適なようですが？ 私は、単一のRFCにどれだけ属するか、そしていつ別々のRFCに属するかについてのガイドラインにあまり精通していません...

@joshlf

オブジェクトアロケータのタイプまたは特性は、この提案のどこに当てはまりますか？ それは将来のRFCのために残されますか？ 他に何かありますか？

はい、それは別のRFCになります。

私は、単一のRFCにどれだけ属するか、そしていつ別々のRFCに属するかについてのガイドラインにあまり精通していません...

それはRFC自体の範囲に依存します。RFC自体はそれを書いた人によって決定され、フィードバックは全員から与えられます。

しかし実際には、これはすでに受け入れられているこのRFCの追跡の問題であるため、拡張機能や設計変更について考えることは、このスレッドには当てはまりません。 RFCリポジトリで新しいものを開く必要があります。

@joshlfああ、 ObjectAllocator<T>は特性だと思っていました。 私は、特定のアロケーターではなく、特性のプロトタイプを作成することを意味しました。 はい、 @ steveklabnikが言うように、その特性は独自のRFCに

@steveklabnikええ今の議論は他の場所でより良いでしょう。 しかし、 @ joshlfは、受け入れられているが実装されていないAPI設計のこれまで予期していなかった欠陥を明らかにしないように、この問題も提起していました。 その意味で、それはこのスレッドの以前の投稿と一致します。

@ Ericson2314ええ、それがあなたの意図したことだと思いました。 私たちは同じページにいると思います:)

@steveklabnikいいですね。 自分の実装をいじって、RFCを提出するのは、それが良い考えのように思える場合です。

@joshlfカスタムアロケータがコンパイラまたは標準ライブラリに入る理由は何もありません。 このRFCがリリースされると、任意の種類の割り当てを行う独自のクレートを簡単に公開できます（jemallocのような本格的なアロケーターでさえカスタム実装できます！）。

@alexregこれは、特定のカスタムアロケーターに関するものではなく、特定のタイプでパラメトリックであるすべてのアロケーターのタイプを指定する特性です。 したがって、RFC 1398が低レベルのアロケーターのタイプであるトレイト（ Allocator ）を定義するのと同じように、アロケーターのタイプであるトレイト（ ObjectAllocator<T> ）について質問しています。タイプTオブジェクトを割り当て/割り当て解除および構築/ドロップできます。

@alexregカスタムオブジェクト固有のアロケータで標準ライブラリコレクションを使用することについての私の初期のポイントを参照してください。

もちろんですが、それが標準ライブラリに属する​​かどうかはわかりません。 機能性や使いやすさを損なうことなく、簡単に別のクレートに入ることができます。

2017年1月4日には、午後9時59分で、ジョシュアLiebow-Feeser [email protected]書きました：

@alexreg https://github.com/alexregこれは、特定のカスタムアロケーターに関するものではなく、特定のタイプでパラメトリックであるすべてのアロケーターのタイプを指定する特性です。 したがって、RFC 1398が低レベルのアロケーターのタイプであるトレイト（アロケーター）を定義しているように、私はトレイト（ObjectAllocator）について質問しています。）これは、タイプTのオブジェクトを割り当て/割り当て解除および構築/ドロップできるアロケータのタイプです。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHub https://github.com/rust-lang/rust/issues/32838#issuecomment-270499064で表示するか、スレッドをミュートしますhttps://github.com/notifications/unsubscribe-auth/ AAEF3IhyyPhFgu1EGHr_GM_Evsr0SRzIks5rPBZGgaJpZM4IDYUN 。

任意のカスタムアロケータで標準ライブラリコレクション（ヒープに割り当てられた値）を使用したいと思います。 つまり、オブジェクト固有のものに限定されません。

2017年1月4日には、午後10時01で、ジョン・エリクソンの[email protected]は書きました：

@alexreghttps ：//github.com/alexregカスタムオブジェクト固有のアロケーターで標準ライブラリコレクションを使用することについての私の初期のポイントを参照して

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHub https://github.com/rust-lang/rust/issues/32838#issuecomment-270499628で表示するか、スレッドをミュートしてくださいhttps://github.com/notifications/unsubscribe-auth/ AAEF3CrjYIXqcv8Aqvb4VTyPcajJozICks5rPBbOgaJpZM4IDYUN 。

もちろんですが、それが標準ライブラリに属する​​かどうかはわかりません。 機能性や使いやすさを損なうことなく、簡単に別のクレートに入ることができます。

はい。ただし、標準ライブラリの機能に依存させたい場合があります（ @ Ericson2314が提案したものなど）。

任意のカスタムアロケータで標準ライブラリコレクション（ヒープに割り当てられた値）を使用したいと思います。 つまり、オブジェクト固有のものに限定されません。

理想的には、両方のタイプのアロケーターを受け入れる必要があります。 オブジェクト固有のキャッシュを使用することには、非常に大きな利点があります。 たとえば、スラブの割り当てとマガジンのキャッシュの両方で、パフォーマンスが大幅に向上します。興味がある場合は、上記のリンク先の論文をご覧ください。

しかし、オブジェクトアロケータートレイトは、単に一般的なアロケータートレイトのサブトレイトである可能性があります。 私に関する限り、それはそれと同じくらい簡単です。 確かに、特定のタイプのアロケーターは汎用アロケーターよりも効率的ですが、コンパイラーも標準もこれについて実際に知る必要はありません（または実際に知る必要があります）。

2017年1月4日には、22：13で、ジョシュアLiebow-Feeser [email protected]書きました：

もちろんですが、それが標準ライブラリに属する​​かどうかはわかりません。 機能性や使いやすさを損なうことなく、簡単に別のクレートに入ることができます。

はい。ただし、標準ライブラリの機能に依存させたい場合があります（ @ Ericson2314 https://github.com/Ericson2314の提案など）。

標準ライブラリコレクション（ヒープに割り当てられた値）を任意のカスタムアロケーターで使用したいと思います。 つまり、オブジェクト固有のものに限定されません。

理想的には、両方のタイプのアロケーターを受け入れる必要があります。 オブジェクト固有のキャッシュを使用することには、非常に大きな利点があります。 たとえば、スラブの割り当てとマガジンのキャッシュの両方で、パフォーマンスが大幅に向上します。興味がある場合は、上記のリンク先の論文をご覧ください。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHub https://github.com/rust-lang/rust/issues/32838#issuecomment-270502231で表示するか、スレッドをミュートしますhttps://github.com/notifications/unsubscribe-auth/ AAEF3L9F9r_0T5evOtt7Es92vw6gBxR9ks5rPBl9gaJpZM4IDYUN 。

しかし、オブジェクトアロケータートレイトは、単に一般的なアロケータートレイトのサブトレイトである可能性があります。 私に関する限り、それはそれと同じくらい簡単です。 確かに、特定のタイプのアロケーターは汎用アロケーターよりも効率的ですが、コンパイラーも標準もこれについて実際に知る必要はありません（または実際に知る必要があります）。

ああ、問題はセマンティクスが異なることです。 Allocatorは、生のバイトBLOBを割り当てて解放します。 一方、 ObjectAllocator<T> 、すでに構築されたオブジェクトを割り当て、これらのオブジェクトを削除する役割も果たします（新しく割り当てられたオブジェクトを構築するために後で配布される可能性のある構築されたオブジェクトをキャッシュできることを含む） 、これは高価です）。 特性は次のようになります。

trait ObjectAllocator<T> {
    fn alloc() -> T;
    fn free(t T);
}

これはAllocatorと互換性がありません。このメソッドは、生のポインターを処理し、型の概念がありません。 さらに、 Allocatorの場合、最初に解放されるオブジェクトをdropするのは呼び出し元の責任です。 これは非常に重要です-タイプT知っていると、 ObjectAllocator<T>はTのdropメソッドを呼び出すなどのことができます。 free(t)はtをfreeに移動し、呼び出し元は最初にtドロップできません-代わりにObjectAllocator<T>の責任です。 基本的に、これら2つの特性は互いに互換性がありません。

ああ、なるほど。 この提案にはすでにそのようなもの、つまりバイトレベルの「上位レベル」のアロケータが含まれていると思いました。 その場合、完全に公正な提案です！

2017年1月4日には、午後09時29分で、ジョシュアLiebow-Feeser [email protected]書きました：

しかし、オブジェクトアロケータートレイトは、単に一般的なアロケータートレイトのサブトレイトである可能性があります。 私に関する限り、それはそれと同じくらい簡単です。 確かに、特定のタイプのアロケーターは汎用アロケーターよりも効率的ですが、コンパイラーも標準もこれについて実際に知る必要はありません（または実際に知る必要があります）。

ああ、問題はセマンティクスが異なることです。 アロケータは、生のバイトBLOBを割り当てて解放します。 ObjectAllocator一方、は、すでに構築されたオブジェクトを割り当て、これらのオブジェクトを削除する責任もあります（新しく割り当てられたオブジェクトを構築するために後で配布される可能性のある構築されたオブジェクトをキャッシュできることを含む）。 特性は次のようになります。

特性ObjectAllocator{{
fn alloc（）-> T;
fn free（t T）;
}
これは、メソッドがrawポインターを処理し、型の概念がないAllocatorとは互換性がありません。 さらに、アロケーターでは、解放されているオブジェクトを最初にドロップするのは呼び出し元の責任です。 これは非常に重要です-タイプTについて知っていると、ObjectAllocatorが許可されますTのdropメソッドの呼び出しなどを行うには、free（t）がtをfreeに移動するため、呼び出し元は最初にtをドロップできません。代わりにObjectAllocatorです。の責任。 基本的に、これら2つの特性は互いに互換性がありません。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHub https://github.com/rust-lang/rust/issues/32838#issuecomment-270505704で表示するか、スレッドをミュートしてくださいhttps://github.com/notifications/unsubscribe-auth/ AAEF3GViJBefuk8IWgPauPyL5tV78Fn5ks5rPB08gaJpZM4IDYUN 。

@alexregああ、そうだ、私もそう望んでいた:)まあ-別のRFCを待たなければならないだろう。

はい、そのRFCをキックスタートしてください、私はそれがたくさんのサポートを得ると確信しています！ そして、説明に感謝します（私はこのRFCの詳細にまったく追いついていない）。

2017年1月5日には、0：53で、ジョシュアLiebow-Feeser [email protected]書きました：

@alexreg https://github.com/alexregああ、そうだと思っていた:)まあ-別のRFCを待たなければならないだろう。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHub https://github.com/rust-lang/rust/issues/32838#issuecomment-270531535で表示するか、スレッドをミュートしてくださいhttps://github.com/notifications/unsubscribe-auth/ AAEF3MQQeXhTliU5CBsoheBFL26Ee9WUks5rPD8RgaJpZM4IDYUN 。

カスタムアロケータをテストするためのクレートが役立ちます。

明らかな何かが欠けている場合は許してください。ただし、このRFCで説明されているLayout特性が、 CopyとCloneを実装しない理由があります。 POD？

何も思いつかない。

プロセスの後半でこれを取り上げて申し訳ありませんが...

メソッドではなく関数であるdeallocような関数のサポートを追加する価値があるでしょうか。 アイデアは、アラインメントを使用して、メモリ内の親アロケータがどこにあるかをポインタから推測できるようにすることです。したがって、明示的なアロケータ参照を必要とせずに解放できます。

これは、カスタムアロケーターを使用するデータ構造にとって大きなメリットになる可能性があります。 これにより、アロケーター自体への参照を保持するのではなく、適切なdealloc関数を呼び出すことができるように、アロケーターの_type_でパラメトリックである必要があるだけです。 たとえば、 Boxが最終的にカスタムアロケータをサポートするように変更された場合、参照を格納するために2ワードに展開する必要はなく、1ワード（ポインタのみ）のままにすることができます。アロケーターにも。

関連する注記として、グローバルアロケータを許可するために非メソッドalloc関数をサポートすることも役立つ場合があります。 これは、メソッド以外のdealloc関数でうまく構成されます-グローバルアロケーターの場合、の静的インスタンスは1つしかないため、アロケーターへのポインター推論を行う必要はありません。プログラム全体のアロケータ。

@joshlf現在の設計では、アロケータを（ゼロサイズの）ユニットタイプにするだけでそれを実現できますstruct MyAlloc;つまり、 Allocator特性を実装します。
参照を格納するか、まったく格納しないかは、常に、アロケータの値による格納よりも一般的ではあり

直接埋め込まれた型にも当てはまることがわかりましたが、データ構造が代わりに参照を保持することを決定した場合はどうでしょうか。 ゼロサイズの型への参照はゼロスペースを占有しますか？ つまり、私が持っている場合：

struct Foo()

struct Blah{
    foo: &Foo,
}

Blahサイズはゼロですか？

実際には、それが可能であっても、アロケータのサイズをゼロにしたくない場合があります。 たとえば、_from_を割り当てるゼロ以外のサイズのアロケータがあるが、元のアロケータを知らなくてもオブジェクトを解放する機能があるとします。 これは、 Box単語だけを使用させるのに役立ちます。 Box::new_from_allocatorようなものがあり、引数としてアロケーターを取る必要があります-そしてそれはゼロ以外のサイズのアロケーターである可能性があります-しかし、アロケーターが元のアロケーター参照なしで解放をサポートした場合、返されるBox<T>は、元のBox::new_from_allocator呼び出しで渡されたアロケーターへの参照の保存を回避できます。

たとえば、割り当て元のサイズがゼロ以外のアロケータがあるが、元のアロケータを知らなくてもオブジェクトを解放する機能があるとします。

基本的にこの理由から、アロケーターとデロケーターの特性を別々に（2つを接続するアソシエートタイプで）因数分解することを提案していたのはずっと昔のことです。

コンパイラーは、これらのアロケーターを使用して割り当てを最適化することを許可されるべきですか？

コンパイラーは、これらのアロケーターを使用して割り当てを最適化することを許可されるべきですか？

@Zoxcどういう意味ですか？

基本的にこの理由から、アロケーターとデロケーターの特性を別々に（2つを接続するアソシエートタイプで）因数分解することを提案していたのはずっと昔のことです。

後世のために、このステートメントを明確にしましょう（オフラインで@ Ericson2314に話しました）：アイデアは、 Boxがデアロケーター上でパラメトリックになる可能性があるということです。 したがって、次の実装を行うことができます。

trait Allocator {
    type D: Deallocator;

    fn get_deallocator(&self) -> Self::D;
}

trait Deallocator {}

struct Box<T, D: Deallocator> {
    ptr: *mut T,
    d: D,
}

impl<T, D: Deallocator> Box<T, D> {
    fn new_from_allocator<A: Allocator>(x: T, a: A) -> Box<T, A::D> {
        ...
        Box {
            ptr: ptr,
            d: a.get_deallocator()
        }
    }
}

この方法では、呼び出し時にnew_from_allocator場合は、 A::Dゼロサイズのタイプで、その後、 dのフィールドBox<T, A::D>ゼロのサイズを占めており、そう結果のBox<T, A::D>サイズは1ワードです。

これがいつ着陸するかについてのタイムラインはありますか？ 私はいくつかのアロケーターのものに取り組んでいます、そしてこのものが私が構築するためにそこにあったらいいのにと思います。

興味があれば、これにいくつかのサイクルを貸していただければ幸いですが、私はRustに比較的慣れていないので、初心者のコードをコードレビューする必要があるという点でメンテナの作業が増える可能性があります。 誰かのつま先を踏んだくないし、人のためにもっと仕事をしたくない。

さて、最近、アロケータの状態を評価するために会いました。これにもいくつかの良いニュースがあると思います。 これらのAPIのサポートはまだlibstdに上陸していないようですが、誰もがいつでも上陸することに満足しています。

私たちが議論したことの1つは、推論の問題が発生する可能性があるため、すべてのlibstdタイプを切り替えるのは少し時期尚早かもしれないということですが、それにもかかわらず、 Allocator特性とLayoutを着陸させるのは良い考えのようです。 std::heapモジュールを入力します。

@joshlfここで手伝いたいのなら、それは大歓迎だと思います！ 最初の部分は、このRFCから標準ライブラリに基本的な型/特性を導入する可能性があります。その後、libstdのコレクションの実験と試用を開始できます。

@alexcrichtonリンクが壊れていると思いますか？ ここを指します。

私たちが議論したことの1つは、すべてのlibstdタイプを切り替えることは、推論の問題の可能性があるため、少し時期尚早かもしれないということです。

トレイトを追加することは良い最初のステップですが、それを使用するために既存のAPIをリファクタリングしないと、あまり使用されません。 https://github.com/rust-lang/rust/issues/27336#issuecomment -300721558で、ファサードの背後にある木枠をすぐにリファクタリングできることを提案しstd新しいタイプのラッパーを追加します。 やるのは面倒ですが、進歩を遂げることができます。

@alexcrichtonオブジェクトアロケータをここでの議論により、アロケーターの特性とオブジェクトの間にほぼ完全な対称性があると私は信じています。アロケータ特性。 例えば、あなたは（私は変更のようなものがありますAddressには*mut u8との対称性のために*mut TからObjectAllocator<T> ;私たちは、おそらくで終わるだろうAddress<T>またはそのようなもの）：

unsafe trait Allocator {
    unsafe fn alloc(&mut self, layout: Layout) -> Result<*mut u8, AllocErr>;
    unsafe fn dealloc(&mut self, ptr: *mut u8, layout: Layout);
}

unsafe trait ObjectAllocator<T> {
    unsafe fn alloc(&mut self) -> Result<*mut T, AllocErr>;
    unsafe fn dealloc(&mut self, ptr: *mut T);
}

したがって、アロケータとオブジェクトアロケータの両方を同時に実験することは有用であると思います。 ただし、これがそのための適切な場所であるかどうか、または別のRFCまたは少なくとも別のPRが必要かどうかはわかりません。

ああ、グローバルアロケーターに関する情報もあるここにリンク@joshlfはあなたが考えていることですか？

@alexcrichtonは、 libstdのどのコレクションにも統合されていなくても、 Allocator特性とLayoutタイプを提供するPRを望んでいるようです。

それを正しく理解すれば、そのためのPRを立てることができます。 少なくともRawVecとVecプロトタイプとの統合を試み続けているので、そうしていませんでした。 （この時点でRawVec完了しましたが、 DrainやIntoIterなど、他にも多くの構造が構築されているため、 Vecは少し難しいです。 IntoIterなど...）

実際、私の現在のブランチは実際にビルドされる可能性があるようです（そして、 RawVecとの統合のための1つのテストに合格しました）ので、先に進んで投稿しました：＃42313

@hawkwは尋ねました：

明らかな何かが欠けている場合は許してください。ただし、このRFCで説明されているレイアウト特性がPODであるため、コピーとクローンを実装しない理由はありますか？

私が作った理由はLayout実装のみをCloneなくCopy私はより多くの構造を追加する可能性開いたままにしたかったということですLayoutタイプを。 特に、私はまだ持ってしようとしていることに興味がLayoutそれを構築するために使用される任意のタイプの構造を追跡しようとすると（の例えば16-配列struct { x: u8, y: [char; 215] }アロケータがするオプションを持つことになりそうという、）現在のコンテンツがどのタイプから構成されているかをレポートするインストルメンテーションルーチンを公開します。

これはほぼ確実にオプション機能である必要があります。つまり、開発者に型が豊富なLayoutコンストラクターの使用を強制することに反対しているようです。 したがって、この形式のインストルメンテーションには、タイプ情報を持たない割り当てを処理するために、「不明なメモリブロック」カテゴリのようなものを含める必要があります。

しかし、それにもかかわらず、このような機能が、 Layout Copy実装させることを選択しなかった主な理由Copy実装は、 Layout自体に対する時期尚早な制約になると考えました。

@alexcrichton @pnkfelix

@pnkfelixがこれをカバーしているようで、そのPRが

現在、 Allocator::oomの署名は次のとおりです。

    fn oom(&mut self, _: AllocErr) -> ! {
        unsafe { ::core::intrinsics::abort() }
    }

それはされた私の注意に持って来らGeckoは少なくともOOM上にも割り当てサイズを知るのが好きということ、けれども、。 OOMが発生している理由としてOption<Layout>ようなコンテキストを追加するために安定化するときに、これを考慮したいと思うかもしれません。

@alexcrichton
複数のoom_xxxバリアント、または異なる引数タイプの列挙型を使用する価値がありますか？ 失敗する可能性のあるメソッドにはいくつかの異なるシグネチャがあり（たとえば、 allocはレイアウトを取り、 reallocはポインタ、元のレイアウト、新しいレイアウトを取りますなど）、 oomようなメソッドがそれらすべてについて知りたい場合です。

@joshlfそれは本当です、はい、しかしそれが有用かどうかは

ここでの安定化のポイントは、「 fn dealloc提供されるアライメントの要件を決定する」ことでもあり、Windowsでのdeallocの現在の実装では、 alignを使用して正しく無料。 @ruudaあなたはこの事実に興味があるかもしれません。

ここでの安定化のポイントは、「 fn dealloc提供されるアライメントの要件を決定する」ことでもあり、Windowsでのdeallocの現在の実装では、 alignを使用して正しく無料。

はい、これが私が最初にこれに遭遇した方法だと思います。 このため、私のプログラムはWindowsでクラッシュしました。 HeapAllocは配置の保証を行わないため、 allocateはより大きな領域を割り当て、元のポインターをヘッダーに格納しますが、最適化として、配置要件が満たされる場合はこれを回避します。 この最適化を失うことなく、 HeapAllocを無料でアライメントを必要としないアライメント対応アロケータに変換する方法があるのだろうか。

@ruuda

HeapAllocはアライメントを保証しないため

32ビットの場合は8バイト、64ビットの場合は16バイトの最小アライメント保証を提供しますが、それより高いアライメントを保証する方法は提供しません。

Windows上のCRTによって提供される_aligned_mallocは、より高いアライメントの割り当てを提供できますが、特に、 freeは違法であるため、 _aligned_freeとペアにする必要がmallocまたは_aligned_mallocどちらで行われたかわからない場合は、Windowsでalloc_systemが使用されているのと同じ難問に陥っています。 deallocateの配置を知っています。 CRTは、 freeと組み合わせることができる標準のaligned_alloc関数を提供していないため、Microsoftでさえこの問題を解決できませんでした。 （これはC11関数であり、MicrosoftはC11をサポートしていないため、これは弱い議論です。）

deallocateは、位置合わせのみを考慮して、位置合わせがオーバーアラインされているかどうかを認識します。実際の値自体は関係ありません。 真にアライメントに依存しないdeallocateが必要な場合は、すべての割り当てをオーバーアライメントとして扱うことができますが、小さな割り当てでは多くのメモリを浪費します。

@alexcrichtonは書いた：

現在、 Allocator::oomの署名は次のとおりです。

    fn oom(&mut self, _: AllocErr) -> ! {
        unsafe { ::core::intrinsics::abort() }
    }

それはされた私の注意に持って来らGeckoは少なくともOOM上にも割り当てサイズを知るのが好きということ、けれども、。 OOMが発生している理由としてOption<Layout>ようなコンテキストを追加するために安定化するときに、これを考慮したいと思うかもしれません。

AllocErr Layoutは、 AllocErr::ExhaustedバリアントのLayoutが既に含まれています。 LayoutをAllocErr::Unsupportedバリアントに追加することもできます。これは、クライアントの期待の観点から最も簡単だと思います。 （ AllocErr列挙型自体の側面を単純に増やすという欠点がありますが、それについて心配する必要はないかもしれません...）

ああ、必要なのはそれだけだと思います。@ pnkfelixの修正に感謝します。

https://github.com/rust-lang/rust/pull/42727が着陸した後になるので、一般的にstd::heapの追跡問題のためにこの問題の転用を開始します。 これに賛成して、他のいくつかの関連する問題を閉じます。

コレクションを変換するための追跡の問題はありますか？ PRが統合されたので、

• 関連するエラータイプについて話し合う
• ローカルアロケータを使用するようにコレクションを変換することについて話し合います（特に関連するエラータイプを活用します）

https://github.com/rust-lang/rust/issues/42774を開いて、 Alloc stdコレクションへの統合を追跡しました。 std::heapモジュールの最初のパスとは別の安定化の軌道に乗っている可能性が高い、libsチームでの歴史的な議論があります。

アロケーター関連の問題を確認しているときに、しばらく前にhttps://github.com/rust-lang/rust/issues/30170にも出くわしました。 OSXシステムアロケータはアライメントが高くバグが多いようです。そのプログラムをjemallocで実行すると、少なくともLinuxでの割り当て解除中にセグフォールトが発生します。 安定化中に検討する価値があります！

ゼロサイズの割り当てが要求された配置と一致する必要があるかどうかという特定の質問を議論する場所として、＃42794を開きました。

（まあ、ゼロサイズの割り当てはユーザーアロケーターでは違法です！）

alloc::heap::allocate関数とその仲間がNightlyでなくなったので、この新しいAPIを使用するようにServoを更新しました。 これは差分の一部です：

-use alloc::heap;
+use alloc::allocator::{Alloc, Layout};
+use alloc::heap::Heap;

-        let ptr = heap::allocate(req_size as usize, FT_ALIGNMENT) as *mut c_void;
+        let layout = Layout::from_size_align(req_size as usize, FT_ALIGNMENT).unwrap();
+        let ptr = Heap.alloc(layout).unwrap() as *mut c_void;

人間工学は良くないと思います。 1つのアイテムのインポートから2つの異なるモジュールからの3つのアイテムのインポートに移行しました。

• allocator.alloc(Layout::from_size_align(…))便利な方法があるのは理にかなっていますか？
• <Heap as Alloc>::_メソッドを無料の関数または固有のメソッドとして利用できるようにすることは理にかなっていますか？ （インポートするアイテムを1つ少なくするには、 Alloc特性を使用します。）

あるいは、 Alloc特性が前奏曲に含まれている可能性がありますか、それともユースケースのニッチすぎるのでしょうか。

@SimonSapin IMOは、このような低レベルAPIの人間工学を最適化することにあまり

@SimonSapin

人間工学は良くないと思います。 1つのアイテムのインポートから2つの異なるモジュールからの3つのアイテムのインポートに移行しました。

私は自分のコードベースとまったく同じ感覚を持っていました-今はかなり不格好です。

allocator.alloc(Layout::from_size_align(…))?便利な方法があるのは理にかなっていますか

Alloc特性ですか、それともHeapですか？ ここで考慮すべきことの1つは、3番目のエラー条件があることです。 Layout::from_size_alignはOption返すため、割り当て時に発生する可能性のある通常のエラーに加えてNoneを返す可能性があります。 。

あるいは、 Alloc特性が前奏曲に含まれている可能性がありますか、それともユースケースのニッチすぎますか？

IMOは、このような低レベルAPIの人間工学を最適化することにあまり意味がありません。

プレリュードを入れるにはおそらく低レベルであることに同意しますが、それでも人間工学を最適化することには価値があると思います（少なくとも、利己的に-それは本当に厄介なリファクタリングでした😝）。

@SimonSapin以前にOOMを扱ったことがありませんか？ また、 std 、3つのタイプすべてがstd::heapモジュールで使用できます（これらは1つのモジュールに含まれているはずです）。 また、以前はサイズがあふれるケースに対応していませんでしたか？ またはゼロサイズのタイプ？

以前にOOMを扱ったことがありませんか？

それが存在する場合、 alloc::heap::allocate関数はResultなしでポインターを返し、OOM処理に選択肢を残しませんでした。 プロセスを中止したと思います。 スレッドをパニックにするために.unwrap()を追加しました。

それらは1つのモジュールにあるはずです

heap.rsにpub use allocator::*;が含まれていることがわかります。 しかし、rustdocページにリストされているimplでHeap Allocをクリックすると、 alloc::allocator::Allocに送られました。

残りについては、私はそれを調べていません。 私は何年も前に書かれた大量のコードを新しいコンパイラに移植しています。 これらは、CライブラリであるFreeTypeのコールバックだと思います。

alloc :: heap :: alllocate関数が存在する場合、結果なしでポインターを返し、OOM処理に選択肢を残しませんでした。

それはあなたに選択肢を与えました。 返されたポインターは、ヒープアロケーターが割り当てに失敗したことを示すnullポインターである可能性があります。 これが、 Resultに切り替えて、人々がそのケースを処理することを忘れないようにしたことをとてもうれしく思う理由です。

まあ、たぶんFreeTypeがnullチェックをしてしまったのかもしれませんが、私にはわかりません。 とにかく、はい、結果を返すことは良いことです。

＃30170と＃43097を考えると、ユーザーがアライメントを要求もなく大きなアライメントでOSXの問題を解決したいと思います> = 1 << 32 。

これを強制する1つの非常に簡単な方法：変更Layoutインターフェースので、 alignで表されるu32の代わりにusize 。

@alexcrichtonこれについて考えがありますか？ これを行うPRを作成する必要がありますか？

@pnkfelix Layout::from_size_alignはまだusizeを取り、 u32オーバーフローでエラーを返しますよね？

@SimonSapin静的な前提条件が、値> = 1 << 32を渡すことが安全でない場合、 usize整列を継続す​​る理由は何ですか？

答えが「一部のアロケータはアライメント> = 1 << 32サポートしている可能性があります」の場合、現状に戻り、私の提案は無視してかまいません。 私の提案のポイントは基本的にこのようなコメントへの「+1」です

std::mem::align_ofはusize返すため

@SimonSapinああ、古き良き安定したAPIの...ため息をつく。

@pnkfelixを1 << 32制限すること

@rfcbotfcpマージ

わかりました。この特性とそのタイプはしばらくの間焼き付けられており、開始以来、標準コレクションの基礎となる実装でもあります。 私は、特に保守的な新規株式公開から始めることを提案します。つまり、次のインターフェースのみを安定させることです。

pub struct Layout { /* ... */ }

extern {
    pub type void;
}

impl Layout {
    pub fn from_size_align(size: usize, align: usize) -> Option<Layout>;
    pub unsafe fn from_size_align_unchecked(size: usize, align: usize) -> Layout;

    pub fn size(&self) -> usize;
    pub fn align(&self) -> usize;
}

pub unsafe trait Alloc {
    unsafe fn alloc(&mut self, layout: Layout) -> *mut void;
    unsafe fn alloc_zeroed(&mut self, layout: Layout) -> *mut void;
    unsafe fn dealloc(&mut self, ptr: *mut void, layout: Layout);

    // all other methods are default and unstable
}

/// The global default allocator
pub struct Heap;

impl Alloc for Heap {
    // ...
}

impl<'a> Alloc for &'a Heap {
    // ...
}

/// The "system" allocator
pub struct System;

impl Alloc for System {
    // ...
}

impl<'a> Alloc for &'a System {
    // ...
}

pub struct Layout { /* ... */ }

impl Layout {
    pub fn from_size_align(size: usize, align: usize) -> Option<Layout>;
    pub unsafe fn from_size_align_unchecked(size: usize, align: usize) -> Layout;

    pub fn size(&self) -> usize;
    pub fn align(&self) -> usize;
}

// renamed from AllocErr today
pub struct Error {
    // ...
}

impl Error {
    pub fn oom() -> Self;
}

pub unsafe trait Alloc {
    unsafe fn alloc(&mut self, layout: Layout) -> Result<*mut u8, Error>;
    unsafe fn dealloc(&mut self, ptr: *mut u8, layout: Layout);

    // all other methods are default and unstable
}

/// The global default allocator
pub struct Heap;

impl Alloc for Heap {
    // ...
}

impl<'a> Alloc for &'a Heap {
    // ...
}

/// The "system" allocator
pub struct System;

impl Alloc for System {
    // ...
}

impl<'a> Alloc for &'a System {
    // ...
}

特に：

• 今のところ、 Allocトレイトのalloc 、 alloc_zeroed 、およびdeallocメソッドのみを安定させます。 これにより、カスタムグローバルアロケータを定義するという、今日の最も差し迫った問題が解決されると思います。
• Errorタイプを削除して、生のポインターのみを使用するようにします。
• インターフェイスのu8タイプをvoid
• Layoutタイプの簡略版。

deallocとアラインメント（正確なアラインメント？適合？不明？）をどうするかなどの未解決の質問がまだありますが、APIではない可能性が高いため、FCP中にそれらを解決できることを望んでいます-破壊的な変化。

何かを安定させるために+1！

AllocErr名前をErrorし、インターフェイスをもう少し保守的にします。

これにより、アロケータがUnsupportedを指定するオプションがなくなりますか？ 私がたくさんハープしている何かにもっとハープする危険を冒して、私は＃44557がまだ問題であると思います。

Layout

Layoutからいくつかのメソッドを削除したようです。 除外したものを実際に削除するつもりでしたか、それとも不安定なままにしておくつもりでしたか？

impl Error {
    pub fn oom() -> Self;
}

これは今日のAllocErr::Exhaustedのコンストラクターですか？ もしそうなら、それはLayoutパラメータを持つべきではありませんか？

チームメンバーの@alexcrichtonは、これをマージすることを提案しました。 次のステップは、タグ付けされた残りのチームによるレビューです。

• [x] @BurntSushi
• [x] @Kimundi
• [x] @alexcrichton
• [x] @aturon
• [x] @cramertj
• [x] @dtolnay
• [x] @eddyb
• [x] @nikomatsakis
• [x] @nrc
• [x] @pnkfelix
• [x] @sfackler
• [x] @withoutboats

懸念事項：

• * mutu8はhttps://github.com/rust-lang/rust/issues/32838#issuecomment-342622672で解決されました

これらのレビューアがコンセンサスに達すると、これは最終コメント期間に入ります。 このプロセスのどの時点でも提起されていない大きな問題を見つけた場合は、声を上げてください。

タグ付けされたチームメンバーが私に与えることができるコマンドについては、このドキュメントを参照してください。

私はこの仕事のいくつかを安定させることに本当に興奮しています！

1つの質問：上記のスレッドで、 @ joshlfと@ Ericson2314は、 alloc場合に最適化するために、 AllocとDealloc特性を分離する可能性について興味深い点を提起しました。 allocはいくつかのデータが必要ですが、 deallocは追加情報を必要としないため、 Deallocタイプのサイズをゼロにすることができます。

この質問は解決されましたか？ 2つの特性を分離することの欠点は何ですか？

@joshlf

これにより、アロケータがサポートされていないことを指定するオプションがなくなりますか？

はい、いいえ、それはそのような操作が安定したさびですぐにサポートされないことを意味しますが、不安定なさびでそれをサポートし続けることができます。

除外したものを実際に削除するつもりでしたか、それとも不安定なままにしておくつもりでしたか？

確かに！ ここでも、安定したAPI表面積を提案しているだけですが、他のすべてのメソッドは不安定なままにしておくことができます。 時間の経過とともに、より多くの機能を安定させ続けることができます。 できるだけ保守的に始めるのが最善だと思います。

@SimonSapin

これは、今日のAllocErr :: Exhaustedのコンストラクターですか？ もしそうなら、それはレイアウトパラメータを持つべきではありませんか？

ああ良い点！ 本当に必要な場合はErrorをゼロサイズのタイプにする可能性を残したかったのですが、もちろん、レイアウトの取得方法を不安定に保ち、必要に応じて安定させることができます。 それとも、レイアウトを維持するErrorを最初のパスで安定させる必要があると思いますか？

@cramertj

私はまだそのような質問/懸念を個人的に見たことがありませんでしたが（私はそれを見逃したと思います！）、私はそれが価値があると個人的には見ませんでした。 たとえば、コレクションにAlloc + Deallocと入力する必要があるため、2つの特性は一般に定型文の2倍になります。 このような特殊な用途では、他のすべてのユーザーが最終的に使用するインターフェイスに個人的に通知したくないと思います。

@cramertj @alexcrichton

私はまだそのような質問/懸念を個人的に見たことがありませんでしたが（私はそれを見逃したと思います！）、私はそれが価値があると個人的には見ませんでした。

一般的に、1つの明白な例外を除いてそれは価値がないことに同意します： Box 。 Box<T, A: Alloc>は、現在のAlloc定義を考えると、少なくとも2ワードの大きさである必要があります（すでに持っているポインターと、少なくともAllocへの参照） ）グローバルシングルトン（ZSTとして実装可能）の場合を除きます。 このような一般的で基本的なタイプを格納するために必要なスペースでの2倍（またはそれ以上）の爆発が私には関係しています。

@alexcrichton

今のように、誰もがたとえばコレクションにAlloc + Deallocと入力する必要があります

次のようなものを追加できます。

trait Allocator: Alloc + Dealloc {}
impl<T> Allocator for T where T: Alloc + Dealloc {}

このような一般的で基本的なタイプを格納するために必要なスペースでの2倍（またはそれ以上）の爆発

プロセスグローバルではないカスタムアロケータを使用する場合のみ。 std::heap::Heap （デフォルト）はゼロサイズです。

それとも、最初のパスでレイアウト保存エラーを安定させる必要があると思いますか？

@alexcrichtonこの提案された最初のパスがなぜそれであるのか私は本当に理解していません。 Vec悪用することですでに実行できる以上のことはほとんどなく、たとえばhttps://crates.io/crates/jemallocatorを使用するには十分ではありません

全体を安定させるためにまだ解決する必要があるものは何ですか？

プロセスグローバルではないカスタムアロケータを使用する場合のみ。 std :: heap :: Heap（デフォルト）はゼロサイズです。

これは、パラメトリックアロケーターを使用する主なユースケースのようです。 次のツリーの簡単な定義を想像してみてください。

struct Node<T, A: Alloc> {
    t: T,
    left: Option<Box<Node<T, A>>>,
    right: Option<Box<Node<T, A>>>,
}

1ワードのAllocを持つツリーから構築されたツリーは、ZST Allocと比較して、データ構造全体のサイズが約1.7倍になります。 それは私にはかなり悪いように思えます、そしてこれらの種類のアプリケーションはAlloc特性にするという全体的なポイントのようなものです。

@cramertj

次のようなものを追加できます。

また、実際の特性エイリアスも用意します:) https://github.com/rust-lang/rust/issues/41517

@glaebhoerlええ、でもまだ実装がないので、安定化はまだAllocator手動実装を無効にすると、特性に切り替えることができると思います-エイリアスは逆方向に-互換性があります;）

@joshlf

このような一般的で基本的なタイプを格納するために必要なスペースでの2倍（またはそれ以上）の爆発が私には関係しています。

今日のすべての実装は、サイズがゼロの型か、ポインタが大きいだけだと思いますよね？ 一部のpointer-size-typesをゼロサイズにすることができる最適化はありませんか？ （またはそのようなもの？）

@cramertj

次のようなものを追加できます。

確かに！ ただし、1つの特性を3つにしました。 過去に、私たちはそのような特性で素晴らしい経験をしたことがありません。 たとえば、 Box<Both>はBox<OnlyOneTrait>キャストされません。 言語機能がこれらすべてをスムーズにするのを待つことができると確信していますが、せいぜい、それらは遠い道のりのようです。

@SimonSapin

全体を安定させるためにまだ解決する必要があるものは何ですか？

知りません。 議論が少なくなるように、絶対に小さいものから始めたかったのです。

今日のすべての実装は、サイズがゼロの型か、ポインタが大きいだけだと思いますよね？ 一部のpointer-size-typesをゼロサイズにすることができる最適化はありませんか？ （またはそのようなもの？）

ええ、アイデアは、あなたのタイプのアロケーターから割り当てられたオブジェクトへのポインターが与えられれば、それがどのインスタンスから来たのかを理解できるということです（例えば、インラインメタデータを使用して）。 したがって、割り当てを解除する必要がある唯一の情報は、ランタイム情報ではなく、タイプ情報です。

割り当て解除の調整に戻るには、2つの方法があります。

• 提案どおりに安定させます（割り当て解除の調整を行います）。 Layoutが含まれていない限り、手動で割り当てられたメモリの所有権を譲渡することは不可能です。 特に、 Vec 、 Box 、 Stringまたはその他のstdコンテナを、必要以上に厳密に配置して構築することはできません（たとえば、ボックス化された要素がキャッシュラインにまたがるのは望ましくありません）、後で手動で分解して割り当てを解除する必要はありません（これは常にオプションであるとは限りません）。 不可能なことの別の例は、simd操作を使用してVecを埋め、それを配ることです。

• 割り当て解除時に調整を必要とせず、WindowsのHeapAllocベースのalloc_systemから小さな割り当ての最適化を削除します。 常に配置を保存してください。 @alexcrichton 、あなたがそのコードをコミットしたそもそもなぜそこに置かれたのか覚えていますか？ 実際のアプリケーションでかなりの量のメモリを節約できるという証拠はありますか？ （マイクロベンチマークを使用すると、割り当てサイズに応じてどちらの方法でも結果を出すことができます—とにかくHeapAllocがサイズを切り上げていた場合を除きます。）

いずれにせよ、これは非常に難しいトレードオフです。 メモリとパフォーマンスへの影響は、アプリケーションのタイプに大きく依存し、どちらを最適化するかはアプリケーション固有です。

私たちは実際にはJustFine（TM）かもしれないと思います。 Allocドキュメントの引用：

一部の方法では、レイアウトがメモリブロックに適合する必要があります。
レイアウトがメモリブロックに「適合する」とは、（または
同等に、メモリブロックがレイアウトに「適合する」ためには）
次の2つの条件が満たされている必要があります。

1. ブロックの開始アドレスはlayout.align()揃える必要があります。

2. ブロックのサイズは[use_min, use_max]範囲内にある必要があります。ここで、

   • use_minはself.usable_size(layout).0であり、

   • use_maxは、以前の（または以前の）容量です。
     （if）への呼び出しを介してブロックが割り当てられたときに返されます
     alloc_excessまたはrealloc_excess 。

ご了承ください：

• ブロックの割り当てに最近使用されたレイアウトのサイズ
  [use_min, use_max]範囲内にあることが保証されており、

• use_max下限は、への呼び出しによって安全に概算できます。
  usable_size 。

• レイアウトkがメモリブロックに適合する場合（ ptr示される）
  現在、アロケータaを介して割り当てられている場合、
  そのレイアウトを使用して、割り当てを解除します。つまり、 a.dealloc(ptr, k);です。

最後の箇条書きに注意してください。 私は、アライメントとレイアウトを割り当てる場合はa私は、アライメントに解放するために、それは法的でなければなりませんb < aに整列されたオブジェクトので、 aまたに整列されますbであるため、配置がbのレイアウトは、配置がa （同じサイズの）レイアウトで割り当てられたオブジェクトに適合します。

これが意味するのは、特定のタイプに必要な最小アライメントよりも大きいアライメントで割り当ててから、他のコードが最小アライメントで割り当てを解除できるようにする必要があるということです。これで機能するはずです。

一部のpointer-size-typesをゼロサイズにすることができる最適化はありませんか？ （またはそのようなもの？）

最近これに関するRFCがあり、互換性の懸念のために実行できる可能性は非常に低いようです： https ：

たとえば、 Box<Both>はBox<OnlyOneTrait>キャストされません。 言語機能がこれらすべてをスムーズにするのを待つことができると確信していますが、せいぜい、それらは遠い道のりのようです。

一方、トレイトオブジェクトのアップキャストは議論の余地なく望ましいようであり、ほとんどの場合、それを実装するための努力/帯域幅/意志力の問題です。 最近スレッドがありました： https ：

@ruuda私はそのalloc_system実装を最初に書いた人でした。 alexcrichtonは、 <time period>の優れたアロケーターリファクタリング中にそれを移動しただけです。

現在の実装では、特定のメモリブロックを割り当てたのと同じ配置で割り当てを解除alloc_systemが変更されるまで、誰もが従わなければならない現在の現実です。

Windowsでの割り当てでは、常にMEMORY_ALLOCATION_ALIGNMENT倍数が使用されます（ただし、バイトに割り当てたサイズは記憶されています）。 MEMORY_ALLOCATION_ALIGNMENTは、32ビットでは8、64ビットでは16です。 オーバーアラインされたタイプの場合、アラインメントがMEMORY_ALLOCATION_ALIGNMENTより大きいため、 alloc_systemによって生じるオーバーヘッドは一貫して指定されたアラインメントの量になり、64バイトのアラインされた割り当てには64バイトのオーバーヘッドがあります。

そのオーバーアラインされたトリックをすべての割り当てに拡張することにした場合（割り当て時に指定したのと同じアラインメントで割り当てを解除する要件がなくなります）、より多くの割り当てにオーバーヘッドが発生します。 アラインメントがMEMORY_ALLOCATION_ALIGNMENTと同じである割り当てでは、 MEMORY_ALLOCATION_ALIGNMENTバイトの一定のオーバーヘッドが発生します。 アラインメントがMEMORY_ALLOCATION_ALIGNMENT未満の割り当てでは、約半分の時間でMEMORY_ALLOCATION_ALIGNMENTバイトのオーバーヘッドが発生します。 MEMORY_ALLOCATION_ALIGNMENT切り上げられた割り当てのサイズが、割り当てのサイズにポインターのサイズを加えたもの以上の場合、オーバーヘッドはありません。それ以外の場合はオーバーヘッドがあります。 割り当ての99.99％がオーバーアラインされないことを考えると、これらすべての割り当てにそのようなオーバーヘッドが本当に発生したいですか？

@ruuda

個人的には、今日のWindowsでのalloc_systemの実装は、 Vecような別のコンテナーへの割り当ての所有権を放棄する機能よりも大きなメリットがあると感じています。 AFAIKですが、常にアライメントをパディングし、割り当て解除にアライメントを必要としないことの影響を測定するデータはありません。

@joshlf

Windowsのalloc_systemは、割り当てで渡されたのと同じ配置が割り当て解除に渡されることに依存しているため、コメントは間違っていると思います。

割り当ての99.99％がオーバーアラインされないことを考えると、これらすべての割り当てにそのようなオーバーヘッドが本当に発生したいですか？

オーバーヘッドが大きいかどうか、およびメモリまたはパフォーマンスを最適化するかどうかは、アプリケーションによって異なります。 私の疑惑は、ほとんどのアプリケーションでどちらも問題ないということですが、少数の少数派がメモリに深く関心を持っており、実際にはそれらの余分なバイトを買う余裕はありません。 そして、別の少数派はアライメントを制御する必要があり、彼らは本当にそれを必要としています。

@alexcrichton

Windowsのalloc_systemは、割り当てで渡されたのと同じ配置が割り当て解除に渡されることに依存しているため、コメントは間違っていると思います。

これは、Windowsのalloc_systemが実際にAllocトレイトを適切に実装していないことを意味しませんか（したがって、 Allocトレイトの要件を変更する必要があるかもしれません）。

@ retep998

私があなたのコメントを正しく読んでいる場合、別の配置で割り当てを解除できる必要があるかどうかに関係なく、すべての割り当てにその配置のオーバーヘッドが存在しませんか？ つまり、64バイトのアラインメントで64バイトを割り当て、64バイトのアラインメントでも割り当てを解除した場合、説明したオーバーヘッドは依然として存在します。 したがって、通常よりも大きい配置を要求する機能であるため、さまざまな配置を割り当て解除できる機能ではありません。

@joshlf alloc_systemによって引き起こされるオーバーヘッドは、現在、通常よりも大きい配置を要求することによるものです。 配置がMEMORY_ALLOCATION_ALIGNMENT以下の場合、 alloc_systemによるオーバーヘッドはありません。

ただし、異なる配置での割り当て解除を許可するように実装を変更した場合、配置に関係なく、オーバーヘッドはほぼすべての割り当てに適用されます。

ああ、分かった; 理にかなっています。

ヒープと＆ヒープの両方にAllocを実装することの意味は何ですか？ どのような場合に、ユーザーはこれらのimplの1つと他のimplを使用しますか？

これは、 *mut u8が「何でもポインタ」を意味する最初の標準ライブラリAPIですか？ String :: from_raw_partsがありますが、それは実際にはバイトへのポインタを意味します。 私は「何でもポインタ」を意味する*mut u8ファンではありません。 他のオプションは何ですか？ 不透明（OPAQUE）型へのポインタの方が意味があるかもしれません。

@rfcbot懸念* mut u8

@dtolnay Alloc for Heapは一種の「標準」であり、 Alloc for &HeapはWrite for &Tようなもので、特性には&mut selfが必要ですが、実装には必要ありません。 特に、 HeapやSystemようなタイプはスレッドセーフであり、割り当てるときに同期する必要がないことを意味します。

ただし、さらに重要なのは、 #[global_allocator]するには、接続先の静的なタイプがT 、 Alloc for &Tです。 （別名、すべてのグローバルアロケーターはスレッドセーフである必要があります）

*mut u8 、 *mut ()は面白いかもしれないと思いますが、個人的には、ここで「これを正しく行う」こと自体を強いられているとは感じていません。

*mut u8の主な利点は、バイトオフセットで.offsetを使用すると非常に便利なことです。

*mut u8 、 *mut ()は面白いかもしれないと思いますが、個人的には、ここでそれ自体を「正しく理解する」ことを強いられているとは感じていません。

安定したインターフェースで*mut u8を使用する場合、自分自身を固定しませんか？ 言い換えれば、これを安定させれば、将来「これを正しくする」機会はありません。

また、将来RFC 2040のような最適化を行う場合に備えて、 *mut ()は私には少し危険に思えます。

*mut u8の主な利点は、バイトオフセットで.offsetを使用すると非常に便利なことです。

本当ですが、簡単にlet ptr = (foo as *mut u8)を実行してから、陽気な方法で進むことができます。 説得力のある代替案がある場合、それはAPIで*mut u8に固執する動機としては十分ではないようです（公平を期すために、それがあるかどうかはわかりません）。

また、将来RFC 2040のような最適化を行う場合に備えて、* mut（）は少し危険に思えます。

その最適化はおそらくすでに起こらないでしょう-それはあまりにも多くの既存のコードを壊してしまうでしょう。 それがなかったとしても、それはに適用される&()と&mut () 、ない*mut () 。

RFC 1861が実装/安定化に近づいた場合は、それを使用することをお勧めします。

extern { pub type void; }

pub unsafe trait Alloc {
    unsafe fn alloc(&mut self, layout: Layout) -> Result<*mut void, Error>;
    unsafe fn dealloc(&mut self, ptr: *mut void, layout: Layout);
    // ...
}

たぶん遠すぎますよね？

@joshlf私はそれらについてPRが開いているのを見たと思いました、残りの未知数はDynSizedです。

これは、オブジェクトのような構造体ハックで機能しますか？ 次のようなNode<T>とします。

struct Node<T> {
   size: u32,
   data: T,
   // followed by `size` bytes
}

および値型：

struct V {
  a: u32,
  b: bool,
}

ここで、 1回の割り当てでサイズ7の文字列を使用してNode<V>を割り当てたいと思います。 理想的には、サイズ16の割り当てを4に揃えて、それにすべてを収めたいと思います。4はu32 、5はV 、7は文字列バイトです。 これが機能するのは、 Vの最後のメンバーの配置が1であり、文字列バイトにも配置1があるためです。

パックドストレージへの書き込みは未定義の動作であるため、タイプが上記のように構成されている場合、これはC / C ++では許可されないことに注意してください。 これはC / C ++標準の穴であり、残念ながら修正できないと思います。 これが壊れている理由を詳しく説明できますが、代わりにRustに焦点を当てましょう。 これは機能しますか？ :-)

Node<V>構造自体のサイズと配置に関しては、Rustコンパイラの気まぐれにかなり慣れています。 Rustは、スタック、ヒープ、参照の背後など、 Node<V>オブジェクトを想定して最適化を行う可能性があるため、Rustが必要とするサイズまたは配置よりも小さいサイズまたは配置で割り当てるのはUB（未定義の動作）です。 -コンパイル時に予想されるものと一致するサイズと配置を持っています。

実際には、答えは残念ながらノーのようです。このプログラムを実行したところ、少なくともRust Playgroundでは、 Node<V>のサイズが12、配置が4であることがわかりました。つまり、 Node<V>は、少なくとも12バイトオフセットする必要があります。 Node<V>内のdata.bフィールドのオフセットは8バイトのように見えます。これは、バイト9〜11が末尾のパディングであることを意味します。 残念ながら、これらのパディングバイトはある意味で「使用されていません」が、コンパイラはそれらをNode<V>一部として扱い、（最も重要なこととして、書き込みを含めて）好きなことを行う権利を留保します。 Node<V>に割り当てると、そこに余分なデータをリスしようとすると、上書きされる可能性があることを意味します）。

（注：Rustコンパイラーがパックされているとは思わないタイプをパックされたものとして扱うことはできません。ただし、何かがパックされていることをRustコンパイラーに伝えることができます。これにより、タイプのレイアウトが変更されます（パディングが削除されます）。 repr(packed) ）

ただし、両方を同じRustタイプの一部にせずに次々にオブジェクトをレイアウトすることに関しては、これが有効であるとほぼ100％確信しています-結局のところ、 Vecが行うことです。 Layoutタイプのメソッドを使用して、合計割り当てに必要なスペースの量を動的に計算できます。

let node_layout = Layout::new::<Node<V>>();
// NOTE: This is only valid if the node_layout.align() is at least as large as mem::align_of_val("a")!
// NOTE: I'm assuming that the alignment of all strings is the same (since str is unsized, you can't do mem::align_of::<str>())
let padding = node_layout.padding_needed_for(mem::align_of_val("a"));
let total_size = node_layout.size() + padding + 7;
let total_layout = Layout::from_size_align(total_size, node_layout.align()).unwrap();

このようなものは機能しますか？

#[repr(C)]
struct Node<T> {
   size: u32,
   data: T,
   bytes: [u8; 0],
}

…次に、より大きなサイズで割り当て、 slice::from_raw_parts_mut(node.bytes.as_mut_ptr(), size)ますか？

詳細な回答をありがとう@joshlf ！ 私のユースケースのTLDRは、サイズ16のNode<V>を取得できるというものですが、Vがrepr(packed)場合に限ります。 それ以外の場合、私ができる最善の方法はサイズ19（12 + 7）です。

@SimonSapinわからない; 試してみます。

本当にこのスレッドに追いついたが、私はまだ何を安定化に対して死んでセットしていませんでした。 難しい問題の実装はまだ進んでいません。

1. アロケーター-多型コレクション
   
   
   
   • 肥大化していない箱すらありません！
   
   
2. 間違いのないコレクション

私は過去数ヶ月のために錆のために少し時間を持っていたが、時間でこれを主張している：私は基本的な形質のデザインは、これらのソリューションに影響を与えると思います。 ここでも完全に自分の主張をする時間があるとは思えないので、最初に少なくともそれらすべての完全な解決策を書いてくれることを願っています：厳密（正しい使用法を強制する）、柔軟性は不可能であると誰かが私に間違っていることを証明します、および現在の特性で人間工学的。 または、上部のチェックボックスをオンにします。

Re： @ Ericson2314のコメント

その視点と@alexcrichtonの何かを安定させたいという願望との対立に関連する質問は、最小限のインターフェースを安定させることでどれだけの利益が得られるかということだと思います。 特に、 Allocメソッドを直接呼び出す消費者はほとんどいないため（ほとんどのコレクションでさえ、おそらくBoxまたは他の同様のコンテナを使用します）、本当の問題は次のようになります。 Allocメソッドを直接呼び出していませんか？ 正直なところ、私が考えることができる唯一の深刻なユースケースは、アロケーター多型コレクション（はるかに幅広いユーザーセットによって使用される可能性が高い）への道を開くことですが、それは＃27336でブロックされているようです。解決されています。 私が見逃している他の大きな使用例があるかもしれませんが、その迅速な分析に基づいて、後で最適ではないとわかるかもしれない設計に私たちを閉じ込めるという犠牲を払って、わずかな利点しか持たないため、安定化から離れる傾向があります。

@joshlfを使用すると、

うーん良い点。 Allocを安定させることなく、グローバルアロケータの指定を安定させることは可能でしょうか？ つまり、 Allocを実装するコードは不安定である必要がありますが、それはおそらく独自のクレートにカプセル化され、そのアロケーターをグローバルアロケーターとしてマークするメカニズム自体は安定しています。 それとも、安定/不安定と安定コンパイラ/夜間コンパイラがどのように相互作用するかを誤解していますか？

ああ@joshlfは、 https： //github.com/rust-lang/rust/issues/42774#issuecomment -317279035にあるように、＃27336が気を散らすものであることを覚えておいて他の問題に遭遇するだろうと確信しています---存在する特性の問題。それが私が今それについての作業を開始するために働きたい理由です。 ＃27336以降の予測される先物について議論するよりも、すべての人が見ることができるようになったら、これらの問題について議論する方がはるかに簡単です。

@joshlfただし、グローバルアロケータを定義するクレートを安定したコンパイラでコンパイルすることはできません。

@sfacklerああ、そうだ、私が恐れていた誤解がある：P

usizeは（割り当てられた追加サイズのように）要求された割り当てのサイズではexcessではなく、 totalため、名前Excess(ptr, usize)は少し混乱します。割り当てのtotalサイズ。

IMO Total 、 Real 、 Usable 、またはサイズが割り当ての合計サイズまたは実際のサイズであることを示す名前は、私が見つけた「超過」よりも優れています誤解を招く。 同じことが_excessメソッドにも当てはまります。

上記の@gnzlbgに同意します。プレーンな（ptr、usize）タプルで十分だと思います。

ただし、 Excessは、最初のパスで安定化することは提案されていないことに注意してください。

懸念を持っている人がいるredditに関する議論のためにこのスレッドを投稿しました： https ：

今日@ rust-lang / libsとさらに話し合った後、安定化の提案にいくつかの調整を加えたいと思います。

• 安定化されたメソッドのセットにalloc_zeroedを追加します。それ以外の場合は、 allocと同じシグネチャを持ちます。
• extern { type void; }サポートを使用してAPIで*mut u8を*mut voidし、 @ dtolnayの懸念を解決し、エコシステム全体でc_voidを統合する方法を提供します。
• allocの戻り値の型を*mut voidに変更し、 ResultとError削除します

おそらく最も論議を呼んでいるのは最後の点なので、それについても詳しく説明したいと思います。 これは今日のlibsチームとの話し合いから生まれたもので、特に（a） ResultベースのインターフェースのABIの効率がポインターを返すものよりも低く、（b）今日の「本番」アロケーターがほとんどないことを中心に展開されました「これはただOOM'd」以上のものを学ぶ能力を提供します。 パフォーマンスのために、ほとんどの場合、インライン化などで紙に書くことができますが、 Errorは余分なペイロードであり、最下層で削除するのは困難です。

エラーのペイロードを返すための考え方は、アロケーターが実装固有のイントロスペクションを提供して、割り当てが失敗した理由を知ることができるということです。そうでない場合、ほとんどすべてのコンシューマーは、割り当てが成功したか失敗したかを知るだけで済みます。 さらに、これは実際にはそれほど頻繁に呼び出されない非常に低レベルのAPIであることが意図されています（代わりに、物事をうまくまとめる型付きAPIを代わりに呼び出す必要があります）。 その意味で、この場所で最も使いやすく人間工学に基づいたAPIを使用することは重要ではありませんが、パフォーマンスを犠牲にすることなくユースケースを有効にすることがより重要です。

*mut u8の主な利点は、バイトオフセットで.offsetを使用すると非常に便利なことです。

libsミーティングでは、 T: Sizedに対して定義されている既存のoffsetと競合しないimpl *mut void { fn offset }も提案しました。 byte_offsetます。

*mut voidおよびbyte_offsetを使用する場合*mut void +1。 externタイプ機能の安定化に問題が発生するのでしょうか、それとも定義のみが不安定であり（liballocは内部で不安定なことを実行できる）、使用ではないため（たとえば、 let a: *mut void = ... isn）、その問題を回避できますか？不安定ではない）？

はい、externタイプの安定化をブロックする必要はありません。 externタイプのサポートが削除された場合でも、これに対して定義するvoidは、常に魔法のタイプの最悪のケースになる可能性があります。

AllocとDeallocを別々の特性にするべきかどうかについて、libs会議でさらに議論がありましたか？

特に触れませんでしたが、特にやむを得ない理由がない限り、先行技術から逸脱するべきではないと一般的に感じていました。 特に、C ++のアロケーターの概念には同様の分割はありません。

この場合、それが適切な比較であるかどうかはわかりません。 C ++では、すべてが明示的に解放されるため、独自のアロケーターのコピー（または参照）を格納する必要があるBox相当するものはありません。 それが私たちにとって大きなサイズの爆発を引き起こす原因です。

std::unique_ptrは、「Deleter」では一般的です。

@joshlf unique_ptrはBoxに相当し、 vectorはVecに相当し、 unordered_mapはHashMap相当します

@cramertjああ、興味深いことに、私はコレクションの種類だけを見ていました。 その時はそれがやるべきことのようです。 後でブランケットimplを介していつでも追加できますが、それを回避する方がおそらくクリーンです。

包括的実装アプローチは、実際にはよりクリーンな場合があります。

pub trait Dealloc {
    fn dealloc(&self, ptr: *mut void, layout: Layout);
}

impl<T> Dealloc for T
where
    T: Alloc
{
    fn dealloc(&self, ptr: *mut void, layout: Layout) {
        <T as Alloc>::dealloc(self, ptr, layout)
    }
}

ほとんどのユースケースで心配する必要のある特性が1つ少なくなります。

• allocの戻り値の型を* mut voidに変更し、結果とエラーを削除します

おそらく最も論議を呼んでいるのは最後の点なので、それについても詳しく説明したいと思います。 これは今日のlibsチームとの話し合いから生まれたもので、特に（a）結果ベースのインターフェースのABIの効率がポインターを返すインターフェースよりも低く、（b）今日の「本番」アロケーターが学習機能を提供していないことを中心に展開されました。 「これはただOOM'd」以上のもの。 パフォーマンスのために、ほとんどの場合、インライン化などを使用して紙で覆うことができますが、エラーは、最下層で削除するのが難しい余分なペイロードであることに変わりはありません。

これにより、nullをチェックせずに返されたポインタを非常に簡単に使用できるようになるのではないかと心配しています。 Result<NonZeroPtr<void>, AllocErr>を返し、 AllocErrゼロサイズにすることで、このリスクを追加せずにオーバーヘッドを取り除くこともできるようです。

（ NonZeroPtrは、https：//github.com/rust-lang/rust/issues/27730#issuecomment-316236397で提案されているように、 ptr::Sharedとptr::Uniqueをマージしたものです。）

@SimonSapinのようなResult<NonZeroPtr<void>, AllocErr>ようなものは、安定化するために3つのタイプを必要とします。これらはすべて真新しいものであり、歴史的に安定化のためにかなり苦しんでいるものもあります。 voidようなものは必須ではなく、（私の意見では）持っておくと便利です。

「nullをチェックせずに簡単に使用できる」ことに同意しますが、これも非常に低レベルのAPIであり、頻繁に使用することを意図していないため、呼び出し元の人間工学に合わせて最適化する必要はないと思います。

また、 Result<NonZeroPtr<void>, AllocErr>ようなより複雑な戻り値の型を持つ可能性のある低レベルのalloc上に、 alloc_oneような高レベルの抽象化を構築することもできます。

AllocErrは実際には役に立たないことに同意しますが、 Option<NonZeroPtr<void>>どうでしょうか。 オーバーヘッドなしで誤って誤用することが不可能なAPIは、RustをCと区別するものの1つであり、Cスタイルのnullポインターに戻ることは私にとって一歩後退したように感じます。 「頻繁に使用することを意図していない非常に低レベルのAPI」であると言うことは、非常に低レベルであまり使用されていないため、一般的でないマイクロコントローラーアーキテクチャのメモリの安全性を気にするべきではないと言うようなものです。

この関数の戻り値の型に関係なく、アロケータとのすべての対話には安全でないコードが含まれます。 低レベルの割り当てAPIは、戻り値の型がOption<NonZeroPtr<void>>か*mut voidかに関係なく誤用される可能性があります。

特にAlloc::allocは、低レベルで頻繁に使用されることを意図していないAPIです。 Alloc::alloc_one<T>やAlloc::alloc_array<T>ようなメソッドは、より頻繁に使用され、「より良い」戻り値の型を持つ代替手段です。

ステートフルAllocErrorは価値がありませんが、Errorを実装し、 allocation failure Displayを持つゼロサイズの型があれば便利です。 私たちが行く場合はNonZeroPtr<void>ルートを、私は見Result<NonZeroPtr<void>, AllocError>よりも好ましいとOption<NonZeroPtr<void>> 。

安定化を急ぐ理由：（ !! Result<NonZeroPtr<void>, AllocErr>は、クライアントが使用するのに間違いなく優れています。これが「非常に低レベルのAPI」であり、優れている必要はないというのは、気のめいるように野心的です。すべてのレベルのコードは、可能な限り安全で保守可能です。常に編集されていない（したがって、人々の短期記憶にページングされていない）あいまいなコードはなおさらです！

さらに、私が確かに望んでいる、ユーザー作成のallocate-polymorphicコレクションがある場合、それはアロケーターを直接使用するかなり複雑なコードのオープン量です。

再デロアクション、運用上、ツリーベースのコレクションごとに1回だけアロアクターを参照/クローンしたいとほぼ確実に考えています。 これは、破棄される各カスタムアロケーターボックスにアロケーターを渡すことを意味します。 しかし、線形型を使用せずにRustでこれを行う最善の方法については未解決の問題です。 以前のコメントとは異なり、このためのコレクションの実装には安全でないコードが含まれていても問題ありません。理想的なユースケースでは、分割アロケーターとデアロケーターの特性の実装ではなく、 Boxの実装が変更されるためです。 つまり、直線性を妨げることなく、安定した進歩を遂げることができます。

@sfacklerデアロケーターをアロケーターに接続するいくつかの関連タイプが必要だと思います。 それらを後付けすることは不可能かもしれません。

@ Ericson2314人々は実世界の実物にアロケーターを使用したいので、安定させるための「ラッシュ」があります。 これは科学プロジェクトではありません。

その関連するタイプは何に使用されますか？

@sfacklerの人々はまだ毎晩ピン留めすることができます/そしてこの種の高度な機能を気にするタイプの人々はそれを快適に行うべきです。 [問題が不安定なrustcと不安定なRustである場合、それはポリシーの修正が必要な別の問題です。]逆に、新しい2.0 stdでエコシステムを分割したい場合を除いて、お粗末なAPIをベイクすることは私たちを永遠に妨げます。

関連するタイプは、デアロケーターをアロケーターに関連付けます。 これが機能するためには、それぞれが他のことを知る必要があります。 [正しいタイプの間違った（デ）アロケーターを使用するという問題はまだありますが、その解決策をリモートで提案した人は誰もいないことを認めます。]

人々が毎晩ピン留めできるのなら、なぜ私たちは安定したビルドを持っているのですか？ アロケーターAPIと直接対話している人々のセットは、グローバルアロケーターを置き換えるなどしてそれらのAPIを利用したい人々よりもはるかに少ないです。

デアロケーターが関連するアロケーターのタイプを知る必要がある理由を示すコードを記述できますか？ C ++のアロケータAPIが同様のマッピングを必要としないのはなぜですか？

人々が毎晩ピン留めできるのなら、なぜ私たちは安定したビルドを持っているのですか？

言語の安定性を示すため。 このバージョンのものに対して作成したコードは決して壊れません。 新しいコンパイラー。 非常に悪いものが必要な場合は毎晩ピン留めします。その保証に値する品質と見なされる機能の最後の反復を待つ価値はありません。

アロケーターAPIと直接対話している人々のセットは、グローバルアロケーターを置き換えるなどしてそれらのAPIを利用したい人々よりもはるかに少ないです。

あはは！ これは、jemallocをツリーから移動するためなどですか？ グローバルアロケータの選択を可能にするひどいハックを安定させることを提案した人は誰もいません。ヒープ自体を静的にするだけですか？ それとも私は提案を間違って読んだのですか？

グローバルアロケータの選択を可能にするひどいハックは安定化することが提案されています。これは、jemallocをツリーから移動できるようにするものの半分です。 この問題は残りの半分です。

#[global_allocator]属性の安定化： https ：

うわぁ

@ Ericson2314グローバルアロケータを選択するためのひどい方法は何だと思いますか？

（https://github.com/rust-lang/rust/issues/27389#issuecomment-342285805で返信）

提案は* mutvoidを使用するように修正されました。

@rfcbotが解決しました* mut u8

@rfcbotレビュー

IRC上でいくつかの議論の後、私たちは安定するつもりNOT_ARCHIVEDの_doことを理解した上で、これを承認していますBox上の汎用Alloc 、代わりにいくつかのDeallocで形質をここで@sfacklerによって提案されているように、適切なブランケットimpl。 意図を誤解した場合はお知らせください。

@cramertj明確にするために、Alloc定義を破らないようにすることは可能ですか？

@joshlfうん、次のようになります： https ：

どのように指定しますDealloc与えるためにAlloc ？ 私はこのようなものを想像しますか？

pub unsafe trait Alloc {
    type Dealloc: Dealloc = Self;
    ...
}

それは私たちを厄介な領域WRThttps ：//github.com/rust-lang/rust/issues/29661に置くと思い

ええ、私はのほか持つ方法ないと思うDeallocの既存の定義との下位互換性がAllocデフォルトを持たずに（つまり、関連するタイプを持たないが）。

アロケーターに対応するデアロケーターを自動的に取得できるようにする場合は、関連付けられたタイプだけでなく、デアロケーター値を生成する関数が必要になります。

しかし、これは将来、 Alloc別のサブトレイトに添付されたもので処理できると思います。

@sfackler理解できません。 あなたのデザインの下でBox::newの署名を書き出すことができますか？

これは配置構文とそのすべてを無視していますが、それを行うことができる1つの方法は

pub struct Box<T, D>(NonZeroPtr<T>, D);

impl<T, D> Box<T, D>
where
    D: Dealloc
{
    fn new<A>(alloc: A, value: T) -> Box<T, D>
    where
        A: Alloc<Dealloc = D>
    {
        let ptr = alloc.alloc_one().unwrap_or_else(|_| alloc.oom());
        ptr::write(&value, ptr);
        let deallocator = alloc.deallocator();
        Box(ptr, deallocator)
    }
}

特に、タイプを知るだけでなく、実際にデアロケーターのインスタンスを生成できる必要があります。 AllocもBoxをパラメーター化して、代わりにA::Deallocを格納することもできます。これは、型推論に役立つ場合があります。 Deallocとdeallocatorを別のトレイトに移動することで、この安定化の後にこれを機能させることができます。

pub trait SplitAlloc: Alloc {
    type Dealloc;

    fn deallocator(&self) -> Self::Dealloc;
}

しかし、 Dropの実装はどのようになりますか？

impl<T, D> Drop for Box<T, D>
where
    D: Dealloc
{
    fn drop(&mut self) {
        unsafe {
            ptr::drop_in_place(self.0);
            self.1.dealloc_one(self.0);
        }
    }
}

しかし、最初にAllocを安定させると仮定すると、すべてのAllocがDeallocを実装するわけではありません。 そして、私はimplの専門化はまだ道のりだと思いましたか？ つまり、理論的には次のようなことをしたいのですが、まだうまくいかないと思いますか？

impl<T, D> Drop for Box<T, D> where D: Dealloc { ... }
impl<T, A> Drop for Box<T, A> where A: Alloc { ... }

どちらかといえば、

default impl<T> SplitAlloc for T
where
    T: Alloc { ... }

しかし、それは本当に必要だとは思いません。 カスタムアロケータとグローバルアロケータのユースケースは十分に異なるため、それらの間に大量の重複があるとは思いません。

私はそれがうまくいくと思います。 しかし、私には、 Deallocすぐに使用して、より単純なインターフェイスを使用できるようにする方がはるかにクリーンに思えます。 すでにAlloc実装している既存のコードを変更する必要のない、非常にシンプルで議論の余地のないインターフェイスを作成できると思います。

unsafe trait Dealloc {
    fn dealloc(&mut self, ptr: *mut void, layout: Layout);
}

impl<T> Dealloc for T
where
    T: Alloc
{
    fn dealloc(&self, ptr: *mut void, layout: Layout) {
        <T as Alloc>::dealloc(self, ptr, layout)
    }
}

unsafe trait Alloc {
    type Dealloc: Dealloc = &mut Self;
    fn deallocator(&mut self) -> Self::Dealloc { self }
    ...
}

関連する型のデフォルトには問題がありましたが？

アロケータへの変更可能な参照であるDealloc 、それほど有用ではないようです。一度に割り当てることができるのは1つだけですよね？

関連する型のデフォルトには問題がありましたが？

ああ、関連する型のデフォルトは十分に離れているので、それらに頼ることはできないと思います。

それでも、もっと簡単にすることができます。

unsafe trait Dealloc {
    fn dealloc(&mut self, ptr: *mut void, layout: Layout);
}

impl<T> Dealloc for T
where
    T: Alloc
{
    fn dealloc(&self, ptr: *mut void, layout: Layout) {
        <T as Alloc>::dealloc(self, ptr, layout)
    }
}

unsafe trait Alloc {
    type Dealloc: Dealloc;
    fn deallocator(&mut self) -> Self::Dealloc;
    ...
}

実装者にボイラープレートを少し書くように要求するだけです。

アロケータへの変更可能な参照であるDealloc 、それほど有用ではないようです。一度に割り当てることができるのは1つだけですよね？

ええ、良い点です。 あなたの他のコメントを考えると、おそらくとにかく論点です。

deallocatorはself 、 &self 、または&mut self取る必要がありますか？

おそらく&mut selfは、他の方法と一貫性があるためです。

クローン状態などを必要としないように、値で自己を取ることを好むアロケーターはありますか？

selfを値で取得する場合の問題は、 Deallocを取得してから、割り当てを続行できないことです。

架空の「ワンショット」アロケーターを考えていますが、それがどれだけ本物かはわかりません。

このようなアロケータは存在する可能性がありますが、 selfを値で取得するには、_all_アロケータがそのように機能する必要があり、 deallocatorが呼び出された後にアロケータが割り当てを許可することはできません。

それを安定させることを考える前に、これのいくつかがコレクションで実装され、使用されることをまだ望んでいます。

あなたは思いますhttps://github.com/rust-lang/rust/issues/27336かで議論のポイントhttps://github.com/rust-lang/rust/issues/32838#issuecomment -339066870は私たちができるようになりますコレクションを進めますか？

タイプエイリアスアプローチがドキュメントの読みやすさに与える影響が心配です。 進行を許可する（非常に冗長な）方法は、タイプをラップすることです。

pub struct Vec<T>(alloc::Vec<T, Heap>);

impl<T> Vec<T> {
    // forwarding impls for everything
}

苦痛だとは思いますが、ここで説明している変更は十分に大きいため、alloc / deallocの分割特性を使用して進める場合は、最初にstdで試してから、再FCPを実行する必要があります。

このようなものが実装されるのを待つタイムラインは何ですか？

grow_in_placeメソッドは、いかなる種類の超過容量も返しません。 現在、レイアウトを使用してusable_sizeを呼び出し、このレイアウトに_少なくとも_適合するように割り当てを拡張しますが、割り当てがそのレイアウトを超えて拡張された場合、ユーザーは知る方法がありません。

alloc_excessおよびrealloc_excessに対するallocおよびreallocメソッドの利点を理解するのに苦労しています。

アロケータは、割り当てを実行するために適切なメモリブロックを見つける必要があります。これには、メモリブロックのサイズを知る必要があります。 次にアロケータがポインタを返すか、タプル「メモリブロックのポインタとサイズ」がパフォーマンスに測定可能な違いをもたらすことはありません。

したがって、 allocとreallocは、APIサーフェスを増やすだけで、パフォーマンスの低いコードの記述を促進しているようです。 なぜAPIにそれらがあるのですか？ 彼らの利点は何ですか？

編集：言い換えると、APIで割り当てられる可能性のあるすべての関数は、 Excessを返す必要があります。これにより、基本的にすべての_excessメソッドが不要になります。

過剰は、大きくなる可能性のある配列を含むユースケースでのみ興味深いものです。 たとえば、 BoxやBTreeMap 、役に立たないか、関連性がありません。 超過分を計算するのにいくらかのコストがかかる可能性があり、確かにもっと複雑なAPIがあるので、超過容量を気にしないコードがそれを支払うことを強制されるべきではないように思えます。

超過分を計算するには、いくらかのコストがかかる場合があります。

例を挙げていただけますか？ メモリを割り当てることはできるが、実際に割り当てられているメモリの量がわからないアロケータはわかりません。また、想像もできません（ Excessとは：割り当てられたメモリの実際の量です。名前を変更します）。

これが少し物議を醸すかもしれない唯一の一般的に使用されるAlloc atorは、POSIX malloc 。これは、常にExcess内部で計算しますが、Cの一部として公開しません。 API。 ただし、要求されたサイズをExcessとして返すことは問題なく、移植可能で、単純で、まったく費用がかからず、POSIX mallocを使用するすべての人がとにかくすでに想定していることです。

jemallocと基本的に他のAlloc atorは、コストをかけずにExcessを返すAPIを提供するため、これらのアロケーターの場合、 Excess返すことはゼロです。コストも。

超過分を計算するのにいくらかのコストがかかる可能性があり、確かにもっと複雑なAPIがあるので、超過容量を気にしないコードがそれを支払うことを強制されるべきではないように思えます。

現在、誰もがメモリを割り当てるための2つのAPIを持つアロケータトレイトの価格をすでに支払っています。 1を構築することができますしながらExcessの上に-less API Excess -full one`を、逆は真ではありません。 だから私はなぜそれがこのように行われないのだろうか：

• Alloc特性メソッドは常にExcess返します
• 1） Allocを使用するのに十分注意しているが、2）使用しないすべてのユーザーに対して、 AllocメソッドからExcessを削除するExcessLessAlloc特性を追加します。現在割り当てられている実際のメモリ量に注意してください（私にはニッチのように見えますが、そのようなAPIがあると便利だと思います）
• ある日、誰かがExcessなしのメソッドの高速パスを使用してAlloc atorを実装する方法を発見した場合、いつでもExcessLessAllocカスタム実装を提供できます。

FWIW Alloc上に必要なものを実装できないため、このスレッドに再びアクセスしました。 以前にgrow_in_place_excessが欠落していると述べましたが、 alloc_zeroed_excessも欠落しているため（そして誰が他に何を知っているか）、再び行き詰まりました。

ここでの安定化が、最初にExcess -fullAPIの安定化に焦点を合わせればもっと快適になります。 そのAPIがすべての用途で最も人間工学的ではない場合でも、そのようなAPIは少なくともすべての用途を許可します。これは、設計に欠陥がないことを示すために必要な条件です。

例を挙げていただけますか？ メモリを割り当てることはできるが、実際に割り当てられているメモリの量がわからないアロケータはわかりません。また、想像もできません（ Excessとは：割り当てられたメモリの実際の量です。名前を変更します）。

今日のほとんどのアロケータはサイズクラスを使用します。各サイズクラスは特定の固定サイズのオブジェクトのみを割り当て、特定のサイズクラスに適合しない割り当て要求は、内部に適合する最小サイズクラスに切り上げられます。 このスキームでは、サイズクラスオブジェクトの配列を作成してからclasses[size / SIZE_QUANTUM].alloc()を実行するのが一般的です。 その世界では、どのサイズのクラスが使用されているかを理解するには、追加の指示が必要です。たとえば、 let excess = classes[size / SIZE_QUANTUM].size 。 それほど多くはないかもしれませんが、高性能アロケータ（jemallocなど）のパフォーマンスは単一のクロックサイクルで測定されるため、特にそのサイズが関数のリターンのチェーンを通過する場合は、意味のあるオーバーヘッドを表す可能性があります。

例を挙げていただけますか？

少なくともPRからalloc_jemallocに移行すると、 alloc_excessはallocよりも明らかに多くのコードを実行しています： https ：

このスキームでは、サイズクラスオブジェクトの配列を作成してからclasses [size / SIZE_QUANTUM] .alloc（）を実行するのが一般的です。 その世界では、使用されているサイズクラスを把握するには、追加の手順が必要です。たとえば、excess = classes [size / SIZE_QUANTUM] .sizeとします。

だから私が正しく従うかどうか見てみましょう：

// This happens in both cases:
let size_class = classes[size / SIZE_QUANTUM];
let ptr = size_class.alloc(); 
// This would happen only if you need to return the size:
let size = size_class.size;
return (ptr, size);

それですか？

少なくともPRからalloc_jemallocに移行すると、alloc_excessはallocよりも明らかに多くのコードを実行しています。

そのPRはバグ修正（パフォーマンス修正ではありません）でした。パフォーマンスに関しては、jemallocレイヤーの現在の状態に多くの問題がありますが、そのPRなので、少なくとも次のようになります。

• nallocxは、GCCの意味でのconst関数、つまり真の純粋関数です。 これは、副作用がなく、結果が引数のみに依存し、グローバル状態にアクセスせず、引数がポインターではないことを意味します（したがって、関数はグローバル状態にアクセスできず、それらをスローします）。C/ C ++プログラムの場合、LLVMはこれを使用できます。結果が使用されない場合に呼び出しを削除するための情報。 AFAIK Rustは現在、FFIC関数をconst fnなどとしてマークすることはできません。 したがって、これは修正できる最初のことであり、インライン化と最適化が適切に機能する限り、超過分を使用しない場合はrealloc_excessゼロコストになります。
• nallocxは、常にmallocx内の整列された割り当てに対して計算されます。つまり、すべてのコードはすでにそれを計算していますが、 mallocxは結果を破棄するため、ここでは実際に2回計算しています。 、場合によってはnallocxはmallocx nallocxとほぼ同じくらい高価です...ブランチにこのようなもののベンチマークがあるjemallocatorのフォークがありますが、これはアップストリームで修正する必要がありますこれを捨てないAPIを提供することによるjemalloc。 ただし、この修正は、現在Excessを使用しているものにのみ影響します。
• そして、それは私たちが整列フラグを2回計算しているという問題ですが、それはLLVMが私たちの側で最適化できるものです（そして修正するのは簡単です）。

そうです、それはより多くのコードのように見えますが、この余分なコードは、実際に2回呼び出しているコードです。これは、最初に呼び出したときに結果を破棄したためです。 修正することは不可能ではありませんが、私はまだこれを修正する時間を見つけていません。

編集： @sfackler今日はなんとか時間をallocに関してalloc_excess 「無料」にすることができ、オーバーヘッドは約1nsしかありませんでした。 jemallocsの高速パス。 ファストパスについてはあまり詳しく調べていませんが、これをさらに改善できる可能性があります。 詳細はこちら： https ：

それですか？

はい。

したがって、これは修正できる最初のことであり、インライン化と最適化が適切に機能する限り、超過分を使用しない場合はrealloc_excessのコストをゼロにします。

グローバルアロケータとして使用する場合、これをインライン化することはできません。

そのAPIがすべての用途で最も人間工学的ではない場合でも、そのようなAPIは少なくともすべての用途を許可します。これは、設計に欠陥がないことを示すために必要な条件です。

alloc_excessを呼び出すGithubには文字通りゼロのコードがあります。 これが非常に重要な機能である場合、なぜ誰もそれを使用したことがないのですか？ C ++の割り当てAPIは、過剰な容量へのアクセスを提供しません。 これらの機能がパフォーマンスを向上させるという実際の具体的な証拠があり、誰もが実際にそれらを使用するのに十分気を配っている場合、下位互換性のある方法で将来これらの機能を追加/安定化することは非常に簡単に思えます。

グローバルアロケータとして使用する場合、これをインライン化することはできません。

jemallocようなグローバルアロケータはこれに依存しているため、少なくともLTOビルドでは、これを解決する必要があります。 nallocxは、_設計による_方法であり、最初の推奨事項です。 jemallocの開発者は、 alloc_excessパフォーマンスに関して、これらの呼び出しをインライン化する必要があり、C属性を適切に伝播して、コンパイラーが呼び出しサイトからnallocx呼び出しを削除するようにしました。 CおよびC ++コンパイラと同様に、 Excess使用します。

それができない場合でも、 jemalloc APIにパッチを適用することで、 Excess APIをゼロコストにすることができます（このようなパッチの初期実装は、rust-lang /にあります。 jemallocフォーク）。 そのAPIを自分で維持することも、アップストリームに配置することもできますが、アップストリームに配置するには、これらの他の言語がこれらの最適化を実行でき、Rustが実行できない理由について適切なケースを作成する必要があります。 または、この新しいAPIは、 Excess必要とするユーザーにとって、 mallocx + nallocxよりも大幅に高速であるなどの別の引数が必要です。

これが非常に重要な機能である場合、なぜ誰もそれを使用したことがないのですか？

それは良い質問です。 std::Vecは、 Excess APIを使用するためのポスターの子ですが、現在は使用していません。以前のコメントはすべて、「これとそれはExcessから欠落しています。 API」は私がVecそれを使わせようとしていました。 Excess API：

• Excessをまったく返さなかった： https ：
• grow_in_place_excessやalloc_zeroed_excessなどの機能が不足しています。
• FFIでC属性を正しく伝播できない： https ：
• ...（ここで終わるとは思えません）

なぜ誰もこのAPIを使用していないのかわかりません。 しかし、 stdライブラリでさえ、それが最適なデータ構造（ Vec ）に使用できないことを考えると、推測しなければならない場合、主な理由は次のとおりです。このAPIは現在壊れています。

さらに推測しなければならない場合、主に単一のstdコレクションが使用していないため（このAPIが最初にテストされると予想される場所）、このAPIを設計した人でさえ使用していないと言えます。また、 _excessとExcessどこでも使用してusable_size / allocation_sizeを意味するのは、プログラミングが非常に混乱し、煩わしいためです。

これはおそらく、 Excess少ないAPIにより多くの作業が費やされ、2つのAPIがある場合、それらの同期を維持するのが難しく、ユーザーが両方を見つけてどちらを使用するかを知るのが難しいためです。そして最後に、ユーザーが正しいことをするよりも便利さを好むのは難しいです。

つまり、競合するAPIが2つあり、作業の100％を一方の改善に、0％を他方の改善に費やした場合、一方が実際に大幅に機能しているという結論に達するのは当然のことです。他よりも優れています。

私の知る限り、Githubでのjemallocテスト以外のnallocxへの呼び出しは2つだけです。

https://github.com/facebook/folly/blob/f2925b23df8d85ebca72d62a69f1282528c086de/folly/detail/ThreadLocalDetail.cpp#L182
https://github.com/louishust/mysql5.6.14_tokudb/blob/4897660dee3e8e340a1e6c8c597f3b2b7420654a/storage/tokudb/ft-index/ftcxx/malloc_utils.hpp#L91

どちらも現在のalloc_excess APIに似ていませんが、スタンドアロンで使用されて、割り当てサイズが作成される前に計算されます。

Apache Arrowは、実装でnallocxを使用することを検討しましたが、うまく機能しないことがわかりました。

https://issues.apache.org/jira/browse/ARROW-464

これらは基本的に私が見つけることができるnallocxへの唯一の参照です。 アロケーターAPIの最初の実装がそのようなあいまいな機能をサポートすることが重要なのはなぜですか？

私の知る限り、Githubでのjemallocテスト以外のnallocxへの呼び出しは2つだけです。

私の頭のてっぺんから、少なくともfacebookのベクタータイプがfacebookのmalloc実装を介してそれを使用していることを知っています（ mallocとfbvectorの成長ポリシー;これはfacebookのC ++のベクターの大きな塊です）そしてまたChapelはそれを改善するために使用しましたStringタイプのパフォーマンス（ここと追跡の問題）。 では、今日はGithubの最高の日ではなかったのでしょうか。

アロケーターAPIの最初の実装がそのようなあいまいな機能をサポートすることが重要なのはなぜですか？

アロケータAPIの最初の実装では、この機能をサポートする必要はありません。

ただし、この機能を適切にサポートすると、そのようなAPIの安定化がブロックされるはずです。

逆方向に追加できるのに、なぜ安定化をブロックする必要があるのですか？後で互換性がありますか？

逆方向に追加できるのに、なぜ安定化をブロックする必要があるのですか？後で互換性がありますか？

少なくとも私にとっては、デザインスペースの半分だけが十分に調査されていることを意味します。

APIの過剰に関連しない部分は、過剰に関連する機能の設計によって影響を受けると思いますか？ 私はその議論に中途半端にしか従わなかったことを認めますが、それは私にはありそうもないようです。

このAPIを作成できない場合：

fn alloc(...) -> (*mut u8, usize) { 
   // worst case system API:
   let ptr = malloc(...);
   let excess = malloc_excess(...);
   (ptr, excess)
}
let (ptr, _) = alloc(...); // drop the excess

これと同じくらい効率的：

fn alloc(...) -> *mut u8 { 
   // worst case system API:
   malloc(...)
}
let ptr = alloc(...);

それから私達はより大きな問題を抱えています。

APIの過剰に関連しない部分は、過剰に関連する機能の設計によって影響を受けると思いますか？

そうです、私は、過剰なAPIが、過剰に関連しない機能の設計に大きな影響を与えることを期待しています。それは完全に削除されます。

これにより、2つのAPIが同期しておらず、excess-apiの機能がexcess-lessのAPIよりも少ないという現在の状況を防ぐことができます。 過剰なAPIの上に過剰な少ないAPIを構築することはできますが、その逆は当てはまりません。

Excessをドロップしたい人は、それをドロップする必要があります。

明確にするために、下位互換性のある方法で事後にalloc_excessメソッドを追加する方法があれば、それで大丈夫ですか？ （もちろん、 alloc_excessなしで安定させるということは、後で追加することは重大な変更になることを意味します。私はただ尋ねているので、あなたの理由を理解しています）

@joshlfそれを行うのは非常に簡単です。

：bell：上記のこれは現在、最終コメント期間に入っています。 ：ベル：

超過分をドロップしたい人はそれをドロップする必要があります。

あるいは、過剰な容量を気にする0.01％の人が別の方法を使用できます。

@sfacklerこれは、錆から2週間の休憩を取ることで得られるものです-デフォルトのメソッドimplsを忘れています:)

あるいは、過剰な容量を気にする0.01％の人が別の方法を使用できます。

この番号はどこで入手できますか？

私のRustデータ構造はすべてメモリ内でフラットです。 それを実行できることが、私がRustを使用する唯一の理由です。 すべてをボックス化できれば、別の言語を使用することになります。 だから私はいつもExcess 0.01%を気にしません、私はいつもそれを気にします。

これはドメイン固有であり、他のドメインではExcess気にしないことは理解していますが、Rustユーザーの0.01％だけがこれを気にかけているとは思えません（つまり、多くの人がVec使用しています） String 、 Excess子のデータ構造です）。

この数は、mallocを使用するもののセットと比較して、nallocxを使用するものが合計で約4つあるという事実から得ています。

@gnzlbg

最初から「正しく」実行した場合、 fn alloc(layout) -> (ptr, excess)あり、 fn alloc(layout) -> ptrはまったくないことを示唆していますか？ それは私には明らかではないようです。 超過分が利用できる場合でも、 alloc_excess(layout).0として実装されている場合でも、超過分が問題にならないユースケース（ほとんどのツリー構造など）には後者のAPIを使用するのが自然なようです。

@rkruppe

それは私には明らかではないようです。 超過が利用可能であっても、alloc_excess（layout）.0として実装されている場合でも、超過が問題にならないユースケース（ほとんどのツリー構造など）に後者のAPIを使用するのは自然なことのようです。

現在、excess-full APIは、excess-lessAPIの上に実装されています。 超過のないアロケータにAllocを実装するには、ユーザーがalloc deallocメソッドと

ただし、excess-fullアロケータにAllocを実装する場合は、さらに多くのメソッドを提供する必要があります（少なくとも、 alloc_excessですが、 realloc_excessに入ると、これは大きくなります。 alloc_zeroed_excess 、 grow_in_place_excess 、...）。

逆の場合、つまり、excess-less APIをexcess-full APIの上に優れたものとして実装し、 alloc_excessとdealloc実装するだけでサポートできます。両方のタイプのアロケータ。

超過分を気にしない、または返送または照会できないユーザーは、入力サイズまたはレイアウトを返すことができますが（これは小さな不便です）、超過分を処理でき、処理したいユーザーは実装する必要はありません。これ以上の方法。

@sfackler

この数は、mallocを使用するもののセットと比較して、nallocxを使用するものが合計で約4つあるという事実から得ています。

Rustエコシステムでの_excess使用に関するこれらの事実を考えると：

• 錆びた生態系で合計0個が_excessを使用
• ruststdライブラリで合計0個が_excessしています
• VecとStringさえ、錆びたstdライブラリで_excess APIを適切に使用できません

• _excess APIは不安定で、excess-less APIと同期しておらず、ごく最近までバグがありました（ excessをまったく返さなかった）...

  そして、他の言語での_excessの使用法に関するこれらの事実を考えると：

• jemallocのAPIは、下位互換性のため、CまたはC ++プログラムではネイティブにサポートされていません。

• jemallocの過剰なAPIを使用したいCおよびC ++プログラムは、次の方法でそれを使用するために邪魔にならないようにする必要があります。
  
  
  
  • システムアロケーターからjemalloc（またはtcmalloc）へのオプトアウト
  
  
  • 言語の標準ライブラリを再実装します（C ++の場合、互換性のない標準ライブラリを実装します）
  
  
  • この互換性のない標準ライブラリの上にスタック全体を書き込みます
  
  
• 一部のコミュニティ（Firefoxはこれを使用し、FacebookはC ++標準ライブラリのコレクションを再実装して使用できるようにします...）は、まだ使用できません。

これらの2つの議論は私にはもっともらしく見えます：

• stdのexcess APIは使用できないため、 stdライブラリは使用できません。したがって、誰も使用できません。そのため、Rustエコシステムでは一度も使用されません。 。
• CとC ++では、このAPIを使用することはほぼ不可能ですが、人的資源を伴う大規模なプロジェクトでは、このAPIを使用するのに非常に長い時間がかかります。したがって、少なくとも一部の潜在的に小さなコミュニティは、このAPIを気にかけています。

あなたの議論：

• _excess APIを使用している人はいないため、気にする人は0.01％にすぎません。

ではない。

@alexcrichton -> Result<*mut u8, AllocErr>から-> *mut voidに切り替えるという決定は、アロケーターRFCの最初の開発に従った人々にとって大きな驚きとなるかもしれません。

私は同意していないあなたが作るのポイントが、それにもかかわらず、人々のかなりの数は、の「重weightness」と一緒に暮らすに喜んであったであろうように思えたResult nullでは不足している可能性の増加を介して戻り値を確認してください。

• @alexcrichtonのように、コンパイラのトリックを介して何らかの方法でそれらに対処できると想定しているため、ABIによって課せられる実行時効率の問題を無視しています。

その遅い変更自体の可視性を高める方法はありますか？

1つの方法（頭のてっぺんから）： Allocatorがまだ不安定な状態で、PR自体のマスターブランチで署名を変更します。 そして、誰がPRに不満を言っているのか（そして誰が祝っているのか！）を見てください。

• これは手に負えないですか？ 定義上、このような変更を安定化と組み合わせるよりも手間がかからないようです...

*mut voidを返すか、 Result<*mut void, AllocErr>を返すかについて：説明したように、「高レベル」と「低レベル」のアロケータ特性を分離するという考えを再検討する必要がある可能性があります。アロケーターRFCのテイクIIで。

（明らかに、 *mut void戻り値に深刻な異議がある場合は、fcpbotを介して懸念事項として提出します。しかし、現時点では、おそらく、libsチームの判断をかなり信頼しています。このアロケーターサガの疲労による部分もあります。）

@pnkfelix

-> Result<*mut u8, AllocErr>から-> *mut voidに切り替えるという決定は、アロケーターRFCの最初の開発に従った人々にとって大きな驚きとなるかもしれません。

後者は、説明したように、私たちが表現したい唯一のエラーはOOMであることを意味します。 したがって、エラーをチェックするための偶発的な失敗に対する保護の利点をまだ持っている、わずかに軽量な中間は-> Option<*mut void>です。

@gnzlbg

stdの余分なAPIは使用できないため、stdライブラリは使用できません。したがって、誰も使用できません。そのため、Rustエコシステムでは一度も使用されません。

次に、それを修正します。

@pnkfelix

mut voidを返すか、

高レベルAPIがalloc_one 、 alloc_arrayなどとしてAlloc自体に含まれることを除いて、これらは基本的に私たちの考えalloc_array 。拡張機能として最初にエコシステムで開発させることもできます。人々がどのAPIに収束するかを確認するための特性。

@pnkfelix

レイアウトにコピーではなくクローンのみを実装させた理由は、レイアウトタイプに構造を追加する可能性を残したかったからです。 特に、レイアウトがそれを構築するために使用される任意の型構造（たとえば、構造体の16配列{x：u8、y：[char; 215]}）を追跡しようとすることにまだ興味があります。現在のコンテンツがどのタイプから構成されているかをレポートするインストルメンテーションルーチンを公開するオプション。

これはどこかで実験されましたか？

@sfackler私はすでにそのほとんどを実行しており、すべてを複製されたAPIで実行できます（超過なし+ _excessメソッド）。 現在、2つのAPIがあり、完全な_excess APIがなくても問題ありません。

まだ少し心配しているのは、アロケータを今すぐ実装するにはalloc + deallocを実装する必要があるということだけですが、 alloc_excess + deallocも同様に機能するはずです。 alloc alloc_excess後で

jemallocatorはAlloc 2回実装します（ Jemallocと&Jemalloc ）。ここで、一部のmethodのJemalloc実装はメソッド呼び出しを&Jemalloc実装に転送する(&*self).method(...) 。 これは、 JemallocのAlloc両方の実装を手動で同期させる必要があることを意味します。 &/_実装で異なる動作をすることが悲劇的であるかどうかは、私にはわかりません。

実際にAlloc特性を使って人々が実際に何をしているのかを知るのは非常に難しいと思いました。 それを使用していることがわかった唯一のプロジェクトは、とにかく毎晩使用し続け（サーボ、レドックス）、グローバルアロケーターを変更するためにのみ使用しています。 それをコレクションタイプのパラメータとして使用するプロジェクトが見つからなかったのはとても心配です（たぶん私は運が悪かっただけで、いくつかありますか？）。 私は特に、 Vecようなタイプの上にSmallVecとArrayVecを実装する例を探していました（ std::VecはAllocがないため） Vecが異なるAlloc atorを使用）がどのように機能するのか疑問に思っていました（同じことがおそらくBoxクローン作成にも当てはまります）異なるAlloc sのBox es）。 これらの実装がどこかにどのように見えるかの例はありますか？

私が見つけた、それを使用している唯一のプロジェクトは、とにかく毎晩使用し続けるつもりです（サーボ、レドックス）

価値があるものとして、Servoは可能な限り不安定な機能から移行しようとしています： https ：

これも鶏が先か卵が先かという問題です。 多くのプロジェクトはまだ不安定なため、 Allocまだ使用していません。

そもそもなぜ_excessAPIを完全に補完する必要があるのか​​は私にはよくわかりません。 これらは元々、jemallocの実験的な* allocm APIを反映するために存在していましたが、APIサーフェス全体を複製しないために、数年前に4.0で削除されました。 私たちは彼らの先導に従うことができたようですか？

後でalloc_excessに関してallocにデフォルトの実装を与えることは可能でしょうか、それとも不可能であるか、重大な変更でしょうか？

alloc_excessに関してallocデフォルトの実装を追加できますが、 alloc_excessはallocに関してデフォルトの実装が必要です。 一方または両方を実装すればすべて正常に機能しますが、どちらも実装しないと、コードはコンパイルされますが、無限に再帰します。 これは以前に発生したことがあり（おそらくRand ？）、これらの関数の少なくとも1つを実装する必要があると言うことができますが、どちらでもかまいません。

それをコレクションタイプのパラメータとして使用するプロジェクトが見つからなかったのはとても心配です（たぶん私は運が悪かっただけで、いくつかありますか？）。

私はそれをしている人を知りません。

私が見つけた、それを使用している唯一のプロジェクトは、とにかく毎晩使用し続けるつもりです（サーボ、レドックス）

これが前進するのを妨げる大きなことの1つは、stdlibコレクションがパラメトリックアロケーターをまだサポートしていないことです。 ほとんどの外部コレクションは内部のもの（ Box 、 Vecなど）を使用するため、これは他のほとんどのクレートもほとんど排除します。

私が見つけた、それを使用している唯一のプロジェクトは、とにかく毎晩使用し続けるつもりです（サーボ、レドックス）

これが前進するのを妨げる大きなことの1つは、stdlibコレクションがパラメトリックアロケーターをまだサポートしていないことです。 ほとんどの外部コレクションは内部のもの（Box、Vecなど）を使用するため、これは他のほとんどのクレートもほとんど排除します。

これは私にも当てはまります-私はおもちゃのカーネルを持っています、そしてもし私がVec<T, A>を使うことができれば、代わりに私は内部で変更可能なグローバルアロケーターファサードを持たなければなりません。

@remexreデータ構造をパラメータ化して、

内部的に変更可能なグローバル状態はまだ存在すると思いますが、グローバルset_allocator関数を使用するよりも、メモリが完全にマップされるまでグローバルアロケーターを使用できないように設定する方がはるかに安全だと感じます。

編集：私が質問に答えなかったことに気づきました。 今、私は次のようなものを持っています：

struct BumpAllocator{ ... }
struct RealAllocator{ ... }
struct LinkedAllocator<A: 'static + AreaAllocator> {
    head: Mutex<Option<Cons<A>>>,
}
#[global_allocator]
static KERNEL_ALLOCATOR: LinkedAllocator<&'static mut (AreaAllocator + Send + Sync)> =
    LinkedAllocator::new();

ここで、 AreaAllocatorは、アロケーターが（割り当て先のアドレス範囲に関して）誤って「オーバーラップ」していないことを（実行時に）確認できる特性です。 BumpAllocatorは、メモリの残りの部分をマッピングしてRealAllocatorを作成するときのスクラッチスペースとして、非常に早い段階でのみ使用されます。

理想的には、 Mutex<Option<RealAllocator>> （または「挿入専用」にするラッパー）を唯一のアロケーターにし、早期に割り当てられたすべてのものをアーリーブートBumpAllocatorでパラメーター化するようにします。

@sfackler

そもそもなぜ_excessAPIを完全に補完する必要があるのか​​は私にはよくわかりません。 これらは元々、jemallocの実験的な* allocm APIを反映するために存在していましたが、APIサーフェス全体を複製しないために、数年前に4.0で削除されました。 私たちは彼らの先導に従うことができたようですか？

現在、 shrink_in_placeはxallocxを呼び出し、実際の割り当てサイズを返します。 shrink_in_place_excessは存在しないため、このサイズは破棄され、ユーザーはnallocxを呼び出して再計算する必要があります。そのコストは、割り当ての大きさによって異なります。

したがって、すでに使用している少なくともいくつかのjemalloc割り当て関数は、使用可能なサイズを返しますが、現在のAPIではそれを使用できません。

@remexre

私がおもちゃのカーネルで作業していたとき、グローバルアロケーターを避けて、アロケーターがセットアップされるまで割り当てが行われないようにすることも私の目標でした。 私が一人ではないと聞いてうれしいです！

デフォルトのグローバルアロケータのHeapという単語は好きではありません。 なぜDefaultないのですか？

もう1つの明確化のポイント： RFC 1974は、これらすべてのものをstd::allocいますが、現在はstd::heapます。 安定化のためにどの場所が提案されていますか？

@jethrogb 「ヒープ」は、「mallocがあなたにポインタを与えるもの」のかなり標準的な用語です-この用語に対するあなたの懸念は何ですか？

@sfackler

「mallocがあなたにポインタを与えること」

私の頭の中を除いて、それがSystemです。

確かに。 Globalは別の名前ですが、多分？ #[global_allocator]を使用して選択するため。

複数のヒープアロケーターが存在する可能性があります（例：libcおよび接頭辞jemalloc）。 std::heap::Heap名前をstd::heap::Default 、 #[global_allocator]名前を#[default_allocator]どうですか？

他に指定しない場合（おそらくVecがアロケータの追加の型パラメータ/フィールドを取得する場合）に得られるものであるという事実は、「per」がないという事実よりも重要です。 -インスタンス」状態（または実際にはインスタンス）。

これで最終コメント期間が終了しました。

FCPに関しては、安定化のために提案されたAPIサブセットの用途は非常に限られていると思います。 たとえば、 jemallocatorクレートはサポートしていません。

どのように？ jemallocatorは、機能フラグの背後にある不安定なメソッドのいくつかの実装にフラグを立てる必要があるかもしれませんが、それだけです。

安定したRustのjemallocatorがje_rallocx呼び出してAlloc::reallocなどを実装できないが、デフォルトのalloc + copy + dealloc implに依存する必要がある場合、それは標準ライブラリのalloc_jemallocクレートIMO。

確かに、コンパイルするものを入手することはできますが、それは特に便利なことではありません。

どうして？ C ++のアロケーターAPIには、reallocの概念がまったくなく、言語が機能しなくなったようには見えません。 それは明らかに理想的ではありませんが、なぜそれが受け入れられないのか理解できません。

C ++移動コンストラクターは任意のコードを実行できるため、C ++コレクションは通常reallocを使用しません。これは、reallocが役に立たないためではありません。

また、比較はC ++ではなく、jemallocサポートが組み込まれた現在のRust標準ライブラリとの比較です。 Alloc APIのこのサブセットのみを使用して、標準外のアロケーターに切り替えると、リグレッションが発生します。

そしてreallocはその一例です。 jemallocatorは現在、 alloc_zeroed 、 alloc_excess 、 usable_size 、 grow_in_placeなども実装しています。

alloc_zeroedは安定化するように提案されています。 私が知る限り（アップスレッドを参照）、 alloc_excess使用は文字通りゼロです。 デフォルトの実装にフォールバックした場合にリグレッションを起こすコードをいくつか示していただけませんか。

しかし、もっと一般的には、これがこれらのAPIの一部を安定させることに反対する議論である理由がわかりません。 jemallocatorを使用したくない場合は、引き続き使用しないでください。

Layout::array<T>() const fnにすることはできますか？

パニックになる可能性があるので、現時点ではありません。

パニックになる可能性があるので、現時点ではありません。

なるほど... const fn Layout::array_elem<T>()で解決します。これは、パニックにならないLayout::<T>::repeat(1).0相当します。

@mzabaluevあなたが説明していることはLayout::new<T>()と同等だと思います。 現在パニックになる可能性がありますが、それはLayout::from_size_align 、次に.unwrap()を使用して実装されているためであり、別の方法で実行できると思います。

@joshlfこの構造体のサイズは5だと思いますが、配列の要素として、これらは配置のために8バイトごとに配置されます。

struct Foo {
    bar: u32,
    baz: u8
}

Foo配列に、サイズ計算の最後の要素のパディングが含まれるかどうかはわかりませんが、それは私の強い期待です。

Rustでは、オブジェクトのサイズは常にその配置の倍数であるため、配列のn番目の要素のアドレスは常にarray_base_pointer + n * size_of<T>()です。 したがって、配列内のオブジェクトのサイズは、それ自体のオブジェクトのサイズと常に同じです。 詳細については、 repr（Rust）の

OK、構造体がその配置に埋め込まれていることがわかりましたが、これは#[repr(C)]を除いて、安定した保証ではありません。
とにかく、 Layout::new constfnにすることも歓迎されます。

これは、安定した関数の文書化された（そして保証された）動作です。

https://doc.rust-lang.org/std/mem/fn.size_of.html

タイプのサイズをバイト単位で返します。

より具体的には、これは、配列のパディングを含むそのアイテムタイプを持つ配列内の連続する要素間のバイト単位のオフセットです。 したがって、タイプTおよび長さn場合、 [T; n]のサイズはn * size_of::<T>()ます。

ありがとう。 Layout::newの結果を乗算するconst fnは、（ saturating_mulなどで実行されない限り）本質的にパニックになることに気付いたので、正方形に戻ります。 constfn追跡問題のパニックについての質問を続けます。

panic!()マクロは現在、定数式ではサポートされていませんが、チェックされた算術によるパニックはコンパイラーによって生成され、その制限の影響を受けません。

error[E0080]: constant evaluation error
 --> a.rs:1:16
  |
1 | const A: i32 = i32::max_value() * 2;
  |                ^^^^^^^^^^^^^^^^^^^^ attempt to multiply with overflow

error: aborting due to previous error

これはAlloc::realloc関連していますが、最小インターフェースの安定化には関連していません（ reallocはその一部ではありません）：

現在、理由はVec::reserve/double呼んRawVec::reserve/double呼んでAlloc::realloc 、のデフォルトのimpl Alloc::realloc （でコピー死んでベクトル要素[len(), capacity())の範囲） 。 capacity() + 1要素を挿入して再割り当てする巨大な空のベクトルの不条理なケースでは、そのすべてのメモリに触れるコストは重要ではありません。

理論的には、デフォルトのAlloc::realloc実装も「bytes_used」の範囲を取る場合、再割り当て時に関連する部分をコピーするだけで済みます。 実際には、少なくともjemallocはrallocx呼び出しでAlloc::reallocデフォルトのimplをオーバーライドします。 alloc / deallocダンスを行うかどうか、関連するメモリのみをコピーすることは、 rallocx呼び出しよりも速いか遅いかは、おそらく多くのことに依存します（ rallocx管理しますかブロックを所定の位置に拡張するには？ rallocxコピーする不要なメモリの量など）。

https://github.com/QuiltOS/rust/tree/allocator-error一般化自体を実行することで、関連するエラータイプがコレクションとエラー処理の問題をどのように解決すると思うかを示し始めました。 特に、モジュールでどのように変更するかに注意してください。

• T実装には、常にResult<T, A::Err>実装を再利用してください
• unwrapまたはその他の部分的なものは決してありません
• ノーoom(e)外のAbortAdapter 。

これは、私が行っている変更が非常に安全であり、まったく無意味であることを意味します。 エラーを返すこととエラーを中止することの両方を扱うことは、精神的な不変条件を維持するために余分な努力を必要とすべきではありません---タイプチェッカーはすべての仕事をします。

私は思い出します---私は@GankroのRFCで思いますか？ またはrfc以前のスレッド--- Gecko / Servoの人々は、コレクションの誤りをタイプの一部にしないのは良かったと言っています。 ええと、 #[repr(transparent)]をAbortAdapter追加して、コレクションをFoo<T, A>とFoo<T, AbortAdapter<A>>間で安全に変換できるようにすることができます（安全なラッパー内で）。すべてのメソッドを複製せずに前後に切り替えます。 [バックコンパットの場合、いずれにしても標準ライブラリコレクションを複製する必要がありますが、 Result<T, !>は最近非常に扱いやすいため、ユーザーメソッドを複製する必要はありません。]

残念ながら、langアイテム（ボックス）の型パラメーターを変更するとコンパイラーが混乱するため、コードは完全に型チェックを行いません（驚きです！）。 ICEを引き起こすボックスコミットは最後のものです---それが良い前のすべて。 @eddybは＃47043で

編集@joshlf私はあなたのhttps://github.com/rust-lang/rust/pull/45272を知らされ、それをここに組み込みました。 ありがとう！

永続メモリ（例： http ：

私は最近、永続メモリアロケータ（具体的にはlibpmemcto）のRustラッパーに取り組んでいます。 このAPIの安定化に関してどのような決定が下されても、次のことを行う必要があります。-

• libpmemctoのような永続メモリアロケータのパフォーマンスラッパーをサポートできます。
• アロケータによってコレクションタイプを指定（パラメータ化）できる（現時点では、Box、Rc、Arcなどを複製する必要があります）
• アロケーター間でデータのクローンを作成できる
• 永続メモリプールのインスタンス化時に再初期化されるフィールドを持つ永続メモリ格納構造体を持つことをサポートできます。つまり、一部の永続メモリ構造体は、ヒープに一時的にのみ格納されるフィールドを持つ必要があります。 私の現在の使用例は、割り当てに使用される永続メモリプールと、ロックに使用される一時データへの参照です。

余談ですが、pmem.io開発（IntelのPMDK）は、内部で変更されたjemallocアロケーターを多用しているため、APIコンシューマーの例としてjemallocを使用するのが賢明なようです。

コレクションでAllocエーターを使用する経験を積むまで、最初にGlobalAllocatorのみをカバーするようにこの範囲を縮小することは可能でしょうか？

IIUCは、これですでにservoのニーズに対応し、コンテナのパラメータ化を並行して試すことができます。 将来的には、どちらかを使用してコレクションを移動することができますGlobalAllocatorのブランケットIMPL追加代わりに、あるいは単にAllocするためにGlobalAllocatorこれらは、すべてのコレクションのために使用することができるようにということ。

考え？

@gnzlbg #[global_allocator]属性を使用するには（ heap::Systemを選択する以外に）、 Alloc特性も安定している必要があります。これにより、 https：/のようなクレートで実装できGlobalAllocatorという名前のタイプや特性はありませんが、新しいAPIを提案していますか？

現在、GlobalAllocatorという名前のタイプまたは特性はありませんが、新しいAPIを提案していますか？

私が提案したのは、 @ alexcrichtonがここで安定化AllocからGlobalAllocatorして、グローバルアロケーターのみを表すようにし、コレクションが別の将来のアロケーター特性（これは、 GlobalAllocator特性によってそれらをパラメーター化できないことを意味するものではありません）。

IIUC servo現在、グローバルアロケーターを切り替えることができる必要があるだけです（アロケーターによって一部のコレクションをパラメーター化することもできるのとは対照的です）。 したがって、両方のユースケースで将来にわたって利用できるソリューションを安定させる代わりに、現在はグローバルアロケーターの問題のみに対処し、後でアロケーターによるコレクションをパラメーター化する方法を理解することができます。

それが理にかなっているかどうかわからない。

IIUCサーボは現在、グローバルアロケーターを切り替えることができる必要があるだけです（アロケーターによって一部のコレクションをパラメーター化することもできるのとは対照的です）。

それは正しいですが：

• トレイトとそのメソッドが安定していて実装できる場合は、 std::heap::Heapを経由せずに直接呼び出すこともできます。 したがって、これは特性グローバルアロケーターであるだけでなく、アロケーターの特性でもあり（アロケーターよりも一般的なコレクション用に別のアロケーターを作成することになったとしても）、 GlobalAllocatorは特に適切な名前ではありません。
• jemallocatorクレートは現在、 alloc_excess 、 realloc 、 realloc_excess 、 usable_size 、 grow_in_place 、およびshrink_in_placeを実装しています。提案された最小限のAPIの一部。 これらはデフォルトのimplよりも効率的である可能性があるため、これらを削除するとパフォーマンスが低下します。

両方の点が理にかなっています。 この機能の安定化を大幅に加速する唯一の方法は、この機能への依存を排除​​することであり、コレクションをパラメーター化するための優れた特性でもあると思いました。

[Servoが（安定した|公式のMozillaクレート）のようになり、貨物がこれを強制して、ここで少しの圧力を取り除くことができれば素晴らしいでしょう。]

@ Ericson2314サーボは、これらのAPIを使用したい唯一のプロジェクトではありません。

@ Ericson2314これが何を意味するのかわかりません、言い換えてもらえますか？

コンテキスト：Servoは現在いくつかの不安定な機能（ #[global_allocator] ）を使用していますが、（一部の機能を安定させたコンパイラに更新するか、安定した代替手段を見つけることによって）ゆっくりとそれから離れようとしています。 ）これはhttps://github.com/servo/servo/issues/5286で追跡され#[global_allocator]を安定させるのは良いことですが、サーボ作業をブロックすることはありません。

Firefoxは、 cdylibコンパイルするときにRust stdがデフォルトでシステムアロケータになり、同じバイナリにリンクされることになったmozjemallocがmallocやfreeようなシンボルを定義するという事実に依存しています。 #[global_allocator]を使用してmozjemallocを明示的に選択し、セットアップ全体をより堅牢にすることを望んでいます。

@SimonSapinアロケーターとコレクションで遊ぶほど、コレクションをAllocパラメーター化したくないと思う傾向があります。アロケーターによっては、コレクションが提供したい場合があるためです。 APIの違い、一部の操作の複雑さの変更、一部のコレクションの詳細は実際にはアロケーターに依存します。

そこで、ここで進歩を遂げるための方法を提案したいと思います。

ステップ1：ヒープアロケーター

最初は、安定したRustで、ユーザーがヒープのアロケーター（または、システム/プラットフォーム/グローバル/フリーストアアロケーター、または名前を付けたい場合）を選択できるように制限することができます。

最初にパラメータ化するのはBoxだけです。これは、メモリの割り当て（ new ）と割り当て解除（ drop ）のみが必要です。

このアロケータートレイトは、最初は@alexcrichtonが提案した（またはいくらか拡張された）APIを持つことができ、このアロケータートレイトは、夜間に、 std::コレクションをサポートするためにわずかに拡張されたAPIを持つことができます。

そこに着くと、stableに移行したいユーザーは移行できますが、APIが不安定なため、パフォーマンスが低下する可能性があります。

ステップ2：パフォーマンスに影響を与えないヒープアロケーター

その時点で、パフォーマンスの低下のために安定版に移行できないユーザーを再評価し、このAPIを拡張して安定化する方法を決定できます。

ステップ3からN： stdコレクションでカスタムアロケーターをサポートします。

まず、これは難しいので、決して起こらないかもしれませんし、決して起こらないことは悪いことではないと思います。

カスタムアロケータを使用してコレクションをパラメータ化したい場合、パフォーマンスの問題または使いやすさの問題があります。

使いやすさの問題がある場合は、通常、カスタムアロケーターの機能を活用する別のコレクションAPIが必要です。たとえば、 SliceDequeクレートのようになります。 カスタムアロケータによってコレクションをパラメータ化しても、ここでは役に立ちません。

パフォーマンスに問題がある場合でも、カスタムアロケーターが私を支援するのは非常に困難です。 Vecは、私が最も頻繁に再実装したコレクションであるため、次のセクションでのみ検討します。

システムアロケータ呼び出しの数を減らす（Small Vector Optimization）

Vecオブジェクト内にいくつかの要素を割り当てて、システムアロケーターへの呼び出し回数を減らしたい場合は、今日はSmallVec<[T; M]>ます。 ただし、 SmallVecはVecはありません：

• Vec移動すると、要素数はO（1）になりますが、 SmallVec<[T; M]>移動すると、N <Mの場合はO（N）になり、その後はO（1）になります。

• len() <= M場合、 Vec要素へのポインタは移動時に無効になりますが、それ以外の場合、つまりinto_iterなどのlen() <= M操作で要素をに移動する必要がある場合は無効になります。ポインタを取るだけでなく、イテレータオブジェクト自体。

これをサポートするために、アロケーター上でVecジェネリックにすることはできますか？ すべてが可能ですが、最も重要なコストは次のとおりです。

• そうすると、 Vecの実装がより複雑になり、この機能を使用していないユーザーに影響を与える可能性があります
• 一部の操作の動作はアロケーターに依存するため、 Vecのドキュメントはより複雑になります。

これらのコストは無視できないと思います。

割り当てパターンを利用する

Vecの成長因子は、特定のアロケーターに合わせて調整されます。 stdでは、一般的なものに合わせて調整できますjemalloc / malloc / ...ただし、カスタムアロケーターを使用している場合は、選択した成長因子がデフォルトでは、ユースケースに最適ではありません。 すべてのアロケーターは、vecのような割り当てパターンの成長因子を指定できる必要がありますか？ わかりませんが、私の直感は私に教えてくれます：おそらくそうではありません。

システムアロケータの追加機能を活用する

たとえば、オーバーコミットアロケータは、ほとんどのTier1およびTier2ターゲットで使用できます。 LinuxのようなシステムやMacosシステムでは、ヒープアロケータはデフォルトでオーバーコミットしますが、Windows APIはVirtualAllocを公​​開します。これは、メモリの予約（ Vec::reserve/with_capacity ）とpushメモリのコミットに使用できます。

現在、 Allocトレイトは、メモリのコミットと予約の概念を分離していないため、Windowsでそのようなアロケータを実装する方法を公開していません（Linuxでは、過剰にコミットしていないアロケータがハッキングされる可能性があります）各ページを1回タッチするだけです）。 また、アロケータがデフォルトでallocにオーバーコミットするかどうかを示す方法も公開していません。

つまり、 Alloc APIを拡張して、これをVecでサポートする必要があります。これは、ほとんど勝てないIMOになります。 そのようなアロケータがあると、 Vecセマンティクスが再び変わるためです。

• Vecは二度と成長する必要がないので、 reserveような操作はほとんど意味がありません
• pushあるO(1)代わりの償却O(1) 。
• ライブオブジェクトへのイテレータは、オブジェクトが生きている限り無効になることはありません。これにより、いくつかの最適化が可能になります。

システムアロケータのその他の追加機能を活用する

cudaMalloc / cudaMemcpy / ...のような一部のシステムアロクターは、固定メモリと非固定メモリを区別し、互いに素なアドレス空間にメモリを割り当てることができます（したがって、に関連付けられたポインタ型が必要になります割り当て特性）、..。

ただし、Vecのようなコレクションでこれらを使用すると、GPUカーネルから行うかホストから行うかに応じて、ベクターのインデックス作成が突然未定義の動作を呼び出すかどうかなど、一部の操作のセマンティクスが微妙に変更されます。

まとめ

すべてのコレクション（またはVecのみ）をパラメーター化するために使用できるAlloc APIを考え出すのは難しい、おそらく難しすぎると思います。

たぶん、global / system / platform / heap / free-storeアロケーターを正しく取得し、 Boxを取得した後、コレクションを再考することができます。 Allocを再利用できるかもしれませんし、 VecAlloc, VecDequeAlloc , HashMapAlloc`が必要かもしれません...あるいは、「本当にこれが必要な場合は、何を知っているか」と言うだけかもしれません。 、標準のコレクションをコピーしてクレートに貼り付け、アロケーターに成形します。」 おそらく最善の解決策は、保育園の独自のクレート（または複数のクレート）にstdコレクションを配置し、安定した機能のみを使用して、これを簡単にすることです。これは、ビルディングブロックのセットとして実装される場合があります。

とにかく、ここでこれらすべての問題に一度に取り組み、すべてに適したAlloc特性を考え出すのは難しいと思います。 ステップ0にいます。ステップ1とステップ2にすばやく到達するための最良の方法は、そこに到達するまでコレクションを画像から除外することだと思います。

そこに着くと、stableに移行したいユーザーは移行できますが、APIが不安定なため、パフォーマンスが低下する可能性があります。

カスタムアロケータを選択することは、通常、パフォーマンスを向上させることであるため、この最初の安定化が誰に役立つかはわかりません。

カスタムアロケータを選択することは、通常、パフォーマンスを向上させることであるため、この最初の安定化が誰に役立つかはわかりません。

みんな？ 少なくとも今は。 あなたが不満を言う方法のほとんどは、最初の安定化提案に欠けています（たとえば、 alloc_excess ）、AFAIKはまだ標準ライブラリの何にも使用されていません。 または、これは最近変更されましたか？

Vec （およびRawVec他のユーザー）はreallocでpush

@SimonSapin

jemallocatorクレートは現在、alloc_excess、realloc、realloc_excess、usable_size、grow_in_place、shrink_in_placeを実装しています。

これらのメソッドから、AFAIK realloc 、 grow_in_place 、およびshrink_in_placeが使用されますが、 grow_in_placeは、でのjemallocのshrink_in_placeに対する単純なラッパーにすぎません。少なくとも、 Alloc特性のshrink_in_placeに関してgrow_in_placeのデフォルトの不安定な実装を実装した場合、それは2つの方法に削減されます： reallocとshrink_in_place 。

カスタムアロケータを選択することは、通常、パフォーマンスを向上させることです。

これは事実ですが、これらのメソッドを使用する悪いアロケーターよりも、これらのメソッドを使用しない、より適切なアロケーターを使用すると、パフォーマンスが向上する可能性があります。

IIUCのサーボの主な使用例は、2番目のジェマロックを使用する代わりにFirefoxのジェマロックを使用することでしたね。

最初の安定化でreallocとshrink_in_placeをAlloc特性に追加しても、パフォーマンスの不満を遅らせるだけです。

たとえば、不安定なAPIをAllocトレイトに追加して、最終的にstdコレクションで使用するようになった瞬間、安定版で同じパフォーマンスを得ることができなくなります。毎晩乗ることができます。 つまり、 realloc_excessとshrink_in_place_excessをallocトレイトに追加し、 Vec / String / ...を使用させると、 realloc安定します。 shrink_in_placeは、1ビットも役に立ちませんでした。

IIUCのサーボの主な使用例は、2番目のジェマロックを使用する代わりにFirefoxのジェマロックを使用することでしたね。

それらはいくつかのコードを共有していますが、FirefoxとServoは2つの別個のプロジェクト/アプリケーションです。

Firefoxはmozjemallocを使用します。これは、多くの機能が追加された古いバージョンのjemallocのフォークです。 一部のunsafe FFIコードは、Ruststdで使用されているmozjemallocの正確性と健全性に依存していると思います。

Servoは、現時点でRustの実行可能ファイルのデフォルトであるjemallocを使用しますが、そのデフォルトをシステムのアロケーターに変更する計画があります。 Servoには、実際に使用されているjemallocの健全性に依存するunsafeメモリ使用量レポートコードもあります。 （ Vec::as_ptr()をje_malloc_usable_size渡します。）

Servoは、現時点でRustの実行可能ファイルのデフォルトであるjemallocを使用しますが、そのデフォルトをシステムのアロケーターに変更する計画があります。

サーボターゲットが最適化されたreallocおよびshrink_to_fit APIを提供するシステムのシステムアロケーターがjemallocのように提供するかどうかを知っておくとよいでしょう。 realloc （およびcalloc ）は非常に一般的ですが、 shrink_to_fit （ xallocx ）はjemalloc固有のAFAIKです。 おそらく最善の解決策は、最初の実装でreallocとalloc_zeroed （ calloc ）を安定させ、後で使用するためにshrink_to_fitを残すことです。 これにより、サーボはパフォーマンスの問題なしにほとんどのプラットフォームのシステムアロケータと連携できるようになります。

Servoには、実際に使用されているjemallocの健全性に依存する安全でないメモリ使用量レポートコードもいくつかあります。 （Vec :: as_ptr（）をje_malloc_usable_sizeに渡します。）

ご存知のように、 jemallocatorクレートにはこのためのAPIがあります。 グローバルアロケーターストーリーが安定し始めると、 jemallocatorクレートに似たクレートが同様のAPIを提供する他のアロケーターにポップアップすることを期待しています。 これらのAPIがAllocトレイトに属するかどうかについてはまったく考えていません。

malloc_usable_sizeがAlloc特性にある必要はないと思います。 #[global_allocator]を使用して、 Vec<T>使用されているアロケーターを確認し、 jemallocatorクレートとは別に関数を使用することは問題ありません。

@SimonSapin Alloc特性が安定すると、LinuxのmallocとWindows用にjemallocatorようなクレートが作成される可能性があります。 これらのクレートには、不安定なAlloc APIのパーツ（たとえば、 usable_size上にmalloc_usable_size ）を実装するための追加機能が含まれている可能性があります。一部ではないAllocメモリが上に報告するように、API mallinfo 。 サーボターゲットとなるシステムに使用可能なクレートがあれば、安定化を優先するためにAlloc特性のどの部分を知るのが簡単になります。おそらく、少なくともいくつかの実験が必要な新しいAPIを見つけるでしょう。アロケーター。

私は物事のビット懐疑的だ@gnzlbg https://github.com/rust-lang/rust/issues/32838#issuecomment -358267292。 これらのシステム固有のものをすべて除外して、allocのコレクションを一般化することは難しくありません-私はそれを行いました。 それを取り入れようとすることは別の挑戦のように思えます。

@SimonSapin Firefoxには不安定なRustポリシーはありませんか？ 私は混乱していたと思います。FirefoxとServoはこれを望んでいますが、もしそうなら、Firefoxのユースケースは安定化への圧力を加えるでしょう。

@sfacklerそれを参照してください^。 私はこれを安定させる必要があるプロジェクトと望んでいるプロジェクトを区別しようとしていましたが、Servoはその分割の反対側にあります。

これが必要で、安定している必要があるプロジェクトがあります。 Rustの消費者としてのServoとFirefoxのどちらにも特に魔法のようなものはありません。

@ Ericson2314正解https ： //wiki.mozilla.org/Rust_Update_Policy_for_Firefox 。 私が説明したように、今日は実用的な解決策があるので、これは何の妨げにもなりません。 #[global_allocator]を使用する方が、より適切で堅牢です。それだけです。

Servoはいくつかの不安定な機能を使用しますが、前述のように、それを変更しようとしています。

FWIW、パラメトリックアロケーターはアロケーターを実装するのに非常に便利です。 さまざまなデータ構造を内部で使用し、より単純なアロケーター（ bsallocなど）でパラメーター化できる場合、パフォーマンスの影響を受けにくい多くの簿記がはるかに簡単になります。 現在、std環境でこれを行う唯一の方法は、最初のフェーズを使用して単純なアロケーターをグローバルアロケーターとして設定し、2番目のフェーズを使用してより大きく複雑なアロケーターをコンパイルする2フェーズコンパイルを行うことです。 。 no-stdでは、それを行う方法はまったくありません。

@ Ericson2314

これらのシステム固有のものをすべて除外して、allocのコレクションを一般化することは難しくありません-私はそれを行いました。 それを取り入れようとすることは別の挑戦のように思えます。

Vec +カスタムアロケーターの上にArrayVecまたはSmallVec実装がありますか？ それが私が最初に述べたポイントであり、それはシステム固有のものではありません。 おそらく、これは想像できる最も単純な2つのアロケーターであり、1つはストレージとしての生の配列であり、もう1つは、配列の容量がなくなったらヒープにフォールバックを追加することで、最初のアロケーターの上に構築できます。 主な違いは、これらのアロケータは「グローバル」ではありませんが、各Vecは、他のすべてのアロケータから独立した独自のアロケータがあり、これらのアロケータはステートフルです。

また、私は決してこれをしないと主張していません。 これは非常に難しいことです。C++は30年間、部分的な成功のみを試みてきました。GPUアロケーターとGCアロケーターは、汎用ポインタータイプにより機能しますが、 ArrayVecとSmallVec実装しています。 Vec上に追加しても、C ++ランドではゼロコストの抽象化にはなりません（ ArrayVecいくつかの問題について詳しく説明しています）。

ですから、将来的にカスタムコレクションアロケーターを追求しない限り、何か有用なものを提供するピースを安定させた後でこれを追求することを望んでいます。

IRCで@SimonSapinと少し話をしましたが、最初の安定化の提案をreallocとalloc_zeroedで拡張すると、FirefoxのRust（安定したRustのみを使用）を使用できるようになります。 mozjemallocは、追加のハックを必要とせずに、安定したRustのグローバルアロケーターとして機能します。 @SimonSapinが述べた

それでも、そこから始めることができます。そこに着いたら、パフォーマンスを低下させることなく、 servoを安定した#[global_allocator]に移動します。

@joshlf

FWIW、パラメトリックアロケーターはアロケーターを実装するのに非常に便利です。

意味についてもう少し詳しく教えていただけますか？ Alloc特性でカスタムアロケータをパラメータ化できない理由はありますか？ または、独自のカスタムアロケータートレイトを使用して、最終的なアロケーターにAllocトレイトを実装します（これらの2つのトレイトは必ずしも等しい必要はありません）。

「SmallVec = Vec +特殊アロケータ」の使用例がどこから来ているのかわかりません。 それは多くの深刻な問題を抱えているという理由だけで、私が以前に（Rustでも他の文脈でも）多く言及したことはありません。 「専用のアロケーターでパフォーマンスを向上させる」と思うと、それはまったく思い浮かびません。

Layout APIを見ると、 from_size_alignとalign_toエラー処理の違いについて疑問に思っていました。前者は、エラーが発生した場合にNoneを返します。 、後者はパニックになります（！）。

適切に定義された有益なLayoutErr列挙型を追加し、両方の場合にResult<Layout, LayoutErr>を返す（そしておそらく現在Option返す他の関数に使用する）方が便利で一貫性があるのではないでしょうか。

@rkruppe

「SmallVec = Vec +特殊アロケータ」の使用例がどこから来ているのかわかりません。 それは多くの深刻な問題を抱えているという理由だけで、私が以前に（Rustでも他の文脈でも）多く言及したことはありません。 「専用のアロケーターでパフォーマンスを向上させる」と思うと、それはまったく思い浮かびません。

RustとC ++でアロケーターを使用するには、2つの独立した方法があります。デフォルトですべての割り当てで使用されるシステムアロケーターと、特定のコレクションのオブジェクトを作成する方法として、アロケーター特性によってパラメーター化されたコレクションの型引数として使用されます。特定のアロケーターを使用します（システムのアロケーターである場合とそうでない場合があります）。

以下では、この2番目のユースケースにのみ焦点を当てます。コレクションとアロケータータイプを使用して、特定のアロケーターを使用するそのコレクションのオブジェクトを作成します。

C ++での私の経験では、アロケーターを使用してコレクションをパラメーター化すると、次の2つのユースケースが提供されます。

• コレクションに特定の割り当てパターンを対象としたカスタムアロケータを使用させることにより、コレクションオブジェクトのパフォーマンスを向上させる、および/または
• コレクションに新しい機能を追加して、以前はできなかったことを実行できるようにします。

コレクションへの新機能の追加

これは、99％の確率でC ++コードベースに見られるアロケーターのユースケースです。 コレクションに新しい機能を追加するとパフォーマンスが向上するという事実は、私の意見では偶然です。 特に、次のアロケータはいずれも、割り当てパターンをターゲットにすることによってパフォーマンスを向上させるものではありません。 これは、 @ Ericson2314が言及しているように、「システム固有」と見なすことができる機能を追加することによって行われます。 これらはいくつかの例です：

• 小さなバッファの最適化を行うためのスタックアロケータ（Howard Hinnantのstack_allocペーパーを参照）。 std::vectorまたはflat_{map,set,multimap,...}を使用でき、カスタムアロケーターを渡すことで、（ SmallVec ）ありまたはなし（ ArrayVec ）の小さなバッファー最適化に追加します。ヒープフォールバック。 これにより、たとえば、コレクションをその要素とともにスタックまたは静的メモリ（ヒープを使用していた場合）に配置できます。

• セグメント化されたメモリアーキテクチャ（16ビット幅のポインタx86ターゲットやGPGPUなど）。 たとえば、C ++ 17 Parallel STLは、C ++ 14の間、Parallel TechnicalSpecificationでした。 同じ著者の先行ライブラリはNVIDIAのThrustライブラリであり、コンテナクラスがGPGPUメモリ（例： thrust :: device_malloc_allocator ）またはピン留めされたメモリ（例： thrust :: pinned_allocator ;ピン留めされたメモリでホストデバイス間の高速転送を可能にするアロケータが含まれています）ある場合）。

• 偽共有（例：Intel Thread Building Blocks cache_aligned_allocator ）やSIMDタイプのオーバーアラインメント要件（例：Eigen3のaligned_allocator ）などの並列処理関連の問題を解決するためのアロケーター。

• プロセス間共有メモリ： Boost.Interprocessには、OSプロセス間共有メモリ機能（System V共有メモリなど）を使用してコレクションのメモリを割り当てるアロケータがあります。 これにより、stdコンテナを直接使用して、異なるプロセス間の通信に使用されるメモリを管理できます。

• ガベージコレクション：Herb Sutterの遅延メモリ割り当てライブラリは、ユーザー定義のポインタ型を使用して、ガベージコレクションメモリを実装するアロケータを実装します。 そのため、たとえば、ベクトルが大きくなると、そのメモリへのすべてのポインタが破棄されるまで、メモリの古いチャンクが存続し、イテレータの無効化が回避されます。

• インストルメント化されたアロケーター：ブルームバーグのソフトウェアライブラリのblsma_testallocatorを使用すると、使用するオブジェクトのメモリの割り当て/割り当て解除（およびC ++固有のオブジェクトの構築/破棄）パターンをログに記録できます。 Vec reserve後に割り当てられるかどうかわかりませんか？ そのようなアロケータを接続すると、それが発生したかどうかが通知されます。 これらのアロケータの一部では、名前を付けることができるため、複数のオブジェクトで使用して、どのオブジェクトが何を実行しているかを示すログを取得できます。

これらは、C ++で実際に最も頻繁に見られるタイプのアロケーターです。 前にも言ったように、パフォーマンスが向上する場合があるという事実は、私の意見では偶然です。 重要な部分は、それらのいずれも特定の割り当てパターンをターゲットにしようとしないことです。

パフォーマンスを向上させるためのターゲティングパターン。

AFAIKこれを行うC ++アロケータは広く使用されていません。これがなぜだと思うのか、すぐに説明します。 次のライブラリは、このユースケースを対象としています。

• C ++ Boost.Pool 、
• C ++ foonathan / memory
• Dのstd.experimental.allocator

ただし、これらのライブラリは、特定のユースケースに対して単一のアロケータを実際に提供するわけではありません。 代わりに、アプリケーションの特定の部分の特定の割り当てパターンを対象としたカスタムアロケーターを構築するために使用できるアロケータービルディングブロックを提供します。

私がC ++の時代から思い出した一般的なアドバイスは、単に「それらを使用しない」ことでした（これらは最後の手段です）。理由は次のとおりです。

• システムアロケータのパフォーマンスを一致させることは非常に困難であり、それを打ち負かすことは非常に困難です。
• 他の誰かのアプリケーションメモリ割り当てパターンがあなたのものと一致する可能性は低いので、あなたは本当にあなたの割り当てパターンを知り、それに一致する必要があるアロケータビルディングブロックを知る必要があります
• ベンダーが異なれば、異なる割り当てパターンを使用するC ++標準ライブラリの実装も異なるため、移植性はありません。 ベンダーは通常、システムアロケーターをターゲットに実装します。 つまり、あるベンダーに合わせたソリューションは、別のベンダーではひどく（システムアロケーターよりも悪い）実行される可能性があります。
• これらを使用する前に使い果たすことができる多くの選択肢があります：別のコレクションを使用する、メモリを予約する、...ほとんどの選択肢は労力が少なく、より大きな勝利をもたらすことができます。

これは、このユースケースのライブラリが役に立たないという意味ではありません。 そういうわけで、 foonathan / memoryのようなライブラリが開花しています。 しかし、少なくとも私の経験では、「機能を追加する」アロケーターよりも実際にはあまり使用されていません。勝利を収めるには、システムアロケーターを打ち負かす必要があります。これは、ほとんどのユーザーが投資するよりも多くの時間を必要とします（Stackoverflowがいっぱいです）。 「Boost.Poolを使用しましたが、パフォーマンスが低下しました。どうすればよいですか？Boost.Poolを使用しないでください。」というタイプの質問の数。

まとめ

IMO C ++アロケーターモデルが完全ではありませんが、両方のユースケースをサポートしていることは素晴らしいことだと思います。Rustのstdコレクションがアロケーターによってパラメーター化される場合は、両方のユースケースもサポートする必要があると思います。どちらの場合もC ++アロケータが便利であることがわかりました。

この問題は、特定のアプリケーションのグローバル/システム/プラットフォーム/デフォルト/ヒープ/フリーストアアロケーターをカスタマイズできることとは少し直交していると思います。両方の問題を同時に解決しようとすると、一方の解決が遅れる可能性があります。それらの不必要に。

一部のユーザーがアロケーターによってパラメーター化されたコレクションで実行したいことは、他のユーザーが実行したいこととは大きく異なる場合があります。 @rkruppeが「割り当てパターンの一致」から始まり、「偽共有の防止」または「ヒープフォールバックを伴う小さなバッファー最適化の使用」から始める場合、最初に理解し、お互いのニーズを理解し、次に到着するのは難しいでしょう。両方で機能するソリューションで。

@gnzlbg包括的な記事をありがとう。 それのほとんどは私の最初の質問に対処しておらず、私はそれのいくつかに同意しませんが、私たちがお互いを超えて話さないようにそれを綴っておくのは良いことです。

私の質問は特にこのアプリケーションについてでした：

小さなバッファの最適化を行うためのスタックアロケータ（Howard Hinnantのstack_allocペーパーを参照）。 std :: vectorまたはflat_ {map、set、multimap、...}を使用でき、カスタムアロケーターを渡すことで、（SmallVec）またはなし（ArrayVec）のヒープフォールバックを使用して小さなバッファー最適化を追加します。 これにより、たとえば、コレクションをその要素とともにスタックまたは静的メモリ（ヒープを使用していた場合）に配置できます。

stack_allocについて読んで、それがどのように機能するかを理解しました。 SmallVec（バッファがコレクションにインラインで格納されている）が通常意味するものではないため、このオプションを見逃しましたが、コレクションが移動したときにポインタを更新する必要があるという問題を回避します（また、移動が安くなります） ）。 また、short_allocを使用すると、複数のコレクションで1つのarenaを共有できるため、通常のSmallVecタイプとはさらに異なります。 これは、割り当てられたスペースが不足したときにヒープ割り当てへの適切なフォールバックを備えた線形/バンプポインターアロケーターのようなものです。

この種のアロケーターとcache_aligned_allocatorが基本的に新しい機能を追加していることに同意しません。 これらは使用方法が異なり、「割り当てパターン」の定義によっては、特定の割り当てパターンに最適化されない場合があります。 ただし、これらは確かに特定のユースケースに最適化されており、汎用ヒープアロケーターとの動作に大きな違いはありません。

ただし、「ポインタ」の意味を大幅に変更するSutterの遅延メモリ割り当てのようなユースケースは、サポートしたい場合は別の設計が必要になる可能性がある別のアプリケーションであることに同意します。

stack_allocについて読んで、それがどのように機能するかを理解しました。 SmallVec（バッファがコレクションにインラインで格納されている）が通常意味するものではないため、このオプションを見逃しましたが、コレクションが移動したときにポインタを更新する必要があるという問題を回避します（また、移動が安くなります） ）。

stack_allocは「紙」を備えた唯一のアロケーターであるため言及しましたが、2009年にリリースされ、C ++ 11より前にリリースされました（C ++ 03はコレクション内のステートフルアロケーターをサポートしていませんでした）。

これがC ++ 11（ステートフルアロケーターをサポート）で機能する方法は、簡単に言うと次のとおりです。

• std :: vectorは、Rust RawVecと同じように、その中にAllocatorオブジェクトを格納します。
• アロケーターインターフェイスには、ユーザー定義のアロケーターがカスタマイズできるAllocator :: propagate_on_container_move_assignment （今後はPOCMA）と呼ばれるあいまいなプロパティがあります。 このプロパティはデフォルトでtrueです。 このプロパティがfalse場合、ムーブ代入ではアロケーターを伝播できないため、標準では、各要素を新しいストレージに手動で移動するためにコレクションが必要です。

したがって、システムアロケータを含むベクトルが移動されると、最初にスタック上の新しいベクトルのストレージが割り当てられ、次にアロケータが移動され（サイズはゼロ）、次に3つのポインタが移動されます。これらは引き続き有効です。 そのような動きはO(1)です。

OTOHO、 POCMA == trueアロケータを持つベクトルが移動されると、最初にスタック上の新しいベクトルのストレージが割り当てられ、空のベクトルで初期化され、次に古いコレクションがdrain挿入されます。新しいもの。古いものは空で、新しいものはいっぱいになります。 これにより、ムーブ代入演算子を使用して、コレクションの各要素が個別に移動されます。 このステップはO(N)あり、要素の内部ポインターを修正します。 最後に、元の空のコレクションが削除されます。 これはクローンのように見えますが、要素自体がクローンされていないためではなく、C ++で移動されていることに注意してください。

それは理にかなっていますか？

C ++でのこのアプローチの主な問題は、次のとおりです。

• ベクトル成長ポリシーは実装定義です
• アロケータAPIには_excessメソッドがありません
• 上記の2つの問題の組み合わせは、ベクトルが最大で9つの要素を保持できることがわかっている場合、9つの要素を保持できるスタックアロケーターを使用できないことを意味します。 1.5なので、18個の要素にペシム化してスペースを割り当てる必要があります。
• ベクトル演算の複雑さは、アロケーターのプロパティによって異なります（POCMAは、C ++アロケーターAPIが持つ多くのプロパティの1つにすぎません。C++アロケーターの記述は簡単ではありません）。 これにより、ベクターのAPIを指定するのが面倒になります。これは、同じタイプの異なるアロケーター間で要素をコピーまたは移動すると、追加のコストが発生し、操作の複雑さが変わるためです。 また、仕様を読むのは非常に面倒です。 cppreferenceのようなドキュメントの多くのオンラインソースは、一般的なケースを前面に出し、99％のユーザーを煩わせないように、1つのアロケータプロパティがtrueまたはfalseの場合に何が変わるかについてのあいまいな詳細を小さな小さな文字で示しています。

たとえば、 _excessメソッドを追加し、標準の準拠コレクションがそれらを使用することを保証することにより、これらの問題を修正するためにC ++のアロケーターAPIの改善に取り組んでいる多くの人々がいます。

この種のアロケーターとcache_aligned_allocatorが基本的に新しい機能を追加していることに同意しません。

たぶん私が意味したのは、以前は使用できなかった状況やタイプでstdコレクションを使用できるということです。 たとえば、C ++では、スタックアロケータのようなものがないと、バイナリの静的メモリセグメントにベクトルの要素を配置できません（ただし、それを実行する独自のコレクションを作成することはできます）。 OTOH、C ++標準はSIMDタイプのようなオーバーアラインされたタイプをサポートしておらず、 newヒープ割り当てしようとすると、未定義の動作が呼び出されます（ posix_memalignなどを使用する必要があります） 。 オブジェクトを使用すると、通常、セグメンテーション違反（*）を介して未定義の動作が明らかになります。 aligned_allocatorようなものを使用すると、別のアロケーターを使用して、未定義の動作を呼び出さずに、これらのタイプをヒープ割り当てし、stdコレクションに配置することもできます。 確かに、新しいアロケータにはさまざまな割り当てパターンがあります（これらのアロケータは基本的にすべてのメモリをオーバーアラインします...）が、人々がそれらを使用するのは、以前はできなかったことを実行できるようにすることです。

明らかに、RustはC ++ではありません。 そして、C ++にはRustにはない問題があります（逆もまた同様です）。 Rustでは、C ++に新しい機能を追加するアロケーターが不要な場合があります。たとえば、SIMDタイプに問題はありません。

（*）C ++およびSTLコンテナーを使用する際の未定義の動作を回避するには、SIMDタイプまたはSIMDタイプを含むタイプ（ Eigen3 docs ）からnewをオーバーロードすることにより、型にnewを使用することはありません（

@gnzlbgありがとう、私もsmallvecの例に混乱しました。 それには、Rustで移動不可能なタイプとある種のアロカが必要になります--- 2つのRFCをレビューし、さらにフォローアップ作業を行います---ですから、今のところ、それについて悩むことはありません。 必要なすべてのスタックスペースを常に使用するという既存のsmallvec戦略は、今のところ問題ないようです。

また、 @ rkruppeに同意します。改訂されたリストでは、アロケーターの新しい機能を、アロケーターを使用するコレクションにはありCollection<Allocator>に新しいプロパティがある場合もあります（たとえば、完全に固定されたメモリに存在します）が、それはアロケータを使用した場合の自然な結果です。

ここで私が見る唯一の例外は、単一のサイズ/タイプのみを割り当てるアロケーターです（NVidiaのものはスラブアロケーターと同様にこれを行います）。 通常のアロケーター用に包括的に実装された別のObjAlloc<T>トレイトを持つことができます： impl<A: Alloc, T> ObjAlloc<T> for A 。 次に、コレクションは、いくつかのアイテムを割り当てる必要がある場合は、ObjAlloc境界を使用します。 しかし、後で互換性を持って逆方向に実行できるはずなので、これを取り上げても少しばかげていると感じます。

それは理にかなっていますか？

もちろんですが、moveコンストラクターがないため、Rustとはあまり関係がありません。 したがって、ポインタを渡すメモリを直接含む（移動可能な）アロケータは不可能です。

たとえば、C ++では、スタックアロケータのようなものがないと、バイナリの静的メモリセグメントにベクトルの要素を配置できません（ただし、それを実行する独自のコレクションを作成することはできます）。

これは動作の変更ではありません。 コレクションがメモリを取得する場所を制御する正当な理由はたくさんありますが、それらはすべて、パフォーマンス、リンカースクリプト、プログラム全体のメモリレイアウトの制御などの「外部性」に関連しています。

align_allocatorのようなものを使用すると、別のアロケーターを使用して、未定義の動作を呼び出さずに、これらのタイプをヒープ割り当てし、stdコレクションに配置することもできます。

これが、Eigenのaligned_allocatorではなく、TBBのcache_aligned_allocatorについて具体的に言及した理由です。 cache_aligned_allocatorは、ドキュメント内の特定の配置を保証していないようです（「通常」128バイトであるとだけ言っています）。また、保証したとしても、通常はこの目的には使用されません（配置が大きすぎて一般的ではないため） SIMDタイプであり、ページ整列DMAなどには小さすぎます）。 あなたが言うように、その目的は偽共有を避けることです。

@gnzlbg

FWIW、パラメトリックアロケーターはアロケーターを実装するのに非常に便利です。

意味についてもう少し詳しく教えていただけますか？ カスタムアロケーターをAllocトレイトでパラメーター化できない理由はありますか？ または、独自のカスタムアロケータートレイトを使用して、最終的なアロケーターにAllocトレイトを実装します（これらの2つのトレイトは必ずしも等しい必要はありません）。

はっきりしていなかったと思います。 もっとよく説明しようと思います。 次のいずれかを使用する予定のアロケータを実装しているとしましょう。

• グローバルアロケーターとして
• 非標準環境で

そして、このアロケーターを実装するために、内部でVecを使用したいとします。 今日存在するVec直接使用することはできません。

• 私がグローバルアロケーターである場合、それを使用すると、自分自身への再帰的な依存関係が導入されます。
• 私が性感染症のない環境にいる場合、今日存在するVecはありません

したがって、必要なのは、単純な内部簿記のために内部で使用する別のアロケータでパラメータ化されたVecを使用できるようにすることです。 これがbsallocの目標です（そして名前の由来-他のアロケーターをブートストラップするために使用されます）。

elfmallocでは、次の方法でグローバルアロケーターになることができます。

• 自分でコンパイルするときは、グローバルアロケーターとしてjemallocを静的にコンパイルします
• 他のプログラムによって動的にロードできる共有オブジェクトファイルを作成します

この場合、システムアロケーターをグローバルアロケーターとして使用してコンパイルしないことが重要です。ロードされると、再帰的な依存関係が再導入されるため、その時点で私たちはシステムアロケーターになります。

ただし、次の場合は機能しません。

• 誰かが私たちをRustのグローバルアロケーターとして「公式」な方法で使用したいと考えています（最初に共有オブジェクトファイルを作成するのではなく）
• 私たちは性感染症のない環境にいます

OTOH、C ++標準は、SIMDタイプのようなオーバーアラインされたタイプをサポートしていません。新しいタイプをヒープ割り当てしようとすると、未定義の動作が呼び出されます（ posix_memalignなどを使用する必要があります）。

現在のAlloc特性はアラインメントをパラメーターとして取るので、このクラスの問題（「別のアラインメントなしでは作業できない」問題）は解消されると思いますか？

@ gnzlbg-包括的な記述（ありがとう）ですが、永続メモリをカバーするユースケースはありません*。

このユースケースを考慮する必要が

• 複数のアロケータが使用されており、特に、そのアロケータが永続メモリ用である場合、システムアロケータになることはあり複数の永続メモリアロケータが存在する可能性があります）
• 標準コレクションを「再実装」するコストは高く、サードパーティライブラリとの互換性のないコードにつながります。
• アロケータの存続期間は必ずしも'staticはありません。
• 永続メモリに格納されているオブジェクトには、ヒープから入力する必要がある追加の状態が必要です。つまり、状態を再初期化する必要があります。 これは、ミューテックスなどに特に当てはまります。 かつて使い捨てだったものはもう処分されません。

Rustには、ここで主導権を握り、HD、SSD、さらにはPCI接続ストレージに取って代わるファーストクラスのプラットフォームにする絶好の機会があります。

*ごく最近まで少し特別だったので、驚くことではありません。 現在、Linux、FreeBSD、およびWindowsで広くサポートされています。

@raphaelcohn

これは本当に永続的なメモリを解決する場所ではありません。 永続メモリへのインターフェイスに関する考え方はあなただけではありません。たとえば、データの整合性の理由から、一般的なアプローチは単に高速ディスクのように扱うことであることが判明する場合があります。

このように永続メモリを使用するユースケースがある場合は、最初に他の場所でそのケースを作成する方がよいでしょう。 それをプロトタイプ化し、アロケーターインターフェースにいくつかのより具体的な変更を考え出し、理想的には、それらの変更が平均的な場合に与える影響に見合う価値があると主張します。

@rpjohnst

同意しません。 これはまさにそれが属する場所のようなものです。 焦点が狭すぎて証拠を探した結果としてデザインが作成されるという決定が下されるのを避けたいと思います。

現在のIntelPMDK（低レベルのユーザースペースサポートに多くの努力が注がれている）は、割り当てられた、ポインター付きの通常のメモリ（ mmap経由のメモリと同様のメモリ）としてはるかに近づいています。 確かに、Linuxで永続メモリを操作したい場合は、現時点でそれがほとんど唯一の呼び出しポートであると思います。 本質的に、それを使用するための最も高度なツールキットの1つ（必要に応じて一般的なツールキット）は、割り当てられたメモリとして扱います。

それをプロトタイピングすることに関しては-まあ、それはまさに私がやったと言ったこと

私は最近、永続メモリアロケータ（具体的にはlibpmemcto）のRustラッパーに取り組んでいます。

（ https://crates.io/crates/nvmlで私のクレートの初期バージョンを使用できcto_poolモジュールのソース管理にはさらに多くの実験があります）。

私のプロトタイプは、実際の大規模システムでデータストレージエンジンを置き換えるために必要なものを念頭に置いて構築されています。 同様の考え方が、私のオープンソースプロジェクトの多くの背後にあります。 私は何年にもわたって、実際の使用法から派生した最高の標準である最高のライブラリを見つけました。

実際のアロケータを現在のインターフェイスに適合させようとするようなものはありません。 率直に言って、 Allocインターフェースを使用し、次にVec全体をコピーし、それを微調整するという経験は苦痛でした。 多くの場所では、アロケータが渡されないと想定しています（例： Vec::new() 。

その際、元のコメントで、アロケーターに何が必要か、そのようなアロケーターのユーザーに何が必要かについて、いくつかの観察を行いました。 これらは、アロケータインターフェイスに関するディスカッションスレッドで非常に有効だと思います。

良いニュースは、 https： //github.com/rust-lang/rust/issues/32838#issuecomment-358940992からの最初の3つの箇条書きが他のユースケースで共有されていることです。

リストに不揮発性メモリを追加しなかったことを追加したかっただけです
リストには、コンテナをパラメータ化するアロケータのユースケースがリストされているためです。
少なくとも私の経験では、「広く」使用されているC ++の世界（
私が言及したアロクターは、ほとんどが多くの人に使用されている非常に人気のあるライブラリからのものです）。
Intel SDK（一部のライブラリ）の取り組みについては知っていますが
ターゲットC ++）私はそれらを使用しているプロジェクトを個人的に知りません（彼らは持っていますか
std :: vectorで使用できるアロケータ？ 知りません）。 これはしません
それらが使用されておらず、重要でもないことを意味します。 知りたい
これらについてですが、私の投稿の要点は、パラメータ化することでした
コンテナによるアロケータは非常に複雑であり、
コンテナのドアを閉めることなく、システムアロケータを進歩させる
（しかし、後でそれに取り組む必要があります）。

2018年1月21日17:36、ジョンエリクソン[email protected]は次のように書いています。

良いニュースは、＃32838からの最初の3つの箇条書きです（コメント）
https://github.com/rust-lang/rust/issues/32838#issuecomment-358940992
他のユースケースで共有されます。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/rust-lang/rust/issues/32838#issuecomment-359261305 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AA3Npk95PZBZcm7tknNp_Cqrs_3T1UkEks5tM2ekgaJpZM4IDYUN
。

私はすでに書かれているもののほとんどを読み込もうとしたので、これはすでにここにあるかもしれません。その場合、私がそれを見逃した場合は申し訳ありませんが、ここに行きます：

ゲーム（C / C ++）でかなり一般的なのは、「フレームごとのスクラッチ割り当て」を使用することです。これは、特定の期間（で）有効な割り当てに使用される線形/バンプアロケーターがあることを意味します。ゲームフレーム）そして「破壊」されます。

この場合は破棄されます。つまり、アロケータを開始位置にリセットします。 これらのオブジェクトはPODタイプである必要があるため、オブジェクトの「破壊」はまったくありません（したがって、デストラクタは実行されません）。

このようなものがRustの現在のアロケーターの設計に適合するのだろうか？

（編集：オブジェクトの破壊がないはずです）

@emoon

ゲーム（C / C ++）でかなり一般的なのは、「フレームごとのスクラッチ割り当て」を使用することです。これは、特定の期間（で）有効な割り当てに使用される線形/バンプアロケーターがあることを意味します。ゲームフレーム）そして「破壊」されます。

この場合は破棄されます。つまり、アロケータを開始位置にリセットします。 これらのオブジェクトはPODタイプである必要があるため、オブジェクトの「破壊」がまったくありません（したがって、デストラクタは実行されません）。

実行可能である必要があります。 頭のてっぺんから、アリーナ自体に1つのオブジェクトと、アリーナのフレームごとのハンドルである別のオブジェクトが必要になります。 次に、そのハンドルにAllocを実装し、割り当てに高レベルの安全なラッパーを使用していると仮定します（たとえば、 BoxがAllocパラメトリックになると想像してください）。ライフタイムは、フレームごとのハンドルが削除される前に、割り当てられたすべてのオブジェクトが削除されることを保証します。 deallocは引き続きオブジェクトごとに呼び出されますが、 deallocがノーオペレーションの場合、ドロップアンドデアロケーションロジック全体が完全にまたはほとんど最適化されている可能性があることに注意してください。

Drop実装しないカスタムスマートポインタタイプを使用することもできます。これにより、他の場所で多くのことが簡単になります。

ありがとう！ 元の投稿でタイプミスをしました。 それは、オブジェクトの破壊が

アロケーターの専門家ではなく、このスレッドをたどることができない人々にとって、現在のコンセンサスは何ですか：stdlibコレクションタイプのカスタムアロケーターをサポートする予定ですか？

@alexreg最終的な計画が何であるかはstdデフォルト型の変数が疑わしいですが、私はちょうどそれ作るには問題がないので、 alloc私たちは今のところのみのものを妨げられることなくlib側で進歩を遂げることができます。

@ Ericson2314わかりました、聞いてよかったです。 デフォルトの型変数はまだ実装されていますか？ またはRFCの段階でおそらく？ あなたが言うように、それらがalloc / std::heapに関連するものに制限されているだけなら、それはすべて大丈夫なはずです。

@alexreghttps ： //github.com/rust-lang/rfcs/pull/2321を参照してください

AllocErrはエラーになるはずだと本当に思います。 他のモジュール（例：io）との整合性が高くなります。

impl Error for AllocErrorおそらく意味があり、害はありませんが、私は個人的にError特性が役に立たないことに気づきました。

今日、Layout :: from_size_align関数を見ていましたが、「 alignは2 ^ 31（つまり、 1 << 31 ）を超えてalignなりません」という制限は私には意味がありませんでした。 そして、gitの非難は＃30170を指摘しました。

それは非常に欺瞞的なコミットメッセージであり、u32にalign適合することについて話していましたが、これは偶発的なものであり、実際に「修正」されている（より回避されている）のはシステムアロケーターの誤動作です。

これは私をこのメモに導きます：ここの「OSX / alloc_systemは巨大な配置でバグがあります」項目はチェックされるべきではありません。 直接的な問題は処理されていますが、長期的には修正が適切であるとは思いません。システムアロケーターの誤動作は、動作するアロケーターの実装を妨げるべきではないからです。 そして、Layout :: from_size_alignの任意の制限がそれを行います。

@glandium 4ギガバイト以上の倍数へのアラインメントをリクエストすると便利ですか？

4GiBの割り当てを4GiBに揃えたい場合が想像​​できます。これは現在は不可能ですが、それ以上になることはほとんどありません。 しかし、今はそのような理由を考えていないからといって、恣意的な制限を加えるべきではないと思います。

4GiBの割り当てを4GiBに揃えたい場合が想像​​できます。

それらのケースは何ですか？

4GiBの割り当てを4GiBに揃えたい場合が想像​​できます。

それらのケースは何ですか？

具体的には、私だけで任意の大きさのアライメントのためのサポートを追加しましたmmap-allocで使用するメモリの大規模な、整列スラブの割り当てをサポートするために、 elfmalloc 。 アイデアは、メモリのスラブをそのサイズに揃えて、そのスラブから割り当てられたオブジェクトへのポインタが与えられた場合、含まれているスラブを見つけるために下位ビットをマスクするだけでよいようにすることです。 現在、4GBのサイズのスラブは使用していません（大きなオブジェクトの場合は、直接mmapに移動します）が、使用できなかった理由はなく、RAM要件が大きいアプリケーションで実行したいと考えていました。それ（つまり、mmapのオーバーヘッドを受け入れたくないほど頻繁にマルチGBオブジェクトを割り当てた場合）。

4GiBを超える配置の考えられる使用例は次のとおりです。大きなページ境界への配置。 4GiBを超えるページをサポートするプラットフォームはすでに存在します。 このIBM文書には、「POWER5 +プロセッサーは、4 KB、64 KB、16 MB、および16GBの4つの仮想メモリー・ページ・サイズをサポートしている」とサポートします。

Allocトレイトの型指定されていない関数はすべて、 *mut u8ます。 つまり、nullポインターを取得または返す可能性があり、すべての地獄が解き放たれます。 代わりにNonNullを使用する必要がありますか？

彼らが返すことができる多くのポインタがあり、そこからすべての地獄が
緩めます。
3:56マイクHommeyの時日、2018年3月4日に[email protected]書きました：

Allocトレイトの型指定されていない関数はすべて、* mutu8を処理しています。
つまり、nullポインターを取得または返すことができ、すべての地獄は
緩めます。 代わりにNonNullを使用する必要がありますか？

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/rust-lang/rust/issues/32838#issuecomment-370223269 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/ABY2UR2dRxDtdACeRUh_djM-DExRuLxiks5ta9aFgaJpZM4IDYUN
。

NonNullを使用するより説得力のある理由は、現在Allocメソッドから返されるResultを許可することです（またはOptionsに切り替えると、将来）小さくする。

NonNullを使用するより説得力のある理由は、Allocメソッド（または将来これに切り替える場合はOptions）から現在返される結果を小さくできることです。

AllocErrは2つのバリエーションがあるため、そうなるとは思いません。

彼らが返すことができる多くのポインターがあり、そこからすべての地獄が解き放たれます。

しかし、nullポインターは、他のどのポインターよりも明らかに間違っています。

さび型システムはフットガンに役立ち、不変条件をエンコードするために使用されると思います。 allocのドキュメントには、「このメソッドがOk(addr)返す場合、返されるアドレスはnull以外のアドレスになります」と明記されていますが、その戻り値の型はそうではありません。 実は、 Ok(malloc(layout.size()))は、明らかにそうではない場合でも、有効な実装になります。

Layoutサイズがゼロ以外である必要があるというメモもあるので、それをNonZeroとしてエンコードする必要があることにも注意してください。。

これらすべての機能が本質的に安全でないからといって、フットガンを防ぐべきではありません。

アロケーターの使用（編集：および実装）で発生する可能性のあるすべてのエラーの中で、nullポインターを渡すことは、追跡するのが最も簡単なものの1つです（少なくともMMUがあり、実行しなかった場合は、逆参照時に常にクリーンなセグメンテーション違反が発生します非常に奇妙なことです）、そして通常、修正するのが最も簡単なものの1つです。 安全でないインターフェースがフットガンを防ごうとするのは事実ですが、このフットガンは（他の考えられるエラーや型システムでこの不変条件をエンコードする冗長性と比較して）不釣り合いに小さいようです。

さらに、アロケーターの実装では、「パフォーマンスのために」 NonNullのチェックされていないコンストラクターを使用する可能性があります。正しいアロケーターでは、とにかくnullが返されることはないため、 NonNell::new(...).unwrap()をスキップする必要があります。 その場合、実際には具体的なフットガンの予防策は得られず、定型的なものが増えるだけです。 （ Resultサイズのメリットは、実際の場合でも、それでも説得力のある理由である可能性があります。）

アロケーターの実装では、NonNullのチェックされていないコンストラクターを使用するだけです。

重要なのは、ユーザーを支援することよりも、アロケーターの実装を支援することです。 MyVecにNonNull<T> MyVecが含まれていて、 Heap.alloc()すでにNonNull返している場合は、チェックされていない、または安全でないチェックされていない呼び出しを1回行う必要があります。

ポインタは戻り値の型であるだけでなく、たとえばdeallocやreallocへの入力型でもあることに注意してください。 それらの関数は、入力がnullである可能性があるかどうかに対して、強化されるはずですか？ ドキュメントは「いいえ」と言う傾向がありますが、型システムは「はい」と言う傾向があります。

layout.size（）とまったく同じです。 割り当て関数は、要求されたサイズが0であることを何らかの形で処理することになっていますか？

（結果サイズの利点は、実際の場合でも、それでも説得力のある理由である可能性があります。）

サイズのメリットがあるとは思えませんが、＃48741のようなものを使用すると、codegenのメリットがあります。

APIのユーザーにとってより柔軟であるという原則を継続する場合、ポインターは戻り値の型ではNonNullである必要がありますが、引数ではそうではありません。 （これは、これらの引数を実行時にnullチェックする必要があるという意味ではありません。）

ポステルの法則アプローチは、ここで採用するのは間違っていると思います。 何かありますか
Allocメソッドにnullポインタを渡すことが有効な場合は？ そうでない場合は、
その柔軟性は基本的にフットガンにもう少しだけ与えることです
敏感なトリガー。

2018年3月5日午前8時、「SimonSapin」 [email protected]は次のように書いています。

APIのユーザーにとってより柔軟であるという原則を継続すると、
ポインタは、戻り値の型ではNonNullである必要がありますが、引数ではそうではありません。 （この
これらの引数を実行時にnullチェックする必要があるという意味ではありません。）

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/rust-lang/rust/issues/32838#issuecomment-370327018 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AA_2L8zrOLyUv5mUc_kiiXOAn1f60k9Uks5tbOJ0gaJpZM4IDYUN
。

重要なのは、ユーザーを支援することよりも、アロケーターの実装を支援することです。 MyVecにNonNullが含まれている場合そして、Heap.alloc（）はすでにNonNullを返します。これは、私が行う必要のあるチェックされていない、または安全でないチェックされていない呼び出しです。

ああ、これは理にかなっています。 フットガンを修正しませんが、その責任を一元化します。

ポインタは戻り値の型であるだけでなく、deallocやreallocなどへの入力型でもあることに注意してください。 それらの関数は、入力がnullである可能性があるかどうかに対して、強化されるはずですか？ ドキュメントは「いいえ」と言う傾向がありますが、型システムは「はい」と言う傾向があります。

Allocメソッドにnullポインタを渡すことが有効な場合はありますか？ そうでない場合、その柔軟性は基本的にフットガンにわずかに敏感なトリガーを与えるだけです。

ユーザーは絶対にマニュアルを読み、心の中で不変量を維持しています。 多くの不変条件は、型システムを介して強制することはできません。可能であれば、関数はそもそも安全ではありません。 したがって、これは、特定のインターフェイスにNonNullを配置することが実際にユーザーを支援するかどうかの問題にすぎません。

• ドキュメントを読んで不変条件について考えるように彼らに思い出させます
• 利便性の提供（ @SimonSapinのポイントとallocの戻り値）
• いくつかの重要な利点を与える（例えば、レイアウトの最適化）

私は、例えば、の引数作りに任意の強力な利点が表示されていないdeallocにNonNull 。 このAPIの使用にはおおよそ2つのクラスがあります。

1. allocを呼び出す比較的簡単な使用法では、返されたポインタをどこかに格納し、しばらくして、格納されたポインタをdealloc渡します。
2. FFI、多くのポインタ演算などを含む複雑なシナリオでは、最後に正しいものをdeallocに渡すことを保証するために重要なロジックが関係しています。

ここでNonNullを使用すると、基本的に最初の種類のユースケースのみが役立ちます。これは、 NonNullを適切な場所に保存し、変更せずにNonNull渡すためです。 理論的には、複数のポインターをジャグリングしていて、そのうちの1つだけがNonNull場合、いくつかのタイプミス（ barを意味するときにfooを渡す）を防ぐことができますが、これはそうではないようですあまりにも一般的または重要です。 deallocが生のポインタを取ることの不利な点（ allocがNonNullを返すと@ SimonSapinは私が起こるべきだと確信しています）は、 as_ptrが必要になることです。潜在的に迷惑ですが、どちらの方法でも安全性に影響を与えない、dealloc呼び出し。

2番目の種類のユースケースは、プロセス全体でNonNullを使い続けることができない可能性があるため、役に立ちません。そのため、取得した生のポインターからNonNullを手動で再作成する必要があります。どういうわけか。 前に議論したように、これは実際の実行時チェックではなく、チェックされていない/ unsafeアサーションになる可能性が高いため、フットガンが妨げられることはありません。

これは、私がdeallocが生のポインターを取ることに賛成しているということではありません。 フットガンに関して主張されている利点は見当たりません。 タイプの一貫性は、おそらくデフォルトで勝つだけです。

申し訳ありませんが、「型システムを介して多くの不変条件を強制することはできません...したがって、試してみません」と読みました。 完璧を善の敵にしないでください！

NonNullによって提供される保証と、 NonNullと生のポインターの間を行き来する必要から失われる人間工学との間のトレードオフについてだと思います。 どちらにしても、特に強い意見はありません。どちらの側も不合理に思えます。

@cramertjええ、でも私はそのような議論の前提を実際には買いません。 Allocは、あいまいで、隠された、ほとんど安全でないユースケースのためのものだと人々は言います。 まあ、あいまいで読みにくいコードでは、できるだけ安全にしたいと思います---正確には、元の作者がいない可能性が非常に低いためです。 逆に、コードが数年後に読み取られている場合は、エゴノミクスをねじ込みます。 どちらかといえば、それは逆効果です。 なじみのない読者が地球上で何が起こっているのかをよりよく理解できるように、コードは非常に明確になるように努める必要があります。 ノイズが少ない<不変量が明確です。

2番目の種類のユースケースは、プロセス全体でNonNullを使い続けることができない可能性があるため、役に立ちません。そのため、取得した生のポインターからNonNullを手動で再作成する必要があります。どういうわけか。

これは単なる調整の失敗であり、技術的な必然性ではありません。 確かに、現在、多くの安全でないAPIは生のポインターを使用する可能性があります。 何かがリードしているような方法は、使用して、優れたインタフェースに切り替えるNonNullまたは他のラッパーを。 そうすれば、他のコードがより簡単に追随できます。 私は、グリーンフィールドで、すべて錆びた、安全でないコードで、読みにくく、情報量の少ないrawポインターに常に頼る理由はありません。

こんにちは！

私は、Rustカスタムアロケーターの作成者/保守者として、 NonNullを支持していると言いたいだけです。 ほぼすべての理由で、このスレッドですでに説明されています。

また、 @ glandiumはFirefoxのjemallocフォークの

@ Ericson2314や他の人たちにもっと多くの返答を書くことができましたが、それはすぐに非常に孤立した哲学的な議論になりつつあるので、ここでは短くします。 私は、この種のAPIでのNonNullの安全上の利点を誇張していると私が信じていることに反対していました（もちろん、他の利点もあります）。 安全上のメリットがないというわけではありませんが、 @ cramertjが言ったように、トレードオフがあり、「プロ」側は誇張されていると思います。 とにかく、私は他の理由でさまざまな場所でNonNullを使用することに傾倒しているとすでに述べました-一貫性のために@SimonSapinがallocで、 deallocで与えた理由です。 それでは、それを実行して、これ以上接線を外れないようにしましょう。

誰もが参加しているNonNullユースケースがいくつかある場合、それは素晴らしいスタートです。

摩擦を少なくともliballoc以内に抑えるために、 Uniqueとその友人を更新して、 NonZeroではなくNonNullを使用することをお勧めします。 しかし、これは、アロケーターの1つの抽象化レベルですでに行っていることのように見えます。また、アロケーターレベルでもこれを行わない理由は考えられません。 私には合理的な変更のように見えます。

（ Unique<T>とNonNull<T>間で安全に変換するFromトレイトの実装はすでに2つあります。）

安定した錆のアロケーターAPIに非常によく似たものが必要であることを考慮して、錆のリポジトリからコードを抽出し、別のクレートに配置しました。

• https://crates.io/crates/allocator_api
• https://github.com/glandium/allocator_api

この/ could /は、APIの実験的な変更を繰り返すために使用できますが、現時点では、rustリポジトリにあるもののプレーンコピーです。

[オフトピック]ええ、 stdがそのようなツリー外の安定したコードクレートを使用できれば、安定したコードで不安定なインターフェイスを試すことができます。 これが、私がstdのファサードを持つのが好きな理由の1つです。

stdは、crates.ioからのクレートのコピーに依存する可能性がありますが、プログラムが同じクレートにも依存している場合、とにかく同じクレート/タイプ/特性がrustcに「似ていない」ので、私はしませんそれがどのように役立つかわかりません。 とにかく、ファサードに関係なく、安定したチャネルで不安定な機能を使用できないようにすることは、偶然ではなく、非常に慎重な選択です。

NonNullを使用することである程度の合意があるようです。 これが実際に起こるための今後の道は何ですか？ ただのPRですか？ RFC？

無関係に、私はボクシングのものから生成されたいくつかのアセンブリを見てきました、そしてエラーパスはかなり大きいです。 それについて何かする必要がありますか？

例：

pub fn bar() -> Box<[u8]> {
    vec![0; 42].into_boxed_slice()
}

pub fn qux() -> Box<[u8]> {
    Box::new([0; 42])
}

コンパイル先：

example::bar:
  sub rsp, 56
  lea rdx, [rsp + 8]
  mov edi, 42
  mov esi, 1
  call __rust_alloc_zeroed<strong i="11">@PLT</strong>
  test rax, rax
  je .LBB1_1
  mov edx, 42
  add rsp, 56
  ret
.LBB1_1:
  mov rax, qword ptr [rsp + 8]
  movups xmm0, xmmword ptr [rsp + 16]
  movaps xmmword ptr [rsp + 32], xmm0
  mov qword ptr [rsp + 8], rax
  movaps xmm0, xmmword ptr [rsp + 32]
  movups xmmword ptr [rsp + 16], xmm0
  lea rdi, [rsp + 8]
  call __rust_oom<strong i="12">@PLT</strong>
  ud2

example::qux:
  sub rsp, 104
  xorps xmm0, xmm0
  movups xmmword ptr [rsp + 58], xmm0
  movaps xmmword ptr [rsp + 48], xmm0
  movaps xmmword ptr [rsp + 32], xmm0
  lea rdx, [rsp + 8]
  mov edi, 42
  mov esi, 1
  call __rust_alloc<strong i="13">@PLT</strong>
  test rax, rax
  je .LBB2_1
  movups xmm0, xmmword ptr [rsp + 58]
  movups xmmword ptr [rax + 26], xmm0
  movaps xmm0, xmmword ptr [rsp + 32]
  movaps xmm1, xmmword ptr [rsp + 48]
  movups xmmword ptr [rax + 16], xmm1
  movups xmmword ptr [rax], xmm0
  mov edx, 42
  add rsp, 104
  ret
.LBB2_1:
  movups xmm0, xmmword ptr [rsp + 16]
  movaps xmmword ptr [rsp + 80], xmm0
  movaps xmm0, xmmword ptr [rsp + 80]
  movups xmmword ptr [rsp + 16], xmm0
  lea rdi, [rsp + 8]
  call __rust_oom<strong i="14">@PLT</strong>
  ud2

これは、ボックスを作成する場所に追加するかなりの量のコードです。 アロケーターAPIがなかった1.19と比較してください。

example::bar:
  push rax
  mov edi, 42
  mov esi, 1
  call __rust_allocate_zeroed<strong i="18">@PLT</strong>
  test rax, rax
  je .LBB1_2
  mov edx, 42
  pop rcx
  ret
.LBB1_2:
  call alloc::oom::oom<strong i="19">@PLT</strong>

example::qux:
  sub rsp, 56
  xorps xmm0, xmm0
  movups xmmword ptr [rsp + 26], xmm0
  movaps xmmword ptr [rsp + 16], xmm0
  movaps xmmword ptr [rsp], xmm0
  mov edi, 42
  mov esi, 1
  call __rust_allocate<strong i="20">@PLT</strong>
  test rax, rax
  je .LBB2_2
  movups xmm0, xmmword ptr [rsp + 26]
  movups xmmword ptr [rax + 26], xmm0
  movaps xmm0, xmmword ptr [rsp]
  movaps xmm1, xmmword ptr [rsp + 16]
  movups xmmword ptr [rax + 16], xmm1
  movups xmmword ptr [rax], xmm0
  mov edx, 42
  add rsp, 56
  ret
.LBB2_2:
  call alloc::oom::oom<strong i="21">@PLT</strong>

これが実際に重要である場合、それは確かに迷惑です。 しかし、LLVMはこれをより大きなプログラム向けに最適化するのでしょうか？

最新のFirefoxでは毎晩__rust_oomへの呼び出しが1439回あります。 ただし、Firefoxはrustのアロケータを使用しないため、malloc / callocが直接呼び出され、続いてoom準備コード（通常は2つのmovqとlea）にジャンプするnullチェックが行われ、AllocErrが入力されてアドレスが取得されます。 __rust__oomに渡します。 これは基本的に最良のシナリオですが、それでも2つのmovqとleaのマシンコードは20バイトです。

ripgrepを見ると、85個あり、それらはすべて同じ_ZN61_$LT$alloc..heap..Heap$u20$as$u20$alloc..allocator..Alloc$GT$3oom17h53c76bda5 0c6b65aE.llvm.nnnnnnnnnnnnnnn関数にあります。 それらはすべて16バイトの長さです。 これらのラッパー関数への呼び出しは685回あり、そのほとんどの前に、 https： //github.com/rust-lang/rust/issues/32838#issuecomment-377097485に貼り付けたものと同様のコードがあり

@noxは今日、 mergefunc llvmパスを有効にすることを検討していましたが、ここで何か違いがあるのではないかと思います。

mergefuncは、複数の同一の_ZN61_$LT$alloc..heap..Heap$u20$as$u20$alloc..allocator..Alloc$GT$3oom17h53c76bda5 0c6b65aE.llvm.nnnnnnnnnnnnnnn関数を削除しないようです（ RUSTFLAGS -C passes=mergefuncで試してみました）。

しかし、大きな違いを生むのはLTOです。これは、Firefoxがmallocを直接呼び出すようにし、 __rust_oom呼び出す直前にAllocErrの作成を任せます。 これにより、アロケータを呼び出す前にLayout必要がなくなり、 AllocErr埋めるときにそのままになります。

これにより、 __rust_oomを除いて、割り当て関数はおそらくインラインでマークする必要があると思います。

ところで、Firefox用に生成されたコードを見て、 malloc代わりにmoz_xmallocを使用することが理想的だと思います。 これは、アロケーター特性の組み合わせとグローバルヒープアロケーターの置き換えがなければ不可能ですが、アロケーター特性のカスタムエラータイプが必要になる可能性があります。 moz_xmallocは間違いなく、次の場合には返されません。失敗。 IOW、それはOOM自体を処理し、その場合、錆びたコードは__rust_oomを呼び出す必要はありません。 これにより、アロケータ関数がオプションでAllocErrではなく!返すことが望ましいでしょう。

AllocErrをゼロサイズの構造体にすることについて説明しました。これもここで役立つ可能性があります。 ポインタもNonNullにすると、戻り値全体をポインタサイズにすることができます。

https://github.com/rust-lang/rust/pull/49669は、グローバルアロケーターをカバーするサブセットを安定させることを目的として、これらのAPIに多くの変更を加えています。 そのサブセットの追跡の問題： https ： 新しいGlobalAlloc特性が導入されました。

このPRは、私たちはのようなことを行うことができますVec::new_with_alloc(alloc)ところalloc: Allocすぐに？

@alexregいいえ

@sfacklerうーん、どうして？ それを行う前に何が必要ですか？ グローバルアロケータを変更するだけの場合を除いて、このPRのポイントは他の方法では実際にはわかりません。

@alexreg

グローバルアロケータを変更するだけの場合を除いて、このPRのポイントは他の方法では実際にはわかりません。

グローバルアロケーターを変更するためだけだと思います。

@alexreg安定しているということであれば、安定させる準備ができていない未解決の設計上の質問がいくつかあります。 Nightlyでは、これはRawVecサポートされており、それに取り組んでみたいと思う人のために、 Vec #[unstable]として追加しても問題ありません。

はい、PRで述べたように、そのポイントは、グローバルアロケーターを変更したり、 Vec::with_capacityせずに（カスタムコレクションタイプなどで）割り当てたりできるようにすることです。

FWIW、 https： //github.com/rust-lang/rust/issues/32838#issuecomment -376793369で言及されているallocator_apiクレートには、マスターにRawVec<T, A>とBox<T, A>がありますブランチ（まだリリースされていません）。 私はそれを、割り当てタイプに対してジェネリックなコレクションがどのように見えるかについてのインキュベーターとして考えています（さらに、安定した錆のためにBox<T, A>タイプが必要であるという事実）。 Vec<T, A>を追加するためのvec.rsの移植はまだ開始していませんが、PRは大歓迎です。 vec.rsは大きいです。

https://github.com/rust-lang/rust/issues/32838#issuecomment -377097485で言及されているcodegenの「問題」は、＃49669の変更で削除されるはずです。

さて、 Allocトレイトを使用してアロケーターをレイヤーに実装するのに役立つことをもう少し考えてみると、（少なくとも私にとっては）役立つと思うことが2つあります。

• 前述のように、オプションで別のAllocErrタイプを指定できます。 これは、 !にする場合や、AllocErrが空になったため、オプションで「失敗」よりも多くの情報を伝達する場合に役立ちます。
• オプションで、別のLayoutタイプを指定できます。 アロケータの2つの層があると想像してください。1つはページ割り当て用で、もう1つはより大きな領域用です。 後者は前者に依存できますが、両方が同じLayoutタイプをとる場合、両方のレイヤーが独自の検証を行う必要があります。最低レベルでは、そのサイズと配置はページサイズの倍数です。より高いレベルでは、そのサイズと配置はより大きな領域の要件に一致します。 しかし、これらのチェックは冗長です。 特殊なLayoutタイプを使用すると、検証をアロケーター自体ではなくLayout作成に委任でき、 Layoutタイプ間の変換により、冗長なチェックをスキップできます。

@cramertj @SimonSapin @glandiumわかりました、明確にしていただきありがとうcrate 、

@alexregは、＃49669のAlloc特性に対する重大な変更の量を考慮すると、最初にマージされるのを待つ方がよいでしょう。

@glandiumまあまあ。 それは着陸からそれほど遠くないようです。 https://github.com/pnkfelix/collections-primeレポにも気づきました...あなたとの関係でそれは何ですか？

もう1つ未解決の質問を追加します。

• Alloc::oomはパニックに陥ることができますか？ 現在、ドキュメントには、このメソッドはプロセスを中止する必要があると書かれています。 これは、アロケータを使用するコードに影響を及ぼします。アロケータは、メモリリークなしでアンワインドを適切に処理するように設計する必要があるためです。

ローカルアロケーターの障害は必ずしもグローバルアロケーターも失敗することを意味するわけではないので、パニックを許容する必要があると思います。 最悪の場合、グローバルアロケータのoomが呼び出され、プロセスが中止されます（そうしないと、既存のコードが破損します）。

@alexregそうではありません。 std / alloc / collectionsにあるものの単純なコピーのようです。 さて、それの2年前のコピー。 私のクレートは範囲がはるかに制限されています（公開されたバージョンには数週間前の時点でAlloc特性しかなく、マスターブランチにはRawVecとBoxしかありませんそれ）、そして私の目標の1つは、安定した錆でそれを構築し続けることです。

@glandiumさて、その場合、そのPRが着陸するまで待ってから、錆びたマスターに対してPRを作成し、タグを付けるのはおそらく理にかなっています。そうすれば、いつマスターにマージされるかがわかります（そして、クレートにマージできます）。 、フェア？

@alexregは理にかなっています。 あなたは今それを始めることができますが、バイクシェディングがそのPRの状況を変える場合、それはあなたの側にいくらかのチャーンを引き起こす可能性があります。

@glandium今のところ、Rustで忙しくしている他のことがありますが、そのPRが承認されたらそれに

Alloc :: oomはパニックに陥ることができますか？ 現在、ドキュメントには、このメソッドはプロセスを中止する必要があると書かれています。 これは、アロケータを使用するコードに影響を及ぼします。アロケータは、メモリリークなしでアンワインドを適切に処理するように設計する必要があるためです。

@AmanieuこのRFCはマージされました： https ：

PRの提出を検討しているAPIに1つの変更があります。

Allocトレイトを「実装」と「ヘルパー」の2つの部分に分割します。 前者はalloc 、 dealloc 、 reallocなどの関数であり、後者はalloc_one 、 dealloc_one 、 alloc_arrayような関数です。

OTOH、 Allocトレイト実装者がalloc_oneなどで凝ったことを行おうとした場合、その割り当てのためにdealloc_oneが呼び出される保証はありません。 これには複数の理由があります。

• ヘルパーは一貫して使用されていません。 ほんの一例として、 raw_vecはalloc_array 、 alloc / alloc_zeroed組み合わせを使用しますが、 deallocのみを使用します。
• たとえばalloc_array / dealloc_arrayを一貫して使用している場合でも、 VecをBoxに安全に変換できます。これによりdealloc使用されます。
• 次に、存在しないAPIの一部があります（ alloc_one / alloc_arrayのゼロ化バージョンはありません）

したがって、たとえばalloc_one特殊化の実際のユースケースがありますが（実際には、mozjemallocが必要です）、代わりに特殊化されたアロケーターを使用することをお勧めします。

実際、それよりも悪いですが、錆のレポでは、 alloc_arrayがalloc_oneだけ使用され、 dealloc_one 、 realloc_array 、 dealloc_arrayは使用されません。 alloc_oneを使用せず、 exchange_mallocを使用します。これには、 sizeとalignです。 したがって、これらの関数は、実装者よりもクライアントの利便性を目的としています。

impl<A: Alloc> AllocHelpers for A （またはAllocExt 、どの名前を選択しても）のようなものを使用すると、実装者が考えた場合に自分の足を撃つことを許可せずに、クライアントにとってこれらの関数の便利さを維持できます。それらはそれらをオーバーライドすることによって（そしてプロキシアロケーターを実装する人々にとってより簡単にすることによって）派手なことをするでしょう。

PRを提出することを検討しているAPIに1つの変更があります

＃50436でそうしました

@glandium

（そして実際のところ、私はmozjemallocをそのように必要としています）、

このユースケースについて詳しく教えてください。

mozjemallocには、意図的にリークするベースアロケーターがあります。 フリーリストを保持する1種類のオブジェクトを除きます。 alloc_oneトリックを行うのではなく、アロケーターを階層化することでそれを行うことができます。

割り当てた正確な配置を割り当て解除する必要がありますか？

この質問への答えが「はい」であることを強調するために、私はマイクロソフト自身からこの素敵な引用を持ってい

Alined_alloc（）は、C11が実装と互換性のない方法で指定したため、おそらく実装されません（つまり、free（）は高度に調整された割り当てを処理できる必要があります）

Windowsでシステムアロケータを使用するには、高度に調整された割り当てを正しく割り当て解除するために、割り当てを解除するときに常に配置を知って

Windowsでシステムアロケータを使用するには、高度に調整された割り当てを正しく割り当て解除するために、割り当てを解除するときに常に配置を知って

それは残念ですが、それはそうです。 それでは、オーバーアラインされたベクトルをあきらめましょう。 ：混乱：

オーバーアラインされたベクトルをあきらめましょう

どうして？ オーバーアラインメントで割り当てと割り当て解除の両方を行うVec<T, OverAlignedAlloc<U16>>が必要です。

どうして？ オーバーアラインメントで割り当てと割り当て解除の両方を行うVec<T, OverAlignedAlloc<U16>>が必要です。

もっと具体的にすべきだった。 つまり、オーバーアラインされたベクターを、コントロール外のAPIに移動することを意味しました。つまり、 Vec<T, OverAlignedAlloc<U16>>ではなくVec<T>を使用するAPIです。 （たとえば、 CString::new() 。）

あなたはむしろ使用する必要があります

#[repr(align(16))]
struct OverAligned16<T>(T);

次にVec<OverAligned16<T>> 。

あなたはむしろ使用する必要があります

場合によります。 f32 sのベクトルでAVX組み込み関数（256ビット幅、32バイトのアライメント要件）を使用するとします。

• Vec<T, OverAlignedAlloc<U32>>は問題を解決し、AVX組み込み関数をベクトル要素（特に整列されたメモリロード）で直接使用できますが、ベクトルは依然として&[f32]スライスにデレフされ、人間工学的に使用できます。
• Vec<OverAligned32<f32>>は実際には問題を解決しません。 各f32は、配置要件のために32バイトのスペースを必要とします。 導入されたパディングは、 f32が連続メモリ上にないため、AVX操作を直接使用できないようにします。 そして、私は個人的に&[OverAligned32<f32>]へのderefを扱うのが少し面倒だと思います。

Box 、 Box<T, OverAligned<U32>>対Box<OverAligned32<T>>単一要素の場合、両方のアプローチはより同等であり、2番目のアプローチが実際に望ましい場合があります。 いずれにせよ、両方のオプションがあると便利です。

Alloc特性へのこのwrt変更を投稿しました： https ：

この号の冒頭にある追跡投稿はひどく古くなっています（最後に編集されたのは2016年です）。 議論を生産的に続けるには、活発な懸念事項の最新リストが必要です。

議論はまた、現在の未解決の質問と設計決定の論理的根拠を含む最新の設計文書から大きな恩恵を受けるでしょう。

「現在毎晩実装されているもの」から「元のAllocRFCで提案されたもの」まで、さまざまなチャネル（rfcリポジトリ、rust-langトラッキングの問題、グローバルalloc RFC、内部投稿、多く）に数千のコメントを生成するdiffのスレッドが複数あります。巨大なPRなど）、そしてGlobalAlloc RFCで安定しているものは、元のRFCで提案されたものとあまり似ていません。

これは、ドキュメントとリファレンスの更新を完了するためにとにかく必要なものであり、現在のディスカッションでも役立ちます。

Alloc特性の安定化について考える前に、まずすべての標準ライブラリコレクションにアロケータサポートを実装してみる必要があると思います。 これにより、この特性が実際にどのように使用されるかについての経験が得られるはずです。

Alloc特性の安定化について考える前に、まずすべての標準ライブラリコレクションにアロケータサポートを実装してみる必要があると思います。 これにより、この特性が実際にどのように使用されるかについての経験が得られるはずです。

そのとおり。 特にBox 、 Box<T, A>に2つの単語を使用させないようにする方法がまだわからないためです。

そのとおり。 特にBox、Boxを避ける方法がまだわからないので2つの言葉を取り上げます。

最初の実装ではBox<T, A>のサイズを心配する必要はないと思いますが、これは、サポートするだけのDeAllocトレイトを追加することで、下位互換性のある方法で後で追加できるものです。割り当て解除。

例：

trait DeAlloc {
    fn dealloc(&mut self, ptr: NonNull<Opaque>, layout: Layout);
}

trait Alloc {
    // In addition to the existing trait items
    type DeAlloc: DeAlloc = Self;
    fn into_dealloc(self) -> Self::DeAlloc {
        self
    }
}

impl<T: Alloc> DeAlloc for T {
    fn dealloc(&mut self, ptr: NonNull<Opaque>, layout: Layout) {
        Alloc::dealloc(self, ptr, layout);
    }
}

Allocトレイトの安定化について考える前に、まずすべての標準ライブラリコレクションにアロケーターサポートを実装してみる必要があると思います。 これにより、この特性が実際にどのように使用されるかについての経験が得られるはずです。

https://github.com/rust-lang/rust/issues/42774によると、 @ Ericson2314がこれに取り組んでいると思います。 彼から最新情報を入手できたら嬉しいです。

最初の実装ではBox<T, A>のサイズを心配する必要はないと思いますが、これは、サポートするだけのDeAllocトレイトを追加することで、下位互換性のある方法で後で追加できるものです。割り当て解除。

それは1つのアプローチですが、それが間違いなく最良のアプローチであるかどうかは私にはまったくわかりません。 これには明確な欠点があります。たとえば、a）ポインタ->アロケータルックアップが可能な場合にのみ機能し（これは、ほとんどのアリーナアロケータには当てはまりません）、b） deallocかなりのオーバーヘッドが追加されます。 この提案またはこの提案のような、より汎用的な効果またはコンテキストシステムである場合があります。 あるいは、まったく別の何かかもしれません。 したがって、これがAlloc特性の現在の化身と下位互換性のある方法で簡単に解決できると想定するべきではないと思います。

@joshlf Box<T, A>はドロップされたときにのみ自分自身にアクセスできるという事実を考えると、これは安全なコードのみで実行できる最善のことです。 このようなパターンは、操作なしのdeallocあり、アロケーターがドロップされたときにメモリを解放するだけのアリーナのようなアロケーターに役立つ場合があります。

アロケータがコンテナ（ LinkedList ）によって所有され、複数の割り当てを管理する、より複雑なシステムの場合、 Boxは内部で使用されないと予想されます。 代わりに、 LinkedList内部は、 LinkedListオブジェクトに含まれているAllocインスタンスで割り当てられて解放される生のポインターを使用します。 これにより、すべてのポインターのサイズが2倍になるのを防ぐことができます。

Box<T, A>はドロップされたときにのみ自分自身にアクセスできるという事実を考えると、これは安全なコードのみで実行できる最善のことです。 このようなパターンは、操作なしのdeallocあり、アロケーターがドロップされたときにメモリを解放するだけのアリーナのようなアロケーターに役立つ場合があります。

そうですが、 Boxは、 deallocがノーオペレーションであることを知りません。

アロケーターがコンテナーによって所有され（ LinkedList ）、複数の割り当てを管理する、より複雑なシステムの場合、Boxは内部で使用されないことを期待しています。 代わりに、 LinkedList内部は、 LinkedListオブジェクトに含まれているAllocインスタンスで割り当てられて解放される生のポインターを使用します。 これにより、すべてのポインターのサイズが2倍になるのを防ぐことができます。

コレクションを作成するために安全でないコードを使用するように人々に要求することは本当に残念だと思います。 目標がすべてのコレクション（おそらく標準ライブラリの外部のものを含む）をアロケーターでオプションでパラメトリックにすることであり、 Boxがアロケーターパラメトリックではない場合、コレクションの作成者はBox使用してはなりません。

そうですが、Boxはdeallocがノーオペレーションであることを知りません。

なぜC ++ unique_ptrが行うことを適応させないのですか？
つまり、アロケータが「ステートフル」の場合はポインタを格納し、アロケータが「ステートレス」の場合は格納しないようにします。
（たとえば、 mallocまたはmmapグローバルラッパー）。
これには、現在のAllocトレインをStatefulAllocとStatelessAlloc 2つの特性に分割する必要があります。
私はそれが非常に失礼でエレガントでないことを理解しています（そしておそらく誰かが以前の議論でそれをすでに提案しました）。
その優雅さにもかかわらず、このソリューションはシンプルで下位互換性があります（パフォーマンスのペナルティはありません）。

コレクションを作成するために安全でないコードを使用するように人々に要求することは本当に残念だと思います。 目標がすべてのコレクション（おそらく標準ライブラリの外部のものを含む）をアロケーターでオプションでパラメトリックにすることであり、Boxがアロケーターパラメトリックではない場合、コレクションの作成者はBoxをまったく使用しないか、安全でないコードを使用する必要があります（および常に物事を解放することを覚えておくことは、CおよびC ++で最も一般的なタイプのメモリの安全性の問題の1つであるため、安全でないコードを正しく取得するのは困難です）。 それは不幸な掘り出し物のようです。

リストやツリーなどのノードベースのコンテナを安全な方法で記述できるエフェクトまたはコンテキストシステムの実装には、時間がかかりすぎる可能性があります（原則として可能であれば）。
この問題に取り組んでいる論文や学術言語は見当たりませんでした（そのような作品が実際に存在する場合は訂正してください）。

したがって、ノードベースのコンテナの実装でunsafeに頼ることは、少なくとも短期的には必要悪かもしれません。

@eucpp注unique_ptr保存されていないがallocator--それが格納Deleter ：

Deleterは、FunctionObjectまたはFunctionObjectへの左辺値参照、または関数への左辺値参照である必要があり、unique_ptr型の引数で呼び出すことができます。::ポインタ `

これは、分割されたAllocとDealloc特性を提供することとほぼ同等であると思います。

@cramertjはい、その通りです。 それでも、ステートフルとステートレスの2つの特性が必要ですDealloc 。

ZST Deallocで十分ではないでしょうか？

15:08 Evgeniy Moiseenkoで火、2018年6月12日には[email protected]
書きました：

@cramertj https://github.com/cramertjはい、その通りです。 それでも、2つ
特性が必要です-ステートフルおよびステートレスDealloc。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/rust-lang/rust/issues/32838#issuecomment-396716689 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AEAJtWkpF0ofVc18NwbfV45G4QY6SCFBks5t8B_AgaJpZM4IDYUN
。

ZST Deallocで十分ではないでしょうか？

@remexre私はそれがそうなると思います:)

rustコンパイラがZSTをすぐにサポートすることを知りませんでした。
C ++では、空のベースの最適化に関する少なくともいくつかのトリックが必要になります。
私はRustでかなり新しいので、いくつかの明らかな間違いをお詫びします。

ステートフルとステートレスに別々の特性が必要だとは思いません。

Box A型パラメーターを追加すると、 Aへの参照やポインターではなく、 A値が直接含まれます。 そのタイプは、ステートレス（デ）アロケータのサイズをゼロにすることができます。 または、 A自体は、割り当てられた複数のオブジェクト間で共有できるステートフルアロケーターへの参照またはハンドルのようなものにすることができます。 したがって、 impl Alloc for MyAllocator代わりに、 impl<'r> Alloc for &'r MyAllocatorようなことをしたいと思うかもしれません。

ちなみに、割り当て解除の方法だけを知っていて、割り当て方法を知らないBox 、 Clone実装しません。

@SimonSapin Clone ingでは、新しいBoxを作成するのと同じ方法で、アロケーターを再度指定する必要があると思います（つまり、 Cloneを使用して実行することはありません）。

@cramertj VecやCloneを実装する他のコンテナと比較して一貫性がないのではないでしょうか。
インスタンス格納する欠点は何ですかAlloc内側BoxではなくDealloc ？
次に、 BoxはCloneとclone_with_alloc実装する可能性があります。

私はこれを分割特性が実際にクローンに大きな影響を与えるとは思いません-implはimpl<T, A> Clone for Box<T, A> where A: Alloc + Dealloc + Clone { ... }ます。

@sfackler私はそのimplに反対しませんが、 clone_intoまたは提供されたアロケーターを使用するものがあることも期待します。

alloc_copyメソッドからAlloc意味がありますか？ これは、たとえばページのコピーオンライトクローンを作成することにより、大規模な割り当てに対してより高速なmemcpy（ Copy/Clone ）実装を提供するために使用できます。

これはかなりクールで、デフォルトの実装を提供するのは簡単です。

このようなalloc_copy関数を使用するとどうなるでしょうか。 impl Clone for Box<T, A> ？

ええ、 Vec同上。

もう少し調べてみると、少なくとも1レベル以上の深さで作成したい場合は、ハッキーと不可能の間の同じプロセス範囲内でコピーオンライトページを作成するアプローチのようです。 したがって、 alloc_copyは大きなメリットにはなりません。

代わりに、将来の仮想メモリのシェナニガンを可能にする、より一般的なエスケープハッチが役立つ可能性があります。 つまり、割り当てが大きく、とにかくmmapに支えられてステートレスである場合、アロケータは割り当ての将来の変更について気付かないことを約束できます。 次に、ユーザーはそのメモリをパイプに移動したり、マップを解除したりすることができます。
あるいは、ダムのmmap-all-the-thingsアロケーターとtry-transfer関数が存在する可能性があります。

代わりに、将来の仮想メモリを可能にするより一般的なエスケープハッチ

メモリアロケータ（malloc、jemalloc、...）は、通常、それらから任意の種類のメモリを盗むことはできません。また、通常、所有するメモリのプロパティを照会または変更することもできません。 では、この一般的なエスケープハッチはメモリアロケータと何の関係があるのでしょうか。

また、仮想メモリのサポートはプラットフォーム間で大きく異なるため、仮想メモリを効果的に使用するには、プラットフォームごとに異なるアルゴリズムが必要になることが多く、保証もまったく異なります。 私は仮想メモリ上でいくつかの移植可能な抽象化を見てきましたが、それらの「移植性」のためにいくつかの状況で役に立たないほど機能しなくなっていないものはまだ見ていません。

あなたが正しい。 そのようなユースケース（私は主にプラットフォーム固有の最適化を考えていました）は、おそらく最初にカスタムアロケーターを使用することによって最もよく提供されます。

AndreiAlexandrescuがCppConプレゼンテーションで説明したComposableAllocator APIについて何か考えはありますか？ ビデオはここのYouTubeで利用可能です： https ： ます、しかし話はあなたがそれを通して見ることを好むかもしれない十分に面白いです） 。

これらすべての必然的な結論は、コレクションライブラリは一般的なWRT割り当てであり、アプリプログラマー自身が建設現場でアロケーターとコレクションを自由に作成できる必要があるということのように思えます。

AndreiAlexandrescuがCppConプレゼンテーションで説明したComposableAllocator APIについて何か考えはありますか？

現在のAlloc APIを使用すると、構成可能なアロケーター（ MyAlloc<Other: Alloc> ）を記述でき、特性と特殊化を使用して、Andreisトークで達成されるほとんどすべてを達成できます。 ただし、AndreiがAPIを構築する方法は、最初から制約のないジェネリック+ SFINAE / staticに基づいているため、Andreiの話からはほとんど何もRustに適用できないという「アイデア」を超えて、Rustのジェネリックシステムそれとは全然違います。

残りのLayoutメソッドを安定させることを提案したいと思います。 これらは、現在のグローバルアロケータAPIですでに役立ちます。

これらはあなたが意味するすべての方法ですか？

• pub fn align_to(&self, align: usize) -> Layout
• pub fn padding_needed_for(&self, align: usize) -> usize
• pub fn repeat(&self, n: usize) -> Result<(Layout, usize), LayoutErr>
• pub fn extend(&self, next: Layout) -> Result<(Layout, usize), LayoutErr>
• pub fn repeat_packed(&self, n: usize) -> Result<Layout, LayoutErr>
• pub fn extend_packed(&self, next: Layout) -> Result<(Layout, usize), LayoutErr>
• pub fn array<T>(n: usize) -> Result<Layout, LayoutErr>

@gnzlbgはい。

@Amanieuは私には問題ないように

アロケーターとライフタイムから：

1. （allocator implsの場合）：allocator値を移動しても、未処理のメモリブロックが無効になってはなりません。

   すべてのクライアントは、コードでこれを想定できます。

   したがって、クライアントがアロケータからブロックを割り当て（a1と呼びます）、次にa1が新しい場所に移動した場合（たとえば、vialet a2 = a1;）、クライアントがa2を介してそのブロックの割り当てを解除することは健全なままです。

これは、アロケータがUnpinなければならないことを意味しますか？

いいキャッチ！

Allocトレイトはまだ不安定なので、RFCのこの部分を変更したい場合は、ルールを変更できると思います。 しかし、それは確かに心に留めておくべきことです。

@gnzlbgはい、ジェネリックシステムの大きな違いを認識しています。彼が詳述するすべてがRustで同じように実装できるわけではありません。 とはいえ、投稿以来、ライブラリのオンとオフに取り組んでおり、順調に進んでいます。

これは、アロケータがUnpinなければならないことを意味しますか？

そうではありません。 Unpinは、 Pinでラップされたときの型の動作に関するものであり、このAPIへの特別な接続はありません。

しかし、 Unpinを使用して前述の制約を適用することはできませんか？

dealloc_arrayに関する別の質問：関数がResult返すのはなぜですか？ 現在の実装では、これは2つの場合に失敗する可能性があります。

• nはゼロです
• n * size_of::<T>()容量オーバーフロー

最初のケースには2つのケースがあります（ドキュメントのように、実装者はこれらから選択できます）。

• 割り当てを返しOkゼロ化にn => dealloc_arrayも返す必要がOk 。
• 割り当ては、ゼロ化されたn =>にErrを返します。 dealloc_array渡すことができるポインタはありません。

2つ目は、次の安全上の制約によって保証されます。

[T; n]のレイアウトは、そのメモリブロックに適合している必要

つまり、割り当てと同じn dealloc_arrayを呼び出す必要があります。 n要素を持つ配列を割り当てることができる場合、 nはTに対して有効です。 そうでなければ、割り当ては失敗するでしょう。

編集：最後の点について： usable_sizeがn * size_of::<T>()よりも高い値を返したとしても、これは引き続き有効です。 それ以外の場合、実装はこの特性制約に違反します。

ブロックのサイズは[use_min, use_max]範囲内にある必要があります。ここで、

• [...]
• use_maxは、ブロックがalloc_excessまたはrealloc_excessへの呼び出しを介して割り当てられたときに返された（または返されたはずの）容量です。

特性にはunsafe implが必要なため、これは当てはまります。

最初のケースには2つのケースがあります（ドキュメントのように、実装者はこれらから選択できます）。

• 割り当ては、ゼロ化されたn Okを返します

この情報はどこから入手しましたか？

ドキュメント内のすべてのAlloc::alloc_メソッドは、ゼロサイズの割り当ての動作が「Safety」句で定義されていないことを指定しています。

core::alloc::Allocドキュメント（強調表示された関連部分）：

ゼロサイズの型とゼロサイズのレイアウトに関する注意： Allocトレイトの多くのメソッドは、割り当て要求はゼロ以外のサイズでなければならないと述べています。そうしないと、未定義の動作が発生する可能性があります。

• ただし、一部の高レベルの割り当て方法（ alloc_one 、 alloc_array ）は、サイズがゼロの型で明確に定義されており、オプションでそれらをサポートできます。 ErrをErr 、またはポインタを付けて

• この場合、 Alloc実装がOkを返すことを選択した場合（つまり、ポインターがゼロサイズのアクセスできないブロックを示している場合）、返されたポインターは「現在割り当てられている」と見なす必要があります。 このようなアロケータでは、現在割り当てられているポインタを入力として受け取るすべてのメソッドは、未定義の動作を引き起こす

• 言い換えると、ゼロサイズのポインターがアロケーターから流出する可能性がある場合、そのアロケーターは同様に、そのポインターが割り当て解除および再割り当てメソッドに逆流することを受け入れる必要があります。

したがって、 dealloc_arrayのエラー状態の1つは間違いなく疑わしいものです。

/// # Safety
///
/// * the layout of `[T; n]` must *fit* that block of memory.
///
/// # Errors
///
/// Returning `Err` indicates that either `[T; n]` or the given
/// memory block does not meet allocator's size or alignment
/// constraints.

[T; N]がアロケータのサイズまたは配置の制約を満たさない場合、AFAICTは割り当てのメモリブロックに適合せず、動作は未定義です（安全条項による）。

もう1つのエラー条件は、「算術オーバーフロー時に常にErrを返す」です。 これはかなり一般的です。 それが有用なエラー状態であるかどうかを見分けるのは難しいです。 Alloc特性の実装ごとに、理論的にラップできる算術演算を実行できる別の実装を思い付くことができる可能性があるため、🤷‍♂️

core::alloc::Allocドキュメント（強調表示された関連部分）：

確かに。 非常に多くのメソッド（ Alloc::alloc ）がゼロサイズの割り当てが未定義の動作であると述べているのは奇妙だと思いますが、 Alloc::alloc_array(0)に実装定義の動作を提供するだけです。 ある意味で、 Alloc::alloc_array(0)は、アロケーターがゼロサイズの割り当てをサポートしているかどうかを確認するためのリトマス試験です。

[T; N]がアロケータのサイズまたは配置の制約を満たさない場合、AFAICTは割り当てのメモリブロックに適合せず、動作は未定義です（安全条項による）。

うん、このエラー状態は冗長なので削除できると思います。 安全条項またはエラー条件のいずれかが必要ですが、両方は必要ありません。

もう1つのエラー条件は、「算術オーバーフロー時に常にErrを返す」です。 これはかなり一般的です。 それが有用なエラー状態であるかどうかを見分けるのは難しいです。

IMO、それは上記と同じ安全条項によって守られています。 [T; N]の容量がオーバーフローした場合、そのメモリブロックは割り当て解除に適合しません。 たぶん@pnkfelixはこれについて詳しく

ある意味で、 Alloc::alloc_array(1)は、アロケーターがゼロサイズの割り当てをサポートしているかどうかを確認するためのリトマス試験です。

Alloc::alloc_array(0)ですか？

IMO、それは上記と同じ安全条項によって守られています。 [T; N]の容量がオーバーフローした場合、そのメモリブロックの割り当てを解除することはできません。

この特性は、ユーザーが独自のカスタムアロケーターに対して実装できること、およびこれらのユーザーがこれらのメソッドのデフォルトの実装をオーバーライドできることに注意してください。 したがって、これが算術オーバーフローに対してErrを返すかどうかを検討するときは、デフォルトメソッドの現在のデフォルト実装が何をするかに焦点を当てるだけでなく、他の人のためにこれらを実装するユーザーにとって何が理にかなっているかも考慮する必要があります。アロケーター。

Alloc::alloc_array(0)ですか？

うん、ごめん。

この特性は、ユーザーが独自のカスタムアロケーターに対して実装できること、およびこれらのユーザーがこれらのメソッドのデフォルトの実装をオーバーライドできることに注意してください。 したがって、これが算術オーバーフローに対してErrを返すかどうかを検討するときは、デフォルトメソッドの現在のデフォルト実装が何をするかに焦点を当てるだけでなく、他の人のためにこれらを実装するユーザーにとって何が理にかなっているかも考慮する必要があります。アロケーター。

わかりましたが、 Alloc実装するにはunsafe implが必要であり、実装者はhttps://github.com/rust-lang/rust/issues/32838#issuecomment-467093527に記載されている安全規則に従う必要があり

追跡の問題のためにここに残されたすべてのAPIは、 Alloc特性であるか、 Alloc特性に関連しています。 @ rust-lang / libs、 https：//github.com/rust-lang/rust/issues/42774に加えて、これを開いたままにしておくと便利だと思い

簡単な背景の質問：ZSTの柔軟性の背後にある動機は何ですか？ コンパイル時に型がZSTであることがわかっているので、割り当て（定数値を返すため）と割り当て解除の両方を完全に最適化できるように思われます。 それを考えると、私たちは次のいずれかを言うべきだと私には思えます：

• ZSTをサポートするかどうかは常に実装者次第であり、ZSTに対してErrを返すことはできません。
• ZSTを割り当てるのは常にUBであり、この場合に短絡するのは呼び出し元の責任です。
• 呼び出し元が実装するある種のalloc_innerメソッドと、短絡を行うデフォルトの実装を持つallocメソッドがあります。 allocはZSTをサポートする必要がありますが、 alloc_innerはZSTに対して呼び出されない場合があります（これは、短絡ロジックを1か所（特性定義内）に順番に追加できるようにするためです。実装者に定型文を保存するため）

現在のAPIの柔軟性が必要な理由はありますか？

現在のAPIの柔軟性が必要な理由はありますか？

これはトレードオフです。 間違いなく、Allocトレイトは実装されるよりも頻繁に使用されるため、ZSTの組み込みサポートを提供することで、Allocをできるだけ簡単に使用できるようにすることが理にかなっている場合があります。

これは、Allocトレイトの実装者がこれを処理する必要があることを意味しますが、Allocトレイトを進化させようとする人は、APIが変更されるたびにZSTを念頭に置く必要があることを私にとってより重要です。 また、ZSTがどのように処理されるか（または「実装定義」の場合はそうなる可能性がある）を説明することにより、APIのドキュメントを複雑にします。

C ++アロケーターはこのアプローチを追求し、アロケーターは多くの異なる問題を解決しようとします。 これにより、実装や進化が困難になっただけでなく、これらすべての問題がAPIでどのように相互作用するかにより、ユーザーが実際に使用することも困難になりました。

ZSTの処理とrawメモリの割り当て/割り当て解除は、2つの直交する異なる問題であると思います。したがって、ZSTを処理しないだけで、AllocトレイトAPIを単純に保つ必要があります。

libstdのようなAllocのユーザーは、たとえば各コレクションでZSTを処理する必要があります。 それは間違いなく解決する価値のある問題ですが、Allocの特性がそのための場所ではないと思います。 この問題を解決するユーティリティが必要に応じてlibstd内に飛び出すことを期待します。その場合、そのようなユーティリティをRFCして、std :: heapで公開することができます。

それはすべて合理的に聞こえます。

ZSTの処理とrawメモリの割り当て/割り当て解除は、2つの直交する異なる問題であると思います。したがって、ZSTを処理しないだけで、AllocトレイトAPIを単純に保つ必要があります。

これは、APIが実装定義ではなく、明示的にZSTを処理しないようにする必要があることを意味しませんか？ IMO、「サポートされていない」エラーは、実行時にあまり役に立ちません。これは、呼び出し元の大多数がフォールバックパスを定義できないため、ZSTがサポートされていないと想定する必要があるためです。 APIを単純化し、サポートされていないことを宣言する方がクリーンなようです。

allocユーザーがZSTを処理するために特殊化を使用しますか？ それともif size_of::<T>() == 0チェックだけですか？

allocユーザーがZSTを処理するために特殊化を使用しますか？ それともif size_of::<T>() == 0チェックだけですか？

後者で十分です。 適切なコードパスは、コンパイル時に簡単に削除されます。

これは、APIが実装定義ではなく、明示的にZSTを処理しないようにする必要があることを意味しませんか？

私にとって重要な制約は、ゼロサイズの割り当てを禁止する場合、 Allocメソッドは、渡されるLayoutがゼロサイズではないと想定できる必要があるということです。

これを実現する方法は複数あります。 1つは、すべてのAllocメソッドに別のSafety句を追加して、 Layoutサイズがゼロの場合の動作が未定義であることを示すことです。

または、ゼロサイズのLayout禁止することもできます。そうすると、 Allocはゼロサイズの割り当てについて何も言う必要がなくなります。これは安全に実行できないためですが、これを行うといくつかの欠点があります。

たとえば、 HashMapような一部のタイプLayout 、複数のLayoutからLayoutを構築し、最後のLayoutはゼロサイズではない場合がありますが、中間のものはそうかもしれません（例えばHashSet ）。 したがって、これらのタイプは、最終的なLayoutを構築するために「何か他のもの」（たとえば、 LayoutBuilderタイプ）を使用し、「ゼロ以外のサイズ」の小切手に支払う必要があります（またはLayoutに変換するときの_unchecked ）メソッド。

特殊化は、ZSTを処理するためにallocユーザーによって使用されますか？ または、size_of ::の場合（）== 0チェック？

まだZSTに特化することはできません。 現在、すべてのコードはsize_of::<T>() == 0ます。

これを実現する方法は複数あります。 1つは、すべてのAllocメソッドに別のSafety句を追加して、 Layoutサイズがゼロの場合の動作が未定義であることを示すことです。

これをコンパイル時の保証にする方法があるかどうかを検討するのは興味深いことですが、レイアウトがゼロ以外のサイズであるというdebug_assertでさえ、99％のバグをキャッチするのに十分なはずです。

アロケーターについての議論には注意を払っていないので、申し訳ありません。 しかし、私は長い間、アロケーターが割り当てている値のタイプにアクセスできることを望んでいました。 それを使用できるアロケータ設計があるかもしれません。

次に、おそらくC ++と同じ問題が発生します。これはアロケーターAPIです。

しかし、私は長い間、アロケーターが割り当てている値のタイプにアクセスできることを望んでいました。 T

これは何のために必要ですか？

@gnzblg @brson今日、割り当てられている値のタイプについて_何か_を知るための潜在的なユースケースがありました。

私は、3つの基礎となるアロケーター（スレッドローカルアロケーター、ロック付きグローバルアロケーター、およびコルーチンが使用するアロケーター）の間で切り替えることができるグローバルアロケーターに取り組んでいます-ネットワーク接続を表すコルーチンを最大に制限できるという考え動的メモリ使用量（コレクション内のアロケーターを制御できない場合、特にサードパーティコード内）*。

スレッド間を移動する可能性のある値（Arcなど）と移動しない値を割り当てているかどうかを知ると便利な場合があります。 またはそうではないかもしれません。 しかし、それは可能なシナリオです。 現時点では、グローバルアロケーターには、ユーザーがどのアロケーターから割り当てを行うかを指示するために使用するスイッチがあります（reallocまたはfreeには必要ありません。そのためのメモリアドレスを確認できます）。

* [また、可能な限りロックなしでNUMAローカルメモリを使用でき、1コア1スレッドモデルでは、合計メモリ使用量を制限できます]。

@raphaelcohn

私はグローバルアロケーターに取り組んでいます

これはGlobalAllocトレイトには当てはまらない（または当てはまる）とは思いません。 Allocトレイトには、型情報を利用できる汎用メソッドがすでにあります（例： alloc_array<T>(1)は単一のT alloc_array<T>(1)割り当てます。ここで、 Tは実際の型であるため、アロケーターは割り当ての実行時に型を考慮に入れることができます）。 この議論の目的には、型情報を利用するアロケーターを実装するコードを実際に見る方が便利だと思います。 これらのメソッドが、アロケーターAPIまたは他のアロケーター特性の一部であるだけでなく、一般的なアロケーター特性の一部である必要がある理由について、良い議論を聞いたことがありません。

Allocによってパラメーター化されたタイプのどれを、タイプ情報を使用するアロケーターと組み合わせるつもりであり、その結果として何を期待するかを知ることも非常に興味深いと思います。

AFAICTは、 T直接割り当てるため、そのための唯一の興味深いタイプはBoxです。 ほとんどのすべての他のタイプstd割り当てることはありませんTあなたのアロケータは何も知らないことを、いくつかの民間の内部型を。 たとえば、 RcとArcは、 (InternalRefCounts, T) 、 List / BTreeSetなどを割り当てます。内部ノードタイプVec割り当てます。 Deque / ... Tの配列を割り当てますが、 T自体は割り当てません。

BoxとVec 、下位互換性のある方法でBoxAllocとArrayAlloc特性を追加し、アロケーターができるAlloc包括的実装を追加できます。これらの問題を一般的な方法で攻撃する必要がある場合は、それらの動作をハイジャックすることに特化してください。 しかし、タイプ情報を悪用するためにアロケーターと共謀する独自のMyAllocBoxおよびMyAllocVecタイプを提供することが、実行可能な解決策ではない理由はありますか？

現在、アロケーターWG専用のリポジトリがあり、OPのリストが古くなっているため、この問題を閉じて、この機能の議論と追跡を1か所で行うことができますか？

良い点@TimDiekmann！ そのリポジトリ内のディスカッションスレッドを優先して、先に進んでこれを閉じます。

これは、一部の#[unstable]属性が指す追跡の問題です。 これらの機能が安定化または非推奨になるまで、閉鎖すべきではないと思います。 （または、別の問題を指すように属性を変更することもできます。）

ええ、git masterで参照されている不安定な機能には、間違いなく未解決の追跡の問題があるはずです。

同意しました。 また、OPへの通知とリンクを追加しました。