Internaly, BioJava uses several mechanisms for caching data. Like you, since hotspot, we've found that caches get agressively cleared which defeats the point of them. The reference objects are quite usefull for canonicalizing objects (e.g. fetching features from a DB if there is no feature object in existance that represents it) and for knowing that they are going away.In short, using all the memory you possibly can, but without actually crashing the JVM is fairly hard in Java. Or, if I am more honest, I never found a good way of doing it. Perhaps someone else has.Cheers Phil _______________________________________________ Biojava-l mailing list - [EMAIL PROTECTED] http://biojava.org/mailman/listinfo/biojava-l
Caches and/or reference objects are used everywhere from DB access to dynamic programming to the event system to large alphabets. They nearly do what we need - if hotspot wasn't so agressive with them, we would have prety much all the fexibility we could want for memory management.
The NIO packages let you do all the unsafe cast operations that so often bite me when writing c. Except, there's no way to accidentaly think you are doing something sane. With NIO and the coms packages, you can write Java device drivers.
You can wrote bytecode to a stream and read it in with a class loader. This lets you extend the application at run-time with dynamically generated code. This is better than writing machine-code at run-time as the bytecode gets varified before it is run, and it runs within a sand-box.
Much of the startup overhead could be solved by having the vm sign that core classes have been varified in the past, and prove that they haven't been altered since. If the hotsopot VMs used a similar trick to dump out 'snapshots' of optimized code, we could avoid every java process under the sun performing the same n optimizations on xerces parsers, and perhaps shave off some of that biojava load-time.
Now, if the NIO stuff was extended so that we could allocate Java objects within buffers, and if there was an 'executable' buffer type that could host an executing VM thread stack, we'd have everything necisary to write a full VM/OS in pure Java.
mmm
Matthew
--
BioJava Consulting LTD - Support and training for BioJava
http://www.biojava.co.uk
_______________________________________________
Biojava-l mailing list - [EMAIL PROTECTED]
http://biojava.org/mailman/listinfo/biojava-l
