There was a generation of date processing in Java when the class wasn't reentrant. The API was functionally flavored though, so people would instantiate one instance configured how they liked and reuse it across all calls. You would only see this problem under heavy load, such as in production, and it basically took encountering someone for whom it had already happened to spot what was going on. I think I found out from the Java issue tracker, thanks to some other dev filing an accurate bug report, but then I was that person for others at a full handful of other jobs afterward. Everyone was surprised, as one would be. They eventually fixed it but that was busted for a long long time.
replyIf I squint, is this a special kind of heap compression?
replyNot really heap compression or special, it's just reusing a reference to an object already allocated on the heap.
replyRight now, if I do this
LocalDate a = LocalDate.of(2020, 1, 1);
LocalDate b = LocalDate.of(2020, 1, 1);
In Java, that can be pretty expensive even for an object as light as a LocalDate. By running the cache and doing
var cache = new HashMap<LocalDate, LocalDate>();
LocalDate a = cache.computeIfAbsent(LocalDate.of(2020, 1, 1), (i)->i);
LocalDate b = cache.computeIfAbsent(LocalDate.of(2020, 1, 1), (i)->i);
The technique works best when you have a lot of repeated objects which are immutable. It is also only really needed because Valhalla isn't here. Once "value types" become a thing, then the representation for `LocalDate` inside the JVM can become just the fields and not a reference. The JVM is also free to do the sort of de-duplication optimization all on it's own for larger objects.
Now I understand what Valhalla is (new JVM vesion!), I thought it was some kind of dark joke at first. Thanks for the explanation!
reply