On Tuesday, February 10, 2015 at 11:59:47 PM UTC+2, Erdal Mutlu wrote: > On Tuesday, February 10, 2015 at 11:44:54 PM UTC+2, Steve Fink wrote: > > On 02/10/2015 11:11 AM, Erdal Mutlu wrote: > > > On Tuesday, February 10, 2015 at 6:59:20 PM UTC+2, Steve Fink wrote: > > >> On 02/10/2015 01:06 AM, Erdal Mutlu wrote: > > >>> Hi, > > >>> > > >>> I have been instrumenting the JS engine interpreter for logging memory > > >>> updates on JS scripts. My current instrumentation logs every use of the > > >>> interpreter for script execution which also includes browser (internal) > > >>> script execution. I wanted to ask if there is a way to separate these > > >>> internal calls from the user (webpage) specific scripts running on the > > >>> interpreter. > > >>> > > >>> I couldn't be sure if this question should be directed to platform or > > >>> js-engine so I am posting it to both. Thanks in advance. > > >> There's actually another list called js-engine. You're posting to > > >> js-engine-internals, which is fine (and better than dev-platform). > > >> > > >> I do not completely understand your question. You say you are logging > > >> "memory updates on JS scripts", but then you discuss logging script > > >> executions. I'm not sure if you just want to log script invocations, > > >> categorized by content vs internal, or if you are just doing that in > > >> order to categorize memory accesses. > > >> > > >> All scripts live within a compartment, and you can tell from that > > >> compartment whether the script is from content (user/webpage) or chrome > > >> (browser/internal). Not only that, but all memory allocations that are > > >> managed by the JS engine's garbage collector (we call them GC things) > > >> are also contained with a compartment. There is other memory which may > > >> be either controlled by a GC thing (as in, it will be automatically > > >> freed when that GC thing is no longer live), or is completely external > > >> to the GC. Those are harder to associate with content vs chrome. This is > > >> what about:memory does -- it scans through all (well, most) of allocated > > >> memory and categorizes it when possible, or else puts it an "Other" > > >> category when it is not directly associated with a web page or chrome. > > >> > > >> Logging script execution crossings between content and chrome is another > > >> matter, since it is about control flow. It's relatively easy to do if > > >> you're only running in the interpreter, since you have to "enter" a > > >> compartment in order to create or manipulate anything. You can > > >> instrument those compartment entries. But I think the JITs do some > > >> compartment-crossing internally, and that's harder to track. (You can > > >> always run with the JITs disabled if that will work for whatever it is > > >> you are trying to accomplish.) > > >> > > >> If you tell me more about what exactly you are trying to achieve, we > > >> could probably be more helpful. > > > > > > Thanks for the quick response and insight about the compartments. > > > > > > I've been working on a scheme to record the memories accessed during the > > > execution of JS script. So far I have been adding some logging mechanism > > > on the Interpret function (namely JSOP_GETNAME, JSOP_GETPROP, > > > JSOP_SETNAME, JSOP_SETPROP). Basically, I am recording the values read > > > and written to JS variables and properties. > > > > > > But I only want to record these values for scripts from content rather > > > than chrome. > > > > Ah, then Jan was right. > > > > Use cx->compartment()->isSystem() > > Thanks. I just tried that and it gets rid of quite number of memory accesses > to log. But I am still seeing some scripts not related to the content being > executed (i.e. XMLHttpRequest being send and handlers being executed) > although they are not marked as system compartment. > > Should I conclude that these scripts also reside in the same compartment as > the content or is there a further identification on the compartments that can > be used for this case? > > Erdal
It seems like these calls to interpreter are from DOM Worker's. Is there way to check if the interpreter is called by main thread or from another thread? Erdal _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
