Remove unused class/includes for DeviceLight after r175792

Review URL: https://codereview.chromium.org/393023009

git-svn-id: svn://svn.chromium.org/blink/trunk@178349 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Do not specify language for font fallback

Providing the default locale as language when searching for
a fallback font does not improve results.

BUG=392724
R=eae,eseidel,abarth

Review URL: https://codereview.chromium.org/381893002

git-svn-id: svn://svn.chromium.org/blink/trunk@178350 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Enable ScriptForbiddenScope in release builds

In order to make sure that we don't execute a script where script execution is forbidden, it is important to get a stack trace of the exact code path that violates the condition in release builds. Then we can fix the code path.

I want to make this change because recently I've observed a couple of crashes probably caused by a script being executed in a ScriptForbiddenScope (e.g., weak callback of V8 GC, weak processing of Oilpan GC).

BUG=389445

Review URL: https://codereview.chromium.org/381493003

git-svn-id: svn://svn.chromium.org/blink/trunk@178351 bbb929c8-8fbe-4397-9dbb-9b2b20218538
[oilpan]: fix for bug 393834.

The issue is because I don't take the threadAttachMutex while doing thread local GCs. When doing marking we have debug asserts that check we are not marking objects that are not in the heap pages. This assert iterates over our threadAttachedSet which can be modified during the thread local GC, ie. a new thread can attach itself or another thread that just did shutdown could remove itself.

This means that we could be iterating a set while it is being modified. To avoid this I have changed the thread local GC to take the threadAttachMutex rather than use a new threadShutdownMutex in debug builds. This ensures no other threads are added/removed in debug.

I am still undecided whether patch 1 or 2 is the best approach. The latter is still a bit fragile since it relies on attachedThreads set not being iterated in release builds. Also the threadedWeakness test should ideally not assume that the GC succeeded and collected any garbage since it could be busy (as it is in this case).

R=ager@chromium.org, erik.corry@gmail.com, haraken@chromium.org, oilpan-reviews@chromium.org, tkent@chromium.org, vegorov@chromium.org, zerny@chromium.org
BUG=393834

Review URL: https://codereview.chromium.org/396213003

git-svn-id: svn://svn.chromium.org/blink/trunk@178352 bbb929c8-8fbe-4397-9dbb-9b2b20218538