harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [vmi] thread library
Date Tue, 30 Jan 2007 15:30:14 GMT
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?

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


View raw message