On Thu, Jan 3, 2013 at 12:53 PM, Sven Panne <[email protected]> wrote:
> Lacking any proof, I somehow doubt that the problem is in v8: :-) Chrome > uses the aligned pointer API quite heavily for some time now without any > known problems. > Conversely, lacking any breakage until this change, i doubt the problem is in my dev environment ;). My code was basically doing the following, but with a good deal of template-level abstraction/indirection going on around it: T t = new T; obj->SetPointerInInternalField( n, t ); that had worked fine for 2+ years until we were forced to switch to the strictly-aligned version, at which point the new assertion was triggered. > Could you set a breakpoint in Utils::ReportApiFailure and check that the > value of the pointer when the error happens? > The problem was resolved/worked around a couple of weeks ago, and i don't intend on going back to the old sources to check this (especially since nobody else is reporting this problem). While trying to figure out what was going on i was spitting out the value from my (new T) call, which was subsequently stuffed into the internal field, to stderr and did verify that it was an even number. As i honestly don't expect the strict-alignment code to be of any use outside of Chromium, my attitude towards it is, "if it works for Chromium, then it works." That wasn't my experience, but my experience is now irrelevant ;). The _only_ reason i ever used SetPointerInInternalField() was because i assumed (wrongly, it turns out) that it was a convenience form of SetInternalField(x, External::New(...)). Since Internal Fields hold Value Handles, it never occurred to me that SetPointerIn... could be anything but a wrapper around an External Value (famous last assumptions...). As you've probably figured out, using External is not really cheap, because > it involves allocating 2 objects: One JavaScript object with a hidden field > containing a Foreign, see Heap::AllocateExternal. > i actually hadn't figured that out - as a rule i don't peek into/mess around with the internals of large/complex libraries i'm using only at the client level. Anything which isn't in the public API, i pretend it doesn't exist. That said, i'm not all that worried about a few more bytes in this context - nobody who's binding JS code to C++ objects truly expects (i think) them to be featherweights in terms of memory requirements. Management summary: let's call this "cannot reproduce" until/unless someone else has a problem with it. :) -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
