Eli Barzilay wrote at 05/21/2011 12:05 AM:
Switching to 3m sounds like the main improvement. Did you check the memory
footprint? It can be especially bad with long-running server processes.
(Specifically, there are certain data patterns that get CGC to leak very fast.)
There was no perceptible leakage in earlier stress tests, and process
size has been reasonable. Perhaps because the app is
external-DBMS-centric, I think it doesn't do anything in in-core data
that I'd consider problematic for a GC, other than C interfacing. There
are large-ish acyclic lists with shared tails, and they seem to be
collected reliably.
Before we invested in moving to 3m at this point, we'd want some
intuition that it is likely a reliability improvement for us. For
example, if we had information that gave us lesser confidence in CGC's
*correctness*, other than the potential for leakage (which we can
observe that we don't experience), that would be a good reason to move
to 3m.
Similar with PLT 4.2.5 vs. Racket 5.x: if we had information that in
general the reliability of the code had improved, or that a nasty bug in
4.2.5 had been fixed, that would be a good reason to upgrade.
Without that information, I think there is overriding incentive for this
client to stick with known quantities for now. Later, they might have
resources to focus on the *non-reliability* reasons to upgrade.
(My *personal* work has already moved to Racket 5.x, of course.)
We have set up core dumps
A stack trace from such a dump can be very useful.
Yes, I emphasized this as a top priority. :) I was saddened to learn
that, not only do core dumps seem to be disabled by default nowadays (we
had to change 5 different things to get core reliably on their servers),
but that Google suggests few people would be able to get core like this
if they tried.
Thanks for the input, Eli.
--
http://www.neilvandyke.org/
_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/users
