[VxW] Regarding Memory Partition in VxWorks
Srinivas O
In VxWorks a function "memPartCreate" is avilable, which is used to create
memory partition. But to delete the memory
partition created with the above call, there is no function. Once we come
out of the application, this partition is not freed. Hope this leads to
memory leakage or reduction of memory for further usuage. Could anybody
suggest me to delete memory partition.
Best Regards
O.Srinivasan
joe durusau
Srinivas O wrote:
What about memPartFree? Most BSPs (if not all) should have
that. As an aside, note that vsWorks does not have automatic
memory free, not garbage collection by default. You have to
manage memory yourself.
Speaking only for myself,
Joe Durusau
Srinivas O
memPartFree is used to free the memory allocated through
memPartAlloc()..........
Am I right? But memPartCreate will create a partition. This partition should
be deleted and then only
we can free the memory. Could you please tell me the scenario whether can we
use memPartFree() to delete/free
the partition.
Thanks and Regards
O.Srinivasan
John
There is no way to delete a partition in VxWorks 5.x. VxWorks AE did
have support for this operation (along with much more advanced memory
management and a better heap allocation algorithm). Unfortunately,
Wind River EOL'd VxWorks AE and never back ported the improvements to
the 5.x code base.
HTH,
John...
=====
Contribute to the VxWorks Cookbook at: http://books.bluedonkey.org/
Andrew Johnson
>
>> In VxWorks a function "memPartCreate" is avilable, which is used to create
>>memory partition. But to delete the memory
>>partition created with the above call, there is no function. Once we come
>>out of the application, this partition is not freed. Hope this leads to
>>memory leakage or reduction of memory for further usuage. Could anybody
>>suggest me to delete memory partition.
>
> There is no way to delete a partition in VxWorks 5.x. VxWorks AE did
> have support for this operation (along with much more advanced memory
> management and a better heap allocation algorithm). Unfortunately,
> Wind River EOL'd VxWorks AE and never back ported the improvements to
> the 5.x code base.
What does deleting a partition actually mean in the context of vxWorks
5.x? I don't believe the OS keeps a list of the partitions it has created
(other than the system memory partition itself), so the OS doesn't have
any need to know that one is no longer needed. memPartDestroy() is
therefor a synonym for a noop.
Assuming that all memory that was allocated from that partition has been
returned (or that whatever was using that memory no longer needs it and
won't use it again) then the partition memory can be returned to wherever
it came from in the first place. If it came from the system memory
partition (i.e. a call to malloc()), it should be passed back to free()
when the application finishes.
- Andrew
--
Dear God, I didn't think orange went with purple until I saw
the sunset you made last night. That was really cool. - Caro
John
> > There is no way to delete a partition in VxWorks 5.x. VxWorks AE did
> > have support for this operation (along with much more advanced memory
> > management and a better heap allocation algorithm). Unfortunately,
> > Wind River EOL'd VxWorks AE and never back ported the improvements to
> > the 5.x code base.
>
> What does deleting a partition actually mean in the context of vxWorks
> 5.x? I don't believe the OS keeps a list of the partitions it has created
> (other than the system memory partition itself), so the OS doesn't have
> any need to know that one is no longer needed. memPartDestroy() is
> therefor a synonym for a noop.
>
> Assuming that all memory that was allocated from that partition has been
> returned (or that whatever was using that memory no longer needs it and
> won't use it again) then the partition memory can be returned to wherever
> it came from in the first place. If it came from the system memory
> partition (i.e. a call to malloc()), it should be passed back to free()
> when the application finishes.
IIRC, and since I no longer have access to the source I cannot confirm
this, there is a WIND object associated with the partition and that,
albeit relatively small, will be allocated memory outside of the
partition's space - it is basically a small structure, the pointer to
which forms the partition ID.
So, you could free the memory in the pool and then free the memory at
the partition ID as well. Problem is that there is a mutex associated
with the partition too. I can't remember in 5.5 whether this is
embedded in the partition structure, or whether there is simply an ID
of an external semaphore in there. In the former case, you can simply
free the memory; in the latter, you must destroy the semaphore first -
check the header file to see how this was done in 5.5.
I guess a better answer to the original question would have been that
there is not a routine for doing so in the OS, but you have the header
file for the memPart object, so writing one would not be that
difficult (esp. if you know that the memory in your partitions is
always going to be malloc'd so you can just free that too).
Piyush Gupta
as a doubly linked list, allocated list (?) free memory list (?). There are head
and tail bytes around each allocation (or free memory ?) . Depending on the size
and sequence of mallocs and frees, interspersed with some mallocs that are not
yet freed, you could end up in a situation that while there is plenty of
"memory" available, there may not be enough contiguous memory available for the
next malloc in your code. In other words, you could be left with a whole bunch
of defragmented memory and crash. This could conceivable take months to happen
depending on the code. (Wonder if the rover had a similar issue.) Contiguous
fragments are coalesced by vxWorks. In general, I try to stay away from malloc
as far as possible.
-Piyush
John wrote:
> _______________________________________________
> VxWorks Users Group mailing list
> VxWe...@lbl.gov
> http://www-csg.lbl.gov/vxworks/
--
-Piyush