implementingc Tweakables

Discussion in 'Java' started by Roedy Green, Jul 4, 2003.

  1. Roedy Green

    Roedy Green Guest

    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.

    --
    Canadian Mind Products, Roedy Green.
    Coaching, problem solving, economical contract programming.
    See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
     
    Roedy Green, Jul 4, 2003
    #1
    1. Advertising

  2. Roedy Green

    xarax Guest

    Roedy Green <> wrote in message news:<>...
    > 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.
     
    xarax, Jul 4, 2003
    #2
    1. Advertising

  3. Roedy Green

    Doug Pardee Guest

    Roedy Green <> wrote:
    > 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).
     
    Doug Pardee, Jul 4, 2003
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.

Share This Page