| |||||||||||||
The Managed Runtime InitiativeThe Managed Runtime InitiativePosted Jun 18, 2010 16:19 UTC (Fri) by jzbiciak (✭ supporter ✭, #5246)In reply to: The Managed Runtime Initiative by giltene Parent article: The Managed Runtime Initiative
As an outsider looking in, these batch virtual memory operations sound interesting in their own right, and not specifically related to Java and GC. It's just that your Java GC can make immediate use of them. This seems like a similar transformation to providing a vector of IO operations, versus repeated calls to read() or write(). What other workloads might benefit from such batch-oriented VM? Poul-Henning Kamp had an article in ACM Queue recently that showed a 10x speedup on heap structures by avoiding VM hits. While not identical to the problem you're solving, I think it highlights that explicitly optimizing VM behavior, even on "solved problems," is a generally interesting space, with opportunities for huge improvements. After all, heaps are "optimal," right? Then why the 10x speedup? Finding how your work can be leveraged outside your Java GC environment will make it more attractive.
(Log in to post comments)
The Managed Runtime Initiative Posted Jun 19, 2010 5:45 UTC (Sat) by giltene (guest, #67734) [Link]
Good point about relevance outside of GC, Java, and Runtimes. There certainly may be uses in other workloads (in memory DBs? DBs in general? Sparse memory applications that rely on virtual memory tricks?). In general, current virtual memory implementations in almost all OSs assume that virtual memory manipulation is a relatively rare event, and we have put forward an algorithm and an application for rapidly-changing mappings that makes a real difference to a vast array of applications, but it can't do so within the limitations of current virtual memory APIs and manipulation speeds.
We built the enhanced APIs to be generic [we think], without assumptions about the user-level code being a runtime, and focusing on the needed functionality and semantics. Our GC code is all in user space (part of the OpenJDK based code we put up along with the kernel mods) - it just needs some very scalable and somewhat different virtual and physical memory manipulation semantics form the kernel.
So yes, there can certainly be other uses for batched virtual memory operation with extremely fast commit times, and for other features like explicit-TLB-invalidate semantics (allowing user process to determine when a TLB invalidate is required, instead of issuing one per page), scalable virtual memory manipulation (not done under process-global lock), large page support that includes remapping capability, user-controlled shatter/unshatter transitions from large to small mappings while retaining large physical page layouts, etc.
The Managed Runtime Initiative Posted Jun 21, 2010 20:56 UTC (Mon) by nix (subscriber, #2304) [Link]
A good few of these features seem like things that could be useful for things like user-mode-linux as well (and anything else that has to manipulate a *lot* of mappings).
|
|||||||||||||