Re: [Chicken-users] Best way to share memory between C and Chicken

2013-05-06 Thread Felix
 Nevertheless: maybe it would be feasible to do all second gen
 gc in a dedicated thread and force a minor gc before passing data
 between threads?  Would it?

Unfortunately, execution and garbage collection are tightly interleaved
in the cheney-on-the-mta model. 

But the idea is intriguing. Implementing it would be the usual hell,
of course. Yet it sounds like something one should think
about. Very interesting.


cheers,
felix

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users


Re: [Chicken-users] Best way to share memory between C and Chicken

2013-05-06 Thread John Cowan
Felix scripsit:

 Unfortunately, execution and garbage collection are tightly interleaved
 in the cheney-on-the-mta model. 

Minor collection is, but major collection could be run in a separate
thread so that it can run concurrently (even on a second core) with the
rest of the program.  As it happens, I was reading about a concurrent
GC just the other day which sounded interesting -- and just happens to
be named Chicken, how cool is that?

http://www.cs.technion.ac.il/~erez/Papers/real-time-pldi.pdf

-- 
John Cowan   http://ccil.org/~cowanco...@ccil.org
We want more school houses and less jails; more books and less arsenals;
more learning and less vice; more constant work and less crime; more
leisure and less greed; more justice and less revenge; in fact, more of
the opportunities to cultivate our better natures.  --Samuel Gompers

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users


Re: [Chicken-users] Best way to share memory between C and Chicken

2013-05-06 Thread Dan Leslie

*cringe*

This will certainly expose what is and is not thread-safe within 
Chicken. I've worked with a /team/ in implementing such behaviour in the 
Unreal engine, albeit a frankenengine of sorts, and with three dedicated 
programmers the endeavour required about a month. But we had the benefit 
of knowing the totality of the code's usage, whereas implementing such 
behaviour could break all sorts of applications written for Chicken Scheme.


OTOH, this would be an enormous boon to the flexibility of Chicken 
Scheme. If it were possible to safely run GC on separate threads, or at 
least have a sort of objective-C level of control over GC, it would make 
implementing native threaded applications far less... /hazy/


Just my two cents, but if the Chicken Team were to pursue this I'd like 
to see it as a major revision feature. IE, Chicken 5: now with very 
different GC behaviour!


-Dan
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users


Re: [Chicken-users] Best way to share memory between C and Chicken

2013-05-06 Thread Felix
From: John Cowan co...@mercury.ccil.org
Subject: Re: [Chicken-users] Best way to share memory between C and Chicken
Date: Mon, 6 May 2013 08:21:34 -0400

 Felix scripsit:
 
 Unfortunately, execution and garbage collection are tightly interleaved
 in the cheney-on-the-mta model. 
 
 Minor collection is, but major collection could be run in a separate
 thread so that it can run concurrently (even on a second core) with the
 rest of the program.  As it happens, I was reading about a concurrent
 GC just the other day which sounded interesting -- and just happens to
 be named Chicken, how cool is that?
 
 http://www.cs.technion.ac.il/~erez/Papers/real-time-pldi.pdf

Nice. What a coincidence. I'll have to read it.

But implementing a collector like this is such a major piece of work
that I don't see this ever happening. It took years to get the current
GC into a reliable state. Running the collector, even only for major
collections concurrently will need numerous changes.  Currently
existing headers in oldspace are modified with a forwarding pointer
and thus be invalidated during GC. Those forwarding pointers could
perhaps be moved into a separate table, but things don't stop
there. The mutator may destructively mutate already copied oldspace
data - these mutations would need to be tracked and properly applied
to the copies in newspace, and so on and so on. As Dan already pointed
out, there are countless places where thread-safety suddenly becomes
an issue.

In short: give me six months, fully compensated and you get something
that works like crap. :-)


cheers,
felix

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users