Garbage collector memory accounting in language-based systems

Abstract

Language run-time systems are often called upon to safely execute mutually distrustful tasks within the same runtime, protecting them from other tasks' bugs or otherwise hostile behavior. Well-studied access controls exist in systems such as Java to prevent unauthorized reading or writing of data, but techniques to measure and control resource usage are less prevalent. In particular, most language run-time systems include no facility to account for and regulate heap memory usage on a per-task basis. This oversight can be exploited by a misbehaving task, which might allocate and hold live enough memory to cause a denial-of-service attack, crashing or slowing down other tasks. In addition, tasks can legitimately share references to the same objects, and traditional approaches that charge memory to its allocator fail to properly account for this sharing. We present a method for modifying the garbage collector, already present in most modern language runtime systems, to measure the amount of live memory reachable from each task as it performs its regular duties. Our system naturally distinguishes memory shared across tasks from memory reachable from only a single task without requiring incompatible changes to the semantics of the programming language. Our prototype implementation imposes negligible performance overheads in a variety of benchmarks, yet provides enough information for the expression of rich policies to express the limits on a task's memory usage.

I-JVM: a Java Virtual Machine for component isolation in OSGi

“…However the administrator must be aware of what I-JVM measures: as Price et al explain in [30], the memory usage statistics for a module are between a maximum (i.e. all shared objects used by the module are charged to the module) and a minimum (i.e.…”

“…I-JVM follows the garbage collector memory accounting algorithm of Price et al [30], which specifically deals with different protection domains sharing a same object. The overall insight of their algorithm is that the garbage collector performs the memory accounting.…”

“…I-JVM implements hard termination in the core JVM: instead of inserting polling code, the compiler unwinder and machine code rewriting ensures that the code of the class will never be executed anymore and stops instantaneously. Overall, I-JVM is a refinement of three research projects: isolates in Java [9], soft termination [32] and garbage collector memory accounting [30] in language based systems.…”

ScapeGoat: Spotting abnormal resource usage in component-based reconfigurable software systems

“…As a consequence, in certain occasions the framework states that an object is being consumed for many components at the same time. We built this solution on top of the JVM Tool Interface (JVMTI) by implementing the algorithm proposed in [37,40], with the main difference being that our solution works without modifying the garbage collector. In summary, this algorithm simply try to find those objects that are reachable from the references of each component.…”

“…However, their work is focused on CPU usage and does not consider other resources, such as memory or I/O. Exploring the Java heap to obtain useful information about resource consumption has been proposed in [37,40]. As in our work, they account objects to the resource principal being explored (in their case to OSGi bundles) the first time an object is reached.…”