You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Mark Hindess (JIRA)" <ji...@apache.org> on 2007/03/05 16:57:51 UTC
[jira] Updated: (HARMONY-3090) Create a new table based API for
thread library functions
[ https://issues.apache.org/jira/browse/HARMONY-3090?page=com.atlassian.jira.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=true 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.
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.
> 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.
> 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 = (*vmi)->GetPortLibrary(vmi); \
> HyThreadLibrary *privateThreadLibrary = privatePortLibraryForThread ->port_get_thread_library(privatePortLibraryForThread)
> THREAD_ACCESS_FROM_ENV and THREAD_ACCESS_FROM_JAVAVM would need to be modified in a similar way.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [vmi] [jira] Updated: (HARMONY-3090) Create a new table based API for thread library functions
Posted by 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.
>
RE: [jira] Updated: (HARMONY-3090) Create a new table based API for thread library functions
Posted by "Zakharov, Vasily M" <va...@intel.com>.
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?
Vasily Zakharov
Intel ESSD
-----Original Message-----
From: Mark Hindess (JIRA) [mailto:jira@apache.org]
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=com.atlassian.ji
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=true 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.
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.
> 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.
> 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 = (*vmi)->GetPortLibrary(vmi); \
> HyThreadLibrary *privateThreadLibrary = privatePortLibraryForThread
->port_get_thread_library(privatePortLibraryForThread)
> THREAD_ACCESS_FROM_ENV and THREAD_ACCESS_FROM_JAVAVM would need to be
modified in a similar way.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.