[jira] [Closed] (JAMES-3745) FastByteArrayOutputStream is never downsized

["Benoit Tellier (Jira)" <se...@james.apache.org>]

     [ https://issues.apache.org/jira/browse/JAMES-3745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Benoit Tellier closed JAMES-3745.
---------------------------------
    Resolution: Fixed

>  FastByteArrayOutputStream is never downsized
> ---------------------------------------------
>
>                 Key: JAMES-3745
>                 URL: https://issues.apache.org/jira/browse/JAMES-3745
>             Project: James Server
>          Issue Type: Improvement
>          Components: IMAPServer
>    Affects Versions: 3.7.0
>            Reporter: Benoit Tellier
>            Priority: Major
>             Fix For: 3.8.0
>
>         Attachments: fastByteArray.png
>
>          Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> I started studying production heap dump in an effort to reduce the per user memory footprint. In conjunction with issues discussed in JAMES-3740 I found that in FastByteArrayOutputStream, upon writing a long line this buffer is sized up and never sized down.
> We can end up with 60KB+ memory allocated per user... Forever.
> While the impact is not as huge as the one described in JAMES-3740 yet for James deployment with a high connection density this could be non neglictible (100s MB of RAM).
> Furthermore given the long lived lifecycle of this buffer (connection) it is very likely to be promoted to the old gen, which could build up to eventually get long GC pauses.
> Suggestion: create a new IMAP composer for each request, 2 -> 64KB allocation is anyway neglictibe, likely cheaper than the lookups to get them back! We will thus allocate more memory, yes, but only for short lived durations, wich JVM GC is really good at.
> IMO it is so easy to avoid this unwanted behaviour that it would be sad not to do it.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org