4 ms·

If I squint, is this a special kind of heap compression?

• cogman10 3mo 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.
  • actionfromafar 3mo ago
    Now I understand what Valhalla is (new JVM vesion!), I thought it was some kind of dark joke at first. Thanks for the explanation!
  • drob518 3mo ago
    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.