Community
Participate
Working Groups
Build 3.5M2 Follow-up of bug 247292, for field specific scenario. This issue has existed since day 1. The code generation relies on a field binding to tell its constant pool declaring class. This forces the compiler to instantiate a new binding each time the receiver type must be used instead of the target field declaring class.
Once this is under control: SourceTypeBinding#RECEIVER_TYPE_EMUL should be discarded and SourceTypeBinding#MAX_SYNTHETICS reduced by one.
Also should discard corresponding #codegenBinding slots
Will also take care of issue raised in bug 128563#c10 given the new support (see InnerEmulationTest#test157)
Created attachment 113015 [details] In progress state non functional patch
Created attachment 113351 [details] More advanced patch
Created attachment 113390 [details] Improved patch
Created attachment 113439 [details] Improved patch 2
Created attachment 113465 [details] Improved patch 3 still having issues in eval support
Created attachment 113490 [details] Proposed patch
Created attachment 113530 [details] Better patch Final version, also takes care of #fieldStore(...)
Note to verifiers: it will be hard to assess this bug, since it is a rewrite of an existing functionality. Need to check source code, for the absence of SourceTypeBinding.getUpdateFieldBinding(...) to check we are no longer constructing these bindings. Numbers from a performance run should also demonstrate the win. Released for 3.5M3
re: comment 3 Issue got forked into bug 249107
Verified for 3.5M3 using I20081026-2000 build.