Doug Lea (dl@cs.oswego.edu)
Wed, 24 Mar 1999 19:41:50 -0500 (EST)
> Okay, back to Java again. Let's say you have a program that generates a > megabyte of garbage per second, but keeps a constant amount of memory live. > Now, compare this to a shared environment where a server generates a megabyte > of state per second that hundreds of clients may (or may not) choose to keep > live by maintaining a reference. In the first case, you really aren't > consuming memory, you're just consuming some small amount of cycles in the > memory subsystem. In the second example, should you bill the allocator of the > memory (as Cornell's JRes does), or should you bill whomever is keeping the > data live? How about both? In the distributed world, I think the consensus approach here is Leasing (as in Jini): The allocator/provider of a service might get charged for doing so. It can in turn charge others for finite-period leases of a reference to this object/service. In most systems of course no currency changes hands but there is nothing preventing this. Offhand I don't see any hope for realistcally applying this to fine-grained within-JVM resources, but maybe someone else does? -- Doug Lea, Computer Science Department, SUNY Oswego, Oswego, NY 13126 USA dl@cs.oswego.edu 315-341-2688 FAX:315-341-5424 http://gee.cs.oswego.edu/ ---------------------------------------------------------------------------- To unsubscribe (or other requests) mailto:majordomo@media.mit.edu List archives, FAQ, etc. http://gee.cs.oswego.edu/dl/javares/
This archive was generated by hypermail 2.0b3 on Wed Mar 24 1999 - 19:45:11 EST