summaryrefslogtreecommitdiffstats
path: root/base
diff options
context:
space:
mode:
authormark@chromium.org <mark@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2010-05-14 15:43:00 +0000
committermark@chromium.org <mark@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2010-05-14 15:43:00 +0000
commit0281161c09660b9ea12337e6ea91d14a0a0c4e6d (patch)
tree18a1b7ca965c034c7f19dde3af15021cc7826e92 /base
parentd15012168dcf10d9a1493c902df4fd2215cb5cb3 (diff)
downloadchromium_src-0281161c09660b9ea12337e6ea91d14a0a0c4e6d.zip
chromium_src-0281161c09660b9ea12337e6ea91d14a0a0c4e6d.tar.gz
chromium_src-0281161c09660b9ea12337e6ea91d14a0a0c4e6d.tar.bz2
64-bit support for Mac OS X in base_unittests.
BUG=44127, 18323 TEST=64-bit base_unittests should all pass Review URL: http://codereview.chromium.org/2126001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@47275 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'base')
-rw-r--r--base/process_util_unittest.cc12
-rw-r--r--base/process_util_unittest_mac.h14
-rw-r--r--base/process_util_unittest_mac.mm39
3 files changed, 49 insertions, 16 deletions
diff --git a/base/process_util_unittest.cc b/base/process_util_unittest.cc
index 9c4aa5d..d58db37 100644
--- a/base/process_util_unittest.cc
+++ b/base/process_util_unittest.cc
@@ -630,7 +630,11 @@ TEST_F(OutOfMemoryTest, Posix_memalign) {
#if defined(OS_MACOSX)
// Since these allocation functions take a signed size, it's possible that
-// calling them just once won't be enough to exhaust memory.
+// calling them just once won't be enough to exhaust memory. In the 32-bit
+// environment, it's likely that these allocation attempts will fail because
+// not enough contiguous address space is availble. In the 64-bit environment,
+// it's likely that they'll fail because they would require a preposterous
+// amount of (virtual) memory.
TEST_F(OutOfMemoryTest, CFAllocatorSystemDefault) {
ASSERT_DEATH(while ((value_ =
@@ -647,11 +651,17 @@ TEST_F(OutOfMemoryTest, CFAllocatorMallocZone) {
base::AllocateViaCFAllocatorMallocZone(signed_test_size_))) {}, "");
}
+#if !defined(ARCH_CPU_64_BITS)
+
+// See process_util_unittest_mac.mm for an explanation of why this test isn't
+// run in the 64-bit environment.
+
TEST_F(OutOfMemoryTest, PsychoticallyBigObjCObject) {
ASSERT_DEATH(while ((value_ =
base::AllocatePsychoticallyBigObjCObject())) {}, "");
}
+#endif // !ARCH_CPU_64_BITS
#endif // OS_MACOSX
#endif // !defined(OS_WIN)
diff --git a/base/process_util_unittest_mac.h b/base/process_util_unittest_mac.h
index 8402e85..7b4fe1c 100644
--- a/base/process_util_unittest_mac.h
+++ b/base/process_util_unittest_mac.h
@@ -14,13 +14,19 @@ namespace base {
// Allocates memory via system allocators. Alas, they take a _signed_ size for
// allocation.
-void* AllocateViaCFAllocatorSystemDefault(int32 size);
-void* AllocateViaCFAllocatorMalloc(int32 size);
-void* AllocateViaCFAllocatorMallocZone(int32 size);
+void* AllocateViaCFAllocatorSystemDefault(ssize_t size);
+void* AllocateViaCFAllocatorMalloc(ssize_t size);
+void* AllocateViaCFAllocatorMallocZone(ssize_t size);
+
+#if !defined(ARCH_CPU_64_BITS)
+// See process_util_unittest_mac.mm for an explanation of why this function
+// isn't implemented for the 64-bit environment.
// Allocates a huge Objective C object.
void* AllocatePsychoticallyBigObjCObject();
-} // namespace base
+#endif // !ARCH_CPU_64_BITS
+
+} // namespace base
#endif // BASE_PROCESS_UTIL_UNITTEST_MAC_H_
diff --git a/base/process_util_unittest_mac.mm b/base/process_util_unittest_mac.mm
index 3cd7e16..2ef1868 100644
--- a/base/process_util_unittest_mac.mm
+++ b/base/process_util_unittest_mac.mm
@@ -4,13 +4,25 @@
#include "base/process_util_unittest_mac.h"
-#import <Cocoa/Cocoa.h>
+#import <Foundation/Foundation.h>
+#include <CoreFoundation/CoreFoundation.h>
+
+#if !defined(ARCH_CPU_64_BITS)
+
+// In the 64-bit environment, the Objective-C 2.0 Runtime Reference states
+// that sizeof(anInstance) is constrained to 32 bits. That's not necessarily
+// "psychotically big" and in fact a 64-bit program is expected to be able to
+// successfully allocate an object that large, likely reserving a good deal of
+// swap space. The only way to test the behavior of memory exhaustion for
+// Objective-C allocation in this environment would be to loop over allocation
+// of these large objects, but that would slowly consume all available memory
+// and cause swap file proliferation. That's bad, so this behavior isn't
+// tested in the 64-bit environment.
@interface PsychoticallyBigObjCObject : NSObject
{
- // On 32 bits, the compiler limits Objective C objects to < 2G in size, and on
- // 64 bits, the ObjC2 Runtime Reference says that sizeof(anInstance) is
- // constrained to 32 bits. Keep it < 2G for simplicity.
+ // In the 32-bit environment, the compiler limits Objective-C objects to
+ // < 2GB in size.
int justUnder2Gigs_[(2U * 1024 * 1024 * 1024 - 1) / sizeof(int)];
}
@@ -20,23 +32,28 @@
@end
+namespace base {
+
+void* AllocatePsychoticallyBigObjCObject() {
+ return [[PsychoticallyBigObjCObject alloc] init];
+}
+
+} // namespace base
+
+#endif // ARCH_CPU_64_BITS
namespace base {
-void* AllocateViaCFAllocatorSystemDefault(int32 size) {
+void* AllocateViaCFAllocatorSystemDefault(ssize_t size) {
return CFAllocatorAllocate(kCFAllocatorSystemDefault, size, 0);
}
-void* AllocateViaCFAllocatorMalloc(int32 size) {
+void* AllocateViaCFAllocatorMalloc(ssize_t size) {
return CFAllocatorAllocate(kCFAllocatorMalloc, size, 0);
}
-void* AllocateViaCFAllocatorMallocZone(int32 size) {
+void* AllocateViaCFAllocatorMallocZone(ssize_t size) {
return CFAllocatorAllocate(kCFAllocatorMallocZone, size, 0);
}
-void* AllocatePsychoticallyBigObjCObject() {
- return [[PsychoticallyBigObjCObject alloc] init];
-}
-
} // namespace base