Adam Lally wrote:
> On 7/11/07, Marshall Schor <[EMAIL PROTECTED]> wrote:
>> 4) I think we want to design the TypeSystemImpl so that when it is
>> "locked" - it is thread-safe for running with multiple threads. This
>> seems to involve adding synchronization to other object accesses.
>> (Example object: the "locked" boolean). Because of (2) above, I'm
>> guessing (hoping) this would not have an impact on performance.
>
> Assuming for a second that "locked" really meant that the type system
> didn't change, it seems like there should be some more efficient way
> to do this. A thread could synchronize briefly on the TypeSystem once
> when it first begins to process a CAS (just to make sure there is a
> "write barrier" so the thread really sees all the changes done prior
> to the locking), and thereafter it does not need to synchronize every
> time it wants to query anything.
>
> Even without much contention for the lock, synchronization adds some
> overhead. I guess I've heard this is a lot less in recent JRE
> versions than it used to be, but I still worry.
>
> However, given the situation with the array types allowed to be
> created after the type system is locked, this gets a lot more
> complicated. I'm not sure there's any good way to do it other than to
> stop creating new types after the type system is locked. Like you
> said, Marshall, the framework itself never does this, but exposes a
> public method that could. Maybe we need to deprecate that method?
>
> -Adam
If we don't have this method, users can only use those array types that
were used in a descriptor somewhere. So you can't create an array of
tokens, for example, if it wasn't mentioned in a descriptor. That
would be contrary to my expectations, but I don't really care too much,
either.
Before we start deprecating methods, though, I would prefer it if we
sat down and thought the whole array story through. What we have now
could certainly use improvement, but I would like to understand what
the real design is that we're aiming at. For example, we still have
this comment in the type system impl (and the code that goes with it):
// Yes, the code below is intentional. Until we actually support real
// arrays of some
// particular fs,
// we have FSArray is the supertype of xxxx[] AND
// xxx[] is the supertype of FSArray
// (this second relation because all we can generate are instances of
// FSArray
// and we must be able to assign them to xxx[] )
--Thilo
