Associating metadata with non-objects

[Charles Lowell]

Hi,

I make extensive use of Get/SetHiddenValue() on Object (as I'm sure
everybody does) to store external references to native peers. My
question is if there is a "best practice" (or any practice for that
matter) for storing peers on any Value?

cheers,
Charles

[Mads Sig Ager]

Hi Charles,

I would use internal fields for that. I would create the JS wrappers from templates specifying a number of internal fields and use Set/GetPointerInInternalField to get and set them. Internal fields are faster to access than hidden properties. 

Cheers,    -- Mads

--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users

[Stephan Beal]

On Tue, May 3, 2011 at 8:32 AM, Mads Sig Ager <ag...@chromium.org> wrote:

I would use internal fields for that. I would create the JS wrappers from templates specifying a number of internal fields and use Set/GetPointerInInternalField to get and set them. Internal fields are faster to access than hidden properties. 

i think Charles is wanting to tie data to non-template-generated values like Numbers. From what i understand, v8 does not have the API to do this. Nor does it provide a stable unique ID per value instance which we can use to do the mapping ourselves (it is doable in SpiderMonkey, but that's probably SM's only advantage over v8).

 

--
----- stephan beal
http://wanderinghorse.net/home/stephan/

[Mads Sig Ager]

Object::GetIdentityHash should give you what you want to do the mapping externally. If you want to add external data after the fact in the object itself hidden values is the way to go. :)

Cheers,    -- Mads

 

 

--
----- stephan beal
http://wanderinghorse.net/home/stephan/

--

[Stephan Beal]

On Tue, May 3, 2011 at 8:56 AM, Mads Sig Ager <ag...@chromium.org> wrote:

On Tue, May 3, 2011 at 8:52 AM, Stephan Beal <sgb...@googlemail.com> wrote:

i think Charles is wanting to tie data to non-template-generated values like Numbers. From what i understand, v8 does not have the API to do this. Nor ...

 

Object::GetIdentityHash should give you what you want to do the mapping externally. If you want to add external data after the fact in the object itself hidden values is the way to go. :)

But Object::GetIdentityHash() only works for Objects, right?

In SpiderMonkey each JS value is a numeric handle with a stable value (v8's aren't stable b/c of how the allocator works), and those numbers can be used to map, e.g. 

a Window handle to a JS Integer.

[Mads Sig Ager]

Yes, GetIdentifyHash only works for Objects. For values you can easily roll your own. What you get from GetIdentityHash will stay the same over time.

-- Mads

 

--
----- stephan beal
http://wanderinghorse.net/home/stephan/

--

[Charles Lowell]

Mads,

Thanks for the helpful tips. I will definitely look into using
internal fields where possible to achieve the speedup.

Stephan is correct, I'm wanting to associate metadata with non-object,
non-template created values like dates and regexen. In fact, for my
use-case (therubyracer), I'd really like to be able to tie metadata to
anything you can get a Handle to since I also reflect non-value things
into Ruby like Context and FunctionTemplate. That said, being able to
get a stable, unique object id for all values would be killer. You
mentioned that it would be relatively straightforward to roll your
own? Any chance you could elaborate?

cheers,
Charles

On May 3, 2:01 am, Mads Sig Ager <a...@chromium.org> wrote:
> On Tue, May 3, 2011 at 8:58 AM, Stephan Beal <sgb...@googlemail.com> wrote:

[Stephan Beal]

On Tue, May 3, 2011 at 3:41 PM, Charles Lowell <cow...@thefrontside.net> wrote:

into Ruby like Context and FunctionTemplate. That said, being able to
get a stable, unique object id for all values would be killer. You
mentioned that it would be relatively straightforward to roll your
own? Any chance you could elaborate?

For OBJECTS you can presumably use the identity hash, but for non-Objects v8 does not publish a _stable_ unique ID. You can get a (void *) to the underlying data (Value::Data(), IIRC), which could then be used as a key, but that address is not guaranteed to be stable - v8 may relocate it as a side-effect of allocation/gc.

When i first started porting my SpiderMonkey JS/C++ type conversions framework to v8. that lack of a stable ID was my first big hurdle, and eventually gave up on the idea that one can tie a (T*) to a JS integer in v8.

For builtin Object types (Date, Regex, etc) you can't stuff your own mappings into them because the number of internal fields is defined by the Template and not on a per-instance basis. e.g. the Regex authors didn't set aside an internal field for our use then we cannot stuff an internal field in those instances.

[Charles Lowell]

On May 3, 11:35 am, Stephan Beal <sgb...@googlemail.com> wrote:

Indeed, but Mads mentioned at the very end of his response that there
was a way to roll your own for values, and I'm curious to hear what he
had in mind.

cheers,
Charles


> --
> ----- stephan bealhttp://wanderinghorse.net/home/stephan/

[Mads Sig Ager]

Hi again Charles,

I was only considering values and I was thinking that rolling your own Hash method for a value would be fairly easy since there are not that many basic types to worry about.

Something along the lines of:

int Hash(Handle<Value> value) {

  if (value->IsObject()) {

    return Handle<Object>::Cast(value)->GetIdentityHash();

  } else if (value->IsString()) {

    // compute and return string hash

  } else if (value->IsNumber()) {

    // compute and return number hash

  } else if (value->IsBoolean()) {

    if (value->IsTrue()) {

      // return hash value for true

    } else {

      // return hash value for false

    }

  } else if (value->IsNull()) {

    // return hash value for null

  } else if (value->IsUndefined()) {

    // return hash value for undefined

  } 

  assert(false);

  return 0;

}

Cheers,    -- Mads

[Mads Sig Ager]

PS: dates and regexps are objects so they will be covered by the Object branch here.

Cheers,    -- Mads

[Charles Lowell]

Mads,

Thanks again for the response. I was under the impression that Date
and RegExp were not objects, only values. For example,
https://github.com/v8/v8/blob/master/include/v8.h#L1355

Although now that I actually attempt to cast it to object and call
object methods on it, it does appear to work. How is that possible,
and why not make it descend from Object in the first place?

cheers,
Charles

On May 3, 2:23 pm, Mads Sig Ager <a...@chromium.org> wrote:
> PS: dates and regexps are objects so they will be covered by the Object
> branch here.
>
> Cheers,    -- Mads
>

[Mads Sig Ager]

That is indeed confusing. We should update the inheritance hierarchy in the API for date and regexp objects. They are JavaScript objects and not primitive values.

The type testing and casting is implemented in terms of the actual JavaScript values and therefore Date and RegExp objects can be casted to Object even though the API inheritance hierarchy does not reflect the fact that they are objects.

Cheers,    -- Mads

[Stephan Beal]

On Tue, May 3, 2011 at 9:51 PM, Mads Sig Ager <ag...@chromium.org> wrote:

The type testing and casting is implemented in terms of the actual JavaScript values and therefore Date and RegExp objects can be casted to Object even though the API inheritance hierarchy does not reflect the fact that they are objects.

Does "can be casted" mean that such casts are legal, or that it "just happens to work"?

[Mads Sig Ager]

On Tue, May 3, 2011 at 10:01 PM, Stephan Beal <sgb...@googlemail.com> wrote:

On Tue, May 3, 2011 at 9:51 PM, Mads Sig Ager <ag...@chromium.org> wrote:

The type testing and casting is implemented in terms of the actual JavaScript values and therefore Date and RegExp objects can be casted to Object even though the API inheritance hierarchy does not reflect the fact that they are objects.

Does "can be casted" mean that such casts are legal, or that it "just happens to work"?

They are perfectly legal. Date and regexps *are* JS objects.

Cheers,    -- Mads

 

--

----- stephan beal
http://wanderinghorse.net/home/stephan/

--

[Mads Sig Ager]

I have changed the inheritance hierarchy in the API to reflect the fact that Date and RegExp objects are Objects.

Thanks,    -- Mads

[Alejandro F. Reimondo]

Hi,
I updated from svn server to revision 7782,
and, as was announced, the solution and project files
was obsoleted/deleted (causing my customizations to make
comfortable builds of my project an impossible mission
... or at least "unsupported" :)
I followed guides on build/ReadMe.txt file to download
& install two additional "text oriented tools" (tons of scripting
code to build project list files!) and run the command
to build All.sln file...
As I expected (considering the complexity/quality
of the tools), ... it failed to build the solution file. :-(
I attached at end of this email the report of failure
(text in command window... as in the '80s).

What I can do to solve the problem?
I am trying to generate the solution file and project files
for 64bits under windows7 (64bits), as a first step
to restore the state of my work (that will require
additions to project files to adapt my changes
to V8).
I have not updated my instalation (yet) for 32bits,
but I suspect that it will go same way...

Please, I need help to solve actual problem
(to build clean sln and project files)
without loosing too much time... I used to build
v8 under this platform daily and now, I am not
sure if the process can be continued, because
if the project are built without merge with local
version, it will overwrite my work on each svn
update+build.

Any help or guide to solve the problem will be appreciated!
thanks in advance,
Ale.
p.d. failure report follows
---------------------------------------------------------------------------------------
Updating projects from gyp files...
Traceback (most recent call last):
File "build/gyp_v8", line 145, in <module>
sys.exit(gyp.main(args))
File ".\build\gyp\pylib\gyp\__init__.py", line 445, in main
options.circular_check)
File ".\build\gyp\pylib\gyp\__init__.py", line 84, in Load
depth, generator_input_info, check, circular_check)
File ".\build\gyp\pylib\gyp\input.py", line 2174, in Load
depth, check)
File ".\build\gyp\pylib\gyp\input.py", line 379, in LoadTargetBuildFile
build_file_path)
File ".\build\gyp\pylib\gyp\input.py", line 940, in
ProcessVariablesAndConditi
onsInDict
ProcessConditionsInDict(the_dict, is_late, variables, build_file)
File ".\build\gyp\pylib\gyp\input.py", line 817, in
ProcessConditionsInDict
variables, build_file)
File ".\build\gyp\pylib\gyp\input.py", line 959, in
ProcessVariablesAndConditi
onsInDict
build_file, key)
File ".\build\gyp\pylib\gyp\input.py", line 959, in
ProcessVariablesAndConditi
onsInDict
build_file, key)
File ".\build\gyp\pylib\gyp\input.py", line 959, in
ProcessVariablesAndConditi
onsInDict
build_file, key)
File ".\build\gyp\pylib\gyp\input.py", line 940, in
ProcessVariablesAndConditi
onsInDict
ProcessConditionsInDict(the_dict, is_late, variables, build_file)
File ".\build\gyp\pylib\gyp\input.py", line 798, in
ProcessConditionsInDict
if eval(ast_code, {'__builtins__': None}, variables):
File "<string>", line 1, in <module>
NameError: name 'msvs_multi_core_compile' is not defined while evaluating
condit
ion 'msvs_multi_core_compile' in build\all.gyp while trying to load
build\all.gy
p
---------------------------------------------------------------------------------------