Yes, I was thinking is such a thing. Each thread has a local heap and
you have a common shared heap too, with shared data in it.
Is such a case, the flag is suffiscient because then the GC could handle
that and trigger thread local heap allocation instead of shared one.
This is consistent with the swap friendliness I was talking about and
can reduce the need of synchronization when allocating memory (a lock
will only occur if the GC doesn't have any memory left in his pool for
the given thread).
And solve finalization's thread, yes.
Le 03/10/2011 22:54, Sean Kelly a écrit :
On Oct 3, 2011, at 12:48 PM, deadalnix wrote:
There's another important issue that hasn't yet been addressed, which is that
when the GC collects memory, the thread that finalizes non-shared data should
be the one that created it. So that SHARED flag should really be a thread-id
of some sort. Alternately, each thread could allocate from its own pool, with
shared allocations coming from a common pool. This would allow the lock
granularity to be reduced and in some cases eliminated.
I'd like to move to CDGC as an intermediate step, and that will need some
testing and polish. That would allow for precise collections if the compiler
support is added. Then the thread-local finalization has to be tackled one way
or another. I'd favor per-thread heaps but am open to suggestions and/or help.
