The `writeFrames` method in StackMapDecoder makes lots of allocations. For N stack map entries, it can make up to a maximum of approximately 1 + N + N log2(N) allocations due to its use of TreeMap, along with Integer boxing. This is more than needed.

If an array is used instead, then we need one allocation for the array, the toArray overhead, and one allocation for a comparator to sort with. Then we loop over the resultant array to write the entries themselves. Overall complexity is not significantly greater than the existing code.

Additionally, validation was missing for the case where multiple stack map entries were existent for a given bytecode index. We can fix that easily as a side effect of this improvement.

Care would be taken to avoid using method handles which would make this all even simpler (using streams etc.).