On 6/23/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
Marina Goldburt wrote:
> Hi,
>
> I've noticed such a strange thing when examined drlvm building process.
> The drlvm replaces hythreads shared library with its own simple
> implementation based on APR. The drlvm hythreads library exports less
> than 1/2 functions comparing with the original hythr.dll.

Yes, that is strange.  Don't know why DRLVM would replace the classlib's
thread library -- seems a bit impolite ;-)

Sorry about that :)  Actually the issue was that the original hythread
library didn't work with the DRLVM - it required a thread to be
attached to the library because hythread monitors functions didn't
work otherwise. DRLVM has it's own threading code which wasn't
originally  based on the hythread.
Then the DRLVM did a quick solution - provided it's own hythr.dll
which exposes to class libraries only those functions which are really
needed.
I agree it doesn't look too nice, though it helped to make it working
with the classlib quickly.


> I thought the rest of functions are used by J9 VM, but
> replacing hythread classlib implementation with the slightly modified
> drlvm one doesn't lead to problems (all tests passed with j9 vm too).

The IBM VME doesn't use Harmony's thread library (there is a remarkably
similar library in the VM subdir called j9thr23).

And,of course, if other VM's want to use their own thread library they
are free to do so.

> So, the question : Why we have so much code in the hythreads module if
> nobody neads it?

The honest answer is, not all the thread library code is needed by
classlib -- but it forms a comprehensive library for any VM / classlib /
tools development.

If I understand correctly, classlibs are mostly using hythread for
synchronization purposes. Could the class libraries do all the needed
synchronization at the Java level by natural Java means like
synchronized blocks? In this case they won't need extra libraries
except java.lang.Object or java.lang.Thread.
Another advantage could be that Java monitors are well known to Java
debuggers while locating problems with synchronization of the native
code may require additional tools and hence could be more difficult...

Thanks,
Andrey.


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]



---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to