4 ms·

Hmm, I understand where you're coming from, but I'd argue that many applications embedding Javascript engines - particularly libraries trying to provide JS bind

by udp 15y ago

Hmm, I understand where you're coming from, but I'd argue that many applications embedding Javascript engines - particularly libraries trying to provide JS bindings - won't need anything more complicated than simple script/function/value manipulation (or at least, nothing that can't be wrapped into something high-level and engine agnostic). It's true that some of the current APIs are implemented in a clunky way, but I'm quite confident there are better ways to do things while still maintaining support for both engines.

apaprocki 15y ago
For simple things it might work, but if a library wrapper was written using your wrapper instead of the native API then there is a good chance it will not be as performance optimized if it was simply using the engine API. That could mean that the work put into that binding would have to be forked / duplicated to create a lower-level binding that could take advantages of some of the engine APIs you don't wrap in the common interface.
- udp 15y ago
  Understood, but I'm not ready to give up on this just yet :-) I know you think this is a futile effort, but I'd welcome any improvements from someone who knows more about the engine internals than I do. I'm currently working out what I can do instead of rooting every ValueRef.
  - apaprocki 15y ago
    For the rooting, you can't know if someone is storing you on the stack unless you get hack-y[1]. So you'd have to assume the opposite, that the caller is storing you on the stack and give them something like .root() to call if they are not. [1] In the end, the way stack-scanning GC works is that it has OS-specific code (see jsnativestack.cpp[2] in SM) to get the highest stack address (stack grows down in all the archs you care about). Then since you know someone is calling into your constructor, you can declare a variable on the stack and get its address to find out the current stack pointer. If 'this' is between the current stack pointer and the stack base, you are on the stack and do not need to root yourself.[3] [2] http://hg.mozilla.org/mozilla-central/file/a1b89b4913ca/js/src/jsnativestack.cpp http://hg.mozilla.org/mozilla-central/file/a1b89b4913ca/js/s... [3] I coded an example up to show you (it uses an OSX-specific pthread API to get the stack base -- see the SM code for other platforms) http://pastebin.com/dVDGWJP5 http://pastebin.com/dVDGWJP5

by udp 15y ago

apaprocki 15y ago

For simple things it might work, but if a library wrapper was written using your wrapper instead of the native API then there is a good chance it will not be as performance optimized if it was simply using the engine API. That could mean that the work put into that binding would have to be forked / duplicated to create a lower-level binding that could take advantages of some of the engine APIs you don't wrap in the common interface.

udp 15y ago
Understood, but I'm not ready to give up on this just yet :-) I know you think this is a futile effort, but I'd welcome any improvements from someone who knows more about the engine internals than I do. I'm currently working out what I can do instead of rooting every ValueRef.
- apaprocki 15y ago
  For the rooting, you can't know if someone is storing you on the stack unless you get hack-y[1]. So you'd have to assume the opposite, that the caller is storing you on the stack and give them something like .root() to call if they are not. [1] In the end, the way stack-scanning GC works is that it has OS-specific code (see jsnativestack.cpp[2] in SM) to get the highest stack address (stack grows down in all the archs you care about). Then since you know someone is calling into your constructor, you can declare a variable on the stack and get its address to find out the current stack pointer. If 'this' is between the current stack pointer and the stack base, you are on the stack and do not need to root yourself.[3] [2] http://hg.mozilla.org/mozilla-central/file/a1b89b4913ca/js/src/jsnativestack.cpp http://hg.mozilla.org/mozilla-central/file/a1b89b4913ca/js/s... [3] I coded an example up to show you (it uses an OSX-specific pthread API to get the stack base -- see the SM code for other platforms) http://pastebin.com/dVDGWJP5 http://pastebin.com/dVDGWJP5