Re: [vmi] [jira] Updated: (HARMONY-3090) Create a new table based API for thread library functions

[Mark Hindess <ma...@googlemail.com>]

[ Sorry, I missed this originally and while trying to catch up with
where things were with this issue I finally noticed it. ]

On 7 March 2007 at 20:16, "Zakharov, Vasily M"
<va...@intel.com> wrote:
>
> Mark,
> 
> As far as I understand, this your patch overrides all the previous
> patches for this issue, and it may be applied without disrupting the
> operations of Classlib/IBM VM/DRL VM.
> 
> However, if classlib is built with -Dhy.no.thr=true flag, the hythr
> library is rebuilt with the new approach, and both IBM VM and DRL VM
> would not function until they're patched accrordingly.
> 
> Is my understanding correct?

Yes.  Both the IBM VM and DRL VM will need to be modified to produce an
hythr dll with the correct API (and HYTHR_0.2 version string).

The IBM VM is being fixed to produce the required library.  Has anyone
looked at making the necessary modifications to DRL VM?

Regards,
 Mark.

> -----Original Message-----
> From: Mark Hindess (JIRA) [mailto:jira@apache.org]=20
> Sent: Monday, March 05, 2007 6:58 PM
> To: commits@harmony.apache.org
> Subject: [jira] Updated: (HARMONY-3090) Create a new table based API for
> thread library functions
> 
> 
>      [
> https://issues.apache.org/jira/browse/HARMONY-3090?page=3Dcom.atlassian.j=
> i
> ra.plugin.system.issuetabpanels:all-tabpanel ]
> 
> Mark Hindess updated HARMONY-3090:
> ----------------------------------
> 
>     Attachment: harmony-3090-as-an-option.diff
> 
> In order to give VM a chance to get this change implemented,  I'd like
> to see this change implemented as an option.  So I've updated Ron's
> patch to work against latest trunk and use a -Dhy.no.thr=3Dtrue ant =
> flag.
> To simplify the patch, I moved the thread changes to a new thrstub tree,
> and I moved the hythread.h include to be picked up from there too.  I
> also fixed a few compile problems on linux - in addition to the one
> Salikh mentions above.=20
> 
> Tim, feel free to assign this to me (or keep it if you prefer).
> 
> 
> 
> > Create a new table based API for thread library functions
> > ---------------------------------------------------------
> >
> >                 Key: HARMONY-3090
> >                 URL:
> https://issues.apache.org/jira/browse/HARMONY-3090
> >             Project: Harmony
> >          Issue Type: Improvement
> >          Components: Classlib
> >            Reporter: Ronald Servant
> >         Assigned To: Tim Ellison
> >         Attachments: harmony-3090-as-an-option.diff,
> launcher_02052007_patch.txt, thread_api_harmony_patch_20070130a.txt,
> thread_api_harmony_patch_20070206.txt
> >
> >
> > Both DRLVM and the IBM VME maintain their own implementations of the
> hythr shared library (not always named hythr).  This leads to a
> situation where the VM is linked against one of the shared libraries and
> the classlib is linked against another.  The internal implementation of
> hythr assumes a certain amount of coordination between the threading
> functions.  For the most part this does not lead to problems when things
> aren't co-ordinated.  However there have been issues.
> > One such issue would involve thread local storage (TLS).  The Harmony
> implementation of TLS uses static variables as the basis for its
> implementation.  Those statics are confined on a shared library basis.
> Meaning that if a TLS value was being set when the VM called a thread
> lib function, a call to a thread lib function from the classlib would
> not see that TLS data.  This is due to the VM and classlib using
> different thread library shared libraries. =20
> > The above is the case when the shared libraries contain the same
> implementation.  A similar scenario arises when the shared libraries for
> threading do not contain the same implementation. =20
> > The thread library used by the VM, for example, could be relying on
> some storing values in TLS that will modify the behaviour of other calls
> to thread library functions.  When the classlib calls it's own
> implementation of thread library functions, the behvaiour of those
> functions will not be modified by the values set in TLS by the VM.  This
> could lead interesting hard to diagnose failures in the runtime as a
> whole.
> > A solution to these problems would be to create a standard thread API,
> much like the one created for the port library.
> > The VM would become responsible for providing the hythr shared
> library. The classlib (and other tools that use threading functions)
> would compile against the API and no-opt implementation of hythr.
> > The attached patch is one possible implementation of this idea.  It
> creates a thread library table (HyThreadLibrary) much like the port
> library table.  The thread library is created by the port library during
> the port library's initialization.  The thread library can be obtained
> from the port library using the new port_get_thread_library() function.
> 
> > Also, the VMI has been extended to include a new GetThreadLibrary()
> function.  Alternatively, we could leave the VMI as is and modify the
> following defines in hythread.h to:
> > #define THREAD_ACCESS_FROM_VMI(vmi) HyPortLibrary
> *privatePortLibraryForThread =3D (*vmi)->GetPortLibrary(vmi); \
> > HyThreadLibrary *privateThreadLibrary =3D privatePortLibraryForThread
> ->port_get_thread_library(privatePortLibraryForThread)
> > THREAD_ACCESS_FROM_ENV and THREAD_ACCESS_FROM_JAVAVM would need to be
> modified in a similar way.
> 
> --=20
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>