InstanceCounter/Oilpan GC tracing: Add clang support

InstanceCounter/Oilpan GC tracing: Add clang support

This CL fixes two issues:
- Add clang support for InstanceCounter type resolver
- Add a mutex when writing to objectgraph map.
-- Oilpan GC marking phase is only run on single thread, however, weak processing are not.
-- Heap wtf collection implementations may mark their back store on weak processing phase.

BUG=378157
NOTRY=true

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

[kouhei (in TOK), 2014-05-29 03:29:11]

I'm trying to add mac clang support too. I'd appreciate if you would try to run
GC_TRACING with const size_t extractNameFunctionPrefixLength = 0; and paste its
result.

[tkent, 2014-05-29 04:03:52]

On 2014/05/29 03:29:11, kouhei wrote:
> I'm trying to add mac clang support too. I'd appreciate if you would try to
run
> GC_TRACING with const size_t extractNameFunctionPrefixLength = 0; and paste
its
> result.

On OSX 10.9  + clang


With Patch Set 1 as is:
Showed the following, then an assertion failed.

---------- AFTER MARKING -------------------
WebCore::DeviceLightController 2
WebCore::RuleSet::PendingRuleMaps 1
WebCore::AbstractWorker 30
WebCore::ContextFeatures 2
WebCore::CSSFontSelectorClient 1
WebCore::GeolocationController 1
WebCore::StyleSheetCollection 2
.....

ASSERTION FAILED: !hasHash()

With Patch Set 1 + extractNameFunctionPrefixLength=0:
Showed the following, then an assertion failed.

---------- AFTER MARKING -------------------
WebCore::NavigatorGamepad] 1
blink::ContextFeaturesCache] 1
WebCore::StyleRuleBase] 181
WebCore::HeapTerminatedArray<WebCore::RuleData>] 185
....

ASSERTION FAILED: !hasHash()

[kouhei (in TOK), 2014-05-29 04:05:56]

Thanks. Then the mac failure seems to be from other reason.

Would you post stack trace of ASSERTION FAILED: !hasHash()?

[tkent, 2014-05-29 04:09:57]

On 2014/05/29 04:05:56, kouhei wrote:
> Would you post stack trace of ASSERTION FAILED: !hasHash()?

Here it is: https://code.google.com/p/chromium/issues/detail?id=378157#c3

[kouhei (in TOK), 2014-05-29 05:40:24]

On 2014/05/29 04:09:57, tkent wrote:
> On 2014/05/29 04:05:56, kouhei wrote:
> > Would you post stack trace of ASSERTION FAILED: !hasHash()?
> 
> Here it is: https://code.google.com/p/chromium/issues/detail?id=378157#c3

Would you test patch set2 would fix? I can't repro consistently, but I haven't
seen the assert hit since patchset2

[tkent, 2014-05-29 12:42:59]

> Would you test patch set2 would fix? I can't repro consistently, but I haven't
> seen the assert hit since patchset2

It worked on OSX.  Thanks!

[tkent, 2014-05-29 12:43:05]

lgtm

https://codereview.chromium.org/304033004/diff/20001/Source/platform/heap/Hea...
File Source/platform/heap/Heap.cpp (right):

https://codereview.chromium.org/304033004/diff/20001/Source/platform/heap/Hea...
Source/platform/heap/Heap.cpp:1475: AtomicallyInitializedStatic(Mutex&, mutex =
*new Mutex);
This looks unnatural.
Does the following work?
    AtomicallyInitializedStatic(Mutex, mutex);

[kouhei (in TOK), 2014-05-30 01:20:58]

On 2014/05/29 12:43:05, tkent wrote:
> lgtm
> 
>
https://codereview.chromium.org/304033004/diff/20001/Source/platform/heap/Hea...
> File Source/platform/heap/Heap.cpp (right):
> 
>
https://codereview.chromium.org/304033004/diff/20001/Source/platform/heap/Hea...
> Source/platform/heap/Heap.cpp:1475: AtomicallyInitializedStatic(Mutex&, mutex
=
> *new Mutex);
> This looks unnatural.
> Does the following work?
>     AtomicallyInitializedStatic(Mutex, mutex);

This didn't work. It seems that this is the way to statically initialize mutex
regarding other usage?
https://code.google.com/p/chromium/codesearch#search/&q=AtomicallyInitialized...

[kouhei (in TOK), 2014-05-30 01:23:11]

The CQ bit was checked by kouhei@chromium.org

[commit-bot: I haz the power, 2014-05-30 01:24:30]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/kouhei@chromium.org/304033004/20001

[commit-bot: I haz the power, 2014-05-30 01:25:23]

Change committed as 175092