[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-smalltalk] Some patches and comments for tcl-8.4.0

From: Paolo Bonzini
Subject: Re: [Help-smalltalk] Some patches and comments for tcl-8.4.0
Date: Tue, 22 Oct 2002 12:40:17 +0200
User-agent: Mutt/1.4i

> The following is what I use to build smalltalk-2.0.7 against tcl/tk 8.4.0.

Thanks, I'll apply it.

> Don't remember if it was that new const or other things wanting consts now,
> but some internal gst functions got const added to them.  I only did the
> minimal necessary to compile.  However, it probably would not be a bad idea
> to audit the code and put more around where appropriate.  Then again, I
> think const is strongly underused.

Yes, because it was K&R until 2.0 -- I am planning to use more const
qualifiers in the future.

> Finally, I don't understand why anyone would ever prototype static
> functions (except in the case where there is recursion across multiple
> functions).

Simple: you can then rearrange the functions in any order you like,
instead of having to perform a mental topological sort of the call graph

> In this case, I simply removed it.

No problem, I'll add it back :-)


ps: a short update on will-be-2.1 -- a new garbage collector is already in
place: the incremental non-generational variant already works (I have to
try it with Blox, but it passes the test suite and generates the manual
successfully), the generational variant is still untested but the code is
there (only a handful of lines since the non-generational variant is the
same as the generational one, but uses the whole old-space as the
remembered set instead of only the pages that were touched since the last
scavenging).  Performance of the non-generational GC vs. the old one is
encouraging.  The idea is based on VisualWorks (young generation uses a
copying collector, if the copied data exceeds a threshold tenuring is
activated -- currently I have a 360 K young generation with a threshold of
60 K; old generation uses mark&sweep collection with an allocator
resembling malloc with compaction triggered by growth of the space
reserved to old generation and manually by the user; the sweep phase is
incremental, while marking is -- at least for now, and unlike VW --
atomic).  Oh my god what a dense post scriptum. :-)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]