Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #26940 > unrolled thread

Reclaiming Allocated Memory

Back to article view | Back to comp.lang.forth

Contents

  Reclaiming Allocated Memory Doug Hoffman <glidedog@gmail.com> - 2013-11-25 07:41 -0500
    Re: Reclaiming Allocated Memory Paul Rubin <no.email@nospam.invalid> - 2013-11-25 07:04 -0800
      Re: Reclaiming Allocated Memory albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-11-25 16:16 +0000
        Re: Reclaiming Allocated Memory Paul Rubin <no.email@nospam.invalid> - 2013-11-25 09:03 -0800
          Re: Reclaiming Allocated Memory Doug Hoffman <glidedog@gmail.com> - 2013-11-26 06:30 -0500
            Re: Reclaiming Allocated Memory AKK <akk@nospam.org> - 2013-11-26 13:07 +0100
      Re: Reclaiming Allocated Memory Doug Hoffman <glidedog@gmail.com> - 2013-11-26 05:11 -0500
    Re: Reclaiming Allocated Memory anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-04 16:46 +0000
      Re: Reclaiming Allocated Memory Doug Hoffman <glidedog@gmail.com> - 2013-12-05 06:43 -0500
        Re: Reclaiming Allocated Memory Paul Rubin <no.email@nospam.invalid> - 2013-12-05 06:30 -0800
          Re: Reclaiming Allocated Memory albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-12-05 14:37 +0000
            Re: Reclaiming Allocated Memory Paul Rubin <no.email@nospam.invalid> - 2013-12-05 07:21 -0800
          Re: Reclaiming Allocated Memory Doug Hoffman <glidedog@gmail.com> - 2013-12-06 04:57 -0500
            Re: Reclaiming Allocated Memory Paul Rubin <no.email@nospam.invalid> - 2013-12-06 07:38 -0800
              Re: Reclaiming Allocated Memory Doug Hoffman <glidedog@gmail.com> - 2013-12-07 06:14 -0500
        Re: Reclaiming Allocated Memory anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-05 18:14 +0000
          Re: Reclaiming Allocated Memory Doug Hoffman <glidedog@gmail.com> - 2013-12-06 04:58 -0500
            Re: Reclaiming Allocated Memory Bernd Paysan <bernd.paysan@gmx.de> - 2013-12-06 17:30 +0100
              Re: Reclaiming Allocated Memory Doug Hoffman <glidedog@gmail.com> - 2013-12-07 05:59 -0500
                Re: Reclaiming Allocated Memory anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-07 11:57 +0000
                  Re: Reclaiming Allocated Memory albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-12-07 17:48 +0000
                    Re: Reclaiming Allocated Memory Bernd Paysan <bernd.paysan@gmx.de> - 2013-12-07 19:15 +0100
                      Re: Reclaiming Allocated Memory anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-09 13:45 +0000
            Re: Reclaiming Allocated Memory anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-06 17:42 +0000

Page 2 of 2 — ← Prev page 1 [2]

#27174

In article <2013Dec7.125713@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Doug Hoffman <glidedog@gmail.com> writes:
>>On 12/6/13 11:30 AM, Bernd Paysan wrote:
>>> In a simple allocater like the one for region based memory, you can shrink
>>> all objects in place, and to grow them, you need to copy them to a new
>>> location, unless they are the last allocated object (in which case growing
>>> them is almost for free).
>>
>>That last point is a good one.  Thanks.
>
>Yes, if you RESIZE the last allocated thing, and the result fits in
>the current block, then it's cheap.  But with my current
>implementation, every other RESIZE, even if it shrinks, is expensive:
>I don't know the old size of the resized thing, so I always allocate
>new memory, and the amount of memory I copy there is usually bigger
>(possibly much bigger) than the old size.

How can you ever RESIZE if you don't know the old size of the resized
thing? You don't know how much to copy, I would say.

<SNIP>

>
>- anton

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#27176

Albert van der Horst wrote:
> How can you ever RESIZE if you don't know the old size of the resized
> thing? You don't know how much to copy, I would say.

Copy up to the size of the new object.

However, as usual, thinking out of the box helps to keep things simple in 
Forth.  When you have a resizable object, you usually have some whay to 
determine the size of the object by itself.  So you could tell a variant of 
RESIZE the previous size.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#27200

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Albert van der Horst wrote:
>> How can you ever RESIZE if you don't know the old size of the resized
>> thing? You don't know how much to copy, I would say.
>
>Copy up to the size of the new object.
>
>However, as usual, thinking out of the box helps to keep things simple in 
>Forth.  When you have a resizable object, you usually have some whay to 
>determine the size of the object by itself.  So you could tell a variant of 
>RESIZE the previous size.

Sure, if I can cahnge the interface, the lack of knowledge about the
old size is not a problem.  And with such an interface, one could
implement if based on ALLOCATE and FREE:

: RESIZE1 ( addr1 u1 u2 -- addr2 ior )
  allocate dup 0= if
    nip nip exit then
  drop swap >r 2dup r> move
  swap free ;

However, the only point for implementing RESIZE in my regions package
is to be able to use some libraries that were written for the standard
memory-allocation wordset; and for that wordset RESIZE has sthe stack
effect ( a-addr1 u -- a-addr2 ior ).

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

[toc] | [prev] | [next] | [standalone]

#27168

Doug Hoffman <glidedog@gmail.com> writes:
>On 12/5/13 1:14 PM, Anton Ertl wrote:
>> Doug Hoffman <glidedog@gmail.com> writes:
>
>> Unfortunately the use of such tools encourages
>> programmers to free everything at the end.
>
>Agreed.  Probably one should test and if that is a problem redesign so 
>more freeing is done sooner if possible.

If something can be freed earlier, yes it should be freed earlier.
But if it cannot, it should not be freed at the end of the process,

>e) RESIZE may not be not available without even more effort (extra 
>indirection?  manual copying of contents from old to new?).

Actually implementing RESIZE in my garbage collector should not be a
problem.  It's a bigger problem for the region-based allocator I am
working on and causes more program complexity than the rest combined.

However, does RESIZE fit with a GC?  I don't think so.  The point of
using a GC is that you don't need to keep track of how many things
point to an allocated place and where they are.  But if you use
RESIZE, you need to keep track of every address that points to your
RESIZEable thing; if you already do that, you can also use FREE for
that thing, and there is no point in using GC.

You can use ALLOCATE/RESIZE/FREE in the same program as my garbage
collector, so if you want to use RESIZE, my suggestion is to use it
with ALLOCATE and FREE, and use GC for things that do not resize.

Hmm, there would be one benefit from having RESIZE on garbage
collected memory: One could point from the resizable area to garbage
collected memory without declaring (and undeclaring) these pointers as
roots.  So maybe I will do it after all.

>> Which of these restrictions don't fit your programming style?
>
>a), b), and e) would be a problem for me.

a and b would require system-specific extensions, but all are
possible.  Maybe in a future revision.

>Yes.  Except a true region-based scheme has the advantage of fast 
>freeing compared to the above even after a large number of allocations, 
>if I understand correctly.

That's an implementation issue.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.forth

csiph-web