Usage of Japanese fonts results in continuous memory increase

Problem definition:
when executed a sample Java application containing labels, text fields
and panels, we found that there is a steady increase in memory with
increase in number of iterations. Please note that the memory utilisation
of this sample application did not show any stabilisation or decrease, even
after 50 iterations. This is our actual problem. Please find attached the
sample program for your kind reference and testing.

Our Observation:
1) Kindly note that this increase in memory with the sample applciation is
specifically observed only in the Japanese locale. We have also found that
the memory is actually increasing when executing "setVisible(true)" method
of the Dialog class. Due to this continuous memory incresae, swap space
keeps growing and overruns after certain iterations. It is also observed
that the memory increase is directly proportional to the number of labels,
textfields and editfields in the dialog. An interesting observation is that
this memory increase is virtually unperceivable when the same sample
application is executed in English locale.Also, when only english font like
"Courier" is used for labels, text fields, etc the memory increase seem to
be less. So, it is very clear that there is a memory increase during the
display of japanese strings(can contain combination of English and japanese
characters) in Japanese locale.
Tip: This problem is found to be across JVM (say) JDK 1.1.8, JDK1.2.2 and
JDK 1.3.1


STEP BY STEP PROCEDURE FOR SIMULATING THE PROBLEM
_______________________________________________

Environment:
H/w : Sparc Ultra-10
Memory : 512 MB
Swap: 1 GB
OS : Solaris 8 (Multilingual)
Locale : All Japanese locales (e.g.) ja_EUCJP
JDK : JDK 1.3.1, JDK 1.4.0-beta2
Tool used : Glance Plus (to observe memory increase)

Step by Step procedure:

1. Login to the above environment in any of the Japanese locales

2. Copy the mem.java file (included as part of Mem.zip file that is
attached herewith) to the above environment

3. Compile and generate the mem.class, showframe.class, tpframe.class
files.

4. Execute using the following option.
     java mem

5. The applciation will display a frame with two buttons namely "show" and
"hide"

6. Start the 'Glance plus' tool. Choose the 'Process Memory Regions'
(Option - M) and 'Swap Space' (Option - w ) option after choosing the
process id of our sample java application and observe the 'Data VSS',
'Total VSS' and 'Swap used' fields.

7. Click the "show" button. A child frame appears with 5 text fields

8. Click the "hide" button. The child frame disappears.

9. Repeat the steps 7 and 8 once.

10. After every 3 iterations of step 9, an increase in memory of around 1
MB is observed using Glance plus (after refresh, if required) in 'Data
VSS', 'Total VSS' and 'Swap used' fields. Please refer to
Resultjapanese.txt for more details on our observations.

11. If the steps 1-10 are repeated in English locale, the above memory
increase is not observed.


# uname -a
SunOS ultra10 5.8 Generic_108528-07 sun4u sparc SUNW,Ultra-5_10

# java -version
java version "1.3.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_01)
Java HotSpot(TM) Client VM (build 1.3.1_01, mixed mode)

** Note: DTS tested with Jprobe Profiler with Memory Debugger ServerSide Suite Edition for Solaris tool. Version 3.0.1 (Build RTM301_P6)

01/11/01

DTS made arrangement for HP openview Glanceplus tool for this bug. DTS tested with this tool and can able to reproduce this problem.

You can download the Glanceplus software from osiris through nfs or ftp.

System name : osiris
IP address: 129.158.230.191
Username : admin
passwd : abc123

Mount cdrom through nfs.

Example:

mount -F nfs 129.158.230.191:/cdrom/cdrom0 /mnt (client side)