JDK-6307181 : Performance problems on Solaris 10 (SunBlade1500, 2500), Solaris x86 & JDS platforms
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 5.0u3
  • Priority: P1
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris
  • CPU: other
  • Submitted: 2005-08-05
  • Updated: 2010-08-06
  • Resolved: 2005-08-06
Related Reports
Duplicate :  
JDK-4835595 - PixelGrabber.grabPixels runs up to 600 times slower on JDK1.4.1 than on JDK1.3.1
Duplicate :  
JDK-6307332 - Performance problems on Solaris using UML and remotely connected by VNC like application
Description
We are from the Java Studio Enterprise team, and our latest product JSE8 (with early access next week, ie burn the CD for shipment next week). We have found a serious performace issue on Solaris with latest hardware like

Solaris 10 on Sunblade 1500 & 2500
Solaris 10 x86
JDS platform

The scenario used is the most common usecase that our customer will use.

1. Install JSE8 IDE from "/net/balui.sfbay/kits/oriondev/main/Build050803_28/installers/"
2. Open the IDE after install
3. Create a UML diagram (Click File->New Project, Select  UML project)
Note: Our QA can help you setup and show the scenario
4. Create a UML diagramby clikcing on the Diagram node on the Project Tab (left side of IDE)
5. Try dragging an element (like Class) from right side pallette. Repeat this. After a while >5 you will see slow response.

We took process stack trace during slow response

====================================
fe941208 __1cNObjectMonitorFenter6MpnGThread__v_ (139b38, 471c80, 134, 0, f8cc0a10, 46a4f8) + 8
 feb1bd58 __1cSObjectSynchronizerJjni_enter6FnGHandle_pnGThread__v_ (dfefd7fc, 471c80, 1, 1, 759c, fefd79a4) + 25c
 feb1f9e0 jni_MonitorEnter (6000, 48c110, 471c80, fefd835c, fefccaf8, fef86000) + 2b0
 fa8a76b4 ???????? (471d38, a87288, dfefd8e0, 2, 0, 49480) + fffffffffbd87f84
 e0af5e70 Java_sun_awt_image_DataBufferNative_setElem (471d38, dfefd9b8, 11c, 134, d69a, dfefd9b4) + 48
 f8bfcc9c * *sun/awt/image/DataBufferNative.setElem(IIILsun/java2d/SurfaceData;)V+0
 f8c78694 * sun/java2d/pipe/RegionSpanIterator.getPathBox([I)V+-12480
 f8bfd00c * *java/awt/image/SinglePixelPackedSampleModel.setDataElements(IILjava/lang/Object;Ljava/awt/image/DataBuffer;)V+131 (line 605)
 f8cb9330 * *java/awt/image/WritableRaster.setDataElements(IILjava/lang/Object;)V+21 (line 268)
 f8cc0a10 * *sun/java2d/loops/OpaqueCopyArgbToAny.Blit(Lsun/java2d/SurfaceData;Lsun/java2d/SurfaceData;Ljava/awt/Composite;Lsun/java2d/pipe/Region;IIIIII)V+231 (line 167)
 f8c97ab4 * I2CAdapter
======================================

Also see attached logs of stack traces
Comments
WORK AROUND Use -J-Dsun.java2d.pmoffscreen=false flag to improve JVM java2d performance for JSE UML app.
06-08-2005
EVALUATION I can see from the stack traces that DataBufferNative is involved, which is used in some extreme cases to read back from a hardware surface (X11 Pixmap). For general loops like OpaqueCopyArgbToAny, this process will happen one pixel at a time, which can be very slow. Without seeing the source code for the UML editor, I can only guess that this routine is attempting to blend an image (possibly a VolatileImage) to the Swing backbuffer. Try running the application with -Dsun.java2d.pmoffscreen=false, which disables our use of pixmaps and should eliminate the performance problem. This issue is discussed in great detail in 4835595. This system property isn't necessarily an ideal solution; if you could point me to the source code for the UML editor (e.g. code from the com.tomsawyer or com.embarcadero packages), I could look into it further.
05-08-2005