From 48f5c47907654350ce30a8dfdda0e977f5d3d39f Mon Sep 17 00:00:00 2001 From: Hans Boehm Date: Fri, 27 Jun 2014 14:50:10 -0700 Subject: 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 --- compiler/dex/compiler_enums.h | 22 +++++++++++++--------- 1 file changed, 13 insertions(+), 9 deletions(-) (limited to 'compiler/dex/compiler_enums.h') 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); -- cgit v1.2.3