diff --git a/_includes/disqus.txt b/_includes/disqus.txt
index c61dc44df4..c4955c51e0 100644
--- a/_includes/disqus.txt
+++ b/_includes/disqus.txt
@@ -1,7 +1,11 @@
 <div id="disqus_thread"></div>
 <script type="text/javascript">
     /* * * CONFIGURATION VARIABLES: EDIT BEFORE PASTING INTO YOUR WEBPAGE * * */
+  {% if page.language == 'ja' %}
+    var disqus_shortname = 'scalajp'; // required: replace example with your forum shortname
+  {% else %}
     var disqus_shortname = 'scalasip'; // required: replace example with your forum shortname
+  {% endif %}
 
     /* * * DON'T EDIT BELOW THIS LINE * * */
     (function() {
diff --git a/_includes/toc-large.txt b/_includes/toc-large.txt
index 91a037d4a1..d5d9dfc6a3 100644
--- a/_includes/toc-large.txt
+++ b/_includes/toc-large.txt
@@ -12,10 +12,10 @@
   <ul>
     {% for i in (1..totalPages) %}
       {% for pg in site.pages %}
-        {% if pg.partof == page.partof and pg.num and pg.num == i %}
-          <li><a href="{{ pg.url }}">{{ pg.title }}</a></li>
+        {% if pg.partof == page.partof and pg.num and pg.num == i and page.language == pg.language %}
+          <li><a href="{{ site.baseurl }}{{ pg.url }}">{{ pg.title }}</a></li>
         {% endif %}   
-        {% if pg.partof == page.partof and pg.num and page.num and page.num == pg.num and pg.num == i %}
+        {% if pg.partof == page.partof and pg.num and page.num and page.num == pg.num and pg.num == i and page.language == pg.language %}
           <div id="toc"></div>
         {% endif %}
       {% endfor %}
diff --git a/_layouts/overview-large.html b/_layouts/overview-large.html
index 07e17ef2c9..af39e9d866 100644
--- a/_layouts/overview-large.html
+++ b/_layouts/overview-large.html
@@ -7,8 +7,30 @@
 <div class="container">
   <div class="row">
     
-    {% if page.title %}<h1>{{ page.title }}</h1>{% else %}<h1>{{ site.title }}</h1>{% endif %}
+    <div class="span10">{% if page.title %}<h1>{{ page.title }}</h1>{% else %}<h1>{{ site.title }}</h1>{% endif %}</div>
     
+    {% for pg in site.pages %}
+      {% if pg.partof == page.partof and pg.languages %}
+        {% assign languages = pg.languages %}
+      {% endif %}
+    {% endfor %}
+
+    {% if page.language %}
+      {% capture intermediate %}{{ page.url | remove_first: page.language }}{% endcapture %}
+      {% capture rootTutorialURL %}{{ intermediate | remove_first: '/' }}{% endcapture %}
+    {% else %}
+      {% assign rootTutorialURL = page.url %}
+    {% endif %}
+
+    <div class="span6">
+      {% if languages %}
+        <a href="{{ site.baseurl }}{{ rootTutorialURL }}"><img src="{{ site.baseurl }}/resources/images/language/en.png" title="Language: en"/></a> 
+        {% for l in languages %}
+          <a href="{{ site.baseurl }}/{{ l }}{{ rootTutorialURL }}"><img src="{{ site.baseurl }}/resources/images/language/{{ l }}.png" title="Language: {{ l }}"/></a> 
+        {% endfor %}
+      {% endif %}
+    </div>
+
     <div class="span10">
       {{ content }}
       {% if page.disqus == true %}{% include disqus.txt %}{% endif %}
diff --git a/ja/overviews/parallel-collections/architecture.md b/ja/overviews/parallel-collections/architecture.md
new file mode 100644
index 0000000000..ee3eeea3e3
--- /dev/null
+++ b/ja/overviews/parallel-collections/architecture.md
@@ -0,0 +1,78 @@
+---
+layout: overview-large
+title: 並列コレクションライブラリのアーキテクチャ
+
+disqus: true
+
+partof: parallel-collections
+num: 5
+language: ja
+---
+
+通常の順次コレクションライブラリと同様に、Scala の並列コレクションライブラリは異なる並列コレクションの型に共通して存在する多くのコレクション演算を含む。
+これも順次コレクションで使われた手法だが、並列コレクションライブラリはほとんどの演算をいくつかある並列コレクション「テンプレート」の中で一度だけ実装することでコードの重複を回避することを目指している。これらの「テンプレート」は多くの異なる並列コレクションの実装により柔軟に継承されている。
+
+この方法の利点はより簡略化された**メンテナンス性**と**拡張性**にある。
+メンテナンスに着目すると、並列コレクションの演算がそれぞれ単一の実装を持ち、全ての並列コレクションによって継承されることで、メンテナンスはより簡単にそして強固になる。なぜなら、バグフィクスはいちいち実装を重複させずに、クラスの継承を通して伝搬するからだ。
+同じ理由で、ライブラリ全体が拡張しやすくなる。新たなコレクションのクラスはその演算の大部分を単に継承すればいいからだ。
+
+## 中心概念
+
+前述の「テンプレート」となるトレイト群は、ほとんどの並列演算をスプリッタ (`Splitter`) とコンバイナ (`Combiner`) という二つの中心概念に基づいて実装する。
+
+### スプリッタ
+
+その名前が示すように、スプリッタ (`Splitter`) の役割は並列コレクションを何らかの有意な方法で要素を分割することだ。
+基本的な考えとしては、コレクションを小さい部分にどんどん分割していき、逐次的に処理できるまで小さくしていくことだ。
+
+    trait Splitter[T] extends Iterator[T] {
+      def split: Seq[Splitter[T]]
+    }
+
+興味深いことに、`Splitter` は `Iterator` として実装されているため（`Iterator` の標準メソッドである `next` や `hasNext` を継承している）、フレームワークはスプリッタを分割だけではなく並列コレクションの走査にも利用できる。
+この「分割イテレータ」の特徴は、`split` メソッドが `this`（`Iterator` の一種である `Splitter`）を分割して、並列コレクション全体の要素に関する**交わりを持たない** (disjoint) の部分集合を走査する別の `Splitter` を生成することだ。
+通常のイテレータ同様に、`Splitter` は一度 `split` を呼び出すと無効になる。
+
+一般的には、コレクションは `Splitter` を用いてだいたい同じサイズの部分集合に分割される。
+特に並列列などにおいて、任意のサイズの区分が必要な場合は、より正確な分割メソッドである `psplit` を実装する `PreceiseSplitter` という `Splitter` のサブタイプが用いられる。
+
+### コンバイナ
+
+コンバイナ (`Combiner`) は、Scala の順次コレクションライブラリのビルダ (`Builder`) をより一般化したものだと考えることができる。
+それぞれの順次コレクションが `Builder` を提供するように、それぞれの並列コレクションは各自 `Combiner` を提供する。
+
+順次コレクションの場合は、`Builder` に要素を追加して、`result` メソッドを呼び出すことでコレクションを生成することができた。
+並列コレクションの場合は、`Combiner` は `combine` と呼ばれるメソッドを持ち、これは別の `Combiner` を受け取り両方の要素の和集合を含む新たな `Combiner` を生成する。`combine` が呼び出されると、両方の `Combiner` とも無効化される。
+
+    trait Combiner[Elem, To] extends Builder[Elem, To] {
+      def combine(other: Combiner[Elem, To]): Combiner[Elem, To]
+    }
+
+上のコードで、二つの型パラメータ `Elem` と `To` はそれぞれ要素型と戻り値のコレクションの型を表す。
+
+**注意:** `c1 eq c2` が `true` である二つの `Combiner` （つまり、同一の `Combiner` という意味だ）があるとき、`c1.combine(c2)` は常に何もせずに呼ばれた側の `Combiner` である `c1` を返す。
+
+## 継承関係
+
+Scala の並列コレクションは、Scala の（順次）コレクションライブラリの設計から多大な影響を受けている。
+以下に示すよう、トレイト群は通常のコレクションフレームワーク内のトレイト群を鏡写しのように対応している。
+
+[<img src="{{ site.baseurl }}/resources/images/parallel-collections-hierarchy.png" width="550">]({{ site.baseurl }}/resources/images/parallel-collections-hierarchy.png)
+
+<center><b>Scala のコレクションと並列コレクションライブラリの継承関係</b></center>
+<br/>
+
+並列コレクションが順次コレクションに緊密に統合することで、順次コレクションと並列コレクションの単純な置換えが可能となることを目標としている。
+
+順次か並列かのどちらでもありうる（`par` と `seq` を呼び出すことで並列コレクションと順次コレクションを切り替えられるような）コレクションへの参照を持つためには、両方のコレクション型に共通するスーパー型の存在が必要となる。
+これが、上の図に出てくる `GenTraversable`、`GenIterable`、`GenSeq`、`GenMap`、`GenSet` という「一般」(general) トレイト群で、これらは順番通り (in-order) の走査も、逐次的 (one-at-a-time) な走査も保証しない。
+対応する順次トレイトや並列トレイトはこれらを継承する。
+例えば、`ParSeq` と `Seq` は両方とも一般列 `GenSeq` のサブタイプだが、お互いは継承関係に無い。
+
+順次コレクションと並列コレクションの継承関係に関するより詳しい議論は、このテクニカルリポートを参照してほしい。 \[[1][1]\]
+
+## 参照
+
+1. [On a Generic Parallel Collection Framework, Aleksandar Prokopec, Phil Bawgell, Tiark Rompf, Martin Odersky, June 2011][1]
+
+[1]: http://infoscience.epfl.ch/record/165523/files/techrep.pdf "flawed-benchmark"
diff --git a/ja/overviews/parallel-collections/concrete-parallel-collections.md b/ja/overviews/parallel-collections/concrete-parallel-collections.md
new file mode 100644
index 0000000000..c6b863dad3
--- /dev/null
+++ b/ja/overviews/parallel-collections/concrete-parallel-collections.md
@@ -0,0 +1,164 @@
+---
+layout: overview-large
+title: 具象並列コレクションクラス
+
+disqus: true
+
+partof: parallel-collections
+num: 2
+language: ja
+---
+
+## 並列配列
+
+並列配列 ([`ParArray`](http://www.scala-lang.org/api/{{ site.scala-version }}/scala/collection/parallel/mutable/ParArray.html)) は、線形で連続的な要素の配列を保持する列だ。
+そのため、内部の配列を変更することで効率的な要素の読み込みや更新ができるようになる。
+また、要素の走査も非常に効率的だ。
+並列配列は、サイズが一定であるという意味で配列と似ている。
+
+    scala> val pa = scala.collection.parallel.mutable.ParArray.tabulate(1000)(x => 2 * x + 1)
+    pa: scala.collection.parallel.mutable.ParArray[Int] = ParArray(1, 3, 5, 7, 9, 11, 13,...
+    
+    scala> pa reduce (_ + _)
+    res0: Int = 1000000
+    
+    scala> pa map (x => (x - 1) / 2)
+    res1: scala.collection.parallel.mutable.ParArray[Int] = ParArray(0, 1, 2, 3, 4, 5, 6, 7,...
+
+内部的には、並列配列の[「スプリッタ」 (splitter)](architecture.html#id1) の分割は走査用の添字を更新した二つの新たなスプリッタを作る事に結局なる。
+[「コンバイナ」 (combiner)](architecture.html#id1) はより複雑だ。多くの変換メソッドの多く（例えば、`flatMap`、`filter`、`takeWhile` など）は、事前に結果の要素数（そのため、配列のサイズ）が分からないため、それぞれのコンバイナはならし定数時間 (amortized constant time) の
+ `+=` 演算を持つ配列バッファの変種だ。
+異なるプロセッサがそれぞれの並列配列コンバイナに要素を追加し、後で内部の配列を連結することで合成が行われる。
+要素の総数が分かった後になってから、内部の配列が割り当てられ、並列に書き込まれる。そのため、変換メソッドは読み込みメソッドに比べて少し高価だ。また、最後の配列の割り当ては JVM上で逐次的に実行されるため、map 演算そのものが非常に安価な場合は、配列の割り当てが逐次的ボトルネックとなりうる。
+
+`seq` メソッドを呼び出すことで並列配列はその順次版である `ArraySeq` に変換される。
+`ArraySeq` は元の並列配列の内部構造と同じ配列を内部で使うためこの変換は効率的だ。
+
+## 並列ベクトル
+
+並列ベクトル ([`ParVector`](http://www.scala-lang.org/api/{{ site.scala-version }}/scala/collection/parallel/immutable/ParVector.html))
+は、低い定数係数の対数時間で読み込みと書き込みを行う不変列だ。
+
+    scala> val pv = scala.collection.parallel.immutable.ParVector.tabulate(1000)(x => x)
+    pv: scala.collection.parallel.immutable.ParVector[Int] = ParVector(0, 1, 2, 3, 4, 5, 6, 7, 8, 9,...
+    
+    scala> pv filter (_ % 2 == 0)
+    res0: scala.collection.parallel.immutable.ParVector[Int] = ParVector(0, 2, 4, 6, 8, 10, 12, 14, 16, 18,...
+
+不変ベクトルは 32分木として表されるため、スプリッタはそれぞれのサブツリーをスプリッタに割り当てることで分割される。
+現行のコンバイナの実装はベクトルとして要素を保持し、遅延評価で要素をコピーすることで合成する。
+このため、変換メソッドは並列配列のそれに比べてスケーラビリティが低い。
+ベクトルの連結が将来の Scala リリースで提供されるようになれば、コンバイナは連結を用いて合成できるようになり、変換メソッドはより効率的になる。
+
+並列ベクトルは、順次[ベクトル](http://www.scala-lang.org/api/{{ site.scala-version }}/scala/collection/immutable/Vector.html)の並列版で、定数時間で一方から他方へと変換できる。
+
+## 並列範囲
+
+並列範囲 ([`ParRange`](http://www.scala-lang.org/api/{{ site.scala-version }}/scala/collection/parallel/immutable/ParRange.html)) 
+は、順序付けされた等間隔の要素の列だ。
+並列範囲は、逐次版の [Range](http://www.scala-lang.org/api/{{ site.scala-version }}/scala/collection/immutable/Range.html) と同様に作成される:
+
+    scala> 1 to 3 par
+    res0: scala.collection.parallel.immutable.ParRange = ParRange(1, 2, 3)
+    
+    scala> 15 to 5 by -2 par
+    res1: scala.collection.parallel.immutable.ParRange = ParRange(15, 13, 11, 9, 7, 5)
+
+順次範囲にビルダが無いのと同様に、並列範囲にはコンバイナが無い。
+並列範囲に対する `map` 演算は並列ベクトルを生成する。
+順次範囲と並列範囲は、一方から他方へと効率的に `seq` と `par` メソッドを用いて変換できる。
+
+## 並列ハッシュテーブル
+
+並列ハッシュテーブルは要素を内部の配列に格納し、各要素のハッシュコードにより格納する位置を決定する。
+並列可変ハッシュ集合 (
+[mutable.ParHashSet](http://www.scala-lang.org/api/{{ site.scala-version}}/scala/collection/parallel/mutable/ParHashSet.html)) 
+と並列可変ハッシュマップ ([mutable.ParHashMap](http://www.scala-lang.org/api/{{ site.scala-version }}/scala/collection/parallel/mutable/ParHashMap.html))
+はハッシュテーブルに基づいている。
+
+    scala> val phs = scala.collection.parallel.mutable.ParHashSet(1 until 2000: _*)
+    phs: scala.collection.parallel.mutable.ParHashSet[Int] = ParHashSet(18, 327, 736, 1045, 773, 1082,...
+    
+    scala> phs map (x => x * x)
+    res0: scala.collection.parallel.mutable.ParHashSet[Int] = ParHashSet(2181529, 2446096, 99225, 2585664,...
+
+並列ハッシュテーブルのコンバイナは、要素をハッシュコードの最初の文字に応じてバケットに振り分ける。
+これらは単にバケットを連結することで合成される。
+最終的なハッシュテーブルが構築されると（つまりコンバイナの `result` メソッドが呼ばれると）、
+内部の配列が割り当てられ、異なるバケットからハッシュテーブル配列の別々の連続したセグメントへ並列して要素が書き込まれる。
+
+順次ハッシュマップとハッシュ集合は `par` メソッドを用いて並列のものに変換できる。
+並列ハッシュテーブルは、その内部ではいくつかの区分に分けて要素を保持しているが、それぞれの要素数を管理するサイズマップを必要とする。
+そのため、順次ハッシュテーブルが並列テーブルに最初に変換されるときにはサイズマップが作成されなければいけない。
+ここで発生するテーブルの走査により最初の `par` の呼び出しはハッシュテーブルのサイズに対して線形の時間がかかる。
+それ以降のハッシュテーブルの変更はサイズマップの状態も更新するため、以降の `par` や `seq` を用いた変換は定数時間で実行される。
+サイズマップの更新は `useSizeMap` メソッドを用いることで開始したり、中止したりできる。
+重要なのは、順次ハッシュテーブルの変更は並列ハッシュテーブルにも影響があり、またその逆も真であることだ。
+
+## 並列ハッシュトライ
+
+並列ハッシュトライは、不変集合と不変マップを効率的に表す不変ハッシュトライの並列版だ。
+これらは、[immutable.ParHashSet](http://www.scala-lang.org/api/{{ site.scala-version }}/scala/collection/parallel/immutable/ParHashSet.html) クラスと
+[immutable.ParHashMap](http://www.scala-lang.org/api/{{ site.scala-version}}/scala/collection/parallel/immutable/ParHashMap.html) クラスにより提供される。
+
+    scala> val phs = scala.collection.parallel.immutable.ParHashSet(1 until 1000: _*)
+    phs: scala.collection.parallel.immutable.ParHashSet[Int] = ParSet(645, 892, 69, 809, 629, 365, 138, 760, 101, 479,...
+    
+    scala> phs map { x => x * x } sum
+    res0: Int = 332833500
+
+並列ハッシュテーブル同様に、並列ハッシュトライのコンバイナは事前に要素をバケットにソートしておき、それぞれのバケットを別のプロセッサに割り当て、それぞれがサブトライを構築することで、結果のハッシュトライを並列に構築する。
+
+並列ハッシュトライは `seq` と `par` メソッドを用いることで順次ハッシュトライと定数時間で相互に変換できる。
+
+## 並列並行トライ
+
+[concurrent.TrieMap](http://www.scala-lang.org/api/{{ site.scala-version }}/scala/collection/concurrent/TrieMap.html)
+は、複数のスレッドから同時にアクセスできる (concurrent thread-safe) マップだが、
+[mutable.ParTrieMap](http://www.scala-lang.org/api/{{ site.scala-version}}/scala/collection/parallel/mutable/ParTrieMap.html)
+は、その並列版だ。
+並列データ構造の多くは、走査時にデータ構造が変更された場合に一貫性のある走査を保証しないが、並行トライは更新が次回の走査まで見えないことを保証する。
+つまり以下の 1 から 99 の数の平方根を出力する例のように、並行トライを走査中に変更できるようになる:
+
+    scala> val numbers = scala.collection.parallel.mutable.ParTrieMap((1 until 100) zip (1 until 100): _*) map { case (k, v) => (k.toDouble, v.toDouble) }
+    numbers: scala.collection.parallel.mutable.ParTrieMap[Double,Double] = ParTrieMap(0.0 -> 0.0, 42.0 -> 42.0, 70.0 -> 70.0, 2.0 -> 2.0,...
+    
+    scala> while (numbers.nonEmpty) {
+         |   numbers foreach { case (num, sqrt) =>
+         |     val nsqrt = 0.5 * (sqrt + num / sqrt)
+         |     numbers(num) = nsqrt
+         |     if (math.abs(nsqrt - sqrt) < 0.01) { 
+         |       println(num, nsqrt)
+         |       numbers.remove(num)
+         |     }
+         |   }
+         | }
+    (1.0,1.0)
+    (2.0,1.4142156862745097)
+    (7.0,2.64576704419029)
+    (4.0,2.0000000929222947)
+    ...
+
+コンバイナは、内部的には `TrieMap` として実装されている。
+これは、並行なデータ構造であるため、変換メソッドの呼び出しに対して全体で一つのコンバイナのみが作成され、全てのプロセッサによって共有される。
+他の並列可変コレクションと同様に、`TrieMap` とその並列版である `ParTrieMap` は `seq` と `par` メソッドにより取得でき、これらは同じ内部構造にデータを格納してあるため一方で行われた変更は他方にも影響がある。変換は定数時間で行われる。
+
+## 性能特性
+
+列型の性能特性:
+
+|               | head   | tail     | apply  | 更新    | 先頭に<br>追加 | 最後に<br>追加 | 挿入 |
+| --------      | ------ | -------- | ------ | ------ | --------- | -------- | ---- |
+| `ParArray`    | 定数    | 線形     | 定数    | 定数    |  線形     | 線形      | 線形  |
+| `ParVector`   | 実質定数 | 実質定数 | 実質定数 | 実質定数 | 実質定数  | 実質定数   | -    |
+| `ParRange`    | 定数    | 定数     | 定数    | -       |  -       | -        | -    |
+
+集合とマップ型の性能特性:
+
+|                          | 検索    | 追加    | 削除    |
+| --------                 | ------ | ------- | ------ |
+| **不変**                  |        |         |        |
+| `ParHashSet`/`ParHashMap`| 実質定数 | 実質定数 | 実質定数 |
+| **可変**                  |        |         |        |
+| `ParHashSet`/`ParHashMap`| 定数    | 定数     | 定数    |
+| `ParTrieMap`             | 実質定数 | 実質定数 | 実質定数 |
diff --git a/ja/overviews/parallel-collections/configuration.md b/ja/overviews/parallel-collections/configuration.md
new file mode 100644
index 0000000000..7a3e25b8ff
--- /dev/null
+++ b/ja/overviews/parallel-collections/configuration.md
@@ -0,0 +1,67 @@
+---
+layout: overview-large
+title: 並列コレクションの設定
+
+disqus: true
+
+partof: parallel-collections
+num: 7
+language: ja
+---
+
+## タスクサポート
+
+並列コレクションは、演算のスケジューリングに関してモジュール化されている。
+全ての並列コレクションはタスクサポートというオブジェクトによりパラメータ化されており、これがタスクのスケジューリングとプロセッサへの負荷分散 (load balancing) を担当する。
+
+タスクサポートは内部にスレッドプールの実装への参照を持っており、タスクをより小さいタスクにいつどのように分割するかを決定している。
+この内部の振る舞いに関してより詳しく知りたい場合はこのテクノロジーレポートを参照してほしい \[[1][1]\]。
+
+現行の並列コレクションにはいくつかのタスクサポートの実装がある。
+JVM 1.6 以上でデフォルトで使われるのは、`ForkJoinTaskSupport` で、これは内部でフォーク/ジョインプールを使う。
+JVM 1.5 とその他のフォーク/ジョインプールをサポートしない JVM はより効率の劣る `ThreadPoolTaskSupport` を使う。
+また、`ExecutionContextTaskSupport` は `scala.conccurent` にあるデフォルトの実行コンテクスト (execution context) の実装を使い、`scala.concurrent` で使われるスレッドプールを再利用する（これは JVM のバージョンによってフォーク/ジョインプールか `ThreadPoolExecutor` が使われる）。それぞれの並列コレクションは、デフォルトで実行コンテクストのタスクサポートに設定されているため、並列コレクションは、Future API で使われるのと同じフォーク/ジョインプールが再利用されている。
+
+以下に並列コレクションのタスクサポートを変更する具体例をみてみよう:
+
+    scala> import scala.collection.parallel._
+    import scala.collection.parallel._
+    
+    scala> val pc = mutable.ParArray(1, 2, 3)
+    pc: scala.collection.parallel.mutable.ParArray[Int] = ParArray(1, 2, 3)
+    
+    scala> pc.tasksupport = new ForkJoinTaskSupport(new scala.concurrent.forkjoin.ForkJoinPool(2))
+    pc.tasksupport: scala.collection.parallel.TaskSupport = scala.collection.parallel.ForkJoinTaskSupport@4a5d484a
+    
+    scala> pc map { _ + 1 }
+    res0: scala.collection.parallel.mutable.ParArray[Int] = ParArray(2, 3, 4)
+
+上の例では、並列コレクションに対して並列度2のフォーク/ジョインプールを使うように設定した。
+並列コレクションを `ThreadPoolExecutor` を使うように設定する場合は:
+
+    scala> pc.tasksupport = new ThreadPoolTaskSupport()
+    pc.tasksupport: scala.collection.parallel.TaskSupport = scala.collection.parallel.ThreadPoolTaskSupport@1d914a39
+    
+    scala> pc map { _ + 1 }
+    res1: scala.collection.parallel.mutable.ParArray[Int] = ParArray(2, 3, 4)
+
+並列コレクションがシリアライズされるとき、タスクサポートフィールドはシリアライゼーションから省かれる。
+並列コレクションがデシリアライズされるとき、タスクサポートはデフォルトの値である実行コンテクストタスクサポートに設定される。
+
+カスタムのタスクサポートを実装するには、`TaskSupport` トレイトを拡張して以下のメソッドを実装する:
+
+    def execute[R, Tp](task: Task[R, Tp]): () => R
+    
+    def executeAndWaitResult[R, Tp](task: Task[R, Tp]): R
+    
+    def parallelismLevel: Int
+
+`execute` メソッドはタスクを非同期的にスケジューリングし、計算の結果をフューチャー値として返す。
+`executeAndWait` メソッドは同じことを行うがタスクが完了してから結果を返す。
+`parallelismLevel` はタスクサポートがタスクのスケジューリングをするのに用いる対象コア数を返す。
+
+## 参照
+
+1. [On a Generic Parallel Collection Framework, June 2011][1]
+
+  [1]: http://infoscience.epfl.ch/record/165523/files/techrep.pdf "parallel-collections"
diff --git a/ja/overviews/parallel-collections/conversions.md b/ja/overviews/parallel-collections/conversions.md
new file mode 100644
index 0000000000..e022357408
--- /dev/null
+++ b/ja/overviews/parallel-collections/conversions.md
@@ -0,0 +1,60 @@
+---
+layout: overview-large
+title: 並列コレクションへの変換
+
+disqus: true
+
+partof: parallel-collections
+num: 3
+language: ja
+---
+
+## 順次と並列コレクション間での変換
+
+全ての順次コレクションは、`par` メソッドを用いて何らかの並列コレクションへと変換できる。
+順次コレクションのいくつかには、直接対応する並列版を持つものがあり、それらのコレクションの変換は効率的だ。
+順次と並列コレクションが同じデータ構造で表現されているため変換は定数時間で実行される（唯一の例外は初回の `par` が少し高価である可変ハッシュマップと可変ハッシュ集合だが、二回目以降の `par` の呼び出しは定数時間で行われる）。
+また、可変コレクションに関しては、同じ内部構造を共有する場合、順次コレクションで行われた更新はそれに対応する並列版からも見えていることに注意して欲しい。
+
+| 順次           | 並列           |
+| ------------- | -------------- |
+| **可変**       |                |
+| `Array`       | `ParArray`     |
+| `HashMap`     | `ParHashMap`   |
+| `HashSet`     | `ParHashSet`   |
+| `TrieMap`     | `ParTrieMap`   |
+| **不変**       |                |
+| `Vector`      | `ParVector`    |
+| `Range`       | `ParRange`     |
+| `HashMap`     | `ParHashMap`   |
+| `HashSet`     | `ParHashSet`   |
+
+リスト、キュー、ストリーム等、その他のコレクションは、要素を順番にアクセスしなければいけないという意味で本質的に逐次的だ。それらのコレクションは、似ている並列コレクションに要素をコピーすることで、並列版に変換される。
+例えば、リストは標準の並列不変列である並列ベクトルに変換される。
+
+全ての並列コレクションは、`seq` メソッドを用いて何らかの順次コレクションに変換できる。
+並列コレクションから順次コレクションへの変換は常に効率的で、定数時間で実行される。
+並列可変コレクションに対して `seq` を呼び出すと、同じ内部構造にデータを格納した順次コレクションを返す。
+そのため、コレクションの変更は、他方にも見えることになる。 
+
+## 異なるコレクション型の間での変換
+
+順次と並列コレクション間での変換とは直交して、コレクションは別のコレクション型でも変換できる。
+例えば、`toSeq` を呼び出すことで順次集合を順次列に変換できるが、`toSeq` を呼び出して並列集合を並列列に変換することもできる。
+一般的なルールとしては、`X` に並列版があれば、`toX` メソッドは、そのコレクションを `ParX` コレクションに変換する。
+
+以下の表に全ての変換をまとめる:
+
+| メソッド         | 戻り値の型      |
+| -------------- | -------------- |
+| `toArray`      | `Array`        |
+| `toList`       | `List`         |
+| `toIndexedSeq` | `IndexedSeq`   |
+| `toStream`     | `Stream`       |
+| `toIterator`   | `Iterator`     |
+| `toBuffer`     | `Buffer`       |
+| `toTraversable`| `GenTraverable`|
+| `toIterable`   | `ParIterable`  |
+| `toSeq`        | `ParSeq`       |
+| `toSet`        | `ParSet`       |
+| `toMap`        | `ParMap`       |
diff --git a/ja/overviews/parallel-collections/ctries.md b/ja/overviews/parallel-collections/ctries.md
new file mode 100644
index 0000000000..ef11ea3648
--- /dev/null
+++ b/ja/overviews/parallel-collections/ctries.md
@@ -0,0 +1,143 @@
+---
+layout: overview-large
+title: 並行トライ
+
+disqus: true
+
+partof: parallel-collections
+num: 4
+language: ja
+---
+
+並列データ構造の多くは、走査時にデータ構造が変更された場合に一貫性のある走査を保証しない。
+これは、ほとんどの可変コレクションにも当てはまることだ。
+並行トライ (concurrent trie) は、走査中に自身の更新を許すという意味で特殊なものだと言える。
+変更は、次回以降の走査のみで見えるようになる。
+これは、順次並行トライと並列並行トライの両方に当てはまることだ。
+唯一の違いは、前者は要素を逐次的に走査するのに対して、後者は並列に走査するということだけだ。
+
+この便利な特性を活かして簡単に書くことができるアルゴリズムがいくつかある。
+これらのアルゴリズムは、 要素のデータセットを反復処理するが、要素によって異なる回数繰り返す必要のあるアルゴリズムであることが多い。
+
+与えられた数の集合の平方根を計算する例を以下に示す。
+繰り返すたびに平方根の値が更新される。
+平方根の値が収束すると、その数は集合から外される。
+
+    case class Entry(num: Double) {
+      var sqrt = num
+    }
+    
+    val length = 50000
+    
+    // リストを準備する
+    val entries = (1 until length) map { num => Entry(num.toDouble) }
+    val results = ParTrieMap()
+    for (e <- entries) results += ((e.num, e))
+    
+    // 平方根を計算する
+    while (results.nonEmpty) {
+      for ((num, e) <- results) {
+        val nsqrt = 0.5 * (e.sqrt + e.num / e.sqrt)
+        if (math.abs(nsqrt - e.sqrt) < 0.01) {
+          results.remove(num)
+        } else e.sqrt = nsqrt
+      }
+    }
+
+上のバビロニア法による平方根の計算 (\[[3][3]\]) は、数によっては他よりも早く収束することに注意してほしい。
+そのため、それらの数を `result` から削除して処理が必要な要素だけが走査されるようにする必要がある。
+
+もう一つの例としては、幅優先探索 (breadth-first search) アルゴリズムがある。
+これは、対象となるノードが見つかるか他に見るノードが無くなるまで反復的に前線ノードを広げていく。
+ここでは、二次元の地図上のノードを `Int` のタプルとして定義する。
+`map` はブーリアン型の二次元配列として定義し、これはその位置が占有されているかを示す。
+次に、今後拡張予定の全てのノード（ノード前線）を含む `open` と、拡張済みの全てのノードを含む `closed` という二つの平行トライマップを宣言する。
+地図の四隅から探索を始めて、地図の中心までの経路を見つけたいため、`open` マップを適切なノードに初期化する。
+次に、`open` マップ内の全てのノードを拡張するノードが無くなるまで反復的に拡張する。
+ノードが拡張されるたびに、`open` マップから削除され、`closed` マップに追加される。
+完了したら、対象ノードから初期ノードまでの経路を表示する。
+
+    val length = 1000
+    
+    // Node 型を定義する
+    type Node = (Int, Int);
+    type Parent = (Int, Int);
+    
+    // Node 型の演算
+    def up(n: Node) = (n._1, n._2 - 1);
+    def down(n: Node) = (n._1, n._2 + 1);
+    def left(n: Node) = (n._1 - 1, n._2);
+    def right(n: Node) = (n._1 + 1, n._2);
+    
+    // map と target を作る
+    val target = (length / 2, length / 2);
+    val map = Array.tabulate(length, length)((x, y) => (x % 3) != 0 || (y % 3) != 0 || (x, y) == target)
+    def onMap(n: Node) = n._1 >= 0 && n._1 < length && n._2 >= 0 && n._2 < length
+    
+    // open マップ - ノード前線
+    // closed マップ - 滞在済みのノード
+    val open = ParTrieMap[Node, Parent]()
+    val closed = ParTrieMap[Node, Parent]()
+    
+    // 初期位置をいくつか追加する
+    open((0, 0)) = null
+    open((length - 1, length - 1)) = null
+    open((0, length - 1)) = null
+    open((length - 1, 0)) = null
+    
+    // 貪欲法による幅優先探索
+    while (open.nonEmpty && !open.contains(target)) {
+      for ((node, parent) <- open) {
+        def expand(next: Node) {
+          if (onMap(next) && map(next._1)(next._2) && !closed.contains(next) && !open.contains(next)) {
+            open(next) = node
+          }
+        }
+        expand(up(node))
+        expand(down(node))
+        expand(left(node))
+        expand(right(node))
+        closed(node) = parent
+        open.remove(node)
+      }
+    }
+    
+    // 経路の表示
+    var pathnode = open(target)
+    while (closed.contains(pathnode)) {
+      print(pathnode + "->")
+      pathnode = closed(pathnode)
+    }
+    println()
+
+並行トライはまた、逐次化可能 (linearlizable) 、ロックフリー (lock-free)、かつ計算量が定数時間の `snapshot` 演算をサポートする。
+この演算は、ある特定の時点における全ての要素を含んだ新たな並列トライを作成する。
+これは、実質的にはそのトライのその時点での状態を捕捉したことと変わらない。
+`snapshot` 演算は、並列トライの新しいルートを作成するだけだ。
+後続の更新は並列トライのうち更新に関わる部分だけを遅延評価で再構築し他の部分には手を付けない。
+まず、これはスナップショット演算に要素のコピーを伴わないため、演算が高価ではないということだ。
+次に、コピーオンライト (copy-on-write) の最適化は平行トライの一部だけをコピーするため、後続の更新は水平にスケールする。
+`readOnlySnapshot` メソッドは、`snapshot` メソッドよりも少しだけ効率が良いが、更新のできないリードオンリーなマップを返す。
+このスナップショット機構を用いて、並行トライは逐次化可能で計算量が定数時間の、`clear` メソッドも提供する。
+並行トライとスナップショットの仕組みに関してさらに知りたい場合は、\[[1][1]\] と \[[2][2]\] を参照してほしい。
+
+並行トライのイテレータはスナップショットに基づいている。
+イテレータオブジェクトが作成される前に並行トライのスナップショットが取られるため、イテレータはスナップショットが作成された時点での要素のみを走査する。
+当然、イテレータはリードオンリーなスナップショットを用いる。
+
+`size` 演算もスナップショットに基づいている。
+率直に実装すると、`size` を呼び出した時点でイテレータ（つまり、スナップショット）が作り、全ての要素を走査しながら数えていくというふうになる。
+そのため、`size` を呼び出すたびに要素数に対して線形の時間を要することになる。
+しかし、並行トライは異なる部分のサイズをキャッシュするように最適化されているため、`size` の計算量はならし対数時間まで減少している。
+実質的には、一度 `size` を呼び出すと二回目以降の `size` の呼び出しは、典型的には最後に `size` が呼ばれた時点より更新された枝のサイズのみを再計算するというように、最小限の仕事のみを要するようになる。
+さらに、並列並行トライのサイズ計算は並列的に実行される。
+
+## 参照
+
+1. [Cache-Aware Lock-Free Concurrent Hash Tries][1]
+2. [Concurrent Tries with Efficient Non-Blocking Snapshots][2]
+3. [Methods of computing square roots][3]
+
+  [1]: http://infoscience.epfl.ch/record/166908/files/ctries-techreport.pdf "Ctries-techreport"
+  [2]: http://lampwww.epfl.ch/~prokopec/ctries-snapshot.pdf "Ctries-snapshot"
+  [3]: http://en.wikipedia.org/wiki/Methods_of_computing_square_roots#Babylonian_method "babylonian-method"
diff --git a/ja/overviews/parallel-collections/custom-parallel-collections.md b/ja/overviews/parallel-collections/custom-parallel-collections.md
new file mode 100644
index 0000000000..433a0a16bc
--- /dev/null
+++ b/ja/overviews/parallel-collections/custom-parallel-collections.md
@@ -0,0 +1,247 @@
+---
+layout: overview-large
+title: カスタム並列コレクションの作成
+
+disqus: true
+
+partof: parallel-collections
+num: 6
+language: ja
+---
+
+## コンバイナを持たない並列コレクション
+
+ビルダ無しでもカスタム順次コレクションを定義できるように、コンバイナ無しで並列コレクションを定義することが可能だ。
+コンバイナを持たなければ、（例えば `map`、`flatMap`、`collect`、`filter`、などの）変換メソッドはデフォルトでは、継承関係で一番近い標準コレクションの型を返すことになる。
+例えば、範囲はビルダを持たないため、その要素を写像 (`map`) するとベクトルが作られる。
+
+以下に具体例として、並列の文字列コレクションを定義する。
+文字列は論理的には不変列なので、並列文字列は `immutable.ParSeq[Char]` を継承することにする:
+
+    class ParString(val str: String)
+    extends immutable.ParSeq[Char] {
+
+次に、全ての不変列にあるメソッドを定義する:
+
+      def apply(i: Int) = str.charAt(i)
+      
+      def length = str.length
+
+この並列コレクションの直列版も定義しなければならない。
+ここでは `WrappedString` クラスを返す:
+
+      def seq = new collection.immutable.WrappedString(str)
+
+最後に、この並列文字列コレクションのスプリッタを定義しなければならない。
+このスプリッタは `ParStringSplitter` と名づけ、列スプリッタの `SeqSplitter[Char]` を継承することにする:
+
+      def splitter = new ParStringSplitter(str, 0, str.length)
+      
+      class ParStringSplitter(private var s: String, private var i: Int, private val ntl: Int)
+      extends SeqSplitter[Char] {
+
+        final def hasNext = i < ntl
+		
+        final def next = {
+          val r = s.charAt(i)
+          i += 1
+          r
+        }
+
+上のコードでは、`ntl` は文字列の長さの合計、`i` は現在の位置、`s` は文字列自身を表す。
+
+並列コレクションのイテレータ（別名スプリッタ）は、順次コレクションのイテレータにある `next` と `hasNext` の他にもいくつかのメソッドを必要とする。
+第一に、スプリッタがまだ走査していない要素の数を返す `remaining` というメソッドがある。
+次に、現在のスプリッタを複製する `dup` というメソッドがある。
+
+        def remaining = ntl - i
+        
+        def dup = new ParStringSplitter(s, i, ntl)
+
+最後に、現在のスプリッタの要素の部分集合を走査する別のスプリッタを作成するのに使われる `split` と `psplit` メソッドがある。
+`split` メソッドは、現在のスプリッタが操作する要素の、交わらなく (disjoint) 、空でもない、部分集合の列を返すことを約束する。
+現在のスプリッタが一つ以下の要素を持つ場合、`split` は自分自身だけが入った列を返す。
+`psplit` メソッドは、`sizes` パラメータが指定する数どおりの要素を走査するスプリッタの列を返す。
+もし `sizes` パラメータが現在のスプリッタよりも少ない要素を指定した場合は、残りの要素は追加のスプリッタに入れられ、それは列の最後に追加される。もし `sizes` パラメータが今ある要素よりも多くの要素を必要とした場合は、それぞれのサイズに空のスプリッタを追加して補う。
+また、`split` か `psplit` のどちらかを呼び出しても現在のスプリッタを無効化する。
+
+        def split = {
+          val rem = remaining
+          if (rem >= 2) psplit(rem / 2, rem - rem / 2)
+          else Seq(this)
+        }
+        
+        def psplit(sizes: Int*): Seq[ParStringSplitter] = {
+          val splitted = new ArrayBuffer[ParStringSplitter]
+          for (sz <- sizes) {
+            val next = (i + sz) min ntl
+            splitted += new ParStringSplitter(s, i, next)
+            i = next
+          }
+          if (remaining > 0) splitted += new ParStringSplitter(s, i, ntl)
+          splitted
+        }
+      }
+    }
+
+上のコードでは、`split` は `psplit` に基づいて実装されているが、これは並列の列ではよくあることだ。
+並列マップ、集合、`Iterable` のスプリッタを実装する方が `psplit` を必要としないため簡単であることが多い。
+
+これで、並列文字列クラスができた。唯一の短所は `filter` のような変換メソッドを呼び出すと並列文字列の代わりに並列ベクトルが返ってくる点だ。
+フィルタをかけた後でベクトルから文字列を再び生成するのは高価であるかもしれず、これは望ましいとは言えない。
+
+## コンバイナを持つ並列コレクション
+
+例えばコンマを除外するなどして、並列文字列内の文字を `filter` したいとする。
+前述のとおり、`filter` の呼び出しは並列ベクトルを返すが、（API のインターフェイスによっては並列文字列が必要なため）どうしても並列文字列が欲しい。
+
+これを回避するには並列文字列コレクションのコンバイナを書かなくてはならない。
+今度は `ParSeq[Char]` の代わりに `ParSeqLike` を継承することで `filter` の戻り値の型がより特定のものであることを保証する（`ParSeq[Char]` ではなく、`ParString` を返す）。
+（二つの型パラメータを取る順次 `*Like` トレイト群とは異なり）`ParSeqLike` は第三の型パラメータを取り、これは並列コレクションに対応する順次版の型を指定する。
+
+    class ParString(val str: String)
+    extends immutable.ParSeq[Char]
+       with ParSeqLike[Char, ParString, collection.immutable.WrappedString]
+
+前に定義したメソッドはそのまま使えるが、`filter` の内部で使われる protected なメソッドである `newCombiner` を追加する。
+
+      protected[this] override def newCombiner: Combiner[Char, ParString] = new ParStringCombiner
+
+次に `ParStringCombiner` クラスを実装する。
+コンバイナは ビルダのサブタイプだが `combine` というメソッドを導入する。
+`combine` メソッドは、別のコンバイナを引数に取り現在のコンバイナと引数のコンバイナの両方の要素を含んだ新しいコンバイナを返す。
+`combine` を呼び出すと、現在のコンバイナと引数のコンバイナは無効化される。
+もし引数が現在のコンバイナと同じオブジェクトである場合は、`combine` は現在のコンバイナを返す。
+このメソッドは並列計算の中で複数回呼び出されるので、最悪でも要素数に対して対数時間で実行するなど、効率的であることが期待されている。
+
+`ParStringCombiner` は内部に `StringBuilder` の列を管理することにする。
+これで列の最後の `StringBuilder` に要素を追加することで `+=` を実装し、現在のコンバイナと引数のコンバイナの `StringBuilder` のリストを連結することで `combine` を実装できるようになる。
+並列計算の最後に呼び出される `result` メソッドは、全ての `StringBuilder` を追加することで並列文字列を生成する。
+これにより、要素のコピーは、毎回 `combine` を呼ぶたびに行われるのではなく、最後に一度だけ行われる。
+理想的には、この処理を並列化してコピーも並列に実行したい（並列配列ではそうなっている）が、文字列の内部表現にまで踏み込まない限りはこれが限界だ。そのため、この逐次的ボトルネックを受け入れなければいけない。
+
+    private class ParStringCombiner extends Combiner[Char, ParString] {
+      var sz = 0
+      val chunks = new ArrayBuffer[StringBuilder] += new StringBuilder
+      var lastc = chunks.last
+      
+      def size: Int = sz
+      
+      def +=(elem: Char): this.type = {
+        lastc += elem
+        sz += 1
+        this
+      }
+      
+      def clear = {
+        chunks.clear
+        chunks += new StringBuilder
+        lastc = chunks.last
+        sz = 0
+      }
+      
+      def result: ParString = {
+        val rsb = new StringBuilder
+        for (sb <- chunks) rsb.append(sb)
+        new ParString(rsb.toString)
+      }
+      
+      def combine[U <: Char, NewTo >: ParString](other: Combiner[U, NewTo]) = if (other eq this) this else {
+        val that = other.asInstanceOf[ParStringCombiner]
+        sz += that.sz
+        chunks ++= that.chunks
+        lastc = chunks.last
+        this
+      }
+    }
+
+
+## どうやってコンバイナを実装すればいい？
+
+これには定義済みのレシピは無い。
+扱っているデータ構造に依存するし、実装者による創意工夫が必要なことも多い。
+しかし、通常用いられれるいくつかの方法がある:
+
+<ol>
+<li>連結とマージ。
+これらの演算に対して効率的な（通常、対数時間の）実装を持つデータ構造がある。
+もし、扱っているコレクションがそのようなデータ構造を用いてるならば、コレクションそのものをコンバイナとして使える。
+フィンガーツリー、ロープ、そしてヒープの多くが特にこの方法に向いている。</li>
+<li>二段階評価。
+並列配列と並列ハッシュテーブルで用いられてる方法で、要素が効率良く連結可能なバケットに部分ソート可能で、バケットから最終的なデータ構造が並列に構築可能なことを前提とする。
+まず、第一段階では別々のプロセッサが独立して要素をバケットに書き込んでいき、最後にバケットが連結される。
+第二段階では、データ構造が割り当てられ、別々のプロセッサがそれぞれデータ構造の異なる部分に交わらないバケットから要素を書き込んでいく。
+異なるプロセッサが絶対にデータ構造の同じ部分を変更しないように注意しないと、微妙な並行エラーが発生する可能性がある。
+前の節で示したように、この方法はランダムアクセス可能な列にも応用できる。</li>
+<li>並行データ構造 (concurrent data structure)。
+上の二つの方法はデータ構造そのものには同期機構を必要としないが、二つの異なるプロセッサが絶対に同じメモリの位置を更新しないような方法で並行して構築可能であることを前提とする。
+並行スキップリスト、並行ハッシュテーブル、split-ordered list、並行AVLツリーなど、複数のプロセッサから安全に更新することが可能な並行データ構造が数多く存在する。
+考慮すべき重要な点は、並行データ構造は水平にスケーラブルな挿入方法を持っていることだ。
+並行な並列コレクションは、コンバイナはコレクション自身であることが可能で、単一のコンバイナのインスタンスを並列演算を実行する全てのプロセッサによって共有できる。</li>
+</ol>
+
+## コレクションフレームワークとの統合
+
+`ParString` はまだ完成していない。
+`filter`、`partition`、`takeWhile`、や `span` などのメソッドで使われるカスタムのコンバイナを実装したが、ほとんどの変換メソッドは暗黙の `CanBuildFrom` のエビデンスを必要とする（完全な説明に関しては、Scala コレクションのガイドを参照）。
+これを提供して `ParString` をコレクションフレームワークの一部として完全に統合するには、`GenericParTemplate` というもう一つのトレイトをミックスインして `ParString` のコンパニオンオブジェクトを定義する必要がある。
+
+    class ParString(val str: String)
+    extends immutable.ParSeq[Char]
+       with GenericParTemplate[Char, ParString]
+       with ParSeqLike[Char, ParString, collection.immutable.WrappedString] {
+      
+      def companion = ParString
+
+コンパニオンオブジェクトの中で `CanBuildFrom` パラメータのための暗黙の値を提供する。
+
+    object ParString {
+      implicit def canBuildFrom: CanCombineFrom[ParString, Char, ParString] =
+        new CanCombinerFrom[ParString, Char, ParString] {
+          def apply(from: ParString) = newCombiner
+          def apply() = newCombiner
+        }
+        
+      def newBuilder: Combiner[Char, ParString] = newCombiner
+      
+      def newCombiner: Combiner[Char, ParString] = new ParStringCombiner
+      
+      def apply(elems: Char*): ParString = {
+        val cb = newCombiner
+        cb ++= elems
+        cb.result
+      }
+    }
+
+## 更なるカスタム化 -- 並行とその他のコレクション
+
+並行コレクションの実装は一筋縄ではいかない（並列コレクションと違って、並行コレクションは `collection.concurrent.TriMap` のように並行して更新可能なもの）。
+コンバイナは特に頭をひねるところだ。
+これまで見てきた多くの**並列** (parallel) コレクションでは、コンバイナは二段階評価を行った。
+第一段階では、異なるプロセッサによって要素はコンバイナに加えられ、コンバイナは一つに組み合わされる。
+第二段階で、全ての要素がそろった時点で結果のコレクションが構築される。
+
+コンバイナのもう一つの方法としては、結果と成るコレクションを要素を使って構築してしまう方法がある。
+これは、そのコレクションがスレッドセーフであることを必要とし、コンバイナは**並行** (concurrent) な要素の挿入を可能とする必要がある。
+この場合、単一のコンバイナが全てのプロセッサにより共有される。
+
+並行コレクションを並列化するには、コンバイナは `canBeShared` メソッドをオーバーライドして `true` を返す必要がある。
+これで並列演算が呼び出される時に単一のコンバイナのみが作成されることが保証される。
+次に `+=` メソッドがスレッドセーフである必要がある。
+最後に `combine` メソッドは現在のコンバイナと引数のコンバイナが同一である場合は現在のコンバイナを返す必要があるが、それ以外の場合は例外を投げてもいい。
+
+スプリッタは負荷分散のために小さいスプリッタへと分割される。
+デフォルトでは、`remaining` メソッドで得られる情報によってスプリッタの分割をいつ止めるか決定する。
+コレクションによっては `remaining` の呼び出しは高価で、スプリッタの分割を決定するのに他の方法を使ったほうが望ましい場合もある。
+その場合は、スプリッタの `shouldSplitFurther` メソッドをオーバーライドする。
+
+デフォルトの実装では、残りの要素数がコレクションのサイズを並列度の8倍で割った数より多い場合に分割される。
+
+    def shouldSplitFurther[S](coll: ParIterable[S], parallelismLevel: Int) =
+      remaining > thresholdFromSize(coll.size, parallelismLevel)
+
+同値の実装として、スプリッタに何回分割されたかを格納するカウンタを持たせ、分割回数が `3 + log(parallelismLevel)` よりも多い場合だけ `shouldSplitFurther` が `true` を返すようにできるが、これは `remaining` の呼び出しを回避する。
+
+さらに、ある特定のコレクションに対して `remaining` を呼び出すのが安価な演算ではない場合（つまり、コレクション内の要素数を求めなければいけない場合）、スプリッタの `isRemainingCheap` メソッドをオーバーライドして `false` を返すべきだ。
+
+最後に、スプリッタの `remaining` メソッドの実装が非常に厄介な場合は、コレクションの `isStrictSplitterCollection` メソッドをオーバーライドして `false` を返すことができる。そのようなコレクションは、スプリッタが厳格である（つまり、`remaining` メソッドが正しい値を返す）ことが必要であるメソッドが失敗するようになる。大切なのは、これは for-展開で使われるメソッドには影響しないことだ。
diff --git a/ja/overviews/parallel-collections/overview.md b/ja/overviews/parallel-collections/overview.md
new file mode 100644
index 0000000000..d55034af95
--- /dev/null
+++ b/ja/overviews/parallel-collections/overview.md
@@ -0,0 +1,167 @@
+---
+layout: overview-large
+title: 概要
+
+disqus: true
+
+partof: parallel-collections
+num: 1
+language: ja
+---
+
+**Aleksandar Prokopec, Heather Miller 著**<br>
+**Eugene Yokota 訳**
+
+## 動機
+
+近年におけるプロセッサ製造業者のシングルコアからマルチコアへの移行のまっただ中で、産学ともに認めざるをえないのは「大衆的並列プログラミング」が大きな難題であり続けていることだ。
+
+並列コレクション (parallel collection) は、並列プログラミングを容易にすることを目指して Scala 標準ライブラリに取り込まれた。
+ユーザは低レベルな並列化に関する詳細を気にせず、親しみやすいコレクションという高レベルの抽象概念 (abstraction) を利用できる。
+この概念が隠蔽する並列性によって、信頼性のある並列実行が開発者にとってより身近なものになると願っている。
+
+アイディアは簡単だ -- コレクションはよく理解されており、よく使われているプログラミングの抽象概念だ。
+さらに、その規則性により、コレクションは効率良く、ユーザが意識すること無く、並列化することができる。
+ユーザが順次コレクション (sequential collection) を並列に計算するものに「置き換える」ことを可能にすることで、Scala の並列コレクションは、より多くのコードに並列性をもたらす方向に大きな一歩を踏み出したと言える。
+
+例えば、大きなコレクションに対してモナディックな演算を行なっている逐次的 (sequential) な例をみてほしい:
+
+    val list = (1 to 10000).toList
+    list.map(_ + 42)
+    
+同じ演算を並列に実行するには、単に順次コレクションである `list` に対して `par` メソッドを呼び出すだけでいい。後は、順次コレクションを普通に使うのと同じように並列コレクションを利用できる。上記の例は以下のように並列化できる:
+
+    list.par.map(_ + 42)
+
+Scala の並列コレクションの設計は、2.8 で導入された Scala の（順次）コレクションライブラリに影響を受けており、またその一部となるように深く統合されている。
+Scala の（順次）コレクションライブラリの重要なデータ構造の多くに対して対応する並列のコレクションを提供する:
+
+* `ParArray`
+* `ParVector`
+* `mutable.ParHashMap`
+* `mutable.ParHashSet`
+* `immutable.ParHashMap`
+* `immutable.ParHashSet`
+* `ParRange`
+* `ParTrieMap` (`collection.concurrent.TrieMap` は 2.10 より追加された)
+
+Scala の並列コレクションライブラリは、順次ライブラリコレクションと共通のアーキテクチャを持つだけでなく、その**拡張性**も共有している。
+つまり、普通の順次コレクションと同様に、ユーザは独自のコレクション型を統合して、標準ライブラリにある他の並列コレクションにあるものと同じ（並列の）演算を自動的に継承できる。
+
+## 例をいくつか
+
+並列コレクションの一般性と利便性を例示するために、いくつかの簡単な具体例を用いて説明しよう。全ての例において、ユーザが意識すること無く演算は並列に実行されている。
+
+**注意:** 以下の例ではサイズの小さいコレクションを並列化しているが、これはあくまで説明のための例で、実用では推奨されない。
+一般的な指標として、コレクションのサイズが数千要素など、サイズが大きいほど並列化による高速化が顕著であることが多い。（並列コレクションのサイズと性能に関する詳細に関しては、このガイドの[性能](performance.html)に関する節の[該当する項](performance.html#id18)を参照してほしい）
+
+#### map
+
+並列 `map` を使って `String` のコレクションを大文字に変換する:
+
+    scala> val lastNames = List("Smith","Jones","Frankenstein","Bach","Jackson","Rodin").par
+    lastNames: scala.collection.parallel.immutable.ParSeq[String] = ParVector(Smith, Jones, Frankenstein, Bach, Jackson, Rodin)
+    
+    scala> lastNames.map(_.toUpperCase)
+    res0: scala.collection.parallel.immutable.ParSeq[String] = ParVector(SMITH, JONES, FRANKENSTEIN, BACH, JACKSON, RODIN)
+
+#### fold
+
+`ParArray` の `fold` を使った合計:
+
+    scala> val parArray = (1 to 1000000).toArray.par    
+    parArray: scala.collection.parallel.mutable.ParArray[Int] = ParArray(1, 2, 3, ...
+    
+    scala> parArray.fold(0)(_ + _)
+    res0: Int = 1784293664
+
+#### filter
+
+並列 `filter` を使ってラストネームがアルファベットの "J" 以降のから始まるものを選択する:
+
+    scala> val lastNames = List("Smith","Jones","Frankenstein","Bach","Jackson","Rodin").par
+    lastNames: scala.collection.parallel.immutable.ParSeq[String] = ParVector(Smith, Jones, Frankenstein, Bach, Jackson, Rodin)
+    
+    scala> lastNames.filter(_.head >= 'J')
+    res0: scala.collection.parallel.immutable.ParSeq[String] = ParVector(Smith, Jones, Jackson, Rodin)
+
+## 並列コレクションの意味論
+
+並列コレクションのインターフェイスは普通の順次コレクションと同じ感覚で使うことができるが、特に副作用を伴う演算と結合則が成立しない演算においては、演算の意味するものが異なることに注意する必要がある。
+
+これを理解するためには、まず、演算が**どのように**並列実行されているのかをイメージする必要がある。
+概念的には、Scala の並列コレクションフレームワークは、ある並列コレクションにおける演算を並列化するために、再帰的にコレクションを「分割」(split) し、並列にそれぞれの部分に演算を適用し、並列に完了した全ての結果を再び「合成」(combine) することで行う。
+
+このような並列コレクションの並行 (concurrent) で、「アウト・オブ・オーダー」("out-of-order"、訳注: 記述された順序以外で演算が実行されること) な意味論から以下の二つの結果が導き出される:
+
+1. **副作用を伴う演算は非決定性につながる可能性がある**
+
+2. **結合則が成立しない演算は非決定性につながる可能性がある**
+
+### 副作用を伴う演算
+
+並列コレクションフレームワークの**並行**実行の意味論を考慮すると、計算の決定性 (determinism) を維持するためには、コレクションに対して副作用 (side-effect) を伴う演算は一般的に避けるべきだ。具体例としては、`foreach` のようなアクセスメソッドを用いる場合に、渡されるクロージャ中から外の `var` を増加することが挙げられる。
+
+    scala> var sum = 0
+    sum: Int = 0
+
+    scala> val list = (1 to 1000).toList.par
+    list: scala.collection.parallel.immutable.ParSeq[Int] = ParVector(1, 2, 3,…
+    
+    scala> list.foreach(sum += _); sum
+    res01: Int = 467766
+    
+    scala> var sum = 0
+    sum: Int = 0
+    
+    scala> list.foreach(sum += _); sum
+    res02: Int = 457073    
+    
+    scala> var sum = 0
+    sum: Int = 0
+    
+    scala> list.foreach(sum += _); sum
+    res03: Int = 468520    
+    
+ここでは、`sum` が 0 に初期化されて、`list` に対して `foreach` が呼び出されるたびに `sum` が異なる値を持っていることが分かる。この非決定性の原因は**データ競合** (data race; 同一の可変変数に対する並行した読み書き) だ。
+
+上の例だと、二つのスレッドが `sum` の**同じ**値を読み込んで、その `sum` の値に対して何らかの演算を実行した後で、`sum` に新しい値を書きこもうとするかもしれない。以下に示すように、その場合は、大切な結果の上書き（つまり、損失）が起きる可能性がある:
+
+    ThreadA: sum の値を読み込む、sum = 0                sum の値: 0
+    ThreadB: sum の値を読み込む、sum = 0                sum の値: 0
+    ThreadA: sum を 760 増加する、sum = 760 を書き込む   sum の値: 760
+    ThreadB: sum を 12 増加する、sum = 12 を書き込む     sum の値: 12
+
+上の例は、どちらか一方のスレッドが `0` に各自の並列コレクションの担当部分からの要素を加算する前に、二つのスレッドが同じ値 `0` を読み込むシナリオを示している。この場合、`ThreadA` は `0` を読み込み、`0+760` を合計し、`ThreadB` も `0` に自分の要素を加算し、`0+12` となった。各自の合計を計算した後、それぞれが経験結果を `sum` に書き込む。`ThreadA` が `ThreadB` よりも先に書き込むが、直後に `ThreadB` がそれを上書きするため、実質 `760` という値が上書きされ、失われることになった。
+
+### 結合則が成立しない演算
+
+**「アウト・オブ・オーダー」**実行の意味論を考慮すると、非決定性を避けるためには、慎重に、結合則が成立する演算のみを実行するべきだ。つまり、並列コレクション `pcoll` に対して `pcoll.reduce(func)` のように高階関数を呼び出すとき、`func` が要素に適用される順序が任意でも大丈夫であるように気をつけるべきだということだ。単純で、かつ明快な結合則が成立しない演算の例は減算だ:
+
+    scala> val list = (1 to 1000).toList.par
+    list: scala.collection.parallel.immutable.ParSeq[Int] = ParVector(1, 2, 3,…
+    
+    scala> list.reduce(_-_)
+    res01: Int = -228888
+    
+    scala> list.reduce(_-_)
+    res02: Int = -61000
+    
+    scala> list.reduce(_-_)
+    res03: Int = -331818
+    
+上の例では、`ParVector[Int]` の `reduce` メソッドが `_-_` と共に呼び出されている。
+これは二つの不特定の要素を取り出し、前者から後者を引く。
+並列コレクションフレームワークはスレッドを呼び出し、それぞれが実質的に、独自にコレクションから異なる部位を取り出し `reduce(_-_)` を実行するため、同じコレクションに `reduce(_-_)` を実行するたびに毎回異なった結果が得られることとなる。
+
+**注意:** 結合則が成立しない演算と同様に、交換則が成立しない演算も並列コレクションの高階関数に渡されると非決定的な振る舞いをみせると思われがちだが、それは間違っている。単純な例としては、文字列の連結がある。結合則は成立するが、交換則は成立しない演算だ:
+
+    scala> val strings = List("abc","def","ghi","jk","lmnop","qrs","tuv","wx","yz").par
+    strings: scala.collection.parallel.immutable.ParSeq[java.lang.String] = ParVector(abc, def, ghi, jk, lmnop, qrs, tuv, wx, yz) 
+    
+    scala> val alphabet = strings.reduce(_++_)
+    alphabet: java.lang.String = abcdefghijklmnopqrstuvwxyz
+
+並列コレクションにおける**「アウト・オブ・オーダー」**の意味論は、演算が（**時間的**な意味で、つまり非逐次的に）バラバラの順序で実行されるという意味であって、結果が（**空間的**に）バラバラに**「再合成」**されるという意味ではない。結果は、一般的に**順序どおり** (in-order) に再合成される。つまり、A、B、C の順番に分割された並列コレクションは、再び A、B、C の順番に再合成される。任意の B、C、A というような順序にはならない。
+
+異なる並列コレクションの型における、分割と再合成の詳細ついてはこのガイドの[アーキテクチャ](architecture.html)の節を参照してほしい。 
diff --git a/ja/overviews/parallel-collections/performance.md b/ja/overviews/parallel-collections/performance.md
new file mode 100644
index 0000000000..3efd9336d4
--- /dev/null
+++ b/ja/overviews/parallel-collections/performance.md
@@ -0,0 +1,227 @@
+---
+layout: overview-large
+title: 性能の測定
+
+disqus: true
+
+partof: parallel-collections
+num: 8
+outof: 8
+language: ja
+---
+
+## JVM における性能
+
+JVM における性能モデルは論評こそは色々あるが、それに巻き込まれて結局よく理解されてないと言える。
+様々な理由から、あるコードは期待されているよりも性能が悪かったり、スケーラブルではなかったりする。
+以下にいくつかの理由をみていく。
+
+一つは JVM 上のアプリケーションのコンパイル工程が静的にコンパイルされた言語のそれとは同じではないということが挙げられる（\[[2][2]\] 参照）。
+Java と Scala のコンパイラはソースコードを JVM バイトコードに変換するだけで、最適化はほとんど行わない。
+現代的な JVM の多くではプログラムのバイトコードが実行されると、それは実行しているマシンのコンピュータアーキテクチャのマシンコードに変換する。
+これはジャストインタイムコンパイラ (just-in-time compiler、JITコンパイラ) と呼ばれる。
+しかし、JITコンパイラは速度を優先するため、最適化のレベルは低いといえる。
+再コンパイルを避けるため、いわゆる HotSpot コンパイラは頻繁に実行される部分だけを最適化する。
+これがベンチマーク作者へ及ぼす影響は、プログラムを実行するたびにそれらが異なる性能を持つことだ。
+（例えば、ある特定のメソッドのような）同じコードを同じ JVM インスタンス上で複数回実行したとしても、そのコードが間に最適化された場合は全く異なる性能を示す可能性がある。
+さらに、コードのある部分の実行時間を測定することは JITコンパイラが最適化を実行している時間を含む可能性があり、一貫性に欠ける結果となることもある。
+
+JVM において隠れて実行されるものの一つに自動メモリ管理がある。
+ときどきプログラムの実行が停止され、ガベージコレクタが実行されるのだ。
+もしベンチマーク測定されるプログラムがヒープメモリを少しでも使ったならば（ほとんどの JVM プログラムは使用する）、ガベージコレクタが実行されなければならず、測定を歪めることになる。測定するプログラムを多くの回数実行することでガベージコレクションも何回も発生させガベージコレクションの影響を償却 (amortize) する必要がある。
+
+性能劣化の原因の一つとして、ジェネリックなメソッドにプリミティブ型を渡すことによって暗黙に発生するボクシングとアンボクシングが挙げられる。
+実行時にプリミティブ型は、ジェネリックな型パラメータに渡せるように、それらを表すオブジェクトに変換される。
+これは余計なメモリ割り当てを発生させ、遅い上に、ヒープにはいらないゴミができる。
+
+並列的な性能に関して言えば、プログラマがオブジェクトがどこに割り当てられるかの明示的なコントールを持たないためメモリ輻輳 (memory contention) がよく問題となる。
+実際、GC効果により、オブジェクトがメモリの中を動きまわった後である、アプリケーションライフタイムにおける後期のステージでもメモリ輻輳が発生しうる。
+ベンチマークを書くときにはこのような効果も考慮する必要がある。
+
+## マイクロベンチマークの例
+
+コードの性能を計測するにあたり、上に挙げた効果を回避する方法がいくつかある。
+第一に、対象となるマイクロベンチマークを十分な回数実行することで JITコンパイラがマシンコードにコンパイルし、また最適化されたことを確実にしなければいけない。これはウォームアップ段階 (warm-up phase) と呼ばれる。
+
+マイクロベンチマークそのものは、独立した JVM インスタンスで実行することでプログラムの別の部分により割り当てられたオブジェクトのガベージコレクションや無関係な JITコンパイルによるノイズを低減すべきだ。
+
+より積極的な最適化を行うサーバーバージョンの HotSpot JVM を用いて実行するべきだ。
+
+最後に、ベンチマークの最中にガベージコレクションが発生する可能性を低減するために、理想的にはベンチマークの実行の前にガベージコレクションを行い、次のサイクルを可能な限り延期すべきだ。
+
+Scala の標準ライブラリには `scala.testing.Benchmark` トレイトが定義されており、上記のことを考えて設計されている。
+並行トライの `map` 演算をベンチマークする具体例を以下に示す:
+
+    import collection.parallel.mutable.ParTrieMap
+    import collection.parallel.ForkJoinTaskSupport
+    
+    object Map extends testing.Benchmark {
+      val length = sys.props("length").toInt
+      val par = sys.props("par").toInt
+      val partrie = ParTrieMap((0 until length) zip (0 until length): _*)
+      
+      partrie.tasksupport = new ForkJoinTaskSupport(new scala.concurrent.forkjoin.ForkJoinPool(par))
+      
+      def run = {
+        partrie map {
+          kv => kv
+        }
+      }
+    }
+
+`run` メソッドはマイクロベンチマークの本体で、これが何度も実行され実行時間が計測される。
+上のコードでの `Map` オブジェクトは `scala.testing.Benchmark` トレイトを拡張しシステム指定されたいくつかのパラメータを読み込む。
+`par` は並列度、`length` はトライの要素数をそれぞれ表す。
+
+このプログラムをコンパイルした後、このように実行する:
+
+    java -server -cp .:../../build/pack/lib/scala-library.jar -Dpar=1 -Dlength=300000 Map 10
+
+`server` フラグはサーバ VM が使われることを指定する。
+`cp` はクラスパスを指定し、現ディレクトリと Scala ライブラリの jar を含む。
+`-Dpar` と `-Dlength` は並列度と要素数を指定する。
+最後に、`10` はベンチマークが同じ JVM 内で実行される回数を指定する。
+
+以下はハイパースレッディング付きクアッドコアの i7 で `par` を `1`、`2`、`4` と `8` に設定して得られた実行時間だ:
+
+    Map$	126	57	56	57	54	54	54	53	53	53
+    Map$	90	99	28	28	26	26	26	26	26	26
+    Map$	201	17	17	16	15	15	16	14	18	15
+    Map$	182	12	13	17	16	14	14	12	12	12
+
+初期の試行の実行時間が高めであるが、コードが最適化されると低減することが上のデータから分かる。
+さらに、`4` スレッドに対して `8` スレッドの性能向上が少ししかみられないことからハイパースレッディングによる利益があまりないことも分かる。
+
+## コレクションがどれだけ大きければ並列化するべきか？
+
+これはよく問われる質問だが、これには少し込み入った答が必要になる。
+
+並列化の採算が取れる（つまり、並列化による高速化が並列化することに伴うオーバーヘッドを上回る）コレクションのサイズは多くの要素に依存するからだ。
+全ては書ききれないが、いくつかを挙げる:
+
+<ul>
+<li>マシンのアーキテクチャ。
+異なる CPU の種類はそれぞれ異なる性能特性やスケーラビリティ特性を持つ。
+それとは別に、マシンがマルチコアなのかマザーボード経由で通信するマルチプロセッサなのかにもよる。</li>
+<li>JVM のベンダとバージョン。
+異なる VM はそれぞれコードに対して異なる最適化を実行時に行う。
+異なるメモリ管理や同期のテクニックを実装する。
+<code>ForkJoinPool</code> をサポートしないものもあるので、その場合はよりオーバーヘッドのかかる <code>ThreadPoolExecutor</code> が補欠で使われる。</li>
+<li>要素あたりの負荷。
+並列演算の関数や条件関数が要素あたりの負荷を決定する。
+負荷が軽ければ軽いほど、並列化による高速化を得るのに必要な要素数は多くなる。</li>
+<li>特定のコレクション。
+例えば、<code>ParArray</code> と <code>ParTrieMap</code> のスプリッタではコレクションの走査するスピードが異なり、これは走査だけをみても要素あたりの負荷があるということだ。</li>
+<li>特定の演算。
+例えば、<code>ParVector</code> の（<code>filter</code> のような）変換メソッドは（<code>foreach</code> のような）アクセスメソッドにくらべてかなり遅い。</li>
+<li>副作用。
+メモリ領域を並行で変更したり、<code>foreach</code>、<code>map</code> その他に渡されるクロージャから同期機構を用いると輻輳が発生する可能性がある。</li>
+<li>メモリ管理。
+大量にオブジェクトを割り当てるとガベージコレクションサイクルが誘発される。
+新しいオブジェクトへの参照がどのように取り回されるかによって GC サイクルにかかる時間が異なる。</li>
+</ul>
+
+上に挙げたものを単独でみても、それらを論理的に論じてコレクションの採算が取れるサイズの正確な答を出すのは簡単なことではない。
+サイズがいくつであるかを大まかに示すために、以下に安価で副作用を伴わないベクトルの集約演算（この場合、sum）をクアッドコアの i7（ハイパースレッディング無し）で JDK7 上で実行した具体例を示す:
+
+    import collection.parallel.immutable.ParVector
+    
+    object Reduce extends testing.Benchmark {
+      val length = sys.props("length").toInt
+      val par = sys.props("par").toInt
+      val parvector = ParVector((0 until length): _*)
+      
+      parvector.tasksupport = new collection.parallel.ForkJoinTaskSupport(new scala.concurrent.forkjoin.ForkJoinPool(par))
+      
+      def run = {
+        parvector reduce {
+          (a, b) => a + b
+        }
+      }
+    }
+   
+    object ReduceSeq extends testing.Benchmark {
+      val length = sys.props("length").toInt
+      val vector = collection.immutable.Vector((0 until length): _*)
+      
+      def run = {
+        vector reduce {
+          (a, b) => a + b
+        }
+      }
+    }
+
+まずこのベンチマークを `250000` 要素で実行して `1`、`2`、`4` スレッドに関して以下の結果を得た:
+
+    java -server -cp .:../../build/pack/lib/scala-library.jar -Dpar=1 -Dlength=250000 Reduce 10 10
+    Reduce$    54    24    18    18    18    19    19    18    19    19
+    java -server -cp .:../../build/pack/lib/scala-library.jar -Dpar=2 -Dlength=250000 Reduce 10 10
+    Reduce$    60    19    17    13    13    13    13    14    12    13
+    java -server -cp .:../../build/pack/lib/scala-library.jar -Dpar=4 -Dlength=250000 Reduce 10 10
+    Reduce$    62    17    15    14    13    11    11    11    11    9
+
+次に、順次ベクトルの集約と実行時間を比較するために要素数を `120000` まで減らして `4` スレッドを使った:
+
+    java -server -cp .:../../build/pack/lib/scala-library.jar -Dpar=4 -Dlength=120000 Reduce 10 10
+    Reduce$    54    10    8    8    8    7    8    7    6    5
+    java -server -cp .:../../build/pack/lib/scala-library.jar -Dlength=120000 ReduceSeq 10 10
+    ReduceSeq$    31    7    8    8    7    7    7    8    7    8
+
+この場合は、`120000` 要素近辺が閾値のようだ。
+
+もう一つの具体例として、`mutable.ParHashMap` と（変換メソッドである）`map` メソッドに注目して同じ環境で以下のベンチマークを実行する:
+
+    import collection.parallel.mutable.ParHashMap
+    
+    object Map extends testing.Benchmark {
+      val length = sys.props("length").toInt
+      val par = sys.props("par").toInt
+      val phm = ParHashMap((0 until length) zip (0 until length): _*)
+      
+      phm.tasksupport = new collection.parallel.ForkJoinTaskSupport(new scala.concurrent.forkjoin.ForkJoinPool(par))
+      
+      def run = {
+        phm map {
+          kv => kv
+        }
+      }
+    }
+   
+    object MapSeq extends testing.Benchmark {
+      val length = sys.props("length").toInt
+      val hm = collection.mutable.HashMap((0 until length) zip (0 until length): _*)
+      
+      def run = {
+        hm map {
+          kv => kv
+        }
+      }
+    }
+
+`120000` 要素だとスレッド数を `1` から `4` に変化させていくと以下の実行時間が得られる:
+
+    java -server -cp .:../../build/pack/lib/scala-library.jar -Dpar=1 -Dlength=120000 Map 10 10    
+    Map$    187    108    97    96    96    95    95    95    96    95
+    java -server -cp .:../../build/pack/lib/scala-library.jar -Dpar=2 -Dlength=120000 Map 10 10
+    Map$    138    68    57    56    57    56    56    55    54    55
+    java -server -cp .:../../build/pack/lib/scala-library.jar -Dpar=4 -Dlength=120000 Map 10 10
+    Map$    124    54    42    40    38    41    40    40    39    39
+
+ここで要素数を `15000` まで減らして順次ハッシュマップと比較する:
+
+    java -server -cp .:../../build/pack/lib/scala-library.jar -Dpar=1 -Dlength=15000 Map 10 10
+    Map$    41    13    10    10    10    9    9    9    10    9
+    java -server -cp .:../../build/pack/lib/scala-library.jar -Dpar=2 -Dlength=15000 Map 10 10
+    Map$    48    15    9    8    7    7    6    7    8    6
+    java -server -cp .:../../build/pack/lib/scala-library.jar -Dlength=15000 MapSeq 10 10
+    MapSeq$    39    9    9    9    8    9    9    9    9    9
+
+このコレクションのこの演算に関しては、`15000` 要素以上あるときには並列化の高速化による採算が取れる（一般に、配列やベクトルに比べてハッシュマップやハッシュ集合の方が少ない要素で並列化の効果を得ることができる）。
+
+## 参照
+
+1. [Anatomy of a flawed microbenchmark, Brian Goetz][1]
+2. [Dynamic compilation and performance measurement, Brian Goetz][2]
+
+  [1]: http://www.ibm.com/developerworks/java/library/j-jtp02225/index.html "flawed-benchmark"
+  [2]: http://www.ibm.com/developerworks/library/j-jtp12214/ "dynamic-compilation"
diff --git a/overviews/parallel-collections/architecture.md b/overviews/parallel-collections/architecture.md
index 94570988f0..15c9a79a6b 100644
--- a/overviews/parallel-collections/architecture.md
+++ b/overviews/parallel-collections/architecture.md
@@ -6,6 +6,7 @@ disqus: true
 
 partof: parallel-collections
 num: 5
+languages: [ja]
 ---
 
 Like the normal, sequential collections library, Scala's parallel collections
diff --git a/overviews/parallel-collections/concrete-parallel-collections.md b/overviews/parallel-collections/concrete-parallel-collections.md
index f0c6329222..fdb5aedfa2 100644
--- a/overviews/parallel-collections/concrete-parallel-collections.md
+++ b/overviews/parallel-collections/concrete-parallel-collections.md
@@ -6,6 +6,7 @@ disqus: true
 
 partof: parallel-collections
 num: 2
+languages: [ja]
 ---
 
 ## Parallel Array
diff --git a/overviews/parallel-collections/configuration.md b/overviews/parallel-collections/configuration.md
index 127a7079d6..2618eef12e 100644
--- a/overviews/parallel-collections/configuration.md
+++ b/overviews/parallel-collections/configuration.md
@@ -6,6 +6,7 @@ disqus: true
 
 partof: parallel-collections
 num: 7
+languages: [ja]
 ---
 
 ## Task support
diff --git a/overviews/parallel-collections/conversions.md b/overviews/parallel-collections/conversions.md
index 58c8840a01..3801f5f486 100644
--- a/overviews/parallel-collections/conversions.md
+++ b/overviews/parallel-collections/conversions.md
@@ -6,6 +6,7 @@ disqus: true
 
 partof: parallel-collections
 num: 3
+languages: [ja]
 ---
 
 ## Converting between sequential and parallel collections
diff --git a/overviews/parallel-collections/ctries.md b/overviews/parallel-collections/ctries.md
index 87eb27c74b..01209d70bc 100644
--- a/overviews/parallel-collections/ctries.md
+++ b/overviews/parallel-collections/ctries.md
@@ -6,6 +6,7 @@ disqus: true
 
 partof: parallel-collections
 num: 4
+languages: [ja]
 ---
 
 Most concurrent data structures do not guarantee consistent
diff --git a/overviews/parallel-collections/custom-parallel-collections.md b/overviews/parallel-collections/custom-parallel-collections.md
index e12809b3eb..9f116b0229 100644
--- a/overviews/parallel-collections/custom-parallel-collections.md
+++ b/overviews/parallel-collections/custom-parallel-collections.md
@@ -6,6 +6,7 @@ disqus: true
 
 partof: parallel-collections
 num: 6
+languages: [ja]
 ---
 
 ## Parallel collections without combiners
diff --git a/overviews/parallel-collections/overview.md b/overviews/parallel-collections/overview.md
index 258e931df5..77293aa6de 100644
--- a/overviews/parallel-collections/overview.md
+++ b/overviews/parallel-collections/overview.md
@@ -6,6 +6,7 @@ disqus: true
 
 partof: parallel-collections
 num: 1
+languages: [ja]
 ---
 
 **Aleksandar Prokopec, Heather Miller**
diff --git a/overviews/parallel-collections/performance.md b/overviews/parallel-collections/performance.md
index 17747ecef8..3f1875f519 100644
--- a/overviews/parallel-collections/performance.md
+++ b/overviews/parallel-collections/performance.md
@@ -7,6 +7,7 @@ disqus: true
 partof: parallel-collections
 num: 8
 outof: 8
+languages: [ja]
 ---
 
 ## Performance on the JVM
diff --git a/resources/images/language/ja.png b/resources/images/language/ja.png
new file mode 100644
index 0000000000..9ac9fd09d3
Binary files /dev/null and b/resources/images/language/ja.png differ