harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrey Chernyshev" <a.y.chernys...@gmail.com>
Subject Re: [classlib][concurrent] java.util.concurrent module proposal
Date Wed, 12 Jul 2006 16:22:14 GMT
On 7/12/06, Geir Magnusson Jr <geir@pobox.com> wrote:
>
>
> Tim Ellison wrote:
> > Nathan Beyer wrote:
> >> I've checked in my proposal for the java.util.concurrent module at
> >> https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk/s
> >> andbox/juc-proposal.
> >
> > You didn't just check in a proposal, you also checked in
> > Doug Lea et al's code.  Nobody should commit other people's code into
> > svn this way.
>
> The code is under public domain license, so there should be no problem
> doing it since Doug et al produce no builds, and they suggested we do
> this.  it's also in our sandbox, and we're not redistributing it yet.
>
> >
> > Was there a reason to create .../classlib/trunk/sandbox? wouldn't
> > .../classlib/sandbox make more sense?
>
> We already had the sandbox under /trunk
>
> >
> >> The README gives a high level overview of the content. I've generated some
> >> documentation and published it here for easier browsing:
> >> http://people.apache.org/~ndbeyer/concurrent/project-reports.html.
> >>
> >> Design -
> >>
> >> Most of the code is straight from Doug Lea and the JSR group. The only piece
> >> I've added are the service interfaces that the VM must implement and I've
> >> uplifted the original code, where necessary to utilize these VM service
> >> interfaces.
> >
> > I was hoping that we would be able to discuss these first, so it seems
> > you have already concluded these questions independently; but I'll ask
> > them anyway to hear the rationale:
> >
> > What interfaces to the VM, or internal APIs to the class library code,
> > does the concurrent code currently use?
> >
> > Do you think it makes sense to modify the concurrent code, or create an
> > adapter that maps onto the Harmony VM / internal APIs?
> >
> > I see copying the code as a one-way operation.  We can hope to track
> > updates to the original code thoroughly, but I don't see any fixes made
> > in Harmony making it back directly into Doug's repository.
>
> Why not?  We just offer them to Doug, and he can accept or reject.
>
> >
> > Is there a reason why we want to fork this code?  I'd rather we worked
> > with Doug (contributing directly to his project to make it more widely
> > usable etc).
>
> Tim, isn't this what we discussed? This isn't a fork in the community
> sense, it's what amounts to a "read only" copy of the code for purposes
> of building, but tracking what Doug does?  We've been very clear about that.
>
> >
> >> org.apache.harmony.concurrent.AtomicSupport [1] - The service interface for
> >> 'java.util.concurrent.atomic' features such as CAS (compare and swap) and
> >> volatile read/writes.
> >
> > These look like the right set of operations (without having gone through
> > the list exhaustively).
> >
> > It would be good to move the AtomicSupport type into o.a.h.luni.platform
> > so they can be used by other code (thinking reflect/objectIO etc.)
> > without having to depend on all the concurrent utils.
> >
> >> org.apache.harmony.concurrent.LocksSupport [2] - The service interface for
> >> 'java.util.concurrent.locks' support. This is similar to the
> >> java.util.concurrent.locks.LockSupport contract.
> >
> > These are thread operations, perhaps just a misnomer.  In LockSupport we
> > need MonitorEnter and MonitorExit etc.
> >
> > <sidebar> would be good to round out the set with a type to
> > invokeVirtual and friends too </sidebar>
> >
> >> These service interfaces would need to be implemented by a VM provider and
> >> their implementations are registered using Service Provider configuration
> >> files, as defined by the JAR specification [3]. The rationale for the design
> >> of the support classes was to preserve as much of the original code as
> >> possible,
> >
> > Do you mean by implementing the internal APIs that the concurrency code
> > has on Sun's implementation?
> >
> >> so as to facilitate future maintenance and isolate the external
> >> variability with well-defined service contracts.
> >
> > This SPI is a runtime framework, right?  Do you really think that people
> > will leave it until runtime to determine which provider they have for
> > these methods?  I doubt it -- they are so closely tied to the VM that
> > they will not be pluggable at runtime.  The VM/JIT will have to
> > recognize these as special methods to make it anything like usable.
>

> I agree - it doesn't seem right to use the SPI for this, but I haven't
> looked at the code.

I tend to agree with that too.

I guess the idea was that the SPI approach could help to keep the
j.u.concurrent code "truly" shared between Harmony and RI. However,
the j.u.concurrent code will have to be modified for that accordingly
- I'm not sure if it is currently looking for any
LockSupport/AtomicSupport VM service providers. It all works under
assumption that we propose the changes for SPI approach back to the
JSR group. Am I getting your ideas right, Nathan?

On the other hand, it seems like the SPI will really be needed only
for AtomicSupport class - LockSupport is a "public" class and can
always be substituted by VM vendor. I think that the j.u.c.atomic
classes implementations will mostly be forwarding calls to the
AtomicsSupport hence they are unlikely to be extensively changed over
time, we can probably modify them once and keep untouched in the
Harmony source tree.

Another point is that, atomic classes are performance sensitive - one
would expect them to work quickly. SPI architecture probably adds some
extra level of indirection, in contrary to a simple static method call
which is likely to be inlined by the optimizing compiler. Wouldn't it
produce a slowdown?

Other than that, the proposed interfaces look to me pretty reasonable.
The only small question I have: in the AtomicsSupport class, the names
for CAS operations do not differentiate between types of objects (e.g.
they are always named just as "compareAndSet"), while volatile
variable access methods are named differently for different types -
"volatileSetLong", "volatileSetInt" e.t.c. Can we choose a single
naming convention for all methods?

Thanks,
Andrey.


>
> >
> >> If you wan to see what source code changed, then extract the
> >> 'concurrent.tar.gz' and compare the 'concurrent' folder from there to the
> >> 'concurrent/src/main/java/java/util/concurrent' folder.
> >
> > hmm, thanks.
> >
> >> TODOs -
> >>
> >> * Implement the service interfaces by a VM!!
> >>
> >> * Setup the build scripts (trivial) - currently there's a 'pom.xml' that's
> >> in the project, which can be used with Maven to run a build and generate
> >> documentation (mvn package site). It was just quicker for me to do this
> >> while I as hacking.
> >>
> >> * Consider and possible implement base/default service providers for win32
> >> and linux that VMs can use if they like.
> >>
> >> * Determine the best place to integrate the TCK source, which is also
> >> available at Doug Lea's site.
> >
> > Are you serious?  Why would we copy the TCK into Harmony too?!
>
> Because that isn't the TCK, but simply testcases?
>
>
> >
> >> * There are a LOT of changes, fixes and enhancements to the code at Doug
> >> Lea's site; consider what code we should additional take.
> >
> > As I said above, I'd rather we work with Doug directly.  I don't
> > understand why we have to 'take ownership' of this code.
>
> You keep saying that, but I keep trying to tell you that this *is*
> working with Doug directly.   He's fine with this approach.  We're not
> *forking* the code - we're just getting a copy for convenience, with the
> intent of working with Doug, offering changes back, and tracking what
> his tagged versions are.
>
> geir
>
> >
> >> Let the discussions begin.
> >
> > Thanks for tackling this.
> >
> > Regards,
> > Tim
> >
> >
> >> -Nathan
> >>
> >>
> >>
> >> [1]
> >> http://people.apache.org/~ndbeyer/concurrent/apidocs/org/apache/harmony/conc
> >> urrent/AtomicSupport.html
> >>
> >> [2]
> >> http://people.apache.org/~ndbeyer/concurrent/apidocs/org/apache/harmony/conc
> >> urrent/LocksSupport.html
> >>
> >> [3]
> >> http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html#Service%20Provider
> >
> >
>
> ---------------------------------------------------------------------
> 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
>
>


-- 
Andrey Chernyshev
Intel Middleware Products Division

---------------------------------------------------------------------
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