Re: GCJ/minGW produced executables and linux/wine

[Andrew Haley <aph at redhat dot com>]

Jeff Sturm writes:
 > On Wed, 5 Mar 2003, Andrew Haley wrote:
 > > That's true only of targets to which gcj has not yet been ported.  A
 > > gcj port absolutely requires a working SEGV handler.
 > 
 > And a working MD_FALLBACK_FRAME_STATE_FOR.

Or sjlj.

 > Has anyone succeeded yet implementing this macro for a non-Linux
 > target?

Not that I know of.  It's harder to do on a system where the shape of
the stack frame is undocumented.  Not impossible, but so far no-one
has tried to do it.

 > > -fcheck-references is a half-baked workaround.
 > 
 > -fcheck-references isn't that terrible really.  It adds a little to
 > code size but has a negligible effect on runtime, since the branch
 > outcome is easy to predict.

Last time I benchmarked it was significantly worse, probably because of
code bloat.

 > It also may avoid certain pessimizations resulting from
 > -fnon-call-exceptions.
 > 
 > -fcheck-references has no effect on native code,

That is its greatest weakness.

 > but that's probably fixable.

Well, there is only one good way that I know of: use smart pointers in
CNI.

So, this

java::lang::reflect::Method *
java::io::ObjectOutputStream::getMethod (jclass klass, jstring name, 
					 JArray<jclass> *arg_types)

turns into

ref<java::lang::reflect::Method>
java::io::ObjectOutputStream::getMethod (jclass klass, jstring name, 
					 ref<JArray<jclass>> arg_types)

It's easy to do although rather boring.  We could perhaps automate the
transformation.

IMO we should do this, but everyone else seems worried that it
involves changing CNI.  That doesn't seem such a bug deal IMO.  It
would make gcj run correctly on far more targets.

 > (I wonder what other VM's do?  Rely on signal handling or
 > explicitly test each pointer?)

The former, probably.  It's much easier to do this if you control your
own stack, which JITs and interpreters all do AFAIAA.

 > > -fcheck-references is the configuration default unless we're using
 > > sjlj.  sjlj is deprecated in gcc and will not be supported for ever.
 > 
 > You are correct.  Sjlj is indeed the odd case.
 > 
 > >  > > Please let me know which tests still fail.
 > >
 > > Throw_2 passes?
 > >
 > > Wow, that's *really* weird.  It's supposed to detect the case when
 > > there is not a working SEGV handler, even with -fcheck-references.
 > >
 > > That is bad news.  I would love to know _how_ that test passes.
 > 
 > No idea.  On a hunch, I'm starting a build with no-gc.

I think Ranjit already explained.  We need to change the test to print
"OK" in each catch NullPointerException block.

Andrew.