× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Comments in-line Neil.


Jon Paris

www.Partner400.com
www.SystemiDeveloper.com



On Nov 19, 2010, at 5:27 PM, rpg400-l-request@xxxxxxxxxxxx wrote:

Is that a hunch or is that based on some previous dealings in that area?

I've worked with many different OSs over the years - most had something of this nature in their dynamic memory handling routines. It makes sense if you think about it because once you've handed out an address you are not able to "shuffle" memory to optimize usage and so having large numbers of tiny "gaps" would not make sense.

I honestly can't recall 10% if that applies to IBM i or not but I'm fairly certain it does.

...
Instead of allocating 6400 bytes it could allocate 9200 bytes, that feels
like a lot of wasted ram?

I doubt it would ever be that big a difference. It probably depends on how big a chunk would be left over/

I do know that most malloc implementations write a 16 byte header that
describes the allocated memory, then calls to dealloc (and realoc) knock 16
bytes off the pointer passed in to get to the header which stores the total
number of bytes stored.

Could this be the extra overhead you are referring to?

I don't recall talking about overhead. It is just a question of not wanting to have to reject a request for 5,000 bytes simply because all you have available is 100 separate areas of 1,000 bytes.




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.