[drlvm] Java stack limits (was: Re: [drlvm][em64t] build fails)
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 ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: [drlvm] Java stack limits (was: Re: [drlvm][em64t] build fails)
Can we get the value from the harmonyvm.properties file? Thanks, Mikhail 2006/11/17, Tim Ellison [EMAIL PROTECTED]: 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 ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: [drlvm][em64t] build fails
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
16 Nov 2006 14:48:05 +0600, Egor Pasko [EMAIL PROTECTED]: 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][em64t] build fails
On the 0x223 day of Apache Harmony Alexey Varlamov wrote: 16 Nov 2006 14:48:05 +0600, Egor Pasko [EMAIL PROTECTED]: 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
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
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
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
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
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
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
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
On 11/15/06, Geir Magnusson Jr. [EMAIL PROTECTED] 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
Geir Magnusson Jr. wrote: Gregory Shimansky wrote: Pavel Afremov wrote: On 11/13/06, Gregory Shimansky [EMAIL PROTECTED] 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
On 11/13/06, Pavel Afremov [EMAIL PROTECTED] 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][em64t] build fails
Gregory Shimansky wrote: Geir Magnusson Jr. wrote: Gregory Shimansky wrote: Pavel Afremov wrote: On 11/13/06, Gregory Shimansky [EMAIL PROTECTED] 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
Geir Magnusson Jr. wrote: Gregory Shimansky wrote: Geir Magnusson Jr. wrote: Gregory Shimansky wrote: Pavel Afremov wrote: On 11/13/06, Gregory Shimansky [EMAIL PROTECTED] 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
Pavel Afremov wrote: On 11/15/06, *Geir Magnusson Jr.* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 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
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
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
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
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
On 11/13/06, Gregory Shimansky [EMAIL PROTECTED] 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
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
Pavel Afremov wrote: On 11/13/06, Gregory Shimansky [EMAIL PROTECTED] 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
Gregory Shimansky wrote: Pavel Afremov wrote: On 11/13/06, Gregory Shimansky [EMAIL PROTECTED] 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
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
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
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 [EMAIL PROTECTED] 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
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
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
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
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
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
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
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:1/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
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
Re: [drlvm][em64t] build fails
DRLVM build always requires prebuilt classlib... I believe ia32 classlib is ok until linking happens. On 11/11/06, Gregory Shimansky [EMAIL PROTECTED] 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
On 11/10/06, Gregory Shimansky [EMAIL PROTECTED] 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
On Saturday 11 November 2006 01:43 Weldon Washburn wrote: On 11/10/06, Gregory Shimansky [EMAIL PROTECTED] 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
It looks like I'll have the patch ready in a few minutes. Sorry for breaking this. On 11/11/06, Gregory Shimansky [EMAIL PROTECTED] wrote: On Saturday 11 November 2006 01:43 Weldon Washburn wrote: On 11/10/06, Gregory Shimansky [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] wrote: On Saturday 11 November 2006 01:43 Weldon Washburn wrote: On 11/10/06, Gregory Shimansky [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] wrote: On Saturday 11 November 2006 01:43 Weldon Washburn wrote: On 11/10/06, Gregory Shimansky [EMAIL PROTECTED] 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
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.
