Andrey Chernyshev wrote:
On 6/29/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Andrey Chernyshev wrote:
Hello,
In addition to the already proposed generic tasks like 5.0 support or
concurrent GC mentioned by Ivan, I'd like to add some more specific
things that might be interesting
Andrey Chernyshev wrote:
Hello,
In addition to the already proposed generic tasks like 5.0 support or
concurrent GC mentioned by Ivan, I'd like to add some more specific
things that might be interesting for people to look at as well:
(1) Complete Java bytecode verifier
Class structure
On 6/29/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Andrey Chernyshev wrote:
Hello,
In addition to the already proposed generic tasks like 5.0 support or
concurrent GC mentioned by Ivan, I'd like to add some more specific
things that might be interesting for people to look at as well:
On the 0x198 day of Apache Harmony Rana Dasgupta wrote:
On 22 Jun 2006 16:16:24 +0700, Egor Pasko [EMAIL PROTECTED] wrote:
Addressing JIT changes, I would suggest some short-term
iprovements/projects that are interesting to do to quickly catch up
with DRLVM optimizing JIT(s):
*
On 29/06/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Andrey Chernyshev wrote:
Hello,
In addition to the already proposed generic tasks like 5.0 support or
concurrent GC mentioned by Ivan, I'd like to add some more specific
things that might be interesting for people to look at as
Hello,
In addition to the already proposed generic tasks like 5.0 support or
concurrent GC mentioned by Ivan, I'd like to add some more specific
things that might be interesting for people to look at as well:
(1) Complete Java bytecode verifier
Class structure verification and subroutines (e.g.
On Wednesday 28 June 2006 21:05 Andrey Chernyshev wrote:
(2) Handling out of C memory conditions
VM must throw OutOfMemoryException when there is a lack of C memory.
For example, if local or global handle cannot be allocated then OOME
should be thrown � OutOfMemoryException must be thrown
Hi Andrey,
I think all of what you propose is worth doing. Some of the items
might be low priority since they don't directly map to a requirement
or spec. It seems 3, 4, 6 and 7 fall in the low priority category.
Some additional observations:
3) Eliminate C++ exceptions support is a good
If somebody interested, I can share my GC which was made to replace GC
v4. It addresses performance issues I've noticed on GC v4:
- too many atomic ops
- too many bit shifts
- too many passes (touches of objects data)
New GC (which has code name gc_yuk) is combination of copying and
Weldon Washburn wrote:
On 6/21/06, Xiao-Feng Li [EMAIL PROTECTED] wrote:
If no one else is doing it, I will start the porting of SableVM's gen
GC into DRLVM.
Good idea. Go for it.
I talked to Carl Lebsack today. He mentioned that SableVM asked
permission to relicense his generational GC
On the 0x18F day of Apache Harmony Rana Dasgupta wrote:
On 6/20/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Build and dependency issues aside, what are the next functional
enhancements / features for DRLVM?
I think #1 is to get it to function with Java 5 classfiles, so we can
make
On 6/21/06, Weldon Washburn [EMAIL PROTECTED] wrote:
I agree with java 5 being #1. Some additional thoughts. GCV4 needs
replacing for a variety of reasons. The port of MMTk should pick up a
bunch of the great GC work being done in the Jikes/MMTk community. It
would also be nice to have a
2006/6/21, Weldon Washburn [EMAIL PROTECTED]:
On 6/20/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
On Tuesday 20 June 2006 19:44 Salikh Zakirov wrote:
Geir Magnusson Jr wrote:
Build and dependency issues aside, what are the next functional
enhancements / features for DRLVM?
I
On 6/21/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
Yes it will work with Jitrino.JET and for now only wirh it. This is done
because compilation optimizations may lose exact bytecode and local
variables mapping which are required for debugging. If JVMTI is enabled
on
the command line only
On 6/21/06, Xiao-Feng Li [EMAIL PROTECTED] wrote:
If no one else is doing it, I will start the porting of SableVM's gen
GC into DRLVM.
Good idea. Go for it.
I talked to Carl Lebsack today. He mentioned that SableVM asked
permission to relicense his generational GC under Apache license. It
Build and dependency issues aside, what are the next functional
enhancements / features for DRLVM?
I think #1 is to get it to function with Java 5 classfiles, so we can
make the switch throughout the project.
Thoughts? What else?
geir
Geir Magnusson Jr wrote:
Build and dependency issues aside, what are the next functional
enhancements / features for DRLVM?
I think #1 is to get it to function with Java 5 classfiles, so we can
make the switch throughout the project.
Thoughts? What else?
As far as I can tell, general
On 6/20/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Build and dependency issues aside, what are the next functional
enhancements / features for DRLVM?
I think #1 is to get it to function with Java 5 classfiles, so we can
make the switch throughout the project.
Thoughts? What else?
I agree
On Tuesday 20 June 2006 19:44 Salikh Zakirov wrote:
Geir Magnusson Jr wrote:
Build and dependency issues aside, what are the next functional
enhancements / features for DRLVM?
I think #1 is to get it to function with Java 5 classfiles, so we can
make the switch throughout the project.
On 6/20/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Build and dependency issues aside, what are the next functional
enhancements / features for DRLVM?
I think #1 is to get it to function with Java 5 classfiles, so we can
make the switch throughout the project.
Geir,
Good question. By
On 6/20/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
On Tuesday 20 June 2006 19:44 Salikh Zakirov wrote:
Geir Magnusson Jr wrote:
Build and dependency issues aside, what are the next functional
enhancements / features for DRLVM?
I think #1 is to get it to function with Java 5
On 6/20/06, Rana Dasgupta [EMAIL PROTECTED] wrote:
On 6/20/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Build and dependency issues aside, what are the next functional
enhancements / features for DRLVM?
I think #1 is to get it to function with Java 5 classfiles, so we can
make the switch
As mentioned in the [general] milestones and roadmap thread, work on
integrating the concurrency APIs will require VM support and it seems like
DRLVM is close to having some of it complete, so I would lobby for that.
The VM APIs need are atomic CAS, parking and possibly methods for set/get of
23 matches
Mail list logo
