[concurrency-interest] Joda-Time immutability

Stephen Colebourne scolebourne at joda.org
Mon Aug 1 16:29:04 EDT 2011


I'd be interested in any real world benchmark that indicates a
significant slow down at the application level (not a micro
benchmark).

However, this thread didn't exactly give me any better options in line
with compatibility (esp. now 2.0 is released)

Stephen


On 1 August 2011 19:54, Shay Banon <kimchy at gmail.com> wrote:
> Hi,
>   I find the solution to change to volatile fields problematic. In my case,
> I use the mutable version of the DateTime to have UTC based timestamps
> converted automatically to relevant timezone and rounding, over a very large
> collection. Having volatile field means heavy writing and then reading of
> those values, which will really hurt perf. Here is an example of what I do:
> long[] timestamps = ... //very large dataset of timestamps
> MutableDateTime time = ..
> for (int i = 0; i < timestamps.length; i++) {
>      time.setMillis(timestamp[i]);
>      ....
>      time.getMillis();
> }
> I think changing to volatile will hurt many more programs out there than one
> might think...
> I would even say that the immutable values will almost always have to go
> through a memory barrier of some sort when "transfered" to another thread,
> so in practice the volatile solution will break more code out there (by it
> performing badly). I think if this can't be solved in the proper way (finals
> on immutable, non volatile on mutable, and hack serialization), then my vote
> is to break serialization, and if not, then do nothing and make a note in
> the docs regarding the immutable values.
> -shay.banon
> p.s. Sorry if this discussion has diverged to pure Joda, will be happy to
> continue it on the Joda mailing list if it makes sense
> On Tue, Jun 21, 2011 at 2:49 PM, Stephen Colebourne <scolebourne at joda.org>
> wrote:
>>
>> On 21 June 2011 09:11, Mark Thornton <mthornton at optrak.com> wrote:
>> > This should be backward compatible with existing serialized instances
>> > while
>> > allowing the fields in BaseDateTime to be final. It comes at the expense
>> > of
>> > a slightly larger MutableDateTime object, and slightly slower
>> > deserialization.
>>
>> In the end, I think Doug's advice is probably right. Just use
>> volatile. I don't think its ideal, but it "Just Works", which is a
>> good thing in this codebase.
>>
>> Mark, I think your change would work (and I like the neat set before
>> defaultReadFields). However it would have required any mutable
>> application subclass to be changed, which I was hoping to avoid.
>> Compared to the volatile approach I decided simple is best.
>>
>>
>> https://github.com/JodaOrg/joda-time/commit/67f1a30fc0fceda751b6347b2b16a5081878ac1e
>>
>> Another variation which would also appear to work would be to change
>> the data storage in BaseDateTime to a transient final two element
>> array and use ObjectStreamField to read and write the existing
>> serialized format. (The final array would presumably keep immutability
>> happy, while the array settability even when final would keep the
>> mutable classes happy). But the complexity was considerably greater,
>> so volatile won (unless someone screams that it kills their
>> performance).
>>
>> Thanks everyone for your thoughts.
>>
>> Stephen
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
> _______________________________________________
> 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