3 ms·

The absolute most interesting thing about Chicken Scheme is the way it does allocations and garbage collection. I've wanted for a long time to make the time to

The absolute most interesting thing about Chicken Scheme is the way it does allocations and garbage collection. I've wanted for a long time to make the time to add a always-on cpu and memory profiler to Chicken Scheme that just tallys the "return" addresses during the gc, meaning at each cg cycle you have a pretty darn good tracing profiler, and keeps the "return" addresses in cells when they are moved off stack, so at any moment you can blame your memory usage on particular code. Clearly you could do this sort of thing with a lot of runtimes, but Chicken's design really lends itself to it.

pmelendez 14y ago
It really does. This dissertation explores the differences with other implemantations [PDF] http://www.cs.indiana.edu/~dyb/papers/3imp.pdf http://www.cs.indiana.edu/~dyb/papers/3imp.pdf
- tsewlliw 14y ago
  I'm totally going to read that. Also, I'm really interested in the debug-ability of Chicken. Instead of a stacktrace, which sort of captures "where you're going", a stacktrace in Chicken captures "how you got here", which in conjunction with using immutable data structures would make the most absolutely amazing blob of data to be sent back by a customer - you could potentially restart execution with their data and step thru.
pi18n 14y ago
Chicken allocations and GC are a really great compromise between heap and stack memory. I've been looking into GC implementations recently and it's one of the most interesting. Another one I think is interesting is Lua's with the "upvalues" -- objects are on the stack unless they survive the frame they live in, in which case they are moved to the heap. But they implement it with a double dereference, so it has its own downside.
hga 14y ago
Chicken Scheme and it's use of Baker's "Cheney on the M.T.A." allocation and GC is intensely neat ... but correct me if my analysis was wrong: isn't it inherently single threaded? (No problem for a lot of people, but my particular area of interest is making SMP/ccNUMA systems sing. In Lisp. :-)
- cryptonector 14y ago
  Any time you have closures you have threading issues. Think: if two threads call the same closure concurrently, how do they synchronize access to closed variables? I don't know if Chicken Scheme allows multiple distinct instances of the run-time in one process -that would be very cool, and if anyone knows please do tell here-, but it can't safely support multi-threading any more than any standard Scheme can. To get what you want in a Lisp you need to apply either Erlang concepts (threads with distinct global namespaces, exchanging serialized data via messaging) or Clojure concepts (immutable state + COW techniques + special top-level, mutable variables with synchronization for all mutable state; but I repeat myself, since that's roughly what COW implies).
  - rayiner 14y ago
    > Any time you have closures you have threading issues. Think: if two threads call the same closure concurrently, how do they synchronize access to closed variables? > To get what you want in a Lisp Several Common Lisp implementations expose pthreads-style shared memory threads (SBCL, ECL, Clozure, Allegro, etc). It works just fine. The problem of synchronizing access to the closed-over variables in a closure is precisely the same as the problem of synchronizing access to instance variables of a class, and has the same solution: use a mutex.
  - coldtea 14y ago
    >Think: if two threads call the same closure concurrently, how do they synchronize access to closed variables? Same way you do it in C/C++/Java etc with their threads? Not really a unique to closures problem. >(To get what you want in a Lisp you need to apply either Erlang concepts (...) or Clojure concepts Or this fancy CSP thing? (Is it similar to Erlang? I don't know Erlang).

pmelendez 14y ago

It really does. This dissertation explores the differences with other implemantations [PDF] http://www.cs.indiana.edu/~dyb/papers/3imp.pdf http://www.cs.indiana.edu/~dyb/papers/3imp.pdf

tsewlliw 14y ago
I'm totally going to read that. Also, I'm really interested in the debug-ability of Chicken. Instead of a stacktrace, which sort of captures "where you're going", a stacktrace in Chicken captures "how you got here", which in conjunction with using immutable data structures would make the most absolutely amazing blob of data to be sent back by a customer - you could potentially restart execution with their data and step thru.

pi18n 14y ago

Chicken allocations and GC are a really great compromise between heap and stack memory. I've been looking into GC implementations recently and it's one of the most interesting. Another one I think is interesting is Lua's with the "upvalues" -- objects are on the stack unless they survive the frame they live in, in which case they are moved to the heap. But they implement it with a double dereference, so it has its own downside.

hga 14y ago

Chicken Scheme and it's use of Baker's "Cheney on the M.T.A." allocation and GC is intensely neat ... but correct me if my analysis was wrong: isn't it inherently single threaded? (No problem for a lot of people, but my particular area of interest is making SMP/ccNUMA systems sing. In Lisp. :-)

cryptonector 14y ago
Any time you have closures you have threading issues. Think: if two threads call the same closure concurrently, how do they synchronize access to closed variables? I don't know if Chicken Scheme allows multiple distinct instances of the run-time in one process -that would be very cool, and if anyone knows please do tell here-, but it can't safely support multi-threading any more than any standard Scheme can. To get what you want in a Lisp you need to apply either Erlang concepts (threads with distinct global namespaces, exchanging serialized data via messaging) or Clojure concepts (immutable state + COW techniques + special top-level, mutable variables with synchronization for all mutable state; but I repeat myself, since that's roughly what COW implies).
- rayiner 14y ago
  > Any time you have closures you have threading issues. Think: if two threads call the same closure concurrently, how do they synchronize access to closed variables? > To get what you want in a Lisp Several Common Lisp implementations expose pthreads-style shared memory threads (SBCL, ECL, Clozure, Allegro, etc). It works just fine. The problem of synchronizing access to the closed-over variables in a closure is precisely the same as the problem of synchronizing access to instance variables of a class, and has the same solution: use a mutex.
- coldtea 14y ago
  >Think: if two threads call the same closure concurrently, how do they synchronize access to closed variables? Same way you do it in C/C++/Java etc with their threads? Not really a unique to closures problem. >(To get what you want in a Lisp you need to apply either Erlang concepts (...) or Clojure concepts Or this fancy CSP thing? (Is it similar to Erlang? I don't know Erlang).