Re: [rvm-research] [rvm-core] about sys.C sysMalloc warning

Hi Robin Garner,
      Thank you very much!   Lowering the  target.max-mappable.address works !
And I will search & ask in reaserchers list, Thanks again.

       Using the -X:gc:eagerMmapSpaces=true can't solve this problem.
And the malloc warning is different every time.
such as:

wcx@suse82:~> rvm HelloWorld
malloc returned something that is in RVM address space: 0xa5704530
malloc returned something that is in RVM address space: 0xa5704530


wcx@suse82:~> rvm HelloWorld
malloc returned something that is in RVM address space: 0xa2904530
malloc returned something that is in RVM address space: 0xa2904530



wcx@suse82:~> rvm HelloWorld
malloc returned something that is in RVM address space: 0xa2f04530
malloc returned something that is in RVM address space: 0xa2f04530



2015-04-13 13:02 GMT+08:00 Robin Garner <[email protected]>:
> Hi Wang,
>
> This is more on-topic for the researchers list, so I've redirected my reply
> there.
>
> MMTk strongly assumes that it can have a large contiguous chunk of virtual
> memory to itself, and it can map it lazily when it needs it.
> This doesn't sit well with Linux's assumptions about how applications want
> to use memory.  On Ubuntu, malloc generally allocates in low addresses, so
> by starting the heap at 0x50000000 or so, we allow malloc some space for
> itself.
>
> Evidently malloc on SUSE isn't doing that, and I'm not sufficiently across
> suse to know why.
>
>
> One possible workaround is to shift your virtual address space into a lower
> region of memory.
>
> Edit build/targets/x86_64-linux.properties and change the value of
>
>   target.max-mappable.address=0xb0000000
>
> to be (say) 0x80000000.  Of course this will leave you with a very small
> usable memory, so you can increase it until you have problems.
> You can also try dropping the lower-bound constants
>
> target.bootimage.code.address=0x64000000
> target.bootimage.data.address=0x60000000
> target.bootimage.rmap.address=0x67000000
>
> until you encounter problems - just make sure to keep them at the same
> offsets from each other.  I seem to recall some code that assumes that heap
> addresses are greater than 0x30000000, so that's probably the lowest usable
> offset.
>
> You could also try running with -X:gc:eagerMmapSpaces=true, which should
> reserve MMTk's heap in advance.  I'm not sure whether this still works.
>
> It's also worth checking whether malloc always uses the same addresses - if
> they move around from run to run, the problem may be harder to work around.
>
> Let us know how you get on.
>
> regards,
> Robin
>
>
> On 13/04/15 13:37, wangchenxi7 wrote:
>>
>> Hi,everyone
>>
>> I’m a new developer of JikesRVM. When I run the rvm ,something print on
>> my screen and cause some random error.
>>
>>
>> the warning is :
>>
>> malloc returned something that is in RVM address space: 0xa2f04530
>>
>> malloc returned something that is in RVM address space: 0xa2f04530
>>
>> malloc returned something that is in RVM address space: 0xa2f04530
>>
>> malloc returned something that is in RVM address space: 0xa2f04530
>>
>> malloc returned something that is in RVM address space: 0xa2f04530
>>
>> malloc returned something that is in RVM address space: 0xa2f04530
>>
>>
>> and sometimes it will crash the program:
>>
>> JikesRVM: TROUBLE.  Got a signal (Segmentation fault; #11) from outside
>> the VM's address space in thread 0xa2fffb40.
>>
>> JikesRVM: UNRECOVERABLE trapped signal 11 (Segmentation fault)
>>
>> handler stack f749be84
>>
>> si->si_addr   0x4
>>
>> cs            0x00000023
>>
>> ds            0x0000002b
>>
>> es            0x0000002b
>>
>> fs            0x00000000
>>
>> gs            0x00000063
>>
>> ss            0x0000002b
>>
>> edi           0x00000000
>>
>> esi -- PR/VP  0x000000a8
>>
>> ebp           0xa5500010
>>
>> esp -- SP     0x71a222d4
>>
>> ebx           0xf75c9ff4
>>
>> edx           0xa5500018
>>
>> ecx           0x00000000
>>
>> eax           0xa550003c
>>
>> eip           0xf749be84
>>
>> trapno        0x0000000e
>>
>> err           0x00000004
>>
>> eflags        0x00010207
>>
>> fpregs        a55042a0
>>
>> oldmask       0x00020000
>>
>> cr2           0x00000004
>>
>> fp0 0x00000000000000000000
>>
>> fp1 0x00000000000000000000
>>
>> fp2 0x00000000000000000000
>>
>> fp3 0x00000000000000000000
>>
>> fp4 0x00000000000000000000
>>
>> fp5 0x00000000000000000000
>>
>> fp6 0xb00012552516c1c34009
>>
>> fp7 0xbfc8f66208f7eb134001
>>
>> JikesRVM: internal error
>>
>> invalid native thread address (not an address a8)
>>
>> Aborted (core dumped)
>>
>>
>> But,When I copy the program(see below) and the build jikesRVM-3.13 to a
>> Ubuntu server，It’s all Ok.
>>
>>    1
>>
>>    2 public class accessArray {
>>
>>    3
>>
>>    4   public static void main(String[] args) {
>>
>>    5
>>
>>    6     final int size=1000000;
>>
>>    7
>>
>>    8 int a[]=new int[size];
>>
>>    9 int b[]=new int[size];
>>
>>   10 int c[]=new int[size];
>>
>>   11
>>
>>   12 int i,j,k;
>>
>>   13
>>
>>   14 for(i=0;i<size;i++){
>>
>>   15       a[i]=i;
>>
>>   16       b[i]=i+2;
>>
>>   17 //        System.out.println(b[i]);
>>
>>   18     }
>>
>>   19
>>
>>   20 for(j=0;j<size;j++)
>>
>>   21       c[j]=a[j]+b[j];
>>
>>   22
>>
>>   23 for(j=1;j<size;j*=10)
>>
>>   24       System.out.println(c[j]);
>>
>>   25   }
>>
>>   26
>>
>>   27 }
>>
>>
>> My platform is
>>
>> LSB
>>
>> Version:core-2.0-noarch:core-3.2-noarch:core-4.0-noarch:core-2.0-x86_64:core-3.2-x86_64:core-4.0-x86_64:desktop-4.0-amd64:desktop-4.0-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch
>>
>> Distributor ID:SUSE LINUX
>>
>> Description:openSUSE 12.2 (x86_64)
>>
>> Release:12.2
>>
>> Codename:Mantis
>>
>>
>> I can learn that this is caused by the overlap of the MMTk heap and some
>> malloc thinks.But I don’t know how to correct it ?
>>
>>
>> Anything responsed is helpful. Thank you!
>>
>>
>>        wang
>>
>> China CAS.ICT
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
>> Develop your own process in accordance with the BPMN 2 standard
>> Learn Process modeling best practices with Bonita BPM through live
>> exercises
>> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
>> event?utm_
>> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
>>
>>
>>
>> _______________________________________________
>> Jikesrvm-core mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
>>
>



--

------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Jikesrvm-researchers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers