Будет ли JIT оптимизировать новые объекты

Question

Я создал этот класс для того неизменны и имеющий свободно API:

public final class Message { 
    public final String email; 
    public final String escalationEmail; 
    public final String assignee; 
    public final String conversationId; 
    public final String subject; 
    public final String userId; 

    public Message(String email, String escalationEmail, String assignee, String conversationId, String subject, String userId) { 
     this.email = email; 
     this.escalationEmail = escalationEmail; 
     this.assignee = assignee; 
     this.conversationId = conversationId; 
     this.subject = subject; 
     this.userId = userId; 
    } 

    public Message() { 
     email = ""; 
     escalationEmail = ""; 
     assignee = ""; 
     conversationId = ""; 
     subject = ""; 
     userId = ""; 
    } 

    public Message email(String e) { return new Message(e, escalationEmail, assignee, conversationId, subject, userId); } 
    public Message escalationEmail(String e) { return new Message(email, e, assignee, conversationId, subject, userId); } 
    public Message assignee(String a) { return new Message(email, escalationEmail, a, conversationId, subject, userId); } 
    public Message conversationId(String c) { return new Message(email, escalationEmail, assignee, c, subject, userId); } 
    public Message subject(String s) { return new Message(email, escalationEmail, assignee, conversationId, s, userId); } 
    public Message userId(String u) { return new Message(email, escalationEmail, assignee, conversationId, subject, u); } 

} 

Мой вопрос, будет ли оптимизатор сможет избежать многих объектов творений, когда создается новый объект например:

Message m = new Message() 
    .email("foo@bar.com") 
    .assignee("bar@bax.com") 
    .subject("subj"); 

Есть ли что-нибудь, что можно получить от создания отдельного объекта изменяемого объекта-строителя?

Обновление 2: После прочтения ответа apangin мой критерий признан недействительным. Я буду держать его здесь для справки о том, как не для сравнения :)

Update: я взял на себя смелость измерения это сам с этим кодом:

public final class Message { 
public final String email; 
public final String escalationEmail; 
public final String assignee; 
public final String conversationId; 
public final String subject; 
public final String userId; 

public static final class MessageBuilder { 
    private String email; 
    private String escalationEmail; 
    private String assignee; 
    private String conversationId; 
    private String subject; 
    private String userId; 

    MessageBuilder email(String e) { email = e; return this; } 
    MessageBuilder escalationEmail(String e) { escalationEmail = e; return this; } 
    MessageBuilder assignee(String e) { assignee = e; return this; } 
    MessageBuilder conversationId(String e) { conversationId = e; return this; } 
    MessageBuilder subject(String e) { subject = e; return this; } 
    MessageBuilder userId(String e) { userId = e; return this; } 

    public Message create() { 
     return new Message(email, escalationEmail, assignee, conversationId, subject, userId); 
    } 

} 

public static MessageBuilder createNew() { 
    return new MessageBuilder(); 
} 

public Message(String email, String escalationEmail, String assignee, String conversationId, String subject, String userId) { 
    this.email = email; 
    this.escalationEmail = escalationEmail; 
    this.assignee = assignee; 
    this.conversationId = conversationId; 
    this.subject = subject; 
    this.userId = userId; 
} 

public Message() { 
    email = ""; 
    escalationEmail = ""; 
    assignee = ""; 
    conversationId = ""; 
    subject = ""; 
    userId = ""; 
} 

public Message email(String e) { return new Message(e, escalationEmail, assignee, conversationId, subject, userId); } 
public Message escalationEmail(String e) { return new Message(email, e, assignee, conversationId, subject, userId); } 
public Message assignee(String a) { return new Message(email, escalationEmail, a, conversationId, subject, userId); } 
public Message conversationId(String c) { return new Message(email, escalationEmail, assignee, c, subject, userId); } 
public Message subject(String s) { return new Message(email, escalationEmail, assignee, conversationId, s, userId); } 
public Message userId(String u) { return new Message(email, escalationEmail, assignee, conversationId, subject, u); } 


static String getString() { 
    return new String("hello"); 
    // return "hello"; 
} 

public static void main(String[] args) { 
    int n = 1000000000; 

    long before1 = System.nanoTime(); 

    for (int i = 0; i < n; ++i) { 
     Message m = new Message() 
       .email(getString()) 
       .assignee(getString()) 
       .conversationId(getString()) 
       .escalationEmail(getString()) 
       .subject(getString()) 
       .userId(getString()); 
    } 

    long after1 = System.nanoTime(); 

    long before2 = System.nanoTime(); 

    for (int i = 0; i < n; ++i) { 
     Message m = Message.createNew() 
       .email(getString()) 
       .assignee(getString()) 
       .conversationId(getString()) 
       .escalationEmail(getString()) 
       .subject(getString()) 
       .userId(getString()) 
       .create(); 
    } 

    long after2 = System.nanoTime(); 



    System.out.println("no builder : " + (after1 - before1)/1000000000.0); 
    System.out.println("with builder: " + (after2 - before2)/1000000000.0); 
} 


} 

я нашел разницу быть значительным (строитель быстрее), если строковые аргументы не являются новыми объектами, но все равно (см. комментарий в getString)

В том, что я себе представляю, более реалистичный сценарий, когда все строки являются новыми объектами, разница пренебрежимо мало, и запуск JVM приведет к тому, что первый быть немного медленнее (я пробовал в обоих направлениях).

С «новой строкой» код был в целом много раз медленнее (мне пришлось уменьшить n), возможно, указывая на то, что происходит некоторая оптимизация «нового сообщения», но не от " новая строка ".

Answer 1

Да, HotSpot JIT может устранить избыточные распределения в местном контексте.

Эта оптимизация обеспечивается с помощью Escape Analysis с JDK 6u23. Его часто путают с распределением по стеклу, но на самом деле он намного более мощный, поскольку он позволяет не только выделять объекты в стеке, но и полностью исключать выделение путем замены полей объектов переменными (Scalar Replacement), которые подлежат дальнейшему оптимизаций.

Оптимизация контролируется опцией JVM -XX:+EliminateAllocations, которая по умолчанию включена.

---

Благодаря оптимизации элиминации распределения, как ваши примеры эффективного создания Message объекта работы на один и тот же путь. Они не выделяют промежуточные объекты; просто последний.

Ваш тест показывает ошибочные результаты, потому что он собирает много common pitfalls из microbenchmarking:

• он включает в себя несколько тестов в одном методе;
• он измеряет OSR stub вместо окончательной скомпилированной версии;
• он не делает разминки;
• не потребляет результатов и т.д.

Замерим правильно с JMH. В качестве бонуса JMH имеет профилировщик распределения (-prof gc), который показывает, сколько байтов действительно выделено за итерацию. Я добавил третий тест, который работает с отключенной оптимизацией EliminateAllocations, чтобы показать разницу.

package bench; 

import org.openjdk.jmh.annotations.*; 

@State(Scope.Benchmark) 
public class MessageBench { 

    @Benchmark 
    public Message builder() { 
     return Message.createNew() 
       .email(getString()) 
       .assignee(getString()) 
       .conversationId(getString()) 
       .escalationEmail(getString()) 
       .subject(getString()) 
       .userId(getString()) 
       .create(); 
    } 

    @Benchmark 
    public Message immutable() { 
     return new Message() 
       .email(getString()) 
       .assignee(getString()) 
       .conversationId(getString()) 
       .escalationEmail(getString()) 
       .subject(getString()) 
       .userId(getString()); 
    } 

    @Benchmark 
    @Fork(jvmArgs = "-XX:-EliminateAllocations") 
    public Message immutableNoOpt() { 
     return new Message() 
       .email(getString()) 
       .assignee(getString()) 
       .conversationId(getString()) 
       .escalationEmail(getString()) 
       .subject(getString()) 
       .userId(getString()); 
    } 

    private String getString() { 
     return "hello"; 
    } 
} 

Вот результаты. Оба builder и immutable выполняют одинаково и выделяют всего 40 байт на итерацию (точно размер одного объекта Message).

Benchmark          Mode Cnt  Score  Error Units 
MessageBench.builder        avgt 10  6,232 ± 0,111 ns/op 
MessageBench.immutable       avgt 10  6,213 ± 0,087 ns/op 
MessageBench.immutableNoOpt      avgt 10 41,660 ± 2,466 ns/op 

MessageBench.builder:·gc.alloc.rate.norm   avgt 10 40,000 ± 0,001 B/op 
MessageBench.immutable:·gc.alloc.rate.norm  avgt 10 40,000 ± 0,001 B/op 
MessageBench.immutableNoOpt:·gc.alloc.rate.norm avgt 10 280,000 ± 0,001 B/op 

Answer 2

Я понимаю, что JIT компилятор работает перестановка существующего кода и выполнение основного статистического анализа. Я не думаю, что JIT-компилятор может оптимизировать распределение объектов.

Ваш Строитель неверен, и ваш свободный API не будет работать так, как вы ожидаете (создайте только один объект на каждый построенный).

Вы должны иметь что-то вроде:

public class Message() { 
    public final String email; 
    public final String escalationEmail; 

    private Message (String email,String escalationEmail) { 
    this.email = email; 
    this. escalationEmail = escalationEmail; 
    } 

    public static class Builder { 
     public String email; 
     public String escalationEmail; 

     public static Builder createNew() { 
      return new Builder(); 
     } 

     public Builder withEmail(String email) { 
      this.email = email; 
      return this; 
     } 

     public Builder withEscalation(String escalation) { 
      this.escalation = escalation; 
      return this; 
     } 

     public Builder validate() { 
      if (this.email==null|| this.email.length<7) { 
      throw new RuntimeException("invalid email"); 
      } 
     } 


     public Message build() {¨ 
     return new Message(this.email,this.escalation); 
     } 

    } 

} 

Тогда вы можете иметь что-то подобное.

Message.Builder.createNew() 
          .withEmail("exampple@email.com") 
          .withEscalation("escalation") 
       .validate() 
       .build(); 

Answer 3

В строитель шаблон, вы должны сделать так:

Message msg = Message.new() 
.email("foo@bar.com") 
.assignee("bar@bax.com") 
.subject("subj").build(); 

Какой Message.new() создаст объект класса строитель, функция email(..) и assignee(...) вернется this. И последняя функция build() создаст объект на основе ваших данных.

Answer 4

будет оптимизатор сможет избежать многих создания объекта

Нет, но Инстанциация очень дешевая операция на JVM. Беспокойство об этой потере производительности будет типичным примером преждевременной оптимизации.

Есть ли что-нибудь, что можно получить от создания отдельного объекта изменчивого строителя?

Работа с неизменяемыми обычно является хорошим подходом. С другой стороны, строители также не повредят вам, если вы используете экземпляры компоновщика в небольшом контексте, поэтому их изменяемое состояние доступно только в небольшом локальном окружении. Я не вижу серьезных недостатков на любой стороне, это действительно зависит от ваших предпочтений.

Answer 5

Во-первых, ваш код не имеет подхода к построению и генерирует много объектов, но уже есть пример построителя, поэтому я не буду добавлять еще один.

Затем, относительно JIT, короткий ответ НЕТ (нет оптимизации создания нового объекта, кроме мертвого кода) ... длинный ответ нет, но ... есть другой механизм, который будет оптимизировать материал в JVM/

Существует пул строк, который позволяет избежать создания нескольких строк при использовании строковых литералов. Существует также пул объектов для каждого примитивного типа обертки (поэтому, если вы создаете объект Long с Long.valueOf, это тот же объект, который возвращается каждый раз, когда вы просите о том же длинном ...). Что касается строк, есть также механизм дедупликации строк, встроенный в сборщик g1 garbadge в обновлении java 8 20. Вы можете протестировать его со следующими параметрами JVM, если вы используете недавнюю JVM: -XX: + UseG1GC -XX: + UseStringDeduplication

Если вы действительно хотите оптимизировать создание нового объекта, вам нужно реализовать какой-то пул объектов, и ваш объект будет неизменным. Но будьте осторожны, что это не простая задача, и вы получите много кода, связанного с созданием объекта и управляющим размером пула, чтобы не переполнять вашу память. Поэтому я советую вам сделать это, только если это действительно необходимо.

Наконец, экземпляр объекта в куче является дешевой операцией, если вы не создаете миллионы объектов за секунду, а JVM делает много оптимизаций во многих полях, поэтому, если какой-либо хороший тест производительности (или профилирование памяти) доказать, что у вас есть проблема с объектом конкретизации не думать об этом слишком много;)

с уважением,

Лоик