Java Performance Tuning

Java(TM) - see bottom of page

|home |services |training |newsletter |tuning tips |tool reports |articles |resources |about us |site map |contact us |
Tools: | GC log analysers| Multi-tenancy tools| Books| SizeOf| Thread analysers| Heap dump analysers|

Our valued sponsors who help make this site possible
JProfiler: Get rid of your performance problems and memory leaks! 

Training online: Concurrency, Threading, GC, Advanced Java and more ... 

Javva The Hutt October 2003

JProfiler
Get rid of your performance problems and memory leaks!

Modern Garbage Collection Tuning
Shows tuning flow chart for GC tuning


Java Performance Training Courses
COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs

Java Performance Tuning, 2nd ed
The classic and most comprehensive book on tuning Java

Java Performance Tuning Newsletter
Your source of Java performance news. Subscribe now!
Enter email:


Training online
Threading Essentials course


JProfiler
Get rid of your performance problems and memory leaks!


Back to newsletter 035 contents | All Javva's articles

Storing object structures persistently

In last month's column, I talked about alternate data storage locations for objects created by the JVM, like a "short-life" memory, a "long-life" memory, a "no collect" memory and a "persistent" memory. A bunch of you emailed me to tell me this is nothing new, predominently mentioning Prevalyer, which is a technology for dumping and restoring object structures.

Well I wasn't convinced that Prevayler and equivalents is what I meant. Firstly, this is only persistent storage, and not the other types I mentioned. But more importantly, Prevayler doesn't avoid object conversion overheads. I was really thinking that the optimal way to store an object is to do so by dumping the memory strucure with no conversion. Of course you'd be stuck using the same JVM if you wanted to restore objects, or there would have to be a standard for in-memory object formats. But that isn't too difficult.

Deciding I didn't have enough experience to decide how feasible this whole scenario was (and to check that I hadn't misunderstood the Prevayler supporter's objections), I discussed this with Jack. He pointed out that a long time ago he used to work for a company called GemStone which had already implemented part of my suggestion. They had a proprietary JVM (in 1996) which maintained a disk image of the JVM. There were all sorts of optimizations involved in ensuring performance didn't suffer, but essentially objects didn't need to be converted to alternative formats for storage. So not only is this feasible, the technology has even been implemented at least once already! So I think I'll stand by my prediction that you'll see various types of object memory spaces in future JVMs. But I must admit that you may not have heard it here first after all.

Diary of a Hutt

August 7. Stupid departmental outings coming up. They haven't done this for a couple of years, but have decided that they will this year. This time we are going into some woods to form teams and do some kind of armyish rubbish, you know, take the enemy flag and silly things of that sort. Actually, the boy in me is looking forward to it. The lazy boy in me wishes that he could watch it all from hot air balloon while drifting along with some food and drink.

August 14. Boris has an acquaintance who I can only refer to as Vlad, because the name "Vlad The Impaler" springs to mind every time I see him. Vlad has certain security "skills" which, when applied in the wrong way, could result in a prison sentence. I however have convinced Parsons that our system needs some testing to determine if it is sufficiently secure. Parsons liked the idea of an unannounced challenge to the security group, and agreed to Vlad as long as I was constantly monitoring his activity, which I did. After all, opportunities like this are few and far between.

August 21. Vlad found that external access to our systems was fully secure, but that internal access allowed some unauthorized entries to take place. I monitored his every move, and verified the report he wrote. His report did mention that a couple of low level accounts were broken into, which contained data that was accessed, but the data was not relevant to company operations, consisting merely of routine company administrative information. The precise information was not mentioned.

August 28. At the company outing, I formed a scouting unit with Boris and Brainshrii, sort of a performance unit sub-team. As soon as we were out of sight of all the rest, I took out my map and showed Boris and Brainshrii exactly where to go and what to do. In just over an hour later, we had retired to the picnic grounds in possession of both teams colors, several of the target tokens and the primary flag. The referee there was rather confused as to how we had managed it, so I informed him that we were the company performance team, and so were routinely faster than everyone else. We then spent the afternoon lounging, eating, drinking, and enjoying some of the latest video releases while waiting for the rest of the department to eventually straggle in. Now that's what I call department outing, nice and relaxing. It also appears that our performance sub-unit had won the lion's share of the awards. Knowledge is power, even if your knowledge is just "routine company administrative information".

BCNU

Javva The Hutt.


Back to newsletter 035 contents


Last Updated: 2024-08-26
Copyright © 2000-2024 Fasterj.com. All Rights Reserved.
All trademarks and registered trademarks appearing on JavaPerformanceTuning.com are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries. JavaPerformanceTuning.com is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
URL: http://www.JavaPerformanceTuning.com/news/javvathehutt035.shtml
RSS Feed: http://www.JavaPerformanceTuning.com/newsletters.rss
Trouble with this page? Please contact us