Re: libobjc2 & arc & multithreading

[David Chisnall]

Hi,

> On 27 Nov 2017, at 06:56, Andreas Fink <afink@list.fink.org> wrote:
> 
> Hello all,
> 
> I have a heavily multithreaded application which runs under MacOS X and 
> Linux. Under linux we use gnustep-base and libobjc2 (its a server app with no 
> GUI). The application is completely written with automatic reference counting 
> (ARC). Under heavy load under Linux we now noticed that we are very often 
> sitting in locks triggered by ARC releasing objects in memory it doesn't need 
> anymore. Usually my code is at a }  and libobjc2 waits on some global lock on 
> freeing objects while other threads sit on a init or alloc call or also on a 
> ARC release.
> 
> There is nothing generally wrong with this but the performance is impacted. 
> 99% of the objects which get released with ARC that way are being created in 
> the same thread which means no lock would be needed. Only when an object was 
> created or held by another thread, things should be done more carefully. I 
> believe this could speed things up a lot.

Thanks for the report.  Please can you open an issue on GitHub so that I don’t 
forget it?

It appears that this is related to the release of weak variables.  I haven’t 
tested the code with a heavily multithreaded environment, but it’s clear that 
this can be a bottleneck.

There are a couple of things I can imagine doing to improve this:

The first is simply to hash the object pointer value and have multiple weak 
reference tables, each with separate locks.  This would reduce contention.

The other thing that would probably make a bigger difference is to use a bit in 
the refcount to indicate whether an object has any weak references at all.  
This would allow us to completely avoid having the lock.  

Note that ‘no lock is needed’ is not correct, because we have no write barrier 
for a store of an object pointer to memory accessible by another thread (ObjC 
GC mode did have this, but it proved somewhat useless because almost all object 
pointers were stored to the heap at some point and so became potentially 
globally reachable).  

> There is obviously a few things in libobjc2 which need better maintenance.
> For example we always have to remove a debug log output related to a dtrace 
> release which otherwise would spam our stdout as its being constantly called.

Please open a GitHub issue.

> Is there anyone on this list who would like to join our efforts in this area 
> or has some feedback on this subject? We have not touched libobjc2 code part 
> until now but its essentially our performance bottleneck now.

I am the maintainer of libobjc2, so I am always interested in feedback (and 
patches). Most of my time on libobjc2 is currently being spent on a new ABI, 
which should remove a number of restrictions inherited from the GCC ABI, but 
that can proceed in parallel with improvements to ARC.

David