On Tue, Nov 3, 2009 at 11:12 PM, Erik Huelsmann ehuels@gmail.com wrote:
This evening, I've updated the list of tickets at http://trac.common-lisp.net/armedbear/report/1. Assigning the tickets in the list to specific releases makes the roadmap view (http://trac.common-lisp.net/armedbear/roadmap) nicely indicate our progress.
If you have an issue, but it's not mentioned in the list of tickets, 2 things can be the case:
- We don't know about your ticket, or have forgotten about it
- The ticket is more of a general thing we need to keep doing
(there's no specific goal or target to be achieved)
In the second case, we can't file a ticket, because I would like to be able to close tickets some day. As you'll find, I've assigned some tickets to the milestone "too-vague". If we can't come up with more specific descriptions, I think we'll have to reclassify these to "reminder" type tickets. (We don't have those, yet, btw.)
So, I'd like to hear your comments on missing tickets.
I don't know if it can be a ticket, and it's a long-term goal, but: we have had many discussions about save-image and serialization; now that we are addressing startup times too, it occurred to me that this stuff is somehow all connected together. Serialization is useful to restore the state of variables; however most of the startup time is not spent assigning variables, but loading and instantiating compiled functions through reflection, and serialization would probably not help much in this case. What could help is, as per Ville's idea, create a big "loader" class which references compiled function classes directly by name in its bytecode (and thus does not use reflection), and use that to restore compiled functions in block when you load the saved image. This should hopefully speed up startup times quite dramatically. However, it's not an easy goal since it depends on some other things:
- compiled functions should not call loadCompiledFunction but delegate loading of other classes to their classloader, so that when loaded immediately abcl will provide a temporary classloader, when loaded by the big loader class they will all use the same classloader completely avoiding reflection. - remember/recall should be redesigned since now it allows to load a given function only once. - serialization alone is not easy to implement and get right, and requires us to make choices: should serialization only be used for save-image, or given that we implement it do it so that it is more fine-grained (to allow serialization of single Lisp objects, e.g. for remoting or short-term persistence)? The first case is easier, the second one is way cooler ;) - and probably other things I'm not considering.
Alessio