internal fields

[Bruce MacNaughton]

I am new to Nan, V8, and C++ (so if I haven't put a big enough target on my back I don't know what else I can add). I've written a lot of JavaScript and, in the past, C, assembler, and kernel mode code, so hopefully the bulls-eye is a little smaller now.

I'm working with an existing code base and am trying to understand why things were done the way they were. It uses Nan to create an addon for nodejs. I'm hoping someone here can help me understand some pieces that escape me.

1. The code sets internal field count for each class - sometimes to 1 and sometimes to 2 - but never invokes "setInternalField()" or "getInternalField()". Is there some reason, possibly historical, that "setInternalFieldCount()" needed to be called to set a value? The way I have interpreted what I've read is that my code needs to set and get the value explicitly, so setting a value but never storing anything there makes no sense to me.

  // Prepare constructor template

 v8::Local<v8::FunctionTemplate> ctor = Nan::New<v8::FunctionTemplate>(New);

 ctor->InstanceTemplate()->SetInternalFieldCount(2);

 ctor->SetClassName(Nan::New("MyClass").ToLocalChecked());

2. Given that I'm storing something in internal fields, my understanding is that I need to free any resources (memory, etc.) that are used by the internal field if the object is GC'd. Doing that in the destructor seems to be the right way to handle that. Is that all there is to it?

3. What difference does it make to v8 if the internal field is an aligned pointer or not? Is the ability to set/get aligned pointers a consistency check so assumptions can be made? Does the interface check the alignment? (Not critical for me, I don't think, but I'd like to understand.)

[J Decker]

On Sat, Nov 4, 2017 at 9:29 AM, Bruce MacNaughton <bmacna...@gmail.com> wrote:

I am new to Nan, V8, and C++ (so if I haven't put a big enough target on my back I don't know what else I can add). I've written a lot of JavaScript and, in the past, C, assembler, and kernel mode code, so hopefully the bulls-eye is a little smaller now.

I'm working with an existing code base and am trying to understand why things were done the way they were. It uses Nan to create an addon for nodejs. I'm hoping someone here can help me understand some pieces that escape me.

 

Nan is really a nodejs thing, and not V8... so this is sort of the wrong place for these questions...

 

1. The code sets internal field count for each class - sometimes to 1 and sometimes to 2 - but never invokes "setInternalField()" or "getInternalField()". Is there some reason, possibly historical, that "setInternalFieldCount()" needed to be called to set a value? The way I have interpreted what I've read is that my code needs to set and get the value explicitly, so setting a value but never storing anything there makes no sense to me.

  // Prepare constructor template

 v8::Local<v8::FunctionTemplate> ctor = Nan::New<v8::FunctionTemplate>(New);

 ctor->InstanceTemplate()->SetInternalFieldCount(2);

 ctor->SetClassName(Nan::New("MyClass").ToLocalChecked());

Does it use Wrap and/or as classes subclassed with ObjectWrap?  Wrap uses internal field 0 to store the class so it can be later unwrapped from the V8 object.

https://github.com/nodejs/node/blob/master/src/node_object_wrap.h#L75 (near that is also SetWeak reference)

 

2. Given that I'm storing something in internal fields, my understanding is that I need to free any resources (memory, etc.) that are used by the internal field if the object is GC'd. Doing that in the destructor seems to be the right way to handle that. Is that all there is to it?

the destructor is really too late, at the point the destructor is called, the Object holding it would have also disappeared.... If the destructor is getting called, it's probably because of an ObjectWrapped thing disappearing, which internally stores the object in the class as a Persistent<> that is SetWeak()'d.  SetWeak takes a callback which is called when the object is GC'd.

 

3. What difference does it make to v8 if the internal field is an aligned pointer or not? Is the ability to set/get aligned pointers a consistency check so assumptions can be made? Does the interface check the alignment? (Not critical for me, I don't think, but I'd like to understand.)

I dooubt it matters... basically internal fields seem to be user-data fields that store the value so your user code can later retrieve it.  Internally I wouldn't expect V8 to ever actually do anything with those fields. Since they are usually pointers that are stored, aligned buffers will be more optimal.

 

--
--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups "v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Bruce MacNaughton]

Thanks for pointing me in the right direction.

To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+u...@googlegroups.com.

[Bruce MacNaughton]

Does it use Wrap and/or as classes subclassed with ObjectWrap?  Wrap uses internal field 0 to store the class so it can be later unwrapped from the V8 object.

https://github.com/nodejs/node/blob/master/src/node_object_wrap.h#L75 (near that is also SetWeak reference)

Yes, I think you just answered my question. So

 object->Wrap(info.This());

in the Object::New() method stores the instance in internal field 0, right?

[Jakob Kummerow]

3. What difference does it make to v8 if the internal field is an aligned pointer or not? Is the ability to set/get aligned pointers a consistency check so assumptions can be made? Does the interface check the alignment? (Not critical for me, I don't think, but I'd like to understand.)

I doubt it matters... basically internal fields seem to be user-data fields that store the value so your user code can later retrieve it.  Internally I wouldn't expect V8 to ever actually do anything with those fields. Since they are usually pointers that are stored, aligned buffers will be more optimal.

It actually does matter, and the interface does check for alignment. The reason is that V8 relies on those pointers being aligned: it uses this fact as part of the mechanism for deciding to ignore them.

[J Decker]

Well 'aligned' is pretty generous... it only requires being 16 bit aligned...  (2 byte)

from https://github.com/v8/v8/blob/master/src/api.cc#L1186

const int kSmiTag = 0;

const int kSmiTagSize = 1;

const intptr_t kSmiTagMask = (1 << kSmiTagSize) - 1;

#define HAS_SMI_TAG(value) \

  ((reinterpret_cast<intptr_t>(value) & ::i::kSmiTagMask) == ::i::kSmiTag)

bool Object::IsSmi() const { return HAS_SMI_TAG(this); }

Utils::ApiCheck(smi->IsSmi(), location, "Pointer is not aligned");

Which since this is ObjectWrap feature, it's passed a pointer to a class, which I would imagine 'new' will return a 4 or 8 byte aligned pointer; but on further research there is no guarantee.