On Sat, Jan 11, 2014 at 7:43 PM, Andreas Schlegel <
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.
_______________________________________________
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
