harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Salikh Zakirov <Salikh.Zaki...@Intel.com>
Subject Re: [vmi] thread library
Date Fri, 02 Feb 2007 10:11:37 GMT
The attached patch series explore the idea of making portlib mostly independent
of threading library. It changes portlib to use OS services (via thrdsup.h
macro wrappers). I have only tried it on Windows, and would like to have some
feedback before expending more effort on Linux version.

With these patches applied, the only threading functions called from portlib
are hythread_attach() and hythread_detach().

One pair of attach/detach calls was at portlib initialization and shutdown
stages. I figured it is not needed anymore, since portlib does not use thread
library services directly. Thus, the startup thread will be attached to the
thread library by the VM itself.

Another attach/detach pair is in consoleCtrlHandler, which obviously needs to
call into real thread library in order to provide signal handlers with fully
functional VM environment. Fortunately, after the VM is started, it could
initialize a thread library and pass a function table pointer to the portlib
(this is not in the patch series, but can be done).

Tim Ellison wrote:
> So the problem is that if we combine portlib & threadlib functions we
> would need a 'two-phase' portlib initialization, so that the launcher
> can use some of the portlib functions to find&load the VM-specific
> threadlib functions.

Exactly. The VM will need to set up a thread library and pass thread function
table pointer to the portlib at some stage.

>> Practically, at this moment this issue prevents having J9 and DRLVM
>> installation in the same jre/ directory, as both depend on different hythr.dll,
>> which needs to be along with hyprt.dll, and thus cannot be put into vmdir.
> Agreed.  The proposed patch hythread.c is providing a stub, so when we call:
> hyport_init_library
>   hyport_startup_library
>     hythread_allocate_library <- we want this provided by a vm-specific
>                                  hythr.dll loaded from the vm subdir,
>                                  in much the same way the launcher uses
> the portlib functionality to load a specific VM's vmi.dll from the vm
> subdir.

I propose a bit different approach: do not use threading library at portlib
initialization stage at all. In this way, port library will never need to load
a dummy library, and will always work with a genuine thread library provided by
the VM. In return, port library will only be able to use thread library after
VM was initialized.

Thus, thread library will not be initialized from within hyport_init_library(),
we will need to invent some new interface like


and call that from the VM after it loaded the thread library.

Thoughts, objections?
Salikh Zakirov

View raw message