EBFE (x.delete@this.y.com) on November 26, 2012 1:24 am wrote:
> Background != Free
> App has to run slow interpreter/baseline compiler.
> Background compilation has a large working set and seriouly competes for LLC.

Background compilation means, when nothing else is using the processor, like, for example, during recharging, who cares about LLC when not using it?

> No, collecting short lived objects is expensive.

So, let's split short lived objects in two categories, those wich the compiler can prove can be allocated at the stack, where allocation and collection are free, but only a few VMs do this, and those wich are collected in the gen 0, and the collection cost is not being copyed to gen 1, once I heard from a VM programmer that they did not implement the logic to allocate objects in stack because gen 0 collections are so cheap that, in the end, there was no measurable performance difference.

> Copying is expensive.
> To make copying possible is also costy.

Copying is done on modern processors at a rate of 8 bytes per cycle or so, pointer derreference is done at a rate of one per 4 cycles, so copying is very cheap.

> However it does hurt throughput.

When there is a single thread of the app running use concurrent GC, when all processor threads are full use a non-concurrent GC, wich part of my previous statement is so hard to understand?

> Allocators waste space.
> VM allocators have no magic over C++ allocators, except that you can't customize.

VM allocators move objects arond to fill memory holes, C++ allocators can't.

> Such small cost accumalates and it results in visible penalty.

Ok, lists other small costs to see how much it accumulates

> Totally irrelevant.

Side note, sanity check as well, to avoid so many claims that C++ is fast by the spec because the spec treats almost everything as undefined behaviour, for our pleasure no compiler do the same.

> So you elaborated that VM has overhead because it has to take more care than C++.

You must take more care when reading.

> How can you know if there is a registered handler?

There is a try...catch block arround the code when there is a registered handler.

> C++ needs 0 check.

True, that's why almost every security flaw are in C/C++ program and almost every shipping C/C++ program is plagged by a security flaw at some point of it's live.

> The optimizer usually has to leave some check uneliminated unhoisted.
> And even redundant checks is diffcult to eliminate.

Yep, there are some proposals to make redundant checks easier to remove, but fortunally the optimizer is able to remove some of them.