Re: [Question] Could the max code size check be optional?

This is a multi-part message in MIME format...

------------=_1616005634-16935-20
Content-Type: multipart/alternative; boundary="00000000000075a5b205bdbfa105"

--00000000000075a5b205bdbfa105
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>
> It is possible, you would just have to write it yourself - or it could
> perhaps be included in asm-commons. A similar thing already exists
> (AnalyzerAdapter) but I think it only works with bytecode that has updated
> stackframes - I assume if you are not updating the maxLocals and maxStack
> you are also not updating frames.


Thanks x4e.

Yes, you're correct I'm not creating/updating the frames. I'm creating java
bytecode from scratch.

If your pipeline has some optimizer in the middle, perhaps you can
> write your generated bytecode into a MethodNode first, then run your
> optimizer over a MethodNode and only then send it to the MethodWriter
>

Thanks Eugene.

Yes, this is the case. However, my optimization requires a MethodNode which
has its max local/stack and stack map frames computed. Basically, because
I'm using a SourceInterpreter to compute SourceValues:

Analyzer<SourceValue> analyzer =3D new Analyzer<>(new SourceInterpreter());
>

I've noticed that in order to execute, it requires the MethodNode to have
at least the max local/stack correctly set. That's why I tried to work
around it by calling the MethodWriter in the middle.

Cheers,
Manuel.

El mi=C3=A9, 17 mar 2021 a las 14:53, Eugene Kuleshov (<[email protected]=
>)
escribi=C3=B3:

> Manuel,
>
>   If your pipeline has some optimizer in the middle, perhaps you can
> write your generated bytecode into a MethodNode first, then run your
> optimizer over a MethodNode and only then send it to the MethodWriter
>
>   regards,
>   Eugene
>
>
> On Wed, Mar 17, 2021 at 7:10 AM Manuel Carrasco <[email protected]> wrote:
> >
> > 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. 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.
> >
> >
> > --
> > 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=3Dhelp
> > OW2 mailing lists service home page: http://www.ow2.org/wws
>

--00000000000075a5b205bdbfa105
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It is po=
ssible, you would just have to write it yourself - or it could=20
perhaps be included in asm-commons. A similar thing already exists=20
(AnalyzerAdapter) but I think it only works with bytecode that has=20
updated stackframes - I assume if you are not updating the maxLocals and
 maxStack you are also not updating frames. </blockquote><div><br></div><di=
v>Thanks x4e. <br></div><div><br></div><div>Yes, you&#39;re correct I&#39;m=
 not creating/updating the frames. I&#39;m creating java bytecode from scra=
tch.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
<div>If your pipeline has some optimizer in the middle, perhaps you can<br>
write your generated bytecode into a MethodNode first, then run your<br>
optimizer over a MethodNode and only then send it to the MethodWriter</div>=
</blockquote><div><br></div><div>Thanks Eugene.</div><div><br></div><div>Ye=
s, this is the case. However, my optimization requires a MethodNode which h=
as its max local/stack and stack map frames computed. Basically, because I&=
#39;m using a SourceInterpreter to compute SourceValues:<br></div><div><br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><div><span><span cl=
ass=3D"gmail-line" id=3D"gmail-LC28" lang=3D"java"><span class=3D"gmail-nc"=
>Analyzer</span><span class=3D"gmail-o">&lt;</span><span class=3D"gmail-nc"=
>SourceValue</span><span class=3D"gmail-o">&gt;</span> <span class=3D"gmail=
-n">analyzer</span> <span class=3D"gmail-o">=3D</span> <span class=3D"gmail=
-k">new</span> <span class=3D"gmail-nc">Analyzer</span><span class=3D"gmail=
-o">&lt;&gt;(</span><span class=3D"gmail-k">new</span> <span class=3D"gmail=
-nc">SourceInterpreter</span><span class=3D"gmail-o">());</span></span></sp=
an></div></blockquote><div><br></div><div>I&#39;ve noticed that in order to=
 execute, it requires the MethodNode to have at least the max local/stack c=
orrectly set. That&#39;s why I tried to work around it by calling the Metho=
dWriter in the middle.<br></div><div><br></div><div>Cheers,<br></div><div>M=
anuel.<br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">El mi=C3=A9, 17 mar 2021 a las 14:53, Eugene Kuleshov (&lt;=
<a href=3D"mailto:[email protected]">[email protected]</a>&gt;) escribi=
=C3=B3:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Manuel,<=
br>
<br>
=C2=A0 If your pipeline has some optimizer in the middle, perhaps you can<b=
r>
write your generated bytecode into a MethodNode first, then run your<br>
optimizer over a MethodNode and only then send it to the MethodWriter<br>
<br>
=C2=A0 regards,<br>
=C2=A0 Eugene<br>
<br>
<br>
On Wed, Mar 17, 2021 at 7:10 AM Manuel Carrasco &lt;<a href=3D"mailto:asm@o=
w2.org" target=3D"_blank">[email protected]</a>&gt; wrote:<br>
&gt;<br>
&gt; Hi,<br>
&gt;<br>
&gt; How are you?<br>
&gt;<br>
&gt; I noticed that the MethodWriter currently (184aaa9f0ec4c233872087a3c4d=
2d96a3c204ac6) throws an exception when the method size exceeds the maximum=
 allowed by the JVM. The intent is clear to me, the library wants to emit J=
ava bytecode that is legal in terms of the specification. My question is, c=
ould we make this check optional and true by default?<br>
&gt;<br>
&gt; 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 fr=
ames available. So, you execute the ClassWriter to compute them, but it wil=
l crash as soon the MethodWriter verifies the maximum code size.<br>
&gt;<br>
&gt; The current implementation is limiting user optimizations on their cod=
e in case it has already exceeded the maximum limit. At least, it is not al=
lowing them to compute the max stack and local as well as the map stack fra=
mes.<br>
&gt;<br>
&gt; I tested commenting the check and emitting the code. It didn&#39;t cra=
sh, and I could optimize it, so it can be executed by the JVM.<br>
&gt;<br>
&gt; Considering all this, I&#39;d like to know if you consider reasonable =
to make the max code size check optional. Perhaps, I&#39;m missing some oth=
er technical reason that could make this impossible.<br>
&gt;<br>
&gt; Thanks in advance!<br>
&gt;<br>
&gt; Cheers,<br>
&gt; Manuel.<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; You receive this message as a subscriber of the <a href=3D"mailto:asm@=
ow2.org" target=3D"_blank">[email protected]</a> mailing list.<br>
&gt; To unsubscribe: mailto:<a href=3D"mailto:[email protected]" targ=
et=3D"_blank">[email protected]</a><br>
&gt; For general help: mailto:<a href=3D"mailto:[email protected]" target=3D"_b=
lank">[email protected]</a>?subject=3Dhelp<br>
&gt; OW2 mailing lists service home page: <a href=3D"http://www.ow2.org/wws=
" rel=3D"noreferrer" target=3D"_blank">http://www.ow2.org/wws</a><br>
</blockquote></div>

--00000000000075a5b205bdbfa105--

------------=_1616005634-16935-20
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

------------=_1616005634-16935-20--