Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix pointer arithmetic (invalid use of void) #57

Merged
merged 1 commit into from
Sep 5, 2021

Conversation

dexterbg
Copy link
Contributor

@dexterbg dexterbg commented Sep 5, 2021

gcc in pedantic mode fails to compile umm_malloc.c because of the void * arithmetics:

umm_malloc.c:326:49: error: invalid use of 'void'
     c = (((void *)ptr) - (void *)(&(UMM_HEAP[0]))) / UMM_BLOCKSIZE;

See e.g. https://stackoverflow.com/a/3524270 and https://stackoverflow.com/a/25375321

@rhempel rhempel merged commit 91ac2cc into rhempel:master Sep 5, 2021
@rhempel
Copy link
Owner

rhempel commented Sep 5, 2021

Thanks for this - every MR gets reviewed (eventually). I just happened to have some time for this little hobby project this morning :-)

Can I ask you to let me know a bit more about where you are using umm_malloc? I can see from your GitHub profile that you have an interest in vehicle monitoring systems ...

@dexterbg
Copy link
Contributor Author

dexterbg commented Sep 5, 2021

Ralph,

on the contrary, thank you for the lib :-)

I'm one of the main developers on the OVMS project, an all open source vehicle monitoring solution:

The OVMS includes Duktape (https://github.com/svaarala/duktape) to support Javascript plugins on the vehicle module. We're running the system on an ESP32 using a modified esp-idf release 3. We've had the issue of the standard memory management getting into trouble with the allocation/freeing pattern of the Javascript heap & garbage collection, leading to the overall system slowing down significantly over time.

Your library is now managing the Duktape heap on a dedicated chunk of main memory, which solves the issue. As a very welcome side effect, scripting performance has got a boost of factor 3-8, depending on how memory intense the script is.

I can't tell how much of that speed boost is because umm_malloc doesn't need to take care of locking or poisoning in this use case, and the allocations also don't need to be tracked for the FreeRTOS task monitoring. According to Angus from Espressif (https://www.esp32.com/viewtopic.php?t=8628#p36412), their allocator was also originally based on your work, but they went on to an own implementation to support multiple memory regions with different capabilities.

You wrote:

You can even use it on a bigger project where a single process might want to manage a large number of smaller objects, and using the system heap might get expensive.

So… consider that confirmed :-)

Regards,
Michael

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants