2

I have rasters in my program of approximately 1500x500 pixels. Each pixel is represented with a float. I believe that means that 1500x500x4(bytes) = 3 million bytes or 3mb. They can be bigger than this. Does the Java Garbage Collector treat big objects differently than smaller ones? Do they skip into a higher generation automatically?

smuggledPancakes
  • 9,881
  • 20
  • 74
  • 113
  • 3
    I don;t think there is any discrimination like that. If no reference exists to object, then object is eligible for GC irrespective big or small. – kosa Jul 09 '12 at 15:15
  • 1
    why do you care if the gc treats big objects differently? – jtahlborn Jul 09 '12 at 15:17
  • Besides which, unless something like this is delimited specifically in the memory model, it's implementation specific. – Clockwork-Muse Jul 09 '12 at 15:18
  • 1
    @jtahlborn, b/c it's bloody important, the young gen is very fast to be collected unlike the tenured one which may involve stop the world full gc for few seconds. – bestsss Jul 09 '12 at 15:31
  • @thinksteep, performance-wise there is, GC is not some magic thing that happens and the application is unaffected (possible w/ read-barrier gc, aka real-time GCs but most widely-spread GCs are not amongst them) – bestsss Jul 09 '12 at 15:32
  • If you want to watch your JVM I'd recommend VisualVM which is free. Take a look at the VisualGC plugin and you can watch each generation and how it's being garbage collected. http://visualvm.java.net/plugins.html – jjathman Jul 09 '12 at 15:33
  • to answer the question, if you use large short-lived objects, make sure the young-gen (known also as nursery/eden) is large enough as well. – bestsss Jul 09 '12 at 15:34
  • @bestsss, I agree that performance-wise there is discrimination, but not while doing GC. Correct me if I am wrong. I agree with Peter Lawrey statement also, but moving to tenured doesn't mean, object is GCed. – kosa Jul 09 '12 at 15:35
  • 1
    @jjathman, -verbose:gc is usually better, albeit hard to read. – bestsss Jul 09 '12 at 15:35
  • @thinksteep, GCs try to play very smart - for instance each thread has its own area to allocate objects, hence nothing is shared in that case. The area can be too small to allocate large objects and in that case the object may go straight into the tenured area. Now, there can be different type of collections - i.e. concurrent of stop-the-world. Most impls. have stop-the-world for the tenured but can do concurrent for the young gen. – bestsss Jul 09 '12 at 15:38

1 Answers1

6

Larger objects can be placed straight into tenured space. The size of the individual objects is what matters e.g. float[1500][1500] is 1500 objects which are 1500*4 (plus overhead) each.

http://blog.dynatrace.com/2011/05/11/how-garbage-collection-differs-in-the-three-big-jvms/

This suggest JRockit does place large objects into tenured space but doesn't say anything about HotSpot.

This suggests large objects have to be larger than the young generation space to go directly into tenured space.

https://blogs.oracle.com/jonthecollector/entry/size_matters

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
  • Objects that don't fit the TLAB will go into the tenured, however you just need to resize the young gen to accommodate for the large enough array and it's ok. – bestsss Jul 09 '12 at 15:30
  • Unfortunately, resizing the young gen is a global setting and will affect all threads, so who knows whether the net effect will come out positive. – Marko Topolnik Jul 09 '12 at 16:33
  • @MarkoTopolnik, unless the application very heavily employs object pooling, larger young gens seem a win to me. I tend to configured the servers w/ 1/3 of heap as young gen. – bestsss Jul 09 '12 at 16:37
  • @bestsss I have used an 8 GB eden size and 1 GB for the rest for a low GC application. It produced less than 8 GB in a day so it GC once per day at 5 AM with no collections (minor or otherwise) during the day. – Peter Lawrey Jul 09 '12 at 17:45
  • 1
    @PeterLawrey, possible but definitely a hard task. you'd have to have all structures preallocated, not using logging [or very customized one], not using java.util.Lock, most of the String methods, no byte-char conversion, no nio selectors, no iterators, no CLQ {easy I guess w/ ring buffers}, no double->string, etc. Still possible, but it's a hard task, I am used to 250-300MB garbage per second. – bestsss Jul 09 '12 at 19:15
  • 200 MB/s is creating garbage like mad ;) – Peter Lawrey Jul 09 '12 at 19:56