classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: API clean up patch


From: David Holmes
Subject: RE: API clean up patch
Date: Wed, 18 May 2005 13:02:49 +1000

Archie Cobbs writes:
> Who wants a VM that's incapable of generating stack traces??

Probably noone, but I'd love to be able to NOT have the stacktrace always
filled in automatically upon construction.

> Summary of changes:
>
>    - Add a "vmdata" field to ClassLoader, VMThread, and VMThrowable.
>      Seems to me that every VM will require these (am I wrong?)

Did you mean ClassLoader or VMClassLoader?

While every VM may need VM specific data fields I don't see how adding these
really helps because you can't know how the VM needs to use them. If a
particular VM has to modify the VMxxx classes anyway then they can add
whatever data fields they need. In OVM we tend to have multiple "opaque"
references to VM data structures.

>    - Constructor.getParameterTypes() and getExceptionTypes() become
>      native methods, to align with Field.java and Method.java, and
>      because nowhere is the code that sets these fields anyway.

Shouldn't there be VMConstructor, VMField, and VMMethod  classes that are
deferred to rather than making these native? Or is the expectation that a VM
will have to modify these classes regardless? (I don't think there is much
VM independent code that can really go in these classes, so expecting the VM
to modify Constructor et al directly is not unreasonable.

Just my 2c.

David Holmes







reply via email to

[Prev in Thread] Current Thread [Next in Thread]