On Dec 3, 2015, at 1:35 PM, mark.reinh...@oracle.com wrote: > >> I'm very tempted to take a bite at this, but the above text is rather >> forbidding. I think I know how to do it. (Famous last words?) > > As the author of the above-quoted paragraph, I wish you luck. It's > a tough problem. > > Random musing: I wrote those words in 2005. At this point in time I > suspect that an unmap method that works on some operating system but > not others might be more acceptable than it would have been back then.
We are takeing a crack at it with Panama, since using C APIs often requires timely deallocation of (non-Java) temps. The basic components are two: 1. A type called "Scope" which is bound to a Java stack frame using try-with-resources, and whose open, append, and close operations can do things like malloc and free. 2. A smart pointer type which is a tuple (value type some day) of <base, offset, type, scope>, whose indirection operations always check for a dead scope. This requires tricky compiler optimizations to make the scope checks fold up and go away. But it seems doable. One hard part is race conditions, but if we have fast path for operations within the thread owning the Scope, we can win, I think. (This is one reason it's important for a Scope to be bound to a stack frame.) In the absence of value types there will be a little bit of garbage created to represent the scopes and smart pointers, but it's O(N) where N is the number of operations, not O(M) where M is the number of bytes being operated on. And moving stuff to value types will reduce GC overhead even more. Basically, the little dribble of GC activity is the cost of safety. — John
