JDK-4254022 : PERF: GridBagLayout inefficiency
  • Type: Bug
  • Status: Resolved
  • Resolution: Fixed
  • Component: client-libs
  • Sub-Component: java.awt
  • Priority: P4
  • Affected Version: 6
  • OS:
    generic,linux,solaris_2.5.1,solaris_2.6,solaris_7,windows_nt generic,linux,solaris_2.5.1,solaris_2.6,solaris_7,windows_nt
  • CPU: generic,x86,sparc
  • Submit Date: 1999-07-14
  • Updated Date: 2017-05-16
  • Resolved Date: 2005-02-12
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 Availabitlity Release.

To download the current JDK release, click here.
6 b24Resolved
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Name: rlT66838			Date: 07/14/99

We have profiled our Java program and one of
the places it is spending the most time is in
GridBagLayout allocating new arrays.  For example:

  GridBagLayoutInfo () {
    minWidth = new int[GridBagLayout.MAXGRIDSIZE];
    minHeight = new int[GridBagLayout.MAXGRIDSIZE];
    weightX = new double[GridBagLayout.MAXGRIDSIZE];
    weightY = new double[GridBagLayout.MAXGRIDSIZE];

This method is called many times.  It allocates 
arrays of MAXGRIDSIZE (512) ints and doubles.
Also there are other allocations of arrays of 
[MAXGRIDSIZE] elements.  MAXGRIDSIZE is a static final 
int so a class can't even extend GridBagLayout and
change its value.

How about adding setMaxGridSize() to GridBagLayout,
or a new constructor GridBagLayout(int maxGridSize)?
(Review ID: 85571) 

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mustang

EVALUATION We should change GridBagLayout to use a vector instead of a fixed array of size 512. This is not only a waste of memory when small numbers of components are in the Layout, but it limits the maximum grid to 512. We have had complaints about both of these problems. We need to clean up GridBagLayout and GridBagLayoutInfo to use Vectors instead of the arrays. eric.hawkes@eng 1999-12-22 Because of a risk of breaking serialization with older versions and that both Vectors and ArrayList work with objects not int and double arrays causing quite a bit of extra code to be written for a slight performance gain this is being deffered until Tiger richard.ray@eng 2000-09-07 Comitting to tiger, as it should also fix 4623196. ###@###.### 2003-10-15 My original intention was to replace the int[] and double[] arrays in GridBagLayoutInfo with ArrayLists. However it turns out that a new GridBagLayoutInfo is created everytime the container is layed out. By putting off creation of the GridBagLayoutInfo until we know the width and height of the grid, we can create arrays of the exact size needed. This is a shorter-reaching and more compatible change (for instance, this doesn't break serialization). I still employed local ArrayLists during layout when the GridBagConstraints are being examined and before the grid size is known. I've attached the modified code example from the JavaDoc (GridBagEx1) which I used to take some performance numbers. It shows the Frame and then does a series of resizes. Overall, it looks like runtime performance is a wash running with or without my fix. Really, though, it doesn't look like the allocation of arrays is really a hotspot at all. This may have been true in the 1.1.* days, but I think it's no longer the case. On the bright side, OptimizeIt reports 33k less memory being used by int[]s, and the fix causes roughly one quarter the number of GCs: java -verbosegc before: $ c:/tiger/tiger/build/windows-i586/bin/java -verbosegc -cp . GridBagEx2 [GC 511K->211K(1984K), 0.0071006 secs] [GC 723K->275K(1984K), 0.0045100 secs] [GC 783K->282K(1984K), 0.0014622 secs] [GC 793K->294K(1984K), 0.0005599 secs] [GC 806K->279K(1984K), 0.0009201 secs] [GC 790K->289K(1984K), 0.0005169 secs] [GC 799K->291K(1984K), 0.0006515 secs] [GC 802K->292K(1984K), 0.0005072 secs] [GC 803K->296K(1984K), 0.0005159 secs] [GC 805K->297K(1984K), 0.0005135 secs] [GC 805K->298K(1984K), 0.0004632 secs] [GC 810K->299K(1984K), 0.0005008 secs] [GC 810K->306K(1984K), 0.0005099 secs] [GC 818K->311K(1984K), 0.0005298 secs] [GC 821K->310K(1984K), 0.0005345 secs] [GC 822K->314K(1984K), 0.0004714 secs] [GC 826K->300K(1984K), 0.0005099 secs] [GC 812K->304K(1984K), 0.0005232 secs] [GC 813K->306K(1984K), 0.0004495 secs] [GC 814K->307K(1984K), 0.0004899 secs] [GC 817K->308K(1984K), 0.0004619 secs] [GC 817K->309K(1984K), 0.0005342 secs] [GC 818K->311K(1984K), 0.0005230 secs] [GC 822K->316K(1984K), 0.0004956 secs] [GC 827K->321K(1984K), 0.0005094 secs] [GC 833K->310K(1984K), 0.0004434 secs] [GC 822K->312K(1984K), 0.0005476 secs] java -verbosegc after: $ c:/tiger/tiger/build/windows-i586/bin/java -verbosegc -cp . GridBagEx2 [GC 511K->211K(1984K), 0.0071040 secs] [GC 723K->286K(1984K), 0.0046603 secs] [GC 798K->296K(1984K), 0.0020308 secs] [GC 808K->297K(1984K), 0.0009177 secs] [GC 809K->298K(1984K), 0.0007943 secs] [GC 810K->299K(1984K), 0.0009182 secs] [GC 811K->299K(1984K), 0.0008974 secs] [GC 811K->301K(1984K), 0.0007395 secs] Also (other practical limits notwithstanding), it's now possible to create a GridBagLayout with > 512 Components wide and high. The following test used to throw an ArrayIndexOutOfBoundsException. It now runs to completion, provided you sufficently increase the heap size (: // Flex the new GridBagLayout with more than 512 items wide & high import java.awt.*; public class BigGBL { public static final int ITEMS = 600; public static void main(String[] args) { GridBagLayout gbl = new GridBagLayout(); GridBagConstraints gbc = new GridBagConstraints(); Panel panel = new Panel(); panel.setLayout(gbl); for (int i = 0; i < ITEMS; i++) { for (int j = 0; j < ITEMS; j++) { gbc.gridx = i; gbc.gridy = j; panel.add(new Label("Label"), gbc); } } panel.doLayout(); } } ###@###.### 2003-10-20