Salikh Zakirov wrote:
> Ronald Servant wrote:
>> On 1/31/07, Tim Ellison <[EMAIL PROTECTED]> wrote:
>>> Ah, the same way that we are doing the VMI library today. In fact, why
>>> not just make those thread functions part of the same VMI DLL, then
>>> there is only one stub replacement required?
>> Hmmm... seems like a good idea, but we need to have the portlib link
>> against a shared library named hythr, so that at runtime it can in
>> fact find the real one provided by VM, or I am missing something
>> obvious?
>
> In case of launcher this leads to a chicken-and-egg problem:
> launcher wants to use portlib before it parsed command line and
> decided what vmdir to add to PATH. If portlib will be linked to hythr.dll,
> then it defeats the purpose of having hythr.dll VM-specific, as VM-specific
> library is likely to be present in vmdir (and thus not available at the moment
> when hyprt.dll is loaded).
D'oh -- yes, and you said that once already but I have only just
understood what you meant.
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.
> 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.
Regards,
Tim
