Jump to content
Excelsior Forums
tanelorn

Multiple Compilation Sets and Usage Statistics

Recommended Posts

Hi,

While compiling an application as a set of DLLs (using multiple compilation sets), does the !module myproject.usg directive, when included in each .prj file, have an impact on compilation?

Or is this only used by the "main" (EXE) compilation set?

On a related note: I tried to compile a sub-project where all jars have the -protect=nomatter flag. It also includes an .usg file referencing some classes of those jars. The compilation then fails with a "no classes to compile" (or similar) message. Is this to be expected?

Best regards.

Share this post


Link to post
Share on other sites

Usage (.usg) files are mainly intended to be used with Global Optimizer: they contain classes and members that were used during Trial Run with a special information on their usage and the later is used only by Global Optimizer.

Without Global Optimizer enabled, only information about referenced classes are used from .usg files. So .usg files mainly complete your project in this mode, if not all classes from the classpath was explicitly added to the project (so .usg inclusion has impact on compilation in such case). 

However there should be at least one class that is explicitly added to the compilation set to let .usg files to take any effect. If you compile EXE, the main class is always such explicitly added class. For DLL, if you set -optimize=autodetect and -protect=nomatter, then the compiler does not know from which class it should start optimizing and hence issues "no classes to compile" error. You may explicitly add a class to the compilation set in such case using the

!module YourClass.class

directive.

Share this post


Link to post
Share on other sites

Usage (.usg) files are mainly intended to be used with Global Optimizer: they contain classes and members that were used during Trial Run with a special information on their usage and the later is used only by Global Optimizer.

OK. So, since global optimization cannot safely be used with multiple compilation sets, the trial run is not so useful in this case.

Without Global Optimizer enabled, only information about referenced classes are used from .usg files. So .usg files mainly complete your project in this mode, if not all classes from the classpath was explicitly added to the project (so .usg inclusion has impact on compilation in such case).

From a .prj point of view, what does "explicitly added" mean? Is it its inclusion using a !classpathentry directive?

However there should be at least one class that is explicitly added to the compilation set to let .usg files to take any effect. If you compile EXE, the main class is always such explicitly added class. For DLL, if you set -optimize=autodetect and -protect=nomatter, then the compiler does not know from which class it should start optimizing and hence issues "no classes to compile" error. You may explicitly add a class to the compilation set in such case using the

!module YourClass.class

directive.

Now, that is very interesting. It means I can finely tune the set of classes actually compiled to native code, which mean I will be able to limit the size of my DLLs to actually needed code.

So you answered my next question before I asked it, basically  :D

Best regards.

Share this post


Link to post
Share on other sites
From a .prj point of view, what does "explicitly added" mean? Is it its inclusion using a !classpathentry directive?

Explicitly added means:

1. !classpathentry, if either -protect or -optimize equations set to "all" for it

2. !module YourJar.jar, except both -protect and -optimize equations are not set to "all" globally .

3. !module YourClass.class

4. !batch *.class YourPackage

5. -main=YourClass

Now, that is very interesting. It means I can finely tune the set of classes actually compiled to native code, which mean I will be able to limit the size of my DLLs to actually needed code.

Yes. Note however, that once you add a class to the compilation set, all its import is also automatically added. So in general, you add an import closure of the class with it. To get a complete freedom with defining of the compilation set, use

-superimportonly+

secret option. With this option, the compiler will automatically add only superclasses and superinterfaces of explicitly added class.

Share this post


Link to post
Share on other sites

Explicitly added means:

1. !classpathentry, if either -protect or -optimize equations set to "all" for it

2. !module YourJar.jar, except both -protect and -optimize equations are not set to "all" globally .

3. !module YourClass.class

4. !batch *.class YourPackage

5. -main=YourClass

Nicely detailed. Thanks.

To get a complete freedom with defining of the compilation set, use

-superimportonly+

secret option. With this option, the compiler will automatically add only superclasses and superinterfaces of explicitly added class.

OK. That's some kind of equivalent to -Djet.jit.disable.resolution, but for AOT compilation, then?

Best regards.

Share this post


Link to post
Share on other sites
That's some kind of equivalent to -Djet.jit.disable.resolution, but for AOT compilation, then?

Yes, exactly.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×