[BOUNTY] fix mobile WLCj wallet for android

[rik8119]

Maybe because your device is of a newer generation, so newer phones can handle the memoryerror?

The main memory consumer is org.bitcoinj.core.Block with:

- org.bitcoinj.core.TransactionOutput    with 167.034 objects and 13.362.720 heap swallow   and
- byte[] with 176.775 objects and 7.195.488 heap swallow


EDIT: Inbound connection was to HeaderMessage if i am reading it correctly.

2nd Edit: The BlockMergeMinedPayload loads Transaction and this loads a TransactionOutput and this creates byte[] which has 80 byte of space, so it looks like every transaction in the Parent chain gets 80 bytes assigned.. And this leads to a high memoryload after it reaches block 10k and loading 2k more blocks (including mmBlocks)..

So the question seems to be why does the wallet sees parentcoinbase transaction as headersJ?

3rd Edit: Every new transaction has a size of 80 byte. The problem is that the wallet loads 2k blocks at once. After the block 10k the merge mining starts and the Parent header has 250+ Coinbase transactions per block. Keeping them all inside the heap memory seems to be hard for small devices but after block 12k every block is MM, so the memoryload is even bigger and the app crashes. so reducing the blocks to be loaded at once should solve the problem i guess.

...hmm when i reduce the MAX_HEADERS in HeaderMassage to 500 it completely refuses to download blocks (Error deserializing message)... weird..

[hexafraction]

Maybe because your device is of a newer generation, so newer phones can handle the memoryerror?

The main memory consumer is org.bitcoinj.core.Block with:

- org.bitcoinj.core.TransactionOutput    with 167.034 objects and 13.362.720 heap swallow   and
- byte[] with 176.775 objects and 7.195.488 heap swallow


EDIT: Inbound connection was to HeaderMessage if i am reading it correctly.

2nd Edit: The BlockMergeMinedPayload loads Transaction and this loads a TransactionOutput and this creates byte[] which has 80 byte of space, so it looks like every transaction in the Parent chain gets 80 bytes assigned.. And this leads to a high memoryload after it reaches block 10k and loading 2k more blocks (including mmBlocks)..

So the question seems to be why does the wallet sees parentcoinbase transaction as headersJ?

3rd Edit: Every new transaction has a size of 80 byte. The problem is that the wallet loads 2k blocks at once. After the block 10k the merge mining starts and the Parent header has 250+ Coinbase transactions per block. Keeping them all inside the heap memory seems to be hard for small devices but after block 12k every block is MM, so the memoryload is even bigger and the app crashes. so reducing the blocks to be loaded at once should solve the problem i guess.

...hmm when i reduce the MAX_HEADERS in HeaderMassage to 500 it completely refuses to download blocks (Error deserializing message)... weird..

Sorry about the delay. I took a look at the heap dumps you sent, and I don't see anything abnormal, or an abnormally large heap. It's all around 40-50MB as with my dumps. However, a difference I cannot test directly is dalvik vs ART. Your heap dump reports the environment as Dalvik (if I'm interpreting mixed messages correctly), while my devices uses ART instead.

[achow101]

3rd Edit: Every new transaction has a size of 80 byte. The problem is that the wallet loads 2k blocks at once. After the block 10k the merge mining starts and the Parent header has 250+ Coinbase transactions per block. Keeping them all inside the heap memory seems to be hard for small devices but after block 12k every block is MM, so the memoryload is even bigger and the app crashes. so reducing the blocks to be loaded at once should solve the problem i guess.

...hmm when i reduce the MAX_HEADERS in HeaderMassage to 500 it completely refuses to download blocks (Error deserializing message)... weird..

Try going to store/SPVBlockStore.java and changing the constant DEFAULT_NUM_HEADERS to a lower number. I think that might help.

[rik8119]

Sorry about the delay. I took a look at the heap dumps you sent, and I don't see anything abnormal, or an abnormally large heap. It's all around 40-50MB as with my dumps. However, a difference I cannot test directly is dalvik vs ART. Your heap dump reports the environment as Dalvik (if I'm interpreting mixed messages correctly), while my devices uses ART instead.

Not a deal. Yes the heap is just at 40-50 mb and when the block download reaches 12k it loads 2k blocks in the cache and that is too much, because somehow on older phones the heap memory seems to be restricted to 64 mb (sorry i dont know about whic test app is running at my anfdroid studio).

So there are 2 ways: 1. increase heap
2. reduce blocks in cache.

The second one seems to be more convienient scince older devices maybe get to slow if one app use all ram (although it is just for the download).

@ kinght
This goes straight in the right direction but memory usage is still high and it crashes at 12k (going down to 500 with DEFAULT_NUM_HEADERS and to 260 with the blockCache).

[rik8119]

So guys, now it works with additional largeHeap="true" the memory increases to 190 mb and the wallet loads fine.

I dont know why largeHeap did not work with the earlier version but hey.... you 2 rock!!

Now i just have to adjust some pics and stuff but thats it..

@hexafraction: jk14 send me a private message about a wallet for a bounty i said he maybe could ask you about. Just in case..

[hexafraction]

So guys, now it works with additional largeHeap="true" the memory increases to 190 mb and the wallet loads fine.

I dont know why largeHeap did not work with the earlier version but hey.... you 2 rock!!

Now i just have to adjust some pics and stuff but thats it..

@hexafraction: jk14 send me a private message about a wallet for a bounty i said he maybe could ask you about. Just in case..

Thanks; please let us know if anything is needed. I did get in touch with jk14; the job ended up changing to the point where it involved the C++ side of things, so I had to decline as I do not know enough C++ to make changes and make the resulting code remain secure and reliable.

[achow101]

So guys, now it works with additional largeHeap="true" the memory increases to 190 mb and the wallet loads fine.

I dont know why largeHeap did not work with the earlier version but hey.... you 2 rock!!

Now i just have to adjust some pics and stuff but thats it..

@hexafraction: jk14 send me a private message about a wallet for a bounty i said he maybe could ask you about. Just in case..

Now that you fixed that, is that all that needed to be done? Or are there other problems that need to be fixed before you can pay the bounty?

[rik8119]

So guys, now it works with additional largeHeap="true" the memory increases to 190 mb and the wallet loads fine.

I dont know why largeHeap did not work with the earlier version but hey.... you 2 rock!!

Now i just have to adjust some pics and stuff but thats it..

@hexafraction: jk14 send me a private message about a wallet for a bounty i said he maybe could ask you about. Just in case..

Now that you fixed that, is that all that needed to be done? Or are there other problems that need to be fixed before you can pay the bounty?

Nope just send me your addresses, as for my personal opinion hexafraction should get a bigger portion of the bounty but please let me know your opinion how to split the bounty.

@hexafraction, ok maybe i can help him i am much better at c++ than i am at java and now i have a little bit more time.

[rik8119]

Ok, thank you both! The last part of the bounty will be payed as soon as i have the confirmation from hexafraction.

It is sometime hard for me to get projects like this on the road. I had a little c++ in the university but the stuff needed to create a new coin, the phyton to fit p2pool for FRC/WLC and the Java/android stuff for the wallet now i had to teach me myself (good thing to have you on board for this, i tried it before and failed epicaly ;-).

So to answer hexafraction "I'm really excited to see where this coin (..WLC..) might go." It will go as far as i can. The vision is to supply communities all over the world with coins. This was already tried by many but the demurrage WLC got from Freicoin guaranties a stable monthly payout.

What WLC really needs at the moment are common good initiatives all over the globe.. So if any of you know some feel free to invite them to the WLC homepage (www.winc-ev.org).

@hexafraction thanks for the offer i will send you a message if i need help again.