7 ms·

Will a Java expert (JVM developer) please answer this question? Thank you. How impossible would it be to add a delete keyword to the JVM, and why?

koolba 9y ago
Why would you want to add a delete keyword? Are you trying to add explicit memory management to simplify the work of the garbage collector?
- bobsgame 9y ago
  One example would be game development, where people end up doing object pooling to avoid GC pauses dropping frames.
  - pron 9y ago
    There are better ways to eliminate GC pauses than manual memory management (even ignoring the relatively new "pauseless" GCs). See the new RTSJ (realtime Java) specification here: https://www.aicas.com/cms/en/rtsj https://www.aicas.com/cms/en/rtsj. Not that it's designed for far stricter requirements than games (cases where even microseconds of unexpected latency may result in actual life safety concerns). Manual memory management is a good choice if you have both worst-case latency concerns as well as very restricted RAM and/or severe energy constraints (basically, the kind of applications that Rust was designed to handle).
    - kuschku 9y ago
      The RTSJ solution is to simply pre-allocate everything you could ever want and reuse that. That’s horrible to use for game development.
      - merb 9y ago
        I'm not a game developer, so why is that horrible? consider I have an array/map of my game objects and the rest only works with methods, so most stuff does not lie on the heap, well that means basically no strings, since they would add to heap memory aswell, but only using basic datatypes and arrays. why would some kind of that be problematic? I mean graphics programmic is kind of new to me, but considering that you could offload that to a c/c++ engine via jni (that's another horrible thing of some kind), but just the game code itself doesn't seems to be to bad, does it?
        kuschku 9y ago
        > why would some kind of that be problematic? I mean graphics programmic is kind of new to me, but considering that you could offload that to a c/c++ engine via jni (that's another horrible thing of some kind), but just the game code itself doesn't seems to be to bad, does it? The whole point is not to offload anything. If you need to offload anything, even the render loop, the language has failed.
      - pron 9y ago
        > The RTSJ solution is to simply pre-allocate everything you could ever want and reuse that. That's not the RTSJ solution. RTSJ uses arenas, which are great if you have regular allocation/deallocation cycles, like, say, a frame in a game.
        kuschku 9y ago
        > That's not the RTSJ solution. RTSJ uses arenas, which are great if you have regular allocation/deallocation cycles, like, say, a frame in a game. So how do I get a user’s Oracle JRE installation to use arenas? The only realistic scenario is to preallocate and reuse.
        pron 9y ago
        You don't. You use an RTSJ JVM.
        kuschku 9y ago
        That’s not an option, that was the whole point of the discussion.
        pron 9y ago
        If changing the JVM spec is an option, then surely so is using an existing spec. IBM has an RTSJ JVM[1], which, I believe, is based on J9. [1]: https://www.ibm.com/support/knowledgecenter/en/SSSTCZ_3.0.0/com.ibm.wrt.rtlinux.doc.30/homepage/plugin-homepage-rt.html https://www.ibm.com/support/knowledgecenter/en/SSSTCZ_3.0.0/...
        kuschku 9y ago
        Changing the JVM spec has a chance at being applied in future normal JVMs. Using an entirely separate solution has not.
        9y ago
      - imtringued 9y ago
        Isn't that what almost every game does during loading screens?
    - jsiepkes 9y ago
      JEP 189: Shenandoah: An Ultra-Low-Pause-Time Garbage Collector (http://openjdk.java.net/jeps/189 http://openjdk.java.net/jeps/189) could help with that.
  - mstoodle 9y ago
    You could also check out Eclipse OpenJ9's -Xgcpolicy:metronome option. It only works on Linux X86-64 at the moment, but it is designed to better regulate GC pauses. If you want to learn more, you can open an issue to ask for more details at https://github.com/eclipse/openj9/issues https://github.com/eclipse/openj9/issues .
  - rlp 9y ago
    Even in game development in C/C++, you wouldn't want to be allocating/deleting heap objects in every frame. You'd probably end up pooling there too, unless you're referring to the problem that the JVM has no value types and forces heap allocation for all objects. This will be fixed in JDK 10 (see Project Valhalla).
  - int_19h 9y ago
    What would you expect to be the behavior of any existing references to an object that was deleted? (Keep in mind that Java is a memory-safe language.)
  - imtringued 9y ago
    That doesn't solve the fundamental problem of stop the world pauses. If you had 10 threads sharing the same gc heap that allocate as much garbage as they want and 1 thread that has it's own heap that doesn't allocate anything only the 10 threads would be stopped by the garbage collector and you would have reached your goal. If those 11 threads would share the same heap and 1 thread still doesn't use the gc because it's using manual memory management then you'd still suffer from stop the world pauses. What you want is isolated heaps like erlang does, not manual memory management. I'm still wondering why we have no other programming languages with multiple heaps. You could probably achieve something similar with D and use of memory mapped files to efficiently share memory without copying bewteen processes. Alternatively you could call into C to spawn OS threads that don't suffer from stop the world pauses. But those two options are a hack. You're not supposed to use D like that. I chose D as an example because it's a programming language with both a garbage collector and manual memory management that still suffers from stop the world pauses.
shemnon42 9y ago
Java does memory recovery strictly by garbage collection. To delete an object remove all references to that object and wait. A "delete now" operation imposes requirements on implementations that are not strictly required. Any advantages gained from destructors can be realized via explicit cleanup methods and (as a hedge against mis-use) state checking for initialized and destroyed objects. A delete operation also adds risk that an object that has been deleted may be referenced again (although with esoteric stuff like PhantomReferences you can almost do it).
- bobsgame 9y ago
  Would it be impossible (or prohibitively difficult) to add it to an implementation, though?
  - shemnon42 9y ago
    Prohibitively difficult. If you really truly need delete then you really truly don't need Java and should use something like C.
- bitwize 9y ago
  What about the "automatically gets cleaned up when the object goes out of scope" advantage of destructors?
  - guipsp 9y ago
    You can do that with try-with-resources
- foota 9y ago
  I could see where this might be useful for reducing gc load in an application with (very) soft real time requirements.
mike_hearn 9y ago
It's not impossible. HotSpot/OpenJDK already has one. It's a native method/compiler intrinsic rather than a keyword but amounts to the same thing: http://www.docjar.com/docs/api/sun/misc/Unsafe.html#freeMemory(long) http://www.docjar.com/docs/api/sun/misc/Unsafe.html#freeMemo...
- mstoodle 9y ago
  That frees a block of native memory, not an arbitrary Java object...
imtringued 9y ago
It's far from impossible. I would even say it's extremely trivial to add a C++ style delete keyword but then you'd lose memory safety because of the potential use after free bugs and it wouldn't even increase performance because the problem with garbage collectors is the stop the world pause, lack of off heap allocations for very large data and the needed value types to fully take advantage of that feature. If you want manual memory allocation then you should instead look at sun.misc.Unsafe. http://www.docjar.com/html/api/sun/misc/Unsafe.java.html http://www.docjar.com/html/api/sun/misc/Unsafe.java.html public native long allocateMemory(long bytes); public native void freeMemory(long address); Of course you still have to calculate the field offsets and all that stuff manually because it's not a part of the java language but you only asked about the JVM.

koolba 9y ago

Why would you want to add a delete keyword? Are you trying to add explicit memory management to simplify the work of the garbage collector?

bobsgame 9y ago
One example would be game development, where people end up doing object pooling to avoid GC pauses dropping frames.
- pron 9y ago
  There are better ways to eliminate GC pauses than manual memory management (even ignoring the relatively new "pauseless" GCs). See the new RTSJ (realtime Java) specification here: https://www.aicas.com/cms/en/rtsj https://www.aicas.com/cms/en/rtsj. Not that it's designed for far stricter requirements than games (cases where even microseconds of unexpected latency may result in actual life safety concerns). Manual memory management is a good choice if you have both worst-case latency concerns as well as very restricted RAM and/or severe energy constraints (basically, the kind of applications that Rust was designed to handle).
  - kuschku 9y ago
    The RTSJ solution is to simply pre-allocate everything you could ever want and reuse that. That’s horrible to use for game development.
    - merb 9y ago
      I'm not a game developer, so why is that horrible? consider I have an array/map of my game objects and the rest only works with methods, so most stuff does not lie on the heap, well that means basically no strings, since they would add to heap memory aswell, but only using basic datatypes and arrays. why would some kind of that be problematic? I mean graphics programmic is kind of new to me, but considering that you could offload that to a c/c++ engine via jni (that's another horrible thing of some kind), but just the game code itself doesn't seems to be to bad, does it?
      - kuschku 9y ago
        > why would some kind of that be problematic? I mean graphics programmic is kind of new to me, but considering that you could offload that to a c/c++ engine via jni (that's another horrible thing of some kind), but just the game code itself doesn't seems to be to bad, does it? The whole point is not to offload anything. If you need to offload anything, even the render loop, the language has failed.
    - pron 9y ago
      > The RTSJ solution is to simply pre-allocate everything you could ever want and reuse that. That's not the RTSJ solution. RTSJ uses arenas, which are great if you have regular allocation/deallocation cycles, like, say, a frame in a game.
      - kuschku 9y ago
        > That's not the RTSJ solution. RTSJ uses arenas, which are great if you have regular allocation/deallocation cycles, like, say, a frame in a game. So how do I get a user’s Oracle JRE installation to use arenas? The only realistic scenario is to preallocate and reuse.
        pron 9y ago
        You don't. You use an RTSJ JVM.
        kuschku 9y ago
        That’s not an option, that was the whole point of the discussion.
        pron 9y ago
        If changing the JVM spec is an option, then surely so is using an existing spec. IBM has an RTSJ JVM[1], which, I believe, is based on J9. [1]: https://www.ibm.com/support/knowledgecenter/en/SSSTCZ_3.0.0/com.ibm.wrt.rtlinux.doc.30/homepage/plugin-homepage-rt.html https://www.ibm.com/support/knowledgecenter/en/SSSTCZ_3.0.0/...
        kuschku 9y ago
        Changing the JVM spec has a chance at being applied in future normal JVMs. Using an entirely separate solution has not.
        9y ago
    - imtringued 9y ago
      Isn't that what almost every game does during loading screens?
  - jsiepkes 9y ago
    JEP 189: Shenandoah: An Ultra-Low-Pause-Time Garbage Collector (http://openjdk.java.net/jeps/189 http://openjdk.java.net/jeps/189) could help with that.
- mstoodle 9y ago
  You could also check out Eclipse OpenJ9's -Xgcpolicy:metronome option. It only works on Linux X86-64 at the moment, but it is designed to better regulate GC pauses. If you want to learn more, you can open an issue to ask for more details at https://github.com/eclipse/openj9/issues https://github.com/eclipse/openj9/issues .
- rlp 9y ago
  Even in game development in C/C++, you wouldn't want to be allocating/deleting heap objects in every frame. You'd probably end up pooling there too, unless you're referring to the problem that the JVM has no value types and forces heap allocation for all objects. This will be fixed in JDK 10 (see Project Valhalla).
- int_19h 9y ago
  What would you expect to be the behavior of any existing references to an object that was deleted? (Keep in mind that Java is a memory-safe language.)
- imtringued 9y ago
  That doesn't solve the fundamental problem of stop the world pauses. If you had 10 threads sharing the same gc heap that allocate as much garbage as they want and 1 thread that has it's own heap that doesn't allocate anything only the 10 threads would be stopped by the garbage collector and you would have reached your goal. If those 11 threads would share the same heap and 1 thread still doesn't use the gc because it's using manual memory management then you'd still suffer from stop the world pauses. What you want is isolated heaps like erlang does, not manual memory management. I'm still wondering why we have no other programming languages with multiple heaps. You could probably achieve something similar with D and use of memory mapped files to efficiently share memory without copying bewteen processes. Alternatively you could call into C to spawn OS threads that don't suffer from stop the world pauses. But those two options are a hack. You're not supposed to use D like that. I chose D as an example because it's a programming language with both a garbage collector and manual memory management that still suffers from stop the world pauses.

shemnon42 9y ago

Java does memory recovery strictly by garbage collection. To delete an object remove all references to that object and wait. A "delete now" operation imposes requirements on implementations that are not strictly required. Any advantages gained from destructors can be realized via explicit cleanup methods and (as a hedge against mis-use) state checking for initialized and destroyed objects. A delete operation also adds risk that an object that has been deleted may be referenced again (although with esoteric stuff like PhantomReferences you can almost do it).

bobsgame 9y ago
Would it be impossible (or prohibitively difficult) to add it to an implementation, though?
- shemnon42 9y ago
  Prohibitively difficult. If you really truly need delete then you really truly don't need Java and should use something like C.
bitwize 9y ago
What about the "automatically gets cleaned up when the object goes out of scope" advantage of destructors?
- guipsp 9y ago
  You can do that with try-with-resources
foota 9y ago
I could see where this might be useful for reducing gc load in an application with (very) soft real time requirements.

mike_hearn 9y ago

It's not impossible. HotSpot/OpenJDK already has one. It's a native method/compiler intrinsic rather than a keyword but amounts to the same thing: http://www.docjar.com/docs/api/sun/misc/Unsafe.html#freeMemory(long) http://www.docjar.com/docs/api/sun/misc/Unsafe.html#freeMemo...

mstoodle 9y ago
That frees a block of native memory, not an arbitrary Java object...

imtringued 9y ago

It's far from impossible. I would even say it's extremely trivial to add a C++ style delete keyword but then you'd lose memory safety because of the potential use after free bugs and it wouldn't even increase performance because the problem with garbage collectors is the stop the world pause, lack of off heap allocations for very large data and the needed value types to fully take advantage of that feature. If you want manual memory allocation then you should instead look at sun.misc.Unsafe. http://www.docjar.com/html/api/sun/misc/Unsafe.java.html http://www.docjar.com/html/api/sun/misc/Unsafe.java.html public native long allocateMemory(long bytes); public native void freeMemory(long address); Of course you still have to calculate the field offsets and all that stuff manually because it's not a part of the java language but you only asked about the JVM.