Fix contention due to lzycompute synchronised access in Metadata.normalize

[jurisk]

Our performance traces show that Metadata.normalize uses a lazy val which leads to lzycompute synchronised access and lock contention.

scala.xml.MetaData$.key$lzycompute$1(NamespaceBinding, MetaData, ObjectRef, VolatileByteRef)	4,954	120,519,787,655
   scala.xml.MetaData$.key$1(NamespaceBinding, MetaData, ObjectRef, VolatileByteRef)	4,954	120,519,787,655
      scala.xml.MetaData$.iterate$1(MetaData, MetaData, Set, NamespaceBinding)	4,954	120,519,787,655
         scala.xml.MetaData$.iterate$1(MetaData, MetaData, Set, NamespaceBinding)	3,028	73,017,044,016
         scala.xml.MetaData$.normalize(MetaData, NamespaceBinding)	1,926	47,502,743,639
            scala.xml.Elem.<init>(String, String, MetaData, NamespaceBinding, boolean, Seq)	1,926	47,502,743,639
               scala.xml.Elem$.apply(String, String, MetaData, NamespaceBinding, boolean, Seq)	1,387	33,803,514,665

Replacing it with a def should resolve this, which this PR does.

[SethTisue]

(I don't know this code, but:) is getUniversalKey expensive? because now we might be computing it twice.

[t3hnar]

@SethTisue true, so would be nice to have the code as close as possible to original but without synchronisation introduced by lazy val

[ashawley]

Maybe just break up the conditional logic so that it can be a val?

      if (md eq Null) normalized_attribs
      else if (md.value eq null) iterate(md.next, normalized_attribs, set)
      else {
        val key = getUniversalKey(md, scope)
        if (set(key)) iterate(md.next, normalized_attribs, set)
        else md copy iterate(md.next, normalized_attribs, set + key)
      }

[jurisk]

@SethTisue Good point.
@ashawley It's done as you've suggested.

[ashawley]

Closed with 7ad0adc after rebase

[ashawley]

Thanks for reporting this and for submitting the fix. With any luck, this will be released in 1.0.7 relatively soon.