[Mono-gc-list] My arguments
13 Aug 2003 10:56:24 +0200
El mi=E9, 13 de 08 de 2003 a las 09:05, David Jeske escribi=F3:
At first, I must say sorry for my bad english, i think that this is one
of the reasons because of you don't understand me very well.
> I'm not familiar enough with exactly how libgc works to know whether
> this is the case or not, however, I'll take your word for it.
At the last version of Mono (0.25), lihgc is working with the metadata
of the objects as the libgc works with GJC (GNU Java Compiler). This is
and advantage because makes the collector less conservative and more
accuracy. In spite of the fact, libgc isn't a good collector for Mono,
because it can take advantage of the complete metadata that Mono
provides, it only uses a piece of metadata.
> My point was that most applications I've worked with in the last
> several years have problems with worst-case pause times long before
> they have problems with memory usage or throughput. Memory is cheap
> and CPUs are free, but pauses are often unacceptable. Obviously in
> some environments (embedded, handheld, etc) this isn't the case.
I agree with you at this. There are a lot of applications that they
can't be implemented with languages like Java, because the collector
need a long pauses to do the collect. It is a disadvantage for this
languages, and it would be a great idea to free Mono of this problem.
But i also think that it isn't a priority task, because the common
applications in Mono don't need this property. I think that we need to
make Mono better for the common cases, and not for special cases.
> We're in complete agreement here. Having a second collector
> implementation would be good just because it would encourage Mono to
> learn how to support multiple types of collectors. In this respect, I
> encourage you to write your copying collector, and help Mono figure
> out how to plug in other collectors.
I think that it is a great idea. Give to Mono developers the faculty of
choose among a variety of collectors in function of the application that
they are developing. It is the best alternative for a new collector for
Mono, but from my point of view it will be better to go step by step.
My initial question refers to a simply "stop-the-world" collector. In
your opinion, which would be better,a copying or a Mark-Compact=20
In theory, a copying one needs more space (the double than Mark-Compact)
and less time (only needs to travel through the heap once, instead of
Mark-Compact that needs to travel through at least twice) than a
Mark-Compact collector. But in practice, I have read that they are very
this site talks about a Mark-Sweep collector, but the complexity of
Mark-Compact it will be very similar to a Mark-Compact one).
Personally, i think that a Mark-Compact will be better because we can
made Mono more compatible with .NET (.NET uses a Mark-Compact collector)
in this subject.
> If anyone else is interested in doing a non-pausing collector, I'm
> game to collaborate.
I am working in a collector prototype, but i have just started. In my
initial pretensions there isn't a non-pausing collector, but it could be
a great idea, to add this functionality to the collector in the future.=20
All of my advances will be sent to the list, thus we can discusse about
it if you want. I hope this! :)
Fernando Diaz <firstname.lastname@example.org>