2 recent Java issues

Thought I might add an entry about two recent Java issues I've worked on with customers. Both issues already have fixes underway.

One issue involved the way the Sun JRE allocates the javaplugin.maxHeapSize variable during the plugin initialisation phase on windows. Most boxes should allocate 96MB to this variable. In certain cases, where java suspects that the system is running low on memory we only allocate 64MB. Of course, these are only the default values. The user is free to set their own heapsize via the deployment properties file or via the java control panel. The code has functioned well and good over the past couple of years until we received a recent escalation from a customer who had large 3D modelling memory hungry applets hosted from their website. The applets had a working memory set of somewhere around the 70MB mark but more and more users (with default settings) were complaining of the JRE failing to load the applet due to memory errors. I tried reproducing the issue internally on serveral lab systems with no joy. All systems were showing 96MB as the maxHeapSize variable. That is - until I tested the applet on my laptop...

To obtain deployment properties, you can simply hit the "s" key in the java console window.

...
java.vm.info = mixed mode, sharing
java.vm.name = Java HotSpot(TM) Client VM
java.vm.specification.name = Java Virtual Machine Specification
java.vm.specification.vendor = Sun Microsystems Inc.
java.vm.specification.version = 1.0
java.vm.vendor = Sun Microsystems Inc.
java.vm.version = 1.6.0_03-b05
javaplugin.maxHeapSize = 64m
javaplugin.nodotversion = 160_03
javaplugin.proxy.config.type = direct
javaplugin.version = 1.6.0_03
...

Turns out that my laptop was only allocating this troublesome 64MB value. My laptop had 2GB of RAM, how could this be happening I wondered ??! Turns out that was the very crux of the problem. The JRE was using the following code to determine the heapSize.

if (phyMemory >= virtualAvailMemory)
    {
        // Running out of memory
        maxHeap = 64;
    }
     else if (phyMemory <= 32)
     {
         maxHeap = 64;
     }
     else if ...

One would assume that testing phyMemory against the virtualAvailMemory figure would be a good method of determining a system's resources. Turns out that on some newer windows systems, the physicalMemory value can often be higher than the virtualAvailMemory figure. Windows tends to max out the virtualAvailMemory to around the 2GB size. A simple test on the troublesome PC showed this :

There is  2095212 dwTotalPhys.
There are 2090100  dwAvailVirtual. 
The above figures can also be found by checking the Systems Information tool. The fix was straightforward after that with the introduction of another memory figure to the equation : freePhysicalMemory. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6618901 is following this.
The other issues causing some concern to some customers recently was a new exception message printed when network debugging was switched on in the java console. Recent changes to some DNS lookup bugs mean we print exception stack traces on the console such as :
basic: Referencing classloader: sun.plugin.ClassLoaderInfo@14e113b, refcount=1
java.net.UnknownHostException: java.sun.com
        at java.net.Inet4AddressImpl.lookupAllHostAddr(Native Method)
        at java.net.InetAddress$1.lookupAllHostAddr(InetAddress.java:849)
        at java.net.InetAddress.getAddressFromNameService(InetAddress.java:1200)
        at java.net.InetAddress.getAllByName0(InetAddress.java:1153)
        at java.net.InetAddress.getAllByName(InetAddress.java:1083)
        at java.net.InetAddress.getAllByName(InetAddress.java:1019)
        at java.net.InetAddress.getByName(InetAddress.java:969)
        at com.sun.deploy.cache.Cache.getHostIP(Cache.java:1611)
        at com.sun.deploy.cache.Cache.createHostEntry(Cache.java:1637)
        at com.sun.deploy.cache.Cache.updateHostIPFile(Cache.java:1171)
        at sun.plugin.AppletViewer.updateHostIPFile(AppletViewer.java:1595)
        at sun.applet.AppletPanel.getAccessControlContext(AppletPanel.java:1108)
        at sun.applet.AppletPanel.getClassLoader(AppletPanel.java:1009)
        at sun.applet.AppletPanel.init(AppletPanel.java:215)
        at sun.plugin.AppletViewer.createClassLoader(AppletViewer.java:890)
        at sun.plugin.AppletViewer.appletInit(AppletViewer.java:701)
        at sun.plugin.viewer.LifeCycleManager.loadAppletPanel(LifeCycleManager.j
It can occur when the JRE client itself fails to resolve a hostname (and leaves it to the proxy server instead. Such error messages are misleading and not very pleasing to the eye. We're going to change the implementation in future releases so that a one line warning is printed instead of the stack trace. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6620270 is tracking this.
Comments:

Post a Comment:
  • HTML Syntax: NOT allowed
About

The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.

Search

Categories
Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today