[racket] DrRacket never uses more than 1 GB?

For one of problems Greg has reported in his earlier emails: that DrRacket  
can be crashed even when a memory limit is set, I've seen this as well, 
fairly  commonly on Windows XP and Vista with v4.x and now v5.0.
 
If it is of any use, I can consistently reproduce this on my XP netbook,  
with the following (toy) program using v5.0.
 
#lang scheme
 
(define (go [n 0] [foo '()])
(go (+ n 1) (cons (build-vector  1000000 (lambda (n) (make-string n #\a))) 
foo)))
 
(go)
 
 
I just click the "Run" button, and wait for bad things to happen... I first 
 get an error message stating "Racket Virtual Machine is out of memory.  
Aborting". Then I get a Microsoft Visual C++ Runtime Library dialog box  
indicating a runtime error, where the "application has requested the Runtime to  
terminate it in an unusual way". Finally, I get a dialog box reporting that  
"Racket GUI application has encountered a problem and needs to close.  We  
are sorry for the inconvenience.", and offering to send a report to  
Microsoft.
 
For sure, I can reproduce this when I have the memory limit set  to 1024 MB 
or 2048 MB. So far I have been able to reproduce this with the  memory 
limit set to >= 750 MB. At 512MB, the memory limit correctly kicks,  and I get a 
DrRacket error message, but DrRacket does not crash.
 
Curiously, when the memory limit is set to 700MB, I get a different error  
message. I don't get the dialog box about exceeding the memory limit; 
DrRacket  gives an "out of memory" error in the interactions panel, but does not  
crash.
 
I've just retested with the latest nightly build [Welcome to DrRacket,  
version 5.0.0.9--2010-07-14(d162667/a) [3m].] and gotten the same results.  
With the latest nightly build, I can reproduce the crash with a memory limit as 
 low as 650 MB. (At a memory limit of 600MB, the memory limit error dialog 
did  kick in, with no crash.)
 
My impression is that memory usage, as reported by the Windows Task  
Manager, is not even close to the memory limit at the time of the crash (e.g.  
<200MB, or even much smaller).
 
Jim
 
 
 
In a message dated 7/14/2010 5:23:06 P.M. Central Daylight Time,  
greghendershott at gmail.com writes:

Good  news, I found and fixed my memory over-consumption, albeit the hard  
way.

Some take-aways:

[1] I remain convinced that DrRacket won't  use > 1 GB for on Win64.
[2] It would be great to see DrRacket as a full  64 bit app on Windows
and Mac OS X someday.
[3] The intended use of  Limit Memory and its interaction with actual
memory available from the OS,  could use some better doc/explanation.
It will suggest you increase its  limit when you hit, but on the list
I'm learning that can backfire, and  anyway I've seen the limit ignored
... basically it's all pretty  confusing.
[4] More memory debugging tools would be helpful, as it's  non-trivial
to correlate Racket data to bytes (e.g. no C-style  sizeof).
[5] I learned that some of you seemingly don't use the  DrRacket
environment very much, yourselves? :)
[6] Speaking of DrRacket  and debugging, the debugger needs an option
to limit the display of large  items; otherwise DrRacket becomes very
unresponsive and stepping in the  debugger can take many, many seconds
between each step. Debugging = pain is  the wrong lesson to teach new
folks IMHO.
[7] Although DrRacket is  already a good "IDE", many people know stuff
like Eclipse and Visual  Studio, and this is a big part of the
experience of the "language" and  important for broader acceptance
(assuming that's a  priority?).

Sorry if that's a random brain-dump but I hope it may be  helpful. Also
I hope it's clear that if I didn't like Racket I wouldn't  bother
offering the feedback, so although this may not feel like  a
compliment, indirectly it is. :)

Cheers,
Greg

On Tue,  Jul 13, 2010 at 8:40 PM, Robby Findler
<robby at eecs.northwestern.edu>  wrote:
> On Tue, Jul 13, 2010 at 6:39 PM, Greg Hendershott
>  <greghendershott at gmail.com> wrote:
>> OK mister smartypants.  :)
>
> Indeed! :)
>
>> I set the limit back to 1024  MB.
>>
>> And ... it crashed again DrRacket  again.
>
> That limit is probably high enough to be ineffective as  an actual
> limit. I don't understand the precise connection between  what
> current-memory-use reports and what the OS says that a process  is
> using, but you want to use the numbers for the former, not the  latter.
>
>> Just like it did back when I decided to try  setting it to "unlimited"
>> in the first place, to avoid this  happening.
>>
>> Seriously, is the idea that users are  supposed to:
>> [1] Understand the maximum memory for their system.  (Which isn't
>> documented, but on Win64 is 2 GB ... unless it is  actually 1 GB.)
>> [2] Set the DrRacket memory limit to whatever  value they guessed in 
step 1.
>> [3] Watch DrRacket abend and lose  their work, anyway?
>>
>> I'm not trying to be a PITA, I  genuinely don't understand the intended 
usage.
>>
>> Also I  guess I'm frustrated that I have a memory utilization issue
>> which  is my own darn fault, but I have no clear mental model, yet,
>> what  the heck is happening and how to track it down. In which regard I
>>  suppose I feel like an Alan Perlis punch-line: A programmer who  knows
>> the value, and actually DOES want to understand the cost ...  but
>> can't. Like, if I have to ask the price, I can't afford it ...  ?
>
> ha!
>
> IMO, we are missing good memory  debugging tools, but this is a big
> project so likely you'll have to  stick with what we have so far.
>
> If you build with one of the  alternate collects (sgc?) you can get a
> fair amount of memory  debugging information. Its pretty low-level and
> there is no  visualization to help you understand, but if you are
> careful and think  hard about what it is telling you, you might be able
> to get some use  out of it.
>
>  Robby
>
_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20100715/6263b58c/attachment.html>