Hi Etienne,
> I have not looked in details at the code, but do you really need to do
> the test on every invocation of this specific method? Can't the test
> for security manager be done once and for all earlier? Then you can use
> inheritance/delegation (or other standard design patterns) to delegate
> the call to the appropriate method that will assume a "non-null" pointer
> (or null).
In the case of the security manager it defaults to null and can be set
once and once only. However, the security manager may be set at any
point. You can, however, trap the setting of it. For other objects it is
possible they could be set more than once. I think it's unclear the
implementation path to take then.
> I think that execution time of application versus applets shouldn't be
> prioritized one over the other; so the exception mechanism is not a good
> solution as it would favor one of the two, and slow down the other.
I agree, however, the explicit null check will slow down the execution
speed of applets. Using an object that does nothing won't slow the
execution speed of applets down (assuming no optimisation, etc.). However,
the method invocation may cost more than a null check for the
case where we don't have a security manager. I propose you may be able to
more easily optimise this case though.
> My comments on exceptions are NOT VM specific. Exceptions should be
> "exceptional". From a VM designer point of view, the last thing to
> optimize (in priority) is exceptions.
I don't know. Saying exceptions are exceptional is one way of viewing
there use. An alternative way of programming is to write code assuming no
problems will occur during execution. Then go back and catch the cases
where things go "wrong" (exceptions to the normal way things happen). Often
things go "wrong" more often than we like and we end up with lots of
exceptions. I think it is important for a VM to optimise exceptions :-)
> I would even expect exception execution time to hardly be measurable, as
> the exception object has to store the stack trace, which can be of
> varied length, and thus the simple creation of an exception object might
> also trigger garbage collection, create additional garbage (and thus put
> more pressure on the memory management system). Unreliably measurable
> exceptions mean unreliably measurable application execution time, etc...
Agreed. If only it were possible to dictate the way a language is used.
> Anyway, have fun!
Cheers,
Ian Rogers
