Felix>I tried it out and the resuls are promising.
Just one more finding:
SwingUtilities.invokeLater and SwingUtilities.isEventDispatchThread involve
global synchronization (that is java 1.8) as follows:
at sun.awt.AppContext.get(Unknown Source)
- waiting to lock <0x00000000c0003d30> (a java.util.HashMap)
at sun.awt.SunToolkit.getSystemEventQueueImplPP(Unknown Source)
at sun.awt.SunToolkit.getSystemEventQueueImplPP(Unknown Source)
at sun.awt.SunToolkit.getSystemEventQueueImpl(Unknown Source)
at java.awt.Toolkit.getEventQueue(Unknown Source)
at java.awt.EventQueue.isDispatchThread(Unknown Source)
at javax.swing.SwingUtilities.isEventDispatchThread(Unknown Source)
at org.apache.jmeter.util.JMeterUtils.runSafe(JMeterUtils.java:1373)
It does look like an AWT issue, however we'd better workaround that somehow.
For "isEventDispatchThread" we can use "if )currentThread instanceof
JMeterThread) { 100% non-event dispatch thread}".
For invokeLater I think we can cache
Toolkit.getDefaultToolit().getSystemEventQueue() and then use
eventQueue.postEvent(new InvocationEvent(toolkit, runnable)).
That should be a trivial change to improve scalability and responsiveness.
Of course, it would still make sense to coalesce events (e.g. drop old log
records) before they reach awt (I mean avoid lots of eventQueue.postEvent
calls by buffering the events before they got sent to swing) since awt's
eventQueue does not scale.
Vladimir
