Re: [program-l] memory management
- From: "Tyler Littlefield" <tyler@xxxxxxxxxxxxx>
- To: <programmingblind@xxxxxxxxxxxxx>
- Date: Sun, 12 Apr 2009 10:55:57 -0600
thanks. I'm just worried about speed. I doubt this would be anything big, but I
would like to have a little system that I can write games for or something
similar. I'm going partying once I write my first tic-tac-toe game and it
actually works. :p
Thanks,
Tyler Littlefield
Web: tysdomain.com
email: tyler@xxxxxxxxxxxxx
My programs don't have bugs, they're called randomly added features.
----- Original Message -----
From: tribble
To: programmingblind@xxxxxxxxxxxxx
Sent: Sunday, April 12, 2009 10:54 AM
Subject: Re: [program-l] memory management
Hey Ty -- you can do it all at once or if your list of memory intervals i
ordered, it would only take a few nanoseconds to do it on the fly.
But whatever works is fine.
Have fun.
--le
----- Original Message -----
From: Tyler Littlefield
To: programmingblind@xxxxxxxxxxxxx
Sent: Sunday, April 12, 2009 11:50 AM
Subject: Re: [program-l] memory management
Hello laura.
I was planning on using a struct , or a set of structs that would hold the
flags and etc; I guess I wasn't all to clear.
I was mainly worried about speed. AS it's not a disk i/o operation, the
overhead should be limited. Only time I would need to compact is when new
memory was requested. I was also thinking about building a "compact" interupt
handler, that would clean up the memory and make free blocks available, or keep
a list.
Here's how I have it planned out.
I'll have a linked list of structures with:
flags,
pid (so I know what created the memory block), and size. then a pointer to
the block, and a pointer to the next node.
So, I allocate the node+sizeof(memory_header) and set the pointer to the
top of the memory block created. I need to find some way of locking memory so
that the programmer can't go ahead of it's bounds, but I don't think that is an
issue right now; that would be later on.
When I have a block freed, I add the memory header to another list. When
new memory is allocated, it can run the compact function which will check to
see if a block is next to another block.
The only way I can think to do this is with nested loops, checking each
block against all other blocks in turn, as there may be consecutive memory
blocks at say node 45 and node 1.
Thanks,
Tyler Littlefield
Web: tysdomain.com
email: tyler@xxxxxxxxxxxxx
My programs don't have bugs, they're called randomly added features.
----- Original Message -----
From: tribble
To: program-l@xxxxxxxxxxxxx ; bprogramming
Sent: Sunday, April 12, 2009 10:43 AM
Subject: Re: [program-l] memory management
Hi Ty --
There are several ways you could handle this -- I tend to prefer keeping
the MM information in a separate data structure that points into your
allocatable memory, rather than putting used or not-used flags in the blocks of
memory themselves -- the reason being that if the programmers happen to
overwrite the system info -- for example, writing out of bounds on an array,
you may never know what hit you, so to speak. Also, if you need several of
your blocks to be contiguous, what will you do with the system information
cookie at the start or end of your allocated blocks?
No, there is no simple way to handle memory management. But the code
isn't all that difficult to understand.
I wrote a little OO library in C++ that managed memory for a linker, and
it was quite manageable. It contained a linked list of pointers into
consecutive intervals of memory -- that is, the pointers in the list were of
increasing value, and each record contained the number of bytes in that
interval. Then if I needed an interval of memory, I would search through the
available intervals and find a best fit. And when I freed memory, I would
insert the freed interval back into the list, and if it was adjacent to the
free interval before it or after it, I would merge them into one big interval.
Searching the fragments sounds like it would be time consuming, but it is
a relatively brief operation that doesn't get invoked that often.
Let me know if you have a question. I don't have the code for that old
linker, but writing it or a better one yourself would be a good exercise.
Happy hacking.
--le
----- Original Message -----
From: Tyler Littlefield
To: programmingblind@xxxxxxxxxxxxx
Sent: Sunday, April 12, 2009 10:29 AM
Subject: [program-l] memory management
Hello list,
I'm working on building a kernel from scratch (just for something to
do, I'm learning quite a lot out of it), and have a question.
I was thinking about how I'm going to implament the MM (memory manager).
I had an idea of making blocks of memory available, putting a used or
unused flag on them for now. each block would be of set size, and I could have
a lookup table of sorts.
My other idea was to make them all hold pointers to the next block of
data.
Now, I'm seeing issues with both problems.
If I keep a list of reserved memory, and add a structure to the end of
the list when a new chunk of memory is requested, that works great. But then we
have the issue of memory getting destroyed in the middle.
If someone requests a 1KB block and someone else requests 512 and then
frees it, I can delete that and mark that memory as unused; my issue is this.
Eventually my memory is going to be split up enough that it will
require I "compact" it to fill in those gaps, which would break any code
referencing that memory.
Is there an easier way to do this?
Thanks,
Tyler Littlefield
Web: tysdomain.com
email: tyler@xxxxxxxxxxxxx
My programs don't have bugs, they're called randomly added features.
Other related posts:
