Author Topic: smart pointers as a change to the driver for refcounting  (Read 3133 times)

Offline silenus

  • BFF
  • ***
  • Posts: 144
    • View Profile
smart pointers as a change to the driver for refcounting
« on: October 02, 2014, 11:36:13 AM »
Would it make sense to replace perhaps as a stop gap measure until garbage collection goes in all pointers array_t, object_t etc. with ref counting smart pointers and then removing the free_* calls from the driver. It would seem to me that this would simplify maintenance.

Offline FallenTree

  • BFF
  • ***
  • Posts: 476
    • View Profile
Re: smart pointers as a change to the driver for refcounting
« Reply #1 on: October 10, 2014, 12:56:29 PM »
What is the problem you are trying to solve here? replace refcounting with refcounting?

Offline silenus

  • BFF
  • ***
  • Posts: 144
    • View Profile
Re: smart pointers as a change to the driver for refcounting
« Reply #2 on: October 11, 2014, 10:00:48 AM »
I am trying to reduce the reliance on manual ref count bumping since shared pointers do it automatically. my impression is  that this can be error prone since it is easy to forget to bump the pointer up or down when you do a manual alloc or free. I still think the best solution might to be to try implementing a garbage collector still.

Offline Camlorn

  • Friend
  • **
  • Posts: 76
    • View Profile
Re: smart pointers as a change to the driver for refcounting
« Reply #3 on: October 12, 2014, 04:01:41 PM »
The only way to do this at all is C++.  My understanding is that the driver is C, so you don't get destructors.  The smart pointer trick only works with destructors.  It's possible that someone converted--I've not been following the new FluffOS development really at all.  There are some tricks with C's preprocessing facilities and helper libraries, but they only work on function-local allocations.
But garbage collectors are much harder.  Would it be worth it?  Maybe.  But refcounting with a cycle detector does almost the same thing and is much, much less work from a coding perspective.  It's not like the tiny performance hit is going to matter, either.  There's stuff with GCs allowing for heap defragmentation, but again that's not an issue.  Well, with the exception of lost souls, maybe.
But if your reference counting is "good enough", you put some style guidelines in place, etc, it's not so bad.  I mean, muds aren't doing it, only driver developers.
And finally, the biggest nail in GC implementations in my experience: lack of guarantees.  It's very nice to have a guaranteed destructor call in some cases.  While not so much an issue for LPC, not having this is a pain when using an FFI in a GC language.

Offline silenus

  • BFF
  • ***
  • Posts: 144
    • View Profile
Re: smart pointers as a change to the driver for refcounting
« Reply #4 on: October 13, 2014, 06:20:21 AM »
I think the new 3.0 alpha drivers now compile under C++- so other than some memory management issues it is possible to use shared pointers instead of manual ref count bumping.

I am actually kind of new at this so the only code I am familiar with other than lpc drivers are dynamic runtime languages like ruby. Ruby has a built in garbage collector and to me it seems that an lpc driver is in some ways quite similar to something like ruby internally. Both are OO running on top of an interpreter. I thought about garbage collection and it would seem that it shouldn't be too hard to implement. Mostly just navigating pointers from the root set(stack, objects and call outs) and marking things and periodicallly clearing out the memory with a stop the world collector. The actual different types of objects one would need to navigate is probably limited to objects,arrays,mappings. Fragementation is an issue but I think it is no worse than what exists now.

- but what is a cycle detector? I havent seen an example of this.




Offline Camlorn

  • Friend
  • **
  • Posts: 76
    • View Profile
Re: smart pointers as a change to the driver for refcounting
« Reply #5 on: October 13, 2014, 12:33:38 PM »
In all honesty, given modern computing power, I'm hard-pressed to think of a case wherein the tiny performance downside of refcounting matters.  I'm sure it can, but I don't see how stopping the world is any better-not unless it solves something specifically.
As for "easy to implement", well, if you think it's easy then you're a better computer scientist than I am.  Especially on top of an implementation that already exists.
A cycle detector is similar to the sweep step of a GC: it simply finds cycles.  If a holds a reference to b and b a reference to a, neither can die.  Python at least marks these specially and automatically frees them should they not have a destructor.  Now that I think about it, I'm not sure which is simpler-cycle detecter or a full GC.

Offline silenus

  • BFF
  • ***
  • Posts: 144
    • View Profile
Re: smart pointers as a change to the driver for refcounting
« Reply #6 on: October 13, 2014, 04:23:37 PM »
I think the main concern with the refcounting in the driver is it is known to leak memory even without the cycle issue.  I am not saying a gc is easy but i think it isn't that hard either. The algorithm for the simpler variants isn't too complex (especially mark and sweep). There is some additional overhead unless one reimplements the malloc free code one needs additional pointers and a free pointer list.

Ref counting seems simpler but I worry that the current manual bumping of pointer refs which occurs in many places in the code is both not particularly modular and error prone- hence I suggested using shared pointers instead and automating the ref bumping.

Offline Camlorn

  • Friend
  • **
  • Posts: 76
    • View Profile
Re: smart pointers as a change to the driver for refcounting
« Reply #7 on: October 13, 2014, 06:16:38 PM »
My point isn't so much that there's not better options-there are, especially if we're C++ now.
But is it worth it?  there are very, very large muds running on FluffOS without a problem, so I'm not sure I see the reason or justification for such an effort.  The only mud I know that would directly benefit is Lost Souls, but that's ldmud anyway.
As for GC, if you make the constraint that only one thread may construct or destruct an object at a time, you could easily do a gc_ptr that's used the same as shared_ptr except no worries about cycles.  I sorta brainstormed this earlier, and it's maybe a Saturday project.  So perhaps you're right, at least if someone wanted to retrofit.  I might do it for my own projects, which would have no problem with it-you could easily delegate freeing to a  background thread so that it doesn't lock the whole app, and I highly doubt that most apps spend their whole time creating new objects.

Offline quixadhal

  • BFF
  • ***
  • Posts: 618
    • View Profile
    • A Waste of Time
Re: smart pointers as a change to the driver for refcounting
« Reply #8 on: October 13, 2014, 10:30:25 PM »
There are already drop-in replacements for malloc/free (and thus for the underlying allocation that constructors/destructors use) which do garbage collection.  Why re-invent the wheel for the 400th time?  I believe FallenTree already tried adding GCMALLOC, at my suggestion.  The results were not overly spectacular... probably because of circular structures and possibly references that weren't "lost", but just stopped being used at some point.

At the end of the day, the only system that will every work well is doing reference counting by hand, and knowing when it's really safe to free something.  And yes, that leaves you open to programmer errors, but... it's an LPMUD.  How often does anyone NOT doing driver development, actually modify it?

Offline silenus

  • BFF
  • ***
  • Posts: 144
    • View Profile
Re: smart pointers as a change to the driver for refcounting
« Reply #9 on: October 14, 2014, 05:31:06 AM »
If you are referring to the boehm garbage collector, it is actually less than ideal since it has to guess which entities in the code are pointers. Boehm gc is thus known to leak memory. The main shortcoming of a garbage collector over a ref counting implementation is that memory isn't freed immediately when data stops being referenced and there may be a significant pause in a simple stop the world implementation.

The problem with ref counting is it is imperfect for something like a mud since one can get circular reference garbage. Also it is error prone since I seem to recall Wodan some years ago indicating that fluffos leaks ram and was unable to track the cause. So the problem is that there might be errors in the existing code.

Offline Camlorn

  • Friend
  • **
  • Posts: 76
    • View Profile
Re: smart pointers as a change to the driver for refcounting
« Reply #10 on: October 14, 2014, 09:34:46 AM »
I'm going to have to agree with Quixadhal.
If this was a new project written in a modern programming style, I could see it.  There's a lot of software design things we do now that weren't done 20 years ago.  Most notably to this case, the idea that globals are bad.  Modularity has also become a big thing, which--again--wasn't considered so important when LPC was originally invented.
The Boehm collector is not perfect.  I see people go "O, yay, Boehm!  My problems are over!"  But that's not true.  It's accurate, but not 100% accurate.  Especially if you're holding on to global pointers everywhere, even if you're not using them.  The Boehm collector makes an interesting way to find leaks and might serve well as a good underlying memory manager, but it's not freeing you from this concern.
Refcounting with cycle detection is a garbage collector.  Nothing says that garbage collectors cna't give you guarantees about object destruction.  The Boehm collector doesn't-you can't clean up stuff when Boehm says something should die.  Refcounting should also be able to reduce the pause-the-world collections, too.  I'm not sure why more languages don't use it as a primary technique, given that it spreads the cost out a lot.
But what's being suggested here is to take a system that works and make it work.  it already works, so why bother?  Most muds can stay up for a week or more without reboot, a fact which isn't' true of a lot of user-facing software these days.  If you want to learn about GC, I'd suggest writing your own language-retrofitting into LPC isn't really needed, nor is it simple.

Offline cratylus

  • Your favorite and best
  • Administrator
  • ***
  • Posts: 1020
  • Cratylus@Dead Souls <ds> np
    • View Profile
    • About Cratylus
Re: smart pointers as a change to the driver for refcounting
« Reply #11 on: October 14, 2014, 01:16:40 PM »
But what's being suggested here is to take a system that works and make it work. 

i liek me sum camlorn

Offline silenus

  • BFF
  • ***
  • Posts: 144
    • View Profile
Re: smart pointers as a change to the driver for refcounting
« Reply #12 on: October 14, 2014, 10:21:12 PM »
I think writing one's own language from the ground up is even more work than doing a retrofit. I believe it took Dworkin around two years to get a ground up rewrite of a driver working. I still think the complexity is being overestimated. It's not easy but I don't think it's that difficult either. Adding something like boehm gc is trivial. I think I did the same thing out of interest at one point many years ago- but given how boehm gc works you cannot guarantee unlike a custom gc that all the ram is freed properly. I dont think it much matters either since if the code doesnt work no one needs to use it. I suspect however it would make making other changes to the driver easier if one did modernize the driver some and since the driver has moved to C++ I think it would make some sense to exploit some of the features. One of the hurdles here is that the global memory management of the fluffos driver via C malloc macros makes it difficult to use the C++ style new and delete operators.

I think using classes and stl would vastly simplify a lot of the code. Perhaps it might be better if I did this with ldmud since it's a bit cleaner but I am more familiar with the mudos/fluffos line.

Offline quixadhal

  • BFF
  • ***
  • Posts: 618
    • View Profile
    • A Waste of Time
Re: smart pointers as a change to the driver for refcounting
« Reply #13 on: October 15, 2014, 12:48:34 AM »
Let me put it this way.

Code: [Select]
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
1002      4674  1.3  0.6 124124 100856 ?       S    Sep05 763:42 /home/bloodlines/bin/driver /home/bloodlines/bin/mudos.cfg

Code: [Select]
             total       used       free     shared    buffers     cached
Mem:      16155636   15911016     244620          0     727224   14294332
-/+ buffers/cache:     889460   15266176
Swap:     47069180          0   47069180

My MUD, running FluffOS for 10 days, using up a whole 125MB of RAM out of the 16GB my machine has.
Why do I care about incredibly tiny amounts of memory being leaked again?

If I were running a game with a hundred players, and the MUD were not only sucking up 4GB of RAM but getting noticeably slower, maybe I'd care... but the fact is, I can't think of anything I could do that would make it matter.

Offline silenus

  • BFF
  • ***
  • Posts: 144
    • View Profile
Re: smart pointers as a change to the driver for refcounting
« Reply #14 on: October 15, 2014, 06:30:39 AM »
I guess it does call into question why some of the older memory optimizations are still needed. Perhaps the best solution rather than implementing something new like a gc would be to get rid of the older memory allocators and just use system alloc. STL isn't really compatible with them or the DXMALLOC macro. How many users do you have on at maximum?