dmcl-applications startup time

On last week I was trying to setup DEV ENV on VM and have noticed a very odd behavior of iapi/idql/dmawk/dmbasic commands – their start takes about 5(!) seconds:

~$] time iapi -X -Sapi </dev/null
Running with non-standard init level: api
API> Bye

real    0m4.595s
user    0m4.385s
sys     0m0.124s

Does not look like a good startup time for application which does nothing, does it? Actually, you may say that slow start is a common issue of all java applications, but if my memory serves me right, in Documentum 5.3 tomcat (JMS) startup took about 1 second and that was a tomcat – the whole web container, not a console application which does nothing. After some manipulations with boot classpath (see also: https://weblogs.java.net/blog/enicholas/archive/2008/04/java_secrets_re.html, http://docs.oracle.com/javase/7/docs/technotes/guides/vm/class-data-sharing.html, http://www.oracle.com/technetwork/jp/ondemand/java/20110519-java-a-1-greg-400531-ja.pdf and http://hg.openjdk.java.net/jdk6/jdk6/jdk/file/ca2c9f498b70/make/tools/src/build/tools/) I was able to cut iapi startup time down to 1.5 sec:

~]$ time iapi -X -Sapi </dev/null
Running with non-standard init level: api
API> Bye

real    0m1.477s
user    0m1.373s
sys     0m0.077s

Unfortunately, it seems that DFC is not capable to be resided in boot classpath because EMC developers like to use following pattern in DFC:

getClass().getClassLoader().getResourceAsStream(bla-bla-bla)

and this pattern does not work for classes from boot classpath:

    /**
     * Returns the class loader for the class.  Some implementations may use
     * null to represent the bootstrap class loader. This method will return
     * null in such implementations if this class was loaded by the bootstrap
     * class loader.
     *
     * <p> If a security manager is present, and the caller's class loader is
     * not null and the caller's class loader is not the same as or an ancestor of
     * the class loader for the class whose class loader is requested, then
     * this method calls the security manager's <code>checkPermission</code> 
     * method with a <code>RuntimePermission("getClassLoader")</code> 
     * permission to ensure it's ok to access the class loader for the class.
     * 
     * <p>If this object
     * represents a primitive type or void, null is returned.
     *
     * @return  the class loader that loaded the class or interface
     *          represented by this object.
     * @throws SecurityException
     *    if a security manager exists and its 
     *    <code>checkPermission</code> method denies
     *    access to the class loader for the class.
     * @see java.lang.ClassLoader
     * @see SecurityManager#checkPermission
     * @see java.lang.RuntimePermission
     */
    public ClassLoader getClassLoader() {
        ClassLoader cl = getClassLoader0();
        if (cl == null)
            return null;
        SecurityManager sm = System.getSecurityManager();
        if (sm != null) {
            ClassLoader ccl = ClassLoader.getCallerClassLoader();
            if (ccl != null && ccl != cl && !cl.isAncestor(ccl)) {
                sm.checkPermission(SecurityConstants.GET_CLASSLOADER_PERMISSION);
            }
        }
        return cl;
    }

2 thoughts on “dmcl-applications startup time

  1. Pingback: Q & A. VI | Documentum in a (nuts)HELL
  2. Pingback: Wrong JDK | Documentum in a (nuts)HELL

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s