harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [classlib][vmi] VMI classes for Thread/Object manipulation for java.util.concurrent
Date Thu, 21 Sep 2006 21:26:14 GMT
Andrey Chernyshev wrote:
> On 9/20/06, Tim Ellison <t.p.ellison@gmail.com> wrote:
>> Andrey Chernyshev wrote:
>> > Thanks Nathan! The Threads interface looks fine. Still, may be it
>> > would be nice if two different methods are allocated for parkNanos and
>> > parkUntil - passing the extra boolean parameter seems like an
>> > overhead, though very little.
>> I agree, just create another method rather than passing in a boolean
>> flag.
>> How are you going to avoid apps calling these public methods?  We can do
>> a security/calling stack check on each method send, but it may be
>> preferable to make Threads a singleton and check in a getSingleton()
>> call.
> Yes, accessor classes were also designed as sigletones those instances
> can only be obtained through the AccessorFactory which handles the
> security checks.
> I wonder if it may make sense to have a single factory for accessor
> classes and Threads.

Just let each type handle the security check.


>> Do these need to be rearranged?  Why can't we write the suncompat's
>> Unsafe equivalents in terms of these accessors?
> I wouldn't wish we a have multiple classes which are doing the same
> things, even if some of them are delegating work to others (e.g.
> Objects is written on top of accessors or accessors are rewritten on
> top of Objects) - this seems to me just like extra layers/function
> calls.

Agreed.  I suggest that we have separate types for VM-specific vs. JNI
based accessors so we can have a clean kernel code and common code split.

As written elsewhere, the only delegation/adapter code will be from
suncompat Unsafe to o.a.harmony types.

>> > plus the o.a.util.concurrent.Atomics [5] from the DRLVM.
>> Yep, these need to be moved into the kernel for all VMs to implement.
>> We can define them in (a new) concurrent-kernel unless there is
>> consensus that they would be more generally useful, i.e. misc-kernel or
>> luni-kernel.
> If all VM's are supposed to be 1.5+ compliant anyways, why not just
> adding to the luni-kernel...

Because we want to keep the modularity of concurrency utils separate
from LUNI.  If there is no need for atomic/volatile operations outside
the concurrency module, then we should put them into a concurrent-kernel.


>> Andrey: did you check that everything in Objects is covered by existing
>> accessor/atomics?
> Yes, the Objects is a subset of the existing accessors + Atomics
> combination.

Then how about we delete 'Objects' and implement those parts of Unsafe
in terms of existing ObjectAccessor methods?


>> Do accessors need to be in kernel?  They are implemented solely in terms
>> of JNI - right?
> Right. It is clear that now we have a set of API's that provide
> different type of access to objects (e.g. simple, atomic or volatile),
> arrays and threads. I can imagine the following types of it's
> classification:
> - VM specific or not (or, can be implemented with JNI or not)

yep, this is our kernel vs. common code distinction.

> - Package where they are needed (e.g. j.u.c, awt/swing, io or whatever)

yep, we need to judge where the best place is for each type.  Since they
are o.a.harmony types the risk of putting them too 'low' (e.g. luni) is
that they bloat the module where they are not actually used; and the
risk of putting them too 'high' (e.g. swing) is that we create
dependencies 'up' the semantic stack.

In this instance I think we only need to decide between whether
accessors go into luni, concurrent, and misc (maybe misc gets rolled
into those two?).

> - Objects they are accessing (e.g. object, array, thread)

Do you think we need this distinction in the type hierarchy?  All
accessors work on fundamental types, right?

> We may pick one or another type of classification and split the API
> into different pacakges/jars in accordance with it.
> On the other hand, obviously all of these classes would have the same
> mechanism for getting their instances, and most likely share the way
> how fieldID's (or offsets) are obtained. In other words, it may be
> unnatural to try to split them. This is why I proposed to keep them in
> a single place.

If we can think of a usecase for volatile/atomic operations outside
concurrent then I agree they go into luni & luni-kernel.  If we cannot
then they are split into luni, concurrent, and concurrent-kernel.

> Assuming that there is a portion in this API set which
> is VM-specific, it probably may make sense to put them into kernel.


>> +1 for Atomics moving into a kernel.
>> Same comment as above for atomics etc. not being left as unguarded
>> public types/methods to avoid surprises from mischievous apps.
> Right, I would add the Atomics creation to the AccessorFactory if we
> agreed that all of this stuff is of the same nature.

Again, if they are all in the same component, then one factory is ok
(but unnecessary imho) -- if they are in different components then let's
not couple them at this point.

What do you think?



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

View raw message