Closed GoogleCodeExporter closed 9 years ago
Looks good. Certainly makes sense to minimize internal fragmentation for
systems that don't need the additional alignment. I don't think that we want to
provide an API call for allowing user specified alignment though. The alignment
is mandated by the target platform and not on a case by case basis.
Original comment by chapp...@gmail.com
on 15 May 2012 at 1:33
Original comment by chapp...@gmail.com
on 15 May 2012 at 1:33
Do you have plans to include this in one or other way in the next release?
>> I don't think that we want to provide an API call for allowing user specified
>> alignment though. The alignment is mandated by the target platform and
>> not on a case by case basis.
The statement above seems to be based on the assumption that we plan to give
the responsibility for alignment requirements to the programmer, which is not
at all our intent. In our case (Ada technology) the COMPILER has calculated the
alignment requirements and has generated a call to the allocator function
specifying both size and alignment requirements. For a different target
platform it will generate (possibly) different values.
To compare with C technology you might imagine that one day gcc implements
alignmentof(X), just like it implements today sizeof(X), such that in this
hypothetical future a programmer could call a function aligned_tcmalloc
(sizeof(X), alignmentof(X)) and this way avoid aligning everything to 8 bytes.
This would be open to abuse, if a programmer hard-codes the second parameter
this would create non-portable code, just like a programmer calling malloc with
a hard-coded size parameter. A fool-proof heap interface is not feasible
(without paying for garbage collection), there are many ways to shoot yourself
in the foot. The programmer's mistakes are a job for valgrind.
Size and alignment requirements are both "known" to gcc, regardless of the
programming language, as they are needed to properly allocate variables on the
stack or components in a struct. The only difference is that in C, size was
made visible via the sizeof() construct (as otherwise calling malloc would be a
nightmare), while alignment was not made visible (only because it creates less
of a nightmare, wasting up to 15 bytes per object is not a catastrophy).
For a large mission-critical system memory efficiency represents a significant
development cost, and wasting memory represents a significant cost, so the fact
that people created a wasteful design in the past based on "not a catastrophy",
is not a reasonable justification to continue the waste.
We hope the above is a better justfication for adding alignment support to the
heap API.
Original comment by koen.mee...@gmail.com
on 13 Jul 2012 at 7:15
I think your argument has many good points that would justify this API
addition. It should make the next release.
Original comment by chapp...@gmail.com
on 24 Jul 2012 at 4:04
r175 | chappedm@gmail.com | 2012-11-04 13:15:11 -0500 (Sun, 04 Nov 2012) | 2
lines
issue-430: Introduces 8-byte alignment support for tcmalloc
Original comment by chapp...@gmail.com
on 4 Nov 2012 at 6:16
Original issue reported on code.google.com by
koen.mee...@gmail.com
on 14 May 2012 at 7:33Attachments: