harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [general] Google Android
Date Fri, 30 Nov 2007 17:02:44 GMT
Dan Bornstein wrote:
> On Nov 28, 2007 2:51 PM, Tim Ellison <t.p.ellison@gmail.com> 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

Mime
View raw message