Author: admin

Innodb is full of crap

Innodb code is full of crap. All across the source base it pretends that it can do multiple log groups. But it always initializes only one. And sometimes at random places it acknowledges this fact. There is a case of this schizophrenia within single function. In file log0log.c, function log_write_up_to(), we see the code with this comment:

group = UT_LIST_GET_FIRST(log_sys->log_groups);
        group->n_pending_writes++;      /*!< We assume here that we have only
                                        one log group! */

Then a few lines below we see iteration over the list of groups.

group = UT_LIST_GET_FIRST(log_sys->log_groups);
        /* Do the write to the log files */
        while (group) {
                <...>
                group = UT_LIST_GET_NEXT(log_groups, group);
        }

Why iterate over the list that always has only one member? Why have this list at all, why it’s not direct pointer to the log group? Who needs multiple log groups that never are? Even more interesting is that there is a large part of log-related code that stays there but is disabled with #ifdefs. This is the code for something called log archives. The related configuration options are documented like this:

  • innodb_log_arch_dir
    This variable is unused, and is deprecated as of MySQL 5.0.24. It is removed in MySQL 5.1
  • innodb_log_archive
    Whether to log InnoDB archive files. This variable is present for historical reasons, but is unused. Recovery from a backup is done by MySQL using its own log files, so there is no need to archive InnoDB log files. The default for this variable is 0.

Almost half (albeit disabled) of 3500+ lines of log0log.c file from MySQL 5.1 still deal with these log archives. And this code is still there in MySQL 5.5. Is there anybody who needs it?

The same is for support for some ancient checksum algorithms. I guess the Innodb files with these checksums if still can be found then it’s only on certain spacious 40MB hard-drives that collect dust in some abandoned garage in Finland.

And let’s not forget that wonderful uber-portable 64-bit arithmetic with the help of macros. Yes, it makes the code so readable. I just like to learn what are the current target platforms where there is no compiler available with “long long” or “int64_t” arithmetic? I believe that in year 2011 we could already think of 32-bit arithmetic as something special and 64-bit as the default.

All in all, with all the effort to scale up MySQL to high-end servers why not start cleaning up the mess already?

Tinkering with web design

I made a few changes to my web pages.

– Finally updated info on the libjit page about getting libjit sources from the git repository
– Removed wordpress blog that I never really used and that only was a target for spammers and linked this blog my static pages
– Modified style sheet for my static pages to use analogous color scheme
– Tinkered with the blog template to make it similar to my static pages

My initial style sheet used colors that I chose semi-randomly. I just put in some hex value with digits that looked good for me, then looked at the page in the browser and tried again until I more or less liked it. Time passed and I realized that my color choice was awful. I bothered to read about color schemes and went on with free online tool Adobe Kuler to create my new scheme. Immediately I liked the look of my site much better. Perhaps even with new colors I still will be a laughing stock for people more sensitive to design. I never was one, sorry. But right now I’m happy with my colors.

On the other hand I’m not completely happy with blogspot page template that I got. There are still some glitches. However I fixed the most irritating thing for me personally. I like to maximize my browser window to see at once as much of a page content as possible. But the width of the content area is too small in the default Blogger.com theme, it occupies but a narrow stripe in the middle of the window. I converted the template to elastic design that I use with my static pages and so the text now utilizes much more window space. For me this is a big win.

Back to libjit hacking

Right now I have more free time than I had during last 2 years so perhaps I will be able to contribute something new to libjit.

Currently I’m trying to improve libjit memory management. There is a proposed patch for pluggable memory allocator from Patrick van Beem (http://savannah.gnu.org/patch/?7237). I fully recognize the need for some applications to perform custom memory allocation. However I would like to have more elaborate solution for this problem than that found in the provided patch. First of all, libjit’s own memory manager (jit/jit-cache.[hc]) is not so good. For instance, the way it allocates function redirectors may result in memory leaks. The patch supposedly resolves this problem but only if pluggable memory manager supports some¬†extra¬†feature not available for libjit default manager. This is clearly not how it should be done. The leak should be fixed in the way not dependent on which memory manager is used.

So I try to find appropriate solution that would fix this problem for all libjit users whereas Patrick’s patch keeps libjit logic mostly intact and “solves” the problem by letting third-party allocator do something that normal libjit users will not have ability to do.

Another thing to consider is that libjit allocates code space in relatively small chunks. If at the compile time libjit figures that the code for a function doesn’t fit to the allocated chunk then a bigger chunk is allocated and the compilation is restarted. However on systems with virtual memory (pretty much any modern system where libjit is likely to be ever used) a program can reserve very large amounts of memory in the first place. The system allocates physical memory page for a virtual memory page only when it is really accessed, not when it is reserved. Hence there should be no need for code space reallocation and recompilation. Normally, the way to go is to reserve memory block with size, say, 0.5 GB and all the code generated during lifetime of libjit application should go there. Initially we can commit only few pages from this amount and commit more on demand. If this block ever becomes full then we report error and just quit. Of course, the the size of allocated block should be configurable.

It might be that some application will not be happy with such allocation scheme. For instance, it might target an embedded system where the old allocation scheme works better. Or the application has tight control over the lifetime of JITed functions and it can tell if particular function is no longer needed so the space occupied by the function’s code could be reclaimed and used for something else. And this is exactly what pluggable memory manger interface is for.

So for me the first goal is to provide better internal memory manager for libjit and the second goal provider interface to plug custom managers. Along the way I should figure out the most flexible interface that will allow application to do whatever it wants.