xkcd: Wisdom of the Ancients 
Aber mal ganz allgemein: Du suchst anscheinend nach einem „Speicherleck“, und scheinst dich zu fragen, wo irgendwelche char[] und int[] arrays herkommen.
Ich lehne mich damit zwar weit aus dem Fenster, postuliere aber mal: Das hat mit dem Problem nichts zu tun (*)
Das Problem sind ja offenbar irgendwelche Handles. Und diese Handles werden „von AWT/Swing“ erstellt, um (vage) „irgendwelche UI-Objekte“ abzubilden. Also, du könntest 10 Millionen char[]-Arrays erzeugen, aber das hätte keinen Einfluss auf die Handles.
Ich habe mal dieses Testprogramm erstellt.
ACHTUNG: Begleitenden Text lesen!!!
[spoiler]
Das Programm erstellt dumm-dreist (oder, in schönerer Formulierung: „Automatisiert“ 
) etliche Dialog-Instanzen die mit etlichen Labels gefüllt sind (mit JDialog würde es auch gehen, aber langsamer).
Das stellt Windows ggf. auf eine harte Probe. Die Taskleiste läuft irgendwann über. Das ist nicht „schlimm“, aber … sicherheitshalber sollte man mal lieber keine anderen, „wichtigen“ Anwendungen offen haben
Im Taskmanager kann man sich ansehen, wie die Anzahl der „Benutzerobjekte“ schneller hochgeht, als ein Lämmchen mit dem Schwanz wedelt.
Und wenn die 10000 erreicht sind, kommt:
Exception in thread "AWT-EventQueue-0" java.lang.InternalError: Der aktuelle Prozess verwendet alle Handles der zulässigen Höchstanzahl für Window Managerobjekte.
at sun.awt.windows.WToolkit.eventLoop(Native Method)
at sun.awt.windows.WToolkit.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
package bytewelt;
import java.awt.Dialog;
import java.awt.GridLayout;
import java.awt.Label;
import java.awt.Window;
import javax.swing.SwingUtilities;
public class HandleLeakTest
{
public static void main(String[] args) throws InterruptedException
{
int i = 0;
while (true)
{
int n = i;
System.out.println(i);
SwingUtilities.invokeLater(new Runnable()
{
@Override
public void run()
{
spawn(n);
}
});
i++;
if (i % 1000 == 0)
{
Thread.sleep(10000);
}
}
}
private static void spawn(int i)
{
Dialog d = new Dialog((Window)null);
d.setLayout(new GridLayout(10,10));
for (int j=0; j<100; j++)
{
d.add(new Label(String.valueOf(i)));
}
d.pack();
int x = i % 1000;
int y = i / 1000;
d.setLocation(x, y);
d.setVisible(true);
}
}
[/spoiler]
Und das legt zumindest die Vermutung nahe, dass dort irgendwas nicht richtig aufgeräumt wird. Genauer zu analysieren, WER denn diese Handles an sich reißt, kann natürlich schwierig sein - es ist wohl nicht so offensichtlich wie in dem Beispiel, wo man sagen kann: Der Dialog!!!
(*) Deswegen das Sternchen neben der Aussage „Das hat mit dem Problem nichts zu tun“: Die Suche nach einem „Speicherleck“ sollte sich bestenfalls auf die Klassen konzentieren, die solche „Handles“ verwenden. Leider kann ich nicht mit Bestimmtheit sagen, welche das sind. Irgendwelche GUI-Komponenten - klar. Aber welche noch? Im schlimmsten Fall gibt es gar kein „Leck“ in diesem Sinne: Es KÖNNTE (nur ZUM BEISPIEL!) sein, dass das freigeben der Handles irgendwie mit dem „finalize()“-Aufruf einzelner Klassen verbunden ist. Und wenn der GC keinen Grund hat, die wegzuräumen, KÖNNTEN sie am Leben bleiben und Handles blockieren. (Im allerschlimmsten (oder allerbesten?) Fall ist es auch ein Bug in Swing/AWT, aber … alles hier ist recht spekulativ, deswegen kann man das erstmal nicht „annehmen“…)
