122352 2013-10-04 15:03:44 -0700 [Win] Turn off FastMalloc on Windows 2015-07-30 21:00:23 -0700 1 1 1 Unclassified WebKit WebCore Misc. 528+ (Nightly build) PC All RESOLVED FIXED InRadar P2 Normal --- 1 bfulgham bfulgham benjamin cmarcelo commit-queue ggaren gyuyoung.kim ossy webkit-bug-importer oldest_to_newest 936386 0 bfulgham 2013-10-04 15:03:44 -0700 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. 936434 1 213420 bfulgham 2013-10-04 17:06:37 -0700 Created attachment 213420 Patch 936454 2 bfulgham 2013-10-04 17:33:55 -0700 Committed r156933: <http://trac.webkit.org/changeset/156933> 943686 3 webkit-bug-importer 2013-10-25 11:51:57 -0700 <rdar://problem/15321791> 1068896 4 ossy 2015-02-13 06:14:28 -0800 (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? 213420 2013-10-04 17:06:37 -0700 2013-10-04 17:15:15 -0700 Patch bug-122352-20131004170636.patch text/plain 958 bfulgham SW5kZXg6IFNvdXJjZS9XVEYvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFNvdXJjZS9XVEYvQ2hh bmdlTG9nCShyZXZpc2lvbiAxNTY5MjkpCisrKyBTb3VyY2UvV1RGL0NoYW5nZUxvZwkod29ya2lu ZyBjb3B5KQpAQCAtMSwzICsxLDEzIEBACisyMDEzLTEwLTA0ICBCcmVudCBGdWxnaGFtICA8YmZ1 bGdoYW1AYXBwbGUuY29tPgorCisgICAgICAgIFtXaW5dIFR1cm4gb2ZmIEZhc3RNYWxsb2Mgb24g V2luZG93cworICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9 MTIyMzUyCisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAg KiB3dGYvUGxhdGZvcm0uaDogRW5hYmxlIFVTRV9TWVNURU1fTUFMTE9DIHdoZW4gYnVpbGRpbmcg b24KKyAgICAgICAgV2luZG93cyB0byBzdGljayB0byB0aGUgTVNWQ1JUIGFsbG9jYXRvci9kZWFs bG9jYXRvci4KKwogMjAxMy0xMC0wNCAgT2xpdmVyIEh1bnQgIDxvbGl2ZXJAYXBwbGUuY29tPgog CiAgICAgICAgIFN1cHBvcnQgZm9yLW9mIHN5bnRheApJbmRleDogU291cmNlL1dURi93dGYvUGxh dGZvcm0uaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV1RGL3d0Zi9QbGF0Zm9ybS5oCShyZXZpc2lv biAxNTY5MTcpCisrKyBTb3VyY2UvV1RGL3d0Zi9QbGF0Zm9ybS5oCSh3b3JraW5nIGNvcHkpCkBA IC02NTcsNiArNjU3LDcgQEAKIAogI2lmIE9TKFdJTkRPV1MpCiAjZGVmaW5lIEVOQUJMRV9HTE9C QUxfRkFTVE1BTExPQ19ORVcgMAorI2RlZmluZSBVU0VfU1lTVEVNX01BTExPQyAxCiAjZW5kaWYK IAogI2lmICFkZWZpbmVkKEVOQUJMRV9HTE9CQUxfRkFTVE1BTExPQ19ORVcpCg==