You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by "Zakirov, Salikh" <sa...@intel.com> on 2006/06/30 16:49:32 UTC
RE: removed String.java
Hi Mark, DRLVM developers,
it looks like the issue HARMONY-666 to
remove String and StringBuffer was not accompanied with
corresponding update of org.apache.harmony.kernel.vm.VM
(move intern() native method from String to VM).
As I am planning to do some experiments with string interning
in DRLVM, it caught my interest and I looked into it.
The fix is attached to HARMONY-721.
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.
--
Salikh Zakirov, Intel Middleware Products Division
-----Original Message-----
From: hindessm@apache.org [mailto:hindessm@apache.org]
Sent: Thursday, June 29, 2006 12:58 PM
To: harmony-commits@incubator.apache.org
Subject: svn commit: r417969 - in
/incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/kernel_classes/jav
asrc/java/lang: String.java StringBuffer.java
Author: hindessm
Date: Thu Jun 29 01:57:36 2006
New Revision: 417969
URL: http://svn.apache.org/viewvc?rev=417969&view=rev
Log:
Applied changes from "[#HARMONY-666] String & StringBuffer should be
removed from the DRLVM sources".
Removed:
incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/kernel_classes/java
src/java/lang/String.java
incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/kernel_classes/java
src/java/lang/StringBuffer.java
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] DRLVM segfaults in hythread_tls_get()
Posted by Gregory Shimansky <gs...@gmail.com>.
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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] DRLVM segfaults in hythread_tls_get()
Posted by Andrey Chernyshev <a....@gmail.com>.
On 7/7/06, Tim Ellison <t....@gmail.com> 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 (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Andrey Chernyshev
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] DRLVM segfaults in hythread_tls_get()
Posted by Tim Ellison <t....@gmail.com>.
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.
Regards.
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] DRLVM segfaults in hythread_tls_get()
Posted by Geir Magnusson Jr <ge...@pobox.com>.
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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] DRLVM segfaults in hythread_tls_get()
Posted by Geir Magnusson Jr <ge...@pobox.com>.
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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] DRLVM segfaults in hythread_tls_get()
Posted by Tim Ellison <t....@gmail.com>.
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 (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] DRLVM segfaults in hythread_tls_get()
Posted by Geir Magnusson Jr <ge...@pobox.com>.
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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] DRLVM segfaults in hythread_tls_get()
Posted by Andrey Chernyshev <a....@gmail.com>.
Hi Tim,
On 7/4/06, Tim Ellison <t....@gmail.com> 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 (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Andrey Chernyshev
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] DRLVM segfaults in hythread_tls_get()
Posted by Tim Ellison <t....@gmail.com>.
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 (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] DRLVM segfaults in hythread_tls_get()
Posted by Andrey Chernyshev <a....@gmail.com>.
On 7/3/06, Mark Hindess <ma...@googlemail.com> wrote:
>
> On 3 July 2006 at 15:14, "Andrey Chernyshev" <a....@gmail.com>
> 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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Andrey Chernyshev
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] DRLVM segfaults in hythread_tls_get()
Posted by Geir Magnusson Jr <ge...@pobox.com>.
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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] DRLVM segfaults in hythread_tls_get()
Posted by Salikh Zakirov <Sa...@Intel.com>.
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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] DRLVM segfaults in hythread_tls_get()
Posted by Andrey Chernyshev <a....@gmail.com>.
> 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 <gs...@gmail.com> 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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Andrey Chernyshev
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] DRLVM segfaults in hythread_tls_get()
Posted by Gregory Shimansky <gs...@gmail.com>.
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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
[drlvm] DRLVM segfaults in hythread_tls_get()
Posted by Salikh Zakirov <Sa...@Intel.com>.
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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: removed String.java
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Zakirov, Salikh wrote:
> Hi Mark, DRLVM developers,
>
> it looks like the issue HARMONY-666 to
> remove String and StringBuffer was not accompanied with
> corresponding update of org.apache.harmony.kernel.vm.VM
> (move intern() native method from String to VM).
>
> As I am planning to do some experiments with string interning
> in DRLVM, it caught my interest and I looked into it.
> The fix is attached to HARMONY-721.
Good catch.
>
> 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.
I'm building and checking here.
geir
>
> --
> Salikh Zakirov, Intel Middleware Products Division
>
>
> -----Original Message-----
> From: hindessm@apache.org [mailto:hindessm@apache.org]
> Sent: Thursday, June 29, 2006 12:58 PM
> To: harmony-commits@incubator.apache.org
> Subject: svn commit: r417969 - in
> /incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/kernel_classes/jav
> asrc/java/lang: String.java StringBuffer.java
>
> Author: hindessm
> Date: Thu Jun 29 01:57:36 2006
> New Revision: 417969
>
> URL: http://svn.apache.org/viewvc?rev=417969&view=rev
> Log:
> Applied changes from "[#HARMONY-666] String & StringBuffer should be
> removed from the DRLVM sources".
>
> Removed:
>
> incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/kernel_classes/java
> src/java/lang/String.java
>
> incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/kernel_classes/java
> src/java/lang/StringBuffer.java
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org