On 9/23/05, Robin Garner [EMAIL PROTECTED] wrote:
Weldon Washburn wrote:
Everyone,
I just posted the basics of the GC/VM interface to
http://wiki.apache.org/harmony/HarmonyArchitecture. The VM calls into
the GC using gc_interface.txt. The GC calls into the VM using
Weldon Washburn wrote:
Everyone,
I just posted the basics of the GC/VM interface to
http://wiki.apache.org/harmony/HarmonyArchitecture. The VM calls into
the GC using gc_interface.txt. The GC calls into the VM using
vm_gc_interface.txt.
Weldon
Thanks Weldon, it makes very interesting
Everyone,
I just posted the basics of the GC/VM interface to
http://wiki.apache.org/harmony/HarmonyArchitecture. The VM calls into
the GC using gc_interface.txt. The GC calls into the VM using
vm_gc_interface.txt.
Weldon
On Tue, 2005-08-30 at 20:34 +0800, Xiao-Feng Li wrote:
Hi, Ron, I think your concern is valid. We fully understand POSIX has
been and is being used widely. That's why we want to have a discussion
here. APR does have some features a JVM may need in all platforms,
such as atomic operations,
Using APR doesn´t mean Harmony won´t be posix compliant. Only that it
will be one layer above the posix stuff.
On 8/30/05, Xiao-Feng Li [EMAIL PROTECTED] wrote:
Hi, Ron, I think your concern is valid. We fully understand POSIX has
been and is being used widely. That's why we want to have a
On Aug 27, 2005, at 4:55 AM, David Tanzer wrote:
Some questions: Are these the actual headers we program against? If
yes, this would assume we use C or C++ to implement the VM, or at
least
these components, right?
Sorry if I'm asking something which has already been resolved, but I
was
On 8/28/05, David Tanzer [EMAIL PROTECTED] wrote:
On Sat, 2005-08-27 at 07:15 -0700, Weldon Washburn wrote:
[Snip]
Another suggestion: IMHO it would be good to use the Java Coding
Conventions in C/C++ code too. While this has the disadvantage that
the coding style in the C/C++ code
Posix is popular and widely used across many different platforms. Intel had
implemented ORP basically on top of Posix, and it was easy to use Posix to
wrap Windows APIs.
Now there are more portable API libraries to choose from, such as APR, and
IBM Portability Library. For ease of portability
On Aug 28, 2005, at 6:06 PM, Xiao-Feng Li wrote:
Posix is popular and widely used across many different platforms.
Intel had
implemented ORP basically on top of Posix, and it was easy to use
Posix to
wrap Windows APIs.
Now there are more portable API libraries to choose from, such as
APR,
Some questions: Are these the actual headers we program against? If
yes, this would assume we use C or C++ to implement the VM, or at least
these components, right?
Sorry if I'm asking something which has already been resolved, but I
was just searching the mailing list archives and I found much
method_access.txt has been added.
On 8/25/05, Weldon Washburn [EMAIL PROTECTED] wrote:
On 8/25/05, Davanum Srinivas [EMAIL PROTECTED] wrote:
Weldon,
from which wiki page is this field_access.txt url linked from? could
we not add the code that wiki page itself? (if you enclose with {{{
On 8/18/05, Ricardo Morin [EMAIL PROTECTED] wrote:
Hi,
I updated the Modular Structure JVM Components
section of the architecture document with a
description for each one of the boxes in the UML
diagram, and a brief explanation of notation.
Next step would be to start describing the
Weldon,
from which wiki page is this field_access.txt url linked from? could
we not add the code that wiki page itself? (if you enclose with {{{
and }}} with the code in between it looks nice)
thanks,
dims
On 8/25/05, Weldon Washburn [EMAIL PROTECTED] wrote:
On 8/18/05, Ricardo Morin [EMAIL
On 8/25/05, Davanum Srinivas [EMAIL PROTECTED] wrote:
Weldon,
from which wiki page is this field_access.txt url linked from? could
we not add the code that wiki page itself? (if you enclose with {{{
and }}} with the code in between it looks nice)
Oops. Sorry. I put an http link to
Hi
Thanks, great overview, Ricardo! In regards to APR as a candidate for
the OS Abstraction Layer (OAL) project:
I like the APR idea, but still would like to evaluate how feasible it
will be to port whatever we chose as the OAL to various embedded
platforms, in particular ARM, PowerPC and
*unlurk*
Hi,
On Fri, Aug 19, 2005 at 12:15:40AM -0700, Tom wrote:
I like the APR idea, but still would like to evaluate how feasible it
will be to port whatever we chose as the OAL to various embedded
platforms, in particular ARM, PowerPC and MIPS.
Es you can for example see at [0] APR
Tom wrote:
Hi
I like the APR idea, but still would like to evaluate how feasible it
will be to port whatever we chose as the OAL to various embedded
platforms, in particular ARM, PowerPC and MIPS.
Right now, the APR runs on WindowsCE platforms regardless of CPU.
Of course some things are
Joerg,
thanks for your link, seems like APR is the way to go.
Just one more thing: Instead of just having an abstraction layer, would
it be possible to give our solution a little finer granularity right
from the start ?
E.g. define a part of this layer so that only this part is required on a
Hi Tim:
Do you intend to put some words to your attachment?
Yes, I will go ahead and expand the content of the
Modular Structure JVM Components section to describe
each component and dependency.
Thank you,
Ricardo
--- Tim Ellison [EMAIL PROTECTED] wrote:
Ricardo,
Do you intend to put
I think this is great, but like Tim, was hoping for some descriptions
of the various interfaces :)
geir
On Aug 16, 2005, at 1:45 PM, Ricardo Morin wrote:
Hi All:
In order to continue refining the discussions on JVM
modularity, I have added a component diagram to the
HarmonyArchitecture
Hi,
I updated the Modular Structure JVM Components
section of the architecture document with a
description for each one of the boxes in the UML
diagram, and a brief explanation of notation.
Next step would be to start describing the interface
groups.
Thank you,
Ricardo
Hi All:
In order to continue refining the discussions on JVM
modularity, I have added a component diagram to the
HarmonyArchitecture Wiki page. The diagram drills down
on the Modular Structure JVM Components section by
depicting the major components and interfaces. I
propose discussing the
Torsten Curdt wrote:
Only thing I'd like to throw in the pool
is...
I'd like the vm to be flexible enough to
support native continuation in java. Of
course the first (big) goal is to become
standard compliant ...but I would like
to see at least the *possibility* to hook
in something low-level
Mladen Turk wrote:
Torsten Curdt wrote:
I'd like the vm to be flexible enough to
support native continuation in java. Of
I suppose you meant about light weight JNI calls :)
I suspect that the original poster was refering to Continuations
as in:
http://en.wikipedia.org/wiki/Continuation
or
I suppose that could be one of the requirements of the
Execution Engine component, i.e., the ability (as
Mladen said) to incorporate native code in a
lightweight fashion. This requirement would not
necessarily alter the overall set of components and
interfaces that are shown in the diagram.
I suppose you meant about light weight JNI calls :)
I suspect that the original poster was refering to Continuations
as in:
http://en.wikipedia.org/wiki/Continuation
or
http://www.intertwingly.net/blog/2005/04/13/Continuations-for-
Curmudgeons
Yepp! Currently we work around with bytecode
Michael Haupt wrote:
On 8/16/05, Werner Schuster (murphee) [EMAIL PROTECTED] wrote:
It seems that Dolphin will contain a new invoke-[something] bytecode
that is suppose to help implementation of dynamic languages;
do you have a link to more information on that issue?
Graham
27 matches
Mail list logo
