By: Rob Thorpe (rthorpe.delete@this.realworldtech.com), October 20, 2006 5:47 am
Room: Moderated Discussions
Gabriele Svelto (gabriele.svelto@gmail.com) on 10/20/06 wrote:
---------------------------
>Rob Thorpe (rthorpe@realworldtech.com) on 10/20/06 wrote:
>---------------------------
>>* The problem might occur even if the architecture stores values in-order like
>>x86 does. The compiler could look at "expensiveInitialisation(AnObject)" and inline
>>it into the body of the function. It could then reorder the resulting tree of instructions
>>in such a way that the pointer representing the object is updated before the object
>>is fully constructed.
>
>This cannot happen in Java, a Java compiler/JIT doing so would alter the semantics
>of the language which mandates that only the constructor can work on an uninitialized
>object. Exiting from the constructor makes it initialized and available for other
>code, the compiler/JIT should enforce this behaviour which is the founding principle of safety in the language.
OK, I see.
The problem may still occur in other languages though.
---------------------------
>Rob Thorpe (rthorpe@realworldtech.com) on 10/20/06 wrote:
>---------------------------
>>* The problem might occur even if the architecture stores values in-order like
>>x86 does. The compiler could look at "expensiveInitialisation(AnObject)" and inline
>>it into the body of the function. It could then reorder the resulting tree of instructions
>>in such a way that the pointer representing the object is updated before the object
>>is fully constructed.
>
>This cannot happen in Java, a Java compiler/JIT doing so would alter the semantics
>of the language which mandates that only the constructor can work on an uninitialized
>object. Exiting from the constructor makes it initialized and available for other
>code, the compiler/JIT should enforce this behaviour which is the founding principle of safety in the language.
OK, I see.
The problem may still occur in other languages though.