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 Mon, 12 Jun 2006 07:17:59 GMT
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


Mime
View raw message