User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.11) Gecko/20101012 Firefox/3.6.11 AutoPager/0.6.1.30 Build Identifier: How realistic is it to implement native code on disk caching, VX!32 style? Reproducible: Always

The native code tracemonkey (and JM, I think) generate has object addresses baked into the code. So not very realistic without significant changes. Pretty sure we have existing requests for this...

Sorry, I can't seem to locate any duplicates of this feature request. Please correct me if I'm wrong. (Is it standard protocol to mark bugs as DUPEME before duplicates are found?) Is it possible to annotate the native code with appropriate loading addresses, as a workaround? That would only require modifications to the linker, AFAIK. Though The object format would need some consideration.

"dupeme" is just an annotation that means "I think we have reports like this already, but don't have time now to find the duplicate". Don't read too much into it. ;) If I'd found a duplicate, I would have resolved this bug as duplicate. We've definitely had requests for this on irc and on the mailing lists; not sure whether any ended up as bugs. As modifying the code, the point is that at the moment there is no linker or object format for the jit. The compiler generates a very simple instruction stream, there's an assembler (and in the case of nanojit some optimization passes on what is effectively assembly), and that's it. While it's always possible to create a linker, relocation tables, etc, etc, at the moment there are no plans to do that, and it's not clear that this would necessarily be faster than just re-jitting.

My point is faster loading, not faster execution, though the longer time for optimization might help. Is it on the roadmap at least? Say, FF 4.5? Cheers.

I understand what your point is. I was commenting about speed of loading. Linkers are hard to do well (read: fast). And the whole point of the existing jits is that they're aiming to be fast on the compile time. So it's quite possible for the linker to end up slower than just rerunning the jit. This is not on the roadmap, that I know of. It'd be a lot of complexity for almost certainly not much gain.

(In reply to comment #3) > "dupeme" is just an annotation that means "I think we have reports like this > already, but don't have time now to find the duplicate". Bug 542144?

Sounds like either a dupe of bug 542144 or a WONTFIX.