Re: [drlvm] A list of drlvm enhancements and limitations
I created an MMTk page off the DRLVM core VM development page and put in Weldon's list. On 10/23/06, Gregory Shimansky [EMAIL PROTECTED] wrote: Weldon, can you make a subpage to Rana's list and link it to the MMTK integration item?
Re: [drlvm] A list of drlvm enhancements and limitations
On 10/31/06, Rana Dasgupta [EMAIL PROTECTED] wrote: I created an MMTk page off the DRLVM core VM development page and put in Weldon's list. thank you many times! I tried to create the web page last week but the network and the servers conspired against me. On 10/23/06, Gregory Shimansky [EMAIL PROTECTED] wrote: Weldon, can you make a subpage to Rana's list and link it to the MMTK integration item? -- Weldon Washburn Intel Enterprise Solutions Software Division
Re: [drlvm] A list of drlvm enhancements and limitations
All, Just a few minutes ago I sent a mail titled, [DRLVM][MMTk] current status and plan. It is way too long and detailed to include in this list of drlvm enhancements. Below is a summary that hopefully is at the appropriate level of detail. Please refer to the above email for more information. Summary of MMTk projects 1) Move the exiting uswer-level MMTk port to GCV5 2) Get MMTk SemiSpace, GenMS and CopyMS collector running again. They were broken during migration to latest MMTk source and latest drlvm svn HEAD. 3) Alter DRLVM classloader to force all MMTk classes to be loaded and all methods to be JITed before any java code is executed. Integrate MMTk into an early stage of DRLVM boot. 4) Fix up MMTk/VM porting layer which is located at: drlvm/trunk/vm/MMTki/ext/vm/HarmonyDRLVM/org/apache/HarmonyDRLVM/mm/mmtk 5) Debug and verify JIT support for MMTk's Uninterruptible class. Run simple multithread app and debug. On 10/17/06, Rana Dasgupta [EMAIL PROTECTED] 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 - 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 -- Weldon Washburn Intel Middleware Products Division
Re: [drlvm] A list of drlvm enhancements and limitations
On Monday 23 October 2006 20:21 Weldon Washburn wrote: All, Just a few minutes ago I sent a mail titled, [DRLVM][MMTk] current status and plan. It is way too long and detailed to include in this list of drlvm enhancements. Below is a summary that hopefully is at the appropriate level of detail. Please refer to the above email for more information. Summary of MMTk projects 1) Move the exiting uswer-level MMTk port to GCV5 2) Get MMTk SemiSpace, GenMS and CopyMS collector running again. They were broken during migration to latest MMTk source and latest drlvm svn HEAD. 3) Alter DRLVM classloader to force all MMTk classes to be loaded and all methods to be JITed before any java code is executed. Integrate MMTk into an early stage of DRLVM boot. 4) Fix up MMTk/VM porting layer which is located at: drlvm/trunk/vm/MMTki/ext/vm/HarmonyDRLVM/org/apache/HarmonyDRLVM/mm/mmtk 5) Debug and verify JIT support for MMTk's Uninterruptible class. Run simple multithread app and debug. On 10/17/06, Rana Dasgupta [EMAIL PROTECTED] 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 - 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?) Weldon, can you make a subpage to Rana's list and link it to the MMTK integration item? -- Gregory Shimansky, Intel Middleware Products Division
RE: Re: [drlvm] A list of drlvm enhancements and limitations
For today my vision is: * DRLVM TODOs is broken into Core VM TODOs and JIT TODOs JIT TODOs are broken into For Beginners, Front End, Performance, etc. now implemented :) take a look done. Now it's TODO List for DRLVM. JIT dev tasks link moved there. Limitations enlisted there too. I hope, that's OK for all of us. Thank you for suggestions! Looks great! Good job! Congrats! :) Cheers, Sveta Konovalova -- 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] A list of drlvm enhancements and limitations
On the 0x207 day of Apache Harmony Rana Dasgupta wrote: Gregory had already created an entry on the front page ( see his comments above ). I expected to see JIT development tasks and DRLVM known issues and limitations (TODO list for DRLVM) somewhat unified in naming. Say, I prefer JIT development tasks and Core VM development tasks links near each other. Is it good for everyone so I could change it? On 19 Oct 2006 10:55:43 +0700, Egor Pasko [EMAIL PROTECTED] wrote: On the 0x207 day of Apache Harmony Rana Dasgupta wrote: I added the VM dev tasks to http://wiki.apache.org/harmony/CoreVmDevelopmentItems off Gregory's currently empty page. Please change as necessary. Why not from the front page? On 18 Oct 2006 20:11:14 +0700, Egor Pasko [EMAIL PROTECTED] wrote: now this is done: http://wiki.apache.org/harmony/JIT_Development_Tasks feel free to correct me. Front page is updated too. [snip] -- Egor Pasko, Intel Managed Runtime 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] -- 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]
Re: [drlvm] A list of drlvm enhancements and limitations
I don't really care about wording, I just wanted to make separate list for high level TODO items, like implementation of big pieces, and enhancements/limitations of the current code state. So I made a new link from the page which Rana used and put there my 3 items. If you think appropriate, you could insert your own link there too for JIT TODO items and rename this whole section to drlvm and JIT (if you think JIT is not a part of DRLVM) to include both. Does it sound ok to you? 19 Oct 2006 21:37:30 +0700, Egor Pasko [EMAIL PROTECTED]: On the 0x207 day of Apache Harmony Rana Dasgupta wrote: Gregory had already created an entry on the front page ( see his comments above ). I expected to see JIT development tasks and DRLVM known issues and limitations (TODO list for DRLVM) somewhat unified in naming. Say, I prefer JIT development tasks and Core VM development tasks links near each other. Is it good for everyone so I could change it? On 19 Oct 2006 10:55:43 +0700, Egor Pasko [EMAIL PROTECTED] wrote: On the 0x207 day of Apache Harmony Rana Dasgupta wrote: I added the VM dev tasks to http://wiki.apache.org/harmony/CoreVmDevelopmentItems off Gregory's currently empty page. Please change as necessary. Why not from the front page? On 18 Oct 2006 20:11:14 +0700, Egor Pasko [EMAIL PROTECTED] wrote: now this is done: http://wiki.apache.org/harmony/JIT_Development_Tasks feel free to correct me. Front page is updated too. [snip] -- Egor Pasko, Intel Managed Runtime 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] -- 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] -- Gregory Shimansky, Intel Middleware Products Division
Re: [drlvm] A list of drlvm enhancements and limitations
On the 0x207 day of Apache Harmony Gregory Shimansky wrote: I don't really care about wording, I just wanted to make separate list for high level TODO items, like implementation of big pieces, and enhancements/limitations of the current code state. So I made a new link from the page which Rana used and put there my 3 items. If you think appropriate, you could insert your own link there too for JIT TODO items and rename this whole section to drlvm and JIT (if you think JIT is not a part of DRLVM) to include both. Does it sound ok to you? Now I see your strategy :) Sure, JIT is a part of DRLVM! I do not like pages with nothing except one or two links. That is why I would prefer to put JIT and Core VM tasks on the top page. But if there is something more to add to the TODO List for DRLVM page in the nearest future, I feel like moving these subtasks out of the FrontPage. Gregory, is it something to change in the TODO for DRLVM soon? BTW, I do not like the name: DRLVM known issues and limitations (TODO list for DRLVM), it stresses on limitations too much :) I feel more like leaving it TODO list for DRLVM. Cosmetic change, but.. :) 19 Oct 2006 21:37:30 +0700, Egor Pasko [EMAIL PROTECTED]: On the 0x207 day of Apache Harmony Rana Dasgupta wrote: Gregory had already created an entry on the front page ( see his comments above ). I expected to see JIT development tasks and DRLVM known issues and limitations (TODO list for DRLVM) somewhat unified in naming. Say, I prefer JIT development tasks and Core VM development tasks links near each other. Is it good for everyone so I could change it? On 19 Oct 2006 10:55:43 +0700, Egor Pasko [EMAIL PROTECTED] wrote: On the 0x207 day of Apache Harmony Rana Dasgupta wrote: I added the VM dev tasks to http://wiki.apache.org/harmony/CoreVmDevelopmentItems off Gregory's currently empty page. Please change as necessary. Why not from the front page? On 18 Oct 2006 20:11:14 +0700, Egor Pasko [EMAIL PROTECTED] wrote: now this is done: http://wiki.apache.org/harmony/JIT_Development_Tasks feel free to correct me. Front page is updated too. [snip] -- Egor Pasko, Intel Managed Runtime 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] -- 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] -- 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]
Re: [drlvm] A list of drlvm enhancements and limitations
Egor Pasko wrote: On the 0x207 day of Apache Harmony Gregory Shimansky wrote: I don't really care about wording, I just wanted to make separate list for high level TODO items, like implementation of big pieces, and enhancements/limitations of the current code state. So I made a new link from the page which Rana used and put there my 3 items. If you think appropriate, you could insert your own link there too for JIT TODO items and rename this whole section to drlvm and JIT (if you think JIT is not a part of DRLVM) to include both. Does it sound ok to you? Now I see your strategy :) Sure, JIT is a part of DRLVM! I do not like pages with nothing except one or two links. That is why I would prefer to put JIT and Core VM tasks on the top page. But if there is something more to add to the TODO List for DRLVM page in the nearest future, I feel like moving these subtasks out of the FrontPage. Gregory, is it something to change in the TODO for DRLVM soon? I think we could give it more structure as someone earlier suggested, TODO items, enhancements, limitations, whatever. Or we could break TODO items down in components. First I wanted to see just how much stuff like this we'll collect, then decide what to do with it to make it look pretty. That's why I don't care much about pages layout right now. BTW, I do not like the name: DRLVM known issues and limitations (TODO list for DRLVM), it stresses on limitations too much :) I feel more like leaving it TODO list for DRLVM. Cosmetic change, but.. :) Go for it. -- Gregory Shimansky, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] A list of drlvm enhancements and limitations
On the 0x208 day of Apache Harmony Gregory Shimansky wrote: Egor Pasko wrote: On the 0x207 day of Apache Harmony Gregory Shimansky wrote: I don't really care about wording, I just wanted to make separate list for high level TODO items, like implementation of big pieces, and enhancements/limitations of the current code state. So I made a new link from the page which Rana used and put there my 3 items. If you think appropriate, you could insert your own link there too for JIT TODO items and rename this whole section to drlvm and JIT (if you think JIT is not a part of DRLVM) to include both. Does it sound ok to you? Now I see your strategy :) Sure, JIT is a part of DRLVM! I do not like pages with nothing except one or two links. That is why I would prefer to put JIT and Core VM tasks on the top page. But if there is something more to add to the TODO List for DRLVM page in the nearest future, I feel like moving these subtasks out of the FrontPage. Gregory, is it something to change in the TODO for DRLVM soon? I think we could give it more structure as someone earlier suggested, TODO items, enhancements, limitations, whatever. Or we could break TODO items down in components. +1 to split TODO items down in components. For today my vision is: * DRLVM TODOs is broken into Core VM TODOs and JIT TODOs * JIT TODOs are broken into For Beginners, Front End, Performance, etc. now implemented :) take a look First I wanted to see just how much stuff like this we'll collect, then decide what to do with it to make it look pretty. That's why I don't care much about pages layout right now. Gregory, I suffer from structural laziness :) I am not happy with empty structures as they confuse readers. That is why I wanted to prepare the content first and then structurize. Happily, now it's not an issue, see below. BTW, I do not like the name: DRLVM known issues and limitations (TODO list for DRLVM), it stresses on limitations too much :) I feel more like leaving it TODO list for DRLVM. Cosmetic change, but.. :) Go for it. done. Now it's TODO List for DRLVM. JIT dev tasks link moved there. Limitations enlisted there too. I hope, that's OK for all of us. Thank you for suggestions! -- 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]
Re: [drlvm] A list of drlvm enhancements and limitations
On 18 Oct 2006 11:31:09 +0700, Egor Pasko [EMAIL PROTECTED] wrote: 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. I understand interface devirt with value profiler item from Rana's list as the same task. + 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. Yes, our (Jitrino.OPT) loop optimizations are in a bad state today :) BTW the page I've created recently ( http://wiki.apache.org/harmony/JIT_Tasks_For_Beginners ) could be removed and all the tasks listed there are added to the new page. Another proposal: mark every item with a level of expertise required for a volunteer: Novice, Advanced, Expert This will help both to novice and expert users: Novice will know if the task is rather easy. An expert will have a hint that the task worth to be discussed about side effects more carefully... -- Mikhail Fursov
Re: [drlvm] A list of drlvm enhancements and limitations
On the 0x206 day of Apache Harmony Rana Dasgupta wrote: Egor, I understand them as seperate and distinct optimizations, but we can do it however you, Mikhail would like to list them. The list also does not include more local optimizations that are bound to appear as a result of performance work. I see, small items are not worth to mention.. right! I see these 2 tasks as good candidates to list because they are: * easily understood * attractive to work on * kind of critical for performance today * not trivial, but not too complicated * can be done by 1 contributor in a reasonable amount of time Mikhail, do you agree? are we listing them? On 18 Oct 2006 11:31:09 +0700, Egor Pasko [EMAIL PROTECTED] wrote: 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? -- 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]
Re: [drlvm] A list of drlvm enhancements and limitations
On 18 Oct 2006 13:50:02 +0700, Egor Pasko [EMAIL PROTECTED] wrote: I see, small items are not worth to mention.. right! I see these 2 tasks as good candidates to list because they are: * easily understood * attractive to work on * kind of critical for performance today * not trivial, but not too complicated * can be done by 1 contributor in a reasonable amount of time Mikhail, do you agree? are we listing them? Yes of course! We can clean the page latter if needed. It's an easy task with wiki :) Will you start it (I mean the page with all of the JIT tasks) ? -- Mikhail Fursov
RE: [drlvm] A list of drlvm enhancements and limitations
I side with all those who suggest that we write things down on Wiki. Grouping issues by component might also work out fine. Another suggestion: distinguish between Known Issues and TODOs - that is, between bugs and non-implemented features. I think this will allow us to see what needs to be fixed to ensure the code runs and what needs to be done to make it run better :) Thank you, Nadya Morozova -Original Message- From: Gregory Shimansky [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 17, 2006 11:18 PM To: harmony-dev@incubator.apache.org Subject: Re: [drlvm] A list of drlvm enhancements and limitations On Tuesday 17 October 2006 19:26 Rana Dasgupta wrote: Mikhail, Makes sense. BTW, we need to change the IA-64 to IPF( IA-64 is not an external term ) on any posted list. IA32 to x86-32 bit and Intel 64 to x86-64 bit. Sorry for the typo's. I agree with Mikhail, the list looks quite big with your contribution. I think we can already start building a page which I've created [1] but didn't write anything on it yet. If you want you can start creating sublinks on it and submit your list in parts. I didn't have time to write down my 3 enhancement suggestions so the page is basically clean so far. [1] http://wiki.apache.org/harmony/DrlvmKnownInssuesAndLimitations On 10/17/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Mikhail Fursov wrote: Rana, the JIT list is really good. Thanks for collecting it. I propose to create a single page for DRLVM tasks and list only components on it. And for every component from the list create another page with its tasks. The reason is that after Rana's post we have too much open tasks for a single page. +1 -- Gregory Shimansky, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] A list of drlvm enhancements and limitations
On the 0x206 day of Apache Harmony Mikhail Fursov wrote: On 18 Oct 2006 11:31:09 +0700, Egor Pasko [EMAIL PROTECTED] wrote: 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. I understand interface devirt with value profiler item from Rana's list as the same task. I separeted them just to state them clearly. One task is a value profiler. Another is interface devirt. They are best when they coexist, but they can work without each other (hypothetically). There is also virtual call devirt that I mentioned. Value profiler should be useful here too. + 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. Yes, our (Jitrino.OPT) loop optimizations are in a bad state today :) +1 =) especially because Java is not the best for loop optimizations (sorry if offending:) BTW the page I've created recently ( http://wiki.apache.org/harmony/JIT_Tasks_For_Beginners ) could be removed and all the tasks listed there are added to the new page. +1, I'll make the new page and copy-paste Rana's collection there spiced with my additionals .. if we all agree Another proposal: mark every item with a level of expertise required for a volunteer: Novice, Advanced, Expert This will help both to novice and expert users: Novice will know if the task is rather easy. An expert will have a hint that the task worth to be discussed about side effects more carefully... Let's mark in 2 categories: Novice and Advanced. Otherwise it sounds like you should prove that you are an expert, only then you can take the task, which I do not want to stress on. -- 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]
Re: [drlvm] A list of drlvm enhancements and limitations
On the 0x206 day of Apache Harmony Egor Pasko wrote: On the 0x206 day of Apache Harmony Mikhail Fursov wrote: On 18 Oct 2006 11:31:09 +0700, Egor Pasko [EMAIL PROTECTED] wrote: 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. I understand interface devirt with value profiler item from Rana's list as the same task. I separeted them just to state them clearly. One task is a value profiler. Another is interface devirt. They are best when they coexist, but they can work without each other (hypothetically). There is also virtual call devirt that I mentioned. Value profiler should be useful here too. + 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. Yes, our (Jitrino.OPT) loop optimizations are in a bad state today :) +1 =) especially because Java is not the best for loop optimizations (sorry if offending:) BTW the page I've created recently ( http://wiki.apache.org/harmony/JIT_Tasks_For_Beginners ) could be removed and all the tasks listed there are added to the new page. +1, I'll make the new page and copy-paste Rana's collection there spiced with my additionals .. if we all agree now this is done: http://wiki.apache.org/harmony/JIT_Development_Tasks feel free to correct me. Front page is updated too. [snip] -- 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]
Re: [drlvm] A list of drlvm enhancements and limitations
On 18 Oct 2006 16:13:26 +0700, Egor Pasko [EMAIL PROTECTED] wrote: Let's mark in 2 categories: Novice and Advanced. Otherwise it sounds like you should prove that you are an expert, only then you can take the task, which I do not want to stress on. Ok, moreover some tasks can have both simple and advanced solutions. I'll take a look at the page and add the result of our discussion about optimizer's pipeline refactoring. It looks like we have an agreement in this task too. -- Mikhail Fursov
Re: [drlvm] A list of drlvm enhancements and limitations
Alex, Thanks for the information about Intel64 conventions for long mode. I spoke losely and inaccurately below. I am the collector of the development items, not the originator of all items :-) It may be a good idea to write a short document describing the calling conventions we support on various platforms and add this to our list of JIT docs. Calling conventions affect both JIT and core VM and clearly stating them is useful. It is also one of the first things one may want to know about how the jit works. Thanks, Rana On 10/17/06, Alex Astapchuk [EMAIL PROTECTED] wrote: A small correction: Currently the IA-32 and Intel-64 CG uses calling conventions that pass all parameters on stack. Stack-only is about IA-32 calling convention. Intel64 CG generates a calling convention as per SystemV ABI recommendations [1]. This is a variant of fastcall with 6 GP registers and 8 XMM registers used for arguments passing. Also, all used calling conventions require returning FP values in x87 register stack and Again, only on IA-32. Intel64 code returns float-point values on XMM0. do not support callee-saved SSE registers while all FP arithmetic is done using SSE/SSE2. That's correct. No convention currently used supports callee-saved XMMs... [1] http://refspecs.freestandards.org/elf/x86_64-SysV-psABI.pdf -- Thanks, Alex
Re: [drlvm] A list of drlvm enhancements and limitations
I added the VM dev tasks to http://wiki.apache.org/harmony/CoreVmDevelopmentItems off Gregory's currently empty page. Please change as necessary. Rana On 18 Oct 2006 20:11:14 +0700, Egor Pasko [EMAIL PROTECTED] wrote: now this is done: http://wiki.apache.org/harmony/JIT_Development_Tasks feel free to correct me. Front page is updated too. [snip] -- Egor Pasko, Intel Managed Runtime Division
Re: [drlvm] A list of drlvm enhancements and limitations
On the 0x207 day of Apache Harmony Rana Dasgupta wrote: I added the VM dev tasks to http://wiki.apache.org/harmony/CoreVmDevelopmentItems off Gregory's currently empty page. Please change as necessary. Why not from the front page? On 18 Oct 2006 20:11:14 +0700, Egor Pasko [EMAIL PROTECTED] wrote: now this is done: http://wiki.apache.org/harmony/JIT_Development_Tasks feel free to correct me. Front page is updated too. [snip] -- Egor Pasko, Intel Managed Runtime 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]
Re: [drlvm] A list of drlvm enhancements and limitations
Gregory had already created an entry on the front page ( see his comments above ). On 19 Oct 2006 10:55:43 +0700, Egor Pasko [EMAIL PROTECTED] wrote: On the 0x207 day of Apache Harmony Rana Dasgupta wrote: I added the VM dev tasks to http://wiki.apache.org/harmony/CoreVmDevelopmentItems off Gregory's currently empty page. Please change as necessary. Why not from the front page? On 18 Oct 2006 20:11:14 +0700, Egor Pasko [EMAIL PROTECTED] wrote: now this is done: http://wiki.apache.org/harmony/JIT_Development_Tasks feel free to correct me. Front page is updated too. [snip] -- Egor Pasko, Intel Managed Runtime 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]
Re: [drlvm] A list of drlvm enhancements and limitations
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
Re: [drlvm] A list of drlvm enhancements and limitations
Rana, the JIT list is really good. Thanks for collecting it. I propose to create a single page for DRLVM tasks and list only components on it. And for every component from the list create another page with its tasks. The reason is that after Rana's post we have too much open tasks for a single page. On 10/17/06, Rana Dasgupta [EMAIL PROTECTED] 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
Re: [drlvm] A list of drlvm enhancements and limitations
Mikhail Fursov wrote: Rana, the JIT list is really good. Thanks for collecting it. I propose to create a single page for DRLVM tasks and list only components on it. And for every component from the list create another page with its tasks. The reason is that after Rana's post we have too much open tasks for a single page. +1 On 10/17/06, Rana Dasgupta [EMAIL PROTECTED] 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
Re: [drlvm] A list of drlvm enhancements and limitations
Mikhail, Makes sense. BTW, we need to change the IA-64 to IPF( IA-64 is not an external term ) on any posted list. IA32 to x86-32 bit and Intel 64 to x86-64 bit. Sorry for the typo's. Rana On 10/17/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Mikhail Fursov wrote: Rana, the JIT list is really good. Thanks for collecting it. I propose to create a single page for DRLVM tasks and list only components on it. And for every component from the list create another page with its tasks. The reason is that after Rana's post we have too much open tasks for a single page. +1
Re: [drlvm] A list of drlvm enhancements and limitations
On Tuesday 17 October 2006 19:26 Rana Dasgupta wrote: Mikhail, Makes sense. BTW, we need to change the IA-64 to IPF( IA-64 is not an external term ) on any posted list. IA32 to x86-32 bit and Intel 64 to x86-64 bit. Sorry for the typo's. I agree with Mikhail, the list looks quite big with your contribution. I think we can already start building a page which I've created [1] but didn't write anything on it yet. If you want you can start creating sublinks on it and submit your list in parts. I didn't have time to write down my 3 enhancement suggestions so the page is basically clean so far. [1] http://wiki.apache.org/harmony/DrlvmKnownInssuesAndLimitations On 10/17/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Mikhail Fursov wrote: Rana, the JIT list is really good. Thanks for collecting it. I propose to create a single page for DRLVM tasks and list only components on it. And for every component from the list create another page with its tasks. The reason is that after Rana's post we have too much open tasks for a single page. +1 -- Gregory Shimansky, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] A list of drlvm enhancements and limitations
Very comprehensive list and the GC part is also a good summary that catches those in my mind. We probably want to categorize the items into something like bugs, limitations, enhancements and features wanted so that contributors can have a clear picture on DRLVM functionalities. Thanks, xiaofeng On 10/17/06, Rana Dasgupta [EMAIL PROTECTED] 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
Re: [drlvm] A list of drlvm enhancements and limitations
A small correction: Currently the IA-32 and Intel-64 CG uses calling conventions that pass all parameters on stack. Stack-only is about IA-32 calling convention. Intel64 CG generates a calling convention as per SystemV ABI recommendations [1]. This is a variant of fastcall with 6 GP registers and 8 XMM registers used for arguments passing. Also, all used calling conventions require returning FP values in x87 register stack and Again, only on IA-32. Intel64 code returns float-point values on XMM0. do not support callee-saved SSE registers while all FP arithmetic is done using SSE/SSE2. That's correct. No convention currently used supports callee-saved XMMs... [1] http://refspecs.freestandards.org/elf/x86_64-SysV-psABI.pdf -- Thanks, Alex 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
Re: [drlvm] A list of drlvm enhancements and limitations
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
Re: [drlvm] A list of drlvm enhancements and limitations
Go for it. Gregory Shimansky wrote: 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? - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] A list of drlvm enhancements and limitations
Good idea. -xiaofeng On 10/17/06, Gregory Shimansky [EMAIL PROTECTED] wrote: 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 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] A list of drlvm enhancements and limitations
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 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
