harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Angela Lin" <alin.harm...@gmail.com>
Subject Re: [vmi] thread library
Date Tue, 30 Jan 2007 18:31:22 GMT
On 1/30/07, Tim Ellison <t.p.ellison@gmail.com> wrote:
> Salikh Zakirov wrote:
> > Tim Ellison wrote:
> >> ... there is a dependency on
> >> threadlib from the portlib, and the portlib functions don't get a
> >> reference that can reach 'back' to the VMI struct.
> >>
> >> So while it may be apparent in the launcher, it would be equally
> >> apparent in the portlib functions themselves, since they would have no
> >> reachable threadlib.
> >>
> >> So maybe, as you say, we need to make the threadlib functions an
> >> extension of the current portlib function table rather than the VMI
> >> struct, and have them provided by a DLL loaded by the VM (and the thread
> >> function table populated in the portlib initialization code).
> >>
> >> Any other options?
> >
> > The list of dependencies of port library on thread library is as follows
> > (got from `dumpbin /imports hyprt.dll`)
> >
> >                    48 hythread_tls_get
> >                    40 hythread_self
> >                    49 hythread_tls_set
> >                    47 hythread_tls_free
> >                    23 hythread_monitor_exit
> >                    2B hythread_monitor_notify_all
> >                    14 hythread_global
> >                    32 hythread_monitor_wait
> >                     4 hythread_attach
> >                     9 hythread_detach
> >                    20 hythread_monitor_destroy
> >                    28 hythread_monitor_init_with_name
> >                    21 hythread_monitor_enter
> >                    45 hythread_tls_alloc
> >
> >
> > Analysis:
> >
> > * hythread_tls_get, hythread_tls_set, hythread_tls_free, hythread_tls_alloc,
> > hythread_self are used exclusively for TLS access, which can be provided by
> > thin OS-function wrappers independently of the threading library.
>
> Right, so these can be an extension of the portlib functionality (no VM
> interaction required).
>
> > Attached patch is a dirty way to eliminate dependency,
> > intended as an illustration of how this can be done.
> >
> > * hythread_global is used exclusively as hythread_global("global_monitor"),
> > with a purpose of having one big lock. I'm not exactly sure if it is relevant
> > that LUNI and ARCHIVE want to use the same global monitor. I suspect that this
> > is not really needed, and PORTLIB, ARCHIVE and LUNI can use different monitors.
>
> Requires a bit of investigation -- you may well be right, it may be a
> hang over from the days when the code was all globbed together.
>
> > * hythread_monitor_ functions provide native synchronization primitives, which
> > are not connected to java objects in any way, and are not exposed to the VM,
> > so these also can be implemented directly in portlib as thin OS-function wrappers.
>
> But does the VM need to know when a thread has acquired an OS monitor?
> e.g. for monitoring/deadlock detection/debugging.
>
> Angela: do you have any insight here?

This sounds like the same discussion we had when we were deciding
whether the classlib should use hythr at all or some other lower-level
API.

Yes, you could bypass hythr in the portlib by using a lower-level API.
However, you will also bypass any VM instrumentation/debug tooling in
hythr. Customers would probably not like this approach. For example, I
think we've had complaints when our dump tooling didn't show details
of unattached threads in the VM process.

I prefer the idea of Ron's approach.

I'll comment more on specific hythr API functions a bit later.

Angela

>
> > * hythread_attach and hythread_detach -- these imply attaching thread to the
> > VM, and thus cannon be implemented without dependency on threading library.
>
> A quick grep of the portlib code implies that these are only used in the
>  signal handling code on Windows. Perhaps we can move that signal
> handling code.
>
> > Resume:
> >
> > it seems that the issue of making thread library completely VM-specific boils
> > down to finding a good way of attaching/detaching a thread to/from VM.
> >
> > Currently, I'm not sure how can this be done, since the first time launcher
> > initializes the porting library, and port library calls hythread_attach(), is
> > even before launcher knows which VM it will use. Chicken-and-egg problem again.
> >
> > Thoughts?
>
> Thanks for the analysis.  We might be able to refactor the signal
> handling code... thinking...
>
> Tim

Mime
View raw message