Bug 122352

Summary: [Win] Turn off FastMalloc on Windows
Product: WebKit Reporter: Brent Fulgham <bfulgham>
Component: WebCore Misc.Assignee: Brent Fulgham <bfulgham>
Status: RESOLVED FIXED    
Severity: Normal CC: benjamin, cmarcelo, commit-queue, ggaren, gyuyoung.kim, ossy, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: PC   
OS: All   
Attachments:
Description Flags
Patch darin: review+

Brent Fulgham
Reported 2013-10-04 15:03:44 PDT
There are a number of test crashes on the Windows platform that seem to be caused by the FastMalloc implementation. As one would expect, these are tied to mismatched new/free pairs, and seem to be related to the visibility of the FastMalloc overloads in template expansions, and perhaps when data is allocated and deallocated across shared library boundaries. If I force use of the system allocator, these crashes go away. I cannot measure the performance penalty this might introduce, because we do not currently track Windows performance. However, there does not seem to be a noticeable change in using the MiniBrowser with the system allocator activated. Perhaps I am not using test cases that create/destroy enough memory for this to be noticeable. I would like to do the following: 1. Turn off FastMalloc on the Windows platform. 2. Reactivate the various tests that currently fail due to issues with the allocator. 3. Get a performance bot running 4. Port ggaren’s new allocator to run on Windows, but only use it if we see no change in stability.
Attachments
Patch (958 bytes, patch)
2013-10-04 17:06 PDT, Brent Fulgham
darin: review+
Brent Fulgham
Comment 1 2013-10-04 17:06:37 PDT
Brent Fulgham
Comment 2 2013-10-04 17:33:55 PDT
Radar WebKit Bug Importer
Comment 3 2013-10-25 11:51:57 PDT
Csaba Osztrogonác
Comment 4 2015-02-13 06:14:28 PST
(In reply to comment #0) > There are a number of test crashes on the Windows platform that seem to be > caused by the FastMalloc implementation. As one would expect, these are tied > to mismatched new/free pairs, and seem to be related to the visibility of > the FastMalloc overloads in template expansions, and perhaps when data is > allocated and deallocated across shared library boundaries. > > If I force use of the system allocator, these crashes go away. > > I cannot measure the performance penalty this might introduce, because we do > not currently track Windows performance. However, there does not seem to be > a noticeable change in using the MiniBrowser with the system allocator > activated. Perhaps I am not using test cases that create/destroy enough > memory for this to be noticeable. > > I would like to do the following: > > 1. Turn off FastMalloc on the Windows platform. > 2. Reactivate the various tests that currently fail due to issues with the > allocator. > 3. Get a performance bot running > 4. Port ggaren’s new allocator to run on Windows, but only use it if we see > no change in stability. Is there any plan to switch the Windows port to bmalloc too in the near future?
Note You need to log in before you can comment on or make changes to this bug.