Well, jezek, it's excellent work, thank you for it! I was thinking about creation some kind of simulation library for my project by myself, but port of Bullet most likely is preferable.

I make small demo, with box, bordered by 4 static planes, and several (7-10 is enough) bolls moving in it (billiard, you know). No friction, no gravity, DiscreteDynamicWorld, AxisSweep3 broadphase, SequentialImpulseConstraintSolver, and so on -- mostly copied from your demos. And it shows quite strange behavior.

 1. Energy ( =sum(m*v^2/2) ) does not conserve. Even not close to it. Every collision change total energy of system. For my expirements it's constantly increase, so, after 5000 iterations or above energy increases about 30 times! Even if I decrease simulation step to 0.0001 and use rather small initial velocities (about 5-7m/s). I've noticed, what 1 ball, even with step 0.01 is rather stable in it, so errors seems to rooted in sphere-sphere collisions.

 2. Although sphere-sphere and sphere-plane collisions are totally symmetric (forces are applied to mass center), and they was not given initial rotation (angular velocity), after collisions angular velocity tends to grow up. It means, angular momentum is also not conserve. I do not know, may be it's known limitation of used algorithms, but it also may indicate some errors in it. Again, 1 ball is rather stable in it, so it seems to be a feature of sphere-sphere collisions.

Well, it seems, (http://www.ibm.com/developerworks/java/library/j-jtp09275.html) that java 1.6 already has such feature like escape-analyze based stack or even registry allocation.

I'm sure, it's the question every developer thinking about integrate the library ask first

Well, yes, JIT and GC becames more and more powerfull each day rise. Years Sun engineers adviced not to use object pools just to improve memory allocation, 'cos it does not give the bonus, but only confuses new GC algorithm (it was time generation GC was introduced). So, after years, I was surprised you was able to gain perfomance bonus from such a method, but it is -- and why do not expose it to community? May be it will speed up Sun's JIT enchancements at least

But if do this, it should be done in the way, which can be easily rolled back if JIT at last become smart enough to do the job by itself. I'm near to sure, what code like this

will greatly complicate escape analyze job for such "smart" future JIT. So in current version, gaining perfomance bonus for now you'll likely close the way for you code to gain perfomance boost from future compiler allocation optimization.

By the way, can you summarize the perfomance boost you gaining now? Just to be oriented in then and there to use you library

Yes, sorry, I've forgot about exact syntax for statement annotations -- they are rarely used, as for me.


Well, I agree, your point of view is completely legitime. I just think it's more about your specific use case. As far, as I understand, stack allocations was a critical feature, letting you to port C code to java without great rewritting it to refactor memory usage strategy. So it's really "something special" and "core feature" in your case. But if you want your library to be public used (as for me, it worth it -- it's small, easy, and do the work well -- that's more?), just try to look at it from point of view of developer, thinking about incorporate stack allocations in existing code. In current form, it can't be called non-obtrusive. One should make rather big changes in code, and live with fact, that code won't be ran without instrumentation.  It's makes a high barrier for such decision. From other side -- add annotations to some of statement is not a big deal. Anyone can just do it and be sure, what without special processing such annotations do change nothing in current behavior (and, most probably, even completely removed by obfuscator, if used). As for me, it makes decision "to use or not to use" much easier.

For example. Ive' just downloaded JBullet and exploring sources. I can't run it from my IDE without instrumentation -- although I just want to debug it to clearify code paths, and it's ok for me to have code run slow...

As for "changes the memory behaviour a lot" -- well, think of it from that point of view: memory behavior may be changed a lot by jvm GC options given at startup. It's gives you, in some cases, really big changes in memory behavior, and you really do not see nothing about it in code. It can be chaned by JIT -- and, again, you'll se nothing about it in code. It's java -- memory behavior is much less predictable at all, and I think, most java developers already learn to live with it. You even can't be sure, that new Vector3f() do not actually do the stack allocation by itself -- being optimized by JIT (well, may be for now you can -- such optimizations usually described in Sun's jdk's preview -- but for future... we all waiting for it). If jdk1.7 (8,9..) will include such optimization, one can just remove instrumentation step from it's build process, and letting jit do it's best. While currently one's left with some "strange" legacy code in allocations, which can confuse JIT in it's optimization, and confuse junior developers in understanding "wtf is happens here and why?"

To summarize -- I suppose, annotations-based instrumentation can be added as an option. If someone want stack allocation to be explicit -- it'll have such option. If for someone it'll be easier to add it in non-obtrusive way -- the option will also be here. Nobody can escape. Your library will conquer the world! At least, java part of it

Excellent work, jezek! JBullet at all, and JStackAlloc particular is very interesting. But I have a thought and idea -- why it's so explicit in code level? If you already use so powerfull method as bytecode instrumentation, why not use it like this:


and translate in into the same magic on instrumentation phase? From my current point of view, annotations gives you the same possibilities, as your explicit Stack.alloc, but they

• have no influence on perfomance in case code not instrumented. They just slightly increase class-file size
• do not require instrumentation. If code not instrumented, it just execute as written.
• one can use instrumentation in realtime -- on classloader level, and even switch between optimized/not optimized version in realtime!
• it's subject for more compile-time checking. For example, code like Vector3f = @StackAlloc new Vector3f(v1) simply won't compile, if Vector3f does not have copy constructor. (Unfortunately, it does not save us from missing or misimplementing .set(Vector3f) method...)
• it's declarative, for me it looks much more elegant

That do you think?

Ruslan