On Sunday, 18 May 2014 at 10:33:53 UTC, Andrei Alexandrescu wrote:
Maybe I misunderstood - I thought the change preserves semantics. -- Andrei
There are two layers to the changes discussed in this thread. The first is to remove __monitor from Object. This is something I think we all agree on.
Now there are two possibilities for what to do when a user tries to synchronize on an instance that does not have a monitor field. One option would be to just fall back on a global lock lookup table of some sorts. This is what Yuriy's proposal does, and indeed preserves language semantics at the expense of a "silent" slowdown in these cases. The other is to outright forbid synchronizing on such objects. This is a small breaking change, but arguably the cleaner solution.
If we didn't have to worry about being backwards compatible, I'd definitely argue for the second solution. Java compatibility is not a very strong argument in my opinion. First, porting a Java application 1:1 is asking for performance hazards (w.r.t. GC, ...) anyway. Second, the no-synchronized-by-default design allows for clear error messages that immediately suggest the correct fix (add an attribute to the class declaration), and for mechanical porting, Java classes could just be translated to "@synchronizable class" or whatever.
David
