RFR: 8014513: Sjavac doesn't detect 32-bit jvm properly
erik.joelsson at oracle.com
Thu Jun 13 00:42:41 PDT 2013
Would be great if I could get a final ok on this, thanks.
On 2013-06-07 13:08, Erik Joelsson wrote:
> On 2013-06-05 20:40, Jonathan Gibbons wrote:
>> On 06/05/2013 11:38 AM, Jonathan Gibbons wrote:
>>> On 06/05/2013 07:24 AM, Erik Joelsson wrote:
>>>> Here is a small patch fixing a problem with sjavac. Sjavac tries to
>>>> be smart about sizing itself to no run out of memory. The logic for
>>>> figuring out if it's running on a 32 or 64bit jvm is rather crude
>>>> and misses on several platforms. This patch makes the code more
>>>> Fixing this issue is a requirement to get sjavac to work well on
>>>> all platforms in jprt.
>>>> Bug: http://bugs.sun.com/view_bug.do?bug_id=8014513
>>>> Webrev: http://cr.openjdk.java.net/~erikj/8014513/webrev.langtools.01/
>>> It's OK, but I think it would be better if there was a back door to
>>> override the default value. That would also partially address the
>>> comment in the bug about sjavac looking at the wrong JVM -- it's
>>> using the client process, not the server process.
>>> If you push it as is, I suggest you file a followup bug for further
>>> -- Jon
>> The code might also look better if you used a Set<String> for 32 bit
>> values, and tested for set.contains(dataModel), or if not that, the
>> use a strings-in-switch statement.
> Perhaps I'm missing something or I'm not familiar enough with newer
> features in the language, but I can't get initialization of a set of 3
> Strings to feel more readable and less clumsy than the list of logical
> ORs. The problem with going switch is that there are two different
> Strings being tested.
> Thinking on this some more, I think I was mistaken. We don't need to
> test for both arch and data model. I was just assuming that
> "sun.arch.data.model" might not be as reliable as "os.arch". On the
> other hand, the heuristics here are rather specific to using hotspot
> and open/oraclejdk, so for all practical cases, using
> sun.arch.data.model should be safe. New webrev using just data.model:
> It would be good to provide hooks to control this behavior of sjavac.
> Will file a followup bug for that.
>> -- Jon
More information about the compiler-dev