On 8/20/14, 6:45 PM, Daniel D. Daugherty wrote:
On 8/20/14 2:01 PM, Coleen Phillimore wrote:
On 8/20/14, 3:49 PM, serguei.spit...@oracle.com wrote:
If an EMCP method is not running, should we save it on a previous
version list anyway so that we can make it obsolete if it's
redefined and made obsolete?
I hope, Dan will catch me if I'm wrong...
I think, we should not.
An EMCP method can not be made obsolete if it is not running.
It should be this way otherwise we'd have to hang onto things forever.
An EMCP method should only be made obsolete if a RedefineClasses() or
RetransformClasses() operation made it so. We should not be leveraging
off the obsolete-ness attribute to solve a life-cycle problem.
Yes, this was my error in the change. This is why I made things
obsolete if they were not running. I think I can't reuse this flag. My
latest changes add a new explicit flag (which we have space for in Method*).
In the pre-PGR world, we could trust GC to make a completely unused
EMCP method collectible and eventually our weak reference would go
away. Just because an EMCP method is not on a stack does not mean
that it is not used so we need a different way to determine whether
it is OK to no longer track an EMCP method.
Our on_stack marking is supposed to look at all the places where GC used
to look so I think we can use on_stack to track the lifecycle of EMCP
methods. If the EMCP method is somewhere, we will find it!
I'm running tests on the latest change, but am also waiting for
confirmation from Roland because we were only cleaning out MethodData
for EMCP methods and not for running obsolete methods and I think we
need to do that for obsolete methods also, which my change does now. I
think it was a bug.
Thanks Dan for remembering all of this for me!
Coleen
BTW, I'm reviewing the webrev too, but probably it'd be better to
switch to updated webrev after it is ready.
Yes, this is a good idea. I figured out why I made emcp methods
obsolete, and I'm fixing that as well as Dan's comments. Thanks!
Cool! I'm looking forward to the next review.
Dan
Coleen
Thanks,
Serguei
