High live memory usage from SkinStyleProvider
---------------------------------------------
Key: TRINIDAD-1985
URL: https://issues.apache.org/jira/browse/TRINIDAD-1985
Project: MyFaces Trinidad
Issue Type: Bug
Components: Archetype
Affects Versions: 1.2.12-core
Reporter: Stevan Malesevic
We were checking a live memory usage in one app and noticed that some 83MB of
heap is pinned under SkinStyleProvider. This is under 14 instances of
FileSystemStyleCache$Entry each with about 6MB of memory
Heap shows these keys for styles
Locale Version
en Mozilla/5.0 (Windows NT 5.1; rv:2.0b7) Gecko/20100101 Firefox/4.0b7
ko Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.11)
Gecko/20100701 Firefox/3.5.11 ( .NET CLR 3.5.30729)
en Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.11)
Gecko/20100701 Firefox/3.5.11 ( .NET CLR 3.5.30729)
ko Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.10
(KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10
en Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.10
(KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10
ko Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3)
Gecko/20090824 Firefox/3.5.3
en Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3)
Gecko/20090824 Firefox/3.5.3
en Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.18)
Gecko/2010020220 Firefox/3.0.18 (.NET CLR 3.5.30729)
ko Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.18)
Gecko/2010020220 Firefox/3.0.18 (.NET CLR 3.5.30729)
en Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9)
Gecko/20100315 Firefox/3.5.9 (.NET CLR 3.5.30729)
ko Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9)
Gecko/20100315 Firefox/3.5.9 (.NET CLR 3.5.30729)
en Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; Trident/4.0; .NET
CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
en Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2)
Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)
en Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.15)
Gecko/20101026 Firefox/3.5.15 ( .NET CLR 3.5.30729)
en Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.10)
Gecko/20100914 Firefox/3.6.10 (.NET CLR 3.5.30729)
ko Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727;
.NET CLR 1.1.4322; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.2)
en Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727;
.NET CLR 1.1.4322; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.2)
en Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12)
Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729)
en Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.16)
Gecko/20101130 Firefox/3.5.16 ( .NET CLR 3.5.30729)
ko Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.16)
Gecko/20101130 Firefox/3.5.16 ( .NET CLR 3.5.30729)
en Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13)
Gecko/20101203 Firefox/3.6.13
Now beside the amount of memory pinned by single FileSystemStyleCache$Entry the
issue is that we apparently create too many different versions and there is no
restriction to the size of cache leaving open door for memory leak
Two questions
1. Do we really have different styles for FF on 3.5 or 3.6 or so? If not why
do we key by it?
2. Given different browsers and locales having cache as plain concurrent hash
map is actually a source of leak as over time it can accumulate more and more.
Do we have any restriction there? Should the entries by LRU or have exparation
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
