Improving XPCOM for Mozilla 2

XPCOM technology, based on Microsoft COM, is fundamentally structured around the concept of binary object layouts and stylized calling conventions. XPCOM was a good technique for introducing modularity and extensibility to the Mozilla codebase, but it is showing its age. One of the interesting things about Mozilla 2 is that we can breaking API and binary compatibility.

There are several ways we should improve XPCOM:

  1. Improve reference-counting (this could include universal support for cycle collection, or even allocating all XPCOM objects using MMgc; Graydon and I talked about this some at the Summit, and I’m sure he’ll take the lead determining what this means in practice.
  2. Allow throwing complicated (object-type) exceptions from any XPCOM method, and reduce the verbosity and inefficiencies of nsresult return codes. C++ exceptions, as much as I dislike them, provide the shortest path to this goal. Taras has been working with oink to provide an automated way to convert method calls automatically.
  3. Reduce the complexity and verbosity of using XPCOM. I’ve been spending a fair amount of time working in Python recently, and I’m very impressed with its use of module objects. Using XPCOM could be a lot easier from script with some very simple changes. I’ll blog about this soon!

In order to achieve these objectives, I’m convinced that Mozilla must break XPCOM binary compatibility, and should stop using XPCOM as the binary embedding solution:

The implications of a change like this are considerable:

Brainstorming Example

class nsISupports : virtual public RCObject
{
  inline void AddRef() { IncrementRef(); return 2; }
  inline void Release() { DecrementRef(); return 1; }

  virtual nsISupports* QueryInterface(REFNSIID aIID, PRBool aAddRef) = 0;

  /**
   * For ease of conversion, provide an old-style QI wrapper.
   */
  inline nsresult QueryInterface(REFNSIID aIID, void **aResult) {
    *aResult = QueryInterface(aIID, PR_TRUE);
    return (*aResult) ? NS_OK : NS_NOINTERFACE;
  }

  virtual nsISupports* GetInterface(REFNSIID aIID, PRBool aAddRef) = 0;

  virtual nsIClassInfo* GetClassInfo() = 0;
};

The virtual inheritance of RCObject could be a problem for xptcall. There are ways around that. I’m also a little concerned that objects won’t be storing pointers to the “root” GCObject, but rather vtables within that object. I hope that doesn’t mess up MMgc.

Atom Feed for Comments 5 Responses to “Improving XPCOM for Mozilla 2”

  1. Mike Says:

    Is there anything which needs to be done to make creating language bindings easier? I’d really like to use lua or C# or ocaml, but the bindings aren’t there. Is this because its difficult to create the bindings, or just because there’s no interest?

  2. Robert O'Callahan Says:

    Why would we want GCRoot to be a base class for all XPCOM objects?

    > I’m also a little concerned that objects won’t be storing pointers to the “root”
    > GCObject, but rather vtables within that object

    You mean “subobjects within that object”, right? Not the vtable itself

    If we’re only going to be using XPCOM within libxul, and JS bindings are going to be redone to not use XPCOM, then why we do we need it at all?

  3. Neil Says:

    >Firefox and Thunderbird use binary components to do OS integration.

    More obviously, Thunderbird has this rather large binary component called mail, which is going to take some work just to port to frozen linkage…

  4. Jason Orendorff Says:

    > I’m also a little concerned that objects won’t be storing pointers to the “root”
    > GCObject, but rather vtables within that object. I hope that doesn’t mess up MMgc.

    You’re right, this is a problem. This would mess up MMgc as it stands. There’s some code in GC::MarkItem() that checks that the (possible) pointer points to the start of the allocated region. If it points into the middle of an allocated region, MMgc skips that pointer.

    It can be fixed, at the cost of more often misinterpreting numbers as pointers.

  5. Mark Finkle’s Weblog » Mozilla 2 - The Future of the Mozilla Platform Says:

    [...] about goals for XPCOM in Mozilla 2 to the Wiki and Newsgroup. See Benjamin’s older post on XPCOM changes too. I encourage any extension, embedders and XUL application developers who use binary code to go [...]

Leave a Reply