Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
42 changes: 31 additions & 11 deletions 1.9/ja/book/custom-allocators.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,10 @@
<!-- out the default global allocator in use at compile time. The design is currently -->
<!-- spelled out in [RFC 1183][rfc] but this will walk you through how to get your -->
<!-- own allocator up and running. -->
メモリ割り当てが常に簡単に出来るとは限りません。ほとんどの場合、Rustが既定の方法でメモリ割り当てを行いますが、割り当て方法をカスタマイズする必要が出てくる場合があります。現在、コンパイラと標準ライブラリはコンパイル時に既定のグローバルアロケータを切り替えることが出来ます。詳細は [RFC 1183][rfc] に書かれていますが、ここではどのように独自のアロケータを作成するか順を追って説明します。
メモリ割り当てが常に簡単にできるとは限りません。
ほとんどの場合、Rustが既定の方法でメモリ割り当てを行いますが、割り当て方法をカスタマイズする必要が出てくる場合があります。
現在、コンパイラと標準ライブラリはコンパイル時に既定のグローバルアロケータを切り替えることができます。
詳細は [RFC 1183][rfc] に書かれていますが、ここではどのように独自のアロケータを作成するか順を追って説明します。

[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1183-swap-out-jemalloc.md

Expand All @@ -17,32 +20,40 @@

<!-- The compiler currently ships two default allocators: `alloc_system` and -->
<!-- `alloc_jemalloc` (some targets don't have jemalloc, however). These allocators -->
<!-- are just normal Rust crates and contain an implementation of the routines to -->
<!-- are normal Rust crates and contain an implementation of the routines to -->
<!-- allocate and deallocate memory. The standard library is not compiled assuming -->
<!-- either one, and the compiler will decide which allocator is in use at -->
<!-- compile-time depending on the type of output artifact being produced. -->
現在コンパイラは `alloc_system` と `alloc_jemalloc` (jemallocのないターゲットもあります)という2つの既定のアロケータを提供しています。これらのアロケータは単に普通のRustのクレートで、メモリの割り当てと解放の手続きを実装しています。標準ライブラリはどちらか一方を前提としてコンパイルされているわけではありません。コンパイラは生成する成果物の種類に応じてどちらのアロケータを使用するかをコンパイル時に決定します。
現在コンパイラは `alloc_system` と `alloc_jemalloc` (jemallocのないターゲットもあります)という2つの既定のアロケータを提供しています。
これらのアロケータは普通のRustのクレートで、メモリの割り当てと解放の手続きを実装しています。
標準ライブラリはどちらか一方を前提としてコンパイルされているわけではありません。
コンパイラは生成する成果物の種類に応じてどちらのアロケータを使用するかをコンパイル時に決定します。

<!-- Binaries generated by the compiler will use `alloc_jemalloc` by default (where -->
<!-- available). In this situation the compiler "controls the world" in the sense of -->
<!-- it has power over the final link. Primarily this means that the allocator -->
<!-- decision can be left up the compiler. -->
バイナリを生成する場合、既定では(もし可能なら) `alloc_jemalloc` を使用します。この場合、コンパイラは最後のリンクにまで影響力を持っているという意味で、「全世界を支配」しています。従ってアロケータの選択はコンパイラに委ねることができます。
バイナリを生成する場合、既定では(もし可能なら) `alloc_jemalloc` を使用します。
この場合、コンパイラは最後のリンクにまで影響力を持っているという意味で、「全世界を支配」しています。
従ってアロケータの選択はコンパイラに委ねることができます。

<!-- Dynamic and static libraries, however, will use `alloc_system` by default. Here -->
<!-- Rust is typically a 'guest' in another application or another world where it -->
<!-- cannot authoritatively decide what allocator is in use. As a result it resorts -->
<!-- back to the standard APIs (e.g. `malloc` and `free`) for acquiring and releasing -->
<!-- memory. -->
一方、動的あるいは静的ライブラリの場合、既定では `alloc_system` を使用します。他のアプリケーションや他の環境など、使用するアロケータの決定権がない世界において、Rustは「お客」に過ぎません。そのため、メモリの割り当てと解放を行うには、標準API(例えば `malloc` と `free` )に頼ることになります。
一方、動的あるいは静的ライブラリの場合、既定では `alloc_system` を使用します。
他のアプリケーションや他の環境など、使用するアロケータの決定権がない世界において、Rustは「お客」に過ぎません。
そのため、メモリの割り当てと解放を行うには、標準API(例えば `malloc` と `free` )に頼ることになります。

<!-- # Switching Allocators -->
# アロケータの切り替え

<!-- Although the compiler's default choices may work most of the time, it's often -->
<!-- necessary to tweak certain aspects. Overriding the compiler's decision about -->
<!-- which allocator is in use is done simply by linking to the desired allocator: -->
コンパイラによる既定の選択はほとんどの場合うまく動きますが、しばしば多少の調整が必要になることがあります。コンパイラのアロケータ選択を上書きするには、単に希望のアロケータとリンクするだけです。
コンパイラによる既定の選択はほとんどの場合うまく動きますが、しばしば多少の調整が必要になることがあります。
コンパイラのアロケータ選択を上書きするには、単に希望のアロケータとリンクするだけです。

```rust,no_run
#![feature(alloc_system)]
Expand All @@ -59,7 +70,8 @@ fn main() {
<!-- In this example the binary generated will not link to jemalloc by default but -->
<!-- instead use the system allocator. Conversely to generate a dynamic library which -->
<!-- uses jemalloc by default one would write: -->
この例で生成されるバイナリは既定のjemallocとリンクする代わりに、システムアロケータを使います。逆に既定でjemallocを使う動的ライブラリを生成するには次のようにします。
この例で生成されるバイナリは既定のjemallocとリンクする代わりに、システムアロケータを使います。
逆に既定でjemallocを使う動的ライブラリを生成するには次のようにします。

```rust,ignore
#![feature(alloc_jemalloc)]
Expand All @@ -83,7 +95,9 @@ pub fn foo() {
<!-- crate which implements the allocator API (e.g. the same as `alloc_system` or -->
<!-- `alloc_jemalloc`). As an example, let's take a look at a simplified and -->
<!-- annotated version of `alloc_system` -->
時々jemallocとシステムアロケータの選択では足りず、全く新しいカスタムアロケータが必要になることがあります。この場合、アロケータAPI(例えば `alloc_system` や `alloc_jemalloc` と同様のもの)を実装した独自のクレートを書くことになります。例として、 `alloc_system` の簡素な注釈付きバージョンを見てみましょう。
時々jemallocとシステムアロケータの選択では足りず、全く新しいカスタムアロケータが必要になることがあります。
この場合、アロケータAPI(例えば `alloc_system` や `alloc_jemalloc` と同様のもの)を実装した独自のクレートを書くことになります。
例として、 `alloc_system` の簡素な注釈付きバージョンを見てみましょう。

```rust,no_run
# // only needed for rustdoc --test down below
Expand Down Expand Up @@ -165,7 +179,7 @@ pub extern fn __rust_usable_size(size: usize, _align: usize) -> usize {
size
}

# // just needed to get rustdoc to test this
# // only needed to get rustdoc to test this
# fn main() {}
# #[lang = "panic_fmt"] fn panic_fmt() {}
# #[lang = "eh_personality"] fn eh_personality() {}
Expand All @@ -174,6 +188,8 @@ pub extern fn __rust_usable_size(size: usize, _align: usize) -> usize {
# #[no_mangle] pub extern fn rust_eh_unregister_frames () {}
```

**TODO**:最後のコメントを翻訳する

<!-- After we compile this crate, it can be used as follows: -->
このクレートをコンパイルすると、次のように使えるようになります。

Expand All @@ -198,11 +214,15 @@ fn main() {
<!-- dylibs, and staticlibs must link to exactly one allocator, and if none have -->
<!-- been explicitly chosen the compiler will choose one. On the other hand rlibs -->
<!-- do not need to link to an allocator (but still can). -->
* 1つの成果物は高々1つのアロケータとしかリンクすることはできません。バイナリ、dynlib、staticlibは必ず1つのアロケータとリンクする必要があり、もし明示的に指定されなければコンパイラがアロケータを選択します。一方、rlibはアロケータとリンクする必要はありません(リンクすることも可能です)。
* 1つの成果物は高々1つのアロケータとしかリンクすることはできません。
バイナリ、dynlib、staticlibは必ず1つのアロケータとリンクする必要があり、もし明示的に指定されなければコンパイラがアロケータを選択します。
一方、rlibはアロケータとリンクする必要はありません(リンクすることも可能です)。

<!-- * A consumer of an allocator is tagged with `#![needs_allocator]` (e.g. the -->
<!-- `liballoc` crate currently) and an `#[allocator]` crate cannot transitively -->
<!-- depend on a crate which needs an allocator (e.g. circular dependencies are not -->
<!-- allowed). This basically means that allocators must restrict themselves to -->
<!-- libcore currently. -->
* アロケータを使うコードは `#![needs_allocator]` でタグ付けされます(例えば現時点での `liballoc` クレート)。また、 `#[allocator]` がついたクレートはアロケータを使うクレートに直接的にも間接的にも依存することが出来ません(例えば、循環依存は許されていません)。このためアロケータは原則としてlibcoreにしか依存しないようにする必要があります。
* アロケータを使うコードは `#![needs_allocator]` でタグ付けされます(例えば現時点での `liballoc` クレート)。
また、 `#[allocator]` がついたクレートはアロケータを使うクレートに直接的にも間接的にも依存することができません(例えば、循環依存は許されていません)。
このためアロケータは原則としてlibcoreにしか依存しないようにする必要があります。
21 changes: 0 additions & 21 deletions diff-1.6.0..1.9.0/src/doc/book/custom-allocators.md

This file was deleted.