[
https://issues.apache.org/jira/browse/GEODE-6761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16874672#comment-16874672
]
ASF subversion and git services commented on GEODE-6761:
--------------------------------------------------------
Commit 0cfd5e75dc4192d75b139f774daf84dfd48348ca in geode's branch
refs/heads/develop from Kamilla Aslami
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=0cfd5e7 ]
GEODE-6761: Reduce garbage in LocalRegion.initializationThread (#3750)
* Refactor static ints to enum type.
* Cleanup method names.
* Replace null case with default value.
* Added unit test
Co-authored-by: Kamilla Aslami <[email protected]>
Co-authored-by: Jacob Barrett <[email protected]>
> LocalRegion.initializationThread creates unneeded garbage
> ---------------------------------------------------------
>
> Key: GEODE-6761
> URL: https://issues.apache.org/jira/browse/GEODE-6761
> Project: Geode
> Issue Type: Improvement
> Components: core
> Reporter: Darrel Schneider
> Assignee: Jacob S. Barrett
> Priority: Major
> Labels: performance
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The LocalRegion.initializationThread ThreadLocal is currently used in a way
> that can create unneeded garbage. It is common for operations (like put) to
> set this ThreadLocal to BEFORE_INITIAL_IMAGE and then in a finally block to
> restore the ThreadLocal to its previous value. In most cases the previous
> value will be the default of AFTER_INITIAL_IMAGE. What the current code does
> to the ThreadLocal when setting it back to AFTER_INITIAL_IMAGE is it removes
> the ThreadLocal instead of setting it to the Integer AFTER_INITIAL_IMAGE.
> What this causes under the covers is an entry in a map holding ThreadLocal
> instances to be removed (making it garbage). Then when we set on the next op
> to BEFORE_INITIAL_IMAGE we need to recreate an entry in the map the hold that
> value.
> An easy fix is to just set it to BEFORE_INITIAL_IMAGE instead of doing a
> remove. That keeps the entry in the map and we just keep changing its value
> from one canonical Integer to another.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)