RFR: 8261731: shallow copy the internal buffer of a scalar-replaced java.lang.String object [v7]

Xin Liu xliu at openjdk.java.net
Thu Mar 18 09:11:08 UTC 2021


> There are 3 nodes involving in the construction of a java.lang.String object.
> 1. Allocate of itself, aka. alloc
> 2. AllocateArray of a byte array, which is value:byte[], aka. aa
> 3. ArrayCopyNode which copys in the contents of value, aka. ac
> 
> Lemma
> When a String object `alloc` is scalar replaced, C2 can eliminate `aa` and `ac`.
> 
> Because `alloc` is scalar replaced, it must be non-escaped. The field value:byte[] of j.l.String cannot be seen by external world, therefore it must not be global escaped. Because the buffer is marked as stable, it is safe to assume its contents are whatever ac copies in. Because all public java.lang.String constructors clone the incoming array, the source of `ac` is stable as well.
> 
> It is possible to rewire `aa` to the source of ac with the correct offset. That is to say, we can replace both `aa` and `ac` with a “shallow copy” of the source of `ac`. It’s safe if C2 keeps a reference of the source oop for all safepoints.

Xin Liu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 45 commits:

 - Merge branch 'master' into optimize_substring
 - eliminate AllocateArray node early.
   
   This patch eliminates AllocateArray in process_users_of_string_allocation(),
   so can_eliminate_allocation() and scalar_replacement() don't need any code change.
   
   Because OptimizeTempArray assumes that the string object must be scalar replaced,
   we don't need to generate ObjectValue for AllocateArray. all safepoints must be
   intercepted at string object's scalar_replacement.
 - Handle more StrIntrinsic nodes which use AllocateArray of String.
   
   There are a few subclasses of StrIntrinsicNode. They may be users of
   j.l.String::value, eg StrEqualsNode and StrCompNode etc. This patch
   treats them as general nodes.
   
   This patch fixes TestOptimizeSubstring.java failure with -Xcomp.
   The test methods were not properly inlined or pruned in presence of -Xcomp.
   This patch provides more fine-grained control to make sure those methods are compiled more reliablely.
 - [SIM-JVM-526] fix a crash in scalar replacement
   
   Even though field_val is the value field of j.l.String, the code shape has be changed
   by StringOpt for the more efficient string concatenantion. The array is generated from
   jdk.internal.misc.Unsafe::allocateUninitializedArray instead of AllocateArray node.
   
   This patch checks stricter before genenerating the special SafePointScalarObjectNode node.
   
   This bug is triggered in the following 2 tests with '-ea -esa -XX:CompileThreshold=100':
   compiler/codecache/stress/RandomAllocationTest.java
   compiler/codecache/stress/UnexpectedDeoptimizationTest.java
 - fix a typo introduced in prior change.
   
   This fixes the crashing case reported on github's PR.
 - [SIM-JVM-522] improve second AddP nodes and ArrayCopy node.
   
   It is possible that an AddP node which only has second AddP Nodes as uses.
   In this case, we cannot eliminate its uses. replace its base and address
   with the source of ac.
   
   It is possible that there is a ArrayCopy but res is not its source.
   treat it as a CallStaticJavaNode.
 - [SIM-JVM-509] Check the source of ArrayCopy is from java.lang.String::value.
   
   before we figure out how to determine the byte array is stable, we only accept j.l.String::value
   for the time being because the field is annotated stable.
 - Merge branch 'master' into optimize_substring
 - Merge branch 'master' into optimize_substring
 - Merge branch 'master' into optimize_substring
 - ... and 35 more: https://git.openjdk.java.net/jdk/compare/2b93ae00...800ddc9d

-------------

Changes: https://git.openjdk.java.net/jdk/pull/2570/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2570&range=06
  Stats: 889 lines in 15 files changed: 879 ins; 2 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2570.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2570/head:pull/2570

PR: https://git.openjdk.java.net/jdk/pull/2570


More information about the hotspot-compiler-dev mailing list