DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6768>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6768 High Xms heap settings in JVM produce org.apache.xml.dtm.DTMException: No more DTM IDs are available. ------- Additional Comments From [EMAIL PROTECTED] 2002-03-05 17:27 ------- I'm not sure I understand this objection to the GC kluge. We'd try this _only_ when we're in a situation where we're hamstrung by the fact that garbage collection hasn't run... which should be sufficiently infrequent that its effects on your weak-reference caches are relatively minimal. We can handle 2**16 active DTM IDs at once, remember (though large documents may consume more than one ID); if you're running out, you've churned through one heck of a lot of code and probably have data scattered widely enough that you're thrashing your machines caches and swapfile. Note that if you're counting on weak references to persist until you tell them otherwise, you've got a dependency upon a specific JVM's behavior. There's no guarantee that garbage collection won't occur until you're completely out of space; a JVM may run gc at any time it feels doing so would be advantageous. I'm not sure it's entirely reasonable to expect the Xalan code to make the same assumption. After all, what if Xalan _had_ run out of Java heap space rather than running into this barrier first -- GC would run and you'd still find your caches flushed, and this would be correct/normal operation. (I'm not sure asing us to avoid gc() is entirely _unreasonable_ either; I'd prefer not to invoke it unless we must. Unfortunately, I suspect we must, unless we do a fairly serious reachitecting of how RTFs are manipulated and tracked.)
