[Vm-dev] debugging the garbage collector

[Noah Evans]

Thanks for your reply Eliot,

Compilation was not the problem so much as mismatched vmmaker interp
and cog vm. Having a canonical counterpart made my life easier because
then I knew I was breaking things by myself.

I haven't  changed the semantics if cointerp.

Plan 9 is easy from a threads perspective. Your only options are co
routines or fork. Co routine stacks and metadata are on the heap so
you don't have to worry. I ended up following your #define route which
worked well enough.

Noah

Sent from my iPad

On Feb 15, 2013, at 11:59 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:

>
> Hi Noah,
>
> On Fri, Feb 15, 2013 at 5:52 AM, Noah Evans <noah.evans at gmail.com> wrote:
>>
>> I've taken bert's advice and gotten the canonical svn tree. For the
>> moment I've gone away from VMMaker sources and started with the svn
>> tree's cointerp.c.
>
> I hope you're not considering editing cointerp.c?  That route is
> doomed to failure.  You need to start from the VMMaker and Slang
> source and generate legal C.  Does cointerp.c compile?  If not, what
> errors are you getting?  What's preventing compilation?
>
>> Once I have that working (most of it already
>> compiles, I just need to decide what to do with alloca--it's
>> unimplemented in Plan9 posix emulation).
>
> Hmm.  If Plan9 supports anything like a POSIX threads system then you
> may have to implement alloca.  The issue here is that Cog runs machine
> code in the stack zone which is usually allocated using alloca, and
> that alloca allocates memory on the C stack, so allocating the stack
> zone via alloca arranges that the stack zone is also on the C stack.
> Some (e.g. older linux) thread implementations derive the thread id
> from the stack pointer.  On these implementations it is essential to
> allocate the stack zone via alloca so that thread determination is
> correct within machine code.  Luckily this thread id being encoded in
> the stack pointer (because each thread gets its own distinct stack) is
> giving way to a more modern one using a segment register to implement
> the pointer to the thread control block.  So if you can't implement
> alloca and/or the thread system doesn't depend on the stack pointer
> for thread id, you can simply use malloc, e.g.
> #define alloca(n) malloc
>
>
>> I'll go back and work with
>> Spoon. I'm just trying to minimize the number of variables for the
>> moment. The svn tree has been really great in this regard.
>
>>
>> Can anyone point me to a contributing page for how to submit patches?
>> Or just to the mailing list proper?
>
> You can send patches to me.  I maintain (and authored) the Cog branch.
>
>>
>> Noah
>>
>>
>> On Fri, Feb 15, 2013 at 2:47 PM, David T. Lewis <lewis at mail.msen.com> wrote:
>>>
>>> On Fri, Feb 15, 2013 at 01:14:17PM +0100, Bert Freudenberg wrote:
>>>>
>>>> On 2013-02-15, at 11:27, Noah Evans <noah.evans at gmail.com> wrote:
>>>>
>>>>> Craig, which version of Cog are you using? I'm using the tip of the
>>>>> gitorious tree.
>>>>
>>>> Eliot's canonical sources are in subversion:
>>>>
>>>> http://squeakvm.org/svn/squeak/branches/Cog/
>>>>
>>>
>>> Oh dear, I suspect we may have some confusion here. Craig says:
>>>
>>>
>>>>     The current release of Spoon is 3 beta 3 (23 October 2012),
>>>> available at:
>>>>
>>>>     http://netjam.org/spoon/releases/current
>>>>
>>>>     It includes a Squeak 4.2 object memory (4 February 2011) with
>>>> VMMaker dtl.237 (23 May 2011) installed, and the Spoon VM changes
>>>> applied to that, and with remote browsing support installed. It runs on
>>>> the VM it generates, which is the only one supplied in the release (Mac
>>>> OS, Linux and win32).
>>>
>>> Noah, what platform sources did you start with? The VM that Craig
>>> describes would have been compiled with platform sources from the
>>> trunk VM (not branches/Cog). Those sources are at:
>>>
>>>  http://squeakvm.org/svn/squeak/trunk
>>>
>>> You would need to use a version of those sources from the early 2011
>>> time frame. But I would suggest very stongly that you get an exact
>>> copy of sources from Craig so that you are starting from exactly the
>>> same code base that he is using (or maybe that's what you meant in your
>>> question to Craig the about gitorious tree).
>>>
>>> Mixing generated source code from VMMaker trunk (e.g. VMMaker-dtl.237)
>>> with platform sources from branches/Cog will definitely not work.
>>> And mixing generated sources (from VMMaker) with platform sources
>>> (from Subversion) that are not from the same general time frame will
>>> probably not work.
>>>
>>> Dave
>>>
>
>
>
> --
> best,
> Eliot