On 2011-03-30, at 6:53 PM, chevalma@iro.umontreal.ca wrote:
I would, however, like to propose something else. I would like to volunteer to write the image writer/loader. I would also like to implement the writer in JavaScript. I think that this could help me expose tricky issues that will potentially come up while the GC is being written. I also think that it could be beneficial if I do this around the same time Erick is writing the GC, as we would be able to discuss technical issues that affect both. I would also need the same back-end support the GC will need.
I'm enthusiastic about doing this, I know the system well, and I think I've shown I can be pretty productive. I'm confident it could realistically be done fairly quickly, no slower than the GC will take to be completed. I will also argue that doing this in JS is less bug-prone than the GC, as it will not need to destroy the current heap, we can trigger serialization whenever we want (as opposed to the GC) and the output file can be examined easily using external tools.
What do you think?
Well I guess it depends on what an "image" is. But it sounds reasonable to write the image writer in JS. For one, we already have a JS representation for the machine code, which is the bulk of the information to dump. Moreover, we can easily implement I/O primitives to write binary files. One thing we should discuss as a team is the format of the image. Not only the layout of information, but also what the image represents (the whole heap, or just a section, such as the result of compiling a file). I believe two formats are required (a binary executable, and a custom file format that can be loaded in a running instance of Tachyon). Let me remind everyone that having only an "image dump" feature was a cause of problems for Smalltalk (according to Allen Wirfs-Brock, see his DLS keynote). That's why having a .exe (self contained executable) is important.
I just had a discussion with Erick, and he told me that he would rather implement the GC in C, as a first version. Since he's the one writing it, and he seems interested in the idea of having a JS GC eventually, I will respect his preference and stop insisting on this issue.
I'm glad to see that you take Erick's opinion into account. Don't forget that we are a team and that the decisions are to be taken as a group. As a group we took the decision to implement the GC in C not too long ago. That should be a sufficient reason to stick with the plan. In fact I would have been upset if Erick had expressed that he now wants to write the GC in JS, given that he previously expressed his opinion that it was best to do it first in C. It is important that we voice our opinions openly and listen to each other in the hope of taking the best decision. But coming back on a decision, without new experience and data to back up a desire to change the decision, is frustrating for the team and counter productive. I hope we can avoid such situations.
Marc