Dan Wallach (dwallach@cs.rice.edu)
Mon, 22 Mar 1999 10:49:14 -0600
Nelson recently invited me to join this list, and I've read over the various postings in the archives. Here's my current thinking on the problem. I don't currently have a research program to plug, having just started my new job at Rice, although you can probably read the text below as a manifesto for where I want to go... Because Java allows resources (both CPU and memory) to be shared, the resource accounting problems become much more difficult and also makes it a novel problem for research. In a traditional Unix process-structured system, there's never any debate who to "charge" for any given resource. If you're scheduled to run and you use your entire time quantum, we know to bill it to you. If you allocate a new page to your virtual memory, we know to bill it to you. In Java, this just doesn't work. But, instead of talking about Java, here's a simpler variant of the problem. In Unix, it's possible to create a file and mmap() it in multiple processes. Likewise, when a program is executing multiple times, each instance of the program will share the same VM pages for its code segment. Who should you charge for the code segment? The owner of the program file (on disk)? The owner(s) of running processes? Should you share the charges, or should you bill each instance as if it has a private copy? 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? It's difficult to pull unifying principles from all these problems, but here's my latest stab at the problem. Policies: It's fairly difficult to define a *policy* for memory or CPU allocation. Unless you enforce complete separation of resources (or use a billing policy which maintains the fiction of separation), there's no obvious answer for who to charge. Mechanisms: Once you do define a policy, the mechanisms can be tricky. If you want to charge for memory as a function of whomever is keeping it live, you may need to instrument your garbage collector. If you want to charge for "kernel" CPU as a function of the "user" who initiated the call, you may need to augment Java's stack inspection system, since sometimes the kernel is acting on behalf of a user and other times it's acting on its own accord. Abstractions: Threads are not very useful as a "unit of protection". Threads may cross from "user" classes into "kernel" classes arbitrarily, and the "kernel" could well do non-premptive scheduling by reusing one thread for multiple applications. Call stacks (as used in the Netscape 4.x/JDK 1.2 security architectures) have proven useful so far. Some folks are playing with namespaces (built with ClassLoader hacks). Both my thesis work and JRes have gotten good mileage out of code rewriting to add new semantics. Other abstractions may also be useful. Thoughts anyone? Dan ---------------------------------------------------------------------------- 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 Mon Mar 22 1999 - 11:54:14 EST