<feed xmlns='http://www.w3.org/2005/Atom'>
<title>lua/lgc.h, branch v5.4.9</title>
<subtitle>A mirror of https://github.com/lua/lua
</subtitle>
<id>https://git.lua4.win/lua/atom?h=v5.4.9</id>
<link rel='self' href='https://git.lua4.win/lua/atom?h=v5.4.9'/>
<link rel='alternate' type='text/html' href='https://git.lua4.win/lua/'/>
<updated>2022-12-15T17:18:03+00:00</updated>
<entry>
<title>Small change in barrier macros</title>
<updated>2022-12-15T17:18:03+00:00</updated>
<author>
<name>Roberto Ierusalimschy</name>
<email>roberto@inf.puc-rio.br</email>
</author>
<published>2022-12-15T17:18:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/lua/commit/?id=f874d37fa28037bf3d3300ef8c0740d13792404b'/>
<id>urn:sha1:f874d37fa28037bf3d3300ef8c0740d13792404b</id>
<content type='text'>
Reuse macros for objects when defining the macros for values.
</content>
</entry>
<entry>
<title>Threads are created like other objects</title>
<updated>2022-11-01T20:14:01+00:00</updated>
<author>
<name>Roberto Ierusalimschy</name>
<email>roberto@inf.puc-rio.br</email>
</author>
<published>2022-11-01T20:14:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/lua/commit/?id=9ede317c70ad82279f2e3962eb52904a17bf4b55'/>
<id>urn:sha1:9ede317c70ad82279f2e3962eb52904a17bf4b55</id>
<content type='text'>
Using a version of 'luaC_newobj' that allows offsets (extra space
before the object itself).
</content>
</entry>
<entry>
<title>Bug: finalizer calling exit can corrupt finalization order</title>
<updated>2021-12-22T12:00:52+00:00</updated>
<author>
<name>Roberto Ierusalimschy</name>
<email>roberto@inf.puc-rio.br</email>
</author>
<published>2021-12-22T12:00:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/lua/commit/?id=597a53bbc681089d85b082b46c2e2428dec43b86'/>
<id>urn:sha1:597a53bbc681089d85b082b46c2e2428dec43b86</id>
<content type='text'>
'os.exit' can call lua_close again, separating new finalizers
created after all previous finalizers were already separated.
</content>
</entry>
<entry>
<title>Bug: GC is not reentrant</title>
<updated>2021-12-13T13:41:17+00:00</updated>
<author>
<name>Roberto Ierusalimschy</name>
<email>roberto@inf.puc-rio.br</email>
</author>
<published>2021-12-13T13:41:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/lua/commit/?id=0bfc572e51d9035a615ef6e9523f736c9ffa8e57'/>
<id>urn:sha1:0bfc572e51d9035a615ef6e9523f736c9ffa8e57</id>
<content type='text'>
As the GC is not reentrant, finalizers should not be able to invoke it.
</content>
</entry>
<entry>
<title>Small changes in macros that change GC colors</title>
<updated>2020-08-13T18:23:21+00:00</updated>
<author>
<name>Roberto Ierusalimschy</name>
<email>roberto@inf.puc-rio.br</email>
</author>
<published>2020-08-13T18:23:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/lua/commit/?id=f849885a4b49f2d766e6befc67475c05240023eb'/>
<id>urn:sha1:f849885a4b49f2d766e6befc67475c05240023eb</id>
<content type='text'>
- Macro 'gray2black' was renamed 'nw2black' (Non-White to black), as it
was already being used on objects that could be already black.

- Macros 'white2gray' and 'black2gray' were unified in 'set2gray'; no
reason to have two macros when one will do and, again, 'black2gray' was
already being used on objects that could be already gray.

Moreover, macros 'maskcolors' and 'maskgcbits' were negated to have
ones in the described bits, instead of zeros. (This naming seems more
intuitive.)
</content>
</entry>
<entry>
<title>Better tests for gray lists</title>
<updated>2020-08-07T17:45:20+00:00</updated>
<author>
<name>Roberto Ierusalimschy</name>
<email>roberto@inf.puc-rio.br</email>
</author>
<published>2020-08-07T17:45:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/lua/commit/?id=f13dc59416afa8fc93bb3d784d1a73e49e1b5b09'/>
<id>urn:sha1:f13dc59416afa8fc93bb3d784d1a73e49e1b5b09</id>
<content type='text'>
Test uses an extra bit in 'marked' to mark all elements in gray lists
and then check against elements colored gray.
</content>
</entry>
<entry>
<title>Free bit 7 of GC 'marked' field</title>
<updated>2020-08-07T14:21:44+00:00</updated>
<author>
<name>Roberto Ierusalimschy</name>
<email>roberto@inf.puc-rio.br</email>
</author>
<published>2020-08-07T14:21:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/lua/commit/?id=7c3cb71fa48fbe84d9d9c664eb646446fb80898b'/>
<id>urn:sha1:7c3cb71fa48fbe84d9d9c664eb646446fb80898b</id>
<content type='text'>
Tables were using this bit to indicate their array sizes were real
('isrealasize'), but this bit can be useful for tests. Instead, they
can use bit 7 of their 'flag' field for that purpose. (There are only
six fast-access metamethods.) This 'flag' field only exists in tables,
so this use does not affect other types.
</content>
</entry>
<entry>
<title>Avoid the creation of too many strings in 'package'</title>
<updated>2019-05-03T13:14:25+00:00</updated>
<author>
<name>Roberto Ierusalimschy</name>
<email>roberto@inf.puc-rio.br</email>
</author>
<published>2019-05-03T13:14:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/lua/commit/?id=b14609032cf328dea48b0803f3e585e223283b3d'/>
<id>urn:sha1:b14609032cf328dea48b0803f3e585e223283b3d</id>
<content type='text'>
Both when setting a path and searching for a file ('searchpath'),
this commit reduces the number of intermediate strings created
in Lua.
(For setting a path the change is not relevant, because this is
done only twice when loading the module. Anyway, it is a nice example
of how to use auxlib buffers to manipulate strings in the C API.)
</content>
</entry>
<entry>
<title>After a "bad collections", avoid switching back back to generational</title>
<updated>2019-01-30T13:44:42+00:00</updated>
<author>
<name>Roberto Ierusalimschy</name>
<email>roberto@inf.puc-rio.br</email>
</author>
<published>2019-01-30T13:44:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/lua/commit/?id=2c32bff60987d38a60a58d4f0123f3783da60a63'/>
<id>urn:sha1:2c32bff60987d38a60a58d4f0123f3783da60a63</id>
<content type='text'>
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).
</content>
</entry>
<entry>
<title>Removed internal cache for closures</title>
<updated>2018-11-01T16:21:00+00:00</updated>
<author>
<name>Roberto Ierusalimschy</name>
<email>roberto@inf.puc-rio.br</email>
</author>
<published>2018-11-01T16:21:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/lua/commit/?id=e8c779736f3029df353038352c14c8ab63728811'/>
<id>urn:sha1:e8c779736f3029df353038352c14c8ab63728811</id>
<content type='text'>
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.)
</content>
</entry>
</feed>
