Mike,
You have unfortunately run into the single biggest flaw in all of
Smalltalk: Errors in the application that you are developing can cause
you to lose your IDE. Since all objects exist in one single image, you
can't really get around this, sorry to say.
Most Smalltalkers think this is a good thing, since it allows you to
change the IDE while it's running. But what if you don't want to change
the IDE? What if you'll never want to change the IDE, and you just want
to work on your application? Too bad. Single image.
What I typically do is NEVER save the image once I have run my
application.
I work in the following manner:
1) Run my application, making changes as I go.
2) When I'm done for the day, publish all packages to Store.
3) Quit the image without saving.
The next day:
4) Start the image
5) Load all packages from Store
6) Save the image
Then repeat from #1. This way, I am never saving my own
application-created objects. This system works for me, and I recommend
it.
Thomas Sattler
Morgan Stanley | Technology
750 Seventh Avenue, 14th Floor | New York, NY 10019
Phone: +1 212 762-1212
[hidden email]
> -----Original Message-----
> From:
[hidden email]
> [mailto:
[hidden email]] On Behalf Of Andres Valloud
> Sent: Wednesday, August 20, 2008 10:12 AM
> To:
[hidden email]
> Subject: Re: [vwnc] VW 7.6 startup crash
>
> Mike,
>
> Changing the values as you describe will not (barring any
> unforeseen interaction which I doubt very much) cause the
> mmScavenge.c crash. For example, I usually run my images
> with max memory at about 640mb, growth regime at about 512mb,
> and free memory at about 256mb. The VM won't crash because of that.
>
> Since you did not change the sizesAtStartup:, what would be
> left as far as I can see is one of two scenarios.
>
> a) For some reason the image creates too many objects before
> the memory policy is in effect, the VM is unable to scavenge
> new space and you get a crash. If that is the case, then
> adjusting the startup space headroom with the -h VM switch
> may help. Try something generous like 32
> bitShift: 20.
>
> b) The image was left in a state in which an attempt to start
> back up from a snapshot will cause an infinite recursion
> before things like the UI are up and running. If this is the
> case, then the -h switch will just increase the time it takes
> until you get the mmScavenge.c crash due to the VM not
> finding any more memory into which to tenure objects out of new space.
>
> Andres.
>
>
> Mike Bielser wrote:
> > On 20.08.2008 09:33, Valloud, Andres wrote:
> >
> >> Also, what memory policy parameters are you using? If you
> increased
> >> the size of new space, then that crash can occur if further
> >> adjustment of various headrooms in the memory policy are not done.
> >>
> >> Andres.
> >>
> >
> > Hi Andres
> > maybe I made a mistake? Here is what I did (after clicking the help
> > button in the dialog and reading the included help):
> > 1) doubled growth regime (from approx. 32MB to 64 MB)
> > 2) doubled free memory (from approx. 8MB to 16MB)
> >
> > I left memory at 512MB and figured my changes would be
> safe. Maybe I'm
> > wrong; I'm definitely NOT a VW memory expert.
> >
> > Mike
> >
> > P.S.
> > I'm trying to figure out what's going on, looks like this behavior
> > might be replicable and might be connected to
> > DLLCConnect/ExternalInterface
> >
> > _______________________________________________
> > vwnc mailing list
> >
[hidden email]
> >
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc> >
> >
>
> _______________________________________________
> vwnc mailing list
>
[hidden email]
>
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc>
--------------------------------------------------------
NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Locked
VW7.6-crash.jpg (27K)