Re: Bug#156407: ITP: free-java-sdk -- Complete Java SDK environment consising of free Java tools
In addition to Mark's and Tom's comments, I'd like to address JNI vs CNI.
Grzegorz Prokopski wrote:
Also, SableVM implements the invocation interface, and has clean
support for native code through the "standard" JNI interface.
So of course does GCJ.
>>Now, GIJ's people main objection to JNI (instead of their custom CNI) is
that it is slow. Yet, even though they have potential race
conditions, and their use of CNI, SableVM is at least 2X faster than
GIJ on all benchmarks I've tested.
This is meaningless. CNI is optimized for compiled code, not
interpreted code.
We jave never put much effort into GIJ bytecode interpreter. We would
like to replace it by a good JIT-based interpreter. Alternatively, if
SableVM is much faster, and there are no licensing complications, then
it might be nice to replace the the GIJ interpreter by SableVM. This
would be good chunk of work, but it should be less work than having
competing GIJ/SableVM projects.
As Mark says: The GCJ project is not about any specific pieces, except
that we use Gcc as part of an complete Java environment.
This goes without talking about the limitations of CNI. It is
*incompatible* with: moving collectors, bidirectional object layout,
long running CNI code (because a request for GC would wait
indefinitely and possibly lockup the VM). etc.
I don't believe any of those are inherent limitations. CNI is just
an interface (an C++-based API) - there is no reason in principle why
G++ could not be taught about moving collectors or bidirectional object
layout for Java classes. (G++ does know that Java classes are different
from C++ classes.)
Starting in the fall, yes. There's the whole Sable project (which has
brought the Soot bytecode analysis framework to the world) behind
SableVM. This means at least 3 faculty-researcher and their graduate
and undergradute students.
I welcome the SableVM to consider whether their tchniques and
code could be consistent with GCJ and produce something better than
either. We would welcome such help.
--
--Per Bothner
per@bothner.com http://www.bothner.com/per/
Reply to: