OZONE Asylum
Forums
DHTML/Javascript
The best javascript engine ever
This page's ID:
28037
Search
QuickChanges
Forums
FAQ
Archives
Register
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
Heh. Welcome to my world. To burst your bubble though:[ulist]*JavaScript syntax has a few similarities with C and Perl. One of these is that there is no way to build a JavaScript engine that separates lexical syntax scanning (the lexer/scanner/tokeniser part, depending on what litterature you're reading) from the grammatical syntax scanning (parsing, reduction, or a dozen or so other terms). JavaScript lexical syntax happens to be dependant on the grammatical syntax. As such, you cannot simply use tools such as bison and flex, because bison would need as it's working material the tokens returned from flex, but flex would need to get data from bison regarding what types of tokens are allowed in the current grammar context to give it further tokens. There's a saying in the Perl world: "Only perl can parse Perl". While not strictly true, I hope you can see how the impossibility of separating scanner and parser makes for a much more difficult task. JavaScript is much easier to deal with than Perl on this point though, but not entirely simple. *The parsing phase builds an AST from source code. This AST may (as in SpiderMonkey), or may not (as in JScript (1)), be translated into some type of byte code, depending on which engine you're looking at. Anyway, my point is that the parsing is over once the AST has been completed. The execution has yet to start, though. The memory leaks are not taking place in the parsing phase. They are not even taking place in the execution phase (2). These leaks you're talking about are located to the data, in all likelyhood tied to a less than perfect garbage collection. *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. Microsoft COM uses a reference counting garbage collection scheme, and as such fails to collect garbage cycles. Mozilla XPCOM is very similar (IIRC it's binary compatible), but has (recently added, in fact) a garbage cycle detector to eliminate the problem of garbage cycles. Gecko - in difference to Trident - has interfaces used to prevent garbage cycles in many cases very frequently used from script, such as the DOM. Trident's memory leaks could be addressed in a similar way. I don't have enough knowledge to say anything about how these things are dealt with in the WebKit and Presto rendering engines, but I can not that WebKit is rather leaky, while Presto is the least leaky engine of them all.[/ulist] In other words: The scripting engines are not the problem. The host object models are. If you want to see an execution time leak, i.e. a leak in an actual scripting engine, try the following in SpiderMonkey. [b]Warning: Will consume as close to 100% CPU as it can get and will eventually crash due to running out of memory, but may take a while doing so if you have a lot of RAM[/b][code]var a=[]; a.length=0xffffffff; a.push(0xffffffff,0x100000000);[/code] That's how one of those may look. I can't actually think of a memory leak in the parsing phase, but that doesn't mean there aren't any. 1. Not sure about this, but I haven't heard anything indicating it would use a byte code engine. Maybe I should ask Eric Lippert about it. 2. Execution time leakage is almost always accompanied by either - 100% activity and continually raising memory consumption - or with the application becoming unresponsive due to deadlocks. -- 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-06-2006 02:15)[/small]
Loading...
Options:
Enable Slimies
Enable Linkwords
« Backwards
—
Onwards »