Invalidate / GC-marking after close of large data blocks

[bil til]

In my C software it happens from time to time, that e. g. some larger
block of userdata expired / is closed.

It would be nice, if this then is recognized by the gc as fast as possible.

Currently, I then invoke:
lua_gc( L, LUA_GCCOLLECT);
This works I think, just for runtime predictions this might be a BIT
dangerous - as such a GCCOLLECT run will have to check the complete
global table, it might need quite a time in larger applications, I
think.

Generally, I think it might be more efficient, and nice concerning
runtime predictions for many applications, if there would be a
possiblity, that GC would just "eat the last element on stack and mark
it free", so e. g. invoke like:
lua_gc(L, LUA_GCCOLLECT_TOPOFSTACK);

... or similar command... .

What do you think about this?

[Thomas Jericke]

I think you should use a pointer to your data in your userdata in this case. 
Then you can free the large block of data (and null the pointer) when the userdata is closed instead of freeing it when it is collected.

--

Thomas

[bil til]

> I think you should use a pointer to your data in your userdata in this case.
> Then you can free the large block of data (and null the pointer) when the userdata is closed instead of freeing it when it is collected.

Hi Thomas,
thanks for answer, but this is not possible.

This is for a very constrained RAM application in a 1-Chip
Microcontroller system. Usually in such a system I would not use
dynamic RAM - all memory would be static. For Lua dynamic RAM of
course is necessary - but in this application then ALL dynamic RAM is
operated by Lua - alloc / free is only done by Lua... .

[Thomas Jericke]

And what is preventing you from using the same alloc / free that Lua is using?

--

Thomas

[bil til]

> And what is preventing you from using the same alloc / free that Lua is using?

It is my general caution against using dynamic memory in single chip
microcontroller firmware... this is for control of large machines ...
it is just a security concern.

(I also program sofware for Windows PCs, there of course usage of
alloc/free is used abudandtly).

For Lua I just reserve a very big heap - as large as possible for the
uController I use.

If only Lua uses this, it is still quite well under control - e. g.
easy to check for free memory etc. . If I would use free/ alloc also
for other things, this would get much more tricky... .