Giter Club home page Giter Club logo

lwmem's People

Contributors

dependabot[bot] avatar edieruby avatar majerle avatar matstm avatar upbeat27 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

lwmem's Issues

[feature request] Select region for mem ops.

Hello there,
I tried your lib recently, it's nice although not fully tested yet.
And I think it is reasonable to add a feature that users can select a specific region to do mem ops because they may have several regions with different sizes, and need to specify the particular one for use.
Thus, hopefully we can select that region manually.
Many thanks.

error in lwmem.h

Hi, I think your library works fine,Thank you very much. However, there is a small error in lwmem.h at line 204.

The original definition
#define lwmem_get_size(ptr) lwmem_get_size(NULL, (ptr))

The correct definition
#define lwmem_get_size(ptr) lwmem_get_size_ex(NULL, (ptr))

Feature request: more stats

Hi!
I found this memory allocator particularly intriguing due to its ability to allocate to many different memory regions.
One thing I find it is missing is more useful statistics.
It would be nice to be able to get this info from each LwMEM instance:

  • Total memory size (yes, technically this could be obtained elsewhere, since you assigned the regions and their sizes)
  • Most memory allocated since init (or least memory available since init)
  • Currently allocated memory (or currently available memory)

These are helpful for determining heap usage over time and detecting leaks, etc.
It could of course be enabled/disabled via some #define, as the current stats are.
It would also be useful if it could be done on a region level vs. an instance level, so you can see if you need to decrease/increase the size of specific regions as you are developing the application.

Problem of user option LWMEM_CFG_ENABLE_STATS and macro lwmem_get_stats

Problem
When LWMEM_CFG_ENABLE_STATS is defined as 0, then the statistics function lwmem_get_stats_ex is removed from header file (see line 116-118 in lwmem.h):

116: #if LWMEM_CFG_ENABLE_STATS || __DOXYGEN__
117: void lwmem_get_stats_ex(lwmem_t* lw, lwmem_stats_t* stats);
118: #endif /* LWMEM_CFG_ENABLE_STATS || __DOXYGEN__ */

When user now uses macro lwmem_get_stats in his code and compiles it, there will be an error, that no reference to the function lwmem_get_stats_ex is defined.

211: #define lwmem_get_stats(stats) lwmem_get_stats_ex(NULL, (stats))

Proposal for fix:
I don't know if this is intended behavior, since this only happens when the statistics function is called while the statistics themselves are turned off. If not i propose the following solutions:

  • If no statisics enabled hide the macro. This will result in a linker error, that the macro is undefined, and not the nested error below.
    #if LWMEM_CFG_ENABLE_STATS || __DOXYGEN__
    #define lwmem_get_stats(stats) lwmem_get_stats_ex(NULL, (stats))
    #endif
  • If no statistics enabled set status input to default values. This will compile and run and will not result in an error or crash. Statistics have no real content though.
    #if LWMEM_CFG_ENABLE_STATS || __DOXYGEN__
    #define lwmem_get_stats(stats) lwmem_get_stats_ex(NULL, (stats))
    #else
    #define lwmem_get_stats(stats) (*stats = (lwmem_stats_t){.mem_size_bytes = 0, .mem_available_bytes = 0, .minimum_ever_mem_available_bytes = 0, .nr_alloc = 0, .nr_free = 0})
    #endif

Warning with LWMEM_CFG_CLEAN_MEMORY and accompanying LWMEM_MEMSET call

Problem:
If user option LWMEM_CFG_CLEAN_MEMORY is enabled (set to 1) there will be a memset-call inside prv_insert_free_block which will clean the free-ed blocks with zeros. Inside this memset-call is a macro, which either returns a block pointer or NULL, where the latter throws a compiler warning -Wnonull for the memset-call.

See the following code snippets of lwmem.c:

111: #define LWMEM_GET_PTR_FROM_BLOCK(block) (void *)((block) != NULL ? ((LWMEM_TO_BYTE_PTR(block)) + LWMEM_BLOCK_META_SIZE) : NULL)

219: /* Check valid inputs */
220: if (nb == NULL) {
221:    return;
222: }

248: LWMEM_MEMSET(LWMEM_GET_PTR_FROM_BLOCK(nb), 0x00, nb->size - LWMEM_BLOCK_META_SIZE);

Compiler-warning:
null argument where non-null required (argument 1) [-Wnonnull]

Proposal for fix:
In this function nb is already checked for not beeing NULL, so the used macro itself does not need to do this again. As a fix for removing this warning I propose a second define, similar to LWMEM_GET_PTR_FROM_BLOCK, which does not check the input for beeing NULL but rather just returns the block. This macro should only be called, if nb is checked for beeing NULL earlier! My proposal code would look like this:

New macro definition:

/**
 * \brief           Get block handle from application pointer. Is not NULL-ptr safe! User must check for NULL pointers in advance to this call! Otherwise use @LWMEM_GET_PTR_FROM_BLOCK
 * \param[in]       block: Input pointer to get block from
 */
#define LWMEM_GET_PTR_FROM_BLOCK_UNSAFE(block) (void *)((LWMEM_TO_BYTE_PTR(block)) + LWMEM_BLOCK_META_SIZE)

Updated memset call:

248: LWMEM_MEMSET(LWMEM_GET_PTR_FROM_BLOCK_UNSAFE(nb), 0x00, nb->size - LWMEM_BLOCK_META_SIZE);

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.