Actually I did a test some time ago with jbullet, that uses a object pool normally, I changed that with normal object allocations, performance difference where on modern jvm near to 0%
Why?
Cause the jvm can!!! stackallocate objects when it determines that you dont use them outside of the scope.
So methods like
Vector3f scale(factor,result){}
can allocate internal used objects with nearly no cost at all, as long as you only return the already given variable you give the JIT compiler much freeroom to do such tricks, While still having a complete defensive coded method with no sideeffects.
Bonus JIT:
The jit can do this under certain circumstances as well, when you instanciate a new object and return this, for example
public void applygravity(){
local pos = getTranslation()
pos.add(Vector3f(0,-10,0)
setTranslation(pos)
}
setTranslation(Vector3f v){
this.localtranslation.set(v)
}
Node getTranslation(){
return new Vector3f(this.localtranslation)
}
can be found out to do the following at runtime
public void applygravity(){
this.localtranslation-=10
}
The JDK7 and JDK6 ers in the later version do this kind of JIt optimisation, and can do this also for more complex cases (like with a if, they will just create two highly optimized version for each case, and select the correct one at the start)