Am Montag, den 03.12.2007, 21:16 +0100 schrieb Christophe Raffalli:
> Now the point is this: each mini-thread has its own minor-heap whose
> size is given as the first argument with the following restrictions:

What could work is that you really switch to a copying collector. That
means that there are two minor heaps of fixed size, and a minor GC
copies one heap to the other. While one heap is used, the other is
unused. Every coprocessor would have such a pair of heaps. Of course,
this means that:

- You have very limited memory, and you have to set its max
  size in advance. This heap cannot be extended as needed.
  But this is ok for a coprocessor.
- You waste half of the memory. E.g. if you want to have
  64 K of heap, you have to buy 128 K. On the other hand,
  this saves a lot of code in the OCaml runtime, surely
  more than 64 K, so this is a net win.
- Maybe even this works: The minor GC is done by the main
  processor, and the other heap is also there. This could
  work if the GC is not invoked too often.

Such a copy collector is very small (the minor_gc.c file in the runtime
has less than 300 lines, so you could have a miniature memory manager in
only a few K). If you remove most features of the OCaml runtime, there
are some chances that it really fits into the remaining memory: no I/O,
no generic comparison, no backtraces, no MD5, no lexing, ... You
couldn't use these features in the SPU anyway. From the stdlib I would
only keep arrays and strings (no lists), and add a communication channel
with the main processor.

Of course, programming in this context then does not make any fun. I
mean you'll get stack overflows really quickly. Maybe you can run very
simplistic algorithms. On the one hand I really have doubts whether it
makes sense to run OCaml in such an environment, but on the other hand
it's fun to have such a thing at all...

Gerd
> 
> 1) the minor heap is used as a cache : access to  the major heap copy
> the data in the minor heap. One need to mix the copying
> minor GC with standard caching algorithm.
> 
> 2) to ease the task 1), mutation of data in the heaps of the main thread
> by a mini-thread is illegal (raises an exception in the main thread ?
> Static check ?). This includes the arguments of the mini-thread.
> 
> 3) a mini-thread can not start another mini-thread (raises an exception
> in the main thread ? Static check)
> 
> 4) 2-3) imply that a mini-thread can not access data of other
> mini-threads and that the only way for the main thread to
> get values from a mini-thread is via their 'b result_channel. Thus, if
> you have a main thread M and many mini-threads T1 ... TN
> runnnig, Ti can only acces its own data and the data of M (read only).
> And, M can not acces the data of T1 ... TN.
> 
> If you launch one minithread per SPU or CORE with a minor heap of the
> correct size and you fine tune you application to produce not too much
> cache misses, then, I think this simple model could be usefull ????
> 
> Cheers,
> Christophe
> 
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
Phone: +49-6151-153855                  Fax: +49-6151-997714
------------------------------------------------------------