[plt-scheme] Has there been an improvement in the GC and/or virtual memory manager since v369.100?

I couldn't think of anything. Looking back the SVN logs, though, I see
that I fixed a problem with the GC's handling of an internal stack when
marking unusually long chains of objects. That fix was on May 11 ---
after we changed the version number to 369.100, but before 370 --- so
it probably explains the difference that you see.

Matthew

At Thu, 14 Jun 2007 00:43:49 +0000 (UTC), Kyle Smith wrote:
> Today I was running a benchmark on several functions, which I had run before in
> v369.100, and I noticed a distinct difference in be the behavior of these
> functions as they were given ever larger lists at the end of the run, when they
> are given lists that previously would have caused at least one of them to
> exhaust the available memory.  On the final run they are given lists which
> contain on the order of 156,000,000 symbol?'s. I'm not sure how much memory is
> required to store a quoted unbound symbol in a list.  But let's just you use a
> two 32bit words for each pair, as a minimum, for the pointers to the car and
> cdr.  That would be eight bytes, making the memory requirement for a single 
> list
> on the order of 1gb, and the function is required to construct a flattened copy
> of the argument list, which brings the total, conservatively, to something like
> 2gb's of memory required.  I'm running this benchmark on a Mac Pro with 4gb of
> physical memory, of which only a portion of the last gb is available for use by
> anything other than devices.  So, I'm not surprised that the program would 
> cause
> a heap allocation error.  
> 
> Whats surprising is that, instead of crashing as in v369.100, the run times
> explode beginning at list lengths (not to be confused with the number of
> elements in the list) of 1.8 million, and the hard drive is heard to be
> thrashing, where as I normally can't hear the drive at all.  The benchmark
> completed without a single error, but there was a distinctly non-linear growth
> in run times between lists of length 1.8 to 2.0 million.  If there was a 
> change,
> it is a welcome one.  Just curious if I was seeing the benefit of an
> improvement, of if something else was up?
> 
> Thanks,
> 
> --kyle
> 
> _________________________________________________
>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme