<close> annotation and disabling GC

[stefanos82]

The following comment is found in string.nelua:

When the GC is disabled, you should call `string.destroy` to free the string memory
of non views strings returned by this library, otherwise the memory will leak.
Note that string literals points to a buffer in the program static storage
and such strings should never be destroyed.

and then we have the following lines of code:

--[[
Destroys a string freeing its memory.

This must never be called on string literals.
This function is only needed to be called when not using the GC.
]]
function string:destroy(): void
  if unlikely(self.size == 0) then return end
  default_allocator:dealloc(self.data)
  self.data = nilptr
  self.size = 0
end

-- Effectively the same as `destroy`, called when a to-be-closed variable goes out of scope.
function string:__close(): void
  self:destroy()
end

Does this mean when our string object goes out of scope and we have our GC disabled, will it trigger string:destroy() for us?

[edubart]

Does this mean when our string object goes out of scope and we have our GC disabled, will it trigger string:destroy() for us?

Only if you use <close> annotation on its declaration, that is, a string will be destroyed automatically only if you declare it with <close> annotation.

For example, the bellow will not leak memory:

## pragmas.nogc = true -- disable the GC
require 'string'

local function f()
  local s: string <close> = string.upper('hello')
  -- <close> will call destroy for us at the end of this scope, collecting string memory for us
end

f()

This will also not leak memory:

## pragmas.nogc = true -- disable the GC
require 'string'

local function f()
  local s: string = string.upper('hello')
  s:destroy() -- collect string memory
end

f()

However, this one will leak:

## pragmas.nogc = true -- disable the GC
require 'string'

local function f()
  local s: string = string.upper('hello')
  -- we forgot to destroy our string! it's memory is not collected, so it leaks
end

f()

[stefanos82]

Obviously this one

## pragmas.nogc = true -- disable the GC
local function f()
  local s: string = string.upper('hello')
  -- we forgot to destroy our string! it will leak
end

f()

will leak, because you have not indeed release its internally allocated memory.

My question is, since f() is of local scope, logically it should release everything from inside its scope, right? in other words, we could take advantage of its local scope cleanup mechanism to control pre-allocated user data and have greater control this way.

But is it possible to do something like that with a function? I know we can do it with a record object, but don't know whether it's applicable in functions or not.

[edubart]

My question is, since f() is of local scope, logically it should release everything from inside its scope, right?

No, this is not obvious, if we assign some external variable with s, then we should not destroy it:

## pragmas.nogc = true -- disable the GC
require 'string'

local external_s: string
local function f()
  local s: string = string.upper('hello')
  external_s = s
  -- we should not destroy `s`, because it is now "owned" by `external_s`, destroying it would make our app crash!
end

f()
print(external_s)

You would have to track all assignments, and all argument passing, to effectively know if s could be destroyed, and to do that you would need to introducing some ownership system, or move semantics, which I said a few times that Nelua will not have this in the core because introduces RAII concepts, which I am against. Also tracking all this it's a very complex task to make in the compiler, and languages like Rust and modern C++ already shine in that area, and Nelua is not reinventing them or following its ideas or design choices. Nelua is not another RAII/ownership language, people wanting RAII should open their eyes on other ways to approach the problem, the Linux kernel for example is a big efficient and stable software, and they live without RAII, they have good techniques both safe and efficient.

Custom allocators instead

I am in favor of the following approach for a temporary string, using custom allocators, here it's a pseudo code if you wonder:

## pragmas.nogc = true -- disable the GC

require 'allocators.heap'
require 'string'

-- `string.upper` variation to support custom allocators.
function string.upper_ex(s: string, allocator: auto): string
  local function toupper(c: cint): cint <inline> return (@cuint)(c)-'a'_b < 26 and c & 0x5f or c end
  if unlikely(s.size == 0) then return s end
  local ret: string = {data = (@*[0]byte)(allocator:xalloc(s.size+1)), size = s.size}
  ret.data[s.size] = 0
  for i:usize=0,<s.size do ret.data[i] = (@byte)(toupper(s.data[i])) end
  return ret
end

-- Temporary allocator for strings, used to allocate temporary strings
local temp_string_allocator: HeapAllocator(16384)

-- Function that creates a temporary string and prints it.
local function f()
  local s: string = string.upper_ex('hello', temp_string_allocator)
  print(s)
  -- no need to deallocate the string, it will be deallocate in a the end of frame
end

local function frame()
  f()
  -- free all temporary memory!
  temp_string_allocator:deallocall()
end

for i=1,10 do
  frame()
end

This approach is more efficient than using RAII, than using GC, than using ownership and than using reference counting. And it is how I believe people should do more for efficient software, specially in game world or realtime software. It is more efficient because you deallocate all temporary objects in a batch with deallocall, it will take just a few instructions, and because your temp_string_allocator comes with memory pre-allocated. And if you can make your whole application allocations pre allocated by a custom fixed allocators, you can effectively never have leaks and while being efficient. Also you can deal with dangling pointers with handles as I've already mentioned in other discussions, this approach has many benefits and ways you can have no leaks or dangling references when done properly, and it does not require reinventing ownership or move semantics.

Such a concept will be explored more in Nelua in the future, ideally all methods that allocate memory in the standard library will be able to work with a custom allocator, and the language will provide more utilities for custom allocators. This is not the focus at the moment, because the focus at the moment is making more Lua-like features, and we have the GC or manual memory management meanwhile.

[stefanos82]

About Linux kernel not using RAII...well...they actually do in a way; via constructor / destructor attributes.

• https://github.com/torvalds/linux/blob/5bfc75d92efd494db37f5c4c173d3639d4772966/tools/lib/lockdep/common.c#L15
• https://github.com/torvalds/linux/blob/5bfc75d92efd494db37f5c4c173d3639d4772966/tools/testing/selftests/rseq/rseq.c#L141
• https://github.com/torvalds/linux/blob/5bfc75d92efd494db37f5c4c173d3639d4772966/tools/testing/selftests/net/reuseport_bpf.c#L442

About the rest, yes; I agree.

As you have seen in #135, I have added GingerBill in it that explains in great detail about the (proper) use of memory.

Last but not least, the Relative Pointers by Jonathan Blow demonstrates this concept you have just shown above and is really amazing!

[edubart]

About Linux kernel not using RAII...well...they actually do in a way; via constructor / destructor attributes.

This is more a way to execute code when loading/unloading a library, or before main, not really RAII. This can be used with Nelua also via the <cattribute> annotation on functions, but just GCC/Clang supports this I think. Also it's not like Nelua does not have any RAII, Nelua have some crude RAII concept with defer and <close>, but it's limited to that, things beyond that for my opinion cross the line where RAII is a good feature to have or rely on, due to all of consequences that comes with it.

[stefanos82]

I don't have that extensive experience with RAII so I can take position to defend or reject it.

[stefanos82]

I was playing with a code and accidentally caused a bug in my code which became food for thought which I would like to share.

I introduced general_allocator:delete(o) prematurely to an object that <close> annotation should have dealt with for me and caused memory leak.

Here's the sample:

require 'allocators.general'
require 'io'

local Object: type = @record{ x: integer, y: integer }

function Object:__close()
  io.printf("object %p destroyed\n", self)
  general_allocator:delete(self)
end

do
  local o: *Object <close> = general_allocator:new(@Object)
  -- The culprit line
  general_allocator:delete(o)
  -- ^^^^^^^^^^^^^^^^^^^^^^^

  io.printf("object %p created\n", o)
  io.printf("o.x initial value: %3d, address: %p\n", o.x, &o.x)
  io.printf("o.y initial value: %3d, address: %p\n", o.y, &o.y)

  o.x = 10
  o.y = 20

  io.printf("    o.x new value: %3d, address: %p\n", o.x, &o.x)
  io.printf("    o.y new value: %3d, address: %p\n", o.y, &o.y)
end

Is there a way, like lock() / unlock() we have with threading models?

It could be safer to prevent such action when we are dealing with manual memory management, especially with <close> annotations.

Do you have anything to suggest so I can improve my manual memory management use?

[edubart]

It could be safer to prevent such action when we are dealing with manual memory management, especially with annotations.

When you are doing manual memory management you are responsible for it, including avoiding such mistakes. There is no way, and will not have a way to forbid you from making manual memory management mistakes. But you can use tools to assist finding such mistakes and to confirm that you program is working good, such as using the --sanitize flag. The sanitizer would catch such mistake as a double free. Also you could design your application in a way to avoid such mistakes, but that is on the application level, those ways we have already discussed before such as using pre allocated memory that is never freed, custom temporary allocators or generational handles.

The only way to keep you fully safe from manual memory management is to not do it in the first place, by leaving the GC enabled, and letting it collect the memory for you. With the GC enabled you don't need to call delete or use <close> annotation that deletes it, because the GC will delete automatically for you once the object has no more references.

[stefanos82]

When you are doing manual memory management you are responsible for it, including avoiding such mistakes. There is no way, and will not have a way to forbid you from making manual memory management mistakes. But you can use tools to assist finding such mistakes and to confirm that you program is working good, such as using the --sanitize flag. The sanitizer would catch such mistake as a double free.

That's how I detected it to be honest with you, with -S flag.

Also you could design your application in a way to avoid such mistakes, but that is on the application level, those ways we have already discussed before such as using pre allocated memory that is never freed, custom temporary allocators or generational handles.

The only way to keep you fully safe from manual memory management is to not do it in the first place, by leaving the GC enabled, and letting it collect the memory for you. With the GC enabled you don't need to call delete or use <close> annotation that deletes it, because the GC will delete automatically for you once the object has no more references.

I understand what you are saying and I agree.

I wish there was a way to add a protective layer within __close for such special cases; this way, we could prevent a memory release attempt by throwing a message during compilation / execution procedure.

I modified the previous code to give you an idea of what I actually mean:

require 'allocators.general'
require 'io'

local Object: type = @record{ x: integer, y: integer }

function Object:__memorysafety()
  general_allocator:delete(self)
end

function Object:__close()
  io.printf("object %p destroyed\n", self)
  self.__memorysafety()
end

do
  local o: *Object <close, memorysafety> = general_allocator:new(@Object)
  -- Error: Object 0xdeadc0de cannot be released twice;
  -- <memorysafety> is responsible for memory release handling. 
  general_allocator:delete(o)

  io.printf("object %p created\n", o)
  io.printf("o.x initial value: %3d, address: %p\n", o.x, &o.x)
  io.printf("o.y initial value: %3d, address: %p\n", o.y, &o.y)

  o.x = 10
  o.y = 20

  io.printf("    o.x new value: %3d, address: %p\n", o.x, &o.x)
  io.printf("    o.y new value: %3d, address: %p\n", o.y, &o.y)
end

The logic of course is wrong, so consider my example as pseudo-code.

[stefanos82]

@edubart after all this time, I have just noticed the following in the generated code of the aforementioned code: #define NELUA_NIL (nlniltype){} and typedef struct nlniltype {} nlniltype;.

As far as I can tell, a compound literal cannot be empty, unless you use C23 that have just introduced the support for empty list initialization, else if I'm not mistaken, it's an undefined behavior.

Also, an empty struct is an undefined behavior (C17, 6.7.2.1, point 8).

Was this the original intent with the generated code?

[edubart]

Nelua code generator does not target C standards, it targets GCC and Clang, both do support empty structures, as discussed in #73 (comment)

This could be improved though, but using empty structs at this moment simplifies a lot the code generation, and it does not impact performance.

[stefanos82]

Out of curiosity, how do you use an empty struct in C? I don't remember seeing an example in actual use.