[Mono-dev] boehm and pin to sgen and moveable

[Jonathan Mitchell]

Robert

> On 4 Oct 2015, at 19:02, Robert Jordan <robertj at gmx.net> wrote:
> 
> Hey Jonathan,
> 
> On 03.10.2015 16:25, Jonathan Mitchell wrote:
>> 
>> 
>> Under the Boehm collector objects seem to stay pinned as requested.
>> Under SGEN they don’t i.e.: the exception in the second method below raises i.e.:  self.monoObjectTrace != (NSUInteger)monoObject)
>> 
>> What am I doing wrong?
> 
> It depends on how your methods are actually used.
> 
> In setMonoObject, there is a time frame between
> 
> mono_gchandle_free ()
> mono_gchandle_new ()
> 
> where the GC might regain control and move the object.

Thanks for the reply.
I took another look at this and excluded the possibility of the GC moving the object in a time frame (setMonoObject is publicly private and is only set internally within the class once.)
The issue does not appear when using libmonoboehm, only libmonosgen.
I must be screwing things up somewhere. The issue is 100% repeatable.

I would like to use sgen as it is getting all the TLC now.

I build my own 64 bit runtime for OS X - current up to date with 4.0.4.4.
I note that the existing 32 bit framework packages for OS X still link to libmonoboehm by default (thats where the framework bundle Mono symlink points to)
I will try adding moveable memory support to my bridge code as well and see how that goes.

With regard to moveable memory:
I use mono_object_hash() to key MonoObject * instances as it stays constant through the MonoObject lifetime, even for moveable objects.
The mono_object_hash() key is used to look up a possible NSObject match, testing on -MonoObject equality for each item in the bucket to establish uniqueness.

To test this out I plan to generate a bunch of objects (occupying > than the SGEN nursery area allocation of 4MB).
Then collect with 
mono_gc_collect (mono_gc_max_generation ());
and validate that movement has occurred na is correctly handled.

Does that sound sensible or daft?

J