Stack used in eLua

[Sergio]

Hi guys!
I'm new in the eLua world and, with other enthusiast, we are working to port eLua to a new microcontroller.
We do some basic task to port and the system is booting up! Basic hardware access work fine and can control the access to pins (some led on/off stuff).
Our objetive is learn about eLua and know some internal implementations to known if our work are well done.
We are trying to make a simple test about the used memory (is more academic than practical!), we want to know how much memory is free in the stack. To do this, we define a constant in the linker script to mark the top of the stack and make a function in a c module to calculate the diference between the top of stack and the actual value of the stack pointer. Something like this:

static int stackUsed( lua_State* L )
{
  unsigned int sp, used;
  __asm("MOV %0, R13":"=r"(sp));
  used = ((unsigned int)&_vStackTop - (sp));
  lua_pushinteger( L, used);  
  return 1;
}

Here, the registry R13 store the actual value of the stack pointer in a Cortex M4 microcontroller (lpc4337).  We test too this other version:

static int stackUsed( lua_State* L )
{
  unsigned int sp, used;
  asm volatile ("MRS %0, msp\n" : "=r" (sp) );
  used = ((unsigned int)&_vStackTop - (sp));
  lua_pushinteger( L, used);  
  return 1;
}

But always print the same value of used memory. We call the function stackUsed inside a function waiting for a change,  but not.  There are not changes in the amount of used memory. This is because the eLua use the heap to map the functions arguments or we are doing some wrong?

Thanks a lot for your help!
Sergio

[BogdanM]

Hi Sergio,

A simplified view is that Lua uses the C stack when it interacts with C functions. If you're running "pure" Lua code, then everything will happen in the heap, like you said.

Best,
Bogdan

[Sergio]

Hi Bogdan!
Thanks for your answer! This confirmation explain the viewed behavior. So, define a big part of SRAM for the stack space may be useless, because only will be used for the arguments of the functions called between eLUA/C  and C/C. Is right?

Something like the original idea, but over the heap, can be made? We are using a microcontroller with differents regions of RAM and we setup the system to use "multiple" allocator. Also we readed the implementation of this allocator, is possible that the "multiple" allocator assign memory in the defined regions but never free them?
If this is right, the garbage collector manage the alocation and elimination of the differents objects over the defined RAM regions?

Thanks a lot! We are reading the eLua source code but we don't  understand some parts and mechanicsms.

Sergio

[BogdanM]

Hi,

Sorry for the delayed response.

> So, define a big part of SRAM for the stack space may be useless, because only will be used for the arguments of the functions called between eLUA/C  and C/C. Is right?

Not exactly, but yes, defininig a big stack is pretty in eLua is pretty useless. I found 16K to be enough for all practical cases.

> Also we readed the implementation of this allocator, is possible that the "multiple" allocator assign memory in the defined regions but never free them?

I'm not sure I understand your question. The allocator itself allocates and frees what it's told to. In other words, if it's told to free a memory region, it will free it, no matter if you're using the multiple allocator or any other allocator. If you have memory leaks in your program, they are very likely not a result of your allocator choice.

> If this is right, the garbage collector manage the alocation and elimination of the differents objects over the defined RAM regions?

On the Lua side of things, yes. For C code, you still need to do your allocation and deallocation manually, as usual.

Best,
Bogdan

[Sergio]

Hi Bogdan!
Very thanks for your answer!
When I say the allocator not freed memory (I think) is for the implementation of the function elua_sbrk. I viewed in the source code, when use multiple allocator, a call to malloc function from c language, make a call to dlmalloc function then, the call stack  (mixing functions and macros) is: sys_alloc -> CALL_MORECORE -> MORECORE -> elua_sbrk. In the elua_sbrk implementation I found this code:


// _sbrk_r (newlib) / elua_sbrk (multiple)
static char *heap_ptr;
static int mem_index;

#ifdef USE_MULTIPLE_ALLOCATOR
void* elua_sbrk( ptrdiff_t incr )
#else
void* _sbrk_r( struct _reent* r, ptrdiff_t incr )
#endif
{
  void* ptr;
     
  // If increment is negative, return -1
  if( incr < 0 )
    return ( void* )-1;
   
  // Otherwise ask the platform about our memory space (if needed)
  // We do this for all our memory spaces
  while( 1 )
  {
    if( heap_ptr == NULL )  
    {
      if( ( heap_ptr = ( char* )platform_get_first_free_ram( mem_index ) ) == NULL )
      {
        ptr = ( void* )-1;
        break;
      }
    }
     
    // Do we have space in the current memory space?
    if( heap_ptr + incr > ( char* )platform_get_last_free_ram( mem_index )  )
    {
      // We don't, so try the next memory space
      heap_ptr = NULL;
      mem_index ++;
    }
    else
    {
      // Memory found in the current space
      ptr = heap_ptr;
      heap_ptr += incr;
      break;
    }
  }  

  return ptr;
}

Here, the heap_ptr variable keep the last allocated memory address but this value never decreases. Is for this I ask if the assigned memory never are freed. This is not necessarly a memory leak or something like this, I think the management of free areas are reused through the dlmalloc implementation.

Beyond this, I want implement eLua functions (through a c language module) to have information about used, freed and size of heap region. I've read the dlmalloc documentation and I found a function for that called dlmallinfo, but the returned values in my test are not right, the used memory value change randomly. This may be due to my error, I'm not sure. For this I ask you: You know if this function is working in the port of dlmalloc used in elua? (I've seen your name in the configuration macros of dlmalloc ;) )
Thanks a lot!

Sergio

[BogdanM]

Hi,

> This is not necessarly a memory leak or something like this, I think the management of free areas are reused through the dlmalloc implementation.

You're exactly right. "sbrk" is called to give more memory to the *allocator* iself. Inside its memory region, the allocator manages the actual dynamic memory allocated with malloc() and freed with free(). For reference: https://linux.die.net/man/2/sbrk

>  You know if this function is working in the port of dlmalloc used in elua?

I used it very sparingly, and it's been a while, I don't really remember how well it worked. But it definitely shouldn't output pseudo-random values. Not sure what to tell you, it might be that dlmallinfo() doesn't work well with multiple memory regions. Or it might be a completely different problem, I really don't know.
I suppose you already found this, but here is the man page of the mallinfo() function: http://man7.org/linux/man-pages/man3/mallinfo.3.html

Best,
Bogdan

[rosejohn]

Get here the best online technical help in case your organization or home pc and notebook required to being repaired. We offer technical assistance via different channels like email, telephone calls. We have a technical support team that's available 24/7 to tackle customer's technical difficulties. I m always available to your help if you need more advice to Get help with antiviruses software downloads, installation, uninstall, updates, virus removal, etc please see our this site it free service provided: bitdefender support | Canon Printer Offline  | amazon.com/code  | Cash App Login  | Paypal Login  | Linksys Extender Setup | Roadrunner Email | Bitdefender Login | Avast Login | Roadrunner Email | Amazon Prime Login | www.amazon.com/mytvn | Netgear Extender Setup | Belkin Setup | Webroot Download | Norton Download | Belkin N300 Setup