WIP: prototype ffi support

src/objects.h

Index: src/objects.h
diff --git a/src/objects.h b/src/objects.h
index a7aabe23e0f856b18734e09f3fe4f40c7b4b508d..e502633592f0a17a82173388c45fe34ce07aa7c6 100644
--- a/src/objects.h
+++ b/src/objects.h
@@ -4870,7 +4870,8 @@ class Code: public HeapObject {
   V(REGEXP)                 \
   V(WASM_FUNCTION)          \
   V(WASM_TO_JS_FUNCTION)    \
-  V(JS_TO_WASM_FUNCTION)
+  V(JS_TO_WASM_FUNCTION)    \
+  V(JS_TO_NATIVE_FUNCTION)

[Benedikt Meurer, 2016/06/21 03:26:01]

Not sure this necessary. Those functions could also use the BUILTIN kind,
similar to what we do for TurboFan builtins, i.e. MathSin and friends.

[ofrobots, 2016/06/23 01:02:51]

I think the same argument could be made for JS_TO_WASM_FUNCTION.

These functions would have 1:1 mapping to user provided function pointers. Also,
note this code in log.cc:

    case AbstractCode::BUILTIN:
      description =
          isolate_->builtins()->name(code_object->GetCode()->builtin_index());
      tag = CodeEventListener::BUILTIN_TAG;
      break;

I think all JS_TO_NATIVE_FUNCTIONs should have be considered unique (i.e.
shouldn't share a builtin_index). Are you proposing adding builtin indices for
each of these wrapper functions?

[Benedikt Meurer, 2016/06/23 03:34:07]

JS_TO_WASM is somewhat special and likely subject to change in some way.
But I you are right, I forgot about the implication of BUILTIN for logging. So,
yes, JS_TO_NATIVE_FUNCTION sounds good to me.

 
 #define IC_KIND_LIST(V) \
   V(LOAD_IC)            \