I am profiling an application suddenly using a lot of memory, and i am getting this:
sun.java2d.loops.ProcessPath$Point
As being allocated almost 11.000.000 times.
What is it, and is there a solution to this?
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I am profiling an application suddenly using a lot of memory, and i am getting this:
sun.java2d.loops.ProcessPath$Point
As being allocated almost 11.000.000 times.
What is it, and is there a solution to this?
My initial response would be to question whether this is actually using a lot of memory/CPU cycles? The
sun.packages are internal implementations of Sun’s JVM, so they’re likely to be low-level details of what your code is doing. If these objects are taking up a vast amount of memory that might be an issue, but simply seeing 11 million allocations is no indication that anything is out of the ordinary.Edit: a little Googling seems to show that this is an object used to encode a reference to a particular point on a 2D plane. Chances are that if you’re doing anything that involves graphics then yes, you’d have a large amount of them generated. Additionally, each one only stores two integers (x and y coordinates) and a boolean, so they are going to be very small objects in the grand scheme of things. Even if if none of those 11 million allocations were garbage collected (and I expect the majority will have been local variables so will have been quickly collected), then they’re not going to account for a large part of the heap unless you’re running on devices with tiny amounts of RAM.
In other words, look elsewhere for your problem. It would probably be more helpful to look at objects that are taking up a large amount of the current heap space, or even look at the number of objects currently referenced, in order to find your leak. Read documents giving guidelines on how to find and quash memory leaks with your tool(s) of choice. Looking at total allocations is rarely that useful, unless you know for a given class how many there should be (e.g. it can be good to check that singletons are only created once, for example).