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, 06 Jan 2011 19:21:46 GMT

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

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

While investigating this issue, I found that if we have:
  @agent ie, gecko
  {
    .fooJMWTestSSN {background-color:pink}
  }
the CSS file is shared if this is the only @rule.
If I have:
  @agent ie
  {
    .fooJMWTestSSN {background-color:pink}
  }
@agent gecko
  {
    .fooJMWTestSSN {background-color:pink}
  }
then this creates two different css files (one for gecko and one for IE) even though there
are no diffs in the contents of the css file.
A simple performance enhancement is to make sure the @rules that can be combined, are.
A more complicated enhancement is to do a better job of comparing stylesheet nodes.



> 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.


Mime
View raw message