`ObjectMapper` default heap consumption increased significantly from 2.13.x to 2.14.0

[mhalbritter]

Hello,

I'm currently looking at heap consumption when using native image with a Spring Boot 3 application. Spring Boot 3.0 SNAPSHOT uses Jackson 2.14.0-rc3. I noticed that with the upgrade from 2.13.4.2 to 2.14.0 the application uses more heap memory, which i tracked down to this PR. It changed the cache implementation from ConcurrentHashMap to PrivateMaxEntriesMap, which in turn preallocates a lot of AtomicReference (they appear to be all empty).

I created a reproducer here - it creates an empty objectmapper and then dumps the heap. It has more information and screenshots in the README.

When using Jackson 2.13.4.2 it uses 567 B for the LRUmap, with Jackson 2.14.0 it uses 507320 B for the LRU map. The bad thing is that most of these caches are per ObjectMapper - create more of them and it uses even more heap.

As we're trying to optimize the memory consumption of native image applications, this is quite a bummer and we hope you can help us out here.

Thanks!

[mhalbritter]

You can see the problem (but not as exaggerated) on a regular JVM. I created 100 ObjectMapper and heapdumped.

This is 2.13.4.2:

The usage is negligible.

This is 2.14.0:

The LRUmap uses 82.1% of the heap.

[GedMarc]

From my understanding, ObjectMapper's should be singleton's as much as possible,
and the ObjectReader and ObjectWriters are the thread-safe objects that can be built from it -

So this would be a bad implementation of using the ObjectMapper

We use native imaging throughout and don't experience anything like this when it's used properly

[mhalbritter]

I created 100 ObjectMappers to show the extent of this problem. As you'll see in https://github.com/mhalbritter/graalvm-jackson, it is even observable with only 1 ObjectMapper. 2.14.0 uses ~880x more heap for an empty ObjectMapper compared to 2.13.4.2.

Spring Boot in my WebMVC sample app uses 4 of them. Not sure if we can get this down to 1.

[GedMarc]

Hmmm - @cowtowncoder this one needs your eyes

[sdeleuze]

I agree with @mhalbritter, it looks like the heap allocation regression in 2.14 is pretty huge and I hope that something could be refined on Jackson side.

@cowtowncoder Looking forward to your feedback, we still have the opportunity to update Jackson before Spring Boot 3 GA is released (expected next week).

[cowtowncoder]

Uh. I did have some concerns about apparent complexity of the improved cache choice, relative to benefits. The baseline for cache should be solid from what I recall, but @pjfanning worked on it most closely.

This is unfortunate of course. But just to make sure: that's about 0.5 MB per ObjectMapper, without any use? (basic data structures).

Given timing I suspect the only potentially easyish win would be changing initial size? And even that would require 2.14.1 release.

[cowtowncoder]

Ok, looks like there are just 4 cache instances by default (plus one optional):

1. JacksonAnnotationIntrospector uses it to keep track of annotations that have (or not) JacksonAnnotationsInside. This definitely does not need super-nice cache
2. TypeFactory caches types; this is relatively heavily used during construction of (de)serializers
3. SerializerCache probably the most important cache since many serializers are dynamically accessed
4. DeserializerCache somewhat important but deserializers mostly statically accessed beyond root instances
5. (optional) RootNameLookup -- mostly used with XML, sometimes JSON

Initial sizes of all these seem to be between 16 and 65, nothing drastic unless I am missing something.

It would be good to get more numbers, if possible, on sizes of individual LRUMap instances.
Unfortunately it doesn't look like initial sizes can be reduced a lot (or put another way, reducing would not have humongous effect).
It'd also be good to just have an estimate of a single LRUMap with specific initial size as baseline to consider what exactly to do. The whole PrivateMaxEntriesMap implementation seems very much overpowered for Jackson's use case... and it'd be good to see if some parts could be removed.

[ben-manes]

Sorry, I haven’t looked at that caching logic for about 7 years (or 12 when written). At the time the emphasis was concurrency for server-class usages, when a concurrent lru algorithm was a novel, hard problem. I’m sure those AtomicReferences could be replaced by aAtomicReferenceArray to slim it down. It is striped lanes to reduce thread contention, but you could greatly simplify that by knowing what is actually needed here, e.g. a single array is probably fine.

I later rewrote this to dynamically stripe light weight, mpsc ring buffers. That is more memory conscious by being slimmer and demand based.

[ben-manes]

@bclozel may be interested as he similarly rewrote that original code for use by Spring. There are versions floating around in groovy, mssql jdbc, etc. it should be simple to streamline to be more tuned towards the project needs.

[cowtowncoder]

That sounds useful @ben-manes thank you for sharing. I wonder how easy it'd be to measure -- of course it's not rocket science to just count fields and do it manually but there are probably tools to automate using introspection to at least give static minimums or such.

[ben-manes]

I used openjdk’s object layout on the current code to verify padding rules for protecting against false sharing. And for a rough footprint estimate, jamm is good enough for seeing if things line up to expectations. All are just best guesses due to jvm internal complexity, JEP-8249196.

[mhalbritter]

This is unfortunate of course. But just to make sure: that's about 0.5 MB per ObjectMapper, without any use? (basic data structures).

VisualVM tells me that 1 ObjectMapper on the JVM uses 132.352 B of heap. This is a new ObjectMapper() without doing anything more with it. However all LRUMap instances are 213.640 B of heap.

VisualVM tells me that 1 ObjectMapper in a native image uses 311.944 B of heap. However all LRUmap instances are 507.320 B of heap.

Here are all the LRUmap instances on the JVM with the fields which have a reference on them: