Gespenster Fast JVM load

This essay is about a suggested student project in Java programming. This essay gives a rough overview of how it might work. It does not describe an actual complete program. I have no source, object, specifications, file layouts or anything else useful to implementing this project. Everything I have to say to help you with this project is written below. I am not prepared to help you implement it; I have too many other projects of my own.

I do contract work for a living, which could include writing a program such as this. However, I don’t do people’s homework for them. That just robs them of an education.

You have my full permission to implement this project any way you please.

I solved a similar problem in the Abundance language which ran in 16-bit DOS mode using a technique I called gespenstering. There I loaded the program twice, at different addresses, took snapshots of RAM, and from that discovered which addresses needed relocation, and constructed an EXE file, with all the classes and the application preloaded.

Unfortunately the Microsoft documentation on how 32-bit exe headers work is exceedingly expensive, and I don’t have it. I have picked up only snippets of knowledge here and there.

We need to seek a similar solution for JVMs that run in Windows and NT in 32-bit flat mode. I believe that most of the time you can count on apps being loaded at the same address, which means much of the relocation information is redundant. If you can’t load at the desired address, you revert to the old full load and save that for future reference. When you can, you just map your RAM image into VM and go, with zero load time.

You may still need some fixups for DLLs, but the resolution process could presume that offsets within a DLL have not changed. Using your own table of fixup points would be considerably faster than using the system loader to resolve each symbol individually.

Solving this is much simpler if you have the source code to the JVM. You can then localise all DLL references in easy-to-patch tables.

Another approach would be to arrange at boot time that the DLLs get loaded in standard places in VM, and are pinned, so you need not worry about resolving those symbols a different way each time a JVM is loaded.

Unfortunately, any solution to the problem is not very portable. You need to solve it for each JVM on each platform. JITs present further challenges.

However the reward is high. Java would suddenly become much more spritely. Its reputation for slowness has little to do with execution speed. People are complaining about the long time to load the JVM and load the standard classes. Sun has shown absolutely zero interest in the problem of slow program load. You will be a Java hero. Ideally you would also solve it for the JVMs loaded within browsers where the wait time is especially onerous given the tiny size of the Applet finally invoked.

You might sidestep the relocation problem by having a relocatable header stub that checked if we were loading at precisely the same spot as last time and the DLLs were in the same spots. If so, it loads the old ram image; if not it loads in the traditional slow way and takes a new snapshot.

It is important that somebody tackle this problem, even crudely, just to show Sun the value of solving it properly. Ideally, the feature should be built into the operating system for every frequently used application.

If you want to tackle this project, find the Microsoft documentation on the format of DOS 16-bit EXE file headers and Win32 32-bit flat EXE file headers. Ask the Google search engine about "DOS exe header" and "Windows exe header". Have a look at how BBL does gespenstering in DOS with 16-bit code. See the GESPEN.BLK Forth source code file. Read the documentation part of BBL Forth on gespenstering. Start by converting your RAM snapshots into EXEs that must be loaded back at the exact same address, with the exact same DLLs already preloaded at exactly the same places. You might tackle the simpler 16-bit DOS EXE file header first for practice. Then add the ability to rebuild the DLL links and relocatability. Eventually tackle the JVM itself and any special initialisation it needs on restart. Then consider reducing the size of the RAM snapshot by dropping some easily recreated objects, avoiding garbage, compression etc. This project is similar to the Hibernation (Suspended Animation) Fast Program Load.

	Please email your feedback for publication, errors, omissions, broken/redirected link reports and suggestions to improve this page to Roedy Green :
	Canadian Mind Products
	mindprod.com IP:[65.110.21.43]
	Your face IP:[38.103.63.17]
	You are visitor number 3,703.
	You can get a fresh copy of this page from:	or possibly from your local J: drive (Java virtual drive/Mindprod website mirror)
	http://mindprod.com/project/gespenster.html	J:\mindprod\project\gespenster.html