Friday Feb 22, 2008
Friday Feb 22, 2008
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.
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.
Tuesday Jan 08, 2008
The new rules mean that Argentina began observing Daylight Savings Time (DST) again from Dec30th 2007. The tzupdater tool has been updated and customers can contact the Sun Technical Support Centre to obtain the last binary. http://java.sun.com/javase/timezones/ contains updated information also.
Friday Nov 23, 2007
As timezone support in the JRE seems to have become a more sensitive topic in recent years - more and more people want to have the latest timezone data incorporated into their environment in real time. Sun released the tzupdater tool to address such issues. Unfortunately with some timezones changes being taken at very short notice, even this effort is not enough for some java users.
Here's a quick guide (as promised) on how you can incorporate the latest timezone changes into your JRE :
For those of you new to compiling a JDK 7 workspace - here's what you need (paper and scissors are optional)
fireball $pwd /space/sean/JDK7/openjdk/jdk/make/sun/javazic/tzdata fireball $cp -r ~/tzdata2007i/* .
Don't forget to change the tzdata version number :
fireball $tail -1 VERSION tzdata2007i
All set for a compilation of these new tzdata files next :
fireball $pwd /space/sean/JDK7/openjdk/jdk/make/sun/javazic/tzdata fireball $gnumake clean rm -f ../../../build/solaris-sparc/tmp/sun/sun.javazic/strip_prop_options rm -f ../../../build/solaris-sparc/tmp/sun/sun.javazic/compile_prop_options rm -f ../../../build/solaris-sparc/tmp/sun/sun.javazic/.classes.list rm -f -r ../../../build/solaris-sparc/tmp/sun/sun.javazic/obj rm -f -r ../../../build/solaris-sparc/tmp/sun/sun.javazic/obj_* rm -f -r ../../../build/solaris-sparc/classes/sun/javazic rm -f ../../../build/solaris-sparc/tmp/sun/sun.javazic/.classes.list rm -f -r ../../../build/solaris-sparc/tmp/sun/sun.javazic ../../../build/solaris-sparc/lib/ziEt VoilĂ ! - a new directory full of the latest timezone rules ready for deployment. The new files will work with JDK 7 or earlier JRE releases. - Just replace the jre/lib/zi directory with the newly created one from your workspace. You should ensure that any instance of the JRE being updated is shut down first - otherwise the risk of the JRE continuing to hold references to older timezone data exists.
fireball $gnumake all rm -f -r ../../../build/solaris-sparc/tmp/sun/sun.javazic/zi /usr/bin/mkdir -p ../../../build/solaris-sparc/tmp/sun/sun.javazic/zi rm -f ../../../build/solaris-sparc/tmp/sun/sun.javazic/zi/ZoneInfoMappings /space/sean/jdk/jdk1.6.0_03//bin/java -client -Xmx896m -Xms128m -XX:PermSize=32m
-XX:MaxPermSize=160m -jar ../../../build/solaris-sparc/btjars/javazic.jar -V "`/usr/bin/grep '^tzdata'
./tzdata/VERSION`" -d../../../build/solaris-sparc/tmp/sun/sun.javazic/zi ./tzdata/africa ./tzdata/antarctica
./tzdata/asia ./tzdata/australasia ./tzdata/europe ./tzdata/northamerica ./tzdata/pacificnew
./tzdata/southamerica ./tzdata/backward ./tzdata/etcetera ./tzdata/solar87
./tzdata/solar88 ./tzdata/solar89 ./tzdata/systemv ./tzdata_jdk/gmt ./tzdata_jdk/jdk11_backward rm -f -r ../../../build/solaris-sparc/lib/zi /usr/bin/mkdir -p ../../../build/solaris-sparc/lib/zi rm -f ../../../build/solaris-sparc/lib/zi/ZoneInfoMappings /usr/bin/cp -r ../../../build/solaris-sparc/tmp/sun/sun.javazic/zi/* ../../../build/solaris-sparc/lib/zi
Wednesday Nov 21, 2007
Apparently, it's been the biggest sporting event that Ireland has ever held in terms of global audience - yes, even beats the Ryder Cup event held last year. Fair play to all who got involved. A good success story and a great example of cross border cooperation. After all, it's not everyday you get to see Mr McGuinness and Mr Paisley smiling in the same photo! :-)
Wednesday Nov 14, 2007
The latest version can be downloaded from here
Getting timezone changes to the public should be fast tracked. With the javazic source code now available in the opensource JDK7 project - developers can take this source and use it along with newer Olson data released to build the latest jre/lib/zi files. I plan to post steps for this pretty shortly.
Wednesday Oct 24, 2007
Read today that OpenOffice has surpassed the 100 million download mark. A great achievement! It always amazes me when I get mates asking me whether they need Microsoft office on their new PC/Laptop that they might be considering to purchase. Sadly - alot of them haven't even heard of OpenOffice Once I enlighten them of this software, they're well chuffed with the fact that they have as good a product (or better) for FREE ! PC sales folks tend to pick on easy targets for selling of software that's not necessary. That and extended warranties are where some guys get their commission. No need for either in my view, the later given how cheap your basic PC or laptop has become to buy.
Big corporates, governments and the likes could save $1000000's on software costs if they woke up. They could probably save even more if they moved to the Free Solaris OS
Go download the latest edition of Openoffice now.
Monday Oct 22, 2007

For the first time in over 20 years, many US clocks have had to come up to speed on new DST rules. More importantly, computer applications (esp. those dependent on timestamps) have had to be made aware of these changes. Java is one such product. Clocks in the US (and related) timezones fall back on Nov 4th 2007. A revamped timezone page has been made available at http://java.sun.com/javase/timezones/ .
If you took steps to cater for the new US DST changes prior to March this year then no changes should be necessary. Minimum JRE versions that support the new US DST rules are :Some new (US releated)changes have occurred since these new rules came in. Java users should check http://java.sun.com/javase/timezones/tzdata_versions.html to determine whether they need to upgrade to a newer version of Java.
Sunday Oct 21, 2007
There were a few issues with the installation on my Sony Vaio FE41S laptop. The sound card was one. I think I hit bug 6512149. A simple upgrade to the latest solaris nevada download will solve that one for me. Still haven't had time to properly check out issues with the inbuilt motion camera, the bluetooth stack and the sony short cut keys. Not essential though for my day to day operations.
Tuesday Oct 02, 2007