[Question] Could the max code size check be optional?
"Manuel Carrasco" (via asm Mailing List) <[email protected]> Wed, 17 Mar 2021 11:09:59 +0000
| Newsgroups | gmane.comp.java.objectweb.asm |
|---|---|
| Message-ID | <CA+_2aJ-7+V3JSxz0RG+qByC+ct+HpyUEtpsSoH5_7-oFAmwabA@mail.gmail.com> |
This is a multi-part message in MIME format... ------------=_1615979416-16935-9 Content-Type: multipart/alternative; boundary="000000000000bbbee605bdb986e3" --000000000000bbbee605bdb986e3 Content-Type: text/plain; charset="UTF-8" Hi, How are you? I noticed that the MethodWriter currently (184aaa9f0ec4c233872087a3c4d2d96a3c204ac6) throws an exception when the method size exceeds the maximum allowed by the JVM <https://gitlab.ow2.org/asm/asm/-/blob/master/asm/src/main/java/org/objectweb/asm/MethodWriter.java#L2086>. The intent is clear to me, the library wants to emit Java bytecode that is legal in terms of the specification. My question is, could we make this check optional and true by default? In case that you want to perform an optimization to shrink your code, you may require to have the max stack and local as well as the stack map frames available. So, you execute the ClassWriter to compute them, but it will crash as soon the MethodWriter verifies the maximum code size. The current implementation is limiting user optimizations on their code in case it has already exceeded the maximum limit. At least, it is not allowing them to compute the max stack and local as well as the map stack frames. I tested commenting the check and emitting the code. It didn't crash, and I could optimize it, so it can be executed by the JVM. Considering all this, I'd like to know if you consider reasonable to make the max code size check optional. Perhaps, I'm missing some other technical reason that could make this impossible. Thanks in advance! Cheers, Manuel. --000000000000bbbee605bdb986e3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Hi,</div><div><br></div><div>How are you?<br></div><d= iv><br></div><div>I noticed that the MethodWriter currently (184aaa9f0ec4c2= 33872087a3c4d2d96a3c204ac6) throws an exception when <a href=3D"https://git= lab.ow2.org/asm/asm/-/blob/master/asm/src/main/java/org/objectweb/asm/Metho= dWriter.java#L2086">the method size exceeds the maximum allowed by the JVM<= /a>. The intent is clear to me, the library wants to emit Java bytecode tha= t is legal in terms of the specification. My question is, could we make thi= s check optional and true by default?<br></div><div><br></div><div>In case = that you want to perform an optimization to shrink your code, you may requi= re to have the max stack and local as well as the stack map frames availabl= e. So, you execute the ClassWriter to compute them, but it will crash as so= on the MethodWriter verifies the maximum code size.=C2=A0 <br></div><div><b= r></div><div>The current implementation is limiting user optimizations on t= heir code in case it has already exceeded the maximum limit. At least, it i= s not allowing them to compute the max stack and local as well as the map s= tack frames.<br></div><div><br></div><div>I tested commenting the check and= emitting the code. It didn't crash, and I could optimize it, so it can= be executed by the JVM.</div><div><br></div><div>Considering all this, I&#= 39;d like to know if you consider reasonable to make the max code size chec= k optional. Perhaps, I'm missing some other technical reason that could= make this impossible. <br></div><div><br></div><div>Thanks in advance!</di= v><div><br></div><div>Cheers,<br></div><div>Manuel.<br></div><div><br></div= ></div> --000000000000bbbee605bdb986e3-- ------------=_1615979416-16935-9 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit -- You receive this message as a subscriber of the [email protected] mailing list. To unsubscribe: mailto:[email protected] For general help: mailto:[email protected]?subject=help OW2 mailing lists service home page: http://www.ow2.org/wws ------------=_1615979416-16935-9--