OutOfMemoryError kommt nicht/Bug in Java?

[burninhell]

Hallo,

ich bin mit folgendem Verhalten konfrontiert: Ich habe ein Programm, das mit Fremdkomponenten org.w3c.dom.Document Objekte austauscht und erstelle an einer Stelle ein solches Dokument über JAXP (also ich serialisiere ein Objekt nach XML). Dies funktionierte plötzlich letztens nicht mehr und es liegt an der größeren Input-Datenmenge. Das Problem war, dem auf die Schliche zu kommen, denn eine entsprechende Exception ist nicht geflogen, sondern alle Kerne waren plötzlich voll ausgelastet.
Zuerst habe ich versucht zu debuggen, und das Verhalten tritt einige Sekunden nach dem Aufruf von

javax.xml.bind.Marshaller.marshal(object, document);

auf. Laut VisualVM hat der Heap noch Luft und die CPU macht nichts, aber der Taskmanager zeigt einen XMX Speicherverbrauch und eine Last von 100% auf allen Kernen bei javaw.exe.
Das Verhalten gibt es so auf mehreren Systemen mit 1.7 und auch 1.8. Auch nach 12h kommt es zu keiner Exception.
Weil ich den Marshaller nicht debuggen konnte, hab ich die Serialisierung nach XML gleich selbst mit dem DOM "Parser" gemacht: Gleiches Ergebnis, aber eine Schleifenvariable zeigte mir dass es rasend schnell bis zu einer bestimmten Grenze ging und dann jeder Schleifendurchlauf etwas langsamer wurde. Anfangs 10000/sek, rapide langsamer werdend in den Bereich von 1/sek und später 1/min. Dh, irgendwie läuft mein Programm noch, allerdings ultralangsam gegen unendlich. Die Grenze an der es langsamer wird kam abrupt.
Nächster Schritt: XML mit SAX in Bytearray schreiben und dann mit DOM einlesen: Sax läuft durch aber dann beim einlesen ins DOM: gleiches Ergebnis.

Obwohl ich mir dank VisualVM sicher war, es könne nicht am Speicher liegen, hab ich den in Schritten erweitert:
2G: oben beschriebenes Verhalten bei 1,7G
4G: oben beschriebenes Verhalten bei 3,5G
6G: oben beschriebenes Verhalten bei 5G
8G: läuft durch mit Peak bei ca 5G

Es gibt also eindeutig ein Speicherproblem und ich bekomme bei entsprechender Datenmenge und zu kleiner XMX Config auch einen OutOfMemoryError zB vom SAX geworfen, aber beim JAXP/DOM eben nicht. Interessant ist, dass im Kritischen Moment 3 weitere Threads gestartet werden (so dass alle 4 Kerne ausgelastet sind) VisualVM keine Last und weniger Speicherverbrauch anzeigt, aber im Taskmanager javaw.exe den Speicher und die Kerne auslastet. Es fühlt sich für mich an, wie ein Bug in der VM bei der Speicherallozierung im Heap, allerdings bisher nur bei der Benutzung des DOM bzw JAXP (was vermutlich nur ein Wrapper dafür ist).

Google hat nicht geholfen, deswegen: Hat jemand vielleicht dafür auch nur den Ansatz einer Erklärung?

 

[turtle]

Bug in der VM bei der Speicherallozierung im Heap

Du kannst davon ausgehen, das die Speicherallozierung in der JVM funktioniert.

Du kannst dein Prog starten so dass angegeben wird was der GC so macht, denn meine Vermutung ist, das der sehr beschäftigt zu sein scheint

java -verbose:gc

 

[burninhell]

Ja, es scheint der GC zu sein. Leider wird das in VisualVM nicht so dargestellt, dennn dort wird der GC ohne Last angezeigt, aber vermutlich geht auch die Kommunikation zu VisualVM nicht mehr, weil der GC die Gesamte CPU beansprucht.
Frage: Kann man den GC "besser" konfigurieren, also dass er nicht aller Ressourcen beanspruchen kann oder auf eine Anzahl von Kernen/Threads beschränkt ist? Es gibt ja den Parameter

-XX:+UseParNewGC

Es scheint ja so zu sein, als ob das bei mir automatisch der Standard wäre. Kann man vielleicht auf den nicht-parallelen GC zurückgreifen?

Wieso Versucht der GC eigentlich stundenlang mit voller Last ein freies Byte zu finden, anstatt einen MemoryError zu werfen?