Damien Neil [EMAIL PROTECTED] wrote:
The JVM is a stack machine. JVM opcodes operate on the stack, not on
main memory. The stack is thread-local. In order for a thread to operate
on a variable, therefore, it must first copy it from main store to thread-
local store (the stack).
Silly me,
On Jan 17, 2004, at 2:58 AM, Leopold Toetsch wrote:
Damien Neil [EMAIL PROTECTED] wrote:
The JVM is a stack machine. JVM opcodes operate on the stack, not on
main memory. The stack is thread-local. In order for a thread to
operate
on a variable, therefore, it must first copy it from main
Damien Neil [EMAIL PROTECTED] wrote:
On Thu, Jan 15, 2004 at 09:31:39AM +0100, Leopold Toetsch wrote:
I don't see any advantage of such a model. The more as it doesn't
gurantee any atomic access to e.g. long or doubles. The atomic access to
ints and pointers seems to rely on the architecture
On Jan 15, 2004, at 10:55 PM, Leopold Toetsch wrote:
Damien Neil [EMAIL PROTECTED] wrote:
On Thu, Jan 15, 2004 at 09:31:39AM +0100, Leopold Toetsch wrote:
I don't see any advantage of such a model. The more as it doesn't
gurantee any atomic access to e.g. long or doubles. The atomic
access to
On Thu, Jan 15, 2004 at 11:58:22PM -0800, Jeff Clites wrote:
On Jan 15, 2004, at 10:55 PM, Leopold Toetsch wrote:
Yes, that's what I'm saying. I don't see an advantage of JVMs
multi-step
variable access, because it even doesn't provide such atomic access.
You're missing the point of the
On Friday, January 16, 2004, at 02:58 , Jeff Clites wrote:
On Jan 15, 2004, at 10:55 PM, Leopold Toetsch wrote:
Damien Neil [EMAIL PROTECTED] wrote:
On Thu, Jan 15, 2004 at 09:31:39AM +0100, Leopold Toetsch wrote:
I don't see any advantage of such a model. The more as it doesn't
gurantee any
On Friday, January 16, 2004, at 08:38 , Jeff Clites wrote:
On Jan 16, 2004, at 1:01 PM, Damien Neil wrote:
On Thu, Jan 15, 2004 at 11:58:22PM -0800, Jeff Clites wrote:
On Jan 15, 2004, at 10:55 PM, Leopold Toetsch wrote:
Yes, that's what I'm saying. I don't see an advantage of JVMs
multi-step
Jeff Clites [EMAIL PROTECTED] wrote:
[ threaded var access: read - load - use ... ]
In any case, I thought this sounded like an interesting model,
I don't see any advantage of such a model. The more as it doesn't
gurantee any atomic access to e.g. long or doubles. The atomic access to
ints and
-Original Message-
From: Jeff Clites [mailto:[EMAIL PROTECTED]
Sent: Thursday January 15, 2004 01:28
To: Gordon Henriksen
Cc: [EMAIL PROTECTED]
Subject: Re: JVM as a threading example (threads proposal)
On Jan 12, 2004, at 10:03 AM, Gordon Henriksen wrote:
On Monday
On Thu, Jan 15, 2004 at 09:31:39AM +0100, Leopold Toetsch wrote:
I don't see any advantage of such a model. The more as it doesn't
gurantee any atomic access to e.g. long or doubles. The atomic access to
ints and pointers seems to rely on the architecture but is of course
reasonable.
You
On Jan 12, 2004, at 10:03 AM, Gordon Henriksen wrote:
On Monday, January 12, 2004, at 04:29 , Jeff Clites wrote:
5) Java seems to use a check-in/check-out model for access to global
data, in which global data lives in a central store, but is copied
back-and-forth to thread-local storage for
This is a threading proposal, in the form of a collection of notes.
Rationale:
We need to constantly compare parrot to the JVM, and in particular have
a deep understanding of cases where the JVM performs well (or better
than parrot). The reason for this is obvious: the JVM is the product of
At 01:29 -0800 1/12/04, Jeff Clites wrote:
I'll publish some actual benchmarking numbers, with source code,
separately. (They're just sort of interesting to have on hand.)
If you're benchmarking Perl 5 ithreads for memory usage, you might
want to have a look at Benchmark::Thread::Size.
Liz
On Monday, January 12, 2004, at 04:29 , Jeff Clites wrote:
5) Java seems to use a check-in/check-out model for access to global
data, in which global data lives in a central store, but is copied
back-and-forth to thread-local storage for modification. I don't fully
understand the
14 matches
Mail list logo
