20

This is just a simple theoretical question out of curiosity. I have always been like a java fan boy. But one thing makes me wonder why java does not provide mechanism for creating objects on the stack ? Wouldn't it be more efficient if i could just create small Point(int x,int y ) object on the stack instead of the heap like creating a structure on C# . Is there any special security reason behind this restriction in java ? :)

adn.911
  • 1,256
  • 3
  • 17
  • 30
  • 1
    What happens when you put it in a container that's not on the stack? When you return, the container now has a reference to deallocated memory. – Max Sep 18 '14 at 02:43
  • 1
    @Max: presumably, the language would also need to include constructs that allow the compiler to check against this. – Thilo Sep 18 '14 at 02:46
  • @Max: The container doesn't have a reference to the original, it either has a copy of it or a boxed copy of it. .NET/C# has had this for the past 15 years. https://msdn.microsoft.com/en-us/library/yz2be5wk.aspx – csauve Mar 24 '16 at 19:55

3 Answers3

19

The strategy here is that instead of leaking this decision into the language, Java lets the JVM/Hotspot/JIT/runtime decide where and how it wants to allocate memory.

There is research going on to use "escape analysis" to figure out what objects don't actually need to go onto the heap and stack-allocate them instead. I am not sure if this has made it into a mainstrem JVM already. But if it does, it will be controlled by the runtime (thing -XX:something), not the developer.

The upside of this is that even old code can benefit from these future enhancements without itself being updated.

If you like to manually manage this (but still have the compiler check that it stays "safe"), take a look at Rust.

Thilo
  • 257,207
  • 101
  • 511
  • 656
  • 6
    http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html enabled in 6u23 and later – jtahlborn Sep 18 '14 at 02:46
  • 2
    @jtahlborn: +1. I think the current crop of optimizations don't go as far as actually allocating objects on the stack, though. From the release notes, it sounds like eliminating locks and redundant copies of existing objects. – Thilo Sep 18 '14 at 02:49
  • +1 from the link jtahlborn posted: "It does not replace a heap allocation with a stack allocation for non-globally escaping objects." which implies that *ArgEscape* and *NoEscape* will be allocated on stack. But then again, it's not being explicitly mentioned... – Nir Alfasi Sep 18 '14 at 03:29
  • @alfasin: Yeah, not so clear. I read it as "replaces a heap allocation for a redundant defensive copy with no allocation at all" (re-using existing objects instead), which is what seems to be happening in the example they give. – Thilo Sep 18 '14 at 04:05
  • How can I be ensured that my object is passed by stack? Which rules are applied? – Sergey Ponomarev Jun 30 '18 at 10:12
6

This will tentatively be coming to Java, there is no real ETA set for this so you could only hope it will come by Java 10.

The proposal is called Value Types and you can follow it in the mailing list of Project Valhalla.

I do not know if there were any prior reasons as to why it wasn't in the language in the first place, maybe originally it was thought of as unneeded or there was simply no time to implement this.

skiwi
  • 66,971
  • 31
  • 131
  • 216
3

A common problem would be to initialize some global reference with an object created on the stack. When the method which created the object exits what do you point to?

That being said object are created on the stack in Java, it's just being done behind your back using the escape analysis which makes sure the above scenario doesn't occur.

Mateusz Dymczyk
  • 14,969
  • 10
  • 59
  • 94