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:01:36 GMT
Andrey Chernyshev wrote:
> On 9/21/06, Nathan Beyer <nbeyer@kc.rr.com> wrote:
>> > From: Tim Ellison
<snip>
>> I'll add a factory/singleton method, which can be used then perform any
>> security checks. Then I presume other Classlib code would invoke this via
>> PrivilegedAction, correct?
> 
> The other option could be just to check that the class loader of the
> calling method is the same as the one which was used to load Threads -
> this is how it is done in the AccessorFactory. I suspect the
> PriviledgedAction block would do eventually the same, but possibly
> with some extra expense on creating the PriviledgedAction object.

Agreed, make the constructor private/default visibility then the
getSingleton() method can check...
if (VM.callerClassLoader() != null) { throw new SecurityException(); }

>> > Do these need to be rearranged?  Why can't we write the suncompat's
>> > Unsafe equivalents in terms of these accessors?
>>
>> Personally, I'm all for combining all of these down into one set of
>> interfaces in one module. It's really confusing to have all of these
>> different Object manipulation interfaces that seem alike, but are used in
>> different places.
> 
> I completely agree with this point of view.

The only 'duplication' of API behavior will be the functionality in the
o.a.harmony types and the sun.misc.Unsafe adapter.  That is, let's
design the o.a.harmony types along the dimensions we want to distinguish
and write Unsafe in terms of those.

<snip>

> I don't know the original intent that was put in the Unsafe design. My
> only guesses would be:
> To access the field in JNI code, you'd finally need the jfieldID. Then
> the question comes - what to remember in the Java heap, 64-bit fieldID
> or a Field object? The Field object is likely to consume more memory
> in the Java heap compared to the long value.
> 
> Perhaps there could be also some pointer arithmetic with fieldID's
> assuming that they are corresponding to the field offsets in the
> object, and assuming that the layout of fields in the objects is
> known. But I'm not sure if we want our classlib code be dependent on
> that - ID's could be more abstract than the offsets.

No point in speculating, let's do the right thing for our needs.

Regards,
Tim

-- 

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


Mime
View raw message