[ https://issues.jboss.org/browse/JBIDE-11539?page=com.atlassian.jira.plugi... ] Alexey Kazakov updated JBIDE-11539: ----------------------------------- Fix Version/s: 3.3.0.Beta3 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-11539?page=com.atlassian.jira.plugi... ] Viacheslav Kabanovich commented on JBIDE-11539: ----------------------------------------------- Yes, please attach the memory dump. Please let us know your values of -Xms, -Xmx, -XX:MaxPermSize VM arguments, and approximate size of the workspace. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-11539?page=com.atlassian.jira.plugi... ] Viacheslav Kabanovich commented on JBIDE-11539: ----------------------------------------------- Sigi, please first just let me know how many entries key: org.eclipse.core.internal.resources.File value: org.jboss.tools.jst.web.kb.internal.XmlContextImpl are in the map, and how many xml files are in your workspace. Theoretically, kb model can keep one entry for each xml file. It is a cache to be used for next builds and searches. I have looked into the lifecycle of this map's content, and could not find a case of memory leak: as soon as a resource is renamed or removed, all out-of-date entries are removed. So let us please first check the case of your workspace being too big for the set VM memory arguments. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-11539?page=com.atlassian.jira.plugi... ] Viacheslav Kabanovich commented on JBIDE-11539: ----------------------------------------------- Yes, it is srange to have thousands of entries in PageContextFactory.cache map, if your project has just a couple hundred of files. We have to know what kind of 'extra' source finds its way into the map. Could you please count all xml/html/xhtml/jsp files in your workspace? Also, does your project have links, either to external resources, or referencing inner resources by a different path? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-11539?page=com.atlassian.jira.plugi... ] Sigi Kiermayer commented on JBIDE-11539: ---------------------------------------- With everything and everything double, i have 700 xhtml files(inkl. copies in target folder). There are also 2000 xml files but they arent relevant. Those are for testing etc. It takes a while until i see that eclipse uses so much ram but i have this issues every day after a few hours. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-11539?page=com.atlassian.jira.plugi... ] Viacheslav Kabanovich edited comment on JBIDE-11539 at 4/24/12 12:25 PM: ------------------------------------------------------------------------- But these 2000 xml files may be relevant! You wrote that values in the map are instances of org.jboss.tools.jst.web.kb.internal.XmlContextImpl, objects of this class are created for xml files; while for xhtml files, it is org.jboss.tools.jst.web.kb.internal.FaceletPageContextImpl If your xml files are located under a Java source folder, or Web content folder, they are certainly processed by KB builder, which assumes that any xml may contain expression language to be validated. was (Author: scabanovich): But these 2000 xml files may be relevant! You wrote that in values in the map are instances of org.jboss.tools.jst.web.kb.internal.XmlContextImpl, objects of this class are created for xml files; while for xhtml files, it is org.jboss.tools.jst.web.kb.internal.FaceletPageContextImpl If your xml files are located under a Java source folder, or Web content folder, they are certainly processed by KB builder, which assumes that any xml may contain expression language to be validated. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-11539?page=com.atlassian.jira.plugi... ] Viacheslav Kabanovich edited comment on JBIDE-11539 at 4/24/12 1:28 PM: ------------------------------------------------------------------------ I have created an xml inside Java source folder, with file size of 40Kb, containing 2000 EL instances like #{beanName.propertyName}. I made sure that if I use wrong property name, like #{beanName.wrongpropertyName}, validator puts error marker to it. Then I created 200 copies of the file, rebuilt the project, and checked increase in memory used by Java . It amounted to 500Mb. The map contained just these 200 entries, no memory leak, just heavy memory load. It seems clear what takes most memory - it is JobSafeStructuredDocument objects, referenced by cached context objects. Sigi, you can make certain that your xml files are monitored by KB builder by putting EL #{beanName.wrongpropertyName} into a file, where 'beanName' should be a bean name available in the project. If you get an error marker '"wrongpropertyName" cannot be resolved', then KB builder processes these xml files. Also, could you please check by your dump that most of 485,306,072 bytes, accumulated in HashMap you mentioned, are taken by JobSafeStructuredDocument and BasicStructuredDocument objects. If that is so, probably we should not keep reference to the document, but request it every time we need it; or if it deteriorates performance, elaborate an algorithm, that keeps some documents, while they are heavily used, and disposes them, when they are not in much demand. was (Author: scabanovich): I have created an xml inside Java source folder, with file size of 40Kb, containing 2000 EL instances like #{beanName.propertyName}. I made sure that if I use wrong property name, like #{beanName.wrongpropertyName}, validator puts error marker to it. Then I created 200 copies of the file, rebuilt the project, and checked increase in memory used by Java . It amounted to 500Mb. The map contained just these 200 entries, no memory leak, just heavy memory load. It seems clear what takes most memory - it is JobSafeStructuredDocument objects, referenced by cached context objects. Sigi, you can make certain that your xml files are monitored by KB builder by putting EL #{beanName.wrongpropertyName} into a file, where 'beanName' should be a bean name available in the project. If you get an error marker '"wrongpropertyName" cannot be resolved'. Also, could you please check by your dump that most of 485,306,072 bytes, accumulated in HashMap you mentioned, are taken by JobSafeStructuredDocument and BasicStructuredDocument objects. If that is so, probably we should not keep reference to the document, but request it every time we need it; or if it deteriorates performance, elaborate an algorithm, that keeps some documents, while they are heavily used, and disposes them, when they are not in much demand. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-11539?page=com.atlassian.jira.plugi... ] Viacheslav Kabanovich updated JBIDE-11539: ------------------------------------------ Attachment: Dump_1 .png Dump_2.png -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-11539?page=com.atlassian.jira.plugi... ] Viacheslav Kabanovich resolved JBIDE-11539. ------------------------------------------- Resolution: Done -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-11539?page=com.atlassian.jira.plugi... ] Vlado Pakan commented on JBIDE-11539: ------------------------------------- Please could you verify if this problem is fixed and let me know that I can close this Jira? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-11539?page=com.atlassian.jira.plugi... ] Vlado Pakan closed JBIDE-11539. ------------------------------- -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira