Project Planning May 16, 2018

• Sprint 9 is 4 weeks.  Keep up the pace! 

Michael Stay (Unlicensed), Timm Schäuble

Henry Till

Kyle Butt

• Rosette VM is not multi-threaded. Threads that are running need to keep track of a shared parent context and then write the result into the shared memory. The decision to move forward with the mutable style will make this straightforward. 
• Optimizing Rholang to support this would be a deliverable in Venus.
• When compiling from Rosette to Rholang they need to work through the tuplespace independently.
• At the moment RSpace logs the entire tuplespace. 
  • This could create a performance issue 
  • Is it possible to log individual rows of the tuplespace and not the whole thing?
• What's the story of the threading on the Rholang interpreter, and how does this fit in?
  • It's by design that the interpreter is not multi-threading and captured as a bug https://github.com/monix/monix/pull/670. Mateusz is working to resolve in RChain code.
• To support multi-threading there will need to be architectural changes to RSpace. This would not touch history and rollback. It would impact checkpointing.
• Next steps
  • Will need to do performance testing to prove we can achieve required scale with a single writer. (task - test performance of a single writer)
    • Hinges on completion of produce and consume in RSpace and completion of metrics in Node
  • Kelly Foster schedule this testing as part of Node v0.5 release plan

• Kyle to review the /wiki/spaces/ROS/pages/437223478
• There is a requirement for the ability to compile down to Roscala op-codes from Rholang (VM requirement)
  • Kyle cannot start work to test this until Roscala is complete
  • Roscala is not set to be complete until Sept.
  • This means this the ability of the VM to compile down to Roscala op-cose from Rholang is not likely to be delivered with Mercury.
• It is possible Kyle may be able to start work on primitives in Aug. to support