[ https://issues.apache.org/jira/browse/TRINIDAD-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12986088#action_12986088 ]
Jeanne Waldman commented on TRINIDAD-1985: ------------------------------------------ I reworked the code to reuse the CSSStyle objects at the FileSystemStyleCache level, not the StylesImpl level, and this looks like it saves a lot of memory. I'll upload a patch once more tests have been done. > 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.