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	[quote][b]_Mauro said:[/b] 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 existand they do work in browsers. Why would the system gc miss out on elements?[/quote]I'm not sure you really understand what you're talking about here, because you're conflating two separate things - executable program and data. Parsing generates an AST. The AST is either interpreted or compiled. If the AST is compiled to byte code, then the byte code is compiled (often JITted) into machine code at run time. An interpreter is generally lower performance, but reduces the time needed to go from source code to executing the program. A byte code engine is generally higher performance, but takes more time to go from source code to executing the program. There are JavaScript engines of both the interpreted and the byte code compiled kind. These types of memory leaks are present in either case. But a language engine has more parts than the executable program. The language engine must also hook up a host environment. And that's where almost all the memory leak problems in browsers appear. Memory leaks generally don't happen in the JavaScript engine controlled object space. That object space is governed by the JavaScript garbage collector, and that garbage collector is quite good at getting all circular references in all of the browser hosted JavaScript engines. But to do anything useful in the language you need to use the host environment, and here's where the problem comes in. Generally the browser host is coded in C/C++, Obj-C or Java and except for some Java browsers it is not governed by the same garbage collector. So, the language and it's executable program and it's internal object space is not the problem. The garbage collection mechanism of the host object space is the problem. Or rather, making sure that garbage collection works in both of the object spaces and can cross the object space border in both directions during a collection. Mozilla developers are working on a unified system to allow all the different garbage collectors to interact, allowing different garbage collection schemes to work by using a common interface. That way, SpiderMonkey can do it's arena garbage collection, XPCOM can do it's refcounting (Now with a with a cycle detector!), Python can use whatever garbage collection system that engine uses etc. and all the environments can detect cycles crossing the object space borders. Java browsers, .NET browsers etc. could chose to go the other way - they could chose to write the entire host to be governed by the same garbage collector. It would still not fix the problem with garbage collection when crossing the object space border (say into the Flash plugin), but it would drastically reduce the number of border crossings that must be done. But most browsers are not written for a one-GC-to-rule-them-all run time engine, are they? It's not the JavaScript engine the problem lies with. It's the host that needs to be fixed. [quote]/snip/ How does this impact the proper functionning of the garbage collector?[/quote]As explained above - because the garbage collectors need to be able to detect cycles when references cross into other object spaces, both cycles within that other object space and cycles crossing the border more than once. [quote]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".[/quote]This is what I think you're misunderstanding. The circular references have nothing at all to do with the parsing of the JavaScript and "recursive syntax rules". They aren't even located to the executable program resulting from the parsing of the source. They're all located in the data. And the failures to collect them are because the garbage collector sometimes fails to detect cycles when crossing object spaces or because one of the object spaces doesn't have any cycle detection at all. Microsoft COM is refcounted, and doesn't have a garbage cycle detector/dead object detector. Most C/C++ code in the browser hosts use manual memory management, and also here failure to detect cycles can happen. And crossing over into plugins or extensions, even if the object space on both sides is perfectly free of garbage cycles, can introduce memory leaks because the extension or plugin and the browser host fail to communicate across the border. [quote]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.[/quote] Yeah, but what does that have to do with the parsing? The parser doesn't know anything about objects, references etc. The parser shouldn't have to know, either. If a language doesn't have explicit memory management, and JavaScript is one of those languages, then memory management is the sole responsibility of the object spaces. And even in languages that have explicit memory management, the parser shouldn't have to care, because then the memory management is the responsibility of the executable program. [quote]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.[/quote]If you look at what those practices amount to, you'll see it boils down to a few rules: - Basic memory management by refcounting means that cycles will not be collected. Not at all. - That means an object may never be allowed to contain a reference to itself or any other object that contains a reference chain in which mentioned object can be found. - So, the solution is to either manually remove cycles (which you then need to keep track of manually whenever you introduce) - Or to use a non-cyclic approach, such as storing all reference in a global array and storing the index in the array instead of storing the actual reference. Those are workarounds in the executable program around deficiencies in the object spaces. To fix the problem, you need to fix the gargabe collection mechanism in those object spaces. The problem may still remain, however, if the garbage collectors don't communicate across object space borders, because even if they detect cycles internally, they will fail to detect cycles going through the other object spaces. [quote]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).[/quote]Well, the problem is really disconnected from the parser, that's what I'm saying. The parser is only responsible for turning source code into an AST that eventually becomes an executable program. Objects may, or may not, be created by that executable program, but that has nothing to do with turning source code into executable program. Object lifetimes are handled in the memory management system, whether that is manual allocation/deallocation, manual refcounting, automatic refcounting or some more advanced type of garbage collection scheme. And since the memory management of browsers is fragmented into several different object spaces each governed by separate garbage collectors, memory leaks appear if any of those object spaces fails either detecting cycles internally, or fails to communicate sufficiently with other garbage collectors. -- var Liorean = { abode: "[sigrotate][url]http://liorean.web-graphics.com/[/url]\|[url]http://codingforums.com/[/url]\|[url]http://web-graphics.com/[/url][/sigrotate]", profile: "[url]http://codingforums.com/member.php?u=5798[/url]"}; [small](Edited by [url=http://www.ozoneasylum.com/user/5032]liorean[/url] on 06-07-2006 17:45)[/small] Loading...
Options:	Enable Slimies Enable Linkwords

« Backwards — Onwards »

Show Forum Drop Down Menu