This essay does not describe an existing computer program, just one that should exist. This essay is about a suggested student project in Java programming. This essay gives a rough overview of how it might work. I have no source, object, specifications, file layouts or anything else useful to implementing this project. Everything I have prepared to help you is right here.
This project outline is not like the artificial, tidy little problems you are spoon-fed in school, when all the facts you need are included, nothing extraneous is mentioned, the answer is fully specified, along with hints to nudge you toward a single expected canonical solution. This project is much more like the real world of messy problems where it is up to you to fully the define the end point, or a series of ever more difficult versions of this project and research the information yourself to solve them.
Everything I have to say to help you with this project is written below. I am not prepared to help you implement it; or give you any additional materials. I have too many other projects of my own.
Though I am a programmer by profession, 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 in any way you please and to keep all the profits from your endeavour.
Please do not email me about this project without reading the disclaimer above.Every time you load a JVM (Java Virtual Machine) it goes through the same huge song and dance:
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.In Vista, W2008, W7-32, W7-64, W8-32, W8-64, W2012, W10-32 and W10-64, in the background, the OS (Operating System) preloads commonly used programs in a progess called SuperFetch I don’t know any details.
This page is posted
Optional Replicator mirror
Your face IP:[184.108.40.206]
You are visitor number|