Re: [classlib][concurrent] Complete support?
On 11/9/06, Nathan Beyer [EMAIL PROTECTED] wrote: On 11/8/06, Andrey Chernyshev [EMAIL PROTECTED] wrote: On 11/8/06, Tim Ellison [EMAIL PROTECTED] 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 ([EMAIL PROTECTED]) IBM Java technology centre, UK. -- Andrey Chernyshev Intel Enterprise Solutions Software Division -- Andrey Chernyshev Intel Middleware Products Division
Re: [classlib][concurrent] Complete support?
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 ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: [classlib][concurrent] Complete support?
On 11/8/06, Tim Ellison [EMAIL PROTECTED] 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 ([EMAIL PROTECTED]) IBM Java technology centre, UK. -- Andrey Chernyshev Intel Enterprise Solutions Software Division
Re: [classlib][concurrent] Complete support?
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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?
On 11/8/06, Nikolay Kuznetsov [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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?
On 11/8/06, Andrey Chernyshev [EMAIL PROTECTED] wrote: On 11/8/06, Tim Ellison [EMAIL PROTECTED] 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 ([EMAIL PROTECTED]) IBM Java technology centre, UK. -- Andrey Chernyshev Intel Enterprise Solutions Software Division
Re: [classlib][concurrent] Complete support?
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?
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 [EMAIL PROTECTED] 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?
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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?
2006/11/8, Nathan Beyer [EMAIL PROTECTED]: 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
