Re: Patch: Implement Class.getSigners

[Bryce McKinlay <bryce at mckinlay dot net dot nz>]

On Oct 21, 2003, at 5:24 AM, Tom Tromey wrote:

> > > > > > "Bryce" == Bryce McKinlay <bryce@mckinlay.net.nz> writes:
>
> Tom> I'd really like it if we got rid of the requirement to add a new
> Tom> clause to the marker every time we add a field to Class.  
> Forgetting
> Tom> this has caused bugs for us before.
>
> Bryce> Yeah. I guess we'll have to come up with something to handle the
> Bryce> marking if we're going to put class fields into the class 
> objects for
> Bryce> the new ABI. Its pretty ugly at the moment with all the special 
> cases
> Bryce> in there.
>
> Since I added the "signers" field to Class, we can no longer compile
> Classpath to bytecode, as the Classpath Class has its own "signers"
> field.
>
> It would be nice if this didn't happen.  I can't help thinking this is
> somehow related to the above.  E.g., if we declared all our fields in
> our Class.java, we could generate a mark descriptor for Class just
> like we do for everything else

Marking is somewhat complicated because not all of Class's fields are 
Java types. We'll need to have a split between
"runtime-internal" fields that are known to the compiler and fixed by 
the ABI (things like the ancestors, interface and method tables, etc - 
some of which also need to be marked), and fields like the 
protectionDomain, signers, etc that can be declared in Class.java and 
accessed like any regular Java field.

Since the class objects and mark descriptor are generated at runtime, 
_Jv_BuildGCDescr would need to know about the internal fields somehow 
and add them to the descriptor. Or, perhaps a simpler way would be to 
use a mark procedure like we do now and special-case for the internal 
fields, then just treat the java-declared fields as we would any other 
class.

In any case, its definitely a bug that we can have conflicts when 
generating bytecode.

Regards

Bryce.