[concurrency-interest] Joda-Time immutability

Stephen Colebourne scolebourne at joda.org
Mon Aug 1 17:35:00 EDT 2011


If the choice is Correct and slower or Risky and faster, I choose correct.

Stephen


On 1 August 2011 22:15, Shay Banon <kimchy at gmail.com> wrote:
> I just did a quick test by changing to volatile field the 1.6 release, and
> on my machine I see 6x worse perf on 10 million data points (on a "real
> world" use case in my system, end to end). Naturally, this will vary
> depending on many aspects (number of cores, os) in terms of how volatile
> write and read are handled. I really think that this is the wrong solution
> to the "problem", but up to you...
>
> On Mon, Aug 1, 2011 at 11:29 PM, Stephen Colebourne <scolebourne at joda.org>
> wrote:
>>
>> 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
>> >
>> >
>>
>> _______________________________________________
>> 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