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

>> 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.

You say that, but last time I tried to do virtualisation on Linux, it 
/did/ actually require loading a special kernel module. (Which is 
presumably why it didn't work when I tried it...)

No idea how it works in Windows.

Post a reply to this message

On 8/12/2012 13:35, Orchid Win7 v1 wrote:
> The only problem with that, of course, is that paging is controlled by the
> operating system, not by a user-level application program.

Not in this system. I believe Linux now has a hack in it that lets you get 
first dibs on page faults.

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

Yep. And the room the box was in was full of mainframes, including three 
tape carousels that held 2.5TB each. You've just never worked for a company 
with enough money to buy stuff.

-- 
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

On 13/08/2012 03:54 PM, Darren New wrote:
> On 8/12/2012 13:35, Orchid Win7 v1 wrote:
>> The only problem with that, of course, is that paging is controlled by
>> the
>> operating system, not by a user-level application program.
>
> Not in this system. I believe Linux now has a hack in it that lets you
> get first dibs on page faults.

Hmm, OK.

>> And you're claiming you had 100x more than that IN RAM? Somehow, I
>> doubt it.
>
> Yep. And the room the box was in was full of mainframes, including three
> tape carousels that held 2.5TB each. You've just never worked for a
> company with enough money to buy stuff.

So you're saying that the fact that British Telecom plc could only 
afford 25.2GB of spinning disk for a mission-critical system means that 
they're "not big enough" to play with the Big Boys? :-P

Post a reply to this message