-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Potential ThreadLocalMap.Entry accumulation in JoinPointImpl #302
Comments
|
Just as what I mentioned in code comments, ThreadLocalMap.Entry is WeakReference. When the JoinPointImpl object is collected by GC, the Entry object is still remain. If the adviced method were called frequently, it would result in accumulation of a lot of Entry object. In our own application, we found tens of thousands of Entry per Thread, which were almostly from JoinPointImpl.arcIndex. The life cycle of |
Sorry, I am working on something else at the moment, I am too busy to immerse myself into the details here at the moment. Please be more specific and suggest code changes. As for those weak references, should they not be collected as well after the join point impl was collected? Edit: Please, post screenshots inline, not as zip files. I just fixed that in your comment. |
The problem with releasing the thread-locals is that a live thread could in principle defer proceeding indefinitely or not proceed at all. AspectJ has no way of knowing. Maybe there is a way to at least remove the thread-locals in cases where the last proceed has happened already, i.e. the index is back down to zero. I have not inspected the code yet, I am totally out of context at the moment. |
Avoid potential ThreadLocalMap.Entry accumulation. Entry is a WeakReference. When JoinPointImpl objects are collected by GC, Entry instances are still be referenced by ThreadLocalMap, which leads to memory pressure and potentially more full GCs. So, we proactively remove ThreadLocal<Integer> arcIndex instances when arcIndex has been decremented back to -1 per thread. This is not perfect, because not each thread can be expected to proceed, but it should ameliorate the situation to some degree. Fixes eclipse-aspectj#302. Co-authored-by: Alexander Kriegisch <[email protected]> Signed-off-by: KimmingLau <[email protected]> Signed-off-by: Alexander Kriegisch <[email protected]>
Avoid potential ThreadLocalMap.Entry accumulation. Entry is a WeakReference. When JoinPointImpl objects are collected by GC, Entry instances are still be referenced by ThreadLocalMap, which leads to memory pressure and potentially more full GCs. So, we proactively remove ThreadLocal<Integer> arcIndex instances when arcIndex has been decremented back to -1 per thread. This is not perfect, because not each thread can be expected to proceed, but it should ameliorate the situation to some degree. Fixes eclipse-aspectj#302. Co-authored-by: Alexander Kriegisch <[email protected]> Signed-off-by: KimmingLau <[email protected]> Signed-off-by: Alexander Kriegisch <[email protected]>
Relates to eclipse-aspectj#302. Signed-off-by: Alexander Kriegisch <[email protected]>
Avoid potential ThreadLocalMap.Entry accumulation. Entry is a WeakReference. When JoinPointImpl objects are collected by GC, Entry instances are still be referenced by ThreadLocalMap, which leads to memory pressure and potentially more full GCs. So, we proactively remove ThreadLocal<Integer> arcIndex instances when arcIndex has been decremented back to -1 per thread. This is not perfect, because not each thread can be expected to proceed, but it should ameliorate the situation to some degree. Fixes eclipse-aspectj#302. Co-authored-by: Alexander Kriegisch <[email protected]> Signed-off-by: KimmingLau <[email protected]> Signed-off-by: Alexander Kriegisch <[email protected]>
Relates to #302. Signed-off-by: Alexander Kriegisch <[email protected]>
Avoid potential ThreadLocalMap.Entry accumulation. Entry is a WeakReference. When JoinPointImpl objects are collected by GC, Entry instances are still be referenced by ThreadLocalMap, which leads to memory pressure and potentially more full GCs. So, we proactively remove ThreadLocal<Integer> arcIndex instances when arcIndex has been decremented back to -1 per thread. This is not perfect, because not each thread can be expected to proceed, but it should ameliorate the situation to some degree. Fixes #302. Co-authored-by: Alexander Kriegisch <[email protected]> Signed-off-by: KimmingLau <[email protected]> Signed-off-by: Alexander Kriegisch <[email protected]>
Our application is trying to upgrade aspectjweaver from 1.9.5 to 1.9.21.2 recently. But after upgradtion we found that memory usage in the old generation grows faster and FGC became more frequently, by the way we use jdk 1.8 and CMS+ParNew.
So we had made a heapdump and then found that the size of ThreadLocalMap in our application thread was much larger than before. And I've figured out that the value of growing entry in ThreadLocalMap is from field org.aspectj.runtime.reflect.JoinPointImpl#arcIndex. That's why I tried to review change histroy in JoinPointImpl and issue the following comments 43df701#r140486566
Sorry for that I cannot provide more information about problem from which our application is suffering, such as monitor graph or heapdump file. I am trying to make a reproducer.
The text was updated successfully, but these errors were encountered: