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 st
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
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
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 ato
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
variable access, because it even doesn't provide such atomic ac
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 th
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
in
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 archit
On Wed, Jan 14, 2004 at 10:28:25PM -0800, Jeff Clites wrote:
> You might be right, but that's not exactly how I read it, because later
> it says, "A use action (by a thread) transfers the contents of the
> thread's working copy of a variable to the thread's execution engine.
> This action is per
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 *
> -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
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
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
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 performan
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
15 matches
Mail list logo