We're updating the issue view to help you get more done. 

CollatorServiceShim$CService holds strong reference of collation data permanently

Description

The below is the size and the referencing path to the collation data after obtaining an instance of Korean collator in Android.
ROOT
233,720 56 233,776 → root android.icu.text.CollatorServiceShim$CService@73a06e50.cache
233,720 233,720 → java.util.concurrent.ConcurrentHashMap@17903890.table
233,660 233,660 → java.util.concurrent.ConcurrentHashMap$Node[16]@17904fc8[3]
233,596 233,596 → java.util.concurrent.ConcurrentHashMap$Node@17905018.val
233,553 233,553 → android.icu.impl.ICUService$CacheEntry@17905048.service
233,537 233,537 → android.icu.text.RuleBasedCollator@17905058.data
142,536 142,536 → android.icu.impl.coll.CollationData@17905080

Here is the code snippet from ICU.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 public class ICUService { .... public Object getKey(...) { cache = new ConcurrentHashMap<String, CacheEntry>(); } } public class ICUService extends ICUNotifier private Map<String, CacheEntry> cache; // Record the actual id for this service in the cache, so we can return it // even if we succeed later with a different id. private static final class CacheEntry { final String actualDescriptor; final Object service; CacheEntry(String actualDescriptor, Object service) { this.actualDescriptor = actualDescriptor; this.service = service; } } }

Is the strong reference to collation data intentional?
Why does ICU need the cache?
How much speed-up for caching the collation data?
Could the cache avoided or being soft/weak reference?
GoogleIssue:62512621

Environment

Status

Assignee

Markus Scherer

Reporter

Victor Chang

Labels

Components

Fix versions

Priority

assess