Dan Bornstein wrote: > On Nov 28, 2007 2:51 PM, Tim Ellison <[EMAIL PROTECTED]> wrote: >> Given that the Harmony class library natives are implemented in terms of >> the portlib functions [1], either (a) you implemented the portlib >> functions to work on the Android platform, or (b) changed the natives to >> call the OS directly. > > We did (b), and it is attributable at least in part due to the way the > project progressed: We started with an entirely new library > implementation (not Harmony based at all), and it was only relatively > late in Android's history (after the project was already a going > concern for at least a couple years) that we started importing code > from Harmony to flesh out the implementation.
Fair enough, doing an 'entirely new library implementation' can be tough eh? <g> > At this point, maybe it makes sense for Dalvik to start using portlib, > but I have a clarifying question: What are the advantages and > disadvantages of doing so? In particular, the Android project is > generally very sensitive to unnecessary bloat and slowness. If the > changes needed to use the portability layer really and truly wouldn't > add extra calls (including in bytecode), extra code (ditto), or extra > memory usage, and if the project wouldn't be able to reduce bloat by > moving further away from the portlib style of things, then it sounds > like it would absolutely make sense to adopt it, since (per my > previous note) *not* using it would be an *unnecessary* difference > between the two codebases. The main reason for using the portlib is (unsurprisingly) to achieve a portability story. If you ever envisage Android running on a different platform then you really don't want to #ifdef all the natives for every combination. Even if you can't imaging running on Windows (say in a browser), you'll have to support a Linux 2.7 at some point, or a different flavor of Linux for those new phones etc. Besides the ability to keep all the platform-specific parts in one place to assist with porting, the portlib avoids code duplication in various native sites. If you unroll the portlib you will have duplicate code in there across multiple places. The cost of an additional function call is worth it IMHO. And since the call is via a function table you can do some useful mappings on the way. For example, if you want to resource-limit areas of the class library you can track and throttle their memory/file/whatever usage through a modified portlib table; you can even give code a table with certain sensitive functions removed if you don't want them to use file IO, etc. You can add trace points to code paths, and all sorts of monitoring and management tricks for a very limited cost of indirection through the function table. It will be good to see that changes that have taken place in Android once they are opened up. Regards, Tim
