From: Godmar Back (gback@cs.utah.edu)
Date: Mon Dec 21 1998 - 00:50:53 EST
>
> Godmar Back writes:
> > About names:
> >
> > How about instead of this:
>
> I am not at all passionate about the naming convention. I was just
> trying to impose a little order on what seemed to me a rather
> haphazard comglomeration of names and delcarations scattered
> throughout various *.c and *.h files.. Please go ahead and change
> the names if you want. I think your scheme is a little clearer.
>
Actually, I'll be leaving tomorrow for a 9-day holiday vacation.
I won't do any kaffe hacking until then. So, if you indeed like
it better, could you do that name change?
> > So, can you describe in one paragraph or less what the purpose of
> > these fake utf8Const is?
>
> The idea is this: if you are going to create something, and then
> check if it's already interned, and if so then throw it away and use
> the already interned version, then using a "fake" version avoids
> allocating a chunk of memory that is immediately forgotten (and
> thus puts unnecessary work to the GC).
>
Yeah, the problem is in the layout of strconst:
struct _strconst {
uint32 hash
uint16 len;
char data[1]
}
if that were
struct _strconst {
uint32 hash
uint16 len;
char *dataptr;
char data[1]
}
instead, where you follow dataptr to get to the data, you would not
need extra coding for fakes in compare (hash should be precomputed
anyway). Moreover, you could use the len for a quick reject in the
compare function.
So, the price to pay would be one word. Comp would be:
comp(a, b) {
if (a->len != b->len)
return 0;
return (strcmp(a->dataptr, b->dataptr));
}
fake would then be used like so:
utf8ConstNew(char s, int len)
{
strconst fake;
/* set fake.hash and fake. len ---
do this in one function so we don't touch stuff twice */
computehash_and_length(&fake, s, len)
fake.dataptr = s;
if (it = hashFind(&fake))
return it
u = gcMalloc
u.hash = fake.hash
memcpy(s to u.data)
u.dataptr = &u.data
hashAdd(u)
return u;
}
This would save all the if len = 1 && data[0] == 0 checks.
- Godmar
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:26 EDT