[M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse?

[Jay K]

Tony there is something a bit gray that you are missing.

 

 

The behavior with @M3nogc we don't necessarily consider bad/wrong/buggy.

  It is a consistent assertion failure. Not an access violation.

It could just be Trestle not being fully supported on Windows.

Olaf says Trestle was never fully ported.

I'm not sure anyone knows what is missing, and if Juno really demonstrates that or not.

 

 

However, versions before Feb 20 consistently act like current versions act with @M3nogc.

 Before Feb 20 without @M3nogc.

 Current with @M3nogc.

 

 

What I'd like to see is current without @M3nogc to act just as bad but no worse than before Feb 20. I think the current behavior without @M3nogc is worse. It's just "fail vs. no fail".

 

 

Now, that is apples and oranges. For example, I relatively recently changed the default initial allocation size and maybe incremental allocation sizes. In particular..I forget the exact details but I think changed from malloc to VirtualAlloc, and VirtualAlloc allocates in 64K chunks. I guess I should review that..but that was more recent I think, after Feb 20. I have to check.

The code was a bit flawed somehow and I improved it somehow. I forget. Almost everything is subject to rerererereview when there is a bug, granted.

 

 

I agree as well that Feb 20 might have just uncovered a preexisting problem.

 

 

But much is unclear and figuring this out I don't think will be easy. :(


 

 - Jay


 


From: hosking at cs.purdue.edu
To: jay.krell at cornell.edu
Date: Tue, 22 Sep 2009 21:40:27 -0400
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] CM3 5.8 Release Engineering, was Re: back again -- cm3 status worse?








On 22 Sep 2009, at 08:16, Jay K wrote:

Yes there is fairly definitely a problem on Windows and it dates, I think, to this change:
 
 
2009-02-16 02:20  hosking
  * m3-libs/m3core/src/: Csupport/VAX/dtoa.c, Csupport/big-endian/dtoa.c,
    Csupport/little-endian/dtoa.c, convert/CConvert.i3,
    convert/CConvert.m3, runtime/I386_DARWIN/RTThread.m3,
    runtime/common/RTCollector.m3, runtime/common/RTHeapRep.i3,
    runtime/common/RTOS.i3, thread/POSIX/ThreadPosix.m3,
    thread/PTHREAD/ThreadF.i3, thread/PTHREAD/ThreadPThread.m3,
    thread/PTHREAD/ThreadPThreadC.c, thread/PTHREAD/ThreadPThreadC.i3,
    thread/WIN32/ThreadWin32.m3:
  Clean up RTOS.LockHeap/RTOS.UnlockHeap implementations to better match underlying pthread semantics.
  This means that RTOS.WaitHeap must be called while RTOS.LockHeap is held.
  RTOS.BroadcastHeap can be called whether RTOS.LockHeap is held or not.



I'm not convinced that this change itself broke things, but perhaps instead exposed the brokenness.  In any case, debugging this in the head will probably be easiest.  If we have an example that deterministically breaks then I think we have a place to start.  My suggestion for now, since it appears to trigger the problem, is to use @M3nogc.

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090923/7dd05c47/attachment-0002.html>