summaryrefslogtreecommitdiffstats
path: root/base/process_util_unittest_mac.mm
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/process_util_unittest_mac.mm
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/process_util_unittest_mac.mm')
-rw-r--r--base/process_util_unittest_mac.mm39
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