Ok, now I'm getting the expected out-of-memory error. Reworked a bit how
the live stack is managed and also added some predictive code to collection
class allocations to try to predict ahead of time how large the live stack
should be, which allows allocations error to (mostly) be handled as
here are my results ( slightly modified the script )
[enrico@enrico-mbp oorexx.tests]$./gc2.rx
grabbed10gb 21:40:58.682841
grabbed20gb 21:41:05.994087
grabbed30gb 21:41:13.765010
grabbed40gb 21:41:21.462267
grabbed50gb 21:41:29.247617
grabbed60gb
I’m guessing that we were getting eom failures earlier with the old code
so we never reached the point of getting a livestock allocation failure.
On Sun, Aug 26, 2018 at 1:23 PM Erich Steinböck
wrote:
> I wonder why this is popping up only now. Wouldn't we always have had a
> good chance that
I wonder why this is popping up only now. Wouldn't we always have had a
good chance that the liveStack needed expansion (because we now have more
active objects than before) when a terminal out-of-memory exception
triggered a GC? Why then did this work until now?
On Sun, Aug 26, 2018 at 7:00
Yes, I understand, but the root cause of this problem is a failure trying
to expand the liveStack during a garbage collection. The call to
reportException() at that time causes a recursive allocation failure,
resulting in the eventual out-of-stack condition. I suspect the only real
way to handle
The actual failure is stack overflow (due the the infinite recursion it
goes into)
Unhandled exception at 0x07FED88162FC (rexx.dll) in rexx.exe:
0xC0FD: Stack overflow (parameters: 0x0001,
0x000D3FC0).
Ah good, this confirms my suspicions about one of the things I need to fix.
It's actually amazing that this is the first time an issue has occurred
here in 25 years.
Rick
On Sun, Aug 26, 2018 at 9:40 AM Erich Steinböck
wrote:
> By reserving some memory in a program outside of the debugger
Ok, I was able to find the issue. With an object like a very big array that
holds lots of objects, it is necessary to expand the marking stack size
during the GC process. The failure was happening because this expansion was
failing. It looks like Windows terminated things because Windows itself
>
> devenv /debugexe rexx.exe myprog.rex
> And just start it running by hitting F5
>
This works for the typical script, but for me running above memory exhaust
script will almost consistently take down devenv itself. After trying
repeatedly, the debugger once showed an exception in
Start the process in the debugger first. There are events that don't always
show up as traps. Do this using
devenv /debugexe rexx.exe myprog.rex
And just start it running by hitting F5. It will break if there is some
sort of terminating event.
Rick
On Sun, Aug 26, 2018 at 8:07 AM Erich
>
> It still just runs to completion for me on Windows
>
Here's a version that should show the issue on any platform (it does for
me):
~~~
m = .Array~new(100)
chunk = 500e6
signal on syntax
-- grab memory chunks until almost exhausted
loop
m~append(.MutableBuffer~new(, chunk))
It still just runs to completion for me on Windows. If this is dying to for
you, run it in the debugger to see why it is terminating.
Rick
On Sun, Aug 26, 2018 at 6:05 AM Erich Steinböck
wrote:
> The issue is about what happens when the loop *doesn't* complete, not
> when it *does*.
> If
The issue is about what happens when the loop *doesn't* complete, not when
it *does*.
If you've got 16 GB free, just add `m = .MutableBuffer~new(, 15e9)` as the
first statement and then run the loop.
When it doesn't complete due to lack of memory, with the latest 64-bit
trunk on Windows 7,
13 matches
Mail list logo
