On Thu, 2003-07-31 at 22:24, Clint Jeffery wrote:
> When one runs out of memory, bad things happen. And Icon and Unicon are
> not especially focused on minimizing their in-memory requirements. Still,
> there may be things we can improve, such as reducing heap fragmentation,
> that may improve performance or allow programs to run on larger data sizes.
>
> While the standard way to bump the BLKSIZE (and/or STRSIZE) up is via
> environment variables, and this works fine, it is always reasonable to ask
> whether the automatic behavior can be improved. We may want to increase the
> starting/default BLKSIZE, or better yet, since different systems have way
> different memory sizes, we need to make the default proportional of the system
> physical memory size -- does anyone know a portable call to obtain that?
This makes sense, but I think I would still characterize the behavior
of the sample program as illustrating a bug in Icon's runtime system:
(1) The documentation refers to BLKSIZE as setting the initial size
of the heap, implying that the heap will grow from that size as
needed.
(2) This is indeed the case, as using 'every 1 to 1' in place of
'every 1 to 2' in the sample program shows - in the former case
the heap grows quite nicely and the program continues to run.
For example, here are some region statistics well into the
'every 1 to 1' case:
First 2500000 are OK.
static : 0/0
string : 0/500000
block : 665327708/1023500000
(still no error at this point, incidently, though the program is now
running slowly because of swapping).
(3) When using 'every 1 to 2', the program dies with a heap that
is *much* smaller than the heap sizes reached by the 'every 1 to 1'
version - over *30 times* smaller, in fact! Clearly there is
is room here for the heap to grow. Here are the region statistics
just prior to the segmentation fault:
First 118000 are OK.
static : 0/0
string : 0/500000
block : 31479876/31500000
(Incidently, note that the heap has grown some by this point, it
started at 500000, grew to 1500000, 3500000, 7500000, 15500000 and
31500000).
Running out of room when there is room to grow the heap should
work just fine - the memory management should grow the heap and
continue (as it usually does). When this fails, it's a bug in
Icon's memory management.
Unlike the various stacks, which grow outside the Icon memory
management model, the heap is managed entirely *inside* Icon's
memory management - the *only* acceptable reason for a failure
relating to heap allocation is to exceed the total amount of
available memory (or reaching some agreed-to maximum, which
Icon/Unicon doesn't support while languages like Java do).
Furthermore, that failure should always be detectable by the
runtime system and reported with an error message, not a
segmentation fault.
Yes, increasing BLKSIZE *drastically* is a workaround in this case,
but I believe it's just that - a workaround for a bug in memory
management in Icon (the problem holds for Icon as well as Unicon).
Now, having made that claim, I recognize that it will take some
effort to find and fix this problem (I suspect it's been around
for a while - anyone got some really old versions of Icon to try
it on?), which means someone with a lot of time on their hands
would be needed to work on it. Until then, it'll stay a bug.
--
Steve Wampler -- [EMAIL PROTECTED]
Quantum materiae materietur marmota monax si marmota
monax materiam possit materiari?
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
Unicon-group mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/unicon-group
