IDEA: invariant-related gc hints

[bearophile]

Russell Lewis:
> Other ideas?

When Java was "born" for applets it was really slow, but years later it's has become almost as fast as normally compiled languages, for many purposes fast enough. One of the things that has allowed it to become this fast (beside lot of money, I presume) is a good enough GC (maybe not perfect yet, and not good for everything, but good enough for many purposes).

My knowledge of the detailed internals of a modern GC is limited still (it seems the more I learn the less I seem to know, this newsgroup is good for humility), but I have seen that they are quite refined and complex, and smart enough. From various benchmarks I have seen that the Phobos GC uses 2-12 times less RAM than the Java GC (often 5-8 times less), but I think the HotSpot GC often leads to faster performance of the code compared to the Phobos GC, sometimes much faster.

People have told that beside being (possibly) less refined and complex than the HotSpot GC, the Phobos one is designed for a lower level language, that allows unions and raw pointers too, etc. Such limitations of Java instead of making the Java code slower may instead allow the GC to work at a higher level, allowing faster code overall (here I am talking about heavy-OOP kind of code, of course).

So can't a way be invented to tell the D compiler that some parts of D code are restricted in Java-like capabilities (no C-style pointer management), so the GC can work on them (if they contain OOP) at that higher level with hopefully higher performance on very-OOP code (this may requires a quite more complex GC)? I don't know if this can be done, because you can't make such parts of code transitively safe. This is another possible advantage of the "safe D" Walter was talking about.

(Sorry for any silly thing I may have said).

Bye,
bearophile