http://www.infoq.com/news/2012/08/azul-zing-free

I am pretty sure this means it's real-time GC.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

Le 12/08/2012 02:40, Darren New nous fit lire :
> http://www.infoq.com/news/2012/08/azul-zing-free
> 
> I am pretty sure this means it's real-time GC.
> 
there was already the trick of serial GC vs parallel GC (or how to get a
java application out of trouble when GC kick in, since JVM 5.0)

(GC: garbage collector)

Post a reply to this message

On 12/08/2012 01:40 AM, Darren New wrote:
> http://www.infoq.com/news/2012/08/azul-zing-free
>
> I am pretty sure this means it's real-time GC.

Oh thank God. They've had this magical silver bullet all along, and now 
they've /finally/ released it to the rest of the world. How did we ever 
manage without it? :-P

I like how the algorithm description is sufficiently vague that you 
can't tell how it actually works. It claims to be able to mark 
concurrently "without live objects escaping the collector's reach", but 
doesn't explain how. It says it can delete a page after all objects have 
been relocated, and it "detects" any attempt to access a moved object, 
but again doesn't say how. (It sure /sounds/ like they're saying they do 
some O(n) operation on every single pointer read, which is of course 
absurd.) Come to think of it, they say they use page features to 
implement some of this stuff - which is interesting, since only the OS 
can do that...

Also,

   "Initial in-memory tests on the full Wikipedia English-language site 
index show Zing is truly pauseless while managing a heap in excess of 
140 GB."

Since it's impossible to have a machine with 140GB of RAM, what's the 
point of having a heap that large? It'll just spend forever swapping. 
Surely you'd get far better performance by implementing some explicit 
file handling yourself?

Post a reply to this message

On 8/12/2012 2:23, Orchid Win7 v1 wrote:
> I like how the algorithm description is sufficiently vague that you can't
> tell how it actually works.

It was four clicks away, with the previous three clicks giving successively 
more detailed descriptions.

http://labs.oracle.com/jtech/pubs/04-g1-paper-ismm.pdf

You're welcome.

> it "detects" any attempt to access a moved object, but again doesn't say
> how.

Memory mapping. It traps on reading the memory that hasn't been fixed yet, 
then fixed up the entire page worth of references, then marks the memory as 
readable.

> Since it's impossible to have a machine with 140GB of RAM,

Since when is it impossible? We had 128G of RAM on the Sparcstation we used 
back in 1995 or so. And that wasn't even a mainframe.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

Orchid Win7 v1 wrote:
> Since it's impossible to have a machine with 140GB of RAM, what's the
> point of having a heap that large? It'll just spend forever swapping.
> Surely you'd get far better performance by implementing some explicit
> file handling yourself?

I'm don't know why you might think that.

http://www.tacc.utexas.edu/user-services/user-guides/lonestar-user-guide#overview:upgrade:largemem

Post a reply to this message

On 12/08/2012 05:27 PM, Darren New wrote:
> On 8/12/2012 2:23, Orchid Win7 v1 wrote:
>> I like how the algorithm description is sufficiently vague that you can't
>> tell how it actually works.
>
> It was four clicks away, with the previous three clicks giving
> successively more detailed descriptions.
>
> http://labs.oracle.com/jtech/pubs/04-g1-paper-ismm.pdf
>
> You're welcome.

No.

This is the GC from Sun, the GC that the Azul one is supposed to be 
superior to.

>> it "detects" any attempt to access a moved object, but again doesn't say
>> how.
>
> Memory mapping. It traps on reading the memory that hasn't been fixed
> yet, then fixed up the entire page worth of references, then marks the
> memory as readable.

So you mean it relocates an entire page of live objects, and then uses 
page faults to detect access to the non-existent page and lookup where 
the data has gone?

The only problem with that, of course, is that paging is controlled by 
the operating system, not by a user-level application program.

>> Since it's impossible to have a machine with 140GB of RAM,
>
> Since when is it impossible? We had 128G of RAM on the Sparcstation we
> used back in 1995 or so. And that wasn't even a mainframe.

That's interesting. Because in 1998, I did some work experience with BT. 
One day I was showed into their main datacenter, and their most powerful 
server was running off a RAID-5 array containing not one, not two, not 
three, but SEVEN 4.2 GB drives. I remember feeling slightly giddy trying 
to work out how many multiple gigabytes of data that thing must be able 
to hold in total.

And you're claiming you had 100x more than that IN RAM? Somehow, I doubt it.

Post a reply to this message

Am 12.08.2012 11:23, schrieb Orchid Win7 v1:

> Come to think of it, they say they use page features to
> implement some of this stuff - which is interesting, since only the OS
> can do that...

"Three successive generations of Azul's Vega series systems relied on 
custom multi-core processors and a custom OS kernel to deliver both the 
scale and features needed to support Pauseless GC. In 2010, Azul 
released its first software-only commercial implementation of C4 for 
modern commodity X86 hardware, using Linux kernel enhancements to 
support the required feature set."

Virtualization features maybe, dunno.

Post a reply to this message

On 13/08/2012 10:47 AM, clipka wrote:
> Am 12.08.2012 11:23, schrieb Orchid Win7 v1:
>
>> Come to think of it, they say they use page features to
>> implement some of this stuff - which is interesting, since only the OS
>> can do that...
>
> "Three successive generations of Azul's Vega series systems relied on
> custom multi-core processors and a custom OS kernel to deliver both the
> scale and features needed to support Pauseless GC. In 2010, Azul
> released its first software-only commercial implementation of C4 for
> modern commodity X86 hardware, using Linux kernel enhancements to
> support the required feature set."

Oh, wait - you have to run a customised OS kernel for it to work? Yeah, 
OK, that explains it then...

Post a reply to this message

Am 12.08.2012 22:35, schrieb Orchid Win7 v1:

> So you mean it relocates an entire page of live objects, and then uses
> page faults to detect access to the non-existent page and lookup where
> the data has gone?
>
> The only problem with that, of course, is that paging is controlled by
> the operating system, not by a user-level application program.

Yes, of course. That's also why virtual machines are mind-bogglingly 
slow and/or rely on specially patched OSes. Rrrright.

Andy, wake up.

Post a reply to this message

Am 13.08.2012 11:48, schrieb Invisible:
> On 13/08/2012 10:47 AM, clipka wrote:
>> Am 12.08.2012 11:23, schrieb Orchid Win7 v1:
>>
>>> Come to think of it, they say they use page features to
>>> implement some of this stuff - which is interesting, since only the OS
>>> can do that...
>>
>> "Three successive generations of Azul's Vega series systems relied on
>> custom multi-core processors and a custom OS kernel to deliver both the
>> scale and features needed to support Pauseless GC. In 2010, Azul
>> released its first software-only commercial implementation of C4 for
>> modern commodity X86 hardware, using Linux kernel enhancements to
>> support the required feature set."
>
> Oh, wait - you have to run a customised OS kernel for it to work? Yeah,
> OK, that explains it then...

You HAD to run a customised OS kernel for it to work.

If I understand it correctly, modern CPUs and modern Linux kernels 
already include all the necessary "customizations".

Post a reply to this message