Duplicate compilation attempt when code is too large

[Alex Meiburg]

Thanks. I was unsure if I should ask for a bug id if I'm just submitted a
patch right off the bat, since there's not much to be "tracked".

I split it up into two patches: I cut out the whole CodeSizeOverflow class
in the former. In the latter there is now a second method available to
which you can pass a PrintStream, and the earlier method defaults to syserr.

-- Alexander Meiburg


2014-08-18 12:54 GMT-07:00 Jonathan Gibbons <jonathan.gibbons at oracle.com>:

>
> On 08/03/2014 09:52 AM, Alex Meiburg wrote:
>
>> Hi,
>>
>> This is my first time posting to this list, and I'm not sure of the right
>> protocol -- I've got the following patch to submit. When jsr/ret were in
>> use, if a method ran over the 64k code limit, it would try compilation
>> again with more aggressive space optimization. Since jsr/ret aren't used
>> any more, this just means that it takes twice as long to report the error
>> to the user.
>>
>> There's also some (unused) code in dump() that was printing to sysout
>> where it should have been printing to syserr.
>>
>> I have the patch attached, how/where do I submit it? Please excuse my
>> ignorance, I couldn't find the answer. Thanks!
>>
>> -- Alexander Meiburg
>>
>
> I looked at the suggestion for Gen.    The code has been partially cleaned
> up in this area, such that the catch block is now dead code. So there isn't
> an "efficiency" argument to be made here, but I agree that cleaning up the
> dead code (and the dead exception which appears to no longer be thrown)
> would be a good idea.
>
> I looked at the suggestion for Code, and the inconsistent use of
> System.out and System.err.  I think a good fix here would be to declare a
> single local variable to specify the stream to which all the printing in
> that method should be done.
>
> -- Jon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140818/6e3422d9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2565_gen_overflow.patch
Type: application/octet-stream
Size: 1745 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140818/6e3422d9/2565_gen_overflow-0001.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2566_code_dump.patch
Type: application/octet-stream
Size: 3182 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140818/6e3422d9/2566_code_dump-0001.patch>