• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Devaka Cooray
  • Liutauras Vilda
  • Jeanne Boyarsky
Sheriffs:
  • Knute Snortum
  • Junilu Lacar
  • paul wheaton
Saloon Keepers:
  • Ganesh Patekar
  • Frits Walraven
  • Tim Moores
  • Ron McLeod
  • Carey Brown
Bartenders:
  • Stephan van Hulst
  • salvin francis
  • Tim Holloway

Using BigInteger.modPow makes my program consume insane amounts of memory. Why?  RSS feed

 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I need to use BigInteger, because I'm going to do stuff like: 579192248571394326501337.modpow(65537,579192248571394326501337) millions of times.

But I have a pretty serious problem, I post a example which shows the core of the problem. It happens both with and without threads, so it's not related to that.

Modulo is a modular exponentiation function for longs.

------WITH BIGINTEGER---------


Result: Goes from 70 mb to 352 in 5 seconds or so. It stays at 352 mb forever(after its done). Guess this has to do with BigIntegers being inmutable, but the garbage collector should get of the unused ones, no?
The problem doesn't go away using result=result.modPow(exp,mod);, so guess that the problem isn't he inmutability?
-------WITH LONG----------



With Long: Finishes faster, and the program only consumes 70 mb before and after finishing..


Is this Javafx garbage collector fault?



 
Rancher
Posts: 42974
76
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What is the "352 mb" you mention - how is that measured? I'm not aware of any JVM that releases memory, so if that is the JVM memory allocation, it's just not going to come down (even though internally the memory would have been GCed at some point).
 
Abel Casado
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Oh I meant 352 Megabytes of memory, yeah I didn't explain myself there. I think the problem it's about the GC not doing his job properly. I just realised that it happens with a HashSet too even after I clear it and assign it to null(where I can store as max 25 mill of ints before it practically slows down to 0 speed).

About the example I posted: I have a main stage, a button at the main stage open a secondary window/stage. On this secondary stage there's a button with a controller, let's say handleModular().

And inside handleModular I modified my code to just run the simple example I posted.

Maybe the GC can't remove it because it's inside the button controller?
 
Ulf Dittmer
Rancher
Posts: 42974
76
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

I meant 352 Megabytes of memory, yeah I didn't explain myself there.


Sorry, still not clear: how is this measured? As I said, if that's the JVM process as seen by the OS, then it's just not going to go down, ever, and has nothing to do with what the GC does.
 
Abel Casado
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You're right it shows the allocated memory, not the one currently in used. I had a pretty big stupid there, thanks for making me realize it.

Anyways it's pretty strange that doing the same operations with BigInteger increases the memory allocation to 300 mb while with long it stays at 70, no?
 
Ulf Dittmer
Rancher
Posts: 42974
76
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It is normal. Once the JVM allocates memory, it never releases it. That has nothing to do with GC.

A BigInteger object needs a lot more memory than a long. It's possible that the modPow method allocates further objects during each call (you can check by looking at its source code - it's written entirely in Java).
 
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Ulf Dittmer wrote:A BigInteger object needs a lot more memory than a long. It's possible that the modPow method allocates further objects during each call (you can check by looking at its source code - it's written entirely in Java).


It does. The class uses MutableBigIntegers internally to do large calculations, and these need to be copied from the original values. And if I remember right, multiplication takes three of them.

Winston
 
Marshal
Posts: 61756
193
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to the Ranch
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!