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/process_util_unittest_mac.mm | |
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/process_util_unittest_mac.mm')
-rw-r--r-- | base/process_util_unittest_mac.mm | 39 |
1 files changed, 28 insertions, 11 deletions
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 |