[m-rev.] for review: Add support for weak pointers to the C RTS
paul at bone.id.au
Tue Jul 22 14:16:59 AEST 2014
On Sat, Jul 19, 2014 at 11:45:33AM +1000, Peter Wang wrote:
> On Fri, 18 Jul 2014 14:55:11 +1000, Paul Bone <paul at bone.id.au> wrote:
> > On Tue, Apr 15, 2014 at 10:20:01PM +1000, Paul Bone wrote:
> > > For review by anyone.
> > >
> > No-one has reviewed these changes in the last three months so I've committed
> > them:
> > + Make version_array's rewind code use constant stack space.
> > + Add missing MR_GC_malloc_atomic procedure
> > + Add support for weak pointers to the C RTS
> Hi Paul,
> Sorry for the late comments. Please post a reminder next time.
> I don't like that users who don't use rewind have to pay for it on every
> update, in creating the weak pointer, and whatever overhead that might
> add to GC elsewhere. For users that retain old versions, the size of
> each ML_va also increases from 4 words to 6 words after rounding.
That's a fair point, I was concerned about this but I hadn't thought hard
enough to come up with another solution that I was also happy with. I'm not
happy about reversing the order of the pointers that you suggest in your
next e-mail, that seems too costly/fiddely for the rewind operation.
> An alternative solution would be to allocate a bit array to mark off the
> elements that have been restored already, as you iterate forwards from
> the oldest update to the newest. If the i'th bit is set then the i'th
> element of the version array was already restored to an older value, so
> just ignore the current update. No prev pointers required.
I do like this solution. It should be at least as quick as my changes and
at least as quick as the previous solution. It may even be faster.
I'll implement this and submit a patch for review. I may need help testing
the C# backend as my mono installation is broken due to the Boehm GC
bug/libc bug. I havn't yet patched either my C library or my non-Mercury
More information about the reviews