Creating Objects on the stack memory in java ?

Question

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 ? :)

Leishaleishmania

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. – Kodiak

@Max: presumably, the language would also need to include constructs that allow the compiler to check against this. – Kimbrakimbrell

@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. msdn.microsoft.com/en-us/library/yz2be5wk.aspx – Moussorgsky

Answer 1

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.

Kimbrakimbrell

docs.oracle.com/javase/7/docs/technotes/guides/vm/… enabled in 6u23 and later – Medallist

@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. – Kimbrakimbrell

+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... – Nourish

@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. – Kimbrakimbrell

How can I be ensured that my object is passed by stack? Which rules are applied? – Torhert

Answer 2

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.

Habitforming

Alright! Java will "tentatively" catch up to C#? "Sometime" (tm) – Moussorgsky

@Habitforming Can you please briefly explain what Value Types are? – Kaciekacy

Answer 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.

Breakup

Answer 4

JVM does Scalar Replacement.

Instead of allocating object on stack, it decomposes object into primitives, eliminates unused ones and uses CPU registers and stack to store and operate on useful ones.

This optimization is far more powerful (when it works) than simple stack allocation and is performed automatically and by default.

See -XX:-EliminateAllocations

Demigod