Hacker News new | ask | show | jobs
by cogman10 15 days ago
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.

2 comments

Now I understand what Valhalla is (new JVM vesion!), I thought it was some kind of dark joke at first. Thanks for the explanation!
Right. And this is safe now since Java Time classes are immutable. That’s key. Before, you had to worry about someone modifying the object.