1. About Eu garbage collection
- Posted by Henri.Goffin at sbs.be
Aug 20, 2001
Hi everybody!
It is probably to late to propose enhancement for 2.3 but maybe for the next
one.
Here's my problem. A program I am working on makes use of huge sequences. Some
of them - the biggest ones - are just used temporarily. So I thought naively that
when the routine was done extracting useful data from thoses big sequences it
would suffice to make 'huge = {}' to free up memory. But nope.
It seems that once memory has been dynamically assigned to sequences there is no
way to free it until the program is done. Am i right?
- If no, can someone tell how this can be done? Re-using the same sequence could
be a solution but this strategy might be very tricky to implement depending on
the program logic
-If yes, could'nt it be thinkable to have (in a more or less remote future) some
routine built into Euphoria runtime that would free the memory associated to
specified objects whenever you know you don't need those object at some point in
your program?
Henri Goffin
2. Re: About Eu garbage collection
On 20 Aug 2001, at 19:14, Henri.Goffin at sbs.be wrote:
>
> Hi everybody!
>
> It is probably to late to propose enhancement for 2.3 but maybe for the next
> one.
>
> Here's my problem. A program I am working on makes use of huge sequences. Some
> of them - the biggest ones - are just used temporarily. So I thought naively
> that when the routine was done extracting useful data from thoses big
> sequences
> it would suffice to make 'huge = {}' to free up memory. But nope.
>
> It seems that once memory has been dynamically assigned to sequences there is
> no
> way to free it until the program is done. Am i right?
It would be good if garbage collection did this, but it won't. Rumor has it that
windoze won't free up used memory until the program has quit and exited. In
dos, it's up to you.
> - If no, can someone tell how this can be done? Re-using the same sequence
> could
> be a solution but this strategy might be very tricky to implement depending on
> the program logic
Some people, like me even, use object junk for temporary stroage, and keep
reusing it. Or tempwhatever1 and tempwhatever2.
If you are using dos Eu, you can prolly use the EMS api to grab blocks of
memory and do as you wish. Since EMS pages up to 64K of memory at a
time above one meg, you can access all your ram easily, and this should not
interfere with whatever Eu is doing up there. Keep in mind, *you* must tell
the api to free those pages before you exit the program.
If you don't mind a really big hit on performance, you could use a ramdrive
and the i/o routines to access the variable.
I wonder if we had threads, you could spawn a thread to handle the huge
sequence, and when done, kill the thread, and if windoze would reclaim the
memory? I'm sure you can do this now with a different program, as opposed
to a thread, by using dde or socks to do inter-process communication... have
the other process mangle the huge vars, passing little bits to the main
program for munging them.
Gee, this is like pascal back on dos3, trying to trick the OS to do something
it wasn't meant to do.
Kat
3. Re: About Eu garbage collection
Henri Goffin writes:
> Here's my problem. A program I am working on makes
> use of huge sequences. Some of them - the biggest ones -
> are just used temporarily. So I thought naively that when
> the routine was done extracting useful data from thoses
> big sequences it would suffice to make 'huge = {}' to
> free up memory. But nope.
How do you know that the space is not freed?
> It seems that once memory has been dynamically
> assigned to sequences there is no way to free
> it until the program is done. Am i right?
No.
The values (atoms or sequences) that are currently
assigned to variables in the program must (obviously) be retained.
Other values are freed. For instance,
when a routine returns, the space assigned to its private
variables is released. When any variable is assigned a new
value, the space used by the previous value is released.
When space is released it goes to the "heap"
where it can be used again by your program.
Memory is not returned to the *operating system*,
until your program terminates, so if you are
trying to measure memory usage with some system tool,
you will never see a decrease in the memory used
by your program. Giving memory back to the O/S
during execution of a program is expensive, complicated,
and can't always be done. The normal practice is to free
memory to a heap, where the same application can
use it again.
When you are dealing with huge sequences you may
also face the problem that there is not enough contiguous
space for your sequence. e.g. There might be 10 1Mb blocks
of memory available, but you need 1.5Mb.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
