NullPointerException during VM initialization with instrumented rt.jar

[Lee]

Hello! I apologize for my ignorance, but I'm having some trouble
getting things working. I am using the following test case:


package deucetest;
import java.util.HashMap;

import org.deuce.Atomic;
import org.deuce.transaction.AbortTransactionException;

public class DeuceTest
{
private static class Test
{
private int i;
}

private int i;
private Test test = new Test();
private HashMap<String,Integer> map = new HashMap<String,Integer>();

@Atomic
private void testPrimitive()
{
i = 2;
throw new AbortTransactionException();
}

@Atomic
private void testUserClass()
{
test.i = 4;
throw new AbortTransactionException();
}

@Atomic
private void testRtClass()
{
map.put( "test", 6 );
throw new AbortTransactionException();
}

public DeuceTest()
{
System.out.print( "Primitive type... " );
i = 1;
try
{
testPrimitive();
}
catch( AbortTransactionException ex )
{
System.out.print( "transaction aborted- " );
}
if( i == 1 )
System.out.println( "Passed!" );
else
System.out.println( "Failed! "+i );

System.out.print( "User type... " );
test.i = 3;
try
{
testUserClass();
}
catch( AbortTransactionException ex )
{
System.out.print( "transaction aborted- " );
}
if( test.i == 3 )
System.out.println( "Passed!" );
else
System.out.println( "Failed! "+test.i );

System.out.print( "Built-in type... " );
map.put( "test", 5 );
try
{
testRtClass();
}
catch( AbortTransactionException ex )
{
System.out.print( "transaction aborted- " );
}
if( map.get("test") == 5 )
System.out.println( "Passed!" );
else
System.out.println( "Failed! "+map.get("test") );
}

public static void main( String[] args )
{
new DeuceTest();
}
}


I then instrument rt.jar like so:
java -jar deuceAgent-1.3.0.jar sun-1.6.0.24/rt.jar rt-java-6-
sun-1.6.0.24-deuce.jar

And then run the test like so:
java -Xbootclasspath/p:rt-java-6-sun-1.6.0.24-deuce.jar -
javaagent:deuceAgent-1.3.0.jar deucetest/DeuceTest

Which produces the following:
Primitive type... transaction aborted- Passed!
User type... transaction aborted- Passed!
Built-in type... transaction aborted- Failed! 6


Then I thought to myself, "Yaknow, Self, maybe HashMap isn't getting
instrumented." So I tried:
java -Dorg.deuce.exclude="" -jar deuceAgent-1.3.0.jar sun-1.6.0.24/
rt.jar rt-java-6-sun-1.6.0.24-deuce.jar

When I try to run the test with the same commandline as above, with
the newly instrumented rt.jar with nothing excluded, it produces:
Error occurred during initialization of VM
java.lang.NullPointerException
at java.util.Hashtable.put(Hashtable.java:394)
at java.lang.System.initProperties(Native Method)
at java.lang.System.initializeSystemClass(System.java:1070)

What am I doing wrong here?

Thanks!

[Guy Korland]

Since in your test you work with HashMap, can you try to exclude the HashTable from the instrumentation?

On Sat, Jun 11, 2011 at 2:55 PM, Lee <blad...@gmail.com> wrote:

       at java.util.Hashtable.put(Hashtable.java:394)

[Lee]

Let's see....

java -Dorg.deuce.verbose=true -
Dorg.deuce.exclude="java.util.Hashtable,java.lang.System,java.lang.Object"
-jar deuceAgent-1.3.0.jar rt-original.jar rt.jar

java -Xbootclasspath/p:rt.jar -Dorg.deuce.verbose=true -
javaagent:deuceAgent-1.3.0.jar -cp bin/ deucetest/DeuceTest

Error occurred during initialization of VM
java.lang.NullPointerException
at java.util.Hashtable.put(Hashtable.java:394)
at java.lang.System.initProperties(Native Method)
at java.lang.System.initializeSystemClass(System.java:1070)

The test is being compiled by Eclipse, if that matters.

The problem domain that I'm hoping to use Deuce for involves running
semi-trusted code server-side via rhino and/or a securitymanager. In
addition to gaining all the concurrency benefits of STM, I hope to be
able to roll back the application state if these semi-trusted scripts
throw unexpected exceptions and such. Therefore, if instrumenting the
runtime libraries is too problematic, I suppose I /could/ require that
these bits of semi-trusted code only use special collection and
utility classes that get loaded by something other than the boot
classloader... But that seems like kind of a roundabout and less
robust way of doing things, and would limit the amount of preexisting
code that could be used within the application. :3