1. allocate() and free()
- Posted by Aku <aku at inbox.as>
Dec 01, 2000
------------C5E79E2F95FC21
try:
run km.exw (attached)
click "get total free memory" and remember how much
click "allocate and free", some memory is allocated and freed
click "get total free memory" and free memory is bigly decreased
why?
------------C5E79E2F95FC21
2. Re: allocate() and free()
free() does not give memory back to the operating
system. It simply puts it into a pool of free memory
that's controlled by Euphoria. It will be used by future
calls to allocate().
When the pool is exhausted, allocate() will get
more memory from the operating system, but
free() will never give it back.
I don't know of any language that gives
heap space back to the operating system.
It would be a tricky business, since you can
theoretically only give back space at the end
of the heap, not an arbitrary piece in the middle
somewhere.
In Windows, this is all virtual memory anyway.
The operating system can swap out pages
of memory that aren't being actively used,
to make room for active programs to run.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: allocate() and free()
----- Original Message -----
From: "Robert Craig" <rds at RAPIDEUPHORIA.COM>
>
> I don't know of any language that gives
> heap space back to the operating system.
The Amiga OS does.
Also, if you use the acquire_mem() and release_mem() routines that come with
win32lib.ew, you do not "lose" memory. The release_mem() routine gives back
the memory to Windows for other applications to use. However, the swap file
size might increase thus reducing the free space on your swap drive.
------
Derek Parnell
Melbourne, Australia
(Vote [1] The Cheshire Cat for Internet Mascot)
4. Re: allocate() and free()
- Posted by Robert Craig <rds at RAPIDEUPHORIA.COM>
Dec 01, 2000
-
Last edited Dec 02, 2000
Derek Parnell writes:
> Rob Craig writes:
>> I don't know of any language that gives
>> heap space back to the operating system.
>
>The Amiga OS does.
>
> ...The release_mem() routine gives back
> the memory to Windows for other applications to use.
release_mem() appears to call Euphoria's free().
Euphoria's free() calls C's free(), which does not
give the memory back to the operating system.
The memory stays in the heap, ready for use
within the same Euphoria program (either for
calls to allocate(), or for creating new sequences etc.)
C programs on the Amiga or any other system
would likely work the same way. The heap memory
used by C's malloc() and free() is not returned to the
O/S until the application terminates. It's not practical
for any O/S to take back a small piece of memory
from the middle of your address space.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
5. Re: allocate() and free()
----- Original Message -----
From: "Robert Craig" <rds at RAPIDEUPHORIA.COM>
> >
> > ...The release_mem() routine gives back
> > the memory to Windows for other applications to use.
>
> release_mem() appears to call Euphoria's free().
It does in earlier versions. I replaced all this with calls to the Windows
library routines instead. The current library does not use Euphoria's
routines (directly anyhow).
> C programs on the Amiga or any other system
> would likely work the same way. The heap memory
> used by C's malloc() and free() is not returned to the
> O/S until the application terminates. It's not practical
> for any O/S to take back a small piece of memory
> from the middle of your address space.
It depends on the C implementation for the Amiga. The Amiga OS has native
library routines that implement global malloc() and free() type operations.
If the C complier uses these then freed memory is immediately available for
oher processes. If the C complier is just ported to the Amiga, rather than
optimised for it, then Robert is quite correct.
The Watcom Amiga C compiler was a port from unix and it had its own heap
management, and heap memory was not returned until the application finished.
The Aztec C compiler choose to optimise the malloc() etc routines so that
they directly called the Amiga system library. Other Amiga languages such as
Amiga Basic, Blitz, AMOS, and E used the system library.
------
Derek Parnell
Melbourne, Australia
(Vote [1] The Cheshire Cat for Internet Mascot)
6. Re: allocate() and free()
- Posted by Aku <aku at inbox.as>
Dec 02, 2000
I have made a program in VB that free memory that do not used by the
operating system. I use this code:
a = space(10485760) ' Allocate 10 MB of memory for variable 'a'
' with spaces.
'-------- the free memory decreases...
a = "" ' Free that 10 MB.
'-------- ...then increases again.
I tried run this in Euphoria:
object a
? getc(0)
a = repeat(' ', 10485760)
? getc(0)
a = ""
? getc(0)
And this is a test:
object a
? getc(0) -- Here, my free memory: 110 MB
a = repeat(' ', 10485760)
? getc(0) -- Here, my free memory: 30 MB
-- [ repeat(' ', 10485760) uses 80 MB
-- of memory!!! ]
a = ""
? getc(0) -- Here, my free memory is STILL 30 MB!
I can free memory that is used in VB, why not in Euphoria?
______________________________________________________________________
R> free() does not give memory back to the operating
R> system. It simply puts it into a pool of free memory
R> that's controlled by Euphoria. It will be used by future
R> calls to allocate().
R> When the pool is exhausted, allocate() will get
R> more memory from the operating system, but
R> free() will never give it back.
R> I don't know of any language that gives
R> heap space back to the operating system.
R> It would be a tricky business, since you can
R> theoretically only give back space at the end
R> of the heap, not an arbitrary piece in the middle
R> somewhere.
R> In Windows, this is all virtual memory anyway.
R> The operating system can swap out pages
R> of memory that aren't being actively used,
R> to make room for active programs to run.
R> Regards,
R> Rob Craig
R> Rapid Deployment Software
R> http://www.RapidEuphoria.com
7. Re: allocate() and free()
- Posted by Robert Craig <rds at RAPIDEUPHORIA.COM>
Dec 01, 2000
-
Last edited Dec 02, 2000
Aku writes:
> -- [ repeat(' ', 10485760) uses 80 MB
> -- of memory!!! ]
I don't trust your method of determining free memory.
The call to repeat() above only uses 4x1Mb = 4Mb not 80Mb.
It's also possible that malloc() will ask for *slightly* more than
4Mb.
> I can free memory that is used in VB, why not in Euphoria?
I don't trust your measurements. The O/S call,
GlobalMemoryStatus(), requires you to set the first field
in a structure before making the call, something you
don't bother to do. It also says the values returned
can change even if *nothing* happens in your program
between calls - i.e. the external world can change these
numbers independent of your program.
Euphoria is managing memory in a reasonable way.
A lot of people assume that memory will be given back
to the O/S when it's freed. This is a popular misconception.
Even if it were possible to do this, it would be highly inefficient
to call the O/S with every call to free().
Be thankful you aren't using Java. The last time I looked,
Sun's Java was pre-allocating 16Mb before any tiny Java
program even started running!
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
8. Re: allocate() and free()
- Posted by Robert Craig <rds at RAPIDEUPHORIA.COM>
Dec 01, 2000
-
Last edited Dec 02, 2000
Robert Craig writes:
>> -- [ repeat(' ', 10485760) uses 80 MB
> I don't trust your method of determining free memory.
> The call to repeat() above only uses 4x1Mb = 4Mb not 80Mb
Sorry! It's late, my eyes are getting tired 
.
I guess that should be 40Mb.
But I still doubt that VB really returns freed memory to the O/S.
If it does, it must have a horribly inefficient memory allocator.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
9. Re: allocate() and free()
On 1 Dec 2000, at 23:57, Robert Craig wrote:
> Robert Craig writes:
> >> -- [ repeat(' ', 10485760) uses 80 MB
> > I don't trust your method of determining free memory.
> > The call to repeat() above only uses 4x1Mb = 4Mb not 80Mb
>
> Sorry! It's late, my eyes are getting tired .
> I guess that should be 40Mb.
> But I still doubt that VB really returns freed memory to the O/S.
> If it does, it must have a horribly inefficient memory allocator.
Ok, what about dos5? dos6.22? dos7? If i use 50 megs on a dos box with
64megs, and then write out all the vars and null them, then shell to another
dos session, how much memory will that session have to work with? Is
that repeatable?
Kat
10. Re: allocate() and free()
- Posted by Aku <aku at inbox.as>
Dec 02, 2000
------------F32315416EE956A
R> I don't trust your measurements. The O/S call,
R> GlobalMemoryStatus(), requires you to set the first field
R> in a structure before making the call, something you
R> don't bother to do. It also says the values returned
R> can change even if *nothing* happens in your program
R> between calls - i.e. the external world can change these
R> numbers independent of your program.
OK, now I have set the first field of the struct MEMORYSTATUS
and the result is same as first.
If you don't trust me, you can try yourself.
Here is attached testmem.zip that contains several files:
checkmem.exe = compiled VB program to get memory status
checkmem.* = the sourcecode of checkmem.exe
usemem.exe = compiled VB program that fill a variable with 10 MB
of spaces and can free memory to operating system
usemem.vbp, usemem.frm, usemem.vbw = the sourcecode of usemem.exe
usemem.exw = a euphoria program like usemem.exe
usemem.prj = the IDE file...
To try:
run checkmem.exe
run usemem.exe
click 'get free memory' on checkmem.exe
click first button on usemem.exe
'get free memory' again [free memory decreases]
click second button on usemem.exe
'get free memory' again [free memory increases]
close usemem.exe
close checkmem.exe
run checkmem.exe
run usemem.exw
click 'get free memory' on checkmem.exe
click first button on usemem.exw
'get free memory' again [free memory decreases]
click second button on usemem.exw
'get free memory' again [free memory does NOT increase]
close usemem.exw
close checkmem.exe
------------F32315416EE956A
11. Re: allocate() and free()
Aku writes:
> If you don't trust me, you can try yourself.
Ok, I tried it. Thanks for the very clear demo programs.
It tells me I have 1953Mb of free "memory"
on my 64Mb RAM machine. After the VB program
allocates 10Mb it tells me I have 27Mb less "memory".
Then when the 10Mb is cleared, it tells me I now have
1966Mb, i.e. 13Mb more than I had at the
very beginning.
I don't know what the numbers mean.
I respectfully suggest that you don't know
what the numbers mean either.
It's true that the Euphoria program (as I would expect)
didn't bounce back to the original level of free "memory",
since it is keeping the memory for further use.
Maybe there's a special case where VB can return
the memory. If it's like other Microsoft Basic's I've studied
in the past, it has a separate contiguous area of
memory reserved for just strings, and it triggers an
expensive garbage collection whenever it happens to
run out of string memory. Perhaps it can return to the O/S,
or downsize, that particular block if it's at the end of the heap.
Anyway, this is just idle speculation.
I am content with Euphoria's current way of allocating
and deallocating storage, and I have no plans to change it.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
12. Re: allocate() and free()
- Posted by Aku <aku at inbox.as>
Dec 03, 2000
R> Ok, I tried it. Thanks for the very clear demo programs.
R> It tells me I have 1953Mb of free "memory"
R> on my 64Mb RAM machine. After the VB program
R> allocates 10Mb it tells me I have 27Mb less "memory".
R> Then when the 10Mb is cleared, it tells me I now have
R> 1966Mb, i.e. 13Mb more than I had at the
R> very beginning.
R> I don't know what the numbers mean.
R> I respectfully suggest that you don't know
R> what the numbers mean either.
1953 MB is 64 MB physical memory and pagefile depending to your
drive free space that contains the pagefile.
If the VB program use 10 MB of memory (not 10 MB of string), the O/S
manages the memory, so unnecessary memory from other program
discarded. so free memory decreased less than 10 MB.
after that 10 MB memory freed, free memory is more than before
because that discarded memory.
R> It's true that the Euphoria program (as I would expect)
R> didn't bounce back to the original level of free "memory",
R> since it is keeping the memory for further use.
R> Maybe there's a special case where VB can return
R> the memory. If it's like other Microsoft Basic's I've studied
R> in the past, it has a separate contiguous area of
R> memory reserved for just strings, and it triggers an
R> expensive garbage collection whenever it happens to
R> run out of string memory. Perhaps it can return to the O/S,
R> or downsize, that particular block if it's at the end of the heap.
R> Anyway, this is just idle speculation.
R> I am content with Euphoria's current way of allocating
R> and deallocating storage, and I have no plans to change it.
R> Regards,
R> Rob Craig
R> Rapid Deployment Software
R> http://www.RapidEuphoria.com
