myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeanne Waldman (JIRA)" <...@myfaces.apache.org>
Subject [jira] Commented: (TRINIDAD-1985) High live memory usage from SkinStyleProvider
Date Thu, 03 Feb 2011 00:08:29 GMT

    [ https://issues.apache.org/jira/browse/TRINIDAD-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12989910#comment-12989910
] 

Jeanne Waldman commented on TRINIDAD-1985:
------------------------------------------

I fixed TRINIDAD-2025 move _styleNodeToStyleMap to FileSystemStyleCache to take advantage
of same entires on the higher, browser or version or platform layer
which brings down the memory consumption by about 50%.
 If we limit it to 40 entries, what is the likelihood that we would get up to 40 entries?
Does it matter as much now that we reduced the memory by so much?

related issue TRINIDAD-2026 memory leak in skinstyleprovider. This occurs if one application
uses a bunch of different skins.

> 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
>            Assignee: Jeanne Waldman
>
> 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.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message