> Don't worryooRexx has a C++ version :-) Small requests end up in
> one pool to reduce fragmentation and also speed allocation time.
> Larger blocks of storage are segregated into a different memory pool
> that uses different allocation heuristics. But it's a tough balancing
> act trying to
t;>>
>>> Please respond to
>>> Open Object Rexx Developer Mailing List
>>
>>>
>>> To
>>>
>>> Open Object Rexx Developer Mailing List
>>
>>>
>>> cc
>>>
>>> Subject
>>>
>>> Re: [
>> To
>>
>> Open Object Rexx Developer Mailing List
>
>>
>> cc
>>
>> Subject
>>
>> Re: [Oorexx-devel] System resources exhausted
>>
>> It actually attempts to do that. I spent a fair amount of time this
>> weekend debugging
/2009 13:10
>
> Please respond to
> Open Object Rexx Developer Mailing List
>
> To
>
> Open Object Rexx Developer Mailing List
>
> cc
>
> Subject
>
> Re: [Oorexx-devel] System resources exhausted
>
> It actually attempts to do that. I spent a fair a
It actually attempts to do that. I spent a fair amount of time this
weekend debugging that code since I suspected there was something
preventing the mergers from happening. However, it turns out in
practice, to be a fairly rare event where requests end up being
adjacent to each other. On Windows
> The results were somewhat surprising. First of all, the performance
> was noticeably worse. The interpreter was essentially in a continuous
> state of garbage collection. AND, on top of that, it ran out of
> memory at 4.75Mb rather than 7.5Mb. I tried this using multipliers of
> 2x, 3x, 4x.
I was able to make some tweaks in the garbage collector over the
weekend and pushed the failure point up to the 7.5 Mb mark. Then,
this morning, I tried your suggestion of attempting to apply a
multiplier when I expanded the heap for a large allocation like this.
The results were somewhat surprisi
I don't know the details of the ooRexx memory manager, but I've seen
similar problems with others in the past.
One way that can help is to allocate new requests for large blocks at
the end of the last managed buffer, and small ones at the start of the
earliest available buffer, which will tend to
> > The problem is caused not so much by running out of memory, but rather
> > no longer being able to obtain a single contiguous piece of memory
> > from the system that can contain the new string result.
>
> You can watch the memory usage while the program is executing by
> watching the Performa
> The problem is caused not so much by running out of memory, but rather
> no longer being able to obtain a single contiguous piece of memory
> from the system that can contain the new string result. The
> explanation is somewhat long and involved, but the biggest problem is
> the need to continua
On Sat, Mar 28, 2009 at 9:41 AM, Rick McGuire wrote:
> The problem is caused not so much by running out of memory, but rather
> no longer being able to obtain a single contiguous piece of memory
> from the system that can contain the new string result.
You can watch the memory usage while the pr
The problem is caused not so much by running out of memory, but rather
no longer being able to obtain a single contiguous piece of memory
from the system that can contain the new string result. The
explanation is somewhat long and involved, but the biggest problem is
the need to continually expand
For about a year now, my (Windows, Vista) system has ground to a complete
stop for no apparent reason. A couple of months ago, I discovered that it
was when a background ooRexx program I have (that pulls down
weather-related data that I am collected) came across a 'large' movie file
(about 5 M
13 matches
Mail list logo
