You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Marina Goldburt <ma...@gmail.com> on 2006/06/19 14:10:15 UTC
portlib functionality
Hi,
As I see the main idea of the port library is " isolates all platform
specific knowledge to one area", as written at "http://svn.apache.org/viewvc
/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/group__Port.html ".
However, I've noticed that the code for sig, thread and luni modules also
contain the platform-dependent code.
For example, Java_org_apache_harmony_luni_platform_OSFileSystem_unlockImpl
function contains:
rc = UnlockFileEx ((HANDLE) handle, (DWORD) 0,
nNumberOfBytesToUnlockLow,
nNumberOfBytesToUnlockHigh, (LPOVERLAPPED) & overlapped);
Where the handle was produced by hyfile_open function. It will lead to
problems when somebody tries to replace the portlib with a
different implementation, that can use not os-handles.
Will it make sense to extend the portlib functionality and move such
platform-dependent code from sig, thread, luni modules to the portlib?
Marina.
Re: portlib functionality
Posted by Geir Magnusson Jr <ge...@pobox.com>.
<putting on MailListNag hat>
can we please try to remember to categorize our subject lines?
:)
geir
Marina Goldburt wrote:
> Hi,
>
> As I see the main idea of the port library is " isolates all platform
> specific knowledge to one area", as written at
> "http://svn.apache.org/viewvc
> /incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/group__Port.html
> ".
>
> However, I've noticed that the code for sig, thread and luni modules also
> contain the platform-dependent code.
> For example, Java_org_apache_harmony_luni_platform_OSFileSystem_unlockImpl
> function contains:
> rc = UnlockFileEx ((HANDLE) handle, (DWORD) 0,
> nNumberOfBytesToUnlockLow,
> nNumberOfBytesToUnlockHigh, (LPOVERLAPPED) & overlapped);
> Where the handle was produced by hyfile_open function. It will lead to
> problems when somebody tries to replace the portlib with a
> different implementation, that can use not os-handles.
>
> Will it make sense to extend the portlib functionality and move such
> platform-dependent code from sig, thread, luni modules to the portlib?
>
> Marina.
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: portlib functionality
Posted by Marina Goldburt <ma...@gmail.com>.
> >And the short answer is "yes". The additional file system functionality
> >such as file locking and memory mapping required by the (newly authored
> >within this project) NIO code should be put into the port library.
And what about hythread platform-dependent code? Have the thread and process
routines to be the part of the portlib?
Marina
Re: portlib functionality
Posted by Oliver Deakin <ol...@googlemail.com>.
Marina Goldburt wrote:
> On 7/25/06, Tim Ellison <t....@gmail.com> wrote:
>
>> If you honour the existing table layout then you don't need to break
>> compatibility. In addition, VMs are not required to use the class
>> library portlib if they choose not to.
>
> I don't know the way IBM VME uses the portlibrary, but concerning the
> DRLVM
> (vm/vmi/src/vmi.cpp), the DRLVM needs recompilation if the HyPortLibrary
> structure changes as Paulex described.
>
>>> But it's ok since
>> >Harmony has its own vm and nobody uses j9 vm binaries.
>
>> This is a joke right? There are three VMs in various states of
>> development at Harmony, and people are also using the IBM VME.
>
> As the official Apache Harmony site doesn't have the link to IBM VME, I
> thought people are not using it.
Not meaning to speak for Tim, but just for your (and anyone else's
reading this)
info, there is actually a link to the IBM VME download site on the
"Building
the Apache Harmony Class Library" page [1].
Regards,
Oliver
[1]
http://incubator.apache.org/harmony/subcomponents/classlibrary/build_classlib.html
> And about IBM VME, are there any plans to publish the binaries for 64-bit
> platforms?
>
> Thanks, Marina
>
--
Oliver Deakin
IBM United Kingdom Limited
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: portlib functionality
Posted by Marina Goldburt <ma...@gmail.com>.
On 7/25/06, Tim Ellison <t....@gmail.com> wrote:
>If you honour the existing table layout then you don't need to break
>compatibility. In addition, VMs are not required to use the class
>library portlib if they choose not to.
I don't know the way IBM VME uses the portlibrary, but concerning the DRLVM
(vm/vmi/src/vmi.cpp), the DRLVM needs recompilation if the HyPortLibrary
structure changes as Paulex described.
>> But it's ok since
> >Harmony has its own vm and nobody uses j9 vm binaries.
>This is a joke right? There are three VMs in various states of
>development at Harmony, and people are also using the IBM VME.
As the official Apache Harmony site doesn't have the link to IBM VME, I
thought people are not using it.
And about IBM VME, are there any plans to publish the binaries for 64-bit
platforms?
Thanks, Marina
Re: portlib functionality
Posted by Tim Ellison <t....@gmail.com>.
(Thanks for bringing this onto the list Paulex)
On 25/07/06, Marina Goldburt <ma...@gmail.com> wrote:
> Yes, this is the straightforward mechanism.
>
> The only objection is that adding all the missed functions to the
> HyPortLibrary structure leads to its significant growing.
We should discuss what functions you see as candidates for extension
to the portlibrary.
> The second was that this mechanism needs vm recompilation.
If you honour the existing table layout then you don't need to break
compatibility. In addition, VMs are not required to use the class
library portlib if they choose not to.
> But it's ok since
> Harmony has its own vm and nobody uses j9 vm binaries.
This is a joke right? There are three VMs in various states of
development at Harmony, and people are also using the IBM VME.
Regards,
Tim
> On 7/25/06, Paulex Yang <pa...@gmail.com> wrote:
> >
> > Marina,
> >
> > Actually... I didn't catch up here about "how the portlib can be
> > extended", if you mean what API should look like about the mmap portable
> > version, yes, I meant this; or if you mean the portlib's mechanism to
> > extension, I thought it is straightforward, so please correct me if I
> > make mistakes or miss sth., I thought it needs three steps:
> >
> > 1. Modify hyport.h to add the function prototyp, add the new function
> > prototypes to function table(Struct HyPortLibrary), add a macro to
> > access the new item(like #define hystr_printf
> > privatePortLibrary->str_printf)
> > 2. add the function declaration in portpriv.h, and add the reference to
> > function table instance(MasterPortLibraryTable)
> > 3. implement the function for every platform, and modify makefile if
> > necessary
> >
> > BTW, would you mind if I forward this to the mailing list? I think
> > probably more people will have interest on this topic:).
> >
> > Marina Goldburt wrote:
> > > Paulex,
> > >
> > > As I understand, the proposal'll be about how the portlib can be
> > extended?
> > > While you're preparing the proposal, I'll look through the classlib
> > > code and try to prepare the list of the possible portlib extensions.
> > >
> > > Thanks, Marina.
> > >
> > >
> > > On 7/25/06, *Paulex Yang* <paulex.yang@gmail.com
> > > <ma...@gmail.com>> wrote:
> > >
> > > Marina,
> > >
> > > I've completed the implementation of mmap, and they are good
> > > candidates
> > > to be refactored as extension of portlib. I'm a little guilty that
> > it
> > > appears in slow paces...I'll post a proposal about this soon.
> > >
> > > And I believe there are other candidates in NIO and other
> > > modules(FileLock, ICMP ECHO REQUEST, etc), your (and anyone others')
> > > ideas and suggestions are welcome:).
> > >
> > > Marina Goldburt wrote:
> > > > Hi, Paulex,
> > > >
> > > > On 7/7/06, *Paulex Yang* <paulex.yang@gmail.com
> > > <ma...@gmail.com>
> > > > <mailto:paulex.yang@gmail.com <ma...@gmail.com>>>
> > > wrote:
> > > >
> > > > Yes, I'm working on the FileChannel completion, and my
> > > thought is to
> > > > write platform dependent codes for mmap at first(I thought it
> > is
> > > > easier
> > > > to be accepted, so that things can be moved forward), then
> > > propose a
> > > > mmap related extension to portlib, and if it is accepted,
> > > refactor the
> > > > codes. The current portlib's mmap API cannot meet the
> > > requirement
> > > > of nio
> > > > in several ways:
> > > > 1. cannot map file in modes other than Copy-On-Write
> > > > 2. cannot map part of file
> > > > 3. cannot pick up the opened file descriptor as parameter
> > > >
> > > > Will look at the file locking later...And I'm sure there are
> > > other
> > > > things worthing evaluation to be portlib extension.
> > > >
> > > >
> > > > What is the current state of your development?
> > > > As I see, you didn't extend portlib functionality yet.
> > > > How are you going to do it?
> > > >
> > > > As everybody agrees that moving all platform-dependent code of the
> > > > luni module to the portlib is the correct idea,
> > > > let's discuss the way the portlib can be extended.
> > > >
> > > > Marina.
> > > >
> > >
> > >
> > > --
> > > Paulex Yang
> > > China Software Development Lab
> > > IBM
> > >
> > >
> > >
> >
> >
> > --
> > Paulex Yang
> > China Software Development Lab
> > IBM
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: portlib functionality
Posted by Marina Goldburt <ma...@gmail.com>.
Yes, this is the straightforward mechanism.
The only objection is that adding all the missed functions to the
HyPortLibrary structure leads to its significant growing.
The second was that this mechanism needs vm recompilation. But it's ok since
Harmony has its own vm and nobody uses j9 vm binaries.
Marina.
On 7/25/06, Paulex Yang <pa...@gmail.com> wrote:
>
> Marina,
>
> Actually... I didn't catch up here about "how the portlib can be
> extended", if you mean what API should look like about the mmap portable
> version, yes, I meant this; or if you mean the portlib's mechanism to
> extension, I thought it is straightforward, so please correct me if I
> make mistakes or miss sth., I thought it needs three steps:
>
> 1. Modify hyport.h to add the function prototyp, add the new function
> prototypes to function table(Struct HyPortLibrary), add a macro to
> access the new item(like #define hystr_printf
> privatePortLibrary->str_printf)
> 2. add the function declaration in portpriv.h, and add the reference to
> function table instance(MasterPortLibraryTable)
> 3. implement the function for every platform, and modify makefile if
> necessary
>
> BTW, would you mind if I forward this to the mailing list? I think
> probably more people will have interest on this topic:).
>
> Marina Goldburt wrote:
> > Paulex,
> >
> > As I understand, the proposal'll be about how the portlib can be
> extended?
> > While you're preparing the proposal, I'll look through the classlib
> > code and try to prepare the list of the possible portlib extensions.
> >
> > Thanks, Marina.
> >
> >
> > On 7/25/06, *Paulex Yang* <paulex.yang@gmail.com
> > <ma...@gmail.com>> wrote:
> >
> > Marina,
> >
> > I've completed the implementation of mmap, and they are good
> > candidates
> > to be refactored as extension of portlib. I'm a little guilty that
> it
> > appears in slow paces...I'll post a proposal about this soon.
> >
> > And I believe there are other candidates in NIO and other
> > modules(FileLock, ICMP ECHO REQUEST, etc), your (and anyone others')
> > ideas and suggestions are welcome:).
> >
> > Marina Goldburt wrote:
> > > Hi, Paulex,
> > >
> > > On 7/7/06, *Paulex Yang* <paulex.yang@gmail.com
> > <ma...@gmail.com>
> > > <mailto:paulex.yang@gmail.com <ma...@gmail.com>>>
> > wrote:
> > >
> > > Yes, I'm working on the FileChannel completion, and my
> > thought is to
> > > write platform dependent codes for mmap at first(I thought it
> is
> > > easier
> > > to be accepted, so that things can be moved forward), then
> > propose a
> > > mmap related extension to portlib, and if it is accepted,
> > refactor the
> > > codes. The current portlib's mmap API cannot meet the
> > requirement
> > > of nio
> > > in several ways:
> > > 1. cannot map file in modes other than Copy-On-Write
> > > 2. cannot map part of file
> > > 3. cannot pick up the opened file descriptor as parameter
> > >
> > > Will look at the file locking later...And I'm sure there are
> > other
> > > things worthing evaluation to be portlib extension.
> > >
> > >
> > > What is the current state of your development?
> > > As I see, you didn't extend portlib functionality yet.
> > > How are you going to do it?
> > >
> > > As everybody agrees that moving all platform-dependent code of the
> > > luni module to the portlib is the correct idea,
> > > let's discuss the way the portlib can be extended.
> > >
> > > Marina.
> > >
> >
> >
> > --
> > Paulex Yang
> > China Software Development Lab
> > IBM
> >
> >
> >
>
>
> --
> Paulex Yang
> China Software Development Lab
> IBM
>
>
>
Re: portlib functionality
Posted by Marina Goldburt <ma...@gmail.com>.
Hi, Paulex,
On 7/7/06, Paulex Yang <pa...@gmail.com> wrote:
> Yes, I'm working on the FileChannel completion, and my thought is to
> write platform dependent codes for mmap at first(I thought it is easier
> to be accepted, so that things can be moved forward), then propose a
> mmap related extension to portlib, and if it is accepted, refactor the
> codes. The current portlib's mmap API cannot meet the requirement of nio
> in several ways:
> 1. cannot map file in modes other than Copy-On-Write
> 2. cannot map part of file
> 3. cannot pick up the opened file descriptor as parameter
>
> Will look at the file locking later...And I'm sure there are other
> things worthing evaluation to be portlib extension.
What is the current state of your development?
As I see, you didn't extend portlib functionality yet.
How are you going to do it?
As everybody agrees that moving all platform-dependent code of the luni
module to the portlib is the correct idea,
let's discuss the way the portlib can be extended.
Marina.
Re: portlib functionality
Posted by Paulex Yang <pa...@gmail.com>.
Marina,
Marina Goldburt wrote:
> Tim, Paulex,
>
>> Will look at the file locking later...And I'm sure there are other
>> things worthing evaluation to be portlib extension.
>
> And what is the way to extend the portlib functionality? If we add all
> the
> missing functions to the HyPortLibrary structure, the structure will grow
> awfully. And, as I understand, every change in the structure leads to vm
> recompilation.
Totally agree with you that the portlib modification is serious, so I
think the extension should be considered and discussed on the mailing
list carefully at first...
>
> I can prepare a patch that moves platform-dependent file I/O
> operations from
> luni/luni to luni/port submodule. Is it will be useful?
That of course will be useful, thank you for the initiative. But it will
be even better if you, before creating the patch, propose your plan on
the mailing list at first:)
>
> Marina
>
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: portlib functionality
Posted by "Jimmy, Jing Lv" <fi...@gmail.com>.
Marina Goldburt wrote:
> Tim, Paulex,
>
>> Will look at the file locking later...And I'm sure there are other
>> things worthing evaluation to be portlib extension.
>
> And what is the way to extend the portlib functionality? If we add all the
> missing functions to the HyPortLibrary structure, the structure will grow
> awfully. And, as I understand, every change in the structure leads to vm
> recompilation.
>
> I can prepare a patch that moves platform-dependent file I/O operations
> from
> luni/luni to luni/port submodule. Is it will be useful?
>
> Marina
>
A great idea! :) But as I know, some of the methods are a bit complex
and require well-design on api, e.g., selectImpl() in luni, which was
written into one method in Harmony native code, but IMHO if removes into
portlib, it must be separated into two or three methods, and should be
design carefully. So I suggest more discussion on this. :)
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: portlib functionality
Posted by Marina Goldburt <ma...@gmail.com>.
Tim, Paulex,
>Will look at the file locking later...And I'm sure there are other
>things worthing evaluation to be portlib extension.
And what is the way to extend the portlib functionality? If we add all the
missing functions to the HyPortLibrary structure, the structure will grow
awfully. And, as I understand, every change in the structure leads to vm
recompilation.
I can prepare a patch that moves platform-dependent file I/O operations from
luni/luni to luni/port submodule. Is it will be useful?
Marina
Re: portlib functionality
Posted by Paulex Yang <pa...@gmail.com>.
Tim Ellison wrote:
> (Apologies for the very late response, I'm way behind on my 'must
> respond' list)...
>
> Marina Goldburt wrote:
>
>> Hi,
>>
>> As I see the main idea of the port library is " isolates all platform
>> specific knowledge to one area", as written at
>> "http://svn.apache.org/viewvc
>> /incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/group__Port.html
>> ".
>>
>> However, I've noticed that the code for sig, thread and luni modules also
>> contain the platform-dependent code.
>> For example, Java_org_apache_harmony_luni_platform_OSFileSystem_unlockImpl
>> function contains:
>> rc = UnlockFileEx ((HANDLE) handle, (DWORD) 0,
>> nNumberOfBytesToUnlockLow,
>> nNumberOfBytesToUnlockHigh, (LPOVERLAPPED) & overlapped);
>> Where the handle was produced by hyfile_open function. It will lead to
>> problems when somebody tries to replace the portlib with a
>> different implementation, that can use not os-handles.
>>
>> Will it make sense to extend the portlib functionality and move such
>> platform-dependent code from sig, thread, luni modules to the portlib?
>>
>
> And the short answer is "yes". The additional file system functionality
> such as file locking and memory mapping required by the (newly authored
> within this project) NIO code should be put into the port library.
>
> Paulex: is this this something you are considering?
>
Yes, I'm working on the FileChannel completion, and my thought is to
write platform dependent codes for mmap at first(I thought it is easier
to be accepted, so that things can be moved forward), then propose a
mmap related extension to portlib, and if it is accepted, refactor the
codes. The current portlib's mmap API cannot meet the requirement of nio
in several ways:
1. cannot map file in modes other than Copy-On-Write
2. cannot map part of file
3. cannot pick up the opened file descriptor as parameter
Will look at the file locking later...And I'm sure there are other
things worthing evaluation to be portlib extension.
> Regards,
> Tim
>
>
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: portlib functionality
Posted by Tim Ellison <t....@gmail.com>.
(Apologies for the very late response, I'm way behind on my 'must
respond' list)...
Marina Goldburt wrote:
> Hi,
>
> As I see the main idea of the port library is " isolates all platform
> specific knowledge to one area", as written at
> "http://svn.apache.org/viewvc
> /incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/group__Port.html
> ".
>
> However, I've noticed that the code for sig, thread and luni modules also
> contain the platform-dependent code.
> For example, Java_org_apache_harmony_luni_platform_OSFileSystem_unlockImpl
> function contains:
> rc = UnlockFileEx ((HANDLE) handle, (DWORD) 0,
> nNumberOfBytesToUnlockLow,
> nNumberOfBytesToUnlockHigh, (LPOVERLAPPED) & overlapped);
> Where the handle was produced by hyfile_open function. It will lead to
> problems when somebody tries to replace the portlib with a
> different implementation, that can use not os-handles.
>
> Will it make sense to extend the portlib functionality and move such
> platform-dependent code from sig, thread, luni modules to the portlib?
And the short answer is "yes". The additional file system functionality
such as file locking and memory mapping required by the (newly authored
within this project) NIO code should be put into the port library.
Paulex: is this this something you are considering?
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org