On 24 September 2006 at 14:29, Nathan Beyer [EMAIL PROTECTED] wrote:
* I think we should utilize the Accessor classes in 'misc' (in place
of Objects), but I think these all need to be refactored into a kernel
or VM module. I really don't like the 'misc' naming, as it make it
seem like it's
Andrey Chernyshev wrote:
On 9/22/06, Tim Ellison [EMAIL PROTECTED] wrote:
snip
There is a set of informational methods one would need to access
objects and arrays, regardless of whether the access is going to be
ordinary, volatile or atomic. They are sort of like (I'm taking the
signatures
On Sep 26, 2006, at 6:36 AM, Tim Ellison wrote:
Nathan Beyer wrote:
and there's no mapping from Unsafe's relative/scaled access for
array elements.
* I don't think there is any value in separating the atomic
compare and swap
method into a concurrency-kernel; there are only three
-Original Message-
From: Andrey Chernyshev [mailto:[EMAIL PROTECTED]
Sent: Sunday, September 24, 2006 6:44 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][vmi] VMI classes for Thread/Object manipulation
for java.util.concurrent
On 9/22/06, Tim Ellison [EMAIL PROTECTED] wrote
VM).
Regards,
Tim
-Nathan
-Original Message-
From: Andrey Chernyshev [mailto:[EMAIL PROTECTED]
Sent: Sunday, September 24, 2006 6:44 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][vmi] VMI classes for Thread/Object manipulation
for java.util.concurrent
On 9/22
Andrey Chernyshev wrote:
So if we built the full code path, would the picture be like:
j.u.concurrent.atomic.Atomic //
| // untouched JSR 166
\/ //
Unsafe
Geir Magnusson Jr. wrote:
On Sep 26, 2006, at 6:36 AM, Tim Ellison wrote:
It sounds like you prefer not to split them, which would put an extra
burden on the VM-port to implement more stuff. If they were split then
the consumer (classlib developer) would/may have to use both types.
Is that
On Sep 26, 2006, at 1:16 PM, Tim Ellison wrote:
Geir Magnusson Jr. wrote:
On Sep 26, 2006, at 6:36 AM, Tim Ellison wrote:
It sounds like you prefer not to split them, which would put an
extra
burden on the VM-port to implement more stuff. If they were
split then
the consumer (classlib
-Original Message-
From: Tim Ellison [mailto:[EMAIL PROTECTED]
Andrey Chernyshev wrote:
So if we built the full code path, would the picture be like:
j.u.concurrent.atomic.Atomic //
| // untouched JSR 166
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
On Sep 26, 2006, at 1:16 PM, Tim Ellison wrote:
Geir Magnusson Jr. wrote:
On Sep 26, 2006, at 6:36 AM, Tim Ellison wrote:
It sounds like you prefer not to split them, which would put an
extra
burden on
, September 24, 2006 6:44 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][vmi] VMI classes for Thread/Object
manipulation
for java.util.concurrent
On 9/22/06, Tim Ellison [EMAIL PROTECTED] wrote:
Andrey Chernyshev wrote:
On 9/20/06, Tim Ellison [EMAIL PROTECTED] wrote:
Andrey
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Sunday, September 24, 2006 2:37 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][vmi] VMI classes for Thread/Object manipulation
for java.util.concurrent
On Sep 24, 2006, at 3:29 PM
-Original Message-
From: Andrey Chernyshev [mailto:[EMAIL PROTECTED]
Sent: Sunday, September 24, 2006 6:44 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][vmi] VMI classes for Thread/Object
manipulation
for java.util.concurrent
On 9/22/06, Tim Ellison [EMAIL PROTECTED] wrote:
Andrey
On 9/20/06, Tim Ellison [EMAIL PROTECTED] wrote:
Andrey Chernyshev wrote:
Thanks Nathan! The Threads interface looks fine. Still, may be it
would be nice if two different methods are allocated for parkNanos and
parkUntil - passing the extra boolean parameter seems like an
overhead, though
On 9/21/06, Nathan Beyer [EMAIL PROTECTED] wrote:
-Original Message-
From: Tim Ellison [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 20, 2006 8:11 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][vmi] VMI classes for Thread/Object manipulation
Andrey Chernyshev wrote:
On 9/21/06, Nathan Beyer [EMAIL PROTECTED] wrote:
From: Tim Ellison
snip
I'll add a factory/singleton method, which can be used then perform any
security checks. Then I presume other Classlib code would invoke this via
PrivilegedAction, correct?
The other option
Andrey Chernyshev wrote:
On 9/20/06, Tim Ellison [EMAIL PROTECTED] wrote:
Andrey Chernyshev wrote:
Thanks Nathan! The Threads interface looks fine. Still, may be it
would be nice if two different methods are allocated for parkNanos and
parkUntil - passing the extra boolean parameter seems
, September 20, 2006 8:11 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][vmi] VMI classes for Thread/Object manipulation
for java.util.concurrent
Andrey Chernyshev wrote:
Thanks Nathan! The Threads interface looks fine. Still, may be it
would be nice if two different methods
: Tim Ellison [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 20, 2006 8:11 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][vmi] VMI classes for Thread/Object
manipulation
for java.util.concurrent
Andrey Chernyshev wrote:
Thanks Nathan! The Threads interface looks fine. Still
Moved.
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 21, 2006 5:14 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][vmi] VMI classes for Thread/Object manipulation
for java.util.concurrent
+1
On Sep 21, 2006
Andrey Chernyshev wrote:
Thanks Nathan! The Threads interface looks fine. Still, may be it
would be nice if two different methods are allocated for parkNanos and
parkUntil - passing the extra boolean parameter seems like an
overhead, though very little.
I agree, just create another method
-Original Message-
From: Tim Ellison [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 20, 2006 8:11 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][vmi] VMI classes for Thread/Object manipulation
for java.util.concurrent
Andrey Chernyshev wrote:
Thanks
On 9/18/06, Nathan Beyer [EMAIL PROTECTED] wrote:
I've added some classes[1][2] to luni-kernel in the
org.apache.harmony.kernel.vm package that are intended the VMI replacement
for the sun.misc.Unsafe class. The intent is to provide a VMI class to
support java.util.concurrent. Initially this
Thanks Nathan -- I'll take a look and post comments back here.
Regards,
Tim
Nathan Beyer wrote:
I've added some classes[1][2] to luni-kernel in the
org.apache.harmony.kernel.vm package that are intended the VMI replacement
for the sun.misc.Unsafe class. The intent is to provide a VMI class to
I've added some classes[1][2] to luni-kernel in the
org.apache.harmony.kernel.vm package that are intended the VMI replacement
for the sun.misc.Unsafe class. The intent is to provide a VMI class to
support java.util.concurrent. Initially this will be done by implementing
the sun.misc.Unsafe in
25 matches
Mail list logo
