You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Stefano Mazzocchi <st...@apache.org> on 2006/11/10 21:53:06 UTC
[drlvm][em64t] build fails
I've managed to get everything in place for a DRLVM build.. it runs for
a while and then it fails with these errors:
[cc]
/home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/jit_lock_rt_support_em64t.cpp:
In function ‘void* rth_get_lil_monitor_enter()’:
[cc]
/home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/jit_lock_rt_support_em64t.cpp:127:
error: ‘managed_null’ is not a member of ‘Class’
[cc]
/home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/jit_lock_rt_support_em64t.cpp:
In function ‘void* rth_get_lil_monitor_exit()’:
[cc]
/home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/jit_lock_rt_support_em64t.cpp:265:
error: ‘managed_null’ is not a member of ‘Class’
[cc]
/home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp:
In function ‘void JIT_execute_method_default(void*, _jmethodID*,
jvalue*, jvalue*)’:
[cc]
/home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp:201:
error: ‘struct Class’ has no member named ‘name’
[cc]
/home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp:229:
error: ‘managed_null’ is not a member of ‘Class’
[cc]
/home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp:326:
error: ‘managed_null’ is not a member of ‘Class’
[cc]
/home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp:359:
error: ‘struct Class’ has no member named ‘name’
Suggestions?
--
Stefano.
Re: [drlvm][em64t] build fails
Posted by Alexei Fedotov <al...@gmail.com>.
> DRLVM build always requires prebuilt classlib...
I believe ia32 classlib is ok until linking happens.
On 11/11/06, Gregory Shimansky <gs...@gmail.com> wrote:
> Same for me. I saw this yesterday. It is because HARMONY-1558 has changed
> Class interfaces but didn't change x86_64 specific files. Now that I look at
> the error messages, I think it is quite easy to fix the build. I'll take care
> of weekend.
>
> I wonder how did you get to building drlvm if classlib didn't build for you
> because of -fpic problem? DRLVM build always requires prebuilt classlib...
>
> On Friday 10 November 2006 23:53 Stefano Mazzocchi wrote:
> > I've managed to get everything in place for a DRLVM build.. it runs for
> > a while and then it fails with these errors:
> >
> > [cc]
> > /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/jit_lock_rt_s
> >upport_em64t.cpp: In function 'void* rth_get_lil_monitor_enter()':
> > [cc]
> > /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/jit_lock_rt_s
> >upport_em64t.cpp:127: error: 'managed_null' is not a member of 'Class'
> > [cc]
> > /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/jit_lock_rt_s
> >upport_em64t.cpp: In function 'void* rth_get_lil_monitor_exit()':
> > [cc]
> > /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/jit_lock_rt_s
> >upport_em64t.cpp:265: error: 'managed_null' is not a member of 'Class'
> > [cc]
> > /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp
> >: In function 'void JIT_execute_method_default(void*, _jmethodID*,
> > jvalue*, jvalue*)':
> > [cc]
> > /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp
> >:201: error: 'struct Class' has no member named 'name'
> > [cc]
> > /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp
> >:229: error: 'managed_null' is not a member of 'Class'
> > [cc]
> > /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp
> >:326: error: 'managed_null' is not a member of 'Class'
> > [cc]
> > /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp
> >:359: error: 'struct Class' has no member named 'name'
> >
> > Suggestions?
>
> --
> Gregory Shimansky, Intel Middleware Products Division
>
--
Thank you,
Alexei
Re: [drlvm][em64t] build fails
Posted by Rana Dasgupta <rd...@gmail.com>.
On 11/13/06, Pavel Afremov <pa...@gmail.com> wrote:
>
> >Hello
>
>
>
> >I think that Stack test should print pass if no stack overflow error is
> >happened.
>
> >Test should check processing of this error but not existing of it.
I think that this makes sense. StackTest should be intended to detect
correct handling of the SOE error only if it happens. That makes it platform
independent.
Re: [drlvm] Java stack limits
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
This is weird.
According to my mail, Tim wrote this at 6:01 am :
Tim Ellison wrote:
> Mikhail Loenko wrote:
>> Can we get the value from the harmonyvm.properties file?
>
> I think the question is what default value should you choose? I believe
> we all agree that it should be configurable, at launch time (e.g. -Xss
> -Xmso), and yes at install time maybe in the .properties file.
>
> Regards,
> Tim
I never saw this, because at 9:30am, I wrote :
Geir Magnusson Jr. wrote:
> yeah - the question is what the value should be.
>
> Mikhail Loenko wrote:
>> Can we get the value from the harmonyvm.properties file?
>>
>> Thanks,
>> Mikhail
>>
So sorry - I didn't mean to ignore tim's reponse. I just never saw it...
geir
>
>> 2006/11/17, Tim Ellison <t....@gmail.com>:
>>> Geir Magnusson Jr. wrote:
>>>> I think that it's totally unreasonable to have no upper bound on stack
>>>> size. A Java virtual machine should never be able to hose a machine by
>>>> sucking in all memory...
>>> yeah, like those rotten C programs. You are damned if you do and damned
>>> if you don't, since you'll upset people who hit any arbitrary limit that
>>> you set on the stack size too. As we have seen, current impls do limit.
>>>
>>> Regards,
>>> Tim
>>>
>>> --
>>>
>>> Tim Ellison (t.p.ellison@gmail.com)
>>> IBM Java technology centre, UK.
>>>
>
Re: [drlvm] Java stack limits
Posted by Tim Ellison <t....@gmail.com>.
Mikhail Loenko wrote:
> Can we get the value from the harmonyvm.properties file?
I think the question is what default value should you choose? I believe
we all agree that it should be configurable, at launch time (e.g. -Xss
-Xmso), and yes at install time maybe in the .properties file.
Regards,
Tim
> 2006/11/17, Tim Ellison <t....@gmail.com>:
>> Geir Magnusson Jr. wrote:
>> > I think that it's totally unreasonable to have no upper bound on stack
>> > size. A Java virtual machine should never be able to hose a machine by
>> > sucking in all memory...
>>
>> yeah, like those rotten C programs. You are damned if you do and damned
>> if you don't, since you'll upset people who hit any arbitrary limit that
>> you set on the stack size too. As we have seen, current impls do limit.
>>
>> Regards,
>> Tim
>>
>> --
>>
>> Tim Ellison (t.p.ellison@gmail.com)
>> IBM Java technology centre, UK.
>>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [drlvm] Java stack limits
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
yeah - the question is what the value should be.
Mikhail Loenko wrote:
> Can we get the value from the harmonyvm.properties file?
>
> Thanks,
> Mikhail
>
> 2006/11/17, Tim Ellison <t....@gmail.com>:
>> Geir Magnusson Jr. wrote:
>> > I think that it's totally unreasonable to have no upper bound on stack
>> > size. A Java virtual machine should never be able to hose a machine by
>> > sucking in all memory...
>>
>> yeah, like those rotten C programs. You are damned if you do and damned
>> if you don't, since you'll upset people who hit any arbitrary limit that
>> you set on the stack size too. As we have seen, current impls do limit.
>>
>> Regards,
>> Tim
>>
>> --
>>
>> Tim Ellison (t.p.ellison@gmail.com)
>> IBM Java technology centre, UK.
>>
>
Re: [drlvm] Java stack limits (was: Re: [drlvm][em64t] build fails)
Posted by Mikhail Loenko <ml...@gmail.com>.
Can we get the value from the harmonyvm.properties file?
Thanks,
Mikhail
2006/11/17, Tim Ellison <t....@gmail.com>:
> Geir Magnusson Jr. wrote:
> > I think that it's totally unreasonable to have no upper bound on stack
> > size. A Java virtual machine should never be able to hose a machine by
> > sucking in all memory...
>
> yeah, like those rotten C programs. You are damned if you do and damned
> if you don't, since you'll upset people who hit any arbitrary limit that
> you set on the stack size too. As we have seen, current impls do limit.
>
> Regards,
> Tim
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
Re: [drlvm][em64t] build fails
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Pavel Afremov wrote:
>
>
> On 11/15/06, *Geir Magnusson Jr.* <geir@pobox.com
> <ma...@pobox.com>> wrote:
>
> How could there be no limit to stack size??
>
>
> Limit is there but it's too large, like 2 in power 46.
>
>
> Is there a way the test framework could set this? Does DRLVM support
> -Xss yet?
>
>
>
> No, DRLVM doesn't support –Xss flag. …yet.
>
> I have a question: Is Xss flag significant feature or there are more
> important things?
Probably more important things... but... I would think that -Xss would
be pretty simple?
I think that the solution is (as I noted in another message) is to
somehow set the process stack size w/ ulimit
geir
>
>
>
> Pavel Afremov
>
>
>
>
Re: [drlvm][em64t] build fails
Posted by Pavel Afremov <pa...@gmail.com>.
On 11/15/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
> How could there be no limit to stack size??
Limit is there but it's too large, like 2 in power 46.
> Is there a way the test framework could set this? Does DRLVM support
> -Xss yet?
No, DRLVM doesn't support –Xss flag. …yet.
I have a question: Is Xss flag significant feature or there are more
important things?
Pavel Afremov
Re: [drlvm][em64t] build fails
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x223 day of Apache Harmony Alexey Varlamov wrote:
> 16 Nov 2006 14:48:05 +0600, Egor Pasko <eg...@gmail.com>:
> > On the 0x223 day of Apache Harmony Geir Magnusson, Jr. wrote:
> > > Gregory Shimansky wrote:
> > > > Geir Magnusson Jr. wrote:
> > > >>
> > > >>
> > > >> Gregory Shimansky wrote:
> > > >>>>
> > > >>> -Xss is the lower stack limit, it doesn't specify the maximum
> > > >>> stack size, doesn't it?
> > > >>
> > > >> What does "lower stack limit" mean? :) I think that it's the size
> > > >> of the stack, max.
> > > > I thought it is a starting stack size, like -Xms for heap size. Now
> > > > that I searched the web it appears that it is the maximum indeed.
> > >
> > > "0" is minimum stack size.
> > >
> > > >
> > > >> I think all you need to do then is set the stack size :
> > > >>
> > > >> ulimit -s 8192
> > > >>
> > > >> or something. We should probably do this before each run on linux
> > > >> so that things are well defined and reproducible.
> > > > I think 64-bit SuSE9 is just the only weird distribution which
> > > > doesn't have this limit. In 10th version they fixed this. So ulimit
> > > > -s is not necessary in most cases.
> > >
> > > But harmless. And it makes the test predicable across platforms. and
> > > if the StackSize test is forked, we can make it small to make it
> > > quick...
> >
> > I know nothing about forking Java processes. Does it make sense?
> > Secondly, fork() is fast regardless of the stack size (stacks are COW).
>
> Determinative time here is test execution time, not forking time. The
> point is to make SOE happen quickly instead of stressing host machine.
yes
the most elegant would be to run the test in a separate VM with small -Xss
> >
> > > > I'd still like to have a recursion limit in StackTest but Rana has
> > > > convinced me that no SOE shouldn't mean that test has failed. I'll
> > > > patch it now.
> > > >
> > >
> > > I agree that your fix is utterly bogus :) but we want to test SOE
> > > machinery, so I think that we should set the ulimit to ensure an
> > > environment in which the SOE will happen if DRLVM is working
> > > right. Therefore, we need to set things up such that not getting an
> > > SOE is indeed a failure.
> >
> > What a user would most likely expect on a system with no stack limit?
> > Something like on the other systems with stack limit as in
> > run-anywhere concept. And that would be SOE, not swapping. So, let's
> > limit the stack by, say, 10M if not set with an option. We can
> > implement the option later.
> This is arguable - remember essays about users frustrated by
> artificial Java heap limits :)
I do :) but today is not the right time to merge JVM with OS so
much. Behaving more like RI has more priority.
> Another point can be slightly different meaning for -Xss on RI and
> DRLVM, the latter has united stack as opposite to separate Java stack
> on RI...
I am not sure I understand. What is the "separate Java stack"? Does it
mean that Java stack does not relate to 'ulimit -s' on RI? Why not we
do the same for user convenience?
--
Egor Pasko
Re: [drlvm][em64t] build fails
Posted by Alexey Varlamov <al...@gmail.com>.
16 Nov 2006 14:48:05 +0600, Egor Pasko <eg...@gmail.com>:
> On the 0x223 day of Apache Harmony Geir Magnusson, Jr. wrote:
> > Gregory Shimansky wrote:
> > > Geir Magnusson Jr. wrote:
> > >>
> > >>
> > >> Gregory Shimansky wrote:
> > >>>>
> > >>> -Xss is the lower stack limit, it doesn't specify the maximum
> > >>> stack size, doesn't it?
> > >>
> > >> What does "lower stack limit" mean? :) I think that it's the size
> > >> of the stack, max.
> > > I thought it is a starting stack size, like -Xms for heap size. Now
> > > that I searched the web it appears that it is the maximum indeed.
> >
> > "0" is minimum stack size.
> >
> > >
> > >> I think all you need to do then is set the stack size :
> > >>
> > >> ulimit -s 8192
> > >>
> > >> or something. We should probably do this before each run on linux
> > >> so that things are well defined and reproducible.
> > > I think 64-bit SuSE9 is just the only weird distribution which
> > > doesn't have this limit. In 10th version they fixed this. So ulimit
> > > -s is not necessary in most cases.
> >
> > But harmless. And it makes the test predicable across platforms. and
> > if the StackSize test is forked, we can make it small to make it
> > quick...
>
> I know nothing about forking Java processes. Does it make sense?
> Secondly, fork() is fast regardless of the stack size (stacks are COW).
Determinative time here is test execution time, not forking time. The
point is to make SOE happen quickly instead of stressing host machine.
>
> > > I'd still like to have a recursion limit in StackTest but Rana has
> > > convinced me that no SOE shouldn't mean that test has failed. I'll
> > > patch it now.
> > >
> >
> > I agree that your fix is utterly bogus :) but we want to test SOE
> > machinery, so I think that we should set the ulimit to ensure an
> > environment in which the SOE will happen if DRLVM is working
> > right. Therefore, we need to set things up such that not getting an
> > SOE is indeed a failure.
>
> What a user would most likely expect on a system with no stack limit?
> Something like on the other systems with stack limit as in
> run-anywhere concept. And that would be SOE, not swapping. So, let's
> limit the stack by, say, 10M if not set with an option. We can
> implement the option later.
This is arguable - remember essays about users frustrated by
artificial Java heap limits :)
Another point can be slightly different meaning for -Xss on RI and
DRLVM, the latter has united stack as opposite to separate Java stack
on RI...
>
> --
> Egor Pasko
>
>
Re: [drlvm] Java stack limits
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Tim Ellison wrote:
> Geir Magnusson Jr. wrote:
>> I think that it's totally unreasonable to have no upper bound on stack
>> size. A Java virtual machine should never be able to hose a machine by
>> sucking in all memory...
>
> yeah, like those rotten C programs. You are damned if you do and damned
> if you don't, since you'll upset people who hit any arbitrary limit that
> you set on the stack size too. As we have seen, current impls do limit.
Clearly the "suck all memory until the box turns over and wiggles it's
feet in the air" setting isn't needed by anyone. Is there some
reasonable heuristic based on heap defaults or settings?
geir
>
> Regards,
> Tim
>
[drlvm] Java stack limits (was: Re: [drlvm][em64t] build fails)
Posted by Tim Ellison <t....@gmail.com>.
Geir Magnusson Jr. wrote:
> I think that it's totally unreasonable to have no upper bound on stack
> size. A Java virtual machine should never be able to hose a machine by
> sucking in all memory...
yeah, like those rotten C programs. You are damned if you do and damned
if you don't, since you'll upset people who hit any arbitrary limit that
you set on the stack size too. As we have seen, current impls do limit.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [drlvm][em64t] build fails
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x223 day of Apache Harmony Geir Magnusson, Jr. wrote:
> Egor Pasko wrote:
> > On the 0x223 day of Apache Harmony Geir Magnusson, Jr. wrote:
> >> Gregory Shimansky wrote:
> >>> Geir Magnusson Jr. wrote:
> >>>>
> >>>> Gregory Shimansky wrote:
> >>>>> -Xss is the lower stack limit, it doesn't specify the maximum
> >>>>> stack size, doesn't it?
> >>>> What does "lower stack limit" mean? :) I think that it's the size
> >>>> of the stack, max.
> >>> I thought it is a starting stack size, like -Xms for heap size. Now
> >>> that I searched the web it appears that it is the maximum indeed.
> >> "0" is minimum stack size.
> >>
> >>>> I think all you need to do then is set the stack size :
> >>>>
> >>>> ulimit -s 8192
> >>>>
> >>>> or something. We should probably do this before each run on linux
> >>>> so that things are well defined and reproducible.
> >>> I think 64-bit SuSE9 is just the only weird distribution which
> >>> doesn't have this limit. In 10th version they fixed this. So ulimit
> >>> -s is not necessary in most cases.
> >> But harmless. And it makes the test predicable across platforms. and
> >> if the StackSize test is forked, we can make it small to make it
> >> quick...
> > I know nothing about forking Java processes. Does it make sense?
> > Secondly, fork() is fast regardless of the stack size (stacks are COW).
>
> I'm not sure I meant that as a literal fork, but rather a spawned
> process in which we can set the ulimit indep of the invoking parent.
actually, there is no need of a fork() or an extra process to limit
stack size, I just found the "man 2 setrlimit" :)
> >
> >>> I'd still like to have a recursion limit in StackTest but Rana has
> >>> convinced me that no SOE shouldn't mean that test has failed. I'll
> >>> patch it now.
> >>>
> >> I agree that your fix is utterly bogus :) but we want to test SOE
> >> machinery, so I think that we should set the ulimit to ensure an
> >> environment in which the SOE will happen if DRLVM is working
> >> right. Therefore, we need to set things up such that not getting an
> >> SOE is indeed a failure.
> > What a user would most likely expect on a system with no stack limit?
> > Something like on the other systems with stack limit as in
> > run-anywhere concept. And that would be SOE, not swapping. So, let's
> > limit the stack by, say, 10M if not set with an option. We can
> > implement the option later.
>
> I think that it's totally unreasonable to have no upper bound on stack
> size. A Java virtual machine should never be able to hose a machine
> by sucking in all memory...
>
> geir
>
>
> >
>
--
Egor Pasko
Re: [drlvm][em64t] build fails
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Egor Pasko wrote:
> On the 0x223 day of Apache Harmony Geir Magnusson, Jr. wrote:
>> Gregory Shimansky wrote:
>>> Geir Magnusson Jr. wrote:
>>>>
>>>> Gregory Shimansky wrote:
>>>>> -Xss is the lower stack limit, it doesn't specify the maximum
>>>>> stack size, doesn't it?
>>>> What does "lower stack limit" mean? :) I think that it's the size
>>>> of the stack, max.
>>> I thought it is a starting stack size, like -Xms for heap size. Now
>>> that I searched the web it appears that it is the maximum indeed.
>> "0" is minimum stack size.
>>
>>>> I think all you need to do then is set the stack size :
>>>>
>>>> ulimit -s 8192
>>>>
>>>> or something. We should probably do this before each run on linux
>>>> so that things are well defined and reproducible.
>>> I think 64-bit SuSE9 is just the only weird distribution which
>>> doesn't have this limit. In 10th version they fixed this. So ulimit
>>> -s is not necessary in most cases.
>> But harmless. And it makes the test predicable across platforms. and
>> if the StackSize test is forked, we can make it small to make it
>> quick...
>
> I know nothing about forking Java processes. Does it make sense?
> Secondly, fork() is fast regardless of the stack size (stacks are COW).
I'm not sure I meant that as a literal fork, but rather a spawned
process in which we can set the ulimit indep of the invoking parent.
>
>>> I'd still like to have a recursion limit in StackTest but Rana has
>>> convinced me that no SOE shouldn't mean that test has failed. I'll
>>> patch it now.
>>>
>> I agree that your fix is utterly bogus :) but we want to test SOE
>> machinery, so I think that we should set the ulimit to ensure an
>> environment in which the SOE will happen if DRLVM is working
>> right. Therefore, we need to set things up such that not getting an
>> SOE is indeed a failure.
>
> What a user would most likely expect on a system with no stack limit?
> Something like on the other systems with stack limit as in
> run-anywhere concept. And that would be SOE, not swapping. So, let's
> limit the stack by, say, 10M if not set with an option. We can
> implement the option later.
I think that it's totally unreasonable to have no upper bound on stack
size. A Java virtual machine should never be able to hose a machine by
sucking in all memory...
geir
>
Re: [drlvm][em64t] build fails
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Gregory Shimansky wrote:
> Egor Pasko wrote:
>> On the 0x223 day of Apache Harmony Geir Magnusson, Jr. wrote:
>>> Gregory Shimansky wrote:
>>>> Geir Magnusson Jr. wrote:
>>>>>
>>>>> Gregory Shimansky wrote:
>>>>>> -Xss is the lower stack limit, it doesn't specify the maximum
>>>>>> stack size, doesn't it?
>>>>> What does "lower stack limit" mean? :) I think that it's the size
>>>>> of the stack, max.
>>>> I thought it is a starting stack size, like -Xms for heap size. Now
>>>> that I searched the web it appears that it is the maximum indeed.
>>> "0" is minimum stack size.
>>>
>>>>> I think all you need to do then is set the stack size :
>>>>>
>>>>> ulimit -s 8192
>>>>>
>>>>> or something. We should probably do this before each run on linux
>>>>> so that things are well defined and reproducible.
>>>> I think 64-bit SuSE9 is just the only weird distribution which
>>>> doesn't have this limit. In 10th version they fixed this. So ulimit
>>>> -s is not necessary in most cases.
>>> But harmless. And it makes the test predicable across platforms. and
>>> if the StackSize test is forked, we can make it small to make it
>>> quick...
>>
>> I know nothing about forking Java processes. Does it make sense?
>> Secondly, fork() is fast regardless of the stack size (stacks are COW).
>>
>>>> I'd still like to have a recursion limit in StackTest but Rana has
>>>> convinced me that no SOE shouldn't mean that test has failed. I'll
>>>> patch it now.
>>>>
>>> I agree that your fix is utterly bogus :) but we want to test SOE
>>> machinery, so I think that we should set the ulimit to ensure an
>>> environment in which the SOE will happen if DRLVM is working
>>> right. Therefore, we need to set things up such that not getting an
>>> SOE is indeed a failure.
>>
>> What a user would most likely expect on a system with no stack limit?
>> Something like on the other systems with stack limit as in
>> run-anywhere concept. And that would be SOE, not swapping. So, let's
>> limit the stack by, say, 10M if not set with an option. We can
>> implement the option later.
>
> Well if you run StackTest on RI on a machine which doesn't have any
> stack limit imposed by OS you'll still see SOE quite soon. So RI has a
> limited stack size anyway.
Of course. The JVM should never take down the whole machine.
>
Re: [drlvm][em64t] build fails
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x223 day of Apache Harmony Gregory Shimansky wrote:
> Egor Pasko wrote:
> > On the 0x223 day of Apache Harmony Gregory Shimansky wrote:
> >> Egor Pasko wrote:
> >>> On the 0x223 day of Apache Harmony Geir Magnusson, Jr. wrote:
> >>>> Gregory Shimansky wrote:
> >>>>> Geir Magnusson Jr. wrote:
> >>>>>> Gregory Shimansky wrote:
> >>>>>>> -Xss is the lower stack limit, it doesn't specify the maximum
> >>>>>>> stack size, doesn't it?
> >>>>>> What does "lower stack limit" mean? :) I think that it's the size
> >>>>>> of the stack, max.
> >>>>> I thought it is a starting stack size, like -Xms for heap size. Now
> >>>>> that I searched the web it appears that it is the maximum indeed.
> >>>> "0" is minimum stack size.
> >>>>
> >>>>>> I think all you need to do then is set the stack size :
> >>>>>>
> >>>>>> ulimit -s 8192
> >>>>>>
> >>>>>> or something. We should probably do this before each run on linux
> >>>>>> so that things are well defined and reproducible.
> >>>>> I think 64-bit SuSE9 is just the only weird distribution which
> >>>>> doesn't have this limit. In 10th version they fixed this. So ulimit
> >>>>> -s is not necessary in most cases.
> >>>> But harmless. And it makes the test predicable across platforms. and
> >>>> if the StackSize test is forked, we can make it small to make it
> >>>> quick...
> >>> I know nothing about forking Java processes. Does it make sense?
> >>> Secondly, fork() is fast regardless of the stack size (stacks are COW).
> >>>
> >>>>> I'd still like to have a recursion limit in StackTest but Rana has
> >>>>> convinced me that no SOE shouldn't mean that test has failed. I'll
> >>>>> patch it now.
> >>>>>
> >>>> I agree that your fix is utterly bogus :) but we want to test SOE
> >>>> machinery, so I think that we should set the ulimit to ensure an
> >>>> environment in which the SOE will happen if DRLVM is working
> >>>> right. Therefore, we need to set things up such that not getting an
> >>>> SOE is indeed a failure.
> >>> What a user would most likely expect on a system with no stack limit?
> >>> Something like on the other systems with stack limit as in
> >>> run-anywhere concept. And that would be SOE, not swapping. So, let's
> >>> limit the stack by, say, 10M if not set with an option. We can
> >>> implement the option later.
> >> Well if you run StackTest on RI on a machine which doesn't have any
> >> stack limit imposed by OS you'll still see SOE quite soon. So RI has a
> >> limited stack size anyway.
> > can anything stop us from doing the same?
>
> I don't think that anything does, we just need to agree on a
> reasonable stack size default. On RI and BEA it seems to be different,
> StackTest gives pretty different results.
howabout arithmetic mean? :) Seriously, I do not see a big problem here.
--
Egor Pasko
Re: [drlvm][em64t] build fails
Posted by Gregory Shimansky <gs...@gmail.com>.
Egor Pasko wrote:
> On the 0x223 day of Apache Harmony Gregory Shimansky wrote:
>> Egor Pasko wrote:
>>> On the 0x223 day of Apache Harmony Geir Magnusson, Jr. wrote:
>>>> Gregory Shimansky wrote:
>>>>> Geir Magnusson Jr. wrote:
>>>>>> Gregory Shimansky wrote:
>>>>>>> -Xss is the lower stack limit, it doesn't specify the maximum
>>>>>>> stack size, doesn't it?
>>>>>> What does "lower stack limit" mean? :) I think that it's the size
>>>>>> of the stack, max.
>>>>> I thought it is a starting stack size, like -Xms for heap size. Now
>>>>> that I searched the web it appears that it is the maximum indeed.
>>>> "0" is minimum stack size.
>>>>
>>>>>> I think all you need to do then is set the stack size :
>>>>>>
>>>>>> ulimit -s 8192
>>>>>>
>>>>>> or something. We should probably do this before each run on linux
>>>>>> so that things are well defined and reproducible.
>>>>> I think 64-bit SuSE9 is just the only weird distribution which
>>>>> doesn't have this limit. In 10th version they fixed this. So ulimit
>>>>> -s is not necessary in most cases.
>>>> But harmless. And it makes the test predicable across platforms. and
>>>> if the StackSize test is forked, we can make it small to make it
>>>> quick...
>>> I know nothing about forking Java processes. Does it make sense?
>>> Secondly, fork() is fast regardless of the stack size (stacks are COW).
>>>
>>>>> I'd still like to have a recursion limit in StackTest but Rana has
>>>>> convinced me that no SOE shouldn't mean that test has failed. I'll
>>>>> patch it now.
>>>>>
>>>> I agree that your fix is utterly bogus :) but we want to test SOE
>>>> machinery, so I think that we should set the ulimit to ensure an
>>>> environment in which the SOE will happen if DRLVM is working
>>>> right. Therefore, we need to set things up such that not getting an
>>>> SOE is indeed a failure.
>>> What a user would most likely expect on a system with no stack limit?
>>> Something like on the other systems with stack limit as in
>>> run-anywhere concept. And that would be SOE, not swapping. So, let's
>>> limit the stack by, say, 10M if not set with an option. We can
>>> implement the option later.
>> Well if you run StackTest on RI on a machine which doesn't have any
>> stack limit imposed by OS you'll still see SOE quite soon. So RI has a
>> limited stack size anyway.
>
> can anything stop us from doing the same?
I don't think that anything does, we just need to agree on a reasonable
stack size default. On RI and BEA it seems to be different, StackTest
gives pretty different results.
--
Gregory
Re: [drlvm][em64t] build fails
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x223 day of Apache Harmony Gregory Shimansky wrote:
> Egor Pasko wrote:
> > On the 0x223 day of Apache Harmony Geir Magnusson, Jr. wrote:
> >> Gregory Shimansky wrote:
> >>> Geir Magnusson Jr. wrote:
> >>>>
> >>>> Gregory Shimansky wrote:
> >>>>> -Xss is the lower stack limit, it doesn't specify the maximum
> >>>>> stack size, doesn't it?
> >>>> What does "lower stack limit" mean? :) I think that it's the size
> >>>> of the stack, max.
> >>> I thought it is a starting stack size, like -Xms for heap size. Now
> >>> that I searched the web it appears that it is the maximum indeed.
> >> "0" is minimum stack size.
> >>
> >>>> I think all you need to do then is set the stack size :
> >>>>
> >>>> ulimit -s 8192
> >>>>
> >>>> or something. We should probably do this before each run on linux
> >>>> so that things are well defined and reproducible.
> >>> I think 64-bit SuSE9 is just the only weird distribution which
> >>> doesn't have this limit. In 10th version they fixed this. So ulimit
> >>> -s is not necessary in most cases.
> >> But harmless. And it makes the test predicable across platforms. and
> >> if the StackSize test is forked, we can make it small to make it
> >> quick...
> > I know nothing about forking Java processes. Does it make sense?
> > Secondly, fork() is fast regardless of the stack size (stacks are COW).
> >
> >>> I'd still like to have a recursion limit in StackTest but Rana has
> >>> convinced me that no SOE shouldn't mean that test has failed. I'll
> >>> patch it now.
> >>>
> >> I agree that your fix is utterly bogus :) but we want to test SOE
> >> machinery, so I think that we should set the ulimit to ensure an
> >> environment in which the SOE will happen if DRLVM is working
> >> right. Therefore, we need to set things up such that not getting an
> >> SOE is indeed a failure.
> > What a user would most likely expect on a system with no stack limit?
> > Something like on the other systems with stack limit as in
> > run-anywhere concept. And that would be SOE, not swapping. So, let's
> > limit the stack by, say, 10M if not set with an option. We can
> > implement the option later.
>
> Well if you run StackTest on RI on a machine which doesn't have any
> stack limit imposed by OS you'll still see SOE quite soon. So RI has a
> limited stack size anyway.
can anything stop us from doing the same?
--
Egor Pasko
Re: [drlvm][em64t] build fails
Posted by Gregory Shimansky <gs...@gmail.com>.
Egor Pasko wrote:
> On the 0x223 day of Apache Harmony Geir Magnusson, Jr. wrote:
>> Gregory Shimansky wrote:
>>> Geir Magnusson Jr. wrote:
>>>>
>>>> Gregory Shimansky wrote:
>>>>> -Xss is the lower stack limit, it doesn't specify the maximum
>>>>> stack size, doesn't it?
>>>> What does "lower stack limit" mean? :) I think that it's the size
>>>> of the stack, max.
>>> I thought it is a starting stack size, like -Xms for heap size. Now
>>> that I searched the web it appears that it is the maximum indeed.
>> "0" is minimum stack size.
>>
>>>> I think all you need to do then is set the stack size :
>>>>
>>>> ulimit -s 8192
>>>>
>>>> or something. We should probably do this before each run on linux
>>>> so that things are well defined and reproducible.
>>> I think 64-bit SuSE9 is just the only weird distribution which
>>> doesn't have this limit. In 10th version they fixed this. So ulimit
>>> -s is not necessary in most cases.
>> But harmless. And it makes the test predicable across platforms. and
>> if the StackSize test is forked, we can make it small to make it
>> quick...
>
> I know nothing about forking Java processes. Does it make sense?
> Secondly, fork() is fast regardless of the stack size (stacks are COW).
>
>>> I'd still like to have a recursion limit in StackTest but Rana has
>>> convinced me that no SOE shouldn't mean that test has failed. I'll
>>> patch it now.
>>>
>> I agree that your fix is utterly bogus :) but we want to test SOE
>> machinery, so I think that we should set the ulimit to ensure an
>> environment in which the SOE will happen if DRLVM is working
>> right. Therefore, we need to set things up such that not getting an
>> SOE is indeed a failure.
>
> What a user would most likely expect on a system with no stack limit?
> Something like on the other systems with stack limit as in
> run-anywhere concept. And that would be SOE, not swapping. So, let's
> limit the stack by, say, 10M if not set with an option. We can
> implement the option later.
Well if you run StackTest on RI on a machine which doesn't have any
stack limit imposed by OS you'll still see SOE quite soon. So RI has a
limited stack size anyway.
--
Gregory
Re: [drlvm][em64t] build fails
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x223 day of Apache Harmony Geir Magnusson, Jr. wrote:
> Gregory Shimansky wrote:
> > Geir Magnusson Jr. wrote:
> >>
> >>
> >> Gregory Shimansky wrote:
> >>>>
> >>> -Xss is the lower stack limit, it doesn't specify the maximum
> >>> stack size, doesn't it?
> >>
> >> What does "lower stack limit" mean? :) I think that it's the size
> >> of the stack, max.
> > I thought it is a starting stack size, like -Xms for heap size. Now
> > that I searched the web it appears that it is the maximum indeed.
>
> "0" is minimum stack size.
>
> >
> >> I think all you need to do then is set the stack size :
> >>
> >> ulimit -s 8192
> >>
> >> or something. We should probably do this before each run on linux
> >> so that things are well defined and reproducible.
> > I think 64-bit SuSE9 is just the only weird distribution which
> > doesn't have this limit. In 10th version they fixed this. So ulimit
> > -s is not necessary in most cases.
>
> But harmless. And it makes the test predicable across platforms. and
> if the StackSize test is forked, we can make it small to make it
> quick...
I know nothing about forking Java processes. Does it make sense?
Secondly, fork() is fast regardless of the stack size (stacks are COW).
> > I'd still like to have a recursion limit in StackTest but Rana has
> > convinced me that no SOE shouldn't mean that test has failed. I'll
> > patch it now.
> >
>
> I agree that your fix is utterly bogus :) but we want to test SOE
> machinery, so I think that we should set the ulimit to ensure an
> environment in which the SOE will happen if DRLVM is working
> right. Therefore, we need to set things up such that not getting an
> SOE is indeed a failure.
What a user would most likely expect on a system with no stack limit?
Something like on the other systems with stack limit as in
run-anywhere concept. And that would be SOE, not swapping. So, let's
limit the stack by, say, 10M if not set with an option. We can
implement the option later.
--
Egor Pasko
Re: [drlvm][em64t] build fails
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Gregory Shimansky wrote:
> Geir Magnusson Jr. wrote:
>>
>>
>> Gregory Shimansky wrote:
>>>>
>>> -Xss is the lower stack limit, it doesn't specify the maximum stack
>>> size, doesn't it?
>>
>> What does "lower stack limit" mean? :) I think that it's the size of
>> the stack, max.
>
> I thought it is a starting stack size, like -Xms for heap size. Now that
> I searched the web it appears that it is the maximum indeed.
"0" is minimum stack size.
>
>> I think all you need to do then is set the stack size :
>>
>> ulimit -s 8192
>>
>> or something. We should probably do this before each run on linux so
>> that things are well defined and reproducible.
>
> I think 64-bit SuSE9 is just the only weird distribution which doesn't
> have this limit. In 10th version they fixed this. So ulimit -s is not
> necessary in most cases.
But harmless. And it makes the test predicable across platforms. and
if the StackSize test is forked, we can make it small to make it quick...
>
> I'd still like to have a recursion limit in StackTest but Rana has
> convinced me that no SOE shouldn't mean that test has failed. I'll patch
> it now.
>
I agree that your fix is utterly bogus :) but we want to test SOE
machinery, so I think that we should set the ulimit to ensure an
environment in which the SOE will happen if DRLVM is working right.
Therefore, we need to set things up such that not getting an SOE is
indeed a failure.
geir
Re: [drlvm][em64t] build fails
Posted by Gregory Shimansky <gs...@gmail.com>.
Geir Magnusson Jr. wrote:
>
>
> Gregory Shimansky wrote:
>> Geir Magnusson Jr. wrote:
>>>
>>>
>>> Gregory Shimansky wrote:
>>>> Pavel Afremov wrote:
>>>>> On 11/13/06, Gregory Shimansky <gs...@gmail.com> wrote:
>>>>>>
>>>>>> So what is the point to have a test which would pass either way?
>>>>>> Check
>>>>>> that it doesn't crash the VM, is it the only purpose for it?
>>>>>>
>>>>> I think yes. It should check that test doesn't crash VM if stack
>>>>> size isn't
>>>>> enough.
>>>>
>>>> But we wouldn't know that SOE has happened or not if test passes
>>>> even when SOE was not thrown.
>>>>
>>>> It seems like SuSE9 is the only existing distribution which doesn't
>>>> limit stack size on 64-bit architectures. SuSE10 has this limit and
>>>> Gentoo has it too. Should we care that this test fails on SuSE9 when
>>>> it passes on all other platforms and SOE is known to be thrown?
>>>
>>> How could there be no limit to stack size??
>>
>> Well there is no stack limit imposed by the OS on SuSE9. Maybe it is
>> specific to this version because on SuSE10 there is a normal limit of
>> 8Mb. But when I run ulimit -a on SuSE9 I see this:
>>
>> core file size (blocks, -c) unlimited
>> data seg size (kbytes, -d) unlimited
>> file size (blocks, -f) unlimited
>> max locked memory (kbytes, -l) unlimited
>> max memory size (kbytes, -m) unlimited
>> open files (-n) 4096
>> pipe size (512 bytes, -p) 8
>> stack size (kbytes, -s) unlimited
>> cpu time (seconds, -t) unlimited
>> max user processes (-u) 40960
>> virtual memory (kbytes, -v) unlimited
>>
>> So the stack may grow up to the virtual address range which is pretty
>> huge on 64-bit platforms. No physical memory is enough to allocate
>> stack this big, so the system starts swapping nonstop. Maybe OOM linux
>> killer will kill this process after some time, maybe not.
>>
>>> Is there a way the test framework could set this? Does DRLVM support
>>> -Xss yet?
>>
>> -Xss is the lower stack limit, it doesn't specify the maximum stack
>> size, doesn't it?
>
> What does "lower stack limit" mean? :) I think that it's the size of
> the stack, max.
I thought it is a starting stack size, like -Xms for heap size. Now that
I searched the web it appears that it is the maximum indeed.
> I think all you need to do then is set the stack size :
>
> ulimit -s 8192
>
> or something. We should probably do this before each run on linux so
> that things are well defined and reproducible.
I think 64-bit SuSE9 is just the only weird distribution which doesn't
have this limit. In 10th version they fixed this. So ulimit -s is not
necessary in most cases.
I'd still like to have a recursion limit in StackTest but Rana has
convinced me that no SOE shouldn't mean that test has failed. I'll patch
it now.
--
Gregory
Re: [drlvm][em64t] build fails
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Gregory Shimansky wrote:
> Geir Magnusson Jr. wrote:
>>
>>
>> Gregory Shimansky wrote:
>>> Pavel Afremov wrote:
>>>> On 11/13/06, Gregory Shimansky <gs...@gmail.com> wrote:
>>>>>
>>>>> So what is the point to have a test which would pass either way? Check
>>>>> that it doesn't crash the VM, is it the only purpose for it?
>>>>>
>>>> I think yes. It should check that test doesn't crash VM if stack
>>>> size isn't
>>>> enough.
>>>
>>> But we wouldn't know that SOE has happened or not if test passes even
>>> when SOE was not thrown.
>>>
>>> It seems like SuSE9 is the only existing distribution which doesn't
>>> limit stack size on 64-bit architectures. SuSE10 has this limit and
>>> Gentoo has it too. Should we care that this test fails on SuSE9 when
>>> it passes on all other platforms and SOE is known to be thrown?
>>
>> How could there be no limit to stack size??
>
> Well there is no stack limit imposed by the OS on SuSE9. Maybe it is
> specific to this version because on SuSE10 there is a normal limit of
> 8Mb. But when I run ulimit -a on SuSE9 I see this:
>
> core file size (blocks, -c) unlimited
> data seg size (kbytes, -d) unlimited
> file size (blocks, -f) unlimited
> max locked memory (kbytes, -l) unlimited
> max memory size (kbytes, -m) unlimited
> open files (-n) 4096
> pipe size (512 bytes, -p) 8
> stack size (kbytes, -s) unlimited
> cpu time (seconds, -t) unlimited
> max user processes (-u) 40960
> virtual memory (kbytes, -v) unlimited
>
> So the stack may grow up to the virtual address range which is pretty
> huge on 64-bit platforms. No physical memory is enough to allocate stack
> this big, so the system starts swapping nonstop. Maybe OOM linux killer
> will kill this process after some time, maybe not.
>
>> Is there a way the test framework could set this? Does DRLVM support
>> -Xss yet?
>
> -Xss is the lower stack limit, it doesn't specify the maximum stack
> size, doesn't it?
What does "lower stack limit" mean? :) I think that it's the size of
the stack, max.
I think all you need to do then is set the stack size :
ulimit -s 8192
or something. We should probably do this before each run on linux so
that things are well defined and reproducible.
geir
>
Re: [drlvm][em64t] build fails
Posted by Gregory Shimansky <gs...@gmail.com>.
Geir Magnusson Jr. wrote:
>
>
> Gregory Shimansky wrote:
>> Pavel Afremov wrote:
>>> On 11/13/06, Gregory Shimansky <gs...@gmail.com> wrote:
>>>>
>>>> So what is the point to have a test which would pass either way? Check
>>>> that it doesn't crash the VM, is it the only purpose for it?
>>>>
>>> I think yes. It should check that test doesn't crash VM if stack size
>>> isn't
>>> enough.
>>
>> But we wouldn't know that SOE has happened or not if test passes even
>> when SOE was not thrown.
>>
>> It seems like SuSE9 is the only existing distribution which doesn't
>> limit stack size on 64-bit architectures. SuSE10 has this limit and
>> Gentoo has it too. Should we care that this test fails on SuSE9 when
>> it passes on all other platforms and SOE is known to be thrown?
>
> How could there be no limit to stack size??
Well there is no stack limit imposed by the OS on SuSE9. Maybe it is
specific to this version because on SuSE10 there is a normal limit of
8Mb. But when I run ulimit -a on SuSE9 I see this:
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 4096
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) unlimited
cpu time (seconds, -t) unlimited
max user processes (-u) 40960
virtual memory (kbytes, -v) unlimited
So the stack may grow up to the virtual address range which is pretty
huge on 64-bit platforms. No physical memory is enough to allocate stack
this big, so the system starts swapping nonstop. Maybe OOM linux killer
will kill this process after some time, maybe not.
> Is there a way the test framework could set this? Does DRLVM support
> -Xss yet?
-Xss is the lower stack limit, it doesn't specify the maximum stack
size, doesn't it?
--
Gregory
Re: [drlvm][em64t] build fails
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Gregory Shimansky wrote:
> Pavel Afremov wrote:
>> On 11/13/06, Gregory Shimansky <gs...@gmail.com> wrote:
>>>
>>> So what is the point to have a test which would pass either way? Check
>>> that it doesn't crash the VM, is it the only purpose for it?
>>>
>> I think yes. It should check that test doesn't crash VM if stack size
>> isn't
>> enough.
>
> But we wouldn't know that SOE has happened or not if test passes even
> when SOE was not thrown.
>
> It seems like SuSE9 is the only existing distribution which doesn't
> limit stack size on 64-bit architectures. SuSE10 has this limit and
> Gentoo has it too. Should we care that this test fails on SuSE9 when it
> passes on all other platforms and SOE is known to be thrown?
How could there be no limit to stack size??
Is there a way the test framework could set this? Does DRLVM support
-Xss yet?
geir
Re: [drlvm][em64t] build fails
Posted by Gregory Shimansky <gs...@gmail.com>.
Pavel Afremov wrote:
> On 11/13/06, Gregory Shimansky <gs...@gmail.com> wrote:
>>
>> So what is the point to have a test which would pass either way? Check
>> that it doesn't crash the VM, is it the only purpose for it?
>>
> I think yes. It should check that test doesn't crash VM if stack size isn't
> enough.
But we wouldn't know that SOE has happened or not if test passes even
when SOE was not thrown.
It seems like SuSE9 is the only existing distribution which doesn't
limit stack size on 64-bit architectures. SuSE10 has this limit and
Gentoo has it too. Should we care that this test fails on SuSE9 when it
passes on all other platforms and SOE is known to be thrown?
--
Gregory
Re: [drlvm][em64t] build fails
Posted by Pavel Afremov <pa...@gmail.com>.
On 11/13/06, Gregory Shimansky <gs...@gmail.com> wrote:
>
> So what is the point to have a test which would pass either way? Check
> that it doesn't crash the VM, is it the only purpose for it?
>
I think yes. It should check that test doesn't crash VM if stack size isn't
enough.
Pasha Afremov.
Re: [drlvm][em64t] build fails
Posted by Gregory Shimansky <gs...@gmail.com>.
Pavel Afremov wrote:
> Hello
>
>
>
> I think that Stack test should print pass if no stack overflow error is
> happened.
>
> Test should check processing of this error but not existing of it.
>
>
>
> Optimizing compiler can do very deep recursion unrolling, and SOE can
> happen
> never in this case.
So what is the point to have a test which would pass either way? Check
that it doesn't crash the VM, is it the only purpose for it?
--
Gregory
Re: [drlvm][em64t] build fails
Posted by Pavel Afremov <pa...@gmail.com>.
Hello
I think that Stack test should print pass if no stack overflow error is
happened.
Test should check processing of this error but not existing of it.
Optimizing compiler can do very deep recursion unrolling, and SOE can happen
never in this case.
Thanks
Pavel Afremov.
On 11/13/06, Gregory Shimansky <gs...@gmail.com> wrote:
>
> Gregory Shimansky wrote:
> > On Saturday 11 November 2006 02:36 Pavel Pervov wrote:
> >> Gregory,
> >>
> >> Could you look at https://issues.apache.org/jira/browse/HARMONY-2152. I
> >> believe it'll fix the build.
> >
> > Thank you for a quick fix. The build works now. Don't try to run
> acceptance
> > tests though. The StackTest is a machine killer. It eats all of the
> virtual
> > memory in a moment because it cannot find any stack limit ("ulimit -s
> 8192"
> > may be used as a workaround) and maps all of 2^48 (or whatever number of
> bits
> > are configured in kernel for virtual address space) bytes of virtual
> memory.
> > After that only reset helps.
>
> Ok back to this bug. I decided that on x86_64 linuxes (and ia32 which
> don't have a stack limit for some reason) we need to at least fix the
> test so that it doesn't make OS unusable. I've modified StackTest to
> check firt 10,000,000 recursions and fail is SOE is not thrown. The
> patch is available in HARMONY-2175.
>
> --
> Gregory
>
>
Re: [drlvm][em64t] build fails
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x221 day of Apache Harmony Mika Miettinen wrote:
> Gregory Shimansky wrote:
>
> >On Tuesday 14 November 2006 00:51 Gregory Shimansky wrote:
> >
> >>I'm going to try to do this on my Gentoo at home now. It is mostly
> >>bleeding edge up to date installation.
> >>
> >
> > Now I see what you're talking about. The threading library of
> > classlib doesn't compile on x86_64. It fails with the same error
> >
> > [exec]
> > /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:
> > warning: creating a DT_TEXTREL in object.
> > [exec]
> > /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:
> > x86_64/thrspinlock.o: relocation R_X86_64_PC32 against
> > `hythread_yield' can not be used when making a shared object;
> > recompile with -fPIC
> > [exec]
> > /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:
> > final link failed: Bad value
> >
> > I've found out that thrspinlock.o is compiled from an assembly code
> > of thrspinlock.s which was created in HARMONY-1005. It looks like
> > something wasn't done correctly enough. On SuSE9 it did work ok, but
> > not any more. Compiling assembly sources with "gcc -fpic" didn't
> > change anything. It looks like the code itself has to be changed.
> >
> >
> Sorry for butting into the conversation here, but does this problem
> have something to do with trying to compile on 64-bit linux
> especially?
yes, there is a substring "[em64t]" in the subject line to clarify this
at least, you should put an extra -Dos.arch=x86_64 for classlib
> Because I am getting this same error when I try to compile on 64-bit
> Gentoo on my AMD Athlon 64. But everything goes smoothly when
> compiling on 32-bit Ubuntu on this same computer. Sorry if I'm
> stating something obvious, just wanted to know.
>
> Mika Miettinen
>
>
--
Egor Pasko
Re: [drlvm][em64t] build fails
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Mika Miettinen wrote:
> Gregory Shimansky wrote:
>
>> On Tuesday 14 November 2006 00:51 Gregory Shimansky wrote:
>>
>>
>>> I'm going to try to do this on my Gentoo at home now. It is mostly
>>> bleeding edge up to date installation.
>>>
>>
>> Now I see what you're talking about. The threading library of classlib
>> doesn't compile on x86_64. It fails with the same error
>>
>> [exec]
>> /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:
>> warning: creating a DT_TEXTREL in object.
>> [exec]
>> /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:
>> x86_64/thrspinlock.o: relocation R_X86_64_PC32 against
>> `hythread_yield' can not be used when making a shared object;
>> recompile with -fPIC
>> [exec]
>> /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:
>> final link failed: Bad value
>>
>> I've found out that thrspinlock.o is compiled from an assembly code of
>> thrspinlock.s which was created in HARMONY-1005. It looks like
>> something wasn't done correctly enough. On SuSE9 it did work ok, but
>> not any more. Compiling assembly sources with "gcc -fpic" didn't
>> change anything. It looks like the code itself has to be changed.
>>
>>
>>
> Sorry for butting into the conversation here, but does this problem have
> something to do
> with trying to compile on 64-bit linux especially?
Thanks for "butting in" :)
> Because I am getting
> this same
> error when I try to compile on 64-bit Gentoo on my AMD Athlon 64. But
> everything goes
> smoothly when compiling on 32-bit Ubuntu on this same computer. Sorry if
> I'm stating
> something obvious, just wanted to know.
>
> Mika Miettinen
>
>
Re: [drlvm][em64t] build fails
Posted by Mika Miettinen <mi...@elisanet.fi>.
Gregory Shimansky wrote:
>On Tuesday 14 November 2006 00:51 Gregory Shimansky wrote:
>
>
>>I'm going to try to do this on my Gentoo at home now. It is mostly
>>bleeding edge up to date installation.
>>
>>
>
>Now I see what you're talking about. The threading library of classlib doesn't
>compile on x86_64. It fails with the same error
>
>[exec] /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:
>warning: creating a DT_TEXTREL in object.
>[exec] /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:
>x86_64/thrspinlock.o: relocation R_X86_64_PC32 against `hythread_yield' can
>not be used when making a shared object; recompile with -fPIC
>[exec] /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:
>final link failed: Bad value
>
>I've found out that thrspinlock.o is compiled from an assembly code of
>thrspinlock.s which was created in HARMONY-1005. It looks like something
>wasn't done correctly enough. On SuSE9 it did work ok, but not any more.
>Compiling assembly sources with "gcc -fpic" didn't change anything. It looks
>like the code itself has to be changed.
>
>
>
Sorry for butting into the conversation here, but does this problem have
something to do
with trying to compile on 64-bit linux especially? Because I am getting
this same
error when I try to compile on 64-bit Gentoo on my AMD Athlon 64. But
everything goes
smoothly when compiling on 32-bit Ubuntu on this same computer. Sorry if
I'm stating
something obvious, just wanted to know.
Mika Miettinen
Re: [drlvm][em64t] build fails
Posted by Gregory Shimansky <gs...@gmail.com>.
Gregory Shimansky wrote:
> Stefano Mazzocchi wrote:
>> Gregory Shimansky wrote:
>>> On Tuesday 14 November 2006 00:51 Gregory Shimansky wrote:
>>>> I'm going to try to do this on my Gentoo at home now. It is mostly
>>>> bleeding edge up to date installation.
>>> Now I see what you're talking about. The threading library of
>>> classlib doesn't compile on x86_64. It fails with the same error
>>>
>>> [exec]
>>> /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:
>>> warning: creating a DT_TEXTREL in object.
>>> [exec]
>>> /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:
>>> x86_64/thrspinlock.o: relocation R_X86_64_PC32 against
>>> `hythread_yield' can not be used when making a shared object;
>>> recompile with -fPIC
>>> [exec]
>>> /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:
>>> final link failed: Bad value
>>>
>>> I've found out that thrspinlock.o is compiled from an assembly code
>>> of thrspinlock.s which was created in HARMONY-1005. It looks like
>>> something wasn't done correctly enough. On SuSE9 it did work ok, but
>>> not any more. Compiling assembly sources with "gcc -fpic" didn't
>>> change anything. It looks like the code itself has to be changed.
>>
>> Thanks for having identified the issue.
>>
>> Do we have any idea on how to proceed?
>>
>> (sorry for being pushy, but gump is waiting ;-)
>>
>
> I think I've found a solution. The fix for assembly code is in
> HARMONY-2185. Now if I get everything working with it I'll commit the
> patch.
I've committed the fix. I had to also patch drlvm to make it compile on
gcc 4.1. In depends for classlib I had to link
/usr/lib64/lib{lcms,png,jpeg}.so files because the static versions don't
work.
Now it seems to be working but many tests crash. For the most part these
tests are kernel tests running on jitrino.opt.
--
Gregory
Re: [drlvm][em64t] build fails
Posted by Gregory Shimansky <gs...@gmail.com>.
Stefano Mazzocchi wrote:
> Gregory Shimansky wrote:
>> On Tuesday 14 November 2006 00:51 Gregory Shimansky wrote:
>>> I'm going to try to do this on my Gentoo at home now. It is mostly
>>> bleeding edge up to date installation.
>> Now I see what you're talking about. The threading library of classlib doesn't
>> compile on x86_64. It fails with the same error
>>
>> [exec] /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:
>> warning: creating a DT_TEXTREL in object.
>> [exec] /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:
>> x86_64/thrspinlock.o: relocation R_X86_64_PC32 against `hythread_yield' can
>> not be used when making a shared object; recompile with -fPIC
>> [exec] /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:
>> final link failed: Bad value
>>
>> I've found out that thrspinlock.o is compiled from an assembly code of
>> thrspinlock.s which was created in HARMONY-1005. It looks like something
>> wasn't done correctly enough. On SuSE9 it did work ok, but not any more.
>> Compiling assembly sources with "gcc -fpic" didn't change anything. It looks
>> like the code itself has to be changed.
>
> Thanks for having identified the issue.
>
> Do we have any idea on how to proceed?
>
> (sorry for being pushy, but gump is waiting ;-)
>
I think I've found a solution. The fix for assembly code is in
HARMONY-2185. Now if I get everything working with it I'll commit the patch.
--
Gregory
Re: [drlvm][em64t] build fails
Posted by Stefano Mazzocchi <st...@apache.org>.
Gregory Shimansky wrote:
> On Tuesday 14 November 2006 00:51 Gregory Shimansky wrote:
>> I'm going to try to do this on my Gentoo at home now. It is mostly
>> bleeding edge up to date installation.
>
> Now I see what you're talking about. The threading library of classlib doesn't
> compile on x86_64. It fails with the same error
>
> [exec] /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:
> warning: creating a DT_TEXTREL in object.
> [exec] /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:
> x86_64/thrspinlock.o: relocation R_X86_64_PC32 against `hythread_yield' can
> not be used when making a shared object; recompile with -fPIC
> [exec] /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:
> final link failed: Bad value
>
> I've found out that thrspinlock.o is compiled from an assembly code of
> thrspinlock.s which was created in HARMONY-1005. It looks like something
> wasn't done correctly enough. On SuSE9 it did work ok, but not any more.
> Compiling assembly sources with "gcc -fpic" didn't change anything. It looks
> like the code itself has to be changed.
Thanks for having identified the issue.
Do we have any idea on how to proceed?
(sorry for being pushy, but gump is waiting ;-)
--
Stefano.
Re: [drlvm][em64t] build fails
Posted by Gregory Shimansky <gs...@gmail.com>.
On Tuesday 14 November 2006 00:51 Gregory Shimansky wrote:
> I'm going to try to do this on my Gentoo at home now. It is mostly
> bleeding edge up to date installation.
Now I see what you're talking about. The threading library of classlib doesn't
compile on x86_64. It fails with the same error
[exec] /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:
warning: creating a DT_TEXTREL in object.
[exec] /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:
x86_64/thrspinlock.o: relocation R_X86_64_PC32 against `hythread_yield' can
not be used when making a shared object; recompile with -fPIC
[exec] /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:
final link failed: Bad value
I've found out that thrspinlock.o is compiled from an assembly code of
thrspinlock.s which was created in HARMONY-1005. It looks like something
wasn't done correctly enough. On SuSE9 it did work ok, but not any more.
Compiling assembly sources with "gcc -fpic" didn't change anything. It looks
like the code itself has to be changed.
--
Gregory Shimansky, Intel Middleware Products Division
Re: [drlvm][em64t] build fails
Posted by Gregory Shimansky <gs...@gmail.com>.
Stefano Mazzocchi wrote:
> Gregory Shimansky wrote:
>> Gregory Shimansky wrote:
>>> On Saturday 11 November 2006 02:36 Pavel Pervov wrote:
>>>> Gregory,
>>>>
>>>> Could you look at https://issues.apache.org/jira/browse/HARMONY-2152. I
>>>> believe it'll fix the build.
>>> Thank you for a quick fix. The build works now. Don't try to run
>>> acceptance tests though. The StackTest is a machine killer. It eats
>>> all of the virtual memory in a moment because it cannot find any stack
>>> limit ("ulimit -s 8192" may be used as a workaround) and maps all of
>>> 2^48 (or whatever number of bits are configured in kernel for virtual
>>> address space) bytes of virtual memory. After that only reset helps.
>> Ok back to this bug. I decided that on x86_64 linuxes (and ia32 which
>> don't have a stack limit for some reason) we need to at least fix the
>> test so that it doesn't make OS unusable. I've modified StackTest to
>> check firt 10,000,000 recursions and fail is SOE is not thrown. The
>> patch is available in HARMONY-2175.
>
> Gregory,
>
> does this mean that you are able to compile harmony on your em64t
> machine? if so, can you tell me what version of gcc/ld you're using? thanks
I did compile harmony on em64t. The most tricky part was to set up
depends for classlib, I think I've written about it already. The
distribution is quite old SuSE9 with gcc 3.3.3 and GNU binutils (which
include ld) 2.15.90.0.1.1 20040303 (SuSE Linux).
I'm going to try to do this on my Gentoo at home now. It is mostly
bleeding edge up to date installation.
--
Gregory
Re: [drlvm][em64t] build fails
Posted by Stefano Mazzocchi <st...@apache.org>.
Gregory Shimansky wrote:
> Gregory Shimansky wrote:
>> On Saturday 11 November 2006 02:36 Pavel Pervov wrote:
>>> Gregory,
>>>
>>> Could you look at https://issues.apache.org/jira/browse/HARMONY-2152. I
>>> believe it'll fix the build.
>>
>> Thank you for a quick fix. The build works now. Don't try to run
>> acceptance tests though. The StackTest is a machine killer. It eats
>> all of the virtual memory in a moment because it cannot find any stack
>> limit ("ulimit -s 8192" may be used as a workaround) and maps all of
>> 2^48 (or whatever number of bits are configured in kernel for virtual
>> address space) bytes of virtual memory. After that only reset helps.
>
> Ok back to this bug. I decided that on x86_64 linuxes (and ia32 which
> don't have a stack limit for some reason) we need to at least fix the
> test so that it doesn't make OS unusable. I've modified StackTest to
> check firt 10,000,000 recursions and fail is SOE is not thrown. The
> patch is available in HARMONY-2175.
Gregory,
does this mean that you are able to compile harmony on your em64t
machine? if so, can you tell me what version of gcc/ld you're using? thanks
--
Stefano.
Re: [drlvm][em64t] build fails
Posted by Gregory Shimansky <gs...@gmail.com>.
Gregory Shimansky wrote:
> On Saturday 11 November 2006 02:36 Pavel Pervov wrote:
>> Gregory,
>>
>> Could you look at https://issues.apache.org/jira/browse/HARMONY-2152. I
>> believe it'll fix the build.
>
> Thank you for a quick fix. The build works now. Don't try to run acceptance
> tests though. The StackTest is a machine killer. It eats all of the virtual
> memory in a moment because it cannot find any stack limit ("ulimit -s 8192"
> may be used as a workaround) and maps all of 2^48 (or whatever number of bits
> are configured in kernel for virtual address space) bytes of virtual memory.
> After that only reset helps.
Ok back to this bug. I decided that on x86_64 linuxes (and ia32 which
don't have a stack limit for some reason) we need to at least fix the
test so that it doesn't make OS unusable. I've modified StackTest to
check firt 10,000,000 recursions and fail is SOE is not thrown. The
patch is available in HARMONY-2175.
--
Gregory
Re: [drlvm][em64t] build fails
Posted by Stefano Mazzocchi <st...@apache.org>.
Pavel Pervov wrote:
> Stefano,
>
> (you guys rock, btw!)
>
> We do sometime. ;)
:-D
>> and googling for hyzip doesn't yield anything interesting.
>
> Hyzlib is something that is build along with classlib (it is part of
> ZipSupport in classlib). As you didn't finish classlib build, you do not
> have hyzlib.
> But VMI requires hyzlib to link succesfully.
ah-ha! that explains it thanks.
So, it seems that I need to get the classlib fixed before I can attempt
to move on.
BTW, if people want to follow along, I have a cruisecontrol instance
running on Geir's server that will try every 5 minutes to rebuild if
there are some svn changes.
Find it at http://67.86.14.213:10001/
BTW, I also managed to successfully cloned a full gump run from our ASF
boxes, find it at
http://67.86.14.213:10000/gump/
but it's running with Sun's JVM. (currently running at around 79%
completion)
If you guys help me run harmony on x86_64, it will be a matter of
minutes for me to get an harmony-powered gump going.
--
Stefano.
Re: [drlvm][em64t] build fails
Posted by Pavel Pervov <pm...@gmail.com>.
Stefano,
(you guys rock, btw!)
We do sometime. ;)
> and googling for hyzip doesn't yield anything interesting.
Hyzlib is something that is build along with classlib (it is part of
ZipSupport in classlib). As you didn't finish classlib build, you do not
have hyzlib.
But VMI requires hyzlib to link succesfully.
Regards
--
Pavel Pervov,
Intel Enterprise Solutions Software Division
Re: [drlvm][em64t] build fails
Posted by Stefano Mazzocchi <st...@apache.org>.
Gregory Shimansky wrote:
> On Saturday 11 November 2006 02:36 Pavel Pervov wrote:
>> Gregory,
>>
>> Could you look at https://issues.apache.org/jira/browse/HARMONY-2152. I
>> believe it'll fix the build.
>
> Thank you for a quick fix. The build works now. Don't try to run acceptance
> tests though. The StackTest is a machine killer. It eats all of the virtual
> memory in a moment because it cannot find any stack limit ("ulimit -s 8192"
> may be used as a workaround) and maps all of 2^48 (or whatever number of bits
> are configured in kernel for virtual address space) bytes of virtual memory.
> After that only reset helps.
Cool, that worked (you guys rock, btw!), I'm going much farther ahead
now. I got a -lxml2 not found, so I apt-get libxml2-dev (would be cool
to have a list of needed packages to apt-get for, btw) and I got past
that as well but now I get
build.native.link:
[cc] 0 total files to be compiled.
[cc] Starting link
[cc] /usr/bin/ld: cannot find -lhyzip
[cc] collect2: ld returned 1 exit status
BUILD FAILED
and googling for hyzip doesn't yield anything interesting.
Suggestions?
--
Stefano.
Re: [drlvm][em64t] build fails
Posted by Gregory Shimansky <gs...@gmail.com>.
On Saturday 11 November 2006 02:36 Pavel Pervov wrote:
> Gregory,
>
> Could you look at https://issues.apache.org/jira/browse/HARMONY-2152. I
> believe it'll fix the build.
Thank you for a quick fix. The build works now. Don't try to run acceptance
tests though. The StackTest is a machine killer. It eats all of the virtual
memory in a moment because it cannot find any stack limit ("ulimit -s 8192"
may be used as a workaround) and maps all of 2^48 (or whatever number of bits
are configured in kernel for virtual address space) bytes of virtual memory.
After that only reset helps.
> On 11/11/06, Gregory Shimansky <gs...@gmail.com> wrote:
> > On Saturday 11 November 2006 01:43 Weldon Washburn wrote:
> > > On 11/10/06, Gregory Shimansky <gs...@gmail.com> wrote:
> > > > Same for me. I saw this yesterday. It is because HARMONY-1558 has
> >
> > changed
> >
> > > Sorry about that. I looked at Stefano's error messages. They are very
> > > similar to the ones we battled a few days ago on linux 32-bit platform.
> > > Pavel Pervov can probably tell you exactly what needs to be fixed.
> >
> > I think I can figure out myself just looking at what changes in the patch
> > were
> > done to Class::managed_null and Class::name.
> >
> > There is no reason for excuses. You did a very good job with a patch that
> > big,
> > it is good enough we didn't break anything on ia32 with it :)
> >
> > > I probably need access to a Linux 64-bit machine so that build problems
> > > like this get fixed *before* committing.
> >
> > I'll try to check my commits on x86_64 too once in a while.
--
Gregory Shimansky, Intel Middleware Products Division
Re: [drlvm][em64t] build fails
Posted by Pavel Pervov <pm...@gmail.com>.
It looks like I'll have the patch ready in a few minutes.
Sorry for breaking this.
On 11/11/06, Gregory Shimansky <gs...@gmail.com> wrote:
>
> On Saturday 11 November 2006 01:43 Weldon Washburn wrote:
> > On 11/10/06, Gregory Shimansky <gs...@gmail.com> wrote:
> > > Same for me. I saw this yesterday. It is because HARMONY-1558 has
> changed
> >
> > Sorry about that. I looked at Stefano's error messages. They are very
> > similar to the ones we battled a few days ago on linux 32-bit platform.
> > Pavel Pervov can probably tell you exactly what needs to be fixed.
>
> I think I can figure out myself just looking at what changes in the patch
> were
> done to Class::managed_null and Class::name.
>
> There is no reason for excuses. You did a very good job with a patch that
> big,
> it is good enough we didn't break anything on ia32 with it :)
>
> > I probably need access to a Linux 64-bit machine so that build problems
> > like this get fixed *before* committing.
>
> I'll try to check my commits on x86_64 too once in a while.
>
> --
> Gregory Shimansky, Intel Middleware Products Division
>
--
Pavel Pervov,
Intel Enterprise Solutions Software Division
Re: [drlvm][em64t] build fails
Posted by Pavel Pervov <pm...@gmail.com>.
Gregory,
Could you look at https://issues.apache.org/jira/browse/HARMONY-2152. I
believe it'll fix the build.
On 11/11/06, Gregory Shimansky <gs...@gmail.com> wrote:
>
> On Saturday 11 November 2006 01:43 Weldon Washburn wrote:
> > On 11/10/06, Gregory Shimansky <gs...@gmail.com> wrote:
> > > Same for me. I saw this yesterday. It is because HARMONY-1558 has
> changed
> >
> > Sorry about that. I looked at Stefano's error messages. They are very
> > similar to the ones we battled a few days ago on linux 32-bit platform.
> > Pavel Pervov can probably tell you exactly what needs to be fixed.
>
> I think I can figure out myself just looking at what changes in the patch
> were
> done to Class::managed_null and Class::name.
>
> There is no reason for excuses. You did a very good job with a patch that
> big,
> it is good enough we didn't break anything on ia32 with it :)
>
> > I probably need access to a Linux 64-bit machine so that build problems
> > like this get fixed *before* committing.
>
> I'll try to check my commits on x86_64 too once in a while.
>
> --
> Gregory Shimansky, Intel Middleware Products Division
>
--
Pavel Pervov,
Intel Enterprise Solutions Software Division
Re: [drlvm][em64t] build fails
Posted by Gregory Shimansky <gs...@gmail.com>.
On Saturday 11 November 2006 01:43 Weldon Washburn wrote:
> On 11/10/06, Gregory Shimansky <gs...@gmail.com> wrote:
> > Same for me. I saw this yesterday. It is because HARMONY-1558 has changed
>
> Sorry about that. I looked at Stefano's error messages. They are very
> similar to the ones we battled a few days ago on linux 32-bit platform.
> Pavel Pervov can probably tell you exactly what needs to be fixed.
I think I can figure out myself just looking at what changes in the patch were
done to Class::managed_null and Class::name.
There is no reason for excuses. You did a very good job with a patch that big,
it is good enough we didn't break anything on ia32 with it :)
> I probably need access to a Linux 64-bit machine so that build problems
> like this get fixed *before* committing.
I'll try to check my commits on x86_64 too once in a while.
--
Gregory Shimansky, Intel Middleware Products Division
Re: [drlvm][em64t] build fails
Posted by Weldon Washburn <we...@gmail.com>.
On 11/10/06, Gregory Shimansky <gs...@gmail.com> wrote:
>
> Same for me. I saw this yesterday. It is because HARMONY-1558 has changed
Sorry about that. I looked at Stefano's error messages. They are very
similar to the ones we battled a few days ago on linux 32-bit platform.
Pavel Pervov can probably tell you exactly what needs to be fixed.
I probably need access to a Linux 64-bit machine so that build problems like
this get fixed *before* committing.
Class interfaces but didn't change x86_64 specific files. Now that I look at
> the error messages, I think it is quite easy to fix the build. I'll take
> care
> of weekend.
>
> I wonder how did you get to building drlvm if classlib didn't build for
> you
> because of -fpic problem? DRLVM build always requires prebuilt classlib...
>
> On Friday 10 November 2006 23:53 Stefano Mazzocchi wrote:
> > I've managed to get everything in place for a DRLVM build.. it runs for
> > a while and then it fails with these errors:
> >
> > [cc]
> >
> /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/jit_lock_rt_s
> >upport_em64t.cpp: In function 'void* rth_get_lil_monitor_enter()':
> > [cc]
> >
> /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/jit_lock_rt_s
> >upport_em64t.cpp:127: error: 'managed_null' is not a member of 'Class'
> > [cc]
> >
> /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/jit_lock_rt_s
> >upport_em64t.cpp: In function 'void* rth_get_lil_monitor_exit()':
> > [cc]
> >
> /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/jit_lock_rt_s
> >upport_em64t.cpp:265: error: 'managed_null' is not a member of 'Class'
> > [cc]
> >
> /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp
> >: In function 'void JIT_execute_method_default(void*, _jmethodID*,
> > jvalue*, jvalue*)':
> > [cc]
> >
> /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp
> >:201: error: 'struct Class' has no member named 'name'
> > [cc]
> >
> /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp
> >:229: error: 'managed_null' is not a member of 'Class'
> > [cc]
> >
> /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp
> >:326: error: 'managed_null' is not a member of 'Class'
> > [cc]
> >
> /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp
> >:359: error: 'struct Class' has no member named 'name'
> >
> > Suggestions?
>
> --
> Gregory Shimansky, Intel Middleware Products Division
>
--
Weldon Washburn
Intel Enterprise Solutions Software Division
Re: [drlvm][em64t] build fails
Posted by Gregory Shimansky <gs...@gmail.com>.
Same for me. I saw this yesterday. It is because HARMONY-1558 has changed
Class interfaces but didn't change x86_64 specific files. Now that I look at
the error messages, I think it is quite easy to fix the build. I'll take care
of weekend.
I wonder how did you get to building drlvm if classlib didn't build for you
because of -fpic problem? DRLVM build always requires prebuilt classlib...
On Friday 10 November 2006 23:53 Stefano Mazzocchi wrote:
> I've managed to get everything in place for a DRLVM build.. it runs for
> a while and then it fails with these errors:
>
> [cc]
> /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/jit_lock_rt_s
>upport_em64t.cpp: In function ‘void* rth_get_lil_monitor_enter()’:
> [cc]
> /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/jit_lock_rt_s
>upport_em64t.cpp:127: error: ‘managed_null’ is not a member of ‘Class’
> [cc]
> /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/jit_lock_rt_s
>upport_em64t.cpp: In function ‘void* rth_get_lil_monitor_exit()’:
> [cc]
> /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/jit_lock_rt_s
>upport_em64t.cpp:265: error: ‘managed_null’ is not a member of ‘Class’
> [cc]
> /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp
>: In function ‘void JIT_execute_method_default(void*, _jmethodID*,
> jvalue*, jvalue*)’:
> [cc]
> /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp
>:201: error: ‘struct Class’ has no member named ‘name’
> [cc]
> /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp
>:229: error: ‘managed_null’ is not a member of ‘Class’
> [cc]
> /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp
>:326: error: ‘managed_null’ is not a member of ‘Class’
> [cc]
> /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp
>:359: error: ‘struct Class’ has no member named ‘name’
>
> Suggestions?
--
Gregory Shimansky, Intel Middleware Products Division