In order to allow concatenation of strings to be efficient in both time and space, it must be possible for the result to share much of the data structure with its arguments. This implies that fully manual storage management (e.g. based on explicit malloc/free) is impractical. (It can be argued that this is true even with conventional string representations. Manual storage management typically results in much needless string copying.) Though an explicitly reference counted implementation can be built, we will assume automatic garbage collection.
https://www.cs.rit.edu/usr/local/pub/jeh/courses/QUARTERS/FP/Labs/CedarRope/rope-paper.pdf
#paper #string #strings #rope #gc #storage
Every time a new assignment or parameter passing is made, the reference count of the String has to be increased, this is an atomic lock, and is related to memory management, so it’s there whether you’re using simple reference-counting or copy-on-write.
Under a GC, no atomic lock is required, a simple reference (pointer) has to be copied. This is very efficient, locally, but the memory management costs are just deferred to a later garbage collection phase. Since immutable strings don’t have reference to other objects, the GC for them can theoretically happen in parallel without any drawbacks (assuming the GC supports it).
So under a GC, an immutable String type makes a whole lot of sense, as implementing a copy-on-write one requires a lot of effort, and a mutable one is problematic multi-threading wise.
https://www.delphitools.info/2013/05/13/immutable-strings-in-delphi/
#pascal #string #strings #immutable_string #delphi #gc #programming
Inappropriate deallocation of dynamic storage is a well-known source of catastrophic program failures. In the context of nonextensible applications, such as statically linked programs, this problem can (in theory) be mastered by a careful programmer; for extensible programs, it cannot! There is always the possibility that a module may be added to a program later on; such an extension can introduce additional references to objects of which the implementor of the core modules is unaware. Therefore, Oberon neither requires nor allows explicit deallocation of dynamic storage.
#oberon #gc #programming #programming_languages
The language, however, makes veryfew assumptions about the environment. If not available from a given operating system, dynamic module loading, command invocation, and automaticgarbage collection can be introduced by a small run-time system. In principle, it is possible to forego dynamic loading and to create traditional, staticallylinked applications, but this is anachronistic for the challenges of today’s software systems. Automatic garbage collection is indispensable for reliable,extensible software systems and is probably the biggest culture clash between Oberon and other compiled languages such as Pascal, C, or C++.
#oberon #gc #programming #programming_languages
is it a bad practice to call system.gc ?
http://stackoverflow.com/questions/2414105/why-is-it-a-bad-practice-to-call-system-gc
#java #gc #garbage-collector
