reference counting

classic Classic list List threaded Threaded
9 messages Options
Jim
Reply | Threaded
Open this post in threaded view
|

reference counting

Jim
how about making it possible to manage certain objects
provided by C code by reference counting instead of
garbage collection when the programmer indicates so ?

Reply | Threaded
Open this post in threaded view
|

Re: reference counting

Sean Conner
It was thus said that the Great Jim once stated:
> how about making it possible to manage certain objects
> provided by C code by reference counting instead of
> garbage collection when the programmer indicates so ?

  What's wrong with __gc?  What problem is only solved with reference
counting?

  -spc

Reply | Threaded
Open this post in threaded view
|

Re: reference counting

Gé Weijers
In reply to this post by Jim
In a typed language this would be somewhat easier because you know which stack slots and array entries have to be visited to decrement the reference count, but in Lua this would introduce overhead in every function call, function return, every assignment, etc. etc. because you don't know where these reference counted object are referenced from. You end up paying for the overhead of reference counting AND for the overhead of the regular GC with its write barriers.

I believe it would be a better idea to introduce something like Python's context managers ('with' clause) or C#'s 'using' clause, which will notify your object when you leave the function it was created in, even if you exit the function via an error/exception. This would have far less overhead, and no overhead if you don't use it. (I know this has been discussed before).

(Another problem with reference counting is that the decrement-reference-count operation can cause a recursive deallocation cascade that may take an arbitrarily long time. You can perform a lazy form of reference counting, but then you may as well use the current GC).

On Sun, Apr 14, 2019 at 3:41 AM Jim <[hidden email]> wrote:
how about making it possible to manage certain objects
provided by C code by reference counting instead of
garbage collection when the programmer indicates so ?



--
--

Reply | Threaded
Open this post in threaded view
|

Re: reference counting

云风 Cloud Wu
In reply to this post by Jim
Jim <[hidden email]> 于2019年4月14日周日 下午6:41写道:
>
> how about making it possible to manage certain objects
> provided by C code by reference counting instead of
> garbage collection when the programmer indicates so ?
>


I'm working on a modified lua vm these days. It implements a
thread-safe mixed gc , which
mix a deferred reference counting and mark-sweep gc.

My goal is to share constant GCObject (such as TString and TProto)
with in multiple lua vm.
We can copy a GCObject to another lua vm by reference instead of deep-copy.

The main idea is :

1. Add a SHARED bit in marked of GCObject. When this bit is set, Its
life span is managed by a deferred reference counting system.
2. Shared GCObjects are always white, in the stage GCSpropagate, put
its pointer into a MARKED set instead of touching the marked bits.
3. in the stage GCScallfin , send this MARKED set to the GC thread ,
and GC thread will decease the reference counts of GCObject that is
not in this set but was in the vm.

--
http://blog.codingnow.com

Jim
Reply | Threaded
Open this post in threaded view
|

Re: reference counting

Jim
In reply to this post by Sean Conner
On 4/14/19, Sean Conner <[hidden email]> wrote:
> What's wrong with __gc ?

please read
http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/

some quotes from this article/blog post:

So here’s what Apple has to say about ARC vs GC, when pressed:

    At the top of your wishlist of things we could do for you is
bringing garbage collection to iOS. And that is exactly what we are
not going to do… Unfortunately garbage collection has a suboptimal
impact on performance. Garbage can build up in your applications and
increase the high water mark of your memory usage. And the collector
tends to kick in at undeterministic times which can lead to very high
CPU usage and stutters in the user experience. And that’s why GC has
not been acceptable to us on our mobile platforms. In comparison,
manual memory management with retain/release is harder to learn, and
quite frankly it’s a bit of a pain in the ass. But it produces better
and more predictable performance, and that’s why we have chosen it as
the basis of our memory management strategy. Because out there in the
real world, high performance and stutter-free user experiences are
what matters to our users.

In particular, when garbage collection has five times as much memory
as required, its runtime performance matches or slightly exceeds that
of explicit memory management. However, garbage collection’s
performance degrades substantially when it must use smaller heaps.
With three times as much memory, it runs 17% slower on average, and
with twice as much memory, it runs 70% slower. Garbage collection also
is more susceptible to paging when physical memory is scarce. In such
conditions, all of the garbage collectors we examine here suffer
order-of-magnitude performance penalties relative to explicit memory
management.

The ground truth is that in a memory constrained environment garbage
collection performance degrades exponentially.  If you write Python or
Ruby or JS that runs on desktop computers, it’s possible that your
entire experience is in the right hand of the chart, and you can go
your whole life without ever experiencing a slow garbage collector.

> What problem is only solved with reference counting ?

it releases resources ASAP, avoiding random stalls throughout script
execution and
thus provides a smoother runtime experience (games come to mind here).

there are algorithms that reduce these stalls
(incremental/generational garbage collection) but, given enough
objects, they will be noticeable again.

Reply | Threaded
Open this post in threaded view
|

Re: reference counting

云风 Cloud Wu


Jim <[hidden email]>于2019年4月16日 周二20:20写道:



> What problem is only solved with reference counting ?

it releases resources ASAP, avoiding random stalls throughout script
execution and
thus provides a smoother runtime experience (games come to mind here).

there are algorithms that reduce these stalls
(incremental/generational garbage collection) but, given enough
objects, they will be noticeable again.


Reference counting have stalls problem, too. And not always smoother than gc. For example, releasing a very long linked list.



--
Reply | Threaded
Open this post in threaded view
|

Re: reference counting

Gé Weijers
In reply to this post by Jim

On Tue, Apr 16, 2019 at 5:20 AM Jim <[hidden email]> wrote:
On 4/14/19, Sean Conner <[hidden email]> wrote:
> What's wrong with __gc ?

please read
http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/

Many of the points in that article are still valid, but mobile platforms are no longer as resource constrained as they were in 2013, and a well-designed GC may be faster than a reference counting implementation, especially one in a multithreaded environment. 

A thread safe reference counting implementations is not cheap:
C++ std:shared_ptr<> reference counting for instance introduces lots of overhead because the reference count is adjusted using thread safe (atomic) operations, and those operations are slow. I managed to double the speed of a single threaded program by writing a shared_ptr variant that was not thread safe (and yes, I used move construction and move assignment wherever feasible to avoid reference count adjustments).

When I added thread safety back into my implementation it became just as slow as std::shared_ptr<>.


-- 
--

Reply | Threaded
Open this post in threaded view
|

Re: reference counting

Coda Highland
In reply to this post by 云风 Cloud Wu


On Tue, Apr 16, 2019 at 12:05 PM 云风 Cloud Wu <[hidden email]> wrote:


Jim <[hidden email]>于2019年4月16日 周二20:20写道:



> What problem is only solved with reference counting ?

it releases resources ASAP, avoiding random stalls throughout script
execution and
thus provides a smoother runtime experience (games come to mind here).

there are algorithms that reduce these stalls
(incremental/generational garbage collection) but, given enough
objects, they will be noticeable again.


Reference counting have stalls problem, too. And not always smoother than gc. For example, releasing a very long linked list.

Reference counting also has issues with circularly-linked objects, which gc manages near-effortlessly.

As always, you must choose the right tool for the job.

/s/ Adam 
Jim
Reply | Threaded
Open this post in threaded view
|

Re: reference counting

Jim
On 4/16/19, Coda Highland <[hidden email]> wrote:
>> Reference counting have stalls problem, too. And not always smoother than
>> gc. For example, releasing a very long linked list.

yes, releasing lots of allocated objects at once could take
some time and hence stall the application.

> Reference counting also has issues with circularly-linked objects, which gc
> manages near-effortlessly.

yes, reference cycles are indeed problematic.

> As always, you must choose the right tool for the job.

yes, that's why it could benefit the programmer to be able
to use gc (by default) or reference counting (by indicating so)
in situations where this would be more appropriate.