-
-
Notifications
You must be signed in to change notification settings - Fork 795
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change default RecylerPool
implementation to newLockFreePool
(from threadLocalPool
)
#1117
Comments
Ok, to get discussion started, I will propose we will use:
as the default. This will have following benefits:
Potential downside for using non-global/shared pool is that overall memory retention may be higher than with global/shared pools. As with any choice this will not be the optimal choice for all use cases. I am looking forward to hearing alternative suggestions, comments. |
Note that this is blocked by FasterXML/jackson-databind#4321 |
Note: issue @mariofusco outlined (thanks!) has been resolved now, so the default pool implementation may be changed. |
RecylerPool
implementation for Jackson 2.17 (to non-ThreadLocal based one)RecylerPool
implementation to newLockFreePool
(from threadLocalPool
)
With #1089 (and related) completed, Jackson 2.16 both allows for configuring alternate
RecyclerPool
s to use for buffer recycling and provides a set of alternatives, notably ones that do not useThreadLocal
for recycling.To reduce likelihood of breakage, the default implementation for 2.16 remains ThreadLocal-based pool. This hopefully allows as to gather feedback, experiences by early adopters, on how alternative pools work (for example, Quarkus project is likely to experiment with alternatives). This, in turn, should let us decide on which alternative to use, along with global-vs-per-factory pools.
As the baseline, my icurrent thinking is that per-factory, unbounded/lock-free implementation might work well as the default.
The text was updated successfully, but these errors were encountered: