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 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?
- Maxime
Afficher les réponses par date
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
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 have the slides but I'm not sure what you mean. I think the problem with Smalltalk is that programmers would have liked to distribute standalone, precompiled apps and couldn't really. This wouldn't be an issue for us.
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).
I believe there are two simple approaches:
1. Dump only executable code. Have the compiler initialize itself at startup. This would yield a smaller image file, but may be limiting in terms of dynamic recompilation. It may however be quicker to implement, and be advantageous in terms of cross-platform bootstrapping.
2. Dump all allocated memory. This has the advantage that the compiler can preserve lots of information about its own state for dynamic recompilation (e.g.: it's own IR), and be already initialized at startup. Not necessarily incompatible with approach #1.
Either way, I would implement it using an image file with a C image loader. Writing an actual ELF binary seems more complicated and less portable. Implementing a C image loader would be quick and simple.
- Maxime
On 2011-03-30, at 21:38 , chevalma@iro.umontreal.ca wrote:
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 have the slides but I'm not sure what you mean. I think the problem with Smalltalk is that programmers would have liked to distribute standalone, precompiled apps and couldn't really. This wouldn't be an issue for us.
Since we're advocating in favour of javascript outside the web, I wouldn't be so quick to dismiss this possibility.
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).
I believe there are two simple approaches:
- Dump only executable code. Have the compiler initialize itself at
startup. This would yield a smaller image file, but may be limiting in terms of dynamic recompilation. It may however be quicker to implement, and be advantageous in terms of cross-platform bootstrapping.
- Dump all allocated memory. This has the advantage that the compiler can
preserve lots of information about its own state for dynamic recompilation (e.g.: it's own IR), and be already initialized at startup. Not necessarily incompatible with approach #1.
Either way, I would implement it using an image file with a C image loader. Writing an actual ELF binary seems more complicated and less portable. Implementing a C image loader would be quick and simple.
IIRC, last time we talked about this Marc was arguing that reusing the standard OS tools for loading and linking is a good idea, partly because they don't have to be reimplemented and partly because they are optimized for speed. That being said, I'm in favour of supporting multiple formats in the backend (at least, leaving that option open for later).
Bruno
I did a little profiling to see how much code we allocate when compiling the whole of Tachyon. Seems it's just below 5MB so far. Not too bad. Not to mention, some simple compression schemes would probably work well, if we care.
- Maxime
On 2011-03-30, at 21:38 , chevalma@iro.umontreal.ca wrote:
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 have the slides but I'm not sure what you mean. I think the problem with Smalltalk is that programmers would have liked to distribute standalone, precompiled apps and couldn't really. This wouldn't be an issue for us.
Since we're advocating in favour of javascript outside the web, I wouldn't be so quick to dismiss this possibility.
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).
I believe there are two simple approaches:
- Dump only executable code. Have the compiler initialize itself at
startup. This would yield a smaller image file, but may be limiting in terms of dynamic recompilation. It may however be quicker to implement, and be advantageous in terms of cross-platform bootstrapping.
- Dump all allocated memory. This has the advantage that the compiler
can preserve lots of information about its own state for dynamic recompilation (e.g.: it's own IR), and be already initialized at startup. Not necessarily incompatible with approach #1.
Either way, I would implement it using an image file with a C image loader. Writing an actual ELF binary seems more complicated and less portable. Implementing a C image loader would be quick and simple.
IIRC, last time we talked about this Marc was arguing that reusing the standard OS tools for loading and linking is a good idea, partly because they don't have to be reimplemented and partly because they are optimized for speed. That being said, I'm in favour of supporting multiple formats in the backend (at least, leaving that option open for later).
Bruno _______________________________________________ Tachyon-list mailing list Tachyon-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list
-
Bruno Dufour -
chevalma＠iro.umontreal.ca -
Marc Feeley