JXMapKit/-Viewer extremely slow as webstartable - where to start digging?

Question

Just tried to add some swingx-ws components to the overall swinglabs demos - and noticed that a simple JXMapKit/-Viewer is orders of magnitude slower to load the tiles in the webstartable compared to loading locally.

Rather lost on where I should start looking (ui updates seem to be on the EDT, though might need a closer look):

• anybody else experiencing the different loading times?
• any guess on what might be the reason?
• how to debug a webstartable?

The code is rather straightforward (to run locally, you'll need swingx and swingx-ws:

public class WSDemo {

    private JComponent createContent() {
        JComponent content = new JPanel();
        content.setLayout(new BorderLayout());

        content.add(createMapKit()); 
        return content;
    }

    protected JComponent createMapKit() {
        final int max = 17;
        TileFactoryInfo info = new TileFactoryInfo(1, max - 2, max, 256, true,
                true, // tile size is 256 and x/y orientation is normal
                "http://tile.openstreetmap.org",// 5/15/10.png",
                "x", "y", "z") {
            public String getTileUrl(int x, int y, int zoom) {
                zoom = max - zoom;
                String url = this.baseURL + "/" + zoom + "/" + x + "/" + y
                        + ".png";
                return url;
            }

        };
        DefaultTileFactory tf = new DefaultTileFactory(info);
        tf.setThreadPoolSize(1);
        final JXMapKit kit = new JXMapKit();
        kit.setTileFactory(tf);
        kit.setZoom(10);
        kit.setAddressLocation(new GeoPosition(51.5, 0));
        kit.getMainMap().setDrawTileBorders(true);
        return kit;
    }

    public static void main(String[] args) {
        SwingUtilities.invokeLater(new Runnable() {
            public void run() {
                JFrame frame = new JFrame("");
                frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
                frame.add(new WSDemo().createContent());
                frame.setLocationByPlatform(true);
                frame.setSize(400, 400);
                frame.setVisible(true);
            }
        });
    }

}

Edit:

seems like it's somehow related to permission checking in the web context: profiling shows that the whole connection call stack is different (not overly surprising) and takes ages. Giving up for now ..

Edit 2:

There seem to be 2 separate issues

• the somewhat longer time it takes to open the connections for loading the tiles in the security restricted context, that is the hotspot in JavaWebStartSecurity.checkConnect(String, int), as @Howard already noted.
• a rather weird blocking of the EDT that seems to happen only if the mapKit is used in a SingleFrameApplication (of BSAF)

To reproduce the blocking, run the SimpleWSDemoApp, wait until the map is visible (takes some time, that's the first issue) then use the mouse to move the zoom thumb quickly up and down: the ui is completely blocked. Doing the same on the plain frame (the reference on top) has the initial loading wait, but couldn't ever reproduce the blocking.

The weird thingy (to me) is what blocks the EDT, from the thread dump of VisualVM:

"AWT-EventQueue-0" prio=6 tid=0x063d3000 nid=0x1468 waiting for monitor entry [0x05efe000]
   java.lang.Thread.State: BLOCKED (on object monitor)
    at java.security.Permissions.implies(Unknown Source)
    - waiting to lock <0x29f7b118> (a java.security.Permissions)
    at sun.security.provider.PolicyFile.implies(Unknown Source)
    at java.security.ProtectionDomain.implies(Unknown Source)
    at java.security.AccessControlContext.checkPermission(Unknown Source)
    at java.security.AccessController.checkPermission(Unknown Source)
    at java.lang.SecurityManager.checkPermission(Unknown Source)
    at java.lang.SecurityManager.checkSystemClipboardAccess(Unknown Source)
    at java.awt.event.InputEvent.canAccessSystemClipboard(Unknown Source)
    at java.awt.event.InputEvent.<init>(Unknown Source)
    at java.awt.event.MouseEvent.<init>(Unknown Source)
    at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
    at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
    at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
    at java.awt.Container.dispatchEventImpl(Unknown Source)
    at java.awt.Window.dispatchEventImpl(Unknown Source)
    at java.awt.Component.dispatchEvent(Unknown Source)
    at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
    at java.awt.EventQueue.access$200(Unknown Source)
    at java.awt.EventQueue$3.run(Unknown Source)
    at java.awt.EventQueue$3.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
    at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
    at java.awt.EventQueue$4.run(Unknown Source)
    at java.awt.EventQueue$4.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)

that is dragging the mouse kicks in checking permission for clipboard access ...

Answer 1

A Web Start app is also a JVM process so you can try to profile it with VisualVM (this entry describes how to do that). It's also worth to profile both applications with VisualVM and compare JVM settings like heap size, JIT compiler differences. I think that a Web Start application runs with client compiler, which is slower by means of produced native code than a server compiler.