From mboxrd@z Thu Jan  1 00:00:00 1970
References: <10C19402-24DC-4B30-AD02-F83E12362D5D@gmail.com>
	<D0163309-3424-49C5-ABF6-33A58FFD2241@gmail.com>
From: Steve Simon <steve@quintile.net>
Content-Type: text/plain;
	charset=utf-8
In-Reply-To: <D0163309-3424-49C5-ABF6-33A58FFD2241@gmail.com>
Message-Id: <55207B39-493A-4EDC-A246-2C838197D8F0@quintile.net>
Date: Wed, 10 Dec 2014 01:35:38 +0000
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Subject: Re: [9fans] memory bug in 5l
Topicbox-Message-UUID: 36042cbc-ead9-11e9-9d60-3106f5b1d025

the compilers use a very simple allocator which is designed for speed
rather than efficiency - as i remember it never frees anything and just
allocates from a heap.

it also works if you use libc's malloc and that will allow you to link big t=
hings
(like gs) on small memory machines. in reality memory is cheap and no one
likes to wait when they don't have to.

-Steve



> On 10 Dec 2014, at 00:24, yoann padioleau <aryx.padator@gmail.com> wrote:
>=20
> Also, by curiosity, does anybody know why 5a/, 5l/, 5c/
> (and the other architecture variants) are redefining
> malloc and free? Why not using the malloc and free
> from the libc?
>=20
>=20
>> On Dec 9, 2014, at 4:21 PM, yoann padioleau <aryx.padator@gmail.com> wrot=
e:
>>=20
>> in 5l/obj.c#zaddr()
>> there is:
>>   case D_FCONST:
>>       while(nhunk < sizeof(Ieee))
>>           gethunk();
>>       a->ieee =3D (Ieee*)hunk;
>>       nhunk -=3D NSNAME;
>>       hunk +=3D NSNAME;
>>=20
>> I think it=E2=80=99s a copy paste bug, it should
>> be sizeof(Ieee) instead of those NSNAME
>> (or even better the whole code could be factorized
>> in a call to a->ieee =3D malloc(sizeof(Ieee));
>=20