405 views
in Platform Packages by
Hi EW friends,

I have some questions about EwReclaimMemory in gui's mainloop.  Sometimes we find the EwReclaimMemory() occupies too much cpu, so we make some  optimizations, i.e., we degrade its frequency to 1/50, and find it works well , especially save a lot of CPU. But recently, we find there are some crash occurs inside EwReclaimMeory(), maybe EwDisposeStrings or EwDeregisterResource. I wonder know, whether our optimization would cause this. and do you have some good idea about reducing the consumptions of EwReclaimMemory?

BR

Arnold

1 Answer

0 votes
by
 
Best answer

Hi Arnold,

in principle, there should not happen any of the described issues in case that the Garbage Collector is not called every cycle of the main loop.

Anyhow, I assume that EwReclaimMemory() is still called from the main loop and in the context of the GUI thread / task. Calling EwReclaimMemory() from any other thread / task (e.g. with lower priority) will sooner or later inevitably lead to unpredictable behavior!

Do you get any error messages on the console (via serial interface)? Maybe your system is already running out-of-memory because the Garbage Collector is not running, and the crashes are consequential failures.

Generally, I do not recommend to exclude the Garbage Collector from the main loop, for several reasons:

  • Normally the Garbage Collector is only started after the GUI application has processed signals / timers / events and only in these cases can the GUI application and the situation in the memory change. If the GUI is in idle, the Garbage Collector is not called.
  • If the Garbage Collector is called only very rarely, the runtime for a single EwReclaimMemory() may be longer compared to regular usage.
  • The amount of memory used for a higher number of main loop cycles is completely unpredictable.

Best regards,

Manfred.

by
I have confirmed the EwReclaimMemory is inside gui main loop,  and there are no oom issues found in our system.  The time interval of each loop normally  is 2ms. Each time we found the interval of reclaim memory to be more than 100ms, we invoke once.  As well, I did found any EwPanic in the process of new   Ew object. The crash seems to be EwFree something already been freed? Is there any good method to debug on the issue?
by

Maybe the crash is called due to some other invalid accesses, e.g. by keeping a string or object within native C code.

Can you reproduce the problem when the GC is running every loop?

Btw: Which version are you using? 

And: Which memory manager are you using? In case you are using the Embedded Wizard heap manager, you should get some message from EwVerifyHeap() in case that the memory is corrupted.

Best regards,

Manfred.

by
Hi Manfred,

Is there any prerequisite to use EwVerifyHeap()? Or we just add EwVerifyHeap() before EwReclaimMemory() to check whether there are wrongs?

BR

Arnold
by

Hi Arnold,

the prerequisite to use EwVerifyHeap() is the usage of the Embedded Wizard heap manager - initialized with EwInitHeap() and EwAddHeapMemoryPool().

Best regards,

Manfred.

by
Thanks, I'm going to have a try!

Ask Embedded Wizard

Welcome to the question and answer site for Embedded Wizard users and UI developers.

Ask your question and receive answers from the Embedded Wizard support team or from other members of the community!

Embedded Wizard Website | Privacy Policy | Imprint

...