Javascript cache handling

[riadh chtara]

Hi guys
I was reading
https://developer.mozilla.org/en-US/docs/Nanojit
https://hacks.mozilla.org/2010/03/a-quick-note-on-javascript-engine-components/
https://developer.mozilla.org/en-US/docs/SpiderMonkey

and if I'm not wrong, I think that spiderMonkey compiles js file to bytecode when it executes it .
So I'm wondering if it's possible to change spiderMonkey so that it became possible for it to save the bytecode into a file (some kind of cache).
And then when it gets another file, it checks if it has already the bytecode for this file in cache, and if he does, he will open from cache the bytecode, and continues the execution of bytecode file. The running time will be shorter because the only remaining steps are conversion of bytecode to machine code and running that machine code.
I think if such feature is implemented to Firefox, its js performance will be better for website that the user visits the most.

So, Could you tell me please if that is possible?
And Do you think is good idea to add this feature?

[a.c...@weelya.com]

Hey,

You should look at the XDR API :


JS_EncodeScript()/JS_DecodeScript()

On Wed, 26 Sep 2012 09:25:43
-0700 (PDT), riadh chtara wrote:

> Hi guys
> I was reading
>

https://developer.mozilla.org/en-US/docs/Nanojit [1]
>
https://hacks.mozilla.org/2010/03/a-quick-note-on-javascript-engine-components/
[2]
> https://developer.mozilla.org/en-US/docs/SpiderMonkey [3]

>
>
and if I'm not wrong, I think that spiderMonkey compiles js file to
bytecode when it executes it .
> So I'm wondering if it's possible to
change spiderMonkey so that it became possible for it to save the
bytecode into a file (some kind of cache).
> And then when it gets
another file, it checks if it has already the bytecode for this file in
cache, and if he does, he will open from cache the bytecode, and
continues the execution of bytecode file. The running time will be
shorter because the only remaining steps are conversion of bytecode to
machine code and running that machine code.
> I think if such feature is
implemented to Firefox, its js performance will be better for website
that the user visits the most.
>
> So, Could you tell me please if that
is possible?
> And Do you think is good idea to add this feature?
>

_______________________________________________
> dev-tech-js-engine
mailing list
> dev-tech-...@lists.mozilla.org [4]
>
https://lists.mozilla.org/listinfo/dev-tech-js-engine [5]




Links:
------
[1] https://developer.mozilla.org/en-US/docs/Nanojit
[2]
https://hacks.mozilla.org/2010/03/a-quick-note-on-javascript-engine-components/
[3]
https://developer.mozilla.org/en-US/docs/SpiderMonkey
[4]
mailto:dev-tech-...@lists.mozilla.org
[5]
https://lists.mozilla.org/listinfo/dev-tech-js-engine

[riadh chtara]

Hi
Could you please tell me more about this api?
Do you thing it does woth be tried?

[riadh chtara]

Hi
Could you please tell me more about this api?
Do you thing it does woth be tried?

On Wednesday, September 26, 2012 7:25:10 PM UTC+2, a.c...@weelya.com wrote:

[a.c...@weelya.com]

It depends on which version of JSAPI you are using. IIRC, older
JSAPI version has JS_XDR* API which is now simplified using
Encode/DecodeScript (on mozilla-central).
Look at jsapi.h.
JS_EncodeScript returns a memory area containing the compiled script
(along with its size on 3rd output parameter) which I guess is platform
independant and can be safely stored.

extern JS_PUBLIC_API(void
*)
JS_EncodeScript(JSContext *cx, JSScript *script, uint32_t
*lengthp);

extern JS_PUBLIC_API(JSScript *)
JS_DecodeScript(JSContext
*cx, const void *data, uint32_t length,
JSPrincipals *principals,
JSPrincipals *originPrincipals);

On Wed, 26 Sep 2012 13:49:05 -0700

(PDT), riadh chtara wrote:

> Hi
> Could you please tell me more about
this api?
> Do you thing it does woth be tried?
>
> On Wednesday,
September 26, 2012 7:25:10 PM UTC+2, a.c...@weelya.com wrote:
>
>> Hey,
You should look at the XDR API : JS_EncodeScript()/JS_DecodeScript() On
Wed, 26 Sep 2012 09:25:43 -0700 (PDT), riadh chtara wrote:
>>
>>> Hi
guys
>>
>>> I was reading
>>

https://developer.mozilla.org/en-US/docs/Nanojit [1][1]
https://hacks.mozilla.org/2010/03/a-quick-note-on-javascript-engine-components/
[2][2] And then when it gets another file, it checks if it has already

the bytecode for this file in cache, and if he does, he will open from
cache the bytecode, and continues the execution of bytecode file. The
running
>>

>>> that machine code.
>> pe="cite"
style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px;
width:100%">I think if such feature is implemented to Firefox, its js

performance will be better for website that the user visits the most.

So, Could you tell me please if that is possible? is good idea to add
this
>> ckquote> _______________________________________________
dev-tech-js-engine mailing list
>>
>>> ">
>>
a.org">dev-tech-...@lists.mozilla.org [4] https://develo
>>
rg/en-US/docs/Nanojit [2]
https://hacks.mozilla.org/2010/03/a-quick-note-on-javascript-en
>>
>>>
zilla.org/en-US/do
>> ey [4] mailto:dev-tech-...@lists.mozilla.org
[3] [
>>
>>> h-js-engine

>
>
_______________________________________________
> dev-tech-js-engine
mailing list
> dev-tech-...@lists.mozilla.org [4]
>
https://lists.mozilla.org/listinfo/dev-tech-js-engine [5]




Links:
------
[1] https://developer.mozilla.org/en-US/docs/Nanojit
[2]
https://hacks.mozilla.org/2010/03/a-quick-note-on-javascript-engine-components/
[3]

mailto:dev-tech-...@lists.mozilla.org

[riadh chtara]

Thanks a lot for your help

[riadh chtara]

Thanks a lot for your help

On Wednesday, September 26, 2012 11:07:48 PM UTC+2, a.c...@weelya.com wrote:

[Dave Mandelin]

Someone tried to do this a couple years back, but didn't get it to work. In principle, it should be able to work. The browser is using XDR for JS that is part of the browser UI, and I'm pretty sure that does make startup faster.

For content, it gets harder because you have to actually know it's the same JS code, and you have to be able to deal with sharing parsed JS across different browser sessions. These should be solvable problems, but they could be a lot of work.

Dave

[riadh chtara]

Hi,
Boris Zbarsky told me in a private email that there is a bug about this
https://bugzilla.mozilla.org/show_bug.cgi?id=679942

It will be cool not to recompile browser UI js every time.
But I think that the same thing applies to other js file
Firefox has already a cache system, and when he opens websites, firefox is able to know if an element (js file called in html) is or not in the cache.
I think it's possible to use the same mechanism to know if a bytecode version of js file is in browser cache or not.
I think also it will be a good idea to save only byte code js file to cache(never save text js file).

It's possible to save html, css, xul in the cache in another format(not text, but a simple format that doesn't require parsing). And then when reopen them from cache, the browser will be faster.

I think also it's good idea to implement this also in b2g (if it works for firefox, i think it will work for b2g) because gaia is very big and it will a waste of time to recompile it every time the phone opens.

For the time needed, could you tell me please how much hours it will( of course approximately) to implement that (js only)?
Thank you

[Dave Mandelin]

On Thursday, September 27, 2012 12:31:54 PM UTC-7, riadh chtara wrote:
> For the time needed, could you tell me please how much hours it will( of course approximately) to implement that (js only)?

I'm not sure what scope of work you have in mind, but for 'get caching and sharing to work well across the browser' I'd say maybe 100-400 hours (which is a total guess) for someone who is already familiar with SpiderMonkey.

Dave

[Nicolas B. Pierron]

On 09/27/2012 12:31 PM, riadh chtara wrote:
> For the time needed, could you tell me please how much hours it will( of course approximately) to implement that (js only)?
> Thank you

tl;dr The most practical & useful information to save is likely to be the
monitored type information alone, and not the bytecode (not worth it) or the
assembly (not practical).

This depends what you want to achieve.

Saving the bytecode might be a challenge, the information stored in the
script and aside to it might be tricky to serialize and reload correctly.

Sadly, I don't think saving the bytecode alone is worth doing, the parser is
quite fast and the time spent reading the hard-drive for loading the
bytecode might be save by just calculating it again.

What would be interesting would be to restore the type information aside to
the sources. When a script is running, we are monitoring all the type that
we have seen across the lifetime of the script and this is used to guide
optimizations. This monitoring result is more valuable than the bytecode,
because this is the result of multiple runs and we cannot reproduce it as
fast as the bytecode. The tricky part would be to restore the TypeObject
correctly especially when the TypeObject origin is coming from another script.

I don't think it would be possible to save a compiled (to assembly) version
of the script until we get a baseline compiler which cannot be invalidated
because the way constraints � which are causing invalidations � are handled.
They are mostly registered by external data which means that another script
can hold a constraint which has a lifetime right on the compiled script.
This is a non local problem. So saving the compiled version might imply
saving everything. And this might be an order of magnitude bigger than the
plain sources.

--
Nicolas B. Pierron

[Boris Zbarsky]

On 9/27/12 10:20 PM, Nicolas B. Pierron wrote:
> tl;dr The most practical & useful information to save is likely to be
> the monitored type information alone, and not the bytecode (not worth
> it) or the assembly (not practical).

Hmm. I guess now that we do lazy compilation, you may well be right
about the bytecode not being worth it!

Saving TI information sounds _really_ interesting to me, though!

> I don't think it would be possible to save a compiled (to assembly)
> version of the script until we get a baseline compiler which cannot be
> invalidated

And also until we stop doing the baking-in of global object addresses we
do with compile-and-go, right?

-Boris

[riadh chtara]

I'm not familiar with spidermonkey. (but I worked on other mozilla project GAIA https://github.com/mozilla-b2g/gaia/graphs/contributors)
I'm sorry but I'm student and I don't have this amount of time.
Perhaps is possible to make it a study project (optimazation of cache by saving monitored type information), and then getting a tutor and 1 or two students to work with me on this project.
To do that, same of you need to answer my questions (but this not problem since your doing that now)
What do you thing?
>
>
> Dave

[Nicolas B. Pierron]

This is not much of a problem, because might be able to detect them and
substitute them by dummies using the same mechanism that the GC will use for
relocating.

--
Nicolas B. Pierron

[Dave Mandelin]

On Thursday, September 27, 2012 7:20:06 PM UTC-7, Nicolas B. Pierron wrote:
> Sadly, I don't think saving the bytecode alone is worth
> doing, the parser is quite fast and the time spent reading
> the hard-drive for loading the bytecode might be save by
> just calculating it again.

Do you have data on that? I haven't checked in a long time, so that could be true now, but AFAIK having the XDR'd scripts does make browser startup faster. I also thought that the large Emscripten demos had showed a nontrivial amount of time in parsing.

Dave

[Dave Mandelin]

> I'm sorry but I'm student and I don't have this amount of time.
>
> Perhaps is possible to make it a study project (optimazation of cache by saving monitored type information), and then getting a tutor and 1 or two students to work with me on this project.

I depends on your goals for a study project. But my first piece of advice is to start with fixing a few bugs or doing a few simple optimizations. After that you'll be better equipped to take on big things and have a better understanding of what's possible.

On the project idea of saving type profiles, before doing anything I strongly recommend doing some experiments to try to find out whether it can actually be beneficial. Otherwise you could end up doing a big project only to find out at the end that it can't be used. Another thing is to check with David Anderson on what's happening to the type profiles--there might be work going on soon that changes their format or meaning.

If you're interested in optimization projects, right now I think new optimizations for IonMonkey is a more promising area--it's more limited in scope, applies to more modern parts of the engine, and has the potential for reliable, direct performance improvements.

Dave

[Nicolas B. Pierron]

I don't have any data in mind at the moment, but I know the B2G team were
fighting against flash disk access back in June because the flash latency
plus sqlite database could add huge latency. And I heard multiple comments
from the performance team which discourage disk access in general.

So you probably want to avoid such latency for starting an application.
Notice that this is not much of an issue with monitored types because we can
still run on the interpreter while waiting for the type information to
show-up in another thread and stop the world for patching the type
information with the saved one.

Still, I agree, it would be better to spend time investigating the benefits
of each approach and give real figures before starting anything big. Sorry
for claiming such affirmed position. My feeling is that there is less
chances of failure by saving the monitored types.

--
Nicolas B. Pierron

[Nathan Froyd]

----- Original Message -----
> On 09/28/2012 01:06 PM, Dave Mandelin wrote:
> > Do you have data on that? I haven't checked in a long time, so that
> > could be true now, but AFAIK having the XDR'd scripts does make
> > browser startup faster. I also thought that the large Emscripten
> > demos had showed a nontrivial amount of time in parsing.
>
> I don't have any data in mind at the moment, but I know the B2G team
> were
> fighting against flash disk access back in June because the flash
> latency
> plus sqlite database could add huge latency. And I heard multiple
> comments
> from the performance team which discourage disk access in general.

I wasn't around when the XDR'd scripts bits were introduced, but I do know quite a bit has changed since then. There is an open bug for investigating whether XDR'd scripts are still beneficial to Firefox startup time, which I can't seem to find right now. It would be an useful thing to look at.

-Nathan

[riadh chtara]

Hi Guys,
I was a little bit busy today: I followed the SpiderMonkey building tutorial: it works like a charm. I read also same documentation about IonMonkey.
And now, I have to decide what kind of project I want to do before talking with one of my professor.
Like you said, there many ideas of optimization that could applied to SpiderMonkey and IonMonkey, so I thing it will be a good to start testing the most promising of this idea and figuring out which of these ideas worth to be implemented. (this will for the first semester, from 15/10 to 14/4 )
For the second semester, if everything go fine, it will possible in the second semester(15/4 to 14/10) to continue testing, or, trying to implement same of these idea
I will also have a grade about this project, so I need at the end of the semester to get results (finding out that an idea could optimize the js performance significantly would be great, finding out that an idea couldn't optimize the js performance significantly would no bad also, because it will avoid mozilla developer to loose time trying this idea, but I will in both cases need results)
I think also as the time is not that much, its a good idea to focus on the part with the most promising optimization (ionmonkey) for example.

Every semester is 4 months of real work, 6 hours a week (100 hours per students, I don't know how many students it would be, but I think there are many students who will be interested in this project, but I think the maximum allowed number will be 4 in this kind of project ) .


So could you tell be please, what do you thing about the project (spliting in two parts,(especially, the first part reserved for testing)?
Could you tell also please which part js engine would the best to try to optimize it in this amount of time? (You said Ionmonkey) and which kind of optimization it's we should try for this part?

Thanks a lot
Cheers
Riadh

[Steve Fink]

Personally, I think this is a great approach. Having hard numbers
showing the value of various optimizations (including both currently
implemented and potential ones) would be very valuable. For added value,
calculate what parameters would make the difference between something
being worthwhile or not -- for example, perhaps the XDR fastloading
makes sense on a desktop but not on a b2g device (or vice versa). If you
could boil that down to actual numbers (eg cache access takes X
milliseconds, recomputing takes Y milliseconds), that would be great.
Even better, if you made a framework for recomputing the thresholds that
didn't require too much source modification (so that it would be
resistant to future changes), we could use it on an ongoing basis to
check whether our curent optimizations still make sense, and on which
platforms, and perhaps which potential optimizations would have the most
bang for the buck.

I think the measurement task is much lower risk than actually
implementing the optimizations. Spidermonkey changes very rapidly,
invalidating patches, and it requires a lot of internal knowledge. (It
would be valuable to have that knowledge more widely known, but...) And
honestly, having solid measurements and a good exploration of the
ramifications could easily be more valuable than the optimizations
themselves.

Just my two cents.

[riadh chtara]

Hi Steve,

> Personally, I think this is a great approach.

Thank you

> Having hard numbers
>
> showing the value of various optimizations (including both currently
>
> implemented and potential ones) would be very valuable. For added value,
>
> calculate what parameters would make the difference between something
>
> being worthwhile or not -- for example, perhaps the XDR fastloading
>
> makes sense on a desktop but not on a b2g device (or vice versa). If you
>
> could boil that down to actual numbers (eg cache access takes X
>
> milliseconds, recomputing takes Y milliseconds), that would be great.



> Even better, if you made a framework for recomputing the thresholds that
>
> didn't require too much source modification (so that it would be
>
> resistant to future changes), we could use it on an ongoing basis to
>
> check whether our curent optimizations still make sense, and on which
>
> platforms, and perhaps which potential optimizations would have the most
>
> bang for the buck.
>

This is the kind of idea I'm looking for.

>
> I think the measurement task is much lower risk than actually
>
> implementing the optimizations. Spidermonkey changes very rapidly,
>
> invalidating patches, and it requires a lot of internal knowledge. (It
>
> would be valuable to have that knowledge more widely known, but...) And
>
> honestly, having solid measurements and a good exploration of the
>
> ramifications could easily be more valuable than the optimizations
>
> themselves.

You have a good point here : the project will take a lot of time, if we compare it to firefox(and spiderMonkey) development cycle. And if when the project finish, the discovered optimization are not compatible with the new version of spidermonkey, it will be just a waste of time.
Thanks a lot for your suggestion Steve

Has Anyone,please else other suggestion?

Cheers
Riadh

[Dave Mandelin]

A few optimizations I've been wondering about the effect of, roughly in order from easiest to check out to hardest:

- dead store elimination (sometimes called dead code elimination)
- constant branch elimination (also sometimes called dead code elimination, just to keep things confusing)
- loop unrolling
- SCCP (sparse conditional constant propagation; this subsumes constant branch elimination)
- object inlining (e.g. turning |new Point| into a couple of local variables; would require escape analysis)

You could also think about using SIMD instructions. I haven't thought about that at all yet, so I can't give you any specific pointers.

Dave

[Tom Schuster]

These ideas are great maybe you could list them on
https://github.com/Yoric/Mozilla-Student-Projects/ for inspiration of
others?

Thanks,
Tom

> _______________________________________________
> dev-tech-js-engine mailing list
> dev-tech-...@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-tech-js-engine

[riadh chtara]

Hi gays,
@Dave:
Thanks a lot for your great ideas (I maybe will need same details)
@Tom Schuster
I think that mozilla (and other opensource organisations) should gather and store such student project ideas in a website. This will not only give students a new opportunities and offer help to organisations. But a github repository is great as a beginning.

Thank you again
Cheers
Riadh

[Dave Mandelin]

On Tuesday, October 2, 2012 7:41:14 AM UTC-7, Tom Schuster wrote:
> These ideas are great maybe you could list them on
> https://github.com/Yoric/Mozilla-Student-Projects/ for inspiration of
> others?

That looks like an empty list right now. But David, if any of these ideas fit your concept and you want to list them there, feel free.

Dave

[Dave Mandelin]

On Tuesday, October 2, 2012 7:41:14 AM UTC-7, Tom Schuster wrote:

> These ideas are great maybe you could list them on
> https://github.com/Yoric/Mozilla-Student-Projects/ for inspiration of
> others?

[Tom Schuster]

Look at the "issues" https://github.com/Yoric/Mozilla-Student-Projects/issues.

[David Rajchenbach-Teller]

Actually, the whole point of this pseudo-project is its tracker:
https://github.com/Yoric/Mozilla-Student-Projects/issues

I have opened it so that anybody can enter their project ideas, without
having to go through me to curate them. So it would be great if you
could file your student project ideas.

Cheers,
David

--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla