|
low memory malloc? |
|
Stoppers (21:24 30/6/2009) andy_s (21:47 1/7/2009) Stoppers (07:46 2/7/2009) richcheng (14:52 2/7/2009) Stoppers (16:26 2/7/2009) tribbles (17:02 2/7/2009) Stoppers (17:49 2/7/2009) tribbles (21:53 2/7/2009) Stoppers (12:32 3/7/2009) nunfetishist (12:13 6/7/2009)
|
|
Simon Willcocks |
Message #110434, posted by Stoppers at 21:24, 30/6/2009 |
Member
Posts: 302
|
Hi,
Any bright ideas about how I could ensure that a Linux process only allocates memory in the bottom 1 or 2 GB?
Some older RO software expects everything to be in low memory, and it would be nice to avoid writing a whole new memory management subsystem based on mmap. |
|
[ Log in to reply ] |
|
Andy Stringer |
Message #110442, posted by andy_s at 21:47, 1/7/2009, in reply to message #110434 |
Member
Posts: 13
|
Hi, not sure but firstly do you mean you're porting a RISC OS app to Linux and you need your own app to only ever be allocated low memory? Or that you want to load other people's apps into low memory? If it's your own app what's it written in? C/C++? |
|
[ Log in to reply ] |
|
Simon Willcocks |
Message #110444, posted by Stoppers at 07:46, 2/7/2009, in reply to message #110442 |
Member
Posts: 302
|
I'm writing Linux code in C that should only allocate memory in the bottom 2GB.
It's for ROLF. I want to use RISC OS modules (specifically AWRender) from local code, and I understand that some of its supporting modules need top-bit-clear memory addresses.
I'd like to be able to ignore these requirements in the native Linux code, even at the "cost" of limiting applications containing RO code to a paltry 2GB of virtual memory space.
What I'd really like to be told is that you just use a function called lalloc, or need to have an environment variable called MALLOC_LOWMEM defined when you run the program!
Otherwise, I have to define my own memory map and implement OS_Heap. |
|
[ Log in to reply ] |
|
richard cheng |
Message #110449, posted by richcheng at 14:52, 2/7/2009, in reply to message #110444 |
Posts: 655
|
Just had a look at your ROLF blog. It's starting to look quite intriguing! |
|
[ Log in to reply ] |
|
Simon Willcocks |
Message #110452, posted by Stoppers at 16:26, 2/7/2009, in reply to message #110449 |
Member
Posts: 302
|
Just had a look at your ROLF blog. It's starting to look quite intriguing! Thanks.
I've just cut out a load of debug output from the compatibility library, and the viewer application now displays the StartUp image in a little over 2s, Midget 2.7s, Apple 8.6s and Acorn 61ms.
Still not as fast as my RPC :-( |
|
[ Log in to reply ] |
|
Jason Tribbeck |
Message #110453, posted by tribbles at 17:02, 2/7/2009, in reply to message #110452 |
Captain Helix
Posts: 929
|
It does sound very interesting.
If it helps, I do have some malloc-like routines I wrote to replace the Acorn ones - but you'd need to do the "get a chunk of space in low memory" code yourself. |
|
[ Log in to reply ] |
|
Simon Willcocks |
Message #110454, posted by Stoppers at 17:49, 2/7/2009, in reply to message #110453 |
Member
Posts: 302
|
If it helps, I do have some malloc-like routines I wrote to replace the Acorn ones That'd be great, as long as I can release them under the LGPL.
- but you'd need to do the "get a chunk of space in low memory" code yourself. Linux seems to start allocating at the top of memory, so it's just a matter of using mmap with the appropriate parameters, which I had to do to give BASIC its workspace, anyway.
Whether that will work with ARMLinux, I don't know, but I'll burn that bridge when I come to it. |
|
[ Log in to reply ] |
|
Jason Tribbeck |
Message #110457, posted by tribbles at 21:53, 2/7/2009, in reply to message #110454 |
Captain Helix
Posts: 929
|
If it helps, I do have some malloc-like routines I wrote to replace the Acorn ones That'd be great, as long as I can release them under the LGPL. I had intended to release under LGPL, but under RISC OS at the time separate linked libraries were impossible, so I released under the artistic license.
I'm quite willing to relicense it for you - just have a look and see if it does what you need; if you're happy, I'll do you an LGPL licensed version. I can't say it's totally bug free, but I have used the code for quite a while. It doesn't do a great deal (it's under 200 lines)!
http://www.rovlib.com/
And the particular component is probably the GenHeap bit.
http://www.rovlib.com/api/genheap-frame.html
I've just had a look at the code, and I have done a better version somewhere else.
The better version uses the concept of small and large blocks, and puts small blocks into large blocks, so if you free up all the small blocks in a large block, it frees the large block too - the idea is to prevent fragmentation.
If I remember what I did it in, and I can release it, I'll send it on (this should get you going at least).
- but you'd need to do the "get a chunk of space in low memory" code yourself. Linux seems to start allocating at the top of memory, so it's just a matter of using mmap with the appropriate parameters, which I had to do to give BASIC its workspace, anyway.
Whether that will work with ARMLinux, I don't know, but I'll burn that bridge when I come to it.A mate of mine ported a version of Prolog to the Inmos Transputer. The primary problem he had was that NULL on a Transputer was 0x80000000, and the program was littered with things like:
void* chunk = malloc(1024); if(!chunk) { //... }
0x00000000 was a valid area of memory to be allocated (but pretty rarely). |
|
[ Log in to reply ] |
|
Simon Willcocks |
Message #110462, posted by Stoppers at 12:32, 3/7/2009, in reply to message #110457 |
Member
Posts: 302
|
It looks ideal to me, thanks. I'll give it a go as soon as I get a chance. |
|
[ Log in to reply ] |
|
Rob Kendrick |
Message #110482, posted by nunfetishist at 12:13, 6/7/2009, in reply to message #110457 |
Today's phish is trout a la creme.
Posts: 524
|
void* chunk = malloc(1024); if(!chunk) { //... }
People who write code like this need to be sacked or educated with a sock containing a brick.
mmap()ing some low memory and then using dmalloc() within it seems like the simple approach. |
|
[ Log in to reply ] |
|
|