implementingc Tweakables

[Roedy Green]

See http://mindprod.com/jgloss/tweakable.html

A static final constant that may be safely varied between limits. The
program still behaves the save way, no matter what the value, but it
may run faster at the optimum setting. Tweakables include such things
as ideal buffer sizes, maximum number of threads to spawn, best
initial sizes for various Hashtables and ArrayLists, how frequently to
invoke the garbage collector and even the size of the virtual heap.
Tweakables can also be discrete variables that for example may select
between one of seven different sorting algorithms.

I envision a time when automated optimisation process will monitor
your program every time it runs in production, automatically adjusting
the tweaking parameters until it gradually learns and homes in on the
optimal settings for running under various conditions.


In the meantime, what would be the best way to go about implementing
them? What sort of syntax would you use?

A simple integer tweakable constant has a min, max and suggested
value. Anyone is at liberty to adjust the suggested value between min
and max.

Some tweakables you need no know the value of at compile time.
Some could be adjusted with sliders on generic control panel at run
time, with persistence.

Ideally some program would try adjusting them and doing experiments.

 

[xarax]

See http://mindprod.com/jgloss/tweakable.html

A static final constant that may be safely varied between limits. The
program still behaves the save way, no matter what the value, but it
may run faster at the optimum setting. Tweakables include such things
as ideal buffer sizes, maximum number of threads to spawn, best
initial sizes for various Hashtables and ArrayLists, how frequently to
invoke the garbage collector and even the size of the virtual heap.
Tweakables can also be discrete variables that for example may select
between one of seven different sorting algorithms.

I envision a time when automated optimisation process will monitor
your program every time it runs in production, automatically adjusting
the tweaking parameters until it gradually learns and homes in on the
optimal settings for running under various conditions.


In the meantime, what would be the best way to go about implementing
them? What sort of syntax would you use?

A simple integer tweakable constant has a min, max and suggested
value. Anyone is at liberty to adjust the suggested value between min
and max.

Some tweakables you need no know the value of at compile time.
Some could be adjusted with sliders on generic control panel at run
time, with persistence.

Ideally some program would try adjusting them and doing experiments.

Just leave off the "final" qualifier. Anything that refers to the
static non-final field will get the current value. Make it volatile
so that it won't get cached by the compiler. Use getter/setter
to hide the field itself for better encapsulation/data-hiding.

Assigning to a final field a simple numeric primitive derived from
a constant expression will cause the compiler to copy that constant,
rather than refer to the field (only when the assignment is part
of the field declaration). If the final field is "blank" (assigned
later by an initializer block or a constructor), then the compiler
won't be able to determine the value at compile time (thus causing
the compiler to generate field references rather than copying the
constant). The value of a final field can be computed by method
calls in the declaration assignment, or later in an initializer
block or (for instance fields) a constructor. The final field
must be definitely assigned only once by the end of all initializer
blocks, or in the case of an instance field, by the end of any
and all constructors.

Thus, a so-called tweakable final field cannot be changed after
its first assignment, but that assignment value can be dynamically
computed by an initializer block and/or method calls.

static fields are initialized after the class is loaded. the class
is loaded by the first reference to the class (reference to a class
member or by instantiating an object of the class). the java lang
spec has the exact procedural details for class loading, verifying,
initializing, multi-threading synchronization, etc. (similar remarks
apply to interfaces.)

If you need to change a static field at run time, then it's not
really a final field. However, when there is no further need for
a class (no more references to the class), the class may be
dynamically unloaded. A subsequent reference for the class will
cause a fresh copy of the class to be loaded, verified, initialized
(thus assigning fresh values for the static final fields). This
behavior can depend on many dynamic conditions, so you shouldn't
rely on the timeliness of class unloading, unless you have a
custom class loader that you can control at runtime.

 

[Doug Pardee]

A static final constant that may be safely varied between limits.

You can't vary a constant.

I'm not just being pedantic here. In Java, if you declare a name to be
"final" and assign a constant expression to it, that name is the name
of a constant and not the name of a variable (JLS 15.28). A variable
is evaluated at run-time; a constant is evaluated at compile-time.
From JLS 13.1:
"References to fields that are final and initialized with
compile-time constant expressions are resolved at compile
time to the constant value that is denoted."
(http://java.sun.com/docs/books/jls/second_edition/html/binaryComp.doc.html#44909)

Every time a client references the value of a constant, that value is
compiled into the *client*. This is not an option for the compiler --
it is required by JLS 13.1 that clients not contain code to access
constant fields in other classes. If a client attempts to access a
constant field at run-time (because the field wasn't constant when the
client was compiled), JLS 13.4.8 requires that IllegalAccessError be
thrown.

If you ever change the value of a constant, you have to locate and
recompile all client classes. From JLS 13.4.8:
"If a field is a compile-time constant, then deleting the
keyword final or changing its value will not break
compatibility with pre-existing binaries by causing them
not to run, but they will not see any new value for the
constant unless they are recompiled...

"The best way to avoid problems with 'inconstant constants'
in widely-distributed code is to declare as compile time
constants only values which truly are unlikely ever to change."
(http://java.sun.com/docs/books/jls/second_edition/html/binaryComp.doc.html#45139)

Note that changes in the values of constants can cause significant
changes in the bytecode that is generated for clients. The most
obvious spots are "case" labels in switches, and conditional
compilation where sections of code are omitted because they cannot be
reached given the values of the constants (JLS 14.20).