[
https://issues.apache.org/jira/browse/TRINIDAD-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980425#action_12980425
]
Jeanne Waldman commented on TRINIDAD-1985:
------------------------------------------
When we get a new browser/locale/etc., we get the StyleSheetNodes that match
the StyleContext (this is browser,locale,etc).
Then we merge these together to get the final list of StyleNodes, and from this
we generate the css file.
This is the code that needs to be re-run when we get a new browser/locale/etc.,
where the resulting StyleSheetNodes are unique.
In the adf faces skin files, we have many rules that are particular to a
browser, even a browser version
@agent gecko and (version: 1.7)
@agent gecko and (max-version: 1.9.0)
@agent gecko and (version: 1.8) {
So for gecko 1.7, we'll generate a css file. For gecko 1.8, we'll generate a
different css file, and so on.
Stevan and I think we can try a LRU cache of size 8, and make it configurable
so we can run some tests.
(also, consider optimizing the css generation code as mentioned in
https://issues.apache.org/jira/browse/TRINIDAD-1675, because if we improve
memory with this jira fix, then we'll need to generate the css files more often
and we'll want to speed up that code.)
> 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.
