Segv Fault Handler for Java?

[LaBird]

Dear all,

I'd like to know if we can do some user-level signal handling like those
provided in the Linux + C/C++?
What I would like to do is to capture SEGV fault signal (or to make it
simpler, null pointer exception) which can happen anywhere in the Java user
program. Then a user-level function / code segment (the handler) is invoked
to do something that handles the fault, and finally program can resume from
the faulting point when the handler finishes.

I don't have much experience in Java exception handling, but my pals told me
that using simple try-catch cannot achieve the above behavior. Is there any
other workaround? Thanks in advance!

Best Regards,
LaBird (Benny).
[Email: Please remove the underscores for the correct email address.]

 

[Joshua Cranmer]

Dear all,

I'd like to know if we can do some user-level signal handling like those
provided in the Linux + C/C++?
What I would like to do is to capture SEGV fault signal (or to make it
simpler, null pointer exception) which can happen anywhere in the Java user
program. Then a user-level function / code segment (the handler) is invoked
to do something that handles the fault, and finally program can resume from
the faulting point when the handler finishes.

Global try-catch is possible (see
Thread.setDefaultUncaughtExceptionHandler), but since the entire stack
is unwound in the process, it's only a last resort.

That said, I don't see why you would need such functionality.
NullPointerException and other subclasses of RuntimeException tend to be
indicative of programmer error (most of them can be avoided with runtime
checks like "if (foo != null)") that is rarely recoverable; subclasses
of Error are generally problems that the application can or should not
handle; the other checked exceptions should typically be handled in the
most local frame of reference possible, negating the need for such
global try-catch.

I don't have much experience in Java exception handling, but my pals told me
that using simple try-catch cannot achieve the above behavior. Is there any
other workaround? Thanks in advance!

My best advice is to think hard about what you want to do to make sure
that try-catch is unsuitable. If you really must have such global
nature, you can use the global try-catch.

If you REALLY want to use fault handling, you could go to JNI...

 

[LaBird]

Hi Joshua,

Thanks a lot for your answer.
The reason I considered such feature is because I was thinking about whether
a user-level mechanism to build a software DSM (distributed shared memory)
using Java is possble. In such case the user-level add-on program (as a
library) should be able to bring in a copy of "foo" from another machine in
case it does not have one (or if it's own copy is dirty). For such purpose,
the use of user-level SIGSEGV handler has been widely used in many Linux + C
/ C++ DSM implementations. But I believe Java implementations of DSM (such
as Jackal) are mostly in the level of modifying the Virtual Machine in order
to achieve this purpose.

Best Regards,
LaBird (Benny).

 

[LaBird]

Hi Lew,

When programming in Java, do not think in terms of machine-level
constructs like SIGSEGV. Think in terms of the algorithms. Java has the
facility to provide the features (goals) you want, but likely not via the
techniques (strategies) you seem to be planning.

Consider grid-computing products like WebSphere's Object Grid for examples
of how others have approached similar requirements.

Thanks for the answer, and sorry about top-posting in my previous post.

Best Regards,
LaBird.

 

[Kevin McMurtrie]

The signaling that you're thinking of doesn't exist. The use you speak
of is a bad design even in C/C++.

Distributed caching in Java is performed through a cache element
container that has a getter and setter for data that is internally
immutable. The implementation of get() and set(...) manage
serialization of objects and inter-server communication as needed.

 

[Daniel Pitts]

Hi Lew,



Thanks for the answer, and sorry about top-posting in my previous post.

Best Regards,
LaBird.

It sounds like you might also want to look into the JSR on Isolates
(Eye-so-lits) <http://bitser.net/isolate-interest/>

Very loosely speaking, it is a way of managing several isolated "sub-jvm"

 

[LaBird]

Hi Daniel,

It sounds like you might also want to look into the JSR on Isolates
(Eye-so-lits) <http://bitser.net/isolate-interest/>

Very loosely speaking, it is a way of managing several isolated "sub-jvm"

Thanks for your answer. After briefly reading the JSR on Isolates, together
with other solutions provided by others in this thread, I have a feeling
that most of the solutions work by providing a set of extra API, and require
programmers to call these API on the target objects so that the mechanism
(such as object caching) can work. In other words, the mechanism does not
work on all objects, and if some objects do not call the API, they won't be
able to use that provided feature.

Does this actually increase the burden of programmers since they need to
modify existing Java programs so that those new feature can work on those
objects? Will there be more programmer-transparent solution, for example,
just calling one class or one "wrapper" method at the start of the program,
so that all/most objects in the program can benefit? Or do I just miss how
those API work?

Thanks again!

Best Regards,
LaBird (Benny).