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

[Tony Hosking]

On 22 Sep 2009, at 21:51, Jay K wrote:

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

Yes, clearly I am missing something.

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

Right, it just takes GC out of the equation for what might be wrong.

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

Good.  We can debug that.

> It could just be Trestle not being fully supported on Windows.
> Olaf says Trestle was never fully ported.

I don't know enough about this to say either way.

> 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 does this mean?  That pre-2009-02 is just the same as  
post-2009-02?  How does that narrow anything down to that specific  
time-frame?

>  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".

I still don't understand what this says about that particular time- 
frame.

>  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. :(

If we have a deterministic failure then it should be easy enough to  
track down.

>
>
>  - 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/20090922/bb6e1204/attachment-0002.html>