This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 210706 - @WarmUp
Summary: @WarmUp
Status: RESOLVED WONTFIX
Alias: None
Product: platform
Classification: Unclassified
Component: Module System (show other bugs)
Version: 7.2
Hardware: All All
: P3 normal (vote)
Assignee: Jaroslav Tulach
URL:
Keywords: API, PERFORMANCE
Depends on: 97628
Blocks: 200636
  Show dependency tree
 
Reported: 2012-04-04 14:34 UTC by Jesse Glick
Modified: 2012-05-25 08:35 UTC (History)
2 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2012-04-04 14:34:42 UTC
[Split off from bug #200636 comment #14 JG08.] Currently there are six known warmup task registrations using @ServiceProvider and seven using layer.xml. Some are of dubious value, but it would be good to convert the rest to use a standardized annotation:

@NamedServiceDefinition(path="WarmUp", serviceType=Runnable.class)
@Retention(RetentionPolicy.SOURCE)
@Target(ElementType.TYPE)
public @interface WarmUp {}

Currently the tasks are processed in core.startup but this code is only triggered by GuiRunLevel in o.n.core (i.e. when window system is active) and by ergonomics. Probably the core impl could be replaced by an @OnShowing task. The call from ergonomics might not even be necessary any more given that LayerProvider should guarantee more reliable event timing: the core impl would simply attach a listener to the Lookup.Result<Runnable> and run any new tasks that appear later; or such functionality could just be dropped (OK if features just enabled for the first time are not warmed up).

Still TBD which module the annotation should be in. openide.modules would be one guess, though if the core impl is using @OnShowing and thus in o.n.core the tasks would be ignored when run in a headless module system - not necessarily a problem since there is no guarantee a warmup task is run at all (cf. bug #97628). openide.windows (next to @OnShowing) is also plausible, though some of the current task suppliers might not want this dep (specifically java.j2seplatform, javafx2.platform, mobility.cldcplatform.catalog).
Comment 1 Jaroslav Tulach 2012-05-03 06:53:04 UTC
I'd like to avoid creation of @WarmUp annotation at all. The analysis done by Tomáš Hůrka shows that many usages of that annotation are completely wrong (mobility, JSP, etc.). We don't need to pre-heat JSP unless we know somebody is going to open a JSP editor. In such case, the pre-heating can happen in the JspEditorKit.call() method (if it implements java.util.concurrent.Callable). We don't want to do anything with mobility unless mobility project is opened or created. Again, @WarmUp is not the right place to do such kind of warm up.

According to Tomáš, some of the warmup tasks need to be executed - those would be better with @OnShowing or @OnStart annotation anyway. If there is anything left (and I would guess it is less then five cases), I'd rather stick with less visible @ServicerProvider(path) registration then invent special API for such questionable concept as @WarmUp.

Performance guys may of course, have a different point of view.
Comment 2 Jesse Glick 2012-05-03 16:34:14 UTC
Makes sense. Is there an issue open to actually go through the 13 existing tasks and classify them accordingly?
Comment 3 Jaroslav Tulach 2012-05-25 08:35:36 UTC
Tomáš was driving the process of classifying and cleaning up warm up tasks...