Recently (during 3.4 development) we noticed the
startup time beying affected by different modules
trying to do more and more work during boot time.
This is not by itself wrong, but we need to have a
way to find out that some module did such change
and evaluate and review it. That is why I propose:
1. During first startup (part of regular build)
run the VM with -verbose:class flag and capture
the list of generated files to a file.
2. Compare the content of that file with a
golden-file to be sure that no not new module
class is loaded during the startup.
3. If a class or bunch of classes is detected to
be unexpectedly loaded, complain heavilly so the
regular process can send warning emails to
This is an infrastructure need to make work done during issue 21676
Do you mean part of each developer's local regular build
or as a part of the daily/continuous build?
It should be quite easy on UNIX building machines using standard
unix text tools, it have to be implemented in java otherwise.
There is a little problem with -verbose:class and that is it sometimes
mangle the output with other texts, but the impact should be minimal
(<5 wrong items per run)
What kind of golden file you mean? One big for stable module
configuration or a per module (not that easy). Who will manage
the golden files? (They would have to be updated quite frequently).
Shouldn't it rather be part of tests run instead of firststart
(I'd rather measure second start anyway ;-)
>It should be quite easy on UNIX building machines using
> unix text tools, it have to be implemented in java
I think it should be platform independ - so use java it
IMHO best solution...
> What kind of golden file you mean? One big for stable
> configuration or a per module (not that easy). Who will
> the golden files? (They would have to be updated quite
It could be stored in CVS somewhere in nbbuild module - I
don't see any problem with it.
Is anybody working on it? I don't like to have P1 in my
Nobody is working on this enhancement. IMO I'm not sure this belongs
to nbbuild module.
It is assigned to Petr and it is still a high priority.
Probably the component could be changed to 'performance'.
Reassigning to component performance.
Ruda don't forget to change QA Contact when changing Component...
Might be implemented for JDK1.5 and newer using
java.lang.management.ClassLoadingMXBean. Just need to enhance our startup tests
Created attachment 29714 [details]
original patch idea
We could use management API like in the attachment.
Anyway it is currently part of our footprint tests - count of loaded and
unloaded classes is reported here.
The beauty of this would show if this test was part of commit validation.
Otherwise it is just a postmortem tool.
Re commit-validation: think about current dependency on junit/xtest that can be
probably avoided but also the dependency on particular version of JDK where
updates can have impact and every platform has its L&F implementation that
introduces another difference. Different logging, Xverify, perhaps graphics
accelaration flag can influence results too.
That said I think we want postmortem regression tests now.