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 _______________________________________________ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
