[M3devel] heapalloc/try during initialization

[Tony Hosking]

I'm working on this today.  Let me get back to you.

On 6 May 2009, at 23:53, Jay wrote:

>
> Something like the attached?
>
> (I don't trust email to be formated as expected, so the attachment  
> is canonical and the rest might not be readable.)
>
>
> The idea is to provide a split CollectEnough for AllocTraced to call.
> It's a little lose on the locking but it should be ok and slows down  
> the slow path with extra unlock/relock.
>
>
>
> It's good to get the try out of the fast path in either case.
>
>
>
> PROCEDURE LockedCollectEnough (allocator := FALSE) =
>  BEGIN
>    TRY
>      CollectEnough(allocator);
>    FINALLY
>      RTOS.UnlockHeap();
>    END;
>  END LockedCollectEnough;
>
>
>
> AllocTraced calls this:
>
>
>
> PROCEDURE UnlockedCollectEnough (allocator := FALSE) =
>  BEGIN
>    RTOS.LockHeap();
>    IF collectorOn THEN RTOS.UnlockHeap(); RETURN END; (* duplicated  
> from CollectEnough *)
>    IF NOT Behind() THEN RTOS.UnlockHeap(); RETURN END; (* duplicated  
> from CollectEnough *)
>
> ThreadF.Init shouldn't get here:
>
>
>
>    LockedCollectEnough(allocator);
>  END UnlockedCollectEnough;
>
>
> AllocTraced slow path excerpt:
>
>
>    IF nextPtr> thread.newPool.limit THEN
>      (* not enough space left in the pool, take the long route *)
>      res := NIL;  nextPtr := NIL;  (* in case of GC... *)
>      DEC(thread.inCritical);
>      (* make sure the collector gets a chance to keep up with NEW...  
> *)
>      UnlockedCollectEnough(allocator := TRUE);  (***)
>      RTOS.LockHeap();  (***)
>      res := LongAlloc (dataSize, dataAlignment, thread.newPool,
>                        Note.Allocated, pure := FALSE);
>      IF res = NIL THEN
>        RTOS.UnlockHeap();  (***)
>        RuntimeError.Raise(RuntimeError.T.OutOfMemory);
>      END;
>      INC(thread.inCritical);
>      LOOPHOLE(res - ADRSIZE(Header), RefHeader)^ :=
>          Header{typecode := def.typecode, dirty := TRUE};
>      IF initProc # NIL THEN initProc (res) END;
>      RTOS.UnlockHeap();  (***)
>
>      DEC(thread.inCritical);
>      RETURN LOOPHOLE(res, REFANY);
>
>
> This is all for user threads.
> There /may/ have been issues with pthreads/ntthreads, but I don't  
> there are now.
> Your changed didn't break cygwin pthreads but it did break FreeBSD  
> user threads.
> I only checked each case once so might have made mistakes and gotten  
> it backwards or whatever.
>
>
> Ignorant question/suggestion similar to previous:
>  Thread.T vs. Activation? Userthreads does traced allocations where  
> pthreads/win32threads don't. Maybe change userthreads?
>  Maybe give up on userthreads? This isn't a great reason, granted.
>  I actually would hope the traced thread.t vs. activation could go  
> away, it is ugly. Kudos for user threads for not having it?? (I  
> wonder if there is something around the fact that thread locals  
> aren't visible to the garbage collector..?)
>
>
> - Jay<diff.txt><RTCollector.m3>