68673 - mac memory allocators need rewrite to be carbon-compliant

Status: RESOLVED WONTFIX

(SeaMonkey :: General, defect, P2)

Description

[Kathleen :Brade]

Not sure who to assign this to or if there is a bug already covering this 
specific issue.  Somebody should grab it.  Please cc others who should know about 
this bug.

From Simon's message:
... because our classic allocators use some heap zone stuff to subdivide temp mem 
handles into zones, they don't work under Carbon. So the carbon build was 
switched to use MSL allocators, which never go to temp mem. So running carbon on 
9 means you'll eventually run out of memory.

I think we'll have to change the carbon build to use our allocators, but fix the 
to be carbon-compliant. That's doable, but means work.

Comment 1

[Conrad Carlen (not reading bugmail)]

What's the relative performance between our own allocator and MSL's? If theirs
is as fast (or faster) we should just use theirs. I imagine it would be really
simple to tweak its raw memory allocator to go to temp mem after some point.

Comment 2

[Mike Pinkerton (not reading bugmail)]

i think ours would be faster since it's tuned for different sized blocks, and i'm 
pretty sure the MSL allocators aren't.

Comment 3

[Simon Fraser [no longer active]]

The problem with MSL's allocators is they don't go to temp mem, so we end up 
running out of memory rather quickly.

Comment 4

[Conrad Carlen (not reading bugmail)]

I'm not saying we use them as-is. We would need to make a slight mod to them to
make them go to temp memory as well. Any memory allocator I've seen always has a
place where it allocates raw blocks from the OS and we could just modify that.

Comment 5

[Simon Fraser [no longer active]]

Conrad: we must try to avoid MSL mods; folks have to be able to build with an 
out-of-the-box CodeWarrior.

Comment 6

[Conrad Carlen (not reading bugmail)]

But don't we build our own whole StdCLibs right now? With most src from CW and
then some of our own mixed in. I'm not suggesting we modify MSL files in place
but do what we do now - have copies of the project in our tree which build
mostly from src in CW.

Comment 7

[Simon Fraser [no longer active]]

*sigh*

Comment 8

[Chris Waterson]

Wanna try doug lea's allocator? kandrot checked it in to the source tree...

Comment 9

[rubydoo123]

P2

Comment 10

[rubydoo123]

moving to mozilla1.0

Comment 11

[Mike Pinkerton (not reading bugmail)]

if we stick with a two-product strategy, this bug can go away as it isn't an 
issue on OSX. 

Comment 12

[Simon Fraser [no longer active]]

But what if an embedder wants Carbon builds to run under Mac OS 9?

Comment 13

[Conrad Carlen (not reading bugmail)]

With CW7, we may be able to ditch our own memory allocator. The implementation
that comes with CW7 is based on a Knuth algorithm and uses fixed size allocators
for small blocks. It claims to perform 50% better than the allocators with
previous versions of CW. Its performance, relative to our own allocator, could
be compared pretty easily. Another advantage of their allocator is that the OS
allocation primitives used to allocate pools are factored out into just two
functions in a separate file. We can just provide implementations of those two
functions which, under OS 9, use temp memory and, under OS X, just call
NewPtr/DisposePtr. We don't have to modify CW files at all because of how
they've factored it.

Comment 14

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 15

[Simon Fraser [no longer active]]

To conrad

Comment 16

[Frankie]

Sorry for the spam. Fizzilla CFM build is dead; should this bug go with it?

Comment 17

[Steve Dagley]

Thanks for the reminder Frankie.  Feel free to comment on any more CFM parrots
you find that don't have toe tags :-)  (With apologies to Monty Python)