harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ilya Berezhniuk" <ilya.berezhn...@gmail.com>
Subject Re: [general] Should we make portlib a separate component?
Date Tue, 05 Feb 2008 20:41:04 GMT
If a goal of moving portlib to the top level is establishing porting
layer for both classlib and DRLVM, I think there is some code with
duplicated functionality and different interfaces in classlib and
DRLVM portlibs (although DRLVM portlib is quite small).

Anyway, I support the idea of improving Harmony porting layer, because
APR has some disadvantages for using in Harmony.
I think we can't get rid of using APR (at least quickly) - we will
need to implement or derive a bunch of code. I think we should use APR
where it ideally fits our requirements, and use portlib when using APR
leads to some additional penalty.

Some APR disadvantages I can see:

1) APR is a project designed to fit Apache Server needs, so any
essential change in APR can involve changes in Apache Server too; I'm
afraid such changes will not be welcomed. I'm not sure we can easily
push our current patches to APR.

2) APR is a large porting layer, it includes some code we'll never
use. I'm not sure about classlib, but DRLVM does not use APR fnmatch,
getopt, global and process mutexes, mmap, network IO, pollsets,
crypto, random, shared memory, signals, arrays, tables, conditional
vars and user info functions.

3) AFAIK, APR includes a support for several architectures and OS
flavors not supported by Harmony now. Although it can help in porting
Harmony to these platforms, it also has some disadvantages. As APR
supports old platforms, it includes actually dead code complicating
its usage and internals. For example, I found that APR atomics used in
DRLVM are compiled on Linux like for pre-i386 (with mutexes and
without 'lock' prefix) - most probably because we have not specified
some flag for using modern instruction set.

4) Most APR functions require APR pools to be used. I'm sure this
technique is feasible when used in HTTP server. It can be useful
somewhere in Harmony, but not everywhere. It's not comfortable in some
cases to look for nearby APR pool for calling APR function. I think
APR pools can also affect memory footprint - it's important for
embedded apps like Android.


Thanks,
Ilya.



2008/2/5, Alexei Fedotov <alexei.fedotov@gmail.com>:
> Hello Xiao Feng,
>
> Let me explain my point so it won't sound strange. I believe it is
> important to position our interests carefully because this might be a
> sensitive topic. When open source gurus are asked how should I start
> my open source project, the usual answer is "Please, don't". This is
> because open source enthusiasts are sparse and their efforts should be
> concentrated and focused on main trends instead of being scattered
> around.
>
> Having two porting layers in Apache makes them both less elaborate and
> fine. The feasible question APR team would ask is "Do you have any
> feedback about our porting layer? Why are you choosing to split a
> community instead of communicating to us first? We will gladly answer
> your request." That is why before we would suggest the new porting API
> initiative the list of concerns should be gathered. Ilya Berezhnyuk
> told me that he would share some experience about APR pools, atomics,
> size and community in this thread if he got some free time.
>
> > That only makes sense if we have to choose between APR and a non-Apache project.
>
> I want to listen your concerns about possibility of using use
> non-Apache interfaces for a majority of a porting layer. Generally I
> think that  virtualization epoch replaced the epoch of porting layers
> which adapt your application to the specific OS. While OS interfaces
> evolve into mature ones and have to become more compatible to each
> other, we may think of choosing standard Linux APIs or gcc primitives
> as a porting layer, and implement wrappers for windows platform. For
> other unix platforms this would remove a good deal of wrappers. This
> would also answer Android's concern about too much wrappers to reach
> the device OS API.
>
> Thanks.
>
>
>
> On Feb 5, 2008 4:58 AM, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> > On Feb 4, 2008 11:34 PM, Alexei Fedotov <alexei.fedotov@gmail.com> wrote:
> > > Hello Mark,
> > > Doesn't autoconf insert GPL license in the code by default, does it?
> > >
> > > Generally modularity looks tempting. I'm not yet convinced that we
> > > should generally move away from using APR instead of moving APR closer
> > > to what we want. The synergy with another Apache project seems to be a
> > > good Apache practice.
> >
> > It sounds strange to use APR only because it's an Apache project. That
> > only makes sense if we have to choose between APR and a non-Apache
> > project.
> >
> > Thanks,
> > xiaofeng
> >
> >
> > > Thanks.
> > >
> > >
> > >
> > > On Feb 4, 2008 6:18 PM, Mark Hindess <mark.hindess@googlemail.com> wrote:
> > > >
> > > > Should portlib be a separate component like classlib, drlvm, jdktools,
> > > > etc.?
> > > >
> > > > Currently portlib is closely associated with classlib.  It is built in
> > > > the same way as any other classlib module.  But really it isn't just
> > > > another classlib module.  It's a porting layer for classlib, DRLVM,
> > > > jdktools, etc.
> > > >
> > > > It is suppose to have a well-defined API ... but we changed the API
> > > > without a second thought when the patch for HARMONY-2236, for example,
> > > > was committed.  I'm under no illusions that having portlib as a separate
> > > > component will stop this happening but I think it would help us think
> > > > about it a little differently.
> > > >
> > > > It would also enable us to apply versioning (branching/tagging) to
> > > > portlib separately from classlib which in turn would allow us to
> > > > manage changes to the API more easily.  Classlib/DRLVM could make
> > > > compile/runtime decisions based on the version of the portlib API that
> > > > is found.
> > > >
> > > > Separate versioning of this component should make it easier to make
> > > > changes and extend the portlib to cover additional requirements.  For
> > > > example, to better support DRLVM, particularly if it moved away from
> > > > using APR which I seem to recall was mentioned (again) recently.
> > > >
> > > > It would also give us the flexibility to choose to have portlib use a
> > > > different build mechanism in future - such as autoconf - if we decided
> > > > that was more suitable for a pure native code component.
> > > >
> > > > Comments?
> > > >
> > > > Regards,
> > > >  Mark.
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > > With best regards,
> > > Alexei,
> > > ESSD, Intel
> > >
> >
> >
> >
> >
> > --
> > http://xiao-feng.blogspot.com
> >
>
>
>
> --
> With best regards,
> Alexei,
> ESSD, Intel
>

Mime
View raw message