You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Etienne Gagnon <eg...@sablevm.org> on 2006/03/28 16:57:43 UTC
VMI Questions
Hi Weldon,
I've started reading about the VMI. While my initial goal would be to
get SableVM to work with Harmony as a drop-in replacement for IBM's VM,
I have some questions about some assumptions of the VMI.
In particular, I would like to understand the motivation for the
implicit direct link from the hyluni library to the VM library. In
other words, it seems logical to me that the VM library would cause the
dynamic loading of the hyluni library. On the other hand, I don't
understand why the hyluni library assumes that it will be necessarily
loaded by a specific VM library sitting in a particular directory.
This assumption has an important side effect. The hyluni library
assumes that it can simply call VMI_* global functions which are
resolved by the dynamic linker. Personally, I would have done things
some other way; I would either have had the VM library call a
VMI_SetVMI() function exported by the hyluni library and requested the
the VM library call it, or, better, I would have done like the debug
interface and requested the VMI function table through the GetEnv
function of the invocation interface :
(*jvm)->GetEnv(jvm, &vmi, VMI_VERSION_1);
This would seem the cleanest approach to me. The only problem is to
avoid clashing with Sun's constants.
The problem I see, with the current approach, is that it makes it
impossible to provide distinct VM libraries for different purposes
(debugging, faster execution, profiling, ...), as they can't be all in a
single file.
Etienne
Weldon Washburn wrote:
> ... In any case, feel free to borrow parts of kernel_path that
> make sense. Also, feel free to ask questions about it.
--
Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
Re: VMI Questions
Posted by Tim Ellison <t....@gmail.com>.
also available via :
http://incubator.apache.org/harmony/subcomponents/classlibrary
Regards,
Tim
Mark Hindess wrote:
> The main document on porting is at:
>
> http://tinyurl.com/jfljq
>
> The VM Interface is described at:
>
> http://tinyurl.com/gtd64
>
> and the required kernel classes are described at:
>
> http://tinyurl.com/hawkl
>
> Regards,
> Mark.
>
> On 3/29/06, Enrico Migliore <en...@fatti.com> wrote:
>> Etienne Gagnon wrote:
>>
>>> Hi Weldon,
>>>
>>> I've started reading about the VMI. While my initial goal would be to
>>> get SableVM to work with Harmony as a drop-in replacement for IBM's VM,
>>> I have some questions about some assumptions of the VMI.
>>>
>>>
>> Hi Etienne,
>>
>> could you tell me where I can find the documentation of the VMI?
>>
>> thanks a bunch,
>> Enrico
>
> --
> Mark Hindess <ma...@googlemail.com>
> IBM Java Technology Centre, UK.
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: SableVM and Harmony Class library
Posted by Paulex Yang <pa...@gmail.com>.
Enrico
Personally I think only step 1 and 2 is enough to make SableVM run
Harmony classlib, then the sample launcher in SVN should can launch the
SableVM.
The step 3 is "better have" so that the VM can be more easily ported to
other platform by leveraging the portlib's interface.
Enrico Migliore wrote:
> Hi,
>
>> The main document on porting is at:
>>
>> http://tinyurl.com/jfljq
>>
>> The VM Interface is described at:
>>
>> http://tinyurl.com/gtd64
>>
>> and the required kernel classes are described at:
>>
>> http://tinyurl.com/hawkl
>>
>> Regards,
>> Mark.
>>
>>
>
> Hi all,
>
> I'm reading the documentation above and, at first glance, it seems to
> me that interfacing the SableVM to the Harmony Class Library is a task
> that involves the following steps:
>
> step 1
> ------
> The SableVM /has to/ implement the VM interface, in order for the
> Harmony Class Library to "find" the entry points of a certain number
> of native functions. The entry points are documented here:
>
> http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/group__VMInterface.html
>
>
>
> step 2
> ------
> The SableVM has to implement a Java interface, which means that is
> /has to/ implement in C a small set of Java classes, documented in the
> following link:
>
> http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/kernel_doc/html/index.html#KernelJavaClasses
>
>
>
> step 3
> ------
> The SableVM, in terms of native functions, /should/ call only the
> native functions of the port layer, used by the Harmony Class Library:
>
> http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/group__Port.html#CreatePortLib
>
>
>
> Comments are welcome :-)
>
> Enrico
>
>
>
>
>
--
Paulex Yang
China Software Development Lab
IBM
Re: SableVM and Harmony Class library
Posted by Tim Ellison <t....@gmail.com>.
That's right, there is no hard requirement that these classes be written
in any particular language. Of course they have to provide Java method
interfaces to the rest of the class library so...
In the IBM VM they are written as Java classes with some native methods.
Harmony has compile-against stubs for these types in the 'kernel' module
so we can build the remainder of the class library. Some of those stubs
have parts of implementations that may be useful if people don't have a
start of these types already. Weldon has been writing code to bridge
the harmony kernel classes to the Classpath VM interface.
Regards,
Tim
Etienne Gagnon wrote:
> Up to now, SableVM has managed not to implement any class in C. Of
> course, one could question the "efficiency" of doing so, but hardly
> question the "maintainability" of it. :-)
>
> So, I do not think that step 2 is a hard requirement. (Methods, of
> course, can be native).
>
> Etienne
>
> Enrico Migliore wrote:
>> step 2
>> The SableVM has to implement a Java interface, which means that is /has
>> to/ implement in C a small set of Java classes, documented in the
>> following link:
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: SableVM and Harmony Class library
Posted by Etienne Gagnon <eg...@sablevm.org>.
Up to now, SableVM has managed not to implement any class in C. Of
course, one could question the "efficiency" of doing so, but hardly
question the "maintainability" of it. :-)
So, I do not think that step 2 is a hard requirement. (Methods, of
course, can be native).
Etienne
Enrico Migliore wrote:
> step 2
> The SableVM has to implement a Java interface, which means that is /has
> to/ implement in C a small set of Java classes, documented in the
> following link:
--
Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
Re: SableVM and Harmony Class library
Posted by Tim Ellison <t....@gmail.com>.
Tim Ellison wrote:
> The VMLS functions are designed for VM-global vars. The class library
> natives use VMLS rather than process-global statics so we can have
> multiple VM instances co-existing in the same process. I'll check in an
> example of a VMLS implementation you can use.
If you take a look in the classlib/trunk/native-src/shared/vmls/
directory (at repo revision >= 390442) you will now find a reference
implementation of the VM local storage functions defined in the VMI.
Any questions just shout.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
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: SableVM and Harmony Class library
Posted by Tim Ellison <t....@gmail.com>.
Sounds right (modulo step #2 comment made elsewhere).
In case you missed it: the portlib, VM local storage(VMLS), and
ZipCachePool (that are returned by functions in the VMI function
table[1]) are provided as part of Harmony code base.
The portlib function table is created by the java launcher and (a
pointer) passed through to the VM as a vm_args during JNI_CreateJavaVM as:
#define PORT_LIB_OPTION "_org.apache.harmony.vmi.portlib"
The VMLS functions are designed for VM-global vars. The class library
natives use VMLS rather than process-global statics so we can have
multiple VM instances co-existing in the same process. I'll check in an
example of a VMLS implementation you can use.
The ZipCachePool is used to share open zip/jar files between the VM and
classlibrary, you can create it using the functions in the
include/zipsup.h, and stash it like this:
myJavaVM->zipCachePool = zipCachePool_new(portLibrary);
Regards,
Tim
[1]
http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/structVMInterfaceFunctions__.html#_details
Enrico Migliore wrote:
> Hi,
>
>> The main document on porting is at:
>>
>> http://tinyurl.com/jfljq
>>
>> The VM Interface is described at:
>>
>> http://tinyurl.com/gtd64
>>
>> and the required kernel classes are described at:
>>
>> http://tinyurl.com/hawkl
>>
>> Regards,
>> Mark.
>>
>>
>
> Hi all,
>
> I'm reading the documentation above and, at first glance, it seems to me
> that interfacing the SableVM to the Harmony Class Library is a task that
> involves the following steps:
>
> step 1
> ------
> The SableVM /has to/ implement the VM interface, in order for the
> Harmony Class Library to "find" the entry points of a certain number of
> native functions. The entry points are documented here:
>
> http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/group__VMInterface.html
>
>
>
> step 2
> ------
> The SableVM has to implement a Java interface, which means that is /has
> to/ implement in C a small set of Java classes, documented in the
> following link:
>
> http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/kernel_doc/html/index.html#KernelJavaClasses
>
>
>
> step 3
> ------
> The SableVM, in terms of native functions, /should/ call only the native
> functions of the port layer, used by the Harmony Class Library:
>
> http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/group__Port.html#CreatePortLib
>
>
>
> Comments are welcome :-)
>
> Enrico
>
>
>
>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
JCHEVM
Posted by Enrico Migliore <en...@fatti.com>.
Mark Hindess wrote:
>On 4/1/06, Enrico Migliore <en...@fatti.com> wrote:
>
>
>>I, and others, ported JCHEVM to Cygwin, during the past 2 months; there
>>are still a couple of things to fix, but the main work is done.
>>
>>The port was made in order to be able to "study" JCHEVM on the Windows
>>platform. I understand, in fact, that having the Cygwin layer running on
>>top of Windows may compromise speed performances of any JVM. In
>>principle, the "-no-cygwin" option of GCC should allow us to produce an
>>executable that doesn't need the cygwin1.dll library, but:
>>
>> 1. I haven't yet tried to enable it
>> 2. The functionality of cygwin1.dll might be embedded in the
>>executable file (in this case the Cygwin layer is hidden in the .exe)
>>
>>
>
>I don't think it does include cygwin in any form. It builds against
>the mingw libraries instead.
>
>Regards,
> Mark.
>
>--
>Mark Hindess <ma...@googlemail.com>
>IBM Java Technology Centre, UK.
>
>
>
Hi Mark,
that's interesting and I think it's worth trying to build JCHEVM in
that way.
I don't know though if Windows issues the signals that JCHEVM needs....
Enrico
---------------------------------------------------------------------
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: SableVM or JCHEVM?
Posted by Mark Hindess <ma...@googlemail.com>.
On 4/1/06, Enrico Migliore <en...@fatti.com> wrote:
>
> I, and others, ported JCHEVM to Cygwin, during the past 2 months; there
> are still a couple of things to fix, but the main work is done.
>
> The port was made in order to be able to "study" JCHEVM on the Windows
> platform. I understand, in fact, that having the Cygwin layer running on
> top of Windows may compromise speed performances of any JVM. In
> principle, the "-no-cygwin" option of GCC should allow us to produce an
> executable that doesn't need the cygwin1.dll library, but:
>
> 1. I haven't yet tried to enable it
> 2. The functionality of cygwin1.dll might be embedded in the
> executable file (in this case the Cygwin layer is hidden in the .exe)
I don't think it does include cygwin in any form. It builds against
the mingw libraries instead.
Regards,
Mark.
--
Mark Hindess <ma...@googlemail.com>
IBM Java Technology Centre, UK.
---------------------------------------------------------------------
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: SableVM or JCHEVM?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Enrico Migliore wrote:
> Hi,
>
> I've followed the discussion about the SableVM code donation to the
> Apache foundation, but I still need to understand a couple of things:
>
>
> SableVM or JCHEVM?
> ------------------------
> At the moment there two virutual machines: which of the two should one
> choose to work on?
>
> SableVM svn access
> ---------------------
> I can't find the SableVM repository in the Harmony site, can somebody
> address me where to find it?
SableVM in it's entirety has not been donated to the ASF - rather, it
was relicensed 'in place' where it is, and will remain there for the
time being.
That said, one of our goals was to bridge communities through
architecture and technology, and I think we've done that here.
Work on what interests you. We definitely need go get JCHEVM working
with the Harmony classlibrary, and Weldon's bridge is a great first
step, and one I think should be completed, because there are other VMs
that could use it (in theory) to be able to work with Harmony classlib
as well as the GNU Classlib.
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: SableVM or JCHEVM?
Posted by Enrico Migliore <en...@fatti.com>.
Hi Etienne,
>2 things:
>
>1- SableVM has, from the beginning, put portability as one of its main
>objectives. This is why we went all the way to write an inline-threaded
>interpreter engine, as to get as much speed without sacrificing
>portability and requiring knowledge of intimate details of the target
>platform (assembly language, ABI, etc.). We also kept easier to port
>interpreters (switch and direct threaded).
>
Good.
>The switch-threaded
>interpreter is a pure ISO C interpreter, does not emit a single gcc
>warning with -pedantic on.
>
That's what I like most: source code that compiles clean :-)
I bet that the -ansi flag does the same.
>The other two interpreters require gcc
>extensions (and/or a little inline-assembly code).
>
>2- The SableVM project will not be abandoned any time soon. It is one
>of my main research vehicles, and I am a relatively young tenured
>professor at UQAM. Unlike many other open source JVMs which are
>primarily the project of students, SableVM is a project driven by a paid
>professor.
>
>
>
I see...
>You should chose to work on the project that you feel most comfortable
>to contribute to. I don't know of any open-source VM that would reject
>contributions (at least, without a good reason). :-)
>
>Have fun!
>
>Etienne
>
>
I'll download and build the SableVM source code and play a little with it.
ciao,
Enrico
---------------------------------------------------------------------
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: SableVM or JCHEVM?
Posted by Etienne Gagnon <eg...@sablevm.org>.
Hi Enrico,
Enrico Migliore wrote:
> My ultimate goal, is contributing to the development of a reliable JVM
> which will run on the ARM platform, because I work in the embedded
> systems area. I don't care if such a goal will be achieved in 2 or 3
> years, the only thing I care is not to waste my time in volunteering on
> a thing that may be abandoned.
2 things:
1- SableVM has, from the beginning, put portability as one of its main
objectives. This is why we went all the way to write an inline-threaded
interpreter engine, as to get as much speed without sacrificing
portability and requiring knowledge of intimate details of the target
platform (assembly language, ABI, etc.). We also kept easier to port
interpreters (switch and direct threaded). The switch-threaded
interpreter is a pure ISO C interpreter, does not emit a single gcc
warning with -pedantic on. The other two interpreters require gcc
extensions (and/or a little inline-assembly code).
2- The SableVM project will not be abandoned any time soon. It is one
of my main research vehicles, and I am a relatively young tenured
professor at UQAM. Unlike many other open source JVMs which are
primarily the project of students, SableVM is a project driven by a paid
professor.
You should chose to work on the project that you feel most comfortable
to contribute to. I don't know of any open-source VM that would reject
contributions (at least, without a good reason). :-)
Have fun!
Etienne
--
Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
Re: SableVM or JCHEVM?
Posted by Enrico Migliore <en...@fatti.com>.
Hi Etienne,
>Hi Enrico,
>
>SableVM's trunk ( svn co svn://svn.sablevm.org/sablevm/trunk ) is now
>licensed under the Apache License 2.0. As SableVM is maintained by a
>number of developers, but is also used by many of my students to develop
>new VM components and do research, it was deemed more appropriate not to
>put SableVM in Harmony's repository for the following reasons:
>
>1- Harmony's repository is not the appropriate place for creating many,
>many branches to do academic research on VMs.
>
>2- Keeping a clear Intellectual Property trail would be a nightmare if
>SableVM's development and maintenance was spread over two distinct
>repositories.
>
>3- According to Geir, integration of the VM into Harmony's repository is
>not a preriquisite for J2SE certification.
>
>
>
ok, got it :-)
>The SableVM project has chosen to integrate our VM with Harmony's class
>library. In particular, I have started with a student to implement
>Harmony's VMI. Our objective is to fully adapt SableVM to work with
>Harmony's VMI "as is". If I understand JCHEVM's approach, they are
>going in a different direction; they are developing a "GNU Classpath
>compatibility layer" so that Classpath-based VMs could migrate to
>Harmony with little effort.
>
>
>
ok
>SableVM's goal is to become entirely dependent on Harmony's LUNI
>packages, as we do like Harmony's VMI. This will have the consequence
>of breaking SableVM's compatibility to Classpath's LUNI packages. Yet
>we do not see this as a problem; you will still be able to use
>Classpath other packages with SableVM (awt, swing, etc.).
>
>So, if you wish to contribute to SableVM for helping with the Harmony
>integration, please join us at http://sablevm.org. If you are
>interested, we'll use the SableVM developer mailing-list to coordonate
>the Harmony adaptation effort.
>
>
>
I, and others, ported JCHEVM to Cygwin, during the past 2 months; there
are still a couple of things to fix, but the main work is done.
The port was made in order to be able to "study" JCHEVM on the Windows
platform. I understand, in fact, that having the Cygwin layer running on
top of Windows may compromise speed performances of any JVM. In
principle, the "-no-cygwin" option of GCC should allow us to produce an
executable that doesn't need the cygwin1.dll library, but:
1. I haven't yet tried to enable it
2. The functionality of cygwin1.dll might be embedded in the
executable file (in this case the Cygwin layer is hidden in the .exe)
My ultimate goal, is contributing to the development of a reliable JVM
which will run on the ARM platform, because I work in the embedded
systems area. I don't care if such a goal will be achieved in 2 or 3
years, the only thing I care is not to waste my time in volunteering on
a thing that may be abandoned.
Enrico
---------------------------------------------------------------------
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: SableVM or JCHEVM?
Posted by Etienne Gagnon <eg...@sablevm.org>.
Hi Enrico,
SableVM's trunk ( svn co svn://svn.sablevm.org/sablevm/trunk ) is now
licensed under the Apache License 2.0. As SableVM is maintained by a
number of developers, but is also used by many of my students to develop
new VM components and do research, it was deemed more appropriate not to
put SableVM in Harmony's repository for the following reasons:
1- Harmony's repository is not the appropriate place for creating many,
many branches to do academic research on VMs.
2- Keeping a clear Intellectual Property trail would be a nightmare if
SableVM's development and maintenance was spread over two distinct
repositories.
3- According to Geir, integration of the VM into Harmony's repository is
not a preriquisite for J2SE certification.
The SableVM project has chosen to integrate our VM with Harmony's class
library. In particular, I have started with a student to implement
Harmony's VMI. Our objective is to fully adapt SableVM to work with
Harmony's VMI "as is". If I understand JCHEVM's approach, they are
going in a different direction; they are developing a "GNU Classpath
compatibility layer" so that Classpath-based VMs could migrate to
Harmony with little effort.
SableVM's goal is to become entirely dependent on Harmony's LUNI
packages, as we do like Harmony's VMI. This will have the consequence
of breaking SableVM's compatibility to Classpath's LUNI packages. Yet
we do not see this as a problem; you will still be able to use
Classpath other packages with SableVM (awt, swing, etc.).
So, if you wish to contribute to SableVM for helping with the Harmony
integration, please join us at http://sablevm.org. If you are
interested, we'll use the SableVM developer mailing-list to coordonate
the Harmony adaptation effort.
See below.
Enrico Migliore wrote:
> SableVM or JCHEVM?
> ------------------------
> At the moment there two virutual machines: which of the two should one
> choose to work on?
I would say:
- If you want to work on a Classpath layer => JCHEVM
- If you want to fully implement VMI => SableVM
> SableVM svn access
> ---------------------
> I can't find the SableVM repository in the Harmony site, can somebody
> address me where to find it?
Contributing to SableVM is done in SableVM's repository at
http://sablevm.org. I am in the process of updating our contribution
policy to better reflect the recent license change. Yet, it retain much
of the current policy:
http://sablevm.org/svn/repository/sablevm/trunk/doc/contribution_policy.txt
You're welcome to help! :-)
Etienne
--
Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
Re: SableVM or JCHEVM?
Posted by Tim Ellison <t....@gmail.com>.
This may be obvious, so excuse me if it is...
Part of the Harmony 'modular-design' philosophy is to encourage multiple
core VM, GC, JIT, class library, etc. combinations.
There is room for many VMs, and the fact that SableVM has relicensed and
is coding to the VMI does not in any way mean that work on JCHEVM should
be scaled back.
I'd encourage you to work wherever your interests and skills have the
best effect.
Regards,
Tim
Enrico Migliore wrote:
> Hi,
>
> I've followed the discussion about the SableVM code donation to the
> Apache foundation, but I still need to understand a couple of things:
>
>
> SableVM or JCHEVM?
> ------------------------
> At the moment there two virutual machines: which of the two should one
> choose to work on?
>
> SableVM svn access
> ---------------------
> I can't find the SableVM repository in the Harmony site, can somebody
> address me where to find it?
>
>
> Enrico
>
>
>
> ---------------------------------------------------------------------
> 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
>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
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
SableVM or JCHEVM?
Posted by Enrico Migliore <en...@fatti.com>.
Hi,
I've followed the discussion about the SableVM code donation to the
Apache foundation, but I still need to understand a couple of things:
SableVM or JCHEVM?
------------------------
At the moment there two virutual machines: which of the two should one
choose to work on?
SableVM svn access
---------------------
I can't find the SableVM repository in the Harmony site, can somebody
address me where to find it?
Enrico
---------------------------------------------------------------------
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: SableVM and Harmony Class library
Posted by Weldon Washburn <we...@gmail.com>.
On 3/29/06, Enrico Migliore <en...@fatti.com> wrote:
> Hi all,
>
> I'm reading the documentation above and, at first glance, it seems to me
> that interfacing the SableVM to the Harmony Class Library is a task that
> involves the following steps:
>
> step 1
> ------
> The SableVM /has to/ implement the VM interface, in order for the
> Harmony Class Library to "find" the entry points of a certain number of
> native functions. The entry points are documented here:
>
> http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/group__VMInterface.html
>
>
> step 2
> ------
> The SableVM has to implement a Java interface, which means that is /has
> to/ implement in C a small set of Java classes, documented in the
> following link:
>
> http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/kernel_doc/html/index.html#KernelJavaClasses
>
Perhaps you have already found the empty java stubs at:
modules/kernel/src/main/java/java/lang. To get an idea how much of
the kernel class code need to be written in C vs. Java, take a look at
the filled in kernel classes I did for "hello world" on JCMEVM. You
can find it on JIRA at HARMONY-192. Note that I wrote almost zero C
code. Most of the mods were in Java.
>
> step 3
> ------
> The SableVM, in terms of native functions, /should/ call only the native
> functions of the port layer, used by the Harmony Class Library:
>
> http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/group__Port.html#CreatePortLib
>
>
> Comments are welcome :-)
>
> Enrico
>
>
>
>
>
>
--
Weldon Washburn
Intel Middleware Products Division
SableVM and Harmony Class library
Posted by Enrico Migliore <en...@fatti.com>.
Hi,
>The main document on porting is at:
>
> http://tinyurl.com/jfljq
>
>The VM Interface is described at:
>
> http://tinyurl.com/gtd64
>
>and the required kernel classes are described at:
>
> http://tinyurl.com/hawkl
>
>Regards,
> Mark.
>
>
Hi all,
I'm reading the documentation above and, at first glance, it seems to me
that interfacing the SableVM to the Harmony Class Library is a task that
involves the following steps:
step 1
------
The SableVM /has to/ implement the VM interface, in order for the
Harmony Class Library to "find" the entry points of a certain number of
native functions. The entry points are documented here:
http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/group__VMInterface.html
step 2
------
The SableVM has to implement a Java interface, which means that is /has
to/ implement in C a small set of Java classes, documented in the
following link:
http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/kernel_doc/html/index.html#KernelJavaClasses
step 3
------
The SableVM, in terms of native functions, /should/ call only the native
functions of the port layer, used by the Harmony Class Library:
http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/group__Port.html#CreatePortLib
Comments are welcome :-)
Enrico
Re: VMI Questions
Posted by Mark Hindess <ma...@googlemail.com>.
The main document on porting is at:
http://tinyurl.com/jfljq
The VM Interface is described at:
http://tinyurl.com/gtd64
and the required kernel classes are described at:
http://tinyurl.com/hawkl
Regards,
Mark.
On 3/29/06, Enrico Migliore <en...@fatti.com> wrote:
> Etienne Gagnon wrote:
>
> >Hi Weldon,
> >
> >I've started reading about the VMI. While my initial goal would be to
> >get SableVM to work with Harmony as a drop-in replacement for IBM's VM,
> >I have some questions about some assumptions of the VMI.
> >
> >
> Hi Etienne,
>
> could you tell me where I can find the documentation of the VMI?
>
> thanks a bunch,
> Enrico
--
Mark Hindess <ma...@googlemail.com>
IBM Java Technology Centre, UK.
Re: VMI Questions
Posted by Enrico Migliore <en...@fatti.com>.
Etienne Gagnon wrote:
>Hi Weldon,
>
>I've started reading about the VMI. While my initial goal would be to
>get SableVM to work with Harmony as a drop-in replacement for IBM's VM,
>I have some questions about some assumptions of the VMI.
>
>
Hi Etienne,
could you tell me where I can find the documentation of the VMI?
thanks a bunch,
Enrico
Re: VMI Questions
Posted by Tim Ellison <t....@gmail.com>.
No problem -- I would really appreciate it if you kept brief notes about
things 'you wish you had been told in the doc' so I can improve it.
Thanks
Tim
Etienne Gagnon wrote:
> Ah! I think I see now. Thanks! :-)
>
> Etienne
>
> Tim Ellison wrote:
>>> Unless I am missing something?
>> The actual implementation are provided by the VM in a DLL loaded by the
>> Harmony launcher[1]. At launch time the DLL is loaded (and the VMI
>> functions globally exported).
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: VMI Questions
Posted by Etienne Gagnon <eg...@sablevm.org>.
Ah! I think I see now. Thanks! :-)
Etienne
Tim Ellison wrote:
>>Unless I am missing something?
>
> The actual implementation are provided by the VM in a DLL loaded by the
> Harmony launcher[1]. At launch time the DLL is loaded (and the VMI
> functions globally exported).
--
Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
Re: VMI Questions
Posted by Tim Ellison <t....@gmail.com>.
Etienne Gagnon wrote:
>>> On the other hand, I don't
>>> understand why the hyluni library assumes that it will be necessarily
>>> loaded by a specific VM library sitting in a particular directory.
>> It doesn't. The hyluni library code uses macros that expand out to a
>> function table maintained by the VMStruct as you elude to below.
>> ...
>> The only functions that are exported by the VM are [3]
>> VMInterface* JNICALL VMI_GetVMIFromJNIEnv(JNIEnv* env)
>> VMInterface* JNICALL VMI_GetVMIFromJavaVM(JavaVM* vm)
>
> Exactly. Now, these 2 functions are global. How does the hyluni
> library resolves these two global references? As far as I can see, in
> the build/install process, the hyluni library simply assumes that the
> system's dynamic linker will resolve them assuming they reside in a
> specific file. See build.xml:
>
> <!-- Don't copy the VMI library. the one we build is a stub that is
> replaced by a concrete implementation by the VM-implementor -->
> <patternset excludes="*vmi*${shlib.suffix}*" />
>
> Unless I am missing something?
Ah, ok. So as you have probably seen, the versions in the Harmony SVN
are stubs that return NULL; hence the comment above not to copy the
stubs into the runtime layout.
The actual implementation are provided by the VM in a DLL loaded by the
Harmony launcher[1]. At launch time the DLL is loaded (and the VMI
functions globally exported).
There is a default directory and DLL name built into the launcher:
...
char defaultDllName[] = "clearvm";
char defaultDirName[] = "default";
...
and the user can override these with command-line arguments to launch a
different VM / specify a different VM DLL, like this:
java -vmdir:<sablevm> -vm:<hyvmdll>
>>> The problem I see, with the current approach, is that it makes it
>>> impossible to provide distinct VM libraries for different purposes
>>> (debugging, faster execution, profiling, ...), as they can't be all in a
>>> single file.
>>
>> We want that too, and I believe that it is already possible.
>
> I am surely missing something...
Does that resolve it?
Regards,
Tim
Refs:
[1]
http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/native-src/shared/launcher/main.c?view=markup
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: VMI Questions
Posted by Etienne Gagnon <eg...@sablevm.org>.
>>On the other hand, I don't
>>understand why the hyluni library assumes that it will be necessarily
>>loaded by a specific VM library sitting in a particular directory.
>
> It doesn't. The hyluni library code uses macros that expand out to a
> function table maintained by the VMStruct as you elude to below.
>...
> The only functions that are exported by the VM are [3]
> VMInterface* JNICALL VMI_GetVMIFromJNIEnv(JNIEnv* env)
> VMInterface* JNICALL VMI_GetVMIFromJavaVM(JavaVM* vm)
Exactly. Now, these 2 functions are global. How does the hyluni
library resolves these two global references? As far as I can see, in
the build/install process, the hyluni library simply assumes that the
system's dynamic linker will resolve them assuming they reside in a
specific file. See build.xml:
<!-- Don't copy the VMI library. the one we build is a stub that is
replaced by a concrete implementation by the VM-implementor -->
<patternset excludes="*vmi*${shlib.suffix}*" />
Unless I am missing something?
>>The problem I see, with the current approach, is that it makes it
>>impossible to provide distinct VM libraries for different purposes
>>(debugging, faster execution, profiling, ...), as they can't be all in a
>>single file.
>
>
> We want that too, and I believe that it is already possible.
I am surely missing something...
Etienne
--
Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
Re: VMI Questions
Posted by Tim Ellison <t....@gmail.com>.
Etienne Gagnon wrote:
> Hi Weldon,
>
> I've started reading about the VMI. While my initial goal would be to
> get SableVM to work with Harmony as a drop-in replacement for IBM's VM,
> I have some questions about some assumptions of the VMI.
>
> In particular, I would like to understand the motivation for the
> implicit direct link from the hyluni library to the VM library. In
> other words, it seems logical to me that the VM library would cause the
> dynamic loading of the hyluni library.
Right, in the IBM VME world, the VM explicitly loads the hyluni.dll and
ICUInterface34.dll (a dependent DLL containing char functions used via
String).
> On the other hand, I don't
> understand why the hyluni library assumes that it will be necessarily
> loaded by a specific VM library sitting in a particular directory.
It doesn't. The hyluni library code uses macros that expand out to a
function table maintained by the VMStruct as you elude to below.
So you will see code everywhere like this [1]:
jboolean JNICALL
Java_java_io_File_existsImpl
(JNIEnv * env, jobject recv, jbyteArray path)
{
PORT_ACCESS_FROM_ENV (env);
...
}
Where PORT_ACCESS_FROM_ENV is a macro that expands out as follows [2]:
#define PORT_ACCESS_FROM_ENV(jniEnv) \
HyPortLibrary *privatePortLibrary = \
((HyVMThread *) (jniEnv))->javaVM->portLibrary
The portlibray is itself a function pointer table that contains
functions used in the JNI code.
> This assumption has an important side effect. The hyluni library
> assumes that it can simply call VMI_* global functions which are
> resolved by the dynamic linker.
The only functions that are exported by the VM are [3]
VMInterface* JNICALL VMI_GetVMIFromJNIEnv(JNIEnv* env)
VMInterface* JNICALL VMI_GetVMIFromJavaVM(JavaVM* vm)
The remaining VMI functions are looked-up in a function table [4] in a
similar fashion to the portlib code, so for example [5]:
jint JNICALL
Java_java_util_zip_ZipFile_openZipImpl (JNIEnv * env, jobject recv,
jbyteArray zipName)
{
VMI_ACCESS_FROM_ENV (env);
PORT_ACCESS_FROM_ENV (env);
...
zipCachePool = (*VMI)->GetZipCachePool (VMI);
...
}
> Personally, I would have done things
> some other way; I would either have had the VM library call a
> VMI_SetVMI() function exported by the hyluni library and requested the
> the VM library call it, or, better, I would have done like the debug
> interface and requested the VMI function table through the GetEnv
> function of the invocation interface :
>
> (*jvm)->GetEnv(jvm, &vmi, VMI_VERSION_1);
>
> This would seem the cleanest approach to me.
That is the moral equivalent of what we have done, as shown above.
> The only problem is to
> avoid clashing with Sun's constants.
>
> The problem I see, with the current approach, is that it makes it
> impossible to provide distinct VM libraries for different purposes
> (debugging, faster execution, profiling, ...), as they can't be all in a
> single file.
We want that too, and I believe that it is already possible.
Regards,
Tim
Refs:
[1]
http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/native-src/shared/luni/file.c?view=markup
[2]
http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/native-src/shared/include/hyport.h?view=markup
[3]
http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/native-src/shared/vmi/vmi.c?view=markup
[4]
http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/native-src/shared/include/vmi.h?view=markup
[5]
http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/native-src/shared/archive/zip.c?view=markup
> Etienne
>
> Weldon Washburn wrote:
>> ... In any case, feel free to borrow parts of kernel_path that
>> make sense. Also, feel free to ask questions about it.
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.