You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Pavel Pervov <pm...@gmail.com> on 2006/11/07 10:59:23 UTC
[classlib][concurrent] Complete support?
I've found the following issues with this package:
1) Natives are missing. In particular,
java.util.concurrent.atomic.AtomicLong.VMSupportsCS8 looks like should be
implemented on VM side.
2) ant test -Dbuild.module=concurrent does not work. The output is as
follows:
support-jar:
[jar] Building jar:
C:\_work_\harmony\enhanced\classlib\trunk\deploy\build
\test\support.jar
test-modules:
test:
full-report:
BUILD FAILED
C:\_work_\harmony\enhanced\classlib\trunk\build.xml:167: The following error
occ
urred while executing this line:
C:\_work_\harmony\enhanced\classlib\trunk\make\build-test.xml:58:
C:\_work_\harm
ony\enhanced\classlib\trunk\build\test_report not found.
Do I miss something important?
--
Pavel Pervov,
Intel Enterprise Solutions Software Division
Re: [classlib][concurrent] Complete support?
Posted by Andrey Chernyshev <a....@gmail.com>.
On 11/9/06, Nathan Beyer <nb...@gmail.com> wrote:
> On 11/8/06, Andrey Chernyshev <a....@gmail.com> wrote:
> > On 11/8/06, Tim Ellison <t....@gmail.com> wrote:
> > > Nathan Beyer wrote:
> > > > Instead of continuing to add functionality to the DRLVM-specific
> > > > Atomics class, I'd like to get a consensus on the Threads/Objects
> > > > (include CAS operations) interfaces in luni-kernel. Then we can get
> >
> > Seems like last time we converged that the accessors package has to be
> > complemented with atomic/volatile operations, but pure-JNI and
> > VM-dependent pieces have to be kept separately (pure pieces would have
> > to go to the luni and VM-dependent pieces would go to kernel). Each
> > accessor also needs to be made singleton with the security check
> > incorporated. Is my understanding correct?
> >
> > The proposed "Threads" interface was just fine. Nathan, will you be
> > also proposing updates for the accessor interfaces?
>
> Are you referring to the accessor interfaces from the 'misc' module?
Yes, I was meaning accessors from the 'misc' module, in particular these ones:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/misc/src/main/java/org/apache/harmony/misc/accessors/ObjectAccessor.java?view=markup
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/misc/src/main/java/org/apache/harmony/misc/accessors/ArrayAccessor.java?view=markup
May be we just need to add into this set an "ExtendedObjectAccessor"
with the methods like:
compareAndSetX(Object o, long fieldID, X expected, X value);
setXVolatile(Object o, long fieldID, X value);
plus equivalent class "ExtendedArrayAccessor" with methods like:
compareAndSetX(X[] arr, int index, X expected, X value);
setXVolatile(X[] arr, int index, X value);
Internally, our Unsafe implementation may choose which accessor to use
(either Array or Object) depending on the object type.
Extended classes may become part of kernel and the "regular" ones can
be kept in luni (as VM-independent).
We can name these classes differently ("Objects" or whatever), if the
*Accessor names do not seem good enough (but I guess it won't change
the meaning).
Thanks,
Andrey.
> Are there some others hanging around?
>
> I'm open to suggestions for additional methods for Objects.
>
> -Nathan
>
> >
> > Thanks,
> > Andrey.
> >
> >
> > > > DRLVM to implement these classes and the donated IBM VM to do the same
> > > > so we can have concurrent support from both VMs.
> > >
> > > +1
> > >
> > > --
> > >
> > > Tim Ellison (t.p.ellison@gmail.com)
> > > IBM Java technology centre, UK.
> > >
> >
> >
> > --
> > Andrey Chernyshev
> > Intel Enterprise Solutions Software Division
> >
>
--
Andrey Chernyshev
Intel Middleware Products Division
Re: [classlib][concurrent] Complete support?
Posted by Nathan Beyer <nb...@gmail.com>.
On 11/8/06, Andrey Chernyshev <a....@gmail.com> wrote:
> On 11/8/06, Tim Ellison <t....@gmail.com> wrote:
> > Nathan Beyer wrote:
> > > Instead of continuing to add functionality to the DRLVM-specific
> > > Atomics class, I'd like to get a consensus on the Threads/Objects
> > > (include CAS operations) interfaces in luni-kernel. Then we can get
>
> Seems like last time we converged that the accessors package has to be
> complemented with atomic/volatile operations, but pure-JNI and
> VM-dependent pieces have to be kept separately (pure pieces would have
> to go to the luni and VM-dependent pieces would go to kernel). Each
> accessor also needs to be made singleton with the security check
> incorporated. Is my understanding correct?
>
> The proposed "Threads" interface was just fine. Nathan, will you be
> also proposing updates for the accessor interfaces?
Are you referring to the accessor interfaces from the 'misc' module?
Are there some others hanging around?
I'm open to suggestions for additional methods for Objects.
-Nathan
>
> Thanks,
> Andrey.
>
>
> > > DRLVM to implement these classes and the donated IBM VM to do the same
> > > so we can have concurrent support from both VMs.
> >
> > +1
> >
> > --
> >
> > Tim Ellison (t.p.ellison@gmail.com)
> > IBM Java technology centre, UK.
> >
>
>
> --
> Andrey Chernyshev
> Intel Enterprise Solutions Software Division
>
Re: [classlib][concurrent] Complete support?
Posted by Andrey Chernyshev <a....@gmail.com>.
On 11/8/06, Tim Ellison <t....@gmail.com> wrote:
> Nathan Beyer wrote:
> > Instead of continuing to add functionality to the DRLVM-specific
> > Atomics class, I'd like to get a consensus on the Threads/Objects
> > (include CAS operations) interfaces in luni-kernel. Then we can get
Seems like last time we converged that the accessors package has to be
complemented with atomic/volatile operations, but pure-JNI and
VM-dependent pieces have to be kept separately (pure pieces would have
to go to the luni and VM-dependent pieces would go to kernel). Each
accessor also needs to be made singleton with the security check
incorporated. Is my understanding correct?
The proposed "Threads" interface was just fine. Nathan, will you be
also proposing updates for the accessor interfaces?
Thanks,
Andrey.
> > DRLVM to implement these classes and the donated IBM VM to do the same
> > so we can have concurrent support from both VMs.
>
> +1
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
--
Andrey Chernyshev
Intel Enterprise Solutions Software Division
Re: [classlib][concurrent] Complete support?
Posted by Tim Ellison <t....@gmail.com>.
Nathan Beyer wrote:
> Instead of continuing to add functionality to the DRLVM-specific
> Atomics class, I'd like to get a consensus on the Threads/Objects
> (include CAS operations) interfaces in luni-kernel. Then we can get
> DRLVM to implement these classes and the donated IBM VM to do the same
> so we can have concurrent support from both VMs.
+1
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [classlib][concurrent] Complete support?
Posted by Nathan Beyer <nb...@gmail.com>.
On 11/8/06, Nikolay Kuznetsov <ni...@gmail.com> wrote:
> Guys,
> to get a consensus on the interfaces is very good, but this issue is
> not about interfaces. j.u.concurrent.atomic.AtomicLong in its original
> implementation has private native method: boolean VMSupportsCS8(),
> thus to work with original concurrent classes any VM should export
> following function:
> JNIEXPORT jboolean JNICALL
> Java_java_util_concurrent_atomic_AtomicLong_VMSupportsCS8(JNIEnv *,
> jclass);
>
> So the question here is what is the best place to put this function
> declaration in. For now the most logical place in DRLVM for me is:
> vmcore/src/kernel_classes/native/org_apache_harmony_util_concurrent_Atomics.h
>
> But as soon as the rest of those functions may soon be replaced with
> accessors, probably it makes sense to choose different place.
Yep, that's my thought. I would propose just moving this method to the
JNI for the Objects impl.
>
> Any thought on what is best place to put this function to?
>
> Nik.
>
>
>
> On 11/8/06, Nathan Beyer <nb...@gmail.com> wrote:
> > Instead of continuing to add functionality to the DRLVM-specific
> > Atomics class, I'd like to get a consensus on the Threads/Objects
> > (include CAS operations) interfaces in luni-kernel. Then we can get
> > DRLVM to implement these classes and the donated IBM VM to do the same
> > so we can have concurrent support from both VMs.
> >
> > -Nathan
> >
> > On 11/7/06, Nikolay Kuznetsov <ni...@gmail.com> wrote:
> > > please see the following JIRA issue for the missing function:
> > > http://issues.apache.org/jira/browse/HARMONY-2086
> > >
> > > Nik.
> > >
> > > On 11/7/06, Nikolay Kuznetsov <ni...@gmail.com> wrote:
> > > > While I'm not familiar with j.u.concurrent build infrastructure, but
> > > > the issue about missing native function is known and I'll file a jira
> > > > and provide a fix today.
> > > >
> > > > Nik.
> > > >
> > > > > 1) Natives are missing. In particular,
> > > > > java.util.concurrent.atomic.AtomicLong.VMSupportsCS8 looks like should be
> > > > > implemented on VM side.
> > > > > 2) ant test -Dbuild.module=concurrent does not work. The output is as
> > > > > follows:
> > > > >
> > > > > support-jar:
> > > > > [jar] Building jar:
> > > > > C:\_work_\harmony\enhanced\classlib\trunk\deploy\build
> > > > > \test\support.jar
> > > > >
> > > > > test-modules:
> > > > >
> > > > > test:
> > > > >
> > > > > full-report:
> > > > >
> > > > > BUILD FAILED
> > > > > C:\_work_\harmony\enhanced\classlib\trunk\build.xml:167: The following error
> > > > > occ
> > > > > urred while executing this line:
> > > > > C:\_work_\harmony\enhanced\classlib\trunk\make\build-test.xml:58:
> > > > > C:\_work_\harm
> > > > > ony\enhanced\classlib\trunk\build\test_report not found.
> > > > >
> > > > > Do I miss something important?
> > > > >
> > > > > --
> > > > > Pavel Pervov,
> > > > > Intel Enterprise Solutions Software Division
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: [classlib][concurrent] Complete support?
Posted by Nikolay Kuznetsov <ni...@gmail.com>.
Guys,
to get a consensus on the interfaces is very good, but this issue is
not about interfaces. j.u.concurrent.atomic.AtomicLong in its original
implementation has private native method: boolean VMSupportsCS8(),
thus to work with original concurrent classes any VM should export
following function:
JNIEXPORT jboolean JNICALL
Java_java_util_concurrent_atomic_AtomicLong_VMSupportsCS8(JNIEnv *,
jclass);
So the question here is what is the best place to put this function
declaration in. For now the most logical place in DRLVM for me is:
vmcore/src/kernel_classes/native/org_apache_harmony_util_concurrent_Atomics.h
But as soon as the rest of those functions may soon be replaced with
accessors, probably it makes sense to choose different place.
Any thought on what is best place to put this function to?
Nik.
On 11/8/06, Nathan Beyer <nb...@gmail.com> wrote:
> Instead of continuing to add functionality to the DRLVM-specific
> Atomics class, I'd like to get a consensus on the Threads/Objects
> (include CAS operations) interfaces in luni-kernel. Then we can get
> DRLVM to implement these classes and the donated IBM VM to do the same
> so we can have concurrent support from both VMs.
>
> -Nathan
>
> On 11/7/06, Nikolay Kuznetsov <ni...@gmail.com> wrote:
> > please see the following JIRA issue for the missing function:
> > http://issues.apache.org/jira/browse/HARMONY-2086
> >
> > Nik.
> >
> > On 11/7/06, Nikolay Kuznetsov <ni...@gmail.com> wrote:
> > > While I'm not familiar with j.u.concurrent build infrastructure, but
> > > the issue about missing native function is known and I'll file a jira
> > > and provide a fix today.
> > >
> > > Nik.
> > >
> > > > 1) Natives are missing. In particular,
> > > > java.util.concurrent.atomic.AtomicLong.VMSupportsCS8 looks like should be
> > > > implemented on VM side.
> > > > 2) ant test -Dbuild.module=concurrent does not work. The output is as
> > > > follows:
> > > >
> > > > support-jar:
> > > > [jar] Building jar:
> > > > C:\_work_\harmony\enhanced\classlib\trunk\deploy\build
> > > > \test\support.jar
> > > >
> > > > test-modules:
> > > >
> > > > test:
> > > >
> > > > full-report:
> > > >
> > > > BUILD FAILED
> > > > C:\_work_\harmony\enhanced\classlib\trunk\build.xml:167: The following error
> > > > occ
> > > > urred while executing this line:
> > > > C:\_work_\harmony\enhanced\classlib\trunk\make\build-test.xml:58:
> > > > C:\_work_\harm
> > > > ony\enhanced\classlib\trunk\build\test_report not found.
> > > >
> > > > Do I miss something important?
> > > >
> > > > --
> > > > Pavel Pervov,
> > > > Intel Enterprise Solutions Software Division
> > > >
> > > >
> > >
> >
>
Re: [classlib][concurrent] Complete support?
Posted by Alexey Petrenko <al...@gmail.com>.
2006/11/8, Nathan Beyer <nb...@gmail.com>:
> Instead of continuing to add functionality to the DRLVM-specific
> Atomics class, I'd like to get a consensus on the Threads/Objects
> (include CAS operations) interfaces in luni-kernel. Then we can get
> DRLVM to implement these classes and the donated IBM VM to do the same
> so we can have concurrent support from both VMs.
That would be great.
SY, Alexey
> On 11/7/06, Nikolay Kuznetsov <ni...@gmail.com> wrote:
> > please see the following JIRA issue for the missing function:
> > http://issues.apache.org/jira/browse/HARMONY-2086
> >
> > Nik.
> >
> > On 11/7/06, Nikolay Kuznetsov <ni...@gmail.com> wrote:
> > > While I'm not familiar with j.u.concurrent build infrastructure, but
> > > the issue about missing native function is known and I'll file a jira
> > > and provide a fix today.
> > >
> > > Nik.
> > >
> > > > 1) Natives are missing. In particular,
> > > > java.util.concurrent.atomic.AtomicLong.VMSupportsCS8 looks like should be
> > > > implemented on VM side.
> > > > 2) ant test -Dbuild.module=concurrent does not work. The output is as
> > > > follows:
> > > >
> > > > support-jar:
> > > > [jar] Building jar:
> > > > C:\_work_\harmony\enhanced\classlib\trunk\deploy\build
> > > > \test\support.jar
> > > >
> > > > test-modules:
> > > >
> > > > test:
> > > >
> > > > full-report:
> > > >
> > > > BUILD FAILED
> > > > C:\_work_\harmony\enhanced\classlib\trunk\build.xml:167: The following error
> > > > occ
> > > > urred while executing this line:
> > > > C:\_work_\harmony\enhanced\classlib\trunk\make\build-test.xml:58:
> > > > C:\_work_\harm
> > > > ony\enhanced\classlib\trunk\build\test_report not found.
> > > >
> > > > Do I miss something important?
> > > >
> > > > --
> > > > Pavel Pervov,
> > > > Intel Enterprise Solutions Software Division
> > > >
> > > >
> > >
> >
>
Re: [classlib][concurrent] Complete support?
Posted by Nathan Beyer <nb...@gmail.com>.
Instead of continuing to add functionality to the DRLVM-specific
Atomics class, I'd like to get a consensus on the Threads/Objects
(include CAS operations) interfaces in luni-kernel. Then we can get
DRLVM to implement these classes and the donated IBM VM to do the same
so we can have concurrent support from both VMs.
-Nathan
On 11/7/06, Nikolay Kuznetsov <ni...@gmail.com> wrote:
> please see the following JIRA issue for the missing function:
> http://issues.apache.org/jira/browse/HARMONY-2086
>
> Nik.
>
> On 11/7/06, Nikolay Kuznetsov <ni...@gmail.com> wrote:
> > While I'm not familiar with j.u.concurrent build infrastructure, but
> > the issue about missing native function is known and I'll file a jira
> > and provide a fix today.
> >
> > Nik.
> >
> > > 1) Natives are missing. In particular,
> > > java.util.concurrent.atomic.AtomicLong.VMSupportsCS8 looks like should be
> > > implemented on VM side.
> > > 2) ant test -Dbuild.module=concurrent does not work. The output is as
> > > follows:
> > >
> > > support-jar:
> > > [jar] Building jar:
> > > C:\_work_\harmony\enhanced\classlib\trunk\deploy\build
> > > \test\support.jar
> > >
> > > test-modules:
> > >
> > > test:
> > >
> > > full-report:
> > >
> > > BUILD FAILED
> > > C:\_work_\harmony\enhanced\classlib\trunk\build.xml:167: The following error
> > > occ
> > > urred while executing this line:
> > > C:\_work_\harmony\enhanced\classlib\trunk\make\build-test.xml:58:
> > > C:\_work_\harm
> > > ony\enhanced\classlib\trunk\build\test_report not found.
> > >
> > > Do I miss something important?
> > >
> > > --
> > > Pavel Pervov,
> > > Intel Enterprise Solutions Software Division
> > >
> > >
> >
>
Re: [classlib][concurrent] Complete support?
Posted by Nikolay Kuznetsov <ni...@gmail.com>.
please see the following JIRA issue for the missing function:
http://issues.apache.org/jira/browse/HARMONY-2086
Nik.
On 11/7/06, Nikolay Kuznetsov <ni...@gmail.com> wrote:
> While I'm not familiar with j.u.concurrent build infrastructure, but
> the issue about missing native function is known and I'll file a jira
> and provide a fix today.
>
> Nik.
>
> > 1) Natives are missing. In particular,
> > java.util.concurrent.atomic.AtomicLong.VMSupportsCS8 looks like should be
> > implemented on VM side.
> > 2) ant test -Dbuild.module=concurrent does not work. The output is as
> > follows:
> >
> > support-jar:
> > [jar] Building jar:
> > C:\_work_\harmony\enhanced\classlib\trunk\deploy\build
> > \test\support.jar
> >
> > test-modules:
> >
> > test:
> >
> > full-report:
> >
> > BUILD FAILED
> > C:\_work_\harmony\enhanced\classlib\trunk\build.xml:167: The following error
> > occ
> > urred while executing this line:
> > C:\_work_\harmony\enhanced\classlib\trunk\make\build-test.xml:58:
> > C:\_work_\harm
> > ony\enhanced\classlib\trunk\build\test_report not found.
> >
> > Do I miss something important?
> >
> > --
> > Pavel Pervov,
> > Intel Enterprise Solutions Software Division
> >
> >
>
Re: [classlib][concurrent] Complete support?
Posted by Nikolay Kuznetsov <ni...@gmail.com>.
While I'm not familiar with j.u.concurrent build infrastructure, but
the issue about missing native function is known and I'll file a jira
and provide a fix today.
Nik.
> 1) Natives are missing. In particular,
> java.util.concurrent.atomic.AtomicLong.VMSupportsCS8 looks like should be
> implemented on VM side.
> 2) ant test -Dbuild.module=concurrent does not work. The output is as
> follows:
>
> support-jar:
> [jar] Building jar:
> C:\_work_\harmony\enhanced\classlib\trunk\deploy\build
> \test\support.jar
>
> test-modules:
>
> test:
>
> full-report:
>
> BUILD FAILED
> C:\_work_\harmony\enhanced\classlib\trunk\build.xml:167: The following error
> occ
> urred while executing this line:
> C:\_work_\harmony\enhanced\classlib\trunk\make\build-test.xml:58:
> C:\_work_\harm
> ony\enhanced\classlib\trunk\build\test_report not found.
>
> Do I miss something important?
>
> --
> Pavel Pervov,
> Intel Enterprise Solutions Software Division
>
>