Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4518599

Usage of Japanese fonts results in continuous memory increase



    • sparc
    • solaris_8


      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


      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

      4. Execute using the following option.
           java mem

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

      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)


      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:
      Username : admin
      passwd : abc123

      Mount cdrom through nfs.


      mount -F nfs /mnt (client side)


        Issue Links



              mbronsonsunw Mike Bronson (Inactive)
              duke J. Duke
              0 Vote for this issue
              0 Start watching this issue