You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Ricardo Morin <mo...@yahoo.com> on 2005/08/16 19:45:43 UTC
[arch] Modular JVM component diagram
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 suggested structure and then
proceed to describe and define the components and
interfaces in more detail, based on our discussions.
http://wiki.apache.org/harmony/HarmonyArchitecture
http://wiki.apache.org/harmony-data/attachments/HarmonyArchitecture/attachments/ModularJVM.jpg
Comments? Ideas?
Thank you,
Ricardo
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
Re: [arch] Modular JVM component diagram
Posted by Torsten Curdt <tc...@apache.org>.
>> 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 rewriting
http://jakarta.apache.org/commons/sandbox/javaflow
But that's quite an effort. I heard that in the sun
jvm the exception mechanism does almost provide what
is required for continuations.
It might also be possible to slot it in through the
hotspot interface but it would be nice to have a
slightly easier way of hooking that in.
> It seems that Dolphin will contain a new invoke-[something]
> bytecode that is supposed
> to help implementation of dynamic languages; I don't know any
> details of the semantics yet, but
> having continuations or CPS supported by the JVM/a bytecode would
> probably be nice.
Hmmm... that sounds interesting!
cheers
--
Torsten
Re: [arch] Modular JVM component diagram
Posted by "Werner Schuster (murphee)" <we...@gmail.com>.
Michael Haupt wrote:
>On 8/16/05, Werner Schuster (murphee) <we...@gmail.com> 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 Hamilton mentioned this in his talk on Dolphin at JavaOne05 (I
think it was the technical session).
I also saw a "invokedynamic" bytecode mentioned in some other set of
JavaOne slides... but that's
about all I know.
It wasn't mentioned what this bytecode would do, or how this could
improve dynamic languages.
How about a invokedynamic bytecode that is bundled with a
box-activation-frame bytecode?
If you invoke a method with invokedynamic, you could use the
box-activation-frame in it, to box the
activation frame (ie. move it to a heap data structure) and return a
reference to it.
Oh... and there'd need to be a unbox-activation-frame bytecode as well.
Another idea might be to have a way to do closures easier and more
performant; some way
to abstract away the activation stack. This could allow the VM to use
the stack whenever possible,
and to fallback to the heap if necessary.
OK... I haven't thought these through... does anybody else have any
ideas? After all, a bytecode
change is the one thing that people have been demanding for ... possibly
a decade now.
murphee
--
Blog @ http://jroller.com/page/murphee
Re: [arch] Modular JVM component diagram
Posted by Michael Haupt <mh...@gmail.com>.
Hi Werner,
On 8/16/05, Werner Schuster (murphee) <we...@gmail.com> wrote:
> It seems that Dolphin will contain a new invoke-[something] bytecode
> that is supposed
> to help implementation of dynamic languages;
do you have a link to more information on that issue?
Best regards,
Michael Haupt
Re: [arch] Modular JVM component diagram
Posted by "Werner Schuster (murphee)" <we...@gmail.com>.
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
http://www.intertwingly.net/blog/2005/04/13/Continuations-for-Curmudgeons
It seems that Dolphin will contain a new invoke-[something] bytecode
that is supposed
to help implementation of dynamic languages; I don't know any details of
the semantics yet, but
having continuations or CPS supported by the JVM/a bytecode would
probably be nice.
murphee
--
Blog @ http://jroller.com/page/murphee
Re: [arch] Modular JVM component diagram
Posted by Mladen Turk <mt...@apache.org>.
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 like that without
> the need of fancy byte code rewriting.
>
Right.
I suppose you meant about light weight JNI calls :)
Like I said in '[arch] VM/Classlibrary Interface (take 2)'
thread; most of the time there is no need to
go trough the entire JNI call stack.
Most of the classpath calls should be made simple
returning processor atomic types, so the cost for
calling the native should not exceed the call for
and JVM inline.
Regards,
Mladen.
Re: [arch] Modular JVM component diagram
Posted by Ricardo Morin <mo...@yahoo.com>.
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.
Thanks,
Ricardo
--- Torsten Curdt <tc...@apache.org> 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 like that without
> the need of fancy byte code rewriting.
>
> I am not sure where that would fit into
> the diagram though...
>
> cheers
> --
> Torsten
>
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
Re: [arch] Modular JVM component diagram
Posted by Torsten Curdt <tc...@apache.org>.
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 like that without
the need of fancy byte code rewriting.
I am not sure where that would fit into
the diagram though...
cheers
--
Torsten
Re: [arch] Modular JVM component diagram
Posted by David Tanzer <st...@guglhupf.net>.
Tim Ellison wrote:
> [Snip]
> - I'd vote that the "J2SDK Toolkit" be predominantly written in Java
> and avoid the requirement for the CTL.
Agreed, I'd say we should only choose something different than Java for
implementating the toolit when there is a really good reason (i.e.
performance is critical and a prototype has shown that the C/C++
implementation is faster).
Another point concerning the Toolkit: In the architecture proposal there
is the following suggestion: "The overall tool goal is to permit or
promote augmented clients in addition to the standard-named ones." I
think this is a good idea, for example I can think of lots of things
I want to have in javadoc which the standard version does not provide.
Anyway we should be careful with that so we don't create a possible
vendor lock in to harmony. I think it's crucial for the success of
Harmony that projects written agains harmony can be build with any
other java implementation without too much porting.
This is also an argument for writing the toolkit in Java: we could
distribute these tools for use with other Java Software Development
Kits too.
Regards, David.
> Regards,
> Tim
>
>
> Ricardo Morin wrote:
>
>>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 suggested structure and then
>>proceed to describe and define the components and
>>interfaces in more detail, based on our discussions.
>>
>>http://wiki.apache.org/harmony/HarmonyArchitecture
>>
>>http://wiki.apache.org/harmony-data/attachments/HarmonyArchitecture/attachments/ModularJVM.jpg
>>
>>Comments? Ideas?
>>
>>Thank you,
>>
>>Ricardo
>>
>>____________________________________________________
>>Start your day with Yahoo! - make it your home page
>>http://www.yahoo.com/r/hs
>>
>>
>
>
Re: [arch] Modular JVM component diagram
Posted by Weldon Washburn <we...@gmail.com>.
On 9/23/05, Robin Garner <Ro...@anu.edu.au> 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
> > vm_gc_interface.txt.
> > Weldon
> >
> >
> Thanks Weldon, it makes very interesting reading. I've posted a
> description of MMTk's VM interface on my web page,
> http://cs.anu.edu.au/people/Robin.Garner/, for comparison. This is the
> GC -> VM interface.
Great! Its good you are documenting MMTk interface. I will take a
look at it soon. Please think of the interfaces that I posted as a
starting point. Also, don't feel shy about ripping apart the
interfaces I have posted. The whole point is to quickly evolve
Harmony into something more sophisticated than the existing JVMs.
>
> As described in my thesis (although if you want to read it, remember it
> is now nearly 2 years out of date, and MMTk has moved on - link is also
> on my ANU web page), we follow a "wedge" model of the interface, rather
> than specifying a simple flat API. So while JikesRVM (and Rotor and
> JNode) have a definite API that they code to, there is a package that
> translates this to fit the services MMTk offers. And that's a large
> set, not yet documented (beyond source and javadoc in any case).
>
> I'm going to look more closely at the interface you've posted, and will
> probably have more questions in a short while, but my first
> impressions/questions are:
> - The interface seems tightly coupled to ORP and Sapphire.
Sapphire has been backed out of the source base. As far as I know,
the GC interface I posted has not been used any place but ORP and its
follow-ons.
> For example,
> since there aren't any API calls to do it, I presume the GC knows how
> the object header is laid out ? And knows about something called a
> vtable ?
True and true.
> - It's not explicitly specified in the API, but I assume gc_alloc_fast
> is inlined (or is a macro) ?
gc_alloc_fast is intended to be inlined.
> - Doesn't supporting gc_pin_object restrict the GC implementation
> significantly ?
This might have been one of the APIs left over from when we extended
ORP to run ECMA CLI (.net). I might have forgotten to remove it.
> - I was under the impression ORP doesn't yet support weak references or
> finalizers.
Stay tuned for more info.
> There appears to be support for the GC to tell the VM about
> reference types, but not the other way round. Is this right ? Or is
> this the gc_add_weak_root_set_entry call ?
> - How does the VM enumerate the thread stacks ? Is this the
> gc_add_root_set_entry call ?
I will have to take a look and get back to you.
>
> Do you have any documentation specifying what else the GC talks to ?
> I'm assuming that for its own synchronization, interfacing with the OS
> (mmap etc) it talks directly with the OS, glibc etc.
Yes. I have been waiting to see what response I get to what's already
posted before posting more stuff.
>
> Cheers,
> Robin
>
>
--
Weldon Washburn
Intel Managed Runtime Division
Re: [arch] Modular JVM component diagram
Posted by Robin Garner <Ro...@anu.edu.au>.
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 reading. I've posted a
description of MMTk's VM interface on my web page,
http://cs.anu.edu.au/people/Robin.Garner/, for comparison. This is the
GC -> VM interface.
As described in my thesis (although if you want to read it, remember it
is now nearly 2 years out of date, and MMTk has moved on - link is also
on my ANU web page), we follow a "wedge" model of the interface, rather
than specifying a simple flat API. So while JikesRVM (and Rotor and
JNode) have a definite API that they code to, there is a package that
translates this to fit the services MMTk offers. And that's a large
set, not yet documented (beyond source and javadoc in any case).
I'm going to look more closely at the interface you've posted, and will
probably have more questions in a short while, but my first
impressions/questions are:
- The interface seems tightly coupled to ORP and Sapphire. For example,
since there aren't any API calls to do it, I presume the GC knows how
the object header is laid out ? And knows about something called a
vtable ?
- It's not explicitly specified in the API, but I assume gc_alloc_fast
is inlined (or is a macro) ?
- Doesn't supporting gc_pin_object restrict the GC implementation
significantly ?
- I was under the impression ORP doesn't yet support weak references or
finalizers. There appears to be support for the GC to tell the VM about
reference types, but not the other way round. Is this right ? Or is
this the gc_add_weak_root_set_entry call ?
- How does the VM enumerate the thread stacks ? Is this the
gc_add_root_set_entry call ?
Do you have any documentation specifying what else the GC talks to ?
I'm assuming that for its own synchronization, interfacing with the OS
(mmap etc) it talks directly with the OS, glibc etc.
Cheers,
Robin
Re: [arch] Modular JVM component diagram
Posted by Weldon Washburn <we...@gmail.com>.
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
Re: [arch] Modular JVM component diagram
Posted by Weldon Washburn <we...@gmail.com>.
On 8/28/05, David Tanzer <st...@guglhupf.net> 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 might be inconsistent in some places
> > > it would have the great advantage that all code (and all interfaces)
> > > we write use the same coding style.
> >
> > Good idea! Perhaps you could rewrite a few of the APIs I have posted
> > in Java Coding Conventions style. We could then discuss the merits.
> > If it makes sense, I would then rewrite field_access.txt, etc. to
> > reflect the proposed style.
>
> I have added method_access_java_conv.txt to the wiki, which is
> method_access.txt rewritten according to the Java Coding Conventions.
I looked at method_access_java_conv.txt. It looks like only cosmetic
changes. I don't have any objection to what you are proposing. Does
anyone else have comments/questions?
>
> Regards, David.
>
> --
> David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe
> http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net
> My PGP Public Key: http://guglhupf.net/david/david.asc
> --
> Are You Pondering What I'm Pondering?
> Umm, I think so Brain-2, but a show about two talking lab mice?
> It'll never get on the air!
>
>
Re: [arch] Modular JVM component diagram
Posted by David Tanzer <st...@guglhupf.net>.
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 might be inconsistent in some places
> > it would have the great advantage that all code (and all interfaces)
> > we write use the same coding style.
>
> Good idea! Perhaps you could rewrite a few of the APIs I have posted
> in Java Coding Conventions style. We could then discuss the merits.
> If it makes sense, I would then rewrite field_access.txt, etc. to
> reflect the proposed style.
I have added method_access_java_conv.txt to the wiki, which is
method_access.txt rewritten according to the Java Coding Conventions.
Regards, David.
--
David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe
http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net
My PGP Public Key: http://guglhupf.net/david/david.asc
--
Are You Pondering What I'm Pondering?
Umm, I think so Brain-2, but a show about two talking lab mice?
It'll never get on the air!
Re: [arch] Modular JVM component diagram
Posted by Weldon Washburn <we...@gmail.com>.
On 8/27/05, David Tanzer <st...@guglhupf.net> 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?
The purpose of the text files is to solicit comment on the APIs they
contain. The APIs are similar to the ones we have used for building a
VM. I am very interested in what harmony-dev mailing list thinks of
these APIs.
>
> Sorry if I'm asking something which has already been resolved, but I
> was just searching the mailing list archives and I found much
> controversy about which language to use, but I didn't find a resolution.
I agree that there is no resolution yet. I am hoping that a
discussion of specific APIs will help move us to a resolution.
> Anyway, I thing C/C++ would be a good choice to implement performance
> critical parts of the VM.
I agree with this statement.
>
> 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 might be inconsistent in some places
> it would have the great advantage that all code (and all interfaces)
> we write use the same coding style.
Good idea! Perhaps you could rewrite a few of the APIs I have posted
in Java Coding Conventions style. We could then discuss the merits.
If it makes sense, I would then rewrite field_access.txt, etc. to
reflect the proposed style.
By the way, I also posted vm_class_manipulation.txt to wiki page.
Please take a look.
Weldon
Re: [arch] Modular JVM component diagram
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
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 just searching the mailing list archives and I found much
> controversy about which language to use, but I didn't find a
> resolution.
> Anyway, I thing C/C++ would be a good choice to implement performance
> critical parts of the VM.
I think that this problem will be solved organically, as we start
creating code and accepting donations, I'd expect that we'd let
people do both as we worked out some architecture issues. Then, with
what we've learned, I'd expect we'd restart with a clearer roadmap
that will probably include both C/C++ and Java. Pascal is right out.
>
> Another suggestion: IMHO it would be good to use the Java Coding
> Conventions in C/C++ code too.
Wow! There's a twist on that bikeshed that I haven't seen before :)
> While this has the disadvantage that
> the coding style in the C/C++ code might be inconsistent in some
> places
> it would have the great advantage that all code (and all interfaces)
> we write use the same coding style.
Yes, that's true. OTOH, having two styles helps you realize what
language you're looking at :) My biggest concerns about coding style
are safety and clarity - use {} even for one liners, don't get cute
and write perl-like statements just 'cuz, and document, document,
document. I'd be happy w/ one style...
geir
>
> Regards, David.
>
> On Fri, 2005-08-26 at 09:24 -0700, Weldon Washburn wrote:
>
>> method_access.txt has been added.
>>
>> On 8/25/05, Weldon Washburn <we...@gmail.com> wrote:
>>
>>> On 8/25/05, Davanum Srinivas <da...@gmail.com> 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 field_access.txt in
>>> http://wiki.apache.org/harmony/HarmonyArchitecture. Its under
>>> the "VM
>>> Core" paragraph that Ricardo added last week. Its about 3/4 of the
>>> way down the page.
>>>
>>>
>>>>
>>>> thanks,
>>>> dims
>>>>
>>>>
>>>
>>>
> --
> David Tanzer, Guglhupf Studios, http://guglhupf.net
> My PGP Public Key: http://guglhupf.net/david/david.asc
> --
> Brain: Here we are, Pinky--at the dawn of time!
> Pinky: Narf, Brain. Wake me at the noon of time.
> -- When Mice Ruled the Earth
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [arch] Modular JVM component diagram
Posted by David Tanzer <st...@guglhupf.net>.
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
controversy about which language to use, but I didn't find a resolution.
Anyway, I thing C/C++ would be a good choice to implement performance
critical parts of the VM.
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 might be inconsistent in some places
it would have the great advantage that all code (and all interfaces)
we write use the same coding style.
Regards, David.
On Fri, 2005-08-26 at 09:24 -0700, Weldon Washburn wrote:
> method_access.txt has been added.
>
> On 8/25/05, Weldon Washburn <we...@gmail.com> wrote:
> > On 8/25/05, Davanum Srinivas <da...@gmail.com> 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 field_access.txt in
> > http://wiki.apache.org/harmony/HarmonyArchitecture. Its under the "VM
> > Core" paragraph that Ricardo added last week. Its about 3/4 of the
> > way down the page.
> >
> > >
> > > thanks,
> > > dims
> > >
> >
--
David Tanzer, Guglhupf Studios, http://guglhupf.net
My PGP Public Key: http://guglhupf.net/david/david.asc
--
Brain: Here we are, Pinky--at the dawn of time!
Pinky: Narf, Brain. Wake me at the noon of time.
-- When Mice Ruled the Earth
Re: [arch] Modular JVM component diagram
Posted by Weldon Washburn <we...@gmail.com>.
method_access.txt has been added.
On 8/25/05, Weldon Washburn <we...@gmail.com> wrote:
> On 8/25/05, Davanum Srinivas <da...@gmail.com> 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 field_access.txt in
> http://wiki.apache.org/harmony/HarmonyArchitecture. Its under the "VM
> Core" paragraph that Ricardo added last week. Its about 3/4 of the
> way down the page.
>
> >
> > thanks,
> > dims
> >
>
Re: [arch] Modular JVM component diagram
Posted by Weldon Washburn <we...@gmail.com>.
On 8/25/05, Davanum Srinivas <da...@gmail.com> 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 field_access.txt in
http://wiki.apache.org/harmony/HarmonyArchitecture. Its under the "VM
Core" paragraph that Ricardo added last week. Its about 3/4 of the
way down the page.
>
> thanks,
> dims
>
Re: [arch] Modular JVM component diagram
Posted by Davanum Srinivas <da...@gmail.com>.
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 <we...@gmail.com> wrote:
> On 8/18/05, Ricardo Morin <mo...@yahoo.com> 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 interface
> > groups.
>
> Everyone,
> I have started filling in the interfaces mentioned in the jpeg above.
> I am putting classloader interface(s) into harmony wiki at
> http://wiki.apache.org/harmony-data/attachments/HarmonyArchitecture/attachments/field_access.txt.
> Comments?
>
> >
> > Thank you,
> >
> > Ricardo
> >
> > http://wiki.apache.org/harmony/HarmonyArchitecture
> >
> > --- Tim Ellison <t....@gmail.com> wrote:
> >
> > > Ricardo,
> > >
> > > Do you intend to put some words to your attachment?
> >
> > <snip>
> >
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Yahoo! Mail - You care about security. So do we.
> > http://promotions.yahoo.com/new_mail
> >
>
--
Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service Platform
Re: [arch] Modular JVM component diagram
Posted by Weldon Washburn <we...@gmail.com>.
On 8/18/05, Ricardo Morin <mo...@yahoo.com> 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 interface
> groups.
Everyone,
I have started filling in the interfaces mentioned in the jpeg above.
I am putting classloader interface(s) into harmony wiki at
http://wiki.apache.org/harmony-data/attachments/HarmonyArchitecture/attachments/field_access.txt.
Comments?
>
> Thank you,
>
> Ricardo
>
> http://wiki.apache.org/harmony/HarmonyArchitecture
>
> --- Tim Ellison <t....@gmail.com> wrote:
>
> > Ricardo,
> >
> > Do you intend to put some words to your attachment?
>
> <snip>
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - You care about security. So do we.
> http://promotions.yahoo.com/new_mail
>
Re: [arch] voluntary vs. preemptive suspension of Java threads
Posted by Rodrigo Kumpera <ku...@gmail.com>.
I was wondering what similarities on-stack replacement of JITed code
have with suspension with code patching.
On 9/9/05, Xiao-Feng Li <xi...@gmail.com> wrote:
> Thanks, Rodrigo and Shudo. ORP had a similar approach as code patching
> previously, which we called "IP hijacking". We found, as you observed,
> it had some difficulties in maintenance and portability. I classified
> this approach into the preemptive category.
>
> I suspect a given thread suspension algorithm will have different
> performance characteristics depending on processor architecture, and
> garbage collection algorithm as well. It deserves more study. Since
> the two approaches are not much conflicting, I suggest implementing
> voluntary mechanism at first for its cleanness and portability for the
> first few releases of Harmony.
>
> Thanks,
> xiaofeng
> ==
> Intel Managed Runtime Division
>
> On 9/1/05, shudo@computer.org <sh...@computer.org> wrote:
> > From: Xiao-Feng Li <xi...@gmail.com>
> >
> > > Thread suspension happens in many situations in JVM, such as for GC,
> > > for java.lang.Thread.suspend(), etc. There are various techniques to
> > > suspend a thread. Basically we can classify them into two categories:
> > > preemptive and voluntary.
> >
> > > The preemptive approach requires the suspender, say a GC thread,
> > > suspend the execution of a target thread asynchronously with IPC
> > > mechanism or OS APIs. If the suspended thread happened to be in a
> > > region of code (Java or native) that could be enumerated, the live
> > > references were collected. This kind of region is called safe-region,
> > > and the suspended point is a safe-point. If the suspended point is not
> > > in safe-region, the thread would be resumed and stopped again until it
> > > ended up in a safe-region randomly or on purpose.
> >
> > Sun's HotSpot VMs patch compiled native code to stop thread at the
> > safe points, on which a stack map is provided. It's smart but prone to
> > causes subtle problems, an engineer working on the VM said.
> >
> > Kazuyuki Shudo shudo@computer.org http://www.shudo.net/
> >
>
Re: [arch] voluntary vs. preemptive suspension of Java threads
Posted by Xiao-Feng Li <xi...@gmail.com>.
Thanks, Rodrigo and Shudo. ORP had a similar approach as code patching
previously, which we called "IP hijacking". We found, as you observed,
it had some difficulties in maintenance and portability. I classified
this approach into the preemptive category.
I suspect a given thread suspension algorithm will have different
performance characteristics depending on processor architecture, and
garbage collection algorithm as well. It deserves more study. Since
the two approaches are not much conflicting, I suggest implementing
voluntary mechanism at first for its cleanness and portability for the
first few releases of Harmony.
Thanks,
xiaofeng
==
Intel Managed Runtime Division
On 9/1/05, shudo@computer.org <sh...@computer.org> wrote:
> From: Xiao-Feng Li <xi...@gmail.com>
>
> > Thread suspension happens in many situations in JVM, such as for GC,
> > for java.lang.Thread.suspend(), etc. There are various techniques to
> > suspend a thread. Basically we can classify them into two categories:
> > preemptive and voluntary.
>
> > The preemptive approach requires the suspender, say a GC thread,
> > suspend the execution of a target thread asynchronously with IPC
> > mechanism or OS APIs. If the suspended thread happened to be in a
> > region of code (Java or native) that could be enumerated, the live
> > references were collected. This kind of region is called safe-region,
> > and the suspended point is a safe-point. If the suspended point is not
> > in safe-region, the thread would be resumed and stopped again until it
> > ended up in a safe-region randomly or on purpose.
>
> Sun's HotSpot VMs patch compiled native code to stop thread at the
> safe points, on which a stack map is provided. It's smart but prone to
> causes subtle problems, an engineer working on the VM said.
>
> Kazuyuki Shudo shudo@computer.org http://www.shudo.net/
>
Re: [arch] voluntary vs. preemptive suspension of Java threads
Posted by sh...@computer.org.
From: Xiao-Feng Li <xi...@gmail.com>
> Thread suspension happens in many situations in JVM, such as for GC,
> for java.lang.Thread.suspend(), etc. There are various techniques to
> suspend a thread. Basically we can classify them into two categories:
> preemptive and voluntary.
> The preemptive approach requires the suspender, say a GC thread,
> suspend the execution of a target thread asynchronously with IPC
> mechanism or OS APIs. If the suspended thread happened to be in a
> region of code (Java or native) that could be enumerated, the live
> references were collected. This kind of region is called safe-region,
> and the suspended point is a safe-point. If the suspended point is not
> in safe-region, the thread would be resumed and stopped again until it
> ended up in a safe-region randomly or on purpose.
Sun's HotSpot VMs patch compiled native code to stop thread at the
safe points, on which a stack map is provided. It's smart but prone to
causes subtle problems, an engineer working on the VM said.
Kazuyuki Shudo shudo@computer.org http://www.shudo.net/
Re: [arch] Modular JVM component diagram
Posted by Rodrigo Kumpera <ku...@gmail.com>.
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 <xi...@gmail.com> 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, which are lacked in POSIX. And APR is
> available on a couple of different platforms. Yes, POSIX is availabe
> on some non-UNIX systems too, e.g., one can use POSIX on Windows
> through Windows Services for UNIX or Cygwin.
>
> I'd like to hear how other people think. Folks on the mailing list, comments?
>
> Thanks,
> xiaofeng
>
> On 8/29/05, Ron Braithwaite <ro...@braithwaites.net> wrote:
> > 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, and
> > > IBM Portability Library. For ease of portability across a broad
> > > range of
> > > platforms, I suggest that we use APR as the portability api. Do
> > > folks on the
> > > mailing list think that this is a good idea?
> > >
> > > Thanks,
> > > xiaofeng
> >
> > <delurk>
> >
> > As an intensely interested bystander, I'll just kick in my two cents
> > here. Posix compliance is a really good idea, since it is so
> > frequently specified by so many corporate and governmental policies
> > and regulations (e.g., AFIPS, if memory serves).
> >
> > Yes, there are some portable API libraries out there that are
> > superior in certain aspects to Posix. But I think the repercussions
> > of not being Posix-compliant are going to cost more than any gains
> > from specific gains by a less ubiquitous library.
> >
> > Just my two cents worth.
> >
> > Peace,
> > -Ron
> > </delurk>
> >
> > Ron Braithwaite
> > 2015 NE 37th Ave
> > Portland, OR 97212 USA
> > 503-267-3250
> > ron@braithwaites.net
> >
> >
>
Re: [arch] voluntary vs. preemptive suspension of Java threads
Posted by Rodrigo Kumpera <ku...@gmail.com>.
Some time ago someone on this list pointed to a paper from Sun folks
about this subject.
>From what I remember, they tried the folllowing tecniques:
-Pooling on back-edges and call/return, using ether a boolean flag or
forcing a page-fault at a specific address. They noticed that
page-faulting has a huge latency.
-Dynamic code patching, the thread is stopped and the next reachable
safe-point site is patched to call into the VM instead of following
normal execution. This shown to be very tricky to implement on sparc,
but improves the runtime performance a lot.
Rodrigo
On 8/31/05, Xiao-Feng Li <xi...@gmail.com> wrote:
> Thread suspension happens in many situations in JVM, such as for GC,
> for java.lang.Thread.suspend(), etc. There are various techniques to
> suspend a thread. Basically we can classify them into two categories:
> preemptive and voluntary.
>
> The preemptive approach requires the suspender, say a GC thread,
> suspend the execution of a target thread asynchronously with IPC
> mechanism or OS APIs. If the suspended thread happened to be in a
> region of code (Java or native) that could be enumerated, the live
> references were collected. This kind of region is called safe-region,
> and the suspended point is a safe-point. If the suspended point is not
> in safe-region, the thread would be resumed and stopped again until it
> ended up in a safe-region randomly or on purpose.
>
> In the other approach that we are now considering, JIT will insert
> code that polls a boolean. The boolean can be thread-specific and is
> set true by GC thread or VM if there is a need to prevent the Java
> thread's forward progress. The JIT will put the polling code in such
> places as back-edges, call sites and method returns. Actually we are
> thinking of this mechnism in a more general sense. For example,
> green-threads can be implemented in this way for Java threads to
> downcall into JVM scheduler.
>
> Does anyone have suggestions/data on better approaches?
>
> Thanks,
> xiaofeng
>
[arch] voluntary vs. preemptive suspension of Java threads
Posted by Xiao-Feng Li <xi...@gmail.com>.
Thread suspension happens in many situations in JVM, such as for GC,
for java.lang.Thread.suspend(), etc. There are various techniques to
suspend a thread. Basically we can classify them into two categories:
preemptive and voluntary.
The preemptive approach requires the suspender, say a GC thread,
suspend the execution of a target thread asynchronously with IPC
mechanism or OS APIs. If the suspended thread happened to be in a
region of code (Java or native) that could be enumerated, the live
references were collected. This kind of region is called safe-region,
and the suspended point is a safe-point. If the suspended point is not
in safe-region, the thread would be resumed and stopped again until it
ended up in a safe-region randomly or on purpose.
In the other approach that we are now considering, JIT will insert
code that polls a boolean. The boolean can be thread-specific and is
set true by GC thread or VM if there is a need to prevent the Java
thread's forward progress. The JIT will put the polling code in such
places as back-edges, call sites and method returns. Actually we are
thinking of this mechnism in a more general sense. For example,
green-threads can be implemented in this way for Java threads to
downcall into JVM scheduler.
Does anyone have suggestions/data on better approaches?
Thanks,
xiaofeng
Re: [arch] Modular JVM component diagram
Posted by Tim Ellison <t....@gmail.com>.
I agree with Tom that APR / POSIX will have some of the functionality
required by the VM and classlibs.
I guess like other VMs, the J9 VM is based on a portable library
(portlib) interface to the underlying OS. The J9 portlib has the
functionality that you'd expect to see (memory, files, threads, socket,
interrupt mgmt, locks), and some characteristics that you don't find in
APR / POSIX.
The J9 portlib is implemented as a table of function pointers with a
bunch of macros that add syntactic sugar to make it usable. So a
typical usage in JNI would be something like this:
jboolean JNICALL Java_java_io_File_deleteFileImpl(
JNIEnv *env, jobject recv, jbyteArray path)
{
PORT_ACCESS_FROM_ENV(env);
<<snip>>
result = j9file_unlink(pathCopy);
<<snip>>
}
The macro "PORT_ACCESS_FROM_ENV(env)" picks out the portlib struct from
the JNIEnv, so the "j9file_unlink()" macro expands to the right function
pointer invocation.
The advantage of using function pointers rather than linking directly is
that applications can switch in different implementations of functions
"on the fly".
The other difference is that the portlib is self-referential, so the
j9file_unlink(param)
macro expands to
portLib->file_unlink(portLib, param)
and so on. This means that the implementation of file_unlink uses my
definitions of the portlib functions.
If you put these together your "on the fly" function replacements are
cascaded down to the called functions.
This is turning into an essay <g> perhaps I'll continue on the wiki ...
Regards,
Tim
Tom Tromey wrote:
> 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, which are lacked in POSIX. And APR is
>>available on a couple of different platforms. Yes, POSIX is availabe
>>on some non-UNIX systems too, e.g., one can use POSIX on Windows
>>through Windows Services for UNIX or Cygwin.
>>
>>I'd like to hear how other people think. Folks on the mailing list, comments?
>
>
> Using APR makes sense. In my opinion it should be the way Harmony
> is initially ported. People who want to do a new port can then port
> APR. (Or, perhaps they could strip out the APR-using code from Harmony
> and do a "raw" port.)
>
> Experience with libgcj suggests that OS porting layer has few tricky
> parts[1]. The bulk of the code -- file and network I/O, for instance --
> is simple and porting it doesn't represent a major effort. I think our
> "posix" port (includes linux, solaris, macos x) is about 4 KLOC. The
> Windows-specific code is about 5 KLOC. That's not much.
>
> Tom
>
> [1] Turning signals into exceptions is compiler, OS, and chip dependent.
> This qualifies as "tricky" :-). Another occasionally tricky thing is
> interfacing between the GC and the native thread system -- finding
> stack bounds, noticing thread creation, etc. I would guess that APR
> doesn't yet have support for these kinds of things, though I have not
> looked. Note that these are not "pure" OS-dependent areas but are also
> impacted by decisions in other parts of the VM: exception handling
> approach, null pointer detection approach, GC approach, etc.
>
>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [arch] Modular JVM component diagram
Posted by Tom Tromey <tr...@redhat.com>.
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, which are lacked in POSIX. And APR is
> available on a couple of different platforms. Yes, POSIX is availabe
> on some non-UNIX systems too, e.g., one can use POSIX on Windows
> through Windows Services for UNIX or Cygwin.
>
> I'd like to hear how other people think. Folks on the mailing list, comments?
Using APR makes sense. In my opinion it should be the way Harmony
is initially ported. People who want to do a new port can then port
APR. (Or, perhaps they could strip out the APR-using code from Harmony
and do a "raw" port.)
Experience with libgcj suggests that OS porting layer has few tricky
parts[1]. The bulk of the code -- file and network I/O, for instance --
is simple and porting it doesn't represent a major effort. I think our
"posix" port (includes linux, solaris, macos x) is about 4 KLOC. The
Windows-specific code is about 5 KLOC. That's not much.
Tom
[1] Turning signals into exceptions is compiler, OS, and chip dependent.
This qualifies as "tricky" :-). Another occasionally tricky thing is
interfacing between the GC and the native thread system -- finding
stack bounds, noticing thread creation, etc. I would guess that APR
doesn't yet have support for these kinds of things, though I have not
looked. Note that these are not "pure" OS-dependent areas but are also
impacted by decisions in other parts of the VM: exception handling
approach, null pointer detection approach, GC approach, etc.
Re: [arch] Modular JVM component diagram
Posted by Xiao-Feng Li <xi...@gmail.com>.
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, which are lacked in POSIX. And APR is
available on a couple of different platforms. Yes, POSIX is availabe
on some non-UNIX systems too, e.g., one can use POSIX on Windows
through Windows Services for UNIX or Cygwin.
I'd like to hear how other people think. Folks on the mailing list, comments?
Thanks,
xiaofeng
On 8/29/05, Ron Braithwaite <ro...@braithwaites.net> wrote:
> 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, and
> > IBM Portability Library. For ease of portability across a broad
> > range of
> > platforms, I suggest that we use APR as the portability api. Do
> > folks on the
> > mailing list think that this is a good idea?
> >
> > Thanks,
> > xiaofeng
>
> <delurk>
>
> As an intensely interested bystander, I'll just kick in my two cents
> here. Posix compliance is a really good idea, since it is so
> frequently specified by so many corporate and governmental policies
> and regulations (e.g., AFIPS, if memory serves).
>
> Yes, there are some portable API libraries out there that are
> superior in certain aspects to Posix. But I think the repercussions
> of not being Posix-compliant are going to cost more than any gains
> from specific gains by a less ubiquitous library.
>
> Just my two cents worth.
>
> Peace,
> -Ron
> </delurk>
>
> Ron Braithwaite
> 2015 NE 37th Ave
> Portland, OR 97212 USA
> 503-267-3250
> ron@braithwaites.net
>
>
Re: [arch] Modular JVM component diagram
Posted by Ron Braithwaite <ro...@braithwaites.net>.
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, and
> IBM Portability Library. For ease of portability across a broad
> range of
> platforms, I suggest that we use APR as the portability api. Do
> folks on the
> mailing list think that this is a good idea?
>
> Thanks,
> xiaofeng
<delurk>
As an intensely interested bystander, I'll just kick in my two cents
here. Posix compliance is a really good idea, since it is so
frequently specified by so many corporate and governmental policies
and regulations (e.g., AFIPS, if memory serves).
Yes, there are some portable API libraries out there that are
superior in certain aspects to Posix. But I think the repercussions
of not being Posix-compliant are going to cost more than any gains
from specific gains by a less ubiquitous library.
Just my two cents worth.
Peace,
-Ron
</delurk>
Ron Braithwaite
2015 NE 37th Ave
Portland, OR 97212 USA
503-267-3250
ron@braithwaites.net
Re: [arch] Modular JVM component diagram
Posted by Xiao-Feng Li <xi...@gmail.com>.
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 across a broad range of
platforms, I suggest that we use APR as the portability api. Do folks on the
mailing list think that this is a good idea?
Thanks,
xiaofeng
On 8/20/05, Tom <ec...@gatewide.com> wrote:
>
> 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
> target to get the JVM to run. This will help to use Harmony with
> different bootpaths later on. For example, the VM will not require
> libraries for X-Path and database operations, or will it? (They seem to
> be required to run libapr0 in your link)
>
> Thanks
> Tom
>
> Joerg Wendland wrote:
> > *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 compiles, runs and is supported on
> > these architectures plus nine others.
> >
> > Cheers,
> > Jörg
> >
> > [0] http://packages.debian.org/unstable/net/libapr0
> >
>
Re: [arch] Modular JVM component diagram
Posted by Tom <ec...@gatewide.com>.
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
target to get the JVM to run. This will help to use Harmony with
different bootpaths later on. For example, the VM will not require
libraries for X-Path and database operations, or will it? (They seem to
be required to run libapr0 in your link)
Thanks
Tom
Joerg Wendland wrote:
> *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 compiles, runs and is supported on
> these architectures plus nine others.
>
> Cheers,
> Jörg
>
> [0] http://packages.debian.org/unstable/net/libapr0
>
Re: [arch] Modular JVM component diagram
Posted by Joerg Wendland <we...@scan-plus.de>.
*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 compiles, runs and is supported on
these architectures plus nine others.
Cheers,
Jörg
[0] http://packages.debian.org/unstable/net/libapr0
--
| ScanPlus GmbH F&E fon +49-731-92013-0 |
| Griesbadgasse 7, 89073 Ulm, Germany fax +49-731-92013-159 |
| Geschaeftsfuehrer: Juergen Hoermann HRB 3220 Amtsgericht Ulm |
| PGP 51CF8417 (FP: 79C0 7671 AFC7 315E 657A F318 57A3 7FBD 51CF 8417) |
Re: [arch] Modular JVM component diagram
Posted by Mladen Turk <mt...@apache.org>.
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 not supported, and the CE port itself was
not very much maintained recently. I did initial port together with
OtherBill and others, but since there were no 'real usage' the port
itself was not maintained as it should be.
OTOH the 'core' functionality, like file, network, threading, signaling
is working, so the refresh itself would not take many hours.
I can not speak on Linux based embedded platforms, but since it should
be a POSIX underneath, I see no major problems for that platform either.
Regards,
Mladen.
Re: [arch] Modular JVM component diagram
Posted by Tom <ec...@gatewide.com>.
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 MIPS.
What are there any good alternative projects to APR? All portable
embedded apps I have worked on either did not have the porting
requirement or rolled their own porting layer, always around Berkely
sockets, sometime around POSIX threading.
As I do not have any APR porting experience on my own I tried to use
google to get an estimate of what has been done in regards to APR ports
for these three:
The number of hits for "Apache Portable Runtime", "ARM", "PowerPC" and
"MIPS" produced quite a few hits on Google. (647, 645 and 468,
respectively)
So, rather encouraging, but if someone could post his own experience on
porting APR this would certainly be more helpful than my Google-guessing.
Thanks
Tom
Ricardo Morin 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 interface
> groups.
>
> Thank you,
>
> Ricardo
>
> http://wiki.apache.org/harmony/HarmonyArchitecture
>
> --- Tim Ellison <t....@gmail.com> wrote:
>
>
>>Ricardo,
>>
>>Do you intend to put some words to your attachment?
>
>
> <snip>
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - You care about security. So do we.
> http://promotions.yahoo.com/new_mail
>
>
Re: [arch] Modular JVM component diagram
Posted by Ricardo Morin <mo...@yahoo.com>.
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
http://wiki.apache.org/harmony/HarmonyArchitecture
--- Tim Ellison <t....@gmail.com> wrote:
> Ricardo,
>
> Do you intend to put some words to your attachment?
<snip>
__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail
Re: [arch] Modular JVM component diagram
Posted by Ricardo Morin <mo...@yahoo.com>.
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 <t....@gmail.com> wrote:
> Ricardo,
>
> Do you intend to put some words to your attachment?
> I took a look but
> it didn't make much sense to me without
> understanding the notations and
> colors you adopted.
>
> But... it did cause me to go back and re-read Jon's
> original
> architecture proposal. I broadly agree with the
> proposal, and have the
> following minor comments:
>
> - Can we avoid calling the class library project
> "classpath", unless we
> specifically mean GNU Classpath?
>
> - I'm pleased to see the "development facilities"
> subproject taking a
> major role; however, the proposal says that the
> development facilites
> should be "stripped from the build for
> non-development releases". I
> suggest that we design the trace / debug facilities
> in such a way that
> they can be left in all builds, and enabled at
> different levels
> appropriate to the usage requirements from
> development to end-user.
>
> - The claim is that "The main Harmony project in
> terms of volume is
> likely the JVM project" -- if we are on the hook to
> do a classlibrary
> implementation that will dwarf the VM in terms of
> volume ;-/
>
> - Although not shown in the diagram, I'm assuming
> that the core
> interpreter comes under the Runtime Project in JVM.
>
> - The "VM Core Sub-components" that dims added is a
> good list of things
> that will be addressed in the vm-core. Some of
> these have a natural
> grouping.
>
> - I'd vote that the "J2SDK Toolkit" be
> predominantly written in Java
> and avoid the requirement for the CTL.
>
> Regards,
> Tim
>
>
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
Re: [arch] Modular JVM component diagram
Posted by Tim Ellison <t....@gmail.com>.
Ricardo,
Do you intend to put some words to your attachment? I took a look but
it didn't make much sense to me without understanding the notations and
colors you adopted.
But... it did cause me to go back and re-read Jon's original
architecture proposal. I broadly agree with the proposal, and have the
following minor comments:
- Can we avoid calling the class library project "classpath", unless we
specifically mean GNU Classpath?
- I'm pleased to see the "development facilities" subproject taking a
major role; however, the proposal says that the development facilites
should be "stripped from the build for non-development releases". I
suggest that we design the trace / debug facilities in such a way that
they can be left in all builds, and enabled at different levels
appropriate to the usage requirements from development to end-user.
- The claim is that "The main Harmony project in terms of volume is
likely the JVM project" -- if we are on the hook to do a classlibrary
implementation that will dwarf the VM in terms of volume ;-/
- Although not shown in the diagram, I'm assuming that the core
interpreter comes under the Runtime Project in JVM.
- The "VM Core Sub-components" that dims added is a good list of things
that will be addressed in the vm-core. Some of these have a natural
grouping.
- I'd vote that the "J2SDK Toolkit" be predominantly written in Java
and avoid the requirement for the CTL.
Regards,
Tim
Ricardo Morin wrote:
> 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 suggested structure and then
> proceed to describe and define the components and
> interfaces in more detail, based on our discussions.
>
> http://wiki.apache.org/harmony/HarmonyArchitecture
>
> http://wiki.apache.org/harmony-data/attachments/HarmonyArchitecture/attachments/ModularJVM.jpg
>
> Comments? Ideas?
>
> Thank you,
>
> Ricardo
>
> ____________________________________________________
> Start your day with Yahoo! - make it your home page
> http://www.yahoo.com/r/hs
>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [arch] Modular JVM component diagram
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
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 Wiki page. The diagram drills down
> on the "Modular Structure JVM Components" section by
> depicting the major components and interfaces. I
> propose discussing the suggested structure and then
> proceed to describe and define the components and
> interfaces in more detail, based on our discussions.
>
> http://wiki.apache.org/harmony/HarmonyArchitecture
>
> http://wiki.apache.org/harmony-data/attachments/HarmonyArchitecture/
> attachments/ModularJVM.jpg
>
> Comments? Ideas?
>
> Thank you,
>
> Ricardo
>
>
>
>
> ____________________________________________________
> Start your day with Yahoo! - make it your home page
> http://www.yahoo.com/r/hs
>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org