[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: A review of changes between 5.1 and 5.2-work3
- From: Roberto Ierusalimschy <roberto@...>
- Date: Fri, 21 May 2010 15:45:55 -0300
> To help understand all of the changes between Lua 5.1(.4) and Lua
> 5.2-work3, I took I diff of the source folders of the two, then
> distilled the resulting 16000 line diff line into an easier to read
> blog post. You may be interested in reading the result (and feedback
> is also welcomed):
>
> http://www.corsix.org/content/look-lua-52-work3
Very good work indeed! Many thanks.
Some small corrections/suggestions/notes:
* LUA_ERRGCMM is not related to emergency collections. (Actually
it cannot be called in an emergency collection, because emergency
collections do not run finalizers.) It is just an indication that
the error occured in a finalizer, not in the "regular" code that was
running. (Finalizers should never throw errors, so this status code may
mean that something bad is happening.)
* As I answered in the list, generational mode is very experimental;
that includes the part of it being not incremental. I have a special
interest about how it behaves in games, which could benefit most from
it. (It may be particularly good for hardware with slow memory, as
it avoids visiting all objects each cycle.) A simple note like "it is
not well suited for applications (like games)" may spoil the experiment.
* "In part due to the number of bugs I've found in Lua 5.1" -->
"Due to the number of bugs I've found in Lua 5.1" ;)
* "There is also a new internal function called luaD_shrinkstack, which
implies that stacks can now shrink as well as grow.": The stack could
also shrink in Lua 5.1 by calling luaD_reallocstack with a smaller size;
see 'checkstacksizes' in 'lgc.c'.
* "OP_SETLIST no longer throwing an error when not given a table" is
related to opcode verification. (We could not check that statically,
so it was checked dynamically. With the static check removed, we
removed the dynamic checks too.)
* "The generic for-loop opcode split into two separate opcodes": the
split was to simplify yielding inside the iteraction function. A resume
naturally continues in the second instruction.
-- Roberto