3 ms·

The JVM knows what string concatenation does.

by chrisseaton 5y ago

envp 5y ago
But what if one of the arguments is a function call? Then it isn't easy to prove there are no side effects
- chrisseaton 5y ago
  If it’s too big to in-line then yes.
  - vlovich123 5y ago
    That’s says absolutely nothing about whether the function has a side effect.
    - chrisseaton 5y ago
      If you can inline it into the compilation unit, then you can see if it has side effects or not.
      - deleted 5y ago
        [deleted]
alserio 5y ago
Isn't the point that you don't generally stuff your log of things that are only strings but of things that can become strings? (Asking since I know of your work with truffle)
- chrisseaton 5y ago
  I assumed things like the names of resources that are already strings because you’re using them in the actual program?
  - alserio 5y ago
    A typical logger.info("user {} did the thing", user) can skip the actual string interpolation and user value stringification, if the log level is not > info. However, logger.info("user " + user + " did the thing") cannot avoid at least the execution of user.toString(), even after jit optimizations, unless the jit could prove that toString does not have side effects. But I don't believe the jvm jit tries to do that. Am I wrong?
    - chrisseaton 5y ago
      If user is a string, then #toString() is a trivial method, will inline, and become a no-op.
      - alserio 5y ago
        However, if user happened be an user-defined User object it would be hard to guarantee that it could be inlined
        chrisseaton 5y ago
        Yes
christophilus 5y ago
`"hello" + myFooObject.toString()` Can you eliminate that? It's impossible to say without knowing whether or not `myFooObject.toString()` is effectful. Maybe the JVM can make that assessment. Maybe not. I don't know, but it's not as trivial as "knowing what string concatenation does".
- deleted 5y ago
  [deleted]
- deleted 5y ago
  [deleted]
- sour-taste 5y ago
  A straightforward way to do this is for Java to assume built in types like strings are side effect free, but custom types may not be. This would likely cover a good portion of log lines but not all, obviously.
unclebucknasty 5y ago
The noop determination is made during runtime within the log method called. So, it's LOG.info(obj.toString()), wherein that method inspects the log level setting, then decides whether to ignore. Are you saying that Java does or should "optimize" in such a way that it branches to the logic within each method called during runtime, inspects which code would be executed per possibly mutable runtime values (like log level), considers possible side effects (in-method and in parameters) then decides whether to even invoke the method at all?

The JVM knows what string concatenation does.

envp 5y ago

But what if one of the arguments is a function call? Then it isn't easy to prove there are no side effects

chrisseaton 5y ago
If it’s too big to in-line then yes.
- vlovich123 5y ago
  That’s says absolutely nothing about whether the function has a side effect.
  - chrisseaton 5y ago
    If you can inline it into the compilation unit, then you can see if it has side effects or not.
    - deleted 5y ago
      [deleted]

alserio 5y ago

Isn't the point that you don't generally stuff your log of things that are only strings but of things that can become strings? (Asking since I know of your work with truffle)

chrisseaton 5y ago
I assumed things like the names of resources that are already strings because you’re using them in the actual program?
- alserio 5y ago
  A typical logger.info("user {} did the thing", user) can skip the actual string interpolation and user value stringification, if the log level is not > info. However, logger.info("user " + user + " did the thing") cannot avoid at least the execution of user.toString(), even after jit optimizations, unless the jit could prove that toString does not have side effects. But I don't believe the jvm jit tries to do that. Am I wrong?
  - chrisseaton 5y ago
    If user is a string, then #toString() is a trivial method, will inline, and become a no-op.
    - alserio 5y ago
      However, if user happened be an user-defined User object it would be hard to guarantee that it could be inlined
      - chrisseaton 5y ago
        Yes

christophilus 5y ago

`"hello" + myFooObject.toString()` Can you eliminate that? It's impossible to say without knowing whether or not `myFooObject.toString()` is effectful. Maybe the JVM can make that assessment. Maybe not. I don't know, but it's not as trivial as "knowing what string concatenation does".

deleted 5y ago
[deleted]
deleted 5y ago
[deleted]
sour-taste 5y ago
A straightforward way to do this is for Java to assume built in types like strings are side effect free, but custom types may not be. This would likely cover a good portion of log lines but not all, obviously.

unclebucknasty 5y ago

The noop determination is made during runtime within the log method called. So, it's LOG.info(obj.toString()), wherein that method inspects the log level setting, then decides whether to ignore. Are you saying that Java does or should "optimize" in such a way that it branches to the logic within each method called during runtime, inspects which code would be executed per possibly mutable runtime values (like log level), considers possible side effects (in-method and in parameters) then decides whether to even invoke the method at all?