2 lästige Details im Markierungs-Tab

[uzi]

hm. also wenn ich das richtig sehe, sind die einzigen threads, die NICHT warten und damit cpu verbrauchen können
- "AWT-XAWT" daemon prio=10 tid=0x00007f5704278800 nid=0x65a runnable [0x00007f57085e6000]
- "Service Thread" daemon prio=10 tid=0x00007f570410d800 nid=0x64f runnable [0x0000000000000000]

beide sind imho nicht vom tvb direkt, sondern irgendwas internes der jvm. insbesondere der erste ist mir suspekt. der hat irgendwas mit x11 zu tun, steht auf runnable, hängt aber in einer methode namens waitForEvents. das ist jetzt zwar alles glaskugellesen, sieht aber für mich so aus, als würde das teil laufen/cpu verbrauchen, obwohl es eigentlich auf eine condition warten sollte. kann natürlich sein, dass gerade in dem moment, wo du den dump gezogen hast auch ein event ausgelöst wurde oder vielleicht auch der dump grundsätzlich ein x11-event auslöst. keine ahnung. wie dem auch sei - ich vermute, da wird ds10 wenig machen können. andererseits steckt er viel tiefer in der materie, als ich. vielleicht hast du glück .

[unregistered]

Au weia, das klingt ja nicht gut. Als ich vor Jahren mal "Experte" für eine VM war, gelang es nur unter größter Mühe, um deren Fehler/Bugs herum zu programmieren. Und Java hatte mich als Programmierumgebung schon vor vielen Jahren abgeschreckt!

Umso löblicher, was unter diesen erschwerten Bedingungen geglückt ist. Ich hatte ja keine Vorstellung davon, welches Leiden das mit sich bringen kann.

OFF-TOPIC: Auf meine alten Tage versuche ich ohnehin nur noch eine Programmiersprache zu erlernen: Python

Daß die TVB-Software bereits an die Grenzen von Java stößt, fällt mir dennoch zu glauben schwer. Zumindest hörte ich von größeren Projekten, die sich dessen bedienen und die nach meiner Kenntnis nicht mit Macken der JVM kämpfen müssen.

Naja - ich schrieb ja schon in der Einleitung, daß ich mit beiden "Fehlern" leben kann; wollte nur darauf hinweisen... manchmal können solche Beobachtungen den kundigen Entwickler auf eine gute Fährte bringen... wenn nicht, ist halt Pech.

[ds10]

Das Problem kann aber trotzdem vom Plugin ausgelöst werden, da dort eine weitere Verarbeitung in den Event-Thread geschoben wird.
Eine andere Funktion eines anderen Tabs macht womöglich gerade das Gleiche und schon wartet der Event-Thread gegenseitig.

Das Aufrufen eines anderen Tabs führt dann dazu, dass eine der einstellten Aufgaben abgearbeitet wird und somit wird die andere auch frei abgearbeitet zu werden. Letztendlich kann sowas immer passieren, wenn parallel verarbeitet wird.

Und letztendlich hat es nichts mit der Größe eines Projektes zu tun, sondern damit, was ein Programm macht und wie es arbeitet.

[unregistered]

Danke, Bodo (?), für diese Verständnishilfe.
Oh, ja: Parallele Programmierung - gab es zu meiner Zeit noch kaum und ich staune immer wieder, wenn ich ihr begegne (Schachprogramme, Kernel,...). Diese Techniken sind für mich noch immer neu und IPC/Semaphoren erstmal richtig ins Hirn zu kriegen, stelle ich mir auch nicht einfach vor.

[uzi]

Und Java hatte mich als Programmierumgebung schon vor vielen Jahren abgeschreckt!

Daß die TVB-Software bereits an die Grenzen von Java stößt, fällt mir dennoch zu glauben schwer.

also ich mag java (größtenteils). ich bin kein fan des aktuellen scriptsprachen-trends. dass javascript so einen aufschwung erlebt, macht mir eher sorgen. das gleiche gilt für 'scriptigere' sprachen auf der jvm (groovy, um ein beispiel zu nennen, mit dem ich mich auseinandergesetzt habe). wie auch immer, java hat per se erstmal keine grenzen. oder um es exakter auszudrücken: java ist turing-vollständig. aber natürlich können in der jvm bugs stecken und genauso im tvb selbst. oder in einer der darunterliegenden ebenen (x11 in diesem fall). und dann kommt noch die ganze komplexität des multithreadings dazu.

langer rede kurzer sinn: java ist trotz all der unkenrufe imho eine gute und performante (!) programmiersprache und die jvm eine hervorragende idee (write once, run anywere). potenzial nach oben gibt es immer (gerade im bereich multithreading), aber nach meiner erfahrung überwiegen die vorteile von java. ich kenne schlicht keine bessere programmiersprache. und keine bessere vm, als die jvm . hängt natürlich auch viel vom eigenen geschmack ab. meine devise ist: nicht das programmieren ist teuer, sondern die wartung. oder anders ausgedrückt: je weniger varianten es in einer programmiersprache gibt, aufgabe x zu erledigen, desto besser. denn desto einfacher ist es für einen 'neuen' den code zu lesen. und da versagen nach meiner erfahrung alle 'hippen' sprachen. die sind zwar schnell hingeklatscht, aber beschissen zu warten. leider hechelt java dem tren hinterher. ich sag nur 'autoboxing' .

[uzi]

Das Problem kann aber trotzdem vom Plugin ausgelöst werden, da dort eine weitere Verarbeitung in den Event-Thread geschoben wird.
Eine andere Funktion eines anderen Tabs macht womöglich gerade das Gleiche und schon wartet der Event-Thread gegenseitig.

das wäre das klassische deadlock-szenario und sollte eigentlich keine 100% cpu-last auslösen, sondern ein 'hängendes' programm...

[ds10]

Danke, Bodo (?), für diese Verständnishilfe.

Ne, René, Bodo ist schon lange nicht mehr hier.

Da ich gerade an der Website programmiere kann ich sagen, dass ich mich erst schwer wieder in PHP einarbeiten musste. Es funktioniert halt so anders als Java und dabei muss ich auch feststellen, dass mir Java einfach besser gefällt, allein dass die Variablen feste Typen haben zwingt den Programmierer sauberer zu arbeiten. Verhindert aber von Beginn an mögliche Fehler.

Und wenn man Java kann, dann kann man auch recht schnell andere Hochsprachen erlernen. Assembler ist dann nochmal eine andere Nummer.

[unregistered]

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.

Hi, ich bins nochmal.
Derzeit betreibe ich die RC1 und habe das oben beschriebene Problem zum Zwecke des Thread dumps wieder beobachtet. Interessant dabei: Sobald ich in das Shell-Fenster wechselte, um den Dump anzustoßen, ging die CPU-Belastung zurück. Um also an den folgenden Dump zu gelangen, setzte ich ein sleep vor den pkill Befehl und wechselte zurück zu TVB. (Die CPU-Last schoß sofort wieder hoch!)

Code: Alles auswählen

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

"Image Fetcher 2" daemon prio=10 tid=0x00007f019c866000 nid=0x1064 in Object.wait() [0x00007f01b4bfb000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x00000000f59b20c8> (a java.util.Vector)
	at sun.awt.image.ImageFetcher.nextImage(ImageFetcher.java:147)
	- locked <0x00000000f59b20c8> (a java.util.Vector)
	at sun.awt.image.ImageFetcher.fetchloop(ImageFetcher.java:200)
	at sun.awt.image.ImageFetcher.run(ImageFetcher.java:169)

"Image Fetcher 1" daemon prio=10 tid=0x00007f019c868800 nid=0x1063 in Object.wait() [0x00007f018810d000]
   java.lang.Thread.State: BLOCKED (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x00000000f59b20c8> (a java.util.Vector)
	at sun.awt.image.ImageFetcher.nextImage(ImageFetcher.java:147)
	- locked <0x00000000f59b20c8> (a java.util.Vector)
	at sun.awt.image.ImageFetcher.fetchloop(ImageFetcher.java:200)
	at sun.awt.image.ImageFetcher.run(ImageFetcher.java:169)

"Image Fetcher 0" daemon prio=10 tid=0x00007f019c86e000 nid=0x1062 in Object.wait() [0x00007f0187f0b000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x00000000f59b20c8> (a java.util.Vector)
	at sun.awt.image.ImageFetcher.nextImage(ImageFetcher.java:147)
	- locked <0x00000000f59b20c8> (a java.util.Vector)
	at sun.awt.image.ImageFetcher.fetchloop(ImageFetcher.java:200)
	at sun.awt.image.ImageFetcher.run(ImageFetcher.java:169)

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

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

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

"pool-1-thread-1" prio=10 tid=0x00007f01a80c4800 nid=0x6bf waiting on condition [0x00007f0186f8a000]
   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=0x00007f019c280000 nid=0x6b3 waiting on condition [0x00007f0187e0a000]
   java.lang.Thread.State: TIMED_WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000000f5f3e790> (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=0x00007f01b0009000 nid=0x668 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"AWT-EventQueue-0" prio=10 tid=0x00007f01b05bf800 nid=0x6a7 runnable [0x00007f01b43b2000]
   java.lang.Thread.State: RUNNABLE
	at sun.awt.image.ToolkitImage.getProperty(ToolkitImage.java:169)
	at javax.swing.ImageIcon.<init>(ImageIcon.java:278)
	at util.ui.PictureAreaIcon.<init>(PictureAreaIcon.java:107)
	at util.ui.ProgramPanel.setProgram(ProgramPanel.java:498)
	at util.ui.ProgramPanel.setProgram(ProgramPanel.java:426)
	at util.ui.ProgramListCellRenderer.getListCellRendererComponent(ProgramListCellRenderer.java:184)
	at javax.swing.plaf.basic.BasicListUI.updateLayoutState(BasicListUI.java:1361)
	at javax.swing.plaf.basic.BasicListUI.maybeUpdateLayoutState(BasicListUI.java:1311)
	at javax.swing.plaf.basic.BasicListUI.getPreferredSize(BasicListUI.java:578)
	at javax.swing.JComponent.getPreferredSize(JComponent.java:1660)
	at javax.swing.ScrollPaneLayout.layoutContainer(ScrollPaneLayout.java:790)
	at java.awt.Container.layout(Container.java:1503)
	at java.awt.Container.doLayout(Container.java:1492)
	at java.awt.Container.validateTree(Container.java:1688)
	at java.awt.Container.validate(Container.java:1623)
	- locked <0x00000000f5954530> (a java.awt.Component$AWTTreeLock)
	at javax.swing.RepaintManager$2.run(RepaintManager.java:679)
	at javax.swing.RepaintManager$2.run(RepaintManager.java:677)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
	at javax.swing.RepaintManager.validateInvalidComponents(RepaintManager.java:676)
	at javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1646)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251)
	at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:733)
	at java.awt.EventQueue.access$200(EventQueue.java:103)
	at java.awt.EventQueue$3.run(EventQueue.java:694)
	at java.awt.EventQueue$3.run(EventQueue.java:692)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:703)
	at util.ui.textcomponentpopup.TextComponentPopupEventQueue.dispatchEvent(TextComponentPopupEventQueue.java:55)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
	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=0x00007f01b05be800 nid=0x6a6 in Object.wait() [0x00007f01b42b3000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x00000000f5a263c8> (a java.lang.Object)
	at java.lang.Object.wait(Object.java:503)
	at sun.awt.AWTAutoShutdown.run(AWTAutoShutdown.java:287)
	- locked <0x00000000f5a263c8> (a java.lang.Object)
	at java.lang.Thread.run(Thread.java:724)

"AWT-XAWT" daemon prio=10 tid=0x00007f01b0273800 nid=0x687 runnable [0x00007f01b5123000]
   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=0x00007f01b024f000 nid=0x686 in Object.wait() [0x00007f01b5224000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x00000000f58f2c48> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
	- locked <0x00000000f58f2c48> (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=0x00007f01b010d800 nid=0x670 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

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

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

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

"Finalizer" daemon prio=10 tid=0x00007f01b00b9800 nid=0x66b in Object.wait() [0x00007f01a7efd000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x00000000f58f2e98> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
	- locked <0x00000000f58f2e98> (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=0x00007f01b00b7000 nid=0x66a in Object.wait() [0x00007f01a7ffe000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x00000000f58f2f30> (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 <0x00000000f58f2f30> (a java.lang.ref.Reference$Lock)

"VM Thread" prio=10 tid=0x00007f01b00af800 nid=0x669 runnable 

"VM Periodic Task Thread" prio=10 tid=0x00007f01b0118800 nid=0x671 waiting on condition 

JNI global references: 10462

Heap
 def new generation   total 37312K, used 5713K [0x00000000f2e00000, 0x00000000f5670000, 0x00000000f58a0000)
  eden space 33216K,  17% used [0x00000000f2e00000, 0x00000000f3388f90, 0x00000000f4e70000)
  from space 4096K,   1% used [0x00000000f5270000, 0x00000000f527b558, 0x00000000f5670000)
  to   space 4096K,   0% used [0x00000000f4e70000, 0x00000000f4e70000, 0x00000000f5270000)
 tenured generation   total 82680K, used 71453K [0x00000000f58a0000, 0x00000000fa95e000, 0x00000000fae00000)
   the space 82680K,  86% used [0x00000000f58a0000, 0x00000000f9e674f0, 0x00000000f9e67600, 0x00000000fa95e000)
 compacting perm gen  total 29888K, used 29679K [0x00000000fae00000, 0x00000000fcb30000, 0x0000000100000000)
   the space 29888K,  99% used [0x00000000fae00000, 0x00000000fcafbee8, 0x00000000fcafc000, 0x00000000fcb30000)
No shared spaces configured.

04:57:12 INFO: Channel Settings (day light saving time corrections/icons)
04:57:12 INFO: Storing window size and location
04:57:12 INFO: Storing settings
04:57:12 INFO: Storing window settings

Hoffentlich ist dies zu irgend etwas von Nutzen.

[uzi]

wie oben ist auch hier wieder (unter anderem) der hier aktiv:

Code: Alles auswählen

"AWT-XAWT" daemon prio=10 tid=0x00007f01b0273800 nid=0x687 runnable [0x00007f01b5123000]
   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)

ich find den verdächtig und dass die cpu-last nur dann da ist, wenn du das fenster aktiv hast, ist nur wasser auf meine mühlen.

im vergleich zum ersten dump ist die awt-event-queue dazugekommen. wenn ich dich richtig verstehe, hattest du beim ersten dump gar nicht die cpu-last, weil du das fenster gewechselt hast. gut möglich, dass die event-queue angehalten wird, wenn das fenster nicht aktiv ist. kann aber auch sein, dass die queue immer nur dann aufwacht, wenn es events zu verarbeiten gibt. keine ahnung. wäre jedenfalls auch ne möglichkeit, dass da die last herkommt.

[unregistered]

wenn ich dich richtig verstehe, hattest du beim ersten dump gar nicht die cpu-last, weil du das fenster gewechselt hast.

Das kann ich inzwischen nicht mehr verifizieren/falsifizieren, hauptsächlich, weil inzwischen ein Java-Update von Oracle gekommen ist, und ich das einfach mal eingespielt habe. Und von deren Qualitätssicherung muß man wohl nicht allzuviel halten. Da reift die Banane schon mal beim Kunden... (der dafür mitunter ja auch noch Geld bezahlt... ganz wie bei MS).

Dazu könnte ich mich noch breiter auslassen, aber das gehört sicher nicht hierher, schon gar nicht, wo doch René einen Super-Job macht, und das AUS LIEBE !!!
Ach, die Welt könnte so schön sein...

Außerdem: der Bug #2 (Resize-Folgen) war DEFINITIV früher nicht vorhanden. Ich kann nur nicht mehr sagen, wann die Änderung kam. Offenbar war meine (unschuldige) Vermutung falsch, es sei ein Nebeneffekt einer Optimierung in TVB gewesen. Aber vielleicht ist die Optimierung ja auch in Java passiert, und Entwickler testen halt selten, die Bildschirmauflösung zu verändern, WÄHREND ein Programm läuft...

In früheren Zeiten würde ich das dann wenigstens an den Verursacher gemeldet haben, so daß man sich kümmern kann. Aber Oracle hat - im Gegensatz zu Sun, das Java ursprüglich entwickelt hat - die Erlaubnis, Reports zu machen an Bedingungen geknüpft, die ich nicht erfülle, solange ich keinen (zahlenden) Vertrag mit denen mache.

Also: falls es sich dabei wirklich nicht um Nebeneffekte des TVB-Codes handelt, bin ich mit meinem Latein am Ende. Und so zumindest habe ich René verstanden.