sharing graal experiments

John Rose john.r.rose at
Mon Feb 18 19:30:45 PST 2013

On Feb 18, 2013, at 3:28 PM, John Rose <john.r.rose at> wrote:

> On Feb 18, 2013, at 2:26 PM, Christian Thalinger <christian.thalinger at> wrote:
>> On Feb 18, 2013, at 12:46 PM, "Deneau, Tom" <tom.deneau at> wrote:
>>> Just to make sure I understand,
>>> you are saying we do not need to create a separate sumatra/sumatra-dev/graal repo, we can just use Sumatra/Sumatra-dev/hotspot, which will occasionally be synced with graal/graal
>>> and graal/graal will occasionally be synced with some development version of hotspot.
>> Yes, that's what I thought would work best.  Not sure if John has other plans.
> This will work.  It does not conflict with any other use of sumatra-dev that I am envisioning.
> The plan of record for sumatra-dev is here:
> I have only one hesitation:  This move, of incorporating an advanced development project like Graal, can be done for at most one repo.  Is there any other OpenJDK repo. that we would want to incorporate?  I think not.  If it were 12 months ago, we might want to tie more closely to lambda/collections repos.  But there is no circumstance like that today.  What do you think?

One more thought:  How about if we have graal/graal copied into sumatra-dev/graal, keeping the existing copy of jdk8/hotspot also.

Upside:  There will always be a known-good snapshot of the whole jdk8/* forest, and builds will be known to work modulo local changes (whether on branches or not).

For graal-based experiments we would expect developers to remove the "stock" hotspot and replace it with graal (mv hotspot{,-jdk8}; mv graal hotspot).

Downsides: Redundancy (although the hotspot and graal repos would be near duplicates).  Uncertainty as to where to host branches (stock hotspot vs. graal).

— John

More information about the graal-dev mailing list