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.
alt Hacker News
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
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
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.