3 ms·
I've played around with it. It doesn't seem like a huge perf boost and would require a lot of dev work -- people who want value semantics use value types and th
by Locke1689 12y ago
I've played around with it. It doesn't seem like a huge perf boost and would require a lot of dev work -- people who want value semantics use value types and the CLR can do better analysis then we can (e.g., across assemblies).
- bad_user 12y agoI think on the JVM's escape analysis was originally introduced to get rid of intrinsic locks, a task it does really well - something which I can say after countless of benchmarks I made trying out different synchronization strategies. Currently it's really hard to beat the JVM's intrinsic locks (i.e. the synchronized block), precisely because of this - because if the JVM detects that some piece of code is single-threaded, then it eliminates the lock completely. I think stack-allocated values by means of escape analysis done at runtime is just an extension of that. Also, escape analysis, theoretically at least, goes beyond what one can do with value types. For instance functional/persistent data-structures are guilty of generating a lot of short-term junk and because internally these data-structures are represented as trees, you need references for linking the nodes together. On the whole I am pleased with how well the JVM handles short term junk, whether escape analysis plays a part in it I don't know.