upvote
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
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