[Javapathfinder-devel] CVS commit digest and policy

[Peter C. M. <pcm...@em...>]

I've added an entry to the CVSROOT/loginfo, to henceforth post commit 
messages to this list (so that people can see what's going on before 
the stuff eventually shows up in the anonymous repository).

When we commit, we should append a line "related bugs" that refers to 
corresponding entries in the bug tracking system.

Since there was no prior notification, I append a short digest of my 
major commits during the last days

-- Peter


------------------------------------------------ 05/04
superficially, this is a simplistic java.lang.Class.newInstance() 
implementation (we don't treat
exceptions yet).

But in reality it is the ability to call back into JPF executed code 
from native methods. This is not a full
circle yet, since the called JPF method will be executed atomically 
(i.e. is not allowed to block). This
can be worked around at some point by adding a sythetic frame to call 
the desired method (something
we already do for static inits during VM initialization), but that's 
not supported yet. But the main
infrastructure for this  (mostly the different return value and next pc 
handling by means of a call type
StackFrame attribute) is now in place.

The main motivation for this is to ease on-the-fly instrumentation in 
the future

related bugs: 1195640

------------------------------------------------ 05/02
* fixed problem with recursive class init (StaticArea.newClass), which 
also answered
the long standing question why there ever were life object overwrites 
accepted
(indeed that was a hack enabling recursive class init - sort of). Now 
the innermost
recursion proceeds with static class init, while the outer ones 
re-check before they
ever create/init a class object

* re-introduced UncaughtException usage. Indeed we need this to handle 
the
notorious 'ArrayIndexOutOfBounds' problem that was nothing but an 
unhandled
exception in a clinit (i.e. automatically executed code with an 
'artificial'
stackframe) that just didn't have the right provisions to check for 
failure
(no central place to check for null pc's - could be called from 
anywhere). This
also required slight changes to DFSearch, since we have to check for 
failed
properties no matter what when we return from forward (not just for new 
states)
The other searches already did this anyway.

maybe we should also do this for backtracks

related bugs: 1191665 (closing)

------------------------------------------------- 04/30
Java 1.5 LDC_W workaround

With Java 1.5, Sun silently introduced a classfile change - LDC_W can
now directly reference CLASS constpool entries. Unfortunately, BCEL 5.1 
chokes on it with a
hard exception. It's fixed in BCELs Subversion repository since Aug 
2004, but they don't
have a new release out yet. The mods I did (close to a hack) should 
compile with both BCELs,
but of course only run - when encountering a Java 1.5 classfile - with 
BCEL > 5.1 (e.g. from
their source repository). Good thing I built the runtime library 
snapshot from BCELs source
repository, so that should work.

Don't know yet if this fixes all Java 1.5 problems

The fix needs to be updated when a new BCEL version comes out 
(Types.CLASS)

related bugs: 1191462 (part)

--------------------------------------------------  04/29
fixed problem with extra-native method use of MJIEnv, mostly
by pulling heap and static area out of the MJIEnv call environment
(it's invariant).

Still the use of MJIEnv outside native methods is dangerous, since
you have to make sure you don't rely on the call environment, but
as long as we don't have MJIEnv refactored (which doesn't make much
sense otherwise), this seems to be the lesser of evils

related bugs: 1191644 (closing)