Skip to content

Meeting Journal

Jump to bottom Edit New page
ramLlama edited this page Dec 18, 2013 · 10 revisions

Meeting Journal

December 3, 2013

  • Parallelize Makefile

    Currently, make does not work in parallel mode (-j<n> where n > 1). This makes compilation and regresssion testing extraordinarily slow. Supporting parallel make should speed things up greatly.

December 10, 2013

  • How does Spoonhover deal with parallel GC?

    • Maybe email him?

    • Conjecture: Parallel allocation with sequential GC

      It seems possible to assigns a private “heap” to each processor. Each processor allocates in this heap. this heap can further be partitioned into a nursery and an older generation. Due to generational collection, MLton must keep track of the pointers from old to new (nursery) in a write set. Now each processor can maintain their heaps but when one needs to collect a nursery — this is called a minor collection in MLton speak as far as I recall — all processors can synchronize and they can all do a minor collection bun this collection has to be sequential. A major collection is not necessary because with the write sets will make a minor collection possible. Similarly for a major collection all processors can synchronize. this enables parallel allocation but no parallel GC. It is interesting though that minor GC can be performed without major changes to the architecture of the heaps.

  • Use Github wiki for Meeting Journal?

  • Parallel Semantics

    • Look at Manticore for parallel semantics

      Despite not being as restricted as ours, may have some good ideas and edge cases to consider.

    • Exception Semantics

      • Different possibilities regarding semantics consistency across sequential, single-core, and multi-core execution

      • Have to consider how to handle side-effects

      • Have to consider how to handle non-terminating threads

      • May also need to consider when threads are independent and exception in one shouldn’t affect the other (e.g. interactive programming)

      • What Spoonhover considers a deviation from “sequential semantics” may really be about exception semantics in a parallel context.

      • Some ideas

        • Follow the sequential semantics.

        • Have a parallel semantics that is separate. The parallel semantics would not have to kill parallel threads running when one raises an exception but would instead wait until they complete and pass a sequence/list of exceptions/results up. This seemed like a non-desirable choice at first but in a program with side effects or concurrency, this might be the right thing. For example, you would not a server to kill all communication with clients just because one thread raised an exception.

December 17, 2013

  • Tentatively confirmed that Spoonhover’s version does parallel allocation with sequential GC

    • Is GC per-processor or per-thread?

    • Is there a global nursery?

    • How is tracing multiple stacks handled?

  • Spoonhover’s version exposes multiple threading models

    • Try to enumerate what is supported. Include any preexisting models that MLton had

    • How does Spoonhover modify and use MLton.Thread?

  • Stack handling

    • There are multiple ways to do this, each with their own set of challenges

    • What did Spoonhover do?

    • Possible challenges with keeping track of stacks in a work-stealing model.

Add a custom footer
Add a custom sidebar
Clone this wiki locally