See the wiki. Don't mix the two!! Ever.Yes, I know that bloody well, my new heaptrc WITH cmem nearly works but bangs because HEAP.INC is USED BEFORE (in ' { Arguments } setup_arguments;') having had the opportunity to install cmem.
See the wiki. Don't mix the two!! Ever.Yes, I know that bloody well, my new heaptrc WITH cmem nearly works but bangs because HEAP.INC is USED BEFORE (in ' { Arguments } setup_arguments;') having had the opportunity to install cmem.
Why use cmem ?
because it seems much faster in multihtreading applications.
use -Fa command line option. From docs:That does not work if heaptrc is selected, though. cmem will still be loaded after heaptrc. Still the same problem about using two memory managers.
-Fa<x>[,y] (for a program) load units <x> and [y] before uses is parsed
That does not work if heaptrc is selected, though. cmem will still be loaded after heaptrc. Still the same problem about using two memory managers.He does not say he wants both at the same time. From what I read he either wants:
So in any case just one mem-mgr.
At least that his how I read his posts
use -Fa command line option. From docs:Thanks for the tip.
-Fa<x>[,y] (for a program) load units <x> and [y] before uses is parsed
see https://forum.lazarus.freepascal.org/index.php/topic,44590.0.html.
See my last line above. The sick option part..
You are wrong in assuming it is faster. cmem does simply larger allocations, which can easily cause problems in long running applications. It looks faster, but not always and you should test.
Technically cmem is a bare and very basic OS heap based manager. The default memory manager is more advanced than that.cmem uses msvcrt in win10 and seems to be a tcmalloc allocator. tcmalloc looks like a subtle piece of software. That heap allocator has much evolved in the last 6 years and seems to be the mainstream heap allocator whereas HEAP.INC doesn't seem to have evolved in the last 10 years.
With threads, you need scaling. cmem does not scale at all.
Sadly, the compiler insists on having system beeing initialized BEFORE cmem than with heap.inc ...
cmem is mostly meant for *nix, e.g. to use valgrind.
I don't think this is really tested functionality on Windows, specially in combination with heaptrc.
You may want to try asking on the fpc-devel mail list.Thanks for your help.
But I am not sure it is possible. AFAIK system is always used. So even your unit is implicitly using system. Which means never mind how early you load your unit, it will load system before itself.
I don't think this is really tested functionality on Windows, specially in combination with heaptrc.I know it works because I run both FPC and Lazarus with cmem for the last 3 months, not just 5 minutes sometimes, but for hours many days in a week.
Sadly, the compiler insists on having system beeing initialized BEFORE cmem than with heap.inc ...
You may want to try asking on the fpc-devel mail list.
But I am not sure it is possible. AFAIK system is always used. So even your unit is implicitly using system. Which means never mind how early you load your unit, it will load system before itself.
If BrunoK wants to use the Windows heap manager directly for all allocations, including those in early startup than he needs to implement and set his heap manager directly in the System unit. This involves at least rtl\win32\system.pp, rtl\win64\system.pp, rtl\win\sysheap.inc and rtl\inc\heap.inc.The idea is to stay near current operation.
Don't mess with these things! The Windows RTL has a secondary entry point in Exec_Tls_Callback in rtl\win\systlsdir.inc which is called before the normal entry point and which might lead to allocations. It might not do so now, but it's not guaranteed to be this way in the future as well.If BrunoK wants to use the Windows heap manager directly for all allocations, including those in early startup than he needs to implement and set his heap manager directly in the System unit. This involves at least rtl\win32\system.pp, rtl\win64\system.pp, rtl\win\sysheap.inc and rtl\inc\heap.inc.The idea is to stay near current operation.
I have already added a -dCMEM compiler option in TOption.interpret_option + include(init_settings.globalswitches,cs_use_cmem); { new cs_use_cmem in enum) +
in pmodules.pas loaddefaultunits
{ The correct heap manager should be setup BEFORE 'system' initializes
but it is not the case yet ~bk }
{ Units only required for main module }
if (cs_use_cmem in current_settings.globalswitches) then
AddUnit('cmem');
that works without any trouble, but there is still this question of getting them in the correct order in fpc_InitializeUnits.
You are alright about maybe messing with these things. I won't come complaining if it breaks and anyway it is my custom 3.0.6 version.
Don't mess with these things! The Windows RTL has a secondary entry point in Exec_Tls_Callback in rtl\win\systlsdir.inc which is called before the normal entry point and which might lead to allocations. It might not do so now, but it's not guaranteed to be this way in the future as well.
The only clean way is to integrate it directly into the System unit.
Don't mess with these things! The Windows RTL has a secondary entry point in Exec_Tls_Callback in rtl\win\systlsdir.inc which is called before the normal entry point and which might lead to allocations. It might not do so now, but it's not guaranteed to be this way in the future as well.
The only clean way is to integrate it directly into the System unit.
But cmem is an unit, and as such implicitly requires system, which means that system initializes before cmem?