[concurrency-interest] Joda-Time immutability

Shay Banon kimchy at gmail.com
Mon Aug 1 17:15:45 EDT 2011


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20110802/cd4498f9/attachment.html>


More information about the Concurrency-interest mailing list