www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - IDEA: invariant-related gc hints

reply Russell Lewis <webmaster villagersonline.com> writes:
Say that you create a new variable on the heap.  You fill it up with 
data, then cast it to invariant because you know that the contents will 
never change again.

That object might become garbage, of course, but you know that nothing 
it points to can possibly become garbage until the root object (the one 
that you cast to invariant) becomes garbage.

It seems to me that this information would be useful to the GC.  Just 
brainstorming here...but certainly, we could say, "until object X is 
garbage collected, objects A,B,C,D should all get marked 'live' in every 
GC sweep."

Moreover, the GC knows that all accessible data is also invariant, at 
least until the root reference goes away, so none of those objects need 
to be re-swept during a mark-and-sweep pass.

This sort of knowledge might really improve performance on programs that 
had a large set of invariant data.

Other ideas?
Jul 24 2008
next sibling parent BCS <ao pathlink.com> writes:
Reply to Russell,

 Say that you create a new variable on the heap.  You fill it up with
 data, then cast it to invariant because you know that the contents
 will never change again.
 
 That object might become garbage, of course, but you know that nothing
 it points to can possibly become garbage until the root object (the
 one that you cast to invariant) becomes garbage.
 
 It seems to me that this information would be useful to the GC.  Just
 brainstorming here...but certainly, we could say, "until object X is
 garbage collected, objects A,B,C,D should all get marked 'live' in
 every GC sweep."
 
 Moreover, the GC knows that all accessible data is also invariant, at
 least until the root reference goes away, so none of those objects
 need to be re-swept during a mark-and-sweep pass.
 
 This sort of knowledge might really improve performance on programs
 that had a large set of invariant data.
 
 Other ideas?
 

the easiest way to effect this might be to put all the allocations in the same memory section. If you know you wont drop anything, a sequential allocator (all memory allocations will be adjacent) might do the trick OTOH if the root becomes garbage but the rets is not you get a rather large block of garbage hanging around.
Jul 24 2008
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
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
Jul 24 2008
next sibling parent Marianne Gagnon <auria.mg gmail.com> writes:
 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.
 

I think that's a little stretched, enabling sections with less features is not how i imagine a clean and well-designed language
Jul 24 2008
prev sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:g6b4h3$1748$1 digitalmars.com...

 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.

Hmmmm. If only....... oh! wait, that's right. http://www.digitalmars.com/d/2.0/safed.html "When you enter SafeD, you leave your pointers, unchecked casts and unions at the door. Memory management is provided to you courtesy of Garbage Collection. Class objects are passed around using opaque handles. Arrays and strings are bound-checked (it's possible to turn the checks off with a compiler switch, but then you're no longer in SafeD). You may still write code that will throw a runtime exception (e.g., array out-of-bounds error, or uninitialized-class-object error), but you won't be able to overwrite memory that hasn't been allocated to you or that has already been recycled." The only issue then is slicing. Slicing still allows you to point into the middle of memory blocks, which slows down the GC. Unless, of course, a slice were to have three pointers -- one to the beginning of the memory block, one to the beginning of the slice, and one to the end of the slice. Ahhh, now it's all making sense why W wants to separate slices from normal arrays ;)
Jul 24 2008