Re: [Bug-apl] Boehm garbage collector

[Blake McBride]

Dear Elias,

First, no generic GC for C can compact because it changes locations of objects, and pointers would be invalid.  The only way to fix that would be pointers to pointers, and that changes the entire system.

I am very interested in reducing clones.  That is extremely important IMO, especially given your observations.  My opinion is that we should ignore the cloning issue right now and focus on making the system as bug free and compliant as possible.  (I actually think we are not too far from that!)  Once that is done, the cloning issue should be high on the priority list.

I think the cloning issue can be addressed without introducing a new GC or necessarily modifying the current GC method.  It'll just have to be carefully handled during the cloning process.  

Also, I haven't really looked at the GNU APL source code but I hope Juergen's GC code has debug code to verify no leaks.  This would typically involve an #ifdef that causes the system to maintain a linked list of all active objects.  After X operations you can see what is still there.  This would be very slow debug code that would only be active when compiled in.

Thanks.

Blake

On Thu, May 29, 2014 at 11:19 AM, Elias Mårtenson <address@hidden> wrote:

Well, a good compacting garbage collector has definitely better performance than non-compacting reference counting. That said, the Boehm GC is not compacting and, as you stated yourself, it has to work within the confines of C++, so the difference is much less clear. It is in fact likely that you are right when it comes to that solution.

That said, it may be worth exploring. Maybe. The reason I started thinking about it in the first place was when trying to come up with a good scheme to get rid of the excessive cloning (I've observed this problem to slow down execution of a function by a thousand times). My previous forays into solving this has resulted in very fast execution, but with severe bugs. And of course, correctness is more important than performance so I had to go back to the drawing board.

Now, the solution to the cloning problem will likely involve similar analysis as a "GCification" of the code base. Thus, I felt that it would be interesting to at least mention it to spark a discussion around it.

Regards,

Elias

On 29 May 2014 23:38, Blake McBride <address@hidden> wrote:

Dear Elias,

I have experience with the Boehm collector and thought I would share some opinions.

1.  Since C/C++ was not designed with GC in mind, the Boehm collector is forced to take into account many very system specific factors.  These factors vary widely from system to system, and from system release to system release.  This means that, rather than portable code, you are maximally system dependent.  While that may be fine as long as the Boehm team continues to support their collector, all of your code will fall on its face the day they don't.  In other words, anything built with the Boehm collector will from then on be completely dependent on them.  The source code they provide, while complete, is pretty useless unless you understand all of the very system specific nuances of each system they support.  In other words, you can't support it yourself.

2.  A GC like Boehm would never be as fast as reference counting.  Reference counting, when possible, only does what it needs to do at the time it needs to do it.  A generic GC has to use up a specified amount of memory and then check everything.  I know generational GC's and concurrent GC's minimize some of this but it still takes time and their assumptions are rarely completely accurate so their function is reduced, i.e. _conservative_ collector.

The Boehm collector is a great solution when you want to add GC to a system after-the-fact, or if you are unwilling to do the hard work yourself.  It seems to me that Jurgen has already done the hard work in a portable way.  I'd prefer not to mess with it, nor pepper the system with Boehm ifdefs.

Just an opinion (from someone who has used the Boehm collector and has written my own collectors).

Thanks.

Blake

On Thu, May 29, 2014 at 9:24 AM, Elias Mårtenson <address@hidden> wrote:

I've been playing around with the Boehm (Böhm, I suppose) garbage collector, and it's pretty amazing. Jürgen, do you have any experience with it?

Updating the GNU APL code to (conditionally, with a compiler option) to support using the collector for at least Value objects should be fairly simple. This would provide several benefits:

• A performance improvement since there is no need to deal with the reference counter.
• Improved parallelism if one wants to expand threading beyond simply paralellising simple loops (no need to deal with race conditions when accessing the reference count)
• Provide a more solid ground when attempting to reduce excessive cloning (with the GC, once can simply share everything and clone before modification)

I was thinking of starting to implement this, but it would take more than a few hours which means that I first would like to hear your input on it before wasting my time.

Regards,

Elias