1 Reply Latest reply on Jun 1, 2012 10:56 PM by Steve.Clamage-Oracle

    STLPort memory allocation issue and _STLP_USE_MALLOC

      In our group (CGBU BRM) we have ported our application to use the STLPort std c++ collections - and during our current benchmarking issues are found that the STLPort is not allowing to scale when multiple threads are configured. Further to analysis, it was noted that the STL_Port uses the default node allocator engine for eveyr allocation/deallocation (which overrides the default/custom memory allocators like libumem/mtmalloc) - and this nodeallocator has a single threaded mutex lock gaurd over the memory alloc/dealloc.
      STLPort documentation indicates that defining the flag "_STLP_USE_MALLOC" allows to use the default memory allocator (instead of this node allocator) - has this been verified or similar issues found in this regard?

      Senthil Madasamy
        • 1. Re: STLPort memory allocation issue and _STLP_USE_MALLOC
          The macro STLPUSE_MALLOC is a configuration macro that can be used when STLport is initially built, by enabling the definition in the STLport configuration file. This and other configuration macros cannot be modified with the STLport as supplied with Studio. You would have conflicting definitions of various classes and functions in the runtime library compared with user code.

          We looked into various ways of changing the default allocator behavior, but could not find a way that would retain binary compatibility. We would either have to provide two versions of STLport with the compiler, or break binary compatibility. We do not consider either of these to be viable solutions, since another option is already available.

          If you are running on Solaris 10u10 or 11, I recommend instead that you use the Apache stdcxx library. To use this library instead of STLport, replace the library=stlport4 option with -library=stdcxx4.
          You will of course have to recompile all the C++ code.