[armedbear-devel] 0.18 and beyond

[Erik Huelsmann]

Hi Alessio,

On Wed, Nov 4, 2009 at 5:47 PM, Alessio Stalla <alessiostalla at gmail.com> wrote:
> On Tue, Nov 3, 2009 at 11:12 PM, Erik Huelsmann <ehuels at 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:
>>
>> 1) We don't know about your ticket, or have forgotten about it
>> 2) 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.

save-image by itself is a well defined functionality, I think. If
there are any intermediate milestones which can be equally well
defined, I'd like to file them too; however, "serialization" in
general isn't good enough to file as a ticket. "serialization of ABCL
LispNumber class descendants" would be more to the point, if that's
what you would be trying to achieve. I think you get the picture.

> 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:

Bye,

Erik.