813324 - Compiled JS cache for Firefox

Status: RESOLVED INCOMPLETE

(Core :: JavaScript Engine, defect)

Description

[riadh.chtara]

Attachment: patch file

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.19 (KHTML, like Gecko) Ubuntu/11.10 Chromium/18.0.1025.168 Chrome/18.0.1025.168 Safari/535.19

Steps to reproduce:

I wanted to find out if it's worth to implement a cache for spidermonkey: in normal case : spidermonkey compile script and then run it.
I want to change it, and save compiled JavaScript files to a hard drive cache (for most recent and most used js files), and then open the compiled file from cache instead of recompiling them

I tried to deserialize compiled jsscript objects and save them to hard drive.
If a js file is opened a second time, I prevent Firefox from reloading it, and I opened from the hard drive directly in compiled format.
The duration  of loading file (from http server or hard drive), the duration of compiling and the duration of running for each js script are saved to  a log file ( /home/riadh/info.log)
Could you please try to install the patch and try to visit some websites, and  check the log file (if loadtime + comptime (for nocache) >  loadtime + comptime (for fromcache) for script with same url (for msot of files),it's great. Otherwise , it's a problem.

Please create the following folder structure in your hard drive (linux) (or change /home/riadh/tmp/js/conf/comp, /home/riadh/info.log and /home/riadh/tmp/js in the patch file)
/home/riadh/tmp/js/conf/
Then create an empty file comp in /home/riadh/tmp/js/conf
(if comp exists ,then firefox will save js complied file, otherwise, it will work normally, the only change is that the time needing for opening js file file, compiling it and running it will be written to the log file
In the log file,
*files called "nocache" are files opened with saving compiled files disabled (comp file doesn't exist),
*files called "withcache" are files opened with saving compiled files enabled (comp file exist), but in this case the compiled file doesn't exist and js is compiled
*files called "fromcache" are files opened with saving compiled files enabled (comp file exist), and in this case the compiled file exist and js is not compiled


For many website firefox works fine. But with google, it crash.
Could you help me please fixing this bug?
Could you also please give me any suggestion
 




Actual results:

The browser work fine for many website, but when I open google the website browser crash


Expected results:

The browser dosn't crash

Comment 1

[Nicolas B. Pierron [:nbp]]

Comment on attachment 683305 [details] [diff] [review]
patch file

Review of attachment 683305 [details] [diff] [review]:
-----------------------------------------------------------------

You should decouple the cache operations from the rest, and use a thread to load from the cache while you are doing the compilation on the other thread.  If the cache finish before the compilation, then you can terminate the compilation earlier.

::: content/base/src/nsScriptLoader.cpp
@@ +539,5 @@
> +
> +      nsCString * spec = new nsCString();
> +      scriptURI->GetSpec(*spec);
> +      char chars[200];
> +      sprintf(chars,"%s" ,spec->get());

If you wonder from where your crashes are coming from, stop using such declaration of variable to prevent buffer overflow and thus prevent the stack from being erased.

::: js/src/jsapi.cpp
@@ +5804,5 @@
> +char * fname(char * key){
> +	size_t ha = hash((char * )key);
> +	char *str, *cl;
> +	char * i, *j;
> +    str = (char *) malloc(200);

Ok this is weird, at first I thought this was C&R indentation style, but this is just a mix of tab & spaces.

Comment 2

[riadh.chtara]

(In reply to Nicolas B. Pierron [:pierron] [:nbp] from comment #1)
> Comment on attachment 683305 [details] [diff] [review]
> patch file
> 
> Review of attachment 683305 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> You should decouple the cache operations from the rest, and use a thread to
> load from the cache while you are doing the compilation on the other thread.
> If the cache finish before the compilation, then you can terminate the
> compilation earlier.
I was thinking of estimating the reading time for a file
* there are two reading speed for a file in hard drive : speed1 is when the file is in the hard drive cache, speed2 is when the file is not in cache, of course speed1 > speed2
*for almost all of the files, if there are in hard drive cache, reading time > compiling time.
*for files that are not in cache, it will depend on the size of the file and the time of compiling
*to try to guess if a file is in cache or not, we use that MAX LIFE IN CACHE variable (the maximum duration that we didn't open a file and we have found after this duration that the file is in the cache)
*if we open the file we calculate the reading time, and we compare reading time with estimated reading time, and we try to enhance our estimation.
we could use a very simple machine learning algorithm to do that.
we need to keep a database with information we collect.

=> your idea is a lot simpler than mine, the only problem is that we will do two thing at the same time: reading and compiling, but i thing reading doesn't need a lot of cpu (it basically wait for hard drive).
So what do you think?
> ::: content/base/src/nsScriptLoader.cpp
> @@ +539,5 @@
> > +
> > +      nsCString * spec = new nsCString();
> > +      scriptURI->GetSpec(*spec);
> > +      char chars[200];
> > +      sprintf(chars,"%s" ,spec->get());
> 
> If you wonder from where your crashes are coming from, stop using such
> declaration of variable to prevent buffer overflow and thus prevent the
> stack from being erased.
> 
Thanks a lot, I have tried everything for a week to solve this problem.
Same website have scripts with very long names (more than 200 chars) and my buffer cannont hold them.
Now, it works just fine.
> ::: js/src/jsapi.cpp
> @@ +5804,5 @@
> > +char * fname(char * key){
> > +	size_t ha = hash((char * )key);
> > +	char *str, *cl;
> > +	char * i, *j;
> > +    str = (char *) malloc(200);
> 
> Ok this is weird, at first I thought this was C&R indentation style, but
> this is just a mix of tab & spaces.
Very sorry for that, I had problem with my eclipse configuration,and it's driving me crazy


Thanks a lot

Comment 3

[riadh.chtara]

Attachment: patch file : second version

Comment 4

[riadh.chtara]

Attachment: fixing indentation problem,use of local varibles instead of glabal ones

Comment 5

[riadh.chtara]

I get very good results, with this simple hard drive cache. It's very encouraging.

Comment 6

[riadh.chtara]

So a I have said it's very promising.
This is a little road map for the next steps:
* I will try some fast compression algorithms: the purpose to compress bytecode. I want to find out if there are algorithms with very fast decompression and decent ratio (to store more data inthe cache)
* I will try to use my approach for caching js files (smart caching with predicting of time needed to read bytecode from hard drive) and the idea of Nicolas B. Pierron (run two threads : one for reading and another one for compiling and then when one of them finish, close the second one.)
* I will finally try to see the effect of using same memory cache on the performance of the navigator.
So, if you have any comments or suggestions please tell me

Comment 7

[Till Schneidereit [:till]]

Comment on attachment 683686 [details] [diff] [review]
fixing indentation problem,use of local varibles instead of glabal ones

(In reply to riadh.chtara from comment #6)
> * I will try some fast compression algorithms: the purpose to compress
> bytecode. I want to find out if there are algorithms with very fast
> decompression and decent ratio (to store more data inthe cache)

You should take a look at how source code compression works, which you can find in the class ScriptSource in jsscript.h/cpp.

Comment 8

[riadh.chtara]

 
> You should take a look at how source code compression works, which you can
> find in the class ScriptSource in jsscript.h/cpp.

Thanks for you suggestion, Till
There are many similar things between source compression, and bytecode compression and it's a very good idea to use the same strategies in both cases.

As far I can see, there is a spacial compression thread that handle compression.
I think that it's a good idea to have only one thread for the hole browser process, this thread should  wait until all opened web page are loaded and shown in browser,the bytecode for the script used in these pages should remain in memory and then while user is browsing them, the compression thread compresses the bytecode for every script and saves it to hard drive. If the compression thread detects that user is opening other web pages, it should finish the compression for current script and then wait until these pages are completely shown.
The purpose of that is to have a transparent compression : the user will not wait for it, and when we will choose compression library,we care only decompression speed and compression ratio and we can neglect compression speed  as we have all time we need to compress

For the choice of compression library, in jsscript.h/cpp, zlib is used. but there many other good libraries. 
There is lz4 : compression ratio 31%   (for bytecode), decompression speed 330Mo/s (for bytecode), so it s very good choice. 
So I will choose it, at least at the Begin to do tests and then maybe if I find a better one, it could be easily replaced .

Comment 9

[riadh.chtara]

Attachment: patch file: version3 , with compression

Comment 10

[riadh.chtara]

Hey
If yoou wat
This is a small conclusion about the use of cache:
https://groups.google.com/forum/?fromgroups=&hl=de#!topic/mozilla.dev.tech.js-engine/u59mYsv6DZ4

I have changed the name of the file needed for enabling cache (see the first comment) 
from /home/riadh/tmp/js/conf/comp to /home/riadh/tmp/js/conf/compile
If you want to enable cache you need to create an empty file called
/home/riadh/tmp/js/conf/compress
The results are stared in info.log file( /home/riadh/info.log)

Comment 11

[dreakan]

You should probably update the patch to not use hardcoded directories, but store the disk cache rooted from some folder inside a user's Profile folder.  Then this will work for all supported platforms.

Also, you should not require users beforehand to create any folders or directories.  Can the patch be updated to include some sort of initializer to create the necessary folder/file structure if found not to exist?

Comment 12

[riadh.chtara]

Thank you dreakan for you great suggestion
Of course, the purpose of the patch is to do tests (it's not for final users)
But, its maybe time to make testing easier for other people.
So, I will do this as soon as possible.

Comment 13

[riadh.chtara]

Attachment: patch update: files structure auto generation

Comment 14

[riadh.chtara]

I couldn't know how to determine the profile folder. So I saved files in /tmp/cache folder.
I didn't want to spend a while for finding the profile folder, because there are many more import things I should do before.
But,I updated the patch so that it generates the files structure automatically at the beginning
(in /tmp/cache).
Saving compiling files and compressing are enable.To disable them, please delete :
*/tmp/cache/config/compress to disable compression or 
*/tmp/cache/config/compile to disable Saving compiling files
The log file is in /tmp/cache/info.log

The patch allows also windows support(I didn't try it because I should spend a half of day to configure my windows build environment and building firefox. There are more important hing to do for now). But it will be great if one of you could try it.

I need to start now building the cache handling mechanism.

Comment 15

[dreakan]

For Windows at least, maybe this bug can help:
   Bug 74085 - [Win] Disk cache should use local directory (CSIDL_LOCAL_APPDATA)

Anyone else have details for other platforms?

Comment 16

[Nicolas B. Pierron [:nbp]]

Hi Riadh,

On 11/30/2012 08:28 AM, riadh chtara wrote:
> I has worked this week on implementing the compression for the bytecode.
> and this is the new patch
> https://bugzilla.mozilla.org/attachment.cgi?id=687094
> 
> I used lz4 (very fast decompression speed, and compression ratio)
> *Few information
> The average lz4 compression ratio for bytecode is  1/3.
> The average compiling duration = 1/2 average execution duration (for facebook, gmail, google, twitter).(evaluate = compile + execute)

I am sorry to ask you that now, but can you clarify what you call execute, because facebook, gmail and twitter are constantly executing code and I don't understand what you are comparing your data against.

> *Results
> -If the bytecode file is in the hard drive cache:
> The duration for reading the not compressed file>  The duration for reading and decompressing the compressed file =>  the difference is between +20% to 100%) but both two duration is almost always less than 15% of the compiling duration. And the execution duration is much much bigger compared to both durations, so it's not possible to notice the difference.
> -If the bytecode file is not in the hard drive cache:
> The duration for reading the not compressed file<  The duration for reading and decompressing the compressed file but both durations are>  than compiling time and compiling this js is the best solution

When providing result, please provide the raw data of the measurement in addition to your current interpretation[1].  As well as the way you determine the data to be in disk the cache or not.  If the data are not in the cache, the time measured is likely to be mostly the seek time of the hard drive, and no difference should be noticeable over huge number of measurements.

Saving 15% of the compilation time, but this is not noticeable compared to the "execution" time?  Is that right?

> *Conclusion
> -There is not big difference between both choices in term of speed.

Please clarify, which choices, compressed or uncompressed?

> -In term of disk usage, the byte code is between 4-3 times more bigger than script. So if you are visiting many websites, and you disable compression,  you could need a big amount of disk space and the problem is you could run out of hard disk cache, but if you enable it, you will have 3 times more space)
> -The compression is slow, it will run on a background thread (it's a good idea to make one thread who's responsible of compression and writing to hard drive for the hole browser, on this thread should wait until the decrease of the activity of the machine)
> -If a memory cache will be implemented, the best idea is to use compression,(the cache needed for the fowling browser session:(gogle,facebook, twitter, gmail) is 2.9 Mo with compression, so even 3-4Mo of memory cache will be enough). The memory cache with compression will not be faster than disk cache(without compression) but will be much more reliable, because the browser is responsible of handling this cache(n the other case it is os and you don't control it)

How many cache hit/miss do you have in function of the cache size after a representative[?] browsing session?

Can you provide data on the size of the script that you encountered, how do they affect cache performances?

> =>I believe that in all cases (whether kind of cache you choose), with the results I have with my computer and os (ubuntu, ext4 for hard drive), it would be a an absolutely good choice to implement cache for bytecode. I can only recommand you to added to firefox.
> So I have a question for you, are you considering implementing this to firefox?

The problem is not only the performance win, but also the impedance cost added by such a code, such as the maintenance cost.

In your patch, can you explain why you disable COMPILE_N_GO flag?

[1] http://www.aps.org/publications/apsnews/200608/history.cfm

Comment 17

[riadh.chtara]

Hi dreakan: 
there is a class called nsifile that allows to handle files and directories in all platforms in the same way. 
I will try using it  with this funcion (toolkit/xre/nsapprunner.cpp
mProfileLock->GetDirectory(getter_AddRefs(mProfD));

Your suggetion leads me to find both the nsifile class and mProfileLock->GetDirectory so thanks a lot for you

(In reply to dreakan from comment #15)
> For Windows at least, maybe this bug can help:
>    Bug 74085 - [Win] Disk cache should use local directory
> (CSIDL_LOCAL_APPDATA)
> 
> Anyone else have details for other platforms?

Comment 18

[riadh.chtara]

Hi Nicolas
Thanks for your questions. I'm really glad to answer them.
> 
> I am sorry to ask you that now, but can you clarify what you call execute,
> because facebook, gmail and twitter are constantly executing code and I
> don't understand what you are comparing your data against.
> 
The compiling time for me is the time needed for to be executed
frontend::CompileScript(cx, obj, NULL, options, chars, length);
The execution time for me is the time length of 
JS_PUBLIC_API(bool) tmp = Execute(cx, script, *obj, rval);

> When providing result, please provide the raw data of the measurement in
> addition to your current interpretation[1].  
The measurement are here
https://docs.google.com/file/d/0B9VtjieUwlMDYUdoMEpjcHVPMjg/edit
*Script labeled withcache:  cache activated an compiled script was not found 
*Script labeled fromchache: cache activated an compiled script was found 
> As well as the way you
> determine the data to be in disk the cache or not. 
I use a hash function to give name to script. 
To check if a js compiled function is in cache or not, I use the hash function and look if a file with that name exist or not.

> If the data are not in
> the cache, the time measured is likely to be mostly the seek time of the
> hard drive, and no difference should be noticeable over huge number of
> measurements.
In the case of my measurement, (i have opened google,gmail,google drive, twitter, and facebook) and all files still in cache.
I will try to give you another result file with same script are not in hard drive cache.
 
> Saving 15% of the compilation time, but this is not noticeable compared to
> the "execution" time?  Is that right?
I mean you use cache, and whether you use compression or not, you will get a decease of 85% of compiling time, and 28% decrease in evaluation time (compile + execution) the second time you open a script.
> 
> Please clarify, which choices, compressed or uncompressed?
I will choose compression to be able to decrease the size of the saved files and to have the possibility to save more files  
> 
> How many cache hit/miss do you have in function of the cache size after a
> representative[?] browsing session?
Cache hit 147
cache miss 120
When a file A was not used for a long while , we should delete it.
(we should set max cache size to 20Mo, and if our current cache size is = 20Mo, and we want to add new file to cache, we delete the file A to save room for the new file)
> Can you provide data on the size of the script that you encountered, how do
> they affect cache performances?
The sizes of scripts are in the file, there are called is scriptsize
There many file > 100ko
This doesn't affect performance


> The problem is not only the performance win, but also the impedance cost
> added by such a code, such as the maintenance cost.
If we clean all hard drive js cache every time we close firefox (or better every time the computer is shutdown be writing files to /tmp folder in linux), I think it will work fine and will be great. It's really simple and doesn't require a lot of maintenance. In one session even if you use compression, it's hard to go out of 
So it could be very simple.(especially if we use your approach for handling cache

> In your patch, can you explain why you disable COMPILE_N_GO flag?
Someone from spidermonkey team told me that if I  want to use JS_EncodeScript and JS_DecodeScript, I need to disable COMPILE_N_GO (I'm not but very sure about the reason but I think it's because this makes optimization for the current window and this optimization couldn't be used with other window)
But I'm sure of that the gain of using the cache is much much bigger than the gain  of using COMPILE_N_GO.

I will add a comment with measure results(case file are not in hard drive cache), I really need to go now 
If you have more question, please tell me,. I was thrilled to answer your questions
Best
Riadh

Comment 19

[riadh.chtara]

Hi
I have updated the results files. The files are in excel fomat, so you can easily do calculation on them.
The first file contains the results for a small browsing session (google,facebook,gmail..) 

https://docs.google.com/file/d/0B9VtjieUwlMDa01WN19jalVnY1k/edit

For the second one, I tried to show  what happens when a file is out of cache, It was a very big session more than 750 script).And the bytecode files were used 3800 times .
https://docs.google.com/file/d/0B9VtjieUwlMDYnBQdzlUelQ4Q28/edit
I got in this session only one file which is not in cache(file number 3183 with red background).
So it's great.

Best
Riadh

Comment 20

[Nicolas B. Pierron [:nbp]]

(In reply to riadh.chtara from comment #19)
> I have updated the results files. The files are in excel fomat, so you can
> easily do calculation on them.

Thanks, I did some calculation on my own on the data …

> The first file contains the results for a small browsing session
> (google,facebook,gmail..) 
> 
> https://docs.google.com/file/d/0B9VtjieUwlMDa01WN19jalVnY1k/edit

This raw data are extremely interesting!  What I remarked:

- The name of the script does not seems to be enough in some cases, some script are parametrized, or have a different name but are still showing the same size and same compression size.  I wonder if a checksum in addition to a similar prefix might be a better way to check for matches.

- Huge scripts are showing the greatest improvement and the biggest script, such as what drive.google.com is using 2.5 MB (bytecode size) alone and cause a *180ms+45ms pause* instead of *~6ms+45ms pause* when there is a cache hit (45ms is the execution time before the script yield).  If the next access is done later in the futur and not within ~300ms (compression time), then this optimization would be interesting, as long as the cache is not evicted.  The current implementation is mono-threaded, which means that the cache would always be live after the script is compiled.  Can you provide deltas of time between the creation of the cache entry and every hit of it?

In this session, a cache entry is hit 1.2 times and if we omit entries which are never hit other entries are hit 3.4 times.  Cache entries of bigger scripts (above the mean of 14.16ms of compilation time) have more hits (2.33 times) and if we omit entries which are never hit entries are same average as small script hit 3.5 times.  The accumulated bytecode size used by scripts which are below the mean of 14ms compilation time (as-if they were not in the cache) is around 8.3 MB (3.0 MB compressed).

Note: Small scripts tend to be extremely badly compressed, is that a bug in the compression library?

This means, that bigger scripts tend to be re-used more frequently than smaller scripts, and a cache would be more efficient for bigger scripts.

What I wonder is when should we evict the cache, when is an entry too old?

In addition, I would appreciate if you can measure if one instance of the script is alive when there is a cache hit?  If we can clone the existing scripts instead of loading them from the disk, this might be faster.

Comment 21

[riadh.chtara]

Hi,
Thanks a lot for your answer.

> This raw data are extremely interesting!  What I remarked:
> 
I'm extremely  glad for hearing that. :) 
Thank you again.

I want just to recall that purpose of my code is only to test if it does worth to implement js bytecode cache for Firefox. So I wanted to do that with the minimum change to Firefox source code because I was not sure if it will work and I didn't want to "waste" a lot of time doing that.
But now, as we start getting good results, I absolutely agree that we need to change many things and do stuff in right way

> - The name of the script does not seems to be enough in some cases, some
> script are parametrized, or have a different name but are still showing the
> same size and same compression size.  I wonder if a checksum in addition to
> a similar prefix might be a better way to check for matches.
I think  the best solution for this problem is to create a mini database with the following information
-id (integer :auto incremented, we could use the id as file name)
-script URL
-expire date (firefox uses cache is so it's able to determine the expire date for any file, we could use this to get the expire date)
-compiling duration 
-frequency 
-last open date 
-delete = false (if we should delete the file)

If we open a script and we find out that the loading and the decompression time of the script is > the compiling duration of this script (from the database), this means that the script is no longer in cache
=> so all the bytecode files which last open date is before the last open date for this script are no longer in cache and  should be marked deleted from the database by changing delete to true (and later should be deleted from the hard drive)
I'm not sure , but I think that cache  is cleaned when the os is rebooting, this represents a big problem, so the best options is to delete bytecode files at booting (we put simply them in /tmp folder)

> - Huge scripts are showing the greatest improvement and the biggest script,
> such as what drive.google.com is using 2.5 MB (bytecode size) alone and
> cause a *180ms+45ms pause* instead of *~6ms+45ms pause* when there is a
> cache hit (45ms is the execution time before the script yield).  If the next
> access is done later in the futur and not within ~300ms (compression time),
> then this optimization would be interesting, as long as the cache is not
> evicted.  
I think this a good idea. Because in this case, the compiled script is in the memory, but Firefox doesn't know about it. So it reload it and recompile it. And maybe try to saved it.
But you know, 300ms is not that much, people need more than 300ms to open a new window of a website. So I suggest to keep in memory the script that are opened for the last 10s.  
> The current implementation is mono-threaded, which means that the
> cache would always be live after the script is compiled.  Can you provide
> deltas of time between the creation of the cache entry and every hit of it?
> 
Yes of course I can, I'm thinking of tow options for doing that:
-The first is to to simply write in the log file for each script the running date of each script, and then use excel to calculate delta
-The second option is to add a field to the database (first open time) and every time there is a hit, use it to calculate delta.  
> In this session, a cache entry is hit 1.2 times and if we omit entries which
> are never hit other entries are hit 3.4 times.  Cache entries of bigger
> scripts (above the mean of 14.16ms of compilation time) have more hits (2.33
> times) and if we omit entries which are never hit entries are same average
> as small script hit 3.5 times.  The accumulated bytecode size used by
> scripts which are below the mean of 14ms compilation time (as-if they were
> not in the cache) is around 8.3 MB (3.0 MB compressed).
> 
> Note: Small scripts tend to be extremely badly compressed, is that a bug in
> the compression library?
> 
Its not a bug, it's caused by the compression algorithms, so maybe we should use another compression algo (with extremely fast decompression, I'm not sure that there is one like this better than lz4, but if there is it would be great to use it) or we could simply not compress these files (which more simple) 
> This means, that bigger scripts tend to be re-used more frequently than
> smaller scripts, and a cache would be more efficient for bigger scripts.
> 

> What I wonder is when should we evict the cache, when is an entry too old?
I think the best option is to the hole cache at boot time. 
We should also set a maximum value for cache size.
I have told about the thread that should compress script a save them in background. When this thread finish compressing and saving file it should do two thing
-deletes files that their delete value in database is true, and deletes database entry  that represents them 
-checks if the total size < maximum value for cache size . If it's not, deletes files and entries until total size<= maximum value for cache size (uses last open date  and frequency to determine which file should be deleted first. 
> In addition, I would appreciate if you can measure if one instance of the
> script is alive when there is a cache hit?  If we can clone the existing
> scripts instead of loading them from the disk, this might be faster.
What do you mean by is alive: is in the temporary memory waiting for being saved ? or we keep a second level memory cache where we put the ? or  you mean it's possible to serialize a script while it's still executed? 


I still have a question about your approach for making two thread one to compile, another to open file,  and when one of them start, finish the other one.
I start implement it, but i have a concern, if we finish a thread and this thread has write many in the heap, we what happens? Is it possible to clean them?

Best
Riadh

Comment 22

[Nicolas B. Pierron [:nbp]]

(In reply to riadh.chtara from comment #21)
> > In addition, I would appreciate if you can measure if one instance of the
> > script is alive when there is a cache hit?  If we can clone the existing
> > scripts instead of loading them from the disk, this might be faster.
>
> What do you mean by is alive: is in the temporary memory waiting for being
> saved ? or we keep a second level memory cache where we put the ? or  you
> mean it's possible to serialize a script while it's still executed? 

By is alive, I mean, either another compartment is using the script or the script has not yet been garbage collected.

> I still have a question about your approach for making two thread one to
> compile, another to open file,  and when one of them start, finish the other
> one.
> I start implement it, but i have a concern, if we finish a thread and this
> thread has write many in the heap, we what happens? Is it possible to clean
> them?

You cannot terminate another thread, the other thread has to monitor a status flag to suicide-it-self by eagerly returning.

Comment 23

[riadh.chtara]

Hi,
Thank you
> By is alive, I mean, either another compartment is using the script or the
> script has not yet been garbage collected.
I didn't know that it is possible to use such script. So it's great idea to use them. (there in memory, we need just to serialize and copy them which much quicker)

> You cannot terminate another thread, the other thread has to monitor a
> status flag to suicide-it-self by eagerly returning.
I think there is a way to kill a thread by another thread(In linux atleast, in this case there is the following function that should be used : pthread_cancel).
But, I find that's absolutely not recommended to use it.
The best thing to do like you said :'the other thread has to monitor a status flag to suicide-it-self by eagerly returning'
But in this case in this case, someone has to clean heap before the end of the thread. So this could be very tricky.
So, I have a lot of work to setup this.  This will keep busy for a while.
I'll keep you update.

Best
Riadh

Comment 24

[riadh.chtara]

Hi,
I almost finished my javascript bytecode cache handling system.
I still need to do same test on it.
The cool part Nicolas has suggested  is also not finished yet. I need same help to do it.
Could you tell me please how to check if a script is alive? Which function should I use?

Best,
Riadh

Comment 25

[Nicolas B. Pierron [:nbp]]

(In reply to riadh.chtara from comment #24)
> Could you tell me please how to check if a script is alive? Which function
> should I use?

A script is "alive" if it is not garbage collected.  I know that compartments have a way to iterate on all their JSScript.  We use it when we are sweeping compiled code, or marking scripts. Have a look at  gc::cellIter uses in jscompartment.cpp, but I think it would be better to maintain an update an associative table to map to the correct script.

For evaluating, it would be fine to go dirty on such thing, but looking at others compartment implies being extremely careful as compartment are supposed to act in isolation from each others, except through wrapper, for security reasons.

Comment 26

[riadh.chtara]

thank you 
I'm working on that.

Comment 27

[riadh.chtara]

Attachment: new patch, database suppprt

Comment 28

[riadh.chtara]

Hi guys,
This is the new patch.
It includes handling the database of compiled js files.
The old files are cleaned automatically.
The database keeps also a list of jsscript that are not cleaned by garbage collector and uses them if needed.
I still have same bugs. I'm working on fixing them.
But these bugs don't occur often. So you could try it without having much problems.
One of the bugs I was talking about is related to content/base/scr/nsScriptloder.cpp.
I wanted to save only the compiled file of extern js files (I use js url as a key in the database, but many inline js can have the same url if there are in the same file), Could you help me please solve that. The result of this problem.
Could anyone please try to test the patch on windows , surf some websites (many times) and send me back info.log file.
The results on Linux are always encouraging.

Comment 29

[riadh.chtara]

Attachment: 700020: new patch, database suppprt (missing files solved)

Comment 30

[Nicolas B. Pierron [:nbp]]

(In reply to riadh.chtara from comment #28)
> I wanted to save only the compiled file of extern js files (I use js url as
> a key in the database, but many inline js can have the same url if there are
> in the same file), Could you help me please solve that. The result of this
> problem.

I don't think that we are lazily compiling JS scripts, so you can make a collection of bytecode per file instead of one bytecode per JSScript.  Otherwise the parser should at least have a line & column information which might help you to identify uniquely a script in a file.

In fact it is usual to have multiple JSScript per file, so I wonder why you are not seeing this problem more frequently.

Comment 31

[riadh.chtara]

Hi
(In reply to Nicolas B. Pierron [:pierron] [:nbp] from comment #30)

> 
> I don't think that we are lazily compiling JS scripts, so you can make a
> collection of bytecode per file instead of one bytecode per JSScript. 
> Otherwise the parser should at least have a line & column information which
> might help you to identify uniquely a script in a file.
But I think this is what I'm doing, for each js file,I create an only compiled file.

> In fact it is usual to have multiple JSScript per file, so I wonder why you
> are not seeing this problem more frequently.
I didn't know that. I'm a little bit confused here. I use this code to generate the compiled scippt for  the char * chars. Before that the hole js file is loaded in chars.

JSScript * scr;
scr = frontend::CompileScript(cx, obj, NULL, options, chars, length);
      jsfile = JS_EncodeScript(cx, scr, &size);



So is it possible in this case that many JSScripts are generated?


By the way I'm trying to test my patch with windows. AS you might already know, the project I'm doing is also for my university. So I have to write a report about it before March.It might seems far but, I have also all my exams before that. I don't have a lot of time. But before writing my report, I want to try patch on windows. The file system there is different. This could have a huge consequence on the reading time.So I'd like to see what will happen. So, I was fighting to build firefox with my patch since three days. I will keep you update with that.
Thank you

Comment 32

[Nicolas B. Pierron [:nbp]]

(In reply to riadh.chtara from comment #31)
> JSScript * scr;
> scr = frontend::CompileScript(cx, obj, NULL, options, chars, length);
>       jsfile = JS_EncodeScript(cx, scr, &size);
> 
> So is it possible in this case that many JSScripts are generated?

Sadly I don't have all the answers :(, You should ask on IRC because this is way faster to get answers than waiting on somebody to answer his bug-mail.

Maybe luke or jorendorff might be able to provide more details on how scripts are compiled and if there is an easy mapping between all the JSScript produced within a file and the file name.

Comment 33

[Luke Wagner [:luke]]

Here's a link to some previous investigations in this area:
 - bug 679939: currently bytecode are dynamically specialized to the dynamic contents of the global object and thus, to cache the JSScript we'd have to stop doing this specialization.
 - bug 679940: currently JSScript contains a dynamic portion (holding jit code, etc) and the static portion that would be cacheable; the bug is about splitting off this static portion which would be an optimization anyway since CloneScript could just share it.
 - bug 679942: is about making the actual cache, but doing it in the browser (which has more useful knowledge in the network cache and DOM than the JS engine has)

Comment 34

[riadh.chtara]

Hey luke,
thanks for your help.
There a lot of interesting idea in this bugs.
By the way, I use dom in my patch (to prevent downloading a script from webserver or reading it if there is a cache hit.
And may be it would be better to add the cache handling part between necko and and spidermonkey (but this would be harder to implement, and I wanted to do is to test if this worth to been implemented)

Comment 35

[riadh.chtara]

hey Nicolas
thanks also for your answer
> Sadly I don't have all the answers :(, You should ask on IRC because this is
> way faster to get answers than waiting on somebody to answer his bug-mail.
No problem.

By the way i'm still trying to build firefox on windows (almost a week now) .
And i still falling. (it's a problem with my computer, i may be need to find  a new one)
But i still fighting

Comment 36

[riadh.chtara]

Hey
As I said I was trying to test the cache system on windows.
I taught this will be easy, and it will take me an evening to do it. It has taken me 10 days (I hate my stupid computer, it was one my biggest challenge; It start crashing when it's hot, so this means after 1 hour of compiling, and then after restating it, i a have to start from the beginning . A friend borrowed me netbook (with it very slow atom process, it takes more than 6hours to build firefox) and things start getting much much better since)
I still have some bugs to solve
But i very happy to said that even with windows(A it's greate idea to

Comment 37

[riadh.chtara]

Hey
As I said I was trying to test the cache system on windows.
I taught this will be easy, and it will take me an evening to do it. It has taken me 10 days (I hate my stupid computer, it was one my biggest challenge; It start crashing when it's hot, so this means after 1 hour of compiling, and then after restating it, i a have to start from the beginning . A friend borrowed me netbook (with it very slow atom process, it takes more than 6hours to build firefox) and things start getting much much better since)

But i very happy to said that even with windows and NTFS, it's great idea to enable js caching)
Example of result i get for a page with jquery and jquery ui on the netbook 

I still have some bugs but i'm not sure if i will have enough time to solve them.

Comment 38

[dreakan]

This this related in any way with Bug 288473 ?

Comment 39

[riadh.chtara]

Hi dreakan, 
thanks for your question.
I think yes,the idea is the same but there is some difference in the implementation
*my purpose when I start was to test if this could work, with writing as less code as possible, so i implemented the code in jsapi, but I will suggest if they wants to have clean code to move with other browser cache as in https://bugzilla.mozilla.org/show_bug.cgi?id=288473 bug
Implementing such system will cause a very big improvement in the engine if the saved file is the disk cache, however it will make it slower if it's not . Thant doesn't happens a lot but needed to be solved .Two things were implemented to avoid that
*compression with lz4 very fast decompression=> almost instantly, compressed compiled files are 2.7 smaller than compiled script
*a cleaning system is implemented to clean files that are not in hard driver cache.

Comment 40

[riadh.chtara]

Hi dreakan, 
thanks for your question.
I think yes,the idea is the same but there is some difference in the implementation
*my purpose when I start was to test if this could work, with writing as less code as possible, so i implemented the code in jsapi, but I will suggest if they wants to have clean code to move with other browser cache as in https://bugzilla.mozilla.org/show_bug.cgi?id=288473 bug
Implementing such system will cause a very big improvement in the engine if the saved file is the disk cache, however it will make it slower if it's not . Thant doesn't happens a lot but needed to be solved .Two things were implemented to avoid that
*compression with lz4 very fast decompression=> almost instantly, compressed compiled files are 2.7 smaller than compiled script
*a cleaning system is implemented to clean files that are not in hard driver cache.