[racket] DrRacket never uses more than 1 GB?
Thanks Matthew. This was Racket 5.0. I swore "unlimited" was set in
DrRacket GUI. Maybe some bug where that was ignored? I'll check again
but meanwhile I reverted temporarily to PLT Scheme 4.2.5. Another git
bisect turned up a point where the behavior changed (before that I
wasn't running out of memory) and I'm trying to figure out why. After
I figure that out I'll pop the stack and go back to Racket 5.0 to
confirm what's happening with that.
> I don't think that's it. If you have a memory limit set, then there's a
> factor of 2 involved, but that doesn't apply when you don't have a
> memory limit.
That's not what I'm seeing so far.
Again this is all on Windows 7 64-bit, in case that matters. Since
Racket (and PLT Scheme) are 32-bit processes, 2 GB is the max they
*could* get.
But they never get 2 GB. Just 1 GB. On both PLT 4.2.5 and Racket 5.0,
when I set "unlimited" in the GUI I have never, ever seen the
DrXxx.exe process exceed 1 GB. It always tops out there and GC kicks
in. If GC can't free up much, it just gets stuck "flatlined" there at
1 GB, and eventually the Visual C++ runtime error occurs.
So:
[1] At some point my code started using much more memory. That's my
issue to figure out. Shouldn't need > 1 GB for this project.
[2] Even so, 1 GB seems to be a limit even if "unlimited" is set.
On Tue, Jul 13, 2010 at 7:35 AM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> At Mon, 12 Jul 2010 16:55:17 -0400, Greg Hendershott wrote:
>> Ah. If the GC needs 2X actual that would explain 2 GB --> 1 GB usable.
>> That's a shame but I understand.
>
> I don't think that's it. If you have a memory limit set, then there's a
> factor of 2 involved, but that doesn't apply when you don't have a
> memory limit.
>
>> Since I posted, my git bisect suggests it wasn't my code that changed,
>> instead there was some change from PLT 4 to Racket.
>
> For "Racket", do you mean version 5.0? If you mean later versions from
> git, I wonder whether commit 41d1daf53 from June 1 is relevant. (Commit
> 0e664e7c0 is needed along with 41d1daf53 under Windows.)
>
>