Title: [92146] trunk/Source/_javascript_Core
- Revision
- 92146
- Author
- [email protected]
- Date
- 2011-08-01 15:09:24 -0700 (Mon, 01 Aug 2011)
Log Message
REGRESSION(r92092): Build fails on 64 bit
https://bugs.webkit.org/show_bug.cgi?id=65458
Reviewed by Oliver Hunt.
The build was broken because some compilers were smart enough to see
an array index out of bounds due to the decision fuction for when to
go from precise size classes to imprecise size classes being broken:
it would assume that sizes in the range 97..128 belonged to a precise
size class when in fact they belonged to an imprecise one.
In fact, the code would have run correctly, by way of a fluke, because
though the 4th precise size class (for 97..128) didn't exist, the next
array over from m_preciseSizeClasses was m_impreciseSizeClasses, and
its first entry would have been a size class that is appropriate for
allocations in the range 97..128. However, this relies on specific
ordering of fields in NewSpace, so it's still a bug.
This fixes the bug by ensuring that allocations larger than 96 use
the imprecise size classes.
* heap/NewSpace.h:
(JSC::NewSpace::sizeClassFor):
Modified Paths
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (92145 => 92146)
--- trunk/Source/_javascript_Core/ChangeLog 2011-08-01 21:46:52 UTC (rev 92145)
+++ trunk/Source/_javascript_Core/ChangeLog 2011-08-01 22:09:24 UTC (rev 92146)
@@ -1,3 +1,29 @@
+2011-08-01 Filip Pizlo <[email protected]>
+
+ REGRESSION(r92092): Build fails on 64 bit
+ https://bugs.webkit.org/show_bug.cgi?id=65458
+
+ Reviewed by Oliver Hunt.
+
+ The build was broken because some compilers were smart enough to see
+ an array index out of bounds due to the decision fuction for when to
+ go from precise size classes to imprecise size classes being broken:
+ it would assume that sizes in the range 97..128 belonged to a precise
+ size class when in fact they belonged to an imprecise one.
+
+ In fact, the code would have run correctly, by way of a fluke, because
+ though the 4th precise size class (for 97..128) didn't exist, the next
+ array over from m_preciseSizeClasses was m_impreciseSizeClasses, and
+ its first entry would have been a size class that is appropriate for
+ allocations in the range 97..128. However, this relies on specific
+ ordering of fields in NewSpace, so it's still a bug.
+
+ This fixes the bug by ensuring that allocations larger than 96 use
+ the imprecise size classes.
+
+ * heap/NewSpace.h:
+ (JSC::NewSpace::sizeClassFor):
+
2011-07-31 Gavin Barraclough <[email protected]>
https://bugs.webkit.org/show_bug.cgi?id=64679
Modified: trunk/Source/_javascript_Core/heap/NewSpace.h (92145 => 92146)
--- trunk/Source/_javascript_Core/heap/NewSpace.h 2011-08-01 21:46:52 UTC (rev 92145)
+++ trunk/Source/_javascript_Core/heap/NewSpace.h 2011-08-01 22:09:24 UTC (rev 92146)
@@ -81,6 +81,7 @@
// [ 8, 16... 128 )
static const size_t preciseStep = MarkedBlock::atomSize;
static const size_t preciseCutoff = 128;
+ static const size_t maximumPreciseAllocationSize = preciseCutoff - preciseStep;
static const size_t preciseCount = preciseCutoff / preciseStep - 1;
// [ 128, 256... 1024 )
@@ -113,7 +114,7 @@
inline NewSpace::SizeClass& NewSpace::sizeClassFor(size_t bytes)
{
ASSERT(bytes && bytes < maxCellSize);
- if (bytes < preciseCutoff)
+ if (bytes <= maximumPreciseAllocationSize)
return m_preciseSizeClasses[(bytes - 1) / preciseStep];
return m_impreciseSizeClasses[(bytes - 1) / impreciseStep];
}
_______________________________________________
webkit-changes mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-changes
