|
[
Permalink
| « Hide
]
Alexander Kellett added a comment - 09/Dec/09 10:21 AM - edited
AFAIU v8 is still quite a bit slower than the C++ based engine in Safari. Have you considered using that instead?
No - that APi is not really usable, and I think v8 and safari are neck and neck for speed.
safari also doesn't support a lot of the platforms we need. Author:{'name': 'Aaron', 'email': 'aaron@10gen.com'}
Message: http://github.com/mongodb/mongo/commit/8add9a17b9fe9d4a0a647c982326a2279aac2d23 Author:{'name': 'Aaron', 'email': 'aaron@10gen.com'}
Message: http://github.com/mongodb/mongo/commit/ebdb8282a2150c22a280705e99240d97b68e46d0 Author:{'name': 'Aaron', 'email': 'aaron@10gen.com'}
Message: http://github.com/mongodb/mongo/commit/bec620a87a8ea0974431952d0aba291372002558 Right now in sm, if a double that could be represented as an int is moved to sm and back, it remains a double. Right now in v8, in the same situation, the double is returned as an int without loss of information. Is this ok?
I'm just asking because the jstests don't check this behavior in TypeConservation though they test several other cases (I added a commented out --D-- section to demonstrate this particular issue) and the implementation for the current v8 behavior is nicer than would be required if we needed to keep track of the original type. i think this is ok.
i can theoretically see a problem this would could cause, but don't think its relevant. Author:{'name': 'Aaron', 'email': 'aaron@10gen.com'}
Message: http://github.com/mongodb/mongo/commit/b9ddc3e9ef3b1e234bc84dd6a80326f0196a249d Author:{'name': 'Aaron', 'email': 'aaron@10gen.com'}
Message: http://github.com/mongodb/mongo/commit/25b56fbba919cba1c370fc3dd9ee72b7deeef7ef Author:{'name': 'Aaron', 'email': 'aaron@10gen.com'}
Message: http://github.com/mongodb/mongo/commit/df01c097d655133080dabb4b40f7c1bc8754b522 Author:{'name': 'Aaron', 'email': 'aaron@10gen.com'}
Message: http://github.com/mongodb/mongo/commit/385bb326413e01ba27e62ab582e9b57f9251c269 It looks like it's impossible in v8 to implement access interceptors on a value which v8 represents internally as an array. Right now I'm using access interceptors to implement write protection, but to do so I am converting BSON arrays to v8 objects instead of v8 arrays (and then back into BSON arrays round-trip). However, with this implementation we can't treat the BSON arrays as arrays in js code (for example forEach() won't work, since v8 thinks it's dealing with a non-array object). I could conceivably use v8 arrays instead of v8 objects in cases where write protection isn't required, but then we'd have two different array formats and that could be confusing to a js programmer.
Inheriting from Array doesn't work correctly in v8, so that isn't an option for getting around this problem. I could post a question on the v8 user group, but I may not get any helpful feedback. What should I do? Just disable write protection for arrays? Yeah - just don't worry about write protection for arrays
not that important. Author:{'name': 'Aaron', 'email': 'aaron@10gen.com'}
Message: http://github.com/mongodb/mongo/commit/78a9e77c33a0276893ec2412bc4305195a5b5665 Author:{'name': 'Aaron', 'email': 'aaron@10gen.com'}
Message: http://github.com/mongodb/mongo/commit/643ad02d77769b59a458116b123f3902f8867cc6 I believe its impossible.
i'm pretty sure keySet() is supposed to only return fields on the current object, not including prototype fields. and i don't think there is a way to do that in pure js. if there is - then sure. Author:{'name': 'Aaron', 'email': 'aaron@10gen.com'}
Message: http://github.com/mongodb/mongo/commit/4cf6964975f5e7a87c2ac4a0f1e59a98c07f1666 Author:{'name': 'Aaron', 'email': 'aaron@10gen.com'}
Message: http://github.com/mongodb/mongo/commit/c3ea73736f3971adde40f41dfb7fdc9cff9b0a9a Yeah - probably can do something like that actually.
At least can't think of any problems right now. Author:{'name': 'Aaron', 'email': 'aaron@10gen.com'}
Message: http://github.com/mongodb/mongo/commit/15971b9ad92f8c82897046c92b7bf55683f8c95b Author:{'name': 'Aaron', 'email': 'aaron@10gen.com'}
Message: http://github.com/mongodb/mongo/commit/455bf0c0492421f8467f88e1f2371cb3e29dc5d9 Author:{'name': 'Aaron', 'email': 'aaron@10gen.com'}
Message: http://github.com/mongodb/mongo/commit/499cb647b65ca9d1b0cbdc27f72359b30bf2bf39 I'm implementing a js version of keySet and adding it to Object rather than Object.prototype to avoid having a new and confusing 'keySet' key in all objects when doing manual iteration. This requires that keySet be called explicitly via Object.keySet() rather than simply doing obj.keySet().
Hopefully this new interface is ok. Author:{'name': 'Aaron', 'email': 'aaron@10gen.com'}
Message: http://github.com/mongodb/mongo/commit/81b7e051b2c42e47566b9005e3db13e6a59ea68b Author:{'name': 'Aaron', 'email': 'aaron@10gen.com'}
Message: http://github.com/mongodb/mongo/commit/e7e790ee960c7e455b6655064f15a7547d38b039 It appears that when spidermonkey is invoked to return a value from a native c++ callback, values which the callback returned as 'undefined' type are converted to 'null' type. As a result, undefined values are converted to null when the db is queried.
This conversion is not performed by v8, and as a result one (or more) of the js tests don't pass, producing obscure output. Should I make v8 perform the same conversion undefined->null? Alternatively I could just fix the test(s) individually. lets make v8 work like spider monkey for now
Author:{'name': 'Aaron', 'email': 'aaron@10gen.com'}
Message: http://github.com/mongodb/mongo/commit/ad93048085caf8d79b7850a61b2d0669f2b972e1 v8 reorders fields with numeric names
In v8: > z = { "x":1,"4":2 }; { "4" : 2, "x" : 1 } while in sm: > z = { "x":1,"4":2 } { "x" : 1, "4" : 2 } I'm assuming this isn't a big deal for us. I'm just going to make the tests more flexible where they are failing currently. Author:{'name': 'Aaron', 'email': 'aaron@10gen.com'}
Message: http://github.com/mongodb/mongo/commit/ad8698567078da9b0d085dd33e02ca98147afe60 Author:{'name': 'Aaron', 'email': 'aaron@10gen.com'}
Message: http://github.com/mongodb/mongo/commit/5d9f70180b38379b45450fdf27ef97319e97745d Author:{'name': 'Aaron', 'email': 'aaron@10gen.com'}
Message: http://github.com/mongodb/mongo/commit/7c005a3fee2104ab00fb1c7c42c7cb5c0bd755b9 Author:{'name': 'Aaron', 'email': 'aaron@10gen.com'}
Message: http://github.com/mongodb/mongo/commit/de9e185d3d0ce38da0da0ff82509a90c383c4870 Author:{'name': 'Aaron', 'email': 'aaron@10gen.com'}
Message: http://github.com/mongodb/mongo/commit/bbcc6c1d0c80305396f051efdc34935505b614be Author:{'name': 'Aaron', 'email': 'aaron@10gen.com'}
Message: http://github.com/mongodb/mongo/commit/0e045e2fe1f9dede478a2980d6f4f75b6bc7b0ad we definitely need that and cannot get rid of it
used for client debugging in eval, etc... That's fine - just make sure to update the website docs with a note about 1.3
Author:{'name': 'Aaron', 'email': 'aaron@10gen.com'}
Message: http://github.com/mongodb/mongo/commit/793dfc134b24030ed19e29f4654077dfe56a75ce Author:{'name': 'Aaron', 'email': 'aaron@10gen.com'}
Message: http://github.com/mongodb/mongo/commit/643ec0261b21c8053dfabe9a9446d7bdc3ef788d Author:{'name': 'Aaron', 'email': 'aaron@10gen.com'}
Message: http://github.com/mongodb/mongo/commit/6c7cc48dcd1788a97878f7c7a9ee6e4ea3092f63 Author:{'name': 'Aaron', 'email': 'aaron@10gen.com'}
Message: http://github.com/mongodb/mongo/commit/39967b06090dab2e55d71ab520708e5900b4c3d2 Author:{'name': 'Aaron', 'email': 'aaron@10gen.com'}
Message: http://github.com/mongodb/mongo/commit/76275b5a6bae403289ab0dba760a3f5022761362 Author:{'name': 'Aaron', 'email': 'aaron@10gen.com'}
Message: http://github.com/mongodb/mongo/commit/80bd8d169d617a90cd515fd720ba38720066617d Author:{'name': 'Aaron', 'email': 'aaron@10gen.com'}
Message: http://github.com/mongodb/mongo/commit/556a55420536d63159c762e377d4d1f640e54340 Is it running out of v8 memory or total memory? Is the v8 memory configurable?
If its system memory, then its probably a leak in the v8 side... Author:{'name': 'Aaron', 'email': 'aaron@10gen.com'}
Message: http://github.com/mongodb/mongo/commit/770394a02d11fdf3b62be0c671083fb14826e1a0 Need to get running in a buildbot environment.
The scope cache is a very big deal for a lot of things.
What's the problem? For using v8 for testing it ok, but to use v8 as a spidermonkey replacement we need the caches to work. I haven't investigated the details, but v8 expects v8::Context's to be entered in a hierarchical fashion and internally maintains a stack of the active contexts. When a v8::Context is exited, v8 automatically enters the next context in its stack. When we reuse V8Scope's, we can't completely reset the v8::Context's stored within them, and v8 asserts when the ordering relationships are not as expected.
I'm sure there's some way of making this work, I just wanted to make sure it's worth the time. I assume scope caches were implemented because creating a scope is expensive in spidermonkey. Do we know the same is expensive in v8? Currently its definitely expensive because it has to re-run all the js-helpers.
If we could handle that differently, then we can probable remove the cache Ok, I'm trying to make it work and I'd like to know what the semantics of a Scope reset() are. It looks like in the sm engine reset() doesn't actually do anything:
void reset(){ smlock; assert( _convertor ); return; <more lines after the return;> Is that intentional? Is it ok to leave user data sitting in a scope in my v8 implementation? Yes - that's fine for now.
Its really a place holder in case there are things we need to do. Author:{'name': 'Aaron', 'email': 'aaron@10gen.com'}
Message: http://github.com/mongodb/mongo/commit/91362b9e354970f54a2acab9cf7089bf603713e1 Author:{'name': 'Aaron', 'email': 'aaron@10gen.com'}
Message: http://github.com/mongodb/mongo/commit/453aa1977ebb8a897ae803bc093fa8d09a4afe26 now a v8 64-bit linux buildbot slave
it does not seem to pass the tests yet Author:{'login': 'astaple', 'name': 'Aaron', 'email': 'aaron@10gen.com'}
Message: http://github.com/mongodb/mongo/commit/ad8292a9f7102a9a4f048710136f297419c5ab5a Author:{'login': 'astaple', 'name': 'Aaron', 'email': 'aaron@10gen.com'}
Message: http://github.com/mongodb/mongo/commit/56c790cb76ba471f152317ba962c5894b0330e7e Author:{'login': 'astaple', 'name': 'Aaron', 'email': 'aaron@10gen.com'}
Message: http://github.com/mongodb/mongo/commit/40184615d5f10e8885b9927fce4a94964ca5f58a passes all tests and is in bb
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Closed
Major
finish v8 engine
