Hi Tim,
On 7/4/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
Andrey Chernyshev wrote:
> I'm not sure it is just a name clash problem - drlvm won't give the
> hythread library if the class lib hadn't requested it.
The classlib builds it's own copy of the hythread library, so there is
no need for a compatible VM to rebuild it or provide it.
VMs are free to use the thread library for their own implementation, or
use another thread library (but they shouldn't replace classlib's).
> The problem is
> that, the classlib will not work with it's original hythread library
> if the classlib is run with drlvm.
> This happens because, for example, monitor_enter() implementation of
> the hythread requires each thread be attached to the hythread library
> first (it requires
> a pointer to HyThread structure be stored in the TLS), but this can
> only be done by VM during thread creation.
> To solve this, VM either has to always register every new Java thread
> with the classlib's hythread library, or provide it's own
> implementation of the hythread.
Registering the thread creation is the preferred option.
I agree that this is the most easiest way. However, I don't know what
happens with other VM's, but in DRLVM thread creation takes approx.
~50% longer (on Windows) if it does hythread_attach for every new Java
thread.
Registering all new threads with the classlib's hythread also seems to
be an extra requirement for VM vendors which doesn't look quite
obvious to me, at least I wasn't able to catch this from the class
library porting documentation.
BTW, if the class libraries really need to do some synchronization in
the native code, may be we can consider using APR mutexes to do that?
As far as I remember APR mutexes do not require threads to be
registered in a special way with APR in order to use them, they simply
delegate to Enter/Leave CriticalSection on Windows and pthread_mutex
on Linux.
You can take a look at the "hythread emulation" library contained in the drlvm
(drlvm\vm\vmcore\src\thread\hythr\hythreads.cpp ) which implements the
hythread_monitor_enter/exit functions using APR and hence can work
without hythread_attach calls as well. Still, may be it isn't that
bad idea to replace the original hythread in classlib with the one
suggested by drlvm? It contains much less code but at the same it
seems like it does everything what the classlib really needs. :)
Seriously, it is not quite clear why the classlib would need such
comprehensive threading library written in a native code as long as
there is a rich set of J2SE threading API available for them.
Thanks,
Andrey.
> It seems that classlib's hythread implementation assumes that the
> hythread is shared between VM and classlib and VM is building it's
> threading subsystem on top of the hythread.
No that's not the case. For example the IBM VME and JCHEVM do not share
the classlib thread library, there is no need for DRLVM to do so if it
chooses.
Regards,
Tim
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Andrey Chernyshev
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
