As an external observer with significant knowledge on what it takes to get there (we at Azul seem to currently be the only ones to have actually done it in a shipping commercial product), I would recommend an incremental approach. It is my understanding (based on offline discussion) that Go currently uses a conservative, non-relocating collector, so there is a lot of work yet to be done to support any form of long-running collector (which almost invariably means supporting a moving collector).

Starting with a precise and generational stop-the-world implementation that is robust is a must, and a good launching pad towards a concurrent compacting collector (which is what a "pauseless" collector must be in server-scale environments). Each of those qualities (precise, generational) slaps serious requirements on the execution environment and on the compilers (whether they are pre-compilers or JIT compilers doesn't matter): precise collectors require full identification of all references at code safepoints, and also require a robust safepoint mechanism. Code safepoints must be frequent (usually devolve to being at every method entry and loop back edge), and support in non-compiler-generated code (e.g. library and runtime code written in C/C++) usually involves some form of reference handle support around safepoints. Generational collectors require a write barrier (a ref-store barrier to be precise) with full coverage for any heap reference store operations (in compiler-generated code and in all runtime code).

It is my opinion that investing in the above capabilities early in the process (i.e. start now!) is critical. Environments that skip this step for too long and try to live with conservative GC in order to avoid putting in the required work for supporting precise collectors in the compilers and runtime and libraries find themselves heavily invested in compiler code that would need to be completely re-vapmed to move forward. Some (like Mono) get stuck there for many years, and end up with complicated things like mostly-precise-but-still-conservartive scanning that reduce the efficiency of generational collection and bump-pointer allocation. This usually happens because the investment in already existing compilers that do not provide precise information, and the lack of systemic and disciplined support for safepoints and write barriers in the runtime and non-generated code libraries become too big a thing to do a "from scratch overhaul" of. [write barrier support in generated code is usually a localized, near-trivial piece of work, it's the coverage of write barriers everywhere in non-genearated code that usually takes a long time, and has a long bug tail].

C4-like capability would add the need for a full-coverage read barrier (a ref-load barrier to be precise) for any heap reference load operations (in compiler-generated code and in all runtime code), so it would be good to keep that in mind as part of the overall effort.

-- Gil.

On Oct 11, 2012, at 9:36 AM, Ian Lance Taylor <ia...@google.com>
 wrote:

> On Thu, Oct 11, 2012 at 3:23 AM,  <2pau...@googlemail.com> wrote:
>>
>> Maybe this is a really blunt question, but could somebody pin a number on
>> the project, a dollar amount? With that information, the problem would be
>> significantly narrowed down to the level of a fundraising problem.
>
> I don't think there is any point to trying to raise funds without
> first identifying the people who would actually do it.  This is not a
> project that can be put out to bid.  The result has to be acceptable
> to the Go maintainers.
>
> Ian