2 lästige Details im Markierungs-Tab

[unregistered]

Hallo,

meine Begeisterung für diese Software hält an, die nun zu vermeldenden "kleineren" Fehler sind nicht erst seit dem letzten Release aufgetreten, waren aber (vor LANGER Zeit) noch NICHT vorhanden. Aber da sie bei meiner Art, TVB zu nutzen, ziemlich regelmäßig zu störenden Effekten führen, will ich sie hier kund tun:

• Fehler 1 (einfach zu reproduzieren):
  
  Wenn der erste Eintrag im Markierungstab deselektiert wird (z.B. per RMB -> Markieren -> entferne Sendung von Standardliste), dann beginnt das Programm 100% CPU zu verbrauchen (endlos zu warten). Meine derzeitiger "Workaround": nachdem die Sendung tatsächlich entfernt worden ist, kurz auf ein anderes Tab klicken und wieder zurück wechseln. Dann geht die CPU-Nutzung wieder zurück.
  
  Fehler 2 (leider kann ich diesen nicht stabil reproduzieren):
  
  Nachdem TVB über Einstellungen -> Allgemeine Einstellungen -> Maustasten -> Einfacher Linksklick -> Markieren
  eingestellt wurde, nutze ich die linke Maustaste im Markierungstab um Filmeinträge manuell zu DESELEKTIEREN. Dabei kommt es immer mal wieder vor (nicht nur nach Scroll-Bewegungen), daß der "falsche" Eintrag aus den markierten entfernt wird. Mein Workaround hier: Stattdessen über RMB -> Menü -> markieren -> gehen, wobei der FOKUS garantiert auf den richtigen Eintrag wechselt, der dann auch deselektiert wird. Ist halt lästig.

Wie gesagt, beide Situationen haben eine Wordaround-Methode, müssen daher nicht als kritisch beurteilt werden. Aber es ist wahr, daß das (zu 2.6.irgendwas-Zeiten) noch ging, da gingen halt andere Sachen nicht. Deshalb habe ich auch lange nichts "gemeldet".

[ds10]

Ich hab' jetzt hier Markierungen hinzugefügt, entfernt und überall mit links geklickt. Ich kann auch nach etlichen Versuchen die Probleme nicht nachvollziehen. Hier geht weder die CPU dauerhaft auf 100% noch wird die falsche Sendung entfernt.

[unregistered]

Danke für die Rückmeldung.

Nun muß ich also weiter forschen...
Ich verwende übrigens Ubuntu Precise (3.2.0-45-generic/amd64) mit Gnome3, Java build 1.7.0_21-b11 von Oracle, darauf TVB 3.3

Ehe ich mir nun die Mühe mache, TVB auf Windows umzustellen, möchte ich wissen, welche Probleme ich bei der Übernahme der Konfiguration zu erwarten habe. Als ich das (vor Jahren) mal versuchte, stellte sich heraus, daß das .tvbrowser-Verzeichnis keineswegs kompatibel war und ich hatte mich damals davon überzeugt, daß eine gleichzeitige Nutzung der selben Konfiguration (abwechselnd+exklusiv) nur möglich war, indem ich unter Windows eine virtuelle Maschine mit Linux auf meine im Netz befindliche Konfiguration zugreifen ließ.

Auch jetzt könnte ich (unter Linux) eine VM mit Windows aufsetzen und TVB dort laufen lassen. Nur möchte ich die über Jahre gewachsenen Einstellungen nicht nochmal vornehmen müssen.

Hat da jemand Erfahrungen oder Hinweise für mich?

[uzi]

z.B. per RMB -> Markieren -> entferne Sendung von Standardliste

--

Ich hab' jetzt hier Markierungen hinzugefügt, entfernt und überall mit links geklickt. Ich kann auch nach etlichen Versuchen die Probleme nicht nachvollziehen. Hier geht weder die CPU dauerhaft auf 100% noch wird die falsche Sendung entfernt.

allerdings muss ich zugeben, dass ich gestern auch versucht hatte das nachzuvollziehen und im kontextmenü (= rmb) gar keinen menüpunkt 'markieren' habe. insofern ist mir auch nicht wirklich klar, was unregistered da genau gemacht hat. ich habs dann darauf geschoben, dass ich noch mit tvb 3.2 unterwegs bin...

[unregistered]

ich habs dann darauf geschoben, dass ich noch mit tvb 3.2 unterwegs bin...

Nee, nee. Das RMB gibt es schon lange (2. von oben). Wie gesagt: ich lebe schon lange damit trotz der Probleme. (ein CPU-Kern wird 100% busy, nachdem ein Eintrag unmarkiert wurde. Und sporadisch wird der falsche Eintrag unmarkiert).

Wenn das aber nur bei mir auftreten sollte, schleppe ich das schon lange mit mir herum.

[uzi]

also bei mir sieht tab markierungen -> 1. eintrag -> rmb so aus, wie im anhang. wie gesagt, in dem menü gibt es keinen punkt 'Markieren'. jedenfalls nicht bei mir.

[ds10]

Also ich verwende auch Ubuntu 12.04 64Bit. Hast du denn Personas aktiviert? Das Problem ist mit Sicherheit ein Threading-Problem, bei dem zwei oder mehr Threads gegenseitig auf sich warten und dabei Last produzieren oder irgendwie startet eine Endlosschleife.

@uzi
Bei dir steht doch Markierung entfernen (mit dem Schreddersymbol).

Und ich habe natürlich auch mit Rechtsklick probiert und nicht nur mit Klicken.

[uzi]

@uzi
Bei dir steht doch Markierung entfernen (mit dem Schreddersymbol).

richtig. aber der frager sagt "RMB -> Markieren -> entferne Sendung von Standardliste". ich würde nicht vermuten, dass er damit 'Markierung entfernen' meint. falls doch: bei mir auch keine cpu-last. so oder so: wenn sich die cpu-last reproduzieren lässt, ist mein rat wie immer: zu dem zeitpunkt einen thread dump machen. dann kann ds10 genau sehen, welche threads aktiv sind und wo die im code rumhängen.

[ds10]

Wenn er ein Untermenü hat, dann heißt das, dass er mehr als eine Markierungsliste eingerichtet hat. Natürlich habe ich beide Varianten überprüft, es ließ sich aber in keiner Konfiguration nachvollziehen. Thread dump könnte natürlich helfen.

[unregistered]

Hallo,

es ist mir eine Ehre, es mit derart kompetenten und mitdenkenden Sachverständigen zu tun zu bekommen!
Also: Untermenü habe ich, weil ich in der Tat mehrere Listen führe. Das nutze ich, um ihnen jeweils eine andere Farbe zuzuordnen. Alle Einträge kommen ZUSÄTZLICH in die Standardliste, von wo aus ich dann "navigiere". Dort kann ich dann über die Farbe grob einschätzen, welche "Güte" die Sendung hat (z.B. "Comedy/Serien" vs. "unbedingt aufzeichnenswerter Langspielfilm", etc...).

Außerdem bin ich sehr froh, daß Ubuntu/Precise x64 nicht grundsätzlich hinderlich ist. Also bin ich optimistisch, daß die Ursache auffindbar sein wird. Der einzige Haken: ich habe seit 15 Jahren nicht mehr entwickelt, war damals auch unter Win. Deshalb habe ich mich seinerzeit zwar auch schon mit ereignisgesteuerter Programmierung herumschlagen dürfen, aber außer meinem Wohlwollen bedeutet das heute eigentlich nichts mehr.

Jedenfalls habe ich den Hinweis "Thread dump" mal gegoogelt und folgende Kommandos daraus destilliert:

Code: Alles auswählen

echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope # ohne dies ging gar nichts
jstack -F `ps -el | awk '/java/ { print $5;}'`

bekomme aber nur

Code: Alles auswählen

Attaching to process ID 1524, please wait...
sun.jvm.hotspot.debugger.NoSuchSymbolException: Could not find symbol "gHotSpotVMTypes" in any of the known library names (libjvm.so, libjvm_g.so, gamma_g)
	at sun.jvm.hotspot.HotSpotTypeDataBase.lookupInProcess(HotSpotTypeDataBase.java:585)
	at sun.jvm.hotspot.HotSpotTypeDataBase.readVMTypes(HotSpotTypeDataBase.java:150)
	at sun.jvm.hotspot.HotSpotTypeDataBase.<init>(HotSpotTypeDataBase.java:85)
	at sun.jvm.hotspot.bugspot.BugSpotAgent.setupVM(BugSpotAgent.java:569)
	at sun.jvm.hotspot.bugspot.BugSpotAgent.go(BugSpotAgent.java:493)
	at sun.jvm.hotspot.bugspot.BugSpotAgent.attach(BugSpotAgent.java:331)
	at sun.jvm.hotspot.tools.Tool.start(Tool.java:163)
	at sun.jvm.hotspot.tools.JStack.main(JStack.java:86)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at sun.tools.jstack.JStack.runJStackTool(JStack.java:136)
	at sun.tools.jstack.JStack.main(JStack.java:102)
Debugger attached successfully.
jstack requires a java VM process/core!

zurück.

Vermutlich wird es am besten sein, wenn ihr mich weiter lotst. Alternativ könnte ich auch alles (Ubuntu-VM + Konfigurationsdaten) zur Verfügung stellen, Es handelt sich ja bloß um (komprimiert) 4 GB. (lol)
Also wohl besser, ich lerne auf meine alten Tage noch ein wenig über die heutgen Werkzeuge...

[ds10]

Alle Einträge kommen ZUSÄTZLICH in die Standardliste

Nun das scheint eine wichtige Information zu sein. Du hast die Sendungen also mindestens zweifach markiert, das habe ich bisher noch nicht getestet.

Thread dump bekommst du, wenn du die tvbrowser.sh von der Konsole aus startest, dann die PID vom Java-Prozess ermitteln und in einer anderen Konsole kill -QUIT PID eingeben. Dann sollte in der Konsole in der die tvbrowser.sh läuft der Thread dump ausgegeben werden.

[unregistered]

Thread dump bekommst du, wenn du die tvbrowser.sh von der Konsole aus startest, dann die PID vom Java-Prozess ermitteln und in einer anderen Konsole kill -QUIT PID eingeben.

Ah! Das ist ja einfach (wenn kein anderer Java-Prozess läuft, reicht demnach

Code: Alles auswählen

pkill -QUIT java

Inzwischen bin ich mega-irritiert, weil es mir gerade selber nicht gelingen will, den vermeldeten "Endlos-Wartezustand" zu reproduzieren. Aber ich bin mir sicher, daß er wieder auftreten wird. Und nun bin ich ja gerüstet, DANN den Thread dump zu liefern. Seltsam nur, daß es mir bereits zur festen Angewohnheit geworden ist, immer wieder den Tabwechsel auszulösen, um dem Phänomen vorzubeugen...

Übrigens eine weitere "Gewohnheit" im Zusammenhang mit TVB, von der ich gerne wüßte, daß ich sie mir abgewöhnen kann:
Bevor ich das VM-Fenster (VirtualBox) resize, schließe ich TVB und öffne es danach wieder, weil - so vermute ich - seit einer nachvollziehbaren Optimierung die Mauskoordinaten nach dem Resize sonst falsch interpretiert werden. (Habs gerade nochmal probiert: Nach dem resize geht das RMB-Menü nicht mehr unter der Maus sondern versetzt auf.)

Anscheinend wertet das Java-Programm die Bildschirmgröße nur noch beim Start aus. Es ist ja auch nicht sehr üblich, "virtuelle Bildschirmgrößen" zu verwenden, wie es die virtualbox-guest-additions erlauben. Allerdings ging genau das noch vor geraumer Zeit. Damals war TVB aber insgesamt langsamer. Also werde ich vielleicht damit leben müssen? Oder bekommt Java Größenänderungen des Anwendungsfensters in einem passenden Event mitgeteilt? Dann sollte dort die entsprechende Initialisierungsroutine nochmal ablaufen.

Jedenfalls danke ich für die Zusammenarbeit und möchte um Verzeihung bitten, daß, was ich reproduzierbar nannte, nun nicht einmal bei mir stabil reproduziert werden kann. <peinlich>
Ich bleibe am Ball...

[ds10]

Anscheinend wertet das Java-Programm die Bildschirmgröße nur noch beim Start aus. Es ist ja auch nicht sehr üblich, "virtuelle Bildschirmgrößen" zu verwenden, wie es die virtualbox-guest-additions erlauben. Allerdings ging genau das noch vor geraumer Zeit. Damals war TVB aber insgesamt langsamer. Also werde ich vielleicht damit leben müssen? Oder bekommt Java Größenänderungen des Anwendungsfensters in einem passenden Event mitgeteilt? Dann sollte dort die entsprechende Initialisierungsroutine nochmal ablaufen.

Also soweit ich weiß, habe ich darauf keinen Einfluss als Programmierer, ich kann zwar die Bildschirmgröße abfragen, aber wo ein Mausklick registriert wird, hängt von Java ab. Im Programm erhält man dann die Koordinaten an dem das Kontextmenü angezeigt werden soll. Wenn die nicht stimmen, dann wüsste ich jetzt nicht, wie ich dafür sorgen kann, dass Java die Positionen richtig ermittelt.

Wenn der Effekt immer auftreten würde unter VMs, dann könnte ich zwar einen Workaround einbauen, aber das halte ich für nicht sinnvoll, da der dann eben auch Fehler verursachen kann, wenn Größenänderungen des Bildschirms von Java doch korrekt verarbeitet werden.

[unregistered]

(...) aber wo ein Mausklick registriert wird, hängt von Java ab. (...)
dann könnte ich zwar einen Workaround einbauen, aber das halte ich für nicht sinnvoll.(...)

Aha. Daß ich da nicht drauf gekommen bin, mag damit zu tun haben, daß ich mir falsche Vorstellungen davon mache, was JAVA eigentlich ist. Aber es leuchtet mir völlig ein. Und es ist auch eine völlig plausible Erklärung dafür, warum meine "reproduzierbare Beobachtung" nun nicht mehr reproduzierbar zu sein scheint. Also eine Verhaltensänderung von TVB auftritt, ohne daß sich das Programm selbst geändert hat. (Erinnert mich übrigens an die Zeiten, als ich selbst mal mit einer 4GL entwickelte. Ich nahm halt fälschlicherweise an, java sei C ähnlicher.) Aber da es ja in einer maschinenunabhängigen virtuellen Umgebung abläuft, ist es naturgemäß von deren Qualität abhängig.

Dummerweise habe ich, der sich angewöhnt hat, Konfigurationsänderungen und Updates meines Computers einem VCS ähnlich zu dokumentieren und zu sichern, dieses Verhalten nicht auf die VirtualBox-VM ausgedehnt, in der TVB läuft, so daß ich nicht mehr nachvollziehen kann, wann dort Java Updates passiert sind.

Und es beunruhigt mich, nun auch vermuten zu müssen, daß das Unmarkieren von falschen Einträgen in der Markierungsliste, das mir gerade vorhin wieder passiert ist, womöglich auch auf vorübergehende Macken der Oracle-Java-Implementation zurück gehen könnte. Jedenfalls werde ich gelegentlich mal daran arbeiten, auch die Konfiguration meiner VM's zu protokollieren, falls es mein Speicherplatz zuläßt (bereits heute 455 GB nur von VM's belegt).

Und falls ich dazu die Zeit finde, versuche ich irgendwann mal, verschiedene Versionen von Java (und ihre Wirkung auf TVB) miteinander zu vergleichen. Jedenfalls stimme ich dem zu, daß es KEINE gute Idee wäre, den Code von TVB DAFÜR zu verändern!

[unregistered]

so oder so: wenn sich die cpu-last reproduzieren lässt, ist mein rat wie immer: zu dem zeitpunkt einen thread dump machen. dann kann ds10 genau sehen, welche threads aktiv sind und wo die im code rumhängen.

Endlich bin ich dieses Vorfalls habhaft geworden! THREAD DUMP:

Code: Alles auswählen

Full thread dump Java HotSpot(TM) 64-Bit Server VM (23.25-b01 mixed mode):

"Timer-0" prio=10 tid=0x00007f56f440c800 nid=0x6ca in Object.wait() [0x00007f57006f4000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x00000000f7ad3a20> (a java.util.TaskQueue)
	at java.util.TimerThread.mainLoop(Timer.java:552)
	- locked <0x00000000f7ad3a20> (a java.util.TaskQueue)
	at java.util.TimerThread.run(Timer.java:505)

"Keep-Alive-SocketCleaner" daemon prio=10 tid=0x00007f56e80d0000 nid=0x6aa in Object.wait() [0x00007f56dab52000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x00000000f6c97120> (a sun.net.www.http.KeepAliveStreamCleaner)
	at sun.net.www.http.KeepAliveStreamCleaner.run(KeepAliveStreamCleaner.java:101)
	- locked <0x00000000f6c97120> (a sun.net.www.http.KeepAliveStreamCleaner)
	at java.lang.Thread.run(Thread.java:724)

"Store settings periodically" prio=10 tid=0x00007f56fc0be000 nid=0x6a6 waiting on condition [0x00007f56da545000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
	at java.lang.Thread.sleep(Native Method)
	at tvbrowser.TVBrowser$3.run(TVBrowser.java:706)

"pool-1-thread-1" prio=10 tid=0x00007f56fc0bd000 nid=0x6a5 waiting on condition [0x00007f56daa51000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
	at java.lang.Thread.sleep(Native Method)
	at tvbrowser.core.plugin.PluginProxyManager$5.run(PluginProxyManager.java:1323)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:724)

"TimerQueue" daemon prio=10 tid=0x00007f56f42c0800 nid=0x69f waiting on condition [0x00007f56db7eb000]
   java.lang.Thread.State: TIMED_WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000000f5fc8458> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082)
	at java.util.concurrent.DelayQueue.take(DelayQueue.java:220)
	at javax.swing.TimerQueue.run(TimerQueue.java:171)
	at java.lang.Thread.run(Thread.java:724)

"DestroyJavaVM" prio=10 tid=0x00007f5704009000 nid=0x648 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"AWT-EventQueue-0" prio=10 tid=0x00007f57045c5800 nid=0x68d waiting on condition [0x00007f57005f3000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000000f58f73e0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
	at java.awt.EventQueue.getNextEvent(EventQueue.java:543)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:211)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)

"AWT-Shutdown" prio=10 tid=0x00007f5704496000 nid=0x68c in Object.wait() [0x00007f57007f5000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x00000000f5a35e18> (a java.lang.Object)
	at java.lang.Object.wait(Object.java:503)
	at sun.awt.AWTAutoShutdown.run(AWTAutoShutdown.java:287)
	- locked <0x00000000f5a35e18> (a java.lang.Object)
	at java.lang.Thread.run(Thread.java:724)

"AWT-XAWT" daemon prio=10 tid=0x00007f5704278800 nid=0x65a runnable [0x00007f57085e6000]
   java.lang.Thread.State: RUNNABLE
	at sun.awt.X11.XToolkit.waitForEvents(Native Method)
	at sun.awt.X11.XToolkit.run(XToolkit.java:627)
	at sun.awt.X11.XToolkit.run(XToolkit.java:591)
	at java.lang.Thread.run(Thread.java:724)

"Java2D Disposer" daemon prio=10 tid=0x00007f5704256800 nid=0x659 in Object.wait() [0x00007f57086e7000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x00000000f5915c70> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
	- locked <0x00000000f5915c70> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)
	at sun.java2d.Disposer.run(Disposer.java:145)
	at java.lang.Thread.run(Thread.java:724)

"Service Thread" daemon prio=10 tid=0x00007f570410d800 nid=0x64f runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread1" daemon prio=10 tid=0x00007f570410b000 nid=0x64e waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread0" daemon prio=10 tid=0x00007f5704109000 nid=0x64d waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" daemon prio=10 tid=0x00007f5704106800 nid=0x64c waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" daemon prio=10 tid=0x00007f57040b9800 nid=0x64b in Object.wait() [0x00007f56fbefd000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x00000000f5915ec0> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
	- locked <0x00000000f5915ec0> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)
	at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:189)

"Reference Handler" daemon prio=10 tid=0x00007f57040b7000 nid=0x64a in Object.wait() [0x00007f56fbffe000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x00000000f5915f58> (a java.lang.ref.Reference$Lock)
	at java.lang.Object.wait(Object.java:503)
	at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133)
	- locked <0x00000000f5915f58> (a java.lang.ref.Reference$Lock)

"VM Thread" prio=10 tid=0x00007f57040af800 nid=0x649 runnable 

"VM Periodic Task Thread" prio=10 tid=0x00007f5704118800 nid=0x650 waiting on condition 

JNI global references: 2711

Heap
 def new generation   total 37888K, used 20253K [0x00000000f2e00000, 0x00000000f5710000, 0x00000000f58a0000)
  eden space 33728K,  59% used [0x00000000f2e00000, 0x00000000f41b9f38, 0x00000000f4ef0000)
  from space 4160K,   1% used [0x00000000f4ef0000, 0x00000000f4efd4d0, 0x00000000f5300000)
  to   space 4160K,   0% used [0x00000000f5300000, 0x00000000f5300000, 0x00000000f5710000)
 tenured generation   total 83996K, used 57972K [0x00000000f58a0000, 0x00000000faaa7000, 0x00000000fae00000)
   the space 83996K,  69% used [0x00000000f58a0000, 0x00000000f913d198, 0x00000000f913d200, 0x00000000faaa7000)
 compacting perm gen  total 29184K, used 29023K [0x00000000fae00000, 0x00000000fca80000, 0x0000000100000000)
   the space 29184K,  99% used [0x00000000fae00000, 0x00000000fca57fe0, 0x00000000fca58000, 0x00000000fca80000)
No shared spaces configured.