[Biojava-l] Java Resource Management [a semi troll...]
matthew_pocock at yahoo.co.uk
Tue Feb 11 11:02:13 EST 2003
> 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.
> Biojava-l mailing list - Biojava-l at biojava.org
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.
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.
BioJava Consulting LTD - Support and training for BioJava
More information about the Biojava-l