Nat!'s Web Journal

I don't know who specified it, but that you can't use & on pointers is a major lameness in C.

Especially with addresses you want to mask off bits, and you now always have to cast to an integer and then back again. The problem is though, which integer ? Traditionally on UNIX one used int, but that f.e. never worked well on the Atari ST f.e., where int was defined on some compilers to be 16 bit. With the advent of 64 bit computing, it remains to be seen if all compilers will promote long to 64 bit, so logically one should be using unsigned long long, but that is just horrible :)

One reason, why you may not be able to use & on pointers, might be because you couldn't use AND on address registers on some CPUs like the 680000. but then C was developed for the PDP-11 and I don't know that machine at all.

It is also none none none convenient, that you can't say (void *) p + 12. I suspect some PASCALers were on the committee when this was discussed. :)

[Playing right now: Gasoline from the album "Audioslave" by Audioslave]

It looks like the tracer is working. I ran a dummy Cocoa application and that worked out OK! I then tried TextEdit.app. It works alright so far, except that the background of the window is brown... Check it out:

I don't know, why that artefact happens. Obviously the different malloc library scheme is tripping something up...

What I did was, I nm'ed all the (Text) symbols in malloc.So in /usr/lib/System.dylib and created a .c file that defines them. I then record anything worthy with my tracer and do the memory management with the brand spankin' new Mullocator (my own mallocer). I couldn't figure out how to use the original code in libSystem.dylib. I tried to create function pointers to the "original" routines, but that didn't work out. It looks like I would have needed to parse the original macho file. That's for another project though...

I then tried to launch Safari and Preview with the tracer lib wedged in. Both failed and crashed. Looking at the crash dumps and at the allocation history though it appears, IF i intercept everything, that there are bugs in those applications, that try to access non allocated memory. But any judgement on this is way premature.

The album is pretty routine rock mostly, but the last track The Last Remaining Light is awesome! Sorta like Soundgarden meets Alice in Chains. The first three minutes build up to a final hair raising two minutes, that are worth the € 12 I payed for this alone! One of my favorite track of the year so far.

Ok enough of this boring music shit. :)

Found a bug in valloc, which I just coded yesterday. Still TextEdit.app remains brown. Weird.

OK next up, I might as wll try to reproduce the gawk benchmark using the wedge technique, and I hope that not too much of the 25% gain I had is lost by the shared library call (my original gawk test used static calls).

For the benefit of those, who want to try "Wedging" for themselves, Here is a little test case, a simple example that overrides random.

# Contributed by Eiso AB <eiso@chem.rug.nl>

BEGIN {
  Switch["123"] = " abc "
  Switch["82"] = " def "
  Switch["985"] = " ghi "
  Switch["20"] = " jkl "
  Switch["1098"] = " mno "
  Switch["3874"] = " pqr "
  Switch["272"] = " stu "

  Switch_R["123"] = " 123 "
  Switch_R["82"] = " 82 "
  Switch_R["985"] = " 985 "
  Switch_R["20"] = " 20 "
  Switch_R["1098"] = " 1098 "
  Switch_R["3874"] = " 3874 "
  Switch_R["272"] = " 272 "

  for (i=0; i <30000; i++)
  {
    s1 = s2 = s3 = " 123 82 985 20 1098 3874 272 "

    for (j in Switch)
    {
      # Manually doing a gsub
      while (match(s1, j))
        s1 = substr(s1, 1, RSTART-1) Switch[j] substr(s1, RSTART+RLENGTH)

      # Use gsub
      gsub(j, Switch[j], s2)

      # gsub, and prevent RE recompile
      gsub(Switch_R[j], Switch[j], s3)
    }
  }
}

bash-2.05a$ 
time ./mullegawk -f bench1.awk 

real    0m16.922s
user    0m14.140s
sys     0m2.480s

bash-2.05a$ time ./applegawk -f bench1.awk 

real    0m22.372s
user    0m19.540s
sys     0m2.310s

bash-2.05a$ time ./gawk.sh 

real    0m24.526s
user    0m21.810s
sys     0m2.240s

bash-2.05a$ time ./gawk.sh 

real    0m18.709s
user    0m15.290s
sys     0m2.030s
bash-2.05a$ 

void   *malloc( size_t size)
{
   void  *ptr;

   ptr = mulle_malloc( size);
   return( ptr);
}

#define OVJLAAAA( x, y)   for( x = 0; x < y; x++) /* garbage */
#define PVJLAAAA( x, y)   for( x = 0; x < y; x++) /* garbage */
#define QVJLAAAA( x, y)   for( x = 0; x < y; x++) /* garbage */
#define RVJLAAAA( x, y)   for( x = 0; x < y; x++) /* garbage */

bash-2.05a$ time /usr/bin/cpp < foo.cpp > /dev/null

real    0m8.561s
user    0m6.840s
sys     0m0.920s

bash-2.05a$ time ./cpp.sh 

real    0m7.320s
user    0m5.440s
sys     0m0.950s

Apple:

real    0m0.455s
user    0m0.320s
sys     0m0.040s

real    0m0.460s
user    0m0.280s
sys     0m0.050s

[Playing right now: By The Pain I See In Others from the album "Deliverance" by Opeth]

Rewrote some other not too often used, but lamely written piece of the Mullocator. Considering all the #ifdef and comments that have been inserted, the core code is pretty slim. It's like a fluffy kitten, that when hosed down looks just a spiny little rodent :)
Got actually a email request by someone, who wants ImagePrinter converted to Mac OS X. I asked why he didn't just use OmniGraffle. If there's anything ImagePrinter does better, then I will release it (what the hell :))

malloced bytes    : 82403192
freed bytes       : 86235890

Well almost.

The problem is that TextEdit.app is leaking when running with the Mullocator. It know this sounds so wrong :) But I am tracing all the "malloc/realloc/free" calls that are coming in, and I get twice as many "malloc" calls as I get free calls, when TextEdit.app is idling (and the cursor is blinking). So the problem can't be in my code. The problem can't be in TextEdit.app either, because with the normal Apple malloc it doesn't leak. Somehow either some memory is freed behind my back (how ?) or somehow my code induces Carbon/Cocoa to not free as much memory as usually.

This has me stumped at the moment.

Read this on the extreeemly mild mannered apple developer mailing list, where cotton balls are considered dangerous weapons

On Tuesday, June 24, 2003, at 11:26 AM, some guy wrote:

> When you old guys retire, who is going to take your places?

Some, take a break from computing and educate yourself about the economic and political environment you inhabit. The powers that drive industry today could care less if us old bastards and/or bitches retire, die, or evaporate.

And as for who will be taking our place?

It ain't you.

Other Guy

(names removed to protect the innocent and guilty :)) : Wow an actual flame. My gracious, I think I might faint! Actually that was a very good laugh.

Well, the public apology just came in, which just goes to show, that the dark age we are living in, is anything but far from over.

Damit verliert mein Körper einen wichtiges Glied aus der Ernäherungskette. Die Zufuhr von Schokolade und Vanille ist erstmal unterbrochen. Mal sehen, wie sich das auswirkt.

Unfortunately reproducably, so I have to redo everything on my overflowing local disk (500MB left) instead of my network drive (40 GB left).

Here's what the crash looks like, in case you wonder:

Wed Jun 25 22:37:21 2003

panic(cpu 0): nfs: bioread, not dir
Latest stack backtrace for cpu 0:
      Backtrace:
         0x0008581C 0x00085C4C 0x000287B4 0x0016EF44 0x000B08F8 0x000B8B98 0x0020F3CC 0x00092970 
         0x00090009 
Proceeding back via exception chain:
   Exception state (sv=0x18CF7500)
      PC=0x9000B6CC; MSR=0x0000F030; DAR=0x0007E4B0; DSISR=0x40000000; LR=0x0002C6CC; R1=0xBFFFDA80; XC
P=0x00000030 (0xC00 - System call)

Kernel version:
Darwin Kernel Version 6.6:
Thu May  1 21:48:54 PDT 2003; root:xnu/xnu-344.34.obj~1/RELEASE_PPC

This also means a definite end of life of the Sybase Adaptor for Mac OS X Server 1.2. I wonder if anyone cares about that anyway. :)

memset( block, length - 2 * ALIGNMENT, 0x9B);	/* initalize with some trash */

+ 40 
+ 44
+ 8
+ 72
+ 40
+ 40
+ 40
+ 131072 (131072)