> > 1. Heavy churn of memory usage. Bumping a heap pointer is significantly > faster than malloc/free. Yes, you can duplicate this in a non-managed > language using e.g. placement new in C++. You're basically just making > your language a little bit more managed to achieve this though, and it's > remarkably easy to royally screw it up when you do so. > Right, but with a non-managed language you achieve a more deterministic runtime experience. So yes, one does have to be careful about how often to ask the kernel for memory, but at least it can be handed back to the OS again when no longer needed (unlike how the JVM behaves).
> 2. A managed language will optimise jit compilation based on runtime > metrics. These will change based on runtime data, and the framework can > even make a speculative (but beneficial) optimisation, then revert if it > turns out to be inappropriate. A statically compiled language simply > doesn't have this opportunity available. > We're then stepping into this non-deterministic world where nothing is guaranteed. The problem that JIT compilers face is that of time constraints, they need to optimize but without incurring significant overhead to the *running* application. Android is pretty smart about this and tries to mitigate the overhead by offering pre-compiled applications (ODEX files) as well as serializing the JIT-traced code to the Dalvik cache. However, none of this really matters to a user who just notices that scrolling around the screen in a browser, PDF or ebook reader feels snappier on an iPad than on an Android tablet. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/HVJPRD3qFGkJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
