Grzegorz Czajkowski (grzes@CS.Cornell.EDU)
Wed, 17 Mar 1999 21:14:14 -0500 (EST)
Hello, I do agree that resource accounting/controlling/management should find its way into the JVM. The sooner the better, of course, so that the number of incompatible solutions does not keep growing. I did some experiments with implementing JRes in the JVM. The JRes Java interface remained the same, while all the bookkeeping + intercepting object allocations and deallocations were done in the runtime. I've done it with an optimizing compiler from Microsoft Research. Some performance data may be of interest: * when running applications under the control of original JRes (with bytecode-rewriting) on top of this particular JVM, tracking memory usage on a per-thread basis added 8-12% overhead to the application execution time * when JRes was implemented in the runtime, the overheads dropped to 0.8-1.8%. (Benchmarks: Lisp, JavaCC, plus some of the benchmarks that came with the compiler). Thus, with a little bit of fine-tuning, it should be possible to equip the JDK with memory controlling features (BTW in my opinion this is the most expensive resource to control; CPU, net, and disk I/O are much cheaper to deal with) so that the overheads will be truly negligible. This in turn could make it feasible to add resource control mechanisms as an integral part of the standard JVM (whatever comes after Java 2.0). -- Greg ---------------------------------------------------------------------------- To unsubscribe (or other requests) mailto:majordomo@media.mit.edu List archives, FAQ, member list, etc. http://gee.cs.oswego.edu/dl/javares/
This archive was generated by hypermail 2.0b3 on Thu Mar 18 1999 - 06:57:57 EST