You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Nathan Beyer <nb...@kc.rr.com> on 2006/06/10 22:53:10 UTC
[classlib][vm] Prerequisites for java.util.concurrent
I've been working with the java.util.concurrent code to see what we'd need
to have in place to get this code to be a part of Harmony.
System.nanoTime() - A number of the classes rely on the new nanoTime method.
I'm assuming this would just be marked as a native method like
currentTimeMillis in luni-kernel, which would leave it up to the VMs
implement. I can easily stub out the Java code. Anyone interested in getting
our VMs to implement this method? I'm guessing that if IBM donates an
updated VME for 1.5 usage, this would also be provided.maybe?
Annotations - There are a few places where the @SuppressWarnings annotation
is used. Building the annotations themselves is trivial, but we'll actually
need to be using Java 5 class files to properly compile annotation class
files. These can be commented out until the 5 class file support is enabled.
PriorityQueue - There's at least one dependency on this class. I think
someone is already working on this one though.
VMI Atomicity/Lock API - All of the AtomicXXX classes are delegated to a
VM-specific API for atomic gets and sets. This API will need to be defined
and then implemented by the various VMs. Many of the lock APIs also make use
of this API.
Arrays.copyOf() - Several classes utilize a set of Arrays.copyOf() methods,
which are new in Java SE 6 [1]. We'd either have to rework these
implementations to use System.arraycopy or just implement the new methods.
AbstractMap.SimpleEntry<K,V> - The ConcurrentHashMap uses this class as a
base class for Map.Entry objects. This is a new public class, which is also
part of Java SE 6 [2]. Either this code can be reworked to just implement
the Map.Entry interface, or the SimpleEntry class can be built out, which
should be trivial.
Thoughts, comments, questions?
[1] http://java.sun.com/javase/6/docs/api/java/util/Arrays.html
[2]
http://java.sun.com/javase/6/docs/api/java/util/AbstractMap.SimpleEntry.html
RE: [classlib][vm] Prerequisites for java.util.concurrent
Posted by Nathan Beyer <nb...@kc.rr.com>.
Is it the JSR166_PFD tag, do you know? It looks like there have been a
number of maintenance fixes between that tag (seemingly that last tag) and
Java 6 additions/HEAD.
> -----Original Message-----
> From: Geir Magnusson Jr [mailto:geir@pobox.com]
> Sent: Sunday, June 11, 2006 5:32 PM
> To: harmony-dev@incubator.apache.org
> Subject: Re: [classlib][vm] Prerequisites for java.util.concurrent
>
>
>
> Tim Ellison wrote:
>
> >
> > Strange that there are 6.0 dependencies. Is there a j.u.concurrent
> > maintenance stream we can track rather than the dev stream?
> >
>
> Yes. There's a tag.
>
> geir
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][vm] Prerequisites for java.util.concurrent
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Tim Ellison wrote:
>
> Strange that there are 6.0 dependencies. Is there a j.u.concurrent
> maintenance stream we can track rather than the dev stream?
>
Yes. There's a tag.
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][vm] Prerequisites for java.util.concurrent
Posted by Paulex Yang <pa...@gmail.com>.
Ah, I'm sorry, I think it's me misunderstand you.
Nathan Beyer wrote:
> Sorry if I was confusing, the PriorityQueue is just a dependency of the
> j.u.c. There are a few classes that us it internally, including the
> PriorityBlockingQueue.
>
>
>> -----Original Message-----
>> From: Paulex Yang [mailto:paulex.yang@gmail.com]
>> Sent: Monday, June 12, 2006 2:18 AM
>> To: harmony-dev@incubator.apache.org
>> Subject: Re: [classlib][vm] Prerequisites for java.util.concurrent
>>
>> Nathan,
>>
>> I'm working on the j.u.PriorityQueue (harmony-574), but I didn't find
>> anything related to atomic or lock on this class? The spec on this class
>> said:
>>
>> *"Note that this implementation is not synchronized.* Multiple threads
>> should not access a PriorityQueue instance concurrently if any of the
>> threads modifies the list structurally. Instead, use the thread-safe
>> |PriorityBlockingQueue| <ci...@gmail.com> class."
>>
>> So I guess you meant j.u.c.PriorityBlockingQueue here? which indeed
>> requires some operations to be atomic, such as clear(), etc. Please
>> correct me if I missed something here.
>>
>> Paulex.
>>
>> Nathan Beyer wrote:
>>
>>>> -----Original Message-----
>>>> From: Tim Ellison [mailto:t.p.ellison@gmail.com]
>>>>
>>>> Nathan Beyer wrote:
>>>>
>>>>
>>>>> I've been working with the java.util.concurrent code to see what we'd
>>>>>
>>>>>
>>>> need
>>>>
>>>>
>>>>> to have in place to get this code to be a part of Harmony.
>>>>>
>>>>>
>>>>>
>>>>> System.nanoTime() - A number of the classes rely on the new nanoTime
>>>>>
>>>>>
>>>> method.
>>>>
>>>>
>>>>> I'm assuming this would just be marked as a native method like
>>>>> currentTimeMillis in luni-kernel, which would leave it up to the VMs
>>>>> implement. I can easily stub out the Java code. Anyone interested in
>>>>>
>>>>>
>>>> getting
>>>>
>>>>
>>>>> our VMs to implement this method? I'm guessing that if IBM donates an
>>>>> updated VME for 1.5 usage, this would also be provided.maybe?
>>>>>
>>>>>
>>>> It's in the Harmony port library as:
>>>> U_64 VMCALL hytime_hires_clock (struct HyPortLibrary *portLibrary)
>>>>
>>>> [1]
>>>>
>>>>
>> http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/doc
>>
>>>> /vm_doc/html/hytime_8c.html?view=co
>>>>
>>>>
>>>>
>>>>
>>>>> Annotations - There are a few places where the @SuppressWarnings
>>>>>
>>>>>
>>>> annotation
>>>>
>>>>
>>>>> is used. Building the annotations themselves is trivial, but we'll
>>>>>
>>>>>
>>>> actually
>>>>
>>>>
>>>>> need to be using Java 5 class files to properly compile annotation
>>>>>
>> class
>>
>>>>> files. These can be commented out until the 5 class file support is
>>>>>
>>>>>
>>>> enabled.
>>>>
>>>> Sounds like all Harmony-oriented VMs are happy for us to move to the
>>>>
>> 1.5
>>
>>>> compiler, even if getting the runtime annotation info may not be there
>>>> yet.
>>>>
>>>>
>>> Cool. I think the sooner we move forward, the better...at least more
>>>
>> fun.
>>
>>> Anyway, I think we're probably stretching the capabilities of the 1.5
>>>
>> source
>>
>>> to 1.4 bytecodes functionality as far as it can go.
>>>
>>>
>>>
>>>>> PriorityQueue - There's at least one dependency on this class. I think
>>>>> someone is already working on this one though.
>>>>>
>>>>>
>>>>>
>>>>> VMI Atomicity/Lock API - All of the AtomicXXX classes are delegated to
>>>>>
>> a
>>
>>>>> VM-specific API for atomic gets and sets. This API will need to be
>>>>>
>>>>>
>>>> defined
>>>>
>>>>
>>>>> and then implemented by the various VMs. Many of the lock APIs also
>>>>>
>> make
>>
>>>> use
>>>>
>>>>
>>>>> of this API.
>>>>>
>>>>>
>>>> Do these have to be VM-specific?
>>>>
>>>>
>>> To be honest, I'm not sure. It may be possible to write this code in a
>>> VM-agnostic way, but someone who's a bit more familiar with the
>>>
>> underlying
>>
>>> concepts and the native code should a peek at it. (Any VM folks have a
>>> thought?) The only reason I'm guessing it's VM-specific at the moment is
>>> just a hunch, since the atomic guarantees and lock support ties into the
>>> memory models guarantees, which is maintained by the VM, it seemed
>>>
>> apropos.
>>
>>>
>>>>> Arrays.copyOf() - Several classes utilize a set of Arrays.copyOf()
>>>>>
>>>>>
>>>> methods,
>>>>
>>>>
>>>>> which are new in Java SE 6 [1]. We'd either have to rework these
>>>>> implementations to use System.arraycopy or just implement the new
>>>>>
>>>>>
>>>> methods.
>>>>
>>>>
>>>>> AbstractMap.SimpleEntry<K,V> - The ConcurrentHashMap uses this class
>>>>>
>> as
>>
>>>> a
>>>>
>>>>
>>>>> base class for Map.Entry objects. This is a new public class, which is
>>>>>
>>>>>
>>>> also
>>>>
>>>>
>>>>> part of Java SE 6 [2]. Either this code can be reworked to just
>>>>>
>>>>>
>>>> implement
>>>>
>>>>
>>>>> the Map.Entry interface, or the SimpleEntry class can be built out,
>>>>>
>>>>>
>>>> which
>>>>
>>>>
>>>>> should be trivial.
>>>>>
>>>>>
>>>> Strange that there are 6.0 dependencies. Is there a j.u.concurrent
>>>> maintenance stream we can track rather than the dev stream?
>>>>
>>>> Regards,
>>>> Tim
>>>>
>>>>
>>>>
>>>>
>>>>> Thoughts, comments, questions?
>>>>>
>>>>>
>>>>>
>>>>> [1] http://java.sun.com/javase/6/docs/api/java/util/Arrays.html
>>>>>
>>>>> [2]
>>>>>
>>>>>
>>>>>
>> http://java.sun.com/javase/6/docs/api/java/util/AbstractMap.SimpleEntry.ht
>>
>>>> ml
>>>>
>>>>
>>>> --
>>>>
>>>> Tim Ellison (t.p.ellison@gmail.com)
>>>> IBM Java technology centre, UK.
>>>>
>>>> ---------------------------------------------------------------------
>>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>>
>>>
>>>
>>>
>> --
>> Paulex Yang
>> China Software Development Lab
>> IBM
>>
>>
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
>
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][vm] Prerequisites for java.util.concurrent
Posted by Paulex Yang <pa...@gmail.com>.
Nathan,
I've attached an implementation of PriorityQueue at Harmony-574. Would
you please to look if it is OK for concurrency to use? Thank you.
Nathan Beyer wrote:
> Sorry if I was confusing, the PriorityQueue is just a dependency of the
> j.u.c. There are a few classes that us it internally, including the
> PriorityBlockingQueue.
>
>
>> -----Original Message-----
>> From: Paulex Yang [mailto:paulex.yang@gmail.com]
>> Sent: Monday, June 12, 2006 2:18 AM
>> To: harmony-dev@incubator.apache.org
>> Subject: Re: [classlib][vm] Prerequisites for java.util.concurrent
>>
>> Nathan,
>>
>> I'm working on the j.u.PriorityQueue (harmony-574), but I didn't find
>> anything related to atomic or lock on this class? The spec on this class
>> said:
>>
>> *"Note that this implementation is not synchronized.* Multiple threads
>> should not access a PriorityQueue instance concurrently if any of the
>> threads modifies the list structurally. Instead, use the thread-safe
>> |PriorityBlockingQueue| <ci...@gmail.com> class."
>>
>> So I guess you meant j.u.c.PriorityBlockingQueue here? which indeed
>> requires some operations to be atomic, such as clear(), etc. Please
>> correct me if I missed something here.
>>
>> Paulex.
>>
>> Nathan Beyer wrote:
>>
>>>> -----Original Message-----
>>>> From: Tim Ellison [mailto:t.p.ellison@gmail.com]
>>>>
>>>> Nathan Beyer wrote:
>>>>
>>>>
>>>>> I've been working with the java.util.concurrent code to see what we'd
>>>>>
>>>>>
>>>> need
>>>>
>>>>
>>>>> to have in place to get this code to be a part of Harmony.
>>>>>
>>>>>
>>>>>
>>>>> System.nanoTime() - A number of the classes rely on the new nanoTime
>>>>>
>>>>>
>>>> method.
>>>>
>>>>
>>>>> I'm assuming this would just be marked as a native method like
>>>>> currentTimeMillis in luni-kernel, which would leave it up to the VMs
>>>>> implement. I can easily stub out the Java code. Anyone interested in
>>>>>
>>>>>
>>>> getting
>>>>
>>>>
>>>>> our VMs to implement this method? I'm guessing that if IBM donates an
>>>>> updated VME for 1.5 usage, this would also be provided.maybe?
>>>>>
>>>>>
>>>> It's in the Harmony port library as:
>>>> U_64 VMCALL hytime_hires_clock (struct HyPortLibrary *portLibrary)
>>>>
>>>> [1]
>>>>
>>>>
>> http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/doc
>>
>>>> /vm_doc/html/hytime_8c.html?view=co
>>>>
>>>>
>>>>
>>>>
>>>>> Annotations - There are a few places where the @SuppressWarnings
>>>>>
>>>>>
>>>> annotation
>>>>
>>>>
>>>>> is used. Building the annotations themselves is trivial, but we'll
>>>>>
>>>>>
>>>> actually
>>>>
>>>>
>>>>> need to be using Java 5 class files to properly compile annotation
>>>>>
>> class
>>
>>>>> files. These can be commented out until the 5 class file support is
>>>>>
>>>>>
>>>> enabled.
>>>>
>>>> Sounds like all Harmony-oriented VMs are happy for us to move to the
>>>>
>> 1.5
>>
>>>> compiler, even if getting the runtime annotation info may not be there
>>>> yet.
>>>>
>>>>
>>> Cool. I think the sooner we move forward, the better...at least more
>>>
>> fun.
>>
>>> Anyway, I think we're probably stretching the capabilities of the 1.5
>>>
>> source
>>
>>> to 1.4 bytecodes functionality as far as it can go.
>>>
>>>
>>>
>>>>> PriorityQueue - There's at least one dependency on this class. I think
>>>>> someone is already working on this one though.
>>>>>
>>>>>
>>>>>
>>>>> VMI Atomicity/Lock API - All of the AtomicXXX classes are delegated to
>>>>>
>> a
>>
>>>>> VM-specific API for atomic gets and sets. This API will need to be
>>>>>
>>>>>
>>>> defined
>>>>
>>>>
>>>>> and then implemented by the various VMs. Many of the lock APIs also
>>>>>
>> make
>>
>>>> use
>>>>
>>>>
>>>>> of this API.
>>>>>
>>>>>
>>>> Do these have to be VM-specific?
>>>>
>>>>
>>> To be honest, I'm not sure. It may be possible to write this code in a
>>> VM-agnostic way, but someone who's a bit more familiar with the
>>>
>> underlying
>>
>>> concepts and the native code should a peek at it. (Any VM folks have a
>>> thought?) The only reason I'm guessing it's VM-specific at the moment is
>>> just a hunch, since the atomic guarantees and lock support ties into the
>>> memory models guarantees, which is maintained by the VM, it seemed
>>>
>> apropos.
>>
>>>
>>>>> Arrays.copyOf() - Several classes utilize a set of Arrays.copyOf()
>>>>>
>>>>>
>>>> methods,
>>>>
>>>>
>>>>> which are new in Java SE 6 [1]. We'd either have to rework these
>>>>> implementations to use System.arraycopy or just implement the new
>>>>>
>>>>>
>>>> methods.
>>>>
>>>>
>>>>> AbstractMap.SimpleEntry<K,V> - The ConcurrentHashMap uses this class
>>>>>
>> as
>>
>>>> a
>>>>
>>>>
>>>>> base class for Map.Entry objects. This is a new public class, which is
>>>>>
>>>>>
>>>> also
>>>>
>>>>
>>>>> part of Java SE 6 [2]. Either this code can be reworked to just
>>>>>
>>>>>
>>>> implement
>>>>
>>>>
>>>>> the Map.Entry interface, or the SimpleEntry class can be built out,
>>>>>
>>>>>
>>>> which
>>>>
>>>>
>>>>> should be trivial.
>>>>>
>>>>>
>>>> Strange that there are 6.0 dependencies. Is there a j.u.concurrent
>>>> maintenance stream we can track rather than the dev stream?
>>>>
>>>> Regards,
>>>> Tim
>>>>
>>>>
>>>>
>>>>
>>>>> Thoughts, comments, questions?
>>>>>
>>>>>
>>>>>
>>>>> [1] http://java.sun.com/javase/6/docs/api/java/util/Arrays.html
>>>>>
>>>>> [2]
>>>>>
>>>>>
>>>>>
>> http://java.sun.com/javase/6/docs/api/java/util/AbstractMap.SimpleEntry.ht
>>
>>>> ml
>>>>
>>>>
>>>> --
>>>>
>>>> Tim Ellison (t.p.ellison@gmail.com)
>>>> IBM Java technology centre, UK.
>>>>
>>>> ---------------------------------------------------------------------
>>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>>
>>>
>>>
>>>
>> --
>> Paulex Yang
>> China Software Development Lab
>> IBM
>>
>>
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
>
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
RE: [classlib][vm] Prerequisites for java.util.concurrent
Posted by Nathan Beyer <nb...@kc.rr.com>.
Sorry if I was confusing, the PriorityQueue is just a dependency of the
j.u.c. There are a few classes that us it internally, including the
PriorityBlockingQueue.
> -----Original Message-----
> From: Paulex Yang [mailto:paulex.yang@gmail.com]
> Sent: Monday, June 12, 2006 2:18 AM
> To: harmony-dev@incubator.apache.org
> Subject: Re: [classlib][vm] Prerequisites for java.util.concurrent
>
> Nathan,
>
> I'm working on the j.u.PriorityQueue (harmony-574), but I didn't find
> anything related to atomic or lock on this class? The spec on this class
> said:
>
> *"Note that this implementation is not synchronized.* Multiple threads
> should not access a PriorityQueue instance concurrently if any of the
> threads modifies the list structurally. Instead, use the thread-safe
> |PriorityBlockingQueue| <ci...@gmail.com> class."
>
> So I guess you meant j.u.c.PriorityBlockingQueue here? which indeed
> requires some operations to be atomic, such as clear(), etc. Please
> correct me if I missed something here.
>
> Paulex.
>
> Nathan Beyer wrote:
> >
> >> -----Original Message-----
> >> From: Tim Ellison [mailto:t.p.ellison@gmail.com]
> >>
> >> Nathan Beyer wrote:
> >>
> >>> I've been working with the java.util.concurrent code to see what we'd
> >>>
> >> need
> >>
> >>> to have in place to get this code to be a part of Harmony.
> >>>
> >>>
> >>>
> >>> System.nanoTime() - A number of the classes rely on the new nanoTime
> >>>
> >> method.
> >>
> >>> I'm assuming this would just be marked as a native method like
> >>> currentTimeMillis in luni-kernel, which would leave it up to the VMs
> >>> implement. I can easily stub out the Java code. Anyone interested in
> >>>
> >> getting
> >>
> >>> our VMs to implement this method? I'm guessing that if IBM donates an
> >>> updated VME for 1.5 usage, this would also be provided.maybe?
> >>>
> >> It's in the Harmony port library as:
> >> U_64 VMCALL hytime_hires_clock (struct HyPortLibrary *portLibrary)
> >>
> >> [1]
> >>
> http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/doc
> >> /vm_doc/html/hytime_8c.html?view=co
> >>
> >>
> >>
> >>> Annotations - There are a few places where the @SuppressWarnings
> >>>
> >> annotation
> >>
> >>> is used. Building the annotations themselves is trivial, but we'll
> >>>
> >> actually
> >>
> >>> need to be using Java 5 class files to properly compile annotation
> class
> >>> files. These can be commented out until the 5 class file support is
> >>>
> >> enabled.
> >>
> >> Sounds like all Harmony-oriented VMs are happy for us to move to the
> 1.5
> >> compiler, even if getting the runtime annotation info may not be there
> >> yet.
> >>
> >
> > Cool. I think the sooner we move forward, the better...at least more
> fun.
> > Anyway, I think we're probably stretching the capabilities of the 1.5
> source
> > to 1.4 bytecodes functionality as far as it can go.
> >
> >
> >>> PriorityQueue - There's at least one dependency on this class. I think
> >>> someone is already working on this one though.
> >>>
> >>>
> >>>
> >>> VMI Atomicity/Lock API - All of the AtomicXXX classes are delegated to
> a
> >>> VM-specific API for atomic gets and sets. This API will need to be
> >>>
> >> defined
> >>
> >>> and then implemented by the various VMs. Many of the lock APIs also
> make
> >>>
> >> use
> >>
> >>> of this API.
> >>>
> >> Do these have to be VM-specific?
> >>
> >
> > To be honest, I'm not sure. It may be possible to write this code in a
> > VM-agnostic way, but someone who's a bit more familiar with the
> underlying
> > concepts and the native code should a peek at it. (Any VM folks have a
> > thought?) The only reason I'm guessing it's VM-specific at the moment is
> > just a hunch, since the atomic guarantees and lock support ties into the
> > memory models guarantees, which is maintained by the VM, it seemed
> apropos.
> >
> >
> >>> Arrays.copyOf() - Several classes utilize a set of Arrays.copyOf()
> >>>
> >> methods,
> >>
> >>> which are new in Java SE 6 [1]. We'd either have to rework these
> >>> implementations to use System.arraycopy or just implement the new
> >>>
> >> methods.
> >>
> >>>
> >>> AbstractMap.SimpleEntry<K,V> - The ConcurrentHashMap uses this class
> as
> >>>
> >> a
> >>
> >>> base class for Map.Entry objects. This is a new public class, which is
> >>>
> >> also
> >>
> >>> part of Java SE 6 [2]. Either this code can be reworked to just
> >>>
> >> implement
> >>
> >>> the Map.Entry interface, or the SimpleEntry class can be built out,
> >>>
> >> which
> >>
> >>> should be trivial.
> >>>
> >> Strange that there are 6.0 dependencies. Is there a j.u.concurrent
> >> maintenance stream we can track rather than the dev stream?
> >>
> >> Regards,
> >> Tim
> >>
> >>
> >>
> >>> Thoughts, comments, questions?
> >>>
> >>>
> >>>
> >>> [1] http://java.sun.com/javase/6/docs/api/java/util/Arrays.html
> >>>
> >>> [2]
> >>>
> >>>
> >>
> http://java.sun.com/javase/6/docs/api/java/util/AbstractMap.SimpleEntry.ht
> >> ml
> >>
> >>>
> >> --
> >>
> >> Tim Ellison (t.p.ellison@gmail.com)
> >> IBM Java technology centre, UK.
> >>
> >> ---------------------------------------------------------------------
> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
> >
>
>
> --
> Paulex Yang
> China Software Development Lab
> IBM
>
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][vm] Prerequisites for java.util.concurrent
Posted by Paulex Yang <pa...@gmail.com>.
Nathan,
I'm working on the j.u.PriorityQueue (harmony-574), but I didn't find
anything related to atomic or lock on this class? The spec on this class
said:
*"Note that this implementation is not synchronized.* Multiple threads
should not access a PriorityQueue instance concurrently if any of the
threads modifies the list structurally. Instead, use the thread-safe
|PriorityBlockingQueue| <ci...@gmail.com> class."
So I guess you meant j.u.c.PriorityBlockingQueue here? which indeed
requires some operations to be atomic, such as clear(), etc. Please
correct me if I missed something here.
Paulex.
Nathan Beyer wrote:
>
>> -----Original Message-----
>> From: Tim Ellison [mailto:t.p.ellison@gmail.com]
>>
>> Nathan Beyer wrote:
>>
>>> I've been working with the java.util.concurrent code to see what we'd
>>>
>> need
>>
>>> to have in place to get this code to be a part of Harmony.
>>>
>>>
>>>
>>> System.nanoTime() - A number of the classes rely on the new nanoTime
>>>
>> method.
>>
>>> I'm assuming this would just be marked as a native method like
>>> currentTimeMillis in luni-kernel, which would leave it up to the VMs
>>> implement. I can easily stub out the Java code. Anyone interested in
>>>
>> getting
>>
>>> our VMs to implement this method? I'm guessing that if IBM donates an
>>> updated VME for 1.5 usage, this would also be provided.maybe?
>>>
>> It's in the Harmony port library as:
>> U_64 VMCALL hytime_hires_clock (struct HyPortLibrary *portLibrary)
>>
>> [1]
>> http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/doc
>> /vm_doc/html/hytime_8c.html?view=co
>>
>>
>>
>>> Annotations - There are a few places where the @SuppressWarnings
>>>
>> annotation
>>
>>> is used. Building the annotations themselves is trivial, but we'll
>>>
>> actually
>>
>>> need to be using Java 5 class files to properly compile annotation class
>>> files. These can be commented out until the 5 class file support is
>>>
>> enabled.
>>
>> Sounds like all Harmony-oriented VMs are happy for us to move to the 1.5
>> compiler, even if getting the runtime annotation info may not be there
>> yet.
>>
>
> Cool. I think the sooner we move forward, the better...at least more fun.
> Anyway, I think we're probably stretching the capabilities of the 1.5 source
> to 1.4 bytecodes functionality as far as it can go.
>
>
>>> PriorityQueue - There's at least one dependency on this class. I think
>>> someone is already working on this one though.
>>>
>>>
>>>
>>> VMI Atomicity/Lock API - All of the AtomicXXX classes are delegated to a
>>> VM-specific API for atomic gets and sets. This API will need to be
>>>
>> defined
>>
>>> and then implemented by the various VMs. Many of the lock APIs also make
>>>
>> use
>>
>>> of this API.
>>>
>> Do these have to be VM-specific?
>>
>
> To be honest, I'm not sure. It may be possible to write this code in a
> VM-agnostic way, but someone who's a bit more familiar with the underlying
> concepts and the native code should a peek at it. (Any VM folks have a
> thought?) The only reason I'm guessing it's VM-specific at the moment is
> just a hunch, since the atomic guarantees and lock support ties into the
> memory models guarantees, which is maintained by the VM, it seemed apropos.
>
>
>>> Arrays.copyOf() - Several classes utilize a set of Arrays.copyOf()
>>>
>> methods,
>>
>>> which are new in Java SE 6 [1]. We'd either have to rework these
>>> implementations to use System.arraycopy or just implement the new
>>>
>> methods.
>>
>>>
>>> AbstractMap.SimpleEntry<K,V> - The ConcurrentHashMap uses this class as
>>>
>> a
>>
>>> base class for Map.Entry objects. This is a new public class, which is
>>>
>> also
>>
>>> part of Java SE 6 [2]. Either this code can be reworked to just
>>>
>> implement
>>
>>> the Map.Entry interface, or the SimpleEntry class can be built out,
>>>
>> which
>>
>>> should be trivial.
>>>
>> Strange that there are 6.0 dependencies. Is there a j.u.concurrent
>> maintenance stream we can track rather than the dev stream?
>>
>> Regards,
>> Tim
>>
>>
>>
>>> Thoughts, comments, questions?
>>>
>>>
>>>
>>> [1] http://java.sun.com/javase/6/docs/api/java/util/Arrays.html
>>>
>>> [2]
>>>
>>>
>> http://java.sun.com/javase/6/docs/api/java/util/AbstractMap.SimpleEntry.ht
>> ml
>>
>>>
>> --
>>
>> Tim Ellison (t.p.ellison@gmail.com)
>> IBM Java technology centre, UK.
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
>
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
RE: [classlib][vm] Prerequisites for java.util.concurrent
Posted by Nathan Beyer <nb...@kc.rr.com>.
> -----Original Message-----
> From: Tim Ellison [mailto:t.p.ellison@gmail.com]
>
> Nathan Beyer wrote:
> > I've been working with the java.util.concurrent code to see what we'd
> need
> > to have in place to get this code to be a part of Harmony.
> >
> >
> >
> > System.nanoTime() - A number of the classes rely on the new nanoTime
> method.
> > I'm assuming this would just be marked as a native method like
> > currentTimeMillis in luni-kernel, which would leave it up to the VMs
> > implement. I can easily stub out the Java code. Anyone interested in
> getting
> > our VMs to implement this method? I'm guessing that if IBM donates an
> > updated VME for 1.5 usage, this would also be provided.maybe?
>
> It's in the Harmony port library as:
> U_64 VMCALL hytime_hires_clock (struct HyPortLibrary *portLibrary)
>
> [1]
> http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/doc
> /vm_doc/html/hytime_8c.html?view=co
>
>
> > Annotations - There are a few places where the @SuppressWarnings
> annotation
> > is used. Building the annotations themselves is trivial, but we'll
> actually
> > need to be using Java 5 class files to properly compile annotation class
> > files. These can be commented out until the 5 class file support is
> enabled.
>
> Sounds like all Harmony-oriented VMs are happy for us to move to the 1.5
> compiler, even if getting the runtime annotation info may not be there
> yet.
Cool. I think the sooner we move forward, the better...at least more fun.
Anyway, I think we're probably stretching the capabilities of the 1.5 source
to 1.4 bytecodes functionality as far as it can go.
>
> > PriorityQueue - There's at least one dependency on this class. I think
> > someone is already working on this one though.
> >
> >
> >
> > VMI Atomicity/Lock API - All of the AtomicXXX classes are delegated to a
> > VM-specific API for atomic gets and sets. This API will need to be
> defined
> > and then implemented by the various VMs. Many of the lock APIs also make
> use
> > of this API.
>
> Do these have to be VM-specific?
To be honest, I'm not sure. It may be possible to write this code in a
VM-agnostic way, but someone who's a bit more familiar with the underlying
concepts and the native code should a peek at it. (Any VM folks have a
thought?) The only reason I'm guessing it's VM-specific at the moment is
just a hunch, since the atomic guarantees and lock support ties into the
memory models guarantees, which is maintained by the VM, it seemed apropos.
>
> > Arrays.copyOf() - Several classes utilize a set of Arrays.copyOf()
> methods,
> > which are new in Java SE 6 [1]. We'd either have to rework these
> > implementations to use System.arraycopy or just implement the new
> methods.
> >
> >
> >
> > AbstractMap.SimpleEntry<K,V> - The ConcurrentHashMap uses this class as
> a
> > base class for Map.Entry objects. This is a new public class, which is
> also
> > part of Java SE 6 [2]. Either this code can be reworked to just
> implement
> > the Map.Entry interface, or the SimpleEntry class can be built out,
> which
> > should be trivial.
>
> Strange that there are 6.0 dependencies. Is there a j.u.concurrent
> maintenance stream we can track rather than the dev stream?
>
> Regards,
> Tim
>
>
> > Thoughts, comments, questions?
> >
> >
> >
> > [1] http://java.sun.com/javase/6/docs/api/java/util/Arrays.html
> >
> > [2]
> >
> http://java.sun.com/javase/6/docs/api/java/util/AbstractMap.SimpleEntry.ht
> ml
> >
> >
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][vm] Prerequisites for java.util.concurrent
Posted by Andrey Chernyshev <a....@gmail.com>.
On 6/18/06, Nathan Beyer <nb...@kc.rr.com> wrote:
> Thanks. How does the Atomics class work in regards to volatile reads of
> elements of an array? Here's the class I'm looking at implementing with the
> Atomics API [1]. The CAS operations are trivial. It's the 'get' and 'set'
> methods that I'm trying to figure out.
Hi Nathan,
Atomics in drlvm has a function MemoryReadWriteBarrier() defined in
atomics.h (see http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/include/atomics.h)
which can be utilized for implementing volatile reads and writes for
AtomicIntegerArray. Some work, however, will still be needed for
atomics.cpp to add volatile set() and get() implementations accessible
through JNI interface.
Another approach to implement AtomicArray.get and set could be via CAS
operation. For example, for set() method, you simply can do something
like:
int orig = arr[i]; // guess original master value
compareAndSet(i, orig, newValue); // set new value; if the
original value is unexpected, it would just mean that someone else has
changed it concurrently which is OK for this case and we just do
nothing;
For get() method, algorithm could be like:
int orig = arr[i];
compareAndSet(i, 0, 0); // do CAS with whatever value, this
ensures cache is flushed;
return arr[i]; // return the master value
In terms of the speed, it must be almost same as doing mfense, at
least on IA32 (mfense is probably 20-30% faster).
Thank you,
Andrey Chernyshev
Intel Middleware Products Division
>
> -Nathan
>
> [1]
> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concu
> rrent/atomic/AtomicIntegerArray.java?rev=1.19&only_with_tag=JSR166_PFD&conte
> nt-type=text/vnd.viewcvs-markup
>
> > -----Original Message-----
> > From: Artem Aliev [mailto:artem.aliev@gmail.com]
> > Sent: Friday, June 16, 2006 6:52 AM
> > To: harmony-dev@incubator.apache.org
> > Subject: Re: [classlib][vm] Prerequisites for java.util.concurrent
> >
> > Nathan,
> >
> > > VMI Atomicity/Lock API - All of the AtomicXXX classes are delegated to a
> > > VM-specific API for atomic gets and sets. This API will need to be
> > defined
> > > and then implemented by the various VMs. Many of the lock APIs also make
> > use
> > > of this API.
> >
> > I have done some experiments with concurrent in DRLVM. So there are
> > two kernel classes in the DRLVM that, probably, provide full set of VM
> > dependent
> > functionality required by util.concurrent. Both have special VM support.
> >
> > vm/vmcore/src/kernel_classes/javasrc/java/util/concurrent/locks/LockSuppor
> > t.java
> > -- park/unpark methods
> >
> > The special queue could be used in case you need to implement it in VM
> > independent way.
> >
> > vm/vmcore/src/kernel_classes/javasrc/org/apache/harmony/util/concurrent/At
> > omics.java
> > -- CAS operations on references, ints, longs etc.
> >
> > The methods are aware of internal object layout and reference format.
> > VM independent implementation could be done base on java monitors, but
> > it kills the idea of the util.concurrent.
> >
> > Thanks
> > Artem Aliev
> > Intel Middleware Product Division
> >
> >
> >
> > On 6/14/06, Nathan Beyer <nb...@kc.rr.com> wrote:
> > > I stubbed out the method in luni-kernel (as well as two other methods
> > that
> > > were missing). I looked at DRLVM and it already has nanoTime
> > implementation,
> > > but it's not using the method you mentioned. I took a peek at the
> > > JCHEVM/classlibadaptar, but I couldn't quite discern the various
> > artifacts.
> > >
> > > -Nathan
> > >
> > > > -----Original Message-----
> > > > From: Tim Ellison [mailto:t.p.ellison@gmail.com]
> > > > Sent: Tuesday, June 13, 2006 6:34 AM
> > > > To: harmony-dev@incubator.apache.org
> > > > Subject: Re: [classlib][vm] Prerequisites for java.util.concurrent
> > > >
> > > > Nathan Beyer wrote:
> > > > <snip>
> > > > > Does this mean we can stub out the luni-kernel System and just get
> > the
> > > > VMs
> > > > > to implement it in their kernel classes using this method?
> > > >
> > > > That's what I was thinking, and we can implement it in the luni-kernel
> > /
> > > > classpathadapter as a reference for VMs if we so choose.
> > > >
> > > > Regards,
> > > > Tim
> > > >
> > > > --
> > > >
> > > > Tim Ellison (t.p.ellison@gmail.com)
> > > > IBM Java technology centre, UK.
> > > >
> > > > ---------------------------------------------------------------------
> > > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > > > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> > >
> > >
> > > ---------------------------------------------------------------------
> > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
RE: [classlib][vm] Prerequisites for java.util.concurrent
Posted by Nathan Beyer <nb...@kc.rr.com>.
Thanks. How does the Atomics class work in regards to volatile reads of
elements of an array? Here's the class I'm looking at implementing with the
Atomics API [1]. The CAS operations are trivial. It's the 'get' and 'set'
methods that I'm trying to figure out.
-Nathan
[1]
http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concu
rrent/atomic/AtomicIntegerArray.java?rev=1.19&only_with_tag=JSR166_PFD&conte
nt-type=text/vnd.viewcvs-markup
> -----Original Message-----
> From: Artem Aliev [mailto:artem.aliev@gmail.com]
> Sent: Friday, June 16, 2006 6:52 AM
> To: harmony-dev@incubator.apache.org
> Subject: Re: [classlib][vm] Prerequisites for java.util.concurrent
>
> Nathan,
>
> > VMI Atomicity/Lock API - All of the AtomicXXX classes are delegated to a
> > VM-specific API for atomic gets and sets. This API will need to be
> defined
> > and then implemented by the various VMs. Many of the lock APIs also make
> use
> > of this API.
>
> I have done some experiments with concurrent in DRLVM. So there are
> two kernel classes in the DRLVM that, probably, provide full set of VM
> dependent
> functionality required by util.concurrent. Both have special VM support.
>
> vm/vmcore/src/kernel_classes/javasrc/java/util/concurrent/locks/LockSuppor
> t.java
> -- park/unpark methods
>
> The special queue could be used in case you need to implement it in VM
> independent way.
>
> vm/vmcore/src/kernel_classes/javasrc/org/apache/harmony/util/concurrent/At
> omics.java
> -- CAS operations on references, ints, longs etc.
>
> The methods are aware of internal object layout and reference format.
> VM independent implementation could be done base on java monitors, but
> it kills the idea of the util.concurrent.
>
> Thanks
> Artem Aliev
> Intel Middleware Product Division
>
>
>
> On 6/14/06, Nathan Beyer <nb...@kc.rr.com> wrote:
> > I stubbed out the method in luni-kernel (as well as two other methods
> that
> > were missing). I looked at DRLVM and it already has nanoTime
> implementation,
> > but it's not using the method you mentioned. I took a peek at the
> > JCHEVM/classlibadaptar, but I couldn't quite discern the various
> artifacts.
> >
> > -Nathan
> >
> > > -----Original Message-----
> > > From: Tim Ellison [mailto:t.p.ellison@gmail.com]
> > > Sent: Tuesday, June 13, 2006 6:34 AM
> > > To: harmony-dev@incubator.apache.org
> > > Subject: Re: [classlib][vm] Prerequisites for java.util.concurrent
> > >
> > > Nathan Beyer wrote:
> > > <snip>
> > > > Does this mean we can stub out the luni-kernel System and just get
> the
> > > VMs
> > > > to implement it in their kernel classes using this method?
> > >
> > > That's what I was thinking, and we can implement it in the luni-kernel
> /
> > > classpathadapter as a reference for VMs if we so choose.
> > >
> > > Regards,
> > > Tim
> > >
> > > --
> > >
> > > Tim Ellison (t.p.ellison@gmail.com)
> > > IBM Java technology centre, UK.
> > >
> > > ---------------------------------------------------------------------
> > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][vm] Prerequisites for java.util.concurrent
Posted by Artem Aliev <ar...@gmail.com>.
Nathan,
> VMI Atomicity/Lock API - All of the AtomicXXX classes are delegated to a
> VM-specific API for atomic gets and sets. This API will need to be defined
> and then implemented by the various VMs. Many of the lock APIs also make use
> of this API.
I have done some experiments with concurrent in DRLVM. So there are
two kernel classes in the DRLVM that, probably, provide full set of VM
dependent
functionality required by util.concurrent. Both have special VM support.
vm/vmcore/src/kernel_classes/javasrc/java/util/concurrent/locks/LockSupport.java
-- park/unpark methods
The special queue could be used in case you need to implement it in VM
independent way.
vm/vmcore/src/kernel_classes/javasrc/org/apache/harmony/util/concurrent/Atomics.java
-- CAS operations on references, ints, longs etc.
The methods are aware of internal object layout and reference format.
VM independent implementation could be done base on java monitors, but
it kills the idea of the util.concurrent.
Thanks
Artem Aliev
Intel Middleware Product Division
On 6/14/06, Nathan Beyer <nb...@kc.rr.com> wrote:
> I stubbed out the method in luni-kernel (as well as two other methods that
> were missing). I looked at DRLVM and it already has nanoTime implementation,
> but it's not using the method you mentioned. I took a peek at the
> JCHEVM/classlibadaptar, but I couldn't quite discern the various artifacts.
>
> -Nathan
>
> > -----Original Message-----
> > From: Tim Ellison [mailto:t.p.ellison@gmail.com]
> > Sent: Tuesday, June 13, 2006 6:34 AM
> > To: harmony-dev@incubator.apache.org
> > Subject: Re: [classlib][vm] Prerequisites for java.util.concurrent
> >
> > Nathan Beyer wrote:
> > <snip>
> > > Does this mean we can stub out the luni-kernel System and just get the
> > VMs
> > > to implement it in their kernel classes using this method?
> >
> > That's what I was thinking, and we can implement it in the luni-kernel /
> > classpathadapter as a reference for VMs if we so choose.
> >
> > Regards,
> > Tim
> >
> > --
> >
> > Tim Ellison (t.p.ellison@gmail.com)
> > IBM Java technology centre, UK.
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
RE: [classlib][vm] Prerequisites for java.util.concurrent
Posted by Nathan Beyer <nb...@kc.rr.com>.
I stubbed out the method in luni-kernel (as well as two other methods that
were missing). I looked at DRLVM and it already has nanoTime implementation,
but it's not using the method you mentioned. I took a peek at the
JCHEVM/classlibadaptar, but I couldn't quite discern the various artifacts.
-Nathan
> -----Original Message-----
> From: Tim Ellison [mailto:t.p.ellison@gmail.com]
> Sent: Tuesday, June 13, 2006 6:34 AM
> To: harmony-dev@incubator.apache.org
> Subject: Re: [classlib][vm] Prerequisites for java.util.concurrent
>
> Nathan Beyer wrote:
> <snip>
> > Does this mean we can stub out the luni-kernel System and just get the
> VMs
> > to implement it in their kernel classes using this method?
>
> That's what I was thinking, and we can implement it in the luni-kernel /
> classpathadapter as a reference for VMs if we so choose.
>
> Regards,
> Tim
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][vm] Prerequisites for java.util.concurrent
Posted by Tim Ellison <t....@gmail.com>.
Nathan Beyer wrote:
<snip>
> Does this mean we can stub out the luni-kernel System and just get the VMs
> to implement it in their kernel classes using this method?
That's what I was thinking, and we can implement it in the luni-kernel /
classpathadapter as a reference for VMs if we so choose.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
RE: [classlib][vm] Prerequisites for java.util.concurrent
Posted by Nathan Beyer <nb...@kc.rr.com>.
> -----Original Message-----
> From: Tim Ellison [mailto:t.p.ellison@gmail.com]
>
> Nathan Beyer wrote:
> > I've been working with the java.util.concurrent code to see what we'd
> need
> > to have in place to get this code to be a part of Harmony.
> >
> >
> >
> > System.nanoTime() - A number of the classes rely on the new nanoTime
> method.
> > I'm assuming this would just be marked as a native method like
> > currentTimeMillis in luni-kernel, which would leave it up to the VMs
> > implement. I can easily stub out the Java code. Anyone interested in
> getting
> > our VMs to implement this method? I'm guessing that if IBM donates an
> > updated VME for 1.5 usage, this would also be provided.maybe?
>
> It's in the Harmony port library as:
> U_64 VMCALL hytime_hires_clock (struct HyPortLibrary *portLibrary)
>
> [1]
> http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/doc
> /vm_doc/html/hytime_8c.html?view=co
Does this mean we can stub out the luni-kernel System and just get the VMs
to implement it in their kernel classes using this method?
>
>
> > Annotations - There are a few places where the @SuppressWarnings
> annotation
> > is used. Building the annotations themselves is trivial, but we'll
> actually
> > need to be using Java 5 class files to properly compile annotation class
> > files. These can be commented out until the 5 class file support is
> enabled.
>
> Sounds like all Harmony-oriented VMs are happy for us to move to the 1.5
> compiler, even if getting the runtime annotation info may not be there
> yet.
>
> > PriorityQueue - There's at least one dependency on this class. I think
> > someone is already working on this one though.
> >
> >
> >
> > VMI Atomicity/Lock API - All of the AtomicXXX classes are delegated to a
> > VM-specific API for atomic gets and sets. This API will need to be
> defined
> > and then implemented by the various VMs. Many of the lock APIs also make
> use
> > of this API.
>
> Do these have to be VM-specific?
>
> > Arrays.copyOf() - Several classes utilize a set of Arrays.copyOf()
> methods,
> > which are new in Java SE 6 [1]. We'd either have to rework these
> > implementations to use System.arraycopy or just implement the new
> methods.
> >
> >
> >
> > AbstractMap.SimpleEntry<K,V> - The ConcurrentHashMap uses this class as
> a
> > base class for Map.Entry objects. This is a new public class, which is
> also
> > part of Java SE 6 [2]. Either this code can be reworked to just
> implement
> > the Map.Entry interface, or the SimpleEntry class can be built out,
> which
> > should be trivial.
>
> Strange that there are 6.0 dependencies. Is there a j.u.concurrent
> maintenance stream we can track rather than the dev stream?
>
> Regards,
> Tim
>
>
> > Thoughts, comments, questions?
> >
> >
> >
> > [1] http://java.sun.com/javase/6/docs/api/java/util/Arrays.html
> >
> > [2]
> >
> http://java.sun.com/javase/6/docs/api/java/util/AbstractMap.SimpleEntry.ht
> ml
> >
> >
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][vm] Prerequisites for java.util.concurrent
Posted by Tim Ellison <t....@gmail.com>.
Nathan Beyer wrote:
> I've been working with the java.util.concurrent code to see what we'd need
> to have in place to get this code to be a part of Harmony.
>
>
>
> System.nanoTime() - A number of the classes rely on the new nanoTime method.
> I'm assuming this would just be marked as a native method like
> currentTimeMillis in luni-kernel, which would leave it up to the VMs
> implement. I can easily stub out the Java code. Anyone interested in getting
> our VMs to implement this method? I'm guessing that if IBM donates an
> updated VME for 1.5 usage, this would also be provided.maybe?
It's in the Harmony port library as:
U_64 VMCALL hytime_hires_clock (struct HyPortLibrary *portLibrary)
[1]
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/hytime_8c.html?view=co
> Annotations - There are a few places where the @SuppressWarnings annotation
> is used. Building the annotations themselves is trivial, but we'll actually
> need to be using Java 5 class files to properly compile annotation class
> files. These can be commented out until the 5 class file support is enabled.
Sounds like all Harmony-oriented VMs are happy for us to move to the 1.5
compiler, even if getting the runtime annotation info may not be there yet.
> PriorityQueue - There's at least one dependency on this class. I think
> someone is already working on this one though.
>
>
>
> VMI Atomicity/Lock API - All of the AtomicXXX classes are delegated to a
> VM-specific API for atomic gets and sets. This API will need to be defined
> and then implemented by the various VMs. Many of the lock APIs also make use
> of this API.
Do these have to be VM-specific?
> Arrays.copyOf() - Several classes utilize a set of Arrays.copyOf() methods,
> which are new in Java SE 6 [1]. We'd either have to rework these
> implementations to use System.arraycopy or just implement the new methods.
>
>
>
> AbstractMap.SimpleEntry<K,V> - The ConcurrentHashMap uses this class as a
> base class for Map.Entry objects. This is a new public class, which is also
> part of Java SE 6 [2]. Either this code can be reworked to just implement
> the Map.Entry interface, or the SimpleEntry class can be built out, which
> should be trivial.
Strange that there are 6.0 dependencies. Is there a j.u.concurrent
maintenance stream we can track rather than the dev stream?
Regards,
Tim
> Thoughts, comments, questions?
>
>
>
> [1] http://java.sun.com/javase/6/docs/api/java/util/Arrays.html
>
> [2]
> http://java.sun.com/javase/6/docs/api/java/util/AbstractMap.SimpleEntry.html
>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org