On 1/30/07, Tim Ellison <[EMAIL PROTECTED]> 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
