The best javascript engine ever — OZONE Asylum, home of the Mad Scientists

DHTML/Javascript

The best javascript engine ever

This page's ID: 28037

Edit Post

Who can edit a post?	The poster and administrators may edit a post. The poster can only edit it for a short while after the initial post.

Your User Name:
Your Password:
Login Options:	Remember Me On This Computer

Your Text: Insert Slimies » Insert UBB Code » Close Last Tag \| All Tags UBB Help	Ok, thanks for the pointers, but I have to understand it all, and maybe burst your bubble back about what happened to Scott some time ago :) 1) Why not a semi-compiled engine? I am taking flex and bison as "academic examples" and tools to support a js parser's development, but why not a Java-like engine? What in the js model prevents that exactly? I'd be tempted to say safety, among things, but I really, really don't see how a semi-compiler would differ from a Java JIT machine or ActionScript in the Shockwave Flash component: those things exist and they do work in browsers. Why would the system gc miss out on elements? In other words: [quote] Garbage collection is the problem. JavaScript is a garbage collected language. But the object model of the underlying host isn't necessarily controlled by the same garbage collector. [/quote] How does this impact the proper functionning of the garbage collector? >> in all likelyhood tied to a less than perfect garbage collection. I've posted many things in that thread, that apparently ended up unread, and I don't really have time to dig them up. The leaks he pointed out are classical, runtime leaks, memory that got out of control of the js interpreter, objects that simply "lost theyre referrer" but kept theyre memory space. From several accounts and docs on the internet, from several sources including youngpup, this is caused by circular references being "misprocessed", and this is a syntaxic limitation of many parsers and interpreters afaik, in terms of "recursive syntaxic rules". Basically, what happened in his code is that he created objects referring to objects reffering to... and the chain got "broke" at some point, if he deleted them "in the wrong order", leaving some objects unreferenced, and therefore, undeletable by the gc or anyone else for that matter. I even had a sample bison syntax which caused exactly this issue in my papers somewhere: by then creating circular references and deleting elements in the wrong order inside the code, you could get very similar behaviors to the ones being discussed. One fact about this: there are js practices that prevent these kinds of memory management issues. So the higher level syntax has a direct impact on those, regardless of the gc model or behavior. ...I certainly don't understand how what you said applies to the gc behavior and impacts it, but I understand the issue described by Scott is caused by circular object references, and I understand I saw the same thing occur in other parsing tools because of syntaxic limitations (which, of course, don't cause the leaks at parsing time, but "prepare" the objects to be incorrectly treated and deleted). Loading...
Options:	Enable Slimies Enable Linkwords

« Backwards — Onwards »

Show Forum Drop Down Menu