OK, I figured it out.

Short answer

Just wrap the swing content inside a JPanel (or some other JComponent). Then only ever call SwingNode.setContent() once to add the wrapper. When you need to update the swing content, call removeAll() on your wrapper and then add() with the appropriate content.

Long Answer

Thanks to the suggestion in this answer: https://stackoverflow.com/a/66283491/2423283 I was able to determine that the leak is caused by GlassStage which is a non-api class which among other things, keeps a static list of all implementations of GlassStage. The content of a SwingNode gets managed by an instance of EmbeddedScene which is a subtype of GlassStage.

Items are removed from the static list when close() is called on them. SwingNode.setContent() does not close any pre-existing content, but Container.removeAll() does.

Working code

Here's an example of the fixed code:

public class LeakDemoFixed extends Application {

    //Keep week references to all panels that we've ever generated to see if any
    //of them get collected.
    private Collection<WeakReference<JPanel>> panels = new CopyOnWriteArrayList<>();
    
    @Override
    public void start(Stage primaryStage) throws Exception {
        
        SwingNode node = new SwingNode();
        
        //These 2 lines were added
        JComponent swingContent = new JPanel();
        node.setContent(swingContent);
        
        Pane root = new Pane();
        root.getChildren().add(node);
        
        //Kick off a thread that repeatedly creates new JPanels and resets the swing node's content
        new Thread(() -> {
            
            while(true) {
                
                //Lets throw in a little sleep so we can read the output
                try {
                    Thread.sleep(500);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                
                SwingUtilities.invokeLater(() -> {
                    JPanel panel = new JPanel();
                    panels.add(new WeakReference<>(panel));
                    //Removed the line below
                    //node.setContent(panel);
                    
                    //Added these 2 lines
                    swingContent.removeAll();
                    swingContent.add(panel);
                });
                
                System.out.println("Panels in memory: " + panels.stream().filter(ref -> ref.get() != null).count());
                
                //I know this doesn't guarantee anything, but prompting a GC gives me more confidence that this
                //truly is a bug.
                System.gc();
            }
            
        }).start();
        
        primaryStage.setScene(new Scene(root, 100, 100));
        
        primaryStage.show();
        
    }
    
    public static void main(String[] args) {
        launch(args);
    }
}

I didn't reached this question before but here is what I've done to correct the issue. I would like this fix to be integrated into JavaFX for Java8 but I don't know how to get this done and they closed the issue (because of duplicate)

https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8284352

The problem is due to the JLightweightFrame never being released by de SwingNodeDisposer.

The SwingNodeDisposer holds an hard pointer to the JLightweightFrame that prevents its suppression.

I have modified the SwingNode.setContentImpl() function to use a WeakReference instead of an hard pointer and now memory is properly released.

...

    WeakReference<JLightweightFrame> lwFramePtr = new WeakReference<JLightweightFrame>(lwFrame);
    SwingNodeDisposer disposeRec = new SwingNodeDisposer(lwFramePtr);
    Disposer.addRecord(this, disposeRec);

...

This gives good results without having the need to use a single JPanel or to encapsulate it inside a WeakReference.

Take a snapshot with visualvm then analyze GC roots with with Eclipse Memory Analyzer (MAT) http://www.eclipse.org/mat/