<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi David,<div><br></div><div>I appreciate the response, I've found that there's a problem somewhere within C1 and C2, and that disabling them has the JVM attain more typical startup CPU usage values, though at the cost of performance as the Interpreter has to support execution of Java code all by itself. Thanks for the advice though! I'll keep working to ensure this works somehow</div><div><br></div><div>best regards,</div><div>Julian</div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 23, 2023 at 8:13 PM David Holmes <<a href="mailto:david.holmes@oracle.com">david.holmes@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 23/06/2023 8:21 pm, Julian Waters wrote:<br>
> Hi all,<br>
> <br>
> Anyone who has seen JDK-8288293 <br>
> (<a href="https://bugs.openjdk.org/browse/JDK-8288293" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8288293</a> <br>
> <<a href="https://bugs.openjdk.org/browse/JDK-8288293" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8288293</a>>) might probably be <br>
> intrigued to learn that gcc has been able to compile a complete, <br>
> somewhat functioning Windows JDK for somewhat over a month by this <br>
> point. There is an unfortunate catch: The experimental HotSpot produced <br>
> by gcc in this manner is extremely volatile and unstable, often suddenly <br>
> spiking CPU usage to 100% and devouring system resources at completely <br>
> random moments, causing the entire system (not just the Java process <br>
> itself, per se) to freeze as a result of the immense strain suddenly <br>
> placed on it<br>
> <br>
> The question I have is: How do HotSpot developers debug and profile <br>
> HotSpot in cases where bugs or performance hits like this occur? I don't <br>
> have much experience working with HotSpot as of yet, so I don't quite <br>
> know where to start in tackling this issue. Any tips on what to do in <br>
> dealing with this performance issue would be greatly appreciated!<br>
<br>
I can't say I have any specific advice for this situation. You have <br>
basically used a "new" compiler to build a Windows JDK and it doesn't <br>
work. That is not a situation we normally need to debug.<br>
<br>
About the only advice I could give would be to disable all optimisations <br>
in the compiler and see how that goes.<br>
<br>
Sorry.<br>
<br>
David<br>
<br>
<br>
> best regards,<br>
> Julian<br>
</blockquote></div>