Rana, thank you for collecting it all together in one list!
I think 2 more optimizations should find themselves in the list as separate items, because they are easily formulated and are a good chance for performance gains that Jitrino.OPT can offer: + "Type Value Profiling" in Jitrino.OPT - Implement profiling the most probable caller's type for virtual and interface calls. Integrate with Jitrino high-level devirtualizer and the "interface call devirtualization" item. + "Loop versioning" optimization in Jitrino.OPT - Implement versioning of hot loops to allow as little exceptions (especially bounds checks) as possible in these loops. Integrate with "ABCD improvements" item. Rana, Mikhail, do you like them as separate? On the 0x205 day of Apache Harmony Rana Dasgupta wrote: > Hi Gregory, > It is a good idea to put up a live list, thanks. Here are some > suggestions on the contents for development items in the VM/JIT. A few may > be almost done. We can fine tune...and add other work items as well > > JIT Items > ====== > - GC related: WB support in Jitrino.opt > > Implement support of write barriers in the Jitrino.opt compiler. Write > barriers are required to implement a generational GC. Currently WB are > supported in Jitrino.JET only. > > - JIT: HLO improvements in Jitrino > > A set of performance-oriented improvements: > > - Reduce overhead from Back Branch Polling - remove BBP from finite > loops or reduce overhead if loop finiteness is undetermined. > > - Implement interface call devirtualization - based either on > heuristics or on the edge profile or on the value profile. The latter > requires implementation of the value profile. > > - Array Bounds Check Elimination - need to fix current ABCD algorithm and > implement a new range check elimination optimization > > - Loop unrolling - Improve loop unrolling and the code produced after this > optimization. > > > - JIT: New optimizations in Jitrino high-level optimizer. > > The Escape Analysis (EA) algorithm prototype is in Jitrino code. > The following new optimizations could use EA information: > > - EA-based scalar replacement > - EA-based on-stack allocation > > - Improvement of calling conventions. > > Currently the IA-32 and Intel-64 CG uses calling conventions that pass all > > parameters on stack. Also, all used calling conventions require returning > FP values in x87 register stack and do not support callee-saved SSE > registers while all FP arithmetic is done using SSE/SSE2. > > Although aggressive inlining reduces the overhead performance can > be improved in the following directions: > - Passing arguments in GP and SSE registers > - SSE-friendly calling conventions. > - Pluggable calling conventions. > > Calling convention improvements require changes in all JITs and VM core. > > - Branch optimization in IA32/Intel 64 CG. > > Analysis of the code generated by Jitrino on IA32 show that many > unnecessary branches could be eliminated. > > - Register allocation improvements and tuning. > > Currently there are 2 global register allocators in Jitrino: > bin-packing and color graph. Further improvement of register > allocation could be done in the following directions: > > - Profile-guided live-range splitting in the register allocators. > - Tuning and enhancing the color graph RA. > - Implementation of new register allocation schemes. > > - IA-64 enabling. > > Jitrino.opt contains an IA-64 code generator but the rest of the system > does not support this platform. Also, the Jitrino.opt code generator needs > more platform-specific optimizations and tuning. > > - X87 based floating point math. > > Currently all FP operations in Jitrino are implemented using SSE/SSE2 > except for the calling conventions which use x87 and a few other minor > exceptions in Jitrino.opt to be fixed. > > If a processor does not support these technologies the system behavior > is undefined. > > - Jitrino front-end re-factoring (BC translator, HLO info, etc.) > > Re-factor Java bytecode translator in the Jitrino.opt to make the code > clearer and simplify the used data structures. > Improve HLO framework (SSA on-demand, cleanup on-demand etc.) > > - DPGO: Bytecode-based edge profiling > > Currently edge profile information in the Jitrino.opt is mapped to the > Internal Representation (IR) which makes profile sensitive to the IR > transformations. Mapping profile (or IR) to the bytecode will remove such > dependency. Then possibility to unify the IR-bytecode mapping used for > profiling and JVMTI support should be also considered. > > > Core VM > ======= > > - bytecode verifier: > Develop subroutine Verification > > - JNI: > JNI Weak References development > > Globalization: These are community tasks ( geir ) but not important for > product > - Develop VM locale support > - Unicode support for Java classes/method/field name > > > - Thread Manager: > Develop synchronization protocol for JVM > Implement of synchronization and other basic helpers for IPF > remove "non system locks" > > - Stack : Complete overflow handling support for Java and native code > > - Tool Interface: > Profiling implementation, in particular Heap iteration, in JIT mode > > - Garbage Collection: > The work in the garbage collection area is new gc_v5 functionality, and > bug fixing and removal of performance bottlenecks( SpecJBB2005 ) in GCV4.1. > The work on GC_v5 include: > Generational GC with WB support > LOS support > Parallelization Support > Debugging and verification framework > Weak Reference and Finalizer Support > > ( Xiao Feng?) > > - MMTk integration: > Support for magic classes in Jitrino > VM/JIT support for MMTk collectors including RSE and thread suspension > > ( Weldon, could you please add details?) > > Thanks > > > > > > > > > > > > > > > > > > On 10/16/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > > > > > Once it's more or less ready let's point to that page from TODO on our > > > website > > > > > > Thanks, > > > Mikhail > > > > > > 2006/10/17, Gregory Shimansky <[EMAIL PROTECTED]>: > > > > Hello > > > > > > > > You know that drlvm was donated by Intel and there was some period of > > > time > > > > while drlvm was developed internally. We had an internal bugzilla > > > server to > > > > track the issues. In an effort to move all development to the open > > > this > > > > internal bugzilla will be closed. > > > > > > > > The database is quite big and contains a lot of valuable information > > > including > > > > still open bugs. There are many of them which are not exactly bug > > > reports, > > > > but requests for enhancements or limitation problems. These small > > > issues > > > > didn't make it to README because they are mostly minor and low > > > priority, but > > > > it is better to use information which we have already than rediscover > > > these > > > > problems again. > > > > > > > > So not to create a lot of garbage in JIRA like problem requests > > > without > > > > patches I think it is better to create something like a TODO list for > > > drlvm. > > > > Not exactly bugs, but more like known limitations list. > > > > > > > > To give you an example, vm/vmcore/src/init/properties.cpp contains a > > > #define > > > > MAX_PROP_LINE 5120 which is a maximum property length specified in > > > > vm.properties file. I am not even sure if this file still used, > > > probably not, > > > > but a buffer length limitation is still a bad thing. > > > > > > > > I think a good place for such list would be on wiki. I am going to > > > create a > > > > page for it so that everyone who has open bugs inside of Intel could > > > add a > > > > line or two describing a problem recorded in bugzilla. I have 3 like > > > these > > > > filed myself including the one I gave as an example. > > > > > > > > I don't know the number of such bugs overall, maybe it is not so big. > > > But > > > > before creating JIRAs for them I think it is better to collect a list > > > on > > > > wiki. What do you think? > > > > > > > > -- > > > > Gregory Shimansky, Intel Middleware Products Division > > > > > > > > > -- Egor Pasko, Intel Managed Runtime Division --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
