Re: [drlvm] DRLVM segfaults in hythread_tls_get()
On 7/7/06, Tim Ellison [EMAIL PROTECTED] wrote: Geir Magnusson Jr wrote: Actually, let me flip this the other way... What are the differences between the impl of the threading lib in DRLVM vs that in classlib? Yep, that is the right question. I don't know the answer, perhaps whoever made those changes can enlighten us. I guess these are the key differences: hythread in drlvm: - lightweight library which implements just the minimal set of functions that appeared to be needed for classlib to work, e.g. monitor_enter/exit and TLS support. - contains almost no code and delegates directly to APR threading API. original hythread included with the classlib: - contains much more extensive threading API, e.g. it adds wait/notify, interrupt, suspend, sleep, resume e.t.c. - the full set of threading API which is described in java.lang.Thread and java.lang.Object classes; - is platform-dependent, there are two versions for Linux and Windows, it seems it is written directly on top of win32 API / pthreads respectively. Personally, I would prefer to have classlib accessing threading functionality through the standard Java API like java.lang.Thread or Object and not using hythread at all, at least this will help VM's to show more useful debugging information for classlib. For example, VM knows nothing about hythread native monitors unless VM is building it's internal threading subsystem on top of the same hythread. Synchronization problems are tricky to identify and debug and I would prefer to face them in Java rather than in the native code. 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] -- 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]
Re: [drlvm] DRLVM segfaults in hythread_tls_get()
Geir Magnusson Jr wrote: Tim Ellison 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). Why not? Just curious what the downside is. Maybe I'm missing the point here... ...either you are building the same thread library and replacing it, which is only a waste of time; or you are building a different thread library and replacing it, which is likely to upset the classlib code. 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]
Re: [drlvm] DRLVM segfaults in hythread_tls_get()
Tim Ellison wrote: Geir Magnusson Jr wrote: Tim Ellison 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). Why not? Just curious what the downside is. Maybe I'm missing the point here... ...either you are building the same thread library and replacing it, which is only a waste of time; or you are building a different thread library and replacing it, which is likely to upset the classlib code. What if you support the same contracts? I'm trying to figure out where the solution is... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] DRLVM segfaults in hythread_tls_get()
Actually, let me flip this the other way... What are the differences between the impl of the threading lib in DRLVM vs that in classlib? Geir Magnusson Jr wrote: Tim Ellison wrote: Geir Magnusson Jr wrote: Tim Ellison 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). Why not? Just curious what the downside is. Maybe I'm missing the point here... ...either you are building the same thread library and replacing it, which is only a waste of time; or you are building a different thread library and replacing it, which is likely to upset the classlib code. What if you support the same contracts? I'm trying to figure out where the solution is... geir - 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]
Re: [drlvm] DRLVM segfaults in hythread_tls_get()
Tim Ellison 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). Why not? Just curious what the downside is. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] DRLVM segfaults in hythread_tls_get()
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]
Re: [drlvm] DRLVM segfaults in hythread_tls_get()
I didn't find the exact reason why this happens, looks like a drlvm ant scripts work differently. It could be a side effect of the recent adoption of DRLVM build for classlib binaries. The trick is that drlvm should put it's own hythread library into the deploy JRE. Before that change drlvm wasn't building the original hythread library at all, but now libhythr.so is copied from the class libraries into the deploy directory along with all other native class libraries. There could be two ways to resolve it: (a) Do a quick-fix in build.xml / deploy.copy_classlib target - add a filter which will will exclude hythr from copying; (b) More graceful fix - split the process.components target in build.xml into compilation of the components and their copying into deploy directory, and then update the dependencies order for the build target to make sure that class libraries are always copied first and then the compiled drlvm binaries are copied second, overwriting the classlib binaries if needed. I would prefer to do (a) for now since these kind of dependencies between classlib and drlvm are supposed to be handled by the top level build anyways. Thanks, Andrey. On 6/30/06, Gregory Shimansky [EMAIL PROTECTED] wrote: On Friday 30 June 2006 21:39 Salikh Zakirov wrote: Zakirov, Salikh wrote: By the way, there are some other issues with current state of DRLVM, as the following smoke tests (run by 'build.sh test') fail on Linux/ia32: util.DoPrivileged classloader.LogLoader classloader.SysRes I'm going to bisect recent commits to find the failure cause. The bisection haven't helped at all, since the older versions of DRLVM reproduce the same errors or do not work at all (with fixed class library version: latest). The above tests are failing with segfault in hythr library, #0 0x54e48c28 in hythread_tls_get (thread=0x0, key=1) at ../../shared/thread/hythreadinspect.c:134 #1 0x54f8d609 in hyport_tls_get (portLibrary=0x54f97ae0) at ../../shared/port/hytlshelpers.c:52 #2 0x54f8e57d in hyerror_set_last_error (portLibrary=0x54f97ae0, platformCode=2, portableCode=-308) at ../../shared/port/hyerror.c:231 after reading NULL thread pointer from TLS. Apparently, hythread_attach() isn't called anywhere in the DRLVM, but is required for some classlib functions in order to work properly. I've seen no major changes to thread files in CLASSLIB, so it makes me wonder why this has broken in DRLVM? I have also found that DRLVM's drop-in replacement of libhythr.so is no longer built or installed into jre/bin. I've just found the same problem. When everything is built from the scratch or after build.sh clean the hythr library in DRLVM deploy repository is correct. When the build is incremental the hythr library is taken from classlib. You can replace it manually from lnx_ia32_gcc_debug/semis/vm/hythr/_bin location. I didn't find the exact reason why this happens, looks like a drlvm ant scripts work differently. -- Gregory Shimansky, 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] -- 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]
Re: [drlvm] DRLVM segfaults in hythread_tls_get()
On 3 July 2006 at 15:14, Andrey Chernyshev [EMAIL PROTECTED] wrote: I didn't find the exact reason why this happens, looks like a drlvm ant scripts work differently. It could be a side effect of the recent adoption of DRLVM build for classlib binaries. The trick is that drlvm should put it's own hythread library into the deploy JRE. Before that change drlvm wasn't building the original hythread library at all, but now libhythr.so is copied from the class libraries into the deploy directory along with all other native class libraries. There could be two ways to resolve it: (a) Do a quick-fix in build.xml / deploy.copy_classlib target - add a filter which will will exclude hythr from copying; (b) More graceful fix - split the process.components target in build.xml into compilation of the components and their copying into deploy directory, and then update the dependencies order for the build target to make sure that class libraries are always copied first and then the compiled drlvm binaries are copied second, overwriting the classlib binaries if needed. c) Call the drlvm thread library something else to avoid the name clash with the existing library? (As IBM VME does with it's thread library.) I would prefer to do (a) for now since these kind of dependencies between classlib and drlvm are supposed to be handled by the top level build anyways. I don't think we should expect the top-level build to fix any problems like this. The top-level build should be completely dumb. My preference for the top-level build to just do a recursive copy of the drlvm/deploy tree and the classlib/deploy tree to a top-level deploy tree - which means it has to know nothing about the structure of the deploy directories. (And I don't think we should rely on the order in which the recursive copies happen - i.e. the set of files under deploy/drlvm and deploy/ classlib trees should not intersect.) Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] DRLVM segfaults in hythread_tls_get()
Andrey Chernyshev wrote: I didn't find the exact reason why this happens, looks like a drlvm ant scripts work differently. It could be a side effect of the recent adoption of DRLVM build for classlib binaries. Most likely. :) The trick is that drlvm should put it's own hythread library into the deploy JRE. Yes. Before that change drlvm wasn't building the original hythread library at all, but now libhythr.so is copied from the class libraries into the deploy directory along with all other native class libraries. There could be two ways to resolve it: (a) Do a quick-fix in build.xml / deploy.copy_classlib target - add a filter which will will exclude hythr from copying; Sure. (b) More graceful fix - split the process.components target in build.xml into compilation of the components and their copying into deploy directory, and then update the dependencies order for the build target to make sure that class libraries are always copied first and then the compiled drlvm binaries are copied second, overwriting the classlib binaries if needed. No - this is too random for my taste. I'd rather see things be very deliberate, such as not have the name clash. Then it's harder to screw up. I would prefer to do (a) for now since these kind of dependencies between classlib and drlvm are supposed to be handled by the top level build anyways. I don't think we want to put too much intelligence into the top-level build. each part of the top level build, be it drlvm, classlib, jchevm, classlibadapter, whatever should provide it's artifacts in an agreed-upon location/structure, and the top level just copes from there. We need to make sure that we're order independent. This way, adding things to the 'federation' is easy. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] DRLVM segfaults in hythread_tls_get()
Mark Hindess wrote: On 3 July 2006 at 15:14, Andrey Chernyshev [EMAIL PROTECTED] wrote: (a) Do a quick-fix in build.xml / deploy.copy_classlib target - add a filter which will will exclude hythr from copying; (b) More graceful fix - split the process.components target in build.xml into compilation of the components and their copying into deploy directory, and then update the dependencies order for the build target to make sure that class libraries are always copied first and then the compiled drlvm binaries are copied second, overwriting the classlib binaries if needed. c) Call the drlvm thread library something else to avoid the name clash with the existing library? (As IBM VME does with it's thread library.) Yes I would prefer to do (a) for now since these kind of dependencies between classlib and drlvm are supposed to be handled by the top level build anyways. I don't think we should expect the top-level build to fix any problems like this. The top-level build should be completely dumb. My preference for the top-level build to just do a recursive copy of the drlvm/deploy tree and the classlib/deploy tree to a top-level deploy tree - which means it has to know nothing about the structure of the deploy directories. (And I don't think we should rely on the order in which the recursive copies happen - i.e. the set of files under deploy/drlvm and deploy/ classlib trees should not intersect.) Yes. That's what I just said (in a different way) in the mail I just sent seconds ago... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] DRLVM segfaults in hythread_tls_get()
On 7/3/06, Mark Hindess [EMAIL PROTECTED] wrote: On 3 July 2006 at 15:14, Andrey Chernyshev [EMAIL PROTECTED] wrote: I didn't find the exact reason why this happens, looks like a drlvm ant scripts work differently. It could be a side effect of the recent adoption of DRLVM build for classlib binaries. The trick is that drlvm should put it's own hythread library into the deploy JRE. Before that change drlvm wasn't building the original hythread library at all, but now libhythr.so is copied from the class libraries into the deploy directory along with all other native class libraries. There could be two ways to resolve it: (a) Do a quick-fix in build.xml / deploy.copy_classlib target - add a filter which will will exclude hythr from copying; (b) More graceful fix - split the process.components target in build.xml into compilation of the components and their copying into deploy directory, and then update the dependencies order for the build target to make sure that class libraries are always copied first and then the compiled drlvm binaries are copied second, overwriting the classlib binaries if needed. c) Call the drlvm thread library something else to avoid the name clash with the existing library? (As IBM VME does with it's thread library.) 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 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. 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. Thanks, Andrey. I would prefer to do (a) for now since these kind of dependencies between classlib and drlvm are supposed to be handled by the top level build anyways. I don't think we should expect the top-level build to fix any problems like this. The top-level build should be completely dumb. My preference for the top-level build to just do a recursive copy of the drlvm/deploy tree and the classlib/deploy tree to a top-level deploy tree - which means it has to know nothing about the structure of the deploy directories. (And I don't think we should rely on the order in which the recursive copies happen - i.e. the set of files under deploy/drlvm and deploy/ classlib trees should not intersect.) Regards, Mark. - 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]
Re: [drlvm] DRLVM segfaults in hythread_tls_get()
Andrey Chernyshev wrote:
(a) Do a quick-fix in build.xml / deploy.copy_classlib target - add a
filter which will will exclude hythr from copying;
Verified.
The Andrey's suggestion worked out (patch below).
To make the smoke tests pass on Linux I had to further apply more patches:
* fix String.intern() (patch from HARMONY-721)
* add -Bsymbolic flag to hyzlib linking command, as suggested by Gregory
to avoid name clashes with system libz during dynamic linking. (Patch to
classlib further below).
---
Subject: [PATCH] Workaround to avoid copying *hythr* from classlib's bin/
directory
--- a/build/make/build.xml
+++ b/build/make/build.xml
@@ -432,6 +432,7 @@ Version: $Revision: 1.16.2.20 $
fileset dir=${external.dep.CLASSLIB}/deploy/jdk/jre/bin
include name=*/
exclude name=java*/
+exclude name=*hythr*/
/fileset
/copy
--
---
Subject: [PATCH] added overridable LDFLAGS in rules.mk, use -Bsymbolic for
hyzlib
--- a/depends/build/rules.mk
+++ b/depends/build/rules.mk
@@ -26,7 +26,7 @@ all: $(DLLNAME) $(EXENAME) $(LIBNAME)
-Wl,-soname=$(@F) $(VMLINK) -o $@ \
$(BUILDFILES) $(SYSLIBFILES) \
-Xlinker --start-group $(MDLLIBFILES) -Xlinker --end-group \
- -lc -lm -ldl
+ -lc -lm -ldl $(LDFLAGS)
$(EXENAME): $(BUILDFILES) $(MDLLIBFILES)
$(CC) $(VMLINK) \
--- a/native-src/linux.IA32/zlib/makefile
+++ b/native-src/linux.IA32/zlib/makefile
@@ -29,4 +29,6 @@ BUILDFILES = \
DLLNAME = ../libhyzlib.so
+LDFLAGS = -Wl,-Bsymbolic
+
include $(HY_HDK)/build/make/rules.mk
--
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] DRLVM segfaults in hythread_tls_get()
On Monday 03 July 2006 22:12 Salikh Zakirov wrote:
Andrey Chernyshev wrote:
(a) Do a quick-fix in build.xml / deploy.copy_classlib target - add a
filter which will will exclude hythr from copying;
Verified.
The Andrey's suggestion worked out (patch below).
To make the smoke tests pass on Linux I had to further apply more patches:
* fix String.intern() (patch from HARMONY-721)
* add -Bsymbolic flag to hyzlib linking command, as suggested by Gregory
to avoid name clashes with system libz during dynamic linking. (Patch to
classlib further below).
This is a strange case of name collision (if it is name collision) that I see.
Usually if there is a name collision all tests crash, not just 3 out of many.
Also I've seen crashes only on SuSE for some reason, on Gentoo everything
works fine.
Adding -Bsymbolic makes them go away but I didn't really investigate deeply
why it happens. Hopefully this is temporary and harmless linking change until
Zlib is used by classlib as an external resource. It is for the better if
classlib does not duplicate public symbols from Zlib and -Bsymbolic is a
crutch to help to workaround this problem for some time.
On a side note shouldn't it be LDFLAGS += instead of LDFLAGS = ?
---
Subject: [PATCH] Workaround to avoid copying *hythr* from classlib's bin/
directory
--- a/build/make/build.xml
+++ b/build/make/build.xml
@@ -432,6 +432,7 @@ Version: $Revision: 1.16.2.20 $
fileset dir=${external.dep.CLASSLIB}/deploy/jdk/jre/bin
include name=*/
exclude name=java*/
+exclude name=*hythr*/
/fileset
/copy
--
---
Subject: [PATCH] added overridable LDFLAGS in rules.mk, use -Bsymbolic for
hyzlib
--- a/depends/build/rules.mk
+++ b/depends/build/rules.mk
@@ -26,7 +26,7 @@ all: $(DLLNAME) $(EXENAME) $(LIBNAME)
-Wl,-soname=$(@F) $(VMLINK) -o $@ \
$(BUILDFILES) $(SYSLIBFILES) \
-Xlinker --start-group $(MDLLIBFILES) -Xlinker --end-group \
- -lc -lm -ldl
+ -lc -lm -ldl $(LDFLAGS)
$(EXENAME): $(BUILDFILES) $(MDLLIBFILES)
$(CC) $(VMLINK) \
--- a/native-src/linux.IA32/zlib/makefile
+++ b/native-src/linux.IA32/zlib/makefile
@@ -29,4 +29,6 @@ BUILDFILES = \
DLLNAME = ../libhyzlib.so
+LDFLAGS = -Wl,-Bsymbolic
+
include $(HY_HDK)/build/make/rules.mk
--
Gregory Shimansky, 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]
Re: [drlvm] DRLVM segfaults in hythread_tls_get()
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. 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]
[drlvm] DRLVM segfaults in hythread_tls_get()
Zakirov, Salikh wrote: By the way, there are some other issues with current state of DRLVM, as the following smoke tests (run by 'build.sh test') fail on Linux/ia32: util.DoPrivileged classloader.LogLoader classloader.SysRes I'm going to bisect recent commits to find the failure cause. The bisection haven't helped at all, since the older versions of DRLVM reproduce the same errors or do not work at all (with fixed class library version: latest). The above tests are failing with segfault in hythr library, #0 0x54e48c28 in hythread_tls_get (thread=0x0, key=1) at ../../shared/thread/hythreadinspect.c:134 #1 0x54f8d609 in hyport_tls_get (portLibrary=0x54f97ae0) at ../../shared/port/hytlshelpers.c:52 #2 0x54f8e57d in hyerror_set_last_error (portLibrary=0x54f97ae0, platformCode=2, portableCode=-308) at ../../shared/port/hyerror.c:231 after reading NULL thread pointer from TLS. Apparently, hythread_attach() isn't called anywhere in the DRLVM, but is required for some classlib functions in order to work properly. I've seen no major changes to thread files in CLASSLIB, so it makes me wonder why this has broken in DRLVM? I have also found that DRLVM's drop-in replacement of libhythr.so is no longer built or installed into jre/bin. Can someone with experience in interfacing DRLVM to hythr library look into the problem? Nik? Artem? - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] DRLVM segfaults in hythread_tls_get()
On Friday 30 June 2006 21:39 Salikh Zakirov wrote: Zakirov, Salikh wrote: By the way, there are some other issues with current state of DRLVM, as the following smoke tests (run by 'build.sh test') fail on Linux/ia32: util.DoPrivileged classloader.LogLoader classloader.SysRes I'm going to bisect recent commits to find the failure cause. The bisection haven't helped at all, since the older versions of DRLVM reproduce the same errors or do not work at all (with fixed class library version: latest). The above tests are failing with segfault in hythr library, #0 0x54e48c28 in hythread_tls_get (thread=0x0, key=1) at ../../shared/thread/hythreadinspect.c:134 #1 0x54f8d609 in hyport_tls_get (portLibrary=0x54f97ae0) at ../../shared/port/hytlshelpers.c:52 #2 0x54f8e57d in hyerror_set_last_error (portLibrary=0x54f97ae0, platformCode=2, portableCode=-308) at ../../shared/port/hyerror.c:231 after reading NULL thread pointer from TLS. Apparently, hythread_attach() isn't called anywhere in the DRLVM, but is required for some classlib functions in order to work properly. I've seen no major changes to thread files in CLASSLIB, so it makes me wonder why this has broken in DRLVM? I have also found that DRLVM's drop-in replacement of libhythr.so is no longer built or installed into jre/bin. I've just found the same problem. When everything is built from the scratch or after build.sh clean the hythr library in DRLVM deploy repository is correct. When the build is incremental the hythr library is taken from classlib. You can replace it manually from lnx_ia32_gcc_debug/semis/vm/hythr/_bin location. I didn't find the exact reason why this happens, looks like a drlvm ant scripts work differently. -- Gregory Shimansky, 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]
