Bug 41072
| Summary: | Remove the JSLock when JSC_MULTIPLE_THREADS is disabled | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Yi Shen <max.hong.shen> |
| Component: | JavaScriptCore | Assignee: | Nobody <webkit-unassigned> |
| Status: | UNCONFIRMED | ||
| Severity: | Minor | CC: | ap, laszlo.gombos, loki, zherczeg |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | All | ||
| OS: | All | ||
Yi Shen
For some platform like Symbian, on which the JSC_MULTIPLE_THREADS is disabled, the implementation of JSLock is empty. While the JSLock are used very often in JavaScriptcall, for example,
void JSEventListener::handleEvent(...) {
...
JSLock lock(SilenceAssertionsOnly);
...
}
We can remove this kind of useless JSLock by using macro like following, to improve the performance and battery life for the mobile device (especially for the webkit-based widget which may keep running javascript all the time).
void JSEventListener::handleEvent(...) {
...
#if ENABLE(JSC_MULTIPLE_THREADS)
JSLock lock(SilenceAssertionsOnly);
#endif
...
}
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Mark Rowe (bdash)
If’ing every use of JSLock would be incredibly ugly. If the implementation of JSLock when JSC_MULTIPLE_THREADS is not defined is empty and defined inline in a header any decent compiler will completely optimize this code away. That’s a much cleaner solution than touching every single place that JSlock is used.
Yi Shen
Yes, I am totally agree with you Mark. But these empty JSLock functions are not defined inline in header file, right?
Mark Rowe (bdash)
So instead of changing to code to inline the functions your proposal is to #if all of the callsites? Why not just inline the functions?!
Yi Shen
Yes, I can change it to inline if you think it is necessary :)
Laszlo Gombos
Let's check the assembly generated by RVCT/GCC before we change the source.