On 11/27/2013 02:40 PM, David Chase wrote:
On 2013-11-27, at 6:53 AM, Peter Levart <peter.lev...@gmail.com> wrote:
Ah, I have misunderstood the back-porting issue. It was not about not having
new class but about which existing class to use as a host that might not exist
in older version of platform...
Sorry for noise.
Noise is okay. This fix was a PITA, init order can hide surprises, and I don't
mind going over the details.
As to the activation of the code in question, practically never, except in tests or when
bozo-bytecode-generators (a remark I resemble) are making mistakes. The
"initialize" of the throwIAE method is deferred until loading of a class that
performs an illegal-access-override of an interface method -- e.g., interface I { int
m(); } class C implements I { private int m(); } so even that requires an inconsistent
set of classes, which is
unlikely in any normal initialization.
Longer-term/hoped-for plan is to create a custom throwIAE method each time this happens
so that an informative error message can be included -- "C.m() overrides I.m() but
is private" (or protected, or package-inaccessible) -- but that is tricky because we
don't have a good place to put the method; by the time we learn this about class C, we
have rewritten its constant pool and it is difficult to add more, and the constant pool
cache is fragile-yet-critical-to-interpreter-performance. So for now, I did this.
I did test it as much as I could figure out how, including running the
regression test in Netbeans and poking around, and also running it under jdb on
some embedded platforms and trying to think of commands that might trigger
embarrassing failures.
The push is in the pipeline, but if you have other tests you can suggest, it is
not too late to pull the emergency stop (in particular, I am gatekeeper for
hs-comp this month, so I can put off the next turn of the crank till the last
moment).
David
Your and David Holmes' answers have pretty much silenced me. I can't
think of any more troubles...
About creating an informative error message: is there a way to
dynamically dig-out from the VM, while executing the single system-wide
throwIAE method, the symbolic invocation attributes of a call-site
together with the target object in case of instance method invocation?
From that data it could be possible to re-compute the context in
question, I assume...
Regards, Peter
