Permspace can get corrupted on Solaris Sparc 7,8,9 if it is positioned at
0x80000000. This is reproducible even with one of the demo programs:

| 1. get hold of a complete J2SE 1.4.2_07 (for example) SDK installation.
| One of mine happens to live at /opt_earth/java/j2sdk1.4.2_07/. Adapt
| path names below suitably.-- Make sure DISPLAY is set, but this is
| just so the JVM has something nice to do.
|
| 2. cd /opt_earth/java/j2sdk1.4.2_07
| bin/java -Xms300m -Xmx768m -XX:MaxPermSize=1440m \
| -jar demo/jfc/Java2D/Java2Demo.jar
| (from another terminal window) locate the pid of this java process,
| and
| pmap $pid
|
| 3. Inspect the pmap output. Find the segment or two which make up the
| java heap. The permanent generation segment will be the next one
| above these in the address space, i.e. the next one below these in
| pmap output. For example, this might look like:
| ...
| 6F380000 8K read/write/exec [ anon ]
| 6F400000 34112K read/write/exec [ anon ] <<<<java heap
| 74950000 273088K read/write/exec [ anon ] <<<<java heap
| 9F400000 6912K read/write/exec [ anon ] <<<<perm gen
| F9580000 8K read/write/exec [ anon ]
| Note that the segments are spaced such that there's room to grow the
| heap to 768m, and room to grow the perm gen to 1440m, and additional
| red zone padding between segments.
| Note also that these segments are created from higher towards lower
| addresses. The 0x9F400000 was chosen by the kernel to accommodate
| a 1440m segment plus redzone padding, given that another segment
| already started at 0xF9580000. Thus the requested MaxPermSize
| determines where the perm gen segment will start (the stuff at
| higher addresses will not vary much from one run to the next; but
| it will depend on the exact sizes of several shared libraries, and
| thus will vary depending on Solaris version and patch levels.)
|
| 4. Work out how much larger MaxPermSize will need to be in order to
| get the base address of the perm gen segment just below 0x80000000,
| but the already-occupied part of it extends above . This
| may take a few trial and error iterations, since small changes are
| sometimes absorbed by the padding. For example:
| bin/java -Xms300m -Xmx768m -XX:MaxPermSize=1940m \
| -jar demo/jfc/Java2D/Java2Demo.jar
| ...
| 4FF7C000 96K read/write/exec /usr/dt/lib/libXm.so.4
| 50000000 34112K read/write/exec [ anon ]
| 55550000 273088K read/write/exec [ anon ]
| 80000000 6400K read/write/exec [ anon ]
| F9500000 352K read/exec /opt_earth/java/j2sdk1.4.2_07/jre/lib/sparc/libawt.so
| ...
| and I got the same at 1942m, but the next 2-MBy increment did the
| trick on my system:
|
| 5. bin/java -Xms300m -Xmx768m -XX:MaxPermSize=1944m \
| -jar demo/jfc/Java2D/Java2Demo.jar
| Exception in thread "main" java.lang.NoSuchMethodError: sun.awt.image.InputStreamImageSource: method <init>()V not found
| at sun.awt.image.URLImageSource.<init>(URLImageSource.java:23)
| at sun.awt.SunToolkit.createImage(SunToolkit.java:529)
| at java2d.DemoImages.getImage(DemoImages.java:87)
| at java2d.DemoImages.<init>(DemoImages.java:72)
| at java2d.Java2Demo.<init>(Java2Demo.java:113)
| at java2d.Java2Demo.main(Java2Demo.java:478)
|
| This is le bug.
|
| The progress-bar graphics in the preliminary window will have frozen
| up showing "Loading image" (for example - the victim class would
| depend on where exactly each class falls in the perm gen segment
| which now straddles the 0x80000000 line), and the java process is
| sitting there doing nothing, ready to debug with everything you can
| think of throwing at it - SIGQUIT, pmap, gcore, dbx, SA...
| In my case, the address space layout around the perm gen segment was
| now:
| 4FB7C000 96K read/write/exec /usr/dt/lib/libXm.so.4
| 4FC00000 34112K read/write/exec [ anon ]
| 55150000 273088K read/write/exec [ anon ]
| 7FC00000 4352K read/write/exec [ anon ]
| F9500000 352K read/exec /opt_earth/java/j2sdk1.4.2_07/jre/lib/sparc/libawt.so
| so of those 4352K's worth of page table mappings already created in
| the perm gen, there are 4096k in 0x7FC00000-7FFFFFFF and 256k above
| 0x80000000.
|
| 6. It seems that similar problems can also happen when the perm gen is
| above 0x80000000 but the java heap crosses the 0x80000000 mark, or
| even when the java heap is strictly below and the perm gen is strictly
| above this (and some copying of stuff from the heap to the perm gen
| occurs), but this is not as easy to reproduce with a small demo such
| as the Java2D one - you'd need to run something which loads far more
+ classes and exercises garbage collection seriously.

2.4 Describe problem impact to the customer. (optional)

###@###.### 2005-2-25 14:28:42 GMT