harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paulex Yang <paulex.y...@gmail.com>
Subject Re: [classlib][vm] Prerequisites for java.util.concurrent
Date Tue, 13 Jun 2006 11:50:09 GMT
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| <cid:part1.06010603.05020808@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


Mime
View raw message