A Passion for Music

Monday, December 11, 2006 at 12:18 PM

Posted by Mark Dalrymple, Member of Technical Staff, Mac Team

After an orchestra rehearsal last month, some of us went to the local Eat-n-Park, a family restaurant chain here in western Pennsylvania. I was decked out in a traditional black Google T-shirt. After chatting with the waitress a bit, she asked about the shirt, and I said that I worked at Google. She said "Wow! It never occurred to me that people actually worked there."

Yes, indeed, real live people work here. And because we're real people, we have real interests. The most interesting programmers I've come across have also had serious passions outside the world of bits and bytes. Among the Googlers I know are a triathlete, an expert wordsmith, a rescue dog trainer, and an incredible black-and-white photographer.

My particular passion is music. I've been playing music of one kind or another since fourth grade, having floated into and out of dozens of groups, and I have played hundreds of performances over the years. I met my wife Sharlotte in a community orchestra in Northern Virginia. Since moving to the Pittsburgh area in 2000, we've joined two concert bands, one community orchestra, an on-again off-again woodwind quintet, and we sing in a church choir.

I started out my music career on trombone in elementary school and got to be a fairly decent player. In junior high school, my folks sent me to The Summer Arts Camp at Interlochen, an 8-week musical immersion experience where you perform 7 complete concerts. That's a fresh batch of music nearly every week! At Interlochen, I met the bassoon while I was counting hundreds of bars of rest during orchestra rehearsals. One week the group was doing the Berceuse and Finale from Stravinski's Firebird suite, which has an amazing bassoon part. At that point, I decided I wanted to play that thing. I had to play that thing. Luckily, my school had an instrument no one was using, so I glommed onto it and took some lessons. I've kept up with both instruments over the years, becoming a "doubler": that is, I play each of them well enough to not embarrass myself in public.

Sharlotte and I are very busy musically, especially during the holiday times. This month, we're slated to play a three-night run of a hometown Christmas musical, one orchestra concert, three community band benefit concerts, background music at a grocery store, background music for a dinner banquet, two church services, and we'll be demonstrating the double-reed family to the local middle school's seventh grade band. It's a crazy schedule, but we love it.

I'll leave you with two recordings. In the first, I'm performing "Bye Bye Blues", a bass trombone solo with the Westmoreland Symphonic Winds Jazz band. The other is Zephyrs (The West Winds), a quintet I'm in, playing the second movement of the woodwind quintet by Muczynski, which includes Sharlotte on oboe and me on bassoon. I hope you enjoy the music -- played by people!

Google Summer of Code and Macs

Wednesday, December 06, 2006 at 12:10 PM

Posted by: Desmond Elliott, Student

What did you do on your summer vacation? Desmond Elliott, a computer science student at Edinburgh University, spent some of his time working on Camino, the Mac-only open source browser, as part of the Google Summer of Code (GSoC). Here's what Desmond had to say about the experience:

Working on Camino this summer was so much fun. I had never done much software development outside of the required coursework for University, and I decided that I really needed some experience. There is only so much you can learn from coursework!

My GSoC project was certainly a challenge for me. I had never written any Objective-C, and let me assure you, it showed! I wasn't part of the Mozilla/Camino community. I had never worked on a codebase as vast as Camino/Gecko. And I'd never had somebody review my code and scrutinise it as much as Google engineer Stuart Morgan did.

Working on this project made me a better developer because so many of the patches I submitted were negatively reviewed. Instead of taking this personally, I used it to improve my coding style and standard. For example, when I write code in Java for my research project, I think about whether I am wastefully creating objects.

Of course, I did learn a lot about Cocoa/Objective-C Programming on Mac OS X, but I learned a lot more as well. I learned about the importance of being able to communicate with people non-verbally. I think that being a great developer means you can work as a team and I certainly learned a lot about that this summer. Some of the people you work with might not even natively speak your language, so how you express yourself is important. I learned about managing my own time on a self-directed project. It was almost like it was a trial for my undergraduate research project.

Although my mentor Mike Pinkerton was always busy with those "work" things that Google forces him to do (and he cannot talk about them, which is even worse), he was an excellent mentor. He was always able to meet with me once a week. This was important for both of us because it made sure that neither of us were out of the loop. He was quick to respond to my emails, too.

There are so many great things that I took from GSoC that I could go on and on.

Even though GSoC is over, I'm still active within the Camino team. And I will definitely apply for a place in GSoC next summer, my last summer at University, and it will probably be writing Mac software once again.

Remote Access

Friday, December 01, 2006 at 12:50 PM

Posted by: Amanda Walker, Member of Technical Staff, Mac Team

I started my career working on Mac networking products way back in the '80s and '90s, well before the Internet was in everybody's living room. For example, I wrote SLIP and PPP packages to get Mac users online over dialup connections, pitched in on efforts to standardize things so that everyone's gear would actually work with everyone else's, and so on. In those days, "Internet client software" meant Telnet and FTP, not web browsers and streaming video. We could see the potential, but it would take years for reality to catch up to the vision.

About a year ago, I got a phone call out of the blue from a recruiter, asking if I was interested in talking to Google about its incipient Mac team. This was quite a surprise: Until that point, while I was an avid Google user, I hadn't noticed Google paying any special attention to Mac users, beyond delivering a Mac version of Google Earth.

By the time I got the recruiting call, I had not worked on insanely great Mac software for awhile. The idea of a Google Mac team was very intriguing, and things snowballed from there. As Greg Robbins noted, Google was quietly recruiting a top-notch Mac development group, and the search wasn't limited to just Silicon Valley. I live near Washington D.C., where Google does not have an engineering office, so I mostly work at home. This has its downside -- there's no excellent, free Google food, and I sometimes feel like I'm living at work (hmm, maybe I am: check out the picture).

However, it all works surprisingly well, at least for our team. VPN, high-speed Internet service, and flat-rate long distance make it a lot easier than it used to be, but I also spend about 20% of my time working from Mountain View and other Google offices. Of course, there are worse things than having to leave D.C. for California during the winter.

In the '80s, I chose to develop Mac networking software because I wanted to change the world. Here in the future, it's a much taller order. Technology is moving faster than ever, and Apple and Google are both very careful not to tip their hands in advance about future products. So instead of questions like "the Inter-what?", I get questions like "will I be able to watch YouTube on my iPhone?" Unfortunately, they don't tell me the answer to that. But I'm ready for anything: one thing my home office has in common with the Googleplex is an espresso machine, available 24/7.

Getting Loaded

Tuesday, November 28, 2006 at 10:04 AM

Posted by: Dave MacLachlan, Member of Technical Staff, Mac Team

Categories are a really interesting feature of Objective-C, especially for those of us who came from C++. Not only do categories allow you to extend other classes for which you may be lacking the source, but they also give you a really simple way of hiding interfaces from your clients without all the baggage of a pImpl pattern. We use categories a lot here at Google to "enhance" the system frameworks.

We do run into a couple of major problems with categories, though. One issue is about class-specific initialization. Objective-C has traditionally had three solutions for class-specific initialization:

1. lazy initialization
2. +initialize
3. +load

With lazy initialization, we call our initialization routine as necessary to make sure our class-specific stuff is initialized before we use it. This works fine except that in implementing it, we often end up writing code where every method starts with a method call to the initialization check, which is ugly and a potential source of stupid bugs.

+initialize is the "best practice" for initializing class variables. For a standard class, it works great. This technique usually does almost everything we want it to do and has reasonably clear semantics, although the part that says "you could be invoked more than once" is a bit of a pain. The problem with +initialize is that it is virtually useless for categories, in that if I override a class's initialize method in my category, I can't call the original initialize. Also, if I have two categories on a class, and both have initialize methods, it is unclear which one will be called. Even if it works now, there's no guarantee the original framework you're extending won't be "enhanced" and break you in the future when an initialize method is added to the class you extended. So, as far as categories are concerned, +initialize is pretty much useless. Interestingly if you think about it, in some ways +initialize is very much like lazy initialization, with the details hidden under the covers. Basically, you have the runtime doing the check instead of you having to code it.

+load is an interesting option, and probably one of the less understood areas of how the Objective-C runtime actually works. According to the NSObject documentation:

1. +load is invoked once per class or category.
2. +load is usually invoked before +initialize, but not always.
3. You can't be sure your superclasses are loaded.
4. You can't be sure any other classes are loaded.
5. You know, you really should be using +initialize.

Item 1 is great, but there are a lot of interesting little caveats that follow it. Basically, the docs say you can't call ANY other classes, including your superclass, safely from within a +load. Looking at the obj-c runtime code (ADC registration required), we can get a bit more information on how +load works. We see that we are guaranteed that our superclasses are "+load"ed before we are "+load"ed, but we can't call out to other classes, so officially we can't use NSDictionary, NSString, et al. In practice, this appears to work pretty much all the time, but I certainly wouldn't intentionally ship code that depended on it.

So it appears that if we stay with traditional Objective-C, we are basically stuck with lazy initialization for doing class-specific initialization in a category. Luckily, if we break with tradition, we can use the "constructor" attribute. Yes, the syntax is ugly, but it does potentially solve a lot of our problems.

Constructors (which is a horrible name that must have been intentionally designed to cause confusion with C++/Java constructors) are guaranteed to be called after +load but before main. This gets rid of several of the caveats of +load, because you can be guaranteed that all your classes are loaded and that +initialize will be invoked on classes as needed by your constructor function.

So doing something like the following gives us a nice, relatively clean way of class-specific initialization in a category.

@implementation Foo(FooBarAdditions)
....
@end

@interface Foo(FooBarAdditionsPrivateMethods)
+ (void)initializeBar;
@end

@implementation Foo(FooBarAdditionsPrivateMethods)
+ (void)initializeBar {
// Initialize stuff here
}
@end

void __attribute__ ((constructor)) InitializeFooBar(void) {
static BOOL wasInitialized = NO; 
  if (!wasInitialized) {    
// safety in case we get called twice.
    [Foo initializeBar];
    wasInitialized = YES;
  }
}

@synchronized swimming Feedback

Thanks to reader Ron Avitzur for pointing out that the nice Objective-C workaround for the DCLP that I showed in a recent post is officially bad. He's got a nice writeup on his blog about why even though it's pretty, it's nothing more than a global flag, which in theory doesn't get us around the problem at all.

Woz comes to Google

Tuesday, November 21, 2006 at 9:21 AM

Posted by: Scott Knaster, Technical Writer

The first time I ever saw the mysterious inscription Woz was while reading the legendary Red Book that came with my Apple ][. I soon found out that Woz was Steve Wozniak, who had designed the Apple ][ and co-founded Apple Computer. The more I learned about Woz and his inventions, the more amazed I was: how he enabled the Apple ][ to use a cheap cassette recorder to load and save data; his incredible design for color output that two professional engineers told me "couldn't possibly work"; his unique disk controller that somehow managed to use software for timing and eliminated the need for all but 5 chips.

Woz is a Silicon Valley legend of the highest order, so we at Google were thrilled to welcome him here last Thursday to talk about his new book, iWoz: From Computer Geek to Cult Icon: How I Invented the Personal Computer, Co-Founded Apple, and Had Fun Doing It. Woz arrived about 20 minutes late, but stayed more than twice as long as he was "supposed" to, answering every question, signing every book, and talking to everyone who wanted to talk to him (and so I figured out why he was late in the first place).

Woz's talk showed why he is an inspiration to engineers (and other people) everywhere. He captivated the crowd with his passion and enthusiasm for what he does, whether it's designing computers, putting on massive concerts, or talking about his life and work. I highly recommend you see Woz on his travels if you get a chance -- if you're lucky, you might even get pranked -- and whether you see him in person or not, his book is a wonderful peek at the life of this remarkable guy.

And now I have this great souvenir:

More Earth for the Mac

Tuesday, November 14, 2006 at 10:49 AM

Posted by: John Gardiner, Technical Writer, Google Earth team, and Rose Yao, Mac Product Manager

Late last week, Google released an updated beta version of Google Earth 4 for Mac OS X (and some other platforms). For those of you who love Google Earth, this release includes a number of neat new features and enhancements:

Performance improvements: we've made 3-D models (such as those created in SketchUp or imported from the 3D warehouse) load more quickly and more realistically.

Paths and polygons: a very cool advanced feature -- and now it's in the FREE version.

Altitude: This is useful for overlays such as weather radar images where you want to see the image from directly above, but also want to look at the ground imagery from an angle. It's also good if you're going on a hike and want to pick an easier path :).

And as usual, we're trying to improve the Google Earth experience with new icons, printing functionality, and more. Check it out!

@synchronized swimming (part 2)

Tuesday, November 07, 2006 at 10:52 AM

Posted by: Dave MacLachlan, Member of Technical Staff, Mac Team

Previously we addressed the problem of optimizing around a shared resource. We came up with one solution, but it was kind of messy, and we wondered if there might be a better way. And now: the conclusion.

There is at least one more elegant solution, but it is slightly less safe. So far I've assumed we're using Objective-C, but what happens if we use Objective C++, specifically Objective C++ with gcc 4? According to the GCC4 porting notes:

GCC 4.0 automatically adds locks around any code that initializes local static variables in C++. If you do not need this protection and want to reduce your code size slightly, you can disable the locking behavior by passing the -fno-threadsafe-statics option to the compiler.

This appears to be backed up by the gcc 4.0 release notes and the C++ ABI. So this implies that if we just change our compiler from standard Obj-C to Obj-C++ we should be able to do the following:

+(id)fooFerBar:(id)bar {
   static NSDictionary *foo = [NSDictionary dictionaryWithObjects:...];
   return [foo objectWithKey:bar];
}

which is certainly nice and clean. Let's take a quick look at the disassembly:

cxa_guard_acquire

my actual code

cxa_guard_release
cxa_guard_abort
Unwind_Resume
...

and by scanning the code for cxa_* (ADC registration required) we can see that it's doing almost exactly what we want. The only pitfalls here are if we somehow attempt to compile with a gcc version less than 4.0 (we can put in guards against this happening) or we use -fno-threadsafe-statics in a threaded environment, in which case we're asking for trouble, and trouble will certainly follow (we won't do that).

So, we've got a thread-safe shared resource that does what we want with a minimal amount of code. One last tiny issue remains. What happens if we accidentally mix our Objective-C @synchronized with C++ dynamic initialization of local statics?

+(id)fooFerBar:(id)bar {
@synchronized(self) {
   static NSDictionary *foo = [NSDictionary dictionaryWithObjects:...];
   return [foo objectWithKey:bar];
}
}

and the disassembly shows:

...
objc_sync_enter
objc_exception_try_enter
setjmp
objc_exception_extract
cxa_guard_acquire

my actual code

cxa_guard_release
cxa_guard_abort
objc_exception_try_exit
objc_sync_exit
objc_exception_throw
...

Yes, ladies and gentlemen, you get to pay for 4 lock/unlocks and two
exception stacks to protect your wee shared resource, so you may want
to watch for this pattern in your performance-sensitive code when
porting to Objective C++.

Feedback from part 1

Thanks to reader Bill Bumgarner, who came up with an interesting solution to my problem that has a distinctive Obj-C feel to it:

static NSDictionary *foo = nil;

+(id)fooFerBar:(id)bar {
@synchronized(self) {
   if (!foo) foo = [NSDictionary dictionaryWithObjects:...];
   ReplaceMethodImplementationWithSelector
      ([self class], @selector(fooFerBar), @selector(fooFerBar2));
}
   return [foo objectWithKey:bar];
}

+(id)fooFerBar2:(id)bar {
   return [foo objectWithKey:bar];
}

where ReplaceMethodImplementationWithSelector swizzles fooFerBar with fooFerBar2. So, the first time fooFerBar is called we get our slow case, and any later calls get the fast case, assuming the first thread has completed fooFerBar. This solution provides great performance, and you only have to pay for the synchronize once. Very nice!