I agree fully, and that is why I haven't spent much time on the issue lately.
Also, now that I've been thinking about it some more, I realise that the issues would be identical regardless of GC or not. The problem is still how to share references to values, but still clone them when needed (but never when not needed). This problem is actually pretty much orthogonal to the GC. I'm still impressed by the Boehm GC, but it won't help us with the important issues that are being faced right now. As for learning the internals, I suggest you implement a native library. That will definitely make you understand how it fits together. Regards, Elias On 30 May 2014 00:50, "Blake McBride" <blake1...@gmail.com> wrote: > 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 <loke...@gmail.com> > 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 <blake1...@gmail.com> 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 <loke...@gmail.com> >>> 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 >>>> >>> >>> >> >
