Mixed stuff

[Hans-Dieter.Dreier@materna.de]

--hEEaW2VUU91N5Xbf1OgAjJBZcLMSYzGu
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

>Hans-Dieter Dreier wrote:
>
>> I would think that the compiler knows the implementation (at least the
>> signature, that is, whether it is a method call or a data member) of all
>> accessible items in the superclass. Then it would not need to generate
>> get/set calls unless necessary. Using calls to access an item that can b=
e
>> directly accessed carries a *huge* performance penalty.
>
>Well for a start this would increase fragility, since at the language
>level you can treat it can be a get/set or physical field.

If by fragility you also mean that clients and derived classes must be reco=
mpiled if they use the affected member, you're right - but isn't this inevi=
table for most changes of the member's signature? Certainly there are vario=
us degrees of fragility. It is important to find the right balance between =
fragility and speed (both compiler's and object's). The architecture should=
 be designed such that the user has a chance to choose among the alternativ=
es. This might be not easy to implement, however, and the resulting modules=
 may not mix well.

>It's also hard to know just whether it can set it out using just a
>field.  This is because these get/sets could be the target of a dynamic
>dispatch, which you can't tell.  This is especially true if you allow
>multiple implementations.  So if it's part of a dynamic dispatch it must
>be a get/set.  The compiler can find out this sort of information
>through optimisation, but it's hard to just know.

Why should it be hard to find a class member's signature? Isn't that all th=
at is needed? Maybe I'm missing the point or we are using different assumpt=
ions, so please explain.

>I'm assuming by "no link time" you refer to at run time.  That being
>said, everything at run time is dynamic in Java.  I was referring to
>compile time linking - sorry if I was vague.  The important thing is you
>don't need to recompile the class.  Offset information is determined at
>link time, also can MI instance layout information.

Do you mean to say that members' offsets are *set* by the linker?
Interesting idea, hmmm... Certainly this involves a lot of fixups at link t=
ime, but it *could* be done if an executable is constructed the usual way. =
How would this mix with incremental linking or replacement of modules? At l=
east all the fixup information would have to be retained as long as further=
 incremental linking should be possible. And wouldn't we have to write our =
own linker?

>> Example: If you have an index to all the objects of some kind and you
>> don't want this index to interfere with GC. That is, objects may be
>> collected even if they are mentioned in the index, using weak references=
.
>> Those would be set to NULL when the object is being collected, in order =
to
>> avoid dangling pointers.  I don't think weak references are an important
>> feature. Implementing them afterwards would have a heavy impact on GC,
>> however.
>
>No, I know what they are.  =3D)  I just wondered how they were relevant to
>implementing elimination optimisations.

Not really. But I'd leave eliminition optimisations to GC, if whole object =
are to be eliminated. At least for a start. GC is already there, and it is =
performing at runtime, so the compiler need not know about dynamic behaviou=
r of the program. I wouldn't mind if the compiled objects contain *a little=
* unnecessary stuff as long as it has no real impact on execution speed or =
memory consumption.

>I suspect the advantage of precompilation is more related to reduced
>size of the AST over the source.  But the real reason I want to use ASTs
>is that they are easy to edit, use, and globally optimise.

I found that *source code* is the most compact form if unneccessary layout =
& comments are stripped (automatically). IMO, no AST can be that small. But=
 nowadays memory size isn't that important anymore.

>> The CString was created on the stack (which I didn't know by then),
>> passed to the constructor of SomeClass, assigned to some SomeClass membe=
r
>> and then discarded, leaving a dangling pointer behind. A silly mistake, =
to
>> be sure, but if you're not familiar with the conventions...
>
>And that too should be and can be prevented with GC.

Of course. I really can't understand those (C++ programmers) who insist on =
doing memory management by hand. Maybe they don't know better. Well, someti=
mes the environment makes GC hard...
>
>-- =

>     Matthew Tuck - Software Developer & All-Round Nice Guy
>             mailto:matty@box.net.au (ICQ #8125618)
>       Check out the Ultra programming language project!
>              http://www.box.net.au/~matty/ultra/
>
>


--

Regards,

Hans-Dieter Dreier
(Hans-Dieter.Dreier@materna.de)=

--hEEaW2VUU91N5Xbf1OgAjJBZcLMSYzGu
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

IDENTIFIKATIONSANGABEN:
a20389a.txt IA5 DX-MAIL X.400 User Agent=

--hEEaW2VUU91N5Xbf1OgAjJBZcLMSYzGu--