"Cacti VS Llamas" - BCC #98

Worklogs "Cacti VS Llamas" - BCC #98 Kommentare

Donnerstag, 18. April 2019 um 11:01 Uhr von DAK

In Java (wie auch Python) sind weak references nicht nötig, da der GC nicht nur Referenzen zählt, sondern auch Zyklische Referenzen erkennt. In BMax wird ein Objekt erst dann freigegeben, wenn es keine Referenzen mehr darauf gibt. Das heißt, wenn man die letzte outside reference auf eine zyklische Referenz verliert hat man ein Memory Leak das man nicht mehr recovern kann.

In Java und Python wird ein Objekt freigegeben wenn es keine Verbindung von dem Objekt zum Global Space/Local Space/Stack mehr gibt. Das heißt, wenn man die letzte outside reference auf eine zyklische Referenz verliert, dann wird selbige Referenz vom GC gefressen.

Samstag, 13. April 2019 um 07:41 Uhr von DivineDominion

Was heißt "nicht gut" -- Mein Java ist ein bisschen eingerostet, aber da erinnere ich mich auch nicht an "unowned" und "weak references," da gab es auch nur die einfache Unterscheidung: ist Referenz da oder nicht. Das ist dann ja keine Idiotie vom GC, sondern einfach nur eine Beschränkung der Sprache Smile

Es gibt eine Wrapper-Klasse, WeakReference<T>: https://docs.oracle.com/javase...rence.html

Analog dazu den Bmax-Vorschlag: https://github.com/bmx-ng/brl.mod/issues/108

Worklog-Kommentare zu kommentieren ist leider maximal umständlich. Fände eine Diskussion in einem separaten Thread aber interessant

Freitag, 12. April 2019 um 12:47 Uhr von DAK

@Thunder:
Du hast natürlich recht. Es ist schon eine Weile her dass ich in BMax was gemacht hab, hab gedacht es gab ein manuelles Delete. Es ist hald schon blöd, wenn man einen GC hat, der einem das Memory Management abnehmen soll, das aber nicht gut tut...

Mittwoch, 10. April 2019 um 19:14 Uhr von Thunder

@DAK: bin mir nicht sicher, wie du dir das vorstellst. Manuelles Memory Management kannst du natürlich machen, aber wie soll das mit BlitzMax-Typen funktionieren? Mit malloc den memory für den Typen bereitstellen und dann hineinkopieren?

Wie soll die Delete-Methode das eigene Objekt löschen? Vielleicht gibt es ja eine Funktion vom GC die ich nicht kenne Very Happy

Jedenfalls müsste man aufpassen mit dem Namen "Delete". Die "Delete"-Methode wird nämlich vom BlitzMax GC aufgerufen, wenn er das Objekt freigibt. Das heißt mit manuellem Memory-Management kommt es ganz schnell zu double-frees. Es ist übrigens auch nicht garantiert, dass die "Delete"-Methode vom GC jemals aufgerufen wird. Habe das hier dokumentiert: https://www.blitzforum.de/foru...hp?t=39579
Ob das ganze auch für Bmax-NG zutrifft, kann ich nicht sagen.

Montag, 8. April 2019 um 19:21 Uhr von DivineDominion

Brucey, der bmax-ng pflegt, reagiert auf Probleme auf GitHub sehr schnell. Da scheinen noch Leute dran zu arbeiten. Leider haben die keine laufende Test-Suite, sodass viele Änderungen ungeahnte Konsequenzen haben könnten -- wie zum Beispiel mein Problem von neulich: " Abstract base type in different file with Field does not keep Field's value in concrete subclass from other file #417 " (https://github.com/bmx-ng/bcc/issues/417)

Hat sich herausgestellt, dass bmax-ng auch nicht mehr einfach Referenzen zählt. Dann wäre nämlich sehr einfach gewesen, "weak" zu implementieren, indem man bei solchen Referenzen eben den Zähler nicht erhöht. Das wäre eher analog zu Swift/Objective-C, wo retain/release aufgerufen wurden, damit der Garbage Collector weiß, wann er was löschen darf.

Klar, manuelles memory management würde das Problem umgehen. Dafür andere aufmachen. Wie immer Smile



Montag, 8. April 2019 um 10:44 Uhr von DAK

Mist, man kann Worklog-Kommentare nicht editieren... Also falls sich ein Mod bemüßigt fühlt die beiden Posts zu mergen, bitte gerne Wink

Um das Problem in BMax zu umgehen könnte man den ganzen GC auslassen. Dafür gibt man jedem Objekt eine Delete-Methode, die von allen referenzierten Objekten die Delete-Methode aufruft und dann sich selbst löscht. Braucht etwas mehr Hirn und ein explizites Aufrufen der Delete-Methode, aber dafür klappt es zuverlässig und man braucht sich nicht auf den mäßigen GC von BMax verlassen.

Montag, 8. April 2019 um 10:39 Uhr von DAK

Und wenn der BMax-GC zyklische Referenzen erkennen könnte (wie z.B. der Python-GC) dann hätte man das ganze Problem auch nicht. Dann bräuchte man nicht mal mehr sich darum kümmern müssen, welche Referenzen weak oder strong sind.

Freitag, 5. April 2019 um 21:32 Uhr von Eingeproggt

Der Beitrag zu weak references gefällt mir.
Führt mir schön vor Augen, dass die Uni-Zeit schon ein paar Jährchen zurück liegt... Aber man sich doch mit ein paar theoretischen Eigenschaften von Programmen beschäftigen muss, um sie "gut" zu machen.
Ehrlich gesagt könnte man fast den "Glauben" an Software-Entwicklung verlieren. Wenn ich überlege, wie viele "professionelle" und / oder kommerzielle Programme ich schon gesehen habe, in denen sich die Entwickler nicht um solche Details gekümmert haben...


Kommentar schreiben

Titel:
Text: