Oilpan: Prepare to move DatabaseContext to Oilpan heap.

Oilpan: Prepare to move DatabaseContext to Oilpan heap.

We need to change
  HashMap<ExecutionContext*, RefPtr<DatabaseContext>>
to
  HashMap<ExecutionContext*, OwnPtr<Persistent<DatabaseContext>>>
Because we can't use PersistentHeapHashMap due to mutiple threads, and can't put
Persistent<> to HashMap directly.

BUG=347902
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=170246

[tkent, 2014-03-28 00:52:05]

Please review this.
This is the last one in modules/webdatabase/.

[haraken, 2014-03-28 01:03:24]

https://codereview.chromium.org/215063005/diff/1/Source/modules/webdatabase/D...
File Source/modules/webdatabase/DatabaseManager.h (right):

https://codereview.chromium.org/215063005/diff/1/Source/modules/webdatabase/D...
Source/modules/webdatabase/DatabaseManager.h:103: // We can't use
PersistentHeapHashMap because multiple threads update the map.

What's the issue of updating a PersistentHeapHashMap from multiple threads? I
guess it's safe as long as it's guaranteed that a thread that touches the
PersistentHeapHashMap does not outlive the thread that created the
PersistentHeapHashMap.

[tkent, 2014-03-28 01:17:25]

https://codereview.chromium.org/215063005/diff/1/Source/modules/webdatabase/D...
File Source/modules/webdatabase/DatabaseManager.h (right):

https://codereview.chromium.org/215063005/diff/1/Source/modules/webdatabase/D...
Source/modules/webdatabase/DatabaseManager.h:103: // We can't use
PersistentHeapHashMap because multiple threads update the map.
On 2014/03/28 01:03:24, haraken wrote:
> 
> What's the issue of updating a PersistentHeapHashMap from multiple threads? I
> guess it's safe as long as it's guaranteed that a thread that touches the
> PersistentHeapHashMap does not outlive the thread that created the
> PersistentHeapHashMap.

When the (Persistent)HeapHashMap gets new value and it needs to allocate more
memory for backing, it uses heap for the *current thread*.  Even if the value
was removed from the HeapHashMap and the corresponding thread is dying, the
allocated backing can be still used.  Then the thread heap can't be empty.

[haraken, 2014-03-28 01:30:07]

On 2014/03/28 01:17:25, tkent wrote:
>
https://codereview.chromium.org/215063005/diff/1/Source/modules/webdatabase/D...
> File Source/modules/webdatabase/DatabaseManager.h (right):
> 
>
https://codereview.chromium.org/215063005/diff/1/Source/modules/webdatabase/D...
> Source/modules/webdatabase/DatabaseManager.h:103: // We can't use
> PersistentHeapHashMap because multiple threads update the map.
> On 2014/03/28 01:03:24, haraken wrote:
> > 
> > What's the issue of updating a PersistentHeapHashMap from multiple threads?
I
> > guess it's safe as long as it's guaranteed that a thread that touches the
> > PersistentHeapHashMap does not outlive the thread that created the
> > PersistentHeapHashMap.
> 
> When the (Persistent)HeapHashMap gets new value and it needs to allocate more
> memory for backing, it uses heap for the *current thread*.  Even if the value
> was removed from the HeapHashMap and the corresponding thread is dying, the
> allocated backing can be still used.  Then the thread heap can't be empty.

Understood.

LGTM.

[tkent, 2014-03-28 01:53:04]

The CQ bit was checked by tkent@chromium.org

[commit-bot: I haz the power, 2014-03-28 01:53:16]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/tkent@chromium.org/215063005/1

[commit-bot: I haz the power, 2014-03-28 02:07:06]

Change committed as 170246