Re: 'instrumenting' arrays

Hmmm

Perhaps I should make the transactional array more explicit and should
not allow
normal arrays to become transactional. If a user wants to have a
transactional array,
he has has to use some kind of provided wrapper around the array instead.

So something like:

TransactionalArray<String> array = new TransactionalArray<String>(10);

The array is used inside the TransactionalArray class so I don't need to worry
about what type of array it is.

Thanks Scott and I hope you had a nice vacation :)

On Wed, Mar 10, 2010 at 12:42 AM, Scott Vachalek <[email protected]> wrote:
> Using stack frames, you can probably rule out some cases where it's clearly
> coming from a simple array  (e.g. it was just constructed in this same
> method) but I think this will be a rare scenario.  If an array is passed in
> as a method argument, for example, you would have to backtrack to all of its
> callers and so on.  In simple cases (not that they're simple to solve) you
> can figure it out but ultimately you're looking at the halting problem.
> I think you're going to more or least have to treat them all as if they
> might be your transactional array... invoke some method that decides if they
> are or not and do the right thing.
>
> On Tue, Mar 9, 2010 at 2:04 PM, Peter Veentjer <[email protected]>
> wrote:
>>
>> I'm writing an STM called Multiverse
>> http://multiverse.codehaus.org
>>
>> One of the things I want to add to one of the next releases is support
>> for transactional arrays. I already figured out how to deal with the
>> array itself;
>> if an transactional object has a field of type array of type X, I
>> upgrade the type of that field to: array of type transactional
>> reference of type X. This is
>> peanuts. I already got a prototype TransactionalArray working that
>> doesn't rely on instrumentation and lazily fills the array with
>> transactional references.
>> And I also got transactional references for primitives that reduce the
>> amount of boxing/unboxing.
>>
>> The big problem is with the instrumentation of methods because it is
>> hard to figure out if the bytecode that accesses an array is touching
>> a normal array
>> or a transactional one. With GET_FIELD/PUT_FIELD this isn't a problem
>> because the instrumentation can determine based on the type of the
>> field owner
>> if something extra needs to be done. But in this case the context
>> matters and not the type.
>>
>> So has someone experience with 'instrumenting' arrays?
>>
>>
>> --
>> You receive this message as a subscriber of the [email protected] mailing list.
>> To unsubscribe: mailto:[email protected]
>> For general help: mailto:[email protected]?subject=help
>> OW2 mailing lists service home page: http://www.ow2.org/wws
>>
>
>

-- 
You receive this message as a subscriber of the [email protected] mailing list.
To unsubscribe: mailto:[email protected]
For general help: mailto:[email protected]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws