harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [general] Google Android
Date Wed, 28 Nov 2007 23:52:40 GMT
On 11/28/07, Dan Bornstein <danfuzz@google.com> 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.
>
> 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?

It is interesting that you should ask about portlib's advantages.  It
turns out that the portlib code in DRLVM is very confusing at the
moment and is in need of cleanup.  I worry that cleaning up
DRLVM/portlib might require changing portlib internals.  A question
for Tim: would IBM entertain changes to portlib internals?

An approach that does not require IBM, Google, Intel, etc to agree on
generic portlib code would be to simply leave things as they are.  For
an open source handheld internet device, it seems an embedded Linux is
the only practical choice for the OS.  Gluing a handheld JVM directly
to an embedded Linux certainly reduces the code maintenance effort.
This comes at the cost of being portable to some non-Linux embedded
OS.  An interesting related question -- what non-Linux embedded OS's
does Harmony portlib support?


>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.
>
> Thanks for your help,
>
> -dan
>


-- 
Weldon Washburn

Mime
View raw message