Re: [classlib][drlvm] integrating j.u.c with drlvm

[Rustem Rafikov]

Nathan,
I created ISSUE#*1144, *
Please try the patches attached.

--bwR

RE: [classlib][drlvm] integrating j.u.c with drlvm

[Nathan Beyer]

Go for it; looking forward to it.

-Nathan

> -Original Message-
> From: Rustem Rafikov [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 08, 2006 5:08 AM
> To: harmony-dev@incubator.apache.org
> Cc: [EMAIL PROTECTED]
> Subject: Re: [classlib][drlvm] integrating j.u.c with drlvm
> 
> As a first step I would like to implement the following methods:
> 1. getFieldOffset - it may be done by forwarding call to
> ObjectAccessor.getFieldID or by JNI wrapping of existing impl in
> atomics.cpp.
> The second, I think, is preferable because we avoid further conversion of
> fieldID to field offset on each CAS call (in common case).  But in this
> case
> we will need to implement set/getVolatile instead of using the impl from
> ObjectAccessor.
> 2. compareAndSet* - to implement this I need to change interface of cas
> methods in the Atomics.java to use long field IDs.
> 
> If nobody has objections  I am going to prepare a patch adding this
> implementation.
> 
> Rustem Rafikov
> Intel Middleware Products Division
> 
> On 8/7/06, Andrey Chernyshev <[EMAIL PROTECTED]> wrote:
> >
> > On 8/7/06, Nathan Beyer <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > > > -Original Message-
> > > > From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED]
> > > >
> > > > On of the technical things we have to do still for
> > java.util.concurrent
> > > > is to create sun.misc.Unsafe for the VMs and see how things work
> > together.
> > > >
> > > > How much work will it be for DRLVM?
> > >
> > > Some of it seems to be available in a class called
> > > "org.apache.harmony.util.concurrent.Atomics", at least the CAS stuff.
> > > There's a replacement for java.util.concurrent.locks.LockSupport in
> the
> > > DRLVM source that has a JNI complement, but this will need to be
> > converted
> > > to be used within sun.misc.Unsafe.
> > >
> > > The other major missing piece is the object field manipulation and the
> > > volatile set of those fields as well. Some of this may already be
> > available,
> > > but I don't know for sure.
> >
> > Would the accessors package available at
> >
> >
> classlib/trunk/modules/misc/src/main/java/org/apache/harmony/misc/accessor
> s
> > suite these needs? May be the ObjectAccessor and ArrayAccessor classes
> > could help. They don't, however, provide a volatile access support
> > yet. But, it probably can be added with the help of
> > MemoryReadWriteBarrier() function defined in
> > drlvm/trunk/vm/vmcore/include/atomics.h.
> >
> > BTW: what if we use a simple access instead of the volatile one for a
> > while, is this API frequently used (compared to the other
> > util.concurrent ones)? May be we could adopt concurrent in several
> > steps. First, add lock support and the basic CAS operations, then add
> > volatile access e.t.c.
> >
> > Thanks,
> > Andrey.
> >
> > >
> > > -Nathan
> > >
> > > >
> > > > geir
> > > >
> > >
> > >
> > >
> > > -
> > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> >
> > --
> > Andrey Chernyshev
> > Intel Middleware Products Division
> >
> > -
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib][drlvm] integrating j.u.c with drlvm

[Rustem Rafikov]

As a first step I would like to implement the following methods:
1. getFieldOffset - it may be done by forwarding call to
ObjectAccessor.getFieldID or by JNI wrapping of existing impl in atomics.cpp.
The second, I think, is preferable because we avoid further conversion of
fieldID to field offset on each CAS call (in common case).  But in this case
we will need to implement set/getVolatile instead of using the impl from
ObjectAccessor.
2. compareAndSet* - to implement this I need to change interface of cas
methods in the Atomics.java to use long field IDs.

If nobody has objections  I am going to prepare a patch adding this
implementation.

Rustem Rafikov
Intel Middleware Products Division

On 8/7/06, Andrey Chernyshev <[EMAIL PROTECTED]> wrote:


On 8/7/06, Nathan Beyer <[EMAIL PROTECTED]> wrote:
>
>
> > -Original Message-
> > From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED]
> >
> > On of the technical things we have to do still for
java.util.concurrent
> > is to create sun.misc.Unsafe for the VMs and see how things work
together.
> >
> > How much work will it be for DRLVM?
>
> Some of it seems to be available in a class called
> "org.apache.harmony.util.concurrent.Atomics", at least the CAS stuff.
> There's a replacement for java.util.concurrent.locks.LockSupport in the
> DRLVM source that has a JNI complement, but this will need to be
converted
> to be used within sun.misc.Unsafe.
>
> The other major missing piece is the object field manipulation and the
> volatile set of those fields as well. Some of this may already be
available,
> but I don't know for sure.

Would the accessors package available at

classlib/trunk/modules/misc/src/main/java/org/apache/harmony/misc/accessors
suite these needs? May be the ObjectAccessor and ArrayAccessor classes
could help. They don't, however, provide a volatile access support
yet. But, it probably can be added with the help of
MemoryReadWriteBarrier() function defined in
drlvm/trunk/vm/vmcore/include/atomics.h.

BTW: what if we use a simple access instead of the volatile one for a
while, is this API frequently used (compared to the other
util.concurrent ones)? May be we could adopt concurrent in several
steps. First, add lock support and the basic CAS operations, then add
volatile access e.t.c.

Thanks,
Andrey.

>
> -Nathan
>
> >
> > geir
> >
>
>
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
Andrey Chernyshev
Intel Middleware Products Division

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib][drlvm] integrating j.u.c with drlvm

[Andrey Chernyshev]

On 8/7/06, Nathan Beyer <[EMAIL PROTECTED]> wrote:



> -Original Message-
> From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED]
>
> On of the technical things we have to do still for java.util.concurrent
> is to create sun.misc.Unsafe for the VMs and see how things work together.
>
> How much work will it be for DRLVM?

Some of it seems to be available in a class called
"org.apache.harmony.util.concurrent.Atomics", at least the CAS stuff.
There's a replacement for java.util.concurrent.locks.LockSupport in the
DRLVM source that has a JNI complement, but this will need to be converted
to be used within sun.misc.Unsafe.

The other major missing piece is the object field manipulation and the
volatile set of those fields as well. Some of this may already be available,
but I don't know for sure.


Would the accessors package available at
classlib/trunk/modules/misc/src/main/java/org/apache/harmony/misc/accessors
suite these needs? May be the ObjectAccessor and ArrayAccessor classes
could help. They don't, however, provide a volatile access support
yet. But, it probably can be added with the help of
MemoryReadWriteBarrier() function defined in
drlvm/trunk/vm/vmcore/include/atomics.h.

BTW: what if we use a simple access instead of the volatile one for a
while, is this API frequently used (compared to the other
util.concurrent ones)? May be we could adopt concurrent in several
steps. First, add lock support and the basic CAS operations, then add
volatile access e.t.c.

Thanks,
Andrey.



-Nathan

>
> geir
>



-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Andrey Chernyshev
Intel Middleware Products Division

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [classlib][drlvm] integrating j.u.c with drlvm

[Nathan Beyer]

> -Original Message-
> From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED]
> 
> On of the technical things we have to do still for java.util.concurrent
> is to create sun.misc.Unsafe for the VMs and see how things work together.
> 
> How much work will it be for DRLVM?

Some of it seems to be available in a class called
"org.apache.harmony.util.concurrent.Atomics", at least the CAS stuff.
There's a replacement for java.util.concurrent.locks.LockSupport in the
DRLVM source that has a JNI complement, but this will need to be converted
to be used within sun.misc.Unsafe.

The other major missing piece is the object field manipulation and the
volatile set of those fields as well. Some of this may already be available,
but I don't know for sure.

-Nathan

> 
> geir
> 



-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[classlib][drlvm] integrating j.u.c with drlvm

[Geir Magnusson Jr]

On of the technical things we have to do still for java.util.concurrent
is to create sun.misc.Unsafe for the VMs and see how things work together.

How much work will it be for DRLVM?

geir

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]