Re: Patch: add extensions directory contents to VMClassLoader classpath.

[Andrew Haley <aph at redhat dot com>]

Ranjit Mathew writes:
 > Andrew Haley wrote:
 > > Ranjit Mathew writes:
 > [...]
 > >  > we're installing the SEGV handler only after the VMClassLoader
 > >  > has initialised. Hence the SEGV was not caught via the
 > >  > normal exception handling mechanism.
 > > 
 > > Ah, okay.  Not a problem then.
 > 
 > Do I take this as an "OK" for the "dir.exists()" patch?

It looks to me as though that patch qualifies for the "fixes something
broken, obviously correct" get-out clause.

[P.S.  If you just throw an "if" around a block of code, it's much
easier to understand a patch made with "diff -w".]

 > In any case, I decided to see if we can install the SEGV and FPE
 > handlers before the VMClassLoader is initialised, so that a
 > NullPointerException is thrown for the original bug.

Umm, not so obvious.  I suppose, strictly speaking, that all Java code
should have the SEGV and FPE handlers around it, but I don't think
it's very important in the primordial startup phase.

 > So I tried out the following patch on a clean tree (i.e.  without
 > the "dir.exists()" patch) and was able to bootstrap and pass all
 > the libjava and Jacks testsuite again. I tested this out on
 > i686-pc-linux-gnu. Does anyone think that this could create
 > problems on other platforms?
 > 
 > (I also noticed that we don't protect INIT_SEGV with a #ifdef
 > HANDLE_SEGV - I think this is an oversight and not deliberate.)
 > 
 > Is this OK for mainline?

Yes, OK.  This is a more risky patch, but at this stage in the
development cycle we can give it a go.

 > In any case, I think the "dir.exists()" patch should still
 > be applied - there's no reason to wait for a NullPointerException
 > to be thrown if it can be avoided easily.

I agree.

Andrew.