I'd appreciate feedback from anyone here. There's no precedent in the standard library for using deferred reference counting at the Python level, so we're in some uncharted waters here. I don't think anyone would have been relying on whenthreading objects are deallocated, so that shouldn't be an issue. Are there other tradeoffs to using DRC that I'm not aware of?

Personal opinion: I think that we should not expose free threaded implementation to the Python level and end user. Fragmentation is only enough for C API.

cc@vstinner@colesbury

Personal opinion: I think that we should not expose free threaded implementation to the Python level and end user. Fragmentation is only enough for C API.

Reiterating my previous comment: I'm +0.1 for documenting it. I'll happily yield if others are strongly opposed.

I am -1 on documentation, we have bunch of private Python API that are related to C API but we don't expose it the Python documentation since we don't want people depends on it.

Personal opinion: I think that we should not expose free threaded implementation to the Python level and end user. Fragmentation is only enough for C API.

Same. I truly think we shouldn't be exposing anything that relies on our implementation of refcounting. It's causing a hard enough time for other implementations already. And even causes problems for ourselves when we try to optimize away refcounting.

I truly think we shouldn't be exposing anything that relies on our implementation of refcounting. It's causing a hard enough time for other implementations already.

In general, I agree. I've removed the documentation note from this PR.

That said, I do think it's important that we do expose and document some (unstable) APIs for working with the current reference counting implementation, because otherwise people will try to hack it together themselves. For example, Nanobindwas using silly hacks with immortalization before we exposed some better APIs for messing with reference counting. I think that'smuch more dangerous.

With this applied, I see similar performance to if lock was a local variable:

I don't understand well your benchmark. Can you show numbers before/after this change?

I don't understand well your benchmark. Can you show numbers before/after this change?

Updated the description. The benchmark is just trying to measure the amount of time spent accessing the object. See alsothe issue.

@Fidget-Spinner Out of curiosity can we just apply deferred refcount with tracing objects that have a possilbity of high concentration?
Then we don't have to modify objects in this way.

From my understanding, the issue with automatically applying DRC is that it only lets an object be deallocated during a garbage collection, which breaks code that relies on__del__ (or a weakref finalizer) being called when the object's reference count hits zero.

Maybe we could enable it for objects without__del__, and then disable it ifweakref.finalize is called on it?

@Fidget-Spinner Out of curiosity can we just apply deferred refcount with tracing objects that have a possilbity of high concentration? Then we don't have to modify objects in this way.

You mean like track objects that are frequently shared and apply it to those objects? It would be quite easy to implement, the only problem is like Peter said we can't defer finalizers of things that take up a huge amount of memory and rely on immediate reclamation.

If we can apply it to the conditional case, as Peter said, behavior change would not be an issue. OTAH, memory consumption also would not be an issue if we can provide a disable tracing option where the device has low memory. Most of the production machines have enough memory, so it would not be an issue, IIUC. (Please let me know if it will consume huuuuge memory)

Side note, the reason I am talking about tracing is that I am now starting to fear that we will attach the deferred ref API all over the codebase due to performance reasons. It would be chaos for us..

It's generally a one-line change to an object's initializer, why would that be chaos?

We could also shift the decision to the user and add a genericthreading.hot, which would enable deferred reference counting (or maybe immortalize non-GC types), but document it as "might do nothing" for forward compatibility. That would act as a safeguard against people constantly asking for deferred reference counting on their favorite objects.

It's generally a one-line change to an object's initializer, why would that be chaos?

No, you are now starting to measure microbenchmarks and then applying them. Can you guarantee that the case is limited?
I can bet that we will find more cases that is the high contention.
How about 3rd party projects? those projects should measure the high contention and then change the code?

A better solution would be that we don't have to care about such a case, and the interpreter applies it automatically. I am fine with just applying for this case, but let's discuss a better solution and think about what we can provide.

You can work around the scaling issues in the repro pretty easily by passing the lock as an argument toscale:

importthreadingimporttimelock=threading.Lock()defscale(lock):a=time.perf_counter()for_inrange(10000000):lock.locked()b=time.perf_counter()print(b-a,"s")threads= [threading.Thread(target=scale,args=(lock,))for_inrange(8)]forthreadinthreads:thread.start()

I think we should be very cautious about exposing implementation details like deferred reference counting.

I think we should be very cautious about exposing implementation details like deferred reference counting.

FWIW, I don't think we'reexposing it, per se. Things will "just work" from the user's perspective. I'd really rather the interpreter do it than force weird implementation details, like using locals.

Ok._thread is still a documented module--should it be private there too?

I don't really see the motivation for these particular classes. It seems unlikely to me that someone is checkinglock.locked() simultaneously from multiple threads without also acquiring and releasing the lock, which itself will be a bottleneck. Maybe this makes sense forthreading.Event()?

I agree with@mpage that we should be cautious about exposing implementation details. The motivation here doesn't seem sufficient enough to me to overcome that caution.

lock.locked() was just an example to measure the reference count contention and not the internalPyMutex contention.Event is fixed here already too. In practice, people will be doingwith lock or whatever, but that will still have the same refcount contention.

I agree with@mpage that we should be cautious about exposing implementation details. The motivation here doesn't seem sufficient enough to me to overcome that caution.

I don't think we're exposing any actual implementation details, right? The reference count is still hidden tothreading users.sys._defer_refcount is a different story, but I'm going to move that anyway.