Solving Java Memory Leaks

yeah thanks for coming in this morning it's yíall doug has been having fun code one what do you think of the event so far they're happy sorry it's about to get a lot better oh right okay yeah soon as I leave the building yes it's yeah definitely the quality is gonna go skyrocketing right right so here to talk about Java and memory leaks so I'm just going to test arms everybody's arms working hands up who's not who's had it in memory leak it's like yeah right who maybe the better question is that the passive question is who hasn't experienced a memory leak in it at any time point in time right if they haven't they sir they haven't oh right exactly and they haven't they yes I'm mmm yeah sorry to inform you you are suffering from a memory leak so anyways I just wanted to do like this like short 45 minutes so I'll go burning through stuff it's a condensation of a four hour workshop that I do on the subject so you can get an idea what's going on probably won't be as in-depth as the four hours but hopefully we will get to this button is kind of going weird I was hitting it yesterday it was like always double forwarding about me so that's about me slide stuff co-founded J clarity and you might notice the Microsoft and Azura thing over there that's because three or even 19th of August we were org so now I'm actually principal engineer part of the Java platform group within Microsoft so we're planning on having fun digging around in in the internals of the JVM to make you know life better for everybody and particularly those people are using the azure cloud and also we'd like to talk about jaikrit because as we say it's the hottest unconference on the planet right and it's heaven in July right so memory leak chronic condition which an application retains a growing amount of memory that is never accessed and is never free so we have data in memory that's not no longer semantically useful to the application and it's just hanging around just like consuming memory and and causing all kinds of havoc so let's just start the story by saying you know this is typically what a process in in memory looks like seeing as textarea data hairy area shared memory stack place for systems heap you know so and and then we have this thing called I'll just call it C heap and this is really known as like unmanaged memory well we have mem managed memory so we had to have a term for this other part with so we just call it like native heap or unmanaged memory then when you get that set that like - X MX or minus MX setting what happens is that when you start your java application it takes that parameter says I'm going to reserve that much memory as a malloc in how to C heap and we're gonna create this other data structure which we're going to call Java heap and that's where we're gonna do a lot of our work so this is where what known as manage memory and this is a part of memory that we're actually gonna focus on in this particular talk so be aware that we can leak you know just about everywhere in the gray area but we're really going to only focus on parts of the green area here so manage leaks is commonly known as memory leak and so as I said data is semantically not useful and it remains lies so can never be recovered right symptoms occupancy if heap grows over time and that affects the thing that tries to clean it up which we commonly call the garbage collector and when we get into this condition where all of heap is consumed then basically we try to do an allocation in that space we get this fatal out of memory are being throwing our JVM terminates and that can sometimes have detrimental effects on the performance of your application right on rare occasions we actually do get this thing like in out of memory air happening and a single thread and the JVM will survive it's like okay that's kind of weird what's going on there so what happens is that you know the you'll try to allocate and you get at the allocation failure the garbage collector will run and then we'll retry the allocation and we'll do it again and then the garbage collector run again then we'll try again and if you fail at that point then what happens is the thread dies the allocation pressure goes off of the heap and all sudden maybe there's enough room in heap for all of the other threads to survive and continue working and stuff like that so we've actually used that as as a diagnostic and finding strangely enough concurrency bugs in the JVM so you can get to some weird places when this happens common fallacies running the garbage collectors several times will just free the amount of memory that we need and we're gonna dive into that very deeply to see why that's not true you know failure free memory is often blamed on the garbage collector it's not working for some reason and you can configure the garbage collector just solved the problem well you sort of can there is a trick to do it the traders often do this so they don't want garbage collection to run during the day so what they do is they say okay I can allocate I don't know 40 terabytes of data today so I can just make my heap 40 terabytes in size and you know and just basically let it leak until we shut it down at night and you know so larger heaps in that case will solve the problem but you know generally you know if you're running 24/7 that's not what you want to do so I have this like overly simplified view of heap in the longer version we just actually go and as to how you actually build this thing but you can see I got a piece of code here I'm going to execute it and I'm gonna get a stack frame and in the stack frame and a hold primitive values of which pointers are the primitive values as well as you know there's an INT in there so it's like another primitive value and and you can see we got like these you know data allocated off in heap we got this other space called meta space and meta space holds the definitions you know so it's a like a map that says what the memory actually is and what it looks like so we you know so that we can decode it while we're using it so you're gonna have some headers in there and the headers are gonna point to the instances and this is gonna point to headers so there's all this like you know spaghetti soup going on inside here right so we do tend to break the pointers down into two different classes of pointers one we're gonna call internal pointers so with internal point is what we see is that the source and the desk of the pointer is within the blue square that's going to be our Java heap space and you can see in this case we have a number of different internal pointers in here we also you know if you couldn't guess from internal pointers we have this term called external pointers and as you can see the difference here really is that where's the source in this case the source is outside of the memory pool that we're that we want to collect right so when we actually go into a garbage collection cycle the first thing we want to do is we want to find all of the things that are live by definition so live by definition is anything that's outside of the memory space that's pointing into the memory space so the first thing you have to do is we have to find these things and that's known as a scan for routes as you've probably already aware so what I'm going to do is I'm going to go to all these different memory spaces like stack frames meta space code cache other memory pools you know the list goes on of places where we're going to look and we're just gonna scan these things and we're gonna build this route set so you can see what we're essentially doing is we're finding all of the external pointers and I'm just going to put them into a set and then I'm going to start working in through this algorithm which we called mark-sweep which means start from the roots trace down anything that is reachable by a pointer value like everything in this picture is going to be considered life right and then we're going to sweep either in place or evacuation or use some technique to basically at the end of the day clean up and return memory to your applications so that gives us some nice expression as application developers you have an infinite amount of memory right because that's what the view the garbage collector gives you and you can just allocate allocate allocate allocate and then the garbage collector is like your mom she just keeps coming cleaning up after you there you go oh I have some mums in the room that are saying no okay so you know so you know so some of the things we'd like to do is we'd like to monitor Java heap so we want to introduce some fundamental questions right is the heap stable over time and is it large enough to cope with the the amount of live data that we actually have and the other thing we actually want to look at is the allocation rate I did a talk yesterday where I talked about the effects of allocation rates on performance so if you're there yeah if you you you'll know all about that so the problem with the memory leak is that we're just going to inflate the like dataset size and the cost of the garbage collection is basically a function of the live data data set size in modern collectors meaning that what we're gonna see is we're gonna see increased GC overheads as we go on so I think I got a chart here later on that actually shows this so there are some tools that we can actually use the one we recommend is going to be just turn on GC logging collected GC logs we have some wonderful tools that we used to be able to give you but and we're in the process of hopefully being able to give them to you again to help you analyze these things yeah sort of a part of the onboarding of our IP and to Microsoft they are now deciding what to actually do with it so hopefully yeah that's a process onto its own that's another talk anyways so we prefer to use the GC login because it's basically an event-driven journal of everything that's happened and we can do all kinds of wonderful mouse on it to figure out what's going on right and barring that then you can just basically use things like JVM stat in the form of J command or J console or something like that to monitor what's going on a lot of the modern tools automatically hook into the stuff so they give you some basic information as what's going on so here is a heap occupancy after collection first question is the heap stable I'm going to draw a straight line across the bottom there and lift it up and say okay does that actually you know work in terms of does that look flat and the answer is yep so far so good right we can't prove what we can't see so but you know every so far everything looks so it looks okay right is Eve large enough well yeah looks good so far so you know that's a different type of analysis but you know it looks okay now if you compare that to this one you're gonna ask is EEP stable so I'm going to draw my string same straight line and say well it probably looks more like that so no we're losing about one gigabyte per day and more importantly if you like pop out into that region there it's like look what happened to the collections right as we started filling up the memory pools also in the garbage character has to start working harder and harder to give us this illusion of infinite amounts of memory until it finally says give up and pulls the curtain back and you can see the man behind it that's been lying to you okay sorry yes it is yeah the rebranding that I was told that I wasn't supposed to ask about rebranding for this conference so or the next one actually which is tomorrow but yeah we'll just ignore that for now right so maybe stabilize applications so this is really funny I just did in June a large application that was destabilized it's like don't do this anywhere the the vendor recommendation was that you run system GCS every two minutes yeah the results were not good but it was very easy engagement for me I looked really smart all I had to do is set a flag don't do that yeah so it managed systems very seems to be leaking so this is our sort of things right that we looked at before or maybe we didn't it's in the long the other ones in longer one sorry so you know I guess the thing is we're using a tracing collector so Java's garbage collection is tracing based and it's precise it's not reference counting like you'd see in some other runtimes should I mention PI you know Python there's something I got or it's not a precise collector or go where they have to do other things to make it sort of precise but the point is it's it's it's precise so anything that's not referenced it's gonna be collected it's found and collected so the unused data is so that means the unused data is referenced and either directly or indirectly from GC root which means that's a bug in our application code alright so what we want to do is we want to find that bug in our application code and fix code and you know hopefully the whole problem goes away that's the whole point of it right so you know we get into this you know let's find the data that's being referenced but is no longer needed right so typical causes so this is a friend of mine said oh when you when I was writing the workshop the first time you said you need to put in like all the typical causes and I said I know typical causes I think I've reduced the problem it's really not that hard right so these and I said okay well let's just list some of them but at the end of the day this is a condition you have there exists at least one pointer change from a GC root to a target to your - to your target that's what we're looking for okay so you know how can you find these things whoops probably should have got rid of this slide really what we want to do is we want to get some tooling that's going to give us visibility into what our heap actually looks like so I'm gonna give you this definition and we're gonna use this to see if we can help us compose a diagnostic process so we have object age its number of collections that an object has survived generation all objects of the same age okay generational count the number of different generations that we have for a given class okay pretty simple let's put that into practice here's some shapes I'll call it a shape you tell me the generational count right so I'll start with cloud since we're at a cloud event currently okay cloud I got a flight to catch so shout okay to perfect triangles okay half I'll say half circle normally I call her happy lips but I don't know I spent a lot of time in non-english speaking countries I don't know what any ellipse is one yes that's the tricky one a lot of people say four so we have it's in age for an hour at age four but there's only one of them okay and we can go do triangles stars for ya okay across it was like two anyways we can go through the whole thing I circle one normal cross for cached normal normal leak isn't that awesome that's a precise definition of a memory leak okay and not only that you you you get over these weird things where people like you know I had a nice long common I do Morais actually spend more time more billable hours talking to be people and convincing them of certain things that I actually do doing real work you know like the last one I did we spent 15 minutes diagnosing and turning off the full GC two days of discussions convincing them that they needed to do this for all their systems alright so and and then you just run in all these weird things so you had another one is like this cash we got this cashing product from a company and they said yeah they didn't have an eviction policy right if you look at it says oh your cash is leaking is that what your eviction policy looked like so oh we don't have one what's that going excellent you just bought yourself a memory leak alright and you go to the company they're going like well no that's not a memory leak that's how our cash works like okay let's go back to fundamentals here anyway so you see where it all goes anyway so you usually get two questions here to say okay the first is the obvious of why's it'll leak well you know I'm creating more of these I'm holding on to them and I'm if I just keep this particular behavior up then I'm gonna fill the heap with stars and then gonna run out I'm gonna run our memory because I'm just gonna have stars right so you know the analogy here is you know we're generally looking for the elephant in the room or the the stars in the heap or whatever you want to call it and the other one question I get if I had a longer talk I'd let you try to guess what it is but why is that cached and the thing is like thinking you're caching powders right there's generally like two ways we cache one is we put stuff in heap at the beginning and we just leave it there yeah class loaders might be an example right the other one is that we put stuff into a cache and then we evicted all right so that put into cache evict looks like a normal object life cycle just longer all right put in the beginning and use forever looks like the Haffey lipst right so that might be a leak we might not be using that anymore but it was only one or two I don't really care it's not worth my time to find them I want to find the stars cuz that's the one that's going to take us down but you know you see that the definition actually gives some distinction between caches and leaks which is why I'm very convinced that the star is a leak and not just some funky cash and going on okay right so that pretty much covers everything here so what we actually want to do and we'll do this at the end hopefully if we have time is we want a tool that we actually give us generational counts and J fluid which is the excuse me profiler within the netbeans profiler and you can take it out and use it in other places actually gives you the memory profiler will give you a generational count and what you'll find is that if I look at the generational counts and sort by generational counts the leaks will tend to have a generational count that's equal to the number of garbage collection cycles that you've had running which is makes it really nice and fun now it's netbeans I think is you'll find it and get to start and yeah I hope to show you at the end I don't have a clock up because I didn't do the mirroring right 21 yeah we will have time okay hey I'm memory leak Souls you know okay so yeah so we basically covered that so I'm not going to go there right so a memory leak triage right recipe we call these recipes at this point profile for generational counts make sure you have allocation sites profiling turned on when you do this then when you're confident you figured out what's leaking you trigger a heap dump and then once you've collected all this data then all you do is you just target the object that you know that that's leaking and you say what's the causal execution path to that allocation site and then it's now it's just a standard debug the logic figure out what's going on what the life cycle is and what you need to do to unhook it so that you you get rid of the leak right so this it's all pretty simple and should be able to do it in a few minutes now let's talk about what leaks typically look like right so I was liking this to like a gang right it's like the the bad gang in the neighborhood and there's always like the ringleader the thing that actually is responsible for everything coming together and it's got all these supporting actors and generally you find is like you know I saw you know it's like Glee King filled leaking field those are typically going to be like string string string string string string and probably for a variety string so you know so if you're looking for strings where are you going to find them yeah exactly don't look for as I say JDK classes don't leak generally I did got caught once where I had one leaking and an inconvenient time but anyways generally they don't point is that I want to look for the leaking object which is more than likely going to be a domain object it's going to be the quickest most efficient path into figuring out what's going on right because my domain objects are gonna have very minimal causal execution paths and generally there's only be one involved there's maybe one place in the code where I'm going to figure out what's going on and I'm probably gonna have to make one small change in the code in order to fix it I would say in one case I asked the client for one method from one class got the source code modified at centre-back to him said here try this you know that's all it really took like done like I said I spend more time convincing than I do actually doing real work okay so yeah focus there right that's the guy you want to look for or the object or whatever sorry yeah you know it's like you know you need collections they're gonna be involved so you look at structures collections there and and the leaking I'm just going to have fields so you know those are gonna come running along those are going to likely be strengths yeah exactly cool object profiling headaches and what a surprise memory profiling can be expensive actually just say is expensive sometimes not suitable for production environments and may be difficult to use in test environments so you're gonna take quite a hit unless you use some really interesting techniques that most profilers don't use memory profiling distorts the allocators not quite true for flight recorder but then the quality of information you get from what flight recorder isn't what you get from other profilers just because of how it actually works right so we get the so the if you saw my demo yesterday when I found the hot allocation site it turns out that it wasn't really a problem because the optimizer is optimized it away so if you basically changed the code there then you know yeah so there's there's some problems there so generally we don't have to worry too much about it when we're doing memory leaks but you do have to worry about it when you're doing other type of memory profiling so the alternative technique is just just take a snapshot of the heap right but this is a single point in time like we have a problem of dynamics something is growing we want to watch the growth right if we get a single snapshot it's only what it looks like then which can make it a little more difficult to do the analysis but we do have a technique we can use and this is called a using Dominator trees right so if you look at this particular graph here you can see I got some green red black gray things like seif consider this to be an object graph right the dominating object in this graph is gonna be the red one you know it seems we get this the center of attention in this paved case right so it's any object you Nanaji graft that must be passed through to reach any other object and in this case we get this as being a pinch point so what I want what I'm going to do is I'm going to calculate retain set size so basically I want to know the size of the set of black things that's an immediate Dominator and you know there's a Dominator tree the gray object may or may not be included it depends on the toolings interpretation of Dominator but it's part of the retain set size but it's not strictly reachable by a a single object so it's kind of cool cuz we get a heap dump what we can do is you just run a query over the heap dump that says find these sinks okay so guess what the number one top hit is going to be caches right that's exactly what a cache looks like so you can get a tenth you can tend to get a lot of false positives where as we're using generational counts I don't need to know anything about the domain like nothing I'd only need to look at source code are nothing all right so I give me the let me run it and we'll sort it out it in this case here you really have to go sorting through things and figure out okay what's happening here and then you also have the problem that maybe it is the cache that is leaking for bad eviction policy and stuff like that so it's a little trickier but it's still very effective and you can still find things so here acquire heap dump you can do it when you get out of memory years I'd suggest not waiting that long the current set of tools that we have don't really scale well to larger heaps so I've have been very slowly working on a tool that hopefully scale so I call it J hippo which you can get at the adopt project and helped me build it if you're interested so we're using neo4j as the back-end gives me something that should scale and they should give me gql as a standard query language for getting information out so after we get the heap time for gonna calculate Dominator trees and then we're gonna start looking for the elephant in other words who has the largest retain set retain set size how are you doing Oh 28 oh we're gonna have lots of time here that's excellent right okay cool so we have about 15 minutes for a demo I'll take questions now also alright any time just shut them out yes sir Absalon yeah isn't that fun well I've never thought of it actually being helpful to okay so for those who don't know what epsilon is epsilon is actually a no garbage collection option so there's no garbage collector in the JVM at all which is really kind of fun because really what you're saying is like I don't want to take the throughput hit if having to go through all the read barriers and things like write read write barriers and everything when I do stuff like mutate or move or just plain access and so if I don't have a garbage collector and I have to cooperate the garbage collector so I can take all that barrier load off all right so if you look at Zed GC you know sorry wrong country z GC but I look at z GC then the barrier hit is approximately 15% on your throughput right because Shannon doe the barrier hit is approximately 15% g1 it's approximately 10% and if you do a comparison to like like a parallel collector alright and CMS there's something like a probably about a 5% hit or something like that but if you go to epsilon then you're hit on throughput is like zero it's really nice right well compared to the parallel collector it's even faster than so I guess it's like a negative views parallels our baseline no because you'd still be creating temporary objects that would be normally garbage collected out so yeah it's an interesting thought but yeah since you are creating temps and there's no garbage collection running the temps are just going to consume memory and that's going to be it mm-hmm I like that idea that's that could be like a nice trick question hey yeah so if you're not allocating at all then I would say that's a good technique if you think like oh I'm doing zero allocations which some applications actually do we've worked on a number of occasions that have zero allocation rate so you do some initial setup and stuff and then bang you're done those go really fast oops okay so I have this wonderful application here which I call leaky I'll let you guess what it does and if I just run it you can see that basically so what I've done here is let's look at some of the source code why not yeah all right I'm giving away the goods here am i showing all the class names okay it doesn't matter so let's try leaky so basically what what you what you can see here is like let's just set better you can see that now right so I'm gonna do stuff and that's my heap occupancy afterwards all right so how am i monitoring that then we can actually just look at that and say yeah let's get rid of that we don't need that you can you can so there is some part of the serviceability architecture it does have some internal performance counters that you can actually look at to to get some stats out of the JVM and in this case here right you can see what I'm doing is from the menu manufacturing getting the memory MMX beans and from the memory MX beans I'm actually getting maybe it's easier to read this way yeah okay yeah I'm getting how you know the occupancy how much memory is actually in use and stuff like that and so we can just pop that up into our applications so every time we do stuff it's like yeah our heap occupancy goes up and when you we get this balloon thing happening or the beach ball then it's probably a garbage collection cycle running and everything like that okay so so you know so the question is like you know how can we use some of the tooling to figure out you know why this thing is leaking and actually which class is leaking if you can't figure that out by the names so III was such a visually in here I thought I'd doing flight recorder also but maybe 33 yeah if we get n Bish's so I'm gonna do a visual VM are we still running no we need to be running right no we are running okay so there's leaky there's leaky okay so now we are attached to leaky here and let me just have some fun with this there and yeah okay so we can see what's going on bit all right so there's our profiler RJ flew a profiler I'm gonna go to the memory settings and and and really what you want to do is any profiler you use make sure you check the filters and know how it works because the one thing you don't want to do is filter the bottleneck out of your profile all right and end up tricking yourself so in this case here I want I'm just gonna look for everything because I don't know what I'm looking for so I'm just gonna look for all classes all arrays attach the memory profiler get rid of settings and boom there we are look at that generations right over there so I can just sort of sort this whole thing by generations over this a little bit okay and Wow we have floats in there okay but you can see everything's about generation one that's quite normally you see that the vast majority of the classes are going to be I have a generational count of one so let's do stuff and oh wow okay generation no this is actually the generational count as I defined it like how many different generations of java.lang object array are there okay how many different generations of car array are there how many different generations of the whatever the next one is array dollar or a hashmap entry you might guess or something like that no this is actually part of the tool this is what Jay this is what Jay flew up do is it does it actually will calculate the generational count I mean you could do this yourself it requires a little trick with getting garbage Carson counters and playing with phantom references and fun things like that if you're interested and building your own but yeah that's pretty much what it does so anyways where are we do stuff again and really what we're seeing is that we're gonna end up with just to make this a bit smaller sorry for the back what you can see is that we sort of just like have this cliff effect here right you see that it goes like 11 oh no that's 6 1 12 5 and really what we're seeing is that okay these are all of the things remember say this is a gang right so where's where's the thing that we're interested in the gang sorry I have to just make it a bit bigger to make it a little bit more useable there's something funky going on here right and yeah so like where the domain classes well you know there's leaking class leaking field right so pretty much in this application we've identified that leaking class is leaking and probably some association with leaking field we can get the allocation stack traces right here which is really nice yeah that makes sense so that's the that's how I'm actually you know that's that's this is the that's the that's the allocation site right there the construct called the constructor the allocation site for the object array which is also leaking yeah so you know so let's go on to the next step and let's see if we can actually take a heap dump and this should load up into the heap dump rating heap dump wow that's coming along very quickly yeah sometimes getting the tools to cooperate can be challenging yeah getting customers to cooperate challenging tools even more challenging all right I mean who has that experience actually should ask who are customers first so yeah I know who I'm insulting here first okay okay so we can just look at this like okay what are the objects now we can just go through and we know what we're looking for it's that one there and so now here's all the instances of it so we can actually see what they look like here's our fields what a surprise leaking field is part of leaking class and we have these other things that are actually in there just to make things more massive so you can see pretty much it's really mechanical at this point in time as to what's going on so you know there's other things that we can actually do here in terms of figuring out oops sorry yeah it's like a bit of an annoyance with that one here so yeah anyways you get the idea so we have enough information here we can just we can start looking at dominators we can do a ket Dominator calculation right here we can find the GC roots which is like kind of neat and nice this is can sometimes take a bit hopefully as heap is not big enough okay that we can actually and where to go to all right well these are GC roots but we should be able to calculate here pass to GC roots right so let's leaking claw oh so this instance is again but those fields references sorry here it is right here my bad so now it's now it's on a path where it's computing what are the things that are referencing me so I can see the data structures that it's contained too and I can flip trace this all the way back to a GC root so that you know you really have a deep understanding of what's going on by the time you go back into the application so if we go back to the profiler here well it's calculating that we'd see there's our leaky leaky model so if we go back into the source code I'll make this as big as I possibly can you can see that leaky model is right here it's not I mean this is just kind of like like a silly things I'm just collecting these strings onto an ArrayList and stuff like that so rather contrived when you do it in bigger applications sometimes it does take a little time to sort of to wiggle through the logic but you know eventually you'll you'll get there all right so here it is so there's a little bit of a guide there to tell you what it is to help you understand what you're looking at oh sorry that's the that's the wrong one oh right excuse me yeah over here yeah so anyways we at this point in time we can just follow the words so that's we craft a so that's profiler artifacts so you do have to be careful that but you can see there's our leak here there's our model right and then we're in some sort of like hash map thing here and and anyways we can trace this all the way back to GC root and we get a good understanding the anatomy of what our heap looks like and you know probably have a really good understanding of what we need to do to fix this particular application okay and that says five minutes so I'm really happy to take questions now for the anyone has them yeah this is a visual VM you can get you can get similar types of information using other profilers I'm just using this one here because not for any particular reason I think so well visual viana is the only one J fluid and visual VM is the only profiler that actually gives you the generational counts none of the others will som advertise but they're lying to you they'll give you an they try to give you an equivalent but they don't actually will give you this level of detail you have to do snapshotting and stuff like that to figure out what's going on yes oh yeah oh yeah if you like statics you will leak right if you like giving like free wielding access to all of the variables inside your data and stuff like that you know like the getters are evil type thing you will leak theirs and there's just this open style of program where there's like little encapsulation and what I call little encapsulation of state behavior representation all that stuff we tend to find far more performance issues in that style of application than we do in anything that's written where well you know it I would just say that you know the rule of thumb has always been you know control state control control state internal state and minimize the visibility of every variable in your in your application right so fields are preferred if you can't use the field and of course the and then we'll accept sorry local variables are preferred if you can't use the local variable then yeah well okay we're okay with fields by the time you go to static if it's not final constant then you know you know forget it weird weird you've lost me at that point and yeah so that's it I think the other thing is like collections of collections as soon as you start doing that you're missing abstractions in your model and that's just a sign that you just have bad modeling and that tends to lead to leaks also because then you know it's just easy when you get collections the collections of collections just forget to unhook something and also you're just basically you know yeah boom right so there's those types of things that we find so better modeling leads to better performance localized variables leads to better performance you get better optimizations from the compiler there's less visibility so the compilers are able to do more it's just you know it's just an across-the-board win easier to reason fewer logic errors you know so it's not just a performance issue ok yes right so there's just a number of flags you can use to turn it on so I have a whole talk on unified logging you can probably look it up on speaker deck or SlideShare I think I've launched him both up there we in sense um I'll just start it up here and you can see how do I create a GC log file and you see basically these are the settings that we actually recommend for unified logging so it looks something like that for a JDK 8 then you end up using these things here

Channel: Oracle Developers

Views: 15,875

Keywords: groundbreakers, oracle cloud, oracle developers

Id: E2KYTXKUsT4

Length: 45min 5sec (2705 seconds)

Published: Thu Sep 19 2019