[Webkit-unassigned] [Bug 126703] Fix alignment in data section allocator.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=126703





--- Comment #4 from Filip Pizlo <fpizlo at apple.com>  2014-01-10 22:25:48 PST ---
(In reply to comment #3)
> I got into this one when trying to allocate with alignment of 16. In this case, both the old, and the suggested new version allocates 2 LSectionWords, so in this case the code works OK, but the assertion is triggered.

Right, because there is no guarantee that the returned pointer is actually 16 byte aligned. That's what the assertion is asserting. It has nothing to do with allocation size. 

> 
> But, suppose we wanted to allocate 15 or 17 with alignment of 16.
> 
> In case of 15, both calculations yield 2 LSectionWords, which is good, but in case of 17, the old one yields 3 LSectionWords, which is not aligned to 16, but the suggested new calculation yields 4 LSectionWords which is the correct version I think.

Nobody castes if you allocate the right number of section words. The relevant part is the alignment of the returned pointer.

> 
> It can't see why the new code "fails to align allocations to the requested alignment except if that alignment is LSectionWord". Can you please explain this, or give an example?

Do you understand how memory allocation works?  The OS allocator, or the language allocator like C++ "new", will provide a hard guarantee that the returned pointer is aligned to some machine word amount. We conservatively assume that it's sizeof(LSectionWord). The OS allocator isn't going to magically align allocations to the thing that LLVM wanted via the "alignment" parameter. We just asset that LLVM will never ask for alignment greater than sizeof(LSectionWord), which is true on Darwin.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.