Charm++ parallel programming system

[Phil Miller <unmobile AT gmail.com>]

Hi James,

I'm not really sure what's going on then. I'll let one of the current developers dig into it.

Phil

On Thu, May 24, 2018, 5:52 PM James Bordner <jobordner AT gmail.com> wrote:

Hi Phil,

I've made some modifications to the ring.C example to convert the array to a 1D chare array with dynamic insertion, and it exhibits similar behavior to my program.  I'll attach a tar file with the modified example.  What am I missing here?

Thanks!

James

Output:

$ ./pgm

Charm++: standalone mode (not using charmrun)

Charm++> Running in non-SMP mode: numPes 1

Converse/Charm++ Commit ID: v6.8.2

Warning> Randomization of virtual memory (ASLR) is turned on in the kernel, thread migration may not work! Run 'echo 0 > /proc/sys/kernel/randomize_va_space' as root to disable it, or try running with '+isomalloc_sync'.

Charm++> scheduler running in netpoll mode.

CharmLB> Load balancer assumes all CPUs are same.

Charm++> Running on 1 unique compute nodes (8-way SMP).

Charm++> cpu topology info is gathered in 0.000 seconds.

BEGIN insert element 0

Msg::pack()   msg 0x2945770  -->  buf 0x2945df0

Msg::unpack() msg 0x2945770  <--  buf 0x2945df0

Msg::pack()   msg 0x2945770  -->  buf 0x2945df0

Msg::unpack() msg 0x2945770  <--  buf 0x2945df0

Msg::unpack() msg 0x2946410  <--  buf 0x2945df0

Segmentation fault (core dumped)

Modifications to ring:

$ diff -br ring ring_insert

diff -br ring/ring.C ring_insert/ring.C

9a10

>   CkPrintf ("Msg::pack()   msg %p  -->  buf %p\n",m,p);

24a26

>    CkPrintf ("Msg::unpack() msg %p  <--  buf %p\n",t,buf);

37c39

<   CkPrintf("branch created on %d\n", CkMyPe());

---

>   CkPrintf("element inserted on %d\n", CkMyPe());

75a78,79

>   CProxy_Btest a = CProxy_Btest::ckNew();

>   for (int i=0; i<10; i++) {

82c86,90

<   CProxy_Btest::ckNew(msg1);

---

>     CkPrintf ("BEGIN insert element %d\n",i);

>     a[i].insert(msg1);

>     CkPrintf ("END   insert element %d\n",i);

>   }

>   a.doneInserting();

Only in ring_insert: ring.C~

diff -br ring/ring.ci ring_insert/ring.ci

10c10

<   group Btest {

---

>   array [1D] Btest {

On Thu, May 24, 2018 at 10:28 AM, James Bordner <jobordner AT gmail.com> wrote:

Hi Phil, I had done that as well, each individual "insert()" leads to Charm++ calling pack() twice and unpack() three times.  Again, this is on a single core, so I would expect that pack() and unpack() would not be called at all.

        87 LINE BEFORE enzo_block_array[index].insert(0x2ef93f0)

       149 MsgRefine::pack()   msg 0x2ef93f0 --> buffer 0x2ef8d10

       224 MsgRefine::unpack() msg 0x2ef9a10 <-- buffer 0x2ef8d10

        36 MsgRefine::MsgRefine(0x2ef9a10) [ in-place message constructor ]

       149 MsgRefine::pack()   msg 0x2ef9a10 --> buffer 0x2ef8d10 [ returns saved buffer ]

       224 MsgRefine::unpack() msg 0x2ef9c70 <-- buffer 0x2ef8d10

        36 MsgRefine::MsgRefine(0x2ef9c70) [ in-place message constructor ]

       224 MsgRefine::unpack() msg 0x2ef9e30 <-- buffer 0x2ef9d80

        36 MsgRefine::MsgRefine(0x2ef9e30) [ in-place message constructor ]

           Block::Block(0x2ef9e30)         [ Base element constructor ]

           EnzoBlock::EnzoBlock(0x2ef9e30) [ Derived element constructor ]

        89 LINE AFTER enzo_block_array[index].insert(0x2ef93f0)

Also, the more processes I use, the less memory leaked, so this seems specific to elements being created on the same process.

Thanks,

James

On Tue, May 22, 2018 at 2:58 PM, Phil Miller <mille121 AT illinois.edu> wrote:

Try adding prints to the constructor and destructor as well, and include the value of the 'this' pointer in all of them. I bet what you're seeing is copying of the message for each element receiving it.

On Tue, May 22, 2018 at 4:36 PM, James Bordner <jobordner AT gmail.com> wrote:

I'm trying to track down a memory leak related to creating chare array elements using a constructor that has a custom packed message argument.   I would expect the message's pack() and unpack()  methods not to get called if run on a single processor; however, they are not only called, but called multiple times per element inserted.  Specifically, pack(), unpack(), pack(), unpack(), unpack().  The chare array is derived from another base chare array, so perhaps that's causing the multiple pack()/unpack() calls.  But I don't know why the extra "unpack()" at the end, or why pack() and unpack() are getting called at all given it's a single processor run.

Thanks,

James