🚀 go-pugleaf

In article <243@brand.UUCP> barad@brand.UUCP (Herb Barad) writes:
>
>  I have been using BS II for a little while now.  I have run into a
>few problems.  When trying to perform a simulation, I get the fatal
>error:
>
>"ggcCopy: out of new space for context <aMethodContext>".  Interrupt
>or kill me.

This means that you have run off the end of one of your memory spaces.  I found
the default space lengths unmanageable.  I set NewLength to 350 and
OldLength to 1700.  I also set SurvivorLength to 350 as well to go with
NewLength.

>Another error that I has happend in similar situations is:
>
>"Overflow Remembered <aSemaphore>".  Interrupt of kill me.

This one is much, much harder.  There is a wired-in array called Remembered
which I found to be far too short.  It started out at 800 and I made it 10,000.
DON'T DO THIS BLINDLY!  IT WILL INVALIDATE ALL OLD IMAGES!  The array is
saved as part of the image and unless you write conversion software (I didn't
since I ran into it fairly early) you will have to start from scratch,
running "rot" on a Xerox image.

>Any hints on how to cure this?  Also, the System Tracer doesn't seem
>to work properly - anybody experience problems with it?

It doesn't work AT ALL.  It still thinks there's an OT.  There isn't.
The VMemWrite function can be duplicated in considerably less time
by running "Smalltalk reorganize" (seconds instead of hours), and a new
sources file can be built with "Smalltalk newSourceFile:without:" but
I have found no substitute for the class-winnowing feature.

>I plan to get access to Xerox's PS system.  How does this compare to
>BS II?  Will these problems go away?  Better garbage collection,
>virtual memory management, etc.????

I wish I knew what PS had inside it.  All I can say is that with an
assembler-coded VM, it is much faster, and it has had more man-hours poured
into it by far.  I would expect a cleaner, faster, supported product.
However, you give up the ability to dink with the VM.

>					Thanks for the help....

Glad to.  Let me know your experiences!  I have several bugfixes I can
tell you about...

>-- 
>
>Herb Barad	[USC - Signal and Image Processing Institute]


-- 
Mike O'Brien
The Rand Corporation

{sdcrdcf,decvax}!randvax!obrien
obrien@rand-unix.arpa

BS has a very interesting and elegant memory management scheme called
"generation scavenging" that is described in the May 84 issue of both
Software Engineering Notes and SIGPLAN Notices.  It uses several
different memory areas for garbage collection.  The sizes of these
areas can be changed by setting environment variables.  Unfortunately,
the default sizes are set too small.  Try setting the environment variable
SurvivorLength to 35.  That got rid of the errors here.

Ralph Johnson