This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [boehms-gc] support for cache hash tables (gt_ggc_cache_rtab)
- From: Tom Tromey <tromey at redhat dot com>
- To: Laurynas Biveinis <laurynas dot biveinis at gmail dot com>
- Cc: Gcc Patch List <gcc-patches at gcc dot gnu dot org>
- Date: 02 Aug 2006 15:17:15 -0600
- Subject: Re: [boehms-gc] support for cache hash tables (gt_ggc_cache_rtab)
- References: <d1e3ff2b0607150815i5cb78e54oc702477d72c4a2a8@mail.gmail.com>
- Reply-to: tromey at redhat dot com
>>>>> "Laurynas" == Laurynas Biveinis <laurynas.biveinis@gmail.com> writes:
Laurynas> If the objects pointed to by them are collected, they are
Laurynas> automatically set to NULL by the collector, which looks like
Laurynas> HTAB_EMPTY_ENTRY to others. By comparison, current
Laurynas> collectors set them to HTAB_DELETED_ENTRY, is this
Laurynas> difference important, or just for statistics?
The general idea is that you don't want to re-hash all the entries in
a hash table when one entry is deleted. But, if you mark a deleted
entry as "empty", then future searches may stop there instead of
proceeding on to find the real entry.
So, it matters quite a bit.
I only skimmed hashtab.c. But, this is a pretty ordinary way to
implement hash tables, and by my reading hashtab.c does it this way as
well.
Tom