[Nestmates] RFR: 8189163: [Nestmates] Updated invokeInterface selection/resolution rules
tobias.hartmann at oracle.com
Thu Mar 8 09:22:52 UTC 2018
On 08.03.2018 09:53, David Holmes wrote:
>> Just wondering, the change in dependencies.cpp wasn't necessary for functionality/correctness but is
>> just an optimization, right?
> No it's necessary. Without it we get an assertion failure:
> # Internal Error
> pid=17815, tid=17868
> # assert(counter_changed) failed: failed dependencies, but counter didn't change
> My thinking was that the is_witness check found the private method and considered it an indicator of
> a failed dependency (which it isn't), but no changes had occurred that should have invalidated the
> dependencies, hence the assertion failed.
Yes, the assert indicates that an assumption (probably DepType::unique_concrete_method?) that did
hold during compilation does not hold anymore after the compilation although the system dictionary
modification counter didn't change.
But since the original assumption is also based on CHA (and should therefore also consider private
methods), I wonder why that only fails after compilation.
Do you have a regression test for that? And if so, does this reproduce without nestmates?
More information about the valhalla-dev