JDK-6899078 : potential deadlock and performance issue in freeing strike resources with D3D pipeline
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 7
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2009-11-06
  • Updated: 2022-06-28
  • Resolved: 2009-11-25
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
6u21Fixed 7 b77Fixed
Related Reports
Relates :  
Relates :  
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.

EVALUATION We can reduce the amount of thread context switching needed by polling for any other strikes once we are on the toolkit thread. Also the source of potential deadlock is unneeded code and we can remove it.