[8u] RFR: 8143925 : enhancing CounterMode.crypt() for AESCrypt.implEncryptBlock() + 8146581 : Minor corrections to the patch submitted for earlier bug id - 8143925

[Hohensee, Paul]

I'm not a huge fan of making manual changes to get around not having backported patches on which a patch (i.e., this one) depends (whew!). I'd rather see the 8 (!) patches Martin references done first. If we don't, then if we/Oracle ever decide to do any of those backports, it's going to be very confusing. I'd rather have something as close as possible to what was tested in the parent repo. Andrew, what do you think?

Thanks,
Paul

On 1/20/20, 9:35 AM, "jdk8u-dev on behalf of Anton Kozlov" <jdk8u-dev-bounces at openjdk.java.net on behalf of akozlov at azul.com> wrote:

    On 17.01.2020 15:38, Anton Kozlov wrote:
    >>  * src/cpu/x86/vm/stubRoutines_x86_32.hpp
    >>   * 1st hook does not apply cleanly because 8132160 [6] is not in 8u.
    >> Manually applied changes adding 3800 to the current code_size2 value.
    > Oh, great. In my patch, I've confused 8 with 0 and used 3000 here as well. Strange, it should crash right at the start, probably need a debug build. Thanks, I'll make an update.
    
    Fixed, current patches are 
    
      http://cr.openjdk.java.net/~akozlov/8143925/hotspot.01/
      http://cr.openjdk.java.net/~akozlov/8143925/jdk.00/
    
    Difference between hotspot.00 vs hotspot.01 is below.
    
    Thanks,
    Anton
    
    --- a/src/cpu/x86/vm/stubRoutines_x86_32.hpp    Mon Dec 28 23:11:01 2015 -0800
    +++ b/src/cpu/x86/vm/stubRoutines_x86_32.hpp    Mon Dec 28 23:11:01 2015 -0800
    @@ -31,7 +31,7 @@
     
     enum platform_dependent_constants {
       code_size1 =  9000,           // simply increase if too small (assembler will crash if too small)
    -  code_size2 = 25000            // simply increase if too small (assembler will crash if too small)
    +  code_size2 = 25800            // simply increase if too small (assembler will crash if too small)
     };
     
     class x86 {