You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Mark Hindess <ma...@googlemail.com> on 2008/02/04 16:18:50 UTC
[general] Should we make portlib a separate component?
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.
Re: [general] Should we make portlib a separate component?
Posted by Gregory Shimansky <gs...@apache.org>.
On 4 февраля 2008 Mark Hindess 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?
I am currently planning some restructure in the VM code to separate it on the
principle of platform dependent/independent. Most of the dependent parts are
going to be moved into VM's internal port component and hopefully improve its
modularity. Of course a lot of code would still remain to be somewhat
platform dependent in the VM code, this change is not going to be instant,
but code for handling signals/exceptions, crash handling and native stack
iteration is certainly the candidates for porting library, not a core part of
VM code.
Merging the VM port library with class library one is not a trivial thing to
do. For example there is a quite different approach at the API level, class
library is a masterpiece of using preprocessor (often with a detriment to the
understanding to how exactly thing are working) and pure C while drlvm's
library is a collection of mostly unrelated platform dependent functionality
with mixed C/C++ interfaces that are yet to be unified and reorganized in
many aspects.
I think that porting code of class library and VM would eventually merge, but
it is a quite distant future IMHO. We didn't even defeat the infamous problem
of two hythread libraries with a well defined common interface, the porting
stuff is by far less organized.
I'll start on moving code inside of VM source tree to sort out the interfaces
inside of it between "port" and "vmcore" subtrees. Also I think that "port"
should provide a shared library instead of a static one.
--
Gregory
Re: [general] Should we make portlib a separate component?
Posted by Alexey Varlamov <al...@gmail.com>.
> > I'm not yet convinced that we should generally move away from using
> > APR instead of moving APR closer to what we want.
>
> That would be a huge task and I see no sign of effort being applied to
> that problem. I'd like to be wrong though?
Hmm, it might be easier to advance Harmony portlib to separate
(sub)project as alternative to APR.
>
> The portlib API is a good deal more flexible. (Nevertheless, it might
> be an interesting exercise to implement portlib on APR.)
There is one more dependency on APR existing in DRLVM, it is log4cxx.
Anyway, I doubt we can afford moving from APR in near future, benefits
are not so evident to force this task.
--
Alexey
Re: [general] Should we make portlib a separate component?
Posted by Mark Hindess <ma...@googlemail.com>.
On 4 February 2008 at 18:34, "Alexei Fedotov" <al...@gmail.com>
wrote:
> Hello Mark,
> Doesn't autoconf insert GPL license in the code by default, does it?
I don't think so. Wouldn't that already be a problem if it did - since
we use apr and apr-util which both use autoconf?
Anyway, don't get hung up on that. It was just a example in what was
intended to be a general comment about using the right tool for the job.
(autoconf might be that tool but there are other choices these days.)
> Generally modularity looks tempting.
Good. That was my main motivation.
> I'm not yet convinced that we should generally move away from using
> APR instead of moving APR closer to what we want.
That would be a huge task and I see no sign of effort being applied to
that problem. I'd like to be wrong though?
The portlib API is a good deal more flexible. (Nevertheless, it might
be an interesting exercise to implement portlib on APR.)
> The synergy with another Apache project seems to be a good Apache
> practice.
I agree but I don't see anything synergistic about combining harmony
with APR. APR is not a good fit - see discussions in the archives.
Regards,
Mark.
> On Feb 4, 2008 6:18 PM, Mark Hindess <ma...@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
Re: [general] Should we make portlib a separate component?
Posted by Ilya Berezhniuk <il...@gmail.com>.
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 <al...@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 <xi...@gmail.com> wrote:
> > On Feb 4, 2008 11:34 PM, Alexei Fedotov <al...@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 <ma...@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
>
Re: [general] Should we make portlib a separate component?
Posted by Alexei Fedotov <al...@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 <xi...@gmail.com> wrote:
> On Feb 4, 2008 11:34 PM, Alexei Fedotov <al...@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 <ma...@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
Re: [general] Should we make portlib a separate component?
Posted by Xiao-Feng Li <xi...@gmail.com>.
On Feb 4, 2008 11:34 PM, Alexei Fedotov <al...@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 <ma...@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
Re: [general] Should we make portlib a separate component?
Posted by Alexei Fedotov <al...@gmail.com>.
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.
Thanks.
On Feb 4, 2008 6:18 PM, Mark Hindess <ma...@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
Re: [general] Should we make portlib a separate component?
Posted by Alexei Fedotov <al...@gmail.com>.
Tim, Mark,
I like a careful rewording about gradual movement of internal
components to a higher level.
It would be challenging goal to get some API consensus and usage
synergy among the projects, or may be smaller parts of the projects.
Some time ago I was thinking about porting library design and argued
for APR myself, but now I believe that Cygwin approach of using open
standards such as pthread API or just Linux OS calls instead of
symmetric wrapping system API calls for every platform may worth to be
considered as an interesting portlib architecture possibility,
especially with growing virtualization opportunities. This would give
us more supporters such as Android guys. <joke>Also, we may assume
that portlib gradually replaces APR when Tomcat on the top of Harmony
replaces HTTPD.</joke>
Thanks.
On Feb 4, 2008 11:35 PM, Tim Ellison <t....@gmail.com> wrote:
> Mark Hindess 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.
>
> Well it isn't today. DRLVM and jdktools do their own thing, so it
> really is just a factoring of the class library code.
>
> > 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.
>
> I don't see why this a problem. We have control over both sides of the
> API boundary, so changing the API to suit a usecase better is fine,
> provided the implementation and its usage is changed simultaneously --
> and it was.
>
> We don't promote the portlib APIs for our end users to use. If we did
> then of course we would have to be more careful. Even internally, like
> the VMI, we are careful when there are internal users.
>
> > 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.
>
> I see what you are saying, but again, I'm yet to be convinced there is a
> problem being solved here. Why not also version control the hycommon,
> hythread, etc internal APIs too?
>
> > 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?
>
> I don't have a strong objection to moving it out to a 'top level'
> component -- it just seems premature when there is no pressing need to
> do so. If somebody declared a porting problem, or DRLVM gurus said they
> want easier access to use it then sure. Perhaps there is a driver that
> I'm not seeing here.
>
> It sounds like it is just a move within the project, not a re-architecture.
>
> Regards,
> Tim
>
--
With best regards,
Alexei,
ESSD, Intel
Re: [general] Should we make portlib a separate component?
Posted by "Jimmy,Jing Lv" <fi...@gmail.com>.
2008/2/5, Tim Ellison <t....@gmail.com>:
> Mark Hindess 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.
>
>
> Well it isn't today. DRLVM and jdktools do their own thing, so it
> really is just a factoring of the class library code.
>
>
> > 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.
>
>
> I don't see why this a problem. We have control over both sides of the
> API boundary, so changing the API to suit a usecase better is fine,
> provided the implementation and its usage is changed simultaneously --
> and it was.
>
> We don't promote the portlib APIs for our end users to use. If we did
> then of course we would have to be more careful. Even internally, like
> the VMI, we are careful when there are internal users.
>
>
> > 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.
>
>
> I see what you are saying, but again, I'm yet to be convinced there is a
> problem being solved here. Why not also version control the hycommon,
> hythread, etc internal APIs too?
>
>
> > 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?
>
>
> I don't have a strong objection to moving it out to a 'top level'
> component -- it just seems premature when there is no pressing need to
> do so. If somebody declared a porting problem, or DRLVM gurus said they
> want easier access to use it then sure. Perhaps there is a driver that
> I'm not seeing here.
>
> It sounds like it is just a move within the project, not a re-architecture.
>
I have a request here, that JDWP may use portlib to port to all
platforms and facilitate the development and refactor. As a result,
moving portlib to top-level may be a good way for build?
> Regards,
>
> Tim
>
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
Re: [general] Should we make portlib a separate component?
Posted by Mark Hindess <ma...@googlemail.com>.
On 4 February 2008 at 20:35, Tim Ellison <t....@gmail.com> wrote:
> Mark Hindess 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.
>
> Well it isn't today. DRLVM and jdktools do their own thing, so it
> really is just a factoring of the class library code.
I think you'll find DRLVM does several of its own things ;-) *and* that
one of them is portlib - see:
vm/port/src/logger/logger.cpp
I'll comment on the rest of your message in the morning.
-Mark.
> > 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.
>
> I don't see why this a problem. We have control over both sides of the
> API boundary, so changing the API to suit a usecase better is fine,
> provided the implementation and its usage is changed simultaneously --
> and it was.
>
> We don't promote the portlib APIs for our end users to use. If we did
> then of course we would have to be more careful. Even internally, like
> the VMI, we are careful when there are internal users.
>
> > 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.
>
> I see what you are saying, but again, I'm yet to be convinced there is a
> problem being solved here. Why not also version control the hycommon,
> hythread, etc internal APIs too?
>
> > 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?
>
> I don't have a strong objection to moving it out to a 'top level'
> component -- it just seems premature when there is no pressing need to
> do so. If somebody declared a porting problem, or DRLVM gurus said they
> want easier access to use it then sure. Perhaps there is a driver that
> I'm not seeing here.
>
> It sounds like it is just a move within the project, not a re-architecture.
>
> Regards,
> Tim
>
Re: [general] Should we make portlib a separate component?
Posted by Tim Ellison <t....@gmail.com>.
Mark Hindess 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.
Well it isn't today. DRLVM and jdktools do their own thing, so it
really is just a factoring of the class library code.
> 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.
I don't see why this a problem. We have control over both sides of the
API boundary, so changing the API to suit a usecase better is fine,
provided the implementation and its usage is changed simultaneously --
and it was.
We don't promote the portlib APIs for our end users to use. If we did
then of course we would have to be more careful. Even internally, like
the VMI, we are careful when there are internal users.
> 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.
I see what you are saying, but again, I'm yet to be convinced there is a
problem being solved here. Why not also version control the hycommon,
hythread, etc internal APIs too?
> 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?
I don't have a strong objection to moving it out to a 'top level'
component -- it just seems premature when there is no pressing need to
do so. If somebody declared a porting problem, or DRLVM gurus said they
want easier access to use it then sure. Perhaps there is a driver that
I'm not seeing here.
It sounds like it is just a move within the project, not a re-architecture.
Regards,
Tim
Re: [general] Should we make portlib a separate component?
Posted by Xiao-Feng Li <xi...@gmail.com>.
I fully agree with this proposal. It makes at least a common native
resource manager easier for native memory, file handles, etc.
Thanks,
xiaofeng
On Feb 4, 2008 11:18 PM, Mark Hindess <ma...@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.
>
>
>
--
http://xiao-feng.blogspot.com