Bug 111002 - IndexedDB: Avoid ScriptValue copies in IDBAny
Summary: IndexedDB: Avoid ScriptValue copies in IDBAny
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Alec Flett
URL:
Keywords:
Depends on: 110206
Blocks: 100292
  Show dependency treegraph
 
Reported: 2013-02-27 11:58 PST by Alec Flett
Modified: 2013-03-01 17:06 PST (History)
8 users (show)

See Also:


Attachments
Patch (11.83 KB, patch)
2013-02-27 12:00 PST, Alec Flett
no flags Details | Formatted Diff | Diff
Patch (11.89 KB, patch)
2013-02-27 13:21 PST, Alec Flett
no flags Details | Formatted Diff | Diff
Patch (11.89 KB, patch)
2013-02-27 13:23 PST, Alec Flett
no flags Details | Formatted Diff | Diff
Patch (11.95 KB, patch)
2013-02-27 13:53 PST, Alec Flett
no flags Details | Formatted Diff | Diff
Patch for landing (12.04 KB, patch)
2013-03-01 14:55 PST, Alec Flett
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alec Flett 2013-02-27 11:58:59 PST
IndexedDB: Avoid ScriptValue copies in IDBAny
Comment 1 Alec Flett 2013-02-27 12:00:45 PST
Created attachment 190569 [details]
Patch
Comment 2 Alec Flett 2013-02-27 12:06:57 PST
With this patch, only 2 IDB tests crash as a result of bug 110206. As this bug does result in a useful cleanup in IDB, we should land it anyway.

The cases that now crash are:
storage/indexeddb/readonly.html
storage/indexeddb/keyrange.html

Strangely they both crash accessing keyRange.lower

With the patch in bug 110206, we do not crash at all.
Comment 3 Alec Flett 2013-02-27 12:13:58 PST
jsbell / dgrogan - comments?
Comment 4 David Grogan 2013-02-27 12:15:49 PST
Comment on attachment 190569 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=190569&action=review

> Source/WebCore/Modules/indexeddb/IDBAny.cpp:114
> +const ScriptValue& IDBAny::scriptValue()

I don't pretend to know what's going on in the rest of this patch, but returning a reference seems scary. You've ensured that it won't be problematic?
Comment 5 WebKit Review Bot 2013-02-27 12:26:26 PST
Comment on attachment 190569 [details]
Patch

Attachment 190569 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://webkit-commit-queue.appspot.com/results/16758178
Comment 6 Alec Flett 2013-02-27 12:59:28 PST
yes, (in fact thats the key line in this whole patch) - in fact the only caller (in V8IDBAnyCustom.cpp) does this:

impl->scriptValue().v8Value()

This is generally ok as long as the scope of the owning object is longer than the return value - such as the above when the return value is a temporary.
Comment 7 Joshua Bell 2013-02-27 13:07:31 PST
Comment on attachment 190569 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=190569&action=review

Seems okay. You might want to wait to land this until after https://bugs.webkit.org/show_bug.cgi?id=110206 lands so that it's easier to verify that bug's fix is in and behaving as expected.

> Source/WebCore/Modules/indexeddb/IDBAny.cpp:48
> +    return adoptRef(new IDBAny((IDBAny*)0));

A little wonky, but hidden inside the implementation. Seems reasonable.

> Source/WebCore/bindings/v8/custom/V8IDBAnyCustom.cpp:60
> +

Remove this extra whitespace.

> Source/WebCore/bindings/v8/custom/V8IDBAnyCustom.cpp:61
> +}

Looks like compile fails - need ASSERT_UNREACHED() / return v8::Undefined();
Comment 8 WebKit Review Bot 2013-02-27 13:12:59 PST
Comment on attachment 190569 [details]
Patch

Attachment 190569 [details] did not pass cr-linux-debug-ews (chromium-xvfb):
Output: http://webkit-commit-queue.appspot.com/results/16802097
Comment 9 Joshua Bell 2013-02-27 13:13:06 PST
Comment on attachment 190569 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=190569&action=review

>> Source/WebCore/Modules/indexeddb/IDBAny.cpp:48
>> +    return adoptRef(new IDBAny((IDBAny*)0));
> 
> A little wonky, but hidden inside the implementation. Seems reasonable.

Per discussion (and for the record), maybe have a constructor with signature:

IDBAny(IDBAny::Type type) : m_type(type), m_integer(0) { ASSERT(type == NullType || type == UndefinedType); }

.. and remove the IDBAny() and IDBAny(IDBAny*) contructors. Then createNull() would be:

return adoptRef(new IDBAny(NullType));

and createInvalid() would be:

return adoptRef(new IDBAny(UndefinedType));
Comment 10 Joshua Bell 2013-02-27 13:19:29 PST
See also wkbug.com/100292 - IMHO, in the medium term we should be striving to eliminate IDBAny in general, but that requires pushing more smarts into ScriptValue which should wait for wkbug.com/110206 and any other pending refactors. So no harm in doing this now.
Comment 11 Alec Flett 2013-02-27 13:21:42 PST
Created attachment 190589 [details]
Patch
Comment 12 Alec Flett 2013-02-27 13:23:35 PST
Created attachment 190590 [details]
Patch
Comment 13 WebKit Review Bot 2013-02-27 13:33:34 PST
Comment on attachment 190590 [details]
Patch

Attachment 190590 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://webkit-commit-queue.appspot.com/results/16758226
Comment 14 WebKit Review Bot 2013-02-27 13:44:03 PST
Comment on attachment 190590 [details]
Patch

Attachment 190590 [details] did not pass cr-linux-debug-ews (chromium-xvfb):
Output: http://webkit-commit-queue.appspot.com/results/16758230
Comment 15 Alec Flett 2013-02-27 13:53:50 PST
Created attachment 190597 [details]
Patch
Comment 16 Alec Flett 2013-03-01 09:42:16 PST
abarth@ - r? 

Now that bug 110206 is fixed, this is less of an issue, but it's still a good code cleanup and does reduce some totally unnecessary, if minor, copies
Comment 17 Adam Barth 2013-03-01 14:21:10 PST
Comment on attachment 190597 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=190597&action=review

> Source/WebCore/Modules/indexeddb/IDBAny.h:122
> +    IDBAny(Type);
> +    IDBAny(PassRefPtr<DOMStringList>);
> +    IDBAny(PassRefPtr<IDBCursor>);
> +    IDBAny(PassRefPtr<IDBCursorWithValue>);
> +    IDBAny(PassRefPtr<IDBDatabase>);
> +    IDBAny(PassRefPtr<IDBFactory>);
> +    IDBAny(PassRefPtr<IDBIndex>);
> +    IDBAny(PassRefPtr<IDBObjectStore>);
> +    IDBAny(PassRefPtr<IDBTransaction>);
> +    IDBAny(const IDBKeyPath&);
> +    IDBAny(const String&);
> +    IDBAny(const ScriptValue&);
> +    IDBAny(int64_t);

Should these be marked explicit?

> Source/WebCore/Modules/indexeddb/IDBAny.h:127
> +    const RefPtr<DOMStringList> m_domStringList;

const RefPtr is sort of unusual in WebCore, but I guess it's fine.
Comment 18 Alec Flett 2013-03-01 14:55:33 PST
Created attachment 191044 [details]
Patch for landing
Comment 19 Alec Flett 2013-03-01 14:56:59 PST
Comment on attachment 190597 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=190597&action=review

>> Source/WebCore/Modules/indexeddb/IDBAny.h:122
>> +    IDBAny(int64_t);
> 
> Should these be marked explicit?

yes they should. done.

>> Source/WebCore/Modules/indexeddb/IDBAny.h:127
>> +    const RefPtr<DOMStringList> m_domStringList;
> 
> const RefPtr is sort of unusual in WebCore, but I guess it's fine.

We've started using it recently - it's actually really nice and works just as you want it to - like a const pointer.
Comment 20 WebKit Review Bot 2013-03-01 17:06:26 PST
Comment on attachment 191044 [details]
Patch for landing

Clearing flags on attachment: 191044

Committed r144517: <http://trac.webkit.org/changeset/144517>
Comment 21 WebKit Review Bot 2013-03-01 17:06:32 PST
All reviewed patches have been landed.  Closing bug.