Синхронизированный блок занимает больше времени после работы с ASM

Question

Я пытаюсь использовать синхронизированный блок java с использованием ASM. Проблема в том, что после инструментария время выполнения синхронизированного блока занимает больше времени. Здесь он увеличивается с 2 мсек до 200 мсек в ящике Linux.

Я реализую это, идентифицируя код операции MonitorEnter и MonitorExit.

Я пытаюсь использовать инструмент на трех уровнях 1. непосредственно перед MonitorEnter 2. после MonitorEnter 3. Перед MonitorExit. 1 и 3 вместе работают нормально, но когда я делаю 2, время выполнения резко возрастает.

Даже если мы применяем еще одну инструкцию SOP, которая предназначена для выполнения только один раз, она дает более высокие значения. Вот пример кода (простое число, 10 петель):

for(int w=0;w<10;w++){ 
synchronized(s){ 
    long t1 = System.currentTimeMillis(); 
    long num = 2000; 
for (long i = 1; i < num; i++) { 
     long p = i; 
    int j; 
    for (j = 2; j < p; j++) { 
      long n = p % i; 
     } 
    } 
long t2 = System.currentTimeMillis(); 
System.out.println("Time>>>>>>>>>>>> " + (t2-t1)); 
} 

Вот код для instrumention (здесь System.currentMilliSeconds() дает время, при котором произошло instrumention, его не в меру времени выполнения, то excecution время от obove заявления СОП):

public void visitInsn(int opcode) 
    { 
     switch(opcode) 
     { 
      // Scenario 1 
     case 194: 
      visitFieldInsn(Opcodes.GETSTATIC, "java/lang/System", "out", "Ljava/io /PrintStream;"); 
      visitLdcInsn("TIME Arrive: "+System.currentTimeMillis()); 
      visitMethodInsn(Opcodes.INVOKEVIRTUAL, "java/io/PrintStream", "println", "(Ljava/lang/String;)V"); 
      break; 

     // scenario 3 
     case 195: 
      visitFieldInsn(Opcodes.GETSTATIC, "java/lang/System", "out", "Ljava/io/PrintStream;"); 
      visitLdcInsn("TIME exit : "+System.currentTimeMillis()); 
      visitMethodInsn(Opcodes.INVOKEVIRTUAL, "java/io/PrintStream", "println", "(Ljava/lang/String;)V"); 
      break; 
     } 

     super.visitInsn(opcode); 

     // scenario 2 
     if(opcode==194) 
     { 
      visitFieldInsn(Opcodes.GETSTATIC, "java/lang/System", "out", "Ljava/io/PrintStream;"); 
      visitLdcInsn("TIME enter: "+System.currentTimeMillis()); 
      visitMethodInsn(Opcodes.INVOKEVIRTUAL, "java/io/PrintStream", "println", "(Ljava/lang/String;)V"); 

     } 

     } 

Я не могу найти причину, почему это происходит и как это исправить т.

Заранее благодарен.

Answer 1

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

Если вы вызываете следующий код:

int result = 0; 
for(int i = 0; i < 1000; i++) { 
    result += i; 
} 

Это будет переведен непосредственно в байт-код Java компилятором Java, но во время выполнения виртуальная машина будет легко увидеть, что этот код ничего не делает. Выполнение этого кода не будет влиять на внешний мир (приложение), так почему JVM его выполняет? Это соображение именно то, что оптимизирует компилятор для вас.

Если вы однако вызвать следующий код:

int result = 0; 
for(int i = 0; i < 1000; i++) { 
    System.out.println(result); 
} 

среда выполнения Java не может оптимизировать код больше. Вся петля должна всегда запускаться, так как метод System.out.println(int) всегда делает что-то real так, что ваш код будет работать медленнее.

Теперь давайте посмотрим на ваш пример. В первом примере вы в основном пишите этот код:

synchronized(s) { 
    // do nothing useful 
} 

Весь этот блок кода можно легко удалить с помощью времени выполнения Java. Это означает: Синхронизация не будет! Во втором примере, вы пишете вместо этого:

synchronized(s) { 
    long t1 = System.currentTimeMillis(); 
    // do nothing useful 
    long t2 = System.currentTimeMillis(); 
    System.out.println("Time>>>>>>>>>>>> " + (t2-t1)); 
} 

Это означает, что эффективный код может быть выглядеть следующим образом:

synchronized(s) { 
    long t1 = System.currentTimeMillis(); 
    long t2 = System.currentTimeMillis(); 
    System.out.println("Time>>>>>>>>>>>> " + (t2-t1)); 
} 

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

Вы должны действительно прочитать:

• http://www.ibm.com/developerworks/java/library/j-jtp02225/
• http://www.ibm.com/developerworks/library/j-jtp12214/

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

На боковой ноте: Синхронизация по String почти всегда плохая идея. Ваши строки могут быть или не быть interned, что означает, что вы не можете быть абсолютно уверены в их личности. Это означает, что синхронизация может работать или не работать, и вы можете даже синхронизировать другие части вашего кода.