Ramblings of a Sun employee
Coffey's Blog
Archives
« November 2009
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
Click me to subscribe
Search

Links
 

Today's Page Hits: 9

Friday Feb 22, 2008
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.
Posted at 02:48PM Feb 22, 2008 by coffeys in Sun  |  Comments[0]

Tuesday Jan 08, 2008
Argentina changes timezone rules
The politicians in Argentina decided to give everyone a surprise for the new year by rushing new timezone rules for their country through parliament over the holiday break!

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.

Posted at 03:46PM Jan 08, 2008 by coffeys in Sun  |  Comments[0]

Friday Nov 23, 2007
Want the latest timezone data support in your JRE ? - NOW ? Step right up.

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 :

  • Go, grab a copy of the latest JDK 7 code. In there you'll find all the tools necessary to build the necessary zi files.
  • Sun uses the Olson timezone data releases as its guide for timezone rules. Their release versions are in the format of tzdata<year><letter>. The current tzdata rules at time of writing are the tzdata2007i rules. Go grab a copy of these at ftp://elsie.nci.nih.gov/pub/tzdata2007i.tar.gz and extract locally.
  • Java uses the javazic tool to compile its timezone rules. Unix OSes use the zic (Zone Information Compiler) tool. You need to get a copy of the javazic tool compiled in your workspace before the new zi files can be created...

    For those of you new to compiling a JDK 7 workspace - here's what you need (paper and scissors are optional)

  • A JDK 7 binary - Set your ALT_JDK_IMPORT_PATH variable to here.
  • A JDK 6 binary - Set your ALT_BOOTDIR variable to here.
  • A Binary Plugs directory - Set your ALT_BINARY_PLUGS_PATH variable to this. - Download from http://download.java.net/openjdk/jdk7/ - Install it using something like : java -jar jdk-7-ea-plug-b23-solaris-sparc-30_oct_2007.jar
  • cd to the jdk/make directory and issue a gnumake sanity command.
  • Be sure and read the README-builds.html file included in the JDK7 source if you've issues with building. Bear in mind that http://sunfreeware.com/ is a good spot to pick up any binaries that may be missing from your system.
  • Build the JDK sub directory : gnumake all
  • Once you have a build - you're good to make changes to the tzdata files.

    
    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/zi 
    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
    Et 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.
    Posted at 05:15PM Nov 23, 2007 by coffeys in Sun  |  Comments[2]

    Wednesday Nov 21, 2007
    WRC Rally - Ireland
    Managed to view some stages of the WRC rally in the North West of Ireland over the weekend. Great day out. Shame about the weather - I think it was one of the wettest weekends for a long time! Well done to Sebastien Loeb for winning the Irish leg of this tour. He looks all set to win his third consecutive WRC title. Wales remains as the final leg in the WRC 2007 tour.

    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! :-)


    Posted at 05:22PM Nov 21, 2007 by coffeys in Personal  |  Comments[2]

    Wednesday Nov 14, 2007
    tzupdater 1.3.0 is out
    After some delay - tzupdater 1.3.0 was released Monday. This build contains the tzdata2007h rules. Some of the main changes here being :
  • Brazil will observe DST from 2007-10-14 00:00 to 2008-02-17 00:00.
  • Egypt has changed DST rules.
  • Gaza DST changes.
  • Iran will resume DST next year.
  • Venezuela is currently planning to change time zones on January 1 to -04:30.

    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.

  • Posted at 10:24AM Nov 14, 2007 by coffeys in Sun  |  Comments[0]

    Wednesday Oct 24, 2007
    Openoffice celebrates over 100 million downloads
     Use OpenOffice.org 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.

    Posted at 06:13PM Oct 24, 2007 by coffeys in Personal  |  Comments[0]

    Monday Oct 22, 2007
    US Daylight Saving Time Ends November 4, 2007

    Clocks

    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.

    Posted at 05:21PM Oct 22, 2007 by coffeys in Sun  |  Comments[0]

    Sunday Oct 21, 2007
    Solaris Nevada on Sony Vaio
    Finally got around to replacing my ubuntu linux partition with a recent copy of Solaris Nevada (b70b). Happy to report that the new install GUI worked very well and I had no problems configuring the GRUB menu to have my windows and solaris partitions live happily side by side! Graphics, io, wifi, battery reporting all work fine. Netbeans worked like a treat first time round too.

    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.

    Posted at 12:15AM Oct 21, 2007 by coffeys in Personal  |  Comments[0]

    Tuesday Oct 02, 2007
    New Timezone data docs on java.sun.com
    New articles relating to how timezones are handled in the Sun JRE have been released on java.sun.com These pages explain how the Java SE group handles new timezone data which regularly changes worldwide. Recent changes in US DST (Daylight Savings Time) rules has highlighted why it's important to keep these rules up to date. Details on the timezone data released in every JRE are also available. Find out more about Sun's tzupdater tool. This product was released to help keep customers update to date with the latest timezone rules regardless of the JRE update version being used. Check out http://java.sun.com/javase/timezones/index.html for more information and FAQ links.
    Posted at 10:14AM Oct 02, 2007 by coffeys in Sun  |  Comments[0]