[M3devel] heapalloc/try during initialization

[Jay]

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
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diff.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090506/14887e03/attachment-0001.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: RTCollector.m3
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090506/14887e03/attachment-0001.ksh>