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.
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.
| JDK 6 | JDK 7 |
|---|---|
6u21Fixed  |
7 b77Fixed |
Related Reports
|
Relates :
|
|
|
Relates :
|
Description
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.
Comments
|