Gespenster Fast JVM load

Disclaimer

Please do not email me about this project without reading the disclaimer above.

1. It loads all the various code and scans the relocation headers to relocate various symbols.
2. It has to resolve all hooks into DLLs (Dynamic Link Libraries) to account for the fact the DLLs are not loaded at the same standard addresses.
3. It loads a large number of the standard classes.

I solved a similar problem in the Abundance language which ran in 16-bit DOS (Disk Operating System) mode using a technique I called gespenstering. There I loaded the program twice, at different addresses, took snapshots of RAM (Random Access Memory) 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 (Java Virtual Machines) 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 DLL (Dynamic Link Library) s, 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 (Just In Times) 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 (Big Black Lady) 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.

standard footer

	This page is posted on the web at:	http://mindprod.com/project/gespenster.html
	Optional Replicator mirror of mindprod.com on local hard disk J:	J:\mindprod\project\gespenster.html
	Please read the feedback from other visitors, or send your own feedback about the site. Contact Roedy. Please feel free to link to this page without explicit permission.
	Canadian Mind Products IP:[65.110.21.43] Your face IP:[13.59.198.150]
Feedback	You are visitor number