On 03/08/2024 06:07 AM, David Brown wrote:
> On 08/03/2024 13:41, Paavo Helde wrote:
>> 07.03.2024 17:36 David Brown kirjutas:
>>>
>>> CPython does use garbage collection, as far as I know.
>>>
>>
>> AFAIK CPython uses reference counting, i.e. basically the same as C++
>> std::shared_ptr (except that it does not need to be thread-safe).
>
> Yes, that is my understanding too. (I could be wrong here, so don't
> rely on anything I write!) But the way it is used is still a type of
> garbage collection. When an object no longer has any "live" references,
> it is put in a list, and on the next GC it will get cleared up (and call
> the asynchronous destructor, __del__, for the object).
>
> A similar method is sometimes used in C++ for objects that are
> time-consuming to destruct. You have a "tidy up later" container that
> holds shared pointers. Each time you make a new object that will have
> asynchronous destruction, you use a shared_ptr for the access and put a
> copy of that pointer in the tidy-up container. A low priority
> background thread checks this list on occasion - any pointers with only
> one reference can be cleared up in the context of this separate thread.
>
>>
>> With reference counting one only knows how many pointers there are to
>> a given heap block, but not where they are, so heap compaction would
>> not be straightforward.
>>
>> Python also has zillions of extensions written in C or C++ (all of AI
>> related work for example), so having e.g. heap compaction of Python
>> objects only might not be worth of it.
>>
>

Wondering about mark-and-sweep or abstractly
whatever means that detects references, vis-a-vis,
reference counting and reference registration and
this kind of thing, sort of is for making the automatic
cleanup along the lines of stack-unwinding.

Like how C++ works on stack objects, ....

Then, that makes de-allocation part of the routine,
and adds reference-counts to objects, but it would
be pretty safe, ..., and the GC would never interrupt
the entire runtime.

One might figure that any time an lvalue is assigned
an rvalue, the rvalue's refcount increments and any
previous assigned revalue's refcount decrements,
then anything that goes out of scope it's rvalue
is assigned null, its un-assigned rvalue refcount decrements,
that any refcount decremented to zero results deletion.

Isn't that smart-pointers?

https://en.wikipedia.org/wiki/Smart_pointer

Maybe the big code cop should say "you should use smart pointers".

I think smart pointers should usually be the way of things,
any kind of pointer, then with, you know, detach() or what,
manual management.

I suppose it's nice that syntactic sugar just does that,
or, that the runtime makes a best effort sort of
inference, while, it would be nice if when an object's
purpose is fulfilled, that it can be canned and it results
freeing itself.

Static analysis and "safe programming"
is an option in any deterministic language, ...,
given "defined behavior" of the runtime, of course.

How about "ban USB and PXE" and
"proxy-defeating DNS", "read-only
runtime", "computer literacy suprise quiz".

The idea of memory pools and freelists and
arenas and slabs and dedicated allocations
for objects of types and the declaration at
definition-time of the expected lifetime and
ownership of objects, gets into a lot of ways
to have both efficiency and dedication by design.

Shadow stack, NX bit, shared register protection,
Orange Book, journaling, link-layer?

A usual behavior of Java crashing is leaving
the entire heap in a heap-dump file, ....

These days a usual sort of approach is, like,
the old "trust but verify", static analysis and
all, figuring that type-safety first is the greatest
possible boon to correctness, then that
memory-management would better be a
sort of "if you could just explicitly close your
resources when you're done then maybe
have a mark-and-sweep on the side, and
mark lifetime resources as so, then anything
left would be waste".

I'm a big fan of C/C++ coders and it's nice
to know about Java which I think is great
and I mostly think in it, vis-a-vis,
Go and JavaScript and similar event loops,
like Windows, or the Pythonic or something like
that, there's something to be said for that
Haskell is probably cooler than me, these
days I'm looking at the language specs and
the opcode instructions as from assembler
languages with regards to "modular modules
with well-defined modules and modularity".

Figuring "modular modules" and "scope the globals".