Archive for August, 2011
Getting the java heap size you asked for
Friday, August 26th, 2011
In a recent post I discussed a method we’re using for automatically setting the java heap size appropriately at runtime. It now turns out that the issue of setting the heap size is complicated by the fact that the heap size you request on the command line isn’t necessarily what you get given. In some cases the differences are modest, but sometimes they can be significant – amounting to hundreds of megabytes of discrepancy.
The simple test I did was to compare the heap size requested by setting the -Xmx value on the java command with the actual amount of available memory as reported by Runtime.getRuntime().maxMemory(). What I found was that the relationship between these two values isn’t 1:1, isn’t fixed at a given ratio, and is platform (and indeed VM) dependent.
According to this bug report the actual implementation of -Xmx is VM-dependent, so that the value you supply on the command line is merely a suggestion to the VM and it’s free to do whatever it likes. Because I’d like my software to work consistently on all platforms I therefore had a look at what the different VMs actually do.
The OSX VM actually stays very close to the requested amount of memory across the whole range of requested heap sizes. The linux and windows VMs though overcommit at small heap sizes (there seems to be a minimum allowed heap size of ~10MB), but undercommit by up to 12% at larger heap sizes. When you’re requesting a heap of serveral gigabytes in size a 12% loss is a significant amount of memory.
Our immediate solution to this problem is to do a trial run where we launch a small program which reports the actual heap size allocated. We then relaunch the normal java command, increasing the heap request size by a correction factor calculated from the trail run. This seems to produce consistent results on all platforms and gives us what we asked for in the first place.
Mac application bundle caching
Wednesday, August 10th, 2011
Having spent a frustrating hour or so trying to update a mac application bundle I thought I’d share a couple of things which caused no end of confusion and aren’t what you’d expect and are therefore likely to catch out those working with application bundles for the first time.
Basically I was finding that although I was making changes to my bundle these changes weren’t actually being applied. The bundle seemed to hold on to older versions of the data in the bundle even if this had been changed or even deleted.
It turns out that OSX caches information from the application bundle and then doesn’t check to see if the information in the bundle has been updated unless it is forced to. There are two separate caches which can affect you, a cache of the bundle icons, and a cache of the Info.plist file.
Icon cache
Inside your application bundle you can create a file containing a series of icons for your application. You make this file from a series of individual bitmap files normally by using the icon composer application which comes with the developer tools in OSX. What you will find is that if you update your icns file containing your application icons you won’t actually see any difference in the icons which are shown in the finder. The reason for this is that OSX caches the icons associated with files in a folder in a hidden file called .DS_Store. If this file is present then the finder will read the icon data out of that even if the icns file in your application bundle has been updated.
If you want to force the finder to recalculate the DS_Store file then you need to do the following:
- Make sure you have closed all finder windows showing your folder of interest
- From within the terminal delete the .DS_Store file from your folder of interest
- Relaunch the finder using Apple > Force Quit > Finder > Relaunch (this won’t affect any of your running applications)
This will force the finder to recalculate the icon cache for your folder and any changes to your icns file will be visible.
Info.plist cache
The Info.plist file in your application bundle provides all of the basic information about how to launch your application, where to find the icon file and various settings relating to the applications name and version. As with the application icons the information in the Info.plist file is cached by the OS, such that if you change the data in the file (say you change the name of the executable you want to run), then the bundle will remember the old value not the new one.
As an aside, if you’re having problems running an application bundle, the easiest way to see what’s actually going wrong is to open the Applications > Utilities > Console application and then relaunch your application. Any output generated on stdout or stderr by an application bundle will show up in this application and you can see any error messages which are generated.
Clearing the Info.plist cache is a bit easier than clearing the icon cache. The quickest way to reset it is to simply move your application to a different folder (say your desktop), and then move it back. This will reset the Info.plist cache and your changes should be applied.