日本ソフトウェア科学会第 34 回大会 (2017 年度) 講演論文集

Swift 処理系における不可分命令のオーバーヘッドとその解決案
竹内 幹雄

河内谷 清久仁参照カウント方式のメモリ管理では，個々のオブジェクトの被参照数 (参照カウント) を不可分命令を用いて更新し，それがゼロになったらそのオブジェクトを回収する．不可分命令は複数スレッドによるメモリアクセスの競合を避けるために必要であるが，それが起きないことが事前にわかっている場合，あるいは起きたことが事後にわかる場合は，通常の命令と補償コードを用いることでそのオーバーヘッドを削減できる．今回我々は Swift 処理系の通常の命令による単一スレッド向けのコード生成および実行時ライブラリを値型にまで拡張した．マイクロベンチマークによる評
価では，複数スレッド向けのコードと比べて最大 87%の実行時間が削減されることが確認された．さらにトランザクショナルメモリによるオブジェクト回収時の子オブジェクトの参照カウントの更新の最適化についても述べる．

Automatic memory management based on reference counting updates reference count of each object withatomic operation and collects the object when the count becomes zero. Atomic operation is needed to avoid
conflicts of memory access with multiple threads, however, if it is known in advance that the conflict won’t
happen or if it is possible to detect the conflict when it happens, we can eliminate the overhead by using
non-atomic operation and compensation code. In this paper, we enhanced the Swift compiler and runtime
library to use non-atomic operations for generating single-threaded code for value types. With micro benchmark suite, we confirmed that the execution time with single-threaded code was reduced by at most 87%of the original multi-threaded code. We also introduce an idea for using transactional memory to optimize
decrements of reference count of child objects when the parent is about to be collected.

ステップで印の付いていない全てのオブジェクトを一1 はじめに度に回収する．メモリ管理の平均オーバーヘッドが低自動メモリ管理は，プログラミング言語の歴史におく，アプリケーションのスループットが高い反面，アける最も重要な発明の一つである．データの生存期間プリケーションに比較的長い停止時間が存在する弱点

はアプリケーション全体に関わる大域的な性質であるがあり，レスポンスが重視されるユーザインタフェーにも関わらず，手動メモリ管理はそれを局所的に判断スなどの対話型アプリケーションに使いづらい面がしなければならず，本質的に危険である．自動メモリある．

管理はその重責からプログラマを解放する．
自動メモリ管理の種類には，大きく分けて，トレーシング方式と参照カウント方式の二種類がある．

参照カウント方式は，個々のオブジェクトの参照を，変数に保存または変数から削除する際に，そのオブジェクトの被参照数 (参照カウント) を増減し，そトレーシング方式は，時折，大域変数などから再帰れがゼロになったらそのオブジェクトを回収する．ア

的に到達可能な全てのオブジェクトに印を付け，次のプリケーションに長い停止時間が存在しないものの，∗ The overhead of atomic operations and its solution

for the Swift programming language.
This is an unrefereed paper. Copyrights belong tothe Authors.
Mikio Takeuchi, Kiyokuni Kawachiya, 日本アイ・ビー・エム (株) 東京基礎研究所, IBM Research - Tokyo.

メモリ管理のオーバーヘッドが全体の実行時間に占める割合が比較的大きく，スループットが重視されるサーバーなどの非対話型アプリケーションには無駄が多く不向きである．

ケープ解析の結果は保守的であり，その効果は限定的

2 Swift 処理系における参照カウント方式のメモリ管理である．
本論文では，別の手段として，オブジェクトが複数Swift [3] は米国 Apple 社によって設計実装されたスレッドからアクセスされないための条件として，アプログラミング言語である．対話型アプリケーショプリケーションが単一スレッドで動作するという性質

ンのためのプラットフォームである iOS, watchOS,を用いる．これはエスケープ解析より厳しい条件でtvOS, macOS 向けの主要言語に位置付けられており，あるが，オブジェクトごとの判断が不要というメリッ

その処理系は参照カウント方式のメモリ管理を採用しトがある．アプリケーションが単一スレッドで動作すている．2014 年に発表された比較的新しい言語であることを保証するには，処理系がアプリケーションのるが，プログラミング言語の人気ランキング TIOBE

コンパイル時または実行時に，スレッドの作成を検出

Index [14] で 2017 年に過去最高の 10 位に入っておするか，あるいはプログラマがアプリケーションのコり，世界中で多くのプログラマに利用されている．

ンパイル時に単一スレッドで動作することを宣言すれ2015 年にオープンソースとして公開されて以降，我々は Swift をハイブリッドクラウドプラットフォー

ばよい．Swift コンパイラは後者のためのオプションを既に持っている．

ム Bluemix 向けの言語の一つに位置付け，開発者に今回我々はそのオプションの適用範囲を値型にま提供している．クラウドで動作するアプリケーションで拡張した．値型 (value type) は参照型 (referenceの多くは非対話型アプリケーションであるため，参照type) と異なり複数の参照を持たない型であるが，現カウント方式のメモリ管理の特徴である，長い停止時

在の Swift 処理系はコピーオンライト (図 1) という間が存在しないことのメリットが生かせず，高いオー仕組みで値型を実装しており，実装上は複数の参照をバーヘッドのデメリットが目立つ事がある．

持ち不可分命令で参照カウントが更新されているた参照カウント方式のメモリ管理のオーバーヘッドのめ，メモリ管理のオーバーヘッドは参照型と変わらな

多くの部分は，不可分命令による参照カウント更新にい．そのため通常の命令による単一スレッド向けコー起因することがわかっている．不可分命令は，複数のド生成の適用範囲を値型まで拡張することで大きなコアを持つプロセッサ上で複数のスレッドが同時に同性能向上が期待された．実際にマイクロベンチマーク

じオブジェクトの参照カウントを更新する際の競合をで効果を測定したところ，図 2 に示すように，複数避けるために必要であるが，なんらかの手段でそれがスレッド向けのコードと比べて最大 87%の実行時間起きないことを保証できれば，通常の命令で参照カウが削減されることが確認できた．

ントを更新することでそのオーバーヘッドを削減できる．
そのような手段の一つで既に実用化されているも

3 Swift アプリケーションを単一スレッド向けにビルドする手順のにエスケープ解析 [13] がある．エスケープ解析はSwift 処理系は，Swift もしくは C++で書かれたプログラムのコンパイル時に行う静的な解析であり，実行時ライブラリのバイナリを処理系のビルド時にオブジェクトを作成したスレッドがそれを他スレッド作成している．2017 年 9 月の時点では通常のビルドからもアクセス可能な状態にするコードを検出し，オ時には複数スレッド向けのバイナリしか作成しないた

ブジェクトを複数スレッドからアクセスされる可能性

め，まずは Swift 処理系をビルドし直し単一スレッドのあるものとないものに分類する．オブジェクトを他向けのバイナリを作成する必要がある．その後 Swiftスレッドからアクセス可能な状態にするコードが実で書かれたアプリケーションを単一スレッド向けにコ際に実行されるとは限らず，またオブジェクトが他スンパイルし，作成した単一スレッド向けの実行時ライレッドからアクセス可能な状態になっても，実際に他ブラリのバイナリとリンクする．

スレッドからアクセスされるとは限らないため，エスする．

'~/.swift-build-presets[preset: buildbot_linux,single-thread]

!"#$
$%
&%

mixin-preset=buildbot_linux'!"#$&$%&%(()#)'*+,"-.%/
01234567489:45

swift-stdlib-use-nonatomic-rc=true
そして定義した preset を指定すれば単一スレッド向けにビルドされる．

'!"#&$
$%
&%

(!"#$
$%
&%*%

$ build-script --preset=buildbot_linux,\!"#$%&'()"-.,)-/)01234(+, #)*%

single-thread
3. 2 Swift アプリケーションを単一スレッド向けにコンパイルする

図1

コピーオンライトによる値型の実装

Swift ア プ リ ケ ー ション を 単 一 ス レッド 向 け に
コ ン パ イ ル す る に は ，コ ン パ イ ル 時 に オ プ ショ

3. 1 Swift 処理系を単一スレッド向けにビルドする
本論文の読者は，Swift 処理系のビルドに慣れていると仮定する．もしまだの場合はビルド手順 [2] を一ン -Xfrontend -assume-single-threaded を指定する．

$ swiftc -Xfrontend -assume-single-threaded \MyApplication.swift

読し，build-script による通常のビルドができるようになってから進めて欲しい．以下では単一スレッド向けのビルドに必要な差分だけを示す．

3. 1. 1 macOS の場合

4 トランザクショナルメモリによる参照カウントの更新
2, 3 節では，不可分命令の代わりに通常の命令でオSwift 処 理 系 を 単 一 ス レッド 向 け に ビ ル ド す る

ブジェクトの参照カウントを増減することでそのオーに は ，ビ ル ド 時 に 以 下 の オ プ ション を 指 定 す る ．

バーヘッドを大きく削減できることを，単一スレッド

swift-stdlib-use-nonatomic-rc=trueで動作するアプリケーションを題材として示した．本

ビルド時に指定可能なオプションは多岐に渡るた

節では同手法の適用範囲を，複数スレッドで動作すめ，煩雑になるのを避けるため，Swift のビルドシスるアプリケーションにまで広げる方法について議論

テムは複数のオプションをまとめて表現するためのする．

preset という仕組みを持っている．

複数スレッドで動作するアプリケーションにおいて標準で用意されている macOS 向けの preset の一も，実際に競合する参照カウントの更新は全体の一部つが上記オプションを含むため，それを指定すれば単であり，競合する確率も参照カウントの更新ごとにま一スレッド向けにビルドされる．

ちまちである．不可分命令による参照カウント更新の$ build-script --preset=buildbot,tools=RA,\

オーバーヘッドは，それが競合しなかった場合は結果

stdlib=RD,single-thread

的に無駄になるため，全ての参照カウントの更新に対

3. 1. 2 Linux の場合する競合する参照カウントの更新の割合が比較的低残念ながら，標準で用意されている Linux 向けのい場合，競合に備えてあらかじめ全ての参照カウント

preset に単一スレッド向けのものは存在しない．その更新を不可分命令で実行する代わりに，まず通常のこで Swift のビルドシステムが用意する仕組みを用い命令で参照カウントを更新し，競合が起きたら不可分て自分用の preset を定義する．それには以下の内容

命令でその参照カウントの更新をやり直した方が最からなるファイル ~/.swift-build-presets を作成

G)71

図246@,=?
57MJ4.1-)6741
5CG571.V
57M7/.
57M/

ランザクショナルメモリは IBM Blue Gene/Q [15],IBM zEnterprise EC12 [9], IBM POWER 8 [10] などの商用プロセッサでサポートされている．ここでは米国 Intel 社の Transactional Synchronization

Extensions [11] が提供する Restricted Transactional

令に置き換えただけではそのコストに見合うだけのオーバーヘッドの削減効果が得られない．

Intel Core i7-4770 3.40GHz (4cores x 2HT) 上で，†1 本論文ではトランザクショナルメモリはハードウェアトランザクショナルメモリを指すものとする*+,-./01234/15./67809!
()*+,-./,0123455,/6741()*+,-./,8)92:,;.,1/,()*+,-./,8)923455,/6741<=464/45>7?*)6/@#>,)-0==)2>7/6741)=2:A)*()*+,-./,8)923455,/6741:@4=60==)2B)5.,<=4*#+,C,=?,->7/6741)=2
D16,E=)6,0/F,=G)11()*+,-./,:6=71EH76@3:6=71E35)??0==)2I,66,=0==)20**,1-J=4GI,1,=7/K:L==4=I54M)535)??
N2*,J544O)147
01E=2<@41,M44F<@41,M44F
0==)20**,1-+,?,=C,J7M41)//70==)2#>
D6,=)6,>)6)
0==)2D135)??
P*,1354?,0==)2:.M?/=7*6
Q26,:A)*012O)?@)M5,H76@035)??
3@)=)/6,=876,=)5?8)=E,:4=6:4=6,-:6=71E?
0==)20**,1-N4I,1,=7/3)*6.=,<=4*<4*J=4160==)2I,1,=7/:4=6:6=71E?
:6=71ED16,=*45)6741
0==)2PR<P>:4=6:6=71E?S17/4-,3@)=)/6,=876,=)5?:G)55>7/6741)=2876,=)5:7G#>0==)2<4*J=4160==)20==)20**,1<=464/45>7?*)6/@(416,3)=54L0==)2B)5.,<=4*$0==)2876,=)53)5/.5)64=0==)20**,1-8)671'
Q7634.163@)=?
0==)2PRI,1,=7/<P>0==)2B)5.,<=4*0==)2B)5.,<=4*T0==)20**,1-0==)2PRD160==)20**,1-SNJ'%(416,3)=54<7(,G?,60==)2PR+,R0==)20**,1-N4J=4GI,1,=7/0==)20**,1-I,1,=7/:6=./6?
0==)20**,1-0:3DD
O7?64E=)G0==)2<5.?L;.)50==)2PRD160==)2PRI,1,=7/+,R:,C,1Q44G0==)2<5.?L;.)5:71E5,L5,G,163455,/6741
L==4=O)1-571E0==)20**,1-:,;.,1/,
SNJ&>,/4-,0==)20**,1-+,*,)6345:6=71EL;.)5<4716,=34G*)=7?410==)20**,1-P*6741)5?
:6=71EQ.75-,=<452G4=*@7/3)55?
()*+,-./,:6=71E0==)20**,1-8)92()*:.*,=3@)=?
:6)67/0==)20==)2<5.?L;.)5J7C,L5,G,163455,/6741:4=68,66,=?D1<5)/,+IQO7?64E=)G
K4*>,7176+)1E,0??7E1G,16>7/6741)=2
PMU,/60554/)6741
H)5?@O)?@N,?6:6=34G*5,VH)5F:6=71EH)5F>7/6741)=2#<4*J=416S1?)R,<4716,=+IQO7?64E=)GPRPMU,/6?
0==)20**,1-:6=71E?
>7/6741)=2#PRPMU,/6?
>7/6741)=2PRPMU,/6?
>7/6741)=2T()*+,-./,:@4=6:6=71E()*+,-./,:,;.,1/,()*+,-./,:@4=6+,C,=?,-0==)2>7/6741)=2TPRPMU,/6?
:6)/F<=4G4PM?,=C,=354?.=,>7/6741)=2+,G4C,PM?,=C,=<)=67)5520**57,-(,6@4>7/6741)=2:A)*PRPMU,/6?
NA4:.G+,/.=?7C,PA1,-<)=)G,6,=+3$<=7G?
>7/6741)=2+,G4C,PRPMU,/6?
:,6S1741WPRPMU,/6?
X4=844*:,6LV/5.?7C,P=WPRPMU,/6?
PM?,=C,=S1)**57,-(,6@4871F,-87?6:6=N4D16+,C,=?,-Q7-7=,/6741)5Y471:,6D?:.M?,6PRWPRPMU,/6?
:,6S1741:,6LV/5.?7C,P=:,6D?:.M?,6PR:,6D16,=?,/6WPRPMU,/6?
:,6D16,=?,/6PM?,=C,=J4=A)=-,=:6=./6'"#!"#$%&'()*+,-./&!0#%(&(1(*0%#2)&%#,(&3#,4.25(,()%!&25(.&%+(&6($-07%&'0#768'!"&!"%!"$!"#

57M?A7R634=,Z46@,=?[メモリ更新の競合の発生はトランザクショナル
メモリ †1 [5] を用いて検出することができる．ト
57M?A7R634=,Z)64G7/+3[&!

&57M?A7R634=,Z141)64G7/+3[

通常の命令による単一スレッド向けコード生成による性能向上

終的なオーバーヘッドが低くなる可能性がある．

&"&!!=1>-0,;/.1-/<1;?</,0@1%1;?</,0.@1871678A+36;
B;74361C-/<,;378%
2<,8.,6;378,+1=/47<D$#"

Memory (RTM) 命令セットを例題に，その適用可能!
"

RTM では，XBEGIN, XEND 命令でトランザク'#($:-0,;/.1-/<12<,8.,6;378

図3)%性を検討する．

RTM の効果

ションを開始または終了する．トランザクションの実行中に，通常の命令によるメモリ更新が競合すれば，

g++ 5.4.0, GNU assembler 2.26.1 でコンパイルしそのトランザクションは失敗し，XBEGIN の引数とたコードを，8 スレッドでメモリ更新を 1 億回ずつ並して指定した補償コードに制御が移される．したがっ
列実行した時間を比べたところ，競合が起きない場て補償コードとして不可分命令で同じメモリを更新

合，一つのトランザクションで三つ以上のメモリ更新するコードを書けば，ひとまず目的は達成できるが，を行えば，それに見合う効果が得られることがわかっ

XBEGIN, XEND にはそれ自身の実行コストがある

ため，一つのメモリ更新を不可分命令から通常の命た (図 3)．

5 トランザクショナルメモリによるオブジェ

クト回収時の子オブジェクトの参照カウン

トの更新

4 節で，トランザクショナルメモリで性能を改善するには，一つのトランザクションで三つ以上のオブジェクトの参照カウントを更新する必要があることがトの参照カウントのデクリメントと，子オブジェクトわかった．本節では，その可能性を探るため，参照カの回収を分割し，前者を一つのトランザクションにまウント方式のメモリ管理の動作を検討する．

とめる．この分割により，前者と後者の間で，後に回参照カウント方式のメモリ管理では，各オブジェク収する子オブジェクトを覚えておく必要が生じるが，トが持つ参照カウントが，そのオブジェクトが他からこれは，回収しない子オブジェクトの参照をクリアす指される時にインクリメント，指されなくなる時にデることで表現できる．補償コードではトランザクショクリメントされる．デクリメントにより参照カウントンを使わず，同じ手続きの子オブジェクトへの再帰呼がゼロになると，そのオブジェクトは回収される．オ

び出しにより 1 パスで実現する．回収対象のオブジェ

ブジェクトの回収は，そのオブジェクトが参照する全クトが，性能向上に必要な数の子オブジェクトを持たての子オブジェクトの参照カウントをデクリメントしない場合は，最初からこの補償コードを実行すればよて (図 4)，ゼロになればそれを回収した後に，そのオい．以上を仮想コードで示すと以下のようになる．

ブジェクトが占めるメモリを解放する．子オブジェク

Procedure: Collect Object TM(O)トは一般に複数あるため，それらの参照カウントのデN is the number of objects referenced from O

クリメントを一つのトランザクションで実行すれば，T is a threshold value decided from CPU specs,性能向上のための条件を満たすことが可能である．

average failure ratio, etc.
if N ≥ T then

5. 1 Swift 処理系におけるオブジェクトの回収// Proposed method

現在の Swift 処理系は，オブジェクトの回収を，同XBEGIN // Start a transaction

じ手続きの子オブジェクトへの再帰呼び出しにより 1

for all object P referenced from O do

パスで実現している．それを仮想コードで示すと以下Decrement P s RC with non-atomic (light)のようになる．

operation

Procedure: Collect Object(O)if the RC reached 0 thenfor all object P referenced from O do
Decrement P

remember P (e.g. by clearing P that hass RC with atomic (heavy) op-eration
if the RC reached 0 thencall Collect Object(P )end ifend forFree the memory area used by Onon-zero RC)
end ifend forXEND // End the transaction
if the transaction failed thengoto TRADITIONAL
end iffor all object Q whose RC reached 0 do

5. 2 トランザクショナルメモリによるオブジェク
トの回収

5. 1 節のコードにトランザクショナルメモリを直接適用すると，トランザクションが入れ子になる．RTM

call Collect Object TM(Q)end forFree the memory area used by O
returnはトランザクションの入れ子をサポートするが，トラ

end if

ンザクションの失敗は常に最も外側のトランザクショTRADITIONAL:

ンを失敗させるため失敗時のペナルティが大きすぎ// Original method, for small N or transaction-て使いづらい．この問題を避けるため，子オブジェク

failure cases

!"#%!"#$%&'!"()$*+,-./01
234&/567*8!"#$!"#&!"#'

図4

オブジェクト回収時の子オブジェクトの参照カウントのデクリメント

for all object P referenced from O do
Decrement P

569:01234&;<=>?@A:.?</01234&/!"#$%&
BC4DE%&9:s RC with atomic (heavy) op-eration
if the RC reached 0 thencall Collect Object TM(P )end ifend forケーションを止める必要がある．メモリの利用効率も多少下がるため，Swift では採用されていない．

2017 年に発表予定の Swift 4 では，memory ownership model [1] が導入される予定になっている．
ownership を明示的に指定することで，オブジェクトの参照の変数への代入時の挙動をプログラマがきめ細かく制御できるようになる予定である．

Free the memory area used by O

7 おわりに6 関連研究参照カウント更新のオーバーヘッドを削減する試み
としては，次の 2 つが代表的である．

本論文で，我々は Swift 処理系の通常の命令による単一スレッド向けのコード生成および実行時ライブラリを値型にまで拡張した．マイクロベンチマークによ延期型参照カウント法 (deferred reference count-る評価では，通常の複数スレッド向けのコードと比べing) [4] は，ローカル変数から参照されるオブジェクて最大 87%の実行時間が削減されることが確認されトを，参照カウントを更新する代わりにゼロカウントた．Swift アプリケーションを単一スレッド向けにビ表に登録して管理する方法である．参照カウントがルドする具体的な手順についても解説した．さらにトゼロであることが，そのオブジェクトがどこからも参ランザクショナルメモリによるオブジェクト回収時の照されていないことを意味しないため，オブジェクト子オブジェクトの参照カウントの更新の最適化についの即時回収ができず，回収のために時々全体のアプリても述べた，ケーションを止める必要がある．メモリの利用効率も我々は他にも Server Side Swift に関する研究開多少下がる．それらはいずれもメモリの少ない携帯端発を行なっている．例えば Linux 上での効率のよい末で動作する対話型アプリケーションの実行に影響がスレッドのスケジューリング方法や，複数スレッドあるため，Swift には採用されていない．

アプリケーションでの効率の良い参照カウントの実併合型参照カウント法 (coalesced reference count-装方法，Swift による web サーバフレームワークのing) [12] は，オブジェクトのフィールドから参照さKitura [6] などがある．我々の Swift 関連技術の全般

れるオブジェクトを，参照カウントを更新する代わりについては Swift@IBM web site [8] や Swift@IBMに，前回の回収以降の初回のフィールドへの書き込み

Slack channel [7] を参照されたい．

時に，そのオブジェクトの書き込み前のフィールドの値をスレッドごとのログに登録して管理する方法で

参 考 文 献ある．延期型参照カウント法と同様に，オブジェクト[ 1 ] Apple Inc.: Ownership manifesto, http://github.com/apple/swift/blob/master/docs/Owner
shipManifesto.md.の即時回収ができず，回収のために時々全体のアプリ[ 2 ] Apple Inc.: Swift GitHub repository, http://github.com/apple/swift.
[ 3 ] Apple Inc.: Swift web site, http://swift.org/.
[ 4 ] Deutsch, L. P. and Bobrow, D. G.: An Eﬃcient,Incremental, Automatic Garbage Collector, Commun. ACM, Vol. 19, No. 9(1976), pp. 522–526.
[ 5 ] Herlihy, M. and Moss, J. E. B.: Transactional
Memory: Architectural Support for Lock-free Data
Structures, Proceedings of the 20th Annual International Symposium on Computer Architecture, ISCA
’93, New York, NY, USA, ACM, 1993, pp. 289–300.
[ 6 ] IBM Corporation: Kitura web site, http://www.
kitura.io/.
[ 7 ] IBM Corporation: Swift@IBM Slack channel,
http://swift-at-ibm-slack.mybluemix.net/.
[ 8 ] IBM Corporation: Swift@IBM web site, http://developer.ibm.com/swift/.
[ 9 ] IBM Corporation: z/Architecture Principle ofOperations. SA22-7832-10, http://www.ibm.com/
support/docview.wss?uid=isg2b9de5f05a9d578198
52571c500428f9a, February 2015.
[10] IBM Corporation: IBM Power ISATM Version
3.0B. Book II. Chapter 5: Transactional Memory Facility, http://openpowerfoundation.org/?resource_lib=power-isa-version-3-0, March 2017.
R[11] Intel Corporation: Intel⃝
64 and IA-32 Architectures Software Developer’s Manual. Volume 1.
RChapter 16: Programming with Intel⃝
Transactional Synchronization Extensions, 253665-063US,
July 2017.
[12] Levanoni, J. and Petrank, E.: A Scalable Reference Counting Garbage Collector, Technical Report
CS-0967, Technion - Israel Institute of Technology,Haifa, Israel, November 1999.
[13] Park, Y. G. and Goldberg, B.: Escape Analysis
on Lists, Proceedings of the ACM SIGPLAN 1992
Conference on Programming Language Design andImplementation, PLDI ’92, New York, NY, USA,ACM, 1992, pp. 116–127.
[14] TIOBE Software: TIOBE Index, http://www.
tiobe.com/tiobe-index/.
[15] Wang, A., Gaudet, M., Wu, P., Amaral, J. N.,
Ohmacht, M., Barton, C., Silvera, R., and Michael,M.: Evaluation of Blue Gene/Q Hardware Supportfor Transactional Memories, Proceedings of the 21stInternational Conference on Parallel Architectures
and Compilation Techniques, PACT ’12, New York,NY, USA, ACM, 2012, pp. 127–136.