>One thing I don't remember from the C4 papers is what overall percentage of CPU time is used by concurrent collection. I know they have a lot of ability to schedule the work in otherwise idle CPU cycles. But the battery piper eventually needs to be paid, so it would be interesting to know the overhead, both in CPU cycles and in cache misses.
One huge issue of the Azul one is they needed to modify linux because it makes a huge amouns of system calls ( i think thet are basically doing very small allocations and deallocations) and linux could not handle that , that amount of system calls must have a significant cost . Cache misses is interesting and worth knowing but is also a cost of non concurrent Gcs .. As far as CPU cycles imho your always better of loosing them and making pauses as small as possible. If the GC perf cost is say 5% sycnronizing it to be concurrent should not be higher than say 20% miore or 6 % ... I woould always spend 1% to reduce pauses by 60-70% on a quad core is an easy choice . To me the rust approch covers both type and memory safety and optional GC use .. If the GC pauseless technology matures it can handle it and the region based allocation will fall away yet you can write pauseless kernels and 3D engines today and use the extensive C libraries to get the ball rolling quickly.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
