You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Gregory Shimansky <gs...@gmail.com> on 2006/10/16 22:47:32 UTC
[drlvm] A list of drlvm enhancements and limitations
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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] A list of drlvm enhancements and limitations
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] A list of drlvm enhancements and limitations
Posted by Xiao-Feng Li <xi...@gmail.com>.
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 <rd...@gmail.com> 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 <ml...@gmail.com> 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 <gs...@gmail.com>:
> > > > 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] A list of drlvm enhancements and limitations
Posted by Rana Dasgupta <rd...@gmail.com>.
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 <al...@gmail.com> 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
Posted by Alex Astapchuk <al...@gmail.com>.
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 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 <ml...@gmail.com> 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 <gs...@gmail.com>:
>> > > 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] A list of drlvm enhancements and limitations
Posted by Mikhail Fursov <mi...@gmail.com>.
On 18 Oct 2006 13:50:02 +0700, Egor Pasko <eg...@gmail.com> 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
Posted by Egor Pasko <eg...@gmail.com>.
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 <eg...@gmail.com> 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] A list of drlvm enhancements and limitations
Posted by Rana Dasgupta <rd...@gmail.com>.
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.
Thanks,
Rana
> On 18 Oct 2006 11:31:09 +0700, Egor Pasko <eg...@gmail.com> 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?
> >
> >
Re: [drlvm] A list of drlvm enhancements and limitations
Posted by Mikhail Fursov <mi...@gmail.com>.
On 18 Oct 2006 16:13:26 +0700, Egor Pasko <eg...@gmail.com> 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
Posted by Egor Pasko <eg...@gmail.com>.
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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] A list of drlvm enhancements and limitations
Posted by Gregory Shimansky <gs...@gmail.com>.
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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] A list of drlvm enhancements and limitations
Posted by Egor Pasko <eg...@gmail.com>.
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 <eg...@gmail.com>:
> >
> > 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 <eg...@gmail.com> 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 <eg...@gmail.com>
> > > > 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: harmony-dev-unsubscribe@incubator.apache.org
> > > > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> > > >
> > > >
> >
> > --
> > Egor Pasko, Intel Managed Runtime Division
> >
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
>
> --
> 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] A list of drlvm enhancements and limitations
Posted by Gregory Shimansky <gs...@gmail.com>.
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 <eg...@gmail.com>:
>
> 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 <eg...@gmail.com> 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 <eg...@gmail.com>
> > > 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: harmony-dev-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> > >
> > >
>
> --
> Egor Pasko, Intel Managed Runtime Division
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Gregory Shimansky, Intel Middleware Products Division
Re: [drlvm] A list of drlvm enhancements and limitations
Posted by Egor Pasko <eg...@gmail.com>.
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 <eg...@gmail.com> 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 <eg...@gmail.com>
> > 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: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
--
Egor Pasko, Intel Managed Runtime Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] A list of drlvm enhancements and limitations
Posted by Rana Dasgupta <rd...@gmail.com>.
Gregory had already created an entry on the front page ( see his comments
above ).
On 19 Oct 2006 10:55:43 +0700, Egor Pasko <eg...@gmail.com> 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 <eg...@gmail.com>
> 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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
Re: [drlvm] A list of drlvm enhancements and limitations
Posted by Egor Pasko <eg...@gmail.com>.
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 <eg...@gmail.com> 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] A list of drlvm enhancements and limitations
Posted by Rana Dasgupta <rd...@gmail.com>.
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 <eg...@gmail.com> 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
Posted by Egor Pasko <eg...@gmail.com>.
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 <eg...@gmail.com> 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] A list of drlvm enhancements and limitations
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x206 day of Apache Harmony Mikhail Fursov wrote:
> On 18 Oct 2006 11:31:09 +0700, Egor Pasko <eg...@gmail.com> 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] A list of drlvm enhancements and limitations
Posted by Mikhail Fursov <mi...@gmail.com>.
On 18 Oct 2006 11:31:09 +0700, Egor Pasko <eg...@gmail.com> 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
Posted by Egor Pasko <eg...@gmail.com>.
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 <ml...@gmail.com> 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 <gs...@gmail.com>:
> > > > 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] A list of drlvm enhancements and limitations
Posted by Gregory Shimansky <gs...@gmail.com>.
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. <geir@pobox.com > 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] A list of drlvm enhancements and limitations
Posted by Rana Dasgupta <rd...@gmail.com>.
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. <geir@pobox.com > 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
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
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 <rd...@gmail.com> 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 <ml...@gmail.com> 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 <gs...@gmail.com>:
>> > > > 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] A list of drlvm enhancements and limitations
Posted by Mikhail Fursov <mi...@gmail.com>.
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 <rd...@gmail.com> 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 <ml...@gmail.com> 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 <gs...@gmail.com>:
> > > > 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
> > > >
> > >
> >
>
>
--
Mikhail Fursov
Re: [drlvm] A list of drlvm enhancements and limitations
Posted by Weldon Washburn <we...@gmail.com>.
On 10/31/06, Rana Dasgupta <rd...@gmail.com> 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 <gs...@gmail.com> 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
Posted by Rana Dasgupta <rd...@gmail.com>.
I created an MMTk page off the DRLVM core VM development page and put in
Weldon's list.
On 10/23/06, Gregory Shimansky <gs...@gmail.com> 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
Posted by Rana Dasgupta <rd...@gmail.com>.
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 <ml...@gmail.com> 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 <gs...@gmail.com>:
> > > 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
> > >
> >
>
Re: [drlvm] A list of drlvm enhancements and limitations
Posted by Mikhail Loenko <ml...@gmail.com>.
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 <gs...@gmail.com>:
> 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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] A list of drlvm enhancements and limitations
Posted by Xiao-Feng Li <xi...@gmail.com>.
Good idea. -xiaofeng
On 10/17/06, Gregory Shimansky <gs...@gmail.com> 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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org