The 6u10+ JDK D3D pipeline needs to free glyphs on the Toolkit thread
(see bug 6705443 for more details). This means having to switch
over to that thread from the disposer thread, one time for each strike.
And because this needs to happen synchronously, and involves calling
into native code to do so, it would seem relatively expensive.
This hasn't been seen as a performance problem in most apps but an
app that generates many (as in tens of thousands) strikes over
a short period of time, it can show up in measurements.

In addition there's a call to dispose() in Font2D.java.
When the 6u10 code was added this became a source of potential deadlock.