aboutsummaryrefslogtreecommitdiff
path: root/lstate.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Bug when growing a stackRoberto Ierusalimschy2020-11-081-1/+1
| | | | | | When a stack grows, its extra area can be in use, and it becomes part of the common area. So, the extra area must be kept correct all the times. (Bug introduced by commit 5aa36e894f5.)
* Hash always use all characters in a long stringRoberto Ierusalimschy2020-10-121-1/+1
| | | | | | | Hashes for long strings are computed only when they are used as keys in a table, not a too common case. And, in that case, it is to easy to force collisions changing only the characters which are not part of the hash.
* No more field 'lua_State.stacksize'Roberto Ierusalimschy2020-10-121-5/+3
| | | | | | The stack size is derived from 'stack_last', when needed. Moreover, the handling of stack sizes is more consistent, always excluding the extra space except when allocating/deallocating the array.
* Correct handling of 'luaV_execute' invocationsRoberto Ierusalimschy2020-10-121-1/+1
| | | | | | | | | The previous stackless implementations marked all 'luaV_execute' invocations as fresh. However, re-entering 'luaV_execute' when resuming a coroutine should not be a fresh invocation. (It works because 'unroll' called 'luaV_execute' for each call entry, but it was slower than letting 'luaV_execute' finish all non-fresh invocations.)
* Revision of stackless implementationRoberto Ierusalimschy2020-10-121-20/+25
| | | | | | - more organized handling of 'nCcalls' - comments - deprecation of 'setcstacklimit'
* Back to a stackless implementationRoberto Ierusalimschy2020-10-121-41/+2
| | | | | | | | | | | | | A "with stack" implementation gains too little in performance to be worth all the noise from C-stack overflows. This commit is almost a sketch, to test performance. There are several pending stuff: - review control of C-stack overflow and error messages; - what to do with setcstacklimit; - review comments; - review unroll of Lua calls.
* Optimization in 'markold'Roberto Ierusalimschy2020-07-291-1/+1
| | | | | | | | | | OLD1 objects can be potentially anywhere in the 'allgc' list (up to 'reallyold'), but frequently they are all after 'old1' (natural evolution of survivals) or do not exist at all (when all objects die young). So, instead of 'markold' starts looking for them always from the start of 'allgc', the collector keeps an extra pointer, 'firstold1', that points to the first OLD1 object in the 'allgc' list, or is NULL if there are no OLD1 objects in that list.
* DetailsRoberto Ierusalimschy2020-07-291-2/+2
| | | | | The fields 'old' and 'finobjold' were renamed 'old1' and 'finobjold1', respectively, to make clearer the main ages of their elements.
* Fixed bug: invalid 'oldpc' when returning to a functionRoberto Ierusalimschy2020-07-171-0/+1
| | | | | | | | | | The field 'L->oldpc' is not always updated when control returns to a function; an invalid value can seg. fault when computing 'changedline'. (One example is an error in a finalizer; control can return to 'luaV_execute' without executing 'luaD_poscall'.) Instead of trying to fix all possible corner cases, it seems safer to be resilient to invalid values for 'oldpc'. Valid but wrong values at most cause an extra call to a line hook.
* Avoid any code before locks in the APIRoberto Ierusalimschy2020-07-061-2/+3
| | | | | For consistency in the C API, avoid any initializations before callling lua_lock.
* Make sure that main thread is non yieldableRoberto Ierusalimschy2020-07-061-0/+1
| | | | | Main thread must be non yieldable even at "level 0" (bare API), outside the 'pcall' from 'lua.c'.
* Detail in 'lua_resetthread'Roberto Ierusalimschy2020-06-171-5/+4
| | | | | | 'lua_resetthread' should reset the CallInfo list before calling 'luaF_close'. luaF_close can call functions, and those functions should not run with dead functions still in the CallInfo list.
* 'luaE_shrinkCI' shouldn't remove first free CallInfoRoberto Ierusalimschy2020-06-151-8/+14
| | | | | Due to emergency collections, 'luaE_shrinkCI' can be called while Lua is building a new CallInfo, which for a while is still a free CallInfo.
* Improvements in the handling of signalsRoberto Ierusalimschy2020-05-221-4/+5
| | | | Added 'volatile' to 'l_signalT' variables plus some minor changes.
* Short strings always use all bytes in the hashRoberto Ierusalimschy2020-04-011-1/+1
| | | | | | Collisions in short strings occurr just by their existence, when internalizing them. (Collisions in long strings is caused/controlled by the program, when adding them as keys to the same table.)
* Clearer distinction between types and tagsRoberto Ierusalimschy2020-01-311-2/+2
| | | | | LUA_T* represents only types; tags (types + Variants) are represented by LUA_V* constants.
* Larger C-stack limits for new threadsRoberto Ierusalimschy2019-10-171-1/+1
| | | | | | New threads were being created with very small C-stack limits. This is not a problem for coroutines, because 'lua_resume' sets a new limit, but not all threads are coroutines.
* 'setCstacklimit' renamed to 'setcstacklimit'Roberto Ierusalimschy2019-09-241-1/+1
| | | | Function names in the API use only lowercase letters.
* Supressed errors in '__close' generate warningsRoberto Ierusalimschy2019-08-161-0/+16
|
* Small changes around C-stack limitRoberto Ierusalimschy2019-06-261-1/+1
| | | | | | | | | - Better documentation in 'testes/cstack.lua' about using 'debug.setCstacklimit' to find a good limit. - Constant LUAI_MAXCSTACK gets added CSTACKERR (extra stack for error handling), so that it is compatible with the argument to 'debug.setCstacklimit'.
* New function 'setCstacklimit'Roberto Ierusalimschy2019-06-181-2/+26
| | | | | Added new functions to dynamically set the C-stack limit ('lua_setCstacklimit' in the C-API, 'debug.setCstacklimit' in Lua).
* Revamp around 'L->nCcalls' countRoberto Ierusalimschy2019-06-121-27/+26
| | | | | The field 'L->nCcalls' now counts downwards, so that the C-stack limits do not depend on the stack size.
* Fixed bug with to-be-closed variables in base C levelRoberto Ierusalimschy2019-04-261-0/+2
| | | | | | | | To-be-closed variables in C use 'ci.nresults' to code that there is a variable to be closed in that function. The intialization of the base C level (the one "running" when calling API functions outside any Lua call) did not initialize 'ci.nresults', creating (correct) warnings in valgrind.
* LUAI_MAXCCALLS renamed LUAI_MAXCSTACKRoberto Ierusalimschy2019-03-251-8/+8
| | | | | | | The limit LUAI_MAXCCALLS was renamed LUAI_MAXCSTACK, which better represents its meaning. Moreover, its definition was moved to 'luaconf.h', given its importance now that Lua does not use a "stackless" implementation.
* Changes in the warning systemRoberto Ierusalimschy2019-03-141-2/+2
| | | | | | | | - The warning functions get an extra parameter that tells whether message is to be continued (instead of using end-of-lines as a signal). - The user data for the warning function is a regular value, instead of a writable slot inside the Lua state.
* After a "bad collections", avoid switching back back to generationalRoberto Ierusalimschy2019-01-301-1/+3
| | | | | | | After a major bad collection (one that collects too few objects), next collection will be major again. In that case, avoid switching back to generational mode (as it will have to switch again to incremental to do next major collection).
* No more LUA_ERRGCMM errorsRoberto Ierusalimschy2019-01-011-0/+7
| | | | | Errors in finalizers (__gc metamethods) are never propagated. Instead, they generate a warning.
* Added a warning system to LuaRoberto Ierusalimschy2018-12-281-0/+2
| | | | | The warning system is just a way for Lua to emit warnings, messages to the programmer that do not interfere with the running program.
* Changes in the control of C-stack overflowRoberto Ierusalimschy2018-12-271-16/+33
| | | | | | | | | | * unification of the 'nny' and 'nCcalls' counters; * external C functions ('lua_CFunction') count more "slots" in the C stack (to allow for their possible use of buffers) * added a new test script specific for C-stack overflows. (Most of those tests were already present, but concentrating them in a single script easies the task of checking whether 'LUAI_MAXCCALLS' is adequate in a system.)
* New functions 'lua_resetthread' and 'coroutine.kill'Roberto Ierusalimschy2018-12-131-2/+25
| | | | | | New functions to reset/kill a thread/coroutine, mainly (only?) to close any pending to-be-closed variable. ('lua_resetthread' also allows a thread to be reused...)
* Removed internal cache for closuresRoberto Ierusalimschy2018-11-011-1/+1
| | | | | | | | | | | | | | | | | | | The mechanism of "caching the last closure created for a prototype to try to reuse it the next time a closure for that prototype is created" was removed. There are several reasons: - It is hard to find a natural example where this cache has a measurable impact on performance. - Programmers already perceive closure creation as something slow, so they tend to avoid it inside hot paths. (Any case where the cache could reuse a closure can be rewritten predefining the closure in some variable and using that variable.) - The implementation was somewhat complex, due to a bad interaction with the generational collector. (Typically, new closures are new, while prototypes are old. So, the cache breaks the invariant that old objects should not point to new ones.)
* First "complete" implementation of to-be-closed variablesRoberto Ierusalimschy2018-10-171-2/+2
| | | | | | | Still missing: - handling of memory errors when creating upvalue (must run closing method all the same) - interaction with coroutines
* Removed extra information from RCS keyword stringsRoberto Ierusalimschy2018-08-231-1/+1
| | | | | Version numbers and dates (mostly wrong) from RCS keyword strings removed from all source files; only the file name are kept.
* no need to check whether libraries and host use the same kernel;Roberto Ierusalimschy2018-06-181-6/+5
| | | | Lua should work correctly with several copies of the kernel
* new field 'nilvalue' in struct 'global_State' to avoid the use ofRoberto Ierusalimschy2018-06-151-1/+2
| | | | addresses of static variables
* no more 'luaO_nilobject' to avoid comparison of global variable addressesRoberto Ierusalimschy2018-06-011-3/+2
| | | | (now uses static variables)
* macro 'luai_makeseed' now controls the whole process of making the seedRoberto Ierusalimschy2018-05-291-17/+17
|
* 'gcemergency' should be zero before any memory allocationRoberto Ierusalimschy2018-02-051-2/+2
|
* janitor work on castsRoberto Ierusalimschy2018-01-281-3/+3
|
* new macro 'isLuacode' (to distinguish regular Lua code fromRoberto Ierusalimschy2017-12-191-2/+2
| | | | hooks, where C code can run inside a Lua function).
* no more 'stackless' implementation; 'luaV_execute' calls itselfRoberto Ierusalimschy2017-11-231-2/+26
| | | | | recursively to execute function calls. 'unroll' continues all executions suspended by an yield (through a long jump)
* using 'trap' to stop 'luaV_execute' when necessary (tracing andRoberto Ierusalimschy2017-11-131-1/+2
| | | | to update its copy of 'base' when the stack is reallocated)
* back to 'CallInfo' (no gains with its removal)Roberto Ierusalimschy2017-11-071-8/+55
|
* no more 'CallInfo' structureRoberto Ierusalimschy2017-11-041-53/+4
|
* more fields moved out of 'CallInfo'Roberto Ierusalimschy2017-11-031-3/+3
|
* baby steps to remove 'CallInfo': keeping 'L->func' correctRoberto Ierusalimschy2017-10-311-3/+6
|
* some cleaning in GC parametersRoberto Ierusalimschy2017-10-111-3/+5
|
* new type 'StackValue' for stack elementsRoberto Ierusalimschy2017-06-291-5/+5
| | | | (we may want to put extra info there in the future)
* revamping the incremental collectorRoberto Ierusalimschy2017-05-261-10/+2
| | | | | | Some simplifications (not counting bytes, couting only slots visited; no more 'gcfinnum'); more GC parameters; using vararg in 'lua_gc' to set parameters in different GC modes
* barrier for prototype's cache (with new gray list 'protogray' to keepRoberto Ierusalimschy2017-05-041-2/+2
| | | | prototypes to have their caches visited again) + constant 'MAXMISS'
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-16 00:50:43 +0000