JavaScript Speicherleck im IE

Wie vielleicht schon bekannt ist, leckt die JavaScript-Implementierung im Internet Explorer 6 Speicher (z.B. www.jibbering.com/faq/faq_notes/closures.html#clMem). Leider habe keine Hinweise darauf gefunden, ob das Problem im IE 7 behoben wurde oder nicht. Hat jemand dazu Sachdienliches?
Anm.: Sinn dieses Threads ist es nicht zu dokumentieren, dass der IE ein minderwertiges Produkt ist, sondern die Allgemeinheit auf Probleme mit dessen JS-Implementierung hinzuweisen. Weitere Dokumentierung von Lücken oder Schwächen sowie Häme bringen das Thema nicht weiter.

Hilft das support.microsoft.com/kb/830555? Dem nach wäre 7.0 nicht davon betroffen.

Irgendwie wäre mir eine Aussage, die nicht von Mircosoft kommt und nicht mit den offiziellen JS-Don'ts für IE (ohne jegliche Versionsangabe - msdn.microsoft.com/library/default.asp?url=/library/en-us/ietechcol/dnwebgen/ie_leak_patterns.asp) verknüpft ist, lieber...

Wir haben es nicht bis ins letzte Detail untersucht. Aber Leaks gibt es im IE7 immernoch. Und insbesondere im ursprünglichen Problembereich von DOM<->JS.
Allerdings hilft es eh' nicht viel, da man den IE6 ja durchaus noch berücksichtigen muss und der ja mit seiner Garbage Collection nun definitiv ein Problem hat.
Update: Ich habe gerade in unserem Code just einen solchen Leak gefixt, der innerhalb kürzester Zeit hunderte MB RAM im IE7 verschwinden lässt.
Hatte mit der üblichen DOMElement->Eventhandler->DOMElement-Kette zu tun. Also genau der Bug, den es in IE6 auch schon gab.

Dummerweise ist das kein Bug, sondern genau so erwartete Funktionalität.

Original von schokofreak
Dummerweise ist das kein Bug, sondern genau so erwartete Funktionalität.

Wenn Du eine zyklische Datenstruktur hast, und dann alle Referenzen von Aussen fallen läßt und der garbage collector dann nicht in der Lage ist, diese zyklische Datenstruktur abzuräumen, das wär genau die von Dir erwartete Funktionalität? Das bekomme ich auch in C++ ganz einfach hin, wo sollte dann noch der Vorteil eines garbage collectors liegen?

Original von schokofreak
Dummerweise ist das kein Bug, sondern genau so erwartete Funktionalität.

Also ich bin ja normalerweise kein MS-Basher, aaaaber:
- COM-Refcounting in eine garbage collected scripting language reinzuzerren
- die Objekte, die die JS/COM-Grenze crossen nicht sauber zu tracken
- dieses Problem über mehrere Versionen nicht in den Griff zu bekommen
und dann zu behaupten, das wäre "by design" ist
DOOF!
Ich habe DirectX seit 1.0 programmiert und kann daher nachvollziehen, dass die Jungs das Refcounting nicht so einfach loswerden, solange sie mit nativen COM-Objekten um sich werfen.
Müssten sie aber nicht, wenn einfach die ganzen DOM-Objekte ganz reguläre JS-Objects wären (auf die man z.B. auf prototypes usw setzen könnte), die wiederum den Interfacepointer halten. Aber ich schweife ab. Refcounting und Garbage Collection funktionieren einfach nicht zusammen, das ist eine Erkenntnis der frühen 70er Jahre IIRC. Sowas in einem Browser des Jahres 2006/7 zu machen ist einfach dämlich.
/rant off

Original von schokofreak
Dummerweise ist das kein Bug, sondern genau so erwartete Funktionalität.

Ich danke dem Schreibenden für seinen überaus hochwertigen und fundierten Beitrag zum Thema - auch wenn ich mich wie ein Blinder im Nebel fühle, wenn ich versuche, zu ergründen wie der Beitrag meine Eingangsfrage voran bringt.
Ich würde ja hoffen, dass ein Mod die letzten, wenig themaspezifischen Posts aus diesen Thread heraus schneidet, aber darauf zu hoffen ist vermutlich ebenso vergebens wie auf einen einsichtigen Admin, der schokofreaks Account zurücksetzt, damit der 14-jährige, an den dessen Passwort geleckt ist, nicht mehr in der Lage wäre, den Entwicklerbereich mit seiner Polemik zu nerven.
@semi-topic: Der EcmaScript-Standard sieht keine Garbage-Collection vor, richtig, aber wenn mir ein Browser, wie verbreitet, diese als Addon liefert, kann ich erwarten, dass dies auch den Anspruch einer GC erfüllt - und der Fehler wird durch Microsofts, was das Eingangsproblem war, lückenhafte Dokumentation nicht zum Feature.

Original von Todi42
Wenn Du eine zyklische Datenstruktur hast, und dann alle Referenzen von Aussen fallen läßt und der garbage collector dann nicht in der Lage ist, diese zyklische Datenstruktur abzuräumen, das wär genau die von Dir erwartete Funktionalität?

Das kann nicht mal die Mutter der GC Sprachen (java). Java 1.5 produziert dir, wenn du pech hast, genau das dass die Objekte sich gegenseitig am Leben erhalten - obwohl man sie von aussen niemals mehr adressieren kann.
Das ist auch absolut korrekt. Wer mit GC Arbeitet darf nicht einfach meinen es seie alles zum Wegwerfen und nicht mehr drum kümmern... gewisse Programmiergrundsätze gelten immer noch.
Deshalb: Es liegt in der Verantwortung des Entwicklers, solche sache sauber aufzuräumen.

Original von schokofreak

Original von Todi42
Wenn Du eine zyklische Datenstruktur hast, und dann alle Referenzen von Aussen fallen läßt und der garbage collector dann nicht in der Lage ist, diese zyklische Datenstruktur abzuräumen, das wär genau die von Dir erwartete Funktionalität?

Das kann nicht mal die Mutter der GC Sprachen (java). Java 1.5 produziert dir, wenn du pech hast, genau das dass die Objekte sich gegenseitig am Leben erhalten - obwohl man sie von aussen niemals mehr adressieren kann.
Das ist nur die halbe Wahrheit. Der GC in Java findet sehr wohl nicht mehr adressierbare Objektgruppen, da er von der Objekthierachie ausgehen kann. Sobald eine Gruppe von Objekten von deiner Anwendung nicht mehr referenziert wird wird sie vom GC erkannt, da sie nicht mehr in der Objekthierachie enthalten ist. Da können innerhalb dieser Gruppe soviele Querverbindungen sein wie du willst ...

> Java 1.5 produziert dir, wenn du pech hast, genau das dass die Objekte sich gegenseitig am Leben erhalten -
Nennt sich zyklische Referenz und wird von allen modernen GCs erkannt (Flash, Java, .Net)

Java - die Mutter der GC-Sprachen? Aha... Na da spricht ja jemand der so richtig Ahnung hat. Das Statement, dass Standard-GC keine Zyklen auflösen kann passt da sehr gut dazu.
Am besten mal Google nach Mark&Sweep oder Generational GC fragen. Ansonsten kann ich nur auf Dieter Nuhr verweisen...

Leute, schaltet mal bitte einen Gang zurück. Ich mag es gar nicht, wenn so ein angespannter Ton herrscht, ist nicht gut für den Blutdruck ;-)
Eigentlich schätze ich schokos Statements, denn trotz einer gewissen Dampfwalzenmentalität hat er eigentlich von vielen Dingen Ahnung. Und auf der anderen Seite der Schützengräben habe ich eigentlich auch den Eindruck, dass COrthbandt weiss, wovon er redet. Ich finde es schade, dass hier so viel Energie auf Gestichle verwendet wird, was gar nicht nötig ist.
Vielleicht könnt ihr ja in Zukunft bei gewagteren Aussagen eine Quelle hinzufügen (Google ist keine Quelle), statt einfach nur irgendwas zu behaupten ("Das gehört so! Jawoll!") und vielleicht erstmal diskutieren, worum es überhaupt geht (Serverfarm der Nasa vs. Browserspiel der Klasse D(urchschnitt)), bevor ihr euch gegenseitig den IQ eines Toastbrotes bescheinigt.
Die Firma dankt.
Anmerkung: Das war kein Versuch, hier den Mod zu spielen, sondern meine persönliche, ungefilterte und exklusive hier bei GN übertragene Meinung, weil mich das Gestreite nervt.

Leider funktioniert der GC in Java nicht so zuverlässig, wie es oft angepriesen wird.
Hab vor noch nicht mal sonderlich all zu langer Zeit wegen genau solch einem Problem eine Applikation stark redesignen müssen.
Zusätzlcih denke ich dass, selbst wenn das Java nun hinkriegen sollte... wo steht dass ein JavaScript das auch kann? Schliesslich ist es ja keine Java Virtual Machine, sondern eben nur ein Skriptinterpreter.
Nur da Garbage Collection geboten wird, heist das noch lange nicht dass es auch 100 % perfekt geboten werden muss... speziell von Leuten mit COM erfahrung erwart ich zu respektieren dass Software UND Frameworks nicht alles aushalten müssen - sie müssen es nur konsistent, reproduzierbar und logisch erklärbar tun.