diff options
author | mark@chromium.org <mark@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2010-05-14 15:43:00 +0000 |
---|---|---|
committer | mark@chromium.org <mark@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2010-05-14 15:43:00 +0000 |
commit | 0281161c09660b9ea12337e6ea91d14a0a0c4e6d (patch) | |
tree | 18a1b7ca965c034c7f19dde3af15021cc7826e92 /base | |
parent | d15012168dcf10d9a1493c902df4fd2215cb5cb3 (diff) | |
download | chromium_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.cc | 12 | ||||
-rw-r--r-- | base/process_util_unittest_mac.h | 14 | ||||
-rw-r--r-- | base/process_util_unittest_mac.mm | 39 |
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 |