This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Questions about __cxa_throw and type_info


> I don't understand why you are messing around with __cxa_throw and
> type_id.  Our implementation predated the introduction of RTTI into
> the language so we needed to define conventions for object identification
> (for example, return the class name as a string).  But we managed to
> do everything without messing with details like this, and still got the
> thing to run on about six different C++ compilers.

The big hurdle that I'm trying to jump here is the ability to throw and catch exceptions. But, for conversation's sake, I'll explain some background and design decisions made for this project.

One of the things that I dislike most about extension languages is the tedium required to write the bindings for each and every parameter to and from each and every function call... not to mention that this has it's impact on the performance limit the extension language. Also, many of them do not allow for bidirectional invokation. For example, a c++ application may evaluate a Lua script, and a Lua script may call an exposed function, but the exposed function cannot easily (if at all) call a subrutine of that same script (let alone a virtual method of an object within the script).

I already have a proof of concept that is able to forge a virtual table and instance an object. The virtual methods that are overridden by the new forged virtual table enter a thunk which invokes the interpreter passing the this pointer and virtual function id as parameters. The interpreter uses stack-based contexts which makes it reentrant and (hopefully) as thread safe as the code that it executes. The executed code is also able to call member functions of exposed c++ objects. The object format is intended to be 100% compatible with c++ objects of the host platform allowing instanced objects from the extension language to be passed directly to the application without any exhaustive marshaling or get/set interaction. With native object compatibility, theoretically the interpreter can be replaced with a jit compiler engine when the project has matured to that level, thus breaking all manor of performance caps.

In addition to these issues that I have with general extension languages, I also want to address issues that exist in revising c++ dynamic libraries. Specifically, the dependence on object size and virtual table structure between application and library. If an application derives a class from one defined in a library, then the base class in the library cannot gain new data members or virtual functions without breaking compatibility with the compiled application. The application needs to be recompiled every time changes like this occur in the library. The proposed solution here is to embed metadata with the exposed object. The interpreter will use this metadata to link the code it is executing with the c++ classes it is interacting with or deriving new classes from. This might not do anything about the human element, but at least object size, member data precision, and addition of virtual methods can all be removed from the equation. That will allow existing extensions to
 have greater longevity without revisions to applications breaking them.

The final core design consideration is to keep the extension language platform independent (maybe that's implied by the phrase 'extension language'... but maybe not). To accomplish this, a byte-code is used. Why don't I just use java?... because there are some other things that I want to do very differently which I haven't mentioned in this explanation. But, in short, I hope some other design decisions I have might improve performance and reduce code size for both the byte-code extensions and the interpreter, as well as open up a few worlds of possible new design models that were previously only possible within ugly nests of templates that resulted in massive code replication and bloat of microsoftic proportions.

The only major concept that I do not yet have a proof-positive for is exception throwing and catching. I'd like for the interpreter to be able to catch arbitrary objects thrown to it from any c++ function that it has invoked as well as throw objects that it has created. In order to throw objects from the interpreter, I need a mechanism where I can pass a void* and type_info* which __cxa_throw looks like the right function for. Catching is a little bit of a different monster... I will need the interpreter (or at least part of it) to implement it's own personality function so that it may examine the exception header and decide if any of the interpreted code in its context is able to handle the error. Since this new standard for exception handling is still relatively young, I don't believe c++ offers any mechanism for examining the exception headers yourself, so I will probably need to do some black magic to pull off this one. I'll also want the c++ runtime to be able to
 negotiate casting instances of extension classes during a throw-catch scenario. I believe this requires forging properly working type_info objects to accompany the forged virtual tables.

The importance of the integration of exception handling is minor in contrast to the other highlights, but... exceptions happen! I'd like for the integration with c++ to appear as though it were 100% native (without all the detriments of platform dependence, library revision problems, etc).

The final product will allow this extension system to be interoperable with almost any existing or future c++ framework (I will eventually need to implement template support... sigh). Extensions can be deployed in data files or even client-server transmissions with little or no regard to application version or host platform. And extensions can have the power to interact directly with much lower-level portions of the application than is typical of other common extension scenarios.

Well... If I haven't already established my insanity... you can have me committed after reading this.

Thank you,
- Brian





 
____________________________________________________________________________________
Don't get soaked.  Take a quick peek at the forecast
with the Yahoo! Search weather shortcut.
http://tools.search.yahoo.com/shortcuts/#loc_weather


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]