Community
Participate
Working Groups
Build Identifier: EHS3.6 After the plugin attributes were added, the toc file had new enablement elements: <topic label="Domain gates" href="dfhs3/topics/dfhs3c0016.html"> <enablement> <with variable="platform"> <test property="org.eclipse.core.runtime.isBundleInstalled" args="com.ibm.cics.ts.doc"/> </with> </enablement> </topic> These brought a 400k TOC file up to about 2MB in the plugin. When we looked at a heapdump of the IEHS after it ran out of memory, the biggest use of memory was about 600MB for an array of TocContribution objects. The biggest TocContribution object was 150MB on its own. Most of this seemed to be made up of XML Element objects used to store the XML in memory. I suspect the root cause of this problem is in the eclipse code base, and the way it stores UAElement XML as DOM elements, which are notoriously memory heavy. However, we need a fix to be able to use large toc files within EHS. Reproducible: Always Steps to Reproduce: 1.download EHS3.6 2.place a plugin with sufficient <enablement> element in its toc.xml 3.open the information center, it will crash.
Moving to UI (PDE User Assistance issues fall under UI). There are no committers available to investigate this currently. Are you having memory issues when working with the toc file in the PDE toc editor? If the Eclipse help system is what is dying under the memory load, it indicates a problem in Platform UA.
Hi, I am the "originator" of this bug. The problem is not the PDE editor, it is when running an information center. The (rather cryptic) first comment is how the bug was discovered. We added some code to the dita generation which added enablement elements to every topic in our already large toc files, quadrupling the size. Having done this, running the standalone infocenter (org.eclipse.help.standalone.Infocenter class) would run out of memory very quickly. Having investigated, the cause seems to be that the infocenter caches the W3C DOM for the toc file in memory, which comes in at around 600MB. I don't grok the eclipse UA/UI codebase, so I'm not sure if that's required due to the way things hang together, or if it would be possible to use a less heavyweight data structure, or another method entirely, to cache the toc file. tldr; This should be under platform UA. It definitely seems to be UAElement.java doing the caching of the DOM.
Moving to UA. Note that there are no active committers working on that component.
Can you please attach a simple example plugin that demonstrates the problem? No one is working in this area at the moment. PW
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
