Aleksey,
Sorry for not being clear earlier, but I am a bit concerned with the bug synopsis: we have sure worked around the issue with LambdaForms, but are we sure this fixed the general problem? John asked me to follow up on that with more concrete benchmark, and I will do that later. In other words, I would like to see the separate issue submitted for this workaround, and record the fix under that issue.
It depends on what do you mean by general problem here.
I don't see anything obviously wrong either with U.dAC() or with dependency tracking in VM. What we stumbled upon is an inherent limitation of current dependency tracking implementation.
It's not specific to U.dAC(). Regular class loaders can hit similar problem as well.
With compiled LFs we ended up in relatively polluted context. Considering how many classes we spin for LFs, validating this context over and over again takes considerable amount of time.
The question is how common polluted contexts are and how frequently do we need to validate them.
We could think of improving dependency tracking in VM by increasing granularity and narrowing contexts, thus making polluted contexts less likely.
If you want to use 8058309 for dependency tracking improvments in VM, let me know. So far, I got an impression it is about LFs & JSR292 mostly.
Best regards, Vladimir Ivanov _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
