Comments on Useless Factor: An idea for garbage collection research

Anonymous,To your first question, I didn't mean to...

2008-06-25T14:02:00.000-07:00

Anonymous,

To your first question, I didn't mean to imply that. I should change the wording.

To your second question, it seems that, in practice, virtual read barriers through temporary memory protection is much, much, much more efficient than actual read barriers. This is only true if traps are sprung rarely, which should be true in well-designed collectors. Write barriers for things like keeping track of old to young pointers, or for maintaining the tricolor invariant during incremental/concurrent marking, don't seem so bad. Sapphire hasn't been benchmarked enough, though, to know if it's actually faster than Appel's concurrent copying collector using memory protection. (There is no publicly available implementation, unfortunately.)

First of all, I really appreciate you writing this...

2008-06-25T13:26:00.000-07:00

First of all, I really appreciate you writing this blog!

Now, I have a few questions:

When you said
"One idea is that this would be useful for large servers with many cores that are under memory pressure. Existing algorithms which depend on page faults can be slow when those faults occur."

Were those two seperate thoughts, or are you implying that GC's that use page faults perform slower on large heap/multicore boxeS?

My second question is regarding the choice of read or write barriers vs. page faults for concurrent copying.

Though a page fault is much less performant then a barrier when it occurs, how does it compare to the overhead of having barriers on *all* pointer/reference/object read/writes (Which I believe is neccessary for concurrent collection, no?)

I would love to hear your thoughts on this or if you have any suggestions on papers which adderss this question, I'd love to read those too.

James,Oops, I suppose that when you said "shared m...

2008-06-11T14:35:00.000-07:00

James,

Oops, I suppose that when you said "shared memory" you meant "shared memory". My bad. Anyway, adapting GC algorithms to non-shared memory is orthogonal to the problem I'm trying to solve, which is to make a fast concurrent compacting GC with minimal space overhead. It could be used in an environment with non-shared memory. But maintaining lots of little separate heaps isn't always a good idea, as it can cause external fragmentation if done badly.

I'm only using "shared" memory in the context of s...

2008-06-11T13:47:00.000-07:00

I'm only using "shared" memory in the context of shared versus lock-free thread-specific memory as in Erlang. Also in Dos days we had a couple of simple but very useful tools for memory isolation - mark/release in Turbo Pascal, and multiple subheap capability in TS Modula-2.

James

I'm sure they'll maintain relevant for a good whil...

2008-06-11T13:26:00.000-07:00

I'm sure they'll maintain relevant for a good while. I'm not sure exactly what you mean by "shared" but if you mean uniform access, I don't think I'm smart enough right now to make an efficient garbage collector for NUMA architectures which takes into account the non-uniformity of memory access times. I'd imagine it'd take a shape similar to distributed memory designs. This is my first project. Anyway, I don't have a NUMA machine to play around with; people don't really use them yet.

Daniel,It would appear that you're focused on GC f...

2008-06-11T11:44:00.000-07:00

Daniel,

It would appear that you're focused on GC for shared memory environments. Do you think shared mem environments will maintain the same relevance for future software development?

James