Keith wrote:
> In any case, keep in mind that any rule for merging synch blocks at
> compile time necessarily relates to the run-time rule for
> reacquisition of locks. There is no point in making the merging rules
> more restrictive or less restrictive than the corresponding run-time
> rules you want to enforce.
Yes, but we also need to consider spec-manship issues. Requiring more
run-time fairness gets into contentious territory. I'd hate to see
the whole JMM JSR fail due to objections such as those just raised by
Oracle. Limiting synch block fusion is just another compiler rule in
a spec mainly devoted to compiler rules, so should not encounter these
kinds of obstacles.
Jan-Willem wrote:
> I think the strongest assertion we might want to make beyond the ones
> above is "the number of consecutive monitorExit actions which may be
> elided by the compiler is bounded by some fixed but
> implementation-dependent number".
I think we need to impose a ceiling on that number to prevent choice
of, say, 10^123456, i.e., effectively no limit at all. Mandating a
ceiling should also make compliance testable, at least approximately
so. Bounding this number also better accommodates later efforts to
deal with fairness without needing to change the JMM spec. A ceiling
of 256 sounds good to me. It should be some number in this general
order of magnitude, so might as well be exactly 256. A better approach
might be to bound total (clock-time) duration, not block counts, but
this would lead to all sorts of problems for both us and compiler
writers trying to follow the spec, without much changing the overall
effect.
-Doug
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:29 EDT