You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently (up to Jackson 2.9) byte[] and char[] buffer recycling covers about 4 buffer types for both. I got a report that total retention per thread can exceed 600kB. This is bit more than I would expect for most usage (I'd have guessed 1/10 of that, maybe up to 64kB). Looking at what could be causing this, I think it must be the auto-expanding output buffers:
TextBuffer uses CHAR_CONCAT_BUFFER, and for large output chunks may expand up to 256k chars, i.e. 512 kB
ByteArrayBuilder uses BYTE_WRITE_ENCODING_BUFFER, with size up to 256kB
Now: although we do want to keep buffers sizable enough, I think retention is something to balance too, and both should probably be capped at 128kB level.
There would be other possibilities too, like possibly allocating larger chunks, but only "returning" (and recycling) smaller chunks. But while that would be more optimal I am bit worried that code would be more complicated and possibly fragile; whereas simple size change is, well, simple and unlikely to cause issues (since behavior/logic won't change).
The text was updated successfully, but these errors were encountered:
cowtowncoder
changed the title
Consider reducing max size of recycled byte[]/char[] blocks by TextBuffer, ByteArrayBuilder
Reduce max size of recycled byte[]/char[] blocks by TextBuffer, ByteArrayBuilderJun 14, 2019
Currently (up to Jackson 2.9)
byte[]
andchar[]
buffer recycling covers about 4 buffer types for both. I got a report that total retention per thread can exceed 600kB. This is bit more than I would expect for most usage (I'd have guessed 1/10 of that, maybe up to 64kB). Looking at what could be causing this, I think it must be the auto-expanding output buffers:TextBuffer
usesCHAR_CONCAT_BUFFER
, and for large output chunks may expand up to 256k chars, i.e. 512 kBByteArrayBuilder
usesBYTE_WRITE_ENCODING_BUFFER
, with size up to 256kBwhich are used via methods like:
Now: although we do want to keep buffers sizable enough, I think retention is something to balance too, and both should probably be capped at 128kB level.
There would be other possibilities too, like possibly allocating larger chunks, but only "returning" (and recycling) smaller chunks. But while that would be more optimal I am bit worried that code would be more complicated and possibly fragile; whereas simple size change is, well, simple and unlikely to cause issues (since behavior/logic won't change).
The text was updated successfully, but these errors were encountered: