harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@apache.org>
Subject Re: [general] Should we make portlib a separate component?
Date Fri, 08 Feb 2008 23:54:08 GMT
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

Mime
View raw message