Hi,
> > You're talking about 8392345 which omits filler objects from -live dumps? I > figured that was fairly clear-cut, since these are not reachable objects > (it's unfortunate that the docs conflate performing a full gc with removing > unreachable objects, but several parts of the doc are clear that only > reachable objects are expected in a live dump). Presumably just using -all > isn't enough for you, since you want to see how it looks after compaction? > You can still get close by triggering a full gc and then taking a -all dump. I believe what you’re seeing is that these fillers are put in the heap dump to fill in gaps in plabs just as they would be used as tlabs. I would expect to see them in the -live heap dump. > > 'to address a bug in MAT' - it's not just MAT, it's a fundamental information > loss that the filler arrays are not directly identifiable as such. Other > tools like Java Object Layout (JOL) have the same problem (worse in some > ways. Tools like that understandably don't consider reachability, so filler > arrays in 'live' dumps can be even more confusing than in MAT, where at least > they're marked unreachable and researching 'unreachable int arrays' might > give you some clues). > > For the wider problem: > > Can we make filler arrays identifiable in heap dumps? We've discussed > proposals, I don't love any of them but some might be workable. I'm not > currently planning on taking that further unless a clear consensus emerges. I > may at least zero the arrays to reduce confusion (users can otherwise be > tempted to try to figure out the source of the int arrays from their > mysterious contents), avoid data leakage and improve compressibility. > I maintain that filler objects do not fit in the current definition of a heap > dump, but I accept they have value, and if we can limit their negative impact > (primarily confusion) then I don't mind the conceptual impurity. I think I’d call this a dilemma. Choices are, replace int[] with something more identifiable or filter it out. In my opinion, filtering filler out the less desirable option because it eliminates possible analytics (it certainly eliminates mine). Replacing filler int[] minimizes the corruption/bias being introduced into the data being collected. We were discussing replacement with a more identifiable marker. I didn’t see any objections to this so this is why I was surprised but the PR. I wouldn’t class it as conceptual impurity, it’s more then it a suggestion that better represents purpose. That said, I think I’ve stated my POV and if the con > Should we extend the format (explicitly, with new types, or implicitly with > synthetic instances like 'G1RegionInfo'), or indeed create a new format, to > better serve observability needs? More VM internal details would certainly be > useful in some cases. Actual object layout, region boundaries, object age, > TLABs etc., would all be valuable, and we could directly encode the waste > that filler indirectly points to. Using current heap dumps to understand heap > layout is even worse with Valhalla and flat representations, perhaps it's a > good time to improve things. I would start from the use-cases > (HeapDumpOnOutOfMemoryError - I want to know why I OOMed, I want to > understand some particular occupancy metric, I want to reduce footprint, ...). There are a lot of great ideas in there and I do think we do need to extend the current format. I can add to your list, there isn’t anything to sort out if compact headers are being used or not unless some tooling has made a call to drag command line options into the heap. And I wish I’d had some of the other details that you’ve listed as there are a number of useful analytics that could be performed. For example, identification of transients/(zombies). We were discussing replacement with a more identifiable marker. I didn’t see any objections to this so this is why I was surprised by this PR. I wouldn’t class it as conceptual impurity, as it’s a name change to something that better represents purpose. That said, I think I’ve stated my POV and if the consensus it filter then so be it. Kind regards, Kirk
smime.p7s
Description: S/MIME cryptographic signature
