-
Bug
-
Resolution: Fixed
-
P3
-
1.4.2
-
b67
-
x86
-
windows_xp
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-2132530 | 5.0u7 | Philip Race | P3 | Resolved | Fixed | b01 |
FULL PRODUCT VERSION :
A DESCRIPTION OF THE PROBLEM :
We have problem with heavy report rendering in server environment (8+ threads, 4 CPUs). We don't get 100% cpu usage. Threads are blocked about 70% of the time.
We had this problem in 1.4.2 because of bug 4641861. I was expecting that upgrading to 1.5.0 would resolve the issue. But it didn't.
In 1.4.2, threads were blocked for NativeFontWrapper's synchronized static native methods (which no longer exist in 1.5). Now they are waiting in FileFontStrike.getGlyphOutlineBounds for access to the boundsMap field.
I think use of a ReadWriteLock for access to the boundsMap (instead of simply synchronizing on it) would greatly improve the scalibility. Currently threads that are only reading the map block each other which is not necessary.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
You'll need an SMP machine (not hyper threaded). Run at least twice the number of CPUs threads. Each thread should use something like TextLayout to calculate the boundaries of a string displayed in a font.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
100% CPU usage
ACTUAL -
~30%-50% CPU usage
REPRODUCIBILITY :
This bug can be reproduced always.
A DESCRIPTION OF THE PROBLEM :
We have problem with heavy report rendering in server environment (8+ threads, 4 CPUs). We don't get 100% cpu usage. Threads are blocked about 70% of the time.
We had this problem in 1.4.2 because of bug 4641861. I was expecting that upgrading to 1.5.0 would resolve the issue. But it didn't.
In 1.4.2, threads were blocked for NativeFontWrapper's synchronized static native methods (which no longer exist in 1.5). Now they are waiting in FileFontStrike.getGlyphOutlineBounds for access to the boundsMap field.
I think use of a ReadWriteLock for access to the boundsMap (instead of simply synchronizing on it) would greatly improve the scalibility. Currently threads that are only reading the map block each other which is not necessary.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
You'll need an SMP machine (not hyper threaded). Run at least twice the number of CPUs threads. Each thread should use something like TextLayout to calculate the boundaries of a string displayed in a font.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
100% CPU usage
ACTUAL -
~30%-50% CPU usage
REPRODUCIBILITY :
This bug can be reproduced always.
- backported by
-
JDK-2132530 Java2D Font implementation should improve MT scaleability of getting outline (visual) bounds.
-
- Resolved
-