upvote

points

by cogman105 hours ago |
comments
upvoteby drob5185 hours ago|
next
[-]
I do something similar for Java Time local dates. Financial data in particular has lots of redundant date info and benefits from being memoized. Converting to epoch millis also works.
reply
upvoteby hinkley3 hours ago|
parent|
next
[-]
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.
reply
upvoteby actionfromafar4 hours ago|
parent|
prev|
[-]
If I squint, is this a special kind of heap compression?
reply
upvoteby cogman104 hours ago|
parent|
[-]
Not really heap compression or special, it's just reusing a reference to an object already allocated on the heap.

Right now, if I do this

    LocalDate a = LocalDate.of(2020, 1, 1);
    LocalDate b = LocalDate.of(2020, 1, 1);
A and B reference 2 different object allocations on the heap even though they are the same date. a != b.

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);
Now you have the situation where `a == b` and you immediately end up dropping the object allocation for b on the next GC.

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.

reply
upvoteby actionfromafar2 hours ago|
parent|
[-]
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
upvoteby to11mtm3 hours ago|
prev|
[-]
I mean FWIW this looks to me much like the sort of hacks I had to get into last time I worked with Java so I can't really blame you....

> Valhalla can't come soon enough for us.

This will be interesting to see for sure, I think it will raise the bar for competitors as well; .NET GC has lingered in some ways for a while in progressing [0][1], there is a long standing github discussion around a lower latency GC where there is a potential alternative [2] but nothing really signaling that it could be integrated in future as an option. Valhalla might finally put enough pressure on microsoft to do something about the lag in this space.

[0] - The inferred stackalloc stuff on the JIT level is awesome but I don't count that as improvement to actual GC

[1] - Pinned allocs took a long time and we still can't get aligned pinned allocs (have to manually pad instead)

[2] - https://github.com/dotnet/runtime/discussions/115627

reply