4 ms·

Sounds like fascinating work. I would have expected big unpredictable performance problems from using a read barrier to lazily fixup references to moved objects

Sounds like fascinating work. I would have expected big unpredictable performance problems from using a read barrier to lazily fixup references to moved objects, given how expensive each page fault is in a superscalar pipeline. But it's hard to recommend a vendor who's opaque about pricing. If we have to ask, we probably can't afford it.

runT1ME 16y ago
If i'm not mistaken, the 'read barrier' is only active during a mark of the heap, not all the time. So, considering that marking can be parallelized and there's a good chance a lot of the heap is now dead objects (you only mark live ones) you shouldn't be too affected.
modeless 16y ago
Page faults are usually expensive because the bits you need must be read in from disk. In this case the bits you need are still in RAM, and could even conceivably be in cache. It's probably not tremendously more expensive than a cache miss (which is still quite expensive, but hopefully the collector is fixing up pointers fast enough that actual page faults are relatively rare).
- binaryfinery 16y ago
  They'd be about as expensive as throwing an exception. And the live objects would, I assume, quickly pull all the other live objects into the active pages. I love this hack.
  - danvet 16y ago
    Furthermore they're using 2mb pages instead of the usual 4kb (on x86). That cuts the overhead by a factor of 512 alone. The remaining problem I see is cache-trashing because on every minor page-fault you have to run a part of your mark&sweep algo, surely kicking out all the application data&code from caches. That's inevitable less efficient than a stop-the-world approach.
schumihan 16y ago
On their hardware appliance, they use a special instruction to implement the barrier. For software appliance, the performance may be a real problem.
ggruschow 16y ago
To be fair, if you've got a budget that supports a multi-developer team and you fundamentally need their solution, you can afford their prices. They're not insane, and if you just ask they're not opaque. On the other hand, did you know you can turn off the garbage collector on CPython?

runT1ME 16y ago

If i'm not mistaken, the 'read barrier' is only active during a mark of the heap, not all the time. So, considering that marking can be parallelized and there's a good chance a lot of the heap is now dead objects (you only mark live ones) you shouldn't be too affected.

modeless 16y ago

Page faults are usually expensive because the bits you need must be read in from disk. In this case the bits you need are still in RAM, and could even conceivably be in cache. It's probably not tremendously more expensive than a cache miss (which is still quite expensive, but hopefully the collector is fixing up pointers fast enough that actual page faults are relatively rare).

binaryfinery 16y ago
They'd be about as expensive as throwing an exception. And the live objects would, I assume, quickly pull all the other live objects into the active pages. I love this hack.
- danvet 16y ago
  Furthermore they're using 2mb pages instead of the usual 4kb (on x86). That cuts the overhead by a factor of 512 alone. The remaining problem I see is cache-trashing because on every minor page-fault you have to run a part of your mark&sweep algo, surely kicking out all the application data&code from caches. That's inevitable less efficient than a stop-the-world approach.

schumihan 16y ago

On their hardware appliance, they use a special instruction to implement the barrier. For software appliance, the performance may be a real problem.

ggruschow 16y ago

To be fair, if you've got a budget that supports a multi-developer team and you fundamentally need their solution, you can afford their prices. They're not insane, and if you just ask they're not opaque. On the other hand, did you know you can turn off the garbage collector on CPython?