[Biojava-l] Java Resource Management [a semi troll...]

[Matthew Pocock]

> 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  -  Biojava-l at biojava.org
> http://biojava.org/mailman/listinfo/biojava-l
> 

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.

mmm

Matthew

-- 
BioJava Consulting LTD - Support and training for BioJava
http://www.biojava.co.uk