definition of a "TLAB refill"?

sorry for the n00b or repeat question (if there is a good way to search the list archives please send me a URL) but i am trying to find a solid definition of a "TLAB refill" - most TLAB docs refer to the "refill" but don't actually define what it means. thanks. ron.

Re: definition of a "TLAB refill"?

here someone is explaining the output of -XX:+PrintTLAB would make sense to me. On Mon, Nov 13, 2017 at 12:16 PM, Thomas Schatzl wrote: > Hi, > > On Mon, 2017-11-13 at 11:12 -0800, Ron Reynolds wrote: > > sorry for the n00b or repeat question (if there is a good way to > > s

"--" at the beginning of a end-collection line and best region count when it's not 2048

-- 59G->59G(59G), 2.0932801 secs] ^^ this "--" is entirely undocumented as far as i can tell; i believe it indicates that the young collection (or any collection?) was cancelled (i've always seen these in the last-ditch-attempt young-collections before a full-GC). is that correct? also the variou

Re: "--" at the beginning of a end-collection line and best region count when it's not 2048

Thomas Schatzl wrote: > Hi, > > On Thu, 2017-11-16 at 09:15 -0800, Ron Reynolds wrote: > > -- 59G->59G(59G), 2.0932801 secs] > > ^^ this "--" is entirely undocumented as far as i can tell; i believe > > it indicates that the young collection (or any colle

Re: "--" at the beginning of a end-collection line and best region count when it's not 2048

(do you really think it needs to be 512M? that appears to be the default max possible value...) On Thu, Nov 16, 2017 at 3:12 PM, Thomas Schatzl wrote: > Hi, > > On Thu, 2017-11-16 at 14:08 -0800, Ron Reynolds wrote: > > JVM - Java HotSpot(TM) 64-Bit Server VM (25.131-b11) for

young-collections are too infrequent?

increasing the max-pause-time from 100ms to 200ms has certainly made our young-collections less frequent (before they were about every 5-10 seconds; now they're 30-60+ seconds apart). unfortunately our Full-GC woes continue. one thing i noticed is that once the JVM is warmed up only humongous-all

Shenandoah GC

someone at work just mentioned this new GC; i believe available only in Open-JDK JVM and only if explicitly included. (?) i've just started doing research on it (the only source of which seems to be https://wiki.openjdk.java.net/display/shenandoah/Main) but it sounds like a replacement for G1. ha

gc-log is within STW event?

this blog https://engineering.linkedin.com/blog/2016/02/eliminating-large-jvm-gc-pauses-caused-by-background-io-traffic raises the question i my mind - why would logging to gc-log be done during a STW event at all? wouldn't it make sense to defer gc-logging to after the STW event? i suppose writi

Re: -Xms and -Xmx

the point of setting start and max heap sizes to the same value is to avoid the cost of having to increase the heap size at runtime in those cases where you are fairly sure you will need all the heap (i.e., server environments). the disadvantages of setting them is that you might be reserving more

Full-GC class-histogram generation time

going thru a gc-log of a box that had several Full-GCs (OpenJDK 64-Bit Server VM (11.0.3+7-201905271830) on CentOS 6.9 with 20 cores and 132GB) and i came across some really surprising times for the output from -Xlog:gc*=info,gc+classhisto*=trace: (notice the timestamps) [2020-02-29T*02:39:42.403

Re: Young G1 GC Notification

i use this exact mechanism and it works well. the only difference between my code and yours (that i can see, for the most part) is the call to emitter.addNotificationListener(receiver, filter, bean); in my case filter is also null but the hand-back is the bean itself (so it could be written as em