Fixing Java tools on Snow Leopard

Posted on October 21, 2009 by Brian Pontarelli

I was attempting to work with VisualVM and Tomcat over the past few days on Snow Leopard and it was constantly failing. I was getting errors like this:

    "attach: task_for_pid(59980) failed (5)"

I was also getting errors inside VisualVM and from the command like using jmap that went like this:

Attaching to process ID 61218, please wait...
sun.jvm.hotspot.debugger.NoSuchSymbolException: Could not find symbol "heapOopSize" in any of the known library names (-)
	at sun.jvm.hotspot.HotSpotTypeDataBase.lookupInProcess(HotSpotTypeDataBase.java:399)
	at sun.jvm.hotspot.HotSpotTypeDataBase.readVMIntConstants(HotSpotTypeDataBase.java:319)
	at sun.jvm.hotspot.HotSpotTypeDataBase.<init>(HotSpotTypeDataBase.java:88)
	at sun.jvm.hotspot.MacOSXTypeDataBase.<init>(MacOSXTypeDataBase.java:36)
	at sun.jvm.hotspot.bugspot.BugSpotAgent.setupVM(BugSpotAgent.java:578)
	at sun.jvm.hotspot.bugspot.BugSpotAgent.go(BugSpotAgent.java:499)
	at sun.jvm.hotspot.bugspot.BugSpotAgent.attach(BugSpotAgent.java:337)
	at sun.jvm.hotspot.tools.Tool.start(Tool.java:163)
	at sun.jvm.hotspot.tools.HeapDumper.main(HeapDumper.java:77)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at sun.tools.jmap.JMap.runTool(JMap.java:179)
	at sun.tools.jmap.JMap.main(JMap.java:110)
Debugger attached successfully.
sun.jvm.hotspot.tools.HeapDumper requires a java VM process/core!

And I also got some other strange errors from jmap like this one:

61218: Unable to open socket file: target process not responding or HotSpot VM not loaded
The -F option can be used when the target process is not responding

I opened an issue with the VisualVM team and they tested things out on Snow Leopard and said it all worked fine. I figured they were smokin’ something and decided to try a Sun product and see if it worked. I fired up NetBeans and sure enough, VisualVM and jmap worked great. This indicated it was definitely a VM configuration issue.

Here’s the what you need to do to get your Java applications working with the VM tools on Snow Leopard. Add the following parameters to the java command and everything will start working fine:

java -Xverify:none -Xshare:off -Xcom.sun.management.jmxremote

The -Xverify:none is the setting that allows VisualVM and jmap to capture thread dumps. Without this setting, you’ll get strange errors like those above. The -Xshare:off gets VisualVM working without any startup errors or random failures. The last setting is really just for JConsole and other JMX tools.

Enjoy!

Posted in Java, OS X, Testing | Tagged , , , , , | 1 Comment

C++ references

Posted on August 6, 2009 by Brian Pontarelli

Assigning reference return value to a variable

When assigning a reference return value to a variable, a copy is made. Here is an example:

class References {
private:
    std::string name;

public:
    References(const std::string& name) : name(name) {
    };

    virtual ~References() {
    };

    const std::string& getName() const {
        return name;
    };
};

References r("foo");
std::string n = r.getName();

This code makes a copy of the name member variable from the References class and puts the copy into the variable n.

Assigning reference return value to a reference variable

When assigning a reference return value to a reference variable, no copy is made. Here is an example:

class References {
private:
    std::string name;

public:
    References(const std::string& name) : name(name) {
    };

    virtual ~References() {
    };

    const std::string& getName() const {
        return name;
    };
};

References r("foo");
const std::string& n = r.getName();

This code does not make a copy of the name member variable. Instead, the reference variable is now a reference directly to the member variable inside the class.

Passing a reference return value to a method that takes a reference

When you pass the return value from a method that returns a reference directly into a method that takes a reference, no copy is made. Here is an example:

class References {
private:
    std::string name;

public:
    References(const std::string& name) : name(name) {
    };

    virtual ~References() {
    };

    const std::string& getName() const {
        return name;
    };
};

void print(const std::string& s) {
    ...;
}

References r("foo");
print(r.getName());

This passes the reference returned directly into the method as a reference. Therefore, no copy is made.

Using a reference method in a comparison operator

This is the same as the method invocation example above because all operators take references.

Posted in C++ | Tagged , | Leave a comment

Fixing macbook wake up problems

Posted on March 24, 2009 by Brian Pontarelli

One of the family Apple notebooks (a Macbook) was having some issues waking up from sleep periodically. It was also having issues when the lid was closed the fan would constantly spin as though the machine was overheating. I took the machine into the only Apple store I trust (the main tech there is pretty solid, although he still doesn’t use Terminal). The fix was pretty simple:

  1. Open up Terminal (Google it if you’ve never done it)
  2. Type in ‘cd /var/vm’
  3. Type in ‘rm sleepimage’

It looks like this:

$ cd /var/vm
$ rm sleepimage

This should fix any issues with sleeping and waking up. The root cause is that if you move the machine to fast, have any static electricity and shock the machine, or otherwise jostle it too much when it is going into sleep mode (just after you close the lid), the sleep image will become corrupt and you’ll start having issues.

Posted in OS X | Tagged | 2 Comments

Generic variable to the current type

Posted on March 6, 2009 by Brian Pontarelli

I just noticed that I’ve been using the Builder pattern with method chaining a lot. Looks like this:

FooBuilder builder = new FooBuilder();
Foo foo = builder.add(...).divide(...).multiple(...).builder();

The issue that arises is that I want to store a bunch of methods in a base class that various builders can use. In order to do this correctly, I have to really hack up my classes with some strange generics and unchecked casts like this:

public class BaseBuilder<T extends BaseBuilder> {
  public T add(...) {
    ...
    return (T) this;
  }
  public T divide(...) {
    ...
    return (T) this;
  }
  public T multiply(...) {
    ...
    return (T) this;
  }
}

public class FooBuilder extends BaseBuilder<FooBuilder> {
  public Foo build() {
    ...
  }
}

This is really annoying. I think every class should have a generic type variable that references the current type and let the compiler figure it out. Just name the variable ME or something. It would make the code look like this instead:

public class BaseBuilder{
  public ME add(...) {
    ...
    return this;
  }
  public ME divide(...) {
    ...
    return this;
  }
  public ME multiply(...) {
    ...
    return this;
  }
}

public class FooBuilder extends BaseBuilder{
  public Foo build() {
    ...
  }
}

Now that’s much nicer looking.

Posted in Java | 6 Comments

Inferred typing

Posted on March 6, 2009 by Brian Pontarelli

I know that .Net 4 is going to have some pretty cool features around dynamic typing and C++0x is also adding some auto typing features. I was thinking about all of this today and realized that what I really use most of the time is an inferred type. Essentially it would infer a new type based on the method’s contents.

Let’s say we have this:

public void callSomeMethod(Object obj) {
  obj.methodCall();
}

In static languages this fails because Object doesn’t contain the method methodCall. However, what if we told the compiler to create a new interface based on the content of the method? This code would then look like this:

public void callSomeMethod(autotype obj) {
  obj.methodCall();
}

The autotype keyword would cause the compiler to actually create this code:

public interface MethodCallInterface {
  void methodCall();
}

public void callSomeMethod(MethodCallInterface obj) {
  obj.methodCall();
}

This would now compile. Next, a caller to this method could pass in any object whose type the compiler could add this interface to. If you called it like this:

public class MyClass {
  public void methodCall() {
    System.out.println("Here I am");
  }
}

// Some other code somewhere
MyClass mc = new MyClass();
callSomeMethod(mc);

The compiler could take the interface it created for this method call and then see if the type passed in could implement that interface. If MyClass has already been compiled, it could do one of two things:

  • If MyClass is accesible as part of the current compilation unit, it could update the compiled Class to implement the interface
  • If it isn’t part of the current compilation unit and isn’t final, it could create a proxy for the call that implements the interface and delegates the call

Not sure yet how #2 really works or if it even makes sense to do it that way, but it seems to be the only way to make it work if the Class is in a JAR or DLL or something like that.

The only issue would be reflection. How could you reflection on the method and then pass an Object to it so that it would not completely blow chunks at runtime? Perhaps the reflective method invocation could determine if the object being passed could be proxied to the dynamic interface and then create a proxy on the fly.

Anyways, just pondering type systems in general today….

Posted in .Net, C++, Java | Leave a comment