Re: Thread.finalize

Date view Thread view Subject view Author view

From: Alexandre Oliva (oliva@dcc.unicamp.br)
Date: Sun Dec 13 1998 - 14:41:48 EST


On Dec 13, 1998, Godmar Back <gback@cs.utah.edu> wrote:

> I apologize.

Apologies accepted :-)

> I really want the interpersonal relationships between
> kaffe-core as tension free and warm as possible.

So do all of us, don't we? :-)

> In my opinion, Amdahl's Law tells us that we shouldn't focus our
> optimization efforts on thread finalization.

Except on programs that rely on creating lots of Threads to run simple
commands. I have plans to implement this kind of program. And then,
if it's easy to improve a bit, why not improve it? :-)

> I didn't realize that your motivation was to save a function call,

Two, actually, because of the additional accessor method.

> I thought your motivation was cleanness in the sense that no outside
> entity should be able to invoke Thread.finalize0 maliciously,
> which could happen if there was a package access method.

I'd give it package access if that was all the problem, but then I
decided to take a step further.

> Please remind me what I silently undid a few days ago.
> I honestly don't remember what that was. Was is the #include
> "config-mem.h" in clr.c? That really was an oversight.

Yep, I was referring to that episode. Now it's my time to apologize
for taking an accident as a purposeful action.

> It did break the compile on FreeBSD, but you're right, I must have not
> been paying attention. The proper fix is of course to also include
> "config-std.h" (although I'm not sure if that's how it ought to be.)

I'll give it a try on SunOS later, but last time I tried to build on
SunOS (2 days ago, I think), it wouldn't :-(

> Yes there is. If you have a private anonymous inner class, then you
> don't want any method with package access manipulating it.
> Sun realized at some point that the way they did inner classes was
> incompatible with the protection mechanism in the JVM spec, and to my
> knowledge this problem is still open.

I think that it's a verifier issue; it should look at attributes of
inner classes to avoid unintended access. Admittedly, this could also
be used to give inner classes privileged access to their containing
classes, by adding attributes to the referred entities, but then it
woulnd't work in older virtual machines.

> Could we could get the opinions of other team members on the Thread.finalize
> issue.

Sure, I'll wait for (dis)approval from others.

Cheers,

-- 
Alexandre Oliva  http://www.dcc.unicamp.br/~oliva  aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil


Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:14 EDT