I'm also saying that while there are many types of GCs, the big dividing
line seems to be non-blocking versus blocking designs. Within blocking
designs, there are GCs that are better for one application or another, but
when the outcomes are examined it often turns out that some change in the
code generation strategy would eliminate the disparity. Often that change
help the application in any case. Not always, but often.
So what I'm saying here is that the cost of multiple GCs is low, but the
cost of multiple static compilation strategies is high.
I agree with these statement. That said Bitc will have multiple standard
libs
- you will need to support a kernel lib ( threaded ? , reentrant
?) . In my case processes have a single user thread why pay the price for a
concurrent lib ?
- You need to support libs for arm which may be a major market as
it is more c dependent and changing .
Also customers will create there own libs this is a compete and utter mess
in Unix (esp linux) which should have been sorted out years ago . 95% of
apps can make do with a VM ( where you can change the GC strategy) and the
pauses are irrelevant ( too small to matter) . I would strongly push
customers into this at it gives a much better experience with user written
libs.
That leaves a few apps , systems and device drivers . Here
there is nothing wrong with encouraging using simple smaller Mark and Sweep
to communicate to another critical or shared process using static
management. This is how things work now , sure a great pause less
concurrent GC with little penalty can make things smoother ( and simpler to
design) but its hard to build in practice (else they would be more common
in Java and C#). Even with this I doubt such a GC would beat clients using
a simple mark and sweep and a critical process doing static management . I
would probably place a VM (which supports ahead of time compilation) ahead
in the priority list once you have a gen GC with a Nursery ( which should be
available) . .
Yes. And all of the really clever schemes do a good job of optimizing away
the barriers in a whole lot of cases - as we will.
Every single one requires at least an if on each reverence .
I like your example very much. It's a wonderful illustration of a bad
problem with a pretty simple solution. It's therefore a great example of why
optimizers designed to compile non-GCd languages don't do a good job on GC'd
code, and why compilation strategies really matter a lot.
I see what your saying , you can communicate to the GC like don't pause
now , or fix this object but this communication needs to be synchronized
( ie an interlock on a variable) and what if you run lots of small loops (
eg contains on a collection of strings) each requiring such communication..
The compiler now needs to work out where to pause , then you can have the
issue of running out of memory and not being able to collect as the thread
is in pause so need a force policy etc . The real issue is your adding more
and more layers of complexity and for what ? 5 % of programs which do have
an alternative and kernels will most likely still be mainly static
management.
A performance difference of close to 100% even if the if is always false...
Umm. On modern multi-issue processors, assuming a decent compiler, I doubt
that very much, but there certainly is a cost, and it's certainly
significant.
With the code as written on x86 and no apparent dependencies , yes you are
right. On some ARMs it will cost 100% - assuming an x86 platform for a c
like language is not the best idea , the alternative platforms are growing
fast , have bad tools and little choice ie great market. in some GC
strategies the references will have a dependency eg fix this reference or
the region for this reference. Meaning super scalar is either dangerous
telling the GC it requires the reference after the work is done or requires
synchronization which again can be expensive for lots of little things.
Maybe I'm just not brave enough I like small steps and keeping it simple.
But I would have though if its easy there would be more Java or C#
concurrent collectors on the market , we can all read the papers . I would
pay for one in one project I worked as it saved doing static allocation.
In fact if you write such a collector im sure you can sell it to M$.
Ben
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
