Mit freundlichen Grüßen Andreas Schlegel
Am 12.01.2014 13:35, schrieb Till Schneidereit: > On Sat, Jan 11, 2014 at 7:43 PM, Andreas Schlegel > <schlegel.andr...@gmail.com <mailto:schlegel.andr...@gmail.com>> wrote: > >>> Regardless of the threading stuff, objects don't belong to >>> contexts at all. They belong to compartments and can only be >>> accessed if that compartment has been entered. To refer to >>> objects from other compartments, a cross-compartment wrapper >>> has to be created. I would recommend dealing with that after >>> your changes work within a single global object. >> Can you explain me a little bit? I understand that the >> compartments are used to create multiple memory heaps for >> increasing perf of the garbage collector and the wrappers are >> used to touch objects from another compartment. >> But I don't understand the direct relation to my work. I need >> the Context to create RootedValues/Objects and for calling >> other functions which needs the context. I found only a >> function which gives me the default context over the runtime >> of an object, but the object's don't belong to the context >> :-). It's a little bit confusing to me. >> >> >> Objects don't belong to contexts, ever. A context is for storing >> things relevant to the current control flow state, not to data in >> the VM. At some point, contexts will be removed entirely and the >> state they now hold will be kept on the runtime. For now, using >> the default context should be fine. >> >> The compartments will become relevant if and when you start >> comparing objects from different globals. I don't know if that's >> required at all. If not, you shouldn't have to worry about >> compartments at all, as your function will be invoked with the >> correct compartment already entered. For clarity's sake, here's >> an example script for which compartments have to be pushed on and >> popped from the stack: >> >> var global = newGlobal(); >> evalcx('var obj = {foo:"bar"}', global); >> print(global.obj.foo); > Ok, I understand. At the moment I've changed the functions > LooselyEqual and StrictlyEqual of the Interpreter. The comparism > with "==" and "===" is mostly done there if I'm correct. My tests > show that only comparing in loops with more than 10 iterations are > done someone else, because of JIT optimization. The available > comparism tests for globals are all passed. > > Can you give me a test example to test if my code get into trouble? > > > I don't know your code, so this is somewhat speculative, but: if you > create an object (in your case a proxy, IINM) in one global and then > do a comparison with another object from another global, that should > blow up or give false results if you don't specifically handle these > cases. If it doesn't, then your code is set up so that the comparison > happens after some other code has already done the required unwrapping > for you. In that case, great, but you might want to test in the > browser, too, by creating multiple iframes and comparing objects from > two of them. I'm not so good in JavaScript, how can I assign the values to the globals for testing? For my case the "transparent" proxies are only the same, if the targets have the same identity. var global1 = newGlobal(); evalcx('var obj = {foo:"bar"}', global1); evalcx('var proxy1= new Proxy(obj)', global1); var global2 = newGlobal(); evalcx('var proxy2= new Proxy(obj)', global2); reportCompare(true, proxy1 == proxy2); Is this correct? At the moment I've only installed the Spidermonkey Engine, can I test the behaviour without a browser? _______________________________________________ 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
