Osci-2.3.4 using mmap instead of malloc/new

[Rajni]

Hi all,

It is observed that with latest upgrade osci-2.3.4 is using mmap instead of malloc/new operator that were being used in earlier versions. This change leads to performance degradation since mmap is slower than malloc. Then why has osci moved to mmap. Does anyone has any idea?

Regards,

Rajni 

[David Black]

First, it is Accellera 2.3.4 since OSCI is ancient history.

This was added to allow address sanitation according to git log comments:

    This is required to make SystemC work with ASAN. The current implementation leads
    to SIGSEGV in ASAN, because it runs into the protected area at the end of the
    stack.

In other words, it supports finding bugs.

For information on ASAN see one of:

• https://github.com/google/sanitizers/wiki/AddressSanitizer
• https://learn.microsoft.com/en-us/cpp/sanitizers/asan?view=msvc-170

Although performance is indeed important, bug finding is often more important.

It is heavily dependent on your particular application and use of SystemC. So you may need to do substantial investigation. The blanket statement "This change leads to performance degradation since mmap is slower than malloc." is incorrect unless highly qualified. It has to do with how you use memory. Have you specifically measured its impact on your design? You can go back to the old approach to compare.

A good discussion of some of the performance issues can be found here:

• https://stackoverflow.com/questions/44001260/random-mmaped-memory-access-up-to-16-slower-than-heap-data-access

You can change it back by defining ENABLE_LEGACY_MEM_MGMT when using cmake or SC_LEGACY_MEM_MGMT if using make when building the executable. Since you are asking about such low-level detail, I assume you can deal with that.

Finally, this is part of the implementation details and not part of the SystemC standard per se. You are free to use your own implementation of the SystemC standard. If you wish to debate this further, please become a member of Accellera and join the Language Working Group to participate in discussions.