Bug 113144 – JSC_enableProfiler=true should also cause JSGlobalData to save the profiler output somewhere

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[Filip Pizlo]

It should save it in the current directory by default, but you should be able to set JSC_PROFILER_PATH to have it save it somewhere else.

[Filip Pizlo]

Created attachment 194729 [details]
the patch

[Filip Pizlo]

Created attachment 194730 [details]
the patch

[Build Bot]

Comment on attachment 194730 [details]
the patch

Attachment 194730 [details] did not pass win-ews (win):
Output: http://webkit-commit-queue.appspot.com/results/17139880

[Filip Pizlo]

Created attachment 194736 [details]
the patch

Spell GetCurrentProcessId correctly this time.

[Build Bot]

Comment on attachment 194736 [details]
the patch

Attachment 194736 [details] did not pass win-ews (win):
Output: http://webkit-commit-queue.appspot.com/results/17139892

[Filip Pizlo]

Created attachment 194751 [details]
the patch

another Win fix.

[Filip Pizlo]

Comment on attachment 194751 [details]
the patch

Clearing r? because I need to add some horrible atexit hacks to make this practical. Apparently DRT doesn't delete it's JSGlobalData's.

[Geoffrey Garen]

> Apparently DRT doesn't delete it's JSGlobalData's.

This is really a WebKit issue: WebCore (intentionally) leaks its singleton JSGlobalData.

[Filip Pizlo]

Created attachment 194977 [details]
the patch

Made the atexit() thing work.

[Geoffrey Garen]

Comment on attachment 194977 [details]
the patch

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

r=me

> Source/JavaScriptCore/profiler/ProfilerDatabase.cpp:37
> +static SpinLock registrationLock;

Needs " = SPINLOCK_INITIALIZER;".

[Filip Pizlo]

(In reply to comment #10)
> (From update of attachment 194977 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=194977&action=review
> 
> r=me
> 
> > Source/JavaScriptCore/profiler/ProfilerDatabase.cpp:37
> > +static SpinLock registrationLock;
> 
> Needs " = SPINLOCK_INITIALIZER;".

Will do.

But a question for future reference: isn't it true that on all platforms we care about, globals get initialized to all-zero?  And if that's the case, and SPINLOCK_INITIALIZER is just { 0 }, then can't we just make things simpler and change SpinLock's contract to say that it guarantees that all-zero is a valid unlocked state and that we don't need " = SPINLOCK_INITIALIZER"?

[Geoffrey Garen]

> But a question for future reference: isn't it true that on all platforms we care about, globals get initialized to all-zero?

Yes. That's a part of the C/C++ ABI.

> And if that's the case, and SPINLOCK_INITIALIZER is just { 0 }

For !ENABLE(COMPARE_AND_SWAP) platforms, that's not the case:

TCSpinLock.h:114: #define SPINLOCK_INITIALIZER { PTHREAD_MUTEX_INITIALIZER }
pthread.h:#define PTHREAD_MUTEX_INITIALIZER {_PTHREAD_MUTEX_SIG_init, {0}}
pthread_impl.h:#define _PTHREAD_MUTEX_SIG_init		0x32AAABA7

[Build Bot]

Comment on attachment 194977 [details]
the patch

Attachment 194977 [details] did not pass win-ews (win):
Output: http://webkit-commit-queue.appspot.com/results/17120904

[Filip Pizlo]

Landed in http://trac.webkit.org/changeset/146932