You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Geir Magnusson Jr <ge...@pobox.com> on 2006/06/20 14:04:39 UTC
[drlvm] what's next?
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
---------------------------------------------------------------------
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] what's next?
Posted by "Nektarios K. Papadopoulos" <np...@inaccessnetworks.com>.
Weldon Washburn wrote:
> On 6/21/06, Xiao-Feng Li <xi...@gmail.com> 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
> seems possible that all of SableVM will be relicensed under Apache
> license. :) Carl mentioned that the SableVM/GC interface is not
But it *is* relicensed since last March see:
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200603.mbox/%3c44249683.2000702@sablevm.org%3e
> well defined but sees value in what we are proposing here.
>
>>
>> Thanks,
>> xiaofeng
>>
>> ---------------------------------------------------------------------
>> 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
>>
>>
>
>
--
Nektarios K. Papadopoulos
inAccess Networks
---------------------------------------------------------------------
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] what's next?
Posted by Weldon Washburn <we...@gmail.com>.
On 6/21/06, Xiao-Feng Li <xi...@gmail.com> 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
seems possible that all of SableVM will be relicensed under Apache
license. :) Carl mentioned that the SableVM/GC interface is not
well defined but sees value in what we are proposing here.
>
> Thanks,
> xiaofeng
>
> ---------------------------------------------------------------------
> 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
>
>
--
Weldon Washburn
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] what's next?
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 6/21/06, Weldon Washburn <we...@gmail.com> 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 simple C generational collector. I am
> real busy with MMTk port. Otherwise I would volunteer to look into
> porting SableVM's generational collector. I think it was written by
> Carl Lebsack. Porting both MMTk and SableVM GC would give DRLVM a
> much better basis for generic VM/GC interfaces.
>
If no one else is doing it, I will start the porting of SableVM's gen
GC into DRLVM.
Thanks,
xiaofeng
---------------------------------------------------------------------
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] what's next?
Posted by Ivan Volosyuk <iv...@gmail.com>.
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
compacting collector with adaptive switching. It can switch from
copying to compacting during one GC, so evacuation area can be quite
small and dynamically predicted. Copying collector has very simple
code pass with one advanced idea and it is extremely fast. Sliding
compacting algorithm is used when performance equation suggests it or
when evacuation area overflows.
About performance, on SpecJBB2005 (modified to be used on jre1.4) on
Dual HT Xeon 3.2GHz gc_yuk versus gc_v4 gives:
- 27% score gain
- 7 times less average GC pauses
- 5 times less time spent in stop-the-world state
I think the idea of all advanced algorithms is to give high
performance, IMHO this code would be good starting point in
performance race.
I am going to continue improving and experimenting with this code
base. The code is quite small ~170kb of sources with 1/3 of it in
copyright headers. And quite clean and easy for experimenting. I have
tried a few parallelization attempts, but it didn't give me
performance improvement on the mentioned above server. Looks like the
limiting factor of performance is memory speed - little CPU work
needed, but all live objects need to be scanned. Next step would be to
make a concurrent GC algorithm, it can be a solution for further
performance improvement.
--
Ivan
Intel Middleware Products Division
On 6/20/06, Weldon Washburn <we...@gmail.com> wrote:
> On 6/20/06, Geir Magnusson Jr <ge...@pobox.com> 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 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 simple C generational collector. I am
> real busy with MMTk port. Otherwise I would volunteer to look into
> porting SableVM's generational collector. I think it was written by
> Carl Lebsack. Porting both MMTk and SableVM GC would give DRLVM a
> much better basis for generic VM/GC interfaces.
>
> Another thing that needs to happen in DRLVM is a well designed
> VM-JIT-GC synchronization protocol. Clear, understandable
> system-wide synch protocol will be very nice to have when we get to
> the point of advanced threading module. This really does not exist
> today. If there is interest, I could start a harmony-dev email thread
> on this topic.
---------------------------------------------------------------------
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] what's next?
Posted by Weldon Washburn <we...@gmail.com>.
On 6/20/06, Geir Magnusson Jr <ge...@pobox.com> 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 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 simple C generational collector. I am
real busy with MMTk port. Otherwise I would volunteer to look into
porting SableVM's generational collector. I think it was written by
Carl Lebsack. Porting both MMTk and SableVM GC would give DRLVM a
much better basis for generic VM/GC interfaces.
Another thing that needs to happen in DRLVM is a well designed
VM-JIT-GC synchronization protocol. Clear, understandable
system-wide synch protocol will be very nice to have when we get to
the point of advanced threading module. This really does not exist
today. If there is interest, I could start a harmony-dev email thread
on this topic.
>
> geir
>
> ---------------------------------------------------------------------
> 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
>
>
--
Weldon Washburn
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] what's next?
Posted by Weldon Washburn <we...@gmail.com>.
On 6/20/06, Rana Dasgupta <rd...@gmail.com> wrote:
> On 6/20/06, Geir Magnusson Jr <ge...@pobox.com> 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 next, I guess we mean in the relatively
> near future...Some thoughts that come to mind in addition to 1.5 are:
> 1. We should start running classlibraries and existing api tests against
> the DRLVM bits. This is sure to identify bugs/issues that will need
> addressing.
> 2. We need to achieve completeness in the DRLVM VM functionality.....we
> don't handle stack overflows well, efficient unmanagd heap management
> issues, there is functional completenes needed in the verifier, optimized
> locks( thin, deflatable, jit optimized ), improvements in JVMTI support as
> Gregory points out.
> 3. In garbage collection, one thread that Weldon has already started is
> MMTk integration which looks promising, but while we finish that work, it
> may also make sense to substitute the existing rudimentary GC with a more
> functional one with better performance that can work as the default GC
> outside the MMTk integrated suite.
+1 (+2 if we port an existing gc from another jvm)
> 4. We should also look at enhancements to the JITs ...and other than support
> for new platforms ( 64 bit , down level platforms that support x87 but not
> SSE* instructions..based on the minimum machine model we want to support eg
> a pentium III running Windows/Linux )some of this work would benefit from
> performance guidance...helpers should be inlined, some of the
> optimizations eg., devirtualization perfected, polling to support
> collection should consume less overhead, more optimized JNI invocation at
> some point.
This brings up a good point. Performance is important but the subject
of this thread is, "...what are the next functional enhancements?"
Should the scope be broadened to include performance goals? If true,
perhaps start a discussion on this topic.
> 5. This is also in reference to the other thread you started about goals for
> Harmony, it may help to establish some vectors that are important for us in
> Harmony eg., among...1.5 and TCK compatibility, performance( benchmarking ),
> startup time, memory footprint, and that in some sense will determine the
> priorities. The work to be done will fall out of this.
>
> Feedback most welcome :-)
>
> Thanks,
> Rana
>
>
> ---------------------------------------------------------------------
> 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
>
>
--
Weldon Washburn
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] what's next?
Posted by Weldon Washburn <we...@gmail.com>.
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 idea for several
reasons. First, operating systems traditionally avoid implementing in
C++. Eliminating C++ from DRLVM will make it more conducive to VM/OS
integration. Second, there is the possibility that JVM implementation
will migrate to Java. In other words, the parts of the VM that need
"C++" features might end up being rewritten in Java and using Java
exception handling. Bottom line: mix/matching Java/C/C++ inside the
VM is a burden with a small long term payback.
4) This item becomes much simpler if C++ code is re-coded in Java.
On 6/28/06, Andrey Chernyshev <a....@gmail.com> 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 verification and subroutines (e.g. finally blocks) has
> to be added to the bytecode verifier in order to make it
> full-functional (as required by JVMS spec).
>
> (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 �C OutOfMemoryException must be thrown (this is
> required by JNI/JVMTI spec).
>
> (3) Eliminate C++ exceptions support
> ��urrently some parts of VM and native part of kernel classes are
> complied with C++ exception support which gives an extra overhead. One
> of the issues is that some parts are using MS implementation of STL
> which requires C++ exception support. MS STL has to be replaced with
> something else.
>
> (4) Destructive stack unwinding - perhaps it needs to be eliminated from VM.
> In certain cases VM performs stack unwinding up to the nearest M2N
> frame and just jumps to that point. If some C++ objects are available
> on stack, destructors for these objects won't be called. This may
> affect VM stability under stress conditions.
>
> (5) Unicode support
> Currently VM doesn't support classes/field/names which utilize
> character other than ASCII. Handling of the Unicode names will likely
> be needed for certification. This impacts class loader, natives
> support, JNI and JVMTI components. Another issue is that VM would not
> understand the command line args (like class name and start arguments)
> if they are written with unicode characters.
>
> (6) String internal implementation could be moved to Java.
> Internal representation of strings is currently kept in the native
> class loading code (string pool). To enable efficient resource
> deallocation, they better be moved to Java code such that GC/class
> unloading can operate with strings more efficiently.
>
> (7) Unify C Memory management.
> Native memory is currently allocated in DRLVM by ~10 different means
> at different places. Some of examples are using APR memory pools, C
> mallocs, C++ new operator e.t.c. This complicates the communication
> between the different modules within DRLVM since there is no
> consideration how to deallocate the memory being allocated by other
> component and may trigger memory leaks in the system.
> I wonder if there could be any ideas how the memory management
> approach could be unified in the DRLVM? It may also help to monitor
> and eliminate possible memory leaks in the system.
>
> (8) Complete JNI and JVMTI implementations.
> JNI and JVMTI specs are currently not completely implemented. For
> example, JNI is missing weak references implementation, invocation
> API. JVMTI is missing RedefineClasses function.
> ...
> There certainly other gaps which I'm not aware of ;)
>
> Any thoughts which of the above could be worth doing?
>
> Thanks,
> Andrey.
>
>
> On 6/21/06, Rana Dasgupta <rd...@gmail.com> wrote:
> > On 6/20/06, Geir Magnusson Jr <ge...@pobox.com> 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 next, I guess we mean in the relatively
> > near future...Some thoughts that come to mind in addition to 1.5 are:
> > 1. We should start running classlibraries and existing api tests against
> > the DRLVM bits. This is sure to identify bugs/issues that will need
> > addressing.
> > 2. We need to achieve completeness in the DRLVM VM functionality.....we
> > don't handle stack overflows well, efficient unmanagd heap management
> > issues, there is functional completenes needed in the verifier, optimized
> > locks( thin, deflatable, jit optimized ), improvements in JVMTI support as
> > Gregory points out.
> > 3. In garbage collection, one thread that Weldon has already started is
> > MMTk integration which looks promising, but while we finish that work, it
> > may also make sense to substitute the existing rudimentary GC with a more
> > functional one with better performance that can work as the default GC
> > outside the MMTk integrated suite.
> > 4. We should also look at enhancements to the JITs ...and other than support
> > for new platforms ( 64 bit , down level platforms that support x87 but not
> > SSE* instructions..based on the minimum machine model we want to support eg
> > a pentium III running Windows/Linux )some of this work would benefit from
> > performance guidance...helpers should be inlined, some of the
> > optimizations eg., devirtualization perfected, polling to support
> > collection should consume less overhead, more optimized JNI invocation at
> > some point.
> > 5. This is also in reference to the other thread you started about goals for
> > Harmony, it may help to establish some vectors that are important for us in
> > Harmony eg., among...1.5 and TCK compatibility, performance( benchmarking ),
> > startup time, memory footprint, and that in some sense will determine the
> > priorities. The work to be done will fall out of this.
> >
> > Feedback most welcome :-)
> >
> > Thanks,
> > Rana
> >
> >
> > ---------------------------------------------------------------------
> > 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
> >
> >
>
>
> --
> Andrey Chernyshev
> Intel Middleware Products Division
>
--
Weldon Washburn
Intel Middleware Products Division
Re: [drlvm] what's next?
Posted by Gregory Shimansky <gs...@gmail.com>.
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 (this is
> required by JNI/JVMTI spec).
This is not really anywhere in JNI spec, but that is how RI behaves when
NewGlobalRef or NewLocalRef cannot be executed because of lack of C heap. It
is probably good to follow this behavior instead of crashing.
JVMTI spec requires returning JVMTI_ERROR_OUT_OF_MEMORY, not throwing an
exception but this is a minor difference.
> (7) Unify C Memory management.
> Native memory is currently allocated in DRLVM by ~10 different means
> at different places. Some of examples are using APR memory pools, C
> mallocs, C++ new operator e.t.c. This complicates the communication
> between the different modules within DRLVM since there is no
> consideration how to deallocate the memory being allocated by other
> component and may trigger memory leaks in the system.
> I wonder if there could be any ideas how the memory management
> approach could be unified in the DRLVM? It may also help to monitor
> and eliminate possible memory leaks in the system.
I can share some interesting observation from my experience on this topic.
I've analyzed a stress test when JNI functions mentioned above are used in
stressed heap conditions, when no memory is available. To reach this result
the test's native code used malloc until malloc returned NULL, then started
to call NewLocalRef.
When running this test on JRockit on windows which doesn't gracefully handle
such situation, it crashes and produces a crash analysis dump to the
terminal. One of the lines in it stated that 1 malloc with 1000 (whatever was
the size used for exhausing C heap) bytes has failed. I didn't try this test
on linux.
This means that JRockit somehow replaced malloc used in Java native function
of the test to register the condition that it has failed once. I wonder how
it can be done. It would allow complete C heap memory management unification
both for VM and Java native API and user code.
--
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] what's next?
Posted by Pavel Rebriy <pa...@gmail.com>.
On 29/06/06, Geir Magnusson Jr <ge...@pobox.com> 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:
> >
> > (1) Complete Java bytecode verifier
> > Class structure verification and subroutines (e.g. finally blocks) has
> > to be added to the bytecode verifier in order to make it
> > full-functional (as required by JVMS spec).
>
> Do you think that it will be complete at that point? It's my
> understanding that it's fairly difficult and subtle to get it right.
> I'm hoping that we can just get that from Sun :)
IMHO, developing of verifier is not so difficult. Is it subtle? - yes, but
not difficult.
It is not harder then developing of JIT :)
>
> > (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 (this is
> > required by JNI/JVMTI spec).
>
> What does it do now?
>
> geir
>
> ---------------------------------------------------------------------
> 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
>
>
--
Best regards,
Pavel Rebriy
Re: [drlvm] what's next?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Andrey Chernyshev wrote:
> On 6/29/06, Geir Magnusson Jr <ge...@pobox.com> 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:
>> >
>> > (1) Complete Java bytecode verifier
>> > Class structure verification and subroutines (e.g. finally blocks) has
>> > to be added to the bytecode verifier in order to make it
>> > full-functional (as required by JVMS spec).
>>
>> Do you think that it will be complete at that point? It's my
>> understanding that it's fairly difficult and subtle to get it right.
>> I'm hoping that we can just get that from Sun :)
>
> Actually I'm not sure if RI is doing all of this, but if it does, it
> could be a problem for us to pass the TCK. Are you saying it might be
> possible to somehow borrow a verifier from reference VM? :)
I can always dream, can't I?
>
>>
>> >
>> > (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 (this is
>> > required by JNI/JVMTI spec).
>>
>> What does it do now?
>
> Most likely it will exit with assert in the debug mode and will crash
> in the release mode. The code currently does malloc() and then
> memset()
> (I was looking at oh_allocate_object_handle() function in
> object_handle.cpp. It seems it is eventually called if one does
> NewGlobalRef(), for example).
> RI fails more gently in that case saying something like:
> "Exception in thread "main" java.lang.OutOfMemoryError: requested 152
> bytes for CHeapObj-new. Out of swap space?"
An OOM would be good here... it goes without saying...
geir
---------------------------------------------------------------------
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] what's next?
Posted by Andrey Chernyshev <a....@gmail.com>.
On 6/29/06, Geir Magnusson Jr <ge...@pobox.com> 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:
> >
> > (1) Complete Java bytecode verifier
> > Class structure verification and subroutines (e.g. finally blocks) has
> > to be added to the bytecode verifier in order to make it
> > full-functional (as required by JVMS spec).
>
> Do you think that it will be complete at that point? It's my
> understanding that it's fairly difficult and subtle to get it right.
> I'm hoping that we can just get that from Sun :)
Actually I'm not sure if RI is doing all of this, but if it does, it
could be a problem for us to pass the TCK. Are you saying it might be
possible to somehow borrow a verifier from reference VM? :)
>
> >
> > (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 (this is
> > required by JNI/JVMTI spec).
>
> What does it do now?
Most likely it will exit with assert in the debug mode and will crash
in the release mode. The code currently does malloc() and then
memset()
(I was looking at oh_allocate_object_handle() function in
object_handle.cpp. It seems it is eventually called if one does
NewGlobalRef(), for example).
RI fails more gently in that case saying something like:
"Exception in thread "main" java.lang.OutOfMemoryError: requested 152
bytes for CHeapObj-new. Out of swap space?"
Thanks,
Andrey.
>
> geir
>
> ---------------------------------------------------------------------
> 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
>
>
--
Andrey Chernyshev
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] what's next?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
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 verification and subroutines (e.g. finally blocks) has
> to be added to the bytecode verifier in order to make it
> full-functional (as required by JVMS spec).
Do you think that it will be complete at that point? It's my
understanding that it's fairly difficult and subtle to get it right.
I'm hoping that we can just get that from Sun :)
>
> (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 �C OutOfMemoryException must be thrown (this is
> required by JNI/JVMTI spec).
What does it do now?
geir
---------------------------------------------------------------------
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] what's next?
Posted by Andrey Chernyshev <a....@gmail.com>.
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. finally blocks) has
to be added to the bytecode verifier in order to make it
full-functional (as required by JVMS spec).
(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 �C OutOfMemoryException must be thrown (this is
required by JNI/JVMTI spec).
(3) Eliminate C++ exceptions support
��urrently some parts of VM and native part of kernel classes are
complied with C++ exception support which gives an extra overhead. One
of the issues is that some parts are using MS implementation of STL
which requires C++ exception support. MS STL has to be replaced with
something else.
(4) Destructive stack unwinding - perhaps it needs to be eliminated from VM.
In certain cases VM performs stack unwinding up to the nearest M2N
frame and just jumps to that point. If some C++ objects are available
on stack, destructors for these objects won't be called. This may
affect VM stability under stress conditions.
(5) Unicode support
Currently VM doesn't support classes/field/names which utilize
character other than ASCII. Handling of the Unicode names will likely
be needed for certification. This impacts class loader, natives
support, JNI and JVMTI components. Another issue is that VM would not
understand the command line args (like class name and start arguments)
if they are written with unicode characters.
(6) String internal implementation could be moved to Java.
Internal representation of strings is currently kept in the native
class loading code (string pool). To enable efficient resource
deallocation, they better be moved to Java code such that GC/class
unloading can operate with strings more efficiently.
(7) Unify C Memory management.
Native memory is currently allocated in DRLVM by ~10 different means
at different places. Some of examples are using APR memory pools, C
mallocs, C++ new operator e.t.c. This complicates the communication
between the different modules within DRLVM since there is no
consideration how to deallocate the memory being allocated by other
component and may trigger memory leaks in the system.
I wonder if there could be any ideas how the memory management
approach could be unified in the DRLVM? It may also help to monitor
and eliminate possible memory leaks in the system.
(8) Complete JNI and JVMTI implementations.
JNI and JVMTI specs are currently not completely implemented. For
example, JNI is missing weak references implementation, invocation
API. JVMTI is missing RedefineClasses function.
...
There certainly other gaps which I'm not aware of ;)
Any thoughts which of the above could be worth doing?
Thanks,
Andrey.
On 6/21/06, Rana Dasgupta <rd...@gmail.com> wrote:
> On 6/20/06, Geir Magnusson Jr <ge...@pobox.com> 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 next, I guess we mean in the relatively
> near future...Some thoughts that come to mind in addition to 1.5 are:
> 1. We should start running classlibraries and existing api tests against
> the DRLVM bits. This is sure to identify bugs/issues that will need
> addressing.
> 2. We need to achieve completeness in the DRLVM VM functionality.....we
> don't handle stack overflows well, efficient unmanagd heap management
> issues, there is functional completenes needed in the verifier, optimized
> locks( thin, deflatable, jit optimized ), improvements in JVMTI support as
> Gregory points out.
> 3. In garbage collection, one thread that Weldon has already started is
> MMTk integration which looks promising, but while we finish that work, it
> may also make sense to substitute the existing rudimentary GC with a more
> functional one with better performance that can work as the default GC
> outside the MMTk integrated suite.
> 4. We should also look at enhancements to the JITs ...and other than support
> for new platforms ( 64 bit , down level platforms that support x87 but not
> SSE* instructions..based on the minimum machine model we want to support eg
> a pentium III running Windows/Linux )some of this work would benefit from
> performance guidance...helpers should be inlined, some of the
> optimizations eg., devirtualization perfected, polling to support
> collection should consume less overhead, more optimized JNI invocation at
> some point.
> 5. This is also in reference to the other thread you started about goals for
> Harmony, it may help to establish some vectors that are important for us in
> Harmony eg., among...1.5 and TCK compatibility, performance( benchmarking ),
> startup time, memory footprint, and that in some sense will determine the
> priorities. The work to be done will fall out of this.
>
> Feedback most welcome :-)
>
> Thanks,
> Rana
>
>
> ---------------------------------------------------------------------
> 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
>
>
--
Andrey Chernyshev
Intel Middleware Products Division
Re: [drlvm] what's next?
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x198 day of Apache Harmony Rana Dasgupta wrote:
> On 22 Jun 2006 16:16:24 +0700, Egor Pasko <eg...@gmail.com> 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):
> >
> > >* Devirtualization improvements
> >
> > >Currently DRLVM does *not* devirtualize interface calls.
> >
> > >A not-so-quick hack for the start: make a class-test based on the
> > >class that
> > >a) implements the interface
> > >b) has the the method invoked with some instance (first invocations are
> > >easy to register in JIT since they initiate compilation phase)
>
> Sounds look a sensible first approach. It would be good to find a micro or a
> workload that we can use to demonstrate the existence of the interface
> virtual method call perf problem, and then the improvement.
OK, that's a good point. I'll try to reach this kind of a workload.
Does a microbenchmark make sense to find it's place in JIRA?
> >In future, a more sophisticated heuristic would be interesting to
> > >experiment with. Ideas?
> >
> > >* Back-Branch-Polling (BBP) improvements
> >
> > >BBP is an optimization pass that inserts extra helper-function-calls
> > >(safepoints) in loops to make them interruptable
> > >(suspendable). Necessary for Thread::stop() and quick response to
> > >GC.
> >
> > >In DRLVM BBP introduces an overhead about 1-2% (on single-threaded
> > >workloads), which could be optimized out. Currently, backedges are
> > >polled for non-interruptable loops. We could detect finite loops and
> > >poll them more wisely.
>
> Same suggestion, it would be nice to acquire this single threaded workload(
> SpecJVM?) that demonstrates this 1-2% loss first.
Hm, a subject to find out too..
> >BTW, Jrockit sometimes forgets about polling. Harmony should be better.
> > >Yet, we can turn BBP off with a quick experimental option:
> > > -Xjit ia32::bbp=off{0},jet::no_bbp=true
>
>
> Where are you proposing this optimization? Does the BBP exist in the DRLVM
> codebase in the .JET jit only ? (Why two flags to turn it off, BTW :-) )
Two flags: first for Jitrino.OPT, second for Jitrino.JET
It is Jitrino.OPT that needs the improvement since JET has too little
opportunities to optimize like that.
> >* Over-synchronization removal
> >
> > >Nested synchronization blocks on the same object can be removed. Not
> > >done in DRLVM yet.
>
>
> It would be good to identify some broader Harmony goals/targets at some
> point ...other than compatibility and functional completeness. Eg., where do
> we want to be as compared to RI or other VM's in performance,
> responsiveness, etc.? For example BBP above can be seen as a
> responsiveness optimization, so it may be OK even if it shows no perf
> gain, ie., if the optimization can just eliminate the loss. Depends on where
> we want to go.... Initially of course any improvement is good :-)
OK, I know, we need a set of corresponding benchmarks for that too :)
BTW, responsiveness has it's impact on performance when we run
multithreaded code. So, we can talk only about performance on certain
workloads (and, yes, certain hardware...)
--
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] what's next?
Posted by Rana Dasgupta <rd...@gmail.com>.
On 22 Jun 2006 16:16:24 +0700, Egor Pasko <eg...@gmail.com> 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):
>
> >* Devirtualization improvements
>
> >Currently DRLVM does *not* devirtualize interface calls.
>
> >A not-so-quick hack for the start: make a class-test based on the
> >class that
> >a) implements the interface
> >b) has the the method invoked with some instance (first invocations are
> >easy to register in JIT since they initiate compilation phase)
Sounds look a sensible first approach. It would be good to find a micro or a
workload that we can use to demonstrate the existence of the interface
virtual method call perf problem, and then the improvement.
>In future, a more sophisticated heuristic would be interesting to
> >experiment with. Ideas?
>
> >* Back-Branch-Polling (BBP) improvements
>
> >BBP is an optimization pass that inserts extra helper-function-calls
> >(safepoints) in loops to make them interruptable
> >(suspendable). Necessary for Thread::stop() and quick response to
> >GC.
>
> >In DRLVM BBP introduces an overhead about 1-2% (on single-threaded
> >workloads), which could be optimized out. Currently, backedges are
> >polled for non-interruptable loops. We could detect finite loops and
> >poll them more wisely.
Same suggestion, it would be nice to acquire this single threaded workload(
SpecJVM?) that demonstrates this 1-2% loss first.
>BTW, Jrockit sometimes forgets about polling. Harmony should be better.
> >Yet, we can turn BBP off with a quick experimental option:
> > -Xjit ia32::bbp=off{0},jet::no_bbp=true
Where are you proposing this optimization? Does the BBP exist in the DRLVM
codebase in the .JET jit only ? (Why two flags to turn it off, BTW :-) )
>* Over-synchronization removal
>
> >Nested synchronization blocks on the same object can be removed. Not
> >done in DRLVM yet.
It would be good to identify some broader Harmony goals/targets at some
point ...other than compatibility and functional completeness. Eg., where do
we want to be as compared to RI or other VM's in performance,
responsiveness, etc.? For example BBP above can be seen as a
responsiveness optimization, so it may be OK even if it shows no perf
gain, ie., if the optimization can just eliminate the loss. Depends on where
we want to go.... Initially of course any improvement is good :-)
>
>
> --
> 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] what's next?
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x18F day of Apache Harmony Rana Dasgupta wrote:
> On 6/20/06, Geir Magnusson Jr <ge...@pobox.com> 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,
>
> [...]
>
> 4. We should also look at enhancements to the JITs ...and other than support
> for new platforms ( 64 bit , down level platforms that support x87 but not
> SSE* instructions..based on the minimum machine model we want to support eg
> a pentium III running Windows/Linux )some of this work would benefit from
> performance guidance...helpers should be inlined, some of the
> optimizations eg., devirtualization perfected, polling to support
> collection should consume less overhead, more optimized JNI invocation at
> some point.
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):
* Devirtualization improvements
Currently DRLVM does *not* devirtualize interface calls.
A not-so-quick hack for the start: make a class-test based on the
class that
a) implements the interface
b) has the the method invoked with some instance (first invocations are
easy to register in JIT since they initiate compilation phase)
In future, a more sophisticated heuristic would be interesting to
experiment with. Ideas?
* Back-Branch-Polling (BBP) improvements
BBP is an optimization pass that inserts extra helper-function-calls
(safepoints) in loops to make them interruptable
(suspendable). Necessary for Thread::stop() and quick response to
GC.
In DRLVM BBP introduces an overhead about 1-2% (on single-threaded
workloads), which could be optimized out. Currently, backedges are
polled for non-interruptable loops. We could detect finite loops and
poll them more wisely.
BTW, Jrockit sometimes forgets about polling. Harmony should be better.
Yet, we can turn BBP off with a quick experimental option:
-Xjit ia32::bbp=off{0},jet::no_bbp=true
* Over-synchronization removal
Nested synchronization blocks on the same object can be removed. Not
done in DRLVM yet.
So, any compiler-guy interested in JIT enhancements is welcome to
participate. Any JIT-related questions are welcome too.
Voluteers? :)
[1] LIL: An Architecture-Neutral Language for Virtual-Machine Stubs
(http://www.usenix.org/events/vm04/tech/full_papers/glew/glew_html/index.html)
--
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] what's next?
Posted by Rana Dasgupta <rd...@gmail.com>.
On 6/20/06, Geir Magnusson Jr <ge...@pobox.com> 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 next, I guess we mean in the relatively
near future...Some thoughts that come to mind in addition to 1.5 are:
1. We should start running classlibraries and existing api tests against
the DRLVM bits. This is sure to identify bugs/issues that will need
addressing.
2. We need to achieve completeness in the DRLVM VM functionality.....we
don't handle stack overflows well, efficient unmanagd heap management
issues, there is functional completenes needed in the verifier, optimized
locks( thin, deflatable, jit optimized ), improvements in JVMTI support as
Gregory points out.
3. In garbage collection, one thread that Weldon has already started is
MMTk integration which looks promising, but while we finish that work, it
may also make sense to substitute the existing rudimentary GC with a more
functional one with better performance that can work as the default GC
outside the MMTk integrated suite.
4. We should also look at enhancements to the JITs ...and other than support
for new platforms ( 64 bit , down level platforms that support x87 but not
SSE* instructions..based on the minimum machine model we want to support eg
a pentium III running Windows/Linux )some of this work would benefit from
performance guidance...helpers should be inlined, some of the
optimizations eg., devirtualization perfected, polling to support
collection should consume less overhead, more optimized JNI invocation at
some point.
5. This is also in reference to the other thread you started about goals for
Harmony, it may help to establish some vectors that are important for us in
Harmony eg., among...1.5 and TCK compatibility, performance( benchmarking ),
startup time, memory footprint, and that in some sense will determine the
priorities. The work to be done will fall out of this.
Feedback most welcome :-)
Thanks,
Rana
---------------------------------------------------------------------
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] what's next?
Posted by Rana Dasgupta <rd...@gmail.com>.
On 6/21/06, Gregory Shimansky <gs...@gmail.com> 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 Jitrino.JET will be enabled automatically.
>
> Perfect timing! It may be easier for unoptimized code but ties in really
> nicely with the proposed MMTk and WB work around .Jet etc.
>You can also encounter bugs which happen because of not really well tested
> >code of debugger interferes into exeuction of GC :)
No worries, we will then use your debugger to debug its own problems :-)
Re: [drlvm] what's next?
Posted by Gregory Shimansky <gs...@gmail.com>.
2006/6/21, Weldon Washburn <we...@gmail.com>:
>
> On 6/20/06, Gregory Shimansky <gs...@gmail.com> 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 classfiles, so we
> can
> > > > make the switch throughout the project.
> > > >
> > > >
> > > >
> > > > Thoughts? What else?
> > >
> > > As far as I can tell, general DRLVM development directions are
> > > * more features, e.g. JVMTI
> >
> > I am also trying to improve the current JVMTI support which works on
> > interpreter only at the moment.
> >
> > I am trying to prepare a patch with implementation of some debugging
> functions
> > for JIT mode. It should contain stack trace group of functions,
> exception,
> > method enter/exit events and breakpoints using int3 trap in the compiled
> > code.
>
> Excellent. Will it work with Jitrino.JET?
>
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 Jitrino.JET will be enabled automatically.
It would be great if this debugger could be used during the port of MMTk.
>
You can also encounter bugs which happen because of not really well tested
code of debugger interferes into exeuction of GC :)
--
Gregory Shimansky, Intel Middleware Products Division
Re: [drlvm] what's next?
Posted by Weldon Washburn <we...@gmail.com>.
On 6/20/06, Gregory Shimansky <gs...@gmail.com> 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 classfiles, so we can
> > > make the switch throughout the project.
> > >
> > >
> > >
> > > Thoughts? What else?
> >
> > As far as I can tell, general DRLVM development directions are
> > * more features, e.g. JVMTI
>
> I am also trying to improve the current JVMTI support which works on
> interpreter only at the moment.
>
> I am trying to prepare a patch with implementation of some debugging functions
> for JIT mode. It should contain stack trace group of functions, exception,
> method enter/exit events and breakpoints using int3 trap in the compiled
> code.
Excellent. Will it work with Jitrino.JET? It would be great if this
debugger could be used during the port of MMTk.
>
> --
> 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
>
>
--
Weldon Washburn
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] what's next?
Posted by Gregory Shimansky <gs...@gmail.com>.
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.
> >
> >
> >
> > Thoughts? What else?
>
> As far as I can tell, general DRLVM development directions are
> * more features, e.g. JVMTI
I am also trying to improve the current JVMTI support which works on
interpreter only at the moment.
I am trying to prepare a patch with implementation of some debugging functions
for JIT mode. It should contain stack trace group of functions, exception,
method enter/exit events and breakpoints using int3 trap in the compiled
code.
--
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] what's next?
Posted by Salikh Zakirov <Sa...@Intel.com>.
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 DRLVM development directions are
* more features, e.g. JVMTI
* higher performance: VM, JIT, GC
Personally, I am going to look into following areas (in order)
- extend JVMTI support in DRLVM: "Heap" group of functions.
I have some code working already,
but not yet ready for filing JIRA with patch yet.
- play with class unloading and see what are the design consequences
- then do a generational garbage collector (from scratch)
I looked into this a little bit, but not quite sure when I'll be able
to get something working.
---------------------------------------------------------------------
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] what's next?
Posted by Nathan Beyer <nb...@kc.rr.com>.
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
array elements as though they were volatile.
DRLVM has a class stubbed for CAS [1] and lock support [2], the later of
which I'd probably suggest moving to a VMI package. The piece about the
set/get of array elements in a volatile fashion can be seen in the
AtomicIntegerArray [3] class; look for putIntVolatile. I'm not completely
clear on the details, but it seems to be necessary as array elements of an
array aren't normally guaranteed to be treated like volatile fields and this
method guarantees that. (I'm still trying to dig my way through the Java
Memory Model stuff, so bear with me.)
Do the current DRLVM build scripts build these utility classes [1][2] and
their native counterparts? I was having trouble running the build scripts
the other day (the Eclipse download killed me) and haven't had much time to
experiment.
The other piece that might need to be considered is how to handle AtomicLong
on platforms that can't do 64-bit CAS natively. I was hoping this would be
handled by the VM, but Doug's code [4] seems to handle it in the class
itself.
-Nathan
[1]
http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/vmcor
e/src/kernel_classes/javasrc/org/apache/harmony/util/concurrent/Atomics.java
?view=markup
[2]
http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/vmcor
e/src/kernel_classes/javasrc/java/util/concurrent/locks/LockSupport.java?vie
w=markup
[3]
http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concu
rrent/atomic/AtomicIntegerArray.java?rev=1.25&content-type=text/vnd.viewcvs-
markup
[4]
http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concu
rrent/atomic/AtomicLongFieldUpdater.java?rev=1.23&content-type=text/vnd.view
cvs-markup
> -----Original Message-----
> From: Geir Magnusson Jr [mailto:geir@pobox.com]
>
> 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
---------------------------------------------------------------------
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