harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Chernyshev <a.y.chernys...@gmail.com>
Subject Re: Using APR for Harmony's native link to the OS?
Date Fri, 10 Feb 2006 18:03:17 GMT
On 2/10/06, Enrico Migliore <enrico.migliore@fatti.com> wrote:
> Stefano Mazzocchi wrote:
>
> > tellison@apache.org wrote:
> >
> >> Author: tellison
> >> Date: Fri Feb 10 05:57:38 2006
> >> New Revision: 376690
> >>
> >> URL: http://svn.apache.org/viewcvs?rev=376690&view=rev
> >> Log:
> >> Applying patches received as HARMONY-42 (com.ibm.io.nio.FileChannel
> >> is not fully implemented)
> >>  - refactoring of some java platform code
> >>  - additional behavior on NIO file channels
> >>  - refactoring of some IO code
> >>  - work in progress on memory mapping
> >
> >
> > Tim's commits made me think about something that I thought about a
> > loooooong time ago (probably 1999) in the "would be awesome" kind of
> > department but I put off for a future where we would have a project to
> > work on a JVM.
> >
> > turns out we do have one now and turns out that APR[1] is a library
> > that is now very solid and reached API stability over years of work by
> > a lot of people.
> >
> > so, here it is, does it make sense to have harmony depend on APR and
> > therefore abstract away all those OS-specificities? (I'm talking about
> > both the VM and the native part of the class library).
> >
> > It also has a major social side effects: it would create the ultimate
> > social bridge between the HTTPD/APR side of the foundation and the
> > java side of the foundation, maybe allowing people from one side to
> > contribute to the other, or, at least to help out in the interface
> > between them which naturally is the JVM.
> >
> > What do you think?
> >
> > [1] http://apr.apache.org/
> >
> I haven't gone through the APR library therefore I don't know how many
> layers (i.e. function calls)
> it puts between Apache and the underlying OS.
>

I was looking into APR's part which is responsible for threading
(threadproc and locks). From what I've seen, I've got an impression
that the APR does almost exactly what I would do in order to find a
smallest "common denominator" between, for example, Win32 threading
API and pthreads. So in my opinion it is pretty much close to the
concept of thin portability layer we may need between VM/Classlib and
OS.

> As far as the the native code of the Classlib and the VM is concerned, I
> think that we should keep it
> as thinner as possible in order to:
>
>        1. have Java programs run fast

I suspect the performance could be a requirement for HTTPD as well.

>        2. ease portability to different OS's and platforms (embedded
> systems included)

Yes, this means some layer between VM/Classlib and OS is needed
anyways, and it might be good to reuse some of the existing "standard"
solutions, rather than try to create one more. It seems that HTTPD
mist be in the same position regarding the performance and portability
requirements. Therefore, I would agree with the point that having a
shared layer for two different projects, like HTTPD and Harmony, could
be beneficial for both of them.


Thank you,
Andrey Chernyshev
Intel Middleware Products Division


>
> The GNU/Classpath guys, for example, have defined a standard interface
> to underlying OS
> and that's it. Therefore I don't think we really need the APR layer.
>
> Enrico
>
>
>
>
>
>
>

Mime
View raw message