<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Mar 28, 2012, at 7:50 PM, David Holmes wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">One query I have is whether, given its intended usage, this change might add pressure to the reference processing subsystem?<br></span></blockquote></div><br><div>Not undue pressure, I hope. JSR 292 applications tend to converge rapidly on the number of distinct MethodTypes they use. After this the MethodType intern table will be stable and its entries will not need reference queue processing.</div><div><br></div><div>The main exception to this generalization (which the current patch addresses) is that some applications load wads of code via class loaders and then throw the class loaders away. This will cause various kinds of churn in the JVM internals, leading to whole classes (etc.) being garbage collected. In that case, the MethodType table needs to "keep up" with the rest of the churn, and not cause a storage leak. I don't see how it can add a significant new overhead. The reclamation of the classes themselves is a far bigger job.</div><div><br></div><div>Thanks,</div><div>— John</div></body></html>