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:[EMAIL PROTECTED]
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:[EMAIL PROTECTED]

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 ([EMAIL PROTECTED])
IBM Java technology centre, UK.

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



--
Paulex Yang
China Software Development Lab
IBM



---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--
Paulex Yang
China Software Development Lab
IBM



---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to