diff options
author | Hans Boehm <hboehm@google.com> | 2014-06-27 14:50:10 -0700 |
---|---|---|
committer | Hans Boehm <hboehm@google.com> | 2014-07-11 15:37:05 -0700 |
commit | 48f5c47907654350ce30a8dfdda0e977f5d3d39f (patch) | |
tree | c535d2af13e6fb175ba4ab0d9d044b5c9d2f8489 /compiler/dex/compiler_enums.h | |
parent | 438b9039c77b2c9556f362e8cbbefcf21c55b527 (diff) | |
download | android_art-48f5c47907654350ce30a8dfdda0e977f5d3d39f.tar.gz android_art-48f5c47907654350ce30a8dfdda0e977f5d3d39f.tar.bz2 android_art-48f5c47907654350ce30a8dfdda0e977f5d3d39f.zip |
Replace memory barriers to better reflect Java needs.
Replaces barriers that enforce ordering of one access type
(e.g. Load) with respect to another (e.g. store) with more general
ones that better reflect both Java requirements and actual hardware
barrier/fence instructions. The old code was inconsistent and
unclear about which barriers implied which others. Sometimes
multiple barriers were generated and then eliminated;
sometimes it was assumed that certain barriers implied others.
The new barriers closely parallel those in C++11, though, for now,
we use something closer to the old naming.
Bug: 14685856
Change-Id: Ie1c80afe3470057fc6f2b693a9831dfe83add831
Diffstat (limited to 'compiler/dex/compiler_enums.h')
-rw-r--r-- | compiler/dex/compiler_enums.h | 22 |
1 files changed, 13 insertions, 9 deletions
diff --git a/compiler/dex/compiler_enums.h b/compiler/dex/compiler_enums.h index 799a742032..bdedadbcf8 100644 --- a/compiler/dex/compiler_enums.h +++ b/compiler/dex/compiler_enums.h @@ -440,19 +440,23 @@ std::ostream& operator<<(std::ostream& os, const DividePattern& pattern); /** * @brief Memory barrier types (see "The JSR-133 Cookbook for Compiler Writers"). - * @details Without context sensitive analysis, the most conservative set of barriers - * must be issued to ensure the Java Memory Model. Thus the recipe is as follows: - * -# Use StoreStore barrier before volatile store. - * -# Use StoreLoad barrier after volatile store. - * -# Use LoadLoad and LoadStore barrier after each volatile load. + * @details We define the combined barrier types that are actually required + * by the Java Memory Model, rather than using exactly the terminology from + * the JSR-133 cookbook. These should, in many cases, be replaced by acquire/release + * primitives. Note that the JSR-133 cookbook generally does not deal with + * store atomicity issues, and the recipes there are not always entirely sufficient. + * The current recipe is as follows: + * -# Use AnyStore ~= (LoadStore | StoreStore) ~= release barrier before volatile store. + * -# Use AnyAny barrier after volatile store. (StoreLoad is as expensive.) + * -# Use LoadAny barrier ~= (LoadLoad | LoadStore) ~= acquire barrierafter each volatile load. * -# Use StoreStore barrier after all stores but before return from any constructor whose - * class has final fields. + * class has final fields. */ enum MemBarrierKind { - kLoadStore, - kLoadLoad, + kAnyStore, + kLoadAny, kStoreStore, - kStoreLoad + kAnyAny }; std::ostream& operator<<(std::ostream& os, const MemBarrierKind& kind); |