[concurrency-interest] Joda-Time immutability

Doug Lea dl at cs.oswego.edu
Tue Jun 21 02:40:09 EDT 2011


We hit issues like this all the time inside j.u.c code, where we can work
around expressivity limitations using jdk-internal Unsafe hacks. Despite a
fair amount of trying (e.g., proposed but scrapped  Fences API), we
haven't found a good way to support non-privilaged use. In the mean time,
the only officially sanctioned strategy is to declare the possibly-mutable
fields as volatile. You can additionally use AtomicXFieldUpdaters to
arrange weaker-than-volatile writes. However, currently, they encounter
more overhead in dynamic type checks than they usually save in underlying
fence costs. So I'd just use volatile and hope that someday we provide a
way to improve performance. Until then, on most machines and usage
patterns, you won't lose enough performance to justify any of the tricks
people have mentioned.

-Doug


> In Joda-Time way back when we structured the code in a complex manner
> and then claimed immutability. This is causing difficulty to try and
> obey proper immutability standards, and I'd like any ideas on fixes.
>
> Consider the "immutable" class DateTime. The hierarchy is as follows:
>
> AbstractInstant
> AbstractDateTime
> BaseDateTime
> DateTime / MutableDateTime
>
> https://github.com/JodaOrg/joda-time/tree/master/src/main/java/org/joda/time
> https://github.com/JodaOrg/joda-time/tree/master/src/main/java/org/joda/time/base
>
> The two Abstract prefixed classes are not an issue, as they just share
> code and contain no state. However the BaseDateTime contains all the
> state (and DateTime/MutableDateTime contain no state).
>
> As a result of this (bad) design, the instance variables in
> BaseDateTime are not final (as they need to be mutated by the
> MutableDateTime subclass). The DateTime ("immutable") subclass is thus
> storing its state in regular mutable variables in BaseDateTime. Under
> the memory model, claiming DateTime as immutable is wrong.
>
> Making changes to fix this is easy, however making changes and
> preserving backwards compatibility (which is very important here) and
> performance (also important) appears to be very tricky at the moment,
> and thats what I'd like thoughts on.
>
> Options considered:
> a) Change BaseDateTime instance variables to final. No - it breaks the
> mutable subclass
>
> b) Move instance variables down from BaseDateTime to DateTime and
> MutableDateTime. No - Serialization broken (deserialization contains
> the data, but it tries to populate BaseDateTime, not DateTime).
>
> c) Try to do something clever with serialization to read the fields in
> manually. No - can't then store the read data as the instance variable
> has to be final...
>
> d) Change the instance variables to be volatile. Seems like an
> overhead (especially for a performance sensitive class like this).
> Doesn't seem ideal when 99% of the uses will use the "immuable" class
> where its effectively final in nature.
>
> Have I missed an idea? Is there any way to say at the end of a
> constructor "please publish this state as I promise it won't change
> later"?!
>
> Stephen
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>




More information about the Concurrency-interest mailing list