<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
P4 is the default JBS priority, so sometimes it just means no one
figured out the true priority.<br>
But in general P4 bugs could be open for years, or even never get
fixed.<br>
The priority is also partially an assessment of where it falls as a
priority for the JDK developers.<br>
A user of JDK may have an entirely different perspective.<br>
And that's why there are vendors who provide support for JDK. They
can also arrange the backports you need.<br>
But that's not done here. Here is where you come to participate and
contribute fixes, not ask for fixes.<br>
So my suggestion is to raise it via your support channel to your
particular vendor who provided your binary.<br>
<br>
-phil<br>
<br>
<br>
<div class="moz-cite-prefix">On 5/21/24 8:46 PM,
<a class="moz-txt-link-abbreviated" href="mailto:mark.yagnatinsky@barclays.com">mark.yagnatinsky@barclays.com</a> wrote:<br>
</div>
<blockquote type="cite" cite="mid:CH3PR12MB76197D4ECC54728844CE705CF9EB2@CH3PR12MB7619.namprd12.prod.outlook.com">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style>@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-ligatures:standardcontextual;}a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}span.EmailStyle18
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
font-family:"Calibri",sans-serif;
mso-ligatures:none;}div.WordSection1
{page:WordSection1;}</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal">(Sorry about my previous “do I need to
subscribe?” email; in retrospect that was needless noise.)<o:p></o:p></p>
<p class="MsoNormal">The purpose of this email is twofold:
first, inquire about the status of ticket filed a few years
ago, and second to point out some non-obvious reasons why it
might be slightly more serious than it seems.<o:p></o:p></p>
<p class="MsoNormal">The ticket is this one <a href="https://bugs.openjdk.org/browse/JDK-8260866" moz-do-not-send="true" class="moz-txt-link-freetext">
https://bugs.openjdk.org/browse/JDK-8260866</a> (stack
overflow in regex matching quantified alternation)<o:p></o:p></p>
<p class="MsoNormal">The priority is listed as P4, which I guess
means something like “medium” (more important than p5, but
less than p3)<o:p></o:p></p>
<p class="MsoNormal">It also has a specific person assigned,
which seems vaguely encouraging, but no updates at all in the
years since it’s been created, which seems less encouraging.<o:p></o:p></p>
<p class="MsoNormal">It was seemingly never once discussed on
this mailing list, not even when it was first filed.<o:p></o:p></p>
<p class="MsoNormal">As an outsider, I’m not quite sure how to
interpret all these various omens and turn them into guesses
about its eventual fate.<o:p></o:p></p>
<p class="MsoNormal">Will it remain unfixed for another decade
or two? Will it be fixed in a few months, but then never
backported to old versions? Something else? No one knows?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">That concludes the status inquiry. Now on
to the advocacy. Some bugs are annoying, but once you hit
them, you can work around them by changing your code so it
does not trigger the bug.<o:p></o:p></p>
<p class="MsoNormal">Note the phrase “your code” above. This is
much more awkward to do if the bug triggered by third-party
code you got from maven central or something.<o:p></o:p></p>
<p class="MsoNormal">At that point your options are to either
ask the third party library to work around it, or else fork
the dependency (which is not well supported by mainstream
build tools (or maybe I’m just using them wrong)).<o:p></o:p></p>
<p class="MsoNormal">In this case, regular expressions are so
ubiquitous that the bug is quite plausibly more likely to be
triggered by some third party dependency than by code you own.<o:p></o:p></p>
<p class="MsoNormal">That was the case for me today: after
spending hours trying to track down a stack overflow error I
found the offending regex in a third party library.<o:p></o:p></p>
<p class="MsoNormal">The good news is that for the kinds of
inputs we need to handle, it is indeed easy to substitute a
much simpler regex that would avoid the issue.<o:p></o:p></p>
<p class="MsoNormal">The bad news is that it’s not my code, so I
can’t. I could petition the maintainers of the library, but
this is not great because:<o:p></o:p></p>
<p class="MsoNormal">First, maybe the version I’m on is not
longer even supported, and newer versions are not compatible,<o:p></o:p></p>
<p class="MsoNormal">Second, it may take them a while to fix it,
and third, it is wasteful (and inelegant) to have workarounds
slowly percolate throughout the Java ecosystem instead of
fixing the problem at the root.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The other annoying thing here is that even
when you have “enough” stack space to avoid crashing, using it
may not be quite “free”.<o:p></o:p></p>
<p class="MsoNormal">For instance, project loom’s foundational
premise seems to be that “most threads have oversized stacks;
we can have more threads if we start off with small stacks and
grow them only when needed”.<o:p></o:p></p>
<p class="MsoNormal">This would be false when the thread in
question uses a regex with quantified alternation.<o:p></o:p></p>
<p class="MsoNormal">(Since many Loom threads will be based on
the same Runnable, it’s a pretty safe bet that if one of them
uses this feature, many will, so you can’t assume it will
“average out”.)<o:p></o:p></p>
<p class="MsoNormal">There are other reasons besides loom to be
low on stack space; maybe you’re using some crazy framework(s)
that like(s) to have call stacks that are crazy deep.<o:p></o:p></p>
<p class="MsoNormal">Or maybe you’re running with -Xss set
pretty low. Or you passed a small value for stack space to
the Thread constructor.<o:p></o:p></p>
<p class="MsoNormal">Or maybe none of these things are true, but
in most operating systems a thread stack costs “real” memory
in proportion to its high-watermark, so even a SINGLE heavy
regex in the lifetime of a thread is tantamount to a memory
leak of hundreds of kilobytes.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Practicalities aside, I don’t like it when
code consumes “surprising” types of resources, or surprising
amounts of them.<o:p></o:p></p>
<p class="MsoNormal">For instance, you wouldn’t expect a sorting
function to spawn threads behind your back, unless it was
called “parallel sort” or something like that.<o:p></o:p></p>
<p class="MsoNormal">You wouldn’t expect it to allocate
multi-gigabyte arrays, nor to perform I/O.<o:p></o:p></p>
<p class="MsoNormal">Similarly, most functions need only O(1)
stack space, so this tends to be the default assumption unless
the docs explicitly call out “this thing might throw stack
overflows at you so make sure you have plenty of stack space”<o:p></o:p></p>
<p class="MsoNormal">Some need a bit more… for instance, I would
not be surprised if a regex need stack space in proportion to
the depth of the parse tree of the regex.<o:p></o:p></p>
<p class="MsoNormal">But stack space in proportion to the length
of the string being matched is the kind of thing that I’d hope
gets called out in those @implNotes thingies, or better yet
fixed.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Even people who know that regex matching
can sometimes take exponential time may naively assume that
regex matching would not consume O(n) stack space, where n is
the input length.<o:p></o:p></p>
<p class="MsoNormal">What’s worse, not only does it indeed
consume stack space linear in the length of the input, but the
constant hidden by the O() notation is itself pretty scary.<o:p></o:p></p>
<p class="MsoNormal">For instance, consider the regex that
caused my troubles today:<o:p></o:p></p>
<p class="MsoNormal"><a href="https://github.com/apache/camel/blob/main/core/camel-support/src/main/java/org/apache/camel/support/ObjectHelper.java#L63" moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/apache/camel/blob/main/core/camel-support/src/main/java/org/apache/camel/support/ObjectHelper.java#L63</a><o:p></o:p></p>
<p class="MsoNormal">After getting rid of extra escaping and
also double-escaping caused by java not having “raw” strings,
we’re left with this:<o:p></o:p></p>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Courier New";color:#067D17;background:#EDFCED;mso-ligatures:none">,(?!(?:[^(,]|[^)],[^)])+\))</span><span style="font-size:10.0pt;font-family:"Courier New";color:#080808;mso-ligatures:none"><o:p></o:p></span></p>
<p class="MsoNormal">(I find the above hard to read; the regex I
would have replaced it with, if it had been “our” code is
simply a single comma.)<o:p></o:p></p>
<p class="MsoNormal">Anyway, I tried creating a Scanner with the
delimiter above and looping through all the tokens in the
string that originally caused the crash.<o:p></o:p></p>
<p class="MsoNormal">I thought that perhaps it would work, since
I had a simple example that does everything in main, but it
also crashed.<o:p></o:p></p>
<p class="MsoNormal">Then I decided to play an alternating game
where I trimmed the string until it stopped crashing, then
lowered Xss by 64k and repeated.<o:p></o:p></p>
<p class="MsoNormal">Eventually, I got it crashing with a call
stack well over 500 calls deep on a string less than a 128
characters long.<o:p></o:p></p>
<p class="MsoNormal">(The string was not hand-crafted; it was
simply a prefix of the original string that caused the first
crash I tracked down.)<o:p></o:p></p>
<p class="MsoNormal">The string in question had a mere five
tokens, which is to say that it had just four commas.<o:p></o:p></p>
<p class="MsoNormal">It had no open or close parenthesis, so the
entire negative lookahead assertion served as a giant no-op,
at least when it wasn’t crashing.<o:p></o:p></p>
<p class="MsoNormal">(Technically, the stack usage is linear in
the length of the input AFTER the first comma, but the first
comma was pretty early.)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Sorry if this email is poorly organized;
I’ve already spent way too many hours on it (not even counting
the debugging that prompted it) and I need to get some sleep
now.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">If anyone actually reads all or most of
this, thank you.<o:p></o:p></p>
<p class="MsoNormal">Mark.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">P.S. if anyone actually responds, thank you
even more.<o:p></o:p></p>
</div>
<p><span style="mso-ansi-language: EN-US" lang="EN-US">This
message is for information purposes only. It is not a
recommendation, advice, offer or solicitation to buy or sell a
product or service, nor an official confirmation of any
transaction. It is directed at persons who are professionals
and is intended for the recipient(s) only. It is not directed
at retail customers. This message is subject to the terms at:
<a href="https://www.ib.barclays/disclosures/web-and-email-disclaimer.html" moz-do-not-send="true" class="moz-txt-link-freetext">https://www.ib.barclays/disclosures/web-and-email-disclaimer.html</a>.
</span></p>
<p><span style="mso-ansi-language: EN-US" lang="EN-US">For
important disclosures, please see: <a href="https://www.ib.barclays/disclosures/sales-and-trading-disclaimer.html" moz-do-not-send="true" class="moz-txt-link-freetext">https://www.ib.barclays/disclosures/sales-and-trading-disclaimer.html</a>
regarding marketing commentary from Barclays Sales and/or
Trading desks, who are active market participants; <a href="https://www.ib.barclays/disclosures/barclays-global-markets-disclosures.html" moz-do-not-send="true" class="moz-txt-link-freetext">https://www.ib.barclays/disclosures/barclays-global-markets-disclosures.html</a>
regarding our standard terms for Barclays Investment Bank
where we trade with you in principal-to-principal wholesale
markets transactions; and in respect to Barclays Research,
including disclosures relating to specific issuers, see: <a href="http://publicresearch.barclays.com" moz-do-not-send="true" class="moz-txt-link-freetext">http://publicresearch.barclays.com</a>.<br>
__________________________________________________________________________________
<br>
If you are incorporated or operating in Australia, read these
important disclosures: <a href="https://www.ib.barclays/disclosures/important-disclosures-asia-pacific.html" moz-do-not-send="true" class="moz-txt-link-freetext">https://www.ib.barclays/disclosures/important-disclosures-asia-pacific.html</a>.<br>
__________________________________________________________________________________<br>
For more details about how we use personal information, see
our privacy notice: <a href="https://www.ib.barclays/disclosures/personal-information-use.html" moz-do-not-send="true" class="moz-txt-link-freetext">https://www.ib.barclays/disclosures/personal-information-use.html</a>.
<br>
__________________________________________________________________________________<br>
</span></p>
</blockquote>
<br>
</body>
</html>