Maurizio Cimadamore is a compiler engineer at Oracle. He is currently working on the language and runtime aspects of many foundational projects that will change the shape of the Java platform, such as Project Valhalla and Project Panama. In the previous years, he has contributed to the design and implementation of several features of the Java programming language, such as diamond inference, lambda expressions and local variable type-inference. Maurizio holds a PhD in language design and implementation.
Accessing foreign (e.g. off-heap) memory from a Java application can be useful for a number of reasons, from avoiding the costs associated with garbage collection, to sharing memory across multiple processes and/or with native code. Yet, to date, the Java SE API provides no official tools for accessing foreign memory, forcing developers to cope with less than ideal solutions. One such solution, perhaps the most widely used, is the ByteBuffer API, which allows the creation of so called "direct" byte buffers --- thus allowing users to manipulate off-heap memory directly from Java. Another, less common, avenue by which developer can access foreign memory from Java code is through the Unsafe API, which exposes several low-level functionalities to manipulate both off-heap and on-heap memory directly, and in a very efficient fashion, thanks to its clever use of JVM intrinsics. Unfortunately, existing approaches for accessing foreign memory are far from being ideal: on the one hand, the ByteBuffer API, which has been designed after I/O use cases, suffers from several limitations --- lack of addressing space, non-deterministic deallocation to name a few --- when used as a general purpose foreign memory API; on the other hand, using the Unsafe API -- as the name implies -- is a risky business, which can result in hard JVM crashes if the API is not used correctly. In other words, when it comes to accessing foreign memory, no optimal solution exists - and Java developers are faced with a dilemma: should they use the safe, trodded but twisted (and possibly less efficient) ByteBuffer path or should they abandon all safety guarantees and embrace the (unsupported) Unsafe API? In this talk we paint the path to the future: a safe, supported and efficient foreign memory access API for Java. By providing a more targeted solution to the problem of accessing foreign memory, not only developers will be freed by the limitations of the existing APIs - but they will also enjoy improved performances, as the new API will be designed from the ground-up with JIT optimizations in mind - and all without sacrificing memory access safety.
Bring your favorite questions about Java SE and the Java Development Kit — past, present, or future — to this open Q&A session.
|Talks by tracks||Talks by session types||List of Speakers|