Mailing Lists: Apple Mailing Lists

Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Moving Data in Memory Part II



Well, for "historical" mac users, the main difference is between MacOS 9 style processes versus OS X.

On OS9, your process had a spot in memory, and it could change from run to run (specially with vm enabled, where some of the "free" space was allocated dynamically to other cooperative processes, but let's not go too far in the last millenium ).

On OSX, your process lives in its 4 gigs of virtual space on our aging 32 bit systems, and pretty much everything you see that takes place in the process itself is very deterministic in terms of memory allocations. Your stack starts at the same address by convention determined by Apple, as well as the standard heaps used by the malloc subsystem. So no, it is not strange to see behaviors to be near identical across runs, across machines, and in many cases across OS versions. All due to the nice shielding of the virtual address space.

However, any process with a UI typically gets a good randomization for memory allocation, even with only the raw allocations done by the underlying frameworks (Cocoa, Carbon, you name it) that happen to live in user space.

Ludo



On Vendredi, octo 22, 2004, at 22:04 Canada/Eastern, David Duncan wrote:

On Oct 22, 2004, at 09:45 PM, Gohara, David wrote:

  Thanks for the responses.  It would appear that it is indeed a case of malloc.  One thing I noticed and I've never done the test before is that the same code compiled on a different machine gives me the exact same memory addresses.  For example, if I compile and run the code on my G4 laptop or G5 desktop.  How can that be?  I may be misunderstanding something with regards to memory addresses but shouldn't it be very unlikely for memory allocations to be identical on two different machines?

As long as the machine code that is run is the same (same gcc version and compiler flags, same source, etc) then there is no reason for anything to change. After all, malloc() an algorithm to allocate memory -- it would be very strange indeed if it produced different results on the same (machine) code with the same starting point.
--
Reality is what, when you stop believing in it, doesn't go away.
Failure is not an option. It is a privilege reserved for those who try.


David Duncan

_______________________________________________ Do not post admin requests to the list. They will be ignored. PerfOptimization-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/perfoptimization-dev/email@hidden

This email sent to email@hidden
References: 
 >Re: Moving Data in Memory Part II (From: David Duncan <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.