[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: RE: User setting of GC Threshold
- From: "Bilyk, Alex" <ABilyk@...>
- Date: Tue, 25 Feb 2003 11:38:20 -0800
Good points. On the relating note I would like to assert again that line 443 in ldo.c saying
G(L)->GCthreshold += (G(L)->nblocks - old_blocks);
will lead to eventual consumption of ALL available computer memory under the right conditions regardless of the platform.
It had happened in one of our biggest commercial projects about a week prior to release date. It was easily fixed (by removing this line and afterwards by avoiding too much parsing) but it scared the hell out of just about everyone. I would not want to imagine what would have happened if this problem was discovered after our release. The problem is that under certain conditions the line above effectively disables GC.
AB
.
-----Original Message-----
From: Roberto Ierusalimschy [mailto:roberto@inf.puc-rio.br]
Sent: Tuesday, February 25, 2003 3:33 AM
To: Multiple recipients of list
Subject: Re: User setting of GC Threshold
> It seems rather limiting to me to just allow this one predefined
> auto-threshold. It would be more flexible to permit the user to define an
> automatic post-GC function which is called upon completion of GC with the
> current memory info, and which returns the new desired threshold.
1) Programming is rather limiting.
2) "The cheapest, fastest, and more reliable components of a system are
those that aren't there." Or, as Asko pointed out, "Every additional
feature also adds to the learning curve, documentation pages, etc.
etc.".
3) When we stop asking for new features, we have more time (and
motivation) to realize how to implement them.
(I leave this "automatic post-GC function" as an exercise. Hints:
* "automatic post-GC function" -> gc metamethod
* "current memory info" -> lua_getgcthreshold/count"
* "returns the new desired threshold" -> lua_setgcthreshold
)
-- Roberto