Thread Class Memory Fuzzy on Embedded Platform

Question

I ran into a strange problem that I was able to track down, but I still don't see the reason. Maybe someone here can shed some light?

I work on a PowerPC processor on top of VxWorks 5.5 developing in C ++ using the PPCgnu604 toolchain.

I have a class like:

class MyClass { public: void run( void ); private: CommandMesssageClass command; StatusMessageClass status; }; 

When my application is running, it will dynamically allocate an instance of MyClass and spawn a thread that points to its "run" function. In fact, he just sits there to vote on teams and after receiving will issue a status.

Please note that this is an abridged version of the class. There are several other methods and variables for brevity.

The problem that I see is when messages about the command and status are defined as private members of the class, I get a change in the available bytes in the memory, despite the fact that there should not be a dynamic memory allocation. This is important because it has to be a deterministic and speed-safe procedure.

If I move one or both of the message declarations to the start function, it works fine without extra highlighting!

I need to miss something fundamental in my understanding of C ++ declarations and memory allocation. I understand that the class instance that I dynamically create will be completely allocated to the heap (including all member variables) when it is created. The difference I see here is that moving message declarations to the launch function pushes them on the stack instead. The pile in this case is more than large enough to accompany the entire class size. Why, apparently, not enough memory is allocated until certain parts are used?

Message classes do not dynamically allocate their own. (And if they did, I would expect that moving the ad would not change the behavior in this case, and I would still see the heap resize.)

To control memory allocation, I use the following call to VLLL memx (or memPartLib):

 memPartInfoGet( memSysPartId, &partitionStatus ); ... bytesFree = partitionStatus.numBytesFree; 

Edit:

To clarify, the MyClass object is initialized and initialized in the initialization procedure, and then the code introduces speed-safe processing. During this time, after receiving the command message on the serial line (the first interaction with the objects of the Command or Status message), additional memory is allocated (or, rather, the number of free bytes decreases). This is bad because dynamic memory allocation is not deterministic.

I was able to get rid of the problem by moving the class variables as I described.

Answer 1

I am missing something fundamental in my understanding of C ++ declarations and memory allocation.

I do not think so. All that you say that you expect above is true - programmers have relied on this behavior for a long time. :-)

Why doesn't it seem like enough memory is allocated until certain servings are used?

For brevity, you have left the grace of the class. I have experience debugging similar problems, and I think that somewhere there a library function, in fact, makes a distribution of runtimes that you are not aware of.

In other words, runtime distribution is present in both cases, but two different MyClass sizes mean that the malloc pools are populated differently. This can be proved by moving objects onto the stack inside run (), but populating MyClass to the same size. If you still see a free memory drop, then this has nothing to do with whether these objects are on the heap or the stack ... this is a secondary effect, which is due to the size of MyClass.

Remember that malloc is stocky - most implementations do not perform individual distributions for each call in malloc. Instead, it redistributes and stores memory in the pool, and increases these pools if necessary.

I am not familiar with your toolchain, but typical suspects for unexpected small distributions on embedded systems include ctype functions (locales) and date and time functions (time zone).