You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Weldon Washburn <we...@gmail.com> on 2006/09/22 20:28:25 UTC

[classlib][launcher] I am looking at the interaction between {classlib, launcher, drlvm} and {hysock, hysig, hythread}

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

Re: [classlib][launcher] I am looking at the interaction between {classlib, launcher, drlvm} and {hysock, hysig, hythread}

Posted by Weldon Washburn <we...@gmail.com>.
gpProtectedMain() is in

classlib/trunk/modules/luni/src/main/native/launcher/shared/main.c

signalProtectedMain() is in

classlib/trunk/modules/luni/src/main/native/launcher/shared/cmain.c

Incidentally, I am noticing that portlib gets initialized with a default
copy of

MasterPortLibraryTable from portpriv.h.  This could be causing all kinds of
undefined behavior.

I think shortly after hyport_create_library() is called, we should re-write
the functions to point into DRLVM thread manager.  Andrey Chernyshev -- what
do you think?



On 9/26/06, Leo Li <li...@gmail.com> wrote:
>
> Hi, Weldon:
>     Which file includes signalProtectMain() or  gpProtectedMain ? :)
>
>
> On 9/25/06, Weldon Washburn <we...@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 <we...@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
>
>


-- 
Weldon Washburn
Intel Middleware Products Division

Re: [classlib][launcher] I am looking at the interaction between {classlib, launcher, drlvm} and {hysock, hysig, hythread}

Posted by Leo Li <li...@gmail.com>.
Hi, Weldon:
     Which file includes signalProtectMain() or  gpProtectedMain ? :)


On 9/25/06, Weldon Washburn <we...@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 <we...@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

Re: [classlib][launcher] I am looking at the interaction between {classlib, launcher, drlvm} and {hysock, hysig, hythread}

Posted by Paulex Yang <pa...@gmail.com>.
Weldon Washburn wrote:
> On 9/26/06, Leo Li <li...@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 
<ci...@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 <we...@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 <we...@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


Re: [classlib][launcher] I am looking at the interaction between {classlib, launcher, drlvm} and {hysock, hysig, hythread}

Posted by Leo Li <li...@gmail.com>.
Hi, Weldon:
     If you have a built Harmony classlib, you can find the doc in
HarmonyRoot/doc/vm_doc/html/group__Port.html or other htmls in the
directory.

On 9/27/06, Weldon Washburn <we...@gmail.com> wrote:
>
> On 9/26/06, Leo Li <li...@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?
>
> On 9/25/06, Weldon Washburn <we...@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 <we...@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
> >
> >
>
>
> --
> Weldon Washburn
> Intel Middleware Products Division
>
>


-- 
Leo Li
China Software Development Lab, IBM

Re: [classlib][launcher] I am looking at the interaction between {classlib, launcher, drlvm} and {hysock, hysig, hythread}

Posted by Weldon Washburn <we...@gmail.com>.
On 9/26/06, Leo Li <li...@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?

On 9/25/06, Weldon Washburn <we...@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 <we...@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
>
>


-- 
Weldon Washburn
Intel Middleware Products Division

Re: [classlib][launcher] I am looking at the interaction between {classlib, launcher, drlvm} and {hysock, hysig, hythread}

Posted by Leo Li <li...@gmail.com>.
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?:)



On 9/25/06, Weldon Washburn <we...@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 <we...@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

Re: [classlib][launcher] I am looking at the interaction between {classlib, launcher, drlvm} and {hysock, hysig, hythread}

Posted by Weldon Washburn <we...@gmail.com>.
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 <we...@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