[Mono-devel-list] Typed allocation facility in runtime

[Paolo Molaro]

On 04/07/03 Dick Porter wrote:
> > When I'll convince Dick to put a list of synch structs in the thread
> > object, we'll also be able to remove that bit from the bitmap and
> > strings will be pointer-free, too:-)
> 
> Do you mean the MonoThreadsSync *synchronisation field in MonoObject?
> 
> I'm open to suggestions on how to improve that, but it has to be
> accessible from the MonoObject * without having to scan a list held
> somewhere else, or theres no point optimising the monitor locks :)

Currently a MonoThreadsSync struct is allocated when an object is
locked. We currently don't remove the sync struct from the object,
but for some workloads this behaviour is not very good: we could have
tons of in-memory structs that may be completely unused and won't be
freed until the object that holds them is freed.
The idea is to remove the sync struct from the object on monitor_exit()
and putting it in a list inside MonoThread. Adding an item or retrieving
it from this list is lock-free, since it's done in the current thread,
so it will be pretty fast. The number of existing locks will be equal to
the maximum number of contemporary locks held and that is likely going
to be a small number. This trick will also limit the number of requests
to the memory allocator since most of the time a sync block will be
ready for use in the current thread's list.
MonoThread is tracked by the GC and so would be the sync struct list,
hence we can tell the GC that most objects don't reference pointers.

lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better