2010/1/9 Egor Pasko <egor.pa...@gmail.com>: > On the 0x68E day of Apache Harmony Nathan Beyer wrote: >> On Sun, Dec 20, 2009 at 1:42 PM, Tim Ellison <t.p.elli...@gmail.com> wrote: >>> On 19/Dec/2009 20:54, Nathan Beyer wrote: >>>> On Sat, Dec 19, 2009 at 2:26 PM, Tim Ellison <t.p.elli...@gmail.com> wrote: >>>>> On 19/Dec/2009 18:57, Nathan Beyer wrote: >>>>>> RE: https://issues.apache.org/jira/browse/HARMONY-6404 >>>>>> >>>>>> I posted up two proposed patches for String, please comment on which >>>>>> is preferable. One is the change previously mentioned, the other is a >>>>>> slightly bigger reorganization. >>>>> Neither. There is nothing wrong with the original code. >>>>> >>>>> Any JVM or compiler that would actually move a load up above a >>>>> conditional store to the same variable would be seriously broken all >>>>> round. >>>> >>>> Does that really matter? >>> >>> Yes, we don't code to allow for bogus VM/compiler implementations. >>> >>>> Shouldn't the Java source be written such that it's as correct as >>>> possible according to the language spec and related specs? >>> >>> I'm guessing you have your tongue firmly in your cheek when writing that >>> :-) Yes to "correct as possible" but we don't account for the never to >>> be implemented edge cases that are possible by the spec. >>> >>> Put another way, we don't fix things that are not broken. I challenge >>> you to show an implementation that would do the read re-ordering as you >>> suggest. >> >> So what's all the fuss, then? According to this guy [1] ... our code >> is broken and he helped define the memory model. This is the guy >> suggesting the issue. Our code is almost exactly like the same he >> describes as broken. The only difference is we have an extra check on >> 'count'. >> >> At this point, I just want to understand. >> >> [1] http://jeremymanson.blogspot.com/2008/12/benign-data-races-in-java.html > > Sorry for delayed answer (was on vacation). > > After all the fuss I think Tim is right. JMM is a model that is close > to real implementations except some corner cases like this. JMM allows > slightly more than any JVM implementation would do. That's a good > excersise to think about and be warned, but not a lot more. > > If our goal is to please all possible JVM implementations, we should > bother, but that would be far from the main goal of the project. Until > we have a meaningful implementation to make two memory loads in the > place where only one is required, we should not take any action on > hashCode. > > -- > Egor Pasko
Since this issue doesn't have clear consensus, at least not to me, I'd like to get an explicit vote for resolving this issue as "Wont Fix". https://issues.apache.org/jira/browse/HARMONY-6404 +1 to close as "Wont Fix" -1 to leave open - please accompany with a patch
