On Thu, 2005-05-26 at 15:43 -0400, Geir Magnusson Jr. wrote:
This isn't an immediate goal, but certainly would be something to
keep in mind when architecting ? I mean, you can certainly see VMs
being incorporated into the OS?
Hmmm. Interesting...
You are talking about a VM becoming part
On May 27, 2005, at 6:12 PM, Matthew French wrote:
On Thu, 2005-05-26 at 15:43 -0400, Geir Magnusson Jr. wrote:
This isn't an immediate goal, but certainly would be something to
keep in mind when architecting ? I mean, you can certainly see VMs
being incorporated into the OS?
Hmmm.
Xiao-Feng Li said:
People usually develop memory manager for OS kernel at multiple levels
for a variety of purposes. It's not limited to the hardware page
granularity. People just don't call them GC in OS kernel.
Hmmm. We are getting off topic here. Ironically I think we also have a
problem
On May 25, 2005, at 11:04 PM, Steve Blackburn wrote:
Weldon Washburn wrote:
You advocate starting from a clean slate.
[Interpreting the above as a comment about the harmony project as a
whole...]
That's not my position at all.
, too)
RB
-Original Message-
From: Steve Blackburn [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 25, 2005 4:57 PM
To: Weldon Washburn
Cc: harmony-dev@incubator.apache.org
Subject: Re: Terminology etc
Weldon Washburn wrote:
a)
Inlining ap
On 5/25/05, Steve Blackburn [EMAIL PROTECTED] wrote:
I agree it is orthogonal to the language chosen to write the JIT. It
is not orthogonal to the language chosen to write the GC.
As you say, you really want the barrier expressed in either Java,
bytecode or IR. So you could write your GC in
Hi Weldon,
One reason is that Harmony will need to plug in GCs other than MMTk.
Absolutely. MMTk was designed from the outset with this in mind (at the
time Jikes RVM already had another set of collectors).
Another reason is that in the long term the JVM's memory manager (GC)
probably
PROTECTED]
Sent: Wednesday, May 25, 2005 11:33 PM
To: harmony-dev@incubator.apache.org
Subject: Re: Terminology etc
On 5/25/05, Steve Blackburn [EMAIL PROTECTED] wrote:
I agree it is orthogonal to the language chosen to write the JIT. It
is not orthogonal to the language chosen to write the GC
Weldon Washburn wrote:
You advocate starting from a clean slate.
[Interpreting the above as a comment about the harmony project as a
whole...]
That's not my position at all.
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200505.mbox/[EMAIL
PROTECTED]
I advocate a
I thought it might be helpful to clarify some terminology and a few
technical issues. Corrections/improvements/clarifications welcome ;-)
VM core
The precise composition of the VM core is open to discussion and
debate. However, I think a safe, broad definition of it is that
part of the VM
2005/5/24, Steve Blackburn [EMAIL PROTECTED]:
I thought it might be helpful to clarify some terminology and a few
technical issues. Corrections/improvements/clarifications welcome ;-)
Scheduled for translation...
Raffaele
This is excellent! For one, I find Java-in-Java to be much clearer after
this little set of definitions.
A quick proposal: perhaps VM bootstrap as used below should really be
something like VM initialization, VM init, or even VM startup,
since the word bootstrap is very specific and to me at
A question (sorry)： would it include realtime capabilities?
Current
systems are sometimes real nightmares from this point of view and it is a
must have for embedded systems...
I certainly hope so... I don't believe it is beyond us to achieve that.
That
Hi, on the subject of terminology, when you say scheduling, what do you
mean exactly? Are you talking about monitors and other sync issues or are
you talking about some kind of m:n thread scheduling? Or neither? :)
Cheers,
Dave
On 5/24/05, Steve Blackburn [EMAIL PROTECTED] wrote:
Dmitry
2005/5/24, David Griffiths [EMAIL PROTECTED]:
Hi, on the subject of terminology, when you say scheduling, what do you
mean exactly? Are you talking about monitors and other sync issues or are
you talking about some kind of m:n thread scheduling? Or neither? :)
I'm talking about that I'm
I've added this to the wiki and linked from the main page.
- Original Message -
From: Steve Blackburn [EMAIL PROTECTED]
To: harmony-dev@incubator.apache.org
Sent: Tuesday, May 24, 2005 8:05 AM
Subject: Terminology etc
I thought it might be helpful to clarify some terminology
There isn't much space for plugability of components beyond compile-link
time. And I see no reason to have it otherwise.
Rodrigo
On 5/24/05, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
On May 24, 2005, at 4:49 AM, Dmitry Serebrennikov wrote:
* OS interface is perhaps one place where
Steve, this clarification of terminology helped me a lot to understand
your approach better. As Java-in-C camper I can even see now the
advantages in the approach. But just let me add my 2 cents of pretty
wild ideas.
Having read your MMTk papers, it appears to me that the required
JAVA extensions
I think you dind't quite get how it works with MMtk. There are a few
magic classes that receive special treatment from the compiler and
translates method calls into pointer operations. This way MMtk can operate
under the same condition of C code.
I'm not sure how did you relate interface
Steve, if the spokes were in Java but the hub in C, would we then lose
all of the aggressive inlining benefits that Java-in-Java solution can
provide?
I don't know. These are really interesting questions and ones I think
we need to hear lots of informed opinion on. My experience
20 matches
Mail list logo
