harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paulex Yang <paulex.y...@gmail.com>
Subject Re: [classlib][launcher] I am looking at the interaction between {classlib, launcher, drlvm} and {hysock, hysig, hythread}
Date Thu, 28 Sep 2006 08:42:38 GMT
Weldon Washburn wrote:
> On 9/26/06, Leo Li <liyilei1979@gmail.com> wrote:
>>
>> Hi, Weldon:
>>     The usage of the argument of portLibrary is for the function to call
>> other functions of the port library if needed. The argument is just a
>> virtual function table, as you said, can be any implemenatation of the
>> HyPortLibrary struct, not only the HyPortLibrary struct the function
>> belongs
>> to. Of course, different HyPortLibrary might lead to different 
>> behavior of
>> the function if the HyPortLibrary is used by it.
>>     I think the main purpose of the design is to alter some function 
>> of a
>> specified HyPortLibrary struct flexibly, especially at runtime: What is
>> necessary to do is just to change an entry in HyPortLibrary while the
>> altered function can make use of other functions as well as other
>> functions
>> can use it.
>>    Am I all right?:)
>
>
>
> Hmmm... Interesting idea you have.  Basically the idea is to rewrite the
> virtual function table _before_ any of the functions are used.  This 
> makes
> much more sense than the way drlvm currently boots up.  By the way, is 
> there
> any documentation that says what you are suggesting?  In other words, was
> portlib specifically designed to do what you suggest?
I think so, here below the part of portlib document at {harmony svn 
root}/enhanced/classlib/trunk/doc/vm_doc/html/group__Port.html

"The port library is implemented as a table of function pointers. One 
advantage of a function pointer based table is the ability to replace 
any functionality without recompiling the entire Java virtual machine. 
For example if an application is experiencing a memory leak, the memory 
management functions of the port library can be replaced to help 
determine the root cause of this leak. Alternatively applications 
wishing to control all memory allocation can provide their own routines 
to override the platform specific allocation and deallocation of memory.

Various implementations of the port library may choose not to implement 
all functionality contained in the port library table. If a platform 
does not support sockets, and thus the Java virtual machine does not 
utilize sockets, the port library does not need to provide a valid 
socket behavior. The port library contains version control information 
<cid:part1.01000201.01070009@gmail.com> that enables applications to 
determine if required functionality is supported. In addition the 
version control information allows applications to determine if the port 
library provided is compatible with the one which they were compiled 
against."

>
> On 9/25/06, Weldon Washburn <weldonwjw@gmail.com> wrote:
>> >
>> > It looks like hysignal.c is using the right monitor enter/exit().  
>> That
>> > is,
>> > the one
>> > from  drlvm/trunk/build/win_ia32_msvc_debug/deploy/jre/bin/hythr.dll
>> >
>> > However, a bunch of functions in classlib's hysignal.c have an 
>> incoming
>> > argument of "HyPortLibrary *portlib".  The portlib variable can either
>> > point
>> > to the original classlib portlib C struct.  Or it can point to PORTLIB
>> > which
>> > is a C struct with all the entries nulled out (more on this later.)
>> >
>> > I think the next question to ask is what hysignal.c does with
>> > the "HyPortLibrary *portlib" argument.  If anyone knows, please 
>> tell us.
>> > Otherwise I will keep digging.
>> >
>> > From stepping through DRLVM bootup, it looks like classlib's 
>> portlib is
>> > _dropped_  in signalProtectMain().  Then launcher gpProtectedMain 
>> calls
>> > invocation(PORTLIB,...) where PORTLIB is a nulled out HyPortLibrary C
>> > struct.  We need to put comments in the code describing the switch 
>> from
>> > classlib's portlib to drlvm's nulled out version.
>> >
>> > On 9/22/06, Weldon Washburn <weldonwjw@gmail.com> wrote:
>> > >
>> > > All,
>> > > Its not clear at this moment what threading implementation is being
>> > > executed when hysignal.c calls hythread_monitor_enter().  If someone
>> > > already knows, please tell us.  Otherwise,  I will step through it
>> with
>> > the
>> > > debugger to find out what is going on.
>> > >   - Weldon
>> > >
>> > > --
>> > > Weldon Washburn
>> > > Intel Middleware Products Division
>> > >
>> >
>> >
>> >
>> > --
>> > Weldon Washburn
>> > Intel Middleware Products Division
>> >
>> >
>>
>>
>> -- 
>> Leo Li
>> China Software Development Lab, IBM
>>
>>
>
>


-- 
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


Mime
View raw message